Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[Richard Fontana]

On Fri, Nov 30, 2018 at 07:20:15PM -0500, Michael Dolan wrote:
> The Common Cure Rights Commitment (CCRC) which was based on the KES also
> applies to an indefinite pool of projects. If one or a few of the companies
> own all the copyright, my recommendation would be to just relicense the
> project with an appropriate additional permission as a license modifier and
> require all new contributors to give the same license. Instead it could
> apply to N number of projects, many of which we do not know about and for
> each one it only applies to contributions from that company and it doesn't
> change the project license. Even if the company wrote all the code in a
> file today, what happens when NewContributor makes a contribution - now you
> have to notify everyone to remove the "WITH CCRC-1.0" in the next SPDX
> review? Unless someone is running cregit and reviewing each of those files
> they would never know.

Note: Common Cure Rights Commitment was an earlier name for what Red
Hat later ended up branding the GPL Cooperation Commitment. As was
pointed out on the call, GPLCC now exists as three variants,
Corporate, Individual and Project. The Corporate version is a
commitment made by companies, not specifically tied to particular
projects or code. The Individual version is similar but is made by
individuals. The Project version is designed be used in a project
source repository. My original suggestion had been to have an SPDX
exception identifier for the Project version only (I will comment on
this issue in a separate posting).

The Project version of GPLCC serves exactly as what Mike calls "an
appropriate additional permission as a license modifier and require[s]
all new contributors to give the same license". It is designed to be
usable by existing as well as new projects, by applying prospectively
to all contributions as of the date of adoption of the commitment. 

> I think if communities want to do this, we should be guiding them to
> revisit using a CLA or some other means to capture commitments from prior
> contributors and change the project license itself to include these
> exceptions in any future contributions.

With the GPLCC Project version, a CLA is not needed since it
contemplates that past contributions might not be covered by the
commitment while future ones will be. This may make an SPDX identifier
for GPLCC unusual, in that it describes a licensing fact for an entire
project that may not apply to all contributions made under the
underlying project license. Nonetheless, Red Hat considers it highly
desirable to have SPDX recognize GPLCC with an identifier. 

As for the KES, I don't have any concerns about SPDX separately
recognizing an identifier for it. If it does, however, then I believe
it would be no less justifiable to have an identifier for GPLCC. I do
not think Red Hat itself would find any practical value in using a KES
identifier, especially if the kernel developers themselves don't use
it in individual source files, but admittedly we are making only
limited use of SPDX identifiers at present.

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2461): https://lists.spdx.org/g/Spdx-legal/message/2461
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[James Bottomley]

On Mon, 2018-12-03 at 10:34 -0500, Michael Dolan wrote:
> So if I can summarize my the situation we're discussing:
> 
> 1) The additional permission is from one or more of many authors and
> would only apply in a situation where that author(s)' code is being
> enforced as part of a work.

Yes.  As I said this is the reason I don't think we'd apply the tag
unless it were reliable (i.e. all authors demonstrably agreed).

However, there's no current kernel plan for this, it was just a
speculative answer to a theoretical "how would we handle it if it
arose" question.

> 2) The license for the file, any resultant binary or the work would
> not change.

the KES is effectively a conditioned covenant not to sue, so it's very
much like an additional right, like a patent grant.

> 3) The KES was never drafted as a license exception that would apply
> to a file or compiled work.

Agreed.  The KES kernel process is designed to work on the single
statement file which authors and companies sign to cover their entire
contributions.

> I think my concerns can be summarized as:
> 
> A) Has there ever been a SPDX license exception where the exception
> only applied to only an individual's contributions of code in a file
> or work? We often rely on license headers or statements in LICENSE or
> COPYING files to identify a license exception. Here we would need to
> go to the KES in the documentation file and then cross check that
> against the git commit itself to identify the author.

I'd strongly advise no to this.  The SPDX tags are supposed to make
reliable statements to downstream recipients about the licence of the
file.  Anything not all authors of the file agree to isn't a reliable
statement ... and probably would cause all sorts of issues with the DCO
on fairness grounds (if one author hasn't agreed, why do I have to?). 
Which would basically negate all the good SPDX and DCO work we've done.
 That's why I suggest we'd never apply the tag to a file we couldn't
round up entire author agreement for ... and if there are legal
questions like this around the tag I don't think we'd ever use it.

> B) If the license for the file, compiled binary or overall work are
> not modified under this situation, what role does SPDX play in a file
> distributed between parties? What about in a SPDX license identifier?
> 
> D) I'm concerned about the concept the DCO captures a KES on
> contribution. Further how would that be tracked?

