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]> 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]> > 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 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#6053): https://lists.spdx.org/g/Spdx-tech/message/6053 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]] -=-=-=-=-=-=-=-=-=-=-=-
