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]
Cc: [email protected]
Subject: Re: standards/60308 (Make is missing SPDX license indetifiers)
Date: Tue, 4 Aug 2026 11:30:54 +0300

  >      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!
 
 Sorry and I don’t want to be rude, but as I’ve said, SPDX license
 identifiers were not part of SPDX 2.0—they were in annex E
 (https://spdx.github.io/spdx-spec/v2.3/using-SPDX-short-identifiers-in-source-files/),
 which does not make them part of the specification. As I’ve pointed out,
 CycloneDX 1.7 documentation states that they require SPDX short license
 IDs 
 (https://cyclonedx.org/docs/1.7/json/#metadata_tools_oneOf_i0_components_items_licenses_items_oneOf_i0_license).
 Again, I admit they are not creators or maintainers of SPDX—only
 downstream users.
 
 I don't see they'll be part of SPDX 3.x anytime soon or ever.
 
 CISA’s new (Published July 29, 2026):
 '2026 Minimum Elements for a Software Bill of Materials (SBOM)'
 recommends using SPDX short license identifiers, but they do not recommend
 the use of SPDX-License-Identifier spefic.
 
 Here’s a quote from CISA’s documentation under
 'Component Data > Component License (New)' (link to document is
 https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf):
 
    When possible, the SBOM author should convey this information in a
    machine-processable fashion, such as by using System Package Data 
 eXchange
    (SPDX) license identifiers.
 
 Instead, they recommend machine-readability, which SPDX short licenses
 provide. My point is this: Repeatedly guessing the correct SPDX license
 from full license text is a waste of computer resources.
 That’s why I provided these identifier patches in the first place.
 
 There’s also a citation linking to https://spdx.org/licenses/. And as I
 anticipate this objection: I admit this doesn’t guarantee the future of
 SPDX-License-Identifier anyway. But it won’t survive if projects and people
 refuse to use it and add identifiers. An identifier is just one line in
 a file—licenses are often more than twenty lines long.
 
 If there’s an alternative standard besides only having licenses at the top
 of files (which are there for everyone to study), I’d be more than happy to
 hear about it.
 
  >  Does FSFE intend to become the normative authority for this syntax?
 
 I don't see they have urge to become authority. They are just downstram 
 user of
 specification like CycloneDX.
 
  >  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.
 
 It's open source project. Anyone is free to provide help on this one.
 ISO is more problematic but this is more or less matter of profesionality
 of SPDX organization.
 
  >  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.
 
 I'm aware that *BSD family has own license naming system.
 LICENSE-fields and confident they are also something to discuss but not 
 in here.
 
  >  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.
 
 I think we can let this one go without pushing further. No confidence, no
 implementation—fewer worries for everyone. I don’t mind if you or any
 admin close this, as I lack the perspective to sway opinions toward what I
 perceive as reliable enough to implement. No harm done in my part.
 
 Time will tell how this plays out with SPDX-License-Identifiers.
 The future holds the answers.