You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Brian Behlendorf <br...@collab.net> on 2004/12/31 03:20:18 UTC
Regarding Java and the LGPL (fwd)
For what it's worth, here is the letter I sent to the FSF earlier this
month asking for further LGPL clarification. No response yet, but it's
the holidays.
Brian
---------- Forwarded message ----------
Date: Sat, 18 Dec 2004 19:19:17 -0800 (PST)
From: Brian Behlendorf <br...@apache.org>
To: Dave Turner <no...@gnu.org>, licensing@gnu.org
Subject: Regarding Java and the LGPL
Dear David, and others at licensing@gnu.org,
Recently we noticed an addition to the FSF's web site:
http://www.gnu.org/licenses/lgpl-java.html
We welcome this move by the FSF to educate and clarify. We have projects at
the Apache Software Foundation that are eager to be able to make use of
LGPL-licensed Java works. We respect the commonly-accepted intention of the
LGPL, which is to ensure that improvements to the LGPL-licensed work can be
made, while not encumbering the license of other works that use the
LGPL-licensed work. We also respect the right-to-tinker freedom embodied in
section 6 of the LGPL, especially as with Java this is trivially easy to
accomplish.
We feel, however, that the LGPL, and your clarification, still leave us with
many questions. It is also clear from the fact that several LGPL Java
applications are dual-licensing with other "medium-strength copyleft" licenses
like the MPL and CPL, or are adding additional terms to their LGPL license like
the Hibernate project has, that these uncertainties remain. Part of the
problem is that the language in the LGPL is still specific to the world of
compiled executables, and not as relevant to the world of bytecode interpreters
and name-based loaders.
We'd like your feedback on a number of scenarios, as clearly as possible, so we
can determine whether we can lift the existing moratorium on importing
LGPL-licensed works. Please let us know if any particular scenario needs more
fleshing out; but the idea was to reduce the examples as tightly as possible.
In the following, A represents an Apache Software License-licensed
work, and L represents the LGPL-licensed works. A would contain the
parts of L necessary to make import and inheritance references to L,
but it is only used when the user chooses to separately download L.
Assume that those interfaces are unique to L, not an implementation of
interfaces defined elsewhere. A_s and A_c are the source code and
compiled forms of A, and L_s and L_c are the source and compiled forms
of L.
1) A_s is distributed from apache.org, without L anywhere nearby.
Despite the references to L in A_s, can we distribute A_s under the
license of our choosing?
2) A_c is distributed from apache.org. It was compiled with L_c in
the classpath, so function signatures were checked. Can we distribute
A_c under the license of our choosing?
3) A_s and L_s are combined into a single tarball and distributed.
Does section 5 of the LGPL, or section 6 of the LGPL, or neither apply
to the tarball as a whole?
4) A_c and L_c are combined into a single tarball and distributed.
Does section 5 of the LGPL, or section 6 of the LGPL, or neither apply
to the tarball as a whole?
5) Say a recipient downloads the tarball defined in question #3,
deletes L_s, and distributes A_s. Can that recipient then follow only
the terms of copyright on A_s?
6) Say a recipient downloads the tarball defined in question #3,
deletes L_c, and distributes A_c. Can that recipient then follow only
the terms of copyright on A_c?
We have our own interpretations and opinions of the answers to these
questions, and we think LGPL users have a set of interpretations as
well, but they differed so widely we felt there was a need to
understand your interpretation and how that maps to the language in
the LGPL.
Thanks,
Brian Behlendorf
Director, ASF
Re: Regarding Java and the LGPL (fwd)
Posted by Paul Libbrecht <pa...@hoplahup.net>.
Le 1 juin 2012 à 01:14, Roy T. Fielding a écrit :
> One of the nice things about today's Alsup ruling is that we
> can finally, definitively, and without regard to the FSF's opinions,
> resolve the issue of name-based dynamic binding in Java and its
> meaning for the LGPL terms. The names are not copyrightable.
>
> http://www.groklaw.net/article.php?story=20120531173633275
This seems to be indeed fairly rejoicing news.
A little request for clarification: what is the difference in binding by name of Java and of the symbols of libtool?
From the summary up there, I read that this is the "API functional-structure", is that right?
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Regarding Java and the LGPL (fwd)
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 1/06/12 8:30pm, Sam Ruby wrote:
> On Thu, May 31, 2012 at 11:22 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>>
>> On May 31, 2012, at 6:09 PM, Sam Ruby wrote:
>>
>>> On Thu, May 31, 2012 at 7:14 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>>>> One of the nice things about today's Alsup ruling is that we
>>>> can finally, definitively, and without regard to the FSF's opinions,
>>>> resolve the issue of name-based dynamic binding in Java and its
>>>> meaning for the LGPL terms. The names are not copyrightable.
>>>>
>>>> http://www.groklaw.net/article.php?story=20120531173633275
>>>
>>> An article on CNET suggests that the ruling is more narrow than that:
>>>
>>> http://news.cnet.com/8301-13578_3-57444928-38/judge-says-37-oracle-apis-are-not-copyrightable/
>>
>> It isn't general to all APIs. It is general to the issue of name-based
>> dynamic binding in Java because that is why the specific APIs were
>> deemed non-copyrightable.
>
> I continue to read the decision as more narrow than that you imply:
>
> "Rather, it holds on the specific facts of this case, the particular
> elements replicated by Google were free for all to use under the
> Copyright Act."
I can't speak so much for the American legal system, but in the British and Australian common law system (which is very similar in many ways), a judgement on its own is neither narrow nor broad. A judgement stands on its own facts until such time as it is cited in a future case. The more often it is cited on slightly different facts, the broader the interpretation becomes. Often the way judges distinguish (that is, ignore) previous judgements is by interpreting them as narrowly as possible, exactly as Alsup did with the Dentalab case.
Common law is essentially revisionist history of case decisions. Over time the bits that judges like are referenced again and again, and become the basis of common law you can rely on. This one case from a Circuit court isn't that, but it is certainly a strong precedent which I am sure will be cited by lawyers everywhere in the USA for years to come. We'll know in 20 years whether it stands the test of time. All of us hope so, but I think it is a little early for Apache to base any major decisions on just yet.
One problem with the GPL is that there are so few cases brought on it, that there just isn't enough case law to state whether using an API ("binding") from a GPL program will infect the whole application as GPL. FSF think so [1] and that using "exec" magically eliminates the API binding problem[2] although I'm personally at a loss to explain why kernel threads have anything to do with copyright law. Certainly Alsup's decision raises some interesting questions. I'd say this questions appears a long way from "finally, definitively".
Ari Maniatis
[1] http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
[2] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
>
>> IOW, he affirmed Larry's interpretation of the same copyright laws.
>
> It certainly is not inconsistent with that interpretation.
>
>> ....Roy
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Regarding Java and the LGPL (fwd)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, May 31, 2012 at 11:22 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>
> On May 31, 2012, at 6:09 PM, Sam Ruby wrote:
>
>> On Thu, May 31, 2012 at 7:14 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>>> One of the nice things about today's Alsup ruling is that we
>>> can finally, definitively, and without regard to the FSF's opinions,
>>> resolve the issue of name-based dynamic binding in Java and its
>>> meaning for the LGPL terms. The names are not copyrightable.
>>>
>>> http://www.groklaw.net/article.php?story=20120531173633275
>>
>> An article on CNET suggests that the ruling is more narrow than that:
>>
>> http://news.cnet.com/8301-13578_3-57444928-38/judge-says-37-oracle-apis-are-not-copyrightable/
>
> It isn't general to all APIs. It is general to the issue of name-based
> dynamic binding in Java because that is why the specific APIs were
> deemed non-copyrightable.
I continue to read the decision as more narrow than that you imply:
"Rather, it holds on the specific facts of this case, the particular
elements replicated by Google were free for all to use under the
Copyright Act."
> IOW, he affirmed Larry's interpretation of the same copyright laws.
It certainly is not inconsistent with that interpretation.
> ....Roy
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Regarding Java and the LGPL (fwd)
Posted by Greg Stein <gs...@gmail.com>.
On Jun 1, 2012 1:53 PM, "Lawrence Rosen" <lr...@rosenlaw.com> wrote:
>
> Greg Stein wrote:
>
> Nah... I can't see a damage award being all that high. Likely quite a bit
less than the cost to litigate.
>
> I also seem to recall reading somewhere that appealing a *jury* trial is
a huge burden to overcome. Appealing one judge's thoughts is one thing, but
a jury? Difficult.
>
> And recall that appeals are usually based on procedure or interpretation
of law. Facts from the original case cannot be appealed... they're facts
:-) (and I seem to recall jury answers become a fact).
>
>
>
> LOL. It is a little more complicated than that, but if you draw the
conclusion that appeals are on average difficult and unproductive, that’s
right.
Hehe... I'd be fine with "vastly more complicated" :-P
RE: Regarding Java and the LGPL (fwd)
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Greg Stein wrote:
Nah... I can't see a damage award being all that high. Likely quite a bit
less than the cost to litigate.
I also seem to recall reading somewhere that appealing a *jury* trial is a
huge burden to overcome. Appealing one judge's thoughts is one thing, but a
jury? Difficult.
And recall that appeals are usually based on procedure or interpretation of
law. Facts from the original case cannot be appealed... they're facts :-)
(and I seem to recall jury answers become a fact).
LOL. It is a little more complicated than that, but if you draw the
conclusion that appeals are on average difficult and unproductive, that's
right.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com>
www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242
From: Greg Stein [mailto:gstein@gmail.com]
Sent: Friday, June 01, 2012 10:42 AM
To: Mark Struberg; legal-discuss@apache.org
Subject: Re: Regarding Java and the LGPL (fwd)
On Jun 1, 2012 6:29 AM, "Mark Struberg" <st...@yahoo.de> wrote:
>...
> As someone pointed out, this is also a much more complex 'political' game.
If Oracle does _not_ appeal, would they than risk getting sued by their own
share holders (for not trying to do in their best interrest) ?
Nah... I can't see a damage award being all that high. Likely quite a bit
less than the cost to litigate.
I also seem to recall reading somewhere that appealing a *jury* trial is a
huge burden to overcome. Appealing one judge's thoughts is one thing, but a
jury? Difficult.
And recall that appeals are usually based on procedure or interpretation of
law. Facts from the original case cannot be appealed... they're facts :-)
(and I seem to recall jury answers become a fact).
Cheers,
-g
Re: Regarding Java and the LGPL (fwd)
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Jun 1, 2012 at 7:41 PM, Greg Stein <gs...@gmail.com> wrote:
> I also seem to recall reading somewhere that appealing a *jury* trial is a
> huge burden to overcome. Appealing one judge's thoughts is one thing, but a
> jury? Difficult.
>
> And recall that appeals are usually based on procedure or interpretation
> of law. Facts from the original case cannot be appealed... they're facts
> :-) (and I seem to recall jury answers become a fact).
>
> The jury's result in this case was "if API's can be copyrighted, then this
was infringement". It was the judge who decided that they can't be
copyrighted.
Re: Regarding Java and the LGPL (fwd)
Posted by Greg Stein <gs...@gmail.com>.
On Jun 1, 2012 6:29 AM, "Mark Struberg" <st...@yahoo.de> wrote:
>...
> As someone pointed out, this is also a much more complex 'political'
game. If Oracle does _not_ appeal, would they than risk getting sued by
their own share holders (for not trying to do in their best interrest) ?
Nah... I can't see a damage award being all that high. Likely quite a bit
less than the cost to litigate.
I also seem to recall reading somewhere that appealing a *jury* trial is a
huge burden to overcome. Appealing one judge's thoughts is one thing, but a
jury? Difficult.
And recall that appeals are usually based on procedure or interpretation of
law. Facts from the original case cannot be appealed... they're facts :-)
(and I seem to recall jury answers become a fact).
Cheers,
-g
Re: Regarding Java and the LGPL (fwd)
Posted by Mark Struberg <st...@yahoo.de>.
I try to recap what I understood from glancing over those 40 pages.
> Oracle is likely to appeal the ruling, so what if the next ruling says
> something different ? (just curious)
That might happen. But the ruling has a very detailed (both technically and legally) argumentation chain. And this chain is more of the kind of the ones from a tank and not from a filigree necklace ;)
Also: currently the ruling is explicitly only valid for those 37 APIs.
If Oracle would loose the appeal, the next court might even widen it to a general rule (as the EuGH already did afaik).
As someone pointed out, this is also a much more complex 'political' game. If Oracle does _not_ appeal, would they than risk getting sued by their own share holders (for not trying to do in their best interrest) ?
LieGrue,
strub
----- Original Message -----
> From: Emmanuel Lécharny <el...@gmail.com>
> To: legal-discuss@apache.org
> Cc:
> Sent: Friday, June 1, 2012 12:03 PM
> Subject: Re: Regarding Java and the LGPL (fwd)
>
> Le 6/1/12 5:22 AM, Roy T. Fielding a écrit :
>> On May 31, 2012, at 6:09 PM, Sam Ruby wrote:
>>
>>> On Thu, May 31, 2012 at 7:14 PM, Roy T.
> Fielding<fi...@gbiv.com> wrote:
>>>> One of the nice things about today's Alsup ruling is that we
>>>> can finally, definitively, and without regard to the FSF's
> opinions,
>>>> resolve the issue of name-based dynamic binding in Java and its
>>>> meaning for the LGPL terms. The names are not copyrightable.
>>>>
>>>> http://www.groklaw.net/article.php?story=20120531173633275
>>> An article on CNET suggests that the ruling is more narrow than that:
>>>
>>>
> http://news.cnet.com/8301-13578_3-57444928-38/judge-says-37-oracle-apis-are-not-copyrightable/
>> It isn't general to all APIs. It is general to the issue of name-based
>> dynamic binding in Java because that is why the specific APIs were
>> deemed non-copyrightable.
>>
>> IOW, he affirmed Larry's interpretation of the same copyright laws.
>
> Oracle is likely to appeal the ruling, so what if the next ruling says
> something different ? (just curious)
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Regarding Java and the LGPL (fwd)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 6/1/12 5:22 AM, Roy T. Fielding a écrit :
> On May 31, 2012, at 6:09 PM, Sam Ruby wrote:
>
>> On Thu, May 31, 2012 at 7:14 PM, Roy T. Fielding<fi...@gbiv.com> wrote:
>>> One of the nice things about today's Alsup ruling is that we
>>> can finally, definitively, and without regard to the FSF's opinions,
>>> resolve the issue of name-based dynamic binding in Java and its
>>> meaning for the LGPL terms. The names are not copyrightable.
>>>
>>> http://www.groklaw.net/article.php?story=20120531173633275
>> An article on CNET suggests that the ruling is more narrow than that:
>>
>> http://news.cnet.com/8301-13578_3-57444928-38/judge-says-37-oracle-apis-are-not-copyrightable/
> It isn't general to all APIs. It is general to the issue of name-based
> dynamic binding in Java because that is why the specific APIs were
> deemed non-copyrightable.
>
> IOW, he affirmed Larry's interpretation of the same copyright laws.
Oracle is likely to appeal the ruling, so what if the next ruling says
something different ? (just curious)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Regarding Java and the LGPL (fwd)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On May 31, 2012, at 6:09 PM, Sam Ruby wrote:
> On Thu, May 31, 2012 at 7:14 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>> One of the nice things about today's Alsup ruling is that we
>> can finally, definitively, and without regard to the FSF's opinions,
>> resolve the issue of name-based dynamic binding in Java and its
>> meaning for the LGPL terms. The names are not copyrightable.
>>
>> http://www.groklaw.net/article.php?story=20120531173633275
>
> An article on CNET suggests that the ruling is more narrow than that:
>
> http://news.cnet.com/8301-13578_3-57444928-38/judge-says-37-oracle-apis-are-not-copyrightable/
It isn't general to all APIs. It is general to the issue of name-based
dynamic binding in Java because that is why the specific APIs were
deemed non-copyrightable.
IOW, he affirmed Larry's interpretation of the same copyright laws.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Regarding Java and the LGPL (fwd)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, May 31, 2012 at 7:14 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> One of the nice things about today's Alsup ruling is that we
> can finally, definitively, and without regard to the FSF's opinions,
> resolve the issue of name-based dynamic binding in Java and its
> meaning for the LGPL terms. The names are not copyrightable.
>
> http://www.groklaw.net/article.php?story=20120531173633275
An article on CNET suggests that the ruling is more narrow than that:
http://news.cnet.com/8301-13578_3-57444928-38/judge-says-37-oracle-apis-are-not-copyrightable/
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Regarding Java and the LGPL (fwd)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
One of the nice things about today's Alsup ruling is that we
can finally, definitively, and without regard to the FSF's opinions,
resolve the issue of name-based dynamic binding in Java and its
meaning for the LGPL terms. The names are not copyrightable.
http://www.groklaw.net/article.php?story=20120531173633275
....Roy
On Dec 30, 2004, at 6:20 PM, Brian Behlendorf wrote:
>
> For what it's worth, here is the letter I sent to the FSF earlier this month asking for further LGPL clarification. No response yet, but it's the holidays.
>
> Brian
>
> ---------- Forwarded message ----------
> Date: Sat, 18 Dec 2004 19:19:17 -0800 (PST)
> From: Brian Behlendorf <br...@apache.org>
> To: Dave Turner <no...@gnu.org>, licensing@gnu.org
> Subject: Regarding Java and the LGPL
>
>
> Dear David, and others at licensing@gnu.org,
>
> Recently we noticed an addition to the FSF's web site:
>
> http://www.gnu.org/licenses/lgpl-java.html
>
> We welcome this move by the FSF to educate and clarify. We have projects at the Apache Software Foundation that are eager to be able to make use of LGPL-licensed Java works. We respect the commonly-accepted intention of the LGPL, which is to ensure that improvements to the LGPL-licensed work can be made, while not encumbering the license of other works that use the LGPL-licensed work. We also respect the right-to-tinker freedom embodied in section 6 of the LGPL, especially as with Java this is trivially easy to accomplish.
>
> We feel, however, that the LGPL, and your clarification, still leave us with many questions. It is also clear from the fact that several LGPL Java applications are dual-licensing with other "medium-strength copyleft" licenses like the MPL and CPL, or are adding additional terms to their LGPL license like the Hibernate project has, that these uncertainties remain. Part of the problem is that the language in the LGPL is still specific to the world of compiled executables, and not as relevant to the world of bytecode interpreters and name-based loaders.
>
> We'd like your feedback on a number of scenarios, as clearly as possible, so we can determine whether we can lift the existing moratorium on importing LGPL-licensed works. Please let us know if any particular scenario needs more fleshing out; but the idea was to reduce the examples as tightly as possible.
>
> In the following, A represents an Apache Software License-licensed
> work, and L represents the LGPL-licensed works. A would contain the
> parts of L necessary to make import and inheritance references to L,
> but it is only used when the user chooses to separately download L.
> Assume that those interfaces are unique to L, not an implementation of
> interfaces defined elsewhere. A_s and A_c are the source code and
> compiled forms of A, and L_s and L_c are the source and compiled forms
> of L.
>
> 1) A_s is distributed from apache.org, without L anywhere nearby.
> Despite the references to L in A_s, can we distribute A_s under the
> license of our choosing?
>
> 2) A_c is distributed from apache.org. It was compiled with L_c in
> the classpath, so function signatures were checked. Can we distribute
> A_c under the license of our choosing?
>
> 3) A_s and L_s are combined into a single tarball and distributed.
> Does section 5 of the LGPL, or section 6 of the LGPL, or neither apply
> to the tarball as a whole?
>
> 4) A_c and L_c are combined into a single tarball and distributed.
> Does section 5 of the LGPL, or section 6 of the LGPL, or neither apply
> to the tarball as a whole?
>
> 5) Say a recipient downloads the tarball defined in question #3,
> deletes L_s, and distributes A_s. Can that recipient then follow only
> the terms of copyright on A_s?
>
> 6) Say a recipient downloads the tarball defined in question #3,
> deletes L_c, and distributes A_c. Can that recipient then follow only
> the terms of copyright on A_c?
>
>
> We have our own interpretations and opinions of the answers to these
> questions, and we think LGPL users have a set of interpretations as
> well, but they differed so widely we felt there was a need to
> understand your interpretation and how that maps to the language in
> the LGPL.
>
> Thanks,
>
> Brian Behlendorf
> Director, ASF
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org