Michael Dolan wrote at 19:16 (PST) on Monday:

Which leads back to my earlier point that the KES language specifically
scopes the additional permission to the Linux kernel, so no one could use
it "as-is" for another project. If the kernel community won't use the SPDX
identifier, who will use it?

Note that nearly all SPDX exception identifiers currently listed are: (a)
specific to one project and (b) not used by that (or any upstream) project.

SPDX users almost always seek to do more with identifying licensing info
than upstream projects really want/can do. So, it's completely reasonable to
have SPDX identifiers that upstream probably won't use themselves. In fact,
that's the more common occurrence. Upstreams rarely have the time,
inclination, or know-how to properly use SPDX identifiers in files. But
others with that expertise do write SPDX data for those projects later, and
they need the tools for that job. SPDX shouldn't deny them those tools.

In other words, I strongly doubt that Bison, nor any other project, will
every write "GPL-3.0-or-later WITH Bison-exception-2.2" anywhere, but
everyone here nevertheless needs Bison-exception-2.2 listed in the SPDX
Exceptions list to write their own SPDX data for Bison.

Thus, we all need KES-Exception to write correct SPDX data for Linux.
--

Bradley M. Kuhn

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