How JSHint learned the hard way not to use ethical source licensing

The so-called “ethical” licenses like the Hippocratic License seem like such a good idea. These licenses prohibit people from using the licensed software if they “actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of underprivileged individuals or groups.” Blocking evildoers from great software is a very good thing, right?

Wrong. Or, at least, the application is wrong. While I’ve been saying this for some time, it’s perhaps even more persuasive to hear from someone who tried to apply an “ethical” license provision to their software, and discovered the hard way that they’re as ill-conceived as they are well-intentioned. 

Over to you, JSHint’s Mike Pennisi.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Turns out blocking evil is hard

JSHint has been around since 2011, with a provision in its otherwise open source license that says something pretty unobjectionable: “The Software shall be used for Good, not Evil.” Interestingly, Pennisi wanted to shift away from the non-free “do no evil” license, but it took seven years to get from that determination to the relicensing of the code under the MIT Expat license. During that time, JSHint lost its place as the most popular tool in its category to one that “most developers today consider antiquated,” Pennisi said.

Oof. How did the ethical license provision hurt the community, and why did it take so long to reverse course?

The first problem with the license is ambiguity. The licensor might know exactly what she means by “evil” (though I suspect most hard-and-fast perspectives would struggle to provide clear guidance for edge cases), but the licensee does not. Pennisi wrote in his JSHint: Watching the Ship Sink post:

Because of this [“Good, not Evil”] clause, folks who respect the practice of software licensing simply could not use JSHint. If you’re not versed in legal matters, that probably seems like an odd restriction. By rejecting JSHint, are people admitting that they want to do evil? And is that clause actually enforceable, anyway?

The answer to the second question is “no,” and that helps answer the first question. Legally-conscious objectors aren’t betraying their own dastardly motivations; they’re refusing to enter into an ambiguous contract. Put differently: they’re not saying, “I’m an evildoer,” they’re saying, “I don’t understand what you want.” This consideration disqualified JSHint from inclusion in all sorts of contexts.

The tl;dr? “Fewer people [using this] bizarrely-encumbered JavaScript linter,” noted Pennisi. For a project like JSHint, where those who use the code are the same people with the talents to improve that code, losing users means losing contributors, said Pennisi. This, in turn, led JSHint to fall behind alternative options for JavaScript builders. In turn, he went on, “A dwindling user/contributor-base is a vicious cycle. Though the movement may have started with license-conscious folks, everyone felt the pain of the release cycle equally, and their exodus exacerbated the problem.”

Again, it’s not the intention that is wrong. It’s simply that such things are difficult (read: impossible) to apply in practice. As Maish Saidel-Keesing has written, “What is unethical?” is a hard question to answer “or more accurately, harder to agree upon.” 

SEE: Linux commands for user management (TechRepublic Premium)

Whatever your political opinions or your ethics, the best possible chance for your open source project to become great and, hence, get used for great things, is to use a standard open source license. The code should be what matters, not the license. If you use an unfamiliar, unpopular license, you draw attention to (arguably) the least important aspect of your software. Don’t do that. Center the developer’s attention on how great your software is, not how encumbered by an ethical license it is.

Disclosure: I work for AWS, but the views expressed herein are mine and don’t necessarily reflect those of my employer.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications.
Delivered Tuesdays

Sign up today

Also see