Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
MIME-Version: 1.0
From: Ted Dunning <tdunning@apache.org>
Date: Thu, 27 Oct 2016 10:49:27 -0700
Message-ID: <CAJwFCa34RKbC35_GSg5NxZrQ1=b36-zw13f=mc9ayXinibVBHQ@mail.gmail.com>
Subject: JSON license again
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Content-Type: multipart/alternative; boundary=001a1135045eb25eff053fdc5e73
archived-at: Thu, 27 Oct 2016 17:50:06 -0000

--001a1135045eb25eff053fdc5e73
Content-Type: text/plain; charset=UTF-8

I know that this has been brought up, but I think that we have
institutionalized an erroneous decision. That decision is that the json.org
license is a Category A license.

The json.org version of the BSD license is problematic because it imposes
constraints on the downstream consumer by including a constraint on field
of endeavor that the software "not be used for evil". Debian and Google,
for instance, won't consume anything with this license:

https://wiki.debian.org/qa.debian.org/jsonevil
https://www.cnet.com/news/dont-be-evil-google-spurns-no-evil-software/

Apache has codified a policy that is apparently based on a determination
that the no-evil clause was "clearly a joke".

https://www.apache.org/legal/resolved#json
https://s.apache.org/json-license-ok

At work, we now have more than one customer whose legal team has decided
not to get the joke. I will be filing patches to remove those dependencies
from Hive and HCatalog, but the point remains that the json.org license
isn't acceptable to those customers.

To me, all of this clearly shows that the json license is substantially
hindering downstream adoption due to a perception by those downstream
consumers that you can't put a joke into a license. I, frankly, agree with
those folks. Not doing evil is a good thing and I try to do that myself,
but having to get a legal opinion that everything I do is not evil would
make it impossible to get anything done.

I think that this license should be moved to category X due to the non-free
nature of the license. There is a clean-room reimplementation of the core
part of the library available from the Android team
<https://developer.android.com/reference/org/json/package-summary.html> so
removing the dependency. Using Jackson or Gson instead is another fine
approach.

A quick look at maven central indicates that at least the following Apache
projects are affected

Tika
Hive
Wink
possibly Asterixdb (because hyracks had this dependency)
Shindig
Spark (transitive from Hive)
Giraph
Rave
Felix
Tuscany
Tinkerpop

--001a1135045eb25eff053fdc5e73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div>I know that this has been brought up, but I think=
 that we have institutionalized an erroneous decision. That decision is tha=
t the <a href=3D"http://json.org">json.org</a> license is a Category A lice=
nse.</div><div><br></div><div>The <a href=3D"http://json.org">json.org</a> =
version of the BSD license is problematic because it imposes constraints on=
 the downstream consumer by including a constraint on field of endeavor tha=
t the software &quot;not be used for evil&quot;. Debian and Google, for ins=
tance, won&#39;t consume anything with this license:</div><div><br></div><d=
iv><a href=3D"https://wiki.debian.org/qa.debian.org/jsonevil">https://wiki.=
debian.org/qa.debian.org/jsonevil</a><br></div><div><a href=3D"https://www.=
cnet.com/news/dont-be-evil-google-spurns-no-evil-software/">https://www.cne=
t.com/news/dont-be-evil-google-spurns-no-evil-software/</a><br></div><div><=
br></div><div>Apache has codified a policy that is apparently based on a de=
termination that the no-evil clause was &quot;clearly a joke&quot;.</div><d=
iv><br></div><div><a href=3D"https://www.apache.org/legal/resolved#json">ht=
tps://www.apache.org/legal/resolved#json</a><br></div><div><a href=3D"https=
://s.apache.org/json-license-ok">https://s.apache.org/json-license-ok</a><b=
r></div><div><br></div><div>At work, we now have more than one customer who=
se legal team has decided not to get the joke. I will be filing patches to =
remove those dependencies from Hive and HCatalog, but the point remains tha=
t the <a href=3D"http://json.org">json.org</a> license isn&#39;t acceptable=
 to those customers.</div><div><br></div><div>To me, all of this clearly sh=
ows that the json license is substantially hindering downstream adoption du=
e to a perception by those downstream consumers that you can&#39;t put a jo=
ke into a license. I, frankly, agree with those folks. Not doing evil is a =
good thing and I try to do that myself, but having to get a legal opinion t=
hat everything I do is not evil would make it impossible to get anything do=
ne.</div><div><br></div><div>I think that this license should be moved to c=
ategory X due to the non-free nature of the license. There is a clean-room =
reimplementation of the core part of the <a href=3D"https://developer.andro=
id.com/reference/org/json/package-summary.html">library available from the =
Android team</a>=C2=A0so removing the dependency. Using Jackson or Gson ins=
tead is another fine approach.</div><div><br></div><div>A quick look at mav=
en central indicates that at least the following Apache projects are affect=
ed=C2=A0</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:=
none;padding:0px"><div>Tika</div><div>Hive</div><div>Wink</div><div>possibl=
y Asterixdb (because hyracks had this dependency)</div><div>Shindig</div><d=
iv>Spark (transitive from Hive)</div><div>Giraph</div><div>Rave</div><div>F=
elix</div><div>Tuscany</div><div>Tinkerpop</div></blockquote><div><br></div=
><div><br></div></div>

--001a1135045eb25eff053fdc5e73--