NFSL

Huh?

The NonFunctional Source License (NFSL) is a Fair Source license that converts to Apache 2.0 or MIT after a duration you specify. It is designed for SaaS companies that value both user freedom and developer sustainability, but also value choosing their own timeline more than they value originality. NFSL provides everything a developer needs to use and learn from your software without harmful free-riding, except for us free-riding on the Functional Source License by copying it and changing the fixed two year timeline to be whatever duration you want.

NFSL-1.0-ALv2 (raw)

NFSL-1.0-MIT (raw)

How exactly does the timeline work?

The timeframe you specify applies to each software version that is made available. Methods of making software available include pushing a Git commit, publishing a package to a repository, mailing out a CD in a tin, or casting to sea the code as a bottled message.

Specifying the Timeline Duration

Use of the NFSL requires you to use the following format syntax to specify the duration parameter, for use in the template, that determines how soon your software automatically converts to the permissive future license (MIT or Apache 2.0).

Duration Format Syntax

Format: duration: <integer> <unit>[ <integer> <unit>]* where unit is: years, months, weeks, days

Each <integer> must be a positive whole number
Units can be singular or plural (1 year or 2 years)
Multiple units can be combined with spaces
When this format definition is followed precisely, it is compatible with git's --before option for practical verification, and can be used in an NFSL license.

Duration Examples

Single unit durations:

2 years
18 months
90 days
12 weeks
1 year
36 months

Mixed unit durations:

1 year 6 months
2 years 3 months
1 year 3 months 2 weeks
3 years 6 months

Verifying License Conversion with Git

The git-compatible duration format enables a practical workflow for users to verify which versions of your code have converted to the permissive license:

# For a project licensed as NFSL with "2 years" duration
git clone <repository>
git checkout `git rev-list -n 1 --before="2 years ago" main`
# If LICENSE.md is NFSL, you can now use this version under MIT or Apache 2.0

# For a project with "18 months" duration
git checkout `git rev-list -n 1 --before="18 months ago" main`

# For a project with "1 year 6 months" duration
git checkout `git rev-list -n 1 --before="1 year 6 months ago" main`

This allows anyone to easily identify and use versions of your software that have automatically transitioned to open source licensing. Just like FSL, but with your own timeline. You know, that thing we changed.

Who?

Here are some product logos we thought looked nice. Among these, we like the ones we're familiar with. We appreciate their support of the FSL that we free-rided on, and we figured they wouldn't mind the extra promotion.

Add yours on GitHub, and if anyone actually uses this, we may replace these placeholder logos.

FAQ

Why?: Many SaaS companies wish to make the source code for their core products available under permissive terms without the risk of harmful free-riding. Having yet another license for this purpose to choose from makes life a bit more difficult for both producers and consumers of such software.
What is harmful free-riding?: Harmful free-riding is the sort of free-riding that leads to the free-rider problem: “We benefited from the FSL's resources, but did not pay for them, or maybe we under-paid since we did a free trial of Sentry. Regardless, our contribution may be under-produced, overused, or degraded vs FSL. Despite aspirations to be cooperative (a prosocial behaviour), we're free-riders perpetuating the free-rider problem.”
Why not Open Source?: Open Source does not protect against harmful free-riding. Also, we wanted to free-ride on Sentry's FSL instead. We decided what was beyond FSL is not being constrained to exactly two years - a one-size-fits-all timeline that felt unnecessarily strident to us. So we borrowed FSL's excellent but persnickety work and revolutionized the licensing landscape by changing one very impactful parameter. Creating a new revolutionary project by changing literally one parameter is what Open Source means to us; but software licensed by this or FSL are not open source, so go figure.
What about AGPLv3 though?: AGPLv3 is not permissive enough. As a highly viral copyleft license, it exposes users to serious risk of having to divulge their proprietary source code. NFSL does not introduce this risk, so NFSL software can be adopted at organizations where AGPL is outside of policy.
Why not open core?: Open core is not permissive enough. It restricts based on feature set, such that some product features are never open. Moreover, the percentage of features that are restricted is highly variable from product to product. With NFSL, all product features are available now for almost all uses, and are soon fully permissive.
Why not [some other alternative]?: We just asked our LLM assistant what license we should use, and it recommended FSL, but we just couldn't come to terms with the fixed two-year duration. We've made similar attempts over the decades to find a license. None has truly caught on with us, and we knew we would outright abandon any we tried that we didn't create ourselves.

NFSL's immediate predecessor is obviously the Functional Source License (FSL), which itself evolved from the Business Source License (BSL or BUSL). FSL's time-based approach is great, and we borrowed their originality. Each NFSL implementation is essentially the same license — we just let you pick your own duration instead of dictating exactly two years. NFSL is FSL with one parameter changed. That's the innovation, and it's transformative.
What can I do with NFSL software?: You can do anything with NFSL software except undermine its producer. You can run it for almost all purposes, study it, modify it, and distribute your changes, including proposing improvements back to the producer. After the duration specified in the license (which the producer gets to choose, unlike FSL's rigid two years), it becomes permissive Open Source software under Apache 2.0 or MIT.
Why only Apache 2.0 and MIT?: Because FSL chose these we assume for good reason and we didn't want to expend energy thinking for ourselves.
Okay, but I can use NFSL with a different change license, right?: No. If you do this, you'll have to call it something other than NFSL. We're already pushing it by taking FSL and changing one thing - if you change the target license too, just use the Business Source License directly. It's similar to NFSL (and FSL) but allows for any change license.
What's with the name?: It's like FSL, but less functional in standardizing the community.
It's NonFunctional. ¯\_(ツ)_/¯
What's the backstory?: We read Sentry's FSL announcement, thought "this is great but exactly two years feels restrictive," and decided to free-ride on their excellent work by making that one thing configurable. That's it.
How do I adopt NFSL for my product?: Glad you asked! Check out our guide on GitHub.