이 프로젝트를 재라이선스할 권리가 없음

(github.com/chardet)

1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개

chardet의 원 저자인 Mark Pilgrim이 프로젝트의 LGPL 라이선스 위반을 지적하며, 최근 버전 7.0.0의 MIT 라이선스 전환을 철회할 것을 요구함
그는 유지보수자들이 “완전한 재작성”이라 주장하더라도, 원본 코드에 직접 노출된 상태에서 작성된 파생물이므로 LGPL을 유지해야 한다고 명시함
여러 개발자들이 AI 보조 재작성이 실제로 “클린룸 구현(clean room implementation)”인지, 그리고 LLM이 원본 코드를 학습했는지 여부를 논의함
일부는 API 호환성과 공정 이용(fair use) 가능성을 언급했으나, 다수는 저작권 침해 가능성과 AI 코드 생성의 법적 불확실성을 우려함
이번 논의는 AI가 생성한 코드의 저작권 책임, 오픈소스 프로젝트의 라이선스 변경 절차, 유지보수 권한의 한계를 둘러싼 중요한 선례로 주목됨

Mark Pilgrim의 문제 제기

Mark Pilgrim은 자신이 chardet의 원 저자이며, 프로젝트가 LGPL 라이선스로 배포되어 왔다고 명시함
- 그는 버전 7.0.0에서 “재라이선스 권한이 있다”는 유지보수자의 주장이 잘못되었다고 지적
- LGPL 하의 코드는 수정되더라도 동일한 라이선스로 공개되어야 하며, “완전한 재작성” 주장은 법적 근거가 없음을 강조
- “코드 생성기 추가”가 새로운 권리를 부여하지 않는다고 명시
Pilgrim은 프로젝트를 원래의 LGPL 라이선스로 되돌릴 것을 요구함

커뮤니티의 초기 반응

한 사용자는 AI 보조 재작성 이전 버전의 포크가 있는지 질문, 다른 사용자가 6.0.0 버전 링크를 제시
일부는 “법적으로 Mark가 옳다”고 동의하며, LGPL 위반 가능성을 인정
다른 사용자는 “AI를 통한 재작성은 불가피한 트레이드오프”라며 실용적 관점을 언급

법적 논의: API, 저작권, 공정 이용

한 사용자는 Google LLC v. Oracle America, Inc. 판례를 인용해 API도 저작권 보호 대상임을 언급
- API 호환성을 이유로 한 재작성은 공정 이용 요건을 충족하지 않으면 불법일 수 있다고 설명
이에 대해 다른 사용자는 Google의 경우 공정 이용으로 인정되었다며 반박
논의는 API 호환성 재작성의 합법성과 AI 생성 코드의 저작권 상태로 확장됨

AI 코드 생성과 클린룸 구현 논쟁

일부는 “AI가 원본 코드를 학습했을 가능성”이 있다면 클린룸 구현이 성립하지 않는다고 지적
- LLM이 chardet 코드를 학습했는지 여부가 법적 판단의 핵심이 될 수 있음
다른 사용자는 “AI가 입력·출력만을 기준으로 코드를 생성했다면 가능할 수도 있다”고 주장
- 그러나 이에 대해 “그렇다면 라이선스 자체가 무의미해진다”는 반론이 제기됨
AI 코드의 저작권 책임 불명확성과 라이선스 준수 검증의 어려움이 주요 쟁점으로 부상

라이선스 호환성과 GPL 논의

일부는 MIT 라이선스가 GPL과 호환되지 않는다고 주장했으나, 다른 사용자가 FSF의 공식 문서를 인용해 MIT(Expat)는 GPL 호환임을 설명
그러나 “LGPL 코드를 MIT로 재라이선스하는 것은 여전히 위반”이라는 점에는 다수 의견이 일치
또 다른 사용자는 “LGPL 코드 기반의 명성과 저장소를 유지하면서 계약을 버릴 수는 없다”고 지적

AI 학습 데이터와 신뢰 문제

여러 사용자가 “Claude가 LGPL 코드를 학습하지 않았다고 믿을 수 있는가”라는 의문 제기
- AI 모델의 학습 데이터 추적 불가능성이 법적 리스크로 언급됨
일부는 “AI 코드가 표절 가능성을 내포한다면 사용 자체를 피해야 한다”고 주장
- 연구 인용을 통해 AI 코드의 2~5%가 기존 코드 복제일 가능성이 있다는 통계가 제시됨

프로젝트 정체성과 유지보수 권한

일부는 “이전 기여자들의 코드가 모두 제거되었다면, 새로운 버전은 독립적일 수 있다”고 주장
- 그러나 “이름과 평판을 그대로 사용하는 것은 부적절하다”는 반론 존재
“저작권은 표현을 보호하지 이름을 보호하지 않는다”는 의견도 제시됨
유지보수자가 모든 기존 코드를 제거했다면 법적 위반이 아닐 수 있다는 견해도 있었으나, 명확한 증거는 제시되지 않음

