CentOS는 RedHat의 비즈니스에 해가 될까요? 득이 될까요?

권순선의 이미지

/.CentOS와 관련해서 재미있는 기사가 떴는데, 과연 CentOS가 RedHat의 비즈니스에 해가 되는지, 아니면 득이 되는지 이야기하는 것입니다.

CentOS는 상용으로 판매하고 있는 RedHat Enterprise Linux에서 제공하는 Source RPM을 활용하여 RedHat의 트레이드마크 등 재배포가 금지되어 있는 부분만을 제외한 RHEL의 클론을 제공하는 프로젝트입니다. CentOS를 사용하면 RHEL이 소비자에게 과금하는 서비스의 핵심인 소프트웨어 업데이트까지도 RHEL과 몇 시간/며칠 차이를 두고 그대로 이용할 수 있습니다. 사용자 입장에서는 CentOS가 RHEL과 거의 동일한 셈이죠. 따라서 이런저런 이유로 인해 CentOS는 RHEL의 비즈니스에 해가 된다는 주장과 그렇지 않다는 주장이 엇갈리고 있는데 여러분의 생각은 어떻습니까?

그리고 CentOS에 대한 RedHat의 공식적인 입장은 그동안 본 적이 없는 것 같은데 혹 이 부분에 대해서도 아시는 것이 있으면 좀 알려 주시면 감사드리겠습니다.

댓글

lacovnk의 이미지

오픈소스 또는 리눅스의 주요한 비즈니스 사업 케이스인데.. 이런 논란의 대상이 되니 기분이 묘하군요 :) 믿는 도끼에 발등 찍힌다... 와 조금 비슷하게.

간단히 드는 의문은 다음과 같습니다.

1. 해가 되면 어쩔껀데? - Redhat이 취할 수 있는 행동이 있을까요?

2. "책임"을 위해서 RHEL을 이용하는 경우가 있는데.. 만일 제가 CentOS와 별도로 RHEL SRPM을 재패키징해서 "좀 덜 안정적이지만 CentOS보다는 책임을 져주겠다"는 상용 서비스를 하면.. Redhat은 어떻게 반응할까요? 시장은 존재할테고..

3. 제가 CentOS의 일부분을 바꾸어서 상용 배포판을 만드는 것이 가능한가요? RHEL을 재패키징 하는 과정이 라이센스로 보호될 수 있는 것일까요?

권순선의 이미지

1. redhat이 centos의 존재 자체를 흔들 수 있는 방법은 지금까지 누구에게나 공개해 왔던 srpm을 고객에게만 공개하는 것으로 정책을 바꾼다면 가능할 것입니다. 물론 centos개발자 중 일부가 rhel의 정식 고객이 되어 srpm을 받아서 그것을 다시 외부에 공개하는 것 역시 문제 없습니다만 이것 말고도 redhat이 간편하게(?) 빌드할 수 있는 srpm 대신 소스 그 자체만을 공개하는 식으로 바꾸는 것도 가능하나 현재로서는 그렇게 하지 않고 있으므로 이는 redhat도 centos를 용인(?)하거나 혹은 자체적으로 자신들의 비즈니스에 해가 되지 않는다/도움이 된다 고 판단한 것이 아닌가 하는 생각이 듭니다. 어쨌거나 전통적인 지적재산권의 개념을 가진 기존 기업의 입장에서 본다면 redhat의 이러한 정책(누구에게나 srpm 공개)은 이해하기 어려운 일임에 틀림 없습니다.

2. 소규모라면 문제 없습니다. redhat은 아마 그다지 크게 신경쓰지 않을 것입니다. 그러나 만약 그런식의 비즈니스가 자신들의 비즈니스보다 더 큰 규모가 된다면 1번에서 이야기했던 여러가지 정책 변경을 검토해 보겠지요.

3. 패치나 패키징 시스템이 전통적으로 소스코드에 적용되는 저작권의 개념을 그대로 따라간다고 보기는 좀 애매한 부분이 많습니다. 라이센스 상에서 엄격한 해석은 매우 다양한 논란의 여지가 있으나 상용 배포판을 만드는 것이 가능한가? 하는 질문에 대해서는 '가능하다'라고 간단히 답할 수 있겠습니다. 왜냐하면 redhat의 fedora를 기반으로 한 수많은 상용 배포판들이 이미 널려있고 1,2에서 적은 대로 redhat의 비즈니스와 상대가 되지 않는 규모라면 오히려 시장을 함께 키우는데 일조할 수 있으므로 redhat이 이를 문제삼지는 않을 것입니다. redhat이 그냥 마구 퍼주는 것 같지만 라이센스를 모두 지키면서도 1번에서 이야기한 여러가지 방법들을 통해 효과적으로 그러한 상황을 control하고 경쟁자들이 free ride하는 것을 막을 수 있기 때문입니다.

