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

[Lawrence Rosen]

Apache Legal JIRA-218 asked:
>> My question is about whether "Eclipse Public License -v 1.0" 
>> is compatible with our Apache License 2.0.
>> I couldn't find an answer on https://www.apache.org/legal/resolved.html. 

Larry Rosen suggested: 
> The obvious answer we could state in a short FAQ: "Of course. All FOSS 
> licenses 
> are compatible for aggregations.”

Ralph Goers then responded:
> The fundamental problem here is that it seems that most of the rest of us
> disagree completely with this statement. I know I do. Yes, I am not an 
> attorney,
> but I don’t need to be to express that the many conversations I have had
> with attorneys for the companies I have worked for and that their (possibly
> incorrect) opinions are the reason why we would prefer to be overly 
> conservative.

Thank you Ralph!

That is EXACTLY the reason why we moved this conversation to 
legal-disc...@apache.org, which is a public email list that anyone can read and 
copy. I'm now also copying license-discuss@opensource.org and the European 
Legal Network .  I'm hoping for responses from 
attorneys. I'm fully prepared to ride my horse into the sunset if other 
attorneys tell me I'm inventing copyright law.

I will lend my horses to others to ride into the sunset if (PLEASE!) attorneys 
say something supportive.

/Larry


-Original Message-
From: Ralph Goers [mailto:ralph.go...@dslextreme.com] 
Sent: Wednesday, May 20, 2015 1:18 PM
To: Legal Discuss; Lawrence Rosen
Subject: Re: Proposal: Apache Third Party License Policy



___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Ben Tilly]

The first item in the Open Source Definition seems to address this.

1. Free Redistribution

The license shall not restrict any party from selling or giving away
the software as a component of an aggregate software distribution
containing programs from several different sources. The license shall
not require a royalty or other fee for such sale.

Therefore you would think that all open source software should be OK
to distribute in an aggregation.

But not all aggregations are created equal.  Licenses in the GPL
family distinguish between things that have simply been aggregated
together, versus things that are meant to be used as part of a
combined work.  Therefore if you, for instance, shipped an Apache 1.1
licensed program from one source together with a GPLed library from
another source that the program won't run without, then you're in
violation of the GPL.

So if you're aggregating open source programs that do different things
and do not rely on each other, then open source software licenses
should be fine.  But there are some potential gotchas.

On Wed, May 20, 2015 at 1:40 PM, Lawrence Rosen  wrote:
> Apache Legal JIRA-218 asked:
>>> My question is about whether "Eclipse Public License -v 1.0"
>>> is compatible with our Apache License 2.0.
>>> I couldn't find an answer on https://www.apache.org/legal/resolved.html.
>
> Larry Rosen suggested:
>> The obvious answer we could state in a short FAQ: "Of course. All FOSS 
>> licenses
>> are compatible for aggregations.”
>
> Ralph Goers then responded:
>> The fundamental problem here is that it seems that most of the rest of us
>> disagree completely with this statement. I know I do. Yes, I am not an 
>> attorney,
>> but I don’t need to be to express that the many conversations I have had
>> with attorneys for the companies I have worked for and that their (possibly
>> incorrect) opinions are the reason why we would prefer to be overly 
>> conservative.
>
> Thank you Ralph!
>
> That is EXACTLY the reason why we moved this conversation to 
> legal-disc...@apache.org, which is a public email list that anyone can read 
> and copy. I'm now also copying license-discuss@opensource.org and the 
> European Legal Network .  I'm hoping for responses 
> from attorneys. I'm fully prepared to ride my horse into the sunset if other 
> attorneys tell me I'm inventing copyright law.
>
> I will lend my horses to others to ride into the sunset if (PLEASE!) 
> attorneys say something supportive.
>
> /Larry
>
>
> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Wednesday, May 20, 2015 1:18 PM
> To: Legal Discuss; Lawrence Rosen
> Subject: Re: Proposal: Apache Third Party License Policy
> 
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Ralph Goers]

Larry,  you are welcome.  However, the other link you forwarded [1] has a 
section named "Can I write proprietary code that links to a shared library 
that's open source?”.  It basically answers the very question you are asking - 
namely, that there are cases where you cannot take code written under the 
Apache License, combine it with code licensed under the GPL (regardless of 
whether the code is explicitly included or only dynamically linked via a Java 
JAR file) and then distribute that under a proprietary license. Furthermore, 
links such as this [2] by the FSF explicitly call out what their position is on 
how works are combined even when using dynamic linking - once bound together 
the whole aggregation needs to abide by the terms of the license, not just the 
included work.

To me, the fundamental purpose of the Apache license is to allow anyone to do 
whatever they want with the software, including modifying it and including it 
in their proprietary product with no requirements to do so.  If an Apache 
project were to directly or indirectly require software that uses a license 
that requires anyone to meet certain requirements in order to create and 
distribute their software under whatever license they choose that project would 
not be meeting the goals of the ASF.

Ralph


[1] - http://opensource.org/faq#linking-proprietary-code 

[2] - http://www.gnu.org/licenses/lgpl-java.html 

