[64일차]오픈 소스 라이선스의 이해와 전략

오픈 소스의 법적 토대가 되는 '라이선스(License)'를 깊이 있게 다룬다.

1. 오픈 소스 판별의 핵심: 라이선스 유무

오픈 소스 소프트웨어(OSS)를 학습할 때 가장 먼저 명심해야 할 점은 "소스 코드가 공개되어 있다고 해서 모두 오픈 소스는 아니다"라는 사실이다.

깃허브(GitHub)의 퍼블릭(Public) 레포지토리는 누구나 코드를 볼 수 있지만, 라이선스가 명시되지 않았다면 타인이 이를 자유롭게 사용, 수정, 배포할 권한이 없다.
즉, 라이선스 파일(LICENSE)이 존재해야 비로소 오픈 소스로서의 법적 효력을 갖는다.

라이선스가 없는 프로젝트를 발견했을 때

코드가 유용하거나 학습 가치가 높음에도 라이선스가 없는 경우가 있다. 이 경우 저작권법에 의해 '모든 권리는 저작자에게 있음(All Rights Reserved)' 상태가 되므로 함부로 가져다 쓰면 법적 문제가 발생할 수 있다.

이때 깃허브의 기능을 활용하여 적극적으로 행동할 수 있다.

• 라이선스 제안(Propose New File): 깃허브 웹 인터페이스에서 'Add file' 기능을 통해 LICENSE 파일을 생성하고 저작자에게 풀 리퀘스트(PR)를 보낼 수 있다.
  • 의도: "당신의 코드가 훌륭하니, 오픈 소스로 공개하여 더 많은 사람이 쓸 수 있게 하는 것이 어떤가?"라는 정중한 제안이다.

---

2. 주요 라이선스 종류와 선택 가이드

라이선스를 직접 선택하거나 제안할 때는 프로젝트의 성격과 배포 목적을 고려해야 한다.
크게 허용적 라이선스(Permissive)와 공유를 강제하는 카피레프트(Copyleft) 계열로 나뉜다.

대표적인 라이선스 3종

1. MIT 라이선스 (Permissive)

   • 특징: 가장 단순하고 제한이 적다. 저작권 고지와 라이선스 사본만 포함하면 상업적 이용, 수정, 배포가 자유롭다.
   • 사용처: Node.js 생태계(npm), React, Vue.js 등 접근성을 높여 사용자 확장을 목표로 하는 프레임워크나 라이브러리에서 주로 사용한다.

2. Apache License 2.0 (Permissive + Patent)

   • 특징: MIT와 유사하게 자유로운 사용을 보장하지만, '특허권'에 대한 명시적인 허용 조항이 포함되어 있다. 기여자가 자신의 코드가 포함된 소프트웨어 사용자를 상대로 특허 소송을 제기하지 못하도록 막는다.
   • 사용처: 안드로이드, 쿠버네티스 등 기업 간 협업이 활발하거나 대규모 엔터프라이즈 프로젝트에서 선호한다.

3. GNU GPL v3 (Strong Copyleft)

   • 특징: 강력한 전염성을 가진다. 이 코드를 사용하여 만든 소프트웨어를 배포할 경우, 해당 소프트웨어의 전체 소스 코드도 동일한 GPL 라이선스로 공개해야 한다.
   • 사용처: 리눅스 커널, Git 등 소프트웨어의 자유 정신을 강력하게 지키고자 하는 프로젝트에서 사용한다.

---

3. 라이선스 변경과 분쟁 사례 (심화)

라이선스는 불변의 법칙이 아니다. 프로젝트의 소유권자(저작자)는 필요에 따라 라이선스를 변경할 수 있다.
최근 오픈 소스 기업들이 클라우드 제공 업체(CSP)와의 갈등으로 라이선스를 변경하며 큰 파장을 일으키기도 했다.

왜 변경하는가?

• 클라우드 기업들(예: Amazon AWS)이 오픈 소스(MongoDB, ElasticSearch 등)를 가져다가 유료 클라우드 서비스로 판매하면서도, 정작 원작자에게는 수익을 공유하거나 기여하지 않는 문제가 발생했다.
  이에 원작 기업들은 "오픈 소스 정신은 지키되, 클라우드 기업의 무임승차는 막겠다"는 명분으로 라이선스를 변경했다.

주요 변경 및 논란 사례

1. MongoDB (AGPL → SSPL)

   • 내용: 2018년, MongoDB는 AGPL에서 자체 제작한 SSPL(Server Side Public License)로 라이선스를 변경했다.
   • 논란: SSPL은 "MongoDB를 서비스로 제공하려면, 그 서비스의 인프라 코드까지 모두 공개하라"는 조항을 담고 있다. 이는 사실상 클라우드 업체를 겨냥한 것이다.
     OSI(오픈 소스 이니셔티브)는 SSPL을 공식 오픈 소스 라이선스로 인정하지 않아 논란이 되었다.

2. ElasticSearch (Apache 2.0 → SSPL/Elastic License)

   • 내용: 로그 분석 도구로 유명한 ElasticSearch는 2021년 라이선스를 변경했다.
   • 결과: 이에 반발한 AWS는 ElasticSearch의 마지막 오픈 소스 버전을 포크(Fork)하여 'OpenSearch'라는 별도의 오픈 소스 프로젝트를 출범시켰다. 이로 인해 생태계가 둘로 쪼개지는 진통을 겪었다.

3. Terraform by HashiCorp (MPL → BUSL)

   • 내용: 2023년, 인프라 관리 도구 Terraform이 상용 이용을 제한하는 BUSL(Business Source License)로 변경되었다.
   • 결과: 오픈 소스 진영은 이에 즉각 반발하여 'OpenTofu'라는 대체 프로젝트를 리눅스 재단 하에 출범시켰다.

이러한 사례들은 오픈 소스가 단순한 '무료 나눔'을 넘어 기업의 비즈니스 모델과 밀접하게 연관되어 있다는 점을 시사한다.

---

4. 오픈 소스 탐색 경로

오픈 소스 프로젝트에 참여하거나 학습하고 싶다면 다음 경로들을 활용할 수 있다.

• GitHub (Explore & Trending): 가장 거대한 플랫폼이다. 'Explore' 탭이나 'Trending'을 통해 현재 인기 있는 기술 트렌드를 파악할 수 있다.
• 기업별 오픈 소스 포털: 네이버(Naver Open Source), 카카오, 페이스북(Meta), 구글 등 IT 기업들은 자사가 공개한 기술을 모아둔 별도의 페이지를 운영한다.
• CodeTriage: 수많은 오픈 소스 프로젝트 중 이슈 처리가 필요한 프로젝트를 선별해서 보여주는 서비스이다. 언어별로 필터링하여 기여할 대상을 찾기 유용하다.
• Google Code-in (종료): 과거 구글이 학생들을 위해 운영했던 프로그램이다. 현재는 종료되었지만, 아카이브를 통해 어떤 방식의 기여가 있었는지 참고할 수 있다.