GNU 프로젝트


리차드 스톨만





이 글은 처음에 "오픈 소스"라는 책에 포함되어 출판되었던 것입니다. 





 [ English | Italian | Korean | Russian | Spanish ] 

















소프트웨어를 공유했던 최초의 공동체


MIT 대학의 인공지능 연구소에서 일하기 시작했던 1971년부터 나는 소프트웨어를
공유하는 공동체의 일원이 되기 시작했다. 이 공동체는 이미 수년 전부터 존재하고
있던 것이었으며 MIT에만 유일하게 존재하는 특별한 것은 아니었다. 요리법을
공유하는 것이 요리의 역사만큼 오래된 것처럼, 소프트웨어를 공유하는 것은
컴퓨터의 역사만큼이나 오래된 것이었다. 그러나 우리들은 소프트웨어를 공유해
나가는 더욱 이상적인 우리들만의 공동체를 MIT에서 만들어 나갔다. 





인공지능 연구소에서는 ITS (Incompatible Time-sharing System)라고 불리는
시분할(time-sharing) 운영체제를 사용하고 있었는데, ITS는 당시에 사용되던 가장
큰 시스템 중의 하나인 DEC사의 PDP-10 기종에 탑재할 목적으로 인공지능 연구소의
(1)해커 연구원들에 의해서 어셈블리 언어로 만들어진 운영체제였다. 인공지능
연구소의 연구원으로서 그리고 공동체를 구성하고 있는 해커의 일원으로서 나는
ITS를 더 나은 시스템으로 만드는 일에 종사하고 있었다. 





우리는 우리들의 소프트웨어를 "자유 소프트웨어"라고 말하지는 않았다. 왜냐하면
그 당시까지만 해도 "자유 소프트웨어"라는 용어가 아직 존재하지 않았기
때문이다. 하지만 우리가 만들었던 소프트웨어의 모습는 지금의 "자유
소프트웨어"가 의미하는 바로 그것이었다. 다른 대학이나 기업에서 우리가 만든
프로그램을 사용하거나 다른 시스템으로 이식하기 위해서 우리에게 도움을 요청할
때면 우리는 언제든지 우리의 프로그램을 그들에게 빌려주었다. 이러한 형태는
매우 일반적인 것이어서 새롭고 흥미로운 프로그램을 사용하고 있는 사람을
발견했다면 언제든지 그 사람에게 프로그램의 소스 코드를 보여 달라고 요청할 수
있었다. 공동체의 시절 - 그 당시는 특정한 프로그램의 소스 코드를 자유롭게 얻을
수 있었기 때문에 프로그램을 수정하거나 그 프로그램을 기반으로 한 새로운
프로그램을 만들 수 있는 가능성이 언제든지 열려있었던 공유의 정신이 충만한
시절이었다. 





(1) 해커라는 단어가 시스템의 보안을 뚫고 들어가서 해악한 일을 저지르는
침범자의 의미로 사용되고 있는 현재의 관행은 대중 매체에 의해서 오도된 경향이
크다고 할 수 있다. 우리 해커들은 이 단어를 침범자라는 의미가 아닌 "프로그램을
만들기 좋아하고 능숙하게 다룰 수 있는, 즉 프로그램 자체를 즐기는 사람"이라는
의미로 사용하고 있다. 














공동체의 붕괴


이러한 상황은 1980년대 초에 DEC사가 PDP-10 시리즈의 생산을 중단하면서 부터
급격하게 붕괴되었다. 1960년대를 풍미했던 PDP-10 시리즈의 강력하고 우아한 설계
구조도 1980년대로 접어들면서 어드레스 공간을 더이상 자연스럽게 확장할 수
없었기 때문에 DEC사는 32비트 기반의 VAX를 주력 기종으로 삼으면서 PDP-10
시리즈를 퇴역시켰는데, PDP-10 시리즈의 단종은 ITS 환경에서 만들어진 거의 모든
프로그램들이 호환성의 문제로 인해서 더이상 사용될 수 없다는 것을 의미했다.






