Re: Is srpm allowed to violate a license if %prep restores compliance?

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

 



On Mon, Mar 22, 2021 at 12:10:50PM +0100, Vít Ondruch wrote:
> 
> Dne 22. 03. 21 v 10:49 Zbigniew Jędrzejewski-Szmek napsal(a):
> >On Mon, Mar 22, 2021 at 09:19:43AM +0100, Vít Ondruch wrote:
> >>Dne 21. 03. 21 v 11:52 Zbigniew Jędrzejewski-Szmek napsal(a):
> >>>On Sun, Mar 21, 2021 at 11:47:17AM +0200, Otto Urpelainen wrote:
> >>>>Greetings,
> >>>>
> >>>>I am doing my first Fedora package review [1], for litehtml library.
> >>>>The source tree contains some bundled items that, in violation of
> >>>>original licenses, do not include a copy of the relevant licenses.
> >>>>There are two problem items:
> >>>>
> >>>>1. gumbo-parser is included in source form and only contains link to
> >>>>the correct license in source files and repository README, but
> >>>>license text itself is not included like the license, Apache
> >>>>Software License 2.0, demands.
> >>>This one is easy to fix: just include the license file as another
> >>>Source. It'll then be part of the srpm, even though it's not part of
> >>>the Source0 tarball. Since the upstream *links* to a license, there
> >>>is no risk of confusion about the text, you can even use this exact
> >>>URL for the Source line…
> >>
> >>Just FTR, including license file as SOURCE have always been wrong
> >>suggestion, because the review guidelines [1] states the following:
> >My interpretation was based on the text in the Licensing Guidelines.
> >I consider those to be authoritative over the Review Guidelines, which
> >after all are and must be just a derived checklist of things specified
> >elsewhere in the guidelines.
> >
> >>MUST: If (and only if) the source package includes the text of the
> >>license(s) in its own file, then that file, containing the text of
> >>the license(s) for the package must be included in %license.[4]
> >The authoritative text is unequivocal:
> >
> >   [when the license text is required by the license] either "Include a
> >   copy of what they believe the license text is" or "Choose not to
> >   package that software for Fedora".
> >
> >>>Please note that the guidelines also say that the packager MUST
> >>>contact upstream and ask them to fix the issue [1].
> >>
> >>And this is just SHOULD:
> >>
> >>SHOULD: If the source package does not include license text(s) as a
> >>separate file from upstream, the packager SHOULD query upstream to
> >>include it. [28]
> >Again, the authoritative text says:
> >
> >"Packagers who choose to do this should ensure that they have
> >exhausted all attempts to work with upstream to include the license
> >text as part of the source code, or at least, to confirm the full
> >license text explicitly with the upstream, as this minimizes the risk
> >on the packager."
> >
> >"It is important to reiterate that in situations where the indicated
> >license does not imply a requirement that the license be distributed
> >along with the source/binaries, Fedora packagers are NOT required to
> >manually include the full license text when it is absent from the
> >source code. but are still encouraged to point out this issue to
> >upstream and encourage them to remedy it."
> >
> >It does NOT say "MUST", but comes very close. Also by saying "NOT
> >required [in the other case]", it implies that [in this case] it is.
> >
> >>Granted, the licensing guidelines you are referring to might be
> >>interpreted differently.
> >"might be"? I don't think there's much wiggle room.

> My interpretation is that it is reasonably fine to include the
> package into Fedora even without license file, while the situation
> should be certainly clarified with upstream.

This is the issue we disagree on. My interpretation is that (in the
case where the license requires the text to be distributed) this is
not optional.

(We would certainly be violating that license if we were to distribute
the code without the license text. In practice, the effect of this is
small and it's trivial to rectify, but as a matter of principle, we
want to obey the licenses. And the Licensing Guidelines seem to
support this interpretation.)

> If there is no wiggle room, then you can't start suggesting "just
> include the license file as another Source." You should start with
> "Please note that the guidelines also say that the packager MUST
> contact upstream and ask them to fix the issue [1]." followed by
> that the package is forbidden from Fedora as long as there is no
> license file included

This is what I wrote (just in a slightly different order)...

> or "that they have exhausted all attempts to
> work with upstream to include the license text as part of the source
> code, or at least, to confirm the full license text explicitly with
> the upstream,".

No, "or" is not appropriate here. The recommendation to "exhaust all
attempts to work with upstream" is there because we don't want packagers
to "guess" the license text and include something different than the
upstream intended. But following that recommendation does not absolve
the packager from the requirement to include the license text.

(In this particular case that started this discussion, there is no
ambiguity about the license text, because upstream provided a working
URL to the license text. Hence my recommendation to immediately
include it.)

> But I'll be glad, if the licensing guidelines as well as review
> guidelines are unambiguous and aligned.

Me too ;)

Zbyszek
_______________________________________________
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