오픈소스 라이선스 배경 및 연혁

안녕하세요 기술전략팀 조영준입니다.

요즘 많은 기업에서 회사 내부에서 개발중인 프로젝트를 오픈소스로 공개하는 케이스가 많습니다. (우분투 OS에서부터 DB인 MySql, 큐브리드, 마리아DB, 기타 앵귤러JS, 테서플로, 제플린 등등.. 너무나 많은 프로젝트들이 오픈되어있어서 나열하기 어렵습니다)

단순히 소스코드만 공개해두면 오픈소스 프로젝트가 될까요? 다른 사람이 그 코드를 사용할 수 있게 하고, 쓸 수 있게 만들어줘야 오픈소스가 됩니다.

"Hello world" 하나만 출력해서 만든 소스가 오픈소스가 될 수 있습니다.

이런 이유로, 세계 여러 오픈소스 재단에서는 오픈소스에 대한 일정의 Rule을 정하고 있고, 각 재단에서 생각하는 오픈소스의 철학과 나아가야 하는 방향이 조금씩 다르게 나타나고 있습니다. 그 결과 각 재단이 생각하는 오픈소스에 대해 각 라이선스를 발급하기 시작했습니다.

이번에 공유드리는 내용은 오픈소스 라이선스 출현 배경에 대해 기술전략팀에서 스터디 한 내용입니다. (각 오픈소스 라이선스의 룰은 다음 공유에서..)

목차는

1. BSD 유닉스를 만들었던 버클리 대학에서 시작한 BSD 라이선스
2. 아파치 웹서버를 만들었던 Apache 라이선스
3. GNU를 만들었던 리처드 스톨만의 GPL라이선스
4. Mozilla, eclipse 등 각사의 환경에 맞춘 MPL, EPL 라이선스 순서입니다.

재미있는 부분은 1. BSD 라이선스와 2. Apache라이선스의 경우에는 오픈소스를 가져다 써도 큰 제약이 없지만, GPL라이선스의 경우에는 수정한 본인의 소스도 공개를 해야하는 조건이 있습니다.이는 GNU를 만든 리처드 스톨만의 Free Software 철학이 담겨 있기 때문입니다.(3.1 참고)

또한, GPL 라이선스가 소스코드를 공개해야하는 룰이 있다보니, LGPL(소스코드 공개 의무 없음)을 만들었는데, LGPL사용을 하지말고 소스코드를 다 공개해야 하는 GPL을 사용 하라고 이야기 하고 있습니다. 이부분도 볼만 합니다.(3.8참고)

내용이 조금 길수 있으니, 각 라이선스의 첫부분인 1.1, 2.1, 3.1, 4.1 을 읽어보시고 조금더 보고싶으시면 1.2, 2.2, 3.2 로 조금씩 추가해서 읽어보시면 도움이 되실겁니다.

감사합니다.

목차

1. BSD유닉스를 만들었던 버클리 대학에서 시작한 BSD 라이선스
2. 아파치 웹서버를 만들었던 Apache 라이선스
3. GNU를 만들었던 리처드 스톨만의 GPL라이선스
4. Mozilla, eclipse 등 각사의 환경에 맞춘 MPL, EPL 라이선스

1. BSD(Berkeley Software Distribution) Lisense

1.1 BSD Lisense 출현 배경

AT&T의 벨 연구소(Bell Labs. 현재는 노키아 소속.)와 MIT 대학에서 1964년부터 개발을 시작하여 1969년도에 시분할 운영 체제 멀틱스(Multics)를 출시하였다. 그 후 벨 연구소의 켄 톰슨, 데니스 리치, 더글러스 매클로리가 1969년도부터 멀틱스를 간략화하여 소형 컴퓨터에서도 작동할 수 있는 운영 체제를 개발하였고, 유닉스라는 명칭으로 1973년 10월에 대중에 공개하였다.

AT&T는 미국 전화 산업의 독점 기업이었기 때문에 미국 정부로부터 반독점 규제를 받았는데 전화 산업과 전화 산업에 연관된 사업 외에는 제품을 팔 수 없도록 한 것도 그중의 하나였다. 따라서 이 시기에는 전화 산업과 아무 관련이 없던 유닉스도 소스 코드까지 무료로 배포되었다.

1977년에 캘리포니아 대학교 버클리 캠퍼스의 대학원생이었던 빌 조이(Bill Joy)가 유닉스의 소스 코드를 기반으로 BSD의 최초 버전을 만들어 배포하였다. 나중에는 CSRG(Computer Systems Research Group)라는 그룹을 만들어 BSD 개발을 맡게 되었다.

CSRG에서 개발한 BSD의 소스 코드는 AT&T의 USL(UNIX System Laboratories, Inc.)의 소스 코드를 사용하고 있었기 때문에 USL측에서 소송을 걸었고, 결국 합의하게 되었다. 이 소송이 오랫동안 진행되면서 오픈 소스 운영 체제의 대표 주자 BSD가 밀려나고 리눅스가 떠오르게 되었다. 이 소송이 제기된 직후 AT&T측은 USL을 노벨(Novell, Inc.)측에 판매하였다.

USL과 CSRG의 합의안은 완전한 소스 코드를 포함하는 4.4BSD-Encumbered는 USL측으로부터 라이선스를 얻어야 사용할 수 있으며 USL측의 소스 코드를 제거한 4.4BSD-Lite(1994년 6월 출시)에 대해서는 향후 USL측이 소송을 제기할 수 없다는 것이었다. 그래서 이전 BSD 버전을 기반으로 포크한 FreeBSD와 NetBSD는 4.4BSD-Lite를 기반으로 자신들이 지금까지 작성한 소스 코드를 추가하여 운영 체제 소스 코드를 재작성해야 했다. 현재 최신 버전은 4.4BSD-Lite Release 2(1995년 6월 출시)이다.

이 소송으로 기존의 카피라이트에 학을 뗀 CSRG측은 BSD 라이선스라는 소스 코드 작성자의 이름 표기 의무 외에는 거의 아무런 제한이 없는 라이선스로 BSD를 배포하였다.

1.2 BSD License History

배경 및 연혁 BSD 라이선스로 배포되고 있는 대표적인 프로젝트는 앞서 설명한 BSD OS이다. 1977년부터 1995년까지 활동했던 버클리 대학의 CSRG(Computer Systems Research Group)에서 최초로 배포한 BSD OS는 현재 FreeBSD, OpenBSD, NetBSD, DragonFly BSD등의 형태로 변형되어 계속해서 오픈소스로 배포되고 있다. 다시 말해, 윈도우 NT 3.1의 TCP/IP 네트워킹 코드라든지, 애플의 OS X와 iOS의 기초 대부분과 같이 현대의 사유 운영 체제에 부분적으로나 전체적으로 포함되었다는 것을 의미한다.

