> However, there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don’t believe this is in the spirit of open source.
This is 100% in the spirit of open source. If this is a problem for them, why not adopt an open source license that compels developers to open source their code instead, like the AGPL?
This is purely a way for HashiCorp to ensure they are the only ones who can commercialize these formerly open source projects. Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
The blog post is disingenuous. We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin.
Thankfully over time, they already pushed responsibility for most Terraform providers back onto their partners, so I'm hopeful the ecosystem of providers can still stay vibrant and open.
We are deep believers in open source---heck my last project at Microsoft was to take .NET open source and cross-platform, our CTO helped found TypeScript, and Pulumi is an Apache open source project---it seems HashiCorp no longer is.
The bald faced disingenuous nature of this change here is wild. They can't compete at their pricing because their pricing is absolutely insane over what the market can bear and they refuse to accept it.
They are going out of their way to make it less expensive to stop using terraform altogether right as so many new options have entered the market
OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.
I love the ethos of open source and have spoken at and helped run conferences, and had the pleasure of being paid to develop it - but the productivity I had when paid ten hours a day to work on OSS compared to whenever I get a chance between work family and everything else, well, it's better for everyone to get paid and release code, than not get paid and not write the code.
I see these semi-commercial licenses as the equivalent of a legal "just don't take the piss".
Would be interested in your side of the question. How do we keep on developing the code as well as keeping it open?
Not that I don't appreciate the effort. I'm sure what has been achieved involved a fair share of convincing too.
[1]: https://isdotnetopen.com/
Being in the Apache Foundation gives me all the assurance I need alone, though.
Pulumi being open source while Terraform is now proprietary cements that.
It sounds like a Terraform alternative, but looking at the website it doesn't really convey if it's a Terraform fork or ground-up re-write, or something else?
It's not comparable.
So without defending the change they -have- made, that doesn't seem like where you're going to run into problems as a result of said change.
Would this prevent you from integrating some modules such as AWS (I believe) from TF?
So much love for Pulumi from me, it’s an amazing product.
On top of that, whether or not an OSS project accepts your PR means nothing about its quality or utility.
This change appears to have very little or nothing to do with most of us engineers and everything to do with companies wrapping and reselling. As far as I’m concerned it’s a good change.
Anyone who’s thinking about it. Stay away from Pulumi unless you’re okay moving from declarative IAC to some bullshit imperative Python or node constructors and for loops, and everything else that comes with writing OOP. I don’t care about the Hashicorp brand. I care about writing quality IAC and Pulumi is not it.
High level, times have changed. Source should be (my two cents, ymmv) about a mutually beneficial partnership between builders and users, not “give it all away for free or you’re not legit.” Users get to understand and extend what they’re running (via source), while the project steward/maintainer/owner can continue to do so.
It is a balance to be maintained in tension, not an equilibrium to be reached.
That sounds like what the GP comment is saying. If someone said "turns out open source doesn't work for our business model" it's hard to argue with. If instead they talk about "evolving open source models" and whatnot, it feels like they want the best of both worlds. It's been happening a lot recently that companies pretend they are "open sourcing" something for the PR but really use a much more restrictive license.
https://fossa.com/blog/open-source-software-licenses-101-agp...
You're not free to decide your source available model is open source and reap the marketing benefits of open source without the costs.
I don't know enough about their operations to have good suggestions on how to become sustainable. But, I don't like this move. There are many sustainable open source companies. Moving to source available from open source will likely never be a move I like.
It isn't just the need to eat. There's also the issue of keeping investors happy and their continual drive to maintain growth or earnings at stratospheric levels.
Strict IP laws are the only safe way to do that, and that is why so much software has leveraged them over the years. The internet era felt like an aberration for a while, but things seem to be shifting back to high double digit margins as the only desirable goal.
Pragmatically I would rather bsl than closed source and I am more likely to use a product that is bsl, with reasonable transfer time and license, than a 100% closed source product.
I'd also much rather have "open source" with commercialization restrictions than closed source.
It's still in most people's best interest to contribute to these projects if they were before, or would have before. Many businesses(and this is where most of the contributions get funded from, let's be real) rely on these projects and have no intention of selling them or competing with HashiCorp services.
My big gripe with the BSL is when companies switch from a proper open source license to the BSL, sometimes they try to sell it as a positive development, which is BS. The HashiCorp announcement is better than some in this regard, worse than others. Claiming it's the "evolution" of open source is weird spin, of course.
I also feel like any company switching from open source to BSL puts a stench of death / desperation on them, and it makes me worry for their future. If they have to make OSS -> BSL switch today, what's the next user hostile change going to be? Will they even survive?
At least they admit it isn't open source in the FAQ and are calling it the community version instead of the open source version.
> On 29 November 2021, HashiCorp set terms for its IPO
...I'm starting to think I'm onto something. (I do welcome anecdata that either helps or hurts my hypothesis)
I firmly believe this is a fact too.
One place I recently worked, I joined as it was going public and it went downhill quickly. The friends I’d made there talked about the fun perks, holidays and benefits the company was known for. Over the space of less than a year most of the culture atrophied, people left in droves and there were exactly zero holidays or perks given out.
Their stock was down 60% only 3 short months after IPO.
I think this is just a struggle to turn what was once technical excellence into something that gives money. I haven't followed HashiCorp lately but was once a fan of some of their products. These days it seems things are slower over there. At least that's what it feels at a distance.
The opposite of open source isn't closed source, the opposite of open source is restrictive. You're not forced to refuse to let people see the source when you're not open source. You're not forced to eliminate everything that OSI-approved licenses must have if you're not OSI-approved. There are no OSI cops that bust proprietary vendors for using a subset of their characteristics.
Of course it would be better if it were Free software, but it would be better if all software were Free software. They're doing them.
edit: My objection comes when people pretend licenses are open source when they are not OSI-approved and couldn't be. HashiCorp is not claiming to have remained open source: they're now "source-available."
This seems too black and white. Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
For the most part, no, the main direct customer benefit comes from the absence of lock-in with regard to maintenance and services thar results from the absence of usage restrictions.
There's some potential indirect ecosystem benefit for customers from the somewhat lower friction for partners in some source-available-but-use-restricted situations, but otherwise for most customers its the same as any other proprietary license.
Open-source isn't a gospel, it's a religion to some but not the end of the story in terms of what humanity can come up with. God(s?) didn't stop at "closed or open source". We can find alternatives while aiming for ideals.
As I explained in an earlier thread, MongoDB tried using AGPL. AGPL is not a barrier for Amazon, they still will resell your product without contributing. MongoDB ended up using a variant of AGPL that is even stricter (requiring the entire tech stack to be under the same license) but is no longer considered FOSS. Until the attitude changes around what FOSS is, this will keep happening.
I don't think this is true.
It's no longer considered FOSS because it's no longer FOSS.
> Until the attitude changes around what FOSS is, this will keep happening.
That's a weird thing to say. You're happy with it happening, and everybody else using bad definitions won't change that.
Something is either FOSS or it's FOSS-washed crippleware riding the coattails of actual FOSS for $$$.
They need more open PRs? It's not like these contributions would necessarily be welcome.
All that it achieve is making sure noone can build a better product. Aka "yes our product is crap in a lot of places, but we don't want to fix it. Better extract licensing fees by locking you all with us".
The behaviour of dying companies. Which make sense. Their business model never worked.
Not just in the spirit but a fundamental tenant.
AGPL and other pseudo-FOSS are purist idealistic aspirations that are, in reality, self-sabotaging footguns.
No it's not!
It's allowed, but it's not in the spirit.
The spirit is everyone sharing.
It can be true at the same time that "mechanisms to force sharing are against the spirit" and "entities that don't share are against the spirit".
That is the spirit of Free Software (ie restricting users as little as possible) Open Source is much smaller in scope.
So restricting competitors is as much against the OS spirit as it is against the FS spirit.
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 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.
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.
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.
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.
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.
Uhm, yeah, something DID change: the license and terms. I don't understand what kind of argument this is.
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.
e.g. AWS -> Elasticsearch.
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.
To imply that a non-open-source license like the BUSL is part of such an evolution of "open source" models (commercial or otherwise) betrays either severe confusion or a deliberate attempt to mislead.
Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U....
> Pulumi is able to adapt any Terraform Provider for use with Pulumi, enabling management of any infrastructure supported by the Terraform Providers ecosystem using Pulumi programs.
If Pulumi - another open-source infra-as-code tool (that ain't even a fork of any Hashicorp product AFAICT) - is really the thing scaring Hashicorp away from open source, then that doesn't really do Hashicorp any favors here.
Pulumi made Hashicorp build Terraform CDK. Which is a great result.
And the only reason Hashicorp was able to build CDK quickly is because they built it on top of Amazon's open source Amazon CDK. Another competitor.
Just because nobody has tried yet doesn’t mean that it won’t ever happen. Companies are doing this precisely because companies like Amazon abuse FOSS licenses to stand up their own hosted versions of open source projects.
This is not an abuse of FOSS licenses. If developers have a problem with this, there are open source licenses that would make this use case less attractive for Amazon, like the AGPL.
That nobody has tried suggests paranoia at best.
> Companies are doing this precisely because companies like Amazon abuse FOSS licenses to stand up their own hosted versions of open source projects.
The AGPL exists and already fully addresses that.
Spacelift is a significantly better product than Terraform Cloud, and since they apparently can't compete on quality they're going with this instead.
I think they're being more honest than others in not saying that changing their license is not to remain "open source". It's evident they know the pushback they would get from calling this "open source".
Overall it seems like a loser move. Look what happened to Elasticsearch - to me and most others, ES no longer exists. I've happily moved on to OpenSearch and not looked back at poor kimchi. Due to their own actions, Elasticsearch is no longer relevant.
Will Hashicorp's move spur a similar effort to fork the last open-source license version of Terraform and other Hashicorp tools? What other choice is there when the creator gets petty and insecure, and goes hostile against the open source community that helped create it? Extremely disappointed with the Hashicorp leadership team. MitchellH and your little sidekick Armon Dadgar - you owe your community better than this.
I interviewed with Hashicorp back in 2016 and ended up turning down the job. I used to have a small amount of regret about this decision, but now that true colors have been revealed, I know I made the right call.
What's that saying about trust?
Trust takes years to build, seconds to break, and forever to repair.
It's surprising to learn that people I thought were so smart could turn out to be this dumb!
> Trust takes years to build, seconds to break, and forever to repair.
Don't agree with that. That's really aggressive man. Hashicorp has built some awesome stuff, and tried to make a business based on Open Source. They haven't broken any contracts or done anything immoral - it's their choice.
Now someone will fork it to "Terrafoam" or whatever and that'll be it. MitchellH's vision and expertise is no longer critical to the project.
> HashiCorp considers a competitive offering to be a product or service provided to users or customers outside of your organization that has significant overlap with the capabilities of HashiCorp’s commercial products or services.
So, consider there is no cost estimate service and you built a thing that got popular (https://github.com/infracost/infracost). Then after 2 years Terraform Cloud catches up. What happens? Are you out of business?
Yeah. It seems like the Apache/MIT route has been working “well” to support a suite of libraries. But for bigger “business-critical” full-on products, like databases etc, you see much more weird contortions, including making self-hosting difficult and feature-gating essentials. Better than closed source, but not ideal. I’ve been thinking for a while that licensing is likely the pragmatic way out. But it’s important that it’s broadly understood, fair and clear.
> […] a product or service provided to users or customers outside of your organization that has significant overlap
Ouch, judging by the language it seems like it’s (1) unclear and (2) the authority on that ambiguity leans in favor of the company, which paves the way for selective enforcement. “Don’t worry, we aren’t going to come after anyone” is not convincing when legal documents are being signed. Hoarding soft- or future powers is a huge red flag in contracts, imo.
What do others think about this license in particular?
"Then after 2 years Terraform Cloud catches up" Really good point, company scopes change.
> BSL provides a Change Date usually between one to four years in which the BSL license converts to a Change License that is open source, which can be GNU General Public License (GPL), GNU Affero General Public License (AGPL), Apache, etc.
So to me the most important question is what is the change license and how long does it take? If it's 1 year then it goes MPS 2.0: okay that's fine. But if it's much longer and more restrictive than it's a real about face and means the opensource version is really not workable as it's too far behind the head.
--- EDIT:
> 4 years, MPL 2.0
https://www.hashicorp.com/license-faq#What's-the-difference-...
4 years is basically "of historical interest" only especially when security is involved.
Four years, MPL2.0
This is hostile to end users, small people an companies, not just big megacorps wanting the "steal" the code and run it as a service. Be successful in running and using Hashicorp's software, and they decide to shut you down if you are deemed a competitor.
Like https://github.com/hashicorp/vault/blob/main/go.mod#L25
Yep open source is used as a marketing. I doubt they'd gain much adoption if it started with BSL at first place.
Adoption is one risk, https://github.com/hashicorp/terraform/graphs/contributors is an entirely different risk
At any moment for any reason they can declare that you your use or your business in some way competes with them and cut you off.
You have no recourse. They don't need to explain it. They can even add a product remotely like what you're building or misunderstand your product and you are screwed.
The BSL carries with it immense legal risk.
"We require our external contributors to sign a Contributor License Agreement ("CLA") in order to ensure that our projects remain licensed under Free and Open Source licenses such as MPL2 while allowing HashiCorp to build a sustainable business.
HashiCorp is committed to having a true Free and Open Source Software ("FOSS") license for our non-commercial software. A CLA enables HashiCorp to safely commercialize our products while keeping a standard FOSS license with all the rights that license grants to users: the ability to use the project in their own projects or businesses, to republish modified source, or to completely fork the project."
It's disappointing that the non-legal text on the page repeatedly suggested that signing a CLA would help keep HashiCorp projects open source when the actual text of the license agreement made no such claims.
Someone should try challenging the CLA when the pretext of it changes (their contributions being relicensed to non-FOSS). Most CLAs are very dry but HashiCorp may be in trouble with all the proclamations in theirs.
> You hereby grant to HashiCorp and to recipients of software distributed by HashiCorp 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 Your Contributions and such derivative works.
This pretty much covers anything they'd need. (I'm not a lawyer.)
Linux doesn't require a CLA for contributions. These open source cosplay clowns do.
We also use CockroachDB which uses BSL, but we're not providing a remotely competitive offering.
I'll likely continue to recommend HashiCorp products (Nomad, Consul, Terraform, and Packer) to anyone who asks my advice, but it's disappointing to hear this change.
We maintain a rudimentary SBOM for anyone curious: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
I’m the Nomad Eng Lead and while licensing is out of my control we have a lot of users in a similar position to you: not knowing what might someday could be construed competition. I can’t make any promises but will do whatever I can to give you confidence that Nomad is still the right tool for your job.
> I can’t make any promises...
really sums it all up in light of these big changes, and simply put the big picture (aka licensing) is what people build and bet their professional lives on.
Problem is with the license not the tool. It’s nice that you’re trying to do what you can, but it’s like trying to sell roof insurance to a homeless person.
I think we've seen time and time again large enterprises abusing the spirit of open source for their own monetary gain, contributing nothing back, and just acting in bad faith.
One should always read software licenses before installing a dependency, regardless of how a particular project is marketed. This would still be necessary even if companies weren’t using the term “open source” to refer to this type of license.
People make it sound like companies are out to confuse you by calling it “open source”. If you’re the kind of developer that blindly uses a piece of software because someone claimed it was open source without doing due diligence on how it can be legally used, then you deserve whatever consequences may arise.
License technicalities don't matter. If people use permissive licenses as an excuse to justify an ecosystem that is parasitic any such system will die out, it cannot sustain itself.
For many, the spirit of open source is to allow it to be used in any way, commercially or otherwise. I don't consider it acting in bad faith at all to use what's out there and made available, and I am happy to give things away as in beer. Otherwise it's not open source (which is also fine, not all software has to be open source).
To abuse the spirit of open source, make arbitrary rules about its use.
Well, by definition they wouldn't be open source projects then. But yes, better to make that clear from the start.
i strongly appreciate the FAQ but this part felt weak/not the whole truth. What is not being said? who is hashicorp afraid of? there wasnt a doubt in my mind before and now there is.
indeed i just saw a startup demo today show off a feature that they admitted was just Vault in a wrapper (they even called their thing Vault haha) and that was it, but i would not have thought Hashicorp would mind them at all (its a very new startup)
What about all the cloud providers with their own Vault offering, which is likely just Hashicorp's FOSS Vault with lipstick and other bells/whistles?
People are paying good money for Secrets Management, and probably not to HashiCorp (directly or indirectly). If your cloud provider offers a turn-key solution and it's priced right, why would you bother with an external 3rd party?
HashiCorp recently rolled out a "Free Tier" to their HCP service[1]. They're clearly trying to get more people to use their first-party services.
> Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license. Commercial licensing terms are available and can enable use cases beyond the BSL limitations.
Looks to me very similar to (A)GPL + commercial dual licensing, for instance.
it's obvious that for a company (money-making entity), that they're going to want to have a monopoly in providing the software aaS. That's the monetization strategy on otherwise free software.
I don't think this is surprising. We saw this years ago with AWS and MongoDB. Yes, a startup can offer Vault cheaper since they don't have to pay for developers to build the software, and, in fact, they get to offshore their support costs to the developing company too ("yay" OSS).
I don't like it, but for a corporation that is trying to develop OSS, it makes perfect sense.
- Software made by startups that are precious to HN. In this case, building a business on top of them is "freeloading" and it's deeply immoral. Examples: Elastic, HashiCorp, Mongo
- "Public good software", there's nothing wrong with profiting from it, in fact, it's encouraged. Examples: Linux, Postgres, Nginx, Apache
Like service discovery and better load balancing algorithms.
The "Public good software" you refer to is much better represented by things like Capital One's Cloud Custodian, or the massive number of software libraries in NPM, PYPI, and all over GitHub.
> Software made by startups that are precious to HN. In this case, building a business on top of them is "freeloading" and it's deeply immoral. Examples: Elastic, HashiCorp, Mongo
I don't believe it's nearly as cut and dry as this post claims. The companies who are "freeloading" are usually undertaking massive efforts to be able to run the software in a very different environment than it was originally designed for. Building a hosting solution like AWS, with the high availability solutions they offer, is an incredibly complex problem, and they're adding significant value on top of the original software. Without solutions like DocumentDB and OpenSearch, many companies would not be able to build the solutions that they have built with AWS. Additionally, if we take this stance, are these companies not "freeloading" on the open source contributors' efforts?
One could argue that cloud providers' contributions to upstream could be more significant, but how much of what AWS has developed would be useful to anyone who isn't running at their scale, and using the same solutions for the physical layer?
I see two real problems, here:
* A lack of foresight on the part of the companies who originally built their businesses based on software with overly permissive license (Elastic is probably a good example, as they decided to pivot to SaaS _after_ they built a company on the premise of open source software). If they wanted to control other peoples' use of the software to the extend that they are complaining about now, they should not have chosen MIT/MPL/BSD/Apache licenses.
* Changes in leadership which result in a major change in business model which is no-longer in line with the original goals of the companies (I believe HC probably falls in with this bunch). In this case, the new leadership has effectively "bought" something without doing their due diligence. They thought they had all of the keys to the kingdom, but they didn't understand that what they were buying.
Think how difficult it is to get most companies to listen to your needs, much less ship what you need, versus being able to contribute your own pull request and have it merged.
Why should this mean the source owner deserves any less of a product revenue than the company that won't let you add your own features? It shouldn't.
If you get your feature merged at the long end of a customer relationship / product manager interaction, do you expect that means you should get paid for your feature request or get to keep it? If you write the spec for your feature in code instead of a PowerPoint or Word doc, so it does what you need exactly right, you're still asking them to ship a feature you need, just better specified and delivered sooner. It lowers the overhead both firms waste, which lowers your licensing cost and your cost of delay.
From the viewpoint of a CTO of a mega enterprise -- a vendor that lets me make things work is worth more per month to me than a vendor that won't, and no, I don't expect my enterprise get paid for the vendor accepting the fix that scratches my particular itch.
I think what you say is factually correct, but maybe misrepresents the situation a bit.
The license automatically converts to full open-source after 4 years. Maybe this isn't ideal, but it isn't "big company takes your code and locks it away forever" either.
Aside from that, there's still value in contributing to a product you're consuming at your day job: not having to maintain forks. If you can get your feature into the upstream project, less work for you in the long run, it's a win win.
Should you contribute to corporate owned projects in your free time for the fun of it? Probably not, unless you think it will earn you some kind of recognition (resume fodder).
Currently moving from Traefik to APISIX.
Moving away from the easy-to-predict flat rate Team pricing and to a new model based on number of managed resources ($0.000004 per resource per month or something like that) was just wacky…
… and now this “you can’t make money from the software you helped write” BS.
1. The article doesn't link to the actual text of the BSL in use. Link it please!
2. In my understanding, all BSL 1.1 are different, and differ by 2 factors: Additional Use Grant and Change Date. Those are both reasonable ideas but I wish they went a step further and the license would be formatted like Creative Comons. That one also provides versions that differ from use to use but you can instantly tell from the title which version is applied. I wish there was an official "BSL 1.1 4year non-compete" name for this with a good general definition of "non-compete" (and a few other common commercial uses to be granted).
As much as I love open-souce, I get the point that there are a bunch of freeloaders using stuff and not contributing back.
Full disclosure, I'm a shitty open source contributor, but I have some projects on github that I know others have gotten use from, and that makes me happy, not concerned someone is "freeloading".
Ideally your moneymaker can compete on its own without being dependent upon gatekeeping how the open source part is used. But with project ownership means you can change the rules for your competitors, but it's also a sign that you fear your offering is not competitive enough without the rule change.
On the other hand, many contributions(PRs) that hashicorp got (for free) are now relicensed to a different license. Who's actually the freeloader here?
Have you ever looked at the number of unreviewed PRs on Hashicorp projects?
Freeloaders like HashiCorp using other people's compilers and libraries?
There are a few realistic paths forward from here, to be confirmed when Hashi releases the full license they intend to use.
1. The Terraform community is large and talented, and we care intensely about open source. There will be a fork that remains open, and I'm hoping we can get all the commercial vendors and interested parties to be joint custodians of it. Like joeduffy says, their arguments are disingenuous, and their taking down of previous videos on their open source philosophy is too.
2. There is likely a Bring-Your-Own Terraform path, letting users supply their own Terraform for executing their code, and a commercial ecosystem that dispatches code and processes response with their own secret sauce. Just like you'd do with GitHub Actions.
3. Meanwhile, Terraform up to 1.5.5 is still open source, it's still amazing, and can still be used with the dozens of commercial tools out there.
I'm obviously very biased, but take a look at Infisical as an open source alternative to Vault: https://github.com/Infisical/infisical (we run under MIT + some enterprise features).
I've seen one quote when we wanted to buy Vault Enterprise for peace of mind (we did not need namespaces), and well, it was completely out of reach. Moon prices. No wonder people turn to someone else hosting these products for them.
Business Source License 1.1 - BUSL-1.1 [1]
Sure, it's hard to make money in open source. I spent 20 years doing it. It ain't easy.
But here's the thing: open source also helps you accelerate a business you might not otherwise be able to build. You get market validation by giving away a free thing, and then you hope to be able to collect some revenue on the backend once you've got a large enough user base, a proven product, and maybe even some contributors. Maybe even a whole ecosystem. You think VCs would have thrown all that money at a thing with no users?
Want to throw it all out? Fine. That's your right. But it's not gonna stop companies from forking the last open source licensed codebase and taking your cookies.
Open core is a thing. You can be good at it, and users understand and respect it. You would think that Mitchell would have learned after his failure to monetize Packer that he needed an actual proprietary value prop to build around before he built Hashi. Guess not.
You can't have it both ways.
Open source implies a model of collaboration between different organizations. A single vendor, even with an OSI license, does not an open source project make. And we have only ourselves to blame. Most companies can’t spare their developers for open source development - it’s time consuming and frankly open source is the outlier in how we think about code ownership and development. It’s hard to be a good steward. It’s hard to pitch the upside of such an abstract investment. In the end, actually want vendors, strongly opinionated solutions, managed by a single entity, but vendors we hire to let us treat their code as open and extensible.
I wonder if this era of single-vendor “open source” will be looked at not because it redefined open source but because it changes how we think about vendors, expecting certain types of code access and transparency.
Copyright assignments are put in place for exactly this (allowing a single entity to relicense the whole codebase unilaterally based on their own interests), and we should maybe come up with a better term than "open source" for projects in this situation.
It always feels scummy having to assign copyright for my own contributions to a big company.
So, no, I don’t see a CLA for an otherwise open source project transforming it into something other than open source.
And, if it did, we’d have to have a serious conversation about the “or any later version” clause of the GPL and how it makes all software using it not open source.
"Open source" has a clear meaning: the source code is open.
It does not imply that the source is free to see, free to modify or free to fork.
I'm pro open source, but I also have no problem that said source is not copyable, redistributable, etc.
To me open source is about _knowledge_ of how something is done. Period.
For the next two years, HashiCorp provided virtually no enhancements to TFC except cosmetic changes. I submitted feature requests for small and large challenges. Sometimes I was even met with argument. Meanwhile, several competing services were born, likely out of necessity of their own founders. Ultimately I had to switch and about halfway out the TFC door they announced their bizarre pricing model changes.
HashiCorp had years and years to build a quality commercial product on top of Terraform but squandered the opportunity.
At first this reminded me of the Docker arc but it may be more like Chef.
IMO they should just avoid open-sourcing the cloud platform if they want to sell it.
Also, why not just have gone with GPL since the beginning to at least benefit from the repackaging too?
Contributors should consider it as a red flag when a project isn't willing to accept inbound contributions under the same terms as they grant to others.
I wonder if whatever MPL 2.0-licensed contributions were made less than 4 years ago.
To be honest I'm not a huge fan of the wringing about the OSI definition, but it exists for a reason. This whole article is just another example of corporate gaslighting. If you don't define this and prevent that definition from being acquired, you're going to keep having CEOs define open source on how they 'feel', and you won't have the 'spirit' of open source at all.
I mean it's literally the BS License. You really can't even make that up.
There's a pattern here that, person builds an open source product, gets corporate sponsoring, funds a company, then suddenly the open source product steers away from open source because it's upsetting the corporate sponsors.
If you're so bothered by others using your work and not giving back (something that is ENTIRELY allowed by FL/OSS licenses), why make it open in the first place?
It kinda passes the image that these companies want to benefit from free work, but the moment someone uses their product for free and doesn't give back, it's just a nuisance for them.
as always, the hobbyist linux hacker is the problem (/s)
On an unrelated note, I've always loathed their antagonistic approach to users and hope their company dies so the industry can standardize on less crappy cloud configuration management tool. But unfortunately incumbents take a very long time to defeat.
Hopefully they all get forked (or existing forks take off), and it is just a matter of the community converging on the winner that we all use in the future.
That CLA grants HashiCorp full license over your Copyright, and explicitly allows them to sublicense your contributions[1]. Drew Devault's blog posts[2][3] on this topic are extremely relevant.
[1] > Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to HashiCorp and to recipients of software distributed by HashiCorp 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 Your Contributions and such derivative works.
[2] https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
[3] https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html
Specifically the part in FAQ which says "internal production use is fine", but then license says that "non-production use only" and then "You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.".
IANAL, but even to me this statement is full loopholes. WHO do we consider 3rd party? WHAT do we consider "hosted or embedded basis"? WHEN do we consider it "competitive with Hashicorps products"?
Looks like it stays k8s + pulumi + ansible for me.
I do think they’ll be able to benefit from this though — serious businesses that derive value from their offerings should be comfortable paying more/something for the value they’re receiving.
"Open Source" software always have been loved by companies because it provided extreme flexibility (closed forks, forks for customers, secret sauce addition, etc.), plus announced the message that their code is free for all, given there's no warranties.
These companies have skipped more nuanced licenses such as Apache, MPL, EPL even GPL in some cases, trusting that every actor in the software landscape is rational and ethical.
The idea was nice, but it involved humans.
After a couple high caliber forks, HashiCorp indeed felt the pain, and reflexively they moved to BSL.
What they forgot is their initial license has been designed to allow this in the first place. MIT/BSD/Expat is not suitable for monolithic code bases of this size, but people won't listen.
On the other hand, the code is HashiCorp's. They can do whatever they want with the code they write and put out there. They decided to change the terms they share their license, and nobody can say anything about it.
Is it ethical? No. Were the forks were ethical? Depends on motivation.
These things happen when you choose a license without much consideration for the future.
Maybe we shouldn't abuse Open Source software this much and embrace "Free Software" more, but this is just me.
So, at the end, "market forces" abused HashiCorp and, HashiCorp reacted. This is a normal impact/response event. Nothing extraordinary.
Edit: While one may argue that this is also similar with RedHat/IBM, The impact of the change, the number of broken promises, ecosystem dynamics and the motivation behind it make it different, yet I don't want to double the size of this comment.
Vendors like Hashicorp, that take advantage of contributors who give away their work(PRs) under the MPL, only to then have this work relicensed to a different license?
Hashicorp could just request the source code from those "vendors" (after all, the MPL has copyleft) and integrate their changes. (They have to be users first but this shouldn't be that big of a problem).
I wonder who the freeloader really is. CLAs should not be accepted. Ever.
1. Build a nice product, scream open source everywhere. 2. Get users to buy in on all the niceties, perhaps even nice contributions in terms of integrations and such(that people probably would not have cared for if it was some niche closed source product with much fewer users) 3. Once they are established enough, and people have gotten used to the learning curve, change the license and try to lock in as many users as they can and ignore the loud few who scream foul.
Some other product comes out to fill the void and they do the same as above..
https://github.com/hashicorp/vagrant/blob/main/LICENSE
Looks like it converts to the Mozilla Public License after four years:
> Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.
Open source seems to be evolving from being truly open source to being a variant with financially driven contingencies. HashiCorp have created great OSS over the years and am grateful for it. I understand their intention behind this move, but having a financially driven motive drive their OSS is not a good thing. I'd rather they not open source any of their code than put such limitations on it with these licenses.
One of my weekend projects https://tfstate.com is intended to aid with statefile configuration drift detection. Which (I've since discovered) is also something that Hashicorp offers as a service.
I feel worried.
1. Under the hood, it runs the terraform binary.
2. Receives API calls from the terraform binary.
3. Uses a modicum of code from the terraform cloud SDK.
I think I've answered my own question with (1), which may constitute "hosting" or "embedding" a Hashicorp product.
> To release and publish the HashiCups provider to the Terraform Registry, you must publicly host the source code in a GitHub repository you own.
without the FOSS part. Do you have a different link?
I know of at least one massive global company using vault in production, for free as a backend to their own password manager frontend.
My own $dayjob was just going to set it up actually, I guess we'll have to re-evaluate that now.
I can't even imagine how many companies use vault in production.
Using it as a backend for a password manager... more of a grey area, but Hashicorp doesn't offer a password manager.
They've all used Terraform extensively but always rolled their own means of deploying IaC, with solutions more clunky than CloudFormation which let's face it isn't brilliant.
Why did Hashicorp fail to win this business? I think their pricing just seems too outlandish and is based on paying for the value of software they've already open sourced rather than being tied to the cost of providing a good service plus reasonable margin.
Their strategy appears to have failed, exacerbated by the macroeconomic landscape. I doubt their chosen solution - Microsoftification of their open source project - is going to do them any favours.
Maybe the new effort is going into AWS native provider but I really doubt the default AWS provider is getting enough attention.
The "Licensed Work" parameter should refer to what they are licensing. Right now it reads "The Licensed Work is (c) 2023 HashiCorp, Inc."
I don't see how a corporation itself is copyrightable content to which a license may be granted.
Having your use of something important hinge on this one awkward sentence seems kind of scary. It's unclear to me whether, if you use (say) terraform for production infra, and someday HashiCorp releases a new product competitive with yours or merges with your competitor, your use of TF is then in violation of the license. "Offering the Work" is not defined and seems like it could be interpreted in different ways.
https://github.com/hashicorp/terraform/blob/main/LICENSE#L8-...
I feel especially privileged to have lead the Heroku Add-ons/Ecosystem team at a pretty pivotal time in devtools history. There was a sudden emergence of people/companies inventing entirely new things (e.g., databases, logging systems, telemetry, etc.) and so much of it was OSS. The overwhelming majority of these companies took the approach of "we'll make this thing free and successful, and we'll build a business off the back of enterprise support contracts and maybe some feature discrimination in a private 'enterprise' version" (e.g., clustering/HA support). I think in part it was because back then the only open source success story anybody had as a reference was RedHat, and cloud adoption wasn't as ubiquitous as it is today. Certainly not in the enterprise segment. So in the vacuum that was left emerged a whole industry of smaller startups that would provide said technology as a managed service. Go check out the Heroku Add-ons Marketplace circa 2012-2015 to see what I mean. Belatedly the creators of these technologies realised the enterprise support contract business was a terrible business to be in, and realised managed services was where they should have been all along. Absolutely none of these companies had any problem muscling in on the ecosystem of managed providers that had contributed to their success in a meaningful way. Some of the startups got acquisition offers on pretty lowball terms, others were essentially forced to accept partner terms that were so onerous it was doubtful they could ever turn what they'd built into a successful high growth business now. Many saw the writing on the wall and found an exit at a larger cloud/platform company that could roll them into their broader product portfolio.
Fast-forward a few years and AWS starts offering some of these technologies as a managed offering (disclaimer: I later worked at AWS for a couple of years). Suddenly these same companies don't like having similar market pressure exerted on them, and so begins the slow trend of license changing away from APL/MIT/whatever towards something that is trying to neutralise a legitimate competitor. Rules for thee, not rules for me.
My time at AWS gave me some new perspective on this whole sorry saga though, some things I'd observed but couldn't quite articulate why it didn't feel right. AWS taught me that at a certain level of scale almost everything ultimately becomes a logistics challenge. Trying to ensure that the infrastructure that's supporting tens of thousands of customers globally is constantly running, highly available, able to support the continued growth, etc.? It's as much a problem of capacity planning and co-ordination as one of software. And the more successful you get the less the problem becomes the specific nuances of running a given OSS product and the more it skews towards just knowing how to coordinate millions of anything.
What this surfaced for me is that in the vast majority of cases that I was personally familiar with, the companies in question barely used their own products. I don't mean in way that suggests they didn't believe in their value. It's just that their day-to-day needs of building said product very rarely intersected with the need to be the most sophisticated user of said product. They had very limited experience at operating it at scale, they all had customers (or managed service partners) who had orders of magnitude more experience about the realities of operating it. And high on their own hubris they'd decided that because they'd invented the technology they were now suddenly expected to be the world leaders at running it. They weren't. And they were never going to be, because the moment you hit that inflection point of success AWS/Microsoft/Google/so many others are better at running software than you are... and a license isn't going to change that reality. The "we'll run this for you" is just a bad business to be in.
A better business is "we'll provide you a UX and workflow and features _on top_ of that thing that makes it even better". There's a whole industry of companies who exist solely to make your AWS bill comprehensible, because AWS are organisationally incapable of providing good UX for most things. In it's most reductive and cynical take Heroku is "just" a UX on top of the core AWS commodities, one that has been largely unchanged for 5-10 years depending on who you want to ask (the slow decline there is a whole separate topic).
Which is why I was excited to take on a product leadership role at HashiCorp to help launch Terraform Cloud a few years ago (I left last year). Here you had an OSS product with a big community, and a set of features and capabilities that extended that to try and make it even better. Especially in situations where you're having to work with other people or across multiple teams. The fact that Spacelift, Scala, Harness, Pulumi, Terrateam, etc. existed didn't bother me much. If they copied what we were doing it was often good validation, if we lost a customer to them it was a good data point for things we were lacking or needed to fix, in some cases they just had wildly different takes on fundamental things which were a great reason for some self-reflection and to question why our conviction on a different way was so strong... were we right? How did we know?
OSS is good for so many reasons, but as a product person one of the things I loved most was the way it could help shape what the product could be in the future. Because of the ecosystem that erupts around it. You've already got such a huge advantage as the steward of the project, the most recognised brand in the ecosystem you created, the brand recognition in an enterprise conversation, and so with all of that head start I felt like we should just win on our merits. And if you can't win given all of that advantage then maybe you don't deserve to.
This only affects people who are directly competing with hashicorp using hashicorps code. That sounds like a reasonable thing to want to prohibit.
Why should hashicorp have to spend tens of millions on product development only for a competitor to spend zero but be able to offer the same product? That sounds like a net negative for the whole industry as it disincentivizes R&D
More here: https://www.weave.works/blog/statement-for-terraform-hashico...
Companies want it for free, and individuals don't have enough luxury time to be able to do it themselves.
Prove me wrong and help patch or fund https://github.com/purpleidea/mgmt/ and you'll have an even better replacement for terraform!
It’s a good question. I suspect several forks might be happening as we speak.
Microsoft does it too but they don't pretend to care about software freedoms.
I've been tempted to try and put together a terraform cloud alternative myself - whilst I enjoy using it, the pricing is pretty expensive if you have many state files.
There's a license that actively prevents this. It's called the GNU GPL.
Has anyone here identified any forks that predate the license change?
Not everything has to be _free_. The major benefit of OSS for many is that you can read the source code. The major benefit of paid SaaS is that things just work and you pay for that. BSL can be the perfect combination of these.
The main issue I have with the BSL is opensource-washing were companies basically release an open source product which become popular because it is open source, and then do a bait-and-switch and relicense it under the BSL restrictive license, but still claim "it is open source" which is a lie.
The anger is at a company that trades on the benefits of open source, and then shuts that down when it becomes inconvenient. People think they're free-loading on the contributions of others.
Anything before the change is still MPL and can be forked and built on top of freely.
Does anyone know of a similar tool?
I'm interested only in the ability to manage environment variables with a web UI, and have processes restart gracefully on change, everything else consul provides is not of use to me.
Any suggestions?
You'll end up writing some glue code.
I guess the signal here is they care more about and have pivoted business-wise to their own hosted offerings. I admit I'm not entirely sure what those are. I don't anyone that uses Terraform Cloud, but I guess someone must. So I guess Consul, Nomad, and Vault, but again, does anyone use the hosted versions of these? The big sell to me has always been all of their products can be self-hosted. Professionally, my use has mostly been with defense and intelligence customers offering behind an air gap who couldn't use the cloud offerings if they wanted to.
By far the biggest value add has always seemed to be Vault. Consul and Nomad have very clear competitors that still command more mindspace, but Vault seems to reign supreme if you want to self-host a secrets manager. On this front, though, as great of a product as it is, how much of that is even due to Hashicorp itself? The security is provided by implementations of open encryption algorithms, Shamir secret sharing, fips modules in the OS, and HSM support, but they don't make the HSMs. HA is provided by the Raft implementation of the Paxos family of consensus voting, but again, they didn't invent that. The fact this product exists at all is because they stood on the shoulders of giants who did all the heavy lifting in creating these secure and robust algorithms in the first place, and then shared them and allowed others to build commercial offerings on top of them. Your entire company exists because of other people's open source efforts, and then you close off and say no one else can build on top of your work, when if the OGs had done that, your product would never have been a viable business.
Employee A: But what about the community?
Employee B: ..Aaand it's gone!
You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.
But similar to the GitLab Sentry backend API (e.g. https://gitlab.com/gitlab-org/gitlab/-/blob/v15.0.0-ee/lib/a... ) the Terraform state endpoints are also in Rails, just like all the rest of the Internet facing GitLab API: https://gitlab.com/gitlab-org/gitlab/-/blob/v15.0.0-ee/lib/a...
as an additional "FWIW," the TF docs even claim they welcome alternative implementations of registry.terraform.io although I'm guessing one quick git commit and that language could disappear, too: https://github.com/hashicorp/terraform-docs-common/blob/e4cc...
I actually went to look that up because "who, exactly, are they envisioning making a hosted copy of Vagrant?!" FFS
I hope these contributors yank their PRs https://github.com/hashicorp/vagrant/pulls