All Your Licensing Are Belong To Us^W You
Today is a day full of emotions. When I first started Keygen, I never thought it'd take off the way that it has. I never thought I'd be working full-time on it, either. When Keygen's revenue exceeded my full-time salary at the time, I was caught off guard even though it was an accomplishment 5 years in the making.
After all, I thought that milestone was something reserved for the Twitter talking heads. But with hard work, I made it work, even when my peers said I shouldn't.
Last month was the 7 year anniversary of Keygen's first commit.
Wait — did I just link to the…
Yes. Yes, I did.
After 7 years of being closed source, I'm incredibly excited to announce that Keygen is now open source! Let's unpack what that means for us and for you.
What's changing?
If you're a current Keygen Cloud customer (what we're calling our SaaS moving forward), nothing changes. Starting today, in addition to Keygen Cloud, Keygen is now available in two self-hosted editions: Keygen CE and Keygen EE.
Each edition offers unique features and benefits, and you can choose the edition that best suits your specific personal or business needs:
Keygen CE: the Community Edition (CE) of Keygen. This is a self-hosted single-tenant version of Keygen's API. To start using Keygen CE, you can visit our GitHub or follow our self-hosting instructions. Keygen CE is free (as in beer) to self-host.
Keygen EE: the Enterprise Edition (EE) of Keygen. Also a self-hosted version of Keygen's API, Keygen EE can be single- or multi-tenant depending on configuration and license. Keygen EE comes with features that are more enterprise-centric such as environments, historical request logs, event (audit) logs, and advanced permissions. Keygen EE will require a valid license key to self-host.
Keygen Cloud: the SaaS version of Keygen. Keygen Cloud is a fully-managed cloud service that provides all the benefits of Keygen EE without the need to manage infrastructure. This is the Keygen you already know and love.
Both Keygen CE and EE are the same code base. Actually, Keygen Cloud itself is an instance of Keygen EE in multiplayer mode. It's all the same code.
Yes — that means we run Keygen EE in Keygen Cloud, and use Keygen Cloud to license Keygen Cloud. It's wild, but the headers don't lie:
curl -v https://api.keygen.sh/v1/ping# ...# < Keygen-License: id="645993cd-e5f4-40e4-8a43-b35cefd04a8d",# iss="2023-03-15 20:03:03 UTC",# exp=""# < Keygen-Edition: EE# < Keygen-Mode: multiplayer# ...
*mindblown*
Why open source?
Going into this, you may have had looming concerns of financial instability at Keygen, or concerns of an "OuR gReAt JoUrNeY" post, but none of the reasons for choosing to open source Keygen are related to financial troubles, a lack of growth, or anything else negative. Keygen has been profitable since year 1, and continues to grow >50% year over year (YoY). Operating Keygen is my dream job, and I'm in it for the long haul.
So, please, curb those concerns. Keygen is simply evolving.
I've built and maintained many open source projects. Open sourcing Keygen is a way for me to (hopefully) be yet another example of how open source software can be sustainable, and another way to give back to the community.
The root "why" is that, actually, I've always wanted to do it. From day 1, I thought about building Keygen in public. But I didn't out of fear. And after I got my first customers, that fear grew. I didn't want to lose what I had. But I still always wanted to do it.
In addition to that looming desire to open source Keygen, there are a handful of other "whys" that ultimately pushed me to make Keygen's source code available. And one night I had a couple glasses of wine, started thinking crazy thoughts, and opened this issue.
Below is the expanded view of what's discussed in that issue.
Markets
The number one reason is: the current market. Every enterprise I talk to wants to self-host Keygen. The reasons vary from compliance, to security, to fear of us being a small team, to fear of SaaS, to looming fear of the current financial market, to scaling.
Up until today, Keygen has not been self-hostable. Over the past 7 years, I've explicitly chosen to focus on Keygen's cloud offering. I didn't want to be distracted by managing a self-hosted version as well as a cloud version. But over the years, more and more, I've wanted to offer a self-hosted option.
In the interim — to curb some of those concerns I mentioned above — I had even offered source code escrow to some enterprises. I thought, that way, I'd still be in control of the source code unless something unexpected occurred.
But even with that, a self-hosted option was still hot on the feature request list. And not only from enterprises. Even small businesses wanted that option, too.
During my internalized planning-and-brainstorming of that option, I thought, "if I'm going to all this trouble to make Keygen self-hostable, why not open source it so anybody can self-host it?" That "anybody" would include enterprises, of course, but also small businesses and personal projects that can't afford Keygen Cloud yet.
With that said — by open sourcing Keygen, I feel like I'm moving in the direction that my market wants me to move towards. A direction of choice.
Bus-factor
The dreaded bus-factor. When discussing Keygen with medium to large businesses, a recurring fear is one concerning the fact that Keygen is run and maintained by a single person. The bus-factor is a risk measurement, simply asking the question: "how many people can be hit by a bus before the business can no longer function?"
The answer for Keygen has historically been: 1 person.
One of the key benefits of open sourcing Keygen is that it eliminates its bus-factor of 1. Previously, Keygen was maintained by a single person (me), which made it vulnerable to disruptions if that person (me) was unable to continue maintaining it.
By open sourcing Keygen, I am ensuring that the project can be self-hosted and maintained by the community irrespective of myself.
Instead of hiring to eliminate the bus-factor problem, I chose to open source.
(Though, I am still looking for the right teammates.)
Longevity
The next related fear that is commonly discussed is longevity. Now, this is a fear that is pretty easy to curb with the right words. Keygen is a 100% bootstrapped business, and as mentioned earlier, it's been profitable since year 1. I work on it full-time and it continues to grow YoY. I continually improve Keygen based on customer feedback.
But there's still that concern — especially from the startup community — because Keygen hasn't taken on venture debt. Perhaps this is actually rooted in the bus-factor, but I find it funny because I typically have the same fear but for venture-backed startups.
However, in the unlikely event of Keygen LLC discontinuing support of Keygen, the open source community can take the reigns of the Keygen project, if they so desire.
Continuity
Related to longevity is business continuity. What happens in the event that Keygen LLC is shutdown? In addition to the open source community taking the reigns of the Keygen project, we are working on a migration path from Keygen Cloud to Keygen EE (and vice-versa), where customers can export and import their Keygen resources between instances of Keygen (e.g. Keygen Cloud to a self-hosted instance of Keygen).
We understand that continuity is vital. By open sourcing Keygen, we hope to mitigate the risk of disruption and loss of value that can result from a traditional business closure, creating a more sustainable and enduring ecosystem around the project.
Trust
In addition to alleviating fears, I also want to build trust. And going open source can help accomplish that goal. Open source software, by its very nature, is built upon a foundation of transparency and collaboration. The code for an open source project is publicly available, and anyone can review it, audit it, test it, and change it.
We don't do anything nafarious at Keygen, and we want to prove that. We also want to prove that we're a secure and stable platform to build your licensing upon.
You will also be able to see the sheer number of tests Keygen has.
Feel free to clone the repository and poke around.
Copycats
I'm probably a little bit biased, but I see Keygen as a market-leader in the cloud-based Licensing-as-a-Service (LaaS) niche. And with that, as other founders know, come "copycats." Like clockwork, a new copycat appears every year.
It's incredibly disheartening to see API endpoints flat-out copied by a competitor, down to the URL and response payload (you know who you are). It's even more disheartening to read the documentation you've painstakingly written over the years stolen by the same competitor and not even reworded. Even worse still is when nobody notices this, much less cares, and their circle of friends on Twitter choose the copycat over you.
Now, I have "competitors" that flat-out plagiarize Keygen, and then I have competitors that compete with Keygen. I have respect for the latter, but not the former. (The former also normally don't last for more than a year or two.)
I'm hopeful that going open source can largely snuff these copycats out. After all, who would want to use the closed source copycat of an open source project?
I'm also hopeful that I don't eat these words.
Compliance
When you enter the enterprise space, you learn a lot of acronyms. Like SOC2, ISO27001, HIPAA, BAA, and GDPR. You also fill out a lot of security questionnaires.
It's much easier for enterprises to succeed in their strict security and compliance goals when they can self-host Keygen and their data. Some enterprises love Keygen Cloud, but others keep asking to self-host and I feel like the clock is ticking.
Keygen has also received interest from the public and defense sectors, so being auditable (and self-hosted) is table-stakes for these types of high-security contracts.
Rather than maintain a "Keygen Shield" platform, likely managing single-tenant instances of Keygen inside of private datacenters, I chose to open source. This pushes the burden of maintenance of many single-tenant instances of Keygen off of myself, and onto the enterprise engineering teams.
It also allows me to never fill out another security questionnaire again (as much as I wish this were the case, it never will be).
I feel like this a win–win. But time will tell.
Why ELv2?
I chose to license Keygen under the Elastic License 2.0 (ELv2) license because it provides the best balance between freedom and protection. The ELv2 license is a permissive fair-code license that allows you to use, modify, and distribute Keygen as long as you follow a few simple rules:
You may not provide Keygen's API to others as a managed service. For example, you cannot host Keygen yourself and sell it as a cloud-based licensing service, competing with Keygen Cloud. However, you can sell a product that directly exposes and utilizes Keygen's API, as long as Keygen cannot be used outside of your product for other purposes (such as your customer using an embedded Keygen EE instance to license their product in addition to your product).
You may not circumvent the license key functionality or remove/obscure features protected by license keys. For example, our code contains license gates that unlock functionality for Keygen EE. You cannot remove or change the licensing code to, for example, unlock a Keygen EE feature in Keygen CE.
You may not alter, remove, or obscure any licensing, copyright, or other notices.
Anything else is fair game. There's no clause that requires you to open source modifications or sacrifice a goat while listening to 90s keygen music.
You can self-host Keygen EE to license your enterprise application.
You can embed Keygen CE in your on-premise application.
You can run Keygen CE on a private network.
You can fork Keygen and go closed-source.
If the ELv2 license doesn't work for your company, please reach out.
Why not AGPLv3?
Fear, being one reason. I've worked hard on Keygen over the last 7 years , and although I'm open sourcing Keygen today, I'm not doing so without fear.
Fear of a well-funded corporation taking Keygen and selling it as a Keygen Cloud competitor, putting me out of business (the classic ELv2 justification, I know).
Fear of my license choice blowing up in my face.
Fear of losing a significant number of Keygen Cloud customers to Keygen CE.
Fear of Keygen EE not taking off how I think it will.
Fear of a security vulnerability being exploited.
Fear of the unknown.
But I digress —
Since Keygen is now open source (err… source-available?), all past issues and pull requests are now public, and you can read my inner dialog here and here discussing the choice. It was a tough decision, but ultimately, I felt ELv2 was the best choice for my business's longevity. AGPLv3 didn't offer the protections I was looking for.
In addition — in discussions with our enterprise customers, very few had a problem with ELv2, but many had problems with AGPLv3 and other GPL-style licenses. These discussions had a big impact on the license choice.
ELv2 also allows me to keep Keygen CE and Keygen EE in a single code base. If I went with AGPLv3, I would have been forced to use an "open core" model, with a closed source enterprise edition. And if I didn't go open core, somebody would just rip out the EE licensing code and open source their "changes" under AGPLv3.
Open core sounded too complex for me to manage. I didn't want that much churn in my code base. The potential for breaking things was too high. Not to mention that I'd need to either split and rewrite my git repo's history, or start 2 whole new repos. I didn't want to lose the 7 year history of the repo. And thinking of having to make changes across 2 repos for Keygen Cloud also sounded like a nightmare.
I also didn't want to mess with dual-licensing, either, because it too can add unnecessary complexity (e.g. the growing-in-popularity dual-licensed ee/ directory pattern).
I didn't want more complexity. I wanted a simple license with simple terms.
In the end, I chose ELv2 because it made the most sense for Keygen LLC.
As a bonus, the ELv2 license allows me to have a single code base that demos how Keygen can be used to license an application, since Keygen uses itself for licensing.
Will I change my mind later? Maybe. But don't bet on it.
What's next?
There's a lot I want to do. From introducing SAML/SSO for Keygen EE, to expanding upon our distribution system with native support for ecosystems like npm, Rubygems, Docker, Sparkle, PyPI, Composer, and more.
If there's something specific you want to see, open an issue or join in on an existing discussion (which at this point in time probably consists of me talking to myself). Or if there's something your business needs right now, open a pull request.
If you're interested in obtaining a Keygen EE license, please reach out. We're currently working on a migration path from Keygen Cloud to Keygen EE for Ent customers.
If you're interested in self-hosting Keygen CE, check out the code on GitHub.
And of course, Keygen Cloud is available as a fully-managed service.
It's been an exciting journey, and we're just getting started.