원래의 BSD 라이선스는 4개의 조항을 포함하고 있었는데, 그중 제 3조항인 광고에 대한 조항은 U.C. 버클리 코드를 사용하는 제품을 광고할 때는 항상 그 코드를 사용한다는 사실을 표시하도록 요구하는 것이었다. 이 조항은 1999년 7월 22일 캘리포니아 주립대학의 기술 라이선싱 부서의 책임자가 공식적으로 폐지했다. (즉 4개 조항으로 이루어진 라이선스는 OSI의 승인을 받지 않음)

BSD 3-Cause(제3조항 BSD, "BSD New" 또는 "BSD Simplified") 라이선스는 광고에 대한 조항을 삭제한 조항을 의미한다. 다른 명칭으로 "BSD NEW"라는 말을 쓰고 있지만, BSD 라이선스의 최신버전은 아니다. 이버전 이후에 "BSD Simplified"라는 명칭의 BSD 2-Cause 버전이 나왔다.

OSI 이사회는 앞서 언급한 원래 BSD 라이선스에서 광고조항을 삭제한 BSD 3-Cause, BSD 2-Cause를 승인하였다. ※ OSI에 의해 승인된 라이선스 리스트 - https://opensource.org/licenses/alphabetical ※ BSD License의 모든 버전 - https://en.wikipedia.org/wiki/BSD_licenses

• 참고자료 ) 유닉스 및 유닉스 계열 운영 체제의 족보

출처 (1) BSD History - https://namu.wiki/w/BSD (2) BSD 로고 - https://en.wikipedia.org/wiki/Template:BSD (3) 유닉스 계열 운영 체제의 족보 - https://commons.wikimedia.org/wiki/File:Unix_history-simple.svg

2. Apache License

2.1 ASF(Apache Sfotware Foundation, ASF) 출현 배경

아파치 소프트웨어 재단(Apache Software Foundation, ASF)은 다양한 오픈소스 프로젝트를 지원하고, 관리하는 비영리재단이다. 자유소프트웨어재단(Free Software Foundation, FSF)과 함께 오픈소스 문화를 꽃피운 대표 단체로 꼽힌다. ASF에서 관리하는 오픈소스 소프트웨어는 누구나 참여할 수 있는 동시에 ‘아파치 방식(Apache Way)’이라는 독특한 문화 아래에서 관리된다.

ASF는 1999년 설립된 미국의 공식 비영리단체다. ASF 설립에 참여한 이들은 이미 1995년부터 1999년까지 ‘아파치그룹’이란 이름으로 활동했으며, 당시 ‘아파치 HTTPD 웹서버’를 개발하는 데 힘쓰고 있었다. 아파치 웹서버는 누구나 무료로 사용할 수 있고, 소스코드를 수정하고 재배포할 수 있는 서버였다. 동시에 지속적인 유지보수도 필요했다. 당시 브라이언 벨렌도프(Brian Behlendorf)라는 개발자는 보다 체계적으로 아파치 웹서버 기술을 개선하고자 메일링 리스트를 만들었고, 이후 많은 기여자가 협업하면서 아파치 웹서버 기술을 발전시켰다.

ASF는 왜 하필 ‘아파치’라는 이름을 사용했을까? 아파치는 미국의 인디언 부족명에서 따왔다고 한다. 아파치 부족은 용맹한 전사를 거느리고 다양한 전략을 구상하는 종족으로 유명했으며, 19세기 미국 군대와 직접 전투를 벌이기도 했다. 또한 ‘패치 웹서버(patchy web server)’라는 발음과 비슷한 점도 아파치라는 이름을 선택하는 데 영향을 끼쳤다. 패치는 어떤 프로그램을 일부 수정하는 작업을 뜻한다.

아파치 서버는 향후 전 세계 웹사이트 중 65%가 사용할 만큼 인기 있는 기술이 됐다. 아파치그룹은 이외에도 자바, 펄, PHP와 관련된 다양한 오픈소스 프로젝트를 진행했다. 다양한 기술을 만들었던 개발자들은 법률적인 조언이나 경제적인 지원을 해줄 수 있는 체계적인 단체가 필요하다고 느꼈고, 그에 따라 ASF가 설립됐다.

ASF는 오픈소스 기여자들이 소프트웨어 개발에 집중하도록 도와주고 있다. 예를 들어 ASF는 오픈소스 개발에 필요한 하드웨어를 제공하거나 커뮤니케이션을 보다 쉽게 할 수 있게 지원한다. 개인들이 지적재산권 분쟁 같은 소송에 휘말리지 않도록 법적인 보호막도 제공한다. 다른 단체에서 ‘아파치’라는 브랜드를 함부로 사용하지 못하도록 막는 역할도 맡고 있다.

2.2 Apache License History

아파치 재단이나 재단의 프로젝트에 의해서 만들어진 모든 소프트웨어는 현재 아파치 라이선스 버전 2.0에 의해 배포되고 있다. 아파치 라이선스 버전 2.0은 2004년 아파치 재단에 의해 승인되었다. 버전 2.0으로 개정한 이유는 많은 프로젝트들이 라이선스를 수정할 필요 없이 재사용할 수 있도록 하고, 기여코드(Contribution)의 제출에 대한 라이선스를 명확히 하며, 기여자들의 특허에 대한 특허 라이선스를 요구하는 등의 내용을 반영하기 위해서였다. 라이선스 개정에 따라, 아파치 그룹의 원래 목표에 충실 하면서도 다른 오픈소스 라이선스들과의 상호운용성도 높아지게 되었다. 아파치 재단에서 만들어진 모든 패키지들은 특별한 언급이 없어도 아파치 라이선스 버전 2.0에 의해 배포된다.

아파치 라이선스의 가장 큰 프로젝트는 안드로이드 플랫폼이다. 커널과 애플리케이션을 제외한 안드로이드 플랫폼의 많은 부분은 아파치 라이선스로 배포되고 있다. 하지만 일부 요소들은 CPL, EPL, GPL, LGPL 등으로 배포되고 있으며, 이들은 아파치 라이선스가 아닌 각각의 라이선스 규칙을 따라야 한다는 점을 주의해야 한다. ※ 아파치 라이선스 모든 버전 http://www.apache.org/licenses/

2.3 (그 외) Apache Way

ASF에서 만드는 소프트웨어는 리눅스나 파이썬처럼 특정 한 사람을 중심으로 개발되지 않는다. 같은 관심을 가진 그룹이 모여 정보를 공유하며 집단으로 개발한다. ASF가 제공하는 오픈소스 프로젝트들은 ‘아파치 라이선스’로 배포된다. 아파치 라이선스는 다른 오픈소스 라이선스보다 자유도가 높은 편이다.

ASF의 커뮤니티 운영 방식은 조금 독특하다. 먼저 각 오픈소스 기술은 ‘PMC’(Project Management Committees) 소속 기여자들이 주도한다. ASF 프로젝트에는 누구나 기여할 수 있으나 오류 보고 같은 비교적 단순한 참여만 가능하다. PMC 멤버처럼 소스코드에 접근 권한을 가진, 보다 핵심적인 기여자가 되려면 기존 PMC 멤버들로부터 초대를 받아야 한다. 모든 의사소통은 동료들의 의견을 기반으로 결정되며, 의견이 좁혀지지 않으면 투표를 거쳐 의사결정을 한다.

