11 ms·

OpenTerraform – an MPL fork of Terraform after HashiCorp's license change

151 points by igorzij 3y ago

igorzij 3y ago
Hashicorp switched Terraform from MPL to BSL yesterday. Many other companies did that in the past to prevent others taking their code and charging for running it as a managed service (eg Mongo, Elastic). With Hashi however, the server-side part was never open-source to start with. There was no such thing as "open-source Terraform Server". And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license. 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. So this change probably hits other TACOS (Spacelift, Env0) much harder than us. But with the recent pricing changes and now the license there is no guarantee that Hashicorp won't make another move in the future that would one way or another hurt us. So if there was an MPL fork, we'd rather swith to that, just to stay on the safe side. And since there isn't one yet, we thought why not make one?
- orangepurple 3y ago
  The Terraform language should not be impacted by the license change any more than the GCC license impacts code it compiles (for example). I'd love to hear any assertions to the contrary.
  - CuriousCosmic 3y ago
    I think that depends exactly on the licensing. The GPL has a specific exception for GCC that prevents it from polluting the licensing conditions of compiled programs.
- lars_francke 3y ago
  You use TACOS as if it is well known. It isn't by me. Seems to stand for "Terraform Automation and COlaboration Software"
  - izalutski 3y ago
    Yeah apologies we're in a little bubble here together with Spacelift, Scale, Env0 and Atlantis so starting to assume everyone knows the niche terminology lol Yeah so basically TACOS are ci-like tools / control planes for Terraform. The OG one being Terraform Cloud. The term TACOS was coined by Piotr Zaniewski here: https://itnext.io/spice-up-your-infrastructure-as-code-with-tacos-1a9c179e0783 https://itnext.io/spice-up-your-infrastructure-as-code-with-...
    - cube2222 3y ago
      It's actually much older than that. I think it was coined by CloudPosse with this video: https://youtu.be/4MLBpBqZmpM https://youtu.be/4MLBpBqZmpM (December 2020)
      - igorzij 3y ago
        oh wow didn't know thanks!!
    - chenrui 3y ago
      atlantis would be fine, see this comment, https://github.com/runatlantis/atlantis/issues/3663#issuecomment-1674038026 https://github.com/runatlantis/atlantis/issues/3663#issuecom...
- nunez 3y ago
  I wonder how this affects Pulumi, since they were using Terraform under the hood for some things IIRC.
  - spott 3y ago
    I don’t think they were running terraform, they were converting terraform code to Pulumi code as a way to bootstrap their supported services/clouds/etc.
  - ckdarby 3y ago
    Pulumi itself isn't doing anything. The TF bridge is interacting. If they really want to remove liability they'd just leave TF out of the repo and shift all liability to the end user where the first step runs a package install that brings in terraform.
    - Proven 3y ago
      [dead]
- darkwater 3y ago
  IANAL but probably Hashicorp has some trademark over "Terraform" in this context. I don't know if it's 100% safe for you to call it "Open Terraform".
  - igorzij 3y ago
    thanks! indeed, totally valid concern
- Zetice 3y ago
  > And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license. Has an attorney who practices in this area reviewed this sentence in their capacity as an attorney (e.g. to a client of theirs, and not as free legal advice on Twitter et. al.)?
bovermyer 3y ago
I'm curious if Pulumi is interested in this.
- igorzij 3y ago
  they might well be! As well as all other TACO providers eg Spacelift, Scalr, Env0 Yes we are competing in the same market; customers using Spacelift probably wont be using Digger and vice versa. But we feel like having a community-friendly fork would benefit everyone, without harming anyone.
- deleted 3y ago
  [deleted]
