[Tracker] Additional license metadata

[bact]

This is a tracker for issues related new metadata field for license/exception.

Some of these issues are collection of proposal from different Implementers calls in 2025.

They are not necessarily about the information from the exact legal text, and could also be information/opinion that will help a more efficient processing of licensing data. Who will host such the information is also a question/concern.

• Brought up to 27 Jan 2026 Tech call.
  https://docs.google.com/document/d/1NdHYU_VZtLacD4bEmf2GiUVRTbrcev1beaJpq8s8-pU/edit?tab=t.awbnfkarxcue
• Scheduled for further discussion in 3 Mar 2026 Tech call.
• Rescheduled for 10 March 2026 Tech call.

[zvr]

I wanted to address a related issue; not of the "content" of extra information, but of its modelling and integration on the SPDX model.
IF there is a decision to allow some extra information, there is the open question of how to model it. I go by the assumption that any extra information will not reside in the SPDX License List.

I am concerned because the different issues (#1181, #1182, #1183, and #1184) talk about "properties". I honestly believe that we can not have any additional properties — not because we don't want to model the data, but because of the way SPDX data actually work.

Think of some of the things that have been expressed about this new information:

1. SPDX has its License List, which keeps information on licenses (ListedLicense class in our model)
2. There are some "additional properties" available
3. Someone else publishes the extra information making use of these extra properties

This can not work and violates all our SPDX modeling.

The SPDX Project publishes the information of its License List in a machine-readable format; the way it's been currently done is by creating the data and publishing it in the https://github.com/spdx/license-list-data repo. For example, the file https://github.com/spdx/license-list-data/blob/main/SPDXv3/v3jsonld/MIT.json in lines 29ff. defines a ListedLicense with the identifier "http://spdx.org/licenses/MIT". It also provides its licenseText, a matching template, and the rest of the information from the License List.

Now, if someone were to do step (3) above, i.e. publish more information about this license, what would happen? This someone will need to add an additional property to this license.
However, a very fundamental characteristic of SPDXv3 is that every Element is immutable: once created ("minted") there can be no changes to it, ever.
Therefore, it will not be possible to "add" this property to the Element with identifier "http://spdx.org/licenses/MIT". On the contrary, a new identifier will have to be created (which will also have a different creator and creationInfo). Of course this defeats the whole purpose: since whenever someone wants to express something more, a new identifier has to be created, each publication of any additional information will result in new identifiers and not of extra information about "http://spdx.org/licenses/MIT".

The only way to model this in SPDXv3, is by using Relationships instead of properties.
IF a decision is reached to allow the licenseContentType, for example (saying "this license is OK for code, not OK for documentation" or something like that), this can NOT be an extra property of the ListedLicense. There should be a RelationshipType like "isAppropriateFor" and one should create a Relationship of this type from this License to "Code" (which I assume will be a Vocabulary of different content types).
Or, IF a decision is reached to allow "license version series", there should be Relationships between MPL-1.0, MPL-1.1 and MPL-2.0, for example — NOT extra properties in any of these licenses.
This is exactly why in SPDXv3 the declared and concluded licenses are no longer "properties", but expressed via Relationships.

By using Relationships we also get attribution /authorship information ("who said that this license is appropriate for X"), which automatically translates to "according to A, this license is appropriate for X".

TL;DR: whatever license information we publish has to come either (a) from the SPDX License List or (b) be expressed in Relationships. There can not be additional properties.

So please keep all this in mind in all these discussions.