PMC 외에 ASF 운영조직, ASF 이사회, ASF 멤버도 따로 존재한다. ASF 이사회는 9명으로, ASF 멤버들이 투표를 거쳐 선출한다. ASF 오픈소스 프로젝트의 기술 기여자는 수천 명이지만 ASF 멤버는 500여명 규모로 작다. ASF 멤버는 기존 멤버의 추천 혹은 투표를 통해서 될 수 있다. ASF는 이처럼 기여도나 관심이 높은 사람에게 특정 권한을 주는 방식을 ‘능력주의(Meritocracy)’라고 부른다.

ASF는 내부 문화도 아파치 방식을 적용했다. ASF에 속한 모든 사람들은 ▲소프트웨어 협업 개발 ▲상업적으로 활용할 수 있는 표준 라이선스 ▲고품질 유지되는 소프트웨어 ▲서로 존경하며 정직하게 기술 교류를 할 것 ▲표준에 충실할 것 ▲보안 기능에 충실할 것이라는 6가지 원칙을 따라야 한다.

ASF 멤버나 PMC 멤버 대부분 무급으로 일하며 재능기부의 일환으로 커뮤니티 활동을 하고 있다. 하지만 재단을 운영하기 위해서는 어느 정도 비용이 필요한데, ASF는 이를 후원을 통해 해결하고 있다. 핵심 후원사로는 피보탈, 페이스북, 클라우데라, 구글, 야후, 마이크로소프트, 리스웹이 있으며 이 외에도 40여개 기업이 다양한 규모로 ASF를 후원하고 있다

출처 (1) Apache Histroy - http://navercast.naver.com/contents.nhn?rid=122&contents_id=116802 (2) Apache Way - http://www.slideshare.net/shanecurcuru/the-apache-way-16769653

3. GPL(General Public License)

3.1 FSF(Free Software Foundation) 출현 배경

Free Software 의미

자유 소프트웨어’의 ‘자유(Free)’가 ‘무료’를 뜻하는 건 아니다. ‘표현의 자유’라는 말에서 자유가 무료가 아니라 특정 사항에 구속되지 않은 관점을 말하듯, 자유 소프트웨어의 자유도 비슷한 의미를 지닌다. 자유 소프트웨어의 반대 개념은 ‘독점’ 소프트웨어다. 소프트웨어 소스코드를 특정 기업이 독점하는 사례를 가리킨다. ‘마이크로소프트(MS) 오피스’ 같은 제품을 생각하면 쉽다. MS 오피스 제품의 소스코드는 공개돼 있지 않기 때문에 아무나 수정하지 못한다. 사용자 측면에서도 비용을 지불하지 않으면 함부로 설치할 수 없다.

자유 소프트웨어는 자유의 의미를 크게 4가지로 보고 있다.

1. 프로그램을 어떠한 목적을 위해서도 실행할 수 있는 자유.
2. 프로그램의 작동 원리를 연구하고 이를 자신의 필요에 맞게 변경시킬 수 있는 자유. 이러한 자유를 위해서는 소스코드에 대한 접근이 선행돼야 한다.
3. 이웃을 돕기 위해서 프로그램을 복제하고 배포할 수 있는 자유.
4. 프로그램을 향상시키고 이를 공동체 전체의 이익을 위해서 다시 환원시킬 수 있는 자유. 이러한 자유를 위해서는 소스코드에 대한 접근이 선행돼야 한다.

Free Software Foundation과 GNU

소프트웨어도 기업 자산이라고 생각한다면 기업이 소프트웨어 소스코드를 공개하지 않고 유료로 판매하는 것이 무슨 문제일까 생각할 수 있다. 자유소프트웨어재단을 만든 리처드 스톨만은 이런 생각에 반기를 들었다. 리처드 스톨만은 소프트웨어가 처음에 등장했을 때부터 공유 정신이 널리 퍼져 있었다는 점을 강조한다. 실제로 스톨만은 1970년 MIT 인공지능 연구소에 들어갔을 때 ‘ITS’(Incompatible Time-sharing System)란 운영체제를 이용했다. 리처드 스톨만을 포함한 내부 연구원들은 ITS 운영체제를 개선하는 데 기여했으며, 다른 대학이나 기업에서 MIT 연구소가 만든 기술을 이용하고 싶다고 요청하면 스스럼없이 프로그램을 빌려주었다. 리처드 스톨만은 이러한 문화를 “요리법을 공유하는 것이 요리의 역사만큼 오래된 것처럼, 소프트웨어를 공유하는 것은 컴퓨터의 역사만큼이나 오래된 것이었다”라고 표현했다.

리처드 스톨만이 경험한 소프트웨어 공유 문화는 1980년부터 달라진다. PC 및 소프트웨어 산업이 발전하고 관련 기업들이 생겨나며 소프트웨어에 특허나 독점에 관한 법률을 적용하는 경우가 늘어났다. 사용자들은 소프트웨어에 쉽게 접근할 수 없었고, 개발자 역시 서로 협력하는 길이 막혔다. 리처드 스톨만은 자신이 경험했던 소프트웨어 공유 문화를 되살리고 싶었다. 이를 위해 스톨만은 먼저 프로그램을 만들기로 했다. 그렇게 시작한 것이 ‘GNU’(그뉴) 프로젝트다.

GNU는 유닉스와 호환되는 운영체제다. 리처드 스톨만은 소프트웨어 공유 운동을 시작하기 위해 가장 먼저 필요한 게 운영체제라고 생각했다. 운영체제는 컴퓨터를 사용하는 데 필요한 핵심 소프트웨어이고, 운영체제가 있다면 컴퓨터를 이용해서 다양한 종류의 작업을 할 수 있었기 때문이다. 따라서 자유롭게 사용할 수 있는 운영체제가 있다면 상호 협력하는 개발자들이 공동체를 다시 한번 만들 수 있을 거라고 스톨만은 판단했다.

리처드 스톨만이 ‘유닉스’ 계열 운영체제를 만들기로 한 이유는 기존 유닉스 사용자들이 새로운 시스템에 쉽게 적응할 수 있으리라고 생각했기 때문이었다. GNU라는 이름은 ‘GNU는 유닉스가 아니다’(Gnu is Not Unix)라는 문장의 첫 글자를 따서 만든 약어다. GNU는 유닉스와 호환되도록 만들어진 운영체제이기는 하지만, 유닉스와는 다른 운영체제라는 의미를 내포하기 위해 만든 이름이다. GNU 프로젝트에선 시스템 리소스를 관리하는 커널 ‘허드’를 만들기도 했는데, 1991년 리눅스가 관심을 받으면서 GNU 도구에 리눅스 커널이 통합됐다.