- jen20 3y ago
  Why would they be? Pulumi talks to providers at the protocol level - contrary to the belief of many, Pulumi is not a Terraform wrapper.
  - bovermyer 3y ago
    I thought they used portions of Terraform's code. Clearly, based on my downvotes, I'm mistaken and should be ashamed.
    - sharms 3y ago
      I think it was still a good question. Pulumi is relevant if we talk about cloud orchestration in general, and is a Terraform alternative. Terraform is an abstraction over cloud APIs and there isn't anything which would stop the development of a HCL -> Pulumi compiler for example.
      - jen20 3y ago
        One actually exists already, built into the CLI [1]! [1]: https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/migrating-to-pulumi/from-terraform/#converting-terraform-hcl-to-pulumi https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/mig...
whazor 3y ago
Hopefully they can finally add the ability to initiate providers ad-hoc, such that you can create environments and then configure those afterwards in one go.
- lvncelot 3y ago
  If you haven't checked it out already, you might want to take a look at Terragrunt[1] which is what I'm using for that purpose. In short, it can take multiple Terraform projects (stacks), track their dependencies, and run them in the correct order. For instance, I have one stack that sets up a bunch of Hetzner Cloud vm instances and creates an RKE cluster on top of 'em, and another stack that uses the k8s provider and creates k8s resources based on the cloud instances, like a MetalLB load balancer. [1] https://terragrunt.gruntwork.io/ https://terragrunt.gruntwork.io/
  - linuxdude314 3y ago
    That’s what it’s for but a lot of us don’t like the added complexity. It would be ideal if it was built in to the language.
jakozaur 3y ago
Well, can next Terraform successor be build by few vendors and community, not just a single one? Not a single vendor should own it all or even the majority.
- klysm 3y ago
  Unclear how that would work in practice to me without some shitty half followed standards
  - simon_turner 3y ago
    Apache Software Foundation?
alephnerd 3y ago
I know most HN commentators are thinking about Terraform, but I think this change was done with Consul and Vault in mind. Plenty of companies (including my employer) have been building fully monetized software using Consul and Vault under the hood and not paying them a dime. We're a company that's valued/market capped in the Billions btw and I know plenty of other large software companies doing the same thing.
- proxysna 3y ago
  Yes, people underestimate how important consul and vault are in modern infra. There is no direct replacement for vault or consul in how versatile and powerful these tools are.
  - linuxftw 3y ago
    I definitely underestimate them because in my last 7 roles I haven't used either. I don't know how far back 'modern' goes, but 3 roles were over the last 24 months (just started a new role) and none of those roles the companies used consul or vault to manage anything.
    - alephnerd 3y ago
      If you've ever done a credit card transaction or any form of dollar based transaction, it's using software directly built on top of Consul.
      - dralley 3y ago
        Are there public details about this? Are you referring to the Visa Network or something related?
        deleted 3y ago
        [deleted]
      - cthalupa 3y ago
HtmlProgrammer 3y ago
How does this new license work in terms of either a bug is found in terraform post support date or a new feature is added to the Hashicorp version. Can the patch / new code be copied to this version without violating anything or does it have to be some sort of “clean room” patch where you only read the bug report and not the actual fix
- yebyen 3y ago
  I think appropriating code against the license would be a license violation. Whether it's a bug or a feature doesn't really make any difference. If it's not licensed for copying, then you can't copy it. You can't re-license it without permission. That's why they are saying it's not an "open source" license anymore – because it's not. Source available means just that. You can read it (say for the purpose of figuring out some annoying bug so you can contribute the fix upstream) and you can probably build and run it, so long as your use is according to the terms granted in the license. But you can't redistribute it, any copy you take probably isn't yours, and it's only usable according to the terms of the license.
  - linuxftw 3y ago
    I think there's a compelling argument to be made for bug fixes and small changes being derivative works of the originally licensed open source software. As such, it's unlikely that the 'copyright' of those small changes would be able to stand on their own. Perhaps 'derivative works' isn't the right term. I know there's some exceptions for copyright when there's 'one way' to do something, or something that substantially is not a creative work, such as a function that adds two numbers.
    - yebyen 3y ago
      You might be thinking of the "obviousness test" for patents. If an invention is a combination of two things which are established prior art, and there is a suggestion, teaching, or motivation which any person could discover through straightforward analysis of the existing prior art, then it's not a patentable innovation. There being one right way to solve a problem, doesn't really change whether a bit is copied or not. If you have a bug and there's one right way to solve the issue, then you don't need to copy the original. You can reproduce the bug and solve the issue, and any similarity between the independent solutions is coincidental. If you take the source code and accept the new license terms, I think you'll be bound by the terms. I am not a lawyer and I haven't read the full text of the BUSL-1.1 but I will now, since that's probably the best way to understand what the license does or does not do.