1,2,3에서 이야기한 것과 매우 비슷한 상황이 얼마전에 oracle에서 rhel을 재패키징해서 oracle 리눅스 배포판을 만들겠다고 했던 것일텐데 oracle과 같은 거대 sw 기업이 그러한 시도를 했음에도 redhat은 srpm의 공개 정책을 변경하지 않았습니다. 저는 개인적으로 그때 redhat이 어떠한 정책 변화를 가져오지는 않을까 하고 내심 궁금했었는데 역시 그냥 기존 정책을 그대로 밀고 나가더군요. 이는 redhat이 고객들에게 제공하는 서비스와 기술력, 그리고 그동안 쌓아온 브랜드 파워에 대한 신뢰와 자신감이 없다면 불가능하였을 것입니다. 그런 점에서 저는 개인적으로 redhat이 더 잘 되어서 오픈소스 비즈니스의 좋은 케이스가 될 수 있기를 바랍니다.

묵검추의 이미지

시도가 아니라 오라클에서는 이미 그러한 형태로 서비스를 진행하고 있지요.. 물론 파트너 관계이지만 레드햇 배포판으로 자사의 이름 붙은 리눅스 배포판을 만들고 훨씬 저렴한
가격에 서비스를 진행하고 있습니다.
아직 우리나라 영업하는 분들은 rhel 을 권해주지만은요
http://www.oracle.com/technologies/linux/index.html

kihlle의 이미지

기업의 입장에서 적어도 비용문제로 RHEL대신 CentOS를 도입할 곳은 아마도 (국내에는) 없을것으로 생각합니다.
오히려 엔지니어들의 저변확대에 도움이 될거 같습니다.

ps2.
RHEL을 다른 방식으로 구현(?)하는 것은 예전의 whitebox배포본을 포함하여 여러가지 시도가 있었던 것으로 알고 있습니다. 지금쯤 다들 어떻게들 먹고사는지...

homeless

익명 사용자의 이미지

CentOS가 RedHat에게 해가 되지 않고 오히려 저변확대에 도움이 된다면
RedHat이 직접 ftp버젼을 발표해도 되지 않을까요?

오히려 RedHat이 "RHEL과 Fedora"로 정책이 바뀌면서
아직도 RedHat 9을 RedHat Linux라면서 사용하는 부작용만 낳은듯합니다.

권순선의 이미지

꼭 그렇지만은 않습니다. redhat은 fedora가 있는데 굳이 rhel의 또다른 버전을 제공해야 할 이유가 없으며 지금의 rhel / fedora 라인업이 적당하다고 봅니다. 다만 예전 기억을 더듬어 본다면 rhel이 windows vista 처럼 다양한 버전이 존재했었던 것 같은데 vista처럼 마케팅에 많은 투자를 하지 않을 것이라면 rhel의 버전과 가격정책도 최대한 단순화하는 것이 어떨까 합니다. 그리고 redhat은 rhel만으로 계속 어필하기는 힘들고, jboss나 database 등 개별 sw 로도 어떻게든 수익 모델을 확립하고 단순히 os 벤더에서 종합 솔루션 제공 업체로 포지셔닝하려고 하고 있으므로 rhel과 같은 os 그 자체에 그다지 많은 신경을 쓰는 것보다는 다른 솔루션들에 대한 마케팅 노력이 더 필요할 것입니다. 그리고 redhat 9과 같은 구버전들은 어차피 redhat이 현재 공식적으로 지원하는 것도 아니고 rhel이 목표로 하고 있는 시장/고객과도 거리가 있기 때문에 redhat 9이 rhel의 시장/고객을 잠식한다고는 생각하지 않습니다.

다즐링의 이미지

엔지니어에 따라 다르겠지만..

본인이 책임질수 없는 미묘한 부분을 책임져주는 것이 rhel입니다.
저라면.. 대부분의 시스템은 centos 코어는 rhel을 구매합니다.
(디비라던가.. )
물론.. 시스템이 크래쉬나거나 한다고 해서.. rh를 콜해서
답이 오지는 않겠죠 -_-;;; 대형고객이 아니라서..

