www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LEGAL-192) Why is LGPL not allowed
Date Sat, 22 Feb 2014 02:15:29 GMT

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

Chris A. Mattmann edited comment on LEGAL-192 at 2/22/14 2:15 AM:
------------------------------------------------------------------

Dear Sam,

Thank you for your comments. The ones that I wanted to directly reply to were:

{quote}
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.
{quote}
and;
{quote}
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.
{quote}

I understand your concern. The Apache Software Foundation, however; does not share the same
concerns. We do not put explicit requirements on downstream consumers of Apache License, version
2 ("ALv2") software that for example, those software developers who license their components
as LGPL as you have. You stated it yourself. You want changes that are made to your code by
downstream contributors/etc. to be LGPL, and for you to have access to the source code. I
do not speak for all members of the ASF, nor all users of the ALv2 license, but I can tell
you that the ALv2 and the Apache Software Foundation IMO do not have the same concerns of
downstream modifications. That is, we don't explicitly enforce those contributions or modifications
(a) come back to our projects (as source code); and (b) that they are similarly licensed to
our own projects' upstream ALv2 works. 

This is a fundamentally different philosophy that is at the heart of the reciprocity versus
non reciprocity goals and requirements. I'm not commenting on which one is right, but I think
that's the philosophical difference. It's less of a "moral" argument as you state it. I contribute
to tons of open source software and have for years, but I don't share the same belief as you
that it's more "moral" to request those modifications downstream be open source and that they
be licensed similarly. In fact, the big elephant in the room disadvantage of this is that
you will see a lack of contributions from major companies to your open source software product;
contributions that can be tremendous difference makers in the features and capabilities of
our ALv2 products. We have to allow those companies then to be able to take our code; package
it up (even as closed source if need-be) and sell capabilities off of that - so long as there
is a core at the Apache Software Foundation, maintained by a community under the foundations's
policies, that are consistent with our mission.

Your queries trying to get definitive (quotable) statements from "FSF" and "ASF" I think are
heavy handed approaches, and I do not think you will have a ton of success there. I applaud
you for being willing to relicense even some of your software as ALv2. However, if there are
products that you are not willing to relicense away from LGPL, I simply do not see many options
for their successful incorporation *here at the ASF* into Apache upstream products, including
Spark. That doesn't prevent *downstream communities* from combining Apache Spark along with
your own LGPL products, into some collective and/or derivative works; it simply prevents it
from happening here at Apache b/c one of our foundation's goals is to not provide "surprises"
for our downstream customers and users. As Roy is stating (I believe -- Roy knows exactly
what he is stating and this simply my interpretation of it, and I would honestly take heed
of what he is saying since he has been around for a lot longer than many of us have in OSS
land), our foundation's *policy* is that we don't include LGPL components in our Apache produced
software, *here at the ASF*. If we did, we would be creating *surprises* for our users who
expect software that conforms to our legal/resolved policies and that fall under the ALv2's
permissiveness, and those users include individual, Joe-developer-types; as well as large
companies willing to pay their employees time' to work on ASF stewarded projects.


was (Author: chrismattmann):
Dear Sam,

Thank you for your comments. The ones that I wanted to directly reply to were:

{quote}
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.
{quote}
and;
{quote}
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.
{quote}

I understand your concern. The Apache Software Foundation, however; does not share the same
concerns. We do not put explicit requirements on downstream consumers of Apache License, version
2 ("ALv2") software that for example, those software developers who license their components
as LGPL as you have. You stated it yourself. You want changes that are made to your code by
downstream contributors/etc. to be LGPL, and for you to have access to the source code. I
do not speak for all members of the ASF, nor all users of the ALv2 license, but I can tell
you that the ALv2 and the Apache Software Foundation IMO do not have the same concerns of
downstream modifications. That is, we don't explicitly enforce those contributions or modifications
(a) come back to our projects (as source code); and (b) that they are similarly licensed to
our own projects' upstream ALv2 works. 

This is a fundamentally different philosophy that is at the heart of the reciprocity versus
non reciprocity goals and requirements. I'm not commenting on which one is right, but I think
that's the philosophical difference. It's less of a "moral" argument as you state it. I contribute
to tons of open source software and have for years, but I don't share the same belief as you
that it's more "moral" to request those modifications downstream be open source and that they
be licensed similarly. In fact, the big elephant in the room disadvantage of this is that
you will see a lack of contributions from major companies to your open source software product;
contributions that can be tremendous difference makers in the features and capabilities of
our ALv2 products. We have to allow those companies then to be able to take our code; package
it up (even as closed source if need-be) and sell capabilities off of that - so long as there
is a core at the Apache Software Foundation, maintained by a community under the foundations's
policies, that are consistent with our mission.

Your queries trying to get definitive (quotable) statements from "FSF" and "ASF" I think are
heavy handed approaches, and I do not think you will have a ton of success there. I applaud
you for being willing to relicense even some of your software as ALv2. However, if there are
products that you are not willing to relicense away from LGPL, I simply do not see many options
for their successful incorporation *here at the ASF* into Apache upstream products, including
Spark. That doesn't prevent *downstream communities* from combining Apache Spark^TM, along
with your own LGPL products, into some collective and/or derivative works; it simply prevents
it from happening here at Apache b/c one of our foundation's goals is to not provide "surprises"
for our downstream customers and users. As Roy is stating (I believe -- Roy knows exactly
what he is stating and this simply my interpretation of it, and I would honestly take heed
of what he is saying since he has been around for a lot longer than many of us have in OSS
land), our foundation's *policy* is that we don't include LGPL components in our Apache produced
software, *here at the ASF*. If we did, we would be creating *surprises* for our users who
expect software that conforms to our legal/resolved policies and that fall under the ALv2's
permissiveness, and those users include individual, Joe-developer-types; as well as large
companies willing to pay their employees time' to work on ASF stewarded projects.

> 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