Minbook
EN
Deep Dive MMU

오픈소스 라이선스 선택 가이드 — MIT vs Apache vs Fair-code vs 추가조건

· 4 min read

라이선스 선택은 첫 번째 사업 결정이다

오픈소스 프로젝트를 시작할 때 대부분 라이선스를 “나중에 정하자”거나 “MIT면 되겠지”로 넘깁니다. 하지만 라이선스는 사업 모델의 가능 범위를 결정합니다.

G4a~G4d에서 분석한 8개 회사의 라이선스 선택을 종합하면, 패턴이 보입니다:

회사라이선스수익 모델라이선스 변경 이력
LangChainMIT프레임워크 → LangSmith (SaaS)없음
LlamaIndexMIT프레임워크 → LlamaCloud (SaaS)없음
CrewAIMIT프레임워크 → Enterprise (SaaS)없음
LangfuseMIT + EEMIT 코어 + Enterprise 기능 유료없음
Dify조건부재판매 제한없음
Hugging FaceApache 2.0허브 → 컴퓨팅 판매없음
n8nFair-code셀프호스트 무료 → Cloud 유료없음 (처음부터 Fair-code)
ElasticSSPL → AGPL 추가셀프호스트 → Cloud 유료Apache → SSPL (AWS 대응)

라이선스별 허용/제한 비교표

graph LR
    subgraph PERMISSIVE["허용적 (Permissive)"]
        MIT["MIT"]
        APACHE["Apache 2.0"]
    end

    subgraph COPYLEFT["카피레프트 (Copyleft)"]
        GPL["GPL v3"]
        AGPL["AGPL v3"]
    end

    subgraph RESTRICTED["제한적 (Source Available)"]
        BSL["BSL 1.1"]
        SSPL["SSPL"]
        FAIR["Fair-code"]
    end

    MIT -->|"+ 특허 보호"| APACHE
    APACHE -->|"+ 수정 공개 의무"| GPL
    GPL -->|"+ 서비스 포함"| AGPL
    AGPL -->|"+ 경쟁 서비스 금지"| BSL
    BSL -->|"+ 서비스 스택 공개"| SSPL

    style PERMISSIVE fill:#e8f5e9,stroke:#4caf50
    style COPYLEFT fill:#e3f2fd,stroke:#2196f3
    style RESTRICTED fill:#fff3e0,stroke:#ff9800
항목MITApache 2.0GPL v3AGPL v3BSL 1.1SSPLFair-code
소스 코드 열람✅✅✅✅✅✅✅
수정✅✅✅ (공개)✅ (공개)✅✅✅
상업적 사내 사용✅✅✅✅✅✅✅
재배포✅✅✅ (공개)✅ (공개)제한제한❌
SaaS로 제공✅✅✅✅ (공개)❌❌❌
포크 경쟁✅✅✅✅❌❌❌
특허 보호❌✅✅✅✅✅가변
OSI 인증✅✅✅✅❌❌❌

각 라이선스의 한 줄 요약

  • MIT: “가져가서 아무거나 해도 돼. 저작자 표시만 해줘”
  • Apache 2.0: “MIT + 특허 분쟁 시 라이선스 자동 종료”
  • GPL v3: “수정하면 수정한 코드도 GPL로 공개해야 해”
  • AGPL v3: “GPL + 서비스로 제공해도 소스를 공개해야 해”
  • BSL 1.1: “경쟁 서비스 금지. 4년 후 자동으로 오픈소스 전환”
  • SSPL: “서비스로 제공하려면 서비스 스택 전체를 공개해야 해”
  • Fair-code: “사내 사용은 무료, 재판매는 금지”

규모별 라이선스 판단 프레임워크

의사결정 플로우

graph TD
    START["오픈소스 프로젝트 시작"] --> Q1{"코드 자체가\n경쟁 위협이\n될 수 있나?"}

    Q1 -->|"YES\n(인프라, 플랫폼)"| Q2{"AWS/클라우드가\n관리형 서비스를\n만들 가능성?"}
    Q1 -->|"NO\n(CLI, 라이브러리, 도구)"| Q3{"수익원이\n코드인가,\n콘텐츠/서비스인가?"}

    Q2 -->|"높음"| R1["Fair-code / BSL\n(처음부터 방어)"]
    Q2 -->|"낮음"| Q4{"커뮤니티 기여가\n필수적인가?"}

    Q3 -->|"코드"| Q4
    Q3 -->|"콘텐츠/서비스"| R2["MIT\n(최대 채택)"]

    Q4 -->|"YES"| R3["MIT / Apache 2.0\n(기여 마찰 최소화)"]
    Q4 -->|"NO"| R4["AGPL / MIT+EE\n(방어 + 기여 균형)"]

    style R1 fill:#fff3e0,stroke:#ff9800
    style R2 fill:#e8f5e9,stroke:#4caf50
    style R3 fill:#e8f5e9,stroke:#4caf50
    style R4 fill:#e3f2fd,stroke:#2196f3

규모별 권장

프로젝트 규모특성권장 라이선스이유
1인 사이드 프로젝트사용자 0~100, 수익 없음MIT채택 극대화, 방어 불필요
1인 + 수익화 시도사용자 100~1K, 초기 수익MIT (코드 외 수익) 또는 AGPL (코드 수익)수익원에 따라 분기
스타트업 (Seed~A)사용자 1K~10K, VC 투자Apache 2.0 + EE 또는 BSL특허 보호 + 경쟁 방어
성장기 (Series B+)사용자 10K+, ARR $1M+Fair-code 또는 BSLAWS 방어 필수

