I replaced “Terraform” with “XFree86” and “OpenTF” with “X.org” as I read it, and the arguments sounded so familiar.
“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!
> That being said, after HashiCorp’s CTO released “binding” answers to some of these FAQs, it seems clear that the only folks who this affects are those that sell software to other companies.
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.
hashicorp.com is not a random site. While an FAQ does not necessarily constitute a license, this FAQ Hashicorp is binding so it becomes an extention of it.
How exactly are we assured that it is "binding"? That FAQ says "we view the guidance in these FAQs as binding", but what guarantee is there that that "view" won't change in the future as they become more hard pressed for cash?
Because if it says so on their website (especially if it also says that it's binding), then they have it in writing and you can use that as evidence. 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?
The operative issue is likely that there is no agreement here. Hashicorp did not provide those statements as part of the agreement, and you were not presented those terms as part of the agreement, so why would they be construed as part of the agreement?
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.
If they are binding why not add them to the license? Rights for GPLv2, Apache 2.0, etc., are defined in one place. That's one of the main strengths of those agreements.
> 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.
Totally agree. You’ve done a great job articulating my feelings on the matter as someone who writes a lot of TF day in and day out (end user, not an integrator/consultant/etc).
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.
You're probably right. But they should find a new name. Terraform is a trademark and it will confuse potential adopters - even if they stick an 'open' in front of it.
Who is this dragon company and what weight does their opinion hold anyway? Most of these reasons to not fork are pretty half-baked.
> 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.
My biggest concern is the legally untested clause in their BUSL on ‘competing with hashicorp’. I do not know whether I can run Terraform from a production control panel to start new infra for customers. I do not know when this competing might change.
Their faq comments are useless: they had a faq item before saying they would be FOSS forever which they removed with this move.
This is the core of the matter. With the language of their license, they have a financial incentive to start offering services that increasingly cover more and more of the possible "bulk" use cases.
Your use might have been perfectly fine last week, but can be competing with their new offerings from the beginning of next week.
The arguments presented by dragondrop are a classic example of FUD. The author is afraid of what Hashicorp can do if we don't just ignore the license change and pretend nothing happened. Based on that fear, they present various scenarios that seem scary to them. But when you look closer, these fears are ridiculous.
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.
I don’t agree at all with the arguments here. Terraform is so widely adopted that it has become a basic, almost built-in component of every cloud ecosystem. Hashicorp would have been better off by treating it as a Trojan horse into enterprises and focusing on its other assets. I expect there will be a newcomer that will take advantage of this mishap and we’ll be talking about their solution next year (unless OpenTF manages to win people over).
> You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.
> 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.
> HashiCorp could feel forced to strengthen its position and introduce incompatible differences in new releases of Terraform and major-cloud providers
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.
> Notably, the three largest companies that most-directly compete with HashiCorp’s managed Terraform offerings, Spacelift, Env0, and Scalr, all have made multi-million dollar pledges to support a fork of Terraform (13 FTEs for five years between these three companies).
Wow all these three companies have products offering automation using Terraform. Obviously they would be against the license change.
Because it was libre, or because it was (is) gratis?
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.
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. "
We started using it because it was open source, as is almost everything else noteworthy in that space.
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.
> In fact my employer mandates our use of VBox, so we all download it, irrespective of license terms.
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...
Thanks for your concern. No, the extension pack does not contain any features we use, at all, but of course, this is on an individual, unmonitored, BYOD basis, so whatever the employees do is on them, I guess. We haven't been warned either which way about this.
Many end-users just really don't care. Most end-users haven't the knowledge, skills, or resources to accomplish and maintain a fork. That's an idealistic fantasy of a small percentage of elite devs and corps.
> It's the guest additions ISO thingy that's not open source.
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.
And that’s great for the developer ecosystem. HashiCorp wants to lock you in to Terraform Cloud and start jacking up the price because they EULAed away competition.
Too late to edit my first reply to you, but I wanted to add that this situation would be like if Facebook said you can’t use React to make a social media website.
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.
It’s absolutely crazy to me that other companies free-ride off of companies like Hashicorp and Mongo’s work and the free-riders are the ones many - particularly on this site - support.
It gets pointed out every time that this is not the case at all. It's not even subtle; it's about open source and the not-so-fine line between protecting your business model versus exploitation.
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.
> most people do not have any conceptual qualms with the AGPL.
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.
Huh? I am not a lawyer, but I think you have this a bit wrong. It doesn't require that at all. AGPL "virility" is just like GPL virility. If you link to AGPL code, from code that is otherwise compatible with the AGPL, then in order to comply with the AGPL, you need to ship the source code of your entire program, with the same semantics about linking as the GPL. That does NOT at ALL mean you need to ship the entire SaaS offering, just the offending component. It does not include things that communicate with that program over the network. And that's only if that is your choice to remediate the license violation in the first place: if you really "mentally copied" some code, you can have the code in question rewritten.
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.
This is at least in part why the AGPL is arguably not that great, but it's a minor point in the grand scheme of things.
I once saw a presentation once given by a lawyer where the GPL meant different things to different communities (again I'm talking about the GPL here). I believe it was Van Lindberg that gave that talk.
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:
"...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."
I am not a lawyer, but I think this is getting a bit out of hand. I mean granted, GPL does definitely have some gray area, but the gray area that GPL has is being wildly exaggerated. The main thing about GPL that is called into question is its virality, but the virality of AGPL is exactly the same as GPL.
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.
I do remember reading the endless comments on licensing on GPL/LGPL/BSD on slashdot.
> 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?
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”.
> Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project you work on later.
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.
Back in the early 90s, of course the Unix wars were raging hotly. It was posited as a legal strategy by SCO attorneys, that if some developer for BSD had read Unix source code at any point, they would thereby become "Mentally Contaminated" and unable to perform clean-room development of the freely-licensed BSD systems.
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.
There were more factors than that. One was the burgeoning hegemony of the Wintel architecture, standardized with the PCI bus, cheap disks and fast interfaces, etc. The ability of BSD and Linux to leverage this hardware figured mightily into toppling the proprietary giants of the Unix world. Some of these vendors even realized it, such as Sun Microsystems, who introduced PCI-based systems late in the game.
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.
Hashicorp built Terraform on top of other FOSS systems. Other companies built on top of Terraform. And then Hashicorp pulls the rug out. Yeah, I can imagine how those companies are irked, just as Hashicorp would be if Google suddenly made Go proprietary or Linus locked up Linux.
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.
Indeed. I trade favors with my other professional friends all the time: my buddy gives me legal advice, and I audit his security setup. We both win! It’s amazing how nice it is to give and receive quality work without having to swap cash for every little thing.
It’s crazy to me how many people in the software industry consider abiding by the terms of the software’s license, rather than some moral imperative to do more, to be “free riding”.
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.
One of the arguments is that there are many non-Hashicorp contributors to Terraform, not to mention the larger ecosystem, who want a say in keeping their work free. This argument is even extended to Hashicorp currently only spending less than a handful of fte's on Terraform maintenance. If you subscribe to those views, you turn the "taking a free ride" argument on its head.
I'll add that at the end of the day, a maintainer of open source needs to tend to its garden in order to receive contributions. This is a case of HashiCorp failing to do that on multiple levels (devoting too few resources, changing licenses, etc). So people leave to form new communities and that's only natural.
Those contributors work will still be free for the rest of time under MPL 2.0. The change now is that new changes will take 4 years until they become MPL 2.0, but until then those new change's source is still available for people to work with, fix bugs, and adapt to their business's needs.
Yes, it is incredible that a site dedicated to startups and creating companies, has so many people that advocate not paying for the work of others, while expecting to be paid for their own work, made possible by such tooling.
In that regard our profession is a shame when comparing with other industries.
Right, and that's why people are upset that Hashicorp is (in a sense) taking away their contributions to this open source project without paying for it.
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.
The product would have been worse without the contributions. More expensive for Hashicorp to maintain. And if it wouldn't have been free, their value proposition would have been very different. People would've used alternatives, for many of them that'd have meant something homegrown. Terraform would not have been so successful, Hashicorp wouldn't have been as big a company as it now is, as a result. The model as it was was a win-win for everybody. But sure, freeloader competitors may be a fair concern of Hashicorp, thank goodness they solved that problem, didn't they? But at what expense, they are disturbing an equilibrium that was established between themselves and their users.
I expect Microsoft, IBM, Apple...to have paid whatever is required.
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.
Yeah right, saving this reply for when OpenTF fork also goes commercial in a couple of years, or fades into obscurity as the big defenders fail to keep it going.
If you want to be paid for some bit of work, license it such that payment is required.
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.
It's not free-riding to use a project under the terms of its license. Users are in no way obligated to pay or contribute back. (I say this as an open source developer myself.)
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.
There is no way Hashicorp would have gotten this level of adoption (and become this big) as they are today if they offered their products in a classic Microsoft, Oracle, etc. pay to license way.
Now that they have gotten what they want (get big) they have decided to alter the deal. That upsets people.
TLDR; if we don’t keep TF open source in 5 years everything will become Terraform Cloud - horrible, painful to work with Enterprise-grade BS.
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.
> The only companies that need to worry about the license change are those with production products that are “offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp’s products.”
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.
I think many start-ups use open source mainly as an argument for adoption in the ecosystem, and they have to consider the consequences. Many projects avoid choosing AGPL or GPLv3 licenses to facilitate easier enterprise adoption ('Hey, we can use X and create SaaS without hassle') without generating revenue, while being funded by venture capital and without getting contributions back. Then, when they are adopted, they complain. While the contributions from corporations like HashiCorp are impressive, the overall situation is complex. There's a reason why Linux is still around and growing.
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.
Oh My... 99% of users are not affected only companies which have profit motive.
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
“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!