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