우리는 몇몇 오래된 프로그램을 Python으로 다시 작성했습니다. espeak-ng의 G2P 프론트엔드, Cotovia의 갈리시아어 및 스페인어 전사 규칙, AhoTTS의 바스크어 언어 처리, EYE N3 추론기, OWL 2 DL 추론기 HermiT. C, C++, Java로, 대부분 10년도 더 된 것들이며, 모두 그 일을 하는 데 있어 여전히 최고인 것들입니다.
동기는 평범했습니다. 갈리시아어를 음소화하는 C 프로그램은 훌륭하지만, ARM 보드 위의 Python 음성 스택 안에 넣고 싶어지는 순간 문제가 됩니다. 그러면 컴파일러, 툴체인, 크로스 컴파일, 플랫폼별 패키징 방식, 그리고 텍스트를 마샬링해야 하는 서브프로세스 경계가 필요해집니다. Java 추론기는 JVM이 필요합니다. 순수 Python은 pip install이면 됩니다. 읽기도 쉽습니다: 원래 빌드 시스템이 어떻게 작동하는지 몰라도, 강세가 어디에 놓이는지 결정하는 파일을 열어서 바꿀 수 있습니다.
이식은 반자율적으로 이루어졌습니다. AI가 원본 소스를 읽고 Python을 작성했으며, 사람이 작업을 지휘하고 출력을 원본 바이너리에 대해 확인했습니다. 그중 몇 개는, 우리 쪽 사람 중 누구도 원본 소스를 읽은 적이 없습니다. 모델이 그것을 읽었습니다. 우리는 diff와 동등성 테스트를 읽었습니다.
이는 우리가 결정을 내려야 했지만 답할 수 없었던 질문을 남깁니다: 그 결과물은 파생 저작물인가, 그리고 누가 그것을 소유하는가?
우리는 엔지니어입니다. 여기 어떤 것도 법률 자문이 아니며, 우리는 그것을 제공할 자격이 없습니다. 이는 우리가 내린 결정과 그 뒤에 있는 추론에 대한 서술입니다.
계속 뒤섞이는 두 가지 질문
소스를 읽어 프로그램을 재구현하는 것은 새로운 일이 아닙니다. Python이 존재한 이래로 사람들은 C를 Python으로 다시 작성해 왔습니다. 새로운 것은 그 배치입니다: 읽는 자가 기계이고, 구현하는 자도 같은 기계이며, 루프 안의 사람들은 원본을 본 적이 없습니다.
여기에는 두 개의 질문이 있으며, 이에 대한 거의 모든 논의는 이를 하나로 뭉갭니다. 이 둘은 독립적입니다.
- 그 결과물이 애초에 소유될 수 있는가? 저작권은 저자가 있는 저작물에 붙습니다. 기계가 코드를 만들었다면, 누가 저자인가?
- 그 결과물은 입력의 파생물인가? 누가 저작했든 — 만약 누군가 했다면 — 그 결과가 원본을 침해하는가?
여러분은 이 둘 중 하나에는 그렇다고, 다른 하나에는 아니라고 어느 조합으로든 답할 수 있습니다. 이 둘을 분리해 두십시오.
여기서부터는 어휘가 필요합니다. **파생 저작물(derivative work)**은 기존 저작물에 기반한 저작물입니다 — 번역, 각색, 이식. 파생 저작물을 만들 권리는 원본의 저작권 보유자에게 속합니다. 카피레프트(copyleft) 라이선스(GPL 계열)는 배포하는 것이 같은 조건 아래 유지된다는 조건으로 코드를 사용하고 수정할 수 있게 합니다. 허용적(permissive) 라이선스(MIT, Apache-2.0, BSD)는 결과물을 독점 소프트웨어 안에 실어 배포하는 것을 포함해 사실상 무엇이든 할 수 있게 합니다. LGPL은 그 중간에 있습니다: 카피레프트는 라이브러리 자체에 적용되지만, 그것을 더 큰 프로그램에 링크하는 것이 그 프로그램을 강제로 오픈시키지는 않습니다. 이 모든 것은 저작권 위에 세워져 있습니다. 집행할 저작권이 있을 때만 효력이 있습니다.
질문 하나: 저자가 존재하는가?
저작권에는 인간 저자가 필요합니다. 미국 저작권청은 일관되게 이를 견지해 왔고, Thaler v. Perlmutter 사건에서 D.C. 순회 항소법원도 동의했습니다: 저작권법은 “모든 적격 저작물이 최초에 인간에 의해 저작되어야 한다”고 요구합니다(No. 23-5233, D.C. Cir., 2025년 3월 18일; 연방대법원은 2026년 3월에 상고를 기각했습니다). 유럽의 기준은 형태는 다르지만 비슷한 지점에 도달합니다 — 보호를 받으려면 “저자 자신의 지적 창작물”이어야 하며, 이는 창작하는 저자의 존재를 전제합니다.
이들 중 어느 것도 AI 지원 작업이 보호받을 수 없다고 말하지 않습니다. 둘 다 기계가 스스로 생성한 것은 그렇다고 말합니다. 그 경계선은 저작물을 둘러싼 것이 아니라 저작물을 관통하며, 정확히 어디에 떨어지는지는 사람이 얼마나 기여했는지에 달려 있습니다. 우리의 이식 작업에서 사람의 기여는 실재하지만 얇습니다: 대상을 고르고, 패키지를 구조화하고, 동등성 실패를 판단하는 것. 이것이 우리를 전사 규칙의 저자로 만든다는 것은 명확하지 않습니다.
이는 어색한 대상을 만들어냅니다. 라이선스는 권리 보유자가 부여하는 허가입니다. 결과물에 대해 아무도 권리를 보유하지 않는다면, 저장소 루트에 있는 라이선스 파일은 장식일 뿐입니다. 그 논증이 어디로 향하는지 주목하십시오: 그것은 upstream의 것에 닿기도 전에 자기 자신의 라이선스부터 갉아먹습니다. 기계 생성 코드가 소유되지 않는다고 주장하는 사람은 누구든, upstream의 것 근처에도 가기 전에 자기 자신의 배포 조건이 집행될 수 없다고 주장하는 셈입니다.
질문 둘: 파생물인가?
이 질문은 누가 저자인지에 신경 쓰지 않습니다. 침해 여부는 원본에 대한 접근에 더해 그 보호받는 표현(expression) — 그것이 무엇을 하는지가 아니라 그것이 쓰인 특정한 방식 — 과의 실질적 유사성에 좌우됩니다.
우리에게는 접근이 있었습니다. 모델이 소스를 읽었습니다. 그 절반은 논쟁의 여지가 없습니다.
유사성 절반이 흥미로워지는 지점이며, 언어를 바꾸는 것이 사람들이 기대하는 것보다 덜 중요해지는 지점이기도 합니다. 소설을 다른 언어로 번역하는 것은 파생 저작물을 만들어냅니다. 그것이 교과서적인 예입니다. 언어를 바꾸는 것은 문자 그대로의 복제 주장을 무력화합니다. 그것은 구조에 대한 주장은 무력화하지 못합니다 — 변환의 순서, 함수로의 분해, 규칙 표의 형태, 경계 사례가 나뉘는 방식 같은 것들 말입니다.
도구가 무언가를 세탁해 주지는 않는다는 것도 분명히 말할 가치가 있습니다. 복제물을 지휘하고 그 결과를 배포한다면, 그것을 만든 사람은 여러분입니다. “모델이 그것을 작성했다”는 “컴파일러가 그것을 출력했다”만큼도 방어 논리가 되지 못합니다.
반대편에서 가장 강력한 논증
언어 간 재구현이 괜찮다는 진지한 주장이 있으며, 이는 그저 손을 흔드는 대신 제대로 서술될 가치가 있습니다.
SAS Institute v World Programming 사건(CJEU, C-406/10, 2012년 5월 2일)에서 법원은 “컴퓨터 프로그램의 기능성도, 컴퓨터 프로그램이 그 특정 기능을 활용하기 위해 사용하는 프로그래밍 언어와 데이터 파일 형식도, 그 프로그램의 표현 형태를 구성하지 않는다”고 판시했습니다. 따라서 이들은 저작권으로 보호되지 않습니다. 소프트웨어 지침(2009/24/EC, 제1조 제2항)도 프로그램 요소의 근저에 있는 아이디어와 원리에 대해 같은 말을 합니다. 법원은 또한 라이선시가 프로그램의 동작을 연구하고 관찰하여 그 배후의 아이디어를 파악하고 이를 재구현할 수 있다고 판시했습니다.
이는 사소한 기술적 문제가 아닙니다. 이는 음소화기가 하는 일 — 이 자소 시퀀스가, 이 문맥에서, 저 음소가 된다 — 을 아무도 소유하지 않는다는 것을 의미합니다. 갈리시아어 강세 규칙은 갈리시아어에 대한 사실입니다. OWL 2 직접 의미론은 공개된 W3C 명세입니다. 그 해석에 따르면, 표현이 아니라 동작을 재현하는 재구현은 합법적이며, 언어를 넘나드는 다시 쓰기는 복사-붙여넣기보다 침해로부터 훨씬 멀리 있습니다.
그 논증과 우리 상황 사이의 간극은 소스입니다. SAS는 동작을 연구하는 것에 관한 것입니다. 우리 모델은 코드를 읽었습니다.
이미 존재하는 선례와 그것이 미치는 범위
“기계 출력에는 저자가 없으므로 저작권이 붙지 않는다”는 논증은 사고 실험이 아닙니다. 이는 업계 전반의 프로덕션에서 하중을 지탱하고 있습니다. 모델 증류와 합성 학습 데이터 모두 이에 의존합니다.
이에 대한 가장 명확한 공개 진술은 널리 사용되는 오픈 TTS 모델인 Kokoro-82M입니다. 그 모델 카드는 이것이 오로지 허용적이거나 저작권이 없는 오디오로만 학습되었다고 말하며, 허용 가능한 출처 중에 다음을 나열합니다:
Synthetic audio generated by closed TTS models from large providers
그리고 미국 저작권청의 AI 정책 지침을 가리키는 각주가 달려 있습니다. 그 추론의 사슬은 위와 같습니다: 그 오디오는 기계가 생성했고, 기계 출력에는 인간 저자가 없으므로, 그것에는 저작권이 존재하지 않으며, 따라서 그것으로 학습한다고 해서 침해할 것이 없습니다. 이 모델은 Apache-2.0으로 배포됩니다. 그 카드는 또한 경계도 긋습니다 — 오픈 TTS 모델과 커스텀 음성 클론에서 나온 합성 오디오는 제외합니다 — 이는 저자들이 그 논증이 어디서 멈추는지 파악했으며, 이를 모든 것에 적용하지는 않았다는 신호입니다.
이식에 대해 중요한 부분은 여기입니다. 그 선례는 이 문제의 다른 절반을 해결합니다.
Kokoro의 논증은 입력에 관한 것입니다. 그들이 소비한 것은 그 자체가 기계 생성물이었으므로, 그 주장은 그것이 애초에 저작권을 지니지 않았다는 것입니다. 저작권 없는 것이 들어갔으니, 물려받을 것도 없습니다.
우리의 상황은 그 거울상입니다. 우리가 소비한 것 — espeak-ng의 C, Cotovia의 C++, HermiT의 Java — 은 수십 년 전에 이름이 알려진 사람들이, 이름이 알려진 대학에서, 명백히 인간이 작성했고 저작권이 있는 것입니다. 나온 것은 기계가 작성한 것입니다. “AI 출력에는 저작권이 없다”는 논증은 우리의 출력에는 적용되지만, 우리의 입력에는 적용되지 않습니다. 이는 upstream으로 거슬러 올라가지 않습니다. 이는, 다시 말하지만, upstream의 권리는 전혀 건드리지 않은 채 우리 자신의 라이선스만 무너뜨리는 논증입니다.
주목할 만한 또 다른 비대칭이 있습니다. Kokoro의 남은 노출은 사실상 저작권이 아닙니다 — 그것은 계약입니다. 폐쇄형 제공업체들의 서비스 약관은 대개 그들의 출력을 경쟁 모델 학습에 사용하는 것을 금지하며, 여러분이 동의한 조건은 그 출력이 저작권이 없는 것으로 밝혀졌다고 해서 사라지지 않습니다. 카피레프트는 그런 식으로 작동하지 않습니다. 아무도 GPL에 “동의합니다”를 클릭하지 않습니다. 그것은 일방적인 허가 부여이며, 여러분이 그 허가를 필요로 할 때만 — 즉, 여러분이 만든 것이 파생 저작물일 때만 — 여러분을 구속합니다.
그래서 이 모든 것은 아무도 답하지 않은 그 하나의 질문으로 다시 무너져 내립니다. 언어를 넘나드는, 기계가 작성한 재구현이 파생 저작물이 아니라면, GPL은 애초에 관여하지 않았고 그것에 대한 어떤 것도 적용되지 않았습니다. 만약 그것이 파생 저작물이라면, GPL은 첫 줄부터 적용되었습니다. 세 번째 상태는 없으며, AI 저작권에 대해 아무리 논쟁해도 그 바늘은 움직이지 않습니다.
클린룸, 그리고 두 개의 모델이 하나를 만드는가
바로 이 문제에 대한 고전적인 답은 클린룸 프로토콜이며, 그 형태가 중요하므로 정확히 서술할 가치가 있습니다.
한 팀이 원본을 읽고 기능 명세를 작성합니다: 그 프로그램이 행동적 관점에서 무엇을 하는지. 원본을 본 적이 없는 두 번째 팀은 오직 그 명세만으로 구현합니다. 두 번째 팀의 출력은 그들이 본 적 없는 표현에서 복사된 것이 아님이 입증 가능합니다. 그것이 PC BIOS가 재구현된 방식이며, 그 재구현이 살아남은 이유입니다.
명백한 현대적 방법은 한 모델을 돌려 읽고 서술하게 하고, 신선한 컨텍스트를 가진 다른 모델로 구현하게 하는 것입니다. 구조적으로는 이것이 같은 프로토콜입니다. 이것은 클린룸인가요?
형태는 맞습니다. 하지만 클린룸은 기술적 구성물이 아니라 증거적 구성물입니다. 그 전체 가치는 여러분이 부정행위를 했다고 가정하는 누군가에게 나중에 그 분리를 입증할 수 있다는 데 있습니다. 그래서 이 2-모델 버전은 그 규율이 끝까지 유지될 때만 의미가 있습니다:
- 양쪽이 진정으로 컨텍스트를 절대 공유하지 않습니다. “잊으라고 지시했다”가 아니라 — 별도의 실행, 별도의 기록입니다.
- 명세는 동작만 담고 그 외에는 아무것도 담지 않습니다. 원본의 제어 흐름을 그대로 반영하는 의사코드도 없습니다. 식별자 이름도 없습니다. 함수 순서도 없습니다. 이런 것들은 표현이며, 그런 것으로 가득 찬 명세는 그저 변장한 원본입니다.
- 양쪽의 기록이 모두 보관됩니다. 증거를 댈 수 없는 클린룸은 그저 이야기일 뿐이기 때문입니다.
읽는 쪽이 구조를 방출한다면, 그 오염은 곧바로 통과하고, 여러분은 단계만 더 많고 토큰 비용만 더 큰 파생 저작물을 갖게 됩니다.
우리는 이렇게 하지 않았습니다. 구현하는 모델이 소스를 직접 읽었습니다. 이것이 pycotovia의 README가 저장소 안에, 공개적으로 다음과 같이 말하는 이유입니다:
Because the implementing AI read the GPL source, this is not a clean-room reimplementation and we make no such claim. It is a source-derived port.
우리는 그 문장을 나중에 답해야 하느니 차라리 지금 적어 두는 편을 택하겠습니다.
우리가 한 일
우리는 upstream의 라이선스를 유지했습니다.
espyak는 espeak-ng와 일치하는 GPL-3.0-or-later입니다. 이것은 어려운 사례조차 아닙니다: 이 패키지는 espeak-ng 자체의 데이터 파일 — dictsource, phsource, lang — 을 그대로 번들하며, 변경 없이 복사한 파일에는 어떤 저작권 이론도 손대지 못합니다. upstream의 데이터가 wheel 안에 있으므로, upstream의 라이선스도 함께 옵니다.
pycotovia는 Cotovia(GPL-3.0+)와 일치하는 GPL-3.0입니다. ahotts-g2p와 pyAhoTTS-Iparrahotsa는 AhoTTS와 일치하는 GPL-3.0이며, AhoTTS의 라이선스 파일은 언어 처리 부분에 대해 GPL-3.0+를 명시합니다. pyeye는 EYE와 일치하는 MIT입니다. 카피레프트가 들어가면 카피레프트가 나오고, 허용적인 것이 들어가면 허용적인 것이 나옵니다.
우리가 그렇게 한 것은 그것이 필요하다고 확립했기 때문이 아닙니다. 그 비대칭성이 답을 필요로 하지 않고도 결정을 내려 주었기 때문입니다.
우리는 어차피 오픈소스로 공개합니다. 카피레프트는 우리에게 거의 비용이 들지 않습니다 — 유일한 실질적 비용은 고객이 그 코드를 독점적인 무언가 안에 넣고 싶어 하는 경우인데, 이 특정 라이브러리들에서 그런 경우는 드뭅니다. 그러니 엄밀히 그럴 필요가 없을 때 카피레프트를 취하는 비용은 거의 0입니다.
다른 쪽 오류는 대칭적이지 않습니다. 카피레프트여야 했던 것에 허용적 라이선스를 붙여 배포하는 것은, 다른 사람들이 여러분이 제공할 권리가 없었던 조건 아래 그 위에 무언가를 쌓아 올린 뒤에, 나중에, 공개적으로, 다른 누군가에 의해 발견되는 문제입니다. 그것을 되돌린다는 것은 모든 다운스트림 사용자에게 연락한다는 뜻입니다.
그 비대칭성은 또한 왜 이런 불일치를 일반적으로 경계해야 하는지의 이유이기도 합니다. LGPL 원본의 구조적 이식이 단지 다른 언어로 다시 쓰였다는 이유만으로 Apache-2.0이 될 수는 없습니다 — 그리고 그것이 바로 만들기 쉽고 알아차리기 어려운 종류의 불일치입니다. 아무것도 불평하지 않기 때문입니다. 빌드는 통과합니다. 테스트도 통과합니다. 라이선스 헤더는 그저 파일 하나일 뿐입니다. HermiT는 LGPL이며, 이를 이식한 우리의 Python 포트도 이에 맞춰 LGPL-3.0을 지닙니다. 전체 집합을 다시 검토해 보니 두 가지 불일치를 더 찾았는데, 둘 다 극적이지 않은 것들입니다: upstream이 MIT인데 Apache-2.0을 명시한 래퍼 하나, 그리고 README에는 라이선스 이름이 적혀 있지만 대응하는 파일이 없는 저장소 몇 개. 그것이 평범하고 올바른 결말입니다 — 확인하고, 고쳐야 할 것을 고치고, 흥미로운 질문은 열어 둡니다.
그 정도로 한쪽으로 기운 비대칭 아래에서는, 결정을 내리기 위해 법적 질문을 해결할 필요가 없습니다. 그저 틀려도 견딜 수 있는 쪽 가지를 택하면 됩니다.
같은 질문, 반대 방향을 가리키며
위의 모든 것은 우리가 만들어내는 코드에 관한 것입니다. 동일한 논리가 우리가 받는 코드에도 적용됩니다. 누군가 우리 저장소 중 하나에 풀 리퀘스트를 엽니다. 그 패치는 모델이 작성했습니다. 그들은 우리에게 무엇을 부여하고 있는 것일까요?
대부분의 프로젝트는 이를 Developer Certificate of Origin — DCO, 커밋 메시지 맨 아래의 Signed-off-by: 줄 — 로 처리합니다. 이는 기여자가 서명할 때 확인하는 짧은 진술입니다: 자신이 그 기여를 직접 만들었거나, 그것이 호환되는 라이선스 아래의 출처에서 왔으며 자신이 프로젝트의 조건 아래 이를 제출할 권리를 가지고 있다는 것입니다. 이는 의도적으로 가볍습니다. 변호사도, 서류 작업도 없이 커밋당 한 줄입니다. 이는 리눅스 커널과 QEMU를 비롯한 많은 프로젝트가 자신들의 코드가 어디서 왔는지를 확립하는 방식입니다.
기계가 작성한 패치의 경우, 그 두 조건 어느 쪽도 간단히 참이 아닙니다. 그리고 어느 쪽 갈래를 택하든 이 갈림길은 같은 방식으로 풀립니다.
기계 생성 출력이 저작권을 지니지 않는다면, 기여자는 그것에 대해 아무 권리도 갖지 않습니다. 여러분에게 라이선스를 부여할 것이 없습니다.
대신 그것이 학습 데이터로부터 파생된 것으로 취급된다면, 그 권리는 — 무엇이든 간에 — 그 데이터를 작성한 사람에게 속합니다. 기여자는 여전히 아무것도 가지고 있지 않으며, 여전히 여러분에게 라이선스를 부여할 것이 없습니다.
어느 쪽이든, 그들은 자신이 가지고 있지 않은 것을 부여할 수 없습니다. 그 서명이 부정직한 것은 아닙니다. 기여자는 선의로 서명했고 그 작업을 했습니다. 그것은 그저 공허할 뿐입니다: 결코 자신의 것이 아니었던 무언가의 이전.
실질적인 결과는 그것이 들리는 것만큼 경악스럽지는 않으며, 두 갈래는 뚜렷하게 다릅니다.
첫 번째 갈래에서는, 여러분은 아예 허가가 필요하지 않습니다. 아무도 소유하지 않는 자료는 누구나 사용할 수 있습니다. 그 패치를 받아들이는 것은 괜찮으며 나쁜 일은 일어나지 않습니다. 조용히 바뀌는 것은 반대 방향입니다: 카피레프트는 저작권 위에 세워져 있으며, 저작권이 없는 자료에는 붙을 수 없습니다. 기계가 작성한 패치를 축적하는 GPL 프로젝트는 자신의 라이선스가 미치지 못할 수도 있는 부분들을 축적하게 됩니다. 라이선스는 배포된 저작물을 여전히 지배합니다. 그 안의 집행 가능한 핵심은 아무도 눈치채지 못하는 사이에 서서히 얇아집니다.
두 번째 갈래는 이빨이 있습니다. 모델이 암기한 학습 데이터를 문자 그대로 재현한다면 — 이는 실제로 일어나는 일이며, 새로운 로직보다는 흔한 관용구와 잘 알려진 구현에서 더 자주 일어납니다 — 여러분은 확인할 방법이 없었던 기여자로부터의 보증을 받고 다른 누군가의 저작권 있는 코드를 받아들인 셈입니다. DCO의 모든 가치는 서명하는 사람이 알 수 있는 위치에 있었다는 데 있습니다. 여기서는 그렇지 않습니다.
Debian은 지금 이를 검토하고 있습니다. LLM 사용에 대한 총회 결의안이 2026년 7월 23일에 다섯 개의 투표 안건과 함께 논의 기간에 들어갔습니다. 이들은 범위 전체에 걸쳐 있습니다: 안건 A는 패키지, 문서, 웹 리소스에 대한 LLM 지원 기여를 완전히 금지하도록 사회 계약을 개정할 것입니다. 안건 C는 기여자들에게 실용적인 한도 내에서 LLM을 피할 것을 요청하고, 프로젝트 커뮤니케이션에는 인간만의 작성을 요구하며, 개별 관리자가 자신만의 금지를 부과할 수 있게 합니다. 안건 B, D, E는 라이선스 검증, 기여자 책임, 공개, 클라우드 서비스로의 기밀 자료 전송 제한 등에 다양하게 기반해 조건부로 AI 지원 작업을 허용합니다. 이 글을 쓰는 시점에 이는 논의 중이며 아무것도 결정되지 않았습니다.
이번이 두 번째입니다. 2024년의 이전 시도는 결의 없이 끝났으며, 중단한 이유는 새겨둘 가치가 있습니다: 조치에 대한 반대는 그 우려가 근거 없다는 것이 아니라, 아무도 집행할 수 없는 규칙은 채택할 가치가 없다는 것이었습니다. diff를 봐서는 알 수가 없습니다.
이는 주변부의 우려가 아닙니다. 이는 정확히 출처를 가장 신중하게 관리하는 프로젝트들에 가장 세게 떨어집니다. DCO 기반 프로젝트의 코드가 어디서 왔는지에 대한 전체 모델이 바로 그 하나의 확인에 달려 있기 때문입니다.
우리는 이를 어떻게 다룰지 해결하지 못했으며, 엄격해지기에는 불리한 위치에 있습니다. 우리는 모델이 작성한 이식을 배포합니다. 기계가 작성한 코드를 공개하면서 기계가 작성한 기여는 거부하는 프로젝트는 동시에 두 가지 양립할 수 없는 입장을 취하는 것이며, 우리는 그러고 싶지 않습니다. 정직한 선택지는 Debian이 저울질하고 있는 것과 같습니다 — 공개, 기여자 책임, 또는 아무도 검증할 수 없는 규칙 — 이며, 우리는 아직 하나를 고르지 않았습니다.
이 논증이 흐르는 또 다른 축
Debian의 논쟁은 출처와 라이선싱에 관한 것입니다. 그것이 유일한 축은 아니며, 두 번째 축은 저작권과 아무 관계가 없습니다.
FLOSS 포지인 Codeberg는 2026년 7월에 회원이 승인한 두 개의 동의안을 채택했고, 라이선스는 거의 건드리지 않는 표현으로 그 근거를 밝혔습니다. 그 반대는 비용과 노력에 관한 것입니다: 모두에게 떠넘겨지는 에너지 및 하드웨어 소비, 작은 포지들을 일반 사용자까지 방해하는 방어 수단으로 내모는 크롤러 트래픽, 공개되었다가 결코 유지 관리되지 않는 일회성 “바이브 코딩” 프로젝트, 그리고 검토하는 사람들에게 걸리는 부담입니다:
Maintainers are under an increased work-load due to people submitting (often well-meaning) low-effort, LLM-generated contributions that require substantial amounts of time to review.
그들의 이용 약관은 이제 그런 프로젝트를 대량 삭제가 아니라 관리자가 사안별로 적용하는 방식으로 만류합니다.
그러니 유통되고 있는 독립적인 두 질문이 있으며, 프로젝트는 그 격자 위 어디에든 자리할 수 있습니다: 기계가 작성한 코드에 애초에 라이선스를 부여할 수 있는가, 그리고 생태계가 그 물량을 감당할 수 있는가. Debian은 첫 번째에 투표하고 있으며 아직 결론짓지 못했습니다. Codeberg는 두 번째에 대해 행동했습니다. 어느 결과도 다른 쪽을 해결하지 못하며, 프로젝트가 각각에 내놓는 답은 대체로 서로 상관이 없습니다.
우리가 해결되었다고 가장하지 않을 부분
우리는 애초에 그 어느 것도 할 필요가 없었을지도 모릅니다.
세 가지 논증을 함께 고려해 보십시오. 기능성은 보호받지 않는다고 CJEU가 직접 말했습니다. 순전히 기계가 생성한 출력에는 인간 저자가 없을 수 있으므로, 걱정할 새로운 저작권이 없을 수 있고, 어색하게도 우리의 것도 없을 수 있습니다. 그리고 진정한 규율을 갖추고 실행된 2-모델 프로토콜은 진짜 클린룸일 수 있으며, 그 경우 이 이식은 애초에 보호받는 표현에 전혀 닿지 않았습니다.
이 셋 모두가 성립한다면, 이 이식들 중 일부는 떳떳하게 허용적으로 라이선스될 수 있었을 것입니다. 어느 것도 성립하지 않는다면, 우리의 보수적인 선택이 그저 옳았던 것입니다. 우리는 어느 쪽인지 모르며, 시험해 보지도 않았습니다. 우리는 그것을 해결하는 사례가 되는 데는 관심이 없습니다.
이 질문은 무시한다고 사라지지 않습니다. 이런 종류의 이식은 점점 평범한 일이 되고 있습니다 — 이제는 저렴하며, 유지 관리될 수 있는 곳으로 옮겨질 가치가 있는 유지되지 않는 C 코드가 엄청나게 많습니다. 그 이식 하나하나가 같은 두 질문을 마주하게 될 것이며, 그중 대부분은 묻지 않음으로써 답할 것입니다. 자신이 작성하지 않은 패치를 병합하는 모든 프로젝트도 마찬가지입니다. 즉 모든 프로젝트가 그렇습니다. 그 질문들은 여러분이 코드를 작성하든 그저 받아들이든 상관없이 찾아옵니다.