인공지능 연구소를 중심으로 한 해커들의 공동체도 PDP-10과 함께 붕괴되기
시작해서 1981년에는 인공지능 연구소에서 근무하던 대부분의 해커들이
스핀오프(spin-off) 회사인 심볼릭스(Symbolics)로 직장을 옮기게 되었다.(역자주:
스핀오프란 대학이나 기업 연구실의 연구원들이 독립해서 설립하거나 깊이
관여하고 있는 회사를 말한다.) 스티브 레비(Steve Levy)의 저서인
"해커들"(역자주: 한국에는 사민서각이라는 출판사에 의해서 "해커 - 그 광기와
비밀의 기록"이라는 이름으로 번역 출판되었다.)에는 이러한 상황들이 전성기 때의
공동체에 대한 일화와 함께 자세히 묘사되어 있는데, 해커들의 이직에 따른 가장
큰 문제는 바로 공동체 자체를 유지할 만한 인적 자원이 없어진다는 것이었다.
인적 자원의 부족은 결국 1982년에 인공지능 연구소에서 구입한 PDP-10을 운영하기
위해서 ITS가 아닌 DEC의 운영체제를 도입하는데까지 이르게 되었다. 물론, DEC의
운영체제는 자유 운영체제가 아니었다. 





당시에 소개되었던 VAX나 68020과 같은 현대적인 모델의 컴퓨터들은 전용
운영체제를 탑재하고 있었는데, 이들은 모두 자유 소프트웨어가 아니었다. 따라서
바이너리 형태의 프로그램을 사용하고자 할 때 조차도 관련 자료를 유출하지
않겠다는 비공개 계약 조건에 동의해야만 했다. 





이러한 사실은 컴퓨터를 사용하는 처음 단계부터 자신의 주위 사람들을 돕지
않겠다고 약속하는 것과 같은 의미를 갖는다. 즉 상호 협력적인 공동체는 처음부터
불가능하게 되는 것이다. 독점 소프트웨어의 소유자들은 소프트웨어를 공유하는
것을 "저작권 침해(pirate)"라는 단어를 사용해서 마치 해적 행위와 같이 해악한
것과 동일시 하려고 했으며, 프로그램에 대한 수정이 필요할 때는 그들에게 이를
요청하도록 했다. 





독점 소프트웨어 제도는 소프트웨어를 다른 사람들과 함께 공유하거나 교환하는
것을 금지하기 때문에 결코 사회적인 제도라고 할 수 없다. 이는 분명하게 잘못된
비윤리적인 제도이지만, 이러한 나의 주장이 어떤 사람들에게는 충격적인 사실로
받아들여질 수도 있을 것이다. 그러나 사용자들을 각각 고립시키고 서로가 서로를
돕는 것을 금지하는 방법으로 사람들을 무력하게 만드는 제도에 대해서 우리가
언급할 수 있는 것은 과연 무엇이겠는가? 만약, 독점 소프트웨어 제도에 대한 나의
생각에 대해서 거부감이 느껴진다면 아마도 그 사람은 독점 소프트웨어 산업이
유포해 왔던 개념들을 아무런 의심없이 그대로 인정해 왔기 때문이라고 할 수
있다. 소프트웨어 제작업자들은 소프트웨어의 유통 형태에 대해서 기존의 방식이
유일한 방법이라는 생각을 사람들에게 각인시키기 위해서 오랫동안 노력해 왔다.






소프트웨어 제작업자들이 사용하는 "저작권 침해 행위를 중단하라"거나 " "우리의
권리를 행사한다"는 등의 표현은 표면적인 것일 뿐이며, 그들이 의도하는 숨겨진
진의는 법률적이고 과격한 표현을 사용함으로써 대중들로 하여금 그들의 주장을
비판없이 수용하게 만들려는 데 있다. 





구체적인 예를 살펴보면, 일반 사용자들이 소프트웨어 회사들의 권리를
"침해"한다든가 또는 소프트웨어 회사들이 그들의 정당한 "권리를 행사"한다는
표현 안에는 마치 소프트웨어 제조 회사들이 소프트웨어를 유형, 무형으로 완전히
소유할 수 있는 천부적인 자연권을 갖고 있어서 소프트웨어에 대한 사용자들의
권리를 통제할 수 있다는 전제가 포함되어 있다. 만약, 그들의 권리가 진정한
자연권이라면 대중이 그들로부터 어떠한 피해를 입는다 하더라도 이에 반대하거나
저항할 수 없을 것이다. 그러나 한가지 흥미로운 사실은 미국의 헌법과 법률 전통
안에서는 저작권이 자연권 안에 포함되지 않음에도 불구하고 연방 정부가
인위적으로 부여한 독점권에 의해서 소프트웨어를 자유롭게 복제할 수 있는
사용자들의 권리가 제한당하고 있다는 점이다. 





소프트웨어 제조 회사들이 사용하는 표현에 내포되어 있는 또하나의 가정은
소프트웨어에 있어서 중요한 것은 오직 소프트웨어를 이용해서 수행할 수 있도록
사용자들에게 허용된 작업 자체이지 작업 과정을 통해서 형성될 수 있는
사람들간의 만남과 교류는 아니라는 점이다. 만약, 이러한 점들이 중요하게
고려되었다면 사람들간의 만남과 교류를 통해서 소프트웨어가 공유될 수 있다는
무척이나 자연스러운 발상에 근거해서 소프트웨어를 공유하거나 소스 코드를
보여주는 행위를 "권리의 침해"라는 강압적인 표현으로 오도하지는 못할 것이다.
그들이 중요하게 생각하는 것은 소프트웨어를 이용해서 최대한의 재화를 창출하는
것이기 때문에 소프트웨어에 대한 적용 범위와 고려의 대상을 사용자들의 만남과
교류가 아닌 작업 그 자체로 한정시킨 것이다. 





또한 "권리의 침해"나 "권리의 주장"이라는 표현 안에는 소프트웨어를 창작하고
수정하는 등의 모든 권한이 소프트웨어 제조 회사에 귀속되어 있으므로 그들의
주장을 인정하고 수용하지 않으면 특정한 작업을 수행할 수 있는 프로그램이나
그밖의 유용한 소프트웨어들을 전혀 사용할 수 없게 되리라는 강압적인 또하나의
잘못된 가정이 포함되어 있기도 하다. 이러한 가정은 매우 설득력 있게 들릴 수도
있지만 자유 소프트웨어 운동이 구속과 통제가 없는 많은 양의 자유
소프트웨어들을 만들어 냄으로써 그 오류를 불식시킬 수 있었다. 





만약, 이러한 가정들을 거부하고 사용자를 최우선으로 고려한 일반적인 상식과
윤리의 기준에서 이 문제를 판단한다면 우리는 매우 다른 결론에 도달하게 된다.
사람들이 서로 돕는 것은 이 사회를 지탱해 나가는 근간이 되므로 결국 사용자들은
그들의 필요에 따라서 프로그램을 자유롭게 수정하거나 공유할 수 있는 것이다.






이러한 결론이 도출되는 보다 엄밀한 추론 과정은 지면 관계상 생략하기로 한다.
그러나 GNU 홈페이지에 올려져 있는 http://www.gnu.org/philosophy/why-free.html
문서를 통해서 보다 자세한 내용들을 참고할 수 있을 것이다. 














냉혹한 도덕적 선택


공동체가 사라짐에 따라서 이 공동체를 예전처럼 지탱해 나가는 것은 불가능했고,
그대신 나는 냉혹한 도덕적 선택의 기로에 서게 되었다. 





손쉬운 선택은 비공개 협약에 서명하고 동료 해커들을 돕지않겠다는 것을
약속하면서 독점 소프트웨어의 세계에 합류하는 것이었다. 





만약 그렇게 했다면 내가 개발했을 소프트웨어 또한 비공개 협약에 의해서
배포되었을 것이므로 다른 사람들이 그들의 동료를 돕지 못하도록 강요하는
또하나의 요인이 되었을 것이다. 





나는 이러한 방법으로 돈을 벌 수 있었을 것이며 아마도 프로그램을 만드는
작업으로 부터 즐거움을 누릴 수도 있었을 것이다. 그러나 훗날 내 인생을
정리하면서 내가 보내온 과거를 돌이켜 봤을 때 내가 사람들을 단절시키는 벽을
만들어 왔으며 또한 이 세상을 보다 나쁘게 만들어 왔다는 것을 느끼게 될
것이라는 점도 알고 있었다. 





나는 MIT의 인공지능 연구소와 나에게 제어 프로그램의 소스 코드를 줄 것을
거부했던 사람으로 인해서 프린터의 사용에 곤란을 겪은 경험을 갖고 있었기
때문에 이러한 비공개 협약이 가져올 결과를 이미 알고 있었다.(프로그램에 특정한
기능이 결여되어 있었기 때문에 프린터를 사용하는데 많은 곤란을 겼었다.) 그래서
나는 비공개 협약은 결코 유익하지 않다는 생각을 갖고 있었다. 그가 소스 코드를
함께 공유하기를 거부했을 때 나는 매우 분개했으며, 나는 결코 같은 짓을 다른
사람들에게 하지 않겠다고 다짐했던 것이다. 





보다 간단하지만 결코 유쾌하지 않은 또하나의 선택은 컴퓨터 분야를 떠나는
것이었다. 이 선택은 내가 갖고 있는 기술이 내가 원하지 않는 방향으로 사용되지
않도록 할 수 있지만, 다른 측면에서 보면 내가 가진 기술이 허비되는 것이라고 할
수 있다. 만약, 이 방법을 선택했다면 컴퓨터 사용자들을 제한하고 단절시키는
일을 직접 하지는 않았을 것이므로 내가 비난의 대상이 되지는 않았겠지만,
그럼에도 불구하고 그러한 일들은 계속해서 일어났을 것이다. 





이러한 이유로 인해서 나는 프로그래머가 뭔가 좋은 역할을 할 수 있는 방법을
찾게 되었다. 나는 생각했다. 공동체를 다시 부활시키기 위해서 내가 직접 만들 수
있는 프로그램이 없을까? 





해답은 명확했다. 제일 먼저 필요한 프로그램은 바로 운영체제였던 것이다.
운영체제는 컴퓨터를 사용하기 위해서 필요한 가장 핵심적인 소프트웨어이다.
운영체제가 있다면 컴퓨터를 이용해서 다양한 종류의 작업을 할 수 있지만, 만약
운영체제가 없다면 컴퓨터 자체를 사용할 수 없게 된다. 따라서 자유롭게 사용할
수 있는 운영체제를 가질 수 있다면 상호 협력적인 해커들의 공동체를 다시 한번
재건할 수 있을 것이며 어떠한 사람에게도 공동체에 합류하기를 권유할 수 있게 될
것이다. 또한 운영체제의 구입에 수반되는 "재배포를 금지한다."는 등의 계약
조건에 구애받을 필요가 없어지므로 친구들의 자유를 침해하지 않고도 누구나
컴퓨터를 사용할 수 있게 될 것이다. 





운영체제의 개발자로서 나는 이러한 작업에 적합한 기술을 갖고 있었다. 그래서
성공하지 못할 가능성이 있음에도 불구하고 나는 이 일이 나의 소명이라고
생각하게 되었다. 나는 새롭게 개발할 운영체제를 유닉스와 호환되도록 만들
생각을 했다. 그렇게 함으로써 이식성을 갖게 되고 기존의 유닉스 사용자들이
새로운 시스템에 쉽게 적응할 수 있으리라고 생각했기 때문이다. GNU라는 이름은
MIT의 해커들이 프로그램의 이름을 지을 때 사용하던 재귀적 약어(recursive
acronym)의 습관을 반영한 것으로 GNU's Not Unix 즉 "GNU는 유닉스가
아니다."라는 뜻이 되도록 GNU라는 단어를 처음부터 의도적으로 조합해서 만든
것이다. 예를들면, EINE라는 이름의 에디터는 Emacs가 아니라는 의미로 "Eine Is
Not Emacs"라는 문구를 먼저 생각한 뒤에 여기서 각 단어의 첫 글자를 따서
EINE라는 이름이 되도록 만든 것이며, CYGNUS는 "Cygnus Your GNU Support" 라는
문구를 이용해서 만든 것이다. 따라서 GNU는 유닉스와 호환되도록 만들어진
운영체제이기는 하지만 유닉스와는 다른 운영체제라는 의미를 내포시키기 위해서
만든 이름이라고 할 수 있다. 





운영체제는 단순히 커널만을 의미하는 것이 아니라 여러가지 프로그램들을
실행시킬 수 있는 통합적인 시스템 운영 환경을 의미하는 것이다. 1970년대에
운영체제라고 말할 수 있을 만한 것들은 모두 셸과 같은 명령어 처리기와
어셈블러, 컴파일러, 인터프리터, 디버거, 텍스트 에디터 그리고 메일 프로그램과
같은 다양한 종류의 프로그램들을 갖고 있었다. ITS와 멀틱스(Multics), VMS,
유닉스 등의 운영체제들도 이러한 프로그램들을 포함하고 있었고, 따라서 이제부터
시작될 GNU 운영체제에도 이러한 프로그램들이 모두 필요했다. 





훗날 나는 유대교의 랍비 (2) 힐렐(Hillel)이 말했다는 다음과 같은 잠언을 듣게
되었는데, GNU 프로젝트를 시작하게 된 결단은 이러한 정신과 일맥 상통한다고 볼
수 있다. 





내가 내 자신을 위하지 못한다면, 그 누가 나를 위해 줄 것인가?


내가 내 자신만을 위한다면, 온전한 나 자신이 될 수 있을까?


바로 지금이 아니라면, 그 언제 할 수 있을 것인가?








(2) 무신론자로서 나는 어떠한 종교 지도자도 따르지 않지만, 때때로 그들이 남긴
금언에 내가 탄복하고 있다는 사실을 깨닫곤 한다.(역자주: 위의 금언은 탈무드
토라의 "위대한 세명의 랍비" 장에서 인용된 것으로, 힐렐은 예수 탄생전에
실존했던 유대 랍비의 이름이다.) 














구속되지 않는다는 관점에서의 자유


자유 소프트웨어라는 용어는 때때로 잘못 이해되기도 하는데, 이 말은 무료나
공짜라는 말이 내포하고 있는 금전적인 측면과는 전혀 관계없는 "구속되지
않는다"는 관점에서의 자유를 의미한다. 다른 언어와는 달리 영어에는
무료(gratis)를 의미하는 단어와 자유(freedom)를 의미하는 단어가 별도로
존재하지 않고 모두 free라는 단어를 사용하기 때문에 이러한 오해의 소지가 더욱
많다고 할 수 있지만, 무료 맥주(free beer)나 언론의 자유(free speech)와 같은
예를 생각해 보면 그 차이를 보다 명확하게 구분할 수 있을 것이다. 한국어의
경우에는 한자 문화권의 영향으로 이러한 2가지 경우에 대해서 무료(無料)나
무상(無償)이라는 단어와 자유(自由)라는 단어를 선택적으로 사용할 수 있기
때문에 "자유 소프트웨어"라는 용어상에 존재하는 혼란이 영어에서 비해서 비교적
적은 편이라고 할 수 있다. 그러나 이러한 언어상의 차이에 관계없이 중요한 것은
"자유"가 의미하는 본질적인 부분이며 사용자에게 다음과 같은 4가지 종류의
자유를 실질적으로 보장하는 프로그램을 자유 소프트웨어라고 말할 수 있다. 








목적에 상관없이 프로그램을 실행시킬 수 있는 자유 


필요에 따라서 프로그램을 개작할 수 있는 자유(이러한 자유가 실제로 보장되기
위해서는 소스 코드를 이용할 수 있어야만 한다. 왜냐하면 소스 코드 없이
프로그램을 개작한다는 것은 매우 어려운 일이기 때문이다.) 


무료 또는 유료로 프로그램을 재배포할 수 있는 자유 


개작된 프로그램의 이익을 공동체 전체가 얻을 수 있도록 이를 배포할 수 있는
자유 


"자유" 라는 단어는 금전적인 측면이 아닌 구속되지 않는다는 관점에서의 자유를
의미하기 때문에 자유 소프트웨어를 유료로 판매하는 데에는 어떠한 모순도
존재하지 않는다. 실제로 소프트웨어를 판매할 수 있는 자유는 매우 중요하며,
자유 소프트웨어들을 모아서 CD-ROM의 형태로 판매하는 것은 자유 소프트웨어의
발전 기금을 조성할 수 있는 실질적인 방법이 되기 때문에 공동체에 있어서 매우
중요한 부분이다. 따라서 임의의 배포판이나 소프트웨어 모음집에 자유롭게
포함시킬 수 없는 프로그램은 자유 소프트웨어가 아니라고 할 수 있다. 





자유라는 단어가 갖고 있는 모호함 때문에 사람들은 오랫동안 이를 대체할 수 있는
용어를 생각해 왔지만, 적절한 용어를 찾지는 못했다. 영어는 다른 언어에 비해서
많은 단어와 뉘앙스를 갖고 있지만 간단 명료함을 갖고 있지는 못하다. 자유
소프트웨어라는 용어에서 사용되는 free라는 단어는 unfettered, 즉
해방(解放)시킨다는 의미와 같은 뜻이라고 할 수 있을 것이다. liberated나
freedom 또는 open이라는 단어들은 이 단어들이 갖고 있는 다른 의미나 단점들
때문에 free 대신 사용하기에 문제가 있다고 생각한다.(역자주: 이러한 점들은
영어 뿐만 아니라 한국어에도 동일하게 적용되는 것으로 자유 소프트웨어 대신에
무료나 공개, 해방 소프트웨어와 같은 단어는 원어인 free가 갖고 있는 의미를
그대로 살리지 못한다고 볼 수 있기 때문에 "자유 소프트웨어"라고 용어가 가장
좋은 형태라고 생각한다.) 














GNU 소프트웨어와 GNU 시스템


완전한 운영체제 전체를 만든다는 것은 매우 커다란 프로젝트에 해당한다. 따라서
나는 기존에 존재하던 사용 가능한 자유 소프트웨어들을 개작하거나 취합해서
시스템을 완성시켜 나갈 생각을 하게 되었다. 예를들면, 프로젝트가 시작되었던
초반에는 TeX(텍)을 주된 조판 프로그램으로 사용했으며, 몇년 뒤에는 GNU에 맞는
새로운 윈도우 시스템을 개발하는 것 대신에 X 윈도우 시스템을 사용하기로
결정했다. 





이러한 결정으로 인해서 GNU 시스템은 단순히 GNU 소프트웨어들을 모두 모아놓은
것 이상의 것이 되었다. GNU 시스템은 GNU 소프트웨어 뿐만 아니라 그들만의
목적을 가진 다른 사람이나 프로젝트를 통해서 만들어진 소프트웨어도 포함하게
되었는데 이는 이 프로그램들이 자유 소프트웨어이기 때문에 가능한 것이었다.
일반적으로 GNU라는 이름은 GNU 프로젝트와 GNU 시스템을 지칭하는데 모두 사용될
수 있기 때문에 GNU 프로젝트를 가르킬 때는 GNU의 G 발음을 보다 명확하게 해서
GNU(쥐엔유)라고 읽고, GNU가 GNU 시스템을 가르킬 때는 G의 발음을 흐르게 해서
GNU, 즉 "그누~" 또는 "제뉴"라고 이를 구분하기도 한다. GNU 시스템은 GNU
프로젝트를 통해서 구현하려고 하는 유닉스와 호환되는 완벽한 소프트웨어 시스템
전체를 말하며 GNU 프로젝트는 이러한 시스템을 구현하기 위해서 진행되고 있는
프로젝트 자체를 의미한다. 














프로젝트의 시작


1984년 1월에 나는 MIT의 연구원직을 사임하고 GNU 소프트웨어를 만들기 시작했다.
내가 MIT를 떠난 이유는 연구원이 개발한 소프트웨어에 대한 저작권을 소속 회사나
학교로 귀속시킬 수 있는 법률과 내규에 따라서 MIT 당국이 내가 개발한
소프트웨어를 자유 소프트웨어로 만들지 못하게 할 가능성이 있었기 때문이다.
만약, 내가 MIT의 연구원으로 남아있게 되면 그들이 결과물에 대한 소유권을
주장하거나 MIT의 배포 조항을 강제로 적용할 가능성도 있었으며, 심지어 독점
소프트웨어 패키지로 만들 가능성도 배제할 수 없었다. 그러나 나는 공동체 모두가
공유할 수 있는 새로운 소프트웨어를 만들려는 나의 의도가 이러한 외적 조건들로
인해서 좌절되는 것을 원하지 않았다. 





한편, 내가 연구원직을 사임했음에도 불구하고 MIT의 인공지능 연구소장이었던
윈스턴(Patrick Winston) 교수는 내가 연구실의 장비들을 계속해서 사용할 수
있도록 배려해 주었다. 














첫번째 단계


GNU 프로젝트를 시작하기 얼마전에 나는 VUCK라는 이름으로도 알려진 자유 대학
컴파일러 킷(Free University Compiler Kit)에 대한 얘기를 듣게 되었다.(약어로
사용된 VUCK가 Free의 첫자인 F로 시작되지 않는 것은 free에 해당하는 독일어가
V로 시작되기 때문이다.) 이 컴파일러는 C와 파스칼을 포함한 여러개의 언어를
컴파일할 수 있었고 다양한 종류의 플랫폼에서 사용할 수 있도록 만들어진
것이었다. 나는 VUCK의 개발자에게 GNU가 이 컴파일러를 사용할 수 있는 지의
여부를 서신으로 물어보았다. 





자유 대학(Free University)이라는 이름 안에서의 free는 종교로부터 자유롭다는
의미로 사용된 것이다. 그는 대학은 자유롭지만 컴파일러는 그렇지 않다며 비웃는
듯한 회신을 보내왔다. 즉, 대학의 이름에는 자유라는 단어가 포함되어 있지만
VUCK는 학생들에게 결코 자유로운 소프트웨어가 아니었던 것이다.(역자주: 리차드
스톨만에게 도착한 회신은 독일어가 아닌 영어로 되어 있었기 때문에 free라는
영어 단어가 정확히 어떤 의미로 사용되었는 지 자신도 알 수 없다는 리차드
스톨만의 확인이 있었다. 단지, 정확하게 말할 수 있는 것은 VUCK가 "자유
소프트웨어"는 아니었다는 점이다. 아마도 V는 Verfuegung이나
Verfuegungsfreiheit의 첫자로 추측해 볼 수 있지만, 이를 확인할 방법은 없다.)
이러한 이유로 인해서 나는 GNU 프로젝트를 위한 첫번째 프로그램으로 다수의
언어와 플랫폼을 지원하는 컴파일러를 만들 결심을 하게 되었던 것이다. 





컴파일러 전체를 모두 작성해야 하는 수고를 피할 수 있으리라는 희망을 갖고 나는
로렌스 리버모어 연구소(Lawrence Livermore Lab.)에서 개발한 파스텔(Pastel)
컴파일러의 소스 코드를 입수했다. 이 컴파일러는 멀티 플랫폼을 지원하는
것이었으며 시스템 프로그래밍 언어로 사용할 목적으로 파스칼 언어를 확장한
파스텔 언어로 만들어진 것이었다. 물론, 파스텔 컴파일러는 파스텔 언어를 컴파일
하는데 사용되는 것이다. 파스텔 컴파일러는 파스텔 언어가 컴파일된 것이었기
때문에 나는 C 언어를 처리하기 위한 프론트 엔드(front-end) 부분을 덧붙여서
모토롤라의 68000 시스템에 맞게 이식하기 시작했다. 그러나 파스텔 컴파일러를
사용하기 위해서는 수 MB 용량의 스택(stack)이 필요하다는 사실을 알게 되었을 때
나는 파스텔 컴파일러를 활용하려던 계획을 포기할 수밖에 없었다. 왜냐하면 68000
기반의 유닉스 시스템에서는 기껏해야 64KB의 스택만을 사용할 수 있었기
때문이다. 





포트란을 비롯한 대부분의 프로그래밍 언어들은 프로그램에서 사용할 변수를 미리
선언하도록 설계되어 있다. 그러나 파스텔 언어는 변수를 그 사용에 관계없이
임의의 위치에서 선언할 수 있도록 되어 있었기 때문에 선언된 변수와 사용되고
있는 변수에 대한 정보를 올바르게 유지하기 위해서는 프로그램을 한번에 읽어서
메모리로 모두 올린 뒤에 처리하는 구조를 가질 수밖에 없었고, 이에 따라서 소스
코드와 거의 동일한 크기의 메모리와 스택이 필요한 상황이 일어날 수밖에 없었다.
즉, 파스텔 컴파일러는 입력 파일 전체를 한번에 파싱해서 이를 하나의 신택스
트리로 구성한 다음 연속된 명령어로 변환해서 출력 파일을 생성하는 구조를 갖고
있었던 것이다. 그러나 이러한 방식에서는 레지스터와 스택을 전혀 효율적으로
사용할 수 없기 때문에 나는 새로운 컴파일러를 처음부터 다시 만들어야 한다는
결론을 내리게 되었다. 파스텔 컴파일러를 포기한 이후에 새로 개발한 컴파일러는
이제 GCC라는 이름으로 알려지게 되었는데, GCC 컴파일러에는 파스텔 컴파일러의
소스 코드를 전혀 사용하지 않았지만 파스텔에 추가시켰던 C 언어 프론트 엔드는
GCC에도 계속해서 사용하려고 노력했다. 그러나 이러한 일들은 모두 이후 몇년
뒤에 이루어진 것들이었고, 그 당시에는 최우선적으로 GNU Emacs를 만드는 일에
집중하고 있었다. 














GNU Emacs


나는 1984년 9월부터 GNU Emacs를 만들기 시작했으며, 1985년 초에는 제법 쓸만한
상태가 되었다. 나는 vi나 ed의 사용법을 배우는 데에 관심이 없었기 때문에
유닉스가 아닌 다른 기종에서 편집 작업을 해 왔지만, Emacs를 만든 후에는
유닉스와 다른 기종의 컴퓨터에서 모두 편집 작업을 할 수 있게 되었다. 





사람들이 GNU Emacs를 사용하고 싶어하는 시점에 되었을 때, 이 에디터를 어떠한
방법으로 배포할 것인가에 대한 의문이 제기되었다. 물론, 내가 사용하고 있던 MIT
컴퓨터의 익명 FTP 사이트에는 올려둔 상태였다.(이 컴퓨터의 이름은
prep.ai.mit.edu였으며 GNU의 주된 FTP 사이트가 되었다. 몇년 뒤에 이 시스템을
퇴역시켰을 때도 우리는 그 이름을 새로운 시스템에서 계속해서 이어나갔다.)
하지만 그 당시에는 Emacs에 관심을 갖고 있는 사람들 중에서 인터넷을 통해 FTP를
이용할 수 있는 사람이 거의 없었다. 따라서 어떠한 방법으로 Emacs를 구할 수
있는 지를 그들에게 알려주는 것이 문제의 핵심이었다. 





나는 인터넷을 통해서 Emacs를 구해줄 수 있는 친구를 찾아보거나 반송용 우표가
붙어있는 봉투를 테이프와 함께 보내면 PDP-10용 Emacs를 복사해 주겠다고 말했다.
즉, Emacs를 배포하는데 있어서 금전적인 비용이 우리에게 청구되지 않는 방법을
생각해 냈던 것이다. 그러나 당시의 나는 직장을 갖고 있지 못했기 때문에 자유
소프트웨어를 통해서 수입을 얻을 수 있는 방법을 구상하고 있었다. 나는
150달라의 비용을 지불하면 누구에게나 Emacs가 들어있는 테이프를 우송해 주는
방법을 생각해 냈는데, 이러한 판매 방식을 통해서 나는 자유 소프트웨어를 이용한
사업을 시작하게 되었고 리눅스에 기반한 GNU 시스템 전체를 담고 있는 배포판을
판매하고 있는 현재의 리눅스 배포판 업체들의 시초가 되었던 것이다. 














프로그램은 누구에게나 자유로운가?





프로그램의 원저작자가 자신의 프로그램을 자유 소프트웨어로 공개했다고 하더라도
그 프로그램이 프로그램을 입수한 모든 사람들에게 자유 소프트웨어로 남아있게
된다고 할 수는 없다. 예를들면, 저작권이 없는 공개 소프트웨어(public domain
software)는 일종의 자유 소프트웨어라고 할 수 있다. 그러나 공개 소프트웨어는
누구든지 이 프로그램을 개작해서 독점 소프트웨어로 변형시킬 수 있으며,
저작권이 수반된 많은 종류의 자유 프로그램들도 수정 버전을 독점 소프트웨어로
만드는 것을 쉽게 허용하는 라이센스에 의해서 배포되고 있다. 





이러한 문제의 전형적인 예는 X 윈도우 시스템에서 찾아볼 수 있다. MIT에 의해서
개발된 X 윈도우 시스템은 자유 소프트웨어로 배포되었지만 수정 버전에 대한
독점권을 인정하는 라이센스를 갖고 있기 때문에 많은 컴퓨터 회사들이 이
프로그램을 채택하게 되었다. 그들은 X 윈도우 시스템을 그들이 독점적으로
판매하고 있는 유닉스 시스템에 바이너리 형태로만 추가한 뒤에 기존의 유닉스와
동일한 비공개 계약 조건에 의해서 관리되도록 만들어 버렸다. 이러한 종류의 X
윈도우 시스템은 유닉스와 마찬가지로 더이상 자유 소프트웨어가 아닌 것이다.






X 윈도우 시스템의 개발자들은 이러한 결과가 잘못된 것이라고 생각하지 않았으며
오히려 그렇게 되기를 의도하고 있었다. 왜냐하면 그들의 목적은 "자유"가 아니라
많은 사용자를 가진 프로그램을 만드는 데 "성공"하는 것이었기 때문이다. 그들은
사용자들이 프로그램에 대한 자유를 갖게 되는가의 여부에 상관없이 오직 많은
사용자를 갖게 되는데만 관심을 두었다. 





이러한 그들의 선택은 결국 "이 프로그램은 자유로운가?"라는 질문에 대한 답을
구할 때 어떤 기준에 의해서 "자유"의 총량을 산출할 것인가라는 역설적인 상황을
초래하게 만들었다. 만약 MIT의 배포 기준에 따라서 자유를 판단한다면 X 윈도우
시스템은 자유 소프트웨어라고 할 수 있지만, 일반적인 사용자에게 허용된 자유를
생각한다면 X 윈도우 시스템은 독점 소프트웨어라고 할 수있다. X 윈도우를
사용하는 대부분의 사용자들은 유닉스와 함께 제공되는 독점 버전을 사용하고
있으며 이러한 버전은 자유롭게 사용할 수 있는 것이 아니다. 














카피레프트와 GNU GPL


GNU의 목적은 GNU가 널리 알려지는 것이 아니라 사용자들에게 자유를 주는 것이다.
따라서 우리의 배포 기준에는 GNU 소프트웨어가 독점 소프트웨어로 변질되는 것을
막을 수 있는 조항이 필요했으며, 이를 위해서 (3) "카피레프트(copyleft)"라는
방식을 사용했다. 





카피레프트는 저작권법을 그 근간으로 하지만 저작권법이 갖고 있는 주된 목적을
반대로 이용해서 소프트웨어를 개인의 소유로 사유화시키는 대신 자유로운 상태로
유지시키는 수단으로 삼는 것이다. 





카피레프트의 핵심은 프로그램을 실행하고 복제할 수 있는 권리와 함께 개작된
프로그램에 대한 배포상의 제한 조건을 별도로 설정하지 않는한, 개작과 배포에
대한 권리 또한 모든 사람에게 허용하는 것이다. 즉 프로그램에 대한 실행과 복제,
개작, 배포의 모든 자유를 허용하는 것이다. 이러한 방법을 통해서 "자유
소프트웨어"라는 용어의 핵심인 "자유"를 모든 사람들에게 보장할 수 있고
프로그램을 입수한 사람은 그 누구도 뺏을 수 없는 권리를 갖게 된다. 





카피레프트가 실제로 유효하려면 개작된 프로그램 또한 자유로와야만 한다. 만약
우리가 만든 프로그램에 기반한 2차적 프로그램이 만들어 진다면, 이러한 보장이
있어야만 우리 모두가 개작된 프로그램을 사용할 수 있을 것이다. 직업
프로그래머들이 GNU 소프트웨어를 개량하기 위해서 자원했을 경우에도
카피레프트는 그들의 고용주들이 개작된 프로그램을 독점 소프트웨어로 만들려는
것을 방지할 수 있다. 





프로그램을 사용하는 모든 사람들의 자유를 확실히 보장하기 위해서는 개작된
부분이 자유로와야 한다는 요건은 매우 본질적인 것이다. X 윈도우 시스템을 독점
소프트웨어의 형태로 만든 기업들은 그들의 운영체제와 하드웨어에 X 윈도우를
이식하기 위해서 어느 정도의 수정을 가했는데, 그들이 수정한 부분은 X윈도우
전체와 비교하면 작은 부분에 불과하지만 하찮은 것은 아니다. 그러나 단지
프로그램을 수정했다는 이유만으로 사용자들의 자유를 제한할 수 있다면 누구나
이런 방법을 악용해서 쉽게 이익을 얻을 수 있을 것이다. 





위에서 언급한 문제는 자유 프로그램과 그렇지 않은 프로그램을 함께 결합하는
경우와도 연관이 있다. 이러한 결합으로 이루어진 결과물은 필연적으로 자유
소프트웨어가 될 수 없으며 자유 소프트웨어가 아닌 프로그램이 갖고 있던 자유의
결여가 결국 결과물 전체로 확대되어 버리게 된다. 프로그램 간의 이러한 결합을
허용하는 것은 배를 침몰시키기에 충분한 구멍을 만드는 것과 같으므로
카피레프트가 가져야 할 가장 중요한 요건은 바로 이러한 구멍을 막는 것이다. 즉
카피레프트로 배포된 프로그램에 어떠한 첨삭이 일어나거나 다른 프로그램과 함께
결합된다고 하더라도 그 결과물에는 반드시 카피레프트가 적용되어야만 하는
것이다. 





대부분의 GNU 소프트웨어에는 카피레프트를 실제로 구현한 라이센스 기준인 GNU
General Public License가 사용된다.(역자주: GNU General Public License는
소프트웨어를 배포하기 위해서 GNU가 사용하는 일반적이고 공개적인 라이센스라는
의미를 갖고 있기 때문에 "GNU 일반 공개 라이센스" 쯤으로 번역할 수 있지만,
대부분의 경우에는 GPL이라는 용어를 사용하므로 우리말로 번역하지 않고 GPL 또는
원어 그대로 GNU General Public License라고 하는 것이 가장 바람직한 표현
형태이다.) 우리는 상황에 따라서 다른 종류의 카피레프트를 사용하기도 하는데
GNU 매뉴얼의 경우에는 GNU GPL의 엄밀한 조건들이 모두 필요하지 않기 때문에
보다 간단한 형태의 카피레프트를 사용하고 있다. 





(3) 1984년인지 85년인지 정확히 기억나지는 않지만, 돈 홉킨스(Don Hopkins)라는
사람이 내게 편지를 보내온 적이 있었다.(그는 매운 상상력이 풍부한 친구였다.)
그가 보낸 편지 봉투에는 재미있는 문구가 몇개 쓰여져 있었는데 그 중에
"카피레프트 -- 모든 권리는 취소됩니다."라는 구절이 있었고 나는
"카피레프트"라는 단어를 당시에 내가 생각하고 있던 배포 형태를 나타내는
이름으로 사용하게 되었다. 














자유 소프트웨어 재단


Emacs의 사용에 대한 관심이 증가함에 따라서 사람들이 GNU 프로젝트에 참여하기
시작했고 우리는 지금이 기금을 모을 적절한 시기라는 결정을 하게 되었다. 그래서
1985년에 자유 소프트웨어의 개발을 위해서 면세 혜택이 주어지는 자유 소프트웨어
재단(Free Software Foundation)을 설립하게 된다. 자유 소프트웨어 재단, 즉
FSF는 Emacs의 테이프 배포 사업을 맡게 되었고 점진적으로 다른 종류의 자유
소프트웨어까지 테이프에 담아서 판매했는데 여기에는 GNU 이외의 자유
소프트웨어들도 포함되었고 매뉴얼의 판매 또한 병행되었다. 





FSF는 기부를 받고 있지만 대부분의 운영 자금은 자유 소프트웨어의 판매와 이와
관련된 부수적인 서비스를 통해서 충당되고 있다. 현재 FSF는 소스 코드나
바이너리가 담겨 있는 CD-ROM과 인쇄물로 만들어진 매뉴얼(매뉴얼도 카피레프트에
의해서 관리되므로 개작과 재배포가 허용된다.) 그리고 주문자가 선택한 플랫폼에
맞춰서 모든 소프트웨어들을 컴파일해서 수록한 디럭스 배포판(Deluxe
Distribution)을 판매하고 있다. 





자유 소프트웨어 재단이 고용한 사람들은 그동안 많은 종류의 GNU 소프트웨어
패키지를 만들거나 관리해 왔는데, 이중에서 특히 주목할 만한 것은 C
라이브러리와 셸이다. GNU C 라이브러리는 GNU/Linux 시스템에서 실행되는 모든
프로그램이 리눅스와 연동하기 위해서 반드시 필요한 것이다. C 라이브러리는 자유
소프트웨어 재단의 스탭 중 한 사람인 롤랜드 맥그래스(Roland McGrath)가 개발한
것이며 대부분의 GNU/Linux 시스템에서 사용하고 있는 셸 프로그램인 BASH(배쉬)는
FSF의 고용자였던 브라이언 폭스(Brian Fox)가 개발한 것으로 BASH는 (4) Bourne
Again SHell의 약자로 사용된 것이다. 





우리는 이러한 프로그램을 개발하기 위해서 기금을 사용했는데, 이는 GNU
프로젝트가 단순히 특정한 작업 도구나 개발 환경에 국한된 것이 아니기 때문이다.
우리의 목표는 완성된 형태의 운영체제를 만드는 것이며, 이러한 프로그램들은
우리의 목표를 위해서 필요한 것들이었다. 





(4) "Bourne again Shell"이라는 이름은 유닉스에서 일반적으로 사용되던 셸
프로그램인 ``Bourne Shell (본셸)''에 빗대어 만든 재미있는 표현이다. BASH는
다른 셸들과는 달리 약어 그대로 배쉬이라고 발음하며, Bourne again은 발음상
Born again이 되어 최초의 셸인 본셸의 재현이라는 의미를 갖게 된다. 














자유 소프트웨어에 대한 지원


자유 소프트웨어가 갖고 있는 철학은 널리 만연되어 있는 특정한 형태의 상업적
관행에 반대하지만 그렇다고 상업 행위 자체를 거부하는 것은 아니다. 사용자의
자유를 존중하는 사업이라면 우리는 그들의 성공을 기원할 것이다. 





Emacs의 판매는 자유 소프트웨어 사업의 한가지 예라고 할 수 있다. Emacs의 판매
사업을 자유 소프트웨어 재단으로 이관한 뒤에 나는 또다른 생계 수단을
강구해야만 했는데, 나는 내가 개발했던 자유 소프트웨어와 관련된 서비스를
제공하는 방법을 생각해 내게 되었다. 여기에는 GNU Emacs를 프로그래밍하거나
GCC를 최적화시키는 방법에 대한 교육과 GCC를 새로운 플랫폼으로 이식하는 작업이
주가 되는 소프트웨어 개발이 포함되었다. 





오늘날에는 자유 소프트웨어와 관련된 이러한 종류의 사업들이 많은 기업에 의해서
이루어 지고 있다. 어떤 업체들은 자유 소프트웨어로 구성된 CD-ROM을 판매하기도
하고 또다른 업체들은 사용자들의 질문에 답변해주는 것부터 시작해서 버그를
잡아주거나 프로그램에 새로운 주요 기능을 추가해 주는 등의 다양한 수준과
요구에 맞는 지원을 유료로 제공하기도 한다. 한 단계 더 나아가서 이제는 새로운
자유 소프트웨어 제품을 기반으로 사업을 시작하는 기업들도 생겨나고 있다. 





그러나 많은 기업들이 실제로는 단지 자유 소프트웨어와 함께 연동할 수 있는
소프트웨어를 기반으로 한 업체일 뿐임에도 불구하고 자신을 "오픈 소스"라는
이름과 연관시키고 있다는 사실에 각별히 주의해야 한다. 이러한 기업들은 자유
소프트웨어 업체가 아니라 그들의 상품을 이용해서 사용자가 자유로부터
멀어지도록 유혹하고 있는 독점 소프트웨어 업체인 것이다. 그들의 제품이 갖고
있는 유혹은 자유 보다는 편리함인데, 그들은 이것을 "부가가치(附加價値)"라는
이름으로 우리가 수용해 주기를 요구하고 있다. 그러나 자유라는 측면에서 이를
판단한다면 우리는 이러한 제품을 부가가치가 아닌 "자유감치(自由減値)"
제품이라고 불러야 마땅할 것이다. 














기술적인 목표


GNU의 주된 목표는 자유 소프트웨어가 되는 것이다. GNU가 유닉스에 비해서
기술적인 장점을 전혀 갖지 못하게 된다 하더라도 사용자들이 서로 협력할 수 있게
함으로써 사회적인 이점은 갖게 될 것이고 사용자들의 자유를 존중하게 된다는
점에서 윤리적인 이점도 있다고 할 수 있다. 





그러나 우수한 기술의 표준들을 GNU에 수용했던 것은 무척이나 당연한 일이었다.
예를들면, 제한된 영역의 메모리 사용을 극복하기 위해서 동적 할당 방식의
자료구조를 도입했으며 8비트 코드를 처리할 수 있도록 해서 어떠한 형태의 입력에
대해서도 이를 정상적으로 처리할 수 있도록 했다. 





또한, 16비트 컴퓨터를 지원하지 않도록 결정함으로써 유닉스에서 채택하고 있던
작은 크기의 메모리로 인한 문제를 없앨 수 있게 되어 1MB가 넘지 않는 한도에서는
메모리의 사용을 줄이기 위해서 노력할 필요가 없어졌다.(GNU 시스템이 완성될
시점에는 32비트 컴퓨터가 일반적인 추세가 되리라는 것이 확실했다.) 따라서
프로그램에서 큰 용량의 파일을 처리하는 것이 수월해 졌기 때문에
프로그래머들에게 입출력에 대한 문제를 고려하지 말고 입력 파일 전체를 메모리로
올려서 사용하도록 권장할 수 있었다. 





결국 이러한 결정은 GNU 프로그램들이 같은 유닉스 프로그램에 비해서 향상된
속도와 신뢰성을 갖도록 해 주었다. 














기증받은 컴퓨터


GNU 프로젝트의 명성이 높아지면서 유닉스가 탑재된 시스템을 기증하는 사람들이
생겨나기 시작했다. GNU를 구성하는 프로그램을 개발하는 가장 손쉬운 방법은
유닉스 환경에서 먼저 개발한 뒤에 이를 하나씩 GNU에 맞게 수정하는 것이었기
때문에 이러한 시스템은 우리에게 매우 유용한 것이었다. 그러나 그들은 우리가
유닉스를 사용하는 것이 과연 정당한가라는 윤리적인 문제를 제기해 왔다. 





유닉스는 예나 지금이나 독점 소프트웨어에 해당한다. 그리고 GNU 프로젝트의
철학은 독점 소프트웨어를 사용하지 않겠다는 데 있다. 그런데, 독점 소프트웨어를
사용해서 자유 소프트웨어를 만든다는 것은 모순이 아니겠느냐는 것이 그들의
주장이었던 것이다. 그러나 자기 자신을 보호하기 위해서 사용한 무력을 정당
방위로 인정받을 수 있는 것과 같이 다른 사람들이 독점 소프트웨어를 사용하지
않을 수 있도록 돕기 위해서 자유 소프트웨어를 만드는 과정에 독점 소프트웨어를
사용할 필요가 있다면, 나는 이것 또한 정당화될 수 있다는 결론을 내렸다. 





그러나 이러한 방법이 정당화될 수는 있다 하더라도 독점 소프트웨어를 사용하는
것은 여전히 해악한 것이었다. 그래서 어느 시점에 이르렀을 때, 우리는 더이상
독점 소프트웨어를 사용하지 않기로 결정하고 기증받은 컴퓨터에서 사용할 수 있는
자유 운영체제를 찾기 시작했다. 사용 가능한 운영체제를 발견한 경우에는
운영체제를 교체했지만, 자유 운영체제를 사용할 수 없는 경우에는 자유
운영체제를 사용할 수 있는 시스템으로 컴퓨터 자체를 교체시켰다. 오늘날에는
이미 유닉스를 대체할 수 있는 자유 운영체제를 갖고 있기 때문에 유닉스가 설치된
시스템을 전혀 사용하지 않고 있다. 














GNU 태스크 리스트


GNU 프로젝트가 진행됨에 따라서, 그리고 발견하거나 개발된 자유 운영체제의 구성
요소들이 많아짐에 따라서 마침내 남아있는 부분에 대한 목록을 만드는 것이
필요한 시점이 되었다. 우리는 이 목록을 이용해서 남아 있는 부분들을 만드는데
필요한 개발자들을 모집했는데, 이 목록은 "GNU 태스크 리스트(GNU Task
List)"라는 이름으로 불리게 되었다. 우리는 아직 개발되지 않은 유닉스 시스템의
구성 요소 뿐만 아니라 하나의 완벽한 운영체제가 되기 위해서 필요하다고 판단한
다양한 종류의 소프트웨어와 문서 프로젝트 등을 이 목록에 추가시켰다. 





