Meet the Fair Core License

Fair Core is to Fair Source what Open Core is to Open Source.

A perfect blend of the Functional Source License 1.1 & the Elastic License 2.0 balancing developer sustainability & user freedom. Safely share projects with commercial features in a single codebase & under a single license while eventually contributing it to Open Source via delayed Open Source publication.

The pitch

The Fair Core License, or FCL, is a mostly-permissive non-compete Fair Source license that eventually transitions to Open Source after 2 years.

The text

FCL-1.0-ALv2 (raw)
FCL-1.0-MIT (raw)

The FAQ

What user freedoms does the FCL offer?

The FCL is a Fair Source license that allows a user to read, use, modify, and redistribute a project, where "use" is any use case that does not compete with the business interests of the author. For the large majority of users, this will mean that the user can use the project how they see fit, since most users do not wish to compete with the author.

The FCL is designed to balance user freedom and developer sustainability, allowing companies to monetize their cloud-based and self-hosted projects, and safely share their core products without the risk of harmful free-riding.

For more information about Fair Source and the user freedoms and goals of the initiative, please see the Fair Source website.

What is a competing use under the FCL?

Under the FCL, a competing use is any use case that competes with the business interests of the author. For most projects licensed under the FCL, this will mean creating a competing cloud or SaaS offering, but ultimately, this will depend on how a particular project is being monetized by the author.

But since the FCL transitions to Open Source after 2 years, any user is free to use an Open Source version of the project for a competing use.

How is the FCL a blend of the FSL & ELv2 licenses?

The FCL is largely based on the FSL license, but includes additional limitations derived from the ELv2 license. These additions make the terms more suitable for projects that monetize not only SaaS, but also self-hosting.

How is the FCL different from the FSL?

The FSL, by design, offers little protection for self-hostable projects with commercial features, e.g. a self-hostable project with an Enterprise Edition and a Community Edition. In this example, under the FSL, somebody could fork and modify the project to grant themselves the EE feature set in CE without recourse.

The only way around that is to separately license the commercial features under a one-off proprietary license, but then those features will never become Open Source.

In contrast, the FCL allows you to safely share all your code under a singe codebase and license, and eventually contribute all of it to Open Source.

How is the FCL different from the ELv2?

Like the ELv2, the FCL uses license keys to gate commercial features. However, the ELv2 fails to protect users' long-term access to those commercial features if the licensor shuts down and is unable to renew license keys. After a user's license key expires, their access to the commercial features is lost forever.

In contrast, the FCL safeguards a user's long-term access by eventually converting to an Open Source license. We wrote about our journey relicensing from ELv2.

How are commercial features safely shared?

Your project's commercial features can be gated with a license key. The FCL includes provisions that protect those features from unauthorized access. Instead of separately licensing your commercial features under a proprietary license, e.g. all files in an ee/ directory, they can all live under the same codebase and license.

What types of projects are a good fit for the FCL?

Projects with commercial features that are self-hosted or run on-premise, and want to safely share all of their code — not just some of it. If your project doesn't monetize self-hosting via commercial features, you may want to consider the FSL instead.

In addition, the FCL may be an ideal choice for projects moving from a closed source model to Fair Source, because commercial features can simply be wrapped in a license key check, requiring minimal project reorganization.

How does the FCL contribute to Open Source?

Like the FSL, projects licensed under the FCL will transition to an Open Source license after 2 years, balancing developer sustainability and user freedom.

What Open Source licenses are supported?

Like the FSL, the FCL supports Apache 2.0 and MIT change licenses.

Why only Apache 2.0 & MIT?

We're following what the FSL chooses to support. More info can be found on the FSL website. If you need something different, feel free to open an issue on GitHub.

How exactly does the 2-year period work?

The 2-year timeframe applies to each software version made available, whether through pushing a Git commit, publishing a package to a repository, sending via an email attachment, or mailing out a floppy disk via snail mail.

For example, you could clone a Git repository, run git checkout `git rev-list -n 1 --before='2 years ago' master` and, given the LICENSE file is FCL, use that version under the Open Source terms of the change license.

How is the FCL different from Open Core?

Both the FCL and Open Core restrict access to certain parts of a project's codebase, particularly commercial features. In Open Core, these features are often closed source or separately licensed under an ee/ directory.

The FCL, however, uses license keys to restrict commercial features. The restriction method differs, but the effect is the same. Compared to Open Core, the FCL provides a simplified way to license an entire project — its core and its commercial features — under the same terms and in a single codebase.

For projects moving from closed source to Fair Source, the FCL can be advantageous because it doesn't require project reorganization. In Open Core, commercial features need to be extracted and separately licensed or made closed source, causing potential code churn and risk. In contrast, the FCL allows a project's commercial features to simply be wrapped in a license key check.

Another advantage of the FCL is that commercial features will eventually become Open Source. In contrast, an Open Core project's commercial features will never become Open Source, unless a proprietary license is used which is delayed Open Source.

Finally, the FCL is a non-compete license, unlike Open Core, which typically doesn't restrict on endeavor, though that also depends on the proprietary license used.

Who's involved in the FCL?

The FCL was drafted by Heather Meeker and contributed by Keygen. Heather is a lawyer well-known for her involvement in Open Source, having helped draft many licenses, including the FSL and ELv2 licenses.

The FCL is a derivative of the FSL, created by Sentry, and incorporates elements inspired by the ELv2, created by Elastic.

Who's using the FCL?

It's used by us, Keygen, among others, and we'd love for more to join in.

Add your project on GitHub.