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)

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.
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, or mailing out a CD in a tin. For example, if you specified 18 months, one could clone a repo, run git checkout `git rev-list -n 1 --before="18 months ago" master`, and—if LICENSE.md is NFSL—use that version under MIT or Apache 2.0. Just like FSL, but with your own timeline. You know, that thing we changed.
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.