<웹진 172호 : 인사이드 이슈> 오픈 소스, 새로운 패러다임을 만들다

최근, 미국의 한 오픈소스 (Open Source) 기업이 업계 최초로 연 매출 20 억 달러 (약 2 조 3000 억원) 매출을 달성했다는 뉴스가 나왔다. 또한, 기업들의 수요 증가로 매년 두 자릿수 이상 성장을 하고 있다. 세계적인 불경기의 영향으로 올해 소프트웨어(SW) 시장이 크게 위축된 가운데, 오픈소스 등 경비 절감과 연관된 분야는 성장세를 이어가고 있다는 소식이 연일 보도되고 있다.

하지만 이러한 흐름이 장점만을 지니고 있는 것은 아니다. 지속적으로 ‘저작권’ 에 관한 혼란이 발생하고 있는 것이다. 지난해 초반, 오픈소스 프로젝트를 운영하는 비영리단체 소프트웨어자유관리단 (SFC) 이 세계적인 가상화 전문업체 VM 웨어를 저작권 침해를 이유로 독일 법원에 제소한 사건도 있었다. 이렇듯, 전세계적으로 오픈소스가 확산되는 추세에 맞춰 계약·저작권 위반 관련 분쟁이 늘고 있으며 우리나라 SW 업체들도 이와 관련된 법적분쟁에 잠재적으로 노출돼 있는 상황이다. 특히, 국내 SW 업체들 중에는 오픈소스 라이선스 규약을 지키지 않고, 무료라고 생각하는 업체들도 있다. 스마트폰과 태블릿용 애플리케이션 경우 오픈소스만으로 제작이 가능한 것도 상당수 있는데다, SW 업계에서는 안드로이드 앱의 90%, iOS 앱의 절반 가량이 오픈소스를 활용하는 것으로 추정하고 있다.

 

양날의 검과 같은 ‘오픈소스’, 그 특징과 우리가 가지고 있는 오해들, 그리고 활용상 주의점에 대해 락플레이스의 윤종민 수석을 통해 알아보자.

 

 

< 락플레이스 윤종민 수석연구원 >

 

Q: 오픈소스 (Open Source) 는 언제부터, 어떻게 생겨난 것인가요?

 

1960 년대는 IBM360 으로 대표되는 메인프레임이 지배하던 시대였습니다. 이 당시에는 소프트웨어와 하드웨어가 밀접하게 결합 (bundling) 되어 있었기 때문에 특정 기종을 위해 만들어진 소프트웨어는 다른 기종에서 작동하지 않았죠. 이때 IBM 은 소프트웨어 소스코드를 하드웨어와 함께 제공했고, 운영체제 소프트웨어의 소스코드를 폐쇄하지 않았습니다. 그러나 IBM 이 ‘반독점법’ 패소에 대한 대응방안의 하나로 소프트웨어를 하드웨어와 분리(unbundling) 하면서 소프트웨어 자체가 중요한 산업이 되었고, 기업들간의 경쟁이 심화되면서부터 소프트웨어의 소스코드는 기업의 비밀이 되었습니다. 그리고 모든 기업들에게 소스코드는 경쟁우위를 보장해주는 기술자원으로 변하였죠.

이러한 흐름의 다른 한쪽에서는 소스코드를 공개하는 새로운 흐름이 형성되고 있었습니다. 1969 년 AT&T 의 벨연구소에서 근무하고 있던 켄 톰슨 (Ken Thompson)이 개인적인 연구를 수행하기 위해 유닉스 (Unix) 라는 운영체제를 만들었는데요. 이 운영체제는 C 라는 새로운 고급 언어로 작성되었는데, 이는 하드웨어에 종속되지 않는 특징을 지니고 있었습니다. 이로 인해 벨 연구소가 아닌 곳에서도 유닉스를 사용할 수 있게 되었고, 이렇게 개발된 유닉스의 소스코드는 주로 연구기관을 중심으로 배포되었습니다.

