They really didn&#x27;t. They changed it to prevent companies from building commercial products around terraform, which is what you&#x27;ve suggested as a cloud protection license.Companies that use terraform to manage their infrastructure are not practically impacted in any way, except by this OpenTF effort (which I don&#x27;t personally oppose either!) which will create a schism and leave us with competing tools that are not quite interoperable over time (thinking about ZFS&#x2F;OpenZFS, MySQL&#x2F;MariaDB, etc.).<a href="https:&#x2F;&#x2F;www.hashicorp.com&#x2F;license-faq#usage-limitations" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.hashicorp.com&#x2F;license-faq#usage-limitations</a>It isn&#x27;t the AGPL, but I am just sort of stunned at the uproar around this. Is Hashicorp supposed to just shrug and clap while a competitor takes (primarily) their work and competes with them using it? That&#x27;s what the MPL allows, and they don&#x27;t want to do that anymore, so they... changed the license to protect their interests. What do you expect them to do?

There is no such thing as an open source license that prevents others from doing something specific with the software, that&#x27;s basically the point of open source.

Yes. Worse than that, they changed to a license that prevents companies to use their product freely - if they chose some &quot;cloud protection license&quot; that simply handicaps possible competitors to their commercial offwrings, this fork would probably not happen, or at least it wouldn&#x27;t have such momentum.

IMHO Hashi TF is the fork since they changed the license to a non-open source one.OpenTF is the same MPL license under a different name.

Expect the repository to be published very soon, once we’re officially part of a foundation and have some basic community guardrails and processes in place.

Big supporter in this move! When can we use it?

env0 founder here - we are honored to collaborate on bringing OpenTF to the world together with our friends and backed by a massive support of the community.#opentf

Digger hereThe future of Terraform is open-sourceWe are beyond excited to be part of this great initiative. We did of course expect a fork to be of significant interest to people; what we did not expect is this crazy level of support for it. 2k+ stars, 100+ companies and 400+ individuals pledged, and there is already more full-time engineering positions committed to it by pledging companies than the whole Terraform Core team at Hashicorp (source: terraform commit history)

There’s parallels but it’s not the same. Red Hat’s projects are still all fully open source. And it’s not clear it’s a mistake yet.(I work for red hat but this is my personal opinion).

Seeing OpenTF on the CNCF website would be glorious. TF has become too ingrained in the cloud operating model, CNCF is where it belongs. Maybe a Vault fork will join it someday.Will HashiCorp remain relevant throughout this? Seeing a lot of parallels with Red Hat&#x27;s recent mistake...

Personally speaking, I wish it had been OpenInfra.I think they have a stronger sense of community building, and more more intentionally make space for individuals to take leadership roles that are truly independent from their employer (member company) affiliations.

Is there a general guide about popular OSS foundations and what kinds of projects are a good fit for each? What&#x27;s your general feel on that?

I agree. I have been outspoken in my criticism of the LF -- but I would like to think that I have been fair as well, calling out cases where they are the right fit for a project. And in this case, for myriad reasons, they are indeed the right fit. Kudos to the OpenTF crew -- we loved speaking with some of them on Monday[0], and left enthusiastic for the future of OpenTF![0] <a href="https:&#x2F;&#x2F;oxide-and-friends.transistor.fm&#x2F;episodes&#x2F;fork-in-the-road-for-terraform" rel="nofollow noreferrer">https:&#x2F;&#x2F;oxide-and-friends.transistor.fm&#x2F;episodes&#x2F;fork-in-the...</a>

The CNCF has made exceptions on their license policy before, specifically for MPL based software. It&#x27;ll probably be easier for OpenTF to go through that process than to relicense (which is likely not even possible for anyone other than Hashicorp).- <a href="https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;foundation&#x2F;tree&#x2F;main&#x2F;license-exceptions">https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;foundation&#x2F;tree&#x2F;main&#x2F;license-excepti...</a>- <a href="https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;foundation&#x2F;blob&#x2F;main&#x2F;license-exceptions&#x2F;cncf-exceptions-2023-06-27.json">https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;foundation&#x2F;blob&#x2F;main&#x2F;license-excepti...</a>

Terraform was (and I assume currently, OpenTF) under an MPL license, which is not currently compatible with the approved licenses that the CNCF supports: <a href="https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;foundation&#x2F;blob&#x2F;main&#x2F;allowed-third-party-license-policy.md">https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;foundation&#x2F;blob&#x2F;main&#x2F;allowed-third-p...</a>For them to get accepted into the CNCF would require relicensing a large amount of MPL work. What&#x27;s always been confusing to me about Hashicorp&#x27;s change and any subsequent relicense of OpenTF is that I know for a fact not everyone who contributed code to Terraform signed the CLA and allowed permission to relicense.I suspect if OpenTF tries to relicense to a more permissive license like Apache 2 (rather than less in the case of BSL) license we might see some fireworks.

It is in the very article this thread is about

Can you please share a link to the reference for the quote about transferring OpenTF to CNCF?Moving OpenTF to CNCF is a great approach. It will be helpful to be able to share this news.

What would you see as the benefits of them joining CNCF?

&gt; We completed all documents required for OpenTF to become part of the Linux Foundation with the end goal of having OpenTF as part of Cloud Native Computing FoundationImho the best possible choice, and one that was easy to see coming when they announced they were joining &quot;an existing foundation&quot;.

I think this should be addressed sooner rather than later. A lot of core plugins (e.g. AWS) are written by HashiCorp themselves and the license could be changed at any time, putting OpenTF users in danger of violating the license. Furthermore, to publish a provider one needs a HashiCorp account and agree to their Terms of Service.

No immediate change with regards to how the plugins are handled. Longer term I think the entire plugin ecosystem could benefit from less centralized control, in the interest of all other projects that depend on it (eg. Pulumi, Crossplane etc). As OpenTF we are already working with other parties interested in keeping the ecosystem in good shape. But for now there&#x27;s no change necessary, since the TF registry seems itself to just be a lightweight proxy to GitHub Packages, they don&#x27;t seem to host anything themselves.(Marcin, co-founder of Spacelift, and one of the members of the OpenTF initiative)

While learning Pulumi AWSx and TypeScript I created a proxy server for AWS Lambda [0]. As part of Spacelift we also have a private provider registry and I&#x27;m happy to turn some of that code into an equivalent open source proxy in Go.[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;spacelift-io&#x2F;github.packages.tf">https:&#x2F;&#x2F;github.com&#x2F;spacelift-io&#x2F;github.packages.tf</a>

The registry protocol is documented and pretty straightforward to implement (source: I implemented a private TF provider registry as static files in S3 at a past gig), and Terraform has config settings to easily point to alternative sources for plugins, so mirroring the plugin distribution should be pretty simple.

First of all, congratulations, I hope OpenTF will live and prosper, I really liked Terraform when I was working with it.I&#x27;m wondering how OpenTF will handle the plugins. Will it pull from HashiCorps servers, or will it spin up its own plugin registry? If the latter, will the existing plugins be mirrored?

