최근 List-KR 이슈 #1095를 읽었다. List-KR의 저장소 소유자인 fifoqueue와 핵심 기여자였던 piquark6046 사이에서 운영권과 프로젝트의 대표성을 둘러싼 갈등이 어떻게 이어졌는지 정리한 글이다.
이 글은 해당 이슈에 공개된 이메일, 커밋 기록, 사건의 시간 순서를 바탕으로 한 개인적인 의견이다. 공개되지 않은 대화나 상대방의 설명이 있을 수 있으므로, 누구의 의도를 단정하기보다 공개 자료에서 확인할 수 있는 프로젝트 거버넌스 문제에 초점을 맞추려고 한다.
이 글은 공개된 자료를 바탕으로 작성한 저의 개인적인 소견일 뿐이며, 새로운 분쟁을 일으키거나 특정 개인·조직을 비난하기 위한 글이 아닙니다. 또한 List-KR의 소유자인 fifoqueue, piquark6046, AdGuard를 포함한 어느 당사자의 공식 입장이나 의견도 대변하지 않습니다.
기여량과 소유권은 같은 것일까?
piquark6046가 List-KR에 상당히 많은 기여를 했고 실질적인 유지보수에서도 큰 역할을 했다는 점은 분명해 보인다. 프로젝트가 유지되는 데 기여한 시간과 노력은 충분히 인정받아야 한다.
하지만 코드를 많이 기여했다는 사실과 프로젝트의 소유권이나 공식적인 대표성을 결정할 권한은 별개의 문제라고 생각한다.
오픈소스 프로젝트에서는 원래 만든 사람보다 다른 기여자가 더 많은 코드를 작성하는 상황도 충분히 생길 수 있다. 저장소 관리 권한을 받거나 조직의 Owner가 되는 일도 협업 과정에서는 자연스럽다. 그렇다고 그 순간 프로젝트의 이름, 브랜드, 공식 배포 경로까지 자동으로 그 기여자에게 넘어가는 것은 아니다.
기여는 프로젝트에 대한 공로와 영향력을 만든다. 그러나 소유권이나 대표권의 이전에는 당사자 사이의 명시적인 합의가 필요하다. 둘을 같은 것으로 취급하면 프로젝트에 오래 기여한 사람과 프로젝트의 정체성을 최종적으로 책임지는 사람 사이의 경계가 불분명해진다.
회사 직원의 기여와 회사의 소유는 다르다
이 사건에서는 piquark6046가 AdGuard에 입사한 뒤 README에 List-KR이 AdGuard에 의해 유지보수되는 것처럼 해석될 수 있는 문구가 들어갔다. 또한 list-kr.com과 NPM의 @list-kr처럼 프로젝트 이름을 사용하는 별도 인프라도 만들어졌다. 별도 인프라를 만든 행위 자체가 문제라는 뜻은 아니다. 쟁점은 이 채널들이 List-KR의 공식 채널처럼 보이는 이름을 사용하면서도 실제 관리 주체는 저장소 소유자인 fifoqueue와 달랐다는 데 있다.
한 기여자가 AdGuard 직원이라는 사실만으로 List-KR 자체가 AdGuard의 프로젝트가 되는 것은 아니다. 직원 개인이 업무의 일부로 오픈소스 프로젝트에 기여할 수는 있지만, 그 기여만으로 기존 프로젝트의 소유권과 대표성이 회사에 이전되지는 않는다.
list-kr.com은 이름만 보면 List-KR의 공식 웹사이트처럼 보이고, NPM의 @list-kr도 공식 패키지 네임스페이스로 받아들이기 쉽다. 외부 사용자는 내부의 권한 관계나 합의 내용을 알 수 없기 때문에 프로젝트와 같은 이름을 사용하는 도메인과 패키지를 자연스럽게 공식 배포 경로로 인식한다. 저장소는 fifoqueue가 소유하지만 도메인, 패키지와 주요 배포 경로는 다른 주체가 관리한다면 법적인 소유권이 이전되지 않더라도 프로젝트를 누가 대표하고 무엇을 공식 List-KR로 배포할지에 대한 실질적인 통제권은 분리될 수 있다.
따라서 이슈 작성자의 주장처럼 이런 변화가 저장소 소유자와 충분히 합의되지 않은 상태에서 진행됐다면, 단순히 개발 편의를 위한 인프라 추가가 아니라 프로젝트의 공식성과 대표성을 누가 결정할 수 있는가에 관한 거버넌스 문제가 된다. 소유자 입장에서는 자신이 저장소를 계속 소유하고 있는데도 사용자가 접하는 공식 채널과 배포 경로는 다른 쪽으로 옮겨가는 상황처럼 느낄 수 있다.
이런 대표성 문제를 둘러싸고 양측 사이에 1차 분쟁이 발생한 것으로 설명된다. 이슈 작성자에 따르면 이 과정에서 fifoqueue는 자신이 List-KR의 소유자이며, 프로젝트의 소유권을 AdGuard에 넘기거나 관리를 위임할 의사가 없다고 명확히 밝혔다. 그전까지 piquark6046와 fifoqueue 사이에 권한 범위를 둘러싼 오해가 있었다고 하더라도, 적어도 이 시점 이후에는 소유자의 입장이 분명해진 셈이다.
1차 분쟁 이후에도 왜 포크하지 않았을까?
바로 이 지점에서 가장 큰 의문이 남는다.
운영 방향이 그렇게 달랐다면 왜 1차 분쟁 직후 독립적인 포크를 만들지 않았을까?
List-KR은 오픈소스 프로젝트다. 라이선스가 허용하는 범위에서는 누구나 코드를 포크해 다른 정책과 운영 방식으로 발전시킬 수 있다. 기업이 포크를 기반으로 별도 제품이나 서비스를 운영하는 것도 가능하다.
구체적으로 List-KR의 package.json에는 라이선스가 GPL-3.0-only로 명시되어 있다. GPLv3는 수정과 재배포, 상업적 이용을 허용하지만, 수정본을 배포할 때는 변경 사실과 라이선스 고지를 유지하고 수정한 결과물도 같은 GPLv3 조건으로 제공해야 한다. 비소스 형태로 배포한다면 그에 대응하는 소스도 이용할 수 있게 해야 한다.
물론 이런 카피레프트 의무는 기업이 포크를 운영할 때 고려해야 할 조건이다. 다만 List-KR은 애초에 소스와 변경 이력이 공개된 오픈소스 프로젝트였고, 별도 포크 역시 공개 저장소로 운영할 수 있었다. 따라서 외부인이 단정할 수는 없지만, 소스 제공 의무가 독립 포크를 선택하기 어려울 정도로 큰 추가 부담이었을 가능성은 높지 않아 보인다. 적어도 라이선스 자체가 포크를 막는 장벽은 아니었다.
원 저장소의 소유자와 필터 정책이나 운영 방향이 맞지 않았다면, 별도 이름의 한국어 필터를 만들고 List-KR을 기반으로 했다는 사실을 밝힌 뒤 AdGuard의 정책에 맞게 운영할 수 있었다. 예를 들어 처음부터 AdGuard Korean Filter처럼 구분되는 이름과 배포 채널을 사용했다면 기존 List-KR의 소유권이나 공식성을 둘러싼 충돌은 훨씬 줄었을 것이다.
오픈소스에서 포크는 실패나 배신이 아니다. 하나의 프로젝트 안에서 해결하기 어려운 방향 차이가 생겼을 때 각자가 원하는 길을 갈 수 있게 하는 정상적인 선택지다.
결과적으로 piquark6046는 List-KR 기여를 중단했고, AdGuard 쪽에서는 별도 포크를 사용하게 된 것으로 보인다. 결국 포크가 해결책이 됐다면, 1차 분쟁 시점에 공식성을 명확히 분리한 포크를 선택했을 때 상당 부분 피할 수 있었던 갈등은 아니었을까 하는 생각이 든다.
포크의 자유와 원 프로젝트의 정체성
포크 자체에는 문제가 없다. 오픈소스 라이선스가 허용한다면 원 프로젝트의 동의 없이도 포크할 수 있다. 오히려 이것은 오픈소스가 보장하는 핵심적인 자유다.
하지만 코드를 포크할 권리와 원 프로젝트의 이름이나 공식적인 지위를 이어받을 권리는 같은 개념이 아니다.
새로운 프로젝트가 원본의 코드를 사용할 수 있다고 해서 자신을 원 프로젝트 그 자체로 소개할 수 있는 것은 아니다. 특히 기존 프로젝트와 동일한 이름, 도메인, 조직 명의나 주요 배포 경로를 사용한다면 사용자가 원본과 포크를 구분하기 어려워진다.
그래서 이번 논란의 핵심은 포크의 정당성보다 List-KR이라는 이름과 공식성을 누가 결정할 수 있었는가에 있다고 본다. 코드는 라이선스에 따라 공유되지만 프로젝트의 정체성과 대표성은 별도의 거버넌스 문제다.
실질적인 유지보수자의 입장도 생각해볼 필요가 있다
물론 piquark6046의 입장에서 이해할 수 있는 부분도 있다.
원 소유자가 프로젝트를 적극적으로 관리하지 않았던 기간 동안 오랫동안 실질적인 유지보수를 담당했다면 프로젝트에 강한 책임감과 주인의식을 느꼈을 수 있다. 자신이 대부분의 문제를 처리하고 배포 생태계까지 관리했다면, 운영 방향을 결정할 권한도 충분히 있다고 생각했을 가능성이 있다.
그러나 책임감과 공로가 크다는 사실이 소유권의 자동 이전을 의미하지는 않는다.
이 프로젝트를 내가 가장 많이 유지보수했다.
라는 주장과
그러므로 이 프로젝트가 어느 회사의 프로젝트인지, 누가 공식적으로 대표하는지를 내가 결정할 수 있다.
라는 주장 사이에는 큰 차이가 있다.
전자가 사실이어도 후자가 자동으로 성립하지는 않는다. 장기간의 유지보수로 운영 구조가 사실상 달라졌다면, 필요한 것은 암묵적인 소유권 이전이 아니라 역할과 권한을 명문화하는 합의였다고 생각한다.
공개된 기록을 어떻게 봐야 할까?
이슈에는 작성자의 주장만 있는 것이 아니라 관련 커밋, README 변경 내역, 이메일, 인프라와 배포 경로의 변화, 사건의 시간 순서가 함께 제시되어 있다. 따라서 단순히 한쪽의 감정적인 주장으로만 치부하기는 어렵다.
또한 이슈 작성자는 자신에게 불리할 수 있는 내용도 일부 인정한다. 프로젝트를 적극적으로 관리하지 않았던 시기가 있었고, piquark6046가 많은 실질적인 유지보수를 했으며, 이메일에서 공격적인 표현을 사용한 부분이 있었다는 점을 직접 언급한다.
이런 내용까지 포함한 설명이 커밋과 이메일의 흐름에 상당 부분 맞물리기 때문에, 공개된 자료만 놓고 보면 저장소 소유자가 왜 이 상황을 부당하다고 느꼈는지는 충분히 이해할 수 있다.
다만 공개 자료 대부분이 한쪽 당사자가 정리한 것이라는 한계도 분명하다. piquark6046나 AdGuard 측에서 공개하지 않은 맥락이 있을 수 있다. 따라서 확인되지 않은 동기를 단정하거나 개인에 대한 비난으로 이어가는 것은 피해야 한다.
오픈소스에서 우리는 무엇을 소유하는가?
이번 사건을 보며 다시 느낀 것은 오픈소스에서 다음 세 가지를 구분해야 한다는 점이다.
- 코드를 사용할 권리: 라이선스가 정한 범위에서 복제하고 수정하고 배포할 수 있는 권리
- 프로젝트를 운영할 권한: 저장소 병합, 릴리스, 정책 결정 등에 참여할 수 있는 권한
- 프로젝트의 소유권과 대표성: 이름, 공식 채널, 브랜드와 최종적인 정체성을 결정하는 지위
많은 기여를 한 사람의 공로는 존중받아야 한다. 실질적인 유지보수자에게 충분한 권한과 의사 결정 참여가 보장되는 것도 중요하다. 그러나 그 공로와 프로젝트의 소유권은 같은 것이 아니다.
운영 방향이 맞지 않는다면 포크할 자유가 있다. 그리고 그 자유를 행사할 때는 원본과 포크의 이름과 공식성을 명확히 구분하는 것이 사용자와 양쪽 프로젝트 모두에게 더 건강하다.
결국 이 사건에서 가장 이해하기 어려웠던 것은 포크가 가능했음에도 왜 기존 List-KR의 소유권과 공식성을 둘러싼 갈등까지 이어졌는가 하는 점이다.
어쩌면 이번 사건은 List-KR만의 문제가 아닐지도 모른다. 프로젝트를 처음 만든 사람과 가장 많이 유지보수한 사람이 다를 때, 그리고 기업이 핵심 기여자의 고용주로 등장했을 때 오픈소스 공동체가 역할과 대표성을 어떻게 합의해야 하는지를 보여주는 사례에 가깝다.
코드는 열려 있어도 프로젝트의 거버넌스가 저절로 정해지는 것은 아니다. 그래서 권한과 대표성에 대한 합의는 기여가 커질수록 더 일찍, 더 명확하게 이루어져야 한다.