PR#1142: Update Packing Guidelines for Licensing to enable SPDX identifiers - packaging-committee

		`@@ -5,16 +5,20 @@`

		`== Fedora Licensing`

		`- The goal of the Fedora Project is to work with the Linux community to create a complete, general purpose operating system exclusively from Free and Open Source software.`
		`+ The goal of the Fedora Project is to work with the Linux community to create a complete,`
		`+ general purpose operating system exclusively from free and open source software.`

		`- All software in Fedora must be under licenses in the {fedora-licensing-list}.`
		`- This list is based on the licenses approved by the`
		`+ All software in Fedora must be under licenses that has been determined to be https://docs.fedoraproject.org/en-US/legal/license-approval/[allowed for Fedora].`
		`+ This criteria is based on the licenses approved by the`
		`https://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses[Free Software Foundation],`
		`https://opensource.org/licenses/[OSI]`
		`and consultation with Red Hat Legal.`

		`- If code is multiple licensed, and at least one of the licenses is approved for Fedora,`
		`- that code can be included in Fedora under the approved license(s) (but only under the terms of the approved license(s)).`
		`+ For more details on the criteria for allowed and not-allowed licenses, questions related to process,`
		`+ or other helpful guidance related to Fedora licensing, see https://docs.fedoraproject.org/en-US/legal/[Licensing in Fedora].`
		`+`
		+ The information here provides guidance on how to add license text in `+%license+` and how to populate the `+License:+` field of
		`+ spec files for Fedora packages.`

		`== License Text`

		`@@ -26,7 +30,6 @@`
		`the packager should do their best to point out this confusion to upstream.`
		`This sometimes occurs when an upstream project's only reference to a license is in a README (where they simply say "licensed under the FOO license"), on their website,`
		`or when they simply do not check a copy of the license into their Source tree.`
		`- Common licenses that require including their texts with all derivative works include ASL 2.0, EPL, BSD and MIT.`
		`Packagers should point out to upstream that by not including a proper full license text,`
		`they are making it difficult or impossible for anyone to comply with their desired license terms.`

		`@@ -39,8 +42,8 @@`
		`they can easily remedy this by making full license text available in the source code.`
		`Packagers who choose to do this should ensure that they have exhausted all attempts to work with upstream to include the license text as part of the source code,`
		`or at least, to confirm the full license text explicitly with the upstream, as this minimizes the risk on the packager.`
		`- Packagers should also take copies of license texts from reliable and canonical sources`
		`- (such as the Fedora Software Licenses page, the FSF licenses page, or the OSI license list), whenever possible.`
		`+ Packagers may also take copies of license texts from reliable and canonical sources`
		`+ (such as the original license text from the license steward, Fedora licenses page, the FSF licenses page, or the OSI license list), whenever possible.`

		`* Choose not to package that software for Fedora.`

		`@@ -62,9 +65,6 @@`
		`In cases where the licensing is unclear, it may be necessary to contact the copyright holders to confirm the licensing of code or content.`
		`In those situations, it is _always_ preferred to ask upstream to resolve the licensing confusion by documenting the licensing and releasing an updated tarball.`
		`However, this is not always possible to achieve.`
		`- In such cases, it is acceptable to receive confirmation of licensing via email.`
		`- A copy of the email, containing full headers, must be included as a source file (marked as %license) in the package.`
		`- This file is considered part of the license text.`

		`== License: field`

		`@@ -73,147 +73,26 @@`
		but maintainers must make every possible effort to be accurate when filling the `+License:+` field.

		`The License: field refers to the licenses of the contents of the _binary_ rpm.`
		`- When in doubt, ask.`

		`- If a source package generates multiple binary packages, the License: field may differ between them if necessary.`
		`- This implies that a single spec may have multiple per-subpackage License: tags.`
		`- Each of those License: tags must comply with all applicable guidelines.`
		`+ This policy and examples can be found at https://docs.fedoraproject.org/en-US/legal/license-field/[License: field in Spec file].`

		`=== Valid License Short Names`

		- The `+License:+` field must be filled with the appropriate license Short License identifier(s) from the "Good License" tables on the {fedora-licensing} page.
		`- If your license does not appear in the tables, it needs to be sent to legal@lists.fedoraproject.org (note that this list is moderated, only members may directly post).`
		`- If the license is approved, it will be added to the appropriate table.`
		`-`
		`- === "Distributable"`
		`-`
		- In the past, Fedora (and Red Hat Linux) packages have used "Distributable" in the `+License:+` field.
		`- In virtually all of these cases, this was not correct.`
		`- Fedora no longer permits packages to use "Distributable" as a valid License.`
		`- If your package contains content which is freely redistributable without restrictions,`
		`- but does not contain any license other than explicit permission from the content owner/creator,`
		- then that package can use "Freely redistributable without restriction" as its `+License:+` identifier.
		`-`
		`- === Firmware`
		`-`
		- The `+License:+` field for any firmware that disallows modification should be set to: "Redistributable, no modification permitted".
		`-`
		`- === Versioned licenses`
		`-`
		`- Some licenses include the version as part of the Short License Identifier.`
		`- This is only done when multiple versions of the license differ in significant ways (e.g.`
		`- one revision is GPLv2 incompatible, while a later version is not).`
		`- Be careful to ensure that you use the correct Short License Identifier, as shown in the tables on the {fedora-licensing} page.`
		`-`
		`- === "or later version" licenses`
		`-`
		`- Some licenses state that either the current version of the license or later versions may be used.`
		`- It is important to note when a license states this.`
		`- When a license has an "or later version" clause, we note that by appending a + to the Short License Identifier.`
		`- Please note that there are already special Short License Identifiers for GPLv2+ and LGPLv2+, there is no need to append an additional + for those cases.`
		`-`
		`- === GPL and LGPL`
		`-`
		- Since compatibility of code and library linking is especially complex with GPL and LGPL, Fedora packages can no longer simply use "GPL" or "LGPL" in the `+License:+` field.
		`- Please refer to the {fedora-licensing} page for the acceptable identifiers, and be careful to ensure that you select the correct one.`
		`-`
		`- === Dual Licensing Scenarios`
		`-`
		`- If your package is dual licensed (or triple licensed, etc.), the spec must reflect this by using "or" as a separator.`
		`- Note that this only applies when the contents of the package are actually under a dual license,`
		`- and not when the package contains items under multiple, distinct, and independent licenses.`
		`-`
		`- Example:`
		`- Package libfoo is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later.`
		`- The package spec must have:`
		`-`
		`- ....`
		`- License: MPLv1.1 or GPLv2+`
		`- ....`
		`-`
		`- === Multiple Licensing Scenarios`
		`-`
		`- If your package contains files which are under multiple, distinct, and independent licenses, then the spec must reflect this by using "and" as a separator.`
		`- Fedora maintainers are highly encouraged to avoid this scenario whenever reasonably possible,`
		- by dividing files into subpackages (subpackages can each have their own `+License:+` field).
		`-`
		`- Example:`
		`- Package bar-utils contains some files under the Python License, some other files under the GNU Lesser General Public License v2 or later,`
		`- and one file under the BSD License (no advertising).`
		`- The package spec must have:`
		`-`
		`- ....`
		`- License: Python and LGPLv2+ and BSD`
		`- ....`
		`-`
		`- In addition, the package must contain a comment explaining the multiple licensing breakdown.`
		`- The actual implementation of this is left to the maintainer.`
		`- Some suggested implementations include`
		`-`
		- * A comment right above the `+License:+` field:
		`-`
		`- ....`
		`- # The entire source code is GPLv2+ except foolib/ which is BSD`
		`- License: GPLv2+ and BSD`
		`- ....`
		`-`
		- * Including a file as `+%license+` which contains the licensing breakdown for the packaged files, then using:
		`-`
		`- ....`
		`- # For a breakdown of the licensing, see PACKAGE-LICENSING`
		`- ....`
		`-`
		`- * Noting the license above the appropriate %files section:`
		`-`
		`- ....`
		`- %files`
		`- %doc Changes`
		`- # Python`
		`- %{_bindir}/cobra-util`
		`- %{_bindir}/viper-util`
		`- # LGPLv2+`
		`- %{_bindir}/gnu-util`
		`- %{_bindir}/rms-util`
		`- # BSD`
		`- %{_bindir}/berkeley-util`
		`- ....`
		`-`
		`- === Combined Dual and Multiple Licensing Scenario`
		`-`
		`- If you are unlucky enough that your package possesses items multiple, distinct, and independent licenses...AND some of those items are dual licensed,`
		`- you must note the dual licensed items by wrapping them with parenthesis ().`
		`- Otherwise, the guidelines for Dual and Multiple Licensing apply.`
		`-`
		`- Example:`
		`- Package baz-utils contains some files under the Python License, some other files under the GNU Lesser General Public License v2 or later,`
		`- one file under the BSD License, no advertising, and one file which is dual licensed as Mozilla Public License v1.1 and GNU General Public License v2 or later.`
		`- The package spec must have:`
		`-`
		`- ....`
		`- License: Python and LGPLv2+ and BSD and (MPLv1.1 or GPLv2+)`
		`- ....`
		+ The `+License:+` field for new packages as of July 2022 must be filled with the appropriate SPDX license identifier or
		`+ expression from the list of https://docs.fedoraproject.org/en-US/legal/allowed-licenses/[allowed licenses for Fedora.`
		`+ Note that some licenses may be allowed for only certain types of material, e.g., fonts, content, or documentation.`

		`- Since this is a multiple licensing scenario, the package must contain a comment explaining the multiple licensing breakdown.`
		`- The actual implementation of this is left to the maintainer.`
		`+ The SPDX License List provides identifiers for each individual license or exception based on a set of matching guidelines.`
		`+ For example, licenses that have different versions or options related to later versions have specific identifiers.`
		`+ 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.`

		`- === Mixed Source Licensing Scenario`
		+ https://docs.fedoraproject.org/en-US/legal/license-field/[License: field in Spec file] contains examples and further explanations for using SPDX expressions in the `License:` field.

		`- In some cases, it is possible for a binary to be generated from multiple source files with compatible, but differing licenses.`
		`- Thus, the binary file would actually have simultaneous dual licensing (an AND, as opposed to an OR).`
		`- For example, it is possible that a binary is generated from a source file licensed as BSD with advertising,`
		`- and another source file licensed as QPL (which specifies that modifications must be shipped as patches).`
		`- In this scenario, we'd wrap the list of licenses for that binary with parenthesis, example:`
		`+ For more information on what to do if you find a license that is not on the Fedora list,`
		`+ does not have a corresponding SPDX license identifier or expression, or other process questions, see https://docs.fedoraproject.org/en-US/legal/license-review-process/[License Review Process].`

		`- Package spot-utils contains some files under the Python License, but one of the files is generated from a BSD with advertising source file and a QPL source file.`

		`- ....`
		`- License: Python and (BSD with advertising and QPL)`
		`- ....`

		`- == Public Domain`
		`+`

		`- Works which are clearly marked as being in the Public Domain, and for which no evidence is known to contradict this statement,`
		`- are treated in Fedora as being in the Public Domain, on the grounds that the intentions of the original creator are reflected by such a use, even if due to regional issues,`
		`- it may not have been possible for the original creator to fully abandon all of their their copyrights on the work and place it fully into the Public Domain.`
		`- If you believe that a work in Fedora which is marked as being in the Public Domain is actually available under a copyright license,`
		`- please inform us of this fact with details, and we will immediately investigate the claim.`