I&#x27;ll join the other members of the OpenTF Initiative who&#x27;ve already commented - I&#x27;m honoured to be a part of this effort and can&#x27;t wait for us to push this forward in the following days, weeks, months, and years! It&#x27;s been a pleasure working with everybody from all the companies involved.Happy to answer any questions you might have!Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it&#x27;s committee-steered.

You are entirely right; it&#x27;s nowhere comparable. I&#x27;m just talking about the theoretical impacts. (after all, the re-licencing was also a theoretical problem, i.e. Hashicorp might abuse the non-compete clause so Terraform is not safe to use) I just find it interesting to mention - after all, the important details the ones which are not talked about.

&gt; signing a CLA with The Linux Foundation, Eclipse, ASF etc.what is the reason those require CLA? Why underlying license is not enough?

For what it&#x27;s worth, the CNCF is not big on CLAs in general although, as far as I know, they don&#x27;t specifically prohibit them. In general, they prefer to use a developer certificate of origin.

Yeah this makes sense. &quot;CLAs (or DCOs) assigning copyright to foundations are good, CLAs assigning copyright to corporate entities are questionable&quot; does seem like a pretty good rule of thumb for contributors who care about this kind of thing (which I agree most people should).

You are technically correct but I do see a difference between signing a CLA with The Linux Foundation, Eclipse, ASF etc. and a purely commercial corporate entity.

Companies saying &quot;we will let some FTEs contribute to this project along with their regular work&quot; is very different from Amazon paying a dedicated team to work on it full time.

They&#x27;ve already got more FTEs on this than Amazon seemingly put on OpenSearch.

It’s a bit different because OpenSearch is a project of and by Amazon, not a project where many companies participate equally under a foundation.

If they aim for making it a CNCF project, it may very well be a simple inbound=outbound licensing (everyone keeps their copyrights). The CNCF gives projects two options: DCO or CLA, where the CLA is a very simple formality. It being a foundation and not a for-profit company already makes licensing shenanigans unlikely.

Ideally we would want to let people contribute freely without the need to sign anything extra. However, for the exact process we will defer to the Linux Foundation &#x2F; CNCF. The ultimate goal is to ensure that a rug pull like this is never allowed to happen again.(Marcin here, co-founder of Spacelift, one of the members of the OpenTF initiative)

This kind of trolling can easily be prevented by saying &quot;Sure, we will remove your contributions. Name the exact line numbers affected&quot;

&gt; Because any single contributor can claim at any point in the future that the project is using their code illegallySo, you&#x27;ve never heard of a Developer Certificate of Origin? If it&#x27;s good enough for Linux, it&#x27;s good enough for me.

&gt; Every open source project should make its contributors sign CLAsWhat&#x27;s the point of open source if you have to reveal you real identity?

CLAs are very misunderstood in the software industry. Every open source project should make its contributors sign CLAs, and you should be wary of using one that doesn&#x27;t. Why? Because any single contributor can claim at any point in the future that the project is using their code illegally, and that you&#x2F;your company should pay them for using their proprietary IP for all of these years. Can you prove that you audited every single line in the project you used and were sure of its copyright status? A CLA ensures exactly that. There&#x27;s a reason why Linux Foundation, Apache, CNCF, Mozilla, heck even FSF all have strict CLA requirements.Relicensing is a completely separate conversation, and there are plenty of open source CLAs which don&#x27;t have that provision.

I am seeing parallels to the Amazon vs. ElasticSearch fiasco.Also interesting to mention that they haven&#x27;t said a single word about CLAs. If this project would require a CLA (and copyright assignment) to contribute, then it doesn&#x27;t matter that it&#x27;s a foundation, they could also re-licence it easily, which is exactly what they are fighting against.

Credential leases will be available in Infisical soon!Disclaimer: I&#x27;m one of the founders.

I am hoping someone will take on Vault since it really has a unique perspective on credential leases that I don&#x27;t believe its competitors currently tackleI have been trying to help <a href="https:&#x2F;&#x2F;github.com&#x2F;vaagrunt&#x2F;vagrunt">https:&#x2F;&#x2F;github.com&#x2F;vaagrunt&#x2F;vagrunt</a> but there are 4400 forks so it&#x27;s hard to know if one of the other ones is getting &quot;community buy in&quot; - I just saw that one in another HN thread and tried to help out (it&#x27;s always bugged me that there was no $(make dist) for Vagrant so hopefully here&#x27;s my ability to fix that bug since Hashicorp was for damn sure never going to accept any such PR)

Do similar initiatives exist for the other HashiCorp products?

It’s a traumatic birth for sure- but I think in the long run Hashicorp took the right approach. There’s already more FTE commitments from the community than Hashicorp actually had working on it.

Kind of like Hashicorp has done so far for everyone non-corporate.

Right, suddenly someone&#x27;s doing the work for them and for &quot;free&quot;.

Marcin here, co-founder of Spacelift, one of the members of the OpenTF initiativeAs a long-term HashiCorp fanboy, and a true fan of the work of Mitchell this would be my dream come true, on a very personal level. It would also be a great day for the entire community.

Ohad co-founder of env0 here, early supporter in the OpenTF initiative.
TFE and TFC have a future. Competition is good for everybody. It forces innovation. 
However, only OpenTF will make sure to properly differentiate between the OSS layer and the commercial layer.

I don&#x27;t think there is a future for TFE in the face of OpenTF.  It&#x27;s a dumb Terraform runner, the competition has far more features and integrations with other tools.   The BSL was HashiCorps way to curtail competitors and it has backfired spectacularly.

Can they do that without reverting their own license back to MPL?

I wonder how long until Hashicorp starts to use OpenTF as the upstream for TFE

&gt; currently temporary Technical Lead of the OpenTF ProjectAssuming you aren&#x27;t committing under pseudonyms, you&#x27;ve to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).

Do you have an idea on where you stand on incompatible changes that are strict improvements over TF? As a concrete example, <a href="https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;terraform&#x2F;issues&#x2F;13022">https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;terraform&#x2F;issues&#x2F;13022</a> - My only read on this is that Hashicorp arent doing this as this removes a key selling point of Terraform Cloud.

Initially we strive for 100% interoperability.The provider framework has been kept MPL, as have the providers, so we will keep being compatible.We will see what the longer-term future brings, and we&#x27;ll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it&#x27;s in place.Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it&#x27;s committee-steered.

Right, but lets be honest, I don&#x27;t care about 1995 of those providers. Nobody is using Terraform to manage spotify playlists [0]. The big ones are what matter, and (and HashiCorp manage the big ones)[0] <a href="https:&#x2F;&#x2F;registry.terraform.io&#x2F;providers&#x2F;conradludgate&#x2F;spotify&#x2F;latest&#x2F;docs" rel="nofollow noreferrer">https:&#x2F;&#x2F;registry.terraform.io&#x2F;providers&#x2F;conradludgate&#x2F;spotif...</a>

