▲

러그풀, 포크, 그리고 오픈소스 봉건주의

 (lwn.net)
9P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 오픈소스 생태계의 권력 역학이 기업·개발자·사용자 사이에서 어떻게 작동하는지, 그리고 이를 뒤흔드는 러그풀(리라이선싱)과 포크라는 전술의 영향에 대한 정리
  • 대형 클라우드 제공자가 큰 영향력을 행사하는 가운데, 단일 기업 중심 프로젝트는 재라이선스로 권력을 재배치할 수 있고, 이에 대한 대응으로 포크가 등장함
  • 사례 분석에서 Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey, Puppet→OpenVox 등 각기 다른 커뮤니티 재편과 기여자 이동 양상이 보임
  • CLA 채택, 단일 기업 지배, 재단 이관 시점 등은 러그풀 위험 신호로 제시되며, 중립 거버넌스와 다기관 기여층 확대가 대응 전략으로 권고됨
  • 결론적으로 재라이선스는 클라우드 견제 수단이 될 수 있으나 기여자 권한도 함께 약화시키며, 포크 가능성이 기업의 의사결정에 억제력으로 작용함

오픈소스 내 권력 구조와 러그풀, 포크

  • 오픈소스 소프트웨어 생태계에서는 대기업, 중소기업, 기여자, 사용자 등이 각자 소프트웨어 방향성과 수익 구조에 영향을 미치기 위한 권력을 행사함
  • 특히 대형 클라우드 제공업체가 상당한 힘을 가지게 되며, 소규모 회사나 커뮤니티보다 우위를 점하는 경향이 있음
  • 이러한 상황에서 개발사 또는 프로젝트 소유 기업이 소프트웨어 라이선스를 변경(러그풀) 하거나, 반대로 커뮤니티 또는 타기업이 포크를 진행하며 권력 이동이 발생함

권력 역학과 전술 개관

  • 오픈소스 세계에서 대형 클라우드 제공업체가 가장 강한 채널·배포 권력을 행사하며, 소규모 회사와 기여자, 사용자를 착취하는 구조 형성
    • 봉건주의 시대처럼 토지 통제와 유사하게, 클라우드 제공업체가 오픈소스 소프트웨어를 서비스화하면서 기여를 회피
    • 소규모 회사가 대부분의 개발 작업을 담당하나, 클라우드 제공업체의 무료 이용으로 인해 불리한 위치
  • 러그 풀 전술로 소규모 회사가 소프트웨어를 재라이선싱하여 클라우드 제공업체에 대응하나, 이는 기여자와 사용자에게 더 큰 피해 초래
    • 클라우드 제공업체가 프로젝트를 서비스로 전환하면서 기여를 하지 않아 소규모 회사의 권력 약화
    • 재라이선싱으로 사용자에게 불이익 발생, 그러나 포크를 통해 권력 균형 재조정 가능
  • 단일 회사 주도 프로젝트에서 러그 풀 위험이 높아, 회사 평판 평가가 필요하나 인수합병이나 파산으로 무용지물될 수 있음
    • 투자자 압력으로 수익 증대를 위한 재라이선싱 발생, 특히 클라우드 제공업체와 경쟁 시 더 빈번
    • 더 제한적인 라이선스로 타사 수익화를 어렵게 하여 권력 이동 시도
  • 러그 풀로 인한 포크 생성이 반란적 집단 행동으로 권력 회복 수단이나, 인력과 자원 부족으로 실패 위험이 큼
    • 대형 회사나 클라우드 제공업체가 자원으로 포크 지원 가능, 그러나 인기 포크가 항상 성공하지 않음
    • MongoDB나 Sentry 사례처럼 포크가 발생하지 않은 경우 존재, Perforce의 Puppet 인수 후 개발 비공개화로 OpenVox 포크 유발

주요 사례 비교

