Emmanuel Bourg <[EMAIL PROTECTED]> writes: >Henning P. Schmiedehausen wrote:
[...] >> No, it is not. You should try to consider the implications of >> e.g. paragraphs 5 and 6 of LGPLv2 in respect to your application. >Ok, let's look at them, let me know if my understanding of the license >is wrong. > From http://www.fsf.org/licenses/lgpl.html [...] >"However, linking a "work that uses the Library" with the Library >creates an executable that is a derivative of the Library (because it >contains portions of the Library), rather than a "work that uses the >library". The executable is therefore covered by this License. Section 6 >states terms for distribution of such executables." >I understand it is a static linking, that's when the compilation produce >one executable file containing both the author code and the library >code. It doesn't apply to Java since every component remains in its own >.class and .jar, all the code isn't melted into a single file. Is it? Who draws the line? Think .war deployment. Think in-war execution as e.g. WebLogic does. This is _one_ file, a complete application (executeable) which runs in its environment. From a lawyers point of view, it might not that much different from a self-extracting archive that runs on a command line (You can argue, that a WAR or EAR is a "distribution medium" for Java code, but then again: That is a question for a lawyer, not a developer). The distinction is blurred, right. The C-concepts simply don't apply to Java code. You and I try to find a technical solution for a legal problem. There is none. We simply use the wrong set of tools for this. LGPL is a license defined and backed by the FSF. If you choose to apply it verbatim to your code and distribute your code under this license, you (as the licensor) and the user as the licensee are _bound_ to this license! If you try to add additional restrictions to the LGPL, you might find out, that LGPL suddently does not apply anymore (paragraph 10) and in fact, no license between the two parties exist. This is stupid, but I have already seen incredibly stupid things in court. >"When a "work that uses the Library" uses material from a header file >that is part of the Library, the object code for the work may be a >derivative work of the Library even though the source code is not. >Whether this is true is especially significant if the work can be linked >without the Library, or if the work is itself a library. The threshold >for this to be true is not precisely defined by law." >Header files doesn't exist in Java, this point is moot. Once again there >is no code imported (I'm not sure about static variables in interfaces >though, I'll have to check this). Does it not? At which point, the code from the LGPL archive is referenced? At compile time (Which is clearly not linking, but inclusion in the C-sense)? Or at run-time? (Which would be dynamically linking in the C-sense). Inclusion would make your code a derived work! I can get even worse than this... :-) Imagine a malicious user writing a file --- cut --- package net.sf.hibernate; public interface Session extends java.io.Serializable { [... add lots of method signatures } --- cut --- and putting this under ASFv2 license. If I build against a set of mock interfaces, can the result be put onto an apache.org server? [...] >So, what did I miss exactly ? Nothing. You just _interpreted_ paragraph 5 and 6 with the intention that ASFv2 and LGPL are compatible. So you put some meaning into Java things like importing or runtime-references that fit your explanation. Thats fine and a valid point of view It is possible to interpret these things differently. And until the body that created the LGPL (FSF) clears these different points of view up, there are different interpretations. I was just trying to play devils' advocate here. The FSF refuses to clarify. So in the end, the board decided to play it safe. Which means "LGPL is viral when used with Java code, so we cannot have it on apache.org servers". On a personal note: I do agree with you. However, our agreement doesn't could much in a court. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development "Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems." -- Michelle Levesque, "Fundamental Issues with Open Source Software Development" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
