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.
Cheers, Art
The job of a citizen is to keep his mouth open. -- Günter Grass
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
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
_._,_._,_
Links:
You receive all messages sent to this group.
View/Reply Online (#6054) |
Reply to Sender
| Reply to Group
|
Mute This Topic
| New Topic
Your Subscription |
Contact Group Owner |
Unsubscribe
[[email protected]]
_._,_._,_
|
