www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: primary distribution location
Date Wed, 05 Feb 2003 09:04:38 GMT
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message