LWN: Comments on "SPDX identifiers in the kernel"

SPDX identifiers in the kernel

zack — Sun, 10 Dec 2017 21:36:45 +0000

To be clear, I'm aware of the note about syscall use in the kernel. What I'm wondering is where the SPDX notation makes the link between that exception identifier and its expansion.

SPDX identifiers in the kernel

zack — Sun, 10 Dec 2017 21:35:13 +0000

So where is the actual meaning of "Linux-syscall-note" defined?
It doesn't seem to be one of the officially supported exception of SPDX https://spdx.org/licenses/exceptions-index.html

SPDX identifiers in the kernel

hook — Fri, 08 Dec 2017 10:22:52 +0000

Of course adding the SPDX short identifiers into the code is not a cure-all, but it is a massive step forward for clarity. Especially in a code-base as huge as the Linux kernel.

As for general best practices on copyright and license info, have you checked <https://reuse.software/> yet?

SPDX identifiers in the kernel

nix — Thu, 07 Dec 2017 13:40:25 +0000

It works even less well for languages other than C and languages that have nothing like the preprocessor -- but almost any language you can name has comments.

SPDX identifiers in the kernel

gregkh — Thu, 07 Dec 2017 11:59:30 +0000

It's a common idea, but it doesn't really work well for .h files.

Also, what happens when you combine multiple .c files into a single .o file?

It gets messy very quickly, we tried it. Hence the fall-back to a comment, which works out much better

SPDX identifiers in the kernel

cbcbcb — Thu, 07 Dec 2017 11:51:04 +0000

It seems a shame that these identifiers are written as comments. With appropriate macro definitions you could have

    #include "spdx.h"

    SPDX_LICENCE_IDENTIFIER("GPL-2.0")

And with appropriate definitions, the licence information could be propagated into object and executable files too. This would be useful, as it takes effort to establish which source files have been used in a build, and therefore which licences apply to your binaries.

SPDX identifiers in the kernel

pombredanne — Thu, 30 Nov 2017 14:40:55 +0000

FWIW, I helped a bit with this effort and with my FLOSS tool: https://github.com/nexB/scancode-toolkit which can used anywhere and is not kernel specific

SPDX identifiers in the kernel

pombredanne — Thu, 30 Nov 2017 14:37:56 +0000

Yes, this is exactly what this means.

Don't stop with the kernel, extend it to all software projects

pombredanne — Thu, 30 Nov 2017 14:36:37 +0000

I helped making this happen for the kernel and I am scratching my head on how to make this possible everywhere. I have tools, but that's only part of the story. What would be the way?

SPDX identifiers in the kernel

pombredanne — Thu, 30 Nov 2017 14:34:46 +0000

Did you read the docs? https://lwn.net/Articles/738809/ ?

SPDX identifiers in the kernel, systemd, casync

flussence — Sat, 25 Nov 2017 18:16:55 +0000

SPDX is one of the few universally good ideas I've seen for metadata. Perl 6 switched everything to it earlier this year too; turns out it's much easier to get everyone to agree on a common shorthand for licenses than it is to make everyone use, say, SemVer. In an ecosystem role like that it nudges people away from ad-hoc license proliferation, which is probably a good thing.

I'm not so much a fan of its standalone metadata file format, but I don't think I'm ever going to find a package metadata format that's good - they all gradually expand until they reimplement half of X.509.

SPDX identifiers in the kernel

mtaht — Sat, 25 Nov 2017 01:51:00 +0000

Sigh. Now I need to go update kill-a-lawyer.el.

SPDX identifiers in the kernel, systemd, casync

zuki — Fri, 24 Nov 2017 15:23:02 +0000

I now added SPDX tags in the same format to systemd and casync.

Seems like a good idea, I hope this catches, and e.g. Fedora's licensecheck scripts can be made more reliable.

SPDX identifiers in the kernel

timur — Tue, 21 Nov 2017 14:56:04 +0000

My company requires a full GPLv2 (and v2 only) copyright statement on each file. I don't think that's going to change any time soon. Does this mean that, on new files, we should always also include the SPDX line?

SPDX identifiers in the kernel

compenguy — Mon, 20 Nov 2017 15:27:57 +0000

I'm just going to stop here, because we clearly got different guidance from our corporate copyright lawyers.

I will say that the policy we enacted based on that guidance is very similar to the policies of all the other corporations I've worked with, as well as a wide range of products I've used. I will also direct you to SPDX's own documentation for producing SDPX distribution notices: https://spdx.org/sites/cpstandard/files/pages/files/spdx-...

