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 (#6052): https://lists.spdx.org/g/Spdx-tech/message/6052 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]] -=-=-=-=-=-=-=-=-=-=-=-
