We Are Not Supporting OpenTF
medium.com
medium.com
“If they fork XF86, users won’t know which product to install. They’ll drift apart and ruin the whole market!” Or maybe everyone will (once again) adopt the truly open version that the majority of contributors switch to.
Either way, I’m not too worried about it. Forks of open source projects happen all the time for a thousand reasons. That certainly beats closed stagnation!
I’m not so sure about this. The Licensing FAQ doesn’t have the full legal weight of an update or addendum to the actual license. There’s no guarantee that they won’t renege these “binding” answers next year, and unlike the license agreement my company isn’t agreeing to them as terms of use.
https://raw.githubusercontent.com/hashicorp/terraform/main/L...
Just as a corollary, do you think it would still be actually binding if Hashicorp put punitive clauses in there? E.g. "violations of any of these terms will be subject to a 10% of revenue penalty". Are you still bound by that, even though it wasn't part of the agreement?
> Otherwise everyone could just make and sign contracts and go back to them claiming that their lawyers were mistaken in their interpretations of them, no?
That's kind of the point of the formal agreements. By putting it in the agreement, their lawyers are saying "this text says what we intend" and by agreeing to it you're saying "the terms in this text are acceptable", and then the whole thing is immutable unless both parties come to an agreement again.
That's the special space contracts enable. Everyone knows that they're proposing or agreeing to legally binding obligations and can treat it thusly. Slapping random bits of text around and saying they're legally binding is a mess because who knows if you've seen it, or when they'll change it, and whether you'll see any updates to it before you agree to another contract.
It's either in the contract and binding, or not in the contract and not legally binding. Hashicorp can choose to bind themselves however they want, but the only entity enforcing those terms is Hashicorp itself.
They, as the copyright owner, have said it is binding.
>There’s no guarantee that they won’t renege these “binding” answers next year
Next year they could changed the license entirely if they wanted to.
Changing the licence can't be done retroactively by Hashicorp. Changing the interpretation of the licence can be done retroactively by Hashicorp.
Yeah, that's kind of the problem in the first place. It seems as though open source projects with CLAs are just future closed source projects.
https://news.ycombinator.com/item?id=28425849
They have no skills in managing true open source projects. We’re better off in an OpenTF World. We don’t need their support.
This is so disingenuous. HC started and managed several of the biggest OSS projects out there. They significantly contributed to and evangelized OSS for over a decade. It's easy to say "we don't need their support" when you're piggybacking off of 13 years of their work and money.
I think that's what frustrates me about this whole thing. It's not the actual forking of terraform but it's the attitude that the companies and people behind OpenTF have had as they've gone through this. There's been a certain smugness and sense of entitlement that this entire thing gives off which doesn't sit right with me. Don't forget that the main drivers behind this are companies that stand to lose the most (commercially) from the licensing change. It's not as altruistic as they make it seem.
I would probably feel better about it if they just came out and said that this impacts their business prospects and as a result they're forking it. But they put this "we're doing this for the community" veil over it which feels disingenuous.
Follow the money. Without a workable IaC tool a lot of the backing companies’ business models fail. That’s why they’re treating this like the final act of Les Miserables.
HC has done a lot of great work with TF but left themselves open to this competition by not providing better value consulting services or pricing around TF cloud.
> A schism like this would be devastating for the tool’s adoption
Except when it isn’t, like in the case of LibreOffice. Terraform is already by far the most popular in its category. It’s pretty obvious that OpenTF will instantly be the superior choice by the merits of the license alone. HashiCorp will have the support of one company while OpenTF will be backed by multiple companies.
Cloud providers like AWS will have an automatic legal incentive to contribute to their providers as a part of the OpenTF project instead of HashiCorp. HashiCorp will be alone on an island.
Other parts of this article basically just say “don’t worry, HashiCorp won’t sue you.” Sorry, that’s not as good as free and open source.
Yes, HashiCorp is moving too slowly. That’s why they have to use the Oracle army of lawyers method, because most of the value in Terraform Cloud can be replicated in a weekend with a Gitlab template. Print the terraform plan out to the MR comments, use Gitlab’s variable management for secrets, manage your state in the backend of your choice, and that’s pretty much it.
Also, the terraform private registry gives you zero benefit over using repository URLs with references to tags/commits/branches. Yet another thing you don’t need terraform cloud for.
Their faq comments are useless: they had a faq item before saying they would be FOSS forever which they removed with this move.
Your use might have been perfectly fine last week, but can be competing with their new offerings from the beginning of next week.
Is what you are doing competing with Terraform cloud? You can send your questions to licensing@hashicorp.com for clarification.
For example, "people will be confused whether they should use TF or OpenTF". Guess what: at the beginning everybody will be using TF except a small minority who will consciously chose OpenTF, mostly for development. And they will make sure that, at least at the beginning, the choice will be irrelevant because the compatibility between these two is a top priority. It's like saying in 2004 "You shouldn't release CentOS because people will not be sure if they want to run CentOS or Red Hat". It simply makes no sense. All other arguments are like that.
> A “competitive offering” is a product that is sold to third parties, including through paid support arrangements, that significantly overlaps the capabilities of a HashiCorp commercial product.
We all get what they're trying to do. The bad thing is that this isn't only overly broad, but a moving target. I looked at HashiCorp's product page, and they're building up a wide portfolio of IaaS tools. Those are such fundamental tools that even if you're not a cloud provider at all, you're likely to have an overlap in "capabilities" at some point. IMO, IANAL and all that, that's a significant business risk for anyone using Terraform, for any purpose.
I'm sure it's hard to turn FOSS into money. I sympathize. But poisoning the well too discourage competitors will drive everybody away.
But could they really? Who actually developed the AWS provider?
My biggest problem with terraform over the last few years is that it always feels like they haven't been investing enough development in it. This has been spelled out directly by Terraform employees in their github issues, and it's visible by inference in the way that they disengage from certain issues.
Wow all these three companies have products offering automation using Terraform. Obviously they would be against the license change.
I know that I downloaded and learned Terraform because it was free of charge only. I honestly didn't care and I didn't know about its specific licensing status. I was able to quickly and easily install, configure, and run it because Hashicorp made it available as a free-of-charge download. Period, full stop.
Compare it to VirtualBox, which is clearly not F/OSS, but gratis to download and use. In fact my employer mandates our use of VBox, so we all download it, irrespective of license terms. It's extremely popular, even outstripping qemu and other libre VMM implementations.
Plenty of orgs will give you gratis products until you hit a certain usage level, and then they fly out a salesperson to get you onto an enterprise contract. We had zero interest in those shenanigans.
VirtualBox is GPLv2 licensed, so it is F/OSS.
https://www.virtualbox.org/wiki/Downloads says
"The binaries are released under the terms of the GPL version 3" and the sources are here - https://www.virtualbox.org/browser/vbox/trunk
(up to V6.1, it was licensed under GPL v2 - https://www.virtualbox.org/wiki/GPL )
And VirtualBox is available in Debian: https://wiki.debian.org/VirtualBox notes that "A proprietary extra package enhances the base experience, adding things like RDP access to the Guest. "
Gratis but proprietary means that the vendor retains full control, which they have an incentive to (ab)use, making it a riskier bet for a company.
I do hope you're not using the non-FOSS extension pack for a business while ignoring its license, or you're going to have a "fun" conversation with Oracle's sales/legal department...
No, it's the extension pack that is closed source and under a non-GPL license. The guest additions ISO is commonly confused with the extension pack, but they have completely different spheres of influence and functionality. Guest additions is GPLv2, just as the main app is.
If you don’t want to build your own Terraform CI solution you’ll be forced to buy it from HashiCorp.
React wouldn’t have the adoption it would today if Meta were to have done something so untrustworthy. So many organizations would have avoided it entirely because they would have seen that as untrustworthiness and a business risk.
https://lwn.net/Articles/942346/
Notably, while AGPL is probably not the best license for unrelated reasons, most people do not have any conceptual qualms with the AGPL. I can not say the same for the pretend-open licenses that have been being pushed through with all of the usual excuses.
Also, robust open source projects have outside contributors. When you're contributing to an open source project under open license terms, it's mutually beneficial. But why would other companies willingly contribute to closed/shared source projects? What exactly is in it for them? Hence the resources that are being dedicated to OpenTF.
Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project you work on later.
The reasoning goes that if you see something useful in an AGPL project and decide to use it (not copy and paste but actually recode it from scratch), the AGPL license follows that code in your head.
It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss.
Google (and other large enterprises) definitely claims this, though honestly I think the main problem with the AGPL is the mechanism by which it works, not necessarily the idea behind it.
> and that even viewing AGPL code might taint any project you work on later.
Never heard this before. I also have no idea why this would be any different from other potentially-not open source software licenses.
> It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss.
For patents I understand why this is the case even if it's not necessarily an ideal situation, but for AGPL it's still just copyright law at play, regardless of what the restrictions are. I don't understand how this differs from other licenses so strongly.
If code from agpl licensed product is found in a closed source SaaS offering, then the entire SaaS offering must be made open source.
Copying can be accomplished through either copy/paste or mental reading and retyping.
This is different from BSD where just the copyright notices need to follow the code.
You may be confusing the AGPL with SSPL. MongoDB switched to the SSPL from the AGPL, wherein terms were added that would imply that you essentially do have to open source the entire SaaS offering, not just the components that make up the program. Whether this is even enforceable or not is curious to me, because honestly, it seems dubious: how can a copyright license apply to other copyrighted works arbitrarily that are otherwise unrelated?
However, AGPL is even less stringent than it seems. Because it aims to be a copyright license rather than a contract, the AGPL is phrased in such a way that it is not "triggered" unless the code is actually modified[1]:
With the AGPL, there are two triggers that both have to occur for the source code sharing requirement to kick in:
1. You’ve modified the program.
2. You make the modified program available to people remotely through a computer network.
[1]: https://fossa.com/blog/oss-license-compliance-expert-heather...
The usual somewhat pejorative figurative term used to describe the requirement for using the same license on derivative works is “virality”, in reference to being like a virus, not “virility”—“the quality of having strength, energy, and a strong sex drive; manliness”.
https://www.linkedin.com/in/vanlindberg/
Basically the license was read differently based upon the community -- particularly in subtle ways.
You can say, "Well... it's the GPL it means this and exactly this." But that presentation convinced me that different licenses can have different readings -- particularly depending upon the community.
It's worth noting this is google's take on it AGPL is here:
https://opensource.google/documentation/reference/using/agpl...
"...we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner."
For GPL, the main question is what constitutes linking. Let's read the text.
> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
This does leave some room for interpretation, but the intent is pretty clear to laypeople: when you want to distribute a GPL-derived work, you have to distribute the source code in such a way that users are able to build install and run it, including any required subprograms. What this DOES NOT do is implicate other unrelated programs. A program that e.g. merely communicates with a database is not intended to be implicated here.
The thing about this that I think is important is that the GPL can only concern things that are plausibly possible to consider derivative works of the software, being a copyright license. Obviously, as a layperson, I do not know exactly what nuances and what range of opinions exist on what a "derivative work" actually entails. That said, it doesn't seem to be that controversial on it's face. I found this explanation from Adam Blaier of Brown and Blaier Attourneys and Councelers at Law[1]:
> Derivative works are new, original works based upon one or more existing works. In software and computer programs, this includes lines of code. Creating a software derivative work involves modifying the source code of an existing computer program either by revising it or translating it into another computer language. Simply linking to the existing original code in a library program without modifying it does not create a derivative work. Using a plug-in or a device driver also does not create a derivative work, even if you look at the program’s source code to determine how to use the plug-in or device driver.
Note that in this interpretation, merely linking to a program does not create a derivative work. In theory that would actually make a lot of GPL linking exceptions unnecessary, if I understand correctly. I presume that the FSF would disagree.
To me, that's the real gray area.
> It's worth noting this is google's take on it AGPL is here:
I worked at Google and went to their legal classes (the ones you have to take when you join.) It's FUD bullshit. Google's "legal stances" are motivated by their desires to uphold some kind of status quo. They leaned really hard on this when it came to their IARC and open source policies, and when I asked (multiple times) why they simply couldn't just be less strict than the law (since obviously, they do not have to choose to hoover up as much intellectual property from their employees as possible; they could always, y'know, decide a reasonable divide and put it into the contract) I never got a reasonable answer even one single time. I can't imagine, for the life of me, that this concept never occurred to anyone at Google. And you may think I'm being unreasonable, but every. single. time. this came up, there was a sob story about how they have to do it. They told people this, and most of them presumably just believed it without realizing it's totally within their power to just not handle copyright assignment that way if they don't want to.
So then why is Google so heavy on AGPL FUD? Simple. They don't want people to use AGPL. They want people to use Apache 2 because then they can do whatever they want with it. AGPL does technically pose some risks, but the risk is not that a judge is going to rule that the entirety of google3 has to be released under the AGPL license or something stupid like that. (Don't get me wrong, they can't use AGPL in their main monorepo, that'd be a terrible idea even with automation that ensures license compliance. But, the idea that they can never use AGPL ever at all is pure comedy. Sincerely.) Google's stance on AGPL is about as convincing to me as Nintendo's stance on the legality of emulators.
And don't think I'm some sort of stupid Stallman zealot, I use ISC license on nearly everything I release, because I simply don't give a shit. However, I find this degree of buying into FUD a little disgusting.
[1]: https://brownandblaier.com/blog/derivate-works-and-software/
> Simply linking to the existing original code in a library program without modifying it does not create a derivative work. Using a plug-in or a device driver also does not create a derivative work, even if you look at the program’s source code to determine how to use the plug-in or device driver.
This is clearly debatable. Tainted linux kernels are a thing. It's one thing if you distribute a kernel with a proprietary driver (nvidia comes to mind here). It's another thing if you ship a GPL kernel, and another if the user decided to taint their own kernel with a driver with a proprietary license.
The combined program here is the Kernel and the Nvidia drivers. You can't get around it even though the NVidia drivers are "weakly" linked into the kernel.
The question is at what point is "linking" established? During compilation? During dll loading? Or when you hit a rest endpoint?
Oh please, that's nothing but FUD. If this were true, then working on closed-source proprietary code for your employer would taint any project (open source or proprietary) that you work on later. Clearly that's not the case.
> It's not dissimilar to a certain argument of patents.
It's quite dissimilar. Patents and copyright are two very different legal regimes.
https://www.paulaoki.com/.admin/930108.oppose.html
So some of us thought this was a hilarious concept, and some joker printed up tons of mugs, tee shirts, and baseball caps which read MENTALLY CONTAMINATED, and they sold them at the Usenix conferences for a while. It was good for a laugh.
And that's why Linux won.
My friend at the time said Linux's codebase was terrible compared to netbsd....
I'd say it was a perfect storm in this regard. Sure, the lawsuit gave proprietary Unix a bad name. But that, in itself, wouldn't have been a death knell, if it weren't for these other practical factors.
How much did HC pay to use Go or Linux? Face it: we all free ride off others’ work, and in turn, they use ours. And look at how much amazing stuff we all have — for free! — because of it.
In that regard our profession is a shame when comparing with other industries.
Everything we do is built on the shoulders of giants. If we’re very lucky, we’ll make something nice that others will want to build upon in turn.
As consumer from commercial software, and someone that has paid FOSS developers since the mid-90's, I am quite comfortable doing statements about people abusing other people's work.
I will give it 5 years time.
Yeah... that's not what you meant.
Virtually no one is actively disagreeing here with Hashicorp's right the charge money for the software they built. But it's just a different model, in which so many outside contributors would not have been... contributors.
So when yet another company finds out that when VC money runs out, someone has to actually pay for something, everyone gets the pitchforks.
Meanwhile in other professions, when someone does something for free, that is charity.
If you choose to license it under a permissive open source license, you go into that expecting you won't get paid.
For the record, I'm an open source developer myself, and do not expect to get paid for my work. That's fine, and I'm perfectly ok with that. What I won't do is wait for people to depend on my work and then suddenly change licensing in order to exploit them.
If Hashicorp wanted to stop “free riding” the solution was and is simple: don’t make Terraform open-source.
Open source works well without (much and often any) money involved. Businesses don’t. This is why open source is not an automatic business model.
Yours, someone who has spent the last 14 years maintaining a popular open source project mostly without any money and now with some donations.
Now that they have gotten what they want (get big) they have decided to alter the deal. That upsets people.
If HashiCorp didn't like that, they should have made TF proprietary in the first place. But of course they didn't do that: they knew that if they'd done so, they would have gotten very little traction. But now that many people and businesses depend on TF, they've decided to change the rules. Pretty scummy.
I don’t think forking is bad for terraform ecosystems. It might be bad for HashiCorp, but for community in general it can become that source of competition that will make terraform even better.
Let’s be honest, most of the modules are made by community, there are thousands of modules out there.
HashiCorp recently spent all their love on enterprise related products (like TF Cloud) and almost no love on terraform itself. Our team tried TF Cloud (because it’s HashiCorp, it should be a great product, huh?) and the experience was horrible.
If we let HashiCorp do that licensing trick they as a company won’t have any incentives to improve terraform.
That's might be the current situation but it does not mean that will last. If the license changes again or if they e.g. decide stop the development, it will be a lot harder to make a fork in order to e.g. keep up to date with security patches.
> these problems with the Terraform core repository are not new
> The only material change over the past ~14 days, in our opinion, is that certain business’s have had their margin profile change.
Often people deal with things until something breaks camel's back. In this case it was the license change for many companies/users and hopefully it will mean that OpenTF will end up fixing those earlier problems as well.
From my point of view: Stick with a real, copyleft license that has less adoption by other enterprises and focuses on organic growth instead of VC-driven hypergrowth. Alternatively, be prepared for the consequences that Amazon or other hyperscalers will attract a large number of potential customers using your product without giving anything back. In that case, establish another source of income right away. One has to be realistic: Competing with your open-source product's SaaS against a SaaS by Amazon or other hyperscalers will not work out if that's your only way to make money.
Edit: typos, grammar
Do not forget it is those companies which provide the choice to the users and Hashicorp strives to restrict their choice.
Hashicorp should not be seen in the vacuum. What is point of it all ? The point is Hashicorp is looking to monetize their ecosystem better, meaning making things more expensive for customers.
You probably seen RedHat's play - kill CentOS to improve RHEL monetization, not enough ? Take the next step to try to kill off some alternatives