JSHint: Asking Nicely

This is the third essay in a four-part series about relicensing the JSHint software project.

Despite initial appearances, relicensing JSHint involved much more than modifying a single text file. The LICENSE file is just the technical representation of a legal contract, and the consent it describes is not something you can patch in a text editor.

Specifically, we wanted to remove the clause, “The Software shall be used for Good, not Evil.” It’s a pretty ridiculous statement, so ridiculous that we were tempted to simply strike it without justification. Because really, could anyone actually take use to court?

The “Good, not Evil” clause is intended to mock the practice of software licensing. It’s ironic that respect for the very same practice is what drove us down this path. We held the JSON license to a standard which it tacitly rejects. It would have been immensely easier to apply the same glib perspective and simply remove the clause without explanation… But if we did that, we’d not only be subverting the wishes of the original author; we’d be subverting our own principles.

The creator of JSHint put it in much plainer terms: “I don’t want to be a douchebag. :-)”

In this essay, I’ll discuss why we ruled out a complete project rewrite, what it looked like to request permission from the project’s contributors (over 200 people, all told), and how we came excruciatingly close to achieving that goal.

Forget a rewrite

The license only applies to “copies or substantial portions” of JSLint, so one way forward would be to just rewrite the whole darned thing. If we created a new project from scratch, then we could license it however we wanted. Such a “clean break” would be far less controversial (not to mention less confusing) than changing the terms of existing code. Unfortunately, JSHint’s size and complexity made this unappealing in more ways than one.

First and foremost, the effort itself would be substantial. Just writing a JavaScript parser is no small task, let alone one that can speculatively detect and report suspicious patterns.

Beyond that, my other priorities made releasing a rewritten project much more risky than strictly necessary. For reasons I discussed in a previous essay, I wanted to publish the relicensed project on the well-established “version 2” channel of JSHint. No matter how careful you are (or how many tests you have), you are bound to introduce new bugs when you rewrite code. When sharing rewritten software with the world, most maintainers increment the major version of their project (e.g. from “4.7” to “5.0”). That sends a clear signal to developers: “take care when upgrading.” By bucking this trend and publishing drastically different code with the same major version (e.g. “2.11” to “2.12”), I’d be sure to surprise a lot of developers with unexpected errors.

If, on the other hand, we had permission from the people involved in the contract, then we could keep the code. Would it really be easier to contact those people and convince them to give us permission? Like apples and oranges, there’s no obvious basis for comparison between programming challenges and social organizing efforts. It’s possible that rewriting would have been easier, but that’s not clear even in hindsight. That’s why we decided to seek out approval.

The source of the problem

As the author of the license terms, the creator of JSLint has the power to change the project’s license and to permit others to do the same. With their permission, we could avoid a lot of the hassle.

Except that the terms of the JSON license are no accident. The author chose them intentionally, and they’ve been very public about their continued confidence in this decision. Even so, we reached out specifically regarding JSHint. We received the following response:

The license must remain in all copies and derivative works.

For all of its improvements, JSHint still started from JSLint, and there’s no denying the influence that the creator had on its source. Their refusal to budge all but tanked the effort.

That is, until Simon Kaegi of the Eclipse Foundation discovered a version of JSLint that was distributed under the terms of the MIT Expat license. Through a private negotiation, the foundation had received permission from the author of JSLint to include the code using the FOSS license. Although we weren’t privy to the particulars of the discussion, the proof was in the software: version 0.2.0 of Eclipse Orion included an MIT-licensed version of JSLint.

It took a little doing to “inject” the unencumbered version into the project’s history, but I won’t get into that here. If you’re curious, you can check out the technical summary of the rewrite.

This was a big step, but we still had many more to take.

One more thing

When folks submit code to free and open source software (FOSS) projects, they typically own their contributions. Even though we’d found an Expat-licensed version of JSLint, we still had to respect the desires of all the people who had built on the JSON-licensed version. Local lawyers Joel Kinney and Steven Ayr helped me understand this. Steven wrote,