Except Hashicorp has already done something similar recently i.e. <a href="https:&#x2F;&#x2F;developer.hashicorp.com&#x2F;terraform&#x2F;plugin&#x2F;framework&#x2F;migrating" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.hashicorp.com&#x2F;terraform&#x2F;plugin&#x2F;framework&#x2F;m...</a>So they can always do it again...

HashiCorp manages a handful (~4 [0]) of the providers, while over 2,000 are managed by the community. I suspect breaking the interface would be further damaging to their reputation. The clouds will also have some influence around their provider.[0]: <a href="https:&#x2F;&#x2F;registry.terraform.io&#x2F;browse&#x2F;providers?tier=official" rel="nofollow noreferrer">https:&#x2F;&#x2F;registry.terraform.io&#x2F;browse&#x2F;providers?tier=official</a>

It would be stupid cat-and-mouse game because it would make all previous versions of legacy Terraform irrelevant, and is unlikely to cause much harm in the long run because the same protocols can be implemented by other tools.

They already did do a Terraform, SDKv2 to plugin framework migration thing earlier [0] so why not again?[0]: <a href="https:&#x2F;&#x2F;developer.hashicorp.com&#x2F;terraform&#x2F;plugin&#x2F;framework&#x2F;migrating" rel="nofollow noreferrer">https:&#x2F;&#x2F;developer.hashicorp.com&#x2F;terraform&#x2F;plugin&#x2F;framework&#x2F;m...</a>

Is Hashicorp were to change Terraform protocols without extremely good justification, the project would be dead immediately. The existence of Terraform in its current state is bringing billions in revenue to vendors like AWS and GCP. There&#x27;s a lot of money at play. Hashicorp wouldn&#x27;t risk that.

If they do, they likely have to give plenty of notice due to third party providers, and will still have to maintain the old protocol&#x2F;a for older versions of all the providers.

How will providers be handled? If Terraform changes the protocols and interfaces it sounds like a game of cat and mouse.The providers will support Terraform and update to the latest framework, which may be incompatible with OpenTF at the time. Are we forking those too?

I&#x27;d really love to see this continued for some of the other hashicorp tools that have taken the turn to closed licensing. Vault is at the top of my list, but definitely some others like consul and vagrant seem like they have healthy communities that have been responsible for making hashicorp products successful, and stand to lose out with the whole switch part of this post-facto bait+switch.

&gt; &quot;HashiCorp even had all contributors sign a CLAOf course, this is untrue. They may have had all contributors after some specific date sign one, but it is simply untrue that all contributors have signed one at all.

Oh come now, that’s a stretch.In the announcement literally the only mention of this is:&gt; The manifesto outlined the intent of the OpenTF initiative in two steps — the first was to appeal to HashiCorp to return Terraform to the community and revert the license change they were making for this project. The second, in case the license was not reverted, was to fork the Terraform project as OpenTF.&gt; Since no reversal has been done, and no intent to do one has been communicated, we’re proud to announce that we have created a fork of Terraform called OpenTF.What you’ve quoted and linked to is the manifesto before this announcement.They could have played the announcement much differently to how they did, but they chose not to, and chose to focus on the positives instead.It’s not even in the announcement faq.&gt; they could&#x27;ve left out all the judging side comments.That is literally what they did.I imagine the manifesto will disappear now that it is, obviously, superseded.Just give it a tiny bit of time, yeah? Come on, what they’re doing seems like good work, well played and without nastiness.

Can anyone fork and change the license? I assume yes if originally MIT or similar.I wish it were not the case. It should be more like contributors get paid like employees retroactively in a situation like this but no idea how something could be structured like this.

&gt; They could be focusing on the licence and their perception of HashicorpThey literally do:&quot;HashiCorp even had all contributors sign a CLA which explicitly said (link to the CLA in the Internet Archive as HashiCorp has of course removed this wording): [...]The move to BUSL—which is not a free and open source license—broke the implicit contract. That was the brash action!Terraform would&#x27;ve never gotten the adoption it did, or all the contributions from the community had it not been open source. Most of us would&#x27;ve never agreed to the CLA to contribute to the project if it was BUSL licensed. Taking all those contributions and all that community trust, and then changing to the BUSL license is a bait and switch.&quot; [1]I agree with the overall sentiment, but they could&#x27;ve left out all the judging side comments.[1] Source: <a href="https:&#x2F;&#x2F;opentf.org&#x2F;#why-fork" rel="nofollow noreferrer">https:&#x2F;&#x2F;opentf.org&#x2F;#why-fork</a>

For anyone also wondering, that last quote is from here: <a href="https:&#x2F;&#x2F;opentf.org&#x2F;#why-fork" rel="nofollow noreferrer">https:&#x2F;&#x2F;opentf.org&#x2F;#why-fork</a>

I prefer reasonable business decisions that support open source software over companies baiting and switching.If Hashicorp didn’t have a business plan that made money off terraform being OSS then the time for that was years ago.If you release as OSS then your competitors will use it to. This is predictable and all plans should account for it.This competition didn’t hurt Hashicorps chances of profitability, they were factored in from the beginning.

&gt; It makes sense they&#x27;d do this, but we need to stop loving people who appear to give us things. They&#x27;re just making reasonable business decisions.I don&#x27;t see OP talking about &#x27;loving people&#x27;. Just stating that a very good approach was taken. Wrt &#x27;give us things&#x27;, it is not about giving either (that&#x27;s like free beer), but about freedom. If OpenTF indeed ends up under Linux Foundation &#x2F; CNCF it doesn&#x27;t matter how many competitors are involved, but that freedoms are assured.

env0 founder here, direct competition of Terraform Cloud, and core member in the OpenTF initiative. Thank you for your note. I wanted to mention that indeed env0 enjoyed Terraform being free, but also contributed back to the Terraform ecosystem, with github.com&#x2F;env0&#x2F;terratag OSS and TheIaCPodcast.com for education.
Also important to mention another and probably a more important key member in the OpenTF initiative - Gruntwork, creators of Terragrunt and Terratest. I believe we all contributed nicely to the community. Just my 2 cents, in order to add a bit more context to &quot;companies who make money from Terraform being free&quot;.

Yeah. I don’t really love that companies exploited something hashicorp gave away for free, then play good when they finally have to commit to the ecosystem when hashicorp takes it away.Where was this support when they built a business on this free work?

Is it a reasonable business decision to compete with a large and enthusiastic open source community though?

It&#x27;s support from companies who make money from Terraform being free, and at least one looked like a direct Terraform Cloud competitor that probably hurt Hashicorp&#x27;s chances of making Terraform profitable.It makes sense they&#x27;d do this, but we need to stop loving people who appear to give us things. They&#x27;re just making reasonable business decisions.

We actually specifically don&#x27;t want this to be our employees. Rather, we want the foundation to employ the maintainers (whom we&#x27;ll pay for). Which is partially because of the bad incentives the former approach creates.Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it&#x27;s committee-steered.

