Greetings,

Over at Red Hat, we've been gradually increasing our support of the
use of "SPDX-License-Identifier:" in source files for various reasons.

We've encountered some situations where a traditional project practice
might be to insert a GPL license notice at the top of a file, perhaps
following a copyright notice, where the contents of the file are of
dubious copyrightability, and where there is an important policy
(perhaps more significant now than in the past) in avoiding any
contribution of support to the idea that such material is, or ought to
be, copyrightable. (I'm using "copyrightable" a little loosely here,
as we often do in open source, in a way that might also encompass, for
example, situations where the contents are strictly speaking likely
copyrightable but also likely subject to a noninfringement defense of
some sort for essentially all users.)

As one example, though not necessarily the most interesting one, think
of the default form of a configuration file that might be installed
with a particular package. (Such configuration files actually tend not
to have license notices, but occasionally they do.)

In such situations there may also be significant value in preserving
the traditional practice of including the GPL (or other) license
notice. Thus for example using a public domain approximation like CC-0
or the Unlicense or what have you is not particularly helpful.

We've been thinking one useful approach to take in such cases is to
say something like the following:

// The content of this file is such that this file may not need a license.
// But, if this file does need a license, the license is:
// SPDX-License-Identifier: GPL-2.0-or-later

At any rate, that's what we're trying to get across. The problem is
that the SPDX-License-Identifier expression there by itself does not
express the notion of "if needed" or "not sure". Even apart from that,
the bare use of GPL-2.0-or-later in this example seems inappropriate
from an SPDX standpoint since it does not accurately reflect the legal
intent being expressed in the file.

NOASSERTION (I gather not normally used with SPDX-License-Identifier:
) does not seem to adequately capture what we're trying to express
here. Nor something like the possibly-nonsensical "GPL-2.0-or-later OR
NOASSERTION".

We were thinking one possibility would be to define an exception
(worded similarly to the example statement above) that would express
the "not sure/if needed" concept, and could be used with the baseline
license identifier using the WITH expression. Imagine if SPDX accepted
this as an exception identifier called "If-Needed":

   SPDX-License-Identifier: GPL-2.0-or-later WITH If-Needed

But this sort of identifier would depart from the model that I think
SPDX has assumed thus far in recognizing exceptions, which is the
FSF-popularized notion of "additional permission" exceptions. (See
https://github.com/spdx/spdx-spec/issues/153)

Does anyone have any suggestions/reactions to this issue?

Richard

On Tue, Nov 23, 2021 at 1:56 PM Richard Fontana <rfontana@...> wrote:

Greetings,

Over at Red Hat, we've been gradually increasing our support of the
use of "SPDX-License-Identifier:" in source files for various reasons.

We've encountered some situations where a traditional project practice
might be to insert a GPL license notice at the top of a file, perhaps
following a copyright notice, where the contents of the file are of
dubious copyrightability, and where there is an important policy
(perhaps more significant now than in the past) in avoiding any
contribution of support to the idea that such material is, or ought to
be, copyrightable. (I'm using "copyrightable" a little loosely here,
as we often do in open source, in a way that might also encompass, for
example, situations where the contents are strictly speaking likely
copyrightable but also likely subject to a noninfringement defense of
some sort for essentially all users.)

As one example, though not necessarily the most interesting one, think
of the default form of a configuration file that might be installed
with a particular package. (Such configuration files actually tend not
to have license notices, but occasionally they do.)

In such situations there may also be significant value in preserving
the traditional practice of including the GPL (or other) license
notice. Thus for example using a public domain approximation like CC-0
or the Unlicense or what have you is not particularly helpful.

We've been thinking one useful approach to take in such cases is to
say something like the following:

// The content of this file is such that this file may not need a license.
// But, if this file does need a license, the license is:
// SPDX-License-Identifier: GPL-2.0-or-later

At any rate, that's what we're trying to get across. The problem is
that the SPDX-License-Identifier expression there by itself does not
express the notion of "if needed" or "not sure". Even apart from that,
the bare use of GPL-2.0-or-later in this example seems inappropriate
from an SPDX standpoint since it does not accurately reflect the legal
intent being expressed in the file.

NOASSERTION (I gather not normally used with SPDX-License-Identifier:
) does not seem to adequately capture what we're trying to express
here. Nor something like the possibly-nonsensical "GPL-2.0-or-later OR
NOASSERTION".

It seems to me that the core problem here is that there is an assertion being made— that an evaluation has been made and that the results of the evaluation is that it is public-domain-like.

I’m reminded of the original form (pre-CC0) of CC’s public domain approach (SPDX: CC-PDDC), where the ‘licensor’ could assert that “to the best of [their] knowledge, the work of authorship identified is in the public domain”, and CC’s later experiment with the Public Domain Mark, which avoids license language in favor of a rights “statement”; lots of relevant SPDX-y discussion here: 

https://github.com/spdx/license-list-XML/issues/988

I think you really want (in this example) something like “GPL-2.0-or-later OR CC-PDM-1.0”, which conveys the ambiguous nature of the assessment and allows a policy engine to say “we trust upstream attempts to do self-analysis of CC-PDM” or “hell no, our risk tolerance can’t accept the vagaries of self-defined public domain and so we must fall back to the other license”. Unfortunately, since part of what you’re after is brevity and simplicity, and CC (not unwisely) sought precision, I don’t think the actually text of CC-PDM gets you where you want to be even if it is logically/legally the correct approach.

Luis