The world of open source tooling has expanded to welcome JSHint, as the project’s maintainers have finally completed the necessary work to adopt the MIT Expat license. Previously, the JavaScript linter’s code was partially published under the JSON license, with an additional seemingly innocuous clause that stated: “The Software shall be used for Good, not Evil.” This clause prevented it from being recognized by FSF as a free software license and similarly was not recognized as open source by the Open Source Initiative.
In an essay titled Watching the Ship Sink, JSHint co-maintainer Mike Pennisi describes how the license hurt the project. Despite having captured the distinction of being the most popular JavaScript linter in 2015, the tool has been brutally outpaced during the past five years by its contemporary, ESLint, largely due to the effects of having non-free licensing.
“Legally-conscious objectors aren’t betraying their own dastardly motivations; they’re refusing to enter into an ambiguous contract,” Pennisi said. “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.”
Licensing concerns prevented developers from the Debian and Fedora GNU/Linux distributions from including JSHint. Pennisi even dips into a bit of WordPress history, when he detailed how programming platforms that “repackaged” JSHint also reconsidered due to its additional clause.
“There was a time when the popular content management system WordPress repackaged JSHint in this way,” he said. “Once they learned of the JSON license, they replaced JSHint in a matter of weeks.” Pennisi referenced a ticket for WordPress 4.9 wherein JSHint was removed from core’s implementation of CodeMirror, as well as WordPress’ build tools.
“When a project like JSHint loses users, it also loses contributors,” Pennisi said. “This slows the addition of new features and the correction of bugs. Timeliness is important for these things, and people perceive delays very negatively. The best example of this comes from JSHint’s delayed support for async functions.”
JSHint had become what Pennisi described as a “bizarrely-encumbered JavaScript linter.” Unfortunately, the process of going open source after seven years was not as simple as submitting a pull request for a license change. In a series of essays, he unfolds the grueling process of requesting permission from all of the project’s 200+ contributors, only to end up receiving one refusal and some who weren’t available for contact. Ultimately, the JSHint team was forced to rewrite the source code but only for the parts that were contributed by the five people who had not permitted the license change.
At the beginning of August, JSHint updated to use the MIT Expat license in version 2.12.0 and is now GPL-compatible. Pennisi’s cautionary tale of what he called “the liberation of JSHint” is a fascinating read that details the struggle of overcoming the challenges of the project’s original license. The key takeaway from this story is that software creators should strongly consider the ramifications of licensing up front, even if a large community of users seems unimaginable at first. Open source licensing takes a project further than its creator could ever have brought it alone.
“For many people, licensing is an esoteric part of software development,” Pennisi said. “It’s a relatable opinion: the legal frameworks are intimidating, and most considerations can be addressed by simply defaulting to well-known free/open-source licenses.
“The trouble is that not all software is distributed under well-known free/open-source licenses. My hope is that the particulars of JSHint’s decay help folks understand why licensing matters.”