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@xxxxxxxxxx> 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@xxxxxxxxxx>: > > > > > > > > > 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/pages/license-field.adoc#user-content-perl-packages > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
