Thanks for the links, Richard. I'll try to follow up there though of course welcome further discussion here as well.

On Thu, Nov 10, 2022 at 5:06 PM Richard Fontana <rfontana@...> wrote:

On Thu, Nov 10, 2022 at 3:01 PM Luis Villa <luis@...> wrote:
[...]

> (1) Would SPDX be an appropriate mechanism for representing that opt-out clause in a machine-readable way, eg via a short identifier + WITH?
>
> (2) This would be, to the best of my knowledge, the first proposed Exception that removes permissions[3] rather than granting new permissions. Would that be acceptable to SPDX? Would that break any implicit or explicit expectations of the specifications or tooling?

Recent exchange that is possibly slightly related to those questions:
https://github.com/spdx/change-proposal/issues/4#issuecomment-1283004681
https://github.com/spdx/change-proposal/issues/4#issuecomment-1304842184

JL: to be clear, this proposal is about an improved way to capture "exceptions" that are NOT on the SPDX License List, so relevant to the extent that such a hypothetical additional clause would not end up being eligible for inclusion on the SPDX License List, you could still represent it with an SPDX conformant license expression

Basically, I believe SPDX has locked itself into a model of what an
"exception" is that is based on normative FSF doctrine built up around
FSF-authorized GPL exceptions, but which does not fully reflect how
standardized license terms actually get supplemented by other terms in
the real world with the GPL and other FOSS licenses (in some cases by
removing permissions, and in some cases where it is not actually clear
whether permissions are being removed). I think this is inconsistent
with SPDX's professed mission of focusing on "just the facts".

JL: I don't think it's inconsistent with this, but it is consistent with the prior standing license inclusion guidelines - see previous email