Dawn Foster는 다양한 러그풀, 포크, 그 이후의 영향을 데이터를 통해 분석함. (Jupyter 노트북 데이터셋으로 결과 일부 공개)

  • Elasticsearch → OpenSearch
    • 2021년 Elastic의 SSPL 재라이선스 이후 AWS가 OpenSearch 포크 조직함
    • Elastic은 사내 기여자 비중이 포크 전후 크게 변하지 않았고, OpenSearch는 Amazon 주도 기여가 지속되는 양상임
    • 2024년 Linux Foundation 이관 이후에도 외부 기여 급증은 관찰되지 않았다는 분석임
  • Terraform → OpenTofu
    • 2023년 HashiCorp의 BSL 전환 직후 OpenTofu가 Linux Foundation 아래 출범함
    • Terraform은 여전히 사내 중심 기여를 유지했으나, OpenTofu에는 여러 기업의 신규 기여자가 빠르게 유입됨
    • 본 사례는 사용자 주도 포크 + 중립 재단 출범이 활성 커뮤니티 형성에 유리했음을 시사함
  • Redis → Valkey
    • 2024년 Redis의 SSPL 전환 직후 기존 외부 기여자 다수가 Valkey로 이동함
    • Redis는 포크 전 외부 기여 비중이 높았던 예외적 케이스였고, 포크 후 외부 기여 0으로 급감, Valkey는 다수 기업 연합 커뮤니티로 출발함
  • Puppet → OpenVox
    • Perforce 인수(2022) 이후 개발·릴리스 비공개화와 릴리스 빈도 축소가 발생, 이에 대응해 커뮤니티가 OpenVox 포크를 추진함

데이터 관찰과 메트릭

  • 러그풀 이후 GitHub 포크 수 급증이 흔히 관찰되며, 이는 하드 포크 검토 움직임의 프록시 신호로 해석됨
    • 장기적으로는 원본과 포크가 병행 전진하는 경향이 있으나, 재라이선스된 원본은 사용량 감소 경향이 관측된다는 분석임
  • 재단 하 우산 출범은 신규 프로젝트 초기 기여 유치에 유리하나, 사후 이관은 효과가 제한적일 수 있음
    • OpenSearch 사례는 이관만으로 외부 기여 급증이 보장되지 않음을 시사함

위험 신호와 가이드라인

  • CLA(Contributor License Agreement) 사용은 기업에 재라이선스 권한을 집중시켜 권력 불균형을 확대하는 신호임
    • DCO(Developers Certificate of Origin) 기반 프로젝트는 상대적으로 러그풀 위험이 낮은 경향임
  • 거버넌스 점검이 필요하며, 단일 기업 지배와 리더십 편중은 리스크 요인
    • 중립 재단, 다기관 리더십, 외부 기여 저변을 갖춘 프로젝트가 지속가능성 측면에서 유리함
  • 기여자 기반의 폭과 심도 또한 핵심 평가 항목
    • 기업은 의존 프로젝트에 직접 기여자 파견으로 영향력·지속가능성 동시 강화 필요
    • CHAOSS의 메트릭·프랙티셔너 가이드는 프로젝트 건전성 진단·개선에 활용 가능함

커뮤니티·거버넌스 제언

  • 중립 거버넌스 체계로의 유도와 외부 기여자 확대가 러그풀 억제에 실질적 수단임
    • 포크 가능성 자체가 기업의 재라이선스 결정 비용을 높여 억제력으로 작동함
  • Hazel Weakly의 보호 장치 질의에 대해, 발표자는 Valkey·OpenTofu 성공이 재라이선스 재고를 유도한 실제 사례를 언급함
    • Dirk Hohndel은 더 많은 외부 기여자 유치가 러그풀 위험을 올려 경영 판단의 리스크를 키운다고 강조함

결론

  • 대형 클라우드 사업자 영향력이 커지면서 오픈소스 생태계가 점점 봉건주의적 구조로 변하고 있음
  • 라이선스 변경은 클라우드 업체의 힘을 견제하지만, 그 과정에서 커뮤니티 기여자 권한이 줄어드는 부작용이 생김
  • 그러나 기여자와 사용자에게는 '포크'라는 반격 수단이 존재, 이는 봉건시대와는 차별화되는 오픈소스 고유의 힘임
  • 포크의 실질적 가능성은 기업의 미래 정책 결정에 영향을 미치며, 실제로 Valkey, OpenTofu 성공 사례에 자극 받아 일부 기업이 러그풀 계획을 철회하기도 함
  • 궁극적으로 프로젝트의 거버넌스 중립성과 외부 기여자 활성화가 러그풀 방지와 건강한 생태계 유지를 위한 열쇠임

참고 자료

▲
ndrgrd 1일전  [-]

