I love hashicorp's software. I just wish their enterprise licensing models weren't so outlandishly expensive for small to medium companies. I wouldn't go so far as to call their vault pricing outright predatory, but it comes close.
Inevitable end for every open source company since the free money ended. What bothers me is that wording is vague enough.
> HashiCorp considers a competitive offering to be a product or service provided to users or customers outside of your organization that has significant overlap with the capabilities of HashiCorp’s commercial products or services.
So, consider there is no cost estimate service and you built a thing that got popular (https://github.com/infracost/infracost). Then after 2 years Terraform Cloud catches up. What happens? Are you out of business?
Hashicorp has a billion dollars in the bank and is growing 48% YoY, so they aren’t in danger of failing. They may be in danger of not justifying their $5 billion valuation.
> Inevitable end for every open source company since the free money ended.
Yeah. It seems like the Apache/MIT route has been working “well” to support a suite of libraries. But for bigger “business-critical” full-on products, like databases etc, you see much more weird contortions, including making self-hosting difficult and feature-gating essentials. Better than closed source, but not ideal. I’ve been thinking for a while that licensing is likely the pragmatic way out. But it’s important that it’s broadly understood, fair and clear.
> […] a product or service provided to users or customers outside of your organization that has significant overlap
Ouch, judging by the language it seems like it’s (1) unclear and (2) the authority on that ambiguity leans in favor of the company, which paves the way for selective enforcement. “Don’t worry, we aren’t going to come after anyone” is not convincing when legal documents are being signed. Hoarding soft- or future powers is a huge red flag in contracts, imo.
What do others think about this license in particular?
I know of precisely zero such companies, and I can't imagine how such a company would even have customers in the first place when Terraform already has a $0 pricetag.
I could maybe understand this for Consul or Vault, since those are actual hostable services that could probably be resold - but I don't know of anyone reselling those, either.
I wouldn't call them a competitor by any stretch; more like a partner. A Terragrunt codebase just wraps Terraform, with the same exact backends (including Hashicorp's SaaS offerings) and the same exact providers and everything.
Dozens of them out there
I wonder with great interest which one of these got hashicorp worries about their wallet enough to make this move. Could it be env0 raising 42M earlier this year?
So every person who uses Linux for work and doesn't make a kernel contribution is a freeloader? A plant shop keeper running Linux on their work computer is a freeloader? I don't think that's even the intent of the GNU movement let alone all of open source.
Yeah, it always confuses me when people release something under e.g. the BSD or MIT license and then complain about "freeloaders."
It's totally understandable to not want companies to profit off of proprietary, closed-source forks of your software. I get it! But there are licenses that you can use to stop that from ever happening (namely [A]GPL). Why not use one of those?
It's because a lot of them were culturally anti-copyleft, but had never read the licenses or the reasons behind them.
Copyleft is politically scary to some people, so they refuse to acknowledge it other than to call people zealots. Explicit licenses protect you. Open source spirits don't. Everyone should be honest: the only reason a lot of people prefer open source is because they want to preserve a rug-pull option. Then they get surprised with it's Amazon pulling the rug on them.
Disclosure: I work for Amazon, but I've been a copyleft advocate for a quarter century.
Indeed, copyleft can be politically scary. Especially when for-profit companies co-opt copyleft to drive licensing revenue by selling alternative license arrangements [1]. If all those who adopt copyleft licenses pledged to commitment to community-oriented GPL enforcement principles [2] I think that it would be a lot less scary. Unfortunately we've seen "copyleft trolls" that try to wield copyleft as a weapon, either for profit or to make other demands that are not helpful to the community.
Copyleft licenses are, indeed, protective licenses from my perspective. Or, they should be.
An aside, when it comes to "Amazon pulling the rug" -- what exact incident are you referring to?
I've been into free software since I was a kid, so all of this is very familiar to me. You've done a great job of breaking it down! Thanks for this and similar comments on this post. I hope they clear things up for some people. I feel that GPL (and AGPL, even more so) often does not get a fair shot, and that's a shame.
GPLs are a bit complicated for companies because (personal opinion alert) I THINK it is ok if you’re a company, member of a particular community, to be able to embed that on some product and not be mandated to open-source the whole thing.
IMHO not everything needs to be open-source, but in many case it just makes so much sense that is a dumb idea to reinvent the wheel.
Many projects are succesfull this way. One I can think of is LLVM.
Projects are free to choose permissive licenses like BSD.
Companies are then free to use the code however they like and not contribute back in any way.
Projects are then free to be annoyed by this because they hoped that companies would contribute time and/or resouces out their own good will.
Finally, projects are free to move to "business source" licenses because good will didn't work, so they need to utilize the legal system to ensure that large companies help sustain the project.
Describing changing to a source-available licenses as "now utilizing the legal system" is strange.
Projects choosing a permissive license like BSD is utilizing the legal system. BSD is a contract, a copyright license. It imposes restrictions/limitations/obligations, which can/would be enforced by a court.
Come on, you're unfairly quoting bits of my sentences in order to fuss over something unrelated to my point.
I said:
> so they need to utilize the legal system to ensure that large companies help sustain the project.
No shit they were using the legal system before with the BSD license. I am saying that they are now using the legal system to ensure companies contribute, which is not something the BSD license did.
Have you ever set lenient guidelines, people took advantage of them in a way you didn't like, so you were forced to tighten your guidelines in a way you didn't originally want to?
eg: a professor establishes a generous late homework policy, which most students use reasonably, except a few who decide to turn in everthing on the last day of the term and make the TA's lives hell. Prof is allowed to be disappointed and then adjust their future terms' policies to be more specific (eg "submit assignments max 5 days late").
For this analogy to work, it also needs to include the professor advertising their course and attracting good-will primarily on the basis of their generous policy, and then bait-and-switching involved participants when they later decided they didn't like it.
The professor could advertise their course this way for Term 1, realize their policy isn't working as intended, and then change their policy (and advertising) as of Term 2. That's not a bait and switch. There was no promise that their course would have the generous original policy in for all terms in perpetuity.
As far as I can tell, you are allowed to fork HashiCorp's code up until the point of license change, and continue to use it as you like, rebrand it as a new project, whatever. I could be wrong, but I don't think HashiCorp ever said "we will never ever change our license."
Ehh.. with terraform it's more like putting out a bootstrapped "need a penny, take a penny. have a penny, leave a penny" jar in front of the register, occasionally putting your own pennies into it (while other people leave theirs as well), then, after the jar starts to overflow, and you realized no one was giving your business extra money, you decide to take the jar (now a significant chunk of change, thanks in large part to the good will of others)
> In other words, free as in freedom, but not free as in beer.
That's the Free Software slogan, not open source. The only relationship between the two is that open source can easily be relicensed into Free Software (or proprietary, or whatever.)
There's nothing in open source about friendliness or collaborative development. I'm not forced to take your advice or contributions just because I'm open source, so how could that have anything to do with it?
> That's the Free Software slogan, not open source. The only relationship between the two is that open source can easily be relicensed into Free Software (or proprietary, or whatever.)
> There's nothing in open source about friendliness or collaborative development.
Your view of the meanings of "free" and "open source" software is very literal and narrow. I'm not trying to debate the technical definitions of those terms, because frankly, I don't care and I don't think they matter in this discussion.
The crux of what I am saying is this:
A company may choose to share their source code for others to benefit from, under the hope that large players will contribute back in some way rather than use the situation to the disadvantage of the upstream company.
In other words, they might hope to:
* Let hobbyists learn from and use their code for free.
* Let competing companies use their code, as long as they contribute something back (money, bugfixes, festures, community support, QA).
* Make their employees happy.
and they may not hope to:
* Empower other large companies to freeload--ie, profit without contributing back at all.
Yes, I understand that permissive open source licenses allow freeloading in a legal sense. That does not mean the upstream companies have to be happy about it, much in the same way that you're allowed to use your office's shared kitchen to microwave fish, but your colleagues do not have to be happy about it.
> That's the Free Software slogan, not open source. The only relationship between the two is that open source can easily be relicensed into Free Software (or proprietary, or whatever.)
While you are correct that the Free Software Movement has slogans like "free as in freedom" and has a definition based on "the four freedoms," the Open Source Movement also recognizes and advocates for "Software Freedom" as well.
"We build a world where the freedoms and opportunities of Open Source software can be enjoyed by all." [1]
Software that is licensed under Apache 2.0, MIT, BSD, or any of the other so-called "permissive" licenses is labeled "Free Software" by the Free Software Movement as-is. It does not require a "relicense" to become Free Software.
Said another way: you don't have to use a copyleft license like the GPL to qualify for the "Free Software" label.
It is just a different name for the same thing, because there was a group that developed a vocabulary before another group existed.
Originally it's "free as in speech" not "free as in freedom"
But BSL is definitely not free as in speech. So if it's neither free as beer, so what part of it is "free"?
By any chance are you familiar with Little Free Library (https://littlefreelibrary.org/), those public boxes for people to take or leave books? How would you feel if someone took ALL the books, repeatedly, and then sold them? Would you just shrug and say "well that's totally fine, why is it free in the first place?"
This behavior is antisocial, and completely destroys the offering/concept for everyone.
I have a bootstrapped software company with an open-core product. Meanwhile, a VC-backed startup that has raised over $100m of funding decided to use one of my core open source libraries (which they haven't contributed to in any way) for a critical component of their commercial product, which also overlaps with my product's functionality in some ways.
In response, I eventually made the difficult decision to archive that library's repo and moved its functionality into my main product in a way that prevented external use. So then this startup created a hostile fork of my library, and started to implement functionality that is only present in my own commercial product.
After that, I had to waste several months of unpaid time just to make their fork of my own library no longer easily compatible with recent versions of my own product. Some time later, finally the startup decided to abandon use of my library altogether and wrote their own similar library (which was undoubtedly much easier for them, being able to see all the edge cases my library already handled).
My lesson from all this: I will never create another new large open source product ever again. Too many sociopaths out there for the system to work at all. If I ever decide to make something source-available, I will consider BSL.
And before someone says "why not AGPL?", it is because many companies don't touch AGPL software with a ten-foot pole. My sense is that adopting AGPL for a brand new product typically causes the product to be dead on arrival. That said, I would honestly love to be wrong here.
If there are a lot of AGPL open core / commercial FOSS companies that have been successful, please share examples, I say this genuinely and without snark.
Thanks for the post. I’m sorry you went through this with bad actors in open-source.
I agree fully with your *GPL point of view and have seen that in practice many time.
It is in the written guidance for open-source in the company I work for, along the lines “for GPL-like licenses, that’s a ‘no’ by default, unless you follow this very complicated process to get approvals from many people”.
Given the lengths you say you went to to actively stop and sabotage licenced (by you) usage I have to question why you even picked an open source license in the first place?
When I started developing my main product, I didn't know if it would be successful, especially since it involved a paradigm shift in how most people thought of the workflow involved (database schema changes / migrations). So I made it open source to encourage adoption and experimentation.
Meanwhile I put some of the core logic (database schema introspection and diff'ing) in a separate library and repo, since it could be re-used for other applications in case my original product didn't get traction.
Fast forward many years, and the product has been fairly successful. The open source edition of the product has been used by many hundreds of companies and has been downloaded 1.2 million times. And in terms of the paradigm shift, the push/pull schema change semantics that I invented have been copied by several much larger projects, such as Prisma.
The separate library was used by a few companies too (e.g. by Canonical for one notable case), but mostly for internal use-cases, not things that directly competed with my product. I think most folks had enough moral fiber or common sense to understand that using the library in a competitive way would result in the library being killed off. What other choice did I have? I wasn't going to let my business be killed by a hostile fork of my own library.
> How would you feel if someone took ALL the books, repeatedly, and then sold them?
Books are rivalrous and excludable goods. If you take all the books, then others can't enjoy them. Open source software is non-rivalrous and (mostly) non-excludable. This is the thing that makes free software possible. And it's also the thing that makes it unlike the book example.
> decided to use one of my core open source libraries (which they haven't contributed to in any way) for a critical component of their commercial product, which also overlaps with my product's functionality in some ways.
This is really terrible, and I'm sorry to hear that it happened to you. But as far as I'm aware this has always been the whole point of "permissive" licenses. Licenses like MIT and (Berkeley) BSD subsidize the private sector with work done by the universities. The core idea, at least compared to GPL licenses, is to allow businesses to profit off of donated work. So while I sympathize with you, it seems like you deliberately chose a license that allowed and encouraged exactly the behavior you saw.
> And before someone says "why not AGPL?", it is because many companies don't touch AGPL software with a ten-foot pole.
This is presumably because businesses don't want to use software that creates in them obligations to give back. But you do want them to give back, or at least you don't want them to take too much. So I feel like there's a fundamental tension here. You're trying to make your project appealing to businesses by telling them they can take it for free and give nothing back. But you're also saying that behavior is "antisocial" and "completely destroys the offering/concept for everyone."
> If you take all the books, then others can't enjoy them.
Sure, and if your company takes a bootstrapped commercial open source product that it didn't develop or contribute to, and then pays several employees a salary to do things which actively reduce that product's ability to develop a sustainable revenue stream, then you definitely risk permanently destroying that open source product.
On a macro level, if many companies do this, the entire ecosystem of open source begins to falter. Hence all the moves to BSL, SSPL, Commons Clause, etc.
I was making an analogy to that. If some people keep taking all the books and selling them, the system falls apart, and people stop putting free books in the box.
> it seems like you deliberately chose a license that allowed and encouraged exactly the behavior you saw.
"Allowed", yes. But nothing in the license I chose (Apache License v2) actively "encourages" the behavior of using a project in a way that actively destroys the project. (Nor does it discourage it either.)
> You're trying to make your project appealing to businesses by telling them they can take it for free and give nothing back. But you're also saying that behavior is "antisocial" and "completely destroys the offering/concept for everyone."
I have no problems with businesses using a project for free and giving nothing back, on its own. I do have a problem with businesses taking a project, and profiting off it while also directly competing with it and/or forking the project in a way that directly kneecaps the project's revenue stream. That is what I am calling antisocial and destructive.
Yes, you chose the wrong license without understanding its implications.
> My sense is that adopting AGPL for a brand new product typically causes the product to be dead on arrival.
It may hinder adoption (in the corporate world) but not contribution to the source. And if you want to promote the spirit of opensource and make money too, dual licensing with xGPL is the best way to go. MySQL is a successful example of this licensing and business model.
It's pretty telling that you listed only a single example product, and one which was first released twenty-eight years ago, and also one which raised venture capital.
Just because dual-licensing has been successful in a very limited number of exceptional situations, does not mean that it is a reproducible path towards building a sustainable software business.
Also keep in mind:
* MySQL hasn't been an independent business for over 15 years. AFAIK there is no public information on its revenue or profitability.
* Much of Oracle's recent work on the product has been on MySQL Heatwave, which is only available as a managed service.
* Most MySQL Community Edition commits come from Oracle.
* Meanwhile the company behind MariaDB, arguably a more "open" fork of MySQL, is having financial problems and may well end up having its stock de-listed soon.
* The non-open-source Business Source License was originally created by MariaDB for their MaxScale product. The license's existence is fully backed by Monty Widenius, original creator of MySQL.
To be clear, I'm not saying any of the above to criticize Oracle or MariaDB. Rather, just pointing out that a general statement of "dual licensing with xGPL is the best way to go" is not really backed by the facts on the ground.
I must ask, do you run a commercial open source business yourself?
MySQL is a successful product that was sold to Sun / Oracle for a BILLION dollars. MariaDB and Percona Server are good examples of competing businesses produced from a commercially successful GPL opensource software (MySQL):
The commercial success of a product totally depends on the business model you come up with, whatever be its opensource (or not) license.
Corporates have a vested interest in promoting the propaganda that only a non-xGPL opensource license can be commercialised successfully simply because they cannot freely steal the source code of a competing xGPL licensed software.
The real value of an FSF license, like the AGPL, is that it is designed to protect the copyright holders, and its users, "right to repair". And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license (even if future versions are closed source, the old version under xGPL remain opensource perpetually). Other open source license (that are less stringent) are prioritised to increase developer contribution. Source code under such license can thus be closed-source even from the original copyright holder.
But again, commercial success totally depends on the business model you come up with, irrespective of your license. The right license and the right business model will empower each other. Or cripple your business.
> The real value of an FSF license, like the AGPL, is that it was designed to protect the copyright holders, and its users, “right to repair”. And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license
17 USC Sec. 203 suggests that may not be strictly true in the US.
> MySQL is a successful product that was sold to Sun / Oracle for a BILLION dollars
"Successful exit" is not the same thing as a sustainable product or business model. I mentioned several key concerns in my previous reply, which you didn't address here at all. Specifically, if dual-licensed GPL was the best way to go, it wouldn't be the case that entities outside of MySQL/Oracle (e.g. AWS) were capturing a huge amount of MySQL's value/revenue, possibly exceeding that of the product's own revenue. Why else would development be shifted to the managed-service-only, closed-source MySQL Heatwave product?
> MariaDB and Percona Server are good examples of competing businesses
Yes, I'm very familiar with the MySQL ecosystem (click my profile). I mentioned several concerns specifically about MariaDB in my previous reply and you did not address those at all.
You also didn't answer my question about whether you've ever run a commercial open source business, so I must conclude that you haven't. I do, and frankly I don't appreciate when other people -- who seemingly don't havie direct personal experience in this area -- attempt to confidently lecture me about how I supposedly chose the wrong license.
Listing Red Hat in your reply also seems a bit ridiculous, given all the latest contention in that space over Red Hat threatening to cancel customer subscriptions if they republish RHEL's sources. If GPL-based software was the panacea you claim, things like this wouldn't be happening with ever-increasing frequency over the past couple years.
> ... if dual-licensed GPL was the best way to go, it wouldn't be the case that entities outside of MySQL/Oracle (e.g. AWS) were capturing a huge amount of MySQL's value/revenue ... Why else would development be shifted to the managed-service-only, closed-source MySQL Heatwave product?
And do you realise that you are comparing corporates with two completely different philosophies and business model? It's absolutely in character for Oracle to use the loophole in the older GPL (that has since been fixed by the AGPL) to try to make MySQL closed-source again by offering it through a SaaS infrastructure. Oracle has never been a champion of the opensource movement, while the original owners of MySQL were. It is the same with IBM, who are now the owners of Red Hat Linux. And that shows in how they ran / run their business.
We are discussing about opensource software business models only. Not open-source and closed-source ones (it should be a no-brainer that closed-source software business models are the most successful and profitable ones).
> I mentioned several concerns specifically about MariaDB in my previous reply and you did not address those at all.
Simply because it is irrelevant to our discussion. The success or failures of MySQL or MariaDB or Oracle's MySQL was/is not just solely because of its license and there are many other factors behind it (for example, MariaDB earned a lot of scorn from open source developers because they felt betrayed after its original source - MySQL - ended up in Oracle's hand). Nevertheless, MySQL is a great example of a commercially successful example of a dual-licensed GPL product.
I have enough business experience, and a good understanding of open source software to understand its strength and limitation in a commercial setting. Honestly, you do need a lecture for not being able to see the obvious:
1. As per your own confessions, a competitor was able to use your open source code without sharing subsequent work on the codebase. This would obviously have never happened with the AGPL license, as the license compels others who distribute the software (even as SaaS) to share the source code.
2. You tried to change the codebase and / or license to make it more difficult for them to fork your code and use it. This shows your own confusion regarding the open source philosophy and your business model. Your code was used by others in the spirit of the open source license you chose. And yet, you continue to assert you are the wronged party?
3. It is also easy to see that you (wrongly) chose a permissive opensource license out of self-interest to your business (hoping to attract more developer contributions and then close source the product later when it becomes profitable, just as your competitor did) than out of an equal commitment to the open source philosophy. Your competitor outwitted you because you weren't knowledgable about licenses, your own business goals and business model.
> Honestly, you do need a lecture for not being able to see the obvious
You are making a ton of reading comprehension errors, as well as completely incorrect assumptions about the situation I described. And then lecturing me about those incorrect assumptions. Cool cool.
> a competitor was able to use your open source code without sharing subsequent work on the codebase.
No, that's not what I said at all. I described how a company used one of my open source libraries in a way which directly competed with my primary product. The problem here is they did share their changes, and those changes included functionality which was already present only in the enhanced paid closed source edition of my product.
This is why I said it was a "hostile fork" of my library: users could combine the open source edition of my product with the hostile fork of my library to get functionality for free that normally is only in my paid product.
I absolutely understood that this situation was possible with a permissive license. I just did not expect a company to do this so soon after my paid product launched, especially as the product wasn't even financially successful yet by that time.
> This would obviously have never happened with the AGPL license
I can say with absolute certainty, if my product had an AGPL license, it would not have succeeded in any form. Many of my largest users do not adopt AGPL software under any circumstances.
> You tried to change the codebase and / or license to make it more difficult for them to fork your code and use it.
The former, not the latter. I never tried to change the license, nor said anything about that here. I changed the codebase so that the previously-external library was now an internal package instead of a standalone repo, and refactored things to prevent compatibility with the hostile fork.
> Your code was used by others in the spirit of the open source license you chose. And yet, you continue to assert you are the wronged party?
My code was used in a way which negatively impacted the revenue stream which would pay for further development of that code. As I've said elsewhere in this subthread at https://news.ycombinator.com/item?id=37084057, the license is entirely neutral about that topic: it neither encourages nor discourages such use. However, I assert that common sense should typically discourage people from such antisocial behavior, because you can reasonably expect that kneecapping the revenue stream for a project can result in that project either getting killed off or radically changing shape in response.
> you (wrongly) chose a permissive opensource license out of self-interest to your business (hoping to attract more developer contributions
I never said anything about "hoping to attract more developer contributions" and that has never been my motivation for open sourcing this work. I described why I chose an open source license directly in a sibling subthread here: https://news.ycombinator.com/item?id=37083698
> and then close source the product later when it becomes profitable, just as your competitor did
You're just completely inventing false details here out of thin air!
My product has two editions, a FOSS one and an enhanced paid one; the latter is closed-source. Both editions already existed at the time of the events I'm describing here. Both are still actively developed and supported, and today they're widely used by companies you are definitely familiar with.
The library in question was one component of this product, not the product itself.
Meanwhile the startup that made the hostile fork of the library runs a managed service (SaaS).
> Your competitor outwitted you because you weren't knowledgable about licenses, your own business goals and business model.
I'll never understand this attitude. Are some people contributing to open source principally for a kind of quid-pro-quo? I think it's nice when people contribute back, but it's certainly not a motivation for me to open source stuff - other than to set an example. People can do what they want with the software, that's the whole point.
Full disclosure, I'm a shitty open source contributor, but I have some projects on github that I know others have gotten use from, and that makes me happy, not concerned someone is "freeloading".
It’s not quid-pro-quo. At the same time, does that seem ethical (even if it is legal) to build some dysfunctional business models exploiting somebody’s open source for profit and not contributing back?
There are many motivations such as mindshare, not reinventing the wheel and creating standards that motivate people and companies to contribute to open-source. Ripping-off other’s work - even when legally ok - is not right.
The system is designed to foster collaboration and not to enable shitty business models.
> does that seem ethical (even if it is legal) to build some dysfunctional business models exploiting somebody’s open source for profit and not contributing back?
You're describing a thing that happens here, and not even bothering to make an ethical argument against it. People are just supposed to accept the premise, and go on to discuss the implications of it.
> The system is designed to foster collaboration and not to enable shitty business models.
"Spirit of open source" people are arguing that the system wasn't designed at all. You're arguing that open source licenses themselves have little or nothing to do with open source licensing. Instead, it has something vaguely to do with freedom and friendly and collaborative and other nice words. You don't have to be friendly or collaborative to produce either open source or Free Software.
It's not so much quid-pro-quo as freedom. I like creating open source to give users freedom, not to contribute to billion dollar companies jailing everyone's data in SaaS and creating a surveillance dystopia.
I also work on open source full time. I personally am happy to give my work away unconditionally to both freeloaders and contributors and fortunately my employer feels the same way (I am often a freeloader myself on unrelated projects).
Ideally your moneymaker can compete on its own without being dependent upon gatekeeping how the open source part is used. But with project ownership means you can change the rules for your competitors, but it's also a sign that you fear your offering is not competitive enough without the rule change.
I find it brave we had this generation of companies creating open-source business models.
It’s a shame it didn’t work out for them due to bad actors.
The trend I see is for the next generation of good open-source great ideas to be much more protective around their intellectual property. Such a loss, again, due to bad actors.
I don't think the loss is due to bad actors. These actors aren't bad, they're rational. I think the loss is due to giving away things unconditionally without thinking about what that means. Many companies aren't reneging on open source. The ones that are reneging can't compete on what they are selling, so they have to compete on what they're not selling.
Bad actors want to take advantage no matter what. It is the same case as Red Hat recent moves not to provide easy-to-rebrand linux distribution sources. Before they went the extra mile to foster collaboration, but were forced to be less friendly because of freeloaders.
Similar point here. Hashicorp have very good products that are open source as a way to foster collaboration. Freeloaders rebrand it and re-sell with no added value, so Hashicorp are forced to close it (or more like put a timer) to protect their investment.
As I said, I'm a big fan of open-source, and have been working on it for a long time, but am growing more and more frustrated with the current state of things, so much so, that it makes a lot of sense to me that companies that start with great collaboration spirit are forced to tighten their sources due to bad actors in the system.
> it's also a sign that you fear your offering is not competitive enough without the rule change.
Agreed. It can't mean anything other than that you can't compete on a fair playing field, so you have to add restrictions to lock customers into your service. That you wrote the service is irrelevant since you licensed it as a gift to the world. It's exactly what Free Software was designed to thwart, and exactly what open source was designed to preserve.
It need not be HashiCorp employees. I merged as many (if not more) PRs into Terraform after leaving as I did while working there - the notion of community maintainers was nixed in 2018, though that was never communicated.
In this case in particular, their stuff was under MPL (which has copyleft). If there were other companies offering Hashicorp services with hasicorp software, they also are under the obligation to open-source their changes under the MPL to their users, so hashicorp could get back those "contributions" from "freeloaders".
On the other hand, many contributions(PRs) that hashicorp got (for free) are now relicensed to a different license. Who's actually the freeloader here?
It is, by definition, impossible to use and not contribute. To use is to contribute. As soon as you install a Hashicorp product, before you even run it, you have already contributed.
Nothing wrong with this imo. I actually hope more open source projects start with a business source license if their ultimate goal is to become a SaaS platform.
I think we've seen time and time again large enterprises abusing the spirit of open source for their own monetary gain, contributing nothing back, and just acting in bad faith.
Abusing the spirit of open source, what? If somebody doesn't want any competitors they should have read the licenses and understood them, and not simply used open source as a buzzword for marketing purposes.
A lot of people start open source businesses under the good faith assumption that competitors will be fair and that the people who do the actual work capture the value, and that people genuinely contribute back.
License technicalities don't matter. If people use permissive licenses as an excuse to justify an ecosystem that is parasitic any such system will die out, it cannot sustain itself.
If your business can't succeed using an open source license you made poor business choices. Own it, don't blame the license or the open source community.
If I have to pay developers, operate a business, allocate time and money to create value and take the risk that comes with it, and you come and take my work unchanged, strip all atribution and mereley resell it, then I can't succeed by definition. The most talented businessman on earth cannot.
If that's what you think open source is, it'll vanish. No commercial system can exist like that and it should not because it effectively means distributing resources from people who do everything to people who do nothing.
> and you come and take my work unchanged, strip all atribution and mereley resell it, then
If they strip all attribution, then you can just take them to court for violating the license; other than public domain and WTFPL, even the most permissive licenses (BSD/MIT/Apache) still require attribution.
> If that's what you think open source is, it'll vanish.
Free software has been fine without any businessmen or companies involved, we don't need your or any company's approval. It seems like the only thing that will vanish from the open source sphere are companies with flawed business plans.
If you're not able to come up with a business plan that involves open sourcing your software, that's fine!
Building a business off the open source model and community good-will before realising it doesn't work is either incompetence or dishonesty.
> If that's what you think open source is, it'll vanish. No commercial system can exist like that and it should not because it effectively means distributing resources from people who do everything to people who do nothing.
This is a weirdly hyper-capitalist take. You're saying that the successful businesses built off open source "should not" exist?
> If somebody doesn't want any competitors they should have read the licenses and understood them, and not simply used open source as a buzzword for marketing purposes.
One should always read software licenses before installing a dependency, regardless of how a particular project is marketed. This would still be necessary even if companies weren’t using the term “open source” to refer to this type of license.
People make it sound like companies are out to confuse you by calling it “open source”. If you’re the kind of developer that blindly uses a piece of software because someone claimed it was open source without doing due diligence on how it can be legally used, then you deserve whatever consequences may arise.
Not having competition is not the problem I have seen listed when abuse is talked about. It is not contributing back in ways that are promotional to how much the company is benefiting. Or not going out of their way to acknowledge that they started with someone else's open source project, not even something like an academic citation.
Open source licenses don't require you to do those things. That was the intention in coming up with them.
They were the Bazaar people. They sold open source as something that makes software quality better. It was the counterpoint to Free Software, who said they made programs morally better, and that it was largely irrelevant whether copyleft made software quality better.
> Open source licenses don't require you to do those things. That was the intention in coming up with them.
I mentioned the cases I have seen the word abuse used as a counter point to 'If somebody doesn't want any competitors' which is not something I have seen brought up when taking about abusing the spirit of open source.
I was not taking about what the licenses legally bind you to do.
There are open source licenses, such as the AGPL, which explicitly require that those changes being contributed back. There are licenses which require attribution. The fact the companies switching to the BS License is a sign that those aren't the real issues.
AGPL is very explicit/narrow about how and when you give back not everyone will want exactly that. My last example of where I have seen the word abuse used is only about lack of attribution similar to an academic citation.
> abusing the spirit of open source for their own monetary gain
For many, the spirit of open source is to allow it to be used in any way, commercially or otherwise. I don't consider it acting in bad faith at all to use what's out there and made available, and I am happy to give things away as in beer. Otherwise it's not open source (which is also fine, not all software has to be open source).
To abuse the spirit of open source, make arbitrary rules about its use.
The main way I think about this and how I often see people act are that actions which undermine the long term success and sustainability open source community is abusive. So you take a behavior and say if a non-trivial number of people emulated/copied this behavior will the open source community survive long term, if the answer is no, then the behavior is abusive.
Of course people disagree with what will lead to long term sustainability of open source projects and communities, though it does seems like a reasonable heuristic to the first degree of approximation.
Then I'd say that the abusive behavior is to imply there are terms in the license that aren't actually there, and to use that implication to attract developers and customers to your project. If your open source has a soul, write it into the license. Note that after you do that, it will not be an open source license.
I do not follow either of your statements. I do not know what you would use as an example for your first sentence. I do not know what you are trying to communicate with the last two sentences.
Open Source is poorly defined. All the most popular "open source" licenses are restrictive. The restrictions are what differentiates them. Hell, look at GPL..
It's a spectrum IMHO from closed-source to "do whatever you want" source.
> As a result, we believe commercial open source models need to evolve for the ecosystem to continue providing open, freely available software.
To imply that a non-open-source license like the BUSL is part of such an evolution of "open source" models (commercial or otherwise) betrays either severe confusion or a deliberate attempt to mislead.
Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
> Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
Just because nobody has tried yet doesn’t mean that it won’t ever happen. Companies are doing this precisely because companies like Amazon abuse FOSS licenses to stand up their own hosted versions of open source projects.
AWS in particular already has its own competing services that predate or otherwise do not derive from Hashicorp's offerings (CloudFormation, Secrets Manager, etc.). Same with pretty much every other major cloud provider. The whole point of going with Vault or Consul or Terraform or what have you is to not tie oneself to a particular provider's offerings.
Put simply: Hashicorp's target market for a given product is largely not going to be interested in a cloud provider's locked-down equivalent, and a cloud provider is not going to be interested in deprecating its own tightly-integrated product in favor of customizing some third-party offering.
And again: if this was a legitimate fear, then the AGPL already fully addresses it.
I'm thinking that AGPL is, indeed, the Ebola of viral licenses, but it does not cover the case where a large cloud vendor simply takes an AGPL-licensed product and offers it as a cloud service. AGPL does not cover that case. Nothing the cloud vendor does challenges any of the AGPL's terms.
The cloud vendor issue is license agnostic. ElasticSearch comes to mind. For the AGPL side, MongoDB and Neo4J come to mind.
Recall that AGPL came into play by way of a hole in the GPL terms, the one where you can modify a GPL codebase but you don't have to say anything unless you publish it. GPL was weak in therms of the definition of "publish". AGPL closed that hole.
But, that hole only becomes toxic the moment you modify the code or plug proprietary stuff into it. Cloud vendors don't do that.
Cloud providers build a proprietary control plane to deploy copies of the program and it could be argued that such code is a modification of the program itself and thus has to be released. That's why they won't touch AGPL code.
AGPL doesn't infect you code unless you don't link with AGPL-licensed one. Control planes rarely do this. That's why Amazon was absolutely OK with MongoDB being under AGPL.
> but it does not cover the case where a large cloud vendor simply takes an AGPL-licensed product and offers it as a cloud service
Because it doesn't need to, nor should it. That's only a competition issue if the upstream developer is actually offering a managed version themselves - and in that case they already have "we actually developed this software so we're the best option for supporting it in The Cloud™" as a selling point that even the likes of Amazon and Google cannot replicate (not without themselves participating in the actual development of the software in question). They should lean into that selling point and offer a better managed offering than what any cloud vendor could ever hope to offer.
Plus, as I've mentioned in sibling comments, large cloud vendors probably don't have much interest in reselling Hashicorp's products anyway. Why resell Terraform when you're trying to lock customers into CloudFormation? Why resell Vault when you're trying to lock customers into Secrets Manager? Why resell any of Hashicorp's products when the thing for which they're marketed - avoiding vendor lock-in - is literally antithetical to your business model of maximizing vendor lock-in?
> But, that hole only becomes toxic the moment you modify the code or plug proprietary stuff into it. Cloud vendors don't do that.
Sure they do. If they didn't modify their managed versions of FOSS applications to integrate tightly with the rest of their offerings, then why would anyone bother to use the cloud-vendor-managed versions in the first place? If there's no benefit integration-wise relative to just slapping the vanilla version on some EC2 instance or EKS container or whatever, then what's the point?
SSPL is much worse than AGPL. At worst AGPL demands you to license your own code under same terms.
While SSPL demands you to license third-party code from backup solutions to operating system and firmware. Good luck publishing source code of Linux kernel or even Windows under SSPL.
> companies like Amazon abuse FOSS licenses to stand up their own hosted versions of open source projects
This is not an abuse of FOSS licenses. If developers have a problem with this, there are open source licenses that would make this use case less attractive for Amazon, like the AGPL.
That licence tends to have the dual effect of dissuading otherwise valid users from using it, because a lot of devs and corps see “something something GPL” and just shut down.
Exactly, which is why all these companies that claim they can't survive without their shiny new I-can't-believe-it's-not-open-source licenses deserve all the scorn they get. I've flipped the bozo switch on Hashicorp.
I haven't looked to see what licenses are involved, but Pulumi makes liberal use of Terraform providers[1]. And I would definitely consider them to be a Hashicorp competitor.
> Pulumi is able to adapt any Terraform Provider for use with Pulumi, enabling management of any infrastructure supported by the Terraform Providers ecosystem using Pulumi programs.
TF providers are just wrappers around other APIs - and the vast majority ain't even developed by Hashicorp in the first place.
If Pulumi - another open-source infra-as-code tool (that ain't even a fork of any Hashicorp product AFAICT) - is really the thing scaring Hashicorp away from open source, then that doesn't really do Hashicorp any favors here.
> TF providers are just wrappers around other APIs
If it's so simple, Pulumi could have done this themselves. Why didn't they? Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
> If it's so simple, Pulumi could have done this themselves. Why didn't they?
Because that would be a waste of time unless there's some specific case where an existing provider is insufficient.
> Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
Pulumi itself is free software, just like Terraform was (and hopefully still is). There is literally nothing stopping Hashicorp from doing the exact same thing in the opposite direction.
Are you pretending they aren't a competitor profiting off that work though?
Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/. So, Pulumi has grown their directly competing product partially on top of the Terraform ecosystem - and I'd argue they'd be half as successful without reusing Terraform providers - and make money off of that product. It's at least understandable to me that Hashicorp doesn't like this.
Most TF providers are not maintained by Hashicorp, but by the company whose product the provider integrates into. Development of the provider is an investment the company makes to lower CAC.
Sure, but the providers for some of the biggest platforms are maintained by HashiCorp[1] - like the AWS, Azure, GCP, and Kubernetes providers[2], and it appears the Pulumi AWS provider (for example) _does_ use the Terraform AWS provider, even to this day[3].
3. https://github.com/pulumi/pulumi-aws/tree/008c4360bc9fc24303... - Just prove it to myself, I can see the `upstream` git submodule, which embeds pulumi/terraform-provider-aws, which is a fork of hashicorp/terraform-provider-aws, although the repo was not created as a fork in Github, so it is not marked as a "fork" and so I have to compare commit histories to tell that it is a fork.
The Pulumi Kubernetes provider is a native provider. It does not take a TF provider as a dependency. Instead, it works directly based off the k8s API spec.
The Google TF provider is actually maintained by Google via Magic Modules, a single source for both TF and Ansible . The generated TF provider does reside in HashiCorp’s GH org tho.
I've always seen open source as more of a spectrum. On one extreme, you have gpl3 stuff coming from the church of GNU itself. Moving up the spectrum you have stuff like the Linux kernel or certain CNCF projects, which can be used in proprietary distributions etc. Above that you'll have company specific licenses like the Amazon software license or whatever hashicorp+elastic are doing these days. At some point you're with RHEL where you need to sign a license to get their source, and above that you're signing ndas, and above that its closed source, and above that they're cryptographically obfuscating their source code with anti reverse engineering licensing.
I appreciate open source in all it's forms, as it's so much easier to 1. Read the code in case of a bug or just to understand your dependencies better, 2. Many of the semi closed licenses still allow you to learn things like syntax for GitHub actions or do analytics or whatever, which is still more value than an entirely closed system, and 3. It allows me to reproduce binaries and independently audit security.
That said, I'm worried about a tragedy of the commons situation. I'm not a fan of capitalism, but at the end of the day I can't pay for housing or taxes in clout or goodwill, and the only way I see likely to both attract talent and survive is one which works within the system while sacrificing their principles as little as possible. These wonderful engineers at elastic and hashicorp and pulumi and every other company mentioned in this thread need to eat.
I'm not saying I have an answer, but I am saying that I respect and understand why companies like elastic and hashicorp are resorting to drastic measures. If the choice is between either of those companies going under or having their source code come with a little bit more restrictions, I'd chose the latter. I'd much rather them have a noncompete clause in their license than have them just shut the window into their source code altogether.
That's being disingenuous. The link you cite is the pricing of Pulumi Cloud. Of course hosting infra can cost money. The second non-heading line in your link shows a way to host Pulumi on your own infra and that is fully free: https://www.pulumi.com/docs/concepts/state#using-a-self-mana...
However, Pulumi Cloud is only as valuable as Pulumi itself. If Pulumi didn't support deploying to AWS, for example, then it is useless to my organization which uses AWS and I'm obviously not going to consider Pulumi Cloud. So Pulumi does gain a lot of value even from just the Terraform AWS provider that it uses under the hood (and which it can continue to use because it seems Terraform provider licenses are not changing, which is nice).
> The paid features have nothing to do with the providers;
They absolutely do. If I use AWS and Pulumi could not deploy to AWS, well I'm certainly not going to buy Pulumi Cloud, am I? If I use multiple cloud providers and Pulumi doesn't support all of them, I'm unlikely to invest further in Pulumi Cloud, right?
The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
The fact that Pulumi leverages the Terraform AWS provider under the hood adds huge value for them, and I absolutely believe they indirectly profit off of that.
No, they absolutely do not. Pulumi - as in the actual tool, not its developers' equivalent to Terraform Cloud - would still exist and would have used those providers regardless of whether or not there's some Pulumi equivalent to Terraform Cloud. Pulumi also would've existed (and resulted in indirect profits via Pulumi Cloud) had that provider ecosystem not yet existed; it just would've been Pulumi starting it instead of Hashicorp/Terraform.
> The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
And you can use 100% of that value without paying a fraction of a penny to Pulumi, just as you can without paying a fraction of a penny to Hashicorp. It's a completely different offering from their respective paid products altogether.
> I absolutely believe they indirectly profit off of that.
You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers. That's one of the main sales pitches for open source, after all: to collaborate on something that benefits everyone instead of wasting a bunch of effort on independent silos.
That is: Hashicorp indirectly profits off Pulumi's own contributions to that same ecosystem. They could profit even more by making Terraform compatible with Pulumi's provider interface (even still! I'm pretty sure Apache 2.0 code can be included in non-FOSS codebases, BUSL included).
Like, the relationship between Hashicorp and Pulumi is not just to the letter but to the spirit of free and open source software. If Pulumi's existence and success (despite being nowhere near that of Terraform, and despite also being open source - even more permissively so, in fact) is indeed what motivated Hashicorp to switch Terraform from MPL 2.0 to BUSL, then that's toxic as all hell and completely nullifies any of Hashicorp's lip service to "open source".
> You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers.
This is idealism.
The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort. Then, Pulumi can spin up a directly competing product in a fraction of the time by reusing all of that work. So I understand the motivation for the license change.
Circling back to your original comment which spawned this thread:
> Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
The answer is unequivocally "yes". Pulumi has. And Pulumi can continue to do so, apparently. Terraform providers continue to be MPL-licensed.
With IBM Cloud® Secrets Manager, you can create secrets dynamically and lease them to applications while you control access from a single location. Built on open source HashiCorp Vault, Secrets Manager helps you get the data isolation of a dedicated environment with the benefits of a public cloud.
No, it's realism. The only one to blame for Hashicorp not adequately capitalizing on the two-way street that is multiple FOSS (well, formerly, in one case) IaC systems being compatible with one another... is Hashicorp. Instead of recognizing a case where "open source" is mutually beneficial, they'd rather take their ball and go home - and that's their right, but it ain't beyond criticism.
> The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort
The reality is that Hashicorp adopted Pulumi's strategy of autogenerating provider resources from API catalogs rather than maintaining handwritten bindings (i.e. what differentiates Pulumi's "native" v. "classic" providers). So yes, Pulumi's providers clearly have value. Hell, they can continue to have value even after Hashicorp's BUSL shenanigans thanks to Apache 2.0 being permissive.
> The answer is unequivocally "yes". Pulumi has.
The answer is hardly "unequivocal", per above and per the previous comments. Calling a collection of third-party-developed API shims a "product" is itself a massive stretch of the word, and calling bidirectional / mutually beneficial contribution to that collection "competition" is itself a massive stretch of the word.
IBM Cloud Secrets Manager is much better evidence in support of an unequivocal "yes" (though like most non-mainframe IBM-branded products these days I'd question whether or not it counts as "of any significance").
Would terraform have been successful without the ecosystem of providers provided by third parties, and many, many external contributions to providers they do manage?
ctrl+f for "open source", and note where they stop using it. Note that they describe this change to maintain "open, freely available products", not open source.
I think they're being more honest than others in not saying that changing their license is not to remain "open source". It's evident they know the pushback they would get from calling this "open source".
Sure, Crossplane leverages the K8s control plane for managing desired state for systems outside of the kubernetes cluster. It functions in a very similar fashion to terraform but it’s storing its own state in etcd instead of another state store. That makes GitOps + Crossplane play really nicely together and avoid the extra complexity that happens with terraform apply operations. They have a terraform wrapper provider for importing existing config and state.
It’s really nice to have infra and apps flow through the same pipes.
I mean, they allow you to create a manifest that then auto provisions some infrastructure, so... Shrug
I'm being half-serious. Of course the point is that "competing" is deliberately very poorly defined, and it's entirely on the whim of hashicorp to decide whether or not you're competing and then impose a lot of legal costs on you.
Did they have to get signoff from all contributors to relicense? I can't imagine this was a popular move for the people who contributed outside of hashicorp.
That CLA grants HashiCorp full license over your Copyright, and explicitly allows them to sublicense your contributions[1]. Drew Devault's blog posts[2][3] on this topic are extremely relevant.
[1] > Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to HashiCorp and to recipients of software distributed by HashiCorp a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
I don't know if they have required old commiters to sign it. I commited to one library that is now under Hashicorp back in 2015 and did not need to sign anything but it was MIT licensed back then. They have also rewritten affected lines as part of larger rewrite.
The CLA is a relatively recent thing. They certainly do not have my sign-off, though I haven't checked whether all code contributed after February of 2017 has been replaced (yet).
And I checked the contribution guide for the aws provider, no mention of a CLA there. I wonder if Hashicorp would be able to pull the providers under the same BSL in future ?
My understanding is that a _lot_ of the AWS provider was written by AWS developers on the clock. I think that pattern holds true for a lot of "official" providers. For that reason I don't expect to see BSL for providers.
how this works from the point of view of current license? They can't just take MPL code and modify license terms in my reading of FAQ (Q9 in https://www.mozilla.org/en-US/MPL/2.0/FAQ/)?..
Which does not disclaim "be forked and built on top of freely", especially given that Hashicorp products (in the modern era, at least) are written in Go and MPL is a file-level license: creating a new file in the same module under a non-MPL license and shipping it beside the MPL code as one broader unit is, I believe, fair game. But even still: MPL is a legitimate open source license that just asks that you give your changes back to the community. Seems like a fair trade to me.
> creating a new file in the same module under a non-MPL license and shipping it beside the MPL code as one broader unit is
but they are not saying they will be adding new files under business license keeping old files under MPL, they are saying future releases of products will be shipped under business license.
Well, sorry, I was responding to what I'd assumed was the parent comment talking about what would happen in a forked-Terraform world. The original Terraform project as maintained by Hashicorp is using its rights under the CLAs they required signatures for to fully relicense going forward, yes, that's correct (to my reading).
Why would you want to fragment the ecosystem like that, in response to a license change that is a non-event unless you're profiteering off of Hashicorps work?
Dunno about others, but I always ask myself where these companies would be if their software was under non free license from the start.
This is hostile to end users, small people an companies, not just big megacorps wanting the "steal" the code and run it as a service. Be successful in running and using Hashicorp's software, and they decide to shut you down if you are deemed a competitor.
At any moment for any reason they can declare that you your use or your business in some way competes with them and cut you off.
You have no recourse. They don't need to explain it. They can even add a product remotely like what you're building or misunderstand your product and you are screwed.
Given their exactly similar rug-pull stunt, in the context of what I was saying one would need to be able to load that link with date range restrictions showing before and after the rug pull, and (of course) exclude Sentry employees in order to show community contributions
I don't have the emotional energy to dig up such a report, but I'd be stunned if Sentry receives the same outside contribution rate as it did before
All that I get from this is that HashiCorp is no longer an open source company.
> However, there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don’t believe this is in the spirit of open source.
This is 100% in the spirit of open source. If this is a problem for them, why not adopt an open source license that compels developers to open source their code instead, like the AGPL?
This is purely a way for HashiCorp to ensure they are the only ones who can commercialize these formerly open source projects. Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
Ideology is great until people need to eat. That’s what revenue is for.
High level, times have changed. Source should be (my two cents, ymmv) about a mutually beneficial partnership between builders and users, not “give it all away for free or you’re not legit.” Users get to understand and extend what they’re running (via source), while the project steward/maintainer/owner can continue to do so.
It is a balance to be maintained in tension, not an equilibrium to be reached.
> Ideology is great until people need to eat. That’s what revenue is for
That sounds like what the GP comment is saying. If someone said "turns out open source doesn't work for our business model" it's hard to argue with. If instead they talk about "evolving open source models" and whatnot, it feels like they want the best of both worlds. It's been happening a lot recently that companies pretend they are "open sourcing" something for the PR but really use a much more restrictive license.
I argue the window is moving as to what “open source” means out of survival. Source available is the new open source, and what young technologists will grow up grinding on. You’ll have folks complain about it during the transition (as happens with any Overton window sort of event), but they’ll move on eventually and a new crop of tech industry will grow up with this as the new normal. Change is inevitable, broadly speaking.
I agree except I think it's our of short term greed plus arrogance rather than survival. Maybe in some cases that's not true, but when companies like Meta are championing pretend open source, it's not existential for them, it's trying to push for a world where they have more control. Like I said, I don't have a problem with closed source business models, it's the deliberate conflation that's troubling, especially when it's leveraged to get community contributions.
On the other hand, if popular software becomes faux-pen source (I read that somewhere recently) and community members stop contributing, it's a loss too because it means we all become takers on whatever company's terms.
Your almost certainly right about the window shifting, I'm going to keep complaining anyway.
> I argue the window is moving as to what “open source” means out of survival.
I don't think this is happening at all. Open source means the same thing it's always meant. Some people are just retreating from open source. Which is fine, they should be writing Free Software anyway if they want the world to have it, or use proprietary licenses if they don't. Otherwise very wealthy people will live on your back.
I agree. But there are an awful lot of younger devs who really do seem to confuse "open source" with "source available". It's worth educating people about this.
So, I don't think this is a generational thing. I think most people of all ages and generations have mostly just not thought about this. But the reason more people are thinking about it now is that the distribution model has changed on a way that has highlighted an existential weakness with this model.
I lack data, so I cannot say anything broadly. But in the devs that I know, this is 100% a generational thing. It may be different in different circles.
My perspective is more like the parent's. As someone who has grown up along with open source, I've found it surprising recently how up in arms people are about how critical the ability for anyone to commercialize a project is for the definition of open source. To me, I care a lot about whether I can see how software is implemented, and modify it for my own use, but it has never really occurred to me that I need to have the right to commercialize any arbitrary project.
But :shrug: I guess different people care about different things, is what I've realized watching these discussions unfold.
But I do think this purist perspective on open source is just going to result in more Snowflakes and fewer Hashicorps, because why bother with this fight?
> But I do think this purist perspective on open source is just going to result in more Snowflakes and fewer Hashicorps, because why bother with this fight?
Orgs like Hashicorp clearly think they benefit by pretending to be open source.
They could simply stop being disingenuous about their source available proprietary software, and nobody would stop them.
First of all, as is probably clear if you read my comments on this, I personally think it would be better if the definition of "open source" did not exclude this kind of re-sale limitation. I don't think it's intuitive at all that this is required to fit the definition of "open source". It seems to me like a tacked on ideological stance from the gatekeeper of the definition, that isn't present in or implied by the words themselves.
But while that's what I think, it isn't at all the view espoused here by Hashicorp. They aren't claiming this is open source. They are accepting the OSI definition and not claiming their new license falls within it.
They aren't being disingenuous. You're putting words in their mouth, and then getting mad at them about those words they didn't say.
> They aren't being disingenuous. You're putting words in their mouth, and then getting mad at them about those words they didn't say.
No, they say open source needs to evolve, the implication this is an evolution (not devolution) of open source.
Their announcement talks about how they spoke to OSS experts. That's not relevant: the experts would simply have said: that's not open source.
Hashicorp several times say the BSL is permissive. Permissive is a well established term in software licensing. No, the BSL is not. The BSD and MIT and Apache licenses are permissive.
Finally there is this claptrap from their FAQ:
> 17. Does HashiCorp still believe in open source?
>
> Yes. [...]
No, companies keep making services with code I can read and modify for my own use, and people in the community keep bringing this fight to them because they're peeved that other companies can't commercialize that software that they didn't build.
Companies will naturally conclude they should just make proprietary software, which doesn't require a big fight. And I think that's a shame.
The problem is these companies almost universally could not exist without open source software that allowed them to commercialize things. It is impossible for the vast majority of companies to ever "give back" as much to open source as they profit off of it - from the Linux kernel, all the GNU stuff, the nginx or apache webservers hosting webpages and API access, the haproxy load balancers, the corosync/pacemaker they're using to keep things online, etc. etc. etc.
How many of these companies could exist if all these projects underpinning their own swapped to the SSPL, BSL, etc? And I don't mean now - once you reach a certain size, if you have to replace a bunch of dependencies, you have the resources to do it. But when these companies were smaller, would they have been able to create their own implementation of all these dependencies and still get their product to market? Would they have had the resources to commit to all of it? Would they have had the money to pay for non-FOSS options?
How many of these projects would still exist if the community couldn't commercialize them? We're not even talking about whether or not they ultimately end up contributing code back, etc., because it's not like these licenses give you some threshold of code contribution after which you can commercialize it. Sure, the possibility exists of some special private licensing agreement being struck, but that's possible with proprietary code, too.
Source available might sound fine from a personal use perspective, but it ignores the fact that the environment that made all of this possible would not have been possible under that model.
To me, the difference is that these are all building blocks rather than standalone products. I think of these commercial products as making sense for standalone services, rather than libraries and other building blocks.
But also: I think the business model that built all those open source building blocks has always been pretty shitty, relying on a lot of altruistic un- or poorly- compensated work from people. And I think that's bad. But I don't think demanding that companies making useful services also be subjected to a shitty business model is a good solution.
You're welcome! Thanks for continuing the civil discourse :)
But, let's take just apache and nginx as an example: Lots of people offer just webhosting as a service. It's gotten less and less common now, with things like Squarespace, Shopify, Medium, etc. etc. etc., but once upon a time there were tens of thousands of companies that were making all their money by providing storage/compute/networking and a place to upload your HTML files, and then later adding in additional services like PHP and other scripting languages, MySQL for database hosting, etc.
Now, the context here is a bit different here, of course, particularly for Apache httpd. But Nginx has Nginx Plus, MySQL AB would license you a closed-source version or do the usual support/consulting/etc. stuff. But it's not hard to imagine a world where they could have easily said "Hey you know we're experts in running this stuff, we should just run it for people and charge them" - just like we see with a lot of these "open source" companies today.
There was never a general outcry about tons of businesses making money just hosting these open source services, even though the vast majority never contributed financially or otherwise to these open source projects. The only real difference I can see between then and now is simply what path the companies behind the projects, where applicable, have taken to monetize. Would the internet be a better place if MySQL AB moved to offering hosting as a service and put MySQL on the BSL, preventing all of these webhosting companies from having existed? If F5 had done it after acquiring Nginx? Cheap and plentiful webhosting is a big part of what grew the internet so quickly, particularly before the 'Web 2.0' days of social media sites centralizing so much of the traffic on the internet into a handful of places.
> But I don't think demanding that companies making useful services also be subjected to a shitty business model is a good solution.
Well, I'm not demanding a company do anything. I'm just saying that the internet as it exists today, including all of these companies we're talking about, would not exist if earlier on people had made the same choices they are. Open source is not about guaranteeing a viable business model to companies - it doesn't care about your business - it's about ensuring certain freedoms in software. And the internet we're discussing this on exists because of those freedoms it guaranteed.
If you can't build a viable business when abiding by those freedoms for whatever reason, then sure - go build proprietary software. I'm not going to call it or you evil. But I do take issue with a company using open source as a method to gain adoption, additional contributions, mindshare, etc. and then no longer being open source while talking about how they are an "evolution" of it. You're not an evolution of open source if you're removing freedoms.
The OSI Open Source Definition and the FSF Free Software Definition are for most practical purposes identical (and most licenses meet both or neither); historically, the Open Source and Free Software communities have somewhat different reasons for preferring the same thing, but the things are the same.
That distinction is what makes copyleft licenses. Free software is just as overarching as open source, see e.g. the FSF's list of free software licenses: https://www.gnu.org/licenses/license-list.html
MIT, BSD, and GPL are all on both OSI’s list of Open Source licenses and the FSF’s list of Free Software licenses.
Yes, the FSF has a general preference that people use copyleft licenses like the GPL, but they recognize that permissive licenses meet the Free Software Definition.
GPL is an open-source license, and MIT-licensed software is free software.
The difference between free software and open-source is a matter of marketing. Open-source is a way of presenting free software to businesses and investors. Free software is an unabashedly political movement, openly concerned first and foremost with the public good. But the licenses themselves and the software itself, those things are identical.
This is what these companies want you to believe, that it's a fait accompli and you just have to accept it. That's not actually reality, and giving up words and communities to people who want to corrupt them is not the right reaction.
> I argue the window is moving as to what “open source” means
Only if we let it, and stop shouting about it and finding alternatives every time a company does this.
This isn't a new thing; companies have been trying to play "almost open source" games for decades, and they'll continue playing those games as long as it either works or doesn't have sufficiently large penalties for trying. (Much as companies will continue violating copyleft licenses as long as they either get away with it or the penalties for trying are simply an expected part of the risk.)
The best possible response to a company doing this is that someone forks the code, starts or expands a competitor, and the original company's revenue drops massively as a deterrent.
> The best possible response to a company doing this is that someone forks the code, starts or expands a competitor, and the original company's revenue drops massively as a deterrent.
but still manages to suck the air out of the room when you want Elasticsearch because AWS already has the company's billing details and no one wants to figure out paying another provider.
The window can't move, as there is an official version of what "open source" means, the Open Source Definition, which does not restrict you from reselling stuff.
We've had "source available" for a long time, which means something else.
I don't disagree that people may still use SA software more as time goes by, but I would argue that when possible people will prefer open source controlled by entities that keep it such.
This is not how language works. The phrase "open source" will mean what people think it means. An organization with a lot of credibility and mindshare can affect that meaningfully by maintaining and explaining the official definition from their perspective, but they can never be guaranteed success in convincing people that their definition is what those words will mean forever.
> "open core" has always been a euphemism for "proprietary."
Yes. And in some ways, source available licensing is a nicer model for proprietary software than open core. At least with the former you can actually see all of the code to inspect how it works when something is broken.
Bleh. Every business wants to build on software freedom but they don't really want to see others freely build on their own software.
Projects can have a Contributor License Agreement (CLA). It gives the owner of the project a right to republish (or copyright) the contributions. You can't contribute to the project without signing it.
And this is why I think people who love Software Freedom should think twice about signing a CLA for their copyleft licensed contributions. [1]
inbound=outbound license terms is a good norm for FOSS. Why should a software vendor play by different rules than everyone else when it comes to things like copyleft compliance?
This is true. The question to me is: does the party to whom you give the rights and authority subscribe to community-oriented FOSS license compliance principles? [1]
That's not true. As the copyright holder they are not bound by the licence that they release it to others under.
The reason AGPL isn't being adopted in these situations is that it doesn't sufficiently protect against someone doing what e.g. AWS repeatedly does - turning open-source projects into services and then dominating the market while continuing to benefit from the upstream project. See the ElasticSearch licence change for a prominent example.
Looking at the public data [1], Hashicorp looses money every quarter. At some point they need to stop burning cash because they have yet to figure out how to run a sustainable business.
I don't know enough about their operations to have good suggestions on how to become sustainable. But, I don't like this move. There are many sustainable open source companies. Moving to source available from open source will likely never be a move I like.
Why do you think "open core", which most of those are, is somehow better than BSL?
> pretty much every crypto company in the blockchain/web3 space
The entire "space" has yet to prove to be sustainable. Most of these are hype-driven borderline scams, I would not list them in a _sustainable open source business_ context :)
> Why do you think "open core", which most of those are, is somehow better than BSL?
Firstly, I don't have a problem with BSL. I do think in general it's a bit of a slap in the face to build a business on the backs of volunteer contributors, and then close-source all your codebases which are comprised of their work.
Sure, when people contributed, they signed a CLA which gives Hashicorp the right to relicense the work (which has legitimate uses outside of killing open source, such as giving them the ability to make that software available under other terms in addition to their open source offering)
it gives whiplash to the people who contributed based on that promise.
Actually, I don't even know if this is legal, but even if it is, it's a huge violation of the trust of outside contributors to their software products.
> The entire "space" has yet to prove to be sustainable.
I agree that it's unproven, but this downturn has made apparent that so are the majority of software companies which have not IPOed and shown a sustained profit for 5+ years.
I'd give Uniswap pretty good odds of outliving the majority of YC startups.
> I'd give Uniswap pretty good odds of outliving the majority of YC startups.
The majority of YC startups are definitely not sustainable.
Probably even most of the successful ones are not sustainable, they make empty sustainability promises hoping to get bought by <BIGCORP> and end up on "our amazing journey" lists.
Sorry for veering off-topic there. I agree that re-licensing and BSL/AGPL are muddy-territory and I'm also not sure how to feel about them.
But a surviving project moving to BSL is still clearly better then the company going under and the project ending in limbo.
Even with BSL you can still access the code, audit it, learn from it, fork it to keep your own patches on top and keep up with upstream, etc. Huge value compared to closed source.
You're free to decide open source isn't working for you. (Well, assuming you're not using any open source software that has decided on viral licenses because that's the payment _they_ expect)
You're not free to decide your source available model is open source and reap the marketing benefits of open source without the costs.
I think these projects should just dual license as AGPL and BPL/EPL.
That way all the "it's not really technically open source" complainers couldn't day that its not technically open source.
It wouldnt substantively change anything of course, but that's somewhat the point. BPL/EPL/SSPL was always fully within the spirit of open source, it just pissed off the same large corporations who also can't stand the AGPL.
One day someone untrustworthy will be in charge of the FSF, and ‘or later’ is suddenly going to be #awkward. Linus made the right call there, for sure.
The FSF is not an autocratic kingdom with a despotic ruler on top. It is a 501(c)(3) foundation, with bylaws and regulations to cover this eventuality.
This was all hashed out years ago in numerous flame wars on Usenet, as I’m sure you know.
I'm not sure if we're agreeing or not to be honest. I'm not sure if you're implying it's a bad thing that people won't contribute to AGPL+CLA (and thereby justifies these more restrictive licenses), or agreeing that people shouldn't contribute to AGPL+CLA (and thereby volunteer their time to the benefit of one specific vendor).
Whether or not someone contributes to something and under what terms is a personal choice. I dont think there is anything wrong with not contributing for any reason at all. Or if you dont like the cla, forking it and not using a cla in your fork.
I view that as a very different question from whether its ethical to advertize something agpl+cla as being open source.
They exist so that you can continue to use hashicorp tools in your business for free and look at/change their source code like you would any other software.
The one restriction is that you can't compete with their hosted services using their software. Which 99% of people who use their software have zero interest in.
The "it's not fair! it's not real open source!" narrative is pumped up by companies like Amazon that feel entitled to use their monopoly power to leech value from these companies by selling paid versions of their products.
No, Open Source has always required that usage be unrestricted (Either Freedom 0 or OSD/DFSG points 5 and 6). Allowing any restrictions on usage tends to get political, as people use the license to push their specific issue, making it much harder to share and use code without issues.
So requiring that anyone that runs your code and tries to publish a paper can only do with your approval (which is a real license that exist) is fine also? Saying "anyone can use this however they want" is much easier to check for that coming up with rules (and licenses) that allow for the BSL but not for the above academic licenses.
> Ideology is great until people need to eat. That’s what revenue is for.
It isn't just the need to eat. There's also the issue of keeping investors happy and their continual drive to maintain growth or earnings at stratospheric levels.
Strict IP laws are the only safe way to do that, and that is why so much software has leveraged them over the years. The internet era felt like an aberration for a while, but things seem to be shifting back to high double digit margins as the only desirable goal.
Based on multiple previous employers of mine, it seems like software companies start noticeably going downhill about 1.5 years after they go public. Let's check Wikipedia and see how I did:
> On 29 November 2021, HashiCorp set terms for its IPO
...I'm starting to think I'm onto something. (I do welcome anecdata that either helps or hurts my hypothesis)
> it seems like software companies start noticeably going downhill about 1.5 years after they go public.
I firmly believe this is a fact too.
One place I recently worked, I joined as it was going public and it went downhill quickly. The friends I’d made there talked about the fun perks, holidays and benefits the company was known for. Over the space of less than a year most of the culture atrophied, people left in droves and there were exactly zero holidays or perks given out.
I hate to say it but this feels inevitable. We've accepted that the requirement (legally!) of a public company is to deliver the maximum possible returns to investors, and as such, employees become a cost center to optimize away, and just generally, anything that negatively impacts the quarterly report must be eliminated, even if that thing is the only thing that will keep the next quarterly report in the black.
Quarterly scope for fiscal data is one of the most short-sighted decisions humans have ever done. Expecting quarterly up-and-to-the-right, where simple sustenance is not enough, but profit must grow quarterly, on a planet with finite resources in an economy with finite money, is a guaranteed, zero-exceptions, recipe for failure, by definition.
Fiduciary responsibility isn't entirely about returns, it's about the best interests of the investors. And if you've invested in a company with a certain mission it would be said to be in your interests for that mission to continue.
If I were starting a business these days I'd be tempted to found it on the basis that 60% must be owned by employees of the company until the last living descendant of king Charles dies.
It's not a legal requirement. Fiduciary duty doesn't even mean you have to act in best interests of the investors, just that you're honest and not trying to swindle them.
Making it seem like it's a legal requirement however is a very good thing for all the corporate raiders out there.
Their stock was down 60% only 3 short months after IPO.
I think this is just a struggle to turn what was once technical excellence into something that gives money. I haven't followed HashiCorp lately but was once a fan of some of their products. These days it seems things are slower over there. At least that's what it feels at a distance.
It's not weird at all to go public before profitability, that was even the standard in tech for the longest time. The IPO was a _fundraising_ event, not a dump-the-company-on-the-public-and-move-on event.
>Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
This seems too black and white. Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
> Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
For the most part, no, the main direct customer benefit comes from the absence of lock-in with regard to maintenance and services thar results from the absence of usage restrictions.
There's some potential indirect ecosystem benefit for customers from the somewhat lower friction for partners in some source-available-but-use-restricted situations, but otherwise for most customers its the same as any other proprietary license.
Being able to tear through the source code of something to figure out why it's doing what it's doing is valuable even if you never make changes.
I worked for a company a lot of years ago that had BSDi licenses for some of it servers and had paid an extra fee for source access and that -did- actually come in handy to me once or twice.
Later, the same went for the Radiator RADIUS server where you got source access automatically with a license purchase.
White box versus black box debugging is absolutely something that can make a difference, especially when something goes wrong.
> Being able to tear through the source code of something to figure out why it's doing what it's doing is valuable even if you never make changes.
Yep. I've definitely noticed this at work with some proprietary ('open-core') software that we use, and it's made me inclined to prefer source-available proprietary products over more restrictive proprietary ones as well. It's not as favorable as actual F/OSS, but it definitely makes a bit difference nonetheless.
It’s obviously a spectrum, but (some) people think of different things when they hear “closed source” vs. “source available”. Also, a company like Microsoft providing source to big customers doesn’t make their products source available, at least not in the commonly understood way. Source available usually means the source is freely available for reading and often compiling. That obviously does not apply to Windows.
> Closed source can (and does, see Windows) provide source to customers too.
This just means it's Source Available to certain customers - Closed Source to others.
I agree that universally available "timebomb open source" "Source Available" is different from "Closed Source", though.
It allows for certain risk planning, like: If HashiCorp goes away, we will be able to host and patch (and keep using) product X for the foreseeable future - along with the ability to actually read the code and determine if it is something worth touching with a ten foot pole...
> Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
The opposite of open source isn't closed source, the opposite of open source is restrictive. You're not forced to refuse to let people see the source when you're not open source. You're not forced to eliminate everything that OSI-approved licenses must have if you're not OSI-approved. There are no OSI cops that bust proprietary vendors for using a subset of their characteristics.
Of course it would be better if it were Free software, but it would be better if all software were Free software. They're doing them.
edit: My objection comes when people pretend licenses are open source when they are not OSI-approved and couldn't be. HashiCorp is not claiming to have remained open source: they're now "source-available."
The blog post is disingenuous. We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin.
Thankfully over time, they already pushed responsibility for most Terraform providers back onto their partners, so I'm hopeful the ecosystem of providers can still stay vibrant and open.
We are deep believers in open source---heck my last project at Microsoft was to take .NET open source and cross-platform, our CTO helped found TypeScript, and Pulumi is an Apache open source project---it seems HashiCorp no longer is.
If they think we'll go crawling back to their 100x more expensive 6-7 figure Terraform Enterprise garbage just because we can't use spacelift anymore, then I'll show them the team of engineers we can hire for the same dollars to move the whole stack to pure pulumi or crossplane or the various CDKs
The bald faced disingenuous nature of this change here is wild. They can't compete at their pricing because their pricing is absolutely insane over what the market can bear and they refuse to accept it.
They are going out of their way to make it less expensive to stop using terraform altogether right as so many new options have entered the market
I believe it's a bit too early to make this call but based on the experience of interacting with Terraform the binary it would be absolutely amazing for the community if Terraform could be turned into a library that can become a building block for higher level services.
I don't know the details of BSL, but can HashiCorp now require compensation/$$$ from Spacelift, Scalr, Env0, etc? In that case, these products can be forced to offer similar pricing as Terraform Cloud.
IANAL but I believe the BSL restrictions only apply to new upstream code versions. All HashiCorp repos can and always will be usable under MPL as they were up until the moment immediately before the license change.
In other words: if you hard fork now, you don't need to pay.
Can I ask where Pulumi gets revenue from? (Honest question first time I have heard of you, quick look seems to be a CentOS for hashicorp ?)
I love the ethos of open source and have spoken at and helped run conferences, and had the pleasure of being paid to develop it - but the productivity I had when paid ten hours a day to work on OSS compared to whenever I get a chance between work family and everything else, well, it's better for everyone to get paid and release code, than not get paid and not write the code.
I see these semi-commercial licenses as the equivalent of a legal "just don't take the piss".
Would be interested in your side of the question. How do we keep on developing the code as well as keeping it open?
I am a paying Pulumi user. Their tool integrates with a cloud platform and we pay per resource managed by Pulumi.
Pulumi is one of several products where I like that it’s open source in case I need to move off their cloud, but hope that I don’t have to (Plausible is another).
Said well (and thank you for being a customer and valuable member of our community!)
The analogy I draw sometimes is that our open source infrastructure as code SDK ("Pulumi") is like Git, and our commercial offering ("Pulumi Cloud") is like GitHub.
Like GitHub, the Pulumi Cloud offers valuable features that go beyond the open source project for teams looking to manage lots of projects securely at scale, but we definitely love our open source community and want folks to have the choice to use Pulumi however makes the most sense for them.
This approach also has the nice consequence that we can be fully transparent with our community at all times while also building a strong, long-term business. If a new feature is part of the infrastructure as code SDK, it's open source and free; if it's part of the Pulumi Cloud SaaS, it's part of our commercial offering. This avoids needing to do things like artificially hold back features (like open core) or violating our commitment to the open source community (like Hashi's new license).
Is the Pulumi Individual Edition open for use by solo founders operating as a sole proprietership? I can't find anything clarifying whether it's individual (as in hobbyist, nonprofessional) or individual, as in, one person not collaborating with anyone else.
Yes it is open to individual comercial use (companies much larger then sole proprieterships may only have one person doing inferstructure). They also have a version for nonprofits https://www.pulumi.com/pricing/open-source-free-tier/
So here's my perspective on these two competing models:
1. I can read all of the code, modify it, and self-host it for my own purposes, but the license disallows me from re-selling it.
2. I can read, modify, self-host, and commercialize a subset of the code, and the rest is an opaque SaaS.
To me, as a customer with no interest in re-selling this code, I don't see how #2 is better than #1 in any way. And I find it incredibly mystifying that I keep seeing companies ragged on here for doing #1 while the model in #2 is somehow held up as the paragon of ethical virtue or something.
Can you help me understand? Why is it better for me to be able to read less of the code I'm running?
Convenience and reliability from a business perspective
For #2 in good faith using the github model here,
Sure there’s Git and Github. Also sourcehut, using google cloud source repository or any managed git service.
Either 1) I need the software and I can have a team maintain it.
Electing for the software-as-a-service vs self hosted model is in itself.
1. I can compute, resources, maintenance and time The proprietary or a version of the product myself or a fork and get the feature functionality from other open source or provider.
2. Pay for the GitHub licensing cost and using the service and ok with magic abstractions to operate the software. (Which admirably lately has been bad.
Also frame it as from the beginning of the git project elected to also build all the same parity features, would it be the same tool, be the product that exists, or brain share it has today. Maybe not.
I maybe misunderstanding you here but in these cases opaqueness is part your trade off to offload fairly complex for a marginal cost that’s s decision by you.
What I like best is to use a fully managed service that I can contribute changes or even self host a modified version if that's what I need to do to get what I need. But I don't want to self-host. But I highly value the option. And I highly value the ability to go read the code when I wonder "hmmm why is it doing that?" and maybe contribute a bug fix if it shouldn't be.
All of this works great with model #1 - with full "source available" with a license that limits re-sale - but is limited with model #2, where it only works for the "open core" portions of the product, but not the proprietary SaaS portion.
It’s also fair to say this isnt black and white and open source is vast and there are certain software and companies where opting for #2 that definitely feel like a big rug pull, money grab, and smack in the face to the community that supported them. (Is red hat in my opinion)
If you want to build something with a bunch of smart people for a long period of time the outcome is raising venture capital, paying people salaries that are competitive to share holders, and won’t implode. The bsl is a consequence of that but it is a rule to guard from the few bad apple in this case.
What’s ethical or virtuous or perfect is very nuanced
Usually the two are not mutually exclusive. Terraform Cloud (the HC equivalent of the aforementioned "opaque SaaS") is afaik not open source and never has been, you can't read the code for it or self-host it. Not opining on the broader issue, just clarifying this point.
Plausible is amazing, I love it. I moved off of another platform that started as open source and then went closed source, but Plausible ended up being a better platform over all anyways.
I really don’t think that was ever in doubt. You only need to use it for a very short time to find that the ergonomics are infinitely nicer than Terraform.
My biggest issue with terraform is concept of state file. It seems that Pulumi continues on this model. I wish someone came up with innovative idea of not needing state file.
From my prelimary search, Bicep does utilize a state file, but it is completely hidden from the end users. Seems to be managed in Azure directly and automagically.
I think you might be misunderstanding this page. Bicep's "state file" is actual Azure state. Bicep is a nicer way to write ARM (Azure Resource Manager), which is pretty much an Azure API. if you are familiar with Kubernetes, ARM represents Azure internal state in the same way kubernetes YAML represents actual kubernetes objects stored in the cluster.
> No state or state files to manage: All state is stored in Azure. Users can collaborate and have confidence their updates are handled as expected.
Not sure how I could "misunderstand" this quote to mean anything else.
By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.
> this is difficult for me to think about in the same way as trying to picture a 4th dimension.
Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.
tagging provider resources? not speaking for every provider or api, but at least on AWS not everything that can be managed supports tagging.
also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.
infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.
totally possible im
missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.
This anecdote is a lot less interesting, both because of the separation (you know some people vs they run a company with direct exposure) and lack of detail. I'm sure you do know some people who contribute, but you haven't given any details about their experience that would contradict OP's claim that contributing is hard.
I work at AWS in Professional Services until tomorrow. I worked with the SA and had meetings with the service team responsible for the AWS Service in question to discuss the API shortcomings that we needed for automations. He contributed to Terraform once the APIs became available from our service team and I wrote the equivalent CloudFormation custom resources for a project (and open sourced on the public AWS Samples GitHub repo after going through the approval process) as part of a larger project.
I found a bug in the underlying service API that affected both my implementation and the Terraform provider my coworker wrote. I posted a sample in our internal Slack channel where the developers of the AWS service hang out and they fixed the API bug relatively quickly.
My coworker, had no problem getting his TF code merged in. I know the code he wrote and I went to the GitHub page before posting this and it is in there.
Later as native CloudFormation support was added, I replaced my custom resources with the native equivalent as part of the larger project I was working on.
There's probably not much AWS contribution to the core of Terraform from AWS, but there's very little contribution to that from anybody outside of HashiCorp because contributions happen on the providers.
AWS is definitely involved with their provider though. AWS ProServ built out a whole account vending machine thing that was in Terraform (the name escapes me atm), and various other service teams and SAs are regularly involved in contributing to and growing the Terraform ecosystem.
It would be super disingenuous to imply AWS is not contributing to the success and growth of Terraform.
It's definitely possible. I patched the AWS Terraform provider. It took three months to merge the two line bugfix though. Terraform's biggest weakness may be that it's too ambitious for its own good. 1.7k issues on Terraform itself and another 3.7k on the AWS provider. Ended up using boto3 to build out my CD platform.
>We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin.
OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.
You have to acknowledge that all these OSS projects officially backed by a corporation don't want you to contribute certain features that are part of their enterprise offering. As soon as there's an "enterprise" tier, contributions are not only based on their merit, but also evaluated as a threat to their business model.
Sometimes it's not even obvious for external contributors, but there may be some small overlap with other paid features that are part of their product roadmap.
If a project on Github only has maintainers from the corporate side, you can be certain that they will ultimately drive the product for their own interest solely.
We should always pay close attention to the governance model of projects we depend on or that we wish to contribute to.
Of course, but the major difference is that if I don't like the maintainers, I can create a fork, build a community around it and happily run it in production. Imagine where nodejs would be right now if they had been BSL licensed in the iojs times.
I’m sorry, but no. These are usually simple bugs like “forgot to a set a field during refresh”. They almost always correspond to one or more Terraform issues too, often ones that have been open for 4-5 years or have been “marked as stale” by some infuriating bot.
I don't know if it is the case for the fixes pulumi sent, but for PRs I've made to terraform providers it can take a very long time for them to be looked at, and even longer to get merged. And I think it is mostly from nor having enough resources to approve and merge PRs. Although that could possibly be fixed by inviting developers outside the company to help with approval and merging, especially for providers.
Sure, OSS doesn't mean you have to take all PRs, but if your claim is that others are just taking your code and not giving anything back, one of the alleged leeches showing up to talk about how they've tried to give back is very much pertinent.
Having been on the upstream side of things, it's very he-said-she-said. HashiCorp code could be a PITA to contribute to, or maybe this particular provider was bad at contributing.
The only way to know for sure is to dive into the merged and unmerged PRs and see how they were handled.
I'm not affiliated in any way with one of their competitors. Co-workers and I sent bug fix PR's to for example Vault. The last couple of years almost none of them were merged. These were small bug fixes, not (large) feature additions.
Then don't complain about people not contributing to your projects. You reserve the right to reject my PR, and I reserve the right not to contribute any more.
isn't the simpler explanation that they would in effect lose the ability to relicense the project and therefore lose control of their baby?
To not lose control you need to have people assign copyright which is generally a headache. I've only heard of the FSF doing that .. (not sure why this hasn't been streamlined electronically somehow)
That's a lot of assumptions you're making here. From my little use of terraform it did had a bunch of issues that were purely a bug and laying unfixed for a long time.
For example, the widely used 'count' anti-pattern is still present, and no actions have been taken up to this day. This topic has persisted for 5 years. 5 YEARS!!! That's what triggered my decision to migrate to Pulumi.
I'm not sure if open sourcing .NET is the best bit to put on your resume when Microsoft has been sabotaging the developer ecosystem to keep VS relevant. [1]
Not that I don't appreciate the effort. I'm sure what has been achieved involved a fair share of convincing too.
It sounds like a Terraform alternative, but looking at the website it doesn't really convey if it's a Terraform fork or ground-up re-write, or something else?
Not sure why you're so insistent on this when Pulumi folks themselves on this post have said that they contribute back up to the AWS provider source repo (1).
Maybe not all their providers utilize Terraform, but it was definitely how their product started out. When you run Pulimi using their AWS provider and get errors at runtime, some of those are verbatim Terraform errors.
Their docs and site is very clear to muddle this connection but if you ever used their API, you'd know this.
I am very much wondering this too. I've used Pulumi and like it a lot, it has a great UX in general. But the ecosystem for Terraform is orders of magnitude bigger, e.g. searching for help on Terraform is going to give a lot more results than Pulumi. As someone who can dig into details, this is not a big deal and can use Pulumi on personal projects but cannot in good faith recommend it for team projects only because of the ability to find resources is more important then.
I don't know if the license change actually means providers will not be able to work with Pulumi, but if it does, it seems risky to use Pulumi even for personal projects if newer provider versions (i.e., versions that work with newer products released by the cloud provider) will not work with Pulumi, it's a dead end. And that's not to mention the useful providers that aren't cloud and completely community developed that will not have the resources to maintain two codebases in any case (I'm thinking of Sendgrid).
I looked at terraform-sdk license - it still seems to be MPL. I think this means that all providers can continue to be open and work with both platforms, it will be important for Pulumi to clarify this to prevent the death spiral. Given some negative feedback towards the Hashicorp blog post from Pulumi employees on this thread, I am somewhat skeptical of this since if everything is fine, then complaining will otherwise have a negative effect, that us users have to assume that Hashicorp is actually stomping them out. And if it's the case, sorry but in good faith to everyone else that may need to work on infrastructure I make, I will have to be complicit in the stomping.
> This is purely a way for HashiCorp to ensure they are the only ones who can commercialize these formerly open source projects. Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
Pragmatically I would rather bsl than closed source and I am more likely to use a product that is bsl, with reasonable transfer time and license, than a 100% closed source product.
I'd also much rather have "open source" with commercialization restrictions than closed source.
It's still in most people's best interest to contribute to these projects if they were before, or would have before. Many businesses(and this is where most of the contributions get funded from, let's be real) rely on these projects and have no intention of selling them or competing with HashiCorp services.
I'd rather have proprietary than "almost open source". Both aren't useful, but only one attempts to damage the common understanding of what "Open Source" means.
I do not call anything under BSL open source. I would prefer if companies when presenting the BSL talk about their schedule to open source, the schedule being when the Change License takes effect, at least if the Change License is an open source one.
Under BSL, change license is required to be open source. I haven't seen any precedents yet, but MariaDB owns the BSL trademark, so they can enforce that.
Why? To me, the BSL comes off as a good faith attempt at a compromise between the letter of "Open Source" and the realities of not wanting to give free labor to your competition.
The actual text of the BSL mandates - under threat of infringing on BSL's trademark - that in at most four years the code will be available under a GPL 2.0 compatible license. In practice, the BSL license is usually a traditional open source one with caveats. The BSL FAQ also states and restates many, MANY times that it is not an open source license according to the OSI's definition.
I can't help but feel like the outcry over this is just a tempest in a teapot. I have a hunch that "Open Source" will do just fine without us having to carry water for it. After all, the list of OSI's corporate sponsors is quite illustrious: https://opensource.org/sponsors/
I can’t believe you’re the only one in the thread who’s mentioned that it’ll revert to traditional open source licensing in four years. That changes everything, imo. It’s so much better than software staying closed source forever, possibly because the company went out of business.
What? Why? I don't get this at all. Like, the direct pragmatic benefits of being able to read and modify source code are just enormous. The benefits of maintaining this pure definition of open source are amorphous at best, in comparison.
If we don't have a common definition, everyone has their own, and there's no common understanding of what rights you have for a piece of Open Source software. That commons has far far more value than any one or ten pieces of software.
> That commons has far far more value than any one or ten pieces of software.
I don't think so.
I suppose I can understand why people who feel strongly that the OSI definition is perfect (or at least extremely good) are very intent on protecting it, whereas I see it as flawed and am thus less concerned about this fracturing. So I understand your perspective upon reflection, though I honestly have a lot of trouble imagining holding it myself.
A lot of people in this thread have been saying stuff like "just go full proprietary, that's better", and it sounds ridiculous to me every time I read a variant of it
What would you change then? Practically only the 4th criteria would be one I'd change (but presumably it's there for a reason):
"Integrity of the author's source code: The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software."
As for the commons, you are aware that the OSD comes from the Debian Free Software Guidelines (it's the same thing but for some minor working changes)? That is the commons that's been talked about, and it's deployed on far more systems than any BSL code is. So moving to completely propriety (note that this doesn't mean it's not Source Available) means that everyone is upfront about what the state is, whereas something like the BSL is leaning into the halo effect under the justification that the code will be open source at some future point.
Yes, I don't think it makes sense that the definition of "open source" requires that people can arbitrarily re-sell it. Like, just the words themselves, in my view, clearly don't imply that. I'm happy to stipulate that this is what was meant when the term was invented and that there is a single gatekeeper of the official definition in order to keep it this way. I'm just telling you that I (and I think many people) find this to fall outside what the words directly evoke. So to me "source available" just sounds like a slightly more awkward synonym. But I don't mind using the official language, because I know people care a lot about this (to me) extra ideology, and I think they're entitled to advocate for that.
But this second part of the argument I just don't grok at all. These licenses like BSL provide significantly more of what I want in software I use than proprietary software does. (Namely, the ability to read, modify, and self-host the software of I choose to.)
I think what must be going on is that when you see a license like this you think "there is no point to something like that besides a PR stunt trying to imply proprietary software is open source", and I think "oh this seems like a really useful compromise that allows commercial enterprises to create software with code that I can read, modify, run myself, and contribute to if I want to, without a different company that did none of the work on the software making all the money from it". Just totally different perspectives.
So if you got the rights from the BSL but the part about the code becoming Open Source you'd be happy with right? I think that's a completely fine attitude to take, and sure, all other things being equal, code licensed under the BSL is better than not having access to the source at all. But, given (at least) the majority of BSL projects were under an open source license, with external contributions, the spectre of "I have changed the deal, pray I do not alter it further" is raised. Additionally, if you read the actual post by Hashicorp, they do sail quite close to the wind in terms of implying the BSL is open source, so had they been more careful in their language (or even in their CLA), then people would be less annoyed.
The reason I'm personally annoyed at the attempt to drop the requirement for no restrictions on use is because it is something some academic software does (things like "if you use this code, any results must be shown to me before publishing and require my approval", which as you can imagine isn't great), or with rules around benchmarking (which some DB companies have been known to do), and it's significantly harder to draw the line between something that would allow the BSL, or the above two cases, than it is to require no restrictions on use.
I agree with pretty much all of this! Certainly, I would have a lot more respect for projects to start with this kind of license.
But this part:
> had they been more careful in their language (or even in their CLA), then people would be less annoyed.
I just don't agree. I think they were very careful in their language, and I keep wondering whether everyone here who is pissed at them even actually read it, because I feel like a lot of people keep saying they said things that they clearly worked hard to not say.
I don't think that the OSD is perfect, at all; I will readily acknowledge its problems. (And OSI more so.)
I think it's a common shared understanding and a focal point, and there's huge value in preserving that. Having a different common understanding might be acceptable, and might even be an improvement, but only if people agree on it. Having no common understanding would mean something of great value was lost.
Right now, many different groups who may not all agree on all goals nonetheless gain value by sticking to Open Source, and not a dozen slight variations on additional restrictions. In the absence of that, we'd have the "non-commercial" group, the "educational use" group, the "don't compete with us" group, the "don't use for military applications" group, the "don't use for nuclear reactors" group, the "don't use to develop proprietary software" group, the "don't redistribute unmodified versions" group, the "don't distribute outdated versions" group, a dozen variations on "don't distribute if you disagree with our values" groups, the "don't distribute if you're a large company" group, the "don't distribute if you're a specific company" groups...
Every one of those is a license term I've seen advocated. Every one of those violates the OSD, so it thankfully stays obscure and unpopular, because enough people prefer using and contributing to software with less unusual licensing.
> Having no common understanding would mean something of great value was lost.
Yeah I guess this just seems like hyperbole to me. It seems good to me that there's a pretty widely agreed upon definition, sure, but I just don't think it matters all that much, in the scheme of things.
You do realize that it is people like you who are turning FOSS in to OSS, then claiming BSL (and non-OSI Stuff) are not OSS and blaming others for damaging understanding?
> Both aren't useful, but only one attempts to damage the common understanding of what "Open Source" means
We have a messaging flow building platform which is BSL. Anyone who wants to run their own instance is welcome to and people do and thus find it useful. The idea that the world would be better off if we made it closed source and prevented that... is just nonsense.
> Anyone who wants to run their own instance is welcome to and people do and thus find it useful. The idea that the world would be better off if we made it closed source and prevented that... is just nonsense.
How does making something closed source automatically mean someone can't run their own instance of it, even for free? Closed source does not mean 'You can only download this if you pay us', just as open source does not mean 'You can download this for free'
Closed source doesn't preclude developers distributing it for free, BSL isn't claiming to be Open Source.. but it's silly to insist that that software that is *publically available* to anyone to download and run.. describe itself as "closed source".
That's true. I think the taxonomy I'd really endorse is that the dichotomy is between free software and proprietary software, and within each there are a range of restrictions/guarantees (depending on your PoV: user or developer) that licenses might have.
The broad distinction we care about within free software is copyleft vs. permissive, and one important one in proprietary software is source-available vs. closed-source.
Then besides all of that there are the non-licensing realities of how development is actually carried out, whether it is collaborative with outsiders, and with which outsiders...
The terms get harder because open/closed suggests straightforward opposites that partition all the options. But I'd characterize licenses like BSL and the Fair Source License as 'generous proprietary licenses with public source availability', but not open-source.
I have a feeling that the term 'open-source' is more likely to erode than 'free software', in the coming decades. We'll see, I guess.
I'd agree with that and honestly I don't really care too much how our stuff is described except that it seems inaccurate and unfair to apply something like "closed source" to a BSL project that takes PRs, and to insist that only code released an OSI licence can be of benefit to the world.
> The broad distinction we care about within free software is copyleft vs. permissive
You are exactly correct about this.
1. Open-Source is a "Marketing Program for Free-Software". You describe yourself as having the "free-software" world view (which I describe as an anti-developer property worldview).
> The terms get harder because open/closed suggests straightforward opposites that partition all the options.
2. Again, you are exactly correct. By erroneously choosing term that is generic, that was already in use, and that can't be trademarked, the OSI set itself up for a loosing battle as "the universal standard" for what is not "closed-source".
GENERIC/DESCRIPTIVE: "We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark “open source”; the mark is too descriptive. Ironically, we were partly a victim of our own success in bringing the “open source”
concept into the mainstream. So “Open Source” is not and cannot become a trademark.
> But I'd characterize licenses like BSL and the Fair Source License as 'generous proprietary licenses with public source availability', but not open-source.
As a person with a self-defined affiliation with free-software, it makes complete sense that you would see it this way, but how many people outside of the free-software group see that? The further someone is from self-affiliation with "free-software" surely the less likely they are to agree with this terminology.
> I have a feeling that the term 'open-source' is more likely to erode than 'free software', in the coming decades. We'll see, I guess.
I 100% agree with you. The OSI postulates a union between the interests of people who release software into the public domain, and the interests of people like yourself who believe in Free-Software.
In my view, there is nothing uniting these two groups and the fracture is 100% inevitable. Even if your preferred term `source-available` were to gain widespread acceptance/use, there is no reason for independent developers to subsidize big business by making their source free to use for those big businesses, unless the developers ideologically agree with the tenants of the free-software movement. However, if the developers agreed with the free-software movement, they would choose a GPL style license, not a MIT/BSD/Apache style public domain license.
I don't think anyone is arguing that BSL is capital O Open Source, and even the BSL licence stressses that it is not an Open Source licence. But both "closed source" and "source available" feel like poor descriptors for a project that is developed in the open and takes PRs from outside contributors.
Source available is proprietary. Decades ago, it was not unusual for proprietary Unix software to be distributed in source form, and installed by first compiling it on the target system. Merely distributing source is not and has never been the key difference between open-source and proprietary software.
I mostly agree. But I also think it is a jerk move to change the license like this after accepting many external contributions, even if it is legal due to CLAs.
At least they admit it isn't open source in the FAQ and are calling it the community version instead of the open source version.
Yeah, it's not binary. BSL is worse than open source, but it sucks way less than fully closed products. I'll at least consider using it.
My big gripe with the BSL is when companies switch from a proper open source license to the BSL, sometimes they try to sell it as a positive development, which is BS. The HashiCorp announcement is better than some in this regard, worse than others. Claiming it's the "evolution" of open source is weird spin, of course.
I also feel like any company switching from open source to BSL puts a stench of death / desperation on them, and it makes me worry for their future. If they have to make OSS -> BSL switch today, what's the next user hostile change going to be? Will they even survive?
As I explained in an earlier thread, MongoDB tried using AGPL. AGPL is not a barrier for Amazon, they still will resell your product without contributing. MongoDB ended up using a variant of AGPL that is even stricter (requiring the entire tech stack to be under the same license) but is no longer considered FOSS. Until the attitude changes around what FOSS is, this will keep happening.
If Amazon don't have a need to change anything in software, they'll just provide it as service without any problems. AGPL permits this.
If they have to change something, then they would likely want want to return hose changes in upstream to lower maintenance burden. Or just publish changes on github of upstream doesn't want to accept them. AGPL is fine with this too.
If Amazon would like create similar offering but with some secret sauce that they don't want to share, then they'll develop in-house solution from scratch and sell it as a service in AWS.
Um. Mongodb changed its license before AWS offered a mongodb compatible service. And since I can't get the source code for documentdb, either it isn't actually using a fork of mongodb, or Amazon isn't complying with the AGPL. I think the latter is pretty unlikely.
If AWS decides to copy your product, going closed-source or source-available just means they have to copy it from design docs or protocol specs. That's more friction than being able to reuse code outright, but it's not going to stop them.
AWS never offered MongoDB as a managed service, or used any of their server software when it was licensed under APLv3, or SSPLv1.
However, we have contributed patches to MongoDB even after their license change to improve its performance on Graviton processors. Because that's what's good for customers, and MongoDB is an important customer and partner.
AGPLv3 gives all the permissions needed to offer software as a manged service, just like every other FOSS license does. Unfortunately, in my personal opinion, the license has been co-opted by companies that do not care about Software Freedom, and rather hope that companies fear the license so they choose an alternative commercial agreement [1]. I don't think that's good for the community.
> Does Amazon have any policies against offering AGPv3 software as a service?
Each use of AGPLv3 licensed software has to be reviewed to ensure that the obligations of the license can be and will be met (and also screen for cases where it is known that the vendor of software does not prefer a company like Amazon import the software under a FOSS license). Today we use AGPLv3 licensed software internally, and include AGPLv3 licensed software in Amazon Linux (Ghostscript, in particular).
> Does Amazon contribute funding back to the software projects they offer as a service?
Yes, in varying ways. For example, it is not easy to provide "funding" for something like Apache Kafka. You need to have people working on the upstream.
> Does Amazon contribute code changes back to the software projects they modified when offering them as a service?
Yes, but not all changes are appropriate for upstream.
> But the (modified) source is available to consumers of the service either way, under the AGPL?
If Amazon made an AGPLv3 licensed program available to others over a network, it would have an obligation to provide to anyone that has access to that program the complete corresponding source.
Today, there aren't any services from Amazon that offer AGPLv3 licensed programs as a service. An example that may come to someone's mind is Grafana, but there is a partnership there, and AGPLv3 is not the binding license in that case.
In my personal opinion, AGPLv3 compliance is not difficult, so long as the licensor of the software is committed to community-oriented copyleft enforcement principles [1].
I think it would be awesome if Amazon could offer hosted AGPLv3 software, plus revenue share with the developers, code contributions to the original project and public forks containing non-upstreamable changes.
I heard there was a lawsuit about this, but can't find the outcome. Can someone please enlighten me how that story ended (if it had - but I think it should, it's been quite a while ago)?
Having it both ways is what I wish for them, as a user. I want their source, I want to be able to use it, I want them to sell it, and I don't want some copycat to undercut them.
Open-source isn't a gospel, it's a religion to some but not the end of the story in terms of what humanity can come up with. God(s?) didn't stop at "closed or open source". We can find alternatives while aiming for ideals.
All that it achieve is making sure noone can build a better product. Aka "yes our product is crap in a lot of places, but we don't want to fix it. Better extract licensing fees by locking you all with us".
The behaviour of dying companies. Which make sense. Their business model never worked.
They pretend some companys do not follow the ethics and principles of open source by not contributing but Hashicorp hasn't adopted those principles in the first place. If you make people sign a CLA before contributing, you are not really a good open source player in the first place.
> BSL provides a Change Date usually between one to four years in which the BSL license converts to a Change License that is open source, which can be GNU General Public License (GPL), GNU Affero General Public License (AGPL), Apache, etc.
So to me the most important question is what is the change license and how long does it take? If it's 1 year then it goes MPS 2.0: okay that's fine. But if it's much longer and more restrictive than it's a real about face and means the opensource version is really not workable as it's too far behind the head.
It is important to understand that there are two kinds of open-source software:
- Software made by startups that are precious to HN. In this case, building a business on top of them is "freeloading" and it's deeply immoral. Examples: Elastic, HashiCorp, Mongo
- "Public good software", there's nothing wrong with profiting from it, in fact, it's encouraged. Examples: Linux, Postgres, Nginx, Apache
Isn’t it though?
Nginx (org) allows companies like Kong (org) to exist?
I honestly think that’s a better relationship, kong basically advertises nginx (seems that nginx also talks about kong openly)… and yet both have enterprise services. They may not be in direct competition but they do have overlap. That’s what good competition looks like.
Or another way to look at it: software that volunteers can't/won't develop and thus will only exist if a company can sustain itself vs. software that volunteers can and will develop.
Open source software, by and large, is not maintained by volunteers, and I think the view of it is harmful to understanding how open source works.
The vast, vast, vast majority of open source software was created by engineers at for-profit companies where, through their line of work, they faced a problem, and after solving it had the insight "hey, other companies may have this problem". On the flip side, the vast majority of maintainers are engineers at for-profit companies who face new problems related to the software every day, and share their solutions back so we can all benefit from everyone else's work.
Its not the old fable of the greybeard in his basement tirelessly maintaining some internet-critical piece of software (though, those definitely exist). Its: "Hey, your business uses Kubernetes and derives millions in revenue either directly or indirectly from it? Mind helping keep it going?"
This is critical to understand because: Vault and Terraform could absolutely have been sustained and grown by the community of its users. There is zero doubt in my mind of this. List the top 50 websites by traffic volume, and every single one of those companies uses both of these products, extensively; many of the companies have engineers devoting effort toward projects like Linux, Kubernetes, Javascript, or Postgres. Vault and Terraform aren't even close to a situation of "but who maintains it"; Hashicorp just refused to let anyone have power in the project that wasn't on their payroll. Far more open source projects die due to this than a lack of interest in maintenance.
The root problem isn't profit motive; its venture capital. To some degree, it is also: projects created to solve the problems of their users before their creators actually have the same problem.
I think you make a solid distinction between two very different types of software, though I'm not sure I agree with your examples, specifically. If Linux didn't have the wide-spread usage and network of distributions that it currently does, there would be very little difference between it and Elastic, HC or Mongo. When it was originally gaining popularity, the general feeling of the technology world was that it was crazy to give away an operating system.
The "Public good software" you refer to is much better represented by things like Capital One's Cloud Custodian, or the massive number of software libraries in NPM, PYPI, and all over GitHub.
> Software made by startups that are precious to HN. In this case, building a business on top of them is "freeloading" and it's deeply immoral. Examples: Elastic, HashiCorp, Mongo
I don't believe it's nearly as cut and dry as this post claims. The companies who are "freeloading" are usually undertaking massive efforts to be able to run the software in a very different environment than it was originally designed for. Building a hosting solution like AWS, with the high availability solutions they offer, is an incredibly complex problem, and they're adding significant value on top of the original software. Without solutions like DocumentDB and OpenSearch, many companies would not be able to build the solutions that they have built with AWS. Additionally, if we take this stance, are these companies not "freeloading" on the open source contributors' efforts?
One could argue that cloud providers' contributions to upstream could be more significant, but how much of what AWS has developed would be useful to anyone who isn't running at their scale, and using the same solutions for the physical layer?
I see two real problems, here:
* A lack of foresight on the part of the companies who originally built their businesses based on software with overly permissive license (Elastic is probably a good example, as they decided to pivot to SaaS _after_ they built a company on the premise of open source software). If they wanted to control other peoples' use of the software to the extend that they are complaining about now, they should not have chosen MIT/MPL/BSD/Apache licenses.
* Changes in leadership which result in a major change in business model which is no-longer in line with the original goals of the companies (I believe HC probably falls in with this bunch). In this case, the new leadership has effectively "bought" something without doing their due diligence. They thought they had all of the keys to the kingdom, but they didn't understand that what they were buying.
In either case, it's not the fault of those who saw an opportunity to build on the work of others. The moral of the story is: don't give away your core intellectual property if your business model depends on monetizing it.
I always thought that OSS was supposed to be a loss-leader. By being the author you have more credibility for offering services. Sure someone else can do it, but are they really gonna know how to offer support in some rare crazy edge case that is blowing up production right now?
They made $102M of revenue from support in the latest quarter. Their cost for providing the support was $15M, and their entire R&D costs were $54M. (Professional services was a tiny amount of revenue in comparison, and at break-even.)
Clearly support and services could easily generate enough revenue to sustain development. What it can't currently sustain is their $91M / quarter of sales and marketing.
This one is interesting to me. I've been a big fan of Hashicorp ever since the only thing they had was Vagrant over a decade ago. The core of my usage has remained all of the CLI tooling, i.e. Packer, Terraform. It's more or less impossible to create any kind of competitors by trying to steal from these as they're free to begin with, plus they provide virtually no value on their own and rely on a universe of a providers and plugins to actually do anything, some of which are created by Hashicorp, but many of which are not. One of the more extensive foolaround tools I ever made was vaguely inspired by Packer, years ago when there wasn't a plugin to support Hyper-V and I wanted automate creating machine images for my Windows laptop to run various flavors of Linux so I could work on Linux from Scratch over and over without having to copy/paste everything at the command line. It was only "architecturally" inspired, though. I didn't even look at their source code and wrote everything from scratch entirely in Powershell since it was only for personal use and only intended to run on Windows.
I guess the signal here is they care more about and have pivoted business-wise to their own hosted offerings. I admit I'm not entirely sure what those are. I don't anyone that uses Terraform Cloud, but I guess someone must. So I guess Consul, Nomad, and Vault, but again, does anyone use the hosted versions of these? The big sell to me has always been all of their products can be self-hosted. Professionally, my use has mostly been with defense and intelligence customers offering behind an air gap who couldn't use the cloud offerings if they wanted to.
By far the biggest value add has always seemed to be Vault. Consul and Nomad have very clear competitors that still command more mindspace, but Vault seems to reign supreme if you want to self-host a secrets manager. On this front, though, as great of a product as it is, how much of that is even due to Hashicorp itself? The security is provided by implementations of open encryption algorithms, Shamir secret sharing, fips modules in the OS, and HSM support, but they don't make the HSMs. HA is provided by the Raft implementation of the Paxos family of consensus voting, but again, they didn't invent that. The fact this product exists at all is because they stood on the shoulders of giants who did all the heavy lifting in creating these secure and robust algorithms in the first place, and then shared them and allowed others to build commercial offerings on top of them. Your entire company exists because of other people's open source efforts, and then you close off and say no one else can build on top of your work, when if the OGs had done that, your product would never have been a viable business.
Moving away from the easy-to-predict flat rate Team pricing and to a new model based on number of managed resources ($0.000004 per resource per month or something like that) was just wacky…
… and now this “you can’t make money from the software you helped write” BS.
I don't know if I've ever seen so many useful Open Source software products go proprietary at once; Vault, Consul, Terraform are all useful parts of many people's stacks, that they chose specifically because of their licence.
Hopefully they all get forked (or existing forks take off), and it is just a matter of the community converging on the winner that we all use in the future.
Not possible, at least for vault and terraform
The way the architecture works, any fork would have an impossible task to take off and maintain compatibility
All this implies is that Hashicorp is no longer an open source company. Many of Hashicorp's actions like this one run completely against the nature of open source software. Another example is `Hashicorp Vault Secrets` - which they just launched as a closed-source SaaS only tool.
I'm obviously very biased, but take a look at Infisical as an open source alternative to Vault: https://github.com/Infisical/infisical (we run under MIT + some enterprise features).
> Why is HashiCorp making this change?
>
> We strongly believe in the value of openly sharing source code and enabling practitioners to solve their problems, building communities, and creating transparency. HashiCorp provides feature-rich products to the community for free, and that development is made possible by our commercial customers who partner with us. By shifting to this license, HashiCorp can better manage commercial uses of our source code and continue to invest in our thriving community of practitioners, many of whom are contributors, in a manner that will not impede their work.
i strongly appreciate the FAQ but this part felt weak/not the whole truth. What is not being said? who is hashicorp afraid of? there wasnt a doubt in my mind before and now there is.
indeed i just saw a startup demo today show off a feature that they admitted was just Vault in a wrapper (they even called their thing Vault haha) and that was it, but i would not have thought Hashicorp would mind them at all (its a very new startup)
> Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license. Commercial licensing terms are available and can enable use cases beyond the BSL limitations.
Looks to me very similar to (A)GPL + commercial dual licensing, for instance.
GPL permits this: "Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge"
because there's a contention between the people developing the software and the startup community.
it's obvious that for a company (money-making entity), that they're going to want to have a monopoly in providing the software aaS. That's the monetization strategy on otherwise free software.
I don't think this is surprising. We saw this years ago with AWS and MongoDB. Yes, a startup can offer Vault cheaper since they don't have to pay for developers to build the software, and, in fact, they get to offshore their support costs to the developing company too ("yay" OSS).
I don't like it, but for a corporation that is trying to develop OSS, it makes perfect sense.
SaaS itself is against the spirit of open source, if not the letter of the license. It is the most closed model of providing software, far more closed than closed source binaries. Whether it runs on open source behind the scenes doesn’t matter; your data is controlled by the provider and you have no privacy or ability to run anything on your own terms.
At the very least anyone using open source to run SaaS for profit should be giving something back to the authors of the software. That’s the least they can do given the user hostility of the model as typically implemented.
Open source is stuck in the 90s and has failed to respond to the rise of SaaS or “the new closed.” The big mechanism of restricting freedom now is closed execution, ownership of the network effect, and closed data not closed source. Google could open every bit of their source and nothing would be gained freedom-wise.
SaaS is not software; SaaS is a service. The spirit of free software is giving software away as a gift and a tool for people to use to do whatever they like with it, business included.
Running a service based on free software is absolutely within the spirit of free software. Free software isn't about a circle of gifts, it's about software freedoms. You're not obligated in spirit to "give something back" because you use free software.
Yes it's ok to use OSS to operate your business. That's a sound and intended way of using OSS. Everyone benefits.
No it's not ok to provide a competing product to the very people that you get the core of it from. That's literally stealing if not fraud. At least it is ethically dubious.
I'm not saying it's literally a yes/no decision, but this is the baseline.
I think OSS projects should offer a paid for "integration license" by default.
Hashicorp wouldn’t be in the position they are without being open source in the beginning.
Think about all the reduction in sales cost their open source model resulted in. Because they were open source, they had a foot in the door and in-built evangelism.
Once that stopped being an advantage and they had utilized all the community goodwill by being open source, they make this change.
> indeed i just saw a startup demo today show off a feature that they admitted was just Vault in a wrapper (they even called their thing Vault haha) and that was it, but i would not have thought Hashicorp would mind them at all (its a very new startup)
What about all the cloud providers with their own Vault offering, which is likely just Hashicorp's FOSS Vault with lipstick and other bells/whistles?
People are paying good money for Secrets Management, and probably not to HashiCorp (directly or indirectly). If your cloud provider offers a turn-key solution and it's priced right, why would you bother with an external 3rd party?
HashiCorp recently rolled out a "Free Tier" to their HCP service[1]. They're clearly trying to get more people to use their first-party services.
> On a specified Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License. Our current Change License for HashiCorp projects is MPL 2.0.
I wonder if whatever MPL 2.0-licensed contributions were made less than 4 years ago.
They didn't take contributions under the MPL. They required their CLA too, giving them the rights to do this.
Contributors should consider it as a red flag when a project isn't willing to accept inbound contributions under the same terms as they grant to others.
759 comments
[ 2.5 ms ] story [ 496 ms ] thread> HashiCorp considers a competitive offering to be a product or service provided to users or customers outside of your organization that has significant overlap with the capabilities of HashiCorp’s commercial products or services.
So, consider there is no cost estimate service and you built a thing that got popular (https://github.com/infracost/infracost). Then after 2 years Terraform Cloud catches up. What happens? Are you out of business?
"Then after 2 years Terraform Cloud catches up" Really good point, company scopes change.
Yeah. It seems like the Apache/MIT route has been working “well” to support a suite of libraries. But for bigger “business-critical” full-on products, like databases etc, you see much more weird contortions, including making self-hosting difficult and feature-gating essentials. Better than closed source, but not ideal. I’ve been thinking for a while that licensing is likely the pragmatic way out. But it’s important that it’s broadly understood, fair and clear.
> […] a product or service provided to users or customers outside of your organization that has significant overlap
Ouch, judging by the language it seems like it’s (1) unclear and (2) the authority on that ambiguity leans in favor of the company, which paves the way for selective enforcement. “Don’t worry, we aren’t going to come after anyone” is not convincing when legal documents are being signed. Hoarding soft- or future powers is a huge red flag in contracts, imo.
What do others think about this license in particular?
As much as I love open-souce, I get the point that there are a bunch of freeloaders using stuff and not contributing back.
I could maybe understand this for Consul or Vault, since those are actual hostable services that could probably be resold - but I don't know of anyone reselling those, either.
I always just stuck to vanilla Terraform but recall coming across them at some point.
Dozens of them out there I wonder with great interest which one of these got hashicorp worries about their wallet enough to make this move. Could it be env0 raising 42M earlier this year?
In other words, free as in freedom, but not free as in beer.
It's totally understandable to not want companies to profit off of proprietary, closed-source forks of your software. I get it! But there are licenses that you can use to stop that from ever happening (namely [A]GPL). Why not use one of those?
Copyleft is politically scary to some people, so they refuse to acknowledge it other than to call people zealots. Explicit licenses protect you. Open source spirits don't. Everyone should be honest: the only reason a lot of people prefer open source is because they want to preserve a rug-pull option. Then they get surprised with it's Amazon pulling the rug on them.
Indeed, copyleft can be politically scary. Especially when for-profit companies co-opt copyleft to drive licensing revenue by selling alternative license arrangements [1]. If all those who adopt copyleft licenses pledged to commitment to community-oriented GPL enforcement principles [2] I think that it would be a lot less scary. Unfortunately we've seen "copyleft trolls" that try to wield copyleft as a weapon, either for profit or to make other demands that are not helpful to the community.
Copyleft licenses are, indeed, protective licenses from my perspective. Or, they should be.
An aside, when it comes to "Amazon pulling the rug" -- what exact incident are you referring to?
[1] https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
[2] https://sfconservancy.org/copyleft-compliance/principles.htm...
IMHO not everything needs to be open-source, but in many case it just makes so much sense that is a dumb idea to reinvent the wheel.
Many projects are succesfull this way. One I can think of is LLVM.
Because projects believ(ed) that the good will of their users would be enough to sustain their projects and businesses.
Now that certain projects see that good will isn't working, they're switching to the legal system.
Projects are free to choose permissive licenses like BSD.
Companies are then free to use the code however they like and not contribute back in any way.
Projects are then free to be annoyed by this because they hoped that companies would contribute time and/or resouces out their own good will.
Finally, projects are free to move to "business source" licenses because good will didn't work, so they need to utilize the legal system to ensure that large companies help sustain the project.
What part of this do you disagree with?
Projects choosing a permissive license like BSD is utilizing the legal system. BSD is a contract, a copyright license. It imposes restrictions/limitations/obligations, which can/would be enforced by a court.
I said:
> so they need to utilize the legal system to ensure that large companies help sustain the project.
No shit they were using the legal system before with the BSD license. I am saying that they are now using the legal system to ensure companies contribute, which is not something the BSD license did.
Wait not like that.
Have you ever set lenient guidelines, people took advantage of them in a way you didn't like, so you were forced to tighten your guidelines in a way you didn't originally want to?
eg: a professor establishes a generous late homework policy, which most students use reasonably, except a few who decide to turn in everthing on the last day of the term and make the TA's lives hell. Prof is allowed to be disappointed and then adjust their future terms' policies to be more specific (eg "submit assignments max 5 days late").
As far as I can tell, you are allowed to fork HashiCorp's code up until the point of license change, and continue to use it as you like, rebrand it as a new project, whatever. I could be wrong, but I don't think HashiCorp ever said "we will never ever change our license."
That's the Free Software slogan, not open source. The only relationship between the two is that open source can easily be relicensed into Free Software (or proprietary, or whatever.)
There's nothing in open source about friendliness or collaborative development. I'm not forced to take your advice or contributions just because I'm open source, so how could that have anything to do with it?
Opinions like that are the reason why more and more companies are walking away from the great attempt of building stuff collaboratively.
> There's nothing in open source about friendliness or collaborative development.
Your view of the meanings of "free" and "open source" software is very literal and narrow. I'm not trying to debate the technical definitions of those terms, because frankly, I don't care and I don't think they matter in this discussion.
The crux of what I am saying is this:
A company may choose to share their source code for others to benefit from, under the hope that large players will contribute back in some way rather than use the situation to the disadvantage of the upstream company.
In other words, they might hope to:
* Let hobbyists learn from and use their code for free.
* Let competing companies use their code, as long as they contribute something back (money, bugfixes, festures, community support, QA).
* Make their employees happy.
and they may not hope to:
* Empower other large companies to freeload--ie, profit without contributing back at all.
Yes, I understand that permissive open source licenses allow freeloading in a legal sense. That does not mean the upstream companies have to be happy about it, much in the same way that you're allowed to use your office's shared kitchen to microwave fish, but your colleagues do not have to be happy about it.
What about this is so hard to understand?
While you are correct that the Free Software Movement has slogans like "free as in freedom" and has a definition based on "the four freedoms," the Open Source Movement also recognizes and advocates for "Software Freedom" as well.
"We build a world where the freedoms and opportunities of Open Source software can be enjoyed by all." [1]
Software that is licensed under Apache 2.0, MIT, BSD, or any of the other so-called "permissive" licenses is labeled "Free Software" by the Free Software Movement as-is. It does not require a "relicense" to become Free Software.
Said another way: you don't have to use a copyleft license like the GPL to qualify for the "Free Software" label.
It is just a different name for the same thing, because there was a group that developed a vocabulary before another group existed.
[1] https://opensource.org/
This behavior is antisocial, and completely destroys the offering/concept for everyone.
I have a bootstrapped software company with an open-core product. Meanwhile, a VC-backed startup that has raised over $100m of funding decided to use one of my core open source libraries (which they haven't contributed to in any way) for a critical component of their commercial product, which also overlaps with my product's functionality in some ways.
In response, I eventually made the difficult decision to archive that library's repo and moved its functionality into my main product in a way that prevented external use. So then this startup created a hostile fork of my library, and started to implement functionality that is only present in my own commercial product.
After that, I had to waste several months of unpaid time just to make their fork of my own library no longer easily compatible with recent versions of my own product. Some time later, finally the startup decided to abandon use of my library altogether and wrote their own similar library (which was undoubtedly much easier for them, being able to see all the edge cases my library already handled).
My lesson from all this: I will never create another new large open source product ever again. Too many sociopaths out there for the system to work at all. If I ever decide to make something source-available, I will consider BSL.
And before someone says "why not AGPL?", it is because many companies don't touch AGPL software with a ten-foot pole. My sense is that adopting AGPL for a brand new product typically causes the product to be dead on arrival. That said, I would honestly love to be wrong here.
If there are a lot of AGPL open core / commercial FOSS companies that have been successful, please share examples, I say this genuinely and without snark.
I agree fully with your *GPL point of view and have seen that in practice many time.
It is in the written guidance for open-source in the company I work for, along the lines “for GPL-like licenses, that’s a ‘no’ by default, unless you follow this very complicated process to get approvals from many people”.
Meanwhile I put some of the core logic (database schema introspection and diff'ing) in a separate library and repo, since it could be re-used for other applications in case my original product didn't get traction.
Fast forward many years, and the product has been fairly successful. The open source edition of the product has been used by many hundreds of companies and has been downloaded 1.2 million times. And in terms of the paradigm shift, the push/pull schema change semantics that I invented have been copied by several much larger projects, such as Prisma.
The separate library was used by a few companies too (e.g. by Canonical for one notable case), but mostly for internal use-cases, not things that directly competed with my product. I think most folks had enough moral fiber or common sense to understand that using the library in a competitive way would result in the library being killed off. What other choice did I have? I wasn't going to let my business be killed by a hostile fork of my own library.
Books are rivalrous and excludable goods. If you take all the books, then others can't enjoy them. Open source software is non-rivalrous and (mostly) non-excludable. This is the thing that makes free software possible. And it's also the thing that makes it unlike the book example.
> decided to use one of my core open source libraries (which they haven't contributed to in any way) for a critical component of their commercial product, which also overlaps with my product's functionality in some ways.
This is really terrible, and I'm sorry to hear that it happened to you. But as far as I'm aware this has always been the whole point of "permissive" licenses. Licenses like MIT and (Berkeley) BSD subsidize the private sector with work done by the universities. The core idea, at least compared to GPL licenses, is to allow businesses to profit off of donated work. So while I sympathize with you, it seems like you deliberately chose a license that allowed and encouraged exactly the behavior you saw.
> And before someone says "why not AGPL?", it is because many companies don't touch AGPL software with a ten-foot pole.
This is presumably because businesses don't want to use software that creates in them obligations to give back. But you do want them to give back, or at least you don't want them to take too much. So I feel like there's a fundamental tension here. You're trying to make your project appealing to businesses by telling them they can take it for free and give nothing back. But you're also saying that behavior is "antisocial" and "completely destroys the offering/concept for everyone."
Sure, and if your company takes a bootstrapped commercial open source product that it didn't develop or contribute to, and then pays several employees a salary to do things which actively reduce that product's ability to develop a sustainable revenue stream, then you definitely risk permanently destroying that open source product.
On a macro level, if many companies do this, the entire ecosystem of open source begins to falter. Hence all the moves to BSL, SSPL, Commons Clause, etc.
I was making an analogy to that. If some people keep taking all the books and selling them, the system falls apart, and people stop putting free books in the box.
> it seems like you deliberately chose a license that allowed and encouraged exactly the behavior you saw.
"Allowed", yes. But nothing in the license I chose (Apache License v2) actively "encourages" the behavior of using a project in a way that actively destroys the project. (Nor does it discourage it either.)
> You're trying to make your project appealing to businesses by telling them they can take it for free and give nothing back. But you're also saying that behavior is "antisocial" and "completely destroys the offering/concept for everyone."
I have no problems with businesses using a project for free and giving nothing back, on its own. I do have a problem with businesses taking a project, and profiting off it while also directly competing with it and/or forking the project in a way that directly kneecaps the project's revenue stream. That is what I am calling antisocial and destructive.
> My sense is that adopting AGPL for a brand new product typically causes the product to be dead on arrival.
It may hinder adoption (in the corporate world) but not contribution to the source. And if you want to promote the spirit of opensource and make money too, dual licensing with xGPL is the best way to go. MySQL is a successful example of this licensing and business model.
Just because dual-licensing has been successful in a very limited number of exceptional situations, does not mean that it is a reproducible path towards building a sustainable software business.
Also keep in mind:
* MySQL hasn't been an independent business for over 15 years. AFAIK there is no public information on its revenue or profitability.
* Much of Oracle's recent work on the product has been on MySQL Heatwave, which is only available as a managed service.
* Most MySQL Community Edition commits come from Oracle.
* Meanwhile the company behind MariaDB, arguably a more "open" fork of MySQL, is having financial problems and may well end up having its stock de-listed soon.
* The non-open-source Business Source License was originally created by MariaDB for their MaxScale product. The license's existence is fully backed by Monty Widenius, original creator of MySQL.
To be clear, I'm not saying any of the above to criticize Oracle or MariaDB. Rather, just pointing out that a general statement of "dual licensing with xGPL is the best way to go" is not really backed by the facts on the ground.
I must ask, do you run a commercial open source business yourself?
- MariaDB: https://mariadb.com/products/community-server/
- Percona Server for MySQL: https://www.percona.com/software/mysql-database/percona-serv...
Other additional examples of successfully commercialised xGPL products with different business models:
- Red Hat Linux: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
- QT: https://www.qt.io/licensing/
- Ghostscript: https://www.ghostscript.com/licensing/index.html
- WordPress: https://wordpress.com/ (based on https://wordpress.org/ )
- Buskill (hardware): https://www.buskill.in/
- Moodle: https://moodle.com/ (based on https://moodle.org/)
- ProtonMail: https://proton.me/mail (based on https://github.com/ProtonMail )
- Tutanota: https://tutanota.com/ (based on https://github.com/tutao/tutanota/ )
- Dada Mail: https://www.dadamailproject.com/
- Dietlibc: https://www.fefe.de/dietlibc/
The commercial success of a product totally depends on the business model you come up with, whatever be its opensource (or not) license.
Corporates have a vested interest in promoting the propaganda that only a non-xGPL opensource license can be commercialised successfully simply because they cannot freely steal the source code of a competing xGPL licensed software.
The real value of an FSF license, like the AGPL, is that it is designed to protect the copyright holders, and its users, "right to repair". And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license (even if future versions are closed source, the old version under xGPL remain opensource perpetually). Other open source license (that are less stringent) are prioritised to increase developer contribution. Source code under such license can thus be closed-source even from the original copyright holder.
But again, commercial success totally depends on the business model you come up with, irrespective of your license. The right license and the right business model will empower each other. Or cripple your business.
17 USC Sec. 203 suggests that may not be strictly true in the US.
https://www.law.cornell.edu/uscode/text/17/203
"Successful exit" is not the same thing as a sustainable product or business model. I mentioned several key concerns in my previous reply, which you didn't address here at all. Specifically, if dual-licensed GPL was the best way to go, it wouldn't be the case that entities outside of MySQL/Oracle (e.g. AWS) were capturing a huge amount of MySQL's value/revenue, possibly exceeding that of the product's own revenue. Why else would development be shifted to the managed-service-only, closed-source MySQL Heatwave product?
> MariaDB and Percona Server are good examples of competing businesses
Yes, I'm very familiar with the MySQL ecosystem (click my profile). I mentioned several concerns specifically about MariaDB in my previous reply and you did not address those at all.
You also didn't answer my question about whether you've ever run a commercial open source business, so I must conclude that you haven't. I do, and frankly I don't appreciate when other people -- who seemingly don't havie direct personal experience in this area -- attempt to confidently lecture me about how I supposedly chose the wrong license.
Listing Red Hat in your reply also seems a bit ridiculous, given all the latest contention in that space over Red Hat threatening to cancel customer subscriptions if they republish RHEL's sources. If GPL-based software was the panacea you claim, things like this wouldn't be happening with ever-increasing frequency over the past couple years.
And do you realise that you are comparing corporates with two completely different philosophies and business model? It's absolutely in character for Oracle to use the loophole in the older GPL (that has since been fixed by the AGPL) to try to make MySQL closed-source again by offering it through a SaaS infrastructure. Oracle has never been a champion of the opensource movement, while the original owners of MySQL were. It is the same with IBM, who are now the owners of Red Hat Linux. And that shows in how they ran / run their business.
We are discussing about opensource software business models only. Not open-source and closed-source ones (it should be a no-brainer that closed-source software business models are the most successful and profitable ones).
> I mentioned several concerns specifically about MariaDB in my previous reply and you did not address those at all.
Simply because it is irrelevant to our discussion. The success or failures of MySQL or MariaDB or Oracle's MySQL was/is not just solely because of its license and there are many other factors behind it (for example, MariaDB earned a lot of scorn from open source developers because they felt betrayed after its original source - MySQL - ended up in Oracle's hand). Nevertheless, MySQL is a great example of a commercially successful example of a dual-licensed GPL product.
I have enough business experience, and a good understanding of open source software to understand its strength and limitation in a commercial setting. Honestly, you do need a lecture for not being able to see the obvious:
1. As per your own confessions, a competitor was able to use your open source code without sharing subsequent work on the codebase. This would obviously have never happened with the AGPL license, as the license compels others who distribute the software (even as SaaS) to share the source code.
2. You tried to change the codebase and / or license to make it more difficult for them to fork your code and use it. This shows your own confusion regarding the open source philosophy and your business model. Your code was used by others in the spirit of the open source license you chose. And yet, you continue to assert you are the wronged party?
3. It is also easy to see that you (wrongly) chose a permissive opensource license out of self-interest to your business (hoping to attract more developer contributions and then close source the product later when it becomes profitable, just as your competitor did) than out of an equal commitment to the open source philosophy. Your competitor outwitted you because you weren't knowledgable about licenses, your own business goals and business model.
You are making a ton of reading comprehension errors, as well as completely incorrect assumptions about the situation I described. And then lecturing me about those incorrect assumptions. Cool cool.
> a competitor was able to use your open source code without sharing subsequent work on the codebase.
No, that's not what I said at all. I described how a company used one of my open source libraries in a way which directly competed with my primary product. The problem here is they did share their changes, and those changes included functionality which was already present only in the enhanced paid closed source edition of my product.
This is why I said it was a "hostile fork" of my library: users could combine the open source edition of my product with the hostile fork of my library to get functionality for free that normally is only in my paid product.
I absolutely understood that this situation was possible with a permissive license. I just did not expect a company to do this so soon after my paid product launched, especially as the product wasn't even financially successful yet by that time.
> This would obviously have never happened with the AGPL license
I can say with absolute certainty, if my product had an AGPL license, it would not have succeeded in any form. Many of my largest users do not adopt AGPL software under any circumstances.
> You tried to change the codebase and / or license to make it more difficult for them to fork your code and use it.
The former, not the latter. I never tried to change the license, nor said anything about that here. I changed the codebase so that the previously-external library was now an internal package instead of a standalone repo, and refactored things to prevent compatibility with the hostile fork.
> Your code was used by others in the spirit of the open source license you chose. And yet, you continue to assert you are the wronged party?
My code was used in a way which negatively impacted the revenue stream which would pay for further development of that code. As I've said elsewhere in this subthread at https://news.ycombinator.com/item?id=37084057, the license is entirely neutral about that topic: it neither encourages nor discourages such use. However, I assert that common sense should typically discourage people from such antisocial behavior, because you can reasonably expect that kneecapping the revenue stream for a project can result in that project either getting killed off or radically changing shape in response.
> you (wrongly) chose a permissive opensource license out of self-interest to your business (hoping to attract more developer contributions
I never said anything about "hoping to attract more developer contributions" and that has never been my motivation for open sourcing this work. I described why I chose an open source license directly in a sibling subthread here: https://news.ycombinator.com/item?id=37083698
> and then close source the product later when it becomes profitable, just as your competitor did
You're just completely inventing false details here out of thin air!
My product has two editions, a FOSS one and an enhanced paid one; the latter is closed-source. Both editions already existed at the time of the events I'm describing here. Both are still actively developed and supported, and today they're widely used by companies you are definitely familiar with.
The library in question was one component of this product, not the product itself.
Meanwhile the startup that made the hostile fork of the library runs a managed service (SaaS).
> Your competitor outwitted you because you weren't knowledgable about licenses, your own business goals and business model.
I guess i...
Full disclosure, I'm a shitty open source contributor, but I have some projects on github that I know others have gotten use from, and that makes me happy, not concerned someone is "freeloading".
There are many motivations such as mindshare, not reinventing the wheel and creating standards that motivate people and companies to contribute to open-source. Ripping-off other’s work - even when legally ok - is not right.
The system is designed to foster collaboration and not to enable shitty business models.
You're describing a thing that happens here, and not even bothering to make an ethical argument against it. People are just supposed to accept the premise, and go on to discuss the implications of it.
> The system is designed to foster collaboration and not to enable shitty business models.
"Spirit of open source" people are arguing that the system wasn't designed at all. You're arguing that open source licenses themselves have little or nothing to do with open source licensing. Instead, it has something vaguely to do with freedom and friendly and collaborative and other nice words. You don't have to be friendly or collaborative to produce either open source or Free Software.
Ideally your moneymaker can compete on its own without being dependent upon gatekeeping how the open source part is used. But with project ownership means you can change the rules for your competitors, but it's also a sign that you fear your offering is not competitive enough without the rule change.
It’s a shame it didn’t work out for them due to bad actors.
The trend I see is for the next generation of good open-source great ideas to be much more protective around their intellectual property. Such a loss, again, due to bad actors.
Similar point here. Hashicorp have very good products that are open source as a way to foster collaboration. Freeloaders rebrand it and re-sell with no added value, so Hashicorp are forced to close it (or more like put a timer) to protect their investment.
As I said, I'm a big fan of open-source, and have been working on it for a long time, but am growing more and more frustrated with the current state of things, so much so, that it makes a lot of sense to me that companies that start with great collaboration spirit are forced to tighten their sources due to bad actors in the system.
Agreed. It can't mean anything other than that you can't compete on a fair playing field, so you have to add restrictions to lock customers into your service. That you wrote the service is irrelevant since you licensed it as a gift to the world. It's exactly what Free Software was designed to thwart, and exactly what open source was designed to preserve.
Freeloaders like HashiCorp using other people's compilers and libraries?
Hashicorp were probably not packaging a compiler+libraries and selling it and didn’t have a business model around compilers.
Have you ever looked at the number of unreviewed PRs on Hashicorp projects?
No it doesn't. There's nothing stopping them delegating that task to community members apart from the desire to retain corporate control.
On the other hand, many contributions(PRs) that hashicorp got (for free) are now relicensed to a different license. Who's actually the freeloader here?
I think we've seen time and time again large enterprises abusing the spirit of open source for their own monetary gain, contributing nothing back, and just acting in bad faith.
License technicalities don't matter. If people use permissive licenses as an excuse to justify an ecosystem that is parasitic any such system will die out, it cannot sustain itself.
If that's what you think open source is, it'll vanish. No commercial system can exist like that and it should not because it effectively means distributing resources from people who do everything to people who do nothing.
If they strip all attribution, then you can just take them to court for violating the license; other than public domain and WTFPL, even the most permissive licenses (BSD/MIT/Apache) still require attribution.
Free software has been fine without any businessmen or companies involved, we don't need your or any company's approval. It seems like the only thing that will vanish from the open source sphere are companies with flawed business plans.
Back in the real world, with people in it, the GPL and (by extension) Open Source were created for underlying reasons.
Building a business off the open source model and community good-will before realising it doesn't work is either incompetence or dishonesty.
> If that's what you think open source is, it'll vanish. No commercial system can exist like that and it should not because it effectively means distributing resources from people who do everything to people who do nothing.
This is a weirdly hyper-capitalist take. You're saying that the successful businesses built off open source "should not" exist?
One should always read software licenses before installing a dependency, regardless of how a particular project is marketed. This would still be necessary even if companies weren’t using the term “open source” to refer to this type of license.
People make it sound like companies are out to confuse you by calling it “open source”. If you’re the kind of developer that blindly uses a piece of software because someone claimed it was open source without doing due diligence on how it can be legally used, then you deserve whatever consequences may arise.
That is exactly what people who call non-OSI-approved licenses “Open Source” are doing.
However, I agree, one should also read the license and those of the entire dependency tree.
They were the Bazaar people. They sold open source as something that makes software quality better. It was the counterpoint to Free Software, who said they made programs morally better, and that it was largely irrelevant whether copyleft made software quality better.
I mentioned the cases I have seen the word abuse used as a counter point to 'If somebody doesn't want any competitors' which is not something I have seen brought up when taking about abusing the spirit of open source.
I was not taking about what the licenses legally bind you to do.
For many, the spirit of open source is to allow it to be used in any way, commercially or otherwise. I don't consider it acting in bad faith at all to use what's out there and made available, and I am happy to give things away as in beer. Otherwise it's not open source (which is also fine, not all software has to be open source).
To abuse the spirit of open source, make arbitrary rules about its use.
The main way I think about this and how I often see people act are that actions which undermine the long term success and sustainability open source community is abusive. So you take a behavior and say if a non-trivial number of people emulated/copied this behavior will the open source community survive long term, if the answer is no, then the behavior is abusive.
Of course people disagree with what will lead to long term sustainability of open source projects and communities, though it does seems like a reasonable heuristic to the first degree of approximation.
It's a spectrum IMHO from closed-source to "do whatever you want" source.
Well, by definition they wouldn't be open source projects then. But yes, better to make that clear from the start.
To imply that a non-open-source license like the BUSL is part of such an evolution of "open source" models (commercial or otherwise) betrays either severe confusion or a deliberate attempt to mislead.
Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
Just because nobody has tried yet doesn’t mean that it won’t ever happen. Companies are doing this precisely because companies like Amazon abuse FOSS licenses to stand up their own hosted versions of open source projects.
That nobody has tried suggests paranoia at best.
> Companies are doing this precisely because companies like Amazon abuse FOSS licenses to stand up their own hosted versions of open source projects.
The AGPL exists and already fully addresses that.
That's hardly paranoia. Why wait until you need to change it under pressure from one of the big CSPs (a la Elastic/AWS)? It is proactive at best.
Put simply: Hashicorp's target market for a given product is largely not going to be interested in a cloud provider's locked-down equivalent, and a cloud provider is not going to be interested in deprecating its own tightly-integrated product in favor of customizing some third-party offering.
And again: if this was a legitimate fear, then the AGPL already fully addresses it.
The cloud vendor issue is license agnostic. ElasticSearch comes to mind. For the AGPL side, MongoDB and Neo4J come to mind.
Recall that AGPL came into play by way of a hole in the GPL terms, the one where you can modify a GPL codebase but you don't have to say anything unless you publish it. GPL was weak in therms of the definition of "publish". AGPL closed that hole.
But, that hole only becomes toxic the moment you modify the code or plug proprietary stuff into it. Cloud vendors don't do that.
Because it doesn't need to, nor should it. That's only a competition issue if the upstream developer is actually offering a managed version themselves - and in that case they already have "we actually developed this software so we're the best option for supporting it in The Cloud™" as a selling point that even the likes of Amazon and Google cannot replicate (not without themselves participating in the actual development of the software in question). They should lean into that selling point and offer a better managed offering than what any cloud vendor could ever hope to offer.
Plus, as I've mentioned in sibling comments, large cloud vendors probably don't have much interest in reselling Hashicorp's products anyway. Why resell Terraform when you're trying to lock customers into CloudFormation? Why resell Vault when you're trying to lock customers into Secrets Manager? Why resell any of Hashicorp's products when the thing for which they're marketed - avoiding vendor lock-in - is literally antithetical to your business model of maximizing vendor lock-in?
> But, that hole only becomes toxic the moment you modify the code or plug proprietary stuff into it. Cloud vendors don't do that.
Sure they do. If they didn't modify their managed versions of FOSS applications to integrate tightly with the rest of their offerings, then why would anyone bother to use the cloud-vendor-managed versions in the first place? If there's no benefit integration-wise relative to just slapping the vanilla version on some EC2 instance or EKS container or whatever, then what's the point?
This is not an abuse of FOSS licenses. If developers have a problem with this, there are open source licenses that would make this use case less attractive for Amazon, like the AGPL.
sounds like it's doing its intended job well then?
Spacelift is a significantly better product than Terraform Cloud, and since they apparently can't compete on quality they're going with this instead.
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U....
> Pulumi is able to adapt any Terraform Provider for use with Pulumi, enabling management of any infrastructure supported by the Terraform Providers ecosystem using Pulumi programs.
Pulumi made Hashicorp build Terraform CDK. Which is a great result.
And the only reason Hashicorp was able to build CDK quickly is because they built it on top of Amazon's open source Amazon CDK. Another competitor.
Also Terraform now directly integrates with CDK. So apparently Hashicorp felt the heat .
Looks like competition to me.
If Pulumi - another open-source infra-as-code tool (that ain't even a fork of any Hashicorp product AFAICT) - is really the thing scaring Hashicorp away from open source, then that doesn't really do Hashicorp any favors here.
If it's so simple, Pulumi could have done this themselves. Why didn't they? Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
Because that would be a waste of time unless there's some specific case where an existing provider is insufficient.
> Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
Pulumi itself is free software, just like Terraform was (and hopefully still is). There is literally nothing stopping Hashicorp from doing the exact same thing in the opposite direction.
Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/. So, Pulumi has grown their directly competing product partially on top of the Terraform ecosystem - and I'd argue they'd be half as successful without reusing Terraform providers - and make money off of that product. It's at least understandable to me that Hashicorp doesn't like this.
1. https://developer.hashicorp.com/terraform/registry/providers... - "official" providers are maintained by HashiCorp
2. https://registry.terraform.io/browse/providers?tier=official - The filtered list of "official" providers maintained by HashiCorp
3. https://github.com/pulumi/pulumi-aws/tree/008c4360bc9fc24303... - Just prove it to myself, I can see the `upstream` git submodule, which embeds pulumi/terraform-provider-aws, which is a fork of hashicorp/terraform-provider-aws, although the repo was not created as a fork in Github, so it is not marked as a "fork" and so I have to compare commit histories to tell that it is a fork.
The Google TF provider is actually maintained by Google via Magic Modules, a single source for both TF and Ansible . The generated TF provider does reside in HashiCorp’s GH org tho.
I kind of feel that this is the point of open source. That the work one group of people does can be leveraged by all of humanity.
I appreciate open source in all it's forms, as it's so much easier to 1. Read the code in case of a bug or just to understand your dependencies better, 2. Many of the semi closed licenses still allow you to learn things like syntax for GitHub actions or do analytics or whatever, which is still more value than an entirely closed system, and 3. It allows me to reproduce binaries and independently audit security.
That said, I'm worried about a tragedy of the commons situation. I'm not a fan of capitalism, but at the end of the day I can't pay for housing or taxes in clout or goodwill, and the only way I see likely to both attract talent and survive is one which works within the system while sacrificing their principles as little as possible. These wonderful engineers at elastic and hashicorp and pulumi and every other company mentioned in this thread need to eat.
I'm not saying I have an answer, but I am saying that I respect and understand why companies like elastic and hashicorp are resorting to drastic measures. If the choice is between either of those companies going under or having their source code come with a little bit more restrictions, I'd chose the latter. I'd much rather them have a noncompete clause in their license than have them just shut the window into their source code altogether.
That's being disingenuous. The link you cite is the pricing of Pulumi Cloud. Of course hosting infra can cost money. The second non-heading line in your link shows a way to host Pulumi on your own infra and that is fully free: https://www.pulumi.com/docs/concepts/state#using-a-self-mana...
However, Pulumi Cloud is only as valuable as Pulumi itself. If Pulumi didn't support deploying to AWS, for example, then it is useless to my organization which uses AWS and I'm obviously not going to consider Pulumi Cloud. So Pulumi does gain a lot of value even from just the Terraform AWS provider that it uses under the hood (and which it can continue to use because it seems Terraform provider licenses are not changing, which is nice).
The paid features have nothing to do with the providers; AFAICT that's competing with Hashicorps's backend / state management offerings - namely, Terraform Cloud: https://www.hashicorp.com/products/terraform/pricing?ajs_aid...
They absolutely do. If I use AWS and Pulumi could not deploy to AWS, well I'm certainly not going to buy Pulumi Cloud, am I? If I use multiple cloud providers and Pulumi doesn't support all of them, I'm unlikely to invest further in Pulumi Cloud, right?
The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
The fact that Pulumi leverages the Terraform AWS provider under the hood adds huge value for them, and I absolutely believe they indirectly profit off of that.
No, they absolutely do not. Pulumi - as in the actual tool, not its developers' equivalent to Terraform Cloud - would still exist and would have used those providers regardless of whether or not there's some Pulumi equivalent to Terraform Cloud. Pulumi also would've existed (and resulted in indirect profits via Pulumi Cloud) had that provider ecosystem not yet existed; it just would've been Pulumi starting it instead of Hashicorp/Terraform.
> The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
And you can use 100% of that value without paying a fraction of a penny to Pulumi, just as you can without paying a fraction of a penny to Hashicorp. It's a completely different offering from their respective paid products altogether.
> I absolutely believe they indirectly profit off of that.
You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers. That's one of the main sales pitches for open source, after all: to collaborate on something that benefits everyone instead of wasting a bunch of effort on independent silos.
That is: Hashicorp indirectly profits off Pulumi's own contributions to that same ecosystem. They could profit even more by making Terraform compatible with Pulumi's provider interface (even still! I'm pretty sure Apache 2.0 code can be included in non-FOSS codebases, BUSL included).
Like, the relationship between Hashicorp and Pulumi is not just to the letter but to the spirit of free and open source software. If Pulumi's existence and success (despite being nowhere near that of Terraform, and despite also being open source - even more permissively so, in fact) is indeed what motivated Hashicorp to switch Terraform from MPL 2.0 to BUSL, then that's toxic as all hell and completely nullifies any of Hashicorp's lip service to "open source".
This is idealism.
The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort. Then, Pulumi can spin up a directly competing product in a fraction of the time by reusing all of that work. So I understand the motivation for the license change.
Circling back to your original comment which spawned this thread:
> Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
The answer is unequivocally "yes". Pulumi has. And Pulumi can continue to do so, apparently. Terraform providers continue to be MPL-licensed.
Another example I learned of was IBM Cloud Secrets Manager, which is basically reselling Vault: https://www.ibm.com/cloud/secrets-manager
With IBM Cloud® Secrets Manager, you can create secrets dynamically and lease them to applications while you control access from a single location. Built on open source HashiCorp Vault, Secrets Manager helps you get the data isolation of a dedicated environment with the benefits of a public cloud.
No, it's realism. The only one to blame for Hashicorp not adequately capitalizing on the two-way street that is multiple FOSS (well, formerly, in one case) IaC systems being compatible with one another... is Hashicorp. Instead of recognizing a case where "open source" is mutually beneficial, they'd rather take their ball and go home - and that's their right, but it ain't beyond criticism.
> The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort
The reality is that Hashicorp adopted Pulumi's strategy of autogenerating provider resources from API catalogs rather than maintaining handwritten bindings (i.e. what differentiates Pulumi's "native" v. "classic" providers). So yes, Pulumi's providers clearly have value. Hell, they can continue to have value even after Hashicorp's BUSL shenanigans thanks to Apache 2.0 being permissive.
> The answer is unequivocally "yes". Pulumi has.
The answer is hardly "unequivocal", per above and per the previous comments. Calling a collection of third-party-developed API shims a "product" is itself a massive stretch of the word, and calling bidirectional / mutually beneficial contribution to that collection "competition" is itself a massive stretch of the word.
IBM Cloud Secrets Manager is much better evidence in support of an unequivocal "yes" (though like most non-mainframe IBM-branded products these days I'd question whether or not it counts as "of any significance").
I think they're being more honest than others in not saying that changing their license is not to remain "open source". It's evident they know the pushback they would get from calling this "open source".
It’s really nice to have infra and apps flow through the same pipes.
I'm being half-serious. Of course the point is that "competing" is deliberately very poorly defined, and it's entirely on the whim of hashicorp to decide whether or not you're competing and then impose a lot of legal costs on you.
It's a racket.
That CLA grants HashiCorp full license over your Copyright, and explicitly allows them to sublicense your contributions[1]. Drew Devault's blog posts[2][3] on this topic are extremely relevant.
[1] > Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to HashiCorp and to recipients of software distributed by HashiCorp a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
[2] https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
[3] https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html
It's stuff in the MPL period that is more questionable if they don't have contributor sign off.
It’s a good question. I suspect several forks might be happening as we speak.
And I checked the contribution guide for the aws provider, no mention of a CLA there. I wonder if Hashicorp would be able to pull the providers under the same BSL in future ?
Anything before the change is still MPL and can be forked and built on top of freely.
per my reading of FAQ if you fork and modify old MPL it still have to be MPL, so if hashicorp fork old MPL code they need to release it under MPL.
but they are not saying they will be adding new files under business license keeping old files under MPL, they are saying future releases of products will be shipped under business license.
This is hostile to end users, small people an companies, not just big megacorps wanting the "steal" the code and run it as a service. Be successful in running and using Hashicorp's software, and they decide to shut you down if you are deemed a competitor.
At any moment for any reason they can declare that you your use or your business in some way competes with them and cut you off.
You have no recourse. They don't need to explain it. They can even add a product remotely like what you're building or misunderstand your product and you are screwed.
The BSL carries with it immense legal risk.
Yep open source is used as a marketing. I doubt they'd gain much adoption if it started with BSL at first place.
Adoption is one risk, https://github.com/hashicorp/terraform/graphs/contributors is an entirely different risk
I don't have the emotional energy to dig up such a report, but I'd be stunned if Sentry receives the same outside contribution rate as it did before
Like https://github.com/hashicorp/vault/blob/main/go.mod#L25
> However, there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don’t believe this is in the spirit of open source.
This is 100% in the spirit of open source. If this is a problem for them, why not adopt an open source license that compels developers to open source their code instead, like the AGPL?
This is purely a way for HashiCorp to ensure they are the only ones who can commercialize these formerly open source projects. Which is fine. But just go closed source, then, and own that, instead of trying to have it both ways.
High level, times have changed. Source should be (my two cents, ymmv) about a mutually beneficial partnership between builders and users, not “give it all away for free or you’re not legit.” Users get to understand and extend what they’re running (via source), while the project steward/maintainer/owner can continue to do so.
It is a balance to be maintained in tension, not an equilibrium to be reached.
That sounds like what the GP comment is saying. If someone said "turns out open source doesn't work for our business model" it's hard to argue with. If instead they talk about "evolving open source models" and whatnot, it feels like they want the best of both worlds. It's been happening a lot recently that companies pretend they are "open sourcing" something for the PR but really use a much more restrictive license.
On the other hand, if popular software becomes faux-pen source (I read that somewhere recently) and community members stop contributing, it's a loss too because it means we all become takers on whatever company's terms.
Your almost certainly right about the window shifting, I'm going to keep complaining anyway.
I don't think this is happening at all. Open source means the same thing it's always meant. Some people are just retreating from open source. Which is fine, they should be writing Free Software anyway if they want the world to have it, or use proprietary licenses if they don't. Otherwise very wealthy people will live on your back.
But :shrug: I guess different people care about different things, is what I've realized watching these discussions unfold.
But I do think this purist perspective on open source is just going to result in more Snowflakes and fewer Hashicorps, because why bother with this fight?
Orgs like Hashicorp clearly think they benefit by pretending to be open source.
They could simply stop being disingenuous about their source available proprietary software, and nobody would stop them.
But while that's what I think, it isn't at all the view espoused here by Hashicorp. They aren't claiming this is open source. They are accepting the OSI definition and not claiming their new license falls within it.
They aren't being disingenuous. You're putting words in their mouth, and then getting mad at them about those words they didn't say.
No, they say open source needs to evolve, the implication this is an evolution (not devolution) of open source.
Their announcement talks about how they spoke to OSS experts. That's not relevant: the experts would simply have said: that's not open source.
Hashicorp several times say the BSL is permissive. Permissive is a well established term in software licensing. No, the BSL is not. The BSD and MIT and Apache licenses are permissive.
Finally there is this claptrap from their FAQ:
> 17. Does HashiCorp still believe in open source? > > Yes. [...]
"implication"
> the experts would simply have said: that's not open source.
Presumably the experts did tell them that it is not an open source license, which is why they chose not to claim that it is.
> Permissive is a well established term in software licensing. No, the BSL is not.
I think BSL easily fits the bill for the word "permissive".
It's just all so much gatekeeping, and it's really tiring.
Because companies keep bringing this fight.
Companies will naturally conclude they should just make proprietary software, which doesn't require a big fight. And I think that's a shame.
How many of these companies could exist if all these projects underpinning their own swapped to the SSPL, BSL, etc? And I don't mean now - once you reach a certain size, if you have to replace a bunch of dependencies, you have the resources to do it. But when these companies were smaller, would they have been able to create their own implementation of all these dependencies and still get their product to market? Would they have had the resources to commit to all of it? Would they have had the money to pay for non-FOSS options?
How many of these projects would still exist if the community couldn't commercialize them? We're not even talking about whether or not they ultimately end up contributing code back, etc., because it's not like these licenses give you some threshold of code contribution after which you can commercialize it. Sure, the possibility exists of some special private licensing agreement being struck, but that's possible with proprietary code, too.
Source available might sound fine from a personal use perspective, but it ignores the fact that the environment that made all of this possible would not have been possible under that model.
To me, the difference is that these are all building blocks rather than standalone products. I think of these commercial products as making sense for standalone services, rather than libraries and other building blocks.
But also: I think the business model that built all those open source building blocks has always been pretty shitty, relying on a lot of altruistic un- or poorly- compensated work from people. And I think that's bad. But I don't think demanding that companies making useful services also be subjected to a shitty business model is a good solution.
But, let's take just apache and nginx as an example: Lots of people offer just webhosting as a service. It's gotten less and less common now, with things like Squarespace, Shopify, Medium, etc. etc. etc., but once upon a time there were tens of thousands of companies that were making all their money by providing storage/compute/networking and a place to upload your HTML files, and then later adding in additional services like PHP and other scripting languages, MySQL for database hosting, etc.
Now, the context here is a bit different here, of course, particularly for Apache httpd. But Nginx has Nginx Plus, MySQL AB would license you a closed-source version or do the usual support/consulting/etc. stuff. But it's not hard to imagine a world where they could have easily said "Hey you know we're experts in running this stuff, we should just run it for people and charge them" - just like we see with a lot of these "open source" companies today.
There was never a general outcry about tons of businesses making money just hosting these open source services, even though the vast majority never contributed financially or otherwise to these open source projects. The only real difference I can see between then and now is simply what path the companies behind the projects, where applicable, have taken to monetize. Would the internet be a better place if MySQL AB moved to offering hosting as a service and put MySQL on the BSL, preventing all of these webhosting companies from having existed? If F5 had done it after acquiring Nginx? Cheap and plentiful webhosting is a big part of what grew the internet so quickly, particularly before the 'Web 2.0' days of social media sites centralizing so much of the traffic on the internet into a handful of places.
> But I don't think demanding that companies making useful services also be subjected to a shitty business model is a good solution.
Well, I'm not demanding a company do anything. I'm just saying that the internet as it exists today, including all of these companies we're talking about, would not exist if earlier on people had made the same choices they are. Open source is not about guaranteeing a viable business model to companies - it doesn't care about your business - it's about ensuring certain freedoms in software. And the internet we're discussing this on exists because of those freedoms it guaranteed.
If you can't build a viable business when abiding by those freedoms for whatever reason, then sure - go build proprietary software. I'm not going to call it or you evil. But I do take issue with a company using open source as a method to gain adoption, additional contributions, mindshare, etc. and then no longer being open source while talking about how they are an "evolution" of it. You're not an evolution of open source if you're removing freedoms.
Yes, the FSF has a general preference that people use copyleft licenses like the GPL, but they recognize that permissive licenses meet the Free Software Definition.
The difference between free software and open-source is a matter of marketing. Open-source is a way of presenting free software to businesses and investors. Free software is an unabashedly political movement, openly concerned first and foremost with the public good. But the licenses themselves and the software itself, those things are identical.
Only if we let it, and stop shouting about it and finding alternatives every time a company does this.
This isn't a new thing; companies have been trying to play "almost open source" games for decades, and they'll continue playing those games as long as it either works or doesn't have sufficiently large penalties for trying. (Much as companies will continue violating copyleft licenses as long as they either get away with it or the penalties for trying are simply an expected part of the risk.)
The best possible response to a company doing this is that someone forks the code, starts or expands a competitor, and the original company's revenue drops massively as a deterrent.
Example of the last time this worked?
https://investor.oracle.com/investor-news/news-details/2023/...
Oracle decided to make Hudson commercial, it was forked and Jenkins is still around but Hudson is dead.
Turns out Jenkins development needs to be sponsored somehow.
but still manages to suck the air out of the room when you want Elasticsearch because AWS already has the company's billing details and no one wants to figure out paying another provider.
We've had "source available" for a long time, which means something else.
I don't disagree that people may still use SA software more as time goes by, but I would argue that when possible people will prefer open source controlled by entities that keep it such.
I’d kill for your confidence
This has been the case since the 2000s, as companies want the branding without the openness. This is extremely well worn by now.
I argue that companies who want it both ways are continuing to throw up chaff. But we know this chaff extremely well.
None of this discussion is new. "open core" has always been a euphemism for "proprietary."
Yes. And in some ways, source available licensing is a nicer model for proprietary software than open core. At least with the former you can actually see all of the code to inspect how it works when something is broken.
Bleh. Every business wants to build on software freedom but they don't really want to see others freely build on their own software.
perhaps according to Hashicorp's marketing team, otherwise I haven't seen any evidence this is the case
https://fossa.com/blog/open-source-software-licenses-101-agp...
inbound=outbound license terms is a good norm for FOSS. Why should a software vendor play by different rules than everyone else when it comes to things like copyleft compliance?
[1] https://meshedinsights.com/2021/06/14/legally-ignoring-the-l...
[1] https://sfconservancy.org/copyleft-compliance/principles.htm...
The reason AGPL isn't being adopted in these situations is that it doesn't sufficiently protect against someone doing what e.g. AWS repeatedly does - turning open-source projects into services and then dominating the market while continuing to benefit from the upstream project. See the ElasticSearch licence change for a prominent example.
I don't know enough about their operations to have good suggestions on how to become sustainable. But, I don't like this move. There are many sustainable open source companies. Moving to source available from open source will likely never be a move I like.
[1] https://www.google.com/finance/quote/HCP:NASDAQ
What are some examples?
And Hashicorp + Red Hat managed to make it work as open source companies for >10 years also
There are many more "open core" companies, like TimescaleDB, Docker, etc, who then sell proprietary services on top of the open source software
> pretty much every crypto company in the blockchain/web3 space
The entire "space" has yet to prove to be sustainable. Most of these are hype-driven borderline scams, I would not list them in a _sustainable open source business_ context :)
Firstly, I don't have a problem with BSL. I do think in general it's a bit of a slap in the face to build a business on the backs of volunteer contributors, and then close-source all your codebases which are comprised of their work.
Sure, when people contributed, they signed a CLA which gives Hashicorp the right to relicense the work (which has legitimate uses outside of killing open source, such as giving them the ability to make that software available under other terms in addition to their open source offering)
But when as little as a year ago they promised "We remain committed that the core of our technology will always remain open source." (https://web.archive.org/web/20220703202305/https://www.hashi...)
it gives whiplash to the people who contributed based on that promise.
Actually, I don't even know if this is legal, but even if it is, it's a huge violation of the trust of outside contributors to their software products.
> The entire "space" has yet to prove to be sustainable.
I agree that it's unproven, but this downturn has made apparent that so are the majority of software companies which have not IPOed and shown a sustained profit for 5+ years.
I'd give Uniswap pretty good odds of outliving the majority of YC startups.
The majority of YC startups are definitely not sustainable.
Probably even most of the successful ones are not sustainable, they make empty sustainability promises hoping to get bought by <BIGCORP> and end up on "our amazing journey" lists.
But a surviving project moving to BSL is still clearly better then the company going under and the project ending in limbo.
Even with BSL you can still access the code, audit it, learn from it, fork it to keep your own patches on top and keep up with upstream, etc. Huge value compared to closed source.
SUSE is a niche player that was bought out in various forms a number of times.
Canonical is largely a billionaire's toy and hasn't published financial numbers in half a decade. They were losing money last time I looked at them.
Don't know Prisma.
Gitlab is losing money.
For the crypto companies, let's hold off on any of that in terms of "sustainability".
Look at the top 20 software companies. How many of them have open source their core product, their main revenue source?
GitLab (Enterprise) is also proprietary software.
> And Hashicorp managed to make it work as open source companies for >10 years also
You mean they lived off VC money for >10 years?
> There are many more "open core" companies, like TimescaleDB, Docker, etc, who then sell proprietary services on top of the open source software
As above. Since when is Docker making lots of money?
You're not free to decide your source available model is open source and reap the marketing benefits of open source without the costs.
That way all the "it's not really technically open source" complainers couldn't day that its not technically open source.
It wouldnt substantively change anything of course, but that's somewhat the point. BPL/EPL/SSPL was always fully within the spirit of open source, it just pissed off the same large corporations who also can't stand the AGPL.
BPL, EPL, SSPL are all "not open source", and AGPL+CLA is "we're setting up for a bait and switch with not open source versions".
This was all hashed out years ago in numerous flame wars on Usenet, as I’m sure you know.
Which is fine imo as long as the moment they pull the bait/switch they stop calling it open source (and others can fork at that point)
I view that as a very different question from whether its ethical to advertize something agpl+cla as being open source.
It literally is not, and they only exist in order to not be.
The one restriction is that you can't compete with their hosted services using their software. Which 99% of people who use their software have zero interest in.
The "it's not fair! it's not real open source!" narrative is pumped up by companies like Amazon that feel entitled to use their monopoly power to leech value from these companies by selling paid versions of their products.
It does affect the the richest, most abusive corporations though.
It isn't just the need to eat. There's also the issue of keeping investors happy and their continual drive to maintain growth or earnings at stratospheric levels.
Strict IP laws are the only safe way to do that, and that is why so much software has leveraged them over the years. The internet era felt like an aberration for a while, but things seem to be shifting back to high double digit margins as the only desirable goal.
> On 29 November 2021, HashiCorp set terms for its IPO
...I'm starting to think I'm onto something. (I do welcome anecdata that either helps or hurts my hypothesis)
I firmly believe this is a fact too.
One place I recently worked, I joined as it was going public and it went downhill quickly. The friends I’d made there talked about the fun perks, holidays and benefits the company was known for. Over the space of less than a year most of the culture atrophied, people left in droves and there were exactly zero holidays or perks given out.
Quarterly scope for fiscal data is one of the most short-sighted decisions humans have ever done. Expecting quarterly up-and-to-the-right, where simple sustenance is not enough, but profit must grow quarterly, on a planet with finite resources in an economy with finite money, is a guaranteed, zero-exceptions, recipe for failure, by definition.
If I were starting a business these days I'd be tempted to found it on the basis that 60% must be owned by employees of the company until the last living descendant of king Charles dies.
Making it seem like it's a legal requirement however is a very good thing for all the corporate raiders out there.
Their stock was down 60% only 3 short months after IPO.
I think this is just a struggle to turn what was once technical excellence into something that gives money. I haven't followed HashiCorp lately but was once a fan of some of their products. These days it seems things are slower over there. At least that's what it feels at a distance.
That's a scary thought.
The vast majority of tech companies that IPOd since Facebook have been a disaster of an investment.
This seems too black and white. Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
For the most part, no, the main direct customer benefit comes from the absence of lock-in with regard to maintenance and services thar results from the absence of usage restrictions.
There's some potential indirect ecosystem benefit for customers from the somewhat lower friction for partners in some source-available-but-use-restricted situations, but otherwise for most customers its the same as any other proprietary license.
I worked for a company a lot of years ago that had BSDi licenses for some of it servers and had paid an extra fee for source access and that -did- actually come in handy to me once or twice.
Later, the same went for the Radiator RADIUS server where you got source access automatically with a license purchase.
White box versus black box debugging is absolutely something that can make a difference, especially when something goes wrong.
Yep. I've definitely noticed this at work with some proprietary ('open-core') software that we use, and it's made me inclined to prefer source-available proprietary products over more restrictive proprietary ones as well. It's not as favorable as actual F/OSS, but it definitely makes a bit difference nonetheless.
Which, of course, is obviously false. Which means the words have different meaning than what you ascribe to them.
Source available means you can view the source code, by abiding to the terms the owner of the code sets.
Closed source means you can’t change or redistribute that source, regardless of whether you are allowed to view it.
https://www.microsoft.com/en-us/sharedsource/
This just means it's Source Available to certain customers - Closed Source to others.
I agree that universally available "timebomb open source" "Source Available" is different from "Closed Source", though.
It allows for certain risk planning, like: If HashiCorp goes away, we will be able to host and patch (and keep using) product X for the foreseeable future - along with the ability to actually read the code and determine if it is something worth touching with a ten foot pole...
The opposite of open source isn't closed source, the opposite of open source is restrictive. You're not forced to refuse to let people see the source when you're not open source. You're not forced to eliminate everything that OSI-approved licenses must have if you're not OSI-approved. There are no OSI cops that bust proprietary vendors for using a subset of their characteristics.
Of course it would be better if it were Free software, but it would be better if all software were Free software. They're doing them.
edit: My objection comes when people pretend licenses are open source when they are not OSI-approved and couldn't be. HashiCorp is not claiming to have remained open source: they're now "source-available."
They need more open PRs? It's not like these contributions would necessarily be welcome.
That is the spirit of Free Software (ie restricting users as little as possible) Open Source is much smaller in scope.
So restricting competitors is as much against the OS spirit as it is against the FS spirit.
The blog post is disingenuous. We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin.
Thankfully over time, they already pushed responsibility for most Terraform providers back onto their partners, so I'm hopeful the ecosystem of providers can still stay vibrant and open.
We are deep believers in open source---heck my last project at Microsoft was to take .NET open source and cross-platform, our CTO helped found TypeScript, and Pulumi is an Apache open source project---it seems HashiCorp no longer is.
The bald faced disingenuous nature of this change here is wild. They can't compete at their pricing because their pricing is absolutely insane over what the market can bear and they refuse to accept it.
They are going out of their way to make it less expensive to stop using terraform altogether right as so many new options have entered the market
In other words: if you hard fork now, you don't need to pay.
I love the ethos of open source and have spoken at and helped run conferences, and had the pleasure of being paid to develop it - but the productivity I had when paid ten hours a day to work on OSS compared to whenever I get a chance between work family and everything else, well, it's better for everyone to get paid and release code, than not get paid and not write the code.
I see these semi-commercial licenses as the equivalent of a legal "just don't take the piss".
Would be interested in your side of the question. How do we keep on developing the code as well as keeping it open?
Pulumi is one of several products where I like that it’s open source in case I need to move off their cloud, but hope that I don’t have to (Plausible is another).
Said well (and thank you for being a customer and valuable member of our community!)
The analogy I draw sometimes is that our open source infrastructure as code SDK ("Pulumi") is like Git, and our commercial offering ("Pulumi Cloud") is like GitHub.
Like GitHub, the Pulumi Cloud offers valuable features that go beyond the open source project for teams looking to manage lots of projects securely at scale, but we definitely love our open source community and want folks to have the choice to use Pulumi however makes the most sense for them.
This approach also has the nice consequence that we can be fully transparent with our community at all times while also building a strong, long-term business. If a new feature is part of the infrastructure as code SDK, it's open source and free; if it's part of the Pulumi Cloud SaaS, it's part of our commercial offering. This avoids needing to do things like artificially hold back features (like open core) or violating our commitment to the open source community (like Hashi's new license).
1. I can read all of the code, modify it, and self-host it for my own purposes, but the license disallows me from re-selling it.
2. I can read, modify, self-host, and commercialize a subset of the code, and the rest is an opaque SaaS.
To me, as a customer with no interest in re-selling this code, I don't see how #2 is better than #1 in any way. And I find it incredibly mystifying that I keep seeing companies ragged on here for doing #1 while the model in #2 is somehow held up as the paragon of ethical virtue or something.
Can you help me understand? Why is it better for me to be able to read less of the code I'm running?
For #2 in good faith using the github model here,
Sure there’s Git and Github. Also sourcehut, using google cloud source repository or any managed git service.
Either 1) I need the software and I can have a team maintain it.
Electing for the software-as-a-service vs self hosted model is in itself.
1. I can compute, resources, maintenance and time The proprietary or a version of the product myself or a fork and get the feature functionality from other open source or provider.
2. Pay for the GitHub licensing cost and using the service and ok with magic abstractions to operate the software. (Which admirably lately has been bad.
Also frame it as from the beginning of the git project elected to also build all the same parity features, would it be the same tool, be the product that exists, or brain share it has today. Maybe not.
I maybe misunderstanding you here but in these cases opaqueness is part your trade off to offload fairly complex for a marginal cost that’s s decision by you.
What I like best is to use a fully managed service that I can contribute changes or even self host a modified version if that's what I need to do to get what I need. But I don't want to self-host. But I highly value the option. And I highly value the ability to go read the code when I wonder "hmmm why is it doing that?" and maybe contribute a bug fix if it shouldn't be.
All of this works great with model #1 - with full "source available" with a license that limits re-sale - but is limited with model #2, where it only works for the "open core" portions of the product, but not the proprietary SaaS portion.
If you want to build something with a bunch of smart people for a long period of time the outcome is raising venture capital, paying people salaries that are competitive to share holders, and won’t implode. The bsl is a consequence of that but it is a rule to guard from the few bad apple in this case.
What’s ethical or virtuous or perfect is very nuanced
SSPL is unacceptable for me because it have its restrictions last forever.
https://learn.microsoft.com/en-us/azure/azure-resource-manag...
Not sure how I could "misunderstand" this quote to mean anything else.
By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.
surely, state needs to be tracked somehow. what would an alternative even be?
I'm sure there are complications i don't care to see here, but why is "this is what is actually deployed" not the default case?
Refreshing the state file (and reconciling differences) also uses the cloud provider API’s. I don’t think we’re going to get better than that.
Unless someone makes a common standard for resource reporting that all cloud providers implement.
that’s part of the case for a centralized state, to have an additional place that describes what should exist and what it looks like.
Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.
also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.
infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.
totally possible im missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.
I work at AWS in Professional Services until tomorrow. I worked with the SA and had meetings with the service team responsible for the AWS Service in question to discuss the API shortcomings that we needed for automations. He contributed to Terraform once the APIs became available from our service team and I wrote the equivalent CloudFormation custom resources for a project (and open sourced on the public AWS Samples GitHub repo after going through the approval process) as part of a larger project.
I found a bug in the underlying service API that affected both my implementation and the Terraform provider my coworker wrote. I posted a sample in our internal Slack channel where the developers of the AWS service hang out and they fixed the API bug relatively quickly.
My coworker, had no problem getting his TF code merged in. I know the code he wrote and I went to the GitHub page before posting this and it is in there.
Later as native CloudFormation support was added, I replaced my custom resources with the native equivalent as part of the larger project I was working on.
There's probably not much AWS contribution to the core of Terraform from AWS, but there's very little contribution to that from anybody outside of HashiCorp because contributions happen on the providers.
AWS is definitely involved with their provider though. AWS ProServ built out a whole account vending machine thing that was in Terraform (the name escapes me atm), and various other service teams and SAs are regularly involved in contributing to and growing the Terraform ecosystem.
It would be super disingenuous to imply AWS is not contributing to the success and growth of Terraform.
OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.
Sometimes it's not even obvious for external contributors, but there may be some small overlap with other paid features that are part of their product roadmap.
If a project on Github only has maintainers from the corporate side, you can be certain that they will ultimately drive the product for their own interest solely.
We should always pay close attention to the governance model of projects we depend on or that we wish to contribute to.
The only way to know for sure is to dive into the merged and unmerged PRs and see how they were handled.
To not lose control you need to have people assign copyright which is generally a headache. I've only heard of the FSF doing that .. (not sure why this hasn't been streamlined electronically somehow)
Fair enough, let's see the PRs so we can judge for ourselves.
It's not comparable.
Not that I don't appreciate the effort. I'm sure what has been achieved involved a fair share of convincing too.
[1]: https://isdotnetopen.com/
Being in the Apache Foundation gives me all the assurance I need alone, though.
So without defending the change they -have- made, that doesn't seem like where you're going to run into problems as a result of said change.
It sounds like a Terraform alternative, but looking at the website it doesn't really convey if it's a Terraform fork or ground-up re-write, or something else?
---
Actually, on second thought it sounds like the platform they're built on top of (Terraform) is now undergoing some fundamental business model changes.
Probably best to see how that plays out first. :/
Maybe not all their providers utilize Terraform, but it was definitely how their product started out. When you run Pulimi using their AWS provider and get errors at runtime, some of those are verbatim Terraform errors.
Their docs and site is very clear to muddle this connection but if you ever used their API, you'd know this.
(1): https://news.ycombinator.com/item?id=37081306
Pulumi being open source while Terraform is now proprietary cements that.
I don't know if the license change actually means providers will not be able to work with Pulumi, but if it does, it seems risky to use Pulumi even for personal projects if newer provider versions (i.e., versions that work with newer products released by the cloud provider) will not work with Pulumi, it's a dead end. And that's not to mention the useful providers that aren't cloud and completely community developed that will not have the resources to maintain two codebases in any case (I'm thinking of Sendgrid).
I looked at terraform-sdk license - it still seems to be MPL. I think this means that all providers can continue to be open and work with both platforms, it will be important for Pulumi to clarify this to prevent the death spiral. Given some negative feedback towards the Hashicorp blog post from Pulumi employees on this thread, I am somewhat skeptical of this since if everything is fine, then complaining will otherwise have a negative effect, that us users have to assume that Hashicorp is actually stomping them out. And if it's the case, sorry but in good faith to everyone else that may need to work on infrastructure I make, I will have to be complicit in the stomping.
Would this prevent you from integrating some modules such as AWS (I believe) from TF?
So much love for Pulumi from me, it’s an amazing product.
Pragmatically I would rather bsl than closed source and I am more likely to use a product that is bsl, with reasonable transfer time and license, than a 100% closed source product.
I'd also much rather have "open source" with commercialization restrictions than closed source.
It's still in most people's best interest to contribute to these projects if they were before, or would have before. Many businesses(and this is where most of the contributions get funded from, let's be real) rely on these projects and have no intention of selling them or competing with HashiCorp services.
The actual text of the BSL mandates - under threat of infringing on BSL's trademark - that in at most four years the code will be available under a GPL 2.0 compatible license. In practice, the BSL license is usually a traditional open source one with caveats. The BSL FAQ also states and restates many, MANY times that it is not an open source license according to the OSI's definition.
I can't help but feel like the outcry over this is just a tempest in a teapot. I have a hunch that "Open Source" will do just fine without us having to carry water for it. After all, the list of OSI's corporate sponsors is quite illustrious: https://opensource.org/sponsors/
If we don't have a common definition, everyone has their own, and there's no common understanding of what rights you have for a piece of Open Source software. That commons has far far more value than any one or ten pieces of software.
I don't think so.
I suppose I can understand why people who feel strongly that the OSI definition is perfect (or at least extremely good) are very intent on protecting it, whereas I see it as flawed and am thus less concerned about this fracturing. So I understand your perspective upon reflection, though I honestly have a lot of trouble imagining holding it myself.
A lot of people in this thread have been saying stuff like "just go full proprietary, that's better", and it sounds ridiculous to me every time I read a variant of it
As for the commons, you are aware that the OSD comes from the Debian Free Software Guidelines (it's the same thing but for some minor working changes)? That is the commons that's been talked about, and it's deployed on far more systems than any BSL code is. So moving to completely propriety (note that this doesn't mean it's not Source Available) means that everyone is upfront about what the state is, whereas something like the BSL is leaning into the halo effect under the justification that the code will be open source at some future point.
But this second part of the argument I just don't grok at all. These licenses like BSL provide significantly more of what I want in software I use than proprietary software does. (Namely, the ability to read, modify, and self-host the software of I choose to.)
I think what must be going on is that when you see a license like this you think "there is no point to something like that besides a PR stunt trying to imply proprietary software is open source", and I think "oh this seems like a really useful compromise that allows commercial enterprises to create software with code that I can read, modify, run myself, and contribute to if I want to, without a different company that did none of the work on the software making all the money from it". Just totally different perspectives.
The reason I'm personally annoyed at the attempt to drop the requirement for no restrictions on use is because it is something some academic software does (things like "if you use this code, any results must be shown to me before publishing and require my approval", which as you can imagine isn't great), or with rules around benchmarking (which some DB companies have been known to do), and it's significantly harder to draw the line between something that would allow the BSL, or the above two cases, than it is to require no restrictions on use.
But this part:
> had they been more careful in their language (or even in their CLA), then people would be less annoyed.
I just don't agree. I think they were very careful in their language, and I keep wondering whether everyone here who is pissed at them even actually read it, because I feel like a lot of people keep saying they said things that they clearly worked hard to not say.
I think it's a common shared understanding and a focal point, and there's huge value in preserving that. Having a different common understanding might be acceptable, and might even be an improvement, but only if people agree on it. Having no common understanding would mean something of great value was lost.
Right now, many different groups who may not all agree on all goals nonetheless gain value by sticking to Open Source, and not a dozen slight variations on additional restrictions. In the absence of that, we'd have the "non-commercial" group, the "educational use" group, the "don't compete with us" group, the "don't use for military applications" group, the "don't use for nuclear reactors" group, the "don't use to develop proprietary software" group, the "don't redistribute unmodified versions" group, the "don't distribute outdated versions" group, a dozen variations on "don't distribute if you disagree with our values" groups, the "don't distribute if you're a large company" group, the "don't distribute if you're a specific company" groups...
Every one of those is a license term I've seen advocated. Every one of those violates the OSD, so it thankfully stays obscure and unpopular, because enough people prefer using and contributing to software with less unusual licensing.
Yeah I guess this just seems like hyperbole to me. It seems good to me that there's a pretty widely agreed upon definition, sure, but I just don't think it matters all that much, in the scheme of things.
Agree to disagree I suppose!
We have a messaging flow building platform which is BSL. Anyone who wants to run their own instance is welcome to and people do and thus find it useful. The idea that the world would be better off if we made it closed source and prevented that... is just nonsense.
How does making something closed source automatically mean someone can't run their own instance of it, even for free? Closed source does not mean 'You can only download this if you pay us', just as open source does not mean 'You can download this for free'
The broad distinction we care about within free software is copyleft vs. permissive, and one important one in proprietary software is source-available vs. closed-source.
Then besides all of that there are the non-licensing realities of how development is actually carried out, whether it is collaborative with outsiders, and with which outsiders...
The terms get harder because open/closed suggests straightforward opposites that partition all the options. But I'd characterize licenses like BSL and the Fair Source License as 'generous proprietary licenses with public source availability', but not open-source.
I have a feeling that the term 'open-source' is more likely to erode than 'free software', in the coming decades. We'll see, I guess.
You are exactly correct about this.
1. Open-Source is a "Marketing Program for Free-Software". You describe yourself as having the "free-software" world view (which I describe as an anti-developer property worldview).
See: You can find OSI describe itself as a "Marketing Program for Free-Software" in their original FAQ: https://web.archive.org/web/20010406183942/http://opensource...
> The terms get harder because open/closed suggests straightforward opposites that partition all the options.
2. Again, you are exactly correct. By erroneously choosing term that is generic, that was already in use, and that can't be trademarked, the OSI set itself up for a loosing battle as "the universal standard" for what is not "closed-source".
GENERIC/DESCRIPTIVE: "We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark “open source”; the mark is too descriptive. Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream. So “Open Source” is not and cannot become a trademark.
https://opensource.org/pressreleases/certified-open-source.p...
ALREADY IN USE: There are many documented uses of "open source" in relation to software that is not closed-source, going all the way back to 1985. https://www.arp242.net/open-source.html#pre-1998-usage
> But I'd characterize licenses like BSL and the Fair Source License as 'generous proprietary licenses with public source availability', but not open-source.
As a person with a self-defined affiliation with free-software, it makes complete sense that you would see it this way, but how many people outside of the free-software group see that? The further someone is from self-affiliation with "free-software" surely the less likely they are to agree with this terminology.
> I have a feeling that the term 'open-source' is more likely to erode than 'free software', in the coming decades. We'll see, I guess.
I 100% agree with you. The OSI postulates a union between the interests of people who release software into the public domain, and the interests of people like yourself who believe in Free-Software.
In my view, there is nothing uniting these two groups and the fracture is 100% inevitable. Even if your preferred term `source-available` were to gain widespread acceptance/use, there is no reason for independent developers to subsidize big business by making their source free to use for those big businesses, unless the developers ideologically agree with the tenants of the free-software movement. However, if the developers agreed with the free-software movement, they would choose a GPL style license, not a MIT/BSD/Apache style public domain license.
At least they admit it isn't open source in the FAQ and are calling it the community version instead of the open source version.
My big gripe with the BSL is when companies switch from a proper open source license to the BSL, sometimes they try to sell it as a positive development, which is BS. The HashiCorp announcement is better than some in this regard, worse than others. Claiming it's the "evolution" of open source is weird spin, of course.
I also feel like any company switching from open source to BSL puts a stench of death / desperation on them, and it makes me worry for their future. If they have to make OSS -> BSL switch today, what's the next user hostile change going to be? Will they even survive?
As I explained in an earlier thread, MongoDB tried using AGPL. AGPL is not a barrier for Amazon, they still will resell your product without contributing. MongoDB ended up using a variant of AGPL that is even stricter (requiring the entire tech stack to be under the same license) but is no longer considered FOSS. Until the attitude changes around what FOSS is, this will keep happening.
I don't think this is true.
If they have to change something, then they would likely want want to return hose changes in upstream to lower maintenance burden. Or just publish changes on github of upstream doesn't want to accept them. AGPL is fine with this too.
If Amazon would like create similar offering but with some secret sauce that they don't want to share, then they'll develop in-house solution from scratch and sell it as a service in AWS.
> Their proprietary license protecting their code set competitors and intentional clones back days, weeks or months ... years ago.
- benologist, https://news.ycombinator.com/item?id=17454032
If AWS decides to copy your product, going closed-source or source-available just means they have to copy it from design docs or protocol specs. That's more friction than being able to reuse code outright, but it's not going to stop them.
AWS never offered MongoDB as a managed service, or used any of their server software when it was licensed under APLv3, or SSPLv1.
However, we have contributed patches to MongoDB even after their license change to improve its performance on Graviton processors. Because that's what's good for customers, and MongoDB is an important customer and partner.
AGPLv3 gives all the permissions needed to offer software as a manged service, just like every other FOSS license does. Unfortunately, in my personal opinion, the license has been co-opted by companies that do not care about Software Freedom, and rather hope that companies fear the license so they choose an alternative commercial agreement [1]. I don't think that's good for the community.
[1] https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
Does Amazon contribute funding back to the software projects they offer as a service?
Does Amazon contribute code changes back to the software projects they modified when offering them as a service?
Each use of AGPLv3 licensed software has to be reviewed to ensure that the obligations of the license can be and will be met (and also screen for cases where it is known that the vendor of software does not prefer a company like Amazon import the software under a FOSS license). Today we use AGPLv3 licensed software internally, and include AGPLv3 licensed software in Amazon Linux (Ghostscript, in particular).
> Does Amazon contribute funding back to the software projects they offer as a service?
Yes, in varying ways. For example, it is not easy to provide "funding" for something like Apache Kafka. You need to have people working on the upstream.
> Does Amazon contribute code changes back to the software projects they modified when offering them as a service?
Yes, but not all changes are appropriate for upstream.
> Yes, but not all changes are appropriate for upstream.
But the (modified) source is available to consumers of the service either way, under the AGPL?
If Amazon made an AGPLv3 licensed program available to others over a network, it would have an obligation to provide to anyone that has access to that program the complete corresponding source.
Today, there aren't any services from Amazon that offer AGPLv3 licensed programs as a service. An example that may come to someone's mind is Grafana, but there is a partnership there, and AGPLv3 is not the binding license in that case.
In my personal opinion, AGPLv3 compliance is not difficult, so long as the licensor of the software is committed to community-oriented copyleft enforcement principles [1].
[1] https://sfconservancy.org/copyleft-compliance/principles.htm...
It's no longer considered FOSS because it's no longer FOSS.
> Until the attitude changes around what FOSS is, this will keep happening.
That's a weird thing to say. You're happy with it happening, and everybody else using bad definitions won't change that.
Something is either FOSS or it's FOSS-washed crippleware riding the coattails of actual FOSS for $$$.
Open-source isn't a gospel, it's a religion to some but not the end of the story in terms of what humanity can come up with. God(s?) didn't stop at "closed or open source". We can find alternatives while aiming for ideals.
All that it achieve is making sure noone can build a better product. Aka "yes our product is crap in a lot of places, but we don't want to fix it. Better extract licensing fees by locking you all with us".
The behaviour of dying companies. Which make sense. Their business model never worked.
Not just in the spirit but a fundamental tenant.
No it's not!
It's allowed, but it's not in the spirit.
The spirit is everyone sharing.
It can be true at the same time that "mechanisms to force sharing are against the spirit" and "entities that don't share are against the spirit".
AGPL and other pseudo-FOSS are purist idealistic aspirations that are, in reality, self-sabotaging footguns.
> BSL provides a Change Date usually between one to four years in which the BSL license converts to a Change License that is open source, which can be GNU General Public License (GPL), GNU Affero General Public License (AGPL), Apache, etc.
So to me the most important question is what is the change license and how long does it take? If it's 1 year then it goes MPS 2.0: okay that's fine. But if it's much longer and more restrictive than it's a real about face and means the opensource version is really not workable as it's too far behind the head.
--- EDIT:
> 4 years, MPL 2.0
https://www.hashicorp.com/license-faq#What's-the-difference-...
4 years is basically "of historical interest" only especially when security is involved.
Four years, MPL2.0
- Software made by startups that are precious to HN. In this case, building a business on top of them is "freeloading" and it's deeply immoral. Examples: Elastic, HashiCorp, Mongo
- "Public good software", there's nothing wrong with profiting from it, in fact, it's encouraged. Examples: Linux, Postgres, Nginx, Apache
Like service discovery and better load balancing algorithms.
I honestly think that’s a better relationship, kong basically advertises nginx (seems that nginx also talks about kong openly)… and yet both have enterprise services. They may not be in direct competition but they do have overlap. That’s what good competition looks like.
Edit: I do not know if kong pays nginx.
The vast, vast, vast majority of open source software was created by engineers at for-profit companies where, through their line of work, they faced a problem, and after solving it had the insight "hey, other companies may have this problem". On the flip side, the vast majority of maintainers are engineers at for-profit companies who face new problems related to the software every day, and share their solutions back so we can all benefit from everyone else's work.
Its not the old fable of the greybeard in his basement tirelessly maintaining some internet-critical piece of software (though, those definitely exist). Its: "Hey, your business uses Kubernetes and derives millions in revenue either directly or indirectly from it? Mind helping keep it going?"
This is critical to understand because: Vault and Terraform could absolutely have been sustained and grown by the community of its users. There is zero doubt in my mind of this. List the top 50 websites by traffic volume, and every single one of those companies uses both of these products, extensively; many of the companies have engineers devoting effort toward projects like Linux, Kubernetes, Javascript, or Postgres. Vault and Terraform aren't even close to a situation of "but who maintains it"; Hashicorp just refused to let anyone have power in the project that wasn't on their payroll. Far more open source projects die due to this than a lack of interest in maintenance.
The root problem isn't profit motive; its venture capital. To some degree, it is also: projects created to solve the problems of their users before their creators actually have the same problem.
The "Public good software" you refer to is much better represented by things like Capital One's Cloud Custodian, or the massive number of software libraries in NPM, PYPI, and all over GitHub.
> Software made by startups that are precious to HN. In this case, building a business on top of them is "freeloading" and it's deeply immoral. Examples: Elastic, HashiCorp, Mongo
I don't believe it's nearly as cut and dry as this post claims. The companies who are "freeloading" are usually undertaking massive efforts to be able to run the software in a very different environment than it was originally designed for. Building a hosting solution like AWS, with the high availability solutions they offer, is an incredibly complex problem, and they're adding significant value on top of the original software. Without solutions like DocumentDB and OpenSearch, many companies would not be able to build the solutions that they have built with AWS. Additionally, if we take this stance, are these companies not "freeloading" on the open source contributors' efforts?
One could argue that cloud providers' contributions to upstream could be more significant, but how much of what AWS has developed would be useful to anyone who isn't running at their scale, and using the same solutions for the physical layer?
I see two real problems, here:
In either case, it's not the fault of those who saw an opportunity to build on the work of others. The moral of the story is: don't give away your core intellectual property if your business model depends on monetizing it.They made $102M of revenue from support in the latest quarter. Their cost for providing the support was $15M, and their entire R&D costs were $54M. (Professional services was a tiny amount of revenue in comparison, and at break-even.)
Clearly support and services could easily generate enough revenue to sustain development. What it can't currently sustain is their $91M / quarter of sales and marketing.
I guess the signal here is they care more about and have pivoted business-wise to their own hosted offerings. I admit I'm not entirely sure what those are. I don't anyone that uses Terraform Cloud, but I guess someone must. So I guess Consul, Nomad, and Vault, but again, does anyone use the hosted versions of these? The big sell to me has always been all of their products can be self-hosted. Professionally, my use has mostly been with defense and intelligence customers offering behind an air gap who couldn't use the cloud offerings if they wanted to.
By far the biggest value add has always seemed to be Vault. Consul and Nomad have very clear competitors that still command more mindspace, but Vault seems to reign supreme if you want to self-host a secrets manager. On this front, though, as great of a product as it is, how much of that is even due to Hashicorp itself? The security is provided by implementations of open encryption algorithms, Shamir secret sharing, fips modules in the OS, and HSM support, but they don't make the HSMs. HA is provided by the Raft implementation of the Paxos family of consensus voting, but again, they didn't invent that. The fact this product exists at all is because they stood on the shoulders of giants who did all the heavy lifting in creating these secure and robust algorithms in the first place, and then shared them and allowed others to build commercial offerings on top of them. Your entire company exists because of other people's open source efforts, and then you close off and say no one else can build on top of your work, when if the OGs had done that, your product would never have been a viable business.
Moving away from the easy-to-predict flat rate Team pricing and to a new model based on number of managed resources ($0.000004 per resource per month or something like that) was just wacky…
… and now this “you can’t make money from the software you helped write” BS.
Hopefully they all get forked (or existing forks take off), and it is just a matter of the community converging on the winner that we all use in the future.
I'm obviously very biased, but take a look at Infisical as an open source alternative to Vault: https://github.com/Infisical/infisical (we run under MIT + some enterprise features).
i strongly appreciate the FAQ but this part felt weak/not the whole truth. What is not being said? who is hashicorp afraid of? there wasnt a doubt in my mind before and now there is.
indeed i just saw a startup demo today show off a feature that they admitted was just Vault in a wrapper (they even called their thing Vault haha) and that was it, but i would not have thought Hashicorp would mind them at all (its a very new startup)
> Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license. Commercial licensing terms are available and can enable use cases beyond the BSL limitations.
Looks to me very similar to (A)GPL + commercial dual licensing, for instance.
it's obvious that for a company (money-making entity), that they're going to want to have a monopoly in providing the software aaS. That's the monetization strategy on otherwise free software.
I don't think this is surprising. We saw this years ago with AWS and MongoDB. Yes, a startup can offer Vault cheaper since they don't have to pay for developers to build the software, and, in fact, they get to offshore their support costs to the developing company too ("yay" OSS).
I don't like it, but for a corporation that is trying to develop OSS, it makes perfect sense.
At the very least anyone using open source to run SaaS for profit should be giving something back to the authors of the software. That’s the least they can do given the user hostility of the model as typically implemented.
Open source is stuck in the 90s and has failed to respond to the rise of SaaS or “the new closed.” The big mechanism of restricting freedom now is closed execution, ownership of the network effect, and closed data not closed source. Google could open every bit of their source and nothing would be gained freedom-wise.
Running a service based on free software is absolutely within the spirit of free software. Free software isn't about a circle of gifts, it's about software freedoms. You're not obligated in spirit to "give something back" because you use free software.
Yes it's ok to use OSS to operate your business. That's a sound and intended way of using OSS. Everyone benefits.
No it's not ok to provide a competing product to the very people that you get the core of it from. That's literally stealing if not fraud. At least it is ethically dubious.
I'm not saying it's literally a yes/no decision, but this is the baseline.
I think OSS projects should offer a paid for "integration license" by default.
Think about all the reduction in sales cost their open source model resulted in. Because they were open source, they had a foot in the door and in-built evangelism.
Once that stopped being an advantage and they had utilized all the community goodwill by being open source, they make this change.
What about all the cloud providers with their own Vault offering, which is likely just Hashicorp's FOSS Vault with lipstick and other bells/whistles?
People are paying good money for Secrets Management, and probably not to HashiCorp (directly or indirectly). If your cloud provider offers a turn-key solution and it's priced right, why would you bother with an external 3rd party?
HashiCorp recently rolled out a "Free Tier" to their HCP service[1]. They're clearly trying to get more people to use their first-party services.
[1] https://www.hashicorp.com/products/vault/pricing
IMO they should just avoid open-sourcing the cloud platform if they want to sell it.
Also, why not just have gone with GPL since the beginning to at least benefit from the repackaging too?
I wonder if whatever MPL 2.0-licensed contributions were made less than 4 years ago.
Contributors should consider it as a red flag when a project isn't willing to accept inbound contributions under the same terms as they grant to others.