Steven Stallion wrote: > Daniel de Kok wrote: >> On Sat, Apr 5, 2008 at 6:03 PM, Steven Stallion <stallions at ociweb.com> >> wrote: >>> With regard to distributing a JVM, it is out of scope (see above). >> >> Not fully, since we can not distribute JVMs with e.g. Sun's >> indemnification clause. If this is to be a CentOS project, I think it >> should be runnable with CentOS plus a JDK that we can distribute. As >> far as I am aware, the only Sun-heritage JDK that we can distribute >> are the GPL'ed OpenJDK bits. Does JBoss work well with this JDK? > > I think there may be a misunderstanding of how JBoss is packaged and > shipped. There is no JVM distributed along with JBoss; CentAS would be > treated precisely the same. Again, it is designed to run on a number of > different JVM's which of course vary for each deployment platform. Well ... looking at this objectively, there is jboss.org already and it seems a vibrant community already. All the releases there are GPL and can be rebuilt and used. There is also this that I see "JBoss Enterprise Application Platform" .. which I assume is this from RHEL sources: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/JBEAP/SRPMS/ Now, that contains SRPMS that are jpp ... and must be compiled with some version of Java. So, that would need to be made work on an open version of Java (like java-1.6.0.openjdk). I also understand that Red Hat is selling other products as well that I do not see the SRPMS for (unless they are included in the ones I posted in JBEAP). These include all the other things listed here: http://www.jboss.com/products/index and here: http://www.redhat.com/jboss/ (Enterprise Portal Platform, Enterprise Data Services Platform, Enterprise SOA Platform, etc.) However, I see most of those things also here as GPL: http://sourceforge.net/project/showfiles.php?group_id=22866 more below ... > >> We require this for all CentOS-hosted projects and SIGs. CentOS is a >> long-term project, and having a development team member on a >> subproject will guarantee some continuity. Apart from that, some >> decisions (e.g. some policy decisions) may need to be delegated to the >> development team. > > Makse sense; thanks for the explanation. > >> May I ask a more explicit question: what advantages will a whitelabel >> JBoss stack give to CentOS over RHWAS, taking the additional >> maintenance "costs" into account? Additionally, how will continuity be >> guaranteed for existing users if Object Computing loses interest in >> maintaining this? > > As far as the advantages go, the a whitelabel JBoss allows for modified > redistributions of JBoss; currently this is not possible due to Red Hat > Trademark Guidelines. There are a number of projects/companies out there > which rely on JBoss, and in some cases require re-distributing JBoss > alongside their project. This then is where we require explanation. I understand the need for a scrubbed version of things to meet trademark restrictions. I see only this from the JBoss.com site: http://www.jboss.com/company/logos That points to the standard trademark page that we also use for guidance: http://www.redhat.com/about/companyprofile/trademark/ So, at this point, what we really need is a discussion about what it is we are trying to accomplish. By this I mean, show me something that says what needs to be removed (and I may have already published that in my links). Lets include in the discussion what files specifically we are going to try to scrub/rebuild and then redistribute ... and what license they are under,etc. Also in the discussion what form are redistributing in (SRPMS/RPMS ... tar balls ... etc.) I think be defining this we (the CentOS Core team) can better understand all the issues at hand. I can see the benefit of doing this, if it is done correctly ... and I think I see the need as well, but I also think a vibrant detailed discussion can be helpful as well. Thanks, JOhnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20080406/f4798bfc/attachment-0007.sig>