This is the third essay in a four-part series about relicensing the JSHint
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
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
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
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
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
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
(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
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
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.