www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Date Fri, 07 Feb 2003 13:14:29 GMT
Santiago Gala wrote:
> Stefano Mazzocchi wrote:
> 
>> Morgan Delagrange wrote:
>>
>>> OK, Java-specific question.  It seems likely that
>>> altering or inlining LGPL code pollutes the Apache
>>> license.  Are you of the opinion that IMPORTING but
>>> not altering or distributing LGPL classes pollutes the
>>> Apache licecnse?  And if so, can that be stated on the
>>> Wiki page?  If LGPL code cannot be imported, it's
>>> pretty much useless in any capacity for Java projects.
>>
>>
>>
>> Bingo.
>>
>> The only *reasonable* way of dealing with LGLP stuff would be thru 
>> some for of reflection (reflection, for those who don't know, is the 
>> ability for java to connect to 'named' resources of classes. it's the 
>> most *dynamic* form of loading for a language which is already 
>> entirely dynamically loaded).
>>
>> So, suppose that LGPLObject is there somewhere in your classloading 
>> space (the classloader is the virtual machine subsystem that looks for 
>> your classes, classes being the objects and main units for java 
>> programs, all classes are always dynamically loaded)
>>
>> and this LGPLObject contains the method (java terminology for a 
>> function) called doSomething()
>>
>> If you use *regular* programming practices you have to do
>>
>>  import LGPLObject;
>>
>> then
>>
>>  LGPLObject o = new LGPLObject();
>>  o.doSomething();
>>
>> that will
>>
>>  1) ask the classloader to find that object
>>  2) allocate memory for it
>>  3) create the object
>>  4) invoke the object method doSomething
>>
>> This means, mostly, for legal sakes that the LGPLObject *MUST* be in 
>> the classloading space during compilation time.
>>
> 
> In legal terms, your program will not build without a class named 
> LGPLObject which has a public doSomething() method. 

Incorrect: it will *build*, but it will not *execute*.

> So, you *depend* on 
> it. In a sense, with import you're stating dependency in your sources.

True. This is the reason why this legal route-around will not work 
against GPL, but only against LGPL.

>> Now, if we use reflection, we can do
>>
>>   Class c = Class.forName("LGPLObject");
>>   Object o = c.newInstance();
>>   Method doSomething = c.getMethod("doSomething");
>>   doSomething.invoke();
>>
>> which compiles even without having the LGPL library in your classpath.
>>
> 
> In legal term, again, your program will *behave differently* if a class 
> named LGPLObject exists in your runtime environment and it happens to 
> have a doSomething() public method. With dynamic loading you're not 
> stating dependency, merely *acknowledging existence*.

This accademic trick is done to prove there is a way to totally isolate 
the virality of LGPL in Java (at least, that's my personal opinion). I 
think it would be pretty hard to state that my program can be considered 
part of the LGPL-ed library if I call build it even if it's not even 
present on my disk.

> As the concept of "derivative work" is about something that extends or 
> change a preexisting work, the second approach will probably skip it 
> (specially if your program tests for the result of the snippet code and 
> survives when the given class is not in the path).

Exactly.

> I don't think that even reflection will stand in court if your program 
> cannot perform its duty without the given library being there. I.E. fine 
>  when alternate services can perform a task, or for non-essential 
> components of a project.

Again, you are not taking into account that I working again the LGPL, 
not the GPL. There is no way to route around GPL. It was very carefully 
designed for that purpose.

>> *BUT* programming java in this way is *FOOLISH*. Reflection was 
>> created to load classes programmatically at runtime, it was not 
>> created as a way to route around legal problems.
>>
> 
> +1
> 
> <disclaimer type="IANAL">
>    ditto. Also, I am just a plain committer, so take it as just my opinion.
> </disclaimer>

let me state again that I consider this discussion pretty accademic 
(there is no way in the world I would suggest going down the reflection 
path to use a LGPL library... it would be much easier to rewrite the 
damn library or convince the author to change the licensing!)

Still, I think we need to sort out all possible cases since they're 
going to come up again in the future.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message