Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The OpenTF Manifesto

opentf.org

Post reply on HN
Print view View original

321–330 of 392 posts

Re: The OpenTF Manifesto

#321

Post by xinayder »

dbingham wrote: post #23

I appreciate the letter and trying to work with Hashicorp -- I used to have a ton of respect for Hashicorp. But honestly... at this point... ...just fork it into a foundation. Don't wait for Hashicorp's response. I get wanting to have the appearance of working with Hashicorp, but we've been shown again, and again, and again, and a-fucking-gain that private corporations cannot be trusted to maintain public goods. Only…

Why not get it under the umbrella of either the Linux Foundation or CNCF? Things like this and Ansible should be really kept under neutral companies and not companies like Red Hat and HashiCorp that have shown that all they care about open source is the free work they get from contributors.

Re: The OpenTF Manifesto

#322

Post by garfieldnate »

I'm looking forward to seeing the creation of the foundation. Honestly, given the huge number of people that use it, the open source activity, etc., closing the source is a huge deal and Hashicorp could not really expect anything other than a big response to keep the open source version going. Am I wrong here?

Re: The OpenTF Manifesto

#323

Post by Pet_Ant »

lmm wrote: post #298
jjnoakes wrote: post #292

Earlier quoted context omitted.

This seems extremely dismissive and shallow. The imperative part of that code appears to be analogous to templating. The actual work done under the covers is not imperative, but is based on the difference between the result of the template execution and the current state of the system. That's what makes it declarative.

> This seems extremely dismissive and shallow. When someone tries to make a sophisticated argument that up is down and white is black, dismissive and shallow is the right response. > The actual work done under the covers is not imperative Having a declarative layer somewhere in the stack doesn't make something declarative, if that's not the layer you actually use to work on and reason about the system. See the famous…

I’m guessing this is the reference?

http://conal.net/blog/posts/the-c-language-is-purely-functio...

Re: The OpenTF Manifesto

#324

Post by jhoelzel »

While this wont affect 99.9% of us, I am very happy what this will mean for further kubernetes adoption.

VMS are a concept of older times and should be replaced by containers. YES; there is still use for VM's but everyone and their mother migration to k8s will mean wonders for portability of applications and more.

Re: The OpenTF Manifesto

#325

Post by linuxandrew »

VectorLock wrote: post #319
pxc wrote: post #306

Earlier quoted context omitted.

They can't retroactively take source code away from people who they already granted access to it under the MPL. The old code is still available under the MPL forever- even if they take down all of their own public copies of it, anyone with the old Terraform code is still free to upload their copy for the creation of a new fork. That's kinda the whole idea with these open-source licenses :)

I've heard some people discuss that the contribution agreement that Hashicorp makes people sign gives them the right to change the license for existing contributions, but I'm not a lawyer so I really couldn't say for certain either way.

HashiCorp makes its external contributors sign a CLA to basically hand over the copyright.

However the MPL and licensing in general is irrevocable. They have irrevocably licensed Terraform 1.5.5 under the MPL and an enterprise license (dual license). Anyone can use, modify and distribute version 1.5.5 under the terms of the MPL.

Since HashiCorp retains full copyright they can release the next version under the BSL.

Note that many free software projects (like Linux) don't have a CLA which makes relicensing impractical since every contributor would have to agree to it.

Re: The OpenTF Manifesto

#326

Post by ericb »

lmm wrote: post #320
waynesonfire wrote: post #316

Earlier quoted context omitted.

Right below your comment was another comment that started with, "The truth is that a fork hurts everyone." So, which is it?

Currently forks are painful, because they aren't normalized i.e. our tools and workflows don't expect them. I'm saying rather than discouraging forks we should adapt our tools and workflows to expect them.

Sure, tooling could be better.

But the real work is all the hard work that goes into a fork. I've watched open forks die all the time--all it takes is no one to step up and do/pay for the work, which is basically the default, because it is in everyone's interest if someone else is the one to do that.

I think that's really the crux of the problem--there are plenty of folks willing to maintain software for money, and a whole lot of people who'd rather it not cost money and if it does, not their money.

If the tooling is better, who is going to maintain this?

Re: The OpenTF Manifesto

#327

Post by throwaway2037 »

lmm wrote: post #288
enneff wrote: post #242

Earlier quoted context omitted.

What would it mean to “normalise” forking? The costs of maintaining a fork are significant, and if one group of programmers are being funded to work on the project then it can be very difficult to fork a project in any meaningful way without significant resources behind it. Also IIUC most of the parties in this conversation are corporations. They’re all trying to enjoy the benefits of open source development for a va…

> The costs of maintaining a fork are significant Why? If we have tooling or workflows that assume forks don't happen, maybe we can fix those. Forking should be cheap, easy and frequent.

I assume OP meant cost == community. That is the hard part of a fork.

Re: The OpenTF Manifesto

#328

Post by jq-r »

jen20 wrote: post #237
yevpats wrote: post #165

Earlier quoted context omitted.

I think it's not only the issue with terraform but also the underlying infrastructure. AWS should've never have imperative APIs in the first place. Or at least it's time for AWS V2 APIs

This is clearly a poor idea. Declarative infrastructure management is ultimately a dead end, because order of operations actually matters.

I'm not sure one follows from the other.

You could have both: eg if resource Y depends on X, then you would just declare Y after X. Or you could do a "depends_on" directive like in TF.

That certainly doesn't sound like a dead end to me.

Re: The OpenTF Manifesto

#329

Post by brikis98 »

new23d wrote: post #175

As an end-user, not competing with HashiCorp, this change doesn't worry me. According to their FAQ [1]: 10. What are the usage limitations for HashiCorp’s products under BSL? All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp commercial products, hosted or self-managed. 24. Can I host the HashiCorp products as a…

How do you know you're not competing with HashiCorp?

That's not meant to be a redundant or snarky question. The key issue with the BSL and that FAQ is that the wording is intentionally vague. What does "competing" mean? What does "hosting or embedding" mean? Who decides?

In order to really know if you're a competitor, you have to reach out to HashiCorp (as the FAQ tells you to do). So whether your usage is valid is not controlled by the license terms, but is instead entirely at the whim of HashiCorp. So they switched from a permissive open source license to a HashiCorp decides license: they get to decide on a case by case basis now—and they can change their mind at any time.

That is very shaky footing on which to build anything.

See https://blog.gruntwork.io/the-future-of-terraform-must-be-op... for more info.

Re: The OpenTF Manifesto

#330

Post by brikis98 »

mousetree wrote: post #128

As a regular end-user of Terraform, what difference does BSL vs MPL make to me? From reading this article it seems not very much? Perhaps I'm misreading this.

It means that whether you can use Terraform at any future company you work for will be determined... by HashiCorp.

That's because the BSL license is intentionally vague. What does "competing" mean? What does "hosting or embedding" mean? Who decides?

In order to really know if you're a competitor, you have to reach out to HashiCorp (as the FAQ tells you to do). So whether your usage is valid is not controlled by the license terms, but is instead entirely at the whim of HashiCorp. So they switched from a permissive open source license to a HashiCorp decides license: they get to decide on a case by case basis now—and they can change their mind at any time.

That is very shaky footing on which to build anything.

And the legal team at every company you work for will have to take that into account before deciding you can or can't use Terraform.

See https://blog.gruntwork.io/the-future-of-terraform-must-be-op... for more info.

Post reply on HN