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

Attachment: 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

Reply via email to