📚 지식 노트

오픈 소스의 정의: 자유 소프트웨어, 오픈 소스, 소스 공개

세 말은 비슷하게 들리지만 가리키는 것이 다르다. 자유 소프트웨어는 FSF가 정한 네 가지 자유(어떤 목적으로든 실행, 연구하고 고치기, 복사본 재배포, 고친 판 배포)를 주는 소프트웨어다. FSF는 ‘자유’가 가격이 아니라 권리의 문제라고 강조한다(What is Free Software?). 오픈 소스는 OSI의 오픈 소스 정의(OSD) 10가지 기준을 만족하는 라이선스로 배포된 소프트웨어다.

• OSD의 요점: 재배포를 막거나 사용료를 받지 않고(1조), 소스를 고칠 수 있는 형태로 주고(2조), 고친 판을 허락하고(3조), 사람·집단이나 사용 분야를 차별하지 않는다(5·6조). 특정 제품에 묶이거나(8조) 함께 배포되는 다른 소프트웨어를 제한해서도(9조) 안 된다.
• 판매도 된다: 1조는 ‘팔지 말라’가 아니라 ‘남이 팔거나 나눠 주는 것을 막지 말라’는 뜻이다. 오픈 소스 소프트웨어를 돈 받고 파는 것도, 지원 계약으로 버는 것도 정의 안이다.
• 소스 공개형(source-available): 소스는 내려받아 읽을 수 있지만 경쟁 서비스 금지처럼 쓰임을 막는 조건이 붙은 라이선스다. SSPL, BUSL, RSALv2가 예이고, 어느 것도 OSI 승인 목록에 없다.

저작권과 라이선스의 관계

코드는 저작물이다. 라이선스 없이 공개된 코드는 기본으로 저작자가 모든 권리를 갖는다. 남이 복제·수정·배포하면 침해가 될 수 있고, GitHub에 공개돼 있거나 포크할 수 있다는 것은 허락이 아니다(Choose a License). 라이선스는 저작자가 ‘이 조건을 지키면 이 권리를 허락한다’고 적은 문서다. 조건을 어기면 허락의 근거가 사라진다.

• 저작권은 기여자마다 있다: 별도 계약이 없으면 기여한 코드의 저작권은 각 기여자에게 남는다. 그래서 오래된 프로젝트의 라이선스를 바꾸려면 기여자의 동의나, 기여 때 받아 둔 권리(뒤의 CLA)가 필요하다.
• 상표와 특허는 따로다: 라이선스는 대개 저작권을 다룬다. 프로젝트 이름과 로고(상표)는 별도 정책으로 관리하고, 특허는 Apache 2.0·GPLv3처럼 명시하는 라이선스와 그렇지 않은 라이선스로 나뉜다.

허용형과 카피레프트

라이선스는 남이 고친 판을 배포할 때 무엇을 요구하느냐로 크게 나뉜다. 허용형(permissive)은 고지만 지키면 고친 판을 비공개 제품에 넣어도 된다. 카피레프트(copyleft)는 고친 판을 배포할 때 같은 라이선스로 소스를 공개하라고 요구한다. 카피레프트는 그 요구가 닿는 범위로 다시 나뉜다.

표의 ‘—’는 그런 조항이 따로 없다는 뜻이다. 특허 조항이 없다고 특허 사용을 막는다는 뜻은 아니지만, 다툼이 생겼을 때 기댈 문장이 없다.

