Date 1 - 2 of 2
Plan to add Linux Kernel Enforcement Statement to SPDX additional permissions list
Bradley M. Kuhn <bkuhn@...>
James Bottomley wrote:
Finally, there's the question of what value does a file containing WITHAt 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
So I think it's a question for the SPDX community to answer whetherIt 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.
James replied:(b) both are not granted by all copyright holders in Linux.
Yes: your (b) isn't true for the syscall exception. The syscallHas 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
* * *
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:
On Sun, 2018-12-02 at 19:10 -0800, Bradley M. Kuhn wrote:
James Bottomley wrote:That's absolutely not what I was saying. It obviously has a legalFinally, there's the question of what value does a file containingAt the beginning here, it seems like you are saying the
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 alsoHopefully I've clarified that above.
Later, you point out again that it is indeed anOK, 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 byThe 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
I'd written:Really, there's no borrowed code in Linux. There's shared code that weJames replied:(b) both are not granted by all copyright holders in Linux.Yes: your (b) isn't true for the syscall exception. The syscallHas the Linux project gotten the syscall exception for all code that
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
* * *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.
|1 - 2 of 2|