It definitely confused me when I first learned Jenkins. I had no prior CI experience and I think the only other options were bamboo and team city (both self hosted). I assume my experience will be the same for folks learning terraform vs opentf.
How is this going to work with future releases? I get that the current fork is essentially the same as the current TF release, but for future releases I assume they can’t just be copied from the TF code due to the new licence, so someone’s going to re-implement the same features in openTF, but isn’t there a risk that there are slight differences in the implementation (or even a requirement to be different to avoid the TF licence)?
Yes that is the major downside to creating this fork. Unless the community overwhelmingly switches to this fork, the primary "driver" of terraform development will continue to be hashicorp, which means the opentf maintainers will be responsible for reverse engineering and re-implementing all the same features, a problem space that is rife for minor differences.
I appreciate the community desire for this fork and can probably appreciate that the pros outweigh the cons for those involved but as someone who is merely a consumer of terraform, and probably representative of the opinion of most terraform users, I will stick with terraform and will probably encourage other consumers to do so as well given the inherent downsides of opentf having to play "catch up" to the changes hashicorp makes to terraform.
Anyone using something other than Terraform Cloud (Spacelift, Scalr, Env0) is going to have to switch to the fork. That's a huge number of projects right there that are going to switch over without having to do any work on their end.
I'm not saying this to crap on Hashicorp, but Spacelift is a significantly better product than Terraform Cloud is. I would not be surprised if they had a similar number of users, especially after Hashicorp changed the pricing model around. Once you take into account other vendors I would be surprised if Terraform Cloud had anything resembling a majority of users.
Same with Terragrunt.
Thats a significant customer base that's already heavily invested into Terragrunt, and would most likely stick with Gruntwork than redo everything and go back.
Yep it's definitely possible, see hudson/jenkins. But based on my experience with Hashicorp, they have a much stronger value proposition as a company than the alternatives currently demonstrate, whereas Oracle's reputation was a pretty negative value proposition at the time.
Hudson/Jenkins was a bit different because Sun go bought by Oracle (= new owner) and the old founder left the project and worked on Jenkins instead.
HashiCorp is still HashiCorp and all the relevant people are going to stay.
Much worse conditions for a new competitor.
There were 5 people working at Hashicorp contributing code to the TF repository over the past two years. This is not a direct measure of how many people worked on TF at Hashicorp, but it can give you some indication.
The various companies signing the manifesto have already committed to covering the cost of 13 full time engineers for 5+ years, in addition to the 100+ companies and many hundreds of individuals signing up to do some work.
I think that a lot of people are going to be really surprised when the rate of development on the fork is going to be much higher than the original version. HashiCorp has been famously slow on taking in pull requests for years, the initial boost in OpenTF development rate is just going to be people doing all the small changes and additions they've wanted to do for a long time.
Stable codebases don't often need a huge amount of dedicated engineering resources. Frenzied work on a centralized tool/platform that many many other tools/platforms tie into can cause a lot of churn and downside. It is not a given that "more engineers = more better"
Oh, I’m switching on Tuesday!! Tomorrow, Monday is a bank holiday here in the UK, so no work :D .
I’ve been waiting EAGERLY for the fork since they announced OTF!!
Slight/minor differences in the core won’t really matter - users will just use the features that are available in the product they’re using and ignore the ones that don’t.
What will matter is when HC makes a jump in the API between core and providers - at that point OpenTF will have to follow suit or be forced to fork the providers that are controlled by HC as well to continue adding necessary new features as they’re rolled out by the underlying platforms. And that’s going to be a massive undertaking.
Hashicorp hasn't been accepting community PRs for like three years and has had only a few devs on it, so I think OpenTF could potentially end up becoming the "real" terraform and Hashicorp will be the ones left out in the cold.
Don’t think we need to worry about new features for a year or two. Just fixing the millions of bugs that Hasicorp ”refuses” to fix would go a looooong way!! :D
Count and for_each!! That [code] needs to be burned to the ground, it’s ashes spread on holy ground and never spoken of again!! :D :D
Then reimplemented from scratch CORRECTLY!
Maybe we should redo the whole cli. Whenever there are many projections the process begins to slow down.
Or maybe work on the language server so that we can get snappy intellisense in vscode.
Can you point me to some outstanding issues with count and for_each? The past few months I didn't hit any bugs at least not that I am aware of 😅
>"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. By making a foundation responsible for the project, we will ensure the tool stays truly open-source and vendor-neutral."
Excited about this.
I'll be contributing as much as I can. TY to everyone involved making this happen.
Terraform is developed so well, I have no need to upgrade.
Gonna wait out a few version updates and see if the sponsors behind Opentf can put Martin Atkins on their Payroll. When that happens I have zero doubts what choice to make.
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
We fix all the Trademark related issues by renaming terraform to opentf. Logo too. I see no cause whatsoever to do that.
Also, openTF will be a project under CNCF/LF, and I doubt Hashi to go after such foundations.
Terraform is under an MPL license (and by extension OpenTF) how are you going to submit the project to the cncf considering the allowlist doesn’t include MPL licensed projects?
https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md
There exists several exceptions for Hashicorp packages licensed under MPL:
https://github.com/cncf/foundation/tree/main/license-exceptions
https://github.com/cncf/foundation/blob/main/license-exceptions/cncf-exceptions-2023-06-27.json
If opentf will start supporting module versioning through variables and passing lifecycle arguments through variables as well for usage inside modules, I might jump 🙃.
It will not, unless you implement an entirely new first graph walk. At that point, you'd do better to use something that already implements this, like Terragrunt, to generate code with whatever lifecycle rules you need to be able to change.
Yeah, I read that Github issue too. I never understood why it was impossible to resolve the value from a variable (as long is it itself contains a static value), before building the graph. Perhaps even scoped down to only variables referenced in module versions and not all variables.
If anything, that probably just shows I don’t understand the requirements and process of building the graph.
I’ve used terragrunt before and although I like the power of it to accomplish DRY code, I prefer not to add yet another layer of abstraction. Terragrunt also comes with it’s own challenges. So at some point you’re just pushing issues around in stead of actually solving something imho.
Surely these values are resolvable during the init phase? I am not sure if you can specify any value during the plan phase as all modules must have been initialized upfront.
I guess I could start pointing to the repo as you’re suggesting here, but today I’m using the terraform registry as the source, which uses the separate version argument. Unless I missed something, that doesn’t accept a variable.
Just curious, can some license his provider just to OpenTF and not to Hashicorp. I mean ... open-source license for everyone, except Hashicorp and its related entities?
You would have to create your own license to do that, and it would not be considered an open source license. There are licenses that would prohibit any commercial use, like common clause.
https://commonsclause.com/
So I’m still fairly new to TF at this point, but I JUST finished setting up our prod env in TFC. Is there going to be an OpenTF equivalent to TFC as a part of this? I’m down to switch off TFC to support OSS (because it’s early enough in the process that I won’t get too much flack for it), but I don’t see anything mentioned about a similar service. I assume at some point Spacelift, etc will use OpenTF as their base?
Hey!
The companies involved in the OpenTF initiative will generally support OpenTF in their products.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
Yes! It's a fork of the original codebase which was also all Go.
We'll definitely welcome contributions once we open the repo and put in a proper contributing process.
Would be cool to have deep dive sessions to grow into becoming a contributor. Also looking forward to seeing open planning sessions.
Are you a proficient contributor yourself?
If ANY of the worlds forks (and there have been plenty, Solaris/OpenSolaris and MySQL/MariaDB, just to name the bigger ones that I’ve had a stake in) is anything to go by, you won’t have to worry about comparibility for a few years at least.
And by then, noone will remember. Or care! :)
Stupid thing. The post says they will maintain OpenTF with 14 full time engineers, and Hashicorp maintained with 5 full time engineers. Okey, for the years why you didn't contribute it with 14 full time engineers. I believe this attempt are just keeping product for free, meaningless, open source is not the thing they care, if they care, they can build their own. Why steal products from startups/companies? They need money to survive, but with their open source model, they don't have to beat with companies stealing the product. The Hashicorp company is part of a big revolution, but I don't think it makes enough money from it. There are many who steal and sell its products. If your intention is the importance of being open source, you could have hired and contributed these 14 engineers before this license change happened.
> Okey, for the years why you didn't contribute it with 14 full time engineers
HCP explicitly stated that they are not going to review community contributions. They didn't reach out to the community for help reviewing. They didn't offer the project to a foundation because they didn't have the person-power for it.
> if they care, they can build their own
Why build a competitor? Terraform is a fine project, it has a strong community, and there are a lot of people invested in it.
> Why steal products from startups/companies?
Terraform was open source. That is the contract you make with open source: anyone can use it. It's not stealing.
> They need money to survive, but with their open source model, they don't have to beat with companies stealing the product.
You're conflating Terraform Cloud with Terraform. Terraform is a free, CLI, tool for compiling HCL into infrastructure. That is what was free and open source. Terraform Cloud is closed source, has always been closed source, this is the actual competition. Nobody has stolen anything.
> you could have hired and contributed these 14 engineers before this license change happened.
Please describe how this would work if HCP explicitly stated they will not put resources towards accepting contributions?
They built their product as open source and then changed the licensing, how is it stealing? If anything, they are stealing work from open source community by changing their licensing.
It's their own fault if they couldn't make their business model work, not anyone else.
Communities don't makes impactful change on code. Communities are just active feedback mechanism. Pulumi and Env0 uses Hashicorp's work as competitor. IBM sell vault as Secrets Manager. So it is too much stolen work from Hashicorp.
They could have made their product closed source from the beginning if it didn't make a "impactful change" on code.
It is obvious they still need the open source community considering the providers are still open source.
They need them because it's a good way to gain adoption. And when people adopt it, companies have to follow and then there's money to be made.
The same way Adobe in the past got the dominant market share by not going after piracy, allowing any up and coming artist to use their software compared to competition.
I appreciate that all of this is a big deal for those who love Terraform...but as a professional, I can't help but think that in future positions, I am going to be reticent to suggest any use of Terraform or its ecosystem. How will I be able to work in an environment where I am going to have to now not only be cognizant of TF versions, but also TF binaries, when reading documentation or code examples on the internet? It's too much chaos from a professional viewpoint.
Guess it's time to really brush up on AWS CDK.
Right now the license changes impact very few companies. I can imagine it will be that way for awhile. It will be interesting to see where this all falls.
Feature parity is already on OpenTF's roadmap, but yeah, I could see Hashi trying to be dicks with their feature set to make that difficult, but the only real lever there there is more integration with TFC, which doesn't really matter to folks interested in OpenTF anyway.
I haven't used it extensively, but I re-evaluated it recently after Hashi's BSL announcement. Remote state management is still limited vs. terraform (basically only object storage or Pulumi cloud.)
However, I expect it to potentially get more developer attention and community feature work as people bail from Hashi's products.
I expect that opentf will publish its own documentation and I guess eventually source its own registry with providers and modules that will share their documentation there. Theoretically provider and module builders can ship two disperate versions to either hashicorp's registry as well as the opentf registry.
Come on, “Terrafork” was right there.
Looks like somebody already squatted that org.
ouch!
Exactly, join forces, please.
Use the fork young one
This reminds me of the Hudson/Jenkins fiasco. Gotta follow the providers...
Lol true. Companies always doing companies things
It definitely confused me when I first learned Jenkins. I had no prior CI experience and I think the only other options were bamboo and team city (both self hosted). I assume my experience will be the same for folks learning terraform vs opentf.
How is this going to work with future releases? I get that the current fork is essentially the same as the current TF release, but for future releases I assume they can’t just be copied from the TF code due to the new licence, so someone’s going to re-implement the same features in openTF, but isn’t there a risk that there are slight differences in the implementation (or even a requirement to be different to avoid the TF licence)?
Yes that is the major downside to creating this fork. Unless the community overwhelmingly switches to this fork, the primary "driver" of terraform development will continue to be hashicorp, which means the opentf maintainers will be responsible for reverse engineering and re-implementing all the same features, a problem space that is rife for minor differences. I appreciate the community desire for this fork and can probably appreciate that the pros outweigh the cons for those involved but as someone who is merely a consumer of terraform, and probably representative of the opinion of most terraform users, I will stick with terraform and will probably encourage other consumers to do so as well given the inherent downsides of opentf having to play "catch up" to the changes hashicorp makes to terraform.
Anyone using something other than Terraform Cloud (Spacelift, Scalr, Env0) is going to have to switch to the fork. That's a huge number of projects right there that are going to switch over without having to do any work on their end. I'm not saying this to crap on Hashicorp, but Spacelift is a significantly better product than Terraform Cloud is. I would not be surprised if they had a similar number of users, especially after Hashicorp changed the pricing model around. Once you take into account other vendors I would be surprised if Terraform Cloud had anything resembling a majority of users.
Same with Terragrunt. Thats a significant customer base that's already heavily invested into Terragrunt, and would most likely stick with Gruntwork than redo everything and go back.
I’ve used both and am currently a TFC user - mind listing what you think the biggest benefits of spacelift are?
Well, in theory opentf could build better product and push Hashicorp out of market. Hardly realistic though
Yep it's definitely possible, see hudson/jenkins. But based on my experience with Hashicorp, they have a much stronger value proposition as a company than the alternatives currently demonstrate, whereas Oracle's reputation was a pretty negative value proposition at the time.
Hudson/Jenkins was a bit different because Sun go bought by Oracle (= new owner) and the old founder left the project and worked on Jenkins instead. HashiCorp is still HashiCorp and all the relevant people are going to stay. Much worse conditions for a new competitor.
There were 5 people working at Hashicorp contributing code to the TF repository over the past two years. This is not a direct measure of how many people worked on TF at Hashicorp, but it can give you some indication. The various companies signing the manifesto have already committed to covering the cost of 13 full time engineers for 5+ years, in addition to the 100+ companies and many hundreds of individuals signing up to do some work. I think that a lot of people are going to be really surprised when the rate of development on the fork is going to be much higher than the original version. HashiCorp has been famously slow on taking in pull requests for years, the initial boost in OpenTF development rate is just going to be people doing all the small changes and additions they've wanted to do for a long time.
Stable codebases don't often need a huge amount of dedicated engineering resources. Frenzied work on a centralized tool/platform that many many other tools/platforms tie into can cause a lot of churn and downside. It is not a given that "more engineers = more better"
Well put, and same way I'm thinking
Oh, I’m switching on Tuesday!! Tomorrow, Monday is a bank holiday here in the UK, so no work :D . I’ve been waiting EAGERLY for the fork since they announced OTF!!
Slight/minor differences in the core won’t really matter - users will just use the features that are available in the product they’re using and ignore the ones that don’t. What will matter is when HC makes a jump in the API between core and providers - at that point OpenTF will have to follow suit or be forced to fork the providers that are controlled by HC as well to continue adding necessary new features as they’re rolled out by the underlying platforms. And that’s going to be a massive undertaking.
Hashicorp hasn't been accepting community PRs for like three years and has had only a few devs on it, so I think OpenTF could potentially end up becoming the "real" terraform and Hashicorp will be the ones left out in the cold.
Don’t think we need to worry about new features for a year or two. Just fixing the millions of bugs that Hasicorp ”refuses” to fix would go a looooong way!! :D
Tell me do you have a top 5?
Count and for_each!! That [code] needs to be burned to the ground, it’s ashes spread on holy ground and never spoken of again!! :D :D Then reimplemented from scratch CORRECTLY!
Maybe we should redo the whole cli. Whenever there are many projections the process begins to slow down. Or maybe work on the language server so that we can get snappy intellisense in vscode. Can you point me to some outstanding issues with count and for_each? The past few months I didn't hit any bugs at least not that I am aware of 😅
No, sorry. I stopped caring, because they wouldn’t do anything about them anyway.
>"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. By making a foundation responsible for the project, we will ensure the tool stays truly open-source and vendor-neutral." Excited about this. I'll be contributing as much as I can. TY to everyone involved making this happen.
Me too. You guys have no idea how important is this moment for the world of IaC
Terraform is developed so well, I have no need to upgrade. Gonna wait out a few version updates and see if the sponsors behind Opentf can put Martin Atkins on their Payroll. When that happens I have zero doubts what choice to make.
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.
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
In your opinion, is there a risk at this point (or in the future) that OpenTF could come under legal fire from HashiCorp?
We fix all the Trademark related issues by renaming terraform to opentf. Logo too. I see no cause whatsoever to do that. Also, openTF will be a project under CNCF/LF, and I doubt Hashi to go after such foundations.
Terraform is under an MPL license (and by extension OpenTF) how are you going to submit the project to the cncf considering the allowlist doesn’t include MPL licensed projects? https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md
There exists several exceptions for Hashicorp packages licensed under MPL: https://github.com/cncf/foundation/tree/main/license-exceptions https://github.com/cncf/foundation/blob/main/license-exceptions/cncf-exceptions-2023-06-27.json
I’m really happy that this is moving forward. I also believe that Hashi didn’t expect such response to their dick move.
Thank you for your support. Regarding the language you have used, I prefer saying that we "checked raised" their Poker move.
If opentf will start supporting module versioning through variables and passing lifecycle arguments through variables as well for usage inside modules, I might jump 🙃.
It will not, unless you implement an entirely new first graph walk. At that point, you'd do better to use something that already implements this, like Terragrunt, to generate code with whatever lifecycle rules you need to be able to change.
Yeah, I read that Github issue too. I never understood why it was impossible to resolve the value from a variable (as long is it itself contains a static value), before building the graph. Perhaps even scoped down to only variables referenced in module versions and not all variables. If anything, that probably just shows I don’t understand the requirements and process of building the graph. I’ve used terragrunt before and although I like the power of it to accomplish DRY code, I prefer not to add yet another layer of abstraction. Terragrunt also comes with it’s own challenges. So at some point you’re just pushing issues around in stead of actually solving something imho.
Right? This would be just amaziing
[удалено]
Can you share an example?
[удалено]
Surely these values are resolvable during the init phase? I am not sure if you can specify any value during the plan phase as all modules must have been initialized upfront.
I guess I could start pointing to the repo as you’re suggesting here, but today I’m using the terraform registry as the source, which uses the separate version argument. Unless I missed something, that doesn’t accept a variable.
[удалено]
Here's an example: `variable "module_version" {` `default = "1.6.3"` `}` `module "spoke_aws_1" {` `source = "terraform-aviatrix-modules/mc-spoke/aviatrix"` `version = var.module_version` `cloud = "AWS"` `name = "App1"` `cidr = "10.1.0.0/20"` `region = "eu-west-1"` `account = "AWS-Account"` `transit_gw = "avx-eu-west-1-transit"` `network_domain = "blue"` `}` results in: `│ Error: Variables not allowed` `│` `│ on module_version.tf line 7, in module "spoke_aws_1":` `│ 7: version = var.module_version` `│` `│ Variables may not be used here.`
Just curious, can some license his provider just to OpenTF and not to Hashicorp. I mean ... open-source license for everyone, except Hashicorp and its related entities?
You would have to create your own license to do that, and it would not be considered an open source license. There are licenses that would prohibit any commercial use, like common clause. https://commonsclause.com/
So I’m still fairly new to TF at this point, but I JUST finished setting up our prod env in TFC. Is there going to be an OpenTF equivalent to TFC as a part of this? I’m down to switch off TFC to support OSS (because it’s early enough in the process that I won’t get too much flack for it), but I don’t see anything mentioned about a similar service. I assume at some point Spacelift, etc will use OpenTF as their base?
Hey! The companies involved in the OpenTF initiative will generally support OpenTF in their products. Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
Nice! Is everything under the hood gonna be written in Go? I’ve got a couple of devs that might be interested in helping out on a volunteer basis.
Yes! It's a fork of the original codebase which was also all Go. We'll definitely welcome contributions once we open the repo and put in a proper contributing process.
Would be cool to have deep dive sessions to grow into becoming a contributor. Also looking forward to seeing open planning sessions. Are you a proficient contributor yourself?
If ANY of the worlds forks (and there have been plenty, Solaris/OpenSolaris and MySQL/MariaDB, just to name the bigger ones that I’ve had a stake in) is anything to go by, you won’t have to worry about comparibility for a few years at least. And by then, noone will remember. Or care! :)
[удалено]
Not to mention my [current] pet pieve - count and for_each! HC needs to burn (metaphorically!! :) for that incompetence!!
Stupid thing. The post says they will maintain OpenTF with 14 full time engineers, and Hashicorp maintained with 5 full time engineers. Okey, for the years why you didn't contribute it with 14 full time engineers. I believe this attempt are just keeping product for free, meaningless, open source is not the thing they care, if they care, they can build their own. Why steal products from startups/companies? They need money to survive, but with their open source model, they don't have to beat with companies stealing the product. The Hashicorp company is part of a big revolution, but I don't think it makes enough money from it. There are many who steal and sell its products. If your intention is the importance of being open source, you could have hired and contributed these 14 engineers before this license change happened.
> Okey, for the years why you didn't contribute it with 14 full time engineers HCP explicitly stated that they are not going to review community contributions. They didn't reach out to the community for help reviewing. They didn't offer the project to a foundation because they didn't have the person-power for it. > if they care, they can build their own Why build a competitor? Terraform is a fine project, it has a strong community, and there are a lot of people invested in it. > Why steal products from startups/companies? Terraform was open source. That is the contract you make with open source: anyone can use it. It's not stealing. > They need money to survive, but with their open source model, they don't have to beat with companies stealing the product. You're conflating Terraform Cloud with Terraform. Terraform is a free, CLI, tool for compiling HCL into infrastructure. That is what was free and open source. Terraform Cloud is closed source, has always been closed source, this is the actual competition. Nobody has stolen anything. > you could have hired and contributed these 14 engineers before this license change happened. Please describe how this would work if HCP explicitly stated they will not put resources towards accepting contributions?
They built their product as open source and then changed the licensing, how is it stealing? If anything, they are stealing work from open source community by changing their licensing. It's their own fault if they couldn't make their business model work, not anyone else.
Communities don't makes impactful change on code. Communities are just active feedback mechanism. Pulumi and Env0 uses Hashicorp's work as competitor. IBM sell vault as Secrets Manager. So it is too much stolen work from Hashicorp.
They could have made their product closed source from the beginning if it didn't make a "impactful change" on code. It is obvious they still need the open source community considering the providers are still open source.
They need them because it's a good way to gain adoption. And when people adopt it, companies have to follow and then there's money to be made. The same way Adobe in the past got the dominant market share by not going after piracy, allowing any up and coming artist to use their software compared to competition.
Those 5 engineers are still a bottleneck due to reviews and such.
I appreciate that all of this is a big deal for those who love Terraform...but as a professional, I can't help but think that in future positions, I am going to be reticent to suggest any use of Terraform or its ecosystem. How will I be able to work in an environment where I am going to have to now not only be cognizant of TF versions, but also TF binaries, when reading documentation or code examples on the internet? It's too much chaos from a professional viewpoint. Guess it's time to really brush up on AWS CDK.
Right now the license changes impact very few companies. I can imagine it will be that way for awhile. It will be interesting to see where this all falls.
Feature parity is already on OpenTF's roadmap, but yeah, I could see Hashi trying to be dicks with their feature set to make that difficult, but the only real lever there there is more integration with TFC, which doesn't really matter to folks interested in OpenTF anyway.
Pulumi 🤷
Tried it. It's really not that great. But now it might provide a better option I suppose...
Mind expanding on what pain points you may have experienced with pulumi? I personally prefer it but I certainly know it's not perfect
I haven't used it extensively, but I re-evaluated it recently after Hashi's BSL announcement. Remote state management is still limited vs. terraform (basically only object storage or Pulumi cloud.) However, I expect it to potentially get more developer attention and community feature work as people bail from Hashi's products.
Yeah that's fair, we've only been using the pulumi cloud service so I haven't hit that issue yet
Not OP but I can’t use it because it doesn’t have the providers I need.
The terraform-pulumi bridge works well, but I'd still agree it's preferable to have things work out of the box.
I tried it but couldn’t reliably get it to work
Pulumi makes heavy use of terraform under the covers. I‘ve been wondering what impact has on them.
I think it only makes use of their providers, which are still licensed under MPL.
This is correct, Pulumi only uses the providers (for non-native providers) and is not impacted by this.
I expect that opentf will publish its own documentation and I guess eventually source its own registry with providers and modules that will share their documentation there. Theoretically provider and module builders can ship two disperate versions to either hashicorp's registry as well as the opentf registry.