당신의 사이드 프로젝트가 방금 500개의 스타를 넘겼고, 낯선 사람이 첫 진지한 풀 리퀘스트를 열었습니다: 당신이 몇 달째 피해온 문제를 해결하는 2,000줄의 코드입니다. 당신은 병합 버튼을 누르고 싶습니다. 하지만 그 전에 불편한 질문을 던져야 합니다: 당신은 정말로 그 코드를 배포할 법적 권리가 있는가 — 그리고 그 기여자가 어디에서 일하든 관계없이, 영원히, 당신의 라이선스로 계속 배포할 권리가 있는가?
당신의 저장소에 기여 정책이 없다면, 솔직한 답은 확신할 수 없다는 것입니다. 기여자는 자신이 작성한 모든 줄의 저작권을 여전히 소유하고 있으며, 프로젝트의 라이선스만으로는 누가 누구에게 무엇을 허여했는지 항상 정리되지 않습니다. 그 불확실성은 그것이 중요해지는 날까지 보이지 않게 남아 있습니다: 재라이선싱, 인수, 라이선스 실사를 수행하는 기업 사용자, 또는 기여자의 고용주가 그 작업이 처음부터 자신들의 것이었다고 주장하는 경우.
이 문제를 해결하는 두 가지 메커니즘이 있으며, 거의 모든 오픈 소스 프로젝트가 그중 하나를 선택합니다: 기여자 라이선스 동의서(CLA)와 개발자 원산지 증명서(DCO)입니다. 둘 다 기여자가 기여할 수 있는 권한이 있고 프로젝트가 그것을 배포할 권리가 있다는 것을 확립하기 위해 존재합니다. 그러나 무게, 마찰, 그리고 나중에 할 수 있는 일에서 엄청나게 다릅니다. 이 가이드는 각각이 어떻게 작동하는지, 언제 어느 것을 선택해야 하는지, 그리고 오후 한나절 만에 당신의 선택을 설정하는 방법을 설명합니다.
프로젝트에 기여 정책이 필요한 이유
저작권은 자동으로 부여됩니다. 누군가 코드를 작성하는 순간, 그들은 그것을 소유합니다 — 등록도, 저작권 표시도 필요하지 않습니다. 그들이 그것을 당신의 프로젝트에 제출할 때, 당신의 오픈 소스 라이선스는 많은 것을 커버하지만, 기여 정책만이 채울 수 있는 빈틈을 남깁니다:
- 인바운드 허여. 당신의 아웃바운드 라이선스(MIT, Apache-2.0, GPL)는 사용자가 당신의 코드로 무엇을 할 수 있는지 알려줍니다. 기여 정책은 들어오는 기여가 호환되는 조건으로 도착한다는 것을 명시하여, 파일별 출처를 일일이 추적하지 않고도 결합된 작업을 배포할 수 있게 합니다.
- 고용주의 주장. 대부분의 고용 계약은 부업 프로젝트 IP를 고용주에게 양도합니다, 적어도 직원의 업무와 관련된 작업에 대해서는요. 기여자에게 제출할 권리가 있음을 확인하도록 요구하는 정책은 그 책임과 서면 기록을 기여자에게 부과합니다.
- 재라이선싱 선택권. 만약 언젠가 라이선스를 변경하거나, 상업용 에디션을 추가하거나, 프로젝트를 재단에 기부하고 싶다면, 모든 기여자로부터 권리를 얻어야 합니다. 수십 명의 과거 기여자로부터 소급하여 그 허가를 모으는 것은 고통스러운 것과 불가능한 것 사이 어딘가입니다. 첫날 선택한 정책이 그 문이 열려 있을지를 결정합니다.
- 특허 보호. 코드 기여는 특허 권리를 동반할 수 있습니다. 일부 정책은 명시적인 특허 허여를 포함하고, 다른 것들은 그렇지 않은데, 이는 대부분의 메인테이너가 인식하는 것보다 더 중요합니다.
이 중 어느 것도 상시 고용된 법률 사무소를 필요로 하지 않습니다. CLA 또는 DCO를 선택하고, 저장소에 그것을 기록하고, 자동으로 시행하는 것이 필요합니다. 각 선택이 무엇을 수반하는지 살펴보겠습니다.
기여자 라이선스 동의서(CLA)란 무엇인가?
기여자 라이선스 동의서는 기여자와 프로젝트(또는 그 뒤에 있는 회사나 재단) 사이의 서명된 법적 문서입니다. 기여자는 한 번 서명하고, 그 서명은 그들의 모든 미래 기여를 커버합니다.
오픈 소스 라이선스와 달리, CLA는 표준화되어 있지 않습니다. 각 프로젝트가 자체적으로 작성하지만, 대부분은 두 가지 익숙한 형태에 속합니다:
개인 vs. 기업 CLA
- 개인 CLA (ICLA): 자신을 대신하여 기여하는 개인이 서명합니다. 일반적으로 프로젝트에 광범위한 저작권 라이선스와 종종 특허 라이선스를 허여하며, 기여자는 자신의 저작권을 유지합니다.
- 기업 CLA (CCLA): 회사가 서명하여 직원들이 기여할 수 있도록 승인합니다. 회사는 직원들이 제출한 작업에 대해 동일한 권리를 허여합니다. CCLA 없이 기업 기여를 받아들이는 프로젝트는 모든 직원의 관리자가 알고 있고 승인한다고 신뢰하는 것인데, 이는 실사 중에 증발하는 바로 그런 종류의 신뢰입니다.
라이선스 허여 vs. 저작권 양도
대부분의 현대 CLA는 라이선스 허여입니다: 기여자는 소유권을 유지하고 프로젝트에 영구적이고, 전 세계적이며, 로열티 없는 라이선스를 부여합니다 — 종종 재라이선싱을 허용할 만큼 충분히 광범위한 라이선스입니다. 아파치 소프트웨어 재단의 ICLA가 대표적인 예입니다.
소수의 프로젝트는 저작권 양도를 사용하는데, 여기서 기여자는 소유권을 완전히 이전합니다(자유 소프트웨어 재단의 접근 방식). 양도는 프로젝트에 시행하고 재라이선싱할 최대한의 자유를 주지만, 기여자에게 가장 많은 것을 요구하며 커뮤니티 주도 프로젝트에서 인기를 잃었습니다.
CLA가 당신과 기여자에게 드는 비용
트레이드오프는 마찰입니다. 처음 기여하는 사람은 풀 리퀘스트를 떠나, 법적 문서를 읽고, 서명하고(보통 전자적으로), 메인테이너가 코드를 검토하기 전에 상태 확인이 녹색으로 바뀌기를 기다려야 합니다. 도구가 이것을 거의 고통 없게 만들었습니다 — CLA Assistant 같은 봇이 풀 리퀘스트에 서명 링크와 함께 댓글을 달고 서명을 자동으로 기록합니다 — 그러나 그것은 여전히 "당신의 버그를 고쳤습니다"와 "당신이 내 수정을 병합할 수 있습니다" 사이의 관문입니다. 일부 지나가는 기여자는 여기서 이탈합니다.
그 대가로, 프로젝트는 서명되고 감사 가능한 기록을 얻습니다: 이 사람이, 이 날짜에, 이러한 권리를 허여했다는 것. 기업 후원 프로젝트, 이중 라이선스 프로젝트, 그리고 언젠가 인수될 수 있는 모든 것에게 그 서면 기록은 실제 돈의 가치가 있습니다.
개발자 원산지 증명서(DCO)란 무엇인가?
개발자 원산지 증명서는 2004년 리눅스 재단이 리눅스 커널을 위해 도입했으며, 정확히 CLA의 무게를 피하기 위해서였습니다. 그것은 기여자가 서명하고 보관하는 계약이 아닙니다. 그것은 기여자가 커밋 메시지에 Signed-off-by 줄을 추가함으로써 모든 커밋마다 확인하는 짧은 증명입니다 — 다섯 문단, 버전 1.1:
Fix off-by-one error in retry backoff calculation
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
Signed-off-by: Alex Rivera <[email protected]>그 줄을 추가하는 것은 하나의 플래그입니다: git commit -s가 구성된 Git 신원을 사용하여 자동으로 그것을 덧붙입니다. 서명함으로써, 기여자는 다음을 증명합니다:
- 그들이 기여를 (전부 또는 일부) 만들었고 프로젝트의 오픈 소스 라이선스에 따라 제출할 권리가 있다, 또는
- 그들의 기여가 이 제출을 허용하는 적절한 오픈 소스 라이선스 하에 이미 있는 이전 작업에 기반한다, 또는
- 그들이 위 중 하나를 증명한 다른 사람으로부터 기여를 받았고 그것을 수정하지 않았다, 그리고
- 그들이 기여와 그 기록 — 서명을 포함하여 — 이 공개되고 무기한 보관된다는 것을 이해한다.
그것이 전체 메커니즘입니다. 별도의 문서도, 계정 연결도, 프로젝트별 온보딩도 없습니다. 시행은 상태 확인입니다: DCO 앱 또는 동등한 확인이 풀 리퀘스트의 모든 커밋이 유효한 서명을 가지고 있는지 검증하고, 메인테이너는 녹색일 때만 병합합니다.
DCO의 의도적인 한계
DCO가 하지 않는 것을 주목하세요. 그것은 프로젝트의 아웃바운드 라이선스가 이미 전달하는 것 이상의 라이선스를 허여하지 않습니다 — 그것은 기여가 프로젝트의 라이선스 조건으로 도착하는 것에 의존합니다. 그것은 특허 허여를 포함하지 않습니다. 그리고 기여자별로 서명되고 보관되는 것이 없기 때문에, 누가 무엇에 동의했는지에 대한 중앙 레지스트리가 없습니다; git 이력 자체가 기록입니다.
옹호자들은 이것을 장점으로 봅니다: DCO의 낮은 장벽이 핵심입니다. 리눅스 커널, GitLab(2017년 CLA에서 전환), 그리고 Chef(2016년 전환)는 모두 커밋별 증명이 모든 기여자에게 부담을 주지 않고 필요한 출처를 제공한다고 결론지었습니다. OpenStack의 기술 위원회는 2025년 모든 기여에 대해 CLA를 DCO로 대체하기로 결의했습니다. 업계 추세는 명백합니다 — 그러나 추세는 당신의 프로젝트에 대한 평결이 아닙니다, 다음 섹션에서 설명하듯이.
CLA vs. DCO 나란히 비교
| 차원 | CLA | DCO |
|---|---|---|
| 법적 메커니즘 | 기여자당 한 번 서명되고 보관되는 동의서 | 커밋 메시지의 커밋별 증명 |
| 기여자가 하는 일 | 문서에 서명(보통 봇 링크를 통해) | git commit -s로 Signed-off-by 추가 |
| 저작권 처리 | 프로젝트에 명시적 라이선스 허여(또는 양도) | 기여가 프로젝트 라이선스 하에 도착; 별도 허여 없음 |
| 특허 허여 | 보통 포함됨 | 없음 |
| 재라이선싱 자유 | 광범위한 허여가 종종 허용 | 추가 권리 없음; 재라이선싱은 모든 기여자의 동의 필요 |
| 기여자 마찰 | 높음: 읽고, 서명하고, 확인 대기 | 최소: Git 플래그 하나 |
| 시행 도구 | CLA Assistant, EasyCLA, 사용자 정의 봇 | DCO 앱, 커밋 메시지 확인 |
| 동의 기록 | 서명 데이터베이스 | git 이력 자체 |
| 고용주 커버리지 | 기업 CLA가 직원을 명시적으로 커버 | 기여자가 제출할 권리가 있음을 자기 증명 |
| 최적 적합 | 기업 후원, 이중 라이선스, 또는 인수 관련 프로젝트 | 기여 마찰이 가장 중요한 커뮤니티 프로젝트 |
CLA가 올바른 선택인 경우
DCO가 포착하지 못하는 권리에 프로젝트의 미래가 달려 있을 수 있을 때 CLA를 선택하세요:
- 이중 라이선스 또는 재라이선싱을 계획하고 있다. 상업용 에디션, 라이선스 변경, 또는 카피레프트에서 허용적 라이선싱으로의 이동이 조금이라도 그럴듯하다면, 광범위한 라이선스-백이 있는 CLA가 그 옵션을 열어두는 유일한 가벼운 방법입니다. 몇 년 후 동의를 재구성하는 것은 악몽 같은 시나리오입니다.
- 회사가 프로젝트를 뒷받침하고 있다. 기업 후원자, 인수자, 그리고 IP 실사를 수행하는 엔터프라이즈 고객은 고고학이 아닌 서명 레지스트리를 원합니다. Google, 아파치 프로젝트, 그리고 Canonical은 정확히 이 이유로 CLA를 사용합니다.
- 당신의 분야에서 특허가 중요하다. 코덱, 무선 프로토콜, ML 모델 아키텍처 — 특허가 많은 분야에서, CLA의 명시적 특허 허여는 DCO가 조용히 건너뛰는 실제 작업을 하고 있습니다.
- 재단이 그것을 요구한다. 일부 재단은 호스팅이나 졸업의 조건으로 그들의 CLA를 의무화합니다. DCO로 충분하다고 가정하기 전에 확인하세요.
이 경로를 간다면, CLA 자체를 표준적이고 지루하게 유지하세요: 처음부터 작성하기보다 아파치 ICLA 또는 Harmony 템플릿에서 시작하고, 개인 및 기업 버전 모두를 게시하고, 첫날 서명 봇을 연결하여 마찰이 PDF 왕복이 아닌 한 번의 클릭이 되도록 하세요.
DCO가 이기는 경우
기여가 생명줄이고 마찰이 적일 때 DCO를 선택하세요:
- 많은 캐주얼 기여자가 있는 커뮤니티 프로젝트. 문서 수정, 오타 교정, 작은 버그 패치 — 서명 관문에서 이탈할 가능성이 가장 높은 기여는 또한 DCO가 우아하게 처리하는 것들입니다.
- 허용적 라이선스, 재라이선싱 계획 없음. 프로젝트가 영원히 MIT 또는 Apache-2.0으로 남고 로드맵에 상업용 에디션이 없다면, CLA의 추가 권리는 당신에게 거의 이득이 없습니다.
- 솔로 메인테이너와 소규모 팀. DCO는 서명 인프라도, 동의서를 보관할 법적 실체도, 기업 양식에 연서할 프로세스도 필요하지 않습니다. 그것은
CONTRIBUTING.md파일과 상태 확인으로 운영할 수 있는 거버넌스입니다. - 최대 호환성 자세. 일부 기여자 — 특히 엄격한 IP 정책을 가진 대기업에 고용된 사람들 — 는 DCO에는 서명할 수 있지만 법적 검토 없이 외부 CLA에 서명할 수 없습니다. DCO는 그 문을 열어둡니다.
어느 것을 선택하든, 결정을 기록하세요. 정책을 명시하고, 정확한 서명 또는 서명 흐름을 보여주고, 전체 텍스트를 링크하는 CONTRIBUTING.md는 가장 흔한 혼란의 원인을 제거합니다: 기여자가 실패한 상태 확인으로부터 요구 사항을 추측하는 것.
어느 선택이든 약화시키는 5가지 실수
1. 둘 다 말하기. 가장 흔한 실제 실패는 한 문단에서 DCO 서명을 요구하고 다른 문단에서 CLA 서명을 요구하는 CONTRIBUTING.md입니다 — 보통 반쯤 완료된 마이그레이션 후에요. 기여자는 한 지시를 따르고, 다른 확인은 실패하고, 메인테이너는 어쨌든 병합하는데, 이는 둘 다의 요점을 무효화합니다. 하나의 메커니즘을 선택하고, 시행하고, 다른 것의 모든 흔적을 삭제하세요.
2. 자동화된 시행 없음. 산문으로만 명시된 정책은 제안입니다. 풀 리퀘스트 워크플로에 필수 상태 확인으로 확인을 연결하세요 — 서명의 경우 DCO 앱, 서명의 경우 CLA Assistant 또는 EasyCLA — 그래서 동의되지 않은 기여가 실수나 메인테이너 피로로 병합될 수 없도록 하세요.
3. 기업 기여자 무시. 회사가 당신의 프로젝트를 사용하고 패치한다면, 직원들은 근무 시간에 코드를 제출할 것입니다. CLA 정책 하에서, 그것은 관계가 따뜻할 때 일찍 CCLA에 서명을 받는 것을 의미합니다. DCO 정책 하에서, 그것은 서명 요구 사항이 누구의 첫 기여도 IP 사건이 되지 않을 만큼 충분히 눈에 띄도록 하는 것을 의미합니다.
4. 고용 계약이 기여를 허용한다고 가정하기. 같은 동전의 반대면: 다른 프로젝트에 기여한다면, 먼저 자신의 고용 계약을 확인하세요. 많은 것들이 업무 관련 부업 프로젝트 IP를 기본적으로 고용주에게 양도합니다. DCO의 증명("나는 이것을 제출할 권리가 있다")은 그 서류가 그렇게 말할 때만 참입니다.
5. AI 지원 코드에 대한 정책 없음. 기계 생성 기여는 2004년 시대의 DCO 텍스트나 대부분의 CLA 템플릿이 예상하지 못한 출처 질문을 제기합니다. 당신의 입장을 결정하세요 — 검토와 함께 허용, 공개, 또는 금지 — 그리고 첫 AI 생성 풀 리퀘스트가 도착한 후가 아니라 전에 CONTRIBUTING.md에 CLA/DCO 정책과 함께 명시하세요.
프로젝트의 돈 쪽도 잊지 마세요
여기 메인테이너들이 세금 시즌까지 미루는 부분이 있습니다: 프로젝트가 첫 달러를 버는 순간 — GitHub Sponsors 지급금, Open Collective 기부금, README 때문에 들어온 컨설팅 계약 — 그것은 재정을 가지고, 재정은 장부가 필요합니다.
기여 출처를 감사 가능하게 만드는 것과 같은 규율이 프로젝트 자금을 관리 가능하게 만듭니다. 후원 수입을 급여와 별도로 추적하여 과세 대상 자영업 소득이 무엇인지 알 수 있도록 하세요. 프로젝트 비용 — 도메인 갱신, CI 분, 변호사가 당신의 CLA를 검토한 오후 — 을 자체 계정에 기록하여 공제가 개인 카드 명세서로 증발하지 않도록 하세요. 프로젝트가 LLC로 성장하거나 재정 호스트에 합류한다면, 깨끗한 과거 기록이 전환을 법의학적이 아닌 지루하게 만듭니다.
플레인 텍스트 회계는 이 워크플로에 유난히 잘 맞습니다: 당신의 장부는 코드 옆 버전 관리에 살고, 모든 항목은 이력을 가지고, 아무것도 독점 형식에 숨지 않습니다. 우리의 문서는 첫 장부를 몇 분 만에 실행하는 방법을 안내합니다.
프로젝트의 장부를 Git 이력만큼 깨끗하게 유지하세요
CLA와 DCO 중 하나를 선택하는 것은 오후 한나절이 걸립니다; 몇 년 후 출처나 프로젝트 재정을 풀어내는 것은 몇 주가 걸립니다. 지금 기여 결정을 내리고, 그 시행을 자동화하고, 프로젝트의 돈에 커밋에 기울이는 것과 같은 관심을 기울이세요. Beancount.io는 당신의 재정 데이터에 완전한 투명성과 통제를 제공하는 플레인 텍스트 회계를 제공합니다 — 블랙 박스도, 벤더 종속도 없습니다. 무료로 시작하세요 그리고 개발자와 재무 전문가들이 왜 플레인 텍스트 회계로 전환하는지 확인하세요.
