Isn't "Terraform" a copyrighted / owned word by Hashicorp? Is it somehow itself part of the MPL - the name itself?

Would then whatever opentf.org would become need a new "tf" name?

Just don't know the ins and outs on that.

There was definitely room for improvement around using Terraform to do actual deployments. From better UX around doing PR's -- showing not only the commit diff but the output of a "tf plan" as well to see what it might actually do -- to actually running the deployments on isolated build machines that could hold the sensitive cloud API keys and provide a deployment audit trail, these were all features that teams absolutely needed to use Terraform sanely. As a solo developer you don't really need those features, but if you're on a team you definitely did, and were almost certainly willing to pay for it. Hashicorp recognized that need and created the cloud/enterprise offerings to provide that.

At some point the thought even crossed my mind of creating some open-source tool that could provide a nice enough web interface for dealing with Terraform for teams, building on what we had and providing the features I listed above, but the main reason I didn't was because it would be biting the hand that feeds. Such a tool would take away people's incentives from using Hashicorp's paid offerings and ultimately reduce their investment in Terraform and their other fantastic tools, and in my opinion, be disrespecting the tremendous work Hashicorp had done up to that point. I've been a user of their stuff since they only had Vagrant, and of course have loved them seeing them succeed.

It seems others, however, had different opinions and saw a business opportunity thanks to the permissive licensing and the high costs of Hashicorp's paid offerings. Plenty of money to be made from making it easy to use TF in teams, especially when you're not obligated to contribute back or maintain the underlying software [1]. Any time I saw a "Launch/Show HN" post from a company that was offering such TF wrapper web interfaces, I kept being surprised that Hashicorp hadn't yet clamped down on preventing lower-cost offerings of their paid services. It was only a matter of time.

[1]: I realize this reads as overly harsh to some of these companies, especially as some of them are in here replying and pledging to give back, so let me try to explain my reasoning here. When I use a product, I like it when the source is available from me to learn from and understand how it works [2] and to contribute back to for needed features or bugfixes [3].

When a company makes a product open-source, that's great! But if that product is the core of that company's business model [4], and another company starts competing with that company using the same open-source product, then I see a problem down the line. While you can make the argument that the competition is good and motivates the two companies to compete on the value they bring to their customers, which is a net-benefit to the open-source ecosystem as a whole as the open-source product is improved, it eventually turns into a race to the bottom. Pricing will be used as a core differentiator, reducing the overall R&D spending on the open-source product because ultimately the two companies have to maintain non-R&D staff like sales, finance, and support. If the Total Addressable Market is fixed (obviously not, but work with me), then that's two or more companies with the same fixed non-R&D costs diverting revenue that could be spent instead on improving the open-source product. Sure, the reality is that a lot of that revenue isn't going back to the open-source product, as a lot of people are complaining about in the comments, but that diversion is probably going to happen anyway whether there's 1 company or 20, so I'd accept it as a cost of doing business.

If instead the competition were on providing a better but different open-source product in the same space (e.g. Pulumi), rather than working off the same base, that would be a different story. But if developers keep seeing businesses take open-source projects and directly compete with their creators, then I think we're going to see a net harm to the open-source community as it creates a sort of chilling effect as it'll demotivate them from going the open-source route so that they can find a viable way to sustain their efforts. I think licenses such as the BSL and SSPL are valid enough compromises, considering that even mentioning the AGPL inside of a lot of companies seems to be like someone saying Voldemort's name. We can't rely on large corporations sponsoring open-source projects, either with money or developer time, if we want them to succeed.

We grant inventors 20 years of exclusive-use on an invention, provided they explain how to reproduce it through the publishing of a patent. What's the difference between that and the BSL? I see a lot of complaints about bait-and-switches, but I don't really see the issue. If you contributed to the project under the old license, it's still available under the old license! You just don't get any of the new changes starting from the license change. If you decided to use Terraform in a non-competing way [5] solely because of the old license, and are concerned about the new one, then you have to recognize that Hashicorp is now another addition to a long-line of "open-core" companies trying to deal with the reality that companies will make money any way they legally can. This is where the industry is currently headed, and whatever replacement you find will probably be next.

If you believe different, then make an open-source offering, and don't just make a public statement saying it'll be open-source forever. Public statements are great and all, up until there's doubts about meeting payroll. Find a way to make the statement legally binding and then we're talking. Which is I guess why there's so much consternation, since the way to do it is through the license, but the OSI doesn't recognize any of these other licenses as "open-source" and the AGPL is a non-starter at most companies.

