Including Fedora's 'Good' list as SPDX metadata

[seabass-labrax]

Issue #1736 includes the interesting point that AppStream (widely used in Linux distributions) is yet another program which uses SPDX License Identifiers to attempt to determine whether software is free or not. This appears to be a common desire among users of SPDX, yet both the FSF and OSI lists are inadequate for this task.

Fedora's 'Good' list of licenses has recently been transformed into a more machine-readable format. I would like to suggest that Fedora's decision on the 'License Status' could be automatically included in releases of the SPDX License List. This would serve as a (more comprehensive and recent) marker of whether software is freely licensed in practice.

[goneall]

It looks like this is relatively straight-forward to add to the licenseListPublisher .

I took a look at the fedora-licenses.json which is generated anytime the Fedora license list is updated. There is a field license with a property status that appears to map to the "Good" list - but this should be confirmed. There is another field spdx_abbrev which looks like it maps to the SPDX ID if one exists.

I would propose we add a new property to the generated license-list-data files fedoraStatus which would simply be the value of the license.status property. This property would show up in the RDFa, JSON license details, and RDF formats. The property would be optional - it would not be included if an SPDX license ID is not found in any of the spdx_abbrev fields.

An alternative would be to "interpret" the status and translate to "Good" or not. Personally, I would avoid any interpretation of non-SPDX fields in case there are future changes to the field. We could leave that up to the users of the data.

It would be great to have someone from Fedora review this proposal - ping @richardfontana @jlovejoy

If we want to implement this - we should open an issue in the licenseListPublisher.

BTW - with the machine generated files, it would also be straight forward for any other tools to correlate the SPDX license information with the Fedora license information now that the information is machine readable.

[jlovejoy]

Thanks @seabass-labrax for kicking this off! Also flagging @dcantrell as we discussed this idea some time ago when Fedora was deciding on a data format.

The terminology has now changed - what was described as "good" on the old Fedora wiki is now "allowed". Fedora also recognizes some allowed categories, such as "allowed-content", "allowed-font", allowed-documentation" - so it would probably be best to simply reproduce that status and then provide a link to the explanations in Fedora Docs at https://docs.fedoraproject.org/en-US/legal/license-approval/ if people want to understand what the status means.

In the Fedora-license-data, the "spdx_abbrev" field corresponds to an SPDX id, be it on the SPDX License List, or a LicenseRef- if not.

@goneall - let me know if it'd be helpful to talk through this on an upcoming SPDX-legal call or something. This might also be a good time to get an update on the status of the FSF-isfree and OSI-approved data alignment (not to add to this issue though)

[swinslow]

I haven't yet given this a lot of thought, but I'm generally +1 to adding a "Fedora approved" column if it can be easily automated.

I think this makes sense given that (1) Fedora is closely aligning with using SPDX identifiers, and (2) Fedora has a well-established community process for evaluating "allowed" licenses in accordance with FOSS principles, which we've recently taken into account in updating the SPDX review process to streamline adding Fedora-approved licenses.

[jlovejoy]

we don't have a label for this kind of thing, so I tagged it as discuss for now!

[mattdm]

So, for what it's worth, I think this would be great.

[jlovejoy]

I'm moving this for 3.25, but let's plan to discuss on whatever is the next legal call after the 3.24 release in May

Not sure what to label this, it's not really a "policy change" but more adding data to the SPDX License List as a whole.

@swinslow @richardfontana @mattdm @xsuchy @dcantrell for awareness

[jlovejoy]

discussed on Jun 13th call: see meeting notes, but key outcome regarding question of adding Fedora-approved column or any other for that matter: Criteria:

1. Must be automatable
2. Must be relevant to license inclusion criteria => applicable to inputs into License List as an "upstream" factor

[jlovejoy]

@jlovejoy to follow-up with Fedora team re: process for automating

[goneall]

We can automate this pas part of the license list publishing process if Fedora is (or plans to) publish the good list in a machine readable format.

[mattdm]

We can automate this pas part of the license list publishing process if Fedora is (or plans to) publish the good list in a machine readable format.

We do! The repository at https://gitlab.com/fedora/legal/fedora-license-data is authoritative, and the lists on our docs site are generated from there.

The main files are in TOML, and those are automatically assembled into https://gitlab.com/fedora/legal/fedora-license-data/-/jobs/artifacts/main/raw/fedora-licenses.json?job=json on every update.

[goneall]

Thanks @mattdm for the pointer - with just a brief review, it looks like the JSON file is pretty self explanatory.

If we want to include this information in the website and the SPDX license list data, it should be pretty straight-forward.

[xsuchy]

We even have the schema for that JSON https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/tools/fedora-license-schema.json?ref_type=heads

[jlovejoy]

putting @xsuchy and I as "assignees" on this and probably can remove the "discuss on legal call" label, as I think next steps are to:

• (generally) document the discussion as to criteria for the columns on the main page
• (specific to Fedora) connect the various people in terms of figuring out what need to be done on SPDX side to pull in that data

[xsuchy]

Hmm, I may work on that someday. But it is a very low priority for me.

[jlovejoy]

this was discussed from a more general standpoint (in terms of documenting these columns generally) on June 13, 2024 legal call

related task to start document as to these columns mean, how they work, requirements (see meeting minutes)

also impact data model

[jlovejoy]

moving this out to next release to keep on radar, although given the larger context of work, it may be more of a "Later Release"