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

[Tuukka Pasanen <pasanen.tuukka%gmail.com@localhost>]

> 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.