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 <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
