freedesktop.org.xml file license

[hadess]

I've historically been the maintainer of shared-mime-info for around 15 years, and cmd/parser/freedesktop.org.xml looks like it's a copy of the database shipped with shared-mime-info, which is released under the GPL, with shared-mime-info's translators work merged in, and the GPL header removed.

The license that you're shipping mimemagic under (MIT) isn't compatible with shared-mime-info's.

There are a number of possibilities to fix this problem:

• change the mimemagic license to be GPL compatible
• parse the XML file that shared-mime-info ships at runtime, and don't ship it in a codebase with an incompatible license

Using a GPL file as a source makes your whole codebase a derived work, making it all GPL, so I think it's pretty important that this problem gets corrected before somebody uses it in a pure MIT codebase, or a closed-source application.

You will also need to re-add the GPL header to the shared-mime-info XML file as a matter of urgency.

[zRedShift]

@hadess @fooishbar I hope you'll find the changes to your satisfaction.

[hadess]

@hadess @fooishbar I hope you'll find the changes to your satisfaction.

This is great, thanks very much.

[taelerwatkins-tcn]

@zRedShift One thing to note, you seem to have left the "v" off the 2.0 release. Our dep revision lock went from looking like "v1.1.0" to "2.0". Just something interesting to note. This is also non-conformant with gomodules.

[taelerwatkins-tcn]

With the versioning as-is being non-compliant with go modules (regarding my previous comment), this cannot be downloaded via go mod download. You will always get v1.1.0 because the old versions are cached at proxy.golang.org

[yawaramin]

Then it seems the v1.1.0 (or older) cached in proxy.golang.org is also being distributed from there under an incorrect license?

[zRedShift]

This is great, thanks very much.

Great! Thank you.

With the versioning as-is being non-compliant with go modules (regarding my previous comment), this cannot be downloaded via go mod download. You will always get v1.1.0 because the old versions are cached at proxy.golang.org

I updated the tag to v2.0.0. I haven't used golang in a while so I forgot some of its idiosyncrasies. I think a /v2 needs to be appended to the repository URL now.

Then it seems the v1.1.0 (or older) cached in proxy.golang.org is also being distributed from there under an incorrect license?

I wonder if there's a way to force yank/retract it. I tried to add a retract directive in the go.mod file, for the previous releases, but according to this:

Module authors can now retract module versions using the retract directive in go.mod. A retracted version still exists and can be downloaded (so builds that depend on it won't break), but the go command won’t select it automatically when resolving versions like @latest. go get and go list -m -u will print warnings about existing uses.

[SamSaffron]

Note anyone reading this, I am more than open for a PR that adds the "magic" detection to https://github.com/discourse/mini_mime (MIT) - a dependency of Mail gem and by association Rails.

Turns out https://github.com/apache/tika/blob/8b82b4c942c82f9cc2eb393e669227606b5f15fc/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml is Apache which is compatible with MIT.

If anyone feels like submitting a PR go for it!

[taelerwatkins-tcn]

It shows up now with the v2.0.0 tag, so thanks for that, but... go mod is ridiculously hard to please.

$ go mod download github.com/zRedShift/mimemagic@v2.0.0 go mod download: github.com/zRedShift/mimemagic@v2.0.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I really hate the rigidity they've built into this system. We've had similar issues with go mod in one of our GitHub repos.

[taelerwatkins-tcn]

Oh that's right, you don't need a folder, you can manage it by creating a "v2" release branch, then tagging the release using that branch. Also, if going v2.x.x, then the name declared in the module must have /v2 appended to it, as well as the package declarations in the go source files.

Or you could use a version such as v1.2.0 without all the module trouble.

[zRedShift]

It shows up now with the v2.0.0 tag, so thanks for that, but... go mod is ridiculously hard to please.

$ go mod download github.com/zRedShift/mimemagic@v2.0.0 go mod download: github.com/zRedShift/mimemagic@v2.0.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I really hate the rigidity they've built into this system. We've had similar issues with go mod in one of our GitHub repos.

Reading the documentation, it seems the "correct" way is to use go mod download github.com/zRedShift/mimemagic/v2 (with an optional @v2.0.0 suffix). I guess I have been spoiled by better package managers, but it seems very silly. If someone doesn't pin their version, their package should be broken by a major semver breaking update.

Should I introduce a v1.2.0 tag as well? That's what @minad did, with v0.3.6 and v0.4. I have a feeling, however, that changing from MIT to GPL-2.0-or-later is a major, semver breaking change. On the other hand the MIT license was never valid in the first place so technically it was always under GPL and nothing changed between the versions.

[taelerwatkins-tcn]

We commented at almost the exact same time with exactly the same content pretty much, haha.

EDIT (to reduce notification clutter): I must apologize. I should have opened a separate issue for the golang specific versioning conversation. I must admit that I was reading from the bottom up and stopped to reply when I found the end result. After reading top-down for more context I realized my error in my "contributions", such as they were, to this issue. Again, my apologies.

[em-]

Turns out https://github.com/apache/tika/blob/8b82b4c942c82f9cc2eb393e669227606b5f15fc/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml is Apache which is compatible with MIT.

@SamSaffron I'd suggest to double check with someone with better legal knowledge than me, but I'm not really sure that "Apache is compatible with MIT" in general. I'm confident enough that you can make the resulting work to be Apache-2.0 as a whole, but I sincerely doubt about doing the reverse as you'd be basically ignoring the Apache-2.0 patent provision for instance. Let's not address a licensing issue with a different one. :D

[fooishbar]

Thankyou for resolving this. Hope you have a nice Sunday.