You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2004/10/07 14:03:46 UTC
Re: [configuration] handling exceptions in AbstractConfiguration
Emmanuel Bourg <sm...@lfjr.net> writes:
> From a technical/legal point of view there is no reason to avoid a
>dependency on a LGPLed component in an Apache project, the license FAQ
>on Hibernate is pretty clear:
>"The use of the unmodified Hibernate binary of course never affects the
>license of your application or distribution.
>If you modify Hibernate and redistribute your modifications, the LGPL
>applies."
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.
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]
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.
>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.
Regards
Henning
(Can we keep the unavoidable licensing flame-fest centered on one
list? general@jakarta or even general@apache.org preferred).
[1] Everyone that uses Linux with binary modules _should_ be aware,
that this is really a GPL violation. The fact that the copyright
holder (Linus Torvalds) does not intend to sue, does not mean, that
there still is a license violation and strictly spoken, noone that
uses a binary module with the Linux kernel actually has a license for
the OS [2].
[2] personally, I couldn't live without the nvidia accelerated module. :-)
--
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
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Emmanuel Bourg wrote:
> Ricardo Gladwell wrote:
>> Henning P. Schmiedehausen wrote:
>>> (Can we keep the unavoidable licensing flame-fest centered on one
>>> list? general@jakarta or even general@apache.org preferred).
>>
>> I think you flamed first. Emmanuel just trolled :P
>
> Well I'm just highly interested in these license issues, I don't mean to
> flame anyone, it's just a courteous debate :)
>
> Emmanuel Bourg
Sorry, just me being facetious :)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Ricardo Gladwell wrote:
> Henning P. Schmiedehausen wrote:
>
>> (Can we keep the unavoidable licensing flame-fest centered on one
>> list? general@jakarta or even general@apache.org preferred).
>
>
> I think you flamed first. Emmanuel just trolled :P
Well I'm just highly interested in these license issues, I don't mean to
flame anyone, it's just a courteous debate :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Ricardo Gladwell <ri...@btinternet.com>.
Henning P. Schmiedehausen wrote:
> (Can we keep the unavoidable licensing flame-fest centered on one
> list? general@jakarta or even general@apache.org preferred).
I think you flamed first. Emmanuel just trolled :P
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@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
Re: [configuration] handling exceptions in AbstractConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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