오픈 소스 소프트웨어의 역사와 라이선스 변천사

오픈 소스 소프트웨어의 정의와 기원

오픈 소스 소프트웨어의 역사는 곧 라이선스의 역사입니다. 타인이 작성한 코드를 어떻게 사용할 수 있는지 결정하는 유일한 기준이 라이선스이기 때문입니다. 라이선스가 명문화되기 훨씬 이전부터 코드는 자유롭게 공유되었습니다. 하지만 코드가 상품화되면서 공유는 중단되었고, 법정에서 공유의 정당성을 입증하기 위해 라이선스가 작성되었습니다.

이것이 짧은 요약입니다. 긴 역사를 이해하는 것이 중요한 이유는 오늘날 서버에서 실행하는 소프트웨어에 당시의 결정들이 여전히 반영되어 있기 때문입니다. 그중 일부 결정은 1983년에 내려졌습니다. 또 다른 결정은 작년에 내려졌으며, 이로 인해 현재 저희의 셀프 호스팅 가이드에 포함된 일부 애플리케이션이 서로 다른 이름의 두 가지 버전으로 제공되는 것입니다.

소프트웨어는 판매되기 이전에 공유되었습니다

1950년대와 1960년대에는 소프트웨어가 기기와 함께 제공되었습니다. IBM은 시스템과 함께 소스 코드를 배포했으며, 1955년에 설립된 SHARE와 같은 사용자 그룹은 테이프에 담긴 프로그램을 서로 공유했습니다. 이 관행은 두 가지 사건으로 종식되었습니다. 1969년 IBM은 소프트웨어를 하드웨어와 분리하여 가격을 책정하겠다고 발표했으며, 이는 소프트웨어 단독 시장을 형성하는 계기가 되었습니다. 이후 법적 규제가 뒤따랐습니다. 1980년에 제정된 컴퓨터 소프트웨어 저작권법(Computer Software Copyright Act of 1980)은 미국 내에서 프로그램이 저작권 보호 대상임을 확립했습니다. 1980년 이후부터는 직접 작성하지 않은 코드는 기본적으로 비공개 상태가 되었으며, 따라서 이를 공유하려면 저작권자의 서면 허가가 필요하게 되었습니다.

Homebrew Computer Club과 취미 활동가를 위한 공개 서한

Homebrew Computer Club은 1975년 3월 캘리포니아주 멘로파크의 한 차고에서 첫 모임을 열었습니다. 회원들은 하드웨어와 종이 테이프를 가져왔으며, 복제는 모임의 일부였습니다. Bill Gates와 Paul Allen이 작성한 Altair BASIC은 복사된 테이프 형태로 방 안을 돌았습니다. 1976년 2월, Gates는 클럽 뉴스레터에 "취미 활동가를 위한 공개 서한(An Open Letter to Hobbyists)"을 기고하며 이에 대응했습니다.

대다수의 취미 활동가들이 알고 있듯이, 여러분 대부분은 소프트웨어를 훔치고 있습니다.

그는 Altair 소유자 10명 중 1명 미만이 BASIC 비용을 지불했으며, 이를 작성하는 데 사용된 컴퓨터 시간의 가치가 40,000달러가 넘는다고 적었습니다. 현대의 모든 논쟁은 이미 그 서한 안에 들어 있습니다. 소프트웨어 복제는 비용이 들지 않으며 복제하는 모든 사람에게 도움이 됩니다. 하지만 소프트웨어를 작성하는 데는 여전히 누군가의 1년이라는 삶이 소요됩니다. 아래에 설명된 모든 라이선스는 이 두 가지 사실을 동시에 해결하려는 시도입니다.

1983년의 GNU와 법적 발명품으로서의 GPL

Richard Stallman은 웹이 등장하기 전 사람들이 사용하던 뉴스그룹 네트워크인 Usenet을 통해 1983년 9월 GNU를 발표했습니다. GNU는 "GNU's Not Unix"의 약자입니다. 이 계획의 목표는 누구나 복제하고 수정할 수 있는 완전한 Unix 호환 시스템을 만드는 것이었습니다.

