I'm interested in proposing that Fedora adopt a 'common-licenses' directory convention, similar to Debian and Debian-derived distributions, whereby default installations of Fedora would include a prepopulated subdirectory /usr/share/licenses/common-licenses (or maybe /usr/share/common-licenses) with certain highly common license texts. A Debian container I am currently running has these files in /usr/share/common-licenses: Apache-2.0 Artistic BSD CC0-1.0 GFDL GFDL-1.2 GFDL-1.3 GPL GPL-1 GPL-2 GPL-3 LGPL LGPL-2 LGPL-2.1 LGPL-3 MPL-1.1 MPL-2.0
I do not propose to have all or even most of those, but I could see a basis for GPLv2, GPLv3, LGPLv2.0, LGPLv2.1, probably LGPLv3, maybe Apache-2.0. These happen not only to be licenses that are very common in Fedora (LGPLv3 might be an exception but it would be associated with LGPL-2.x-or-later licensing), but also they tend not to occur in textually noteworthy variants. For example, we all know that there are lots of different GPLv2 texts out there with different current and historical FSF addresses, but they are commonly seen as equivalent by the relevant license using community, such that updating to a newer-FSF-address version is seen as unremarkable to everyone except possibly for super-pedantic FOSS license obsessives.
This would go a little way towards addressing the problem of defining a modern policy for inclusion of license files with binary packages. If an applicable package license is already contained in /usr/share/licenses/common-licenses (let's say, as indicated by the spec file License: field, even though that has shortcomings), that license could be omitted from inclusion in /usr/share/licenses/{package name}/. This would mean, for example, that a Fedora system would no longer need to have tens of thousands of identical/near-identical copies of GPLv2 in /usr/share/licenses/.
What I am totally unclear on is how something like this should be proposed. Is it a packaging policy issue, or a proposal for a change in some existing fundamental package that gets installed on all systems (probably not fedora-release, but maybe something similar to that?)? A package created for this specific purpose? Is it a FESCO issue?
Richard
On Tue, Jul 25, 2023 at 5:14 PM Richard Fontana rfontana@redhat.com wrote:
I'm interested in proposing that Fedora adopt a 'common-licenses' directory convention, similar to Debian and Debian-derived distributions, whereby default installations of Fedora would include a prepopulated subdirectory /usr/share/licenses/common-licenses (or maybe /usr/share/common-licenses) with certain highly common license texts. A Debian container I am currently running has these files in /usr/share/common-licenses: Apache-2.0 Artistic BSD CC0-1.0 GFDL GFDL-1.2 GFDL-1.3 GPL GPL-1 GPL-2 GPL-3 LGPL LGPL-2 LGPL-2.1 LGPL-3 MPL-1.1 MPL-2.0
I do not propose to have all or even most of those, but I could see a basis for GPLv2, GPLv3, LGPLv2.0, LGPLv2.1, probably LGPLv3, maybe Apache-2.0. These happen not only to be licenses that are very common in Fedora (LGPLv3 might be an exception but it would be associated with LGPL-2.x-or-later licensing), but also they tend not to occur in textually noteworthy variants. For example, we all know that there are lots of different GPLv2 texts out there with different current and historical FSF addresses, but they are commonly seen as equivalent by the relevant license using community, such that updating to a newer-FSF-address version is seen as unremarkable to everyone except possibly for super-pedantic FOSS license obsessives.
This would go a little way towards addressing the problem of defining a modern policy for inclusion of license files with binary packages. If an applicable package license is already contained in /usr/share/licenses/common-licenses (let's say, as indicated by the spec file License: field, even though that has shortcomings), that license could be omitted from inclusion in /usr/share/licenses/{package name}/. This would mean, for example, that a Fedora system would no longer need to have tens of thousands of identical/near-identical copies of GPLv2 in /usr/share/licenses/.
What I am totally unclear on is how something like this should be proposed. Is it a packaging policy issue, or a proposal for a change in some existing fundamental package that gets installed on all systems (probably not fedora-release, but maybe something similar to that?)? A package created for this specific purpose? Is it a FESCO issue?
This would be under the purview of the Fedora Packaging Committee: https://pagure.io/packaging-committee
The mailing list for discussion is packaging@.
I am not opposed to this idea, though I guess we'd probably want to use SPDX identifiers for the text files?
The mechanics of adopting common-licenses will be interesting to figure out.
There is some precedent in the RPM world, as Mandriva and Mageia used it somewhat. I wouldn't say they fully adopted it, since there was no working out how to consistently apply licensing documentation policy.
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.
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.
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).
Richard
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.
Dne 26. 07. 23 v 0:12 Neal Gompa napsal(a):
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.
That does not make sense to me :)
Can you elaborate what is the difference between https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt and
https://github.com/spdx/license-list-XML/blob/main/src/GPL-2.0-or-later.xml#...
And if there are really some difference can we rather ask for the change in SPDX? And include in the XML what we need? I really want to avoid maintaining other list of licenses and they relation to SPDX ids.
On Wed, Jul 26, 2023 at 12:19 PM Miroslav Suchý msuchy@redhat.com wrote:
Dne 26. 07. 23 v 0:12 Neal Gompa napsal(a):
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.
That does not make sense to me :)
Can you elaborate what is the difference between https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt and
https://github.com/spdx/license-list-XML/blob/main/src/GPL-2.0-or-later.xml#...
The generated text file (I assume this is generated from the XML file) https://raw.githubusercontent.com/spdx/license-list-data/main/text/GPL-2.0-o...
is not easily readable compared to the license steward version, which is *designed* to be readable. Actually, the XML file may be more easy to read than the text file. I also have the impression that SPDX's approach of generating text files from XML files has tended to result in subtle errors in some cases.
You can argue that no one actually reads the license, but then that's an argument for not including the license text to begin with. After all, it will be in the source code (usually). Fedora really doesn't have a clear rationale for why particular license texts get installed in /usr/share/licenses.
And if there are really some difference can we rather ask for the change in SPDX? And include in the XML what we need? I really want to avoid maintaining other list of licenses and they relation to SPDX ids.
Well in my proposal we're really only talking about a handful of license texts that are known to get (typographically) updated only very rarely and in nonsubstantive ways. The idea of having all packages symbolically link to hundreds of SPDX-standardized license texts is much more problematic, though worth thinking about as it may help clarify why we are bothering to include any license files at all.
Richard
On 7/26/23 1:53 PM, Richard Fontana wrote:
Well in my proposal we're really only talking about a handful of license texts that are known to get (typographically) updated only very rarely and in nonsubstantive ways. The idea of having all packages symbolically link to hundreds of SPDX-standardized license texts is much more problematic, though worth thinking about as it may help clarify why we are bothering to include any license files at all.
Richard
I think I’m about to say approximately the same thing Richard was saying in the quoted paragraph, but I want to say it differently and more explicitly.
For many common licenses, project-specific details like the name(s) of the copyright holder(s) are substituted into the license text. In some, such as the “MIT family,” a copyright statement is part of the license text and is required to be reproduced with copies. For packages under such licenses, linking to a canonical license file corresponding to the SPDX ID will not be an adequate substitute for shipping the project’s actual license file(s), which will be different in almost every case even though they match the same SPDX “template.”
The licenses in the original proposal, such as the GPL family and Apache-2.0, have in common that they have relatively long texts and that project-specific details generally appear in a separate copyright and license statement, perhaps in source file header comments or a readme, rather than in the same file with the full license text. For both of these reasons, those licenses have the most potential for useful “deduplication.”
Dne 26. 07. 23 v 19:53 Richard Fontana napsal(a):
The generated text file (I assume this is generated from the XML file) https://raw.githubusercontent.com/spdx/license-list-data/main/text/GPL-2.0-o...
is not easily readable compared to the license steward version, which is*designed* to be readable. Actually, the XML file may be more easy to read than the text file. I also have the impression that SPDX's approach of generating text files from XML files has tended to result in subtle errors in some cases.
Can you first propose to SPDX to include in the xml files section <text-steward> that will include steward version (likely in <pre> tags so the formatting will be preserved? This way we can fetch it from there and do not have to maintain it separately.
Dne 25. 07. 23 v 23:13 Richard Fontana napsal(a):
I'm interested in proposing that Fedora adopt a 'common-licenses' directory convention, similar to Debian and Debian-derived distributions, whereby default installations of Fedora would include a prepopulated subdirectory /usr/share/licenses/common-licenses (or maybe /usr/share/common-licenses)
I don't think that any folder such as `common-licenses` is good idea.
Let me explain. I think that ultimately, we should remove all license files from our packages and replace them with symlinks to some common location, be it e.g. `/usr/share/licenses/`. This directory could well be populated by some package such as `spdx-licenses`. But I don't think we should really treat some licenses somehow exceptionally. Of course, the `spdx-licenses` could be split into some subpackages such as `spdx-licenses-common`, but there is no real need to place them elsewhere. And if there is the need (I can't really see it), then again, they should be linked into some common location.
Vít
with certain highly common license texts. A Debian container I am currently running has these files in /usr/share/common-licenses: Apache-2.0 Artistic BSD CC0-1.0 GFDL GFDL-1.2 GFDL-1.3 GPL GPL-1 GPL-2 GPL-3 LGPL LGPL-2 LGPL-2.1 LGPL-3 MPL-1.1 MPL-2.0
I do not propose to have all or even most of those, but I could see a basis for GPLv2, GPLv3, LGPLv2.0, LGPLv2.1, probably LGPLv3, maybe Apache-2.0. These happen not only to be licenses that are very common in Fedora (LGPLv3 might be an exception but it would be associated with LGPL-2.x-or-later licensing), but also they tend not to occur in textually noteworthy variants. For example, we all know that there are lots of different GPLv2 texts out there with different current and historical FSF addresses, but they are commonly seen as equivalent by the relevant license using community, such that updating to a newer-FSF-address version is seen as unremarkable to everyone except possibly for super-pedantic FOSS license obsessives.
This would go a little way towards addressing the problem of defining a modern policy for inclusion of license files with binary packages. If an applicable package license is already contained in /usr/share/licenses/common-licenses (let's say, as indicated by the spec file License: field, even though that has shortcomings), that license could be omitted from inclusion in /usr/share/licenses/{package name}/. This would mean, for example, that a Fedora system would no longer need to have tens of thousands of identical/near-identical copies of GPLv2 in /usr/share/licenses/.
What I am totally unclear on is how something like this should be proposed. Is it a packaging policy issue, or a proposal for a change in some existing fundamental package that gets installed on all systems (probably not fedora-release, but maybe something similar to that?)? A package created for this specific purpose? Is it a FESCO issue?
Richard _______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 25. 07. 23 v 23:13 Richard Fontana napsal(a):
maybe /usr/share/common-licenses) with certain highly common license texts. A Debian container I am currently running has these files in /usr/share/common-licenses:
I would love to be on pair with Debian. There is no need to be different. And if we have serious reason to differ, then I would welcome to have talk with Debian people and come to solution that will fit both distributions.
-
Ben Beasley -
Miroslav Suchý -
Neal Gompa -
Richard Fontana -
Vít Ondruch