본문으로 가기

오픈소스 SW동향

오픈소스SW 동향 상세
[해외법률자료] RHEL(Red Hat Enterprise Linux) 비즈니스 모델의 GPL 문제 종합 분석
  1. 작성일 :
  2. 2024.01.18
  3. 작성자 :
  4. 박준석
  5. 조회수 :
  6. 227

RHEL(Red Hat Enterprise Linux) 비즈니스 모델의 GPL 문제 종합 분석
A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model


by Bradley M. Kuhn on June 23, 2023


이 글은 주로 IBM의 Red Hat이 RHEL에 대한 완전한 대응 소스(CCS)의 공개를 중단하고 CentOS Linux를 종료하는 변화에 대한 반응으로 작성되었습니다(이 두 사건은 아래에서 설명하겠지만 서로 연관되어 있습니다). 이 문서가 Red Hat의 RHEL 비즈니스 모델, 관련 소스 코드 공개, 그리고 RHEL의 GPL 준수 이슈에 대한 포괄적인 토론서로서의 역할을 수행하길 바라며 이를 작성하였습니다.
약 20년 동안, Red Hat(현재는 IBM이 완전 소유한 자회사)은 소유권을 가진 것처럼 느껴지고 작동하는 운영 체제의 배포 및 유통에 대한 비즈니스 모델을 실험해왔습니다. 이 모델은 GPL과 기타 표준 라이선스 조건을 준수하고 있습니다. SFC를 포함한 소프트웨어 권리 활동가들은 수년 동안 Red Hat과 그들의 변호사들과 논의하며, Red Hat Enterprise Linux(RHEL)의 비즈니스 모델이 재앙을 초래하고, 커뮤니티 지향적인 자유 소프트웨어 및 오픈 소스 소프트웨어(FOSS)에 대해 적극적으로 불친절하다고 주장해 왔습니다. 이러한 호소, 토론, 그리고 격려는 Red Hat의 법률과 OSPO 부서의 핵심 인원들, 심지어는 고위 임원들에게도 전달되었으며, 그들은 이에 대해 심각하게 고려하였습니다. 그러나 그들은 결국 이를 무시하고 거부하였으며, 때로는 "만약 그렇다면, GPL 위반으로 우리를 고소하라"는 태도를 보였습니다. 활동가들은 이러한 논의를 불편하게 느꼈지만, 우리 모두가 Red Hat의 행동이 개선될 것이라는 희망을 갖고 있었기 때문에, 이러한 논의의 성격과 진행을 지금까지는 "오픈 비밀"로 유지해 왔습니다. 그러나 최근의 사건들은 상황이 단순히 악화되고 있으며, 아마도 더욱 악화될 것임을 보여줍니다.