자유 Unix! 이번 추수감사절부터 저는 GNU(Gnu's Not Unix의 약자)라는 완전한 Unix 호환 소프트웨어 시스템을 작성하여, 이를 사용할 수 있는 모든 사람에게 무료로 배포할 것입니다.

Free Software Foundation(FSF)은 1985년에 설립되었습니다. FSF의 자유 소프트웨어 정의는 0번부터 시작하는 네 가지 자유를 명시합니다. 프로그램을 어떤 목적으로든 실행할 자유, 프로그램을 연구하고 수정할 자유, 복제본을 재배포할 자유, 그리고 수정된 버전을 배포할 자유입니다. 1번 자유는 소스 코드를 요구하는데, 이는 바이너리 형태로는 실질적인 연구가 불가능하기 때문입니다. 여기서 "자유(Free)"는 가격이 없다는 뜻이 아니라 자유를 의미합니다. FSF는 이를 "공짜 맥주(free beer)가 아닌 언론의 자유(free speech)와 같은 자유"라고 표현합니다.

선언문이 발명의 핵심은 아니었습니다. 라이선스가 핵심이었습니다. GNU General Public License(GPL)는 저작권을 공유를 방해하는 용도가 아닌, 공유를 강제하는 용도로 사용합니다. 사용자는 한 가지 조건 하에 네 가지 자유를 얻습니다. 소프트웨어를 전달받는 모든 사람에게도 소스 코드와 함께 동일한 자유가 보장되어야 한다는 조건입니다. Stallman은 이를 카피레프트(copyleft)라고 불렀습니다. 이 라이선스는 1985년 GNU Emacs와 함께 처음 배포되었고, 1989년 GPL 버전 1, 1991년 6월 버전 2가 되었습니다.

GPL이 작동하는 이유는 저작권법을 거스르는 것이 아니라 저작권법에 기반을 두고 있기 때문입니다. 라이선스가 없다면 타인의 코드를 배포할 권리는 전혀 없습니다. GPL은 그 권리를 부여하는 대신 조건을 부착합니다. 따라서 라우터 내부에 수정된 GPL 코드를 탑재하여 배포하면서 소스 코드 제공을 거부하는 공급업체는 단순히 약속을 어기는 것이 아닙니다. 이는 저작권 침해에 해당하며, 저작권자는 이를 법정으로 가져갈 수 있습니다. 이것이 바로 2000년대 Harald Welte의 gpl-violations.org 사례부터 2021년 제기된 Software Freedom Conservancy의 Vizio 소송에 이르기까지 법적 집행이 가능한 이유입니다. 해당 소송은 TV를 구매한 사람도 소스 코드를 요구할 권리가 있다고 주장합니다.

Linux가 시스템을 완성하다

1991년 당시 GNU 프로젝트는 컴파일러, C 라이브러리, 셸 및 대부분의 도구를 갖추고 있었습니다. 하지만 GNU의 자체 커널인 Hurd의 개발이 계획보다 훨씬 지연되면서 작동하는 커널이 없었습니다. 1991년 8월, 헬싱키의 한 학생이 comp.os.minix 뉴스그룹에 다음과 같은 글을 올렸습니다.

저는 386(486) AT 호환 기종을 위한 (무료) 운영체제를 만들고 있습니다(취미일 뿐이며, GNU처럼 크고 전문적이지는 않을 것입니다).

Linux 0.01은 1991년 9월, Linus Torvalds가 직접 작성한 라이선스 하에 등장했으며, 이 라이선스는 판매를 금지했습니다. 그는 1992년 초 이를 GPLv2로 교체했으며, 이후 이를 자신의 가장 잘한 결정 중 하나로 꼽았습니다. 이 라이선스 덕분에 기업의 기여가 안전해졌습니다. 기업은 경쟁사가 해당 개선 사항을 독점할 수 없다는 사실을 알고 안심하고 엔지니어를 커널 개발에 투입할 수 있게 되었습니다.

버클리에는 이미 자유 Unix가 존재했습니다. Linux가 BSD(Berkeley Software Distribution)가 아닌 기본 자유 Unix가 된 이유는 부분적으로 소송 때문입니다. Unix System Laboratories는 1992년 Berkeley Software Design을 고소했고, 이 소송은 1994년 초까지 이어졌습니다. 그 2년 동안 BSD 시스템은 법적 위험을 안고 있었지만 Linux는 그렇지 않았고, 바로 그때 사용자들이 유입되었습니다. FSF는 Linux가 커널이고 주변 도구 대부분이 GNU이므로 결합된 시스템을 GNU/Linux라고 부를 것을 요청합니다. 대부분의 사람들은 Linux라고 부릅니다. 두 이름 모두 동일한 소프트웨어 집합을 가리킵니다.

1998년: 오픈 소스라는 명칭의 등장과 치유되지 않은 분열

1998년 1월, Netscape는 자사 브라우저의 소스 코드를 공개하겠다고 발표했습니다. 이는 당시까지 이러한 결정을 내린 기업 중 가장 규모가 컸으며, 이로 인해 실무적인 문제가 드러났습니다. 영어권에서 "free software"라는 표현은 "비용이 들지 않는 소프트웨어"로 읽혔고, 기업 경영진들은 이를 문자 그대로 받아들였습니다. 1998년 2월, 팰로앨토에 모인 한 그룹은 더 나은 용어를 찾고자 했고, Christine Peterson이 "open source"라는 명칭을 제안했습니다. 몇 주 지나지 않아 Eric Raymond와 Bruce Perens는 Open Source Initiative(OSI)를 설립했습니다. 이 단체는 1997년 Perens가 작성한 Debian Free Software Guidelines를 바탕으로 Open Source Definition을 채택했습니다.

Open Source Definition에는 10가지 기준이 있습니다. 이 중 두 가지가 현대의 논쟁 대부분을 결정짓습니다. 소스 코드는 반드시 공개되어야 하며, 라이선스는 프로그램의 사용 주체나 사용 목적을 제한해서는 안 된다는 것입니다. "상업적 서비스로 제공할 수 없다"는 조항이 포함된 라이선스는 다른 어떤 허용 사항이 있더라도 이 기준을 통과하지 못합니다. 이 문장을 기억하십시오. 이것이 오늘날의 source-available 라이선스가 넘지 못하는 경계선입니다.

1998년에 시작된 분열은 어떤 라이선스가 허용 가능한지에 대한 문제가 아니라, 그 이유에 관한 것입니다. FSF의 입장은 윤리적입니다. 프로그램을 수정할 수 없는 사용자는 자신의 컴퓨터를 통제할 수 없다는 논리입니다. 반면 Raymond의 에세이 "The Cathedral and the Bazaar"를 통해 기업들에 설파된 OSI의 입장은 실용적입니다. 개방형 개발 방식이 더 나은 소프트웨어를 생산하며, 기업은 이를 활용할 수 있다는 것입니다. 이에 대한 Stallman의 반박문인 "Why Open Source Misses the Point of Free Software"는 여전히 gnu.org에 게시되어 있으며, 그는 새로운 용어를 결코 받아들이지 않았습니다. 이 용어의 창설을 도왔던 Perens는 1999년 OSI 이사회에서 사임하며, 해당 운동이 자유 소프트웨어의 본질에서 멀어졌다고 비판했습니다.

실무적인 차이가 얼마나 작은지 정확히 이해할 필요가 있습니다. FSF의 자유 라이선스 목록과 OSI의 승인된 라이선스 목록은 GPL, MIT, Apache 2.0, BSD를 포함하여 거의 모든 부분에서 일치합니다. 두 가지 의미를 모두 포괄해야 하는 필자들은 FOSS(free and open source software) 또는 FLOSS(free/libre and open source software)라는 용어를 사용합니다.

기업이 코드를 배포하는 방식

1999년 Red Hat의 주식 시장 상장은 소프트웨어 복사본 판매보다 기술 지원과 패키징에 수익 모델이 있음을 증명했습니다. IBM은 2001년 Linux에 10억 달러를 투자했습니다. 2001년 Microsoft의 최고 경영자는 Linux를 "암"이라고 지칭했으나, 같은 회사가 2016년 Linux Foundation에 플래티넘 회원으로 가입했고 2018년에는 GitHub를 75억 달러 규모의 주식으로 인수했습니다. IBM은 2019년 Red Hat을 340억 달러에 인수했습니다. 이는 라이선스에 대한 철학이 바뀌어서가 아닙니다. 수익이 발생하는 지점이 달라졌기 때문입니다. 운영 체제가 공유 비용이 되면 자체 운영 체제를 유지 관리하는 비용이 커지며, 모든 공급업체는 그 상위 계층에서 경쟁하기를 원합니다.

기업의 소유권은 반대 방향으로도 작용합니다. 2010년 Oracle이 Sun을 인수했을 때 MySQL과 OpenOffice.org를 함께 인수했고, 두 커뮤니티 모두 떠났습니다. MySQL에서 MariaDB가 파생되었고, 2010년 9월에는 OpenOffice.org에서 LibreOffice가 포크(fork)되었습니다. 포크는 사용자 커뮤니티가 행사할 수 있는 유일한 투표권이며, 라이선스는 그 투표를 가능하게 만드는 근거입니다.

현재 직접 호스팅하는 일부 애플리케이션에 포크(fork)가 존재하는 이유

2018년부터 일부 기업들이 이미 배포한 소프트웨어의 라이선스 조건을 변경했습니다. 상황은 매번 동일했습니다. 한 기업이 거의 모든 개발자를 고용하고, 훨씬 규모가 큰 클라우드 제공업체가 동일한 소프트웨어를 관리형 서비스로 판매하자, 소규모 기업이 라이선스 때문에 경쟁할 수 없다고 판단한 것입니다.

• MongoDB는 2018년 10월 SSPL(Server Side Public License)을 채택했습니다. SSPL은 해당 소프트웨어를 서비스로 제공할 경우, 그 서비스를 제공하는 데 사용된 모든 소스 코드를 공개해야 한다고 명시합니다. OSI는 이를 오픈 소스로 인정하지 않았고, MongoDB는 2019년 심사에서 이를 철회했습니다.
• Redis는 2018년과 2019년에 일부 모듈에 사용 제한을 추가했으며, 2024년 3월 버전 7.4부터 메인 서버를 이중 소스 제공(source-available) 조건으로 전환했습니다. 마지막 BSD 라이선스 릴리스의 포크인 Valkey가 며칠 뒤 등장했으며, 이는 Amazon, Google, Oracle 등이 지원하는 Linux Foundation 산하 프로젝트가 되었습니다. 2025년 5월, Redis는 Redis 8을 위한 세 번째 옵션으로 OSI 승인을 받은 AGPLv3(Affero General Public License version 3)를 추가했습니다.
• Elastic은 2021년 1월 Elasticsearch와 Kibana를 Apache 2.0에서 SSPL 및 Elastic License 이중 라이선스 체제로 전환했습니다. Amazon은 OpenSearch를 포크했습니다. Elastic은 2024년 8월 AGPLv3를 세 번째 옵션으로 추가했으며, OpenSearch는 2024년 9월 Linux Foundation 산하의 OpenSearch Software Foundation으로 이관되었습니다.
• HashiCorp는 2023년 8월 Terraform 및 기타 도구를 BUSL(Business Source License)로 전환했습니다. BUSL은 경쟁적인 프로덕션 환경에서의 사용을 금지하므로, 효력이 유지되는 동안에는 오픈 소스 라이선스가 아닙니다. 각 릴리스는 정해진 날짜(Terraform의 경우 4년 후)가 지나면 오픈 라이선스로 전환됩니다. OpenTofu는 몇 주 만에 포크되었으며 현재는 마찬가지로 Linux Foundation 산하에 있습니다.

이 문제의 양측 모두 타당한 근거가 있으며, 어느 쪽도 악의적으로 행동하는 것은 아닙니다. 50명의 급여를 지급하는 기업이 훨씬 큰 기업이 자사의 결과물을 재판매하는 상황을 겪는다면, 이는 선의만으로는 해결할 수 없는 문제입니다. Apache 2.0 조건 하에 서비스를 구축했다가 갑자기 새로운 조건에 직면한 사용자 역시 문제가 있으며, 그 누구도 사용자에게 먼저 동의를 구하지 않았습니다. 이 중 두 사례에서 이후 어떤 일이 벌어졌는지 주목하십시오. 포크가 자리를 잡은 후, Elastic과 Redis 모두 강력한 카피레프트(copyleft)를 다시 도입했습니다. AGPLv3는 서비스 제공자가 운영하는 변경 사항을 공개하도록 요구하므로, 카피레프트가 원래의 불만을 해결한 셈입니다. 2026년 8월 기준으로 두 프로젝트와 두 포크 모두 활발히 운영되고 있으며, 이는 라이선스가 의도한 결과이기도 합니다.

라이선스를 변경할 권한은 누구에게 있는가

프로젝트의 라이선스를 변경하려면 한 주체가 전체 코드의 저작권을 통제해야 합니다. 기업은 두 가지 방법 중 하나로 이러한 통제권을 확보합니다. 저작권 양도(Copyright assignment)는 각 기여물의 소유권을 기업에 넘기는 방식입니다. 기여자 라이선스 계약(CLA)은 기여자 본인이 소유권을 유지하되, 기업이 해당 기여물을 재라이선스할 수 있을 만큼 충분히 광범위한 권리를 부여하는 방식입니다. 두 경우 모두 보통 첫 번째 pull request 시 봇이 게시하는 링크를 클릭하여 서명하게 됩니다.

Linux에는 CLA가 없습니다. 기여물은 Developer Certificate of Origin과 함께 GPLv2 조건으로 제공되며, 저작권은 수천 명의 개인과 기업에 분산되어 있습니다. 그 모든 서명을 수집하는 것은 불가능하므로, 누구도 Linux의 라이선스를 변경할 수 없습니다. 다수의 독립적인 저작권 보유자가 존재하는 모든 프로젝트에는 동일한 보호 장치가 적용되며, 이는 단순한 약속보다 강력합니다. 왜냐하면 누가 무엇을 소유하고 있는지에 대한 사실 관계에 기반하기 때문입니다.

따라서 의존하려는 소프트웨어에 대해 던져야 할 질문은 현재 오픈 소스인지 여부가 아닙니다. 누가 라이선스를 변경할 수 있는지, 그리고 그들이 단독으로 변경할 수 있는지 확인해야 합니다.

재단이 실제로 제공하는 것

재단은 자산을 보유하고 의사결정 방식에 대한 규칙을 정합니다. Apache Software Foundation, Linux Foundation, 그 산하의 Cloud Native Computing Foundation, 그리고 Software Freedom Conservancy는 각자 이러한 역할을 수행합니다. 재단이 마법처럼 중립적인 것은 아닙니다. 회원들은 의석에 대한 비용을 지불하며, 대규모 재단 프로젝트에서 상근으로 일하는 대부분의 사람들은 회원 기업으로부터 급여를 받습니다. 여기서 얻는 것은 범위가 좁지만 여전히 가치가 큽니다. 상표권과 릴리스 프로세스가 특정 벤더의 소유가 아니므로, 단일 기업이 프로젝트를 사유화할 수 없습니다.

상표권은 사람들이 간과하는 부분입니다. 코드는 라이선스가 적용됩니다. 이름은 상표이며, 상표는 코드 라이선스로 보호되지 않습니다. 코드는 언제든 포크할 수 있습니다. 하지만 보통 이름을 그대로 사용할 수는 없습니다. 이 이야기 속의 포크들이 Valkey, OpenSearch, OpenTofu, Forgejo라고 불리는 이유가 바로 여기에 있습니다.

메인테이너 문제

현대 인프라는 한두 명의 무급 메인테이너가 관리하는 프로젝트에 의존하고 있으며, 이러한 구조적 결함은 장애가 발생할 때 드러납니다. 2014년 OpenSSL에서 발견된 Heartbleed 버그는 웹 암호화 트래픽의 상당 부분을 처리하는 라이브러리를 강타했는데, 당시 이 라이브러리는 거의 자금 지원 없이 소수의 인원이 유지보수하고 있었습니다. 2021년 12월에 발생한 Log4Shell 사태는 전 세계의 대응 자원을 Apache Log4j 프로젝트의 작은 자원봉사 팀으로 집중시켰습니다.

2024년 3월에 발견된 XZ Utils 백도어는 가장 극명한 사례입니다. 공격자가 코드가 아닌 메인테이너를 직접 겨냥했기 때문입니다. 한 계정이 약 2년 동안 Linux 배포판 전반에서 사용되는 압축 라이브러리에 실질적으로 유용한 기여를 했습니다. 다른 계정들은 지칠 대로 지친 유일한 메인테이너에게 도움을 받아들이라고 압박했습니다. 새로 합류한 공동 메인테이너는 SSH(secure shell) 데몬이 liblzma와 링크되는 시스템을 노리고 릴리스 아카이브에 백도어를 심었습니다. 한 개발자가 로그인 시간이 예상보다 0.5초 정도 더 걸리는 이유를 조사하다가 이를 발견했습니다. 이는 순전히 운이었으며, 관련된 모든 이들이 공개적으로 이를 인정했습니다.

자금 지원이 시작되었습니다. 2019년부터 시작된 GitHub Sponsors, Open Collective, 2022년부터 운영 중인 독일의 Sovereign Tech Fund, 그리고 OpenSSF의 Alpha-Omega 프로젝트가 그 예입니다. 하지만 자금 지원은 불균형하며, 이미 유명한 프로젝트에 집중되는 경향이 있습니다. 규제 또한 도입되고 있습니다. 유럽연합(EU)의 Cyber Resilience Act가 2024년 12월 발효되었으며, 대부분의 의무 사항은 2027년 12월부터 적용됩니다. 초기 초안은 무급 자원봉사자에게 제조사로서의 책임을 지우려 했으나, 재단과 배포판 운영자들의 오랜 로비 끝에 최종 문안에서는 "오픈 소스 소프트웨어 스튜어드(open source software steward)"라는 더 가벼운 범주가 신설되었습니다.

오픈 소스의 역사가 VPS의 소프트웨어에 갖는 의미

당사의 셀프 호스팅 가이드에 포함된 모든 애플리케이션은 이러한 결정의 하위 단계에 위치합니다. Nextcloud는 포크(fork)로 인해 탄생했습니다. 2016년 ownCloud의 창립자와 팀원 다수가 프로젝트를 떠나 AGPLv3 라이선스로 프로젝트를 재시작했으며, 이후 두 제품은 병렬로 운영되어 왔습니다. 이러한 역사는 고려할 가치가 있는 Nextcloud 대안과 이 두 서비스와 경쟁하는 셀프 호스팅 Dropbox 대안의 배경이 됩니다.

동일한 패턴이 Git 호스팅 서비스에서도 나타납니다. Gitea는 2016년 Gogs의 포크로 시작되었습니다. 2022년 말 프로젝트의 상표권과 도메인이 한 기업으로 이전되자, 같은 해 12월 Codeberg는 Forgejo를 포크했습니다. 이후 Forgejo는 2024년 버전 9부터 MIT 라이선스에서 GPLv3로 전환되었습니다. 두 프로젝트 모두 셀프 호스팅 Git 서버 옵션에서 다루고 있으며, 라이선스 차이는 이들이 계속해서 분화되는 주된 이유 중 하나입니다. 한편, 대부분의 자유 소프트웨어는 Microsoft가 소유한 폐쇄형 플랫폼인 GitHub에서 개발됩니다. 이는 양측 모두 타당한 근거를 가진 오래된 논쟁거리입니다. GitHub의 실체를 참조하십시오.

서버에 프로젝트를 도입하기 전, 10분 정도 투자하여 다음 네 가지 사항을 확인하는 것이 좋습니다.

• 마케팅 페이지가 아닌 저장소의 LICENSE 파일을 읽어 보십시오. 페이지에는 "오픈 소스"라고 명시되어 있어도 실제 파일의 내용은 그렇지 않은 경우가 많습니다.
• CLA(기여자 라이선스 합의)나 저작권 양도 조항이 있는지 확인하십시오. 이러한 조항이 있다면 단일 소유자가 향후 릴리스의 라이선스 조건을 변경할 수 있습니다.
• 저작권 보유자가 단일 기업인지, 다수의 기여자인지, 혹은 재단인지 확인하십시오.
• 활발하게 활동하는 메인테이너의 수를 확인하십시오. 메인테이너가 한 명뿐인 프로젝트는 사용자뿐만 아니라 해당 개인에게도 위험 요소가 됩니다.

이러한 내용이 단일 벤더 소프트웨어를 피하라는 의미는 아닙니다. 많은 단일 벤더 소프트웨어는 매우 훌륭하며, 비용을 지불하는 구조 덕분에 지속적으로 유지보수되는 경우가 많습니다. 다만, 사용자가 어떤 위험에 노출되어 있는지 파악하라는 의미입니다. 셀프 호스팅할 가치가 있는 것을 결정할 때, 라이선스를 메모리 요구 사항과 함께 비교 항목에 포함하십시오.

이 역사의 일부는 현재 사용 중인 시스템에서도 확인할 수 있습니다. Debian이나 Ubuntu 시스템의 모든 패키지는 고유한 라이선스 조건을 포함하고 있습니다.

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

첫 번째 숫자는 저작권 파일을 포함한 설치된 패키지의 개수이며, 소규모 VPS에서는 보통 수백 개 정도입니다. 두 번째 명령어는 bash 패키지의 저작권 파일 상단을 출력하며, 여기에는 GNU General Public License 버전 3가 명시되어 있습니다. 파일이 누락되었다면 해당 패키지가 Debian 정책에 따라 빌드되지 않았음을 의미합니다. 이는 드문 경우이므로 신뢰하기 전에 다시 한번 검토해야 합니다.

FAQ

자유 소프트웨어와 오픈 소스의 차이점은 무엇입니까?

두 용어는 거의 동일한 라이선스 범위를 다루지만, 해당 라이선스가 왜 중요한지에 대한 관점이 다릅니다. "자유 소프트웨어(Free software)"는 1985년 Free Software Foundation에서 제안한 더 오래된 용어로, 사용자가 프로그램을 변경할 수 없다면 컴퓨터를 통제할 수 없다는 윤리적 논거를 제시합니다. "오픈 소스(Open source)"는 1998년 2월 기업들에게 동일한 라이선스를 더 쉽게 설명하기 위해 만들어졌으며, 실용적인 측면을 강조합니다. GPL, MIT, BSD, Apache 2.0 라이선스는 모두 양쪽의 공식 목록에 포함되어 있습니다. 두 개념을 모두 아우르기 위해 FOSS 또는 FLOSS라는 용어를 사용하기도 합니다.

소스 공개(Source-available) 소프트웨어는 오픈 소스와 같습니까?

아닙니다. 소스 공개는 코드를 읽을 수 있다는 의미일 뿐입니다. 오픈 소스는 Open Source Definition에 따라, 소프트웨어 사용 주체나 사용 목적을 라이선스로 제한할 수 없어야 합니다. SSPL과 Business Source License는 경쟁적인 상업적 이용을 제한하므로, 소스를 공개하더라도 해당 정의에 따르면 오픈 소스가 아닙니다. 개인적인 용도로만 직접 호스팅한다면 이러한 제한이 문제가 되지 않을 수 있습니다. 하지만 이를 기반으로 제품을 개발하려 한다면 먼저 라이선스 문구를 면밀히 확인해야 합니다.

기업이 이미 부여한 오픈 소스 라이선스를 철회할 수 있습니까?

이미 배포된 코드에 대해서는 불가능합니다. 해당 버전은 배포 당시의 라이선스를 그대로 유지하며, 이것이 바로 Valkey나 OpenTofu와 같은 포크(fork) 프로젝트가 마지막으로 허용적인 라이선스가 적용된 커밋에서 시작될 수 있었던 이유입니다. 기업이 할 수 있는 것은 향후 출시될 버전에 새로운 조건을 적용하는 것이며, 이는 저작권 양도나 기여자 라이선스 계약(CLA)을 통해 프로젝트 전체의 저작권을 통제할 때만 가능합니다. Linux와 같이 다수의 독립적인 저작권자가 참여하는 프로젝트는 누구도 임의로 라이선스를 변경할 수 없습니다.

자체 호스팅 소프트웨어에서는 어떤 라이선스를 확인해야 합니까?

직접 실행하고 재판매하지 않는 소프트웨어라면 GPL, AGPL, MIT, Apache 2.0 등 OSI가 승인한 모든 라이선스가 필요한 권한을 제공합니다. 더 중요한 확인 사항은 저작권자가 누구인지입니다. 이는 향후 라이선스 조건이 변경될 수 있는지 여부를 결정하기 때문입니다. 재단이나 다수의 독립적인 기여자가 소유한 프로젝트는 사용자의 의사에 반하여 라이선스를 변경할 수 없습니다. 반면 기여자 라이선스 계약이 있는 단일 벤더 프로젝트는 변경이 가능합니다. 두 경우 모두 훌륭한 소프트웨어일 수 있지만, 규칙을 독단적으로 바꿀 수 있는 것은 후자뿐입니다.