I don't think that's what GP means by "legally binding"

When a company gives you a license that has terms written in it, that license is binding... on them as well as you. When a company gives you a document that refers to an FAQ that they can change on the fly to meet their needs, and make changes to it, that is a signal that they do not view the license's terms as binding on them. Only on you (the user / developer working on an integrated or derivative work.)

The license that grants you permission to use the software as long as you remain on the right side of this line, which we can move as we deign it necessary to move the line is not much of a license grant. I just heard it called "bullshit license" and I think that's the best explanation for what BSL actually stands for now.

I support Hashicorp's right to make money from their business, but I think these lawyers are in over their head. It doesn't make much sense to me. We'll have to see who gets a license grant from Hashi and how much they're going to pay for it.

Having worked with lawyers on software licensing, and knowing how verbose they are, I'm confident that whoever added the Additional Use Grant in the BSL was not a lawyer and did not get it reviewed by a lawyer. There are no definitions for "hosted", "production use", or "embedded". The plain language definition for these words is not concrete enough and thus the FAQ.

legal documents refer to other documents for specifics all the time, these are legally binding references

So they just added a new FAQ because their license was unclear, it's got a "last updated" date under every single entry. What assurances do we have that these binding statements won't be changed in the future? It looks as though they have definitely made changes to this page at least 4 times since it was published, in only two weeks.

https://www.hashicorp.com/license-faq#future-competitive-pro...

If in the future HashiCorp creates an offering then they will exempt me from action under the BSL according to this section. What is the likelihood of this changing later on? What is my recourse if it does? All of these questions, you can ask yourself (and your lawyers, again and again each time) now of any open source project that makes contributors sign a CLA. Since there was nothing stopping HashiCorp from doing this, what will stop others?

This is a terrible thing for Open Source IMO. Competition is good, but I understand HashiCorp have some competitors that are leveraging their good will against them and costing them deals. I hope that Hashi don't use this new license to squash their competitors and stamp out Open Source. But I won't take that as foregone conclusion, it's up to HashiCorp how they pursue these changes and up to the rest of us how to react when they do. I've got my fingers crossed for good.

> leveraging their good will against them and costing them deals

Spacelift co-founder here. I keep seeing this argument, and I'm puzzled. What good will are we talking about, and how are we leveraging it against anyone? Is building a good commercial product that folks love on top of an open source ecosystem somehow unethical? And if so - why? I used every opportunity to try and help Hashi build something better on top of core TF, both personally (applied for a job on their TFE team back in 2018, talked about many ideas that then went into Spacelift instead) and as a company (we tried VERY hard to partner). All to no avail.

On the other hand, for 9 years non-Hashi folks (including ourselves here at Spacelift) spent countless hours, for the first years contributing to Terraform core, and more recently when PRs were no longer accepted they were still busy building providers, modules, tooling, courses, tutorials, cheatsheets, they've been running local meetups, all powered by the open source ethos and the common good.

Not really sure who is leveraging whose good will here.

To me, this is the core bait and switch problem. It’s not just that expectations and commitments are suddenly unilaterally changed. Is that the core subject of the license (an open-source codebase) has quite often been built collaboratively with the agreement and contribution of entities outside of the organization unilaterally claiming domain over the underlying work.

If this is somehow permissible under the original license, it points to needing licenses that offer more consistency and protection. If I contribute to your project, I want to make sure that you can’t close the door on the codebase whenever you feel that you’ve harvested enough value from me, value that you’re now going to go monetize with others.

Would you want outsiders dictating how your projects evolve? What if someone came along and monetized your project and didn't give any money back?

Every project, company, contributor, and community get to decide this for themselves. There are no easy or correct answers

When you've had thousands of hours of free external contributions to the ecosystem, where is the actual ownership? Is it still "your project"? And if so, to what extent? What are your obligations to the community members and/or external contributors?

On the monetization question - do you need to give others the opportunity to give money back? If so, who should assess the size and "adequacy" of these contributions? If you don't provide the opportunity for others to sponsor the project, does it change your rights and obligations?

These are not easy questions, and now our entire industry is trying to work out the answers. OP's is one voice in this discussion, and an important one given GitLab's prominence and the fact that they took a different path, which seems to be working well for them.

It's also a way more complex problem for software like Terraform that explicitly depends on the work of others for its core functionality than for something that works perfectly fine standalone, like Hashi's Vault, or indeed GitLab itself.

I wasn't talking about you at all. And I honestly haven't followed the conversation you (SpaceLift in particular) may have been having with Hashi or not, though I am absolutely aware of and maybe even in the same boat as you. I think this is an issue between Hashi and some V.V.large players, I suspect that there are big companies who are selling deals that say they "support Terraform" when they aren't actually building it or supplying labor to Terraform as a code project in any meaningful way. But they derive value from a pledge in their real big money contracts to "support Terraform" which in reality costs them nothing except that they will have had to accept the license terms, clearly, whatever they are at that time.

They sell licenses to major (even government) institutions and Hashi OSS might be used as part of the solution, but Hashi aren't getting a cut of the deal. Let's say. I think those big companies want to have Terraform support with a capital T, and it would diminish their marks substantially to switch streams now and edge out Hashi, the smaller player (who is actually doing all of the work), by supporting OpenTF – separating them from ongoing development efforts of HashiCorp who undoubtedly are expending some significant labor to make and maintain Terraform itself.

But I don't think it's right for Open Source companies to pull the rug on other companies that have built successful products on them. I think the best outcome possible for Spacelift and companies like it now is the OpenTF route (assuming you can't get a suitably proper BUSL license grant from HashiCorp, which it seems like you might if you get them to declare you "not a competitor" even once, according to the FAQ as it reads today. IANAL.)

I think you're using the MPL software as the license was designed, and your company should be able to deliver Terraform with additional value provided through the interface and the scaffolding (eg. better Terraform Cloud) that you built around it, and charge money for it. But of course I'm not the lawyer. I am very glad to meet you here though!

> I think the best outcome possible for Spacelift and companies like it now is the OpenTF route (assuming you can't get a suitably proper BUSL license grant from HashiCorp, which it seems like you might if you get them to declare you "not a competitor" even once, according to the FAQ as it reads today. IANAL.)

IANAL as well, but this sounds like a HUGE trap. Will that protect you from their next licensing change and its restrictions?

Is such a declaration transferrable? Would it limit Spacelift's exit strategies because they would be unable to ship their product if acquired?

If there is a community where the new licensing terms no longer meet people's needs, then something like OpenTF is absolutely the right way to go. Anything else, and your company is operating by the grace of Hashi.

> your company is operating by the grace of Hashi

Well unless TF competitors were prepared to go off and build their own (OpenTF) it's as you say anyway, Terraform doesn't just spring into existence without Hashi building it first. If you are building on it, then you have it to build upon because they built it first. License changes notwithstanding, if the ongoing efforts of HashiCorp today are worth anything to you, then it's to your advantage to go on supporting TF with a capital T and disregard the fork. But if you think they will try to extract more than their contribution is worth from you, then the choice is clear...ish. How much will it cost you to form and maintain the fork?

It's a tough calculation. Will you derive more benefit from the partnership with Hashi (assuming they're amenable to forming one) or will you derive more benefit from the ownership associated with building your own OpenTF? How much will it cost? Must be all companies with a Terraform arm are doing this calculus right now, trying to figure out if there is a "support both" option they can live with, or otherwise if they're going to have to pick one, how to not pick the loser.

I understand that for some companies the calculus may be obvious and the choices clear. If your entire business depends on Terraform, then accepting all the terms might as well be tantamount to accepting a full buyout without any price tag. It's a pretty big no-brainer of a "no deal!" but on the other hand if you are VMWare or RedHat and you need for your contracts to support Terraform with a capital T... I think it's those companies who can't just say "we support the fork" and move on with business as usual, without taking a big hit to the credibility of their support promises. Will they actually participate in a fork, if they say they support it?

(What does that signal about their commitment to the tech if they do, and can you even support both without putting yourself in a precarious legal position?)

This is a great comment -- there's a lot of wisdom in here for anyone contemplating repeating Hashi's mistakes!

We do t know if it was a mistake, only time can answer that.

We for one have no impact or intention to stop using Hashi products

We do know. Now.

All your comments are full of unknowns and conjectures and astroturfing. It shows you're not very knowledgeable about this topic at all.

> What assurances do we have that these binding statements won't be changed in the future?

Companies change their Toss and other legal docs all the time, this is just another one, though not typical. Their FAQ now has legal obligations for both parties, unlike how we see most FAQs

This FAQ literally changes daily and different versions directly contradict one another. So which one is "binding" - the Aug 15th or the Aug 22nd version? Or perhaps the former was "binding" for a week, now the latter interpretation took over, until in two weeks time something else becomes "binding"? This is worse than the license change itself.

You change the license once, everyone gets to read it, reflect on it, speak to their lawyers if they're not sure about it, and move on. Using the mutable FAQ in lieu of an immutable license is just a sign that the interpretation is purely based on the vendor's (mutable) business goals, and you should be very careful building on any particular "binding" version.