On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote: > > So, I have just made another commit to the license packaging guidelines to update the sections on dual-licensing, multiple licenses and use of "with" for license exception over here: https://pagure.io/packaging-committee/pull-request/1142 > > In light of this thread, I'd suggest we update the first sentence of the Dual Licensing section to say, "If your package is dual licensed under a choice of two (or three, etc.) licenses and both licenses are "good" for Fedora, the License: field must reflect this by using "OR" as a separator. " and add the following to the Dual Licensing section: > > "If your package is licensed under a choice of two licenses and one is a "good" license and one is a "bad" license, then the License: field must reflect the "good" license only contain a comment explaining the original choice. > > Example: Package dbfoo is dual licensed under Affero General Public License v3 or Server Side Public License and Fedora considers the Server Side Public License as "bad". Note the choice in a comment above the License: field and the License field as follows: > > # The upstream package license is: AGPL-3.0-or-later OR SSPL-1.0 > License: AGPL-3.0-or-later I don't think this is a good idea. Obviously if a packager wants to put in such a comment they can, but I don't think this should be required or even recommended for the following reasons: First, it arguably creates more work for the packager to analyze licenses. Maybe in some cases this is work that the packager would be doing already, I realize. (For example, encountering SSPL-1.0, in your hypothetical, and verifying that it actually is a match to SPDX SSPL-1.0.) Second, and I think this is possibly the most important reason, in probably most cases of upstream Good License OR Bad License, the Bad license won't be in the SPDX list. What if the Bad license does not have a standard SPDX identifier -- would we want the packager to use a LicenseRef (after having gone to the trouble of verifying that the Bad license isn't on the SPDX list via the matching criterion)? The examples we've been talking about here - the "GPL or Artistic" classic case, or the "AGPL-3.0 OR SSPL-1.0" hypothetical -- are atypical because (certain versions of ) the Artistic License 1.0 are represented in the SPDX list as is SSPL version 1.0. If not LicenseRef, we surely wouldn't want to have the packager make up some arbitrary identifier (thus encouraging non-conformant SPDX-style license expression syntax). For example, we wouldn't want to have # Upstream license is GPL-2.0-or-later OR Proprietary. And certainly we wouldn't want to encourage the packager to waste time submitting a Bad license (already rejected by Fedora) to SPDX -- in most cases it likely wouldn't even meet SPDX inclusion criteria. Third, I am not seeing why the information about a non-carried-over upstream dual license is valuable (to mandate or even encourage). At best I'd say it's sometimes *interesting* information, but not worth having the packager use LicenseRef or departing from SPDX expression syntax or whatever (see previous comment). If the only reason left is to avoid offending Perl modules maintainers upstream, that's limited to the special case of Perl modules and I don't think that's a good enough reason :) I'm also somewhat concerned about generalizing the principle here (meaning, either we have inconsistent guidelines or we make even more work for the packager). Consider upstream packages that have source files stripped from the source tarball because the license is "bad", or for which source files under a "good" license are not reflected in the binary RPM. Richard _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
