That's pretty disappointing. I personally haven't used much beyond vault (I've used but not enjoyed or built anything on terraform), but this is pretty diametrically opposed to what I appreciated most about hashicorp products. Heck, I've even contributed a chunk of the code I use the most from vault (Cert management) and now I'm going to have to reevaluate whether I can attempt to use that service for customers going forward, and whether I will contribute ever again.
It definitely feels like the whole era of VC drying up is bringing out the worst possible future for some of these non GPL/similar licenses. Which is unfortunate for any of us who have deliberately learned only OSS and operations around it, giving back the whole time, with dreams of building services that leverage that knowledge someday as a chance to be our own boss while also utilizing and giving back to the OSS that got us this far.
I read the rest of your comments on this topic and I’m sorry this happened to you.
I have extensive experience with enterprise vault, implementing and managing it across a company infrastructure to manage application secrets, and during the few years we implemented vault and was in negotiations about our contract, I noticed the sales engineers would
1) be dishonest or misleading about features “needed” for our user case or make long-term promises they couldn’t possibly keep about features. standard salesmanship stuff but was very aggressive.
2) encouraged an integration style that would make migrating out of vault practically impossible, if not outrightly dangerous
3) continually rug pulled features we thought would be free forever (okta/mfa login being the biggest one I can think of). You can’t pass any serious compliance without that, and they realized anyone heavily relying on vault for secrets management would absolutely have to pay for this feature.
Basically it just seemed like hard core vendor lock in and every year our bill would be a lot higher for essentially the same or fewer features. Not to mention nonsensical pricing that even their own engineers can’t explain and changes constantly and arbitrarily.
So all this to say sorry this happened to you and for Vault specifically I am not surprised and would personally not rely on it for anything serious, even though I personally consider it fantastic software - I simply lost trust in hashicorp.
You should be using the OIDC login method most of the time for MFA, and not their built-in MFA.
I’m unsure if the equivalent software is worth the price when compared to Vault and not sure I can seriously suggest anything else even if I hate this new license.
You can use a mix of secrets manager and certificate manager products in AWS and accomplish essentially the same things Vault promises for much cheaper (and easier to manage).
I’m underselling of course the vast capabilities of vault. but most companies don’t need those advanced features, and they don’t really sell them, they sell and lock you into features that once you implement are going to become an extraodinary hurdle to migrate out of.
On the oidc - yes we were using okta as that. but at some point mid-contract the “okta” management features that connected to it became enterprise only, and we had reasoned that if we didnt need more advanced features (dr, replication) we could go back to OSS when we wanted. In fact that was even told to us, until that was no longer the case.
AWS Secrets Manager was so easy to setup. With implicit auth using IAM roles on our EC2s and the aws sdk I was able to add secrets support in literally a day for all our services.
Definitely appreciate your comment, so thank you. It means a lot.
I think fortunately, I'm not doing all that much with vault aside from initializing it, configuring k8s auth, writing some small policies depending on some inputs for the specific user, and then setting cert-manager up to use it. It's definitely one of the more simple projects to rip and replace.
But it's frustrating, for sure. I got some of my coolest code set up to unseal and initialize vault programmatically, and was hoping to eventually get it to a point where I'd be able to orchestrate that on a user's behalf without having control myself, via e2e crypto. Maybe with another CA project I could achieve the same thing. But yeah, looking at the new license file in the vault project, I'm not sure how well any of this would work out if my code was orchestrating it. And certs are pretty fundamental to the project.
From the article: “End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp.”
Literally nothing has changed, this isn’t disappointing, it’s smart, they’re protecting themselves against cloud providers that have repeatedly abused the goodwill of the open source community.
Maybe you missed my last sentence. I've been hacking on and off for a couple years on a side project I'd like to monetize, to capture some of my value add, while also giving back. (It's sorta "if you build it they will come" at this point tbh so I don't necessarily expect it to work). My project is sort of "OSS platform as a service" only I just deploy it for you and teach you to run it yourself, while jumping on a call occasionally if you need SRE for it, and continuing to iterate on tooling as well as make PRs to the tools as it makes sense. Vault and consul (as a vault backend only) are components I've used for that (via cert-manager so they're replaceable tbh) and I'm no longer sure if that's viable.
And generally as a contributor to the vault codebase, however small, I'm not thrilled they want to capture more value from it themselves while not offering me a miniscule chunk of that.
The whole cloud provider argument really feels a lot like Displaced Aggression. You're probably punishing the people smaller than you a lot more than you are the billion dollar cloud providers who can afford both expensive lawyers and can very easily afford to fork your codebases as we see with OpenSearch vs ElasticSearch.
If so, you can check out Infisical (https://github.com/Infisical/infisical) as an open source alternative to Vault. The absolute majority of our codebase is licensed under MIT and we have no intentions to change that.
I'll definitely check it out. That said, I'm starting to feel a lot more skeptical of the ability for even founders to manage stuff like this. I would say the same of my own OSS as a "founder," but if my company controls it in some way then I'm not sure there's a reasonable way for me to ensure that continues in perpetuity. At least not via a split model like a lot of these recent news stories have revolved around.
From what I've seen of Mitchell as well, at least in the past, I kind of doubt this is something he would have gone through with on his own.
I think the easiest way to manage it is essentially to do nothing. Accept open source contributions without a contributor license agreement and their copyright locks in future maintainers, yourself included. Extricating those contributions eventually becomes impossible without a cleanroom rewrite that is usually economically impractical and way too risky to a business with revenue.
This requires a copyleft license, and can be bypassed if all contributors agree to sign away their code to a company trying to relicense and monetize the code (as the Audacity contributors did for some reason).
But your contributions stopped being "your" contributions the moment you signed off on them being merged into the vault codebase. Why would they owe you anything when you already indicated you were cool with the fact that you didn't want anything in return by contributing?
This change protects the project from getting outright shut down because huge companies use it to extract value without some of that value going into guaranteeing the project stays supported. If you contributed to it, the minuscule chunk you get is "it keeps existing and you get to keep using it" instead of "this is not worth our time, we're sunsetting this".
I guess you can chalk that up to naivety on my part. I've always assumed there is a social contract on top of the CLA I probably signed, that the software I wrote would continue to be available and maintained via contributions from both the company and community. And since they very obviously benefit from a plethora of OSS themselves, including the language they've used to build their products and the platforms they undoubtedly run on.
I guess I'm always free to fork the codebase I care about under its current license and try to build a community around that. But I think we all know that's not as viable.
Anyway, I'll just be reconsidering my use of software open sourced by companies, I guess, regardless of how permissively it's licensed. The free lunches I thought we collectively agreed were awesome and ought to keep helping each other provide, are apparently ending as money gets tight.
Just because they have the legal right doesn't make it ethical, and even if someone makes the argument that it is ethical that doesn't change that it's a bit of a slap in the face to the open source community. You're allowed to be annoyed by this.
So, I don't understand -- had you known that this license change to prevent competitor use of their product, would you not have bothered to add the functionality you contributed?
No idea. I contributed 8ish years ago when vault was a significantly smaller project (it was 9mo old at the time) and IIRC there was nothing like hosted hashicorp back then. I just wanted to put into vault a CA keypair I used easyrsa to generate and that didn't work without a good deal more crypto plumbing, and I tried to make it a bit more futureproof while I was there. I had no real idea that 8 years down the road I would be tired of corpo life and tired of having to fight to contribute to OSS and might want to earn money in that sphere.
Today, absolutely. I would simply choose another piece of software to build on and contribute to. Or build my own if I thought something open enough and good enough didn't exist yet.
Seems like you missed the part where I literally typed "giving back." Or that I literally contributed part of the hashicorp codebase, specifically vault. And it's been hard continuing to do that at $DAYJOB consistently, so I've hacked on a side project in my spare time (also open sourcing plenty of useful tools during that hacking) as a means to the end of eventually finding ways to keep giving back directly and teaching others to do the same.
with all due respect, unless "giving back" means giving them money, its probably not worth what you think its worth. I maintain some small projects, and most of the people "giving back" contribute such a tiny amount of code that its almost not worth mentioning.
that might not be your situation, but I know as a maintainer, in most cases I would much prefer a monetary contribution than a pull request. edit, 2015, ouch:
Not sure what you're getting at with your edit. I'll try to assume positive intent.
I maintain quite a few projects as well, also pretty small. Code to me means a great deal more than a small amount of money. The money is nothing compared to what I've made in my career thanks almost entirely to the code that exists publicly and my ability to run and modify it as needed to learn. I am glad to get code because it tells me something is useful enough for someone else to bother, which to me is what giving back is all about.
> The money is nothing compared to what I've made in my career
right, but thats not the case for everyone. you have been fortunate, but for many they cant even pay their bills with the tiny donations that come in. hence why the need arises for a license like this. to force people to either go away, or pay up.
as you've noticed, its not ideal. in a perfect world I would license my code without restriction, but I need to pay rent like everyone else.
Imagine that someone see your open-source code and creates a competitor product by assimilating it...
Imagine that this entity is much bigger than you even...
People downvote but from a strategic point of view it makes no sense at all.
It's all good because usually open-source is an investment for bigger companies that they can recoup somewhere else.
But for small-players, it makes absolutely no sense to create a business and also make it easy for competitors to compete or even for competitors to appear.
But people probably realize that otherwise there wouldn't be so many debates.
Who funds open-source? (not talking about source-available but the most permissive Open-Source licenses)
Adding a non-compete clause to your license is not "literally nothing" - in fact, it might be extremely problematic for a large number of downstream users.
As for "abusing the goodwill of the open source community", that's kind of the point of FOSS. Free riding is not stealing. That's proprietary world logic, and everyone saying we need to stop people from free riding FOSS is calling for the enclosure of the commons.
Let me be perfectly clear: there is no license condition you can put on software that will let everyone use it as if it were in the commons but prevent Amazon Web Services from hosting it.
> Let me be perfectly clear: there is no license condition you can put on software that will let everyone use it as if it were in the commons but prevent Amazon Web Services from hosting it.
"The following licence is granted to everyone except the following entities: Amazon, Alphabet, Apple, Microsoft, Meta, Oracle"
"Today Amazon introduces the AWS Partnered Software Supplier Programm. Selected companies are invited to offer their products as deeply integrated AWS services.
The first announced Parter are: Not-at-all-amazon-for-hashicorp inc, Not-at-all-amazon-for-mariadb inc."
This is super disingenuous in a world where things like the GPL exist and any other license that prevents you from putting further restrictions on the combined product.
> they’re protecting themselves against cloud providers that have repeatedly abused the goodwill of the open source community
This seems a lot more likely to be targeting other startups that build on terraform like spacelift, env0, maybe pulumi (although I think they interface with providers directly, so this might not affect them as much), etc. And maybe there are similar companies for their other offerings, although I'm less familiar with those.
Absurd. Providing a managed instance of open source software that’s complicated to manage is fine. It’s not AWS’s fault that Elastic did a bad job of selling into AWS accounts. They should have worked on their value prop.
AWS customers like that there's one bill and one account. Who wants to deal with multiple vendors if they don't have to? It isn't a level playing field when Amazon offers a service.
Amazon could have chosen a cooperative, long-term, strategy and shared some revenue with the authors for some quid-pro-quo, and the world and Amazon, would be better for it. Instead, Amazon chose to cook the goose that lays the golden eggs, now they have to figure it out themselves, and whole ecosystems of services they could have hosted are running away from them.
The reason historically it hasn’t been a level playing field is because Amazon have:
- The ability to invent new infrastructure to suit a need. For example, multi legged ENIs that provide the EKS control plane are simply not available to others,
- The ability to integrate with IAM natively,
- The ability to build common network architectures without outrageous costs (traffic over peering links being a good example since that is what basically all vendors have to do).
This is overthinking it. For nearly every given service, Amazon can just slap together a managed version and it will be the easiest one for people to discover and use if they are already using AWS. It doesn't require any of that special sauce fanciness. Most of their managed offerings are mediocre also-ran versions of things, but they are just easier to use within the existing ecosystem, so they win.
What I find absurd is the perspective that it is 1. a giant no no breach of the spirit of open source software to provide software with open source code but a license that restricts commercial resale, and 2. it's totally great for megacorporations to reap the vast majority of the rewards that accrue to popular mature open source software services.
I honestly can't fathom this worldview or how so many people here seem to be so sure it is the one that makes sense.
If you win this battle for mindshare, people will just stop making open source services like these. Every service will just be fully closed source SaaS. Amazon can't just re-sell that no matter what, and people just crap on you if you make it open source (edit: re-reading this, should have said "source available" here), so why would anyone bother?
Increasingly people who make open source software services are damned if they do and damned if they don't, and if that is how it's gonna be, people are going to just stop bothering with it.
The huge difference is where the copyright of the code lays. OSS projects that require contributors to assign their copyright away, should not be trusted, and should not receive goodwill contributions to begin with. Otherwise, what today is Apache 2.0, tomorrow can become Commercial, while asking nobody for permission, because the maintainers have ownership of 100% of the code.
Not that OSS projects backed by commercial-driven entities usually receive any meaningful amount of contributions from external people... but still, an important detail to think about OSS.
It's super frustrating, because I want to assume the best, but I'm starting to agree more and more with this perspective as stuff like this makes me more cautious/cynical. Unless my CLA assigns copyright to a foundation, in which case I am more likely to believe it will be kept in line with the foundation's charter, e.g.
The rule is simple: If you want to relicense a project, then you need approval from all the individual copyright holders. It does not matter if you are relicensing between permissive OSS licenses such as, for example, from Apache 2.0 to MIT. They are different licenses, so you need permission for the change.
That's why OSS is commonly called a "Community". The software's copyright belongs to the hands of all the community of developers who have written and contributed code.
What a CLA usually does is grant perpetual permission to do anything with the code, including to relicense without asking. Practically speaking, CLAs grant full control to a single hand. Thus, OSS projects with such CLAs are not part of any so-called "Open Source Community" in any meaningful way.
EDIT: Changed "CLAs grant full ownership" -> "CLAs grant full control", to avoid misunderstandings.
> What a CLA usually does is grant perpetual permission to do anything with the code, including to relicense without asking. Practically speaking, CLAs grant full ownership to a single hand.
What CLAs do, is explained in the first half of the sentence. What it means in practice (in the context of talking about relicensing) is hence what "practically speaking" means.
Anyway I've edited it to avoid using the word "ownership", which might confuse the intended meaning.
I would much rather contribute to a project with a CLA and the possibility to be commercially licensed by the entity driving the work on the project. I'm not that interested in working for Amazon for free...
You can't have it both ways. You either believe in, and enthusiastically participate in the development of free software (the philosophy of which requires freedoms to be available on an equitable basis), or you don't.
I am not an ideologue (and I frankly struggle to understand why people find it appealing to be ideologues).
I just want there to be a lot of software made that is useful to me. Software is far more useful to me if I can read and modify its source code.
So my metric is just whether I think something will incentivize people to make more or less of that kind of software. I worry that people will make less and less software that runs as a service in this fashion, as it n becomes more and more obvious that the benefits of that software flow to giant integrated cloud platform providers rather than to the people who make the software.
Being a chump is not motivating, and I think that's the current incentive structure. So I like seeing people try different structures that seem to me like they structure the incentives better.
But you're totally right, philosophy has nothing to do with it for me.
> ... as it n becomes more and more obvious that the benefits of that software flow to giant integrated cloud platform providers rather than to the people who make the software.
The whole point of open source is that everybody has the opportunity to contribute to the benefit of everybody. You don't get to say "oh, but nazis / Amazon / rapists don't get to use this because I disagree with their morals".
The incentive to contribute comes from being part of a community that gets to experience better quality software. For many (me included), that's plenty. I really don't care what Amazon does - I'm neither a customer, nor an investor.
> Does assigning copyright with a CLA mean that I would not be free to, say, submit the same PR to more permissive fork as well as Hashicorp's vault?
A CLA, by definition, licenses rather than assigns copyright. A CAA assigns copyright. Typically, a CLA does not restrict the licensors right to license the same contribution elsewhere (if it is legally derivative of a project whose own license is restrictive, that may prevent it, however.)
It depends on the CLA, and there is often very little similarity between one CLA and another. On a technical note, CLAs don't usually assign copyright, they only grant a licence, but one which permits the recipient of the CLA to relicense the contribution whenever they choose to.
It definitely feels like the whole era of VC drying up is bringing out the worst possible future for some of these non GPL/similar licenses. Which is unfortunate for any of us who have deliberately learned only OSS and operations around it, giving back the whole time, with dreams of building services that leverage that knowledge someday as a chance to be our own boss while also utilizing and giving back to the OSS that got us this far.