1980 년대 들어 유닉스는 전세계의 대학이나 연구기관으로 퍼져 나갔으며, 이러한 경향으로 인해 기업들은 유닉스가 시장성이 있음을 인지하고, 유닉스 기종을 만들기 시작했습니다. 이로 인해 유닉스는 상업화의 길을 걷기 시작했죠. 1984 년 ‘독점금지법’ 과 관련해서 AT&T 분할이 이루어지면서 AT&T 가 컴퓨터업계에 진출할 수 있게 되었는데요. 이 과정을 통해 AT&T 는 과거 거의 무료로 소스코드를 공개하던 방식에서 유닉스의 상품화로 입장을 바꾸어, 가격도 오르고 소스 코드 역시 엄격하게 관리되어 더 이상 개방되지 않게 되었습니다.

이렇게 유닉스 분야에 상업화 바람이 불면서 유닉스 초기에 존재하던 활발한 소스코드 공개 문화는 사라져 버리게 되어, 결국 제각각이 되어버린 유닉스들은 점차 폐쇄적으로 바뀌어 호환성을 갖지 못하게 되는 상태까지 이르게 됩니다.

유닉스의 상업화 경향이 강화되면서 이에 대한 반발의 움직임으로 자유소프트웨어 운동이 추진되기 시작했는데요. 폐쇄적으로 진행되어 가는 상업용 유닉스의 흐름과는 별개로 자유소프트웨어 (Free Software) 가 개발되기 시작한 것입니다.

1983 년 경에 시작된 GNU 프로젝트는 리차드 스톨만 (Richard Stallman) 이 주도하였는데요. 이 프로젝트의 목표는 기술적으로 완벽한 ‘유닉스 호환 소프트웨어 체계를 개발하는 것’ 이었습니다. 그러나 GNU 는 기술적으로 유닉스와 같지만, 사용자들에 자유를 준다는 점에서 유닉스와는 본질적으로 달랐습니다 . 결국 사회적 측면에서 볼 때 , GNU 프로젝트는 기술적으로는 동등하지만 사회적으로는 완전히 다른 소프트웨어를 개발하는 것이었죠. 스톨만이 추구한 것은 ‘사적 독점 소프트웨어 사회체계’ 에 맞서 소프트웨어를 공유하고 협력하는 공동체를 만들고, 궁극적으로는 ‘사적 독점 소프트웨어’ 를 완전히 극복하는 것이었습니다. 그래서 스톨만은 이 프로젝트를 수행하기 위해 1985년 ‘자유 소프트웨어 재단(Free Software Foundation)’ 을 설립하였습니다.

< 그림 1> 자유 소프트웨어 재단 (Free Software Foundation)의 로고

 

자료 : www.gnu.org

 

자료 : www.fsf.org

 

여기서 ‘자유’ 는 다음 네 가지의 의미를 지닙니다.

첫째, 어떤 목적으로도 프로그램을 가동시킬 수 있는 자유

둘째, 필요에 맞게 소프트웨어를 수정할 자유

셋째, 무료 또는 유로로 복사본을 재배포할 수 있는 자유

넷째, 전체 공동체가 혜택을 볼 수 있도록 프로그램의 수정본을 배포할 수 있는 자유

한편, 이와 같은 공공의 영역에 위치하고 있는 자유 소프트웨어의 약점은 누군가 그것을 사유 소프트웨어로 사용할 가능성이 있다는 점일텐데요. 이 문제를 해결하기 위해 스톨만은 저작권에는 반대하지만, 그것을 이용하여 저작권에 대응하는 GPL(General Public Licence)를 개발하였습니다. GPL 은 해당 프로그램을 마음대로 복사, 배포, 수정할 수 있으나, 그 수정된 프로그램의 소스는 반드시 공개되어야 한다는 라이센스죠.

