오픈소스, 그리고 자바 - 오픈소스라이프사이클

출처 : http://blog.sdnkorea.com/blog/entry?page=89#recentTrackbacks

오픈소스, 그리고 자바

썬특집기사/특별기고 2007/05/28 15:17 Posted by Sun

*이 기고는 월간 마이크로소프트 6월호에 기고된 JCO 부회장 최상훈님의 글로서 오픈소스로 전환한 자바에 대한 내용 입니다.
_______________________________________________________________________________________

오픈소스, 그리고 자바

최상훈 소프트웨어 엔지니어 (vicdev@magicn.com)

CORBA ORB 및 Naming, Notification 서비스를 설계, 개발, 컨설팅했고, 엔터프라이즈 시스템, EAI, BPM 및 메시징 시스템 개발 프로젝트에 참여했다. 현재는 다날㈜에서 모바일 결제 시스템을 개발하는 해외 개발팀 팀장을 맡고 있다. objectworld.org에서 방법론, 아키텍처, 패턴 등을 스터디하고 있으며 JCO 부회장으로 활동하고 있다. 우리나라에도 아파치나 JBoss 같은 오픈소스 재단 창립되어 우리나라 개발자들도 개발을 즐길 수 있기를 꿈꾸고 있다.

 

여태껏 자바는 썬마이크로시스템즈(이하 Sun)의 전유물이라 할 정도로 자바에 대한 많은 의사결정을 Sun에서 정의했다. 그럴 수 밖에 없던 것이, 애초에 자바는 Sun에서 어떠한 하드웨어 플랫폼에서도 이식 가능한 객체지향 플랫폼을 만들기 위해 구성된 그린 프로젝트의 결과물이기 때문이다. 이때 그린 프로젝트에서 자바의 전신인 오크(Oak) 프로그래밍 언어를 제작한 제임스 고슬링은 일약 스타가 되었다. 따라서 자바의 지적 재산권은 Sun이 소유하고 있으며 자바는 당연히 Sun의 소유권 안에 있는 개발언어이다.

하지만 전자제품에 탑재되는 이식성 높은 플랫폼으로 쓰기에 너무 매력적이었던 자바는 웹의 폭발적인 인기와 함께 세상의 주목을 받기 시작했다. 웹브라우저에 add-in되어 실행되는 애플릿의 강력한 기능이 개발자들의 관심을 샀기 때문이다. 이렇게 세상의 주목을 받기 시작했던 자바는 IT 역사와 함께 진화하여 현재 자바의 지위와 사랑을 받게 되었다. ? 12년 동안의 자바의 역사를 생각하면 참으로 많은 일들이 있었던 것 같다. 자바를 둘러싼 MS와의 전쟁, SE/EE/ME 로의 다각화(Java2), 각종 패러다임을 주도하기도, 적응하기도 했던 자바는 12년 IT 역사와 함께 했다고 해도 과장되지 않을 것이다.

자바는 이제 Sun의 전유물이라 할 수 없을 정도로 많은 개발자들과 업체, 커뮤니티에 의해 사용되고 있다. 지난 몇 년 동안 IBM을 비롯한 Apache Software Foundation (ASF), 그리고 많은 개발자 커뮤니티로부터 자바를 오픈 소스화 하라는 압박에 가까운 요구를 받던 Sun이 드디어 자바를 SE 6 버전을 기점으로 오픈 소스 프로젝트로 전환 하였다. Sun측에서 자바를 오픈 소스로 전향할 언질을 일찍부터 흘려왔음에도 불구하고 여태까지 지연됐던 이유는 Sun이 자바를 오픈 소스로 전환할 권리가 있는지 확인하는 법률적인 검토 때문이었다고 한다. (Sun의 오픈 소스 책임자 사이몬 핍스)

