AI 및 오픈소스 소프트웨어 라이선스 완벽 해설: MIT vs Apache vs GPL vs AGPL vs 독점 라이선스

빠른 사실 정리

• MIT는 가장 짧고 흔한 permissive 라이선스입니다 — 약 170단어, 특허 조항 없음.
• Apache-2.0은 MIT에 없는 명시적 특허 허여 조항을 추가하며, 이는 많은 기업이 기업 주도 프로젝트에 Apache-2.0을 선호하는 이유입니다.
• GPL은 소프트웨어를 배포할 때만 소스코드 공개를 요구하고, AGPL-3.0은 이 요구를 네트워크 서비스 운영에까지 확장합니다.
• OSI 승인 "오픈소스"는 Open Source Initiative가 부여하는 구체적인 인증이며, "source-available"과 "fair-code"는 이 정의를 충족하지 못하는 라이선스를 가리키는 마케팅 용어입니다.
• AI 모델 라이선스는 코드 라이선스와 완전히 별개의 범주입니다. 도구의 코드는 Apache-2.0이더라도, 다운로드하는 모델 가중치는 전혀 다른, 종종 더 제한적인 조건을 가질 수 있습니다.

Permissive 라이선스란? MIT, Apache-2.0, BSD

• MIT 라이선스는 매사추세츠 공과대학교(MIT)에서 대학이 개발한 소프트웨어를 최소한의 제약으로 공개하는 방법으로 시작되었습니다. 약 170단어로 이루어져 있으며 거의 무제한의 권리를 부여하고, 재배포하는 사본이나 실질적인 부분에 원저작권 및 라이선스 문구를 유지할 것만을 요구합니다.
• Apache License 2.0은 Apache Software Foundation에서 나왔으며, 기업 및 커뮤니티 기여자들에게 대규모 협업 프로젝트를 위한 공통 법적 프레임워크를 제공하기 위해 설립되었습니다. MIT와 달리 명시적 특허 허여 조항을 포함하는데 — 기여자가 코드에 관한 특허권을 사용자에게 라이선스하는 것으로, 특허 포트폴리오를 보유한 많은 기업이 이를 선호하는 이유입니다.
• BSD 라이선스(2조항 및 3조항)는 캘리포니아 대학교 버클리(UC Berkeley)에서 Berkeley Software Distribution 운영체제를 위해 만들어졌습니다. 3조항 버전은 허가 없이 원저작자의 이름을 파생 제품 홍보에 사용하는 것을 금지하는 비승인 조항을 추가로 포함합니다.
• 도입자 입장의 실질적 효과: permissive 라이선스가 적용된 도구를 포크·수정·내장하여 폐쇄형 제품의 일부로 판매하면서도 자체 소스코드를 전혀 공개하지 않아도 됩니다 — 실제 위험은 배포물에서 필수 저작권/라이선스 표시를 누락하는 것뿐입니다.
• 이 사이트 리뷰의 실제 사례: Ollama와 llama.cpp는 모두 MIT를 사용하며, vLLM은 Apache-2.0을 사용합니다 — 세 가지 모두 소스 공개 의무를 발생시키지 않고 상업 제품에 내장할 수 있습니다.

Copyleft란? GPL·LGPL 계열