GNU 프로젝트는 여러 가지 기술을 개발했으나, 1990 년대 초까지 운영체제의 핵심기능을 담당하는 ‘커널’ 의 개발이 지지부진한 상태로 진행되고 있었습니다. GNU 가 독립된 운영체제로 완성되기 위해서 커널은 반드시 필요한 것이었는데요. 이 문제는 리눅스 (Linux) 라는 프로그램이 개발되어 GNU 프로젝트에 합류함으로써 해결되었습니다. 리누스 토발즈 (Linus Benedict Tovalds)가 유닉스를 개조하던 끝에 새로운 커널을 개발한 것이죠. 1992 년에 이 새로운 커널이 불완전했던 GNU 체계와 결합하면서 완전한 자유운영체제인 GNU/Linux 가 완성되었습니다.

 

< 그림 2> GNU/Linux 의 로고

 

자료 : http://www.howopensource.com/2012/12/linux-and-gnulinux/

 

리눅스가 발전하면서 자유소프트웨어 운동도 발전하였는데, 이 과정에서 자유소프트웨어 운동 내부에서도 분화가 이루어지기 시작했습니다. 이상주의적이고 도덕적인 스톨만의 입장에 대해서 실용주의적 관점에서의 비판이 이루어지기 시작한 것입니다.

자유소프트웨어 운동을 주도해왔던 스톨만은 공유와 협동의 문화에 입각해서 소프트웨어를 개발해야 하며, 사적 이익과 독점을 추구하는 산업체 주도의 문화에 반대해야 한다고 역설했습니다. 도덕적인 측면에서 자유소프트웨어의 개발을 주장했던 것이죠. 그러나 자유 소프트웨어의 정신은 존중하지만, 스톨만의 도덕적이고 이상주의적 운동방식에 대해 비판적인 입장을 취하는 집단들이 형성되기 시작했습니다.

새로운 접근의 논리적 근거는 에릭 레이몬드 (Eric Raymond) 의 ‘성당과 시장 (Cathedral and Bazaar)’ 이라는 논문이 발표되면서 이루어졌는데요. 이 글은 리눅스를 개발하는 방식이 왜 성공적인 결과로 귀결되었는지를 분석하고, 그 분석결과를 자신이 참여한 오픈소스 프로젝트를 통해 검증한 글입니다. 리눅스 및 오픈소스 소프트웨어 기술 개발에 대해 ‘인류학적 접근’ 을 시도한 글이라고 할 수 있죠

레이몬드는 GNU 프로젝트에서 리눅스가 수행한 기능과 역할보다도, 리눅스가 개발되고 개선되는 방식에 주목했습니다. 리눅스의 개발 방식은 스톨만이 주도한 GNU 프로젝트의 개발 방식과는 매우 다른 것이었죠. 레이몬드에 따르면, 스톨만이 주장하는 방식은 탁월한 능력을 가진 전문가들이 복잡한 프로그램을 개발하기 위해 위대한 고립 속에서 주의 깊게 작업하는 것과 유사했습니다. 이것은 중세의 ‘성당 (Cathedral)’ 을 건축하는 것과 유사한 접근 방식이었는데요. 그러나 리눅스 개발되는 과정은 마치 ‘시장 (Bazaar)’ 에서 여러 사람들이 모여 어지럽게 뒤섞여 제품을 개발하는 방식을 취했다고 주장하며, 바로 이러한 방식이 리눅스의 성공을 가져온 것이라고 의견을 펼쳤습니다.

그는 “충분히 많은 베타테스터(β tester) 와 공동 개발자가 있으면, 거의 모든 문제들은 빨리 파악될 것이고, 그 중에는 쉽게 고치는 사람이 있게 마련이다” 라는 사실을 지적하면서, 불완전한 소프트웨어를 자주 빠르게 발표하여 수많은 사람들이 버그를 수정하는 방식에 주목하였습니다. 또, 그는 리누즈 토발즈가 리눅스를 만들었다는 사실보다, ‘리눅스의 개발 모델’ 을 만든 것에 더 큰 의미를 부여하였습니다.

