[jamestanderson]

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.

[joeduffy]

Pulumi Founder/CEO here.

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.

[fishpen0]

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

[fishnchips]

Spacelift co-founder here - please don’t panic. We will make sure you can continue to use Spacelift :)

[candiddevmike]

You, humanitec, and env0 should start a community fork of pre-BSL Terraform and donate it to the CNCF.

[fishnchips]

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.

[Coryodaniel]

Massdriver would contribute here.

[mattl]

I really hope this happens.

[gravlaks]

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.

[kdmccormick]

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.

[redeux]

>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.

[alexandre_m]

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.

[jupp0r]

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.

[yjftsjthsd-h]

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.

[kdmccormick]

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.

[jsiepkes]

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.

[jen20]

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.

[netheril96]

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.

[thayne]

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.

[ilyt]

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.

[x1919]

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.

[nailer]

> Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp.

Fair enough, let's see the PRs so we can judge for ourselves.

[geokon]

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)

[lifeisstillgood]

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?

[paulgb]

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).

[joeduffy]

[Joe, Pulumi Founder here.]

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).

[sanderjd]

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?

[hyperdrivetech]

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.

[hyperdrivetech]

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

[homewardbound]

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.

[maxloh]

I prefer #1 too, given that the source code will eventually become FOSS one day.

SSPL is unacceptable for me because it have its restrictions last forever.

[pcthrowaway]

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.

[ZiiS]

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/

[tedivm]

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.

[_cenw]

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.

[1]: https://isdotnetopen.com/

Being in the Apache Foundation gives me all the assurance I need alone, though.

[vmatsiiako]

I'm a huge fan of Pulumi. After HCP's license switch, I'm even more sure that Pulumi will be a clear winner over Terraform in the long term.

[Aeolun]

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.

[vbezhenar]

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.

[notnmeyer]

this is difficult for me to think about in the same way as trying to picture a 4th dimension.

surely, state needs to be tracked somehow. what would an alternative even be?

[hdjjhhvvhga]

> 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.

[verve_rat]

Querying the cloud provider apis for current state? Go to the actual source of truth?

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?

[grudg3]

Bicep does that, but it's Azure only, and you can't really 'destroy', just apply.

[rirze]

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.

https://learn.microsoft.com/en-us/azure/azure-resource-manag...

[hughesjj]

<3 pulumi

[nailer]

Just want to say I love Pulumi and think using actual code (rather than HCL config files) is the ideal realisation of the infra-as-code vision.

Pulumi being open source while Terraform is now proprietary cements that.

[justinclift]

Hadn't heard of Pulumi before.

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?

[nailer]

Pulumi is infra as code. Not like Terraform define it - using the world's most hated config file format - but actual code - Python, TypeScript, etc.

[rirze]

It is powered by Terraform underneath-- but Pulumi has done a ton of work to make the abstraction seamless.

[__jem]

Only some of the providers are based on Terraform. I think it would be incorrect to say it's "powered by Terraform."

[justinclift]

Thanks all. I'll add it to my ToDo list for checking out. :)

---

Actually, on second thought it sounds like the platform they're built on top of (Terraform) is now undergoing some fundamental business model changes.

Probably best to see how that plays out first. :/

[chokolad]

It is not powered by Terraform AFAIK

[chokolad]

As far as I know Pulumi is not powered by Terraform underneath.

[aatd86]

Open-source at big companies has a different financial structure.

It's not comparable.

[scarface_74]

Opposite anecdote, I know a few SAs at AWS who contribute to Terraform.

[evantbyrne]

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.

[lolinder]

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.

[scarface_74]

Is this enough detail?

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.

[glenngillen]

(former product lead for Terraform here)

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.

[mst]

They appear to be aware that the ecosystem is important and providers have remained under an OSS license (at least as of this change).

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.

[melezhik]

However I wonder what’s pulumi future gonna be with that move ? So you guys now are going to maintain a transpiller for a closed product, huh ?

[anuraaga]

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.

[thrixton]

Hey Joe,

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.

[_0c0t]

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.

[toomuchtodo]

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.

[version_five]

> 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.

[toomuchtodo]

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.

[JoshTriplett]

> 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.

[toomuchtodo]

> 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?

[riffraff]

Jenkins/Hudson?

Oracle decided to make Hudson commercial, it was forked and Jenkins is still around but Hudson is dead.

[yjftsjthsd-h]

I don't know what the impact was on their revenue, but pretty much anything Oracle has ever touched.