> On May 20, 2015, at 1:40 PM, Lawrence Rosen  wrote:
> 
> Apache Legal JIRA-218 asked:
>>> My question is about whether "Eclipse Public License -v 1.0" 
>>> is compatible with our Apache License 2.0.
>>> I couldn't find an answer on https://www.apache.org/legal/resolved.html. 
> 
> Larry Rosen suggested: 
>> The obvious answer we could state in a short FAQ: "Of course. All FOSS 
>> licenses 
>> are compatible for aggregations.”
> 
> Ralph Goers then responded:
>> The fundamental problem here is that it seems that most of the rest of us
>> disagree completely with this statement. I know I do. Yes, I am not an 
>> attorney,
>> but I don’t need to be to express that the many conversations I have had
>> with attorneys for the companies I have worked for and that their (possibly
>> incorrect) opinions are the reason why we would prefer to be overly 
>> conservative.
> 
> Thank you Ralph!
> 
> That is EXACTLY the reason why we moved this conversation to 
> legal-disc...@apache.org, which is a public email list that anyone can read 
> and copy. I'm now also copying license-discuss@opensource.org and the 
> European Legal Network .  I'm hoping for responses 
> from attorneys. I'm fully prepared to ride my horse into the sunset if other 
> attorneys tell me I'm inventing copyright law.
> 
> I will lend my horses to others to ride into the sunset if (PLEASE!) 
> attorneys say something supportive.
> 
> /Larry
> 
> 
> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] 
> Sent: Wednesday, May 20, 2015 1:18 PM
> To: Legal Discuss; Lawrence Rosen
> Subject: Re: Proposal: Apache Third Party License Policy
> 
> 
> 
> 
> -
> 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

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

[Lawrence Rosen]

Ben Tilly quoted OSD #1 [Free Redistribution]
"The license shall not restrict any party from selling or giving away the 
software as a component of an aggregate software distribution containing 
programs from several different sources. The license shall not require a 
royalty or other fee for such sale."

He then added this: "But not all aggregations are created equal." And now some 
at Apache are treating Ben Tilly's added statement as important for analysis of 
aggregations containing FOSS software.

How do "unequal aggregations" affect OSD #1?

I'm expressly NOT speaking of derivative works.! I used the word "aggregation" 
on purpose.

/Larry


-Original Message-
From: Ben Tilly [mailto:bti...@gmail.com] 
Sent: Wednesday, May 20, 2015 2:07 PM
To: Lawrence Rosen; License Discuss
Cc: Legal Discuss; European Legal Network
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

The first item in the Open Source Definition seems to address this.

1. Free Redistribution

The license shall not restrict any party from selling or giving away the 
software as a component of an aggregate software distribution containing 
programs from several different sources. The license shall not require a 
royalty or other fee for such sale.

Therefore you would think that all open source software should be OK to 
distribute in an aggregation.

But not all aggregations are created equal.  Licenses in the GPL family 
distinguish between things that have simply been aggregated together, versus 
things that are meant to be used as part of a combined work.  Therefore if you, 
for instance, shipped an Apache 1.1 licensed program from one source together 
with a GPLed library from another source that the program won't run without, 
then you're in violation of the GPL.

So if you're aggregating open source programs that do different things and do 
not rely on each other, then open source software licenses should be fine.  But 
there are some potential gotchas.

On Wed, May 20, 2015 at 1:40 PM, Lawrence Rosen  wrote:
> Apache Legal JIRA-218 asked:
>>> My question is about whether "Eclipse Public License -v 1.0"
>>> is compatible with our Apache License 2.0.
>>> I couldn't find an answer on https://www.apache.org/legal/resolved.html.
>
> Larry Rosen suggested:
>> The obvious answer we could state in a short FAQ: "Of course. All 
>> FOSS licenses are compatible for aggregations.”
>
> Ralph Goers then responded:
>> The fundamental problem here is that it seems that most of the rest 
>> of us disagree completely with this statement. I know I do. Yes, I am 
>> not an attorney, but I don’t need to be to express that the many 
>> conversations I have had with attorneys for the companies I have 
>> worked for and that their (possibly
>> incorrect) opinions are the reason why we would prefer to be overly 
>> conservative.
>
> Thank you Ralph!
>
> That is EXACTLY the reason why we moved this conversation to 
> legal-disc...@apache.org, which is a public email list that anyone can read 
> and copy. I'm now also copying license-discuss@opensource.org and the 
> European Legal Network .  I'm hoping for responses 
> from attorneys. I'm fully prepared to ride my horse into the sunset if other 
> attorneys tell me I'm inventing copyright law.
>
> I will lend my horses to others to ride into the sunset if (PLEASE!) 
> attorneys say something supportive.
>
> /Larry
>
>
> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Wednesday, May 20, 2015 1:18 PM
> To: Legal Discuss; Lawrence Rosen
> Subject: Re: Proposal: Apache Third Party License Policy 
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Ben Tilly]

To be fair, the responses that I have seen involving Apache involved
independent analyses that came to the same conclusion that I did, and
did not reference my comment.  Furthermore my email there bounced
(which is why I just took them off the CC list), so they probably did
not see it.

Now on to the OSD.  The OSD was unfortunately not written by a lawyer,
and can be parsed ambiguously in many ways.  So you often have to go
back to intent to figure out which way it should be parsed.

My understanding is that the original version of item #1 is that third
parties are not restricted from giving away or selling the software
without paying royalties or any fee.  The awkward wording around
aggregation was added so that
http://opensource.org/licenses/artistic-license-1.0 could be declared
open source despite section 5 which only allowed it to be sold as part
of an aggregation.  Furthermore there is no question that Bruce Perens
was aware of section 2 of http://www.gnu.org/licenses/gpl-2.0.html and
intended the GPL v2 to be open source.

Given that, here is how I read, "The license shall not restrict any
party from selling or giving away the software as a component of an
aggregate software distribution containing programs from several
different sources. The license shall not require a royalty or other
fee for such sale."

I read it as saying that when you distribute, you are free to charge
or not as you wish, and you owe no royalty or fee regardless of what
you choose.  However there is a distinction between "AN aggregate" and
"ANY aggregate".  Some aggregates are not allowed to be distributed.
Another similar hair to split is that the manner in which it is sold
can matter.  For example it is OK to sell it in a box, but is not
necessarily OK to put the name of the author of the software on said
box.  (A number of open source licenses have advertising
restrictions.)

That said, I completely agree that it is possible to parse that
section in a way that the *GPL v* family of licenses will fail.  But
this is not the only way in with the OSD fails to be a legal document.