서로 윈윈하는 관계가 되는거죠.

요즘 우분투 서버를 잘 애용하는데..
서포트업체가 생긴다면.. 정말 -_-;; 좋을듯합니다.
OS는 공짜 서포트는 비용을 받고..
( 물론 아직까지 서포트 받아본적은 없습니다-_-;;)

-------------------------------------------------------------------------------------------------------
Life ... http://iz4u.net/blog/

------------------------------------------------------------------------------------------------
Life is in 다즐링

환골탈태의 이미지

저는 일관성있는 관리를 위해서 CentOS로 통합하는 작업을 하고 있습니다만..
몇몇 관리 서버들은 굳이 CentOS를 할 필요는 없을거 같다고 생각하고 있었습니다.
다즐링님 글을 읽고보니 우분투 서버 사용에 관심이 가는군요. ^^
하긴 각종 툴의 설치와 관리가 좋아서 관리나 모니터링 서버에 딱이라는 생각이 들기도 합니다.
좀 한가해지면 우분투로 모니터링 서버나 구축해 봐야겠습니다.
__________________________________________________
모두 다 Feisty로 바꾸었습니다.

__________________________________________________
모두 다 Hardy로 업그레이드 하고 있습니다.

number3의 이미지

비공식적인 이야기지만,
CentOS가 패키징할 때 언급한 이미지나 Redhat 글자를 다 제거 못 한것으로 알고 있습니다.
이 점을 Redhat에서도 파악하고 있는 듯 하고(아님 말고..)
기능이나 성능 측면에서 RHEL과 거의 비슷하다는 것도 ..

RedHat은 CentOS를 사용하다 깊은 문제에 빠지면, Redhat으로 라이센스를 구매하고 지원을 받을 것이라 예측하고 있는 듯 합니다. 사실 패키징이나 라이브러리 문제들이야 삽질하면 되겠지만, 커널이나 기타 하드웨어나 운영체제와 밀접한 디버깅을 할 수 있는 곳이 얼마나 있을까요?

사용자들이야 CentOS를 사용해서 상용에 버금가는 안정성과 신뢰를 확보할 수 있고,
Redhat은 잠재적인 고객들을 많이 확보하고 고객지원에 들어가는 교육, 훈련 비용을 절감할 수 있으니,

모두 다 이익을 보는 시장인 거 같은데요..

sugarlessgirl의 이미지

좋은 말씀이십니다.

Quote:
RedHat은 CentOS를 사용하다 깊은 문제에 빠지면, Redhat으로 라이센스를 구매하고 지원을 받을 것이라 예측하고 있는 듯 합니다.

이 부분이 확~ 와닿는군요.

MS 같은 기업이 사용자를 자기네 플랫폼으로 끌여들이기 위해 들이는 노력을 본다면..

말씀하신대로 모두 다 이익을 보는 시장인 듯 합니다.

멋지군요.

howl의 이미지

RH과 CentOS의 관계하고는 전혀 다르지만..
얼마전까지 M$가 윈도나 오피스의 불법복제를 상당부분 방관한 것도 비슷한 맥락으로 읽을 수 있겠지요.

--------
We Await Silent Trystero's Empire

--------
We Await Silent Trystero's Empire

문태준의 이미지

레드햇의 수익모델이 고객에 대한 신뢰성 제공, 서티 인증 제공, 서비스 제공이라고 생각을 합니다. 리눅스를 잘 다룰수 있는 사용자라면 레드햇이든 데비안이든 특별히 상관은 없을거라 생각은 하는데 문제는 기술지원서비스이겠지요.

각종 상용솔루션에서도 지원하는 OS가 있고 이런 경우에는 당연히 그 OS를 사용하게 됩니다. 또한 공짜이기에 리눅스를 쓰는 것은 아닌 것처럼 서비스에 대한 책임이나 지원이 필요한 경우가 점차 늘어가고 있고 선택의 요인이 "초기 도입비용이 무료"인것은 아닐 것이라 생각합니다.

