looks like it shows the changes on a per-line level, which loses a bit of the detail, but hopefully it's followable

Do we have an updated version of the licensing page that has SPDX-equivalent identifiers for the Fedora identifiers? We shouldn't rely on an external unstable reference for this.

I guess I'm still pretty unclear on why the guidelines need to actually change for any of this. The guidelines say to use license tag from the list that Fedora Legal provides. Why does that need to change? The guidelines don't care whether that tag is from SPDX or something else; we use what Legal says to use. I don't think it's desirable to have packagers just go and pull from some non-Fedora-approved SPDX list, so I'm not sure why even mentioning that other lists of license tags exist is a good thing.

@ngompa - if by the "external unstable reference" - you mean the SPDX-Fedora comparison Google sheet I've been working diligently to get up-to-date - No, we would not rely on that. @dcantrell has been working on an improved data storage of the license data (improved over a table in the wiki) which will include corresponding SPDX identifiers for all approved Fedora licenses (still in use).

@tibbs - the guidelines say to use the Fedora id as listed in the Fedora license tables on the wiki. The change is to use SPDX ids. Many of the Fedora and SPDX ids are the same, but there are variations. This was discussed on a previous issue #971 - but happy to fill in any gaps as needed.

As for what constitutes an "approved" or "good" license for Fedora - there is no change there.

@ngompa - if by the "external unstable reference" - you mean the SPDX-Fedora comparison Google sheet I've been working diligently to get up-to-date - No, we would not rely on that. @dcantrell has been working on an improved data storage of the license data (improved over a table in the wiki) which will include corresponding SPDX identifiers for all approved Fedora licenses (still in use).

What i mean is that whatever identifiers we use should be on the Fedora Licensing page. We should not redirect people to spdx.org or anywhere else. Those are implementation details that packagers must not care about.

@ngompa - if by the "external unstable reference" - you mean the SPDX-Fedora comparison Google sheet I've been working diligently to get up-to-date - No, we would not rely on that. @dcantrell has been working on an improved data storage of the license data (improved over a table in the wiki) which will include corresponding SPDX identifiers for all approved Fedora licenses (still in use).

What i mean is that whatever identifiers we use should be on the Fedora Licensing page. We should not redirect people to spdx.org or anywhere else. Those are implementation details that packagers must not care about.

Right now that information is in the old Fedora wiki but not actively owned or maintained by anyone. Adjacent to this PR but separate is the creation of a new set of docs for the Fedora Legal team which involves documenting our process for proposing, approving, and then documenting approved licenses. I say this adjacent because going forward the approval process should favor using SPDX expressions which will then be put in the table of approved licenses.

You're right that we can't just point to spdx.org and tell people to use that, because that's just a list of identifiers and a spec. Fedora Legal will approve derived SPDX expressions which may or may not map directly to a single SPDX short name. For instance, Fedora Legal could hypothetically approve (AND THIS IS PURELY A HYPOTHETICAL EXAMPLE) "Artistic-1.0 AND GPL-3.0-or-later" but that does not mean Fedora packagers are free to use "Artistic-1.0" by itself. Package Maintainers will have to continue to review the list of approved Fedora licenses and what to put in the RPM spec file.

+The +License:+ field for new packages as of the Fedora Linux 36 branch date (2022-02-08) must be filled with the appropriate SPDX License identifier or expression from the SPDX License List and listed as a "Good License" on the {fedora-licensing} page.

I'm not sure if it makes sense to write a date here. People generally add new packages to multiple Fedora releases after they are reviewed and approved, so packages with the new license tags will appear in old releases too inevitably. I think it's simpler and sufficient to say "The License field for new packages must be filled with …".

I guess I'm still pretty unclear on why the guidelines need to actually change for any of this. The guidelines say to use license tag from the list that Fedora Legal provides. Why does that need to change? The guidelines don't care whether that tag is from SPDX or something else; we use what Legal says to use. I don't think it's desirable to have packagers just go and pull from some non-Fedora-approved SPDX list, so I'm not sure why even mentioning that other lists of license tags exist is a good thing.

Yeah, that's how I'd see it too. Instead of saying

the appropriate SPDX License identifier or expression from the SPDX License List and listed as a "Good License" on the {fedora-licensing} page.

just say

listed as a "Good License" on the {fedora-licensing} page.

This is all that packagers need to care about.

I think it's useful for packagers (new and old) to know that the identifiers we are (now) using are SPDX change, and useful (particularly for us old-timers) to highlight that the format has changed.

Maybe something like:

• The +License:+ field for new packages must be filled with the appropriate SPDX License identifier or expression from the "Good License" list on the {fedora-licensing} page.

?