RHEL 비즈니스 모델이 정확히 무엇입니까?
RHEL의 비즈니스 모델은 다음과 같이 간결하게 설명할 수 있습니다. IBM의 Red Hat은 고객에게 RHEL 복사본을 제공하고, 이 복사본에는 지원과 자동 업데이트 구독 계약이 포함됩니다. 우리의 이해에 따르면, 이 계약은 고객이 소프트웨어를 원하는 만큼 복사, 수정, 재배포 및/또는 재설치할 수 있는 권리를 제한하지 않음을 명확히 언급하고 있습니다(§1.4 참조). 그러나 계약에는 고객이 이러한 활동을 수행하게 되면, Red Hat이 해당 계약을 취소하고 고객에게 더 이상 서비스를 제공하지 않을 수 있다는 조항도 포함되어 있습니다. 기본적으로, Red Hat은 고객에게 (a) 소프트웨어의 자유와 권리와 (b) Red Hat 고객으로서의 지위 중에서 선택하도록 요구합니다. 또한, 저희가 검토한 일부 계약 버전에서는 Red Hat이 고객의 RHEL 복사본 수(§10 참조)를 "검토"(사실상 BSA 스타일의 감사)할 권리를 갖고 있음이 명시되어 있습니다.
Red Hat의 변호사들은 이 비즈니스 모델이 GPL을 준수하고 있다고 주장하고 있습니다(그러나 우리는 그것에 대해 완전히 확신하지는 못합니다). 이들의 주장은 GPL 계약의 어떤 조항도 특정 주체가 다른 주체와 비즈니스 관계를 유지하도록 요구하지 않기 때문입니다. 또한, 이들은 비즈니스 관계가 GPL 계약에 의해 보장된 권리를 행사하는 것을 포함한 모든 행동에 따라 해제될 수 있다고 주장했습니다. 이러한 분석이 정확한지에 대한 논의는 여전히 치열하게 이루어지고 있으며, 이 특정 문제에 대한 항의를 제기한 법원 판례만이 GPL 계약에 따른 부적절한 행위가 허용되는지에 대한 결정적인 답변을 제공할 수 있습니다. 이 모델이 GPL을 위반하는지 아닌지에 대한 논의는 GPL 전문가들 사이에서도 여전히 진행 중입니다. 그러나 이 모델이 GPL 계약의 정신과 부합하지 않는다는 것은 분명합니다. RHEL 비즈니스 모델은 비호감적이며, 완고하며, 변덕스러우며, 분명히 논란의 여지가 있습니다.
또한, 이 RHEL 비즈니스 모델은 우리가 알고 있는 한 소프트웨어 산업에서는 상당히 독특하게 남아있습니다. IBM의 Red Hat이 지난 20년 동안 "아마도 GPL을 위반하지 않을 것"이라는 모호한 영역에서 대부분의 시간을 보냈다는 점은, 이 비즈니스 모델을 신중하게 구축한 그들의 노력을 인정해주어야만 합니다.

