n8n's Fair-code Experiment — Neither Open Source Nor Proprietary

“Source Is Open, Competition Is Not”

n8n is a workflow automation platform. It lets you visually design trigger, conditional branching, API calls, and data transformation pipelines. It’s similar to Zapier or Make (formerly Integromat), but with one critical difference: the source code is publicly available.

Yet n8n does not call itself “open source.” It calls itself Fair-code.

Aspect	MIT / Apache	Fair-code (n8n)	Proprietary
View source code	Yes	Yes	No
Modify and self-use	Yes	Yes	No
Commercial use (internal)	Yes	Yes	License required
Resale / hosted service	Yes	No	No
Fork into competing product	Yes	No	No
OSI-certified open source	Yes	No	No

The core principle: “Free for internal use, prohibited to resell.”

Why n8n Didn’t Choose MIT

The AWS Problem

The biggest risk of an MIT license is that a cloud provider takes the code and sells it as a managed service.

graph LR
    A["OSS company\ndevelops code"] --> B["Published under MIT"]
    B --> C["AWS/Azure/GCP launches\nManaged Service"]
    C --> D["Sells same product\nat larger scale than creator"]
    D --> E["Creator's revenue\ndeclines"]

    style C fill:#ffebee,stroke:#f44336
    style D fill:#ffebee,stroke:#f44336
    style E fill:#ffebee,stroke:#f44336

This is not hypothetical. It has happened multiple times:

Company	Product	AWS Response	Outcome
Elastic	Elasticsearch	Amazon OpenSearch Service	Elastic changed license (Apache to SSPL)
MongoDB	MongoDB	Amazon DocumentDB	MongoDB changed license (AGPL to SSPL)
Redis	Redis	Amazon ElastiCache	Redis changed license (BSD to RSAL)

When AWS forks an open source project and creates a managed service, the original creator has to compete against their own code. Competing against AWS’s infrastructure, sales force, and existing customer base is virtually impossible.

n8n sidestepped this problem from day one. By starting with Fair-code instead of MIT, they blocked the “fork n8n and sell Managed n8n” scenario at the license level.

The Sustainable Use License

n8n uses the Sustainable Use License. Its key clause:

“You may use the software for your own internal business purposes. You may NOT provide the software to third parties as a hosted or managed service.”

In plain terms: using it inside your own company is OK; selling it as a hosting service to others is not.

For the vast majority of users, this means fully free:

Internal company automation — free
Personal projects — free
Community contributions — welcome
Building a SaaS on top of n8n and selling it — requires a separate agreement

License Change History: Elastic, MongoDB, HashiCorp

Starting with Fair-code from the beginning, as n8n did, is rare. Most companies begin with MIT, Apache, or AGPL, encounter the AWS problem, and then change their license. These transitions invariably spark serious community conflict.

Elastic: SSPL, Then Back to AGPL

When	License	Why
~2018	Apache 2.0	Standard open source
2021-01	SSPL + Elastic License	Responding to AWS OpenSearch
2024-08	Added AGPL option	Easing community backlash

How it unfolded:

AWS forked Elasticsearch and launched Amazon OpenSearch Service
Elastic changed from Apache 2.0 to SSPL (Server Side Public License)
SSPL says: “If you offer this software as a service, you must open-source your entire service stack” — effectively blocking cloud resale
Community backlash: “It’s no longer open source”
AWS continued maintaining OpenSearch as an independent project
In 2024, Elastic offered AGPL as an additional option as a compromise

graph TB
    A["Apache 2.0\n(Fully open)"] -->|"AWS fork"| B["SSPL\n(Full stack disclosure\nrequired for service use)"]
    B -->|"Community backlash"| C["AGPL added\n(Compromise)"]

    D["Community trust"] -->|"SSPL switch"| E["Trust eroded"]
    E -->|"AGPL addition"| F["Partially restored"]

    style B fill:#ffebee,stroke:#f44336
    style E fill:#ffebee,stroke:#f44336

MongoDB: AGPL to SSPL

When	License	Why
~2018	AGPL v3	Copyleft (source disclosure when providing as a service)
2018-10	SSPL	Strengthened defense against AWS DocumentDB

MongoDB went a step beyond AGPL by creating SSPL. While AGPL required: “If you modify this software, disclose your source,” SSPL demands: “If you offer this software as a service, disclose the source of your entire service stack.”

AWS responded by building DocumentDB, an API-compatible service developed independently rather than using MongoDB directly. The result: SSPL successfully defended against forks, but it couldn’t defend against clones.

HashiCorp: MPL to BSL

When	License	Why
~2023	MPL 2.0	Mozilla Public License
2023-08	BSL 1.1	Defense against cloud resale

HashiCorp (Terraform, Vault, Consul) switched to BSL (Business Source License) in 2023. BSL’s key characteristics:

Source code: Publicly available (readable, modifiable)
Non-commercial use: Free
Competing service provision: Prohibited
Automatic conversion after 4 years: BSL becomes Apache 2.0 (eventually becomes fully open source)

The community response to HashiCorp’s BSL transition gave birth to OpenTofu — an open source fork of Terraform, hosted by the Linux Foundation, maintaining the MPL 2.0 license.

The License Spectrum

