Ruby off the Rails: Code library yanked over license blunder | Hacker News Reader

Ruby off the Rails: Code library yanked over license blunder

theregister.com

51 pointspjmlp15 comments

> Paul Berg, an open-source licensing consultant, told The Register in an email that while this is a difficult situation, the developers involved appear to be handling it well.

From a lawyer/licensing POV they handled it well. From an engineering/building POV, this is very poorly done.

When thousands of websites - including government ones - are breaking because you super harshly fix what's ultimately a pretty small licensing issue, there's a problem. That licensing issue could have been quietly been fixed, it would have been less virtuous from a legal point of view, but the world would have been a slightly better place.

The licensing issue quite frankly did not harm anyone. Thousands of websites breaking, definitely did. So while this may be considered to be a success by an open source licensing consultant, the rest of the world is a bit more nuanced.

There should be plenty of permissively license MIME databases considering it's basically a compilation of public knowledge and hardly even code?

For instance, Debian has a public domain[2] mime-support package[1] where /etc/mime.types comes from. Apache and nginx both ship their own mime.types.

[1] https://packages.debian.org/buster/mime-support

[2] https://metadata.ftp-master.debian.org/changelogs//main/m/mi...

I wish there is a protocol from GPL community that any GPL violation will always be given 7 - 30 days to sort things out.

People argued that the maintainer or developer are under no obligation to be held liable for the violation, and hence yanking it was their only option. Which is fair.

But if we have had a convention in place, where by allowing time to fix the issue. It wouldn't be in a mess, especially those in different time zone across the world.

Yes we could argued it was developer's problem doing without vendored gems or a rubygems mirror which doesn't obey yanks. But I think that is a different topic.

Rails 5.2.5, 6.0.3.6 and 6.1.3.1 were released with the updated dependencies.

https://weblog.rubyonrails.org/2021/3/26/marcel-upgrade-rele...

From the release:

"Before 1.0.0, Marcel—which is distributed under the terms of the MIT License, like Rails—indirectly depended on MIME type data released under the incompatible GNU General Public License. Marcel 1.0.0 instead directly packages MIME type data adapted from Apache Tika, released under the permissive and compatible Apache License 2.0."

Already discussed: https://news.ycombinator.com/item?id=26566925

We were slightly bit by this over the weekend and caught in the unfortunate situation where we're basically left complaining about free software and handling of said ecosystem.

Luckily we didn't have any critical fixes that needed to go out. I'm sure there were a few teams who needed to scramble but were left waiting.

Yes it could be handled better, but please remember, so much of it is software where no money needed to be paid to use.

I used to use the activation.jar from JavaMail for Mime in my app. server, then I realized Mime is pretty simple and replaced it with this file: https://github.com/tinspin/rupy/blob/master/mime.txt

Thanks. I was looking for a simple mimemap like this. make it easier for my image server to detect image

What's the best practice here, for avoiding deploy-time dependencies on RubyGems.org in general, and specific RubyGems.org-hosted gems in particular?

I've been doing Rails for a number of years on medium-sized teams. However, I have been lucky/unlucky enough to have generally been distanced from the devops side of things.

Bundler lets you vendor your gems directly, obviously, but that seems like a non-starter from a practical standpoint when we consider the size of Rails+dependencies.

If you work on a non-open-source project using libraries from open-source projects, you should always:

1. have the ability to rebuild everything from your own repo, without requiring an external source to be available.

2. Specify versions of every library, preferably with a hash of their contents in some form, that gets checked at build time.

3. Subscribe to the serious bugs, announce, security, and/or major release lists for each library, so that you know when something big is happening.

4. Keep old versions that you used.

5. Update to new versions only when you have an expressible need.

Every bit of software has a cost. Sometimes that cost is in dollars, sometimes in reciprocity, and always in awareness.

Right - those are the goals and they are crucial ones. I was thinking "best practices" in terms of, well, practice. The implementation of things to achieve those goals.

The most obvious thing one could do in Ruby land is to vendor one's gem dependencies with bundler, but I'm not sure how that works in conjunction with a typical git-based workflow.

Note that:

> On Thursday 26 March, mimemagic was updated again to v0.4.1, which restored the MIT license and removed the GPL covered code – theFreedesktop.org Shared Mime Types database. Users must now provide that themselves.

More information here:

https://github.com/jellybob/mimemagic/pull/3

The issue seems to have been resolved. RoR is a great framework it should get more recognition.

It’s already the most recognized web development framework in the world outside of maybe the .NET ecosystem and maybe whatever rules Java these days.

Ditto to the other reply to your comment. RoR is extremely well recognized and widely praised. It's fallen out of fashion in the past few years, but I don't know anyone who doesn't recognize it as a great piece of technology.

Reply on news.ycombinator.com