jlovejoy commented 3 years ago

This PR represents a series of commits to update the Packaging Guidelines for Licensing to enable the use of SPDX identifiers.

There is more that needs to be updated and I need to go back and fix links, but this seemed like enough for a start.

Note: I'm not so Git savvy and used the Pagure GUI for all of this... which is a bit challenging due to no word-wrapping. Please be kind if this ends up looking messy :)

Signed-ff-by: JLovejoy

jlovejoy commented 3 years ago

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

ngompa commented 3 years ago

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.

tibbs commented 3 years ago

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.

jlovejoy commented 3 years ago

@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 commented 3 years ago

@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.

dcantrell commented 3 years ago

@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.

zbyszek commented 3 years ago

+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.

mattdm commented 3 years ago

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.

mattdm commented on line 41 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

mattdm commented on line 44 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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

mattdm commented 3 years ago

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?

1 new commit added

update sentence re: license field

3 years ago

jlovejoy commented 3 years ago

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?)

jlovejoy commented 3 years ago

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?

decathorpe commented 3 years ago

@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.

ref commented 3 years ago

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 :-)

Edited 3 years ago by ref

ref commented on line 16 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

ref commented on line 7 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

ref commented on line 28 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

Edited 3 years ago by ref

ref commented on line 87 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

mattdm commented 3 years ago

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.

