Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8196117CEF for ; Mon, 25 May 2015 18:11:59 +0000 (UTC) Received: (qmail 52626 invoked by uid 500); 25 May 2015 18:11:59 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 52416 invoked by uid 500); 25 May 2015 18:11:59 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 52406 invoked by uid 99); 25 May 2015 18:11:59 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 May 2015 18:11:59 +0000 Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id C44941A046D for ; Mon, 25 May 2015 18:11:57 +0000 (UTC) Received: by qgfa63 with SMTP id a63so49035296qgf.0 for ; Mon, 25 May 2015 11:11:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.40.92 with SMTP id o89mr48047236qkh.74.1432577516931; Mon, 25 May 2015 11:11:56 -0700 (PDT) Received: by 10.96.186.130 with HTTP; Mon, 25 May 2015 11:11:56 -0700 (PDT) In-Reply-To: <199701d096fe$c69d1fb0$53d75f10$@rosenlaw.com> References: <18c601d09678$9df86cd0$d9e94670$@rosenlaw.com> <199701d096fe$c69d1fb0$53d75f10$@rosenlaw.com> Date: Mon, 25 May 2015 11:11:56 -0700 Message-ID: Subject: Re: Proposal: Apache Third Party License Policy From: Henri Yandell To: ASF Legal Discuss , Lawrence Rosen Content-Type: multipart/alternative; boundary=001a113c11d4029df90516ebf2a6 --001a113c11d4029df90516ebf2a6 Content-Type: text/plain; charset=UTF-8 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 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@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 > > On Sun, May 24, 2015 at 7:23 PM, Lawrence Rosen > wrote: > > [I cleaned up the subject line again] > > > > Sam Ruby wrote: > >> Mike responded to you, indicating that modifications made to code made > available under the EPL must be released under the EPL. The EPL is > certainly not a proprietary (closed source) license. > > > > You're right, it isn't. Neither is Apache License 2.0. They are both > *FOSS* licenses. > > > > Works that are released under a FOSS license remain under that FOSS > license. Always. Unless the author changes it for future distributions. > > > > If someone convinced you that Apache License 2.0 software ever becomes > proprietary, they're tricking you. > > > > Derivative works -- that's another matter. Depends on whether the > original work was released under a reciprocal license. In that respect > only, ALv2 and EPL are different. ALv2 and EPL software are both FOSS. > Always. Derivative works: Maybe not. > > > > But that has nothing to do with being proprietary (closed source) > licenses for the FOSS software itself. Never! OSI would never approve such > a license. > > > > 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. > > > > As for ALv2 components that our projects incorporate, like BSD or MIT > components, anyone can already create proprietary derivative works and > we're pleased to continue to let them do so without reciprocation. > > > > /Larry > > > > -----Original Message----- > > From: Sam Ruby [mailto:rubys@intertwingly.net] > > Sent: Sunday, May 24, 2015 3:45 PM > > To: Legal Discuss; Lawrence Rosen > > Subject: Re: [License-discuss] [FTF-Legal] Proposal: Apache Third > > Party License Policy > > > > On Sun, May 24, 2015 at 3:59 PM, Lawrence Rosen > wrote: > >> > >> AFAIK, *all* FOSS software can be used in proprietary (closed source) > >> programs. See Freedom 1, 2 and 5 in my earlier email. By which I mean > "uses" > >> and "copies" and "combinations." (Reciprocation may be necessary only > >> for certain "derivative works" under Freedom 3.) > > > > Again, it is my experience that people who explicitly chose the GPL do > so because the code can NOT be used in proprietary (closed source) > programs. See: > > > > http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem > > > > Note: some chose to dual license the code under a non-FOSS license to > enable inclusion in proprietary (closed source) programs. > > > > I believe that this may be related to the disagreement as to whether or > not GPL meets your personal definition of Free software. Of course the FSF > has it's own definition of Free software, and the GPL meets the FSF's > definition of that term. > > > >> *No exceptions are > >> needed* for the EPL, unless I misunderstood Mike Milinkovich. > > > > Mike responded to you, indicating that modifications made to code made > available under the EPL must be released under the EPL. The EPL is > certainly not a proprietary (closed source) license. > > > > - Sam Ruby > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > > For additional commands, e-mail: legal-discuss-help@apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > For additional commands, e-mail: legal-discuss-help@apache.org > > --001a113c11d4029df90516ebf2a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Your original proposal was (quoting the hea= rt of it; for any readers not familiar refer back to the whole email):
<= br>Proposal: "Apache projec= ts may accept=20 contributions under ANY OSI-approved open source license. Such software=20 may now be included in Apache aggregations that, as described above,=20 will be licensed to the public under Apache License 2.0."

An exception has evolved through the course of these threads, namely t= hat GPL/AGPL versions are an exception to that and not covered. That also m= eans a policy cannot approve 'ANY' as it's unknown what the nex= t licence on the list would be.