[2]: Reading the source code for libraries I use has been incredibly valuable in my understanding of how to use the libraries properly, much better than any documentation could. And of course, makes me a better programmer in the process.

[3]: At one point, Terraform was missing a feature that I badly needed. With the source available, I could easily get a new version of it running locally with that feature to unblock me, and then everyone benefited when I contributed it back to the project. It's also been invaluable having these locally modifiable builds to understand the quirks of products from cloud vendors, and to work around them. Ever had multiple deployment pipelines fail because Azure decided to one day change the format of the timestamps they returned in API calls, without publishing a new API version? I have.

[4]: As opposed to supplementing their business model. Google open-sourcing K8s was great for them because it drove adoption of their cloud VMs. Their cloud business makes money off the VMs, not GKE, so sponsoring K8s is essentially a marketing expense. But for Hashicorp, their core business model is paid offerings of their products.

[5]: Yes, I get that the license currently is un-clear, for all their products. But let's simply say that you're not trying to directly sell a wrapper around running Terraform.

Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at all to just blow up and force you to figure out how to make the software work again.

Configuration management tools should make your life easier, not harder. You shouldn't have to hire a "Terraform Admin with 3 yrs experience" just to learn all the bizarre quirks of this one tool just to get your S3 bucket to have the correct policy again. You shouldn't have to write Go tests just to change said policy. It's like it was invented to be a jobs program for sysadmins.

I have a laundry list of all the stupid design decisions that went into the damn thing. And because the entire god damn industry is stuck on this one tool, no other tool will ever replace it. Its providers are so large and there are so many modules created that it would take years of constant development to replace it. So it doesn't get changed or improved, and it can never be replaced. It is the incumbent that blocks progress. A technological quagmire we can't extricate ourselves from.

The essential purpose of this tool is really to be a general interface to random APIs, track dependencies in a DAG, pass values into resources when it has them, attempt to submit a request to the API, and then die if it doesn't get a 200 back. We can accomplish this in a simpler way that is less proprietary and more useful. And we can ramp up on specific functionality to give the solution actual intelligence, like default behaviors for specific resources in specific providers, hints on how to name a resource, more examples, canned modules that are easier to discover or publish, ability to use different languages or executables, etc. But we need to put forward those alternatives now, or we won't get the chance again for a long time.

“Internal error? The #$@! does that mean?”

You could have both: eg if resource Y depends on X, then you would just declare Y after X. Or you could do a "depends_on" directive like in TF.

That certainly doesn't sound like a dead end to me.

I have a whole bunch of bare metal sitting in data centers all over the world, how am I expected to manage it?

Ansible/Salt/Chef is obviously one type of solution, but like you said, being able to code things in TS is really nice.

One thing TF does well, is bare metal.

> We strongly prefer joining an existing reputable foundation over creating a new one. Stay tuned for additional details in the coming week.

Joining an existing foundation sounds like the right move to me. Many organizations need this fork to take off very quickly, since they are facing legal uncertainty. Make sure it is clear how to support the project, and those organizations will be happy to do so.

It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue.

With Vault they’ve just recently launched their new cloud secrets service. Most of their revenue comes from Vault. Nearly all of their future revenue growth is vault. Any competitor could relatively easily provide the same service with vault FOSS today. Vault is feature complete. The only moat they have is their license.

Best for the ecosystem if both Vault and Terraform are maintained by a foundation. Not best for Hashicorp, but best for the industry for sure.

His GitHub activity seem to indicate he is now focused on the Zig programming language.

After thinking about it for a few days, I think Hashicorp's move is actually net great for everyone. The products that matter will be forked and maintained in the open. Hashicorp would choose wisely to merge mature forks back into their product, if they can, and now you have a pretty standard model of up selling enterprise features on an open product that's developed in the actual open. It frees Hashicorp up to focus on the enterprise, which they have already been doing, but they've been neglecting their OSS, like Terraform (what the actual fuck is going on with the development of Terraform over the last two years?)

This is great. I'm really looking forward to using freed forks that pop up in the months ahead.

This is Hashicorp's sink or swim moment.

If you asked me when they announced the license change, I'd say bet the horse on Pulumi and move on. But now I actually think this could really rejuvenate the TF ecosystem.

Obviously there would be tradeoffs involved. But if we can cover the 80% situation, that would be a good start.

I think Gruntwork's blog explains this the best - https://blog.gruntwork.io/the-future-of-terraform-must-be-op...

Obviously, there's the argument that Hashicorp might sue you even for that, but it feels like the reductio ad absurdum that any company can sue you for anything, and not remotely plausible.