SPDX identifiers in the kernel

Jonno — Mon, 20 Nov 2017 13:22:25 +0000

>> If the licence text differs, you use a different SPDX identifier.
> The license variants cover the different *terms* of the license, not the variations in copyright statement, nor will they ever.

True, but the problem with the BSD licences are that the *terms* of the licence differs depending on the copyright holder (as the original BSD licence explicitly mentioned "University of California, Berkeley" and other copyright holders replaced that with their own name when they released code under an equivalent license).

For example, the *only* difference between the *terms* of BSD-2-Clause and BSD-2-Clause-NetBSD are these two phrases:

(1) "THE COPYRIGHT HOLDERS" <-> "THE NETBSD FOUNDATION, INC."
(2) "THE COPYRIGHT HOLDER" <-> "THE FOUNDATION"

>> Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
>Templatized or boilerplate copies of the license are insufficient to meet this requirement.

Obviously using SPDX to *identify* the licence does not absolve you of the responsibility to also *comply* with the license. But SPDX license identifiers *can* make it easier to do so.

Consider the following hypothetical project of 5 source files. Note that file01.c and file02.c have different copyright holders and thus different copyright notices, but both are under the same licence, so you only need one copy of the license *terms* (located in the file LICENSE.BSD-2-Clause). However, file03.c is copied from NetBSD and are thus under a slightly different license. Therefore it does not only uses a different copyright notice, but also a different SPDX license identifier and a separate copy of the license terms (this time located in LICENSE.BSD-2-Clause-NetBSD). Note that LICENSE.BSD-2-Clause and LICENSE.BSD-2-Clause-NetBSD only differs by 4 words, but (as you said) some sort of template would not actually comply with either license, and you therefore need to carry both versions. Next is file04.c which is copied from FreeBSD, which is under another slightly different license, and thus a third SPDX license identifier and a third license file. And finally we have file05.c which contains parts copied from NetBSD, parts copied from FreeBSD, and parts written by me, which means that to use this file you need to comply with both the NetBSD license and the FreeBSD license (which fortunately are compatible with each other, you just need to keep both license files around to comply with both of them at the same time). All in total there are 5 source files with a total of 6 copyright notices, but thanks to the SPDX license identifiers we only need one copy each of the 3 license terms.

========== file01.c ==========
// Copyright (c) 2012-2016 Joe Random Hacker
// SPDX-License-Identifier: BSD-2-Clause
...

========== file02.c ==========
// Copyright (c) 2017 Jon Severinsson
// SPDX-License-Identifier: BSD-2-Clause
...

========== file03.c ==========
// Copyright (c) 2008 The NetBSD Foundation, Inc.
// SPDX-License-Identifier: BSD-2-Clause-NetBSD
...

========== file04.c ==========
// Copyright (c) 1992-2012 The FreeBSD Project
// SPDX-License-Identifier: BSD-2-Clause-FreeBSD
...

========== file05.c ==========
// Copyright (c) 2008 The NetBSD Foundation, Inc.
// Copyright (c) 1992-2012 The FreeBSD Project
// Copyright (c) 2017 Jon Severinsson
// SPDX-License-Identifier: BSD-2-Clause-NetBSD AND BSD-2-Clause-FreeBSD
...

==== LICENSE.BSD-2-Clause ====
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

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 SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

= LICENSE.BSD-2-Clause-NetBSD =
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

= LICENSE.BSD-2-Clause-FreeBSD =
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of the FreeBSD Project.

SPDX identifiers in the kernel

compenguy — Sun, 19 Nov 2017 16:54:42 +0000

> If the licence text differs, you use a different SPDX identifier. The SPDX Licence List [2] currently contain 15 BSD licence variants, and more can be added as needed.

The license variants cover the different *terms* of the license, not the variations in copyright statement, nor will they ever.

Look at the link you supplied for the SPDX BSD-2-Clause license. All the text in red is boilerplate that must be filled in with the actual values for the project whose license you're attempting to comply with:

> Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Templatized or boilerplate copies of the license are insufficient to meet this requirement.

SPDX identifiers in the kernel

Jonno — Sun, 19 Nov 2017 11:06:51 +0000

> There could be 12 files, each under the license with the SPDX identifier "BSD-2-Clause", but each of those 12 could (and likely would) have different copyright statements or other additional text. So if they all reference a file named "BSD-2-Clause", how will the correct variant of the data be included?

