On Mon, Jan 16, 2023 at 1:19 AM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
Hi Benson, Richard,
To add a couple thought to this topic, which I see raised in various
venues every so often:
On 1/4/23 12:11 AM, Benson Muite wrote:
> Hi Richard,
>> Fedora used to maintain in its old license list an indication of
>> whether a "good" license was GPLv2 and (separately) GPLv3 compatible.
>> We thought this over carefully but decided not to continue this
>> practice in the migration of this data to the fedora-license-data
>> repository. This despite the fact that a lot of careful thought went
>> into those determinations (such that I think the preserved record of
>> those determinations has some significant historical value for GPL
>> interpretation). We did this because in essentially no real-world case
>> was the information ever used to take any action with respect to an
>> actual or proposed Fedora package.
> This data is helpful. Adding this to SPDX would be good, but given the
> number of licenses, it would be most efficient if other interested
> parties also contributed to this.
I can tell you that this kind of thing highly unlikely to be added to
the SPDX project for a couple reasons:
1) license "compatibility" relies on a legal interpretation at a couple
levels, which is not the perview of the SPDX Project (nor should be) and
can vary as is the nature of legal interpretations in un-tested areas
2) determining license "compatibility" relies on context (as mentioned
already a couple times in this thread, I think) - that context (i.e.,
how is the software under the various licenses in question being used?)
can vary and it's very hard, if not impossible to capture this fully -
too many variables.
Most attempts to track license compatibility seems to ignore the
question of context or make broad assumptions about how the software is
used or combined. This results in "answers" that may not be correct
given your specific situation.
I actually disagree with both you and Richard on this. :)
It's fine that SPDX doesn't offer this guidance, but Fedora as a
distributor *needs* it. Fedora provided very valuable guidance with
its "will-it-blend" chart and offering explicit interpretation. It was
useful for both packagers and upstreams to figure out what they can
and cannot do. Eliminating that guidance is creating problems now
because with the transition to SPDX, you're effectively requiring
everyone to re-evaluate all packages for their licensing and document
it without any real ability to figure out if it makes any sense
anymore.
>> As for compatibility of arbitrary licenses more generally:
If I'm
>> counting correctly, Fedora now has 286 licenses in the simple
>> "allowed" category (corresponding to the old "good [for
software]"
>> category) and this is expected to increase substantially with the
>> ongoing migration to use of SPDX identifiers. So it is basically
>> impractical if not impossible to maintain any useful, well-reasoned
>> set of context-free compatibility relationships for each Fedora
>> allowed license with respect to any other arbitrary Fedora allowed
>> license.
agreed.
> For software licenses, probably a simple categorization is reasonable?
> Permissive, weakly protective, strongly protective, network protective
categorization of types of licenses is a bit harder than you'd think.
While it may be somewhat useful in terms of providing generalizations
about compliance, it doesn't really answer the question of license
compatibility.
> Suggestions can then be issued to packagers to check license compliance
> that typically either the most protective license applies, or contents
> with separate licenses are in separate packages.
>
> The Apache 2 and GPL conflict seems well known. There are 1012 packages
> in the repositories with both GPL and Apache licenses:
> $ dnf repoquery --all --info > allpackageinfo.txt
> $ cat allpackageinfo.txt | grep -n "ASL.* GPL" >>
GPLonly_AND_APACHE.txt
> $ cat allpackageinfo.txt | grep -n "Apache.* GPL" >>
GPLonly_AND_APACHE.txt
> $ cat allpackageinfo.txt | grep -n " GPL.*ASL" >>
GPLonly_AND_APACHE.txt
> $ cat allpackageinfo.txt | grep -n " GPL.*Apache" >>
GPLonly_AND_APACHE.txt
> $ wc -l GPLonly_AND_APACHE.txt
>
> Need to check that either GPL license is the main one that applies with
> Apache licensed software included in GPL software but no GPL software in
> Apache licensed software or separate Apache and GPL packages are produced:
>
https://www.apache.org/licenses/GPL-compatibility.html
to play devil's advocate a bit here:
This conflict is well known because the ASF or the FSF says this, but
does that make it legally true? Who might challenge this in court and
what would that case look like in terms of who would bring such a case
and under what claims?
Some incompatibilities are more obvious given the specific conditions of
the licenses that directly conflict in that you cannot comply with both
at the same time (e.g., combining GPL or any license that requires the
release of source code with code under a license that restricts access
to source code) - but those are less likely to be of the kind at issue
here given Fedora's broader licensing policy.
Other incompatibilities are more based on community ideals or statements
from license stewards, which while influential, may not have been tested
in court. In that case, how does one decide?
(btw, I don't have good answers to these questions :)
Historically, when it comes to disagreements like this, we've taken
the more pessimistic view as our guidance. In this particular example,
Fedora generally assumes ASL 2.0/Apache-2.0 and GPLv2/GPL-2.0 are not
compatible. This guidance became a community norm as both Fedora and
Debian agreed on this and propagated it to upstreams, who have since
used that and done things like create exceptions to enable that
compatibility.
This is an example of where interpreting licenses and offering
guidance helps make the world a better place. :)
--
真実はいつも一つ!/ Always, there's only one truth!