RHEL 비즈니스 모델이 GPL 계약을 위반합니까?
아마도 GPL을 피해갈 수 있는 모호한 비즈니스 모델의 가장 큰 문제점은, 위반사항이 생길 수 있고 실제로 발생한다는 점입니다. 이는 비즈니스 모델에서의 가벼운 벗어남 조차도 명백하게 GPL 계약을 위반하기 때문입니다. IBM이 Red Hat을 인수하기 전, Red Hat은 2006년 이후 RHEL 비즈니스 모델과 관련된 문서화된 GPL 위반 사례가 두 건뿐이었다는 점에서 SFC는 그들에게 어느 정도의 공을 인정하고 있습니다. 이 비즈니스 모델이 얼마나 쉽게 규정을 넘어설 수 있는지 설명하기 위해, 이러한 위반의 일반적인 상황을 공유하려 합니다.
첫 번째 위반 사례는, 대형 Fortune 500 기업이 내부적으로 RHEL을 사용하면서 리눅스 기반의 대중적인 제품을 개발하고 있는 상황입니다. 이 기업(이하 '회사 A'라 칭하겠습니다)은 주로 CentOS Linux를 기반으로 한 소비자용 제품(이하 '제품 P'라 칭하겠습니다)을 만들기로 결정했습니다. 그러나 제품 P는 RHEL 소스로부터 빌드된 일부 패키지를 포함하고 있었습니다. 회사 A는 이 별개의 제품 P에 대한 추가 지원이나 업데이트 서비스를 찾거나 요청하지 않았습니다. Red Hat이 후에 제품 P가 RHEL의 일부를 포함하고 있다는 것을 알게 되자, Red Hat은 제품 P에 대한 로열티를 요구했습니다. 또한, 이 로열티가 지불되지 않으면, 회사 A의 내부 RHEL 서버에 대한 지원과 업데이트 서비스를 중단하겠다고 위협했습니다.
회사 A는 강력한 법률 팀과 능숙한 비즈니스 개발 팀을 보유하고 있었기 때문에, 그들은 양보하지 않았습니다. 회사 A는 결국 내부 서버에 대한 RHEL 고객으로 계속 활동하며, 로열티 지불 없이 제품 P를 계속 판매했습니다. 그러나 이 로열티 요구는 GPL이 부여한 권한에 대한 "추가적인 제한"을 생성하므로 명백한 위반이었습니다. GPLv3에는 다음과 같이 명시되어 있습니다:
"당신은 이 라이선스에 따라 부여되거나 확인된 권리의 행사에 대해 추가적인 제한을 부과할 수 없습니다. 예를 들어, 당신은 이 라이선스에 따라 부여된 권리의 행사에 대해 라이선스 비용, 로열티 또는 기타 요금을 부과할 수 없습니다." 이 상황에서 Red Hat은 추가 제한을 시도했으며, 그로 인해 GPL을 위반했습니다. 로열티가 지불되지 않았고, 회사 A가 어떠한 불이익도 겪지 않았기 때문에 이 위반은 해결되었습니다. SFC는 이 사건을 뒤늦게 알게 되어, Red Hat에게 이전의 로열티 요구가 위반이었다고 알렸습니다. Red Hat은 이것이 위반이라는 주장에 대해 이의를 제기하거나 동의하지 않았으나, 향후 이런 식의 요구를 하지 않겠다는 데는 비공식적으로 동의하였습니다.
또 다른 위반 사례에서는 우리가 미국 이외의 특정 국가에서 Red Hat이 RHEL 시스템의 사용량을 줄이는 모든 고객에게 추가 계약에 서명하도록 요구하는 것을 알게 되었습니다. 이 추가 계약에서 고객은 현재 Red Hat과 서비스 계약이 체결된 RHEL 복사본을 제외하고, 전체 조직에서 모든 RHEL 복사본을 삭제하였음을 약속했습니다. 그러나 GPL 계약은 사용자에게 원하는 만큼의 소프트웨어 복사본을 생성하고 보유할 권리를 무제한으로 부여하며, GPL에 따라 라이선스를 받은 소프트웨어의 배포자는 사용자가 합법적으로 얻은, GPL 라이선스를 받은 타사 소프트웨어의 복사본을 삭제하였음을 증명하도록 요구할 수 없습니다. SFC는 이 위반 사항을 Red Hat의 법률 팀에 알렸고, 이 추가적인 합의가 더 이상 어떤 Red Hat 고객에게도 제시되지 않을 것이라는 보장을 받았습니다.
이 두 사례에서 SFC는 이들이 "빙산의 일각"일 수 있다는 우려를 표현했습니다. 수년 동안 우리는 혼란스러워하는 Red Hat 고객들의 이야기를 들었습니다. 업계에서는 RHEL '시트 라이선스'에 대한 이야기가 일반적이며, 많은 소프트웨어 구매 전문가들이 RHEL 비즈니스 모델의 미묘한 부분을 인식하지 못하고, 이에 따른 권한을 제대로 이해하지 못합니다. 우리는 RHEL 영업 직원들이 더 많은 '시트 라이선스'를 판매하기 위해 고객들을 고의적으로 혼란스럽게 만드는 것을 우려하고 있습니다. "만약 숲에서 GPL 위반이 일어났는데 관련된 모든 사람이 그것을 듣지 못한다면, 그 위반으로 인해 소프트웨어 권한이 실제로 침해되었다는 사실을 누가 알 수 있을까요?" 우리는 접수된 RHEL 관련 GPL 위반 사례를 열심히 조사하고, 가능한 한 많은 GPL 위반을 처리하기 위해 노력하고 있습니다. 만약 위반 사항을 알고 계시다면, 바로 compliance@sfconservancy.org로 이메일을 보내주시기 바랍니다. 우리는 많은 RHEL 영업직원과 비즈니스 개발 전문가들이 무지나 악의로 인해 GPL을 정기적으로 위반하고 있을 수 있으며, 이 사실을 아무도 알아채지 못할 수 있다는 우려를 가지고 있습니다. 다시 말해, IBM의 Red Hat이 설명하는 비즈니스 모델이 GPL을 잘 준수할 수 있지만, 우리의 경험으로는 이 모델을 아무 방향으로든 수정하는 것은 확실히 위반으로 이어질 것 같습니다.
또한, Red Hat은 역사적으로 'caveat emptor'라는 고전적인 접근법을 많은 애매모호한 비즈니스 거래에서 활용해 왔습니다. 엄밀히 말해 GPL과 RHEL 계약을 주의 깊게 읽는 사람들은 그들이 체결하는 계약을 이해할 수 있지만, 대부분의 소규모 기업들은 이러한 거래를 진정으로 이해하기 위해 필요한 FOSS 라이선싱에 대한 통찰력과 지식을 갖추지 못하고 있을 것입니다.

독립적인 CentOS가 왜 그렇게 중요했습니까?
2014년 초에 Red Hat이 CentOS를 "인수"하기 전까지, CentOS는 RHEL 비즈니스 모델의 문제에 대해 탁월한 대안을 제공했습니다. 구체적으로, CentOS는 커뮤니티 주도 프로젝트로, 많은 자원봉사자들이 참여하였고, 소규모 기업들의 일부 참여를 통해 RHEL용으로 만들어진 CCS 릴리스를 재구성하기 위해 사용하였습니다. 2014년 이전에는 CentOS를 RHEL 비즈니스의 "탄광의 카나리아"로 봤습니다. 만약 CentOS가 살아 있고, 사용 가능하며, Red Hat의 업데이트와 서비스를 구매하고 싶지 않은 사람들에게 RHEL에 대한 실질적인 대안으로 보인다면, 커뮤니티는 안심할 수 있습니다. Red Hat이 RHEL에서 GPL을 위반하더라도, CentOS의 활력은 이러한 위반들이 RHEL 코드베이스를 둘러싼 FOSS 커뮤니티에 단지 미미한 부정적 영향을 미치고 있다는 것을 확신시켰습니다.
그러나 Red Hat은 이 활발한 커뮤니티가 그들의 이익에 해가 될 수 있다는 것을 명확하게 인식하였습니다. 2013년부터 Red Hat은 그들의 영향력을 확대하기 위한 일련의 조치를 시작했습니다. 첫째로, 그들은 CentOS를 "인수"하였습니다. 이것은 처음에는 협력적인 관계로 보였지만, Red Hat은 CentOS의 주요 자원봉사자들에게 거절할 수 없는 일자리 제안을 하고, CentOS를 제품화하는 소규모 기업들을 인수하거나, 그렇지 않으면 CentOS를 Red Hat의 자체 운영에 통합하였습니다.
IBM이 Red Hat을 인수한 후에 상황은 더욱 악화되었습니다. "인수"의 일환으로 CentOS 브랜드에 대한 권리를 얻게 된 Red Hat은 CentOS의 본질을 점차 바꾸기 시작했습니다. CentOS Linux는 RHEL의 검증 및 안정화 역할을 포기하고, RHEL의 테스트 베이스로 전환되었습니다. 2020년, 대다수가 COVID-19 팬데믹으로 인해 산만해져 있을 때, Red Hat은 모든 CentOS Linux 개발을 일방적으로 중단하였습니다. 그 후에 (2021년 말, 코로나19 델타 변이가 유행하던 시점), Red Hat은 CentOS Linux를 완전히 폐지했습니다. 그 후 IBM의 Red Hat은 "CentOS Stream"이라는 이름으로 RHEL과 관련된 실험적인 소스 패키지를 참조하게 되었습니다. 이 패키지들은 실제로 RHEL 소스 릴리스가 아니었고, 주로 RHEL에 나중에 통합될 가능성이 있는 기능을 테스트하는 용도로 사용되었습니다.
최근에 Red Hat은 RHEL CCS가 더 이상 공개적으로 제공되지 않을 것이라고 발표했습니다. GPL 계약은 Red Hat이 CCS를 모두에게 공개할 의무가 없다는 점을 명확히 합니다. 이는 GPL의 요구사항에 대한 흔한 오해입니다. CCS 제공의 세부 사항은 GPL 계약의 버전에 따라 다르지만, 일반적인 원칙은 CCS가 (a) 바이너리 배포를 받는 사람에게 제공되거나 (b) 소스에 대한 서면 요청을 한 사람에게 제공되어야 한다는 것입니다. 일반적으로, 완화할 수 있는 요인이 없는 상황에서, 회사가 CCS를 모두에게 공개적으로 배포하는 것에서 이미 바이너리를 받은 고객에게만 제공하는 것으로 전환한다는 사실은 우려스러울 수 있습니다.
그러나 이런 상황에서, 이는 마치 Red Hat이 10년 동안 진행해온 계획의 정점에서, RHEL이 GPL 계약을 준수하는지 '신뢰하되 확인하자'라는 커뮤니티의 노력을 막아버리는 것으로 보입니다. 즉, 이것은 Rocky Linux와 Alma Linux와 같은 조직들에게 큰 타격을 입혔습니다. 이들은 사실상 지난 10년 동안 Red Hat이 천천히 분해해온 CentOS Linux 프로젝트의 사실상의 계승자들이었습니다. 이들 조직들은 RHEL 릴리스를 기반으로 한 Linux 배포판을 만들려 했는데, 이제는 Red Hat이 까다롭게 그들에게 합리적인 가격으로 RHEL 서비스 및 업데이트의 '좌석 라이선스'를 판매하는 것을 거부함으로써, 그들이 그것을 효과적으로 수행할 수 있을지 여부는 알 수 없게 되었습니다. 이번 주에는 적어도 RHEL CCS에 적시에 접근하려면 그렇게 해야 하는 것으로 보입니다.