Roark66 3y ago
In this I'm mostly concerned by the extremely vague description of what is it you can't do with this new terraform commercially. You can't "compete" with hashicorp. Well, if I'm doing devops consulting and I write terraform for clients is it competing with hashicorp? If not, what if they start offering such service tomorrow? Will it be competition them? Personally, speaking figuratively, I think they just pulled a shotgun and decided to shoot both of their feet off. 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.
- SteveNuts 3y ago
  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.
  - izalutski 3y ago
    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
    - thayne 3y ago
      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.
      - igorzij 3y ago
        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.
p10jkle 3y ago
https://www.hashicorp.com/trademark-policy https://www.hashicorp.com/trademark-policy - surely this is a violation?
- znpy 3y ago
  OpenTF would be a good name in my opinion, they could just rename the project.
linuxftw 3y ago
I encourage this project to switch to AGPL license. Also, if you're a maintainer of a dependency of terraform and other projects, please consider doing the same. There's no way terraform can afford to support all those dependencies themselves.
- dzikimarian 3y ago
  As many organizations considers that AGPL may affect anything connected to it by the network and have carpet ban for applications licensed under AGPL, it would kill the project.
  - linuxftw 3y ago
    Then they can go it alone or pay terraform.
    - dzikimarian 3y ago
      Small percent would actually pay. Due to that less and less engineers would use Terraform. In a few years most people on the market will switch to something else, that's easily accessible and it will take the crown.
      - deleted 3y ago
        [deleted]
      - arielcostas 3y ago
        Good, competition incentivises innovation.
nunez 3y ago
This is awesome! The CentOS of Terraform, finally. I'll probably use this for my personal projects instead of Hashi's official stuff.
- znpy 3y ago
  Not really. I don't think that OpenTerraform will be able to pull the Terraform code and relicense it under the MPL. Either this fork lives on and becomes its own thing (better or worse than the original terraform? only time will tell!) or it dies very quickly.
- igorzij 3y ago
  thanks!!
CommanderData 3y ago
I wonder if the license change also applies to HCL? Which I'm seeing more and more use of in open source projects unrelated to IaC.
- mdaniel 3y ago
  no, it and a ton of other things in their GH org are still MPL (for now): https://github.com/hashicorp/hcl-lang/blob/main/LICENSE https://github.com/hashicorp/hcl-lang/blob/main/LICENSE including, confusingly https://github.com/hashicorp/boundary/blob/main/LICENSE https://github.com/hashicorp/boundary/blob/main/LICENSE which I would have thought would have fallen into the same "but AWS gonna steal our shit" fearmongering as Nomad, did to say nothing of the future in which AWS offers Managed Vagrant™ :eyeroll:
  - rahkiin 3y ago
    That last link clearly says BSL though
    - mdaniel 3y ago
      Well, my comment clearly was made before they made the change. I wonder if my linking to it actually tipped them off, or do they really have so many products that they couldn't check each one was converted? Having this delay makes me now more concerned that they're going to "catch" more of the MPL ones and relicense them, too
