GPL vs MIT vs Apache 2.0 차이와 라이선스 역사

GPL, MIT, Apache: 각 라이선스가 요구하는 사항

GPL, MIT, Apache 2.0은 소프트웨어를 다른 사람에게 전달할 때 무엇을 해야 하는지에 대해 서로 다른 방식으로 답한다. MIT는 저작권 고지만 요구한다. 그 외에는 요구하지 않는다. Apache 2.0은 저작권 고지와 함께 코드에 관여하는 모든 사람 사이의 특허 관련 약정을 요구한다. GPL은 기반으로 만든 결과물의 소스 코드를, 받은 것과 동일한 라이선스로 공개하도록 요구한다.

이 문제는 프로젝트를 운영하는 소프트웨어의 라이선스가 변경되어 두 갈래로 나뉘는 날까지는 법률가에게나 해당하는 문제처럼 보인다. 그때부터는 운영 문제가 된다. 선택할 패키지 저장소가 2개가 되고, 서로 통신하지 못하는 클라이언트 라이브러리가 생긴다. 이 가이드는 해당 라이선스를 만든 운동이 아니라 라이선스와 그 작동 방식을 다룬다. 따라서 각 섹션은 결국 업그레이드를 수행해야 하는 운영 담당자에게 어떤 의미가 있는지에서 끝난다.

GPL이 존재하는 이유: 아무도 고칠 수 없었던 프린터

1980년 무렵 MIT Artificial Intelligence Lab은 Xerox 9700 레이저 프린터를 받았다. 연구소는 이전 프린터의 소프트웨어를 수정해 작업이 걸리면 사용자에게 알려 주도록 했다. 그러나 새 프린터에는 소스 코드가 없었고, 비밀 유지 계약을 이유로 소스 코드 요청도 거부되었다. 당시 연구소에서 프로그래머로 일하던 Richard Stallman은 이 거부를 단순한 불운이 아니라 일반적인 상황으로 받아들였고, 1983년 9월 27일 GNU 프로젝트를 발표했다.

Copyleft는 저작권법에 반대하는 것이 아니라 저작권법을 기반으로 한다. 기본적으로 다른 사람이 작성한 코드를 복사할 권리는 전혀 없다. GPL은 다음 조건으로 그 권리를 부여한다. 프로그램을 다른 사람에게 제공할 때는 같은 조건으로 소스 코드도 제공해야 한다. 그래야 그들이 연구소에서 할 수 없었던 작업을 할 수 있다. 라이선스가 없으면 애초에 허가를 받지 못했으므로 이 조건을 법적으로 집행할 수 있다.

Stallman은 먼저 GNU Emacs용 라이선스를 작성한 뒤, 이를 일반화해 1989년 2월 25일 GPL version 1으로 만들었다. GPL version 2는 1991년 6월에 나왔으며, 현재도 사용자가 실행하는 대부분의 시스템 소프트웨어에 적용되는 라이선스다. 라이브러리용으로 Lesser GPL도 나왔다. 이를 통해 copyleft 라이브러리는 어떤 라이선스로든 제공되는 프로그램에 링크할 수 있고, 해당 프로그램 전체가 GPL을 적용받도록 만들지 않아도 된다.

GPL이 self-hoster에게 어떤 영향을 미치는지는 한 가지 세부 사항으로 결정된다. 의무는 사용이 아니라 배포할 때 발생한다. GPL 프로그램을 수정해 자신의 서버에서 실행하고, 이를 사용해 대중에게 서비스를 제공하더라도 다른 사람에게 복사본을 제공하지 않았다면 누구에게도 소스 코드를 제공할 의무가 없다. AGPL이 존재하는 이유는 바로 이 차이 때문이다.

허용적 라이선스의 전통: BSD, 그리고 MIT

