3 ms·

To copy the comment from Reddit https://old.reddit.com/r/Terraform/comments/15o9mzt/openterraform_an_mpl_fork_of_terraform_after/jvqio3o/ https://old.reddit.co

To copy the comment from Reddit https://old.reddit.com/r/Terraform/comments/15o9mzt/openterraform_an_mpl_fork_of_terraform_after/jvqio3o/ https://old.reddit.com/r/Terraform/comments/15o9mzt/openterr... > 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/terraform/tf.go#L161 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.

igorzij 3y ago
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.
- pachico 3y ago
  I think it's quite clear they don't care about being called an open source company, which is fine, as I see it. This will shake the sandbox. I personally hope that the community will step up with a fork.
dpeckett 3y ago
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.

igorzij 3y ago

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.

pachico 3y ago
I think it's quite clear they don't care about being called an open source company, which is fine, as I see it. This will shake the sandbox. I personally hope that the community will step up with a fork.

dpeckett 3y ago

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.