Hashicorp switched Terraform from MPL to BSL yesterday. Many other companies did that in the past to prevent others taking their code and charging for running it as a managed service (eg Mongo, Elastic). With Hashi however, the server-side part was never open-source to start with. There was no such thing as "open-source Terraform Server". And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license.
Funny enough, our own product (Digger, an open-source CI runner for Terraform) is not using Terraform (or any other Hashicorp's code) under the hood. So this change probably hits other TACOS (Spacelift, Env0) much harder than us. But with the recent pricing changes and now the license there is no guarantee that Hashicorp won't make another move in the future that would one way or another hurt us. So if there was an MPL fork, we'd rather swith to that, just to stay on the safe side. And since there isn't one yet, we thought why not make one?
The Terraform language should not be impacted by the license change any more than the GCC license impacts code it compiles (for example). I'd love to hear any assertions to the contrary.
Yeah apologies we're in a little bubble here together with Spacelift, Scale, Env0 and Atlantis so starting to assume everyone knows the niche terminology lol
Yeah so basically TACOS are ci-like tools / control planes for Terraform. The OG one being Terraform Cloud.
I don’t think they were running terraform, they were converting terraform code to Pulumi code as a way to bootstrap their supported services/clouds/etc.
The TF bridge is interacting. If they really want to remove liability they'd just leave TF out of the repo and shift all liability to the end user where the first step runs a package install that brings in terraform.
> And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license.
Has an attorney who practices in this area reviewed this sentence in their capacity as an attorney (e.g. to a client of theirs, and not as free legal advice on Twitter et. al.)?
they might well be! As well as all other TACO providers eg Spacelift, Scalr, Env0
Yes we are competing in the same market; customers using Spacelift probably wont be using Digger and vice versa. But we feel like having a community-friendly fork would benefit everyone, without harming anyone.
I think it was still a good question. Pulumi is relevant if we talk about cloud orchestration in general, and is a Terraform alternative. Terraform is an abstraction over cloud APIs and there isn't anything which would stop the development of a HCL -> Pulumi compiler for example.
Isn't that to be expected? I only used Terraform for AWS, but the Terraform resources correspond almost directly to those of AWS CloudFormation and AWS's API.
Hopefully they can finally add the ability to initiate providers ad-hoc, such that you can create environments and then configure those afterwards in one go.
If you haven't checked it out already, you might want to take a look at Terragrunt[1] which is what I'm using for that purpose. In short, it can take multiple Terraform projects (stacks), track their dependencies, and run them in the correct order.
For instance, I have one stack that sets up a bunch of Hetzner Cloud vm instances and creates an RKE cluster on top of 'em, and another stack that uses the k8s provider and creates k8s resources based on the cloud instances, like a MetalLB load balancer.
I know most HN commentators are thinking about Terraform, but I think this change was done with Consul and Vault in mind.
Plenty of companies (including my employer) have been building fully monetized software using Consul and Vault under the hood and not paying them a dime. We're a company that's valued/market capped in the Billions btw and I know plenty of other large software companies doing the same thing.
Indeed - but the Terraform community appears to be hit the hardest. Because unlike Consul, there's no open-source hostable anything. It feels just an arbitrary restriction for a language + CLI; the terms of the licence can be viewed as if whatever you ship has Terraform cli embedded, you're in breach. I can see the reason for SPL like Mongo did - it is indeed unfair for AWS to make money off hosted open-source mongodb. But this move by Hashi I'm struggling to wrap my head around
> it is indeed unfair for AWS to make money off hosted open-source mongodb
Why? If software authors don't understand that releasing their code under an open source license means someone else other than them may potentially benefit from it, that's really on them.
Sure just do a Google search and you will see that a user searching for the database is going to get routed to the clone in the AWS organic and sponsored results
Based on BSL, if you aren't trying to commercialize on top of Terraform you'd still be fine.
If you're using Terraform to manage deployments in test and development it's still business as usual, but if you're actively using them in production or making a company that sells a wrapper around Terraform then you'd have to pay Hashicorp.
Honestly it's pretty fair. I can continue to make my own personal, test, or development apps using vault, consul, and terraform.
And this move was done because plenty of large companies (not naming names because this is starting to touch a legal gray area) are using Vault and Consul in production to generate hundreds of millions to billions a year in revenue.
with Vault and Consul that makes a ton of sense; they're centralised backend services that are inherently SaaS-like. But expanding the "on top of terraform" definition to a CLI / language? That's insane. It's like making a programming language or framework proprietary and saying you can't sell anything written in the language without the language creator's permission. I guess such languages did exist in the early days of the industry but those days are long gone
As has been pointed out elsewhere in the comments, this is incorrect. The switch to BSL does not mean you have to start paying Hashicorp to use their formerly OSS products in production. To quote their FAQ:
> All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp products or services.
Yes, people underestimate how important consul and vault are in modern infra. There is no direct replacement for vault or consul in how versatile and powerful these tools are.
I definitely underestimate them because in my last 7 roles I haven't used either. I don't know how far back 'modern' goes, but 3 roles were over the last 24 months (just started a new role) and none of those roles the companies used consul or vault to manage anything.
This is why they're having to make these moves. How much value have they given you vs how much have you paid? If the gap is too large, they have to start locking some things down.
Open Source software quickly becomes a tragedy of the commons because most organizations are unscrupulous. Look at how AWS destroyed the entire Elastic, MongoDB, PostgreSQL, Kafka, etc ecosystems by abusing overly permissive licenses.
Particularly with corporate charity (aka "permissive") licenses. If you want the source to stay open for users further down the chain, use a license that requires that.
It's a major reason why I'd never release a core revenue generating feature of mine under a permissive Open Source License.
Unsrupulous implies some form of an ethical code, whereby you are judged by intent, not by action - which is an idealized view of the world but an unrealistic one at that.
Strongly disagree with your point as you are comparing SaaS vendors who package these technologies under the hood with no immediate access provided to their customers, just as means to delivering a service with tech providers who were just blatantly packed by AWS and provided as identical technology.
There is a huuuuge difference between OP and your examples.
the tragedy of the commons is a thoroughly debunked though experiment, and actual studies show that in the real world, just like in this case, the real tragedy of the commons is when one entity (hashicorp) is able to monopolize a common good (open source software with contributions from tons of people outside of hashicorp) in a way everyone who was being a good user of the commons (by contributing back to those projects) is opposed to because it actively destroys something everyone was using collaboratively.
I have been thinking a lot about the tragedy of the commons (totc) within the context of usufructian socialist services and expanding them beyond their fairly narrow use case currently (public libraries are the biggest example). I was theorycrafting community makerspaces, tool libraries, and public baths, but I was hung up on thinking about totc. Do you have some sources that you would recommend for more detail on refuting or debunking totc? Thanks!
> Look at how AWS destroyed the entire ... PostgreSQL, Kafka, etc ecosystems
Err, I think you need better examples, as the PostgreSQL ecosystem is doing just fine, and RDS doesn't threaten anyone's IPO price. Since Kafka is not only Apache licensed but is an Apache project, I gravely doubt that the Apache Foundation is going to IPO anytime soon either
If you want to pick on two other ecosystem casualties by the Big Bad AWS Gonna Steal Our Shit fearmongering, use Sentry and Sourcegraph as examples of "we want the community until we don't" rug pulls
Do you think Google should lock down the go language and compiler, considering how much value they've given Terraform and likely how little Terraform has paid for go itself?
Following your example, Alphabet should open source all the weights they use in their current search algorithm as well as the algorithm itself.
And extending that principle, they should also open source the machine translation model and weights Robert DeNero made for them when at Google Translate.
Both of these are dumb hypotheticals but serve to point out the fact that there are loss leaders and revenue generators at each company.
True, just like Qualcomm bought Eudora (mac) email for fame, Google started the Go project to keep Rob Pike (of UNIX fame) happy and to help their own internal SRE teams. The public "good will" and benefits to Google SRE have more than paid for their efforts to create the Go language, plus also there is some publicity and fame for Google having most of the remaining early UNIX guys on staff ...
My employer pays for Visual Studio, JetBrains, Mac tax + dev license pays for XCode, Oracle, SQL Server,...
I guess it is up to Google to decide how to monetize Go, or who knows, maybe some day they will put it into a foundation of sorts that should find a way to keep sponsoring its development.
Terraform would have avoided years of stringly typed mess had it not been written in Go. I’d estimate that half the provider bugs I saw were either because of a lack of generics (and correct unwillingness to generate code), or because of casting empty interfaces.
The only advantage was static binaries, which not many other languages in a usable state supported at the time. It’s not even like there was an ecosystem at the time - HC had to maintain an AWS client for Go for several years, and similarly for Azure.
Don’t think it’s targeted at Vault. Vault has APIs so in the enterprise, you can self host and a vendor can manage vault through the APIs. Terraform specifically is built CLI only in the OSS so you have to repackage the underlying binary and hence are subject to the license as a vendor.
that's the most puzzling bit. Do they not want to anyone offering anything that could compete with any of Hashi's products to be able to use terraform binary at all?
if so, that's similar to proprietary programming languages. Not a thing. The community can just agree on a similar but open alternative and the original company is left behind. That's why all languages and frameworks are open-source with permissive licenses.
and if not, if it's just about the hosted / managed parts - then what exactly is it that I can use wrongly? Terraform Cloud / Enterprise was never open source. There's nothing I can self-host and charge users for...
> Do they not want to anyone offering anything that could compete with any of Hashi's products to be able to use terraform binary at all?
I think they want to make it difficult for SaaS products that embed terraform (or an altered version of terraform I would assume where they have built APIs) in their product. That said, customers can install terraform so you can still hypothetically have an "integration" with Terraform where you call the raw binary (like Atlantis). So basically, they want terraform cloud to have a "privileged" user experience is my guess.
On the other hand, we wanted to give them money to have a support contract, maybe some yearly architecture reviews or a call with a consultant to point us towards new features. We have similar agreements with e.g. AWS, we're looking at setting something like this up with a postgres consultancy. However, the smallest offering was solidly in the six figures a year. That put it into a very different investment process, the board got involved and you can all guess where it went from there.
I'm also surprised no one is really mentioning Nomad in this discussion either, I know for a fact circleci used nomad at some point to schedule CI tasks on worker machines. If I create a SaaS product that runs programs which get scheduled with nomad under the hood is that a breach of the license?
How does this new license work in terms of either a bug is found in terraform post support date or a new feature is added to the Hashicorp version.
Can the patch / new code be copied to this version without violating anything or does it have to be some sort of “clean room” patch where you only read the bug report and not the actual fix
I think appropriating code against the license would be a license violation. Whether it's a bug or a feature doesn't really make any difference. If it's not licensed for copying, then you can't copy it. You can't re-license it without permission.
That's why they are saying it's not an "open source" license anymore – because it's not. Source available means just that. You can read it (say for the purpose of figuring out some annoying bug so you can contribute the fix upstream) and you can probably build and run it, so long as your use is according to the terms granted in the license. But you can't redistribute it, any copy you take probably isn't yours, and it's only usable according to the terms of the license.
I think there's a compelling argument to be made for bug fixes and small changes being derivative works of the originally licensed open source software. As such, it's unlikely that the 'copyright' of those small changes would be able to stand on their own.
Perhaps 'derivative works' isn't the right term. I know there's some exceptions for copyright when there's 'one way' to do something, or something that substantially is not a creative work, such as a function that adds two numbers.
You might be thinking of the "obviousness test" for patents. If an invention is a combination of two things which are established prior art, and there is a suggestion, teaching, or motivation which any person could discover through straightforward analysis of the existing prior art, then it's not a patentable innovation.
There being one right way to solve a problem, doesn't really change whether a bit is copied or not. If you have a bug and there's one right way to solve the issue, then you don't need to copy the original. You can reproduce the bug and solve the issue, and any similarity between the independent solutions is coincidental.
If you take the source code and accept the new license terms, I think you'll be bound by the terms. I am not a lawyer and I haven't read the full text of the BUSL-1.1 but I will now, since that's probably the best way to understand what the license does or does not do.
In this I'm mostly concerned by the extremely vague description of what is it you can't do with this new terraform commercially. You can't "compete" with hashicorp. Well, if I'm doing devops consulting and I write terraform for clients is it competing with hashicorp? If not, what if they start offering such service tomorrow? Will it be competition them?
Personally, speaking figuratively, I think they just pulled a shotgun and decided to shoot both of their feet off. As someone doing devops consultancy since well before terraform became a thing I'd have no problem at all going back to custom python code with configuration in yaml if the clients decide its better for them.
IANAL, but I'm pretty sure writing terraform files is just fine. The issue comes when you take the source code from Terraform, package it, and resell it in some form commercially.
So, if you were AWS, you can't create "Elastic Terraform Service" using the TF source code as the base of your product.
There's a fundamental difference
Terraform's "server" was never open-source in the first place
So you already cannot pull the move that AWS did with Elastic and Mongo
The open-source part of Terraform is the CLI, the compiler, etc
Extremely puzzling move
It means you can't provide a CI/CD pipeline for terraform as a service. Because that would overlap with functionality of terraform cloud and enterprise.
Not necessarily; only if that CI/CD pipeline actually benefits from Hashicorp's code one way or another (embed, distribute, etc). I highly doubt that Hashi would consider Gitlab in breach of their license because they have support of Terraform state in their pipelines. Classic TACOS eg Scalr and similar might be in a somewhat bigger trouble as they have to have the terraform binary as part of their solution. But even then, they can remove all traces of terraform from their product and require the user to install a docker image with terraform version of user's choice.
Yes indeed a puzzling move from Hashicorp's leadership perspective. Could be a miscalculation; or no calculation at all.
It looks like it boils down to being no longer able to "incorporate the source code or embed or distribute newer versions of Terraform." (From Spacelift's blog). For a piece of software that doesn't even have a server, this seems extremely restrictive. I wouldn't be surprised if Hashicorp takes a few steps back on this / provides clarifications for specific use cases
Yeah that embed portion, I use terraform in a tool I maintain to make it easier to manage kubernetes deployments and with that embed clause that makes terraform DoA for me. It's been nice to work with but not essential, so now even though it's annoying I'll remove it next time I do a big push on the codebase.
> As someone doing devops consultancy since well before terraform became a thing I'd have no problem at all going back to custom python code with configuration in yaml if the clients decide its better for them.
Or for that matter, custom Python code with Pulumi - which AFAICT ain't pulling these sorts of shenanigans (yet).
“Thanks to integration with Terraform providers, Pulumi is also able to support a superset of the providers that Terraform currently offers.” From Pulumi’s site
I encourage this project to switch to AGPL license. Also, if you're a maintainer of a dependency of terraform and other projects, please consider doing the same. There's no way terraform can afford to support all those dependencies themselves.
As many organizations considers that AGPL may affect anything connected to it by the network and have carpet ban for applications licensed under AGPL, it would kill the project.
Small percent would actually pay. Due to that less and less engineers would use Terraform. In a few years most people on the market will switch to something else, that's easily accessible and it will take the crown.
Well, my comment clearly was made before they made the change. I wonder if my linking to it actually tipped them off, or do they really have so many products that they couldn't check each one was converted?
Having this delay makes me now more concerned that they're going to "catch" more of the MPL ones and relicense them, too
Shares were going down for some time, env0 (Terraform Cloud competitor) just raised 35m from VC for a what seems to be a good product... Hashicorp did it's move. If there's a community behind, the fork will live and, who knows, maybe many will start using it instead of the original one. It's all up to the community and substantial sponsors, at this point.
I still think that the best way to compete is by having a more appealing product, thought, rather than changing licence. And I mean this for Hashicorp, Elastic, etc.
If you need to do this move is because you don't really succeed at having a better product, else you would just benefit from FOSS rather than it being a liability.
We are in some sense a competitor too, alongside Spacelift, Env0, Scalr and a few others. Our product is built differently though, Digger is orchestrating terraform jobs in your existing CI instead of taking over the whole CI stack and effectively duplicating it just to run terraform. We built it this way almost by accident; our original product was very different (think "heroku-like UI for AWS" that generated and ran terraform on the server) and this is how we arrived at what Digger is now. Luckily we don't seem to be affected by the licensing change as we neither embed nor distribute any of hashicorp's code (it's on the user to set up the right version of it in say GH Actions).
Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we did purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.
> Funny enough, our own product (Digger, an open-source CI runner for Terraform) is not using Terraform (or any other Hashicorp's code) under the hood.
if Hashi chooses to enforce it to such extent that even calling a terraform binary (which is open source itself for now) constitues "embedding"... then good luck Hashi staying an "open source company". The days of proprietary programming languages are long gone. They appear to be confusing the languages / frameworks space with self-hostables. BSL makes total sense for Mongo / Elastic (as well as Vault or Consul). Not so much for a CLI / compiler thingie which Terraform is.
What a smackdown! You guys had me thinking you'd written a custom executor engine or something of that nature.
I've spent a fair amount of time digging around the terraform codebase and hacking on providers. I'm not too worried about the license change tbh, almost all the important IP is locked up in the provider codebases and no matter what direction hashicorp goes those providers will remain open.
The question will be, how are those providers executed? Most likely an open terraform fork will fill that role for the foreseeable future. But long-term I think hashicorp just handed IaC to crossplane and pulumi.
I think ACK from AWS and k8s-config-connector
from GCP probably represent the future of IaC. Crossplane is neat and all and pioneered the architecture but using the cloud provider native operators directly will always be a better experience. The question will be what the next generation of TACOS frontend tools look like.
Rewriting a provider into a kubernetes reconciler isn't an impossible undertaking and the tools for doing so are improving at a rapid rate. I recently finished up on a major project writing a kubernetes controller for a private cloud platform.
They're burning $50M loss last quarter which is mind blowing considering they had a monopoly originally. Michael raised too much money and let everything go to his head and his leadership. The internal chatter I hear is pure technical folks know this is a terrible choice, but "leadership" is so pressured and desperate given the economic headwinds they're trying to cut out any competitors building on top of their success. They refuse to believe their paid offers are just not good enough.
Hashicorp had lost nearly all it's value in the space.
Terraform, terra..what? Pulumi is starting to gain momentum as the long term winner in the space.
Nomad, K8s is mostly destroyed their future outside of some very specific cases around smaller deployments and frequent disconnects with the control plane.
Vagrant, docker RIP.
Consul, coredns and the main reason to use it for service discovery is gone with any of the cloud providers versions like ECS or K8s.
Vault, Pulumi chipping away at the main reason why people buy it which is dealing with TFs lack of encrypting each value in the state file. There are still spots where Vault wins (but open source is all that is needed) such as issuing out temp credentials off of a "root credential".
Packer, lack of overall community adoption even though in automation with hardware it is incredibly needed. Piss poor documentation and experience when getting started with it.
Rest of the services I've never looked at because there hasn't been a gap with a lack of a winner already. License change just means company is dead in my future choices anyways.
The size of a usable nomad cluster can absolutely dwarf the (pathetic) scaling capabilities of Kubernetes, largely thanks to the poor etcd API which simply cannot be fixed.
> They're burning $50M loss last quarter which is mind blowing considering they had a monopoly originally.
Their finances are pretty insane. In 2023 on sales of $475M their operating loss was $297M. And everything is going the wrong direction. They had $163M increase in operational expenses and increased revenue by only $155M. The last quarter they didn't increase revenue at all.
I don't see how the stock is worth $5.6B and any more than the $1.2B current liquidation value of the cash that they've got. How did they manage to go public at all?
They need to have a license structure like ARM. With ARM you can license their IP cores or you can license their architecture. Apple and NVidia and even Qualcomm have different needs (higher performance, higher process node, better battery life, and higher cost is okay for them) and they take an Architecture License (Qualcomm occasionally licenses IP cores, too.)
Spacelift and Env0 need architecture licenses. People on TF cloud essentially are licensing their IP cores. Their terraform cloud service is being run very poorly. When outsiders moved to provide an alternative for this thing which is broken inside of Hashicorp, the lawyers have been sic'd on them! That is not adult behavior. It shows a great naivety in business affairs ...
136 comments
[ 2.0 ms ] story [ 195 ms ] threadThe GPL has a specific exception for GCC that prevents it from polluting the licensing conditions of compiled programs.
Seems to stand for "Terraform Automation and COlaboration Software"
Yeah so basically TACOS are ci-like tools / control planes for Terraform. The OG one being Terraform Cloud.
The term TACOS was coined by Piotr Zaniewski here: https://itnext.io/spice-up-your-infrastructure-as-code-with-...
(December 2020)
The TF bridge is interacting. If they really want to remove liability they'd just leave TF out of the repo and shift all liability to the end user where the first step runs a package install that brings in terraform.
Has an attorney who practices in this area reviewed this sentence in their capacity as an attorney (e.g. to a client of theirs, and not as free legal advice on Twitter et. al.)?
Yes we are competing in the same market; customers using Spacelift probably wont be using Digger and vice versa. But we feel like having a community-friendly fork would benefit everyone, without harming anyone.
Clearly, based on my downvotes, I'm mistaken and should be ashamed.
[1]: https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/mig...
Downvotes are nothing more than an indicator of how many people clicked the downvote button.
That was several years ago, though; might be stale.
There is an unfortunate meme that this makes it a “Terraform wrapper” like CDK for TF, which it does not.
For instance, I have one stack that sets up a bunch of Hetzner Cloud vm instances and creates an RKE cluster on top of 'em, and another stack that uses the k8s provider and creates k8s resources based on the cloud instances, like a MetalLB load balancer.
[1] https://terragrunt.gruntwork.io/
It would be ideal if it was built in to the language.
Not a single vendor should own it all or even the majority.
Plenty of companies (including my employer) have been building fully monetized software using Consul and Vault under the hood and not paying them a dime. We're a company that's valued/market capped in the Billions btw and I know plenty of other large software companies doing the same thing.
Why? If software authors don't understand that releasing their code under an open source license means someone else other than them may potentially benefit from it, that's really on them.
Predatory unethical open source freeloaders don’t.
Amazon has never offered a database service based on the MongoDB server software. Not when it was AGPLv3 nor when it was SSPLv1.
It implemented a wire protocol for interoperability purposes, similar to functionality in IBM DB2, Azure CosmosDB, FerretDB, and other databases.
If you're using Terraform to manage deployments in test and development it's still business as usual, but if you're actively using them in production or making a company that sells a wrapper around Terraform then you'd have to pay Hashicorp.
Honestly it's pretty fair. I can continue to make my own personal, test, or development apps using vault, consul, and terraform.
And this move was done because plenty of large companies (not naming names because this is starting to touch a legal gray area) are using Vault and Consul in production to generate hundreds of millions to billions a year in revenue.
> All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp products or services.
Competition is healthy. Everyone should be reluctant to lock himself in with a vendor seeking a monopoly.
The idea that every credit card transaction or any form of dollar based transaction works on software directly built on Consul is patently false.
Open Source software quickly becomes a tragedy of the commons because most organizations are unscrupulous. Look at how AWS destroyed the entire Elastic, MongoDB, PostgreSQL, Kafka, etc ecosystems by abusing overly permissive licenses.
The problem lies with OSS, not with people using it.
Oh you mean the unwritten, unenforceable, undefined, romanticized spirit of the license?
It's a major reason why I'd never release a core revenue generating feature of mine under a permissive Open Source License.
Unsrupulous implies some form of an ethical code, whereby you are judged by intent, not by action - which is an idealized view of the world but an unrealistic one at that.
On the matter, Grafana has relicensed most of its software to AGPLv3 (eg: https://github.com/grafana/grafana/blob/main/LICENSE)
There is a huuuuge difference between OP and your examples.
Err, I think you need better examples, as the PostgreSQL ecosystem is doing just fine, and RDS doesn't threaten anyone's IPO price. Since Kafka is not only Apache licensed but is an Apache project, I gravely doubt that the Apache Foundation is going to IPO anytime soon either
If you want to pick on two other ecosystem casualties by the Big Bad AWS Gonna Steal Our Shit fearmongering, use Sentry and Sourcegraph as examples of "we want the community until we don't" rug pulls
Following your example, Alphabet should open source all the weights they use in their current search algorithm as well as the algorithm itself.
And extending that principle, they should also open source the machine translation model and weights Robert DeNero made for them when at Google Translate.
Both of these are dumb hypotheticals but serve to point out the fact that there are loss leaders and revenue generators at each company.
Hashicorp doesn't generate revenue from Terraform.
(They do generate revenue from Terraform Cloud, but that's a backend for Terraform, not Terraform itself)
I guess it is up to Google to decide how to monetize Go, or who knows, maybe some day they will put it into a foundation of sorts that should find a way to keep sponsoring its development.
The only advantage was static binaries, which not many other languages in a usable state supported at the time. It’s not even like there was an ecosystem at the time - HC had to maintain an AWS client for Go for several years, and similarly for Azure.
Side note: I’m not defending the license change and generally think most of HashiCorp’s products are not that great.
Plenty of companies are using Vault and Consul in this manner.
Review the FAQ here: https://www.hashicorp.com/license-faq
The problem is that "competing offering" is poorly defined.
if so, that's similar to proprietary programming languages. Not a thing. The community can just agree on a similar but open alternative and the original company is left behind. That's why all languages and frameworks are open-source with permissive licenses.
and if not, if it's just about the hosted / managed parts - then what exactly is it that I can use wrongly? Terraform Cloud / Enterprise was never open source. There's nothing I can self-host and charge users for...
I think they want to make it difficult for SaaS products that embed terraform (or an altered version of terraform I would assume where they have built APIs) in their product. That said, customers can install terraform so you can still hypothetically have an "integration" with Terraform where you call the raw binary (like Atlantis). So basically, they want terraform cloud to have a "privileged" user experience is my guess.
Clearly Terraform was also in mind, since Terraform is now under the BUSL: https://github.com/hashicorp/terraform/blob/main/LICENSE
Can the patch / new code be copied to this version without violating anything or does it have to be some sort of “clean room” patch where you only read the bug report and not the actual fix
That's why they are saying it's not an "open source" license anymore – because it's not. Source available means just that. You can read it (say for the purpose of figuring out some annoying bug so you can contribute the fix upstream) and you can probably build and run it, so long as your use is according to the terms granted in the license. But you can't redistribute it, any copy you take probably isn't yours, and it's only usable according to the terms of the license.
Perhaps 'derivative works' isn't the right term. I know there's some exceptions for copyright when there's 'one way' to do something, or something that substantially is not a creative work, such as a function that adds two numbers.
There being one right way to solve a problem, doesn't really change whether a bit is copied or not. If you have a bug and there's one right way to solve the issue, then you don't need to copy the original. You can reproduce the bug and solve the issue, and any similarity between the independent solutions is coincidental.
If you take the source code and accept the new license terms, I think you'll be bound by the terms. I am not a lawyer and I haven't read the full text of the BUSL-1.1 but I will now, since that's probably the best way to understand what the license does or does not do.
Personally, speaking figuratively, I think they just pulled a shotgun and decided to shoot both of their feet off. As someone doing devops consultancy since well before terraform became a thing I'd have no problem at all going back to custom python code with configuration in yaml if the clients decide its better for them.
So, if you were AWS, you can't create "Elastic Terraform Service" using the TF source code as the base of your product.
It looks like it boils down to being no longer able to "incorporate the source code or embed or distribute newer versions of Terraform." (From Spacelift's blog). For a piece of software that doesn't even have a server, this seems extremely restrictive. I wouldn't be surprised if Hashicorp takes a few steps back on this / provides clarifications for specific use cases
Or for that matter, custom Python code with Pulumi - which AFAICT ain't pulling these sorts of shenanigans (yet).
I'll probably use this for my personal projects instead of Hashi's official stuff.
I don't think that OpenTerraform will be able to pull the Terraform code and relicense it under the MPL.
Either this fork lives on and becomes its own thing (better or worse than the original terraform? only time will tell!) or it dies very quickly.
Having this delay makes me now more concerned that they're going to "catch" more of the MPL ones and relicense them, too
I still think that the best way to compete is by having a more appealing product, thought, rather than changing licence. And I mean this for Hashicorp, Elastic, etc.
If you need to do this move is because you don't really succeed at having a better product, else you would just benefit from FOSS rather than it being a liability.
https://github.com/diggerhq/digger
Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we did purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.
> Funny enough, our own product (Digger, an open-source CI runner for Terraform) is not using Terraform (or any other Hashicorp's code) under the hood.
Oh yes you are:
https://github.com/diggerhq/digger/blob/develop/pkg/core/ter...
You're on thin ice if you want to argue whether forking a terraform process constitutes "hosting" or "embedding" terraform.
This will shake the sandbox. I personally hope that the community will step up with a fork.
I've spent a fair amount of time digging around the terraform codebase and hacking on providers. I'm not too worried about the license change tbh, almost all the important IP is locked up in the provider codebases and no matter what direction hashicorp goes those providers will remain open.
The question will be, how are those providers executed? Most likely an open terraform fork will fill that role for the foreseeable future. But long-term I think hashicorp just handed IaC to crossplane and pulumi.
I think ACK from AWS and k8s-config-connector from GCP probably represent the future of IaC. Crossplane is neat and all and pioneered the architecture but using the cloud provider native operators directly will always be a better experience. The question will be what the next generation of TACOS frontend tools look like.
Rewriting a provider into a kubernetes reconciler isn't an impossible undertaking and the tools for doing so are improving at a rapid rate. I recently finished up on a major project writing a kubernetes controller for a private cloud platform.
They're burning $50M loss last quarter which is mind blowing considering they had a monopoly originally. Michael raised too much money and let everything go to his head and his leadership. The internal chatter I hear is pure technical folks know this is a terrible choice, but "leadership" is so pressured and desperate given the economic headwinds they're trying to cut out any competitors building on top of their success. They refuse to believe their paid offers are just not good enough.
Hashicorp had lost nearly all it's value in the space.
Terraform, terra..what? Pulumi is starting to gain momentum as the long term winner in the space.
Nomad, K8s is mostly destroyed their future outside of some very specific cases around smaller deployments and frequent disconnects with the control plane.
Vagrant, docker RIP.
Consul, coredns and the main reason to use it for service discovery is gone with any of the cloud providers versions like ECS or K8s.
Vault, Pulumi chipping away at the main reason why people buy it which is dealing with TFs lack of encrypting each value in the state file. There are still spots where Vault wins (but open source is all that is needed) such as issuing out temp credentials off of a "root credential".
Packer, lack of overall community adoption even though in automation with hardware it is incredibly needed. Piss poor documentation and experience when getting started with it.
Rest of the services I've never looked at because there hasn't been a gap with a lack of a winner already. License change just means company is dead in my future choices anyways.
This is the most important sentence, as I see it.
The size of a usable nomad cluster can absolutely dwarf the (pathetic) scaling capabilities of Kubernetes, largely thanks to the poor etcd API which simply cannot be fixed.
Their finances are pretty insane. In 2023 on sales of $475M their operating loss was $297M. And everything is going the wrong direction. They had $163M increase in operational expenses and increased revenue by only $155M. The last quarter they didn't increase revenue at all.
I don't see how the stock is worth $5.6B and any more than the $1.2B current liquidation value of the cash that they've got. How did they manage to go public at all?
https://www.reddit.com/r/Terraform/comments/15p2p32/impact_o...
Spacelift and Env0 need architecture licenses. People on TF cloud essentially are licensing their IP cores. Their terraform cloud service is being run very poorly. When outsiders moved to provide an alternative for this thing which is broken inside of Hashicorp, the lawyers have been sic'd on them! That is not adult behavior. It shows a great naivety in business affairs ...