• MIT·BSD: 가장 짧다. 저작권 고지와 라이선스 문구를 복사본에 남기라는 것이 사실상 전부다. 3조항 BSD는 옛 4조항 판의 ‘광고 조항’을 뺀 것이다. 4조항 판은 FSF가 GPL과 맞지 않는다고 본다(FSF 라이선스 목록).
• Apache 2.0: 허용형이지만 두 가지가 더 있다. 기여자가 자기 기여에 필요한 특허를 사용료 없이 허락하고, 그 저작물이 특허를 침해한다며 소송을 거는 사람은 그 허락을 잃는다(3조). 배포할 때는 라이선스 사본을 주고, 바꾼 파일에 바꿨다고 표시하고, 원본에 NOTICE 파일이 있으면 그 고지를 옮겨 실어야 한다(4조, 원문).
• 약한 카피레프트: MPL 2.0은 파일 단위다. MPL 코드가 든 파일을 고치면 그 파일은 MPL로 공개하지만, MPL 코드가 없는 새 파일은 어떤 라이선스든 되고 비공개 제품과 정적으로 묶어도 된다(MPL FAQ). LGPL은 라이브러리 단위로, 그 라이브러리를 쓰는 앱은 자기 조건으로 배포하되 사용자가 라이브러리를 바꿔 끼울 수 있게 해야 한다.
• 강한 카피레프트: GPL은 GPL 코드와 하나로 묶인 프로그램 전체를 배포할 때 전체 소스를 GPL로 내라고 한다. GPLv3는 특허 허락을 조문에 넣었다(11조, GPLv3).
• 네트워크 카피레프트: AGPLv3는 GPLv3에 13조를 더했다. 프로그램을 고쳐 네트워크로 쓰게 하면, 그것을 쓰는 모든 사용자에게 소스를 받을 길을 무료로 알려야 한다(AGPLv3).

어떤 라이선스를 고를까

내 프로젝트에 라이선스를 붙일 때 묻는 질문은 사실상 하나다. 남이 고친 판을 배포할 때 그 소스도 공개되기를 원하는가. 원하지 않으면 허용형, 원하면 카피레프트이고, 나머지 질문은 그 안에서 고르는 것이다.

• 널리 쓰이길 원하면: 허용형이 마찰이 가장 적다. 회사 제품에도 부담 없이 들어간다. 기업 기여자가 많고 특허가 걱정이면 Apache 2.0, 아주 짧은 것을 원하면 MIT가 흔한 선택이다.
• 고친 판이 공개되길 원하면: 라이브러리는 쓰는 쪽 코드를 강제하지 않는 MPL·LGPL, 완성된 프로그램은 GPL, 서버에서 도는 프로그램이 클라우드에서 고쳐진 채 쓰이는 것까지 막고 싶으면 AGPL이다.
• 직접 만들지 않는다: 새로 쓴 라이선스나 ‘상업적 사용 금지’를 덧붙인 변형은 OSD를 벗어나기 쉽고, 다른 라이선스와의 호환을 아무도 모른다. 이미 있는 라이선스를 원문 그대로 쓴다.

의무 체크리스트

남의 오픈 소스를 내 제품에 넣어 배포할 때 실제로 챙겨야 할 일은 몇 가지로 모인다. 갈래마다 어느 항목이 붙는지를 표로 보면, 허용형은 고지 위주이고 카피레프트로 갈수록 소스 제공이 더해진다.

• 고지 모으기: 앱의 ‘오픈 소스 라이선스’ 화면, 설치 폴더의 THIRD_PARTY_NOTICES 같은 곳에 의존성마다 저작권 문구와 라이선스 사본을 모은다. 빌드 때 SBOM에서 자동으로 만들면 빠뜨리지 않는다.
• 소스 제공: 카피레프트 부분의 소스를 바이너리와 함께 주거나, 받을 수 있는 방법을 알린다. 고친 부분이 빠진 소스는 의무를 채우지 못한다.
• 변경 표시: Apache 2.0과 GPL 계열은 바꾼 파일에 바꿨다는 표시를 요구한다. 파일 머리 주석이나 변경 기록으로 남긴다.
• LGPL의 바꿔 끼우기: LGPLv3는 사용자가 고친 라이브러리로 다시 링크할 수 있도록, 사용자 시스템의 공유 라이브러리를 쓰거나 다시 링크할 수 있는 형태의 앱 코드를 함께 주라고 한다(4조, LGPLv3).

링크, 배포, SaaS가 의무를 바꾼다

