오픈소스 소프트웨어 이야기 (1부)

오픈소스 소프트웨어는 무료 소프트웨어의 공유라는 단순한 의미를 넘어 안드로이드 스마트폰에서 보았듯이 어느덧 기업의 비즈니스 모델로 확고하게 자리잡고 있으며, 나아가 앞으로 상용 소프트웨어를 대체할 것으로 예상하는 사람들도 있는 실정입니다. 이에 4부로 나누어 오픈소스 소프트웨어를 이해하고, 이를 기초로 앞으로의 전망 및 법률적 검토를 해 보고자 합니다.

☑ 1부 : 오픈소스 소프트웨어의 역사 (과거)

□ 2부 : 오픈소스 소프트웨어에 대한 오해 (현재)

□ 3부 : 오픈소스 소프트웨어의 앞으로의 전망 (미래)

□ 4부 : 오픈소스 소프트웨어의 법률적 문제 (사례)

오픈소스 소프트웨어의 개념

“누군가가 나의 등잔의 심지에서 불을 붙여가도 내 등잔의 불은 여전히 빛나고 있습니다.” 미국의 정치가 토머스 제퍼슨이 한 말이다. 이러한 명언은 이후 오픈소스 소프트웨어 생성의 정신적 기초가 되었다.

오픈소스 소프트웨어(Open Source Software, 줄여서 OSS라 함)란 일반 사용자의 공동연구를 통해 개발, 시험, 개선작업과 공동연구를 보장하기 위해 해당 소프트웨어의 소스코드(인간이 읽을 수 있는 언어 형식으로 작성된 것, 대표적인 언어 형식으로는 C, Java 등이 있다)가 공개되는 소프트웨어를 말한다.

대표적인 오픈소스 소프트웨어로는 최근 안드로이드(android) 때문에 모바일 플랫폼으로서 각광을 받고 있는 리눅스 커널(linux kernel, 점유율 약 50%), 서버시장의 약 30%의 점유율을 보이고 있는 리눅스 OS, 전세계 웹서버의 60% 이상을 차지하고 있는 아파치(apache), DB 분야의 선두주자인 MySQL, 통합개발환경을 제공하는 이클립스(eclipse) 등이 있다. 우리나라에서도 이름난 오픈소스 소프트웨어가 있으니, 최근 NHN이 인수하여 전세계의 웹콘텐츠 플랫폼 시장의 약 60%를 휩쓸고 있는 XpressEngine(익스프레스, 줄여서 XE, 아래 그림)이 그것이다.

오픈소스 소프트웨어의 태동

오픈소스 소프트웨어의 기원은 1980년대로 거슬러 올라간다. 하드웨어 중심 체제로부터 점점 소프트웨어의 비중이 높아지면서 소프트웨어 기업의 소프트웨어에 대한 이용ㆍ배포ㆍ복제ㆍ수정 등에 일정한 제한을 가하려고 하는 추세가 있자, 이러한 ‘독점’ 체제에 반발하여 ‘공유’를 주장하는 운동이 리차드 스톨만(Richard Stallman)에 의하여 일어났다. 리차드 스톨만은 소프트웨어 상업화에 반대하고 소프트웨어 개발 초기의 상호협력적인 문화로 돌아갈 것을 주장하며 1984년 GNU(GNU is Not UNIX의 약자, Unix는 대표적인 서버 OS)프로젝트를 주도하였고, 이듬해인 1985년 FSF(프리 소프트웨어 재단,http://www.fsf.org,아래 그림)를 조직하면서, ‘소프트웨어는 공유돼야 하며 프로그래머는 소프트웨어로 돈을 벌어서는 안된다’는 내용의 GNU 선언문을 제정하기도 했고, 이를 지원하기 위하여 저작권(copyright)에 대응하는 카피레프트 운동도 주창하였다.

1990년대 들어서면서 인터넷의 보급과 더불어 GNU GPL(General Public License)로 배포된 리눅스의 보급으로 자유소프트웨어 운동이 확산되었고, 1998년에는 MS의 웹브라우저인 익스플로러에 밀려 어려움을 겪고 있던 Netscape사가 웹브라우저 Mozilla의 소스코드를 공개하는 결정을 하게 되었다(현재까지 Mozilla Project로 계승되어 있고, 리눅스 OS는 대부분 기본적으로 Mozilla 웹브라우저인 Firefox를 탑재하고 있다, 아래 그림).

오픈소스 소프트웨어의 정착

그 즈음 자유소프트웨어라는 용어에서 오픈소스 소프트웨어로 용어가 변경되는데, 자유(free)란 용어 때문에 일반인들이 무료라고 인식하고 있다는 점, GPL 조항의 엄격성 때문에 소프트웨어 개발이 용이하지 않다는 점을 탈피하기 위해서였다. 이후 1998년 오픈소스 소프트웨어를 인증하는 OSI(Open Source Initiative,http://www.opensource.net,아래 그림)가 에릭 레이몬드(Eric Raymond) 등에 의하여 결성되면서 오픈소스 소프트웨어 운동은 궤도에 오르게 된다.

OSI 단체가 정한 오픈소스 소프트웨어의 기준을 OSD(Open Source Definition)이라 하는데, 이 기준을 만족해야만 오픈소스 소프트웨어로 인정받게 된다. 때문에 이제는 위 OSD 기준을 충족시키는 것을 오픈소스 소프트웨어로 부르고 있다.

오픈소소 소프트웨어의 요건

OSD 기준에 따르면, 오픈소스 소프트웨어는 아래 6가지 요건을 갖추어야 한다.

1) 자유로운 재배포 (Free Redistribution : The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.)

2) 소스코드 제공 (Source Code : The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.)

