www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Halliday (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-192) Why is LGPL not allowed
Date Sun, 23 Feb 2014 18:22:19 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909827#comment-13909827

Sam Halliday commented on LEGAL-192:

Thanks Marvin,

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:

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

I do not believe that "reverse engineering" is necessary in order to achieve this goal on
the JVM (unless we get into a jar signing sidetrack, or exotic setups that use non-standard
runtime environments). Both Roy and Larry have indicated that there are still some outstanding
points that could benefit from clarifying interpretations from the FSF, which I can now understand
and agree with from a technical point of view. Referring to Roy's comment above:

bq. the LGPL is designed for limited redistribution of shared libraries of the Unix/C variety.
Its terms are specific to that purpose. If you try to apply it to any other form of software,
the terms will lead to confusion...

... I can only infer that the confusion is in regards to the FSF's interpretation of what
"debug" and "reverse engineer" mean on the JVM. I postulate that a differentiator between
the MPL/EPL-style Category B licenses and the LGPL (specifically within the realms of JVM
projects), is that the FSF want end users to have the legal right to swap LGPL jars at runtime
with modified (or updated) versions.

Joshua, am I understanding the FSF's interpretation of Section 4 correctly, or have I completely
bastardised the philosophy? :-)

> 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 allowed because
>   "The LGPL is ineligible primarily due to the restrictions it places on larger works,
violating the third license criterion. Therefore, LGPL-licensed 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 clearly states that
software which uses LGPL software can be distributed under whatever license the developer
>   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 Apache project.
Since my project places no constraint on the distribution of the larger work, I do not see
why I should have to change the license in order 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

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

View raw message