Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011787Dwarf FortressGeneralpublic2021-07-23 03:252021-08-24 09:16
Assigned Tolethosor 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformLinuxOSDebianOS VersionBullseye
Product Version0.47.05 
Target VersionFixed in Version 
Summary0011787: The release tarball for Linux ships GPL-licensed shared libraries, but violates their license
DescriptionThe release tarball for Dwarf Fortress for Linux contains these shared libraries:

$ tar -tf df_47_05_linux.tar.bz2 df_linux/libs/ df_linux/libs/

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: [^] 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 ReproduceUnpack the downloaded release tarball, look in libs/, see that and are there, but not licensing information or a pointer to corresponding source code is provided along them.
Additional InformationThis 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 and 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;a=blob;f=COPYING3;h=94a9ed024d3859793618152ea559a168bbcbb5e2;hb=HEAD [^]) and the GCC runtime exception (e.g. taken from;a=blob;f=COPYING.RUNTIME;h=e1b3c69c179dfaff5744ea4bf853e6b0d90c9ef9;hb=HEAD [^]).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
lethosor (manager)
2021-08-11 14:11
edited on: 2021-08-11 19:43

I am not a lawyer, but [^] 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.

kritzefitz (reporter)
2021-08-24 09:16
edited on: 2021-08-27 03:11

I think libgcc_s and libstdc++ should be equally (un-)problematic, as they should both be covered by the same runtime library exception (from [^]):

> 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 ( [^] 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!

- Issue History
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 View Revisions
2021-08-24 09:16 kritzefitz Note Added: 0041138
2021-08-27 03:11 kritzefitz Note Edited: 0041138 View Revisions
2021-08-27 03:11 kritzefitz Note Edited: 0041138 View Revisions

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker