An ActiveX control is an object that supports a customizable programmatic interface. Using the methods, events and properties exposed by the control, web developers can automate their web pages to give the functionality which is equivalent to that of a desktop application.
Introduction
As web application developers, we want to give our users a highly functional application. We want to provide our users with functionality like printing streams, local socket programming ,local threading, cross domain scripting etc., but as we know that due to the disconnected architecture of the Internet and security restrictions of any standard browser, this task becomes difficult. That’s when the ActiveX comes to the rescue. This is mostly for web applications where the users would not be apprehensive about doing a one time installation of the component. Also, in an intranet application these components can be a big boost to the functionality of the application.
Writing ActiveX Class in C#
We will first write an interface called ASignatures which holds the signatures of the methods and properties. These methods and properties can then be accessed via JavaScript at the browser level. By default all members of an interface are abstract and public. The main ActiveX class AClass will inherit from this interface. Above the main ActiveX class we will mention the ClassInterfaceType as AutoDual. This will indicate the type of the interface generated for the main class which will automatically be generated and exposed to the COM. Normally AutoDual is not recommended because it has some versioning limitations. We will use the ClassIntrefaceType as AutoDual because the purpose of this code is instructional. In the main class we will write two methods FName(), and SName() and one property Age. In our example we will return the basic datatypes but this can be implemented for complex datatypes too.
using System;using System.Runtime.InteropServices;namespace ANamespace { publicinterface ASignatures { string FName(); string SName(); int Age { get;} } [ClassInterface(ClassInterfaceType.AutoDual)] publicclass AClass :ASignatures { publicstring FName() { return"Imran"; } publicstring SName() { return"Nathani"; } publicint Age { get { return 24; } } }}
Compiling the ActiveX control
For those who do not know how to compile out of Visual Studio IDE, you need to search for the c# compilercsc.exe in the folder:
\WINDOWS\Microsoft.NET\Framework\v2.0.xxxxx
Place your AClass.cs file in the folder where the csc.exe exists. Then by command (DOS) interface go to that particular folder and execute the following command:
csc /t:library AClass.cs
Registering the Assembly with the client
You can register the assembly in multiple ways of implementation and it mostly depends on the target users. For example, creating a setup file for download or having a self extractor file which could prompt in the browser, depends totally on the functionality requirement. However for our example we would register the assembly by using the command prompt which is the easiest and could be done by a batch file too. Therefore, in same folder as above immediately after the compilation step we execute the following command:
regasm AClass.dll /tlb /codebase
Also we must note that the .NET Framework needs to be installed on the client for registration and working.
Using the ActiveX control
We can then access our newly created ActiveX control via JavaScript. We will simply display the data returned by the methods and property in alert boxes. The below code demonstrates how we can access the properties in the ActiveX control.
<html><head><scriptlanguage="javascript"> <!-- Load the ActiveX object --> var x = new ActiveXObject("ANamespace.AClass"); <!-- Access the Method --> alert(x.FName()); alert(x.SName()); <!-- Access the Property --> alert(x.Age); </script></head><body></body></html>
This will work like a charm in Internet Explorer but may need an API plugin for other browsers like FireFox or Safari.
Summary
In this article you have seen how we can increase the functionality of our web application by implementation of ActiveX controls in C#. The practical applications of ActiveX are limitless especially for graphics and multimedia.
Although ClickOnce deployment works well for most applications, there are some situations where Windows Installer is more appropriate.The following are some limitations that you should be aware of:
우분투 넷북 리믹스는 넷북이라고 불리는 소형 인터넷 기기를 위한 우분투 'respun' 버전입니다. 하지만 쿠분투나 주분투, 에듀분투처럼 우분투의 다른 배포판은 아니고, 작은 화면과 낮은 성능을 가진 모바일 기기에서 우분투를 효율적으로 사용할 수 있도록 해주는 패키지 모음입니다. 이는 우분투를 개발, 배포하고 있는 캐노니컬에서 인텔과 합작으로 진행하고 있는 Moblin project 의 결과물이기도 합니다.
주문한지 3년만에 델 미니 9 이 도착했습니다!!! 무식한(?) 택배 아저씨, 사람없다고 물건 던져두고 그냥 가신.. 성질나서 델코리아로 또 전화하려다가 같이온 이상한 물품을 보고 참았습니다.
주문한지 한 달이 다 되어가는 시점이고, 몇 번이나 배송지연이 되었던 관계로 델 고객 상담부서쪽 분들과 계속 논쟁을 했었는데, 그 덕분인지, "이거 먹고 떨어져라." 인지.. 그닥 쓸모없는 걸 보내주셨군요. 하지만 베이징에 갈때 써먹을 수 있을 것 같아 그냥 이거 먹고 떨어지기로 했습니다. -_-;;;
그나저나 배터리는 언제나 오려나... 400불짜리 놋북사면서 150불치 뜯어낸 ;ㅁ; 이러고 살고 싶지 않았는데 ;;;
여튼.. 그리하여 천신만고(?) 끝에 도착한 델 미니 9!!! 첫인상..
부팅 열라 느려~
XP 를 처음 세팅하는 과정때문에 그렇겠지만, 일단 기본 인상은 그것으로 낙찰.. 이제 밀고 우분투 깔아야지 =3=33
빠르군요. 역시 SSD 인가.. XP 에서 잠시 테스트 삼아 이런저런 작업(?)을 해봤는데, 전혀 부담스러움을 느끼지 않았을 정도니까.. 설치까지 10분이 안 걸린듯.. 근데 역시나 SSD 용량이.. XP 때엔 3.5GB 를 잡아먹고 있었는데, 우분투는 2.2GB 밖에 안 먹는군요. 1.3GB 아꼈습니다. ㅎㅎ
근데 놋북을 써본 적이 없어서 그런가.. 터치패드 감도가 지나치게 민감하다는 생각이 들었습니다. 계속 설정이 틀려서 결국 USB 마우스를 꼽고 설정을 해야만 했습니다. 움.. 어렵다..
델 미니 9 에는 Ubuntu mini - Netbook Remix 패키지를 설치했습니다. Netbook remix 는 넷북 전용 우분투 배포판!!! 은 아니고, 그냥 넷북에 최적화(?)시켜주는 패키지 모음입니다. Launchpad 의 PPA 를 통해 제공됩니다.
deb http://ppa.launchpad.net/netbook-remix-team/ubuntu hardy main deb-src http://ppa.launchpad.net/netbook-remix-team/ubuntu hardy main
sudo apt-get install go-home-applet human-netbook-theme maximus ume-launcher window-picker-applet
try { Console.WriteLine("데이터베이스 연결중..."); connection.Open(); Console.WriteLine("데이터베이스 연결 성공");
Console.WriteLine("현재 데이터베이스 : " + connection.Database); Console.WriteLine("현재 연결 상태 : " + connection.State); Console.WriteLine("데이터베이스 버전 : " + connection.ServerVersion); } catch (Exception E) { Console.WriteLine("데이터베이스 연결 실패"); Console.WriteLine(E.Message); Console.WriteLine(E.StackTrace); } Console.WriteLine("데이터베이스에 연결 종료중..."); connection.Close(); Console.WriteLine("데이터베이스에 연결 종료 성공"); } } }
참고하세요. 추가로 컨넥트 스트링 부분에 string connectionString = "server=localhost;database=디비명;uid=아이디;pwd=패스워드;Charset=utf8"; 이 처럼 Charset=utf8(latin1 등) 부분의 옵션을 사용하여 멀티랭귀지 캐릭터 셋을 설정 할 수 있음. 현재 euckr은 1.0.7 버전은 지원하지 않으며 소스를 다운받은후 소스수정후 재컴파일 하여 사용할수 있음 (소스를 보면 euckr,949 부분은 주석처리 되어 있음.ㅡㅡ;)
OpenSource 소프트웨어는 일반적으로 자유롭게 사용, 복제, 배포, 수정할 수 있으며, 소스코드가 공개되어있는 소프트웨어를 말한다. OpenSource 의 예로는 Linux 커널 및 관련 GNU 소프트웨어, 아파치 웹서버, FireFox 웹브라우저, MySQL 데이터베이스시스템, Python/PHP/Perl 언어, Eclipse 툴 등을 들 수 있으며, 그 외에도 전세계의 수많은 개발 자들이 개발하고 있는 프로그램들이 있다.
통상 OpenSource 소프트웨어는 자유소프트웨어(FreeSoftware)를 포함한 넓은 의미로 사용되며, 국내에서도 자유소프트웨어를 포함한 OpenSource 소프트웨어를 ‘공개소프트웨어'로 번역하여 사용하고 있다. 하지만 역사 및 추구하는 이념 등에서 자유소프트웨어와 OpenSource 소프트웨어는 미묘한 차이가 있다.
자유소프트웨어(FreeSoftware)는 리차드 스톨만(RichardStallman)과 FSF(Free Software Foundation)에 의해 만들어진 개념으로서, 소프트웨어의 이용자에게 해당 소프트웨어를 실행, 복제, 배포할 수 있는 자유, 그리고 소스코드에 대한 접근을 통해서 이를 학습, 수정, 개선시킬 수 있는 자유를 부여하는 소프트웨어이다. 1980년대에 들어 PC가 널리 보급되기 시작하면서 이전에는 하드웨어의 부속물로만 간주되던 소프트웨어가 거대한 부가가치산업으로 발전하기 시작하였고, 이러한 흐름과 함께 지적재산권 및 라이센스계약을 통하여 소프트웨어의 사용, 복제, 배포, 수정에 일정한 제한을 가하려는 움직임이 나타나게 된다. 소프트웨어를 둘러싼 이러한 일련의 흐름에 반대하고 소프트웨어의 자유로운 사용, 공유, 수정에 대한 기존의 권리를 지키기 위하여 리차드 스톨만은 FSF를 설립하고 자유소프트웨어(FreeSoftware) 운동을 전개하였다.
한편 1990년대 들어서면서 인터넷과 더불어 GPL(General Public License)로 배포된 리눅스가 널리 보급되기 시작하였고, MS의 익스플로러에 밀려 어려움을 겪고 있던 Netscape사가 웹브라우저의 소스코드를 공개하는 결정을 내렸으며, IBM, Sun 등이 자유소프트웨어에 대한 지원을 시작하였다. 그러나 자유소프트웨어의 '자유Free'라는 단어가 한편으로 '무료'라는 의미를 가진다는 점, 엄격한 GPL조항 때문에 상용 기업들이 참여를 꺼려한다는 점 등을 이유로 OpenSource 라는 용어가 제안되었고, 1998년 Open Source Initiative가 활동하기 시작하면서 OpenSource 소프트웨어가 널리 사용되게 되었다. OSI는 OpenSource 소프트웨어로 인정받을 수 있는 10가지 '라이센스 조건'을 정의하고, 각각의 소프트웨어에 대한 라이센스를 분석하여 OpenSource 소프트웨어라이센스에 해당하는지 여부에 대한 인증을 하고 있다. 주요 내용을 살펴보면, 소프트웨어에 대한 배포 및 수정의 자유를 인정해야 하며 소스 코드를 제공할 수 있어야 할 것, 그리고 어떤 사람이나 그룹 또는 이용분야에 대한 차별이 없어야 한다는 조건 등을 두고 있다.
위 문단은 마치 오픈소스가 GPL에 반대해서 시작된 것이고, GPLed software가 곧 Free Software인 것처럼 오해할 소지가 있습니다. OSI나 FSF쪽의 어느 누구도 그렇게 말한 사실이 없습니다. Open Source Definition은 몇년전부터 수많은 사람들이 free software 조건으로 말하던 Debian Free Software Guildelines를 데비안에 관련된 부분을 중립적으로 고친 것에 불과합니다. FSF 조차도 GPL이 아니더라도 광범위한 소프트웨어를 free software라고 말하고 있습니다. -- cwryu 2007-07-17 10:51:05
2007년 6월 기준으로, 58개의 라이센스가 오픈 소스 라이센스로 인정되어 등록되어 있다. 하지만 실제로 많이 사용되는 라이센스의 갯수는 한정되어 있다. 오픈 소스 프로젝트 개발 포털사이트인 http://freshmeat.net 에 등록되어 있는 프로젝트들 중에서 OpenSource 로 분류되는 약 34,368개 프로젝트의 OpenSource 소프트웨어 라이선스 분포를 참고해 보면 약 82%에 해당하는 프로젝트가 GPL/LGPL을 사용하고 있으며, 그 뒤를 BSD가 차지하고 있다. 따라서 GPL/LGPL/BSD 라이센스가 주로 사용되고 있음을 알 수 있다. 그러나 Mozilla 웹브라우저, Apache 웹서버 등 일부 중요한 OpenSource 소프트웨어들은 자체적으로
Linux 커널 : 가장 대표적인 OpenSource 소프트웨어인 Linux라 하면 보통 "Linux 운영체제"를 통칭한다. 하지만 여기서는 명확한 설명을 위해 Linux 커널에 한정하기로 한다. 보통 RedHat, SusE, 그리고 한컴리눅스 등이 배포하는 Linux 운영체제에는 Linux 커널을 포함하여 많은 애플리케이션과 유틸리티로 구성되어 있다. 또한 각 애플리케이션 및 유틸리티는 서로 다른 라이센스 하에 배포되고 있다. Linux 커널은 토발즈에 의해 최초로 개발되었고, 이후 많은 사람들의 자발적 참여와 기여 덕택에 오늘날 가장 인기있는 운영체제 중 하나가 되었다. 토발즈는 현재까지도 Linux 커널 개발의 중심에 있으며 Linux 개발 커뮤니티에는 수천명의 개발자가 서로 협력하고 아이디어를 공유하며 Linux를 더 좋은 운영체제로 만들어 가고 있다.
Apache : Apache는 현재 가장 많이 이용되는 웹서버이다. 오늘날 Apache의 전신은 1995년까지 NCSA(National Center for Supercomputer Applications)에 의해 개발되었다. 이 후 핵심 개발자인 Rob McCool를 포함 많은 개발자들이 NCSA 떠나면서 NCSA 주도의 웹 서버 개발이 정체되었다. 그래서 많은 웹마스터들은 스스로 필요한 기능을 개발하고 버그를 수정해 나가야만했다. 이런 상황에서 소수의 몇몇 웹마스터들이 이메일과 정기적인 미팅을 통해 NCSA가 개발한 웹서버를 공식적으로 유지보수하기 시작하였다. 이들은 자신들을 Apache Group이라 명명하였고, 오늘날 Apache Software Foundation의 근간이 되었다. Apache Software Foundation(ASF)은 1999년에 설립되었고 지금은 Apache 개발을 주도하고 있다.
Bind : BIND(Berkeley Internet Name Daemon)는 일반 IT유저에게는 잘 알려져 있지 않지만 가장 많이 이용되는 DNS(Domain Name System)이다. 즉, BIND는 호스트명을 IP주소로 변환시켜주는 프로그램으로서 인터넷의 인프라를 구성하는 매우 중요한 요소다. BIND는 모든 Unix 시스템에서는 사실상의 표준으로 자리잡았으며, 다른 많은 다른 시스템에 포함되어 있기 때문에 사실상 인터넷 표준이라 할 수 있을 것이다. BIND는 1984년에 Paul Mockapetris에 의해 처음 개발되었고, 현재는 Paul Vixie가 주도하고 있는 ISC(Internet Software Consortium)에서 주도적으로 개발을 책임지고 있다. 참고로, ISC는 1993년에 UUNET의 지원을 받아 Rick Adams에 의해 설립되었고 지금은 SUN, HP, IBM, SGI 등 주요 소프트웨어기업의 지원을 받고 있다. BIND는 ISC에서 자체 개발한 라이센스를 적용하고 있으며, 개인적 혹은 상업적 용도 구별없이 자유롭게 이용, 복제, 수정, 및 재배포가 가능하다.
Mozilla Firefox : Mozilla는 Netscape에 의해 시작된 오픈 소스 브라우저 프로젝트이다. 이 프로젝트의 일원이었던 Dave Hyatt와 Blake Ross는 Netscape가 받고있는 상업적 후원이 오히려 Mozilla 브라우저 개발에 악영향을 미치고 있다고 믿었다. 그래서 이들은 실험적으로 Mozilla Project에서 파생한 작은 Firefox Project를 별도로 시작하여 핵심적 기능을 갖춘 브라우저 개발에 착수하였다. 그런데 2003년 4월, Mozilla Foundation은 기존 Mozilla Project보다 오히려 Firefox Project에 더 전념할 계획을 밝혔다. 이 후 Firefox Project는 몇 번 이름 변화 과정을 거쳤다. 원래 Phoenix라 명명되었지만, Phoenix Technologies사와 상표권 분쟁으로 인해 Firebird로 변경하였다. 하지만, Firebird 역시 Firebird란 무료 데이터베이스 소프트웨어 프로젝트로 부터 거센 저항을 받았다. 결국 Mozilla Firebird로 다시 이름을 고쳤지만, 지속된 반발로 인해 2004년 2월 오늘날의 이름은 Mozilla Firefox로 다시 변경하였다.
현재 소프트웨어는 다음과 같이 저작권, 특허권, 영업비밀, 상표 등의 지적재산권법에 의해 보호받고 있다.
저작권 : 어떤 프로그래머가 특정 소프트웨어를 개발하게 되면 컴퓨터프로그램저작권이 자동적으로 발생하며, 프로그래머 또는 그가 속한 회사에 부여된다. 저작권(copyright)은 시, 소설, 노래 등 저작물에 대해 부여되는 권리로서 그 표현(expression)의 결과물을 보호하는 것이다. 누구도 원 저작자나 저작권자의 허가가 없이는 해당 저작물을 복사, 개작, 재배포할 수 없다.
특허권 : 특허는 하드웨어에 구현되거나 소프트웨어에 의해 동작이 구현되는 발명(invention)을 보호한다. 특허권은 자동으로 부여되는 것이 아니고 법에 정해진 절차에 의해 출원을 하여야 하며, 심사를 통해 부여되는 권리이다. 특허 기술을 구현(implementation)하기 위해서는 반드시 특허권자의 허락을 득하여야만 한다. 특허 소유자는 소유자가 허가하지 않은 사람이 해당 특허를 활용한 제품을 만들거나, 사용하거나, 판해하는 것을 막을 수 있다. 특허는 무엇인가 유용한 것을 하도록 하는 방식(method)이므로 소프트웨어의 경우 특허받은 방식을 구현하는 소프트웨어라면 프로그래밍 언어가 다르거나 소스코드가 다르더라도 해당 특허권자의 명시적인 허가를 받아야 하며 이는 OpenSource 소프트웨어, 독점소프트웨어에 공통으로 해당된다.
영업비밀 : 영업비밀이란 공연히 알려져 있지 아니하고 독립된 경제적 가치를 지니는 것으로서 상당한 노력에 의하여 비밀로 유지되는 생산 방법, 판매 방법, 기타 영업 활동에 유용한 기술상/영업상의 정보로 정의되어 있다. 이러한 영업비밀은 "부정경쟁방지 및 영업비밀보호에 관한 법률"에 의하여 보호받고 있으며, 이와 같은 영업비밀을 부당한 수단으로 취득하거나, 비밀유지의무가 있음에도 다른 사람에게 누출하는 것은 처벌받게 된다.
상표 : 상표권이란 제품이나 서비스와 연계되어 마케팅에 활용되는 이름 등을 보호한다. 또한 상표는 시장에서 나의 제품과 타인의 제품을 구별해 주는 역할을 한다.
이상과 같은 지적재산권에 의해 권리자는 소프트웨어에 대한 배타적인 권리를 가지게 되며, 원칙적으로 권리자만이 소프트웨어를 사용, 복제, 배포, 수정할 수 있다. 하지만 다양한 필요에 의해 이들 권리자가 다른 사람에게 일정한 내용을 조건으로 하여 특정 행위를 할 수 있는 권한을 부여할 필요가 있는데, 이와 같은 권한을 보통 '라이센스(license, 사용허가권)'라고 한다. 이러한 의미에서 라이센스는 물건을 판매하는 매매와는 차이가 있으며, 소프트웨어에 대한 지적재산권은 여전히 원래의 권리자에게 남아있고 일부 사용에 대한 권리만을 부여하는 것이다. 마이크로소프트, 오라클 등 일반적인 독점(proprietary)소프트웨어 업체의 라이센스는 고객이 소프트웨어 권리자에게 대금을 지급하고 소프트웨어의 ‘사용’ 권한만을 허락하는 것이 일반적이다. 따라서 허락을 얻지 않고 소프트웨어를 복제, 배포, 수정하는 행위는 라이센스를 위반함과 동시에 불법에 해당한다.
OpenSource 소프트웨어 역시 독점소프트웨어(proprietary software)와 동일하게 저작권 등에 의한 법적 보호를 받고 있으며, 이와 같은 권리에 기반하여 이용자에게 라이센스를 부여한다. 그러나 OpenSource라이센스는 일반적인 독점소프트웨어 라이센스와는 많은 점에서 차이가 있다. 기본적으로 OpenSource라이센스는 다음과 같이 사용자의 자유로운 사용, 복제, 배포, 수정을 보장하고 있다.
라이센시는 해당 OpenSource 소프트웨어를 자유롭게 복제할 수 있으며, 일정한 조건하에 재배포할 수 있다.
라이센시는 해당 OpenSource 소프트웨어를 자유롭게 수정하여 사용할 수 있으며, 일정한 조건하에 수정된 내용을 재배포할 수 있다.
라이센시는 해당 OpenSource 소프트웨어의 소스코드를 자유롭게 획득하고 접근할 수 있다.
OpenSource라이센스는 소프트웨어의 사용, 복제, 배포, 수정의 자유를 부여함과 아울러 다른 한편으로는 소프트웨어의 사용자에게 일정한 의무를 부과하고 있다. 구체적인 내용은 OpenSource 소프트웨어와 함께 배포되는 라이센스의 내용을 통해 알 수 있다. 해당 OpenSource 소프트웨어에 대한 라이센스는 주로 소스코드 내부나 홈페이지 등에 명시되어 있다. 소스코드에서는 주로 최상위 디렉토리에 COPYING이라는 독립된 파일에 라이센스 조항을 기록하기도 하며, 각각의 소스코드 파일 상단에 명시해 두기도 한다.
OpenSource라이센스에서 요구하고 있는 준수사항을 라이센시가 이행하지 않으면 권리자로부터 저작권 위반 (또는 계약 위반)으로 소송을 제기 당할 수 있다. 만약 권리를 침해한 것으로 결론이 내려지면 소프트웨어의 배포가 더 이상 불가능할 뿐만 아니라 이미 배포한 소프트웨어에 대한 손해배상 등 막대한 책임을 부담할 수 있다. 특히 임베디드 소프트웨어의 경우 이를 내장한 제품까지 판매하지 못하거나 리콜(Recall) 해야 하는 경우도 발생할 수 있으므로 라이센스의 의무사항을 명확히 이해하여 이와 같은 상황을 사전에 예방하는 것이 필수적이다. 그러나 이러한 위험 때문에 OpenSource 소프트웨어를 전혀 사용하지 않겠다는 결론을 내릴 필요는 없다. 독점소프트웨어 라이센스에서 규정하고 있는 의무사항에 비하면 OpenSource라이센스가 요구하고 있는 내용이 결코 어려운 것이 아니므로, 오히려 이를 잘 이해하고 준수함으로써 OpenSource 소프트웨어의 장점을 적극 활용할 필요가 있다. 또한 몇몇 라이센스만이 독자 개발한 소스 코드의 공개를 요구하고 있기 때문에 이를 잘 분석한 후 사용한다면 문제 발생 소지는 거의 없을 것이다.
따라서 인터넷 상에서 자유롭게 구할 수 있는 오픈 소스를 다운로드받아 개발에 적용할 때는 반드시 라이센스의 요구 사항을 반드시 확인하여야 한다. 또한, 자체 판단이 불가능할 경우에는 외부 전문가에게 조언을 의뢰하여 개발 시작 전 해당 라이센스의 요구 사항과 오픈 소스 사용 목적을 확실히 분석하여야 한다. 이렇게 하는 것만으로도 충분히 올바르게 오픈 소스를 최대한 활용할 수 있으며, 나중에 발생할 수 있는 문제들을 사전에 차단할 수 있다.
OpenSource라이센스의 의무사항은 각각의 라이센스마다 조금씩 차이가 있지만 크게 나누어 보면 공통적으로 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이센스의 소프트웨어 조합시 조합 가능 여부 확인' 등이 있고 선택적으로는 '소스코드 공개', '특허관련 사항 준수' 등이 있다.
아래는 모든 OpenSource 소프트웨어에 공통적으로 적용되는, 항상 지켜야 할 사항들이다.
저작권 관련 문구 유지 : 앞에서 저작권이란 표현된 결과물에 대해 발생하는 권리이며 자동적으로 부여된다고 기술하였다. 소프트웨어의 소스코드에 대해서도 마찬가지이며 잘 관리되는 OpenSource 소프트웨어들의 경우 거의 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있는데 만약 이러한 개발자 정보를 임의로 수정하거나 삭제하여서는 안된다. 특히 GPL등 수정된 결과물을 다시 공개하도록 규정하고 있는 '상호주의(reciprocal)' 라이센스들의 경우 만약 소스코드 상에 개발자 정보가 수정/삭제된 채로 외부에 소스코드를 공개하였다가 그 사실이 밝혀질 경우 더 큰 문제가 발생할 수 있다. 상식적으로도 쉽게 판단 가능한 사항이므로 항상 준수하여야 한다.
제품명 중복 방지 : 사용하는 OpenSource 소프트웨어와 동일한 이름을 제품명이나 서비스 명으로 사용하여서는 아니된다. 특히 유명한 OpenSource 소프트웨어들일수록 해당 OpenSource 소프트웨어의 이름이 상표로서 등록되어 있는 경우가 많기 때문에(예: 리눅스) 더욱 조심하여야 한다. 다만 이러한 제품명/서비스명에 대한 결정이 개발자들에 의해 이루어지는 경우는 많지 않으므로 역시 상식적인 수준에서 판단하면 될 것이다.
서로 다른 라이센스의 조합 : 소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이센스가 상호 상충되는 경우가 있다. 예컨대 MPL 조건의 A코드와 GPL 조건의 B코드를 결합하여 ‘A+B’라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 ‘A+B’의 A부분을 MPL로 배포할 것을 요구하는 반면, GPL은 ‘A+B’ 전체를 GPL로 배포할 것을 요구하기 때문에, ‘A+B’프로그램을 배포하는 것은 불가능하게 된다. 이러한 문제를 가르켜 라이센스의 양립성(Compatibility) 문제라고 한다. 따라서 어떤 OpenSource 소프트웨어에 다른 OpenSource 소프트웨어를 섞을 경우 반드시 두개의 라이센스가 서로 호환되는지를 확인하여야 한다. 양립성문제는 자유/OpenSource 소프트웨어 진영에 심각한 문제점을 제기하였으며, 이를 해결하기 위한 노력도 다양하게 진행되고 있다. 예를 들어 모질라 프로젝트(Mozilla.org)에서는 프로젝트의 결과물을 MPL, GPL, LGPL의 3가지(triple) 라이센스로 배포하는 라이센스 정책을 채택하여, 라이센스의 양립성과 관련된 불확실성을 제거하고 모질라 코드를 GPL 또는 LGPL 기반의 응용프로그램에 사용할 수 있도록 하였다. Trolltech도 Qt 라이브러리에 대한 OpenSource 소프트웨어라이센스인 QPL과 GPL의 양립성 문제를 해결하기 위하여 QPL 및 상용라이센스 이외에 GPL을 추가하는 정책을 취하고 있다. 한편 최근 개정된 GPL 3.0은 Apache License 2.0과 양립가능하다.
아래는
사용 여부 명시 : 많은 OpenSource라이센스들은 소스코드를 자유롭게 열람하고 수정 및 재배포할 수 있는 권리를 부여하는 한편, 소프트웨어를 사용할 때 해당 OpenSource 소프트웨어가 사용되었음을 명시적으로 표기하는 것을 의무사항으로 채택하고 있다. 이것은 마치 논문을 쓸 때 인용을 하는 것과 비슷하여, '이 소프트웨어는 OpenSource 소프트웨어인 무엇무엇을 사용하였습니다.'라는 식으로 사용 여부를 명확히 기술하라는 것이다. 사용자 매뉴얼이나 기타 매뉴얼을 대체하는 매체가 있다면 그곳에 기술하면 된다.
소스코드 공개 : OpenSource라이센스에 따라서는 수정하거나 추가한 부분이 있을 때 해당 부분의 소스코드도 공개하여야 한다고 명시하는 경우가 있다. 이에 해당하는 라이센스는 GPL이 가장 유명하다. 그러나 정확한 공개 범위는 각각의 라이센스에서 정하고 있는 범위가 다르고, 소프트웨어를 개발하는 방법에 따라서도 달라질 수 있다. 자세한 내용은 다음 절의 쟁점부분을 참고하기 바란다.
특허 : 특허에 대한 기본적인 내용은, 만약 어떤 기술이 특허로 보호될 경우 해당 기술을 구현할 때 반드시 특허권자의 허락을 받아야 한다는 것이다. 이는 OpenSource 이냐 아니냐에 상관 없이 공통적으로 해당된다. 그러나 어떤 특허를 OpenSource 로 구현할 경우 해당 특허의 구현 결과는 OpenSource라이센스를 따르게 되는 등, OpenSource 소프트웨어와 관련된 특허권의 문제는 보다 복잡하게 전개되고 있다. 특히 최근 소프트웨어특허가 급격히 증가하면서 문제가 심각해지고 있기 때문에, 새롭게 만들어지는 OpenSource라이센스들에서는 특허관련조항을 포함하고 있는 경우가 많아지고 있다. 이와 관련된 자세한 내용도 다음 절의 쟁점부분을 참고하기 바란다.
GPL은 현재 가장 많은 OpenSource 소프트웨어가 채택하고 있는 라이센스이다. OpenSource라이센스들 중에서 가장 많이 알려져 있고 의무사항들도 타 라이센스에 비해 엄격한 편이다. GPL의 주요 내용은 다음과 같다.
소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실 명시
소프트웨어를 수정하거나 새로운 소프트웨어를 링크(Static과 Dynamic linking 모두)시키는 경우 GPL에 의해 소스 코드 제공해야 함.
Object Code 또는 Executable Form으로 GPL 소프트웨어를 배포하는 경우, 소스 코드 그 자체를 함께 배포하거나 또는 소스코드를 제공받을 수 있는 방법에 대한 정보 함께 제공해야 함
자신의 특허를 구현한 프로그램을 GPL로 배포할 때는 GPL 조건을 준수하는 이용자에게는 로열티를 받을 수 없으며, 제3자의 특허인 경우에도 특허권자가 Royalty-Free 형태의 라이센스를 제공해야만 해당 특허 기술을 구현한 프로그램을 GPL로 배포하는 것이 가능
GPL 소프트웨어를 사용하였을 경우 "본 제품(소프트웨어)는 GPL 라이센스 하에 배포되는 소프트웨어 XXX(사용한 GPL 소프트웨어 이름)를 포함합니다"와 같은 문구를 매뉴얼 혹은 그에 준하는 매체에 포함시키고, GPL 전문을 첨부해야 한다.
GPL에서 가장 논란이 되는 부분은 소스코드 공개 범위이다. 실제 소스코드 공개 범위는 다음 장의 쟁점 부분에서 확인하기로 한다. 소스코드를 공개하기 위해서는 소스코드를 CD Rom 등의 매체에 담아서 제품판매시 함께 배포하거나, 매뉴얼에 소스코드를 요청할 수 있는 연락처를 기입하여 두거나, 혹은 FTP 서버, 웹서버 등에 소스코드를 업로드해 두고 매뉴얼에 해당 주소를 기입하면 된다.
최근 특허에 관한 쟁점도 중요성이 증가하고 있는데, 자세한 내용은 다음 장의 쟁점 부분에서 설명한다.
FSF가 일부 Library에 GPL보다 다소 완화된 형태인 GNU Lesser General Public License (LGPL)를 만들어 사용하고 있는 이유는 오픈 소스 소프트웨어의 사용을 장려하기 위한 전략적인 차원에서이다. 만일 상용 Library와 동일한 기능을 제공하는 Library에 GNU와 같은 엄격한 라이센스를 적용하게 되면, 개발자들이 Library의 사용을 꺼려할 것이다. 오히려 이미 널리 사용되고 있는 상용 Library와 동일한 기능을 제공하는 Library를 LGPL로 배포하여 그 사용을 장려하고 사실상의 표준으로 유도하는 한편, 관련된 다른 오픈 소스 소프트웨어를 보다 더 많이 사용할 수 있도록 하겠다는 것이 FSF의 전략이다. LGPL Version 2.1은 GNU ‘Library’ General Public License version 2.0의 후속 버전이다. 일부 한정된 Library에 대해서만 LGPL을 사용하려는 것이 FSF의 의도였으나 ‘Library’란 단어가 라이센스 이름에 포함되어 개발자들이 모든 Library를 위한 라이센스로 오인하는 경향이 있었다. 결국 이러한 오인을 방지하기 위하여 ‘Library’를 ‘Lesser’로 수정하였을 뿐 기본적인 내용은 동일하기 때문에 Version 2.1으로 표기한 것이다. LGPL의 주요 내용을 요약하면 다음과 같다.
소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 LGPL에 의해 배포된다는 사실 명시
LGPL Library의 일부를 수정하는 경우 수정한 Library를 LGPL에 의해 소스 코드 공개
LGPL Library에 응용프로그램을 링크시킬(Static과 Dynamic Linking 모두) 경우 해당 응용프로그램의 소스를 공개할 필요 없음. 다만 사용자가 Library 수정 후 동일한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그램의 Object Code를 제공해야 함
특허의 경우 GPL과 동일함
LGPL은 링크하는 소프트웨어의 소스코드를 공개할 필요가 없다는 점이 GPL과 가장 큰 차이점이다. 여하한 경우에도 LGPL 소프트웨어 자체는 공개해야 하지만 LGPL 소프트웨어와 링크되는 부분의 소프트웨어 소스코드는 공개해야 할 의무가 발생하지 않으므로 기업의 입장에서는 LGPL 소프트웨어를 좀더 선호하게 된다. 사용 여부 명시 등은 GPL과 동일하게 반영하면 되고 공개해야 할 소스코드의 공개 역시 GPL과 동일한 방식을 이용하면 된다.
BSD(Berkeley Software Distribution) 라이센스는 GPL/LGPL보다 덜 제한적이기 때문에 허용범위가 넓다. 이는 BSD 라이센스로 배포되는 프로젝트가 미국 정부에서 제공한 재원으로 운영되었기 때문이다. GPL과의 차이점 중 가장 중요한 사항은 BSD 라이센스는는 소스코드 공개의 의무가 없다는 점이다. 따라서 BSD 라이센스의 소스 코드를 이용하여 새로운 프로그램을 개발하여도 새로운 프로그램의 소스 코드를 공개하지 않고 BSD가 아닌 다른 라이센스를 적용하여 판매할 수 있다. 주요 내용을 요약하면 다음과 같다.
소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시
수정 프로그램에 대한 소스 코드의 공개를 요구하지 않기 때문에 상용 소프트웨어에 무제한 사용가능
아파치 라이센스는 아파치 웹서버를 포함한 아파치 재단(ASF: Apache Software Foundation)의 모든 소프트웨어에 적용되며 BSD 라이센스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다. 다만 "Apache"라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 명시적으로 들어가 있고, 특허권에 관한 내용이 포함되어 BSD 라이센스보다는 좀더 법적으로 완결된 내용을 담고 있다. 특히 Apache License 2.0에서 특허에 관한 조항이 삽입되어 GPL 2.0으로 배포되는 코드와 결합되는 것이 어렵다는 문제가 었었는데, GPL 3.0(안)에서는 이 문제를 해결하여 아파치 라이센스로 배포되는 코드가 GPL 3.0으로 배포되는 코드와 결합하는 것이 가능해졌다.
MPL은 Netscape 브라우저의 소스코드를 공개하기 위해 개발된 라이센스이다. MPL은 공개하여야할 소스코드의 범위를 좀더 명확하게 정의하였다. GPL에서는 링크되는 소프트웨어의 소스코드를 포함하여 공개하여야 할 소스코드의 범위가 모호하게 정의되어 있지만 MPL에서는 링크 등의 여부에 상관없이 원래의 소스코드가 아닌 새로운 파일에 작성된 소스코드에 대해서는 공개의 의무가 발생하지 않는다. 따라서 MPL 소프트웨어 그 자체는 어떻게 하든 공개를 해야 하지만 원래 소스코드에 없던 새로운 파일들은 공개하여야 할 의무가 발생하지 않으므로 GPL에 비해 훨씬 명확하다. 주요 내용을 요약하면 다음과 같다.
소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 MPL에 의해 배포된다는 사실을 명시
MPL 코드를 수정한 부분은 다시 MPL에 의해 배포
MPL 코드와 다른 코드를 결합하여 프로그램을 만들 경우 MPL 코드를 제외한 결합 프로그램에 대한 소스코드는 공개할 필요가 없음
소스코드를 적절한 형태로 제공하는 경우, 실행파일에 대한 라이센스는 MPL이 아닌 다른 것으로 선택가능
앞에서 GPL/LGPL/BSD/MPL/Apache License 등 많이 사용되는 라이센스들을 간략히 살펴보았는데 이중에서 GPL/LGPL/MPL 등은 수정한 내용에 대한 소스코드를 공개하여야 하고 BSD/Apache License 등은 수정하더라도 소스코드를 공개할 의무가 발생하지 않는다. GPL/LGPL/MPL 등 소스코드 공개 의무가 발생하는 라이센스는 상호주의(reciprocal) 혹은 copyleft 라이센스라고 하며, 그 결과물이 원 소프트웨어의 파생물(derivative work)일 경우 소스코드를 공개해야 한다. 그런데 소스코드의 공개범위를 기계적으로 판단할 수 있는 방법은 없으며 라이센스마다 서로 다르게 정의하고 있으므로 잘 판단하여야 한다. GPL을 중심으로 보다 자세히 살펴보도록 하자.
GPL의 경우, GPL 프로그램의 소스코드를 이용자가 개발한 프로그램코드에 삽입하거나 링크시킨 후 함께 배포하고자 하는 경우, 이용자가 개발한 프로그램도 GPL 조건으로 배포해야 한다. 반면 GPL 제2조 후단에서는 ‘원 프로그램으로부터 파생되지 않고 그 자체로 독립적이고 분리되어 있는 저작물(separate works)은 다른 라이센스 조건에 의해 배포가능하며, 단순집합물(mere aggregation)로서 원 프로그램과 동일한 매체로 배포할 수 있다’고 규정하고 있다. 예를 들어 독립적으로 제작된 프로그램을 GPL 프로그램과 단순히 동일한 매체에 저장하여 배포할 경우에는 GPL이 아닌 다른 라이센스조건에 의해 배포할 수 있다. 하지만 구체적으로 어떠한 경우가 파생물에 해당하는지, 또는 독립된 프로그램의 단순한 집합물에 해당하는지를 구별하는 것은 쉽지 않다. 결국 최종적으로는 법원의 판단에 의해 결정될 문제인데, FSF는 GPL FAQ에서 몇 가지의 구별기준을 제시하고 있다. 예를 들어 두개의 모듈이 동일한 실행파일에 포함되어 있거나 공유주소영역(shared address space)에서 링크되어 실행되도록 설계된 경우에는 전자에 포함되고, 2개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments 형태로 통신하는 경우에는 후자에 해당한다. 플러그인(plug-ins)의 경우 동적으로 링크되어 함수호출을 하고 데이터구조를 공유하는 경우에는 전자에, fork와 exec를 이용하면 후자에, 해당한다. 인터프리터(interpreter)나 컴파일러(compiler)의 경우에는 원칙적으로 컴파일된 결과물과는 분리된 것으로 보지만, 컴파일과정에서 라이브러리나 클래스가 결과물에 추가된 경우에는 라이브러리 또는 클래스와 결과물은 하나의 프로그램으로 볼 수 있다.
이와 같은 GPL의 특징은 다른 OpenSource 소프트웨어 라이센스와 비교할 때 명확히 드러난다. 예를 들어 LGPL은 일정한 요건을 충족시키는 경우 LGPL 라이브러리(Library)를 이용하는 프로그램(Work that uses the Library), 다시 말해 컴파일 또는 링크를 통해 LGPL 라이브러리와 함께 작동하도록 설계된 프로그램들을 배포할 경우에는 소스코드를 제공하지 않아도 된다.(LGPL 제5조). MPL도 한편으로는 GPL과 마찬가지로 수정된 코드의 소스코드를 제공할 것을 요구하면서, 다른 한편으로는 MPL 조건의 코드와 기타의 라이센스 조건의 코드를 결합한 프로그램(MPL에서는 이를 ‘Larger work’라고 표현하고 있다)을 만드는 것을 허용하고, 결합된 프로그램을 MPL이 아닌 다른 라이센스로 배포하는 것을 허용하고 있다(MPL 제3.7조). 예를 들면 별도의 파일로 함수(Function)를 추가할 경우 MPL은 기존 코드의 수정부분에만 적용할 뿐 추가된 함수에는 적용되지 않는다.
한편 원칙적으로 GPL 조건으로 배포하면서도 GPL 제2조와 관련해서는 다소 완화된 내용의 조건으로 프로그램을 배포하는 경우가 있다. 대표적 사례는 리눅스커널의 경우인데, 리눅스커널의 ‘COPYING' 파일에 포함되어 있는 라이센스 조건에는 ’정상적인 시스템 콜에 의해 커널 서비스를 이용하는 사용자프로그램(user programs)은 GPL에 의해 배포하지 않아도 좋다는 내용이 포함되어 있다. 이와 같은 내용에 따라 리눅스커널을 기반으로 한 라이브러리나 응용프로그램은 소스코드를 제공하지 않고도 배포할 수 있으며, 시장에서는 이를 확대해석하여 표준커널인터페이스를 이용하는 디바이스 드라이버나 동적 커널모듈(Loadable Kernel Module)도 사용자프로그램이 시스템 콜을 이용하는 것과 크게 다르지 않기 때문에 소스코드를 제공할 필요가 없는 것으로 보고 있다.
- 리눅스 커널은 부적절한 예제입니다. 리눅스 커널의 COPYING 파일의 내용은 GPL의 "derived work"가 어디까지인가에 대해 명확히 하는 부분이지, GPL에 따로 예외를 부여하는 조항이 아닙니다. 또 커널 모듈이 GPL이 아닐 수 있다는 내용도 리눅스 토발즈나 다른 리눅스 개발자의 생각과 다르며, 아래에 있는 내용과도 다릅니다. -- cwryu 2007-07-08 08:42:26
두 번째 사례는 GNU Classpath 프로젝트와 자바(Java) 플랫폼사례이다. GNU Classpath 프로젝트는 자바(java)언어의 가상머신(virtual machines) 및 컴파일러에서 사용되는 핵심 클래스라이브러리(core class libraries)를 자유소프트웨어로 대체하기 위한 프로젝트인데, 동 프로젝트의 결과물을 GPL로 배포하면서도 이와 링크된 다른 독립된 소프트웨어는 GPL로 배포할 필요가 없다는 내용의 예외를 인정하였다. 그런데 2006년 말 Sun이 향후 자바 플랫폼을 GPL 조건으로 배포하겠다는 선언을 하면서, 자바 플랫폼 중 특히 Java SE(Java Platform Standard Edition)와 Java EE(Java Platform Enterprise Edition)의 GPL 배포조건에 Classpath 예외를 추가한다고 발표하였다. 그 결과 Classpath 예외조항을 포함한 GPL 조건의 자바 플랫폼을 이용한 응용프로그램도 소스코드를 공개하지 않고 배포할 수 있다.
GPL, LGPL, MPL, Apache 라이센스 등의 OpenSource라이센스는 특허와 관련된 조항들을 가지고 있는데, 각각의 경우를 ⅰ) 라이센서(Licensor)의 특허인 경우, ⅱ) 제3자의 특허인 경우, ⅲ) 라이센시(Licensee)의 특허인 경우로 구분하여 설명할 수 있다. 다만 LGPL은 특허와 관련해서는 GPL과 동일하게 규정하고 있으며, BSD는 특허에 관한 규정을 두고 있지 않기 때문에 이하에서는 생략한다.
라이센서(Licensor)의 특허인 경우 : 소프트웨어에 대해 저작권을 가지고 있는 주체가 특허권을 함께 가지고 있는 경우이다. MPL과 Apache 라이센스는 이와 같은 경우 라이센서가 소프트웨어를 OpenSource라이센스조건으로 배포하는 경우 관련 특허권의 라이센스도 무상으로 제공하는 것으로 규정하고 있다. GPL의 경우에는 명문으로 규정하고 있지 않지만 대체적으로 관련 조문(제7조 등)의 해석상 묵시적인 라이센스를 제공하는 것으로 보고 있다. GPL 3.0에서는 단순 재배포자를 제외한 개발자 및 기여자(Contributor)의 경우 자신이 기여한 부분과 관련된 특허권 라이센스를 무상으로 제공하는 것으로 규정하고 있다. 한가지 주의하여야 할 것은 특허권 그 자체는 여전히 유효하다는 것이다. 따라서 예를 들어 특허권자 특허받은 정렬 알고리즘을 GPL로 배포되는 리눅스에 로열티 없이 사용 가능하도록 제공한다고 할지라도 독점 라이센스인 MS 윈도우즈에는 해당 정렬 알고리즘을 사용토록 허가하면서 여전히 로열티를 받을 수 있다.
라이센시(Licensee)의 특허인 경우 : 프로그램을 사용하는 이용자가 특허권을 가지고 있는 경우이다. MPL의 경우 이용자가 자신의 특허권을 문제 삼지 않고 그냥 사용하는 경우에는 아무런 문제가 없지만, 만약 이용자가 MPL 프로그램을 사용하던 중 자신의 특허권을 근거로 소송을 제기하게 되면, 적절한 시일 내에 소송을 철회하지 않는 한 라이센스가 종료되고, 그 결과 MPL 프로그램을 더 이상 사용할 수 없거나, 그 동안 사용했던 부분에 대하여 로열티 산정을 하는 등 일정한 보복이 가해진다. Apache 라이센스 2.0도 MPL과 비슷한 취지의 조항을 추가하였으며, GPL 3.0에서도 관련 내용이 추가되었다.
제3자의 특허인 경우 : 특허 소유자와 이를 프로그램으로 구현한 주체가 다른 경우인데, GPL 제7조에 의하면 특허 소유자가 무상(Royalty-Free) 조건의 특허 라이센스를 허용하지 않는다면 구현자는 이 프로그램을 GPL 조건으로 배포할 수 없다. 예를 들면 甲회사가 乙회사의 특허기술을 바탕으로 A라는 프로그램을 만들었을 경우, 乙회사가 그 특허를 모든 사람에게 무상으로 허용하지 않는다면, 설사 甲회사가 라이센스를 무료로 받았다고 할지라도 A프로그램을 GPL 조건으로 배포할 수 없다. 나아가 GPL 3.0에서는 제3자인 특허권자가 이용자들을 차별하여 라이센스를 부여하는 것을 막기위한 조항이 삽입되었다. 그 결과 2006년 말 MS와 노벨사이에 체결되었던 형태의 계약은 향후 어려울 것으로 보인다. MPL은 제3자의 특허인 경우에도 일단 배포는 허용하되, ‘LEGAL’이라는 이름의 파일을 추가하여 어떠한 특허가 문제되고 있는지, 어떤 사람이 클레임을 제기하고 있는지에 대한 사항을 자세히 기록하도록 하고 있다.
또한 일부 OpenSource 소프트웨어는 복수의 라이센스하에 배포되는 경우가 있다. 이를 주로 듀얼 라이센스(dual license)라고 하며, 이런 경우는 주로 오픈 소스 소프트웨어를 상업적 목적으로 이용할 뿐만 아니라 OpenSource 커뮤니티와의 협력을 위한 경우가 대부분이다. 하나 이상의 라이센스가 있는 OpenSource 소프트웨어를 이용할 경우, 이용자는 사용 목적에 가장 잘 부합하는 라이센스 하에 배포되는 소스 코드를 선택할 수 있다. 대표적인 사례로는 MySQL, Trolltech의 Qt 라이브러리 등이 있다.
Linux 커널은 GPL v2로 배포된다. 그런데 리눅스커널의 'COPYING'파일에는 GPL v2 전문과 함께 다음과 같은 내용이 맨 위에 추가로 기재되어 있다.
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
정상적인 시스템 콜에 의해 커널 서비스를 이용하는 사용자프로그램(user programs)은 GPL에 의해 배포하지 않아도 좋다는 뜻이다. 이와 같은 내용에 따라 리눅스커널을 기반으로 한 라이브러리나 응용프로그램은 GPL v2의 영향을 받지 않는 것이다. 그러나 Linux 커널은 커널의 기능을 커널 모듈이라는 형태로도 이용할 수 있는 인터페이스를 제공하는데 이 커널 모듈도 위의 예외사항에 속하는지에 대한 논란이 계속되고 있다. 즉, 리눅스 커널모듈도 모두 GPL v2로서 소스코드를 공개해야 하는지, 아니면 독점 라이센스를 적용하여 소스코드를 공개하지 않아도 되는지에 대한 논란이다. 이에 대해서는 리눅스 커널 개발자들 사이에서도 의견이 갈리고 있다.
최소한, http://www.kernel.org 에서 배포되는 공식 커널 버전을 기준으로 모듈 인터페이스를 임의로 수정하지 않은 상태에서 동작이 가능한, 자체 개발된 커널 모듈은 GPL이 아닐 수 있다고 주장할 수 있다. 그러나 모듈 인터페이스를 임의로 수정할 경우에는 설득력이 훨씬 약해지며, 커널 모듈이 GPL이냐 아니냐에 대한 논란은 매우 첨예하게 대립하고 있으므로 커널 모듈은 모두 GPL이라고 가정하고 공개가 불가능한 부분은 사용자프로그램(user program)에서 구현하는 것이 바람직하다.
커널 모듈 인터페이스에는 MODULE_LICENSE()라는 것이 있어서, 여기에서 커널 모듈의 라이센스를 GPL로 지정하면 EXPORT_SYMBOL_GPL()로 정의한 "GPL 심볼"을 사용할 수 있다. 커널 모듈의 라이센스를 GPL로 하지 않으면 "GPL 심볼"이 아닌 심볼만을 사용해야 한다. 이 인터페이스를 가이드라인으로 커널 모듈이 GPL이 되어야 하는 지 여부를 어느정도 판가름할 수 있다. 하지만 이 "GPL 심볼"만 피해가면 GPL로 안 해도 된다고 오해해서는 안 된다. 이와 같은 장치는 반드시 GPL이 되어야 하는 지 명확하게 하기 위한 목적일 뿐이다. 즉 "GPL 심볼"을 사용한 모듈은 반드시 GPL이 되어야 하지만, GPL 심볼을 사용하지 않도록 피해간다고 해서 GPL이 아니어도 된다는 의미는 아니다. 심볼 사용 여부와 관계없이 GPLv2의 2항에 따라 (If identifiable sections of that work ... can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.) 해당 커널 모듈이 리눅스 커널과 얼마나 독립적인가가 GPL 여부 판단의 문제가 된다. 실제로 GPL이 아닌 상태로 배포되고 있거나 배포되었던 커널 모듈들의 예로, Open Sound System (멀티 플랫폼, 최근에 GPL로 전환되기 전), NVidia/ATI의 비디오 카드 드라이버 (MS-Windows에서 포팅), AFS (유닉스에서 포팅) 등을 보면, 그 개발 과정이나 의존하는 플랫폼이 리눅스와는 독립적으로 이루어졌다고 볼 수 있다. (하지만 이들 역시 약간 애매한 상태에 있는 게 사실이다.)
FreeBSD는 1993년에 처음 발표되었다. FreeBSD는 Unix 시스템인 BSD(Berkeley Software Distribution)를 기반으로 개발되었고, 다양한 Unix 버전 중 오픈 소스 Unix라 할 수 있을 것이다. FreeBSD는 가장 제약 사항이 적은 BSD License에 의해 배포되고 있다. 따라서 FreeBSD 소스 코드를 상업적으로 아무런 제한없이 이용할 수 있다. 단, 소스 코드 혹은 바이너리 형식으로 재배포할 때는 FreeBSD의 원저작권자인 The Regents of the University of California의 저작권을 명시해야 한다. 현재 FreeBSD의 소스 코드에는 다음과 같이 저작권이 명시되어 있다. "All of the d0cumentation and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by The Regents of the University of California" 또한, Free BSD를 이용하고 있음을 밝히기 위해서는 다음의 사항을 명시해야 한다. "This product includes software developed by the University of California, Berkeley and its contributors." 마지막으로 재배포 시에는 FreeBSD 소스 코드에 포함된 라이센스 내용을 그대로 포함시켜야 한다. 요약하면, FreeBSD는 소스 코드 공개를 요구하지 않으며, 만약 원본 혹은 수정된 소스 코드를 공개하고자 하면 위에서 언급한 사항들만 준수하면 된다.
MySQL은 현재 가장 인기 있는 관계형 데이터베이스 서버로서 사용자는 GPL 라이센스나 일반 상용 라이센스 둘 중 한가지를 선택할 수 있는데, 상용 라이센스는 GPL 라이센스의 여러가지 요구사항들(소스코드 공개 등)을 지키기 어려운 경우에 선택할 수 있으므로 일반적인 상용 라이센스 판매를 통해 수익을 내고 있다. 이러한 라이센싱 모델을 듀얼 라이센스라고 하며 MySQL은 듀얼 라이센싱 모델의 대표적인 사례로서 종종 언급된다. MySQL의 이같은 듀얼 라이센싱 모델에 대해서 좀더 살펴보면 다음과 같다.
우선 OpenSource 프로젝트 목적으로 MySQL을 이용할 경우를 살펴보자. 만약, 이용자가 MySQL 라이브러리를 이용하여 개발한 애플리케이션을 GPL 라이센스 하에 배포한다면, 이 경우 MySQL은 GPL 라이센스가 적용된다. 즉, 이용자가 기꺼이 직접 개발한 애플리케이션을 GPL하에 배포하기 때문에 MySQL 라이브러리 역시 GPL이 되더라도 문제가 발생하지 않을 것이다. 또한, 이용자가 GPL이 아닌 Open Source Initiative에서 인정한 라이센스 하에 직접 개발한 애플리케이션을 배포할 경우에도 특별 예외 조항을 두어 라이센스 충돌이 발생하지 않도록 하였다. 즉, 비록 GPL 라이브러리를 이용하더라도, 직접 개발하였거나 GPL 라이브러리와 독립된 부분으로 인정이 되는 애플리케이션의 소스 코드는 GPL이 아닌 다른 OpenSource라이센스로 배포할 수 있도록 하였다. GPL의 원칙을 따를 경우, GPL 라이브러리에 기반한 애플리케이션 전체 소스 코드가 GPL이 되기 때문에 소스 코드 공개 의무가 발생한다. 한편 GPL 등 OpenSource라이센스조건을 따르지 않는 형태로 사용하고자 하는 경우에는 MySQL AB사로부터 Commercial License를 받아야 한다.
그러나 한가지 주지하여야 할 것은 GPL의 의무사항은 소프트웨어를 배포할 때 발생하는 것이므로 만약 MySQL을 다운로드해서 MySQL과 연동되는 웹사이트 등을 만들어서 서비스만 하는 경우는 MySQL을 직접 배포하지 않는 것이므로 GPL의 의무사항이 발생하지 않는다는 것이다. 예를 들어 인터넷 포털 업체들은 MySQL의 상용 버전을 구입하지 않고 GPL 버전을 사용하면서 MySQL이나 관련 소프트웨어의 소스코드를 공개하지 않고 있다.
Apache 소프트웨어들은 현재 ASF에서 자체적으로 개발한 Apache License Version 2.0하에 배포되고 있다. Apache License에 따르면, 누구든 자유롭게 Apache 소프트웨어를 다운받아 부분 혹은 전체를 개인적 혹은 상업적 목적으로 이용할 수 있다. 또한, 재배포 시에도 원본 소스 코드 혹은 수정한 소스 코드를 반드시 포함시킬 것을 요구하지 않는다. 다만, 재배포하고자 할 경우에는 Apache License, Version 2.0을 포함시키고 ASF에 개발된 소프트웨어임을 명확히 밝힐 것을 요구한다. 아울러 ASF가 승인하지 않는 ASF 공식 마크를 임의로 사용할 수 없다.
Firefox는 오픈 소스 소프트웨어이며 현재 MPL, GPL, LGPL 세 가지 라이센스 하에 배포되고 있다. 이 세가지 라이센스는 모두 공통적으로 누구나 소스 코드를 보고 수정하며 재배포하는 것을 허용한다. 원래 Firefox는 MPL에 의해 배포되었다. 그런데 파생물의 상업적 이용을 제한적으로 허락하는 MPL은 GPL 혹은 LGPL과 호환될 수 없기 때문에 FSF로 부터 많은 비난을 받았다. 이 문제를 해결하기 위해 Mozilla는 Firefox를 MPL, GPL, 그리고 LGPL하에 다시 라이센싱하였다. 이 후, 개발자들은 이 세 가지 라이센스 중 자신들의 목적에 가장 잘 부합하는 라이센스를 선택할 수 있게 되었다. 그런데 하나 유의할 점은, Firefox의 일부 상용 컴포넌트를 포함하고 있기 때문에, 이 상용 컴포넌트는 위에서 언급한 세 가지 라이센스의 적용을 받지 않는다. 대신, 이들은 Mozilla End User License Agreement(EULA)의 제한을 받고 있다.
Sendmail은 1981년 Eric Allman에 의해 Mail Transfer Agent(MTA)로 개발되었다. 당시에 그는 UC Berkely에서 일하며 대학의 네트워크와 Arpanet 사이에 이메일을 주고받기 위한 목적으로 sendmail을 개발하였다. 처음부터 Sendmail은 메일 프로토콜의 개방성과 라우팅 기능성, 파일의 유연성에 초점을 맞추었기 때문에 오늘날 이메일 서버 시장의 1위 자리를 차지할 수 있었을 것이다. Allman은 여전히 Sendmail 개발의 중심에 있으며, Sendmail의 유지보수와 기능 및 성능 개선 등의 난관을 헤쳐가기 위해 Sendmail, Inc.이라는 회사를 설립하였다. Sendmail 8.9 이전 버전은 오픈 소스 형식으로 개발되었으며, 8.9 버전부터는 Allman이 설립한 회사에 의해 개발 및 공개되었다. 이러한 역사적 배경 때문에 Sendmail은 두 가지 다른 라이센스 형식을 취하고 있다. 우선, Sendmail을 단순히 컴파일해서 바이너리만 사용하거나, 아니면 오픈 소스 형식으로 소스 코드를 제공하며 이용할 경우는 Sendmail License를 적용받는다. 이 라이센스는 Sendmail의 자유로운 이용, 수정, 및 배포를 허락한다. 단, 재배포할 경우에는 배포에 필요한 비용 이상을 부과할 수 없으며, Sendmail에 포함된 copyright notice를 반드시 포함시켜야 한다. 그리고 재배포시 소스 코드를 포함시키지 않을 경우에는, 최대 3년까지 소스 코드 제공을 보장하는 문서를 포함시켜야 한다. 반면, 소스 코드 제공없이 상업적 용도로 이용할 경우에는 Sendmail, Inc.와 접촉해서 별도의 라이센스를 받아야만 한다.
최근 국내외 많은 기업들이 OpenSource 소프트웨어를 활용하여 비즈니스를 수행하고 있다. 선진 기업들은 기업 외부의 OpenSource 소프트웨어를 도입하여 활용할 뿐만 아니라, OpenSource 개발방법론을 통해 기업에서 필요한 소프트웨어를 개발하기도 하며, 그 과정에서 외부에 있는 OpenSource 커뮤너티를 적극 활용하기도 한다. 하지만 국내 기업들의 대다수는 OpenSource 소프트웨어관련 정책을 따로 마련하지 않고 개발자들 수준에서 기업외부에 존재하는 OpenSource 소프트웨어를 단순 활용하는 수준에 머물러 있는데, 향후 OpenSource 소프트웨어에 대한 활용의 필요성이 지속적으로 증가할 것이라는 점을 고려한다면 개별기업차원에서 OpenSource 소프트웨어관련 정책을 수립할 필요성이 있다. OpenSource 소프트웨어 관련 정책을 수립할 때에는 개별기업이 속한 시장의 상황, OpenSource 소프트웨어의 발전정도, 개별기업들의 기술수준 및 비즈니스모델 등을 고려할 필요가 있다.
개별기업에서 OpenSource 를 활용할 경우에는 OpenSource 의 장/단점을 명확히 이해한 상태에서 활용 여부 및 방향을 결정하여야 할 것이다. 일반적으로 OpenSource 소프트웨어는 다음과 같은 장점을 가지고 있다.
Low Entry Cost : 일반적으로 OpenSource 는 Web 상에서 무료로 다운로드 및 소스 코드 수정/ 재배포가 가능한 것이 특징이다. 따라서 초기 개발을 시작하기 위한 비용이 적게 요구된다는 장점이 있다.
Fast, Flexible Development : OpenSource 커뮤니티는 보통 최신 기술 정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운영되기 때문에 독점 프로그램에 비해 기술 발전 속도가 빠르다.
Open Formats & Protocols : OpenSource 는 주로 Open Formats 또는 Protocols을 사용하기 때문에 서로 다른 소프트웨어간 상호 연동성이 보장되는 장점이 있다. 모든 기기들이 서로 다른 Network을 통해 하나로 연결되는 Ubiquitos 시대에는 필수적인 요소로 볼 수 있다. 또한 OpenSource 운동의 주 원인 역시 상용 프로그램들간의 비호환성을 해결하는 것이다.
Reliability & Stability : OpenSource 의 개발 과정을 볼 때, 전세계에 있는 수많은 우수한 개발자들이 직접 개발과 Debugging 과정에 참여하기 때문에 In-house에서 폐쇄적으로 개발되는 독점 프로그램에 비해 비교적 안정적으로 동작한다는 평이 일반적이다. 하지만 이러한 Reliability와 Stability는 많은 개발자들의 적극적인 참여가 있을 때에만 가능한 것이기 때문에, 사용하고자 하는 OpenSource 의 개발 과정을 주의깊게 살펴볼 필요가 있다.
Networking : OpenSource 가 확산된 가장 큰 이유가 다양하고 강력한 Networking 기능 지원이라 해도 과언이 아닐 것이다. 대표적으로 Apache는 전세계 웹 서비스의 절반 이상을 차지하고 있을 정도이다. 또한 Open Source Networking Solution은 대부분 상용 프로그램과 호환되기 때문에 상품화에도 아주 잘 활용될 수 있을 것이다.
애플리케이션의 부족: 대부분의 사용자들은 Windows 기반의 GUI(Graphical User Interface)를 갖고 있는 Application에 익숙해 있지만, 이에 버금가는 Linux 기반의 Application이 많이 부족한 것이 현실이다. 또한 Linux 기반으로 개발된 많은 Application들은 Windows 기반 Application들과 호환되지 않는 문제점도 있다.
빈약한 문서: 상용 프로그램에 비해 OpenSource 는 체계적인 문서를 갖고 있지 못한 단점이 있다. 이는 경우에 따라서는 개발과정의 지연을 초래할 수도 있기 때문에 활용하고자 하는 OpenSource 가 얼마만큼 문서화가 잘 되었는지도 잘 살펴보아야 한다.
불확실한 개발 로드맵: OpenSource 는 영리를 목적으로 하는 회사에서 개발되는 것이 아니라, 자발적 참여를 바탕으로 Web 상에서 자유롭게 개발되는 것이 특징이다. 그렇기 때문에 독점 프로그램에서 볼 수 있는 Roadmap을 기대하기 힘든 면이 있다. OpenSource 의 이러한 단점은 OpenSource 를 활용하는 개발 과제의 Roadmap에 까지 영향을 미칠 수 있기 때문에 활용하고자 하는 OpenSource 의 향후 개발 계획이 얼마나 체계적으로 세워져 있는지도 고려해야 한다.
지적 재산권: OpenSource 에 기업이 보유한 특허 및 소스코드를 포함시킬 경우 OpenSource라이센스는 일반적으로 Royalty-free를 요구하고 있다. 따라서 Royalty-free를 원치 않을 경우에는 해당 OpenSource 를 사용할 수가 없으며, 또한 사용 후 Royalty를 주장하게 되면 해당 OpenSource 에 대한 사용 권한이 박탈되는 경우가 일반적이다. 따라서 OpenSource 를 활용하여 특허를 구현하거나 기존 소스코드를 포함하고자 할 경우, 반드시 Royalty에 대한 입장을 명확히 하여야 할 것이다.
오픈 소스를 활용하기 위해서는 독점소프트웨어와 마찬가지로 반드시 해당 OpenSource 의 라이센스에 대한 준수가 필수적이다. 하지만 OpenSource라이센스에서 강제하고 있는 내용에 대해서 개발자 및 관리자들의 이해가 아직도 많이 부족한 것이 현실이다. 자칫 잘못하면 라이센스 위반으로 이미 판매중인 제품을 리콜하거나, 소스코드를 공개해야 하며, 개발중인 제품을 아예 처음부터 다시 개발해야 하는 상황을 초래할 수도 있으므로 체계적인 프로세스를 수립하고 이를 담당할 관련 조직을 구축하는 것이 필요하다.
개발이 끝난 이후에 OpenSource라이센스관련 문제가 발견된다면 수정에 많은 시간과 비용이 소요되므로 과제 계획 단계부터 OpenSource라이센스문제를 고려할 필요가 있다. 또한 개발이 진행되면서도 단계별로 준수해야 할 사항들을 정의하고 반드시 체크해야만 한다. 본 문서에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 S/W 개발프로세스를 다음과 같이 표준화/단순화하였다.
OpenSource라이센스 관련 문제를 피하는 가장 좋은 방법은 개발 기획 시점부터 이를 고려하는 것이다. 우선 해당 과제에 OpenSource 를 활용할 것인지의 여부를 판단하여야 하며, 구체적으로 어떤 프로그램을 사용할 지를 판단하여야 한다. OpenSource 의 특성상 Web 상에 여기저기 흩어져 있지만, 쉽게 OpenSource 에 관한 정보를 찾을 수 있는 곳으로는 Freshmeat.net, SourceForge, OSDir.com, BerliOS, Bioinformatics.org 등을 들 수 있다. 이와 같은 사이트들은 대부분 License별 OpenSource 분류 항목을 두고 있기 때문에 쉽게 해당 프로그램의
기획 단계의 마지막으로 해당 S/W Component별로 소스코드 공개가능여부를 판단하여야 한다. GPL등 소스코드 공개 의무가 발생하는 OpenSource 소프트웨어를 사용할 경우에는 과제 결과물의 소스코드 공개가 요구되기 때문에, 경우에 따라서는 S/W 구현 방법을 달리해야하기 때문이다. 소스코드의 공개가능 여부에 대한 판단 기준으로 다음의 사항을 참조할 수 있을 것이다.
Maintenance : 소프트웨어의 경우 하드웨어와 달리 개발 후 지속적 Upgrade 및 Debugging과 같은 Maintenance 과정이 중요하다. 이러한 Maintenance 과정은 상당한 Resource를 요하기 때문에 Maintenance를 직접 할 것인지에 대한 고려가 필요하다. 개발한 소스 코드를 OpenSource 커뮤니티에 공개하고, 이를 바탕으로 오픈 소스 커뮤니티를 통한 Maintenance 방법 역시 경우에 따라 아주 효율적일 수도 있을 것이다.
Fast Development : OpenSource 의 개발 모델 중 가장 특징적인 것이 바로 ‘Release Early and Often’을 통한 ‘Parallel Development and Debugging’이 가능한 것이다. 이를 통해 OpenSource 는 빠른 개발 속도를 가능케 하고 있다. 이러한 모델을 Resource가 부족한 개발 과제에 적용하면 보다 효율적이고 빠른 개발이 가능할 것이다.
Reliability 확보: S/W의 신뢰성 확보의 가장 좋은 방법은 다양한 사용자들이 다양한 환경에서 해당 프로그램을 사용하면서 발견되는 문제점을 신속히 수정하는 것이다. 이런 측면에서 볼 때 OpenSource 커뮤니티를 잘 활용하면 S/W Reliability 확보에 상당한 도움을 얻을 수 있을 것이다.
차별화 유지 어려움 : 소스 코드를 공개하게 되면 그 소스 코드는 경쟁사에게도 공유되는 것이기 때문에 결국 제품의 차별화 확보가 불가능하게 되는 단점이 있다.
지적재산권 확보의 어려움: 기업이 보유한 특허를 구현하여 소스코드를 공개하는 것은 결국 모든 사용자들에게 Royalty-free의 조건으로 특허를 공개하는 것이나 마찬가지가 된다.
특허 침해 소송 제기 가능성 증가: 소스 코드가 공개되어 있으면 누구든 그 소스 코드를 볼 수 있기 때문에 특허 침해 소송 제기 가능성이 증가하게 되는 문제점이 발생할 수 있을 것이다.
자체 개발한 소스 코드를 공개해도 무방한 경우는 특별히 구현 방법에 신경 쓸 필요가 없다. 단, 소스 코드를 공개할 경우 회사보유의 지적재산권을 포함시키지 않도록 주의할 필요가 있다. 그러나 소스 코드 공개를 원하지 않을 경우는 사용하는 OpenSource 의 라이센스 강제 사항과 활용하고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한 경우가 발생할 수 있기 때문에, 이럴 경우는 라이센스 혹은 법률 전문가에게 의뢰하여 정확한 판단을 받아야 할 것이다.
개발이 완료된 후에는 개발 결과물인 소스 코드에 대해 실질적인 검증 작업이 필요하다. 개발 계획서 그 자체로는 라이센스 이슈가 없었더라도 실제 구현 과정에서 개발자가 OpenSource라이센스에 대한 검증없이 사용한 경우가 있을 수 있기 때문이다. 최근에는 특정한 소스코드가 OpenSource 코드와 일치하는지를 검증하여 주는 프로그램을 활용하는 사례가 증가하고 있다.
이 단계에서는 사용된 OpenSource 소프트웨어들을 라이센스별로 분류하고 각 라이센스에서 준수해야 할 사항들이 실제로 제품에 반영될 수 있도록 하여야 한다. 앞에서 OpenSource 의 라이센스 의무사항은 크게 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이센스 조합', '사용 여부 명시', '소스코드 공개', '특허' 등이 있다고 기술하였는데 이중에서 '저작권 관련 문구 유지', '제품명 중복 방지', '특허' 등은 기획 및 구현 단계에서 확인되어야 할 사항이고, 제품화단계에서는 '소스코드 공개', '사용 여부 명시' 등을 확인할 필요가 있다.
소스코드 공개는 공개 의무가 발생하는 소스코드를 제품을 배포할 때 함께 배포한다거나(예: CD롬 등), 연락처를 기재하고 해당 연락처로 요청하게 한다거나, 혹은 별도의 웹사이트 등에 업로드하여 두고 받아 가도록 하는 등의 방법이 가능하다.
사용 여부 명시는 해당 의무가 발생하는 소프트웨어에 대한 설명을 사용자 매뉴얼 등에 기재함으로써 이루어지는데, GPL/LGPL/MPL에서 이를 요구하고 있다. 이와 같은 경우 OpenSource 를 사용하였음을 숨기지 않고 고객에게 그 사실을 정확히 전달할 필요가 있다.
1991년 배포된 GPL 2.0은 2007년까지 16년 동안 수정 없이 사용되었다. 소프트웨어관련 기술과 이를 둘러싼 시장, 제도의 변화속도에 비추어보면 상당히 오랜 기간 동안 개정되지 않고 사용된 것으로 평가할 수 있다. 하지만 1990년대 초반 오픈소스소프트웨어가 널리 사용되기 이전에 만들어진 GPL 2.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․서버 운영체제로부터 휴대폰, PDA, 셋탑박스, 홈네트워킹 장비 등의 임베디드소프트웨어분야에서 광범위하게 사용되고 있었다. 다시 말하면 더 이상 FSF의 GNU프로젝트에서만 사용되는 라이선스가 아니며, 그야말로 자유/오픈소스소프트웨어에 관계된 수많은 기업과 사람들이 지켜야 할 행동규범의 지위를 갖게 된 것이다.
FSF는 지난 수년 동안 자유/오픈소스소프트웨어 커뮤니티, 산업계, 학계 등과 공식적으로 또는 비공식적으로 GPL의 개정에 대해 논의해 왔으며, 이를 바탕으로 마련한 첫번째 안(First Discussion Draft)을 2006년 1월 발표하였다. 초안의 발표와 함께 다양한 의견을 수렴하기 위한 토론위원회 등의 공식적인 프로세스를 만들었다. 이를 바탕으로 인터넷을 통한 의견 수렴, 수차례의 국제 컨퍼런스를 거쳐 2006년 7월에 두번째 안을, 2007년 3월과 5월 각각 세 번째 안과 네 번째 안을 발표하였으며, 지난 2007년 6월 29일 마침내 공식적으로 GPL 3.0을 발표하였다.
GPL 3.0의 전체적인 체계를 보면, 서문을 제외하고 제0조부터 제17조까지 총 18개 조문으로 구성되어 있다. 이중 제4조 내지 제6조, 제8조 내지 제10조, 제12조, 제14조 내지 제17조는 기존의 GPL 2.0의 내용을 적절히 수정해서 재구성한 것이다. 새롭게 추가된 내용으로는 제0조 내지 제1조에서 각종 용어를 새로이 도입하거나 기존의 용어를 수정하였으며, 제3조를 중심으로 DRM과 관련된 내용이 추가되었다. 또한 오픈소스소프트웨어 라이선스의 급격한 증가와 양립성 문제를 완화하고자 제7조에서 GPL에 부가적인 조건을 추가할 수 있도록 규정하고 있다. 아울러 제11조 등은 소프트웨어특허문제, 제13조에서는 Affero GPL과의 양립성문제에 대처하고자 새롭게 추가된 내용이다.
GPL의 개정과정에서 가장 논란이 되었던 내용은 DRM(또는 ‘Tivoization’) 관련 쟁점, 특허권의 취급, 오픈소스라이선스간 양립성, 네트워크서버형태로 GPL 소프트웨어를 이용하는 경우의 처리 등이다. 이 밖에 소스코드의 범위를 명확히 하고, 새로운 용어를 정의하는 등의 수정이 있었다.
미국의 Tivo라는 회사는 케이블방송 또는 위성방송 등의 방송프로그램을 하드디스크에 녹화하거나, 경우에 따라서는 개인 PC나 DVD 등에 저장할 수 있도록 하는 DVR(digital video recorder)제품을 시장에 출시하여 성공하였다. 한편 해당 제품에는 리눅스커널 등 GPL 소프트웨어가 포함되어 있었기 때문에 Tivo는 GPL 2.0의 규정에 따라 관련 소스코드를 이용자들에게 제공하였다. 그런데 일부 이용자들이 해당 소스코드를 수정하여 다시 Tivo의 제품에 포팅하였으나 정상작동하지 않았다. 이는 Tivo사가 이용자들이 해당 제품을 수정하여 사용하는 것을 허용하지 않았기 때문이다.
이상과 같은 Tivo의 정책에 대해 스톨만은 Tivo가 GPL을 악용하고 있다고 주장하였다. GPL의 근본 목적은 이용자들이 해당 소프트웨어를 자유롭게 수정하여 사용할 수 있도록 하는 것임에도 불구하고 Tivo는 이를 막고 있다는 것이다. 스톨만은 이와 같은 GPL의 남용행위를 Tivoization이라고 이름짓고, 이를 방지하기 위해 GPL 3.0에 다음과 같은 2가지 종류의 규정을 마련하였다.
첫 번째는 GPL 코드를 특정한 사용자제품(User Product)에 포함시키거나 혹은 그와 함께 배포하는 경우에는 해당 소스에 설치 정보(Installation Information)를 함께 제공해야 한다는 것이다. 이 때 ‘사용자 제품(User Product)’이란 통상적인 소비자 제품이나 집안에서 쓰일 목적으로 설계되었거나 판매되는 제품을 말하며, ‘설치 정보(Installation Information)'란 소프트웨어를 수정하여 해당 제품에 설치하고 실행하는 데 필요한 방법(methods), 절차(procedures), 인증키(authorization keys) 혹은 여타 정보 모두를 의미한다. 다만 소프트웨어가 ROM에 설치된 경우처럼, 해당제품의 제조업체나 여타 제3자도 수정된 코드를 제품에 설치할 수 없는 경우에는 설치정보를 제공하지 않아도 된다. 또한 사용자가 설치하거나 수정한 저작물 및 해당 제품에 대한 지원서비스나 보증, 업데이트를 계속해서 제공할 필요는 없다. 그리고 사용자의 수정으로 인해 네트워크의 작동에 실질적이고 부정적인 영향을 끼치거나, 네트워크를 통한 통신 규칙 및 프로토콜을 위반하는 경우에는 네트워크에 대한 접속을 거부할 수 있다.
사용자제품에 대한 GPL 3.0의 현행규정은 초안에서의 내용보다는 상당히 완화된 것이다. 개정 과정에서 리누스 토발즈를 포함한 리눅스커널 개발자들은 DRM 기술이 미디어기업들에 의해 남용될 가능성이 있다는 점은 인정하지만, GPL 3.0의 DRM 관련 규정을 적용하게 될 경우 최종이용자에 대한 제한을 포함하는 어떠한 라이선스도 받지 못하는 결과를 초래할 것이라고 주장하였다. 또한 어떠한 행위가 GPL의 남용에 해당하는지를 결정하는 것은 본질적으로 정치적인 문제인데, 정치적인 목적 때문에 FSF가 저작권을 가진 프로그램을 GPL 3.0으로 전환할 경우 FSF 스스로 신뢰를 깨뜨리는 것이라고 주장하였었다. 결국 이와 같은 비판을 어느 정도 수용하여 현행규정으로 수정한 것이다.
Tivo와 관련하여 GPL 3.0에 도입된 두 번째 규정은, DRM과 관련하여 각국의 법률에 의해 보호되는 이익을 포기하도록 한 것이다. DRM은 ”Digital Rights Management"의 약칭으로 콘텐츠 제공자의 권리와 이익을 안전하게 보호하기 위하여 적법한 사용자만 허용된 사용권한에 따라 콘텐츠를 사용하도록 하는 기술이다. 그러나 다른 한편으로 DRM은 이용자의 행위를 제한하는 측면이 있는데, GPL 3.0의 첫 번째 토론안에서는 이와 같은 측면을 강조하여 DRM 관련 규정의 제목을 “Digital Restrictions Management"로 표기했었다. FSF는 미국, 유럽 기타 각국이 DRM 기술을 회피하는 행위에 대해 민사책임을 부과하거나, 심지어 형사처벌을 하도록 하는 법률을 제정하는 것에 대해 비판해 왔다. 아울러 이용자들의 자유를 보호하는 것을 최우선의 목표로 하고 있는 GPL 프로그램이 이와 같은 DRM으로 사용되고 있다는 것에 심각한 우려를 표명하였다. 이와 같은 FSF의 GPL에 대한 반감은, 결국 현행 규정과 같이 GPL 3.0이 적용되는 프로그램을 포함한 DRM은 법적 보호를 받지 못하도록 하는 결과로 나타났다.
오픈소스소프트웨어, 특히 FSF 등 자유소프트웨어(Free Software)진영이 소프트웨어특허에 대해 가지는 시각은 GPL 서문에 잘 나타나 있다. 이에 따르면 현재 소프트웨어특허로 인하여 자유소프트웨어가 끊임없이 위협을 받고 있는 상황이며, 만약 자유소프트웨어의 배포자들이 개별적으로 특허를 취득하는 경우 해당 프로그램이 사유(proprietary)소프트웨어가 될 가능성이 있으므로, FSF는 이러한 문제에 대처하기 위해서 GPL 조건의 소프트웨어를 이용하는 모든 사람들이 무료로 자유롭게 사용할 수 있는 특허만을 자유소프트웨어에 포함시키고자 한다는 것이다. 이와 같은 기본인식에도 불구하고 GPL 2.0에는 특허권에 관한 내용이 짧게 언급되어 있을 뿐인데, 비록 자유소프트웨어진영이 소프트웨어특허에 대해 반대하고 있긴 하지만, 소프트웨어특허의 인정여부는 결국 각국의 입법 또는 법해석에 관한 문제이다. 따라서 GPL의 차원에서는 GPL 조건의 소프트웨어에 관련 특허가 부여되었거나 앞으로 부여될 수 있다는 현실을 받아들일 수밖에 없다. 특허권에 관한 GPL 2.0에서의 내용을 요약하면, 첫째, 특허권자 자신이 특허기술을 구현한 소프트웨어를 GPL로 배포하였다면, GPL 서문이나 제7조의 해석상, GPL 조건을 준수하면서 해당 소프트웨어를 사용하는 이용자에게는 특허권을 주장하지 않겠다는 서약을 한 것으로, 또는 특허라이선스를 묵시적으로 허락한 것으로 해석할 수 있다. 둘째, 소프트웨어에 제3자의 특허기술이 포함된 경우, 특허권자가 모든 GPL 이용자에게 무상의 라이선스를 제공하는 경우에만 해당 소프트웨어를 GPL로 배포할 수 있다. 다시 말해 프로그램의 복제물을 제공받은 임의의 제3자가 해당 프로그램을 무상으로(royalty-free) 사용하거나 재배포할 수 없는 경우, 해당 소프트웨어를 GPL로 배포하는 것은 불가능하다.
1980년대 이후 미국을 중심으로 소프트웨어를 특허권에 의해 보호하려는 경향이 높아졌으며, 특히 1990년대 후반부터 소프트웨어관련 특허권의 수가 급격히 증가하였다. 그에 따라 GPL 2.0의 한계를 지적하고 소프트웨어 특허에 대한 대책이 필요하다는 요구가 오픈소스소프트웨어 커뮤니티 내부에서 꾸준히 제기되었다. 이와 같은 문제제기는 GPL 3.0으로의 개정과정에서 다양한 논의로 연결되었으며, 가장 많은 논쟁과 수정안의 제출로 이러졌다. GPL 3.0에서의 특허권에 관한 논의와 주요내용은 ⅰ) 라이선서 등 전방(upstream)의 특허권, ⅱ) 라이선시 등 후방(downstream)의 특허권, 기타 ⅲ) 제3자가 가지는 특허권의 경우로 나누어 볼 수 있다.
첫째, 라이선서 등이 특허권에 의한 소송을 제기할 수 있는 위험과 관련하여, GPL 2.0에서는 명시적 규정을 두고 있지는 않았지만 제7조 등의 해석상 라이선서가 자신이 가지는 특허권을 ‘묵시적으로’ 허락하는 것으로 해석할 수 있음은 앞에서 본 바와 같다. 하지만 미국법상으로는 이러한 해석이 가능하지만, 모든 국가가 그와 같지는 않을 것이라는 의견이 있었다. 이러한 문제제기를 받아들여 GPL 3.0은 기여자(Contributor)의 경우 자신이 기여한 부분(Contributor Version)에 대해서는, 비차별적이고 무료인 (non-exclusive and free royalty) 특허 라이선스를 허락하는 것으로 규정하였다.
개정과정에서 이와 관련하여 가장 쟁점이 되었던 부분은, 개발자 및 기여자이외에 GPL 프로그램의 단순한 재배포자(distributor)도 동 규정의 범위에 포함시킬 것인가의 여부에 관한 것이었다. 두 번째 안에서는 단순 배포자도 무료의 특허라이선스를 허락하는 것으로 명시적으로 규정했었다. 하지만 이에 대해 특히 대규모 특허 포트폴리오를 가진 일부 기업들이 자사가 가진 소프트웨어특허 포트폴리오 전체에 대한 권리를 상실할 가능성이 있다는 문제점을 지적하였다. 이와 같은 의견이 일부 반영되어 세 번째 토론안부터는 현재와 같이 기여자만 특허라이선스를 허락하는 것으로 규정하고 단순 배포자는 제외되었다. 두 번째는 라이선시 등으로부터 특허소송이 제기되는 경우인데, 이와 같은 경우를 다루고 있는 라이선스 조항을 통상 특허보복(Patent Retaliation)조항이라고도 한다. 예컨대 애플의 경우, Apple Public Source License에 의해 배포되는 프로그램을 사용하는 이용자가, 애플이 먼저 특허소송을 제기하지 않았음에도, 애플에 대해 특허소송을 제기하는 경우에는 아무런 통지 없이 라이선스가 자동으로 종료된다. 이와는 달리 Apache License 2.0의 경우는, 상대방에 대한 반소제기 등 방어의 목적인지 여부와 상관없이, 아파치라이선스 프로그램을 사용하는 어떠한 이용자에 대해서 특허소송을 제기하는 경우, 소송을 제기한 날에 해당 라이선스가 종료하는 것으로 규정하고 있다.
이와 같은 특허보복조항의 필요성은 브루스 페렌스 등을 중심으로 오픈소스커뮤니티 내부에서 일찍부터 제기되었었다. 하지만 스톨만 등은 특허보복조항의 실효성에 의문을 제기하였으며, GPL 3.0의 두 번째 안에서는, 네트워크서버형태의 이용자에 대한 제한적인 보복조항을 도입하고, 일반적인 보복조항은 이용자들의 선택사항의 하나로 규정하는데 그쳤다. 그런데 이용자들의 선택사항을 규정한 조항(제7조)에 대한 배포판업체들의 비판, Apache License 2.0과의 양립성 등을 고려하여, 세 번째 안부터는 이용자들의 특허침해소송을 제10조 후단의 추가적인 제한(further restrictions)으로 규정함으로써, 일반적인 특허보복조항을 도입하는 것으로 결론내렸다.
세 번째는 라이선서와 라이선시의 관계에 있지 않는 제3자가 특허권을 소유하고 있는 경우이다. 이와 같은 경우 라이선스규정을 통해 해결할 수 있는 문제는 별로 없으며, 소프트웨어 특허에 관한 정책 또는 법해석의 문제로 귀결된다. 그래서 FSF는 GPL 2.0에서와 같이 GPL 3.0에서도 서문(Preamble)을 통해 소프트웨어 특허의 위험성을 지적하고 각국이 소프트웨어 특허의 부여를 제한할 것을 주장하고 있다. 또한 GPL 2.0 제7조의 규정을 제12조에 그대로 위치시키면서, 모든 이용자가 GPL의 조건에 따라 프로그램을 이용할 수 있도록 하는 것이 불가능할 경우에는 제3자의 특허권을 구현한 프로그램을 GPL로 배포할 수 없도록 하고 있다. 그런데 GPL 2.0의 특허규정을 엄격하게 요구하는 것은 현실적으로 어려움이 있다. 예를 들어 리눅스커널의 경우 (특정업체의 조사결과에 따르면) 미국특허 수백개가 관련되어 있는데, 각각의 특허에 대해 무료 라이선스를 취득하는 것은 불가능에 가깝다고 볼 수 있다. 특히 수백개의 GPL 프로그램들을 배포하는 GNU/리눅스 배포판업체들의 경우에는 더더욱 그러하다고 볼 수 있다. 이와 같은 현실적인 어려움을 받아들여 GPL 3.0은, 배포자가 제3자의 특허가 포함되어 있다는 사실을 알더라도, ⅰ) 공중이 이용가능한 네트워크 서버 등을 통해 무료로 관련 소스코드를 복제할 수 있도록 하거나, ⅱ) 해당 프로그램에 대하여, 본인에게 주어진 특허라이선스의 혜택을 스스로 박탈하거나, ⅲ) GPL의 요구사항에 부합하는 특허라이선스를 후방 이용자(downstream users)에게도 허락하는 경우에는, 제3자의 특허가 포함된 GPL 프로그램을 배포할 수 있다.
한편 개정과정의 후반부에서 가장 이슈가 되었던 사항은 MS와 노벨의 특허관련 협약의 체결과, 이와 같은 협약을 막기 위한 조항을 GPL에 도입하는 것이었다. MS는 최근 들어 계속해서 리눅스를 비롯한 오픈소스소프트웨어가 자사의 특허권들을 침해하고 있다고 주장하고 있다. 하지만 현실적으로 다수의 오픈소스소프트웨어관련 기업들을 상대로 소송을 제기하는 것이 쉽지 않으며, 여론도 무시할 수 없는 상황이다. 결국 노벨 등 일부 이해관계가 맞는 기업들을 중심으로 협약을 체결하는 형태로 오픈소스커뮤니티에서 자사의 특허를 인정(?)받고자 노력하고 있다. 이에 대해 스톨만은 MS의 이와 같은 차별적인(discriminatory) 특허라이선스가 부당하다고 판단하고 이를 막기 위한 조항을 규정을 마련하였다. 핵심 내용은 GPL 프로그램과 관련하여 특정인에게 특허라이선스를 허락하는 경우 후방 라이선시들에게도 특허라이선스가 자동적으로 주어진다는 것과, 차별적인 특허라이선스를 체결하는 경우 GPL 프로그램을 배포할 수 없도록 하는 것이다. 그러나 동 조항이 구체적으로 어떠한 의미를 지니는지, 차별적 특허라이선스협정과 포괄적인 크로스라이선스협정의 구별기준이 무엇인지 등 많은 의문이 제기되고 있으며, FSF(또는 소프트웨어자유법센터:SFLC)는 이에 관한 명확한 답변을 하지 못하고 있다. 동 조항이 GPL 3.0에 포함된 이후 삼성전자와 LG전자가 각각 MS와 특허크로스라이선스협정을 체결했다. 국내 기업들의 이와 같은 협정들이 GPL 3.0에서 금지하고 있는 협정에 해당하는지의 여부에 대한 분석도 필요한 시점이다.
소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이선스가 상호 상충되는 경우가 있다. 예컨대 MPL 조건의 A코드와 GPL 조건의 B코드를 결합하여 ‘A+B’라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 ‘A+B’의 A부분을 MPL로 배포할 것을 요구하는 반면, GPL은 ‘A+B’ 전체를 GPL로 배포할 것을 요구하기 때문에, 두 라이선스의 요구조건을 모두 충족하면서 ‘A+B’프로그램을 배포하는 것은 불가능하다. 이러한 문제를 가리켜 라이선스의 양립성(Compatibility) 문제라고 한다. 따라서 어떤 오픈소스 소프트웨어에 다른 오픈소스 소프트웨어를 섞을 경우 반드시 두개의 라이선스가 서로 양립하는지를 확인하여야 한다. 양립성문제는 오픈소스소프트웨어 진영에 심각한 문제점을 제기하였으며, 이를 해결하기 위한 노력도 다양하게 진행되고 있다. 예를 들어 모질라 프로젝트(Mozilla.org)에서는 프로젝트의 결과물을 MPL, GPL, LGPL의 3가지(triple) 라이선스로 배포하는 라이선스 정책을 채택하여, 라이선스의 양립성과 관련된 불확실성을 제거하고 모질라 코드를 GPL 또는 LGPL 기반의 응용프로그램에 사용할 수 있도록 하였다. Trolltech도 Qt 라이브러리에 대한 오픈소스소프트웨어라이선스인 QPL과 GPL의 양립성 문제를 해결하기 위하여 QPL 및 상용라이선스 이외에 GPL을 추가하는 정책을 취하고 있다.
오픈소스 라이선스의 양립성문제는 주로 GPL 조건의 엄격성 때문에 나타난다. GPL 3.0의 초기버전에서는 이러한 양립성 문제를 해결하기 위해 이용자들이 추가적인 제한/허용 조건을 선택할 수 있도록 폭넓게 규정했었다. 예를 들어 특허보복조항의 포함여부, 네트워크서버형태로 이용하는 경우 소스코드를 제공하게 할 것인지의 여부 등을 개별적으로 선택할 수 있도록 하였다. 그러나 GNU/리눅스 배포판업체들은 오픈소스소프트웨어 라이선스들의 증가와 그에 따른 양립성문제는 인정하지만, 추가적인 제한/허용 규정에 의해 수많은 프로그램들이 서로 다른 GPL 조건들을 가질 경우, 라이선싱과 관련된 문제들이 더욱 복잡하게 될 것이라고 주장하였다. 이러한 비판을 어느 정도 수용하여 현행규정은 앞에서 살펴본 것처럼 특허보복조항을 제10조에 포함시키고, 네트워크서버형태의 이용과 관련해서는 제14조를 별도로 만드는 등 보다 단순화하였다. 또한 이러한 조치를 통해 GPL 3.0은 Apache License 2.0과 양립가능하며, 네트워크서버형태로 이용하는 경우에도 소스코드를 제공하도록 요구하는 Affero GPL 3.0(안)과도 양립가능하게 되었다.
일반적으로 하나의 라이선스가 전세계적으로 동일하게 사용되는 경우는 드물다. 라이선서(licensor)가 시장을 지역적으로 구분하고자 하는 전략적인 이유도 있겠지만, 각국마다 저작권법 등의 법제도가 상이하기 때문이다. 그래서 라이선서는 각국에 적합한 라이선스를 따로 만들어서 배포하게 된다. GPL 2.0은 일반적인 상용라이선스와는 다르긴 하지만, 어디까지나 미국의 법체계를 기반으로 만들어진 것이 틀림없다. 사용되는 용어에서나 워런티, 책임의 제한 등에 관한 내용이 이를 잘 말해주고 있다. 그렇지만 오픈소스소프트웨어가 전세계적으로 사용되고 있는 현재, GPL이 미국이외의 지역에서 하나의 라이선스로 사용되기 위한 변화가 필요하다. 이를 반영하여 GPL 3.0에서는 용어를 새롭게 정의하거나 추가하고 있다. 특히 중요한 용어로는 “propagate"와 ”convey"이다. 어떤 저작물을 “프로퍼게이트(propagate)”하는 것은, 저작권자의 허가를 받지 않고 어떠한 행위를 하는 경우 저작권을 위반하게 되는 모든 행위를 의미한다. 예를 들어 저작물을 복제, 배포, 전시하는 등의 행위를 포함한다. 다만 하나의 컴퓨터에서 단순 실행하거나 개인적으로 복제 또는 수정하는 것은 제외한다. 두 번째로 저작물을 “컨베이(convey)”하는 것은 제3자가 복사본을 제작하거나 받을 수 있도록 가능케 해주는 모든 종류의 프로퍼게이트 행위를 의미한다. GPL 2.0의 배포(distribution)에 해당하는 개념인데, 각국의 저작권법에서 배포의 범위가 다르고, 일부 지역에서는 ”공중에의 전달(communicating to the public)" 등 다른 표현을 사용하는 등 혼동을 가져올 수 있기 때문에 새롭게 정의하게 된 것이다. 다만 컴퓨터 네트워크를 통해 사용자와 상호작용하는 것은 컨베이가 아니다.
오픈소스 라이선스 중에서 GPL/LGPL/MPL 등은 수정한 내용에 대한 소스코드를 공개하여야 하고 BSD/Apache License 등은 수정하더라도 소스코드를 공개할 의무가 발생하지 않는다. GPL/LGPL/MPL 등 소스코드 공개 의무가 발생하는 라이선스를 상호주의(reciprocal) 혹은 copyleft 라이선스라고 하며, 그 결과물이 원 소프트웨어의 2차적저작물(derivative work)일 경우 소스코드를 공개해야 한다. 그런데 소스코드의 공개범위를 기계적으로 판단할 수 있는 방법은 없으며 라이선스마다 서로 다르게 정의하고 있으므로 잘 판단하여야 한다. 특히 GPL과 관련하여 구체적으로 어떠한 경우가 2차적저작물에 해당하는지, 또는 독립된 프로그램에 해당하는지를 구별하는 것은 쉽지 않다. 결국 최종적으로는 법원의 판단에 의해 결정될 문제인데, FSF는 GPL FAQ에서 몇 가지의 구별기준을 제시하여 왔었다. 예를 들어 두개의 모듈이 동일한 실행파일에 포함되어 있거나 공유주소영역(shared address space)에서 링크되어 실행되도록 설계된 경우에는 전자에 포함되고, 2개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments 형태로 통신하는 경우에는 후자에 해당한다.
GPL 3.0에서는 소스코드의 공개범위와 관련하여 좀더 상세한 규정을 마련하였다. 동 규정에 의하여 공개할 범위에 포함되는 “해당 소스(Corresponding Source)”란, 목적코드를 생성, 설치, 그리고 (실행 가능한 작업물의 경우) 구동하고, 그 작업물을 수정하는데 필요한 모든 소스코드를 의미하며, 그 활동들을 제어하는 스크립트를 포함한다. 예를 들어 소스 파일과 연관된 인터페이스 정의 파일을 포함하고, 또한 프로그램의 다른 부분들과 그 서브프로그램 사이의 제어 흐름이나 밀접한 데이터 통신 등을 통해 프로그램이 특별히 필요로 하는, 동적 링크된 하위프로그램과 공용 라이브러리의 소스코드를 포함한다. 다만 프로그램의 시스템 라이브러리와 범용적인 툴 등은 포함하지 않는다. (KLDP 위키 번역 참조).
IBM의 극적인 탈출 거스너 회장의 빠르고 파격적인 구조조정…브랜드 이미지 획기적 개선 위기의 순간, 대반전 ①
기업 회생 스토리에는 한 가지 공통점이 있다. 최악의 순간에서 과감한 조치들이 신속하게 취해졌다는 사실이다. 생존의 마지막 기회를 놓치지 않는 것, 그것이 바로 ‘지옥에서 천당으로’의 대역전을 만들어 내는 비결이다. 어영부영하다가는 끝장이다. 이코노미스트는 국내외 기업들이 절체절명의 위기에서 극적으로 회생한 그 순간을 포착해 당시 상황을 재구성한 ‘위기의 순간, 대반전’을 연재한다.
관련사진
샘 팔미사노 현 IBM 회장(왼쪽)과 루이스 거스너 전 IBM 회장.
주주총회가 열리는 플로리다로 가는 비행기에 몸을 실은 루이스 거스너 IBM 회장은 초조했다. 1993년 4월은 그의 인생에서 가장 잔인한 달이었다. 그때까지 IBM은 아홉 분기 연속 적자를 내고 있었고, 한때 170달러를 돌파했던 주가는 48달러로 곤두박질해 있었다.
성난 주주들은 신임 회장을 혼내주겠다고 벼르며 플로리다로 속속 모여들고 있었다. 주주처럼 보이는 한 사람이 장내로 뛰어들었다. 그의 손에 들려 있는 포스터에는 이런 문구가 적혀있었다. ‘난 IBM에 속아 왔다!’주총에서 돌아와 책상 앞에 앉아 머리를 쥐어뜯으며 한참을 고민하던 거스너가 외쳤다.
“세상을 바라보는 장소로 책상만큼 나쁜 곳은 없다.” 그는 달력에 빼곡하게 스케줄을 써 넣은 다음 자리를 박차고 밖으로 나갔다.
토론해봐야 뾰족한 수 없을 걸
CFO인 제롬 요크도 전 세계 사업장을 돌아다녔다. 두 달 내내 발품을 판 요크는 거스너에게 충격적인 보고를 했다. 55%에 달하던 영업이익이 45%로 떨어져 있었다. 이유는 더 기가 막혔다. 영업비용이 경쟁사보다 11%나 더 지출되고 있었던 것이다. 거스너와 요크는 즉각 11개 분야에 걸쳐 30개가 넘는 비용 절감 프로젝트를 추진했다.
거스너는 이 프로젝트에 전 직원이 동참하라고 소리쳤다. 지시를 무시하거나 소극적인 태도를 보이면 누구라도 해고하겠다고 엄포를 놓았다. 해당 부서원들이 얼마나 비용을 쓰고 있는지 발표하는 동안 요크는 열심히 계산기를 두드렸다. 심지어 그 자리에서 비용 절감 방안을 내놓고 해당 부서로부터 그대로 실행하겠다는 약속을 받아내기도 했다.
볼멘소리를 하는 부서장들도 있었지만, 거스너는 “3년 안에 최대 70억 달러의 비용을 줄여야 한다”며 그들의 입을 막았다. 거스너는 ‘토론은 얼마든지 하라. 그러나 아마도 이것 말고 다른 대안은 없을 것’이라는 식으로 밀어붙였다. 거스너는 나락으로 떨어진 주가를 다시 끌어올리려면 회사를 월 스트리트 기준으로 운영해야 한다고 생각했다.
우선 임원들의 출퇴근 시간부터 뜯어고쳤다. 그때까지 IBM은 오전 9시 출근 오후 5시 퇴근이었는데, 이것은 거스너가 보기에 월 스트리트의 패턴과는 전혀 맞지 않았다. 거스너는 자신은 물론 이사들의 시간표부터 바꾸었다. 그들은 이르면 새벽 5시에라도 나와 신문을 보고, 해외지사에서 들어오는 정보들을 샅샅이 훑어보며 9시 반 뉴욕증시가 개장될 때까지 신경을 곤두세웠다.
거스너는 미국에서만 4만 명, 해외지사에서 3만5000명을 내보내기로 이사진과 합의했다. 그것은 IBM의 전통 같은 ‘종신고용 원칙’을 폐기하는 선언이나 다름없었다. 엄청난 규모에 비해 결단은 빨랐다. 전임 회장 에이커스처럼 단계적인 감원이 아니라 일시에 이루어졌기에 충격이 컸다.
당시 거스너는 이렇게 위로(?)했다. “한 번 크게 얻어맞는 것이 계속 이마에 물방울이 떨어지는 고문보다 덜 고통스럽다.” 위로를 했는지 모르지만 위로금은 후하지 못했다. 고작 26주치 월급과 6개월치 의료보험료를 떠나는 직원의 손에 쥐어줬을 뿐이다. 에이커스가 2년치 월급을 주었던 것에 비하면 인색하기 짝이 없었다.
물론 거스너는 에이커스의 그런 지나치게 후한 위로금이 IBM에 재앙을 가져왔다고 여기고 있었다. 너무나 빠른 속도로 이뤄진 감축이라 쫓겨나는 직원들은 고통을 느낄 겨를도 없었다. 임신 8개월의 한 여직원은 코카콜라 애틀랜타지사를 고객으로 유치한 성과로 포상금을 받은 지 5일 만에 해고됐는가 하면, 심지어 병원에 입원한 어느 직원은 뇌종양으로 혼수상태에 빠져 해고통지서를 읽지도 못했다.
남은 직원들도 당황하기는 마찬가지였다. 임금인상은 억제되고 이전의 풍족했던 복리후생비는 기대할 수 없었다. 한 순간에 IBM은 자신들이 알던 IBM이 아니었다. 떠난, 혹은 남은 직원들에게 거스너는 저승사자처럼 보였겠지만 거스너의 눈엔 이전의 IBM이 지옥으로 가는 줄도 모를 만큼 자만했던 것으로 보였다.
거스너와 요크는 효율이 떨어지는 곳을 색출해 냈다. 내부거래 시스템이 딱 걸렸다. 고객서비스 부서가 부품부서에서 부품을 구입하는데 그 구입가를 매번 협상하는 식이다. 회사 전체 손익에 아무런 영향도 주지 않는 불필요한 협상을 하느라 시간과 비용만 낭비하고 있었다.
더 큰 문제는 지사별 실적이 왜곡되고 있는 것이었다. 예컨대 IBM 일본지사가 현지 판매에서 적자를 보았을 경우, 생산한 부품을 본사에 비싼 값에 떠넘겨 손익을 맞추는 식이다. 요크는 이런 말도 안 되는 회계 시스템을 즉각 수정했다. 당시 요크는 “실적을 못 내는 지사나 사업 부문은 그만큼 월급도 줄어들 것”이라고 경고했다.
한 번 크게 얻어맞는 게 낫다
거스너와 요크는 해외지사를 완전히 통제하지 못하고 있음을 실감했다. 심지어 보고조차 제대로 받지 못하고 있었다. 4주마다 보고해야 할 손익대조표가 6주가 지나도 도착하지 않았다. 2주는 손익이 뒤바뀌기에 충분한 시간이다. 화가 난 요크는 아무리 사소한 물건을 구매하더라도 회계부서에 다 보고하도록 했다.
거스너는 마케팅 혁신을 위해 리처드 토먼을 퍼스널 시스템스 그룹 책임자로 영입했다. 토먼은 컴퓨터는 잘 몰랐지만, 탁월한 기업 투시력으로 얼마나 인력과 비용이 낭비되는지를 간파했다. 그는 부서통합을 추진했다. 예컨대 PC사업 부문에만 여섯 개의 연구소가 있었는데 중복되는 연구로 낭비되는 돈이 매년 수백만 달러에 달했다.
토먼은 미국과 전 세계에 흩어져 있는 연구소를 하나로 통합했다. 이어 토먼은 ‘싱크패드’라는 브랜드만 남기고 모든 PC 사업을 정리했다. 소비자가 잘 외우지도 못하고, 심지어 자동차 모델명이 아니냐는 소리까지 듣는 PS/1, 앰브러, PC300 같은 브랜드를 모두 시장에서 철수시켰다.
오스틴 사업장에서 올라온 빌 애밀리오는 PC 사업조직 재정비를 추진했다. 애밀리오는 3500개에 달하는 PC 사업 부문의 모든 제품을 깨알같이 적어놓은 홍보책자부터 전부 폐기시켰다. 거스너는 IBM에서만 30년을 근무하고 은퇴한 샘 앨버트를 만났다. 난국을 타개할 아이디어를 구하기 위해서였다. 앨버트가 말했다.
“IBM은 컴퓨터가 처음 세상에 나왔을 때 쓰던 용어를 아직도 그대로 사용한다. 그것은 최첨단 기계의 성능을 마력으로 표시하는 것처럼 어색한 일이다.”
거스너는 깨달음을 얻었다. 자신도 얼마 전, 연구소를 시찰하다가 한 연구원이 알아듣지도 못하는 전문용어로 한참을 설명하는 것을 예의상 듣고 왔던 터였다. 앨버트의 지적은 결국 IBM이 자만에 빠져 시대에 뒤떨어지고 고객으로부터도 멀어지고 있다는 것이었다. 거스너는 지사를 돌며 고객들과도 대화를 나누었다. 문제는 심각했다.
IBM의 영업자들은 많았지만, 정작 고객에게 신제품을 제대로 설명할 수 있는 영업자는 그리 많지 않았다. 심지어 고객으로부터 “HP나 컴팩은 제품 흥정에서 설치까지 2주면 충분하지만 IBM은 두 달 안에 담당자와 통화만 해도 아주 운이 좋은 것”이라는 치욕적인 얘기까지 들어야 했다.
거스너는 각 사업장에 “한 달 안에 우수 고객이라고 할 만한 사람들의 명단을 작성해 가져오라”고 지시했다. 유럽의 지사들로부터 시간이 촉박하다는 답변이 들어오자 진노하며 “기한까지 내 책상에 명단을 가져오지 못하는 사람들에겐 더 이상 일을 시키지 않겠다”고 엄포를 놓았다.
거스너는 취임하자마자 이사진을 교체했다. 당시 이사들 중에는 전임 회장 에이커스와의 친분으로 뽑은 사람과 다른 회사 CEO로 있다가 은퇴 후 온 이들이 여럿 있었는데 대부분 IBM이 추구해야 할 첨단 기술과는 거리가 먼 사람들이었다. 거스너는 전문성을 갖춘 새 이사진에게 비(非)핵심 사업 부문을 솎아내도록 했다.
이사진은 금융 자회사인 IBM 크레디트 코퍼레이션을 우선 지목했다. 고객이 하드웨어 장비를 할부로 구입할 수 있도록 지원하는 자회사인데 가뜩이나 좋지 못한 자금 흐름을 악화시키는 주범이었다. 하지만 거스너는 이를 살려두기로 했다. 나중에 IBM이 대형 고객을 유치할 때는 매우 중요한 역할을 할 것이란 가능성을 보았기 때문이다.
대신 방위사업 자회사인 페더럴 시스템스 컴퍼니는 매각을 결정했다. 이 회사는 미 연방항공국으로 25억 달러에 달하는 시스템 업그레이드 작업을 수주해 놓은 상태였지만 IBM의 장기적 성장 관점에서 비 핵심사업으로 분류한 것이다. 오히려 당시 높은 값을 받을 수 있었기에 서둘러 팔아치웠다.
거스너는 이처럼 장기적으로 IBM의 성장에 도움이 되는 사업들로 구조조정의 가닥을 잡았다. 거스너는 IBM의 브랜드 이미지가 실추되고 조롱당하고 있는 것을 참을 수 없었다. 거스너는 애비 컨스탬을 부사장으로 임명하고 전 세계에서 진행되던 광고를 혁신하라고 지시했다. 컨스탬은 특단의 해결책을 제안했다.
각각의 제품에 대한 광고를 수십 개의 광고대행사에 맡겼던 것을 하나의 광고대행사에 전담시키는 것이었다. 그것은 광고업계를 흥분시키기에 충분했다. 컨스탬은 IBM의 모든 광고를 도맡아 줄 대행사를 조용히 수소문했지만, 이미 내로라하는 광고대행사들은 이미 수 주 전에 돌입해 있었다. 결국 마이크로소프트의 광고를 맡고 있던 오길비 앤 매더가 낙점됐다.
무엇을 남기고, 무엇을 버릴까
오길비는 마이크로소프트와 계약을 파기해야만 했다. 경쟁사 광고를 맡을 수 없도록 돼 있었기 때문이다. 오길비가 잘나가는 마이크로소프트를 포기하고 추락한 IBM을 선택한 이유는 5억 달러라는 엄청난 수주 금액 때문이다. 실제로 ‘뉴욕타임스’ 1면에 ‘광고업계 최대 계약’이란 제목의 기사가 실렸다.
오길비의 북미지역 총괄책임자인 셸리 레저러스가 빌 게이츠를 만나 “더 이상 마이크로소프트의 일을 할 수 없을 것 같다”고 말했다. 빌 게이츠는 “혹시 우리 회사와 무슨 문제가 있었느냐”고 아무렇지도 않은 듯 반문했지만, 그것은 ‘IBM 같은 회사의 일을 하기 위해 마이크로소프트를 버리느냐’는 의아함을 표시한 것이었다.
빌 게이츠가 불쾌했던 만큼 거스너에겐 통쾌한 일이었다. 그리고 그것은 광고를 한 대행사에 몰아주겠다는 파격적인 아이디어가 없었다면 불가능했던 일이다. 광고 제작에 앞서 시장조사를 한 결과 IBM의 이미지는 우려했던 것보다 훨씬 나빴다. 심지어 조사기관에서 “응답자들의 IBM에 대한 반감이 너무나 커 조사를 더 이상 진행하기 힘들다”는 얘기까지 나올 지경이었다.
그럴수록 국면을 확실하게 바꾸어 줄 파격적인 광고가 절실했다. 거스너가 정해둔 마감시간이 다가오는데도 이렇다 할 대안을 못 내놓던 오길비는 한 가지 결론에 도달한다. IBM의 인지도 자체가 아닌 ‘IBM이 변하고 있다’는 사실을 전달하자는 것이었다. 수녀들을 등장시켜 영어가 아닌 체코어로 IBM PC를 소개하는 파격적인 CF는 바로 그렇게 탄생한 것이다.
이 CF가 완성되는 과정에서 특히 광고 마지막 부분에 들어간 문구는 이전의 ‘잘난 체하고 오만한’ IBM의 이미지를 개선하는 데 결정적인 역할을 했다. 처음엔 ‘컴퓨터로 세계가 좁아지고 있는 시대에 컴퓨터 사용자들이 겪는 고통을 해결해 주는 기업이 되겠다’는 의미를 담아 ‘작은 세상, 그 해답’이라는 문구를 광고에 덧붙였다.
그것을 거스너가 ‘세상의 해답’으로 최종 수정해 내보냈다. 기술이 뛰어나다 자랑하는 것이 아니라 문제를 해결하기 위해 겸허한 기업정신으로 일한다는 느낌을 주었다는 평가를 받았다. 극적으로 탈출에 성공한 IBM은 4년 후인 1997년 미국 내에서 매출액 기준 6위에 랭크됐고, 주가는 사상 최고치인 177달러를 넘어서기도 했다.
숫자로 본 IBM 위기탈출 순간
48달러 = 한때 170달러를 돌파했던 IBM 주가는 1993년 4월 주총 당시 48달러로 폭락했다. 2300명 = 주주총회장엔 평소의 3배가 넘는 주주들이 무능한 경영진을 벼르고 있었다. 45% = 55%에 달하던 전 세계 IBM 사업장의 영업이익률은 무려 10%나 빠져 있었다. 11% = 영업비용이 통제되지 않아 경쟁사보다 11%나 과다지출되고 있었다. 30개 = 거스너 회장은 11개 분야에 걸쳐 30개가 넘는 비용절감 프로젝트를 즉각 추진했다. 70억 달러 = 3년 내 70억 달러의 비용을 절감한다는 목표를 잡았다. 5시 = 거스너는 오전 9시 출근하던 임원들을 새벽 5시에 출근하도록 했다. 8만 명 = 미국 내 4만~5만 명, 해외 사업장 3만5000명 이상을 정리해고하기로 했다. 26주치 = 2년치 월급을 주던 퇴직 위로금을 26주치로 삭감해 지급했다. 6개월 = 직원 업무평가 등급을 상·중·하로 나눠 ‘하’를 받은 직원은 6개월 정직에 처했다. 20일 = 전 세계 사업장에 20일 내에 우수고객명단을 작성해 제출토록 했다. 5억 달러 = 전 세계 수십 개 광고대행사에 맡겼던 광고를 오길비에 몰아줘 경쟁사 MS를 따돌렸다. 플러스 3억8200만 달러 = 92년 4분기 54억 달러의 적자를 냈던 IBM이 93년 4분기에 흑자로 돌아섰다.
CPU 성능(performance)은 임의의 application의 수행시간에 반비례한다. cpu excution time은 곧 명령어의 개수를 의미하며, 이는 순수하게 임의의 application이 cpu를 사용한 시간을 뜻한다.
CPU time을 결정하는 세 개의 요소로는 instruction의 개수, CPI, Period가 있으며 다음과 같이 계산한다. CPU time = 초/program = instructions/program * clocks/instruction * seconds/clock = # of instruction * CPI * Clock rate(Period)
instruction의 개수: 프로그램의 크기와는 관계가 없으며 순수하게 수행되는 명령어의 개수이다.
CPI: 명령어마다 다르므로 대개는 average로 한다.
Clock rate: cycle하나당 걸리는 시간
성능을 좋게 하기 위해서는 CPU time을 줄여야 하는데, 이는 곧 위의 식에서 보는 바와 같이 # of instruction이나 CPI, Clock rate를 줄이면 된다. 이러한 요인들로 하여금 CPU time을 줄이는 방법은 다음과 같다.
동작 clock을 빠르게 한다. (Clock rate를 줄인다)
성능 좋은 컴파일러를 사용하거나 좋은 알고리즘을 이용하여 프로그래밍한다. (# of instruction을 줄인다)
pipelining등의 기법을 사용한다.(CPI를 줄인다)
또한, CPU 성능을 높이기 위한 것으로 다음과 같은 기법들을 사용할 수 있다.
Pilelining
한국어로 하면 '분업'을 뜻한다.
5단계 pilelining은 Instruction Fetch - Decode - Operand Fetch - Excute - Write Back 의 단계로 이루어진다.
각 단계에 필요한 resource가 따로있다.
resource를 효율적으로 사용하기 위한 방법으로 놀고있는 resource를 방지한다.
모두 clock에 동기화 되어 있어서 clock이 튈 때마다 다음 단계로 옮겨진다.
Super scalar
명령어 처리하는 모듈이 여러 개 있는 것으로, 모듈이 2개일 경우 2-way super scalar라고 한다.
dependency가 없는 여러 개의 명령어를 동시해 수행할 수 있게 한다. (2-way일 경우 2개 동시에 수행 가능)
dependency가 없는 명령어 set은 하드웨어가 찾아낸다.
3-way, 4-way, 5-way 등등으로 사용할 수 있다.
pilelining과 함께 사용하면 더더욱 성능이 증가된다.
VLIM(Very Long Instruction Word)
dependency가 없는 명령어를 하나의 명령어로 만들어 parellel하게 실행될 수 있는 것 끼리 묶는다.
super scalar와 비슷하게 보이지만 dependency가 없는 명령어 set을 compiler가 찾아내므로 소프트웨어적으로 체크한다는 점이 다르다.
CPU 성능을 측정하는 방법으로 두 가지 기준이 있다. 그 하나가 Response Time이고 나머지 하나가 Throughput이다.
Response Time: 프로그램 하나가 시작하면서부터 끝날 때까지의 시간
Througput: 단위시간 당 처리하는 일의 양 예를 들어서, CPU를 두 개로 늘린다면 Response Time에는 변화가 없으나 Througput은 증가할 것이다.
Section 1: Global Environment : 아파치 전체적인 영향이 미치는 설정 Section 2: 'Main' server configuration : 주 서버에 대한 설정 Section 3: Virtual Hosts : 가상 호스트에 대한 설정
자, 그럼 이제부터 이 아파치웹서버의 모든 환경을 설정하는 아파치환경파일 httpd.conf파일의 설정방법에 대해서 상세히 알아보도록 하자.
### Section 1: Global Environment
전제환경설정 파트로 Section 1에서 설정하는 것들은 아파치 웹서버에 전반적인 영향을 미친다.
ServerType standalone
서버의 구동방법으로는 standalone과 inetd방식이 있는데, standalone 방식은 하나의 웹데몬(아파치서버)이 클라이언트의 접속을 모두 처리하는 방식으로 응답속도가 빠른 방법으로 주로 이방식을 사용한다. inetd 방식은 inetd라는 시스템의 /etc디렉토리 끝에 존재하는 inetd라는 슈퍼데몬이 클라이언트의 접속요구가 있을 때마다 웹서버를 구동하는 방식이다. 일반적으로 응답속도가 빠르고 효율적인 standalone으로 설정하여 사용한다.
ServerRoot "/usr/local/apache"
아파치서버의 홈디렉토리를 지정하며 절대경로로 지정한다. 이후로 나오는 대부분의 패스들은 이 경로에 대한 상대경로로 지정이 된다. 예를 들어 환경설정파일, 에러로그파일등의 상대경로의 기준이 되는 위치이다.
LockFile logs/accept.lock
아파치 컴파일시 USE_FCNTL_SERIALIZED_ACCEPT나 USE_FLOCK_SERIALIZED_ACCEPT으로 컴파일 했을 때 사용되는 LockFile의 경로지정시에 사용된다. 가급적 기본값으로 사용한다.
PidFile logs/httpd.pid
PidFile 설정은 ServerType을 Standalone으로 설정했을때만 유효한 것으로 아파치 서버의 프로세스가 생성되어 있을 때 그 프로세서ID(PID)를 기록하는 파일을 지정한다. 당연히 아파치서버가 재시작되거나 과부하로 인해 PID가 바뀌게 될 경우에는 이 파일의 PID값도 바뀌게 된다. 즉 다시말해서 여기서 지정된 파일(httpd.pid)에 실행되고 있는 아파치서버의 프로세스번호(PID)값이 기록된다고 하면 정답이다. ServerRoot를 기준으로한 상대경로로 지정된다. 절대경로로 지정하려면 "/"로 시작하는 절대경로를 적어주면 된다.
아파치 서버의 환경설정파일은 3개이au httpd.conf, srm.conf, access.conf 가 그것이다. 그러나 하나의 설정파일로 하는 것이 효율적이기 때문에 지금은 httpd.conf파일안에 3개의 파트(Section)로 나누어서 하나의 파일안에서 설정을 하고 있다. srm.conf와 access.conf파일의 내용은 현재 비어있는 상태이지만, 필요하다면 이 파일 내에도 설정을 할 수 있다. 아파치 서버가 실행이 될 때는 httpd.conf, srm.conf, access.conf 순으로 언제나 이 3개의 파일을 모두 읽고 난뒤에 실행이 되기 때문이다. 만약 이 두 개의 파일을 서버가 무시하도록 하려면 다음과 같이 하거나 "#"으로 붙여 두면 주석처리되어 무시된다.
ResourceConfig /dev/null AccessConfig /dev/null
Timeout 300
클라이언트의 요청에 의해 서버와 연결이 되었을 때 클라이언트와 서버간에 아무런 메시지가 발생하지 않았을 때 오류로 처리될 시간을 초단위로 설정한다. 초기값은 1200이며 보통은 300초로 지정을 한다. 네트웍의 속도가 나쁠수록 수치값은 높게 설정하는 것이 좋다.
KeepAlive On
접속한 채로 특별한 요청없이 지속적인 연결을 허용할 것인지를 설정한다. 허용하지 않으려면 off
MaxKeepAliveRequests 100
클라이언트가 접속된 시간동안 아파치서버에 요청할 수 있는 최대의 개수를 지정한다. 0을 지정하면 제한없음을 의미하며, 서버의 성능향상을 위하여 가능한 높은 값이 좋다.
KeepAliveTimeout 15
아파치 서버는 같은 접속상태의 클라이언트에서 여기서 지정한 초만큼의 요청이 없었을 때 접속을 끊게 된다.
MinSpareServers 5 MaxSpareServers 10
아파치 웹서버는 성능향상과 빠른 응답속도를 위해 유휴서버(현재 서비스대기 중인 프로세스)를 만들게 되는데 이 유휴서버의 개수는 시스템의 상황에 따라 달라지게 된다. 유휴서버가 MinSpareServers의 개수(5) 보다 적게되면 추가로 생성을 하게 되며 MaxSpareServers의 개수(10)보다 많게 되면 죽이게 된다. 즉, 유휴서버의 개수를 적절히 조절하기 위한 것이라 생각하면 된다.
StartServers 5
아파치 웹데몬이 구동될 때 자식프로세스를 몇 개로 할 것인가를 지정한다. 시작할 때 동시에 띄우게 될 웹데몬의 개수이다. 그러나 웹데몬이 구동되고 난 뒤엔 시스템의 상황(부하율등)에 따라 대부분 합리적인 개수만큼 동적으로 생성되었다가 죽기도 하므로 큰 의미를 가지는 것은 아니다.
MaxClients 150
아파치웹서버에 접근할 수 있는 클라이언트의 최대갯수는 이 상한값으로 제한한다. 여기서 지정한 개수이상의 클라이언트의 요청이 생긴다면 아파치는 응답하지 않고 이 요청을 무시한다. 이를 제한하는 이유는 시스템의 자원을 아파치 웹서버가 무한정 차지하는 것을 방지하기 위한 것이다.
MaxRequestsPerChild 30
아파치 웹서버의 자식프로세스들이 클라이언트의 요청 개수를 지정한다. 만약 자식프로세스가 이 값만큼의 클라이언트요청을 받았다면 이 자식프로세스는 자동으로 죽게된다. 이 값이 0으로 설정이 된다면 자식프로세스가 자동으로 죽는일은 없을 것이다. 그러나 0아닌 다른 값으로 설정함으로서 프로세스의 수를 적절히 조절하여 시스템의 부하조절과 자원낭비를 어느정도 방지 할 수 있다.
Listen 3000 Listen 12.34.56.78:80
시스템의 기본값이외에 다른 IP Address와 포트에 대해서도 연결할 수 있도록 해 준다. 환경설정파일(httpd.conf) 맨뒤에 나오는 가상호스트(Virtual Host)부분에서 설정되는 가상호스트를 설정하기 위해 필요하다.
BindAddress *
서버가 응답할 수 있는 IP Address를 설정하는 것이다. 하나의 시스템에 있는 아파치웹서버 하나로 여러 웹서버처럼 관리하는 웹호스팅서비스등에서 많이 이용하는 것으로 여러 IP Address를 인식할 수 있게 한다. "*"으로 설정이 되었다면 모든 IP Address에 대해 응답할 수 있으며, IP Address를 지정한다면 지정한 IP Address에 대해서만 응답할 수 있게 된다. 여러개의 IP Address를 ISP로부터 할당받아서 웹호스팅서비스를 하고자 한다면 이부분에서 지정해 주면된다. 이 설정파일의 맨 뒷부분에 나오는 ~부분의 IP bind 가상호스트부분에서 아파치 웹서버가 응답할 수 있도록 하려면 여기서 IP Address를 지정해 줘야 한다.
ExtendedStatus On
server-status로 아파치웹서버의 상태를 상태를 모니터링 할 때 "자세한상태정보"기능을 제공할 것인지(On) 아닌지(Off)를 설정하는 것이다.
### Section 2: 'Main' server configuration
Section 2에서 설정하는 항목들은 아파치의 주된서버가 사용할 값들을 지정한다. 에 정의된 가상호스트들에서 지정하지 않는 것은 여기서 지정된 값이 기본값으로 적용된다. 또한 여기서 지정하는 값을 각 내에도 지정할 수 있으며 이경우엔 각내에서 지정한 값이 우선적용된다.
Port 80
아파치웹서버의 기본포트를 지정한다. 특별하게 사용하는 것이 아니라면 80번으로 해둬야 한다. 사용가능한 포트는 0 ~ 65535이며 1024이하의 포트번호는 시스템에서 특별하게 예약되어 있으므로 80번 이외의 다른 포트를 사용하려면 1024이상의 포트번호를 지정해서 사용해야 할 것이다. 특별한 지정이 없다면 에 정의된 각각의 가상호스트들의 기본포트가 된다. 만약 내에서 Port가 지정이 된다면 그 포트번호가 우선한다.
(특별히 PORT를 따로 지정해 줄 필요가 있을 때는 따로 지정해 주며, 이때는 웹서버로 접근할 때 반드시 따로지정한 PORT번호로 접근해야 한다. 예를들어 Port 1234로 지정했다면, 접근시 : http://www.domain.co.kr:1234 로 접속해야한다. 단, 80번은 default이므로 Port번호를 입력하지 않아도 도메인만으로 그냥 접근할 수 있다. 예: http://www.domain.co.kr )
User nobody Group nobody
아파치 웹데몬이 요청을 받았을 때 여기서 지정한 user와 group으로 응답을 하게된다. 이 설정은 ServerType이 Standalone방식이며, 아파치의 실행이 root권한으로 실행이 되었을 때 유효한 것이다. 많은 웹서버관리자들이 nobody로 설정을 해 두고 있으며, 만약 시스템에 nobody user가 없다면 새로생성(useradd)을 해야 할 것이다. 단, root로 설정하는 것은 절대로 있어서는 안되며 nobody이외의 다른 시스템사용자 id로 지정을 한다면 정말 신중히 모든면(시스템 보안 및 자원사용등)에서 깊게 고려를 해봐야 한다.
ServerAdmin webmaster@www.domain.co.kr
여기서 지정하는 email address는 웹문서 로딩에러등의 문제에서 클라이언트측으로 보내질 메일주소값이다. 대부분 웹서버관리자의 email address로 설정을 한다.
ServerName new.host.name
클라이언트에게 보여주는 호스트이름을 지정한다. www를 쓰지않는 호스트에서 www를 쓰는 것처럼 보이게 할 수 있다. 예를 들어 bbs.manualand.co.kr을 www.manualand.co.kr로 지정해서 쓸 수 있다. 이곳에 IP Address를 적게 되면 클라이언트에는 Ip Address를 보여준다.
DocumentRoot "/usr/local/apache/htdocs"
아파치 웹서버의 웹문서가 있는 경로를 지정한다. 예를 들어 "http://www.manualand.co.kr/index.html"의 초기 문서라면 이 초기문서의 절대 경로는 여기서 지정된 "/usr/local/apache/htdocs/index.html"이 된다. 경로의 맨 마지막에 "/"를 추가해서는 안된다. Alias를 사용하여 다른 위치를 지정할 수도 있다.
Options FollowSymLinks AllowOverride None
에서 지정되는 값에 대한 옵션은 다음과 같은 의미를 가지고 있다. None : 일단 모든허용을 하지 않는다. All : 모든허용을 한다. Indexes : Includes : FollowSymlinks : ExeCGI : MultiViews :
UserDir public_html
하나의 아파치 웹서버에서 여러 사용자의 홈페이지를 별도로 만들어 관리할 때 필요한 개별 가입자의 홈페이지 디렉토리이름이다. 예를 들어 sspark이란 계정가입자의홈페이지는 "http://manualand.co.kr/~sspark"라는 홈페이지를 가지고 있을 때 sspark의 계정에서 "public_html"이란 디렉토리가 홈디렉토리가 되어 이 디렉토리에 있는 초기문서 index.html을 불러서 보여주게 된다.
AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec Order allow,deny Allow from all
MOVE LOCK UNLOCK> Order deny,allow Deny from all
계정사용자의 홈페이지(public_html)의 접근에 대한 옵션을 지정한 것이다.
DirectoryIndex index.html
디렉토리만을 지정했을 경우에 그 디렉토리에서 찾게될 문서의 순서를 지정해 준다. 즉, 디렉토리 이름만을 지정하더라도 여기서 지정한 index.html을 찾아서 웹브라우즈에 보여준다. 여러개의 파일을 지정할 수 있으며, 이런 경우에는 순서대로 찾아서 보여준다. 예를 들어 "DirectoryIndex index.html index.htm"로 지정했다면 먼저 "index.html"을 찾아서 있다면 이 파일을 로딩하고, "index.html"이 없다면 "index.htm"을 찾아서 로딩해 준다.
AccessFileName .htaccess
디렉토리별로 접근제어할 정보(ID, Password)를 담고 있는 파일을 지정한다. 디렉토리별로 인증을 거쳐서 접근할 수 있는 설정을 하기위한 것이다. 예를 든다면 어떤 홈페이지의 전부나 혹은 일부에로 접근하려고 할 때 ID, Password를 묻는 창이 뜨면서 맞게 입력한 경우에만 접근허용하는 것이다. 보안상의 이유로 이 파일의 이름을 다른 이름으로 바꾸로 싶다면 ".htaccess"대신에 다름이름을 적어주면 된다.
Order allow,deny Deny from all
바로위에서 설정한 파일(".htaccess")의 내용을 볼 수 없게 할 때 사용하는 옵션이다. 보안상의 이유로 이 옵션은 설정해 두는 것이 좋다. 만약 이 옵션을 주석처리해 둔다면 ".htaccess"파일에 대한 보안은 누구도 장담할 수 없을 것이다.
UseCanonicalName On
TypesConfig conf/mime.types
웹서버의 mime type을 지정한 파일을 지정한다. mime.types파일은 서버에 의해 리턴될 수 있는 파일명과 mime형식을 기술해 놓은 파일이다.
DefaultType text/plain
mime.types 파일에 정의 되어있지 않은 파일형식에 대한 요청을 받았을 때 알 수 없는 문서타입에 대하여 사용할 기본적인 mime 타입을 정해둔다.
HostnameLookups Off
웹서버의 로그(access_log)를 지정하는 Format에서 "DNS Lookup"으로 지정하였을 때, domain으로 남길 것인가, IP Address로 남길 것인가를 지정한다. Default로 Off는 IP Address로 남기는 것이며, Domain으로 변경할 필요가 없으므로 on으로 설정한 것보다는 속도가 조금빠르다.on으로 하게 되면 IP address를 IP Domain으로 변환해야 하므로 속도가 조금 느릴 수 있다.
ErrorLog logs/error_log
아파치 웹서버의 에러로그 기록파일을 지정한다. 참고할 사항은 맨 마지막에 설정하는 부분에서 각서버에 대한 에러파일을 지정해 두지 않으면 그에 대한 에러로그도 여기에 기록되며, 지정해 두게 되면 그에 해당하는 로그는 이 파일에 기록되지 않는다.
LogLevel warn
바로위에서 설정한 에러로그 파일에 얼마나 자세하게 적을 것인지를 결정한다. 다음에 해당하는 순서대로 중요도가 정해진다. " debug → info → notice → warn → error → crit → alert → emerg "
바로 아래에서 사용할 CustomLog에서 사용할 몇가지 로그형식의 별명을 정한 곳이다. 웹서버의 관리자나 서버관리자는 이 부분을 특히 유심히 봐둬야 한다. 웹서버의 로그를 어떤 식으로 남길 것인가를 결정하는 Format을 지정하는 곳이다. 원하는 정보를 지정해서 볼 수 있으므로, 관리자에게 필요한 Format으로 설정해야 하며, 또한 접속통계를 내기에 적당한 Format으로 설정해 둬야 한다.
CustomLog logs/access_log common
위에서 정한 로그형식(여기선 common)대로 로그를 남기게 된다. 맨마지막에서 지정하는 부분에서도 아파치 1.3.9버전 부터는 CustomLog를 가상호스트별로 지정할수 있도록 CustomLog를 제공한다. 에서 CustomLog를 지정하지 않으면 여기서 지정한 형식대로 로그를 남기게 되며 부분에서 CustomLog를 지정했을 경우에는 여기서 지정한 로그형식은 무시된다.
위에서 지정한 4가지의 로그형식(combind, common, referer, agent)중에서 원하는 부분의 #(주석행)을 제거하면 지정된다.
ServerSignature On
서버가 생성하는 문서(error d0cuments, FTP directory listings, mod_status and mod_info output etc., but not CGI generated d0cuments)의 trailing footer line의 설정을 가능하게 한다.
Alias /icons/ "/usr/local/apache/icons/"
필요한 만큼의 디렉토리 별칭을 만들어 쓸 수 있다. 사용하는 형식은 다음과 같다. Alias fakename(가상이름) realname(진짜이름)
AddDescription은 서버가 생성한 인덱스의 파일 뒤에 간단한 설명을 표시할 때 사용한다. 이 설정은 IndexOptions가 FancyIndexing으로 설정되었을때만 표시되며, 설정형식은 다음과 같다. 형식 : AddDescription "표시할 설명" 파일확장자
ReadmeName README
ReadmeName은 디렉토리목록표시 뒤에 붙여서 보여줄 README파일의 이름을 지정한다.(일종의 꼬릿말)
HeaderName HEADER
HeaderName은 디렉토리목록표시 앞에 붙여질 파일의 이름을 지정한다. (일종의 머릿말)
SSI(Server Side Include)문서를 인식하게 하기위한 설정이다. SSI코드가 들어가 있는 문서는 확장자가 *.shtml이다. 시스템의 날짜와 카운터등 CGI프로그램을 하지 않아도 HTML문서에서 단 몇줄로 CGI의 효과를 낼 수 있는 SSI기능을 인식하게끔 하는 설정이다. "7장. 아파치와 SSI"편에서 자세히 설명되어 있다.
위의 3가지 설정은 기본적인 1.1반응도 처리하지 못하며 HTTP/1.0 스팩을 제한하고 있는 브라우즈에 대하여 HTTP/1.1반응을 하지 못하게 한 것이다.
SetHandler server-status Order deny,allow Deny from all Allow from www.manualand.co.kr
서버의 상태를 점검할 수 있게하는 설정이다. 이는 "http://www.manualand.co.kr/server-status"와 같은 형식으로 서버의 상태를 점검할 수 있다. "6장. 아파치서버 모니터링"편에서 자세히 설명되어 있다. 여기서 지정한 "SetHandler server-status"의 설정으로 인해 서버 모니터링을 할 수 있는 것이다.
SetHandler server-info Order deny,allow Deny from all Allow from www.manualand.co.kr
이설정을 위해서는 mod_info.c가 적재되어야 하며, 이는 "http://www.manualand.co.kr/server-info"와 같은 방식으로 서버의 정보를 볼 수 있다. 위에서 설정한 server-status와 함께 실행중인 웹서버의 상태점검을 위한 것이다.
Deny from all ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
아파치 1.1이전 버전의 오래된 버그에 대한 악용이 있을시에는 지정한곳 (http://phf.apache.org/phf_abuse_log.cgi) 으로 방향을 전환시킨다.
ProxyRequests On
아파치 웹서버를 Proxy서버로 사용할 때 on을 해줘야 한다. 즉 프락시서버 지시자로서 프락시서버를 on 시킨다.
Order deny,allow Deny from all Allow from .your_domain.com
ProxyVia On
HTTP/1.1 "Via:"헤드처리를 활성화시킬 것인지 비활성화 시킬것인지를 지정한다. Off, On, Full, Block중 하나가 올 수 있으며 Full은 서버버전을 포함하며, Block은 나가는 모든 것에 대해 Via:헤더를 제거한다.
여러분의 시스템에서 여러개의 도메인이나 호스트네임을 설정하여 관리하고자 한다면 부분을 설정해 줘야 한다. 가상호스트에 대한 정보는 http://www.apache.org/docs/vhosts/를 참조해 보면 좀더 자세한 정보를 얻을 수 있다. '-S'옵션을 사용함으로써 가상호스트의 설정에 대한 점검을 할 수 있다. name-based 가상호스트를 사용하길 원한다면 적어도 한 개이상의 IP Address를 정의할 필요가 있다. "4-2절의 내용"과 "10장.웹호스팅 서비스를 위한 가상호스트"편에서 자세히 설명되어 있다.
![[http]](http://wiki.kldp.org/imgs/http.png)
