Re: license of the binary policy

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

 



On 10/06/2022 13:20, Petr Pisar wrote:
That's everything fine. (Although there are licenses which explicitly require
mentioning a license disclaimer in every piece of documentation.) But this not
case of v0.55.0.tar.gz. It does not contain a word about a license of the font.
The src/QtAwesome/LICENSE.md is contained in the v0.55.0.tar.gz which explicitly states:

    The Font Awesome font is licensed under the SIL Open Font License

The OFL license itself is missing though, I will ask upstream to include it.
Why isn't this LICENSE.md file in the tar ball, or Fedora dist-git? You should
add it there as well as a copy of OFL. OFL has very similar requirment as
CC-BY:

     2) Original or Modified Versions of the Font Software may be bundled,
     redistributed and/or sold with any software, provided that each copy
     contains the above copyright notice and this license. These can be
     included either as stand-alone text files, human-readable headers or
     in the appropriate machine-readable metadata fields within text or
     binary files as long as those fields can be easily viewed by the user.
Since we're expanding on this specific package (the license documentation should be substantially improved in this regard), how would you deal with the "the above copyright notice" issue? In the Moolticute project, there are multiple libraries with different licenses and different copyright notices. Most licenses state that the copyright notice must be included. For example, src/CyoEncode and src/SimpleCrypt are both BSD (to be completely accurate: the former is 2-clause, the latter 3-clause), but they have different copyright notices. The license is included in the source itself, so upstream is correct. How should packagers deal with this? Do they have to extract the license from every file and call them for example "LICENSE.CyoEncode" and "LICENSE.SimpleCrypt" and include those in dist-git?
This specific package is very relevant to this thread: It demonstrates the
very same problem. Upstream thinks that not putting a license text into the
tar ball is fine. And you think that not declaring the missing license in
License tag is fine. And you argue with effective licensing.
Let me be clear, I agree that licenses are important and they should be included in the rpm. I viewed the license field as something different, which is why I preferred the "effective" license. New packagers have a very steep learning curve. It doesn't help that licensing is a complicated and sensitive matter. The current documentation just isn't clear enough (at least for me) on how to deal with it. That the licenses aren't included is a mistake on my part as this was my first package. I am not arguing what is better or worse, since I feel like I don't have enough experience, I'm trying get a better understanding of what and why.
And that's the community effective licensing cult Mr. Fontana discourages and
instead recommends listing all the licenses in the RPM tag. Because people
does not understand it make does the effective simplification incorrectly.
I understand where you're coming from, but calling it a cult is not necessary.

--
Arthur Bols
fas/irc: principis
_______________________________________________
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