Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: