Hacker News new | ask | show | jobs
by mooreds 1909 days ago
I give my boss a hard time about our dependency management system because it is relatively unknown[0], but licensing is built into it from the ground up. You can't import any dependency (no matter how buried) without assigning a license to it.

This lets us confidently know, via software, the open and closed source licenses in our code base.

Licensing is one of those out of band concerns that doesn't burn you until it does.

0: https://github.com/savant-build/savant-core

4 comments

> You can't import any dependency (no matter how buried) without assigning a license to it.

That wouldn't help here. Mimemagic declared itself to be MIT, and only turned out to be GPL because it embedded a file derived from GPL sources. That file didn't even have a license header specifying it as GPL.

Anyone importing it would mark it as MIT.

EDIT: Mimemagic didn't even turn out to be GPL, it turned out to be infringing on the GPL, and the author solved that by relicensing it to GPL.

Fair point. I guess software couldn't have helped this issue.
That's a good idea generally, but it wouldn't have saved you from this issue. The gem had an MIT license, and the offending file was copied in, not sourced through a dependency.
Depends on the process. If assigning a license means that there is a review of the dependency before use, this is normally seen.
Gotcha, fair point. I should have read deeper; I only read the Rails issue, but should have dove into the mimemagic one. My bad.
You're correctly getting downvoted for your thinly-veiled advertisement because it's besides the point. The gem was labeled as "license: MIT" all the time, but that label was just factually wrong. Garbage in, garbage out.
People can of course downvote me for whatever reason they want. I do object to you calling this an advertisement. Sure, it links to my employer's website, but it is an OSS build library that addresses licensing issues.

Yes, GIGO applies, but what about the underlying Gem? Was the XML file relicensed? (Haven't dug into that issue 97 referenced in the GH thread.)

Edit: from sibling comments, looks like this build system wouldn't have caught the underlying issue, which was a GPL licensed, unmarked file copied in.

The product in question being open-source or not has nothing to do with whether it's advertising. I would have been okay with it if your product genuinely did something to solve the issue at hand, but as you admit, it does not, so all that's left is "this is a good time to mention my product".
The build tool I linked to would not have solved the issue. I should have read further into the GH repos to understand how the Gem was contaminated. That's my fault.

I have thoughts on the applicability of the build tool mentioned and its relation to licensing issues in general, but I feel I'm repeating myself. I'm not sure continuing this conversation will be productive, so I'm gonna stop.

How do you handle transitive dependencies?
When you are importing a jar file (this is a java build tool) you have to specify the provenance of every dependency, and any dependency of those dependencies.

It's a real pain, but the pain is all upfront.