At the moment there is no KES on file concept in the kernel.  I merely
theorised how it would work if someone one day submitted a file with
one.  If it's going to be legally problematic, we can just never allow
it (although that decision would be for the kernel community to make
not me).

As for tracking: git ties the signoffs in commit messages to modified
files, so that's about as strongly tracked as you can get.  I can use
git to go from any file to all the author signoff statements (well, at
least as far back as signoff history goes).

> D) If we accept A), how likely is it this will be misapplied? Should
> we enable this at all?

My answer is simple: don't accept A).  Any SPDX tag and modifier must
represent the reliable state of the licence which means it must have
been agreed to by all authors of the file.

James


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2460): https://lists.spdx.org/g/Spdx-legal/message/2460
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[Michael Dolan]

So if I can summarize my the situation we're discussing:

1) The additional permission is from one or more of many authors and would
only apply in a situation where that author(s)' code is being enforced as
part of a work.

2) The license for the file, any resultant binary or the work would not
change.

3) The KES was never drafted as a license exception that would apply to a
file or compiled work.

I think my concerns can be summarized as:

A) Has there ever been a SPDX license exception where the exception only
applied to only an individual's contributions of code in a file or work? We
often rely on license headers or statements in LICENSE or COPYING files to
identify a license exception. Here we would need to go to the KES in the
documentation file and then cross check that against the git commit itself
to identify the author.

B) If the license for the file, compiled binary or overall work are not
modified under this situation, what role does SPDX play in a file
distributed between parties? What about in a SPDX license identifier?

D) I'm concerned about the concept the DCO captures a KES on contribution.
Further how would that be tracked?

D) If we accept A), how likely is it this will be misapplied? Should we
enable this at all?



On Sat, Dec 1, 2018, 3:09 PM James Bottomley <
james.bottom...@hansenpartnership.com wrote:

> On Sat, 2018-12-01 at 14:36 -0500, Michael Dolan wrote:
> > James thanks for that explanation it helps me understand the angle
> > you're thinking of using this for much better.
> >
> > Let me ask one follow-up if I may. Is it broadly the intention to
> > change the license for new files in the kernel going forward to
> > require the KES?
>
> I know of no such intention and as I explained we have a fairly
> rigorous SPDX tag change process that makes this very difficult in
> practice.
>
> > haven't had a conversation like this with anyone but would like to
> > get a sense of how broadly the support is for this. I missed plumbers
> > so maybe it came out of discussions there where there is support.
> > We've also seen at least 4 new McHardy cases recently and I'm not
> > sure if that maybe prompted it.
>
> The current enforcement statement is maintained in
> Documentation/process/kernel-enforcement-statement.rst and anyone can
> submit a patch to add their name to the list.
>
> There were no conversations about it at Plumbers and there's certainly
> no requirement to add your name.
>
> > I ask because we ran into complications when we previously discussed
> > the possibility of making the KES a requirement to contribute. We
> > never went that far and I'm also not sure we've resolved some of
> > those concerns broadly.
>
> Developers don't like being dictated to, so I think that's wise.  Plus
> we have no real way of adding something like this without modifying the
> DCO which I think we all agree would be a bad idea.
>
> So the current process is per file if someone chooses to add the tag or
> by voluntarily adding your name to the enforcement statement in the
> kernel Documentation directory.
>
> > Finally, in the kernel we have the SysCall exception. Have you
> > thought about adding a provision like this to that notice?
>
> You mean to the DCO? ... no, definitely not since we don't really want
> to modify it.
>
> >  There may be other options. My concern is this was drafted as an
> > individual, unilateral additional permission from the copyright owner
> > and I don't think it works as some are intending.
>
> OK, could you elaborate the problem as you see it?  We believe the
> system call exception is a very old promise made to (and relied upon
> by) users of the Linux Kernel.  The current documented process in the
> kernel requires this promise to be included as "WITH Linux-syscall-
> note" in the header files which are exported to other development
> packages like glibc so there's a visible reminder.  If you're asking
> how we preserve and keep it going forward, firstly as a promise relied
> on it's estoppel but secondly it's still explicitly mentioned in the
> kernel COPYING file which still documents the overall contract with
> users.  If the fear is some future copyright troll saying their
> contributions in the syscall area were made without the syscall
> exception and therefore all userspace binaries are under GPL unless
> they get paid to waive it, I really don't see that flying in any
> jurisdiction because we have a promise made and notice given in the
> COPYING file.
>
> James
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2459): https://lists.spdx.org/g/Spdx-legal/message/2459
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[James Bottomley]

