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

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

GPL, MIT, Apache 2.0은 소프트웨어를 배포할 때 타인에게 무엇을 제공해야 하는가라는 동일한 질문에 대해 서로 다른 방식으로 답합니다. MIT는 저작권 고지만을 요구합니다. Apache 2.0은 저작권 고지에 더해 코드 기여자 모두와의 특허 합의를 요구합니다. GPL은 귀하가 구축한 결과물의 소스 코드를 귀하가 받은 것과 동일한 라이선스로 공개할 것을 요구합니다.

이는 법률가의 영역처럼 보이지만, 운영 중인 프로젝트의 라이선스가 변경되어 프로젝트가 둘로 나뉘는 날에는 운영상의 문제가 됩니다. 이때는 두 패키지 저장소 중 하나를 선택해야 하며, 서로 통신이 불가능해진 클라이언트 라이브러리 문제를 해결해야 합니다. 이 가이드는 라이선스를 탄생시킨 운동이 아니라 라이선스 자체와 그 작동 방식에 관한 것이므로, 모든 섹션은 업그레이드를 수행해야 하는 운영자의 관점에서 마무리됩니다.

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개의 조항이 있었는데, 세 번째 조항인 광고 조항은 소프트웨어의 기능을 언급하는 모든 광고 자료에 대학에 대한 감사를 표기하도록 요구했습니다. 이는 확장성이 없습니다. 스톨만(Stallman)은 1997년 버전의 NetBSD에서 75개의 개별적인 감사 표기를 확인했습니다. UC 버클리는 기술 라이선스 사무소(Office of Technology Licensing)의 윌리엄 호스킨스(William Hoskins)가 보낸 서한을 통해 1999년 7월 22일 해당 조항을 철회했습니다.

남은 것은 3조항 BSD 라이선스인데, 이는 기여자의 이름을 사용하여 제품을 보증하는 것을 금지하는 원본의 조항을 유지합니다. 2조항 버전은 그마저도 삭제한 형태입니다. MIT 라이선스 문구는 1980년대 MIT에서 X Window System을 다루면서 나왔으며, 실제로는 2조항 BSD와 동일한 역할을 합니다.

동기는 서로 달랐습니다. 공적 자금으로 운영되는 대학은 기업을 포함한 모든 곳에서 자신들의 연구 결과가 사용되기를 원했습니다. GNU 프로젝트는 폐쇄될 수 없는 공유 자산을 원했습니다. 두 입장 모두 정직하며, 각각 실패 모드가 존재합니다. 허용적 라이선스 코드는 비공개로 전환될 수 있으며, 이 경우 아무것도 돌려받지 못합니다. 카피레프트 코드는 법무팀이 해당 조건을 수용하지 않는 기업들에 의해 거부됩니다.