The SPDX identifier "BSD-2-Clause" refers *explicitly* to the BSD 2-clause "Simplified" License [1]. If the licence text differs, you use a different SPDX identifier. The SPDX Licence List [2] currently contain 15 BSD licence variants, and more can be added as needed.

[1] https://spdx.org/licenses/BSD-2-Clause.html
[2] https://spdx.org/licenses/

SPDX identifiers in the kernel

lkundrak — Fri, 17 Nov 2017 19:55:34 +0000

Unless I'm mistaken the BSDs regularly pull in the DRM subsystem and certain drivers from Linux that happen to be dual-licensed.

SPDX identifiers in the kernel

bfields — Fri, 17 Nov 2017 19:17:02 +0000

I'm having trouble understanding who exactly this is useful to.

Anything in the kernel source tree should be available under GPLv2. So I guess the only reason you'd care about the license on individual files is if you want to incorporate some portion into a more liberally-licensed project? Are there that many of those projects? I must be missing something.

SPDX identifiers in the kernel

compenguy — Fri, 17 Nov 2017 18:59:20 +0000

> The file name is the same as the SPDX identifier and it contains the full license text along with some machine parsable meta data.

I don't understand how that system will work.

There could be 12 files, each under the license with the SPDX identifier "BSD-2-Clause", but each of those 12 could (and likely would) have different copyright statements or other additional text. So if they all reference a file named "BSD-2-Clause", how will the correct variant of the data be included? "cat foo1/LICENSE.txt foo2/LICENSE.txt foo3/LICENSE.txt ... > BSD-2-Clause" probably follows the letter of the license terms, but not the spirit because there's no way to know which entry in that file corresponds with a specific source file.

SPDX identifiers in the kernel

corsac — Fri, 17 Nov 2017 12:21:28 +0000

One could also take a look at the Debian DEP5 proposal (http://dep.debian.net/deps/dep5/) and the machine-readable debian/copyright format (https://www.debian.org/doc/packaging-manuals/copyright-fo...). There's also a differences analysis between SPDX and DEP5 (https://wiki.debian.org/Proposals/CopyrightFormat#Differe...)

SPDX identifiers in the kernel

tglx — Fri, 17 Nov 2017 09:33:37 +0000

Yes, that's in the documentation which is under review right now.

Any SPDX identifier used in the kernel must have a corresponding file under
LICENSES/... The file name is the same as the SPDX identifier and it contains
the full license text along with some machine parsable meta data.

Don't stop with the kernel, extend it to all software projects

rakoenig — Fri, 17 Nov 2017 07:18:33 +0000

Suffering from a coirporate policy that requires a full assessment process for software that contains Open Source components I'm glad to see those SPDX identifiers show up in the kernel. Next step would be to include them as well in all userland software. But yet they are very rare, just download some sources of popular programs and go hunting for SPDX and you won't find much.

If there would be a valid SPDX tag everywhere it would make automation of our ugly process easier. Currently we sometimes invest more effort in the bureaucratic and legally required stuff than in actually developing software.

SPDX identifiers in the kernel

JdGordy — Thu, 16 Nov 2017 23:19:10 +0000

Presumably there would be an implicit "see the LICENSE.TXT for the full text" associated with this tag?

SPDX identifiers in the kernel

sharkhands — Thu, 16 Nov 2017 19:36:34 +0000

How does this work with projects which have short license comments (i.e. "Distributed under the terms of the MIT license") in source files, and then a separate LICENSE.txt or the like which is intended to apply globally to the codebase?

SPDX identifiers in the kernel

compenguy — Thu, 16 Nov 2017 19:14:17 +0000

SPDX license identifiers are generally insufficient for license compliance. They an important first step in the process of identifying whether compliance is possible, and categorizing what types of obligations compliance carries, but it doesn't help with the actual process of compliance.

Most open source licenses carry a requirement that you distribute the exact license text for the work with the work. Simply saying "this is under the MIT license" is inadequate. Distributing a template MIT license is inadequate. Distributing the exact text of the MIT license file provided by the copyright holders (generally containing one or more copyright statements) is what's required. Without the means to locate and collate the obligatory license files, compliance is difficult, expensive, and easy to get wrong.

tl;dr: I really hope that once they get these license identifiers into files, they don't say "yay, we did it!" and stop. In many instances they'll need to either annotate the source with the full text of each original license, or provide the path to each of those original licenses in the source tree.