GNU 프로젝트

글: 리처드 스톨먼

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

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

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 프로젝트를 통해서 구현하려고 하는 유닉스와 호환되는 완벽한 소프트웨어 시스템 전체를 말하며 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)을 설립하게 된다. 자유 소프트웨어 재단, 즉 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 라이브러리를 사용하려는 의욕을 저하시키게 되는 것이다.

GNU/Linux를 포함한 GNU 시스템에서는 오직 GNU C 라이러리만을 사용할 수 있기 때문에 이러한 문제에서 예외일 수 있다. 따라서 GNU C 라이브러리의 배포 조건에 고려되어야 할 점은 독점 소프트웨어가 GNU 시스템용으로 컴파일 될 수 있도록 GNU C 라이브러리의 사용을 허용할 것인가라는 문제로 귀착된다. 독점 소프트웨어를 GNU에서 사용할 수 있도록 허용하는 것에는 어떠한 윤리적인 문제도 없다. 그러나 전략적으로 볼 때 이러한 것을 허용하지 않는 것은 자유 소프트웨어의 개발을 촉진한다기 보다 오히려 GNU 시스템의 사용을 저하시킬 가능성이 크다고 할 수 있다. 이것이 GNU C 라이브러리를 LGPL로 관리되도록 한 전략적인 이유이다.

다른 라이브러리들은 상황에 맞는 전략적 판단을 통해서 결정하는 것이 필요할 것이다. 만약 어떠한 라이브러리가 특정한 종류의 프로그램을 개발하는데 중요한 역할을 수행하게 된다면, 이러한 라이브러리는 GPL로 관리되도록 해서 자유 소프트웨어에서만 사용되도록 제한하는 것이 바람직하다. 그렇게 함으로써 자유 소프트웨어의 개발자들은 독점 소프트웨어 개발자에 대한 비교 우위와 이점을 갖게 될 수 있을 것이다.

GNU Readline의 예를 생각해 보면, 이 라이브러리는 BASH의 명령행 편집 기능을 구현하기 위해서 개발된 것이다. Readline은 LGPL이 아닌 GPL에 의해서 관리되었기 때문에 아마도 LGPL로 배포했을 경우 보다는 그 사용 빈도가 많지 않았을 것이다. 그러나 이로 인해서 우리가 잃은 것은 아무 것도 없다. 반면에, Readline을 채택한 유용한 자유 소프트웨어가 하나라도 만들어 졌다면 이는 공동체 전체에 있어서 매우 유용한 수확이라고 할 수 있다.

독점 소프트웨어의 개발자들은 자본이라는 우위를 갖고 있다. 그러나 자유 소프트웨어의 개발자들은 서로를 위해서 이점을 만들어 주어야 한다. 나는 언젠가는 우리가 독점 소프트웨어에 라이센스를 허용하지 않는 넉넉한 양의 GPL 라이브러리들을 갖게 되기를 희망한다. 이러한 라이브러리들은 새로운 자유 소프트웨어 안에서 유용한 기능을 수행하는 모듈로 활용될 것이며 보다 나은 자유 소프트웨어를 개발하는데 있어서 주요한 이점들을 제공하게 될 것이다.

가려운 곳을 긁는다?

에릭 레이몬드(Eric Raymond)는 “소프트웨어에 있어서 모든 좋은 성과들은 개발자 자신의 가려운 곳을 긁는 것으로부터 시작된다.”라고 주장한다.(역자주: 에릭 레이몬드의 대표적인 저작인 성당과 시장에 소개되어 있는 문장으로 사이트를 통해서 한국어 번역 전문을 참고할 수 있다.) 때때로 이것은 타당한 말일 것이다. 그러나 GNU 소프트웨어의 핵심적인 부분들은 대부분 완전한 자유 운영체제를 만들기 위한 목적으로 개발된 것이다. GNU는 가려울 때마다 가려운 곳을 긁듯이 그때그때 만들어 진 것이 아니라 비전과 계획에 의해서 만들어 진 것이다.

