www-legal-discuss mailing list archives

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

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

Marvin Humphrey commented on LEGAL-192:

The ASF's policy on LGPL ensures that downstream consumers of Apache products
will be able to incorporate them into proprietary binary products without
having to evaluate whether such binaries satisfy LGPL requirements for
"reverse engineering":

[...] provided that the terms permit modification of the work for the customer's own use and
reverse engineering for debugging such modifications. 

It's true that the ASF's source distributions will always fulfill such LGPL
requirements, but commercial downstream products incorporating both the ASF
product and a theoretical LGPL dependency may not.

Disallowing mandatory LGPL dependencies makes Apache more
"commercial-friendly" because our users know they will always be able to
consume our products without being forced by an LGPL dependency to satisfy its
provisions.  If we change that policy, downstream consumers with "no LGPL"
policies of their own will no longer be able to know with confidence which
"Apache" products they can use.

I don't see how the FSF can offer any "clarifications" or policy changes which
could influence this ASF policy.  The LGPL's provisions are what they are -- a
proprietary binary which incorporates an LGPL dependency must support limited
reverse engineering.

> 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