Apache and the JSON license

The JSON license is a slightly modified variant of the MIT license, but that variation has led it to be rejected as a free-software or open-source license by several organizations. The change is a simple—rather innocuous at some level—addition of one line: "The Software shall be used for Good, not Evil.". Up until recently, code using the JSON license was acceptable for Apache projects, but that line and the ambiguity it engenders was enough for Apache to put it on the list of disallowed licenses.

At the end of October, Ted Dunning brought up the license on the Apache legal-discuss mailing list. He suggested that classifying the JSON license as acceptable (i.e. on the list of Category A licenses) was an "erroneous decision". That decision was made, he said, "apparently based on a determination that the no-evil clause was 'clearly a joke'". He pointed to a thread from 2008 where a "lazy consensus" formed that the "not evil" condition did not preclude Apache projects from using the license.

But Dunning pointed out that some of his customers' legal teams are not getting the "joke". As a license term, "good not evil" leaves quite a bit to be desired:

Dunning suggested that the license be moved to Category X, which contains licenses that cannot be used by Apache projects. Multiple replies in the thread made it clear there is no real support for the license and plenty of interest in seeing it be banned. In fact, Apache's vice president of legal affairs, Jim Jagielski, decided to ban the license on November 3. He explained his reasoning in a post two days earlier:

But, simply removing the license from the approved list doesn't magically fix the projects that depend on code using it. Dunning had a list of around a dozen Apache projects that may depend on JSON-licensed code; there may well be others. He also pointed to a Debian web page listing alternative JSON implementations. But work needs to be done to switch projects to acceptable alternatives—and that will take time.

Apache projects cannot make releases using code that is covered by a Category X license, so any that depend on JSON-licensed code need to fix that. Alan Gates wondered if there could be some kind of grace period for projects to come into compliance. He noted that the Apache Hive data warehousing project is in the middle of trying to get out a maintenance release, which would be blocked by the change; others may be similarly affected. Furthermore:

He and Jagielski had spoken about the matter and the latter had suggested perhaps adding a "grandfather clause" that would allow projects that already use JSON-licensed code to continue to make releases for some period of time. Gates proposed six months as that time frame. In general, that idea was popular, but there were some wrinkles.

Dunning would like to see a much shorter deadline for resolving the license problem. He has done some work to make it easier for projects to switch to a properly licensed alternative, but there is still a lot of testing that needs to be done to ensure everything works correctly. Gates asked if a six-month period would really matter given that the license has been present in Apache products for years, but Dunning is concerned that Apache projects are losing users over it:

There are other considerations, though. Andrew Wang said that the Apache Hadoop framework for big data processing relies on third-party libraries that use JSON-licensed code. "We can't simply swap it out." In addition, enterprise software is expected to only make bug fixes for multiple years, he said, so switching libraries will be problematic from that perspective:

There was a fair amount of discussion of how various projects could proceed to remove the dependency on JSON-licensed code, but no clear consensus emerged on how disruptive the change would be. Enough of a consensus on having a grace period of some length did emerge, however, to the point that Jagielski issued a statement that prohibited projects from adding JSON license dependencies, but allowed others some time to make the change:

It is, in some ways, surprising that it has taken this long for Apache to tackle this particular license problem. Other organizations have banned the license for years and Apache is rather notoriously picky about licenses. The "determination" that it was a joke clause back in 2008 seems a bit strange, in truth. But "there has been no real 'outcry' over our usage of it, especially from end-users and other consumers of our projects which use it", Jagielski said, which may explain why it hadn't been addressed until now.

It is likely that few would admit to using the JSON-licensed code for "evil" (however that is defined), but that isn't really the crux of the matter. Legal departments are understandably leery of how others (and courts, in particular) might interpret the clause. It is quite ambiguous and corporate legal teams go to great lengths to avoid that kind of thing when they can. Given that Apache projects are used at lots of large companies, it is perhaps also surprising that the outcry wasn't louder than it is even today.

Several in the thread wondered about getting the license's author, Douglas Crockford, to change it. That was deemed unlikely by Jagielski and Sam Ruby, who have both discussed it with him multiple times. Crockford has given at least one license exception in the past ("I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."), though no one suggested pursuing that path for Apache projects.

But letting the issue linger certainly had a cost for the projects that depended on that code. It would, it seems, have been far better to grasp the nettle some time ago. In the end, though, by mid-2017 the problem should be resolved, hopefully with minimal disruption.