예를 들어, 우리가 GNU C 라이브러리를 개발한 이유는 유닉스 형태의 운영 환경에서 C 라이브러리가 필요했기 때문이고, BASH를 개발한 이유 또한 유닉스 환경이 셸을 요구하기 때문이었다. GNU tar나 내가 직접 개발한 GNU C 컴파일러와 GNU Emacs 그리고 GDB와 GNU Make도 같은 이유에서 개발된 것들이었다.

어떠한 종류의 GNU 프로그램은 자유에 대한 위협에 대처하기 위해서 만들어 진 것이다. gzip은 LZW 압축 알고리즘의 특허 문제로 인해서 공동체 안에서 사라져 버린 압축 프로그램을 대체하기 위해서 개발되었다. 우리는 독점 라이브러리로 인해서 일어나는 문제들을 해결하기 위해서 LessTif를 개발할 사람들을 모집했으며 더욱 최근에는 GNOME과 Harmony를 만들기 시작했다. 또한 사생활과 자유 중에서 하나를 선택해야만 하는 불합리한 문제를 없애기 위해서 자유 소프트웨어가 아닌 기존의 인기있는 암호화 소프트웨어를 대체할 GNU Privacy Guard를 개발하고 있기도 하다.

물론, 이러한 프로그램들을 개발하고 있는 개발자들은 자신의 작업에 흥미를 갖고 있으며 많은 사람들이 그들의 필요와 관심에 따라서 다양한 기능들을 덧붙여 가고 있다. 그러나 이러한 것이 프로그램이 존재하게 되는 이유는 아니다.

예기치 않은 개발들

GNU 프로젝트를 시작할 당시에는 GNU 시스템을 모두 완성한 뒤에 완성된 시스템 전체를 공개하려고 생각했었다. 그러나 다음과 같은 이유로 인해서 그렇게 되지 못했다.

GNU 시스템을 구성하는 각각의 요소들은 유닉스에서 먼저 구현한 뒤에 이를 GNU로 옮긴 것이기 때문에 GNU 시스템이 완성되기 오래 전부터 이미 유닉스에서 사용되고 있었다. 이러한 프로그램 중에서 어떠한 것들은 유명해 졌으며 사용자들이 프로그램을 확장하거나 호환이 되지 않던 다양한 종류의 유닉스로 이식시켰다. 또한 유닉스 이외의 운영체제로 이식이 이루어 지기도 했다.

이러한 과정을 통해서 그 프로그램들은 보다 강력한 기능을 갖게 되었고 기부와 공헌자들을 GNU 프로젝트로 끌어들이게 되었다. 그러나 이것은 GNU의 개발자들로 하여금 GNU 시스템을 완성시켜나가는 것 보다 오히려 기존의 구성 요소에 새로운 기능을 덧붙이거나 다른 시스템으로 이식하는데 시간을 투자하도록 만들었기 때문에 동작 가능한 최소한의 시스템을 완성하는데 몇년이 지연되는 결과를 가져왔다.

GNU Hurd

1990년 무렵에는 GNU 시스템이 거의 완성되었지만 운영체제를 구성하는 핵심 부분 중의 하나인 커널이 누락된 상태였다. 우리는 Mach(마하 또는 마크)를 기반으로 한 서버 프로세스들을 연결해서 커널을 구현하기로 결정했다. Mach는 카네기 멜론 대학(Carnegie Mellon University)에서 개발한 마이크로커널(microkernel)로 후에 유타 대학(University of Utah)으로 그 개발이 넘어갔다. 커널은 운영체제를 구성하는 핵심 부분을 가리키는 말인데 마이크로커널 아키텍처에서는 IPC와 메모리 관리 부분만을 커널에 내장시키고 나머지 부분들은 자율적인 프로세스로 구현한 뒤에 이들을 연결시키는 구조를 갖고 있다. 따라서 우리가 만들려고 했던 GNU Hurd(허드)는 Mach와 자율적인 프로세스 서버들의 집합이라고 할 수 있으며 유닉스 커널이 갖고 있는 다양한 기능들을 그대로 수행할 수 있는 것이었다. 그러나 GNU Hurd의 개발은 Mach를 자유 소프트웨어로 배포한다고 예고했던 시기까지 지연되었다.