• GNU General Public License(GPL)는 리처드 스톨먼과 자유소프트웨어재단(FSF)이 GNU 프로젝트의 라이선스로 작성했으며, 소프트웨어의 자유가 이후로도 계속 보존되어야 한다는 개념에 기반합니다 — 수정된 사본을 받는 사람은 원저작자와 동일한 권리를 가져야 한다는 것입니다.
• GPL v2와 GPL v3는 주로 특허 관련 문구와 호환성 조항에서 차이가 있습니다. v3는 명시적인 특허 보복 조항과 반(反)티보화 조항(법적으로 실행할 권리가 있는 수정 소프트웨어의 실행을 막는 하드웨어를 방지하는 조항)을 추가했습니다.
• GNU Lesser General Public License(LGPL)는 라이브러리에 한해 GPL을 완화합니다 — 라이브러리 구성 요소가 교체 가능한 상태를 유지하고 그 자체 소스코드가 공개되어 있는 한, LGPL 라이브러리를 독점 애플리케이션에 링크하면서도 애플리케이션 자체는 오픈소스화하지 않아도 됩니다.
• 실제로 의무를 발생시키는 것: GPL 대상 코드의 수정 사본을 배포하는 행위입니다. 단순히 수정되지 않은 GPL 소프트웨어를 사내에서 사용하거나, GPL 라이선스 운영체제 위에서 독점 소프트웨어를 실행하는 것만으로는 자체 코드가 자동으로 GPL의 적용을 받지 않습니다.
• 주의해야 할 대상: GPL 도구를 포크해 수정하여 상업 제품의 핵심으로 삼으려는 스타트업은 그 수정 사항을 공개하거나 포크를 피하는 계획이 필요합니다. 수정되지 않은 GPL 도구를 사내에서만 실행하는 기업에는 이러한 의무가 없습니다.

AGPL-3.0이 SaaS 허점을 막는 방식

• 막힌 허점: 순수 GPL 하에서는 수정 버전을 호스팅된 웹 서비스로 운영하는 것이 라이선스를 발동시키는 법적 의미의 "배포"에 해당하지 않았습니다 — 기업은 GPL 코드를 가져와 수정하고 SaaS 제품으로만 제공하면서 그 수정 사항을 공개할 필요가 전혀 없었습니다. 이는 비공식적으로 "ASP 허점"(application service provider) 또는 "SaaS 허점"으로 알려지게 되었습니다.
• AGPL-3.0은 바로 이 허점을 막기 위해 작성되었습니다. 네트워크 상호작용 조항을 추가하여, 수정된 소프트웨어의 기능을 네트워크를 통해 사용자에게 제공하는 것이 물리적 사본을 배포하는 것과 동일한 소스 공개 의무를 발동시키도록 했습니다.
• 호스팅 및 재판매에서 중요한 이유: AGPL 라이선스 도구를 가져와 수정한 뒤 클라이언트에게 호스팅 서비스로 제공하는 대행사나 호스팅 제공업체는 그 사용자에게 수정된 소스코드를 제공해야 합니다 — 수정 없이 그대로 운영하는 경우 이 의무는 발생하지 않습니다.
• 이 사이트 리뷰의 실제 사례: Jan, KoboldCpp, SillyTavern, text-generation-webui는 AGPL-3.0으로 제공됩니다 — 개인 또는 사내 용도로 수정 없이 자체 호스팅하는 데는 문제가 없지만, 이 중 하나를 수정해 호스팅 접근을 재판매하는 순간 법적 상황이 크게 달라집니다.
• 이는 라이선스 메커니즘 작동 방식에 대한 일반적인 설명이며 법률 자문이 아닙니다. 특정 배포가 AGPL-3.0의 정확한 문구상 "네트워크를 통해 제공"에 해당하는지는 귀하의 구체적인 아키텍처를 검토하는 변호사에게 확인해야 할 사항입니다.

Source-Available·"페어코드" 라이선스란?

• Business Source License(BSL, BUSL이라고도 함)는 처음부터 소스코드 접근권과 폭넓은 사용권을 부여하며, 향후 정해진 날짜에 라이선스가 진정한 오픈소스 라이선스(흔히 Apache-2.0이나 유사한 permissive 라이선스)로 전환됩니다 — 그 전환 전까지는 대개 경쟁 호스팅 제공을 막기 위한 명시된 상업적 이용 제한이 적용됩니다.
• Server Side Public License(SSPL)는 MongoDB가 만든 것으로, 소프트웨어를 서비스로 제공하는 자는 그 주변에 구축한 서비스 스택 전체도 오픈소스화해야 한다고 요구합니다 — AGPL-3.0보다 훨씬 광범위한 의무로, 경쟁 클라우드 제공업체의 상업적 호스팅을 사실상 불가능하게 만들도록 의도적으로 작성되었습니다.
• Commons Clause는 그 외에는 permissive이거나 copyleft인 기본 라이선스 위에 추가되는 제한 조항으로, 자유로운 사용과 수정은 허용하면서도 소프트웨어 판매나 유료 호스팅 서비스로의 제공은 특별히 금지합니다.
• 프로젝트가 이러한 라이선스로 옮겨가는 이유: 완전히 개방된 라이선스로 시작했다가 이후 source-available 라이선스를 채택하는 프로젝트는 대개 대형 클라우드 제공업체가 개발에 기여하지 않으면서 해당 프로젝트를 호스팅 서비스로 제공하는 상황에 대응하는 것입니다 — source-available 라이선스로 전환하면 유지관리자는 대부분의 개방성을 유지하면서 그 특정 경쟁적 이용만 차단할 수 있습니다.
• 도입자 입장의 실질적 효과: 대개 내부 용도로는 source-available 소프트웨어를 문제없이 읽고, 자체 호스팅하고, 수정할 수 있습니다. 제한이 발동하는 것은 라이선스 보유자 자체의 제공물과 경쟁하는 호스팅 제품으로 재판매하려 할 때입니다 — 프로젝트마다 문구가 크게 다르므로 구체적인 상업적 이용 조항을 반드시 읽으십시오.

독점 및 Freemium "무료" 라이선스는 무엇을 의미하는가?

• 비교표의 "무료(폐쇄형)"는 무비용 독점 소프트웨어를 의미합니다. 벤더의 서비스 약관에 따라 컴파일된 애플리케이션을 사용할 수 있지만, 소스코드에 접근할 수 없으며 이를 수정·감사·포크할 권리도 없습니다.
• 오픈소스 대안과 비교한 핵심 트레이드오프: 단일 벤더가 사용자 경험 전체를 통제하기 때문에 독점 무료 앱은 흔히 더 완성도가 높고 설치가 쉽습니다 — 그러나 그 제품을 계속 무료·안전·유지보수 상태로 유지할지는 전적으로 해당 벤더의 지속적인 의지에 달려 있습니다.
• 벤더 종속(vendor lock-in) 위험: 소스코드 접근권이 없으면 수정 버전을 자체 호스팅할 수 없고, 그 애플리케이션이 데이터를 정확히 어떻게 처리하는지 감사할 수 없으며, 벤더가 유지보수를 중단하거나 가격 모델을 바꾸거나 서비스를 종료할 경우 개발을 계속할 수 없습니다.
• 가장 신경 써야 할 대상: 독점 무료 도구를 중심으로 워크플로나 비즈니스 프로세스를 구축하는 사람은 문서화된 대체 계획을 갖추어야 합니다 — 어떤 벤더 종속에도 적용해야 할 것과 동일한 실사이며, "무료"는 "영구적"이나 "보장됨"을 의미하지 않기 때문입니다.
• Source-Available과는 다릅니다: source-available 라이선스(BSL, SSPL)는 상업적 이용이 제한되더라도 최소한 코드를 읽고 감사할 수는 있게 하지만, 완전히 독점적인 도구는 코드도 그러한 보장도 제공하지 않습니다.

AI 모델 라이선스는 어떻게 작동하는가: Open Weights, RAIL, 허용 사용 제한

