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 additionalIndeed, 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 theI 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 postMike, 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: Meanwhile, that other relevant additional permission, which SPDX callsThe overwhelming majority [of code in Linux] is under "GPLv2 with the "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 whatI'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 theSo 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/ |
|