https://bugzilla.redhat.com/show_bug.cgi?id=2398039
--- Comment #36 from Cristian Le <[email protected]> --- > src/providers/twitch/ChatterinoWebSocketppLogger.hpp uses the same license as > websocketpp, whose license we have included under > resources/licenses/websocketpp.txt, and is already included in our About page. License is one thing, the copyright is another. The copyright holders are different in there. Technically not a big issue since the copyright is still preserved in the files, but depends on how you use those resources/license. > lib/twitch-eventsub-ws is not an external library, but another module of > Chatterino (it lives in the same repo, no submoduling), so licensed under the > same Chatterino license. We could include the same license in that directory > if that would help clarify things. It's ok, just informal clarification is also ok. The eyebrow got raised when it was referencing some other page in the readme so just needed some clarification. If you could add spdx and copyright to the files than our licensecheck software will give you a cookie :) > resources/emoji.json is a list of emojis / emoji sets & their capabilities. > We attribute this and the emoji sets we include inside our About page. Emojis and Unicode license is "quite the topic". Maybe you have already researched that topic? > The rest of the included licenses are included correctly as far as I could > tell, with the only thing I could see being wrong is technically the > copyright year has been updated in some upstreams, which we haven't updated > in a while. The one that I noticed was - licenses/crashpad.txt is Apache-2.0 - Upstream is MIT https://github.com/Chatterino/crash-handler/blob/c8cf62b64906f794ac84cb0c22ceb401f4ea1e8d/LICENSE > Do header-only libraries fall under the same category as statically linked > libraries for the purpose of licenses you need to include? Header-only and static libraries, yes, you own those symbols so you also inherit those licenses. The less known case is C++ templates, that also technically applies, but it is hard to detect and enforce. I don't know of requests on us to enforce that, but for header-only and static, we should be enforcing it and tracking CVEs accordingly. > We could make this a little bit easier by adding a comment to the top of each > license file in resources/licenses/ with information about how we use it, > i.e. whether the license covers assets, it's a header only library, > statically linked, or shared linked. There is a standard for this. In my previous job it used `qt_attribution.json` [1], but I believe that is derived from some other standard on SBOM and SPDX. Kitware/CMake also want to invest in a solution on that last I known. Re: statically vs shared linked, you can only determine from CMake, so you need some simple `configure_file` in there, in which case, you could also conditionally add the `About` for features that are not being built. But not a big priority, so up to your discretion. [1]: https://wiki.qt.io/Qt_attribution.json -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2398039 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202398039%23c36 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
