Daniel P. Berrangé wrote: > On Tue, Sep 19, 2023 at 08:06:45AM +0200, Björn Persson wrote: > > Richard Fontana wrote: > > > I basically don't recognize "effective license" as a valid concept. I > > > see people using it, perhaps increasingly, but I never see any > > > definition of what it means. > > > > Here's an attempt at a definition of "effective license": > > > > Suppose I have a package with several source files, some of which are > > licensed as GPL-2.0-or-later and others as GPL-3.0-or-later. All the > > source files are compiled into a single executable file. > > > > GPL-3.0-or-later does not allow me to convey the executable as > > GPL-2.0-only. GPL-2.0-or-later allows me to convey it as GPL-3.0-only > > or a hypothetical later version. Thus the executable is – effectively – > > covered by the terms of GPL-3.0-or-later. I'd say that the effective > > license of the executable is GPL-3.0-or-later. > > > > If license x allows replacing itself with license y, then (x AND y) > > simplifies into y. The effective license of a combined work is y. > > The problem I have with this kind of "effective" analysis is that > it can lead to a rather misleading presentation of the license > of a package. > > Consider that the package has 10,000 source files, of which > 9999 are GPL-2.0-or-later, and 1 is GPL-3.0-or-later. Lets say > the 9999 files are compiled into 1 binary, and the single 3.0 > file is compiled into 2nd binary. Then the effective license of binary 1 is GPL-2.0-or-later, and the effective license of binary 2 is GPL-3.0-or-later. > The effective analysis rule > says we should express the license of the RPM package as > GPL-3.0-or-later, even though the overwhealming majority of > the package is GPL-2.0-or-later. To prevent misunderstandings like that, I included the following paragraph in my previous message: > > All of the above applies only when sources under different licenses are > > combined to form a program or library based on those sources. It does > > not apply when a package contains multiple separate programs under > > different licenses. SPDX expressions don't make that distinction. Because two separate binaries under different licenses do not simplify into one binary under one license, the best way that SPDX can express the licenses in your package is "GPL-2.0-or-later AND GPL-3.0-or-later". > I view that as intentionally > misleading on the part of Fedora, so am very happy we dropped > the effective analysis practice for RPM spec license tags. Has anyone actually argued in favor of such misrepresentation of licenses, or are you just knocking down strawmen? > It also had a result of changing license changes on rebases > to new versions, even if the existing binaries were not > changed. eg libfoo.so was GPL-2.0-or-later, and then a new > release added a libbar.so as GPL-3.0-or-later. The RPM package > would have to be changed to say 3.0-or-later by effective > license doctrine, despite the pre-existing libfoo.so (that > everyone currently uses) remaining 2.0-or-later. If the new version of libfoo were linked to libbar, and you take the stance that dynamic linking makes a "covered work" in the GPL sense the same way as static linking does, then that would make GPL-3.0-or-later the effective license of libfoo. In that case it would be correct to change the license field of the RPM package to GPL-3.0-or-later. If libfoo were not linked to libbar, or if dynamic linking does not make a "covered work" (which seems to be the Fedora Project's stance), then the effective license of libfoo would remain GPL-2.0-or-later. In that case the license field of the RPM package would become "GPL-2.0-or-later AND GPL-3.0-or-later". To make that clear I included the following paragraph in my previous message: > > All of the above applies only when sources under different licenses are > > combined to form a program or library based on those sources. It does > > not apply when a package contains multiple separate programs under > > different licenses. SPDX expressions don't make that distinction. > > If licenses x and y contradict each other, so that it's impossible to > > comply with both, then the effective license is nil. Such a combined > > work is not allowed. > > That would be true from the POV of a single binary, but not true > from the POV of a package RPM spec. We aggregate the license of > everything in the RPM, so it is valid for the RPM spec to include > incompatible license sets. Correct. That's why I included the following paragraph: > > All of the above applies only when sources under different licenses are > > combined to form a program or library based on those sources. It does > > not apply when a package contains multiple separate programs under > > different licenses. SPDX expressions don't make that distinction. Björn Persson
Attachment:
pgplAaGnQJrFl.pgp
Description: OpenPGP digital signatur
_______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
