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 00:13:19 GMT

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

Sam Halliday commented on LEGAL-192:

Thanks Marvin. I have read the threads that Roy linked and I must admit to being more confused
after reading those messages than I was before! :-) The threads are dealing with ambiguities
in a earlier version of the LGPL, e.g. definition of derivative works. The confusion is entirely
my own fault: Roy's keen eye for detail picked out that my link was the LGPL 2.1. I believe
LGPL 3 and the FSF's clarifying statements have addressed the particular issues raised in
those threads.

I am pleased that the reciprocal source code sharing nature of FOSS licenses are not being
debated. Yesterday, I had thought this was the primary concern.

So it is the nature of section 4 that causes all the objections, but not the part about making
source available? But what exactly is "too much" here, compared to the accepted "Category
B" licenses? You must excuse my ignorance of the core ideals that drive the ASF: what may
be trivial to you is news to me. Much of section B is fairly equivalent to a BSD style license,
so it really must be a specific part of section 4 that causes problems. Is it specifically
the part about debugging and the user's ability to modify the library? (The ability to reverse
engineer is moot in Java for technical reasons, since this is not needed to replace a jar
or to debug it)

> 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