graph LR
    subgraph OPEN["Open Source (OSI-certified)"]
        MIT["MIT\n(Full freedom)"]
        APACHE["Apache 2.0\n(Patent protection)"]
        AGPL["AGPL\n(Service modifications\nmust be disclosed)"]
    end

    subgraph SOURCE["Source Available (Not OSI-certified)"]
        BSL["BSL\n(Competing services prohibited,\nopens after 4 years)"]
        SSPL["SSPL\n(Entire service stack\nmust be disclosed)"]
        FAIR["Fair-code\n(Resale prohibited)"]
        ELASTIC["Elastic License\n(Competing services\nprohibited)"]
    end

    subgraph CLOSED["Proprietary"]
        PROP["Source closed\n(License purchase required)"]
    end

    MIT --> APACHE --> AGPL --> BSL --> SSPL --> PROP

    style OPEN fill:#e8f5e9,stroke:#4caf50
    style SOURCE fill:#fff3e0,stroke:#ff9800
    style CLOSED fill:#ffebee,stroke:#f44336

License	Internal Use	Modification	Resale / Hosting	Fork & Compete	Notable Users
MIT	Yes	Yes	Yes	Yes	LangChain, MMU
Apache 2.0	Yes	Yes	Yes	Yes	HuggingFace, Qdrant
AGPL v3	Yes	Yes (disclose)	Yes (disclose)	Yes (disclose)	Grafana, MinIO
BSL 1.1	Yes	Yes	No (OK after 4 years)	No (OK after 4 years)	HashiCorp, MariaDB
SSPL	Yes	Yes	No	No	MongoDB, Elastic
Fair-code	Yes	Yes	No	No	n8n
Elastic License	Yes	Yes	No	No	Elastic (current)

Sentry (BSL license) and PostHog (MIT + paid cloud) follow similar patterns, demonstrating that Fair-code is not an isolated experiment but part of a broader industry trend.

n8n’s Business Results

Let’s verify whether the Fair-code strategy is actually working, with numbers.

Metric	Figure
ARR	$50M+ (as of 2025; estimated — private company, no official disclosure)
GitHub Stars	55K+
Self-hosted instances	Tens of thousands (estimated from Docker pulls)
Cloud users	Thousands of organizations (estimated)
Funding	Series B, ~$30M+
Team size	~100+
Integrations	400+ services

Pricing Structure

Plan	Monthly Cost	Executions	Key Feature
Community (self-hosted)	$0	Unlimited	Fair-code license
Starter	$20/mo	2,500	Cloud hosted
Pro	$50/mo	10,000	Advanced features
Enterprise	Custom	Unlimited	SSO, audit logs, SLA

n8n’s $50M+ ARR (estimated) validates the Fair-code model. Under MIT, there’s a high probability AWS would have launched “Amazon Workflow Automation (powered by n8n).” Fair-code prevented this scenario from day one.

Pros and Cons of the n8n Model

Pros

AWS defense: Resale is blocked at the license level, eliminating the need for a dramatic license change later
Self-host freedom: Internal use is completely free, minimizing adoption barriers
Community preservation: Source code is available, so contributions, bug reports, and plugin development remain possible
Legal clarity: The terms are simple — “use it yourself, OK; sell it to others, no”

Cons

Not OSI-certified: Cannot be called “open source” — some developers and organizations reject non-OSI licenses on principle
Smaller community: May attract fewer contributors than MIT projects (no resale means reduced corporate contribution incentive)
No forking: The community cannot create an alternative like OpenTofu even if dissatisfied
Legal gray areas: The boundary between “internal use” and “service provision” can be ambiguous. Per n8n’s license FAQ, installing for clients and charging management fees is permitted, but reselling n8n itself as a service (SaaS-style) to third parties is prohibited

Implications for Solo Builders

License Choice Is a Business Model Choice

A license is not a legal appendage. The license determines the boundaries of your viable business models.

Business Model	MIT	Fair-code
Free CLI + paid content	Yes	Yes
OSS to managed SaaS	Yes (AWS risk)	Yes (defended)
Community to enterprise	Yes (active contributions)	Partial (limited contributions)
Fork defense	No	Yes

Why MMU Chose MIT (Revisited)

MMU chose MIT. Even though n8n’s Fair-code offers more protection, here’s why MIT was the right call:

Scale: MMU is a CLI checklist. The probability of AWS creating a “Managed Checklist Service” is effectively zero
Adoption first: The first challenge for a solo project is “getting people to use it.” MIT minimizes adoption friction
Revenue separation: MMU’s revenue comes from content (Playbook Pack), not the CLI code. You can fork the code, but you can’t fork the content
Community contributions: Maintaining 534 items alone is difficult. MIT maximizes contribution incentives

Fair-code is rational “when your code itself could become your competitor.” Since MMU generates revenue from content rather than code, a code fork isn’t a threat.

Summary

Key Point	Details
What is Fair-code	Source available + resale prohibited. Not OSI-certified, so not “open source”
Why n8n chose it	To solve the AWS defense problem from the start
License change dramas	Elastic, MongoDB, and HashiCorp all changed after the fact, causing community conflict
Validation	n8n’s $50M+ ARR (estimated) proves large-scale business is possible under Fair-code
Solo builder takeaway	Use Fair-code when code itself is a competitive threat; use MIT when content is the revenue source

This post concludes the OSS monetization analysis series (G4a-G4d). The next post covers the practical license selection guide — MIT vs Apache vs Fair-code vs additional clauses, with a decision framework by project scale.