Kesic Report
56
FKII REPORT 2004-004 기업의 오픈소스 소프트웨어 활용방안 2004. 10
description
Description of GPL license
Transcript of Kesic Report
FKII REPORT 2004-004
기업의 오픈소스 소프트웨어
활용방안
2004. 10
- 2 -
이 자료는 한국정보산업연합회 임베디드소프트웨어산업협의회에서 삼
성전자(최민석 연구원)의 협조로 작성한 것입니다. 내용과 관련하여 문의
사항이 있으시면 아래로 연락 주시기 바랍니다.
한국정보산업연합회 임베디드소프트웨어산업협의회
TEL: 780-0201~4, E-mail: [email protected]
Ⅰ. 오픈소스 소프트웨어 개념 ···························································1
1. 오픈소스 소프트웨어의 조건 ··················································2
2. 오픈소스 소프트웨어의 특성 ··················································3
Ⅱ. 주요 오픈소스 라이센스와 개발 프로젝트 ································6
1. 오픈소스 라이센스 ······································································6
2. 주요 오픈소스 제품과 개발 프로젝트 ·······························14
Ⅲ. 오픈소스 소프트웨어의 비즈니스 모델 ·································22
1. 비즈니스 모델 분류 ··································································22
2. 공급자와 소매상 ·········································································23
3. 오픈소스 소프트웨어 관련 서비스 ······································29
Ⅳ. 오픈소스 활용시 유의사항 및 활용 프로세스 ····················36
1. 유의사항 ························································································36
2. 오픈소스 활용 프로세스 ··························································38
Ⅴ. 결론 및 제언 ···················································································47
목 차
<표 1> 오픈소스 소프트웨어의 특성 ············································3
<표 2> 소프트웨어 라이센스 비교 ···············································13
<그림 1> 오픈소스 라이센스 사용 현황 ······································9
<그림 2> 오픈소스 소프트웨어의 비즈니스 모델 ··················22
<그림 3> OSI 인증마크 ···································································38
<그림 4> S/W 개발 프로세스 ························································39
<그림 5> Linux 커널 개발 프로세스 ··········································40
<그림 6> Blackduck Tool Overall Architecture ·····················44
<그림 7> SONY의 오픈소스 공개 사례 ····································46
표/그림 목차
[ 요 약 ]
□ 오픈소스 소프트웨어는 소스 코드의 공개를 통해 사용, 복제, 수정, 배포가
자유롭다는 강점을 바탕으로 전 세계적으로 그 역이 확대되고 있다. 하
지만 자유지향적인 오픈소스 소프트웨어에도 지켜야 하는 라이센스와
룰이 있다.
가장 대표적인 라이센스가 GNU GPL과 GNU LGPL인 것으로 나타
나고 있다. 오픈소스 프로젝트 개발 포털사이트인 sourceforge.net에
등록되어 있는 약 87,000개의 라이센스 중 약 67%가 GPL을 따르고
있으며 LGPL 10%, BSD 7% 순으로 나타났다.
□ 오픈소스 소프트웨어는 다양한 형식의 라이센스를 가지고 공개되고
있기 때문에 비즈니스적으로 이용하는데 많은 제약이 따른다. 따라서
그 특성을 잘 알고 사용하지 않으면 큰 곤란을 겪을 수 있다. 또한
커뮤니티에 대해 적절하게 대응하고, 커뮤니티와의 협력을 유지하며
새로운 소프트웨어를 개발하는 경우 그 소스 코드를 명확히 분석하여
야 할 것이다.
□ 오픈소스 소프트웨어를 기반으로 수익을 창출하는 비즈니스 모델에는
(1)제품을 공급․판매하는 사업과 (2)서비스 제공 사업이 있다.
패키지 공급․판매사업자는 독창적인 Linux 공급자, 틈새 또는 전문
공급자, 보완․주변제품의 소매상 등이 있다.
Linux 배포사업에 있어 가장 중요한 성공요소는 브랜드가 되므로 광
고, 전시, 홍보 등을 통해 브랜드를 만들고 독자적인 판매채널을 구축
하여야 한다.
틈새․전문 공급자는 단순히 소프트웨어를 파는 것만으로는 유지할
수 없으므로 대부분의 공급자가 그들 제품에 컨설팅과 지원 등 다양
한 부가서비스를 판매해야 한다.
보완․주변제품의 소매상은 OSS(Open Source Software)시장이 사용
자 측으로 이동하고 있으므로 고객 접근이 용이하고 브랜드가 많이
알려진 소매상이 유리한 비즈니스 모델이 될 것이다. 또한 OSS가 더
욱 대중화 되고 OSS커뮤니티 밖에서 이용됨에 따라 문서화가 중요해
지고 있다.
□ 서비스 제공사업은 OSS개발․커뮤니티 조정자와 OSS 관련 서비스․
지원 조직이 있다.
OSS개발과 커뮤니티 조정자는 거래시장과 컨퍼런스나 거래전시행사
를 개최하는 것이다. 거래시장에서 수요자에게서 수익을 유도해야 하
지만 수요자는 개발자 커뮤니티를 신뢰하기 어려운 상황이므로 이 비
즈니스 모델은 수익을 내기 어렵다. 다만 방문자가 늘고 있는 거래
전시회만이 매력적인 분야라 할 것이다.
OSS관련 서비스․지원은 컨설팅, 시스템 통합, 지원, 유지보수, 원격
관리, 훈련, 응용관리 등과 같은 서비스를 포함한다. 이 비즈니스 모
델에서 OSS에 대한 배경을 가진 회사는 프로세스 노하우를 만들 수
있는 역에서 성공할 수 있을 것이며, OSS에 대한 배경이 없는 회사
는 지식이 중요하지 않거나 쉽게 획득될 수 있는 역에서 성공할 수
있을 것이다.
□ 오픈소스를 활용하기 위한 프로세스는 기획, 구현, 검증, 제품화의 단
계로 구성된다.
기획단계에서는 오픈소스 활용여부를 결정하고 특허보호, 오픈소스
라이센스 확인, 소스 코드 공개여부 결정 등을 고려해야 한다.
구현단계에서 소스 코드를 공개해도 무방한 경우엔 특별히 구현 방법
에 신경 쓸 필요없지만 소스 코드 공개를 원치 않는 경우 활용하는
라이센스의 강제사항과 활용형태에 따라 다양한 경우가 발생할 수 있
으므로 법률 전문가의 자문을 받아야 할 것이다.
검증단계에서는 오픈소스가 사용된 형태를 면 히 분석하여 해당 라
이센스의 위반 여부에 대해 검증하여야 한다.
제품화단계에서는 소스 코드 공개와 함께 사용자 매뉴얼을 작성하여
제공해야 한다.
□ 오픈소스 소프트웨어의 활용이 기대만큼 확산되지 않는 것은 성공적
인 활용사례가 적고 오픈소스 소프트웨어 도입후 유지․보수문제가
발생할 경우 책임소재를 명확히 할 수 없기 때문이다.
따라서 향후 오픈소스 활용의 확산을 위해서는 성공사례를 만들고 이
를 널리 알리며, 오픈소스 사용에 따르는 사후처리문제와 법률적인
책임소재를 명확히 할 수 있는 지원체계를 확립해야 할 것이다.
- 1 -
Ⅰ. 오픈소스 소프트웨어 개념
대부분의 저작물과 기술은 자연발생적으로 탄생한 것이거나 이미 널리
알려져 있는 것이 아니면 누군가가 소유권을 갖게 되고 그 소유권은 일
정한 한도내에서 보호를 받기 마련이다. 그리고 그 소유권을 갖고 있는
사람은 이를 타인이 이용할 경우 자신이 획득한 권리를 이용하여 경제적
이득을 취할 수 있다.
그런데 그 소유권을 이용하여 경제적 이득을 얻지 않고 일반 대중에게
공개하는 사람들이 있다. 이러한 경향은 소프트웨어부문에 집중적으로 나
타나는데 자기가 개발한 소프트웨어의 소스를 공개하는 오픈소스 소프트
웨어 운동 참여자들이다.
이들의 활약으로 인해 소프트웨어의 독점적 이용이 제약되고 보다 많
은 사람들이 이용과 개발에 참여할 수 있는 환경이 이루어지고 있다.
이로인해 소프트웨어산업에서 오픈소스 소프트웨어 진 과 상용소프트
웨어 진 으로 분리되어 경쟁이 나타남으로써 어느 쪽이 소프트웨어산업
에 더 바람직한가에 대한 논쟁이 지속적으로 나타나고 있다.
이러한 논쟁에서 오픈소스 진 은 소프트웨어의 소스 코드를 공개하고
무료로 이용토록 함으로써 많은 사람들이 소프트웨어에 쉽게 접근할 수
있도록 하여 저변을 확대하고 소프트웨어의 개선을 용이하게 함으로써 소
프트웨어 산업이 발전할 수 있다고 주장한다.
반면에 상용소프트웨어 진 은 현재의 소프트웨어시장이 구축되는데
상용소프트웨어를 개발한 기업의 기여도가 훨씬 높다고 주장한다. 저작권
을 통해 적절한 수입을 획득하고 이를 다시 개발에 투자하여 제품의 성능
을 개선함으로써 소비자의 요구에 부응하는 선순환 구조가 소프트웨어 산
업을 발전시키는 원동력이라는 것이다.
이러한 논란에도 불구하고 많은 소프트웨어 개발자 및 이용자가 소프
트웨어의 소스를 오픈하고 무료 또는 저가에 이용할 수 있는 환경이 상용
소프트웨의 독과점에 의한 폐해를 방지하는 역할을 하고, 상용소프트웨어
로 개발되지 않은 부분을 오픈소스소프트웨어가 담당할 수 있으므로 오픈
- 2 -
소스 소프트웨어가 필요하다는 데 공감하고 있다.
여기서는 오픈소스 소프트웨어의 개념과 다양한 특징 및 저작권 등과
관련된 문제들을 짚어 봄으로써 오픈소스 소프트웨어의 비즈니스적 이용
에 따르는 문제점 및 해결방안을 모색해 보고자 한다.
1. 오픈소스 소프트웨어의 조건
오픈소스 소프트웨어는 단순히 소프트웨어의 소스를 공개하여 소스에
대한 접근을 허용하는 것만을 의미하는 것이 아니라 다음과 같은 다양한
배포조건을 수용해야만 한다.
① 자유배포(Free Redistibution) : 소프트웨어의 일부 또는 전부가 재배
포되지 못하도록 제한을 설정할 수 없다.
② 소스 코드(Source Code) : 프로그램 저작물에는 반드시 소스 코드가
포함되어야 한다. 포함시키지 않을 시는 인터넷에서의 무료 다운로
드 허용 등 소스 코드를 제공받을 수 있는 조치를 취해야 한다.
③ 파생저작물(Derived Works) : 프로그램 원저작물의 개작이나 이를
이용한 2차적 프로그램의 창작이 허용되어야 하며 이 창작 프로그
램이 최초 프로그램과 같이 동일한 조건하에서 재배포될 수 있어야
한다.
④ 소스 코드의 보전(Integrity of The Author's Source Code) : 프로그
램을 개작할 목적으로 소스 코드와 패치파일을 함께 제공할 경우
라이센스 안에 소스 코드의 수정을 제한하는 항목을 추가할 수 있
다. 다만 수정된 소스 코드를 이용해 만들어진 프로그램에 대한 자
유로운 배포를 허용해야 한다.
⑤ 개인이나 단체에 대한 차별 금지(No Discrimination Against
Persons or Groups) : 라이센스는 모든 개인과 단체에 대해서 동일
한 기준으로 적용되어야 한다.
⑥ 사용 분야에 대한 차별 금지 (No Discrimination Against Fields of
Endeavor) : 라이센스 안에 특정한 분야에서의 사용을 금지하는 제
- 3 -
한을 설정해서는 안된다.
⑦ 라이센스의 배포(Distribution of License) : 프로그램에 대한 권리는
반복되는 배포에 따른 별도의 라이센스 승인이나 양도 과정 없이도
프로그램을 배포받은 모든 사람에게 동일하게 적용된다.
⑧ 라이센스 적용상의 동일성 유지(License Must Not Be Specific to a
Product) : 라이센스는 반복 배포 과정에서 특정한 배포판에 포함되
어 있는 상태로만 유효하지 않고 모든 배포 단계에서 동일한 효력
을 갖는다. (특정한 배포판에 포함되어 있던 프로그램을 독립적으로
사용하거나 재배포할 경우에도 해당 프로그램을 배포받은 사람은
프로그램이 포함되어 있던 최초의 배포판 상태에서 발생된 권리와
동일한 권리를 갖는다.)
⑨ 다른 라이센스의 포괄적 수용(License Must Not Contaminate
Other Software) : 라이센스에 오픈소스 소프트웨어와 함께 배포되
는 소프트웨어에 대한 제한을 설정해서는 안된다.(예를 들면, 동일
한 매체를 통해서 배포되는 소프트웨어는 모두 오픈소스 소프트웨
어여야 한다 등의 제한을 해서는 안된다.)
2. 오픈소스 소프트웨어의 특성
Feller and Fitzgerald(2000)는 오픈소스 소프트웨어를 연구하는 방법론
을 개발하면서 오픈소스 소프트웨어 현상을 분석적으로 접근하기 위한 틀
을 제시하고 있다. 이 틀에서 언급된 내용들은 오픈소스 소프트웨어의 특
성들을 잘 표현하고 있다.
<표 1> 오픈소스 소프트웨어의 특성
무엇이 오픈소스 소프트웨어인가
소프트웨어 제품과 프로젝트
를 오픈소스 SW로 정의하는
기준은 무엇인가
오픈소스 SW는 그것이 배포되는 조건과 라이
센스에 의해 정의된다. 그러나 최근에는 그 개념
에 상당한 유동성이 존재하고 있다.
- 4 -
어떤 유형의 제품과
프로젝트가
오픈소스 소프트웨어인가
과거에는 운영체제와 네트워킹체제 소프트웨어,
유틸리티, 개발도구, 인프라스트럭처 컴포넌트가
오픈소스 소프트웨어의 주종을 이루었다.
최근에는 생산성 향상과 관련된 응용소프트웨
어, 엔터테인먼트 응용소프트웨어들이 많이 개발
되고 있다.
왜 오픈소스 소프트웨어를 개발하고 사용하는가
오픈소스 소프트웨어 개발의
기술적인 동기는 무엇인가
훌륭한 코드, 신속한 개발주기, 높은 수준의
질, 신뢰성, 안정성의 획득, 좀 더 개방된 표준과
플랫폼의 확보가 오픈소스 소프트웨어 개발의 기
술적인 동기이다.
오픈소스 소프트웨어 개발의
경제적인 동기는 무엇인가
오픈소스 소프트웨어 개발에 대한 기업차원에서
의 동기는 비용과 리스크의 공유이다. 또한 소프
트웨어 산업을 일상적 제품(commodity)산업을 넘
어 서비스 산업으로 재편하려는 노력도 경제적
동기가 되고 있다.
오픈소스 소프트웨어 개발의
사회·정치적 동기는
무엇인가
사용자 스스로가 느끼는 불편한 점을 해결하기
위한 노력, 사회적 평판의 획득, 고도의 능력을
지닌 개발자에게 배우는 것(mentorship), 의미있
는 일을 하고 싶다는 의지, 공동체 지향의 이상주
의 등이 사회정치적 동기라고 할 수 있다.
오픈소스 소프트웨어가 개발되는 시간적 공간적 환경은 어떠한가
오픈소스 소프트웨어 개발의
시간적인 측면은 어떠한가
오픈소스 소프트웨어는 신속한 개발, 재빠른 제품
의 진화, 빈번하고 지속적인 개선된 제품의 제출
을 특징으로 가지고 있다.
오픈소스 소프트웨어 개발의
공간적 측면은 어떠한가
지리적인 측면보다는 사이버스페이스에 의해 경
계가 형성되는 팀으로 구성되어 있다. 개발팀은
분산된 형태로 소프트웨어를 개발한다.
오픈소스 소프트웨어는 어떻게 개발되는가
오픈소스 소프트웨어
개발과정은 어떻게
조직되는가
오픈소스 소프트웨어 개발방법론의 핵심은 제
품개발과 디버깅에서 다수의 개발자가 참여하는
병행개발 방식이다. 개발은 느슨하게 집중화되고
협력적 방식을 통해 이루어지며, 무상의 노력을
제공하는 개발자들이 참여한다.
최근에는 좀 더 개발방식이 조직적으로 이루어
지는 양상을 보이고 있으며 소프트웨어 개발에
대한 금전적 보상도 이루어지고 있다.
- 5 -
* 자료 : Feller and Fitzgerald(2000)
오픈소스 소프트웨어 모델을
지원하기 위해 어떤 것들이
사용되는가
다수가 참여하는 병행개발방식은 인터넷을 통
해 이루어진다. 인터넷은 의사소통과 협업, 배포
플랫폼으로 활용된다.
학술기관, 비영리기관, 민간기관들, 온라인
Agency service도 오픈소스 소프트웨어 개발을
지원하기도 한다.
오픈소스 소프트웨어의 고객과 주요 개발자, 소유자는 누구인가
오픈소스 소프트웨어 개발에
공헌하는 개인 개발자의
특성은 무엇인가
오픈소스 소프트웨어의 개발자는 주로 건전한
의미의 해커, 아마추어 개발자가 아닌 전문개발
자, 상당히 동기부여된 개발자들이다. 그러나 개
발자들의 평판 지향적인 경향 때문에 매우 겸손
하고 자기를 낮추는 문화가 형성되어 있다. 이것
은 협력개발을 촉진시키는 데 중요한 의미를 지
니고 있다.
오픈소스 소프트웨어 제품을
배포하는 기업들의 특성은
무엇인가
오픈소스 배포회사들은 성공적으로 기업공개를
했다. 이들 기업들은 오픈소스 소프트웨어 개발자
들을 지원해주는 후원자(patron)의 역할을 한다.
이들 기업들은 수익모델을 라이센스 요금이 아
니라 새로운데서 찾으면서 소프트웨어 산업의 패
러다임을 변화시키고 있다. 이들 기업들에게는 고
객서비스, 브랜드 관리, 동료들의 평판이 결정적
으로 중요하다.
오픈소스 소프트웨어 제품
사용자들의 특성은 무엇인가
지금까지 오픈소스 소프트웨어의 사용자들은
전문사용자나 신기술 초기 사용자들이었다. 전통
적으로 사용자 풀과 개발자 풀은 상당히 겹쳐 있
었다.
그러나 오픈소스 소프트웨어의 사용용이성과
인터페이스가 향상되면서 이러한 양상은 변화할
것이다.
- 6 -
Ⅱ. 주요 오픈소스 라이센스와 개발 프로젝트
1. 오픈소스 라이센스
(1) 오픈소스 라이센스의 의미
일반적으로 ‘라이센스(license, 사용허가권)’란 ‘면허’ 또는 ‘허락’을 의
미한다. 어떤 프로그래머가 특정 소프트웨어를 개발하게 되면 저작권 등
지적재산권이 프로그래머 또는 그가 속한 회사에 부여되는데, 이러한 지
적재산권에 의해 소프트웨어에 대한 배타적인 권리를 가지게 된다. 그
결과 원칙적으로 권리자만이 소프트웨어를 사용, 복제, 배포, 수정할 수
있는데, 이들 권리자가 다른 사람에게 일정한 내용을 조건으로 하여 특
정행위를 할 수 있는 권한을 부여하는 행위가 ‘라이센스’이다. 이러한 의
미에서 라이센스는 물건을 판매하는 매매와는 차이가 있으며, 소프트웨
어에 대한 지적재산권은 여전히 원래의 권리자에게 남아있고 일부 사용
에 대한 권리만을 부여하는 것이다. MS, 오라클 등 일반적인 상용 소프
트웨어 업체의 라이센스는 고객이 소프트웨어 권리자에게 대금을 지급
하고 소프트웨어의 ‘사용’ 권한만을 허락하는 것이 일반적이다. 따라서
허락을 얻지 않고 소프트웨어를 복제, 배포, 수정하는 행위는 라이센스
를 위반함과 동시에 불법에 해당한다. 그러나 오픈소스 라이센스는 이러
한 상용 소프트웨어와는 다르다. 기본적으로 모든 오픈소스 라이센스는
사용자의 자유로운 사용, 복제, 수정, 배포를 보장하고 있다. 이러한 특
성은 사용 권한만을 허락하는 상용 소프트웨어 라이센스에 비해 사용자
에게 상당한 혜택을 부여하고 있는 것이다.
(2) 오픈소스 라이센스의 종류
현재 OSI(Open Source Initiative)에서는 오픈소스로 인정받기 위한 10
가지 조건을 정의하고 오픈소스로서의 해당여부를 판단하여 인증마크를
부여하고 있다. 아래에 열거하는 오픈소스 라이센스는 OSI에서 인정하는
라이센스들이다.
- 7 -
․ Academic Free License
․ Apache Software License
․ APPLE PUBLIC SOURCE LICENSE
․ Artistic-style Licenses
․ Attribution Assurance License
․ BSD License
․ Common Public License
․ Eiffel Forum License(v1)
․ Eiffel Forum License(v2)
․ Entessa Public License
․ GNU Free Documentation License
․ GNU General Public License
․ GNU Lesser General Public License
․ Historical Permission Notice and Disclaimer
․ IBM Public License Version 1.0
․ Intel Open Source License
․ Jabber Open Source License
․ MIT License
․ MITRE Collaborative Virtual Workspace License
․ MOTOSOTO OPEN SOURCE LICENSE
․ Mozilla Public License 1.1
․ NAUMEN Public License
․ Nethack General Public License
․ Netscape Public License
․ Nokia Open Source License
․ OCLC Research Public License
․ Open Group Test Suite License
- 8 -
․ Open Software License
․ PHP License
․ Python License (CNRI Python License)
․ Python Software Foundation License(Python 2.1.1 license)
․ Q Public License
․ RealNetworks Public Source License
․ RECIPROCAL PUBLIC LICENSE
․ Ricoh Source Code Public License
․ Sleepycat License
․ Sun Industry Standards Source License
․ SUN PUBLIC LICENSE
․ Sybase Open Watcom Public License
․ University of Illinois/NCSA Open Source License
․ Vovida Software License
․ W3C SOFTWARE NOTICE AND LICENSE
․ wxWindows Library Licence
․ X.Net License
․ zlib/libpng License
․ Zope Public License
이상에서와 같이 많은 라이센스가 존재하지만 실질적으로 적용되는
오픈소스 개발 프로젝트는 몇가지로 한정된다. 오픈소스 프로젝트 개발
포털사이트인 sourceforge.net에 등록되어 있는 약 87,000개의 라이센스
별 현황은 <그림 1>과 같다.
약 77%에 해당하는 프로젝트가 GPL/LGPL을 사용하고 있으며, 그 뒤
를 BSD가 차지하고 있다. 따라서 GPL/LGPL/BSD 라이센스가 주로 사
용되고 있음을 알 수 있다.
- 9 -
<그림 1> 오픈소스 라이센스 사용 현황
(3) 주요 오픈소스 라이센스
오픈소스 소프트웨어의 장점을 최대한 활용하기 위해 반드시 준수해
야 하는 오픈소스 라이센스에 대해 살펴본다.
① 오픈 소스 소프트웨어와 구별되는 유사 소프트웨어
가. Public Domain
Public Domain으로 소프트웨어를 공개한다는 것은 모든 저작권을 포
기한다는 의미다. Public Domain 원칙은 미국과 같은 법률적 환경에서만
가능한 것이다. 독일에서는 Public Domain에 따라 소프트웨어를 공표하
는 것이 확정되지 않은 상태이다. 미국에서 Public Domain 소프트웨어는
정부의 지원으로 대학교나 연구기관에서 대부분 개발된다. 그 소프트웨
어는 미국시민은 누구나 아무런 제약없이 이용할 수 있다. 상업적인 용
도로 활용하는 것도 허용된다.
- 10 -
나. Shareware
셰어웨어의 의도는 되도록 많은 사람이 사용가능한 소프트웨어를 만드
는 것이다. 셰어웨어는 단지 바이너리 형태로만 배포된다. 대부분의 저작
권 소유자는 일정한 테스트 과정을 거친후에 지불하는 약간의 사용료만
을 부과한다.
셰어웨어 전도자들은 소프트웨어 생산자가 그들의 결과물에 대해 보상
받기를 원하고 있으며 어느정도 정당한 사용이 요구된다고 주장한다. 프
리웨어 개발자들의 경우에는 그들의 권리를 주장하는 데 있어 마이크로
소프트보다 더 어려울 것이다. 셰어웨어 제품은 종종 테스트 기간 후에
사용의 편의성을 감소시키는 메카니즘을 내장하고 있다. 이 메카니즘은
사용자가 그 라이센스에 대한 대가를 지불하고자 하는 의지을 증가시킬
수 있다.
다. Freeware
프리웨어는 사용에 대한 라이센스 요금을 부과하지 않는 바이너리 형
태로 배포된다. 프리웨어는 사용자(개인 또는 비상업적 이용자)들에게 배
타적으로 소프트웨어를 사용할 권리를 부여할 수 있다. 프리웨어는 종종
보완 제품의 촉진을 위한 마케팅전략의 일부분으로 이용된다. 예를들어,
마이크로소프트는 시장점유율의 확대를 위해 Internet Explorer를 공개했
다.
② GNU General Public License 2.0
1980년대에 들어 PC가 널리 보급되기 시작하면서 이전에는 하드웨어
의 부속물로만 간주되던 소프트웨어가 부가가치산업으로 발전하기 시작
하 다. 이와 함께 지적재산권 및 라이센스를 통하여 소프트웨어의 사용,
복제, 배포, 수정에 일정한 제한을 가하려는 움직임이 나타나게 되었다.
소프트웨어를 둘러싼 이러한 흐름에 반대하고 소프트웨어의 자유로운
사용, 공유, 수정에 대한 기존의 권리를 유지하기 위하여 리차드 스톨만
(Richard Stallman)은 자유 소프트웨어 재단(Free Software Foundation ;
FSF)을 설립하고 자유 소프트웨어 운동을 전개하 다.
FSF는 자신의 소프트웨어에 대한 저작권을 확보한 뒤, 이러한 권리를
- 11 -
전제로 소프트웨어의 자유로운 공유 및 수정을 보장하고자 하 는데, 그
결과 만들어진 것이 GNU General Public License(GPL) 이다. 이후 FSF
는 대부분의 소프트웨어를 GPL에 의해 배포하 으며, 다른 개발자들도
본인들의 의사에 기하여 자신의 소프트웨어를 GPL 조건으로 배포하기
시작하여, 현재 GPL조건의 소프트웨어가 오픈소스 소프트웨어의 가장
많은 부분을 차지하고 있다. GPL의 주요 내용을 요약하면 아래와 같다.
A) 소프트웨어에 대한 자유로운 사용, 복제, 배포 및 수정을 허용
B) 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시
및 GPL에 의해 배포된다는 사실 명시
C) 소프트웨어를 수정하거나 새로운 소프트웨어를 링크시키는 경우
GPL에 의해 소스 코드 공개
D) Linux를 기반으로 개발된 Application은 소스 공개할 필요 없음
E) Object Code 또는 Executable Form으로 소프트웨어를 배포하는 경
우, 소스 코드 또는 written offer를 함께 제공해야 함
F) 자신의 특허를 Royalty-Free로 제공하는 경우에 한하여 이를 구현
한 프로그램을 GPL로 배포할 수 있으며, 제3자의 특허인 경우에도
특허권자가 Royalty-Free형태의 라이센스를 제공해야만 해당 특허
기술을 구현한 프로그램을 GPL로 배포하는 것이 가능
③ GNU Lesser General Public License 2.1
FSF가 일부 Library에 GPL보다 다소 완화된 형태인 GNU Lesser
General Public License (LGPL)를 만들어 사용하고 있는 이유는 오픈소
스 소프트웨어의 사용을 장려하기 위한 전략적인 차원에서이다. 만일 상
용 Library와 동일한 기능을 제공하는 Library에 GNU와 같은 엄격한 라
이센스를 적용하게 되면, 개발자들이 Library의 사용을 꺼려할 것이다.
오히려 이미 널리 사용되고 있는 상용 Library와 동일한 기능을 제공
하는 Library는 LGPL로 배포하여 그 사용을 장려하고 사실상의 표준으
로 유도하는 한편, 관련된 다른 오픈소스 소프트웨어를 보다 더 많이 사
용할 수 있도록 하겠다는 것이 FSF의 전략이다.
LGPL Version 2.1은 GNU ‘Library’ General Public License version
2.0의 후속 버전이다. 일부 한정된 Library에 대해서만 LGPL을 사용하려
- 12 -
는 것이 FSF의 의도 으나 ‘Library’란 단어가 라이센스 이름에 포함되어
개발자들이 모든 Library를 위한 라이센스로 오인하는 경향이 있었다. 결
국 이러한 오인을 방지하기 위하여 ‘Library’를 ‘Lesser’로 수정하 을 뿐
기본적인 내용은 동일하기 때문에 Version 2.1으로 표기한 것이다. LGPL
의 주요 내용을 요약하면 아래와 같다.
A) 소프트웨어에 대한 자유로운 사용, 복제, 배포 및 수정 허용
B) 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시
및 LGPL에 의해 배포된다는 사실 명시
C) LGPL Library의 일부를 수정하는 경우 수정한 Library를 LGPL에
의해 소스 코드 공개
D) LGPL Library에 응용프로그램을 링크시킬 경우 해당 응용프로그램
의 소스를 공개할 필요 없음. 다만 사용자가 Library 수정 후 동일
한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그
램의 Object Code를 제공해야 함
E) 특허의 경우 GPL과 동일함
④ BSD License
BSD(Berkeley Software Distribution) 라이센스는 GPL/LGPL보다 덜
제한적이기 때문에 허용범위가 넓다. 이는 BSD가 미 정부에서 제공한
재원으로 운 되었기 때문이다. GPL과의 차이점 중 가장 중요한 사항은,
BSD 라이센스를 따르는 프로그램의 소스 코드를 구해 수정한 후 소스를
공개하지 않고 BSD가 아닌 다른 라이센스를 적용하여 판매할 수 있다는
점이다. 주요 내용을 요약하면 아래와 같다.
A) ‘저작권 표시’, ‘무보증의 표시’만 한다면 누구든지 자유로이 사용,
복제, 배포, 수정이 가능함
B) 수정 프로그램에 대한 소스 코드의 공개를 요구하지 않기 때문에
상용 소프트웨어에 무제한 사용가능
⑤ MPL(Mozilla Public License)
MPL은 Netscape 브라우저 클라이언트인 Mozilla 소스 코드를 공개하
- 13 -
는 라이센스다. MPL은 MPL-software의 사용에 있어 일종의 복제권을
강요한다. GPL과의 주된 차이는 MPL하에 있는 소프트웨어가 전염성 없
는 소프트웨어 제품으로 포함될 수 있다는 것이다. 따라서 MPL의 기본
은 LGPL과 비슷하다. 또 이와 비슷한 라이센스는 IBM Public License나
Sun Public License다. 이 라이센스는 모두 OSI(Open Source Initiative)
의 승인을 받은 것이다.
<표 2> 소프트웨어 라이센스 비교
소프트웨어 라이센스 무료이용 배포허용 이용상
제한없음
소스 코드 취득/수정
가능
파생물재공개
상용SW와연결가능성
Public
Domain● ● ● ● ●
Shareware ◐ ●
Freeware ● ● ●
GPL ● ● ● ● ●
LGPL ● ● ● ● ● ●
MPL ● ● ● ● ● ●
BSD-License
● ● ● ● ●
* 자료 : Belcon Research, 2002. 7
** shareware는 테스트 기간에만 무료이용이 가능함
- 14 -
2. 주요 오픈소스 제품과 개발 프로젝트
(1) 운 체제(Operating Systems)류
① Apache
1995년까지 NCSA(National Center for Supercomputer Applications)가
가장 널리 사용되는 웹 서버를 제공했다. 그 소프트웨어는 복제가 가능
했고 수정에 대한 내용이 NCSA에 통지되는 파생품도 자유로이 만들 수
있었다.
1995년에, 많은 NCSA 개발자는 Netscape로 옮겨갔다. 그래서 대부분
의 전문적인 사용자들은 더이상 소프트웨어의 품질에 만족할 수 없었고
NCSA 웹 서버의 개발을 진행하는 연락처를 비치했는데 이를 Apache라
고 불 다.
Apache Software Foundation(ASF)은 1999년에 설립되었고 지금은
Apache 개발에 대한 책임을 맡고 있다. 아파치는 오픈소스 소프트웨어
개발과정에서 성공적인 조직관리의 매우 좋은 보기로 알려져 있다. 아파
치 웹 서버는 1996이후 시장을 지배하고 있다. 현재 시장점유율은 약
60%에 달한다(Netcraft, 2001). 마이크로소프트의 IIS는 약 30%를 차지하
고 있다. 아파치 웹서버는 많은 소프트웨어 솔루션에 포함되어 있다.
② Free BSD
Free BSD는 1993년에 처음 발표되었다. Free BSD는 Unix 시스템인
BSD(Berkeley Software Distribution)기반위에서 개발되었고, 오픈소스
Unix 운 체제를 제공한다.
Free BSD는 상업적 이용자와 비 상업적 이용자 양쪽에 거의 제한없이
적용되어 다양한 BSD라이센스하에서 폭넓게 확대되고 있다. NetBSD와
OpenBSD는 FreeBSD가 BSD위에서 개발된 다른 오픈소스 프로젝트 들이
다. 반면에 FreeBSD는 가장 인기있는 변형체라 할 것이다. FreeBSD를 발
표한 Jordan K. Hubbard는 FreeBSD의 목표가 돈과 상관없이 기능과 품
질측면에서 상업적인 소프트웨어를 만드는 것이라고 기술하 다.
FreeBSD가 공급채널을 찾고 있을 때, Walnut Creek은 주요 분배자가
되었고 재정적으로 그리고 IT인프라 장비를 를 통해 FreeBSD를 지원했다.
- 15 -
핵심개발자 중의 한명인 Jordan K. Hubbard는 현재 애플에 고용되어 있
다. 그런데 이것은 애플과 FreeBSD 커뮤니티 사이의 결속을 강화하고 있
다. Apple 운 체제인 Mac OS X는 FreeBSD를 기반으로 하고 있다.
FreeBSD의 상표권자이며 상업적인 BSD/OS의 공급자인 Wind River는
FreeBSD에 대한 재정적인 계약을 중단하면서 고용하고 있던 FreeBSD 개
발자와의 계약도 해지하고 기술적인 지원도 중단하 다.
③ GNOME
GNOME(GNU's Network Object Model Environment)은 Linux와 다
른 Unix 계열 운 체제를 위한 오픈소스 데스크탑 환경에서 KDE와 경
쟁하고 있다. GNOME은 GTK(GNU GUI toolkit)를 사용하고 있고 버전
1.0은 수석 개발자인 Miguel de Icaza와 함께 1999년 3월에 발표되었다.
2001년 5월에 GNOME 배포판을 개발하여 사용자에 보다 친근하게 접
근했던 회사인 Eazel이 문을 닫았다. 그러나 Ximian사의 공동설립자인
Miguel de Icaza 데스크탑에 Linux를 도입하고자 하는 목표를 추구하고
있다. 그러나 Eazel과는 차별화하여 사업적 이용자를 목표로 하고 있다.
2001년 8월에 Dell은 그것이 유저에게 친근하지 않다는 이유로 Linux 운
체제를 가진 PC의 공급을 중단했다. 그러나 GNOME 프로젝트는 썬마
이크로시스템즈, IBM, 휴렛팩커드 등에 의해 지원을 받고 있고 빠른 진
화를 이끌고 있는 강력한 커뮤니티를 갖고 있다.
④ GNU
GNU는 'GNU is not Unix'의 머리 자 조합어이며, 이말이 GNU프로
젝트의 출발점을 잘 표현하고 있다. MIT의 리차드 스톨만(Richard
Stallman)은 자유로이 이용할 수 있는 Unix계열 운 체제를 개발할 목적
으로 1984년에 GNU프로젝트를 시작했다. 그가 GNU프로젝트에 초점을
맞추기 위해 MIT를 그만뒀을 때, MIT는 그들의 정보 기술 자원에 대한
접근을 유지하기 위해 그를 계속해서 지원했다. GNU프로젝트는 아직 경
쟁력있는 자신만의 OS 커널(Hurd) 개발에 성공하지 못했지만 그 대신에
GNU와 Linux의 결합은 매우 성공적이었다.
GNU프로젝트의 발전을 위해 매우 중요한 결정요소는 자유소프트웨어
- 16 -
재단(Free Software Foundation)의 철학과 GNU GPL(GNU General
Public License)이다. 자유소프트웨어재단(FSF)은 1985년에 설립되었고,
기부와 자유소프트웨어의 물리적 형태의 배포와 매뉴얼에 대한 요금으로
유지된다.
현재 GNU프로젝트는 Unix 운 체제 복제품과 관련된 많은 소프트웨
어 프로젝트와 상업적으로 배포되는 소프트웨어에 포함되어 있다. 중요
소프트웨어 제품은 GNU C Compiler나 GNU Privacy Guard(GnuPG),
GNU Emacs(a text editor), GNOME 등이다.
⑤ KDE
KDE(K desktop environment)는 1996년에 설립되었다. 이것은 지금까
지 써왔던 이질적이고 사용자에 친화적이지 않은 Unix 그래픽 사용자
인터페이스(Graphic User Interface;GUI)의 개선을 목표로 하고 있으며
현재 버전3.0까지 나왔다.
KDE는 GPL과 호환되고 KDE라이브러리는 LGPL과 호환된다. KDE데
스크탑에 대한 상업적인 소프트웨어 개발도 가능하다. 모든 KDE 응용소
프트웨어와 중요한 툴들은 GPL하에서 라이센싱된다.
보조적인 생산품인 Koffice는 KDE용 오픈소스 사무용 응용프로그램이
며 데스크탑 시장에서 윈도우의 경쟁자가 되었다.
⑥ Linux
Linux 프로젝트는 리누스 토발즈라는 한 사람과 관련이 깊다. 컴퓨터
공학도 던 그는 Unix를 퍼스널 컴퓨터에서 쓰고 싶었다. 하지만 이러한
욕구를 충족시켜줄만한 제품이 없었고, Tanenbaum교수가 교육용으로 개
발하여 사용하고 있던 Unix 운 체제인 'Minix'를 기본으로 직접 개발하
기 시작했다. 그 소프트웨어가 어느정도 완성되자 그는 조언과 개선을
위해 그 코드를 토론그룹에 공개했다. 현재 Linux는 가장 잘 알려진 오
픈소스 프로젝트가 되었다.
리누스 토발즈는 아직도 Linux 개발의 중심에 있으며 Linux커뮤니티
에는 수천명의 개발자가 시장스타일로 협력하며 참여하고 있다. 그러나
최상위에 토발즈를 놓고 하위 프로젝트를 관리하는 중간책임자 그룹으로
- 17 -
구성된 몇 개의 계층적인 구조도 있다.
여기에는 많은 조직이 참여하고 있다. Red Hat, SuSE, Mandrake Soft
와 같은 공급자와 소프트웨어 기업인 IBM, HP 등이 참여하고 있다. 그
들 기업은 Linux 개발자들을 고용함으로써 인프라적인 재원을 지원하는
역할을 한다. 한편 상업적인 조직과 비상업적인 조직의 컨소시움인
LSB(Linux Standard Base)는 Linux 개발을 위한 공통의 표준을 수립하
려 노력하고 있다.
Linux는 GPL하에서 공개되었다. GNU/Linux 시스템은 부분적으로는
상업적인 Unix 시스템을 대신하기도 하고, 부분적으로는 Windows NT의
경쟁자로서 주로 서버 시장에서 성장했다. 데스크탑의 운 체제로서는
시장 점유율이 낮다. 하지만 추가개발은 사용자 친화적인 부분에 초점을
맞추고 있으므로 경쟁력 있는 Linux 솔루션이 포함될 것이다. 가장 중요
한 특징은 Linux가 Unix에서 발생했던 분기가 일어나지 않아 매우 성숙
하고 기술적으로 매우 뛰어난 운 체제라는 것이다. Unix는 상업적인 버
전으로 썬의 솔라리스가 있고 무료 버전으로 FreeBSD, NetBSD,
OpenBSD 등이 있다. 현재 Linux에서 가장 이슈가 되는 부분은 표준화
다.
(2) 응용소프트웨어류
① DNS와 Bind
DNS(Domain Name System)를 전달하는 BIND(Berkeley Internet
Name Daemon)는 일반 IT유저에게는 잘 알려져 있지 않다. 그러나
BIND는 호스트명을 IP주소로 변환시켜주는 프로그램으로서 인터넷의 인
프라를 구성하는 매우 중요한 요소다. BIND는 모든 UNIX 시스템과 많
은 다른 시스템에 포함되어 있으며 기능면에서 사실상 인터넷 표준이다.
BIND는 1984년에 Paul Mockapetris에 의해 처음 개발되었고, Paul
Vixie가 주도하고 있는 ISC(Internet Software Consortium)에 포함되어
있다. ISC는 1993년에 UUNET의 지원을 받아 Rick Adams에 의해 설립
되었고 지금은 SUN, HP, IBM, SGI 등 주요 소프트웨어기업의 지원을
받고 있다.
- 18 -
② Mozilla
Mozilla는 Netscape에 의해 시작된 오픈소스 브라우저 프로젝트다. 마
이크로소프트가 무료로 Internet Explorer를 제공하고 성능을 개선하기
시작했을 때, Netscape는 자신의 브라우저에서 저작권법에 의해 보호되
지 않는 코드를 공개했다. 이에따라 새로 만들어진 라이센스는 Mozilla
Public License 다.
그 코드를 공개하면서 가졌던 바램은 오픈소스 개발과정의 힘의 균형
이었다. 일부 평가에 따르면 처음에는 큰 개발자 커뮤니티가 없었고,
Netscape 개발자들만이 그 코드에 대부분의 기여를 했다.
Netscape가 Mozilla 프로젝트에 너무 많은 제한을 두었다는 것 말고도
Mozilla가 코드 기반이 매우 크고 프로그램이 너무 복잡하기 때문이다.
그것이 그 프로그램을 이해하기 어렵게 만들고, Mozilla를 성공적인 OSS
프로젝트로 만드는데 문제를 가중시킨다. 이상적으로는 그 작업을 공유
하여 추진할 수 있기 때문에 모듈식의 소프트웨어 디자인이 가능할 수도
있을 것이다. 하지만 2002년까지 Mozilla는 버전 1.0만을 발표할 수 있었
다.
③ Sendmail
Sendmail은 Eric Allman에 의해 Mail Transfer Agent (MTA)로 1981년
에 개발되었다. 그당시에 그는 UC Berkely에서 일했고 그 대학의 네트워
크와 Arpanet 사이에 편지를 교환하기 위해 sendmail을 썼다. 처음부터,
Sendmail은 메일 프로토콜의 개방성과 라우팅 기능성, 파일의 유연성에
초점을 맞추었다. Allman은 여전히 sendmail 개발의 중심에 있다. 그는
1993년에 여러방향으로 전개된 프로그램을 다시 써야 했다. 그리고 커뮤
니티를 재결합해야 했다.
무료인 기본적인 sendmail 프로그램을 보강하면서, 그와 Greg Olson은
1997년에 Sendmail사를 설립했다. Sendmail사는 sendmail의 상업적인 버
전을 제공하면서 관리 툴과 보안 솔루션을 추가하고 있다. Sendmail은
sendmail을 통해 전달되는 우편의 75~80 퍼센트의 시장을 점유하여 시장
을 지배하고 있다.
- 19 -
④ MySQL
MySQL은 1994년에 개발된 관계형 데이타베이스 서버다. 스웨덴계 회
사인 TcX Dataconsult AB(MySQL AB로 변경)가 2000년에 GPL하에서
발표한 소프트웨어다. 또한 상업적인 솔루션에 MySQL을 사용할 수 있
게 하는 라이센싱하에서 버전을 제공한다.
개인회사에서 시작해 2001년 7월 이후에 벤처캐피털에서 자금을 조달
한 MySQL AB가 그 저작권의 소유주이다. MySQL을 채용하고 있는 대
기업은 모토롤라와 야후 등이다. NuSphere사는 Apache와 PHP에
MySQL을 통합한 솔루션을 공급했다가 2001년 7월에 메사추세츠에서
GPL위반으로 고발당해 최초로 법정에 올려졌다.
⑤ PostgreSQL
PostgreSQL은 객체관계형 데이타베이스 서버다. 이것은 UC Berkeley
에서 1996년에 시작되었고 한 팀이 그 코드를 오픈소스인 SQL-database
로 개발한 것이다. 그것은 주로 개인적인 용도로 이용되고 있고 최종목
표에 부담이 없는 기업 프로젝트에서 사용된다. stgreSQL이 퍼지지 못하
는 이유는 많은 오픈소스 소프트웨어가 대부분 초창기에 겪는 바와 같이
불완전한 문서화와 전문적인 지원의 부족 때문이다.
6명의 핵심개발자중 3명을 고용하고 있던 Great Bridge사가 2001년 9
월에 운 을 중단했다. 그들의 주된 목표는 산업계에 전문적인 서비스를
제공하는 것이었다. 하지만 PostgreSQL의 품질문제가 대두되면서, Red
Hat은 PostgreSQL 7.1을 기본으로 한 자신의 데이타베이스 제품을 제공
하고 있다.
⑥ Perl
Perl은 Larry Wall에 의해 1987년에 개발되었다. 처음에 텍스트를 탐색
하고 수정하고 인쇄하기 위한 도구 던 Perl은 네트워크와 시스템 관리
도구로 진화했다. CGI 프로그램 기능성으로 인해 동적인 웹페이지에 적
합한 인터넷 매개체가 되었다.
Wall은 O'Reilly에 임시 고용된 100여명의 다른 개발자들과 Perl의 기
능개선을 추진하고 있다. 예를 들면, ActiveState Tool은 Perl을 위해 전
- 20 -
문툴을 제공하고 CPAN(Comprehensive Perl Archive Network)은 수백
개의 Perl 모듈에의 접근을 가능케 한다.
⑦ Python
Python은 Guido van Rossum에 의해 1991년에 발표된 프로그래밍 언
어다. Python은 Perl이나 Tcl과 종종 비교되면서 빨리 진화한 강력한 객
체지향형 컴퓨터 프로그램 언어다. 이 제품은 자바와 완전히 통합된 버
전으로 제공되고 Java Virtual Machine이 설치된 모든 컴퓨터에서 작동
한다.
Van Rossum은 Python Labs의 책임자로서 Zope Corporation에서 일
하면서 이 프로젝트의 리더역할을 맡고 있다. PSF(Python Software
Foundation)는 2001년 3월에 Python 컴퓨터 프로그램밍 언어로 구성되
는 지적 자산을 보유할 특정한 목적을 가지고 설립되었다. PSF의 주요
후원사는 Zope Corporation과 Active State다.
⑧ Tcl/Tk
Tcl/Tk는 John Ousterhout가 UC Berkeley의 교수시절에 개발했다. Tcl
은 Perl과 Python에 비견되는 프로그래밍 언어다. Tk은 그래픽 사용자
인터페이스(GUI)를 개발하기 위한 툴킷이다. 처음에 Unix 시스템으로 개
발되었던 Tcl/Tk가 현재는 마이크로 소프트 윈도우즈와 Apple
Macintosh 플랫포옴을 지원하고 있다. Ousterhout은 자신의 회사인
Scriptics사를 설립할 때까지 썬과 함께 일했다.
⑨ Gimp
Gimp(GNU Image Manipulation Program)은 종종 '무료 포토샵'이라
고 불리는 그래픽 소프트웨어다. 이것은 Unix 시스템을 위해 Peter
Mattis와 Spencer Kimball에 의해 개발되었고 지금은 대부분의 Linux 공
급판에 포함되어 있다.
- 21 -
⑩ Samba
Samba는 1993에 호주국립대학의 Andrew Tridgell에 의해 개발된
Unix 플랫폼용 윈도우 파일서버와 프린터서버다. 현재의 버전은 2.2.x이
며 중소기업에 적합하며 윈도우 서버를 Linux서버로 교체할 때 편리하게
활용될 수 있다. Samba는 대부분의 Linux 배포판에 포함되어 있다.
윈도우즈 서버에 대응한 화일 서버나 인쇄 서버로서 몇개가 시험적으
로 운 되고 있다. 실리콘그래픽스사는 Samba를 사용하는 가장 빠른
Windows NT fileserver를 제공한다고 밝혔다. 2001년 11월에 PC
Magazine이 인쇄서버로서 Samba/Linux와 윈도우2000을 테스트한 결과
Samba/Linux가 비용과 품질면에서 우수했다.
⑪ Zope
Zope는 독점권을 위해 개발되는 소프트웨어 프로젝트의 하나 다.
1995년에 Digital Creations사가 Rob Page와 Paul Everitt에 의해 설립되
었다. 그들은 신문사의 광고 관리 소프트웨어를 개발하고 있었다. 나중에
그들은 두개의 주된 소프트웨어 제품을 갖게 되었다. 무료 오픈소스 툴
킷인 Bobo와 상업적인 웹응용 플랫포옴인 Principia다. 그들은 재정적으
로 안정될 수 있는 웹 응용 서버 시장에 진입하지 않았다. 대신에 라이
센스 수입모델에서 서비스를 통해 수익을 얻는 비즈니스모델을 그들의
사업으로 채택했다.
오픈소스 소프트웨어로 Principia를 공개함으로써 그들은 마케팅을 촉
진하고 그 제품을 개선하는데 도움을 줄 커뮤니티가 구성되기를 희망했
다. Zope는 응용서버 시장(특히 컨텐츠관리와 포털)에서 경쟁력있는 대
안으로 평가받고 있다. 독일에서는 Zope 서비스를 제공하는 몇몇 기업에
의해 'Eurozope Association'가 설립되기도 했다.
- 22 -
Ⅲ. 오픈소스 소프트웨어의 비즈니스 모델
1. 비즈니스 모델 분류
오픈소스를 기반으로 하는 사업은 OSS기술에 기반을 두고 부가적인
상담 서비스와 지원을 통해 수익을 창출한다. 즉 OSS의 사업모델은 제품
관련(product-related) 사업과 서비스관련(service-related) 사업으로 구분
된다. 서비스와 지원 공급자는 컨설팅과 시스템에의 적용과 통합, 지원,
훈련, 채용과 참모서비스를 제공한다.
<그림 2> 오픈소스 소프트웨어의 비즈니스 모델
OSS Business
Model
Distributorsand
Retailers
OSS-RelatedServices
Original Linux Distributors
Niche and Speciality OSS
Distributors
Retailers of OSS Distributions and Compl.Products
OSS Development and Interest
Enablers
Service and Support
Providers
* 자료 : Berlecon Research 2002
- 23 -
2. 공급자와 소매상(Distributors and Retailers)
(1) 독창적인 Linux 공급자
① 제품과 서비스의 제공
가. 사례
Linux 공급자는 그들 자신만의 Linux 운 체제 버전을 포장하여 판매
한다. 독창적인 Linux 공급자의 사례로는 Red Hat, SuSE, MandrakeSoft,
Caldera, Turbolinux와 Slackware 등이다. 공급자는 소비자와 기업 등 엔
드유저에게 다양한 하드웨어를 위해 Linux 운 체제와 서버용, 데스크탑
용, Ecommerce suite와 같은 다양한 소프트웨어 패키지와 번들제품을 공
급한다. IT 관리자에게는 그들이 적용하기에 적절한 관리 도구를 판다.
개발자에게는 OEM(original equipment manufacturers)을 위한 개발 도
구와 다양한 Linux 버전을 판다.
나. Linux 공급의 기본요소
하나의 Linux 제품은 Linux 커널과 수백가지의 추가적인 파일로 구성
된다. 공급자는 자신만의 버전을 개발하기 위해 최신의 Linux 공개소스
와 모든 과련된 파일을 모아야 한다. 두 번째 단계는 높은 품질과 신뢰
성을 달성하기 위해 테스트하고, 조율하고 목적에 맞는 소프트웨어 조각
들을 최적화해야 한다. 그리고 보통 이러한 노력은 다시 OSS커뮤니티에
환원한다. 세 번째 노력은 매끄러운 설치, 문서화, 효율적인 관리와 생산
성 도구들이 새로 만들어진다. 이 단계에서 Linux 공급자는 개발 실험실
을 제공함으로써 Linux 커뮤니티를 지원하며 추가적으로 다수의 개발자
를 고용하거나 프리랜서 개발자와 공동으로 작업한다.
다. 공급자에 대한 찬반 양론
Linux 공급자는 처음부터 그들의 운 체제를 개발하지 않음으로써 막
대한 소프트웨어 개발 비용을 절감한다. 예를 들면, Red Hat 7.1 운 체
제는 10억 달러를 필요로 했던 것으로 평가된다(Wheeler, 2001a). 그들은
여기서 그들의 최적화된 Linux 버전의 개발을 위해 많은 투자를 절감했
다. 반면에 Linux 공급자는 그들의 제품에 상용소프트웨어 생산자와 같
- 24 -
은 방식으로 제품 가격을 산정할 수 없다. Linux의 다수 구성요소가 자
유로이 다운로드 될 수 있기 때문에 그 제품이 공급자에 의해 부가되는
가치는 패키징에 불과하다.
Linux 버전에 기반하는 소프트웨어 제품은 웹사이트에서 다운로드를
통하거나 CD-ROM을 통해 공급된다. 여기서 Linux 공급자는 다수의 판
매 통로를 사용하게 되는데 가장 중요한 것은 VAR(value added
resellers)과 서점을 포함하는 소매상이다.
라. 중요한 성공 요소
Linux 분배 사업에 있어 중요한 성공 요소는 브랜드를 만드는 것이다.
따라서 공급자들은 광고, 전시, 홍보 등 마케팅에 많은 투자를 하게 되고
공급망과 마케팅은 Linux 공급자의 핵심능력이 된다.
마. 부가적인 서비스
이러한 사실에도 불구하고 대부분의 공급자들은 컨설팅, 통합, 지원,
교육훈련 등의 Linux 관련 서비스를 추가적으로 제공하고, 그 서비스는
부가적인 수입원을 생성한다. 더 나아가 티셔츠나 머그컵 등의 판매를
통해 적은 수입을 꾸준히 생성할 수 있다.
② Linux 공급자를 위한 시장
기본적으로 Linux 공급자는 두개의 시장을 커버한다. 첫번째는 표준화
된 패키지를 중소기업과 개인 소비자에게 공급하는 대중시장이며 두번째
는 큰 기업고객에게 제공되는 솔루션 시장이다.
운 체제시장은 서버와 데스크탑 시장으로 구분된다. 서버시장에서
OSS는 많은 잇점을 제공하여 서버 운 체제로서 중요한 대안이 되었다.
이들의 중요한 경쟁자는 Windows NT와 다양한 다른 Unix 시스템이다.
반면에 데스크탑 시장에서 Linux의 시장 점유는 매우 작고 가장 큰 경쟁
자는 다양한 윈도우즈 버전을 가진 마이크로소프트이다. 하지만 머지많
아 Linux 운 체제가 데스크탑에서도 성공적으로 자리잡을 것이다.
솔루션 시장은 대중시장과 완전히 다르다. 대부분의 공급자는 수익의
원천으로 솔루션시장을 주목한다. 그들 중 몇몇은 컨설팅 회사와의 공동
- 25 -
협력을 통해 솔루션 시장에 대응한다. 한편 SuSE와 같은 회사들은 기업
사용자들을 수익의 원천으로 삼고 있다.
③ 비즈니스 모델의 강점과 약점
가. 낮은 마진
대중시장에서 Linux는 일용품으로 여겨질 수 있다. 왜냐하면 그 컴포
넌트가 무료로 다운로드 받거나 복제될 수 있기 때문이다. 모든 공급자
에 의해 제품화된 다양한 Linux 버전이 부가가치를 형성한다. 하지만 개
당 판매마진은 별로 높지 않다. Linux를 공급하는 제품화 사업은 대중
시장을 목표로 하고 제품을 생산하는 기업은 수익을 높이기 위해 판매를
증가시켜야만 한다.
나. 브랜드에 의한 차별화
그러므로 공급자들은 다른 공급자는 물론 독점 경쟁자들과 차별화할
수 있는 수단을 개발하는데 집중한다. 그리고 이 차별화는 주로 브랜드
에 의해 이루어지며 대중시장에서의 중요한 성공요소가 된다. Red Hat
이나 SuSE와 같은 Linux 공급자는 광고, 전시회, 특화된 교육 등 브랜드
를 만드는 마케팅활동에 많은 노력을 기울 다.
다. 독자적인 판매 채널
두번째 성공요소는 서점이나 VAR(Value Added Reseller)과 같은 판매
채널을 갖는 것이다. 예를 들면, Mandrakesoft는 미국에서는 Macmillan
서점과 협력하고, 독일에서는 작은 컨설팅 회사나 중소기업시장에 접근
하기 위해 통합사업자와 강한 협력과계를 구축하는데 힘을 쏟고 있다.
라. 솔루션과 컨설팅으로 이전하고 있는 공급자들
제품화 사업만으로 생존하는 것이 어렵기 때문에 공급자들은 솔루션과
컨설팅 시장으로 이전함으로써 두번째 사업을 구축한다. 이것은 좀더 돈
벌이가 되는 사업으로의 이동으로 설명될 수 있다. 왜냐하면 단순한 소
프트웨어 판매는 마케팅비용은 높고 데스크탑시장에서 Linux 박스제품의
- 26 -
잠재적 구매자수가 마이크로소프트 박스제품의 구매자에 비해 적어서 마
진이 낮기 때문이다.
Linux를 패키징하고 최적화하는 소프트웨어 지식으로 인해 공급자는
컨설팅과 서비스 사업을 구축할만한 기술적 능력을 갖고 있다. 그러나
그들이 기존의 서비스나 컨설팅 회사에 대응할 경쟁자가 되기 위해 컨설
팅과 비즈니스 프로세스에 노하우를 갖고 있는가는 미지수다.
(2) 틈새와 전문 OSS 공급자
① 제품과 서비스 제공
가. 운 체제 대신 다른 부문에 특화
틈새시장을 공략하거나 전문성을 가지는 공급자는 운 체제가 아닌 다
른 OSS를 개발하고 공급한다. 그들의 제품은 응용, 개발, 관리를 위한 툴
을 포함한다. 그들의 소프트웨어는 Linux에서 실행되기 위해 개발되지만
몇몇의 제품은 윈도우즈나 다른 운 체제에서도 실행된다. 예를들면
Zope, Sendmail.com, Covalent Technologies, Cygnus, Precision Insight,
MySQL, ActiveState, CollabNet 등을 들 수 있다.
나. 공급자는 OSS 프로젝트와의 공생
이 비즈니스 모델에서 기업은 OSS 프로젝트와 공생관계를 유지한다.
OSS는 모아지고, 유지되고, 개발된다. 이런 회사의 주된 기능은 계획을
조정하고 공급을 수행하고 생산제품을 지원하는 것이다. 보통, 그들은 그
특정 프로젝트의 핵심 개발자 몇몇을 고용하고 그 개발자 커뮤니티에 많
이 의존한다.
Zope는 OSS 응용 서버, CMS(content management systems)를 개발하
는 플랫폼, task나 industry에 특화된 부가적인 툴 등을 제공한다. Active
State는 Linux 개발을 위한 독점적인 개발 툴을 제공한다. Precision
Insight는 그래픽 하드웨어를 지원하기 위해 OSS 서버 툴을 제공한다.
Covalent Technologies는 Apache 웹서버의 최적화된 버전을 제공한다.
Sendmail.com은 메시지 서버와 다양한 제품에 내장될 소프트웨어 버전
을 제공한다. MySQL은 다른 소프트웨어 제품에 내장되거나 상업적인
사용을 위한 버전의 데이타베이스 소프트웨어를 제공한다.
- 27 -
② 틈새와 전문 OSS공급자를 위한 시장
가. 시장점유율이 높은 경우
Samba나 Apache 웹서버와 같은 몇몇 OSS 프로젝트의 시장점유율은
높은 편이다. Security Space에 의해 수행된 웹서버에 대한 조사에서
2001년 10월에 Apache의 시장점유율은 63 퍼센트 다. Netcraft의 조사
에서도 Apache는 61 퍼센트의 시장점유율을 기록했다. 그러나 이런 결과
가 개발회사가 이익을 얻을 수 있음을 보여주는 것은 아니다.
나. 고객은 VAR(Value Added Reseller)이나 OEM(Original
Equipment Manufacturer)
틈새와 전문 공급자들의 시장접근은 Linux 공급자의 접근방식과 다르
다. 그들은 개인이나 중소기업을 직접적으로 목표로 하지 않는다. 주요
Linux 공급자는 쉽게 그들의 박스 패키지 안에 전문 소프트웨어 구성요
소를 포함할 수 있다. 그들의 강한 브랜드를 통해 넓은 고객을 기반으로
판매한다. 그럼에도 불구하고, 몇몇의 전문 공급자는 그들의 웹사이트에
서 주문을 받고 Linux 공급자와 같은 채널(VARs, retail chains)을 통해
공급되는 제한된 수의 패키지를 제공한다.
따라서 전문 공급자의 주요 고객은 VAR(Value Added Resellers)이나
OEM(Original Equipment Manufacturers)이며, 이들에게 최적화된 hard
ware-software 번들이나 내장된 제품을 개발하고 파는 것이다.
③ 비즈니스 모델의 강점과 약점
이 범주에 속하는 회사는 보통 다운로드 될 수 있고 복사될 수 있는
OSS를 개발하고 공급하기 때문에 그들이 어떤 종류의 직접적인 사업 모
델을 사용할 수 있었는지 상상하는 것은 어렵다. OSS에 대한 접근이 크
게 제한적이지 않기 때문에 단순히 소프트웨어를 파는 것은 유일한 판매
제안이 될 수 없다.
결과적으로 이 모델의 수익원은 다양성에 있다. 대부분의 회사는 그들
의 제품인 컨설팅과 지원에 대한 부가적인 서비스를 판다. MySQL과 같
은 몇몇 회사는 GPL(General Public License)을 가진 MySQL에 대한 상
업적인 라이센스 요금에서 수입이 발생한다. 다른 경우로 Precision
- 28 -
Insight사는 제품의 최신 버전에 대한 소스 코드는 공개하지 않고 과거
버전만을 공개한다. Sendmail.com에 의해 사용된 다른 방법은 기본적인
sendmail 기능 위에 상업적인 독점소프트웨어를 개발하는 것이다. 기업
이 순수한 OSS분야에 전념하느냐 전통적인 소프트웨어 사업분야에 집중
하느냐 하는 것은 중요한 문제다. 어찌되었든 그들은 양쪽세계에서 모두
살아남을 수 있어야 한다.
(3) 소매상(Retailer)
① 제품과 서비스 제공
소매상은 공급자를 위한 주된 판매 경로다. 소매상은 공급자의 소프트
웨어 제품을 팔거나 OSS 제품이나 상품에 대한 부가적인 매뉴얼 등의
문서와 정보를 제공하거나 판다.
소매상은 소프트웨어 개발 과정에 참여하지 않는다. 그들의 핵심 기능
은 공급과 출판이다. 소매상은 독자적으로 OSS에 초점을 맞추지 않는다.
예를들어 Lehmanns Fachbuchhandlung사의 경우 OSS 교육훈련과 문서
화된 책이 그들의 소매와 출판사업의 한 부분이다. O'Reilly사는 OSS에
기반한 사업을 거의 독자적으로 추진하는 것으로 알려진 회사다.
O'Reilly는 문서화와 교육훈련을 위한 책을 팔고 있다.
출판사업자와 소매 채널의 다른 예에는 CNET와 ZDNet이 포함된다.
또한, CrazyPenguin(UK), Linuxland(Netherlands), Linux Central(U.S)과
Linuxbutikken(Sweden, Norway)처럼 특수화된 다수의 전문 Linux 판매
점이 있다.
② 소매상과 출판업자를 위한 시장
소매상과 전문 Linux 판매점은 대중시장을 목표로 한다. 그들의 고객
은 개인, 기업 유저, 개발자, IT관리자 등이다. OSS 시장은 소프트웨어
전문가나 개발자가 아닌 사용자쪽으로 천천히 이동하고 있다.
③ 비즈니스 모델의 강점과 약점
가. 고객과 알려진 브랜드에 대한 접근
- 29 -
소매상의 이점은 그들의 소매상점을 통해 고객에게 접근한다는 것이
다. 다른 이점은 소매 채널의 널리 알려져 있는 상표다.
웹기반의 리셀러와 전문 Linux 판매점은 브랜드 인지도를 만들어 내는
것이 어렵고 비용이 많이 든다는 것을 알게 된다. 특히 그들이 공급자와
출판사업자와 직접적으로 경쟁할 때는 더 심하다.
일반적으로, 상품화는 그 자체가 비즈니스 모델이 되는 것이 아니고
강한 브랜드가 구축될 때 단지 부가적인 수입원이 된다. 그러므로 상품
화를 통한 수입은 Linux 공급자의 우선적인 관심사항이 된다.
나. 문서화의 필요성
OSS가 더 대중화 되고 OSS 커뮤니티 밖에서 이용됨에 따라 문서화가
필요해졌다. 상업적으로 개발된 소프트웨어의 경우 문서화는 보통 소프
트웨어 생산자나 출판사를 가진 기업에서 행해진다. O'Reilly는 출판지식
과 OSS지식을 결합하여 OSS 서적에 대한 브랜드를 구축하는데 성공했
다. 이 회사는 많은 OSS 프로젝트를 커버하기 때문에 하나의 소프트웨어
개발에 의존하지 않는다.
3. 오픈소스 소프트웨어 관련 서비스(OSS-related Service)
(1) OSS 개발과 커뮤니티 조정자
① 제품과 서비스 제공
이 범주는 두종류의 활동 역을 포함한다. 이것은 먼저 SourceXchange,
Cosource.com, intraDAT 등과 같은 거래시장과 다음으로 LogOn Techno
logy Transfer, Linux New Media 등과 같은 컨퍼런스와 거래전시행사를
포함한다.
가. 거래소
교환이나 거래소의 기능은 잠재적인 구매자와 판매자를 만나게 해주는
것이다. 생산된 소프트웨어는 커스터마이즈되거나 주문생산된 OSS가 될
- 30 -
것이다. 이러한 교환 가능성에 대한 주된 논쟁은 많은 소프트웨어 개발
자가 어떤 프로젝트를 추진할 것인가를 그들 스스로 결정하기를 원한다
는 가정이다. 추가적으로, 세계적인 인터넷 네트워크는 세계적으로 잠재
해 있는 개발자와 가격 인하를 이끌어내는 가능성간에 지렛대 역할을 할
수 있었다.
나. 부가적인 서비스를 이용한 개발 프로세스의 개선
소프트웨어 개발을 위한 거래시장은 연결서비스를 제공하고 프로젝트
관리자와 생상성 향상 툴의 제공를 통해서 개발 프로세스를 개선한다.
심지어, 요구 집합은 서비스가 될 수도 있다. 같은 문제를 가진 다수의
구매자는 소프트웨어를 획득하기 위해 거래소를 통해 자금을 모은다. 지
금까지 이 비지니스에서 어떤 회사도 이익을 내지 못했다. 2001년에는
SourceXchange가 문을 닫았다.
다른 비즈니스모델인 컨퍼런스 주최자는 OSS 프로젝트에 대한 관심을
제고하고 OSS 커뮤니티와 비즈니스 협력자들간의 교류기회를 제공한다.
주최자는 OSS와 Linux에 전문화되거나 OSS에 집중함으로써 수익을 발
생시키는 종합컨퍼런스의 주최자가 된다. 이것은 발간사업과도 연관이
있는데 출판사업자가 OSS 컨퍼런스를 개최하는 활동을 하기도 한다.
② OSS 거래소와 컨퍼런스 주최자의 시장
가. 거래소에 관한 닭-알 문제
거래소는 소프트웨어 공급자와 구매자의 두 그룹으로 정리된다. "공급
자" 그룹은 OSS 개발자 커뮤니티이며 "구매자" 그룹은 특별한 솔루션을
찾는 법인조직의 사용자나 개발자다. 보통, 구매자는 거래소에서 제공된
서비스에 대한 대가를 기꺼이 지불할 것이다. 그러나 그 구매자는 어떤
거래소에 충분한 숫자의 판매자(개발자)가 있는가에만 관심이 있다. 그래
서, OSS 시장은 다른 역에 있는 많은 시장처럼 닭이 먼저냐 알 먼저냐
하는 닭-알 문제에 직면해 있다.
나. 컨퍼런스 개최에 대한 스폰서
컨퍼런스와 거래 전시회 주최자는 주로 OSS커뮤니티가 담당한다. 이것
- 31 -
은 OSS에 대한 철학이 확립되지 않은 비즈니스모델이기 때문에 문제가
될 수 있다. 전통적인 컨퍼런스 사업에서 주최자는 제품이나 기술정보,
노하우에 관심있는 구매자와 판매자의 그룹이다. 그들은 제품의 마케팅
을 위해 행사를 활용하는 판매측으로부터 대부분의 수익을 만들어 내고
있다. 추가적으로 구매자 또는 사람들은 컨퍼런스나 거래 전시회의 입장
료를 지불하고 정보를 획득하는데 관심을 갖고 있다. OSS 사업에서 컨퍼
런스 주최자를 위한 시장이 매력적인가 아닌가는 의문의 여지가 있다.
③ 비즈니스 모델의 강점과 약점
가. 거래소
지금까지 순수한 거래소와 교환 모델은 실패 다. 단순히 거래를 연결
시켜주는 기능의 사업모델로는 부가가치가 충분하지 않기 때문일 것이
다. 개발자는 서비스에 대한 요금을 지불할 의사가 없으므로 수익은 수
요측면에서 발생될 수 밖에 없다.
수요측면에서 소프트웨어 구매자는 프로젝트의 완성도를 신뢰하기가
어려울 수 있다. 일반적으로 소프트웨어 개발 프로젝트는 보통 원하는
것에 대한 정확한 요구조건을 갖는 계약과 그 하청계약에 의해 수행된
다. 그런데 프로젝트는 종종 계약상의 시간과 비용을 초과하곤 한다. 이
러한 경험에 비추어볼 때 기업이 책임성이 없거나 프로젝트의 완성도에
대한 보증이 확실하지 않은 개발자 커뮤니티를 신뢰하기는 어려울 것이
다. 공급측면에서 이런 비즈니스 모델의 주된 경쟁자는 OSS커뮤니티 자
체와 자원봉사자들에 의해 관리되는 모든 프로젝트가 된다.
나. 무료 서비스의 유용성
연결(Matching) 기능은 서비스 회사의 범위에서 추가적인 서비스로 활
용될 수 있다. 예를 들어 MandrakeSoft사와 같은 몇몇 공급자들은 그들
의 지원제공에서 이 모델을 부분적으로 적용한다. 그들은 OSS 개발자와
전문가에게 특별한 문제의 해결을 위해 일정한 금액을 지불한다.
다. 컨퍼런스 주최자
OSS 컨퍼런스와 전시회는 보통 상당히 낮은 가격을 책정하고 있어서
- 32 -
주최자가 수익을 남기면서 운 을 할 수 있는가에 대해서는 의문의 여지
가 있다. 그들은 높은 컨퍼런스 입장료를 요구할 수 없다. 왜냐하면 관심
을 갖고있는 대부분의 사람들은 OSS커뮤니티 회원들이다. 또한 그들은
소프트웨어 공급자들로부터도 높은 요금을 요구할 수 없다. 왜냐하면 많
은 공급자들이 커뮤니티 이거나 작고 지역적인 서비스 회사들이기 때문
이다. 결국 OSS에 대한 지속적인 관심을 유도하기 위해서는 방문자가 늘
어나고 있는 거래 전시회가 좀더 매력적인 분야라 할 것이다.
컨퍼런스 주최자는 특별한 주제에 대한 관심을 매우 중요시 한다. 그
러나 그들의 핵심 능력은 관심있는 주제에 대한 평가, 관심의 대상이 되
는 사람들의 발굴, 컨퍼런스나 거래 전시회의 관리 등에 대한 전문적인
지식이다. 그러한 능력에도 불구하고 컨퍼런스 주최자는 OSS에 대한 그
들의 비즈니스 모델을 제한할 필요가 없다. 비록 그들의 지식이 OSS 주
제를 평가하기 위해 OSS에만 제한을 두더라도 그들은 소프트웨어 시장
전체에 대한 종합적인 지식을 가져야만 한다.
라. 진입장벽에 대한 평가
OSS 컨퍼런스 시장에서 잠재적인 진입자에 대한 진입장벽은 OSS커뮤
니티 내에서의 평판이 될 수 있다. 몇몇 OSS컨퍼런스 조직은 커뮤니티에
서 확실한 명성을 얻었다. 그러나 OSS 컨퍼런스 사업에서 중요한 요소는
흥미를 가진 방문객의 상당한 숫자가 대부분의 B2B 행사에 지불하는 입
장료만큼 그 회사에 지불할 용의가 있느냐 하는 것이다.
(2) OSS-related 서비스와 지원
OSS-related 서비스와 지원은 컨설팅, 시스템 통합, 지원, 유지보수, 원
격관리, 훈련, 응용 관리 등과 같은 몇가지 서비스를 포함한다.
OSS-related 서비스 시장에 있는 회사는 그들의 배경에 따라서 구분된다.
첫번째, Linux 내부나 다른 OSS 제품에 배경을 가진 회사가 있다. 그
들은 그들의 제품 지식에 의지하는 서비스를 확립하려 노력하고 있다.
그들의 핵심역량은 기술과 제품에 대한 지식이다. 그들의 대부분은 전범
위에 걸친 서비스를 제공한다. Linux 공급자, 틈새와 전문 공급자, 독립
적인 OSS 서비스 회사가 이 범주에 속한다.
- 33 -
두번째, 전반적인 IT와 관련된 서비스의 제공을 위해 특별한 프로세스
지식을 가진 회사들이 있다. 이들은 IT 컨설팅이나 시스템 통합,
IT-training, IT-recruiting 면에서 지식을 갖고 있으며, 때로는 수직적인
기능이나 산업적인 특수성에 대한 전문성을 가지기도 한다. 그들은 OSS
related 서비스에 대한 그들의 제공을 확장할 수 있다.
○ OSS 지식에 기반하는 다양한 서비스를 제공하는 전방위 서비스 회사
∙ Linux 공급자 : Red Hat, SuSE, Caldera, MandrakeSoft, Turbolinux
∙ 틈새와 전문 공급자 : Zope, MySQL, Sendmail.com,
Covalent Technologies
∙ 독립적인 OSS 서비스 회사 : Linuxcare
∙ Small service & Integration 회사 : Linux Information Systems,
B-connected
○ 통합과 서비스 지식을 기반으로 한 특별 서비스 회사
∙ 컨설팅과 시스템 통합 : Global System Integrators; Accenture,
KPMG, PricewaterhouseCoopers etc
∙ 훈련 : Microconsult, 다양한 훈련과 e러닝 기업
∙ 리쿠르팅 & 참모 서비스 : StepStone-IT, Monster.de,
JobUniverse.de
① 제품과 서비스 제공
가. 주요 요소와 Linux 경험
컨설팅 회사와 SI회사는 그들의 고객이 IT전략을 달성할 수 있도록 돕
는다. 중요 요소는 Lniux 전문지식이다. 작은 통합사업자와 서비스 회사
는 OSS 개발을 배경으로 하고 서비스에 기반하는 사업을 구축하기 위해
노력한다. 큰 통합사업자는 Linux 전문가를 확보하거나 OSS 개발자를
고용하기 위해 그들의 Unix 전문가들을 활용할 수 있다.
OSS를 지원하는 전통적인 모델이 많은 기업 고객에 의해 받아들여지
지 않음에 따라 지원 회사들은 다양한 서비스 모델을 제공하고 있다. 상
업적인 지원은 개발자 커뮤니티에 전적으로 의존하지 않으면서 지원할
수 있는 OSS 제품을 가져야 한다.
- 34 -
나. 지원 계약의 범주
∙ 계약의 범주 : 설치 지원, 지원 패키지, 연간 지원 계약
∙ 지원 방법 : 전화, e메일
∙ 지원 수준 : 첫번째 수준 = smaller problems, end-user targeted
두번째 수준 = administrator
세번째 수준 = developer targeted, sometimes
including source code changes
∙ 시간 및 날짜의 적용 범위 : 24x5, 24x7, 365days/year
∙ 반응 시간 : 최고 상태에서 1~8시간, 1~16시간, next business day
∙ 지원 제품 목록 : 하드웨어와 소프트웨어
∙ Personalisation : 개인적인 컨설팅과 감사를 포함
∙ 패치 : 업데이트 관리
∙ 지원 인프라 형식 : 데스크탑 PC에서 메인프레임
② OSS-related 서비스와 지원을 위한 시장
가. 시스템 통합을 위한 고객
시스템 통합을 위한 고객은 소기업부터 대기업까지를 포함하며 그것은
제품의 대가를 지불하는 대신 솔루션에 대한 대가를 지불한다. 그런 까
닭에, 그 서비스는 프로젝트에 연관된다.
나. 지원
지원은 어떤 시장과 어떤 사용자 수준에서도 필요하다. 예를 들어
OEM(original equipment manufacturers)과 ISV(Independent Software
Vendors)가 있을 수 있으며 그들의 제품에 Sendmail을 포함할 때
Sendmail.com의 고객이 될 수 있다. 새로운 제품이 구현될 때 시스템 관
리자에게는 지원이 필요하다. 또한, 개인과 기업 유저도 그들의 제품과
함께 지원을 필요로 한다.
다. 교육 훈련
OSS 교육훈련을 위한 Customers는 다양한 수준에서 사용자가 된다.
예를 들면 Red Hat은 고전적인 세미나에서 유저, 시스템 관리자, 개발자
에 대한 훈련 코스(e러닝 포함)를 제공한다. 고객은 일반적으로 business
- 35 -
-related 사용자를 말한다. Red Hat사의 훈련 상품은 Red Hat Linux 공
급에 초점을 맞추고 소프트웨어와 관련된다. "E-Business" 하에서 그들은
SAP-Red Hat 통합에 대한 코스를 제공한다.
③ 비즈니스 모델의 강점과 약점
가. 제품 노하우와 프로세스 노하우의 중요성
앞서 언급한 것처럼 OSS-related 서비스 시장에서 활동하는 회사들은
근본적으로 두개의 다른 그룹이 있다. OSS 배경을 가지는 회사는 실질적
인 제품과 기술 지식을 가지고 있다. 그런데 그들은 지식을 서비스 사업
을 만들기 위해 이용한다. OSS 제품에만 기반하는 사업은 OSS의 개발과
수용에 달려있다.
OSS 배경이 없는 회사는 그 서비스에서 과정 지식을 한 부분으로 보
유하고 있다. 그들은 그들의 OSS-related 서비스에까지 그들의 제공을 확
장하려고 노력한다. 기업의 한 그룹 또는 다른 그룹에서의 성공여부는
분리된 서비스 분야에서 제품 노하우와 프로세스 노하우가 중요하다.
나. 전략적 컨설팅과 제품 지원
전략적 컨설팅은 방법론과 과정의 노하우가 극히 중요하고, 제품 노하
우는 상대적으로 덜 중요한 서비스 분야다. 한편 제품지원은 첫째로 제
품 노하우를 요구한다. 반면에 지원 프로세스에 관한 지식은 컨설팅 비
즈니스에서 프로세스 노하우로서 인식될 수 있다.
OSS를 배경으로 하는 회사는 제품 지식이 중요하고 프로세스 노하우
가 쉽게 획득될 수 있는 역에서 주로 성공할 수 있을 것이다. 이것은
지원과 훈련의 제공이 필요한 케이스다. 특별한 OSS 지식이 없는 참여자
는 이 지식이 단지 중요하지 않은 역할을 하거나 쉽게 획득될 수 있는
분야에서 성공할 수 있을 것이다.
- 36 -
Ⅳ. 오픈소스 활용 시 유의 사항 및 활용 프로세스
1. 유의 사항
(1) 개요
오픈소스 소프트웨어(Open Source Software)는 소스 코드의 공개로 인
한 Royalty Free, 자유로운 사용/복제/수정/배포의 허락, 빠른 기술 발
전 속도 등의 강점을 바탕으로 전 세계적으로 그 역을 급속히 확장시
키고 있다. 또한 Linux를 주축으로 한 오픈소스 소프트웨어를 활용한 개
발이 국내에서도 확대되고 있는 상황이다. 그러나 오픈소스 소프트웨어
역시 개발자의 지적 활동의 소중한 결과물로서 관련 지적재산권법에 의
해 보호되고 있다는 사실은 많이 알려져 있지 않은 것이 현실이다.
상용 소프트웨어를 사용하기 위해 라이센스 준수가 필수적이듯 오픈소
스 소프트웨어 역시 이를 사용하기 위해서는 해당 오픈소스 소프트웨어
의 라이센스 준수가 반드시 선행되어야만 하는 것이다. 이를 위반할 경
우, 우선 해당 오픈소스 소프트웨어에 대한 사용 권리가 박탈되기 때문
에 제품화를 한 경우 더 이상 제품을 판매할 수 없게 된다. 그리고 오픈
소스 커뮤니티로부터의 Claim 및 라이센스 위반 기업(기관)이라는 이미
지 훼손 및 신뢰성 추락을 예상할 수 있을 것이다. 이외에도 최악의 경
우에는 법률 소송에 휘말릴 수 있으며, 각 라이센스에서 요구하는 벌칙
을 받아야 할 것이다.
(2) 오픈소스 소프트웨어의 법적 보호 장치
앞서 언급한 것처럼 오픈소스 소프트웨어 역시 상용 소프트웨어와 동
일하게 법적 보호를 받고 있다. 이러한 법적 보호의 수단으로 Copyright
및 License를 활용하고 있다. 현재 배포되는 모든 오픈소스 코드를 보게
되면 주로 다음과 같은 두 가지 형태의 Copyright 및 License Notice를
볼 수 있다.
① 모든 소스 파일에 명시: 이 경우 보통 소스 파일의 처음 부분을 주
- 37 -
석으로 처리하여 Copyright 및 License Notice를 명시하고 있다.
② 최상위 디렉토리에 Copying 파일 배치: 모든 소스 파일에 명시하
는 대신 Copyright 및 License Notice등 법률적 사항을 별도의
Copying 파일에 명시하고 이다. 이런 형태는 보통 소스 코드 사이
즈가 큰 프로젝트에서 많이 이용되고 있으며, 대표적으로 Linux를
들 수 있다.
오픈소스 라이센스는 현재 Open Source Initiative(이하 OSI)에서 오픈
소스 소프트웨어로 인정 받을 수 있는 10가지 ‘라이센스’ 조건을 정의하
고, 각각의 라이센스를 분석하여 오픈소스 라이센스에 해당하는지 여부
에 대해 판단하고 있다.
오픈소스 라이센스는 소프트웨어의 사용, 복제, 배포, 수정의 자유를
부여함과 아울러 다른 한편으로는 소프트웨어의 사용자에게 일정한 의무
를 부과하고 있다.
만약 사용자가 이러한 의무를 이행하지 않으면 저작권자로부터 저작권
위반 (또는 계약 위반)으로 소송을 제기 당할 수 있다. 그 결과 권리를
침해한 것으로 결론이 내려지면 소프트웨어의 배포가 더 이상 불가능할
뿐만 아니라 이미 배포한 소프트웨어에 대한 손해배상 등 막대한 책임을
부담하게 된다.
특히 임베디드 소프트웨어의 경우 이를 내장한 제품까지 판매하지 못
하거나 Recall 해야 하는 경우도 발생할 수 있으므로 라이센스의 의무사
항을 명확히 이해하여 이와 같은 상황을 사전에 예방하는 것이 필수적이
다. 그러나 이러한 위험 때문에 오픈소스 소프트웨어를 전혀 사용하지
않겠다는 결론을 내리는 것은 현명하지 못한 생각이다.
앞에서 지적한 바와 같이 상용 소프트웨어 라이센스에서 규정하고 있
는 의무사항에 비하면 오픈소스 라이센스가 요구하고 있는 내용이 결코
어려운 것이 아니므로, 오히려 이를 잘 이해하고 이를 준수함으로써 오
픈소스 소프트웨어의 장점을 적극 활용할 필요가 있다.
또한 몇몇 라이센스만이 독자 개발한 소스 코드의 공개를 요구하고 있
기 때문에 이를 잘 분석한 후 사용한다면 문제 발생 소지는 거의 없을
것이다.
OSI에서는 현재 인증 마크제를 도입/운 하고 있기 때문에, 소프트웨어
- 38 -
패키지 상에 “OSI Certified’란 표시가 있으면 그 소프트웨어의 라이센스
는 OSD를 만족시키는 오픈소스 라이센스임을 쉽게 알 수 있다.
<그림 3> OSI Certified Mark
2. 오픈소스 활용 프로세스
앞서 살펴본 것처럼, 오픈소스를 활용하기 위해서는 상용 소프트웨어
와 마찬가지로 반드시 해당 오픈소스의 라이센스에 대한 준수가 필수적
이다. 하지만 오픈소스 라이센스에서 강제하고 있는 내용에 대해서 개발
자들을(Developer) 비롯한 관리자들(Manager)의 이해가 아직도 많이 부
족한 것이 현실이며, 자칫 잘못하면 라이센스 위반 양산 또는 개발 결과
물(Source Code)을 공개해야 하는 상황을 초래할 수도 있을 것이다. 따
라서 오픈소스 활용에는 반드시 체계적인 프로세스가 필요하며, 본 장에
서는 이에 대해 설명할 것이다.
오픈소스 라이센스 관련 문제를 사전에 방지하기 위해서는 계획 단계
부터 이를 고려하여야 한다. 그렇지 않으면, 개발이 끝난 후 문제를 발견
하게 될 것이며, 이럴 경우 처음부터 다시 개발해야 하는 엄청난 개발
비용의 낭비 요인이 발생할 수 있기 때문이다. 또한 개발이 진행되면서
도 개발 단계별로 준수해야 할 사항들을 반드시 지켜야만 한다. 본 문서
- 39 -
에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 S/W 개발
프로세스를 아래와 같이 표준화/단순화하 다.
<그림 4> S/W 개발 프로세스
기획(SW Design) ➡
구현(Implementation) ➡
검증(Verification) ➡
제품화(Production)
(1) 기획(S/W Design)
오픈소스 라이센스 관련 문제를 피하는 가장 좋은 방법은 개발 기획
시점부터 이를 고려하는 것이다. 좀 더 구체적으로 알아보면, 우선 해당
과제에 오픈소스를 활용할 것인지의 여부를 판단하여야 한다. 그런 후
활용하고자 하는 오픈소스의 라이센스를 반드시 확인하여야 한다. 그리
고 기획 단계의 마지막으로 해당 S/W Component별로 소스 코드 공개
가능 여부를 판단하여야 한다.
① 오픈소스 활용 여부 결정
해당 과제에 오픈소스를 활용할지에 대한 판단의 기준으로 다음의 사항
들을 참조할 수 있을 것이다.
가. 장점
• Low Entry Cost : 일반적으로 오픈소스는 Web 상에서 무료로 다
운로드 및 소스 코드 수정/ 재배포가 가능한 것이 특징이다. 따라
서 초기 개발을 시작하기 위해 필요한 비용이 거의 들지 않는 장
점이 있다.
• Reliability & Stability : 오픈소스의 개발 과정을 볼 때, 전세계에
있는 수많은 우수한 개발자들이 직접 개발과 Debugging 과정에
참여하기 때문에 In-house에서 폐쇄적으로 개발되는 상용 프로그
램에 비해 비교적 안정적으로 동작한다는 평이 일반적이다. 하지만
이러한 Reliability와 Stability는 많은 개발자들의 적극적인 참여가
- 40 -
있을 때에만 가능한 것이기 때문에, 사용하고자 하는 오픈소스의
개발 과정 역시 주요 고려대상이 될 수 있다.
참고로 아래 그림은 최근 OSDL에서 발표한 Linux Kernel 개발
과정이다. 이를 보면 Linux Kernel이 단순히 Community 멤버들의
자발적인 참여에 의해 이루어지는 것이 아니라 체계적이고 과학적
인 개발 방법론에 의해 이루어지고 있음을 알 수 있다.
<그림 5> Linux 커널 개발 프로세스
* 자료 : OSDL
• Security : 일반적으로 Virus나 Worm은 System의 취약한 부분, 즉
Bug를 통해 침입하기 때문에 위의 2번을 고려할 때 오픈소스는 상
용 프로그램에 비해 Security 면에서 좀 더 안전하다고 볼 수 있
다.
• Networking : 오픈소스가 확산된 가장 큰 이유가 다양하고 강력한
Networking 기능 지원이라 해도 과언이 아닐 것이다. 대표적으로
Apache는 전세계 웹 서비스의 절반 이상을 차지하고 있을 정도이
다. 또한 Open Source Networking Solution은 대부분 상용 프로
그램과 호환되기 때문에 상품화에도 아주 잘 활용될 수 있을 것이
다.
- 41 -
• Fast, Flexible Development : 오픈소스 커뮤니티는 보통 최신 기술
정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운 되기
때문에 상용 프로그램에 비해 기술 발전 속도가 빠르다.
• Open Formats & Protocols : 오픈소스는 주로 Open Formats 또는
Protocols을 사용하기 때문에 서로 다른 소프트웨어간 상호 연동성
이 보장되는 장점이 있다. 모든 기기들이 서로 다른 Network을 통
해 하나로 연결되는 Ubiquitos 시대에는 그야말로 필수적인 요소
라 하겠다. 또한 오픈소스 운동의 주 원인 역시 상용 프로그램들
간의 비호환성을 해결하는 것이다.
나. 단점
• Lack of Application : 대부분의 사용자들은 Windows 기반의 GUI
(Graphical User Interface)를 갖고 있는 Application에 익숙해 있지
만, 이에 버금가는 Linux 기반의 Application이 많이 부족한 것이
현실이다. 또한 Linux 기반으로 개발된 많은 Application들은
Windows 기반 Application들과 호환되지 않는 문제점도 있다. 단
적인 예로 WinCE기반의 PDA 사용자가 Linux 기반의 PDA 사용
자보다 훨씬 다양한 Application을 이용할 수 있고 또 PC(Personal
Computer)와의 연동성 역시 훨씬 쉽게 이용할 수 있는 것이 사실
이다.
• Poor Documentation : 상용 프로그램에 비해 오픈소스는 체계적인
문서를 갖고 있지 못한 단점이 있다. 이는 경우에 따라서는 개발
과정의 지연을 초래할 수도 있기 때문에 활용하고자 하는 오픈소스
가 얼마만큼 문서화가 잘 되었는지도 잘 살펴보아야 한다.
• Uncertain Roadmap : 오픈소스는 리를 목적으로 하는 회사에서
개발되는 것이 아니라, 자발적 참여를 바탕으로 Web 상에서 자유
롭게 개발되는 것이 특징이다. 그렇기 때문에 상용 프로그램에서
볼 수 있는 Roadmap을 기대하기 힘든 면이 있다. 오픈소스의 이러
한 단점은 오픈소스를 활용하는 개발 과제의 Roadmap에 까지
향을 미칠 수 있기 때문에 활용하고자 하는 오픈소스의 향후 개발
계획이 얼마나 체계적으로 세워져 있는지도 고려해야 한다.
- 42 -
② 특허 보호
오픈소스에 회사 또는 단체가 보유한 특허를 포함시킬 경우 오픈소스
라이센스는 일반적으로 Royalty-free를 요구하고 있다. 따라서
Royalty-free를 원치 않을 경우에는 해당 오픈소스를 사용할 수가 없으
며, 또한 사용 후 Royalty를 주장하게 되면 해당 오픈소스에 대한 사용
권한은 박탈되는 경우가 일반적이다. 따라서 오픈소스를 활용하여 특허
를 구현하고자 할 경우, 반드시 Royalty에 대한 입장을 명확히 하여야
할 것이다.
③ 오픈소스 라이센스 확인
해당 과제에 오픈소스를 사용하기로 결정하 다면 구체적으로 어떤 프
로그램을 사용할 지를 판단하여야 한다. 오픈소스의 특성상 Web 상에
여기저기 흩어져 있지만, 쉽게 오픈소스에 관한 정보를 찾을 수 있는 곳
으로는 다음과 같다.
• Freshmeat.net
• SourceForge
• OSDir.com
• BerliOS
• Bioinformatics.org
위의 사이트들은 대부분 License별 오픈소스 분류 항목을 두고 있기
때문에 쉽게 해당 프로그램의 라이센스를 확인할 수 있을 것이다.
④ 소스 코드 공개 가능 여부 결정
이제 과제 기획 단계의 마지막으로 S/W Component별 소스 코드 공
개 가능 여부에 대하여 결정하여야 한다. 이에 따라 S/W 구현 방법이
많이 달라지기 때문이다. 소스 코드 공개 여부 판단 기준으로 다음의 사
항을 참조할 수 있을 것이다.
가. 장점
• Maintenance : 소프트웨어의 경우 하드웨어와 달리 개발 후 지속
- 43 -
적 Upgrade 및 Debugging과 같은 Maintenance 과정이 중요하다.
이러한 Maintenance 과정은 상당한 Resource를 요하기 때문에
Maintenance를 직접 할 것인지에 대한 고려가 필요하다. 개발한
소스 코드를 오픈소스 커뮤니티에 공개하고, 이를 바탕으로 오픈
소스 커뮤니티를 통한 Maintenance 방법 역시 경우에 따라 아주
효율적일 수도 있을 것이다.
• Fast Development : 오픈소스의 개발 모델 중 가장 특징적인 것이
바로 ‘Release Early and Often’을 통한 ‘Parallel Development
and Debugging’이 가능한 것이다. 이를 통해 오픈소스는 빠른 개
발 속도를 가능케 하고 있다. 이러한 모델을 Resource가 부족한 개
발 과제에 적용하면 보다 효율적이고 빠른 개발이 가능할 것이다.
• Reliability 확보: S/W의 신뢰성 확보의 가장 좋은 방법은 다양한
사용자들이 다양한 환경에서 해당 프로그램을 사용하면서 발견되
는 문제점을 신속히 수정하는 것이다. 이런 측면에서 볼 때 오픈
소스 커뮤니티를 잘 활용하면 S/W Reliability 확보에 상당한 도
움을 얻을 수 있을 것이다.
나. 단점
• 차별화 유지 어려움 : 소스 코드를 공개하게 되면 그 소스 코드는
경쟁사에게도 공유되는 것이기 때문에 결국 제품의 차별화 확보가
불가능하게 되는 단점이 있다.
• IP 확보 불가능: 회사 또는 단체가 보유한 특허를 구현하여 소스
코드를 공개하는 것은 결국 모든 사용자들에게 Royalty-free의 조
건으로 특허를 공개하는 것이나 마찬가지가 된다.
• 특허 침해 소송 제기 가능성 증가: 소스 코드가 공개되어 있으면
누구든 그 소스 코드를 볼 수 있기 때문에 특허 침해 소송 제기
가능성이 증가하게 되는 문제점이 발생할 수 있을 것이다.
(2) 구현(Implementation)
자체 개발한 소스 코드를 공개해도 무방한 경우는 특별히 구현 방법에
신경 쓸 필요가 없다. 단, 소스 코드를 공개할 경우 회사 또는 단체 보유
- 44 -
특허는 구현하지 않도록 주의할 필요가 있다. 그러나 소스 코드 공개를
원하지 않을 경우는 사용하는 오픈소스의 라이센스 강제 사항과 활용하
고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한
경우가 발생할 수 있기 때문에, 이럴 경우는 라이센스 혹은 법률 전문가
에게 의뢰하여 정확한 판단을 받아야 할 것이다.
(3) 검증(Verification)
이제 개발이 완료 되었으면, 개발 결과물인 소스 코드에 대해 실질적
인 검증 작업이 필요하다. 왜냐하면, 개발 계획서 그 자체로는 라이센스
이슈가 없었더라도 실제 구현 과정에서 개발자의 오픈소스 코드에 대한
라이센스 이슈 검증없이 사용된 경우가 있을 수 있기 때문이다.
<그림 6> Blackduck 툴 Overall Architecture
- 45 -
소스 코드 레벨에서 수많은 오픈소스 코드와 비교하는 것이 불가능할
것으로 생각될 수도 있지만, 최근 미국의 Blackduck社에서는 이러한 요
구에 착안하여 소스 코드 레벨에서 오픈소스 코드의 사용을 확인할 수
있는 검증 도구를 개발하여 판매 중에 있다. 세부 내용은 Blackduck社의
웹사이트를 참조하기 바라며, 본 문서에서는 동작 원리에 대해 간략히
설명할 것이다. Blackduck社에서 개발한 검증 도구는 Eclipse Platform
기반의 서버-클라이언트 형식으로 되었다.
서버에는 수많은 오픈소스 코드를 Fingerprint 형식으로 Database化한
Knowledge System을 갖고 있으며, 사용자 프로그램인 클라이언트에서는
서버에 접속하여 자체 개발한 프로젝트의 소스 코드와 서버의 Database
에 있는 오픈소스 코드를 비교하여 유사/동일한 소스 코드 사용에 대해
Report를 해주는 방식이다. 이 Report를 바탕으로 라이센스 전문가는 실
제 사용된 오픈소스 코드의 문제 여부를 최종 판단할 수 있게 된다.
(4) 제품화(Production)
① 소스 코드 공개
제품화 단계에서는 소스 코드 공개와 관련된 작업이 있다. 우선 소스
코드 공개 방법으로 다음의 경우가 가능하다. ‘제품 판매 시 a) 제품과
함께 Machine-readable한 소스 제공, b) 제품과 함께 Written Offer만 제
공하며 이를 통해 소스 제공에 대한 약속 및 정보 제공, 실제 소스는 웹
사이트에 공개’. 이 중 a)는 소스 제공이라는 측면에서는 가장 확실한 방
법이 되겠지만 비용이 많이 들고 비효율적인 방법이다. 따라서 회사 또
는 단체 입장에서는 b)의 방법을 이용하는 것이 더 효율적일 것이다.
② 사용자 메뉴얼 작성
거의 대부분의 오픈소스 라이센스는 해당 오픈소스를 사용할 경우, 사
용자에게 오픈소스를 사용하고 있음을 알릴 것을 요구하고 있다. 즉, 사
용자가 쉽게 접할 수 있는 문서(예: 사용자 메뉴얼) 등에 그 제품에 포
함된 오픈소스 현황을 명시하고 관련 라이센스를 알려줘야 한다.
- 46 -
<그림 7> SONY의 오픈소스 공개 사례
- 47 -
Ⅴ. 결론 및 제언
오픈소스 소프트웨어는 상용소프트웨어의 입장에서는 장애물이 되고
있지만 장기적으로 그 확산의 폭이 더 넓어질 것으로 예상된다. 왜냐하
면 오픈소스의 철학이 소프트웨어의 확산 및 이용 활성화를 지원한다는
인식아래 대부분의 국가에서 오픈소스 소프트웨어 활성화를 위한 다양한
정책을 펼치고 있기 때문이다.
이렇게 활발한 활동에 의해 창출된 오픈소스 소프트웨어를 비즈니스적
으로 이용하기 위해서는 오픈소스의 법적 특성을 잘 알고 사용해야 한
다.
특히 기업이 독립적으로 소프트웨어를 개발하는 것보다 이미 다수의
개발자와 사용자가 참여하여 이용/개선하고 있는 오픈소스를 활용하는
것이 비용이나 시간을 절감하는 데 크게 기여할 수 있지만 오픈소스는
다양한 형태의 라이센스를 가지고 제공되고 있으므로 그 특성을 잘 알고
사용하지 않으면 큰 곤란을 겪을 수 있다.
또한 오픈소스 소프트웨어 관련 커뮤니티의 활동이 왕성해짐에 따라
오픈소스를 이용하여 비즈니스를 추구하는 기업들은 더욱 조심스럽게 접
근을 해야 한다. 즉 커뮤니티에 대해 적절하게 대응하고, 커뮤니티와의
협력을 통해 자원을 구해야 할 것이며, 소프트웨어를 자체 개발하거나
외부기관에 의뢰하여 개발하는 경우 그 소스를 명확히 분석하여 대응하
여야 할 것이다.
한편 오픈소스 소프트웨어를 기반으로 수익을 창출하는 방법에는 제품
을 공급․판매하는 사업과 소프트웨어 개발/유지보수/컨설팅/교육 등을
위주로 하는 서비스 제공 사업이 있다.
첫 번째, 패키지 공급․판매사업은 공급자(Distributors)와 소매상
(Retailers)의 사업모델이 되며 여기에는 독창적인 Linux 공급자, 틈새 또
는 전문 공급자, 보완․주변제품의 소매상 등이 있다.
Linux 공급자는 공급제품의 개발시 많은 투자를 하지 않아도 된다. 하
지만 공급자에 의해 창출되는 부가가치가 패키징에 불과하기 때문에 상
- 48 -
용소프트웨어와 같은 방식으로 높은 가격을 책정할 수 없다. 따라서
Linux 배포사업에 있어 가장 중요한 성공요소는 브랜드가 되므로 광고,
전시, 홍보 등을 통해 브랜드를 만들고 독자적인 판매채널을 구축하여야
한다.
틈새․전문 공급자는 개인이나 다수기업을 직접적인 목표로 설정하지
않고 그들의 웹사이트에서 주문을 받고 일반 채널을 통해 공급되는 제한
된 수의 패키지를 제공한다. 즉 고객에게 최적화된 HW-SW번들이나 내
장제품을 개발하여 공급하는 것이다. 이 경우 소스에 대한 접근이 제한
적이지 않기 때문에 단순히 소프트웨어를 파는 것만으로는 유지할 수가
없다. 따라서 대부분의 공급자가 그들 제품에 컨설팅과 지원 등 다양한
부가서비스를 판매해야 한다.
보완․주변제품의 소매상은 공급자의 소프트웨어 제품을 팔거나 부가
적으로 매뉴얼과 각종 정보를 판매한다. OSS시장이 사용자 측으로 이동
하고 있으므로 고객 접근이 용이하고 브랜드가 많이 알려진 소매상이 유
리한 비즈니스 모델이 될 것이다. 또한 OSS가 더욱 대중화 되고 OSS커
뮤니티 밖에서 이용됨에 따라 문서화가 중요해지고 있다.
두 번째, 서비스 제공사업은 OSS개발․커뮤니티 조정자와 OSS 관련
서비스․지원 조직이 있다.
OSS개발과 커뮤니티 조정자는 거래시장과 컨퍼런스나 거래전시행사를
개최하는 것이다. 거래시장에서 개발자들은 요금 지불의사가 없으므로
수요자에게서 수익을 유도해야 한다. 하지만 수요자는 개발자 커뮤니티
를 신뢰하기 어려운 상황이므로 이 비즈니스 모델은 수익을 내기 어렵
다. 또한 컨퍼런스 역시 수익을 내기 어려운 비즈니스 모델이며, 방문자
가 늘고 있는 거래 전시회만이 매력적인 분야라 할 것이다.
OSS관련 서비스․지원은 컨설팅, 시스템 통합, 지원, 유지보수, 원격관
리, 훈련, 응용관리 등과 같은 서비스를 포함한다. 이 비즈니스 모델은
OSS에 대한 기술적인 배경을 가지는 회사와 그렇지 않은 회사로 구분되
는데 OSS에 대한 배경을 가진 회사는 제품 지식이 중요하고 프로세스
노하우를 만들 수 있는 역에서 성공할 수 있을 것이며, OSS에 대한 배
경이 없는 회사는 지식이 중요하지 않거나 쉽게 획득될 수 있는 역에
서 성공할 수 있을 것이다.
오픈소스를 활용하기 위한 프로세스는 기획, 구현, 검증, 제품화의 단
- 49 -
계로 구성된다.
기획단계에서는 오픈소스 활용여부를 결정하고 특허보호, 오픈소스 라
이센스 확인, 소스 코드 공개여부 결정 등을 고려해야 한다.
구현단계에서 소스 코드를 공개해도 무방한 경우엔 특별히 구현 방법
에 신경 쓸 필요없지만 소스 코드 공개를 원치 않는 경우 활용하는 라이
센스의 강제사항과 활용형태에 따라 다양한 경우가 발생할 수 있으므로
법률 전문가의 자문을 받아야 할 것이다.
검증단계에서는 오픈소스 라이센스가 사용된 경우를 탐색해야 한다.
이 과정은 수작업으로 하기에는 많은 어려움이 따르는데 최근에는 이러
한 역할을 대신하는 툴이 나와 있으므로 이를 활용하는 것도 한 방법이
다.
제품화단계에서는 소스 코드 공개와 함께 사용자 매뉴얼을 작성하여
제공해야 한다.
현재 많은 장점을 가진 오픈소스 소프트웨어의 활용이 기대만큼 확산
되지 않는 것은 성공적인 활용사례가 적고 오픈소스 소프트웨어 도입후
문제가 발생할 경우 책임소재를 명확히 할 수 없기 때문이다.
따라서 향후 오픈소스 활용의 확산을 위해서는 성공사례를 만들고 이
를 널리 알리며, 오픈소스 사용에 따르는 사후처리문제와 법률적인 책임
소재를 명확히 할 수 있는 지원체계를 확립해야 할 것이다.
- 50 -
기업의 오픈소스 소프트웨어 활용방안
서울특별시 영등포구 여의도동 28-1
TEL: 780-0201~7 FAX: 782-1266
http://www.fkii.or.kr
![For The Region: Report, Report, Report [Eng]](https://static.fdocuments.net/doc/165x107/579079761a28ab6874c751c6/for-the-region-report-report-report-eng.jpg)
![[MS-RPL]: Report Page Layout (RPL) Binary Stream Format€¦ · MS-RPL] —. stream report. report page. report report report](https://static.fdocuments.net/doc/165x107/5fd9f7a7a90b7c34145fa364/ms-rpl-report-page-layout-rpl-binary-stream-format-ms-rpl-a-stream-report.jpg)
