HashiCorp Vault forked into OpenBAO
theregister.com
theregister.com
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.
https://github.com/openbao/openbao/issues/new
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 :-)
[0] - https://www.ibm.com/products/secrets-manager
Disclosure - I work for HashiCorp and IBM has been mentioned by name in relation to the license change.
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.
It was Vault. It was IBM.
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?
Because everyone know IBM and mostly only devs know about Hashicorp. There is that saying "No one ever got fired for buying IBM".
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)
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.
But your reasoning at the end was not my understanding.
That said, I have nothing but respect for my former colleagues there. Some of the best engineers have I worked with are still at Hashicorp. :-)
Disclaimer: Views my own, not that of any past, present, or future employer.
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.
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.
That is the main question before you pull the rug of the open source license once you start to be successful thanks to the community...
If you want to help out, you can :
Join Matrix rooms:
- https://chat.lfx.linuxfoundation.org/#/room/#openbao-announc...
- https://chat.lfx.linuxfoundation.org/#/room/#openbao-develop...
- https://chat.lfx.linuxfoundation.org/#/room/#openbao-general...
- https://chat.lfx.linuxfoundation.org/#/room/#openbao-questio...
- https://chat.lfx.linuxfoundation.org/#/room/#openbao-random:...
Join the mailing list: https://lists.lfedge.org/g/openbao
Oh interesting, I wonder who did it.
> co-founder and CEO of DevOps automation biz Scalr and one of the organizers of OpenTofu, a fork of Terraform
Yeah, alright then.
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?
> Blatantly take someone else’s work
> mobilise the community by calling them hostile because of licensing
> spin up a business to build on the community
> make bank
Now I’m not saying that what’s happened, but I am saying it sure does smell funny.
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.
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.
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.
Then, please, use it according to the license, and if you don't want to do it yourself, now you can pay either this guy or HC.
What's the problem?
Someone always has to pay for the development in the end.
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.
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?
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.
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!
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).
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.
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)
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.
Fixed it for ya.
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.
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.
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.
[0]: https://wiki.lfedge.org/display/OH/OpenBao+%28Hashicorp+Vaul...
>people use it under the license
>"you're literally taking my work"
>change license
>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
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.
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.
https://github.com/openbao/openbao
Sad to see Hashicorp going this way, they made a lot of great stuff.
Very early stage still.
For servers tools, maybe people wrote cool stuff at work but they are not published.
The biggest missing piece back then was lack of a search feature and the maintainers were not interested in implementing it.
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
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)
Feel free to ignore the Nix stuff, but I’ve outlined how I create entries with the 1Password CLI: https://github.com/heywoodlh/flakes/tree/main/kube#1password...
After a OnePasswordItem is created, a secret containing your fields and their values appears. It’s marvelous!
(Integrations like this are why I switched away from Bitwarden to 1Password)
IIRC HashiCorp was not interested in supporting these kinds of tools because they were in direct competition with the Vault enterprise offering.
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.
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
There are other great/better options. Check out Infisical for secret management: https://github.com/Infisical/infisical
Disclaimer: I'm one of the maintainers.
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.