리처드 스톨만은 1985년 GNU 프로젝트를 지원하기 위한 자유소프트웨어재단을 설립한다. 그러면서 운영체제를 만드는 것 외에 라이선스도 함께 만들어 공유 운동을 펼쳤다.즉 자유를 실질적으로 보장하기 위해 리차드 스톨만은 자신의 소프트웨어에 대한 저작권을 확보한 뒤, 이러한 권리를 전제로 해당 저작물을 일정한 조건에 의해 사용하도록 허락하는 ‘GNU GPL(GENERAL PUBLIC LICENSE, 일반 공중 사용 허가서)’를 만들었다. 이를 줄여서 ‘GPL’이라고 표현하기도 한다.

GPL는 지켜야 할 조항이 많은 라이선스였는데, 자유소프트웨어재단은 이를 조금씩 완화하면서 GPL 버전1, 버전3 식으로 새롭게 라이선스를 수정해 공개했다. 또한 누구나 GPL 위반사항을 발견하면 자유소프트웨어재단에 신고할 수 있게 했다. 자유소프트웨어재단은 이런 식으로 소프트웨어 공유 문화에 도움이 되도록 라이선스를 발전시키는 식으로 GPL 문화를 퍼뜨리는 운동을 진행하고 있다. 현재 GPL은 전체 오픈소스 가운데 2번째로 많이 사용되고 있다.

3.2 GPL 2.0 License History

대부분의 상용 소프트웨어 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위해 고안되었다. 반면에 GPL은 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도 되었다. 즉, 소프트웨어가 사용자 모두에게 자유롭게 이용될 수 있도록 하는 것이다. GPL은 자유소프트웨어재단(FSF)의 소프트웨어 대부분을 비롯하여 저작자가 이 라이선스의 사용을 지정한 기타 모든 프로그램에 적용된다. 누구나 자신의 프로그램에 이 라이선스를 적용시킬 수 있다.

자유 소프트웨어란 말에서 사용되는 '자유 Free' 라는 단어는 무료라는 금전적인 의미가 아니라 자유(Freedom)를 의미한다 FSF의 라이선스들은 이용자가 자유 소프트웨어의 복제본을 배포할 수 있는(그리고 원한다면 판매할 수 있는) 자유를 보장하기 위해 고안되었다. 또한 소스코드를 받거나, 원하면 얻을 수 있고, 소프트웨어를 수정하거나 그것의 일부를 새로운 자유 프로그램 내에서 사용 할 수 있으며, 이상과 같은 일들을 할 수 있다는 사실을 알 수 있도록 보장하기 위해 고안되었다.

이용자의 권리를 보호하기 위해서는 다른 사람이 이용자의 권리를 부정하거나 포기하도록 요구하는 행위를 금지하기 위한 규정을 만들어야 한다. 이러한 규정들은 이용자가 소프트웨어 복제본을 배포하거나 수정할 경우에 당신에게도 특정한 의무를 부과한다. 즉 프로그램을 무상이나 유상으로 배포할 경우 모든 권리를 수취인에게 전달해야 한다.

3.3 GPL 3.0 License History

1991년 배포된 GPl 2.0은 2007년까지 16년 동안 수정 없이 사용되었다. 소프트웨어 관련 기술과 이를 둘러싼 시장, 제도의 변화속도에 비추어 보면 상당히 오랜 기간 동안 개정되지 않고 사용된 것으로 평가할 수 있다. 하지만 1990년대 초반 오픈소스 소프트웨어가 널리 사용되기 이전에 만들어진 GPL2.0은 최근의 변화된 상황에서 조금씩 그 한계를 드러내고 있었다. 예컨대 자유/오픈소스 소프트웨어 운동이 미국에서 시작되었으며 GPL 2.0도 미국의 법제도를 기반으로 만들어졌는데, 현재 자유/오픈소스 소프트웨어 및 GPL은 전 세계적으로 사용되고 있으며, 그에 따라 각국 법제도의 차이를 반영할 필요성이 제기되었었다. 이밖에 소프트웨어 특허의 확대와 그에 따른 위험의 증가, 자유/오픈소스 소프트웨어 라이선스들의 증가와 양립성 문제, DRM 기술의 확대적용과 법에 의한 보호, 네트워크서버기반 소프트웨어의 증가, P2P 등 새로운 기술의 등장 등 일련의 환경변화로 GPL개정의 필요성은 더욱 증대되었다.

하지만 자유/오픈소스소프트웨어와 GPl의 사용자 층이 넓어진 만큼 개정작업은 더욱 복잡해졌다. 1991년 GPL 2.0이 발표될 당시 리차드 스톨만이 몇몇 법률가와 개발자들로부터 의견을 수렴하긴 했었지만, GPL의 개정에 있어 공식적인 의견수렴 절차나 논의가 필요한 것은 아니었다. GPL 2.0이 발표되고 FSF는 곧바로 GNU 프로젝트의 결과물들을 GPL 2.0으로 교체하였으며, 리누스 토발즈도 리눅스 커널에 GPL 2.0을 채택하였었다. 하지만 이번의 상황은 그렇지 못했다. GPL은 전세계 수만개의 프로젝트에서 사용되고 있었으며, PC, 서버 운영체제로부터 휴대폰, PD, 셋탑박스, 홈네트워킹 장비 등의 임베디드 소프트웨어 분야에서 광범위하게 사용되고 있었다. 다시 말하면 더 이상 FSF의 GNU프로젝트에서만 사용되는 라이선스가 아니며, 그야말로 자유/오픈소스소프트웨어에 관계된 수많은 기업과 사람들이 지켜야 할 행동규범의 지위를 갖게 된 것이다.

FSF는 수년간 자유/오픈소스 소프트웨어 커뮤니티, 산업계, 학계 등과 공식적으로 또는 비공식적으로 GPL의 개정에 대해 논의해 왔으며, 이를 바탕으로 마련한 첫 번째 안(First Discussion Draft)을 2006년 1월 발표하였다. 초안의 발표와 함께 다양한 의견을 수렴하기 위한 토론위원회 등의 공식적인 프로세스를 만들었다. 이를 바탕으로 인터넷을 통한 의견 수렴, 수차례의 국제 컨퍼런스를 거쳐 2006년 7월에 두 번째 안을, 2007년 3월과 5월에 세 번째 안과 네 번째 안을 발표하였으며, 2007년 6월 29일 마침내 공식적으로 GPL 3.0을 발표하였다. GPL의 개정과정에서 가장 논란이 되었던 내용은 DRM(또는 Tivoization) 관련 쟁점, 특허권의 취급, 오픈소스 라이선스간의 양립성, 네트워크 서버 형태로 GPL 소프트웨어를 이용하는 경우의 처리 등이다. 이 밖에 소스코드의 범위를 명확히 하고, 새로운 용어를 정의하는 등의 수정이 있었다.

3.4 Affero GPL 3.0 History

Affero GPL(AGPL)은 네트워크 서버 소프트웨어의 사례에서 커뮤니티와의 협력을 보장하기 위해 만들어진 라이선스이다. Affero GPL은 GPL 라이선스를 기반으로 만들어진 라이선스로서, Affero GPL 1.0은 GPL 2.0을 기반으로 Affero GPL 3.0은 2007년 GPL 3.0을 기반으로 제정되었다.

