diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/ko/thegnuproject.html')
| -rw-r--r-- | talermerchantdemos/blog/articles/ko/thegnuproject.html | 853 |
1 files changed, 853 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/ko/thegnuproject.html b/talermerchantdemos/blog/articles/ko/thegnuproject.html new file mode 100644 index 0000000..0d8a99b --- /dev/null +++ b/talermerchantdemos/blog/articles/ko/thegnuproject.html @@ -0,0 +1,853 @@ +<!--#set var="PO_FILE" + value='<a href="/gnu/po/thegnuproject.ko.po"> + https://www.gnu.org/gnu/po/thegnuproject.ko.po</a>' + --><!--#set var="ORIGINAL_FILE" value="/gnu/thegnuproject.html" + --><!--#set var="DIFF_FILE" value="" + --><!--#set var="OUTDATED_SINCE" value="2005-05-25" --> + +<!--#include virtual="/server/header.ko.html" --> +<!-- Parent-Version: 1.86 --> + +<!-- This file is automatically generated by GNUnited Nations! --> +<title>GNU 프로젝트 - 자유 소프트웨어 재단</title> +<meta http-equiv="Keywords" content="" /> + +<!--#include virtual="/gnu/po/thegnuproject.translist" --> +<!--#include virtual="/server/banner.ko.html" --> +<!--#include virtual="/server/outdated.ko.html" --> +<h2>GNU 프로젝트</h2> + +<p> +글: <a href="http://www.stallman.org/"><strong>리처드 스톨먼</strong></a></p> + +<blockquote> +<p> +이 글은 처음에 “오픈 소스”라는 책에 포함되어 출판되었던 것입니다. +</p> + +</blockquote> + +<h3>소프트웨어를 공유했던 최초의 공동체</h3> +<p> +<abbr title="Massachusetts Institute of Technology">MIT</abbr> 대학의 인공지능 +연구소에서 일하기 시작했던 1971년부터 나는 소프트웨어를 공유하는 공동체의 일원이 되기 시작했다. 이 공동체는 이미 수년 전부터 +존재하고 있던 것이었으며 MIT에만 유일하게 존재하는 특별한 것은 아니었다. 요리법을 공유하는 것이 요리의 역사만큼 오래된 것처럼, +소프트웨어를 공유하는 것은 컴퓨터의 역사만큼이나 오래된 것이었다. 그러나 우리들은 소프트웨어를 공유해 나가는 더욱 이상적인 우리들만의 +공동체를 MIT에서 만들어 나갔다.</p> +<p> +인공지능 연구소에서는 <abbr title="Incompatible Timesharing System">ITS</abbr> +(Incompatible Time-sharing System)라고 불리는 시분할(time-sharing) 운영체제를 사용하고 있었는데, +ITS는 당시에 사용되던 가장 큰 시스템 중의 하나인 DEC사의 <abbr title="Programmed Data +Processor">PDP</abbr>-10 기종에 탑재할 목적으로 인공지능 연구소의 (1)해커 연구원들에 의해서 어셈블리 언어로 +만들어진 운영체제였다. 인공지능 연구소의 연구원으로서 그리고 공동체를 구성하고 있는 해커의 일원으로서 나는 ITS를 더 나은 시스템으로 +만드는 일에 종사하고 있었다.</p> +<p> +우리는 우리들의 소프트웨어를 “자유 소프트웨어”라고 말하지는 않았다. 왜냐하면 그 당시까지만 해도 “자유 +소프트웨어”라는 용어가 아직 존재하지 않았기 때문이다. 하지만 우리가 만들었던 소프트웨어의 모습는 지금의 “자유 +소프트웨어”가 의미하는 바로 그것이었다. 다른 대학이나 기업에서 우리가 만든 프로그램을 사용하거나 다른 시스템으로 이식하기 +위해서 우리에게 도움을 요청할 때면 우리는 언제든지 우리의 프로그램을 그들에게 빌려주었다. 이러한 형태는 매우 일반적인 것이어서 새롭고 +흥미로운 프로그램을 사용하고 있는 사람을 발견했다면 언제든지 그 사람에게 프로그램의 소스 코드를 보여 달라고 요청할 수 있었다. 공동체의 +시절 - 그 당시는 특정한 프로그램의 소스 코드를 자유롭게 얻을 수 있었기 때문에 프로그램을 수정하거나 그 프로그램을 기반으로 한 새로운 +프로그램을 만들 수 있는 가능성이 언제든지 열려있었던 공유의 정신이 충만한 시절이었다.</p> +<p> +(1) 해커라는 단어가 시스템의 보안을 뚫고 들어가서 해악한 일을 저지르는 침범자의 의미로 사용되고 있는 현재의 관행은 대중 매체에 +의해서 오도된 경향이 크다고 할 수 있다. 우리 해커들은 이 단어를 침범자라는 의미가 아닌 “프로그램을 만들기 좋아하고 +능숙하게 다룰 수 있는, 즉 프로그램 자체를 즐기는 사람”이라는 의미로 사용하고 있다.</p> + +<h3>공동체의 붕괴</h3> +<p> +이러한 상황은 1980년대 초에 DEC사가 PDP-10 시리즈의 생산을 중단하면서 부터 급격하게 붕괴되었다. 1960년대를 풍미했던 +PDP-10 시리즈의 강력하고 우아한 설계 구조도 1980년대로 접어들면서 어드레스 공간을 더이상 자연스럽게 확장할 수 없었기 때문에 +DEC사는 32비트 기반의 VAX를 주력 기종으로 삼으면서 PDP-10 시리즈를 퇴역시켰는데, PDP-10 시리즈의 단종은 ITS +환경에서 만들어진 거의 모든 프로그램들이 호환성의 문제로 인해서 더이상 사용될 수 없다는 것을 의미했다.</p> +<p> +인공지능 연구소를 중심으로 한 해커들의 공동체도 PDP-10과 함께 붕괴되기 시작해서 1981년에는 인공지능 연구소에서 근무하던 대부분의 +해커들이 스핀오프(spin-off) 회사인 심볼릭스(Symbolics)로 직장을 옮기게 되었다.(<b>역자주:</b> 스핀오프란 대학이나 +기업 연구실의 연구원들이 독립해서 설립하거나 깊이 관여하고 있는 회사를 말한다.) 스티브 레비(Steve Levy)의 저서인 +“해커들”(<b>역자주:</b> 한국에는 사민서각이라는 출판사에 의해서 “해커 - 그 광기와 비밀의 +기록”이라는 이름으로 번역 출판되었다.)에는 이러한 상황들이 전성기 때의 공동체에 대한 일화와 함께 자세히 묘사되어 있는데, +해커들의 이직에 따른 가장 큰 문제는 바로 공동체 자체를 유지할 만한 인적 자원이 없어진다는 것이었다. 인적 자원의 부족은 결국 +1982년에 인공지능 연구소에서 구입한 PDP-10을 운영하기 위해서 ITS가 아닌 DEC의 운영체제를 도입하는데까지 이르게 +되었다. 물론, DEC의 운영체제는 자유 운영체제가 아니었다.</p> +<p> +당시에 소개되었던 VAX나 68020과 같은 현대적인 모델의 컴퓨터들은 전용 운영체제를 탑재하고 있었는데, 이들은 모두 자유 소프트웨어가 +아니었다. 따라서 바이너리 형태의 프로그램을 사용하고자 할 때 조차도 관련 자료를 유출하지 않겠다는 비공개 계약 조건에 동의해야만 했다.</p> +<p> +이러한 사실은 컴퓨터를 사용하는 처음 단계부터 자신의 주위 사람들을 돕지 않겠다고 약속하는 것과 같은 의미를 갖는다. 즉 상호 협력적인 +공동체는 처음부터 불가능하게 되는 것이다. 독점 소프트웨어의 소유자들은 소프트웨어를 공유하는 것을 “저작권 +침해(pirate)”라는 단어를 사용해서 마치 해적 행위와 같이 해악한 것과 동일시 하려고 했으며, 프로그램에 대한 수정이 +필요할 때는 그들에게 이를 요청하도록 했다.</p> +<p> +독점 소프트웨어 제도는 소프트웨어를 다른 사람들과 함께 공유하거나 교환하는 것을 금지하기 때문에 결코 사회적인 제도라고 할 수 +없다. 이는 분명하게 잘못된 비윤리적인 제도이지만, 이러한 나의 주장이 어떤 사람들에게는 충격적인 사실로 받아들여질 수도 있을 +것이다. 그러나 사용자들을 각각 고립시키고 서로가 서로를 돕는 것을 금지하는 방법으로 사람들을 무력하게 만드는 제도에 대해서 우리가 +언급할 수 있는 것은 과연 무엇이겠는가? 만약, 독점 소프트웨어 제도에 대한 나의 생각에 대해서 거부감이 느껴진다면 아마도 그 사람은 +독점 소프트웨어 산업이 유포해 왔던 개념들을 아무런 의심없이 그대로 인정해 왔기 때문이라고 할 수 있다. 소프트웨어 제작업자들은 +소프트웨어의 유통 형태에 대해서 기존의 방식이 유일한 방법이라는 생각을 사람들에게 각인시키기 위해서 오랫동안 노력해 왔다.</p> +<p> +소프트웨어 제작업자들이 사용하는 “저작권 침해 행위를 중단하라”거나 “우리의 권리를 +행사한다”는 등의 표현은 표면적인 것일 뿐이며, 그들이 의도하는 숨겨진 진의는 법률적이고 과격한 표현을 사용함으로써 대중들로 +하여금 그들의 주장을 비판없이 수용하게 만들려는 데 있다.</p> +<p> +구체적인 예를 살펴보면, 일반 사용자들이 소프트웨어 회사들의 권리를 “침해”한다든가 또는 소프트웨어 회사들이 그들의 +정당한 “권리를 행사”한다는 표현 안에는 마치 소프트웨어 제조 회사들이 소프트웨어를 유형, 무형으로 완전히 소유할 +수 있는 천부적인 자연권을 갖고 있어서 소프트웨어에 대한 사용자들의 권리를 통제할 수 있다는 전제가 포함되어 있다. 만약, 그들의 권리가 +진정한 자연권이라면 대중이 그들로부터 어떠한 피해를 입는다 하더라도 이에 반대하거나 저항할 수 없을 것이다. 그러나 한가지 흥미로운 +사실은 미국의 헌법과 법률 전통 안에서는 저작권이 자연권 안에 포함되지 않음에도 불구하고 연방 정부가 인위적으로 부여한 독점권에 의해서 +소프트웨어를 자유롭게 복제할 수 있는 사용자들의 권리가 제한당하고 있다는 점이다.</p> +<p> +소프트웨어 제조 회사들이 사용하는 표현에 내포되어 있는 또하나의 가정은 소프트웨어에 있어서 중요한 것은 오직 소프트웨어를 이용해서 수행할 +수 있도록 사용자들에게 허용된 작업 자체이지 작업 과정을 통해서 형성될 수 있는 사람들간의 만남과 교류는 아니라는 점이다. 만약, 이러한 +점들이 중요하게 고려되었다면 사람들간의 만남과 교류를 통해서 소프트웨어가 공유될 수 있다는 무척이나 자연스러운 발상에 근거해서 +소프트웨어를 공유하거나 소스 코드를 보여주는 행위를 “권리의 침해”라는 강압적인 표현으로 오도하지는 못할 +것이다. 그들이 중요하게 생각하는 것은 소프트웨어를 이용해서 최대한의 재화를 창출하는 것이기 때문에 소프트웨어에 대한 적용 범위와 고려의 +대상을 사용자들의 만남과 교류가 아닌 작업 그 자체로 한정시킨 것이다.</p> +<p> +또한 “권리의 침해”나 “권리의 주장”이라는 표현 안에는 소프트웨어를 창작하고 수정하는 등의 +모든 권한이 소프트웨어 제조 회사에 귀속되어 있으므로 그들의 주장을 인정하고 수용하지 않으면 특정한 작업을 수행할 수 있는 프로그램이나 +그밖의 유용한 소프트웨어들을 전혀 사용할 수 없게 되리라는 강압적인 또하나의 잘못된 가정이 포함되어 있기도 하다. 이러한 가정은 매우 +설득력 있게 들릴 수도 있지만 자유 소프트웨어 운동이 구속과 통제가 없는 많은 양의 자유 소프트웨어들을 만들어 냄으로써 그 오류를 +불식시킬 수 있었다.</p> +<p> +만약, 이러한 가정들을 거부하고 사용자를 최우선으로 고려한 일반적인 상식과 윤리의 기준에서 이 문제를 판단한다면 우리는 매우 다른 결론에 +도달하게 된다. 사람들이 서로 돕는 것은 이 사회를 지탱해 나가는 근간이 되므로 결국 사용자들은 그들의 필요에 따라서 프로그램을 자유롭게 +수정하거나 공유할 수 있는 것이다.</p> +<p> +이러한 결론이 도출되는 보다 엄밀한 추론 과정은 지면 관계상 생략하기로 한다. 그러나 GNU 홈페이지에 올려져 있는 <a +href="/philosophy/why-free.html">http://www.gnu.org/philosophy/why-free.html</a> +문서를 통해서 보다 자세한 내용들을 참고할 수 있을 것이다. +</p> + +<h3>냉혹한 도덕적 선택</h3> +<p> +공동체가 사라짐에 따라서 이 공동체를 예전처럼 지탱해 나가는 것은 불가능했고, 그대신 나는 냉혹한 도덕적 선택의 기로에 서게 되었다.</p> +<p> +손쉬운 선택은 비공개 협약에 서명하고 동료 해커들을 돕지않겠다는 것을 약속하면서 독점 소프트웨어의 세계에 합류하는 것이었다. 만약 그렇게 +했다면 내가 개발했을 소프트웨어 또한 비공개 협약에 의해서 배포되었을 것이므로 다른 사람들이 그들의 동료를 돕지 못하도록 강요하는 +또하나의 요인이 되었을 것이다.</p> +<p> +나는 이러한 방법으로 돈을 벌 수 있었을 것이며 아마도 프로그램을 만드는 작업으로 부터 즐거움을 누릴 수도 있었을 것이다. 그러나 훗날 +내 인생을 정리하면서 내가 보내온 과거를 돌이켜 봤을 때 내가 사람들을 단절시키는 벽을 만들어 왔으며 또한 이 세상을 보다 나쁘게 만들어 +왔다는 것을 느끼게 될 것이라는 점도 알고 있었다.</p> +<p> +나는 MIT의 인공지능 연구소와 나에게 제어 프로그램의 소스 코드를 줄 것을 거부했던 사람으로 인해서 프린터의 사용에 곤란을 겪은 경험을 +갖고 있었기 때문에 이러한 비공개 협약이 가져올 결과를 이미 알고 있었다.(프로그램에 특정한 기능이 결여되어 있었기 때문에 프린터를 +사용하는데 많은 곤란을 겼었다.) 그래서 나는 비공개 협약은 결코 유익하지 않다는 생각을 갖고 있었다. 그가 소스 코드를 함께 공유하기를 +거부했을 때 나는 매우 분개했으며, 나는 결코 같은 짓을 다른 사람들에게 하지 않겠다고 다짐했던 것이다.</p> +<p> +보다 간단하지만 결코 유쾌하지 않은 또하나의 선택은 컴퓨터 분야를 떠나는 것이었다. 이 선택은 내가 갖고 있는 기술이 내가 원하지 않는 +방향으로 사용되지 않도록 할 수 있지만, 다른 측면에서 보면 내가 가진 기술이 허비되는 것이라고 할 수 있다. 만약, 이 방법을 +선택했다면 컴퓨터 사용자들을 제한하고 단절시키는 일을 직접 하지는 않았을 것이므로 내가 비난의 대상이 되지는 않았겠지만, 그럼에도 +불구하고 그러한 일들은 계속해서 일어났을 것이다.</p> +<p> +이러한 이유로 인해서 나는 프로그래머가 뭔가 좋은 역할을 할 수 있는 방법을 찾게 되었다. 나는 생각했다. 공동체를 다시 부활시키기 +위해서 내가 직접 만들 수 있는 프로그램이 없을까?</p> +<p> +해답은 명확했다. 제일 먼저 필요한 프로그램은 바로 운영체제였던 것이다. 운영체제는 컴퓨터를 사용하기 위해서 필요한 가장 핵심적인 +소프트웨어이다. 운영체제가 있다면 컴퓨터를 이용해서 다양한 종류의 작업을 할 수 있지만, 만약 운영체제가 없다면 컴퓨터 자체를 사용할 수 +없게 된다. 따라서 자유롭게 사용할 수 있는 운영체제를 가질 수 있다면 상호 협력적인 해커들의 공동체를 다시 한번 재건할 수 있을 것이며 +어떠한 사람에게도 공동체에 합류하기를 권유할 수 있게 될 것이다. 또한 운영체제의 구입에 수반되는 “재배포를 +금지한다.”는 등의 계약 조건에 구애받을 필요가 없어지므로 친구들의 자유를 침해하지 않고도 누구나 컴퓨터를 사용할 수 있게 될 +것이다.</p> +<p> +운영체제의 개발자로서 나는 이러한 작업에 적합한 기술을 갖고 있었다. 그래서 성공하지 못할 가능성이 있음에도 불구하고 나는 이 일이 나의 +소명이라고 생각하게 되었다. 나는 새롭게 개발할 운영체제를 유닉스와 호환되도록 만들 생각을 했다. 그렇게 함으로써 이식성을 갖게 되고 +기존의 유닉스 사용자들이 새로운 시스템에 쉽게 적응할 수 있으리라고 생각했기 때문이다. GNU라는 이름은 MIT의 해커들이 프로그램의 +이름을 지을 때 사용하던 재귀적 약어(recursive acronym)의 습관을 반영한 것으로 GNU's Not Unix 즉 +“GNU는 유닉스가 아니다.”라는 뜻이 되도록 GNU라는 단어를 처음부터 의도적으로 조합해서 만든 +것이다. 예를들면, EINE라는 이름의 에디터는 Emacs가 아니라는 의미로 “Eine Is Not Emacs”라는 +문구를 먼저 생각한 뒤에 여기서 각 단어의 첫 글자를 따서 EINE라는 이름이 되도록 만든 것이며, CYGNUS는 +“Cygnus Your GNU Support” 라는 문구를 이용해서 만든 것이다. 따라서 GNU는 유닉스와 +호환되도록 만들어진 운영체제이기는 하지만 유닉스와는 다른 운영체제라는 의미를 내포시키기 위해서 만든 이름이라고 할 수 있다.</p> +<p> +운영체제는 단순히 커널만을 의미하는 것이 아니라 여러가지 프로그램들을 실행시킬 수 있는 통합적인 시스템 운영 환경을 의미하는 +것이다. 1970년대에 운영체제라고 말할 수 있을 만한 것들은 모두 셸과 같은 명령어 처리기와 어셈블러, 컴파일러, 인터프리터, 디버거, +텍스트 에디터 그리고 메일 프로그램과 같은 다양한 종류의 프로그램들을 갖고 있었다. ITS와 멀틱스(Multics), VMS, 유닉스 +등의 운영체제들도 이러한 프로그램들을 포함하고 있었고, 따라서 이제부터 시작될 GNU 운영체제에도 이러한 프로그램들이 모두 필요했다.</p> +<p> +훗날 나는 유대교의 랍비 (2) 힐렐(Hillel)이 말했다는 다음과 같은 잠언을 듣게 되었는데, GNU 프로젝트를 시작하게 된 결단은 +이러한 정신과 일맥 상통한다고 볼 수 있다.</p> + +<blockquote><p> + 내가 내 자신을 위하지 못한다면, 그 누가 나를 위해 줄 것인가?<br /> + 내가 내 자신만을 위한다면, 온전한 나 자신이 될 수 있을까?<br /> + 바로 지금이 아니라면, 그 언제 할 수 있을 것인가? +</p></blockquote> +<p> +(2) 무신론자로서 나는 어떠한 종교 지도자도 따르지 않지만, 때때로 그들이 남긴 금언에 내가 탄복하고 있다는 사실을 깨닫곤 +한다.(<b>역자주:</b> 위의 금언은 탈무드 토라의 “위대한 세명의 랍비” 장에서 인용된 것으로, 힐렐은 예수 +탄생전에 실존했던 유대 랍비의 이름이다.)</p> + +<h3>구속되지 않는다는 관점에서의 자유</h3> +<p> +자유 소프트웨어라는 용어는 때때로 잘못 이해되기도 하는데, 이 말은 무료나 공짜라는 말이 내포하고 있는 금전적인 측면과는 전혀 관계없는 +“구속되지 않는다”는 관점에서의 자유를 의미한다. 다른 언어와는 달리 영어에는 무료(gratis)를 의미하는 단어와 +자유(freedom)를 의미하는 단어가 별도로 존재하지 않고 모두 free라는 단어를 사용하기 때문에 이러한 오해의 소지가 더욱 많다고 +할 수 있지만, 무료 맥주(free beer)나 언론의 자유(free speech)와 같은 예를 생각해 보면 그 차이를 보다 명확하게 +구분할 수 있을 것이다. 한국어의 경우에는 한자 문화권의 영향으로 이러한 2가지 경우에 대해서 무료(無料)나 무상(無償)이라는 단어와 +자유(自由)라는 단어를 선택적으로 사용할 수 있기 때문에 “자유 소프트웨어”라는 용어상에 존재하는 혼란이 영어에서 +비해서 비교적 적은 편이라고 할 수 있다.</p> + +<p>그러나 이러한 언어상의 차이에 관계없이 중요한 것은 “자유”가 의미하는 본질적인 부분이며 사용자에게 다음과 같은 +4가지 종류의 자유를 실질적으로 보장하는 프로그램을 자유 소프트웨어라고 말할 수 있다.</p> + +<ul> + <li>목적에 상관없이 프로그램을 실행시킬 수 있는 자유</li> + + <li>필요에 따라서 프로그램을 개작할 수 있는 자유(이러한 자유가 실제로 보장되기 위해서는 소스 코드를 이용할 수 있어야만 한다. 왜냐하면 +소스 코드 없이 프로그램을 개작한다는 것은 매우 어려운 일이기 때문이다.)</li> + + <li>무료 또는 유료로 프로그램을 재배포할 수 있는 자유</li> + + <li>개작된 프로그램의 이익을 공동체 전체가 얻을 수 있도록 이를 배포할 수 있는 자유</li> +</ul> +<p> +“자유” 라는 단어는 금전적인 측면이 아닌 구속되지 않는다는 관점에서의 자유를 의미하기 때문에 자유 소프트웨어를 +유료로 판매하는 데에는 어떠한 모순도 존재하지 않는다. 실제로 소프트웨어를 판매할 수 있는 자유는 매우 중요하며, 자유 소프트웨어들을 +모아서 CD-ROM의 형태로 판매하는 것은 자유 소프트웨어의 발전 기금을 조성할 수 있는 실질적인 방법이 되기 때문에 공동체에 있어서 +매우 중요한 부분이다. 따라서 임의의 배포판이나 소프트웨어 모음집에 자유롭게 포함시킬 수 없는 프로그램은 자유 소프트웨어가 아니라고 할 +수 있다.</p> +<p> +자유라는 단어가 갖고 있는 모호함 때문에 사람들은 오랫동안 이를 대체할 수 있는 용어를 생각해 왔지만, 적절한 용어를 찾지는 +못했다. 영어는 다른 언어에 비해서 많은 단어와 뉘앙스를 갖고 있지만 간단 명료함을 갖고 있지는 못하다. 자유 소프트웨어라는 용어에서 +사용되는 free라는 단어는 unfettered, 즉 해방(解放)시킨다는 의미와 같은 뜻이라고 할 수 있을 것이다. liberated나 +freedom 또는 open이라는 단어들은 이 단어들이 갖고 있는 다른 의미나 단점들 때문에 free 대신 사용하기에 문제가 있다고 +생각한다.(<b>역자주:</b> 이러한 점들은 영어 뿐만 아니라 한국어에도 동일하게 적용되는 것으로 자유 소프트웨어 대신에 무료나 공개, +해방 소프트웨어와 같은 단어는 원어인 free가 갖고 있는 의미를 그대로 살리지 못한다고 볼 수 있기 때문에 “자유 +소프트웨어”라고 용어가 가장 좋은 형태라고 생각한다.)</p> + +<h3>GNU 소프트웨어와 GNU 시스템</h3> +<p> +완전한 운영체제 전체를 만든다는 것은 매우 커다란 프로젝트에 해당한다. 따라서 나는 기존에 존재하던 사용 가능한 자유 소프트웨어들을 +개작하거나 취합해서 시스템을 완성시켜 나갈 생각을 하게 되었다. 예를들면, 프로젝트가 시작되었던 초반에는 TeX(텍)을 주된 조판 +프로그램으로 사용했으며, 몇년 뒤에는 GNU에 맞는 새로운 윈도우 시스템을 개발하는 것 대신에 X 윈도우 시스템을 사용하기로 결정했다.</p> +<p> +이러한 결정으로 인해서 GNU 시스템은 단순히 GNU 소프트웨어들을 모두 모아놓은 것 이상의 것이 되었다. GNU 시스템은 GNU +소프트웨어 뿐만 아니라 그들만의 목적을 가진 다른 사람이나 프로젝트를 통해서 만들어진 소프트웨어도 포함하게 되었는데 이는 이 프로그램들이 +자유 소프트웨어이기 때문에 가능한 것이었다. 일반적으로 “그뉴”라고 발음하는 GNU라는 이름은 GNU 프로젝트와 +GNU 시스템을 지칭하는데 모두 사용된다. GNU 시스템은 GNU 프로젝트를 통해서 구현하려고 하는 유닉스와 호환되는 완벽한 소프트웨어 +시스템 전체를 말하며 GNU 프로젝트는 이러한 시스템을 구현하기 위해서 진행되고 있는 프로젝트 자체를 의미한다.</p> + +<h3>프로젝트의 시작</h3> +<p> +1984년 1월에 나는 MIT의 연구원직을 사임하고 GNU 소프트웨어를 만들기 시작했다. 내가 MIT를 떠난 이유는 연구원이 개발한 +소프트웨어에 대한 저작권을 소속 회사나 학교로 귀속시킬 수 있는 법률과 내규에 따라서 MIT 당국이 내가 개발한 소프트웨어를 자유 +소프트웨어로 만들지 못하게 할 가능성이 있었기 때문이다. 만약, 내가 MIT의 연구원으로 남아있게 되면 그들이 결과물에 대한 소유권을 +주장하거나 MIT의 배포 조항을 강제로 적용할 가능성도 있었으며, 심지어 독점 소프트웨어 패키지로 만들 가능성도 배제할 수 +없었다. 그러나 나는 공동체 모두가 공유할 수 있는 새로운 소프트웨어를 만들려는 나의 의도가 이러한 외적 조건들로 인해서 좌절되는 것을 +원하지 않았다.</p> +<p> +한편, 내가 연구원직을 사임했음에도 불구하고 MIT의 인공지능 연구소장이었던 윈스턴(Patrick Winston) 교수는 내가 연구실의 +장비들을 계속해서 사용할 수 있도록 배려해 주었다.</p> + +<h3>첫번째 단계</h3> +<p> +GNU 프로젝트를 시작하기 얼마전에 나는 VUCK라는 이름으로도 알려진 자유 대학 컴파일러 킷(Free University +Compiler Kit)에 대한 얘기를 듣게 되었다.(약어로 사용된 VUCK가 Free의 첫자인 F로 시작되지 않는 것은 free에 +해당하는 독일어가 V로 시작되기 때문이다.) 이 컴파일러는 C와 파스칼을 포함한 여러개의 언어를 컴파일할 수 있었고 다양한 종류의 +플랫폼에서 사용할 수 있도록 만들어진 것이었다. 나는 VUCK의 개발자에게 GNU가 이 컴파일러를 사용할 수 있는 지의 여부를 서신으로 +물어보았다.</p> +<p> +자유 대학(Free University)이라는 이름 안에서의 free는 종교로부터 자유롭다는 의미로 사용된 것이다. 그는 대학은 +자유롭지만 컴파일러는 그렇지 않다며 비웃는 듯한 회신을 보내왔다. 즉, 대학의 이름에는 자유라는 단어가 포함되어 있지만 VUCK는 +학생들에게 결코 자유로운 소프트웨어가 아니었던 것이다.(<b>역자주:</b> 리차드 스톨만에게 도착한 회신은 독일어가 아닌 영어로 되어 +있었기 때문에 free라는 영어 단어가 정확히 어떤 의미로 사용되었는 지 자신도 알 수 없다는 리차드 스톨만의 확인이 있었다. 단지, +정확하게 말할 수 있는 것은 VUCK가 “자유 소프트웨어”는 아니었다는 점이다. 아마도 V는 Verfuegung이나 +Verfuegungsfreiheit의 첫자로 추측해 볼 수 있지만, 이를 확인할 방법은 없다.) 이러한 이유로 인해서 나는 GNU +프로젝트를 위한 첫번째 프로그램으로 다수의 언어와 플랫폼을 지원하는 컴파일러를 만들 결심을 하게 되었던 것이다.</p> +<p> +컴파일러 전체를 모두 작성해야 하는 수고를 피할 수 있으리라는 희망을 갖고 나는 로렌스 리버모어 연구소(Lawrence Livermore +Lab)에서 개발한 파스텔(Pastel) 컴파일러의 소스 코드를 입수했다. 이 컴파일러는 멀티 플랫폼을 지원하는 것이었으며 시스템 +프로그래밍 언어로 사용할 목적으로 파스칼 언어를 확장한 파스텔 언어로 만들어진 것이었다. 물론, 파스텔 컴파일러는 파스텔 언어를 컴파일 +하는데 사용되는 것이다. 파스텔 컴파일러는 파스텔 언어가 컴파일된 것이었기 때문에 나는 C 언어를 처리하기 위한 프론트 +엔드(front-end) 부분을 덧붙여서 모토롤라의 68000 시스템에 맞게 이식하기 시작했다. 그러나 파스텔 컴파일러를 사용하기 +위해서는 수 MB 용량의 스택(stack)이 필요하다는 사실을 알게 되었을 때 나는 파스텔 컴파일러를 활용하려던 계획을 포기할 수밖에 +없었다. 왜냐하면 68000 기반의 유닉스 시스템에서는 기껏해야 64KB의 스택만을 사용할 수 있었기 때문이다.</p> +<p> +포트란을 비롯한 대부분의 프로그래밍 언어들은 프로그램에서 사용할 변수를 미리 선언하도록 설계되어 있다. 그러나 파스텔 언어는 변수를 그 +사용에 관계없이 임의의 위치에서 선언할 수 있도록 되어 있었기 때문에 선언된 변수와 사용되고 있는 변수에 대한 정보를 올바르게 유지하기 +위해서는 프로그램을 한번에 읽어서 메모리로 모두 올린 뒤에 처리하는 구조를 가질 수밖에 없었고, 이에 따라서 소스 코드와 거의 동일한 +크기의 메모리와 스택이 필요한 상황이 일어날 수밖에 없었다. 즉, 파스텔 컴파일러는 입력 파일 전체를 한번에 파싱해서 이를 하나의 신택스 +트리로 구성한 다음 연속된 명령어로 변환해서 출력 파일을 생성하는 구조를 갖고 있었던 것이다. 그러나 이러한 방식에서는 레지스터와 스택을 +전혀 효율적으로 사용할 수 없기 때문에 나는 새로운 컴파일러를 처음부터 다시 만들어야 한다는 결론을 내리게 되었다. 파스텔 컴파일러를 +포기한 이후에 새로 개발한 컴파일러는 이제 GCC라는 이름으로 알려지게 되었는데, GCC 컴파일러에는 파스텔 컴파일러의 소스 코드를 전혀 +사용하지 않았지만 파스텔에 추가시켰던 C 언어 프론트 엔드는 <abbr title="GNU Compiler +Collection">GCC</abbr>에도 계속해서 사용하려고 노력했다. 그러나 이러한 일들은 모두 이후 몇년 뒤에 이루어진 +것들이었고, 그 당시에는 최우선적으로 GNU Emacs를 만드는 일에 집중하고 있었다.</p> + +<h3>GNU Emacs</h3> +<p> +나는 1984년 9월부터 GNU Emacs를 만들기 시작했으며, 1985년 초에는 제법 쓸만한 상태가 되었다. 나는 vi나 ed의 +사용법을 배우는 데에 관심이 없었기 때문에 유닉스가 아닌 다른 기종에서 편집 작업을 해 왔지만, Emacs를 만든 후에는 유닉스와 다른 +기종의 컴퓨터에서 모두 편집 작업을 할 수 있게 되었다.</p> +<p> +사람들이 GNU Emacs를 사용하고 싶어하는 시점에 되었을 때, 이 에디터를 어떠한 방법으로 배포할 것인가에 대한 의문이 +제기되었다. 물론, 내가 사용하고 있던 MIT 컴퓨터의 익명 FTP 사이트에는 올려둔 상태였다.(이 컴퓨터의 이름은 +prep.ai.mit.edu였으며 GNU의 주된 FTP 사이트가 되었다. 몇년 뒤에 이 시스템을 퇴역시켰을 때도 우리는 그 이름을 새로운 +시스템에서 계속해서 이어나갔다.) 하지만 그 당시에는 Emacs에 관심을 갖고 있는 사람들 중에서 인터넷을 통해 FTP를 이용할 수 있는 +사람이 거의 없었다. 따라서 어떠한 방법으로 Emacs를 구할 수 있는 지를 그들에게 알려주는 것이 문제의 핵심이었다.</p> +<p> +나는 인터넷을 통해서 Emacs를 구해줄 수 있는 친구를 찾아보거나 반송용 우표가 붙어있는 봉투를 테이프와 함께 보내면 PDP-10용 +Emacs를 복사해 주겠다고 말했다. 즉, Emacs를 배포하는데 있어서 금전적인 비용이 우리에게 청구되지 않는 방법을 생각해 냈던 +것이다. 그러나 당시의 나는 직장을 갖고 있지 못했기 때문에 자유 소프트웨어를 통해서 수입을 얻을 수 있는 방법을 구상하고 있었다. 나는 +150달라의 비용을 지불하면 누구에게나 Emacs가 들어있는 테이프를 우송해 주는 방법을 생각해 냈는데, 이러한 판매 방식을 통해서 나는 +자유 소프트웨어를 이용한 사업을 시작하게 되었고 리눅스에 기반한 GNU 시스템 전체를 담고 있는 배포판을 판매하고 있는 현재의 리눅스 +배포판 업체들의 시초가 되었던 것이다.</p> + +<h3>프로그램은 누구에게나 자유로운가?</h3> +<p> +프로그램의 원저작자가 자신의 프로그램을 자유 소프트웨어로 공개했다고 하더라도 그 프로그램이 프로그램을 입수한 모든 사람들에게 자유 +소프트웨어로 남아있게 된다고 할 수는 없다. 예를들면, 저작권이 없는 공개 소프트웨어(<a +href="/philosophy/categories.html#PublicDomainSoftware">public domain +software</a>)는 일종의 자유 소프트웨어라고 할 수 있다. 그러나 공개 소프트웨어는 누구든지 이 프로그램을 개작해서 독점 +소프트웨어로 변형시킬 수 있으며, 저작권이 수반된 많은 종류의 자유 프로그램들도 수정 버전을 독점 소프트웨어로 만드는 것을 쉽게 허용하는 +라이센스에 의해서 배포되고 있다.</p> +<p> +이러한 문제의 전형적인 예는 X 윈도우 시스템에서 찾아볼 수 있다. MIT에 의해서 개발된 X 윈도우 시스템은 자유 소프트웨어로 +배포되었지만 수정 버전에 대한 독점권을 인정하는 라이센스를 갖고 있기 때문에 많은 컴퓨터 회사들이 이 프로그램을 채택하게 되었다. 그들은 +X 윈도우 시스템을 그들이 독점적으로 판매하고 있는 유닉스 시스템에 바이너리 형태로만 추가한 뒤에 기존의 유닉스와 동일한 비공개 계약 +조건에 의해서 관리되도록 만들어 버렸다. 이러한 종류의 X 윈도우 시스템은 유닉스와 마찬가지로 더이상 자유 소프트웨어가 아닌 것이다.</p> +<p> +X 윈도우 시스템의 개발자들은 이러한 결과가 잘못된 것이라고 생각하지 않았으며 오히려 그렇게 되기를 의도하고 있었다. 왜냐하면 그들의 +목적은 “자유”가 아니라 많은 사용자를 가진 프로그램을 만드는 데 “성공”하는 것이었기 +때문이다. 그들은 사용자들이 프로그램에 대한 자유를 갖게 되는가의 여부에 상관없이 오직 많은 사용자를 갖게 되는데만 관심을 두었다.</p> +<p> +이러한 그들의 선택은 결국 “이 프로그램은 자유로운가?”라는 질문에 대한 답을 구할 때 어떤 기준에 의해서 +“자유”의 총량을 산출할 것인가라는 역설적인 상황을 초래하게 만들었다. 만약 MIT의 배포 기준에 따라서 자유를 +판단한다면 X 윈도우 시스템은 자유 소프트웨어라고 할 수 있지만, 일반적인 사용자에게 허용된 자유를 생각한다면 X 윈도우 시스템은 독점 +소프트웨어라고 할 수있다. X 윈도우를 사용하는 대부분의 사용자들은 유닉스와 함께 제공되는 독점 버전을 사용하고 있으며 이러한 버전은 +자유롭게 사용할 수 있는 것이 아니다.</p> + +<h3>카피레프트와 GNU GPL</h3> +<p> +GNU의 목적은 GNU가 널리 알려지는 것이 아니라 사용자들에게 자유를 주는 것이다. 따라서 우리의 배포 기준에는 GNU 소프트웨어가 +독점 소프트웨어로 변질되는 것을 막을 수 있는 조항이 필요했으며, 이를 위해서 (3) +“카피레프트(copyleft)”라는 방식을 사용했다.</p> +<p> +카피레프트는 저작권법을 그 근간으로 하지만 저작권법이 갖고 있는 주된 목적을 반대로 이용해서 소프트웨어를 개인의 소유로 사유화시키는 대신 +자유로운 상태로 유지시키는 수단으로 삼는 것이다.</p> +<p> +카피레프트의 핵심은 프로그램을 실행하고 복제할 수 있는 권리와 함께 개작된 프로그램에 대한 배포상의 제한 조건을 별도로 설정하지 않는한, +개작과 배포에 대한 권리 또한 모든 사람에게 허용하는 것이다. 즉 프로그램에 대한 실행과 복제, 개작, 배포의 모든 자유를 허용하는 +것이다. 이러한 방법을 통해서 “자유 소프트웨어”라는 용어의 핵심인 “자유”를 모든 사람들에게 +보장할 수 있고 프로그램을 입수한 사람은 그 누구도 뺏을 수 없는 권리를 갖게 된다.</p> +<p> +카피레프트가 실제로 유효하려면 개작된 프로그램 또한 자유로와야만 한다. 만약 우리가 만든 프로그램에 기반한 2차적 프로그램이 만들어 +진다면, 이러한 보장이 있어야만 우리 모두가 개작된 프로그램을 사용할 수 있을 것이다. 직업 프로그래머들이 GNU 소프트웨어를 개량하기 +위해서 자원했을 경우에도 카피레프트는 그들의 고용주들이 개작된 프로그램을 독점 소프트웨어로 만들려는 것을 방지할 수 있다.</p> +<p> +프로그램을 사용하는 모든 사람들의 자유를 확실히 보장하기 위해서는 개작된 부분이 자유로와야 한다는 요건은 매우 본질적인 것이다. X +윈도우 시스템을 독점 소프트웨어의 형태로 만든 기업들은 그들의 운영체제와 하드웨어에 X 윈도우를 이식하기 위해서 어느 정도의 수정을 +가했는데, 그들이 수정한 부분은 X윈도우 전체와 비교하면 작은 부분에 불과하지만 하찮은 것은 아니다. 그러나 단지 프로그램을 수정했다는 +이유만으로 사용자들의 자유를 제한할 수 있다면 누구나 이런 방법을 악용해서 쉽게 이익을 얻을 수 있을 것이다.</p> +<p> +위에서 언급한 문제는 자유 프로그램과 그렇지 않은 프로그램을 함께 결합하는 경우와도 연관이 있다. 이러한 결합으로 이루어진 결과물은 +필연적으로 자유 소프트웨어가 될 수 없으며 자유 소프트웨어가 아닌 프로그램이 갖고 있던 자유의 결여가 결국 결과물 전체로 확대되어 버리게 +된다. 프로그램 간의 이러한 결합을 허용하는 것은 배를 침몰시키기에 충분한 구멍을 만드는 것과 같으므로 카피레프트가 가져야 할 가장 +중요한 요건은 바로 이러한 구멍을 막는 것이다. 즉 카피레프트로 배포된 프로그램에 어떠한 첨삭이 일어나거나 다른 프로그램과 함께 +결합된다고 하더라도 그 결과물에는 반드시 카피레프트가 적용되어야만 하는 것이다.</p> +<p> +대부분의 GNU 소프트웨어에는 카피레프트를 실제로 구현한 라이센스 기준인 GNU General Public License가 +사용된다.(<b>역자주:</b> GNU General Public License는 소프트웨어를 배포하기 위해서 GNU가 사용하는 +일반적이고 공개적인 라이센스라는 의미를 갖고 있기 때문에 “GNU 일반 공개 라이센스” 쯤으로 번역할 수 있지만, +대부분의 경우에는 GPL이라는 용어를 사용하므로 우리말로 번역하지 않고 GPL 또는 원어 그대로 GNU General Public +License라고 하는 것이 가장 바람직한 표현 형태이다.) 우리는 상황에 따라서 다른 종류의 카피레프트를 사용하기도 하는데 GNU +매뉴얼의 경우에는 GNU GPL의 엄밀한 조건들이 모두 필요하지 않기 때문에 보다 간단한 형태의 카피레프트를 사용하고 있다.</p> +<p> +(3) 1984년인지 85년인지 정확히 기억나지는 않지만, 돈 홉킨스(Don Hopkins)라는 사람이 내게 편지를 보내온 적이 +있었다.(그는 매우 상상력이 풍부한 친구였다.) 그가 보낸 편지 봉투에는 재미있는 문구가 몇개 쓰여져 있었는데 그 중에 +“카피레프트 – 모든 권리는 취소됩니다.”라는 구절이 있었고 나는 “카피레프트”라는 +단어를 당시에 내가 생각하고 있던 배포 형태를 나타내는 이름으로 사용하게 되었다.</p> + +<h3>자유 소프트웨어 재단</h3> + +<p>Emacs의 사용에 대한 관심이 증가함에 따라서 사람들이 GNU 프로젝트에 참여하기 시작했고 우리는 지금이 기금을 모을 적절한 시기라는 +결정을 하게 되었다. 그래서 1985년에 자유 소프트웨어의 개발을 위해서 면세 혜택이 주어지는 자유 소프트웨어 재단(<a +href="http://www.fsf.org/">Free Software Foundation</a> – FSF)을 설립하게 +된다. 자유 소프트웨어 재단, 즉 <abbr title="Free Software Foundation">FSF</abbr>는 Emacs의 +테이프 배포 사업을 맡게 되었고 점진적으로 다른 종류의 자유 소프트웨어까지 테이프에 담아서 판매했는데 여기에는 GNU 이외의 자유 +소프트웨어들도 포함되었고 매뉴얼의 판매 또한 병행되었다.</p> + +<p>FSF는 기부를 받고 있지만 대부분의 운영 자금은 자유 소프트웨어의 판매와 이와 관련된 부수적인 서비스를 통해서 충당되고 있다. 현재 +FSF는 소스 코드나 바이너리가 담겨 있는 CD-ROM과 인쇄물로 만들어진 매뉴얼(매뉴얼도 카피레프트에 의해서 관리되므로 개작과 재배포가 +허용된다.) 그리고 주문자가 선택한 플랫폼에 맞춰서 모든 소프트웨어들을 컴파일해서 수록한 디럭스 배포판(Deluxe +Distribution)을 판매하고 있다.</p> + +<p>자유 소프트웨어 재단이 고용한 사람들은 그동안 많은 종류의 GNU 소프트웨어 패키지를 만들거나 관리해 왔는데, 이중에서 특히 주목할 만한 +것은 C 라이브러리와 셸이다. GNU C 라이브러리는 GNU/Linux 시스템에서 실행되는 모든 프로그램이 리눅스와 연동하기 위해서 +반드시 필요한 것이다. C 라이브러리는 자유 소프트웨어 재단의 스탭 중 한 사람인 롤랜드 맥그래스(Roland McGrath)가 개발한 +것이며 대부분의 GNU/Linux 시스템에서 사용하고 있는 셸 프로그램인 BASH(배쉬)는 FSF의 고용자였던 브라이언 폭스(Brian +Fox)가 개발한 것으로 <abbr title="Bourne Again Shell">BASH</abbr>는 (4) Bourne Again +SHell의 약자로 사용된 것이다.</p> + +<p>우리는 이러한 프로그램을 개발하기 위해서 기금을 사용했는데, 이는 GNU 프로젝트가 단순히 특정한 작업 도구나 개발 환경에 국한된 것이 +아니기 때문이다. 우리의 목표는 완성된 형태의 운영체제를 만드는 것이며, 이러한 프로그램들은 우리의 목표를 위해서 필요한 것들이었다.</p> + +<p>(4) “Bourne Again Shell”이라는 이름은 유닉스에서 일반적으로 사용되던 셸 프로그램인 +“Bourne Shell (본셸)”에 빗대어 만든 재미있는 표현이다. BASH는 다른 셸들과는 달리 약어 그대로 +배쉬이라고 발음하며, Bourne Again은 발음상 born again이 되어 최초의 셸인 본셸의 재현이라는 의미를 갖게 된다.</p> + +<h3>자유 소프트웨어에 대한 지원</h3> + +<p>자유 소프트웨어가 갖고 있는 철학은 널리 만연되어 있는 특정한 형태의 상업적 관행에 반대하지만 그렇다고 상업 행위 자체를 거부하는 것은 +아니다. 사용자의 자유를 존중하는 사업이라면 우리는 그들의 성공을 기원할 것이다.</p> + +<p>Emacs의 판매는 자유 소프트웨어 사업의 한가지 예라고 할 수 있다. Emacs의 판매 사업을 자유 소프트웨어 재단으로 이관한 뒤에 +나는 또다른 생계 수단을 강구해야만 했는데, 나는 내가 개발했던 자유 소프트웨어와 관련된 서비스를 제공하는 방법을 생각해 내게 +되었다. 여기에는 GNU Emacs를 프로그래밍하거나 GCC를 최적화시키는 방법에 대한 교육과 GCC를 새로운 플랫폼으로 이식하는 작업이 +주가 되는 소프트웨어 개발이 포함되었다.</p> + +<p>오늘날에는 자유 소프트웨어와 관련된 이러한 종류의 사업들이 많은 기업에 의해서 이루어 지고 있다. 어떤 업체들은 자유 소프트웨어로 구성된 +CD-ROM을 판매하기도 하고 또다른 업체들은 사용자들의 질문에 답변해주는 것부터 시작해서 버그를 잡아주거나 프로그램에 새로운 주요 +기능을 추가해 주는 등의 다양한 수준과 요구에 맞는 지원을 유료로 제공하기도 한다. 한 단계 더 나아가서 이제는 새로운 자유 소프트웨어 +제품을 기반으로 사업을 시작하는 기업들도 생겨나고 있다.</p> + +<p>그러나 많은 기업들이 실제로는 단지 자유 소프트웨어와 함께 연동할 수 있는 소프트웨어를 기반으로 한 업체일 뿐임에도 불구하고 자신을 +“오픈 소스”라는 이름과 연관시키고 있다는 사실에 각별히 주의해야 한다. 이러한 기업들은 자유 소프트웨어 업체가 +아니라 그들의 상품을 이용해서 사용자가 자유로부터 멀어지도록 유혹하고 있는 독점 소프트웨어 업체인 것이다. 그들의 제품이 갖고 있는 +유혹은 자유 보다는 편리함인데, 그들은 이것을 “부가가치(附加價値)”라는 이름으로 우리가 수용해 주기를 요구하고 +있다. 그러나 자유라는 측면에서 이를 판단한다면 우리는 이러한 제품을 부가가치가 아닌 “자유감치(自由減値)” +제품이라고 불러야 마땅할 것이다.</p> + +<h3>기술적인 목표</h3> + +<p>GNU의 주된 목표는 자유 소프트웨어가 되는 것이다. GNU가 유닉스에 비해서 기술적인 장점을 전혀 갖지 못하게 된다 하더라도 사용자들이 +서로 협력할 수 있게 함으로써 사회적인 이점은 갖게 될 것이고 사용자들의 자유를 존중하게 된다는 점에서 윤리적인 이점도 있다고 할 수 +있다.</p> + +<p>그러나 우수한 기술의 표준들을 GNU에 수용했던 것은 무척이나 당연한 일이었다. 예를들면, 제한된 영역의 메모리 사용을 극복하기 위해서 +동적 할당 방식의 자료구조를 도입했으며 8비트 코드를 처리할 수 있도록 해서 어떠한 형태의 입력에 대해서도 이를 정상적으로 처리할 수 +있도록 했다.</p> + +<p>또한, 16비트 컴퓨터를 지원하지 않도록 결정함으로써 유닉스에서 채택하고 있던 작은 크기의 메모리로 인한 문제를 없앨 수 있게 되어 +1MB가 넘지 않는 한도에서는 메모리의 사용을 줄이기 위해서 노력할 필요가 없어졌다.(GNU 시스템이 완성될 시점에는 32비트 컴퓨터가 +일반적인 추세가 되리라는 것이 확실했다.) 따라서 프로그램에서 큰 용량의 파일을 처리하는 것이 수월해 졌기 때문에 프로그래머들에게 +입출력에 대한 문제를 고려하지 말고 입력 파일 전체를 메모리로 올려서 사용하도록 권장할 수 있었다.</p> + +<p>결국 이러한 결정은 GNU 프로그램들이 같은 유닉스 프로그램에 비해서 향상된 속도와 신뢰성을 갖도록 해 주었다.</p> + +<h3>기증받은 컴퓨터</h3> + +<p>GNU 프로젝트의 명성이 높아지면서 유닉스가 탑재된 시스템을 기증하는 사람들이 생겨나기 시작했다. GNU를 구성하는 프로그램을 개발하는 +가장 손쉬운 방법은 유닉스 환경에서 먼저 개발한 뒤에 이를 하나씩 GNU에 맞게 수정하는 것이었기 때문에 이러한 시스템은 우리에게 매우 +유용한 것이었다. 그러나 그들은 우리가 유닉스를 사용하는 것이 과연 정당한가라는 윤리적인 문제를 제기해 왔다.</p> + +<p>유닉스는 예나 지금이나 독점 소프트웨어에 해당한다. 그리고 GNU 프로젝트의 철학은 독점 소프트웨어를 사용하지 않겠다는 데 +있다. 그런데, 독점 소프트웨어를 사용해서 자유 소프트웨어를 만든다는 것은 모순이 아니겠느냐는 것이 그들의 주장이었던 것이다. 그러나 +자기 자신을 보호하기 위해서 사용한 무력을 정당 방위로 인정받을 수 있는 것과 같이 다른 사람들이 독점 소프트웨어를 사용하지 않을 수 +있도록 돕기 위해서 자유 소프트웨어를 만드는 과정에 독점 소프트웨어를 사용할 필요가 있다면, 나는 이것 또한 정당화될 수 있다는 결론을 +내렸다.</p> + +<p>그러나 이러한 방법이 정당화될 수는 있다 하더라도 독점 소프트웨어를 사용하는 것은 여전히 해악한 것이었다. 그래서 어느 시점에 이르렀을 +때, 우리는 더이상 독점 소프트웨어를 사용하지 않기로 결정하고 기증받은 컴퓨터에서 사용할 수 있는 자유 운영체제를 찾기 시작했다. 사용 +가능한 운영체제를 발견한 경우에는 운영체제를 교체했지만, 자유 운영체제를 사용할 수 없는 경우에는 자유 운영체제를 사용할 수 있는 +시스템으로 컴퓨터 자체를 교체시켰다. 오늘날에는 이미 유닉스를 대체할 수 있는 자유 운영체제를 갖고 있기 때문에 유닉스가 설치된 시스템을 +전혀 사용하지 않고 있다.</p> + +<h3>GNU 태스크 리스트</h3> + +<p>GNU 프로젝트가 진행됨에 따라서, 그리고 발견하거나 개발된 자유 운영체제의 구성 요소들이 많아짐에 따라서 마침내 남아있는 부분에 대한 +목록을 만드는 것이 필요한 시점이 되었다. 우리는 이 목록을 이용해서 남아 있는 부분들을 만드는데 필요한 개발자들을 모집했는데, 이 +목록은 “GNU 태스크 리스트(GNU Task List)”라는 이름으로 불리게 되었다. 우리는 아직 개발되지 않은 +유닉스 시스템의 구성 요소 뿐만 아니라 하나의 완벽한 운영체제가 되기 위해서 필요하다고 판단한 다양한 종류의 소프트웨어와 문서 프로젝트 +등을 이 목록에 추가시켰다.</p> + +<p>유닉스와 관련된 대부분의 구성 요소들은 이제 GNU 태스크 리스트에 남아 있지 않다.(대부분의 작업은 모두 완료되었으며 자잘한 몇 +부분만이 남아 있는 상태이다.) 그러나 이 목록에는 “응용 프로그램”이라고 부를 수 있는 소프트웨어를 만들기 위한 +많은 양의 프로젝트들이 가득 차 있다. 협소한 사용자 층을 갖고 있는 프로그램이 아니라면 대부분의 프로그램들은 운영체제와 함께 구성될 +만한 유용한 프로그램이라고 할 수 있을 것이다.</p> + +<p>유닉스에는 게임 프로그램이 포함되어 있기 때문에 자연스럽게 GNU에도 게임이 포함되어야 했다. 따라서 GNU 태스크 리스트에는 이러한 +게임 프로그램들도 처음부터 함께 포함되었다. 그러나 게임 프로그램에는 호환성이라는 문제를 고려할 필요가 없기 때문에 유닉스에서 제공하던 +게임의 종류를 그대로 따르지 않고 사용자들이 좋아할만한 다양한 종류의 게임들을 포함시켰다.</p> + +<h3>GNU Library GPL</h3> + +<p>GNU C 라이브러리에는 GNU Library GPL이라고 불리는 특별한 종류의 카피레프트가 적용된다. 이것은 독점 소프트웨어와의 링크를 +허용하는 것으로 이제는 “GNU Lesser GPL”이라는 이름으로 변경되었으며, LGPL이라고 줄여서 부르기도 +한다. 그렇다면 왜 이러한 예외를 만들었는가?</p> + +<p>LGPL은 우리의 원칙을 수정한 것이 아니다. 우리의 원칙에는 결코 독점 소프트웨어 제품들이 우리가 만든 코드를 사용하도록 허용하지 않고 +있다.(소프트웨어를 우리와 함께 공유하지 않을 것이 명백한 프로젝트에 도움을 줄 이유가 없지 않은가?) C 라이브러리나 다른 +라이브러리들을 LGPL로 만든 것은 원칙을 수정한 것이 아니라 일종의 전략이라고 할 수 있다.</p> + +<p>C 라이브러리는 매우 일반적인 기능을 제공하는 것이어서 모든 독점 운영체제와 컴파일러에는 C 라이브러리가 함께 제공되고 있다. 따라서 +GNU C 라이브러리를 자유 소프트웨어에서만 사용할 수 있도록 한다면 자유 소프트웨어들은 별다른 비교 우위를 갖게 되지 못할 +것이다. 즉, GNU C 라이브러리를 사용하려는 의욕을 저하시키게 되는 것이다.</p> + +<p>GNU/Linux를 포함한 GNU 시스템에서는 오직 GNU C 라이러리만을 사용할 수 있기 때문에 이러한 문제에서 예외일 수 +있다. 따라서 GNU C 라이브러리의 배포 조건에 고려되어야 할 점은 독점 소프트웨어가 GNU 시스템용으로 컴파일 될 수 있도록 GNU +C 라이브러리의 사용을 허용할 것인가라는 문제로 귀착된다. 독점 소프트웨어를 GNU에서 사용할 수 있도록 허용하는 것에는 어떠한 윤리적인 +문제도 없다. 그러나 전략적으로 볼 때 이러한 것을 허용하지 않는 것은 자유 소프트웨어의 개발을 촉진한다기 보다 오히려 GNU 시스템의 +사용을 저하시킬 가능성이 크다고 할 수 있다. 이것이 GNU C 라이브러리를 LGPL로 관리되도록 한 전략적인 이유이다.</p> + +<p>다른 라이브러리들은 상황에 맞는 전략적 판단을 통해서 결정하는 것이 필요할 것이다. 만약 어떠한 라이브러리가 특정한 종류의 프로그램을 +개발하는데 중요한 역할을 수행하게 된다면, 이러한 라이브러리는 GPL로 관리되도록 해서 자유 소프트웨어에서만 사용되도록 제한하는 것이 +바람직하다. 그렇게 함으로써 자유 소프트웨어의 개발자들은 독점 소프트웨어 개발자에 대한 비교 우위와 이점을 갖게 될 수 있을 것이다.</p> + +<p>GNU Readline의 예를 생각해 보면, 이 라이브러리는 BASH의 명령행 편집 기능을 구현하기 위해서 개발된 +것이다. Readline은 LGPL이 아닌 GPL에 의해서 관리되었기 때문에 아마도 LGPL로 배포했을 경우 보다는 그 사용 빈도가 많지 +않았을 것이다. 그러나 이로 인해서 우리가 잃은 것은 아무 것도 없다. 반면에, Readline을 채택한 유용한 자유 소프트웨어가 +하나라도 만들어 졌다면 이는 공동체 전체에 있어서 매우 유용한 수확이라고 할 수 있다.</p> + +<p>독점 소프트웨어의 개발자들은 자본이라는 우위를 갖고 있다. 그러나 자유 소프트웨어의 개발자들은 서로를 위해서 이점을 만들어 주어야 +한다. 나는 언젠가는 우리가 독점 소프트웨어에 라이센스를 허용하지 않는 넉넉한 양의 GPL 라이브러리들을 갖게 되기를 희망한다. 이러한 +라이브러리들은 새로운 자유 소프트웨어 안에서 유용한 기능을 수행하는 모듈로 활용될 것이며 보다 나은 자유 소프트웨어를 개발하는데 있어서 +주요한 이점들을 제공하게 될 것이다.</p> + +<h3>가려운 곳을 긁는다?</h3> +<p> +에릭 레이몬드(Eric Raymond)는 “소프트웨어에 있어서 모든 좋은 성과들은 개발자 자신의 가려운 곳을 긁는 것으로부터 +시작된다.”라고 주장한다.(<b>역자주:</b> 에릭 레이몬드의 대표적인 저작인 성당과 시장에 소개되어 있는 문장으로 사이트를 +통해서 한국어 번역 전문을 참고할 수 있다.) 때때로 이것은 타당한 말일 것이다. 그러나 GNU 소프트웨어의 핵심적인 부분들은 대부분 +완전한 자유 운영체제를 만들기 위한 목적으로 개발된 것이다. GNU는 가려울 때마다 가려운 곳을 긁듯이 그때그때 만들어 진 것이 아니라 +비전과 계획에 의해서 만들어 진 것이다.</p> +<p> +예를 들어, 우리가 GNU C 라이브러리를 개발한 이유는 유닉스 형태의 운영 환경에서 C 라이브러리가 필요했기 때문이고, BASH를 +개발한 이유 또한 유닉스 환경이 셸을 요구하기 때문이었다. GNU tar나 내가 직접 개발한 GNU C 컴파일러와 GNU Emacs +그리고 GDB와 GNU Make도 같은 이유에서 개발된 것들이었다.</p> +<p> +어떠한 종류의 GNU 프로그램은 자유에 대한 위협에 대처하기 위해서 만들어 진 것이다. gzip은 <abbr +title="Lempel-Ziv-Welch">LZW</abbr> 압축 알고리즘의 특허 문제로 인해서 공동체 안에서 사라져 버린 압축 +프로그램을 대체하기 위해서 개발되었다. 우리는 독점 라이브러리로 인해서 일어나는 문제들을 해결하기 위해서 LessTif를 개발할 사람들을 +모집했으며 더욱 최근에는 <abbr title="GNU Network Object Model +Environment">GNOME</abbr>과 Harmony를 만들기 시작했다. 또한 사생활과 자유 중에서 하나를 선택해야만 하는 +불합리한 문제를 없애기 위해서 자유 소프트웨어가 아닌 기존의 인기있는 암호화 소프트웨어를 대체할 GNU Privacy Guard를 +개발하고 있기도 하다.</p> +<p> +물론, 이러한 프로그램들을 개발하고 있는 개발자들은 자신의 작업에 흥미를 갖고 있으며 많은 사람들이 그들의 필요와 관심에 따라서 다양한 +기능들을 덧붙여 가고 있다. 그러나 이러한 것이 프로그램이 존재하게 되는 이유는 아니다.</p> + +<h3>예기치 않은 개발들</h3> +<p> +GNU 프로젝트를 시작할 당시에는 GNU 시스템을 모두 완성한 뒤에 완성된 시스템 전체를 공개하려고 생각했었다. 그러나 다음과 같은 +이유로 인해서 그렇게 되지 못했다.</p> +<p> +GNU 시스템을 구성하는 각각의 요소들은 유닉스에서 먼저 구현한 뒤에 이를 GNU로 옮긴 것이기 때문에 GNU 시스템이 완성되기 오래 +전부터 이미 유닉스에서 사용되고 있었다. 이러한 프로그램 중에서 어떠한 것들은 유명해 졌으며 사용자들이 프로그램을 확장하거나 호환이 되지 +않던 다양한 종류의 유닉스로 이식시켰다. 또한 유닉스 이외의 운영체제로 이식이 이루어 지기도 했다.</p> +<p> +이러한 과정을 통해서 그 프로그램들은 보다 강력한 기능을 갖게 되었고 기부와 공헌자들을 GNU 프로젝트로 끌어들이게 되었다. 그러나 +이것은 GNU의 개발자들로 하여금 GNU 시스템을 완성시켜나가는 것 보다 오히려 기존의 구성 요소에 새로운 기능을 덧붙이거나 다른 +시스템으로 이식하는데 시간을 투자하도록 만들었기 때문에 동작 가능한 최소한의 시스템을 완성하는데 몇년이 지연되는 결과를 가져왔다.</p> + +<h3>GNU Hurd</h3> +<p> +1990년 무렵에는 GNU 시스템이 거의 완성되었지만 운영체제를 구성하는 핵심 부분 중의 하나인 커널이 누락된 상태였다. 우리는 +Mach(마하 또는 마크)를 기반으로 한 서버 프로세스들을 연결해서 커널을 구현하기로 결정했다. Mach는 카네기 멜론 +대학(Carnegie Mellon University)에서 개발한 마이크로커널(microkernel)로 후에 유타 +대학(University of Utah)으로 그 개발이 넘어갔다. 커널은 운영체제를 구성하는 핵심 부분을 가리키는 말인데 마이크로커널 +아키텍처에서는 IPC와 메모리 관리 부분만을 커널에 내장시키고 나머지 부분들은 자율적인 프로세스로 구현한 뒤에 이들을 연결시키는 구조를 +갖고 있다. 따라서 우리가 만들려고 했던 GNU Hurd(허드)는 Mach와 자율적인 프로세스 서버들의 집합이라고 할 수 있으며 유닉스 +커널이 갖고 있는 다양한 기능들을 그대로 수행할 수 있는 것이었다. 그러나 GNU Hurd의 개발은 Mach를 자유 소프트웨어로 +배포한다고 예고했던 시기까지 지연되었다.</p> +<p> +마이크로커널을 채택한 이유 중의 하나는 소스 차원의 디버거 없이는 가장 힘든 작업이 될 수밖에 없는 커널 프로그램의 디버깅을 피하기 +위해서였다. 우리는 완성된 Mach를 활용하면 이러한 작업을 생략할 수 있으며 Hurd 서버들을 디버깅하는 데는 GDB를 사용할 수 +있으리라고 생각했다. 그러나 이러한 작업이 가능하기 위해서는 상당한 기간이 필요했으며 상호 메시지 전달을 위한 멀티 쓰레드 서버를 +디버깅하는 것도 매우 어려운 작업이었다. 이러한 이유로 인해서 Hurd를 만드는 작업에는 많은 시간이 소요되었다.</p> + +<h3>Alix</h3> +<p> +GNU 커널의 이름을 처음부터 Hurd라고 부르려 했던 것은 아니다. 원래의 이름은 당시 내 연인의 이름을 따서 Alix(앨릭스)라고 +했었는데, 유닉스 시스템 관리자였던 그녀는 Alix라는 이름이 유닉스의 버전마다 관례처럼 붙여지던 별칭과 잘 어울린다면서, +“누군가 내 이름을 따서 커널 이름을 지어야 할걸”이라고 친구들에게 농담처럼 말하곤 했다. 나는 아무 말도 하지 +않았지만 Alix를 커널의 이름으로 사용해서 그녀를 놀라게 해주리라 마음먹었다.</p> +<p> +그러나 이러한 나의 생각은 실현되지 못했다. 커널의 주요 개발자였던 마이클 부쉬널(Michael Bushnell, 현재의 이름은 +토마스이다.)이 Hurd라는 이름을 더 선호했기 때문이다. 또한 그는 Alix를 커널의 이름에서 Hurd 서버로 메시지를 전송하는 방법을 +통해서 시스템 콜을 트랩하고 제어할 수 있는 커널의 한 부분으로 변경시켰다.</p> +<p> +훗날, Alix와 나는 헤어지게 되었고 그녀는 그녀의 이름을 다른 것으로 바꿨다. 또한 이러한 사연과는 무관하게 Hurd의 디자인도 C +라이브러리가 서버로 메시지를 직접 전달할 수 있는 형태로 수정되었다. 이러한 이유로 Alix는 HURD에서 사라지게 되었다.</p> +<p> +그러나 이러한 일들이 일어나기 전에 Alix의 친구 중 한 명이 Hurd의 소스 코드에 포함되어 있던 Alix라는 이름을 본 적이 +있었고, Alix에게 그 사실을 전해줌으로써 나의 의도는 그녀에게 전달될 수 있었다.</p> + +<h3>리눅스와 GNU/Linux</h3> + +<p> +현재까지도 GNU Hurd는 하나의 제품으로 사용될 수 있을 만한 상태가 아니다. 그러나 다행스럽게도 또다른 커널이 사용 가능했는데, +1991년에 리누스 토발스(Linus Torvalds)가 유닉스 커널과 호환 가능하게 만든 리눅스라는 이름의 커널이 +그것이었다. 1992년 무렵에 우리는 완전하지 않았던 GNU 시스템과 리눅스를 결합함으로써 하나의 완성된 자유 운영체제를 만들 수 +있었다.(이들을 결합한다는 것은 물론 단순한 작업이 아닌 상당한 노력이 필요한 실제적인 작업이었다.) 따라서 현재 사용되고 있는 GNU +시스템은 리눅스 덕분에 가능했던 것이라고 할 수 있다.</p> + +<h3>미래의 도전들</h3> +<p> +우리는 다양한 종류의 자유 소프트웨어를 개발함으로써 우리의 역량을 증명해 왔다. 그러나 이것이 우리에게 장애가 없는 무소불위의 능력이 +있다는 것을 의미하지는 않는다. 몇 가지 장애물들이 자유 소프트웨어의 앞날을 불확실하게 만들고 있기 때문이다. 이러한 장애들을 극복하기 +위해서는 끊임없는 노력과 인내가 필요하며 때때로 몇년이 소요되기도 할 것이다. 또한 자유를 소중히 여기고 이를 누구에게도 빼앗기지 +않겠다는 의사를 분명히 표현하려는 사람들의 결단이 필요하다.</p> +<p> +우리에게 당면해 있는 장애는 다음과 같은 것들이다.</p> + +<h3>비밀스런 하드웨어</h3> +<p> +하드웨어 제조업에서는 하드웨어에 대한 스펙을 비밀로 하는 경우가 점점 더 늘어나고 있다. 이 때문에 자유롭게 쓸 수 있는 드라이버를 +만드는 것이 힘들어 지고 결과적으로 리눅스와 XFree86에서 새로운 하드웨어를 지원하는 것이 어려워지고 있다. 현재 우리들은 완성된 +자유 운영체제를 갖고 있지만 앞으로 개발될 컴퓨터를 지원할 수 없다면 그렇게 되지 못할 수도 있을 것이다.</p> +<p> +이러한 문제에 대처할 수 있는 방법은 2가지가 있다. 그 첫번째 방법은 리버스 엔지니어링(reverse engineering)을 채용하는 +것이고 두번째 방법은 사용자들이 그 결과를 지원하는 것이다. 리버스 엔지니어링이란 이미 생산되고 있는 하드웨어를 분석해서 설계 구조와 +스펙 등을 알아내는 방법이다. 따라서 프로그래머들이 리버스 엔지니어링을 수행하면 일반 사용자들은 그 결과를 통해서 자유 소프트웨어에서 +사용할 수 있는 하드웨어를 선택할 수 있다. 그렇게 되면 자유 소프트웨어를 사용하는 사람이 증가할수록 하드웨어 스펙을 공개하지 않는 +방침은 결국 스스로의 화를 자초하는 선택이 될 것이다.</p> +<p> +리버스 엔지니어링은 매우 방대한 작업이다. 우리가 과연 이러한 일을 수행할 수 있는 결단을 가진 프로그래머들을 가질 수 있을까? 만약 +우리가 자유 소프트웨어가 아닌 드라이버들을 과감하게 포기하고 자유 소프트웨어라는 원칙을 단호하게 지켜간다면 충분히 가능하리라고 +생각한다. 우리 중 많은 사람들이 자신이 갖고 있는 여분의 시간과 돈을 투자할 수 있다면 자유롭게 쓸 수 있는 드라이버를 갖지 못할 +이유가 없지 않을까? 자유를 누리려는 결단이 널리 확산된다면 얼마든지 가능할 것이다.</p> + +<h3>자유 소프트웨어가 아닌 라이브러리들</h3> +<p> +자유 운영체제에서 사용할 수 있는 자유 소프트웨어가 아닌 라이브러리들은 자유 소프트웨어 개발자들에게 있어 일종의 함정과 같다. 이러한 +라이브러리가 갖고 있는 매혹적인 기능을 외면한다는 것은 개발자에게 있어서 매우 어려운 일이다. 그러나 만약 이러한 유혹에 넘어간다면 +그것은 스스로 자신의 무덤을 파는 것과 같다. 왜냐하면 이러한 라이브러리를 이용해서 만들어진 프로그램은 자유 운영체제에 포함될 수 없기 +때문이다.(보다 정확하게 말하면 프로그램은 포함시킬 수 있겠지만, 라이브러리 자체가 포함될 수 없기 때문에 결국 이러한 프로그램은 +<em>실행</em>될 수 없는 것이다.) 더욱 심각할 수 있는 경우는 만약 독점 라이브러리를 사용한 프로그램이 매우 인기있는 프로그램이 +된다면 이러한 라이브러리에 관심을 갖고 있지 않던 프로그래머들을 같은 유혹에 빠뜨릴 수 있다는 점이다.</p> +<p> +이러한 경우의 첫번째 실례는 1980년대에 사용되던 Motif (모티프) 툴킷에서 찾아볼 수 있다. 그 당시에는 아직 자유 운영체제가 +존재하지 않았지만 Motif가 갖고 있던 문제가 어떤 결과를 초래하리라는 것은 이미 자명한 일이었다. GNU 프로젝트는 두가지 방법으로 +여기에 대응했다. 첫째는 자유 소프트웨어 프로젝트들이 Motif 뿐만 아니라 자유 소프트웨어에 해당하는 X 툴킷 위젯도 지원하도록 권고한 +것이고, 또하나는 Motif를 대체할 수 있는 라이브러리의 개발을 추진한 것이다. 이 작업에는 몇년이 소요되었는데 열성적인 프로그래머들 +덕분에 1997년에 이르러 Moti를 사용하는 대부분의 프로그램을 지원할 수 있는 LessTif 라이브러리가 완성되었다.</p> +<p> +1996년과 1998년 사이에는 이른바 Qt라고 불리는 또다른 <abbr title="Graphical User +Interface">GUI</abbr> 툴킷 라이브러리가 등장했다. Qt는 데스크탑 환경의 자유 소프트웨어인 <abbr title="K +Desktop Environment">KDE</abbr>에 사용되는 핵심 요소이다.</p> +<p> +그러나 자유 운영체제인 GNU/Linux 시스템에서는 Qt의 라이센스와 관련해서 KDE를 사용할 수 없었다. GNU/Linux를 판매하는 +일부 상용 배포판 업체에서는 KDE를 함께 패키징해서 활용성을 증대시킨 시스템을 만들기도 했지만 결국 이것은 자유를 감소시키는 +것이었다. KDE 그룹은 보다 많은 프로그래머들이 Qt를 사용하도록 적극적으로 권장했고 새롭게 리눅스를 사용하게 된 수많은 사람들은 +이러한 문제를 미처 생각하지도 못한 채 KDE를 사용하게 되었다. 상황이 무척 심각해 진 것이다.</p> +<p> +자유 소프트웨어 공동체는 GNOME과 Harmony라는 2가지 방법으로 이 문제에 대응했다.</p> +<p> +우리는 먼저 GNU Network Object Model Environmet, 즉 GNOME(그놈)이라고 불리는 데스크탑 환경의 개발을 +시작했다.(<b>역자주:</b> GNOME을 구성하는 단어들은 여러가지 형태로 배열할 수 있는데, 의미의 전달이 가장 명확한 형태는 +GNU's Environment Model for Network Objects이다.) 이 프로젝트는 미구엘 드 이카자(Miguel de +Icaza)에 의해서 1997년부터 시작되었고 레드햇 소프트웨어가 이를 후원하고 있다.(<b>역자주:</b> 미구엘 드 아카자는 +1999년에 미국의 과학 전문지인 MIT Technology Review가 창간 100주년 기념호에서 선정한 다음 세기를 이끌 젊은 +과학자 100인에 선정되기도 하였으며 GNOME 프로젝트에 대한 공로로 자유 소프트웨어 재단이 수여한 제2회 자유 소프트웨어 발전을 위한 +자유 소프트웨어 재단상을 수상하기도 했다.<!-- dead link as of 2019-07-27 - <a +href="http://gnu.kldp.org/opensources/video/icaza.ra">이카자에 대한 짧은 화상 +자료</a>-->) GNOME은 데스크탑 환경과 유사한 기능들을 제공하지만 오직 자유 소프트웨어만으로 만들어 진다. 또한 C++ 이외에 +다양한 종류의 언어를 지원함으로써 기술적인 장점도 함께 제공한다. 그러나 GNOME의 주된 목적은 자유라고 할 수 있다. GNOME +환경은 자유 소프트웨어가 아닌 어떠한 프로그램의 기능도 자유 소프트웨어 안에서 충족시키기 위한 것이다.</p> +<p> +또하나의 대안인 Harmony는 KDE 소프트웨어들을 Qt 없이도 사용할 수 있도록 하기 위해서 개발된 라이브러리이다.</p> +<p> +1998년 11월에 Qt의 개발자들은 Qt를 자유 소프트웨어로 변경할 것이라고 발표했다. 그러나 이것은 아직까지 확실한 것이 아니며, +부분적으로 Qt가 자유 소프트웨어가 아니었을 때 갖고 있던 문제에 대해서 우리가 단호하게 대처함으로써 나타난 결과라고 할 수 +있다.(Qt의 새로운 라이센스에도 여전히 불충분한 점이 많이 있으므로 가능한 Qt를 사용하지 않는 것이 바람직하다.)</p> +<p> +자유 소프트웨어가 아닌 또다른 라이브러리의 유혹에 우리는 어떻게 대응해야 할까? 공동체의 일원들은 모두가 다 이러한 유혹으로부터 벗어날 +필요성에 공감하게 될까? 그렇지 않다면 편리함을 핑계삼아 자유를 포기하고 중요한 문제를 만들어 내지는 않을까? 우리의 미래는 다름아닌 +우리들 자신의 철학에 달려있는 것이다.</p> + +<h3>소프트웨어에 대한 기술 특허</h3> +<p> +우리가 당면하고 있는 가장 큰 위협은 바로 소프트웨어에 대한 특허로 부터 발생된다. 알고리즘과 새로운 기술에 부여되는 특허는 20년까지 +보장되므로 이러한 영역에는 자유 소프트웨어가 접근할 수 없는 것이다. LZW 압축 알고리즘에 대한 기술 특허는 1983년에 +신청되었다. 그리고 아직까지도 우리는 정상적인 <abbr title="Graphics Interchange +Format">GIF</abbr> 압축을 생성할 수 있는 자유 소프트웨어를 공개하지 못하고 있다. 1998년에는 특허권 침해에 대한 소송 +위협에 따라서 배포판에서 <abbr title="MPEG-1 Audio Layer 3">MP3</abbr> 오디오 압축 프로그램을 제외할 +수밖에 없었다. +</p> +<p> +특허권에 대처할 수 있는 몇가지 방법은 특정한 특허가 특허로 인정될 수 없다는 반대 증거를 찾거나 특허가 취득된 기술을 대체할 수 있는 +방법을 찾는 것이다. 그러나 이러한 방법들이 항상 적용될 수 있는 것은 아니며, 이러한 방법들이 모두 실패할 경우에는 사용자들이 원하는 +기능을 자유 소프트웨어에 포함시킬 수 없게 될 것이다. 만약, 이러한 일이 일어난다면 어떻게 해야 할 것인가?</p> +<p> +자유 소프트웨어가 갖고 있는 자유의 가치를 중요하게 생각하는 사람들은 어떠한 상황에서도 자유 소프트웨어를 버리지 않을 것이다. 우리는 +특허와 관련된 기능이 없더라도 나름대로 원하는 작업을 해 나갈 수 있을 것이다. 그러나 자유 소프트웨어가 갖게 될 기술적 우위를 기대하고 +이를 사용했던 사람들은 특허에 의해서 기술적 장점이 사라진 이후에는 자유 소프트웨어가 실패했다고 단언할 것이다. 따라서 +“시장” 형태의 개발 모델이 갖고 있는 실제적인 효과와 특정한 자유 소프트웨어가 갖고 있는 안정성과 성능에 대해서 +말하는 것이 사람들에게 유용한 동안에는 단지 그러한 말만을 할 것이 아니라 자유와 자유를 지켜나가기 위한 원칙에 대해서도 함께 얘기 +해야만 한다.</p> + +<h3>자유 문서</h3> +<p> +우리의 자유 운영체제가 안고 있는 가장 절실한 문제는 소프트웨어에 대한 부분이 아니라 운영체제에 함께 포함시킬 양질의 문서가 부족하다는 +점이다. 문서 자료는 모든 소프트웨어에 있어서 필수적인 부분이다. 만약 핵심적인 자유 소프트웨어가 자유롭게 이용할 수 있는 좋은 문서 +자료 없이 제공된다면 이는 심각한 문제라고 할 수 있는데, 현재 우리는 이러한 문제를 많이 갖고 있다.</p> +<p> +자유 소프트웨어와 마찬가지로 자유 문서에는 가격이 아닌 자유가 중요한 관건이 된다. 자유 문서의 판단 기준은 자유 소프트웨어와 거의 +같다고 할 수 있다. 즉 모든 사용자에게 자유를 허용하는가이다. 상업적 판매를 포함한 재배포가 온라인 또는 서적의 형태로 모두 허용되어야 +하며, 이러한 문서 자료가 해당 프로그램과 함께 제공될 수 있어야 한다.</p> +<p> +개작에 대한 허용 또한 필수적인 부분이다. 그러나 나는 일반적으로 모든 종류의 글과 책을 개작할 수 있도록 허용해야 한다고 생각하지는 +않는다. 예를 들면, 여러분이 읽고 있는 바로 이글과 같이 우리들의 생각이나 활동을 설명한 글을 개작할 수 있도록 허용할 필요는 없는 +것이다.</p> +<p> +그러나 자유 소프트웨어를 위해서는 문서에 대한 개작의 허용이 필수적인 것이라고 할 수 있다. 소프트웨어를 개작할 수 있는 권리를 사용해서 +소프트웨어를 수정하거나 새로운 기능을 추가했다면 자신의 작업을 책임있게 마무리 하기 위해서 기존의 매뉴얼을 변경된 기능에 맞는 보다 +정확하고 유용한 문서로 고치려고 할 것이다. 그러나 만약 프로그래머들에게 이러한 작업이 허용되지 않는다면, 결국 공동체가 필요로 하는 +요구들을 충족시키지 못하게 되는 것이다.</p> +<p> +문서의 수정 형태에 대한 외형적인 제한 조건을 설정하는 것은 경우에 따라서 별다른 문제가 되지 않는다. 예를 들면, 원저작자의 저작권 +사항이나 배포 조건 또는 저자들의 명단을 보존해야 한다는 제한이나 문서가 수정되었다는 사실을 명시해야 한다는 제한 그리고 수정되지 않은 +부분은 그대로 남겨두어야 한다는 등의 제한 조건은 이러한 부분이 기술적인 내용을 담고 있지 않는 한 큰 문제가 되지 않는다. 왜냐하면 +이러한 종류의 제한들은 프로그래머들이 개작된 프로그램에 맞게 매뉴얼을 수정하는 데 별다른 지장을 주지 않기 때문이다. 즉 이러한 제한들은 +공동체가 매뉴얼을 온전히 활용하는 것을 제한하는 않기 때문에 문제가 되지 않는다.</p> +<p> +그러나 기술적인 내용에 관련된 부분들은 모두 수정할 수 있어야 하며 수정된 문서는 어떠한 배포 매체와 배포 방법을 통해서도 배포될 수 +있어야 한다. 그렇지 않다면 이러한 제한들은 공동체의 필요를 가로막는 장애가 되어 결국 자유롭게 사용할 수 있는 또다른 매뉴얼이 필요할 +것이다.</p> +<p> +그렇다면 자유 소프트웨어의 개발자들이 모든 종류의 매뉴얼을 만들 필요성을 인식하고 이를 실천할 수 있을까? 다시 한번 반복되는 말이지만, +우리의 미래는 다름아닌 우리들 자신의 철학에 달려있는 것이다.</p> + +<h3>우리는 자유에 대해서 얘기 해야만 한다.</h3> +<p> +오늘날에는 대략 천만명 정도의 사람들이 레드햇 “리눅스나” 데비안 리눅스와 같은 GNU/Linux 시스템을 사용하고 +있는 것으로 추산된다. 대부분의 사람들은 실용적인 목적에 따라 움직이며 자유 소프트웨어는 이러한 부분들을 하나둘씩 쌓아왔다.</p> +<p> +대중적이라는 측면이 가져오는 긍정적인 결과는 명확한 것이다. 이전에 비해서 자유 소프트웨어의 개발에 많은 관심을 갖게 될 것이며 자유 +소프트웨어 산업에 보다 많은 고객층이 형성될 것이다. 또한 독점 소프트웨어 제품을 개발하는 대신 상용 자유 소프트웨어를 개발하도록 +기업들을 더욱 많이 장려할 수 있을 것이다.</p> +<p> +그러나 자유 소프트웨어의 바탕에 깔려있는 본질적인 철학적 인식 보다 자유 소프트웨어 자체에 대한 관심이 너무도 빨리 증가하고 있다는 것이 +우리가 당면해 있는 문제이다. 지금까지 4개의 범주로 나눠서 설명했던 미래에 대한 도전과 위협들을 극복해 나갈 수 있는 능력은 자유를 +지키겠다는 우리들의 단호한 의지에 달려있다. 우리의 공동체가 이러한 의지를 견지하기 위해서는 우리와 합류하려는 사람들에게 이러한 철학적 +생각들을 깊게있게 인식시켜 주어야 한다.</p> +<p> +그러나 지금까지는 그렇게 하지 못했다고 볼 수 있다. 공동체의 일원들에게 의식을 심어주는 것보다 우선 공동체 안으로 끌어들이려는 노력이 +우세했던 것이다. 그러나 우리는 2가지를 작업을 함께 병행해야 하며 이러한 노력들이 균형을 이루도록 힘써야 한다.</p> + +<h3>“오픈 소스”</h3> +<p> +1998년 부터는 새로운 사용자들에게 자유에 대해서 이야기 하는 것이 더욱 어려워졌다. 왜냐하면 공동체의 일부에서 “자유 +소프트웨어”라는 말 대신 “오픈 소스 소프트웨어”라는 표현을 사용하기 시작했기 때문이다.</p> +<p> +이 용어를 선호하는 사람들의 의도는 “자유”를 의미하는 영어 단어인 “free”가 갖고 있는 +무료(無料)와 자유(自由)라는 의미상의 혼란을 방지하기 위한 것으로 이는 타당한 것이라고 할 수 있다. 그러나 또다른 사람들은 +“자유”라는 단어가 함축하고 있는 자유 소프트웨어 운동과 GNU 프로젝트의 정신을 의도적으로 퇴색시키기 위해서 +“오픈 소스”라는 표현을 사용하고 있으며 자유나 공동체 보다는 이윤에 더 높은 가치를 부여하는 기업 경영인과 +사용자들에게 보다 친밀하게 다가서기 위해서 이 말을 사용하기도 한다. 따라서 “오픈 소스”라는 용어는 높은 품질과 +강력한 성능을 가진 소프트웨어를 만들 수 있다는 가능성에 초점을 맞춘 말이기 때문에 자유와 공동체 그리고 원칙과 같은 개념을 의도적으로 +전달하지 않으려는 표현이라고 할 수 있다.</p> +<p> +“리눅스 XXX” 등과 같이 리눅스라는 단어가 제호로 들어간 잡지들은 그 분명한 실례의 하나이다. 이러한 잡지에는 +GNU/Linux에서 사용 가능한 독점 소프트웨어의 광고들로 가득 차 있다. Motif나 Qt와 같은 종류의 라이브러리가 다시 생겨났을 +때 과연 이러한 잡지들이 프로그래머들에게 그 위험성을 경고해 줄 것인지 아니면 그 제품의 광고를 실을 것인지는 명확하지 않은가?</p> +<p> +기업이 제공하는 지원은 공동체에 여러가지 방법으로 도움이 될 수 있지만 그 이외의 것들 또한 마찬가지로 유용하다. 그러나 자유에 대해서 +말하지 않는 방법으로 이러한 지원을 받아낸다면 이는 화를 자초하는 것이라고 할 수 있으며, 보다 많은 사용자들을 공동체 안으로 끌어 +들이려는 노력과 공동체의 성원들에게 철학적 인식을 심어주려는 우리의 2가지 목적 안에 존재했던 불균형을 더욱 심화시키는 결과가 될 +것이다.</p> +<p> +“자유 소프트웨어”와 “오픈 소스”는 같은 부류의 소프트웨어를 가리키는 말이다. 그러나 그 +차이점은 소프트웨어와 가치에 대해서 서로 다른 입장을 갖고 있다는 것이다. GNU 프로젝트는 기술적인 측면 그 자체보다 훨씬 중요하다고 +생각하는 “자유”라는 이념을 피력하기 위해서 “자유 소프트웨어”라는 용어를 계속해서 사용할 +것이다</p> + +<h3>노력하라!</h3> +<p> +There is no “try.”라는 요다의 철학(<b>역자주:</b> 영화 스타워즈 에피소드 5편에 나오는 +제다이의 스승 요다의 말로 시도해 본다는 것은 의미가 없고 확신을 갖고 실행하는 것만이 포스의 힘을 불러낼 수 있다는 의미이다. 원문은 +No! Try not. Do. Or do not. There is no try이다.)은 멋지게 들리지만 내게는 효과가 없는 +말이었다. 나는 내가 이 일은 해낼 수 있을까 하는 걱정과 우려 속에서 대부분의 일들을 해왔다. 그러나 내 도시를 침략하려는 적들과 내 +도시 사이에는 오직 나밖에 없었기 때문에 나는 최선을 다해서 싸웠으며 때때로 나 자신이 놀랄 정도로 승리를 거두곤 했다.</p> +<p> +때로는 패배하기도 해서 나의 도시들 중 몇몇이 파멸되기도 했다. 그러나 또다른 도시가 위협받고 있음을 발견했을 때에는 비장하게 또다른 +전투를 준비해 왔다. 싸움이 길어지면서 나는 전운을 감지하는 방법을 체득하게 되었고 다른 해커들의 동맹과 원조를 요청하면서 방어할 도시로 +떠나곤 했다.</p> +<p> +그러나 나는 이제 혼자가 아니다. 전선을 방어하기 위해서 사투를 벌이고 있는 해커들의 부대를 볼 때 나는 큰 기쁨과 위안을 +느낀다. 아마도 이 도시는 건재하리라. 그러나 최근 몇년 사이에 위협은 더욱 커져가고 있으며 마이크로소프트는 우리의 공동체를 노골적으로 +위협하고 있다. 우리는 우리가 갖고 있는 자유의 미래가 보장되리라고 확신할 수 없다. 자유가 남아있게 되리라는 막연한 생각은 버려야 +한다! 만약, 여러분의 자유가 계속해서 지켜지기를 원한다면 그것을 지킬 준비를 해야만 할 것이다.</p> + +<div class="translators-notes"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> +<hr class="thin" /> +<p>이 문서는 2000년 6월 15일 한국 종합 전시장 COEX에서 열린 리차드 스톨만의 기조 연설과 유사한 내용을 담고있습니다. 기조 +연설의 전체 내용과 6월 18일 연세대학교에서 열린 “소프트웨어 특허의 문제점”이라는 주제의 강연은 다음과 같은 +화상 자료로 참고할 수도 있습니다. 아래의 동영상 자료들은 다음과 같은 저작권 사항을 명시하는 한, 어떠한 정보 매체에 의한 복제나 +재배포도 무상으로 허용됩니다. 단, 본문에 대한 수정과 첨삭은 허용되지 않습니다.</p> + +<ul> +<li><a href="http://korea.gnu.org/rms/">2000년 6월 15일 Coex 강연 동영상 자료</a></li> +<li><a href="http://korea.gnu.org/rms/">2000년 6월 18일 연세대학교 강연 동영상 +자료</a></li> +</ul></div> +</div> + +<!-- for id="content", starts in the include above --> +<!--#include virtual="/server/footer.ko.html" --> +<div id="footer"> +<div class="unprintable"> + +<p>FSF와 GNU에 대한 문의는 <a href="mailto:gnu@gnu.org"><gnu@gnu.org></a> 앞으로 보내 +주세요. FSF에 대한 <a href="/contact/">다른 연락 방법</a>도 있습니다. 끊어진 링크나 다른 수정 사항 또는 제안은 +<a href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a> 앞으로 보내 +주세요.</p> + +<p> +<!-- TRANSLATORS: Ignore the original text in this paragraph, + replace it with the translation of these two: + + We work hard and do our best to provide accurate, good quality + translations. However, we are not exempt from imperfection. + Please send your comments and general suggestions in this regard + to <a href="mailto:web-translators@gnu.org"> + + <web-translators@gnu.org></a>.</p> + + <p>For information on coordinating and submitting translations of + our web pages, see <a + href="/server/standards/README.translations.html">Translations + README</a>. --> +이 글의 다른 언어 번역문 작성이나 제출에 대한 정보는 <a +href="/server/standards/README.translations.html">번역 안내</a>를 참고해 주세요.</p> +</div> + +<!-- Regarding copyright, in general, standalone pages (as opposed to + files generated as part of manuals) on the GNU web server should + be under CC BY-ND 4.0. Please do NOT change or remove this + without talking with the webmasters or licensing team first. + Please make sure the copyright date is consistent with the + document. For web pages, it is ok to list just the latest year the + document was modified, or published. + If you wish to list earlier years, that is ok too. + Either "2001, 2002, 2003" or "2001-2003" are ok for specifying + years, as long as each year in the range is in fact a copyrightable + year, i.e., a year in which the document was published (including + being publicly visible on the web or in a revision control system). + There is more detail about copyright years in the GNU Maintainers + Information document, www.gnu.org/prep/maintain. --> +<p>Copyright © 1998, 2001, 2002 Richard Stallman</p> + +<p>이 페이지는 <a rel="license" +href="http://creativecommons.org/licenses/by-nd/4.0/deed.ko">크리에이티브 커먼스 +저작자표시-변경금지 4.0 국제 이용허락서</a>에 따라 이용할 수 있습니다.</p> + +<!--#include virtual="/server/bottom-notes.ko.html" --> +<div class="translators-credits"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> +<p>한국어 번역: 1999년 11월 17일 송창훈 <a +href="mailto:chsong@gnu.org"><chsong@gnu.org></a><br /> +번역 검토 및 확인: 2000년 2월 박주연 <a +href="mailto:kokids@debian.org"><kokids@debian.org></a></p> + +<p>한국어 번역 문의 및 오역에 대한 지적은 <a +href="mailto:www-ko-translators@gnu.org"><www-ko-translators@gnu.org></a> +앞으로 메일을 보내주시기 바랍니다.</p></div> + +<p class="unprintable"><!-- timestamp start --> +최종 수정일: + +$Date: 2020/07/04 08:32:33 $ + +<!-- timestamp end --> +</p> +</div> +</div> +<!-- for class="inner", starts in the banner include --> +</body> +</html> |