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.

Do you think anyone has ever paid Hashicorp to help write some TF scripts?

Absolutely! They have professional services.

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