Berkeley는 다른 경로를 택했다. Computer Systems Research Group은 저작권 고지를 유지하고 모든 보증을 부인하도록 요구하는 라이선스로 Unix 작업물을 배포했다. 원래 버전에는 4개의 조항이 있었으며, 4번째 조항인 광고 조항은 소프트웨어의 기능을 언급하는 모든 광고 자료에 University를 명시하도록 요구했다. 이 방식은 규모를 확장할 수 없다. Stallman은 1997년 NetBSD 버전에서 별도의 명시 문구가 75개 있었다고 집계했다. UC Berkeley는 Office of Technology Licensing의 William Hoskins가 보낸 서한을 통해 1999년 7월 22일 이 조항을 철회했다.

남은 것은 기여자의 이름을 제품 보증에 사용하지 못하게 하는 금지 조항을 추가한 3-clause BSD licence와, 그 조항마저 삭제한 2-clause 버전이다. MIT licence 문안은 1980년대에 MIT에서 나왔으며, 당시 X Window System에 적용되었다. 실제로는 2-clause BSD와 같은 역할을 한다.

동기는 서로 달랐다. 공공 자금으로 운영되는 대학은 기업을 포함해 누구나 연구 결과를 사용하기를 원했다. GNU project는 폐쇄할 수 없는 공유 자산을 만들고자 했다. 두 입장 모두 정당하며, 각각 실패할 수 있는 지점도 있다. 허용적 라이선스 코드는 사유화될 수 있고, 그 결과 아무것도 돌려받지 못할 수 있다. 기업의 법무팀이 해당 조건을 받아들이지 않으면 copyleft 코드는 거부된다.

Berkeley에서 얻을 수 있는 두 번째 교훈이 있다. 이 글에서 계속 되돌아가는 주제이기도 하다. AT&T's Unix System Laboratories는 1992년 BSD 코드와 관련해 Berkeley Software Design을 상대로 소송을 제기했고, 사건은 1994년 초 합의로 종결되었다. 2년 동안 누구도 BSD를 기반으로 안심하고 개발할 수 있는지 확신할 수 없었고, Linux가 성장하는 동안 도입은 정체되었다. 법적 불확실성은 기능 하나가 없는 것보다 빠르게 도입을 막는다.

Apache 2.0에 특허 허여 조항이 추가된 이유

Apache Group의 첫 번째 라이선스는 동일한 광고 조항 문제를 가진 BSD 4-clause 파생 라이선스였다. 2000년에 나온 Version 1.1에서는 해당 조항을 삭제했다. 2004년 1월에 발표된 Version 2.0은 기존 라이선스에 수정 사항을 덧붙인 것이 아니라 새로 작성한 라이선스였다.

가장 중요한 추가 사항은 특허다. MIT와 BSD는 특허에 대해 전혀 규정하지 않는다. 기여자는 자신의 코드에 대해 명확한 저작권 사용 허가를 부여하면서도, 해당 코드의 동작에 적용되는 특허를 보유하고 코드를 사용하는 사람들을 상대로 소송을 제기할 수 있다. Apache 2.0은 이 공백을 막는다. 모든 기여자는 자신의 기여를 포괄하는 특허 라이선스를 부여한다. 또한 해당 저작물이 자신의 특허를 침해한다고 주장하며 소송을 제기하는 사람은 해당 저작물에 대한 자신의 특허 라이선스를 잃는다. 위협이 상호적이므로 실제로는 아무도 소송을 제기하지 않는다.

Version 2.0의 나머지 부분은 관리에 관한 내용이며, 이것이 기업에서 이 라이선스를 선호하는 이유다. 정의된 NOTICE 파일이 있으므로 저작자 표시를 소스 트리 곳곳에 흩어 놓지 않고 한곳에서 관리할 수 있다. 라이선스 전문을 모든 소스 파일에 붙여 넣지 않고 참조 방식으로 적용할 수 있다. 기여에는 명시적인 조건이 적용된다. 상표는 범위에서 제외된다. Apache 2.0 종속 항목을 법무 검토할 때 검토자가 확인하려는 모든 질문에 대한 답이 이미 라이선스 본문에 있으므로 승인이 정례적인 절차가 된다. 이것이 "기업 기본값"이 의미하는 바의 대부분이다.