VMS are a concept of older times and should be replaced by containers. YES; there is still use for VM's but everyone and their mother migration to k8s will mean wonders for portability of applications and more.

Long living forks and fragmentation sucks, but now HashiCorp has to react to this and provide compelling benefits if they don't want to loose the whole project alltogether.

The rest of the agreement is still valid, just the completion part is nullified

Perhaps if they went down the certification strategy it would've been a safer gamble. Certified Hashicorp Terraform Practioner. 650 a cert, probably would've saved their arse.

Cloud blurs the line, since a lot of cloud offerings are managed where you're really doing both at once when you define the managed offering.

Regardless, this is likely a painful moment for him. Maybe he just doesn't want to talk about it, and won't for some time.

Yeah: latency. Everything else is identical, from the software perspective. Even the distributed aspect is identical: multiple copies of software running in one OS, or multiple machines running one copy of the software, are treated virtually identically.

> it's only in the world of modern virtualization and clouds that you can start to do that through APIs

I've worked in multiple companies, starting nearly 20 years ago, that had automated the process of provisioning and re-provisioning both hardware and software across tens of thousands of machines in multiple datacenters. Without virtualization, without the cloud. Know how we did it? Same way Terraform does it. Make an API, make a tool to call it, API backend does some magic, returns result, tool does something with result. Nothing has changed except the buzzwords (and the programming languages).

Configuration management is "a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life." [1] It is not Puppet or CFengine. It is an engineering practice that is nearly 70 years old. Terraform is an implementation of it, as are many other tools, and many things that aren't software at all.

> None of this is marketing speak. It's just definitions and categorizations. Sometimes useful, sometimes not. And all of it is orthogonal to what terraform does do or should do.

On the contrary, the categorizations are made up by people who don't understand the history and practice of the field and confuse designers and practitioners into thinking that what they're doing is correct because "that's just what things in this category do". It's throwing out systems thinking and replacing it with a cargo cult of buzzwords and generally useless concepts.

Every week I see somebody talking about "Infrastructure as Code" as if it's a real thing. It's not. IaC just means somebody put a shell script and config file in Git. Yet they treat it like it's both revolutionary and specific to this one corner of tech. Like we haven't been version-controlling or change-managing the provisioning of computing devices for decades. People who weren't aware of standardized practices for management of fleets of devices basically had to stumble upon it, and not having any other reference, decided to give it a new name and pretend it was novel, and in the process did not learn the lessons from past decades of similar practice.

This is not just an "old man yells at cloud" rant - the point is that tech people keep refusing to learn their history, and then poorly implementing something that could have been designed much better if they'd learned their history. It's like the history of medical practice, where some areas of the globe (cough western europe cough) were embarrassingly backward because they never reached out to learn about the history, research, and best practices outside their sphere. They just did what everyone else around them did. People suffered for decades as a result. We don't suffer quite as much now, but the advancement of technology does suffer as a result of the industry's stodgy refusal to improve on its cargo cult mentality. (Repeating whatever you read in a blog post on HN is what makes things like "Infrastructure as Code" seem like a real and novel idea to people; repeat an idea enough and people just believe it and repeat it too)

Another example: "declarative configuration". All configuration is declarative. Even imperative configuration is declarative. This tautology is debated in blog posts the same way you'd debate the use of types of butter in cooking. It's all just butter. Yeah, some comes without salt; just add some salt to your dish. Yeah, some comes with salt; just withhold some salt from your food. We don't need to go on long-winded writings about the use of different butters. But some people create entire software projects dedicated to one kind of butter, because they think it's super important to only use unsalted butter.

[1] https://en.wikipedia.org/wiki/Configuration_management

I was saying that anyone who operates large scale Kubernetes knows that you will forever be dealing with tuning etcd and fighting to keep etcd alive. It's an underpinning service of Kubernetes.

Roblox's outage was related to the intricacies of running consul and mistakes that they made.

The point I was making was that I would rather, at this scale of operation, be running Nomad and optionally Consul and optionally dealing with the intricacies of Consul than running Kubernetes and being _forced_ to deal with what a miserable pain in the ass etcd is.

I was saying that running Kubernetes is _not_ the obvious choice -- at least once you're at 10^5+ systems.

What's different about this one?

The whole point of this thread is the premise that it's not a fork.

Hashicorp's copy is the fork, and it's backwards that the fork gets to keep the name and the original must rename itself.

How would that be an improvement to anyone in any way? If you want, you can just pretend that Terraform is dead and Hashicorp will never push another commit for it. The people who can make the compromises BSL has can continue to use it.

