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.gard...@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-disc...@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:bay...@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 <lro...@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:ru...@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 <lro...@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:ru...@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 <lro...@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-unsubscr...@apache.org > > For additional commands, e-mail: legal-discuss-h...@apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org > For additional commands, e-mail: legal-discuss-h...@apache.org > _______________________________________________ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
