HashiCorp switched Vault from MPL to BSL license yesterday. The terms of how they define "competitive" products are pretty vague, which means that any commercial product that uses Vault under the hood is at risk of violating the terms of the new license. Moreover, even if it's not violating the terms of license now, it doesn't mean that HashiCorp will not change its mind in future.
Ultimately, it just means that HashiCorp is not an open source company anymore. One of the biggest benefits of open source is building on top of open source software to create even better software. HashiCorp's move makes it impossible and simply slows down innovation. In fact, in their blog post, they say that they will start referring to their previously-open-source product as "community".
Infisical is an open source alternative to HashiCorp Vault. The main difference is that it provides more tools in one platform. Some examples of these are automatic secret scanning and leak prevention, CLI for local development, integrations with services like GitHub Actions, Circle CI, etc.
The core of Infisical is available under the MIT license with only very few features being enterprise-licensed – some will say it's not ideal but at least this type of license does not impose legal risks on our users while gives us the ability to monetize the product efficiently and support the open source (MIT-based) part of the product.
Over the last year, lots of developers and companies of all sizes (from tiny startups to Fortune 10 companies) have partially or fully switched to Infisical. For them, we now process over 300 million secrets per month.
Regarding the open core and proprietary extensions model. The usual endgame of that is what hashicorp seems to have just done - deprecate the open source part in favour of the part that makes money.
This bait&switch is no longer novel. Be open source friendly to leverage the community and then pull the rug is probably taught strategy in VC themed business schools by this point.
If you're going to do the same thing in a while anyway, one may as well stay with hashicorp. Is there a reason to believe you will remain viable as an open source product long into the future?
Maybe I'm missing something, but Infisical ONLY seems to handle shared secrets. Vault handles a lot more, it can for instance create DB users on the fly, with the right permissions that will only live for as long as the vault token does. Vault also has a full CA system in-place, and can rotate secrets, etc.
Does this product do things like that? I couldn't find anywhere where it does those things in the docs, though I admit I only scanned them.
Backed by another corporation trying to monetize it. This will go well.
This repo available under the MIT expat license, with the exception of the ee directory which will contain premium enterprise features requiring a Infisical license.
I just sprained my eye sockets from rolling my eyes too hard.
What's wrong with monetization? You understand that OSS's significant problem is a lack of funding, where authors don't want or don't know how to monetize their product?
Sentry looks like a good model for OSS, and it's proof that you can make a living from OSS. I also don't have anything against "enterprise features" for which you need a license, while most features are available in OSS version.
Open Source is not a business model. It's marketing, for sure, but you can't make money solely by giving away your product.
Every single open source company eventually learns this when they have a strong competitor. Eventually you are forced to stop being open source, because no business wants to compete solely on the strength of their service quality.
Moreover: a community is antithetical to a corporation's interest in the software. Corporations don't give a shit what people want changed in the code, for good reason: their purpose is to make money, not make good software. So business source always ends up annoying and limited while community open source provides the functions the users need, in the way they want them.
So, yeah, you can make money while letting people read your source code. But the actual quality of the end result, the user's happiness, the ability to contribute to the whole thing, is much different in a real community project.
Open source core, paid premium features + support. It's a valid business model, not sure why it's worthy of eye rolling.
For example: Open source database that works on one machine. If you like it and want want to scale up, you can pay for the replication and authorization features with paid support.
The people who will pay for your database are going to pay for it right away. They're not going to "scale up" and then pay for it.
Just ask Docker. There's thousands of companies using Docker Desktop that should be paying for it but aren't. Same for most other Open Source companies with business licenses. Because they set themselves up as an "open source" company, all the villagers revolt when you finally ask to get paid, or stop allowing competitors to steal your lunch. You can survive, but it's very hard, and eventually they die away. (But that's also because most software gets replaced after a decade)
You have to treat your business as a business first and foremost if you want to remain profitable and competitive. You can use Open Source for your business, but you will not survive for long if you're hoping people will pay you just because they can read your code. Eventually reality, and competitors, come knocking.
> Open source core, paid premium features + support. It's a valid business model
I’m a pretty rusted on Odoo developer, this has been their business model for years and it’s worked thus far, even when facing off with the likes of the SAP and Dynamics of the world.
TBH my view is that the frustration towards open source companies around changing their licenses is sort of misguided. If there's a bad guy in the room, it's AWS. AWS is very good at commercializing open source -- they make literally billions of dollars doing so: Elasticache (Redis), AWS Managed Elastic, RDS etc. Changing the license becomes one of the only ways to hold them off, and the companies that have done so more proactively have fared much better. I think everyone agrees that in an ideal world this wouldn't have to happen, and indeed it didn't really happen until recently when the AWS thing started to become an issue.
Ultimately, SOMEONE is going to leverage the open source for financial gain. So, the question becomes which would you rather have:
- The company commercializing the open source (which is in almost every successful case includes the original creator(s) as a founder, CEO, or employee) benefit from the projects success, which in turn allows them to make further investment in the project.
- AWS benefit from the projects success and (generally speaking) contribute very little back.
Of course, there are plenty of projects that are NOT venture funded that see great success through purely community development. That's great! I just think commercial open source is beneficial as well, especially for larger more complex projects (databases, etc.) that need the funding. The two are not mutually exclusive.
I am also of the belief that the additional funding (both from revenue and from venture investment) that goes into these projects gives them the ability to hire more people, which in turn makes the software better for everyone.
Disclaimer: I am investor that invests predominantly in commercial open source companies. Previously I was developer who used a lot of open source, which is what led me here.
> What's wrong with monetization? You understand that OSS's significant problem is a lack of funding, where authors don't want or don't know how to monetize their product?
> Sentry looks like a good model for OSS, and it's proof that you can make a living from OSS.
Sentry is using the BSL, the very same license that HashiCorp has switched to but that change has not been received well.
See, the problem is that you have it backwards. OSS's significant "problem" is those attempting to levarage it for funding. If you want funding, don't do open source; you'll make all the precious money that those who have it think it might be worth, and you won't look like a dick when you pull it back because you're not making enough.
If you want to write software, in a community, for the betterment of that everyone, no matter what anyone else does with that software, then release it as open source.
Can you still make a comfortable living writing open source software? Perhaps, but if that's your goal, you're doing it wrong(tm).
There's nothing wrong with monetization. There's just something wrong with making parts of the code proprietary. There'd be nothing wrong with monetizing by picking a copyleft license and selling exceptions, selling hosting, or selling support, for example.
I tend to trust “side project” OSS software more than OSS software that is some company’s main product. Something like Apache Samza that a company builds for some aspect of its operations and then opens seems to be more trustworthy long-term because the commercial backer doesn’t have to compete with *aaS providers for their main source of revenue. Such projects obviously have their own problems (neglect, deprioritization of features the maker doesn’t need now), but otoh, the maintainers are more likely to accept contributions adding features because they have to think less about market segmentation and such.
I have nothing against dual licensing, but that's not what "enterprise features" are.
As for Open Core, there is one case in which I think that's fine: when none of the proprietary parts would be useful at all in an otherwise 100% FOSS environment. For example, if Linux support were FOSS but all the Windows- and macOS-specific code were proprietary, or if a plugin to talk to Bugzilla were FOSS but a plugin to talk to JIRA were proprietary, I wouldn't see a problem.
Open Core usually fails the FOSS community when the company either 1) makes some essential features like OAUTH/SSO or 2FA Enterprise only, or 2) is openly hostile toward open source components that compete with its own Enterprise features.
How well would your example companies deal with a PR adding open source macOS platform support, or an open source JIRA bridge?
While this statement is technically true, I don't think it has any relevance to the topic at hand. While there are some relatively obscure licenses that are OSS but not FOSS (e.g., the Sybase Open Watcom Public License), isn't everything under discussion here either both free and open source, or neither free nor open source? In particular, the "core" of Open Core is both, but the extras are neither.
This is indeed what we are going for. We want to provide a very predictable license that gives most of the features for free for developers while keeping the managerial features paid to make sure that we can support development and maintenance of Infisical.
> The Business Source License (this document, or the “License”) is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License.
I would argue (and have previously) that BSL is open source, it's just being held in escrow. So it has been released to open source... just that source hasn't been released to the public. (BSL triggers after a max of 4 years into irrevocable OSS).
I think the real issue is that people want more community driven OSS. Stuff that is collaboratively built and not built for a commercial purpose. They want something I think along the lines of KDE where there are paid people to work on it, but it's also contributed to by a community and there isn't someone constantly trying to a make a buck off of it.
One problem with running x-year-old releases of web applications are bugs and vulnerabilities that have been discovered and fixed in those years. Are many people running the 3 year old, now properly OSS versions of Sentry in production?
Using BSL strikes me as trying to have a cake but eat it too: look, we're good open source guys using an open license. Feel free to use our code, but only after it is well beyond its best before date!
I think OSS core + proprietary components (which can be replaced by OSS alternatives) is much less evil business model than what Hashi did: forced contributors to give up copyright and then locked everything under business license.
There are many examples of such approach: Spark/Databricks, Cassandra/Datastax.
I mean, sure, but there's no particular reason to believe that Infisical will keep its current licensing if and when when financial times get tough for them.
When you rely on OSS products that are developed almost exclusively by companies, you just need to assume that one day there's going to be a rug pull and plan accordingly.
I think license they chose doesn't allow to change licensing, unless they require 3p contributors to sign some agreement to give up copyright rights like Hashi asked to do.
So, we can check right away if infisical asks to sign agreement or not.
Infisical doesn't need a CLA because it's permissively licensed. People who contribute their code under the project's license (MIT) have already agreed that anyone (Infisical or anyone else) can take their code fork it into a proprietary project anyway.
> Backed by another corporation trying to monetize it. This will go well.
This is a good point. Open source software by definition must be made by monks that have taken a vow of asceticism. I won’t use any OSS made by anyone that eg drives a car or has been to a dentist.
The problem, though, isn't the mere concept of trying to monetize open source work. It's the fine line between balancing profitability and openness vs deception and exploitation. Open source with community governance is clearly better at upholding ideals, but honestly, other models can work, too. As I see it today, the CLA is a major issue: it can be seen as insurance against existential threats for open source projects, but it's being used to make pulling the FOSS rug legal 99% of the time its ever exercised, it seems.
We'll probably write up a comparison with Infisical soon as well but I'd say the main thing is that our end-to-end encryption has no opt-outs (as Infisical does for many of its integrations), and we use native apps and a CLI rather than offering a web UI. End-to-end encryption in a web browser offers minimal security benefit for reasons discussed in this thread: https://news.ycombinator.com/item?id=21838795 (the discussion is from 2019 and the original NCCGroup link from 2011 is now dead, but all the same issues still apply).
A major use-case for Vault is dynamic generation of secrets, like rotating roles in a Postgres DB or acting as CA (issuing/revoking certs) in a PKI infra. Some, like the former, needs to hold secrets for and communicate with external services.
How easy is this to achieve using EnvKey? Only allusion I see on the comparison page is "Easy Integration: Vault=Poor, EnvKey=Strong" but I have a feeling something else was in mind there.
Yeah, "easy integration" is more speaking to how you get secrets from Vault/EnvKey through to an app.
Dynamic secrets generation isn't built in to EnvKey, but we do offer a CLI that makes it straightforward to generate or rotate credentials/roles as part of your deployment. Rather than baking in this kind of thing, we are more taking a 'give you simple building blocks so you can do anything' approach to automations. For your postgres example, it would look something like this:
# Set variables for an EnvKey environment that includes postgres admin creds in shell
eval $(envkey-source)
# Use the admin credentials from EnvKey to rotate credentials for app role in Postgres.
# You could also create new roles, grant privileges, etc., as needed.
NEW_PASSWORD=$(openssl rand -base64 32)
psql -h $DB_HOST -U $DB_ADMIN_USER -d $DATABASE_NAME -c "ALTER ROLE $ROLE_NAME WITH PASSWORD '$NEW_PASSWORD';"
# Update the credentials in EnvKey for your app.
envkey set app-name production DB_PASSWORD=$NEW_PASSWORD --commit --json
Meanwhile, if you prefix your app start command like this:
envkey-source --watch -- ./run-my-app.sh
Your app process will then be automatically restarted after the `envkey set` command with the latest postgres password in its environment. If you're running multiple instances, you could also use rolling restarts to avoid downtime.
So it's a bit more work compared to Vault for the postgres use-case, but on the other hand, with EnvKey you get a lot of flexibility to setup these kinds of automations for any service or tool.
For acting as a CA, we have some ideas on how to accomplish this that I think would be both simpler and more secure than Vault's approach, but we haven't gotten to it yet.
In my opinion, "having no opt-outs" is not a benefit. It's by definition having less functionality. Infisical offers native SDKs, API, and CLI too + many other features (such as native integrations, webhooks, dashboard, etc).
In the security domain, you often want fewer features, because every feature is another thing to audit, and another chance to introduce a vulnerability.
But, of course, too few features can be just impractical.
There's an inherent tradeoff for sure. In my opinion, I wouldn't say that any added functionality a secrets management service can offer is worth trusting all that service's servers, all its backend dependencies, all its employees and contractors, all its third party sub-processors, etc. with plaintext secrets.
I'd also note that we are able to offer all the features you list without requiring users to opt-out of end-to-end encryption.
"We work with some of the largest companies out there, and none of them had an issue with this."
I imagine they'll regret this if you have a security incident.
"Curious how you are able to create a native integration with, let's say, Vercel without requiring users to opt-out of end-to-end encryption?"
We don't have a native integration with Vercel (you didn't list that in your comment, which is what I was referring to). We don't really have a need for one since all that's required to integrate EnvKey with Vercel is setting a single environment variable. That said, if we did decide to build an official Vercel integration, we wouldn't require removing end-to-end encryption to use it.
Hmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries.
One is envkey-source (https://docs-v2.envkey.com/docs/envkey-source), which contains core client-side decryption and verification logic. It can be used standalone from the shell like this:
# some-command runs with EnvKey vars in its environment
$ envkey-source -- ./some-command
Or like this:
# EnvKey vars are set in current shell
$ eval $(envkey-source)
$ echo $SOME_ENVKEY_VAR
It allows you to integrate with a Go project like this:
// main.go
import (
"os"
_ "github.com/envkey/envkeygo/v2"
)
// assuming you have GITHUB_TOKEN set in EnvKey
token := os.Getenv("GITHUB_TOKEN") // this will stay in sync
We're planning to do a docs-improvement pass soon so I'm very interested in how we could clear up any confusing aspects of how the different pieces fit together.
The second project; it only does caching of the keys. It's a big advantage to use your software without any SDK or client code. You should make it clear that it's optional.
Ok, understood. The purpose is not so much caching as setting the vars in the environment so they can be accessed in a standardized way that is compatible with dotenv, 12 factor apps, etc. But yes, you could also say they’re being cached.
We do try to mention in the docs for each SDK that envkey-source can be used from the shell instead, but I’m sure we can make it clearer. Thanks again!
I remember trying Infiscal, and I was excited to see how good it is, the feature list in the OSS version, and its ease of use... What cooled me off is this limitation in OSS: "3 Infisical Projects, 3 Environments & 5 Team Members."
That's not nice. It's OK to limit SSO access to OSS and stuff like that. But limiting essential features - team members is a no-go.
This is very strange. There is no such limitation. You can create as many projects and environments as you need. You can also add an unlimited number of users
Second this, we don’t have any such limitations on OSS that is you can totally self-host Infisical on your own infrastructure and have unlimited users, projects, and environments.
I think there may be a mix-up here with Infisical Cloud which is the managed service with subscription tiers.
OK, that's great to hear. You may consider removing the "Usage & Billing" page from OSS when self-hosting. Because I thought I'd have to upgrade OSS with a business license once I reached the limit.
Yeah, I've noticed that the app is not enforcing that limit ATM, but the limit was clearly visible in the dashboard when I tried it a couple of months ago (OSS, docker)
At this time (4h after posting) they've responded to almost every other question/comment except this one, so they've seen this question and chosen not to respond, which means the answer is bad - no tests.
I like the idea of a Vault alternative, but I won't use a security product in production that is not automatically tested for vulnerabilities and regressions.
Was interested so had a look and it appears to be the case. I found a directory backend/src with 27K lines of typescript, and backend/tests with 303 lines.
I must admit that the test coverage is still lower than we would want it to be.
Currently, we are in the process of adding tests, and the test coverage will only keep increasing over the next few weeks. You can learn more about this in our community Slack: https://infisical.com/slack
Yes, indeed! I understand how it might sound. We have already started doing it and discussed it within our community – in other words, it's not just a plan. Expect it within the next 2 weeks maximum.
I would prefer that you didn't set yourself hard time-based deadlines for security features. If this product is going to be around long enough for enterprise to trust it, that you did this in two weeks won't make any difference. Unnecessarily rushing yourself to meet an arbitrary deadline helps nobody and hurts the product. Especially if, as noted by GP, you don't have a good track record.
It's also worth noting that you're doing this in the wrong order. The "We can test it all later, ship! ship! ship!" strategy works fine for trivial apps, not security software.
MIT now, but in a few years when the inevitable need to make profit number bigger crops up they'll be doing the same thing.
And there will the same backlash by people pretending that the change is some sort of grave slight and make bold claims about how they're switching away because they actually have to pay for stuff now.
So the introduction says it’s “end-to-end encrypted” but all it does is a link to Wikipedia (which is useless). Is there any documentation on the security model?
Vault has some at-rest encryption but IIRC explicitly says then don’t have any mitigations against a compromised unsealed node. My understanding is that if someone ever gets a root access to a machine running Vault, the game is over. Which makes me wonder ifI can deploy Infiscial to some completely untrusted machine (without any orchestration or networking concerns) and still have some guarantees that all my secrets are safe in some way (cannot be decrypted, cannot be replaced, maybe even cannot be rolled back, etc)?
Put simply, Infisical operates E2EE by default which means the platform itself can’t decrypt secrets. This is unless you opt out of E2EE (secrets remain encrypted at rest) to use select features like native integrations - this is, however, not necessary to use the platform. In your case, you might wish to run Infisical in E2EE mode for maximum security.
That said, it’s always important for you to keep your instance of Infisical secure that is ideally to not allow bad actors to gain root access to the machine.
There has to be a middle ground where yes you can use this to your hearts content for free, but don't package and sell this to undercut our own hosted offering.
It's pretty shitty what happened with mongodb and aws. Morally it always felt wrong.
Prioritizing feature requests and providing good quality support takes a lot of time and effort... You can check in our Slack (https://infisical.com/slack) that we try to reply to everyone within a couple minutes. This is definitely the biggest one, but it's worth it IMO!
I wish secret manager services were obsoleted by OIDC and HSMs. If everything negotiated via keypass & beyondprod style workload identification and... we never save passwords for DBs or web hooks ever again.
...it's annoying that a kubernetes-like complex system exists and it doesn't have to. And now they have a SaaS version for small numbers of secrets....
Infisical 3rd party integrations are one of the best things about it. They just work without having to deal with plugins or crazy configurations. Kudos to the team.
Definitely. Our plan is to double-down on secret management and branch outwards but incrementally starting with secret scanning to prevent and detect leaked secrets in codebases.
Ultimately, we intend each initiative of our roadmap to have synergies with the rest of the platform.
As a rule, plugging your own stuff on HN is actually acceptable, but it needs to be clearly labeled as a plug and you should do it under your own account. Doing it like this—throwaway account plugging a service with no disclosures of any kind—looks really suspicious.
Yes, I work for Fortanix. I have added my email in my account. Please let me know if anything else is needed. I could not update my comment... Otherwise, I am happy to update my original comment as well.
Another option, for companies that want to go full security over automations and kubernetes, is CyberArk Conjur.
Its OpenSource is quite limited in features, but the Enterprise version is very complete.
Ultimately, it just means that HashiCorp is not an open source company anymore. One of the biggest benefits of open source is building on top of open source software to create even better software. HashiCorp's move makes it impossible and simply slows down innovation. In fact, in their blog post, they say that they will start referring to their previously-open-source product as "community".
Infisical is an open source alternative to HashiCorp Vault. The main difference is that it provides more tools in one platform. Some examples of these are automatic secret scanning and leak prevention, CLI for local development, integrations with services like GitHub Actions, Circle CI, etc.
The core of Infisical is available under the MIT license with only very few features being enterprise-licensed – some will say it's not ideal but at least this type of license does not impose legal risks on our users while gives us the ability to monetize the product efficiently and support the open source (MIT-based) part of the product.
Over the last year, lots of developers and companies of all sizes (from tiny startups to Fortune 10 companies) have partially or fully switched to Infisical. For them, we now process over 300 million secrets per month.
Check out our git repo here: https://github.com/Infisical/infisical