GPLv3에서 변경된 내용과 Linux가 GPLv2를 유지한 이유

TiVo는 Linux를 실행하는 비디오 레코더를 출시하고 GPLv2의 요구 사항에 따라 커널 소스 코드를 공개했다. 그러나 하드웨어는 부팅할 때 암호화 서명을 확인하고, 인식하지 못하는 커널의 실행을 거부했다. 소스 코드를 읽고 수정한 뒤 컴파일할 수는 있었다. 하지만 해당 커널이 원래 실행되도록 설계된 장치에서는 실행할 수 없었다. 라이선스의 문구는 준수했지만 그 취지는 무력화되었으며, 이러한 관행에는 티보이제이션(tivoisation)이라는 이름이 붙었다.

2007년 6월 29일에 공개된 GPL version 3은 이 문제에 직접 대응한다. 소비자 장치에 바이너리를 전달하는 경우 "Installation Information"도 함께 제공해야 한다. 여기에는 수정된 버전을 설치하고 실행하는 데 필요한 키 또는 지침이 포함된다. Version 3에는 명시적인 특허 허여 조항도 추가되었다. 또한 2006년 11월 Microsoft와 Novell의 특허 계약에 대응하여 작성된 조항과 Apache 2.0과의 단방향 호환성도 추가되었다.

Linux는 이를 따르지 않았다. 커널은 "or any later version" 선택 조항이 없는 GPL version 2 only이며, COPYING 파일에도 그렇게 명시되어 있다. Linus Torvalds는 서명된 하드웨어에 적용되는 안티 티보이제이션 조항에 공개적으로 반대했다. 실질적인 장벽은 이러한 의견 차이보다 더 크다. 커널에는 저작권자가 수천 명이므로, 모두가 원한다고 해도 재라이선스에 필요한 동의를 누구도 모을 수 없다. 이 단일한 사실은 프로젝트가 가질 수 있는 가장 강력한 보호 장치이며, 단일 회사가 소유한 프로젝트를 살펴볼 때 기억할 가치가 있다.

2007년에 나온 다른 라이선스가 여러분에게는 더 중요하다. 같은 해 11월에 공개된 GNU Affero GPL version 3은 네트워크를 통해 프로그램과 상호 작용하는 사람에게까지 소스 코드 제공 의무를 확장한다. 수정한 AGPL 서비스를 대중에게 제공하면 해당 사용자에게 소스 코드를 제공해야 한다. 이것이 자체 호스팅 웹 소프트웨어의 상당수가 AGPL을 사용하는 이유다. Nextcloud가 한 예이며, Nextcloud의 자체 호스팅 대안을 비교하고 있다면 각 후보의 repository에 있는 라이선스 항목이 기능 목록보다 향후 5년을 더 잘 보여준다.

실제로 어떤 라이선스를 결합할 수 있는가?

호환성은 한 방향으로만 성립한다. 허용적 라이선스에서 카피레프트 라이선스로 결합하는 방향이다.

• MIT 및 BSD 라이선스 코드는 폐쇄형 제품을 포함해 어떤 제품에도 포함할 수 있다.
• Apache 2.0 라이선스 코드는 GPLv3 프로젝트에 포함할 수 있으며, 결합된 저작물에는 GPLv3이 적용된다.
• Apache 2.0 라이선스 코드는 GPLv2 전용 프로젝트에 포함할 수 없다. Apache 2.0의 특허 종료 및 면책 조항은 GPLv2에서 추가할 수 없는 추가 조건이다. FSF와 ASF 모두 이러한 결론을 공표한다.
• GPL 코드를 허용적 라이선스로 변경할 수는 없다. 저작권자만 이를 변경할 수 있으므로, 결국 저작권자가 누구인지 다시 확인해야 한다.

라이선스 변경의 시대: SSPL, BUSL, 그리고 두 라이선스가 아닌 것

