commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <...@intermeta.de>
Subject Re: [configuration] handling exceptions in AbstractConfiguration
Date Thu, 07 Oct 2004 15:18:18 GMT
Emmanuel Bourg <smanux@lfjr.net> 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
hps@intermeta.de        +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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message