3) 2차적 저작물 (Derived Works : The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.)

4) 저작자의 소스코드의 온전함 (Integrity of The Author's Source Code : The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.)

5) 차별금지 (No Discrimination Against Persons or Groups 및 No Discrimination Against Fields of Endeavor : The license must not discriminate against any person or group of persons. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.)

6) 라이선스의 배포와 차별금지 (Distribution of License, License Must Not Be Specific to a Product, License Must Not Restrict Other Software, License Must Be Technology-Neutral : The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. No provision of the license may be predicated on any individual technology or style of interface.)

오픈소소 소프트웨어 라이선스의 유형

오픈소스 소프트웨어의 라이선스란 오픈소스 소프트웨어 개발자와 이용자간에 사용 방법 및 사용조건를 명시한 계약을 의미한다. 만일 개발자와 일정한 조건으로 라이선스 계약을 체결한 이용자가 미리 약정한 사용방법을 어긴 경우, 개발자는 라이선스 계약 위반과 저작권 침해를 주장할 수 있다.

OSI는 현재 69개의 라이선스를 인정하고 있다. 아래 그림은 이름별로 정리한 것이다.

이 중 실제로 많이 사용되고 있는 라이선스로는 GPL(General Public License), LGPL(Lesser General Public License), MPL(Mozilla Public License), BSD(Berkeley Software Distribution), AL(Apache License)가 있다. 이들의 라이선스 내용은 자유로운 사용ㆍ수정ㆍ배포를 인정하다는 점에서 공통이나 구체적으로 살펴보면 상이한 라이선스 조건을 가지고 있다. 대체로 오픈소스 소프트웨어를 ‘공짜’로 쓰는 데만 관심이 있고 개량에 기여하지 않는 것을 막아 보고자 라이선스 정책을 만들어 놓은 것이다. 소소코드 공개성과 전파성이 강한 것부터 정리하면 GPL, LGPL, MPL, BSD, AL가 된다.

GPL은 FSF가 주도하고, 현재 버전 3까지 나와 있다. 그 내용으로는 만일 소스코드를 배포하는 경우 GPL에 의하여 배포된다는 사실을 명시하여야 하며, 소소코드를 수정하는 경우 반드시 개작 부분은 공개하여야 하고, 더불어 소스코드를 링크하는 경우에도 모두 소스코드를 공개하여야 한다. 우리나라의 경우 GPL 라이선스 소프트웨어 등을 ftp://ftp.kaist.ac.kr/gnu/gnu/ 등에서 다운로드할 수 있다.

