Upstream dependency license compatibility check?


In light of the recent Ruby Gem license SNAFU (Good summary here: Ruby off the Rails: Code library yanked over license blunder, sparks chaos for half a million projects • The Register) I was wondering if dependencies with incompatible licenses is something that Tidelift picks up on?

It doesn’t seem so from the various docs and blogs on the subject, and the " Get verified license info from a Tidelift-managed catalog" link in the UI doesn’t return anything for me, so I couldn’t check what that discloses.

If not, this seems like it would be a good feature for lifters and Tidelift customers alike.


1 Like

@mbrookes thank you so much for the great question!

We do a lot of behind the scenes work to determine what license applies to a package version, and we’re actively working on making that data more useful and available to customers. We allow customers to specify a license policy that can exclude and include licenses that they’ve chosen, and we can then compare what packages they are using to that defined set as they look to align their projects with that policy. More features are coming soon including quicker license discovery as well as “yanked” project discovery. In this case the offending GPL licensed versions of the package were yanked pretty quickly, so the main issue became unavailable dependencies.

@brenna This case is a bit more nuanced, since the library in question was using code copied from a GPL licensed library rather than the library itself, but the knock-on effect of the license change was to put downstream dependants in jeopardy of either having to change their license, or stop using the offending library - depending on how they used and redistributed it.

In any case, it got me to thinking about our upstream dependencies, and any transient ones, and how we have no easy mechanism to check their license compatibility with ours. Even if we did it manually (no small task), this case demonstrates that the license could be changed detrimentally.

So it seems that, more than just checking that a customer’s direct dependencies meet their license policy, it should check the upstream tree as well to ensure that these are licensed with the same license, or a compatible one with the same or more permissive terms than the base license policy.

1 Like

@mbrookes Agree, this case was quite nuanced and demonstrates why what we’re building is so valuable!

We do monitor the licenses of upstream dependencies both direct and transitive. At the moment, this isn’t really visible in the lifter dashboard, but soon you’ll be able to keep track of your upstream dependencies licenses, along with any other information we may discover (yanks, deprecations, etc…) by adding your lifted package as a project on Tidelift and setting up your license policy to match your preferences.

We’re actively developing this part of the system so would love to get any feedback you have as you start to use it. In fact, we’re going to schedule a few sessions starting next week for folks to take a look at some of the work we’ve been doing on catalogs, so please let me know if you’re interested.

Thank you for raising this issue and talking through this with us!

1 Like

@mbrookes Note that there was no license change here, it was a license correction. This library was always GPL due to distributing GPL-licensed code, the author only corrected the mistake in the license (which previously claimed to be MIT) and yanked all incorrect versions to prevent anybody from using code they might not be entitled to use.

While detecting license incompatibilities seems more doable, detecting license mistakes like this one seems quite hard, and even if such feature existed and worked fine, it wouldn’t have avoided the mess here, because the main issue as @brenna pointed out was unavailable dependencies caused by the yanking, and that was an intentional move by the gem author.

Whatever the case, I think the incident stills shows that Tidelift is super valuable. The “license tasks” where lifters have to go through their libraries and declare or confirm the declared license for their packages make it more likely that lifters detect this kind of mistakes earlier and thus correcting them creates less mess.

1 Like

In fact it is not clear that the library was always GPL; it always should have been GPL, but since it wasn’t labeled as such, it’s possible a court would treat it as licensed the way it’s labeled, and it would not automatically become GPL in this situation. It all depends on your lawyer’s interpretation, absent precedent, and lawyers’ interpretations vary widely.

Additionally, anyone who was merely depending on mimemagic, but not directly distributing it, arguably does not fall under GPL at all, regardless of how it’s licensed (this would not hold with AGPL). There’s also an arguable loophole in GPL that if mimemagic was merely used to provide a website, and was never distributed to others’ machines, that the website in which it’s used does not need to be GPL-licensed. The SaaS Loophole in GPL Open Source Licenses

It’s impossible to use an automated tool to detect an issue that requires a human to detect it, which describes the improperly MIT-licensed mimemagic versions.

1 Like

Yes, definitely subject to interpretation. I could put some apples in a box and label the box as “pears”, and I guess a judge who knows nothing about fruits could even sentence that I’m right :laughing:. Fortunately it doesn’t need to get there since the gem author admitted the error in the label.

Sure, it’s up to each user of the software to decide whether they are entitled to use it or not. I’m just trying to say that the author made the interpretation that people could be using his gem because it had a MIT license and that they wouldn’t be entitled to use it if they realized it was actually GPL. So the yanking and thus preventing people from using all releases, was an intentional choice.

I guess plagiarism detection techniques checking well known software sources could be used, but yeah definitely a hard problem to solve.

1 Like