On Mon, Jan 16, 2023 at 1:19 AM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> 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! _______________________________________________ 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