On Thu, May 21, 2015 at 8:51 AM, Lawrence Rosen  wrote:
> Ben Tilly quoted OSD #1 [Free Redistribution]
> "The license shall not restrict any party from selling or giving away the 
> software as a component of an aggregate software distribution containing 
> programs from several different sources. The license shall not require a 
> royalty or other fee for such sale."
>
> He then added this: "But not all aggregations are created equal." And now 
> some at Apache are treating Ben Tilly's added statement as important for 
> analysis of aggregations containing FOSS software.
>
> How do "unequal aggregations" affect OSD #1?
>
> I'm expressly NOT speaking of derivative works.! I used the word 
> "aggregation" on purpose.
>
> /Larry
>
>
> -Original Message-
> From: Ben Tilly [mailto:bti...@gmail.com]
> Sent: Wednesday, May 20, 2015 2:07 PM
> To: Lawrence Rosen; License Discuss
> Cc: Legal Discuss; European Legal Network
> Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy
>
> The first item in the Open Source Definition seems to address this.
>
> 1. Free Redistribution
>
> The license shall not restrict any party from selling or giving away the 
> software as a component of an aggregate software distribution containing 
> programs from several different sources. The license shall not require a 
> royalty or other fee for such sale.
>
> Therefore you would think that all open source software should be OK to 
> distribute in an aggregation.
>
> But not all aggregations are created equal.  Licenses in the GPL family 
> distinguish between things that have simply been aggregated together, versus 
> things that are meant to be used as part of a combined work.  Therefore if 
> you, for instance, shipped an Apache 1.1 licensed program from one source 
> together with a GPLed library from another source that the program won't run 
> without, then you're in violation of the GPL.
>
> So if you're aggregating open source programs that do different things and do 
> not rely on each other, then open source software licenses should be fine.  
> But there are some potential gotchas.
>
> On Wed, May 20, 2015 at 1:40 PM, Lawrence Rosen  wrote:
>> Apache Legal JIRA-218 asked:
>>>> My question is about whether "Eclipse Public License -v 1.0"
>>>> is compatible with our Apache License 2.0.
>>>> I couldn't find an answer on https://www.apache.org/legal/resolved.html.
>>
>> Larry Rosen suggested:
>>> The obvious answer we could state in a short FAQ: "Of course. All
>>> FOSS licenses are compatible for aggregations.

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

[Lawrence Rosen]

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 mailto: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 depen

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

[Lawrence Rosen]

Hen, the OSI task of license analysis in this context is trivial. ALL FOSS 
license are compatible with ALv2 for aggregations.

 

But today is a US holiday, so let's give some OSI board members an opportunity 
to comment.

 

/Larry

 

 

From: Henri Yandell [mailto:bay...@apache.org] 
Sent: Monday, May 25, 2015 12:24 PM
To: Lawrence Rosen; license-discuss@opensource.org
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

 

 

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 mailto: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 
<mailto: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 <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 mailto: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 

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

[Henri Yandell]

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 
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 
> 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

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

[Lawrence Rosen]

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:j...@jagunet.com] 
Sent: Tuesday, May 26, 2015 4:42 AM
To: legal-disc...@apache.org
Cc: lro...@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) 
>  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  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 r

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

[Ross Gardler (MS OPEN TECH)]

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 
mailto: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'

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

[Jim Jagielski]

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) 
>  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  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. :-)
> 
> /.L

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

[William A Rowe Jr]

On May 25, 2015 1:54 PM, "Lawrence Rosen"  wrote:
> 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.

As you would readily acknowledge, OSI are not 'our' lawyers.  And further,
they are generally not speaking as the license authors' lawyers, either.

Their work informs and advises the ASF and many other producers and
consumers of OSS.  That alone is sufficient.

> 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.

As stated earlier in the thread, where the license appears to be on the B
or X schedule of licenses.  Asking the author is always the right call.
Most especially when the author forks a license.  When we and the author
understand the author's desires, they are often very willing to dual or
re-license to accomplish their objective.

If their objectives collide with ours, our works won't be based on theirs.
If there is a way to offer a package which combines functional ASF works
with functional 3rd party reciprocally licensed works, this should be
explored, but not as ASF "releases".

> 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.

I haven't seen this occur, as the license policy in oral and written
tradition has been passed down since the foundation's creation, and
familiarity with ASF license restriction policies is part of a project's
admission through the incubator.

There are places to originate both weak and strong copy-left works, this is
not one of those places.

Your comments suggest the software authors are ignorant of licensing law,
and should leave it entirely up to the lawyers; that in the perfect world
there would be only 1 license needed for OSS efforts.  That there are a
number of legitimately differing licenses reflects that differences of
intent do exist, and pontificating that all OSI licenses are one does not
make it so.
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Radcliffe, Mark]

I agree. Even though I am outside GC for OSI, I think that these issues are 
critical to ASF and should remain a decision made by ASF.

-Original Message-
From: license-discuss-boun...@opensource.org 
[mailto:license-discuss-boun...@opensource.org] On Behalf Of Jim Jagielski
Sent: Tuesday, May 26, 2015 4:42 AM
To: legal-disc...@apache.org
Cc: License Discuss
Subject: Re: [License-discuss] 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) 
>  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  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 

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

[Jim Jagielski]

(dropping members@)

As Larry noted, the ASF board makes a distinction between what is
legally possible, and what our policy is. The rationale behind
that policy can easily be found. Larry's proposal would be a major
policy change for the ASF and, we (the ASF) are confident, would
cause major discussion and disruption and confusion to our end-users,
who now, for valid reasons, consider ASF code as "safe" and "brain-dead
easy" to consume and leverage.

