High level, times have changed. Source should be (my two cents, ymmv) about a mutually beneficial partnership between builders and users, not “give it all away for free or you’re not legit.” Users get to understand and extend what they’re running (via source), while the project steward/maintainer/owner can continue to do so.
It is a balance to be maintained in tension, not an equilibrium to be reached.
That sounds like what the GP comment is saying. If someone said "turns out open source doesn't work for our business model" it's hard to argue with. If instead they talk about "evolving open source models" and whatnot, it feels like they want the best of both worlds. It's been happening a lot recently that companies pretend they are "open sourcing" something for the PR but really use a much more restrictive license.
I don't think this is happening at all. Open source means the same thing it's always meant. Some people are just retreating from open source. Which is fine, they should be writing Free Software anyway if they want the world to have it, or use proprietary licenses if they don't. Otherwise very wealthy people will live on your back.
But :shrug: I guess different people care about different things, is what I've realized watching these discussions unfold.
But I do think this purist perspective on open source is just going to result in more Snowflakes and fewer Hashicorps, because why bother with this fight?
Orgs like Hashicorp clearly think they benefit by pretending to be ope source.
They could simply stop being disingenuous about their source available proprietary software, and nobody would stop them.
But while that's what I think, it isn't at all the view espoused here by Hashicorp. They aren't claiming this is open source. They are accepting the OSI definition and not claiming their new license falls within it.
They aren't being disingenuous. You're putting words in their mouth, and then getting mad at them about those words they didn't say.
No, they say open source needs to evolve, the implication this is an evolution (not devolution) of open source.
Their announcement talks about how they spoke to OSS experts. That's not relevant: the experts would simply have said: that's not open source.
Hashicorp several times say the BSL is permissive. Permissive is a well established term in software licensing. No, the BSL is not. The BSD and MIT and Apache licenses are permissive.
Finally there is this claptrap from their FAQ:
> 17. Does HashiCorp still believe in open source? > > Yes. [...]
"implication"
> the experts would simply have said: that's not open source.
Presumably the experts did tell them that it is not an open source license, which is why they chose not to claim that it is.
> Permissive is a well established term in software licensing. No, the BSL is not.
I think BSL easily fits the bill for the word "permissive".
It's just all so much gatekeeping, and it's really tiring.
Because companies keep bringing this fight.
Companies will naturally conclude they should just make proprietary software, which doesn't require a big fight. And I think that's a shame.
How many of these companies could exist if all these projects underpinning their own swapped to the SSPL, BSL, etc? And I don't mean now - once you reach a certain size, if you have to replace a bunch of dependencies, you have the resources to do it. But when these companies were smaller, would they have been able to create their own implementation of all these dependencies and still get their product to market? Would they have had the resources to commit to all of it? Would they have had the money to pay for non-FOSS options?
How many of these projects would still exist if the community couldn't commercialize them? We're not even talking about whether or not they ultimately end up contributing code back, etc., because it's not like these licenses give you some threshold of code contribution after which you can commercialize it. Sure, the possibility exists of some special private licensing agreement being struck, but that's possible with proprietary code, too.
Source available might sound fine from a personal use perspective, but it ignores the fact that the environment that made all of this possible would not have been possible under that model.
To me, the difference is that these are all building blocks rather than standalone products. I think of these commercial products as making sense for standalone services, rather than libraries and other building blocks.
But also: I think the business model that built all those open source building blocks has always been pretty shitty, relying on a lot of altruistic un- or poorly- compensated work from people. And I think that's bad. But I don't think demanding that companies making useful services also be subjected to a shitty business model is a good solution.
But, let's take just apache and nginx as an example: Lots of people offer just webhosting as a service. It's gotten less and less common now, with things like Squarespace, Shopify, Medium, etc. etc. etc., but once upon a time there were tens of thousands of companies that were making all their money by providing storage/compute/networking and a place to upload your HTML files, and then later adding in additional services like PHP and other scripting languages, MySQL for database hosting, etc.
Now, the context here is a bit different here, of course, particularly for Apache httpd. But Nginx has Nginx Plus, MySQL AB would license you a closed-source version or do the usual support/consulting/etc. stuff. But it's not hard to imagine a world where they could have easily said "Hey you know we're experts in running this stuff, we should just run it for people and charge them" - just like we see with a lot of these "open source" companies today.
There was never a general outcry about tons of businesses making money just hosting these open source services, even though the vast majority never contributed financially or otherwise to these open source projects. The only real difference I can see between then and now is simply what path the companies behind the projects, where applicable, have taken to monetize. Would the internet be a better place if MySQL AB moved to offering hosting as a service and put MySQL on the BSL, preventing all of these webhosting companies from having existed? If F5 had done it after acquiring Nginx? Cheap and plentiful webhosting is a big part of what grew the internet so quickly, particularly before the 'Web 2.0' days of social media sites centralizing so much of the traffic on the internet into a handful of places.
> But I don't think demanding that companies making useful services also be subjected to a shitty business model is a good solution.
Well, I'm not demanding a company do anything. I'm just saying that the internet as it exists today, including all of these companies we're talking about, would not exist if earlier on people had made the same choices they are. Open source is not about guaranteeing a viable business model to companies - it doesn't care about your business - it's about ensuring certain freedoms in software. And the internet we're discussing this on exists because of those freedoms it guaranteed.
If you can't build a viable business when abiding by those freedoms for whatever reason, then sure - go build proprietary software. I'm not going to call it or you evil. But I do take issue with a company using open source as a method to gain adoption, additional contributions, mindshare, etc. and then no longer being open source while talking about how they are an "evolution" of it. You're not an evolution of open source if you're removing freedoms.
Yes, the FSF has a general preference that people use copyleft licenses like the GPL, but they recognize that permissive licenses meet the Free Software Definition.
The difference between free software and open-source is a matter of marketing. Open-source is a way of presenting free software to businesses and investors. Free software is an unabashedly political movement, openly concerned first and foremost with the public good. But the licenses themselves and the software itself, those things are identical.
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.
Only if we let it, and stop shouting about it and finding alternatives every time a company does this.
This isn't a new thing; companies have been trying to play "almost open source" games for decades, and they'll continue playing those games as long as it either works or doesn't have sufficiently large penalties for trying. (Much as companies will continue violating copyleft licenses as long as they either get away with it or the penalties for trying are simply an expected part of the risk.)
The best possible response to a company doing this is that someone forks the code, starts or expands a competitor, and the original company's revenue drops massively as a deterrent.
Example of the last time this worked?
https://investor.oracle.com/investor-news/news-details/2023/...
Oracle decided to make Hudson commercial, it was forked and Jenkins is still around but Hudson is dead.
Turns out Jenkins development needs to be sponsored somehow.
but still manages to suck the air out of the room when you want Elasticsearch because AWS already has the company's billing details and no one wants to figure out paying another provider.
We've had "source available" for a long time, which means something else.
I don't disagree that people may still use SA software more as time goes by, but I would argue that when possible people will prefer open source controlled by entities that keep it such.
I’d kill for your confidence
This has been the case since the 2000s, as companies want the branding without the openness. This is extremely well worn by now.
I argue that companies who want it both ways are continuing to throw up chaff. But we know this chaff extremely well.
None of this discussion is new. "open core" has always been a euphemism for "proprietary."
Yes. And in some ways, source available licensing is a nicer model for proprietary software than open core. At least with the former you can actually see all of the code to inspect how it works when something is broken.
Bleh. Every business wants to build on software freedom but they don't really want to see others freely build on their own software.
perhaps according to Hashicorp's marketing team, otherwise I haven't seen any evidence this is the case
https://fossa.com/blog/open-source-software-licenses-101-agp...
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.
inbound=outbound license terms is a good norm for FOSS. Why should a software vendor play by different rules than everyone else when it comes to things like copyleft compliance?
[1] https://meshedinsights.com/2021/06/14/legally-ignoring-the-l...
[1] https://sfconservancy.org/copyleft-compliance/principles.htm...
I don't know enough about their operations to have good suggestions on how to become sustainable. But, I don't like this move. There are many sustainable open source companies. Moving to source available from open source will likely never be a move I like.
What are some examples?
And Hashicorp + Red Hat managed to make it work as open source companies for >10 years also
There are many more "open core" companies, like TimescaleDB, Docker, etc, who then sell proprietary services on top of the open source software
> pretty much every crypto company in the blockchain/web3 space
The entire "space" has yet to prove to be sustainable. Most of these are hype-driven borderline scams, I would not list them in a _sustainable open source business_ context :)
Firstly, I don't have a problem with BSL. I do think in general it's a bit of a slap in the face to build a business on the backs of volunteer contributors, and then close-source all your codebases which are comprised of their work.
Sure, when people contributed, they signed a CLA which gives Hashicorp the right to relicense the work (which has legitimate uses outside of killing open source, such as giving them the ability to make that software available under other terms in addition to their open source offering)
But when as little as a year ago they promised "We remain committed that the core of our technology will always remain open source." (https://web.archive.org/web/20220703202305/https://www.hashi...)
it gives whiplash to the people who contributed based on that promise.
Actually, I don't even know if this is legal, but even if it is, it's a huge violation of the trust of outside contributors to their software products.
> The entire "space" has yet to prove to be sustainable.
I agree that it's unproven, but this downturn has made apparent that so are the majority of software companies which have not IPOed and shown a sustained profit for 5+ years.
I'd give Uniswap pretty good odds of outliving the majority of YC startups.
The majority of YC startups are definitely not sustainable.
Probably even most of the successful ones are not sustainable, they make empty sustainability promises hoping to get bought by <BIGCORP> and end up on "our amazing journey" lists.
But a surviving project moving to BSL is still clearly better then the company going under and the project ending in limbo.
Even with BSL you can still access the code, audit it, learn from it, fork it to keep your own patches on top and keep up with upstream, etc. Huge value compared to closed source.
SUSE is a niche player that was bought out in various forms a number of times.
Canonical is largely a billionaire's toy and hasn't published financial numbers in half a decade. They were losing money last time I looked at them.
Don't know Prisma.
Gitlab is losing money.
For the crypto companies, let's hold off on any of that in terms of "sustainability".
Look at the top 20 software companies. How many of them have open source their core product, their main revenue source?
GitLab (Enterprise) is also proprietary software.
> And Hashicorp managed to make it work as open source companies for >10 years also
You mean they lived off VC money for >10 years?
> There are many more "open core" companies, like TimescaleDB, Docker, etc, who then sell proprietary services on top of the open source software
As above. Since when is Docker making lots of money?
You're not free to decide your source available model is open source and reap the marketing benefits of open source without the costs.
That way all the "it's not really technically open source" complainers couldn't day that its not technically open source.
It wouldnt substantively change anything of course, but that's somewhat the point. BPL/EPL/SSPL was always fully within the spirit of open source, it just pissed off the same large corporations who also can't stand the AGPL.
BPL, EPL, SSPL are all "not open source", and AGPL+CLA is "we're setting up for a bait and switch with not open source versions".
This was all hashed out years ago in numerous flame wars on Usenet, as I’m sure you know.
Which is fine imo as long as the moment they pull the bait/switch they stop calling it open source (and others can fork at that point)
I view that as a very different question from whether its ethical to advertize something agpl+cla as being open source.
It literally is not, and they only exist in order to not be.
The one restriction is that you can't compete with their hosted services using their software. Which 99% of people who use their software have zero interest in.
The "it's not fair! it's not real open source!" narrative is pumped up by companies like Amazon that feel entitled to use their monopoly power to leech value from these companies by selling paid versions of their products.
It does affect the the richest, most abusive corporations though.
It isn't just the need to eat. There's also the issue of keeping investors happy and their continual drive to maintain growth or earnings at stratospheric levels.
Strict IP laws are the only safe way to do that, and that is why so much software has leveraged them over the years. The internet era felt like an aberration for a while, but things seem to be shifting back to high double digit margins as the only desirable goal.
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."
This seems too black and white. Don't their customers get value from having source code available, even if there are restrictions on how that source code can be used?
For the most part, no, the main direct customer benefit comes from the absence of lock-in with regard to maintenance and services thar results from the absence of usage restrictions.
There's some potential indirect ecosystem benefit for customers from the somewhat lower friction for partners in some source-available-but-use-restricted situations, but otherwise for most customers its the same as any other proprietary license.
I worked for a company a lot of years ago that had BSDi licenses for some of it servers and had paid an extra fee for source access and that -did- actually come in handy to me once or twice.
Later, the same went for the Radiator RADIUS server where you got source access automatically with a license purchase.
White box versus black box debugging is absolutely something that can make a difference, especially when something goes wrong.
Yep. I've definitely noticed this at work with some proprietary ('open-core') software that we use, and it's made me inclined to prefer source-available proprietary products over more restrictive proprietary ones as well. It's not as favorable as actual F/OSS, but it definitely makes a bit difference nonetheless.
> On 29 November 2021, HashiCorp set terms for its IPO
...I'm starting to think I'm onto something. (I do welcome anecdata that either helps or hurts my hypothesis)
I firmly believe this is a fact too.
One place I recently worked, I joined as it was going public and it went downhill quickly. The friends I’d made there talked about the fun perks, holidays and benefits the company was known for. Over the space of less than a year most of the culture atrophied, people left in droves and there were exactly zero holidays or perks given out.
Quarterly scope for fiscal data is one of the most short-sighted decisions humans have ever done. Expecting quarterly up-and-to-the-right, where simple sustenance is not enough, but profit must grow quarterly, on a planet with finite resources in an economy with finite money, is a guaranteed, zero-exceptions, recipe for failure, by definition.
If I were starting a business these days I'd be tempted to found it on the basis that 60% must be owned by employees of the company until the last living descendant of king Charles dies.
Making it seem like it's a legal requirement however is a very good thing for all the corporate raiders out there.
Their stock was down 60% only 3 short months after IPO.
I think this is just a struggle to turn what was once technical excellence into something that gives money. I haven't followed HashiCorp lately but was once a fan of some of their products. These days it seems things are slower over there. At least that's what it feels at a distance.
That's a scary thought.
The vast majority of tech companies that IPOd since Facebook have been a disaster of an investment.
They need more open PRs? It's not like these contributions would necessarily be welcome.
Which, of course, is obviously false. Which means the words have different meaning than what you ascribe to them.
Source available means you can view the source code, by abiding to the terms the owner of the code sets.
Closed source means you can’t change or redistribute that source, regardless of whether you are allowed to view it.
This just means it's Source Available to certain customers - Closed Source to others.
I agree that universally available "timebomb open source" "Source Available" is different from "Closed Source", though.
It allows for certain risk planning, like: If HashiCorp goes away, we will be able to host and patch (and keep using) product X for the foreseeable future - along with the ability to actually read the code and determine if it is something worth touching with a ten foot pole...
That is the spirit of Free Software (ie restricting users as little as possible) Open Source is much smaller in scope.
So restricting competitors is as much against the OS spirit as it is against the FS spirit.
The blog post is disingenuous. We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin.
Thankfully over time, they already pushed responsibility for most Terraform providers back onto their partners, so I'm hopeful the ecosystem of providers can still stay vibrant and open.
We are deep believers in open source---heck my last project at Microsoft was to take .NET open source and cross-platform, our CTO helped found TypeScript, and Pulumi is an Apache open source project---it seems HashiCorp no longer is.
The bald faced disingenuous nature of this change here is wild. They can't compete at their pricing because their pricing is absolutely insane over what the market can bear and they refuse to accept it.
They are going out of their way to make it less expensive to stop using terraform altogether right as so many new options have entered the market
In other words: if you hard fork now, you don't need to pay.
I love the ethos of open source and have spoken at and helped run conferences, and had the pleasure of being paid to develop it - but the productivity I had when paid ten hours a day to work on OSS compared to whenever I get a chance between work family and everything else, well, it's better for everyone to get paid and release code, than not get paid and not write the code.
I see these semi-commercial licenses as the equivalent of a legal "just don't take the piss".
Would be interested in your side of the question. How do we keep on developing the code as well as keeping it open?
Pulumi is one of several products where I like that it’s open source in case I need to move off their cloud, but hope that I don’t have to (Plausible is another).
Said well (and thank you for being a customer and valuable member of our community!)
The analogy I draw sometimes is that our open source infrastructure as code SDK ("Pulumi") is like Git, and our commercial offering ("Pulumi Cloud") is like GitHub.
Like GitHub, the Pulumi Cloud offers valuable features that go beyond the open source project for teams looking to manage lots of projects securely at scale, but we definitely love our open source community and want folks to have the choice to use Pulumi however makes the most sense for them.
This approach also has the nice consequence that we can be fully transparent with our community at all times while also building a strong, long-term business. If a new feature is part of the infrastructure as code SDK, it's open source and free; if it's part of the Pulumi Cloud SaaS, it's part of our commercial offering. This avoids needing to do things like artificially hold back features (like open core) or violating our commitment to the open source community (like Hashi's new license).
1. I can read all of the code, modify it, and self-host it for my own purposes, but the license disallows me from re-selling it.
2. I can read, modify, self-host, and commercialize a subset of the code, and the rest is an opaque SaaS.
To me, as a customer with no interest in re-selling this code, I don't see how #2 is better than #1 in any way. And I find it incredibly mystifying that I keep seeing companies ragged on here for doing #1 while the model in #2 is somehow held up as the paragon of ethical virtue or something.
Can you help me understand? Why is it better for me to be able to read less of the code I'm running?
For #2 in good faith using the github model here,
Sure there’s Git and Github. Also sourcehut, using google cloud source repository or any managed git service.
Either 1) I need the software and I can have a team maintain it.
Electing for the software-as-a-service vs self hosted model is in itself.
1. I can compute, resources, maintenance and time The proprietary or a version of the product myself or a fork and get the feature functionality from other open source or provider.
2. Pay for the GitHub licensing cost and using the service and ok with magic abstractions to operate the software. (Which admirably lately has been bad.
Also frame it as from the beginning of the git project elected to also build all the same parity features, would it be the same tool, be the product that exists, or brain share it has today. Maybe not.
I maybe misunderstanding you here but in these cases opaqueness is part your trade off to offload fairly complex for a marginal cost that’s s decision by you.
What I like best is to use a fully managed service that I can contribute changes or even self host a modified version if that's what I need to do to get what I need. But I don't want to self-host. But I highly value the option. And I highly value the ability to go read the code when I wonder "hmmm why is it doing that?" and maybe contribute a bug fix if it shouldn't be.
All of this works great with model #1 - with full "source available" with a license that limits re-sale - but is limited with model #2, where it only works for the "open core" portions of the product, but not the proprietary SaaS portion.
If you want to build something with a bunch of smart people for a long period of time the outcome is raising venture capital, paying people salaries that are competitive to share holders, and won’t implode. The bsl is a consequence of that but it is a rule to guard from the few bad apple in this case.
What’s ethical or virtuous or perfect is very nuanced
SSPL is unacceptable for me because it have its restrictions last forever.
https://learn.microsoft.com/en-us/azure/azure-resource-manag...
Not sure how I could "misunderstand" this quote to mean anything else.
By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.
surely, state needs to be tracked somehow. what would an alternative even be?
I'm sure there are complications i don't care to see here, but why is "this is what is actually deployed" not the default case?
Refreshing the state file (and reconciling differences) also uses the cloud provider API’s. I don’t think we’re going to get better than that.
Unless someone makes a common standard for resource reporting that all cloud providers implement.
that’s part of the case for a centralized state, to have an additional place that describes what should exist and what it looks like.
Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.
also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.
infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.
totally possible im missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.
I work at AWS in Professional Services until tomorrow. I worked with the SA and had meetings with the service team responsible for the AWS Service in question to discuss the API shortcomings that we needed for automations. He contributed to Terraform once the APIs became available from our service team and I wrote the equivalent CloudFormation custom resources for a project (and open sourced on the public AWS Samples GitHub repo after going through the approval process) as part of a larger project.
I found a bug in the underlying service API that affected both my implementation and the Terraform provider my coworker wrote. I posted a sample in our internal Slack channel where the developers of the AWS service hang out and they fixed the API bug relatively quickly.
My coworker, had no problem getting his TF code merged in. I know the code he wrote and I went to the GitHub page before posting this and it is in there.
Later as native CloudFormation support, I replaced my custom resources with the native equivalent as part of the larger project I was working on.
There's probably not much AWS contribution to the core of Terraform from AWS, but there's very little contribution to that from anybody outside of HashiCorp because contributions happen on the providers.
AWS is definitely involved with their provider though. AWS ProServ built out a whole account vending machine thing that was in Terraform (the name escapes me atm), and various other service teams and SAs are regularly involved in contributing to and growing the Terraform ecosystem.
It would be super disingenuous to imply AWS is not contributing to the success and growth of Terraform.
OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.
Sometimes it's not even obvious for external contributors, but there may be some small overlap with other paid features that are part of their product roadmap.
If a project on Github only has maintainers from the corporate side, you can be certain that they will ultimately drive the product for their own interest solely.
We should always pay close attention to the governance model of projects we depend on or that we wish to contribute to.
The only way to know for sure is to dive into the merged and unmerged PRs and see how they were handled.
To not lose control you need to have people assign copyright which is generally a headache. I've only heard of the FSF doing that .. (not sure why this hasn't been streamlined electronically somehow)
Fair enough, let's see the PRs so we can judge for ourselves.
It's not comparable.
Not that I don't appreciate the effort. I'm sure what has been achieved involved a fair share of convincing too.
[1]: https://isdotnetopen.com/
Being in the Apache Foundation gives me all the assurance I need alone, though.
So without defending the change they -have- made, that doesn't seem like where you're going to run into problems as a result of said change.
It sounds like a Terraform alternative, but looking at the website it doesn't really convey if it's a Terraform fork or ground-up re-write, or something else?
Maybe not all their providers utilize Terraform, but it was definitely how their product started out. When you run Pulimi using their AWS provider and get errors at runtime, some of those are verbatim Terraform errors.
Their docs and site is very clear to muddle this connection but if you ever used their API, you'd know this.
Pulumi being open source while Terraform is now proprietary cements that.
I don't know if the license change actually means providers will not be able to work with Pulumi, but if it does, it seems risky to use Pulumi even for personal projects if newer provider versions (i.e., versions that work with newer products released by the cloud provider) will not work with Pulumi, it's a dead end. And that's not to mention the useful providers that aren't cloud and completely community developed that will not have the resources to maintain two codebases in any case (I'm thinking of Sendgrid).
I looked at terraform-sdk license - it still seems to be MPL. I think this means that all providers can continue to be open and work with both platforms, it will be important for Pulumi to clarify this to prevent the death spiral. Given some negative feedback towards the Hashicorp blog post from Pulumi employees on this thread, I am somewhat skeptical of this since if everything is fine, then complaining will otherwise have a negative effect, that us users have to assume that Hashicorp is actually stomping them out. And if it's the case, sorry but in good faith to everyone else that may need to work on infrastructure I make, I will have to be complicit in the stomping.
On top of that, whether or not an OSS project accepts your PR means nothing about its quality or utility.
This change appears to have very little or nothing to do with most of us engineers and everything to do with companies wrapping and reselling. As far as I’m concerned it’s a good change.
Anyone who’s thinking about it. Stay away from Pulumi unless you’re okay moving from declarative IAC to some bullshit imperative Python or node constructors and for loops, and everything else that comes with writing OOP. I don’t care about the Hashicorp brand. I care about writing quality IAC and Pulumi is not it.
Would this prevent you from integrating some modules such as AWS (I believe) from TF?
So much love for Pulumi from me, it’s an amazing product.
Pragmatically I would rather bsl than closed source and I am more likely to use a product that is bsl, with reasonable transfer time and license, than a 100% closed source product.
I'd also much rather have "open source" with commercialization restrictions than closed source.
It's still in most people's best interest to contribute to these projects if they were before, or would have before. Many businesses(and this is where most of the contributions get funded from, let's be real) rely on these projects and have no intention of selling them or competing with HashiCorp services.
The actual text of the BSL mandates - under threat of infringing on BSL's trademark - that in at most four years the code will be available under a GPL 2.0 compatible license. In practice, the BSL license is usually a traditional open source one with caveats. The BSL FAQ also states and restates many, MANY times that it is not an open source license according to the OSI's definition.
I can't help but feel like the outcry over this is just a tempest in a teapot. I have a hunch that "Open Source" will do just fine without us having to carry water for it. After all, the list of OSI's corporate sponsors is quite illustrious: https://opensource.org/sponsors/
If we don't have a common definition, everyone has their own, and there's no common understanding of what rights you have for a piece of Open Source software. That commons has far far more value than any one or ten pieces of software.
I don't think so.
I suppose I can understand why people who feel strongly that the OSI definition is perfect (or at least extremely good) are very intent on protecting it, whereas I see it as flawed and am thus less concerned about this fracturing. So I understand your perspective upon reflection, though I honestly have a lot of trouble imagining holding it myself.
A lot of people in this thread have been saying stuff like "just go full proprietary, that's better", and it sounds ridiculous to me every time I read a variant of it
As for the commons, you are aware that the OSD comes from the Debian Free Software Guidelines (it's the same thing but for some minor working changes)? That is the commons that's been talked about, and it's deployed on far more systems than any BSL code is. So moving to completely propriety (note that this doesn't mean it's not Source Available) means that everyone is upfront about what the state is, whereas something like the BSL is leaning into the halo effect under the justification that the code will be open source at some future point.
But this second part of the argument I just don't grok at all. These licenses like BSL provide significantly more of what I want in software I use than proprietary software does. (Namely, the ability to read, modify, and self-host the software of I choose to.)
I think what must be going on is that when you see a license like this you think "there is no point to something like that besides a PR stunt trying to imply proprietary software is open source", and I think "oh this seems like a really useful compromise that allows commercial enterprises to create software with code that I can read, modify, run myself, and contribute to if I want to, without a different company that did none of the work on the software making all the money from it". Just totally different perspectives.
The reason I'm personally annoyed at the attempt to drop the requirement for no restrictions on use is because it is something some academic software does (things like "if you use this code, any results must be shown to me before publishing and require my approval", which as you can imagine isn't great), or with rules around benchmarking (which some DB companies have been known to do), and it's significantly harder to draw the line between something that would allow the BSL, or the above two cases, than it is to require no restrictions on use.
But this part:
> had they been more careful in their language (or even in their CLA), then people would be less annoyed.
I just don't agree. I think they were very careful in their language, and I keep wondering whether everyone here who is pissed at them even actually read it, because I feel like a lot of people keep saying they said things that they clearly worked hard to not say.
I think it's a common shared understanding and a focal point, and there's huge value in preserving that. Having a different common understanding might be acceptable, and might even be an improvement, but only if people agree on it. Having no common understanding would mean something of great value was lost.
Right now, many different groups who may not all agree on all goals nonetheless gain value by sticking to Open Source, and not a dozen slight variations on additional restrictions. In the absence of that, we'd have the "non-commercial" group, the "educational use" group, the "don't compete with us" group, the "don't use for military applications" group, the "don't use for nuclear reactors" group, the "don't use to develop proprietary software" group, the "don't redistribute unmodified versions" group, the "don't distribute outdated versions" group, a dozen variations on "don't distribute if you disagree with our values" groups, the "don't distribute if you're a large company" group, the "don't distribute if you're a specific company" groups...
Every one of those is a license term I've seen advocated. Every one of those violates the OSD, so it thankfully stays obscure and unpopular, because enough people prefer using and contributing to software with less unusual licensing.
Yeah I guess this just seems like hyperbole to me. It seems good to me that there's a pretty widely agreed upon definition, sure, but I just don't think it matters all that much, in the scheme of things.
Agree to disagree I suppose!
We have a messaging flow building platform which is BSL. Anyone who wants to run their own instance is welcome to and people do and thus find it useful. The idea that the world would be better off if we made it closed source and prevented that... is just nonsense.
How does making something closed source automatically mean someone can't run their own instance of it, even for free? Closed source does not mean 'You can only download this if you pay us', just as open source does not mean 'You can download this for free'
The broad distinction we care about within free software is copyleft vs. permissive, and one important one in proprietary software is source-available vs. closed-source.
Then besides all of that there are the non-licensing realities of how development is actually carried out, whether it is collaborative with outsiders, and with which outsiders...
The terms get harder because open/closed suggests straightforward opposites that partition all the options. But I'd characterize licenses like BSL and the Fair Source License as 'generous proprietary licenses with public source availability', but not open-source.
I have a feeling that the term 'open-source' is more likely to erode than 'free software', in the coming decades. We'll see, I guess.
You are exactly correct about this.
1. Open-Source is a "Marketing Program for Free-Software". You describe yourself as having the "free-software" world view (which I describe as an anti-developer property worldview).
See: You can find OSI describe itself as a "Marketing Program for Free-Software" in their original FAQ: https://web.archive.org/web/20010406183942/http://opensource...
> The terms get harder because open/closed suggests straightforward opposites that partition all the options.
2. Again, you are exactly correct. By erroneously choosing term that is generic, that was already in use, and that can't be trademarked, the OSI set itself up for a loosing battle as "the universal standard" for what is not "closed-source".
GENERIC/DESCRIPTIVE: "We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark “open source”; the mark is too descriptive. Ironically, we were partly a victim of our own success in bringing the “open source” concept into the mainstream. So “Open Source” is not and cannot become a trademark.
https://opensource.org/pressreleases/certified-open-source.p...
ALREADY IN USE: There are many documented uses of "open source" in relation to software that is not closed-source, going all the way back to 1985. https://www.arp242.net/open-source.html#pre-1998-usage
> But I'd characterize licenses like BSL and the Fair Source License as 'generous proprietary licenses with public source availability', but not open-source.
As a person with a self-defined affiliation with free-software, it makes complete sense that you would see it this way, but how many people outside of the free-software group see that? The further someone is from self-affiliation with "free-software" surely the less likely they are to agree with this terminology.
> I have a feeling that the term 'open-source' is more likely to erode than 'free software', in the coming decades. We'll see, I guess.
I 100% agree with you. The OSI postulates a union between the interests of people who release software into the public domain, and the interests of people like yourself who believe in Free-Software.
In my view, there is nothing uniting these two groups and the fracture is 100% inevitable. Even if your preferred term `source-available` were to gain widespread acceptance/use, there is no reason for independent developers to subsidize big business by making their source free to use for those big businesses, unless the developers ideologically agree with the tenants of the free-software movement. However, if the developers agreed with the free-software movement, they would choose a GPL style license, not a MIT/BSD/Apache style public domain license.
At least they admit it isn't open source in the FAQ and are calling it the community version instead of the open source version.
My big gripe with the BSL is when companies switch from a proper open source license to the BSL, sometimes they try to sell it as a positive development, which is BS. The HashiCorp announcement is better than some in this regard, worse than others. Claiming it's the "evolution" of open source is weird spin, of course.
I also feel like any company switching from open source to BSL puts a stench of death / desperation on them, and it makes me worry for their future. If they have to make OSS -> BSL switch today, what's the next user hostile change going to be? Will they even survive?
As I explained in an earlier thread, MongoDB tried using AGPL. AGPL is not a barrier for Amazon, they still will resell your product without contributing. MongoDB ended up using a variant of AGPL that is even stricter (requiring the entire tech stack to be under the same license) but is no longer considered FOSS. Until the attitude changes around what FOSS is, this will keep happening.
I don't think this is true.
If they have to change something, then they would likely want want to return hose changes in upstream to lower maintenance burden. Or just publish changes on github of upstream doesn't want to accept them. AGPL is fine with this too.
If Amazon would like create similar offering but with some secret sauce that they don't want to share, then they'll develop in-house solution from scratch and sell it as a service in AWS.
> Their proprietary license protecting their code set competitors and intentional clones back days, weeks or months ... years ago.
- benologist, https://news.ycombinator.com/item?id=17454032
If AWS decides to copy your product, going closed-source or source-available just means they have to copy it from design docs or protocol specs. That's more friction than being able to reuse code outright, but it's not going to stop them.
AWS never offered MongoDB as a managed service, or used any of their server software when it was licensed under APLv3, or SSPLv1.
However, we have contributed patches to MongoDB even after their license change to improve its performance on Graviton processors. Because that's what's good for customers, and MongoDB is an important customer and partner.
AGPLv3 gives all the permissions needed to offer software as a manged service, just like every other FOSS license does. Unfortunately, in my personal opinion, the license has been co-opted by companies that do not care about Software Freedom, and rather hope that companies fear the license so they choose an alternative commercial agreement [1]. I don't think that's good for the community.
[1] https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
Does Amazon contribute funding back to the software projects they offer as a service?
Does Amazon contribute code changes back to the software projects they modified when offering them as a service?
Each use of AGPLv3 licensed software has to be reviewed to ensure that the obligations of the license can be and will be met (and also screen for cases where it is known that the vendor of software does not prefer a company like Amazon import the software under a FOSS license). Today we use AGPLv3 licensed software internally, and include AGPLv3 licensed software in Amazon Linux (Ghostscript, in particular).
> Does Amazon contribute funding back to the software projects they offer as a service?
Yes, in varying ways. For example, it is not easy to provide "funding" for something like Apache Kafka. You need to have people working on the upstream.
> Does Amazon contribute code changes back to the software projects they modified when offering them as a service?
Yes, but not all changes are appropriate for upstream.
> Yes, but not all changes are appropriate for upstream.
But the (modified) source is available to consumers of the service either way, under the AGPL?
If Amazon made an AGPLv3 licensed program available to others over a network, it would have an obligation to provide to anyone that has access to that program the complete corresponding source.
Today, there aren't any services from Amazon that offer AGPLv3 licensed programs as a service. An example that may come to someone's mind is Grafana, but there is a partnership there, and AGPLv3 is not the binding license in that case.
In my personal opinion, AGPLv3 compliance is not difficult, so long as the licensor of the software is committed to community-oriented copyleft enforcement principles [1].
[1] https://sfconservancy.org/copyleft-compliance/principles.htm...
It's no longer considered FOSS because it's no longer FOSS.
> Until the attitude changes around what FOSS is, this will keep happening.
That's a weird thing to say. You're happy with it happening, and everybody else using bad definitions won't change that.
Something is either FOSS or it's FOSS-washed crippleware riding the coattails of actual FOSS for $$$.
Open-source isn't a gospel, it's a religion to some but not the end of the story in terms of what humanity can come up with. God(s?) didn't stop at "closed or open source". We can find alternatives while aiming for ideals.
All that it achieve is making sure noone can build a better product. Aka "yes our product is crap in a lot of places, but we don't want to fix it. Better extract licensing fees by locking you all with us".
The behaviour of dying companies. Which make sense. Their business model never worked.
Not just in the spirit but a fundamental tenant.
No it's not!
It's allowed, but it's not in the spirit.
The spirit is everyone sharing.
It can be true at the same time that "mechanisms to force sharing are against the spirit" and "entities that don't share are against the spirit".
AGPL and other pseudo-FOSS are purist idealistic aspirations that are, in reality, self-sabotaging footguns.
> 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.