유닉스와 관련된 대부분의 구성 요소들은 이제 GNU 태스크 리스트에 남아 있지
않다.(대부분의 작업은 모두 완료되었으며 자잘한 몇 부분만이 남아 있는
상태이다.) 그러나 이 목록에는 "응용 프로그램"이라고 부를 수 있는 소프트웨어를
만들기 위한 많은 양의 프로젝트들이 가득 차 있다. 협소한 사용자 층을 갖고 있는
프로그램이 아니라면 대부분의 프로그램들은 운영체제와 함께 구성될 만한 유용한
프로그램이라고 할 수 있을 것이다. 





유닉스에는 게임 프로그램이 포함되어 있기 때문에 자연스럽게 GNU에도 게임이
포함되어야 했다. 따라서 GNU 태스크 리스트에는 이러한 게임 프로그램들도
처음부터 함께 포함되었다. 그러나 게임 프로그램에는 호환성이라는 문제를 고려할
필요가 없기 때문에 유닉스에서 제공하던 게임의 종류를 그대로 따르지 않고
사용자들이 좋아할만한 다양한 종류의 게임들을 포함시켰다. 














GNU Library GPL


GNU C 라이브러리에는 GNU Library GPL이라고 불리는 특별한 종류의 카피레프트가
적용된다. 이것은 독점 소프트웨어와의 링크를 허용하는 것으로 이제는 "GNU
Lesser GPL"이라는 이름으로 변경되었으며, LGPL이라고 줄여서 부르기도 한다.
그렇다면 왜 이러한 예외를 만들었는가? 





LGPL은 우리의 원칙을 수정한 것이 아니다. 우리의 원칙에는 결코 독점 소프트웨어
제품들이 우리가 만든 코드를 사용하도록 허용하지 않고 있다.(소프트웨어를
우리와 함께 공유하지 않을 것이 명백한 프로젝트에 도움을 줄 이유가 없지
않은가?) C 라이브러리나 다른 라이브러리들을 LGPL로 만든 것은 원칙을 수정한
것이 아니라 일종의 전략이라고 할 수 있다. 





C 라이브러리는 매우 일반적인 기능을 제공하는 것이어서 모든 독점 운영체제와
컴파일러에는 C 라이브러리가 함께 제공되고 있다. 따라서 GNU C 라이브러리를
자유 소프트웨어에서만 사용할 수 있도록 한다면 자유 소프트웨어들은 별다른 비교
우위를 갖게 되지 못할 것이다. 즉, GNU C 라이브러리를 사용하려는 의욕을
저하시키게 되는 것이다.