오픈소스 라이선스 정리

오픈소스 라이선스란?

개요

소프트웨어를 어떤 조건으로 사용·수정·배포할 수 있는지 정한 규칙(법적 계약) 이다.

• 그냥 사용해도 되는지
• 수정해서 써도 되는지
• 회사 서비스에 넣어도 되는지
• 수정한 코드를 공개해야 하는지
• 상업적으로 판매해도 되는지

이런 것들을 라이선스가 결정한다.

즉, "이 소프트웨어를 어디까지 자유롭게 사용 가능한가?"를 결정 한다.

 

주요 항목

핵심적으로는 아래 항목들이 중요하다.

 

항목	의미
상업적 사용	회사, 서비스, 유료 제품에 사용가능 한가
수정 가능	소스코드를 수정 가능한가
재배포 가능	수정본을 다시 배포 가능한가
폐쇄형 서비스 가능	소스를 공개하지 않고 서비스 가능한가
SaaS 가능	웹 서비스 형태로 제공 가능한가
수정 코드 공개 의무	수정 시 공개해야 하는가
특허 보호	특허 관련 법적 보호가 있는가

 

오픈소스 라이선스 계열 구분

오픈소스 라이선스는 크게 보면 두 철학으로 나뉜다.

구분	Permissive License (허용형)	Copyleft License (카피레프트)
핵심 철학	출처만 남기고 자유롭게 사용	오픈소스를 사용했다면 결과물도 계속 공개
대표 라이선스	MIT, Apache 2.0, BSD	GPL, LGPL, AGPL
상업적 사용	매우 자유로움	가능하지만 조건 존재
폐쇄형 서비스 개발	가능	제한될 수 있음
수정 코드 공개 의무	거의 없음	상황에 따라 존재
SaaS 운영	자유로움	AGPL 등은 공개 의무 가능
기업 친화성	매우 높음	상대적으로 낮음
사업화 난이도	쉬움	법적 검토 필요
오픈소스 생태계 보호	상대적으로 약함	매우 강함
대표적인 기업 선호	스타트업, SaaS, 클라우드	자유소프트웨어 진영
대표적인 느낌	거의 공짜 느낌	강요 느낌(너도 계속 공개해라)

 

오픈소스별 라이선스 비교

라이선스	허용 범위	요구사항	장점	단점	대표 사례
MIT	● 상업적 사용 ● 수정 ● 재배포 ● SaaS ● 폐쇄형 S/W 포함 ● 내부 시스템 사용 ● 유료 제품 포함	● 원 저작권 표시 ● 라이선스 문구 유지	● 사업화가 매우 쉬움 ● 법적 부담이 적음 ● 생태계 확장에 유리	● 오픈소스 기여자가 보상을 못 받을 수 있다 ● 오픈소스 → 소스 비공개 제품으로 흡수될 수 있음	● React ● Vue.js ● Node.js ● jQuery ● OpenClaw
Apache 2.0	● 상업적 사용 ● 수정 ● 재배포 ● SaaS ● 폐쇄형 S/W 포함	● 변경 사항 명시 ● 라이선스 유지 ● NOTICE 파일 유지	● 기업 안정성 높음 ● 특허 분쟁 방어	● MIT보다 약간 복잡	● Kubernetes ● TensorFlow ● Android ● Apache HTTP Server
GPL (GNU General Public License)	● 수정 ● 재배포 ● 파생 프로젝트 생성	핵심 개념: Copyleft ● GPL 코드를 사용했으면 수정본도 반드시 GPL로 공개	● 오픈소스 생태계 보호 ● 기업 독점 방지	● 사업화 부담 ● 법적 해석이 복잡 (링크, 파생물, 플러그인, API)	● Linux Kernel (GPLv2) ● WordPress ● GNU Toolchain
LGPL (Lesser GPL)	● 폐쇄형 앱에서 라이브러리 사용 가능	● 라이브러리 자체 수정 시 공개			● glibc ● 일부 Qt 라이브러리
AGPL (Affero GPL)	핵심 개념: SaaS 시대를 겨냥한 GPL ● GPL보다 AGPL이 더 강력	● 서버에서 사용만 해도 공개 의무 발생	● 대형 클라우드 기업 견제(AWS 같은 곳이 그대로 SaaS화 하기 어려움) ● 오픈소스 유지력이 강함	● 기업 사용 장벽이 높음 ● SaaS 사업과 충돌 가능 ● 상용 플랫폼 운영 시 민감	● Nextcloud 일부 구성 ● 일부 Grafana 시기 ● MongoDB 일부 역사적 논쟁
BSD	MIT와 유사 (문구 차이 정도) ● 상업적 사용 ● 수정 ● 재배포 ● SaaS ● 폐쇄형 S/W 포함 ● 내부 시스템 사용 ● 유료 제품 포함				BSD 계열 코드가 많이 들어감 ● macOS ● iOS ● Cisco 장비
Source Available/Fair-code	● 코드 볼 수 있음 ● Github 공개 ● self-host 가능할 수도 있음 ● 수	● 경쟁 SaaS 운영 ● Managed Service 판매 ● 플랫폼 재판매	● 개발사의 지속가능성 확보 ● 코드 공개와 투명성 유지 ● Self-host 가능성이 높음 ● AI 시대와 잘 맞음 ● 클라우드 대기업 견제 가능	● 라이선스가 복잡함 ● 기업 도입 장벽 존재 ● SaaS/플랫폼 사업에는 제약 가능	● n8n ● 일부 Elastic 계열 ● 일부 MongoDB 계열 변화 ● AI 모델 라이선스들

 

MIT vs BSD

MIT와 BSD는 유사한 것 같지만 아래와 같은 분위기 차이가 있다.

• MIT: 현대 웹/JS 생태계 강함
• BSD: 역사적 UNIX 문화 강

Source Available / Fair-code

전통적인 오픈소스 라이선스의 계열에 더해서 "현대 SaaS / AI 시대의 제 3계열"로 설명하는 경우도 있지만 엄밀히 오픈소스 정의(OSI 기준)에서는 오픈소스가 아니다.

OSI(Open Source Initiative) 기준: 특정 사용 제한이 있으면 오픈소스로 인정 하지 않는다.

• 상업 사용 제한 X
• SaaS 제한 X
• 특정 기업 제한 X
• 경쟁 서비스 제한 X

Source Available은 기술적/분류적 표현이고, Fail-code는 철학적 표현이다.

• SaaS
• 클라우드
• AI 플랫폼
• Agent 서비스

시대가 되면서 빠르게 증가 중인 계열이다.

현실적으로 해석하자면

• Permissive: 자유시장형, "출처만 유지하면 거의 자유롭게 사용가능"
• Copyleft: 오픈소스 공동체 보호형, "오픈소스를 사용한 결과물도 계속 공개되어야 한다."
• Source Available / Fair-code: 오픈소스 정신 + 제작사 생존 전략, "코드는 공개하되 서비스 자체 복제는 제한하자"

구분	Source Available	Fair-code
본질	라이선스 상태	철학/운동
의미	코드 공개	개발자 지속가능성 강조
오픈소스 여부	보통 아님	보통 아님
사용 제한	있을 수 있음	보통 있음
목표	코드 공개 유지	사업 보호 + 공개 균형
대표 사례	각종 BSL/SSPL 계열	n8n 등