의무가 생기는 계기는 대부분 복사본을 남에게 건네는 것이다. GPLv3는 이것을 ‘전달’(convey)이라 부르고, 네트워크로 사용자와 주고받기만 하고 복사본을 건네지 않는 것은 전달이 아니라고 적는다. 또 전달하지 않는 한 고치고 실행하는 데에는 조건이 없다고 밝힌다(GPLv3 0·2조). 같은 GPL 코드라도 어떻게 쓰느냐에 따라 의무가 0에서 프로그램 전체 공개까지 달라진다.

• 안에서만 쓰기: 사내 도구, 개인 서버, 빌드 스크립트처럼 밖으로 복사본을 주지 않으면 카피레프트의 소스 공개 의무는 생기지 않는다.
• 수정본 배포: 앱 스토어에 올리는 앱, 고객에게 파는 기기의 펌웨어, 고객에게 설치해 주는 소프트웨어 모두 배포다. 예제에서는 8개 라이선스 중 5개가 소스 공개를 요구한다.
• 링크: Apache 재단은 GPLv3 저자들이 GPL 코드에 링크하기만 해도 파생 저작물이 된다고 본다는 점을 들어, 자기 프로젝트를 GPL 코드에 링크하지 않는다(Apache 재단). LGPL은 바로 이 경우를 풀어 주려고 만든 라이선스다.
• SaaS: 고친 프로그램을 서비스로만 열면 GPL의 의무는 생기지 않는다. 그래서 생긴 것이 AGPL이고, 이 경우 소스 공개가 필요한 것은 1개(AGPL)뿐이다. 클라우드 업체의 서비스 제공을 겨냥한 SSPL 같은 소스 공개형도 이 틈에서 나왔다.

라이선스 호환

두 라이선스의 코드를 하나로 묶어 배포하려면 양쪽 조건을 동시에 지킬 수 있어야 한다. 이것이 호환이다. 허용형끼리는 대개 문제가 없고, 카피레프트가 끼면 방향이 생긴다. 허용형 코드는 GPL 프로젝트에 들어가지만, GPL 코드는 허용형 프로젝트에 들어가면 그 프로젝트를 GPL로 바꾼다.

• Apache 2.0과 GPL: Apache 2.0 코드는 GPLv3 프로젝트에 넣을 수 있지만(표: 가능) 반대로 GPLv3 코드를 Apache 프로젝트에 넣을 수는 없다. GPLv2와는 아예 맞지 않는데(표: 불가), FSF는 Apache 2.0의 특허 종료·면책 조항이 GPLv2에 없는 추가 제한이라는 이유를 든다(Apache 재단, FSF).
• 판 표기가 중요하다: GPL-2.0-only 코드는 GPLv3 코드와 묶을 수 없지만, GPL-2.0-or-later는 ‘이후 판’인 GPLv3로 쓸 수 있다. GPLv2 코드를 가져올 때는 이 한 단어부터 확인한다.
• MPL 2.0의 다리: MPL 2.0은 3.3조의 ‘보조 라이선스’ 조항으로 GPL 계열 작품과 합쳐 GPL로 배포하는 길을 열어 둔다. 단 파일에 ‘Incompatible With Secondary Licenses’ 표시가 있으면 이 길이 닫힌다.
• GPLv3와 AGPLv3: AGPLv3 13조는 GPLv3 작품과 하나로 묶어 배포하는 것을 허락한다. 합친 작품 안에서 AGPL 부분에는 네트워크 조항이 계속 붙고, 나머지는 GPLv3를 따른다.

소스 공개형과 라이선스 변경

2020년대 들어 회사가 이끄는 인기 프로젝트 몇이 오픈 소스 라이선스를 소스 공개형으로 바꿨다. Elastic과 Redis가 밝힌 이유는 비슷했다. 큰 클라우드 업체가 그 소프트웨어를 관리형 서비스로 팔면서 개발 비용은 원 회사가 지는 구조라는 것이다. 바꾼 판부터 새 라이선스가 붙고, 이미 나온 판은 옛 라이선스 그대로 남는다.

