Plan to add Linux Kernel Enforcement Statement to SPDX additional permissions list (Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment)


Bradley M. Kuhn <bkuhn@...>
 

Michael Dolan wrote:
It solely modifies an individual's contribution with additional
permissions.
Indeed, that's precisely what every "additional permission" does (going back
to the Bison Exception in the 1980s). So, you've basically stated there the
very definition of a "license exception". Restating it a bit more verbosely:
it's an additional permission granted by a copyright holder to work that
allows some copyright-governed activities that the main license otherwise
prohibits. The Linux Kernel Enforcement is thus an exception (or, better
said, "additional permission") like any other.

I *do* think there is a lot of confusion with the word "exception". You
were kind enough to link to a blog post of mine that explains this further,
but the TL;DR is that I've always thought "exception" was a non-optimal term
to describe what these documents do, particularly for developers who usually
mean something else when they talk about an "exception has occurred".

Jilayne independently seems to have come to the same conclusion, as she
mentioned on the call a desire to (eventually) excise the word "exception"
from the language in SPDX that describes what an "additional permission" is.

BTW, in the last few years, I've been favoring the very language used by the
the Linux Kernel Enforcement statement itself: "additional permissions". I
think it's the best phrase. A year or so ago, SPDX also headed in that
direction by explicitly adding that phrase to the definition of the "License
Exceptions" list.

one would have to have ALL authors and copyright owners agree to make the
Kernel Enforcement Statement individually before this [putting this
identifer on a specific file] would be possible.
I suspect if we did the work, we could find files today that are under the
license of GPLv2.0-only WITH Enforcement-Statement-1.0. (More on that at the
end of this message.)

But anyway, is there a rule in SPDX that there must be a specific *file* "in
the wild" that contains *only* copyrights under a particular license
before a license can be listed with SPDX?

I admit that I haven't had time (working for a tiny org with only four
employees) to look through Linux to see if there is a specific file that I
would definitely say *only* contains copyrighted code under "GPLv2.0-only
WITH Linux-Enforcement-Statement". However, I'm quite sure there are
certainly already large portions of many files in Linux today that are
licensed under that license (or perhaps GPLv2.0-or-later WITH
Enforcement-Statement-1.0). Linux developers I've talked to concur (see
below).

But, no matter whether there is a single file that can be identified, are you
saying that SPDX should *not* have a method for representing the license of
those copyrights -- however they happen to be organized on the disk?

I think it's a mistake for SPDX to leave itself unable to represent a license
that has been observed "in the wild". Someday, SPDX may have the ability to
tag copyrighted portions that are smaller than files. I'm sure we'd all love
interactive copyright license annotation of large documents, and such
technology is probably only a few years out anyway. SPDX should plan for the
future, not the past.

Furthermore, we should be careful to avoid this misconception of "the file is
a magically important vessel of copyright holding". Copyright is about works
and portions of works -- which may or may not map to the computing concept of
"files".

There are patent non-assertions from IBM, Google, and others.
As was said by multiple people on the call, pure patent terms ought to be
discussed separately and are not related to the issues hand.

If I may point out Bradley's post
<https://sfconservancy.org/blog/2017/oct/20/additional-permissions/>
in which he stated, "This begs the question: what's the effective
license of Linux? Well, more than likely, it's simply GPLv2-only."
Mike, while I thank you very much for linking to my relevant blog post on
this subject, I'd ask you not to please not quote me out of context from it
-- as you have done above.

The sentence *right after* the one you quoted is:
The overwhelming majority [of code in Linux] is under "GPLv2 with the
syscall exception", and (with this week's announcement) an ever-growing
swath will be licensed under "GPLv2 with the syscall exception and with
the Linux Kernel Statement additional permission".
Meanwhile, that other relevant additional permission, which SPDX calls
"Linux-syscall-note", is one that you personally advocated strongly that we
add to the list. Can you explain the fundamental legal difference between
Linux-syscall-note and the Linux Enforcement Statement? I am really having
trouble seeing it because (a) both are additional permissions that give
permissions not in the GPL and (b) both are not granted by all copyright
holders in Linux.

Who if anyone has discussed this with the kernel contributors and what
was their feedback?
I've discussed it with many. Frankly, in my experience, most Linux
contributors are apathetic and indifferent to SPDX in general, and have no
opinion one way or another -- they just want to get their work done. But I
don't think the "contributor" is the target market for SPDX anyway, though.
Do you? SPDX is really for licensing policy wonks and we have the perennial
problem of trying to convince contributors to take it seriously enough to
help us. I am not sure bothering them with a poll (informally or otherwise)
about this question is likely to make SPDX more popular among them.

I do personally work on a daily basis with many Linux contributors. I've
asked the ones whom I know are interested to licensing policy discussions
about this. They've told me that in fact they believe there *are* entire
files in Linux's tree surely exist under "GPL-2.0 WITH
Linux-Enforcement-Statement" right now. I was talking to one such developer
*this morning*, in fact, but before Mike sent his email so I didn't ask that
developer to do the work to find such a file.

As I mentioned above, I'm pretty sure SPDX project doesn't have the rule that
"until we are shown a specific file in a well-known project where that file
*in its entirety* is proven to be under a license, we will not list that
license". But, even if SPDX wants to institute that rule, I'm sure such a
file could be found in Linux anyway.

Mike wrote further:
My assumption is there are likely very few files in the kernel that the
statement above could be applied to. If you look at cregit, you can
visually see how complicated this would be. I personally would never put
that statement into a SPDX file or short identifier of a binary or file
from the Linux kernel.
So your assumption is that few (or no) more Linux copyright holders will ever
grant this additional permission? That seems a very pessimistic outlook.
Perhaps the Linux Foundation could put some of its resources into advocating
for copyright holders to sign on to the additional permission? Conservancy
has already made a call for folks to sign on to it (in the blog post you
linked to), and we'd be glad to work with you on further promotion.

(Admittedly, Conservancy itself, which holds copyrights in Linux too, has yet
to sign on but it's only because we're a small org and hadn't been able to
set aside the time to get it done. Mike, if you let me know when a good time
would be for Conservancy to sign on for its copyright -- so Linux Foundation
can build some promotion around that -- I'll follow your lead on when we
should do that.)
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

Join {Spdx-legal@lists.spdx.org to automatically receive all group messages.