MIT vs Apache 2.0: 언제 Apache가 나은가

두 라이선스의 실질적 차이는 특허 조항입니다:

  • MIT: 특허에 대한 언급 없음
  • Apache 2.0: 기여자가 자동으로 특허 라이선스를 부여함. 기여자가 특허 소송을 걸면 라이선스가 자동 종료

특허가 중요한 영역(AI 알고리즘, 데이터베이스 엔진 등)에서는 Apache 2.0이 안전합니다. CLI 도구나 유틸리티에서는 MIT로 충분합니다.

MMU의 라이선스 의사결정 과정

판단 기준 적용

질문MMU의 답
코드 자체가 경쟁 위협?❌ — CLI 체크리스트를 AWS가 관리형 서비스로 만들 가능성 0
수익원이 코드?❌ — 수익원은 Playbook Pack(콘텐츠)과 AI Coach(서비스)
커뮤니티 기여 필수?✅ — 534개 항목을 1인이 전부 유지하기 어려움
특허 이슈?❌ — 특허 대상이 될 기술 없음

→ 결론: MIT

리스크 평가

리스크확률영향대응
누군가 fork하여 경쟁 CLI 출시낮음낮음콘텐츠 차별화 (Playbook Pack)
기업이 내부 도구로 채택 후 기여 안 함중간낮음기여 없어도 MIT의 채택 이점이 더 큼
누군가 MMU를 SaaS화극히 낮음중간콘텐츠 + AI Coach가 방어벽

MMU의 경우 Fair-code는 과잉 방어입니다. 보호할 “경쟁 위협”이 없는 상태에서 재판매를 막으면, 채택만 줄이고 방어 효과는 없습니다.

라이선스 변경의 비용

“일단 MIT로 시작하고, 나중에 문제가 생기면 바꾸자”는 전략은 이론적으로는 가능하지만 실무적으로 매우 비싸다는 것이 G4d에서 본 사례들의 교훈입니다.

라이선스 변경 시 발생하는 비용

비용 유형내용
커뮤니티 신뢰HashiCorp → OpenTofu 포크. 개발자 커뮤니티의 반감
법적 복잡성기존 기여자의 동의 필요. CLA(Contributor License Agreement) 소급 적용 어려움
포크 리스크라이선스 변경 전 버전을 기반으로 경쟁 프로젝트 탄생
기업 고객 혼란법무팀이 새 라이선스를 재검토해야 함 → 도입 지연
브랜드 손상”오픈소스가 아니게 됐다” → 미디어/커뮤니티 비판

라이선스는 한 번 정하면 바꾸기 어렵습니다. “사후 변경”보다 “사전 설계”가 훨씬 저렴합니다.

실전 체크리스트

오픈소스 프로젝트를 시작할 때, 아래 5개 질문에 답하면 라이선스가 결정됩니다:

#질문YES →NO →
1코드 자체를 팔아서 돈을 벌 건가?AGPL 이상 검토MIT/Apache
2클라우드 회사가 내 코드로 서비스를 만들 수 있나?Fair-code/BSLMIT/Apache
3기여자의 코드가 비공개 제품에 들어가는 걸 막고 싶나?GPL/AGPLMIT/Apache
4특허가 관련된 기술인가?Apache 2.0MIT 가능
54년 후 완전 오픈소스 전환을 약속하고 싶나?BSLFair-code

전부 NO라면 MIT. 이것이 대부분의 1인 프로젝트에 해당합니다.

CLA (Contributor License Agreement)

라이선스를 나중에 변경할 가능성이 있다면, 처음부터 CLA(기여자 라이선스 동의서)를 받아두는 것이 중요합니다. CLA가 없으면 라이선스 변경 시 모든 기여자의 개별 동의를 받아야 하며, 이는 사실상 불가능에 가깝습니다. Elastic, MongoDB, HashiCorp 모두 라이선스 변경이 가능했던 이유 중 하나가 CLA를 사전에 확보했기 때문입니다.

1인 프로젝트라도 외부 기여를 받기 시작하면 CLA를 도입하세요. GitHub의 CLA Assistant 등으로 자동화할 수 있으며, 초기 설정 비용은 낮지만 나중에 라이선스 전략을 바꿀 수 있는 유연성을 확보해줍니다.

정리

핵심내용
라이선스 = 사업 모델의 프레임어떤 수익화가 가능하고 불가능한지를 결정
가장 중요한 질문”코드 자체가 경쟁 위협인가?” → YES면 방어적, NO면 허용적
1인 프로젝트 기본값MIT (채택 극대화, 과잉 방어 불필요)
사후 변경 비용커뮤니티 신뢰, 법적 복잡성, 포크 리스크 → 비쌈
MMU의 선택MIT — 수익원이 코드가 아닌 콘텐츠이므로 방어 불필요

다음 글에서는 이 시리즈의 결론 — 1인 빌더의 오픈소스 사업화, 엔터프라이즈 없이 가능한가 — 를 다룹니다. G4a~G5의 분석을 종합하여 1인이 실행 가능한 5단계 프레임워크를 제시합니다.

#오픈소스 #라이선스 #MIT #Apache #AGPL #BSL #Fair-code #의사결정
Share

Related Posts

Comments