On 24. 08. 23 20:52, 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. 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. 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?
Hi. Considering the idea behind all the public domain licenses is that anyone can take the code and include it anywhere without any strings attached, we can now easily end up in two different situations:
Situation 1: A project under MIT takes a a public domain function (file, module, whatever) and copies it into the MIT project. Since there is no obligation to mention where this function comes from, they don't do that.
Situation 2: A project under MIT takes a a public domain function (file, module, whatever) and copies it into the MIT project. For good measure, they annotate the function with "a public domain function from X by Y".
Should those two situations be handled differently in the License tag? Previously, we would simply say "MIT" in both situations, but the current no-effective-license-analysis rule kinda makes the second situation more complex for the packager. Being able to omit this woudl certainly makes things a bit easier.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ 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
