Dne 19. 09. 23 v 16:20 Daniel P. Berrangé napsal(a):
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. 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. 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. 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. On the topic of updates/rebases, I think the effective license analysis made maintainers jobs harder, because it is intentionally discarding information about what licenses have been seen to exist. So on update, if you determine the list of current licenses you have to re-do the effective analysis each time, to see if you end up with the same minimised result currently listed in the RPM. IOW the effective analysis is a continuous ongoing cost burden to maintainers which cannot be automated unless someone documents an effective analysis logic rule for every SPDX license pairing.If licenses x and y are compatible, so that it's possible to comply with the terms of both simultaneously, but neither allows replacing itself, then the effective license of a combined work is (x AND y). 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.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.This is one of the reasons why I think we should not try to form complex SPDX expressions with both AND and OR terms. IMHO we should just have a simple enumeration of SPDX license names that have been found to exist.
This makes a lot of sense. The simple enumeration would be enough IMHO and it would certainly simplify packagers life.
Vít
Without being able to distinguish the different components within the package, presenting a more complex SPDX expression is of no practical value IMHO.That's not to say that people haven't been simplifying licenses more than the licenses actually allow. It may well be that combinations that can be simplified are very rare outside of the GPL family.The GPL family is special because by design the "or later" clause lets you form a linear sequence of licenses, such that A can be replaced with B. In the general case for any given pair of licenses there's no clearly defined rule. For some pairings of permissive license the effective simplification is likely to be an entirely arbitrary choice. With regards, Daniel
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
