There are several metadata elements included in the published license and exception lists that aren't in the SPDX model, so that first sentence isn't accurate (referenceNumber, reference, detailsURL, etc.). The second sentence is something that I'd consider to be "in scope" for discussion by this group, probably coupled to the discussion of whether this proposal should push for these additional metadata elements to be included in the license lists directly (vs being managed as separate artifacts).
But we're getting ahead of ourselves - are you expressing interest in being part of a group that would discuss these (and other) topics related to an expanded set of listed license and exception metadata? Cheers, Peter On Fri, Dec 12, 2025 at 12:35 AM Alexios Zavras via lists.spdx.org <[email protected]> wrote: > 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 <bennetkl= > [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]> 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 > > > 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 (#6056): https://lists.spdx.org/g/Spdx-tech/message/6056 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]] -=-=-=-=-=-=-=-=-=-=-=-
