11:19 a.m.
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_...
-
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_library_...
- https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
Are there any other such pages?
Thanks!
Jilayne
11:28 a.m.
Jul 22, 2022 11:19:54 AM Jilayne Lovejoy <jlovejoy(a)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
11:36 a.m.
On Fri, Jul 22, 2022 at 12:29 PM Maxwell G <gotmax(a)e.email> wrote:
Jul 22, 2022 11:19:54 AM Jilayne Lovejoy <jlovejoy(a)redhat.com>:
> - https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
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
11:43 a.m.
Jul 22, 2022 11:37:18 AM Richard Fontana <rfontana(a)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
2:54 p.m.
New subject: [Fedora-packaging] Re: Re: other licensing guidance
On 7/22/22 10:43 AM, Maxwell G wrote:
Jul 22, 2022 11:37:18 AM Richard Fontana
<rfontana(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to packaging-leave(a)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.fedoraproje...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
3:47 a.m.
New subject: [Fedora-packaging] Re: Re: other licensing guidance
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(a)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
9:33 a.m.
New subject: [Fedora-packaging] Re: Re: other licensing guidance
On Mon, Jul 25, 2022 at 4:47 AM Petr Pisar <ppisar(a)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(a)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/ROO...
Note that we have an open issue to reassess the various pre-Artistic
2.0 versions of the Artistic License.
Richard
2:37 a.m.
New subject: [Fedora-packaging] Re: Re: other licensing guidance
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(a)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(a)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/ROO...
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
1:03 p.m.
New subject: [Fedora-packaging] Re: Re: other licensing guidance
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar <ppisar(a)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
1:57 p.m.
New subject: [Fedora-packaging] Re: Re: Re: Re: other licensing guidance
On 7/26/22 12:03 PM, Richard Fontana wrote:
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar <ppisar(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to packaging-leave(a)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.fedoraproje...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
11:01 p.m.
New subject: [Fedora-packaging] Re: Re: other licensing guidance
On Tue, Jul 26, 2022 at 3:37 AM Petr Pisar <ppisar(a)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
12:39 a.m.
New subject: [Fedora-packaging] Re: Re: Re: Re: other licensing guidance
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(a)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
639
days inactive
644
days old
11 comments
4 participants
participants (4)
-
Jilayne Lovejoy -
Maxwell G -
Petr Pisar -
Richard Fontana