env0 founder here. env0 raised $42M (from investors such as Microsoft) and growing fast. We are honored to support OpenTF and already assigned 5 engineers (you will see the usernames in the opentf GitHub repo once that become public).

I am sceptical that 14 - 28 FTE will be dedicated to openTF. If I was to guess it is 14-28 people working on their companies offering and when needed upstreaming bug fixes and features, PR reviewenv0 a small Company is providing 5 FTE, the web claims their revenue is &lt;5m (1.4m)

I&#x27;m thrilled to see that OpenTF appears to be aiming to win on positives, not negatives.&quot;Culture eats strategy for breakfast.&quot; -- Peter Drucker

I&#x27;m thrilled to see that OpenTF appears to be aiming to win on positives, not negatives. They could be focusing on the licence and their perception of Hashicorp, but instead there&#x27;s a lot of emphasis on the positive: getting up and running quickly, upcoming releases, public roadmap, and pledges of engineering work.In the long run few will care about this licencing change (as much as they should!) – business users will accept it, individuals won&#x27;t take any notice, and competitors would get mired in issues as expected. Basically a win for Hashicorp.But winning on positive changes beats licencing issues. Business users will go where the centre of gravity in the ecosystem is, individuals will too, and will prefer free (in both senses) solutions, and competitors will push this hard to all their customers. It&#x27;ll be interesting to see Hashicorp needing to build OpenTF support into their products to remain compatible.&gt; So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository.Wow. Even if most of this doesn&#x27;t actually play out in the long run, that&#x27;s some good support.

Thank you, we appreciate your words! We’ll do our best to make sure if you have to migrate, it’s just a binary change.

Well done all! I&#x27;m really excited to see the community taking ownership of this tool and moving it to a foundation.I&#x27;ll definitely be using OpenTF for any future projects and if I find myself a part of or leading a DevOps team again, will work to migrate that team over.

Massdriver co-founder here.We are super excited to be supporting this initiative. The community around Terraform has been pushed aside for too long.Terraform is the most widely adopted tool for managing cloud infrastructure. Putting it in the hands of a foundation that can ensure it remains open-source, community-driven, and impartial is crucial to so many infrastructure and operations teams around the globe.

We need to raise awareness about this fork so people know about, join in, and support the move. Share it with your friends and co-workers. Upvote or star everything you can. Let&#x27;s push this forward people!

At minimum:- Spacelift- env0- DiggerPulumi is not targeted, since the licenses of the providers are not changed.

Nobody&#x27;s entirely sure, which is a problem.

From the Hashicorp post: &quot;Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.&quot;What vendors is the post referring to?

That&#x27;s very nice to hear, thanks!(even though I wish there was some breaking changes to be able to fix some of nasty bugs that have been there for years ahah)

I think that&#x27;s a good goal, but it seems pretty out of your hands.  After your first addition to the language or state file (which by the sound of it is something you hope to do soon, and I applaud that), TF could immediately introduce something making compatibility impossible without you reverting and breaking the feature.

We have the tooling in place to ensure full equivalence of the most important parts, especially the statefile. We will also take great care to not introduce DSL changes that would make it hard to switch back and forth between OpenTF and the legacy Terraform. Looking at the codebase for the last week, and the list of PRs on the original repo ignored to oblivion I believe there&#x27;s a lot of space for innovation that does not break the interop guarantee.[Marcin, co-founder of Spacelift, one of the members of the OpenTF initiative]

That&#x27;s great news. I wonder what will happen to ongoing roadmap and all the bug&#x2F;feature requests that were pending.I fear that sooner or later the APIs will become non-compatible so the only &quot;good move&quot; would be to jump to OpenTF as soon as possible to avoid complication. But for entreprise it will be a tough jump: updating all tooling, scripts, deployment flows, CI, compliance check, etc.

&gt; very smart people at the helmHear, hear. We would love to see them join forces with OpenTF.

Was thinking the same. Would be great if they provided more &quot;experimental&quot; features with a flag or ENV. Then the default cli could be the &quot;comparability mode&quot;. Cheers and good luck to the project!

People could have forked terraform before too.It’s being forked only now because there is big money at stake.I’m gonna wear my cynical hat and say: it never was about collaboration.Seriously: people are falling for the collaboration meme. Isn’t anybody wondering “why now?”Why not a year ago, why not a year in the future?

One has to wonder how much collaboration was prevented by having Hashicorp refuse to hear their users or accept PRs. At some point, opensource or not, people just stop bothering.

If the maintainers can keep a good throughout of pull request approvals, I think there’s a good likelihood that OpenTF could outpace Terraform in capability. Terraform, IMO, has benefitted significantly from having some very smart people at the helm. Most recently I’ve been impressed with the declarative mapping of imperative actions including import, state moves, and more. These things required very carefully coordination, especially in large active configurations, and are now quite simple and safe.

Not to be confused with related but different “OTF” which is the open source version of Terraform Enterprise:<a href="https:&#x2F;&#x2F;github.com&#x2F;leg100&#x2F;otf">https:&#x2F;&#x2F;github.com&#x2F;leg100&#x2F;otf</a>
<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34536663">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34536663</a>

I can&#x27;t imagine how much you all have on your plates right now, so this can definitely wait.Tools, frameworks, etc all have to be written by people, and I&#x27;m sure you&#x27;re already keenly aware that poor programmer tooling can be the death of a project.This is definitely selfish on my part since I write a lot of Terraform and lean on the language server a lot, but I hope that terraform-ls can have a couple of people dedicated to it eventually.Unfortunately (of course!!) my own pet issues are pretty niche, since I expect there aren&#x27;t many people using a lot of private registry modules like the client I work for. Hence my desire to fix it myself :)

Marcin here, one of the OpenTF folksThis repo [0] seems to still be licensed under MPL, so there is no need for an immediate action, but if there is a willingness in the community to take it over and improve, I see no reason why we wouldn&#x27;t do it.[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;terraform-ls">https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;terraform-ls</a>

I’d call that a bit of a stretch. Python can have full blown OOP, even multiple inheritance. It can be very functional (decorators are used a lot). It’s interpreted, not compiled. It has tons of syntax sugar. Properties, context managers are very Pythonic. Async also works entirely differently. Multi threading with channels is not really a thing in Python. Neither are interfaces (abstract base classes come close though). Python can have impressively expressive type systems nowadays, with mypy and typing. Generics, paramspecs and whatnot. Go is much more rigid in that regard.

Python translates really well into Go.  You could probably learn both at the same time

Learn both, you will eventually have to anyway, and it won&#x27;t hurt your learning curve, in fact will probably help to see similar ideas implemented and expressed very differently.

I ain’t changing the license for mine(so it will stay the same license)

I mostly agree, but subtle thing is that GP is &quot;learning&quot; Python.  I don&#x27;t think they know yet if they can handle it

