Roy T. Fielding wrote:
Can I explore the issue a little bit further? The question that usually arises on Ant is not the storing and distribution of LGPL code itself, but the storing of code that "links" with or depends on the LGPL code. As an example, let's say we want to provide an SSH task for Ant (a recent question). There are a number of LGPL SSH java libraries around. The code in our respository would be developed under the ASF licence - it would consist of a Java class that merely drives the LGPL library. It will typically have import statements - something like:
import lgpl.sshlibrary.Thingy;
This code cannot be compiled without the LGPL library. Once compiled. however, it can be distributed without the library. To use the task code a user needs to supply the LGPL library independently.
So can the above code be stored in our repository? Can the compiled code be included in a binary distribution?
The import statement alone is sufficient to make the source code a work based on the Library, which means we could distribute under the terms of section 6. Those terms are viral and disallow binary-only releases, making our product viral because the Apache license does not require redistribution of source with executables.
In short, the answer is no, and this applies to any software with copyright of The Apache Software Foundation.
Roy, I'm trying hard to understand. I went into section 6 of http://www.gnu.org/copyleft/lesser.html, and suppose you are referring to one of the 5 conditions (a->e) in that clause which we cannot comply with.
Looking at a) and b), it seems this is possible:
<quote>
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
# a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
# b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
...
</quote>
To the best of my understanding (which might be flawed, of course), I think the idea of setting up a non-ASL jar repo might address these conditions. Could you clarify where my misunderstanding is?
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