On Sat, 2018-12-01 at 14:36 -0500, Michael Dolan wrote:
> James thanks for that explanation it helps me understand the angle
> you're thinking of using this for much better.
> 
> Let me ask one follow-up if I may. Is it broadly the intention to
> change the license for new files in the kernel going forward to
> require the KES?

I know of no such intention and as I explained we have a fairly
rigorous SPDX tag change process that makes this very difficult in
practice.

> haven't had a conversation like this with anyone but would like to
> get a sense of how broadly the support is for this. I missed plumbers
> so maybe it came out of discussions there where there is support.
> We've also seen at least 4 new McHardy cases recently and I'm not
> sure if that maybe prompted it.

The current enforcement statement is maintained in
Documentation/process/kernel-enforcement-statement.rst and anyone can
submit a patch to add their name to the list.

There were no conversations about it at Plumbers and there's certainly
no requirement to add your name.

> I ask because we ran into complications when we previously discussed
> the possibility of making the KES a requirement to contribute. We
> never went that far and I'm also not sure we've resolved some of
> those concerns broadly.

Developers don't like being dictated to, so I think that's wise.  Plus
we have no real way of adding something like this without modifying the
DCO which I think we all agree would be a bad idea.

So the current process is per file if someone chooses to add the tag or
by voluntarily adding your name to the enforcement statement in the
kernel Documentation directory.

> Finally, in the kernel we have the SysCall exception. Have you
> thought about adding a provision like this to that notice?

You mean to the DCO? ... no, definitely not since we don't really want
to modify it.

>  There may be other options. My concern is this was drafted as an
> individual, unilateral additional permission from the copyright owner
> and I don't think it works as some are intending.

OK, could you elaborate the problem as you see it?  We believe the
system call exception is a very old promise made to (and relied upon
by) users of the Linux Kernel.  The current documented process in the
kernel requires this promise to be included as "WITH Linux-syscall-
note" in the header files which are exported to other development
packages like glibc so there's a visible reminder.  If you're asking
how we preserve and keep it going forward, firstly as a promise relied
on it's estoppel but secondly it's still explicitly mentioned in the
kernel COPYING file which still documents the overall contract with
users.  If the fear is some future copyright troll saying their
contributions in the syscall area were made without the syscall
exception and therefore all userspace binaries are under GPL unless
they get paid to waive it, I really don't see that flying in any
jurisdiction because we have a promise made and notice given in the
COPYING file.

James


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2455): https://lists.spdx.org/g/Spdx-legal/message/2455
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[Michael Dolan]

James thanks for that explanation it helps me understand the angle you're
thinking of using this for much better.

Let me ask one follow-up if I may. Is it broadly the intention to change
the license for new files in the kernel going forward to require the KES? I
haven't had a conversation like this with anyone but would like to get a
sense of how broadly the support is for this. I missed plumbers so maybe it
came out of discussions there where there is support. We've also seen at
least 4 new McHardy cases recently and I'm not sure if that maybe prompted
it.

I ask because we ran into complications when we previously discussed the
possibility of making the KES a requirement to contribute. We never went
that far and I'm also not sure we've resolved some of those concerns
broadly.

Finally, in the kernel we have the SysCall exception. Have you thought
about adding a provision like this to that notice? There may be other
options. My concern is this was drafted as an individual, unilateral
additional permission from the copyright owner and I don't think it works
as some are intending.




On Sat, Dec 1, 2018, 2:12 PM James Bottomley <
james.bottom...@hansenpartnership.com wrote:

> On Fri, 2018-11-30 at 19:20 -0500, Michael Dolan wrote:
> > I'm just catching up late on a Friday night and noticed this. I have
> > to say I'm surprised this suddenly went to last call for comments. I
> > guess I missed the prior discussion on the list about this and
> > apologize for showing up late.
> >
> > I honestly do not understand the rationale for doing this. When
> > someone receives a SPDX file, how would you actually use one of these
> > exception?
>
> I won't repeat all of your argument, but I think it boils down two two
> fundamental questions
>
>1. How do you trust the kernel file SPDX tag when it includes a WITH
>   additional permission
>2. How do we preserve the tag going forwards
>
> The answer to 1., as you know because you were a large part of it, is
> that we ran a rigorous process to derive the existing licence of every
> file in the kernel using cregit and other tools.  We now run rigorous
> scrutiny of patches seeking to update any existing file with SPDX tags.
>  As a result, we have 19,996 SPDX tags in the current kernel (4.20-rc4-
> 350-gd8f190ee836a) out of 62,477 current files of which 1,312 have WITH
> as part of this (1,302 are the syscall note and the 10 others are no
> invariant sections for documentation and a couple of GCC exceptions)
> none of the current WITH tags have the cure provision.
>
> The answer to 2. is likewise simple; the DCO contribution process
> includes in all parts an attestation that the contribution is being
> submitted under the licence indicated in the file.  This means that as
> long as we rigorously observe the DCO process for Signed-off-by (which
> we do as part of our community DNA), we automatically preserve any WITH
> additional tags in files for all contributions.
>
> I think the question of how the KES would get inserted into the Kernel
> breaks down into two questions
>
>1. Would we accept a patch changing an existing file's SPDX tag to
>   include WITH KernelEnforcementStatement-1.0
>2. Would we accept a wholly new file containing a SPDX tag including
>   WITH KernelEnforcementStatement-1.0
>
> I think 2. is the easiest to answer: For a new file I think yes, we
> would, because we give authors reasonable discretion and once accepted
> the tag would be preserved going foward by the DCO process.
>
> 1. is much more complex: the submitter would have a huge burden to
> prove, as you say, that all authors and contributors to the file
> agreed.  It's not impossible that this burden of proof would be met for
> newer files with small numbers of contributors, I think it highly
> unlikely that it would be met for older files with large number of
> contributors.  However, the bottom line is that you can trust us to ask
> the question rigorously and reject the patch if the burden of proof
> isn't met.
>
> So the bottom line is I think you can trust us if we ever add a file
> with the KES exception.
>
> Finally, there's the question of what value does a file containing WITH
> KernelEnforcementStatement-1.0 provide to downstream?
>
> I think the answer here is pretty much none in legal terms.  However,
> the KES is supposed to be an aspirational statement of reassurance
> driving the enforcement principles of the community and in those terms
> there might be value in adding it to some kernel files.  So I think
> it's a question for the SPDX community to answer whether codifying this
> additional permission actually provides enough measurable value to the
> people the community is meant to serve.
>
> James
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2454): https://lists.spdx.org/g/Spdx-legal/message/2454
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: 

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[James Bottomley]

On Fri, 2018-11-30 at 19:20 -0500, Michael Dolan wrote:
> I'm just catching up late on a Friday night and noticed this. I have
> to say I'm surprised this suddenly went to last call for comments. I
> guess I missed the prior discussion on the list about this and
> apologize for showing up late.
> 
> I honestly do not understand the rationale for doing this. When
> someone receives a SPDX file, how would you actually use one of these
> exception?

I won't repeat all of your argument, but I think it boils down two two
fundamental questions

   1. How do you trust the kernel file SPDX tag when it includes a WITH
  additional permission
   2. How do we preserve the tag going forwards

The answer to 1., as you know because you were a large part of it, is
that we ran a rigorous process to derive the existing licence of every
file in the kernel using cregit and other tools.  We now run rigorous
scrutiny of patches seeking to update any existing file with SPDX tags.
 As a result, we have 19,996 SPDX tags in the current kernel (4.20-rc4-
350-gd8f190ee836a) out of 62,477 current files of which 1,312 have WITH
as part of this (1,302 are the syscall note and the 10 others are no
invariant sections for documentation and a couple of GCC exceptions)
none of the current WITH tags have the cure provision.

The answer to 2. is likewise simple; the DCO contribution process
includes in all parts an attestation that the contribution is being
submitted under the licence indicated in the file.  This means that as
long as we rigorously observe the DCO process for Signed-off-by (which
we do as part of our community DNA), we automatically preserve any WITH
additional tags in files for all contributions.

I think the question of how the KES would get inserted into the Kernel
breaks down into two questions

   1. Would we accept a patch changing an existing file's SPDX tag to
  include WITH KernelEnforcementStatement-1.0
   2. Would we accept a wholly new file containing a SPDX tag including
  WITH KernelEnforcementStatement-1.0

I think 2. is the easiest to answer: For a new file I think yes, we
would, because we give authors reasonable discretion and once accepted 
the tag would be preserved going foward by the DCO process.