If you can handle Python, you will have no issue with Go, which is overall a simpler language.

Regarding the Language Server, terraform-ls: does anyone know if that will also be forked?Gah, this is frustrating! I am learning Python but TF and tf-ls are written in Go. I need to figure out how best to contribute.

We&#x27;re still in the first inning. A little too soon to declare victory IMHO. They&#x27;re moat hasn&#x27;t even been tested yet. Adoption is what actually matters. FTE commitments will disappear quickly if the project isn&#x27;t able to get adoption.Also I know Hashicorp has a good moat (how good we don&#x27;t know yet). Some very big companies pay Hashicorp and there&#x27;s no way they&#x27;re going to leave for opentf anytime soon. The support alone is plenty valuable enough to keep them there.

Seems like the inevitable conclusion. I reckon hashicorp overestimated how much of a moat they have.

Recently I (new to it myself) introduced Terraform on my team at work (my department historically mostly uses CloudFormation), and this whole license rug pull left me wondering if I&#x27;d made a mistake.But if OpenTF really flourishes, this could end up being better for us than if the license change had never happened. I wish you guys the best in making OpenTF a clear winner! The sooner that happens, the less of a shakeup this will be for the whole userbase and the more teams will stay invested and stick with terraform-the-technology (if not the trademark). I&#x27;m optimistic. :)

Thanks, that&#x27;s really appreciated.One thing that is always unclear with company-owned projects is what is exactly going against their business plans so you don&#x27;t waste time preparing a PR only to get half-baked excuses about why it can&#x27;t be accepted.Point in case, the numerous PR&#x27;s and issues to disable warning coalescing in Terraform that are always met with a dismissal but nobody understands why.

How do you plan to deal with changes that will break compatibility with TF?

May I suggest a working group on stateless Terraform? [1] or at least some debate around the possibility of supporting it?[1] <a href="https:&#x2F;&#x2F;www.bejarano.io&#x2F;terraform-stateless&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.bejarano.io&#x2F;terraform-stateless&#x2F;</a>

Yup. This is very much what we intend to do.

Excellent. I&#x27;ve made and supported sevreral PRs in the past and they all seem to just drift around for so long

Our first two issue templates on github are for exactly this! Please add any that are particularly important to you or your team!<a href="https:&#x2F;&#x2F;github.com&#x2F;opentffoundation&#x2F;roadmap&#x2F;issues&#x2F;new&#x2F;choose">https:&#x2F;&#x2F;github.com&#x2F;opentffoundation&#x2F;roadmap&#x2F;issues&#x2F;new&#x2F;choos...</a>

+1. Stale PRs, also communicate and welcome feature requests or bug fixes that may exist across SO and other channels -- TF-scoped, but perhaps even HCL (if possible) or HCL-adjacent libraries.

&gt; Community-driven - so that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit and changes are proposed through a public RFC processIMO if OpenTF wants to quickly pull ahead, they&#x27;d do well to quickly revive popular but neglected PRs from Terraform, inviting those authors to rebase on top of OpenTF and quickly getting them merged.The RFC process will slow them down here, at least for features, but presumably there are still old bug fixes that died on the vine, too.

Welcome aboard to LF and thank you for making my life easier[0]!0: <a href="https:&#x2F;&#x2F;github.com&#x2F;hyperledger&#x2F;toc&#x2F;issues&#x2F;151">https:&#x2F;&#x2F;github.com&#x2F;hyperledger&#x2F;toc&#x2F;issues&#x2F;151</a>!

I&#x27;m guessing their application to the CNCF Sandbox is either planned or in review. It&#x27;s only been 10 days, after all.

Thanks, can you share more details? E.g. are there more reviews, more paperwork required, etc?

The CNCF process takes a bit longer and CNCF is part of the LF anyway. The project governance can benefit from being part of a reputable foundation as soon as practicable.(Marcin here, one of the OpenTF folks)

&gt; We completed all documents required for OpenTF to become part of the Linux Foundation with the end goal of having OpenTF as part of Cloud Native Computing Foundation.Anyone know why this was done in this order? Why not apply for CNCF right from the get-go?

Some of the OpenTF team joined us on Oxide and Friends to talk about the project. It was a great conversation:<a href="https:&#x2F;&#x2F;oxide-and-friends.transistor.fm&#x2F;episodes&#x2F;fork-in-the-road-for-terraform" rel="nofollow noreferrer">https:&#x2F;&#x2F;oxide-and-friends.transistor.fm&#x2F;episodes&#x2F;fork-in-the...</a>

“Fork of Terraform” sounds like an item in a Mars settlers RPG. ;)

Linked page and the root page of the domain lack any explanation of what OpenTF and Terraform are. That should be right at the top of the page.

I was just a kid when Sun died, reading about all the drama of the buyout and the series of forks on Slashdot whenever I had already finished my work in my high school computer science class every morning.I didn&#x27;t really know what or how to think about the mismanagement aspect of it, but I was already a F&#x2F;OSS enthusiast by that time. I ran Linux at home and used free software everywhere I could. I even eschewed Times New Roman in favor of Linux Libertine (then the font of the W in the Wikipedia logo!) for my school essays because I didn&#x27;t want to support the hegemony of a proprietary typeface.What I did understand about Sun was that they had been the caretakers (and sometimes creators) of some of the most important and beloved technology I&#x27;d ever used. I didn&#x27;t know anything about Solaris, Hudson, ZFS or SPARC, but I knew Sun for VirtualBox, OpenOffice, the MySQL database system that seemed to be everywhere in the open-source world, and the Java programming language I was writing in for school.I remember a sense that something precious had died with that buyout, even though I didn&#x27;t understand what led up to it. I worried a lot about OpenOffice, which I relied on and advocated to friends, and I practically cheered when I read about the formation of The Document Foundation and LibreOffice.

TF&#x27;s excellent plugin ecosystem that is not owned by Hashicorp will teach them a bitter lesson.

Yes. Sun became all about extracting rents from vendor lock-in (SPARC, J2ME, SUN DS, etc.). But Sun couldn&#x27;t maintain that vendor lock-in, so Sun went under. Management just did not or would not see this, much less act on it. OpenSolaris was a good initiative for rebuilding mind-share, but it was a bit too little too late.But the biggest mistakes Sun made were made in 2002-2004, and they never recovered:<pre><code> - the Solaris on x86 &quot;cancellation&quot; (it
 was more putting it on hold, maybe, but
 the market took it as a cancellation)
 - not making a deal with Google for Google
 to use Solaris in their data centers
 - killing off Sun PS (professions services)
</code></pre>
The Solaris on x86 &quot;cancellation&quot; killed a lot of mind-share. No one wanted to get locked-in to SPARC.Making a deal with Google would have reinvigorated Solaris&#x27; mind-share at a critical time.IBM did the opposite of killing off its professional services division. IBM killed off their x86 systems division and beefed up its PS, and IBM went on to make a killing on PS.The vendor lock-in issues totally compounded these terrible decisions.After 2002 Sun was always on the back foot.

