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/LICENS...
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