At = this point the conversation is:

a) = Removal of particular licenses on the 'cannot be used' list that ar= e on the OSI list. I think that's LGPL, QPL and Sleepycat licences. I d= on't think either of the latter are used on software today, so I don= 9;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 consi= der on the 'cannot be used' list. This should become a thread on mo= ving 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 p= roposal, but one that should take a pause and restart. Starting with CDDL/E= PL/MPL would make sense as the most popular on that list (possibly individu= ally). A lot of our use of those licences is binary, so having that positio= n has not been as impactful as might be imagined at first.

Hen

On Mon, May 25, 2015 = at 8:23 AM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:
Sam Ruby wrote: > You may not have been aware that it is an ASF problem to worry about w= hether downstream distributors can make derivative works -- Free and propri= etary alike -- of our projects, but it is true.=C2=A0 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 req= uesting that you change that antiquated policy.

Please remember, EVERYONE can make derivative works (free and proprietary a= like) 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 a= nd MPL components under their original licenses. That is a reciprocal requi= rement. 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 sign= ificant accomplishment. I'll wait impatiently for the lawyers who are t= rying 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 t= he 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@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 th= ird 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 c= omponents. 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 whethe= r downstream distributors can make derivative works -- Free and proprietary= alike -- of our projects, but it is true.=C2=A0 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 yo= ur personal definition of Free software.=C2=A0 While others use different t= erms, the conclusion is creating software that makes direct use of GPL soft= ware (for example, in a non-optional and non-pluggable
manner) would make creating proprietary derivative works of our projects pr= oblematic.

As you cite, there are no such problems with licenses like BSD (at least th= e newer versions) or MIT licenses.

EPL and MPL fall someplace in between.

- Sam Ruby

On Sun, May 24, 2015 at 7:23 PM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:
> [I cleaned up the subject line again]
>
> Sam Ruby wrote:
>> Mike responded to you, indicating that modifications made to code = made available under the EPL must be released under the EPL.=C2=A0 The EPL = is certainly not a proprietary (closed source) license.
>
> You're right, it isn't. Neither is Apache License 2.0. They ar= e both *FOSS* licenses.
>
> Works that are released under a FOSS license remain under that FOSS li= cense. Always. Unless the author changes it for future distributions.
>
> If someone convinced you that Apache License 2.0 software ever becomes= proprietary, they're tricking you.
>
> Derivative works -- that's another matter. Depends on whether the = original work was released under a reciprocal license. In that respect only= , ALv2 and EPL are different. ALv2 and EPL software are both FOSS. Always. = Derivative works: Maybe not.
>
> But that has nothing to do with being proprietary (closed source) lice= nses for the FOSS software itself. Never!=C2=A0 OSI would never approve suc= h a license.
>
> I wasn't aware that it is an Apache problem to worry about whether= downstream distributors want to make proprietary derivative works of EPL c= omponents. They can always talk to the Eclipse Foundation about that.
>
> As for ALv2 components that our projects incorporate, like BSD or MIT = components, anyone can already create proprietary derivative works and we&#= 39;re pleased to continue to let them do so without reciprocation.
>
> /Larry
>
> -----Original Message-----
> From: Sam Ruby [mailto:rubys@intertwingly.net]
> Sent: Sunday, May 24, 2015 3:45 PM
> To: Legal Discuss; Lawrence Rosen
> Subject: Re: [License-discuss] [FTF-Legal] Proposal: Apache Third
> Party License Policy
>
> On Sun, May 24, 2015 at 3:59 PM, Lawrence Rosen <lrosen@rosenlaw.com> wrote: >>
>> AFAIK, *all* FOSS software can be used in proprietary (closed sour= ce)
>> programs. See Freedom 1, 2 and 5 in my earlier email. By which I m= ean "uses"
>> and "copies" and "combinations." (Reciprocatio= n may be necessary only
>> for certain "derivative works" under Freedom 3.)
>
> Again, it is my experience that people who explicitly chose the GPL do= so because the code can NOT be used in proprietary (closed source) program= s.=C2=A0 See:
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLInPropr= ietarySystem
>
> Note: some chose to dual license the code under a non-FOSS license to = enable inclusion in proprietary (closed source) programs.
>
> I believe that this may be related to the disagreement as to whether o= r not GPL meets your personal definition of Free software.=C2=A0 Of course = the FSF has it's own definition of Free software, and the GPL meets the= FSF's definition of that term.
>
>> *No exceptions are
>> needed* for the EPL, unless I misunderstood Mike Milinkovich.
>
> Mike responded to you, indicating that modifications made to code made= available under the EPL must be released under the EPL.=C2=A0 The EPL is c= ertainly not a proprietary (closed source) license.
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------<= br> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>


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


--001a113c11d4029df90516ebf2a6--