On 10/06/2022 13:20, Petr Pisar wrote:
That's everything fine. (Although there are licenses which
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.
src/QtAwesome/LICENSE.md is contained in the v0.55.0.tar.gz which
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
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
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.
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
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
instead recommends listing all the licenses in the RPM tag. Because people
does not understand it make does the effective simplification incorrectly.
understand where you're coming from, but calling it a cult is not