On Tue, Jul 25, 2023 at 5:56 PM Richard Fontana rfontana@redhat.com wrote:
On Tue, Jul 25, 2023 at 5:27 PM Neal Gompa ngompa13@gmail.com wrote:
I am not opposed to this idea, though I guess we'd probably want to use SPDX identifiers for the text files?
Yes, that makes sense, although for the *GPL licenses we'd have to use what SPDX considers to be deprecated identifiers (GPL-2.0, etc.). However, I would specifically propose *not* using the SPDX plain text pseudo-renditions of particular license identifiers, which I believe are generated automatically from XML files and don't really serve the purpose I have in mind. We should use the license steward-authorized version of the license in question; so, for example, the file /usr/share/licenses/common-licenses/GPL-2.0 would be a copy of https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt For all the licenses I listed, there is a license steward (FSF, and the Apache Software Foundation) who publishes an official plain text version of the license in question.
Yes, that makes sense to me.
Another aspect of common-licenses is that usually there's some kind of packaging declaration of these things. In Debian, this is handled through DEP-5: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
I'm personally not a total fan of the DEP5 format, but having some kind of extension to the spec file for some (if not all) of this data to be stored in the RPM database when RPMs are installed would make sense to me.
Given how much work has been involved in the migration to SPDX identifiers in spec files, I do wonder whether it would be better to have something like the DEP-5 approach, but that is probably too radical an idea to suggest for Fedora at this time, if ever. :)
I like how the REUSE standard allows use of DEP-5 as a way of specifying repository licensing details, but I understand they are planning to move to some other format (YAML I believe).
I think we could just take a couple of the properties we need and extend RPM. We could also probably create a dependency generator to ensure that there's a dependency on the common-licenses package for the correct license file. We don't need *everything* DEP-5 does.
There are other ways to approach the problem too, that's just what I came up with on the spot.