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