HashiCorp adopts Business Source License
hashicorp.com
hashicorp.com
> 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.
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.
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.
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.
On top of that, whether or not an OSS project accepts your PR means nothing about its quality or utility.
This change appears to have very little or nothing to do with most of us engineers and everything to do with companies wrapping and reselling. As far as I’m concerned it’s a good change.
Anyone who’s thinking about it. Stay away from Pulumi unless you’re okay moving from declarative IAC to some bullshit imperative Python or node constructors and for loops, and everything else that comes with writing OOP. I don’t care about the Hashicorp brand. I care about writing quality IAC and Pulumi is not it.
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.
It definitely feels like the whole era of VC drying up is bringing out the worst possible future for some of these non GPL/similar licenses. Which is unfortunate for any of us who have deliberately learned only OSS and operations around it, giving back the whole time, with dreams of building services that leverage that knowledge someday as a chance to be our own boss while also utilizing and giving back to the OSS that got us this far.
From the article: “End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp.”
Literally nothing has changed, this isn’t disappointing, it’s smart, they’re protecting themselves against cloud providers that have repeatedly abused the goodwill of the open source community.
And generally as a contributor to the vault codebase, however small, I'm not thrilled they want to capture more value from it themselves while not offering me a miniscule chunk of that.
The whole cloud provider argument really feels a lot like Displaced Aggression. You're probably punishing the people smaller than you a lot more than you are the billion dollar cloud providers who can afford both expensive lawyers and can very easily afford to fork your codebases as we see with OpenSearch vs ElasticSearch.
Disclaimer: I'm one of the founders.
From what I've seen of Mitchell as well, at least in the past, I kind of doubt this is something he would have gone through with on his own.
I suspect that Hashicorp would have said the same thing a couple years ago.
What is not MIT licensed?
When you self-host, do you have access to every features for free?
This change protects the project from getting outright shut down because huge companies use it to extract value without some of that value going into guaranteeing the project stays supported. If you contributed to it, the minuscule chunk you get is "it keeps existing and you get to keep using it" instead of "this is not worth our time, we're sunsetting this".
I guess I'm always free to fork the codebase I care about under its current license and try to build a community around that. But I think we all know that's not as viable.
Anyway, I'll just be reconsidering my use of software open sourced by companies, I guess, regardless of how permissively it's licensed. The free lunches I thought we collectively agreed were awesome and ought to keep helping each other provide, are apparently ending as money gets tight.
Today, absolutely. I would simply choose another piece of software to build on and contribute to. Or build my own if I thought something open enough and good enough didn't exist yet.
OK so you want to use their software, make money off it, and give nothing back.
if thats the case, you cant do that any more. you can either stick to personal use, or purchase a commercial license from them.
that might not be your situation, but I know as a maintainer, in most cases I would much prefer a monetary contribution than a pull request. edit, 2015, ouch:
https://github.com/hashicorp/vault/commits?author=andrewstua...
> https://github.com/hashicorp/vault/commits?author=andrewstua...
Not sure what you're getting at with your edit. I'll try to assume positive intent.
I maintain quite a few projects as well, also pretty small. Code to me means a great deal more than a small amount of money. The money is nothing compared to what I've made in my career thanks almost entirely to the code that exists publicly and my ability to run and modify it as needed to learn. I am glad to get code because it tells me something is useful enough for someone else to bother, which to me is what giving back is all about.
right, but thats not the case for everyone. you have been fortunate, but for many they cant even pay their bills with the tiny donations that come in. hence why the need arises for a license like this. to force people to either go away, or pay up.
as you've noticed, its not ideal. in a perfect world I would license my code without restriction, but I need to pay rent like everyone else.
I don't think you'd be happy, would you?
I know I wouldn't be... :-)
It's all good because usually open-source is an investment for bigger companies that they can recoup somewhere else.
But for small-players, it makes absolutely no sense to create a business and also make it easy for competitors to compete or even for competitors to appear.
But people probably realize that otherwise there wouldn't be so many debates.
Who funds open-source? (not talking about source-available but the most permissive Open-Source licenses)
Don't know how much will come of it, but it is worth a shot.
e.g. AWS -> Elasticsearch.
AWS customers like that there's one bill and one account. Who wants to deal with multiple vendors if they don't have to? It isn't a level playing field when Amazon offers a service.
Amazon could have chosen a cooperative, long-term, strategy and shared some revenue with the authors for some quid-pro-quo, and the world and Amazon, would be better for it. Instead, Amazon chose to cook the goose that lays the golden eggs, now they have to figure it out themselves, and whole ecosystems of services they could have hosted are running away from them.
- The ability to invent new infrastructure to suit a need. For example, multi legged ENIs that provide the EKS control plane are simply not available to others,
- The ability to integrate with IAM natively,
- The ability to build common network architectures without outrageous costs (traffic over peering links being a good example since that is what basically all vendors have to do).
I honestly can't fathom this worldview or how so many people here seem to be so sure it is the one that makes sense.
If you win this battle for mindshare, people will just stop making open source services like these. Every service will just be fully closed source SaaS. Amazon can't just re-sell that no matter what, and people just crap on you if you make it open source (edit: re-reading this, should have said "source available" here), so why would anyone bother?
Increasingly people who make open source software services are damned if they do and damned if they don't, and if that is how it's gonna be, people are going to just stop bothering with it.
Lucene is the core piece but %-wise the minority of the ES product.
There's no Lucene "competitor" to Elasticsearch.
Apache Solr, which existed long before Elasticsearch was conceived.
It also doesn't even have a commercial offering; Elasticsearch in no way affects any financial ambitions.
This is super disingenuous in a world where things like the GPL exist and any other license that prevents you from putting further restrictions on the combined product.
Uhm, yeah, something DID change: the license and terms. I don't understand what kind of argument this is.
This seems a lot more likely to be targeting other startups that build on terraform like spacelift, env0, maybe pulumi (although I think they interface with providers directly, so this might not affect them as much), etc. And maybe there are similar companies for their other offerings, although I'm less familiar with those.
As for "abusing the goodwill of the open source community", that's kind of the point of FOSS. Free riding is not stealing. That's proprietary world logic, and everyone saying we need to stop people from free riding FOSS is calling for the enclosure of the commons.
Let me be perfectly clear: there is no license condition you can put on software that will let everyone use it as if it were in the commons but prevent Amazon Web Services from hosting it.
"The following licence is granted to everyone except the following entities: Amazon, Alphabet, Apple, Microsoft, Meta, Oracle"
The first announced Parter are: Not-at-all-amazon-for-hashicorp inc, Not-at-all-amazon-for-mariadb inc."
Not that OSS projects backed by commercial-driven entities usually receive any meaningful amount of contributions from external people... but still, an important detail to think about OSS.
With a CLA, it grants Hashicorp rights to your contribution no other corporation has.
That's why OSS is commonly called a "Community". The software's copyright belongs to the hands of all the community of developers who have written and contributed code.
What a CLA usually does is grant perpetual permission to do anything with the code, including to relicense without asking. Practically speaking, CLAs grant full control to a single hand. Thus, OSS projects with such CLAs are not part of any so-called "Open Source Community" in any meaningful way.
EDIT: Changed "CLAs grant full ownership" -> "CLAs grant full control", to avoid misunderstandings.
No, they don’t. CLAs don’t transfer ownership.
Anyway I've edited it to avoid using the word "ownership", which might confuse the intended meaning.
A CLA, by definition, licenses rather than assigns copyright. A CAA assigns copyright. Typically, a CLA does not restrict the licensors right to license the same contribution elsewhere (if it is legally derivative of a project whose own license is restrictive, that may prevent it, however.)
I just want there to be a lot of software made that is useful to me. Software is far more useful to me if I can read and modify its source code.
So my metric is just whether I think something will incentivize people to make more or less of that kind of software. I worry that people will make less and less software that runs as a service in this fashion, as it n becomes more and more obvious that the benefits of that software flow to giant integrated cloud platform providers rather than to the people who make the software.
Being a chump is not motivating, and I think that's the current incentive structure. So I like seeing people try different structures that seem to me like they structure the incentives better.
But you're totally right, philosophy has nothing to do with it for me.
The whole point of open source is that everybody has the opportunity to contribute to the benefit of everybody. You don't get to say "oh, but nazis / Amazon / rapists don't get to use this because I disagree with their morals".
The incentive to contribute comes from being part of a community that gets to experience better quality software. For many (me included), that's plenty. I really don't care what Amazon does - I'm neither a customer, nor an investor.
I have extensive experience with enterprise vault, implementing and managing it across a company infrastructure to manage application secrets, and during the few years we implemented vault and was in negotiations about our contract, I noticed the sales engineers would
1) be dishonest or misleading about features “needed” for our user case or make long-term promises they couldn’t possibly keep about features. standard salesmanship stuff but was very aggressive.
2) encouraged an integration style that would make migrating out of vault practically impossible, if not outrightly dangerous
3) continually rug pulled features we thought would be free forever (okta/mfa login being the biggest one I can think of). You can’t pass any serious compliance without that, and they realized anyone heavily relying on vault for secrets management would absolutely have to pay for this feature.
Basically it just seemed like hard core vendor lock in and every year our bill would be a lot higher for essentially the same or fewer features. Not to mention nonsensical pricing that even their own engineers can’t explain and changes constantly and arbitrarily.
So all this to say sorry this happened to you and for Vault specifically I am not surprised and would personally not rely on it for anything serious, even though I personally consider it fantastic software - I simply lost trust in hashicorp.
You should be using the OIDC login method most of the time for MFA, and not their built-in MFA.
I’m unsure if the equivalent software is worth the price when compared to Vault and not sure I can seriously suggest anything else even if I hate this new license.
I’m underselling of course the vast capabilities of vault. but most companies don’t need those advanced features, and they don’t really sell them, they sell and lock you into features that once you implement are going to become an extraodinary hurdle to migrate out of.
On the oidc - yes we were using okta as that. but at some point mid-contract the “okta” management features that connected to it became enterprise only, and we had reasoned that if we didnt need more advanced features (dr, replication) we could go back to OSS when we wanted. In fact that was even told to us, until that was no longer the case.
I think fortunately, I'm not doing all that much with vault aside from initializing it, configuring k8s auth, writing some small policies depending on some inputs for the specific user, and then setting cert-manager up to use it. It's definitely one of the more simple projects to rip and replace.
But it's frustrating, for sure. I got some of my coolest code set up to unseal and initialize vault programmatically, and was hoping to eventually get it to a point where I'd be able to orchestrate that on a user's behalf without having control myself, via e2e crypto. Maybe with another CA project I could achieve the same thing. But yeah, looking at the new license file in the vault project, I'm not sure how well any of this would work out if my code was orchestrating it. And certs are pretty fundamental to the project.
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.
Overall it seems like a loser move. Look what happened to Elasticsearch - to me and most others, ES no longer exists. I've happily moved on to OpenSearch and not looked back at poor kimchi. Due to their own actions, Elasticsearch is no longer relevant.
Will Hashicorp's move spur a similar effort to fork the last open-source license version of Terraform and other Hashicorp tools? What other choice is there when the creator gets petty and insecure, and goes hostile against the open source community that helped create it? Extremely disappointed with the Hashicorp leadership team. MitchellH and your little sidekick Armon Dadgar - you owe your community better than this.
I interviewed with Hashicorp back in 2016 and ended up turning down the job. I used to have a small amount of regret about this decision, but now that true colors have been revealed, I know I made the right call.
What's that saying about trust?
Trust takes years to build, seconds to break, and forever to repair.
It's surprising to learn that people I thought were so smart could turn out to be this dumb!
Now someone will fork it to "Terrafoam" or whatever and that'll be it. MitchellH's vision and expertise is no longer critical to the project.
I’m curious how this affects consultants and PSOs that might be competing w Hashi’s services business and running terraform on jenkins or whatever.
Cloud: $16.5M (+88% YoY) Subscriptions: $133.6M (+35% YoY) ProServ: $4.4M (+75% YoY)
[1] https://www.hashicorp.com/blog/mitchell-s-new-role-at-hashic...
> Trust takes years to build, seconds to break, and forever to repair.
Don't agree with that. That's really aggressive man. Hashicorp has built some awesome stuff, and tried to make a business based on Open Source. They haven't broken any contracts or done anything immoral - it's their choice.
> 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?
> 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
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
"We require our external contributors to sign a Contributor License Agreement ("CLA") in order to ensure that our projects remain licensed under Free and Open Source licenses such as MPL2 while allowing HashiCorp to build a sustainable business.
HashiCorp is committed to having a true Free and Open Source Software ("FOSS") license for our non-commercial software. A CLA enables HashiCorp to safely commercialize our products while keeping a standard FOSS license with all the rights that license grants to users: the ability to use the project in their own projects or businesses, to republish modified source, or to completely fork the project."
It's disappointing that the non-legal text on the page repeatedly suggested that signing a CLA would help keep HashiCorp projects open source when the actual text of the license agreement made no such claims.
Someone should try challenging the CLA when the pretext of it changes (their contributions being relicensed to non-FOSS). Most CLAs are very dry but HashiCorp may be in trouble with all the proclamations in theirs.
> 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.
This pretty much covers anything they'd need. (I'm not a lawyer.)
Linux doesn't require a CLA for contributions. These open source cosplay clowns do.
We also use CockroachDB which uses BSL, but we're not providing a remotely competitive offering.
I'll likely continue to recommend HashiCorp products (Nomad, Consul, Terraform, and Packer) to anyone who asks my advice, but it's disappointing to hear this change.
We maintain a rudimentary SBOM for anyone curious: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
I’m the Nomad Eng Lead and while licensing is out of my control we have a lot of users in a similar position to you: not knowing what might someday could be construed competition. I can’t make any promises but will do whatever I can to give you confidence that Nomad is still the right tool for your job.
Problem is with the license not the tool. It’s nice that you’re trying to do what you can, but it’s like trying to sell roof insurance to a homeless person.
> I can’t make any promises...
really sums it all up in light of these big changes, and simply put the big picture (aka licensing) is what people build and bet their professional lives on.
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.
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.
- 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:
* 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.
Think how difficult it is to get most companies to listen to your needs, much less ship what you need, versus being able to contribute your own pull request and have it merged.
Why should this mean the source owner deserves any less of a product revenue than the company that won't let you add your own features? It shouldn't.
If you get your feature merged at the long end of a customer relationship / product manager interaction, do you expect that means you should get paid for your feature request or get to keep it? If you write the spec for your feature in code instead of a PowerPoint or Word doc, so it does what you need exactly right, you're still asking them to ship a feature you need, just better specified and delivered sooner. It lowers the overhead both firms waste, which lowers your licensing cost and your cost of delay.
From the viewpoint of a CTO of a mega enterprise -- a vendor that lets me make things work is worth more per month to me than a vendor that won't, and no, I don't expect my enterprise get paid for the vendor accepting the fix that scratches my particular itch.
I think what you say is factually correct, but maybe misrepresents the situation a bit.
The license automatically converts to full open-source after 4 years. Maybe this isn't ideal, but it isn't "big company takes your code and locks it away forever" either.
And if I understand the license correctly, you're perfectly free to use the software in your own open-source projects, and your commercial projects unless they're a re-packaging of Hashicorp's own, etc. We shouldn't act like this is an evil business decision, or like this is morally equivalent to proprietary software that does stay proprietary forever with no apology or caveats.
As a restriction added to something previously open, it’s horrendous. AGPL would be better.
If I contribute to something with a permissive license then it doesn't prevent the company from releasing new versions of the project under the BSL. The only restrictions on the permissive license is the copyright notices have to be included.
I have not and will not sign anything which assigns copyright for OSS (even to the FSF), so it will be interesting to see whether all of that code has been rewritten.
Aside from that, there's still value in contributing to a product you're consuming at your day job: not having to maintain forks. If you can get your feature into the upstream project, less work for you in the long run, it's a win win.
Should you contribute to corporate owned projects in your free time for the fun of it? Probably not, unless you think it will earn you some kind of recognition (resume fodder).
Currently moving from Traefik to APISIX.
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.
1. The article doesn't link to the actual text of the BSL in use. Link it please!
2. In my understanding, all BSL 1.1 are different, and differ by 2 factors: Additional Use Grant and Change Date. Those are both reasonable ideas but I wish they went a step further and the license would be formatted like Creative Comons. That one also provides versions that differ from use to use but you can instantly tell from the title which version is applied. I wish there was an official "BSL 1.1 4year non-compete" name for this with a good general definition of "non-compete" (and a few other common commercial uses to be granted).
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.
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.
"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 it's easy to conclude whatever offensive thing you'd like when you just make up all the details instead of reading the thread or asking questions about the situation!
Anyway this is completely off the rails of my original point, which is that there are multiple kinds of "freeloaders". Some of them actively destroy the thing they're taking for free, which was why I made the Little Free Library analogy. Just because something is "free" (as in beer) doesn't mean there should be an expectation that the thing will continue to exist in that form once abusive bad actors exploit the free-ness of the offering.
We're seeing this play out over and over again across many FOSS projects, and my prediction is this trend will only accelerate.
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?
There are a few realistic paths forward from here, to be confirmed when Hashi releases the full license they intend to use.
1. The Terraform community is large and talented, and we care intensely about open source. There will be a fork that remains open, and I'm hoping we can get all the commercial vendors and interested parties to be joint custodians of it. Like joeduffy says, their arguments are disingenuous, and their taking down of previous videos on their open source philosophy is too.
2. There is likely a Bring-Your-Own Terraform path, letting users supply their own Terraform for executing their code, and a commercial ecosystem that dispatches code and processes response with their own secret sauce. Just like you'd do with GitHub Actions.
3. Meanwhile, Terraform up to 1.5.5 is still open source, it's still amazing, and can still be used with the dozens of commercial tools out there.
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've seen one quote when we wanted to buy Vault Enterprise for peace of mind (we did not need namespaces), and well, it was completely out of reach. Moon prices. No wonder people turn to someone else hosting these products for them.
Business Source License 1.1 - BUSL-1.1 [1]
Sure, it's hard to make money in open source. I spent 20 years doing it. It ain't easy.
But here's the thing: open source also helps you accelerate a business you might not otherwise be able to build. You get market validation by giving away a free thing, and then you hope to be able to collect some revenue on the backend once you've got a large enough user base, a proven product, and maybe even some contributors. Maybe even a whole ecosystem. You think VCs would have thrown all that money at a thing with no users?
Want to throw it all out? Fine. That's your right. But it's not gonna stop companies from forking the last open source licensed codebase and taking your cookies.
Open core is a thing. You can be good at it, and users understand and respect it. You would think that Mitchell would have learned after his failure to monetize Packer that he needed an actual proprietary value prop to build around before he built Hashi. Guess not.
You can't have it both ways.
Open source implies a model of collaboration between different organizations. A single vendor, even with an OSI license, does not an open source project make. And we have only ourselves to blame. Most companies can’t spare their developers for open source development - it’s time consuming and frankly open source is the outlier in how we think about code ownership and development. It’s hard to be a good steward. It’s hard to pitch the upside of such an abstract investment. In the end, actually want vendors, strongly opinionated solutions, managed by a single entity, but vendors we hire to let us treat their code as open and extensible.
I wonder if this era of single-vendor “open source” will be looked at not because it redefined open source but because it changes how we think about vendors, expecting certain types of code access and transparency.
Copyright assignments are put in place for exactly this (allowing a single entity to relicense the whole codebase unilaterally based on their own interests), and we should maybe come up with a better term than "open source" for projects in this situation.
"Open source" has a clear meaning: the source code is open.
It does not imply that the source is free to see, free to modify or free to fork.
I'm pro open source, but I also have no problem that said source is not copyable, redistributable, etc.
To me open source is about _knowledge_ of how something is done. Period.
"Business Source License" is not Open Source. You don't have to release your software as Open Source if you don't want to, I certainly write a lot of non-open-source software for a living. But people/companies want to take advantage of the good-will/reputation that comes from calling their software Open Source, and associating it with really Open Source software, without really making it Open Source. That's sleazy.
I don't care what a California-based "Open Source Initiative" group try to define as "Open Source Definition". That is all lobbying to me.
If I can see the source, then it's open source. The rest is just play on words which only purpose is to entertain sterile debates of zealot groups attempting vocabulary appropriation in a power struggle.
I don't want to fuel these groups' debates around "free software" vs "open source", Linux vs GNU/Linux or whatnot.
You are perpetrating the mind washing game of zealots that try to convince you they have the right to define what is and is not acceptable to their self defined standards.
You keep quoting articles and pages defining what _a specific group_ with a specific agenda has chosen to appropriate as "Open source".
All your sources and Wikipedia pages are ultimately linked to GNU publications. Read the references.
"an open source software license must also meet the GNU Free Software Definition"
That is plain ridiculous.
> it's also been a thing for 20+ years
No, it has never been "a thing". Especially not 20 years ago. Not even the sources you quote date back more than 5 years.
I don't know for you, but I was there 20+ years ago, developing and using open source softwares, and that distinction did not exist. If you had the source, it was open source, whatever the limitations of the license.
You are being indoctrinated.
> I don't know for you, but I was there 20+ years ago, developing and using open source softwares, and that distinction did not exist.
That's really pretty strange ... it was a pretty hot topic back then ... are you sure you used open source software? like linux, freebsd, apache httpd, gcc, bash, samba, mozilla...
The right to use software commercially even if the copyright holder doesn't like you is an important qualification of open source. GPL, LGPL, BSD, MIT, MPL, Apache etc all include this right. It's important. It did take people some time and debate to figure it out ... 20+ years ago.
So, no, I don’t see a CLA for an otherwise open source project transforming it into something other than open source.
And, if it did, we’d have to have a serious conversation about the “or any later version” clause of the GPL and how it makes all software using it not open source.
I was referring to people's understanding of what open source stands for, not what it actually means.
However, I can say that I personally dislike the fact that GNU projects require copyright assignments too, and that they were able to relicense all their projects from "GPLv2 or later" to "GPLv3 or later" unilaterally. I'm more willing to give the FSF that blank check than commercial entities, though.
Also, the "or any later version" means the recipient (user) chooses, not any single controlling entity.
It always feels scummy having to assign copyright for my own contributions to a big company.
For the next two years, HashiCorp provided virtually no enhancements to TFC except cosmetic changes. I submitted feature requests for small and large challenges. Sometimes I was even met with argument. Meanwhile, several competing services were born, likely out of necessity of their own founders. Ultimately I had to switch and about halfway out the TFC door they announced their bizarre pricing model changes.
HashiCorp had years and years to build a quality commercial product on top of Terraform but squandered the opportunity.
At first this reminded me of the Docker arc but it may be more like Chef.
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.
To be honest I'm not a huge fan of the wringing about the OSI definition, but it exists for a reason. This whole article is just another example of corporate gaslighting. If you don't define this and prevent that definition from being acquired, you're going to keep having CEOs define open source on how they 'feel', and you won't have the 'spirit' of open source at all.
I mean it's literally the BS License. You really can't even make that up.
There's a pattern here that, person builds an open source product, gets corporate sponsoring, funds a company, then suddenly the open source product steers away from open source because it's upsetting the corporate sponsors.
If you're so bothered by others using your work and not giving back (something that is ENTIRELY allowed by FL/OSS licenses), why make it open in the first place?
It kinda passes the image that these companies want to benefit from free work, but the moment someone uses their product for free and doesn't give back, it's just a nuisance for them.
as always, the hobbyist linux hacker is the problem (/s)
On an unrelated note, I've always loathed their antagonistic approach to users and hope their company dies so the industry can standardize on less crappy cloud configuration management tool. But unfortunately incumbents take a very long time to defeat.
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.
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.
Specifically the part in FAQ which says "internal production use is fine", but then license says that "non-production use only" and then "You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.".
IANAL, but even to me this statement is full loopholes. WHO do we consider 3rd party? WHAT do we consider "hosted or embedded basis"? WHEN do we consider it "competitive with Hashicorps products"?
Looks like it stays k8s + pulumi + ansible for me.
I do think they’ll be able to benefit from this though — serious businesses that derive value from their offerings should be comfortable paying more/something for the value they’re receiving.
If Hashicorp changes all the licenses of the providers they maintained, then that's fine -- I have no right to demand free work from them.
I would be worrying a lot more if all my automation was built on Terraform, Consul, and Nomad, though -- and I'm glad I didn't do that.
"Open Source" software always have been loved by companies because it provided extreme flexibility (closed forks, forks for customers, secret sauce addition, etc.), plus announced the message that their code is free for all, given there's no warranties.
These companies have skipped more nuanced licenses such as Apache, MPL, EPL even GPL in some cases, trusting that every actor in the software landscape is rational and ethical.
The idea was nice, but it involved humans.
After a couple high caliber forks, HashiCorp indeed felt the pain, and reflexively they moved to BSL.
What they forgot is their initial license has been designed to allow this in the first place. MIT/BSD/Expat is not suitable for monolithic code bases of this size, but people won't listen.
On the other hand, the code is HashiCorp's. They can do whatever they want with the code they write and put out there. They decided to change the terms they share their license, and nobody can say anything about it.
Is it ethical? No. Were the forks were ethical? Depends on motivation.
These things happen when you choose a license without much consideration for the future.
Maybe we shouldn't abuse Open Source software this much and embrace "Free Software" more, but this is just me.
So, at the end, "market forces" abused HashiCorp and, HashiCorp reacted. This is a normal impact/response event. Nothing extraordinary.
Edit: While one may argue that this is also similar with RedHat/IBM, The impact of the change, the number of broken promises, ecosystem dynamics and the motivation behind it make it different, yet I don't want to double the size of this comment.
Good news: Pulumi is also entirely declarative. The model is what matters in this regard, not the syntax used to express it.
To add to this, having the full expressive power of a programming language for syntax is the way to go. When you have to add explicit looping in your DSL, it’s time to not use a DSL.
HCL is my least favorite part of the hashicorp ecosystem.
Also it’s not like you have to take my word for it — the trend towards CDKs shows that pulumis approach was right. They were just early
When you write a Pulumi program you’re effectively creating a DAG in memory. The resources will be created in whatever order and with the maximum parallelization the dependencies allow.
The other aspect of this is how it adds another requirement to your project - the setup and management of the language environment for the target language. Suddenly you've got another npm/bundler/etc. lockfile to keep up to date, your CI container images are double the size, your developers have another thing to fight homebrew to cooperate with...
Vendors like Hashicorp, that take advantage of contributors who give away their work(PRs) under the MPL, only to then have this work relicensed to a different license?
Hashicorp could just request the source code from those "vendors" (after all, the MPL has copyleft) and integrate their changes. (They have to be users first but this shouldn't be that big of a problem).
I wonder who the freeloader really is. CLAs should not be accepted. Ever.
1. Build a nice product, scream open source everywhere. 2. Get users to buy in on all the niceties, perhaps even nice contributions in terms of integrations and such(that people probably would not have cared for if it was some niche closed source product with much fewer users) 3. Once they are established enough, and people have gotten used to the learning curve, change the license and try to lock in as many users as they can and ignore the loud few who scream foul.
Some other product comes out to fill the void and they do the same as above..
https://github.com/hashicorp/vagrant/blob/main/LICENSE
Looks like it converts to the Mozilla Public License after four years:
> Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.
Open source seems to be evolving from being truly open source to being a variant with financially driven contingencies. HashiCorp have created great OSS over the years and am grateful for it. I understand their intention behind this move, but having a financially driven motive drive their OSS is not a good thing. I'd rather they not open source any of their code than put such limitations on it with these licenses.
One of my weekend projects https://tfstate.com is intended to aid with statefile configuration drift detection. Which (I've since discovered) is also something that Hashicorp offers as a service.
I feel worried.
1. Under the hood, it runs the terraform binary.
2. Receives API calls from the terraform binary.
3. Uses a modicum of code from the terraform cloud SDK.
I think I've answered my own question with (1), which may constitute "hosting" or "embedding" a Hashicorp product.
> To release and publish the HashiCups provider to the Terraform Registry, you must publicly host the source code in a GitHub repository you own.
without the FOSS part. Do you have a different link?
also, for future generations, the permalink(?) is https://github.com/hashicorp/terraform-docs-common/blob/e4cc...
On the contrary, I think Terraform will survive in form or another. Either the BSL license will be lenient enough or people will fork Terraform and support it.
That said, I guess time will tell. I doubt the license make such a big difference. Hashicorp cannot be that stupid (to offend the open source community). Also, a product is not necessarily "dead" even it's mostly used by corporates.
Also, let's keep in context that HCP has an Accumulated Deficit of .8 Billion dollars, and it loses 50 million a Quarter, they're nowhere near becoming profitable, and changes like this, switching from MPL to BSL is just the beginning.
They now have a shit ton of code across all their projects, and they're never going to be able to maintain it all, given their need to make profit.
I'm not going to write a story for you explaining everything in detail, sir.
It's just some forum where I can freely voice my opinion. It doesn't need to be backed by a book of reasons, nor does my loose opinion in such a context undermine my integrity in the slightest.
Cheers
I know of at least one massive global company using vault in production, for free as a backend to their own password manager frontend.
My own $dayjob was just going to set it up actually, I guess we'll have to re-evaluate that now.
I can't even imagine how many companies use vault in production.
Using it as a backend for a password manager... more of a grey area, but Hashicorp doesn't offer a password manager.
But if you're, say, fashion retail, or something, then the risk is pretty low.
And then Amazon buys Hashicorp.
Clearly states that you can use it in a production setup.
They've all used Terraform extensively but always rolled their own means of deploying IaC, with solutions more clunky than CloudFormation which let's face it isn't brilliant.
Why did Hashicorp fail to win this business? I think their pricing just seems too outlandish and is based on paying for the value of software they've already open sourced rather than being tied to the cost of providing a good service plus reasonable margin.
Their strategy appears to have failed, exacerbated by the macroeconomic landscape. I doubt their chosen solution - Microsoftification of their open source project - is going to do them any favours.
Maybe the new effort is going into AWS native provider but I really doubt the default AWS provider is getting enough attention.
The "Licensed Work" parameter should refer to what they are licensing. Right now it reads "The Licensed Work is (c) 2023 HashiCorp, Inc."
I don't see how a corporation itself is copyrightable content to which a license may be granted.
Having your use of something important hinge on this one awkward sentence seems kind of scary. It's unclear to me whether, if you use (say) terraform for production infra, and someday HashiCorp releases a new product competitive with yours or merges with your competitor, your use of TF is then in violation of the license. "Offering the Work" is not defined and seems like it could be interpreted in different ways.
https://github.com/hashicorp/terraform/blob/main/LICENSE#L8-...
I feel especially privileged to have lead the Heroku Add-ons/Ecosystem team at a pretty pivotal time in devtools history. There was a sudden emergence of people/companies inventing entirely new things (e.g., databases, logging systems, telemetry, etc.) and so much of it was OSS. The overwhelming majority of these companies took the approach of "we'll make this thing free and successful, and we'll build a business off the back of enterprise support contracts and maybe some feature discrimination in a private 'enterprise' version" (e.g., clustering/HA support). I think in part it was because back then the only open source success story anybody had as a reference was RedHat, and cloud adoption wasn't as ubiquitous as it is today. Certainly not in the enterprise segment. So in the vacuum that was left emerged a whole industry of smaller startups that would provide said technology as a managed service. Go check out the Heroku Add-ons Marketplace circa 2012-2015 to see what I mean. Belatedly the creators of these technologies realised the enterprise support contract business was a terrible business to be in, and realised managed services was where they should have been all along. Absolutely none of these companies had any problem muscling in on the ecosystem of managed providers that had contributed to their success in a meaningful way. Some of the startups got acquisition offers on pretty lowball terms, others were essentially forced to accept partner terms that were so onerous it was doubtful they could ever turn what they'd built into a successful high growth business now. Many saw the writing on the wall and found an exit at a larger cloud/platform company that could roll them into their broader product portfolio.
Fast-forward a few years and AWS starts offering some of these technologies as a managed offering (disclaimer: I later worked at AWS for a couple of years). Suddenly these same companies don't like having similar market pressure exerted on them, and so begins the slow trend of license changing away from APL/MIT/whatever towards something that is trying to neutralise a legitimate competitor. Rules for thee, not rules for me.
My time at AWS gave me some new perspective on this whole sorry saga though, some things I'd observed but couldn't quite articulate why it didn't feel right. AWS taught me that at a certain level of scale almost everything ultimately becomes a logistics challenge. Trying to ensure that the infrastructure that's supporting tens of thousands of customers globally is constantly running, highly available, able to support the continued growth, etc.? It's as much a problem of capacity planning and co-ordination as one of software. And the more successful you get the less the problem becomes the specific nuances of running a given OSS product and the more it skews towards just knowing how to coordinate millions of anything.
What this surfaced for me is that in the vast majority of cases that I was personally familiar with, the companies in question barely used their own products. I don't mean in way that suggests they didn't believe in their value. It's just that their day-to-day needs of building said product very rarely intersected with the need to be the most sophisticated user of said product. They had very limited experience at operating it at scale, they all had customers (or managed service partners) who had orders of magnitude more experience about the realities of operating it. And high on their own hubris they'd decided that because they'd invented the technology they were now suddenly expected to be the world leaders at running it. They weren't. And they were never going to be, because the moment you hit that inflection point of success AWS/Microsoft/Google/so many others are better at running software than you are... and a license isn't going to change that reality. The "we'll run this for you" is just a bad business to be in.
A better business is "we'll provide you a UX and workflow and features _on top_ of that thing that makes it even better". There's a whole industry of companies who exist solely to make your AWS bill comprehensible, because AWS are organisationally incapable of providing good UX for most things. In it's most reductive and cynical take Heroku is "just" a UX on top of the core AWS commodities, one that has been largely unchanged for 5-10 years depending on who you want to ask (the slow decline there is a whole separate topic).
Which is why I was excited to take on a product leadership role at HashiCorp to help launch Terraform Cloud a few years ago (I left last year). Here you had an OSS product with a big community, and a set of features and capabilities that extended that to try and make it even better. Especially in situations where you're having to work with other people or across multiple teams. The fact that Spacelift, Scala, Harness, Pulumi, Terrateam, etc. existed didn't bother me much. If they copied what we were doing it was often good validation, if we lost a customer to them it was a good data point for things we were lacking or needed to fix, in some cases they just had wildly different takes on fundamental things which were a great reason for some self-reflection and to question why our conviction on a different way was so strong... were we right? How did we know?
OSS is good for so many reasons, but as a product person one of the things I loved most was the way it could help shape what the product could be in the future. Because of the ecosystem that erupts around it. You've already got such a huge advantage as the steward of the project, the most recognised brand in the ecosystem you created, the brand recognition in an enterprise conversation, and so with all of that head start I felt like we should just win on our merits. And if you can't win given all of that advantage then maybe you don't deserve to.
This only affects people who are directly competing with hashicorp using hashicorps code. That sounds like a reasonable thing to want to prohibit.
Why should hashicorp have to spend tens of millions on product development only for a competitor to spend zero but be able to offer the same product? That sounds like a net negative for the whole industry as it disincentivizes R&D
More here: https://www.weave.works/blog/statement-for-terraform-hashico...
Companies want it for free, and individuals don't have enough luxury time to be able to do it themselves.
Prove me wrong and help patch or fund https://github.com/purpleidea/mgmt/ and you'll have an even better replacement for terraform!
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 ?
Microsoft does it too but they don't pretend to care about software freedoms.
I've been tempted to try and put together a terraform cloud alternative myself - whilst I enjoy using it, the pricing is pretty expensive if you have many state files.
There's a license that actively prevents this. It's called the GNU GPL.
Has anyone here identified any forks that predate the license change?
Not everything has to be _free_. The major benefit of OSS for many is that you can read the source code. The major benefit of paid SaaS is that things just work and you pay for that. BSL can be the perfect combination of these.
The main issue I have with the BSL is opensource-washing were companies basically release an open source product which become popular because it is open source, and then do a bait-and-switch and relicense it under the BSL restrictive license, but still claim "it is open source" which is a lie.
The anger is at a company that trades on the benefits of open source, and then shuts that down when it becomes inconvenient. People think they're free-loading on the contributions of others.
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.
Does anyone know of a similar tool?
I'm interested only in the ability to manage environment variables with a web UI, and have processes restart gracefully on change, everything else consul provides is not of use to me.
Any suggestions?
You'll end up writing some glue code.
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.
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.
Employee A: But what about the community?
Employee B: ..Aaand it's gone!
You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.
But similar to the GitLab Sentry backend API (e.g. https://gitlab.com/gitlab-org/gitlab/-/blob/v15.0.0-ee/lib/a... ) the Terraform state endpoints are also in Rails, just like all the rest of the Internet facing GitLab API: https://gitlab.com/gitlab-org/gitlab/-/blob/v15.0.0-ee/lib/a...
as an additional "FWIW," the TF docs even claim they welcome alternative implementations of registry.terraform.io although I'm guessing one quick git commit and that language could disappear, too: https://github.com/hashicorp/terraform-docs-common/blob/e4cc...
I actually went to look that up because "who, exactly, are they envisioning making a hosted copy of Vagrant?!" FFS
I hope these contributors yank their PRs https://github.com/hashicorp/vagrant/pulls