• Elasticsearch: 2021-01-14에 7.11부터 Apache 2.0을 SSPL과 Elastic License 중 고르는 이중 라이선스로 바꿨다(Elastic). 이 변경 뒤 아마존이 관리하는 포크가 나왔다. 약 43개월 뒤인 2024-08-29에 기존 둘을 그대로 둔 채 AGPL을 선택지로 더했다(Elastic).
• Terraform: HashiCorp는 2023-08-10에 이후 나오는 제품 판을 MPL 2.0에서 BUSL 1.1로 바꾼다고 알렸고, API·SDK와 대부분의 라이브러리는 MPL 2.0으로 남겼다(HashiCorp). Terraform에서 갈라져 나온 OpenTofu는 Linux Foundation의 관리 아래 있다. IaC 쪽 이야기는 CI/CD와 인프라 코드 노트에 있다.
• Redis: 2024-03-20에 7.4부터 3조항 BSD를 RSALv2와 SSPLv1 이중 라이선스로 바꾸며, 둘 다 OSI 승인 라이선스가 아니라고 스스로 밝혔다(Redis). 2024-03-28에 Linux Foundation이 7.2.4에서 이어 가는 BSD 라이선스의 Valkey를 출범시켰다. Redis는 약 14개월 뒤인 2025-05-01, Redis 8부터 AGPL을 선택지로 더했다(Redis).
• BSL의 시계: BUSL 1.1로 낸 판은 정한 변경일이나 첫 공개 4주년 중 이른 날에 GPL 2.0 이상과 호환되는 변경 라이선스로 바뀐다. 그 전에도 ‘추가 사용 허락’으로 일부 운영 사용을 열어 줄 수 있다(BSL 1.1). 예를 들어 2024-01-15에 처음 낸 판은 변경일을 2030-01-01로 적어도 2028-01-15에 바뀐다.
• 쓰는 쪽의 대비: 핵심 의존성이 회사 하나에 달려 있다면 그 회사가 라이선스를 바꿀 때 어떻게 할지(옛 판 고정, 포크로 옮기기, 상용 계약)를 미리 정해 둔다. 판을 고정하고 업그레이드 전에 라이선스를 다시 확인하는 것이 최소한의 대비다.

기여: CLA와 DCO

외부 기여를 받는 프로젝트는 ‘이 코드를 프로젝트 라이선스로 내도 되는가’를 확인할 방법이 필요하다. 두 가지 방식이 널리 쓰인다.

• CLA(contributor license agreement): Apache 재단은 메인테이너와 큰 기여를 하는 사람에게 개인용 ICLA를 받고, 회사는 직원의 기여를 위해 CCLA를 낼 수 있다. CCLA는 회사를 대표할 권한이 있는 사람이 서명해야 하고, 개인의 ICLA를 대신하지 않는다(ASF). 회사가 이끄는 프로젝트도 흔히 CLA를 요구한다. Redis의 라이선스 변경 FAQ도 기여를 받는 조건으로 CLA 동의를 적는다.
• DCO(Developer Certificate of Origin 1.1): 커밋 메시지 끝의 Signed-off-by: 줄이 네 가지를 확인한다는 뜻이다. 내가 만들었고 낼 권리가 있다, 오픈 소스 라이선스의 기존 작업을 고쳤다, 그런 확인을 거친 것을 그대로 받았다, 기여와 서명이 공개로 영구히 남는다(DCO). git commit -s가 이 줄을 붙이고(git), 리눅스 커널은 익명이 아닌 알려진 신원으로 서명하라고 요구한다(커널 문서).
• 회사 직원의 기여: 업무 중에 쓴 코드의 저작권이 회사에 있는 경우가 많다. 회사 정책이 허락하는지, CCLA가 필요한지 먼저 확인한다.

오픈 소스 거버넌스와 재단

거버넌스는 누가 무엇을 결정하는지, 결정을 어떻게 바꾸는지, 상표와 도메인 같은 자산을 누가 쥐는지의 규칙이다. 라이선스가 코드의 권리를 정한다면, 거버넌스는 프로젝트의 미래를 정한다.

