This is great, Vault had a lot of community contributions blocked or stalled due to internal politics/roadmap stuff at HC. I think having a community fork will encourage folks to scratch itches that HC was reluctant to add into the product. I know I'd love to add blocking queries and maybe a TPM seal...
Additionally, the Vault plugin model is terrible IMO, I wonder if the fork could revisit how it works or add a better abstraction. Lifecycling plugins, especially with container deployments of Vault, is a nightmare.
TPM seal could be addressed with the PKCS#11 TPM bridge (which requires Vault Enterprise). But I'm curious what blocking queries are, as I've not heard of them before...
Elaboration on the pain points of plugin lifecycle would definitely be useful :-)
Sure, just opened two issues around the blocking queries and plugin interface. I'm not sure how adding Vault Enterprise features like HSM/PKCS#11 into OpenBao will work, could create some legal issues depending on how it's done.
Right, sorry, I wasn't implying that the community should or could add PKCS#11 support, just stating that while TPM support is nominally lacking from Vault Enterprise documentation, it is achievable today via PKCS#11 bridge. :-)
There's no overall consensus within engineering about the change itself.
What is amusing is that most of the public response has been aimed at Terraform whilst internally Terraform wasn't the concern. Gruntworks and the others were not mentioned internally.
Interesting. I'm curious, was it fear of IBM or was there a concrete threat from IBM which was already eating Hashicorp's lunch and was an existential threat?
I have a hard time imagining why anyone would choose IBM's offering over Hashicorp's offering unless they would already be up until their necks into IBM stuff. I also wouldn't really expect the IBM and Hashicorp customer base to overlap much?
IBM has lots of old enterprise mindshare. Existing relationships are the value. Selling Vault just becomes another line item in your IBM contract.
Very similar how AWS just repackages open source products and sells them themselves (Elastic). If you don’t protect yourself from these entrenched enterprise marketing machines, you’re dead.
(Brought Vault into an old, stodgy org, was a schlep)
There’s even a whole cottage business around getting your app on the AWS marketplace and handling billing through AWS. Once it’s on the marketplace it becomes much more appealing to a set of B2B customers because it’s way easier internally to just add some $X,000 line item to your AWS ‘cloud’ bill than to go though the lengthy procurement and approval process of onboarding a new vendor
“Application Modernization” is a huge deal in enterprise. In practice this means some combination of “make it slightly easier to get production traffic to new Java apps” and “deploy a lot of Kubernetes clusters.” Really they want the former but the k8s became a proxy for the capability. It’s why IBM bought RedHat.
Hashicorp products are a very big part of this world. I’d expect that basically every IBM customer also uses Hashicorp products, but they may or may not have a commercial relationship with Hashicorp.
How would you feel if your products were forked by a big business that had already been commercializing your open source code (legally, admittedly) while making no contributions back?
That’s smart today. But it was always my perception that up until a couple of years ago, when all this ElasticSearch v AWS drama began, that it was historically part of some kind of social contract in open source tooling to use permissive licenses. This was just my perception of consumers of open sourced tooling, so your mileage may vary. Very recently it seems there’s been a surge of people noting acceptance of less permissive licenses, and in this landscape I think it’s more likely that a young Hashicorp would have opted for a license that didn’t allow IBM to eat their lunch.
I'd be thrilled with this. This is free marketing to a much broader customer base than I could achieve. Some customers would circle back for more in-depth knowledge and support from the original author/company.
Take, for example, ElasticSearch. They got wider recognition after AWS started "shipping" ES as a service, but sadly, their investors thought they could compete with AWS.
Also, as others mentioned, you should consider a license in advance. And remember that many of these companies benefited from big companies: HashiCorp is getting golang, libraries, OS, and tooling for free, ES is getting JDK for free and etc.
Quick reminder that when HashiCorp chose Go, there were basically no libraries for it, and Mitchell’s libraries appear to this day in a lot of the more serious Go projects.
Not to question Mitchell's generous contributions, but most of his libraries I've seen were convenience wrappers and other creature comforts (eg. go-getter), not foundational work. Happy to be corrected.
By that measure, anything outside of assembly could be defined as “creature comforts” instead of foundational work. I understand why it would be convenient for you if it were true, though.
One of the complaints about Hashicorp products was that they were not accepting any/many contributions from outsiders. Not sure if that was the case with vault.
It’s generally proper etiquette to discuss a contribution with repository maintainers within an Issue before writing the code. That’s just people putting themselves in awkward situations, in my opinion.
The more mature a product company gets the more strict they start getting, too, out of necessity, for code standards and styles. Enforcing styles on community contributions is often a difficult balance between keeping consistency and seeming like a jerk. Sadly, people aren’t always as thoughtful with their contributions as you’d sometimes like them to be.
Anyway, I’m sure I’ll get some flack for saying this, but I help maintain some popular repositories and this has just been some of my observations. Especially with people not checking with the maintainers in an Issue before writing the code.
I find this so confusing... I would feel exactly as I felt when I was picking a license and imagining all the different scenarios my choice might lead to.
Fine, I guess, if the license I'd chosen allowed that? Certainly there are other licenses I could choose (licenses that still retain a good deal of openness) that would protect against that if that was a concern.
Hey HN, I'm involved with this project, glad you found it interesting! Keep in mind it's still a _very_ early stage and not in a usable state. A lot of work in progress but also plenty of opportunities if you want to contribute.
What smells funny is hashicorp pretending to be open source to win market and mind share, and then doing a rug pull. Everything that follows is a reaction to that.
The license change is the very definition of "rugpull":
Use permissive license, build up a community of open source users and people who use your product because of its open code base.
Once it stops suiting your business desires, revoke that permissive license, and switch to one that excludes a (significant) portion of your code's user base.
I wrote a PR to fix something in Vault, then nothing happened for a while, then I saw that hashicorp is changing their licensing, and soon after that, my fix was merged. My fix sat waiting until they changed their license, and then it was merged before I had time to consider if I wanted to contribute under that license.
(Incidentally, sentry also changed their license soon after I interacted with the project. Maybe it's me ruining the OSS world)
So, we should check if OpenBAO is then..? I assume this means the assigned copyright holder is a trusted non-commercial body (Apache or Linux Foundation).
I saw a similar thing happen with another product recently. It made me realise even though the project was touting itself as open source you couldn't even build the open code into a useable product.
So the importance of assigning copyright to a suitable body crystallised for me.
The permissive license was not revoked. The license change is not retroactive. You can continue using the product under MPL license, up to the commit in which the license was changed.
But Hashicorp's business hasn't turned a profit to date. And they rarely merge external pull requests.
If the company maintained the previous ZIRP-era permissive license status quo and then eventually went bankrupt, wouldn't that be a worse outcome for everyone?
> But Hashicorp's business hasn't turned a profit to date. And they rarely merge external pull requests.
When they started out, they had enormous traction in the community because they were open source. People actively contributed to what they thought was an open ecosystem in a collaborative spirit. Without that, their products would just be another expensive, marginal proprietary piece of softwarewthat most people ignored.
Now they're trying to profit off that without reciprocating (their competence at being able actually show a profit is irrelevant).
> If the company maintained the previous ZIRP-era permissive license status quo and then eventually went bankrupt, wouldn't that be a worse outcome for everyone?
No. It'd be a worse outcome for Hashicorp's investors, sure, but the rest of us would have the code, the comunity, and a little less poison in the well.
> they had enormous traction in the community because they were open source.
People don't adopt software only because it is open source. It also has to be useful high-quality software. Attributing the entirety of their success to a permissive open source license is nonsensical.
> Now they're trying to profit off that without reciprocating
Their products are still free to use and you can still read the code. They continue to improve the products. In what way are they not reciprocating? And considering this is a publicly-traded for-profit enterprise, why shouldn't they be able to profit off their work?
Unless your business is directly competing with them, how does the license change directly affect you?
> the rest of us would have the code, the comunity, and a little less poison in the well
At the cost of losing the creator and primary contributor of these projects, which tends to be a death blow to the software's long-term viability!
> People don't adopt software only because it is open source. It also has to be useful high-quality software.
These things are symbiotic. It's a virtue circle. People find it useful, they contribute, other people then find it useful, it grows in popularity, people contribute etc. It's pretty clear that Hashicorp hoped to take advantage of this to build popularity when they open sourced their product code.
If you don't think this is true, why do you think they released it under an OSS license?
> In what way are they not reciprocating?
Reciprocating would mean allowing others to build businesses on software they have also contributed to.
> And considering this is a publicly-traded for-profit enterprise, why shouldn't they be able to profit off their work?
It's not all their own work.
No-one's saying it's not ok to profit from it, it's about screwing over and denying that right to others who built the product to what it is today.
> Unless your business is directly competing with them, how does the license change directly affect you?
The license is badly written, andtherefore risky for any business to use. For example, the word "competing" is not defined. If I build a system to store secrets in MySQL and put an API in front of it, am I competing with vault? What if I sell a managed database service and Oracle buys Hashicorp, am I now competing?
It's badly written on purpose, because Hashicorp don't want anyone (with $$ and a competent legal department) to take their silly license, they want to sell them a contract.
> At the cost of losing the creator and primary contributor of these projects, which tends to be a death blow to the software's long-term viability!
If it's useful high-quality software, history shows us that such projects continue to thrive regardless of the status of the 'creator' (e.g. Jenkins).
> If you don't think this is true, why do you think they released it under an OSS license?
I'm not familiar with Hashicorp's motivations for using a permissive license, and I believe this is tangential to the point being discussed (attributing Hashicorps' products success simply to being open source vs being useful software that solved problems in a novel way).
But I do know sometimes software is open-sourced (or at least made source-available) without accepting changes upstream at all, which clearly isn't done for reasons of wanting contributions. Or other times, authors will accept some outside contributions, but aren't outwardly seeking or encouraging them.
Nothing in any FOSS license requires the author to accept changes. Having the source be available is beneficial on its own for reasons of adoption and allowing users to trust the software.
> Reciprocating would mean allowing others to build businesses on software they have also contributed to.
Nothing prevents these companies from doing so via a fork of the last FOSS-licensed version, which is exactly what they've done, and is fine legally.
> It's not all their own work.
They own it. This is clear cut. It's copyrighted and has a CLA for third party contributions.
> it's about screwing over and denying that right to others
What "right" is that exactly, and what makes it a "right"? Legally you can't just make up "rights" based on feelings and assumptions.
Absolutely nothing in these permissive licenses requires future versions of the work to keep the same license.
> If it's useful high-quality software, history shows us that such projects continue to thrive regardless of the status of the 'creator' (e.g. Jenkins)
No, history shows it's quite a mixed bag, for example OpenSolaris/illumos has a minuscule amount of marketshare/mindshare compared to Solaris's heyday.
Also, Hashicorp very clearly created Vault, Terraform, etc and putting creator in quotes is a really gross way to minimize their clear achievement in designing useful and novel software that previously did not exist, and would not have existed if not for their efforts.
If OpenSSL was taken closed source, I'd still have access to the product under the previous open source license, but its utility would evaporate since it's a security product. I would have to migrate to something else, eventually.
>Does nobody else find it even slightly on-the-nose that the guy behind the TF fork just happens to also run a devops company himself?
Not even a little bit. Yours is a really strange take, in fact. Of course it's the DevOps ecosystem forking widely used OSS DevOps tools when those tools' owners decide to move to a non-OSS license.
>> Blatantly take someone else’s work
How does one "take" open source software?
>> mobilise the community by calling them hostile because of licensing
The license change caused that mobilization.
>> spin up a business to build on the community
>> make bank
Again, what a strange take. TF and Vault are tools. These businesses are selling stuff built with/for these tools, not the tools themselves.
> Now I’m not saying that what’s happened, but I am saying it sure does smell funny.
Honestly it reads a lot like you are casting aspersions for no discernible reason.
This seems to ignore the first part of the story, where Hashicorp builds up a community around an open source project and relicenses the project. OpenTofu and now OpenBao wouldn't have happened if Hashicorp didn't relicense in the first place.
You don’t think that the licence changes were intended exactly these scenarios? Because it sure seems to me that they were.
The vast majority of users were, and are, completely unaffected by the licence changes. You’re really only affected if you are selling TF services commercially.
Welcome to Open Source, where being actually open is a competitive advantage!
If you want users of your software to have the brightest future, you need to accept the fact that others can make money and services with your code. If you try to shut that down, people will fork the most recent version of your code that has an OSI compatible license.
Of course, they could have chosen a license like AGPL in the first place, which prohibits services with non-AGPL changes. But then, the product would have been less likely to have the viral growth that HC products enjoyed.
“The vast majority of users were, and are, completely unaffected by the licence changes.”
Only true if you believe that the new license is safe to use, and that HC can be trusted to stop with this change. The license they adopted isn’t well understood and if I were a corporate lawyer I’d be hesitant to approve it.
Defining “competitive” use is basically up to HC, so that makes the license real iffy.
They’ve poisoned the well for contributions going forward, so HC as an upstream is much less attractive now.
Just as Hashicorp should have understood that the license they chose allows people to use the code as they please, contributors should have understood that Hashicorp could change the license at any time.
If we decide that building companies on top of commercialized open source projects is moral, then we must agree that changing the license is too.
> Does nobody else find it even slightly on-the-nose that the guy behind the TF fork just happens to also run a devops company himself?
Needs way more context. You're basically asking if it's suspicious that a person with high interest in X invests in tools for X. No, it's not, unless there's something more to the story and the position is abused in some way.
I'd find it more suspicious if someone with no interest in DevOps/infra did it.
Even if it was what happened, it doesn't really matter.
Why do companies that pick open source licences get annoyed when someone else profits from their work?
I am all for open source, but it is a lot harder to profit from your own open source product when the bulk of the development cost is yours. It will be a lot easier for a third party to do so.
>people are mad that software isn't open source anymore
I really don't get these arguments that the businesses that supported OpenTofu "blatantly stole" Hashicorp's work, as if Terraform wasn't licensed under a permissive license
> as if Terraform wasn't licensed under a permissive license
It wasn't. MPL is a (relatively weak) copyleft license, not a permissive license. Also, forking under the original license (what OpenTofu did) in no way requires a permissive license anyway.
As far as I'm aware, Scalr is not directly participating in or precipitating the fork at this time [0]. This was started by groups working on OpenHorizon and EdgeX Foundary (two Linux Foundation projects under the LF Edge umbrella) which both use Vault internally and are offered by other organizations commercially. This made them incompatible with the BUSL (for both open source and commercial variants) which necessitated the fork.
Vagrant is a dev tool, it’s not mission critical no company will pay for it. Could see a community effort with Patreon. Basically, if it doesn’t deploy into production corporate won’t pay for it.
Well, lucky you, because now there's new management :-)
In all seriousness, you may want to open an issue <https://github.com/openbao/openbao/issues> as they have weighed in on a few threads here saying they're open to suggestions
Having implemented a reader for 1Password's "old" opvault format, I would imagine the threat model is not just searching, so it may be a heavy lift to coerce ~~Vault~~ OpenBao's mental model over into one that can be used as a consumer a password manager but I'll admit that would be pretty cool to unify vaultwarden and OpenBao into one stop shopping for all one's cryptographic needs
I might be a foolish dreamer, but I think a healthy community with a lot of 3rd party tools make a project even greater. Like git.
It also inspires confidence for new adopters. I was often wondering with vault "why are there so few 3rd party tools? Is almost nobody using vault or people just use their own private tools". I was afraid to "invest" by using a tool that I perceived as not being popular enough and maybe have a limited future (maybe just in the 3rd party tools area)
I went this route too for organisations in onepassword. It wasn't right, there was no way to create a password / secret only the recipient could see. The org admin can always take access through their admin rights. You can't deliver to a personal vault. If it's changed I'll look again but support couldn't understand why it wasn't acceptable. Especially when your looking at the unseal keys for vault.
Now maybe their goals don't align with the community, and/or they don't want to be in the maintainer business for such a project, but better than nothing
I’d definitely like this for nomad. We just started using it at work to manage running jobs on a heterogenous group of machines and it’s really a great product.
“This product is awesome and I’d using it to make money! Wouldn’t it be awful if the team behind it wasn’t paid because of dumb entitlement?”
Fixed that for you.
You’re right, Nomad is awesome, precisely because it has a way different governance model than Kubernetes and other similar products. It’s a cathedral, not a midden.
Given how much of a PITA Vault is, I think it's time for people to move on from it (especially that I'm hearing this is financed by IMB to keep their Vault competitor going).
If there's a security flaw present in the original and fork, how do you write a patch to the same bug without writing identical code? How do you avoid accidentally being influenced by Business Source License code, especially as devs start using LLMs that may ingest that code in their training data?
The scenario you present in the parent comment has echoes of https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America.... - if I recall correctly they did "clean room" re-implementations of the same public API surfaces which in some cases resulted in identical implementations.
To my understanding if some piece of code is the only / obvious way to solve a problem it's not an issue.
To use a trivial example there's only so many ways you can implement a sum contents of array function, I'd imagine for many security vulnerabilities it'll be similar - adding a bounds check or whatever isn't going to be problematic just because you weren't first.
Okay, nice. I didn't know there were identical implementations in that case, I just thought it was about the method signatures being identical (because that's necessary when it's API Compatible).
Additionally, the Vault plugin model is terrible IMO, I wonder if the fork could revisit how it works or add a better abstraction. Lifecycling plugins, especially with container deployments of Vault, is a nightmare.