오픈 소스 자바의 분수령이 된 사건은 2005년에 열린 JavaOne 컨퍼런스에서 발표한 자바 애플리케이션 서버 플랫폼 에디션 9을 발표하면서였다. Sun은 자바 EE의 글래스피쉬(GlassFish) 코드 공유 프로젝트를 발표하면서 자바 EE의 오픈소스 프로젝트 진행을 주도했다. 더 나아가서 자바 플랫폼 전체를 점차적으로 오픈 소싱 하겠다고 약속했으며, 2007년 전반기까지 오픈 소스 라이선스 하에 JDK 전체를 공개하겠다고 선언했다. (오픈 소스 자바 심층 탐구) 이전에도 Sun은 NetBeans나 OpenOffice, Project Looking Glass (3D UI 플랫폼) 프로젝트 같이 사회에 헌정한 오픈소스 제품들이 있었다. 하지만 자바의 오픈소스 소식이 이들보다 충격적이었던 이유는 자바 킬러 어플리케이션이 아닌 자바 자체를 오픈 하겠다고 천명했기 때문이다. (예전에도 Sun은 솔라리스 10을 오픈 솔라리스로 발표하여 세상을 깜짝 놀라게 한 적이 있었다. 이때 솔라리스 코드가 공개했으며, 솔라리스에 관련한 1,670개의 특허를 세상에 기부하였다. http://www.opensolaris.org)

사실 자바의 소스는 원래 사전적으로 ‘오픈’ 되어 있었다. JDK를 설치하면 JAVA_HOME 디렉토리에 자바 소스 코드가 저장된 src.zip 파일이 같이 배포되기 때문이다. (소스코드 용량이 크지 않았던 옛날 버전은 압축되지 않은 채 src 디렉토리에 설치됐다.) 하지만 누구도 자바를 오픈 소스라고 말하지 않는다. 왜냐하면 자바 소스를 볼 수만 있을 뿐이지 그 소스를 변경, 개선, 재배포, 수정, 확장할 수 없기 때문이다. (마치 읽기 권한만 제공하는 DB처럼 말이다.) 게다가 소스가 공개된 것은 자바 라이브러리 뿐이지, 자바 핫스팟 가상머신, javac 컴파일러 및 네이티브 코드 등은 아예 볼 수도 없었다. 따라서 필자에게 제일 반가웠던 자바의 오픈 소스화 소식은 이제까지 봉인됐던 자바의 깊은 곳을 볼 수 있다는 점이었다. 더불어 같이 오픈된 기능은 JavaHelp 2.0 (JSR 97)의 구현이다. (참고로 JavaHelp는 마이크로소프트사의 CHM(Compiled HTML Help)와 유사한 도움말 소프트웨어이다.)

이렇게 자바 오픈 소스화의 배경은 개발을 소싱하여 경쟁 촉발, 가격 하락 및 기술혁신 가속화를 유도하기 위해서이며 (오픈 소스 이니셔티브 > FAQ), 무엇보다도 커뮤니티의 협력(예: 버그와 보안 관련 수정 작업)을 더 많이 얻을 수 있다는데 있다. (고슬링이 밝힌 썬의 오픈소스 채택배경) 즉, 오픈 소싱으로 자바를 개발하면 많은 고급 개발자를 참여시켜 개발의 가속도와 소프트웨어의 품질을 높이려는 목적에서 비롯된다. 이제 Sun은 자바 개발을 주도하는 기득권을 포기함과 함께 자바 개발을 주도해야 하는 부담에서 해방된다. 여기서 Sun은 오픈 소스에 관심이 있고, 참여 의향이 있는 커뮤니티와 순환적인 컨소시엄을 기획하고 있다. 그 모델은 [그림 1]과 같다. 이 모델은 소프트웨어 (특히, 오픈 소스) 진화의 사이클을 보여주고 있으며, 특히 커뮤니티의 역할이 강조되고 있다. (Free and Open Source Licensing White Paper, 2006.12)

[그림 1 오픈소스 라이프 사이클]

여기에 더해서, (필자의 사견으로는) 자바 오픈 소스화의 배경 중 하나로 오픈 소스 그룹들의 선전이 한 몫을 했다고 생각한다. 그 동안 새로 제안됐던 자바 스펙은 Sun에서 자바의 스펙을 주도했던 것이 아니라 이미 존재했던 오픈 소스 프로젝트들에 이끌렸던 경향이 있었다. JDOM이 JDK에 편입되고, Struts에서 JSF로, Log4j에서 Java Logger로 오픈 소스 라이브러리가 자바 라이브러리의 전신이 된 사례가 많다. 또한 Hibernate가 EJB 3.0안에 편입되었고, Spring의 POJO 개념을 EJB 3.0에서 채용하는 등 자바의 많은 스펙은 이미 성공한 오픈 소스 프로젝트들의 기술, 개념들을 흡수하기도 했다. 이런 현상의 본질은 Sun이 독자적으로 자바의 기능을 주도하기엔 너무 자바가 커져버렸다고 할 수 있다. 대세가 이렇게 흐르고 있는 상황에서 Sun이 오픈 소스를 결정하게 된 변수 중에 하나로 오픈 소스 프로젝트들의 성공이 큰 변수가 됐을 것이다.

오픈 소스를 채택하는데 없어서는 안될 선행 작업이 적합한 라이선스의 선택이다. 왜냐하면 오픈 소스는 타인에게 소스의 변경을 허락하는 만큼 소스가 생존하고 진화, 사용하기 위한 보호를 최대한 강화해야 하기 때문이다. 그러기 위해 오픈 소스 개발자들은 저작된 소스에 대해 법적인 라이선스(사용허가권, 면허, 허락)를 부여한다. 오픈 소스 자바가 선택한 라이선스는 ‘GNU GPL(General Public License) v2 + 클래스패스 예외(classpath exception)’이다. GNU 라이선스로 유명한 GPL 라이선스는 오픈 소스 라이선스 중 오픈 소스를 강요(?)하는 라이선스로 유명하다. 왜냐하면 소프트웨어를 수정하거나 새로운 소프트웨어를 링크시키는 경우 GPL에 의해 소스 코드 공개해야 하기 때문이다. 이때 JDK에 GPL을 적용하면 문제가 발생한다. GPL인 JDK는 모든 자바 어플리케이션이 필연적으로 참조하게 되기 때문에 JDK를 참조(클래스패스에 설정)하는 모든 자바 어플리케이션들은 오픈소스로 공개되어야 하는 문제가 발생한다. 그래서 ‘클래스패스 예외’라는 단서가 필요하다. 따라서 Sun은 ‘클래스패스 예외’라는 조건을 건 GPL v2를 채택함으로써 이러한 제약에서 자유롭게 된다. ‘클래스패스 예외’는 JDK를 클래스패스로 링크했다 하더라도 GPL 라이선스 통제로부터 해당 어플리케이션을 예외 시킨다는 선언이다.

※ 오픈소스 라이선스에 대한 자세한 설명은 하단에 기재.

원래 자바는 SCSL (Sun Community Source License) 를 적용했다. 이 라이선스는 자바를 이용하거나 소스를 볼 수 있지만 자바의 지식과 기술을 사용하지 못 하는 제약이 있다.  Sun이 이런 라이선스를 채택한 이유는 자바의 연구를 법적으로 허용하고, 고취시키기 위함이다. 2003년에는 학생들에게 자바 연구를 더욱 촉진시키기 위해 SCSL을 비상업적인 용도로 완화한 JRL (Java Research License) 라이선스를 적용했다. 그리고, 현재에 이르러 누구도 자바를 볼 수 있고 수정, 변경, 재배포할 수 있는 ‘GPL v2 + 클래스패스 예외’로 발전하게 된다. 이런 과정을 통해 봤을 때 Sun이 점차적으로 시대의 흐름에 따라 라이선스를 통해 자바의 법적 제한을 완화했음을 볼 수 있다. 이 말은 Sun이 단계적으로 자바에 대한 권리를 개발자들에게 양도했다고 해석해도 되겠다.

이제 누구나 자바 소스코드를 변경할 권리가 생겼다. 마치 이 선언은 판도라의 상자를 연 상황처럼 여러 변종의 자바가 등장하고 급기야 WORA가 깨질 것으로 우려되기도 하지만 Sun의 오픈 소스 책임자 사이몬 핍스는 다음과 같이 말한다.

"리눅스 커널을 생각해 보라. 리눅스 커널에 도움을 줄 수 있는 사람은 거의 없지만, 그렇다고 그것을 오픈 소스로 만드는 것이 중요하지 않다는 의미는 아니다. 그것은 단순히 리눅스 커널 커미터가 되려는 소명 의식을 가진 사람이 많지 않다는 의미일 뿐이다. … 얼마나 많은 사람들이 오픈 소스 자바 SE 커뮤니티를 구성할 것인지는 모르지만, 몇 백 명 이상이 될 가능성은 없다." (썬, 프로그래머들이여! 오픈 소스 자바를 염려하지 말라)

이 말인즉슨 ‘누구나’ 자바를 변경할 수 있지만, ‘아무나’ 자바를 변경하지 못 할 것이라는 의미이다. 그럼에도 불구하고 확률이 줄었을 뿐이지 자바의 호환성과 상호운용성을 위협하는 문제에서 여전히 자유로울 수 없다. 이런 리스크에 대한 안전장치를 만들기 위해 Sun은 스펙 라이선스를 여전히 소유하고 있으며 자바 인증을 위해 TCK (Technology Compatibility Kit) 검사를 강요하고 있다. 바로 이 부분이 오픈 소스 개발자들로부터 Sun이 완전히 자바의 소유권을 포기하지 않았다고 비판을 받는 이유가 된다. 하지만 이런 제한의 기저에는 나름대로 보편, 타당한 이유가 있다.

사실 이 문제는 호환성과 개방성의 문제이다. 민주주의 사회에서 자유와 평등이 서로를 견제하며 균형을 이루듯이 호환성과 개방성은 상호 배타적이면서 공생하는 모순된 관계를 갖는다. 호환성이 극대화되면 중앙집권적으로 자바의 스펙과 구현이 통제 되고 상대적으로 개방성은 극소화된다. 반면, 개방성이 극대화되면 서로 호환되지 않는 자바의 변종(fork)들이 등장하여 혼돈의 자바 세계가 될 것이다. 따라서 이 두 기능(호환성과 개방성)의 동작은 서로 경쟁하며 균형을 갖추므로 발전한다. 자바가 오픈 소스화되면서 개방성이 극대화되었다. Sun은 개방된 자바의 호환성을 지키기 위해 스펙 정의와 자바 인증을 통제했다. 따라서 자바를 개발하려면 JCP에 의해 관리되는 플랫폼 API 및 스펙(JSR)의 정의를 따라야 한다. 즉, 자바의 스펙 및 API 정의 권한은 여전히 Sun에게 있다는 것이다. 이것이 스펙 제한의 취지이다.

또한 TCK는 오픈 소스로 개발된 자바가 오픈 소스 스펙에 충실하게 개발 되었는지 여부를 증명하는 호환성 요구사항을 검증해준다. 따라서 TCK 인증에 승인되어야 자바라는 공적 인증을 받을 수 있고, 이 플랫폼은 ‘자바’라고 부를 수 있는 것이다. 그렇다면 TCK의 소유권을 왜 Sun만이 소유해야 했을까? 이유는 ‘자바의 호환성’을 보장하는 ‘TCK의 호환성’을 보장해야 하기 때문이다. 자바의 호환성 문제와 마찬가지로 TCK를 아무나 정의한다면 (TCK 호환성이 보장되지 않는다면) TCK가 검증하는 자바의 호환성도 결국 보장 받을 수 없기 때문이다. 이것은 마치 태권도 승단심사를 국기원만 심사하는 이유와 같다. 제 2, 제 3의 국기원이 생긴다는 것은 제 2, 제 3의 여러 변종의 태권도가 생기는 것과 같기 때문이다.

그래서 강조되는 개념이 ‘개방형 표준 (open standard)’이다. 진부한 단어 같지만 상술한 내용을 가장 일목요연하게 표현한 문구이며, Sun이 애용하는 표어이기도 하다.

GlassFish 커뮤니티와 유사하게 Sun은 자바 SE 오픈 소스 구현을 지속적으로 개발하기 위해 OpenJDK 커뮤니티를 설립하였다. 이 커뮤니티는 Sun에서 제공하는 오픈 소스 자바 개발 커뮤니티이다. (http://community.java.net/openjdk/) 이 사이트에서 각각의(SE 6, SE 7) 자바 버전의 소스를 곧바로 다운로드 받을 수 있으며 전체적인 자바 오픈 소스 프로젝트에 대한 소개가 나와 있다. 실제로 자바 개발에 참여하기 위해서는 https://openjdk.dev.java.net/ 를 방문하여 기여자 프로세스를 따라 등록하고 활동하면 된다.

이제 자바는 오픈 소스화를 통해 새로운 시국을 접하게 된다. 다양한 구현 커뮤니티가 생겨날 것이며, 이 커뮤니티들이 서로 경쟁하면서 기술 혁신의 가속화와 품질 향상, 가격 하락 등의 순기능을 기대할 수 있다. 이러한 변화들이 자바를 더욱 재미있게 해줬으면 하는 바램이다.

• 그 밖에 오픈 소스에 대한 단상

지난 2월에 있었던 한국자바개발자협의회(JCO) 컨퍼런스의 오픈 소스 관련 토론 트랙을 준비하면서 필자의 머리를 맴돌았던 화두는 ‘우리는 왜 오픈 소스에 열광했을까?’였다. 한동안 우리는 오픈 소스 신드롬에 빠져있던 것 같다. 우리가 오픈 소스를 바라보는 시각은 여러 가지가 있겠지만 우리는 주로 오픈 소스의 소비자로 오픈 소스를 바라본다. 한편으론 오픈 소스를 해보고 싶은 막연한 바램도 있었을 테지만 말이다. 필자는 이점이 못 마땅했다. 결국 우리가 그토록 관심을 가졌던 오픈 소스는 단지 소비자가 소비재로서 인기 있었던 특정 제품이 오픈 소스이기 때문이지 오픈 소스 자체에 관심을 두지 않았기 때문이다. 이 기사를 빌려 다시금 같이 생각해보고 싶은 문제이다.

오픈 소스를 논할 때 빠지지 않고 등장하는 주제가 오픈 소스의 경제학이다. 생산과 소비 활동으로 동작하는 자본주의 사회에서 오픈 소스를 홍보하기 위해 필연적으로 제시해야 하는 것이 경제적 이익이기 때문에 많은 홍보문서에서 오픈 소스의 경제성을 빼놓지 않는다. 하지만, 이렇게 오픈 소스를 홍보하는 많은 사람들은 오픈 소스의 경제성을 강조하고 설명하는데 개발자라는 집단에게 있어 오픈 소스는 경제성을 초월한 존재론적 가치가 있는 것이 아닐까?

그럼에도 불구하고 오픈 소스 프로젝트들은 경제적 성공을 거둔 멋진 사례들이 많다. 필자가 처음 관심을 갖게 된 ACE-TAO의 경우가 그랬다. 더글라스 슈미츠 교수의 연구실에서 개발한 ACE-TAO는 현재 Microsoft, IBM, Boeing, Nokia, Kodak을 비롯한 46개의 회사에서 스폰싱을 하고 있다. 이유는 후원사에서 필요한 연구 및 개발을 대리해 주기 때문이다. ACE-TAO 뿐만 아니라 다른 오픈 소스 CORBA 프로젝트들은 이런 경제적 후원 하에 연구 개발을 진행하고 있다. 이런 모델은 다소 국소적인 현상일 수 있겠지만, IBM이 4천만 달러를 투자한 eclipse 후원은 상당히 충격적인 비즈니스 모델을 제시했다.

소프트웨어가 복잡하고 거대해짐에 따라 통합 IDE의 니즈는 늘어만 간다. IDE를 통해 개발할 뿐만 아니라 모델링, 형상관리, 배포, 테스팅, DB 접속, XML 작성, 다른 언어 개발 지원에 이르기까지 개발을 위해 필요한 모든 어플리케이션이 하나의 툴에 통합되기를 많은 개발자들이 바래왔었다. 이런 요구사항들을 충족해준 오픈 소스 IDE인 eclipse는 폭발적으로 자바 유저층을 확보했고, 거의 IDE 시장을 독점하다시피 했다. 시장 독점, 기업 이미지 쇄신, IBM의 eclipse 기반 솔루션 소비 등 4천만 달러 이상의 효과를 얻을 수 있었다. 이에 맞춰 Sun은 NetBeans 프로젝트를 더욱 지원하기 시작했으며, 오라클은 JDeveloper를 무료로 제공하고 있다. 이런 현상은 실로 통합 IDE 전쟁의 시대라 표현할 만 하며, 이 전쟁에서 승전의 열쇠는 오픈 소스 프로젝트를 통해 사용자를 확보하고, 확보된 시장에서 2차적 경제 효과를 얻는데 있다.

흔히 외국 문서를 보다 보면 오픈 소스를 오픈 자유 소프트웨어로 표현하는 문서가 많다. 사실 오픈 소스와 자유 소프트웨어는 철학의 차이로 구분된 개념인데, 일반적인 시각에서는 대동소이하게 받아들여 오픈 소스와 자유 소프트웨어를 뭉뚱그려 오픈 자유 소스라고 표현하기도 한다. 이 두 개념은 소스코드를 읽을 수 있는 권리를 제공하는 측면에서 유사성을 가지고 있지만, 자유 소프트웨어 진영에서는 오픈 소스 운동보다 더욱 급진적인 견해를 가지고 있어서 차별화를 시도하고 있다. 여기에 대한 정의는 리차드 스톨만의 ‘왜 자유 소프트웨어가 오픈 소스보다 좋은가?’ (http://www.gnu.org/philosophy/free-soft ··· .ko.html)란 글에서 아주 명확하게 설명되고 있다. 흔히 우리는 ‘자유 소프트웨어 = 공짜 소프트웨어 (프리 웨어)’라고 생각하는데, 공짜 소프트웨어는 자유 소프트웨어의 특징 중 하나일 뿐이지 자유 소프트웨어를 대변할 수 있는 특징이 아니다.

자유 소프트웨어의 목적은 ‘소비자에게 자유를 선사할 수 있는’ 소프트웨어를 제공하는 데 있다. 필자는 자유 소프트웨어를 설명할 때 워싱턴에 있는 한국전쟁 희생장병 국립묘지에 적혀있는 ‘freedom is not free (자유는 공짜가 아니다.)’라는 문장을 즐겨 인용한다. 자유 소프트웨어에서의 ‘자유’는 주어 위치의 ‘자유’ 이지, 형용사 위치의 ‘공짜’가 아니기 때문이다. 이 문장을 애용하는 다른 이유는 이 문장에서 의도하는 내용과 자유 소프트웨어 운동에서의 그것과 관념적으로 유사하기 때문이다.

필자는 한국에서 오픈 소스 작업을 한다는 것에 특별한 의미부여를 하고 있다. 우리 나라처럼 시스템 소프트웨어보다 이를 이용하는 비즈니스 어플리케이션에 집중적인 기술적 인프라에서 오픈 소스 운동은 우리나라 IT 기술의 스팩트럼을 넓혀줄 도구가 될 수 있다고 생각한다. 가령 우리가 직장에서 작업하는 업무에는 DB를 만들 기회가 없지만 오픈 소스 개발에 참여하면 얼마든지 훌륭한 동료들과 DB를 개발해 볼 수 있는 기회가 생기기 때문이다. 이런 ‘기회’들이 모인다면 우리나라 IT 기술의 잠재적인 성숙이 이루어지리라 생각한다.


※ 오픈 소스 라이선스

필자가 오픈소스에 관심을 갖기 시작한 이래로 필자를 가장 힘들게 했던 부분이 라이선스에 대한 내용이었다. 왜냐하면 라이선스는 법적인 영역이기 때문에 개발자에게 읽기 쉽게 설명했음에도 불구하고 낯선 단어들과 복잡한 규정들이 등장하기 때문이다. 이런 오픈 소스 라이선스들은 OSI(Open Source Initiative)에서 심사, 승인하고 있다. ? 참고로 OSI에서는 오픈 소스를 다음과 같이 정의하고 있다. "오픈 소스는 독립적인 피어 리뷰와 재빠른 소스 코드 진화를 지원하여 소프트웨어의 신뢰성과 품질을 촉진하고 있다. OSI의 인증을 받기 위해서는, 소프트웨어가 무료로 읽혀지고, 재배포, 변경, 수정될 수 있음을 보장하는 라이선스를 통해 배포되어야 한다." 또한, 오픈 소스로 규정할 수 있는 10 가지 조건(OSD, The Open Source Definition)들을 발표하였다. (1998년, 참고 자료 : http://softwant.com/cgi-bin/kimsboard/bbs.php3?table=opensource&query=view&l=35) ?

OSI에서 승인한 오픈소스 라이선스들은 현재 총 58개가 있으며, 대표적으로 다음과 같은 소스라이선스 들이 있다. (표준 기반의 / Open Source GIS 구축 지침 개발에 관한 연구, 한국정보사회진흥원)

• <!--[if !supportLists]-->?GPL : GNU General Public 라이선스 2.0

소프트웨어에 대한 자유로운 사용, 복제, 배포 및 수정을 허용하며, 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실 명시해야 한다. 소프트웨어를 수정하거나 새로운 소프트웨어를 링크시키는 경우 GPL에 의해 소스 코드 공개해야 하며, 특이한 사항은 리눅스를 기반으로 개발된 어플리케이션은 소스 공개할 필요가 없다.

• <!--[if !supportLists]-->? <!--[endif]-->LGPL : GNU Lesser General Public 라이선스 2.1

GPL 라이선스가 제한이 엄격해서 오픈소스 소프트웨어의 사용을 장려하기 위한 전략적인 차원에서 다소 완화된 라이선스를 정의하였다. GPL과 대동소이하나 LGPL을 따르는 라이브러리를 링크시킬 경우 해당 응용프로그램의 소스를 공개할 필요가 없다는 점이 큰 차이이다.

• <!--[if !supportLists]--> <!--[endif]-->BSD(Berkeley Software Distribution) 라이선스

GPL, LGPL보다 덜 제한적이기 때문에 허용범위가 넓다. ‘저작권 표시’, ‘무보증의 표시’만 한다면 BSD 라이선스를 따르는 프로그램의 소스 코드를 구해 수정한 후 소스를 공개하지 않고 BSD가 아닌 다른 라이선스를 적용하여 판매할 수 있다.

• MPL(Mozilla Public License) 라이선스

네스케이프 브라우저의 오픈소스 버전인 Mozilla가 채용한 라이선스다. MPL의 경우 MPL 하에 배포된 코드를 포함하는 파일이나, MPL 하에 배포된 파일 자체를 수정한 경우에만 소스코드 배포를 요구한다.

가장 많은 오픈 소스를 퍼블리싱하고 있는 sourceforge.net에 등록되어 있는 약 87,000개의 라이선스별 현황은 [그림 2]와 같다. 이 통계에서 약 77%에 해당하는 프로젝트가 GPL/LGPL을 사용하고 있으며, 그 뒤를 BSD가 차지하고 있다. 따라서 GPL>LGPL>BSD 순서로 라이선스가 사용되고 있다.

[그림 2 sourceforge.net에 등록된 라이선스 별 분포]