Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41654E69.1000702@lfjr.net>
Date: Thu, 07 Oct 2004 16:10:49 +0200
From: Emmanuel Bourg <smanux@lfjr.net>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [configuration] handling exceptions in AbstractConfiguration
References: <PKENIMMEAHDAHILNLIJPEECGGKAB.epugh@upstate.com>
 <41647439.9020905@lfjr.net> <ck3bb2$kpl$1@tangens.hometree.net>
In-Reply-To: <ck3bb2$kpl$1@tangens.hometree.net>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Henning P. Schmiedehausen wrote:

> This is FUD. Hibenate is under LGPL. The LGPL and its implications are
> clearly defined by the FSF and they refuse (according to the board) to
> clarify the virality and the implications of the LGPL (which has been
> written a long, long time ago with C and C++ in mind) when used with
> Java code.

Yes, but it doesn't matter for projects not licensed by the FSF. The 
Hibernate team picked the LGPL, they acknowledged the ambiguity with 
regard to dynamic/static linking, and clarified how the LGPL applied for 
their work. Even if it is not mentionned in the license it still has a 
legal value, see my other post about this.

> The Hibernate people can write on their web site anything they
> want. In the end, the only License that you have is LGPL. This is,
> what counts in court. Not some "Licensing FAQ" which implies that
> program <xxx> is almost LGPL but not exactly and there is this
> exception if the wind is blowing from the east and christmas falls on
> a monday". [1]

You have the license + a clarification from the authors, that's enough 
to clear the uncertaincy. This clarification is not a promise like "You 
are infringing if you do so but I'll not sue you", I won't trust such a 
promise, but it is "You are not infringing if you do so".

> If the Hiberate people really _want_ to make exceptions, they could
> easily license under one of the true free licenses which have been
> approved by the OSI: e.g. ASFv2, OSL, BSD.

Or they can keep the LGPL and put an exception in it, some projects do 
this, for example GNU ClassPath that uses the GPL with an exception.


>>Excluding LGPLed projects is just a political decision imho.
> 
> 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

"5. A program that contains no derivative of any portion of the Library, 
but is designed to work with the Library by being compiled or linked 
with it, is called a "work that uses the Library". Such a work, in 
isolation, is not a derivative work of the Library, and therefore falls 
outside the scope of this License."

Great, no problem so far, it's the basic concept of the LGPL.


"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.


"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).


"If such an object file uses only numerical parameters, data structure 
layouts and accessors, and small macros and small inline functions (ten 
lines or less in length), then the use of the object file is 
unrestricted, regardless of whether it is legally a derivative work. 
(Executables containing this object code plus portions of the Library 
will still fall under Section 6.)"

Ok so even importing static variables from an interface is fine.


"Otherwise, if the work is a derivative of the Library, you may 
distribute the object code for the work under the terms of Section 6. 
Any executables containing that work also fall under Section 6, whether 
or not they are linked directly with the Library itself."

Ok, let's look at the section 6:

"6. As an exception to the Sections above, you may also combine or link 
a "work that uses the Library" with the Library to produce a work 
containing portions of the Library, and distribute that work under terms 
of your choice, provided that the terms permit modification of the work 
for the customer's own use and reverse engineering for debugging such 
modifications."

That means we are allowed to distribute only a part of the library, for 
example a modified jar containing only the classes needed for our project.


" 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:"

Fair enough. The following points explain how the source code can be 
distributed, I don't think it affects Java differently.

"For an executable, the required form of the "work that uses the 
Library" must include any data and utility programs needed for 
reproducing the executable from it. However, as a special exception, the 
materials to be distributed need not include anything that is normally 
distributed (in either source or binary form) with the major components 
(compiler, kernel, and so on) of the operating system on which the 
executable runs, unless that component itself accompanies the executable."

I think the distribution of the Ant or Maven build file complies with 
this requirement.

"It may happen that this requirement contradicts the license 
restrictions of other proprietary libraries that do not normally 
accompany the operating system. Such a contradiction means you cannot 
use both them and the Library together in an executable that you distribute"

It doesn't apply here.


So, what did I miss exactly ?

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org