Software Integrity Blog

 

The fly in the ointment of the JSON license

Use of some JSON projects is limited by the JSON License, which has a problematic, ambiguous clause. The Apache Foundation recently reexamined the issue.

The JSON License and the problem with "Good" and "Evil"

JSON (JavaScript Object Notation) is an extremely flexible, lightweight format for exchanging data of all sorts. It lives up to JSON.org’s description as “an ideal data-interchange format.” But use of some JSON projects is limited by the JSON License. Concern with the license is not new, but the issue has recently been reexamined by the Apache Foundation, and the discussion is a good reminder of the importance of license selection and a caution against “rolling your own.”

The troublesome JSON License clause

The JSON License (read the whole text here) is typical of permissive licenses, with a grant of broad rights, an obligation of attribution, and a disclaimer of liability. Great stuff so far. The fly in the ointment is a little, nine-word addition: “The Software shall be used for Good, not Evil.” “Software” is a defined term. “Good” and “Evil” are not. And therein lies the problem.

Actually, defined or not, this clause is enough to disqualify the JSON License as an open source license per se. Point 6 of the Open Source Initiative (OSI) definition of an open source license is “No Discrimination Against Fields of Endeavour,” which would include evil ones. Although the OSI has approved fewer than 80 licenses, we track over 2,500 licenses in the Black Duck KnowledgeBase, our open source database. Many, like the JSON License, are minor variations on more common licenses.

The Apache Foundation

My sense is that the Apache Foundation, in its license selection, is not so much focused on the lack of OSI approval. Rather, the concern is its ambiguity, Evil clearly being in the mind of the beholder. Some time ago, the foundation justified inclusion of code with the JSON License, on the basis that the Good/Evil clause is “clearly a joke.” But they raised the issue again six weeks or so ago, on the basis that downstream attorneys may not get the joke, thus hindering adoption. And Apache is all about encouraging adoption. Rethinking the decision, they have moved the license to Category X. And they are working to remove any JSON-licensed components from Apache projects.

Use of the JSON License

The JSON License is not among the top licenses we see, but JSON-licensed components are embedded in over 2,300 projects tracked in the Black Duck KnowledgeBase, including some very popular ones, like Perl, Lucene, and Solr. It also turns up in components of some versions of the Java software development kit and runtime environment. So if you are running a Java application, don’t be Evil.

Reining in license proliferation

License proliferation was a big topic 10 years ago. The OSI and the community, in general, have done a good job reining that in. The top 20 licenses cover approximately 98% of the open source out there, so an attorney familiar with a relatively small number licenses is in pretty good shape. But clearly there’s a long, long tail of nonstandard licenses that adopters of software must contend with. One common source of variants, as in the JSON License case, is adding restrictions to a common license. Many, like this one, are not ill-intended. Some licenses, for example, disallow use by companies that use animals for testing or those involved with nuclear power.

Why popular licenses drive adoption

However, understanding the desire for individuality, it’s still a bad idea to invent your own license. There are plenty of official open source licenses from which to choose. Most people or organizations that make their work available as open source want to see adoption. Picking a popular license will help to encourage developers to adopt. In addition, working from a common, standard open source license greatly reduces the burden on lawyers with respect to their review and interpretation of such license. To give a sense for the friction that can come with a custom license, this discussion has, in recent weeks, generated literally hundreds of emails for the Apache Foundation.

Business users of software, too, should be mindful of the rights and obligations of licenses in the products they consume to ensure there are no unusual clauses that could interfere with their use of the software.

Get the 2019 OSSRA

 

More by this author