www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Rosen" <lro...@rosenlaw.com>
Subject RE: Proposal: Apache Third Party License Policy
Date Tue, 26 May 2015 16:08:02 GMT
Jim Jagielski wrote:
> Again, there is a difference between, maybe, what we are allowed to do and what we *should*
do. OSI *might* be able to determine what we legally can do (though I doubt that), but they
have not a clue (no disrespect) what our *policy* is as well as the background and rationale
behind that policy.

I also have no clue what Apache *policy* really is. The current policy is a maze of exceptions
and random licensing opinions by amateurs. 

Perhaps OSI or others are willing to comment?

/Larry

-----Original Message-----
From: Jim Jagielski [mailto:jim@jaguNET.com] 
Sent: Tuesday, May 26, 2015 4:42 AM
To: legal-discuss@apache.org
Cc: lrosen@rosenlaw.com; License Discuss
Subject: Re: Proposal: Apache Third Party License Policy

FWIW, I agree.

Again, there is a difference between, maybe, what we are allowed to do and what we *should*
do. OSI *might* be able to determine what we legally can do (though I doubt that), but they
have not a clue (no disrespect) what our *policy* is as well as the background and rationale
behind that policy.

Letter vs. intent.

> On May 26, 2015, at 4:14 AM, Ross Gardler (MS OPEN TECH) <Ross.Gardler@microsoft.com>
wrote:
> 
> Once again this ignores the community motivations for the policy. The OSI is not qualified
to make judgments on ASF cultural mission.
> 
> Sent from my Windows Phone
> From: Lawrence Rosen
> Sent: ‎5/‎25/‎2015 11:54 AM
> To: legal-discuss@apache.org
> Cc: 'License Discuss'; Lawrence Rosen
> Subject: RE: Proposal: Apache Third Party License Policy
> 
> 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@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@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@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@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 <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.  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 <lrosen@rosenlaw.com> 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
> 


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


Mime
View raw message