[License-discuss] Proposal: Apache Third Party License Policy

Henri Yandell bayard at apache.org
Mon May 25 19:24:11 UTC 2015


I don't see how you are going to do that unless the OSI are going to
maintain complex lists.

If this is "the OSI are launching a license compatibility service", then
there would be something to discuss at Apache. As it is, your proposal is
becoming well trod ground around moving B(inary-only) list licenses to
A(ttribution).

Hen

On Mon, May 25, 2015 at 11:51 AM, Lawrence Rosen <lrosen at rosenlaw.com>
wrote:

> Hen,
>
>
>
> An important part of the proposed Apache Third Party License Policy is
> that we finally leave the sad domain of FOSS license compatibility
> determination to our friends and experts at OSI.
>
>
>
> If we have a question about whether a specific FOSS license "infects"
> Apache code, ask OSI at license-discuss at opensource.org. That's not ASF's
> expertise. Our PMCs and certainly our board of directors are not qualified
> to maintain complex "A, B and X" lists of FOSS licenses and exceptions.
>
>
>
> And so in open source, different organizations can play their own
> important roles in our ecosystem. All this without turning one FOSS
> developer against another FOSS developer here at Apache merely because of
> their choice of wonderful FOSS license.
>
>
>
> /Larry
>
>
>
>
>
> *From:* Henri Yandell [mailto:bayard at apache.org]
> *Sent:* Monday, May 25, 2015 11:12 AM
> *To:* ASF Legal Discuss; Lawrence Rosen
>
> *Subject:* Re: Proposal: Apache Third Party License Policy
>
>
>
>
>
> Your original proposal was (quoting the heart of it; for any readers not
> familiar refer back to the whole email):
>
> Proposal: "Apache projects may accept contributions under ANY
> OSI-approved open source license. Such software may now be included in
> Apache aggregations that, as described above, will be licensed to the
> public under *Apache License 2.0*."
>
>
>
> An exception has evolved through the course of these threads, namely that
> GPL/AGPL versions are an exception to that and not covered. That also means
> a policy cannot approve 'ANY' as it's unknown what the next licence on the
> list would be.
>
> At this point the conversation is:
>
> a) Removal of particular licenses on the 'cannot be used' list that are on
> the OSI list. I think that's LGPL, QPL and Sleepycat licences. I don't
> think either of the latter are used on software today, so I don't see a
> need to do that. There are other licences on the OSI list that we don't
> have covered, so it's possible there are some we would consider on the
> 'cannot be used' list. This should become a thread on moving LGPL licences
> to either the 'weak copyleft -> binary only' or 'can be used' list. The
> former makes more sense.
>
> b) Moving the 'weak copyleft -> binary only' licences to the 'can be used'
> list. That's a worthwhile proposal, but one that should take a pause and
> restart. Starting with CDDL/EPL/MPL would make sense as the most popular on
> that list (possibly individually). A lot of our use of those licences is
> binary, so having that position has not been as impactful as might be
> imagined at first.
>
>
>
> Hen
>
>
>
> On Mon, May 25, 2015 at 8:23 AM, Lawrence Rosen <lrosen at rosenlaw.com>
> wrote:
>
> Sam Ruby wrote:
> > You may not have been aware that it is an ASF problem to worry about
> whether downstream distributors can make derivative works -- Free and
> proprietary alike -- of our projects, but it is true.  As such, we care
> very much about the kind of dependencies a project takes on, and the
> license of code that we bundle.
>
> Sam, of course I'm aware of that. That is precisely why I am requesting
> that you change that antiquated policy.
>
> Please remember, EVERYONE can make derivative works (free and proprietary
> alike) of Apache projects even if that software includes EPL and MPL works.
> What they can't do is to refuse to distribute derivative works of EPL and
> MPL components under their original licenses. That is a reciprocal
> requirement. But it doesn't prevent derivative works.
>
> > EPL and MPL fall someplace in between.
>
> In between what and what?
>
> I've been challenged repeated here because certain GPL folks don't want
> their license interpreted this way. So if Apache changes its obsolete
> policy for every FOSS license except the GPL, I'll consider that a
> significant accomplishment. I'll wait impatiently for the lawyers who are
> trying to create a licensing exception for those GPL licensors that DO want
> their works incorporated into Apache projects.
>
> > And with that, I believe we have covered why the three categories in the
> third partly licensing policy can not be collapsed into one category.
>
> No we haven't settled that at all. :-)
>
> /.Larry
>
>
> -----Original Message-----
> From: Sam Ruby [mailto:rubys at intertwingly.net]
> Sent: Monday, May 25, 2015 4:54 AM
> To: Legal Discuss; Lawrence Rosen
>
> Subject: Re: Proposal: Apache Third Party License Policy
>
> And with that, I believe we have covered why the three categories in the
> third partly licensing policy can not be collapsed into one category.
>
> > I wasn't aware that it is an Apache problem to worry about whether
> downstream distributors want to make proprietary derivative works of EPL
> components. They can always talk to the Eclipse Foundation about that.
>
> You may not have been aware that it is an ASF problem to worry about
> whether downstream distributors can make derivative works -- Free and
> proprietary alike -- of our projects, but it is true.  As such, we care
> very much about the kind of dependencies a project takes on, and the
> license of code that we bundle.
>
> While you may disagree, it is widely believed that the GPL does not meet
> your personal definition of Free software.  While others use different
> terms, the conclusion is creating software that makes direct use of GPL
> software (for example, in a non-optional and non-pluggable
> manner) would make creating proprietary derivative works of our projects
> problematic.
>
> As you cite, there are no such problems with licenses like BSD (at least
> the newer versions) or MIT licenses.
>
> EPL and MPL fall someplace in between.
>
> - Sam Ruby
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20150525/e7dcb437/attachment.html>


More information about the License-discuss mailing list