셀프호스팅 AI 도구를 고객에게 팔 때 — n8n의 내부 업무 목적과 Open WebUI의 50명이 갈리는 자리

서버에 n8n을 올려 두고 몇 주 잘 돌아가면 다음 생각이 자연스럽게 따라와요. 이걸 고객사마다 하나씩 깔아 주고 월 정액을 받으면 어떨까 하는 생각이에요.

결론부터 적을게요. 오픈소스니까 깔아서 팔아도 된다는 통설은 다섯 중 네 도구에서 틀리는데, 틀리는 이유가 도구마다 달라요. n8n은 용도로, Dify는 구성으로, Open WebUI는 브랜딩을 지우는 행위에 인원 임계를 붙여, Flowise는 코드가 놓인 위치로 선을 긋고, Langflow는 아예 긋지 않았어요. 통설이 그대로 통하는 곳은 MIT 한 장뿐인 Langflow 하나예요. 그래서 "이 도구는 상업적 이용이 되나요"라는 질문 자체가 도구마다 다른 질문이 돼요.

아래 내용은 2026년 8월 18일 오전에 다섯 저장소의 라이선스 파일을 raw 주소로 직접 받아 전문을 읽은 것이에요. n8n 공식 문서 한 페이지도 같은 날 원문 마크다운으로 받았고요. 이 글은 법률 자문이 아니고, 각자의 계약을 대신 해석하지도 않아요. 라이선스 파일은 예고 없이 바뀌니까 실제 판단이 필요한 자리라면 그날 원문을 다시 받아 보는 편이 안전해요.

오픈소스라고 부르지 않는 도구가 있어요 — n8n이 직접 밝힌 이유

첫 단추부터 어긋나기 쉬운 자리예요. n8n 공식 문서는 스스로를 오픈소스라고 부르지 않아요. 문서에 이렇게 적혀 있어요.

according to the Open Source Initiative (OSI), open source licenses can't include limitations on use, so we do not call ourselves open source

오픈소스 이니셔티브 기준으로 오픈소스 라이선스는 사용에 제한을 둘 수 없기 때문에 자신들을 오픈소스라고 부르지 않는다는 뜻이에요. 소스가 공개돼 있다는 사실과 오픈소스 라이선스라는 사실이 같은 말이 아니라는 걸 벤더 쪽에서 먼저 밝혀 둔 셈이에요.

그 자리를 채우는 라이선스 이름은 Sustainable Use License, 버전은 Version 1.0이에요. n8n 저장소 루트의 LICENSE.md 안에 ## Sustainable Use License 제목과 그 아래 Version 1.0 이 그대로 적혀 있어요.

문서는 fair-code 라는 말도 같이 써요. 여기서 자주 헷갈리는데, fair-code는 라이선스 이름이 아니에요. 문서가 직접 이렇게 적어요.

Fair-code isn't a software license. It describes a software model where software:

그리고 그 모델을 네 줄로 설명해요. 대체로 무료로 쓸 수 있고 누구나 배포할 수 있다는 것, 소스 코드가 공개돼 있다는 것, 공개·비공개 커뮤니티에서 누구나 확장할 수 있다는 것, 그리고 저자에 의해 상업적으로 제한된다는 것이에요. 앞의 세 줄만 읽으면 오픈소스처럼 들리고, 네 번째 줄에서 갈려요.

전환 시점도 문서에 있어요.

n8n was licensed under Apache 2.0 with Commons Clause until 17 March 2022.

2022년 3월 17일까지는 Apache 2.0에 Commons Clause를 얹은 형태였다는 뜻이에요. 그때 만들어 둔 문서나 블로그 글을 근거로 지금 판단하면 어긋나는 이유가 여기 있어요. 문서는 바뀐 이유도 적어 두었는데, 예전 Commons Clause가 "판매"를 제한하던 것을 "내부 업무 목적"으로 다시 정의했고, 컨설팅과 지원 서비스에 대한 제한은 아예 걷어냈다고 밝혀요.

n8n이 그은 선 — '자기 회사의 내부 업무 목적'이라는 한 문장

LICENSE.md에서 실제로 선을 긋는 곳은 Limitations 절이에요. 절 전체는 네 문장인데, 사용 범위를 가르는 것은 앞의 두 문장이에요.

You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.

앞 문장은 사용과 수정을 자기 자신의 내부 업무 목적, 또는 비상업적·개인적 용도로 한정해요. 뒷 문장은 배포를 다루는데 조건이 두 개 붙어요. 무료여야 하고, 비상업적 목적이어야 해요. 두 조건 중 하나만 만족하는 배포는 이 문장이 열어 주지 않아요.

