On Mon, 2018-12-10 at 15:58 -0700, J Lovejoy wrote:
[...]

C) The issue comes down to how the short identifier would be
effectively used due to the KES's slightly different implementation
as described above in 1-6.

[...]

C-iii) There is also the possibility that people might incorrectly
use the KES in the kernel where it shouldn’t be and consequently make
it appear that some contributors had agreed to the KES who had not
explicitly done so via adding their name to the list and this would
then mean the license identifier was not completely correct.

[...]

Can I please hear some additional thoughts as to the risk and
potential outcomes of C, particularly C-iii from anyone who has this
concern, as well as some of the long-standing members of the SPDX
Legal team?

I haven't quoted C in its entirety, but it misses what I think was
Mike's primary concern, which has also become mine as I've discussed
with the lawyers our current use of the KES.

The design of KES is to be a strong community statement about
principles of enforcement that can be used to rebut someone claiming to
act on behalf of the kernel (i.e. McHardy) when they take actions
contravening the KES like claiming to terminate the licence of the
kernel. The great thing about the current KES is that the document can
be entered into evidence and easily explained to the court. If we have
a process based on SPDX tags, it's going to be a nightmare to explain
to the court at the preliminary injunction phase and worse still, if we
only have a few SDPX tags, it allows the malicious enforcer to claim
that the KES is weaker than it would otherwise appear because there are
so few SPDX tags containing it within the kernel.

So I think, realistically, the kernel wouldn't ever use this. Now that
means don't do it, but I think it's legitimate to wonder how many other
projects would have similar problems.

James