At 08:27 30/10/00 +0100, you wrote:
>Hi,
>
>First of all I have to thank you. Your postings are really
>useful for understanding the issues at hand.
>And is is nice to see someone who can cut the crap and get
>to the facts.
;)
>Peter Donald wrote:
>> >There is another good argument in favor of "mere aggregation":
>> >- Neither the jboss.jar nor the tomcat.jar have been changed
>> > or modified in any way. They are both embedded in the same
>> > file, but they have not been combined.
>>
>> They have been combine because jBoss hardwires interaction to tomcat jars.
>
>So we should avoid hardwired class and method names to
>non-GPLed java code.
right. But it more covers general interactions. For instance even if you
completely made classes/methods configuration dependent but you used
facilities that were only available in a particular other codebase (and not
implemented in another product) then you are in questionable ground. Thou
there has been close cases both ways
>> >If an archive containing unmodified jboss.jar and unmodified
>> >tomcat.jar is distributed under GPL, that would clearly be a
>> >violation of APL. And distributing it under APL would be a
>> >violation of GPL. But do we have to distribute the archive
>> >under one of these licenses?
>>
>> if jBoss removes the tomcat linking classes, all MBeans, and the libraries
>> (and any other non-GPL compatable stuff) it would not violate the GPL but
>> it would also not be very useful now would it ?
>
>We are getting to the heart of the problem.
>
>Before continuing I would like to define what GNU considers
>"platform code" for Java.
>- The virtual machine.
>- Low-level runtime system.
>- Any code in java.* and javax.* packages, and subpackages.
>Please let me know if you disagree with this definition.
I don't have any opinion on the definition but it is the GNU's position
that only code installed with the VM is part of the platform. Thus all code
like java.* is platform, some code in javax.* is platform (and also code in
org.omg.corba.*).
>1) Tomcat linking.
>We should not hardwire class and method names of Tomcat.
>But if we do not do this, and instead have configuration
>files that enable enable the end user to set up how to
>start "a web server" (ie. not just Tomcat), this would be
>OK, _even_ if the default configuration would start Tomcat
>if present.
yep that is fine.
>2) MBeans.
>Just checked this. Looks very much like "platform code" to
>me: All user-accessible classes in javax.management and
>subpackages, with some internal classes in com.sun.*.
well I guess it hinges on your definition of what is platform. GNU lawyers
would argue that you defined platform wrongly ;)
>3) Libraries.
>We use java.* and javax.* a lot but this is "platform code".
>Also use JMX, but that is MBeans above.
>Also use an org.jnp.* library for JNDI, but that is copyright
>Dreambean Software and placed under GPL.
>Do we use other libraries outside java.* and javax.* ?
>(Have to check)
I think you use castor aswell ?? But as I said I am under impression that
the majority of the rest of this is not platform code.
>4) Any other non-GPL compatible stuff.
>Do we use any other non-GPL compatible stuff ?
>(Have to check)
not that I noticed (thou I only browsed and grepped ;])
>Hey, me slashdotter, me no loon ;-)
;)
>What an interesting discussion it could be if RMS complains
>that someone do _not_ want to change _away_ from the GPL...
It is more likely that he will disallow you to use the GPL license. As
either he or FSF owns the GPL he has that right.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