Sun is a great example of a company that had excellent engineers but a terrible business model. Instead of fixing the business model, they tried to extract as much value out what they had and it ultimately lead to the death of the company.Terraform is the gateway to Hashicorp and it feels like they&#x27;re going to lose it.

I&#x27;m sure that was an especially painful change, being such a gratuitously stingy and shortsighted treatment of a dear and painstakingly refined core technology project.My point with that observation about licensing was just that in many cases, it didn&#x27;t even take something as drastic as a license change to get a project superseded by a community fork. Just changing the release process or removing some community maintainers&#x27; commit bits or whatever could be enough.Maybe some of that was because seeing what was done to OpenSolaris made everyone else ready to jump right away as soon as they saw any shift at all in other projects, though.

First time caller, long time listener:You have a blog too! Hurrah! I celebrate your entire catalog. If you start another podcast, please be sure to mention it on oxide and friends. It was crickets over there in the &quot;On the Metal&quot; podcast, but when you guys made that last episode I had 2 years of oxide &amp; friends, so perhaps that was ok.

They definitely changed one of the licenses, and in fact in the most brazen way possible -- they relicensed OpenSolaris to proprietary![0][1] Your point stands, though: illumos very much outpaced and outlived it.[2][0] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-zRN7XLCRhc">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-zRN7XLCRhc</a>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Zpnncakrelk">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Zpnncakrelk</a>[2] <a href="http:&#x2F;&#x2F;dtrace.org&#x2F;blogs&#x2F;bmc&#x2F;2017&#x2F;09&#x2F;04&#x2F;the-sudden-death-and-eternal-life-of-solaris&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;dtrace.org&#x2F;blogs&#x2F;bmc&#x2F;2017&#x2F;09&#x2F;04&#x2F;the-sudden-death-and-...</a>

And arguably MySQL does better than Mariadb nowadays.

It&#x27;s somewhat ironic though, that the license adopted by Hashicorp, the BSL, originates from MariaDB, which is the no-oracle successor to MySQL.

I think the only thing that wasn&#x27;t forked off from the Sun deal was VirtualBox, mainly because Oracle never cared much about it and it&#x27;s still open source, and partly because the container revolution was already brewing.

When Oracle bought Sun, there were a number of open-source projects they started fencing off and developing in a less community-oriented way. Usually, I think they didn&#x27;t even actually change the licenses.In every case I can remember, the community-centric forks outpaced or altogether outlived them. Hudson is dead. OpenOffice is basically irrelevant. Oracle ZFS sees little interest and is not what anyone thinks of when they hear &#x27;ZFS&#x27;. But Jenkins, LibreOffice, and OpenZFS are all going strong many years later.This could end up being a really good thing for Terraform users, would-be contributors, and Terraform itself as a technology. I wonder if any Terraform maintainers from HashiCorp itself will jump ship to work on it full time as OpenTF. A similar phenomenon ended up being a decisive factor with the post-Oracle forks of Sun software IIRC.

Looks like &quot;open-tf&quot; is available as well. That&#x27;d be even better!As an added benefit, shorter names add a sense of legitimacy to new projects.

Why oh why didn’t they add a dash to the GitHub org name? Is it too late to fix that or will be squinting at the repo owner for years to come?<pre><code> opentffoundation
</code></pre>
vs<pre><code> open-tf-foundation</code></pre>

Out of curiosity, what do you mean by this? cross-cluster? they already have HA: <a href="https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;vault&#x2F;blob&#x2F;v1.14.1&#x2F;website&#x2F;content&#x2F;docs&#x2F;internals&#x2F;high-availability.mdx">https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;vault&#x2F;blob&#x2F;v1.14.1&#x2F;website&#x2F;cont...</a>while digging up that link, I also saw one named replication: <a href="https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;vault&#x2F;blob&#x2F;v1.14.1&#x2F;website&#x2F;content&#x2F;docs&#x2F;configuration&#x2F;replication.mdx">https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;vault&#x2F;blob&#x2F;v1.14.1&#x2F;website&#x2F;cont...</a>

Especially if the Vault fork implements things like replication.

Here&#x27;s hoping other HashiCorp products go the same way, creating an excellent new suite of truly OSS cloud tools. HashiCorp shot themselves in the foot, but they may have accidentally benefitted the FOSS community greatly.

Agreed. This will probably end up being a net positive for the Terraform &#x27;concept&#x27; and its relatives like e.g. Pulumi.

&gt; My attempts to submit Pull Requests for much wanted features (fully working documentation with new integration tests all passing) often took months-a year to be accepted and merged.Isn&#x27;t this always going to be the case?Honestly, are you signing up to maintain the feature long-term? Fix bugs? Update documentation? Review PRs with small changes to the feature?The cost of accepting a PR can be much higher than the cost of creating the PR.Even if you promise to maintain it! What if you don&#x27;t? What recourse does the maintainers have?
They can&#x27;t just remove your feature, since customers started using it and you don&#x27;t want to announce breaking changes and scare everybody.If you&#x27;re building an open source product with lots of users, where compatibility is important. Then accepting a PR is a huge liability, you&#x27;ll always want to be extremely conservative about it.A PR is not always a gift, regardless of innocent it looks.

I&#x27;m hopeful on this news. Terraform has become the standard in the industry, but incentives weren&#x27;t quite aligned. My attempts to submit Pull Requests for much wanted features (fully working documentation with new integration tests all passing) often took months-a year to be accepted and merged.Hashicorp engineers were incentivized to work on features related to Hashicorp paid services, and Hashicorp competitors who would similarly benefit from a stronger Terraform codebase were disincentivized from potentially helping Hashicorp.

It was invented by MariaDB and later adopted by CockroachDB, etc. It basically says &quot;you can&#x27;t compete with us&quot;<a href="https:&#x2F;&#x2F;mariadb.com&#x2F;bsl-faq-adopting&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;mariadb.com&#x2F;bsl-faq-adopting&#x2F;</a>

Why is BSL primarily designed for databases? I thought it was just &quot;GPL 4 years after release&quot; sort of thing which seems pretty reasonable to me tbh.

I think HashiCorp, as an infrastructure company, made a big mistake by choosing the BSL license (which was primarily designed for databases). Ultimately, this will destroy their community which in the long-term will also mean a lot of lost revenue...It is also very interesting to see how this will play out specifically for Vault vs Infisical. So far, Infisical has been growing incredibly, especially after the license switch.

OpenTF should poach apparentlymart from HC, that will drive a lot of adoption :)

Time to do you part. Substitute Terraform with OpenTF (Terraform successor) everywhere.Oracle tried to constrain Hudson, but Jenkins won.

Or just finishing to completely destroy their credibility? That would be the last nail in their coffin.

Waiting for Hashicorp&#x27;s next move to introduce some proprietary incompatibility with Terraform Cloud API just so they can artificially damage OpenTF.

