Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
From: "Roy T. Fielding" <fielding@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_276C6A2D-3A39-4D58-BE1F-C6905F876AE0"
Message-Id: <6D1F7AF9-D982-4033-9B84-04CB55E54195@gbiv.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Non OSI approved licenses
Date: Wed, 3 May 2017 11:50:24 -0700
References: <0ACD0AAF-BE23-4039-83B7-DD7519A1CBC8@jaguNET.com> <CABD8fLXn+XMKZ60tLP-H6i+192dDGotfhND68mNj6-3rHDADtQ@mail.gmail.com> <CA+ULb+sH1d2oOYivO7x0i8kgo3b9MdB_eGw_nK0wNh7q0ytVhw@mail.gmail.com> <C47B20E7-2D75-4CFD-ABFF-E2C8570E4B5B@gbiv.com> <CAL5zq9an4PjZms21F812nVyjYizSNja7yo3UmPWP6tFXUAeyug@mail.gmail.com>
To: legal-discuss@apache.org
In-Reply-To: <CAL5zq9an4PjZms21F812nVyjYizSNja7yo3UmPWP6tFXUAeyug@mail.gmail.com>
archived-at: Wed, 03 May 2017 18:50:38 -0000

--Apple-Mail=_276C6A2D-3A39-4D58-BE1F-C6905F876AE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On May 3, 2017, at 5:54 AM, Christopher <ctubbsii@apache.org> wrote:
>=20
> For what it's worth, the *only* reason I initially considered ALv2 for =
my own projects and recommended it to my employer for theirs, before I =
started contributing to Apache software, was because it was approved by =
both OSI and FSF. I doubt I'm not alone in that.

There are a lot of people who think that way, now. ALv2 did not start as =
an OSI
approved license. OSI didn't even think we had cause to create a new =
license.
They have since understood that there is more to open source than =
copyright.

> These groups are excellent proxies for what is "well-known" and =
"widely accepted" (I'm not aware of a better source, anyway). If those =
qualities matter at all to the ASF, then it makes sense to strongly =
prefer licenses approved by these groups over legally-equivalent ones =
which are relatively unknown. (Admittedly, I don't know what form this =
"preference" should take.)
>=20
> I think any decision we make to restrict (or just "prefer") another =
group's approved licenses is still our own decision. So, I don't think =
it makes them them the "license arbiter for Apache" any more than the =
choice to follow the Google Style Guide makes Google the style arbiter =
or the choice to follow Semver 2.0.0 makes semver.org =
<http://semver.org/> the API arbiter.

We just went though an actual, real-world example in which that =
statement would
be factually incorrect.  The ACE license is not OSI-approved, for no =
other reason
than it is a legacy, project-specific variant of BSD.  Jim suggested we =
forbid its inclusion
in an Apache software release based solely on the fact that OSI had not =
approved
that specific license.

What Apache distributes in our source releases is entirely covered by =
the terms
of the Apache License 2.0, whether or not specific files within those =
products
have terms that are *subsets* of those in ALv2.  We satisfy the =
individual license
terms by the contents of LICENSE and NOTICE files, and require those =
file
contents to remain (if applicable) in all downstream distributions.

What other companies receive from the ASF is a package under the Apache =
License.
This is us, the ASF, telling the world that the entire package can be =
redistributed
under the terms of the Apache License NO MATTER WHAT is enclosed in the
package.  Period.  It is our responsibility to ensure that statement is =
true, not OSI's.
Companies trust Apache far more than they trust OSI.

Lawyers understand that concept, just fine, since traditional software =
licensing
occurs as master licenses by one corporation, regardless of how many =
components
developed by multiple entities might be in the package being licensed.

....Roy


--Apple-Mail=_276C6A2D-3A39-4D58-BE1F-C6905F876AE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
May 3, 2017, at 5:54 AM, Christopher &lt;<a =
href=3D"mailto:ctubbsii@apache.org" class=3D"">ctubbsii@apache.org</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">For what it's worth, the *only* reason I =
initially considered ALv2 for my own projects and recommended it to my =
employer for theirs, before I started contributing to Apache software, =
was because it was approved by both OSI and FSF. I doubt I'm not alone =
in that.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div>There are a lot of people who think that way, now. ALv2 =
did not start as an OSI</div><div>approved license. OSI didn't even =
think we had cause to create a new license.</div><div>They have since =
understood that there is more to open source than =
copyright.</div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">These groups are =
excellent proxies for what is "well-known" and "widely accepted" (I'm =
not aware of a better source, anyway). If those qualities matter at all =
to the ASF, then it makes sense to strongly prefer licenses approved by =
these groups over legally-equivalent ones which are relatively unknown. =
(Admittedly, I don't know what form this "preference" should take.)<br =
class=3D""><br class=3D"">I think any decision we make to restrict (or =
just "prefer") another group's approved licenses is still our own =
decision. So, I don't think it makes them them the "license arbiter for =
Apache" any more than the choice to follow the Google Style Guide makes =
Google the style arbiter or the choice to follow Semver 2.0.0 makes <a =
href=3D"http://semver.org/" class=3D"">semver.org</a> the API =
arbiter.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div>We just went though an actual, real-world example in =
which that statement would</div><div>be factually incorrect. &nbsp;The =
ACE license is not OSI-approved, for no other reason</div><div>than it =
is a legacy, project-specific variant of BSD. &nbsp;Jim suggested we =
forbid its inclusion</div><div>in an Apache software release based =
solely on the fact that OSI had not approved</div><div>that specific =
license.</div><div><br class=3D""></div><div>What Apache distributes in =
our source releases is entirely covered by the terms</div><div>of the =
Apache License 2.0, whether or not specific files within those =
products</div><div>have terms that are *subsets* of those in ALv2. =
&nbsp;We satisfy the individual license</div><div>terms by the contents =
of LICENSE and NOTICE files, and require those file</div><div>contents =
to remain (if applicable) in all downstream distributions.</div><div><br =
class=3D""></div><div>What other companies receive from the ASF is a =
package under the Apache License.</div><div>This is us, the ASF, telling =
the world that the entire package can be redistributed</div><div>under =
the terms of the Apache License NO MATTER WHAT is enclosed in =
the</div><div>package. &nbsp;Period. &nbsp;It is our responsibility to =
ensure that statement is true, not OSI's.</div><div>Companies trust =
Apache far more than they trust OSI.</div><div><br =
class=3D""></div><div>Lawyers understand that concept, just fine, since =
traditional software licensing</div><div>occurs as master licenses by =
one corporation, regardless of how many components</div><div>developed =
by multiple entities might be in the package being =
licensed.</div><div><br class=3D""></div><div>....Roy</div><div><br =
class=3D""></div></body></html>=

--Apple-Mail=_276C6A2D-3A39-4D58-BE1F-C6905F876AE0--