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.
> >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.
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.
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.*.
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)
4) Any other non-GPL compatible stuff.
Do we use any other non-GPL compatible stuff ?
(Have to check)
> >Both GPL and APL allow distribution and neither are viral in
> >case of simple aggregation, so it _should_ be possible to
> >distribute an archive that simply aggregates the unmodified
> >software from both of us. Do you agree on this?
>
> yep - as long as it is a distribution of distributions then it is OK. Thou
> jBoss still violates it with respect to all the stuff I said above.
Fine.
> >Do you think that the name of a Tomcat class and method
> >as defaults in an end user editable configuration file
> >would be a violation of the Tomcat APL license, or do
> >you think this would come under the "fair use" clause
> >of the copyright legislation?
>
> Not about the APL - the APL saids almost anything goes. It is the GPL that
> is the license that causes the restriction. Defaulting to Tomcat classes is
> fine as long as it is practicably possible to implement multiple webservers
> with ease - which means not using any special features of tomcat and having
> a "clean" interface.
Ok, fine.
> Whatever the case you have a window of about 3 days before RMS fires up and
> possibly a week or two before it will hit the relevent sites. If in that
> time you don't stop violation of GPL then you will feel the wrath of GNU
> community (which includes those loons at slashdot). This will not be
> pleasant for any involved. I would urge you to try to either fcomply with
> GPL or choose a new license in this time.
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...
Thanks again for your help, Pete.
Best Regards,
Ole Husgaard.
PS: Marc, let me know if you worry about the /. effect.
It can be _bad_ for about half a day if you are not prepared.