[gkbrk]

ElasticSearch? A lot of people moved to open source forks.

[pessimizer]

> 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.

[JohnFen]

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.

[sanderjd]

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.

[dragonwriter]

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.

[hkt]

Not so: open source licenses tend not to have any clauses requiring reciprocation, free software licenses do. Think MIT or BSD vs GPL.

[sanderjd]

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?

[orra]

> 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.

[davidgerard]

> why bother with this fight?

Because companies keep bringing this fight.

[umanwizard]

“Free software” and “open source” mean the same thing.

[riffraff]

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.

[sanderjd]

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.

[cjaybo]

“The window can’t move”

I’d kill for your confidence

[davidgerard]

> I argue the window is moving as to what “open source” means

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."

[pxc]

> "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.

[version_five]

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.

[toomuchtodo]

I encourage you to continue to complain. Sometimes it’s the only way the rest of us have signal we might be wrong.

[seneca]

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.

[ImPostingOnHN]

> I argue the window is moving as to what “open source” means

perhaps according to Hashicorp's marketing team, otherwise I haven't seen any evidence this is the case

[094459]

Yup this is how I see things evolving too. It’s a long game though and I suspect there will be a few twists yet to come.

[cmiles74]

As they mentioned, this is what the AGPL license is for. No one is suggesting that the people at HashiCorp should not be paid for their work.

https://fossa.com/blog/open-source-software-licenses-101-agp...

[asymmetric]

If they made their tools AGPL, they themselves couldn’t build a cloud offering with additional, closed-source features.

[MattJ100]

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.

[ZiiS]

I am not sure being closed source is much comfort if AWS decide they want to crush you.

[n42]

Isn’t that precisely what AGPL is for?

[mperham]

A license controls what OTHERS can do with your source. You, the copyright holder, can do anything you want.

[asymmetric]

Thanks, I stand corrected. How does this play with third-party contributions? Others might be the copyright-holders of a sub-section of the code.

[duckmysick]

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.

[JimDabell]

You ask contributors to sign a copyright assignment before accepting their changes.

[deno]

Only if you accept contributions without a license grant CLA.

[_msw_]

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?

[1] https://meshedinsights.com/2021/06/14/legally-ignoring-the-l...

[bawolff]

From a pragmatic perspective, it is much easier to enforce an open source license with a lawsuit if you own 100% of it.

[Macha]

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.

[pydry]

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.

[Macha]

I'm way more fine with AGPL (without CLA). That's perfectly within the spirit of open source, as it doesn't privilege one group of users over another.

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".

[pydry]

I find it curious that Microsoft doesnt get more shit for demanding a CLA, especially given that embrace, extend, extinguish is in their DNA.

[JimDabell]

Even GNU projects ask people to sign a CLA.

[bawolff]

> AGPL+CLA is "we're setting up for a bait and switch with not open source versions".

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)

[Macha]

I think I'd be fine _using_ an AGPL+CLA product, but not contributing.

[davidgerard]

> BPL/EPL/SSPL was always fully within the spirit of open source

It literally is not, and they only exist in order to not be.

[pydry]

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.

[aragilar]

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.

[mfer]

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.

[1] https://www.google.com/finance/quote/HCP:NASDAQ

[PoachedEggs]

> There are many sustainable open source companies.

What are some examples?

[pcthrowaway]

SUSE, Canonical, Prisma (though their dashboard is closed source), Gitlab, pretty much every crypto company in the blockchain/web3 space.

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

[oblio]

> SUSE, Canonical, Prisma (though their dashboard is closed source), Gitlab, pretty much every crypto company in the blockchain/web3 space.

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?

[pxc]

> Gitlab is losing money.

GitLab (Enterprise) is also proprietary software.

[sebastianz]

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 :)

[pcthrowaway]

> 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)

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.

[re-thc]

Prisma isn't making money.

> 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?

[candiddevmike]

If this doesn't move the needle expect more increases to their licensing. Though I don't know how it could become more expensive.

[ZiiS]

What is so frustraiting is their model seems sound; they just had rediculusly high pricing.

[_ea1k]

> 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.

[davorak]

> 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.

[Rapzid]

I wish I could give you more upvotes.

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.

[ramses0]

"Source Available" please.

[JeremyNT]

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?

[JoshTriplett]

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.

[LexiMax]

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/

[selestify]

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.

[sanderjd]

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.

[JoshTriplett]