계기는 상업적 이해관계였다. 한 회사가 제품의 저작권을 보유하고 있는데, 클라우드 제공업체가 해당 제품을 대규모 관리형 서비스로 판매하면서 회사에 거의 기여하지 않는 상황이 발생했다. 그러자 회사는 이를 막기 위해 라이선스를 변경했다. Redis Labs는 2018년 8월 여러 모듈에 Apache 2.0을 적용한 뒤 Commons Clause를 추가하면서 처음으로 눈에 띄는 조치를 취했다. MongoDB는 2018년 10월 16일 AGPLv3에서 Server Side Public License로 전환했다.

SSPL은 AGPL의 한 조항을 다시 작성한 라이선스다. 프로그램을 제3자에게 서비스로 제공하려면, 해당 서비스를 제공하는 데 사용하는 모든 소프트웨어의 소스 코드를 공개해야 한다. 여기에는 프로그램 주변의 관리 및 오케스트레이션 소프트웨어도 포함된다. 이 의무의 범위에는 명확한 경계가 없으며, 이를 판단한 법원 판례도 없다. OSI는 이 라이선스를 승인하지 않았고, MongoDB는 2019년 3월 신청을 철회했다. Debian은 이미 2018년 12월 SSPL 소프트웨어가 아카이브에 포함되지 않는다고 밝혔다. Fedora도 2019년 1월 이 라이선스가 자유 라이선스가 아니라고 결정했다. 이후 Red Hat은 Fedora와 Red Hat Enterprise Linux에서 MongoDB를 제외했다. 라이선스를 변경하면 발생하는 결과는 명확하다. 배포판이 해당 소프트웨어의 패키징을 중단하므로, 이제 업그레이드는 공급업체의 저장소에서 공급업체 일정에 따라 받아야 한다.

Business Source License는 다른 방식의 장치다. 이 라이선스는 MariaDB 창립자들이 만들었으며, 버전 1.1은 2017년에 발표되었다. copyleft 라이선스가 아니며 오픈 소스 라이선스도 아니다. 소스 코드는 공개되지만, 공급업체가 제외한 용도를 제외하면 사용은 무료다. 일반적으로 제외되는 용도는 경쟁 관계에 있는 호스팅 서비스를 운영하는 것이다. 또한 각 릴리스는 해당 릴리스 이후 최대 4년 이내의 변경일에 실제 오픈 소스 라이선스로 자동 전환된다. 전환되는 라이선스는 GPLv2와 호환되어야 한다. HashiCorp는 2023년 8월 10일 Terraform과 다른 제품을 BUSL 1.1로 변경했다. Outline도 이 라이선스를 사용한다. 따라서 self-hosted Notion 대안 중에서 선택할 때 알아둘 필요가 있다. 자체 팀을 위해 실행하는 것은 허용되지만, 이를 기반으로 서비스를 구축하는 것은 허용되지 않는다.

두 라이선스 모두 부정직한 라이선스는 아니다. 둘 다 소스 코드를 공개한다고 명확히 밝힌다. OSI의 정의에 따른 오픈 소스는 아니며, 그 차이의 영향은 이 라이선스가 겨냥한 클라우드 제공업체가 아니라 사용자에게 돌아온다.

OpenSearch: 라이선스 포크가 운영자에게 초래한 비용

Elastic은 2021년 1월 14일에 Elasticsearch와 Kibana가 7.11 릴리스부터 Apache 2.0을 벗어나 SSPL 또는 Elastic License 중 하나를 선택하게 된다고 발표했다. Version 7.10.2가 Apache 2.0으로 배포된 마지막 릴리스였다. 약 일주일 뒤 AWS는 두 프로젝트의 Apache 2.0 포크를 만들고 유지 관리하겠다고 밝혔다. 2021년 4월 12일 이 포크의 이름은 OpenSearch로 정해졌고, Kibana는 OpenSearch Dashboards로 이름이 바뀌었다. OpenSearch 1.0은 Elasticsearch 7.10.2와 Kibana 7.10.2를 기반으로 빌드되어 2021년 7월 12일 정식 출시되었다.

