Notice by Hyperlinkcan’t we just link to the licenses file for our JavaScript?
Open licenses for software almost always say that if you share a copy of the software, you have to share a copy of the license terms, too. When the vast majority of these licenses were written, “software distribution” inevitably meant copying software to physical media and shipping in the mail. Including the license with the software meant copying to the media or printing out and stuffing in the box. Newer licenses largely follow the older ones, because that’s what’s been done.
There wasn’t any unified, worldwide Web of documents to point to when all this was “decided”. There was no mass-consumer Internet. Now there is. It now makes just about as much sense to link to license terms as to copy them, modulo link rot and permalink stability. Sometimes it makes more sense.
Apps and OS developers typically don’t sweat the space for a plain-text file of license terms they can show deep in settings or behind some little-known line-item in the help menu. But when the software is client-side script and distribution is putting on a web server, there’s often a genuine performance concern. Very few who visit are going to want duplicate souvenir copies of common open source license terms. Sending them to everyone else preemptively means slowing their cold load experience, even if the boilerplate compresses very well. All of these visitors clearly have the means to click a link and download a separate text file. Can’t we just put the URL to the licenses file in a comment at the top of the script, or in the page footer?
Let’s look at the license language. There is no mysterious lawyer jargon here the average coder can’t understand. Just a lot of cobwebs.
The MIT License says:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
“Include in a copy” doesn’t sound very forgiving. If you asked me, lawyer guy, what an MIT dependency requires from your JavaScript app, and I told you “include the license in the software”, I suspect you’d hear “copy it into a header comment”. That’s about the best we have to go on.
Now the BSD licenses:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
This seems to assume the license appears in a source comment in the first place. Not, say, in a LICENSE file elsewhere in the repo. But it feels way too legalistic to conclude that finding the license in NOTICE or README instead of in the source means you don’t have to “retain” the license at all. The purpose, in context, is clearly that copies of the software, source or binary, need to come with the license terms.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
This seems to assume a material, i.e. tangible, distribution. Again, this made perfect sense when software “distributions” were shippable, shelvable boxes or jewel cases. As for referencing, rather than copying, we’d have to read “reproduce” really loosely to mean anything but “copy”. The drafters simply didn’t anticipate the question.
Well, how about a much newer license? Tradition prevails. Take Apache 2.0:
You must give any other recipients of the Work or Derivative Works a copy of this License
“Copy of”, not “reference to”. Looks like bad news. And there’s more:
If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.
Apache 2.0 separates the fixed text of the license terms from copyright and other project-specific notices. But it requires copies of both.
Finally, GPLv2 says, among many, many other things:
You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
There’s that word “copy” again. Elsewhere, GPLv2 speaks specifically in terms of offers. A link could be an offer. But “offer” doesn’t appear in the requirement above. You’re supposed to give the license when you give the software.
Had enough? Now compare Blue Oak 1.0.0:
You must ensure that everyone who gets a copy of any part of this software from you, with or without changes, also gets the text of this license or a link to https://blueoakcouncil.org/license/1.0.0.
Blue Oak acknowledges that links to license terms are a thing. It specifically allows them. It can do that with a permalink because it avoids having any copyright notice or other text that licensors have to fill out or customize. That makes the license a fixed, standardized text, like Apache 2.0. But unlike Apache 2.0, there’s no NOTICE file or other mechanism for the customized copyright notices. They’re unnecessary.
All this clarity sure is nice. I’m glad to have contributed to a license that doesn’t just perpetuate the problem. But Blue Oak getting this right doesn’t help older licenses…or people using software stuck under them.
So what to do?
In practice, context matters. Could a highly motivated software licensor argue that distributing their JavaScript without the license terms in a code comment violates the conditions of their MIT or BSD terms, killing the license, resulting in breach of contract or copyright infringement? I think they could. Colleagues I respect share this view, and worry about potential abuse.
But would someone making this kind of legal claim actually win? I doubt it. Courts don’t like to bend language, but they’re more than capable, given the motivation. I suspect it would be very hard to make a claim like this without appearing the paragon of pettiness.
I struggle to think of circumstances where the difference between getting license terms in the same HTTP GET or one more, after a link click, really seems significant, in light of the public policy behind intellectual property law. If someone’s bringing a lawsuit anyway, that implies they may be more interested in leveraging the pain of the process, and whatever legal uncertainty they can find, to scare people into signing settlements.
There’s an old legal get-rid-of-lawsuit card, so transparently simple judges defensively keep it in Latin: “de minimis non curat lex”, the law does not concern itself with trifles. The difference between a license comment with a URL and a license comment with the license text and copyright notice feels pretty darn trifling to me. But it’s not going to be fun wondering and waiting for a judge to actually write that in a decision closing a case where you’re defendant.
In the end, I doubt any well-read lawyer would say there’s no legal risk. The old licenses say what they say, and what they say isn’t terribly helpful. But pretty much anyone who can figure out the keyboard combo for Dev Tools can see that thousands of companies are serving their JavaScript license notices separately, or not at all, and apparently getting away with it. Takeaway? If you choose to play those odds, you certainly won’t be alone. Just don’t come to me if someone goes “troll” and tries to squeeze you for a settlement check.
Open software licensing stands on dozens of rickety old piles. The terms are decades old, and the approaches they implement were in many cases old even when they were written. We laugh at the government’s desperate pleas for COBOL help, but cool, new software will come out tomorrow under legal terms about as fresh. Until we normalize a way to field-upgrade legal terms for long-lived projects over time, beyond just dumping it all in a foundation, we’re just going to have to wait until something we’re standing on crumbles.
Your thoughts and feedback are always welcome by e-mail.