Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HashiCorp adopts Business Source License

hashicorp.com

Post reply on HN
Print view View original

721–730 of 760 posts

Re: HashiCorp adopts Business Source License

#721

Post by rirze »

chokolad wrote: post #642
justinclift wrote: post #632

Earlier quoted context omitted.

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

It is not powered by Terraform AFAIK

Not sure why you're so insistent on this when Pulumi folks themselves on this post have said that they contribute back up to the AWS provider source repo (1).

Maybe not all their providers utilize Terraform, but it was definitely how their product started out. When you run Pulimi using their AWS provider and get errors at runtime, some of those are verbatim Terraform errors.

Their docs and site is very clear to muddle this connection but if you ever used their API, you'd know this.

(1): https://news.ycombinator.com/item?id=37081306

Re: HashiCorp adopts Business Source License

#722

Post by notnmeyer »

hdjjhhvvhga wrote: post #712
notnmeyer wrote: post #620

Earlier quoted context omitted.

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?

> this is difficult for me to think about in the same way as trying to picture a 4th dimension. Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.

tagging provider resources? not speaking for every provider or api, but at least on AWS not everything that can be managed supports tagging.

also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.

infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.

totally possible im missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.

Re: HashiCorp adopts Business Source License

#723

Post by notnmeyer »

Aeolun wrote: post #684
verve_rat wrote: post #679

Earlier quoted context omitted.

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?

Querying cloud provider API’s takes a while. It can be done, but the results are cached afterwards, which is the state file. 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.

exactly. relying purely on the provider’s api seems like an untenable solution with the current state of things.

Re: HashiCorp adopts Business Source License

#724

Post by rirze »

chokolad wrote: post #640
rirze wrote: post #623

Earlier quoted context omitted.

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

I think you might be misunderstanding this page. Bicep's "state file" is actual Azure state. Bicep is a nicer way to write ARM (Azure Resource Manager), which is pretty much an Azure API. if you are familiar with Kubernetes, ARM represents Azure internal state in the same way kubernetes YAML represents actual kubernetes objects stored in the cluster.

> No state or state files to manage: All state is stored in Azure. Users can collaborate and have confidence their updates are handled as expected.

Not sure how I could "misunderstand" this quote to mean anything else.

By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.

Re: HashiCorp adopts Business Source License

#725

Post by _0c0t »

joeduffy wrote: post #122
jamestanderson wrote: post #28

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 o…

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 hopefu…

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.

Re: HashiCorp adopts Business Source License

#726

Post by teddyh »

elderbarry wrote: post #699
teddyh wrote: post #568

Earlier quoted context omitted.

GNU projects assign the FSF as the copyright holder. The FSF is inherently trustworthy. (Since the FSF controls the GPL .)

One day someone untrustworthy will be in charge of the FSF, and ‘or later’ is suddenly going to be #awkward. Linus made the right call there, for sure.

The FSF is not an autocratic kingdom with a despotic ruler on top. It is a 501(c)(3) foundation, with bylaws and regulations to cover this eventuality.

This was all hashed out years ago in numerous flame wars on Usenet, as I’m sure you know.

Re: HashiCorp adopts Business Source License

#727

Post by icco »

NathanFlurry wrote: post #396

We built our OSS company (Apache 2.0) with Nomad at its core. We provide game server orchestration with a handful of services around it, which could be misconstrued to be considered providing a "competitive offering to HashiCorp." Needless to say, we'll be freezing our Nomad version at the last MPL version because of how vague the license is (intentionally). We also use CockroachDB which uses BSL, but we're not provi…

I would migrate off fast. If they are willing to do this with their oldest and most popular tool, I have no doubt they'll change the license of all of their code soon.

Re: HashiCorp adopts Business Source License

#728

Post by yencabulator »

Aeolun wrote: post #684
verve_rat wrote: post #679

Earlier quoted context omitted.

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?

Querying cloud provider API’s takes a while. It can be done, but the results are cached afterwards, which is the state file. 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.

The state file is more than a cache. If it was just a cache, it wouldn't be problematic.

Re: HashiCorp adopts Business Source License

#729

Post by wlonkly »

danw1979 wrote: post #704
wlonkly wrote: post #245

Earlier quoted context omitted.

I believe providers are still OSS-licensed.

Correct, according to the Hashicorp license change FAQ - https://www.hashicorp.com/license-faq#How-does-this-impact-t... And I checked the contribution guide for the aws provider, no mention of a CLA there. I wonder if Hashicorp would be able to pull the providers under the same BSL in future ?

My understanding is that a _lot_ of the AWS provider was written by AWS developers on the clock. I think that pattern holds true for a lot of "official" providers. For that reason I don't expect to see BSL for providers.

Re: HashiCorp adopts Business Source License

#730

Post by maxloh »

sanderjd wrote: post #443
joeduffy wrote: post #208

Earlier quoted context omitted.

[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 sec…

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 inc…

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.

Post reply on HN