레이몬드의 발표는 프로그래머와 업계에 커다란 반향을 일으켰는데요. 특히 1998 년 1 월 ‘넷스케이프’ 사가 레이몬드의 논리를 수용하여 ‘넷스케이프 커뮤티케이터’ 의 소스코드를 공개한다고 발표하였습니다. 넷스케이프사의 이 결정은 ‘스톨만이 주장하는 자유소프트웨어 운동’ 과는 입장을 달리하는 운동을 형성하는 직접적인 계기가 되었죠. 레이몬드와 그의 입장에 동의하는 사람들은 이러한 ‘오픈소스운동’ 을 관리하기 위해 ‘Open Source Initiative’ 라는 조직을 결성하였습니다. 자유소프트웨어의 이념적 측면보다는 그것이 개발되는 방식에 초점을 맞추는 실용적 접근을 취하는 이들은 산업체와의 관계에서도 스톨만과는 다른 입장을 취하는데요. 이들은 ‘자유소프트웨어는 산업계는 물론이고, 개발자에도 경제적인 보상을 제공할 수 있어야 한다’ 고 주장하고 있습니다. 스톨만은 산업계와의 협력을 거부하면서 폐쇄적인 전략을 취하고 있으며, 소프트웨어의 개발자에게도 도덕적인 대의에 협력할 것을 요구한다고 파악하는 것이죠. 이데올로기적 관점이 아니라, 굳건한 실용적 기반위에 자유소프트웨어가 설 수 있어야 한다는 것이 이들의 주장입니다.

두 운동의 흐름을 종합해 보면 다음 < 표 1> 과 같이 정리할 수 있으며, 결국 자유소프트웨어는 원칙에 입각한 소스코드의 자유로운 사용이라는 측면을 오픈소스 소프트웨어는 사회적 실용성에 중심을 두고 소스코드의 공개라는 측면을 강조한다고 할 수 있다.

 

< 표 1> 자유 소프트웨어 운동의 분화

 

Q: 오픈 소스의 범위와 이에 대한 정의에도 많은 혼란이 있는 것으로 알고 있는데요,

    정확히 오픈소스란 무엇인가요?

 

‘오픈소스 소프트웨어’ 는 소스코드를 공개한 상태로 소스코드를 누구나 자유롭게 개작 및 개작된 소프트웨어를 재배포할 수 있도록 허용된 소프트웨어를 말합니다.

하지만, 소스코드가 공개 되어 있다고 하여서 이를 오픈소스 소프트웨어라 하지는 않는다는 것이 중요합니다.

오픈소스 소프트웨어는 누구라도 소스코드를 읽을 수 있고 사용자가 능력이 있다면, 각종 버그의 수정은 물론이고 그것을 개조하여 기능을 추가할 수 있으며, 누구나 그 소프트웨어의 개발에 참여할 수 있죠. 따라서 오픈소스 소프트웨어는 ‘프로그램을 복제하여 배포할 수 있는 권리’, 소프트웨어의 ‘소스코드에 접근할 수 있는 권리’, 프로그램을 ‘개선할 수 있는 권리’ 를 개발자에게 보장한다는 특징이 있습니다.

 

< 그림 3> 오픈소스와 관련된 개념들

자료 : 구글 이미지

 

그렇기 때문에 오픈소스란, 단지 소스 코드에만 국한되는 용어가 아닙니다. 오픈소스 소프트웨어의 배포 조건은 OSI(Open Source Inititive) 에서 오픈소스 정의 (OSD, Open Source Definition) 규정하고 있으며, 이는 다음과 같습니다. (아래 10 가지)

1. 자유 배포 (Free Redistribution)