> On May 26, 2015, at 10:16 PM, Lawrence Rosen  wrote:
> 
> [This has been a hellishly long thread on private Apache lists before the 
> board cut off discussion on revised policies. Below was the short start of it 
> I submitted over two weeks ago. Apache board members don't want to revise 
> current policy. Many Apache members don't want it. Still, it is a serious 
> proposal to bring some more freedom and cooperation to open source. Please 
> treat this as a political document for license-discuss@. /Larry]
>  
> **
>  
> DRAFT: Apache Third Party License Policy (May 10, 2015)
>  
> Apache projects have long been universal donors to many other software 
> projects around the world. We are proud of that. We intend to continue that 
> tradition by requiring that all software aggregations distributed by Apache 
> Software Foundation will be licensed to the public under the Apache License 
> 2.0. This means that all of our licensees around the world are free to:
>  
> ·   Use Apache software for any purpose.
> ·   Make and distribute copies.
> ·   Create and distribute derivative works.
> ·   Access and use the source code.
> ·   Combine Apache and other software.
>  
> In order to foster our Foundation community ethic to ensure the widest free 
> participation in the open source software community, Apache has now decided 
> to become also a universal acceptor of other open source software licensed to 
> us from around the world. 
>  
> When technically appropriate for that software in the judgment of the PMC, 
> 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.
>  
> Because Apache projects may now incorporate third party open source software 
> into our software aggregations, we have added the following procedures for 
> Apache software releases:
>  
> ·   Because all Apache project contributions will be licensed to Apache 
> under an OSI-approved open source license, the above list of five fundamental 
> software freedoms continues to apply to all Apache software. Downstream users 
> and re-distributors of Apache software can continue to incorporate all of our 
> open source software into their own products unmodified without incurring any 
> special derivative work reciprocity obligations.
>  
> ·   All releases containing any non-Apache open source licensed 
> contributions will be explicitly identified in a NOTICE file that our 
> projects will create. The PMC is responsible to ensure that the text in the 
> NOTICE file expressly satisfies the notice and disclosure requirements of all 
> relevant contribution licenses.
>  
> ·   Modifiers and re-distributors of Apache software will now need to 
> read the NOTICE files to determine whether they have any derivative work 
> reciprocity requirements for specific contributions. 
>  
> You may influence the inclusion or exclusion of specific third party 
> contributions under OSI-approved licenses by joining the Apache project. All 
> such decisions are made by Apache projects in public.
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Tzeng, Nigel H.]

Thanks, without the context it was somewhat harder to follow on license-discuss.

Consider this a vote in the negative as a non-member user of Apache software. 
If I have to start checking every Apache package for GPL code I'll have to 
strongly recommend that we approach all Apache packages with caution.

Becoming a "universal acceptor" significantly impacts your ability to be a 
"universal donor".  I have no desire to accidentally be the cause of any 
organization I work for becoming the test case for what is an aggregation vs 
what is a derivative.  If Apache was willing to indemnify downstream 
users...yah, I didn't think so.

Nice try though.

From: "lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>" 
mailto:lro...@rosenlaw.com>>
Reply-To: "memb...@apache.org<mailto:memb...@apache.org>" 
mailto:memb...@apache.org>>, 
"lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>" 
mailto:lro...@rosenlaw.com>>, License Discuss 
mailto:license-discuss@opensource.org>>
Date: Tuesday, May 26, 2015 at 10:16 PM
To: License Discuss 
mailto:license-discuss@opensource.org>>
Subject: [License-discuss] Proposal: Apache Third Party License Policy

[This has been a hellishly long thread on private Apache lists before the board 
cut off discussion on revised policies. Below was the short start of it I 
submitted over two weeks ago. Apache board members don't want to revise current 
policy. Many Apache members don't want it. Still, it is a serious proposal to 
bring some more freedom and cooperation to open source. Please treat this as a 
political document for license-discuss@. /Larry]

...
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Lawrence Rosen]

Nigel, your answer echoes many others:

 

> If I have to start checking every Apache package for GPL code I'll have to

> strongly recommend that we approach all Apache packages with caution.

 

If we amended the proposal to leave out the GPL licenses, would that calm
your concerns? 

 

I'd really hate to do that at Apache for that set of generous FOSS licenses,
but fear is fear Apache didn't cause this fear of "infection" and Apache
can't cure it. There is a group of attorneys that is drafting an appropriate
"exception" that would allow at least some GPL software to be aggregated
with Apache software.

 

But are ALL other OSI-approved licenses OK with you? 

 

/Larry

 

 

From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu] 
Sent: Wednesday, May 27, 2015 9:42 AM
To: memb...@apache.org; lro...@rosenlaw.com; 'License Discuss'
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

 

Thanks, without the context it was somewhat harder to follow on
license-discuss.

 

Consider this a vote in the negative as a non-member user of Apache
software. If I have to start checking every Apache package for GPL code I'll
have to strongly recommend that we approach all Apache packages with
caution.

 

Becoming a "universal acceptor" significantly impacts your ability to be a
"universal donor".  I have no desire to accidentally be the cause of any
organization I work for becoming the test case for what is an aggregation vs
what is a derivative.  If Apache was willing to indemnify downstream
users.yah, I didn't think so.

 

Nice try though.

 

From: "lro...@rosenlaw.com <mailto:lro...@rosenlaw.com> "
mailto:lro...@rosenlaw.com> >
Reply-To: "memb...@apache.org <mailto:memb...@apache.org> "
mailto:memb...@apache.org> >, "lro...@rosenlaw.com
<mailto:lro...@rosenlaw.com> " mailto:lro...@rosenlaw.com> >, License Discuss
mailto:license-discuss@opensource.org> >
Date: Tuesday, May 26, 2015 at 10:16 PM
To: License Discuss mailto:license-discuss@opensource.org> >
Subject: [License-discuss] Proposal: Apache Third Party License Policy

 