같은 절의 남은 두 문장도 짚어 둘게요. 세 번째는 라이선싱·저작권·기타 고지를 바꾸거나 지우거나 가리지 말라는 문장이에요. 뒤에서 볼 Open WebUI의 브랜딩 조항과 성격이 비슷한데, n8n 쪽은 인원 임계 같은 예외 없이 그냥 금지로 적혀 있어요.

네 번째는 짧아서 지나치기 쉬운데, 이 글의 주제와 바로 닿아요.

Any use of the licensor's trademarks is subject to applicable law.

라이선서의 상표를 쓰는 일은 준거법을 따른다는 문장이에요. 소스 코드에 대한 라이선스가 상표까지 함께 허락해 주는 게 아니라는 뜻이라, 이름을 붙여 팔거나 지우는 쪽을 검토한다면 저작권과 별개로 이 축을 한 번 더 봐야 해요.

"내부 업무 목적"이 실제로 어디까지인지는 공식 문서가 한 문장으로 풀어 줘요.

all use is allowed unless you are selling a product, service, or module in which the value derives entirely or substantially from n8n functionality

가치가 전적으로 또는 실질적으로 n8n 기능에서 나오는 제품·서비스·모듈을 파는 게 아니라면 전부 허용된다는 서술이에요. 판단 기준이 "돈을 받느냐"가 아니라 "받는 돈의 값어치가 어디서 나오느냐"에 걸려 있는 게 눈에 띄어요.

문서는 예시로 양쪽을 갈라 두었어요.

출처: n8n 공식 문서 Sustainable use license 페이지의 What is and isn't allowed 절. 2026년 8월 18일 원문 마크다운 수신본

이 여섯 줄을 나란히 놓으면 성격이 보여요. 금지 쪽 두 줄은 n8n 자체를 상품으로 내놓는 형태예요. 허용 쪽 네 줄은 n8n을 도구로 쓰거나, n8n 주변에서 사람이 하는 일을 파는 형태고요. 세 번째 허용 예가 특히 중요한데, 워크플로를 대신 만들어 주고 돈을 받는 컨설팅은 문서가 명시적으로 허용 목록에 넣어 두었어요. 앞서 본 대로 예전 라이선스에서는 제한되던 부분이었고, 지금은 걷혔다고 문서가 따로 밝혀요.

같은 앱에 붙여 쓰는 건 되고, 고객 계정을 받는 순간 갈려요

여기가 실무에서 가장 자주 부딪히는 자리예요. "우리 서비스의 기능 하나를 n8n으로 돌려도 되나요"라는 질문에 문서가 직접 답을 달아 두었어요.

Usually yes, as long as the back-end process doesn't use users' own credentials to access their data.

대체로 된다고 하면서, 백엔드 과정이 사용자 본인의 자격증명을 써서 그 사용자의 데이터에 접근하지 않는 한이라는 조건을 붙여요. 문서는 이 조건을 예시 두 개로 갈라 보여 줘요.

출처: n8n 공식 문서 Can I use n8n to act as the back-end to power a feature in my app 절. 2026년 8월 18일 수신본

두 예시의 차이를 문서가 스스로 한 줄씩 요약해 두었어요. 첫 번째는 사용자 본인의 HubSpot 자격증명을 수집해 정보를 끌어온다는 점이 사유예요. 두 번째는 사용자 자격증명이 전혀 수집되지 않는다는 점이 사유고요.

갈림의 기준이 유료냐 무료냐가 아니라는 점을 짚어 둘게요. 두 예시 어디에도 요금 이야기가 없어요. 갈린 것은 오직 자격증명이 누구 것이냐예요. 그래서 "무료 베타라서 괜찮다" 같은 생각은 이 절의 기준과 아예 다른 축에 있어요.

회사 정책 쪽 질문에도 같은 기준이 다시 나와요. 문서는 사내 정책상 상업적 이용을 제한하는 코드를 못 쓰게 되어 있는 경우를 두고 이렇게 답해요. 내부 업무 목적으로 쓰고 있고, 고객이 자기 계정을 연결해 워크플로를 만들도록 n8n을 열어 주는 게 아니라면 쓸 수 있을 것이라고요.

정리하면 n8n 쪽 판단선은 두 개예요. 첫째, 내가 파는 값어치가 n8n 기능에서 나오는가. 둘째, 고객이 자기 계정 자격증명을 이 시스템에 넣는가. 둘 중 하나라도 그렇다면 문서는 별도 상업 계약 쪽으로 안내해요.

n8n 안에도 다른 라이선스가 있어요 — 파일 1,118개는 애초에 대상이 아니에요

Sustainable Use License 본문만 읽고 끝내면 놓치는 게 있어요. LICENSE.md는 본문에 들어가기 전에 먼저 덜어내는 목록을 적어 두었거든요. 목록 자체는 네 줄인데, 앞 세 줄이 덜어내고 네 번째 줄이 나머지를 되받는 구조예요. 덜어내는 세 줄부터 볼게요.

