On Thu, Aug 24, 2023 at 02:52:21PM -0400, Richard Fontana wrote: > Some of the complaints that have surfaced since the migration from the > Callaway system to SPDX seem to be, at root, an aesthetic distaste for > complex license expressions in RPM license metadata. This may explain > why some favor application of "effective license" analysis. I suspect > there is also a sort of psychological desire to hide the underlying > licensing complexity that characterizes many packages. Lets take the proposed change to the kernel spec: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2648/diffs#b49eece2a4839c357a77beb23d8760ff33be48cc as an example of "complex license expressions" for which there is likely an aesthetic distaste. Each distinct SPDX-License-Identifier tag expession, is combined such that we end up with: License: ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-2-Clause) AND ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-3-Clause) AND ((GPL-2.0-only WITH Linux-syscall-note) OR CDDL-1.0) AND ((GPL-2.0-only WITH Linux-syscall-note) OR Linux-OpenIB) AND ((GPL-2.0-only WITH Linux-syscall-note) OR MIT) AND ((GPL-2.0-or-later WITH Linux-syscall-note) OR BSD-3-Clause) AND ((GPL-2.0-or-later WITH Linux-syscall-note) OR MIT) AND BSD-2-Clause AND BSD-3-Clause AND BSD-3-Clause-Clear AND GPL-1.0-or-later AND (GPL-1.0-or-later OR BSD-3-Clause) AND (GPL-1.0-or-later WITH Linux-syscall-note) AND GPL-2.0-only AND (GPL-2.0-only OR Apache-2.0) AND (GPL-2.0-only OR BSD-2-Clause) AND (GPL-2.0-only OR BSD-3-Clause) AND (GPL-2.0-only OR CDDL-1.0) AND (GPL-2.0-only OR Linux-OpenIB) AND (GPL-2.0-only OR MIT) AND (GPL-2.0-only OR X11) AND (GPL-2.0-only WITH Linux-syscall-note) AND GPL-2.0-or-later AND (GPL-2.0-or-later OR BSD-2-Clause) AND (GPL-2.0-or-later OR BSD-3-Clause) AND (GPL-2.0-or-later OR MIT) AND (GPL-2.0-or-later WITH GCC-exception-2.0) AND (GPL-2.0-or-later WITH Linux-syscall-note) AND ISC AND LGPL-2.0-or-later AND (LGPL-2.0-or-later OR BSD-2-Clause) AND (LGPL-2.0-or-later WITH Linux-syscall-note) AND LGPL-2.1-only AND (LGPL-2.1-only OR BSD-2-Clause) AND (LGPL-2.1-only WITH Linux-syscall-note) AND LGPL-2.1-or-later AND (LGPL-2.1-or-later WITH Linux-syscall-note) AND (Linux-OpenIB OR GPL-2.0-only) AND (Linux-OpenIB OR GPL-2.0-only OR BSD-2-Clause) AND MIT AND (MIT OR Apache-2.0) AND (MIT OR GPL-2.0-only) AND (MIT OR GPL-2.0-or-later) AND (MIT OR LGPL-2.1-only) AND (MPL-1.1 OR GPL-2.0-only) AND (X11 OR GPL-2.0-only) AND (X11 OR GPL-2.0-or-later) AND Zlib AND (copyleft-next-0.3.1 OR GPL-2.0-or-later) AND (Redistributable, no modification permitted) While the majority of files in the kernel are "GPL-2.0-only", a number of files are offered under a choice of licenses (OR). Even if 99% of files were simply GPL-2.0-only, it only takes a handful of files being offered under a choice, to result in an enourmous SPDX expression like the one above. In the above example, at a bare minimum it would only take 30 files, out of the kernel's 80,000 to have distinct licence choices to cause the existance the above expression. While this is an accurate reflection of the range of distinct file license choices, I'm not convinced that this approach is especially beneficial to Fedora users. What purpose does it serve to list "MPL-1.1 OR GPL-2.0-only" and "MIT OR LGPL-2.1-only", etc if only perhaps < 1% of files carry this choice and we're not telling the user which 1% of files it applies to ? The previous effective license analysis addressed this problem, such that everything reduced down to "GPLv2 and Redistributable" I don't want to suggest going back to effective analysis as I think that was overly simplified, but perhaps we can finese what we're doing today. ie tather than trying to maintain the full list of choices, can we eliminate all the OR clauses, such that we present just a flat list of each distinct SPDX license name that is found. IOW, the above kernel SPDX expression would be License: Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BSD-3-Clause-Clear AND CDDL-1.0 AND copyleft-next-0.3.1 AND GPL-1.0-or-later AND GPL-1.0-or-later-WITH-Linux-syscall-note AND GPL-2.0-only AND GPL-2.0-only-WITH-Linux-syscall-note AND GPL-2.0-or-later AND GPL-2.0-or-later-WITH-GCC-exception-2.0 AND GPL-2.0-or-later-WITH-Linux-syscall-note AND ISC AND LGPL-2.0-or-later AND LGPL-2.0-or-later-WITH-Linux-syscall-note AND LGPL-2.1-only AND LGPL-2.1-only-WITH-Linux-syscall-note AND LGPL-2.1-or-later AND LGPL-2.1-or-later-WITH-Linux-syscall-note AND Linux-OpenIB AND MIT AND MPL-1.1 AND Redistributable, no modification permitted AND X11 AND Zlib > I do think that the current approach can be criticized as being overly > pedantic, and perhaps also internally contradictory (some of Florian's > recent comments get at the various ways in which we are being > contradictory). We have a still-undocumented rule that what I call > "true public domain" should not be reflected in the License: field > (unless it would otherwise be empty), yet we have carefully attempted > to collect nonstandard public domain dedication statements and cover > those by `LicenseRef-Fedora-Public-Domain`. We have been using a > similar approach with `LicenseRef-Fedora-UltraPermissive`. These > basically replace Callaway system names "Public domain" (though this > was sometimes used for "true public domain") and "Freely > redistributable without restrictions", respectively. > > I think it can reasonably be argued that there is little point in > including `LicenseRef-Fedora-Public-Domain` and > `LicenseRef-Fedora-UltraPermissive` in the License: field since they > are associated with no conditions or obligations. In those special > cases where the License: field would otherwise be empty, we can ask > SPDX to create unique identifiers for the license text in question. I think there is value in LicenseRef-Fedora-Public-Domain, etc because it expresses the fact that license analysis has actually been performed and these public domain choices have been correctly identified. I don't like the need to special case the omission to avoid an entirely empty License: field. If we have a need to record LicenseRef-Fedora-Public-Domain in any scenario, we should be consistent. eg consider a package is 100% public domain initially so we have to record that to avoid empty field: License: LicenseRef-Fedora-Public-Domain then one day a file is added which is MIT. I would find it pretty strange for the rule to say we can now drop the LicenseRef-Fedora-Public-Domain to go to just record: License: MIT when 99% of the files are still LicenseRef-Fedora-Public-Domain and only 1 single file were MIT. IMHO the package should be changed to say License: LicenseRef-Fedora-Public-Domain and MIT IOW, I think we should always be recording the license, even if it is a public domain LicenseRef term. > We might want to extend this principle to other things, such as GPL > exceptions that entail no conditions in the use case encountered in > particular packages. (There is already an old issue about this, I > think concerning the Bison exception.) Personally I like the way we're not recording the existance of each license and exception, just not the creation of the combinatorial expansion of each license choice. > > This wouldn't do *that* much to make License: fields simpler, so maybe > it's not particularly worthwhile. There is also the problem that if we > make it optional, package maintainers may be less likely to scrutinize > things that are assumed to fall into these kinds of categories, when > in some cases they actually wouldn't, although I think it's now clear > that those situations are uncommon. In theory we'd still expect > package maintainers to submit issues to have things that seem to > qualify for LicenseRef-Fedora-Public-Domain reviewed, but it might be > challenging to enforce that expectation and the Fedora Legal team > would have to end up doing all that work themselves, which might be a > justifiable result. > > As with abandoning the "license of the binary" rule, this would > seemingly be a major departure from the principles established under > the Callaway system. > > Any thoughts on this? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