[This has been a hellishly long thread on private Apache lists before the
board cut off discussion on revised policies. Below was the short start of
it I submitted over two weeks ago. Apache board members don't want to revise
current policy. Many Apache members don't want it. Still, it is a serious
proposal to bring some more freedom and cooperation to open source. Please
treat this as a political document for license-discuss@. /Larry]

 

.

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Ben Tilly]

You will never cover all legitimate fears that organizations might
have for a variety of reasons that seem good to them.

For example you'd think that the BSD license would be entirely
unobjectionable.  But Facebook released a lot of code under BSD with a
patent license that many objected to.  (They eventually adjusted
course on that patent license, though there is still objectionable
stuff in there.  See
http://www.infoworld.com/article/2908879/open-source-software/facebook-gives-in-on-patent-grant.html
for a quick summary.)

The more easily that you want people to be able to accept what you
produce, the harder you have to be careful about what you consume.

On Wed, May 27, 2015 at 11:17 AM, Lawrence Rosen  wrote:
> Nigel, your answer echoes many others:
>
>
>
>> If I have to start checking every Apache package for GPL code I’ll have to
>
>> strongly recommend that we approach all Apache packages with caution.
>
>
>
> If we amended the proposal to leave out the GPL licenses, would that calm
> your concerns?
>
>
>
> I'd really hate to do that at Apache for that set of generous FOSS licenses,
> but fear is fear Apache didn't cause this fear of "infection" and Apache
> can't cure it. There is a group of attorneys that is drafting an appropriate
> "exception" that would allow at least some GPL software to be aggregated
> with Apache software.
>
>
>
> But are ALL other OSI-approved licenses OK with you?
>
>
>
> /Larry
>
>
>
>
>
> From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu]
> Sent: Wednesday, May 27, 2015 9:42 AM
> To: memb...@apache.org; lro...@rosenlaw.com; 'License Discuss'
> Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy
>
>
>
> Thanks, without the context it was somewhat harder to follow on
> license-discuss.
>
>
>
> Consider this a vote in the negative as a non-member user of Apache
> software. If I have to start checking every Apache package for GPL code I’ll
> have to strongly recommend that we approach all Apache packages with
> caution.
>
>
>
> Becoming a “universal acceptor” significantly impacts your ability to be a
> “universal donor”.  I have no desire to accidentally be the cause of any
> organization I work for becoming the test case for what is an aggregation vs
> what is a derivative.  If Apache was willing to indemnify downstream
> users…yah, I didn’t think so.
>
>
>
> Nice try though.
>
>
>
> From: "lro...@rosenlaw.com" 
> Reply-To: "memb...@apache.org" , "lro...@rosenlaw.com"
> , License Discuss 
> Date: Tuesday, May 26, 2015 at 10:16 PM
> To: License Discuss 
> Subject: [License-discuss] Proposal: Apache Third Party License Policy
>
>
>
> [This has been a hellishly long thread on private Apache lists before the
> board cut off discussion on revised policies. Below was the short start of
> it I submitted over two weeks ago. Apache board members don't want to revise
> current policy. Many Apache members don't want it. Still, it is a serious
> proposal to bring some more freedom and cooperation to open source. Please
> treat this as a political document for license-discuss@. /Larry]
>
>
>
> …
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[jonathon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/05/2015 18:17, Lawrence Rosen wrote:

> If we amended the proposal to leave out the GPL licenses, would that c
alm your concerns?

Right now, if I want to use a software package distributed by The Apache
Software Foundation, I can safely assume ^1 that it is the standard
Apache License, and all I have to be concerned about ^2, is how well the
standard Apache license fits with the license(s) for a project, or
proposed project that I'm working on.

The second issue is: "What will prevent an Apache project from
unilaterally changing to a different license?"

^1: I know that some projects currently use code that is licensed under
something else, but those are both rare exceptions, (at least I hope
that is the case) and utilize a license that either or both FSF and OSI
consider to be compatible with the standard Apache license.

^2: This is that planning/proposal/mockup stage. During coding, source
code licenses are verified to be what was expected, and what was adverti
sed.

jonathon

  * English - detected
  * English

  * English

 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVZpXoAAoJEE1PKy9+kxplnFUP/ijO7cqHF1ICJszrdgQru2Nn
C+S3JHdGnekTSC7POwAz7mqniFtelSz/dUNYyYUUp1yEiF0WIQS5vSxcXBBbOYOi
oFQUGW/wzKQOSqSNYHy5FBkuyyacSZPeEBrLAOSpE9dAV+r98F9wv3W4oJSecCzg
nh+JHDCFKMuAUw3nrqPUqs/CqZRBWI812wC93P7NgP4JEg2V5i/K0MKo/D/lBp6v
ip7bL/AR0RyXIpMPUsgnoOihm+RDioec19bwcGhhJVcn3DG8GzM8eFU7wCFZQQ16
472zxgU01BrZwItFhZSFGrt9JE9n9R6Y4sLmcdtpQMa6v8aMid0vnjMnmKzUJqQR
a+PtESTLn3xf6Xe8BNoMqwGd/M38WBH9l0/HGk1CCncsYsipBxPyyk7fNEho7dt8
t+kdXDNdHe4yxRNqmDfMALYg4nDmzbnSZl5Fbr4S/kMnymyhQlbAJWoZtDd/LX8G
Zmb+3BeWHNvGdJGFM4EFbxbbM1VkUQTE+8wvssEZzafse9vvqBmGJ6h2nSf7thPK
qD7y5T1uLgD525RJ3Yt1+wOU9FLGS1T8Oy/m9OmFt4abohFY1ulZ4MBYGckYf5fY
RWaGwQhOLWzGdGdJiPSZoJM+JPO8+F8CIVkfvoLri97UgRLMUhLzXyBA5yZOQxuY
S6s5wMFPQBRGY1QAE6Iw
=3ual
-END PGP SIGNATURE-
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Richard Eckart de Castilho]

