The line in the LICENSE file that reorders your n8n alternatives

Most "n8n alternatives" lists compare the wrong column.

They line up connector counts, per-execution pricing, cron support, and a screenshot of the canvas. Useful, up to a point. But if you're planning to self-host the engine — the reason you're looking past the SaaS incumbents in the first place — there's a field none of those tables show, and it sits in a file at the root of every repo: LICENSE.

We run n8n in production. The entire AI Alleyway content pipeline is about ten self-hosted n8n workflows on a single box. So this isn't a "we surveyed the landscape" post — it's the one architectural question I wish more alternatives lists led with, because it's the one that quietly decides whether a tool is even eligible for your use case before you've compared a single feature.

Three licenses, three completely different contracts

"Open source" gets used as a single adjective. For self-hosted automation engines it's actually three different legal contracts, and they diverge exactly where it matters — redistribution.

n8n ships under the Sustainable Use License (v1.0). This is source-available, not an OSI-approved open-source license. n8n's own umbrella term for the model is "fair-code." You can read the source, self-host it, and modify it — but the grant is scoped. Straight from the repo's LICENSE.md, you may use or modify the software "only for your own internal business purposes or for non-commercial or personal use," and you may distribute it to others "only if you do so free of charge for non-commercial purposes." In plain terms: run it for yourself all you want; you cannot turn around and offer n8n as a hosted service to third parties, or bundle-and-resell it commercially, without a separate enterprise license.

Activepieces ships under MIT (its Community Edition). MIT is the permissive, OSI-approved baseline — embed it, fork it, resell it, close your fork, no copyleft strings. The honest nuance: MIT covers the Community Edition core; Activepieces keeps some enterprise features under a separate commercial license, so "MIT" describes the open core, not every paid add-on. But the core you'd self-host and build on is genuinely permissive.

Node-RED ships under the Apache License 2.0, stewarded by the OpenJS Foundation. Also OSI-approved and permissive, and Apache 2.0 goes one step past MIT by including an explicit patent grant — the contributors license the patents needed to use their contribution, and there's a patent-retaliation clause. If your legal team cares about patent exposure in a shipped product, that clause is a feature, not boilerplate.

Three tiers: source-available-with-a-redistribution-fence, permissive, permissive-with-a-patent-grant. Same "open" label on the tin.

Why the license is an architectural constraint, not a footnote

Here's the reframe: the license isn't a compliance checkbox you clear at the end. It's a boundary on your architecture, because it constrains where the automation engine is allowed to live in your system.

Ask one question — is the automation layer something you run, or something you ship?

If you run it — internal ETL, ops glue, a content pipeline like ours, back-office orchestration that never leaves your own walls — then n8n's fair-code fence never touches you. "Internal business purposes" is exactly what you're doing. That's precisely our situation: we chose n8n knowingly, and the Sustainable Use License was a non-issue because we don't resell the engine or expose it as a product to anyone. In that world you should optimize for depth, and n8n's depth is real — on the order of 1,100 integrations, strong branching and error handling, and a node ecosystem that means most of what you need already exists.

If you ship it — the automation engine is embedded in a product your customers touch, or you're offering "workflows" as a feature of your SaaS, or you're a platform letting your users build automations — you've crossed the exact line the fair-code license draws. Now n8n's restriction is load-bearing. Offering it as a service to third parties is the thing the license reserves. At that point the feature-richest tool is no longer the honest answer; the eligible tools are the permissively licensed ones. Activepieces (MIT) and Node-RED (Apache 2.0) let you embed, white-label, fork, and resell without asking anyone. That's not a marketing claim — it's what those license texts grant.

This is why a license-blind alternatives list can actively mislead. It'll rank n8n at the top for a reader who's building a product on top of an automation engine — a reader for whom n8n's own license says "not like this." The ranking is correct for the internal-use reader and wrong for the productizing reader, and the table gives you no way to tell which one you are.

Where the hosted tools fit (and why they dodge the question)

For completeness: we've also driven Make (built a real scenario against its API) and Zapier (ran its MCP across Gmail, Calendar, and Slack). Both are fine tools. But they're hosted SaaS — there's no repo to self-host and no LICENSE file to read, so the whole license-tier question is moot. You're renting capacity and accepting the terms of service, full stop. That's a legitimate choice; it's just a different decision than the one this post is about. The license axis only exists once you've committed to self-hosting, which is where the "n8n alternatives" search usually lands you anyway.

The same "it's a service, not a license" framing applies to most of the other hosted names that show up in these roundups — Pipedream, Workato, Power Automate, Gumloop, Tray.ai. I'm assessing those from their docs and terms, not from production use, and none of them change the core point: if you're not self-hosting, you're evaluating a contract, not a license.

The decision, compressed

• Running automations internally? Fair-code is fine. Optimize for depth and ecosystem — n8n earns its spot.
• Shipping the automation layer inside a product, or need to fork/embed/resell freely? The permissive licenses are the honest destination, not the feature-count winner. Look hard at Activepieces (MIT) and Node-RED (Apache 2.0), and read their LICENSE files yourself before you commit.
• Not self-hosting at all? The license tier doesn't apply — you're picking a SaaS on terms-of-service and pricing, and Make/Zapier/Pipedream are competing on that axis instead.

The practical move: before you shortlist any self-hosted automation engine, open its LICENSE file first and answer the run-it-vs-ship-it question. That one field filters the list faster than any feature matrix, and it filters it correctly — because it filters on what you're actually allowed to do, not on what the tool can do.

When I sanity-checked our own stack against this lens, I ended up pulling together the full n8n alternatives breakdown, sorted by why you're leaving — nine tools grouped by the reason someone actually migrates (license, hosting model, pricing shape, integration gaps) rather than by a single leaderboard. If you're weighing a switch, reading it by your reason-for-leaving is a lot more useful than reading it top-to-bottom.

Read the LICENSE file first. It's the cheapest architecture decision you'll make all quarter.