커뮤니티의 종합적 시각

논의는 AI 코드 생성의 법적 책임, 프로젝트 라이선스 변경의 정당성, 오픈소스 유지보수 권한의 한계 등으로 확장됨
일부는 “v7.0.0을 포크해 LGPL로 되돌리자”는 제안도 제시됨

핵심 쟁점 요약

LGPL → MIT 전환의 적법성: 원 저작자의 동의 없이 불가능하다는 다수 의견
클린룸 구현 여부: AI가 원본 코드를 참조하지 않았음을 입증해야 함
프로젝트 명칭·평판 사용 문제: 동일 이름으로의 재배포는 법적·윤리적 논란
AI 코드의 신뢰성: 표절 위험과 공급망 안정성 우려

▲

GN⁺ 8시간전 [-]

Hacker News 의견들

Pilgrim이 저작권(clean room) 개념을 잘못 이해하고 있다고 생각함
“완전한 재작성”이라는 주장은 중요하지 않음. 법적으로는 독립적인 구현이 가능함.
Clean room은 단지 소송을 단순화하기 위한 절차적 장치일 뿐, 원본 코드에 노출되지 않아야 한다는 법적 요구사항은 아님.
실제로 Linux도 Unix 내부 구조를 알고 있었지만 독립적으로 구현되었음
- 법적 해석과는 별개로, AI가 GPL 코드를 자동으로 재작성해 라이선스를 우회할 수 있다면 오픈소스 커뮤니티의 무기를 잃는 셈이라 우려됨
- 구조적 유사성 테스트로 파생 저작물 여부를 판단할 수 있다는 주장도 틀림. Claude를 사용했다는 이유만으로 파생 저작물이라 단정하는 것도 잘못임. 실제 법적 기준은 여전히 불명확한 영역임
- 세 가지 경우로 나눠 생각해야 함.
  1. 코드가 유사하면 clean room 재구현을 증명해야 함
  2. 완전히 다르면 clean room 여부는 무관함
  3. 대부분은 유사/비유사 부분이 섞여 있으므로 각 부분별로 분석 필요함. 일부라도 복사된 부분이 있으면 그 부분은 다시 써야 함
- chardet의 기능(유니코드 인코딩 감지)은 본질적으로 고정되어 있음. 따라서 새 구현이 동일한 테스트를 통과하는 것은 당연함.
  JPlag의 낮은 유사도는 표절이 아님을 보여주는 설득력 있는 증거로 보임
- AI가 생성한 재작성 코드가 저작권 보호 대상이 된다고 생각하는 게 놀라움
“코드베이스를 알고 있다면 재작성도 저작권 위반”이라는 주장은 완전히 타당하지 않음
내부 지식은 특허 영역이지 저작권과는 무관함.
단, 원본 코드를 그대로 옆에 두고 문장만 바꾸는 식은 위반임.
AI가 원본 코드를 보고 비슷한 코드를 생성하면 그건 사실상 병렬 복제로 간주될 가능성이 큼.
하지만 원본을 보지 않고 완전히 새로 작성하면 가능함. 다만 법적으로 방어가 어렵기 때문에 기업 입장에서는 위험 요소로 간주해야 함
- 특허와 저작권의 차이를 명확히 해야 함.
  특허는 독립 발명 여부와 관계없이 침해가 가능하지만, 저작권은 창작의 독립성이 핵심임.
  단, 이미 본 적 있는 작품과 동일한 결과물을 만들었다면 배심원을 설득하기 어려움
  결국 유사성이 있으면 증거의 우세(preponderance of evidence) 기준으로 위반으로 판단될 가능성이 큼
- 마리오 푸조의 『The Godfather』를 읽고 구조가 같은 소설을 쓰면 파생 저작물로 간주될 것임.
  반면 원작을 전혀 모른다면 독립 창작으로 인정됨
- Claude.md 파일이 있다면, 새 유지보수자가 Claude를 코드 생성기로 사용했을 가능성이 높고, 그 모델은 chardet 원본 코드로 학습되었을 것임
- “얼마나 달라야 새 코드로 인정되나?”라는 질문이 나옴
- 재작성은 번역과 유사함. 번역도 저작권 침해임.
  아이디어 자체는 보호되지 않지만, 표현은 보호됨.
  LLM이 학습 과정에서 원본 코드를 봤다면 법적 회색지대임
핵심은 LGPL 위반 여부임.
새 코드가 원본을 기반으로 했다면 파생 저작물로 간주되어 LGPL을 유지해야 함.
“완전한 재작성”이라 주장하더라도 원본 코드에 노출되었다면 라이선스 위반이 될 수 있음
- 노출되었다고 해서 자동으로 파생 저작물이 되는 것은 아님.
  clean room은 단지 소송 방어용 절차일 뿐이며, 입증 책임은 고소인에게 있음.
  Linux나 GNU 도구들도 Unix를 알고 있었지만 합법적이었음