클러스터를 운영하던 사람들이 실제로 어떤 비용을 치렀는지 살펴보자. 패키지 이름과 저장소가 바뀌었다. runbook의 모든 Kibana 참조를 OpenSearch Dashboards로 바꿔야 했다. 플러그인 이름도 변경되었다. 그다음에는 분할이 애플리케이션 코드까지 이어졌다. Elastic의 공식 client library는 version 7.13부터 연결한 대상이 무엇인지 확인하며, Elasticsearch가 아닌 대상에 대해서는 계속 실행하지 않고 서버가 알 수 없는 제품이라고 보고한다. 자신이 근무하지 않는 회사의 라이선스 결정이 자신의 애플리케이션 내부에서 실패하는 호출로 나타난 것이다.

이 이야기는 이후 두 번 더 방향을 바꾸었다. Elastic은 2024년 8월 29일 세 번째 라이선스 선택지로 AGPLv3를 추가했으므로, 현재 Elasticsearch는 다시 OSI 승인을 받은 오픈 소스가 되었다. 2024년 9월 16일 AWS는 OpenSearch를 Linux Foundation이 주최하는 OpenSearch Software Foundation으로 이전했다. 이에 따라 이 포크에는 단일 회사가 아닌 거버넌스 기반이 마련되었다. 분할 후 5년이 지난 시점에 두 프로젝트 모두 오픈 소스이며 유지 관리되고 있다. 2026년 8월 기준 OpenSearch는 3.x series에 있다.

결말이 주는 교훈은 분명하다. 라이선스는 원래대로 돌아왔지만 포크는 남았다. 생태계에 모든 구성 요소가 2개씩 생기면, 문서를 되돌리는 것만으로는 다시 하나로 합쳐지지 않는다.

라이선스 변경이 얼마나 큰 부담이 되는지를 결정하는 수치는 발표 시점과 실제로 배포할 수 있는 안정적인 포크 사이의 간격이다.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

각 간격은 vendor의 공식 발표일부터 포크의 첫 stable release일까지 계산하며, 아래에 나열한 날짜를 사용한다. OpenSearch 1.0에는 179일이 걸렸다. 복사할 기존 포크가 없었기 때문에 포크 이름을 바꾸고 다시 빌드해야 했기 때문이다. OpenTofu에는 153일이 걸렸다. Valkey에는 27일이 걸렸다. Redis 7.2.4에서 포크되었고 protocol과 on-disk format을 동일하게 유지했기 때문이다. 중요한 점은 그 방향이다. 이제는 foundation과 유급 maintainer가 첫날부터 참여하므로, 신뢰할 수 있는 포크가 수 주 안에 나온다.

Valkey와 OpenTofu: 같은 패턴, 더 빠른 전환

Redis Ltd는 20 March 2024에 Redis의 라이선스를 3-clause BSD에서 RSALv2 또는 SSPLv1 중 하나를 선택하는 방식으로 변경했다. 8일 뒤 Linux Foundation은 Redis 7.2.4에서 포크했으며 BSD 3-clause를 유지하는 Valkey를 발표했다. Valkey 7.2.5는 16 April 2024에 동일한 프로토콜과 동일한 데이터 파일을 지원하며 출시되었으므로, 대부분의 운영자에게 마이그레이션은 패키지 이름을 바꾸는 작업이었다. 이후 Redis는 May 2025에 Redis 8에서 AGPLv3를 세 번째 선택지로 추가했다. 이에 따라 OSI의 정의로는 다시 오픈 소스가 되었지만, Valkey는 계속 자체 거버넌스 아래 운영되고 있다. 전체적인 양상은 Elasticsearch와 매우 유사하다.