Content of branches other than the main branch (i.e. "master") are not licensed.

Source code files that contain ".ee." in their filename or ".ee" in their dirname are NOT licensed under the Sustainable Use License.

All third party components incorporated into the n8n Software are licensed under the original license provided by the owner of the applicable component.

네 번째 줄은 덜어내는 게 아니라 되받는 줄이에요. 위 세 줄에 걸리지 않는 나머지가 Sustainable Use License 아래 있다고 적어요.

Content outside of the above mentioned files or restrictions is available under the "Sustainable Use License" as defined below.

첫 줄의 표현을 그대로 옮겨 둘게요. master가 아닌 브랜치는 "금지"가 아니라 "라이선스가 부여되지 않았다" 로 적혀 있어요. 문서의 어투가 그렇다는 뜻이고, 그 차이를 임의로 좁혀 옮기지 않는 편이 안전해요.

두 번째 줄이 이 절의 핵심이에요. 파일명에 .ee. 가 들어가거나 디렉터리명에 .ee 가 들어가는 소스 파일은 Sustainable Use License 대상이 아니고, 별도의 n8n Enterprise License가 있어야 쓸 수 있다고 이어서 적어요. 원문이 디렉터리 쪽에 쓴 말은 in their dirname, 즉 "끝난다"가 아니라 "들어간다"예요. 아래에서 셀 때는 이름이 .ee 로 끝나는 디렉터리를 셌는데, 2026년 8월 18일 조회 시점의 저장소에서는 이름에 .ee 가 들어가는 디렉터리와 .ee 로 끝나는 디렉터리가 둘 다 20개로 같아서 수치가 갈리지 않았어요.

그래서 실제로 몇 개인지 세어 봤어요. 2026년 8월 18일에 GitHub Git Trees API를 recursive=1 로 호출했고, 응답의 truncated 값이 false인 것을 확인한 뒤 셌어요.

출처: GitHub Git Trees API 직접 호출(n8n-io/n8n, master, recursive=1). 2026년 8월 18일 오전 조회 시점의 저장소 스냅샷이에요

검산은 간단해요. 196 더하기 1,014 빼기 92가 1,118이고, 1,014에서 교집합 92를 빼면 922예요.

세는 단위 하나를 밝혀 둘게요. 이 표는 저장소의 파일을 전수로 센 값이에요. 반면 조항의 문언은 Source code files 로 그보다 좁아요. 1,118개 중에서 확장자만 봐도 소스 코드가 아닌 것이 58개 섞여 있어요. .json 31개, .md 11개, .svg 4개, .yaml 3개, .webp 3개, 그리고 .toml·.lock·.gitignore·.csv·.madgerc·justfile 이 각각 1개예요. 조항이 실제로 덮는 범위는 이 58개를 뺀 쪽에 더 가깝고, 표의 수는 "그 규칙이 닿는 경로에 놓인 파일이 이만큼"이라는 뜻으로 읽는 게 정확해요.

922라는 숫자가 이 절을 쓰게 만든 이유예요. 공식 문서 FAQ의 해당 절은 예외를 두 줄로만 적어요. master가 아닌 브랜치, 그리고 파일명에 .ee. 가 들어가는 파일이에요. 디렉터리명 규칙이 그 목록에 없어요. 서드파티 컴포넌트 항목도 없고요. 문서만 읽고 파일명으로만 걸러 내면 922개가 그물 밖으로 빠져나가요.