ref commented on line 46 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

ref commented 3 years ago

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.

1 new commit added

remove sentence re: common licenses require text

3 years ago

1 new commit added

modified title of section and added a bit to lead-in

3 years ago

jlovejoy commented 3 years ago

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?

vondruch commented 3 years ago

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.

ref commented on line 7 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

ref commented on line 42 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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. "

ref commented on line 83 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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

ref commented on line 46 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 3 years ago

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.

Edited 3 years ago by ref

1 new commit added

wording improvements

3 years ago

jlovejoy commented 3 years ago

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

jlovejoy commented 3 years ago

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

jlovejoy commented 3 years ago

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

done in latest commit

1 new commit added

update section on license expressions

3 years ago

1 new commit added

add section on exceptions

3 years ago

1 new commit added

fix spacing on headers

3 years ago

jlovejoy commented 3 years ago

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.

ngompa commented 3 years ago

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.

mattdm commented 3 years ago

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.

bcotton commented 3 years ago

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)

vondruch commented 3 years ago

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.

1 new commit added

update good/bad language to allowed/not-allowed

2 years ago

1 new commit added

Update to section on dual-licensing

2 years ago

1 new commit added

remove process related items

2 years ago

1 new commit added

add note at top

2 years ago

jlovejoy commented 2 years ago

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

jlovejoy commented 2 years ago

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?

zbyszek commented 2 years ago

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.

msuchy commented on line 76 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 2 years ago

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

1 new commit added

additional wording updates to intro text

2 years ago

1 new commit added

update sections on distributable, public domain, and firmware

2 years ago

1 new commit added

remove composite license examples

2 years ago

jlovejoy commented 2 years ago

@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)

jlovejoy commented 2 years ago

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.

1 new commit added

update links in first section

2 years ago

1 new commit added

update more links to new docs

2 years ago

1 new commit added

remove bit on public domain

2 years ago

1 new commit added

remove bit on "distributable to move to new licensing docs

2 years ago

1 new commit added

remove bit on firmware to move to new licensing docx

2 years ago

1 new commit added

remove composite license bit and update more links

2 years ago

jlovejoy commented 2 years ago

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

ref commented on line 43 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 2 years ago

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.

ref commented on line 43 of guidelines/modules/ROOT/pages/LicensingGuidelines.adoc 2 years ago

jlovejoy commented 2 years ago

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

1 new commit added