Request for feedback on NFSL (NonFunctional Source License) - a generalized fork of FSL

[JeffreyUrban]

Hi FSL team,

First, thank you for creating the Functional Source License! It's a thoughtful approach to balancing open development with sustainable business models, and I appreciate the work you've put into it.

I've created the NonFunctional Source License (NFSL) as a derivative of FSL 1.1. The key difference is that NFSL generalizes the fixed 2-year conversion period to support any customizable duration (e.g., 6 months, 18 months, 5 years, etc.).

What I've done:

• Renamed to "NonFunctional Source License" per FSL's requirement that derivatives use a different name
• Maintained all the same terms and restrictions as FSL
• Changed only the duration mechanism from fixed 2 years to a customizable ${duration} placeholder
• Properly credited FSL and Sentry in all documentation
• Created a companion website at https://notFSL.fyi that mirrors the style and presentation of fsl.software (but presented as satire/parody, since you're goal was standardization, and NFSL deviates from that)

Repository: https://github.com/JeffreyUrban/notFSL.fyi

I believe I'm complying with the FSL terms by using a different name and providing proper attribution. However, given that the website presentation is satirical in nature (mimicking your design and README style), I wanted to reach out directly to ensure you're comfortable with this project being a fork and borrowing from your materials.

If you have any concerns or would like me to make changes, I'm happy to discuss. I respect the work you've done and want to make sure this feels friendly rather than disrespectful.

Thank you for considering this, and for creating FSL in the first place!

Best regards,
Jeffrey Urban

[MattiSG]

Hi Jeffrey,

Thank you for sharing your work here.

I'm not part of the team and probably not going to provide the sort of feedback you expect. Still, as a producer of digital commons and an advocate in the circles of power in the EU, I'd still like to share something.

I personally hold a very negative view on alternative licenses with minor differences, especially with a name that sounds very similar to the original. There is a lot of visibility (lobbying, even) work to be done on these before they take credibility and we can start questioning the absolute prerequisite of OSI-approved open source in many sectors. Adding variability that early in the process is, from my perspective, adding significant confusion and decreasing the chances of a breakthrough. Many powerful entities have an interest in leveraging FUD against these initiatives. I believe we should do our best to stand fully united. The Creative Commons won also because hard choices were made around the amount of variability one could offer. An arbitrary duration will be a major obstacle for any corporate or administrative adoption. The amount of work that will be needed to get the FSL approved anywhere will already be immense; if on top bureaucrats and legal people have to cope with “NonFSL” being actually FSL but with the added detail that you need to read the little details for each module, we're from my perspective shooting ourselves in the foot with a rocket launcher.

I am in no position to refrain the creativity of others, and I am sure there must be good reasons to choose different durations than 2 years. I still dare to recommend, however, to assess whether these reasons are truly worth hindering the whole adoption stage that lies ahead of us.

All the best,
Matti Schneider

[JeffreyUrban]

Matti, I appreciate your perspective on standardization, and I want to engage with it constructively, because I believe we overlap in our underlying interests towards the fair-source movement.

On fairness and who shapes licensing standards

I want to start here, because I think this is central to what ’fair’ in ’fair source’ should mean.

There’s a visibility bias in who participates in discussions about software licenses and community. The projects that dominate fair-source conversations are often well-funded startups with existing traction, a capability for and interest in fast time-to-market, and resources for conferences and advocacy. Meanwhile, the projects that most need longer timelines, multi-year development before first release, novel and complex work, and/or solo or bootstrapped developers with slow organic adoption curves, are precisely the ones least able to advocate for themselves. They’re still building. They’re not visible yet. They don’t have marketing budgets and established communities.

I’m starting to develop complex, novel projects, for which I wanted to try open development and expect gradual and organic user adoption. I’m working part-time and bootstrapped, with no marketing budget. That’s the nature of novel, complex work that’s on the opposite end of the spectrum from blitzscaling. This doesn’t have to be a failing of the project; it’s the natural timeline for some ambitious indie work. A 2-year window could easily open the source before the project finds market fit, and well before sustainable revenue is achieved. That’s effectively no window at all.

