https://bugzilla.redhat.com/show_bug.cgi?id=1919639 --- Comment #32 from Otto Urpelainen <oturpe@xxxxxx> --- The process is regretfully long, but we are making progress, which is great. I found two more items: - Because the binary is given a capability, it must be compiled to use position independent by adding '%global _hardened_build 1'. Reference: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie - Directory hierarchy for the icon starting at /usr/share/icons/hicolor must be explicitly imported from the package that owns in by adding 'Requires: hicolor-icon-theme'. Reference: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership which I found unclear, so asked in the mailing list, too: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx/thread/FRVLCDRNBPWE4BSENJAQ5KOEUZVKT5R3/ In other news, I actually installed the package on F34 system and can confirm that it works. From the 4 games I tried, only Settlers 2 was unplayable due to mouse not working. So in general it works, great! Regarding licenses, it is really good that upstream is involved with getting it right for Fedora. GPL compatibility is also an absolute must if dosbox-x comes with a GPL license, so it is good that it has been asserted already — but it is not the only condition that is found in various licenses. All the conditions the author has put on their work have to be fulfilled, otherwise including the software in Fedora would be a copyright violation. I will give an example, reference for this are the Licensing Guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ Original work from dosbox-x is licensed under GPLv2+, so the specfile license field will contain at least that. I picked one item from attachment licensecheck.txt that is listed as having something else than GPLv2+: *No copyright* Do What The Fuck You Want To Public License, Version 2 --------------------------------------------------------------------- dosbox-x-dosbox-x-v0.83.11/include/whereami.h dosbox-x-dosbox-x-v0.83.11/src/gui/whereami.c Checking those files, I find out that it is a bundled library with a copyright notice saying it is originally from https://github.com/gpakosz/whereami and is dual licensed under WTFPL and MIT licenses. So now License is at least (GPLv2+ and (WTFPL or MIT)). Then to licensing conditions. The only condition of MIT is this: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." This is fulfilled by adding the MIT license to the package through the %license field. Checking the Licensing Guidelines, there is a discouraged alternative path, but basically the rule is that the license has to be copied from upstream. So, upstream has to be contacted and asked to add the full license text (which can be copied from the whereami repo). On the other hand, WTFPL does not have any restrictions at all, so including the license text is not required. Still, the Licensing Guidelines have a SHOULD item about asking upstream to add it, just to remove any doubt regarding what the license really is. Probably it can be added when the MIT case is resolved without any extra effort. This procedure has to be repeated for all the content that gets compiled into or otherwise included in the rpm. Details way depending on the exact licenses. (Note that in the particular case of gpakosz/whereami, upstream could leverage the great freedom of WTFPL and simply relicense the whole thing under GPLv2+ and their own name. Complication removed. This may not be an option for other files with different licenses. In theory Fedora could also do the relicensing, the guidelines do not say anything about it, we could ask in the mailing lists — but my hunch is that the answer would be to always use the same license upstream has and fix possible hurdles upstream.) I am also not sure how the resulting combined license for dosbox-x executable should be packaged. Can multiple license files be packaged? Can the multiple licenses be concatenated with a script in the specfile? Or does Fedora only accept a single file that is maintained upstream and copied verbatim? Most probably we have to find an answer to that question before this review is complete. but before doing that, I would really like to first follow the two paths that are available for simplyfying the situation: source minification (remove clutter so it is easier to understand what content is really needed and how it is licensed) and library unbundling (breaking the monolith to multiple small and simple packages — many of which hopefully already exist in Fedora). -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