> If the viability of your business is predicated on being the only one able to provide your project as a service and earn that service revenue gravy, just leave it closed source and proprietary. Sure, you won't get adoption at anywhere near the rate, but that's the tradeoff you make.

I don’t understand why this is a binary. If the conditions of the BSL are unacceptable to YOU that’s fine, just pretend it’s closed source if you wish. For others, that the BSL isn’t completely proprietary is useful for them - let it be useful. Your wishes need not dictate everyone else’s.

No. It was not a rhetorical device.

> you just don't like the implications.

I don't know which implications you're talking about, it was a question without prejudice or load.

> People somehow think that a business which started an open source project "deserves" to profit from it.

I do not agree. I don't hold a position stating that "TF should stay open, and companies should profit from it while giving it patches if you feel like it". I'm the opposite, and I find the approach to permissive licenses as "Ooo... Free tool to build a new product on and profit" as unethical to begin with. I put anything and everything I put out as A/GPLv3 or GFDL, because I produce that code for myself, on my free time, and I don't have a secret desire for it to be forked and closed down for internet cookie points.

If you want to use my tool for any reason (which are not very sophisticated to begin with), comply with GPL, or roll your own. I. Don't. Care.

I also pay for tons of things. Docker, cloud storage, programming fonts I use, anything I deem worth the money they're asking for.

I also use Vagrant a lot, share my Vagrantfiles (again under GPLv3), and if they begin to charge like Docker, I'll pay for it, if I deem it's worth the money they ask for.

However, at the end of the day, I'm a Free Software advocate. I use Free Software to the extent possible, and develop my software as Free Software. Not Open Source software under some permissive license to be grabbed and forked to death.

And even if you could, you're basically just left with the GPLv2.

If Terraform was 100% developed by HashiCorp employees that would be fair description. It's more like "We're the only company allowed to make money off of the codebase you contributed to."

> What is hashicorp or any other company in their position to do?

I'd suggest paying developers to write proprietary code. That way they could just sell a product they fully own instead of having to pull this bullshit re-licensing of an open source codebase.

I have had similar experiences poking around other tf providers which were of apparently low quality.

[1] https://registry.terraform.io/providers/elastic/ec/latest/do...

100%. Docker's UX has always been its killer feature, and it counts for a lot. That's a very real contribution. But this is absolutely still a 'shoulders of giants', 'it takes a village' situation.

Also IIUC most of the parties in this conversation are corporations. They’re all trying to enjoy the benefits of open source development for a variety of reasons.

Ditto for earnings: once your company is publicly traded or at least lands in a Gartner report, you don't need evangelists that badly anymore.

Free pull requests are always welcome, but I guess a calculation was made in this case.

Best of luck with Spacelift :)

MongoDB and Elastic are SSPL. SSPL approaches the problem like the AGPL; it compels licensees who sell a service derived from the software to make available under the SSPL the source of all supporting tooling and software so that a user could spin up their own version of the service.

There's an argument to be made that SSPL is de facto "you can't compete with us" since it would be more challenging to make a competitive SaaS offering if your whole stack is source available. I don't disagree. However, as distasteful as SSPL is, at least it doesn't grant licensing to a product conditionally on the unknowable future product offerings of HashiCorp.

MongoDB, Elastic, etc. cannot stop you from running a competitor based on the terms of their licenses, they just ask that you publish the source code for whatever service you're running in its entirety (I acknowledge there are disagreements about how far "entirety" extends). The clause in Hashicorp's license actually revokes the right to use their software at all if you're a direct competitor.

OK, no one is going to build an open source competitor to Elastic or MongoDB because then you have no moat and your business will probably fail, I get it, but it's still possible to do without repercussion. It's not like the AGPL is that far off in terms of limitation, either, which is why you don't see many copyleft services run by large corporations unless they've been dual-licensed.

To make a python metaphor, if cpython had a testing suite but pytest didn't exist then people wouldn't be able to test their own python code. That's kind of the situation with Terraform right now- you can't test your code using just the Terraform tools, you have to rely on Terratest which was written by Gruntwork. Hashicorp has spent years relying on the open source community to fill those gaps, which Gruntwork has done very nicely.

Hashicorp even recommends Terratest for testing: https://www.hashicorp.com/blog/testing-hashicorp-terraform

However, it still allows your code to be bundled inside a bigger work. The bigger work can be in any license (maybe not GPL, need to check), but MPL stays MPL. This doesn't prevent white-labeling the codebase, though.

