Like many other companies, HashiCorp has dropped the open source approach that gave its products their start for the source-available Business Source License (BSL).
HashiCorp is moving its products previously licensed as Open Source away from it to Business Source License (BSL) moving forward
Terraform is a popular Infrastructure as Code tool used for provisioning cloud resources like AWS, Azure among others
Terraform version 1.5.5 and earlier are still open source
there is a push for a community maintained open source fork if this decision is not reversed, OpenTF
We will see how this plays out… Terraform is awesome but the product would not be very popular today if open source developers hadn’t worked for 10 years for free to maintain and update it.
Now they take all their work and decides it’s not open source anymore, because hashicorp needs to make money.
I wonder how many of those “open source developers”, are actually employees of the same companies HashiCorp is accusing now of competing against them. No company is going to pay their employees to contribute to a piece of software, that they then have to buy a license for… so this can very well mean that HashiCorp is cutting off contributions from the same people most capable of contributing in the first place.
Not so “just”. Terraform open source version went into a fork. Who will work on that one and who will continue with the hashicorp version? It’s a split in the community now, and I bet most devs will continue on the hashicorp version.
I bet most devs will continue on the hashicorp version
Only the hobbyist ones. Every dev paid for by a company using the products, will be on the OpenSource fork.
It’s something companies often forget: open source, and the GPL in particular, is a way for companies to cooperate. Use the AGPL if you want to prevent unfair server-side competition. Switching to the BSL is restricting cooperation to only those with less experience.
PS: IANAL, but by reading MariaDB’s guidelines for the BSL, HashiCorp may not even have applied it correctly.
I used pulumi but it’s much worse than terraform. I didn’t used to think so before I learned terraform however.
My main reason to dislike pulumi is that you have to work around it’s async behavior in python. Maybe it’s better and more natural if you use typescript, but I had to constantly wrap methods in Outputs and other things to get the code to work.
I had to adapt my code to how pulumi worked all the time. With terraform, I just write it and it works.
So I’m using it with Python. For me it’s able to do some stuff that terrafom never would be able to (Ive got a spot where resources are generated for each file/object on disk).
We’ve got it rigged up for aws sso. Each department can make any number of permissions sets (and link to any number of groups). The config for that is all stored in git (with code owners configured so you can only mess up your own stuff).
i dont think theyre equivalent tools since Terraform is used for things like creating cloud VMs with the selected OS image, configuring subnets and route tables among other things which i dont believe NixOS is meant for
I was hit aggressively by HC sales team last year, we are using TF and Vault, and were looking to add consul, now it is pretty vauge how it will all pan put
When Canonical originally had such a CLA to contribute to Ubuntu it was pretty controversial (I don’t think it was common at all at the time), this situation with HashiCorp perfectly demonstrates why.
The integrations with other services are implemented in plugins which are separate programs, that are installed separately, and communicate with the core over RPC. I would imagine these plugins can continue to be licensed however their owners choose. I think this license change just applies to core.
I’m not as familiar with MPLv2 but I don’t think they can with contributions to the fork. Since those contributions won’t be part of the original “we own all your work” agreement they couldn’t simply close source those contributions.
Q: I have written a code patch to a BSL project and would like the BSL vendor to maintain the code as part of the BSL project. How do I contribute it?
A: License your code using the “new BSD” license or dedicate it to the public domain. Code contributions under “new BSD” is compatible with BSL. See BSD on Wikipedia.
but another user there have mentioned that while most of them integrate with Kubernetes and AWS, short lived DB credentials are not in any of those listed
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !technology@beehaw.org
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Fuck’em. 'Nuff said.
We will see how this plays out… Terraform is awesome but the product would not be very popular today if open source developers hadn’t worked for 10 years for free to maintain and update it.
Now they take all their work and decides it’s not open source anymore, because hashicorp needs to make money.
I wonder how many of those “open source developers”, are actually employees of the same companies HashiCorp is accusing now of competing against them. No company is going to pay their employees to contribute to a piece of software, that they then have to buy a license for… so this can very well mean that HashiCorp is cutting off contributions from the same people most capable of contributing in the first place.
No, just new versions.
Not so “just”. Terraform open source version went into a fork. Who will work on that one and who will continue with the hashicorp version? It’s a split in the community now, and I bet most devs will continue on the hashicorp version.
Only the hobbyist ones. Every dev paid for by a company using the products, will be on the OpenSource fork.
It’s something companies often forget: open source, and the GPL in particular, is a way for companies to cooperate. Use the AGPL if you want to prevent unfair server-side competition. Switching to the BSL is restricting cooperation to only those with less experience.
PS: IANAL, but by reading MariaDB’s guidelines for the BSL, HashiCorp may not even have applied it correctly.
I for one am recommending pulumi for any of my teams new infrastructure needs.
I used pulumi but it’s much worse than terraform. I didn’t used to think so before I learned terraform however.
My main reason to dislike pulumi is that you have to work around it’s async behavior in python. Maybe it’s better and more natural if you use typescript, but I had to constantly wrap methods in Outputs and other things to get the code to work.
I had to adapt my code to how pulumi worked all the time. With terraform, I just write it and it works.
So I’m using it with Python. For me it’s able to do some stuff that terrafom never would be able to (Ive got a spot where resources are generated for each file/object on disk).
Give me an example… What file on disk are you generating a pulumi resource from?
We’ve got it rigged up for aws sso. Each department can make any number of permissions sets (and link to any number of groups). The config for that is all stored in git (with code owners configured so you can only mess up your own stuff).
Not that I’d know much about this, but can’t you easily replace terraform with some script that remotely installs NixOS?
i dont think theyre equivalent tools since Terraform is used for things like creating cloud VMs with the selected OS image, configuring subnets and route tables among other things which i dont believe NixOS is meant for
Terraform is great automation, but it really shines over scripts in a few ways:
What a shame.
I was hit aggressively by HC sales team last year, we are using TF and Vault, and were looking to add consul, now it is pretty vauge how it will all pan put
For the people who continue to work on the open source fork of terraform, can HashiCorp pull their commits into their closed source BSL fork?
I would assume not, but I am curious if there’s some weird workaround of their previous license that they still own contributions
deleted by creator
ouch… Well, with the fork they wont have to do that anymore… so thats good.
When Canonical originally had such a CLA to contribute to Ubuntu it was pretty controversial (I don’t think it was common at all at the time), this situation with HashiCorp perfectly demonstrates why.
The integrations with other services are implemented in plugins which are separate programs, that are installed separately, and communicate with the core over RPC. I would imagine these plugins can continue to be licensed however their owners choose. I think this license change just applies to core.
I’m not as familiar with MPLv2 but I don’t think they can with contributions to the fork. Since those contributions won’t be part of the original “we own all your work” agreement they couldn’t simply close source those contributions.
From the BSL FAQ:
That would seem to rule out the MPLv2.
That is for continuing contributions to the commercial project, the fork should be using the old license not the BSL.
The question was if HashiCorp could take contributions to the fork and put them into their commercial product.
That means HashiCorp could only take contributions licensed under the BSD or public domain, or under a CLA. The fork would be none of those.
We were considering Vault, I guess we’ll look into alternatives now, are there any decent Free Software ones in the first place?
ive not done secrets management before but i came across this list on hackernews, a few non-cloud ones use open source license https://news.ycombinator.com/item?id=37133054#37151218
but another user there have mentioned that while most of them integrate with Kubernetes and AWS, short lived DB credentials are not in any of those listed
I’m not an infra dev, but a previous project used SOPS and it seemed alright
I’ve been using Infisical recently and I like it a lot.