Which "open source" AI agent tools are not actually open source
Of the 45 projects catalogued here, 41 carry an OSI-approved licence and four do not. What n8n, Dify, AutoGen and Phoenix restrict, why GitHub's licence field misleads in both directions, and what to check.
Four entries out of 45
Of the 45 projects in this catalogue, 41 carry an OSI-approved licence and four do not. The four are n8n (Sustainable Use License), Dify (Dify Open Source License), AutoGen (CC-BY-4.0) and Phoenix (Elastic-2.0).
Under a tenth by count, considerably more by attention: those four hold 424,833 GitHub stars between them — 13.1% of the 3,249,406 across all 45 entries. n8n, at 200,782, is the third most-starred project listed here; Dify, at 152,550, is seventh. They are two of the three visual workflow builders in the catalogue, and Langflow, at 153,278, sits between them — the only one of the three that is open source.
Among the 41 the distribution is dull, which is the good news: Apache-2.0 19, MIT 18, AGPL-3.0 2, BSD-2-Clause 1, and the MCP specification, whose code and specification text are Apache-2.0 while its documentation is CC-BY-4.0. Thirty-seven of the 45 entries are MIT or Apache-2.0 outright. If your dependency is one of those, you can stop here.
What the four actually restrict
| Project | Licence | The clause that matters | Still permitted |
|---|---|---|---|
| n8n | Sustainable Use License | Reselling it as a hosted service | Internal use, self-hosting |
| Dify | Dify Open Source License | Multi-tenant hosting, branding changes | Otherwise, what Apache 2.0 allows |
| AutoGen | CC-BY-4.0 | Nothing explicit — that is the problem | Use with attribution |
| Phoenix | Elastic-2.0 | Offering it to others as a managed service | Internal use, self-hosting, modification |
Three of these are readable in five minutes and say what they mean. The Sustainable Use License permits internal business use and self-hosting, and withholds the right to resell n8n as a hosted product; n8n publishes it under the “fair-code” banner rather than claiming OSI compliance. Dify’s licence is Apache 2.0 with additional conditions on multi-tenant hosting and on branding. Elastic License 2.0 forbids three things: providing the software to third parties as a managed service, circumventing licence-key functionality, and removing or obscuring licensing and copyright notices.
All three restrict the same thing: becoming a competing hosted service. If you run the software for your own organisation, none of them touches you, and the anxiety most teams bring to this question is misplaced.
AutoGen is a different case, and a worse one. CC-BY-4.0 is a Creative Commons licence written for content — articles, photographs, datasets. It permits commercial use with attribution, so it reads as generous. What it does not do is any of the work a software licence exists to do: no patent grant, no source-versus-object distinction, no permission structure for distributing a compiled derivative. Creative Commons itself advises against applying its licences to software. The honest statement is not “AutoGen is restricted” but “nobody can tell you what its terms mean for a product you ship” — a worse place to be than a restriction you can read.
The licence question is moot anyway: AutoGen is in maintenance mode, accepting only bug fixes, security patches and documentation, with the README routing new projects to Microsoft Agent Framework. If you are choosing today, that decides it before the licence does.
Why GitHub’s licence field is not an answer
The licence shown on a repository page comes from matching the LICENSE file against a set of known templates. It is right most of the time, and when it misleads it misleads in both directions. This catalogue holds a clean example of each.
AutoGen is the first direction: the field reports exactly what the repository declares, and the declaration is a content licence on a code repository. The API is not lying; it simply has no way to tell you the instrument is wrong for the job.
OpenClaw is the other direction. It is the most-starred entry in this catalogue at 386,406 stars, and GitHub reports its licence as NOASSERTION — the value returned when template matching fails. Open the file and it is the MIT licence, verbatim, with one line appended at the end pointing at THIRD_PARTY_NOTICES.md. That one sentence is enough to break the match. This catalogue records MIT because a person opened the file and read it.
Both mistakes are cheap to make and expensive to inherit: a directory assembled from the API would call AutoGen unremarkable and OpenClaw unknown, and be wrong twice.
AGPL is open source, and still a decision
Two entries are AGPL-3.0: Firecrawl at 167,800 stars and Skyvern at 22,757. AGPL-3.0 is OSI-approved. It belongs in the 41, not the four, and nothing here is a complaint about it.
What AGPL adds to the GPL is the network clause: if you modify the program and let users interact with it over a network, those users are entitled to your modified source. That is a copyleft obligation, not a usage restriction, and it is triggered by your modifications reaching users — not by the software being present in your stack.
The consequence is a design choice, and I would make it the same way every time: run these as their own service and call them over HTTP, unmodified. Both ship as self-hostable servers built to be used exactly that way. What creates real exposure is vendoring their source into your tree and patching it, which turns the boundary between their code and yours into an argument you do not want to have later.
If your organisation has a blanket AGPL prohibition — plenty of large ones do, and it rarely comes with an appeals process — treat it as settled rather than fighting it, because permissive alternatives exist for both jobs. Crawl4AI (Apache-2.0) does the crawl-to-markdown work Firecrawl does, at the cost of owning proxy handling and rate limiting yourself (the two compared). For browser automation, Browser Use and Stagehand are both MIT. One category over, Langfuse against Phoenix is MIT against Elastic-2.0 for much the same job.
What to check, in what order
1. Decide what you will do with it before reading any licence. Three questions settle nearly every case: does it run inside your product or beside it, do people outside your company reach it over a network, and will you modify it. If the answers are beside, no and no, every entry in this catalogue is fine — all four included.
2. Open the LICENSE file, not the sidebar. Ten seconds, and it is the whole of the previous section.
3. In a monorepo, check per package. A licence at the root does not guarantee that every published package underneath carries the same terms.
4. Search the text for “service” and “hosting”. The clauses that bite are about providing the software to third parties. If those words are absent, the licence probably does not restrict your plan.
5. Read the bespoke ones properly. The Sustainable Use License and Elastic License 2.0 run about a page each; Dify’s is Apache 2.0 with two extra conditions stated up front. Five minutes removes the guessing.
6. Record the answer with a date. Licences change, and more often toward restriction than away from it. Every entry here carries a last-reviewed date for that reason, and the methodology page explains how.
The restrictions are reasonable. One of the names is not.
Source-available licensing answers a recurring event: a company funds years of engineering, a larger company repackages the result as a managed service, and the funder keeps the maintenance burden without the revenue. The Sustainable Use License and Elastic License 2.0 are narrow, legible responses, and both permit far more than they forbid.
The texts are honest. n8n says “fair-code” rather than claiming OSI compliance. Arize ships Phoenix under a licence whose entire text fits on a page. Dify states its additional conditions at the top of its licence file, as numbered sections 1 and 2 — multi-tenant hosting, then branding — so anyone who opens the file learns within a paragraph what is being withheld.
The name on that file is the problem. It is headed simply “Open Source License”, and the name the project gives it — recorded here, as it must be, as “Dify Open Source License” — asserts the exact status the conditions underneath it rule out. Read the body and you are well informed; read the name, skip the body, and you are worse off than if you had never looked. AutoGen has the same defect from the other direction: CC-BY-4.0 is a real, familiar identifier, which is why it survives an eye-scan its actual terms would not.
That is why this catalogue records a licence type on every entry, not a licence name alone. A name can say anything; a type has to be one of two things, and the criteria are published: an OSI-approved licence or an explicitly documented source-available one, with anything whose licence cannot be established left out entirely. The looseness the rest of the ecosystem runs on — third-party lists, conference slides, “it’s open source, we can just self-host it” in a planning meeting — starts every time with someone reading a name instead of a file.
Projects in this post
n8nNode-based automation with a growing set of AI agent nodesDifyVisual builder for LLM apps, with RAG and agents included
AutoGenAgents that solve problems by conversing with one another
PhoenixTracing and evaluation that runs inside a notebook
FirecrawlTurns whole sites into clean markdown for model consumption
SkyvernBrowser workflow automation that survives layout changesopenclawA single-operator assistant that runs as a local Gateway and reaches you in the chat apps you use.
Crawl4AIAsync Python crawler that emits model-ready output
Browser UseGives an agent a real browser, driven by the DOM rather than pixels
StagehandPlaywright you can mix with natural-language instructions
LangflowDrag-and-drop flow builder that exports to running code
LangfuseTracing, prompt management and evaluation for LLM applicationsModel Context ProtocolThe MCP specification itself — the schema and rules every SDK implements