LGPL은 FSF가 주도하고 현재 버전 3까지 나와 있다는 점에서 GPL가 동일하나, 일부 라이브러리(Library)에 대하여 GPL보다 소스코드의 공개정도를 다소 완화된 형태로 사용할 수 있도록 만들었다는 특징이 있다. 따라서 LGPL 라이브러리의 일부를 수정하는 경우 수정한 라이브러리의 소스코드 공개하여야 하나, LGPL 라이브러리에 응용프로그램을 링크시킬 경우 GPL과 달리 해당 라이브러리만 공개하면 되고 해당 응용프로그램의 소스를 공개할 필요가 없다.

MPL은 Mozilla Project가 주도하고 현재 버전 2.0까지 나와 있다. 소소코드의 수정시 소스코드 공개는 필수적이지만, MPL 코드와 다른 코드를 결합하여 프로그램을 만들 경우 MPL 코드를 제외한 결합 프로그램에 대한 소스코드는 공개할 의무는 없다. 우리나라의 경우 ftp://ftp.kaist.ac.kr/mozilla 에서 MPL 라이선스 소프트웨어를 다운로드받을 수 있다.

BSD는 캘리포니아 대학에서 개발된 라이선스로서 수정 부분에 대하여 소소코드 공개는 의무가 아니며, BSD 소스코드를 상용 프로그램과 조합하는 것도 허용되며, 이 경우 2차적 저작물에 대한 공개의무도 없다.

AL은 아파치 재단(ASF : Apache Software Foundation)에 의하여 운영되며, BSD 라이선스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다. 다만 ‘Apache’라는 표장에 대한 상표권을 침해하지 말아야 한다.

이상의 5가지 라이선스를 비교하면 아래 표와 같다.

위의 라이선스가 적용된 소프트웨어는 소스포지(http://sourceforge.net)또는 프레시미트(http://freshmeat.net) 에서 무료로 다운로드 받아 볼 수 있다. 다양한 용도의 창의적인 소프트웨어를 무료로 체험하면서 즐거움을 느껴볼 수 있을 것이다.

오픈소스 소프트웨어의 개발동기

그렇다면 왜 이런 현상이 발생한 것일까, 오픈소스 소프트웨어의 끝은 어디일까 라는 의문이 들 수밖에 없다. 이 중 후자의 질문은 3부에서 설명하기로 하고, 전자의 질문에 대하여만 답을 찾아보기로 한다.

오픈소스 소프트웨어의 개발주체는 개인이나 기업인 경우가 많았으나 최근에는 정부나 공공기관도 많이 참여하고 있다. 그렇다면 왜 기업이나 공공기관은 막대한 노력과 자본을 들여 오픈소스 소프트웨어를 개발하는 것일까.

사회적 동기, 기술적 동기, 경제적 동기로 나눌 수 있다. 사회적으로는 개발자 자신의 능력을 세상에 알리고 자기성취욕구를 달성하기 위함이며, 나아가 그로 인하여 공공재를 개발하고 공유 정신을 실현할 수 있기 때문이다. 초기의 오픈소스 소프트웨어는 위의 동기가 많았다.

기술적으로 보면, 개인적인 기술의 부족함을 극복하고 동료들의 도움을 얻어 하자를 고쳐가자는 의도에서부터 나아가 기술의 혁신이나 더 좋은 제품을 위한 동기를 찾을 수 있다. 이러한 의도는 이제 기술표준의 획득을 위한 시도로 바뀌고 있다. 정보통신분야의 기술표준을 획득하면 그 기업은 독점적 지위를 누릴 수 있고 신규사업자를 봉쇄하는 효과를 가질 수 있기 때문이다.

경제적으로 보면, 기업의 소프트웨어를 공개함으로써 홍보 효과를 가질 수 있고, 타인의 기술개발을 활용함으로써 저렴한 비용으로 제품을 개발하고 유지할 수 있는 장점이 있기 때문이다.

중요한 점은 오픈소스 소프트웨어의 개발동기가 이제는 기술표준의 획득이나 비즈니스를 위한 것으로 그 중심이 옮겨져 가고 있다는 것이다.

<2부에 계속>

* 법무법인 민후 김경환 대표변호사 작성, 블로그(2012. 2. 24.), 로앤비(2012. 2. 24.) 기고.