Re: Linux kernel enforcement statement discussion

Richard Fontana

On Thu, Dec 13, 2018 at 08:51:10AM -0500, Karen Sandler wrote:
* A few Linux developers have expressed an opinion that they would not use
this identifier to mark upstream code at this point, mostly because they
have not done the work mentioned above. James in particular has agreed that
it operates like any other additional permission/exception, but has
expressed that upstream Linux use of SPDX identifiers in files has a much
higher burden of proof than is typically used by others downstream and
outside of Linux.
I believe it was also pointed out that Linux's DCO policy, and the
current wording of the DCO, could have the effect of seeming to force
contributors to an existing file with "SPDX-License-Identifier:
GPL-2.0 WITH KES-Exception" to make the commitment, presumably
something the kernel would not wish to adopt as a policy (whereas the
Project flavor of GPLCC deliberately implements such a policy). That
could be addressed by revising the wording of the DCO but presumably
no one wants to do that.

* The consensus on the phone call was to give a chance for a legal argument
here to support the statement that "the KES-Exception fails to grant
additional permissions under copyright", as Steve was wondering on the call
if such an argument existed because he'd heard it said that the
KES-Exception isn't an additional permission. I can't find any argument like
that presented here. It looks like people disagreeing on what I think are
more minor points do seem to agree that the KES is in fact an additional
permission / exception, and operates like others on the list. I have to
admit that surprised me a bit, because when we started this thread, that was
what I thought the disagreement was.
I myself have assumed that the KES is a GPLv3-style additional
permission (that is, a "GPL exception" in the traditional sense),
since that's how it's described in the KES itself ("additional
permissions under our license"). FWIW Red Hat's view is that GPLCC is
an additional permission in the same sense, as we've said publicly
numerous times.

I don't see inclusion in the SPDX exception list as conferring
validation that something is, in fact, a GPL-style additional
permission, especially since there seems to have been some interest in
broadening the definition of what an "exception" is for SPDX purposes,
if I understand correctly. I am not sure why the "exceptions" list
couldn't also be broadened to include standardized "additional
restrictions" (to use another GPLv3 concept), obviously with the
"exception" terminology replaced with something less confusing, unless
the exception list is designed to be quasi-political in nature (to
reinforce orthodox GPL interpretive concepts or whatever). I think
that issue may have been discussed before though.

There is something about KES and GPLCC that is different from typical
GPL exceptions, in that they seem to go to enforcement procedure
rather than substantive formal details of license compliance or scope
of copyleft. But I don't see why that difference should create any
doubt that they qualify as additional permissions in the GPL
sense. However IMO that is orthogonal to whether they should be
included in the SPDX exception list, because the SPDX exception list
is not intended to be an authoritative designator of GPL-style
additional permissions. I am not sure the difference goes to
"strippability", to use James's term. A fork of a project using the
similar GPLCC could, I have to assume, strip out GPLCC, but the
additional permission would continue to burden copyrights covered by
GPLCC prior to that fork. This is true of all GPL additional
permissions, though.

* There is now discussion, similar to that about the KES last year that we
delay it again for the next release. I think that's ok, but unlike last
year, we now have similar exceptions from Red Hat that will also get delayed
if we delay this one, so delay here means delaying a whole line of listing
I am obviously completely biased here but I would prefer that
consideration of GPLCC not be delayed. And since the fates of GPLCC
and KES-Exception are, for better or worse, intertwined, I would also
hope consideration of KES-Exception would not be delayed. FWIW I see
no reason why we shouldn't add KES-Exception as well as GPLCC to the
exception list. It's clear that the Linux project won't be
using KES-Exception as an identifier in source files, so the various
potential problems associated with doing so won't actually occur.


Join to automatically receive all group messages.