마이크로커널을 채택한 이유 중의 하나는 소스 차원의 디버거 없이는 가장 힘든 작업이 될 수밖에 없는 커널 프로그램의 디버깅을 피하기 위해서였다. 우리는 완성된 Mach를 활용하면 이러한 작업을 생략할 수 있으며 Hurd 서버들을 디버깅하는 데는 GDB를 사용할 수 있으리라고 생각했다. 그러나 이러한 작업이 가능하기 위해서는 상당한 기간이 필요했으며 상호 메시지 전달을 위한 멀티 쓰레드 서버를 디버깅하는 것도 매우 어려운 작업이었다. 이러한 이유로 인해서 Hurd를 만드는 작업에는 많은 시간이 소요되었다.

Alix

GNU 커널의 이름을 처음부터 Hurd라고 부르려 했던 것은 아니다. 원래의 이름은 당시 내 연인의 이름을 따서 Alix(앨릭스)라고 했었는데, 유닉스 시스템 관리자였던 그녀는 Alix라는 이름이 유닉스의 버전마다 관례처럼 붙여지던 별칭과 잘 어울린다면서, “누군가 내 이름을 따서 커널 이름을 지어야 할걸”이라고 친구들에게 농담처럼 말하곤 했다. 나는 아무 말도 하지 않았지만 Alix를 커널의 이름으로 사용해서 그녀를 놀라게 해주리라 마음먹었다.

그러나 이러한 나의 생각은 실현되지 못했다. 커널의 주요 개발자였던 마이클 부쉬널(Michael Bushnell, 현재의 이름은 토마스이다.)이 Hurd라는 이름을 더 선호했기 때문이다. 또한 그는 Alix를 커널의 이름에서 Hurd 서버로 메시지를 전송하는 방법을 통해서 시스템 콜을 트랩하고 제어할 수 있는 커널의 한 부분으로 변경시켰다.

훗날, Alix와 나는 헤어지게 되었고 그녀는 그녀의 이름을 다른 것으로 바꿨다. 또한 이러한 사연과는 무관하게 Hurd의 디자인도 C 라이브러리가 서버로 메시지를 직접 전달할 수 있는 형태로 수정되었다. 이러한 이유로 Alix는 HURD에서 사라지게 되었다.

그러나 이러한 일들이 일어나기 전에 Alix의 친구 중 한 명이 Hurd의 소스 코드에 포함되어 있던 Alix라는 이름을 본 적이 있었고, Alix에게 그 사실을 전해줌으로써 나의 의도는 그녀에게 전달될 수 있었다.

리눅스와 GNU/Linux

현재까지도 GNU Hurd는 하나의 제품으로 사용될 수 있을 만한 상태가 아니다. 그러나 다행스럽게도 또다른 커널이 사용 가능했는데, 1991년에 리누스 토발스(Linus Torvalds)가 유닉스 커널과 호환 가능하게 만든 리눅스라는 이름의 커널이 그것이었다. 1992년 무렵에 우리는 완전하지 않았던 GNU 시스템과 리눅스를 결합함으로써 하나의 완성된 자유 운영체제를 만들 수 있었다.(이들을 결합한다는 것은 물론 단순한 작업이 아닌 상당한 노력이 필요한 실제적인 작업이었다.) 따라서 현재 사용되고 있는 GNU 시스템은 리눅스 덕분에 가능했던 것이라고 할 수 있다.

미래의 도전들

우리는 다양한 종류의 자유 소프트웨어를 개발함으로써 우리의 역량을 증명해 왔다. 그러나 이것이 우리에게 장애가 없는 무소불위의 능력이 있다는 것을 의미하지는 않는다. 몇 가지 장애물들이 자유 소프트웨어의 앞날을 불확실하게 만들고 있기 때문이다. 이러한 장애들을 극복하기 위해서는 끊임없는 노력과 인내가 필요하며 때때로 몇년이 소요되기도 할 것이다. 또한 자유를 소중히 여기고 이를 누구에게도 빼앗기지 않겠다는 의사를 분명히 표현하려는 사람들의 결단이 필요하다.

우리에게 당면해 있는 장애는 다음과 같은 것들이다.

비밀스런 하드웨어

