On Wed, Jan 12, 2022 at 12:17 AM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > > 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. Forgot to add: while I think situations where you can't (conveniently) use SPDX expressions will predominate in these cases, I also think that these situations are going to be relatively uncommon -- certainly outside the Perl case (which goes away if we decide the (?) Artistic License 1.0 is "good" which I think is reasonably possible at this point). So I think that also suggests not making this a requirement. If the goal is to document the packager's judgment process, then there are a lot of other things the packager might be expected to comment on, depending on what philosophy of license description (if any) we want to specifically adopt. So we might end up with a requirement for comments in most cases, which is probably not going to be popular. 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
