Re: [Fedora-legal-list] Re: Re: Re: other licensing guidance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 26. 07. 22 v 20:51 Daniel P. Berrangé napsal(a):
On Tue, Jul 26, 2022 at 09:37:06AM +0200, Petr Pisar wrote:
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.)
IMHO that's a false assumption / implication of a contributor's
expectations on licensing.

Making an assumption about the license of a code patch in bugzilla,
by connecting it with the license tag in the RPM spec is inherantly
flawed/incorrect IMHO.

No matter what we put in the License: tag, it will always only ever be
a crude high level approximation of the reality of the code licensing
situation. It is a non-binding 3rd party summary of a project's license.


The license for patches in bugzilla is fuzzy, because in attaching
a patch to bugzilla you are not actually directly interacting with the
upstream project. Thus we can't automatically assume they're agreeing
to the project's stated contribution rules on licensing, even though
that's what most users would be happy with if you actually asked them.


There is certainly no stated relationship between bugzilla and the
RPM license header data though, so IMHO that doesn't even come into
play in evaluating license of bugzilla patches.


IMHO for trivial bug fixes, its passable to assume the user intended
for their attached patch to be treatred as licensed under the terms
stated in the source files they modified.


Just FTR, there has been introduced `SourceLicense` tag into RPM recently:

https://github.com/rpm-software-management/rpm/pull/2117


But I doubt it will make situation any easier.


Vít



For non-trivial stuff though I would generally ask the user to submit
it upstream directly, or explicitly agree to my submitting it upstream
on their behalf.


It would be preferrable if downstream bug trackers made a more explicit
statement about assuming license for attached code patches being that
matching the files modified IMHO.

Regards,
Daniel

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux