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 열풍 초기부터 이런 문제를 경고한 사람들이 있었음