하드웨어 제조업에서는 하드웨어에 대한 스펙을 비밀로 하는 경우가 점점 더 늘어나고 있다. 이 때문에 자유롭게 쓸 수 있는 드라이버를 만드는 것이 힘들어 지고 결과적으로 리눅스와 XFree86에서 새로운 하드웨어를 지원하는 것이 어려워지고 있다. 현재 우리들은 완성된 자유 운영체제를 갖고 있지만 앞으로 개발될 컴퓨터를 지원할 수 없다면 그렇게 되지 못할 수도 있을 것이다.

이러한 문제에 대처할 수 있는 방법은 2가지가 있다. 그 첫번째 방법은 리버스 엔지니어링(reverse engineering)을 채용하는 것이고 두번째 방법은 사용자들이 그 결과를 지원하는 것이다. 리버스 엔지니어링이란 이미 생산되고 있는 하드웨어를 분석해서 설계 구조와 스펙 등을 알아내는 방법이다. 따라서 프로그래머들이 리버스 엔지니어링을 수행하면 일반 사용자들은 그 결과를 통해서 자유 소프트웨어에서 사용할 수 있는 하드웨어를 선택할 수 있다. 그렇게 되면 자유 소프트웨어를 사용하는 사람이 증가할수록 하드웨어 스펙을 공개하지 않는 방침은 결국 스스로의 화를 자초하는 선택이 될 것이다.

리버스 엔지니어링은 매우 방대한 작업이다. 우리가 과연 이러한 일을 수행할 수 있는 결단을 가진 프로그래머들을 가질 수 있을까? 만약 우리가 자유 소프트웨어가 아닌 드라이버들을 과감하게 포기하고 자유 소프트웨어라는 원칙을 단호하게 지켜간다면 충분히 가능하리라고 생각한다. 우리 중 많은 사람들이 자신이 갖고 있는 여분의 시간과 돈을 투자할 수 있다면 자유롭게 쓸 수 있는 드라이버를 갖지 못할 이유가 없지 않을까? 자유를 누리려는 결단이 널리 확산된다면 얼마든지 가능할 것이다.

자유 소프트웨어가 아닌 라이브러리들

자유 운영체제에서 사용할 수 있는 자유 소프트웨어가 아닌 라이브러리들은 자유 소프트웨어 개발자들에게 있어 일종의 함정과 같다. 이러한 라이브러리가 갖고 있는 매혹적인 기능을 외면한다는 것은 개발자에게 있어서 매우 어려운 일이다. 그러나 만약 이러한 유혹에 넘어간다면 그것은 스스로 자신의 무덤을 파는 것과 같다. 왜냐하면 이러한 라이브러리를 이용해서 만들어진 프로그램은 자유 운영체제에 포함될 수 없기 때문이다.(보다 정확하게 말하면 프로그램은 포함시킬 수 있겠지만, 라이브러리 자체가 포함될 수 없기 때문에 결국 이러한 프로그램은 실행될 수 없는 것이다.) 더욱 심각할 수 있는 경우는 만약 독점 라이브러리를 사용한 프로그램이 매우 인기있는 프로그램이 된다면 이러한 라이브러리에 관심을 갖고 있지 않던 프로그래머들을 같은 유혹에 빠뜨릴 수 있다는 점이다.

이러한 경우의 첫번째 실례는 1980년대에 사용되던 Motif (모티프) 툴킷에서 찾아볼 수 있다. 그 당시에는 아직 자유 운영체제가 존재하지 않았지만 Motif가 갖고 있던 문제가 어떤 결과를 초래하리라는 것은 이미 자명한 일이었다. GNU 프로젝트는 두가지 방법으로 여기에 대응했다. 첫째는 자유 소프트웨어 프로젝트들이 Motif 뿐만 아니라 자유 소프트웨어에 해당하는 X 툴킷 위젯도 지원하도록 권고한 것이고, 또하나는 Motif를 대체할 수 있는 라이브러리의 개발을 추진한 것이다. 이 작업에는 몇년이 소요되었는데 열성적인 프로그래머들 덕분에 1997년에 이르러 Moti를 사용하는 대부분의 프로그램을 지원할 수 있는 LessTif 라이브러리가 완성되었다.

