V Fri, Jun 10, 2022 at 02:51:03PM +0200, Arthur Bols napsal(a): > 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 > I see. I overlooked this file. I saw only the top-level ./LICENSE. I'm sorry. > 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? Basically yes. You are on the right track. If a license requires for binary distributions to deliver the texts, then the packager needs to extract them (they are often called license declarations or license headers or copyright disclaimers) and store them into the binary RPM package using %license macro. You can do it manually and save them into dist-git, or you can use some kind of sed script in the spec file to collect all lines from " * Copyright (c)" to " * OF THIS SOFTWARE" lines. You can deduplicate identical pieces if you want. Of course the scripted method is prone to aging and it should be verified from time to time that it still works. Here very helps if upstream keeps the license declarations identical. Then the packager only needs to copy one, usually the top-level LICENSE file. If you have an Android phone, go to settings and somewhere deep there is a very long web page with all these license declarations. Of course there are people who claim that it's tedious and too demanding and a user can download and unpack source RPM if he wants to see the license. But I believe the license intention is to have the texts available next to the binaries. Therefore GPL recommends programmers to have a feature in their code to show the license declaration. This alleviates packager's life. For the very same reason I'm not fond of writing license declarations into each source file. I prefer keeping only a single instance in LICENSE or README file. > > 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. No problem. I agree that the Fedora guidelines are not exact enough regarding to packaging the licenses. At the beginning of my packaging experience I also preferred the effective approach. But after years of contact with various licenses, I changed my mind. Keeping a spirit of a license is off doubts. But why a part of a license specifying what I can do with the code should be more important than another part of the license specifying what I have to do with the license text? If they are equal, then the effective simplification should not overlook the other aspect. And thus should be equally good reason why to keep the license listed in the License tag. On the other hand, I understand that the overlong, complicated License tag is not much appeling to the users and that it is laborious for packages. That's probably the reason why the guidelines keep a silent status quo. At the end the License tag is nothing the licenses require us to maintain. It's just an additional value Fedora provides its users. -- Petr
Attachment:
signature.asc
Description: PGP 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
