> As a result, we believe commercial open source models need to evolve for the ecosystem to continue providing open, freely available software.
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?
I haven't looked to see what licenses are involved, but Pulumi makes liberal use of Terraform providers[1]. And I would definitely consider them to be a Hashicorp competitor.
> 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.
TF providers are just wrappers around other APIs - and the vast majority ain't even developed by Hashicorp in the first place.
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.
> TF providers are just wrappers around other APIs
If it's so simple, Pulumi could have done this themselves. Why didn't they? Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
> If it's so simple, Pulumi could have done this themselves. Why didn't they?
Because that would be a waste of time unless there's some specific case where an existing provider is insufficient.
> Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
Pulumi itself is free software, just like Terraform was (and hopefully still is). There is literally nothing stopping Hashicorp from doing the exact same thing in the opposite direction.
Are you pretending they aren't a competitor profiting off that work though?
Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/. So, Pulumi has grown their directly competing product partially on top of the Terraform ecosystem - and I'd argue they'd be half as successful without reusing Terraform providers - and make money off of that product. It's at least understandable to me that Hashicorp doesn't like this.
Most TF providers are not maintained by Hashicorp, but by the company whose product the provider integrates into. Development of the provider is an investment the company makes to lower CAC.
Sure, but the providers for some of the biggest platforms are maintained by HashiCorp[1] - like the AWS, Azure, GCP, and Kubernetes providers[2], and it appears the Pulumi AWS provider (for example) _does_ use the Terraform AWS provider, even to this day[3].
3. https://github.com/pulumi/pulumi-aws/tree/008c4360bc9fc24303... - Just prove it to myself, I can see the `upstream` git submodule, which embeds pulumi/terraform-provider-aws, which is a fork of hashicorp/terraform-provider-aws, although the repo was not created as a fork in Github, so it is not marked as a "fork" and so I have to compare commit histories to tell that it is a fork.
The Pulumi Kubernetes provider is a native provider. It does not take a TF provider as a dependency. Instead, it works directly based off the k8s API spec.
The Google TF provider is actually maintained by Google via Magic Modules, a single source for both TF and Ansible . The generated TF provider does reside in HashiCorp’s GH org tho.
I've always seen open source as more of a spectrum. On one extreme, you have gpl3 stuff coming from the church of GNU itself. Moving up the spectrum you have stuff like the Linux kernel or certain CNCF projects, which can be used in proprietary distributions etc. Above that you'll have company specific licenses like the Amazon software license or whatever hashicorp+elastic are doing these days. At some point you're with RHEL where you need to sign a license to get their source, and above that you're signing ndas, and above that its closed source, and above that they're cryptographically obfuscating their source code with anti reverse engineering licensing.
I appreciate open source in all it's forms, as it's so much easier to 1. Read the code in case of a bug or just to understand your dependencies better, 2. Many of the semi closed licenses still allow you to learn things like syntax for GitHub actions or do analytics or whatever, which is still more value than an entirely closed system, and 3. It allows me to reproduce binaries and independently audit security.
That said, I'm worried about a tragedy of the commons situation. I'm not a fan of capitalism, but at the end of the day I can't pay for housing or taxes in clout or goodwill, and the only way I see likely to both attract talent and survive is one which works within the system while sacrificing their principles as little as possible. These wonderful engineers at elastic and hashicorp and pulumi and every other company mentioned in this thread need to eat.
I'm not saying I have an answer, but I am saying that I respect and understand why companies like elastic and hashicorp are resorting to drastic measures. If the choice is between either of those companies going under or having their source code come with a little bit more restrictions, I'd chose the latter. I'd much rather them have a noncompete clause in their license than have them just shut the window into their source code altogether.
That's being disingenuous. The link you cite is the pricing of Pulumi Cloud. Of course hosting infra can cost money. The second non-heading line in your link shows a way to host Pulumi on your own infra and that is fully free: https://www.pulumi.com/docs/concepts/state#using-a-self-mana...
However, Pulumi Cloud is only as valuable as Pulumi itself. If Pulumi didn't support deploying to AWS, for example, then it is useless to my organization which uses AWS and I'm obviously not going to consider Pulumi Cloud. So Pulumi does gain a lot of value even from just the Terraform AWS provider that it uses under the hood (and which it can continue to use because it seems Terraform provider licenses are not changing, which is nice).
> The paid features have nothing to do with the providers;
They absolutely do. If I use AWS and Pulumi could not deploy to AWS, well I'm certainly not going to buy Pulumi Cloud, am I? If I use multiple cloud providers and Pulumi doesn't support all of them, I'm unlikely to invest further in Pulumi Cloud, right?
The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
The fact that Pulumi leverages the Terraform AWS provider under the hood adds huge value for them, and I absolutely believe they indirectly profit off of that.
No, they absolutely do not. Pulumi - as in the actual tool, not its developers' equivalent to Terraform Cloud - would still exist and would have used those providers regardless of whether or not there's some Pulumi equivalent to Terraform Cloud. Pulumi also would've existed (and resulted in indirect profits via Pulumi Cloud) had that provider ecosystem not yet existed; it just would've been Pulumi starting it instead of Hashicorp/Terraform.
> The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
And you can use 100% of that value without paying a fraction of a penny to Pulumi, just as you can without paying a fraction of a penny to Hashicorp. It's a completely different offering from their respective paid products altogether.
> I absolutely believe they indirectly profit off of that.
You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers. That's one of the main sales pitches for open source, after all: to collaborate on something that benefits everyone instead of wasting a bunch of effort on independent silos.
That is: Hashicorp indirectly profits off Pulumi's own contributions to that same ecosystem. They could profit even more by making Terraform compatible with Pulumi's provider interface (even still! I'm pretty sure Apache 2.0 code can be included in non-FOSS codebases, BUSL included).
Like, the relationship between Hashicorp and Pulumi is not just to the letter but to the spirit of free and open source software. If Pulumi's existence and success (despite being nowhere near that of Terraform, and despite also being open source - even more permissively so, in fact) is indeed what motivated Hashicorp to switch Terraform from MPL 2.0 to BUSL, then that's toxic as all hell and completely nullifies any of Hashicorp's lip service to "open source".
> You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers.
This is idealism.
The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort. Then, Pulumi can spin up a directly competing product in a fraction of the time by reusing all of that work. So I understand the motivation for the license change.
Circling back to your original comment which spawned this thread:
> Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
The answer is unequivocally "yes". Pulumi has. And Pulumi can continue to do so, apparently. Terraform providers continue to be MPL-licensed.
With IBM Cloud® Secrets Manager, you can create secrets dynamically and lease them to applications while you control access from a single location. Built on open source HashiCorp Vault, Secrets Manager helps you get the data isolation of a dedicated environment with the benefits of a public cloud.
No, it's realism. The only one to blame for Hashicorp not adequately capitalizing on the two-way street that is multiple FOSS (well, formerly, in one case) IaC systems being compatible with one another... is Hashicorp. Instead of recognizing a case where "open source" is mutually beneficial, they'd rather take their ball and go home - and that's their right, but it ain't beyond criticism.
> The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort
The reality is that Hashicorp adopted Pulumi's strategy of autogenerating provider resources from API catalogs rather than maintaining handwritten bindings (i.e. what differentiates Pulumi's "native" v. "classic" providers). So yes, Pulumi's providers clearly have value. Hell, they can continue to have value even after Hashicorp's BUSL shenanigans thanks to Apache 2.0 being permissive.
> The answer is unequivocally "yes". Pulumi has.
The answer is hardly "unequivocal", per above and per the previous comments. Calling a collection of third-party-developed API shims a "product" is itself a massive stretch of the word, and calling bidirectional / mutually beneficial contribution to that collection "competition" is itself a massive stretch of the word.
IBM Cloud Secrets Manager is much better evidence in support of an unequivocal "yes" (though like most non-mainframe IBM-branded products these days I'd question whether or not it counts as "of any significance").
Would terraform have been successful without the ecosystem of providers provided by third parties, and many, many external contributions to providers they do manage?
> Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
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.
> 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 licence tends to have the dual effect of dissuading otherwise valid users from using it, because a lot of devs and corps see “something something GPL” and just shut down.
Exactly, which is why all these companies that claim they can't survive without their shiny new I-can't-believe-it's-not-open-source licenses deserve all the scorn they get. I've flipped the bozo switch on Hashicorp.
I'm thinking that AGPL is, indeed, the Ebola of viral licenses, but it does not cover the case where a large cloud vendor simply takes an AGPL-licensed product and offers it as a cloud service. AGPL does not cover that case. Nothing the cloud vendor does challenges any of the AGPL's terms.
The cloud vendor issue is license agnostic. ElasticSearch comes to mind. For the AGPL side, MongoDB and Neo4J come to mind.
Recall that AGPL came into play by way of a hole in the GPL terms, the one where you can modify a GPL codebase but you don't have to say anything unless you publish it. GPL was weak in therms of the definition of "publish". AGPL closed that hole.
But, that hole only becomes toxic the moment you modify the code or plug proprietary stuff into it. Cloud vendors don't do that.
Cloud providers build a proprietary control plane to deploy copies of the program and it could be argued that such code is a modification of the program itself and thus has to be released. That's why they won't touch AGPL code.
AGPL doesn't infect you code unless you don't link with AGPL-licensed one. Control planes rarely do this. That's why Amazon was absolutely OK with MongoDB being under AGPL.
> but it does not cover the case where a large cloud vendor simply takes an AGPL-licensed product and offers it as a cloud service
Because it doesn't need to, nor should it. That's only a competition issue if the upstream developer is actually offering a managed version themselves - and in that case they already have "we actually developed this software so we're the best option for supporting it in The Cloud™" as a selling point that even the likes of Amazon and Google cannot replicate (not without themselves participating in the actual development of the software in question). They should lean into that selling point and offer a better managed offering than what any cloud vendor could ever hope to offer.
Plus, as I've mentioned in sibling comments, large cloud vendors probably don't have much interest in reselling Hashicorp's products anyway. Why resell Terraform when you're trying to lock customers into CloudFormation? Why resell Vault when you're trying to lock customers into Secrets Manager? Why resell any of Hashicorp's products when the thing for which they're marketed - avoiding vendor lock-in - is literally antithetical to your business model of maximizing vendor lock-in?
> But, that hole only becomes toxic the moment you modify the code or plug proprietary stuff into it. Cloud vendors don't do that.
Sure they do. If they didn't modify their managed versions of FOSS applications to integrate tightly with the rest of their offerings, then why would anyone bother to use the cloud-vendor-managed versions in the first place? If there's no benefit integration-wise relative to just slapping the vanilla version on some EC2 instance or EKS container or whatever, then what's the point?
SSPL is much worse than AGPL. At worst AGPL demands you to license your own code under same terms.
While SSPL demands you to license third-party code from backup solutions to operating system and firmware. Good luck publishing source code of Linux kernel or even Windows under SSPL.
AWS in particular already has its own competing services that predate or otherwise do not derive from Hashicorp's offerings (CloudFormation, Secrets Manager, etc.). Same with pretty much every other major cloud provider. The whole point of going with Vault or Consul or Terraform or what have you is to not tie oneself to a particular provider's offerings.
Put simply: Hashicorp's target market for a given product is largely not going to be interested in a cloud provider's locked-down equivalent, and a cloud provider is not going to be interested in deprecating its own tightly-integrated product in favor of customizing some third-party offering.
And again: if this was a legitimate fear, then the AGPL already fully addresses it.
ctrl+f for "open source", and note where they stop using it. Note that they describe this change to maintain "open, freely available products", not open source.
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".
I mean, they allow you to create a manifest that then auto provisions some infrastructure, so... Shrug
I'm being half-serious. Of course the point is that "competing" is deliberately very poorly defined, and it's entirely on the whim of hashicorp to decide whether or not you're competing and then impose a lot of legal costs on you.
Sure, Crossplane leverages the K8s control plane for managing desired state for systems outside of the kubernetes cluster. It functions in a very similar fashion to terraform but it’s storing its own state in etcd instead of another state store. That makes GitOps + Crossplane play really nicely together and avoid the extra complexity that happens with terraform apply operations. They have a terraform wrapper provider for importing existing config and state.
It’s really nice to have infra and apps flow through the same pipes.
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?