Posted by Phil Odence on Thursday, December 8th, 2016
The JSON license 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, really, lies the problem.
Actually, defined or not, this clause is enough to disqualify it 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, Black Duck tracks over 2,700 licenses in its KnowledgeBase. 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.” They re-raised the issue 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 the “X list.” 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 non-standard licenses that adopters of software must contend with. One common source of variants, as in the JSON 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.
Get the latest AppSec news and trends sent directly to you.