pachico 3y ago
Shares were going down for some time, env0 (Terraform Cloud competitor) just raised 35m from VC for a what seems to be a good product... Hashicorp did it's move. If there's a community behind, the fork will live and, who knows, maybe many will start using it instead of the original one. It's all up to the community and substantial sponsors, at this point. I still think that the best way to compete is by having a more appealing product, thought, rather than changing licence. And I mean this for Hashicorp, Elastic, etc. If you need to do this move is because you don't really succeed at having a better product, else you would just benefit from FOSS rather than it being a liability.
- igorzij 3y ago
  We are in some sense a competitor too, alongside Spacelift, Env0, Scalr and a few others. Our product is built differently though, Digger is orchestrating terraform jobs in your existing CI instead of taking over the whole CI stack and effectively duplicating it just to run terraform. We built it this way almost by accident; our original product was very different (think "heroku-like UI for AWS" that generated and ran terraform on the server) and this is how we arrived at what Digger is now. Luckily we don't seem to be affected by the licensing change as we neither embed nor distribute any of hashicorp's code (it's on the user to set up the right version of it in say GH Actions). https://github.com/diggerhq/digger https://github.com/diggerhq/digger Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we did purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.
  - Iammadeofpizza 3y ago
    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.
macca321 3y ago
I wonder if a non commercial Terraform Cloud "offering" like https://github.com/leg100/otf https://github.com/leg100/otf is "competing" with Hashicorp...
- Coryodaniel 3y ago
  There was a thread on Reddit about this and the author got a response from Armon saying it was not. https://www.reddit.com/r/Terraform/comments/15p2p32/impact_of_new_licensing_on_open_source/ https://www.reddit.com/r/Terraform/comments/15p2p32/impact_o...
systemBuilder 3y ago
They need to have a license structure like ARM. With ARM you can license their IP cores or you can license their architecture. Apple and NVidia and even Qualcomm have different needs (higher performance, higher process node, better battery life, and higher cost is okay for them) and they take an Architecture License (Qualcomm occasionally licenses IP cores, too.) Spacelift and Env0 need architecture licenses. People on TF cloud essentially are licensing their IP cores. Their terraform cloud service is being run very poorly. When outsiders moved to provide an alternative for this thing which is broken inside of Hashicorp, the lawyers have been sic'd on them! That is not adult behavior. It shows a great naivety in business affairs ...

151 points by igorzij 3y ago

Hashicorp switched Terraform from MPL to BSL yesterday. Many other companies did that in the past to prevent others taking their code and charging for running it as a managed service (eg Mongo, Elastic). With Hashi however, the server-side part was never open-source to start with. There was no such thing as "open-source Terraform Server". And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license. 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. So this change probably hits other TACOS (Spacelift, Env0) much harder than us. But with the recent pricing changes and now the license there is no guarantee that Hashicorp won't make another move in the future that would one way or another hurt us. So if there was an MPL fork, we'd rather swith to that, just to stay on the safe side. And since there isn't one yet, we thought why not make one?

orangepurple 3y ago
The Terraform language should not be impacted by the license change any more than the GCC license impacts code it compiles (for example). I'd love to hear any assertions to the contrary.
- CuriousCosmic 3y ago
  I think that depends exactly on the licensing. The GPL has a specific exception for GCC that prevents it from polluting the licensing conditions of compiled programs.
lars_francke 3y ago
You use TACOS as if it is well known. It isn't by me. Seems to stand for "Terraform Automation and COlaboration Software"
- izalutski 3y ago
  Yeah apologies we're in a little bubble here together with Spacelift, Scale, Env0 and Atlantis so starting to assume everyone knows the niche terminology lol Yeah so basically TACOS are ci-like tools / control planes for Terraform. The OG one being Terraform Cloud. The term TACOS was coined by Piotr Zaniewski here: https://itnext.io/spice-up-your-infrastructure-as-code-with-tacos-1a9c179e0783 https://itnext.io/spice-up-your-infrastructure-as-code-with-...
  - cube2222 3y ago
    It's actually much older than that. I think it was coined by CloudPosse with this video: https://youtu.be/4MLBpBqZmpM https://youtu.be/4MLBpBqZmpM (December 2020)
    - igorzij 3y ago
      oh wow didn't know thanks!!
  - chenrui 3y ago
    atlantis would be fine, see this comment, https://github.com/runatlantis/atlantis/issues/3663#issuecomment-1674038026 https://github.com/runatlantis/atlantis/issues/3663#issuecom...
nunez 3y ago
I wonder how this affects Pulumi, since they were using Terraform under the hood for some things IIRC.
- spott 3y ago
  I don’t think they were running terraform, they were converting terraform code to Pulumi code as a way to bootstrap their supported services/clouds/etc.
- ckdarby 3y ago
  Pulumi itself isn't doing anything. The TF bridge is interacting. If they really want to remove liability they'd just leave TF out of the repo and shift all liability to the end user where the first step runs a package install that brings in terraform.
  - Proven 3y ago
    [dead]
darkwater 3y ago
IANAL but probably Hashicorp has some trademark over "Terraform" in this context. I don't know if it's 100% safe for you to call it "Open Terraform".
- igorzij 3y ago
  thanks! indeed, totally valid concern
Zetice 3y ago
> And now it seems that any commercial product that uses the Terraform language under the hood is at risk of violating the terms of the license. Has an attorney who practices in this area reviewed this sentence in their capacity as an attorney (e.g. to a client of theirs, and not as free legal advice on Twitter et. al.)?

bovermyer 3y ago

I'm curious if Pulumi is interested in this.

igorzij 3y ago
they might well be! As well as all other TACO providers eg Spacelift, Scalr, Env0 Yes we are competing in the same market; customers using Spacelift probably wont be using Digger and vice versa. But we feel like having a community-friendly fork would benefit everyone, without harming anyone.
deleted 3y ago
[deleted]
jen20 3y ago
Why would they be? Pulumi talks to providers at the protocol level - contrary to the belief of many, Pulumi is not a Terraform wrapper.
- bovermyer 3y ago
  I thought they used portions of Terraform's code. Clearly, based on my downvotes, I'm mistaken and should be ashamed.
  - sharms 3y ago
    I think it was still a good question. Pulumi is relevant if we talk about cloud orchestration in general, and is a Terraform alternative. Terraform is an abstraction over cloud APIs and there isn't anything which would stop the development of a HCL -> Pulumi compiler for example.
    - jen20 3y ago
      One actually exists already, built into the CLI [1]! [1]: https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/migrating-to-pulumi/from-terraform/#converting-terraform-hcl-to-pulumi https://www.pulumi.com/docs/using-pulumi/adopting-pulumi/mig...

whazor 3y ago

Hopefully they can finally add the ability to initiate providers ad-hoc, such that you can create environments and then configure those afterwards in one go.

lvncelot 3y ago
If you haven't checked it out already, you might want to take a look at Terragrunt[1] which is what I'm using for that purpose. In short, it can take multiple Terraform projects (stacks), track their dependencies, and run them in the correct order. For instance, I have one stack that sets up a bunch of Hetzner Cloud vm instances and creates an RKE cluster on top of 'em, and another stack that uses the k8s provider and creates k8s resources based on the cloud instances, like a MetalLB load balancer. [1] https://terragrunt.gruntwork.io/ https://terragrunt.gruntwork.io/
- linuxdude314 3y ago
  That’s what it’s for but a lot of us don’t like the added complexity. It would be ideal if it was built in to the language.

jakozaur 3y ago

Well, can next Terraform successor be build by few vendors and community, not just a single one? Not a single vendor should own it all or even the majority.

klysm 3y ago
Unclear how that would work in practice to me without some shitty half followed standards
- simon_turner 3y ago
  Apache Software Foundation?

alephnerd 3y ago

I know most HN commentators are thinking about Terraform, but I think this change was done with Consul and Vault in mind. Plenty of companies (including my employer) have been building fully monetized software using Consul and Vault under the hood and not paying them a dime. We're a company that's valued/market capped in the Billions btw and I know plenty of other large software companies doing the same thing.

proxysna 3y ago
Yes, people underestimate how important consul and vault are in modern infra. There is no direct replacement for vault or consul in how versatile and powerful these tools are.
- linuxftw 3y ago
  I definitely underestimate them because in my last 7 roles I haven't used either. I don't know how far back 'modern' goes, but 3 roles were over the last 24 months (just started a new role) and none of those roles the companies used consul or vault to manage anything.
  - alephnerd 3y ago
    If you've ever done a credit card transaction or any form of dollar based transaction, it's using software directly built on top of Consul.
    - dralley 3y ago
      Are there public details about this? Are you referring to the Visa Network or something related?
      - deleted 3y ago
        [deleted]
    - cthalupa 3y ago

HtmlProgrammer 3y ago

How does this new license work in terms of either a bug is found in terraform post support date or a new feature is added to the Hashicorp version. Can the patch / new code be copied to this version without violating anything or does it have to be some sort of “clean room” patch where you only read the bug report and not the actual fix

yebyen 3y ago
I think appropriating code against the license would be a license violation. Whether it's a bug or a feature doesn't really make any difference. If it's not licensed for copying, then you can't copy it. You can't re-license it without permission. That's why they are saying it's not an "open source" license anymore – because it's not. Source available means just that. You can read it (say for the purpose of figuring out some annoying bug so you can contribute the fix upstream) and you can probably build and run it, so long as your use is according to the terms granted in the license. But you can't redistribute it, any copy you take probably isn't yours, and it's only usable according to the terms of the license.
- linuxftw 3y ago
  I think there's a compelling argument to be made for bug fixes and small changes being derivative works of the originally licensed open source software. As such, it's unlikely that the 'copyright' of those small changes would be able to stand on their own. Perhaps 'derivative works' isn't the right term. I know there's some exceptions for copyright when there's 'one way' to do something, or something that substantially is not a creative work, such as a function that adds two numbers.
  - yebyen 3y ago
    You might be thinking of the "obviousness test" for patents. If an invention is a combination of two things which are established prior art, and there is a suggestion, teaching, or motivation which any person could discover through straightforward analysis of the existing prior art, then it's not a patentable innovation. There being one right way to solve a problem, doesn't really change whether a bit is copied or not. If you have a bug and there's one right way to solve the issue, then you don't need to copy the original. You can reproduce the bug and solve the issue, and any similarity between the independent solutions is coincidental. If you take the source code and accept the new license terms, I think you'll be bound by the terms. I am not a lawyer and I haven't read the full text of the BUSL-1.1 but I will now, since that's probably the best way to understand what the license does or does not do.

Roark66 3y ago

In this I'm mostly concerned by the extremely vague description of what is it you can't do with this new terraform commercially. You can't "compete" with hashicorp. Well, if I'm doing devops consulting and I write terraform for clients is it competing with hashicorp? If not, what if they start offering such service tomorrow? Will it be competition them? Personally, speaking figuratively, I think they just pulled a shotgun and decided to shoot both of their feet off. 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.

SteveNuts 3y ago
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.
- izalutski 3y ago
  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
  - thayne 3y ago
    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.
    - igorzij 3y ago
      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.

p10jkle 3y ago

https://www.hashicorp.com/trademark-policy https://www.hashicorp.com/trademark-policy - surely this is a violation?

znpy 3y ago
OpenTF would be a good name in my opinion, they could just rename the project.

linuxftw 3y ago

I encourage this project to switch to AGPL license. Also, if you're a maintainer of a dependency of terraform and other projects, please consider doing the same. There's no way terraform can afford to support all those dependencies themselves.

dzikimarian 3y ago
As many organizations considers that AGPL may affect anything connected to it by the network and have carpet ban for applications licensed under AGPL, it would kill the project.
- linuxftw 3y ago
  Then they can go it alone or pay terraform.
  - dzikimarian 3y ago
    Small percent would actually pay. Due to that less and less engineers would use Terraform. In a few years most people on the market will switch to something else, that's easily accessible and it will take the crown.
    - deleted 3y ago
      [deleted]
    - arielcostas 3y ago
      Good, competition incentivises innovation.

nunez 3y ago

This is awesome! The CentOS of Terraform, finally. I'll probably use this for my personal projects instead of Hashi's official stuff.

znpy 3y ago
Not really. I don't think that OpenTerraform will be able to pull the Terraform code and relicense it under the MPL. Either this fork lives on and becomes its own thing (better or worse than the original terraform? only time will tell!) or it dies very quickly.
igorzij 3y ago
thanks!!

CommanderData 3y ago

I wonder if the license change also applies to HCL? Which I'm seeing more and more use of in open source projects unrelated to IaC.

mdaniel 3y ago
no, it and a ton of other things in their GH org are still MPL (for now): https://github.com/hashicorp/hcl-lang/blob/main/LICENSE https://github.com/hashicorp/hcl-lang/blob/main/LICENSE including, confusingly https://github.com/hashicorp/boundary/blob/main/LICENSE https://github.com/hashicorp/boundary/blob/main/LICENSE which I would have thought would have fallen into the same "but AWS gonna steal our shit" fearmongering as Nomad, did to say nothing of the future in which AWS offers Managed Vagrant™ :eyeroll:
- rahkiin 3y ago
  That last link clearly says BSL though
  - mdaniel 3y ago
    Well, my comment clearly was made before they made the change. I wonder if my linking to it actually tipped them off, or do they really have so many products that they couldn't check each one was converted? Having this delay makes me now more concerned that they're going to "catch" more of the MPL ones and relicense them, too

pachico 3y ago

Shares were going down for some time, env0 (Terraform Cloud competitor) just raised 35m from VC for a what seems to be a good product... Hashicorp did it's move. If there's a community behind, the fork will live and, who knows, maybe many will start using it instead of the original one. It's all up to the community and substantial sponsors, at this point. I still think that the best way to compete is by having a more appealing product, thought, rather than changing licence. And I mean this for Hashicorp, Elastic, etc. If you need to do this move is because you don't really succeed at having a better product, else you would just benefit from FOSS rather than it being a liability.

igorzij 3y ago
We are in some sense a competitor too, alongside Spacelift, Env0, Scalr and a few others. Our product is built differently though, Digger is orchestrating terraform jobs in your existing CI instead of taking over the whole CI stack and effectively duplicating it just to run terraform. We built it this way almost by accident; our original product was very different (think "heroku-like UI for AWS" that generated and ran terraform on the server) and this is how we arrived at what Digger is now. Luckily we don't seem to be affected by the licensing change as we neither embed nor distribute any of hashicorp's code (it's on the user to set up the right version of it in say GH Actions). https://github.com/diggerhq/digger https://github.com/diggerhq/digger Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we did purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.
- Iammadeofpizza 3y ago
  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.

macca321 3y ago

I wonder if a non commercial Terraform Cloud "offering" like https://github.com/leg100/otf https://github.com/leg100/otf is "competing" with Hashicorp...

Coryodaniel 3y ago
There was a thread on Reddit about this and the author got a response from Armon saying it was not. https://www.reddit.com/r/Terraform/comments/15p2p32/impact_of_new_licensing_on_open_source/ https://www.reddit.com/r/Terraform/comments/15p2p32/impact_o...

systemBuilder 3y ago

They need to have a license structure like ARM. With ARM you can license their IP cores or you can license their architecture. Apple and NVidia and even Qualcomm have different needs (higher performance, higher process node, better battery life, and higher cost is okay for them) and they take an Architecture License (Qualcomm occasionally licenses IP cores, too.) Spacelift and Env0 need architecture licenses. People on TF cloud essentially are licensing their IP cores. Their terraform cloud service is being run very poorly. When outsiders moved to provide an alternative for this thing which is broken inside of Hashicorp, the lawyers have been sic'd on them! That is not adult behavior. It shows a great naivety in business affairs ...