On Thu, Aug 24, 2023 at 8:52 PM Richard Fontana <rfontana@xxxxxxxxxx> 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. > > 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. > > 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.) > > 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. Wouldn't dropping licenses (or exceptions) that entail no conditions just be another way to do "effective license analysis" (i.e. who needs to decide whether the license entails no conditions)? Listing everything might be verbose, but it at least has the benefit of being *simple*, and doesn't involve judgement calls like "this license doesn't matter in this case"). > As with abandoning the "license of the binary" rule, this would > seemingly be a major departure from the principles established under > the Callaway system. I think keeping the distinction between contents of the upstream sources and contents of the packages we distribute is worthwhile. It's one way to make the License information more meaningful for actual users. Just listing the licenses of the files in the upstream project (whether the contents end up shipped in our packages or not) is "just passing through" information and not particularly useful (in which case we could just say "the license of this package is the license of this upstream project, go look it up yourself" instead of including a License tag in the RPM). Fabio _______________________________________________ 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