• 재단의 역할: 상표와 자산을 한 회사가 아닌 중립 기관이 맡고, 결정 절차를 문서로 공개한다. Apache 재단에서는 저장소 쓰기 권한을 가진 커미터가 기여를 받아들이고, 이사회가 세운 PMC가 프로젝트의 공동체·법적 준수·릴리스를 맡는다. 새 프로젝트는 인큐베이터에서 공동체를 갖춘 뒤 졸업한다(How the ASF works).
• 포크의 자리: 라이선스가 오픈 소스인 한, 공동체는 마지막 수단으로 포크할 수 있다. OpenTofu와 Valkey가 그 예이고, 둘 다 Linux Foundation 아래로 갔다. 반대로 상표는 포크해도 따라오지 않으므로 새 이름이 필요하다.
• 의존성을 고를 때: 커밋하는 사람이 몇인지, 한 회사가 대부분인지, 재단에 속했는지, 보안 신고 절차가 있는지를 본다. 오래 쓸 의존성일수록 코드 품질만큼 거버넌스가 중요하다.

SBOM과 SPDX 식별자

SBOM(software bill of materials)은 소프트웨어를 이루는 구성 요소의 목록이다. CISA는 이것을 ‘소프트웨어를 이루는 재료의 중첩된 목록’이라고 설명한다(CISA). 보안 쪽에서는 새 취약점이 나왔을 때 어디에 그 판이 들었는지 찾는 데, 라이선스 쪽에서는 무엇을 고지하고 무엇을 검토할지 아는 데 쓴다. 파이프라인에서 SBOM을 만들고 서명하는 법은 CI/CD 노트, 공급망 방어의 원리는 보안 › 시스템·소프트웨어 보안에 있다.

• SPDX 식별자: SPDX License List가 라이선스마다 짧은 이름을 정한다(2026년 9월 판 3.29.0). GPL-2.0-only와 GPL-2.0-or-later처럼 판의 범위까지 이름에 담는다. 소스 공개형도 BUSL-1.1, SSPL-1.0처럼 식별자가 있다. 식별자가 있다고 오픈 소스라는 뜻은 아니다.
• 표현식: OR는 골라서 하나, AND는 모두, WITH는 예외 조항을 붙인다. 괄호가 없으면 AND가 OR보다 먼저 묶인다(SPDX 표현식).
• 파일마다 적기: FSFE의 REUSE는 파일마다 저작권과 라이선스 정보를 기계가 읽을 수 있게 적고, 쓰는 라이선스 사본을 모두 저장소에 두라고 권한다.

// SPDX-License-Identifier: Apache-2.0
// SPDX-FileCopyrightText: 2026 Example Project contributors

회사의 오픈 소스 정책

회사는 오픈 소스를 세 방향으로 만난다. 가져다 쓰기(인바운드), 우리 코드를 공개하기(아웃바운드), 직원이 외부 프로젝트에 기여하기다. 이것을 맡는 조직을 OSPO(Open Source Program Office)라 부르고, Linux Foundation 아래의 TODO Group이 OSPO 실무자들의 경험을 모은다.

• 정책은 표 하나로: 허용·검토·금지를 라이선스 갈래와 쓰는 방식(사내 도구, 배포 제품, 서비스)으로 나눈 표를 두면 개발자가 매번 묻지 않아도 된다. 위 단계 그림의 판정은 이런 예시 표를 따른 것이다.
• 자동으로 확인: CI에서 lockfile과 SBOM을 읽어 새 의존성의 SPDX 식별자를 정책과 대조하고, 금지 판정이면 병합을 막는다. 라이선스가 비어 있거나 알 수 없는 패키지도 금지로 다룬다.
• 공개할 때: 비밀값·내부 주소·고객 정보가 이력에 남아 있지 않은지 확인하고, 라이선스 파일과 기여 방법(CLA나 DCO), 보안 신고 창구를 갖춘 뒤 공개한다.
• 돌려주기: 고친 버그를 내부에만 두면 판을 올릴 때마다 다시 고쳐야 한다. 상류에 기여하는 것이 장기적으로 싸다.