모든 사용자의 자유를 보호하는 것의 부차적 이익은, 프로그램의 대체 버전에서 만들어진 개선 사항들을 널리 통용되는 경우, 다른 개발자들이 그것을 통합하여 사용하는 것이 가능해진다는 것이다. 많은 자유 소프트웨어 개발자들은 이러한 결과로 이루어진 협력에 의해 고무되고 용기를 얻는다. 그러나, 네트워크 서버에서 사용되는 소프트웨어의 경우에는 이러한 결과가 나오지 않을 수도 있다. GPL은 수정 버전을 만들고, 소스코드를 공중에게 릴리즈 하지 않은 상태로 공중이 수정 버전을 서버상에서 접근하도록 하는 것을 허용한다. Affero GPL은 그러한 경우에 수정된 소스코드가 커뮤니티에 제공되도록 보장하기 위해 특별히 고안되었다. 그것은 네트워크 서버의 운영자가 그곳에서 실행되고 있는 수정 버전의 소스코드를 해당 서버의 사용자들에게 제공하도록 요구한다. 따라서, 공개적으로 접근 가능한 서버상에서 수정 버전을 공개적으로 사용하는 것은 수정 버전의 소스코드에 대한 공개적 접근을 허용하는 것이다.

3.5 LGPL License History

Lesser GPL(LGPL) 라이선스는 라이브러리는 공유하되 개발된 제품에 대해서는 소스를 공개하지 않고 상용 SW 판매가 가능하도록 허용한 것으로, GPL보다 완화된 라이선스이다. LGPL 2.1은 GNU Lesser General Public License의 이름으로 공표된 최초의 버전인데, GNU Library General Public License 버전 2의 후속판으로 간주되기 때문에 버전 번호를 2.1로 붙인 것이다. LGPL 3.0은 GPL 3.0 기반으로 만들어 졌다.

LGPL 라이선스는 자유소프트웨어 재단이나 기타 저작자의 소프트웨어 중에서 주로 라이브러리와 같이 특수하게 고안된 일부 소프트웨어 패키지에 적용된다. 예를 들어 만약 라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야한다. 또한 수취인이 소스코드를 받을 수 있도록, 혹은 필요에 따라서 스스로 구할 수 있도록 보장해주어야 한다. 만약 라이브러리에 다른 코드를 링크시켰다면, 수취인이 라이브러리를 수정하여 컴파일하는 경우에도 다시 링크를 걸 수 있도록 그 코드에 해당하는 완전한 오브젝트 파일 전체를 함께 제공해야 한다. 그리고 수취인이 이와 같은 권리를 분명히 알 수 있도록 관련 조항들을 보여주어야 한다.

3.6 Free Software vs OpenSource

자유 소프트웨어가 등장하고 시간이 지나며 몇 가지 단점이 지적되기 시작됐다. 자유 소프트웨어는 제약이 많은 GPL 조항 때문에 상용 기술 개발에서 활용할 수 없다는 지적이 대표적이다. 에릭 레이먼드, 브루스 페런스 등은 ‘오픈소스’(Open Source)라는 새로운 용어를 제안하고, 기업들이 소스코드 공개에 보다 많이 참여할 수 있도록 지원했다. 동시에 1998년 에릭 레이먼드와 브루스 페런스는 ‘오픈소스 이니셔티브’(Open Source Initiative, OSI)를 설립하고 오픈소스에 해당하는 라이선스의 최소한의 기준을 정의(Open Source Definition, OSD)해 놓았다. OSI는 이 정의에 따라 인증, 관리 및 촉진하는 일을 진행하고 있다. 현재 업계에선 자유 소프트웨어와 오픈소스를 혼용해서 쓰는 경우가 많지만, 일반적으로 오픈소스 소프트웨어는 자유 소프트웨어를 포함한 넓은 의미로 사용된다.

자유소프트웨어재단은 오픈소스 소프트웨어라는 용어에는 ‘자유롭게 사용할 수 있는 권리’가 포함되어있지 않다고 보고 자유 소프트웨어라는 용어를 사용하기를 권장한다. 그렇다고 두 문화가 서로 적대적인 관계는 아니다. GNU 프로젝트 공식 홈페이지에서는 “자유 소프트웨어 운동과 오픈소스 운동은 공동체에 있어서 두 개의 정당과도 같다”라며 “자유 소프트웨어 운동과 오픈소스 운동은 기본 원칙에 대해서 의견을 달리하지만, 모든 현실적인 방안에 대해서는 같은 생각을 하고 있으며 세부적인 프로젝트에서 같이 협력하고 있다”라고 설명하고 있다. 특히 “자유 소프트웨어 운동에 있어서 우리는 오픈소스 운동을 적이라고 생각하지 않는다”라며 “우리의 적은 독점 소프트웨어”라고 강조한다

3.7 자유소프트웨어재단 설립 30년 후

과거 일부 사람들은 리처드 스톨만을 ‘사회주의자’라고 표현할 만큼 지나친 이상주의자로 여겼다. 자유소프트웨어재단이 설립된 지 30년이 지난 현재 IT 업계 모습을 보면 리처드 스톨만의 꿈이 조금씩 실현되는 모습이다. 과거 자유소프트웨어 문화에 반대하던 많은 사람들은 “금전적인 혜택이 없으면 아무도 프로그래밍을 하지 않을 것이다”, “소프트웨어 개발도 경쟁을 통해서 보다 나은 결과를 얻을 수 있다”, “GNU가 무료라면 아무도 그것을 사용하지 않을 것이다”와 같은 주장을 했다. 하지만 지금은 많은 개발자들이 자유 소프트웨어와 오픈소스 운동에 동의하고, 깃허브와 같은 오픈소스 저장소에 앞다퉈 소스코드를 올리고 있다. 한국 및 전 세계 IT 기업에서 오픈소스 기여 여부는 개발자 면접 시 중요한 요소로 평가되고 있다.

특히 개발자 문화가 발달한 IT 기업일수록 오픈소스에 대한 투자가 활발하다. 구글과 페이스북은 오픈소스 기술에 가장 적극적으로 동참하는 기업으로 꼽힌다. 구글은 지금까지 900개가 넘는 오픈소스 프로젝트를 공개했으며, 페이스북도 330개 이상의 오픈소스 프로젝트를 ‘모두의 자산’으로 공개했다. 심지어 오픈소스를 ‘암덩어리’로 묘사했던 마이크로소프트조차 “MS는 리눅스를 사랑한다”와 같은 발언을 통해 오픈소스 진영 개발자와 사용자에게 러브콜을 보내고 있다. 오픈소스 기술만 유지·보수하는 전문 기업도 늘어나고 있다.

