[cstrahan]

This was handled quite poorly -- a different course of action could have avoided all the chaos while also resolving the GPL violation.

As the GPL FAQ states:

> If a programming language interpreter has a license that is incompatible with the GPL, can I run GPL-covered programs on it? (#InterpreterIncompat)

> When the interpreter just interprets a language, the answer is yes. The interpreted program, to the interpreter, is just data; the GPL doesn't restrict what tools you process the program with.

In mimemagic's case, similar logic could apply:

* mimemagic could redistribute the GPL licensed freedesktop.org.xml file. This redistributed file would retain the original GPL license and its terms.

* mimemagic could then read the freedesktop.org.xml file at run time and generate whatever data structures it needs. mimemagic would continue to be MIT licensed without violating the GPL license.

The problem is that mimemagic includes Ruby code generated from the GPL licensed XML file, and it could be argued that this makes part of mimemagic a derivative of a GPL licensed work. They just needed to stop doing that.

Of course I can't point this out to the repository owner now that the repo has been archived and thus commenting is now disabled.

[thedanbob]

That approach is roughly being taken in this fork: https://github.com/jellybob/mimemagic/issues/1

With the difference that the gem will by default download the XML file at runtime, with the option of using a local copy specified by an environment variable. I guess they are operating under the belief that including any GPL file taints the library, or perhaps they're just playing it safe.

[Dangeranger]

Yes, this approach can work, unless the system which Rails/mimemagic is deployed to has restricted network settings. Under a restricted network setting, I believe the only solution which will work is to use a different package offering similar behavior, under a non-GPL license, or to re-implement the existing behavior using the freedesktop.org.xml as an input/output specification, rather than a source for derived code.

[nitrogen]

Presumably one could download the xml as part of the gem installation process (e.g. using mkmf as if it were a C extension, but there are probably simpler ways), so doing a local install at container build time would store the data with the gems in the Docker image (or local bundle if not using Docker).

But a mime database seems an awful lot like an uncopyrightable list of facts.

[Dangeranger]

Downloading and using the XML file as the source for some transformation would produce what is considered a derivative work, which would thereby be covered under the GPL. By accessing the file contents through an "abstract interface" this limitation could be avoided.

As I understand it, because the XML file contains instructions with regard to how and where to read files for the purpose of discovering their MIME type, those instructions are copyrightable. I could be wrong, as I am not a lawyer.