지속 가능성: 메인테이너와 xz 사건

세상의 많은 소프트웨어가 몇 사람이 여가에 관리하는 라이브러리에 기대고 있다. 사용자는 문제가 있을 때만 말을 걸고, 잘 돌아갈 때는 조용하다. GitHub의 안내서는 메인테이너 번아웃의 원인으로 긍정적 피드백 부족, 거절하기 어려움, 고립, 시간과 돈의 부족을 들고, 경계 정하기·위임·후원 받기·자동화를 권한다(Open Source Guides).

• 무슨 일이 있었나: 2024-03-29, 한 개발자가 xz의 상류 저장소와 5.6.0·5.6.1 릴리스 압축 파일에 백도어가 들었다고 보고했다. 압축 파일 속 난독화된 스크립트가 빌드 중에 liblzma를 바꿨고, 여러 배포판이 sshd를 libsystemd와 엮어 둔 탓에 sshd가 그 라이브러리를 불러왔다. SSH 로그인이 0.30초에서 0.81초로 약 2.7배 느려지고 valgrind 오류가 난 것이 실마리였다(oss-security). CISA는 같은 날 5.4.6 같은 오염되지 않은 판으로 내리라고 권했다(CISA).
• 사람의 문제였다: 공개된 타임라인에 따르면 새 기여자는 2021년 10월 첫 패치를 보냈고, 2022년 4월부터 가짜로 보이는 계정들이 진행이 느리다며 메인테이너를 늘리라고 압박했으며, 그 기여자는 2022년 말 메인테이너가 되었다(Russ Cox). 압박의 표적은 사실상 혼자 프로젝트를 맡던 메인테이너였다.
• 쓰는 쪽이 할 일: 핵심 의존성의 메인테이너가 몇 명인지 알고, 후원이나 인력으로 돕는다. 릴리스 압축 파일과 저장소 내용이 다를 수 있음을 알고, 가능하면 저장소의 태그에서 직접 빌드하거나 둘을 비교한다. 판을 고정하고, 갑작스러운 메인테이너 교체나 빌드 스크립트 변경 같은 신호를 업그레이드 검토에 넣는다.

흔한 오해

• ‘오픈 소스는 공짜니 마음대로 써도 된다’: 돈을 내지 않아도 되는 경우가 많을 뿐, 조건이 붙은 허락이다. 고지를 빼거나 카피레프트 코드를 비공개로 배포하면 허락의 근거를 잃는다.
• ‘GitHub에 공개돼 있으니 써도 된다’: 라이선스 파일이 없으면 기본은 모든 권리 보유다. 저장소가 공개라는 것은 허락이 아니다.
• ‘GPL 라이브러리를 하나라도 쓰면 회사 코드 전부를 공개해야 한다’: 의무는 배포(전달)할 때 생기고, 사내에서만 쓰거나 서비스로만 열면 GPL의 소스 공개 의무는 없다. 다만 배포하는 제품에 묶었다면 범위가 프로그램 전체로 넓다.
• ‘SaaS는 라이선스와 상관없다’: AGPL은 네트워크 사용도 계기로 본다. 서버 쪽 의존성의 AGPL 여부는 꼭 확인한다.
• ‘MIT는 의무가 없다’: 저작권 고지와 라이선스 문구를 복사본에 넣어야 한다. 앱의 오픈 소스 고지 화면이 그 의무를 채우는 곳이다.
• ‘소스를 볼 수 있으면 오픈 소스다’: SSPL·BUSL·RSALv2는 소스가 보여도 OSI 승인 라이선스가 아니다. Redis도 라이선스를 바꾸며 OSI 정의의 오픈 소스가 아니게 됐다고 스스로 밝혔다.
• ‘라이선스는 언제든 거둘 수 있다’: 새 판의 라이선스는 바꿀 수 있지만, 이미 그 라이선스로 받은 판에 대한 권리는 남는다. 포크가 가능한 이유다.

핵심 자료