오늘날 대다수 IT 기업들은 전 세계 많은 개발자와 협력할수록 좋은 소스코드를 만들 수 있다는 생각에 대체로 동의하고 있다. 때로는 실력 있는 개발자를 채용하거나 마케팅 효과를 노리는 수단으로 오픈소스 프로젝트를 진행하기도 하다. 여기엔 기여자 수와 사용자 수를 늘려 특정 기술의 생태계를 확보하려는 전략도 숨어있다. 특히 구글이 ‘안드로이드’라는 모바일 운영체제를 오픈소스로 공개해 새로운 시장 경쟁력을 얻은 것은 오픈소스 생태계의 좋은 롤모델로 꼽힌다.

3.8 라이브러리에 LGPL을 사용하지 말아야 하는 이유

GNU 프로젝트는 라이브러리에 두 가지 주된 이용허락(라이선스)를 사용하고 있습니다. 하나는 LGPL이라 불리는 GNU Lesser GPL이고 또 다른 하나는 일반적인 GNU GPL입니다. 이용허락의 선택은 큰 차이를 유발합니다. LGPL이 적용된 라이브러리는 독점 소프트웨어에 사용될 수 있지만, 일반적인 GPL이 적용된 라이브러리는 단지 자유 프로그램에서만 사용될 수 있습니다.

특정한 라이브러리에 어떤 이용허락을 적용하느냐는 전략적인 문제이기 때문에 구체적인 상황에 따라 달라질 수 있습니다. 현재 대부분의 GNU 라이브러리들은 LGPL을 따르고 있는데, 이것은 우리가 두 가지 전략 중에서 하나는 무시한 채 다른 한가지 전략만을 추구하고 있다는 것을 의미합니다. 이런 이유 때문에 우리는 더욱 많은 라이브러리들을 LGPL이 아닌 일반적인 GPL로 배포하려고 노력하고 있습니다.

독점 소프트웨어 개발자들은 비용면에서 비교 우위를 갖고 있습니다. 그렇게 때문에 자유 소프트웨어 개발자들은 이러한 부분을 상쇄시킬 수 있는 이점을 서로에게 제공해 주어야 할 필요가 있습니다. 라이브러리에 일반적인 GPL을 적용하게 되면 자유 소프트웨어 개발자들은 이를 사용할 수 있지만, 독점 소프트웨어 개발자들은 사용할 수 없게 되어 자유 소프트웨어 개발자들에게 이점을 제공해 줄 수 있습니다.

일반적인 GPL의 적용이 모든 라이브러리에 장점을 제공해 주는 것은 아닙니다. 어떤 경우에는 LGPL을 사용하는 것이 더 좋습니다. 이러한 경우의 일반적인 형태는 GPL을 적용한 라이브러리의 기능이 다른 대체 라이브러리를 통해 독점 소프트웨어에서도 쉽게 구현될 수 있을 때입니다. 이러한 경우에는 GPL이 적용된 라이브러리가 자유 소프트웨어에 대한 특별한 이점을 보장해 줄 수 없기 때문에 단순히 LGPL을 적용하는 것이 그 사용 범위를 넓히기 위해서라도 더 좋다고 볼 수 있습니다.

이러한 이유 때문에 우리는 GNU C 라이브러리에 LGPL을 사용했습니다. GNU C 라이브러리 이외에도 다른 C 라이브러리들이 많이 존재하기 때문에 만약 GNU C 라이브러리에 GPL을 적용하게 되면 독점 소프트웨어 개발자들은 그들이 사용할 수 있는 다른 C 라이브러리를 사용하게 될 것입니다. 이러한 결과는 우리에게 문제를 더 가져다 줄 뿐이며 독점 소프트웨어 개발자들에게는 아무런 문제가 되지 않습니다.

그러나 만약 어떤 라이브러리가 GNU Readline의 경우와 같이, 독자적이고 중요한 기능을 제공하는 것이라면 그것은 전혀 별개의 문제입니다. Readline 라이브러리는 에디터나 셸과 같이 대화형으로 진행되는 프로그램을 사용할 때 명령행 편집이나 히스토리 기능을 제공하는데, 이러한 기능은 다른 라이브러리에서 일반적으로 찾아볼 수 없는 특징적인 것입니다. 따라서 Readline에 GPL을 적용하게 되면 Readline의 사용을 자유 소프트웨어에만 한정시킬 수 있기 때문에 자유 소프트웨어 공동체에 실질적인 힘이 될 수 있습니다. Readline의 기능을 포함시키고자 하는 소프트웨어를 자유 소프트웨어로 만들 수 있는 것입니다.

만약 우리가 독점 소프트웨어에는 찾아볼 수 없는 기능을 가진 GPL 기반의 강력한 라이브러리들을 축적할 수 있다면 그것은 새로운 자유 소프트웨어를 개발할 수 있는 매우 유용한 모듈로 활용될 수 있을 것입니다. 이것은 자유 소프트웨어의 개발에 더욱 큰 이점을 줄 것이고, 어떤 프로젝트들은 GPL이 적용된 라이브러리를 사용하기 위해서, 앞으로 개발될 소프트웨어를 자유 소프트웨어로 만들기로 결정하기도 할 것입니다. 대학의 프로젝트는 이러한 영향을 쉽게 받을 수 있습니다. 최근에는 기업들도 자유 소프트웨어를 만들기 시작했으며, 심지어 몇몇 상업 프로젝트도 이러한 영향을 받게 되었습니다.

자유 경쟁이 갖고 있는 중요한 이점을 부정하려고 하는 독점 소프트웨어 개발자들은 프로그램 저작자들에게 라이브러리를 GPL 소프트웨어에 포함시키지 말 것을 설득하려고 노력할 것입니다. 예를 들면, 만약 라이브러리를 독점 소프트웨어 제품을 만드는데 사용하면 보다 많은 사용자들이 그 라이브러리를 쓰게 될 것이라고 주장할 지도 모릅니다. 이러한 점을 프로그램 저작자들의 자존심과 공명심에 빌어 설득할 경우에는, 상당한 인기를 가진 하나의 라이브러리를 만들어 내는 것이 마치 자유 소프트웨어 공동체가 당면한 가장 필요한 요구라는 그릇된 판단을 유도하게 될 수 있습니다.

그러나 우리는 이러한 유혹에 넘어가서는 안됩니다. 왜냐하면 우리는 GPL 라이브러리를 통한 단결을 통해 더욱 많은 것들을 달성할 수 있기 때문입니다. 자유 소프트웨어 개발자들은 서로가 서로를 지원해야만 합니다. 라이브러리를 자유 소프트웨어에 한정해서 배포하는 방법을 통해 우리는 동료 개발자들이 만든 자유 소프트웨어 패키지들이 이에 대응되는 독점 소프트웨어를 능가하도록 도울 수 있습니다. 이러한 방법들을 통해 자유 소프트웨어가 전반적인 경쟁 우위를 갖게 되면 자유 소프트웨어 운동 전체가 보다 많은 인기를 얻게 될 것입니다.

