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