소프트웨어 권한에 관심이 있는 사람들은 RHEL에 대해 어떻게 해야 합니까?
IBM의 Red Hat이 계속해서 부적절한 행위를 해왔기 때문에 상황이 점점 더 복잡하고 난해해졌습니다. 필수적인 서비스 계약을 잃을까 두려워하는 고객들 때문에 어떤 제3자도 RHEL이 GPL 계약을 제대로 이행하고 있는지 효과적으로 감시할 수 없게 되었습니다. Red Hat의 법무 부서는 최근 수년 동안 SFC가 요청한 모니터링 형식을 설정하는 것을 일관되게 거부해 왔습니다. (예를 들어, 우리는 RHEL 판매원들이 고객들을 설득하여 RHEL을 구매하도록 만드는 교육 자료와 문서를 검토하려 했지만, Red Hat은 이러한 자료를 우리와 공유하려 하지 않았습니다.) 그러나 SFC는 GPL 준수에 대한 세계적인 감시기관으로서, 우리는 RHEL 관련 위반 사항에 대한 보고를 환영합니다.
우리는 이렇게 긴 여정이 FOSS 커뮤니티를 실망스럽게 만든 것에 대해 유감을 표합니다. 개인적으로 1990년대 후반 USENIX 컨퍼런스에서 Red Hat 부스에서 Erik Troan과 같이 있었던 것과, 그와 비슷한 시기에 Bob Young을 만난 것을 생각하면 매우 아쉽습니다. 그들은 FOSS 커뮤니티의 다양성을 이루는 개인들, 취미가, 그리고 소규모 사업체들을 존중하고, 협력하고, 참여하고, 무엇보다도 공정하게 대하고자 하는 회사를 만들고자 했습니다. 우리는 현재의 Red Hat이 IBM의 관리 아래에서 다시 이러한 원칙에 회귀하길 희망합니다.


[원문출처] https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/

※ 소프트웨어자유단체(https://sfconservancy.org/)에 의해 작성된 이 저작물은 크리에이티브 커먼즈 저작자표시-동일조건변경허락 4.0 국제 라이선스에 따라 이용할 수 있습니다.

  1. 첨부파일
이전글, 다음글
이전글 [해외기사] 美, 소프트웨어 공급망 보안 규제 현실화
다음글 [국내기사] 생성형 AI로 신년 축하 이미지 만들어 보니

목록