라이선스별 상업적 이용 가능 여부
라이선스별 상업적 이용 가능 여부는 AI 모델과 오픈소스 프로젝트를 회사 제품에 써도 되는지, 쓴다면 무엇을 지켜야 하는지를 라이선스별로 정리한 문서다.
"오픈소스니까 그냥 써도 되겠지"가 가장 비싼 오해다. 이름에 '오픈'이 붙었어도 상업적 이용이 아예 막힌 것, 매출이 일정 규모를 넘으면 유료로 바뀌는 것, 소스 공개 의무가 따라오는 것이 섞여 있다.
먼저: 오픈소스와 오픈 웨이트는 다른 말이다
이 구분을 못 하면 나머지를 아무리 읽어도 소용이 없다.
| 용어 | 뜻 | 상업적 이용 | 예 |
|---|---|---|---|
| 오픈소스 | OSI 정의를 충족하는 라이선스 | 대체로 자유 | MIT, Apache-2.0 |
| 오픈 웨이트 | 가중치를 내려받을 수 있을 뿐 | 조건이 붙는다 | Llama 커뮤니티 라이선스 |
| 비공개 | API로만 접근 | 제공사 약관에 따름 | GPT-5, Claude |
기사나 보도자료에서 "오픈소스 모델"이라고 쓰는 것들 상당수가 실제로는 오픈 웨이트다. 가중치를 공개했다고 오픈소스가 되지는 않는다.
핵심 기준은 용도 제한이다. OSI 정의는 "어떤 목적으로든 쓸 수 있을 것"을 요구한다. 사용 제한 조항이 하나라도 붙으면 그 시점에 오픈소스가 아니게 된다. OSI는 2025년 2월 분석에서 Llama 라이선스가 용도 제한과 사용자 차별 때문에 오픈소스 정의를 충족하지 못한다고 결론지었다.
한눈에 보기
| 판정 | 해당 라이선스 | 핵심 조건 |
|---|---|---|
| 상업적 이용 가능 | MIT, Apache-2.0, BSD 계열, ISC, MPL-2.0, CC0, CC-BY | 저작권 고지 유지 |
| 조건부 · 소스 공개 | GPL 계열, LGPL 계열 | 배포 시 파생물 소스 공개 |
| 조건부 · 서비스도 공개 | AGPL-3.0 | 웹 서비스로 제공만 해도 소스 공개 |
| 조건부 · 규모 제한 | Llama 커뮤니티 라이선스 | 출시일 기준 MAU 7억 초과 시 별도 계약 |
| 조건부 · 매출 기준 | Stability Community License | 연매출 100만 달러 초과 시 유료 |
| 상업적 이용 불가 | CC-BY-NC 계열, FLUX.1 [dev], Mistral MNPL | 별도 상업 라이선스 구매 필요 |
허가형 라이선스
가장 마음 편한 쪽이다. 상업적 이용, 수정, 재배포, 비공개 소프트웨어에 포함하는 것까지 전부 된다. 다만 아무 의무도 없는 것은 아니다.
| 라이선스 | 판정 | 반드시 지킬 것 | 특징 |
|---|---|---|---|
| MIT | MIT 상업적 이용 가능 | 저작권 고지 + 라이선스 전문 포함 | 가장 짧고 단순 |
| Apache-2.0 | Apache-2.0 상업적 이용 가능 | 고지 + NOTICE 파일 유지 + 변경 사실 명시 | 특허 사용권 명시 — 기업이 선호 |
| BSD-3-Clause | BSD-3-Clause 상업적 이용 가능 | 고지 + 이름으로 홍보 금지 | MIT와 거의 동일 |
| ISC | ISC 상업적 이용 가능 | 저작권 고지 | MIT를 더 줄인 것 |
| MPL-2.0 | MPL-2.0 상업적 이용 가능 | 수정한 파일만 같은 라이선스 유지 | 파일 단위 카피레프트 |
고지 의무를 실제로 어떻게 지키나
"저작권 고지를 포함하라"는 문구가 추상적으로 들리지만, 실무에서는 내 제품 어딘가에 원저작자 정보를 표시하라는 뜻이다.
- 웹 서비스 — 설정·정보 화면에 "오픈소스 라이선스" 항목을 만들고 목록을 넣는다
- 모바일 앱 — 대부분의 앱에 있는 "오픈소스 라이선스" 화면이 이것이다
- 배포 프로그램 — 설치 폴더에
LICENSES또는NOTICE파일 - 라이브러리 — 패키지에 라이선스 파일을 동봉한다
의존성이 수백 개면 손으로 관리할 수 없다. 라이선스 목록을 자동 수집하는 도구를 빌드 과정에 넣는 것이 일반적이다.
Apache-2.0이 MIT보다 기업에 안전한 이유
특허 조항 때문이다. 기여자가 자기 특허를 쓸 권리를 명시적으로 준다. MIT에는 그 문구가 없어서, 나중에 특허 분쟁이 생길 여지가 이론적으로 남는다. 그래서 법무 검토가 있는 회사는 Apache-2.0을 선호한다.
Apache-2.0은 대신 의무가 하나 더 있다. NOTICE 파일이 원본에 있으면 그대로 전달해야 하고, 파일을 수정했다면 수정했다는 사실을 표시해야 한다.
MPL-2.0은 파일 단위로만 카피레프트가 걸린다. MPL 파일을 고쳤다면 그 파일만 MPL로 공개하면 되고, 나머지 자사 코드는 비공개로 둘 수 있다. GPL과 이 점이 결정적으로 다르다.
"오픈소스를 쓰되 우리 코드는 공개하고 싶지 않다"는 상황에서 MPL 프로젝트는 선택지가 되지만 GPL 프로젝트는 아니다.
카피레프트 라이선스
쓸 수는 있지만 소스 공개 의무가 따라온다. 어디까지 공개해야 하는지가 라이선스마다 다르고, 그 차이가 사업에 치명적일 수 있다.
| 라이선스 | 판정 | 언제 공개 의무가 생기나 |
|---|---|---|
| LGPL | LGPL-3.0 조건부 · 소스 공개 의무 | 라이브러리를 수정해서 배포할 때 |
| GPL-2.0 / 3.0 | GPL-3.0 조건부 · 소스 공개 의무 | 파생물을 배포할 때 |
| AGPL-3.0 | AGPL-3.0 조건부 · 서비스 제공 시에도 소스 공개 | 네트워크로 제공만 해도 발생 |
배포하지 않으면 의무가 없다
GPL을 이해하는 열쇠다. GPL의 의무는 "배포"할 때 발생한다. 사내에서만 쓰고 밖으로 내보내지 않으면 소스를 공개할 의무가 없다.
사내 도구, 내부 배치 작업, 회사 서버에서만 도는 프로그램은 GPL 코드를 써도 공개 의무가 생기지 않는다. 이 점 때문에 "GPL은 무조건 위험하다"는 인식은 과장이다.
LGPL — 링크 방식이 갈림길
LGPL은 라이브러리를 고치지 않고 갖다 쓰기만 하면 자사 코드를 비공개로 둘 수 있다. 다만 조건이 있다. 사용자가 그 라이브러리를 다른 버전으로 교체할 수 있어야 한다.
- 동적 링크 — 대체로 안전하다. 사용자가 라이브러리 파일을 바꿔 끼울 수 있다
- 정적 링크 — 교체가 불가능해지므로 추가 조건이 붙는다
실무에서는 동적 링크로 쓰고 라이브러리를 수정하지 않는 것이 안전한 경로다.
AGPL — SaaS에 가장 위험하다
AGPL은 웹 서비스를 만드는 회사에 가장 위험한 라이선스다.
GPL은 소프트웨어를 배포할 때만 소스 공개 의무가 생긴다. 그래서 웹 서비스로만 제공하면 공개하지 않아도 됐다. 이 구멍을 막으려고 만든 것이 AGPL이다.
AGPL 코드를 쓴 웹 서비스는 사용자에게 서비스를 제공하는 것만으로 전체 소스를 공개해야 한다. AGPL 라이브러리 하나를 백엔드에 넣었다가 서비스 코드 전체를 공개해야 하는 상황이 실제로 발생한다.
"사내에서만 쓰니 괜찮다"는 GPL에는 맞고 AGPL에는 틀리다. 사내 웹 서비스라도 네트워크로 제공하면 의무가 발생할 수 있다.
AI 도구 중에도 AGPL로 배포되는 것이 있다. 도입 전에 반드시 확인할 것.
AGPL 프로젝트는 대개 듀얼 라이선스 전략을 쓴다. 무료로 쓰려면 AGPL을 지키고, 소스를 공개하기 싫으면 상업 라이선스를 사라는 구조다. "AGPL이라서 못 쓴다"가 아니라 "돈을 내면 쓸 수 있다"인 경우가 많다.
크리에이티브 커먼즈 — 데이터셋에서 자주 만난다
소프트웨어보다 데이터셋과 모델 카드에서 자주 보인다. 조합형이라 붙은 기호를 읽을 줄 알면 판정이 바로 나온다.
| 기호 | 뜻 | 결과 |
|---|---|---|
| BY | 저작자 표시 | 출처만 밝히면 됨 |
| SA | 동일조건변경허락 | 파생물도 같은 라이선스로 배포 |
| NC | 비영리 | 상업적 이용 불가 |
| ND | 변경 금지 | 수정·가공 불가 |
| 라이선스 | 판정 |
|---|---|
| CC0 | CC0 상업적 이용 가능 — 저작권을 포기한 것. 사실상 제약 없음 |
| CC-BY | CC-BY 상업적 이용 가능 · 출처 표시 |
| CC-BY-SA | 상업적 이용 가능. 단 파생물도 CC-BY-SA로 배포해야 함 |
| CC-BY-NC | CC-BY-NC 상업적 이용 불가 |
| CC-BY-NC-SA | 상업적 이용 불가 + 동일조건 |
ND(변경 금지)가 붙은 데이터셋은 학습에 쓰기 어렵다.
데이터를 정제·변환·토큰화하는 과정 자체가 "변경"에 해당할 수 있기 때문이다. 데이터셋 라이선스에서 ND를 발견하면 그 데이터로 모델을 학습시켜도 되는지를 따로 확인해야 한다. 상업적 이용 여부보다 먼저 걸리는 조건이다.
SA는 방향이 한쪽으로만 열린다. CC-BY 자료를 CC-BY-SA로 묶는 것은 되지만, CC-BY-SA 자료를 조건이 다른 라이선스로 재배포하는 것은 안 된다. 서로 다른 SA 라이선스끼리도 섞이지 않는다.
모델 전용 라이선스
여기가 진짜 함정 지대다. 기존 오픈소스 라이선스가 아니라 개발사가 직접 쓴 라이선스라서, 이름만 보고 판단할 수 없고 원문을 읽어야 한다.
Llama 커뮤니티 라이선스
Llama 조건부 · 사용자 규모 제한 (출시일 기준 MAU 7억 초과 시 Meta와 별도 계약)
상업적 이용은 된다. 다만 오픈소스 라이선스에는 없는 조항이 여럿 붙는다. 아래는 Llama 4 커뮤니티 라이선스 원문 기준이다.[1]
① 월간 활성 사용자 7억 조항 — 흔히 잘못 알려져 있다
원문은 이렇게 규정한다.
> "해당 Llama 버전 출시일에, 라이선시 또는 계열사가 제공하는 제품·서비스의 > 월간 활성 사용자가 직전 달 기준 7억 명을 초과하면, Meta에 라이선스를 > 요청해야 하며 Meta는 재량으로 이를 허가할 수 있다."
두 가지가 중요하다.
- 판정 시점이 "버전 출시일"이다. 나중에 서비스가 커져서 7억 명을 넘게 되는 것은
이 조항에 걸리지 않는다. "7억 넘으면 못 쓴다"고만 적힌 설명은 부정확하다.
- Meta의 재량이다. 요청하면 받을 수 있는 권리가 아니라, 줄 수도 있고 안 줄 수도 있다.
현실적으로 이 조항에 걸리는 회사는 극소수다. 다만 계열사 합산이라는 점은 대기업 계열이라면 확인할 필요가 있다.
② 표시 의무 두 가지
Llama 자료나 그 파생물을 배포하거나, 그것을 포함한 제품·서비스를 제공할 때 원문은 다음을 요구한다.
- (A) 라이선스 사본을 함께 제공할 것
- (B) "Built with Llama" 를 관련 웹사이트·사용자 인터페이스·블로그 글·소개 페이지
또는 제품 문서에 눈에 띄게 표시할 것
③ 파생 모델의 이름
Llama 자료 또는 그 출력물을 써서 AI 모델을 만들거나 학습·파인튜닝한 뒤 배포한다면, 모델 이름 맨 앞에 "Llama"를 붙여야 한다.
출력물로 학습한 경우까지 포함된다는 점이 중요하다. Llama로 합성 데이터를 만들어 다른 모델을 학습시킨 경우도 해당한다.
④ 고지 문구
배포하는 사본에는 다음 문구를 담은 고지를 유지해야 한다.
[모델명] is licensed under the Llama 4 Community License, Copyright © Meta Platforms, Inc. All Rights Reserved.
⑤ 사용 제한 정책(AUP)
별도 문서로 존재하며 계약에 편입된다. 즉 AUP 위반은 라이선스 위반이다.
⑥ 예외 조항
라이선시가 만든 최종 사용자 제품의 일부로 Llama 자료를 받은 사람에게는 MAU 조항이 적용되지 않는다. 남이 만든 앱을 쓰는 사용자까지 이 조항에 묶이지는 않는다는 뜻이다.
버전마다 조항이 달라져 왔다. 3.1, 3.2, 3.3, 4의 내용이 같지 않고, 일부 멀티모달 버전은 EU 소재 법인의 이용을 제한한 전례가 있다. 쓰려는 버전의 원문을 봐야 한다.
Gemma — 버전에 따라 다르다
Google의 Gemma는 초기 버전이 자체 이용약관과 금지 사용 정책을 달고 나왔다. 그런데 Gemma 4부터 Apache-2.0으로 바뀌었다. 같은 이름이라도 버전에 따라 판정이 정반대가 된다.
"이 모델 라이선스가 뭐냐"는 질문은 성립하지 않는다.
"이 모델의 이 버전 라이선스가 뭐냐"로 물어야 한다.
Gemma가 그 대표적인 사례다. 같은 이름으로 검색해 나온 옛 글을 근거로 판단하면 정반대 결론에 도달한다.
OpenRAIL 계열
OpenRAIL-M 조건부 · 사용 제한 조항
Stable Diffusion 초기 버전 등이 쓴 라이선스다. 상업적 이용은 되지만 용도 제한 조항이 붙어 있다. 특정 목적(불법 행위, 차별, 허위정보 생성 등)에 쓰지 않겠다는 조건이고, 이 조건을 하위 배포자에게도 그대로 전달해야 한다.
용도 제한이 있으므로 OSI 기준 오픈소스가 아니다.
Stability Community License
Stability Community 조건부 · 매출 기준 초과 시 유료 (연매출 100만 달러 기준)
Stability AI가 쓰는 방식이다. 연매출 100만 달러 미만인 개인·조직은 연구·비상업·상업 이용이 모두 무료다. 그 이상이면 Professional 또는 Enterprise 라이선스를 사야 한다.
스타트업에는 관대하고 성공하면 돈을 받는 구조다. 매출이 기준선을 넘는 시점에 라이선스를 갱신해야 한다는 점을 놓치기 쉽다. 매출은 회사가 커질수록 자동으로 넘어가므로, 도입 시점에 문제없다고 영원히 문제없는 것이 아니다.
FLUX — 버전마다 정반대다
| 버전 | 라이선스 | 상업적 이용 |
|---|---|---|
| FLUX.1 [schnell] | Apache-2.0 상업적 이용 가능 | 가능 |
| FLUX.1 [dev] | FLUX non-commercial 상업적 이용 불가 · 별도 계약 필요 | 불가 — 별도 상업 라이선스 구매 필요 |
| FLUX.1 [pro] | 독점 | API로만 제공 |
같은 FLUX인데 schnell은 되고 dev는 안 된다. 성능이 좋은 dev를 쓰다가 상업 서비스에 그대로 올리는 사고가 실제로 자주 일어난다. 상업 라이선스는 공식 포털에서 구매할 수 있다.
Mistral MNPL
MNPL 상업적 이용 불가 · 별도 계약 필요
Mistral AI는 모델 대부분을 Apache-2.0으로 내지만, 일부는 MNPL(Mistral Non-Production License)로 낸다. 이름 그대로 프로덕션 사용 불가다. Mistral Large 3, Mistral Small 4 등 주요 모델은 Apache-2.0이지만 모델별로 확인해야 한다.
파인튜닝하면 내 것이 되나
아니다. 실무에서 가장 자주 나오는 오해다.
원본 모델의 라이선스는 파생 모델에도 그대로 따라온다.
- Llama를 파인튜닝했다면 → 모델 이름 앞에 "Llama", "Built with Llama" 표시, AUP 준수
- Apache-2.0 모델을 파인튜닝했다면 → 고지만 유지하면 자유
- 비상업 라이선스 모델을 파인튜닝했다면 → 파생물도 비상업
출력물로 학습시킨 경우까지 걸리는 라이선스가 있다. Llama가 그렇다. Llama로 합성 데이터를 만들어 다른 모델을 학습시켜도 이름 규정이 적용된다.
"우리가 데이터를 넣고 다시 학습시켰으니 우리 모델"이라는 주장은 라이선스 앞에서 성립하지 않는다.
모델 라이선스와 출력물의 권리는 다르다
둘은 별개 문제다.
- 모델 라이선스 — 모델 자체를 쓰고 배포할 권리
- 출력물의 권리 — 그 모델이 만들어 낸 이미지·텍스트·코드를 쓸 권리
이미지 생성 모델에서 특히 중요하다. 모델을 상업적으로 쓸 수 있다고 해서 생성된 이미지를 상업적으로 쓸 수 있다는 보장이 자동으로 따라오지 않는다. 제공사 약관에 별도로 규정되어 있는 경우가 많다.
API 서비스는 대개 약관에 출력물 권리를 명시한다. 자체 호스팅하는 오픈 웨이트 모델이라면 모델 라이선스와 함께 출력물 조항을 따로 찾아야 한다.
자주 하는 실수
① "오픈소스라고 적혀 있어서 썼다"
기사·블로그·심지어 개발사 보도자료도 오픈 웨이트를 오픈소스라고 부른다.
공식 저장소의 LICENSE 파일을 직접 열어 보는 것 말고는 방법이 없다.
② 버전을 확인하지 않았다
Gemma, FLUX, Mistral, Stable Diffusion 전부 버전에 따라 판정이 뒤집힌다. "작년에 확인했다"는 근거가 되지 않는다.
③ 파인튜닝하면 내 것이 된다고 생각했다
위에서 다뤘다. 원본 라이선스가 파생물에도 따라온다.
④ 모델 라이선스와 출력물 권리를 혼동했다
둘은 별개 조항으로 규정된다.
⑤ 사내에서만 쓰니 괜찮다고 판단했다
GPL은 그 판단이 맞다. AGPL은 틀리다.
⑥ 도입 시점에만 확인하고 끝냈다
매출 기준 라이선스는 회사가 커지면 자동으로 조건이 바뀐다. 라이선스는 갱신 대상이지 일회성 확인 대상이 아니다.
⑦ 의존성의 의존성을 안 봤다
내가 고른 라이브러리가 MIT여도, 그것이 끌어오는 라이브러리가 GPL일 수 있다. 전체 의존성 트리를 훑는 도구를 쓰지 않으면 놓친다.
라이선스 원문을 어디서 확인하나
| 대상 | 확인할 곳 |
|---|---|
| 오픈소스 프로젝트 | GitHub 저장소 루트의 LICENSE 파일
|
| 모델 (Hugging Face) | 모델 카드 상단 라이선스 표시 + 저장소의 LICENSE
|
| 모델 (자체 배포) | 개발사 공식 라이선스 페이지. 버전별 URL이 다르다 |
| 패키지 | package.json, pyproject.toml 등의 license 필드
|
README에 적힌 라이선스 이름을 믿지 말 것. 갱신이 안 된 경우가 있다.
LICENSE 파일 원문이 기준이다.
동의해야 내려받히는 모델
Hugging Face의 일부 모델은 약관에 동의해야 다운로드가 열린다. Llama 계열이 대표적이다. 이름·소속을 입력하고 라이선스에 동의하면 계정에 접근 권한이 붙는다.
이 절차 자체가 라이선스에 동의했다는 기록이 된다는 점을 알아 둘 필요가 있다. "몰랐다"가 통하지 않는 구조이고, 사내에서 누가 어떤 계정으로 동의했는지도 관리 대상이 된다. 자동 배포 파이프라인에서 토큰으로 내려받는 경우 그 토큰의 주인이 동의한 것으로 처리된다.
도입 전 체크리스트
□ 공식 저장소의 LICENSE 파일 원문을 직접 열어 봤다 □ 내가 쓰려는 '버전'의 라이선스를 확인했다 □ 상업적 이용이 되는지 확인했다 □ 소스 공개 의무가 있는지 확인했다 (특히 AGPL) □ 매출·사용자 수 기준선이 있는지 확인했다 □ 표기 의무(고지, NOTICE, "Built with ~", 모델 이름 규정)를 확인했다 □ 지역 제한이 있는지 확인했다 □ 파인튜닝·재배포 계획이 있다면 그 조건도 확인했다 □ 모델 출력물의 권리를 별도로 확인했다 □ 의존성의 의존성까지 훑었다 □ 매출·규모가 커졌을 때 재확인할 시점을 정해 뒀다
이 문서는 법률 자문이 아니다.
라이선스 해석은 사업 형태와 관할 법역에 따라 달라진다. 매출이 걸린 결정이라면 라이선스 원문을 근거로 법무 검토를 받는 것이 맞다. 이 문서는 무엇을 확인해야 하는지를 알려 줄 뿐이다.
여담
"오픈소스"라는 표현을 두고 업계와 OSI 사이에 계속 마찰이 있어 왔다. 개발사 입장에서는 가중치를 공개한 것만으로도 충분히 개방적이라고 보지만, OSI 정의는 용도를 제한하지 않을 것을 핵심 조건으로 삼는다. 사용 제한 조항이 하나라도 붙으면 그 시점에 오픈소스가 아니게 된다. 이 때문에 "오픈 웨이트"라는 별도 용어가 자리를 잡았다.
MAU 7억이라는 숫자도 이야깃거리다. 이 기준에 걸리는 회사는 전 세계에 몇 되지 않는다. 사실상 특정 거대 플랫폼들을 겨냥한 조항으로 읽히며, "누구나 쓸 수 있지만 우리 경쟁자는 안 된다"는 의도를 조항으로 옮긴 셈이다. 오픈소스 정의가 사용자 차별 금지를 요구하는 이유가 여기서 드러난다.
