Vibecoding 공개로 Emacs 패치가 거절됨
요약
Vibecoding 관련 Emacs 패치 거절 사례를 통해 오픈소스 라이선스와 LLM 생성 코드의 저작권 문제를 심도 있게 다룹니다. 오픈 웨이트 모델의 정의와 GNU 프로젝트의 엄격한 라이선스 정책 준수의 중요성을 강조합니다.
핵심 포인트
- 오픈 웨이트 모델이 학습 데이터의 오픈소스를 보장하지 않음
- LLM 생성 코드의 저작권 불확실성이 프로젝트 전체 라이선스에 미치는 위험
- GNU 프로젝트의 엄격한 라이선스 정책 및 저작권 보호 원칙
- LLM 활용 시 정직한 공개가 오픈소스 생태계 유지에 필수적임
"open weight"의 open이 무슨 뜻인지 저자가 오해한 것 같음
최종 행렬 덩어리가 공개되어 있고 어느 정도 미세조정할 수 있다고 해서, 그걸 만드는 데 쓴 학습 자료까지 오픈소스였다는 뜻은 아님. OSI seems to agree도 비슷하게 보는 듯하고, 그렇다면 저작권 문제는 전혀 해결된 게 아님
선의로 대가 없이 기여하려는 사람에게 공감은 가지만, GNU는 규칙을 명확히 적어두었고 거기에 가서 "조금만 어겼고, 여기 패치가 있다"고 하면 거절당해도 이상하지 않음. 거절된 이유는 정직함이 아니라, 명시적으로 하지 말라고 한 일을 했기 때문임
비공개 계약이 걸린 데이터시트를 바탕으로 작성된 드라이버도 전부 자유 소프트웨어가 아닌 건가? 제조사 직원이 내부 문서와 전문 지식을 활용해 드라이버를 작성한 경우는 또 어떻게 봐야 하나?
학습 자료가 왜 관련 있는지 잘 모르겠음. 산출물을 자유롭게 사용, 재배포, 수정할 수 있다면 꽤 open에 가깝다고 봄
수십억 명이 틀릴 수도 있다는 걸 저자가 오늘 배우면 좋겠음. Normalization of deviance는 일탈을 정당화하지 않고, 그 일탈이 계속 퍼지는 방식을 설명할 뿐임 chatbot psychosis에서 보이는 패턴 중 하나는 반대하거나 다른 의견을 내는 인간을 적대자로 인식하는 것임. 챗봇이 학습한 narremes에는 사용자가 주인공이고, 어깨너머 카메라와 읽기 쉬운 개인 서사를 가진다는 관점이 포함되어 있음. 챗봇의 후처리된 선호 서사가 사용자에게 주인공 의식을 강화하면서 직접 영향을 주고, 사용자가 충분히 이온화되면 중립적 입장도 받아들이지 못하게 됨
이 경우 저자가 링크하거나 인용하지 않은 the original discussion를 읽어보길 권함. Emacs 커뮤니티는 저자에게 친절하고, 수용적이며, 질문하고, 관심을 보이고, 받아들이는 태도를 보였음. 패치를 거절할 때도 저자를 비난하기보다 GNU 정책에 초점을 맞춰 부드럽게 말함
실제 논의 링크를 글에 넣지 않은 건 솔직히 큰 위험 신호임. 못 알아챈 게 믿기지 않을 정도임
narremes라는 Wikipedia 문서는 단락 하나뿐인데 [incomprehensible] 태그가 붙어 있음
그래도 문맥상 무슨 뜻인지는 알겠고, 여기에는 유용하고 잘 맞는 개념처럼 보임
GNU Project는 미국 저작권 문제만이 아니라 전 세계 저작권 우려를 고려해야 함. 미국 법도 완전히 정리된 상태가 아님
GNU는 중요한 기여에 대해 자신들이 저작권을 100% 보유한다고 확신하고 싶어함. 여기서 저자의 법 해석은 중요하지 않고, GNU Project는 안전하게 가는 중임. LLM에 대해 아마 갖고 있을 다른 우려는 아직 고려하지도 않은 상태임
솔직히 현재 판례 기준으로 보면 저자의 미국 법 이해도 틀렸음[1]. 기존 판례상 LLM 생성 코드는 저작권 보호를 받을 수 없고, 따라서 라이선스를 붙일 수도 없으며 자동으로 퍼블릭 도메인이 됨
게다가 저장소에 LLM 생성 코드가 들어 있는데 그 코드가 명확히 구분·표시되어 있지 않다면, 저장소 전체가 저작권 보호도 라이선스 부여도 불가능한 것으로 간주됨
달리 말하면 저자가 거짓말해서 코드가 커밋되게 했다면, Emacs 코드베이스 전체의 라이선스 효력을 위험에 빠뜨릴 수 있었음
이 모든 건 "IANAL이지만 변호사들이 명백히 틀렸다"는 망상에 가까운 오만한 태도와는 별개임. 관련 법 조항 일부만 보면서, 동시에 변호사들을 오만하다고 비난하고 있음
[1] 약 두 달 전 회사 법무팀과 이런 대화를 나눴을 때 기준으로는 최신임
"거짓말했으면 받아들여졌을 것"이 의미 있는 논거인지는 잘 모르겠음
똑같은 논리를 라이선스에도 쓸 수 있음. 독점 코드베이스에서 뭔가 복사해 와서 직접 썼다고 거짓말하면 패치가 받아들여질 수 있음. 하지만 사실대로 말하면 거절됨. 그러니 결론은 라이선스가 나쁘다는 건가?
맞음. no-LLM 정책에 대해 "그러면 사람들은 그냥 거짓말할 텐데"라는 주장을 자주 들음
그건 해당 사람들에 대해 좋은 얘기는 전혀 아니지 않나?
관리자들을 LLM 찬반 정책 때문에 괴롭혀도 좋을 건 없다고 봄. 그들이 일을 하고 있고, 어떤 기여를 평가하고 받아들이고 거절할지 선택할 권리가 있음
물론 불평하는 건 괜찮다고 봄. 이 사람은 블로그에서 자기 입장을 밝히고 있고, 그렇게 논의를 맞춰가는 것이니까. 다만 framing에는 동의하지 않음. 여기서 문제는 "정직함"이 아님. no-LLM 정책이 공지되어 있었다면, 그런 기여를 원하지 않는 프로젝트에 LLM을 써서 기여하려고 시간을 쓴 책임은 본인에게 있음
이건 비건에게 고기나 치즈가 든 음식을 주고, 재료를 "정직하게" 말했기 때문에 안 먹는다고 불평하는 것과 다르지 않음. "말 안 했으면 유제품이 들어간 줄 몰랐을 텐데"는 좋게 보이지 않고, "말 안 했으면 내가 LLM을 쓴 줄 몰랐을 텐데"도 마찬가지임
동의함. 새 제목으로 Vibecoding gets Emacs patch rejected를 제안했음. 바이브 코딩을 인정한 정직함은 저작권 침해를 인정한 정직함과 비슷함. 거절의 근본 원인은 정직함이 아님
LLM을 쓰고 정직하게 밝히는 건 패치가 거절될 이유라고 봄. LLM을 쓰고 거짓말하는 건 패치 거절에 더해 이후 기여 시도까지 금지될 이유임
GNU와 FSF는 전문적인 법률 자문을 받는 데 꽤 많이 투자함. 그런데 이 잠재 기여자는 인터넷의 어떤 사람이 하는 말에 따라 그 전문 자문을 무시하라고 권하는 셈임
전문 자문에 비용을 냈다면 그 조언을 따르는 게 합리적이고, 동의하지 않는다면 다른 전문가를 찾아야 함. 무작위 인터넷 댓글러의 조언 때문에 그걸 무시하는 건 "거의 풍자적"인 게 아니라 그냥 어리석음
프로젝트에 기여한다는 건 자신을 드러내고 취약한 위치에 서는 일임. 특히 "코드는 작동하고" 개인적인 불편을 해결해주는 경우라면 거절이 더 힘들 수 있음
거절과 별개로, 앞으로 꽤 흥미로운 법정 사례들이 생길 수 있을 것 같음. 대형 모델 제공사들이 어떤 형태의 면책을 제공하고 "우리가 도와 만든 코드이니 원하는 대로 저작권을 주장해도 된다"고 할 수도 있고, 반대로 문제를 밀어붙여 자신들이 소유하며 특정 용도에는 라이선스를 받아야 한다고 할 수도 있음. Claude는 현재 코드를 사용자에게 주지만, 어떤 면책을 제공하는지는 모르겠음. 다른 모델들도 잘 모르겠음
범죄는 잡혔을 때만 불법이라는 사실을 알고 있었나
GNU의 열렬한 팬은 전혀 아니지만, LLM 코딩 도구는 GNU 철학의 정반대에 있는 것 아닌가? 고양이 카페에 개를 데려가고 쫓겨났다고 화내는 느낌임
제목을 "Honesty gets Emacs patch rejected"에서 Vibecoding gets Emacs patch rejected로 바꾼 건 매우 부정직하다고 봄
저자처럼 AI 도구의 도움을 받았더라도 코드에 그 정도 시간과 이해를 들였다면 명백히 바이브 코딩이 아님. "Emacs를 더 빠르게 만들어줘"라고 AI에 던져놓고 결과를 눈감고 제출했다면 바이브 코딩이겠지만, 글을 읽어보면 분명히 그런 일은 아니었음
"honesty"라는 제목도 부정직했음. 패치가 거절된 건 정직함 때문이 아니라 정책 위반 때문임
"바이브 코딩"이라는 용어에 대한 해석에는 동의하지만, 사람들이 그 용어를 워낙 다르게 쓰는 걸 보면 그렇게까지 부정직하다고 보진 않음
나라면 "Breaking contribution policy gets Emacs patch rejected" 정도로 했을 것 같음. 여전히 빈정대지만, 반박하기는 더 어려움
여기서 눈에 띄는 건 저자가 두 달 동안 꾸준히 작업했다고 주장하면서, 문제를 찾고 해결하는 데 사용했다는 모델은 12일 전 출시됐다고 설명한다는 점임
저자가 꽤 화가 난 건 이해하지만, 결국 오픈소스는 어떤 권리를 주는 게 아니라 이미 만들어진 코드를 쓸 수 있는 특권에 가깝다고 봄. 장점이 있다면, 아마 있을 것이고 macOS에 대해 쓴 내용은 대체로 맞으니 Emacs 개발자들이 시간을 내서 살펴볼 수도 있음. 다만 macOS가 그들의 주된 관심사는 아닐 것 같음
이 정책이 얼마나 어리석은지 증명하는 쉬운 해결책이 있음. 두 번째 모니터에 LLM 보조 PR diff를 띄워두고, 기본 모니터에서 수정 내용을 처음부터 손으로 다시 작성하면 됨. 변수 이름과 주석 내용도 조금 바꾸면 됨
이제 사람이 작성한 코드가 되었으니 병합될 수 있음
전 세계 여러 관할권에서 LLM 산출물을 둘러싼 저작권과 법적 쟁점을 보면, 그건 매우 순진한 관점임
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기