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.Bottomley@... 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

> 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


Join { to automatically receive all group messages.