버클리로부터 얻을 수 있는 두 번째 교훈이 있으며, 이는 이 글이 계속해서 강조하는 내용이기도 합니다. AT&T의 Unix 시스템 연구소(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년에 발표되었습니다. 이 라이선스는 카피레프트가 아니며 오픈 소스도 아닙니다. 소스 코드는 공개되어 있고 비운영 환경에서의 사용은 무료입니다. 운영 환경에서의 사용은 벤더의 Additional Use Grant가 허용하는 범위 내에서만 가능하며, 이 허가 조항은 일반적으로 경쟁적인 호스팅 서비스 운영을 금지합니다. 모든 릴리스는 해당 릴리스 이후 최대 4년이 지나면 변경 날짜에 맞춰 자동으로 실제 오픈 소스 라이선스로 전환됩니다. 전환되는 라이선스는 반드시 GPL 버전 2.0 이상이거나 이와 호환되는 라이선스여야 합니다. HashiCorp는 2023년 8월 10일 Terraform 및 기타 제품을 BUSL 1.1로 전환했습니다. Outline 또한 이 라이선스를 사용하고 있으며, 셀프 호스팅 가능한 Notion 대안을 선택할 때 이 점을 고려해야 합니다. 즉, 팀 내부용으로 운영하는 것은 허용되지만, 이를 기반으로 서비스를 구축하는 것은 허용되지 않습니다.

두 라이선스 모두 부정직한 것은 아닙니다. 두 라이선스 모두 소스 코드를 열람할 수 있는(source available) 라이선스임을 분명히 밝히고 있습니다. OSI 정의에 따르면 둘 다 오픈 소스가 아니며, 이로 인한 차이는 원래 겨냥했던 클라우드 제공업체가 아닌 사용자에게 돌아오게 됩니다.

OpenSearch: 라이선스 포크가 운영자에게 미치는 비용

Elastic은 2021년 1월 14일, 7.11 릴리스부터 Elasticsearch와 Kibana의 라이선스를 Apache 2.0에서 SSPL 또는 Elastic License로 변경한다고 발표했습니다. 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일에 정식 출시되었습니다.

이 결정이 클러스터 운영자에게 어떤 비용을 초래했는지 확인해야 합니다. 패키지 이름과 저장소가 변경되었습니다. 런북의 모든 Kibana 참조는 OpenSearch Dashboards로 바뀌었습니다. 플러그인 이름도 이동했습니다. 이후 분기는 애플리케이션 코드까지 영향을 미쳤습니다. Elastic의 공식 클라이언트 라이브러리 7.13 버전부터는 클라이언트가 연결된 대상을 확인하여 Elasticsearch가 아닌 경우 알 수 없는 제품이라는 오류를 반환하며 연결을 거부합니다. 본인이 근무하지 않는 회사의 라이선스 결정이 자신의 애플리케이션 내부에서 호출 실패로 나타난 것입니다.

이후 상황은 두 번 더 반전되었습니다. Elastic은 2024년 8월 29일, 세 번째 라이선스 옵션으로 AGPLv3를 추가한다고 발표했습니다. 라이선스 FAQ에 따르면 이 추가는 2024년 9월에 이루어졌으므로 현재 Elasticsearch는 다시 OSI 승인을 받은 오픈 소스가 되었습니다. 2024년 9월 16일, AWS는 OpenSearch를 Linux Foundation이 호스팅하는 OpenSearch Software Foundation으로 이전했습니다. 이를 통해 포크는 특정 기업에 종속되지 않는 거버넌스 기반을 갖추게 되었습니다. 분기 5년 후 두 프로젝트 모두 오픈 소스가 되었고 유지 관리되고 있으며, OpenSearch는 2026년 10월 기준으로 3.x 시리즈를 이어가고 있습니다.

결말이 곧 교훈입니다. 라이선스는 돌아왔지만 포크는 남았습니다. 생태계에 모든 것의 두 가지 버전이 존재하게 되면, 서류상의 문제를 해결한다고 해서 다시 하나로 합쳐지지는 않습니다.

라이선스 변경이 얼마나 큰 피해를 주는지 결정하는 수치는 발표 시점과 실제로 배포 가능한 안정적인 포크가 나오기까지의 간격입니다.

[
  {
    "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
  }
]

각 간격은 공급업체의 공개 발표부터 포크의 첫 안정 릴리스까지의 기간을 아래 나열된 날짜를 기준으로 계산합니다. OpenSearch 1.0은 179일이 소요되었습니다. 포크의 이름을 변경하고 처음부터 다시 빌드해야 했으며, 참고할 이전 포크가 없었기 때문입니다. OpenTofu는 153일이 소요되었습니다. Valkey는 Redis 7.2.4를 포크하면서 프로토콜과 디스크 내 형식을 동일하게 유지했기에 27일이 소요되었습니다. 중요한 점은 방향성입니다. 이제 신뢰할 수 있는 포크는 몇 주 안에 등장하며, 첫날부터 재단과 유급 관리자가 함께합니다.

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으로 공개한 마지막 릴리스다. 잃게 되는 것은 미래의 권리다. 다음 보안 수정 버전부터 새 조건이 적용되기 때문이다. 마지막으로 허용적인 라이선스가 적용된 버전을 고정하면 몇 달 동안은 사용할 수 있다. 그러나 이것은 장기적인 계획이 아니다.