On 27.05.2015, at 20:17, Lawrence Rosen  wrote:

> If we amended the proposal to leave out the GPL licenses, would that calm 
> your concerns?
>  
> I'd really hate to do that at Apache for that set of generous FOSS licenses, 
> but fear is fear Apache didn't cause this fear of "infection" and Apache 
> can't cure it. There is a group of attorneys that is drafting an appropriate 
> "exception" that would allow at least some GPL software to be aggregated with 
> Apache software.
>  
> But are ALL other OSI-approved licenses OK with you?

I'd personally not be inclined to make a blanket statement on all OSI-approved 
licenses - the list is quite longish.

For example, it is my understanding that the following clause from the LGPL 
also represents a reciprocal licensing term that we do not wish our downstream 
users to be affected by:

> 6. As an exception to the Sections above, you may also combine or link a 
> "work that uses the Library" with the Library to produce a work containing 
> portions of the Library, and distribute that work under terms of your choice, 
> provided that the terms permit modification of the work for the customer's 
> own use and reverse engineering for debugging such modifications.


Actually, I wonder how this licensing term goes along with the OSI rule "9. 
License Must Not Restrict Other Software".

Cheers,

-- Richard
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[cowan]

Richard Eckart de Castilho scripsit:

> Actually, I wonder how this licensing term goes along with the OSI rule
> "9. License Must Not Restrict Other Software".

That's not meant to apply to "other software" of which the licensed software
is a part.  The annotated OSD says:

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.

Rationale: Distributors of open-source software have the right to make
their own choices about their own software.

Yes, the GPL v2 and v3 are conformant with this requirement. Software
linked with GPLed libraries only inherits the GPL if it forms a single
work, not any software with which they are merely distributed.

(ends)

Don't judge a book by its cover or a clause by its title.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
My confusion is rapidly waxing
For XML Schema's too taxing:
I'd use DTDs / If they had local trees --
I think I best switch to RELAX NG.


___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Tzeng, Nigel H.]

Larry,

We're not afraid of GPL and use it where applicable.  The "where applicable" 
part is the issue. Same with "ALL other" OSI-approved licenses since each 
package would have to be reviewed as to whether it would be okay.

Whereas Apache is currently just ALv2 or ALv2 + some permissive license with a 
attribution clause.   It is easy for a Project Manager or Legal to say "if it's 
from Apache it's okay to use".  It's a known quantity and you can trust the 
brand.  Muddy the waters and this is no longer true and a huge step backwards.

Show me the case law to prove what you term aggregation is not what the FSF 
calls derivative and provide indemnification against copyright infringement if 
it isn't aggregation.

THEN the concerns are mitigated.  Otherwise inclusion of any copyleft licensed 
code in Apache projects is a huge issue for users.

From: Lawrence Rosen mailto:lro...@rosenlaw.com>>
Reply-To: Lawrence Rosen mailto:lro...@rosenlaw.com>>, 
License Discuss 
mailto:license-discuss@opensource.org>>
Date: Wednesday, May 27, 2015 at 2:17 PM
To: License Discuss 
mailto:license-discuss@opensource.org>>
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

Nigel, your answer echoes many others:

> If I have to start checking every Apache package for GPL code I'll have to
> strongly recommend that we approach all Apache packages with caution.

If we amended the proposal to leave out the GPL licenses, would that calm your 
concerns?

I'd really hate to do that at Apache for that set of generous FOSS licenses, 
but fear is fear Apache didn't cause this fear of "infection" and Apache 
can't cure it. There is a group of attorneys that is drafting an appropriate 
"exception" that would allow at least some GPL software to be aggregated with 
Apache software.

But are ALL other OSI-approved licenses OK with you?

/Larry


From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu]
Sent: Wednesday, May 27, 2015 9:42 AM
To: memb...@apache.org<mailto:memb...@apache.org>; 
lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>; 'License Discuss'
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

Thanks, without the context it was somewhat harder to follow on license-discuss.

Consider this a vote in the negative as a non-member user of Apache software. 
If I have to start checking every Apache package for GPL code I'll have to 
strongly recommend that we approach all Apache packages with caution.

Becoming a "universal acceptor" significantly impacts your ability to be a 
"universal donor".  I have no desire to accidentally be the cause of any 
organization I work for becoming the test case for what is an aggregation vs 
what is a derivative.  If Apache was willing to indemnify downstream 
users...yah, I didn't think so.

Nice try though.

From: "lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>" 
mailto:lro...@rosenlaw.com>>
Reply-To: "memb...@apache.org<mailto:memb...@apache.org>" 
mailto:memb...@apache.org>>, 
"lro...@rosenlaw.com<mailto:lro...@rosenlaw.com>" 
mailto:lro...@rosenlaw.com>>, License Discuss 
mailto:license-discuss@opensource.org>>
Date: Tuesday, May 26, 2015 at 10:16 PM
To: License Discuss 
mailto:license-discuss@opensource.org>>
Subject: [License-discuss] Proposal: Apache Third Party License Policy

[This has been a hellishly long thread on private Apache lists before the board 
cut off discussion on revised policies. Below was the short start of it I 
submitted over two weeks ago. Apache board members don't want to revise current 
policy. Many Apache members don't want it. Still, it is a serious proposal to 
bring some more freedom and cooperation to open source. Please treat this as a 
political document for license-discuss@. /Larry]

...
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Tzeng, Nigel H.]

On 5/28/15, 12:13 AM, "jonathon"  wrote:


>Right now, if I want to use a software package distributed by The Apache
>Software Foundation, I can safely assume ^1 that it is the standard
>Apache License, and all I have to be concerned about

