Hacker News Reader

> 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?

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 is them shutting down and them continuing under a closed source licence any different for you?

> Or stop developing Terraform, cut expenditures, and move on with life.

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.

> Exactly, you know the answer,

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.

> 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.

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

Probably, many of the same companies who want to fork Terraform now would still want to. But I'd be satisfied and it would likely shift the conversation in a way beneficial to Hashicorp's reputation.

MPL is a copyleft license, actually, just like EPL and EUPL. What it is not is a viral copyleft license. Anyone making changes to TF code and productionizing it is expected to contribute back but only the direct changes to TF itself, not the extensions around it. That's my reading of EPL/MPL/EUPL. Does that match your reading?

You're right. MPL is a weak-copyleft license. I mistyped it, I don't know why. Fixed my comment with a note, thanks.

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.

> As far as I read the MPL, the contribution back part is not mandatory

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.

By contributing back, I mean rolling up a patchset (or a tar of your source tree) and sending back to upstream.

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.

True, sending back to upstream is not required by the license. But even AGPL does not require this.

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.

IMO: HashiCorp is in this situation because they want to grow too big, too fast. A lot of their software is tooling, tooling that doesn't necessarily make sense to sell in a SaaS offering, or if it does: it's going to be commoditized. However, SaaS is where the $ is. They have investors they must please, and they want a big return on investment. It's probably too late to fix this, but IMO if they took the slow and steady route of providing support and professional services HashiCorp could easily be profitable while maintaining all of their products, but perhaps to a lesser degree.

HashiCorp has plenty of revenue and that revenue is growing fast. They are losing money, but that's to be expected during the high-growth phase of their lifecycle. If they are having trouble growing as fast as their investors want it to, changing their licensing is not the way to fix it. This change is unfortunate because it won't bring serious new revenue to the company but it is a major blow to the reputation they had built.

It ain't like Terraform itself was ever a huge moneymaker. Terraform Cloud (i.e. the fancy-shmancy Terraform backend), maybe, but the actual language, the providers, the modules, etc. are all pretty universally free-as-in-beer. The only way to make money with them is to use them to build something else that then makes money.

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).