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 inclusionAre 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_tagThis 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-packagesThat'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