Terraform도 같은 경로를 거쳤지만, 한 장이 더 추가되었다. OpenTofu는 Mozilla Public License 2.0으로 배포된 마지막 릴리스에서 포크했으며, September 2023에 Linux Foundation에 합류하고 10 January 2024에 1.6.0을 출시했다. 3 April 2024에 HashiCorp의 변호사들은 BUSL 라이선스가 적용된 Terraform 릴리스의 코드가 포크에 복사되었다고 주장하며 프로젝트에 cease and desist 서한을 보냈다. OpenTofu는 11 April 2024에 이를 부인하는 상세한 답변을 게시했으며, 문제가 된 코드가 두 프로젝트가 공유하는 MPL 라이선스 적용 이력에서 유래했다고 추적했다. 이후 공개적으로 추가된 내용은 없었다. 이 사건에서 기억해야 할 실제 위험은 따로 있다. 혐의 제기만으로도 한 분기 동안 도입이 중단될 수 있다는 점이다. 이는 30년 전 Berkeley 소송이 일으킨 효과와 같다.

모든 포크가 라이선스에서 시작되는 것은 아니다. Forgejo는 2022년에 Gitea에서 포크했다. Gitea의 개발이 한 회사 아래로 이동한 뒤였으며, 이는 라이선스 문제가 아니라 거버넌스 분쟁이었다. Forgejo는 version 8 시리즈까지 MIT를 유지했다. 이후 2024년 version 9.0부터 GPLv3 또는 이후 버전으로 재라이선스했다. 따라서 해당 작업이 상업적으로 통제되는 제품에 다시 편입될 수 없었다. self-hosted Git 서버 옵션을 검토하고 있다면, 이 조합은 하나의 코드베이스와 두 가지 철학을 보여 주는 가장 분명한 현재 사례다.

무엇이든 도입하기 전에 실행할 테스트

첫 번째 설치 후가 아니라 설치 전에 네 가지 질문을 확인한다.

1. 저작권자는 누구인가? 재라이선스하려면 모든 저작권자의 허가가 필요하므로, 독립적인 기여자가 수백 명이고 권리 양도가 이루어지지 않은 프로젝트는 현실적으로 재라이선스하기 어렵다. 한 회사가 모든 권리를 소유한 프로젝트라면 이사회 의결만으로 재라이선스할 수 있다.
2. CLA가 있으며, 어떤 권리를 부여하는가? 회사가 원하는 어떤 조건으로든 기여분을 재라이선스할 수 있도록 허용하는 Contributor License Agreement는 위에서 설명한 모든 재라이선스의 정확한 근거가 되는 메커니즘이다. Linux kernel이 2004년에 채택한 서명 문구인 DCO(Developer Certificate of Origin)는 어떠한 권리도 이전하지 않는다. 재단이 보유한 CLA가 회사가 보유한 CLA보다 안전하다. 회사는 매각될 수 있기 때문이다.
3. 상표권자는 누구인가? Elastic이 Elasticsearch라는 이름을 유지했으므로 fork는 이름을 바꿔야 했고, Kibana를 언급한 모든 runbook도 다시 작성해야 했다.
4. 특히 자신에게 재라이선스 비용이 얼마나 발생하는가? 데이터 형식, 클라이언트 라이브러리, 다시 작성해야 할 설정, 호환 가능한 fork가 이미 존재하는지를 확인한다.

다음 두 명령으로 이 중 일부를 몇 초 안에 확인할 수 있다.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

모든 Debian 및 Ubuntu 패키지에는 /usr/share/doc/<package>/copyright 경로의 파일이 포함되어 있다. 이 파일에는 프로젝트가 현재 사용하는 라이선스가 아니라 설치한 버전의 라이선스가 기록되어 있다. Ubuntu 24.04의 bash에서는 이 파일에 GNU General Public License version 3이 명시되어 있다. 두 번째 명령을 source checkout 안에서 실행하면 라이선스 파일 자체의 변경 이력을 확인할 수 있다. 최근 2년 안에 해당 파일을 변경한 commit이 있다면 프로젝트를 기반으로 무엇인가를 구축하기 전에 읽어볼 가치가 있다. 명령이 아무것도 출력하지 않으면 저장소에서 라이선스 파일을 다른 이름으로 관리하는 것이므로 root directory의 목록을 확인한다.

