On Wed, Jan 12, 2022 at 12:17 AM Richard Fontana <rfontana(a)redhat.com> wrote:
On Tue, Jan 11, 2022 at 10:49 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> 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