Posted by Phil Odence on August 15, 2018
The Apache Software Foundation’s legal group is an interesting microcosm in which to study open source license issues. Generally, what the Apache Software Foundation (ASF) deems good is good for companies looking to consume open source, and what’s not is not. So their open discussions are useful to monitor if you want to keep tabs on current license issues. Recently they had a go-round about “joke licenses,” which for some companies are no joke. In the end, they decided to disallow the use of software under two different licenses.
The ASF’s mission is “to provide software for the public good.” The organization seems to have concluded that doing the most good requires that the software they provide be readily consumable by all kinds of organizations, not least commercial entities. There are many aspects to ensuring consumability, but certainly licensing plays a big part. The Apache License is recognized as one of the most commercial-friendly licenses—most companies are very comfortable incorporating Apache-licensed code in their software. Beyond that, the Apache Software Foundation has taken it upon itself to vet code included in Apache projects for other licenses that might apply. Their legal group is extremely careful about which licenses they will allow and maintains a list of “Category X” licenses that are disallowed from Apache projects. And recently, after only brief debate, the ASF decided to add two licenses to Category X.
The first was the Solipsistic Eclipse Public License. In case you don’t remember solipsism from your Philosophy 101 course, it is the idea that the only thing you can truly know to exist is your own mind; everything else either is or could be an illusion. The license essentially incorporates the terms of the Eclipse Public License, but goes on to include the caveats “provided that you do not believe the Eclipse Foundation or the author exists, and provided that you affirm publicly when referring to the work, or when questioned or interrogated by beings who putatively exist, that the work does not exist.” Amusing? I think so, and that was clearly the intent, but the ASF has nevertheless banned the license from Apache projects.
Evaluating the SEPL raised similar consideration of the Don’t Be a D*** Public License (copyright 2016), or DBAD license (in its more socially acceptable form). Unlike another questionable license, the WTFPL—which I would argue is, albeit profane, unambiguous—the DBAD is very open to interpretation. It starts with a broad grant of rights—“Do whatever you like”—but then reels those rights back from potential licensees who are being a d***, a state clearly in the eyes of the beholder. So…Category X it is.
No one in the ASF discussion was particularly hung up on the profanity, and someone even took the position that joke licenses are unenforceable so not a problem. But in the end, the essence of the issue of concern was well-characterized by one of the participants in the discussion: “It is the perception of risk by the more conservative of the user population of Apache software.” This was an argument similar to the one that carried the day when the Apache Software Foundation moved the JSON License to Category X. In a nutshell, the argument is this: If our conservative customers won’t like it, we don’t want it.
The Apache Foundation recently updated their page that contains information about licenses to include the following:
“Nonsensical licenses. These licenses while amusing to their creators are legally problematic. They often include subjective Field of use restrictions e.g. ‘Don’t be evil’ with no arbiter for that subjective restriction defined. In some cases they may not even grant sufficient rights to conform to the OSI open source definition. Since we do not wish to surprise our downstream consumers we forbid the use of such licenses.”
By being sensitive to their customers’ needs and concerns, the Apache Software Foundation continues to be one of the most trusted sources of software there is. Their legal group sweats the details so their customers don’t have to. It really matters. And they are not being d***s.
Get the latest Software Integrity news, thought leadership, and more.