Re: standards/60308 (Make is missing SPDX license indetifiers)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 1 Jul 2026 15:55:32 +0300
> From: Tuukka Pasanen <pasanen.tuukka%gmail.com@localhost>
> 
> It seems there have been many questions about removing the
> SPDX-License-Identifier from the specifications in Annex H.
> 
> As mentioned here https://github.com/spdx/spdx-spec/issues/1393,
> it was not part of the official specification. Identifiers were
> previously in the appendix, and efforts are underway to potentially
> reinstate them in some form. However, the specific details of how
> they may be reintegrated into the spec remain unclear.
> 
> Another relevant discussion https://github.com/spdx/spdx-spec/issues/1261
> provides additional context on the removal of these tags.

Thanks, but I'm afraid this is adding confusion rather than context.
For example, someone who appears to be an editor of the SPDX
specification, github.com/bact, said:

	It is an interesting question if we can use the license short
	identifier as an spdxId of a license object and expect the
	SPDX 3 consumer to interpret it the way SPDX 2 does.

Such doubts _from among the SPDX editors_ are really not helping to
inspire confidence in the reliability of the standard!

> The current usage documentation can be found here
> https://github.com/spdx/using/blob/main/docs/license-id-in-source.md.
> 
> Moreover, the REUSE Software project (https://reuse.software/spec-3.3/)
> actively endorses the use of these tags, offering a detailed rationale
> for their adoption. REUSE is an initiative by the Free Software
> Foundation Europe (FSFE).

I checked the REUSE Spec 3.3 and it is defined in terms of the
now-deleted part of the SPDX 2.3 spec, Annex H.  So I would guess that
REUSE Spec 3.4 or whatever will have to do something different.

Does FSFE intend to become the normative authority for this syntax?

Given that there's been an open question about this since October,
with zero responses from anyone at FSFE, I'm not even sure this is on
the radar of anyone responsible:

https://github.com/fsfe/reuse-website/issues/120

I'm just not at all confident in the viability of the SPDX
organization (Linux Foundation? working group?) as a standards body --
they've taken the specific thing you're asking for out of the
standard, published an ISO standard full of 404 broken links to their
own web site, and told people asking how to update from 2.x to 3.x
that the same artefacts might not be interpreted the same way.

> Having read too many licenses during this year. I can confidently say 
> that it
> makes a significant difference whether only the license text is provided
> or whether an SPDX identifier is also included. Even with a license
> text provided, you still need to use a tool to parse it to ensure it
> does not contain any unexpected wording or deviations from the standard.
> 
> With an SPDX-License-Identifier, you can quickly verify that the license
> text matches the expected wording (e.g., BSD-2-Clause). If it does not
> match, as in this example: 
> https://github.com/spdx/license-list-XML/issues/3007
> I need to start figuring from the scratch

Sure, I understand the appeal of quickly summarizing this stuff, which
is why we have, e.g., LICENSE= tags in pkgsrc which, if specified,
have to match the exact text -- modulo naming of copyright holders --
of what is recorded in pkgsrc/licenses/.  (This system predated SPDX.)

I also understand that bespoke systems like pkgsrc's are less
appealing than industry-wide standards bodies.  If there were a
_reliable_ standards body here, that might be an improvement.

But the key point is that the standards body has to inspire confidence
that it will be reliable, and the SPDX organization is not doing that.

> Additionally, there are many licenses with nearly identical wording but
> minor variations. These can also be identified with the right tools
> and a bit of reading. However, having an extra line for the
> SPDX-License-Identifier in the source file does not seem like a burden,
> especially since license can take up most of the file's content in some
> cases.

My concern is that if we add these, we'll have two sources of truth
that might get out of sync, and while one of them is the plain
language, the other is reference to an outside standard by an
unreliable standards body.  So it will be necessary to use wdiff
anyway to work around the unreliability.


I went to draft a policy last month but I stopped because the
authority I wanted to cite for the whole point of the policy --
SPDX-License-Identifier tags in source code -- seems to be unreliable.
I'm open to the proposition that SPDX will clean up their act and
become a useful citation in the future, but that has to be
demonstrated; until then, a sloppy standard doesn't strike me as much
better than checking wdiff.

# [DRAFT] Policy on SPDX-License-Identifier tags

XXX Apparently SPDX-License-Identifier tags have been removed from SPDX
XXX 3.0.1 and I have no idea why.  For now this document cites SPDX 2.2
XXX since that is the one that was codified as ISO/IEC 5962:2021.
XXX
XXX The spdx.dev web site is also currently full of 404 links, which is
XXX why I added a requirement to provide Internet Archive links too.

https://rt.netbsd.org/Ticket/Display.html?id=414980

1. SPDX-License-Identifier tags MAY be added following the syntax of
   [SPDX-2.2], Appendix V "Using SPDX short identifiers in Source
   Files", and SHOULD go in the same comment block as the license text.

2. Anyone adding SPDX-License-Identifier tags MUST NOT remove existing
   copyright notice (e.g., "Copyright (c) 2026 The NetBSD Foundation,
   Inc.") or the copying terms (e.g., "Redistriution and use in source
   code and binary forms, with or without modification, are permitted
   provided...").  (Removing the text would violate the copying terms.)

3. SPDX-License-Identifier tags may be added ONLY where they are
   unambiguously correct.  Anyone who adds them MUST link to the
   canonical SPDX text at [SPDX-LIST] together with an Internet Archive
   link (https://web.archive.org/) and put evidence in the commit
   message that they have personally verified the full text matches the
   canonical SPDX text with wdiff(1) from pkgsrc textproc/wdiff or an
   equivalent word diff tool.  If there is any question, don't do it.

4. If any discrepancy arises, the existing text overrides, and
   SPDX-License-Identifier tags MAY be removed by anyone with a commit
   message explaining the discrepancy.  The removal MUST NOT be then
   reverted without further public discussion or appeal to board@.

5. Except for code imported from external sources (such as external/ or
   code outside external/ shared with other BSDs), new code MUST still
   have license text, not just an SPDX-License-Identifier tag.  New
   code SHOULD use localsrc/admin/copyright/templates/*.

References:

[SPDX-2.2] _Software Data Package Exchange (SPDX)_, The Linux
Foundation, Specification Version 2.2.
https://spdx.dev/wp-content/uploads/sites/31/2023/09/SPDX-specification-2-2.pdf
https://web.archive.org/web/20260418031142/https://spdx.dev/wp-content/uploads/sites/31/2023/09/SPDX-specification-2-2.pdf

[SPDX-LIST] _SPDX License List_, The Linux Foundation
https://spdx.org/licenses/