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 <lro...@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@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 > >
_______________________________________________ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss