We're already exploring alternatives. Future client projects may not use Terraform at all.
Languages and frameworks must remain open or they will wither and die.
- MPL is a weak-copyleft license, which allows companies to grab and run Terraform codebase, provide it as-is (as Terraform), or as white-labeled Terraform compatible feature/layer. This is alright (because license allows this).
- These people also contribute their own fixes upstream, which is great, and maintain their own patches if Hashicorp decides to reject them (which is fine, too, this is how ecosystem works).
But, HashiCorp says that, the thing we develop (i.e. Terraform) is used by others and generate revenue for them, this is great, but we can't generate enough revenue from it to keep the company afloat and continue providing TerraForm development, and sell it as a product at the same time.
What should they do? I'd advocate AGPL, but xGPL licenses are avoided like a plague, because Free Software is not "closed forks" friendly, and companies hate to open everything like that.
BSL is neither Free nor Open, which we all hate, but it allows HashiCorp to survive to a degree (this is not a fact, this is what HashiCorp is thinking).
So, just because people adapted it, and HashiCorp cannot survive, should they say, we're closing shop, it's all MIT now, do whatever you want, bye!?
Weak copyleft licenses are not designed for software that big. Or they assume that the developing party is untouchable. Strong copyleft solves this, but companies hate it because its unrelenting transparency.
What should we do?
P.S.: I neither endorse, nor support BSL, or HashiCorp's decision (or any company treads the same path).
Edit: I mistyped MPL as permissive instead of weak-copyleft. Corrected, sorry.
> What should they do?
Suck it up, open source Terraform under a non profit foundation, find a new source of revenue. Or stop developing Terraform, cut expenditures, and move on with life.
There's no universe where "bait and switch customers who wanted open source into paying us by switching licenses" is a viable option.
> So, just because people adapted it, and HashiCorp cannot survive, should they say, we're closing shop, it's all MIT now, do whatever you want, bye!?
Exactly, you know the answer, you just don't like the implications. People somehow think that a business which started an open source project "deserves" to profit from it. They do not. Open source is a great way to get people to know who you are and build things that are interoperable with your (proprietary, closed source) SaaS offerings. It is not in itself a revenue source.
If the viability of your business is predicated on being the only one able to provide your project as a service and earn that service revenue gravy, just leave it closed source and proprietary. Sure, you won't get adoption at anywhere near the rate, but that's the tradeoff you make.
How would that be an improvement to anyone in any way? If you want, you can just pretend that Terraform is dead and Hashicorp will never push another commit for it. The people who can make the compromises BSL has can continue to use it.
> If the viability of your business is predicated on being the only one able to provide your project as a service and earn that service revenue gravy, just leave it closed source and proprietary. Sure, you won't get adoption at anywhere near the rate, but that's the tradeoff you make.
I don’t understand why this is a binary. If the conditions of the BSL are unacceptable to YOU that’s fine, just pretend it’s closed source if you wish. For others, that the BSL isn’t completely proprietary is useful for them - let it be useful. Your wishes need not dictate everyone else’s.
No. It was not a rhetorical device.
> you just don't like the implications.
I don't know which implications you're talking about, it was a question without prejudice or load.
> People somehow think that a business which started an open source project "deserves" to profit from it.
I do not agree. I don't hold a position stating that "TF should stay open, and companies should profit from it while giving it patches if you feel like it". I'm the opposite, and I find the approach to permissive licenses as "Ooo... Free tool to build a new product on and profit" as unethical to begin with. I put anything and everything I put out as A/GPLv3 or GFDL, because I produce that code for myself, on my free time, and I don't have a secret desire for it to be forked and closed down for internet cookie points.
If you want to use my tool for any reason (which are not very sophisticated to begin with), comply with GPL, or roll your own. I. Don't. Care.
I also pay for tons of things. Docker, cloud storage, programming fonts I use, anything I deem worth the money they're asking for.
I also use Vagrant a lot, share my Vagrantfiles (again under GPLv3), and if they begin to charge like Docker, I'll pay for it, if I deem it's worth the money they ask for.
However, at the end of the day, I'm a Free Software advocate. I use Free Software to the extent possible, and develop my software as Free Software. Not Open Source software under some permissive license to be grabbed and forked to death.
However, it still allows your code to be bundled inside a bigger work. The bigger work can be in any license (maybe not GPL, need to check), but MPL stays MPL. This doesn't prevent white-labeling the codebase, though.
As far as I read the MPL, the contribution back part is not mandatory, but encouraged by not affecting the larger work. It keeps the MPL part open, but doesn't enforce a "send patches back" policy.
That's not how I read it.
> the contribution back part is not mandatory
In that case weak copyleft would not be any different from MIT/BSD.
First, assuming you are distributing only the larger work:
"3.3. Distribution of a Larger Work
You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. [...]"
Assuming the covered (OSS) work is distributed as an executable:
"3.2. Distribution of Executable Form
If You distribute Covered Software in Executable Form then: (a) such Covered Software must also be made available in Source Code Form, as described in Section 3.1 [...]"
Finally, 3.1:
"3.1. Distribution of Source Form
All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License."
The only wiggle room I see is not triggering the distribution clause by a SaaS-only offering. By the way, EUPL is a non-viral copyleft license that closes the SaaS loophole in MPL/EPL/LGPL.
Otherwise, I think I clearly noted that the MPL part's source stays available whatever you do by saying "MPL part stays open".
It's not the earliest hour here, so sorry if I can't articulate my thoughts clearly.
You need to keep MPL part's source open and accessible, yet MPL doesn't prevent abuse like permissive licenses, much.
Rolling up a tar of your source tree, however, will be required if you get a request from one of your customers by email. The difference from GPL is that you will only have to tarball a portion of the tree that was MPL-licensed. That tar must include your patches, as §3.1 requires.
As I said before, many companies argue that using a private fork of an MPL/EPL/LGPL software in a SaaS does not trigger the distribution clause as customers never get a source or a binary of the program that runs in the cloud. EUPL closes that loophole.
It's also possible that many companies violate EPL/MPL/LGPL terms (knowingly or unknowingly).
One good example of non-viral copyleft working as intended is the Eclipse IDE. There are many closed-source tools that use Eclipse IDE under the hood (the part that Eclipse calls RCP), but there are no commercial forks of the IDE itself because any such company would have to open-source their changes to the fork.
They can offer it under more than one license if they want. I, for one, would be pretty happy if they offered it under both BuSL and AGPL.
- business users who are afraid of copyleft could use Terraform under the terms of the BuSL
- the F/OSS community could distribute it under the terms of the AGPL and freely build on it
- competitors to Hashicorp would have a choice:
+ open their whole stack and compete in the market based on the quality of their services and support alone (admirable but very tough)
+ negotiate and pay HashiCorp to license Terraform under special, proprietary terms
Put simply:
> we can't generate enough revenue from it to keep the company afloat and continue providing TerraForm development, and sell it as a product at the same time.
They were never selling it as a product in the first place. It's more of a loss leader if anything; Costco has its $1.50 hot dogs to attract customers to buy memberships, and HashiCorp has Terraform (and its provider/module ecosystems) to attract customers to buy Terraform Cloud (and Vault, and Nomad, and everything else they actually do sell).
It is harsh, but they’re a public company now, not Mitchell.
Would terraform have been as popular it if had never been open source? That we won't know, but we can guess.
Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers?
If I wrote an open letter decrying Salesforce for not open sourcing their codebase, nobody would take me seriously. But we expect better from Hashicorp for some reason.
[Docker] can barely muster a viable business
Ditto for earnings: once your company is publicly traded or at least lands in a Gartner report, you don't need evangelists that badly anymore.
Free pull requests are always welcome, but I guess a calculation was made in this case.
In this case the customers they're losing (as well as the devs, testers, reporters, etc) aren't end users but companies who have built software offerings on top of Terraform. That's the class of user principally impacted by the change to the license. OSS users aren't stoked about testing, but developers who build on top of Terraform in order to eat will submit bug reports and PRs all day.
'They' as in Docker Inc.? They made it accessible for the masses, which counts for a lot, but they built on a lot of pre-existing Linux kernel tech that other people who envisioned containers put in place before Docker came in and seized on the opportunity.
> can barely muster a viable business.
They perused what proved to be the wrong business model until 2019, nowdays they're more than 'barely' viable.
100%. Docker's UX has always been its killer feature, and it counts for a lot. That's a very real contribution. But this is absolutely still a 'shoulders of giants', 'it takes a village' situation.
The photoshop effect*. That is to say, devs that are familiar with it will push their workplaces, because it's a pain to pick up yet another tool when you know one that will work.
*A largely hypothesized reason photoshop was so easy to crack back in the day, was that Adobe knew that if kids grew up using photoshop, businesses wouldn't be willing to spend the money re-training their employees, and would just buy a photoshop license.
I'd wait and see what happens with OpenTerraform. If the fork gains some good momentum, it would be the easier choice. Usually, you should be okay with using the latest FLOSS version for a few weeks/months until things settle anyway.
Citation needed. I don't think it costs very much at all.
Terraform is neither a language nor a framework, and I certainly don't think it will wither and die if they transition to BSL. Case in point, docker's revenue grew by 12x once they started taking control of their code and stopped caring about community. Same with postman or nginx or many other companies.
You can absolutely bet that they would get dropped like a rock if they moved to changing the engine's license. Even the docker desktop code wasn't ever open to begin with anyways.