If we change the paragraph above to mention SPDX but not the list per se, perhaps this line could be:

SPDX is an international standard. It provides identifiers for each individual license or exception based on a set of matching guidelines.

I expected to find a section on how to construct an SPDX license expression for these examples below somewhere.

Based on @tibbs and @zbyszek's comments, maybe the whole how to identify a license section could be moved to the Legal docs rather than being listed here?

I think it's useful for packagers (new and old) to know that the identifiers we are (now) using are SPDX change, and useful (particularly for us old-timers) to highlight that the format has changed.

Maybe something like:

• The +License:+ field for new packages must be filled with the appropriate SPDX License identifier or expression from the "Good License" list on the {fedora-licensing} page.

?

good idea, that is more concise. commit added here https://pagure.io/fork/jlovejoy/packaging-committee/c/7778e9ca1521b58654f86985ae672384d9ff480e?branch=license-packaging-update (correctly I think?)

re: @mattdm other comments:

• I was trying to provide a short description of the SPDX License List (only) not the entire SPDX standard. Adding a link for "more info" would be better than getting too detailed here.

• I still need to go through the existing license expression section of the packaging guidelines and update that. Didn't want to make one PR too big, but if that doesn't matter I can start working on that next??

• re: "how to identify a license" - 6 in 1, half dozen the other, but let's keep it here for now and once we start moving the wiki licensing-main page content to docs, we can reexamine?

@ngompa - if by the "external unstable reference" - you mean the SPDX-Fedora comparison Google sheet I've been working diligently to get up-to-date - No, we would not rely on that. @dcantrell has been working on an improved data storage of the license data (improved over a table in the wiki) which will include corresponding SPDX identifiers for all approved Fedora licenses (still in use).

Side note: There is already a maintained reference for mapping license identifiers from SPDX to those used by Fedora; and it's in "production use" in various .spec file generators:

https://pagure.io/fedora-rust/rust2rpm/blob/main/f/rust2rpm
(data in spdx_to_fedora.csv , reusable python module in licensing.py)

I know that this is used in at least the .spec generators for Rust packages (rust2rpm), I think the one for Go packages uses this functionality too, and I seem to remember the in-progress ocaml .spec file generator also used that python module from rust2rpm.

Based on @tibbs and @zbyszek's comments, maybe the whole how to identify a license section could be moved to the Legal docs rather than being listed here?

Possibly. I think one problem here is that "what you put in the License: tag" and "how you identify a license" are not synonymous (or supposed to be synonymous). Since this is a potentially huge topic it might be better to isolate it to a separate document.

BTW @jlovejoy I now realize something that had been confusing me which is that (I think) you are taking the concept of "license identifier" and forming the verb phrase "identify a license" from it, and I have not seen that phrase used elsewhere. I think this is confusing because license identifiers don't actually identify licenses. In package metadata they might in some cases serve that function; in other cases they might instead represent a judgment about how to describe the licensing of a package (which I see as differerent from "identifying" that licensing). The term "identifier" was, I believe, borrowed by SPDX from programming language jargon where "identifier" is basically a synonym, and arguably a misnomer, for "symbol" and has no larger semantic significance. SPDX license identifiers are license symbols. Their purpose is not to "identify" anything except maybe coincidentally (as in the SPDX-License-Identifier construct when properly used). But maybe we should discuss this further offline :-)

I think we should just get rid of this sentence. It raises a complicated question about FOSS compliance norms that I don' t think this document should necessarily get into.

I would rephrase (see my comment in the Comments on why it is problematic to talk about "identifying ... the license" here). Maybe:
The information here provides some guidance on licensing issues for Fedora packagers.

In general I don't think Fedora packagers should be encouraged to affirmatively do this stuff (I know this has been here for a long time). I guess the edit is okay but if you take license text from the SPDX list in its current form you'll end up with template license texts in at least some cases (which may be okay?). I suppose it would be helpful to know how often Fedora packagers are actually following this guidance and adding in license files that aren't present upstream.

Suggest deleting this sentence. In pretty much every case things in Fedora marked as being "Public Domain" are actually under copyright licenses. I think this sentence might make a confusing situation a little more confusing.

In general I don't think Fedora packagers should be encouraged to affirmatively do this stuff (I know this has been here for a long time). I guess the edit is okay but if you take license text from the SPDX list in its current form you'll end up with template license texts in at least some cases (which may be okay?). I suppose it would be helpful to know how often Fedora packagers are actually following this guidance and adding in license files that aren't present upstream.

I looked into that for @jlovejoy at one point, and while I can't right now find the conversation or remember exactly how I looked, I did find several recent examples.