출처 (1) FSF History - http://navercast.naver.com/contents.nhn?rid=122&contents_id=110382 (2) FSF 철학 - https://www.gnu.org/philosophy/free-sw.html (3) 오픈소스와의 구분 - https://www.gnu.org/philosophy/categories.html (4) GPL 2.0, 3.0, AGPL, LGPL Histroy - 문화채육관광부 오픈소스 라이선스 책자 History (5) LGPL을 사용하지 말아야 하는 이유 - https://www.gnu.org/licenses/why-not-lgpl.html

4. MPL(Mozilla Public License)

4.1 Mozilla Foundation 출현 배경

모질라 프로젝트는 1998년 네비게이터와 익스플로러와의 브라우저 전쟁에서 불리함을 느낀 넷스케이프에가 브라우저 스위트의 소스 코드를 공개하여 수천 명에 이르는 프로그래머들이 일으키는 혁신의 힘으로 브라우저 시장을 다시 한번 리드해 나가고자 하는 의도로 시작되었다. 한 해가 지나지 않아서 새로운 커뮤니티 멤버들은 실제로 새로운 기능과 기존 기능의 업그레이드와 함께 프로젝트 자체의 기획과 관리에도 깊숙하게 관여하기 시작했다.

비록 특정 기업에서 주관하였지만, 오픈 커뮤니티로서 모질라 프로젝트는 이미 기업의 조직범위를 넘어서서 성장하기 시작했고, 커뮤니티 멤버들은 프로젝트가 원래 지향했던 미션의 범위를 넘어 다양한 다른 브라우저나 개발 도구의 개발 등과 같은 프로젝트에도 참여하였다. 사람들은 다양한 방식으로 모질라 프로젝트에 공헌했는데, 이들의 노력은 2002년 모질라 1.0 버전이 출시되면서 그 빛을 보게 된다. 이 버전은 기존의 네비게이터 브라우저의 기능을 크게 업그레이드했을 뿐만 아니라, 이메일 클라이언트를 포함한 다양한 애플리케이션들도 포함된 스위트의 형태를 취했다. 그러나, 이미 브라우저 시장의 판도는 인터넷 익스플로러로 넘어간 상태였다. 2002년 90%가 넘는 인터넷 사용자들이 인터넷 익스플로러의 사용자들이었고, 모질라의 발표가 이를 뒤집을 수 있는 힘을 발휘하기에는 아직 그 힘이 너무 미약하였다. 모질라에서의 새로운 브라우저인 피닉스(Phoenix)도 2002년에 발표되었는데, 이 브라우저가 이후 파이어폭스(FIrefox)가 되면서 구글의 크롬이 나오기 전까지 입지를 조금씩 넓히면서 마이크로소프트 인터넷 익스플로러에 그나마 대항할 수 있는 브라우저로서 분전하였다.

2003년 모질라 프로젝트는 AOL의 손을 떠나 독립적인 비영리 재단인 모질라 재단으로 이관된다. 새로운 모질라 재단은 개방성을 유지하면서, 혁신과 인터넷의 기회를 확대하기 위한 다양한 역할을 하면서 파이어폭스와 썬더버드(Thunderbird) 등이 발표될 수 있도록 하였고, 웹의 접근성 확대와 같은 공익적인 사업을 지원하기 위한 연구기금을 제공하기도 하였다. 2004년 발표된 파이어폭스 1.0은 큰 성공을 거두면서, 1억 건 이상의 다운로드를 기록하였고, 그 이후 시장점유율을 확대하면서 2008년에는 전 세계 브라우저 시장의 20%를 돌파하는 기염을 토하기도 하였다.

그러나, 모질라 프로젝트와 모질라 재단의 이런 성공은 결코 쉽게 이루어진 것이 아니었다. 오픈소스 프로젝트는 그냥 놔둔다고 알아서 굴러가는 그런 것이 아니다. 넷스케이프는 모질라 프로젝트를 위해 운영진으로 6~8명의 인력을 투입했고, 100~150명 정도의 넷스케이프 제품 엔지니어들이 만든 코드를 기부하는 방식으로 모질라 프로젝트를 운영하였다. 그러나, 넷스케이프를 사들인 AOL의 태도가 조금씩 변하기 시작하였다. AOL은 넷스케이프 클라이언트를 통해서 AOL 웹사이트로 들어오는 트래픽이 늘기를 바랬지만, 모질라 프로젝트 팀은 오픈소스 프로젝트의 운영원칙에 따라서 프로젝트를 진행시켜야 했기 때문에 AOL의 다양한 압력에 저항해야만 했다. 이 과정에서 모질라의 운영진들은 모질라 프로젝트가 AOL에 소속된 넷스케이프 엔지니어들이 주도하게 되기 보다는 외부의 순수한 개발자들에 의해 주도가 되어야 한다는 것을 깨닫고 가능한 핵심 기술이 새로운 오픈소스 개발자들에게서 개발될 수 있도록 꾸준히 유도하였다. 이런 와중에 넷스케이프 제품군의 시장점유율은 꾸준히 하락한다.

급기야 AOL 내부에서 2가지 대립되는 시각이 등장하였다. 하나는 오프소스가 놀라운 변화를 가져올 수 있고, 이를 적극적으로 지지하면서 커다란 커뮤니티를 만들어야 한다는 것이었고, 다른 하나는 주로 경영진에서 가진 시각으로 모든 결정은 이익에 기반을 해야 한다는 것이었다. 모질라 운영진들은 AOL의 경영진들과 의견이 매우 달랐다. AOL에 이익을 가져다 주는 방향으로 운영을 해서는 자발적인 자원봉사자들과 다른 상업적 파트너들의 열성적인 참여를 유도할 수 없고, 그로 인해 프로젝트의 질이 떨어진다면 결국 모질라 프로젝트는 실패할 수 밖에 없다는 것을 그들은 너무나 잘 알고 있었다. 이런 갈등의 와중에 발표된 넷스케이프 6기 시장에서 처절한 실패를 하면서 상황은 더욱 악화되었다. 특히 UI 요소를 둘러싼 양측의 갈등이 심했다고 한다. 예를 들어, 특정 버튼을 통해 AOL 사이트로 유입하게 한다거나, 광고와 관련한 요소를 집어넣고, 돈을 지불한 파트너들이 매출을 일으킬 수 있는 요소를 넣는다는 것 등이 대표적인 것들이다.