- 만약 Claude가 원본 코드를 학습했다면, 그 해석에 따르면 AI는 LGPL 파생물만 생성 가능하다는 흥미로운 결론이 나옴
- 저작권이 핵심임. 새 코드가 원본의 파생물이라면 LGPL을 따라야 하고, 아니라면 새 저작권자가 자유롭게 라이선스를 정할 수 있음
- 같은 이름으로 버전만 올린다면, 사실상 같은 프로젝트로 보일 수 있음
컨설팅 중 흥미로운 사례를 봤음.
한 SaaS 회사의 엔지니어가 Claude Code로 자사 앱을 역공학해 API 호환 백엔드를 일주일 만에 만들었음.
“경쟁사가 이렇게 하면 어떻게 보호하나?”라는 질문을 받음
- 그건 단순히 기술 발전임.
  코드 자체가 비즈니스의 핵심이라면 이미 위험함.
  경쟁을 걱정하기보다 더 나은 제품을 만드는 게 중요함
- StrongDM Factory 사례처럼, 외부 서비스를 복제해 테스트용으로 사용하는 일이 현실화되고 있음.
  이제는 “Slack이나 Drive를 재구현하자”는 말이 비현실적이지 않은 시대임
- 만약 AI가 단순 프런트엔드만 보고 백엔드를 재구현했다면, 그건 합법적임.
  API는 공개된 인터페이스이므로 보호 대상이 아님
- 특허는 사후 등록이 불가하고, 저작권은 아이디어를 보호하지 않음.
  IBM BIOS나 DOS의 리버스 엔지니어링 사례처럼, 독립 구현은 합법임
유지보수자는 신탁자(trustee) 이지 소유자가 아님.
원작자의 라이선스를 임의로 바꾸면 안 됨.
완전히 새로 만든 코드라면 새 이름으로 프로젝트를 시작해야 함.
“기존 버전을 고정하라”는 식의 발언은 커뮤니티 정신에 어긋남임
2021년 코멘트에서 이미 “chardet은 LGPL 기반이라 재라이선스 불가”라 언급됨.
그걸 알고도 재작성했다면 무모한 결정이며, 원작자에 대한 무례함임
- 반대로, 프로젝트의 활용도 극대화를 위해 옳은 선택이었다는 의견도 있음
AI가 원본 코드를 본 상태에서 작성했다면 clean room 구현이 아님.
만약 두 개의 AI 팀을 두어 하나는 명세를 만들고 다른 하나는 구현한다면 괜찮을까?
IBM 시절의 전례를 따르지만, 모델이 이미 원본으로 학습됐다면 여전히 문제임
- chardet이 학습 데이터에 포함되어 있다면 어떤 구조로든 clean room 불가임
- 명세를 추출하고 별도의 모델이 그 명세로 코드를 작성한다면, 이론적으로는 clean room 가능함.
  단, 명세가 표현적 요소를 포함하지 않도록 검증해야 함
- 학습 데이터에 원본이 있다면 여전히 위반 가능성이 큼
- API 구조도 저작권의 일부라는 주장도 있었으나, 수정됨
- IBM/Compaq 사례는 표면적으로만 유사함.
  학습 데이터에 원본이 포함된 상황에서는 비교 자체가 무의미함
“위키백과를 복붙하고 몇 단어만 바꾸면 괜찮나요?”라는 농담처럼,
결국 의도적 회피는 불가능함.
의존성 버전을 고정해야 할 정도로 신뢰가 어려운 시대임
- 기술자들은 종종 법을 기술적 규칙으로 오해함.
  하지만 법은 총체적 판단을 중시함.
  법원은 “증거의 우세” 기준으로 판단하며, 단순히 단어를 바꾼다고 새 작품이 되지 않음.
  원본이 필수적이었다면 파생 저작물로 판단될 가능성이 높음.
  학습 데이터에 원본이 포함되어 있다면 저작권 침해 소송이 불가피할 것이라 예측함
한편, Mark Pilgrim이 다시 등장한 것이 흥미로움
그의 위키백과 페이지에는 “인터넷에서 사라진” 일화가 있음.
그의 Python 책들은 여전히 추천할 만함
- 곧 “a2mark” GitHub 계정이 위키백과에 언급될지도 모름
“AI가 GPL 코드로 학습됐다면 모든 AI 코드가 GPL 오염(taint) 된 것 아닌가?”라는 놀라움이 있음
- ReactOS처럼 완전한 clean room을 요구하는 프로젝트도 있지만, 이는 법적 안전장치일 뿐 필수는 아님
- “오염”을 입증하려면 실제로 파생성이 증명되어야 함.
  미국의 clean room 절차는 단지 소송 단축용 전략임
- 저작권 제도는 본래 자본 보호 수단이었기에, 실제로 그렇게 강하게 집행될 가능성은 낮다고 봄
- LLM 열풍 초기부터 이런 문제를 경고한 사람들이 있었음

답변달기