1. is much more complex: the submitter would have a huge burden to
prove, as you say, that all authors and contributors to the file
agreed.  It's not impossible that this burden of proof would be met for
newer files with small numbers of contributors, I think it highly
unlikely that it would be met for older files with large number of
contributors.  However, the bottom line is that you can trust us to ask
the question rigorously and reject the patch if the burden of proof
isn't met.

So the bottom line is I think you can trust us if we ever add a file
with the KES exception.

Finally, there's the question of what value does a file containing WITH
KernelEnforcementStatement-1.0 provide to downstream?

I think the answer here is pretty much none in legal terms.  However,
the KES is supposed to be an aspirational statement of reassurance
driving the enforcement principles of the community and in those terms
there might be value in adding it to some kernel files.  So I think
it's a question for the SPDX community to answer whether codifying this
additional permission actually provides enough measurable value to the
people the community is meant to serve.

James



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2453): https://lists.spdx.org/g/Spdx-legal/message/2453
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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]

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
>
>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 

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[Michael Dolan]

I'm just catching up late on a Friday night and noticed this. I have to say
I'm surprised this suddenly went to last call for comments. I guess I
missed the prior discussion on the list about this and apologize for
showing up late.

I honestly do not understand the rationale for doing this. When someone
receives a SPDX file, how would you actually use one of these exception?

The primary issue I had the first time I heard this suggestion was raised
is that the Kernel Enforcement Statement (KES) was always a commitment from
an individual author for their contributions. It was never drafted to be a
project license or a modifier of a project license. It solely modifies an
individual's contribution with additional permissions. So what would you
have? The one thing I've always thought SPDX was focused on was laying a
factual groundwork for the resultant license determination. And for that
determination to survive without having to comb through who made every
contribution since the last version. A unilateral additional permission
cannot change the license for a project or even a file. I don't see how
this would work and will explain my rationale below.

SPDX-License-Identifier: GPL-2.0-only WITH KernelEnforcementStatement-1.0

I've looked at the details of contributions to a lot of files in the kernel
as have others on this list. 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.

IMO, and I think many of you would agree, one would have to have ALL
authors and copyright owners agree to make the Kernel Enforcement Statement
individually before this would be possible. Or ALL the authors would have
to relicense the project under a new license with a similar exception added
to the new project license. No one has ever made the KES a condition of
contributing to the kernel. What reliance could someone take away if they
saw that applied? And how many people would incorrectly apply it? That's a
real issue IMO.

Further you would have to required contributions to be made with that
statement going forward in the future. Who will remove the KES exception
when the next person who hasn't made a KES pledge sends in a contribution?
How would you know? It takes a TON of compute power and resources for us to
track this in cregit for just the Linux kernel - imagine all the
dependencies that might be included. The moment someone new contributes,
you can no longer rely on any analysis that was previously done for any
file or binary associated with KES in a SPDX file. So now you have to redo
the entire SPDX analysis - or someone downstream who receives an SPDX file
will have to know this nuance and never be able to rely on it for the next
version of the kernel they receive?

There are MANY political and other hurdles we had to work through in
creating the Kernel Enforcement Statement (KES) with developers in the
Linux kernel community and many of the top contributing companies. Karen,
Greg and I were deeply involved in that process and it was not easy. I
realize I had to miss yesterday's call and haven't had time to catch up
with whoever was on, but this is something I would honestly raise my hand
and at least say I'm completely opposed to. Maybe I'm alone on this, but it
makes no sense to me to do this - it undermines key principles behind the
drafting and what it took to get support from nearly 100 maintainers in the
kernel community and critical corporate copyright owners of code in the
kernel.

I will also point out there have been many unilateral grants of additional
permissions. There are patent non-assertions from IBM, Google, and others.
Some may relate to a project, some may relate to all OSS projects and some
may have nothing to do with OSS but could be applied to OSS in certain uses
(e.g. Tesla's). Most have nothing to do with any particular project. Those
likewise do not modify the project license. They are not a part of a
license or grant from any future contributors to a project either. It's no
different than the KES.

The Common Cure Rights Commitment (CCRC) which was based on the KES also
applies to an indefinite pool of projects. If one or a few of the companies
own all the copyright, my recommendation would be to just relicense the
project with an appropriate additional permission as a license modifier and
require all new contributors to give the same license. Instead it could
apply to N number of projects, many of which we do not know about and for
each one it only applies to contributions from that company and it doesn't
change the project license. Even if the company wrote all the code in a
file today, what happens when NewContributor makes a contribution - now you
have to notify everyone to remove the "WITH CCRC-1.0" in the next SPDX
review? Unless someone