The SPDX model defines the characteristics of licenses in the License List: https://spdx.github.io/spdx-spec/v3.0.1/model/ExpandedLicensing/Classes/ListedLicense/ If we want to add more properties there, that's where they should go.
Although probably these better be added to one of the superclasses, since licenses not in the License List might also benefit for such extra properties. -- zvr -- ________________________________ From: [email protected] <[email protected]> on behalf of Peter Monks via lists.spdx.org <[email protected]> Sent: Friday, December 12, 2025 03:22 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; SPDX-legal <[email protected]>; [email protected] <[email protected]> Subject: Re: [spdx-tech] Expression of interest: technical metadata that embellishes the license lists G’day Karen, I may be wrong, but I don’t think there is an SPDX affordance that exists today that really supports embellishing the listed licenses / exceptions with this kind of metadata. (and yes this MOF use case sounds like another great example of the kind of thing I’m thinking of - thanks for sharing it!) Cheers, Peter On Dec 11, 2025, at 4:12 PM, Karen Bennet via lists.spdx.org <[email protected]> wrote: I had a call with LF-AI/Data MOF today and they are open to using SPDX fields/terminology instead of having their own meta data. They just asked that we put together what needs to change in their MOF tool to be more aligned with SPDX. On Thursday, December 11, 2025 at 05:14:26 p.m. EST, Arthit Suriyawongkul via lists.spdx.org <[email protected]> wrote: Another non-legal use case from the Model Openness Framework (another Linux Foundation project). MOF has a use case of wanting to know if a license is meant for a code, data, or documentation. This will be used to evaluate the appropriateness of the license. MOF current implementation is by extending licenses.json from spdx/license-list-data with a custom "ContentType" field. https://github.com/spdx/spdx-3-model/issues/1181#issuecomment-3643835381 Cheers, Art The job of a citizen is to keep his mouth open. -- Günter Grass On Fri 12 Dec 2025, 06:02 Peter Monks, <[email protected]<mailto:pmonks%[email protected]>> wrote: Yep that's right Art - that's one example of the kind of thing I'm thinking about, though I'm trying not to bog the conversation down in specifics yet, because I'm very open to the idea that there are other forms of technical metadata that may benefit other implementers too, and IMO the focus should be on a general solution first, and then a set of consensus-identified common metadata elements second, rather than getting too caught up in the specific technical metadata I happen to need in my own tools (which may very well be a corner case when compared to other implementers' needs). But at the risk of the conversation going down a rabbit-hole critiquing specific examples (which is premature), the specific example I gave on the implementer's call was the notion of "version series", which is basically a way to group SPDX identifiers that form a linear sequence of versions. Some examples: * Apache-1.0, Apache-1.1, and Apache-2.0 * GPL-1.0, GPL-2.0, and GPL-3.0 * LPPL-1.0, LPPL-1.1, LPPL-1.2, LPPL-1.3a, and LPPL-1.3c * Spencer-86, Spencer-94, and Spencer-99 * ...and more, though not all, SPDX identifiers... Another example I didn't mention on the call but that I've also thought about is metadata that identifies the publisher of a license. For example: * Apache Software Foundation (Apache licenses) * Free Software Foundation (GPL, LGPL, AGPL, GFDL, etc. licenses, plus various exceptions) * LaTeX Project * Henry Spencer * ...and more... Additional metadata elements related to those publishers (URLs, other contact information, etc.) may also prove useful. To reiterate - these are just some random examples I've personally run into, and I really don't want this conversation to get sidetracked into nitpicking the specific merits (or not) of these specific examples. My primary goal is to get a sense of whether other implementers also have unmet needs around additional license / exception metadata that doesn't exist in the lists today, and if so, form a group to only then start working through the nitty gritty details of what those elements are, and if/how SPDX might better support them. I hope this also answers your concern Alexios about why the legal team may be reluctant to consider adding these kinds of things to the lists. The examples I provided have no legal relevance (and I imagine there will be other examples in the same bucket), and so it would be no surprise if the legal team were to express disinterest in adding them. The key insight is that having little to no legal significance does NOT mean that such metadata isn't valuable (i.e. to implementers). Cheers, Peter On Thu, Dec 11, 2025 at 7:03 AM Arthit Suriyawongkul <[email protected]<mailto:[email protected]>> wrote: Peter, During the Implementers call on 2025-12-10 you discussed a license matching optimization technique that leverage a knowledge that a couple of licenses may be related or is a member of a same series. I can't recall it entirely, but I think that use case is less about legal (as from legal perspective , each of them is a different license) and more about technical implementation (reduce search space). If you don't mind to repeat that again here to help us better understand it. Cheers, Art The job of a citizen is to keep his mouth open. -- Günter Grass Intel Deutschland GmbH Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany Tel: +49 89 991 430, www.intel.de Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell Chairperson of the Supervisory Board: Nicole Lau Registered Seat: Munich Commercial Register: Amtsgericht München HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#6055): https://lists.spdx.org/g/Spdx-tech/message/6055 Mute This Topic: https://lists.spdx.org/mt/116717999/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