See my comment on the phrase "identify a license" which I think is confusing - presumably a back formation from "license identifier". What we need somewhere is a "How do I figure out what license identifier to put in the license tag?" -- which is not necessarily going to be equivalent to "how do I figure out what the actual set of operative license terms are for this package/this set of source files/"etc.

In general I don't think Fedora packagers should be encouraged to affirmatively do this stuff (I know this has been here for a long time). I guess the edit is okay but if you take license text from the SPDX list in its current form you'll end up with template license texts in at least some cases (which may be okay?). I suppose it would be helpful to know how often Fedora packagers are actually following this guidance and adding in license files that aren't present upstream.

I looked into that for @jlovejoy at one point, and while I can't right now find the conversation or remember exactly how I looked, I did find several recent examples.

Right, I remember now. So there's an interesting policy issue here. I think the current approach largely reflects the views of @spot. I can tell you that in other parts of the Red Hat universe we do not routinely attempt to supply license files downstream that weren't present upstream, if the licensing is otherwise clear. (Indeed we have some reason to encourage the view that inclusion of a license file is not necessary in all cases.) Whether we should or not is a complicated topic.

I have made a few more commits with edits trying to address @ref various comments

What is the process for getting this accepted? I realize we have identified some additional areas needed for documentation or improved explanations - most notably here, the whole section dealing with multiple licenses needs to also be updated - but will that make for too much for one PR? or would it be better to merge this and iterate in another chunk?

What is the process for getting this accepted?

I think that once this was merged, then this would be public and in effect.

Therefore this activity should be officially announced somewhere, probably via Fedora change process?

The +License:+ field for new packages must be filled with the appropriate SPDX License identifier or expression from the "Good License" on the {fedora-licensing} page."

Also, I might read this statement ^^ wrong, but it gives me impression, that the Fedora license page should be amended with SPDX identifiers. Such preparation steps should precede merging this.

BTW there is no explanation, not even reference, what the SPDX actually is.

I continue to have problems with the phrase "identify the license". :-) Can't we just say what we're really talking about here:
"The information here provides guidance on how to populate the LIcense: field of spec files for Fedora packages."
This is not about license determination in any stronger sense than that. If the existing document (prior to your changes) suggests that then this is a good opportunity to change that.

I think this sentence is a little confusingly worded. Maybe:
"SPDX license expressions cover situations where multiple licenses apply to a package, where there is a choice of a license, and where licenses are coupled with exceptions or additional permissions. "

I would say "for specific forms of public domain dedications". Otherwise I think this might be confusing.

I continue to recommend strongly that this section be removed to a separately-developed document. Just as one example, this section doesn't seem to get into the important issue of what to ignore. It seems to assume that license description for purpose of filling in the License: field is simply a matter of using matching tools on license texts in source files. That might be what we want to ultimately recommend, but I'm not sure.

I continue to have problems with the phrase "identify the license". :-) Can't we just say what we're really talking about here:
"The information here provides guidance on how to populate the LIcense: field of spec files for Fedora packages."
This is not about license determination in any stronger sense than that. If the existing document (prior to your changes) suggests that then this is a good opportunity to change that.

done in latest commit

I think this sentence is a little confusingly worded. Maybe:
"SPDX license expressions cover situations where multiple licenses apply to a package, where there is a choice of a license, and where licenses are coupled with exceptions or additional permissions. "

done in latest commit

I would say "for specific forms of public domain dedications". Otherwise I think this might be confusing.

done in latest commit

What is the process for getting this accepted?

I think that once this was merged, then this would be public and in effect.

yes, that is true. And we have a few other interrelated parts...

Therefore this activity should be officially announced somewhere, probably via Fedora change process?

I defer to @mattdm on that question!

The +License:+ field for new packages must be filled with the appropriate SPDX License identifier or expression from the "Good License" on the {fedora-licensing} page."

Also, I might read this statement ^^ wrong, but it gives me impression, that the Fedora license page should be amended with SPDX identifiers. Such preparation steps should precede merging this.

correct @dcantrell is working on an updated database for the license info (good/bad, etc.) which will also include matched SPDX ids. So we need to have that ready at the same time.

BTW there is no explanation, not even reference, what the SPDX actually is.

yes, I struggled with this, as I didn't want to take up precious space here in the packaging guidelines for that. Perhaps a short blurb on the general licensing page would be a better spot and then that can be referenced here?

I also have just made a few more commits to update the sections on dual-licenses, etc.

I don't think in practice mentioning SPDX even matters for this. We could have a small informational blurb about the origin of the new identifiers, but we're not changing anything but the identifiers, and the identifiers are going to be imported into our documentation.

So the fact they're from SPDX is only mildly informational.

