www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Eckart de Castilho (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-192) Why is LGPL not allowed
Date Mon, 24 Feb 2014 08:15:21 GMT

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

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. — 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).{quote}
{quote}

It appears to be irrelevant under which circumstances an reverse-engineering 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-engineering clause in their product license - something
that many products indeed do have. So any company trying to protect their investment by a
anti-reverse-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 penetrates 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. 

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

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 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
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 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
(v6.1.5#6160)

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


Mime
View raw message