I don’t know how common projects like mine are, but I suspect they’re underrepresented in these discussions precisely because of their nature. It seems to me a fundamental principle of fairness (fair.io and fair licensing are explicitly about fairness, particularly for developer sustainability) that projects like mine be supported, even if we aren’t the majority by developer count, funding, or community awareness. I’d like to be able to sustain myself, in part, as a developer working outside of a startup or community project whose resources and ambition can accommodate a two-year window.

The FSL’s philosophy fits my needs perfectly: eventual openness, a commercial window for sustainability, alignment between developer and user interests. If FSL had existed with flexible duration when I started an earlier multi-year project, I might have used it from day one, and that project could have been openly developed under a fair license from the start. Instead, it’s stayed closed, in part because an appropriate license option wasn’t available for consideration. I’m now considering opening that project under NFSL. The fair-source movement could gain projects it’s currently not including… not through ideological disagreement, but simply because the timeline parameter doesn’t match the adoption curve of solo, bootstrapped, novel, and/or complex work.

I’m not asking for my timeline to become the timeline. I’m asking for fairness through flexibility, which also helps an academic who needs 1 year for reproducibility, a game developer who needs 6 months before letting the community fork a failed experiment, and the infrastructure developer who needs 20 years. Maybe someone working on a radical Web3 blockchain innovation needs 5 minutes for their algorithmic contract code; I don’t know, and if the goal is to be an inclusive standard for the wider community, we shouldn’t claim to know the boundaries of sensible timelines for everyone’s use case and market context.

Duration is a parameter, not a philosophy. The FSL already permits configuration of the licensor and of course the repository. Someone may need 5 minutes. Sentry needs 2 years. The contributor of this issue on fair.io needs >2 years for public utility infrastructure software. I need 10 years. These aren’t philosophical disagreements, they’re different contexts requiring different numbers within the same underlying framework.

On broader potential applications

I want to be clear that what follows is aspirational. Fair-source licensing would need to be adopted by providers, purchasers, or regulators to realize these benefits, and that adoption is far from certain. But I think it’s worth articulating who could be served by flexibility in duration, because it suggests fair-source may have potential to reach well beyond its current base.

Safety-critical systems. I spent years supporting nuclear safety systems running on platforms up to 40 years old whose original creators had long since gone bankrupt and whose assets have been acquired multiple times over by companies who aren’t even in the same line of business. In domains like nuclear, medical devices, and avionics, FDA approval, DO-178C certification, and nuclear regulatory compliance regularly exceed 2 years before a single unit ships. For vendors in these spaces, a 2-year window doesn’t provide a commercial window at all; the source would open before the product has generated meaningful revenue to recoup R&D investment. The economics simply don’t work, and vendors who might otherwise be interested in fair-source would likely conclude they cannot accept those terms.

Novel infrastructure software. Harvard’s Stratos Idreos, a leading researcher in database systems, observed that genuinely novel database architectures have historically required approximately 10 years to develop. Foundational projects like PostgreSQL (started 1986, matured as an open-source release in 1996) were developed in academic contexts, or like Google Spanner (paper released in 2012, product released 2017) with substantial corporate resources, or like Cockroach DB (started 2014, version 1.0 in 2017) with substantial VC backing. Fair-source with appropriate timelines could potentially enable a path that hasn’t really existed: the indie developer or small team creating genuinely novel infrastructure software with open development and eventual full openness, without requiring institutional or venture backing.

Consumer and institutional protection. Consider the Google Jamboard: $5000 digital whiteboards sold heavily to schools, introduced in 2016, sold until (estimated) 2020-2021, unusable as of 2024, now becoming expensive e-waste with schools having no recourse. The same pattern repeats across many consumer and IoT devices. Companies sell hardware with proprietary software, end support after 2-4 years, leave users with bricked devices. If fair-source licensing with appropriate durations were adopted in these contexts, whether through vendor choice, purchaser requirements, or regulatory mandate, it could mean that when vendors exit, source opens, communities can maintain discontinued products, and functional hardware doesn’t become landfill. Schools, hospitals, and municipalities operating on limited budgets with multi-year procurement cycles and 10+ year device lifespan expectations could be protected from vendor abandonment. This connects to right-to-repair, sustainability, and e-waste reduction... movements with significant public support and political traction that could become natural allies.