1996년과 1998년 사이에는 이른바 Qt라고 불리는 또다른 GUI 툴킷 라이브러리가 등장했다. Qt는 데스크탑 환경의 자유 소프트웨어인 KDE에 사용되는 핵심 요소이다.

그러나 자유 운영체제인 GNU/Linux 시스템에서는 Qt의 라이센스와 관련해서 KDE를 사용할 수 없었다. GNU/Linux를 판매하는 일부 상용 배포판 업체에서는 KDE를 함께 패키징해서 활용성을 증대시킨 시스템을 만들기도 했지만 결국 이것은 자유를 감소시키는 것이었다. KDE 그룹은 보다 많은 프로그래머들이 Qt를 사용하도록 적극적으로 권장했고 새롭게 리눅스를 사용하게 된 수많은 사람들은 이러한 문제를 미처 생각하지도 못한 채 KDE를 사용하게 되었다. 상황이 무척 심각해 진 것이다.

자유 소프트웨어 공동체는 GNOME과 Harmony라는 2가지 방법으로 이 문제에 대응했다.

우리는 먼저 GNU Network Object Model Environmet, 즉 GNOME(그놈)이라고 불리는 데스크탑 환경의 개발을 시작했다.(역자주: GNOME을 구성하는 단어들은 여러가지 형태로 배열할 수 있는데, 의미의 전달이 가장 명확한 형태는 GNU's Environment Model for Network Objects이다.) 이 프로젝트는 미구엘 드 이카자(Miguel de Icaza)에 의해서 1997년부터 시작되었고 레드햇 소프트웨어가 이를 후원하고 있다.(역자주: 미구엘 드 아카자는 1999년에 미국의 과학 전문지인 MIT Technology Review가 창간 100주년 기념호에서 선정한 다음 세기를 이끌 젊은 과학자 100인에 선정되기도 하였으며 GNOME 프로젝트에 대한 공로로 자유 소프트웨어 재단이 수여한 제2회 자유 소프트웨어 발전을 위한 자유 소프트웨어 재단상을 수상하기도 했다.) GNOME은 데스크탑 환경과 유사한 기능들을 제공하지만 오직 자유 소프트웨어만으로 만들어 진다. 또한 C++ 이외에 다양한 종류의 언어를 지원함으로써 기술적인 장점도 함께 제공한다. 그러나 GNOME의 주된 목적은 자유라고 할 수 있다. GNOME 환경은 자유 소프트웨어가 아닌 어떠한 프로그램의 기능도 자유 소프트웨어 안에서 충족시키기 위한 것이다.

또하나의 대안인 Harmony는 KDE 소프트웨어들을 Qt 없이도 사용할 수 있도록 하기 위해서 개발된 라이브러리이다.

1998년 11월에 Qt의 개발자들은 Qt를 자유 소프트웨어로 변경할 것이라고 발표했다. 그러나 이것은 아직까지 확실한 것이 아니며, 부분적으로 Qt가 자유 소프트웨어가 아니었을 때 갖고 있던 문제에 대해서 우리가 단호하게 대처함으로써 나타난 결과라고 할 수 있다.(Qt의 새로운 라이센스에도 여전히 불충분한 점이 많이 있으므로 가능한 Qt를 사용하지 않는 것이 바람직하다.)

자유 소프트웨어가 아닌 또다른 라이브러리의 유혹에 우리는 어떻게 대응해야 할까? 공동체의 일원들은 모두가 다 이러한 유혹으로부터 벗어날 필요성에 공감하게 될까? 그렇지 않다면 편리함을 핑계삼아 자유를 포기하고 중요한 문제를 만들어 내지는 않을까? 우리의 미래는 다름아닌 우리들 자신의 철학에 달려있는 것이다.

소프트웨어에 대한 기술 특허

우리가 당면하고 있는 가장 큰 위협은 바로 소프트웨어에 대한 특허로 부터 발생된다. 알고리즘과 새로운 기술에 부여되는 특허는 20년까지 보장되므로 이러한 영역에는 자유 소프트웨어가 접근할 수 없는 것이다. LZW 압축 알고리즘에 대한 기술 특허는 1983년에 신청되었다. 그리고 아직까지도 우리는 정상적인 GIF 압축을 생성할 수 있는 자유 소프트웨어를 공개하지 못하고 있다. 1998년에는 특허권 침해에 대한 소송 위협에 따라서 배포판에서 MP3 오디오 압축 프로그램을 제외할 수밖에 없었다.

특허권에 대처할 수 있는 몇가지 방법은 특정한 특허가 특허로 인정될 수 없다는 반대 증거를 찾거나 특허가 취득된 기술을 대체할 수 있는 방법을 찾는 것이다. 그러나 이러한 방법들이 항상 적용될 수 있는 것은 아니며, 이러한 방법들이 모두 실패할 경우에는 사용자들이 원하는 기능을 자유 소프트웨어에 포함시킬 수 없게 될 것이다. 만약, 이러한 일이 일어난다면 어떻게 해야 할 것인가?

자유 소프트웨어가 갖고 있는 자유의 가치를 중요하게 생각하는 사람들은 어떠한 상황에서도 자유 소프트웨어를 버리지 않을 것이다. 우리는 특허와 관련된 기능이 없더라도 나름대로 원하는 작업을 해 나갈 수 있을 것이다. 그러나 자유 소프트웨어가 갖게 될 기술적 우위를 기대하고 이를 사용했던 사람들은 특허에 의해서 기술적 장점이 사라진 이후에는 자유 소프트웨어가 실패했다고 단언할 것이다. 따라서 “시장” 형태의 개발 모델이 갖고 있는 실제적인 효과와 특정한 자유 소프트웨어가 갖고 있는 안정성과 성능에 대해서 말하는 것이 사람들에게 유용한 동안에는 단지 그러한 말만을 할 것이 아니라 자유와 자유를 지켜나가기 위한 원칙에 대해서도 함께 얘기 해야만 한다.

자유 문서

우리의 자유 운영체제가 안고 있는 가장 절실한 문제는 소프트웨어에 대한 부분이 아니라 운영체제에 함께 포함시킬 양질의 문서가 부족하다는 점이다. 문서 자료는 모든 소프트웨어에 있어서 필수적인 부분이다. 만약 핵심적인 자유 소프트웨어가 자유롭게 이용할 수 있는 좋은 문서 자료 없이 제공된다면 이는 심각한 문제라고 할 수 있는데, 현재 우리는 이러한 문제를 많이 갖고 있다.

자유 소프트웨어와 마찬가지로 자유 문서에는 가격이 아닌 자유가 중요한 관건이 된다. 자유 문서의 판단 기준은 자유 소프트웨어와 거의 같다고 할 수 있다. 즉 모든 사용자에게 자유를 허용하는가이다. 상업적 판매를 포함한 재배포가 온라인 또는 서적의 형태로 모두 허용되어야 하며, 이러한 문서 자료가 해당 프로그램과 함께 제공될 수 있어야 한다.

개작에 대한 허용 또한 필수적인 부분이다. 그러나 나는 일반적으로 모든 종류의 글과 책을 개작할 수 있도록 허용해야 한다고 생각하지는 않는다. 예를 들면, 여러분이 읽고 있는 바로 이글과 같이 우리들의 생각이나 활동을 설명한 글을 개작할 수 있도록 허용할 필요는 없는 것이다.

그러나 자유 소프트웨어를 위해서는 문서에 대한 개작의 허용이 필수적인 것이라고 할 수 있다. 소프트웨어를 개작할 수 있는 권리를 사용해서 소프트웨어를 수정하거나 새로운 기능을 추가했다면 자신의 작업을 책임있게 마무리 하기 위해서 기존의 매뉴얼을 변경된 기능에 맞는 보다 정확하고 유용한 문서로 고치려고 할 것이다. 그러나 만약 프로그래머들에게 이러한 작업이 허용되지 않는다면, 결국 공동체가 필요로 하는 요구들을 충족시키지 못하게 되는 것이다.

문서의 수정 형태에 대한 외형적인 제한 조건을 설정하는 것은 경우에 따라서 별다른 문제가 되지 않는다. 예를 들면, 원저작자의 저작권 사항이나 배포 조건 또는 저자들의 명단을 보존해야 한다는 제한이나 문서가 수정되었다는 사실을 명시해야 한다는 제한 그리고 수정되지 않은 부분은 그대로 남겨두어야 한다는 등의 제한 조건은 이러한 부분이 기술적인 내용을 담고 있지 않는 한 큰 문제가 되지 않는다. 왜냐하면 이러한 종류의 제한들은 프로그래머들이 개작된 프로그램에 맞게 매뉴얼을 수정하는 데 별다른 지장을 주지 않기 때문이다. 즉 이러한 제한들은 공동체가 매뉴얼을 온전히 활용하는 것을 제한하는 않기 때문에 문제가 되지 않는다.

그러나 기술적인 내용에 관련된 부분들은 모두 수정할 수 있어야 하며 수정된 문서는 어떠한 배포 매체와 배포 방법을 통해서도 배포될 수 있어야 한다. 그렇지 않다면 이러한 제한들은 공동체의 필요를 가로막는 장애가 되어 결국 자유롭게 사용할 수 있는 또다른 매뉴얼이 필요할 것이다.

그렇다면 자유 소프트웨어의 개발자들이 모든 종류의 매뉴얼을 만들 필요성을 인식하고 이를 실천할 수 있을까? 다시 한번 반복되는 말이지만, 우리의 미래는 다름아닌 우리들 자신의 철학에 달려있는 것이다.

우리는 자유에 대해서 얘기 해야만 한다.

오늘날에는 대략 천만명 정도의 사람들이 레드햇 “리눅스나” 데비안 리눅스와 같은 GNU/Linux 시스템을 사용하고 있는 것으로 추산된다. 대부분의 사람들은 실용적인 목적에 따라 움직이며 자유 소프트웨어는 이러한 부분들을 하나둘씩 쌓아왔다.

대중적이라는 측면이 가져오는 긍정적인 결과는 명확한 것이다. 이전에 비해서 자유 소프트웨어의 개발에 많은 관심을 갖게 될 것이며 자유 소프트웨어 산업에 보다 많은 고객층이 형성될 것이다. 또한 독점 소프트웨어 제품을 개발하는 대신 상용 자유 소프트웨어를 개발하도록 기업들을 더욱 많이 장려할 수 있을 것이다.

그러나 자유 소프트웨어의 바탕에 깔려있는 본질적인 철학적 인식 보다 자유 소프트웨어 자체에 대한 관심이 너무도 빨리 증가하고 있다는 것이 우리가 당면해 있는 문제이다. 지금까지 4개의 범주로 나눠서 설명했던 미래에 대한 도전과 위협들을 극복해 나갈 수 있는 능력은 자유를 지키겠다는 우리들의 단호한 의지에 달려있다. 우리의 공동체가 이러한 의지를 견지하기 위해서는 우리와 합류하려는 사람들에게 이러한 철학적 생각들을 깊게있게 인식시켜 주어야 한다.

그러나 지금까지는 그렇게 하지 못했다고 볼 수 있다. 공동체의 일원들에게 의식을 심어주는 것보다 우선 공동체 안으로 끌어들이려는 노력이 우세했던 것이다. 그러나 우리는 2가지를 작업을 함께 병행해야 하며 이러한 노력들이 균형을 이루도록 힘써야 한다.

“오픈 소스”

1998년 부터는 새로운 사용자들에게 자유에 대해서 이야기 하는 것이 더욱 어려워졌다. 왜냐하면 공동체의 일부에서 “자유 소프트웨어”라는 말 대신 “오픈 소스 소프트웨어”라는 표현을 사용하기 시작했기 때문이다.

이 용어를 선호하는 사람들의 의도는 “자유”를 의미하는 영어 단어인 “free”가 갖고 있는 무료(無料)와 자유(自由)라는 의미상의 혼란을 방지하기 위한 것으로 이는 타당한 것이라고 할 수 있다. 그러나 또다른 사람들은 “자유”라는 단어가 함축하고 있는 자유 소프트웨어 운동과 GNU 프로젝트의 정신을 의도적으로 퇴색시키기 위해서 “오픈 소스”라는 표현을 사용하고 있으며 자유나 공동체 보다는 이윤에 더 높은 가치를 부여하는 기업 경영인과 사용자들에게 보다 친밀하게 다가서기 위해서 이 말을 사용하기도 한다. 따라서 “오픈 소스”라는 용어는 높은 품질과 강력한 성능을 가진 소프트웨어를 만들 수 있다는 가능성에 초점을 맞춘 말이기 때문에 자유와 공동체 그리고 원칙과 같은 개념을 의도적으로 전달하지 않으려는 표현이라고 할 수 있다.

“리눅스 XXX” 등과 같이 리눅스라는 단어가 제호로 들어간 잡지들은 그 분명한 실례의 하나이다. 이러한 잡지에는 GNU/Linux에서 사용 가능한 독점 소프트웨어의 광고들로 가득 차 있다. Motif나 Qt와 같은 종류의 라이브러리가 다시 생겨났을 때 과연 이러한 잡지들이 프로그래머들에게 그 위험성을 경고해 줄 것인지 아니면 그 제품의 광고를 실을 것인지는 명확하지 않은가?

기업이 제공하는 지원은 공동체에 여러가지 방법으로 도움이 될 수 있지만 그 이외의 것들 또한 마찬가지로 유용하다. 그러나 자유에 대해서 말하지 않는 방법으로 이러한 지원을 받아낸다면 이는 화를 자초하는 것이라고 할 수 있으며, 보다 많은 사용자들을 공동체 안으로 끌어 들이려는 노력과 공동체의 성원들에게 철학적 인식을 심어주려는 우리의 2가지 목적 안에 존재했던 불균형을 더욱 심화시키는 결과가 될 것이다.

“자유 소프트웨어”와 “오픈 소스”는 같은 부류의 소프트웨어를 가리키는 말이다. 그러나 그 차이점은 소프트웨어와 가치에 대해서 서로 다른 입장을 갖고 있다는 것이다. GNU 프로젝트는 기술적인 측면 그 자체보다 훨씬 중요하다고 생각하는 “자유”라는 이념을 피력하기 위해서 “자유 소프트웨어”라는 용어를 계속해서 사용할 것이다

노력하라!

There is no “try.”라는 요다의 철학(역자주: 영화 스타워즈 에피소드 5편에 나오는 제다이의 스승 요다의 말로 시도해 본다는 것은 의미가 없고 확신을 갖고 실행하는 것만이 포스의 힘을 불러낼 수 있다는 의미이다. 원문은 No! Try not. Do. Or do not. There is no try이다.)은 멋지게 들리지만 내게는 효과가 없는 말이었다. 나는 내가 이 일은 해낼 수 있을까 하는 걱정과 우려 속에서 대부분의 일들을 해왔다. 그러나 내 도시를 침략하려는 적들과 내 도시 사이에는 오직 나밖에 없었기 때문에 나는 최선을 다해서 싸웠으며 때때로 나 자신이 놀랄 정도로 승리를 거두곤 했다.

때로는 패배하기도 해서 나의 도시들 중 몇몇이 파멸되기도 했다. 그러나 또다른 도시가 위협받고 있음을 발견했을 때에는 비장하게 또다른 전투를 준비해 왔다. 싸움이 길어지면서 나는 전운을 감지하는 방법을 체득하게 되었고 다른 해커들의 동맹과 원조를 요청하면서 방어할 도시로 떠나곤 했다.

그러나 나는 이제 혼자가 아니다. 전선을 방어하기 위해서 사투를 벌이고 있는 해커들의 부대를 볼 때 나는 큰 기쁨과 위안을 느낀다. 아마도 이 도시는 건재하리라. 그러나 최근 몇년 사이에 위협은 더욱 커져가고 있으며 마이크로소프트는 우리의 공동체를 노골적으로 위협하고 있다. 우리는 우리가 갖고 있는 자유의 미래가 보장되리라고 확신할 수 없다. 자유가 남아있게 되리라는 막연한 생각은 버려야 한다! 만약, 여러분의 자유가 계속해서 지켜지기를 원한다면 그것을 지킬 준비를 해야만 할 것이다.