V Fri, Jun 10, 2022 at 11:27:27AM +0200, Arthur Bols napsal(a): > On 10/06/2022 09:19, Petr Pisar wrote: > > Maybe it's not what Moolticute project claims, but it's correct. If Moolticute > > project bundles the font which is not GPLv3+, but CC-BY, and does not say so, > > then the project's claim is incorrect. > The license for QtAwesome is contained in the repo, so it is mentioned. It's not in the tar ball which upstream distributes to Fedora. > > Now to the License tag of the binary RPM package: /usr/bin/moolticute contains > > a copy of src/QtAwesome/QtAwesome/fonts/fontawesome-4.6.1.ttf (grep for > > "DDhg-iW" string). Hence you need to list a license of that font file in the > > License tag. RPM License tag is not about servility to upstream projects. It's > > about providing accurate license data. You should not copy mistakes of the > > upstream. > I don't think upstream is making a mistake (except when license files for > included libraries are missing). When someone creates a FOSS project, they > choose a license. They should check that all libraries are compatible with > that license, but I don't agree that it is a mistake that there isn't a > license breakdown in the repo. The license is normally (and should be) > mentioned at the top of the library files themselves, or somewhere in the > library directory. 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. A recipient of the tar ball gets a wrong impression that GPLv3 agreement is the only set of requirement he needs to fulfill. And that's not true. He also needs to fullfill requirements of the the license of the font. > > How did you come to a conclusion that the font is CC-BY? In my opinion it > > could be OFL, if it were Font Awesome Free. > I guess due to licensecheck, but I don't recall. The license should be OFL > as mentioned in the LICENSE file [0]. I'll correct the mistake next release. > > But I don't think this specific package and project is the topic of this > thread. It was given as an example to explain my point of view. > > [0]: > https://github.com/mooltipass/moolticute/blob/master/src/QtAwesome/LICENSE.md > 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. 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. But that's not how licensing works. If you have a file whose license requires forwarding the license text (like OFL), then simply each participant in the chain of distribution must do it. And a fact that the license is "compatible" with GPLv3 has no effect on it. Technically it isn't compatible. GPLv3 does not mandate carrying OFL text. Hence once you combine GPLv3 and OFL code, you need to forward OFL text forever. An idea that a license overlays another one is not generally true. It always depends on the specific license. 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. -- 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