No -- thanks to the MPLv2, which contains a patent grant.

Does HashiCorp pose a patent threat to OpenTF? If Terraform implements a feature and OpenTF (cleanroom) copies it, could HashiCorp patent the feature to prevent OpenTF from using it?

&gt; Even better would to leave a note rescinding permission for Hashicorp to include that work, though I&#x27;m not sure whether that is a viable strategy.I don&#x27;t see how that would work. If a valid offer has already been made under a license agreement, it&#x27;s then entirely up to Hashicorp whether to merge it or not.

I would suggest that PR authors should resubmit their work to OpenTF, closing the old PR.Even better would to leave a note rescinding permission for Hashicorp to include that work, though I&#x27;m not sure whether that is a viable strategy.At the very least, these steps will create more work for Hashicorp and send a clear signal that the community thinks that they have made a mistake.

Responded on a similar Q above.<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37264675">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37264675</a>We’d love to know what issues &#x2F; PRs are important to your team to help us prioritize

I don&#x27;t see any mention of migrating the issues over, is that part of the plan?I also don&#x27;t have a good grasp of what the situation is for the in-flight PRs for Hashicorp&#x27;s repo: are those changes still MPL until they land in &quot;main&quot; and get BuSL-ed? IOW, is the PR author responsible for resubmitting or could any such patches be pulled in safely (err, DCO and CLA nonsense aside)?

I&#x27;m not sure what they mean by that. But one case where terraform&#x27;s model doesn&#x27;t work very well, is updating a certificate on a load balancer (to be concrete, say an ACM certificate attached to an NLB in AWS) to a new cert and remove the old one. The proper way to do that, without service interruption is the following:1. Create new certificate2. Update the certificate attached to the load balancer3. Delete old certificateBut it isn&#x27;t actually possible to do that in that order with terraform because of how dependencies work.By default what terraform will try to do is:1. Delete old certificate. this will either fail, because the certificate is in use (as is the case in AWS) or destroy a resource that is still in use and cause the load balancer to enter a bad state2. Create new certificate3. Update the load balancerThe only ways I have found to work around this is with targeted applies (which are discouraged), or splitting the change up into multiple code changes, with separate applies for each change.

Not sure what you mean exactly about &quot;shutting down a server when deleting a Terraform resource&quot;. But do you think that&#x27;s something inherent to the design that OpenTF wouldn&#x27;t be able to address?Personally I think Terraform hit on a really good pattern for IaC, and while there are lots of rough edges that could be polished, the overall approach is by far the best fit yet invented for the problem it&#x27;s aiming to solve.

&gt; why can we just simply not do something new along the wayMarcin here, one of the member of the OpenTF.99% of the value of Terraform is its ecosystem - providers, modules, tutorials, courses etc., and millions of lines of battle-tested production code already written in that language. 1% of the value is in the tool itself, with the tool serving as the gatekeeper to all these riches. One of the things that I personally want to see is opening up the codebase to allow building new things on top of it, which then don&#x27;t need to reinvent the wheel.You dislike HCL? Fine, have something else give the tool an AST and we&#x27;ll take it from here. You don&#x27;t need&#x2F;want to go through the CLI? Not a problem, embed some of these libraries directly in your app.

While i rally appreciate the effort and am astounded that they already have the pledge of 10 Full time engineers for 5 years I am left wondering 2 things:A) This could easily be a another reddit moment, where corps and actual bill payers will forget about it in two weeks since it simply -does not concern them-. The supporting list mostly consists of actual competitors.B) If they can manage all these resources, why can we just simply not do something new along the way? Terraform has its flaws and everyone that seriously had to worked with it can name many.For instance: Did you know that you cant easily shut down a server when deleting a terraform resource? At least not without hacks or workarounds?Its time for a &quot;cloud-init native&quot; solution to all these problems and while appreciating the effort i think this fork will actually hinder future development by having things remain the same.- Cluster Api all the way -

Awesome to see how enthusiastic this community is! We at the LF are excited to work with the wider community to bring them under neutral governance like our many other foundations&#x2F;projects. On the CNCF side, we welcome an application through the official processes when they are a bit further along with establishing their initial governance here: <a href="https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;sandbox">https:&#x2F;&#x2F;github.com&#x2F;cncf&#x2F;sandbox</a>

I&#x27;m not into the CDK at all to be honest but isn&#x27;t it a glorified preprocessor that generates the JSON representation of Terraform input, which is then processed as usual by your regular Terraform binary?

This is a big question for me. The CDK style form of authoring IaC is way better than config files in HCL&#x2F;YML&#x2F;JSON. It has some rough edges and I do wish it wasn&#x27;t so gung-ho on the magical object-oriented constructor side-effects, but it&#x27;s still a net improvement.CDKTF looks promising. How will OpenTF interplay with it?

What’s the plan for dealing with the Terraform CDK?

Looking forward to seeing what you develop or even just expose with documentation! Terraform felt artificially constrained by the UI when I used it to MVP my CD platform. I suspect Hashicorp uses an undocumented Go interface internally for Terraform Cloud.

That&#x27;s literally one of my personal goals - to open up the libraries so that new and beautiful things can be built on top of it without having to reinvent the wheel. You will see it being part of the manifesto which says:_Layered and modular - with a programmer-friendly project structure to encourage building on top, enabling a new vibrant ecosystem of tools and integrations_

It would be amazing if these efforts included fully documenting Terraform&#x27;s Go interface and developing it into a first-class library. Being forced to interface with Terraform through HCL really holds it back.

I don&#x27;t think OpenTF interop with future TF is important.  Particularly if OpenTF just moves at a faster pace, and gets way better in time.  I would say leave TF in the dust and just start innovating.

In this case are there any benefits for Hashicorp to move Terraform to BSL? Especially considering:&gt; Will I be able to use OpenTF as a drop-in replacement for legacy Terraform?&gt; Yes&gt; Will OpenTF be compatible with future Terraform releases?&gt; OpenTF will be 100% interoperable with future Terraform releases until the community wishes otherwise.

I am very curious about the future of Nomad. It definitely has its place for some orgs and was exciting to see an alternative to k8s gaining traction.I think this license change will hamper adoption and contribution when teams compare a foundation supported k8s vs a source available Nomad. I haven’t heard of anyone taking this on, but I’d love to keep my eyes on it if&#x2F;when it happens.Disclaimer: early supporter of opentf, cofounder of massdriver

It was intentional, but I was not aware of that project.Consul is just a nice distributed KV store and Consul Templates integrate well with vault secrets.It can also be used as a storage engine for Vault of needed.

&gt; OpenMotoI dunno if you&#x27;re trying to play on &quot;hashimoto&quot; but <a href="https:&#x2F;&#x2F;github.com&#x2F;getmoto&#x2F;moto#readme">https:&#x2F;&#x2F;github.com&#x2F;getmoto&#x2F;moto#readme</a> would be a prime name collision for any such &quot;OpenMoto&quot; nameBut yes, please, to adopting Vault. I don&#x27;t have a horse in the race about Consul but my suspicion is such an effort would only be worthwhile if trying to adopt Nomad, too, which I gravely doubt