Therefore this activity should be officially announced somewhere, probably via Fedora change process?

I defer to @mattdm on that question!

I agree it should be announced, but I think we came to the conclusion that this is fundamentally a Fedora Legal decision, with help from packaging committee on implementation details, so maybe going through FESCo for the Change process isn't right. ( @bcotton , thoughts?)

It might just be something for Community Blog + devel announce.

Therefore this activity should be officially announced somewhere, probably via Fedora change process?

I defer to @mattdm on that question!

I agree it should be announced, but I think we came to the conclusion that this is fundamentally a Fedora Legal decision, with help from packaging committee on implementation details, so maybe going through FESCo for the Change process isn't right. ( @bcotton , thoughts?)

It might just be something for Community Blog + devel announce.

It certainly could go through the Changes process. That said, I think it's probably better treating more like the Council's Policy Change Policy. (TL;DR: two week community comment period after being announced on the Community Blog and then an approval decision)

Therefore this activity should be officially announced somewhere, probably via Fedora change process?

I defer to @mattdm on that question!

I agree it should be announced, but I think we came to the conclusion that this is fundamentally a Fedora Legal decision, with help from packaging committee on implementation details, so maybe going through FESCo for the Change process isn't right. ( @bcotton , thoughts?)

It might just be something for Community Blog + devel announce.

I don't disagree.

I just think that this topic is in heart of Fedora development and we don't actually have better process.

But whatever form it takes, the sooner the better IMO. Not because somebody wanted to prevent it, but because somebody would like to help. E.g. I am very interested in the form of the new organization of the License wiki and the source data. I think this is opportunity to utilize some automation to check the content of License tag and also opportunity to deduplicate license files in Fedora. And also oportunity to simplify our package generators, where upstream already uses SPDX.

New commits to updates as per various discussions.

The larger project this is part of is now being tracked here: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1

hi all - a thought to bounce off you all: as @ref and I review all the legal/licensing related documentation from the wiki, revise as needed, and re-organize into what will become a new Fedora Docs section for fedora-legal, we wondered if these package guidelines should be more concise. For example, there are a bunch of examples and explanations included here, but perhaps these guidelines should stick to a more concise instruction of what to put in the License: field of the spec file, and move more "color" (e.g., examples, explanations, etc.) to the Fedora-legal Docs pages. Thoughts?

This sounds reasonable. Our old docs were often very verbose and uncoordinated. So if we can get rid of a something that is already described elsewhere, this is generally a win.

Can you add a link to SPDX Expressions spec https://spdx.github.io/spdx-spec/SPDX-license-expressions/ ?

@msuchy - in line with the comment above about moving out examples and more explanatory text, the examples for composite licenses will be in a new Fedora-legal docs page, along with a more thorough explanation of the license-of-the-binary policy. I will add links to the SPDX Spec there. (which reminds me... that part of the SPDX Spec could use some updating too... sigh)

I see that FESCO has approved the Change Proposal for the adoption of SPDX ids https://pagure.io/fesco/issue/2799

We are aiming to "go live" with the new Fedora-legal documentation, license data repo, and SPDX id adoption on Wednesday, July 27th. A key piece of that will be getting this PR merged.

Can someone merge this PR on Tuesday evening or Wednesday morning (US time)? - but not before then, as I have a few more things to update!

That way if there are formatting issues, typos, etc, we can try to get them fixed so everything is live and pretty by Wednesday afternoon.

Additional updates to consolidate "how to" info in our new Fedora-docs page with examples and policy on this.

Also updated a bunch of links

I think we should take out this recommendation altogether rather than supplementing it by mentioning the SPDX license list. The problem with the SPDX list is that the SPDX license tempaltes are generally not designed for inclusion in a source repository.

I think we should take out this recommendation altogether rather than supplementing it by mentioning the SPDX license list. The problem with the SPDX list is that the SPDX license tempaltes are generally not designed for inclusion in a source repository.

I think we should take out this recommendation altogether rather than supplementing it by mentioning the SPDX license list. The problem with the SPDX list is that the SPDX license tempaltes are generally not designed for inclusion in a source repository.

yeah, or it should be stated more accurately. You are thinking of the XML templates and you are right. But the SPDX license-list-data repo has files that are usable for this purpose. In any case, that requires a more advanced explanation at this point, when/if SPDX has that explicitly documented, we can potentially add back/point to that

1192 and #1194

other updates related to this: https://pagure.io/packaging-committee/pull-request/1192 and https://pagure.io/packaging-committee/pull-request/1194

@tibbs - this is ready to merge!
(and then I will likely have to check for proper links and typos and do another merge request)

1192 and #1194 are also ready!