Nutanix Objects violates MinIO’s open source license(blog.min.io) |
Nutanix Objects violates MinIO’s open source license(blog.min.io) |
Until then here is my spicy story: - In 2019: Minio Sales contacted Nutanix (like this user mentioned https://news.ycombinator.com/item?id=32152645) hoping for a nice big cheque.
- 2019-2021: Nutanix cites Apache-2 license and refused to pay.
- 2021: Minio changed its license to AGPL (probably few others like Nutanix)
- 2021: Nutanix knows this and refuses to use AGPL version with their product.
- 2022: Discussion went on for another year and nothing came out from Nutanix.
- Now: Minio decided to publicly shame the company.
By the time I joined in June 2021, MinIO was deprecated and we were using an in-house S3 REST API server. I am skeptical that any of the APGL code was distributed because we just weren't using it around the time that MinIO changed from Apache to AGPL.
I don't know if that makes MinIO bad, better or good but it's all about money.
- What are the consequences for these companies?
- Do they share revenue with the open source projects?
- Can they simply distribute these services without any consequences?
- If not, When and How does a small open source project org enforce track and their license?
See Redis for example, two Israeli dudes took the open-source Redis, made tons of money.
Everyone is happy: the two founders became rich, the VCs became rich.
What about the authors and contributors of Redis ? Well thank you for the gift. As a present you can have the privilege to work for us to keep maintaining your bugs. Don't complain too much.
Then you can rewrite the history to make it sound like you created Redis and it's a win, while it's actually just a very smart dude in Italy who wrote most of the software using his own sweat and support from his employer (Pivotal).
He was eventually hired by Redis-the-company, allowed them to use the trademark (originally they were Redis Labs which was a compromise with him), went to their conferences, trained their Redis developers (who contributed to Redis-the-open-source), etc.. I assume he was happy with the deal as he spoke positively about them and chose to spend a lot of time with them, and eventually retired after I presume getting a nice amount of money from the decade-long adventure.
In the long term I think this kind of behavior is going to kill open source for things beyond libraries and building blocks.
Everything open on the Internet is destroyed by exploitation of one form or another: appropriation, spam, scams, etc. I've become fond of saying "the Internet is a dark forest."
If people want to make money off open source, then dual licensing is a good way.
Permissively licensing code and then when companies use it as they wish (due to the permissive license), complaining about it does not look good.
Now this is exposed the next question is if Nutanix Objects is just a MinIO wrapper then what value are they even proving here?
I wonder how many other licences they're violating this way.
MinIO uses AGPL which explicitly includes network usage so Nutanix is forced to provide all patches and associated code.
https://github.com/minio/minio/commits/master/LICENSE
This really seems like Nutanix just didn’t include the MinIO NOTICES file in their OSS disclosures for some reason. Something so minor should have been an easy oversight to fix. Without actually testing out Nutanix, it’s hard to know if they are actually violating this part of the Apache license. MinIO isn’t included in their “open source packages we use” webpage, but that’s not where the NOTICES message would need to be included. Either way, it’s odd that things escalated like this.
The newer AGPL versions of MinIO would offer its own licensing challenge for Nutanix (which is part of the reason for the switch to AGPL). But that’s not even what MinIO is focusing on in their post. MinIO also don’t show the version of their software that they claim Nutanix is using. And it’s very possible that Nutanix froze the minio version in April 2021 (quite likely the case).
However, in later releases they seemed to have replaced the minio based protocol adapter to something that they developed in-house in C++ and have no longer using minio in their protocol stack.
- As you said, MinIO was used to translate S3 REST API requests to internal RPCs.
- MinIO was replaced with an in-house S3 API server.
- I distinctly remember seeing a patch 6-12 months ago where MinIO was removed from the build.
Read Apache v2 attribution clauses.
But the parent to your comment says they don't use it (any more)???
If they then continue to redistribute it, they are committing a copyright violation. That’s when there is cause for a lawsuit.
I wonder how it works. What is the act of revoking an open source license exactly? I assume they simply sent a letter and wrote a blog post? Pretty sure in my country it would have no legal force. Is it different in the US?
There's all kinds of specific legal teeth for that behavior.
The press release is high on FUD (can’t revoke an irrevocable license, no evidence presented they have deployed the AGPLv3 version) and low on details why it took them three years to issue a press release when an injunction would have been granted pretty quick if Nutanix were truly in violation of the Apache license.
I don’t claim to know the details but I do know a little bit the rights under Apache2 and (unless my understanding is incorrect) MinIO’s claims are baffling.
They changed their license from Apache recently. https://en.wikipedia.org/wiki/MinIO#Re-licensing
"2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form."
Afaik Apache only requires you to maintain the copyright when distributing in source form (ie you don’t need to mention the license in binary form) but I’m not a lawyer and maybe misread. The license is certainly irrevocable and patent indemnifying provided you don’t violate it.
You can’t both try to engender good will by releasing your code as OSS and then simultaneously going after someone who would seem to be complying with the terms with FUD. To see the FUD most clearly:
> and we believe they may also be in violation of the GNU AGPL v3 versions of MinIO
If that were the case you’d actually be in a court of law enforcing the license rather than trying to sway any kind of public opinion.
This almost certainly stems from their switch to AGPLv3 to ensure that cloud providers can’t use it as part of their own offering. That’s fair but also provides context on motivation.
That's essentially what I find contentious, is whether "subject to the terms and conditions of this license" it is irrevocable or it is irrevocable irrespective of whether the terms of the license are being violated. With its phrasing I assumed it's the latter.
https://www.nutanix.com/viewer?type=pdf&path=/content/dam/nu...
Looks like it's just there for show.
> we believe they may also be in violation of the GNU AGPL v3 versions of MinIO.
`may also be`? you are not even 100% sure whether they are using your AGPL v3 version? I have no clue, what the heck you were discussing for 3 years.
Moving from Apache-2.0 to AGPLv3 is a clear trap for those who use Minio as part of their commercial offering. With AGPLV3 one need to "disclose your source code" where as its not required with Apache-2.
If you started your "Open source" project with AGPL it is a different thing but to start the project under Apache-2 and few years later introducing AGPLv3 is kind of lame and unethical, IMHO. https://github.com/minio/minio/discussions/12156
Why? The alternative competitors like VMware are better? I'm not up to date on the details but perhaps you may want to elaborate. Thanks.
http://techrights.org/2020/04/28/openwashing-vmware-after-gp...
https://sfconservancy.org/copyleft-compliance/vmware-lawsuit...
MinIO is licensed under AGPL (the current versions, at least): https://github.com/minio/minio/blob/master/LICENSE
It effectively mandates that the modified version needs to be made available: https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
So the logical first question is: why pick software that is using AGPL? Did the engineers/managers just not care? Did they miss it? I know for a fact that there are many out there who couldn't care less about licenses and compliance. Maybe companies haven't been strong armed into caring about licensing as much as they have been in regards to GDPR, for example?Secondly, why should the modified version remain a "secret"? Would competition suddenly spring up? Or maybe the project contains tight coupling to the rest of the platform, which could be considered a security risk?
Why isn't open sourcing a modified version something that would take a few hours anyways, since then none of this would be an issue?
(disclaimer: I discuss SSPL below because I find it interesting; apologies for the tangent)
Honestly, the state of software licensing sometimes puzzles me. For example, MongoDB switched over to SSPL altogether: https://www.mongodb.com/community/licensing
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. ...
Seems like that applies to even patches: https://github.com/mongodb/mongo MongoDB is free and the source is available. Versions released prior to October 16, 2018 are published under the AGPL. All versions released after October 16, 2018, including patch fixes for prior versions, are published under the Server Side Public License (SSPL) v1. See individual files for details.
DigitalOcean, for example, proudly advertises managed MongoDB as a service: https://www.digitalocean.com/products/managed-databases-mong...And yet, to the best of my understanding, the entirety of the DigitalOcean platform isn't open source (even though many projects are): https://github.com/orgs/digitalocean/repositories
Or even anything that might have something to do with MongoDB in particular: https://github.com/orgs/digitalocean/repositories?q=mongo&ty...
It just feels like one of those "rules for thee, not for me" situations, since it wouldn't be feasible for small companies to compete with them. Edit: someone mentioned them probably running the enterprise version which is probably the explanation for this!
That said, the thought experiment of building a company (including all systems) as 100% open source is really interesting, whether such a thing would be feasible if people stopped caring about "guarding" their IP and whatnot.
If someone is to blame, then it's the company leadership and legal department. As much as we want to make us engineers more important than we are, we are not decision makers. Blame should be put where it belongs.
Imagine a medical doctor or civil engineer claiming that knowing the laws of their professions is "mudane". That's why no one takes programers seriously.
> we are not decision makers.
You totally can decide to not work on stuff you are not comfortable with. It's not like there's a shortage of software engineering jobs.
Blame lies with those who are complicit by choice, just as much as those who are directing the behaviour.
Oh, come on. Engineers these days are not stupid. While I agree that their boss could plainly lie to them that he bought a commercial license, it was more like, "What will we use for the underlying storage?" "Maybe MiniIO, they're S3-compatible and efficient." "Fine. Can we use their code, though?" "Sure, it's open source, and we are a *aaS business, so no problem." I saw this kind of thinking before.
One of the issues with open source software, from a branding perspective, is that you can technically be in the clear, but violate the social contract that implicitly exist in the community. Many companies fail to factor that part in when running licenses through legal.
We use a lot of FOSS in our company. We pay licenses and contribute very little (our job isn't to improve gitlab or docker, we are shipping a software product on top of that), but I wouldn't know where exactly we are in the legal-illegal spectrum to save my life.
I consider myself an employee, not an entrepreneur. If I was an entrepreneur, I sure would happily seek legal advice on what exactly is fair use of open source. But really, I wouldn't know who to trust on the free advice market to figure out what I'm allowed and not allowed to do when starting up. I have absolutely 0 interest in legal stuff and it's mostly scary and confusing to me (and that's probably why I don't do any entrepreneurship, not even a side hustle in consulting), and I wish I and other salary men would be given a break about what the company is doing.
Nutanix shouldn't do what they are doing, but I don't think engineers should be to blame. At the end of the day, if an employee would have to go through everything that the company might not do perfectly right before deciding on a job, we would work nowhere. I wouldn't work for Oracle, but where to draw the line exactly ?
[1] https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
however every company thinks in its own way:
https://itextpdf.com/how-buy/agpl-license
> You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications.
and they also kinda fork the license with this text:
> When using iText 7 Community under AGPL, you must prominently mention iText and include the iText copyright and AGPL license in output file metadata, and also retain the producer line in every PDF that is created or manipulated using iText.
I mean this makes it really hard to trust the license at all, what would happen if I build a sever that can modify/create/convert pdfs and release the source code and than I have another program that calls this server internally with a http client, is that still some kind of linking or is it more like mongodb?
I would happily build something with agpl when I could use itext/ghostscript and build something like minio which could than be used behind the scenes, but if that is not possible or if it is a grey zone than I'm not sure if agpl is a cool license at all. every company who uses the agpl writes something different about it, thats why an "official" clarification would be really really cool.
It's the paradox of tolerance: you must not tolerate those who find others intolerable.
It’s a viral license. It infects everything it touches.
Of course, they all differ in subtle ways, so you have to try for yourself.
> And yet, to the best of my understanding, the entirety of the DigitalOcean platform isn't open source (even though many projects are): https://github.com/orgs/digitalocean/repositories
I don't think it's required to open source everything, only the bits that provide the MongoDB service. I don't know if they've done that.
Also, the SSPL seems to be a little controversial [1] as it appears to want to relicence all software it's running near under itself.
[1] https://en.wikipedia.org/wiki/Server_Side_Public_License
Yes, that's my exact point - these things are sometimes full of finer points. I don't doubt that DigitalOcean have talked with MongoDB and have probably figured out some sort of a deal, or another way to offer it as a service (someone mentioned them using the enterprise version, where the terms are probably different).
Though offering MongoDB as a service for a small no-name company all of the sudden seems impossible, unless they actually want to open soruce lots of their own code.
> Also, the SSPL seems to be a little controversial [1] as it appears to want to relicence all software it's running near under itself.
Of course, there was backlash to it even existing, much like larger companies didn't really like AGPL being a thing either.
Then again, I guess one could argue that MongoDB definitely can create such a license, as a reaction against cloud platforms utilizing their solution: https://www.mongodb.com/blog/post/mongodb-now-released-under...
This should be a time of incredible opportunity for open source. The revenue generated by a service can be a great source of funding for open source projects, far greater than what has historically been available. The reality, however, is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture most of the value while contributing little or nothing back to the community. As a result, smaller companies are understandably unwilling to wager their existence against the strategic interests of the large cloud vendors, and most new software is being written as closed source.
I don't really have a horse in that race, though in theory such a license would be good for the open source community, whilst its effects on larger cloud vendors are also pretty much clear. Of course, there is a lot of controversy around it and it's not considered "open source" at all by many.I guess that MinIO or any other company could also do something similar, have dual licenses, where interested parties can pay for commercial usage and whatnot.
There would still need to be an acknowledgment from the NOTICES file, but that’s it.
You also are free to study and learn from the code
AGPL is purposefully designed to eliminate the Embrace, Extend, Extinguish model of Cloud providers, where the provider embraces a popular open source projects, creates a "service" from it, extends that service in order to make their flavor non-compatible with out contributing upstream in an effort to extinguish the original project.
There’s way too much nuance to give a clear answer without something being wrong. Give an example?
Another question is, can anyone just decide to offer commercial version of any opensource project? Is there any kind of license that protects the interest of opensource developers.
Apache is a non-copyleft license. Copyleft licenses like the GPL also require that any code changes, derivative works code, etc. needs to be made available if the software is distributed.
However, you can absolutely charge for support, etc. (But I can't assert copyright over code I didn't actually write.)
>Is there any kind of license that protects the interest of opensource developers
If by "protects the interest" you mean forces consumers of the code to pay them or allows them to restrict who uses their code, then pretty much no. The Open Source Definition as it stands pretty much excludes those kind of restrictions. The developers could of course just choose a proprietary license instead if they want to control how their code is used.
> Does that mean, the owners of the platform to have to pay the other platforms?
No.
Tons of "value-add platforms" exist like this: wrap a bunch of open source up, add a UX layer on top and offer support. As long as you comply with the terms of the license, you can do just that. And many licenses (MIT/BSD/friends) are often complied with by merely redisplaying that software's license in the documentation or on a LICENSES file somewhere.
But there are licenses that are less permissive. The GPL is the one most people think of. If you modify and distribute GPL licensed software to others, you have to share your source. How do you dodge this? SaaS: change the GPL licensed software as much as you want, never distribute it, but instead allow users to interact with it over the network. Totally compliant.
Hence, we got AGPLv3, with this big provision:
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Now, if your bundled SaaS solution includes AGPLv3 software, you have to make its code available.
There are interesting questions here ... if you take an AGPLv3 software and slap a nice GUI under it, is that "linking" under AGPLv3? Possibly. There's at least an argument to be made.
> Is there any kind of license that protects the interest of opensource developers.
If your interest is building software and releasing it openly while keeping it away from people who want to monetize it, traditionally the use of AGPL does just that. Google, Facebook, Amazon – I have first or second-hand knowledge that any attempt to bring AGPL into those ecosystems is a hard no without exception.
But, what "interest" are you trying to protect? I have released software under the BSD license that has been adopted in commercial applications. I'm fine with that; it was in my interest to release it under the BSD license, that's all.
Licenses matter. Pick the one that encodes what you'd like to achieve.
I seriously don't get why engineers think they share no responsibility whatsoever for the company they work for. Somehow, they seem to think their situation is comparable to someone picking orders at an Amazon fulfillment center. Thinking they "have no choice" when making 6 figures and having to fight off the recruiters. That's just an easy excuse they tell themselves to help them sleep at night. It's an insult to workers who actually have little choice to do shitty jobs for shitty companies to put food on the table and can barely make ends meet.
You cannot know laws that are not there, and the very definition of a lot of software positions these day is ‘do evil’.
If a company is intolerant of this, then the AGPL is intolerant of that company.
“I’m going to chose to do Z and A with your software.”
“Moral hazard! Moral hazard!”
Picking a license indicates what you are willing to have others do with your work. If you don’t want people to be able to monetize it, pick a different license.
Picking a license indicates what you are willing to have others do with your work without going after them with a threat of handcuffs and prison bars. I might not be willing to do or threaten (government-mediated) violence to someone for being an arsehole, and yet consider them an arsehole.
He didn't seem to have a real choice, maybe an illusion of choice since (from an external point of view) as he was pinned against the wall.
They were using his software commercially and even using the trademark of Salvatore (he was complaining about such uses occasionally). He was broke, I guess that's why he didn't register the trademark. Literally while they raised 40M USD, he was explaining struggling on this board:
https://news.ycombinator.com/item?id=12506743
This is actually one year after the first Redis Labs deal :/ Totally not the speech of someone with a multi-million exit in sight.
Fast-forward several years later: https://news.ycombinator.com/item?id=19203596 (with already >1B valuation)
If Salvatore just got 10% of the company he would get 100M+ USD. 1%: 10M+ USD.
Something must have happened.
If I'm wrong and he is super rich, then it's my mistake, but in general it's incredibly easy to get screwed up in a hostile shareholding / corporate environment when in front of you you have experienced lawyers and bankers.
It rings hollow to throw your hands up at the license part and say - “not my job”. It is. Understanding the legal risk of that dependency is as important as understanding the technical risk.
If your company doesn’t have a license policy, ask for a lawyer to draft that. But I’ve worked at some pretty penny-ante companies before and even they had an acceptable license policy.
If yours truly doesn’t have one, part of your job as the person building the software is to get one drafted.
It's really not the engineers' job to pick the dependencies per se, but to pick them subject to constraints that are laid out by management. There is certainly no ethical quandary or abdication of moral responsibilities in this setup: engineers will pick among choices that are pre-vetted by people who know the legal ramifications best and have a fiduciary responsibility to shareholders to make sure the company does not run afoul of applicable law.
OTOH - if the engineer did that and received flawed guidance, then it’s a legal issue and not the engineer’s issue. I guess the question is whether the legal review of all FOSS licenses in the product was done.
I'm really starting to think that companies violating OSS licenses is often times malice, not ignorance.
The greater implications of that might have something to do with how we get articles like "Software below the poverty line": https://staltz.com/software-below-the-poverty-line.html
Or maybe the revelations about how "well" supported the people who maintained Log4j were from the open source community: https://words.filippo.io/professional-maintainers/
Earlier this week, a severe RCE in a logging library called Log4j2 got everyone, from Apple to Minecraft. As of yesterday, the maintainer who patched the vulnerability had three sponsors on GitHub: Michael, Glenn, and Matt.
That's why it's hard to be angry with companies and people trying to get paid for their work, supported by various software licenses in one way or another. I do still mostly support open source in spirit, though doing that with my wallet on OpenCollective (or GitHub Sponsors or whatever) is also a good thing to do.The article doesn’t seem to state if they are redistributing it or not, but I’ll take your word for it. Without being a user of the infringing product, I’m not able to tell whose premises the server they SSH’d into is on.
You could simply choose to not pursue legal action against license violators. Choosing a permissive license and then complaining when people do what you gave them permission to do is just ridiculous.
No. Willful copyright infringement for commercial game is a crime. See 17 U.S.C. § 506(a).
It wasn't actually the intent of the AGPL to keep a cloud service from setting up a competitor to your on-prem software. Rather it was to address what some felt was a loophole in the GPL's treatment of copyleft. (Namely that operating software as a service isn't considered distribution in the eyes of the GPL and therefore a cloud provider could add some secret sauce to your open source software without contributing back to the commons.)
That said, as a practical matter it seems to be pretty effective because most cloud providers won't use AGPL software (and a lot of other companies won't either).
But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
Excellent note, and very accurate!
I can start a company that sells your AGPLv3 software tomorrow. I just have to comply with the terms & conditions. If I'm doing absolutely nothing but operating the software without change, I can satisfy the license by saying "git clone github.com/your/software", done.
Where things get murky is on the concept of linking/derivative works. If I operate a cloud service and make changes to your software to make it use my cloud systems efficiently, those changes have to be open-sourced under AGPLv3. Does that leak too much proprietary information about my systems? Very possibly. That might be enough to stop me. But if I keep going down that road, I end up risking a legal argument that our systems have become so tangled together that parts of my software fall under AGPLv3.
For most companies, this is simply not worth the risk. MongoDB took it one step further with the SSPL:
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. [...] “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane. It's also not open source under almost anyone's definition.
Not true. For AWS to run MongoDB proper, they could just negotiate with MongoDB to offer it as a managed service - as Tencent, Alibaba, SAP, IBM, Swisscom, OVH and 10+ others have.
> It's also not open source under almost anyone's definition.
Enter the OSI. While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters. A nit, but an important one - the capitals force us to realize that it's not a word in Webster's Dictionary. It's a proper noun definiton put forth and pushed by one organization. I can certainly say "...oracle is lying..." but if I say "...Oracle is lying...", I expect the black cars to drive up to my house pretty quickly.
True, that is an option. I’ll give anyone odds of it happening ;-)
> While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters.
I think talking about “open source” is overloaded to uselessness. I really prefer to talk about licenses.
Even then the consensus I’ve heard from most people who care to think about software licensing is that the SSPL is essentially a weaponized license designed to strip freedoms. Lowercase open source, you be the judge.
> That said, maybe they would indeed not license to the three "biggies"
I think it's actually likely the other direction: I suspect Mongo has been working with all three to get it licensed as a service, and any hesitation is from their potential customers.
I know AWS the best. They want total control, and hate paying other people. They can also afford a long time horizon. They didn't buy Annapurna Labs to offer an alternative to Intel. They aren't going to want to license Mongo because that cuts into margin and costs them control.