Keygen is now Fair Source
Tuesday, August 6th 2024
Last year, I made Keygen source-available under the ELv2 license. It was a scary thing to do — making an existing closed-source business source-available. But although scary, it was something that I wanted to do since the beginning. And the result has been almost all positive. That's kind of crazy to think about.
Today, I'm excited to announce that Keygen is relicensing under the Fair Core License (FCL). The FCL is a Fair Source license — or more accurately — a Fair Core license.
If you're not familiar with the "Fair Source" term, that's because it's new. Typically, we'd use the term "source-available" for software like Keygen that isn't quite Open Source. However, that term casts a wide net and doesn't communicate any user freedoms beyond the freedom to read the source code. In reality, most source-available software under common licenses like the FSL, BUSL, ELv2, SUL, etc., provides the freedom to read, use, modify, and redistribute, with "use" typically restricted in a non-compete fashion. But "source-available" doesn't convey this reality.
Fair Source is meant to sit between Open Source and source-available. It's not meant to replace Open Source, diminish Open Source, or claim to be Open Source. It isn't Open Source, and never has been. It's a term to clearly communicate something that's close to Open Source, if we envisioned a gradient between Open Source and source-available, and something that eventually contributes to Open Source via delayed Open Source publication (DOSP).
Fair Source projects undergo DOSP. They are publicly available to read and provide the freedom to use, modify, and redistribute, with minimal restrictions to protect the producer's business model. Fair Source values both user freedom and developer sustainability.
Open Source is a great way to share infrastructure, and Fair Source is a great way for companies to safely share their core products. They can live in harmony, and we can hopefully get rid of the "open-washing" problem, and also maybe (and hopefully) the free-rider problem.
We're guilty of "open-washing" ourselves, because of the lack of nuance in the alternative terms, but hopefully Fair Source can help prevent it in the future.
In this post, we'll discuss why we're relicensing from ELv2 to FCL, and what that actually means for us, and for you.
Why I originally chose ELv2
I go into more detail in the original annoucement post, but the main takeaway from that post is that I wanted to continue to monetize Keygen via the SaaS i.e. Keygen Cloud, like I had always done, but I also wanted to start monetizing Keygen via self-hosting.
To monetize self-hosting, I planned on offering an Enterprise Edition, Keygen EE, which would supplement the free self-hosted Community Edition, Keygen CE. The Enterprise Edition would add additional features for larger companies, and come with self-hosting support.
With that monetization strategy in mind, I also wanted to make Keygen as open source as possible without adding unnessary risk to the sustainability of the existing business.
To do this, I needed a license that 1) prevented direct SaaS competition, and 2) also allowed an "open core" business model.
I looked at SSPL, but it didn't offer what I needed. I then looked at the Business Source License (BUSL), and while it offered help with 1), it unfortunately didn't offer any help with 2) — somebody could just publicly fork the repo and give themselves, and others, the EE features without any ramifications, a direct threat to my monetization strategy.
If Keygen were a new project, I could simply add these EE features into an ee/ directory and license
the main repository under BUSL or some other license, and then license the ee/ directory separately
like popular open core projects, such as Cal.com,
Posthog,
and Plausible.
(Another popular route for new projects is a plugin-architecture.)
But the problem was that Keygen was not a new project. I didn't want to refactor years of code into
an ee/ directory. That would be too much code churn, and I ultimately deemed it too risky. Moving
around thousands of lines of code didn't make sense.
I wanted a license that would make these things simple, so that I didn't have to think too hard about these types of things.
Enter the Elastic License 2.0, or ELv2.
The ELv2 license allowed me to 1) prevent direct SaaS competition, and 2) protect those EE features with a license key. I could retrofit 2) into the existing code base without too much churn. I ultimately thought this was a fitting license, since I could actually use Keygen to license Keygen EE. (And I did — even licensing Keygen Cloud itself.)
The ELv2 can even be more permissive than open core projects under AGPLv3, given that you're like 99.999% of users who don't want to directly compete with Keygen Cloud. You can read the source, use it, modify it, and even outright fork it into a private derivative work — something you can't do when licensed under AGPLv3.
For that 99.999%, Keygen is very similar to an open core project — you can use most parts, but not everything without an additional license or agreement. Just like newly open core Plausible, and existing open core projects like GitLab, Posthog, Cal.com, among many, many others
As a user, ELv2 means 1) you can't compete with Keygen Cloud (sorry not sorry to the 0.001%), and 2) you can't remove or modify Keygen EE features protected by a license key — i.e. you can't give yourself the Keygen EE features in Keygen CE.
But herein lies the problem.
The problem with ELv2
After a year of selling Keygen EE (which has done well!), I discovered some recurring — I guess I would call it — "pushback." It comes in as a concern more or less along the following:
"What happens to our access to Keygen EE in the event that Keygen LLC goes out of business?"
This is one of the more confusing parts of the ELv2, and that is — what happens if the licensor goes out of business?
If you remember, under ELv2, you can fork — but you can't modify or remove the features protected by license key, i.e. Keygen EE, without legal ramifications. But that also means that you effectively can't use those features anymore if the licensor goes bust, because come renewal time, there's nobody to renew the license.
This is a big risk for any company buying a license for an ELv2 project, and one I've had to discuss with potential buyers. One of the main selling points of self-hosting — not relying on a third-party SaaS — starts to lose its appeal after risk assessment.
The only "workaround" for this issue with ELv2 is to force the buyer into purchasing a perpetual license (i.e. $$$), so that even if the licensor were to go bust, the licensed features can always be used, legally.
I hate this workaround, because it comes off as predatory. It feels like it goes against Keygen's open source values, and my own values.
This also directly goes against two of the reasons I went source-available — longevity and continuity.
So where do we go from here?
The solution
Starting today, we are relicensing Keygen under the Fair Core License (FCL). The FCL is very similar to the ELv2 we previously used. The FCL was ultimately born out of the Functional Source License (FSL), and like the FSL, it eventually changes to a fully open source license — either Apache 2.0 or MIT — after 2 years. So you can think of the FCL as a blend of the FSL and the ELv2.
The idea for the Fair Core License was born out of me interjecting myself into Sentry's discussion around relicensing their company from BUSL to the Functional Source License (FSL). I even made some comments on some ambiguities in the FSL 1.0 that ultimately led to a clearer FSL 1.1, in my opinion.
I absolutely loved the FSL, because I love open source. The thought that a business can make their source code available under mostly-permissive terms, while protecting themselves from direct competition (but not forever), while also eventually contributing to open source, was awesome. I liked it so much that I wanted to adopt it.
But like BUSL before it, FSL had the same fundamental problem for businesses that wanted to not only monetize via SaaS but also via a commercial self-hosted edition — there was no provision for separating a "community" edition from a "commercial" edition outside of an "open core"-style model. And even then, the commercial features would never be open source unless you write a one-off commercial license that behaves like the BUSL or FSL. It just didn't really work.
So the question remained, with the Functional Source License, how do you protect your commercial edition's features, while still allowing them to eventually become open source?
Enter, the Fair Core License.
The Fair Core License, or FCL, is a mostly-permissive non-compete license, very much like the FSL from which it originated. The FCL was drafted by Heather Meeker and myself, based on the FSL. Heather helped draft both the FSL and the ELv2, so I thought she was the perfect fit to help create the ideal blend of FSL and ELv2.
Like the FSL, it restricts direct competition, such as a Keygen fork competing with Keygen Cloud.
Unlike the FSL, it also has a clause that aligns more with an "open core"-style project, where you want some parts of your code base, like our EE features, to be available in a commercial edition.
We accomplish that through the addition of a couple limitations on top of the FSL, borrowing from the license key limitation of ELv2:
"You must not move, change, disable, or circumvent the license key functionality in the Software; or modify any portion of the Software protected by the license key to:
- enable access to the protected functionality without a valid license key; or
- remove the protected functionality."
With these limitations, the FCL blends the sustainability and freedoms of the FSL and of the ELv2 into a brand new license that is a great fit for other "open core"-style (or "fair core") projects.
Here's the diff between the FCL and the FSL:
-# Functional Source License, Version 1.1, Apache 2.0 Future License +# Fair Core License, Version 1.0, Apache 2.0 Future License ## Abbreviation -FSL-1.1-Apache-2.0 +FCL-1.0-Apache-2.0 ## Notice Copyright ${year} ${licensor name} ## Terms and Conditions
### Licensor ("We") The party offering the Software under these Terms and Conditions. ### The Software The "Software" is each version of the software that we make available under these Terms and Conditions, as indicated by our inclusion of these Terms and Conditions with the Software. ### License Grant -Subject to your compliance with this License Grant, and the Patents, -Redistribution and Trademark clauses below, we hereby grant you the right to-use, copy, modify, create derivative works, publicly perform, publicly display-and redistribute the Software for any Permitted Purpose identified below. +Subject to your compliance with this License Grant and the Limitations, +Patents, Redistribution and Trademark clauses below, we hereby grant you the+right to use, copy, modify, create derivative works, publicly perform, publicly+display and redistribute the Software for any Permitted Purpose identified+below. ### Permitted Purpose A Permitted Purpose is any purpose other than a Competing Use. A Competing Use means making the Software available to others in a commercial product or service that: 1. substitutes for the Software;
2. substitutes for any other product or service we offer using the Software that exists as of the date we make the Software available; or 3. offers the same or substantially similar functionality as the Software. Permitted Purposes specifically include using the Software: 1. for your internal use and access; 2. for non-commercial education; 3. for non-commercial research; and 4. in connection with professional services that you provide to a licensee using the Software in accordance with these Terms and Conditions. +### Limitations + +You must not move, change, disable, or circumvent the license key functionality+in the Software; or modify any portion of the Software protected by the license+key to:+ +1. enable access to the protected functionality without a valid license key; or+ +2. remove the protected functionality.+
### Patents To the extent your use for a Permitted Purpose would necessarily infringe our patents, the license grant above includes a license under our patents. If you make a claim against any party that the Software infringes or contributes to the infringement of any patent, then your patent license to the Software ends immediately. ### Redistribution The Terms and Conditions apply to all copies, modifications and derivatives of the Software. If you redistribute any copies, modifications or derivatives of the Software, you must include a copy of or a link to these Terms and Conditions and not remove any copyright or other proprietary notices provided in or with the Software. ### Disclaimer THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, TITLE OR NON-INFRINGEMENT. IN NO EVENT WILL WE HAVE ANY LIABILITY TO YOU ARISING OUT OF OR RELATED TO THE SOFTWARE, INCLUDING INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF WE HAVE BEEN INFORMED OF THEIR POSSIBILITY IN ADVANCE. In the event the provision of this Disclaimer section is unenforceable under applicable law, the licenses granted herein are void. ### Trademarks Except for displaying the License Details and identifying us as the origin of the Software, you have no right under these Terms and Conditions to use our trademarks, trade names, service marks or product names. ## Grant of Future License We hereby irrevocably grant you an additional license to use the Software, under the Apache License, Version 2.0, that is effective on the second anniversary of the date we make the Software available. On or after that date, you may use the Software under the Apache License, Version 2.0, in which case the following will apply: Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. As you can see, not much has changed.
And the best part?
Rather than split your code base across ee/ directories, you can protect those commercial parts
of your project with a license key, which is functionally the same as separately licensing them,
but without having to have those parts be under a separate one-off commercial license that
will never be open source.
With the FCL, you get to license everything under the same license terms, all the while protecting commercial features. Simpler code, simpler terms, which is what I originally wanted with ELv2.
And like the FSL, it changes to an open source license after 2 years — either Apache 2.0 or MIT. In the case of Keygen and the FCL, after 2 years, it will change to the Apache 2.0 license.
But! — doesn't that mean that anybody can eventually modify the source code to use Keygen EE features without a license key?
Yes, and that's okay. Good, even!
From a business perspective —
The open source release will be 2 years old, and without support guarantees, so I don't believe it will have a noticeable effect on the types of companies Keygen EE is marketed towards. But I believe it will have a positive effect on the individuals and companies that fall outside of our target market.
Being 2 years old also puts any SaaS competition far enough back to not be a concern. So we become even closer to open source without compromising sustainability.
From a user perspective —
It ensures the longevity and continuity of the project, providing assurance that Keygen will remain available and maintainable for all of the businesses that depend on it. This aligns with my original reasons for going source-available.
(This also aligns with our open source values, recognizing that Keygen is built on top of OSS and wouldn't exist without it.)
From a buyer perspective —
Revisiting the original problem with ELv2 — the risk of the licensor going bust — with FCL, the buyer now just needs a 2 year license contract to alleviate that risk before they can move to the open source release. And starting today, we now clearly offer 2 year contracts. That, at least to me, feels much less predatory than before.
The FCL offers more user freedom than the ELv2, while still focusing on developer sustainability, and we're all about that. The closer we can sustainably get to open source, the better.
If your project monetizes self-hosting, consider adopting the FCL for your project; if it doesn't monetize self-hosting, look at the other Fair Source licenses such as the FSL.
If you have any questions, please don't hesitate to reach out.
Until next time.