James Bottomley wrote:

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.

At the beginning here, it seems like you are saying the
LinuxEnforcementStatement-1.0 has no legal significance and is not legally
binding as an additional permissions. I suspect you don't really mean to be
saying that, as it would also mean that other additional permissions granted
for Linux, such as the Linux-Syscall-Note, also have no legal significance.

Later, you point out again that it is indeed an additional permission under
copyright:

So I think it's a question for the SPDX community to answer whether
codifying this additional permission

It sounded on the SPDX Legal conference call, where I've been told by SPDX
leadership is the correct place for these decisions to be made --
that we had nearly full consensus. The only objector appears to be the
Linux Foundation. Jilayne asked for a coherent legal argument that explained
how the LinuxEnforcementStatement-1.0 is *not* an additional permission under
copyright within a week.

I'd written:

(b) both are not granted by all copyright holders in Linux.

James replied:

Yes: your (b) isn't true for the syscall exception. The syscall
exception has been part of the linux kernel COPYING file since before
revision control history began. Accordingly it applies to every
contribution to the Linux kernel and thus is granted by all copyright
holders and we will continue to maintain this.

Has the Linux project gotten the syscall exception for all code that was
every borrowed from another project under GPL-2.0-or-later and/or
GPL-2.0-only? While that borrowed code is a small minority, it is
copyright-wise signifigant.

* * *

As for Conservancy signing onto the enforcement statement, thanks for
your links, James. We're aware of how to do the process -- it sounded
to me like Mike was unsure that more copyright holders would ever sign on,
so I was offering joint press with the LF as a way to help you all with that.
If you don't feel you need -- if you feel developers are likely to be
inspired to sign on without more publicity -- then it hopefully quells Mike's
concerns that there won't be more copyright holders to sign on, and Conservancy
can just take care of it in due course. In any event, more discussion
about that part of it on spdx-legal is probably drifting to off-topic for
the list, but I'd be glad to pick up a side thread with James and Mike about
doing more publicity about the Linux Enforcement Statement jointly between
LF and Conservancy.
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

On Sun, 2018-12-02 at 19:10 -0800, Bradley M. Kuhn wrote:

James Bottomley wrote:

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.

At the beginning here, it seems like you are saying the
LinuxEnforcementStatement-1.0 has no legal significance and is not
legally binding as an additional permissions.

That's absolutely not what I was saying. It obviously has a legal
significance for the *file* but to have legal significance to
downstream it would have to be present in all (or at least all relevant
to the use case) of the files. Absent that it has no useful legal
significance to downstream.

I suspect you don't really mean to be saying that, as it would also
mean that other additional permissions granted for Linux, such as the
Linux-Syscall-Note, also have no legal significance.

Hopefully I've clarified that above.

Later, you point out again that it is indeed an
additional permission under copyright:

So I think it's a question for the SPDX community to answer whether
codifying this additional permission

OK, so the question of whether what is in effect a promise about the
understanding of what constitutes a derived work is an additional
permission or not is something I'm not qualified to get into.

It strikes me that the difference between this and the GPLv3 idea of
additional permissions is strippability. The essence of GPLv3 is that
additional permissions may be stripped in reuse of the licensed code.
However, a statement about interpretation of the licence which
constitutes a promise made to downstream users and which is relied on
by them can't be so easily stripped because a simple reuser of the code
can't negate the existing promise.

It sounded on the SPDX Legal conference call, where I've been told by
SPDX leadership is the correct place for these decisions to be
made -- that we had nearly full consensus. The only objector
appears to be the Linux Foundation. Jilayne asked for a coherent
legal argument that explained how the LinuxEnforcementStatement-1.0
is *not* an additional permission under copyright within a week.

The enforcement statement is also a promise made by a copyright holder
about the code, so it has some of the conundrums of the syscall promise
and strippability thus, in that sense, it's also not a simple
additional permission in the style of GPLv3. I'll let the legal minds
debate whether it's useful to have terminology that separates these two
things.

I'd written:

(b) both are not granted by all copyright holders in Linux.

James replied:

Yes: your (b) isn't true for the syscall exception. The syscall
exception has been part of the linux kernel COPYING file since
before revision control history began. Accordingly it applies to
every contribution to the Linux kernel and thus is granted by all
copyright holders and we will continue to maintain this.

Has the Linux project gotten the syscall exception for all code that
was every borrowed from another project under GPL-2.0-or-later and/or
GPL-2.0-only? While that borrowed code is a small minority, it is
copyright-wise signifigant.

Really, there's no borrowed code in Linux. There's shared code that we
try to dual licence to keep the drivers useful to other projects, but
the contribution of that code to Linux was done in full knowledge of
the obligations of the Linux Kernel COPYING statement as attested to by
the signoffs.

* * *

As for Conservancy signing onto the enforcement statement, thanks for
your links, James. We're aware of how to do the process -- it
sounded to me like Mike was unsure that more copyright holders would
ever sign on, so I was offering joint press with the LF as a way to
help you all with that. If you don't feel you need -- if you feel
developers are likely to be inspired to sign on without more
publicity -- then it hopefully quells Mike's concerns that there
won't be more copyright holders to sign on, and Conservancy
can just take care of it in due course. In any event, more
discussion about that part of it on spdx-legal is probably drifting
to off-topic for the list, but I'd be glad to pick up a side thread
with James and Mike about doing more publicity about the Linux
Enforcement Statement jointly between LF and Conservancy.

OK, so offline works. From the kernel point of view, we think signing
on to our current statement is sufficient, and the additional publicity
is something we've left to the various marketing organizations of the
relevant companies and haven't sought to co-ordinate.

James