[CentOS-devel] Project proposal: CentAS

Johnny Hughes johnny at centos.org
Sun Apr 6 11:08:15 UTC 2008

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:

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:

and here:

(Enterprise Portal Platform, Enterprise Data Services Platform, 
Enterprise SOA Platform, etc.)

However, I see most of those things also here as GPL:

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:

That points to the standard trademark page that we also use for guidance:

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 

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.

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.sig>

More information about the CentOS-devel mailing list