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. So, you *depend* on it. In a sense, with import you're stating dependency in your sources.
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*.
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).
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.
*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>
Regards,
Santiago
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
