GNU 선언문(GNU Manifesto) Copyright (C) 1985 Richard M.Stallman (Copying permission notice at the end.) GNU란 무엇인가? Gnu's Not Unix! GNU는 유닉스와 완벽하게 호환하는 소프트웨어 시스템으로 사용 가능한 모든 이가 무료로 사용하도록 작성한 것이다. 몇몇 다른 자원자들의 도움이 있었으며, 많은 시간적, 금전적 지원 및 프로그램과 장비가 절실히 필요한 상태이다. 우리는 문서 형식기로 TeX를 사용할 것이며, nroff도 여전히 사용될 것이다. 또한 X 윈도우 시스템도 사용할 것이다. 이런 후에 Common Lisp, Empire, 스프레드시트 등과 수많은 다른 프로그램을 온라인 문서를 포함하여 추가할 것이다. 우리는 결국 일반적인 유닉스 시스템의 모든 기능을 갖추게 될 것이다. 지금까지 우리는 편집명령을 작성하기 위한 리스프를 갖춘 Emacs 문서 편집기, 소스 수준의 디버거, yacc 호환 파서 생성기, 링커 등 35개 가량의 유틸리티를 만들어 왔으며, 쉘(명령어 번역기)은 거의 완벽한 수준에 이르렀다. 최적화된 포터블 C 컴파일러가 새로이 제작되었으며, 이번 해에 배포될 것이다. 이미 처음의 커널이 있기는 하지만 유닉스를 구현하기 위해서는 보다 많은 사양들이 추가되어야 할 것이다. 커널과 컴파일러가 완성되면 프로그램 개발에 적합한 GNU 시스템을 배포할 수 있을 것이다. GNU는 유닉스 프로그램들을 사용할 수 있게 해주지만 유닉스와 동일한 것은 아니다. 우리는 다른 운영체제에서의 경험을 살려 가능한 사용하기 편리하도록 향상을 꾀했다. 특히 긴 파일명을 쓸 수 있게 하고, 파일 버전 넘버를 달고, 견고한 파일 시스템을 구축하고, 터미널 비의존적인 디스플레이 장치를 만들 계획이며 최종적으로 몇 개의 리스프 프로그램과 일반적인 유닉스 프로그램이 한 화면을 나누어 쓸 수 있는 리스프 기반의 윈도우 시스템을 만들 것이다. 시스템 프로그래밍 언어로 C와 리스프 두 가지를 다 사용할 수 있을 것이다. 그리고 UUCP, MIT Chaosnet, 인터넷 프로토콜을 지원할 것이다. GNU는 본래 가상메모리를 가진 68000/16000 계열의 컴퓨터를 겨냥하고 제작되었다. 그 까닭은 그 기계들에서 GNU를 가장 쉽게 작동시킬 수 있기 때문이다. 보다 작은 컴퓨터에서 작동시키기 위해서는 사용하고자 하는 사람이 특별한 노력을 기울여야 할 것이다. 심각한 혼돈을 야기할 수 있기 때문에 'GNU'가 이 프로젝트를 지칭할 때는 반드시 'G'를 발음해 주기 바란다. 나는 누구인가? 나는 리차드 스톨만이란 사람이며 Emacs 에디터의 고안자이다. 나는 컴파일러, 에디터, 디버거, 명령어 해석기, 시분할체제와 리스프머신 운영체제에 관해 광범위한 작업을 해왔고, ITS에서 터미널 비의존적인 출력장치를 개발했다. 그런 다음 리스프 기계를 위한 견고한(crashproof) 파일 시스템 하나와 두 개의 윈도우 시스템을 구현했고, 지금은 세 번째 윈도우 시스템을 구상하고 있다. 이것은 GNU는 물론 다른 많은 시스템에 이식될 것이다. 왜 GNU를 만들어야만 했는가? 어떤 프로그램을 좋아한다면 당연히 그것을 좋아하는 사람들과 함께 나누는 것이 황금률(대우받고자 하는 데로 대하라)이라고 생각한다. 소프트웨어를 판매하는 사람들은 사용자를 각각 구분하고, 그들 위에 군림하고, 사용자 서로가 프로그램을 공유하는 것을 막고자 한다. 나는 이런 식으로 사용자 간의 결속이 깨지는 것을 거부한다. 나는 올바를 양심으로 비공개 협정이나 소프트웨어 라이선스 협약에 서명할 수 없다. 여러 해 동안 인공지는 연구소에서 일하면서 그러한 경향과 다른 박정한 일들에 저항해 보았지만 결국에는 그들의 승리로 끝나고 말았다. 내 의지에 역행하는 그런 일들이 일어나는 연구소에 나는 더 이상 머무를 수가 없었다. 내가 계속해서 명예를 손상시키지 않고 컴퓨터를 사용하기 위해, 상업용 소프트웨어를 더 이상 사용하지 않고도 작업을 해나갈 수 있는 충분한 공개 소프트웨어의 본체를 만들 결심을 했다. 유닉스와 호환성을 가지는 이유 유닉스가 이상적인 체제라고 생각하지는 않지만 제법 쓸 만하다고 할 수 있다. 유닉스 체제의 골자는 훌륭한 것이며, 나는 유닉스의 장점을 해치지 않고도 부족한 점을 메꿀 수 있으리라 생각했다. 그리고 유닉스와 호환을 가지면 다른 많은 사람들이 적응하기에도 편리할 것이라 생각했다. GNU를 사용하는 방법 GNU를 사용하는 데 지역적인 제한을 받는 것은 아니다. 누구나 GNU를 수정하고 배포할 수 있지만 어떤 이도 GNU가 보다 널리 배포되는 것을 제한할 수 없다. 즉, 변경한 내용을 독점할 수 없다는 것이다. 나는 모든 버전의 GNU가 공개된 채로 남아 있기를 보장받고 싶은 것이다. 많은 다른 프로그래머들의 동참을 바라는 이유 나는 그 동안 GNU에 흥미를 느끼고 돕고자 하는 많은 프로그래머들을 찾을 수 있었다. 많은 프로그래머들은 시스템 소프트웨어가 상용화된 것을 불쾌하게 생각한다. 이렇게 함으로 해서 보다 더 많은 돈을 벌 수는 있겠지만, 일반적으로 이런 상황에서는 프로그래머들이 서로를 동지로 느끼기보다는 투쟁해야 할 대상으로 느끼게 된다. 프로그래머들 사이에 우정을 나타내는 가장 기본적인 행동은 프로그램을 나누는 것이다. 이제는 전형적인 핵심으로 여기는 마케팅 협정은 프로그래머들이 친구로서 다른 프로그래머를 대하는 것을 금하고 있다. 소프트웨어를 구입한 자는 우정과 준법 중 하나를 선택해야만 한다. 물론 자연적으로 많은 이들이 우정을 보다 중요시한다. 그러나 법의 존재가치를 인정하는 사람들은 어떤 결정을 내리든 편한 마음을 가질 수 없다. 그들은 냉소적이 되어 프로그래밍은 단지 돈을 버는 수단이라고 생각하게 된다. 그러나 독점적인 프로그램들 대신 GNU를 사용하게 되면 우리는 모든 이에게 온정을 가질 수 있으며 법도 준수하게 된다. 게다가 GNU는 영감을 주는 예와 다른 이가 우리와 나누는 일에 동참하도록 고무하는 깃발 노릇도 한다. 이는 우리가 상용 프로그램을 쓸 때는 느낄 수 없는 조화로운 느낌을 갖게 한다. 나와 대화한 프로그래머들 중 거의 반 정도는, 이것은 돈이 대신할 수 없는 중요한 행복이라는 데 공감했다. 당신이 기여할 수 있는 방법 나는 제조업자들에게는 기계와 돈을, 개인들에게는 프로그램과 노동을 지원해 줄 것을 요청한다. 컴퓨터를 기증해서 기대할 수 있는 중요한 점은 GNU가 머지않아 그 기계에서 작동할 것이란 점이다. 기증된 컴퓨터는 완전해질 것이며, 따라서 시스템을 사용할 준비를 모두 갖추게 되어 파워와 효율을 과대포장할 필요가 없을 것이다. 나는 GNU를 위해 시간제로 일하기를 갈망하는 많은 프로그래머들을 찾을 수 있었다. 대부분의 프로젝트에서 그러한 시간제로 배치된 작업을 통합하고 조정하는 일은 매우 어려웠다. 독립적으로 쓰여진 부분들은 함께 동작하지 않았다. 그러나 특정한 작업인 유닉스 시스템은 개별적인 설명이 포함된 백여 개의 유틸리티를 포함한다. 대부분의 인터페이스 사양은 유닉스에 호환되도록 맞추어진다. 만약 각각의 프로그래머가 유닉스 유틸리티 한 개를 유닉스에 호환하도록 재 구현하고 본래의 유닉스 시스템에서 충분히 작동하게 할 수 있으면, 이것들은 함께 묶어 놓아도 올바르게 작동할 것이다. 만일 누군가가 예기치 못했던 문제를 야기시킨다 해도 전체적인 구성요소들을 통합하는 작업은 충분히 가능할 것이다.(커널을 만드는 작업은 세밀한 대화가 필요할 것이며, 소수의 호흡이 잘 맞는 집단이 적당할 것이다.) 만일 내가 금전적인 지원을 얻는다면, 약간의 인원을 전시간 또는 시간제로 고용할 수 있을 것이다. 일반적인 프로그래머 수준의 높은 봉급을 줄 수는 없겠지만, 돈이 가지는 것만큼 공동체 의식을 정립하는 일도 중요한 의미를 가진다고 생각하는 사람들을 찾아볼 것이다. 모든 컴퓨터 사용자가 이득을 얻게 되는 이유 일단 GNU가 작성되니까, 마치 공기처럼 모든 사람들이 훌륭한 시스템 소프트웨어를 무료로 얻을 수 있게 되었다. 이것은 단지 모든 이에게 유닉스 저작권에 대한 비용을 덜어주는 것보다 훨씬 더 많은 의미를 가진다. 이는 시스템 프로그래밍에 드는 노력이 불필요하게 중복되는 것을 피할 수 있음을 의미한다. 대신 절약된 노력은 기술 수준을 향상시키는 데 사용될 것이다. 완벽한 시스템 소스가 모든 사람들에게 제공될 것이다. 결과적으로 시스템에 변화를 주고자 한다면 언제든지 스스로 자유롭게 수정할 수 있을 것이다. 혹은 적당한 프로그래머나 업체에게 의뢰할 수도 있을 것이다. 사용자들은 더 이상 프로그램 소스를 가진 프로그래머나 회사에 의존하지 않아도 될 것이며 독자적으로 수정을 가할 수 있을 것이다. 학교는 모든 학생들이 시스템 코드를 배우고 향상시키도록 장려함으로써 보다 나은 교육환경을 조성할 수 있을 것이다. 하버드 컴퓨터 연구소에서는 어떤 프로그램이든지 그 소스가 공개 전시되지 않으면 시스템에 설치하지 못하게 하는 정책을 쓰곤 했다. 실제로 어떤 프로그램들을 설치하지 못하게 함으로써 이 정책을 고수했다. 나는 이것에서 커다란 영감을 받게 되었다. 결국에는 누가 시스템 소프트웨어를 소유하고 있으며, 누구에게 사용할 수 있는 자격을 부여할 것인지 아닌지를 고려하는 제비용은 상승하게 될 것이다. 복사 라이센스를 포함하여 프로그램 사용에 대한 지불을 준비할 때는 언제나 개인이 지불해야 할 돈이 얼마인가를 알아내야 하는 필요성을 통하여 사회에 많은 비용을 야기시킨다. 그리고 오직 경찰당국만이 모든 사람이 그것을 따르게 하도록 힘을 행사할 수 있다. 막대한 비용을 들여 공기를 생산하는 우주 정거장을 생각해 보자. 이런 경우 각각의 개인은 자신이 호흡하는 공기에 대해 리터 단위로 요금을 지불하는 것이 합당할 것이다. 그렇다고는 해도 호흡하는 공기의 양을 계측하기 위해 메터기가 달린 방독면을 밤낮으로 쓰고 있어야 한다면 그런 방식은 타당한 것이 아니다. 그리고 TV카메라는 당신이 마스크를 벗는 불법을 행하는지 어디서나 지켜보아야 할 것이며, 이것 보다는 사람수에 따라 일정한 세금을 부과하고 마스크를 벗어 던지는 것이 현명하다. 프로그램의 일부 혹은 전체를 복사하는 행위는 프로그래머에게 있어서는 숨을 쉬는 것만큼이나 자연스러운 일이며, 생산적이다. 따라서 프로그램은 마땅히 공개되어야 한다. 몇가지 GNU의 목표에 대한 반대 의견 "무료라면 아무도 그것을 쓰지 않을 것이다. 왜냐하면 무료라는 것은 어떠한 지원도 기대할 수 없다는 것을 의미하기 때문이다." "당신은 그 프로그램에 대한 지원과 도움을 제공하는 대가로 이에 관한 비용을 부과해야만 한다." 만약 사람들이 돈을 지불하고서 GNU에 대한 서비스를 받기 희망한다면, GNU를 무료로 얻은 사람들에게 서비스를 제공하는 회사도 이익을 얻을 수 있을 것이다. 우리는 반드시 실제 프로그래밍 작업과 단순 관리 작업을 구별해야 한다. 전자는 때때로 소프트웨어 판매 회사에게 의존할 수가 없다. 만일 당신의 문제가 충분한 사람에 의해 나누어지지 않는다면 회사는 잊어버리라고 말할 것이다. 만일 당신의 사업이 지원에 대한 의존이 필요하다면, 가능한 필요한 모든 소스와 도구를 갖춰야 할 것이다. 그러면 당신은 당신의 문제를 해결해 줄 수 있는 사람을 고용할 수 있으며, 이것은 다른 어떤 사람의 자비를 받는 것은 아니다. 유닉스 상에서 소스의 가격은 대부분 고려되지 않으며, GNU는 더 쉬울 것이다. 이것은 여전히 유능한 사람이 필요 없을 수는 있으나, 배포에 따른 비난을 할 수 없다. GNU는 모든 세계의 문제를 제거하는 것은 아니며, 단지 그 중 하나이다. 한편, 컴퓨터에 대해 전혀 모르는 사용자들은 여전히 단순한 관리 서비스를 필요로 한다. 이러한 일은 사용자 스스로 능히 처리할 수 있는 종류의 일이지만 그들은 그러한 방법을 모르기 때문이다. 이런 서비스들은 단순한 수작업이나 복구 서비스를 지원하는 회사들이 제공할 수 있다. 사용자들이 제품을 사고, 그에 대한 서비스를 받는 방식을 받아들인다면, 제품을 무료로 받고 서비스를 제공하는 회사들은 가격과 질적인 면에서 모두 완벽을 기할 수 있을 것이며, 사용자들은 어떤 특정한 업체에 얽매일 필요는 없을 것이다. 또한 그러한 서비스가 필요하지 않는 사람들은 서비스에 대한 비용을 들이지 않고도 프로그램을 쓸 수 있을 것이다. "광고를 하지 않고는 많은 사람들에게 알릴 수 없을 것이며, 그러기 위해서는 필히 프로그램에 가격을 매겨야 한다." "무료로 제공되는 프로그램을 광고하는 것은 무의미하다." GNU 같은 프로그램을 많은 컴퓨터 사용자들에게 알릴 수 있는 방법에는 무료, 혹은 극히 적은 비용으로 사용할 수 있는 다양한 공공 정보 전파 방식이 있다. 그러나 광고를 하는 것이 보다 많은 마이크로 컴퓨터 사용자에게 알릴 수 있는 방법일지도 모른다. 만일 실제로 이런 것이 사실이라면, 복사와 배포를 하는 데 돈을 받음으로써 능히 광고와 그 외의 부수적인 비용을 감당할 수 있을 것이다. 이런 방식에서는 광고를 보고 배포본을 구입해서 이익을 얻을 수 있는 사용자가 광고비용을 부담하게 되는 것이다. 반면 많은 사람들이 GNU를 그 친구들을 통해서 구한다면, 이런 종류의 회사들은 성공할 수 없을 것이다. 이는 GNU를 보급하는 데 광고가 필요한 것은 아님을 보여준다. 그렇다고 한다면 무료로 보급되고 있다는 사실이 무료로 알려지는 것을 바라지 않을 만한 이유가 있겠는가? "나의 회사는 경쟁사들에 대한 우위를 차지하기 위해 독점적인(고유의)운영체제가 필요하다. GNU는 시스템 소프트웨어 경쟁이라는 범주에서 제외될 것이다. 당신의 회사가 우위를 차지할 수 없는 것처럼, 당신의 경쟁사들도 그 점에 있어서는 마찬가지일 것이다. 당신과 당신의 경쟁사들 모두 이 분야에서는 별반 이득을 볼 수 없겠지만, 다른 분야에서 서로 경쟁하는 것은 가능할 것이다. 당신의 사업이 운영체제를 판매하는 것이라면 GNU가 마땅치 않게 생각될 것이다. 당신의 사업이 이런 종류가 아니라면 GNU는 시스템 소프트웨어에 관련된 막대한 비용을 절감해 줄 것이다. 나는 제작자와 사용자들이 GNU의 발전에 기여해 나감으로써 서로의 비용을 절감할 수 있기를 희망한다. "프로그래머는 그의 창의력에 대한 보상을 받을 자격이 있지 않은가?" 보상받을 만한 일이란 사회적 공헌을 말한다. 창의성이란 그 결과물을 사회가 대가없이 사용할 수 있을 때 사회적 공헌이 되는 것이다. 어떤 혁신적인 프로그램을 제작한 사람이 그에 대해 보상을 받아야만 한다면, 같은 맥락에서 그것을 자유롭게 사용하지 못하게 한다면 그 때는 제재를 받아야 할 것이다. "프로그래머는 그의 창의력에 대한 보상을 요구할 수 없는가?" 유해한 수단을 사용하지 않는다면 노동에 대한 보수와 자신의 소득이 극대화되기를 바라는 것은 아무 문제가 없다. 그러나 지금까지 소프트웨어 산업에서 보편화된 수단은 유해한 방법이다. 프로그램을 사용하는 것에 제한을 둠으로서 돈을 벌어들이는 행위는 프로그램이 사용되는 범위와 방식을 제한하기 때문에 유해한 것이다. 이는 인간들이 프로그램으로부터 얻을 수 있는 전체적인 풍요로움을 감소시키는 것이다. 선량한 시민이라면 자신이 보다 부유해지기 위해 그런 수단을 쓰지 않는다. 그 까닭은 만일 모든 사람들이 그렇게 한다면 상호간의 유해한 행위로 인해 결과적으로 우리 모두는 보다 빈곤해질 것이기 때문이다. 이것은 칸트의 윤리학이나 황금률 같은 분명한 것이다. 나는 모든 사람들이 자기만의 정보를 축적해 나가는 것은 바람직하다고 여기지 않기 때문에, 누군가 그런 일을 한다면 나는 그것이 잘못된 일이라고 생각할 필요를 느끼게 되었다. 특히, 한 개인의 창의성을 보장받고자 하는 욕구가 일반적으로 전체의 창의성이나 혹은 그 일부분을 저하시키는 행위를 정당화시키지는 않는다. "프로그래머들의 밥줄이 끊기지 않을까?" 나는 모든 사람이 프로그래머가 될 필요는 없다고 답하고 싶다. 아마 우리들 대부분은 거리에 나가 인상을 써서 간신히 약간의 돈을 벌어 살아갈 수는 없을 것이다. 그러나 결과적으로, 우리는 거리에 나가 인상써서 돈을 번다고 비난받을 필요도 없고, 또한 빈궁해질 필요도 없을 것이다. 우리는 그와는 다른 일을 할 수 있을 것이다. 그러나 이것은 "프로그래머는 소프트웨어를 소유하지 않으면 단 한푼도 벌 수 없다."라고 질문하는 사람의 독단적인 가정을 받아 들였다는 점에서 오답이라 할 수 있다. 아마도 이런 생각은 극단적일 것이다. 프로그래머가 생계에 지장을 받지 않을 것에 대한 진정한 이유는, 지금과 같은 정도는 아니겠지만 여전히 프로그래밍으로 돈을 벌 방법들이 있기 때문이다. 프로그램 복사를 제한하는 것이 소프트웨어 사업의 유일한 기본 방침은 아니다. 이런 방침이 보편화된 것은 이렇게 함으로써 가장 돈을 많이 벌 수 있기 때문이다. 고객들에 의해 이런 방식이 거부되거나 금지된다고 해도, 소프트웨어 사업은 지금까지 흔하지는 않았던 새로운 조직 체계로 전환해 나갈 길을 모색할 수 있을 것이다. 여러 가지 사업을 한데 묶어 조직화하는 방법은 무궁 무진한 것이다. 아마 새로운 기반하에서의 프로그래밍은 지금처럼 수익성이 높은 일은 아닐 것이다. 하지만 이것이 변화의 쟁점은 아니다. 지금의 판매 사원들이 그들의 봉급을 버는 방식이 불합리한 것이라고 생각하지는 않는다. 프로그래머들이 그와 같은 방법으로 소득을 올린다 해도 하등 정당하지 못할 이유가 없다(실제적으로 프로그래머들은 여전히 그들보다 월등히 많은 소득을 올리고 있다.) "누구든 그들의 창의력이 사용되는 방법을 지배할 수 있지 않은가?" "인간 생각의 쓰임새를 지배하는 것"은 실제적으로는 그의 인생을 지배하는 것이다. 이는 자신의 인생을 보다 어렵게 만들곤 한다. 지적 소유권에 관해 상세하게 공부한 사람들(변호사 등)은 그 자체로서 완벽한 지적 소유물은 없다고 말한다. 정부가 인정하는 추상적인 지적 소유권들은 특정 목적을 위한 특정 법률 조항으로부터 발생한 것이다. 예를 들어, 특허제도는 발명가가 그의 고안품의 세부 사항을 공개하는 것을 장려하고자 설립된 것이다. 그 목적은 발명한 사람을 돕기보다는 사회를 돕기 위한 것이다. 시간의 측면에서 보면, 특허가 갖는 17년간이 유효기간은 기술이 발전하는 비율과 비교해서 특허권 계약에 드는 비용과 노력은 작다고 보기 때문에, 특허권은 일반적으로 그다지 해악 하게 작용하지는 않는다. 또한 그것은 대부분의 개인들이 특허를 받은 제품을 사용하는 것을 제한하지는 않는다. 고대에는 저작권이라는 것이 존재하지 않았으며 그 시대에 작가들은 빈번하게 다른 이의 작품 상당량을 실제의(허구가 아닌)작품에 복제하기도 했다. 이런 작업들은 유용한 것이었으며, 비록 그 일부분이기는 하지만 많은 사람들의 작품이 계속해서 전수되는(존재해 나가는)유일한 방법이었다. 저작권 제도는 작가 의식을 고취시키고자 급진적으로 만들어진 것이다. 이것이 처음 만들어질 때 주로 염두에 두었던 책의 범주에서 보면, 책은 실용적인 측면에서 인쇄기를 사용해야만 복사가 가능하기 때문에 저작권은 그다지 해롭지는 않았다. 또한 대다수의 사람들이 책을 읽는 것을 제한하지도 않았다. 모든 지적 소유권은 그것들이 어떻든지 그를 허용함으로써 사회 전체에 이득이 된다고 여겨져서, 사회가 허용할 때만 정당하게 되는 것이다. 그러나 어떤 특정 상황에서든 우리는 "그런 인가를 내주는 것이 정말로 우리에게 유익한가? 어떤 종류의 인가를 내줄 것인가?" 하는 질문을 해보아야만 한다. 오늘날의 프로그램들의 경우는 백여년 전의 책의 경우와 크게 다르다. 프로그램이 이웃간에 손쉽게 복사될 수 있다는 사실, 소스 코드와 목적코드로 구분된다는 점, 읽기 위한 것이 아니라 즐기기 위한 것이라는 사실들이 묶여져서, 저작권을 강요하는 사람들이 전체사회에 정신적, 물질적으로 해를 끼치는 상황을 만들고 있다. "경쟁함으로써 보다 나은 결과를 얻을 수 있는가?" 모범적인 경쟁 방식은 경주(race)이며, 승자에게 상을 줌으로써 주자들이 더욱 빨리 달리도록 장려할 수 있는 것이다. 만약 자본주의가 실제로 이런 방식을 따른다면 이는 바람직한 것이다. 그러나 자본주의 옹호론자들은 실제로 항상 이런 방식으로 움직인다고 단정짓는 잘못을 범한다. 만일 주자들이 상이 주어지는 이유를 망각한 채 승리에만 집착한다면, 말할 것도 없이 그들은 다른 주자를 공격한다든지 하는 색다른 전략을 찾게 될 것이다. 주자들이 먼저 싸우기부터 한다면, 그들은 결국 모두 늦어질 수 밖에 없는 것이다. 독점적이고 비밀에 싸인 소프트웨어는 도덕적으로 먼저 싸우기부터 하는 주자들과 동일하다. 슬픈 일이지만 우리의 유일한 심판은 그다지 공정해 보이지 않으며, "매 10야드마다 한 번씩 상대방을 가격할 수 있다."는 규정을 적용하는 정도일 것이다. 그러한 싸움이 있을 때는 그들을 떼어놓고 벌칙을 주어야 하는 데도 말이다. "금전적인 장려가 없다면 아무도 프로그래밍을 하지 않을 것이다." 실제적으로 많은 사람들이 분명한 금전적인 장려가 없어도 프로그래밍을 할 것이다. 프로그래밍은 어떤 사람들에게는 저항할 수 없는 매력인 것이며, 일반적으로 프로그래밍에 능숙한 사람에게 더욱 그렇다. 비록 생활의 기반이 될 가망이 없더라도 꾸준히 계속해 가는 직업적인 음악인들이 많이 있다. 그러나 실제로 질문은 비록 일반적으로 많이 제기되지만, 상황에 적합하지 못하다. 프로그래머들의 소득원이 없어지는 것이 아니라 단지 수입이 줄어드는 것일 뿐이다. 따라서 올바른 질문은 "금전적인 보상이 줄어들더라도 사람들이 프로그래밍을 하게 될까?"일 것이다. 내 경험에 의하면 그렇게 할 것이다. 십년 이상 동안, 세계 정상급 프로그래머들이 인공지는 연구소에서 일했었지만, 그들이 받은 보수는 다른 어떤 곳에서 기대할 수 있는 것보다 훨씬 적은 것이었다. 그들은 명성이나 감사 같은 다양한 종류의 비금전적인 보상을 받았다. 그리고 창의력은 그 자체 안에 보상이라는 개념을 가지고 있다는 점에서 흥미로운 것이다. 그후 그들 대부분은 이전의 작업처럼 그들이 흥미롭게 생각하는 일을 높은 부수를 받으며 할 수 있는 기회가 주어지자 연구소를 떠났다. 이 사실에서 알 수 있는 것은 사람들은 부유해지기 보다는 어떤 까닭을 위해서 프로그래밍을 한다는 것이며, 그런 조건 위에 상당한 보수까지 받을 기회가 주어진다면 그를 예상하고 요구하게 되는 것이다. 보수가 낮은 조직은 높은 보수를 받는 조직과의 경쟁에서 뒤지겠지만, 만일 높은 보수를 받는 조직과는 상호 이동이 없는 완전히 개별적인 집단이라면 그들 나름대로 훌륭하게 활동할 것이다. "우리는 프로그래머가 절대적으로 필요하다. 만일 그들이 우리의 이웃을 돕지 말라 하면 우리는 따를 수 밖에 없다." 당신들은 결코 그런 종류의 요구에 복종해야 할 만큼 절박하지 않다. 명심하라. 열 장정이 도둑 하나를 막지 못하는 법이다. "프로그래머들도 어떤 식으로든 그들의 생계를 꾸려 나가야 하지 않은가?" 요컨대 이것은 진실이다. 그러나 프로그램의 사용에 대한 권리를 파는 것 이외에도 생계를 꾸릴 수 있는 수많은 방법들이 있다. 현재 사용에 대한 권리를 파는 것이 보편적으로 받아들여지는 것은 그런 방식으로 프로그래머나 사업자들이 보다 많은 돈을 벌 수 있기 때문이지, 결코 이것이 생계를 유지하는 유일한 방법이기 때문은 아니다. 다른 방법을 찾고자 한다면 얼마든지 가능할 것이다. 여기 여러 가지 예들이 있다. 새로운 컴퓨터를 내놓는 제조업자는 새 기계에 운영체제를 이식하기 위한 비용을 지불하게 된다. 교육, 단순 관리 작업, 지속적인 서비스들을 제공하는 회사에서도 역시 프로그래머는 필요한 것이다. 사용자의 마음에 흡족하다면 그에 대한 보수를 지불해 달라고 요구하는, 프리웨어라는 새로운 아이디어로 프로그램을 배포하는 사람들도 있다. 혹은 단순 관리 서비스를 제공하고 보수를 받는 사람들도 있다. 나는 이미 이런 방식으로 성공한 사람들을 만났다. 도움이 필요한 사용자들은 사용자 그룹을 결성하고 회비를 조성할 수 있을 것이다. 그룹은 프로그래밍 회사와 계약을 맺고 회원들이 원하는 프로그램을 주문 제작할 수 있을 것이다. 모든 종류의 발전에 필요한 기금은 소프트웨어 세금으로 조성할 수 있을 것이다. 만약 컴퓨터를 구입하는 모든 사람들의 가격의 x 퍼센트를 소프트웨어 세금으로 지불한다면, 정부는 그 돈을 소프트웨어 발전에 쓰여지도록 NSF 같은 단체에 지원할 수 있을 것이다. 그러나 컴퓨터 구입자가 개별적으로 소프트웨어 발전에 공헌한 바가 있다면, 그는 세금을 면제받게 될 것이다. 그는 스스로 어느 프로젝트에 기부할 것인지를 결정할 수 있을 것이며, 때론 그 결과를 쓸 수 있을 것이란 기대를 품고 결정을 내리게 될 것이다. 얼마를 기부하든 지불해야 할 세금 전액을 대신할 수 있을 것이다. 세금의 전체적인 세율은 납세자들이 투표를 해서 결정할 수 있을 것이며, 지불할 액수에 따라 차등 조정될 것이다. 결론: ▶ 컴퓨터 사용자 공동체는 소프트웨어 발전을 지원한다. ▶ 어느 수준의 지원을 할 것인가는 이 공동체가 결정한다. ▶ 자신의 몫이 어떤 프로젝트에 쓰일 것인가에 관심 있는 사용자들은 이를 스스로 결정할 수 있을 것이다. 결국에는 프로그램을 무료로 보급하는 것은 더 이상 단지 생계를 위해 고되게 일할 필요가 없는 풍요로운 세계로 가는 한 단계인 것이다. 사람들은 프로그래밍 같은, 자신이 흥미를 가질 수 있는 일에 시간을 마친 후엔 가족들과 담소한다든지, 로보트를 수리한다든지, 천체를 관측하는 일 따위를 하게 될 것이다. 더 이상 프로그래밍을 생계의 수단으로 삼을 필요가 없게 될 것이다. 우리는 이미, 실제적인 생산성을 향상시키기 위해 전체 사회가 부담해야 할 작업의 분량을 많이 감소시켰다. 이중 매우 적은 부분은 단지 프로그래머들의 유희를 위해서 작성되었다. 그 까닭은 비생산적인 활동이 생산적인 활동을 하기 위해 필요한 것이기 때문이다. 이런 일을 하게 된 주된 이유는 경쟁을 대신할 수 있는 관료정책이며 그와 동일한 부피를 갖는 몸부림인 것이다. 프리소프트웨어는 소프트웨어 생산 분야에서 생산력이 낭비되는 것을 크게 감소시킬 수 있을 것이다. 우리는 이러한 작업을 해 나가야 하며, 생산성을 위한 기술 습득은 적은 노력으로 가능할 것이다. Copyright (C) 1985 Richard M. Stallman 이 문서의 저작권과 배포 허용에 관한 주의사항을 전제하기만 한다면 누구나 이 문서를 요약해서 배포하거나 부분적으로 이용할 수 있으며, 이 글과 같은 방법으로 자신의 문서가 재 배포되는 것을 허용할 수 있을 것이다. 자유 소프트웨어란 무엇인가? What is Free Software? "자유 소프트웨어"의 핵심은 구속되지 않는 자유에 있지 금전적인 혜택에 있는 것이 아니다. 우리가 의도하는 이러한 자유의 의미를 쉽게 이해하기 위해서는 "무료 맥주(free beer)"가 아닌 "언론의 자유(free speech)"와 같은 예를 생각해 볼 수 있을 것이다. "자유 소프트웨어"는 사용자가 소프트웨어를 실행시키고 복제(copying), 배포할 수 있는 자유와 함께 소스 코드에 대한 접근을 통해서 이를 학습하고 수정, 개선시킬 수 있는 원천적인 자유까지를 포괄한다. 따라서, 간략히 말하면 다음과 같은 세 가지 범위의 자유를 내포한다고 할 수 있다. 프로그램의 작동 원리를 연구하고 이를 자신의 필요에 맞게 변경시킬 수 있는 자유 프로그램을 이웃과 함께 공유하기 위해서 이를 복제하고 배포할 수 있는 자유 프로그램을 향상시키고 이를 공동체 전체의 이익을 위해서 다시 환원시킬 수 있는 자유 GNU 소프트웨어를 사용하기 위해서 지불된 비용의 유무에 상관없이 일단, 소프트웨어를 입수한 뒤에는 이를 복제하고 수정할 수 있는 자유가 제한 없이 주어진다. GNU 프로젝트는 이러한 자유를 모든 사용자들에게 실질적으로 보장하기 위해서 저작권의 양도에 관한 실정법에 의해서 그 법률적 효력이 인정될 수 있는 '카피 레프트(copyleft)'라는 새로운 개념을 도입하고 있다. "자유 소프트웨어"와 "카피 레프티드 소프트웨어(copylefted software)" 등과 같이 우리가 구분하고 있는 소프트웨어의 종류와 상호간의 차이점에 대해서는 "소프트웨어의 범주(Categories of Free and Non-Free Software)" 문서를 참조해 주기 바란다. 우리가 의도하고자 하는 자유의 본뜻을 퇴색시키지 않기 위해서 자유 소프트웨어를 언급할 때는 되도록 "무상으로 제공" 된다든가 "무료"라는 등의 표현을 사용하지 말 것을 당부하고 싶다. 또한, 이러한 자유의 억압을 합리화시키는 "저작권 침해(piracy)"와 같은 제도적 장치에 우리 모두가 동의하지 않게 되기를 희망한다. 저작권 침해에 대한 우리의 견해에 대해서는 "혼동을 피하기 위해서 사용을 삼가해야 할 단어나 구문들(Confusing Words and Phrases that are Worth Avoiding)" 문서를 참고하기 바란다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전제나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: What is Free Software? Drafted version: Leonard Tower's 4 Aug 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Song Changhun 송창훈 chsong@cyber.co.kr 자유 소프트웨어 재단이란 무엇인가? What is the Free Software Foundation? 자유 소프트웨어 재단(Free Software Foundation)은 컴퓨터 프로그램의 복제(copying)와 배포(redistribution), 개작(modification)과 이를 위한 소스 코드의 원용에 대한 제한들을 철폐하기 위한 목적으로 설립되었다. 우리는 컴퓨터를 이용한 모든 부문에 걸친 자유 소프트웨어를 개발하고 있으며 특히, GNU 시스템으로 불리는 자유 운영체제의 개발을 지원함으로써 우리의 목적을 달성하려고 한다. 많은 단체들의 중복된 자유 소프트웨어 배포 관행에 반해서 자유 소프트웨어 재단은 새로운 소프트웨어의 개발에 집중하고 있으며 이는 독점적인 상업용 운영체제를 대체하기에 충분한 GNU 시스템을 구축하기 위한 것이다. 자유 소프트웨어 재단은 GNU 시스템의 개발과 더불어 GNU 소프트웨어와 각종 매뉴얼에 대한 판매 사업도 펼치고 있다. 이는 재단 운영을 위해서 필요한 거의 대부분의 자금이 제작 실비에 준하는 판매 수익금을 통해서 조성되고 있기 때문이며 조세 혜택이 주어지는 다양한 형태의 기부 또한 받아들이고 있는 실정이다. 가능하다면 자유 소프트웨어 재단을 통해서 필요한 제품들 - 특히, CD-ROM을 구입할 것을 권유하는 이유는 바로 여기에 있다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: What is the Free Software Foundation? Drafted version: Richard M. Stallman's 26 Dec 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Song Changhun 송창훈 chsong@cyber.co.kr -------------------------------------------------------------------------------- 소프트웨어의 범주 Categories of Free and Non-Free Software 자유 소프트웨어를 논할 때 자주 언급되는 소프트웨어의 종류에 대한 용어들이 있다. 이 문서는 서로 중복되거나 포함될 수 있는 소프트웨어들의 범주에 대해서 설명하고 있다. | "자유 소프트웨어" | "공개 소프트웨어" | "카피 레프티드 소프트웨어" | | "카피 레프트가 아닌 자유 소프트웨어" | "GPL이 적용되는 소프트웨어" | | "GNU 시스템" | "GNU 소프트웨어" | "부분적인 자유 소프트웨어" | | "독점 소프트웨어" | "셰어웨어" | "상용 소프트웨어" | '혼동을 피하기 위해서 사용을 삼가해야 할 단어와 구문들(Confusing Words which You Might Want to Avoid)' 문서 또한 참고해 주기 바란다. 자유 소프트웨어(Free Software) 자유 소프트웨어는 누구에게나 사용과 복제(copying), 배포(distribution)와 개작(modification)이 승인된 소프트웨어다. 특별히, 이것은 소스 코드 (source code)가 이용 가능하다는 것을 의미한다. 또한, 이윤 추구를 위한 유 료 판매의 가능성까지도 포함하고 있다. 프로그램이 자유롭다면, 그것은 잠재적으로 GNU와 같은 자유 운영체제에 포함 될 수 있다. 세부적으로 많은 사항들이 포함되어 있기는 하지만, 프로그램을 자유롭게 만드는 방법에는 여러 가지가 있다. 한가지 이상의 방법으로 프로 그램을 자유롭게 만들 수 있으며 몇 가지 방법이 혼합된 경우에도 여전히 프 로그램은 자유로운 상태로 남아 있을 수 있다. 몇 가지 가능한 형태들이 아래 에 설명되어 있다. 자유 소프트웨어는 가격이 아닌 자유로움의 문제이다. 그러나, 독점 소프트웨 어 회사들은 가끔씩 "자유 소프트웨어"라는 용어를 가격을 언급할 때 사용한 다. 그들은 바이너리(binary)를 무료로 얻을 수 있거나 컴퓨터를 구입할 때 함께 제공되는 소프트웨어를 지칭할 때 자유 소프트웨어라는 용어를 사용하기 도 한다. 그러나, 이것은 GNU 프로젝트가 지향하는 자유 소프트웨어의 의미와 는 거리가 먼 것이다. 이러한 잠재적인 혼란 때문에 소프트웨어 회사가 그들의 제품을 자유 소프트 웨어라고 말할 때는 자유 소프트웨어가 함축하고 있는 모든 자유가 사용자에 게 실제적으로 보장되는가의 여부를 살펴보기 위해서 해당 소프트웨어의 배포 규정들을 항상 확인해 볼 필요가 있다. 때로는 자유 소프트웨어일 수도 있지 만, 때로는 그렇지 않을 수도 있다. 많은 언어에는 구속되지 않는다는 뜻의 '자유'와 무료라는 의미의 '자유'의 두 가지 구별되는 단어가 있다. 예를 들면, 불어에는 'libre'와 'gratuit'가 있다. 영어에는 가격의 관점을 명확하게 지칭하는 'gratis'라는 단어가 있지 만 자유로움을 명확하게 언급하는 일반적인 형용사는 없다. 우리가 사용하려 고 하는 이러한 의미의 단어가 존재하지 않는다는 것은 무척이나 안타까운 일 이다. 자유 소프트웨어는 또한 더 신뢰할 수 있다. 공개 소프트웨어(Public domain software) 공개 소프트웨어는 저작권이 없는 소프트웨어이다. 이것은 저작권이 없는 자 유 소프트웨어의 특별한 경우이다. 이것은 원래의 소프트웨어를 복제하거나 개작한 것은 전혀 자유롭지 않을 수도 있다는 것을 의미한다. 가끔씩 사람들은 "공개"라는 단어를 "자유" 또는 "무료"로 얻을 수 있다는 의 미로 사용하는 경향이 있다. 그러나, "공개"라는 것은 정확하게 말해서 "저 작권이 없음"을 의미하는 법률 용어이다. 따라서, 명확한 의미의 전달을 위해 서 저작권이 없음을 나타날 때는 "공개"라는 용어를 사용하고 그 외의 경우에 는 다른 적절한 용어들을 사용할 것을 권장한다. 카피 레프티드 소프트웨어(Copylefted software) 카피 레프티드 소프트웨어는 소프트웨어의 피양도자가 이를 다시 배포하거나 개작할 때, 그 배포 조건에 어떠한 부가적인 제한 사항도 첨가할 수 없는 소 프트웨어를 의미한다. 이것은 설사 소프트웨어가 개작되었다 하더라도 해당 소프트웨어의 모든 복제본은 자유 소프트웨어여야 한다는 것을 의미한다. GNU 프로젝트의 소프트웨어들은 '자유 소프트웨어'라는 용어에 함축되어 있는 자유를 모든 사용자에게 제공하기 위한 목적에 따라서 대부분의 소프트웨어를 카피 레프티드 소프트웨어로 설정하였다. 왜 소프트웨어를 카피 레프트로 설정하고 실제로 그것이 어떻게 유효하게 되는가에 대해서는 독립된 문서인 '카피 레프트란 무엇인가(What is Copyleft?)'를 참고하기 바란다. 카피 레프트는 일반적인 개념이다. 따라서, 실제로 프로그램을 카피 레프트로 만들기 위해서는 특정한 배포상의 조건들을 설정해야 한다. 프로그램을 카피 레프트로 만들기 위한 배포 조건의 설정은 많은 방법들이 있을 수 있다. 카피 레프트가 아닌 자유 소프트웨어(Non-copylefted free software) 카피 레프트가 아닌 자유 소프트웨어는 배포와 개작 그리고 그것에 부가적인 제한을 더하기 위한 승인이 소프트웨어의 저작자로부터 수반되는 경우에 해당 한다. 만일 프로그램이 자유 소프트웨어라 하더라도 카피 레프트가 아니라면 몇몇 복제본 또는 개작된 배포본은 전혀 자유롭지 않을 수도 있다. 소프트 웨어 회사는 프로그램을 개작하거나 개작하지 않고 컴파일할 수 있다. 그리 고, 독점 소프트웨어의 형태로 실행 파일을 배포할 수 있다. X 윈도우 시스템은 이러한 형태의 단적인 예라고 할 수 있다. X 컨소시움 (consortium)은 카피 레프트가 아닌 자유 소프트웨어로 취급된다는 배포 조 건에 따라서 X11을 배포했다. 만약, X11을 사용하기 원한다면 해당 배포 기 준을 준수하는 조건으로 자유롭게 이를 얻을 수 있다. 그러나, 자유롭지 않은 배포판들이 역시 존재하고 있고 이러한 비자유판들만이 작동하는 유명한 워크 스테이션(workstation)들이나 PC 그래픽 보드들이 있다. 이러한 종류의 하 드웨어를 이용한다면 X11은 자유 소프트웨어가 아닐 것이다. GPL이 적용되는 소프트웨어(GPL-covered software) GNU GPL(General Public License)은 프로그램을 카피 레프트로 만들기 위한 특정 배포 조건들의 집합이다. GNU 프로젝트는 대부분의 GNU 소프트웨어들의 배포 조건으로 GNU GPL을 사용하고 있다. GNU 시스템(GNU system) GNU 시스템은 유닉스 호환의 완벽한 자유 운영체제이다. 유닉스 호환 운영체제는 많은 프로그램들로 구성되어 있다. 우리는 1984년부 터 이 운영체제의 구성 요소들을 축적해 왔다. 첫 번째 '완성된 GNU 시스템' 의 시험 공개는 1996년에 있었다. 우리는 일년 남짓한 기간에 이 운영체제가 일반 사용자들에게도 권장할 수 있을 만큼 성숙되기를 희망한다. GNU 시스템은 모든 GNU 소프트웨어뿐만 아니라, X 윈도우 시스템과 문서 형식 기(text formatter)인 TeX와 같은 GNU 소프트웨어가 아닌 소프트웨어 패키지 또한 포함하고 있다. GNU의 의도가 자유로움이기 때문에 GNU 시스템 안의 모든 구성 요소들은 자유 소프트웨어여야만 한다. 그것들이 모두 카피 레프티드 소프트웨어일 필요는 없지만 기술적인 목적을 충족시키기 위해서 함께 사용하기 위해서는 합법적인 요건들을 갖추고 있어야만 한다. 우리는 X 윈도우 시스템과 같은 카피 레프 트 이외의 자유 소프트웨어들을 사용할 수 있고 또 사용하고 있다. GNU 소프트웨어(GNU software) GNU 소프트웨어는 GNU 프로젝트의 찬조 아래 공개된 소프트웨어이다. 전부는 아니지만 대부분의 소프트웨어들은 카피 레프티드 소프트웨어이다. 그러나, 모든 GNU 소프트웨어는 자유 소프트웨어여야만 한다. 몇몇 GNU 소프트웨어들은 자유 소프트웨어 재단의 운영진에 의해서 작성된다. 그러나, 대부분의 GNU소프트웨어들은 자원자들에 의해서 기증된다. 소프트웨 어에 대한 저작권은 경우에 따라서 자유 소프트웨어 재단이나 소프트웨어를 작성한 기증자에게 돌아가기도 한다. 부분적인 자유 소프트웨어(semi-free software) 부분적인 자유 소프트웨어란 자유 소프트웨어는 아니지만 비영리적인 목적을 가진 개인에 대해서 사용과 복제, 개작과 배포가 허용되는 소프트웨어를 의미 한다. PGP(Pretty Good Privacy-암호화 프로그램)가 이러한 소프트웨어의 일 례이다. 부분적인 자유 소프트웨어는 독점 소프트웨어보다는 훨씬 좋지만 여전히 문제 가 있고 자유 운영체제와 함께 사용할 수 없다. 카피 레프트의 제한 사항은 모든 사용자들의 본질적인 자유를 보호하려는 데 있다. 프로그램의 사용에 대해서 우리가 정당화할 수 있는 유일한 제한 사항 은 제3자에 의해서 어떠한 형태의 제한도 부가되지 못하도록 하는 것이다. 부 분적인 자유 소프트웨어는 오직 이기적인 목적에 의해서 설정된 부가적인 제 한 사항들이 있다. 자유 운영체제에 부분적인 자유 소프트웨어를 포함하는 것은 불가능하다. 이 것은 운영체제에 포함되어 있는 모든 프로그램과 함께 운영체제 전체가 동일 한 배포 규정에 따라야 한다는 조건 때문이다. 부분적인 자유 소프트웨어가 하나라도 포함된다면 결국, 전체적인 운영체제 또한 완전히 자유롭지 못한 부 분적인 자유 소프트웨어가 되는 것이다. 이렇게 되지 않기를 원하는 두 가지 이유가 있다. 자유 소프트웨어는 학생이나 호사가뿐만 아니라 기업까지를 포함하는 모든 사 람들을 위한 것이여야한다. 우리는 기업에서도 GNU 시스템을 사용할 것을 권 유하고 싶다. 따라서, 자유 운영체제에는 부분적인 자유 소프트웨어가 포함되 어서는 안된다. 리눅스 기반의 GNU 시스템을 포함한 자유 운영체제의 상업적 배포판은 매우 중요하며 사용자들은 이러한 상업적 CD-ROM 배포판을 구입할 수 있다는 사실 을 높이 평가해야 한다. 자유 운영체제에 부분적인 자유 소프트웨어가 하나라 도 포함된다면 이는 곧 자유 운영체제의 CD-ROM 배포판 자체를 단절시키는 일 이 될 것이다. 자유 소프트웨어 재단은 비영리 단체이므로 '내부적으로' 부분적인 자유 소프 트웨어를 사용하는 것은 합법적이다. 그러나, 이것이 GNU 시스템에 포함시킬 수 있을 프로그램을 작성하려는 우리의 노력을 침식시키는 것이기 때문에 그 렇게 하지 않는다. 소프트웨어가 필요한 작업이 있다면 우리가 그 작업을 수행할 수 있는 프로그 램을 가질 때까지 GNU 시스템은 틈을 가진다. 우리는 자원자들에게 "우리는 GNU 시스템에 이러한 일을 할 수 있는 프로그램이 필요하다. 우리는 당신이 그것을 작성해 주기 원한다." 라고 말할 것이다. 만약, 우리가 이러한 일에 부분적인 자유 프로그램을 사용한다면 이것은 우리가 말한 것들을 손상시키는 것이며 자유로운 대체 소프트웨어를 작성하려는 기세(우리, 그리고 우리의 견 해를 들어줄 만한 다른 사람들의)을 쫓는 것이다. 따라서, 우리는 그렇게 하 지 않는다. 독점 소프트웨어(proprietary software) 독점 소프트웨어는 자유 소프트웨어도, 부분적인 자유 소프트웨어도 아니다. 소프트웨어에 대한 사용과 배포, 개작 행위는 금지되거나 승인이 필요하며 경 우에 따라서 효과적인 활용을 위한 자유로운 사용이 제한되기도 한다. 자유 소프트웨어 재단은 특정 프로그램의 대체품을 개발할 목적으로 한시적으 로 설치되어 있는 경우를 제외하고는 어떠한 독점 소프트웨어도 재단의 컴퓨 터에 설치하거나 사용할 수 없다는 규정을 준수하고 있다. 이러한 경우 외에 는 독점 소프트웨어의 설치에 대한 어떠한 변명도 있을 수 없다고 생각한다. 예를 들면, 1980년대에 유닉스의 설치했던 것을 정당하다고 생각하는 이유는 그것이 유닉스를 대체할 자유 소프트웨어를 작성하기 위한 것이었기 때문이 다. 우리가 그러한 프로젝트를 수행하지 않았다면 유닉스의 사용은 금지되었 을 것이다. 오늘날에는 자유 운영체제가 이용 가능하기 때문에 이러한 이유 가 더 이상 유효하지 않다. 우리는 모든 시스템에서 자유 운영체제가 아닌 것들을 제거해 왔으며 이제는 어떠한 컴퓨터에도 완전한 자유 운영체제만을 설치해서 운영하고 있다. 우리는 GNU의 사용자나 공헌자들이 이러한 규정을 따를 것을 주장하지는 않는 다. 이것은 자유 소프트웨어 재단이 자체적으로 만든 규정일 뿐이다. 그러나, 우리는 많은 사람들이 여기에 동참해 주기를 희망한다. 셰어웨어(shareware) 셰어웨어란 복제물에 대한 배포의 승인이 수반되는 소프트웨어이다. 그러나, 이것을 계속 사용하기 위해서는 사용료를 지불해야 한다. 셰어웨어는 자유 소프트웨어도 아니며 부분적인 자유 소프트웨어도 아니다. 이러한 두 가지 이유는 다음과 같다. 대부분의 셰어웨어는 소스 코드를 이용할 수 없으므로 프로그램을 전혀 개작 할 수 없다. 비영리 활동에 종사하고 있는 개인에게조차도 사용료의 지불에 따른 복제와 설치만을 허용한다(실제는, 사람들은 종종 배포 규정을 무시하고 이러한 행 위를 한다. 그러나, 배포 규정은 이것을 허용하지 않는다) 상용 소프트웨어(commercial software) 상용 소프트웨어는 소프트웨어의 사용자들로부터 돈을 버는 것을 목적으로 기 업에 의해서 개발되고 있는 소프트웨어이다. 대부분의 상용 소프트웨어는 독 점 소프트웨어이며 많은 사람들은 이 두 가지를 같은 것으로 생각한다. 그 러나, 이것은 잘못이다. 독점 소프트웨어가 항상 상용 소프트웨어인 것은 아 니며 자유 소프트웨어도 상용 소프트웨어가 될 수 있다. 예를 들면, GNU Ada는 항상 GNU GPL의 규정에 따라 배포된다. 그리고 모든 복 제물은 자유 소프트웨어이다. 그러나, Ada의 개발자들은 사후 지원에 대한 판매 방식을 갖고 있다. Ada의 판매자들은 유치 가능한 고객들이 "우리는 상용 컴파일러가 더 안전하다고 생각한다."라고 말할 때 "GNU Ada는 상용 컴 파일러입니다. 자유 소프트웨어가 되었을 뿐이죠."라고 응수한다. GNU 프로젝트에서의 중점은 다른 곳에 있다. 그것은 GNU Ada가 자유 소프트 웨어라는 것이다. 상용 소프트웨어인가 아닌가는 그 다음 문제인 것이다. 그 러나, 상업 환경에서 야기된 부가적인 GNU Ada의 개발은 분명히 이로운 것이 다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Categories of Free and Non-Free Software Drafted version: Richard M. Stallman's 23 Dec 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple PlaceSuite 330, Boston, MA 02111, USA Korean Translator: 1998 Ryu Jaesang 류재상 kidaeryu@soback.kornet.nm.kr -------------------------------------------------------------------------------- GNU General Public License -------------------------------------------------------------------------------- This is an unofficial translation of the GNU General Public License into Korean. It was not published by the Free Software Foundation, and does not legally state the distribution terms for software that uses the GNU GPL--only the original English text of the GNU GPL does that. However, I hope that this translation will help Korean speakers understand the GNU GPL better. 이 문서는 자유 소프트웨어 재단(Free Software Foundation)의 GNU General Public License를 한국어로 번역한 것이다. 이 문서는 GNU General Public License가 내포하고 있는 호혜적인 자유와 공유의 정신을 보다 많은 사람들에게 알리기 위한 희망에서 작성되었지만 자유 소프트웨어 재단의 공식 문서로 취급될 수는 없다. 이는 원래의 문서가 의도하고 있는 내용들이 왜곡되지 않고 법률적으로 유효하기 위해서 선행되어야 할 양국의 현행 법률과 언어의 적합성 여부에 대한 전문가들의 검토 작업에 많은 비용이 필요하기 때문이다. 따라서, 자유 소프트웨어 재단은 오역이나 해석상의 난점으로 인해서 발생될 지 모를 분쟁의 가능성을 미연에 방지하고 문서가 담고 있는 내용과 취지를 보다 많은 사람들에게 홍보하려는 상반된 목적을 한국어 번역문을 공식적으로 승인하지 않음으로써 양립시킬 수 있을 것이다. 자유 소프트웨어 재단은 GNU General Public License를 실무에 적용할 경우, 오직 영문판 GNU General Public License에 의해서 만이 그 법률적 효력이 올바르게 발생될 수 있음을 권고하고 있다. 이 번역문은 법률적 검토와 문서간의 동일성 여부에 대한 검증을 거치지 않은 것이며 이로 인해서 야기될 수 있을 지도 모를 법률적인 문제에 대해서 어떠한 형태의 보증도 하지 않는다. Original Copy: GNU General Public License Korean Translator: 1998 Song Changhun 송창훈 chsong@cyber.co.kr -------------------------------------------------------------------------------- 목 차 GNU GENERAL PUBLIC LICENSE 전 문(前 文) 복제와 개작, 배포에 관한 조건과 규정 GPL을 실무에 적용하는 방법 -------------------------------------------------------------------------------- GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 무상으로 허용된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. 전 문 (前 文) 소프트웨어에 대한 대부분의 라이센스는 해당 소프트웨어에 대한 수정과 공유의 자유를 제한하려는 것을 그 목적으로 한다. 그러나, GNU General Public License는 자유 소프트웨어에 대한 수정과 공유의 자유를 호혜적으로 보장하기 위해서 성립되었다. 자유 소프트웨어 재단이 제공하는 대부분의 소프트웨어들은 GNU General Public License의 규정에 의해서 관리되고 있으며 별도의 관리 방법이 보다 효과적이라고 판단되는 라이브러리 서브루틴(library subroutine)의 경우, 독립된 문서인 GNU Library General Public License를 선택적으로 적용하고 있다. 자유 소프트웨어란 이를 사용하려는 모든 사람에 대해서 동일한 자유와 귄리가 함께 양도되는 소프트웨어를 의미하며 프로그램 저작자의 의지에 따라 어떠한 프로그램에도 이 규정들이 적용될 수 있다. 자유 소프트웨어를 언급할 때 사용되는 '자유'라는 단어의 의미는 금전적인 측면의 자유가 아닌 구속되지 않는다는 관점에서의 자유를 의미하며 GNU General Public License는 자유 소프트웨어를 이용한 복제와 개작, 배포와 수익 사업 등의 가능한 모든 형태의 자유를 실제적으로 보장한다. 여기에는 소스 코드의 전부 또는 일부를 원용해서 개선된 프로그램으로 변형시키거나 새로운 프로그램을 창작할 수 있는 자유가 포함되며 자신에게 양도된 이러한 자유와 권리들을 보다 명확하게 인식할 수 있도록 하기 위한 규정 또한 포함되어 있다. GNU General Public License는 이 문서에 소프트웨어 피양도자의 권리를 제한하는 특정 조항과 단서들을 별항으로 첨가시키지 못하게 함으로써 사용자들의 실질적인 자유와 권리를 보장하고 있다. 자유 소프트웨어의 개작과 배포에 관계하고 있는 사람들은 이러한 무조건적인 권리 양도 규정을 준수해야만 한다. 예를 들면, 특정 프로그램을 배포할 경우 양도자는 피양도자에게 자신이 양도받았던 모든 권리를 수익 여부에 관계없이 그대로 이전해야만 한다. 소스 코드에 대한 사용 권리 또한 여기에 포함되어야 하며 이와 같은 사항들을 명시함으로써 피양도자들에게 그들이 양도받은 권리를 알 수 있도록 해야 한다. 자유 소프트웨어 재단은 다음과 같은 두 가지 방법에 의해서 반복되는 양도에 따른 사용자 모두의 권리를 보호한다: (1) 저작권을 인정함으로써 프로그램 저작자들의 권리를 보호한다. (2) 저작권의 양도에 관한 실정법에 의해서 유효한 법률적 효력을 갖는 GNU General Public License를 통해서 소프트웨어의 복제와 개작, 배포 등에 대한 소프트웨어 피양도자의 권리를 실질적으로 보장한다. 자유 소프트웨어의 사용자들은 지속적인 양도 과정을 통해서 소프트웨어 자체에 수정과 변형에 의한 문제가 발생될 수 있으며 이는 최초의 저작자에 의한 소프트웨어가 갖는 문제가 아닐 수 있다는 개연성에 대해서 인식하고 있어야 한다. GNU General Public License에 자유 소프트웨어에 대한 어떠한 형태의 보증도 규정하지 않은 이유는 이러한 점들이 고려되었기 때문이며 이는 프로그램 원저작자와 자유 소프트웨어 재단의 자유로운 활동을 보장하는 현실적인 수단이기도 하다. 특허 제도는 자유 소프트웨어의 발전을 위협하는 요소일 수밖에 없다. 따라서, 자유 소프트웨어를 배포할 경우 개별적인 배포 과정에 특허를 취득한 저작물을 함께 포함시키지 않음으로써 이용 상의 자유가 제한되지 않도록 하는 것이 최선의 방법이다. GNU General Public License는 이러한 문제에 대처하기 위해서 특허가 취득된 저작물은 그 라이센스를 불특정 다수(이하, "공중"이라 한다)에게 공개적으로 허용하는 경우에 한해서 자유 소프트웨어와 함께 사용할 수 있도록 규정하고 있다. 복제(copying)와 개작(modification), 배포(distribution) 등에 관련된 구체적인 조건과 규정은 다음과 같다. 복제와 개작, 배포에 관한 조건과 규정 제 0 항. 본 라이센스는 GNU General Public License의 규정에 따라서 배포될 수 있다는 사항이 저작권자에 의해서 명시된 모든 컴퓨터 프로그램 저작물에 대해서 동일하게 적용된다. 컴퓨터 프로그램 저작물(이하, "프로그램"이라 한다)이란 특정 프로그램이나 이와 관련된 기타 저작물을 의미하고 "2차적 프로그램"이란 저작권법의 규정에 따라 프로그램의 전부 또는 상당 부분을 원용하거나 다른 프로그래밍 언어로의 번역을 포함할 수 있는 개작 과정을 통해서 창작된 새로운 프로그램과 이와 관련된 저작물을 의미한다(이후로 다른 프로그래밍 언어로의 번역은 별다른 제한 없이 개작의 범위에 포함되는 것으로 간주한다) "피양도자"란 GNU General Public License의 규정에 의해서 프로그램을 양도받은 사람을 의미한다. 본 라이센스는 프로그램에 대한 복제와 개작, 배포 행위에 대해서만 적용된다. 따라서, 프로그램을 실행시키는 행위는 제한되지 않으며 프로그램의 실행에 따른 결과물은 실행 자체에 의한 결과물의 생성 여부에 상관없이 결과물이 2차적 프로그램을 구성했을 때에 한해서 본 라이센스의 규정을 적용할 수 있다. 2차적 프로그램의 구성 여부는 2차적 프로그램 안에서의 프로그램의 역할을 토대로 판단한다. 제 1 항.피양도자는 프로그램에 대한 보증을 제공하지 않는다는 사실과 저작권을 함께 명시하는 한, 양도받은 소스 코드의 전부 또는 일부를 어떠한 정보 매체를 통해서도 복제해서 배포할 수 있다. 피양도자가 프로그램의 소스 코드를 재배포할 때는 프로그램에 대한 보증이 결여되어 있다는 사실과 본 라이센스에 대해서 언급한 사항들을 양도받은 그대로 유지시켜야 하며 GNU General Public License 원문을 함께 제공해야 한다. 복제물을 배포할 경우, 복제물을 제작하기 위해서 소요된 경비를 충당하기 위해서 배포본을 유료로 판매할 수 있으며 유료 판매에 따른 배포본의 환불을 보장하는 별도의 보증을 설정할 수 있다. 제 2 항. 피양도자는 자신이 양도받은 프로그램의 전부 또는 일부를 개작할 수 있으며 이를 통해서 2차적 프로그램을 창작할 수 있다. 개작된 프로그램이나 창작된 2차적 프로그램의 소스 코드는 제 1 항의 규정에 의해서 다음의 사항들을 만족시키는 조건에 한해서 복제해서 배포될 수 있다. a) 개작된 파일은 파일이 개작된 사실과 개작된 날짜가 명시적으로 확인될 수 있도록 작성되어야 한다. b) 배포하거나 출판하려는 저작물의 전부 또는 일부가 양도받은 프로그램으 로부터 파생된 것이라면 개작된 프로그램에 대한 배포본이나 출판물 전 체에 대한 사용 권리를 공중에게 무상으로 허용해야 한다. c) 개작된 프로그램의 일반적인 실행 형태가 명령어 입력 방식에 의한 대화 형 구조 일 경우, 개작된 프로그램은 이러한 대화형 구조로 평이하게 실 행되었을 때 저작권에 대한 사항과 프로그램에 대한 보증이 결여되어 있 다는 사실이 개작된 프로그램을 본 라이센스의 규정에 의해서 다시 개작 해서 배포할 수 있다는 사항과 GNU General Public License를 열람할 수 있는 방법과 함께 실행 직후에 지면 또는 화면을 통해서 출력될 수 있도 록 작성되어야 한다(예외 규정: 양도받은 프로그램이 대화형 구조를 갖 추고 있다 하더라도 통상적인 실행 환경에서 전술한 사항들이 출력되지 않는 형태였을 경우, 이를 개작한 프로그램 역시 관련 사항들을 출력시 키지 않아도 된다) 본 조항들은 개작된 부분이 포함된 2차적 프로그램 전체에 적용된다. 만약, 어떠한 저작물이 2차적 프로그램에 포함되어 있는 부분과 동일한 것이라 하더라도 그것이 양도받은 프로그램으로부터 파생된 것이 아니라 별도의 독립 저작물로 인정될 만한 상당한 이유가 있을 경우, 이 저작물의 개별적인 배포 과정에는 본 라이센스와 규정들이 적용되지 않는다. 그러나, 이러한 저작물이 2차적 프로그램에 포함되어 함께 배포된다면 개별적인 저작권과 배포 기준에 상관없이 배포본의 전체 저작물 모두가 본 라이센스에 의해서 관리되어야 하며 전체 저작물의 일부 또는 전부에 대한 사용상의 모든 권리가 공중에게 무상으로 양도되어야 한다. 이러한 규정은 개별적인 저작물에 대한 저작권자의 권리를 말소시키려는 것이 아니라 2 차적 프로그램으로부터 반복적으로 파생되거나 이러한 프로그램들을 모아 놓은 배포본에 대해서 본 라이센스의 규정들을 동일하게 적용하기 위한 것이다. 프로그램(또는 2차적 프로그램)들을 단순히 저장하거나 배포할 목적으로 함께 구성해 놓은 경우는 이들이 파생적 저작물을 생성하지 않는 한 본 라이센스에 의해서 관리된다. 제 3 항. 피양도자는 다음의 조항 중 하나를 만족시키는 조건에 한해서 제 1 항과 제 2 항의 규정에 따라 프로그램(또는 제 2 항의 규정에 의한 2 차적 프로그램)을 목적 코드나 실행 형태로 복제해서 배포할 수 있다. a) 목적 코드나 실행 형태에 해당하는 소스 코드의 전부를 제 1 항과 제 2 항의 규정에 따라서 컴퓨터가 입력받거나 번역할 수 있는 형태로 소프트 웨어의 배포를 위해서 일반적으로 사용되는 정보 매체를 통해서 함께 제 공해야 한다. b) 목적 코드나 실행 형태에 해당하는 소스 코드의 전부를 최소한 3년 이상 유지될 수 있는 인쇄물의 형태로 제 1 항과 제 2 항의 규정에 따라서 소프트웨어의 배포를 위해서 일반적으로 사용되는 정보 매체를 통해서 제작 실비에 준하는 비용만을 부과해서 공중에게 양도될 수 있도록 함께 제공해야 한다. c) 목적 코드나 실행 형태에 해당하는 소스 코드의 전부를 취득할 수 있는 방법에 대한 정보를 함께 제공해야 한다(이 항목은 비영리적인 배포와 항목 b)에 의해서 목적 코드나 실행 형태의 배포본을 제공할 때에 한해 서 적용될 수 있다) 저작물에 대한 소스 코드란 해당 저작물을 개작하기 위해서 일반적으로 선호되는 표현 형식을 의미하고 실행물에 대한 소스 코드란 올바르게 실행되기 위해서 필요한 모듈과 인터페이스 정의 파일, 컴파일과 설치를 위해서 필요한 스크립트 등을 모두 포함한다. 그러나, 컴파일러나 커널과 같은 운영체제의 주요 부분들에 대한 소스 코드나 바이너리 형태는 프로그램이 이러한 부분들과 직접 관계되지 않는 한 함께 제공하지 않아도 무관하다. 목적 코드나 실행 형태를 특정 장소로부터 복제할 수 있도록 허용하는 방식으로 배포할 경우, 동일한 장소로부터 소스 코드를 복제할 수 있도록 허용하는 것은 피양도자에게 소스 코드를 목적 코드나 실행 형태와 함께 복제해 갈 것을 규정하지 않았다 하더라도 소스 코드를 함께 배포하는 것으로 간주한다. 제 4 항. 본 라이센스에 의해서 명시적으로 프로그램을 양도받지 않았다면 양도받은 프로그램에 대한 복제와 개작, 별도의 라이센스 설정과 배포 행위 둥을 할 수 없다. 이와 관련된 어떠한 행위도 법률적으로 무효이며 본 라이센스에서 규정하고 있는 사용상의 모든 권리는 자동적으로 소멸된다. 단, 본 라이센스의 규정에 의하지 않고 양도받은 프로그램이라 하더라도 이를 명시적인 라이센스 양도 규정에 따라 다시 배포했을 경우, 프로그램을 다시 양도받은 제 3의 피양도자는 본 라이센스를 준수하는 조건하에서 사용상의 권리를 유지할 수 있다. 제 5 항. 피양도자는 프로그램의 양도에 관한 본 라이센스에 서명하지 않음으로써 본 라이센스의 규정들을 받아들이지 않을 수 있다. 이 경우, 피양도자에게는 프로그램에 대한 단순한 사용만이 허용되며 프로그램과 2차적 프로그램에 대한 개작과 배포 행위는 허용되지 않는다. 이는 피양도자가 라이센스에 서명하지 않음으로써 발생된 법률적 금지 사항이다. 따라서, 프로그램(또는 2차적 프로그램)을 개작하거나 배포하는 행위는 복제와 개작, 배포에 관한 본 라이센스의 규정과 조건들을 모두 받아들이겠다는 묵시적인 동의로 간주한다. 제 6 항. 피양도자에 의해서 프로그램(또는 2차적 프로그램)이 반복적으로 배포될 경우, 각 단계에서의 피양도자는 본 라이센스의 규정에 의한 프로그램의 복제와 개작, 배포에 대한 권한을 최초의 프로그램 양도자로부터 양도받은 것으로 자동적으로 간주된다. 프로그램(또는 2차적 프로그램)을 양도할 때는 피양도자의 권리를 제한할 수 있는 어떠한 사항도 별항으로 첨가할 수 없으며 그 누구도 본 라이센스의 규정들을 준수하도록 강제할 수 없다. 제 7 항. 법원의 판결이나 특허권 침해에 대한 주장 또는 특허 문제에 국한되지 않는 그 밖의 다른 이유들로 인해서 본 라이센스의 규정에 배치되는 사안이 발생한다 하더라도 본 라이센스에 배치되는 규정들이 본 라이센스에 대한 실행 상의 우선권을 갖게 되지는 않는다. 따라서, 법원의 명령이나 합의 등에 의해서 본 라이센스에 위배되는 사항들이 부과된다 하더라도 본 라이센스의 규정들을 함께 충족시키면서 해당 프로그램을 배포할 수 없다면 이 프로그램의 배포는 금지된다. 예를 들면, 특정 특허 관련 라이센스가 직접 또는 간접적인 양도 방법에 의해서 프로그램을 무상으로 배포하는 것을 허용하지 않는다면 이 프로그램은 본 라이센스의 규정에 의해서 관리되는 프로그램들과 함께 배포될 수 없다. 특정 상황에서 본 조항의 일부분이 적용될 수 없는 경우에는 해당 부분을 제외한 나머지 부분들을 적용시키며 본 조항의 전부를 적용시키기 위해서는 다른 상황과 조건들이 필요하다. 본 조항의 목적은 특허나 재산권 침해 등의 행위를 조장하거나 해당 권리를 인정하지 않으려는 것이 아니라 GNU General Public License의 실제적인 적용을 통해서 자유 소프트웨어의 배포 체계를 통합적으로 보호하기 위한 것이다. 많은 사람들이 배포 체계에 대한 신뢰있는 지원을 계속해 줌으로써 소프트웨어의 다양한 분야에 많은 공헌을 해 주었다. 소프트웨어를 어떠한 배포 체계를 통해서 배포할 것인가를 결정하는 것은 전적으로 저작자와 기증가들의 의지에 달려있지 일반 사용자들이 강요할 수 있는 문제는 아닌 것이다. 본 조항은 계속되는 본 라이센스의 내용들을 통해서 중요하게 취급되고 있는 점들을 보다 명확하게 설명하는 데 도움이 될 것이다. 제 8 항. 특허권과 저작권의 법적 처리 방식에 의해서 특정 국가에서 프로그램의 배포와 사용이 함께 또는 개별적으로 금지될 경우, 본 라이센스에 의해서 프로그램을 공개한 원저작자는 문제가 발생되지 않는 국가에 한해서 이를 배포한다는 배포상의 지역적 제한 조건을 설정할 수 있으며 이러한 사항은 본 라이센스의 일부로 간주된다. 제 9 항. 자유 소프트웨어 재단은 GNU General Public License를 개정하거나 갱신할 수 있다. 개정되거나 변동되는 사항은 새로운 문제와 관심에 따라서 세부적으로 조정되겠지만 그 근본 정신은 바뀌지 않을 것이다. GNU General Public License의 모든 버전은 다른 버전 번호로 구별될 것이다. 양도받은 프로그램이 특정 버전의 라이센스를 명시하고 있다면 해당 버전 또는 그 이후의 라이센스가 적용되며 버전을 명시하지 않은 경우는 어떠한 버전의 라이센스를 적용해도 무방하다. 제 10 항. 프로그램의 일부를 본 라이센스와 배포 기준이 다른 자유 프로그램과 함께 배포할 경우, 해당 프로그램의 저작자로부터 서면을 통한 승인을 받아야 한다. 자유 소프트웨어 재단이 저작권을 갖고 있는 소프트웨어를 사용하기 위해서는 자유 소프트웨어 재단의 승인을 얻어야 한다. 자유 소프트웨어 재단은 승인 요건에 대해서 예외 규정을 둘 수 있다. 자유 소프트웨어 재단은 자유 소프트웨어의 2차적 저작물들을 모두 자유로운 상태로 유지시키려는 목적과 소프트웨어의 일반적인 공유와 재활용을 증진시키려는 기준에 근거해서 승인 여부를 결정할 것이다. 보증의 결여 제 11 항. 본 라이센스에 의한 프로그램은 무상으로 양도되므로 관련 법이 허용하는 한도 내에서 어떠한 형태의 보증도 제공하지 않는다. 단, 프로그램의 저작권자와 제 3의 배포자에 의해서 공동 또는 개별적으로 특정 목적에 대한 프로그램의 적합성 여부를 검증하기 위한 경우나 상업적 판매에 따른 별도의 보증이 제공된다는 사항이 서면으로 명시되어 있는 경우는 예외로 한다. 이 경우도 해당 프로그램 자체가 갖고 있는 근원적인 보증의 결여를 제한할 수는 없다. 프로그램과 프로그램의 실행에 따라 발생할 수 있는 위험은 모두 피양도자에게 인수되며 이에 따른 보수 및 복구를 위한 제반 경비 또한 모두 피양도자가 부담한다. 제 12 항. 저작권자나 제 3의 배포자가 프로그램의 손상 가능성을 사전에 알고 있었다 하더라도 발생된 손실이 관련 법규에 의해서 보호되고 있거나 저작권자나 프로그램 자체에 대한 보증을 제공하지 않는다는 전제로 프로그램과 개작된 프로그램을 함께 또는 개별적으로 공급한 배포자가 서면으로 별도의 보증을 설정한 경우가 아니라면 프로그램의 사용이나 사용상의 미숙으로 인해서 발생된 손실은 모두 피양도자의 책임이다. 발생된 손실의 일반성이나 특수성 뿐만 아니라 원인의 우발성 및 필연성도 고려되지 않는다. 복제와 개작, 배포에 관한 조건과 규정의 끝. 규정들을 실무에 적용하는 방법 개발한 프로그램이 보다 많은 사람들에게 유용하게 사용되기를 원한다면 그 프로그램이 본 라이센스의 규정에 따라서 자유롭게 수정되고 배포될 수 있도록 자유 소프트웨어로 만드는 것이 최선의 방법이다. 다음과 같은 사항들을 프로그램에 첨가함으로써 해당 프로그램을 자유 소프트웨어로 만들 수 있다. 프로그램에 대한 보증을 제공하지 않는다는 사실을 가장 효과적으로 전달할 수 있는 방법은 소스 코드가 포함되어 있는 모든 파일의 시작 부분에 이러한 사항들을 명시하는 것이다. 각각의 파일들은 최소한 저작권과 GPL을 취득할 수 있는 방법을 명시해야만 한다. 프로그램의 이름과 용도에 대한 설명을 위해서 한 줄을 사용한다. Copyright (C) 19yy 프로그램 저작자의 이름 이 프로그램은 자유 소프트웨어이다. 소프트웨어의 피양도자는 자유 소프트웨어 재단의 GNU General Public License의 규정에 의해서 이 프로그램을 개작된 2차적 프로그램과 함께 또는 개별적으로 배포할 수 있다. 이 프로그램은 보다 유용하게 사용될 수 있으라는 희망에서 배포되고 있지만 제품에 대한 어떠한 형태의 보증도 하지 않는다. 보다 자세한 사항에 대해서는 GNU General Public License를 참고하기 바란다. GNU General Public License는 이 프로그램과 함께 제공된다. 만약, 이 문서가 누락되어 있다면 자유 소프트웨어 재단에 문의하기 바란다(자유 소프트웨어 재단: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA) 또한, 프로그램 저작자와 서면 또는 전자 메일을 통해서 연락할 수 있는 정보를 기재해야 한다. 만약, 이 프로그램이 명령어 입력 방식에 의한 대화형 구조를 택하고 있다면 프로그램이 대화형 방식으로 실행되는 초기 상태에서 다음과 같은 주의 사항을 출력시켜야 한다. Gnomovision version 69, Copyright (C) 19yy프로그램 저작자의 이름 Gnomovision은 제품에 대한 어떠한 형태의 보증도 제공되지 않는다. 보다 자세한 사항은 'show w' 명령어를 이용해서 관련된 사항을 출력해 보기 바란다. 본 프로그램은 자유 소프트웨어이며 특정 규정들을 만족시키는 조건하에서 재배포될 수 있다. 배포에 대한 해당 규정은 'show c' 명령어를 통해서 참조할 수 있다. 'show w'와 'show c'는 General Public License의 해당 부분을 참조하기 위한 가상의 명령어이다. 따라서, 이 명령어들은 마우스를 이용하거나 메뉴 방식을 구성하는 등의 프로그램에 적합한 여러 가지 형태으로 변형될 수 있을 것이다. 만약, 프로그램 저작자가 학교나 기업과 같은 단체나 기관에 고용되어 있다면 프로그램의 자유로운 배포를 위해서 고용주나 해당 기관장으로 부터 프로그램에 대한 저작권을 포기한다는 동의를 얻어야 한다. 예를 들면, 다음과 같은 형식이 될 수 있다. 본사는 James Hacker에 의해서 작성된 'Gnomovision' 프로그램에 관계된 모든 저작권을 포기한다. 1989년 4월 1일 Yoyodye, Inc., 부사장: Ty Coon 서명: Ty Coon의 서명 본 라이센스는 자유 소프트웨어로 설정된 프로그램을 독점 소프트웨어와 함께 사용하는 것을 허용하지 않는다. 만약, 작성된 프로그램이 라이브러리 서브루틴과 같은 프로그램일 경우에는 이를 독점 소프트웨어 형태의 응용 프로그램과 함께 사용함으로써 보다 효과적으로 활용될 수 있다고 생각할 수도 있을 것이다. 이러한 경우는 본 라이센스 대신에 GNU Library General Public License를 사용함으로써 소기의 목적을 충족시킬 수 있을 것이다. -------------------------------------------------------------------------------- 2. GNU 프로젝트의 역사 Overview of the GNU Project GNU 프로젝트는 "GNU"(Gnu is Not Unix - 'GNU는 유닉스가 아니다'라는 뜻의 재귀적 약어)라고 일컬어지는 유닉스 호환 자유 소프트웨어들을 개발해왔다. (GNU 프로젝트에 대한 최초의 문서로는 본 프로젝트의 창립자인 리차드 스톨만(Richard M. Stallman)의 'GNU 선언문'이 있다) 우리가 사용하는 '자유'의 의미는 금전적인 측면의 자유가 아닌 구속되지 않는다는 관점에서의 자유를 의미한다. 따라서, GNU 소프트웨어를 사용하기 위해서 지불된 비용의 유무에 상관없이 일단 소프트웨어를 입수한 뒤에는 다음과 같은 세가지 자유가 실질적으로 보장된다. 첫째, 프로그램을 복제(copying)하고 친구나 동료와 함께 이를 공유할 수 있는 자유 둘째, 원프로그램(source code)를 원용해서 이를 개작(modification)할 수 있는 자유 셋째, 개작된 프로그램을 배포(distribution)할 수 있는 자유 이러한 자유의 보장은 결국 공동체(community) 전체의 발전에 기여하게 될 것이다. (GNU 소프트웨어를 배포할 경우, 배포본 제작에 소요된 경비를 충당하기 위해서 적절한 가격에 이를 판매할 수 있다) GNU 프로젝트는 초기의 컴퓨터 공동체(computing community) 안에 충만해 있던 호의적인 상호 협력의 정신을 재건하기 위한 구체적 실현 방법으로 1983년에 기획되었으며 이는 독점(proprietary) 소프트웨어의 소유자들이 만든 장벽들을 제거함으로써 상호 협력의 풍토를 다시 한 번 부활시키는 것을 그 목적으로 한다. 리차드 스톨만이 MIT(Massachusetts Institute of Technology)에서 직업적인 연구활동을 시작했던 1971년에 그는 자유 소프트웨어만을 사용하는 연구 그룹에서 일하게 되었다. 그 시절은 상업적 컴퓨터 회사 조차도 자유 소프트웨어를 배포하던 때였으므로 프로그래머들은 아무런 제약없이 서로 협력할 수 있었다. 1980년대에 이르러 거의 모든 소프트웨어들은 소유와 독점에 관한 법률에 의해서 제한되었으며 소유권자들은 소프트웨어의 자유로운 이용을 통한 사용자들의 상호 협력을 그들의 권리를 내세워서 금지시켰다. 이것이 GNU 프로젝트가 시작된 이유였다. 모든 컴퓨터 사용자들은 운영체제가 필요하다. 만약, 자유롭게 사용할 수 있는 운영체제가 없다면 컴퓨터를 사용하고자 하는 모든 사람들은 독점적인 상업용 운영체제를 이용할 수밖에 없다. 따라서, 자유 소프트웨어에 대한 첫번째 과제는 자유 운영체제를 만드는 것이다. 운영체제는 단순히 커널(kernel)만을 의미하는 것이 아니다. 운영체제에는 컴파일러(compiler)와 문서 편집기(editor), 문서 형식기(text formatter), 메일 소프트웨어(mail software)와 같은 다양한 종류의 소프트웨어들이 통합되어 있어야 한다. 따라서, 완성된 운영체제를 만든다는 것은 무척이나 방대한 작업이며 많은 세월이 필요한 일이다. 우리가 구상했던 운영체제를 유닉스와 호환되도록 결정했던 이유는 유닉스의 설계방식에 대한 전반적인 우수성과 이식성이 이미 충분히 증명되었기 때문이고 호환성을 통해서 많은 유닉스 사용자들이 보다 쉽게 GNU 환경으로 적응할 수 있게 하기 위해서였다. 자유 운영체제에 대한 우리의 첫 번째 계획은 1990년대에 와서 실현되었다. 커널을 제외한 주요 부분들을 새롭게 작성하고 취합하던 과정에서 우리는 리누스 토발즈(Linus B. Tovalds)에 의해서 리눅스가 개발되고 있다는 사실을 알게 되었고 리눅스는 곧 GNU와 합류하게 되었다. 자유 소프트웨어인 리눅스 커널과의 결합으로 GNU 시스템은 독립된 운영체제로서의 완성된 모습을 갖출 수 있었고 슬렉웨어와 데비안, 레드햇과 같은 GNU 시스템에 기반한 많은 운영체제들이 이제는 수십만에 달하는 사용자를 갖게 되었다. 그러나, GNU 프로젝트가 단지 운영체제의 개발에만 국한되는 것은 아니다. 우리의 목표는 수요가 있는 모든 부문의 자유 소프트웨어를 제공하는 것이다. 응용 소프트웨어인 스프레드시트(spreadsheet)가 이미 활용되고 있으며 GNU 이멕스(emacs)를 몇 년 안에 WYSIWYG(What You See Is What You Get) 형태의 완벽한 탁상 출판 시스템으로 확장시킬 계획이다. 일반인들을 위한 소프트웨어 역시 마다하지 않을 것이다. GNU 시스템에 익숙하지 않은 초보자들을 위해서 그래픽 환경의 간편한 사용자 인터페이스 방식에 대한 개발이 이미 진행되고 있다. 현재 활용될 수 있는 몇 종류의 게임과 같이 삶의 활력소가 될 수 있을 다양한 종류의 소프트웨어 또한 준비되고 있으며 이는 우리가 갖고 있는 또하나의 목표이기도 하다. 그렇다면, 자유 소프트웨어는 어느 한계까지 발전할 수 있을까? 특허 제도와 같은 법률적 강제 장치가 자유 소프트웨어를 전면적으로 금지시키지 않는 한 그 가능성은 무한하다고 생각한다. 우리의 궁극적인 목표는 컴퓨터 사용자들이 희망하는 어떠한 형태의 작업도 완벽하게 실현시킬 수 있는 자유 소프트웨어를 제공하는 것이며 그것은 곧 소프트웨어에 있어서 독점이라는 해악을 영원히 사라지게 만들 것이다. ============================================================================== 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전제나 발췌도 허용되며 상업적 이용과 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. Original Copy: http://www.gnu.org/gnu/gnu-history.html Drafted version: Richard M. Stallman's 26 Dec 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple Place - Suite 330,Boston, MA 02111, USA Korean Translator: 1998 Song Changhun 송창훈 - Dept. of Computer Science, Sogang Univ., Sinsu Dong 1, Mapo Gu, Seoul, ROK 리눅스와 GNU 프로젝트 Linux and the GNU project 일반적으로 "리눅스"라고 알려져 있는 현재의 GNU 시스템은 몇 차례의 괄목할만한 변화를 통해서 성장했으며 많은 컴퓨터 사용자들에 의해서 일상처럼 사용되고 있음에도 불구하고 그 자체에 대한 명확한 인식이나 리눅스와 GNU 시스템과의 관계에 대해서 잘 알고 있는 사람은 많지 않은 것 같다. 우리가 사용하고 있는 리눅스 그 자체는 커널(kernel)을 의미한다. 커널이 운영체제의 핵심 부분이라는 것은 틀림없는 사실이지만 그것만으로 운영체제의 역할을 수행할 수 있는 것은 아니다. 현재 사용되고 있는 GNU 시스템은 리눅스에 기반한 운영체제이며 이는 리눅스를 커널로 채택한 일종의 변형된 종류의 GNU 시스템이라고 할 수 있다. 대부분의 사용자들은 운영체제 전체를 지칭하는 이름으로서의 리눅스와 커널만을 의미하는 명칭으로서의 리눅스를 혼동해서 사용함으로써 그 차이를 명확하게 구분하지 못하고 있으며 이러한 혼재된 명칭의 사용이 그 차이를 더욱 모호하게 만들고 있다고 할 수도 있을 것이다. 프로그래머들은 리눅스가 커널이라는 사실을 대체적으로 잘 알고 있다. 따라서, 리눅스가 운영체제 전체를 의미하는 이름으로도 사용되고 있다는 사실에 대해서 거기에는 그럴 만한 타당한 이유가 있을 것이라는 생각을 리눅스의 역사를 빗대어 추측하곤 한다. 이를테면, 리누스 토발즈(Linus B. Tovalds)가 리눅스를 완성한 후에 그의 친구들이 리눅스를 기반으로 한 운영체제를 완성하기 위해서 유닉스와 유사한 시스템을 갖추기에 충분한 자유 소프트웨어들을 우연찮게 발견했기 때문에 운영체제의 이름을 그 발단이 되는 리눅스의 이름으로 사용하지 않았겠는가 하는 식으로 말이다. 그러나, 그들이 완성체에 가까운 GNU 시스템을 발견한 것은 결코 우연이 아니었다. 이는 GNU 프로젝트가 완벽한 운영체제를 만들기 위해서 가능한 모든 종류의 자유 소프트웨어들을 1984년부터 규합해 왔던 결과였으며 GNU 선언문를 발표함으로써 시작한 우리의 과업을 그후 10년 이상동안 꾸준히 수행해 온 결과였기 때문이다. 자유 소프트웨어 프로젝트는 특정 작업을 수행하기 위한 프로그램을 개발할 목적으로 진행되는 것이 일반적인 관행이다. 예를 들면, 리누스 토발즈의 리눅스 프로젝트는 유닉스 형태의 커널을 개발하기 위한 것이었으며 도날드 쿤스(Donald Knuth)와 밥 쉬라이플러(Bob Scheifler)의 프로젝트는 각각 문서 형식기(text formatter)인 Tex와 X 윈도우를 개발하기 위한 것이었다. 따라서, 리눅스가 운영체제의 핵심 요소였기 때문에 그것을 운영체제 전체의 이름으로 사용했으리라는 추측처럼 특정 프로그램이 갖고 있는 비중에 따라서 그 이름으로 전체를 대표한다는 것은 무척이나 자연스러운 발상인 것이다. 만일, GNU 프로젝트가 특정 프로그램을 개발하기 위한 프로젝트였고 위와 같은 방식으로 운영체제의 이름을 명명하게 된다면 과연 어떤 결과가 되어야 하는 것일까? 리눅스 배포판 CD-ROM의 구성을 살펴보면 리눅스 커널이 3% 정도의 비중을 차지하는데 반해서 GNU 소프트웨어는 전체 소스 코드의 약 28%에 달하며 이는 단일 항목으로서는 가장 큰 비율이다. 또한, 여기에는 시스템 운영을 위해서 반드시 필요한 핵심 요소들이 포함되어 있다. 따라서, 운영체제를 구성하는 특정 프로그램의 비중에 따라서 그 이름을 짓는다면 가장 타당한 이름은 리눅스가 아닌 "GNU"가 되어야 할 것이다. 그러나, 이것은 가장 중요한 점을 간과하고 있기 때문에 질문에 대한 올바른 답변이라고 할 수 없다. 그것은 GNU 프로젝트가 특정 소프트웨어 패키지를 개발하기 위한 프로젝트가 아니라는 점이다. GNU 프로젝트는 C 컴파일러나 문서 편집기와 같은 특정 소프트웨어를 개발하기 위한 것이 아니며 오히려 이들이 GNU 프로젝트를 구성하기 위해서 개발된 것이다. GNU 프로젝트의 목표는 유닉스 형태의 완벽한 운영체제를 개발하기 위한 것이며 이는 우리가 많은 사람들의 도움을 통해서 지금까지 수행해 온 사업의 핵심이다. 많은 사람들이 운영체제의 주요 부분들을 작성함으로써 많은 기여를 했고 그 프로그램들은 모두 전체 시스템을 대표할 이름으로 사용될 만한 충분한 자격이 있다. 그러나 GNU 프로젝트는 단순히 유용한 프로그램들의 집합이 아닌 통합된 시스템으로서의 운영체제 전체를 의미하기 때문에 그 이름이 특정 프로그램으로부터 차용되어서는 안되는 것이다. 우리는 자유 운영체제를 구성하기 위해서 필요한 기본 요소들을 직접 작성하기도 했다. 핵심적이지만 그 개발이 지루한 작업일 수밖에 없는 어셈블러(assembler)와 디버거(debugger), C 라이브러리(library)들을 만들었는데 이러한 프로그램들은 운영체제를 완성하기 위해서 반드시 필요한 부분들이다. 1990년대 초까지 우리는 커널이 제외된 완성도 높은 운영체제를 만들 수 있었다. 마크(Mach-매킨토시의 Mac과 구별하기 위해서 마크라고 발음한다) 운영체제에서 작동하는 커널인 GNU Hurd는 개발 중에 있었다. 이때, 우리는 리눅스의 개발이 완료되었다는 사실을 알게 되었고 곧이어 자유 소프트웨어인 리눅스 커널이 GNU 시스템에 합류함으로써 마침내 완성된 형태의 운영체제를 만들 수 있게 되었다. 그러나, 이들을 결합시킨다는 것은 말처럼 간단한 작업이 아니었다. 설치와 함께 즉시 사용할 수 있는 배포본으로서의 시스템을 구축하는 것은 무척이나 방대한 작업이었기 때문이다. 완성된 전체 시스템을 구성하는 것 이 처음이었기 때문에 C 라이브러리를 리눅스 커널에 맞게 재작성해야 했으며 이전에 다룰 수 없었던 설치와 부팅시에 고려되어야 할 CPU의 번지 지정에 대한 기계어 차원의 문제들이 해결되어야 했다. 다양한 배포본의 구성을 위해서 노력했던 많은 사람들의 수고 덕분에 결국, 리눅스와 이에 맞게 수정된 GNU 시스템은 완성된 운영체제로서의 모습을 갖출 수 있게 되었다. 유닉스 형태의 자유 운영체제를 개발하기 위한 또 하나의 프로젝트로는 버클리 대학(University of California, Berkeley)의 BSD(Berkeley Software Distribution)가 있다. BSD의 개발자들은 GNU 프로젝트와 그 개발자들에게 많은 영향을 받았지만, 실제적인 작업에 있어서는 GNU 시스템과 중복되는 부분이 없다고 볼 수 있다. 물론, 두 시스템 모두 서로의 프로그램을 조금씩 차용 하고 있기는 하지만 전체적으로 볼 때 이들은 독립적으로 발전하고 있다고 할 수 있기 때문에 오늘날의 자유 운영체제는 크게 GNU 시스템과 BSD 시스템 두 개의 영역으로 구분할 수 있을 것이다. GNU 프로젝트는 최초에 계획했던 커널인 GNU Hurd의 개발에 중점을 두고 있지만 리눅스 커널에 기반한 GNU 시스템의 개발도 지원하고 있으며 여기에는 재정적인 지원 또한 포함되어 있다. GNU C 라이브러리에 맞게 리눅스를 재개발하는 작업을 통해서 이제 리눅스에 기반한 GNU 시스템에서도 GNU C 라이브러리를 리눅스에 맞게 수정할 필요 없이 그대로 사용할 수 있게 되었다. 우리는 또다른 리눅스 커널 기반의 GNU 시스템인 데비안(Debian) 배포판의 개발 초기 단계에서 이를 지원하기 위한 기금을 이안 멀독(Ian Murdock)에게 제공하기도 했다. 현재, 우리는 대부분의 작업에 리눅스 기반의 GNU 시스템을 이용하고 있으며 이 시스템의 사용을 많은 사람들 에게 권장하고 있다. 그러나, 리눅스를 커널과 운영체제의 이름으로 혼동해서 사용하는 지금의 경향에서 벗어나서 커널을 의미할 때는 리눅스라는 이름을, 전체 운영체제를 지칭할 때는 GNU라는 명칭을 사용해 줄 것을 간곡하게 당부하고 싶다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Linux and the GNU project Drafted version: Richard M. Stallman's 18 Jan 1998 updated Copyright (C) 1997 Richard M. Stallman Korean Translator: 1998 Song Changhun 송창훈 chsong@cyber.co.kr -------------------------------------------------------------------------------- 마이크로소프트는 거대한 악마인가? Is Microsoft the Great Satan? 많은 사람들은 마이크로 소프트가 소프트웨어 산업을 위협하는 괴물이라고 생각한다. 심지어 마이크로 소프트에 대한 불매 운동까지 벌어지고 있는 실정이다. 그러나, 이에 대한 자유 소프트웨어 공동체의 시각은 조금 다르다. 우리는 마이크로 소프트가 소프트웨어를 독점함으로써 소프트웨어 사용자들에게 해를 미치고 있다고 생각한다. 마이크로 소프트 뿐만 아니라 거의 모든 소프트웨어 회사들은 같은 짓을 하고 있다. 따라서, 다른 회사들의 이러한 행위가 마이크로 소프트의 영향에 비해 미미한 것이라 할지라도 그것이 소프트웨어를 독점하려는 의도가 없기 때문이라고 할 수는 없을 것이다. 모든 회사들이 소프트웨어의 독점에 대해서 동일한 의도를 갖고 있다는 사실이 마이크로 소프트의 책임을 경감시킬 수 있는 것은 아니다. 또한, 마이크로 소프트를 비판할 때는 상대적으로 영향이 적다고 해서 다른 회사들이 마이크로 소프트만큼 나쁘지는 않을 것이라는 생각은 배제해야 한다. 자유 소프트웨어 재단은 마이크로 소프트와 기타 다른 회사들로부터 연유한 어떠한 독점적 소프트웨어도 사용하지 않고 있다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Is Micorsoft the Great Satan? Drafted version: Richard M. Stallman's 16 Jan 1998 updated Copyright (C) 1997 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Ryu Jaesang 류재상 kidaeryu@soback.kornet.nm.kr 소프트웨어의 자유로운 작성 권리 보호를 위한 동참 요청 Help Protect the Rights to Write Both Non-Free and Free Software 자유 소프트웨어(free software)와 그 밖의 소프트웨어를 작성할 수 있는 자유로운 권리는 소프트웨어에 대한 특허와 인터페이스의 전체 화면 구성에 대한 저작권 설정으로 인해서 위협받고 있다. 자유 소프트웨어 재단(Free Software Foundation)은 이러한 위협에 대해서 여러 가지 방법으로 대항해 왔으며 여기에는 '자유 프로그래밍 연맹 (League for Programming Freedom)'에 동참하는 것과 이 단체를 지원하는 방법이 포함되어 있다. 이 연맹은 교수와 학생, 기업인, 프로그래머, 일반 사용자가 함께 참여할 수 있을 뿐만 아니라 심지어 프로그램 작성에 있어서의 자유를 다시 한 번 부활시키는데 기여하고자 하는 상업 소프트웨어 회사조차도 포함될 수 있는 폭넓은 대중 조직이다. 이 연맹의 목적은 개별적인 프로그램에 대해서 저작권을 인정하고 있는 미국 의회의 법률 제도 자체를 반대하는 것이 아니라, 특정 이익에 따라서 판결된 최근의 변화들을 원상대로 회복시키는데 있다. 자유 소프트웨어 재단은 이러한 위협에 대항하기 위한 우리의 노력에 여러분이 함께 동참해 줄 것을 요청한다. 자유 프로그래밍 연맹은 자유 소프트웨어 재단이나 자유 소프트웨어 재단이 발행하고 있는 출판물에 관여하고 있지 않다. 그러나, 자유 소프트웨어 재단이 이 연맹을 지원하는 이유는 마이크로 소프트 보다 영세한 소프트웨어 개발 업체와 마찬가지로 특허와 인터페이스에 관련된 저작권으로 말미암아 우리의 활동이 위협받고 있기 때문이다. 당신 또한 마찬가지다! 당신이나 당신의 고용주가 고소 당할 때까지 문제를 그대로 방치하는 것이 가장 편한 방법일지는 모르겠지만, 그러한 사태가 발생되기 전에 대처하는 것이 현명한 방법일 것이다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Help Protect the Rights to Write Both Non-Free and Free Software Drafted version: Leonard Tower's 4 Aug 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple Place Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Ji Younju 지연주 jiyounju@nownuri.net 자유 소프트웨어는 더 신뢰할 수있다! Free Software is More Reliable! 독점 소프트웨어의 변론자들은 '자유 소프트웨어는 좋은 꿈이다. 그러나 우리 모두는 단지 독점적인 시스템만이 신뢰할 만한 제품을 생산할 수 있다는 사실을 안다. 해커들의 무리는 이것을 할 수 없다'고 말하기를 좋아한다. 그러나 경험적인 증거는 이와 일치하지 않는다. 아래에 묘사된 것처럼, 과학적인 실험은 자유 소프트웨어가 유사한 독점 소프트웨어보다 더 신뢰할 수 있음을 보여 준다. -------------------------------------------------------------------------------- 목 차 GNU 유틸리티는 보다 안정적이다! 암 진료소가 자유 소프트웨어에 의존한다! -------------------------------------------------------------------------------- GNU 유틸리티는 보다 안정적이다! Barton P. Miller와 그의 동료들은 1990년과 1995년에 유닉스 유틸리티의 안정성을 시험하였다. 각각, GNU의 유틸리티들은 현저하게 앞서는 것으로 나타났다. 그들은 GNU 뿐만 아니라 7 가지 상업용 유닉스 시스템을 시험하였다. 그것들에게 무작위의 입력 문자열을 맡김으로써 그들은 "기본 유틸리티 프로그램의 40%(최악의 경우) 이상을 파괴 또는 정체"시켰다. 이 연구자들은 상용 유닉스 시스템이 15%부터 43%범위의 실패율을 가졌다는 것을 발견하였다. 반대로 GNU의 실패율은 단지 7%에 불과 하였다. 또한 Miller는 "우리가 1990년과 1995년에 비교했던 3개의 상용 시스템은 현저하게 안정성에서 향상되었다. 그러나 여전히 상당한 실패율(GNU/Linux의 기본적인 유틸리티들은 여전히 현저하게 상용 시스템보다 월등하다)"을 갖고 있다고 말했다. 보다 자세한 사항은 그들의 문서를 참고하기 바란다. Fuzz Revisited: A Re-examination of the Reliability of Unix Utilities and Services 저자: Barton P. Miller[bart@cs.wisc.edu], David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, Jeff Steidl 암 진료소가 자유 소프트웨어에 의존한다! North Fakota의 Fargo(최근에 개봉된 영화와 홍수의 발생지)에 있는 Rogre Maris 암 진료소는 정확한 안정성이 필수적이기 때문에 리눅스 기반의 GNU 시스템을 사용한다. GNU/Linux의 네트워크 장비들은 안내 시스템을 실행하고, 약물 치료 요법을 배열하고, 그리고 다른 많은 기능들을 수행한다. 이 네트워크는 짧은 교육으로도 진료소의 운영진들이 유용하게 사용할 수 있다. G.W. Wettstein 박사는 다음과 같이 말한다[greg@wind.rmcc.com]: "리눅스 없이는 우리의 암 환자들에 대한 적절한 치료는 오늘날과 같지 못했을 것이다.... 우리가 자유 소프트웨어의 경로로부터 배치할 수 있었던 도구들은 우리가 상업적 방법에는 존재하지 않던 혁신적인 애플리케이션들을 작성하고 개발할 수 있도록 만들어 주었다." -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Free Software is More Reliable! Drafted version: Leonard Tower's 4 Aug 1997 updated Copyright (C) 1997 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Ryu Jaesang 류재상 kidaeryu@soback.kornet.nm.kr 읽을 권리 The Right to Read by Richard Stallman -------------------------------------------------------------------------------- 목 차 티코로 가는 길 저자의 말 참고 서적 -------------------------------------------------------------------------------- 이 글은Communications of the ACM(Volume 40, Number 2)지의 1997년 2월호에 게제되었던것이다. 다음은 루나리언 혁명(Lunarian Revolution)의 선조들에 대한 기사집인 "티코로 가는 길(The Road to Tycho)" 에서 발췌한 것이다. 이 책은 2096년에 루나시티(Lunar City)에서 간행되었다 티코로 가는 길 댄 할버트(Dan Hallbert)에게 있어서 티코(달의 세 번째 상한에 있는 분화구, 혁명의 발단지)로 가는 길은 리사 렌츠(Lissa Lenz)가 그의 컴퓨터를 빌려 달라고 요청했던 대학 시절에 이미 시작되었다. 그녀의 컴퓨터는 파손되었기 때문에 그녀가 다른 사람의 것을 빌리지 않는다면 중간 프로젝트를 완성할 수 없는 상황이었다. 하지만, 그녀가 도움을 요청할 만한 사람은 댄 이외에 아무도 없었다. 이러한 상황은 댄을 딜레마에 빠지게 했다. 그녀를 도와주어야 하지만 컴퓨터를 빌려준다면 그녀는 그의 책들을 읽게 될 것이다. 다른 사람에게 자신의 책을 열람할 수 있게 하는 행위는 수년간의 징역에 처해진다는 사실은 별도로 한다고 해도 그녀가 자신의 책들을 열람할 수 있으리라는 생각이 그에게는 충격으로 다가왔다. 어느 누구나처럼 그도 초등 학교 때부터 책을 공유하는 것은 비열하고 나쁘다는 것을 배워 왔다. 저작권 침해처럼 말이다. 소프트웨어 보호국(SPA-Software Protection Authority)이 이러한 행위를 한 사람을 검거하지 못할 가능성은 거의 없었다. 댄은 소프트웨어 수업 시간을 통해서 각각의 책에는 저작권 감시 장치가 연결되어 있어서 언제 어디서 누구에게 읽혀졌는지에 대한 사항들이 중앙 열람 허가 시스템에 기록되게 되어 있다는 사실을 알고 있었다(소프트웨어 관리국은 이 기록을 이용해서 열람 사항을 위반한 사람들을 검거하기도 하지만 개개인의 관심 사항에 대한 정보를 소매 상인들에게 판매하기도 한다) 만약, 그가 자신의 컴퓨터를 리사에게 빌려준다면, 다음 접속시에 중앙 열람 허가 시스템은 그 사실을 알아낼 것이다. 컴퓨터의 소유자인 그는 범죄 행위를 근절하기 위해서 감당할 수 없는 벌을 받게 될 것이다. 물론, 리사의 의도는 그의 책들을 읽기 위한 것이 아니라 그녀의 중간 프로젝트를 작성하기 위한 것이다. 그러나 댄은 그녀가 중산층의 자녀이기 때문에 자료에 대한 열람료는 물론이고 수업료조차도 감당하기 힘들다는 사실을 잘 알고 있었다. 그의 책들을 몰래 열람하는 것이 그녀가 졸업할 수 있는 유일한 길일지도 몰랐다. 그는 이런 상황을 잘 알고 있었다. 그는 자신이 이용하기 위한 연구 자료들을 모두 열람료를 지불하고 빌려 와야 했다(열람료의 10%는 자료를 작성한 연구자에게 돌아간다. 댄은 학계에 남아 있을 계획이었기 때문에 언젠가는 연구 논문을 작성할 생각을 가지고 있었다. 만약, 이 자료들이 많은 사람들로부터 열람될 수 있다면 지금까지 소요된 경비를 모두 회수할 수 있을 것이다) 나중에 댄은 누구나 도서관에 가서 무료로 정기 간행물의 기사나 심지어 책을 읽을 수 있었던 때가 있었다는 사실을 알게 되었다. 정부 도서관의 허가 없이도 수천 장의 논문을 읽은 독립적인 학자들이 있었다. 그러나 1990년대부터 상업적 간행물과 비영리 간행물의 발행자들은 자료의 열람에 대한 요금을 징수하기 시작했고 2047년에 이르러서는 학술 논문에 대한 자유 열람을 허용하는 도서관은 거의 사라지게 되었다. 물론, 소프트웨어 보호국와 중앙 열람 허가 시스템을 속이는 방법이 있긴 했지만 모두 불법이었다. 댄은 컴퓨터를 이용해서 책을 읽을 때 열람 사항에 대한 감시 코드를 건너뛰게 할 수 있는 불법 디버깅 툴(debugging tool)을 가지고 있던 프랭크 마투치(Frank Martucci)라는 친구를 알고 있었다. 그러나 그는 너무 많은 친구들에게 그 사실을 말했기 때문에 보상금을 받기 위해서 그를 소프트웨어 보호국에 신고한 사람이 생겨났다(열람료로 인해서 많은 빚을 지게 된 학생들은 배신의 유혹에 쉽게 빠져들었다) 2047년에 프랭크는 열람 위반이 아닌 불법 디버깅 툴 소지 위반으로 수감되었다. 댄은 누구나 디버깅 툴을 가질 수 있었던 때가 있었다는 사실을 후에 알게 되었다. 심지어 CD나 네트워크를 통해서 자유롭게 다운로드 받을 수 있는 디버깅 툴도 있었다. 일반 사용자들이 이 툴을 이용해서 저작권 감시 장치에 구애받지 않고 책을 열람하기 시작했을 때, 한 판사는 이러한 행위가 실행령에 의해서 금지되는 범죄 행위라고 판결했다. 그것은 곧 디버깅 툴 자체가 불법이라는 것을 의미했고 디버거의 개발자들은 감옥으로 보내졌다. 프로그래머들은 여전히 디버깅 툴이 필요했지만, 2047년의 디버거 제조업체들은 오직 한정된 수량의 디버거만을 생산할 수 있었으며 공식적으로 허가된 관인 프로그래머들에게만 이를 공급할 수 있었다. 댄이 소프트웨어 수업 시간에 사용하는 디버거는 오직 수업 시간에 실습용으로만 사용될 수 있게끔 특별한 보안 장치에 의해서 관리되고 있었다. 저작권 감시 장치를 속일 수 있는 또 하나의 방법은 수정된 시스템 커널(kernel)을 설치하는 것이었다. 댄은 세기가 바뀌어 가던 무렵에 존재했던 심지어 전체 시스템 자체가 자유롭게 사용될 수 있었던 운영체제의 커널에 대해서 알아낼 수 있었다. 그러나, 그것은 디버거와 마찬가지로 불법이었을 뿐만 아니라 자신의 컴퓨터에 설정되어 있는 루트 패스워드를 모르는 한, 갖고 있다고 해도 설치할 수 있는 방법이 없었다. 연방 수사국(FBI)이나 마이크로소프트 지원단(Microsoft Support)이 루트 패스워드를 알려줄리는 만무한 것이다. 댄은 리사에게 컴퓨터를 쉽게 빌려줄 수는 없다고 생각했다. 그러나, 그녀를 사랑했기 때문에 그녀의 요청을 거절할 수도 없었다. 그녀와 함께 하는 모든 순간마다 그는 기쁨을 느끼고 있었다. 그리고 그녀가 자신에게 도움을 청하고 있다는 사실은 곧 그녀 또한 자신을 사랑하고 있다는 것을 의미한다고 생각했다. 댄은 상상하기 힘든 방법을 통해서 이 문제를 해결했다. 그는 자신의 패스워드를 컴퓨터와 함께 빌려주었다. 리사가 그의 책을 읽더라도 중앙 열람 허가 시스템은 댄이 책을 읽고 있는 것으로 여길 것이다. 이러한 행위가 불법이기는 했지만 그녀가 그를 고발하지 않는 한 소프트웨어 보호국이 그 사실을 알아낼 수는 없을 것이다. 물론, 학교 당국이 그가 리사에게 패스워드를 빌려 준 사실을 알아 낸다면 그녀가 패스워드를 이용해서 무엇을 했는가에 상관없이 학생으로서의 그들의 생명은 끝나게 될 것이다. 학교의 정책은 그들이 학생들의 컴퓨터 사용을 감시하기 위해서 사용하고 있는 방법에 대한 어떠한 형태의 방해도 규제의 대상으로 삼고 있었다. 나쁜 행위를 했다는 그 자체가 중요한 것이 아니라 학교 당국이 학생들을 통제하는 것을 방해하려는 시도가 범죄로 규정되었던 것이다. 학교는 금지된 행위를 시도하려는 혐의를 중시하지 그 자체가 무엇인지에 대해서는 관심을 갖지 않았다. 학생들은 이러한 행위에 의해서 직접적으로 퇴학되지는 않았다. 대신에 그들은 학교의 컴퓨터 시스템을 사용할 수 없게 되기 때문에 어쩔 수 없이 모든 과목에서 낙제하게 되는 것이다. 나중에 댄은 학교의 이러한 정책이 많은 학생들에 의해서 컴퓨터가 사용되기 시작한 1980년대에 시작되었다는 사실을 알게 되었다. 그 이전에는 다른 방식을 통해서 학생들을 규제했었다. 학교는 단순한 혐의 사실이 아니라 해로운 행위에 대해서 학생들을 처벌했었다. 리사는 댄을 고발하지 않았다. 그녀를 돕겠다는 그의 결정은 결국 그들의 결혼으로 이어졌고 그들은 어린 시절부터 교육받았던 저작권 침해 행위에 대해서도 의문을 가지게 되었다. 그들은 저작권의 역사와 복제에 대한 소비에트 연방의 제한 규정들과 제정 당시의 미국 헌법에 대해서도 공부하게 되었다. 그들은 루나 시티로 이사를 가게 되었고 그 곳에서 소프트웨어 보호국의 오랜 감시에서 벗어나고자 하는 동류의 사람들과 만날 수 있었다. 서기 2062년, 타이코에서 혁명이 일어났을 때 자유롭게 읽고자 하는 이 보편적인 권리는 곧 혁명의 중심 목표가 되었다. 저자의 말 읽을 권리를 위한 싸움은 지금도 벌어지고 있는 현실이다. 윗글에는 현재의 생활 방식이 50년이 지난 뒤에야 바뀌는 것으로 되어 있지만 글 속에 묘사되어 있는 특정 법률과 행태들은 이미 클린턴 행정부와 출판업자들에 의해서 제안되고 있는 실정이다. 한 가지 예외가 있다면, 연방 수사국(FBI)과 마이크로소프트가 개인용 컴퓨터에 대한 루트 패스워드를 소유하고 있다는 정도일 것이다. 그러나, 이것도 클리퍼 칩(Clipper chip 국가 안전국(National Security Agency)에 의해서 개발된 암호화 칩)과 클린턴 행정부에서 제안하고 있는 조건부 암호화 열쇠 방식(key-escrow 정부가 모든 문서를 해독할 수 있도록 암호화 열쇠를 정부 지정 기관에 조건부로 보관하는 방식)으로부터 가정해 본 내용이다. 이들의 결합은 이미 장기적인 추세가 되어 가고 있으며 실제로 컴퓨터를 사용하고 있는 사람들을 무인 감시 장치가 통제할 수 있는 형태의 컴퓨터 시스템이 늘어가고 있는 추세이다. 윗글에 나오는 소프트웨어 보호국은 실제로는 소프트웨어 출판업 협회(Software Publiser's Association)를 의미한다. 현재, 이 단체는 공식적인 공권력을 갖고 있지 않지만 비공식적으로는 그러한 행위를 하고 있다. 또한, 이 단체는 그들이 컴퓨터 소유자에게 저작권을 준수하게 하거나 이를 어길 때 처벌을 강제할 수 있는 공동 책임 정책을 옹호하고 있다는 사실을 클린턴 행정부와 같은 그들의 친구나 동료들에게 알려 줄 것을 사람들에게 권유하고 있다. 최근 들어, 소프트웨어 출판업 협회는 영세 규모의 인터넷 사업자들에게 그들의 사용자 모두를 감시할 수 있게 해 달라는 요청을 하면서 위협하고 있다. 대부분의 인터넷 서비스 업체들은 소송 비용을 감당할 수 없기 때문에 이러한 요구에 굴복하고 만다(Atlanta Journal-Constitution, 1996년 10월 1일 D3면) 최소한 하나의 인터넷 서비스 업체(캘리포니아의 오클랜드에 있는 Community ConneXion)가 이를 거부했지만 결국 고소 당하고 말았다. 소프트웨어 출판업 협회는 최근에 이 고소를 취하하겠다고 발표했지만, 다양한 방법을 통해서 이러한 주장을 계속해 나갈 것이 틀림없다. 윗글에서 묘사된 대학의 보안 정책은 지어낸 이야기가 아니다. 예를 들면, 시카고 인근에 위치한 한 대학의 컴퓨터에는 로그인할 때 다음과 같은 메시지가 출력된다. (인용 부호도 포함된다) "본 시스템은 허가 받은 사용자에 한해서 이용할 수 있다. 허가를 받지 않았거나 허가 이상의 사용에 대한 모든 사항들은 감시 시스템에 의해서 기록된다. 권한 이 상의 사용에 대한 감시 과정이나 시스템의 유지 보수 과정에서 허가된 사용자에 대한 사용 내역 또한 기록될 수 있으며 본 시스템을 사용하려는 사람들은 모두 이 러한 감시 체제에 대해서 동의해야만 하며 대학 규정에 위반되는 행위에 대해서는 감시 기록이 대학 당국과 법률 집행관에게 증거로 송부된다는 사실 또한 경고한 다." 이러한 내용은 미국의 헌법 개정 제 4조에 대한 무척이나 흥미 있는 접근 방식이라고 할 수 있다. 즉, 헌법상의 권리를 모든 사람들로 하여금 사전에 포기하게 만드는 것이다. -------------------------------------------------------------------------------- 참고 서적 행정 백서 The administration's "White Paper": Information Infrastructure Task Force, Intellectual Property and the National Information Infrastructure: The Report of the Working Group on Intellectual Property Rights(1995) 백서 주해 An explanation of the White Paper: The Copyright Grab, Pamela Samuelson, Wired, Jan. 1996 기만 Sold Out, James Boyle, New York Times, 31 March 1996 공공 정보인가 개인 정보인가 Public Data or Private Data, Washington Post, 4 Nov 1996 공유를 위한 연합 Union for the Public Domain--a new organization which aims to resist and reverse the overextension of intellectual property powers -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: The Right to Read Drafted version: Richard M. Stallman's 6 Sep 1997 updated Copyright (C) 1996 Richard M. Stallman Korean Translator: 1998 Ji Younju 지연주 jiyounju@nownuri.net 자유 소프트웨어의 판매 Selling Free Software by Richard Stallman -------------------------------------------------------------------------------- 목 차 더 높은 배포 가격이 몇몇 사용자들에게 피해를 줄 것인가? 더높은 배포 가격이 자유 소프트웨어의 사용을 억제할것인가? '소프트웨어 판매'라는 어휘는 역시 혼란스러울 수있다. 높거나 낮은 요금, 그리고 GNU GPL -------------------------------------------------------------------------------- 많은 사람들은 소프트웨어의 배포본에 대해서 돈을 청구하지 않는 것 또는 가능한 적게 단지, 손실을 메울 만큼만 청구하는 것을 GNU 프로젝트의 정신이라고 믿는다. 실제로 우리는 자유 소프트웨어를 배포하는 사람들에게 그들이 원하는 만큼 또는 가능한 만큼 요금을 청구하기를 권장한다. 이것이 당신에게 놀라운 것처럼 보인다면, 이 글의 내용들을 끝까지 읽어보기 바란다. "자유(free)"라는 어휘는 두 가지의 합법적인 의미가 있다. 그것은 구속받지 않는다는 자유로움과 비용에 관계되는 자유로움(무료)으로 언급될 수 있다. 우리가 "자유 소프트웨어"라고 부를 때에, 우리는 비용이 없다는 자유로움이 아닌 구속받지 않는다는 자유로움을 말하는 것이다.("언론의 자유(free of speech)"와 "무료 맥주(free bear)"를 생각해 보라) 특별히 그것은 사용자가 프로그램을 실행할 수 있고 수정할 수 있으며 수정하거나 수정하지 않은 채로 프로그램을 재배포할 수 있는 자유를 의미한다. 자유 소트프웨어는 이따금씩 무료로 배포된다. 그리고 가끔은 상당한 가격으로 배포되기도 한다. 종종 같은 프로그램이 서로 다른 곳에서 두 가지 방법 모두로 배포되기도 한다. 사용자가 프로그램을 사용하는 데에 자유롭기 때문에 그 프로그램은 가격에 상관이 없이 자유롭다. 자유 소프트웨어가 아닌 프로그램들은 대개 높은 가격으로 팔린다. 그러나 이따금씩 상점에서 당신에게 무료로 복사본을 줄 수도 있다. 그렇더라도 그것은 자유 소트프웨어가 될 수는 없다. 비용을 지불하던 지불하지 않던 간에 사용자가 자유를 가지고 있지 않기 때문에 그 프로그램은 부자유스럽다. 자유 소프트웨어는 비용의 문제가 아니기 때문에 가격이 낮아야 더 자유롭다거나 자유에 가깝다는 것이 아니다. 그래서 당신이 소프트웨어의 복제본을 배포한다면 상당한 요금을 청구하거나 돈을 버는 것은 당연하다. 자유 소프트웨어를 배포하는 것은 좋고 합법적이다. 만약, 당신이 그것을 한다면 그것으로부터 이익을 얻는 것도 당연할 것이다. 자유 소프트웨어는 공동체의 사업이다. 그리고 그것에 의존하는 모든 이가 공동체의 건설에 공헌하는 방법을 찾아야한다. 배포자들은 그들의 이익을 자유 소프트웨어 재단이나 몇몇 다른 자유 소프트웨어 개발 프로젝트에 제공함으로써 공동체의 발전에 이바지할 수 있다. 자유 소프트웨어의 배포는 개발 자금을 모으는 것이다. 그것을 낭비하지 말라! 기금을 조성하는데 공헌하기 위해서 당신에게는 부가적인 것이 필요하다. 만약에 당신이 너무 낮은 요금을 청구한다면, 당신은 개발을 지원하기 위한 예비 자금을 전혀 축적할 수 없을 것이다. 더 높은 배포 가격이 몇몇 사용자들에게 피해를 줄 것인가? 사람들은 가끔 높은 배포 요금 때문에 돈이 많지 않은 사용자가 자유 소트프웨어로부터 멀어지는 것을 걱정한다. 높은 가격의 독점 소프트웨어는 그렇다. 하지만 자유 소트프웨어는 다르다. 그 차이는 자유소프트웨어는 자연스럽게 널리 퍼지려는 경향이 있는 것이다. 그리고 그것을 얻을 수 있는 많은 방법들이 있는 것이다. 소프트웨어 판매자들은 당신이 표준 가격을 지불하지 않고 독점 소프트웨어를 실행하는 것을 최대한 막으려고 한다. 만약에 이 가격이 높다면 어떤 사용자들은 프로그램을 사용하는 것이 어려울 것이다. 자유 소프트웨어는 사용자들이 소트프웨어를 사용하려고 배포 요금을 지불하지 않아도 된다. 그들은 복제본을 가지고 있는 친구로부터 또는 네트워크 접근 수단을 가진 친구의 도움으로 프로그램을 얻을 수 있다. 또는 여러 사용자들은 같이 모여서 CD-ROM의 가격을 분담할 수 있다. 그러면 각자가 차례로 소프트웨어를 설치 할 수 있다. 소프트웨어가 자유롭다면 높은 CD-ROM의 가격은 중대한 방해물이 아니다. 더 높은 배포 가격이 자유 소프트웨어의 사용을 억제 할 것인가? 또 다른 일반적인 염려는 자유 소프트웨어의 인기에 대한 것이다. 사람들은 높은 배포 가격이 사용자의 수를 줄이고, 낮은 가격은 사용자들을 장려할 것이라고 생각한다. 이것은 독점 소프트웨어의 경우에는 사실이다. 그러나 자유 소프트웨어는 다르다. 복제본들을 얻을 수 있는 방법은 많지만 배포 서비스의 가격은 인기도에 별 영향이 없다. 결국, '얼마나 많은 사람들이 자유 소트프웨어를 사용할게 될까'라는 것은 주로 자유 소프트웨어가 얼마나 많은 일을 할 수 있나, 그리고 얼마나 그것이 사용하기 쉬운가에 의해서 결정될 것이다. 많은 사용자들은 그들이 원하는 모든 작업을 자유 소프트웨어가 하지 못한다면 계속 독점 소트프웨어를 사용할 것이다. 그러므로, 우리가 결국에 사용자들의 수를 늘리기를 원한다면 우리는 무엇보다도 더 많은 자유 소트프웨어들을 개발해야 할 것이다. 그렇게 할 가장 직접적인 방법은 당신 스스로 필요한 자유 소프트웨어를 작성하거나 안내문을 만드는 것이다. 그러나 당신이 소프트웨어를 작성하기보다는 배포하는 것을 주로 한다면, 당신이 도울 수 있는 최선의 방법은 다른 사람들이 그것들을 작성할 수 있도록 자금을 모으는 것이다. "소트프웨어 판매" 라는 어휘는 역시 혼란스러울 수 있다. 엄밀하게 말하면 "판매"는 상품을 돈과 교환한다는 의미이다. 자유 소프트웨어의 복제본을 파는 것은 적법하다. 그리고 우리는 그것을 권장한다. 그러나 사람들이 "소프트웨어 판매"를 생각할 때에 그들은 대개 대부분의 회사들이 하는 것처럼 소프트웨어를 자유롭기보다는 독점적으로 만드는 것을 상상한다. 그래서 당신이 차별을 명시하려고 하지 않는다면, 이 글이 하는 방법으로, 우리는 "소프트웨어 판매"라는 용어의 사용을 피하고 대신 어떤 다른 용어를 고르는 것이 더 좋다고 제안한다. 예를 들면 당신은 "수수료를 받고 자유 소프트웨어를 배포함" 이라고 말할 수 있다. -- 이것은 명백하다. 높거나 낮은 요금, 그리고 GNU GPL 한 가지의 특수한 상황을 제외하고, GNU General Public License(GNU GPL)는 당신이 얼마나 자유 소프트웨어 복제본의 배포 요금을 청구할 수 있는가에 대한 요구 사항이 없다. 당신은 아무것도 청구하지 않을 수 있고 1 페니, 1 달러, 또는 10억 달러를 청구할 수도 있다. 그것은 당신, 그리고 시장에 달려있다. 그러므로 아무도 복사본에 10억 달러를 지불하기를 원하지 않더라도 불평하지 말아라. 한가지 예외는 바이너리(binaries)가 완벽한 소스 코드(source code)없이 배포되었을 경우이다. GNU GPL은 이것을 하는 사람들에게 부가적인 요청으로서 소스 코드를 제공하기를 요구한다. 소스 코드에 대한 요금의 제한이 없다면 그들은 누군가에게 10억 달러와 같은 지불하지 못할 만큼 많은 요금을 청구 할 수 있다. 그리고 사실상 그것을 감추려는 경향이 있다. 그래서 이 경우에 우리는 사용자의 자유를 보장하기 위하여 소스 코드에 대한 요금을 제한해야만 한다. 그러나 보통 의 상황에서는 배포 가격 제한에 대해 이러한 정당한 이유가 없다. 그래서 우리는 소스 코드에 대한 가격 또한 제한하지 않는다. 가끔 그들의 활동이 GNU GPL이 허락한 선에서 교차되는 회사들이 "GNU 소프트웨어에 대한 요금은 청구하지 않겠습니다." 등의 말을 하면서 GNU 소프트웨어와 그들의 소프트웨어를 함께 사용할 수 있게 승인해 주기를 요청한다. 그들은 결코 그렇게 할 수 없을 것이다. 자유 소프트웨어는 자유에 관한 것이다. 그리고 우리가 GPL을 강제하는 것은 자유를 방어하기 위한 것이다. 우리는 사용자들의 자유를 방어할 때에 배포 요금을 얼마나 청구할 것인가와 같은 부수적인 문제에 의해서 논점이 흩어지지 않게 할 것이다. 자유가 논점이다. 모든 논점이며 유일한 논점이다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Selling Free Software Drafted version: Leonard Tower's 4 Aug 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple Place Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Ryu Jaesang 류재상 kidaeryu@soback.kornet.nm.kr 1986년 10월 30일 스웨덴 왕립 기술원 강연문 Copyright (C) 1987 Richard M. Stallman and Remseth 스웨덴 왕립 기술원 강연문 Kungliga Tekniska Hogskolan(Royal Institute of Technology) Stcholm Sweden. Arranged by the student society "Datorforeningen Stacken" 30. Cotober 1986 Original Copy: RMS Lecture at KTH Drafted version: Richard M. Stallman's 18 Sep 1997 updated Korean Translator: 1998 Ji Younju 지연주 jiyounju@nownuri.net -------------------------------------------------------------------------------- [Note : 이것은 강연을 간략히 편집한 사본이다. 이것이 자연스런 구어체의 어법 뿐 아니라 시작 에 잘못이 있을 수도 있으나, 이상한 것은 프린트를 보길 바란다. 본래의 구사 법을 어기지 않고 정확한 문어체로 표현하는 방법은 분명하지 않다.] 타인이 내게 기대하는 이야깃거리는 3가지가 있는 것 같다. 첫 번째로, 여기 해커 클럽에서 최 고의 이야깃거리는 지난날에 MIT와 같은 곳에서 일어난 일일것이다. '인공지능 연구실'을 그렇게 특별한 장소로 만든 무엇에 대해서 말이다. 그러나 사람들은 나에게 이렇게 말해준다. 내가 세 가 지로 이야기해야하는 GNU 프로젝트의 진행 방향과 소프트웨어와 정보를 사유할 수 없는 이유에 대해 말하려고 했던 월요일과 화요일 회의에 있었던 이들이 다르고 이 두 문제는 각각 1시간이 걸릴 것이므로 우리는 약간 오랫동안 있어야 한다고 말이다. 그래서 나는 그것을 세 부분으로 나 누려 한다. 그러면 사람들은 자기가 흥미없어하는 부분에선 밖으로 나갈 수 있을 것이다. 그리고 내가 한 파트를 끝낼 무렵에 끝났다고 말하면 사람들은 나가도 좋다. 나는 또다른 사람들을 데려 오기 위해 Jan Rynning을 보낼 것이다. ( 누군가 이렇게 말할 것이다. "Janne, 그는 마이크가 필요하지 않을 거야." ) Jan, 밖으로 나가서 사람들을 데려올 준비가 되어있나? Jmr : 난 마이크를 찾고 있어요. 그런데 그것이 잠긴 상자 안에 있다고 하더군요. Rms : 예전에 인공지능 연구실에서 큰 망치로 문을 부셔서 열었는데, 그 깨진 문은 필요로 하는 것을 감히 잠그려는 이들 누구에게나 교훈이 되었지. 그러나 다행히도 나는 불가리아 노래를 배운 적이 있어서 마이크 없이도 해 낼 수 있었다. 어쨌든, 내가 여러분에게 부분적으로 나누어 알려주는 방식으로 해도 계속 들어주시겠습니까? ( 대답 : 예! ) 내가 프로그래밍을 시작한 것은 1969년, 뉴욕의 IBM 연구실에서 였다. 후에 내가 대부분 비슷 한 전산과에 갔다. 해야 할 일을 맡고 있는 교수님들과 누가 무엇을 사용할 수 있는지를 결정하 는 사람들이 있었다. 대부분의 사람에게는 터미널이 부족했으나, 많은 교수들은 그들 연구실에 자 기 터미널이 따로 있었다. 이는 낭비였으나 그들에게는 전형적이었다. 나는 MIT에 있는 인공지능 연구실에 갔을 때, 전혀 다른 뭔가 신선한 정신이 있음을 알았다. 예를 들면, 터미널이 모두들에 게 속한다는 생각이다. 교수들은 그들의 문이 부서질 수 있는 것을 감수하면서도 연구실을 잠갔 다. 나는 실제로 커다란 검은 철제 카트를 보았는데, 이는 교수들이 터미널을 잠갔을 때 교수 연 구실의 문을 따기 위해 사용한 것이다. 그 당시에는 터미널들이 거의 없었고 아마 시스템에는 5 종류의 터미널이 있었던 것 같다. 그래서 만약 그 중에 하나라도 잠기면, 꽤 큰 재난이 아닐 수 없었다. 나는 그 아이디어에 영감 받아서 자주 사람들이 필요로 하는 기계가 있는 방의 문을 열기 위해 천장을 오르거나 바닥을 기었다. 그리고 나는 사람들에게 이기적으로 문을 잠그지 말라는 메모를 남겨두곤 했다. 문을 잠근 사람들은 기본적으로 자신만을 위하는 이들이다. 그들에게는 물론 이유 가 있다. 도난당할수 있는 것이 몇 가지 있기 때문에 그것을 잠그려 하는 것이다. 그러나 이는 그 방에 다른 것들이 같이 있어 해를 입는 타인을 염려하지 않는 것이다. 이런 때에는 거의 매번, 방 이 잠겼는지에 여부가 그들의 책임이 아니라는 주의를 주어서 그들은 타협하여 해결책-그들이 걱 정하는 것들을 놓을 장소 즉, 잠글 수 있는 책상이나 작은 방-을 찾을 수 있었다. 요점은 사람들 이 보통 그런 것을 생각하는 것으로 고통받지 않는다는 것이다. 그들은 이런 생각을 가지고 있다. " 이방은 내것이다. 나는 그것을 잠글 수 있다." 이것은 우리가 그들에게 가지지 말도록 가르쳐야 하는 확실한 이유이다. 이러한 문을 잠그지 말아야 하는 정신은 단순히 여기서 그치는 것이 아니라, 전체적인 삶의 진 리가 된다. 인공지능 연구실의 해커들은 정말로 좋고 흥미 있는 프로그램을 쓰는데 열정적이다. 이는 그들이 더 많이 수행된 성과를 얻고자 하므로, 터미널을 잠그는 것이나 유용한 작업을 가로 막기 위해 행해지는 많은 것들을 그냥 두지 못하기 때문이다. 그것은 높은 도덕심으로 자신들이 노력하는 것을 정말로 염려하는 사람들과 단지 작업으로만 여기는 사람들과의 다른 점이다. 단지 직업으로만 여긴다면, 여러분을 고용한 사람이 너무나 어리석어서 여러분을 그저 앉아서 기다리 게 해도 그들의 시간과 돈을 아무도 염려하지 않는다. 여러분도 그곳에서는 많은 것을 얻을 수 없으며 또한 즐겁지 않을 것이다. 우리가 인공지능 연구실에서 가지지 않은 또 다른 것은 파일 보호이다. 컴퓨터에는 전혀 안전 장치가 없었다. 그래서 우리는 다음과 같은 경우에는 의식적으로 그것을 원했다. 비양립식 타임 셰어링 시스템(Imcompatible Timesharing System)을 쓴 해커들은 보통 자칭 시스템 운용자가 다 른 사람들처럼 전원을 회복하기 위해 파일 보호를 사용한다고 결정했다. 그들 중 아무도 이 방법 을 원하지 않았으므로 그들이 실행하지는 않았다. 파일 보호로 시스템에서 무언가가 깨질 때마다 여러분이 이를 맞추어야 한다. 해결책이 없으며 정확히 무엇이 잘못 되었는지 알지 못한다고 아 무도 여러분을 믿지 않으려 한다고 해서 여러분은 실망하여 앉아만 있을 필요는 없다. 여러분이 이것을 고치기 위해 누군가가 와서 하는 것 보다 10배를 알고 있다면, 여러분은 아침부터 와서 그 시스템을 고칠 누군가를 기다리다가 포기하여 집에 갈 필요가 없다. 그리고 우리는 어떤 교수님이나 상관들이 또 무슨 일을 해야할지에 대해 결정하도록 하지 않았 다. 왜냐하면 우리의 작업은 시스템을 향상시키는 것이기 때문이다! 우리는 물론 사용자에게 이야 기했다. 무엇을 필요로 하는지 말하지 않으면 할 수 없다고 말이다. 그 후에 우리는 어떤 종류의 향상이 가능한지를 볼 수 있게 된다. 그리고 우리는 변화된 시스템을 어떻게 보는가와 다른 시스 템에서 보고 가능하다고 여겨지는 산뜻한 아이디어가 무엇인지에 대해 항상 서로서로 이야기했 다. 우리는 순조로운 기능적 무정부를 가진 셈이다. 그리고 나의 그곳에서의 경험으로 그것이 사 람이 살아가는 가장 중요한 방법이라는 것을 알았다. 불행히도 그런 형태의 인공지능 연구실은 없어졌다. 수년 동안 우리는 인공지능 연구실이 MIT 의 다른 전산 연구실에 의해 없어지는 것을 두려워했다. 그곳의 책임자는 제국건설자 유형의 사 람이며 MIT에서 자신을 승진시키 위해 뭐든지 했다. 그리고 조직을 더 크게 만들었으며 인공지 능 연구실을 자기 연구실의 휘하에 두게 했다. 그는 사람들이 명령이나 혹은 명령과 유사한 것들 에 복종해야 한다고 믿었기 때문에 아무도 그의 방식으로 일을 하기를 원하지 않았다. 이는 우리 가 막아보려 노력했었다. 그러나 우리가 위험을 막아보려 했으나 전혀 예상치 못했던 상업주의에 의해 없어졌다. 80년대 초반 무렵, 해커들은 그들이 하고 있는 일에서 어떤 상업적 이익이 있다는 것을 갑자기 알았다. 개인 회사에서 일을 하면 부자가 되는 것이 가능했다. 막아보려는 나의 모든 노력과는 상관없이, 모든 필요한 일의 분담은 멈춰 버렸고 MIT인공지능 연구실은 파괴되었다. 기본적으로 인공지능 연구실의 나를 제외한 모든 유능한 프로그래머들은 멀리 고용되었고 이것 은 순간적인 변화 이상을 가져왔다. 더군다나 해커들의 문화의 연속성이 깨졌기 때문에 영구적인 변화를 야기하게 되었다. 새로운 해커들은 옛날 해커들로부터 항상 공격을 받았다. 옛날에는 가장 흥미로운 것을 한다는 사람들과 가장 재미있는 컴퓨터, 또한 분야별로 느꼈던 상당한 재미가 있 었다. 일단 이러한 것이 없어지고 나서는 어떤 새로운 것도 이곳에서 재개하지 않았으며 새로운 사람들도 오지 않았다. 영감 받을 수 있던 이가 아무도 없었고 예전 전통을 배우려는 이도 없었 다. 게다가 좋은 프로그램을 짤 수 있는 방법을 배우려는 이도 없었다. 프로그램을 작동시킬 수 없는 교수들과 대학원생들과는 좋은 프로그램 작업을 배울 수 없다. 그래서 내가 사랑하던 MIT 인공지능 연구실은 사라졌다. 그리고 그들을 추방하려던 사람들과 싸운지 20여년이 지난 후 나는 그 정신으로 새로운 사회를 창조하기 위해 나 자신을 바치기로 결심했다. 그러나 내가 직면한 첫 번째 문제는 독점 소프트웨어의 문제였다. 예를 들어 해커들이 떠나가 버린 후 연구실에서 일어난 일은 우리가 개발했던 기계와 소프트웨어가 더 이상 유지될 수 없게 된 것이다. 물론 소프트웨어는 작동했고, 아마 아무도 변화시키지 않았다면 그것은 계속 작동했을 것이다. 그러나 기계는 그러치 않았다. 기계는 파손되었고 그것을 수리할 사람은 아무도 없었다. 결국 그것들은 버려 졌다. 예전에 우리는 기계들의 서비스 계약이 있었으나 기본적으로 그것은 농담이었다. 이것은 인공지능 연구실의 전문 해커들이 각 파트의 문제를 해결하는 방법을 취했다. 만약 수리공에게 수리하게 한다면 며칠이 걸려 여러분은 이를 원치 않을 것이다. 그러므로 고칠 수 있는 이들은 그냥 가서 빨리 고치려고 한다. 그러면 그들은 다른 서비스 종사자보다 10배는 더 잘하기 때문에 아주 나은 직업을 가지고 있는 셈이 된다. 보드가 파손됐다면, 서비스 종사자 에게 새것으로 가져오라고 하면 될 것이다. 실제로 예전에 우리의 해커들은 또한 디지털로부터 온 기계를 수정하곤 했었다. 예를 들어 그 들은 PDP-10을 놓을 페이징 박스를 세웠다. 나는 최근에 여기 스톡홀름에서도 이 일을 하는 사 람들이 있다고 생각한다. 그러나 그 때에 이것은 약간 특별한 일이었다. 그리고 아주 오래 전인 1960년대 초반 사람들은 컴퓨터에 새로운 명령어와 새로운 가상 타임셰어링을 첨가하는 수정을 하곤 했다. 그래서 그 때에 70년대 중반으로 물러나게 된 MIT의 PDP-1은 60년대 초반에 넘겨진 것보다 2배의 기능성을 가지게 된 것이었다. 그리고 특별한 하드웨어 스케줄러는 내가 거의 알지 못하는 많은 것들과 특정한 타임셰어링을 위해 고안된 하드웨어를 개인적으로 나누어 보조 업무 와 메모리 맵핑의 특성이 있다. 또한 인덱스 레지스터와 간접적인 수신인 성명을 첨가시켜 약한 기계를 준합리적인 것으로 확장시켰다. VLSI의 단점이라면 더이상 명령어를 첨가시키지 못하는 것이라고 본다. PDP-1은 아주 약간의 명령어로 흥미로운 프로그램을 가능하게 한다는 흥미로운 특성을 가지고 있다. 이것이 가능한 다른 기계들은 거의 없다. 예를 들어 유명한 디스플레이는 큰 스퀘어를 작게 깨버려서 작은 스퀘어로 만들었다. 그것은 PDP-1에서 다섯 가지 명령어로 쓰여진 것이다. 그리고 많은 다른 훌륭한 디스플레이 프로그램도 거의 명령어를 쓰지 않고 쓰여진 것이다. 그것은 인공지능 연구실에서 행해진 것이다. 그러나 무정부주의 말고 해커들의 문화는 도대체 무엇인가. PDP-1시절에 적어도 오직 한사람만이 초창기에 기계를 사용할 수 있었다. 수년 후에 그들은 타임셰어링 시스템을 쓰고 많은 하드웨어를 첨가했다. 그러나 초창기에는 일정 기간 사용 해야 했다. 물론 지금 프로젝트 연구실에서 작업하는 교수들과 학생들은 항상 낮 동안에 들어온 다. 그래서 많은 시간이 필요한 사람들은 경쟁이 덜 심한 밤 시간을 이용한다. 이것은 해커들이 밤새간에 일하는 문화를 만들어 냈다. 타임셰어링이 있을 때 시간을 구하는 것은 여전히 쉽지만 밤이 사용자가 훨씬 적기 때문에 더 밤 시간을 이용하게 된다. 그러나 여러분 혼자만 있는 것도 아니고 해커도 약간 있기 때문에 문제가 발생하게 되었고 이것은 사회적인 현상으로 이어졌다. 여러분이 낮시간에 있게 되면 진정으로 기계에 관심없는 학생들과 교수들을 발견할 수 있을 것이 다. 반면, 여러분이 밤새 있게 되면 해커들을 발견할 수 있을 것이다. 그러므로 해커들은 밤새 이 용하는 문화를 만들었다. 그리고 그들은 새벽 3시에 중국음식을 먹는 것과 같은 다른 문화도 만 들었다. 나는 차이나타운에서 차에서 맞은 아침이 기억난다. 아침을 맞는다는 것은 고요하기에 더 욱 아름다운 일이었다. 잠자러 가는 것이 제일 기뻤다. 빛이 밝아오고 새가 지저귀는 때에 집으로 가는 것은 아주 좋았다. 여러분은 밤새 일을 한 후 고요하고 온후한 만족감을 진정으로 느낄 수 있을 것이다. 우리가 만든 또 다른 문화는 연구실을 자는 곳으로 만든 것이다. 내가 처음 거기 갔을 때부터 연구실에는 적어도 한 개의 침대가 있었다. 나는 아파트가 없었고 연구실에서 몇 달 동안 생활했 기 때문에 다른 사람보다는 더 연구실에서 지냈을 것이다. 나는 여름엔 시원하고 좋아서 그곳을 매우 편하게 생각했다. 사람들이 그들의 열정으로 연구실에서 자는 것은 이상한 일이 아니다. 해 킹할 때까지 멈추지 않고 거기에 있을 것이다. 완전히 다 해냈을 때에 비로소 가까이 있는 수평 면에 올라 탁 트인 공기를 맞을 것이다. 그러나 해커들이 모두 연구실에 남아 있는 것은 인구 통계학적 변화를 가져왔다. 기계에 진정 으로 관심이 없는 학생들과 교수들은 다수이므로 수적으로 더 우세하지만 그들은 두려워한다. 해 커들 없이 시스템을 유지해야 할 때 그들은 이렇게 말한다. "우리는 재난이 있다. 우리는 상업적 소프트웨어를 가져야 한다.", "우리는 그것을 유지하기 위해 회사를 만들어야 한다." 그들이 완전 히 잘못됐다는 것은 증명이 되었지만, 이미 엎질러진 물이었다. 새로운 KL-10이 출현했을 때 의문은 그것이 양립할 수 없는 타임셰어링 시스템이나 디지탈 Twenex 시스템을 운용할 수 있는 가였다. 일단 ITS를 작동시킬 수 있는 해커들이 가버려서 학 구적인 타입의 사람들은 상업적 소프트웨어를 작동시키는 것으로 선택하고 이는 즉시 여러 파급 효과를 가지게 되었다. 이중 일부는 바로 일어나지는 않았지만, 몇몇 사람은 이러한 효과를 알았 다. 하나는 그 소프트웨어가 허술하게 쓰여져서 훨씬 이해하기 힘든 것이다. 그래서 사람들이 실 제로 필요한 전환이 어렵게 되었다. 또 다른 하나는 소프트웨어 안전 장치의 출현으로 사람들이 타인들과는 확실히 덜 협조하게 되었다는 점이다. 예전 ITS 시절에 우리는 합리성을 가지고 누구 나 어떤 파일을 바꾸고 전환하는 것이 바람직하다고 여겼다. 나는 누군가 맥시마(Macsyma)를 사 용하는데 도움을 요청했던 흥미로웠던 사건을 기억한다. 맥시마는 MIT에서 발달시킨 기호 대수 프로그램이다. 그는 도움 요청을 처리하는 사람에게 요청하여 그로부터 한 시간도 안 되어서 대 답을 얻어냈다. 그는 두려워했고 메시지를 보냈다. "계속해서 여러분의 메일을 읽어야합니까. 그 메일 파일이 여러분의 시스템에 없을 수 있지 않습니까?" "물론 아무 파일도 우리 시스템에서 보 호받지 못합니다. 문제가 뭔가요? 대답은 곧 들을 수 있습니다. 왜 불행합니까? 물론 우리는 각각 다른 사람들의 메일을 읽고 여러분 같은 사람들을 만나 도움을 줍니다." 사람들은 자신이 언제 잘 되는지 알지는 못한다. 그러나 물론 Twenex는 안전장치가 켜지는 디폴트를 가지고 있을 뿐 아니라 안전 장치를 사용 할 수 있다는 가정 하에 설계되었다. 손해를 쉽게 일으키는 것이 많은 사고로부터 여러분을 막아 주는 것은 안전 장치이다. ITS에서 우리는 우연하게 이런 사고를 발견해 낙담했었다. 그러나 Twenex에서는 효과가 엄격한 안전 장치에 의해 유지되고 관리자만이 이것을 켤 수 있다고 되어 있어서 해결되었다. 그것에는 사고로 인해 하는 일을 어렵게 만드는 다른 장치가 없었다. 이 결과 는 Twenex에서 안전장치로는 정말로 가지고 싶은 것을 가질 수 없었다. 다른 장치를 놓는 해커 들이 더 이상 없어서 사람들은 안전 장치의 사용을 강요받게 되었다. 6달 동안 그 기계는 그것들 이 시작한 곳에서 대히트를 거두게 되었다. 연구실에서 일하는 누구나 모든 안전 측정을 무시한 힘을 주는 회전 비트를 가지게 될 것이라는 가정을 처음으로 가지게 되었다. 그러나 어느 날 오 후에 와서보면 모든 것들에 대한 회전비트가 꺼져 있는 것을 발견하게 될 것이다. 내가 그것을 발견했을 때 나는 그것을 타도했다. 처음엔 나는 엘리트에 속하는 사람들 중 한 사람의 패스워드를 알게 되었다. 나는 다시 모든 것들을 켤 수 있었다. 그 다음엔 그는 그의 패스 워드를 바꾸고 그의 마음을 변화시켜 지금은 배타적인 그룹에 속해있다. 그래서 나는 기계를 가 져와서 타임셰어링이 안되는 DDT를 뒤졌다. 나는 잠시 모니터를 여기저기 뒤지고 그 자체에 담 는 방법을 명백히 알아내었다. 나는 그것을 일시 가두어 패스워드 체크를 끄게 하고 사람들의 회 전 비트가 있는 데로 돌아가서 시스템 메시지를 띄웠다. 나는 OZ라고 불리는 기계를 설명해야 해 서 시스템 메시지의 말을 띄웠다. "힘을 압류할 시도가 있습니다. 그래서 배타적인 힘을 패배시켰 습니다. -Radio Free OZ" 나중에 나는 "Radio Free OZ"가 Firesign Theater에 의해 사용된 것 중 하나라는 것을 알아냈다. 나는 그때에는 그것을 몰랐다. 그러나 그것은 점차적으로 악화되어 사람들이 시스템의 안전장치를 더욱 요구하게 만든 셈이 되었다. 결국 내가 비밀로 된 패스워드를 가지는 것을 거절했기 때문에 기계의 사용을 중지하게 되었다. 처음 MIT 인공지능 연구실에 패스워드가 나타나게 된 이래로 나는 패스워드가 없어져야 한다는 나의 신념을 세우고 따르기 위해서 가능한 명백한 패스워드를 항상 가져야 함을 확신하고 모든 이에게 그것이 무엇인지 말해줘야 한다는 결론에 이르게 되었다. 나는 컴퓨터에 안전장치를 갖는 것이 정말로 바람직하다고 보지 않기 때문에 안전 제도를 후원하는 것을 기꺼이 받아들이지 않았다. 그것을 허용하는 시스템에서는 나는 "빈 패스워드"를 사용하고, 허용되지 않거나 그렇게 다른 장소로부터 전혀 로그 인을 하지 못하는 시스템에서는 나의 패스워드로 로그 인을 한다. 그 것은 여러분들이 얻을 수 있는 만큼 명백하다. 사람들이 나처럼 로그 인하는 방법을 지적할 때 나는 이렇게 말한다. "그래요. 그건 누구나 이 기계에서 어떤 데이터를 구하는데 필요있는 아이디 어입니다. 나는 그들이 안전장치에 굽히지 않길 확신하고 싶습니다." 그리고 내가 항상 하는 또 다른 것은 모든 보호에도 나의 디렉토리와 파일을 여는 것이다. 왜 냐하면 때때로 거기에 유용한 프로그램에 결합이 있다면 사람들이 그것을 고칠 수 있기 때문이 다. 그러나 그 기계는 "관광사업"이라고 불릴 정도의 현상을 내도록 구성되지 않았다. 지금 무정부 주의의 다른 형태로 병행해온 "관광사업"은 인공지능 연구실에서는 아주 오랜 전통이고 아웃사이 더들에게 기계를 사용하도록 하는 것이었다. 누구나 그 기계로 와서 어떤 것으로든지 로그 인을 하는 것이 자동이었다는 데에 기뻐했다. 여러분이 온다면 여러분은 로그 인하고 작업할 수 있을 것이다. 나중에 Arpanet이 시작되고 사람들이 전 지역으로부터 우리 기계에 연결하기 시작했을 때 특별하게 받아들여진 전통으로 우리는 이것을 약간 공식화했다. 우리가 이 사람들이 프로그램 을 배워서 오퍼레이팅 시스템을 변화시키기를 바랬다. 아무 곳에서나 이 말을 한다면 시스템 운 영자는 두려워할 것이다. 어떤 아웃사이더가 그 기계를 사용한다는 것을 제안하면 그는 이렇게 말할 것이다. "그러나 그가 시작하면 우리의 시스템 프로그램에서 무엇이 바뀌나?" 그러나 우리 에게는 아웃사이더가 시스템 프로그램을 변화시키는 것으로 사회에 공헌하는 진정한 재미를 맛본 다고 본다. 우리는 그들이 이렇게 하는 것에 항상 용기를 가진다. 물론 새로운 작은 시스템 유틸 리티를 쓰는 것이므로 우리는 그들이 하는 것을 간과하고 잘못 볼 수 있다. 그러나 그것들은 그 특성이 첨가되어서 큰 유틸리티로 바꾸어 진다. 그리고 이것은 숙련자가 새로운 특성을 조금씩 첨가하면서 늘어나게 되어 10년 내지 15년 동안 존재한 프로그램이다. 프랑스의 도시와 같은 곳에서 여러분은 늘어나게 된 지극히 오랜 건물들로 100여년이 지난 후 에도 지금과 같은 길이 만들어졌다는 것을 볼 수 있다. 컴퓨터 분야에서는 1965년에 시작한 프로 그램이 기본적으로 그것과 같다. 그래서 우리는 항상 관광자들이 시스템 유지자가 되도록 고용되 어서 시스템 프로그램을 작업해 좋은 성과를 얻도록 해 둘 것을 바란다. 그러나 ITS기계는 손에서 벗어나 이것을 방지하도록 하는 다른 특성을 가진다. 이중 하나는 "스파이"특성인데 이것은 누구나 누군가가 했던 작업을 볼 수 있다는 것이다. 물론 관광자들은 여 러분이 못된 짓이라고 여기는 스파이짓을 사랑하고 좋은 것이라고 여긴다. 그러나 만약 문제이 일으킬 만한 것을 시작되면 항상 그 괸굉자를 지켜보는 누군가가 있게된 다는 결과를 가져왔다. 곧 그 친구들은 관광 사업의 계속적인 유지가 책임 있는 관광자에게 달려있다는 것을 알고 있기 때문에 매우 화를 내게 될 것이다. 우리는 그 작자가 누구인지 아는 사람을 떠나게 할 수 있었다. 그리고 만약 우리가 그렇게 할 수 없다면, 우리는 완전하게 확실한 곳에서부터 잠시 접근을 끊었 다. 다시 돌아갔을 때 그는 우리를 잊을 정도로 멀리 가버렸을 것이다. 그러면 오랫동안 아주 가 버리게 되는 것이다. 그러나 Twenex시스템은 이런 것을 위해 고안된 것이 아니다. 결국 그들은 모두가 다 아는 나 의 패스워드로 견디지 못했다. 항상 관광자들이 두 세 차례씩 나처럼 로그 인하기 때문에 그들은 내 계좌의 액수를 초과하게 만들었다. 그 때에 나는 거의 다른 기계에서 일을 하고 있었기 때문 에 결국 다시 그것을 켜는 것을 포기하고 그만 두었다. 그게 그거다. 나는 내 자신의 것으로 그 기계에 로그 인하지 못했다. (이 점에서 RMS는 우레와 같은 갈채를 못 받았다. ) 그러나 그들은 처음 Twenex시스템을 취했을 때 만들기를 원하는 것에 마음의 많은 변화를 가 졌다. 안전 장치는 변했다. 그들은 또한 ARPA네트워크와 MIT카오스 네트워크의 기계를 가지길 원했으나, 그들은 이것을 다루기가 불가능했고 그런 변화를 만드는 참신한 유능한 인물이 없었다. 인재가 더 이상 없었기에 변화시키기는 것은 힘들었다. 그 시스템은 허술하게 쓰여졌기 때문에 더욱 이해하기 힘들었고 디지털은 이러한 것을 할 수 없었기 때문에, 상업적 시스템이 기본적으 로 그 자체로 유지한다는 생각은 잘못이었다. 그들은 시스템 해커들을 많이 필요로 했지만 더 이 상 시스템 해커를 꾀어내지는 않았다. 그리고 최근에 MIT에는 Twenex에서 보다 ITS에서 해킹 하는 것에 흥미로운 사람들이 더 많다. 이것을 하는 마지막 이유는 Twenex는 공유될 수 없기 때문이다. Twenex는 독점 프로그램이 다. 만약 여러분이 더러운 방식으로 그들에게 비밀을 지켜주면 여러분은 자원을 갖기에만 급급한 것이고 그들에게는 나쁜 맛을 주는 것이다. 사람이 알아챈다면말이다. (어떤 컴퓨터에 종사하는 이들은 그들이 재미있어하는 일은 무엇이나 하면서 그들이 도대체 누구와 같이 일을 하는지를 잠 시도 생각하지 않는다. 그러나 여러분은 그렇게 프로그램 작업을 하는 것이 얼마나 나쁜 일인지 를 알아낼 것이다. 그것은 더욱 실망시킬 것이다. ) 그것이 충분치 않다면 그들은 매년 여러분에 게 장난으로 쓰여진 50000의 추가 라인 코드를 새롭게 양도할 것이다. 왜냐하면 그들은 "수백만 의 장난스런 타이핑으로 결국 유용한 시스템 개발을 따라 잡는다"는 것을 믿기 때문이다. 이런 독점 시스템으로 일어난 일로 인해 나에게 명백해 진 것은 예전 인공지능 연구실의 정신 을 갖는 유일한 방법이 무료 오퍼레이팅 시스템은 갖는다는 것이다. 누구나 공유할 수 있는 무료 소프트웨어를 구성하는 것이다. 그래서 우리는 이것을 발달시키기 위해 모두를 불러 같이 작업했 다. 그것이 GNU프로젝트를 이끄는 것이다. 이제 두 번째 파트로 넘어가 보자. 3년 반전에 나는 무료 소프트웨어 시스템을 시작했다. 나는 개발 가능한 두 가지 시스템을 볼 수 있었다. 하나는 LISP기계 시스템이다. 그것은 특별한 LISP기계가 아니라 일반적인 목적의 하 드웨어로 쓰일 무료인 것을 제외하고는 막 발전된 MIT LISP기계 시스템이다. 그리고 다른 하나 는 더 양식화된 오퍼레이팅 시스템이다. 내가 양식화된 오퍼레이팅 시스템을 만든다면 그것은 UNIX와 양립할 수 있을 것이다. 왜냐하면 그것은 모든 사람들이 쉽게 다가갈 수 있는 것이기 때 문이다. 얼마 후에 나는 후자를 이룰 수 있다고 결론지었다. 이유는 여러분이 일반적인 목적으로 LISP기계 시스템과 같은 하드웨어를 실제로 가지고 있지 않기 때문이다. LISP기계 시스템은 훌 륭한 실행 속도와 확실한 에러 발견을 얻기 위해 특별한 하드웨어와 특별하게 쓰기 가능한 마이 크로코드를 사용한다. 보통 하드웨어로 LISP시스템이 충분한 속도를 내기 위해 여러분은 가정을 해야 한다. 확실한 독립변수는 올바른 유형이다라는 가정이다. 그렇지 않을 경우에는 시스템이 곧 장 파괴된다. 물론 여러분은 확실하게 체크를 할 것이고 원한다면 확고한 프로그램을 쓸 수 있을 것이다. 그 러나 사실 여러분이 그것을 체크하지 않은 것을 놓치지 않았다면 잘못된 유형의 독립변수 함수를 부여했을 때, 에러를 알리는 기억장치 같은 것을 볼 수 있다. 그러면 결과는 여러분이 이런 에러들을 잡기 위해 LISP시스템 아래서 운용될 것이 필요하게 될 것이다. 사용자에게 계속 운용할 능력을 주게 되고 그것에 일어난 잘못을 고치게 될 것이다. 결국 나는 낮은 수준에서 오퍼레이팅 시스템을 가지는 것보다 훌륭한 오퍼레이팅 시스템을 만드는 것 이 더 낫다는 결론을 지었다.-그것은 오퍼레이팀 시스템과 LISP사이에 선택, 혹은 단지 오퍼레이 팅 시스템을 취하게 되는 것이다. 그래서 나는 처음에 오퍼레이팅 시스템을 하기로 하고 UNIX와 양립할 수 있도록 했다. 마침내 내가 이 시스템에 가장 놀라운 언어인 영어로 이름을 썼다는 것 을 알았을 때 내가 한 선택을 확신했다. GNU란 말은 "Gnu's Not Unix"를 뜻했다. 회생된 두 문 자 어는 MIT의 해커 사회에선 아주 오래된 전통이다. 그것은 TINT라 불린 편집장으로 시작되었 다. 뜻하는 말은 "Tint Is Not Teco."이다. 나중엔 이런 말이 쓰였다. "SINE"은 "SINE Is Not Emacs", FINE은 "Fine Is Not Emacs." EINE은 "Eine Is Not Emacs.", ZWEI는 "Zwei Was Eine Initially." 그리고 결국 지금은 GNU를 쓴다. 나는 약 2년반 전에 GNU 일을 하기 시작한 이후로 작업의 반 이상은 했다. 내가 프로젝트를 작업하려고 준비할 때 처음 내가 이미 유용하게 무료로 찾은 것을 둘러보기 시작했다. 나는 "무 료 대학 컴파일러 장비"라 불리는 흥미로운 휴대용 컴파일러 시스템을 발견했다. 나는 그렇게 이 름을 붙인 것으로 그것을 가질 수 있었다. 그래서 나는 그것을 개발한 사람에게 GNU프로젝트에 그것을 줄 수 있는지를 묻는 메시지를 보냈는데 답이 왔다. "안된다. 대학은 무료일지 모르나 그 들이 발달시킨 소프트웨어는 그렇지 않다." 그러나 그는 역시 양립할 수 있는 UNIX시스템을 원 하고 그것의 핵심부분을 쓰기를 원한다고 말하고 나서 왜 나보고 그 후에 유틸리티를 쓰지 않았 냐고 물었다. 그들은 그의 독점적 컴파일러를 사람들이 살 수 있도록 분포했다. 그리고 나는 이것 이 야비하다는 생각이 들어서 그에게 나의 첫 번째 프로젝트는 컴파일러라고 말했다. 나는 그 때 최적화 컴파일러에 대해 작업한 적이 없었으므로 정말로 몰랐다. 그러나 나는 그때 에 무료라고 하는 컴파일러를 얻었다. 그것은 파스텔(PASTEL)이라 불린 컴파일러인데 본인은 "훌륭하지 않은 파스텔 "이라는 뜻을 지닌다고 본다. 파스텔은 매개변수적인 유형과 명백한 유형의 모수와 같은 특성과 많은 복잡한 것들을 포함한 아주 복잡한 언어이다. 물론 컴파일러는 이 언어로 쓰였고 이러한 것들의 사용을 최적화시키는 많은 복잡한 특성을 가진다. 예를 들어 이 언어에서 "문자열"타입은 매개변수적인 유형이다. 여러 분이 어떤 특정한 길이의 문자열을 원한다면 "string(n)"이라고 말할 수 있다. 그리고 모수는 문 맥에 의해 결정된다. 문자열는 매우 중요해서 그것을 사용할 많은 명령어들이 빨리 작동하는 것 은 필요하다. 이것은 그런 것들을 발견할 특성들이 많아야 한다는 것을 뜻한다. 설정된 문자열의 길이가 함수로 영구적으로 되는 독립 변수일 때, 그들이 만들어내는 코드의 최적화 값을 구하는 것과 같은 것 말이다. 그러나 나는 자동으로 레지즈터를 배분하는 방법을 이 컴파일러에서 알아 냈다. 작동시키는 방법은 기계마다 다르다. 자, 이 컴파일러을 파스텔로 컴파일한 이래로 내가 필요로 하는 방법은 내가 했던 C언어로 초 기 목적을 채우고, 나의 첫 번째 기계로 기대되던 68000을 후기 목적을 채웠다. 그러나 나는 심각 한 문제에 빠졌다. 왜냐하면 PASTEL언어는 여러분이 전에 설정했던 것으로 정의되지 않았기 때 문에 설정과 사용은 어떤 명령 안에 있었다. 즉, 파스칼의 "전의" 설정은 전체적인 프로그램을 읽 고 중심에 있어서 한 번만 처리하기 때문에 쓸모가 없었다. 그리고 그것은 중심에 있어서 한 번 만 처리한다. 결과는 컴파일러에 중간저장이 필요하게 되었다. 필요한 메모리 용량은 여러분의 파 일 크기에 비례했다. 또한 이것은 많은 공간을 차지하기 때문에 여러분은 아주 많은 공간이 필요 했을 것이다. 결과로 나에게 유용했던 68000시스템이 컴파일러에 맞지 않는다는 것을 알았다. 일 시적인 기억 장치에 16K의 단어 분량으로 제한을 두는 것은 UNIX에서는 끔찍한 버전이기 때문 에 6메가 바이트가 있어도 단지 16K의 단어 분량을 가질 수 있었다. 물론 일시적인 충돌을 일으 키거나 같은 때에 다른 것이 있는 행렬 충돌울 막기 위해서 2차식의 행렬이 필요했고 수백 수천 바이트를 가진 큰 함수가 있어야 했다. 그래서 나는 10의 첫 번째 패스나 컴파일러의 그런 패스 들을 디버그하고 기계를 크로스 컴파일하고 나서 두 번째 것은 전혀 운용되지 않는다는 것을 알 아냈다. 내가 이 문제에 대해 무엇을 할지에 대해 생각하고 그것을 고칠지 새로운 컴파일러를 쓸지를 고심하는 동안에 주위의 분위기로 GNU Emacs를 작업하기 시작했다. GNU Emacs는 GNU시스 템의 주요 공헌 부분이다. 그것은 확장된 언어로서의 LISP의 사용은 제외하더라도 내가 10년 전 에 발달시킨 오리 지날 emacs처럼 확장시킬 수 있었던 텍스트 에디터이다. 에디터는 그 자체로 LISP해독기로서 C언어로 실행될 수 있다. LISP해독기는 완전히 휴대 가능하기 때문에 에디터 외 부에 LISP시스템이 필요하지 않다. 에디터는 그 자체에 LISP시스템을 포함하고 있고 모든 명령 이 LISP로 써지므로 여러분에게 여러분 고유의 에디터 명령을 쓰는 방법을 보여주는 예를 제공 할 수 있다. 여러분은 정말로 원하는 에디터 명령으로 그것들을 바꿀 수 있다. 2년 전 그해 여름, 내 친구 한 명은 Gosling Emacs를 일찍이 연구했기 때문에 그의 버전을 분 포하라는 메시지를 Gosling으로부터 허가를 받았다고 나에게 얘기해 주었다. Gosling은 원래 그 의 Emacs 를 세우고 나서 무료로 퍼지도록 하여 사람들이 그것을 발달시킬 수 있도록 한 것이 다. 그것의 바탕은 오리지널 Emacs의 시작과 같은 정신을 따르는 그 자체의 매뉴얼로 Gosling 자체의 언어에 있다. 그리고 나서 그는 그것을 복사하여 사람들의 뒤에서 섞어 놓아 사람들이 그 것을 재구분할 수 없게 만들어 그것을 소프트웨어하우스에서 팔게 했다. 내가 그를 나중에 개인 적으로 대하는 것은 그가 여러분이 그 역사에 대해 기대하는 만큼 얼마나 비열하고 야비한지를 보여주기 위함이다. 그러나 어떤 경우에서든 나의 친구는 나에게 이 프로그램을 주었고 나는 내가 사용했던 오리지 널 Emacs와 그 프로그램이 양립할 수 없을 정도의 높은 수준으로 에디터 명령을 바꾸도록 했다. 수적인 독립 변수를 모두 묶어 쓸 수 있도록 하기 위해 그들은 내가 원하던 모든 특성들을 가지 고 쓸 수 있어야 한다고 기대했다. 그러나 얼마 후에 나는 MOCKLISP라 불리는 그 에디터의 확 장 언어는 임무에 충분치 않다는 것을 발견하였다. 나는 계획했던 것을 하기 위해 즉시 그것을 대체해야 한다고 깨달았다. 실제로 LISP를 MOCKLISP로 대체하는 생각을 하기 전에 내가 알아 낸 것은 그것이 처음으로 행해진 것이라는 것이다. MOCKLISP가 MOCK이라 불린 까닭은 그것 이 데이터 타입의 구조가 아니기 때문이다. 그것은 어떤 종류의 정렬도 갖고 있지 않다. 그것은 LISP기호를 갖고 있지 않으며 이름으로 된 대상이다. 어떤 특정의 이름으로 하나의 대상이 있는 데, 여러분은 그 이름으로 타이프를 치면 항상 그것으로 받을 수 있다. 그리고 이것은 많은 프로 그램을 쓰는 것을 방해하기 때문에, 실제로는 그 방법으로는 할 수 없는 복잡한 문자열 조작을 해야 일을 처리할 수 있을 것이다. 그래서 나는 LISP해독기를 써서 MOCKLISP에다가 놓았으며 그 과정에서 나는 에디터의 내부 데이터 구조가 LISP대상으로 되길 원하기 때문에 그 구조를 다시 써야한다는 것을 알았다. 나는 LISP와 에디터 사이에 조화가 이루어지길 바란다. 그것은 에디터 버퍼, 서브 프로세서, 윈도 우와 버퍼 포지션과 같은 대상들이 모두 LISP대상이 되어야한다는 것을 뜻한다. 그래서 에디터들을 LISP데이터와 LISP기능이 하라는 데로 잘 처리되도록 초기화시켰다. 이것은 내가 모든 대상들의 데이터 포맷을 재구성하고 작업하던 모든 함수을 다시 써야한다는 것을 의미했다. 그리고 6개월 후 에디터 모두를 다시 쓰는 결과가 되었다. 게다가 MOCKLISP로 쓰는 것은 아주 어려운 일이고 불명료했다. 다시 씀으로 인해 LISP의 힘 이 실제로 커지는 것을 보기 위해서 나는 그것들을 더 파워 있고 간단하며 훨씬 빠르게 만들었 다. 그것을 하고난 결과 내가 이 프로그램을 분포하기 시작했을 때 내가 받은 것중에서는 약간만 남았다. 이쯤에서 그는 Gosling이 생각나는 회사에 그것을 분포한 나의 친구의 권리에 도전하는 프로그 램을 팔았다. 메시지는 백업 테이프여서 그는 그것을 찾을 수 없었다. 그리고 Gosling은 그에게 허용을 해주지 않았다. 그리고 나서 이상한 일이 일어났다. 그는 이 회사와 협상하여 회사가 그들 이 분포했던 것과 닮은 것이 분포되는 것은 아무런 관련이 없이 보였다. 그는 여전히 분포했고 그가 일하는 Megatest회사도 그의 것과 같은 것을 분포했다. 그것은 정말로 Gosling Emacs엔 오 래된 버전이었다. 그래서 그는 그들과 그것을 분포하는 것을 그만두고 GNU Emacs의 사용하기 시작했다. 그들은 그가 결국은 허용을 받았다고 생각하게 되었다. 갑자기 모든 이들이 행복해 졌 다. 그리고, 회사는 다양한 보조품을 팔았지만 무료로 GNU Emacs를 분포하는 일을 하도록 나를 고용하기를 원한다고 했다. 그래서 그들에게는 내가 마음을 바꿔 그렇게 할 수 없다고 하는 것이 이상한 일이었다. 나는 프로그램을 분포할 수 없다는 메시지를 네트워크에 보냈다. 그들은 어떤 것도 할 수 없고 언제 무슨 일을 하는 것조차 확실하지 않다고 말했다. 그리고 이것은 누구도 그 것을 사용하지 못하게 될 슬픈 일이 일어나 사람들을 놀라게 할 정도였다. (때때로 나는 내가 살면서 할 수 있는 가장 중요한 것에 대해 생각한다. 비밀로 되어있는 독점 소프트웨어의 거대한 파일을 찾아 거리에 복사본를 뿌리기 시작한다. 그러면 더 이상 그것은 비 밀이 되지 않는다. 아마 내 자신이 새로운 소프트웨어를 쓰는 것보다 그것을 사람들에게 주는 것 이 훨씬 효과적일 것이다. 그러나 아무도 너무 겁이나서 그렇게 하지 않는다. ) 그래서 나는 남아 있는 나머지 분은 다시 쓰도록 강요받았고 일주일 반정도 걸려 그것을 했다. 그들은 대단한 승리를 했고 나는 그 후론 그들과 함께 일하지 않았다. GNU가 약 일년 반 걸려 안정하게 되었을 때 나는 시스템의 다른 부분을 다시 시작했다. 나는 C코드를 기호적으로 디버거하는 GDB라 불린 디버그를 개발했다. 그것은 최근에 분포되었다. 지 금 이 디버그는 버클리 UNIX에 디버그로 있는 DBX의 정신으로 확장된 것이다. 명령어는 독립 변수를 따라 여러분이 원했던 것으로 말하는 언어로 구성되어 있다. 이 디버그의 명령어는 모두 약자화 할 수 있고 보통 명령어는 간단한 문자 약자나 어떤 독특한 약자를 쓸 수 있다. 확장 가 능한 HELP장치가 있다. 여러분은 어떤 명령어나 서브명령어로 HELP 형식을 따라서 그 명령어 의 사용법을 길게 묘사할 수 있다. 물론 C로 표현할 수도 있으며 그 값을 프린트할 수 있다. 여러분은 또한 C디버그를 사용하지 않고 일을 처리할 수 있다. 예를 들어 여러분은 어떤 기억 장치에서 값을 구하기 위해서나 할당하기 위해 C데이터 타입에 맡길 수 있다. 만약 어떤 기억장 치의 어드레스에 떠도는 값을 저장하기를 원한다면 여러분은 이렇게 말할 수 있을 것이다. "나에 게 이 어드레스에 맞는 FLOAT나 DOUBLE유형의 대상을 주시오" 그리고 그것을 할당할 것이다. 여러분이 또 할 수 있는 것은 예전에 테스트되었던 모든 값을 구하는 것이다. 시험된 모든 값은 "값 역사"에 놓이게 된다. 여러분은 그것의 수적인 자리에 의해 역사의 요소에 맡길 수 있거나 쉽 게 달러 사인으로 마지막 요소에 맡길 수 있다. 이것은 리스트 구조를 남기는 것을 훨씬 쉽게 만 든다. 여러분이 다른 것에 초점을 맞추는 C언어 구조를 가지고 있다면 다음과 같이 할 것이다. "PRINT *$.next"가 의미하는 것은 "나에게 보여줄 지난 것은 가져가고 다음 분야를 가져와 지적 하는 구조에 디스플레이 하라."이다. 여러분이 명령을 계속 반복하면 매 때마다 리스트에 다음 구 조가 보일 것이다. 반면 다른 C디버그에서 하는 유일한 방법은 매 때마다 긴 명령을 타이프 하는 것이다. 다루었던 지난 명령을 반복하는 커리지리턴을 타이프 하여 특성들을 모으면 아주 편리하 다. 여러분이 원하는 리스트에 각 요소를 커리지리턴으로 타이프해라. 디버그에는 또한 명확하게 놓을 수 있는 변수들이 있다. 여러분은 이름을 달러 사인으로 할 수 있으며 그것은 변수이다. 여러분은 C데이터타입의 변수 값을 할당할 수 있고 나중에 이것들을 시 험할 수 있다. 그 중에는 사용할 만 한 것들이 있다. 여러분이 시험해 볼 특정한 값이 있다면 그 것에 많이 맡겨야한다는 것을 알아서 그것에 이름을 줄 역사에서의 수를 기억해야한다. 또한 상 황적으로 구분점을 놓을 때 그것들을 위한 사용을 알아야 할 것이다. 상황적 구분점은 기호적인 디버그의 특징이다. 여러분은 이렇게 말할 것이다. "프로그램에서 이 지점에 이르게 되면 그 표현 이 확실할 때만 제외하고 멈추어라." 디버그의 변수는 여러분이 프로그램 변수와 디버그 변수에 서 구한 변수의 정의 값을 비교하게 할 것이다. 그들이 사용할 수 있는 또 다른 것은 할당이 C로 표현되기 때문에 센다는 것이다. 그래서 여러분은 5로 "$foo"의 값을 "$foo++"의 값으로 이득을 볼 수 있는 "foo+=5"를 할 수 있다. 여러분은 또한 상황적 분기점에 이것을 쓸 수 있어서 "$foo--==0"을 쓰는 것은 분기점이 하는 것의 10배나 깨는 간단한 방법이 된다. 모두가 그것을 따를까? foo가 감소하여 그것이 0이면 깨진다. 여러분이 건너 뜨기를 원하는 때, 그 수에 $foo를 놓으면 그렇게 할 수 있다. 또한 정렬하여 요소를 시험할 때도 사용할 수 있다. 포인터를 정렬하 려면 이렇게 할 수 있다. PRINT X[$foo++] 그러나 처음엔 이렇게 해야한다. SET $foo=0 여러분이 포인트를 Print란 표현으로 할 때 X에는 0번째 요소가 있게 되고 그것을 다시 하면 첫 번째 요소가 있게 된다. 이것들을 구조를 나타내는 포인터라고 가정하여, PRINT에 X라고 하 기 전에 별표를 하면, 매 때마다 정렬할 요소들이 포인트된 다음 구조를 프린트하게 된다. 물론 이 명령을 커리지리턴으로 반복할 수 있다. 단순히 반복하는 것이 충분하지 않다면 사용자가 만 든 명령어를 사용할 수 있다. "Mumble"이라고 정의하려면 명령줄에 그 선을 넣고 "end"라고 해 보라. 그러면 이 줄을 수행한 "Mumble"명령이 정의된다. 명령 파일에 이런 정의를 놓는 것은 매 우 유용하다. 각 디렉토리에 명령을 가지고 작업할 디렉토리를 디버거가 자동적으로 하도록 할 수 있다. 그래서 프로그램의 데이터 구조에 접근하기 위한 유용한 방법으로 사용자 정의의 명령 을 각 프로그램에 정의할 수 있다. 또한 사용자 정의의 명령에 설명을 넣을 수 있어서 만들어진 명령에 "help"를 실행할 수 있다. 이 디버그의 특별하게 다른 점은 일시적인 기억장치로부터 조직을 버릴 수 있는 능력이다. 왜 냐하면 여러분이 디버거한 프로그램에 일어난 것을 시험하는 것뿐만 아니라 다른 방법으로 생각 하는 것으로 그것을 변화시키는 것이 중요하기 때문이다. 그래서 여러분이 어떤 문제를 찾아내고 잘못된 것을 안 후에는 코드가 잘못되어 처음 프로그램을 리컴파일하는 것 없이 다음 버그를 알 아내는 것처럼 그것들을 고칠 수 있다. 이것은 유연성 있게 프로그램의 데이터 영역을 변화시킬 수 있을 뿐 아니라 제어의 흐름도 변화시킬 수 있게 한다. 이 디버그에선 다음과 같이 함으로써 직접적으로 제어의 흐름을 변화시킬 수 있다. SET 4PC= 그러면 프로그램을 셀 수 있다. 또한 일시적인 기억장치도 놓을 수 있으며 다음과 같이 말할 수 있다. SET $SP+= 여러분이 일시적 기억장치의 포인터를 어떤 량으로 늘리려면 말이다. 그러나 프로그램의 특정 한 라인에서 시작하기 위해 특정한 라인을 또한 프로그램 카운터로 놓을 수 있다. 그러나 잘못된 함수를 찾아내어서 여러분이 정말로 그 함수를 부르길 원하지 않을 때는 어떤가? 그 함수는 매우 실수를 잘 하기 때문에 여러분이 정말로 원하는 것은 그것으로 되돌아가 그 함수가 했었던 것으 로 일을 수행하는 것이다. 여러분은 "RETURN"명령을 사용할 수 있다. 여러분이 기억장치의 구 조를 선택하여 " RETURN"으로 하면 그것은 그 함수가 즉시 되돌아 간 것처럼 버려지게 될 것 이다. 또한 돌아가야 할 값을 가질 수 있다. 이것을 실행을 계속하지 않는다. 되돌아간 것 처럼하 여 프로그램을 멈추어서 여러분이 다른 것으로 바꿔 계속할 수 있게 하는 것이다. 이런 것들을 한 데 모아서 여러분은 프로그램에서 하던 것을 잘 제어할 수 있다. 게다가 약간 놀랄만한 것이 있다. C는 문자열 상수를 가지고 있다. 만약 여러분이 디버그를 계산하는 표현으로 문자열 상수를 사용한다면 무슨 일이 일어나겠는가? 여러분이 디버그 하는 프 로그램에서 문자열를 만들어 내야 한다. 그것은 잘 될 수 있다. 디버그된 프로그램에 MALLOC라 불리는 것을 설치하고 실행시키면 다시 제어된다. 그러면 문자열 상수가 놓인 곳이 찾아진다. 명백하게 이 디버그가 실제 GNU시스템에서 실행될 때 나는 그 아래서 돌아가는 프로세서의 내부상태를 시험하기 위한 장치를 놓으려고 한다. 예를 들어 페이지가 있고 읽을 수 있고 쓸 수 있는 메모리 맵의 상태와 하위 프로그램의 터미널 상태를 시험하는 것이다. 이미 약간의 명령어 가 있다. 이것은 UNIX의 디버그와는 달리 터미널 상태가 완전히 디버그와 디버그 하는 프로그램 이 분리되어 있다. 그래서 그것은 다루지 않은 모드로 운용되는 프로그램과 입력이 돌아가는 것 을 방해하는 프로그램이 작동하게 된다. 또한 디버그 하는 프로그램의 터미널 세팅이 사용되는 것을 발견하도록 하는 명령어가 있다. 일반적으로 디버그는 하위의 프로세서에서 실행되는 모든 것을 발견하도록 해야 한다. 이미 존재하는 GNU에는 두 가지의 주요 부분이 있다. 하나는 새로운 C컴파일러이고 하나는 TRIX핵심부분이다. 새로운 C컴파일러는 내가 지난봄부터 쓴 것이다. 나는 드디어 파스텔을 던져버려야 한다고 결 심했다. 이 C컴파일러는 Arizona Portable Optimizer 대학으로부터 파스텔에 대한 어떤 생각이 이 용되었다. 이 흥미로운 아이디어는 간단한 명령으로 개발되는 많은 종류의 기계를 작동시키는 것 이다. 그리고 나서 그 기계가 그것을 허용할 때 복잡한 명령로부터 여러 간단한 명령으로 결합 한다. 이것을 하기 위하여 그들은 대수적인 지식으로 명령을 표현했다. 예를 들어 ADD명령은 이 것을 나타낸다. r[3]=r[2]+4 이것은 컴파일러 안에 레지스터 2의 내용을 잡고 4를 더하여 레지스터 3으로 저장하는 표현이 다. 이런 방식으로 어떤 기계에도 가능한 명령을 표현할 수 있다. 그래서 그들은 이 방법으로 모 든 명령을 표현했고 그것들을 묶어야 할 때가 왔을 때, 하나에서 다른 표현으로 대체하는, 즉 결 합된 명령을 더 복잡한 대수 표현으로 바꾸었다. 때때로 처음 명령의 결과가 더 이상 이용을 할 수 있느냐에 달려 있으므로 두 가지의 할당 작 업으로 명령을 묶는 것은 필요했을 것이다. ???로 포인트 되는 이 를 위한 것과 ???로 포인트 되 는 이 값와 함께 다른 것을 두 번째 명령으로부터 온 것으로 대체시켰다. 그러나 이 값이 일단 한 번 사용된 것이라면 여러분은 그것을 대체한 후에 제거할 것이다. 더 이상 그것을 계산할 필 요는 없다. 그래서 정확히 사이에 낀 명령이 더 이상 다른 값이나 그런 것으로 바뀌지 않는 것을 점검하는 대체는 다소 복잡한 것이다. 여러분은 자동 증가와 자동 감소 어드레싱과 같은 것을 지 지할 때 이런 것들이 여러분이 하는 것이 보존할 값가 없는 환경을 점검하는가를 다양하게 체크 해야 한다. 그러나 이러한 모든 것을 체크를 한 후에 여러분은 대체된 복잡한 표현을 가지고 여러분이 선 택한 기계의 정당한 명령을 인식할 본보기를 맞추어야 한다. 그리고 그것이 인식된다면 여러분은 이 두 가지 명령을 하나의 결합으로 대체하고 그렇지 않으면 그것을 따로 놔두어야 한다. 그들의 기술은 이 방법으로 데이터의 흐름에 관여하는 두세 개의 명령을 묶는 것이다. Arizona 컴파일러에서는 실제로 이와 같이 텍스트 문자열로 표현하며 그 컴파일러는 매우 느리 다. 첫 번째로 나는 그들의 컴파일러를 사용할 생각을 해서 그것을 변형했다. 그러나 내가 원하는 속도를 얻기 위해 그것은 전적으로 명백하게 내가 다시 써야 한다는 것은 확실했다. 그래서 나는 이 모든 표현들을 위한 리스트 구조를 사용하기 위해 다시 썼으며 그것은 다음과 같다. (set (reg 2) (+ (reg 2) (int 4))) 이것은 Lisp처럼 보이나 각 기호가 특별히 각인된 것이기 때문에 이것의 의미는 LISP가 아니 다. 정의된 여러분이 필요로 하는 이런 정의된 기호는 특별히 고정된 집합이다. 그리고 각각은 인 수 타입의 특정한 본보기를 가지고 잇다. 예를 들어 "reg"는 항상 세어지는 것이기 때문에 완전수 이다. 그러나 "+"은 두 개의 보충표현을 취한다. 또한 각각의 표현은 그것이 고정된 것인지 유동 적인 것인 지와 얼마나 많은 바이트를 쓰는지를 말해주는 데이터 타입이다. 그것은 여러분이 원 하기만 하면 다른 것으로 운용되도록 확장될 수 있었다. 내가 자동으로 레지스터 배당을 하는 방법은 처음 이 코드를 만들고 결합체와 모든 것을 할 때 아마도 레지스터로 가는 모든 변수를 위해 16으로 시작하는 숫자나 여러분의 기계에 실제 레지스 터를 높이는 가짜레지스터 번호라는 것을 메기는 것이다. 그래서 실제레지스터는 0에서 15까지또 는 다른 수로 번호에 메겨지게 된다. 그리고 나서 컴파일러의 마지막 부분 중 하나는 통과하거나 가짜 레지스터를 실제 레지스터로 바꾸는 것으로 구성된다. 다시 모순된 그래프를 만들면 가짜 레지스터가 같은 포인트에 있는 것이 보인다. 물론 그것은 같은 실제 레지스터로는 갈 수 없고 가능한 한 실제 레지스터에 앉으려고 한다. 그것들이 얼마나 중요한지 우선 순위를 명령하면서 말이다. 마침내 그것은 변수 문제를 위한 코드교정을 해야 한다. 실제 레지스터에 맞지 않는 가짜 레지 스터가 있을 때 그것이 대신 기억장치의 홈으로 놓여야 하는 일 같은 것 말이다. 그 일이 어떤 기계에 일어났을 때 명령의 일부는 약하게 된다. 예를 들면 68000에서 여러분은 메모리에 레지스 터를 더할 수 있으나 하나의 메모리 위치를 다른 것에 더할 수는 없다. 그래서 만약 여러분이 ADD명령을 가지고 있고 68000에 앞세워서 이 두 가지를 메모리 안에서 끝낸다면 그것은 유효하 지 않게 된다. 이 마지막 패스는 레지스터를 통과하고 이것들을 레지스터에 카피하며 이 문제들 을 교정할 필요가 있는 레지스터를 벗어나게 된다. 문제는 또한 인덱스 레지스터에서 나타날 수도 있다. 만약 여러분이 무언가에 의해 인덱스 하 려 한다면 코드가 부당하게되는 대부분의 시간은 여러분이 간접적으로 어드레싱하는 기계의 경우 를 제외하고는 메모리에 있게된다. 여러분이 인덱스 레지스터에 자동 증가를 할 경우에 여러분은 그 값을 레지스터에 카피하고 명령을 실행하여 그것이 실제로 있던 기억장치의 홈에 돌아가 증가 된 값을 카피 해야한다. 많은 방들이 있어서 나는 실제로 충분히 필요한 모든 방을 실행하는 것을 끊내지 않았다. 이 컴파일러는 C코드가 C데이터 타입의 정보로 주석을 달은 구문 트리로 효과적으로 변환하는 parser를 갖추는 작업을 한다. 이 트리를 보는 다른 패스와 LISP같은 코드가 생성된다. 그리고 나 서 몇몇 최적화 면제가 통과된다. 이것들은 계속 쓰여진다. +1은 즉시 단순화될 수 있다. 보통의 하위표현을 인식하여 기본 블록을 찾고 데이터흐름을 분석한다. 그래서 그것은 각 명령의 값이 그 명령 안에서 사용된다는 것을 알리고 이후에는 절대 사용되지 않는다. 그리고 또한, 그 값이 쓰이던 곳에서의 각 명령을 연결하는 것은 개발되어서 만약 내가 가짜 레지스터 R[28]을 생성시 킬 명령을 가지고 있다면 R[28]을 사용할 다른 명령이 있고 그것은 R[28]을 사용할 첫 번째 장소 가 된다. 나는 첫 번째 장소로 돌아가 두 번째 장소에 포인트를 만든다. 그리고 이 포인트는 명령 을 묶는 것을 제어하는 데 쓰인다. 여러분은 인접한 명령을 묶지 말고 그 값를 내는 명령으로 묶어야 한다. 그 사이에 다른 명령이 있다고 할지라도 여러분은 그것들이 방해하지 못하도록 체 크해야 한다. 그리고 나서 묶은 것이 역동적으로 레지스터 할당이 된 후에야 비로소 어셈블리 코 드로 전환된다. Arizona컴파일러에서 명령 인식 자는 LEX로 발달되었다. 여러분의 기계묘사는 LEX가 문자열 로 확실한 명령을 인식시켜 주는 C함수로 변환하는 단순한 LEX프로그램이었다. 내가 가진 것은 LISP처럼 이 통용 법으로 쓰여진 기계묘사로부터 개발된 특별한 목적의 결정 트리를 대신하는 것이다. 그리고 이 인식기는 많은 다른 컴파일러 부분의 서브루틴으로 사용된다. 이 컴파일러는 PCC만큼 빨리 돌아간다. 이것은 PCC와 같은 방식으로 레지스터를 할당한 경우 에 그 실행을 말해두지 않았다면 눈에 띄게 빨리 돌아간다. 이러한 슈퍼 모드에서는 PCC보다 이 것이 훨씬 레지스터를 할당하는 작업을 더 잘한다. 나는 VAX에서 그것이 우수한 코드와 C 컴파 일러를 개발하는 것을 보았다. 68000에서 이 코드는 아직 이상적이지는 않다. 나는 가장 우수하지 않은 것을 초기 단계로 하 는 곳을 보았다. 앞으로의 일은 예측할 수 없기 때문이다. 그것은 초기 단계를 선택하고 그것이 가장 우수하게될 것이라고 생각되는 것을 한다. 그러나 실제로 그것이 다른 것을 했다면 후기 단 계는 무언가를 더 잘 할 수 있을 정도로 스마트해진다. 그러나 초기 단계에서는 후기 단계에서 어떻게 될지 알지 못한다. 그래서 나는 이런 것들에 대한 일을 해야한다. 때때로 이것은 불필요하게 레지스터가 무료로 되게 한다. 그것이 메모리를 종결시키면 레지스 터로 메모리를 복사해야 할 필요가 있다. 이것은 이미 할당된 레지스터를 취하고 기억장치의 홈 밖으로 일시적인 양을 버려야 한다. 물론 이것들이 레지스터가 아니라 메모리에 있기 때문에 명 령을 더 이상 무효로 만든다. 그래서 또 다시 체크해봐야 한다. 가끔씩 그것을 레지스터에 복사해 야 하나 실제로 그렇게 하지는 않을 것이다. 그래서 그것은 그것들을 무료로 놔두어야 할 것이어 서 그것이 할 수 있는 모든 레지스터를 이용하지 않을 것이다. (질문 : 여러분은 32000을 위한 코드 생성기를 가지고 있습니까?) 아직 아니지만 그것은 코드 생성기가 아니라 여러분이 필요로 하는 기계 기술이다. 모든 기계명령의 리스트는 LISP와 같은 형태로 기술된다. 그래서 실제로 인수가 VAX에서 보다는 68000에서 필요한 어떤 레지스터에 있 는 것을 제한하는 아이디어를 실행할 작업은 별도로 하도라도 VAX에서 68000으로 이 컴파일러 를 이식하는 작업은 며칠밖에 안 걸린다. 그래서 이식하는 것은 매우 쉽다. 컴파일러는 어셈블러 코드를 생성시켜 DBX가 원하는 포맷과 GDB의 특정한 내부 포맷에서 디 버그 하는 정보를 발달시킬 수 있다. 나는 이 컴파일러에서 필요로 하는 작업은 3가지 영역에 있 다고 본다. 하나 : 나는 UNIX컴파일러가 가진 것과 같은 "윤곽이 있는"기능을 첨가해야 한다. 둘 : 나는 더 스마트하게 이런 레지스터 할당을 만들어서 엉뚱한 것이 출력되지 않도록 할 것이 다. 셋 : 그 자체는 정확하게 컴파일 되더라도 아직 정확하게 작동하지는 않는 다양한 버그들이 있다. 나는 이것이 약 몇 달 걸릴 것으로 생각하고 컴파일러를 공개할 것이다. 존재하는 시스템의 크기가 있는 다른 부분은 핵심부분이다. ( 질문 : 중지? ) 그렇다. 나는 우리 가 쉬는 것도 잊어버리고 있다고 짐작한다. 왜 나는 단지 5분 정도 걸릴 핵심부분에 대해 이야기 하길 멈추지 않겠는가. 우리는 휴식을 가졌다. 핵심부분을 위해 나는 MIT리서치 프로젝트로 개발된 (내가 알기론 다른 것을 나타내지 않는) TRIX이라 불리는 시스템을 이용하도록 계획을 세웠다. 이 시스템은 Remote Procedure Call에 바 탕이 깔려 있다. 그래서 프로그램은 도메인이라 불린다. 각 도메인은 어드레스 공간과 다양한 기 능이 있다. 어떤 도메인은 "성능 이식"을 만들 수 있어서 다른 도메인에 이 이식을 보낼 수 있다. 시스템을 부르는 것과 다른 사용자 도메인을 부르는 것은 차이점이 없다. 사실 여러분은 여러분 이 가진 것을 부를 수 없다. 그래서 다른 사용자 프로그램에 의해 구현된 장치를 가지는 것은 매 우 쉽다. 파일 시스템은 명료하게 사용자 프로그램에 의해 구현될 수 있다. 네프워크를 통해 통신 하는 것도 명료하다. 여러분은 직접 다른 도메인을 부를 생각을 하지만 실제로 여러분은 네트워 크 서버 도메인을 부른다. 그것은 여러분이 부를 정보를 가지고, 이야기하려고 하는 도메인을 부 를 다른 서버 프로그램의 네트워크로 건네준다. 그러나 이것은 눈에 띄지 않게 일어난다. TRIX커넬은 실행되어 UNIX호환이 제한되지만 더 많이 필요하다. 현재 그것은 예전 UNIX시스 템이 하는 것과 같은 디스켓에 구조를 이용하는 파일 시스템을 가지고 있다. 이것은 UNIX로 파 일을 설치하기 때문에 디버그 하는 것을 더 쉽게 한다. 그러나 TRIX를 실행시키면 그 파일 시스 템은 내가 필요하다고 생각되는 어떤 기능도 가지고 있지 않다. 내가 믿는 기능은 다음과 같은 것이 첨가되어야 한다. 그것은 버전 수, 무삭제, 언제 어떻게 어 디서 파일이 타이프에 백업되느냐는 정보, 극소수의 파일을 대신하는 것이다. 나는 UNIX에서 파 일이 쓰여졌을 때 여러분이 이미 거기에 있는 것을 보는 것은 괜찮다고 생각한다. 예를 들면 여 러분은 얼마나 멀리 그것이 있나 보기 위해서 "열"을 사용할 수 있다. 그리고 프로그램이 사라지 면 여러분은 파일을 부분적으로 쓰여진 것을 볼 수 있다. 이런 것들은 모두 바람직하나 부분적으 로 쓰여진 출력은 결과적으로 여러분이 가지길 원했던 완전한 출력을 잡지는 못할 것이다. 그것 의 새로운 버전이 완전하고 정확하게 만들어질 때까지 예전 버전은 계속 쓰이게 될 것이다. 이것 은 새로운 버전이 가지는 이름 아래서가 아니라 파일 시스템 안에서 볼 수 있다는 것이다. 그것 이 끝났을 때 다시 이름을 받게될 것이다. 각 사용자 프로그램이 이것을 확실하게 해야함에도 불 구하고 ITS에서 일어난 방법대로 된 것이다. 사용자 프로그램에 UNIX호환을 위해 그것은 눈에 보이지 않게 일어난다. 나는 UNIX사용자 프로그램에 버전 수를 맞추려고 하는 괴상한 방식을 가지고 있다. 일반적인 방법으로 이름을 짓는다면 내재된 버전 수로 남겨진 파일 명을 짓는다는 것이다. 그러나 만약 여 러분이 정확하게 이름을 지으려고 한다면, 사용할 버전을 원하거나 전혀 버전을 원하지 않기 때 문에, 여러분은 그것의 끝에 포인트를 두어야 한다. 그러므로 여러분이 파일 명을 "FOO"라 했다 면 그것은 "FOO로 존재하는 버전을 찾고 가장 마지막의 것을 취해라"는 뜻을 나타낸다. 그러나 "FOO."으로 했다면 그것은 "정확히 이름이 FOO인 것을 사용하고 다른 것을 취하지 말라."는 뜻 이 된다. "FOO.3"이라고 하면 그것은 "이름이 FOO.3을 사용해라"라는 뜻이며 FOO.3은 FOO버전 이 3인 것을 나타낸다. 출력에서 여러분이 "FOO"라고 하면 그것은 명백하게 "FOO"의 새로운 버 전을 만들어내나 "FOO."이라고 하면 그것은 정확히 "FOO."으로 이름지어진 파일을 쓰는 것이다. 여기에 모든 항목들 외에 작업하는데 연관된 시도가 있다. 해결되지 않은 문제가 있는지, 어떤 UNIX소프트웨어가 그것에 포인트로 이름을 지어줌에도 불구하고 깨어지는지를 같은 방식으로 얻어 주려고 하는 것이다. 나는 여러분이 이름이 포인트로 끝난 출력을 위해 파일을 열 때 즉시 그 이름으로 열기를 바란 다. 그러면 여러분은 같은 UNIX 방식을 얻을 수 있어 부분적으로 쓰여진 출력을 즉시 볼 수 있 을 것이다. 반면에 여러분이 포인트로 끝내지 않은 이름을 출력할 때 새로운 버전이 그것을 종결 했을 때 나타나게 될 것이다. 만약 작업이 사라지거나 시스템이 충돌이나 그와 같은 어떤 것 때 문에 종결된다면 그것은 다른 이름으로 있게 될 것이다. 그리고 이 생각은 어떤 디렉토리가 다음과 같은 파일을 가지고 있다면 포인트로 끝나지 않은 이름에 그것의 버전 수없이 모든 이름을 붙이도록 "별 붙이기"로 연결될 수 있다. foo.1 foo.2 bar.8 내가 "*"라고 말하면 그것은 다음과 같다. foo bar 왜냐하면 그것은 모든 이름을 취하고 그 버전을 없애 구분된 모든 것을 취하기 때문이다. 그러나 내가 "*."라고 하면 그것은 모든 정확한 이름을 취하고 각각에 포인트를 놓아 그것들에 맞추는 것이다. 이것은 존재하는 모든 개인적인 버전을 위해 모든 이름을 나에게 준다. 그리고 비슷하게 여러분은 "*.c"와 "*.c."의 차이점을 볼 수 있을 것이다. 전자는 여러분에게 기본적으로 모든 ".c" 파일을 버전 없이 줄 것이다. 후자는 여러분에게 모든 버전을 줄 것이다. 이것은 실제로 작동을 안 하므로 여러분은 "*.c.*."라고 해야 할 것이다. 나는 여기서 이 항목을 해결하지 못했다. 이중 장치는 사용자가 볼 수는 없지만 어느 정도 입력할 호환이 있다. 그것은 적당한 명령으로 디스켓에 모든 정보를 써서 파일 디스켓에 방해받지 아니하고, 어떤 때에는 멈출 수 있도록 한다. 아무도 그것을 경시할 수 없다. 다른 아이디어는 매우 과다한 정보이다. 나는 이것을 할지 안 할 지 확신할 수는 없으나 각 파일을 그것의 이름으로 모두 저장시키는 방법에 대한 생각이 있다. 그리고 나면 디스크의 어떤 디렉토리가 사라져도 디스크의 남은 내용물로부터 그것을 재구성할 수 있을 것이다. 또한 나는 파일의 어떤 부분을 조금씩 업데이트하는 방법을 알고 있다. 만약 여러분이 어떤 파 일의 하위영역을 읽는 방식의 새로운 데이터로 대체하려면, 그 파일은 예전 데이터만 보이거나 아니면 새로운 데이터만 보일 것이다. 나는 어떤 잠금장치가 없어도 그렇게 할 수 있다고 믿는다. 네트워크를 지지하기 위해 나는 이 시스템이 TCP/IP를 실행하려고 했다. 나는 또한 UUCP와 같은 것을 얻기 위해 KERMIT를 사용하는 것이 가능하다고 생각한다. 내가 믿는 쉘은 이미 쓰여졌다. 그것은 두 개의 모드를 가지고 있는데 하나는 BOURNE쉘을 모 방한 것이고 다른 하나는 같은 프로그램에서의 C쉘을 모방한 것이다. 나는 아직 그것의 복사 본 을 받지 않았다. 나는 그것을 얼마나 해야 하는지를 알지 못한다. 또한 많은 다른 유틸리티도 존 재한다. MAKE가 존재하고, LS, 분포되고 있는 BISON이라 불리는 YACC대체물이 있다. LEX 에 꽤 유사한 것이 있지만 그것은 전적으로 호환불가능하고 어떤 작업이 필요하다. 그리고 일반 적으로 이루고 있는 것은 이미 이루어진 것 보다 훨씬 덜 낫다. 그러나 우리는 도와 줄 사람이 여전히 많이 필요하다. 사람들은 항상 나에게 물어 본다. "언제 그것이 끝납니까?" 물론 나는 그것이 언제 끝날지 알 수 없으나 나에게 그렇게 물어보는 것은 잘못이다. 만약 여러분이 그것에 보답하기로 계획했다면 여러분이 얻으려는 것을 정확하게 알기 원하는 것은 당연할지도 모른다. 그러나 여러분이 그것에 보답을 하지 않는다면 여러분은 이렇게 물어뵈야 한다. "여러분은 어떻게 그것을 곧 끝낼 수 있 습니까?" 나는 MIT파일에 있는 프로젝트의 리스트를 가지고 있다. 도와주는 사람들은 나에게 이 인터넷 주소로 메일을 보낼 수 있었고 나는 프로젝트의 리스트를 다시 보낼 수 있었다. (나는 분 필을 보는 이 작업을 과연 할 수 있을 지에 의문을 가졌다.) 이것은 읽을 수 있는가? 이것은 (단 지 튀는 공을 따르는)"RMS@PREP.AI.MIT.EDU" 이다. 그리고 쉬자. 쉬고 난후에 나는 실제로 어떤 인수가 있는 것을 말할 것이다. 그래서 지금은 가지 말아라. 여러분이 남는다면 여러분은 실 습을 하고 싶을 것이다. [15분 간 쉬었다.] 나는 어떻게 GNU소프트웨어를 복사할 수 있었는가를 알려주도록 요청받았다. 한 가지 방법은 복사 본을 가진 친구를 알아서 그것을 복사하는 것이다. 그러나 복사 본을 가진 친구를 알지 못 하고 인터넷에도 없다면 그것을 FTP할 수 없으며 항상 분포된 테이프에 주문을 하여 Free Software Foundation에 약간의 돈을 보내야 한다. 물론 무료 프로그램은 무료로 분포된 것과 같 지 않다. 나는 이것을 나중에 자세하게 설명할 것이다. 여기 나는 잘 프린트된 다양한 EMACS매뉴얼을 가지고 있다. 그것은 사진식자 되었고 offset 프린트되었다. 여러분이 EMACS분포에서 온 소스로부터 그것을 프린트 할 수 있다 하더라도 여 러분은 Free Software Foundation으로부터 이것들을 복사할 수 있다. 여러분은 나중에 와서 이것 을 볼 수 있다. 또한 이것은 어떤 정보를 복사하도록 주문할 수 있다. 그리고 [앞의] 그림은 가끔 씩 즐겨진다. [GNU에 오른 RMS에 의해 쫓아진 특징을 포인트 하는] 이것은 놀랄만한 소프트웨 어 저장소이다. 나는 잠시 그에 관해 이야기하겠다. 소프트웨어는 비교적 새로운 현상이다. 아마 30년 전부터 소프트웨어가 분포되기 시작했을 것 이다. 누군가 그것에 관한 사업을 만들자는 제안을 가진 것은 약 20년 전이었다. 그것은 사람들이 했던 방식이나 누가 무슨 권리를 가졌냐에 대해 전통이 없던 영역이었다. 그리고 분석적으로 전 통을 가져올 수 있는 여러 가지 아이디어들이 있었다. 유럽에서 많은 교수들이 좋아하는 한 분석은 프로그램과 수학 사이에 있는 것이다. 프로그램은 큰 공식이다. 전통적으로 수학적인 공식을 소유한 사람은 아무도 없다. 누구나 그것을 복사하고 사용할 수 있다. 보통 사람들에게 가장 의미 있는 분석은 방식에 의한 것이다. 대부분의 프로그램과 같이 여러 분의 보통 삶에서 가진 방식은 무언가를 할 수 있는 명령이다. 그 방식이 자동적으로 기계에 의 해서가 아니라 사람에 의해 작동되기 때문에 차이점이 있는 것이다. 소스 코드와 방식을 위한 옵 젝트 코드 사이에는 차이점이 없고 여전히 가장 비슷하다. 어떤 것도 그 자체의 한 방식을 가지 지 않는다. 그러나 선택된 분석은 복사본을 있는 책을 가지고 하는 분석이었다. 왜 이런 선택을 했는가? 왜냐하면 특정한 선택을 만들어 얻은 대부분을 가진 사람들이 결정을 따랐기 때문이다. 프로그램 을 사용하지 않는 사람들이 아니라 프로그램을 쓰는 사람들이 완전히 자기중심의 형태로 결정하 였다. 결과적으로 그들은 프로그램 분야를 추한 것으로 변하게 했다. 내가 이 분야에 들어서서 1972년 MIT에서 일하기 시작했을 때 우리가 개발한 프로그램이 공유 되지 않았다는 생각은 전혀 거론되지도 않았다. 스탠포드나 CMU나 누구에게나 DIGITAL까지도 마찬가지 였다. 나는 자주 PDP-11크로스 어셈블러 같은 DIGITAL시스템으로부터 프로그램 조각 을 가지고 ITS를 작동하게 하는 많은 특징을 첨가하였다. 그 프로그램을 복사한 것은 아니었다. 이것이 변하기 시작한 때는 70년대 말이었다. 나는 우리가 가진 공유의 정신에 의해 아주 감동 받았다. 우리는 우리가 바라던 것을 사람들이 사용할 수 있어서 기뻐했다. 그래서 내가 처음으로 EMACS를 발달시켰을 때 사람들은 그것이 MIT외부로도 사용되기를 원했다. 나는 그것이 EMACS"친교"에 속하고 EMACS를 사용하기 위해서 여러분이 친교의 멤버가 되어야 한다고 말 했다. 이것은 여러분이 만든 모든 향상에 기여할 책임이 있다는 것을 뜻한다. 오리지널 EMACS 에 대한 모든 향상은 나에게로 다시 보내져서 EMACS의 새로운 버전과 합쳐질 수 있었다. 그래 서 공동체에 있는 누구나 그것으로부터 이익을 볼 수 있었다. 그러나 이것은 SCRIBE가 CMU에서 개발되었을 때 파괴되어서 어떤 회사에 팔렸다. 이것은 여 러 대학에 있는 우리를 매우 방해했다. 왜냐하면 우리는 이것이 누구나에게 유혹적이고 너무 이 익적이어서 비협조적으로 되는 것을 보았기 때문이다. 협조를 여전히 믿는 우리 중 일부는 우리 와 협조하는 사람들을 쫓아내려는 생각을 아예 하지도 ㅇ았다. 나중에는 강한 의식을 가지 우리 가 끝까지 단합할 때까지 사회의 여러 구성원들과 교류하려고 했었다. 이것이 일어난 일이다. 프로그램의 분야는 지금 누구나 그 분야의 다른 사람들과 사용자에게 좋지 않은 방법으로 많은 돈을 번다고 여겨지는 추한 것으로 되었다. 나는 독점 소프트웨어의 실행이 사회에 물질적으로 오염되고, 정신적으로 해롭고, 악의적이라는 것이 확증되기를 바란다. 이 모든 세 가지는 서로 관련되었다. 다른 사람에게 물질적으로 해로운 실행을 하는 컴퓨터에는 사회의 모든 멤버가 연루될 수 있기 때문이다. 그리고 매 때마다 여러분 은 여러분 자신에게 좋은 것을 한다. 여러분이 하는 것은 여러분을 도와주려는 다른 사람에게 상 처를 줄 수도 있다. 여러분은 그런 것을 막기 위해 냉소적으로 되어야 한다. 그리고 그것은 고의 로 작업한 것을 오염시키고 사회적 부패를 야기하기 때문에 악의적이다. 첫 번째로 나는 소프트웨어를 독점하는 데서 오는 해로움과 일반적으로 사용하는 정보에 대해 서 설명하기를 원한다. 그리고 나서 그런 실행을 하는 변수에 반증을 할 것이다. 나는 그런 현상 과 싸우는 방법에 대해 이야기하겠다. 정보를 소유하는 생각은 세 가지 수준으로 해롭다. 세 가지 수준에서 물질적인 해로움은 정신 적인 해로움으로 대응이 된다. 첫 번째 수준은 프로그램의 사용을 감소시킨다는 것이다. 그것은 사람들이 프로그램을 덜 사용 하게 하지만 사실은 사람들이 덜 사용할 프로그램을 만드는 것이다. 프로그램의 사용에 대한 값 이 이 소프트웨어 저장관리자가 좋아할 정도로 자극적이라면 사람들은 그 프로그램을 사용하지 않을 것이다. 이것은 낭비이다. 예를 들어 많은 사람들 중에 반만이 그것에 값을 치르고 프로그램 을 사용한다면 프로그램은 그 반이 낭비되는 것이다. 작업의 같은 양이 딱 반만큼의 이득을 만 만들어내게 된다. 사실은 프로그램을 사용하기 원하는 사람들은 그 프로그램의 주위를 맴돌 필요는 없다. 왜냐하 면 누구나 완전하게 그것을 복사해서 얻을 수 있기 때문이다. 여러분이 프로그램을 쓴 다음 해야 할 것은 그 자리에서 사람들이 원하는 것을 할 수 있도록 해야한다는 것이다. 그러나 그것은 일 어난 일이 아니다. 누군가가 프로그램을 공유하는 것을 고의적으로 방해하려는 대신에 도와주는 사람에게 압력을 주기 때문이다. 사용자가 노출되지 않은 동의의 신호를 보낼 때마다 그는 그의 동료 사용자에게 팔아 버린다. 규칙을 따르고 "나는 이 프로그램을 좋아한다. 나의 이웃도 이 프 로그램을 좋아할 것이다. 나는 우리 둘 다 그것을 가지기를 원한다. "고 말하는 대신에 그는 다음 과 같이 말한다. "그렇소 나는 그것을 나에게 주시오. 나의 이웃을 타도한다! 나는 당신들에게 그 것이 나의 이웃과 멀리 떼어지도록 도와주겠다. 단지 나에게 달라." 이 정신은 정신적으로 해로운 것이다. 이렇게 말하는 태도이다. " 나의 이웃을 타도한다. 나에게 복사본을 달라. " 나는 나에게 무언가의 복사본을 가지게 하지 않겠다고 말하는 이들에게 달려갔다. 왜냐하면 그 들이 어떤 비밀스런 동의의 표시를 했기 때문이다. 누군가 나에게 그것과 같은 것을 요청했을 때 그것이 잘못되었다는 것을 알았다. 나에게 일어났을 때 나를 매우 화나게 하는 것과 같은 일을 남에게도 할 수는 없었다. 그러나 이것은 해로운 수준의 하나일 뿐이다. 두 번째 수준은 사람들이 프로그램을 변화시키길 원할 때이다. 왜냐하면 사람들이 사용하기 원하는 프로그램은 정말로 올바르지는 않기 때문이다. 사람들은 조금 덜 짠 말을 하거나 푸른 고추를 더하면서 다양한 방식을 원하듯이 필요한 효과를 얻기 위해서 프로그램도 변화시키길 원한다. 소프트웨어 소유자들은 실제로는 사람들이 프로그램을 변화시키느냐에 신경을 쓰지 않는다. 그 러나 그들의 목적은 사람들을 막는데 있다. 일반적으로 소프트웨어가 독점되었을 때에는 소스를 구할 수 없고 그것을 변화시킬 수 없다. 이것은 사용자에게 좌절을 주고 프로그래머에게는 작업 을 낭비시킨다. 예를 들어 프로그래머로서 새로운 프로그램을 쓰며 은행에서 수개월 동안 일하는 방법을 얘기했었던 친구가 있었다. 거의 사업적으로 올바르고 유용한 프로그램이 있었는데 그들 이 필요하기에 꽤 적합한 것은 아니었다. 사실은 그들에게는 쓸모가 없었다. 그들이 필요한 것을 하려는 변화의 양은 알마 안되었지만 프로그램의 소스가 유용한 것이 아니었기 때문에 그것은 불 가능했다. 그 친구는 처음부터 잘못 시작되어 작업의 낭비를 가져왔다. 그리고 우리는 세상의 모 든 프로그래머의 일부가 이런 방식으로 그들의 시간을 낭비하고 있다고 추측할 수 있었다. 그리고 적당한 프로그램이 만들어지는 상황이 있으나 불편할 수도 있다. 예를 들어 처음으로 우리가 MIT에서 그래픽 프린터를 가졌을 때, 우리는 소프트웨어를 쓰고 많은 훌륭한 특징을 놓 았다. 그 예로는 프린트하는 것을 끝냈을 때 여러분에게 메시지를 보내고 프린터의 종이가 떨어 져 작업이 대기되었을 때에도 메시지를 보낸다. 우리가 원하는 많은 것들이 이렇게 된다. 우리는 그래서 더욱 훌륭한 첫 번째 레이저 프린터의 하나인 그래픽 프린터를 갖게 되었다. 그러나 소프 트웨어는 Xerox에 의해 공급받아서 그것을 바꿀 수는 없었다. 그들은 이런 특징을 놓지 않아서 우리가 할 수 없었던 것이다. 그래서 우리는 "반만 작동하는" 것을 만들어내야 했다. 그리고 우리 가 그것을 고칠 수는 있었으나 허용되지 않았기 때문에 매우 절망했다. 우리는 방해 받았다. 컴퓨터를 사용하는 많은 사람은 컴퓨터가 미스터리이고 그것이 하는 일을 모르겠다고 말한다. 어떻게 그들이 알 수 있을까? 그들은 사용하는 프로그램을 읽을 수 없다. 사람들이 어떻게 프로 그램이 쓰여지고, 그들이 하는 것을 프로그램이 어떻게 하는지를 배우게 하는 한가지 방법은 소 스 코드를 읽는 것이다. 그래서 나는 컴퓨터를 도구로서 여기는 사용자들의 생각이 소스코드를 비밀로 남겨두려는 결과 인 자기 만족적인 예언이 아닌지가 궁금했다. 이런 종류의 물질적 해로움과 동반하는 정신적 해로움은 자기 충족의 정신에 있다. 어떤 사람 이 많은 시간을 컴퓨터 시스템을 사용하는데 썼다면 그 컴퓨터 시스템의 형태는 그들이 살고 있 는 도시가 된다. 우리의 집과 가구가 있는 것처럼 우리가 사용하는 컴퓨터는, 우리에게 맞도록 변 화시킬 수 없다면, 우리가 사는 것을 결정한다. 그렇게 되면 우리의 삶은 실제로 다른 것들에게 지배를 받게 된다. 이것을 보는 사람은 어떤 식으로든 혼란스럽게 된다. "이것을 바꾸려고 하는 것은 아무 소용이 없다. 그것들은 항상 나쁘게만 된다. 어떤 포인트도 그것을 충돌시키지 않는다. 나는 나의 시간을 가질 것이다. 그것이 과도하게 되었을 때 나는 멀리 가있어서 그것을 더 이상 생각하지 않을 것이다. " 비열정적인 그런 정신은 여러분이 공공심을 느꼈을 때 물건을 더 좋게 만들도록 허용되지 않아서 나타난 결과이다. 세 번째 해로운 수준은 소프트웨어를 개발하는 사람들 사이의 상호작용에 있다. 지식의 어떤 분야는 다른 사람들의 작업을 세웠을 때 진보되지만, 정보의 소유는 명백하게 누구나 그렇게 하 지 못하게 한다. 사람들이 다른 사람들의 작업을 세운다면, 소유심은 수그러 들 것이다. 그러면 그들은 그 분야의 새로운 출발을 확신하게 되고 그 분야의 발전을 보여줄 것이다. 그래서 우리는 다음과 같은 것을 볼 수 있다. 전에 얼마나 일을 했는가를 이해하는 이득이 없 이, 다른 회사들이 얼마나 많은 스프레드시트 시스템을 만들었는가? 그것은 사실이다. 처음으로 쓴 스프레드시트는 완전하지 않았다. 그것은 어떤 종류의 컴퓨터에서만 작동했고 가장 가능한 방 법으로는 일을 수행하지 못했다. 어떤 이들이 그것의 일부분을 다시 쓰려는 이유는 다양하다. 그 러나 그들이 정말로 향상시킬 부분을 다시 쓴다면 그것은 작업을 훨씬 덜 하게 만들 것이다. 여 러분은 시스템의 한 면을 더 잘 만드는 방법을 알고 있을지도 모르나 같은 시스템의 또 다른 면 은 잘 알지 못할 지도 모른다. 사실 이런 문제를 크게 다루는 것이 더 나았을 것이다. 여러분이 좋아하는 부분을 취하고 영감을 얻은 부분만을 다시 쓴다면, 여러분은 완전히 새로운 시스템을 쓰는 것보다 훨씬 덜한 작업으로 모든 방법에서 더 뛰어난 시스템을 가지게 될 것이다. 우리는 시스템이 완전히 다시 쓰여지면 이익을 볼 것이라는 것을 알지만, 그것은 여러분이 첫 번째로 오 래된 것을 읽을 때만 이다. 그리하여 프로그래밍 분야에 있는 사람들은 그들의 많은 시간을 허비하고, 우리가 원하는 것보 다 더 프로그래머를 위한 것을 만든다. 왜 프로그래머에겐 결점이 있는가? 왜냐하면 재능적인 부 로 프로그래머들은, 우리가 하면 두 배가 필요한 것처럼 보여도, 그들이 하는 일에 반을 허비한 다. 사람들이 지능적인 부의 구조를 지적할 때 이렇게 이야기한다. "거대한 고용의 통계량을 보아 라. 얼마나 이 사업이 큰가를 보아라."실제로 증명된 것은 사람들이 많은 시간과 돈을 허비하고 있다는 것이다. 그들은 프로그래머의 생산성을 향상시키는 방법을 찾는 것에 대해 이야기할 때면 프로그래머의 생산성을 삭감시키는 확실한 것을 제거하는 것을 제외하고는 더 우월한 도구에 연 관된 것에 기뻐한다. 왜냐하면 그것은 고용된 프로그래머의 수를 감소시키기 때문이다. 거기에는 약간 정신분열증적인 것이 있다. 물질적인 해로움에 부합하는 정신적인 해로움은 과학적인 협동의 정신에 있다. 그것은 매우 강 해서 전쟁중인 마을에 있더라도 과학자들은 협동하기를 계속한다. 그들은 그들이 하고 있는 것이 전쟁과는 무관하고 오랜 기간 인류에게 이익을 준다고 믿기 때문이다. 최근에 사람들은 더 이상 인류를 위한 장기적인 이익에 신경을 쓰지 않는다. 프로그램의 사용을 방해하는 아이디어를 얻기 위해 우리가 샌드위치를 가졌다고 상상해보자. 여러분은 그것을 먹지만 그것은 소비되지 않는 것이다. 여러분과 다른 사람이 같은 샌드위치를 어떤 시간에 먹을 수 있다. 그것은 항상 원래대로 조장되도록 남아 있게 된다. 우리가 이 샌드위치로 하려는 가장 좋은 일은 배고픈 사람들이 있는 주위에 그것을 옮겨 놓는 것이다. 가능한 한 수개월 동안 그것을 가져와서 가능한 많은 사람들이 그것을 먹게 한다. 반드시 우리는 이 샌드위치를 먹는 값을 가지지 않아야 한다. 왜냐하면 사람들은 그것을 먹을 수 없어서 낭비하게 될 수도 있기 때문이다. 프로그램은 동시에 먹혀지는 많은 다른 장소에 있어서 차례로 다른 사람들에게 이용되기 때문 에 샌드위치와 같다. 그러나 이 샌드위치가 모두에게 어디에서나 영원히 먹기에 충분히 있기만 하면 누군가 그것을 소유할 것이라고 믿기 때문에 그런 일은 일어나지 않게 된다. 프로그램을 소유할 수 있다고 믿는 사람들은 일반적으로 이것의 변수에 두 줄을 놓는다. 첫 번 째 줄은 다음과 같다. "나는 그것을 썼고 그것은 나의 유년기이다. 나의 마음과 영혼이 그것에 있 다. 누가 나에게로부터 그것을 뺏아 갈 수 있는가? 그것이 어디로 가더라도 그것은 나의 것이다. 나의 것!!" 대부분 그것이 그들이 일하는 회사에 속한다고 말하는 것에 동의한다. 그래서 이것은 믿는 것이 중요하다고 여러분 자신에게 쉽게 말할 수 있는 것 중의 하나라고 본다. 그러나 여러분은 여러분 자신에게 전혀 문제가 되지 않는다고 쉽게 확신할 수 있을 것이다. 보통 이런 사람들은 사람들이 어떻게 프로그램을 변화시키는지를 제어하는 권리를 요구하는 변 수를 사용한다. 그들은 이렇게 말한다. "아무도 나의 예술 작품을 혼란시킬 수 없을 것이다." 요리 를 계획한 접시를 만든 사람이 그것이 자신의 작품이므로 여러분이 요리를 하는 것을 제어할 권 리가 있다고 상상해보자. 여러분은 소금을 생략하기를 원하나 그는 이렇게 말할 것이다. "오, 안 됩니다. 나는 이 접시를 만들었고 많은 소금이 여기에 있어야 합니다." " 그러나 나의 의사는 내 가 소금을 먹는 것은 안전하지 않다고 했소. 나는 어떻게 해야하나?" 명백하게 프로그램을 사용하는 사람은 사건에 더 가까이 있다. 프로그램의 사용은 그에게 매우 직접적으로 영향을 준다. 반면에 프로그램을 쓴 사람과는 추상적인 관계일 뿐이다. 그러므로 사람 들에게 가능한한 자신의 삶을 잘 제어할 수 있도록 하기 위해 이러한 것들을 결정하는 사용자가 있어야 한다. 그들이 만드는 변수의 두 번째 줄은 경제적인 것이다. "어떻게 사람들이 프로그램에 값을 지불 하는가?" 라고 말하는 것에는 실제로 약간의 출판물이 있다. 그러나 그들이 말한 많은 것은 혼란 스럽다. 혼란은 다음과 같이 말하는 것과는 전혀 같지는 않다. "우리가 프로그래밍을 하는 많은 사람들을 가지기를 원한다면 그들이 다른 방식으로 생계를 꾸려갈 필요가 없도록 잘 배치해야 한 다."라고 한편에서 말하면 다른 한편에서는 다음과 같이 말할 것이다. "우리는 현행의 시스템을 가지는 것이 필요하다. 여러분은 프로그래밍으로 자본을 모을 필요가 있다." 최근에 적어도 미국 에서는 생계를 이어가는데 필요한 비용과 어떤 종류의 프로그래머를 만드는 자본 사이에 큰 차이 점이 있다. 그들은 항상 다음과 같이 말한다. "내가 어떻게 먹을 수 있는가?" 그러나 문제는 실제 로 어떻게 "그가 먹겠는가?"가 아니라 "어떻게 그가 김밥을 먹겠는가?"이다. "내가 나의 머리 위 에 지붕을 어떻게 만들겠는가?" 라고 하지만 실제 문제는 "그가 어떻게 콘도에 있을 수 있는가? "이다. 현행의 시스템은 소프트웨어 개발에 투자했던 사람들에 의해 선택되었다. 그것은 누구나 시스 템을 개발하는 노력을 지지할 자본을 따라갈 수 있는 한가지 방법이기 때문이 아니라, 그들에게 가능한 최대의 자본을 벌게 할 가능성을 주기 때문이다. 사실, 최근 10년 내지는 15년 전에 다른 방법으로 소프트웨어의 개발을 지지하는 것은 일반적이었다. 예를 들어 70년대 초반에 무료였던 DIGITAL오퍼레이팅 시스템은 그 일에 보수를 받던 사람들에 의해 개발되었다. 많은 유용한 프로 그램이 대학에서 발전되었다. 최근에 이 프로그램들은 팔렸으나 15년 전에 그것들은 무료였다. 아 직 사람들은 그 작업에 보수를 받는다. 여러분이 얼마나 사용했는가가 문제가 되지 않는 한 번 세워진 프로그램이나 무한한 샌드위치 나 짐같은 것을 가지고 있을 때에는 비용이 들지 않는다. 우리가 그것을 사용하는 것에 값을 지 불하지 않는다면 더 잘 그렇다. 그리고 우리가 지금 개발하여 세운 것에 사람들이 지불하는 것들 이 많이 있다. 예를 들어 모든 길이 밖에 있다. 값을 지불하지 않고 프로그램을 하는 사람들을 찾는 것은 매우 쉬운 일이다. 값을 치르지 않고 길을 세울 사람을 찾는 것은 실제로 불가능하다. 길을 만드는 것은 프로그래밍과 같이 창조적이고 재미있지 않다. 그러나 우리는 밖에 많은 길을 가지고 있다. 우리는 그들에게 돈을 지불하게 해야 한다. 우리가 다음과 같이 말하는 것보다는 훨 씬 나을 것이다. "회사를 차려서 길을 만들고 톨게이트를 놓아 다른 길의 코너에 갈 때마다 다른 톨게이트에 돈을 지불하게 하자. 그리고 나서 회사는 그들의 길에 놓을 좋은 장소를 잡는다. 그들 은 이익을 볼 수 있으며 다른 것들은 파산하게 될 것이다." 누군가가 무엇을 저장함으로 많은 돈을 버는 방법을 알아갈 때마다 재미있는 점이 있다. 그 분 야에서 일하는 것에 열정적이고 열망적인 많은 사람들에 대한 하나의 의문은 어떻게 그들이 모두 삶의 어느 정도를 잡을 수 있는가하는 것이다. 예를 들어 우리가 수학을 생각해보면 누군가를 단 순히 수학자로 만들기 위해 자본을 적립하는 것보다 단순히 자신이 수학자가 되기를 원하는 사람 들이 더 많을 것이다. 여러분이 자본을 적립해도 많은 것을 얻지 못할 것이고 그들도 잘 되지 않 을 것이다. 음악가에겐 더욱 치명적이다. 나는 보통 음악가가 되려고 매사추세츠에서 사람들이 얼 마나 많은 시간을 들이는지에 대한 통계량을 보았다. 소득은 중간 수입의 반 또는 거기에도 못 미치게 된다. 그것은 겨우 살아가기에 충분할 정도로 어렵다. 그러나 그렇게 하려고 하는 이들은 많다. 그리고 다소 무엇을 하는데 값을 잘 지불 받는 것이 일반적으로 가능하게 될 때 이런 모든 사람들은 사라질 것이다. 사람들은 다음과 같이 말하면서 시작할 것이다. "누구나 그것에 값을 잘 지불해야지만 그것을 할 수 있다." 그리고 나는 프로그래밍의 분야에서 이러한 일이 일어나는 것을 보았다. 인공지능 연구실에서 일하면서 아주 약간 값을 받는 것을 좋아하는 류의 사람들은 일년에 5만 달라보다 덜 받고 일하 기를 바라지 않는다. 어떤 일이 일어났는가? 돈을 많이 벌 가능성을 가지기 전에 매달리는 사람 들과 그들과 유사한 일을 하는 다른 사람들은 그것에 많은 돈을 지불 받는 것을 보았을 때에 그 들은 서로 같다고 느끼면서 아무도 예전의 방법대로 계속하려고 하지 않을 것이다. 이런 일이 일 어난 후에 사람들에게 많은 돈을 지불하는 것이 단 하나의 방법이라고 더욱 생각하게되었다. 그 러나 그렇지는 않다. 많은 돈을 버는 방법이 존재하지 않는다면 여러분은 약간의 돈으로그렇게 할 사람을 두어야 할 것이다. 특히 그것이 창조적이고 재미있을 때 말이다. 나는 인공지능 연구실의 독특한 세계가 파괴된 것을 보았고 소프트웨어를 파는 것이 주요 원인 이라는 것을 보았다. 또한, 내가 전에 설명한 것처럼, 그런 공동체를 가지기 위하여 무료 소프트 웨어를 어떻게 필요로 하는지를 보았다. 그러나 더 그것에 관해 생각하고 나서 나는 이웃에 파는 사람들을 압력하는 것과 사회적 부패를 조장하는 것에 의해 소프트웨어의 저장이 모든 사회에 상 처를 준다는 것을 알았다. 누군가가 거리에 있는 동안에 사람들이 보는 정신은 상처를 받을 것이 고 아무도 모를 것이다. 그것은 우리가 하루 종일 디스플레이 하는 주위에 많은 회사를 볼 수 있 는 정신이다. 그리고 나의 선택은 명백했다. 그 선택은 그 체제에 동화되어 내가 사는 동안 했던 것에 불행을 느끼느냐, 아니면 그것과 싸우는 것이냐는 것이다. 나는 그것과 싸우기로 결심했다. 나는 소프트웨어를 공유할 공동체를 다시 세우고 보통 정보를 저장하는 현상을 끝내려고 했다. GNU시스템은 이것의 끝을 나타내는 것이다. 그것은 사회적 끝에 대한 기술적인 의미이다. GNU 시스템으로 나는 사용자들이 소프트웨어 저장의 위협에 대해 대처할 수 있기를 바란다. 당장 저장소는 사람의 컴퓨터를 쓸모 없게 하는 힘을 기본적으로 가진다. 약 50여년 전에 마피 아에 있던 미국 사람들이 사용하곤 했었다. 그들은 저장하고 불법으로 된 것을 만들었다. 그들은 기면서 이렇게 말했다. "여기에 있는 많은 곳들이 나중에는 타버릴 것이다. 여러분은 여러분의 장 소가 타버리기를 원하지 않을 것이다. 그렇지 않는가? 우리는 화재에 대해 여러분을 보호할 수 있다. 여러분은 한 달에 천 달러를 우리에게 줘야 한다. 우리는 여러분이 여기에 불을 놓지 않는 다고 확신한다." 이것은 "보호 협박"이라고 부른다. 우리는 사람들이 이렇게 말하는 것을 듣는다. "여러분은 여기에 좋은 컴퓨터를 가지고 있고 거기서 사용할 프로그램이 있다. 여러분이 이들 프 로그램이 사라지지 않기를 원하고 후에 경찰이 오기를 원하지 않는다면 여러분은 나에게 천 달러 를 지불하라. 그러면 나는 여러분에게 라이선스로 이 프로그램의 복사본을 주겠다." 이것은 "소프 트웨어 보호 협박"이라고 한다. 실제로 그들이 하는 모든 것은 모든 이들과 함께 된 것을 필요한 것으로 하는 것을 방해하는 것이다. 그러나 그들은 우리에게 남은 것만큼 그들 자신에게 유용한 기능을 제공하려는 척을 한 다. 내가 바라는 것은 소프트웨어를 가진 마피아 놈들이 "여러분 컴퓨터에 이 프로그램을 없애기 를 원하는가?"라고 말했을 때, 사용자가 이렇게 말하는 것이다. "난 여러분이 무엇을 해도 두렵지 않다. 나는 자유로운 GNU소프트웨어를 가졌고 지금 여러분이 나에게 할 수 있는 것은 아무것도 없다."라고 말이다. 독점 소프트웨어를 제공하는 사람들이 정당화하는 것은 사람들에게 물건을 만들게 하는 자극을 주는 아이디어이다. 나는 다른 사람들이 사용하는 것을 만들어내서 돈들 버는 개인 기업의 생각 을 지지한다. 그러나 지금은 소프트웨어의 분야에선 혼란을 야기시킨다. 독점 프로그램을 만드는 것은 동일한 프로그램을 만들어 그것을 무료로 하는 것처럼 사회에 공헌하는 것이 아니다. 왜냐 하면 프로그램을 쓰는 것은 사회에 잠재적으로 공헌을 하는 것이기 때문이다. 사회에 공헌하는 것은 프로그램이 사용될 때만 일어난다. 여러분이 사용되는 것으로부터 프로그램을 보호하려면 공헌은 실제적으로 일어나지 않는다. 그래서 누구나 만드는 것을 자극하는 것을 가진 독점적 프 로그램은 사회에 공헌하는 것이 아니다. 우리가 원하는 공헌은 무료 소프트웨어이다. 우리의 사회 는 유용하지 않는 것에 자극을 주고 유용한 것에 자극을 주지 않는다면 혼란해 질 것이다. 개인 기업의 기본적인 생각은 따라지지 않는다. 여러분은 사회가 신경증적이라고 말할 수도 있다. 결국 개인이 개인적으로 좋지 않은 다른 행동을 고무시킬 때 우리는 이것을 신경성이라고 말한다. 여 기 사회는 프로그래머가 사회에 좋지 않은 것을 하도록 하는 그런 식으로 행동하고 있다. 나는 특별하다. 나는 오히려 내가 사회의 훌륭한 멤버이고 성공적으로 사회를 이용한다기 보다 는 무언가를 공헌한다고 믿고 있다. 그것은 내가 한 것을 하기로 마음먹었기 때문이다. 그러나 누 구나 적어도 정말로 유용하지 않은 것에 값을 지불한다고 느끼면서 약간의 괴로움을 당한다. 나 쁜 것을 하는 자극적인 아이디어를 패배시키는 것을 그만두자. 그리고 무료 소프트웨어를 만드는 옳은 것을 하는 사람들에게 용기를 주도록 하자. 고맙습니다. [ 이 RMS가 한 시간 동안 질문에 답을 한 후에 나는 아주 약간의 질문과 답을 포함하였다. 테이 프가 나쁜 상태여서 나는 그것의 모두를 가지고 적당한 작업을 할 시간이 없었다. ] Q : 누군가가 당신에게 문제를 주려고 했습니까? A: 나에게 문제가 만들어지려고 했던 때는 소위 Gosling Emacs 의 자기중심적인 소유자들이었다. 그들이 그렇게 할 상황이 아니었다는 것은 별도로 하더라도, 그들은 할 수 있는 것이 많이 없다. 그런데, 나는 사람들이 어떤 생각으로 다른 이들을 생각하지 않는 언어를 사용하는 것에 주의를 주기를 좋아한다. 소프트웨어를 부가 있는 물질적인 것으로 보고 그 차이점을 간과하게 하는 자 기 중심적인 소프트웨어 소유주들에게 이 분야의 많은 기술적인 흐름이 선택되었다. 이것의 가장 악명 높은 예는 "저작권 침해"라는 용어이다. 좋은 시민으로서 이웃과 소프트웨어를 공유하기를 바라는 누군가를 나타낼 때 제발 "저작권 침해"라는 용어를 사용하지 말아라. 나는 여러분에게 이것을 말하는 것을 잊어 버렸다. 복사권의 아이디어는 프린트하는 회사가 만 들었다. 예전에는 저자가 무료로 다른 것들을 복사를 했고, 이것은 나쁜 것이 아니라 아주 유용한 것으로 여겨졌다. 악명 높은 것에서 저자의 작업이 살아 남았던 한가지 방법은 그들 중 일부가 같이 있었던 다른 작업으로 인증되었기 때문이다. 이것은 책들이 그 때에 한 개씩 복사했기 때문이다. 하나의 복사본을 만들 듯이 열 개의 복사 본을 만드는 것은 열 배나 힘들다. 프린트하는 회사는 세워진 것은 사람들이 손으로 책을 복사하 는 것을 막는 것이 아니라 그것과 비교해서 너무 불편함을 막으려고 했던 것이다. 책들이 대량 생산으로 만들어졌을 때, 복사권은 이해되어졌고 읽는 자유가 있지도 않았다. 복사 회사를 소유하지 않은 공공의 멤버로서 여러분은 어떤 식으로도 책을 복사할 수 없었다. 그래서 여러분은 복사권이 있기 때문에 어떤 자유로부터도 풀어지지 않았다. 그래서 복사권이 만들어지 고 기술적인 변화로 인해 도덕적으로 받아들여 졌다. 지금은 그 역현상이 일어나고 있다. 정보를 개인적으로 복사하는 것은 더욱 더 잘 되었고 우리는 기술의 궁극적인 진보가 어떤 종류의 정보 를 복사하는 것을 가능하게 한다는 것을 보게 되었다. 그래서 우리는 복사권이 받아들여지지 않았던 고대 세계와 같은 상황으로 돌아가고 있다. 부에 대한 생각을 고려하면 그것들은 물질적인 것에서 온다. 물질적인 것은 대화법을 꽤 만족 시킨다. 내가 분필을 반으로 깰 수 있다는 것은 사실이지만, 그것이 아니다. 그것은 닳아지고 소 비되는 것이다. 그러나 기본적으로 이것은 한 의자이다. 내 손가락으로 이것을 두 의자로 만들 수 없다. 다른 것을 얻는 유일한 방법은 처음 세웠던 방법대로 그것을 세우는 것이다. 그것은 좀 더 덜 완성된 것이 되고 더 만들어야 할 것이다. 부에 대한 우리의 생각은 이런 사실에 맞춰 도덕적 으로 받아들여져야 한다. 누구나 복사할 수 있는 정보의 일부를 보면 사실은 다르다. 맞춰진 도덕적인 태도는 다르다. 우 리의 도덕적 태도는 어떤 것을 하는 데 있어서 얼마나 사람들을 도울 것이며 얼마나 상처를 줄 것인가를 고려하는 데에서 나온다. 물질적인 것과 함께 여러분은 이 의자에 오고 갈 수 있다. 그 러나 와서 그것을 복제할 수는 없다. 여러분이 의자에서 떠난다면 어떤 것도 만들어 낼 수 없어 서 어떤 실례도 범하지 않을 것이다. 나는 다음과 같이 말했다. "나는 이것을 한 의자로 만들기 위해 작업을 했다. 딱 한 사람만이 이 의자를 가질 수 있다. 내가 가지는 것이 가장 낫다." 우리 는 다음과 같이 말하는 것이 나을 것이다. "그렇다. 그것은 납득이 된다." 그러면, 어떤 사람이 다 음과 같이 말했을 때도 이해될 것이다. "나는 이 디스크를 약간 나누어서 오직 한 사람이 이 디 스크를 가지게 할 것이다. 당신들은 감히 나에게서 그것을 가져가지 못할 것이다." 오직 한사람만 이 디스크를 가질 수 있다면 그것은 그 디스크를 소유한 놈이 될 것이다. 그러나 어떤 사람이 와서 "나는 여러분의 디스크를 손상시키지 않을 것이다. 나는 단지 그것과 같은 다른 것을 마술적으로 만들 것이다. 그리고 나는 그것을 떠나버릴 것이고 여러분은 그저 전 과 같이 이 디스크를 사용하면 된다. "라고 말하면 그것은 다음과 같다. "나는 신비한 의자 복제 기를 가지고 있다. 여러분이 원하기만 하면 거기에 항상 그것을 두고 그것에 앉아서 여러분의 의 자에 앉을 수 있다. 그러나 나도 역시 의자를 가지고 있다. "그것은 좋은 일이다. 사람들이 세울 필요가 없다면 그들은 손가락을 움직여 그것을 복제할 수 있다. 그것을 대단한 일이다. 그러나 기술에서의 이런 변화는 개인적인 복사본을 가지고 그것으로 돈을 벌기를 원하는 사람들에게 맞추어지지 않았다. 그것은 단지 물건을 보존하려는 생각이다. 그래서 그들은 물질적 인 것처럼 프로그램을 하기 위해 최선을 다한다. 여러분이 소프트웨어 가게에 가서 책과 같이 프 로그램의 복사본을 왜 사는지, 언제 사는지 궁금해한 적이 있는가? 그들은 사람들이 그들이 물질 적인 물건을 얻고 있는 것처럼 생각하고 그들이 실제로 복사 가능한 디지털 데이터 형식을 얻었 다는 것을 인식하지 않기를 바란다. 결국 컴퓨터는 전체적인 기계말고는 무엇인가? 여러분은 어떤 다른 기계를 모방한 보편적인 Turing 기계를 아마 연구했을 것이다. 보편적인 기계가 그렇게 훌륭한 이유는 여러분이 다른 기 계를 모방할 수 있고 그 지시가 여러분이 물질적인 것으로 할 수 없는 것을 복사하고 변화시키기 때문이다. 이것은 소프트웨어 저장소가 대중이 그만두기를 바라는 것이다. 그들은 보편적인 기계 에 대해 기술의 변화로 이익을 얻기를 바라나 대중이 이익을 얻기를 원하지는 않는다. 기본적으로 그들은 "물질적인 것의 시대"를 보존하려고 하나 그것은 계속되었다. 우리는 우리가 사는 세상의 실제적 사실에 동시성을 가지고 옳고 그름에 대한 생각을 가져야 할 것이다. Q : 그래서 정보의 소유심을 요약했습니다. 당신은 당신의 견해로 정보를 소유하는 것이 옳은지 에 대한 예가 있다고 봅니까? A : 일반적으로 보통이 아닌 개인적 특성과 같은 정보는 괜찮다고 본다. 즉, 어떤 것을 하는 방법에 대한 정보가 아니라 하려고 의도하는 것에 대한 정보이다. 다른 사람이 특별한 정보를 여러분에 게서 돈을 주고 가져 올 수는 있으나 그것을 가지고 어떤 것도 만들어 낼 수는 없을 것이다. 내 가 비밀스럽게 통제하라고 하는 것은 매우 합리적인 것이다. 그러나 창조적인 정보에 의하여 사 람들이 사용하거나 즐길 수 있는 정보를 그것을 가진 사람들보다 더욱 사용하고 즐길 수 있을 것 이다. 우리는 복사하는 것을 조장할 것이다. -------------------------------------------------------------------------------- 혼동을 피하기 위해서 사용을 삼가해야 할 단어나 구문들 Some Confusing or Loaded Words and Phrases that are Worth Avoiding 우리 모두가 함께 동의하지 않기를 희망하는 개념들이 내포되어 있는 단어와 구문들이 있다. 이러한 어구들에 대한 혼란과 모호함을 피하기 위해서 다음의 단어와 구문들에 대한 사용을 피해 줄 것을 권유하고 싶다. | "for free" | " Give away" | "Piracy" | "보호" | "판매" | "절도" | 이와 관련된 문서인 '소프트웨어의 범주(Categories of Free and Non-Free software)'도 참조해 주기 바란다. "For free" 어떤 프로그램을 자유 소프트웨어(free software)라고 말하려고 한다면, 제발 그것을 언급할 때 "for free"라는 용어를 사용하지 말아 달라. 이 용어는 특별히 "무료(for zero price)"를 의미한다. 자유 소프트웨어는 가격의 문제가 아닌 자유로움의 문제이다. 예를 들면, 많은 FTP 서버에서 자유 소프트웨어를 무료로 이용할 수 있을 때 "for free"라는 용어를 사용할 수 있을 것이다. 그러나 자유 소프트웨어의 복제본들은 또한 CD-ROM을 통해서 유료로 이용할 수도 있다. 독점 소프트웨어(proprietary software)의 복제본들도 경우에 따라서는 무료로 이용 가능할 수 있다. "Give away" "give away"라는 용어를 "자유 소프트웨어를 배포한다"라는 의미로 사용하는 것은 잘못된 것이다. 이것은 "for free"와 같이 자유로움이 아닌 무료로 제공된다는 것을 함축하고 있다. "Piracy" 출판업자들은 종종 저작권 침해 행위로서 복제가 금지된다는 사실을 유의시킬 때 "piracy"라는 단어를 사용한다. 이런 단어를 사용함으로써 그들은 불법 복제가 해적 행위나 유괴, 살인과 도덕적으로 동등하다는 사실을 암시하려고 한다. 불법 복제가 유괴나 살인과 같은 행위와 동일하지 않다고 믿는다면, 그것을 묘사하기 위해서 해적 행위를 의미하는 단어인 "piracy"를 사용하지는 않을 것이다. "복제 금지" 또는 "불법 복제"와 같은 중립적인 용어들이 그 대신 사용 가능하다. 우리 중 몇몇은 "이웃과의 정보 공유"와 같은 긍정적인 용어를 사용할 수도 있을 것이다. "보호(protection)" 출판업자들의 변호사들은 저작권을 묘사할 때, "보호"라는 단어를 사용하는 것을 선호한다. 이 단어는 파괴나 고통과 같은 사태를 예방한다는 묵시적인 어감을 전달한다. 따라서, 이 단어는 보호의 대상이 저작권에 의해서 제한을 받는 사용자가 아닌 그것으로 이윤을 얻는 소유자나 출판업자에 있다는 사실을 조장하는 것이다. "보호"라는 단어를 피하고 대신, 중립적인 용어를 사용하기는 쉽다. 예를 들면, "저작권 보호는 매우 긴 기간 동안 지속된다"라고 말하기 보다 "저작권은 매우 긴 기간 동안 지속된다"라고 말할 수 있다. "소프트웨어 판매(sell software)" "소프트웨어를 판다"라는 용어는 애매모호하다. 엄밀하게 말하면, 자유 프로그램의 복제본을 돈과 교환하는 것이 "판매"이다. 그러나, 사람들은 대게 "판다"라는 용어를 구입후에 소프트웨어의 사용이 독점적으로 제한되는 것과 연관시킨다. 따라서, "수수료를 받고 프로그램의 복제본을 배포함" 또는 "프로그램의 사용에 독점적인 제한을 부가함"이라고 말함으로써 좀 더 정확하게 말할 수 있고 혼란을 피할 수 있다. 보다 진전된 내용에 대해서는 관련된 문서인 '자유 소프트웨어의 판매(selling free software)'를 참고하기 바란다. "절도(theft)" 저작권의 변론자들은 저작권 침해를 묘사하기 위해서 종종 "도난(stolen)"과 "절도(theft)"와 같은 단어들을 사용한다. 동시에 그들은 우리에게 법률 제도가 도덕적 판단을 대표하는 수단이라는 사실을 받아들이기를 요구한다. 만약 복제가 금지된다면, 그것은 그릇된 것이 틀림없다. 따라서, 적어도 미국의 법률 제도가 저작권 침해를 "절도" 행위로 간주하는 것을 기각시킨 것은 타당한 일이라고 할 수 있다. "도난"과 같은 용어를 사용하는 저작권 옹호자들은 그들이 호소하고 있는 근거인 법률을 잘못 해석하고 있는 것이다. 일반적으로 법률에 의해서 옳고 그름이 결정된다는 생각은 틀린 것이다. 법은 정의를 실현하기 위한 최선의 시도일 뿐이다. 법이 정의나 도덕적 행위를 규정하는 것이라는 발언은 앞뒤를 뒤집는 것이다. -------------------------------------------------------------------------------- 저작권과 사용 허가에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 허용되며 상업적 이용을 포함할 수 있는 지속적인 배포에 따른 사용상의 모든 권리는 문서의 취득자에게 조건없이 양도된다. 단, 원문에 대한 수정과 첨삭은 허용되지 않는다. Original Copy: Some Confusing or Loaded Words and Phrases that are Worth Avoiding Drafted version: Leonard Tower's 4 Aug 1997 updated Copyright (C) 1996, 1997 Free Software Foundation, Inc., 59 Temple Place Suite 330, Boston, MA 02111, USA Korean Translator: 1998 Ryu Jaesang 류재상 kidaeryu@soback.kornet.nm.kr 정보사회의 민주화를 위한 대안 - 리눅스 독일방송의 "컴퓨터클럽의 밤"을 보고 허준영(jhoh@gwdg.de) 1998/12/07 눈덮힌 세상이 아직 새벽잠에 취해 주말의 휴식을 즐기고 있을 때, 수많은 독일의 네티즌들은 텔레비전과 컴퓨터의 모니터 앞에서 날밤을 새운 피로를 잊은 채 환호 의 함성을 지르고 있었습니다. 그 즈음, 이 열광의 진원지에서는 각지에서 몰려든 팽귄들이 막 지나온 곳에 새로 운 이정표를 세우고 더한층 힘찬 도약을 다짐하며 함께 걸어가고 있었습니다. 이 제 더이상 팽귄은 외롭지 않다는 사실을 확인하면서... 1998년 12월 5일 밤 11시경부터 다음 날 오전 6시까지 서독 방송국(WDR)은 자사의 정보통신 전문프로그램인 "컴퓨터 클럽"의 250회 방송을 기념해 하인쯔 닉스도르 프 박물관 포럼 (Heinz Nixdorf MuseumsForum:HNF)과 공동으로 특집 프로그램 "컴 퓨터 클럽의 밤"을 생방송으로 제작, 방영했습니다. 이 장시간의 특집 생방송이 진행된 행사장은 독일 컴퓨터업계의 선구자인 하인쯔 닉스도르프를 기념한 세계 최대의 컴퓨터 박물관이 있는 독일 중서부의 작은 도시 파더본(Paderborn). (부연 설명: HNF는 1996년 6000 평방미터의 전시장에 1000여 종의 주요 정보통신기기를 60 여 부문으로 분류, 전시하고 있으며, 1996년 당시 연방 총리인 헬무트 콜이 개 관 테이프를 끊었습니다. 그간 약 17만 여명에 달하는 방문객이 이 전시관을 찾았 다는데, 금년 6월에는 HNF의 국제적인 교류행사를 목적으로 "파더본 논단"이 구성 되었으며 이 자리에서 로만 헤어촉 독일 대통령이 축사를 겸한 특별연설을 하기도 했습니다.) 2000명 이상의 방문객이 이벤트 현장에 운집한 가운데, 밤을 지세며 진행한 이날 생방송의 핵심 주제는 "리눅스 - 그 새로운 대안"이었습니다. 수년 전까지만 해도 소수의 컴퓨터 "광" 내지 "도사"들의 전문 집단이 "뚝딱거리는" 실험적인 운영체 계로 간주되던 리눅스가 이제 오픈 소스운동의 확산과 더불어 사회적 논의대상이 되고, 미래 정보사회를 주도할 대안으로 모색된다는 점에서 어떤 이들은 놀라고 또 어떤 이는 격세지감을 느낄 것입니다. 하지만, 이 행사를 통해 전문가와 비전 문가를 막론하고 많은 사람들이 리눅스로 대변되는 열린 무른모(공개소프트웨어) 운동을 새로운 시각에서 바라보고, 새로운 흐름을 감지하는 기회를 가질 수 있었 다는 점은 부정할 수 없을 것입니다. 세계 최대의 컴퓨터 박물관으로 기네스북에 오른 "하인쯔 닉스도르프 박물관포럼" 에서 기록적인 7시간 여의 철야 생방송이 진행된 이날 행사의 정점에는 예정된 또 하나의 기네스북 사건이 기다리고 있었습니다. 바로, 512 대의 컴퓨터를 소위 클 러스터 (Cluster)라는 개념으로 리눅스를 이용해 네트워크로 연결하는 엄청난 대 작!, 이것이었습니다. 초기 컴퓨터 모델부터 발전과정과 전산 전자적 정보처리의 전개에 관한 역사적 논 의, 인터넷 상의 언어문제, 멀티미디어, 게임개발 등에 대한 소개, 각종 신기술과 미래형 디지털 방송, 그리고 항공우주산업의 첨단 전자장비에 대한 전망에 이르기 까지 다양한 주제를 다룬 이날 철야생방송이 대단원의 막을 내리기 약 한 시간 전 그러니까 6일 오전 5시 경에 독일의 리눅서들은 오스트리아와 스위스에서 온 참가 자와 더불어 마침내 목표량을 초과해 520 대의 컴퓨터들을 (실제 동원된 컴퓨터를 합치면 550 대) 클러스터로 묶는 작업을 완료했습니다. 행사장 바로 옆에 있는 파 더본대학 정보학과 건물에서 일어난 일입니다. 한마디로 부럽더군요. 한국의 리눅서들이 그러한 "대작"을 할 수 없어서가 아니라 그만한 큰 작업을 공개 이벤트로 마련하고 사회적 논의를 통해 정보화에 대한 일 반의 관심을 증대하고 독일 리눅서들이 벌인 공동작업의 성과를 통해 리눅스의 우 수성을 증명함으로써 눈에 보이는 520 여 대의 컴퓨터 이상의 "사회적 네트웍"이 형성될 수 있다는 점이 충혈된 제 눈을 새롭게 뜨게 했습니다. "과연 리눅스는 새로운 대안인가?"라는 화두로 부터 시작하여 리눅스를 비롯한 열 린 무른모는 시종 "컴퓨터클럽의 밤"을 엮는 대화의 연결고리가 되고 있었습니다. 주제토론은 물론, 일반 굳은모(하드웨어)가 소개될 때도 사회자는 "이것을 리눅스 에서도 사용할 수 있습니까?" "리눅스 사용자를 위해 많은 지원 바랍니다" 등의 질문과 당부를 기회있을 때마다 하더군요. 따라서 이날 행사를 "리눅스의 밤"으로 불러도 결코 과장된 표현은 아닐 것입니다. "리눅스여 영원하라! 훌륭한 방송이었습니다. 정보 사회의 민주화에 많은 기여가 있기를 바랍니다." 하고 짧은 축전을 컴퓨터 클럽의 밤 홈페이지에 마련된 방명록 에 남긴 뒤, 저는 잠시 우리 나라의 정보 인프라에 대해 생각해 보았습니다. IMF 한파와 함께 찾아온 국내 경제난의 여파로 가뜩이나 경영난에 허덕이던 `한글 과 컴퓨터사'가 마침내 지난 6월 미국 마이크로 소프트사의 자금지원을 전제로 협 상을 벌이던 중 아래아한글에 대한 개발포기를 선언한 사건은 우리의 정보사회가 안고 있는 많은 문제점을 드러낸 것이었습니다. 이른바 "한컴사태"가 일어난 당일 (16일), 저는 밤잠을 설치면서 분을 삭이다가 한 신문사의 토론방에 "운영체계의 교체로 우리의 한글을 살리자"는 요지의 글을 올린 적이 있습니다. 다시 말해서, MS와 같은 영리를 추구하는 "사익집단"에 우리 나라의 정보기반을 닦는 작업을 맡 길 것이 아니라, 리눅스 등의 공개화된 운영체계를 사회적으로 보급하고 개발을 장려함으로써 누구나 정보화 사회에서 소외되지 않고 제 몫을 찾을 수 있도록 하 는 것이 다가오는 미래의 정보사회의 민주화를 준비하고 궁극적으로는 "정보 복지 사회"를 일구어 내는 길이라는 것이 저의 소신이고, 이 생각은 지금도 변함이 없 습니다. 제아무리 초고속 광통신망을 구축하고 정보화 인프라를 높힌다고 해도, 그 기반 위에서 시스템을 운영하는 체계가 독점권을 가진 외국기업의 것이라면, 과연 그것은 누구를 위한 고속도로가 될 것인가를 자문해 볼 때, 자라나는 2세와 후대의 정보사회를 위해서도 "공개념의 운영체계"를 도입해 튼튼한 토대를 다지는 것이 우리에게 수지맞는 일일 뿐아니라, 나아가 국제사회의 호혜적인 정보기반을 구축하는데도 기여할 것이라고 생각합니다. 독일의 한 대학의 강의실 두 곳을 메운 520 대의 컴퓨터들을 각지에서 참가한 자 원자들의 손으로 리눅스 클러스터를 연결해, 기네스북에 오를 기록을 하루밤 사이 에 만들어 낸 것은 한 방송사의 특집프로그램의 이벤트 중 하나라고 보기에는 그 이면에 내재하고 있는 의미가 크고, 또한 우리에게 시사하는 점도 많다고 생각합 니다. 행사를 주관한 서독 방송국과 HNF 외에도 수많은 도움의 손길이 있었고, 이 리눅스-클러스터-프로젝트를 위해 장비와 기재를 제공한 협찬사들이 있습니다.(스 폰서 명단을 보니 우리나라의 업체로서는 유일하게 삼성이 Quant-X사와 더불어 50 대의 알파칩 기반의 (667MHz) 컴퓨터를 소프트웨어 및 기술진과 함께 제공했군요. 그 외에 HP, Siemens, Seagate, Peacock 등 유수한 기업들이 장비를 협찬 했습니 다.) 이것은 결국 리눅스를 필두로 한 오픈소스운동의 확산이 가져온 언론과 기업 의 반응이기도 하지만, 역으로 이러한 사회운동을 장려하는 사회적 분위기를 증폭 하고 선도하는 역할을 대학과 언론 및 기업이 담당하기 시작했다고 볼 수도 있습 니다. 바로 그러한 사회적 공감대의 형성과 오픈소스 기반의 개발 프로젝트 지원이 우리 정보사회가 당면한 과제 중 우선순위에 들어갈 일이 아닌가 합니다. 그것은 벤처 기업의 육성과 대기업의 경쟁력 확대를 위한 구조조정에 못지 않게 중요한 우리정 보인프라의 개혁과제에 속하는 사안입니다. 왜냐하면 정보의 개발과 가공 및 운영의 모든 과정에서 열린 무른모 및 공개념의 운영체계가 민주화된 정보사회의 뿌리를 튼튼히 할 것이고 훌륭한 자양분이 될 것 이기 때문입니다. 교육적인 측면에서나 실용적인 측면에서 오픈소스운동에 근간을 둔 무른모는 금전적으로 환산할 수 없는 가치를 담지하고 있는 사회적 자산이 아 닐 수 없습니다. 지난 "한컴사태"에서 우리의 네티즌이 보인 저력은 분명코 세계를 놀라게 할 만한 또하나의 사건이었습니다. 그러나 당시에 폭발적으로 일어나 들끓었던 오픈소스에 대한 논의는 한겨레신문사에서 주관한 한컴사태의 해결을 위한 "공개 토론회"를 정점으로 잦아들었고, 지금은 열린한글 프로젝트 등의 열린 무른모 개발작업이 기 존의 한국 리눅스 사용자 그룹 및 한국 FreeBSD 사용자그룹 등과 더불어 지속적인 논의를 하고 있는 실정입니다. 이제는 그간의 논의를 바탕으로 우리의 대학이, 우리의 언론이 그리고 우리의 기 업이 사회적 현상으로 자리메김된 열린 무른모 개발과 오픈소스 운동에 반향을 일 으키고 보다 적극적인 지원 활동을 때를 놓치지 않고 시작해야 할 것입니다. 또한 공공정책을 입안하는 입법부와 집행을 담당하는 행정부 및 각급 자치단체들은 풀 뿌리 민주사회에 걸맞는 "풀뿌리 정보사회"가 빛을 볼 수 있도록 열린 마당과 열 린 분위기를 장려하는 기틀을 마련하는 정치/행정서비스에 인색하지 않아야 할 것 입니다. (이같은 사회 공공부문에 대한 서비스는 적어도 지난 한컴사태 당시 정보 통신부에서 피력한 기업활동에 대한 "시장원리"에 준한 원칙적인 입장에 결코 위 배되지 않는다고 생각합니다.) 저는 정보에 대한 접근가능성이 얼마나 열려있느냐에 따라 미래사회의 민주화를 가늠할 수 있다고 보고 있습니다. 달리 표현하면, 정보 소유의 기회균등이 해당 사회의 커뮤니케이션 상의 복지정도를 결정하는 척도가 된다고도 말할 수 있습니 다. 앨빈 토플러가 보는 미래의 권력수단이 정보에 있다는 사실을 전제로 할 때, 하버마스적인 의사소통의 기회균등 및 정보점유의 기회균등이 얼마나 실현되느냐 에 따라 한 사회집단이 혹은 국가가 절대권력, 내지 독재의 길을 걷느냐, 아니면 민주화의 길을 추진해 가느냐를 구분하는 스펙트럼을 볼 수 있을 것입니다. 우리 사회가 바람직한 민주화의 길을 좨치어 나아가기 위해 공개적인 토론이 열린 마당 에서 지속적으로 이루어지고, 나아가 무른모와 운영체계의 공개념을 상용 소프트 웨어와 운영체계에 대한 대안으로 도입하여 양자의 균형적인 발전을 도모하는 실 천적인 운동이 일어나기를 간절히 바라는 마음에서 이 글을 올립니다. 덧붙이는 말: 지금 열린 한글에서는 한글문제를 위시하여 열린한글 프로젝트의 올 바른 방향을 모색하기 위해 공개 토론회를 준비할 계획이 조심스럽게 제기되고 있 습니다. 가능하다면 우리 나라의 오픈소스운동을 재조명하고 나아갈 바를 논의하 는 마당이 사회운동의 현장이 된다면 더욱 좋지 않을까 생각합니다. 이러한 맥락 에서 한국사회의 오픈소스운동의 대표주자라 할 열린한글이 리눅스 사용자그룹 및 FreeBSD 사용자 모임 등과 힘을 합하여 공동의 이벤트를 만드는 것도 상당히 의미 있는 일이라고 봅니다. 파더본 대학이 이번에 독일의 리눅서에게 공간을 제공하고 기술적 배려를 아끼지 않은 것처럼, 뜻을 같이하는 한국의 대학이 지원하는 강당 에서 공개 세미나를 연다든가, 공개운영체계의 설치 및 활용방법을 시범적으로 보 여주는 것도 생각해 봄 직 합니다. 시작이 반이라는 말이 있듯이 독일어에도 "모 든 시작은 어렵다"(Aller Anfang ist schwer)라는 속담이 있지요. 좋은 출발을 위 해 많은 준비가 있어야 할 것입니다. ------------------------------------- 발췌 : http://www.shinbiro.com/cug/special/jhoh/T1L36 Hurd: OS 설계의 새로운 전략을 향하여 -------------------------------------------------------------------------------- 이 기사는 왜 FSF가 전체 GNU시스템의 기초가 될 Hurd라는 이름의 새 운영체제를 개발하고 있는지에 대한 것이다. Hurd는 CMU의 Mach 3.0 커널 위에 만들어졌고, Mach의 가상메모리 관리와 메시지 전달 기능을 사용한다. GNU C라이브러리는 유닉스 시스템 콜 인터페이스를 제공하고, 스스로 제공할 수 없는 서비스에 대해 Hurd를 부른다. Hurd의 설계과 구현은 Richard Stallman, Roland McGrath, Jan Brittenson과 다른 사람들과 함께 Michael Bushnell이 이끌고 있다. -------------------------------------------------------------------------------- 제 1 부 : OS 설계로의 더 유용한 접근 OS의 기본적인 목적은 여러 프로그램들이 하나의 컴퓨터를 효과적이고 생산적으로 공유할 수 있도록 하는 것이다. 이것은 메모리 보호, 선점형 스케쥴링을 하는 시분할, I/O주변기기에 대한 동등한 억세스, 그리고 다른 서비스를 요구한다. 추가적으로, OS는 여러 사람들이 한 컴퓨터를 공유하는 것을 허용한다. 이 경우 효율성은 사용자를 서로 방해하지 못하도록 하고, 그들을 사전 정리 없이 공유할 수 있게 하고, 또는 물리적 장치의 억세스를 조정하는 서비스를 요구한다. 오늘날의 컴퓨터 시스템에서, 프로그래머는 이 목적을 커널이라 불리는 거대한 프로그램을 통해 구현한다. 이 프로그램은 모든 사용자 프로그램에서 억세스 가능해야 하기 때문에, 시스템에 기능을 첨가하는 것은 자연스러운 일이다. 프로세스 상호작용을 위한 유일한 모델은 커널이 제공하는 특별하고 개인적인 서비스이기 때문에, 아무도 기능을 첨가하기 위해 커널 이외의 다른 장소를 만들지 못한다. 시간이 흐를수록, 더 많은 것들이 커널에 첨가된다. 전통적인 시스템은 사용자가 시스템의 거의 모두를 이해하고, 시스템 안에서 특권 상황을 가질 수 있어야만 그에게 부속을 커널에 더하는 것을 허용한다. 새 부속을 더하는 일은 다른 프로그램을 테스트하는 것 보다 더 많은 고통스러운 편집-컴파일-디버그의 사이클을 요구한다. 이는 다른사람이 시스템을 사용하고 있는 동안은 할 수 없다. 버그는 보통 치명적인 시스템 붕괴를 유발하며, 나아가 다른사람이 시스템을 사용하지 못하도록 한다. 전체 커널은 보통 페이징이 불가능하도록 되어 있다(페이징 가능한 커널이 있지만, 어디가 페이징 가능한지를 결정하는 것은 어렵고, 에러가 나기 쉽다. 보통 이 메카니즘은 어렵고, 간단한 확장을 할 때 조차도 이 일을 어렵게 한다). 이 제한 때문에, 절대적으로 필수적이지 않는 한 전통적인 커널의 벽 뒤에 적절히 속하는 기능은 보통 시스템에서 빠져 있다. 열기/읽기/쓰기 인터페이스로 아주 잘 할 수 있는 많은 좋은 생각들이 전통적 시스템 안의 고유한 독점적인 본성의 문제 때문에 구현되지 못한다. 게다가 참을성 있게 새로운 생각을 구현하려는 사람들 사이에서조차 그들의 컴퓨터의 특권 유저인 사람들만 그렇게 하고 있다. 소프트웨어의 저작권 시스템은 라이센스받지 못한 사람들은 커널의 소스조차 보는 일을 방해하여 그 진흙탕을 더욱 어둡게 하고 있다. 몇몇의 시스템은 이 어려움을 해소하려고 노력했다. Smalltalk-80과 Lisp머신은 모두 이 문제를 해결하는 한 방법을 제시하였다. 시스템 코드는 사용자 코드와 다르지 않다. 모든 시스템은 사용자에게 억세스 가능하며, 필요하면 바뀔 수 있다. 두 시스템은 아주 쉬운 대체와 확장의 기능을 가진 언어로 만들어졌고, 비교적 성공적이었다. 그러나 그들 모두는 사용자와 프로그램을 서로 고립시키는 일에는 아주 안좋아서 OS설계의 중요한 목적 하나에는 실패했다. Mach 3.0커널을 사용하는 대부분의 프로젝트는 OS설계의 바뀌기 어려운 경향을 그대로 갖고 왔다. 내부구조는 다르지만, 사용자와 시스템 사이에는 같은 무거운 장벽이 남아 있다. 단일서버(single-servers)들은 아주 만들기 쉬운 반면에 독점적 커널의 모든 결점을 이어받았다. 다중서버(multi-server)는 커널 기능을 잘 정의된 인터페이스의 논리적인 블록으로 나눈다. 잘 만들어지면 기능을 바꾸거나 더하는 일은 쉽다. 그래서 대부분의 다중 서버 프로젝트는 다소 낫다. 더 많은 시스템의 부분이 페이징 가능하게 된다. 시스템을 더 쉽게 디버깅할 수 있다. 새 시스템 부속을 다른 사용자를 방해하지 않고 테스트할 수 있다. 그러나 사용자와 시스템간의 장벽은 여전히 남는다. 아무도 특권 없이는 이 벽을 넘을 수 없다. GNU Hurd는 반대로 시스템 코드의 영역이 될 수 있는 한 한정되게 설계되었다. 프로그램은 커널의 몇 안되는 필수적인 부분과 통신하면 된다. 시스템의 나머지는 동적으로 대체할 수 있다. 사용자는 그들이 원하는 시스템의 어떤 부분이라도 사용할 수 있으며, 다른 사람들이 이 장점을 이용할 수 있도록 스스로 이 부속을 쉽게 더할 수 있다. 사용자들이 서로의 서비스를 이용하기 위해 미리 상호이해가 필요하지도 않고, 임의 사용자의 서비스를 믿어서 시스템이 취약하게 되지도 않는다. 이를 위해 사용자는 서로와 통신하기 위해 써야 할 이들 시스템 부속을 등록하면 된다. 이들 중 하나는 사용자를 확인하는 일을 책임지며, 인증 서버(authentication server)라고 불린다. 서로를 확인하기 위해 프로그램은 각각은 그들이 믿는 인증 서버와 함께 반드시 통신해야 한다. 다른 부속은 전체적인 관리를 담당하는 수퍼유저에 의한 시스템 부속을 제어하며, 이는 프로세스 서버(process server)라 불린다. 모든 사용자 프로그램이 프로세스 서버와 통신할 필요는 없다. 이는 그 서비스를 필요로 하는 프로그램에만 필요하다. 이와 비슷하게 인증 서버는 서로간의 확인을 하고 싶어하는 프로그램에만 필요하다. 남은 서비스의 어떤 것도 특별한 상태를 필요로 하지 않는다: 네트웍 구현도, 파일시스템도, 프로그램 실행 메카니즘도(setuid를 포함한), 이외의 어떤 것도. 변환기(Translator) 메카니즘 Hurd는 기본적인 사용자와 서버간의 통신수단으로 Mach의 포트를 사용한다(Mach의 포트는 메시지를 주고받는 Mach의 작업(Task)의 통신 지점이다). 각각의 포트는 특별한 프로토콜의 집합을 구현하고, 포트에 의해 표현되는 내재한 객체에서 취하는 작업을 표현한다. Hurd에 의해 지정되는 프로토콜의 일부는 I/O프로토콜이고, 일반적인 I/O작업에 사용한다. 파일 프로토콜은 파일시스템 작업에 사용한다. 소켓 프로토콜은 네트웍 작업에 사용한다. 프로세스 프로토콜은 프로세스를 다루기 위해 사용한다. 다른 것들도 마찬가지이다. 대부분의 서버는 파일을 여는 것으로 억세스된다. 보통 파일을 열 때에는 파일을 가진 디렉토리를 소유하는 서버가 가지는 파일에 관련된(associated) 포트를 연다. 예를 들어 디스크 기반 파일시스템은 보통 각각 열린 파일이나 디렉토리를 표현하는 많은 포트를 제공한다. 파일이 열리면, 서버는 새 포트를 만들고, 이를 파일과 연관시키고, 부른 프로그램한테 포트를 되돌려 준다. 그러나 파일은 그와 관련된 변환기를 가질 수 있다. 이 경우, 파일의 내용을 참조하는 포트를 돌려주는 대신 서버는 그 파일과 연관된 변환기 프로그램을 실행한다. 이 변환기에는 파일의 실제 내용을 가리키는 포트가 주어지고, 열기 동작을 완료하기 위해 원래 사용자에게 포트를 돌려주도록 요청한다. 이 메카니즘은 각 마운트 지점과 관련된 변환기를 갖는 일에 의해 mount에서 사용한다. 프로그램이 마운트 지점을 열면 변환기(이 경우에는 마운트된 파일시스템의 디스크 형식을 아는 프로그램)가 실행되고 포트가 프로그램에 돌려진다. 변환기가 시작한 후에는 이것이 종료하지 않는 한 다시 실행할 필요는 없다. 부모 파일시스템은 나중의 요청에 대비해 변환기로의 포트를 보존한다. 파일의 소유자는 특별한 권한 없이 변환기를 파일에 관련시킬 수 있다. 이는 어떤 프로그램도 변환기가 될 수 있다는 뜻이다. 분명히 시스템은 변환기가 파일 프로토콜을 정확히 구현하지 않으면 적절히 동작하지 않을 것이다. 그러나 Hurd는 최악의 결과가 중지할 수 있는 정지 상태(interruptible hang)가 되도록 설계되었다. 변환기를 사용하는 하나의 방법은 파일 프로토콜을 사용하여 계층적으로 구성된 자료를 억세스하는 것이다. 예를 들어 ftp프로그램의 사용자 인터페이스의 모든 복잡성은 없어졌다. 사용자는 FTP를 나타내는 특별한 디렉토리를 알기면 하면 원격 시스템을 억세스하기 위해 새로운 명령을 배우기 보다는 모든 표준 파일 관련 명령(예를 들어 ls나 cp)를 사용할 수 있다. 비슷하게 간단한 변환기는 tar나 gzip의 복잡성을 줄일 수 있다(이런 투명 억세스에는 약간의 대가가 추가되지만 편리하다). 일반 서비스 변환기를 가지고 파일시스템은 파일와 유사하지 않은 인터페이스와 접촉점으로 행동할 수 있다. 내부 전송으로 Mach 메시지를 사용하는 어떤 버전의 X프로토콜을 구현하는 서비스를 생각해 보자. 각 X디스플레이에 대해 어떤 파일을 그 변환기로서 적절한 프로그램으로 만들 수 있다. X클라이언트는 그 파일을 열 것이다. 이 순간 유용한 파일 명령은 거의 없다(예를 들어 읽고 쓰기는 소용없다). 그러나 새로운 명령(XCreateWindow나 XDrawText)은 의미를 가지게 된다. 이 경우 파일시스템 프로토콜은 접촉점에 쓰이는 노드의 특성을 다루기 위해서만 사용한다. 노드는 I/O명령을 지원하지 않으며, 그런 메시지에느 message_not_understood 리턴 코드를 돌려준다. 이 변환기 기법은 계층적 파일시스템과 같이 구성되지 않은 Hurd의 대부분의 서비스에 접촉하기 위해 사용한다. 예를 들어 암호의 교환을 위해 인증 꼬리말(authorization tags)을 사용하는 암호 서버에 이런 방식으로 접촉한다. 또한 네트웍 프로토콜 서버는 이런 형식으로 접촉할 수 있다. Roland McGrath가 변환기의 이런 사용법을 생각해 냈다. 현명한 파일시스템도(圖) Hurd에서는 변환기는 약간의 의미를 바꾸어서 파일시스템의 일부로 파일시스템과 유사한 관점을 제공하는데 쓰일 수 있다. 예를 들어 그 자체는 바꿀 수 없지만, 그럼에도 다른 곳에 그 파일의 바뀐 버전을 기록하는 파일시스템을 가질 수 있다면 좋을 것이다(이는 소스코드 관리에 유용하다). Hurd는 다른 디렉토리의 개념적인 집합인 디렉토리를 만드는 변환기를 가질 수 있다. 이는 실행하고 싶어하는 모든 프로그램을 포함하는 하나의 디렉토리를 사용자에게 제공하는데 쓰일 수 있다. 이 주제에 대한 여러 가지 유용한 변종들이 있다. 사용자가 할 수 있는 일 어떤 변환기로도 파일시스템을 가로채어 별도의 특권을 얻을 수 없다. 변환기는 변환하는 파일의 소유자의 사용자 id(uid)로 실행하며, 그 소유자에 의해서만 설정되거나 바뀔 수 있다. I/O와 파일시스템 프로토콜은 상호 믿을 수 없는 클라이언트와 서버에 사용을 허가할 수 있도록 주의깊게 설계되었다. 결국 변환기는 단지 보통 프로그램이다. GNU C라이브러리에는 공통적인 종류의 변환기를 만들기 쉽도록 하는 여러 기능이 있다. 암호 서버나 setuid 실행을 허락하는 변환기와 같은 변환기는 특별한 권한을 필요로 한다. 이 변환기들은 누구나 시행할 수 있지만, 이들은 루트가 소유한 노드 위에 설정되어야만 이들의 모든 서비스를 성공적으로 제공할 수 있을 것이다. 이는 어떤 사용자라도 reboot 시스템 콜을 부를 수 있다는 말과 같지만, 그 사용자가 루트이어야만 이를 존중한다. 왜 이렇게 다른가 이 설계가 제공하는 것은 완전히 유닉스 세계의 소설이다. 지금까지 OS들은 시스템 코드의 영역에 그들의 기능의 많은 영역을 유지해 왔으며, 이것은 수정와 수많은 요구에 의한 것을 제외한 확장을 막았다. 사용자는 이 일이 아무리 작업을 쉽게 해도 프로그램에서 시스템의 일부를 바꿀 수 없으며, 시스템 관리자는 네트웍을 끄고 커널에 임의의 부분을 설치하는 것을 꺼린다. Hurd에서는 사용자는 전통적 시스템에 의해 미리 정해진 거의 모든 것을 바꿀 수 있다. 작업 주소 공간과 특성 위의 Mach커널이 제공하는 수많은 제어와 함께 Hurd는 최초로 다른 사용자를 방해하지 않고 그들이 싫어하는 시스템의 일부를 바꿀 수 있는 시스템을 제공한다. 지금까지의 대부분의 Mach기반의 OS는 새 환경에서 대부분 같은 낡은 유닉스의 더 넓은 집합을 구현해 왔다. 반대로, GNU는 이 의미를 확장하여 사용자가 이를 개선하고 빼고 대체할 수 있도록 한다. -------------------------------------------------------------------------------- 제 2 부 : Hurd의 특징을 살펴보자 인증 서버(Authentication Server) Hurd의 중심 서버 중의 하나는 인증 서버이다. 이 서버로의 각 포트는 사용자를 확인하고, 이 서버를 id블럭과 연관시킨다. 각 id블럭은 사용자와 그룹 id의 집합을 포함한다. 어느쪽 집합도 비어있을 수 있다. 이 서버는 위에서 말한 암호 서버와 같지 않다. 인증 서버는 세가지 서비스를 제공한다. 첫번째로 이는 인증 포트에서 간단한 부울(boolean) 연산을 제공한다: 주어진 두개의 인증 포트에서, 이 서버는 uid와 gid의 두 집합을 나타내는 세번째 포트를 제공한다. 두번째로, 이 서버는 임의의 인증 포트를 만들기 위해 uid 0의 어떤 사용자도 허용한다. 마지막으로 이 서버는 서로 믿지 못하는 클라이언트와 서버가 그들을 확인하고 서로에게 초기 정보를 넘겨주는 것을 허용하는 RPC(다른 프로그램과 아마도 다른 호스트간의 원격 프로시저 콜(Remote Procedure Calls))를 제공한다. 이는 파일시스템과 I/O프로토콜의 보안에 중요한 것이다. 어떤 사용자도 인증 프로토콜을 구현하는 프로그램을 쓸 수 있다. 이는 시스템의 보안을 위반하지 않는다. 서비스가 사용자의 인증을 필요로 할 때에는 이는 이것의 믿을 수 있는 인증 서버와 통신한다. 만약 그 사용자가 다른 인증 서버를 사용하면, 처리(transaction)는 중단되고 서버는 더이상 통신하기를 거부할 수 있다. 사실 이는 시스템의 모든 프로그램이 같은 인증 서버를 사용하도록 강제하기 때문에, 우리는 이 인터페이스를 어떤 안정한 동작이라도 가능하고 관계없는 명령을 포함하지 않도록 인터페이스를 설계했다(이것이 분리된 암호 서버가 있는 이유이다). 프로세스 서버(Process Server) 프로세스 서버는 정보 분류 창고로서 동작한다. 여기에는 서버가 지원하는 네가지 주 서비스가 있다. 먼저 프로세스 서버는 Mach커널이 다루어지지 않는 호스트 레벨의 일반적인 정보를 추적한다. 예를 들어 호스트 이름(hostname), 호스트 id, 시스템 버전은 프로세스 서버에 의해 관리된다. 두번째로, 이 서버는 POSIX기능을 사용하고자 하는 프로그램을 돕기 위해 세션과 프로세스 그룹에 대한 POSIX개념을 관리한다. 세번째로 프로세스 서버는 Mach 작업(task)와 Hurd 프로세스 사이의 일대일 사영(mapping)을 관리한다. 모든 작업은 pid를 할당받는다. 프로세스는 이 서버에 메세지 포트를 등록할 수 있고, 이 포트는 요구하는 어떤 프로그램에게도 제공될 수 있다. 이 서버는 이 메세지 포트를 사적으로 만들려는 어떤 시도도 하지 않으며, 따라서 사용자 프로그램은 필요한 보안사항은 스스로 구현해야 한다(GNU C라이브러리는 이 모든 것을 위해 편리한 함수를 제공한다). 프로세스는 프로세스 서버에게 현재의 'argv'와 'envp'값을 알려줄 수 있다. 그런 후 이 서버는 요청에 따라 인수와 환경변수에 대한 벡터를 제공할 것이다. 이는 ps와 같은 프로그램을 쓰기에 유용하고 이 정보를 숨기거나 바꾸는 일도 쉽게 할 수 있다. 이 어떤 것도 필수적이지는 않다. 프로그램은 이 모든 것을 무시하고 자신을 프로세스 서버에 전혀 등록하지 않을 수 있다. 그러나 여전히 부여받은 pid는 가질 것이다. 마지막으로, 프로세스 서버는 동시에 많은 프로세스 메세지 포트를 모으는데 사용하는 프로세스 수집(Process Collection)을 구현한다. 또한 pid와 프로세스 서버 포트와 Mach작업 포트간의 변환기능이 제공된다. 반면에 포트의 보안을 유지하는 일을 확실히 한다. 프로세스 서버가 부가적이라는 것을 강조하는 일은 중요하다. Mach의 제한 때문에 프로그램은 시스템의 모든 작업을 확인하기 위해 루트로 실행되어야 한다. 그러나 다중 프로세스 서버가 각각의 클라이언트들과 함께 공존할 수 있다면 그들만의 세계 모델을 제공할 수 있다. 구현하기 위해 루트 권한을 요구하지 않는 이 프로세스 서버 기능은 사용자당 서버가 될 수 있다. 사용자는 어떤 일이든 할 수 있다. 투명 FTP(Transparent FTP) 투명 FTP는 이제 호기심을 자아내는 생각이다. GNU Emacs에서 쓸 수 있는 유명한 ange-ftp패키지는 모든 Emacs파일관련 명령에서 가상적으로 투명하게 FTP파일을 억세스할 수 있게 한다. 투명 FTP는 같은 일을 하지만 시스템 차원이다. 이 서버는 아직 다 되지 않았다. 자세한 것은 아직 더 만들어야 하지만, 확실히 바뀔 것이다. BSD커널에서는 투명 FTP파일시스템은 Hurd에서보다 더 만들기 어렵지는 않다. 그러나 이 개념을 BSD해커에게 이야기하니 반응은 "그런 건 커널에 속하지 않는다" 라는 것이었다. 어떤 의미에서는 이 말은 옳다. 이런 것이 커널 안에 놓이는 것은 시스템의 모든 계층화 원칙을 위반한다. 그러나 이 불행한 부수 효과는 설계 방법론(사용자가 좋아하지 않은 것을 바꾸지 못하도록 하는일에 기반한)이 시스템 설계자가 더 좋게 하는 일을 방해하는데 사용한다(최근의 BSD커널은 투명 FTP를 제공하는 사용자 프로그램을 쓸 수 있게 한다. 그 예는 alex인데, 실행하기 위해서는 루트권한을 요구한다). Hurd에서는 투명 FTP를 하기 위한 장애물은 없다. 변환기는 /ftp노드에 제공할 수 있다. /ftp의 내용은 있을 것이지만 아마도 직접 볼 수는 없을 것이다. 이는 여러 가능한 형식이 될 수 있다. 예를 들어 uunet의 파일을 억세스하기 위해서 cd /ftp/ftp.uu.net:anonymous:mib@gnu라고 할 수 있다. 또는 원격 계정의 파일을 억세스하기 위해서 cd /ftp/gnu.ai.mit.edu:mib:passwd라고 할 수 있다. 이 명령의 일부는 삭제되며 투명 FTP프로그램은 사용자의 .netrc파일을 읽을 수 있다. 마지막 경우에서 cd /ftp/gnu.ai.mit.edu라고 하면 나머지는 이미 .netrc에 있게 된다. cd를 먼저 할 필요는 없다 - 어떤 파일 명령이라도 사용하자. RFC 1097(the Telnet Subliminal Message Option)에 대해 찾기 위해서는 단지 more /ftp/ftp.uu.net/inet/rfc/rfc1097이라고 치면 된다. RFC를 자주 읽어야 한다면 지역 디스크로 복사할 수 있다. 파일시스템 또한 일반적인 파일시스템도 구현되고 있다. Hurd의 처음판은 BSD 4.4 고속 파일시스템(Fast File System)과 상위 호환인 파일시스템을 포함할 것이다. 일반적인 의미에 더해 레코드 변환기를 위한 수단을 제공하고, 32비트 사용자 id와 그룹 id를 제공하고, 소유자가 임의로 지정할 수 있는 파일의 저자라 부르는 파일당 새 id를 지원한다. 추가적으로 Hurd의 사용자는 다중 uid(없을 수도 있다)를 가질 수 있기 때문에 알려졌지만 임의의 사용자(uid있는: 파일 권한의 존재하는 세계 범주)와 알 수 없는 사용자(uid없는)의 억세스 통졔를 제공하는 권한 비트의 집합을 제공한다. 네트웍 파일시스템 프로토콜은 시작점으로 4.4BSD를 사용하여 구현될 것이다. 기록 구조(log-structured) 파일시스템은 스프라이트(Sprite)에서처럼 같은 개념을 사용하여 구현될 것이지만, 아마도 같은 형식은 아닐 것이다. GNU 네트웍 파일 프로토콜이 곧 설계되던지 NFS가 결점을 제거하기 위해 확장될 것이다. GNU와 다른 OS간에 파일을 옮기고 싶은 사람들을 돕기 위해 MS-DOS파일시스템과 같은 여러 조그만 파일시스템이 있을 것이다. 터미널 I/O서버는 POSIX의 터미널 방식을 제공할 것이다. GNU C라이브러리는 통제 터미널(controlling terminal)을 추적하고 적당한 때에 적절한 통제 신호(contol signals)를 보내며 키보드와 중단(hangup) 신호를 따르는 기능을 제공한다. 프로그램은 여러가지 방식으로 통신 채널에 터미널 드라이버를 추가할 수 있을 것이다. rlogind와 같은 서버는 네트웍 통신 포트에 터미널 프로토콜을 추가할 수 있다. 오래된 프로그램의 하위 호환성을 위해 제공되겠지만 의사 터미널(pseudo-terminal)은 필요하지 않다. GNU의 어떤 프로그램도 이에 의존하지 않을 것이다. 터미널 드라이버의 어떤 것도 사용자에게 강요하지 않는다. 터미널 드라이버는 사용자가 내재한 통신 채널을 쉽게 얻을 수 있도록 하고, 필요할 때마다 또는 함께 자신을 지나칠 수 있고, 다른 터미널 드라이버과 같은 프로그램으로 대체할 수 있도록 한다. 마지막 경우에 대체 프로그램이 필요한 인터페이스를 구현한다면 보통 터미널 드라이버인 것처럼 정확히 C라이브러리에서 쓰일 것이다. 이 유연성때문에 원래의 터미널 드라이버는 복잡한 줄편집기능을 제공하지 않을 것이며, 자신을 POSIX와 BSD에서 찾을 수 있는 기능에 한정한다. readline기반의 터미널 드라이버가 만들어질 것인데, 이는 원하는 사용자를 위해 복잡한 줄편집기능을 제공할 것이다. 터미널 드라이버는 UUCP나 SLIP에서 필요한 큰 부피의 연속 데이터 전송 지원을 잘 하지 않을 것이다. 이 프로그램은 이들의 어떤 기능도 필요로 하지 않는다. 대신에 터미널을 위해 내장된 Mach장치 포트을 쓸 것인데, 이것은 많은 데이터의 전송을 효율적으로 지원한다. 프로그램 실행 execve시스템 콜의 구현은 세 프로그램 사이에 퍼져 있다. 라이브러리는 인수와 환경변수 벡터를 정리한다. 그러고서 이는 파일서버에 실행될 파일을 유지하는 메세지를 보낸다. 파일서버는 실행 권한을 점검하고 exec콜에 필요한 변환을 한다. 예를 들어 만약 파일이 setuid로 되어 있고 파일서버가 능력이 있으면 새 이미지의 사용자 확인을 바꿀 것이다. 또한 파일서버는 이전 작업에 억세스를 한 프로그램이 새 작업으로 억세스를 계속 해야 할 것인지 결정해야 한다. 파일서버가 권한을 증가하고 있거나 읽지 않은 이미지를 실행하면 exec는 보안을 유지하기 위해 새 Mach작업으로 대체할 필요가 있다. 새 이미지에 관련된 방법을 결정한 뒤 파일시스템은 exec서버에게 이 작업을 읽어들이도록 부른다. BFD(Binary File Descriptor)를 사용하는 이 서버는 이미지를 읽어들인다. BFD는 많은 객체 파일 형식을 지원한다. 거의 모든 지원하는 형식을 실행할 수 있을 것이다. 이 서버는 또한 #!으로 시작하는 스크립트를 다루고, 지시하는 프로그램을 통해 실행한다. 또한 표준 exec서버는 새 이미지의 환경변수를 본다. 만약 여기에 EXECSERVERS 환경변수가 있다면 시스템 기본값 대신 exec서버로 지정된 것을 사용한다(물론 파일서버가 안전하게 유지할것을 요구받은 exec에는 실행되지 않는다). 새 이미지는 GNU C라이브러리에서 실행되며, exec서버에게 인수, 환경변수, umask, 현재 디렉토리 등을 얻도록 메시지를 준다. 이 어떤 추가적인 상태도 파일이나 exec서버에게 특별한 것은 아니다. 만약 프로그램이 바란다면 라이브러리에서 다른 방식으로 사용할 수 있다. 새 프로세스 fork시스템 콜은 GNU C라이브러리에서 거의 다 구현되었다. 새 작업은 Mach커널 콜에 의해 만들어진다. C라이브러리는 이 이미지를 적절하게 상속되도록 정리한다. 새 작업은 프로세스 서버에 등록된다(필수적은 아니다). C라이브러리는 fork시에 부를 함수의 벡터를 제공한다. 한 벡터는 fork전에 불리고, 하나는 부모 프로세스에서 나중에, 하나는 자식 프로세스에서 나중에 불린다(이 기능은 일반적인 fork-콜 순서를 대체하기 위해 쓰이지는 않는다. 이는 fork가 일어나기 전에 포트를 닫거나 지워야 하는데 필요한 라이브러리를 위한 것이다). C라이브러리는 진행중인 POSIX.4a에 정의된 두개의 fork 콜을 구현한다(스레드 확장에서 실시간 확장으로 다루는 제안된 표준). 아무것도 사용자에게 이런 방법으로 작업을 만들라고 강요하지 않는다. 프로그램이 약간의 특징과 함께 거의 보통 fork만 사용하려고 하면 그렇게 할 수 있다. 후크는 C라이브러리가 제공할 것이고, 함수는 완전히 대체될 수도 있다. 이들 중 어느것도 전통적인 유닉스 시스템에서 가능하지 않다. 비동기 메세지 앞에서도 말했듯이 프로세스 서버는 등록하는 각 작업에 대한 메세지 포트를 유지한다. 이 포트는 공개이고, 작업에 비동기 메세지를 보내는데 쓰인다. 예를 들어 신호(signal)를 메세지 포트에 보낸다. 신호 메세지는 또한 신호를 보내기 위해 송신자를 믿어야 한다는 지시로 포트를 제공한다. GNU C라이브러리는 여러가지 포트를 제공하는데, 각각은 각 포트를 소유하는 누구에게나 보낼 수 있는 신호의 집합을 나타낸다. 예를 들어 사용자 프로세스가 작업의 커널 포트를 소유하면 어떤 신호를 보내는 것이 허가된다. 만약 사용자가 특별한 터미널 id포트를 소유하면 키보드나 중단 신호를 보낼 수 있다. 사용자는 C라이브러리의 신호 권한 표(signal permission table)에 임의의 새 신호를 등록할 수 있다. 프로세스의 프로세스 그룹이 바뀌면 프로세스 서버는 새 프로세스 그룹을 지시하는 신호를 보낼 것이다. 이 경우 프로세스 서버는 작업의 커널 포트를 제공하여 그 권위를 확인한다. C라이브러리는 또한 현재 프로세스에 의해 사용되는 uid를 더하고 지우기 위한 메세지를 갖는다. 프로그램에 새 uid가 보내지면 라이브러리는 이를 현재 집합에 더하고 새 인증을 밝히기 위하여 그가 아는 모든 I/O서버와 메세지를 교환한다. 비슷하게 메세제는 uid를 지울 수 있다. 후자에서 부른 이는 프로세스의 작업 포트를 제공해야 한다(권한을 더 주어서 프로세스에 해를 입힐 수는 없지만 권한을 빼앗을 수는 있다). Hurd는 사용자 프로그램이 이 메세지를 프로세스에게 보내는 기능을 제공한다. 예를 들어 su명령은 현재의 로그인 세션의 모든 프로그램이 서브쉘을 만들어내기 보다는 새 uid를 얻게 할 수 있다. C라이브러리는 프로그램이 인식하고 싶어하는 비동기 메세지를 더할 수 있게 하며, 또한 표준 집합을 인식할 수 없게 하는 일을 허가한다. 더 유닉스처럼 보이게 하기 C라이브러리는 BSD와 POSIX의 모든 콜와 여기에 대한 몇몇의 확장을 구현할 것이다. 이는 사용자가 싫어하는 콜을 대체하거나 완전히 넘어갈 수 있게 한다. 반면에 유닉스에서는 콜은 대체품 없이 '있는 그대로'써야 한다. 어떤 환경에서는 바이너리 호환도 지원할 수 있다. 이 작업은 프로세스의 어드레스 공간 어딘가에 적재되는 특별한 버전의 라이브러리를 만드는 것으로 동작한다(예를 들어 VAX에서는 이는 스택 위에 넣게 된다). 시스템 콜 전환(system call redirection)이라 불리는 Mach의 특징은 이때 유닉스 시스템 콜을 가로채어 이 특별한 버전의 라이브러리로 바꾸게 하는데 쓰인다(거의 모든 기계에서 이런 전환에 드는 비용은 아주 작다. 이는 Mach에서 아주 최적화된 길이다. 386에서는 약 20개의 명령인데, 이는 간단한 프로시저 콜보다 조금 나쁠 뿐이다). 신호 마스크와 벡터(signal masks and vectors)와 같은 유닉스의 많은 특징은 라이브러리에 의해 완전히 다루어진다. 이는 그런 특징을 유닉스에서보다 아주 싸게 구현하도록 한다. 다른 비용이 많이 드는 방법을 찾아내느니 임계지역(critical sections)을 보호하기 위해 sigblock을 확장하여 사용하는 것이 합리적이다. 네트웍 프로토콜 Hurd는 4.4BSD 프로토콜 스택을 Hurd로 옮기기 아주 쉽게 하는 라이브러리를 가질 것이다. 이는 가상적으로 자유롭게 BSD가 지원하는 모든 프로토콜의 동작을 가능하게 할 것이다. 현재 CCITT프로토콜, TCP/IP프로토콜, Xerox NS프로토콜과 ISO프로토콜이 포함되어 있다. 최적 성능을 내기 위해 초고속 I/O를 위해 제공되는 Hurd의 특징을 이용하는 작업이 필요하다. 대부분의 프로토콜에서 이는 약간의 생각을 필요로 하지만 많은 시간을 들이지는 않는다. Hurd는 TCP/IP프로토콜을 될 수 있는 대로 효율적으로 운영하게 될 것이다. Hurd설계의 유연성의 흥미있는 예제로 BSD에서 성능을 위해 확장하여 쓰이는 IP트레일러의 경우를 생각해 보자. Hurd는 트레일러를 보내고 받게될 것이지만, 이렇게 하여 얻을 수 있는 장점은 거의 없는데, 복사될 데이터의 요구가 없고 페이지 정렬된 데이터의 복사를 피하는 것은 부적절하기 때문이다. -------------------------------------------------------------------------------- 이 문서의 원본은 http://www.fsf.org/software/hurd/hurd-paper.html 에서 볼 수 있습니다. Hurd에 대한 더 자세한 정보를 얻으시려면 GNU의 Hurd Information Page를 참고하세요. 이 문서는 원본을 임의로 수정하지 않고