You still need to read the LICENSE & NOTICE files.  For example
commons-math includes some permissively licensed with an attribution
clauses that you must adhere to.

It¹s not typically onerousŠyou just have to remember to do so.

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[jonathon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 28/05/2015 16:48, Tzeng, Nigel H. wrote:

>> Right now, if I want to use a software package distributed by The Apa
che
>> Software Foundation, I can safely assume ^1 that it is the standard

> You still need to read the LICENSE & NOTICE files.

That is why I wrote:  « During coding, source code licenses are verified
to be what was expected, and what was advertised.»

By way of example, if I'm planning a project that requires Big Data
Analysis, and needs to scale up from petabytes of data, currently, I can
safely assume that Apache Hadoop uses a standard Apache License.
If this proposal takes place, I'll have to look at the license and
notice for every file in Hadoop, during the project planning stage, as
well as during the coding.
For a project planner, the difference is spending 30 minutes playing
with something from The Apache Foundation, to see if it "works" and
spending hours, ^1 verifying that the licenses are what they purport to
be, before spending any time playing with the software, determining
suitability for the project.  And then during the coding process,
somebody will have to spend time verifying that the licenses are what
they were purported to be, and checked out as being, during the project
planning stage.

^1: I am aware of software that reads License and Notice files, to
determine that they conform with known, accepted, licenses.  However,
that software can overlook bizarre clauses.

jonathon

  * English - detected
  * English

  * English

 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVZ1JrAAoJEE1PKy9+kxpl16IQAINYeuNdZaUWEFNSWGWBEAkU
ueUXuHsZwGZf2MJkGiw0sdfqMMtATxSqHPWgiNz7BDaIKR6VMHgsD5zQ9Hlwfw1k
l4fLBDIctrq4A49tDFpR3nSabE7jwUgR790RnsV3rR/HBdczzx6vrNTxXhrC5CMv
LY+Y8R/39E/dtUIj1kwnhQWYyi+iQGb/10lDtwHCVeALh5rZF9Apd73QsPCV+H6u
//VJE//zHu/UJmrIX/h9ZyEQwQ93GLoouimTjjVEYhnHPRc6m5HQuLntU4J+rCUV
bPArdkQuRFpduMHIbtZ0kHwsqowZDeM5GDePZDbKHst5kXRta8Q1wXn5Jkm4u8+0
zq22ioPqinhuZdIbhzgnseA3uGnOTxkDVixh9WByyQeZ9H16bfYdEAQpFrGgHkXN
X+4yOtzk/7EhGjmf52PBc4YClVaahbN0kxaU2O+9WJDA/qIF9CBoUnGKzGDr2VXF
SPaW3DlN0PONhJWNM6YVglm7+aywPVZ8ITGBQYj31Z9B2CTtnwDl2TwhJio1ECDo
pLl1bH25YOo56jQXRS1jbMec1X30Ludn14/ubuTd7PrqUBZFtb/ThPxp5UzVGxps
K1OXAwHBKPpaJUzLvn69Pl2JNG9SW5Giaf1Gt7bb6FnM+hLFtST58Js1l4PG8js8
U1qQM/OvDkNYy+o8YEz/
=xL4Y
-END PGP SIGNATURE-
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Paul Tagliamonte]

On Thu, May 28, 2015 at 05:37:48PM +, jonathon wrote:
> That is why I wrote:  « During coding, source code licenses are verified
> to be what was expected, and what was advertised.»
> 
> By way of example, if I'm planning a project that requires Big Data
> Analysis, and needs to scale up from petabytes of data, currently, I can
> safely assume that Apache Hadoop uses a standard Apache License.
> If this proposal takes place, I'll have to look at the license and
> notice for every file in Hadoop, during the project planning stage, as
> well as during the coding.
> For a project planner, the difference is spending 30 minutes playing
> with something from The Apache Foundation, to see if it "works" and
> spending hours, ^1 verifying that the licenses are what they purport to
> be, before spending any time playing with the software, determining
> suitability for the project.  And then during the coding process,
> somebody will have to spend time verifying that the licenses are what
> they were purported to be, and checked out as being, during the project
> planning stage.
> 
> ^1: I am aware of software that reads License and Notice files, to
> determine that they conform with known, accepted, licenses.  However,
> that software can overlook bizarre clauses.

[replying with my @gmail, just to be clear I'm not speaking for anyone
 besides myself]

Not for nothing, but this is starting to feel more like an ASF thread.

This feels like a political issue the ASF should address on their own;
this thread (purely) being on license-discuss strikes me as odd, could
we move this to the relevant Apache list(s)?

This isn't really a license issue at all (since combining works, even
when not mere aggregation) from Apache2 and LGPL3+/GPL3+ is totally
fine, just results in the combined work distributed under the terms of
the LGPL/GPL.

So, this is really a question for ASF if they wish to allow this on a
policy and political level (for either combined work(s) or mere
aggregations - or both!)


Much love,
  Paul

-- 
:wq


signature.asc
Description: Digital signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Lawrence Rosen]

Nigel, I was looking forward to your answers. They are well thought out. :-)


 

But this part isn't true: "Whereas Apache is currently just ALv2 or ALv2 +
some permissive license with a attribution clause." Read our NOTICE files
(such as they currently exist), or browse the public archives of our
contributions and our aggregations, or run code scans. The current policy
allows "exceptions" to that policy you paraphrased:

 

https://www.apache.org/legal/ramblings.html

 

http://www.apache.org/legal/resolved.html 

 

OTOH, the draft proposal is less than a page long and fits easily in an
email. (See attached.)

 