https://en.wikipedia.org/wiki/Focal_point_(game_theory)

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.

[sanderjd]

> 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

[JoshTriplett]

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.

[aragilar]

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.

[rowanseymour]

> 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.

[cthalupa]

> 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'

[rowanseymour]

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".

[cthalupa]

It's source available. Which is not the same thing as open source.

[pxc]

Enclosed-within-glass software

[davorak]

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.

[notpushkin]

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.

[pxc]

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.

[CrimsonRain]

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?

[davidgerard]

they literally aren't. These are jargon terms with precise meanings.

[thayne]

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.

[gus_massa]

And that's why I disñike CLA.

[LambdaComplex]

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)

[FridgeSeal]

> 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.

[klardotsh]

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.

[scarby2]

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.

[p_l]

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.

[dudus]

1.5 years?

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.

[wmf]

They IPOed at the peak of the ZIRP bubble. There's nowhere to go but down.

[scarface_74]

How many of those companies were profitable before going public?

[LambdaComplex]

Are you implying that it's impossible for a company to be both profitable and have a good internal culture?

That's a scary thought.

[scarface_74]

No I’m saying most tech companies went public without being profitable and that had more to do with the declining stock price.

[foobiekr]

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.

[scarface_74]

All of the current BigTech companies except Amazon were profitable before going public - Apple, Microsoft, Google, Facebook.

The vast majority of tech companies that IPOd since Facebook have been a disaster of an investment.

[pessimizer]

> 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."

[fasterik]

>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?

[dragonwriter]

> 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.

[mst]

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.

[pxc]

> 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.

[rcme]

Source-available is still hugely beneficial to users, even if it’s not open source.

[falcolas]

Closed source can (and does, see Windows) provide source to customers too.

[e12e]

> 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...

[pessimizer]

No, if words have meaning, "closed source" does not provide source. Closed source does not mean "not open source."

[falcolas]

Well then, according to the meaning you are assigning these words, Windows must be open source.

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.

[ZiiS]

The windows source is not avalible to _me_, even if they show it to some people. It is useful to have a term for source available to everyone.

[pseudalopex]

Windows would be not open source and not closed source according to them. I think most people would call it closed source however.

[rcme]

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.

[CrimsonRain]

So where can I view windows 11 source code? Got a link?

[falcolas]

Sure!

https://www.microsoft.com/en-us/sharedsource/

[goodpoint]

Incorrect. Closed source means that you cannot modify or redistribute the sources.

[AYBABTME]

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.

[unknownian]

>like the AGPL?

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.

[thayne]

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.

[_msw_]

Disclosure: I work for Amazon.

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...

[pabs3]

Does Amazon have any policies against offering AGPv3 software as a service?

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?

[_msw_]

> 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.

[e12e]

>> 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?

[pabs3]

Thanks for the answers, very interesting.

[yjftsjthsd-h]

It's a little funny in this context, but allow me to pull this out from my quotes file:

> 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.

[bostik]

Mongo also offers a hosted, paid product (Atlas) directly on AWS. Which I think is pretty smart of them.

[wmf]

AGPL is not a barrier for Amazon, they still will resell your product without contributing.

I don't think this is true.

[iavael]

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.

[orra]

> but is no longer considered FOSS.

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.

[sacnoradhq]

AWS forked Elastic because of pseudo-FOSS AGPL-like licensing.

Something is either FOSS or it's FOSS-washed crippleware riding the coattails of actual FOSS for $$$.

[drdaeman]

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)?

[da768]

> without providing material contributions back

They need more open PRs? It's not like these contributions would necessarily be welcome.

[pxc]

Code contributions are material when Hashicorp makes them, see, but the only contribution from others that matters is cash.

[prmoustache]

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.

[di4na]

I will say.

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.

[bawolff]

> This is 100% in the spirit of open source

Not just in the spirit but a fundamental tenant.

[sacnoradhq]

AGPL is a user-hostile license and a license that MAANGs explicitly forbid.

AGPL and other pseudo-FOSS are purist idealistic aspirations that are, in reality, self-sabotaging footguns.

[Dylan16807]

> This is 100% in the spirit of open source.

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".

[afiori]

> This is 100% in the spirit of open source

That is the spirit of Free Software (ie restricting users as little as possible) Open Source is much smaller in scope.

[riffraff]

The open source definition explicitly says that there must be no restrictions on reselling.

So restricting competitors is as much against the OS spirit as it is against the FS spirit.

[afiori]

touché