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 Sat, 22 Feb 2014 01:32:20 GMT

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

Sam Halliday commented on LEGAL-192:
------------------------------------

Joshua, thank you very much for your continuing involvement in this discussion.

In fact, my situation is much more precarious than you assume. The choice faced by the Spark
Apache project is between several libraries: one of which is a (reasonably large) LGPL library
that I maintain, but has contributions from several members and hence I cannot easily re-license.
Undoubtedly, this library is leader in its field (MTJ, a Java linear algebra library with
orders of magnitude better performance than competitors).

The aforementioned library depends on another library that I maintain (netlib-java, released
under an MIT style license) and a further sub project that I wrote under the LGPL (JNILoader,
a trivial library). Due to the intense in-breeding of the subject at hand, one of the other
options for the Apache project (Breeze) also depends on my MIT-licensed project, and its LGPL
dependency.

I have already given permission for the smaller of these projects (JNILoader) to be licensed
under an Apache License, but I have grave concerns regarding the licensing of the larger of
my works given the confusion that I am hearing, regarding the goals of the ASF.

As a researcher and a developer, with a moral concern for the freedom of my work, I choose
the LGPL because it assures me that any changes to my code will be released as LGPL and I
will have access to the source code of those changes. I do not care about changes to the Application.

In contributing to an Apache project (via the vehicle of a third party component) I understand
that my work may be bundled as part of a larger Combined Work than may have non-free(dom)
components. I am ok with that.

However, I am extremely concerned by the implied goals of the ASF from this thread: there
has been talk of "sub licensing", which is not at all apparent from the Software License Criteria,
which I quote:

{quote}
The license must meet the Open Source Definition.
The license must not place restrictions on the distribution of independent works that simply
use or contain the covered work.
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.
{quote}

I am concerned that the ASF would distribute my works under a license that dilutes the LGPL.

I am also extremely confused by the lack of direct questioning to FSF. There has been allusions
to "previous discussions" that I am not party to, and claims that the LGPL implies an optionality
and non-distributility constraint that, frankly, completely disagrees with the FSF's public
statements on the matter.

What I would like to do is to include my (substantial) LGPL library as part of an Apache project,
such that my library is always protected by the LGPL but that the Application (i.e. everything
other than the Library) can be distributed under whatever license Apache (or its customers)
care for.

FSF: is everything I expect within your interpretation of the LGPL and the ASF's policy?

ASF: is everything I expect within your interpretation of the LGPL and the FSF's policy?

If not, please express your understanding of matters such that the other party can comment.


> 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