High on my list of Things That Annoy Me When I Hack is sourcefiles that contain huge blobs of license text at the top. That is valuable territory which should be occupied by a header comment explaining the code, not a boatload of boilerplate that I’ve seen hundreds of times before.
Hackers have a lot of superstitious ideas about IP law and one is that these blobs are necessary for the license to be binding. They are not: incorporation by reference is a familiar concept to lawyers and courts, it suffices to unambiguously name the license you want to apply rather than quoting it in full.
This is what I do in my code. But to make the practice really comfortable for lawyers we need a registry of standardized license identifiers and an unambiguous way of specifying that we intend to include by reference.
Comes now the Software Package Data Exchange to solve this problem once and for all. It’s a great idea, I endorse it, and I will be using it in all my software projects from now on.
Here is what the hacking guide for NTPsec now says on this topic, lightly edited to remove some project-specific references:
We use the SPDX convention for inclusion by reference You can read about this at
When you create a new file, mark it as follows (updating the year) as required:
/* Copyright 2015 by the NTPsec project contributors
* SPDX-License-Identifier: BSD-2-Clause
*/
For documentation:
// Copyright 2015 by the NTPsec project contributors
// SPDX-License-Identifier: CC-BY-4.0
Modify as needed for whatever comment syntax the language or markup uses. Good places for these markings are at the end of an extended header comment, or at the very top of the file.
When you modify a file, leave existing copyrights in place. You may add a project copyright and replace the inline license with an SPDX tag. For example:
/* Copyright 2015 by the NTPsec project contributors
* SPDX-License-Identifier: NTP
*/
We recognize that occasionally a file may have changed so much that the historic copyright is no longer appropriate, but such decisions cannot be made casually. Discuss it with the project management before moving.
This sounds like an open source movement for the legal community.
How do you submit a license to be added to the list? I noticed there is a couple meant to be applied to documentation. I was thinking that the Open Game License needs to be added as there is a couple of open source projects using it for Tabletop Roleplaying Utilities. Mainly as the license for their data files.
The OGL is found here
http://www.wizards.com/d20/files/OGLv1.0a.rtf
I found it, the text was a bit tiny for my monitor.
How to tag GPLv2 or later?
@Jakub by adding a “+” at the end. See the bit at the bottom of the page under “deprecated licenses”.
I think another superstition – if it is a superstition – seems to be that all code that goes into a binary has to be under the same license – and therefore, “relicensing” BSD/X11/PD code under the GPL (as in the Atheros dispute mentioned in the other thread you linked) is necessary if you want to incorporate it into a larger program (such as the Linux Kernel).
Certainly closed-source Unix vendors have never had any problems “relicensing” BSD code into their proprietary licenses.
@Daniel Franke – it’s “deprecated” for a reason. Though it’s disappointing that they don’t have any easy-to-find examples of this new “license expression syntax”.
A license exception to the effect of “May be relicensed under any later version of the GPL published by the FSF or its successors” is nowhere to be found at http://spdx.org/licenses/exceptions-index.html either.
I’ve got a sneaking suspicion they think the use case can be addressed by something like “GPLv2 OR GPLv3”, but that doesn’t include the (currently nonexistent) GPLv4.
> incorporation by reference is a familiar concept to lawyers and courts
Whud’ya know – legal types understand
# include "license.txt", too!@Random832 “GPL-2.0+” is both the old and the new syntax for “GPL 2 or later”. In the old (deprecated) system it was a special identifier. In the new syntax it’s an instance of the general rule that you can append a “+” to indicate “or any later version”.
Why is it necessary to include a notice on every single file? It’s an extra 2-3 lines duplicated in every file for no good reason, which also have to be updated on the first edit to that file in each calendar year. And what if I refactor by moving, splitting or merging files – does the copyright year change just because the filename did?
Many projects have a single LICENSE file and only a few references in e.g. the main docs. Is that really legally problematic?
Also, pity the poor Java coders (I’m not one) whose silly language forces each class/interface/enum to be in a separate file, creating many tiny files not much larger than the copyright attribution…
@Daniel Armak I think the concern is that someone may find the file in isolation and not have an obvious way to identify what copyright information belongs with it. This was more of a concern before 1989, when such a file might have been considered to be “published without a copyright notice” and therefore in the public domain.
@Random832 if the file is found in isolation without a copyright notice, then copyright-by-default law means it can’t be used at all: it’s the most restrictive license possible. So the person who found the file would need to track it down to its source project; I’d argue this would be a good idea in any case of seriously using existing code, to be able to track the upstream.
And someone who deliberately publishes (emails, copies to their own code, etc) a file meant to be used separately from its repository should include or reference the license and hopefully attribute the original source.
Incidentally, I have to ask about another common superstition – that of (c) being an invalid copyright notice. I do have to wonder: was there ever an actual court case of a work whose copyright notice was written with (c), or some sort of raw markup such as \(co, ©, etc – and was thrown out as being an invalid copyright notice and therefore in the public domain?
> copyright-by-default law
Did it occur to you there might have been a reason I said “before 1989”?
Likewise, even if the use a properly formed © or fully spelled “Copyright” [often when this claim is made “Copr.” is considered an acceptable substitute and therefore should be used when translating text containing U+00A9 into ASCII] was ever required to have a legally valid requirement, it obviously also ceased to be so in 1989. But the 1970s and 1980s would have been the legal landscape in which these superstitions were formed.
I noticed that, and meant to implicitly ask: why then are we recommending/supporting this usage today?
Because in today’s landscape, if you can’t find the original source, you can’t use the code if it doesn’t identify the license or at least the copyright holder (who you can then contact for license information).
Is it at all common to find a piece of code, nontrivial enough to want to use it as-is and to worry about copyright, which used to be a part of a larger project, and not be able to trace where it came from? I don’t remember it ever happening to me. So I tend to side with removing the burden on the code maintainer of the per-file notices. I don’t include such notices in my own projects, and anecdotally, it seems to me that most smaller projects don’t do so – and those are exactly the projects that might be hard to track down.
Is my experience atypical?
Modern tools make different methods of working a lot more practical. Adding a license is only part of the picture where scripted codebases are involved. While the DVCS replaces the need to version stamp in every file, on the other hand doing so for a distribution set also has a place, and if that stamp tags a version information file, THAT is where I would expect to find any license and other legal statements?
I’m in the “don’t copyright every file” camp. There are a number of reasons for this.
A big part of it is a general principle that we should all do things the technically sensible way until there’s a very strong and specific reason to do otherwise. Software development has plenty of challenges already without needing artificial handicaps like extra noise added to each file.
Another part is what Daniel says above, that it appears to be rare that copyright *notification* is a major deal in an infringiment case. In any realistic scenario I can think of, it’s very unlikely that people will have a major dispute about where a given chunk of code came from. As other commenters have said, you can’t really use *any* copywritten data, code included, until you establish where it came from.
Another part is a little technical: what makes files the right granularity? Why not individual directories? Why not definitions inside the file? Why not each line of code?
Speaking of which, file copyright headers are not binding anyway. That’s right! Just because a file says it is owned by ___ and is available under license ____ doesn’t mean that either of those is true. To establish legal rights around a file, you need to have clearly established authorship logs as well as records of any legal documents that might be relevant, e.g. employment contracts that might cause a file to be owned by the author’s employer rather than the auther themself.
On top of all that, the given example, as well as the recommended solution, is for open-source code. For open-source code, I know opinions differ, but I feel it is best to give away the code pretty freely. Instead of planning to exploit the code itself, try instead to treat it as evidence of what you are capable of. If the code does get picked up, then there will be a demand for maintainers of that code, and that’s where you can get leverage to start charging ongoing fees.
Here begins my hate for Our Corporate Lawyers.
At my company, we have a *huge* source tree. I’d estimate as a lower bound estimate roughly the size of KDE. A full build takes a dozen or so build servers ~40 minutes to complete.
We use a revision control system where check-ins require authentication. This means that every single piece of our source code (absent a malicious attack) can be traced back to a particular user.
The lawyers require that every file have a copyright notice in it similar to the one Eric suggested above. The difference is that it must be a year *range*. The result is that for all of January, about half of the lines changed in every check-in consist of updating the copyright year. Legal doesn’t want this to be automated (because it could be asserting copyrights on stuff which isn’t eligible for copyright protection), and won’t let us stick with the initial data plus repository information because it shows a lack of dedication to effectively maintaining copyright protection.
@Garrett Why would half of the lines changed in every check-in consist of updating the copyright year even under those conditions? You should only be updating it on files you actually changed in that year, so unless every single change in the year was a one-line change to a file which was never edited again in that year, it should be substantially less than half.
Allow me to add a little bit more background.
ESR has mentioned in passing a couple of times, I am the PM for the NTPsec project. My actual paying day job, in part, is to “know the people who know the things” about open source stuff, including open source license wankery. I actually work day to day rather closely with real actual passed-the-bar practicing attorneys who specialize in IP and software license law, and who do understand open source. Places where they don’t understand open source, at time I get to educate them, and in the many places were I don’t understand law, they get to educate me.
I asked some of those coworkers, and some well known in the industry open source license experts, and some other people who work in some other corporate open source programs offices, and some people at some open source foundations, about past/current/forwardlooking/& bestpractices for this stuff, and then wrote the first draft of the policy that ESR then rewrote into the project policy docs and then rewrote again for this blog post.
I knew about SPDX because I quite literally randomly picked it as a session to attend at LinuxConfUS Seattle this year. I regularly attend a couple of sessions per conference that I pick off the schedule board, that I pick because when I read the title and abstract, I have no idea what it’s about.
The Linux Foundation is immeasurably invaluable. SPDX is a LF working group. Other WGs and WGs-in-formation form a lot of the invisible scaffolding under all this work.
As many of you point out upthread, it would be nice if we could completely eliminate all this text from source files, and use only the source control metadata and well known community practice. I would like that too. However, doing so remains unwise, because in the worst case likely situation, someone like very much like me gets to explain to a geriatric judge who’s use of computers consists of his clerk printing emails out for him to read, who got randomly selected to preside over a copyright case unlike any he has ever seen before and has almost no useful precedent, what “git blame” is, and how it works. I know it’s going to happen to me sometime in my career, and I’m not looking forward to it.
Anyway, situations still happen when files become disconnected from their source control metadata. Especially when they get ingested into the courts, and especially when someone is trying to pull something underhanded.
And, always always, there is what treaties and the text of the law says…
And then there is working the actual coalface of overworked courts, busy lawyers who patternmatch their way through a day to day grind of proprietary license corplaw, and and knowing that most people are not harboring malice, but there are people spread through the system that do.
I wish it was better. It’s better than it was even last year, let alone as bad as it was 25 years ago. Best working practice will be even better next year, and hopefully, it will be significantly better in another 25.
In the meantime, if anyone else has some really strong system programming chops, and some time to donate, please ping ESR or myself…
>In the meantime, if anyone else has some really strong system programming chops, and some time to donate, please ping ESR or myself…
I’m going to take this opportunity to observe in public that Mark is the kind of manager most programmers wish they had. He makes good decisions, he makes fast decisions, and he doesn’t insert himself where he doesn’t need to be.
With him there are now four A&D regulars on NTPsec, counting myself and Daniel Franke and Susan Sons. Not so surprising, I guess, considering the kind and caliber of people this blog attracts.
But officer, I don’t need a DMV issued license, #include
There’s no problem with however big license blobs in modern editors, aka IDEs. They fold/expand them automatically, like imports list. They also can automatically add the license you like, and automatically inspect for files without license.
Never a license caught my attention, it’s 2015 FCS!
Legality is societal entropy. Very difficult to tame, and it never disappears entirely. Nevertheless, SPDX is a worthy effort. I wish you success.
@Dzmitry auto-insertion of notices like that is exactly what legal departments like Garrett’s worry about. Or: imagine explaining to a geriatric techonophobe judge that a copyright notice is valid even though it was generated by a machine and never read or seen by a human, because it was always autocollapsed.
kill-a-lawyer.el could use an update and maintainer.
https://github.com/emacsmirror/kill-a-lawyer/blob/master/kill-a-lawyer.el
Hi Eric,
Thanks much for the post!
To answer a couple questions in the comments:
1) if you want to request a new license be added to the SPDX License List, see: http://spdx.org/spdx-license-list/request-new-license
2) the license expression syntax explanation is part of the SPDX specification, see appendix IV: http://spdx.org/SPDX-specifications/spdx-version-2.0
3) Matt Atwood (and others) hit some good points as to why having license info in every file is helpful, but the other reason I don’t see discussed here is this: if you sell software, your customers will want to know what open source software is included in your software. This is especially true along the supply chain. When doing the internal diligence to come up with this information, if you cannot figure out what the license is, you will simply not use the code. So, being able to discern this info in a reliable and consistent way at the file level is important far before (or even if you never) end up in a court of law.
Lastly, the SPDX workgroup are always welcome to new participants :)
– a great way to keep tabs on the effort from a high-level is to get on the general mailing list: http://spdx.org/participate/general-spdx-meeting
If anyone is interested in progress with the SPDX License List, the legal (not all lawyers) team that maintains that and there is some interesting work underway right now (see: http://wiki.spdx.org/view/Legal_Team – particularly the meeting minutes)
Thanks much,
Jilayne
SPDX legal team co-lead
There are also matching guidelines that go with the SPDX License List, which people may be interested in, they are available here: http://spdx.org/spdx-license-list/matching-guidelines
4)
Wow yes, kill-a-lawyer.el really could use an update.
First of all, there is now a well maintained and nearly canonical set of cascaded regex’s to recognize many more FLOSS licenses.
How does this apply to BSD licences which aren’t in effect, but which only have to be quoted? That’s a common interpretation of the BSD licence – that the text of the licence itself has to be copied, but the licence isn’t in effect. That’s how closed-source software can incorporate BSD-licensed code without the closed-source software, or any part of it, being licensed under the BSD licence. Article here about this: http://www.groklaw.net/article.php?story=20070114093427179. (The best argument I’ve seen in favour of the common interpretation is here: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-80003.2 “This understanding represents the uninterrupted, longstanding practice and expectation of the global information technology industry, including both its free and proprietary divisions, with vast commercial reliance on the result. As such, disruption of the established interpretation of the permissive licenses is neither likely nor desirable.” As ever, the law doesn’t have to agree with your common sense.)
If you replaced somebody else’s licence notice that was not in effect, you wouldn’t be “incorporating it by reference.” You’d have to decide whether you were satisfying whatever requirements the copyright holder had placed on the licensing of their work by doing so. These copyright notices don’t seem to do much other than give credit to the authors. In the case of closed-source software the preserved notices aren’t next to the source code, so if you think these notices are annoying and useless, one thing you could do is have a file in your project with all of the notices copied into it. That’s just an idea, though – usual warning about not being a lawyer applies.
PS I find licensing discussions really boring.
The relevant clause of the BSD license reads in full: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
I’m not a lawyer, but I don’t see why including it in a file in the distribution (vs copies in every source file) wouldn’t satisfy it.
Hm. Something just struck me. Whenever I’ve seen something incorporated by reference, it’s always been explicitly stated that that was what was being done. That would seem to mandate a tag of the form:
/* Copyright 2015 by the NTPsec project contributors* License incorporated by reference: SPDX-License-Identifier: BSD-2-Clause
*/
So NTPSec uses the two-clause BSD license, whereas Eric’s personal projects generally use the three-clause one. Unless it’s deemed untimely or conducive to flame wars, I’d like to know the reasons people have for using one or the other. In other words, why do some developers worry about potential endorsement-related issues and others don’t?
I’m afraid my reason for using three-clause BSD is really boring – the two-clause version had not been promulgated when I took the copy I clone from. Thanks for reminding me that I should upgrade my projects.
And if your current discussions come to some acceptable solution that the lawyers are also happy with, then would be the time to change :) Is there any reason to change what is used on older projects which just get bug fixes?
As someone that looks everyday on software licenses, can say that having a LICENSE file and including the license on source code headers is a good help as too often code gets mixed from different sources and different licenses.
If not possible or simply too much work for changing source code headers, I recommend looking at the ABOUT file format to describe licenses. This what we’ve began using to address the case of binary files, which are not simple to tag with licenses: http://nunobrito1981.blogspot.de/2015/10/about-format-to-document-third-party.html
Maybe this is a good place to squeeze in a question I have long had on the issues of alternative BSD licenses, and about superstitions about the law: One of my pet peeves as a reader is that so many licenses, including all of the BSD licences, YELL THEIR DISCLAIMERS OF WARRANTIES. Why didn’t the drafters just state them in their inside voices, using conventional (non-) capitalization? Is there any precedent in American law where the upper-casing vs lower-casing of legal language made a difference to the outcome of a case?
>Is there any precedent in American law where the upper-casing vs lower-casing of legal language made a difference to the outcome of a case?
I don’t know, but I do know that this carries over a custom I’ve seen on printed licenses. I think it’s become a traditional observance to make a document look “legal”, what linguists call a register signal.
Or how about stating the reference explicitly, like so?
/* Copyright 2015 by the NTPsec project contributors
* BSD license terms apply: http://spdx.org/licenses/BSD-2-Clause-FreeBSD.html
*/
>Is there any precedent in American law where the upper-casing vs lower-casing of legal language made a difference to the outcome of a case?
Yes, US law says it should be conspicious for a reasonable person. But, no, it is not required to be all capitals. However, there is little choice if you are limited to straight ASCII text. And I think lawyers are not very creative when there is a risc the court will differ in their perception of “conspiciousness” of the new design.
Does Any Law Require All Capitals?
http://www.adamsdrafting.com/all-capitals
Why are Warranty Disclaimers in ALL CAPS?
http://www.mslater.com/post/104847-why-are-warranty
Thanks, Eric and WInter. That was interesting and useful.
>High on my list of Things That Annoy Me When I Hack is sourcefiles that contain huge blobs of license text at the top. That is valuable territory which should be occupied by a header comment explaining the code, not a boatload of boilerplate that I’ve seen hundreds of times before.
Is it very much against the hacker style that it is the editor, EMACS in your case, that should be hiding / collapsing low-priority text areas? Not saying it is the idea way to solve this particular problem, but just as a general attitude to deal with boilerplate. See also XML comments (mostly a Microsoft thing, and maybe ugly, but lends itself well to collapsing.)
>Is it very much against the hacker style that it is the editor, EMACS in your case, that should be hiding / collapsing low-priority text areas?
It’s a good idea, and already exists: kill-a-lawyer.el. But I prefer attacking diseases to masking their symptoms.
To the likes of Eric it’s more hackerly to eliminate the boilerplate entirely, rather than keep it in there and rely on your editor to fold it away.
Most devs use IDEs these days, so to them it’s six of one, half a dozen of the other.
I think “SPDX-License-Identifier” should be “SPDX-License-Expression”.
Technically a SPDX license identifier can only refer to a single license text. A SPDX license *expression* supports various useful modifiers, such as “(GPL-3.0+ WITH Classpath-exception-2.0)” and “(MIT OR BSD-3-Clause)”. Yes, you could follow the tag “SPDX-License-Identifier” with an expression, but it seems cleaner to use the precise terminology.
So… please s/SPDX-License-Identifier/SPDX-License-Expression/g.
Also: I have a draft SPDX tutorial here: https://github.com/david-a-wheeler/spdx-tutorial/