포크가 아직은 쉽지 않은 상황이라 오픈소스 관련 단체들 중에 이걸 도와주는 곳이 있었으면 좋겠네요.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • CLAs(Contributor License Agreement)를 사용하는 프로젝트는 rug pull(기여자의 노력이 소수에 의해 사유화되는 현상)이 더 자주 발생한다고 봄, 반면 DCO(Developers Certificate of Origin)를 쓰는 프로젝트는 이런 불균형이 덜함을 언급함. CLA를 서명하면 프로젝트에 내 기여 코드를 재라이선스할 권리를 주게 됨. 즉, GPL 프로젝트에 GPL 기여를 해도 라이선스 변경이 가능해짐. 이미 퍼미시브 라이선스라면 CLA에 큰 영향이 없지만, 카피레프트(예: GPL)라면 CLA 서명한 측만 독점적 소유가 가능해 불공정해짐. rug pull을 방지하려면 카피레프트 라이선스를 쓰고 CLA 서명을 피하는 게 좋음. 퍼미시브 라이선스는 rug pull이 '게임의 일부'임을 이해해야 함
    • GNU 프로젝트들도 CLA를 요구하지만, 이들이 rug pull을 할 의도로 그런 것은 아닐 것이라 생각함
    • CLA 서명이 무조건 재라이선스 권리 전체를 주는 것은 아니며, CLA마다 다름을 명확히 하고 싶음. 예로 Canonical의 CLA(링크) 조항에 따르면, 내 기여는 기존 라이선스대로도 제공할 것을 약속함. CLA 읽고 이해하는 게 중요함. 대부분의 CLA는 저작권을 기여자에게 남겨두므로, 내 기여로 하고 싶은 대로 할 권리가 남아있음. 근본 문제는 프로젝트 오너에 대한 신뢰가 깨질 수 있다는 것임. CLA는 오너에게 통제권을 부여해 rug pull 위험이 커짐. rug pull에 대처하려면 실질적으로 포크해서 직접 협업해야 이득을 얻을 수 있음. 카피레프트 라이선스에 CLA가 더해진 경우(예: AGPL + CLA)는 오히려 퍼미시브 라이선스 + CLA보다 더 해로울 수 있음. AGPL은 서비스 배포도 소스 공개 의무가 생기지만, CLA로 오너는 폐쇄형 서비스를 하면서 개선사항을 공개하지 않아도 되기 때문임. 실제로 Incus와 LXD 사례처럼 라이선스 조합과 CLA로 인해 커뮤니티 분열과 코드 공유 제한이 발생한 경험이 있음(상세 사례 글)
    • 오픈소스에서 rug pull이라는 현상은 존재하지 않는다고 봄. GPL 복사본은 영원히 존재함
    • 퍼미시브 라이선스를 쓰면 rug pull 가능성이 높긴 하지만, CLA가 언제나 모든 권리를 주는 건 아니라는 점을 지적함
    • "rug pull"이라는 부정적 담론을 오픈소스에서 과하게 순수주의적으로 보는 것은 건강하지 않다고 생각함. 프로젝트는 지속 가능해야 함. 대형 클라우드 사업자들이 인프라 독점한 상황에서, 작은 개발자들이 오픈소스 또는 CLA 기반 프로젝트에서 분쟁을 벌이는 것보다, 에너지를 대기업 독점 현상 완화에 쏟는 게 더 낫다고 봄
  • 컨트리뷰터와 메인테이너는 소규모 기업보다도 힘이 약한 경우가 많음. 그래도 리버럴 라이선스라면 불만족스러우면 포크해서 새로운 길을 갈 수 있음. Valkey 사례처럼 Redis와의 역동적인 라이선스 변화가 재미있음. 개발자 커뮤니티 전체적으로 요즘은 클라우드 제공 서비스에 안주하다 보니 과거처럼 OS, 컴파일러, DB 등을 새로 포크하거나 구현하는 적극성이 부족해진 게 문제라고 느낌. AWS 같은 클라우드 기업들이 서비스로 공급하면서 프로젝트 인지도를 높여준 점도 종종 간과됨(예: ElasticSearch가 AWS 제공 이후 인기). 클라우드가 커널, gcc, jdk 등에 기여함으로써 소규모 기업도 간접 이익을 얻음. 쉽게 대형 클라우드만 탓할 것이 아니라, 비즈니스 모델 자체를 다시 생각하면 좋겠음. 처음부터 폐쇄형으로 시작하면 아무도 신경 안 쓸 것임
  • 사용하는 소프트웨어를 바이너리로 받지 말고 소스코드로 직접 빌드하면, rug pull 같은 이벤트 때 대응력이 올라감. 벤더의 바이너리/이미지로 설치하는 사용자는 포크 전환이 힘들지만, 빌드 인프라를 새로운 소스로 전환하는 건 상대적으로 간단함. 필요한 수정이나 기능을 직접 반영해 쓸 수 있으니 유지보수 의존도가 줄어듦
    • Guix를 좋아하는 이유가 바로 이 구조임. 소스 빌드가 기본이고, 캐싱을 통해 바이너리 패키지도 제공됨. 바이너리가 없으면 직접 소스를 reproducible하게 빌드함. 패치 버전도 같은 패키지 매니저로 간단히 설치할 수 있어 빌드 인프라가 따로 필요 없음. 대규모 배포 환경이라면 빌드 서버를 두는 게 효율적임
    • 왜 반대표가 있는지 모르겠지만 동의함. 소스 빌드는 대체로 어렵지 않음(sqlite 참고)
    • 실제로는 소프트웨어 라이선스에 따라 제한이 다름을 짚어줌. 상용 소프트웨어 중에도 소스를 제공하지만 라이선스상 자유롭게 가공할 수 없는 경우가 많음. 예를 들면 스크립트 언어 기반 상용 제품, 혹은 기업 컨설팅에서 고객에게 소스 제공해도 컴파일 권한은 별도 비용을 내야 하는 사례가 있음
  • Elasticsearch의 rug pull 이후 Amazon이 직접 오픈소스 포크(OpenSearch)에 기여하게 된 모습은, 처음 의도와는 달라도 어느 정도 성과로 볼 수 있음. 그러나 대기업이 기여자와 수익자 간 불균형으로 프로젝트의 불안정성을 초래하는 것도 중요한 논의임
    • 라이선스 준수를 통한 소프트웨어 사용은 문제가 없으며, 오히려 개발자나 스타트업이 확산과 성장만 바라보고 퍼미시브 라이선스를 활용하다가, 대형 클라우드가 진출할 때 문제가 되는 것은 자기모순임. 두 마리 토끼를 모두 가질 순 없다고 봄
    • Elastic이 원한 결과는 더 많은 라이선스 매출이었지만, 많은 유저들이 포크로 전환해 Elastic 신뢰도 하락이 발생함. 오히려 OpenSearch와 ElasticSearch의 경쟁이 에코시스템에 긍정적일 수도 있으나, 이제 두 제품은 호환성이 깨졌고 Elastic의 입지도 약화됨
    • AGPL/GPL 같은 카피레프트 라이선스는 강제로 코드 기여를 요구하므로 독점 라이선스 없이도 피드백 루프를 형성할 수 있음
  • 오픈소스 프로젝트는 라이선스만 바꾼다고 rug pull이 쉬운 게 아님. 더 근본적 문제는 누구나 무료로 일해서도 충분한 삶의 질을 보장받을 수 있는 유토피아적 환경이 아니라는 현실임. 메인테이너 없으면 프로젝트 반감기가 짧을 수밖에 없고, 스폰서십 없는 한 폐쇄적인 라이선스로 이동이 가속화될 것임
    • Mojang/Microsoft와 Bukkit 커뮤니티 사례가 떠오름. 개발자 고용과정에서 프로젝트를 몰래 매입하고 자원봉사자가 수년간 무보수로 일하게 만든 끝에, 그가 DMCA를 이용해 프로젝트를 셧다운하게 됨. 더 자세한 사례: blog
    • 결국 인센티브 문제임. 직접 오픈소스 소프트웨어를 만들어도 클라우드사업자들이 손쉽게 가져가 돈벌이를 할 수 있음. FOSS(Fully Open Source Software) 라이선스 구조가 그런 의미라는 건 알지만, 사회가 너무 무상 노동에 익숙해졌다고 느낌. 그래서 점점 SSPL(Source-available licensing) 같은 새로운 방식이 매력적일 것 같음. 조항 하나 차이로 AGPL은 foss, SSPL은 foss 아님이란 건 용어 혼란이라고 느낌
  • rug pull에 속상해하는 사용자 입장을 이해하지만, 실제로 프로젝트를 주도적으로 개발·유지하는 회사도 재정적 한계가 있어 몇 가지 선택지만 남게 됨. 수익 모델이 없으면 라이선스 변경도 불가피함. 대안으로 크라우드펀딩, 작업량 축소, 굿즈 판매, 추가 자금이 없으면 오픈하게 변경 예고 등 경우의 수를 고민 중임. 관련 글
    • 불만의 본질은 OSS로 공개했다가 사용자를 늘린 후에 돌연 라이선스를 폐쇄적으로 바꿨기 때문임. 처음부터 OSS가 아니었다면 배신감도 없었겠지만, 유저 유입을 위해 OSS로 시작하다가 나중에 변경한 게 문제임
    • Mongo, Elastic, Redis, Hashicorp 등은 rug pull 시점에도 커다란 재정난은 아니었음. Hashicorp의 경우 인수 가치 올리기 전략이었을 수도 있음
  • 최근에는 거버넌스 보드 조직, 규제가 강화된 운영 방안 등을 내세워 기술자들이 자진해서 빠지도록 유도한 뒤, 반대 의견을 억압하고 프로젝트 권한을 취소하는 사례가 늘어남. 실제로 '안전성'을 내세운 오웰적인 분위기가 커뮤니티에 도입되고 있음
  • 거의 모든 오픈소스 사용자는 프리라이더임. 우리는 프로젝트에서 아무런 기여도 하지 않으면서 자유롭게 사용하고 있음. 오픈소스는 대가 없는 선물, 혹은 남의 숙제를 참고하는 문화로 볼 수 있음. 세상에 기여하고 싶으면 기꺼이 하되, 어떤 보상도 기대하면 안 됨. 라이선스 변경 때문에 rug pull이라고 표현하는 것도 편향된 시각임. 어쨌든 우리는 이미 코드를 받았고, 방향성이 바뀐 것이 불행하긴 해도, 세상 모든 것은 영원하지 않음
    • "우리는 대부분 돌려주는 것 없이 사용한다."라는 주장은 완전히 사실은 아님. 실제로 많은 프로젝트에서 코드, 테스트, 문서, 마케팅, 전도 등에 다방면의 기여가 있었음. 이런 프로젝트들은 GitHub에 우연히 올라온 조용한 개발물이 아니라, 회사가 많은 돈을 들여 적극적으로 개발자 전도사(에반젤리스트)를 고용해 기술·라이선스의 장점을 알리고 유저 풀 확대에 힘써왔음. 이런 환경에서 대규모로 코드와 기여를 받아놓고, 갑자기 라이선스를 변경하고, 타 FOSS 프로젝트들이 의존하고 있을 때 그 약속을 파기하는 게 rug pull이라는 비판임. 만약 별도 마케팅 없이 GitHub에 우연히 올라와 자연스럽게 채택된 프로젝트라면 rug pull 논란 대상이 아닐 것임. 하지만 그런 사례는 거의 본 적 없음
    • 반드시 그래야 하는 구조는 아니라고 봄. 기업이나 자금력이 있는 주체들이 자신이 의존하는 오픈소스 프로젝트에 재정적·기술적 기여를 하며 지속성을 높일 수 있음. Open Source Program Office 설립, 사용하는 모든 소프트웨어와 의존성 분석, 기여자 시간 투자와 자금 후원, 동종 업계에도 이런 문화 독려 같은 방법들이 있음
  • 현재 근무 중인 회사에서도 rug pull 이슈로 인해 운영진이 혼란스러워함. 항상 시스템에 대한 지원 계약을 고집해왔지만, Chef, CentOS, VMWare, Broadcom 등에서 비슷한 상황이 반복됨. 비용을 내고 쓸 계획이었는데도 유지보수 기본 서비스가 연간 수천~수만 달러에 다다르고, 그래도 신뢰가 안 됨. 이런 상황이라 차라리 재단을 후원하거나, 정기적으로 OSS 메인터이너를 직접 고용하는 게 낫다고 느껴짐. 예전엔 그런 제안에 냉소적이었지만, 점점 호응이 커지고 있음. 개인적으로라면 VMWare에 비용 지불보다 Proxmox 혹은 qemu 개발자를 고용하겠음
    • 올바른 아이디어라고 생각함. 사용하는 모든 소프트웨어와 의존성을 점검하고, 개발 시간·자금 기여를 통해 지속 가능성을 보장하고, 동종 업계에 이런 태도를 확산시키는 것이 중요함
    • 흥미롭게도, 거론된 기업들은 커뮤니티 중심적으로 하기 위해 오픈소스 프로그램 오피스를 만들었지만, 조직이 너무 커지면 이중성(커뮤니티와 기업 이익간 괴리)이 발생하는 것이 당연한 대가라고 느낌
  • 포크는 쉬운 일이 아니고, 사람과 자원이 있어야 성공함. 오픈소스는 결국 기여자가 많을 때만 작동하는 구조임. 만약 포크가 죽는다면, 그 프로젝트에 프리라이더가 너무 많았다는 뜻임. rug pull에서 가장 큰 문제는 사실상 허위광고라고 생각함. 오픈소스로 고객을 모은 후, 자신에게 불리해지자 그 약속을 파기해서 도덕적으로 문제가 있음. 그러나 기여 중단 자체는 걱정되지 않음. 누구도 영원히 프로젝트에 남을 의무는 없으므로, 개인이나 회사가 중단하는 것도 자연스러운 현상임
답변달기