특정한 소프트웨어의 라이센스에는 해당 소프트웨어의 일부나 전부가 다수의 프로그램으로 구성되는 배포판의 일부로 포함되어 재배포되지 못하도록 배포나 판매상의 제한을 설정할 수 없다. 또한 이러한 종류의 배포판에 대한 판매나 양도에 있어서 별도의 라이센스 비용을 징수할 수 없다.

2. 소스코드 공개 (Source Code Open)

프로그램 저작물에는 반드시 소스 코드가 포함되어야 하며, 컴파일 된 형태 뿐만 아니라 소스코드의 배포 또한 허용되어야 한다. 만약 소스코드를 제외한 상태로 배포하고자 한다면 일반적으로 통용되는 매체를 이용해서 제작 실비에 준하는 비용으로 소스 코드를 제공해야만 한다. 이 경우 가장 바람직한 방법은 인터넷을 통해서 소스 코드를 무료로 다운로드 받을 수 있도록 하는 것이다. 소스코드는 프로그래머들이 개작하기에 용이한 형태로 제공되어야 하며, 고의로 복잡하고 혼란스럽게 만들어진 형태와 선행 처리기나 번역기에 의해서 생성된 중간 형태의 코드는 허용되지 않는다.

3. 2차적 저작물 (Derived Works)

라이센스에는 프로그램 원저작물의 개작이나 이를 이용한 2차적 프로그램의 창작이 허용되어야 하며, 이러한 파생적 프로그램들은 최초의 프로그램이 갖고 있던 라이센스의 규정과 동일한 조건하에서 재배포될 수 있어야 한다.

