Debian and at least some of its derivatives have long had a requirement that each package have a so-called "copyright file" which among other things is supposed to contain "a verbatim copy of its copyright information and distribution license". However, for certain widely-used licenses, copies are not bundled with individual packages, but instead a systemwide copy of each is installed in /usr/share/common-licenses. These include, from what I gather, the Apache License 2.0, some version of the Artistic License, each extant version of the GPL and LGPL, and (oddly) certain versions of the GFDL.
I've been thinking recently that Fedora, and the derivatives of Fedora maintained by Red Hat engineers, would benefit from adopting a similar approach, though I wouldn't suggest using an identical set of licenses. I had a conversation with Neal Gompa yesterday and got the impression he did not consider this to be an entirely crazy idea. I have some concerns about the current Fedora practice of installing certain individual package license files (including license files that appear in thousands if not tens of thousands of Fedora packages in identical form) in /usr/share/licenses and think this particular Debian practice might be a marginal improvement in certain respects.
Any thoughts on this idea?
Richard
On 5.5.2017 17:00, Richard Fontana wrote:
Debian and at least some of its derivatives have long had a requirement that each package have a so-called "copyright file" which among other things is supposed to contain "a verbatim copy of its copyright information and distribution license". However, for certain widely-used licenses, copies are not bundled with individual packages, but instead a systemwide copy of each is installed in /usr/share/common-licenses. These include, from what I gather, the Apache License 2.0, some version of the Artistic License, each extant version of the GPL and LGPL, and (oddly) certain versions of the GFDL.
I've been thinking recently that Fedora, and the derivatives of Fedora maintained by Red Hat engineers, would benefit from adopting a similar approach, though I wouldn't suggest using an identical set of licenses. I had a conversation with Neal Gompa yesterday and got the impression he did not consider this to be an entirely crazy idea. I have some concerns about the current Fedora practice of installing certain individual package license files (including license files that appear in thousands if not tens of thousands of Fedora packages in identical form) in /usr/share/licenses and think this particular Debian practice might be a marginal improvement in certain respects.
Any thoughts on this idea?
I thought that one of reasons to use the %license macro was that we can hardlink those license-files to save space. Or is that just my memory tricking me?
On Fri, 2017-05-05 at 11:00 -0400, Richard Fontana wrote:
Any thoughts on this idea?
I was curious about how much of a problem this really is, so I checked on my workstation:
$ du -sch /usr/share/licenses 27M /usr/share/licenses 27M total
Whoah!
I liked Miro's suggestion of hardlinking the licenses, but it's important to sure they are actually identical with checksums (i.e., don't just use the License field because what if the upstream project subtly adjusted the license file?)
On Fri, May 05, 2017 at 02:28:34PM -0400, Randy Barlow wrote:
I liked Miro's suggestion of hardlinking the licenses, but it's important to sure they are actually identical with checksums (i.e., don't just use the License field because what if the upstream project subtly adjusted the license file?)
Right, it would be necessary for someone maintaining a package to verify that what looks like a common license actually matches the reference copy. (I don't know if Debian does this.) In some cases, non-identical files could be determined nonetheless to match according to some criteria. As an example, the GitHub 'choose-a-license' feature seems to be resulting in a class of noncanonical common license texts that differ from the real authentic copy only in nonsubstantive ways (e.g. whitespace).
Richard
Dne 5.5.2017 v 20:49 Richard Fontana napsal(a):
On Fri, May 05, 2017 at 02:28:34PM -0400, Randy Barlow wrote:
I liked Miro's suggestion of hardlinking the licenses, but it's important to sure they are actually identical with checksums (i.e., don't just use the License field because what if the upstream project subtly adjusted the license file?)
Right, it would be necessary for someone maintaining a package to verify that what looks like a common license actually matches the reference copy. (I don't know if Debian does this.) In some cases, non-identical files could be determined nonetheless to match according to some criteria. As an example, the GitHub 'choose-a-license' feature seems to be resulting in a class of noncanonical common license texts that differ from the real authentic copy only in nonsubstantive ways (e.g. whitespace).
And copyright holder typically on the top of MIT ...
I would love to see some package with the canonical licenses as a start. That would be so much better source of official Fedora licenses then the current wiki, assuming they are machine readable ...
Vít
"RB" == Randy Barlow bowlofeggs@fedoraproject.org writes:
RB> I liked Miro's suggestion of hardlinking the licenses, but it's RB> important to sure they are actually identical with checksums (i.e., RB> don't just use the License field because what if the upstream RB> project subtly adjusted the license file?)
The idea behind having %license (and packages actually using it) is that now we have the licenses identified and stored in a way that RPM controls, instead of simply stored the same way that documentation is stored.
Making RPM do smarter things with those license files is now entirely within the domain of RPM or perhaps some file triggers or even (ugh) a cron job/timer/whatever.
So, want to hardlink those files? Have a package with a file trigger on /usr/share/licenses that runs /usr/sbin/hardlink. Instant space savings, though you still have to spend the inodes. If that's not enough, RPM could probably be taught to do practically anything.
- J<
Jason L Tibbitts III wrote:
The idea behind having %license (and packages actually using it) is that now we have the licenses identified and stored in a way that RPM controls, instead of simply stored the same way that documentation is stored.
Making RPM do smarter things with those license files is now entirely within the domain of RPM or perhaps some file triggers or even (ugh) a cron job/timer/whatever.
So, want to hardlink those files? Have a package with a file trigger on /usr/share/licenses that runs /usr/sbin/hardlink. Instant space savings, though you still have to spend the inodes. If that's not enough, RPM could probably be taught to do practically anything.
If there were a common-licenses package, then perhaps RPMbuild could automatically compare files tagged with %license to those licenses, and replace matching files with a link and a dependency on common-licenses? That should also make the packages smaller, saving some download time and space on the mirrors.
I can't take on any more work so the idea is free for the taking.
Björn Persson