4 ms·

As a Free Software advocate and supporter, I'm thinking about the answer to this question: - MPL is a weak-copyleft license, which allows companies to grab and

As a Free Software advocate and supporter, I'm thinking about the answer to this question: - 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.

smarx007 3y ago
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?
- bayindirh 3y ago
  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.
  - smarx007 3y ago
    > 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.
    - bayindirh 3y ago
      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.
      - smarx007 3y ago
        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.
skywhopper 3y ago
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.
pxc 3y ago
> 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.
yellowapple 3y ago
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).
ecnahc515 3y ago
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.
jaggederest 3y ago
> 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.
- spencerflem 3y ago
  How is them shutting down and them continuing under a closed source licence any different for you?
- stu2b50 3y ago
  > 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.

smarx007 3y ago

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?

bayindirh 3y ago
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.
- smarx007 3y ago
  > 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.
  - bayindirh 3y ago
    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.
    - smarx007 3y ago
      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.

skywhopper 3y ago

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.

pxc 3y ago

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

yellowapple 3y ago

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

ecnahc515 3y ago

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.

jaggederest 3y ago

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

spencerflem 3y ago
How is them shutting down and them continuing under a closed source licence any different for you?
stu2b50 3y ago
> 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.