• 완전히 permissive한 가중치: 일부 모델 계열은 표준 permissive 소프트웨어 라이선스(흔히 Apache-2.0)로 가중치를 공개하여, 코드에 부여하는 것과 동일한 폭넓은 사용권 — 용도 제한 없는 상업적 이용을 포함 — 을 부여합니다.
• RAIL 및 OpenRAIL 라이선스(Responsible AI License)는 BigScience의 BLOOM 모델 공개와 함께 등장했으며, 개방적 접근과 구체적인 금지 용도 목록을 결합하기 위해 법률 연구자들과 공동으로 설계되었습니다 — 일반적으로 허위정보 생성, 차별적 의사결정, 법률 위반 콘텐츠 같은 용도를 금지하는 한편, 그 외 폭넓은 상업적 이용은 허용합니다.
• 맞춤형 "커뮤니티" 또는 "open-weight" 라이선스: 여러 주요 모델 제공업체는 개방형 라이선스처럼 보이지만 용도 제한 조건을 추가한 맞춤형 라이선스로 가중치를 공개합니다. 가장 자주 인용되는 예는 Meta가 공개적으로 배포하는 모델 가중치에 첨부하는 커뮤니티 라이선스로, 폭넓은 무료 사용을 허용하지만 일정 사용 규모 임계값을 초과하면 별도의 상업 계약이 필요하도록 하고, 허용 사용 제한도 함께 부과합니다.
• 구체적으로 확인해야 할 사항: 상업적 이용이 애초에 허용되는지, 조건을 바꾸는 사용 규모나 매출 임계값이 있는지, 허용 사용 정책이 무엇을 금지하는지, 그리고 라이선스가 모델 출력을 이용해 경쟁 모델을 학습시키는 것을 제한하는지 — 이 마지막 제한은 여러 모델 전용 라이선스에서 나타나며 표준 소프트웨어 라이선스에는 상응하는 조항이 없습니다.
• 이는 법률 자문이 아닙니다. 모델 라이선스 조건은 동일한 제공업체의 릴리스 간에도 변경되므로, 동일 조직의 이전 릴리스와 연속성이 있다고 가정하지 말고 배포하려는 특정 모델 가중치에 첨부된 정확한 라이선스 문구를 확인하십시오.

누가 어떤 라이선스를 신경 써야 하는가

도입 전 라이선스 체크리스트: 도구 도입 전 확인할 7가지

1. 1
   저장소의 실제 LICENSE 파일을 읽는다
   Why it matters: 랜딩 페이지의 "오픈소스"라는 주장은 법적 사실이 아니라 마케팅일 수 있습니다 — 소스 저장소 안의 LICENSE(또는 NOTICE/COPYING) 파일이 권위 있는 문서이며, 배지나 가격 페이지가 아닙니다.
2. 2
   라이선스가 최근 변경되었는지 확인한다
   Why it matters: 일부 프로젝트는 상업적 성공을 거둔 후 permissive나 copyleft 라이선스에서 source-available 라이선스로 재라이선싱합니다 — 클라우드 제공업체가 기여 없이 인기 오픈소스 프로젝트를 호스팅하기 시작한 이후 이 패턴은 소프트웨어 업계 전반에서 반복되었습니다. 현재 파일만이 아니라 저장소의 라이선스 이력을 확인하십시오.
3. 3
   중요하다면 라이선스가 실제로 OSI 승인인지 확인한다
   Why it matters: BSL, SSPL 같은 source-available 라이선스는 흔히 오픈소스로 홍보되지만 Open Source Initiative의 승인 목록에는 없습니다 — OSI 승인이 사용 사례의 요건이라면 프로젝트 자체의 설명을 믿기보다 목록을 직접 확인하십시오.
4. 4
   AI 모델에 특화된 상업적 이용 및 용도 제한 조항을 읽는다
   Why it matters: 모델의 라이선스는 상업적 이용을 폭넓게 허용할 수도, 사용 규모 임계값 이상에서 제한할 수도, 특정 응용을 아예 금지할 수도 있습니다 — 이 조항들은 표준 소프트웨어 라이선스 문구 밖에 있으며 코드 라이선스만 확인하면 놓치기 쉽습니다.
