4 ms·

I think this damages all commercial OSS projects. Because after Docker and Terraform, any effort to bring in some OSS project as a dependency will be met with "

I think this damages all commercial OSS projects. Because after Docker and Terraform, any effort to bring in some OSS project as a dependency will be met with "Sure, it's open source now, but what about when...".

charcircuit 3y ago
Most businesses are not directly competing with the businesses making software they depend on
- throw16180339 3y ago
  Some of them, however, may want to be acquired by companies that compete with HashiCorp.
  - sam_bristow 3y ago
    Or HashiCorp might acquire a company you compete with.
    - jen20 3y ago
      Red herring. The licensing FAQ from HashiCorp makes it clear that this would not trigger the BSL provisions. [1]. [1]: https://www.hashicorp.com/license-faq#future-competitive-products https://www.hashicorp.com/license-faq#future-competitive-pro...
  - charcircuit 3y ago
    The aquirerer can pay for license to use Terraform if they want to use Terraform to compete with HashiCorp.
cstejerean 3y ago
The answer is "then a viable fork will sprout up and we can switch to that instead" which is what has happened for every notable widely used OSS project I can think of. And it's not like you have to sit idly while that's happening. A small company might not be able to fork and maintain their own fork but they can pitch in with other companies by providing some development time, or money or infrastructure to help make an OSS fork successful as a community project.
armchairhacker 3y ago
IMO it shouldn't be much different than "sure, it's open source now, but what if it stops being maintained?" Because open-source code never stops being open-source, it just stops getting open-source updates. Closed-source in some situations can prevent you from using existing software; you also have other closed-source issues like bugs being unfixable. Would you rather use a service that worst-case, you have to patch and maintain yourselves? Or a service that worst-case you have to switch to an entirely different service?
- jacquesm 3y ago
  That's true, but for a lot of companies having an entity behind a piece of software will definitely be a major factor in their decision making process so these kind of tricks ultimately benefit closed source offerings. And that's quite annoying. The idea behind open source is very solid, but the assumption that any user of a large package is ultimately able to continue to maintain it is faulty and that means that for a lot of parties the benefits of open source only materialize if someone else is willing to take up the mantle, they are simply not able/staffed/wealthy enough to do this. So every time someone does a rug-pull all FOSS projects suffer.
- scarface_74 3y ago
  > Would you rather use a service that worst-case, you have to patch and maintain yourselves? Having to patch and maintain a complex piece of open source code yourself for most smaller non tech companies for all practical purposes means that it might as well be abandoned closed source code.
  - eschneider 3y ago
    Not really. If you need it fixed or extended and you can't do it yourself, you can always hire someone to do it for you. With open source, you have options.
  - throwaway103xx 3y ago
    Exactly. The end result is the same. Folks are wise to question if they should use OSS that has a CLA assigning copyright because that means they should have zero expectations about the license not changing.
freeopinion 3y ago
I think it shows the huge benefit of OSS. If TF had been closed from the start, users would have no recourse at all. Instead, there is a viable path forward.
- jacquesm 3y ago
  That viability hinges on people actually doing it and the evidence that this is happening at scale just doesn't exist. There are some forks of major packages out there that have been extended but that's because the company had entirely different ideas about the direction in which to take a package. But for the vast majority of FOSS out there the current maintainers are the ones that are capable of doing so and the entities using the package are not able, do not have the funds or the time or people to do so themselves (and more likely a combination of those).
  - freeopinion 3y ago
    The two specific cases cited in the post to which I responded were Docker and Terraform. I think there is a great deal of evidence that people are using alternatives at scale. Let's take a look at some other examples: OpenOffice, Node, Hudson. Of course, there are plenty of cases where forks have not thrived. But that is not really the question. The question is, can you show me a single closed-source project that did something highly objectionable to a large portion of the userbase that was then rescued by the userbase? Can you explain why I should choose IIS over Apache just because there is a possibility that somebody could fork Apache? If either IIS or Apache decided tomorrow that they would no longer support TLS, but only support eeeTLS, why would the Apache situation be worse just because it is OSS and some users might fork it to keep TLS capabilities? It seems obvious to me that in fact Apache is the wiser choice in that regard.
prmoustache 3y ago
On the contrary, it shows how opensource is a reliable long term choice through the possibility of forking.
- jeremyjh 3y ago
  It doesn't matter if you agree, it only matters if there are some decision makers that agree, and I know for a fact that there are. So the damage has already happened.
  - prmoustache 3y ago
    Most decision makers aren't impacted nor concerned by Hashicorp's change of licence.
    - jeremyjh 3y ago
      Again, that is not important for my argument. It only matters that some are concerned.
      - prmoustache 3y ago
        The only one are those that build stuff on top of terraform. And you know what? It will always be worse building stuff on top of a proprietary technology managed by a company that can decide to discontinue it anytime. Look a all those companies that had build services using twitter api.
  - jacquesm 3y ago
    Likewise. This is precisely how it happens, and no amount of wishful thinking about how companies are going to insource the maintainance of some major FOSS package is going to change that. It simply will not happen that way, companies want to focus on their business and not on the vast amount of tooling that underpins basic functionality, they'll just use another supplier.
    - 3y ago
yjftsjthsd-h 3y ago
It's a cautionary tale about CLAs, not FOSS.
- jeremyjh 3y ago
  Are there commercial FOSS projects that don't have CLAs?
  - yjftsjthsd-h 3y ago
    I responded to > any effort to bring in some OSS project as a dependency will be met with "Sure, it's open source now, but what about when...". If you'd like to constrain that to commercial OSS projects it would be more compelling.
    - jacquesm 3y ago
      The alternative to a commercial OSS project is a commercial project without the OSS component. If the quality is perceived to be similar and the OSS license is no longer a factor then it might as well be closed source.
    - jeremyjh 3y ago
      The comment you responded to began with the sentence: >I think this damages all commercial OSS projects.

charcircuit 3y ago

Most businesses are not directly competing with the businesses making software they depend on

throw16180339 3y ago
Some of them, however, may want to be acquired by companies that compete with HashiCorp.
- sam_bristow 3y ago
  Or HashiCorp might acquire a company you compete with.
  - jen20 3y ago
    Red herring. The licensing FAQ from HashiCorp makes it clear that this would not trigger the BSL provisions. [1]. [1]: https://www.hashicorp.com/license-faq#future-competitive-products https://www.hashicorp.com/license-faq#future-competitive-pro...
- charcircuit 3y ago
  The aquirerer can pay for license to use Terraform if they want to use Terraform to compete with HashiCorp.

cstejerean 3y ago

The answer is "then a viable fork will sprout up and we can switch to that instead" which is what has happened for every notable widely used OSS project I can think of. And it's not like you have to sit idly while that's happening. A small company might not be able to fork and maintain their own fork but they can pitch in with other companies by providing some development time, or money or infrastructure to help make an OSS fork successful as a community project.

armchairhacker 3y ago

IMO it shouldn't be much different than "sure, it's open source now, but what if it stops being maintained?" Because open-source code never stops being open-source, it just stops getting open-source updates. Closed-source in some situations can prevent you from using existing software; you also have other closed-source issues like bugs being unfixable. Would you rather use a service that worst-case, you have to patch and maintain yourselves? Or a service that worst-case you have to switch to an entirely different service?

jacquesm 3y ago
That's true, but for a lot of companies having an entity behind a piece of software will definitely be a major factor in their decision making process so these kind of tricks ultimately benefit closed source offerings. And that's quite annoying. The idea behind open source is very solid, but the assumption that any user of a large package is ultimately able to continue to maintain it is faulty and that means that for a lot of parties the benefits of open source only materialize if someone else is willing to take up the mantle, they are simply not able/staffed/wealthy enough to do this. So every time someone does a rug-pull all FOSS projects suffer.
scarface_74 3y ago
> Would you rather use a service that worst-case, you have to patch and maintain yourselves? Having to patch and maintain a complex piece of open source code yourself for most smaller non tech companies for all practical purposes means that it might as well be abandoned closed source code.
- eschneider 3y ago
  Not really. If you need it fixed or extended and you can't do it yourself, you can always hire someone to do it for you. With open source, you have options.
- throwaway103xx 3y ago
  Exactly. The end result is the same. Folks are wise to question if they should use OSS that has a CLA assigning copyright because that means they should have zero expectations about the license not changing.

freeopinion 3y ago

I think it shows the huge benefit of OSS. If TF had been closed from the start, users would have no recourse at all. Instead, there is a viable path forward.

jacquesm 3y ago
That viability hinges on people actually doing it and the evidence that this is happening at scale just doesn't exist. There are some forks of major packages out there that have been extended but that's because the company had entirely different ideas about the direction in which to take a package. But for the vast majority of FOSS out there the current maintainers are the ones that are capable of doing so and the entities using the package are not able, do not have the funds or the time or people to do so themselves (and more likely a combination of those).
- freeopinion 3y ago
  The two specific cases cited in the post to which I responded were Docker and Terraform. I think there is a great deal of evidence that people are using alternatives at scale. Let's take a look at some other examples: OpenOffice, Node, Hudson. Of course, there are plenty of cases where forks have not thrived. But that is not really the question. The question is, can you show me a single closed-source project that did something highly objectionable to a large portion of the userbase that was then rescued by the userbase? Can you explain why I should choose IIS over Apache just because there is a possibility that somebody could fork Apache? If either IIS or Apache decided tomorrow that they would no longer support TLS, but only support eeeTLS, why would the Apache situation be worse just because it is OSS and some users might fork it to keep TLS capabilities? It seems obvious to me that in fact Apache is the wiser choice in that regard.

prmoustache 3y ago

On the contrary, it shows how opensource is a reliable long term choice through the possibility of forking.

jeremyjh 3y ago
It doesn't matter if you agree, it only matters if there are some decision makers that agree, and I know for a fact that there are. So the damage has already happened.
- prmoustache 3y ago
  Most decision makers aren't impacted nor concerned by Hashicorp's change of licence.
  - jeremyjh 3y ago
    Again, that is not important for my argument. It only matters that some are concerned.
    - prmoustache 3y ago
      The only one are those that build stuff on top of terraform. And you know what? It will always be worse building stuff on top of a proprietary technology managed by a company that can decide to discontinue it anytime. Look a all those companies that had build services using twitter api.
- jacquesm 3y ago
  Likewise. This is precisely how it happens, and no amount of wishful thinking about how companies are going to insource the maintainance of some major FOSS package is going to change that. It simply will not happen that way, companies want to focus on their business and not on the vast amount of tooling that underpins basic functionality, they'll just use another supplier.
  - 3y ago

yjftsjthsd-h 3y ago

It's a cautionary tale about CLAs, not FOSS.

jeremyjh 3y ago
Are there commercial FOSS projects that don't have CLAs?
- yjftsjthsd-h 3y ago
  I responded to > any effort to bring in some OSS project as a dependency will be met with "Sure, it's open source now, but what about when...". If you'd like to constrain that to commercial OSS projects it would be more compelling.
  - jacquesm 3y ago
    The alternative to a commercial OSS project is a commercial project without the OSS component. If the quality is perceived to be similar and the OSS license is no longer a factor then it might as well be closed source.
  - jeremyjh 3y ago
    The comment you responded to began with the sentence: >I think this damages all commercial OSS projects.