I would love to see a similar initiative with Vault and maybe Consul.Maybe call it OpenVLT and OpenCNSL. Then we can wrap it in a larger OpenHC or OpenMoto umbrella of projects.Especially with the integration points between Terraform, Vault, and Consul, those can be maintained better.Hell, I would do it myself, it I had the connections and time to do it. I might still try if no one else does. I would model it after OpenTF

Well five is about the amount of sales people I remember joining an absolutely awful call with them a few years ago, so that’s my guess (edit: lol at getting downvoted for relaying an actual experience that happened. been using Vagrant since the original hobo logo circa 2012-2013 and have always been a HC fan, get off your high horse)

Wow I had no idea so few people worked on TF. Where are the bulk of Hashicorp working?&gt; So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository.

Only time will tell, but my mental model is that this new stewardship will be a lot more open to community input than the Hashicorp &quot;we&#x27;re too busy, pound sand&quot; model has beenI dunno if &quot;auto import&quot; will ever be a thing, but I will be first in line to change its model to actually contact the provider during `plan`, which neither TF nor Pulumi do right now and it&#x27;s a cause of endless wasted hours and borked deploys

can we finally fix all the annoying lack of features like auto import of existing resources? and providers that are just executables, so we don&#x27;t need to write them with Go or according to an ABI? I&#x27;m sure lots of users have things they&#x27;d like to fix

Did something happen to the Apache 2 rancher? <a href="https:&#x2F;&#x2F;github.com&#x2F;rancher&#x2F;rancher&#x2F;blob&#x2F;v2.7.5&#x2F;LICENSE">https:&#x2F;&#x2F;github.com&#x2F;rancher&#x2F;rancher&#x2F;blob&#x2F;v2.7.5&#x2F;LICENSE</a> RKE2 is similarly Apache 2: <a href="https:&#x2F;&#x2F;github.com&#x2F;rancher&#x2F;rke2&#x2F;blob&#x2F;v1.26.7%2Brke2r1&#x2F;LICENSE">https:&#x2F;&#x2F;github.com&#x2F;rancher&#x2F;rke2&#x2F;blob&#x2F;v1.26.7%2Brke2r1&#x2F;LICENS...</a>

someone needs to do something for nomad and rancher too, both of them are very powerful

What is the problem with BSL? Is it that the code is still available but you have to run their binaries? Honest question.

It worked very well for LibreOffice. Best of luck!

I don&#x27;t mind it. If a business is providing good software, and they have to make a license change to prevent someone from wholesale copying the work and selling it as a direct competitor, I&#x27;m for it! I&#x27;d rather have the sound business _in business_ and continuing to provide good software.

&gt; Few months later, change license and&#x2F;or close source it.Not to defend HashiCorp too much but in this case &quot;a few months&quot; was actually nine years.

This is a very non-charitable read of the history here.Also, none of the companies that pledge FTE support to OpenTF are open-source.

&gt; Your project gets to have top tier programmers as maintainers, make all the nifty features, fix all bugs etc. for free or at minimum costIn most case in these companies it&#x27;s maintained and created at the expense of the company. I would expect that 90-99%% of the code, product development (talk to users, understand needs, etc), even devrel (marketing) (be on every conference to convince people to use it, that codification is good)- it&#x27;s a lot of money, resources, and effort.&gt; New startup, cool idea, not much budget to hire engineersIn this case a few folks build it from the ground initially (most likely founders) I think. Please, let&#x27;s not forget about this.The important thing here is to discuss why did they do this (I meant relicensing it). Most likely- trying t create a moat from a lot of other VC-funded companies that play in this space? Not sure. It would be great to know their exact concern.

So the business model for these companies goes like this:- New startup, cool idea, not much budget to hire engineers- Make it open source, piggy back on the free exposure that will get you, no marketing is needed because everyone loves open source!- Your project gets to have top tier programmers as maintainers, make all the nifty features, fix all bugs etc. for free or at minimum cost- Few months later, change license and&#x2F;or close source it.- Rinse and repeat!Sometimes you get the community to fork it and maintain it by themselves, unfortunately, that’s not always the case.

oh ok great to know, thanks a lot! All the best with this project;)

We plan to maintain backward compatibility with the legacy version of terraform. You should be able to just start developing and swap the CLI.Depending on when you start, the first release mag already be out!

So I&#x27;m pretty new to Terraform, and in my team we were planning to set it up for our infrastructure next month. Does that change something for us? If it stays backward compatible I assume not much would have to be done for switching? I&#x27;d definitely prefer an open license.

But the AWS provider is owned&#x2F;maintained by Hashicorp, and I believe under the same license.

This is handled by the providers, not by Terraform core, and these maintained fully or partially by cloud vendors. Terraform core is but a small part of a much larger ecosystem.

It seems like really hard work keeping up with AWS api changes, is that not going to be an issue?

I hope this will be a warning for others tempted by relicensing to BUSL. This will probably kill all the community and maybe the company.

My guess is they went IPO. There was a massive cash infusion. Good. Eighteen months go by and people will be exiting. That means cash and talent leave.Now sales are tough. Pricing is terrible. We&#x27;ve been using their services for years while being offered enterprise services without much incentive.Why the license change? Lock out competitors or perhaps a charitable assumption, secure future service offerings without being exploited by cloud offerings that use their code while competing.The decision was a business decision. The amount they spend on sales to sell what I think is an amazing product, just over priced, is their doom. Why lock an enterprise into a three year contract tied to usage?

I&#x27;m really curious what Hashicorp expected here. I supposed their next move is to control access to terraform cloud by versioning. But that&#x27;d chop off a big portion of their userbase. So maybe they grandfather old tfvers in and expect new to use 1.15 or 1.5 I forget.

There was a long-standing PR with support for encrypting the entire statefile at rest. I personally find it worth revisiting.

Do you plan to crypt secrets on tfstate file? I think it could be a killer feature.

You say you have 14 FTEs. But do you have at least one major developer who contributed to terraform. Could you give me the users list who will work on this project.

When someone gets a well-deserved black eye, most folks would rather put on concealer makeup than be forced explain how they got their shiner.  I doubt they want to draw attention to how badly they just pissed off the open source community.

I thought Mitchell stepped down from an exec role a while ago.

I doubt they were involved in the decision, <a href="https:&#x2F;&#x2F;twitter.com&#x2F;mitchellh" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;mitchellh</a> posts a lot about stepping away from leadership to become an engineer again.

I&#x27;m really surprised the Hashicorp founders make no mention of the license change on their X (Twitter) accounts: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;mitchellh" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;mitchellh</a>
 &amp; <a href="https:&#x2F;&#x2F;twitter.com&#x2F;armon" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;armon</a>

OpenTF announces fork of Terraform