With the move to SPDX license nomenclature I'm starting to reevaluate how I review licenses during a package review.
I'm working on a review and it looks like some of the documentation, i.e. stuff that would go in %doc has a specific license. I don't know if this is uncommon or if I just hadn't noticed before, but does this actually impact the package licensing?
In general, I would say that the package license should be based on what's actually in the resultant package (not build system stuff like autotools, random scripts, etc). That seems pretty straightforward, but documentation?
Thanks, Richard
On August 10, 2022 4:35:10 PM UTC, Richard Shaw hobbes1069@gmail.com wrote:
With the move to SPDX license nomenclature I'm starting to reevaluate how I review licenses during a package review.
I'm working on a review and it looks like some of the documentation, i.e. stuff that would go in %doc has a specific license. I don't know if this is uncommon or if I just hadn't noticed before, but does this actually impact the package licensing?
If the %doc part belongs to the main package, then I'd just combine all licenses via AND including the license of the documentation. If it's a separate package, the use the doc license for the -doc subpackage (provided that rpm supports this). But IANAL applies as usual.
In general, I would say that the package license should be based on what's actually in the resultant package (not build system stuff like autotools, random scripts, etc). That seems pretty straightforward, but documentation?
Thanks, Richard
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
On August 10, 2022 4:35:10 PM UTC, Richard Shaw hobbes1069@gmail.com wrote:
With the move to SPDX license nomenclature I'm starting to reevaluate how I review licenses during a package review.
I'm working on a review and it looks like some of the documentation, i.e. stuff that would go in %doc has a specific license. I don't know if this is uncommon or if I just hadn't noticed before, but does this actually impact the package licensing?
If the %doc part belongs to the main package, then I'd just combine all licenses via AND including the license of the documentation. If it's a separate package, the use the doc license for the -doc subpackage (provided that rpm supports this). But IANAL applies as usual.
That sounds right to me ...
In general, I would say that the package license should be based on what's actually in the resultant package (not build system stuff like autotools, random scripts, etc).
Yes, and that is consistent with both the new Fedora legal documentation as well as the earlier guidelines (as I read them, anyway).
That seems pretty straightforward, but documentation?
I think there's a couple of issues. First, all documentation files distributed by Fedora should be under a Fedora-allowed license for documentation. This is true even if the documentation files are not in the built package. Second, to what extent should licenses unique to documentation in a built package be reflected in the License: field? Up to now it's pretty clear Fedora packages have been inconsistent in how they've handled this. My assumption however is that documentation licensing should not be ignored in populating the License: field and we can make this clear with an example in the new legal documentation. (I *think* for the vast majority of Fedora packages there is no license for documentation distinct from the software license.)
On a general note, it's important to pay attention to documentation licensing even though it may seem less critical than software licensing. Although this is still being looked into, there seems to be some evidence of Fedora packages that are including upstream documentation under disallowed licenses (in particular "NC" varieties of Creative Commons licenses).
Richard
Hi,
On August 10, 2022 6:22:43 PM UTC, Richard Fontana rfontana@redhat.com wrote:
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
On August 10, 2022 4:35:10 PM UTC, Richard Shaw hobbes1069@gmail.com wrote:
With the move to SPDX license nomenclature I'm starting to reevaluate how I review licenses during a package review.
I'm working on a review and it looks like some of the documentation, i.e. stuff that would go in %doc has a specific license. I don't know if this is uncommon or if I just hadn't noticed before, but does this actually impact the package licensing?
If the %doc part belongs to the main package, then I'd just combine all licenses via AND including the license of the documentation. If it's a separate package, the use the doc license for the -doc subpackage (provided that rpm supports this). But IANAL applies as usual.
That sounds right to me ...
In general, I would say that the package license should be based on what's actually in the resultant package (not build system stuff like autotools, random scripts, etc).
Yes, and that is consistent with both the new Fedora legal documentation as well as the earlier guidelines (as I read them, anyway).
That seems pretty straightforward, but documentation?
I think there's a couple of issues. First, all documentation files distributed by Fedora should be under a Fedora-allowed license for documentation. This is true even if the documentation files are not in the built package. Second, to what extent should licenses unique to documentation in a built package be reflected in the License: field? Up to now it's pretty clear Fedora packages have been inconsistent in how they've handled this. My assumption however is that documentation licensing should not be ignored in populating the License: field and we can make this clear with an example in the new legal documentation. (I *think* for the vast majority of Fedora packages there is no license for documentation distinct from the software license.)
I think that there's another pitfall here: if you e.g. build a HTML documentation, then you should (?) include the license of all the bundled fonts, CSS and JavaScript as well. I'm afraid we mostly don't do this at all.
PDF would be probably a lot safer.
On a general note, it's important to pay attention to documentation licensing even though it may seem less critical than software licensing. Although this is still being looked into, there seems to be some evidence of Fedora packages that are including upstream documentation under disallowed licenses (in particular "NC" varieties of Creative Commons licenses).
Richard _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Aug 10, 2022 at 12:52 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
I think that there's another pitfall here: if you e.g. build a HTML documentation, then you should (?) include the license of all the bundled fonts, CSS and JavaScript as well. I'm afraid we mostly don't do this at all.
Right. Documentation builders such as doxygen and python-sphinx drop CSS, JavaScript, and image files into the built documentation. Those may carry the license of the documentation builder, or an entirely different license. If those documentation builders each provided a subpackage that contains the stuff that might be copied into documentation, then we could swizzle our documentation packages to use symlinks into those subpackages. I'm not clear on how that would affect the licensing, though. Also, that means that if you update your documentation builder so that the static stuff is not backwards compatible, you have to rebuild everything that uses it. That might be more pain than we want to deal with.
PDF would be probably a lot safer.
Then we have to worry about the licenses of embedded fonts, right?
On August 10, 2022 7:18:35 PM UTC, Jerry James loganjerry@gmail.com wrote:
On Wed, Aug 10, 2022 at 12:52 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
I think that there's another pitfall here: if you e.g. build a HTML documentation, then you should (?) include the license of all the bundled fonts, CSS and JavaScript as well. I'm afraid we mostly don't do this at all.
Right. Documentation builders such as doxygen and python-sphinx drop CSS, JavaScript, and image files into the built documentation. Those may carry the license of the documentation builder, or an entirely different license. If those documentation builders each provided a subpackage that contains the stuff that might be copied into documentation, then we could swizzle our documentation packages to use symlinks into those subpackages. I'm not clear on how that would affect the licensing, though. Also, that means that if you update your documentation builder so that the static stuff is not backwards compatible, you have to rebuild everything that uses it. That might be more pain than we want to deal with.
PDF would be probably a lot safer.
Then we have to worry about the licenses of embedded fonts, right?
Yes, but AFAIK HTML documentation also pulls in fonts.
On Wed, Aug 10, 2022 at 1:24 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
Yes, but AFAIK HTML documentation also pulls in fonts.
True, although at least a couple of python-sphinx themes take pains to symlink to fonts rather than copy them (python-sphinx_rtd_theme and python-pydata-sphinx-theme come to mind). I presume that the symlinking approach means that we don't need to mention the font licenses in the License field, but it would be nice to have Richard confirm that.
But then you still have the various CSS, JavaScript, image and who knows what else files, of course.
I don’t enjoy this topic at all, but I feel obligated to contribute some relevant links.
A previous discussion on the packaging mailing list[1] concluded that it doesn’t seem possible to package HTML documentation generated by almost any system, including at least Sphinx, Doxygen, and mkdocs, in a way that complies with guidelines around pre-compiled and bundled JS, CSS, and fonts. See also [2], which started that discussion.
There might be a conflict between this situation and certain language-specific guidelines that prescribe packaging standardized documentation packages. For example, [3].
[1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006555 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2097267
On Wed, Aug 10, 2022, at 3:35 PM, Jerry James wrote:
On Wed, Aug 10, 2022 at 1:24 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
Yes, but AFAIK HTML documentation also pulls in fonts.
True, although at least a couple of python-sphinx themes take pains to symlink to fonts rather than copy them (python-sphinx_rtd_theme and python-pydata-sphinx-theme come to mind). I presume that the symlinking approach means that we don't need to mention the font licenses in the License field, but it would be nice to have Richard confirm that.
But then you still have the various CSS, JavaScript, image and who knows what else files, of course. -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 8/11/22 10:23, Ben Beasley wrote:
I don’t enjoy this topic at all, but I feel obligated to contribute some relevant links.
A previous discussion on the packaging mailing list[1] concluded that it doesn’t seem possible to package HTML documentation generated by almost any system, including at least Sphinx, Doxygen, and mkdocs, in a way that complies with guidelines around pre-compiled and bundled JS, CSS, and fonts. See also [2], which started that discussion.
There might be a conflict between this situation and certain language-specific guidelines that prescribe packaging standardized documentation packages. For example, [3].
[1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006555 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2097267
The best solution here is to patch Sphinx and Doxygen so they do not produce nonredistributable output.
Dne 15. 08. 22 v 1:19 Demi Marie Obenour napsal(a):
On 8/11/22 10:23, Ben Beasley wrote:
I don’t enjoy this topic at all, but I feel obligated to contribute some relevant links.
A previous discussion on the packaging mailing list[1] concluded that it doesn’t seem possible to package HTML documentation generated by almost any system, including at least Sphinx, Doxygen, and mkdocs, in a way that complies with guidelines around pre-compiled and bundled JS, CSS, and fonts. See also [2], which started that discussion.
There might be a conflict between this situation and certain language-specific guidelines that prescribe packaging standardized documentation packages. For example, [3].
[1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006555 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2097267
The best solution here is to patch Sphinx and Doxygen so they do not produce nonredistributable output.
I am trying to wrap my head around this for RubyGems / RDoc for quite some while, but it is unfortunately easier to say then do. Several issues:
1) If you separate the template from generated documentation, then the documentation is not self contained anymore and transferable to different location, which might break user expectations.
2) If you unbundle the template, then you should also unbundle e.g. the font or JS from the template.
3) The system is not designed to support this scenario and I am not sure if the change would be upstreamable.
4) Even if all the points above were solved, then the update of template would need trigger regenerating all the documentation, to ensure the documentation is not broken. You might argue, that the font change or some JS library change or what not are just minor changes, but OTOH, you don't want to ship broken documentation.
Vít
On 8/15/22 04:37, Vít Ondruch wrote:
Dne 15. 08. 22 v 1:19 Demi Marie Obenour napsal(a):
On 8/11/22 10:23, Ben Beasley wrote:
I don’t enjoy this topic at all, but I feel obligated to contribute some relevant links.
A previous discussion on the packaging mailing list[1] concluded that it doesn’t seem possible to package HTML documentation generated by almost any system, including at least Sphinx, Doxygen, and mkdocs, in a way that complies with guidelines around pre-compiled and bundled JS, CSS, and fonts. See also [2], which started that discussion.
There might be a conflict between this situation and certain language-specific guidelines that prescribe packaging standardized documentation packages. For example, [3].
[1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006555 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2097267
The best solution here is to patch Sphinx and Doxygen so they do not produce nonredistributable output.
I am trying to wrap my head around this for RubyGems / RDoc for quite some while, but it is unfortunately easier to say then do. Several issues:
- If you separate the template from generated documentation, then the
documentation is not self contained anymore and transferable to different location, which might break user expectations.
- If you unbundle the template, then you should also unbundle e.g. the
font or JS from the template.
- The system is not designed to support this scenario and I am not sure
if the change would be upstreamable.
- Even if all the points above were solved, then the update of template
would need trigger regenerating all the documentation, to ensure the documentation is not broken. You might argue, that the font change or some JS library change or what not are just minor changes, but OTOH, you don't want to ship broken documentation.
Another option is to have a system-wide package that the docs depend on, via scripts loaded from file:// URLs. Not sure if that works. If it does not, then bundling is the only option. In either case, though, it should certainly be possible to fix the missing license headers, and to ensure that the minified JS and CSS are built from source during the build of the documentation generator.
On Wed, 10 Aug 2022 at 14:23, Richard Fontana rfontana@redhat.com wrote:
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
On August 10, 2022 4:35:10 PM UTC, Richard Shaw hobbes1069@gmail.com
wrote:
With the move to SPDX license nomenclature I'm starting to reevaluate
how
I review licenses during a package review.
I'm working on a review and it looks like some of the documentation,
i.e.
stuff that would go in %doc has a specific license. I don't know if
this is
uncommon or if I just hadn't noticed before, but does this actually
impact
the package licensing?
If the %doc part belongs to the main package, then I'd just combine all
licenses via AND including the license of the documentation. If it's a separate package, the use the doc license for the -doc subpackage (provided that rpm supports this). But IANAL applies as usual.
That sounds right to me ...
In general, I would say that the package license should be based on
what's
actually in the resultant package (not build system stuff like
autotools,
random scripts, etc).
Yes, and that is consistent with both the new Fedora legal documentation as well as the earlier guidelines (as I read them, anyway).
That seems pretty straightforward, but documentation?
I think there's a couple of issues. First, all documentation files distributed by Fedora should be under a Fedora-allowed license for documentation. This is true even if the documentation files are not in the built package. Second, to what extent should licenses unique to documentation in a built package be reflected in the License: field? Up to now it's pretty clear Fedora packages have been inconsistent in how they've handled this. My assumption however is that documentation licensing should not be ignored in populating the License: field and we can make this clear with an example in the new legal documentation. (I *think* for the vast majority of Fedora packages there is no license for documentation distinct from the software license.)
I think we are overloading a tool (the License tag) which was meant for a 'simpler' time when packages usually had a single license and was not meant to be more useful than that. We are putting a lot of things in here which are 'nuanced' in a way that one License line does not give and needs a more complex solution. People are going to read that the package says 'License: GPL-2.0-only and GFDL-1.2-or-later' and now have to determine.. is the program running under GFDL? Also what is the license that the actual GPL License is under? It is not covered under the GPL but has a distinctly different one. Do we need to add that into the mix?
I keep feeling this is like sending a lot of untrained people with hot-glue guns to fix leaks in the Hoover dam. There are a LOT of different licenses in a package ranging from fonts, straight documentation text, various header files, source code, the licenses themselves, etc. We are then trying to parse all that and put it in a one line summary which will somehow give a person/machine reading it enough context to know what to do with the code.
I think we should look at the problem from the beginning and try to find a good tool to help fix the problem. Then deploy and correct the tool until it helps fix the problem in the first place.
On a general note, it's important to pay attention to documentation licensing even though it may seem less critical than software licensing. Although this is still being looked into, there seems to be some evidence of Fedora packages that are including upstream documentation under disallowed licenses (in particular "NC" varieties of Creative Commons licenses).
Richard _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
Stephen Smoogen ssmoogen@redhat.com writes:
On Wed, 10 Aug 2022 at 14:23, Richard Fontana rfontana@redhat.com wrote:
On Wed, Aug 10, 2022 at 1:47 PM Dan Čermák dan.cermak@cgc-instruments.de wrote:
On August 10, 2022 4:35:10 PM UTC, Richard Shaw hobbes1069@gmail.com
wrote:
With the move to SPDX license nomenclature I'm starting to reevaluate
how
I review licenses during a package review.
I'm working on a review and it looks like some of the documentation,
i.e.
stuff that would go in %doc has a specific license. I don't know if
this is
uncommon or if I just hadn't noticed before, but does this actually
impact
the package licensing?
If the %doc part belongs to the main package, then I'd just combine all
licenses via AND including the license of the documentation. If it's a separate package, the use the doc license for the -doc subpackage (provided that rpm supports this). But IANAL applies as usual.
That sounds right to me ...
In general, I would say that the package license should be based on
what's
actually in the resultant package (not build system stuff like
autotools,
random scripts, etc).
Yes, and that is consistent with both the new Fedora legal documentation as well as the earlier guidelines (as I read them, anyway).
That seems pretty straightforward, but documentation?
I think there's a couple of issues. First, all documentation files distributed by Fedora should be under a Fedora-allowed license for documentation. This is true even if the documentation files are not in the built package. Second, to what extent should licenses unique to documentation in a built package be reflected in the License: field? Up to now it's pretty clear Fedora packages have been inconsistent in how they've handled this. My assumption however is that documentation licensing should not be ignored in populating the License: field and we can make this clear with an example in the new legal documentation. (I *think* for the vast majority of Fedora packages there is no license for documentation distinct from the software license.)
I think we are overloading a tool (the License tag) which was meant for a 'simpler' time when packages usually had a single license and was not meant to be more useful than that. We are putting a lot of things in here which are 'nuanced' in a way that one License line does not give and needs a more complex solution. People are going to read that the package says 'License: GPL-2.0-only and GFDL-1.2-or-later' and now have to determine.. is the program running under GFDL? Also what is the license that the actual GPL License is under? It is not covered under the GPL but has a distinctly different one. Do we need to add that into the mix?
I keep feeling this is like sending a lot of untrained people with hot-glue guns to fix leaks in the Hoover dam. There are a LOT of different licenses in a package ranging from fonts, straight documentation text, various header files, source code, the licenses themselves, etc. We are then trying to parse all that and put it in a one line summary which will somehow give a person/machine reading it enough context to know what to do with the code.
The question that we should first ask ourselves should be: what is the license field used for? Who is *actually* the target audience? Someone who would like to only put GPL code on their system? Someone who would like to prevent GPLv3 code from getting on their system?
Depending on the target usecase, we'll arrive at different solutions for this problem.
I think we should look at the problem from the beginning and try to find a good tool to help fix the problem. Then deploy and correct the tool until it helps fix the problem in the first place.
One possible solution would be to attach a license to every file in a package. This would make it to a certain extend easier to enumerate all the licenses, but it would definitely blow up the package metadata tremendously for a questionable benefit.
Cheers,
Dan