On Tue, Jul 25, 2023 at 5:56 PM Richard Fontana <rfontana(a)redhat.com> wrote:
On Tue, Jul 25, 2023 at 5:27 PM Neal Gompa <ngompa13(a)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.
--
真実はいつも一つ!/ Always, there's only one truth!