다즐링님이 말한것중에서
"시스템이 크래쉬나거나 한다고 해서.. rh를 콜해서 답이 오지는 않겠죠 -_-;;; 대형고객이 아니라서.." -> 이건 아닙니다. RHEL 배포판을 쓰는 경우에도 실제 어떠한 문제가 발생해도 기존의 관성에 익숙하여 스스로 해결하려고 하고 정작 기술지원서비스를 받지 않는 경우가 많지 않나 생각을 합니다. RHEL 구매시 기본적으로 전화, 이메일 기술지원은 제공을 하는데 실제 도움되는 경우가 많습니다. 이건 예전 제가 이쪽 일을 해서 말을 하는 것이지요. RHEL에 대한 서비스외에 컨설팅, 별도 기술지원이야 따로 계약을 하겠지만 이건 별개의 경우일 것이구요.
참고로 현재 미국등은 문의가 있을 경우 레드햇에 직접 문의를 하지만 국내의 경우는 판매한 업체를 통해서 1차 문제해결을 하다보니 약간 시간이 더 걸리는 일은 있습니다.

제 입장에서도 범용적으로 사용하는 것은 CentOS 등을 쓴다고 하더라도 기술지원이 필요하고 크리티컬한 서비스라면 기술지원서비스를 받을 수 있는 것을 쓰는게 꼭 필요한게 아닌가 생각합니다.

그리고 예전에도 말을 했지만 리눅서들 스스로가 자기는 아니라고 말을 하지만 자꾸만 공짜OS라는 것을 너무 머릿속으로 생각하여 모든 책임을 스스로 뒤집어쓰지 않는가 생각하고 기술지원서비스를 받는 것에 대해서 부정적인 생각을 가지고 있다는 느낌입니다. FREE는 자유라고 말을 하면서 자꾸만 공짜에만 집착을 한다고 할까요.

아뭏든 리눅스를 떠나서 소프트웨어는 무상으로 제공하고 서비스에 대한 비용을 받는 형태로 다른 소프트웨어들도 변해가고 있다는 생각이 듭니다. 이건 공개소프트웨어가 시장에서도 인정을 받고 또 기술을 대중화하면서 변화되는 부분들이겠지요.

---------------------------
문태준
http://tunelinux.pe.kr
http://database.sarang.net

---------------------------
문태준
http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임
http://tunelinux.pe.kr
http://database.sarang.net

dldiek의 이미지

해가 되지도 득이 되지도 않을 것 같네요. rhel은 기본 os자체에 대해선 무료 입니다. rhel이 구입시 비용이 발생하는 이유는 오직 유지보수 개념때문으로 알고 있구요.

만약 rhel과 centos가 이름만 다르고 모든 부분이 똑같고, centos가 무료로 짧은 시간 내에 rhel과 똑같은 패치를 제공한다고 가정합시다. 당신이 크리티컬한 서버의 관리자라고 한다면 어떤 것을 사용할 까요?

서버를 구축해서 서비스하는 도 중 os상의 어떤 이슈로 인해 서비스가 중단되는 현상이 발생했습니다.
centos를 사용하고 있었다면 이 문제를 누가 해결해 줄까요? 관리자인 당신이? centos를 만든 커뮤니티가요? 취미로 문제를 해결해 줄려고 하는 사람이 아닌 이상 어느 누구도 공짜로 그 책임을 떠 안고 해결하려고 하진 않을 겁니다. 그런데 radhat은 문제해결을 합니다. 발생하는 비용에 대한 책임이니까요. 관리자의 입장에선 책임 전가를 위해서라도 꼭 필요합니다. rhel에 먼저 발생한 이슈라서 centos의 패치가 빠르게 이루어 진다면 상관없겠지만,. centos에 먼저 발생했다면 rhel에 같은 이슈가 발생해서 해결될때까지의 기간을 기다릴 순 없잖아요. 프로그래머와 하드웨어쪽을 많이 조아서 해결 하는 방법도 있을 수 있겠지만...

만약에 test용으로 쓴다면 centos가 최적일거 같아요..

cwryu의 이미지

/. 원래 글에도 나와 있지만, 한국은 아직 없을지 몰라도 아주 저렴한 가격으로 CentOS에 대해 서포트를 잘 해 주는 회사들이 많이 있습니다. (RHEL이 워낙 비싸기 때문에 상대적으로 아주 저렴) 소프트웨어는 당연히 똑같은 거고, 서비스 유무가 비싼 RHEL을 선호하게 만드는 요인은 아닙니다.

차이는 레드햇이라는 이름과 처음 들어보는 군소업체중 어디를 더 신뢰할 수 있느냐죠..

----
익명이나 오래전 글에 리플은 무조건 -1

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.