4. 소스코드 수정 제한 (Integrity of The Author's Source Code)

빌드 과정을 통해서 프로그램을 개작할 목적으로 소스 코드와 패치 파일을 함께 배포할 경우에는, 정상적인 빌드를 보장하기 위해서 라이센스 안에 소스코드의 수정을 제한하는 항목을 추가할 수 있다. 그러나 이러한 경우에도 수정된 소스 코드를 이용해서 만들어진 소프트웨어에 대한 자유로운 배포를 허용해야 하며, 수정된 소스코드를 통해서 만들어진 2 차적 프로그램을 원래의 프로그램과 구별하기 위해서 별도의 이름과 버전을 사용할 것을 요구하는 항목을 추가할 수 있다.

5. 개인이나 단체에 대한 차별 금지 (No Discrimination Against Persons or Groups)

라이센스는 모든 개인과 단체에 대해서 동일한 기준으로 적용 되어야 한다.

6. 사용 분야에 대한 제한 금지 (No Discimination Against Fields of Endeavor)

라이센스 안에 특정한 분야에 종사하는 사람에 대한 프로그램 사용상의 제한을 설정할 수 없다. 예를 들면, 유전연구나 상용 사업체에서는 해당 프로그램을 사용할 수 없다는 등과 같이 특정한 분야에 대한 사용을 금지하는 제한을 설정해서는 안된다.

7. 라이센스의 배포 (Distribution of License)

프로그램에 대한 권리는 반복되는 배포에 따른 별도의 라이센스 승인이나 양도 과정 없이도 프로그램을 배포 받은 모든 사람에게 동일하게 적용된다.

8. 라이센스 적용상의 동일성 유지 (License must no be specific to a product)

프로그램에 대한 권리는 반복되는 배포 과정에서 특정한 배포판에 포함되어 있는 상태로만 유효하지 않고, 모든 배포 단계에서 동일한 효력을 갖는다. 만약, 특정한 배포판에 포함되어 있던 프로그램을 독립적으로 사용하거나 재배포한다면 해당 프로그램을 배포 받는 사람은 프로그램이 포함되어 있던 최초의 배포판 상태에서 발생된 권리와 동일한 권리를 갖는다.

9. 다른 라이센스의 포괄적 수용 (License must not contaminate other software)

라이센스에 오픈 소스 소프트웨어와 함께 배포되는 소프트웨어에 대한 제한을 설정해서는 안된다. 예를 들면, 동일한 매체를 통해서 배포되는 소프트웨어는 모두 오픈소스 소프트웨어여야 한다는 제한으로 인해서 다른 라이센스 기준을 따르는 소프트웨어가 함께 배포될 수 있는 형태를 금지해서는 안된다.

10. 이용허락의 기술 중립의무  (License Must Be Technology-Neutral)

이용허락 규정이 어떠한 개별 기술이나 인터페이스 형태를 단정해서는 안된다.

이는 이용허락자와 피이용허락자 사이의 계약 성립을 위해 명시적인 동의 표시를 요구하는 것을 막기 위한 것이다. 소위 '클릭랩 (click-wrap)' 이라 불리우는 강제 조항은 FTP 다운로드나 CD-ROM 수집물, 웹 미러링 같은 중요한 소프트웨어 배포 방식과 상충하며, 이런 강제 조항은 코드 재사용을 가로막는다. 오픈소스 정의를 따르는 이용허락은, ( ㄱ ) 클릭랩 다운로드를 지원하지 않는 웹이 아닌 접근 수단을 통한 소프트웨어 재배포와, ( ㄴ ) 팝업 대화 창을 지원할 수 없는 그래픽 사용자 인터페이스 (GUI: Graphical User Interface) 가 아닌 환경에서 이용허락을 적용할 코드가 ( 또는 이러한 코드의 재사용 부분이 ) 실행될 가능성을 허용해야만 한다.

이와같이, 위에서 언급한 10 가지의 조건을 충족해야만이 오픈 소스 소프트웨어라 할 수 있습니다.

 

Q: 오픈소스와 항상 함께 따라다니는 용어가 바로 ‘저작권’ 혹은 ‘특허’ 인 듯 한데요,

     이와 관련한 주의사항이 있다면?

 

먼저 알고 계셔야 하는 개념이 있는데요, 바로 ‘저작권’ 과 ‘특허’ 의 차이점입니다.  

‘저작권’ 은 ‘정신적인 분야의 창작을 의미하는 저작물’ 을 보호하는 권리입니다. 정당하게 얻어진 저작물에 의해 허용되는 보호는 저작물의 표현만으로 범위가 정해지는데요. 그 보호 범위는 저작물에 의해 표현된 아이디어, 개념, 또는 원리까지 미치지는 않습니다.

반면 , ‘특허’ 는 ‘발명 및 창작에 대한 권리’ 이며, 특허법은 이 권리를 보호하여, 법에 규정된 특정 기간 동안 그들을 사용할 독점권을 특허권자에게 부여한다는 특징을 가집니다. 즉, 다른 사람은 특허권 소유자의 허락 없이 ‘특허를 실시’(즉, 특허된 발명을 이용) 할 수 없는 것이죠.

저작권과 특허권은 서로 상이한 방식으로 획득되는데요.   저작권자는 저작물이 완성된 시점부터 자동적으로 보호 받을 수 있지만, 특허의 독점적 이용에 관한 권리를 획득하기 위해서는 ‘출원’ 을 하여야 하고 성공적인 ‘후속 심사’ 와 ‘등록 절차’ 를 거쳐야 합니다.

보호기간 역시 상이한데요. 저작권의 보호기간은 원칙적으로, 저작자의 수명에 50 년을 더한 것으로서, 연장이 불가능한 반면, 발명 특허는 20 년의 특허 보호기간이 부여됩니다.

이 글에서 이야기한 오픈소스 라이선스, 즉 ‘오픈 소스 이용 허락’ 은 지금 이야기고 있는 ‘저작권’ 의 한 형태로, 소프트웨어가 만들어져 배포되는 순간 자연 발생하여 적용이 된다는 점을 분명히 숙지하고 있어야 함을 다시 한번 강조하고 싶습니다.