Under the current rambled Apache policy there is a Legal-JIRA that is
supposed to be posted for every question about what is "an exception."
We're in the 200's in that archive. And the responses there do not benefit
from any of the analytical skills [like Nigel's and many others!] here at
OSI's license-discuss@. 

 

So help Apache!  If there is a set of OSI-approved licenses that adequately
scope "aggregations," including of course the EPL and MPL and the like, that
you think are appropriate for an Apache project to include in an Apache
aggregation, I'd much rather that OSI identify those licenses than that
Apache's engineers JIRA it to death. 

 

The statement that you "use [GPL] where applicable" is right-on! I
occasionally recommend that license too (as at CAVO@ here at OSI). But
please don't forget the final paragraph in the draft Apache proposal:

 

You may influence the inclusion or exclusion of specific third party
contributions under OSI-approved licenses by joining the Apache project. All
such decisions are made by Apache projects in public.

 

Under the Apache Way, I'd rather trust an OSI-blessed list of acceptable
FOSS licenses, and have Apache projects give you a NOTICE file and let you
decide. Remember, under ALv2 our Apache distributed aggregations are ALL
always FOSS.

 

Finally, please, I'd rather hear the following statement from another brave
lawyer here besides me.

 

Nobody who modifies and redistributes software should accept the safety of
Apache or any other FOSS software in a "brain-dead" way (quoting another
email here). Be aware that we live in a commercial open source software
world that includes the legal doctrine of "willful blindness
<http://en.wikipedia.org/wiki/Willful_blindness> ."

 

/Larry

Lawrence Rosen

"If this were legal advice it would have been accompanied by a bill."

 

 

From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu] 
Sent: Thursday, May 28, 2015 9:40 AM
To: Lawrence Rosen; 'License Discuss'
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

 

Larry,

 

We're not afraid of GPL and use it where applicable.  The "where applicable"
part is the issue. Same with "ALL other" OSI-approved licenses since each
package would have to be reviewed as to whether it would be okay.

 

Whereas Apache is currently just ALv2 or ALv2 + some permissive license with
a attribution clause.   It is easy for a Project Manager or Legal to say "if
it's from Apache it's okay to use".  It's a known quantity and you can trust
the brand.  Muddy the waters and this is no longer true and a huge step
backwards.

 

Show me the case law to prove what you term aggregation is not what the FSF
calls derivative and provide indemnification against copyright infringement
if it isn't aggregation.  

 

THEN the concerns are mitigated.  Otherwise inclusion of any copyleft
licensed code in Apache projects is a huge issue for users.

 

From: Lawrence Rosen mailto:lro...@rosenlaw.com> >
Reply-To: Lawrence Rosen mailto:lro...@rosenlaw.com>
>, License Discuss mailto:license-discuss@opensource.org> >
Date: Wednesday, May 27, 2015 at 2:17 PM
To: License Discuss mailto:license-discuss@opensource.org> >
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

 

Nigel, your answer echoes many others:

 

> If I have to start checking every Apache package for GPL code I'll have to

> strongly recommend that we approach all Apache packages with caution.

 

If we amended the proposal to leave out the GPL licenses, would that calm
your concerns? 

 

I'd really hate to do that at Apache for that set of generous FOSS licenses,
but fear is fear Apache didn't cause this fear of "infection" and Apache
can't cure it. There is a group of attorneys that is drafting an appropriate
"exception" that would allow at least some GPL software to be aggregated
with Apache software.

 

But are ALL other OSI-approved licenses OK with you? 

 

/Larry

 

 

From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu] 
Sent: Wednesday, May 27, 2015 9:42 AM
To: memb...@apache.org <mailto:memb...@

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

[Simon Phipps]

[Removing cross-posting]

It's hard to see why this Apache-specific discussion is being redirected to
OSI's mailing list and I suggest we end the conversation unless there is a
specific and well-defined question for us to answer.

Thanks,

Simon
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Lawrence Rosen]

Simon Phipps suggested:

> unless there is a specific and well-defined question for us to answer

 

Q: Which OSI-approved licenses (including MPL, EPL, and the like) are 
*compatible for aggregating* with ALv2 software without "infecting" the rest of 
the aggregated work?

 

The word "aggregate" is used in the OSD. The word "infect" carries much 
unwelcome baggage. I welcome OSI's license-discuss@ efforts to define these 
terms.

 

This question is not specific to the Apache Software Foundation policy on this 
matter or about NOTICE files. ASF is not the only one aggregating ALv2 software 
with other FOSS software. The above is a relevant open source question to all 
of our customers.

 

Thanks for your thoughts.

 

/Larry

 

 

From: Simon Phipps [mailto:webm...@opensource.org] 
Sent: Friday, May 29, 2015 4:51 AM
To: Lawrence Rosen; license-discuss@opensource.org
Subject: Re: [License-discuss] Proposal: Apache Third Party License Policy

 

[Removing cross-posting]

 

It's hard to see why this Apache-specific discussion is being redirected to 
OSI's mailing list and I suggest we end the conversation unless there is a 
specific and well-defined question for us to answer.

 

Thanks,

 

Simon

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[cowan]

Lawrence Rosen scripsit:

> Q: Which OSI-approved licenses (including MPL, EPL, and the like) are
> *compatible for aggregating* with ALv2 software without "infecting" the
> rest of the aggregated work?

All of it, per OSD #1 and the usual understanding of "aggregate".
The OED3 defines the relevant sense of "aggregate" as "To gather (articles,
videos, or other items of digital content) from the Internet and present
them to the user on a single web site, application, etc."

But what ASF seems to care about is: "What, as a matter of policy, should
aggregates published by the ASF contain?"  That has little to do with
license compatibility within the aggregation, and everything to do with
what guarantees ASF (or any similar publisher) wishes to provide to its
customers.

I happen to think that their A, B, and X lists make a lot of sense and
are substantially correct.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Evolutionary psychology is the theory that men are nothing but horn-dogs,
and that women only want them for their money.  --Susan McCarthy (adapted)


___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss