4:51 p.m.
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