Dne 24. 08. 23 v 20:52 Richard Fontana napsal(a):
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
The problem is that leaving out this "true public domain" tag makes license review harder in a sense.
Let me explain. If I am reviewing license and find some file being "true public domain", leaving it out might mean that it won't be recorded anywhere that it was already identified as a "true public domain". Doing the review next time, I (or somebody else) will need to find it the hard way again.
I think that the current license field is unfortunately very limited in expressing the source license. I wish if we were able to record the license per file or even per file lines. But admittedly, this won't be easier.
Vít
(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? Richard _______________________________________________ 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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