[…] some contributor may have only contributed to the project because they knew that a few hundred lines of code pulled from JSLint had the “No Evil” clause attached to them. I don’t think either of those arguments make a lot of sense, but [JSLint’s creator] is himself a good reminder that sometimes there are people who take very specific and very rigid stances in ways you wouldn’t necessarily expect

This might sound like a stretch, but once you’ve donated time and energy building on someone else’s work, it’s only natural to hold a vested interest in its direction. In this posting to the net.emacs newsgroup, FOSS contributor Fen Labalme describes how the maintainer had betrayed their trust:

As one of the ‘others’ who helped to bring EMACS [GOSMACS] up to speed, I was distressed when Jim sold the editor to UniPress. This seemed to be a direct violation of the trust that I and others had placed in Jim as we sent him our improvements, modifications, and bug fixes. I am especially bothered by the general mercenary attitude surrounding EMACS which has taken over from the once proud ‘hacker’ ethic–EMACS is a tool that can make all of our lives better. Let’s help it to grow!

We wanted to get permission from JSHint’s contributors to avoid putting anyone in this position.

Fortunately, there is a well-known process for FOSS contributors to reassign ownership: the Contributor License Agreement, or “CLA” for short. By the time we realized we would need one, JSHint had already accepted patches from over 200 people. The prospect of organizing so many people was pretty discouraging, especially considering that some hadn’t engaged with the project in years. A few details kept it from being fatal:

• only one file in JSHint needed to be relicensed, so we only needed consent from folks who had modified that file
• contributions that were “non-substantive” (e.g. correcting typos or adding references to standard interfaces) were not original creative work and could therefore be relicensed without permission
• people are empathetic and generally want to cooperate (and as contributors to a FOSS project, this group had already proved as much)

First thing’s first: we needed a stopgap for contributions moving forward. The JSHint project adopted a CLA, and we integrated the open source CLAHub tool to help operationalize the new requirement for signatures. It wasn’t quite production ready at the time, so I helped fix some bugs, first (can’t say I expected to be contributing to a Rails application as part of all this).

Next, I e-mailed all the contributors. To my surprise, most of them responded within a week. A few had changed e-mail addresses, but we found their new addresses without trouble. An even smaller number challenged the premise of the effort (I got pretty good at cutting through the absurdity of it all), but only one refused outright. Everyone else signed, and many responded with well-wishes, sympathy, thanks, and offers to help even further. That was an unexpected inspiration.

Unfortunately, there was one non-respondent who we couldn’t find another way to contact. This person had been particularly prolific, but six months prior to our signature drive, they stopped submitting patches. Their activity on GitHub.com also ceased.

Despite my best efforts (and trying to balance respect for privacy against belief in this cause), I wasn’t able to contact this person. This was initially concerning because their consent seemed critical for the relicensing effort. As months went by, concern gave way to deeper worries about their well-being.

This predicament highlighted an aspect of free and open source software development which I’d never considered before. FOSS developers commonly retain ownership of their work, and many of us take it for granted that this is not only fair but desirable. For the first time, I recognized the responsibilities inherent in this, and I began to question whether I wanted them. I’d hate for my unavailability to block an effort I would otherwise support.

Karen Sandler at the Software Freedom Conservancy has spoken about this in the past. Four years ago, there was no easy solution for bequeathing FOSS copyrights, but she was hopeful that she could find an answer. (In the meantime, Conservancy has been running the Debian Copyright Aggregation project–a heck of a perk for Debian developers!) If all you take away from this silly adventure is an awareness of these issues, then I’ll be satisfied.

We ultimately gave up on this signature and (sorry to say) the person behind it. There was simply nothing we could do to help or even contact them; we could only hope for the best and move on. That meant seriously considering the only remaining alternative: rewriting code.