Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Date: Mon, 24 Feb 2014 08:15:21 +0000 (UTC)
From: "Richard Eckart de Castilho (JIRA)" <jira@apache.org>
To: legal-discuss@apache.org
Message-ID: <JIRA.12696077.1392843762729.90924.1393229721954@arcas>
In-Reply-To: <JIRA.12696077.1392843762729@arcas>
References: <JIRA.12696077.1392843762729@arcas>
Subject: [jira] [Commented] (LEGAL-192) Why is LGPL not allowed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LEGAL-192?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13910=
090#comment-13910090 ]=20

Richard Eckart de Castilho commented on LEGAL-192:
--------------------------------------------------

{quote}
I understand that the LGPL does not require the entire Combined Work to be =
able to be modified: just that the LGPLd Library can be modified:

Your application's license needs to allow users to modify the library, and =
reverse engineer your code to debug these modifications. =E2=80=94 FSF 2004

I do not believe that "reverse engineering" is necessary in order to achiev=
e this goal on the JVM (unless we get into a jar signing sidetrack, or exot=
ic setups that use non-standard runtime environments).{quote}
{quote}

It appears to be irrelevant under which circumstances an reverse-engineerin=
g may actually be necessary. I would guess this means that the license any =
product using a non-optional LGPL library cannot have a anti-reverse-engine=
ering clause in their product license - something that many products indeed=
 do have. So any company trying to protect their investment by a anti-rever=
se-engineering clause or maybe by obfuscation, would be unlikely to choose =
using an LGPL library.

I could imagine it would be considered under the circumstance that there is=
 an absolutely clear boundary regarding how deep the library dependency pen=
etrates into the product code. If a library is optional, such a boundary is=
 bound to exist and anti-reverse-engineering clause could likely be applied=
 beyond these boundaries.=20

On the other hand, if it is not optional, it could be argued that it must b=
e possible to reverse engineer the whole product and that therefore anti-re=
verse-engineering clause and obfuscation constitute a violation of the LGPL=
 license terms.=20

Mind, I am just a humble developer, not a lawyer.

> Why is LGPL not allowed
> -----------------------
>
>                 Key: LEGAL-192
>                 URL: https://issues.apache.org/jira/browse/LEGAL-192
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Sam Halliday
>
> According to http://www.apache.org/legal/resolved.html the LGPL is not al=
lowed because
>   "The LGPL is ineligible primarily due to the restrictions it places on =
larger works, violating the third license criterion. Therefore, LGPL-licens=
ed works must not be included in Apache products."
> where part three is
>   "The license must not place restrictions on the distribution of larger =
works, other than to require that the covered component still complies with=
 the conditions of its license."
> But I see no conflict here with regard to distribution. The license clear=
ly states that software which uses LGPL software can be distributed under w=
hatever license the developer wishes:
>   http://www.gnu.org/licenses/lgpl-2.1.html
> The LGPL does, however, require that any changes to the LGPL component is=
 released as LGPL (including source code).
> I have an LGPL library and there is a desire to see it included in an Apa=
che project. Since my project places no constraint on the distribution of t=
he larger work, I do not see why I should have to change the license in ord=
er to comply with these rules.
> If I was using the GPL, I would see your point. But this is the LGPL and =
it appears to meet your objectives.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org