On Sat, 28 Oct 2000, Jon Stevens wrote:
> on 10/28/2000 4:06 PM, "marc fleury" <[EMAIL PROTECTED]> wrote:
> > Indeed if the Avalon guy puts jBoss code in his tree and "contains" our work
> > in his work then yeah.. that needs to be GPL.
> Bingo. So, this is something that is a major problem for me.

        This is truly unfortunate.  There are definitely ares of code that
could be shared - that *should* be shared, such as logging, dynamic
proxies, thread pools, and so on.  It's too bad that it doesn't happen
until a javax package is available...  Particularly since those are *not*
open source (well, under a much more restrictive license, anyway).

On Sat, 28 Oct 2000, marc fleury wrote:
> |2.b.) You must cause any work that you distribute or publish, that in
> |whole or in part contains or is derived from the Program or any part
> |thereof, to be licensed as a whole at no charge to all third parties under
> |the terms of this License.
>
> again, "work that contains the Program" is code that "contains" physically 
> the Program (maybe thinking import in programming terms can help).

        What can I say?  I agree that this is a reasonable interpretation.  
But I don't think it's the only interpretation, and I'm not sure it's even
the interpretation intended by the authors.  There's another section that
specifically allows distribution of GPL and non-GPL programs on the same
medium (Linux distributions), and that passage would be redundant if this
passage reads as you suggest.
        I think it would definitely be safe to download a set of RPMs (one
per product) and then install them all and configure them to point to each
other (using network protocols, standard interfaces, etc.), but I think
it's very questionable whether you can put them in a single pre-configured
package.
        The problem is, I'm in a situation where (to quote "Ronin"),
"Whenever there's a doubt, there is no doubt."  Whatever you say, I
haven't heard anything that convinces me that the interpretation is clear
- I can easily see both sides of the disagreement.  I suspect the only way
for this to ultimately be resolved is to take it to a lawyer and/or RMS.  
Any volunteers?  :)

        Overall, the most unfortunate thing here is that I don't believe
either party is trying to lock out code from the other.  But the fact that
the licenses are not compatible means that one group or the other has to
change licenses in order to enable true sharing of code, which is one of
the greatest promises of open source.  And it doesn't sound like either
party is willing.

Aaron


Reply via email to