OpenTofu’s Slack workspace
Bro... why do opensource projects love proprietary collaboration platforms so much?
this post was submitted on 26 Mar 2025
64 points (95.7% liked)
Programming
19806 readers
376 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
OpenTofu is mostly getting users from the corporate world. My work is on Slack and we're moving to OT. The lowest-friction for me as an OT-when-at-work user is to add another Slack. (I'd personally rather that they used an open platform. But it's easy for me to see why they didn't.)
What is a good open platform for the tech business? My corp want to go full Teams, which sucks even more than Slack. At least most tooling has a Slack integration of some sort.
mattermost?
Is https://huly.io/ any good?
https://elest.io/open-source/huly offers managed-hosting, but their "if you want REAL support, that is $50/mo extra subscription" thing is something to consider..
There's got to be something that they're offering, there ( I'm probably going to be using hosted-Lemmy for my publishing-platform, soon, so these questions are oblique to mine )
_ /\ _
I don't know. I might say "Matrix" and run a private server? But that's a bunch of IT work. It's attractive to use a SaaS because you don't have to do any long-term planning or hiring; just pay Slack a crazy amount of money and it all works.
Corps also like a commercial paid service because they get a contract with an SLA (even if it's rare to actually get anything from these SLAs).
Plus, I don't find slack super competitive in terms of features & usability.
I remember having a much better experience with mattermost.
I felt completely lost. What is Terraform?
Terraform is a tool that codifies cloud APIs into declarative configuration files to automate infrastructure provisioning and management
Not exactly sure what that means, but that may help someone!
Terraform is part of a movement called "Infrastructure as Code" (IaC) which allows engineers to define their cloud infrastructure using code.
This is extremely useful as it allows you to:
-
version infrastructure changes
-
automate resource and configuration creation and management
-
have reproducible environments (think production and staging envs, or deploying a new production env to another datacenter)
Terraform (and OpenTofu) is different to most IaC project as it is agnostic of cloud providers: you can use it to deploy infrastructure to multiple providers, where their competitors are limited to their own platform (I think of AWS's Cloud Development Kit)
In my experience with AWS, you run into issues using terraform that CDK just doesn't have. I'd rather have a different reliable system for each cloud environment than one system that is suboptimal for each environment. Since the providers are different, you don't really have anything in common besides using HCL as the language anyway.
Out of curiosity, what kind of issues have you faced? I work with aws in gov and terraform is used for everything, I've not encountered any issues as of yet.
The one that comes to mind is changing the security group for lambdas from an auto generated one (unspecified in terraform) to a specified one. It had some kind of chicken/egg situation so I ended up having to run two change sets - one to have both security groups set then another to remove the extra. Had to do the same thing in cdk and it just worked. There have been other similar things where everything is fine until you hit some edge case and then you're just wasting time and money doing acrobatics to work around the quirks (that don't exist in cdk).
I'm not in the devops group and they're attached to TF for some reason so I don't get a say in what we use, but I am the "everything is busted call in anyone that can help" guy so I end up dealing with the problems lol
it is agnostic of cloud providers: you can use it to deploy infrastructure to multiple providers
Nicely put. I frequently see the first part of this sentence and not the second. (Maybe I only pay attention to the first part and then disappoint myself...)
Terraform/Tofu allow me to use the same basic syntax and to have one project that controls AWS/GCP/K8s/my home servers, but I cannot use it to describe "a running server process" and just deploy that on any of those places. Instead I'd need to have like aws_beanstalk_service { ... } and gcp_application { ... } and kubernetes_manifest { ... } and systemd_service { ... } and the contents of those blocks would be totally different (and I'd need a bunch of different ancillary blocks for each of those).
Thanks for the detailed comment!
It's useful for configuring a turbo encabulator.
Its for easily deploying virtual machines. You can specify the VM specs, give it an install disk and some instructions, and it will churn out a VM for you.
Honestly, it's not great in my experience, nothing about it is common or portable, so if you change your VM host, it might all fall apart.
It's for far more than just deploying VMs: you can create pretty much anything you can on a cloud provider, such as databases, network rules, access tokens, object storage, etc.
Yeah, but I was trying to keep the description basic, to avoid turning it into a buzzword salad.
Have you used it much? Like it? Hate it? I'm curious to know others thoughts on it.
nothing about it is common or portable, so if you change your VM host, it might all fall apart.
Disclaimer, I'm pretty much elbow deep into terraform daily and have written/contributed to a few providers.
A lot of this is highly dependent upon the providers (the thing that allows the Terraform engine to interface with APIs for AWS, Proxmox, vSphere, etc. The Telmate Proxmox provider in particular is/was quite awful with not realizing a provisioned VM had moved to a new host.
Also, the default/tutorial code tends to be not very flexible. The game changer for me was using the built-in functions for decoding yaml from a config file (like yamldecode(file(config.yml)) in a locals block. You can then specify your desired infrastructure with yaml and (if you write your Terraform code correctly) you can blowout hundreds of VMs, policies, firewall rules, dns records etc with a single manifest. I've also used the local_file resource with a Terraform file template to dynamically create an Ansible inventory file based on what's deployed.
I was using it to deploy VMs to vsphere, and to test, started by deploying against a local KVM. Got it all working, copied the config to my prod vsphere, hoping I could just update the creds, and bunch of the KVM flags didn't work for vsphere, so I had to fix/rewrite them, which wasted a lot of time.
TF would be amazing if it was a single API that appled generically to all backends. And it sorta is for the most part, but there are just a few footguns that can really spoil the mood. If they had a core API and anything non-portable was clearly documented, that would be good as well.
Yeah, that's the other thing to keep in mind, since the KVM APIs are different from the vSphere APIs, you can't just swap providers without changes. But if you were going from a test vSphere stack to a prod, you could update the endpoint and be just fine.
Hashicorp has caught some shit in the past about claiming the code covers multiple providers. Technically, it can if you do weird shit with modules, but in reality there isn't a clean way to have a single, easily understandable project that can provision to multiple platforms.
Imagine a tool that gives you a language in which you can describe the hardware resources you want from a cloud provider. Say you want multiple different classes of servers with different sets of firewall rules. Something like Terraform allows you to put that into a text-based form, make changes to it, re-run the tool and expect resources to be created, changed and destroyed to match what you wrote down.
Infrastructure configuration that is automatically applied to the cloud infrastructure. Like starting and stopping new instances and services, changing connections between them, etc. (I assume anyway.)
It's just a way of defining configurations
Like an .ini file.
Based on the name I thought this was gonna be some platform to make homemade tofu more accessible to people and I was thinking “it’s really not all that hard to make, that’s kind of silly”
going after big nasoya
It’s traditional in open source to have really terrible names.
Not even the first time tofu has been used, I know it as the key validation scheme "trust on first use"
I don’t get it. Why go through the trouble and stay in a license that still allows Hashicorp / IBM to benefit from community contributions?
stay in a license that still allows Hashicorp / IBM to benefit from community contributions?
I don't see how this is the case. As Hashicorp explains, they switched from the open-source Mozilla Public License 2.0 (MPL) to the proprietary Business Source License (BSL) in order to apply restrictions upon users of Terraform:
Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license.
The terms of the MPL and BSL are incompatible, insofar that Hashicorp cannot unilaterally relicense MPL code from OpenTofu into BSL code in Terraform. But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL.
This is exactly the same situation as what Hashicorp was obliged to do before the licensing kerfuffle, so it cuts against Hashicorp's objective: why continue developing legacy Terraform if OpenTofu is going to provide continuity? Perhaps they only intend to develop new, exclusive features that build upon the common legacy code, but users would now retain an option to reject those pricy add-ons and just stick with the free, open-source functionality from OpenTofu.
It seems to me less about giving the finger to Hashicorp and more about giving users a choice in the matter. Without OpenTofu, the userbase are forced into the BSL terms of Terraform, where Hashicorp could unilaterally prohibit any production use by yet another license change. That's no way to live or work, with such a threat hanging overhead. OpenTofu lifts that threat by providing competition, and so maybe does kinda throw the finger at Hashicorp anyway.
On the flip side, precisely because MPL code cannot be unilaterally relicensed to BSL, if OpenTofu starts to gain new features that Terrarform doesn't have, Hashicorp can incorporate those features but they won't be unique. Why would a paying customer give money to Hashicorp for something that OpenTofu provides for free? The ecosystem of features cuts both ways.
Finally, it gives Hashicorp an out: if they acquiesce in future, their BSL code can be unilaterally relicensed as MPL once more, thus allowing code sharing with OpenTofu. Had OpenTofu picked a different license, this could have been much harder. But as described in the OpenTofu manifesto, continuity was the goal.
First of all thank you for your thoughtful response. I do disagree on a few key points though:
The terms of the MPL and BSL are incompatible, insofar that Hashicorp cannot unilaterally relicense MPL code from OpenTofu into BSL code in Terraform. But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL.
When you can still use code from a license and distribute the end result under a different license, that means they are compatible. Just like the MIT is compatible with any other license.
if OpenTofu starts to gain new features that Terrarform doesn’t have, Hashicorp can incorporate those features but they won’t be unique.
So they are benefiting from improvements made in OpenTofu.
Why would a paying customer give money to Hashicorp for something that OpenTofu provides for free?
To access the features that are exclusive to Terraform. Companies spend unglodly amounts of money to pay for MS Sharepoint (completely different product, just giving an example of an expensive product with competitive groupware options in the market). Why wouldn't they pay for Terraform, especially if it included a support contract? I think you are severely underestimating the willingness of customers to pay for service if you don't think that would happen.
And all features henceforth developed for Terraform would be exclusive to it, while all features developed for OpenTofu would be available to Terraform because the MPL is such a pushover license that doing so is trivial. OpenTofu will always stay behind in this scheme. In other words, any developer contributing to OpenTofu is donating work to IBM. I bet they are more than okay with that.
Had they moved new OpenTofu contributions to a strong copyleft license, OpenTofu would lose nothing, while Hashicorp/IBM would lose the freeloading of FOSS developer's contributions. IBM still has an out in this scenario, which is offering services to paying customers, just like Hashicorp did before the licensing fiasco. It's a lucrative business model, and one they are good at.
When you can still use code from a license and distribute the end result under a different license, that means they are compatible. Just like the MIT is compatible with any other license.
Your definition of license compatibility matches mine, as well as with how the term is used by the GNU Project and by the Apache Software Foundation. But I have a minor disagreement with the assertion that the MIT Expat license is compatible with any other license. And it's an important distinction, before I circle back to MPL and BSL compatibility.
The MIT Expat license is, by its own terms, very simple, and crucially allows 1) "sublicense" of the software, and 2) requires the copyright and permission notices to be included with copies. I assert that sublicense means that new license terms can be attached to a copy of such MIT Expat software, but under no circumstance can the new license terms abrogate the requirement about the copyright and permission notices. That is to say, a sublicense of MIT Expat software is void if it either: a) forces the obliteration of the Expat copyright or permission notices, or b) the terms of the new license does not allow for introducing code which wasn't originally licensed under that new license.
For example, when mixing MIT Expat software with GPL software, the resulting combination must be GPL licensed. This is what the GPL's copyleft provisions demand, and this is a valid sublicense of the Expat portion, per what I wrote above. Specifically, GPL doesn't command that the resulting combination to obliterate the copyright and permission notices, and GPL does not prohibit bringing more code into the GPL universe. Hence, MIT Expat and GPL are compatible.
But suppose instead that I've invented my own license, let's call it Litchralee's Interesting Terms (LIT), based on the WTFPL. LIT is quite simple, and adds one proviso which the WTFPL doesn't have:
0. Do WTF you want.
1. Any and all licensing text must be truncated beyond 100 Bytes for ease of understanding.
With this invented license, LIT is one of the (very few) licenses that is incompatible with the Expat license, because the mix of MIT software with LIT software must yield a result that is Expat licensed or LIT licensed. But neither is possible: to honor the Expat license for sublicensing the result means ignoring LIT's proviso #1. To honor LIT's proviso #1 for sublicensing means a full copy of the copyright and permission notices from the Expat license cannot be provided. Therefore, LIT and Expat are not compatible.
This will certainly seem like an edge case, and it certainly is, since the MIT Expat license is otherwise very, very permissive. But it's not all permissive. Its short text must be honored to the same degree that the comparably-larger GPL license must be honored, and the same goes for MPL and equally so for BSL.
In my previous comment, when I said that the MPL and BSL are incompatible, I believe that is still the case, because MPL+BSL => BSL is not an allowed combination, per the text of the MPL itself. As I laid out above, a work that combines two licenses must honor both, but if Hashicorp attempted to incorporate OpenTofu's MPL code into Terraform's BSL codebase and force the BSL license onto that imported OpenTofu, that is a violation of the MPL even if it doesn't violate the BSL.
We can look to the MPL's own text for why MPL+BSL => BSL isn't permitted. The relevant sections are:
1.5. “Incompatible With Secondary Licenses” means that the initial Contributor has attached the notice described in Exhibit B to the Covered Software; or that the Covered Software was made available under the terms of version 1.1 or earlier of the License, but not also under the terms of a Secondary License.
3.3. Distribution of a Larger Work You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).
1.12. “Secondary License” means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses.
Taken together, the MPL does allow for MPL+X => X, but only if: 1) the original MPL software did not include Exhibit B, and 2) X is any of the GPL, LPGL, or AGPL licenses. A brief look at the OpenTofu LICENSE file does not show that they've included Exhibit B, but the BSL would definitely fail the second test, since BSL is not in the list of secondary licenses. That is to say, the MPL's own terms explicitly state its compatibility with GPL, LGPL, and AGPL, and no others.
So Hashicorp cannot "steal" the OpenTofu code back into the closed, proprietary realm of the BSL.
But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL
This, however, is what they could do instead, and it means that Terraform would be BSL-mostly with some MPL OpenTofu code.
So they are benefiting from improvements made in OpenTofu.
Hashicorp can use OpenTofu in the manner given in OpenTofu's license, the same way that you, me, Microsoft, or the province of Quebec can. Open-source software benefits everyone and excludes no one. Is the suggestion that a special license be created, one which might be named "Screw Hashicorp Software License", whose terms disallow one specific organization? That's a rhetorical question, I admit, but if OpenTofu adopted an exclusionary license, that then means they must throw away compatibility with GPL, among others, because that license doesn't allow for sublicenses that exclude anyone.
An example of an exclusionary license -- with very good intent -- is the Anti-Caplitalist Software License, which is a non-open source, exclusionary license against corporations. I have other technical and practical issues with this license, but we're not here for that. Had OpenTofu adopted something like the ACSL as their license, any and all GPL plugins for Terraform that wanted to migrate to OpenTofu would be dead: GPL and ACSL cannot be distributed together, under GPL's terms.
In other words, any developer contributing to OpenTofu is donating work to IBM
Had they moved new OpenTofu contributions to a strong copyleft license
Part of the deal with copyleft licenses is that they create a perpetual one-way ratchet: the universe of copyleft code cannot shrink, always retaining the original grant of terms forever and ever, for all subsequent contributions per whatever license was used. GPL is regarded as one such "strong copyleft" license, but even it provides an out: separate distribution. Had OpenTofu used GPL, HashiCorp could still make use of OpenTofu within their BSL Terraform, by distributing OpenTofu as its own binary. Would this be silly? Yes, absolutely. So has Hashicorp been stopped with a strong copyleft license? Not at all; it's merely an inconvenience.
All the popular copyleft licenses cannot prevent Hashicorp from making some sort of use of OpenTofu. OpenTofu very much wants to preserve compatibility with GPL. OpenTofu would also like to remain FOSS if possible. The answer then is exactly what they chose: keep using MPL.
Using the tools of the capitalist (copyright and licenses) to wage a battle against a corporation is neither an even fight, nor is it even winnable. Instead, strong communities build up their skills and ties to one another to fight in meaningful ways. But that's getting too close to my complaints about the ACSL.