Support loading data at runtime, or by configuring a different location for a preinstalled version
jellybob opened this issue · 84 comments
No license lawyering please - unless you're someone able to speak on behalf of freedesktop.org your interpretation of the GPL isn't going to add anything to this conversation
See rails/rails#41750 and mimemagicrb#97 for background.
In order to cause minimal impact on existing users of the mimemagic gem, particularly people using Rails, I'm going to have it load MIME types from a preinstalled version of the Freedesktop MIME types database, rather than bundling one with the gem. This will require having a copy of that either installed with your distribution, or obtained in some other way. The availability of that will be checked at build time.
Maybe you want to synchronize with @coding-bunny, who attempts to replace mimemagic with another gem. This could also be a viable approach?
I honestly see the alternative of using a different gem as a non-starter, since that gem only supports matching on file extension.
There seems to be a parallel effort over here: https://github.com/Deradon/mimemagic/tree/fetch-mine-data-dynamically
It might be useful to combine these efforts.
The license file here seems to be GPLv2 which is a large part of the problem many have with the newest release of the original gem from my understanding.
Is there any intent to find an older version to start this fork from that has a prior license option or will this fork require GPLv2?
EDIT: This comment was made before I realized the yank of the older versions occurred due to files that were being used in the older version in a way that likely violated the license those files were released under. Please disregard.
From my side it is okay to take the newest commit and revert back to MIT. But the tables.rb and freedesktop.org.xml must not be distributed as part of the gem.
Digging into this further it seems that the XML file isn't the source of truth for this gem, but instead a Ruby class generated from that file, so there are in fact a few steps:
- Locate an XML source file, either pulled remotely or via environment variable.
- Build
lib/mimemagic/tables.rbsomewhere. (Possibly it would work to pipe it all througheval, but that makes me uncomfortable) - Load
lib/mimemagic/tables.rb
The parallel effort going on appears to just pull down the XML file at build time, rather than having it in source control, but the final gem will still include that file and therefore remain GPL licensed.
@minad I'm seeing 4 test failures on master currently - are they expected?
$ rake test
Run options: --seed 26532
# Running:
.F...FF....F.
Finished in 0.173703s, 74.8404 runs/s, 299.3616 assertions/s.
1) Failure:
TestMimeMagic#test_recognize_by_magic [/Users/jonwood/Code/mimemagic/test/mimemagic_test.rb:83]:
--- expected
+++ actual
@@ -1 +1,2 @@
-"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
+# encoding: ASCII-8BIT
+"application/zip"
2) Failure:
TestMimeMagic#test_recognize_all_by_magic [/Users/jonwood/Code/mimemagic/test/mimemagic_test.rb:92]:
--- expected
+++ actual
@@ -1 +1 @@
-["application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "application/zip"]
+["application/zip"]
3) Failure:
TestMimeMagic#test_recognize_extensions [/Users/jonwood/Code/mimemagic/test/mimemagic_test.rb:55]:
--- expected
+++ actual
@@ -1 +1,2 @@
-"text/html"
+# encoding: ASCII-8BIT
+"application/xhtml+xml"
4) Failure:
TestMimeMagic#test_recognize_by_a_path [/Users/jonwood/Code/mimemagic/test/mimemagic_test.rb:64]:
--- expected
+++ actual
@@ -1 +1,2 @@
-"text/html"
+# encoding: ASCII-8BIT
+"application/xhtml+xml"
13 runs, 52 assertions, 4 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1)
/Library/Ruby/Gems/2.6.0/gems/rake-12.3.2/exe/rake:27:in `<top (required)>'
Tasks: TOP => test
(See full trace by running task with --trace)
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
I can at least comment on this having a history of monkey patching and instability.
@jellybob You may also consider distributing a GPL-licensed package including freedesktop.xml+tables.rb+LICENSE. Then the gem could pull that at runtime, offloading the generation process somewhere else. These failures are probably due to using a newer database version and encoding changes in ruby.
I don't want to have too many cooks in the kitchen, but couldn't we add an extconf.rb to the gem? It could download the xml file and generate the rb file when the gem is installed on target systems. No GPL code or files would be distributed with the gem.
I don't think that really helps anything, as you're still pulling in a GPL dependency. I'm honestly a little bit dubious that pulling in the Freedesktop XML at runtime does much for strict license compliance as well - I'm attempting to get in touch with the maintainer of that file to ensure this approach does in fact result in a compliant gem.
Just to revise that statement, I'm 90% confident that using a pre-existing install of the file is going to be safe, as there's no distribution or attempts to do an end run round GPL licensing involved in that, so I'll push on with that path. I'm less confident that including code that goes and downloads wouldn't be considered as against the spirit of the license.
WDYT about this:
- Build the
tables.rbduring runtime while installing the gem?
We could use pre_install_hooks when doing gem install.
Still, feels quite hacky tbh.
So the gem would not share any derived copies of GPL licenced work.
How would that work on platforms using this gem that don't have the required XML files installed?
Let's say a Windows / Macos System?
I just thought about fetch the xml during gem install from https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/2.1/data/freedesktop.org.xml.in.
UPDATE: More or less doing a rake tables during gem install based on my quick'n dirty PoC. (ofc rake tables would not work. Have to achieve this somehow different)
Given the generation doesn't actually take very long I'm inclined to do this at runtime - the alternative requires a bunch of hackery in a pre install hook, and potentially confusing error messages during the install. People who are concerned about the amount of time it might take to download the source file at runtime can make sure the machine they're running on has the file available before hand.
At runtime would be a showblocker for any1 where the rails application is running w/o access to the public internet.
(e.g. build docker image, which fetches data from public internet, then deploy it internally, where you don't have access)
That's why there'll be the option to load a pre-existing version of the file via an environment variable.
WDYT about this:
* Build the `tables.rb` during runtime while installing the gem?We could use pre_install_hooks when doing
gem install.
Still, feels quite hacky tbh.So the gem would not share any derived copies of GPL licenced work.
Seems like this approach still could trigger the GPL requirement. Here is a freedesktop contributor indicating that they believe the the GPL applies to the db/xml itself.
Unless you're able to speak on behalf of freedesktop.org discussions of what the GPL does or does not require are just adding noise here. Please keep discussion to the actual implementation of the plan described.
Unless you're able to speak on behalf of freedesktop.org discussions of what the GPL does or does not require are just adding noise here. Please keep discussion to the actual implementation of the plan described.
I linked to a thread where contributors to freedesktop.org are discussing exactly the issues that are also being discussed in this thread. It seemed like relevant information to take into consideration for the "plan described". Just trying to be helpful but I'll not add anymore "noise" 👍🏼 .
Apologies for the slightly rough tone there. Just to clarify I'm talking to the maintainers at the moment about what would be needed (if its at all possible) to be compliant with both the legal terms of the license, and more generally the spirit of that license.
Unless you're able to speak on behalf of freedesktop.org discussions of what the GPL does or does not require are just adding noise here. Please keep discussion to the actual implementation of the plan described.
There isn't anyone that can do that. Individual contributors hold their own copyright. I'm just but one of a number of contributors to the module where the freedesktop.org.xml originates from.
1. Support for pulling down the freedesktop.org definitions at application startup. This will be the default behaviour. 2. Support for setting the environment variable `FREEDESKTOP_MIME_TYPES_PATH`, which will disable downloading at runtime, and instead load the data from a different location.
Both look good options to me, as long as the files are used as data files, and not use to create code from. Otherwise you should use the update-mime-database file to process the XML, to create cache files (those caches are part of the shared mime info specification).
@hadess thanks for the reply. I believe the proposed solution falls within the usage you've described, so in lieu of anyone being able to definitively speak on this I'm going to go ahead and finish implementing this.
For anyone following along at home, I think we can also skip over the whole thing of generating a Ruby class, and instead just parse the mime type database directly into constants. The generation of a source file is just an optimisation which doesn't really buy us anything if we're doing it all at runtime anyway.
Thanks for the pointer @jellybob. I'm one of the people who runs freedesktop.org, but @hadess is correct. fd.o doesn't hold copyright assignments - the copyright belongs to whoever authored the code - so any decisions on copyright and licensing, including enforcement, are at the total discretion of the authors. In this case, @hadess holds substantial copyright on shared-mime-info so was entitled to take the action, and even if I wanted to I can't tell him otherwise.
I agree with @hadess that your interpretation of the license is correct - with the caveat that I am not a lawyer. Transforming the GPLed XML definitions into Ruby certainly retains the GPL obligations and implications on that Ruby. Loading and parsing the data at runtime changes that situation in two ways:
- you are using an abstract interface to the data files; you could just as easily pull a non-GPLed dataset and use that instead, so in this case the virality of the GPL is less applicable (this is heavily paraphrased and should not be taken as legal gospel), and
- the obligations of the GPL are primarily invoked upon redistribution rather than use; executing code as you're proposing here is very different from distributing code as you were previously doing
Thanks so much for your co-operation and helpful attitude. We really appreciate it, especially given the additional burden it introduces on your users.
I only have one request: please make sure this doesn't break things where it's possible for those of us who can use GPL2+ code to be able to include the data in the Gem. I'd like to still use the original mimemagic because it's simpler. :)
I don't want to have too many cooks in the kitchen, but couldn't we add an extconf.rb to the gem? It could download the xml file and generate the rb file when the gem is installed on target systems. No GPL code or files would be distributed with the gem.
Could we still use extconf.rb to download the xml just not generate a rb file?
Downloading at runtime seems inefficient and introduces an external dependency to application boot.
That would be an odd territory, If we redistribute the built code it would contain the XML thus we would need to do it under GPLv2?
Using extconf.rb you have the same problems as with downloading at runtime in regulated environments, but with a much less clear interface to deal with that. I you don't want to download at runtime then you can update your build process to pull the XML file from your distributions repos, or from the source, at build time.
@wwahammy that's not possible, as it would require redistributing either the source file, or code derived from that source file, which is what resulted in this whole situation in the first place.
What about a "fallback" that uses the Red Hat public domain MIME database? So if you can either a) provide the file via FREEDESKTOP_MIME_TYPES_PATH b) have access to public Internet during runtime, the MIME type database would be pulled, but if neither of those work, MIME type detection could still work, albeit with not as good detection. You could then (somehow) notify developers that they have to provide the mimetypes file and that a fallback is being used.
What about a "fallback" that uses the Red Hat public domain version?
I'd very curious to know what that "Red Hat public domain version" is.
What about a "fallback" that uses the Red Hat public domain version?
I'd very curious to know what that "Red Hat public domain version" is.
This link was posted in the Rails issue: https://pagure.io/mailcap/blob/master/f/mime.types
I am taking the poster's word for it, and apparently https://github.com/elixir-plug/mime uses it.
Edit: To be clear, this is not a "public domain" version of the mimeinfo database that was used by mimemagic, it's a much simpler database that takes data from IANA and a few other places.
This link was posted in the Rails issue: https://pagure.io/mailcap/blob/master/f/mime.types
Right, it's not a "version" so much as something completely different and unrelated to shared-mime-info.
This link was posted in the Rails issue: https://pagure.io/mailcap/blob/master/f/mime.types
Right, it's not a "version" so much as something completely different and unrelated to shared-mime-info.
Yes, I believe I mis-worded it. It's a separate database.
There's a PR at #3 which does the bulk of the changes needed for this, the only thing left is pulling down a version from the internet if one isn't found locally. The more I think about it, the more dubious I become that doing so is actually the right behaviour, at the very least I'm not sure it should be default behaviour on requiring the gem.
If anyone is able to review the PR (particularly @minad who actually knows and understands the code) that would be great. I'm going to go take a break for a couple of hours and then come back to this, hopefully having thought on pulling from the internet a bit.
@wwahammy that's not possible, as it would require redistributing either the source file, or code derived from that source file, which is what resulted in this whole situation in the first place.
I can redistribute the source file though under my license. I'm asking that any changes not break those who can use the older version of the gem.
@wwahammy that's up to Rails, which is what's bringing in mimemagic as a dependency, and could (potentially) allow configuring which version to depend upon. This change is on the mimemagic gem itself, and just does what's needed to bring it away from violating the GPL.
Thank you for your work on this @jellybob! Also thank you @hadess and @fooishbar for working on shared-mime-info/freedesktop.org in the first place, and thank you for helping getting this sorted out!
@jellybob I will take a look at your changes.
@wwahammy Would be acceptable for you to release a "simple" mimemagic-gpl package released under GPL-2.0 which avoids the runtime stuff? I've seen you stated before that you would like to see a GPL version?
@minad can you unarchive the upstream repository? I'm PRing into my own repo at the moment because I can't open PRs upstream. If you'd like to step away from maintaining the Gem I can totally get that, and I'd be happy to discuss helping out, but I'm not hugely interested in becoming the de-facto sole maintainer of a Rails dependency just because I happened to be the person who forked the repo!
I don't want to have too many cooks in the kitchen, but couldn't we add an extconf.rb to the gem? It could download the xml file and generate the rb file when the gem is installed on target systems. No GPL code or files would be distributed with the gem.
I don't think that this can be done this way. Since, if you would compile and distribute a compiled version of the gem it would have to be GPLv2 licensed. The only way forward seems to be of @jellybob, but this definitely has some downsides.
I do like the idea of mimemagic-gpl.
I don't think that this can be done this way. Since, if you would compile and distribute a compiled version of the gem it would have to be GPLv2 licensed. The only way forward seems to be of @jellybob, but this definitely has some downsides.
Based on my experience with including GPL code into non-GPL projects, I have had FOSS lawyers say this is perfectly acceptable and you can distribute the the result. It just depends how it's done
Everyone: there has been literally tens of thousands of dollars of developer time spent here and on the Rails and yet, to my knowledge, NO ONE has spent a few hundred bucks on a FOSS lawyer.
For my part, spending money on lawyers wouldn't really help anything. I'm working at a company with an explicit policy that GPL licensed dependency aren't permitted, this library would be GPL licensed without the changes needed, so I'm making the changes.
can you unarchive the upstream repository? I'm PRing into my own repo at the moment because I can't open PRs upstream. If you'd like to step away from maintaining the Gem I can totally get that, and I'd be happy to discuss helping out, but I'm not hugely interested in becoming the de-facto sole maintainer of a Rails dependency just because I happened to be the person who forked the repo!
I will not maintain this repository and library any longer. My proposal would be to move the library under the umbrella of some organization, either the Rails organization or a new mimemagic.rb organization maintaining this package.
A lawyer who will publicly provide legal advice is typically one of the most expensive kinds. Feel free to investigate; I’m sure it wouldn’t be hard to pool together a few hundred dollars if such a unicorn presented itself.
@georgeclaghorn You stated before that you are discussing the issue within the Rails team. Which way forward do you suggest?
A lawyer who will publicly provide legal advice is typically one of the most expensive kinds. Feel free to investigate; I’m sure it wouldn’t be hard to pool together a few hundred dollars if such a unicorn presented itself.
I am almost positive I can get an opinion though Conservancy since this affects my open source project Houdini but unless there's some sort of request official request from the Rails core team, I'm not wasting their expensive time. There's enough lawyers in enough big companies here to cover this issue.
None of them can likely provide such advice without risking legal liability and thus violating their fiduciary duty to their employer.
@wwahammy Would be acceptable for you to release a "simple" mimemagic-gpl package released under GPL-2.0 which avoids the runtime stuff? I've seen you stated before that you would like to see a GPL version?
I'm only worried about not making this brittle. I want to be able to install my bundle and never have to worry about whether some external library is available. My project doesn't have a licensing problem, we don't want a unnecessary burden.
I'm only worried about not making this brittle. I want to be able to install my bundle and never have to worry about whether some external library is available. My project doesn't have a licensing problem, we don't want a unnecessary burden.
This is perfectly understandable. I simply wonder if it is possible to have two gems implementing the same API (mimemagic and mimemagic-gpl) and exchanging them seamlessly in your stack?
My proposal would be to move the library under the umbrella of some organization, either the Rails organization or a new mimemagic.rb organization maintaining this package.
The golang mimemagic had the same license issue this morning. Perhaps both projects would be willing to join a new MimeMagic org? There are other similar cross-language orgs, such as oauth-xx, which has Python, PHP, and Ruby libraries for OAuth.
@jellybob Re: pulling from the internet
You could leave the user with a gem post-install-hook message, as many other gems have done in the past. It could evaluate the presence, or not, of the source file, and suggest three solutions if it is missing:
- Install the source file at the correct location
- Set the env variable to indicate a different location
- Provide a command the user can run which will download the file to a location which will then be specified by the ENV variable.
Engineer for a large Rails app, with an information security background, here: please do not download packages at runtime by default. Know all of those stories about abandoned Chrome extensions getting hijacked with things that steal information or run crypto miners? By downloading at runtime, you are creating a channel that allows this sort of thing. There was also an example of this happening with node.js recently as well.
libxml2 and thus Nokogiri very frequently has bugs allowing specially crafted XML files to do naughty things (this is part of the reason why Nokogiri vendors the latest version of libxml2). Doing this - by default - is bad for that reason, but it's also bad for anyone whose application deploy process would start tens of thousands of Ruby processes. If someone wasn't aware of this change and just updated to get their app working, we're talking about creating a DDoS against FDO. Applications fail to start, or if you ignore the error, they fail to work correctly once started. None of this is good, and potentially opens up that if you ignore the error, users inadvertently have vulnerabilities which only appear if the database wasn't able to be downloaded. Nevermind that many apps have restricted egress and wouldn't be able to actually reach FDO to download the file.
My suggestion: use extconf.rb to check the system for the XML file. Treat it like it's a .so you need to link to. As with most gems needing native libraries, allow specifying where to find the library via environment variables. If it's not found, fail to "compile" just like any other Ruby library that needs a shared library would (though probably provide instructions on where to get the file). Load the XML file on boot and build out the Ruby class hierarchy or whatever you need to do.
I agree with others that building a derivative work on install (e.g., via extconf.rb) isn't a clear-cut solution absent some sort of mechanism like the Linux kernel has for license tainting. What I would probably do is make this integrate with Bootsnap somehow, so that if you're using Bootsnap, it only needs to parse the .xml file when you have Bootsnap cache the application's classes and whatnot. I'm not sure the Bootsnap cache is a derivative work, but as the application functions without it and users are already needing to come to grips with this possibility with other libraries, I wouldn't worry about it one way or the other.
I'd come to much the same conclusion as @ziggythehamster while away from the computer. I'd much rather have build time failures due to the XML file not being available at gem install than run time failures at some random point in the future because a server was unavailable. I'm not hugely familiar with extconf.rb, but I'm going to dig into that and see if I can persuade it to do what's needed.
Yeah, I'm not either, but I know that's how gems with native code compile that native code. But it's a Ruby file that executes in the install process and it would be ideal to use that as an opportunity to check for the package being available without abusing one of the other hooks in RubyGems.
PR has been updated, and now explicitly only supports making use of a pre-existing copy of the file. Setting the environment variable at build time will look in that location, and then persist it for use at runtime in the form of a C extension (because the way extconf.rb works requires one to be built as far as I can tell... this was quite the rabbit hole).
@minad for the sake of unblocking the world's (and my own) Rails deployments, I'm going to step up and volunteer to take over maintenance of this gem until a better solution can be found. Either that, or can you (once some review has happened) push this version of the gem to Rubygems as 0.3.7, which should then make people's builds at least throw an error about needing the file, rather than just explode. Feel free to drop me an email on jon@blankpad.net if you want to talk about that somewhere less public.
@fooishbar do you have a particular location you would like me to direct people to in order to obtain a copy of the compiled freedesktop.org.xml file for use with this gem if they don't already have one? The only freedesktop.org hosted version of that file I can find is freedesktop.org.xml.in as part of the source releases, and I have no idea what the implications of using that vs a built version would be.
In danger of stating the obvious: A processed version of the file, in this case by gettext, is still GPL
Unprocessed file of course lacks translations
But hey, have a copy of my /usr/share/mime/packages/freedesktop.org.xml as shipped in fc33: freedesktop.org.xml
@jellybob I’m afraid we don’t have a canonical location for a post-processed file. To be honest I’m pretty glad we don’t, since we’re not behind a CDN or anything fancy ... there are a lot of Rails installs happening!
Perhaps you could serve the post-processed from a GH repo alongside this one? AIUI the only difference is translations.
Without having looked at that other PR (I'm trying to land one of my own for an unrelated and hopefully more fun thing), my suggestion would be to say something like:
Install your operating system's shared-mime-info package, or fetch the XML file from the Debian package:
- Visit https://packages.debian.org/sid/amd64/shared-mime-info/download and download the .deb file.
- Install the command-line version of 7-Zip for your platform (sometimes called p7zip)
- Run this command:
7z x -so shared-mime-info_2.0-1_amd64.deb data.tar | 7z e -sidata.tar './usr/share/mime/packages/freedesktop.org.xml'
I would suggest to use ar + tar but ar cannot output to stdout (what) and tar needs --strip-components=4 to not create a hierarchy in the current directory.
In fact, if you use double quotes for the path, it runs on Windows verbatim:
M:\>7z x -so shared-mime-info_2.0-1_amd64.deb data.tar | 7z e -sidata.tar "./usr/share/mime/packages/freedesktop.org.xml"
7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21
Extracting archive: data.tar
--
Path = data.tar
Type = tar
Code Page = UTF-8
Everything is Ok
Folders: 166
Files: 92
Size: 4773833
Compressed: 140800
M:\>dir *.xml
Volume in drive M is rpool_HOME
Volume Serial Number is BA16-F57C
Directory of M:\
10/09/2020 10:26 2,341,534 freedesktop.org.xml
1 File(s) 2,341,534 bytes
0 Dir(s) 8,020,033,536 bytes free
So change the above to use double quotes and then the instructions work for every major OS.
@ziggythehamster this is great, thank you, I've added instructions based on your exploration to the readme.
Amazing work. Thanks for all your work on this @jellybob and others. I'm sure I speak for all of the community when I say I really appreciate it! 👍
As #3 has been merged already I'll copy my comment overhere:
When releasing this as a 0.3.x version will this possibly break on windows machines if you're creating a new rails project?
Rails still has a soft-dependency on 0.3.x.
So I'ld personally like to at least bump the minor version so the rails maintainers can explicitly decide to go w/ the approach here.
(I'd like to avoid another left-pad-situation where suddenly rails install fails for a lot of projects)
Also copying my reply from that thread :)
Yes, it will potentially break creating a new Rails project on Windows, but that feels like a better option than quietly imposing GPL 2 licensing on every new Rails project which is the current situation. We're also looking at yanking 0.3.6 because of those licensing implications, so in practice whatever happens here new Rails projects on Windows are going to be broken to some degree.
Ultimately I don't think there's any way to avoid some degree of pain for users while still complying with license terms, and I consider abiding by those terms to take precedence for both legal and moral reasons.
Mimemagic has been moved to its own org, so I'm also redirecting discussion of this to the repo over there, as shown above. Closing this one.
@jellybob Just to let you know, can't comment yet on issues there.
An owner of this repository has limited the ability to comment to users that have contributed to this repository in the past.
Not sure if intended or not.
@Deradon opening this one back up for now - they are indeed locked down temporarily while we get everything moved over and a release out to try and keep the noise down.
I'd highly suggest to let the rails maintainers know when you release this version and what implications this release has.
Would like to avoid, or at least mitigate, another left-pad-situation where suddenly bundle install does not work in a (new) rails project, for at least some users, and issues pile up in the rails/rails repo.
Yup, we will be doing that.
Closing this issue now as 0.3.7 has been released.
This has been discussed with both @hadess and @fooishbar, and yes, to the best of knowledge of all of us 0.3.7 is legitimately licensed as MIT since we no longer distribute any GPL licensed data with this gem.
I indeed have done so :-) but thanks, that’s sufficient for a public answer here.
@ljharb I'd be really curious to hear the outcome of that if you're happy to share it, either publicly or more privately.
Same from the fd.o side; my email is daniel@fooishbar.org and Bastien's is pretty easily findable as well. It would be really good to understand what you've gleaned from this. We've worked with SFC before and they've always been extremely sensible.
@hadess I wanted to ask about installing dependencies: https://github.com/mimemagicrb/mimemagic#dependencies. As far as I understand, installing those on production environment to use in my project forces my project's source code to be licensed under GPL? Basically shifting the licensing issue from mimemagic gem to me as author of my project?
installing those on production environment to use in my project forces my project's source code to be
licensed under GPL
I heavily doubt that. Look at the linux kernel running via GPLv2 in proprietary environments. IMO there
are comments here on the issue tracker that can not possibly be correct, but it probably distracts too
much from the main issue at hand to discuss that here. It would be nice to read a post-mortem analysis
at a later point, though, simply because I am pretty certain that other projects may be in a somewhat
similar situation licence-wise.
@ipepe
IANAL - A huge portion of the GNU stack is GPL licensed, and a large chunk of that is installed on millions of machines running corporate software.
The license cares about "distribution". You can install whatever GPL'd code you want on the machine and use the tools together. As long as this gem, and your project, are not "distributed" with GPL-licensed code inside them, then it is safe.
Seems to me the previously bundled version of the Freedesktop had some handling for docx files that is no longer handled with the standalone installer... I had to patch in some mimetypes in init of my rails app to get the same behavior as before.
Used the init found here for what it's worth.