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

The following reply was made to PR standards/60308; it has been noted by GNATS.

From: Tuukka Pasanen <[email protected]>
To: [email protected], [email protected],
 [email protected], [email protected], [email protected]
Cc: [email protected]
Subject: Re: standards/60308 (Make is missing SPDX license indetifiers)
Date: Wed, 1 Jul 2026 15:55:32 +0300

 > I went looking at what I thought was the current applicable standard,
 > the SPDX spec athttps://spdx.dev, but the latest version 3.0.1 has
 > completely removed all references to the `SPDX-License-Identifier' tags
 > in source code.
 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.
 
 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).
 
 Additionally, CycloneDX SBOM also incorporates SPDX license IDs,
 suggesting that they will remain a widely adopted industry standard
 both now and in the future.
 > So I'm not at all confident in the long-term value or seriousness of
 > this SPDX business.  And I have had plenty of personal experience
 > already wasting time based on wrong SPDX-License-Identifier tags that
 > were automatically applied across Linux.  We're open to the proposition
 > of adding these tags if they are actually reliable and useful, but the
 > track record of SPDX as a standard is not very convincing right now,
 > and we may need more convincing than just the offer of patches.
 >
 It is true that in my path I have encountered several incorrect tags,
 but most have been  them are correct. When they are correct and
 maintained as part of the licensing workflow, they are very useful.
 
 One can check against them to ensure that the wording in the license
 is correct and consistent with, for example, the BSD-2-Clause license.
 
 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
 
 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.
 
 Given that NetBSD has been around for a long time and includes a lot
 of third-party software (which is already well-aligned with licensing),
 it would be easier to maintain these licenses if all projects provided
 SPDX-License-Identifier data?
 
 My humble opinion—though it is only mine and not necessarily shared
 by others—is that SPDX-License-Identifiers are not going away. There
 is no downside to having them; downstream projects can easily check
 NetBSD's licensing and maintain SBOM if the like.
 
 If the NetBSD community decides to ignore them, that is also a valid and
 correct decision. I have a different perspective and experience with these
 tags, but I respect that others may see things differently.
 
 You are free to close this issue if you choose not to implement them.