어느 쪽이 권위인지는 커밋이 알려 줘요. LICENSE.md의 최종 커밋은 2024년 12월 24일자이고 제목이 refactor(core): Mark all backend Enterprise Edition files and dirs (#12350) 예요. 파일과 디렉터리를 함께 표시한 작업이라고 커밋 제목이 스스로 적고 있어요. 그러니 두 문서가 어긋나는 이 자리에서는 LICENSE.md 쪽을 따르는 게 맞아요.

그 파일들에 적용되는 문서는 따로 있어요. LICENSE_EE.md예요.

This software and associated documentation files (the "Software") may only be used in production, if you (and any entity that you represent) hold a valid n8n Enterprise license corresponding to your usage.

프로덕션에서 쓰려면 사용량에 맞는 유효한 n8n Enterprise 라이선스를 보유해야 한다고 적혀 있어요. 이 파일의 최종 커밋은 한국 시각으로 2022년 8월 30일자예요(UTC로는 8월 29일이라 시간대를 밝히지 않으면 하루가 어긋나요). 참고로 같은 파일에 개발과 테스트 목적의 복사·수정은 구독 없이 가능하다는 문장도 함께 있어요.

.ee 디렉터리 20개가 어떤 것들인지 몇 개만 적어 두면 감이 잡혀요. packages/@n8n/ai-workflow-builder.ee, packages/cli/src/sso.ee, packages/cli/src/permissions.ee, packages/cli/src/modules/external-secrets.ee, packages/cli/src/modules/ldap.ee 같은 것들이에요. 싱글 사인온, 권한, 외부 시크릿처럼 여러 사람에게 서비스로 열어 줄 때 필요해지는 기능이 이쪽에 몰려 있어요.

Dify는 용도가 아니라 구성으로 선을 그어요 — 멀티테넌트와 프론트엔드 로고

Dify는 출발점부터 n8n과 반대예요. LICENSE 첫 조항이 이렇게 시작해요.

Dify may be utilized commercially, including as a backend service for other applications or as an application development platform for enterprises.

다른 애플리케이션의 백엔드 서비스로든, 기업용 애플리케이션 개발 플랫폼으로든 상업적으로 이용될 수 있다고 먼저 적어요. 그리고 바로 이어서 아래 조건에 해당하면 제작자로부터 상업 라이선스를 받아야 한다고 붙여요. 즉 상업적 이용 자체를 막는 구조가 아니라, 특정 구성에 도달하면 별도 라이선스가 필요해지는 구조예요.

조건 a가 첫 번째 선이에요.

Unless explicitly authorized by Dify in writing, you may not use the Dify source code to operate a multi-tenant environment.

멀티테넌트라는 말이 모호해질 수 있는데, 문서가 정의를 붙여 두었어요. Dify의 맥락에서 테넌트 하나는 워크스페이스 하나에 대응하고, 워크스페이스는 각 테넌트의 데이터와 설정을 위해 분리된 영역을 제공한다고 적혀 있어요. 그래서 이 조건은 추상적인 개념 판단이 아니라 내 설치본에서 워크스페이스를 고객마다 나누고 있느냐라는 꽤 구체적인 질문으로 좁혀져요.

조건 b가 두 번째 선이에요.

In the process of using Dify's frontend, you may not remove or modify the LOGO or copyright information in the Dify console or applications. This restriction is inapplicable to uses of Dify that do not involve its frontend.

앞 문장만 읽고 멈추면 틀려요. 뒷 문장에 단서가 붙어 있어요. 프론트엔드를 쓰지 않는 사용에는 이 제한이 적용되지 않는다는 문장이에요. API나 백엔드로만 붙여 쓰는 구조라면 이 조건은 처음부터 걸리지 않는다는 뜻이에요.

프론트엔드가 무엇인지도 문서가 정의해요. 소스 코드에서 직접 실행할 때는 web/ 디렉터리에 있는 모든 컴포넌트, Docker로 실행할 때는 web 이미지예요. 코드 트리와 이미지 이름으로 못박아 둔 정의라 판단이 흔들릴 여지가 적어요.

말미의 두 문장도 같이 읽어 둘 만해요. 위에 적은 조건 말고 나머지 권리와 제한은 전부 Apache License 2.0을 따른다는 문장, 그리고 이 제품의 인터랙티브 디자인이 디자인권으로 보호된다는 문장이에요. 뒤쪽 문장은 라이선스가 아니라 별개의 권리를 가리키는 문장이라 성격이 다르니 따로 세어 두는 게 좋아요. 이 LICENSE 파일의 최종 커밋은 2025년 3월 28일이에요.

워크스페이스를 고객마다 나누는 구조를 검토하고 있다면, 그 워크스페이스에 들어갈 데이터가 어디로 흘러가는지도 같은 자리에서 같이 정리해 두는 편이 나아요. 해외 AI API로 고객 데이터를 보낼 때 국외 이전 예외가 어디까지 열리는지 정리한 글이 그 축을 다뤄요. 라이선스가 여는 구성과 데이터가 걸리는 절차는 서로 다른 문서에 적혀 있거든요.

Open WebUI의 50명 — 상업적 이용이 아니라 '브랜딩을 지우는 것'에 붙는 조건이에요

이 글에서 가장 틀리기 쉬운 자리예요. 그래서 원문 4항을 먼저 읽고 시작할게요.

licensees are strictly prohibited from altering, removing, obscuring, or replacing any "Open WebUI" branding, including but not limited to the name, logo, or any visual, textual, or symbolic identifiers that distinguish the software and its interfaces, in any deployment or distribution, except in the following circumstances:

금지 대상이 무엇인지 문장 앞머리에 나와요. Open WebUI 브랜딩을 바꾸거나, 지우거나, 가리거나, 대체하는 것이에요. 브랜딩의 범위도 적혀 있어요. 이름과 로고는 물론이고 소프트웨어와 그 인터페이스를 구별해 주는 시각적·텍스트적·상징적 식별자까지 포함한다고요.

그리고 예외가 셋이에요.

출처: Open WebUI 저장소 루트 LICENSE 제4항. 2026년 8월 18일 raw 수신본, 파일 최종 커밋 한국 시각 2026년 4월 15일(UTC 4월 14일)

숫자의 정의도 느슨하지 않아요. 최종 사용자를 애플리케이션에 직접 접근하는 개별 자연인으로 정의하고, 기간을 어느 30일 롤링 구간에서든으로 적어요. 월 단위로 끊어 세는 게 아니라 굴러가는 구간 기준이라는 뜻이에요.

4항의 마지막 문장은 문서 자신의 표현으로 이렇게 끝나요. 위 세 경우가 아닌 모든 경우에 Open WebUI 브랜딩을 제거하거나 변경하는 것은 라이선스의 중대한 위반(material breach of license)을 구성한다고요. 이 글은 라이선스 문서가 적은 이 표현까지만 옮기고, 그 밖의 결과는 다루지 않을게요.

앞의 1항부터 3항은 성격이 완전히 달라요. 소스 재배포 시 저작권 고지와 조건 목록과 면책 문구를 유지할 것, 바이너리 재배포 시 그것들을 문서나 배포 자료에 재현할 것, 그리고 사전에 구체적인 서면 허가를 받지 않고는 저작권자와 기여자의 이름을 파생 제품의 추천이나 홍보에 쓰지 말 것이에요. 3항은 절대 금지가 아니라 허가를 받으면 열리는 조건부 금지라서 단서까지 옮겨 적었어요. BSD 3-Clause와 같은 형태고요. 그래서 이 파일은 앞 세 항이 익숙한 BSD 조항이고 4항 하나가 얹힌 구조라고 읽으면 정확해요.

Open WebUI는 커밋 해시로 라이선스가 세 구간이에요

LICENSE 하나만 열고 "이 저장소 코드는 전부 Open WebUI License"라고 적으면 틀려요. 저장소 루트에 라이선스 계열 파일이 네 개 있거든요. LICENSE, LICENSE_HISTORY, LICENSE_NOTICE, 그리고 CONTRIBUTOR_LICENSE_AGREEMENT예요. 2026년 8월 18일에 GitHub Contents API로 루트를 열거해 확인한 목록이에요.

이 중 LICENSE_NOTICE가 구간을 갈라요. 721바이트짜리 짧은 파일인데 내용이 셋이에요.

출처: Open WebUI 저장소 루트 LICENSE_NOTICE. 2026년 8월 18일 raw 수신본

날짜가 아니라 커밋 해시로 경계를 그었다는 점이 특징이에요. 그래서 "언제부터"를 알려면 그 두 해시가 언제 들어갔는지를 저장소에서 따로 봐야 해요.

두 옛 라이선스의 원문은 LICENSE_HISTORY에 실려 있어요. BSD 3-Clause 쪽 저작권 표기는 Copyright (c) 2023-2025 Timothy Jaeryang Baek, MIT 쪽은 Copyright (c) 2023 Timothy Jaeryang Baek 이에요. 현행 LICENSE도 이 관계를 한 줄로 되짚어요. 이전 라이선스가 적용되는 자료는 LICENSE_HISTORY에 명시된 대로 원래의 라이선스 조건을 유지한다는 문장이에요.

한 가지 더 적어 둘게요. 두 파일의 표현 방식이 서로 달라요. LICENSE_NOTICE는 구간을 "이전 / 부터 포함해서 까지 / 이후"로 갈라 적는데, LICENSE_HISTORY는 두 덩이 모두 "해당 커밋 이전에 만들어진 코드와 자료"라는 표현으로 적어요. 구간을 정확히 갈라 놓은 쪽은 LICENSE_NOTICE라서 위 표는 그쪽 서술을 따랐어요.

셀프호스팅으로 쓰는 입장에서는 이 세 구간이 대개 실무 판단을 바꾸지 않아요. 하지만 코드 일부를 떼어다 자기 제품에 넣는 경우라면 이야기가 달라져요. 그 파일이 어느 구간에서 온 것인지에 따라 붙는 조건이 다르고, 그건 LICENSE 한 장을 읽어서는 알 수 없어요.

Flowise와 Langflow — 디렉터리로 가르는 쪽과 아예 안 가르는 쪽

Flowise는 네 번째 방식이에요. 루트 LICENSE.md가 위치로 갈라요.

All content that resides under ... /packages/server/src/enterprise directory and files with explicit copyright notice such as IdentityManager.ts are licensed under Commercial License.

Content outside of the above mentioned directories or restrictions above is available under the "Apache 2.0" license as defined below.

packages/server/src/enterprise 디렉터리 아래 내용과, IdentityManager.ts처럼 명시적 저작권 표기가 있는 파일은 Commercial License이고, 그 밖의 내용은 Apache 2.0이라는 구조예요. 실제로 이 파일 10,541바이트 중 대부분은 Apache License 2.0 전문이고, 위 세 줄짜리 목록이 그 앞에 얹혀 있는 형태예요.

파일 수도 세어 봤어요. 2026년 8월 18일 기준 Flowise main 브랜치의 전체 blob은 2,450개이고, 그중 packages/server/src/enterprise/ 아래 파일이 130개예요. 문서가 따로 지목한 IdentityManager.ts의 실제 경로는 packages/server/src/IdentityManager.ts 로, enterprise 디렉터리 밖에 있어요. 루트 LICENSE.md가 디렉터리 규칙과 별개로 "명시적 저작권 표기가 있는 파일"을 따로 적어 둔 이유가 여기 있어요. 디렉터리만 보고 판단하면 이 파일을 놓쳐요.

그 130개에 적용되는 문서는 packages/server/src/enterprise/LICENSE.md 예요. 프로덕션 사용 요건이 이렇게 적혀 있어요.

may only be used in production, if you ... have agreed to, and are in compliance with, the FlowiseAI Inc Subscription Terms

그리고 유효한 Enterprise Edition 구독을 정확한 호스트 수만큼(for the correct number of hosts) 보유해야 한다고 이어져요. 사용자 수가 아니라 호스트 수를 세는 단위라는 점이 앞의 Open WebUI와 대조돼요.

같은 파일에 완화 문장도 있어요.

Notwithstanding the foregoing, you may copy and modify the Software for development and testing purposes, without requiring a subscription.

개발과 테스트 목적의 복사·수정은 구독 없이 가능하다는 문장이에요. 그래서 "일단 깔아 보고 검토하는 단계"와 "프로덕션에서 돌리는 단계"가 이 문서 안에서 명시적으로 갈려 있어요. 두 파일 모두 최종 커밋이 2025년 5월 27일로 같아요.

Langflow는 다섯 번째 방식인데, 방식이라기보다 선을 긋지 않은 쪽이에요. 저장소 루트에 라이선스 계열 파일이 LICENSE 하나뿐이고, 내용은 MIT 전문 1,065바이트예요. 저작권 표기는 Copyright (c) 2024 Langflow 이고, 본문에는 사용·복제·수정·병합·게시·배포·서브라이선스, 그리고 사본의 판매까지 제한 없이 허용한다는 MIT 표준 문장이 그대로 들어 있어요. 최종 커밋은 2024년 4월 18일이고 그 뒤로 바뀌지 않았어요.

다섯 도구를 한 표로 — 선의 종류가 서로 달라요

지금까지 본 것을 한 자리에 놓으면, 다섯 도구가 서로 다른 종류의 선을 그었다는 게 보여요.

출처: 다섯 저장소의 라이선스 파일 원문과 n8n 공식 문서. 파일 수는 GitHub Git Trees API 직접 호출값이며, 모든 값의 확인 시각은 2026년 8월 18일 오전이에요

표를 세로로 읽으면 질문이 네 개로 좁혀져요. 자기 경우를 판정할 때 이 순서로 물어보면 돼요.

1. 내가 파는 값어치가 전적으로 또는 실질적으로 n8n 기능에서 나오나요? n8n을 호스팅해 놓고 접근에 돈을 받거나, 화이트라벨링해서 고객에게 파는 형태가 여기예요. 공식 문서가 허용되지 않는 예로 직접 적어 둔 두 줄이고, 아래 세 질문과는 별개로 따로 걸려요.
2. 고객이 자기 계정 자격증명을 이 시스템에 넣나요? 그렇다면 n8n 쪽에서 또 걸려요. 공식 문서가 예시로 NOT ALLOWED 판정을 붙여 둔 구조예요.
3. 워크스페이스를 고객마다 나누나요? 그렇다면 Dify 조건 a에 닿아요. 테넌트 정의가 워크스페이스라서 판단이 꽤 기계적으로 갈려요.
4. 이름과 로고를 지울 생각인가요? 그렇다면 Open WebUI 4항을 읽어야 해요. 반대로 브랜딩을 그대로 둘 생각이라면 이 조항은 처음부터 해당되지 않아요.

첫 질문을 목록에서 빼면 안 되는 이유를 한 번 더 적어 둘게요. 고객 자격증명을 받지 않고, 워크스페이스도 나누지 않고, 이름과 로고도 그대로 둔 채로 n8n을 깔아 주고 접근료만 받는 형태가 얼마든지 가능해요. 그런데 그건 공식 문서가 허용되지 않는 예로 직접 적어 둔 바로 그 형태예요. 뒤의 세 질문은 전부 "아니오"인데도요.

네 질문 모두 "아니오"라면 다섯 도구 어디에서도 지금까지 본 조항에는 걸리지 않아요. 다만 그건 이 글이 읽은 문서 안에서 그렇다는 뜻이고, 각 회사의 서비스 약관이나 클라우드 이용 조건은 이번에 열지 않았어요.

선을 넘으면 문서에 뭐라고 적혀 있나 — n8n이 정한 30일

여기서는 라이선스 문서가 스스로 적어 둔 범위까지만 옮길게요. n8n LICENSE.md의 Termination 절이에요.

If you use the software in violation of these terms, such use is not licensed, and your license will automatically terminate.

조건을 어긴 사용은 라이선스가 부여된 것이 아니며, 라이선스가 자동으로 종료된다는 문장이에요. 그리고 바로 다음 문장이 회복 절차를 적어요.

If the licensor provides you with a notice of your violation, and you cease all violation of this license no later than 30 days after you receive that notice, your license will be reinstated retroactively. However, if you violate these terms after such reinstatement, any additional violation of these terms will cause your license to terminate automatically and permanently.

세 단계로 나뉘어 있어요.

출처: n8n 저장소 루트 LICENSE.md의 Termination 절. 2026년 8월 18일 raw 수신본

이 표를 읽는 방식에 주의할 점이 있어요. 회복의 기산점이 위반을 시작한 날이 아니라 통지를 받은 날이에요. 그리고 통지를 보내는 것이 라이선서의 의무로 적혀 있는 게 아니라, 통지가 있었을 때의 효과로 적혀 있어요. 문장 구조를 그대로 옮기면 그래요.

그럼 허용되지 않는 용도가 꼭 필요하면 어떻게 하라고 적혀 있을까요. 공식 문서가 답을 달아 두었어요. 별도의 상업 계약을 맺어야 한다고 하고, 소프트웨어 제작자들이 n8n으로 제품을 만드는 것을 적극 권장하며 다만 이용 조건과 그에 따른 비용을 정하는 합의서에 서명해 달라는 서술이에요. 문의처는 [email protected] 로 문서에 적혀 있어요. 엔터프라이즈용 독점 라이선스가 있다는 안내도 같은 페이지 맨 위 상자에 있고요.

Flowise 쪽 문의처는 enterprise/LICENSE.md에 [email protected] 으로, Dify는 서면 승인이라는 표현으로, Open WebUI는 저작권자의 사전 서면 허가나 엔터프라이즈 라이선스라는 표현으로 각각 적혀 있어요. 넷 다 "안 된다"에서 끝나는 게 아니라 문을 열어 두는 경로를 같이 적어 두었다는 점이 공통이에요.

이 글에서 확인하지 못한 것

솔직하게 남겨 둘게요.

첫째, 각 회사의 서비스 약관과 요금 조건이에요. 이 글이 읽은 것은 저장소의 라이선스 파일과 n8n 공식 문서 한 페이지뿐이에요. 클라우드 버전 약관이나 유료 플랜의 티어 조건은 열지 않았어요.

둘째, Dify와 Open WebUI, Langflow의 파일 수예요. Trees API로 실제로 센 것은 n8n과 Flowise 두 곳이에요. 나머지 세 곳은 문서 문언만 읽었어요.

셋째, 특정 사업 구조가 어느 조항에 걸리는지의 판정이에요. 이 글은 각 문서의 어느 문장이 선을 긋는지까지만 보여 주고, 개별 계약의 해석은 하지 않아요.

넷째, Open WebUI의 두 커밋 해시가 각각 언제 들어갔는지예요. LICENSE_NOTICE가 날짜가 아니라 해시로 경계를 적어 두었고, 그 해시의 커밋 일자는 이번에 조회하지 않았어요.

다섯째, 라이선스 변경 이력의 전체예요. 각 파일의 최종 커밋 시각만 확인했고 그 사이의 개정 과정은 따라가지 않았어요.

정리

• n8n 공식 문서는 스스로를 오픈소스라고 부르지 않아요. OSI 기준으로 오픈소스 라이선스는 사용에 제한을 둘 수 없기 때문이라고 문서가 직접 적어요. 라이선스 이름은 Sustainable Use License Version 1.0 이에요.
• fair-code는 라이선스가 아니라 모델이에요. 문서가 무료 사용·소스 공개·누구나 확장·저자에 의한 상업적 제한 네 가지로 설명해요.
• n8n의 선은 용도예요. Limitations 절이 사용과 수정을 자기 자신의 내부 업무 목적 또는 비상업적·개인적 용도로 한정하고, 배포는 무료이면서 비상업적일 때만 열어요.
• 실무 판단선은 두 개예요. 파는 값어치가 전적으로 또는 실질적으로 n8n 기능에서 나오는가, 그리고 고객이 자기 계정 자격증명을 넣는가예요. 문서의 예시 두 개가 두 번째 기준으로 갈려요.
• n8n 저장소 안에는 다른 라이선스 대상이 섞여 있어요. 2026년 8월 18일 조회 기준 파일명 규칙 196개, 디렉터리 규칙 아래 1,014개, 합집합 1,118개이고 그중 922개는 파일명만 봐서는 안 잡혀요.
• 공식 문서 FAQ는 예외로 파일명 규칙만 적고 디렉터리 규칙을 적지 않아요. LICENSE.md 최종 커밋 제목이 파일과 디렉터리를 함께 표시한 작업이라고 밝히고 있어서, 이 자리에서는 LICENSE.md가 권위예요.
• Dify의 선은 구성이에요. 상업적 이용 자체는 문서가 먼저 열어 두고, 서면 승인 없는 멀티테넌트 운영과 프론트엔드 로고 제거에서 상업 라이선스가 필요해져요. 테넌트 하나 = 워크스페이스 하나로 정의돼 있어요.
• Dify 로고 조항에는 프론트엔드를 쓰지 않는 사용에는 적용되지 않는다는 단서가 붙어 있어요. 프론트엔드는 web/ 디렉터리 또는 web 이미지로 정의돼요.
• Open WebUI의 50명은 판매 한계선이 아니에요. 4항이 금지하는 것은 브랜딩 제거·변경이고, 30일 롤링 50명은 그 금지의 예외 세 가지 중 하나예요. 이름과 로고를 그대로 두면 이 조항은 걸리지 않아요.
• Open WebUI 저장소의 라이선스 계열 파일은 네 개예요. LICENSE 한 장만 읽으면 LICENSE_NOTICE가 커밋 해시 두 개로 갈라 둔 MIT·BSD 3-Clause·Open WebUI License 세 구간을 놓쳐요.
• Flowise의 선은 코드 위치예요. packages/server/src/enterprise/ 아래 130개와 명시적 저작권 표기 파일이 Commercial License이고, 개발·테스트는 구독 없이 가능하다고 같은 파일이 적어요. 세는 단위는 사용자 수가 아니라 호스트 수예요.
• Langflow는 LICENSE 파일 하나뿐이고 MIT 전문 1,065바이트예요. 이 파일 안에서는 재판매·브랜딩 제거·멀티테넌트에 조건을 붙인 문장을 찾지 못했어요.
• 선을 넘었을 때 n8n 문서가 적은 범위는 자동 종료 → 통지 후 30일 내 시정 시 소급 회복 → 재위반 시 영구 종료예요. 허용 밖 용도는 별도 상업 계약으로 안내하고 문의처를 적어 두었어요.
• 모든 인용과 수치의 확인 시각은 2026년 8월 18일 오전이에요. 라이선스 파일은 예고 없이 바뀌니까 판단이 필요한 날에는 원문을 다시 받아 보세요.

가장 짧은 확인은 두 가지예요. 지금 쓰는 도구의 저장소 루트를 열어 라이선스 계열 파일이 몇 개인지 세어 보는 것, 그리고 그중 가장 짧은 파일부터 끝까지 읽는 것이에요. 다섯 곳 중 두 곳에서 형제 파일을 세지 않았다면 틀린 결론에 닿았을 거예요.

함께 보면 좋은 글

• n8n 자동화 워크플로우 초보 가이드 — 셀프호스팅으로 첫 워크플로를 올리는 과정을 다뤄요.
• 해외 AI API로 고객 데이터를 보낼 때 — 라이선스가 아니라 데이터 쪽에 걸리는 절차를 짚어요.
• AI 이미지 저작권·상업적 이용 가이드 — 도구가 아니라 산출물 쪽 라이선스를 다뤄요.

확인한 자료: n8n 저장소 루트 LICENSE.md(4,445바이트)와 LICENSE_EE.md(1,879바이트), n8n 공식 문서 Sustainable use license 페이지 원문 마크다운(13,749바이트), Dify LICENSE(1,801바이트), Open WebUI LICENSE(2,819바이트)·LICENSE_NOTICE(721바이트)·LICENSE_HISTORY(2,872바이트), Flowise LICENSE.md(10,541바이트)와 packages/server/src/enterprise/LICENSE.md(2,893바이트), Langflow LICENSE(1,065바이트). 전부 2026년 8월 18일 오전에 HTTP 200으로 직접 받아 전문을 읽었어요. 파일 수는 같은 날 GitHub Git Trees API를 recursive 옵션으로 호출해 응답의 truncated 값이 false인 것을 확인한 뒤 셌고, 저장소 루트의 라이선스 계열 파일 목록은 GitHub Contents API로 열거해 확인했어요.