이런 갈등이 지속되면서 모질라 프로젝트의 운영진들은 AOL의 직원으로서의 지위와의 상충됨을 느낄 수 밖에 없었다. 그러나, 그들은 프로젝트의 본질을 훼손할 수 없었기에 사사건건 경영진들과 충돌하는 양상이 계속되었다. 넷스케이프 6의 발표 이후 넷스케이프 브라우저를 이용한 매출이 계속 감소하자 결국 AOL은 칼을 빼들었다. 그들은 2001년 모질라 프로젝트를 이끌던 미첼 베이커(Mitchell Baker)를 해고하고, 모질라 프로젝트를 직접 접수하려는 시도를 하였다. 그러나, 모질라 프로젝트의 운영진들도 그렇게 앉아서 당할 수는 없었다. 한동안 외부에 권력투쟁 양상으로 비치는 다양한 사건이 모질라 프로젝트에 있었다. 특히 해고된 미첼 베이커는 직원으로서가 아니라 자원봉사자로 직위를 바꾸고 계속 출근을 하면서 프로젝트를 지켰다. 2002년 마침내 이렇게 지켜낸 프로젝트의 산물이 모질라 1.0이 출시되었다. 그러나, 많은 사람들이 프로젝트의 완성도에 놀라면서도 그다지 좋은 사용자 경험은 주지 못했다는 평가가 나왔다. 당시 미첼 베이커는 모질라 프로젝트 이외에 로터스 1-2-3를 만들었던 미치 카포(Mitch Kapor)와 다른 오픈소스 프로젝트도 진행하고 있었는데, 미치 카포는 미첼 베이커와 브렌단 아이크(Brendan Eich)에게 자신이 투자를 할테니 독립적인 모질라 재단을 만들어 보자는 제안을 하였다.

결국 2003년 AOL은 웹 브라우저 클라이언트에 대한 투자를 완전히 중단한다고 선언하였다. 그러자, 미첼 베이커는 AOL에게 모질라에 최소한의 초기 자금을 준다면 이를 자신들이 운영하겠다고 설득을 해서 2백만 달러의 자금을 받아내고 AOL이 모질라에서 손을 떼게 만들었다. 이 과정에서 안정된 직장을 버리고 불확실한 오픈소스 재단의 일을 위해 브렌단 아이크와 브라이언 벨렌도르프(Brian Belendorff), 크리스 블리자드(Chris Blizzard)도 넷스케이프를 나와서 이사진에 합류를 하면서, 모질라 재단이 탄생하였다. 모질라가 독립할 경우 이들을 적극 지원할 생각이 있었던 미치 카포는 30만 달러를 출연하면서 모질라 재단의 초대 이사장 자리에 올랐다. 이 와중에 모질라와 뜻을 같이 하는 일부 엔지니어들이 동참을 하면서 모질라 재단은 10명 정도의 소규모 인력으로 거대한 오픈소스 플랫폼을 운영해야 하는 운명에 처하게 된다.

모질라 재단의 시작도 이렇게 우여곡절이 많았지만, 운영도 보통 문제가 아니었다. 일단 이렇게 커다란 커뮤니티를 관리하면서 일을 진행시키기에 일하는 사람의 수가 너무 적었다. 특히 무엇보다 계획대로 진행된다고 가정하더라도 가장 중요한 제품인 파이어폭스는 15개월 이후에 출시될 예정이었고, 최소한 이 때까지 제대로 운영할 수 있는 자금부터가 당장 문제였다. 그런데, 놀라운 일들이 연달아 일어났다. 모질라에 우호적인 파트너가 사무실을 임대하고, 적은 공간이지만 임대료 없이 공짜로 공간을 빌려주었다. 비록 작고 아무것도 없는 열악한 환경이었지만, 모질라 재단을 이끌어가는 사람들에게는 커다란 희망과 행복감을 주기에 충분했다고 한다.

비록 핵심연구자들의 수는 적었지만, 이들은 정말 열심히 모질라 프로젝트를 위해서 일을 하였고, 완전한 오픈소스 운영조직으로서 사람들이 정말 원할만한 소비자 제품으로서의 브라우저 제품군을 만들기 위해 사람들의 힘을 모으자 그 성과는 명확해지기 시작했다. 소비자들에게 어필하기 위해서는 비주얼 디자인 요소가 중요했는데, 캐나다의 센터 아일랜드(Center Island)에서 몇몇 비주얼 디자이너들이 멋진 로고와 과거에는 보지 못했던 신선한 비주얼 요소들을 만들어 제공하였다. 마지막으로 검색이 문제였는데, 이 부분에는 구글과 야후! 등의 경쟁구도를 이용해서 검색박스를 이용한 모질라의 초기 비즈니스 모델을 구축하면서 오늘날의 모질라 재단의 지속가능한 발전을 할 수 있는 근거를 마련하였다. 이처럼 오픈소스 정신과 철학으로 거대 기업의 압력에 굴복하지 않았던 이들의 적극적인 투쟁이 오늘날의 모질라를 있게 하였다.

4.2 MPL License History

모질라 프로젝트는 1998년 넷스케이프사가 자사의 웹브라우저 소프트웨어에 대한 소스코드를 오픈소스로 배포되면서 시작되었다. 그 즈음에 오픈소스 라이선스 들로는 BSD계열의 라이선스들과, GPL 및 LGPL 등이 널리 사용되고 있었다. 그런데, 모질라 프로젝트에서는 기존의 라이선스들이 모질라 프로젝트의 라이선스로는 적합하지 않다고 판단하고 MPL라는 별도의 라이선스를 만들었다.

그런데, MPL 라이선스는 GPL라이선스 등과 상호운용성(Compatibility) 문제가 발생하였다. 이러한 문제점을 해결하기 위해 모질라 재단은 프로젝트 코드를 "Mozilla tri-license", 즉 MPL/GPL/LGPL 라이선스에 따라서 배포하였다. 따라서 모질라 코드는 3개의 라이선스에 따라 사용할 수 있고, 이와 같이 3개의 다른 라이선스에 의해 배포하는 이유는 모질라 코드가 다른 오픈소스 라이선스들과 가능한 상호 운용될 수 있도록 하기 위함이다. 모질라 재단은 2004년 라이선스 정책을 바꾸기까지 2년동안 450명에 달하는 모든 기여자들로부터 라이선스 전환에 관한 동의를 받았다.

최근 개정된 MPL 2.0은 Creative Commons Zero, Other Public Domain Dedications, MIT, New BSD and Similar Permissive Licenses, Apache 2.0, GPL and MPL Dual License 와 상호 운용 가능하다. 그러나 CC-BY, CC-BY-*, GPL은 그렇지 않다.

한편 모질라의 다양한 부분에서 새로운 코드베이스로 Non-MPL 라이선스를 사용하고 있는데, MPL 모듈 팀에서는 이에 대한 토론이 진행되었다 .제안된 내용은 Non-MPL 라이선스의 사용을 공식적으로 허용하자는 것이였고, 새로운 코드베이스에 대한 라이선스로 Apache 2.0을 선택 할 수 있도록 허용하는 것으로 결론을 내렸다.

출처 (1) 모질라 프로젝트 - http://health20.kr/3066 (2) MPL - 문화채육관광부 오픈소스 라이선스 책자

5. EPL(Eclipse Public License) History

이클립스 프로젝트는 2001년 IBM에 의해 시작되었으며, 2004년 독립된 비영리조직인 이클립스 재단이 설립되어 이클립스 커뮤니티 Steward로서의 역할을 하고 있다. 현재 이클립스 재단의 프로젝트는 178개에 달한다. CPL과 EPL은 IBM이 이클립스 등 오픈소스 프로젝트를 진행하면서 만든 라이선스이다. 현재 IBM은 EPL만 사용하고 있다.

출처 (1) EPL - 문화채육관광부 오픈소스 라이선스 책자