5. 5
   자체 호스팅과 SaaS 호스팅 중 어느 쪽이 의무를 바꾸는지 판단한다
   Why it matters: AGPL-3.0 하에서는 수정된 소프트웨어를 네트워크를 통해 제공하는 것이 GPL 하에서 사본을 배포하는 것과 동일한 공개 의무를 발동시킵니다 — 코드를 수정하기 전에 계획 중인 배포가 어느 범주에 해당하는지 확인하십시오.
6. 6
   기여를 계획한다면 기여자 라이선스 계약(CLA)이 있는지 확인한다
   Why it matters: CLA는 프로젝트 유지관리자에게 프로젝트 자체 라이선스가 사용자에게 부여하는 것보다 더 폭넓은 권리를 귀하의 기여물에 대해 부여할 수 있습니다 — 이는 주로 프로젝트에 코드를 되돌려 보낼 계획이 있을 때 관련이 있으며, 단순히 소비만 한다면 관련이 없습니다.
7. 7
   코드 라이선스와는 별도로 상표 제한을 확인한다
   Why it matters: permissive나 copyleft 코드 라이선스가 자동으로 프로젝트의 이름이나 로고에 대한 권리를 부여하지는 않습니다 — 코드 라이선스가 포크를 허용하더라도 상표법에 의해 도구의 포크 및 리브랜딩이 막힐 수 있습니다.

흔한 실수

• 저장소의 실제 LICENSE 파일을 읽지 않고 마케팅 페이지의 "오픈소스" 주장을 그대로 믿는 것.
• AGPL-3.0이 소프트웨어 사본을 배포할 때만 문제가 된다고 가정하는 것 — 수정된 코드를 호스팅 서비스로 제공하는 경우에도 적용됨.
• 모델의 코드 라이선스와 가중치 라이선스를 동일한 문서로 취급하는 것 — 실제로는 다른 경우가 많음.
• 코드 라이선스와는 별도인 상표 제한을 확인하지 않고 도구를 포크·리브랜딩하는 것.
• 프로젝트 시작 당시 permissive였던 라이선스가 이후 재라이선싱 후에도 그대로라고 가정하는 것 — 기억이 아니라 현재 라이선스를 확인해야 함.
• "무료니까"라는 이유로 copyleft나 source-available 도구의 법무 검토를 생략하는 것 — 무료 사용 가능과 의무 없음은 같은 말이 아님.

출처

• Open Source Initiative — The Open Source Definition — 라이선스가 OSI 승인 오픈소스로 인증받기 위해 충족해야 하는 공식 정의.
• GNU 프로젝트 — Free Software Licenses — GPL, LGPL, AGPL에 대한 자유소프트웨어재단 자체 설명.
• Apache Software Foundation — Apache License 2.0 — 라이선스 전문.
• MIT 라이선스 전문(Open Source Initiative) — 라이선스 전문.
• MongoDB — Server Side Public License — SSPL 자체 조건과 근거.
• Business Source License FAQ — 이 라이선스를 널리 채택한 사례를 통해 BSL/BUSL 전환 방식을 설명.

자주 묻는 질문

관련 읽을거리

• 로컬 LLM 소프트웨어 완전 디렉터리 — 항목마다 라이선스가 명시된 160개 이상의 로컬 LLM 도구.
• Dify AI Workflow Builder 리뷰 — 라이선스를 명시한 리뷰. 이 가이드를 통해 그 라이선스가 귀하의 배포에 어떤 의미인지 이해할 수 있습니다.
• AI 생성 콘텐츠와 지식재산권 위험 — AI 생성 결과물을 상업적으로 배포할 때 라이선스와 함께 고려해야 할 지식재산권 문제.
• 에이전틱 AI 보안: 아이덴티티와 접근 관리 — 자체 호스팅 AI 배포의 보안 및 거버넌스 고려사항, 라이선스 준수와 함께 검토해야 할 사항.
• 민감 문서를 위한 GDPR 준수 로컬 RAG — 라이선스 위험과 데이터 레지던시/컴플라이언스 위험은 별개의 체크리스트이며, 이 가이드는 컴플라이언스 측면을 다룹니다.