As far as I read the MPL, the contribution back part is not mandatory, but encouraged by not affecting the larger work. It keeps the MPL part open, but doesn't enforce a "send patches back" policy.

    from pulumi_aws import s3

    bucket = s3.Bucket('bucket')

    for i in range(10):
        s3.BucketObject(
            f'object-{i}',
            s3.BucketObjectArgs(
                bucket=bucket.id,
                key=str(i),
            )
        )

Disclaimer: I led the YAML project and added the compiler feature at the request of some folks internally looking for CUE support :)

[1] https://www.pulumi.com/blog/pulumi-is-imperative-declarative...

[2] https://www.pulumi.com/blog/extending-pulumi-languages-with-...

[3] https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes...

It’s actually not a guesstimate about what actions will be taken, it’s a guesstimate of the state that will result from those actions without any reference to ordering or “actions” as a cloud API would understand them - the plan is purely in terms of CRUD on Terraform provider resources and provisioners.

This may seem like a nit, but it fundamentally changes what Terraform is capable of doing in a single pass without external coordination.

Rolling up a tar of your source tree, however, will be required if you get a request from one of your customers by email. The difference from GPL is that you will only have to tarball a portion of the tree that was MPL-licensed. That tar must include your patches, as §3.1 requires.

As I said before, many companies argue that using a private fork of an MPL/EPL/LGPL software in a SaaS does not trigger the distribution clause as customers never get a source or a binary of the program that runs in the cloud. EUPL closes that loophole.

It's also possible that many companies violate EPL/MPL/LGPL terms (knowingly or unknowingly).

One good example of non-viral copyleft working as intended is the Eclipse IDE. There are many closed-source tools that use Eclipse IDE under the hood (the part that Eclipse calls RCP), but there are no commercial forks of the IDE itself because any such company would have to open-source their changes to the fork.

I mainly wanted to focus on the "civil" than "war" aspect of the possible schism.

> "it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit"

... but only earlier today were you equating a data protection law with the Holocaust... seems you could do with a bit less projection and rhetoric yourself, Kraggy.

The state is stored in the resources themselves, to be precise.

> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.

As someone who worked on tagging inside AWS, I don't believe that there are any major AWS services left that don't support tagging. These days, tagging-on-creation also guarantees that you won't have untagged resources if your provider happens to die between "CreateResource" and the "TagResource" operations.

You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.

API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.

State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.

I'm still not sure which of the latter two was the intent of the comment I was responding to

Such hypocrisy, attacking others for "rhetoric" that needs to be "dialled back a bit" when you're every bit as guilty of the exact. same. thing.

If there is more than one back and forth, you become declarative, even if you imperatively generate a "declarative" intermediate representation (not really sure what state file at a point in time could ever be imperative), you then would get back some data from the engine, then make choices about what to send off to the engine in the next request.

It's important to understand that with Pulumi, you can end up in either situation. You have to be careful to not become imperative overall is probably the better way to consider this.

https://www.pulumi.com/docs/languages-sdks/javascript/#entry...

Another way this can break down is if the user writes code to call the same APIs in the middle of a Pulumi script. I meant to try this myself to verify it works, but I would assume that Pulumi is not stopping me from doing something like this.

When someone tries to make a sophisticated argument that up is down and white is black, dismissive and shallow is the right response.

> The actual work done under the covers is not imperative

Having a declarative layer somewhere in the stack doesn't make something declarative, if that's not the layer you actually use to work on and reason about the system. See the famous "the C language is purely functional" post.

1. Creating a resource where created is not the same as ready. This is extraordinarily common with compute resources (a virtual machine, a container, an HTTP server, a process) where attempting to create follow-up resources can result in costly retry-back-off loops. Even when creating Kubernetes resources, Pulumi will stand up an internet-connected deployment more quickly than many other tools because you can ensure the image is published before a pod references it, the pod is up before a service references it, and so on. (The Kubernetes provider bakes some of these awaits in by default.)

2. Resources graphs that are dynamic, reflecting external data sources at the moment of creation. Whether you want to write a Kubernetes operator, synchronize an LDAP directory to a SaaS product, or one of my favorite examples. When I set up demos, I often configure the authorized public IPs dynamically:

    import * as publicIp from 'public-ip';

    new someProvider.Kubernetes.Cluster('cluster',
      {
        apiServerAccessProfile: {
          authorizedIPRanges: [await publicIp.v4()],
          enablePrivateCluster: false,
        },
      }

That was more me yelling into the void or larger thread than at anything specific you said, sorry :]