Government procurement. You’ve advocated for convincing governments to require fair-source licenses from suppliers. I think that’s exactly right, and I support that. But if governments mandate fair-source and the only option is 2-year FSL, vendors of infrastructure software face an impossible choice: they cannot open their source before they’ve had opportunity to recoup multi-year R&D investments, so they would need to decline. And purchasers would need to accept proprietary, because no fair-source alternative exists that matches their procurement context. Duration flexibility could enable successful policy advocacy across sectors. A mandate for fair-source licenses on critical infrastructure could succeed if vendors can choose durations appropriate to their product lifecycle, where it might otherwise fail for infrastructure while succeeding only for SaaS.

On complementarity rather than competition

Fair-source is currently proven in fast-moving SaaS and developer tools. It has not yet been proven in safety-critical systems, long-lifecycle infrastructure, or regulated industries. Those sectors are unlikely to adopt until the model is established elsewhere, which is what FSL is doing brilliantly on its home turf. But by the time conservative industries are ready to consider fair-source, they’ll be starting projects with 10+ year development cycles for 20-40+ year operational lifetimes. If longer-duration options exist when that moment arrives, fair-source could expand into those sectors. If not, the reach of fair source may remain limited to the markets where it first succeeded.

I see NFSL not as competition with FSL, but as preparation for additional contexts, from indie developers like myself, to potential future applications in safety-critical infrastructure, consumer protection, and institutional investment. I welcome the community’s thoughts on whether duration flexibility might better be incorporated into FSL itself, or whether complementary licenses serving different contexts makes more sense. Either approach seems workable to me; what matters is that fair-source becomes genuinely fair across the diversity of legitimate development timescales.

On confusion and discoverability

Regarding your concern about alternative licenses with similar names: I want to address this directly because I think the positioning aids discoverability, while preventing confusion. Timeline flexibility is a major difference in access to this kind of license, despite the minor difference in license text. That’s precisely why I wanted the name to clearly signal the relationship to FSL rather than obscure it, while highlighting the difference. Someone searching for fair-source options should find both, understand the relationship, and choose appropriately. Discoverability can reduce license proliferation: if developers needing longer timelines can easily find an existing option that meets their needs, they're less likely to create yet another variant covering similar ground. I searched and found no suitable alternatives to FSL before creating NFSL.

The name ‘Nonfunctional Software License’ is deliberately and hopefully very obviously self-deprecating. ‘Functional’ versus ‘Nonfunctional’ isn't meant to sound similar; It’s meant to sound like a joke at my own expense, positioning FSL as the serious incumbent and NFSL as the oddball variant for edge cases. The websites reflect this same intent: fsl.software is the authoritative source; notFSL.fyi is intentionally self-deprecating, repeatedly citing its relationship as something different from, inferior to, and respectful of FSL, loudly presenting FSL as the more serious option. The goal is discoverability and honest differentiation, not competition or confusion, and I hope the naming and presentation makes that clear.

Thanks again for your thoughtful response.

[MattiSG]

Thank you for your detailed reply @JeffreyUrban! I appreciate the thoughtful list of use cases.
I fully agree with your points and the relevance of variability in the duration. Mine is only about confusion and the obstacles it induces in advocacy.

Concrete suggestion: how would you feel about replacing the “self-deprecating” aspect of the naming for one that would support both goals of flexibility and adoption, by using instead a name such as “Functional Software License — Flexible variant: <months> delay”, which would enable registering an SPDX such as FSL-1.1-flex-60-MIT for an FSL 1.1 that waits for 60 months (5 years) before turning into an MIT? 🙂 This would enable emergence and consolidation of the most common durations and thus whitelisting of some SPDX, which is I believe a good proxy to think of how corporate & administrative adoption will look like in the long term.