Hacker News Reader

Comment by akajla | Hacker News Reader

Very valid concern. We built the edge agent(https://github.com/warrant-dev/edge-agent) specifically for perf and reliability concerns. It's designed to run in customer infra with built-in storage (currently in-mem/redis) and can respond to all access checks even in the event that the Warrant cloud service is down. Writes would currently still be impacted if Warrant is down so this is definitely an area we're continuing to improve and expand.

Additionally, customers have also requested their own private Warrant service deployments/on-prem so that's something we may offer more broadly in the future.

View on HN

This partially answers the previous post, but it doesn't answer all of the concerns he mentioned.

Even if you have an On-Prem deployment, if Warrant goes belly up, you're still hosed. Unsupported code is a recipe for disaster. What if it has a critical security vulnerability and it can't be patched? Is it legal to keep the code deployed once the contract expires and can't be renewed?

As a former Security Engineer that worked alongside the SRE team, we would never be able to justify this dependency for a production system. We'd rather build it ourselves or live with the crappier version than deal with a black box that can take down the business.

The flip side of this is an Open Source project. We regularly built around Open Source projects instead of starting from scratch when we could.

Have y'all considered moving to a license like BSL or AGPL for what you're building?

This is why 1 year ago we open sourced[0] SpiceDB[1] under Apache2 and have been leading the way for open source Zanzibar systems. SpiceDB has contributors and users from the likes of GitHub and Adobe in addition to Authzed; building in the open and making sure that we aren't the only ones supporting SpiceDB is critical to the long term success of our users and our business.

[0]: https://twitter.com/authzed/status/1443590501484032002

[1]: https://github.com/authzed/spicedb

This is awesome, but it's also kind of wild that YC basically put closed-source and open-source competitors in the same space in virtually the same batch.

I'll definitely be looking at this for my current project.

We have thought about it but still evaluating. In general, our thought here is that in case we go out of business, customers should be able to continue using the software with access to source and some level of temp support. We'd codify these terms into contracts. From conversations with others, this seems similar to how companies like Plaid, Stripe and LaunchDarkly handled it, especially in the early days.

That being said, BSL/AGPL looks interesting but I'm not that well-versed in them so it's something we're going to look into more.

Be careful on licensing anything that gets linked/deployed in to the customers environment. There are many large and small enterprises with “strenuous review” policies, if not blanket bans, on licenses like AGPL. This is not to argue the morals or utility of those policies but it is fact.

Similarly it would behoove you to read on the “relicensing” issues of the last few years. Many companies start small with open source to drive adoption, then discover that business model also explicitly enables others to use the same work and compete in the same space. Much heartache ensues.

Reply on news.ycombinator.com