View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011787 | Dwarf Fortress | General | public | 2021-07-23 03:25 | 2021-08-24 09:16 |
| Reporter | kritzefitz | Assigned To | lethosor | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Platform | Linux | OS | Debian | OS Version | Bullseye |
| Product Version | 0.47.05 | ||||
| Summary | 0011787: The release tarball for Linux ships GPL-licensed shared libraries, but violates their license | ||||
| Description | The release tarball for Dwarf Fortress for Linux contains these shared libraries: $ tar -tf df_47_05_linux.tar.bz2 df_linux/libs/libstdc++.so.6 df_linux/libs/libgcc_s.so.1 df_linux/libs/libstdc++.so.6 df_linux/libs/libgcc_s.so.1 These files look like they are part of GCC, which is licensed under a GPL3 license (with some GCC specific exceptions, which don't seem to apply to this case). However, I can't be exactly certain, because no files in the tarball, nor the website explain where these files come from, what their licensing conditions are and what source code they have been compiled from. This brings up problems, because section 6 of the GPL3 places certain restrictions on the redistribution of compiled forms of covered works, i.e. the shared libraries included in the Dwarf Fortress tarball. The two requirements Dwarf Fortress falls short on are these: * section 5 (which is referenced from section 6) point b states the following: b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices". This isn't done in the case of Dwarf Fortress. The files in question are accompanied by no copyright or license statement at all. * section 6 point d places requirements for the distribution of compiled files through a website download or similar: d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. This isn't done in the case of Dwarf Fortress either. There is no mention at all, what source code the files in question have been compiled from. You may find that this is very pedantic, and you might be right. While this does violate the copyright of the copyright holders of GCC, it is probably unlikely that they will notice this, let alone take legal action against this practice. However, leaving this problem as it is, might cause problems for other people down the line. As an example, there is a bug report for the dwarf-fortress package in Debian, regarding this problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986119. Debian does care about not violating the rights of copyright holders, so the problem had to be actually dealt with. This means the maintainer of the package in Debian (yeah, it's me) had to go out of their way to patch the files in question out of the package. This isn't really a drama, but fixing the issue should be easy, save people who want to redistribute Dwarf Fortress (such as me) some work, and prevent potential legal problems in the future. | ||||
| Steps To Reproduce | Unpack the downloaded release tarball, look in libs/, see that libstdc++.so.6 and libgcc_s.so.1 are there, but not licensing information or a pointer to corresponding source code is provided along them. | ||||
| Additional Information | This problem doesn't really have to be hard to fix. As the first option, maybe you could just remove the files from the tarball? Why are they there in the first place? Most (all?) Linux systems should have those files installed already. For the Debian package, we chose to not use those files for our package, even before we noticed the copyright problem, because as I said: pretty much every Linux system already has these files installed. If you think keeping the files in the tarball is really necessary, the following steps should be sufficient to do so in a license-compliant manner, but keep in mind, I am not a lawyer and this is not legal advice: * Include a paragraph in README.linux such as this: The files libstdc++.so.6 and libgcc_s.so.1 in the libs/ directory are compiled from the source doe for GCC. They are licensed under the GPL version 3 (available in gpl3.txt) and the additional GCC runtime exception (available in gcc-exception.txt). Their source code is available at http://<link to relevant source code tarball>. * Include copies of the GPL3 (e.g. taken from https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=COPYING3;h=94a9ed024d3859793618152ea559a168bbcbb5e2;hb=HEAD) and the GCC runtime exception (e.g. taken from https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=COPYING.RUNTIME;h=e1b3c69c179dfaff5744ea4bf853e6b0d90c9ef9;hb=HEAD). | ||||
| Tags | No tags attached. | ||||
|
|
I am not a lawyer, but https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html appears to indicate that using at least libstdc++ in this way is acceptable. libgcc_s is somewhat less clear. You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. A Compilation Process is "Eligible" if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC. For example, using non-GPL-compatible Software to optimize any GCC intermediate representations would not qualify as an Eligible Compilation Process. DF is definitely compiled solely with GCC on the platforms in question (Linux and macOS). As for why these files are included: DF must have them in order to launch if the system-provided GCC libraries are older than the GCC version used to compile DF. For more modern distributions, this is not the case, and the libraries often actually need to be removed in order for DF to launch. On macOS, these files are almost always necessary, unless users have installed GCC through third-party methods (e.g. Homebrew). In any case, adding licensing information can't hurt, so I'll forward your suggestions along to Toady. |
|
|
I think libgcc_s and libstdc++ should be equally (un-)problematic, as they should both be covered by the same runtime library exception (from https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html): > What libraries does the GCC Runtime Library Exception cover? > > The GCC Runtime Library Exception covers any file that has a notice in its license headers stating that the exception applies. This includes libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov, and other libraries distributed with GCC. AIUI libgcc_s belongs to libgcc, but I am not a lawyer either. However, I'm never quite sure how exactly to interpret that exception. Solely from reading it, I would agree with you, since Dwarf Fortress is compiled in an eligible process and combined with the runtime libraries. However the FAQ (https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html again) says the following: > Note that if you distribute libstdc++ as an independent library, you will need to follow the terms of the GPL when doing so. For example, if you distribute the library itself in object code form, you will need to provide source code to your recipients using one of the methods listed in section 6 of GPLv3. But as long as you are eligible to take advantage of the GCC Runtime Library Exception's permissions for your own program, the GPL's terms do not extend to it. But then again, the question this comes up in doesn't seem all that relevant to this case. I the end I think it comes down to what exactly “combining” and “independent” are supposed to mean. One could argue that since Dwarf Fortress and libstdc++/libgcc_s are different files so they are “independent”. One the other hand one could argue that one has been (dynamically) linked to the other so they are “combin[ed]”. I really don't know which is correct and I can find arguments in favor of both sides. As you say, adding licensing information can't hurt. So I would just err on the side of caution and include it. In any case, thanks for looking into this! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-07-23 03:25 | kritzefitz | New Issue | |
| 2021-08-11 14:11 | lethosor | Note Added: 0041132 | |
| 2021-08-11 14:11 | lethosor | Assigned To | => lethosor |
| 2021-08-11 14:11 | lethosor | Status | new => acknowledged |
| 2021-08-11 19:43 | lethosor | Note Edited: 0041132 | |
| 2021-08-24 09:16 | kritzefitz | Note Added: 0041138 | |
| 2021-08-27 03:11 | kritzefitz | Note Edited: 0041138 | |
| 2021-08-27 03:11 | kritzefitz | Note Edited: 0041138 |
