Hi Fedora packagers and legal,
As Richard and I have been going through the wiki licensing documentation and creating the new Fedora-legal Docs pages (soon to be published!!!) - we have been trying to make sure we have all license-related guidance in one place. This way, Fedora community members know there is one place to go for this kind of information, instead of various places. This will also help in ensuring things stay current. We noticed there are a couple language-specific bits on licensing in the package guidelines.
Is anyone opposed to moving those to the Fedora-legal docs pages on licensing?
The pages we found were: - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_license_for... - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_library_bin... - https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
Are there any other such pages?
Thanks! Jilayne
Jul 22, 2022 11:19:54 AM Jilayne Lovejoy jlovejoy@redhat.com:
There are no license guidelines that I see in the Golang Packaging Guidelines. Am I missing something? -- Thanks,
Maxwell G (@gotmax23) Pronouns: He/Him/His
On Fri, Jul 22, 2022 at 12:29 PM Maxwell G gotmax@e.email wrote:
Jul 22, 2022 11:19:54 AM Jilayne Lovejoy jlovejoy@redhat.com:
There are no license guidelines that I see in the Golang Packaging Guidelines. Am I missing something?
There is some stuff I see relating to license file inclusion, but that's a general topic we haven't been able to tackle yet.
I like the idea of having "legal" guidelines for specific languages be maintained in one place with the more general legal guidelines, but I'm not sure we can really do that with the Golang guidelines at this point.
Richard
Jul 22, 2022 11:37:18 AM Richard Fontana rfontana@redhat.com:
There is some stuff I see relating to license file inclusion
Are you talking about the `%golicenses` part? That's not a legal guideline. The go macros just have a special way of installing licenses, as opposed to marking them with %license in %files. This part should be kept in the Go Packaging Guidelines. -- Thanks,
Maxwell G (@gotmax23) Pronouns: He/Him/His
On 7/22/22 10:43 AM, Maxwell G wrote:
Jul 22, 2022 11:37:18 AM Richard Fontana rfontana@redhat.com:
There is some stuff I see relating to license file inclusion
Are you talking about the `%golicenses` part? That's not a legal guideline. The go macros just have a special way of installing licenses, as opposed to marking them with %license in %files. This part should be kept in the Go Packaging Guidelines.
you're right, that is not a legal guideline - wrong link, too many windows open!
This one has a bit (that is now covered in the new docs and outdated) https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_license_tag
J.
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-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/packaging@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
V Fri, Jul 22, 2022 at 01:54:10PM -0600, Jilayne Lovejoy napsal(a):
On 7/22/22 10:43 AM, Maxwell G wrote:
Jul 22, 2022 11:37:18 AM Richard Fontana rfontana@redhat.com:
There is some stuff I see relating to license file inclusion
Are you talking about the `%golicenses` part? That's not a legal guideline. The go macros just have a special way of installing licenses, as opposed to marking them with %license in %files. This part should be kept in the Go Packaging Guidelines.
you're right, that is not a legal guideline - wrong link, too many windows open!
This one has a bit (that is now covered in the new docs and outdated) https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_license_tag
This is there because most of the Perl packages uses this license combination. It helps packagers to identify the typical license correctly.
Feel free to copy (and reword) it into licensing guidelines. Then Perl packaging guidelines will replace the section with a link to that advice in licensing guidelines. Is it Ok? Please only make the advice linkable.
-- Petr
On Mon, Jul 25, 2022 at 4:47 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Jul 22, 2022 at 01:54:10PM -0600, Jilayne Lovejoy napsal(a):
On 7/22/22 10:43 AM, Maxwell G wrote:
Jul 22, 2022 11:37:18 AM Richard Fontana rfontana@redhat.com:
There is some stuff I see relating to license file inclusion
Are you talking about the `%golicenses` part? That's not a legal guideline. The go macros just have a special way of installing licenses, as opposed to marking them with %license in %files. This part should be kept in the Go Packaging Guidelines.
you're right, that is not a legal guideline - wrong link, too many windows open!
This one has a bit (that is now covered in the new docs and outdated) https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_license_tag
This is there because most of the Perl packages uses this license combination. It helps packagers to identify the typical license correctly.
Feel free to copy (and reword) it into licensing guidelines. Then Perl packaging guidelines will replace the section with a link to that advice in licensing guidelines. Is it Ok? Please only make the advice linkable.
What do you think of this? https://gitlab.com/fedora/legal/fedora-legal-docs/-/blob/main/modules/ROOT/p...
Note that we have an open issue to reassess the various pre-Artistic 2.0 versions of the Artistic License.
Richard
V Mon, Jul 25, 2022 at 10:33:53AM -0400, Richard Fontana napsal(a):
On Mon, Jul 25, 2022 at 4:47 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Jul 22, 2022 at 01:54:10PM -0600, Jilayne Lovejoy napsal(a):
On 7/22/22 10:43 AM, Maxwell G wrote:
Jul 22, 2022 11:37:18 AM Richard Fontana rfontana@redhat.com:
There is some stuff I see relating to license file inclusion
Are you talking about the `%golicenses` part? That's not a legal guideline. The go macros just have a special way of installing licenses, as opposed to marking them with %license in %files. This part should be kept in the Go Packaging Guidelines.
you're right, that is not a legal guideline - wrong link, too many windows open!
This one has a bit (that is now covered in the new docs and outdated) https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_license_tag
This is there because most of the Perl packages uses this license combination. It helps packagers to identify the typical license correctly.
Feel free to copy (and reword) it into licensing guidelines. Then Perl packaging guidelines will replace the section with a link to that advice in licensing guidelines. Is it Ok? Please only make the advice linkable.
What do you think of this? https://gitlab.com/fedora/legal/fedora-legal-docs/-/blob/main/modules/ROOT/p...
That's good.
I'm slightly surprised that you decided to hide the unapproved license part "Artistic-1.0-Perl" from "GPL-1.0-or-later OR Artistic-1.0-Perl" expression.
I understand it makes the License tag more comprehensible.
On the other hand, I worry it will complicate merging user-supplied patches back to upstreams. Because users contributing to Fedora will see only GPL, hence they will understand their patches are GPL. But then upstream will assume or insisit on the full "GPL-1.0-or-later OR Artistic-1.0-Perl" combination. The will make a friction because Fedora maintainers will need to renegotiate a license of the patch with the patch author to get the "OR Artistic-1.0-Perl" part back. (Though I admin this case quite theoritical. I haven't seen many patches from Fedora users. Fedora-origin patches are usually authored by Fedora maintainers.)
Does hiding the unapproved licenses from a License tag also influnce which license files are packaged with %license macro? Should we because of that start removing Artistic-1.0-Perl texts from Perl packages?
Note that we have an open issue to reassess the various pre-Artistic 2.0 versions of the Artistic License.
I can see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/37. I wasn't aware about it. Allowing Artistic-1.0-Perl would palliate the above mentioned worry.
-- Petr
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar ppisar@redhat.com wrote:
I'm slightly surprised that you decided to hide the unapproved license part "Artistic-1.0-Perl" from "GPL-1.0-or-later OR Artistic-1.0-Perl" expression.
I understand it makes the License tag more comprehensible.
That's not really the reason. It's the assumption that in any case where there's a dual license involving a 'good' (allowed) license and a 'bad' (not-allowed) license, we assume that Fedora shouldn't be seen as extending a non-Fedora license downstream, even symbolically. For example, "GPL-2.0 OR LicenseRef-Horrible-Proprietary-License" would look inconsistent with Fedora's own policies.
On the other hand, I worry it will complicate merging user-supplied patches back to upstreams. Because users contributing to Fedora will see only GPL, hence they will understand their patches are GPL. But then upstream will assume or insisit on the full "GPL-1.0-or-later OR Artistic-1.0-Perl" combination. The will make a friction because Fedora maintainers will need to renegotiate a license of the patch with the patch author to get the "OR Artistic-1.0-Perl" part back. (Though I admin this case quite theoritical. I haven't seen many patches from Fedora users. Fedora-origin patches are usually authored by Fedora maintainers.)
Hmm, interesting issue. I guess if a Fedora user is providing a copyrightable patch in, say, a Bugzilla ticket, it's unclear. Not because of the License: field, but more because of the concept that Fedora is not actually distributing anything under the Artistic License. Even if the user's copy of the repository has the same dual license as upstream, it's not clear because Fedora policy would seem to suggest that the user can't submit a patch under the Artistic License. But that's also true even if we authorize "GPL-1.0-or-later OR Artistic-1.0-Perl" in the License: field. All the more reason to accelerate the reassessment review of the Artistic License. :-)
Does hiding the unapproved licenses from a License tag also influnce which license files are packaged with %license macro? Should we because of that start removing Artistic-1.0-Perl texts from Perl packages?
We haven't really started to tackle the %license issue yet. For now I would suggest not changing any existing practice.
Richard
On 7/26/22 12:03 PM, Richard Fontana wrote:
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar ppisar@redhat.com wrote:
I'm slightly surprised that you decided to hide the unapproved license part "Artistic-1.0-Perl" from "GPL-1.0-or-later OR Artistic-1.0-Perl" expression.
I understand it makes the License tag more comprehensible.
That's not really the reason. It's the assumption that in any case where there's a dual license involving a 'good' (allowed) license and a 'bad' (not-allowed) license, we assume that Fedora shouldn't be seen as extending a non-Fedora license downstream, even symbolically. For example, "GPL-2.0 OR LicenseRef-Horrible-Proprietary-License" would look inconsistent with Fedora's own policies.
On the other hand, I worry it will complicate merging user-supplied patches back to upstreams. Because users contributing to Fedora will see only GPL, hence they will understand their patches are GPL. But then upstream will assume or insisit on the full "GPL-1.0-or-later OR Artistic-1.0-Perl" combination. The will make a friction because Fedora maintainers will need to renegotiate a license of the patch with the patch author to get the "OR Artistic-1.0-Perl" part back. (Though I admin this case quite theoritical. I haven't seen many patches from Fedora users. Fedora-origin patches are usually authored by Fedora maintainers.)
Hmm, interesting issue. I guess if a Fedora user is providing a copyrightable patch in, say, a Bugzilla ticket, it's unclear. Not because of the License: field, but more because of the concept that Fedora is not actually distributing anything under the Artistic License. Even if the user's copy of the repository has the same dual license as upstream, it's not clear because Fedora policy would seem to suggest that the user can't submit a patch under the Artistic License. But that's also true even if we authorize "GPL-1.0-or-later OR Artistic-1.0-Perl" in the License: field. All the more reason to accelerate the reassessment review of the Artistic License. :-)
Does hiding the unapproved licenses from a License tag also influnce which license files are packaged with %license macro? Should we because of that start removing Artistic-1.0-Perl texts from Perl packages?
We haven't really started to tackle the %license issue yet. For now I would suggest not changing any existing practice.
just to add some color to a couple things raised here. As may be obvious at this point, the process of reviewing and updating all the licensing and legal related documentation has raised some questions and also brought to light other things that could probably use a re-review as well. The %license advice in the packaging guidelines and re-reviewing Artistic-1.0 are two such examples. In the spirit of some kind of "project management" (not trying to boil the ocean) and reaching the immediate goal of publishing the new Fedora-legal documentation, etc., we have noted various things like these for later/further investigation or review. :)
Jilayne
Richard _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-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/packaging@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar ppisar@redhat.com wrote:
I'm slightly surprised that you decided to hide the unapproved license part "Artistic-1.0-Perl" from "GPL-1.0-or-later OR Artistic-1.0-Perl" expression.
I understand it makes the License tag more comprehensible.
On the other hand, I worry it will complicate merging user-supplied patches back to upstreams. Because users contributing to Fedora will see only GPL, hence they will understand their patches are GPL. But then upstream will assume or insisit on the full "GPL-1.0-or-later OR Artistic-1.0-Perl" combination. The will make a friction because Fedora maintainers will need to renegotiate a license of the patch with the patch author to get the "OR Artistic-1.0-Perl" part back. (Though I admin this case quite theoritical. I haven't seen many patches from Fedora users. Fedora-origin patches are usually authored by Fedora maintainers.)
Does hiding the unapproved licenses from a License tag also influnce which license files are packaged with %license macro? Should we because of that start removing Artistic-1.0-Perl texts from Perl packages?
OK, after some deliberation, we've decided to give an exception to packages containing Perl code that use the Perl 5 GPL|Artistic dual license. These packages can continue to represent the dual license in the License: field.
It is possible that a similar exception might be granted in the future in some comparable case involving some other dual license and some other community, but I have a feeling there isn't any.
Note that we have an open issue to reassess the various pre-Artistic 2.0 versions of the Artistic License.
I can see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/37. I wasn't aware about it. Allowing Artistic-1.0-Perl would palliate the above mentioned worry.
As for this, though, and again after much deliberation, we've decided to keep the status of Artistic-1.0-Perl as not-allowed.
Richard
V Wed, Jul 27, 2022 at 12:01:34AM -0400, Richard Fontana napsal(a):
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar ppisar@redhat.com wrote:
I'm slightly surprised that you decided to hide the unapproved license part "Artistic-1.0-Perl" from "GPL-1.0-or-later OR Artistic-1.0-Perl" expression.
I understand it makes the License tag more comprehensible.
On the other hand, I worry it will complicate merging user-supplied patches back to upstreams. Because users contributing to Fedora will see only GPL, hence they will understand their patches are GPL. But then upstream will assume or insisit on the full "GPL-1.0-or-later OR Artistic-1.0-Perl" combination. The will make a friction because Fedora maintainers will need to renegotiate a license of the patch with the patch author to get the "OR Artistic-1.0-Perl" part back. (Though I admin this case quite theoritical. I haven't seen many patches from Fedora users. Fedora-origin patches are usually authored by Fedora maintainers.)
Does hiding the unapproved licenses from a License tag also influnce which license files are packaged with %license macro? Should we because of that start removing Artistic-1.0-Perl texts from Perl packages?
OK, after some deliberation, we've decided to give an exception to packages containing Perl code that use the Perl 5 GPL|Artistic dual license. These packages can continue to represent the dual license in the License: field.
It is possible that a similar exception might be granted in the future in some comparable case involving some other dual license and some other community, but I have a feeling there isn't any.
Note that we have an open issue to reassess the various pre-Artistic 2.0 versions of the Artistic License.
I can see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/37. I wasn't aware about it. Allowing Artistic-1.0-Perl would palliate the above mentioned worry.
As for this, though, and again after much deliberation, we've decided to keep the status of Artistic-1.0-Perl as not-allowed.
Thanks for the guidance.
-- Petr
-
Jilayne Lovejoy -
Maxwell G -
Petr Pisar -
Richard Fontana