> 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.
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.
This will shake the sandbox. I personally hope that the community will step up with a fork.