Professional Documents
Culture Documents
Kesic Report
Kesic Report
Kesic Report
2004. 10
이 자료는 한국정보산업연합회 임베디드소프트웨어산업협의회에서 삼
성전자(최민석 연구원)의 협조로 작성한 것입니다. 내용과 관련하여 문의
사항이 있으시면 아래로 연락 주시기 바랍니다.
한국정보산업연합회 임베디드소프트웨어산업협의회
TEL: 780-0201~4, E-mail: fkii@fkii.org
- 2 -
목 차
Ⅴ. 결론 및 제언 ··················································································· 47
표/그림 목차
- 1 -
소스 소프트웨어가 필요하다는 데 공감하고 있다.
여기서는 오픈소스 소프트웨어의 개념과 다양한 특징 및 저작권 등과
관련된 문제들을 짚어 봄으로써 오픈소스 소프트웨어의 비즈니스적 이용
에 따르는 문제점 및 해결방안을 모색해 보고자 한다.
1. 오픈소스 소프트웨어의 조건
- 2 -
한을 설정해서는 안된다.
⑦ 라이센스의 배포(Distribution of License) : 프로그램에 대한 권리는
반복되는 배포에 따른 별도의 라이센스 승인이나 양도 과정 없이도
프로그램을 배포받은 모든 사람에게 동일하게 적용된다.
⑧ 라이센스 적용상의 동일성 유지(License Must Not Be Specific to a
Product) : 라이센스는 반복 배포 과정에서 특정한 배포판에 포함되
어 있는 상태로만 유효하지 않고 모든 배포 단계에서 동일한 효력
을 갖는다. (특정한 배포판에 포함되어 있던 프로그램을 독립적으로
사용하거나 재배포할 경우에도 해당 프로그램을 배포받은 사람은
프로그램이 포함되어 있던 최초의 배포판 상태에서 발생된 권리와
동일한 권리를 갖는다.)
⑨ 다른 라이센스의 포괄적 수용(License Must Not Contaminate
Other Software) : 라이센스에 오픈소스 소프트웨어와 함께 배포되
는 소프트웨어에 대한 제한을 설정해서는 안된다.(예를 들면, 동일
한 매체를 통해서 배포되는 소프트웨어는 모두 오픈소스 소프트웨
어여야 한다 등의 제한을 해서는 안된다.)
2. 오픈소스 소프트웨어의 특성
- 3 -
과거에는 운영체제와 네트워킹체제 소프트웨어,
유틸리티, 개발도구, 인프라스트럭처 컴포넌트가
어떤 유형의 제품과
오픈소스 소프트웨어의 주종을 이루었다.
프로젝트가
최근에는 생산성 향상과 관련된 응용소프트웨
오픈소스 소프트웨어인가
어, 엔터테인먼트 응용소프트웨어들이 많이 개발
되고 있다.
- 4 -
다수가 참여하는 병행개발방식은 인터넷을 통
해 이루어진다. 인터넷은 의사소통과 협업, 배포
오픈소스 소프트웨어 모델을
플랫폼으로 활용된다.
지원하기 위해 어떤 것들이
학술기관, 비영리기관, 민간기관들, 온라인
사용되는가
Agency service도 오픈소스 소프트웨어 개발을
지원하기도 한다.
- 5 -
Ⅱ. 주요 오픈소스 라이센스와 개발 프로젝트
1. 오픈소스 라이센스
- 6 -
․ 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
- 7 -
․ 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
- 8 -
<그림 1> 오픈소스 라이센스 사용 현황
가. Public Domain
Public Domain으로 소프트웨어를 공개한다는 것은 모든 저작권을 포
기한다는 의미다. Public Domain 원칙은 미국과 같은 법률적 환경에서만
가능한 것이다. 독일에서는 Public Domain에 따라 소프트웨어를 공표하
는 것이 확정되지 않은 상태이다. 미국에서 Public Domain 소프트웨어는
정부의 지원으로 대학교나 연구기관에서 대부분 개발된다. 그 소프트웨
어는 미국시민은 누구나 아무런 제약없이 이용할 수 있다. 상업적인 용
도로 활용하는 것도 허용된다.
- 9 -
나. Shareware
셰어웨어의 의도는 되도록 많은 사람이 사용가능한 소프트웨어를 만드
는 것이다. 셰어웨어는 단지 바이너리 형태로만 배포된다. 대부분의 저작
권 소유자는 일정한 테스트 과정을 거친후에 지불하는 약간의 사용료만
을 부과한다.
셰어웨어 전도자들은 소프트웨어 생산자가 그들의 결과물에 대해 보상
받기를 원하고 있으며 어느정도 정당한 사용이 요구된다고 주장한다. 프
리웨어 개발자들의 경우에는 그들의 권리를 주장하는 데 있어 마이크로
소프트보다 더 어려울 것이다. 셰어웨어 제품은 종종 테스트 기간 후에
사용의 편의성을 감소시키는 메카니즘을 내장하고 있다. 이 메카니즘은
사용자가 그 라이센스에 대한 대가를 지불하고자 하는 의지을 증가시킬
수 있다.
다. Freeware
프리웨어는 사용에 대한 라이센스 요금을 부과하지 않는 바이너리 형
태로 배포된다. 프리웨어는 사용자(개인 또는 비상업적 이용자)들에게 배
타적으로 소프트웨어를 사용할 권리를 부여할 수 있다. 프리웨어는 종종
보완 제품의 촉진을 위한 마케팅전략의 일부분으로 이용된다. 예를들어,
마이크로소프트는 시장점유율의 확대를 위해 Internet Explorer를 공개했
다.
- 10 -
전제로 소프트웨어의 자유로운 공유 및 수정을 보장하고자 하였는데, 그
결과 만들어진 것이 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로 배포하는 것이 가능
- 11 -
는 것이 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
- 12 -
는 라이센스다. MPL은 MPL-software의 사용에 있어 일종의 복제권을
강요한다. GPL과의 주된 차이는 MPL하에 있는 소프트웨어가 전염성 없
는 소프트웨어 제품으로 포함될 수 있다는 것이다. 따라서 MPL의 기본
은 LGPL과 비슷하다. 또 이와 비슷한 라이센스는 IBM Public License나
Sun Public License다. 이 라이센스는 모두 OSI(Open Source Initiative)
의 승인을 받은 것이다.
Freeware ● ● ●
GPL ● ● ● ● ●
LGPL ● ● ● ● ● ●
MPL ● ● ● ● ● ●
BSD-Licens ● ● ● ● ●
e
- 13 -
2. 주요 오픈소스 제품과 개발 프로젝트
① Apache
② Free BSD
- 14 -
핵심개발자 중의 한명인 Jordan K. Hubbard는 현재 애플에 고용되어 있
다. 그런데 이것은 애플과 FreeBSD 커뮤니티 사이의 결속을 강화하고 있
다. Apple 운영체제인 Mac OS X는 FreeBSD를 기반으로 하고 있다.
FreeBSD의 상표권자이며 상업적인 BSD/OS의 공급자인 Wind River는
FreeBSD에 대한 재정적인 계약을 중단하면서 고용하고 있던 FreeBSD 개
발자와의 계약도 해지하고 기술적인 지원도 중단하였다.
③ GNOME
④ GNU
- 15 -
재단(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
⑥ Linux
- 16 -
구성된 몇 개의 계층적인 구조도 있다.
여기에는 많은 조직이 참여하고 있다. 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
- 17 -
② Mozilla
③ Sendmail
- 18 -
④ MySQL
⑤ PostgreSQL
⑥ Perl
- 19 -
문툴을 제공하고 CPAN(Comprehensive Perl Archive Network)은 수백
개의 Perl 모듈에의 접근을 가능케 한다.
⑦ Python
⑧ Tcl/Tk
⑨ Gimp
- 20 -
⑩ Samba
⑪ Zope
- 21 -
Ⅲ. 오픈소스 소프트웨어의 비즈니스 모델
1. 비즈니스 모델 분류
OSS
Business
Model
Distributors OSS-Related
and Services
Retailers
OSS
Niche and Retailers of OSS Service and
Original Linux Development
Speciality OSS Distributions and Support
Distributors Compl.Products and Interest
Distributors Enablers Providers
- 22 -
2. 공급자와 소매상(Distributors and Retailers)
① 제품과 서비스의 제공
가. 사례
Linux 공급자는 그들 자신만의 Linux 운영체제 버전을 포장하여 판매
한다. 독창적인 Linux 공급자의 사례로는 Red Hat, SuSE, MandrakeSoft,
Caldera, Turbolinux와 Slackware 등이다. 공급자는 소비자와 기업 등 엔
드유저에게 다양한 하드웨어를 위해 Linux 운영체제와 서버용, 데스크탑
용, Ecommerce suite와 같은 다양한 소프트웨어 패키지와 번들제품을 공
급한다. IT 관리자에게는 그들이 적용하기에 적절한 관리 도구를 판다.
개발자에게는 OEM(original equipment manufacturers)을 위한 개발 도
구와 다양한 Linux 버전을 판다.
다. 공급자에 대한 찬반 양론
Linux 공급자는 처음부터 그들의 운영체제를 개발하지 않음으로써 막
대한 소프트웨어 개발 비용을 절감한다. 예를 들면, Red Hat 7.1 운영체
제는 10억 달러를 필요로 했던 것으로 평가된다(Wheeler, 2001a). 그들은
여기서 그들의 최적화된 Linux 버전의 개발을 위해 많은 투자를 절감했
다. 반면에 Linux 공급자는 그들의 제품에 상용소프트웨어 생산자와 같
- 23 -
은 방식으로 제품 가격을 산정할 수 없다. Linux의 다수 구성요소가 자
유로이 다운로드 될 수 있기 때문에 그 제품이 공급자에 의해 부가되는
가치는 패키징에 불과하다.
Linux 버전에 기반하는 소프트웨어 제품은 웹사이트에서 다운로드를
통하거나 CD-ROM을 통해 공급된다. 여기서 Linux 공급자는 다수의 판
매 통로를 사용하게 되는데 가장 중요한 것은 VAR(value added
resellers)과 서점을 포함하는 소매상이다.
라. 중요한 성공 요소
Linux 분배 사업에 있어 중요한 성공 요소는 브랜드를 만드는 것이다.
따라서 공급자들은 광고, 전시, 홍보 등 마케팅에 많은 투자를 하게 되고
공급망과 마케팅은 Linux 공급자의 핵심능력이 된다.
마. 부가적인 서비스
이러한 사실에도 불구하고 대부분의 공급자들은 컨설팅, 통합, 지원,
교육훈련 등의 Linux 관련 서비스를 추가적으로 제공하고, 그 서비스는
부가적인 수입원을 생성한다. 더 나아가 티셔츠나 머그컵 등의 판매를
통해 적은 수입을 꾸준히 생성할 수 있다.
② Linux 공급자를 위한 시장
- 24 -
협력을 통해 솔루션 시장에 대응한다. 한편 SuSE와 같은 회사들은 기업
사용자들을 수익의 원천으로 삼고 있다.
가. 낮은 마진
대중시장에서 Linux는 일용품으로 여겨질 수 있다. 왜냐하면 그 컴포
넌트가 무료로 다운로드 받거나 복제될 수 있기 때문이다. 모든 공급자
에 의해 제품화된 다양한 Linux 버전이 부가가치를 형성한다. 하지만 개
당 판매마진은 별로 높지 않다. Linux를 공급하는 제품화 사업은 대중
시장을 목표로 하고 제품을 생산하는 기업은 수익을 높이기 위해 판매를
증가시켜야만 한다.
나. 브랜드에 의한 차별화
그러므로 공급자들은 다른 공급자는 물론 독점 경쟁자들과 차별화할
수 있는 수단을 개발하는데 집중한다. 그리고 이 차별화는 주로 브랜드
에 의해 이루어지며 대중시장에서의 중요한 성공요소가 된다. Red Hat
이나 SuSE와 같은 Linux 공급자는 광고, 전시회, 특화된 교육 등 브랜드
를 만드는 마케팅활동에 많은 노력을 기울였다.
다. 독자적인 판매 채널
두번째 성공요소는 서점이나 VAR(Value Added Reseller)과 같은 판매
채널을 갖는 것이다. 예를 들면, Mandrakesoft는 미국에서는 Macmillan
서점과 협력하고, 독일에서는 작은 컨설팅 회사나 중소기업시장에 접근
하기 위해 통합사업자와 강한 협력과계를 구축하는데 힘을 쏟고 있다.
- 25 -
잠재적 구매자수가 마이크로소프트 박스제품의 구매자에 비해 적어서 마
진이 낮기 때문이다.
Linux를 패키징하고 최적화하는 소프트웨어 지식으로 인해 공급자는
컨설팅과 서비스 사업을 구축할만한 기술적 능력을 갖고 있다. 그러나
그들이 기존의 서비스나 컨설팅 회사에 대응할 경쟁자가 되기 위해 컨설
팅과 비즈니스 프로세스에 노하우를 갖고 있는가는 미지수다.
① 제품과 서비스 제공
가. 운영체제 대신 다른 부문에 특화
틈새시장을 공략하거나 전문성을 가지는 공급자는 운영체제가 아닌 다
른 OSS를 개발하고 공급한다. 그들의 제품은 응용, 개발, 관리를 위한 툴
을 포함한다. 그들의 소프트웨어는 Linux에서 실행되기 위해 개발되지만
몇몇의 제품은 윈도우즈나 다른 운영체제에서도 실행된다. 예를들면
Zope, Sendmail.com, Covalent Technologies, Cygnus, Precision Insight,
MySQL, ActiveState, CollabNet 등을 들 수 있다.
- 26 -
② 틈새와 전문 OSS공급자를 위한 시장
가. 시장점유율이 높은 경우
Samba나 Apache 웹서버와 같은 몇몇 OSS 프로젝트의 시장점유율은
높은 편이다. Security Space에 의해 수행된 웹서버에 대한 조사에서
2001년 10월에 Apache의 시장점유율은 63 퍼센트 였다. Netcraft의 조사
에서도 Apache는 61 퍼센트의 시장점유율을 기록했다. 그러나 이런 결과
가 개발회사가 이익을 얻을 수 있음을 보여주는 것은 아니다.
- 27 -
Insight사는 제품의 최신 버전에 대한 소스 코드는 공개하지 않고 과거
버전만을 공개한다. Sendmail.com에 의해 사용된 다른 방법은 기본적인
sendmail 기능 위에 상업적인 독점소프트웨어를 개발하는 것이다. 기업
이 순수한 OSS분야에 전념하느냐 전통적인 소프트웨어 사업분야에 집중
하느냐 하는 것은 중요한 문제다. 어찌되었든 그들은 양쪽세계에서 모두
살아남을 수 있어야 한다.
(3) 소매상(Retailer)
① 제품과 서비스 제공
② 소매상과 출판업자를 위한 시장
- 28 -
소매상의 이점은 그들의 소매상점을 통해 고객에게 접근한다는 것이
다. 다른 이점은 소매 채널의 널리 알려져 있는 상표다.
웹기반의 리셀러와 전문 Linux 판매점은 브랜드 인지도를 만들어 내는
것이 어렵고 비용이 많이 든다는 것을 알게 된다. 특히 그들이 공급자와
출판사업자와 직접적으로 경쟁할 때는 더 심하다.
일반적으로, 상품화는 그 자체가 비즈니스 모델이 되는 것이 아니고
강한 브랜드가 구축될 때 단지 부가적인 수입원이 된다. 그러므로 상품
화를 통한 수입은 Linux 공급자의 우선적인 관심사항이 된다.
나. 문서화의 필요성
OSS가 더 대중화 되고 OSS 커뮤니티 밖에서 이용됨에 따라 문서화가
필요해졌다. 상업적으로 개발된 소프트웨어의 경우 문서화는 보통 소프
트웨어 생산자나 출판사를 가진 기업에서 행해진다. O'Reilly는 출판지식
과 OSS지식을 결합하여 OSS 서적에 대한 브랜드를 구축하는데 성공했
다. 이 회사는 많은 OSS 프로젝트를 커버하기 때문에 하나의 소프트웨어
개발에 의존하지 않는다.
① 제품과 서비스 제공
가. 거래소
교환이나 거래소의 기능은 잠재적인 구매자와 판매자를 만나게 해주는
것이다. 생산된 소프트웨어는 커스터마이즈되거나 주문생산된 OSS가 될
- 29 -
것이다. 이러한 교환 가능성에 대한 주된 논쟁은 많은 소프트웨어 개발
자가 어떤 프로젝트를 추진할 것인가를 그들 스스로 결정하기를 원한다
는 가정이다. 추가적으로, 세계적인 인터넷 네트워크는 세계적으로 잠재
해 있는 개발자와 가격 인하를 이끌어내는 가능성간에 지렛대 역할을 할
수 있었다.
가. 거래소에 관한 닭-알 문제
거래소는 소프트웨어 공급자와 구매자의 두 그룹으로 정리된다. "공급
자" 그룹은 OSS 개발자 커뮤니티이며 "구매자" 그룹은 특별한 솔루션을
찾는 법인조직의 사용자나 개발자다. 보통, 구매자는 거래소에서 제공된
서비스에 대한 대가를 기꺼이 지불할 것이다. 그러나 그 구매자는 어떤
거래소에 충분한 숫자의 판매자(개발자)가 있는가에만 관심이 있다. 그래
서, OSS 시장은 다른 영역에 있는 많은 시장처럼 닭이 먼저냐 알 먼저냐
하는 닭-알 문제에 직면해 있다.
- 30 -
은 OSS에 대한 철학이 확립되지 않은 비즈니스모델이기 때문에 문제가
될 수 있다. 전통적인 컨퍼런스 사업에서 주최자는 제품이나 기술정보,
노하우에 관심있는 구매자와 판매자의 그룹이다. 그들은 제품의 마케팅
을 위해 행사를 활용하는 판매측으로부터 대부분의 수익을 만들어 내고
있다. 추가적으로 구매자 또는 사람들은 컨퍼런스나 거래 전시회의 입장
료를 지불하고 정보를 획득하는데 관심을 갖고 있다. OSS 사업에서 컨퍼
런스 주최자를 위한 시장이 매력적인가 아닌가는 의문의 여지가 있다.
가. 거래소
지금까지 순수한 거래소와 교환 모델은 실패였다. 단순히 거래를 연결
시켜주는 기능의 사업모델로는 부가가치가 충분하지 않기 때문일 것이
다. 개발자는 서비스에 대한 요금을 지불할 의사가 없으므로 수익은 수
요측면에서 발생될 수 밖에 없다.
수요측면에서 소프트웨어 구매자는 프로젝트의 완성도를 신뢰하기가
어려울 수 있다. 일반적으로 소프트웨어 개발 프로젝트는 보통 원하는
것에 대한 정확한 요구조건을 갖는 계약과 그 하청계약에 의해 수행된
다. 그런데 프로젝트는 종종 계약상의 시간과 비용을 초과하곤 한다. 이
러한 경험에 비추어볼 때 기업이 책임성이 없거나 프로젝트의 완성도에
대한 보증이 확실하지 않은 개발자 커뮤니티를 신뢰하기는 어려울 것이
다. 공급측면에서 이런 비즈니스 모델의 주된 경쟁자는 OSS커뮤니티 자
체와 자원봉사자들에 의해 관리되는 모든 프로젝트가 된다.
나. 무료 서비스의 유용성
연결(Matching) 기능은 서비스 회사의 범위에서 추가적인 서비스로 활
용될 수 있다. 예를 들어 MandrakeSoft사와 같은 몇몇 공급자들은 그들
의 지원제공에서 이 모델을 부분적으로 적용한다. 그들은 OSS 개발자와
전문가에게 특별한 문제의 해결을 위해 일정한 금액을 지불한다.
다. 컨퍼런스 주최자
OSS 컨퍼런스와 전시회는 보통 상당히 낮은 가격을 책정하고 있어서
- 31 -
주최자가 수익을 남기면서 운영을 할 수 있는가에 대해서는 의문의 여지
가 있다. 그들은 높은 컨퍼런스 입장료를 요구할 수 없다. 왜냐하면 관심
을 갖고있는 대부분의 사람들은 OSS커뮤니티 회원들이다. 또한 그들은
소프트웨어 공급자들로부터도 높은 요금을 요구할 수 없다. 왜냐하면 많
은 공급자들이 커뮤니티 이거나 작고 지역적인 서비스 회사들이기 때문
이다. 결국 OSS에 대한 지속적인 관심을 유도하기 위해서는 방문자가 늘
어나고 있는 거래 전시회가 좀더 매력적인 분야라 할 것이다.
컨퍼런스 주최자는 특별한 주제에 대한 관심을 매우 중요시 한다. 그
러나 그들의 핵심 능력은 관심있는 주제에 대한 평가, 관심의 대상이 되
는 사람들의 발굴, 컨퍼런스나 거래 전시회의 관리 등에 대한 전문적인
지식이다. 그러한 능력에도 불구하고 컨퍼런스 주최자는 OSS에 대한 그
들의 비즈니스 모델을 제한할 필요가 없다. 비록 그들의 지식이 OSS 주
제를 평가하기 위해 OSS에만 제한을 두더라도 그들은 소프트웨어 시장
전체에 대한 종합적인 지식을 가져야만 한다.
라. 진입장벽에 대한 평가
OSS 컨퍼런스 시장에서 잠재적인 진입자에 대한 진입장벽은 OSS커뮤
니티 내에서의 평판이 될 수 있다. 몇몇 OSS컨퍼런스 조직은 커뮤니티에
서 확실한 명성을 얻었다. 그러나 OSS 컨퍼런스 사업에서 중요한 요소는
흥미를 가진 방문객의 상당한 숫자가 대부분의 B2B 행사에 지불하는 입
장료만큼 그 회사에 지불할 용의가 있느냐 하는 것이다.
- 32 -
두번째, 전반적인 IT와 관련된 서비스의 제공을 위해 특별한 프로세스
지식을 가진 회사들이 있다. 이들은 IT 컨설팅이나 시스템 통합,
IT-training, IT-recruiting 면에서 지식을 갖고 있으며, 때로는 수직적인
기능이나 산업적인 특수성에 대한 전문성을 가지기도 한다. 그들은 OSS
related 서비스에 대한 그들의 제공을 확장할 수 있다.
① 제품과 서비스 제공
가. 주요 요소와 Linux 경험
컨설팅 회사와 SI회사는 그들의 고객이 IT전략을 달성할 수 있도록 돕
는다. 중요 요소는 Lniux 전문지식이다. 작은 통합사업자와 서비스 회사
는 OSS 개발을 배경으로 하고 서비스에 기반하는 사업을 구축하기 위해
노력한다. 큰 통합사업자는 Linux 전문가를 확보하거나 OSS 개발자를
고용하기 위해 그들의 Unix 전문가들을 활용할 수 있다.
OSS를 지원하는 전통적인 모델이 많은 기업 고객에 의해 받아들여지
지 않음에 따라 지원 회사들은 다양한 서비스 모델을 제공하고 있다. 상
업적인 지원은 개발자 커뮤니티에 전적으로 의존하지 않으면서 지원할
수 있는 OSS 제품을 가져야 한다.
- 33 -
나. 지원 계약의 범주
∙ 계약의 범주 : 설치 지원, 지원 패키지, 연간 지원 계약
∙ 지원 방법 : 전화, 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에서 메인프레임
가. 시스템 통합을 위한 고객
시스템 통합을 위한 고객은 소기업부터 대기업까지를 포함하며 그것은
제품의 대가를 지불하는 대신 솔루션에 대한 대가를 지불한다. 그런 까
닭에, 그 서비스는 프로젝트에 연관된다.
나. 지원
지원은 어떤 시장과 어떤 사용자 수준에서도 필요하다. 예를 들어
OEM(original equipment manufacturers)과 ISV(Independent Software
Vendors)가 있을 수 있으며 그들의 제품에 Sendmail을 포함할 때
Sendmail.com의 고객이 될 수 있다. 새로운 제품이 구현될 때 시스템 관
리자에게는 지원이 필요하다. 또한, 개인과 기업 유저도 그들의 제품과
함께 지원을 필요로 한다.
다. 교육 훈련
OSS 교육훈련을 위한 Customers는 다양한 수준에서 사용자가 된다.
예를 들면 Red Hat은 고전적인 세미나에서 유저, 시스템 관리자, 개발자
에 대한 훈련 코스(e러닝 포함)를 제공한다. 고객은 일반적으로 business
- 34 -
-related 사용자를 말한다. Red Hat사의 훈련 상품은 Red Hat Linux 공
급에 초점을 맞추고 소프트웨어와 관련된다. "E-Business" 하에서 그들은
SAP-Red Hat 통합에 대한 코스를 제공한다.
나. 전략적 컨설팅과 제품 지원
전략적 컨설팅은 방법론과 과정의 노하우가 극히 중요하고, 제품 노하
우는 상대적으로 덜 중요한 서비스 분야다. 한편 제품지원은 첫째로 제
품 노하우를 요구한다. 반면에 지원 프로세스에 관한 지식은 컨설팅 비
즈니스에서 프로세스 노하우로서 인식될 수 있다.
OSS를 배경으로 하는 회사는 제품 지식이 중요하고 프로세스 노하우
가 쉽게 획득될 수 있는 영역에서 주로 성공할 수 있을 것이다. 이것은
지원과 훈련의 제공이 필요한 케이스다. 특별한 OSS 지식이 없는 참여자
는 이 지식이 단지 중요하지 않은 역할을 하거나 쉽게 획득될 수 있는
분야에서 성공할 수 있을 것이다.
- 35 -
Ⅳ. 오픈소스 활용 시 유의 사항 및 활용 프로세스
1. 유의 사항
(1) 개요
- 36 -
석으로 처리하여 Copyright 및 License Notice를 명시하고 있다.
② 최상위 디렉토리에 Copying 파일 배치: 모든 소스 파일에 명시하
는 대신 Copyright 및 License Notice등 법률적 사항을 별도의
Copying 파일에 명시하고 이다. 이런 형태는 보통 소스 코드 사이
즈가 큰 프로젝트에서 많이 이용되고 있으며, 대표적으로 Linux를
들 수 있다.
오픈소스 라이센스는 현재 Open Source Initiative(이하 OSI)에서 오픈
소스 소프트웨어로 인정 받을 수 있는 10가지 ‘라이센스’ 조건을 정의하
고, 각각의 라이센스를 분석하여 오픈소스 라이센스에 해당하는지 여부
에 대해 판단하고 있다.
오픈소스 라이센스는 소프트웨어의 사용, 복제, 배포, 수정의 자유를
부여함과 아울러 다른 한편으로는 소프트웨어의 사용자에게 일정한 의무
를 부과하고 있다.
만약 사용자가 이러한 의무를 이행하지 않으면 저작권자로부터 저작권
위반 (또는 계약 위반)으로 소송을 제기 당할 수 있다. 그 결과 권리를
침해한 것으로 결론이 내려지면 소프트웨어의 배포가 더 이상 불가능할
뿐만 아니라 이미 배포한 소프트웨어에 대한 손해배상 등 막대한 책임을
부담하게 된다.
특히 임베디드 소프트웨어의 경우 이를 내장한 제품까지 판매하지 못
하거나 Recall 해야 하는 경우도 발생할 수 있으므로 라이센스의 의무사
항을 명확히 이해하여 이와 같은 상황을 사전에 예방하는 것이 필수적이
다. 그러나 이러한 위험 때문에 오픈소스 소프트웨어를 전혀 사용하지
않겠다는 결론을 내리는 것은 현명하지 못한 생각이다.
앞에서 지적한 바와 같이 상용 소프트웨어 라이센스에서 규정하고 있
는 의무사항에 비하면 오픈소스 라이센스가 요구하고 있는 내용이 결코
어려운 것이 아니므로, 오히려 이를 잘 이해하고 이를 준수함으로써 오
픈소스 소프트웨어의 장점을 적극 활용할 필요가 있다.
또한 몇몇 라이센스만이 독자 개발한 소스 코드의 공개를 요구하고 있
기 때문에 이를 잘 분석한 후 사용한다면 문제 발생 소지는 거의 없을
것이다.
OSI에서는 현재 인증 마크제를 도입/운영하고 있기 때문에, 소프트웨어
- 37 -
패키지 상에 “OSI Certified’란 표시가 있으면 그 소프트웨어의 라이센스
는 OSD를 만족시키는 오픈소스 라이센스임을 쉽게 알 수 있다.
2. 오픈소스 활용 프로세스
- 38 -
에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 S/W 개발
프로세스를 아래와 같이 표준화/단순화하였다.
기획 구현 검증 제품화
(SW Design) ➡ (Implementation) ➡ (Verification) ➡ (Production)
① 오픈소스 활용 여부 결정
가. 장점
• Low Entry Cost : 일반적으로 오픈소스는 Web 상에서 무료로 다
운로드 및 소스 코드 수정/ 재배포가 가능한 것이 특징이다. 따라
서 초기 개발을 시작하기 위해 필요한 비용이 거의 들지 않는 장
점이 있다.
• Reliability & Stability : 오픈소스의 개발 과정을 볼 때, 전세계에
있는 수많은 우수한 개발자들이 직접 개발과 Debugging 과정에
참여하기 때문에 In-house에서 폐쇄적으로 개발되는 상용 프로그
램에 비해 비교적 안정적으로 동작한다는 평이 일반적이다. 하지만
이러한 Reliability와 Stability는 많은 개발자들의 적극적인 참여가
- 39 -
있을 때에만 가능한 것이기 때문에, 사용하고자 하는 오픈소스의
개발 과정 역시 주요 고려대상이 될 수 있다.
참고로 아래 그림은 최근 OSDL에서 발표한 Linux Kernel 개발
과정이다. 이를 보면 Linux Kernel이 단순히 Community 멤버들의
자발적인 참여에 의해 이루어지는 것이 아니라 체계적이고 과학적
인 개발 방법론에 의해 이루어지고 있음을 알 수 있다.
* 자료 : OSDL
- 40 -
• 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에 까지 영
향을 미칠 수 있기 때문에 활용하고자 하는 오픈소스의 향후 개발
계획이 얼마나 체계적으로 세워져 있는지도 고려해야 한다.
- 41 -
② 특허 보호
③ 오픈소스 라이센스 확인
④ 소스 코드 공개 가능 여부 결정
가. 장점
• Maintenance : 소프트웨어의 경우 하드웨어와 달리 개발 후 지속
- 42 -
적 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)
- 43 -
특허는 구현하지 않도록 주의할 필요가 있다. 그러나 소스 코드 공개를
원하지 않을 경우는 사용하는 오픈소스의 라이센스 강제 사항과 활용하
고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한
경우가 발생할 수 있기 때문에, 이럴 경우는 라이센스 혹은 법률 전문가
에게 의뢰하여 정확한 판단을 받아야 할 것이다.
(3) 검증(Verification)
- 44 -
소스 코드 레벨에서 수많은 오픈소스 코드와 비교하는 것이 불가능할
것으로 생각될 수도 있지만, 최근 미국의 Blackduck社에서는 이러한 요
구에 착안하여 소스 코드 레벨에서 오픈소스 코드의 사용을 확인할 수
있는 검증 도구를 개발하여 판매 중에 있다. 세부 내용은 Blackduck社의
웹사이트를 참조하기 바라며, 본 문서에서는 동작 원리에 대해 간략히
설명할 것이다. Blackduck社에서 개발한 검증 도구는 Eclipse Platform
기반의 서버-클라이언트 형식으로 되었다.
서버에는 수많은 오픈소스 코드를 Fingerprint 형식으로 Database化한
Knowledge System을 갖고 있으며, 사용자 프로그램인 클라이언트에서는
서버에 접속하여 자체 개발한 프로젝트의 소스 코드와 서버의 Database
에 있는 오픈소스 코드를 비교하여 유사/동일한 소스 코드 사용에 대해
Report를 해주는 방식이다. 이 Report를 바탕으로 라이센스 전문가는 실
제 사용된 오픈소스 코드의 문제 여부를 최종 판단할 수 있게 된다.
(4) 제품화(Production)
① 소스 코드 공개
② 사용자 메뉴얼 작성
- 45 -
<그림 7> SONY의 오픈소스 공개 사례
- 46 -
Ⅴ. 결론 및 제언
- 47 -
용소프트웨어와 같은 방식으로 높은 가격을 책정할 수 없다. 따라서
Linux 배포사업에 있어 가장 중요한 성공요소는 브랜드가 되므로 광고,
전시, 홍보 등을 통해 브랜드를 만들고 독자적인 판매채널을 구축하여야
한다.
틈새․전문 공급자는 개인이나 다수기업을 직접적인 목표로 설정하지
않고 그들의 웹사이트에서 주문을 받고 일반 채널을 통해 공급되는 제한
된 수의 패키지를 제공한다. 즉 고객에게 최적화된 HW-SW번들이나 내
장제품을 개발하여 공급하는 것이다. 이 경우 소스에 대한 접근이 제한
적이지 않기 때문에 단순히 소프트웨어를 파는 것만으로는 유지할 수가
없다. 따라서 대부분의 공급자가 그들 제품에 컨설팅과 지원 등 다양한
부가서비스를 판매해야 한다.
보완․주변제품의 소매상은 공급자의 소프트웨어 제품을 팔거나 부가
적으로 매뉴얼과 각종 정보를 판매한다. OSS시장이 사용자 측으로 이동
하고 있으므로 고객 접근이 용이하고 브랜드가 많이 알려진 소매상이 유
리한 비즈니스 모델이 될 것이다. 또한 OSS가 더욱 대중화 되고 OSS커
뮤니티 밖에서 이용됨에 따라 문서화가 중요해지고 있다.
두 번째, 서비스 제공사업은 OSS개발․커뮤니티 조정자와 OSS 관련
서비스․지원 조직이 있다.
OSS개발과 커뮤니티 조정자는 거래시장과 컨퍼런스나 거래전시행사를
개최하는 것이다. 거래시장에서 개발자들은 요금 지불의사가 없으므로
수요자에게서 수익을 유도해야 한다. 하지만 수요자는 개발자 커뮤니티
를 신뢰하기 어려운 상황이므로 이 비즈니스 모델은 수익을 내기 어렵
다. 또한 컨퍼런스 역시 수익을 내기 어려운 비즈니스 모델이며, 방문자
가 늘고 있는 거래 전시회만이 매력적인 분야라 할 것이다.
OSS관련 서비스․지원은 컨설팅, 시스템 통합, 지원, 유지보수, 원격관
리, 훈련, 응용관리 등과 같은 서비스를 포함한다. 이 비즈니스 모델은
OSS에 대한 기술적인 배경을 가지는 회사와 그렇지 않은 회사로 구분되
는데 OSS에 대한 배경을 가진 회사는 제품 지식이 중요하고 프로세스
노하우를 만들 수 있는 영역에서 성공할 수 있을 것이며, OSS에 대한 배
경이 없는 회사는 지식이 중요하지 않거나 쉽게 획득될 수 있는 영역에
서 성공할 수 있을 것이다.
오픈소스를 활용하기 위한 프로세스는 기획, 구현, 검증, 제품화의 단
- 48 -
계로 구성된다.
기획단계에서는 오픈소스 활용여부를 결정하고 특허보호, 오픈소스 라
이센스 확인, 소스 코드 공개여부 결정 등을 고려해야 한다.
구현단계에서 소스 코드를 공개해도 무방한 경우엔 특별히 구현 방법
에 신경 쓸 필요없지만 소스 코드 공개를 원치 않는 경우 활용하는 라이
센스의 강제사항과 활용형태에 따라 다양한 경우가 발생할 수 있으므로
법률 전문가의 자문을 받아야 할 것이다.
검증단계에서는 오픈소스 라이센스가 사용된 경우를 탐색해야 한다.
이 과정은 수작업으로 하기에는 많은 어려움이 따르는데 최근에는 이러
한 역할을 대신하는 툴이 나와 있으므로 이를 활용하는 것도 한 방법이
다.
제품화단계에서는 소스 코드 공개와 함께 사용자 매뉴얼을 작성하여
제공해야 한다.
현재 많은 장점을 가진 오픈소스 소프트웨어의 활용이 기대만큼 확산
되지 않는 것은 성공적인 활용사례가 적고 오픈소스 소프트웨어 도입후
문제가 발생할 경우 책임소재를 명확히 할 수 없기 때문이다.
따라서 향후 오픈소스 활용의 확산을 위해서는 성공사례를 만들고 이
를 널리 알리며, 오픈소스 사용에 따르는 사후처리문제와 법률적인 책임
소재를 명확히 할 수 있는 지원체계를 확립해야 할 것이다.
- 49 -
기업의 오픈소스 소프트웨어 활용방안
- 50 -