어떤 라이선스도 모든 결과로부터 사용자를 보호하지 않으며, 이념만으로 선택하면 예상하지 못한 상황에 놓이기 쉽다. 저작권이 여러 사람에게 분산되어 있거나 재단이 보유한 프로젝트를 우선 선택하고, export할 수 있는 형식으로 데이터를 보관한다. 그런 다음 어떤 fork로 이동할지 알아보고, 필요해지기 전에 그 이름을 적어 둔다. 각 후보에 이 점검을 적용하는 데는 1시간도 걸리지 않는다. 2026년에 무엇을 self host할지 결정할 때 이 과정이 upgrade와 migration을 가르는 기준이 된다.

FAQ

MIT 라이선스는 BSD 라이선스와 같은가?

실질적으로 MIT 라이선스는 2-clause BSD 라이선스와 같다. 저작권 고지와 보증 부인 조항을 유지하면 된다. 그 외에는 폐쇄형 제품을 만드는 것을 포함해 자유롭게 사용할 수 있다. 3-clause BSD 라이선스는 한 가지 조건을 추가한다. 허가 없이 기여자의 이름을 제품 홍보에 사용할 수 없다는 조건이다. 이전의 4-clause 버전은 광고 자료에 감사 문구를 넣도록 요구했다. UC Berkeley는 1999년 7월 22일 이 조항을 철회했다. 따라서 현재 이 조항을 포함하는 라이선스는 거의 없다.

Apache 2.0 코드를 GPLv2 프로젝트에 넣을 수 있는가?

아니요. Apache 2.0에는 GPLv2가 추가하는 것을 허용하지 않는 조건이 있다. 대표적인 예가 특허 종료 조항이다. 따라서 결합된 저작물은 두 라이선스를 동시에 충족할 수 없다. FSF와 ASF도 모두 이 결론을 발표했다. 반대 방향은 가능하다. Apache 2.0 코드는 GPLv3 프로젝트에 포함할 수 있으며, 결과물은 GPLv3가 된다. Linux kernel에 Apache 2.0 코드를 병합할 수 없는 이유도 이와 같다. Linux kernel은 GPL version 2만 적용되기 때문이다.

SSPL은 오픈 소스 라이선스인가?

아니요. 이 답변은 실제 운영에 영향을 준다. OSI는 SSPL을 승인한 적이 없다. MongoDB도 2019년 3월에 승인 신청을 철회했다. Debian은 2018년 12월에 SSPL 소프트웨어를 아카이브에 포함하지 않겠다고 밝혔다. Fedora는 2019년 1월에 이 라이선스가 자유 라이선스가 아니라고 결정했다. 그 후 Red Hat은 Fedora와 Red Hat Enterprise Linux에서 MongoDB를 제외했다. 따라서 배포판이 이전에 유지 관리하던 패키지가 이제 공급업체 저장소에서 제공될 수 있다. 업데이트 일정도 공급업체의 지원 일정에 따르게 된다. Business Source License도 오픈 소스가 아니라 소스 공개 라이선스다. 다만 각 릴리스는 4년 이내에 오픈 소스 라이선스로 전환된다.

이미 실행 중인 버전에도 라이선스 변경이 적용되는가?

아니요. 릴리스와 함께 부여된 라이선스는 이미 공개된 복사본에 대해 철회할 수 없다. 포크가 가능한 이유가 바로 이것이다. OpenSearch는 Elasticsearch 7.10.2를 기반으로 만들어졌다. Elasticsearch 7.10.2는 Elastic이 Apache 2.0으로 공개한 마지막 릴리스다. 잃게 되는 것은 미래의 권리다. 다음 보안 수정 버전부터 새 조건이 적용되기 때문이다. 마지막으로 허용적인 라이선스가 적용된 버전을 고정하면 몇 달 동안은 사용할 수 있다. 그러나 이것은 장기적인 계획이 아니다.