English [en]   català [ca]   Česky [cs]   Deutsch [de]   ελληνικά [el]   español [es]   suomi [fi]   français [fr]   hrvatski [hr]   Bahasa Indonesia [id]   italiano [it]   日本語 [ja]   한국어 [ko]   Nederlands [nl]   polski [pl]   русский [ru]   Shqip [sq]   Türkçe [tr]   українська [uk]   简体中文 [zh-cn]   繁體中文 [zh-tw]  

Это перевод страницы, написанной на английском языке.

Проект GNU

Ричард Столмен

Первоначально опубликовано в книге Открытые исходные тексты. Ричард Столмен никогда не был сторонником “открытого исходного текста”, но он передал эту статью, чтобы идеи движения за свободное программное обеспечение не отсутствовали в этой книге полностью.

Почему сейчас важно, как никогда, настаивать на том, чтобы программы, которыми мы пользуемся, были свободны.

Первое сообщество обмена программами

Когда в 1971 году я начал работать в Лаборатории искусственного интеллекта MIT [1], я стал частью сообщества обмена программами, которое существовало на протяжении многих лет. Обмен программами не ограничивался нашим конкретным сообществом; он был так же стар, как компьютеры, подобно тому, как обмен рецептами так же стар, как кулинария. Но мы занимались этим больше, чем большинство других.

ЛИИ пользовалась операционной системой под названием ITS [2] (Несовместимая система разделения времени), которую штатные хакеры (1) лаборатории спроектировали и написали на языке ассемблера компьютера PDP-10 компании Digital, одного из крупных компьютеров той эпохи. Моя работа как члена сообщества, штатного хакера ЛИИ, состояла в улучшении этой системы.

Мы не называли свои программы “свободными программами”, потому что такого термина не существовало; но именно этим они и были. Когда люди из другого университета или компании хотели перенести или воспользоваться программой, мы всегда с радостью позволяли им это. Если вы видели, что кто-то пользуется незнакомой и интересной программой, вы всегда могли попросить взглянуть на исходный текст, чтобы его можно было прочесть, изменить или разделать на запчасти для новой программы.

(1) Употребление слова “хакер” в значении “взломщик защиты” — ошибка, которой мы обязаны средствам массовой информации. Мы, хакеры, отказываемся признавать это значение и продолжаем употреблять это слово в значении “тот, кто любит программировать, кто получает удовольствие от игры мысли, или комбинация и того, и другого”. См. мою статью “О хакерстве”.

Гибель сообщества

Положение резко изменилось в начале восьмидесятых годов XX века, когда компания Digital прекратила поставки оборудования для серии PDP-10. Ее архитектура, изящная и мощная для шестидесятых, не могла естественным образом расширяться на более емкие адресные пространства, которые становились достижимы в восьмидесятых. Это значило, что почти все программы, составлявшие ITS, устарели.

Сообщество хакеров ЛИИ уже развалилось, незадолго до этого. В 1981 году отпочковавшаяся компания Symbolics переманила почти всех хакеров из ЛИИ, и обезлюдевшее сообщество было не в состоянии поддерживать себя (в книге Стива Леви “Хакеры” описаны эти события, а также дана ясная картина этого сообщества в его расцвете.) Когда в 1982 году ЛИИ купила новую PDP-10, администрация решила пользоваться несвободной системой разделения времени компании Digital вместо ITS.

У современных компьютеров той эпохи, таких, как VAX или 68020, были свои собственные операционные системы, но ни одна из них не была свободной: вам приходилось подписывать договор о неразглашении, чтобы получить хотя бы копию исполняемых файлов.

Это значило, что первым шагом в пользовании компьютером было обещание не помогать своему соседу. Сотрудничество в сообществе было запрещено. Правило, установленное владельцами несвободных программ, гласило: “Если вы обмениваетесь со своим соседом, вы — пират. Если вам нужны любые изменения, упрашивайте нас внести их”.

Мысль о том, что общественная система несвободного программного обеспечения — система, в которой говорят, что вам не позволено обмениваться программами или изменять их — антиобщественна, что она неэтична, что она просто неправильна, для некоторых читателей может стать неожиданностью. Но что еще мы могли бы сказать о системе, основанной на том, что людей разобщают и пользователей делают беспомощными? Читатели, которым эта мысль кажется неожиданной, возможно, приняли общественную систему несвободного программного обеспечения как данность или судили о ней в терминах, предложенных предприятиями, которые занимаются несвободными программами. Издатели программ долго и упорно работали над тем, чтобы убедить людей, что на вопрос можно смотреть только с одной позиции.

Когда издатели программ говорят об “осуществлении” своих “прав” или “прекращении пиратства”, то, что они говорят в действительности, вторично. Настоящее сообщение этих заявлений состоит в невысказанных допущениях, которые они считают само собой разумеющимися и которые общество просят принять без проверки. Итак, давайте их проверим.

Одно из допущений состоит в том, что у программистских компаний есть бесспорное естественное право владеть программами, а тем самым обладать властью над всеми пользователями этих программ. (Если бы это было естественным правом, то независимо от того, сколько вреда это причиняет обществу, мы не могли бы возражать.) Интересно, что конституция США и юридическая традиция отвергают эту точку зрения; авторское право не является естественным, это искусственная монополия, введенная государством, которая ограничивает естественное право пользователей копировать.

Другое невысказанное допущение состоит в том, что единственное, что важно в программе — это то, какую работу она позволяет вам выполнять; что нас, пользователей компьютеров, не должно беспокоить, какого рода общество нам позволено иметь.

Третье допущение состоит в том, что у нас не было бы программ, которыми можно было бы пользоваться (или никогда не появилось бы программы для выполнения той или иной конкретной задачи), если бы мы не предложили компании власть над пользователями этой программы. Это допущение, возможно, казалось правдоподобным до того, как движение за свободное программное обеспечение продемонстрировало, что мы можем сделать множество полезных программ, не налагая на них цепей.

Если мы отклоняем эти допущения и судим об этих вопросах на основе морали обычного здравого смысла, отдавая приоритет пользователям, то мы приходим к совершенно другим заключениям. Пользователи компьютеров должны быть вольны изменять программы под свои нужды и обмениваться программами, потому что помощь другим людям составляет основу общества.

Здесь недостаточно места для подробного изложения причин, приводящих к этому заключению, так что я отсылаю читателя к страницам http://www.gnu.org/philosophy/why-free.html и http://www.gnu.org/philosophy/free-software-even-more-important.html.

Жесткий нравственный выбор

Поскольку мое сообщество исчезло, я не мог продолжать жить, как раньше. Вместо этого передо мной встал жесткий нравственный выбор.

Легче всего было присоединиться к миру несвободного программного обеспечения, подписывая договоры о неразглашении и обещая не помогать своему брату-хакеру. Скорее всего, я также стал бы разрабатывать программы, которые выпускали бы на условиях неразглашения, увеличивая таким образом давление на других людей, чтобы они тоже предавали своих собратьев.

Я мог бы зарабатывать на этом деньги, и возможно, мне было бы интересно писать программы. Но я знал, что в конце своей карьеры я оглянулся бы на прошедшие годы, в которые я строил стены, чтобы разобщить людей, и ощутил, что я провел свою жизнь, делая мир хуже.

Я уже испытал на себе, что бывает, если другие подписывают договор о неразглашении, когда кто-то отказался дать мне и ЛИИ исходный текст программы управления нашим принтером. (Отсутствие определенных функций в этой программе приводило к тому, что работа с этим принтером просто выводила из себя.) Так что я не мог сказать себе, что договоры о неразглашении — это что-то невинное. Я очень разозлился, когда он отказался поделиться с нами; я не мог встать на его место и делать то же самое в отношении всех других.

Другой возможностью, простой, но неприятной, было бы покинуть отрасль вычислительной техники. В этом случае мои способности не пошли бы во вред, но они бы все-таки пропали впустую. Я не был бы виновен в разобщении и ограничении пользователей компьютеров, но тем не менее это происходило бы.

Так что я искал способ, которым программист мог бы делать что-то хорошее. Я спросил себя, не было ли программы или программ, которые я мог бы написать с тем, чтобы сообщество вновь стало возможным.

Ответ был ясен: что было нужно прежде всего — это операционная система. Эти программы жизненно важны для того, чтобы приступить к пользованию компьютером. Если есть операционная система, можно делать многое; без нее на компьютере нельзя работать вообще. Со свободной операционной системой у нас снова могло бы быть сообщество сотрудничающих хакеров — и мы могли бы приглашать любого присоединиться к нам. И любой был бы в состоянии пользоваться компьютером, не начиная с заговора, обездоливающего его друзей.

У меня как у разработчика операционной системы были нужные для этой работы навыки. Так что, хотя я и не мог твердо рассчитывать на успех, я осознавал, что сама судьба выбрала меня для этого дела. Я решил сделать систему совместимой с Unix, с тем чтобы она была переносима и чтобы пользователи Unix могли легко перейти на нее. Название “GNU” было выбрано по хакерской традиции как рекурсивное сокращение фразы “GNU — не Unix” [3].

Операционная система означает не только ядро, которого едва достаточно для выполнения других программ. В семидесятые годы XX века в каждую операционную систему, заслуживающую этого названия, входили командные оболочки, ассемблеры, компиляторы, интерпретаторы, отладчики, текстовые редакторы, почтовые программы и многое другое. Они были в ITS, они были в Multics, они были в VMS, они были и в Unix. Они будут и в операционной системе GNU.

Позднее я услышал такие слова, приписываемые Гиллелу (1):

Если я не за себя, кто будет за меня?
Если я только за себя, кто я такой?
Если не сейчас, когда?

Решение начать проект GNU было основано на похожем мироощущении.

(1) Как атеист я не являюсь последователем каких бы то ни было религиозных лидеров, но иногда я обнаруживаю, что восхищаюсь тем, что сказал кто-нибудь из них.

“Свободный” от слова “свобода”

Термин “свободная программа” иногда понимают неверно — он не имеет никакого отношения к стоимости. Он относится к свободе. Таким образом, вот определение свободной программы.

Программа свободна для вас, конкретного пользователя, если:

Поскольку “свободный” относится к свободе, а не стоимости, между продажей копий и свободными программами нет противоречия. На самом деле свобода продавать копии жизненно важна: сборники свободных программ, продаваемые на компакт-дисках, важны для сообщества, и их продажа — важный способ получить средства на развитие свободных программ. Таким образом, программа, которую люди не вольны включать в эти сборники, не является свободной.

Неоднозначность слова “свободный” привела к долгим поискам альтернатив, но никто не нашел лучшего термина. В английском языке больше слов и нюансов, чем в любом другом, но в нем не хватает простого однозначного слова, которое значит “свободный” от слова “свобода” — наиболее близко к этому значению подходит слово “нескованный”. Такие альтернативы, как “освобожденный”, “свобода” (“программы свободы”) и “открытый”, имеют либо неверное значение, либо какой-то другой недостаток.

Программы GNU и система GNU

Разработка целой системы — очень большой проект. Чтобы сделать это достижимым, я решил адаптировать и применять, где только возможно, существующие части свободных программ. Например, я с самого начала решил применять TeX в качестве основной программы форматирования текста; через несколько лет я решил воспользоваться системой X Window вместо того, чтобы писать еще одну оконную систему для GNU.

В результате этих и других подобных этим решениям система GNU — это не то же самое, что собрание всех программ GNU. Система GNU включает программы, которые не являются программами GNU — программы, которые разработаны другими людьми и проектами в их собственных целях, но которыми мы можем воспользоваться, потому что они свободны.

Начало проекта

В январе 1984 года я уволился из MIT и начал писать программы GNU. Уйти из MIT было необходимо, чтобы институт не смог помешать распространению GNU в качестве свободных программ. Если бы я остался в штате, институт мог бы заявить, что работа принадлежит ему, и навязать свои собственные условия распространения или даже обратить работу в пакет несвободных программ. Я был не намерен проделать большую работу только затем, чтобы увидеть, как она станет бесполезной для того, ради чего она затевалась — создания нового сообщества обмена программами.

Однако профессор Уинстон, тогдашний руководитель ЛИИ, любезно пригласил меня продолжать пользоваться ресурсами лаборатории.

Первые шаги

Вскоре после организации проекта GNU я услышал о “Наборе свободного университета для компиляторов” [4], известном также как VUCK. (Голландское слово “свободный” пишется через v.) Это был компилятор, спроектированный для работы со многими языками, включая Си и Паскаль, и для поддержки многих целевых машин. Я написал его автору и спросил, не может ли GNU воспользоваться этим компилятором.

Он ответил с насмешкой, заявив, что университет свободен, а компилятор — нет. Таким образом, я решил, что моей первой программой для проекта GNU станет многоязычный многоплатформенный компилятор.

Надеясь избежать необходимости писать весь компилятор самому, я достал исходный текст компилятора языка Пастель. Это был многоплатформенный компилятор, разработанный в Ливерморской лаборатории Лоуренса. Он поддерживал расширенную версию языка Паскаль, задуманную как системный язык программирования, и был написан на этом языке. Я добавил предобработчик для Си и начал переносить его на компьютер Motorola 68000. Но мне пришлось бросить это, когда я обнаружил, что компилятору требуется много мегабайт стекового пространства, а доступная система Unix 68000 допускала только 64k.

Затем я осознал, что компилятор Пастели функционировал, преобразуя весь входной файл в синтаксическое дерево, переводя все дерево в цепочку “инструкций”, а затем генерируя весь выходной файл, не освобождая память ни на каком этапе. В этот момент я пришел к заключению, что мне придется написать новый компилятор с нуля. Новый компилятор известен как GCC [5], из компилятора Пастели в нем ничего не используется, но мне удалось адаптировать и использовать предобработчик Си, который я написал. Но это произошло несколько лет спустя; сначала я работал над GNU Emacs.

GNU Emacs

Я начал работать над GNU Emacs в сентябре 1984 года, и в начале 1985 года им можно было начинать пользоваться. Это позволило мне начать пользоваться системами Unix для редактирования; поскольку учиться пользованию vi или ed мне было не интересно, до этого я проводил редактирование на других видах машин.

В этот момент у людей начало возникать желание пользоваться GNU Emacs, что поставило вопрос о том, как его распространять. Конечно, я поместил его на сервере анонимного ftp на компьютере MIT, которым я пользовался. (Этот компьютер, prep.ai.mit.edu, стал, таким образом, основным сайтом ftp для распространения GNU; когда через несколько лет его списали, мы перенесли это имя на свой новый сервер ftp.) Но в то время многие заинтересованные люди не были в Интернете и не могли получить копию по ftp. Итак, вопрос был в том, что мне им говорить.

Я мог бы сказать: “Найдите знакомого, у которого есть сеть и который сделает вам копию”. Или я мог бы делать то, что я делал с первоначальным Emacs для PDP-10 — сказать им: “Пришлите мне ленту и конверт с маркой и обратным адресом, и я перешлю вам ее с записанным на ней Emacs”. Но у меня не было работы, и я подыскивал способы зарабатывать на свободных программах. Так что я объявил, что буду высылать ленту всем, кому она нужна, за 150 долларов. Таким образом я приступил к коммерческому распространению свободных программ, ставшему предтечей компаний, которые в наши дни распространяют целые системы GNU/Linux.

Для каждого ли пользователя программа свободна?

Если программа свободна, когда она выходит из рук автора, это не обязательно означает, что она будет свободной для всякого, у кого есть ее копия. Например, программы в общественном достоянии (программы, на которые не распространяется авторское право) свободны; но любой может сделать несвободную модификацию такой программы. Подобным образом, многие свободные программы находятся под действием авторского права, но они распространяются под простыми неограничительными лицензиями, что допускает несвободные модификации.

Хрестоматийной иллюстрацией этой проблемы является система X Window. Разработанная в MIT и выпущенная как пакет свободных программ под неограничительной лицензией, она вскоре была освоена различными компьютерными компаниями. Они добавили X к своим несвободным системам Unix, поставляя ее только в двоичном виде, и распространили на нее тот же самый договор о неразглашении. Эти копии X были не более свободны, чем Unix.

Разработчики системы X Window не считали это проблемой — они этого ждали, и это соответствовало их намерениям. Их целью была не свобода, а только “успех”, определяемый как “большое число пользователей”. Им было все равно, есть ли у этих пользователей свобода; они заботились только о том, чтобы пользователи были многочисленны.

Это привело к парадоксальной ситуации, в которой разные способы подсчета количества свободы дают разные ответы на вопрос “свободна ли программа?” Если бы вы судили на основании свободы, предоставляемой условиями лицензии MIT, то вы бы сказали, что X свободна. Но если бы вы мерили свободу среднего пользователя X, вам пришлось бы сказать, что она несвободна. Большинство пользователей X работало с несвободными версиями, поставляемыми с системами Unix, а не со свободной версией.

Авторское лево и GNU GPL

Целью GNU было дать пользователям свободу, а не просто быть популярной. Поэтому нам нужно было применять условия распространения, которые предотвратили бы обращение программ GNU в несвободные программы. Метод, которым мы пользуемся, называется “авторским левом”.(1)

Авторское лево пользуется авторским правом, но переворачивает его, чтобы оно служило целям, противоположным тем, для которых оно обычно используется: вместо того, чтобы быть средством ограничения программы, оно становится средством сохранения свободы программы.

Центральная идея авторского лева заключается в том, что мы даем всем разрешение исполнять программу, копировать программу, изменять программу и распространять измененные версии — но не разрешение добавлять свои собственные ограничения. Таким образом, жизненно важные свободы, определяющие “свободную программу”, гарантированы для каждого, у кого есть копия; они становятся неотчуждаемыми правами.

Чтобы авторское лево было действенным, измененные версии тоже должны быть свободны. Это гарантирует, что работа, основанная на нашей, становится доступной нашему сообществу, если ее публикуют. Когда программисты, которые работают программистами, безвозмездно улучшают программы GNU, именно авторское лево не дает их нанимателям сказать: “Вам нельзя обмениваться этими изменениями, потому что мы собираемся воспользоваться ими, чтобы сделать свою несвободную версию этой программы”.

Требование, что изменения должны быть свободны, существенно, если мы хотим гарантировать свободу каждого пользователя программы. Компании, которые сделали несвободные версии системы X Window, обычно вносили изменения, чтобы перенести ее на свои системы и свою аппаратуру. Эти изменения были малы по сравнению с широчайшим охватом системы X, но они не были тривиальны. Если бы внесение изменений оправдывало отказ пользователям в свободе, любому было бы легко воспользоваться этим оправданием.

В связи с этим возникает вопрос о сочетании свободной программы с несвободными исходными текстами. Такое сочетание неизбежно было бы несвободным; если несвободной части недостает каких бы то ни было свобод, этих же свобод недостает и всей программе в целом. Допустить такие сочетания означало бы открыть брешь, достаточную, чтобы потопить корабль. Следовательно, требование перекрыть эту брешь критично для авторского лева: все, что добавляется или сочетается с программой под авторским левом, должно быть таким, чтобы более крупная комбинированная версия также была свободной и чтобы на нее распространялось авторское лево.

Конкретная реализация авторского лева, которую мы применяем в большинстве программ GNU — это Стандартная общественная лицензия GNU, или сокращенно GNU GPL. У нас есть другие виды авторского лева, употребительные в особых обстоятельствах. Руководства GNU также выпускаются под авторским левом, но мы пользуемся гораздо более простым видом авторского лева, потому что для руководств не требуется вся сложность GNU GPL.(2)

(1) В 1984 или 1985 году Дон Хопкинс (малый с богатым воображением) прислал мне письмо. На конверте он написал несколько забавных изречений, в том числе такое: “Авторское лево — все права зареверсированы”. Я воспользовался выражением “авторское лево” в качестве названия концепции распространения, над которой я в то время работал.

(2) Сейчас для документации мы пользуемся Лицензией свободной документации GNU.

Фонд свободного программного обеспечения

По мере того как интерес к пользованию Emacs возрастал, в проект GNU стали вовлекаться другие люди, и мы решили, что пора снова поискать фонды. Итак, в 1985 году мы создали Фонд свободного программного обеспечения (ФСПО), благотворительную организацию, пользующуюся налоговыми льготами, для развития свободного программного обеспечения. ФСПО также взял на себя деятельность по распространению Emacs на лентах; впоследствии она дополнилась добавлением на ленту других свободных программ (как GNU, так и неGNU), а также продажей свободных руководств.

В те времена доход ФСПО состоял по большей части из прибыли от продажи копий свободных программ и других связанных с этим услуг (компакт-дисков с исходным текстом, компакт-дисков с двоичными файлами, прекрасно распечатанных руководств — все это со свободой изменять и распространять дальше) и дистрибутивов “люкс” (дистрибутивов, в которых мы транслировали полный сборник программ для выбранной клиентом платформы). Сегодня ФСПО по-прежнему продает руководства и другой товар, но основную часть средств он получает из членских взносов. Вы можете присоединиться к ФСПО на fsf.org.

Сотрудники Фонда свободного программного обеспечения написали и поддерживали некоторое количество пакетов программ GNU. Два из наиболее примечательных — библиотека Си и командный интерпретатор. Библиотека Си GNU — это то, чем каждая программа, работающая в системе GNU/Linux, пользуется для связи с Linux. Она была разработана штатным сотрудником Фонда свободного программного обеспечения, Роландом Мак-Грэтом. Командный интерпретатор, применяемый в большинстве систем GNU/Linux — BASH [6], “Опять оболочка Баурна”(1), разработанный сотрудником ФСПО Брайеном Фоксом.

Мы финансировали разработку этих программ, потому что целью проекта GNU были не только средства или среда разработки. Нашей целью была полная операционная система, а эти программы были нужны для достижения этой цели.

(1) “Опять оболочка Баурна” — игра слов, построенная на названии “Оболочка Баурна” — так называли обычный в Unix командный интерпретатор.

Поддержка свободных программ

Философия свободного программного обеспечения отвергает определенную широко распространенную деловую практику, но она не против предпринимательства. Когда предприятия уважают свободу пользователей, мы желаем им успеха.

Продажа копий Emacs иллюстрирует одну из разновидностей предпринимательской деятельности, основанной на свободных программах. Когда ФСПО взял это дело на себя, мне понадобился другой способ зарабатывать на жизнь. Я нашел такой способ в продаже услуг, связанных со свободными программами, которые я разработал. Сюда входило обучение таким предметам, как программирование GNU Emacs, настройка GCC и разработка программ (по большей части — перенос GCC на новые платформы).

Сегодня каждый из этих видов деятельности практикуется некоторым числом корпораций. Одни распространяют сборники свободных программ на компакт-дисках; другие продают услуги по поддержке разного уровня, начиная от ответов на вопросы пользователей и исправления ошибок и заканчивая добавлением новых серьезных функций. Мы даже начинаем встречать компании, занимающиеся свободными программами, основанные на выпуске новых свободных программных продуктов.

Однако будьте внимательны — некоторое число компаний, которые ассоциируют себя с термином “открытый исходный текст”, в действительности основывают свои предприятия на несвободных программах, которые работают со свободными программами. Эти компании не являются компаниями по разработке свободных программ — они занимаются несвободными программами, и продукты их заманивают пользователей прочь от свободы. Они называют эти программы “пакетами добавочной ценности”. Это показывает, какие ценности они хотели бы заставить нас усвоить: приоритет удобства над свободой. Если мы ценим свободу больше, мы должны называть эти пакеты “пакетами с дефицитом свободы”.

Технические цели

Основная цель GNU — быть свободным программным обеспечением. Даже если бы у GNU не было технических преимуществ перед Unix, у нее было бы социальное преимущество — позволение пользователям сотрудничать, и этическое преимущество — уважение свободы пользователя.

Но было естественно применять в работе известные стандарты хорошей практики — например, динамическое размещение структур данных, чтобы избежать произвольных фиксированных ограничений на размер, или обработку всех возможных 8-разрядных кодов везде, где это имеет смысл.

В дополнение, мы отказались от свойственной Unix оптимизации под небольшие размеры памяти, решив не поддерживать 16-разрядные машины (было ясно, что 32-разрядные машины будут нормой к тому времени, как система GNU будет завершена), и не пытаться снизить потребление памяти, если только оно не превышало мегабайта. В программах, для которых обработка очень больших файлов не была жизненно важна, мы рекомендовали программистам читать весь входной файл в память, а потом сканировать его содержимое, не беспокоясь о вводе-выводе.

Благодаря этим решениям многие программы GNU смогли превзойти свои аналоги из Unix по надежности и скорости.

Принесенные в дар компьютеры

По мере того, как репутация проекта GNU возрастала, люди стали предлагать в дар проекту машины под управлением Unix. Они были очень полезны, потому что самым простым способом разработки компонентов GNU было делать это в системе Unix и заменять компоненты этой системы один за другим. Но в связи с этим возникла этическая проблема: правильно ли было, что у нас вообще была копия Unix.

Unix была (и остается) несвободной, а согласно философии проекта GNU, нам не следует пользоваться несвободными программами. Но применив тот же ход рассуждений, который приводит к заключению, что насилие с целью самозащиты оправдано, я заключил, что применение несвободного пакета законно, когда это критично для разработки свободной замены, которая помогла бы другим прекратить пользоваться этим несвободным пакетом.

Но хотя это было оправданное зло, все-таки это было зло. Сегодня у нас больше нет никаких копий Unix, потому что мы заменили их на свободные операционные системы. Если мы не могли заменить операционную систему машины на свободную, мы вместо этого заменяли машину.

Список задач GNU

По мере осуществления проекта GNU и увеличения числа найденных или разработанных системных компонентов в какой-то момент стало полезно составить список оставшихся пробелов. Мы пользовались им для набора разработчиков, которые писали бы недостающие части. Этот список стал известен как “Список задач GNU”. В дополнение к недостающим компонентам Unix мы заносили туда разные другие полезные проекты по написанию программ и документации, которые, как мы думали, обязана содержать по-настоящему полная система.

Сегодня (1) в “Списке задач GNU” едва ли остались какие-нибудь компоненты Unix — все эти задачи были выполнены, кроме нескольких несущественных. Но список полон проектов, которые кто-то мог бы назвать “приложениями”. Любую программу, привлекательную более, чем для узкого класса пользователей, было бы полезно добавить к операционной системе.

В список задач включаются даже игры — и так было с самого начала. В Unix входили игры, так что в GNU они, естественно, тоже должны входить. Но для игр проблема совместимости не стояла, поэтому мы не повторяли список игр, которые были в Unix. Вместо этого мы записали целый спектр разного рода игр, которые могли бы понравиться пользователям.

(1) Это было написано в 1998 году. В 2009 году мы больше не поддерживаем длинный список задач. Сообщество разрабатывает свободные программы так быстро, что мы не можем даже отслеживать их все. Вместо этого у нас есть список высокоприоритетных проектов — гораздо более короткий список проектов, к осуществлению которых мы хотим поощрить людей прежде всего.

Библиотечная GNU GPL

Для библиотеки Си GNU использована особая разновидность авторского лева, названная Библиотечной стандартной общественной лицензией GNU (1), которая дает разрешение компоновать с этой библиотекой несвободные программы. Зачем было сделано это исключение?

Это не было делом принципа; нет принципа, согласно которому несвободные программные продукты вправе включать в себя наши программы. (Зачем вносить вклад в проект, в основе которого лежит отказ делиться с нами результатами?) Применение LGPL для библиотеки Си или для любой другой библиотеки — вопрос стратегии.

Библиотека Си выполняет общую задачу; любая несвободная система или компилятор поставляется с библиотекой Си. Следовательно, если бы мы сделали свою библиотеку Си доступной только для свободных программ, это не предоставило бы свободным программам никакого преимущества — это только создало бы стимул не пользоваться нашей библиотекой.

Для одной системы это не верно: в системе GNU (в том числе GNU/Linux) библиотека Си GNU — единственная библиотека Си. Так что условия распространения библиотеки Си GNU определяют, можно ли скомпилировать несвободную программу для системы GNU. Нет этической причины, по которой следует разрешать несвободные приложения в системе GNU, но со стратегической точки зрения кажется, что их запрет сильнее отвращал бы людей от пользования системой GNU, чем поощрял бы разрабатывать свободные приложения. Вот почему применение Библиотечной GPL — хорошее стратегическое решение для библиотеки Си.

Для других библиотек стратегическое решение нужно принимать отдельно для каждого случая. Когда библиотека решает специальную задачу, которая может помочь в написании программ определенных видов, то если выпустить ее под GPL, ограничивая только свободными программами, это будет одним из способов помочь разработчикам других свободных программ, давая им преимущество перед несвободным программным обеспечением.

Рассмотрим GNU Readline, библиотеку, разработанную, чтобы реализовать редактирование командной строки для BASH. Readline выпускается под обычной GNU GPL, а не Библиотечной GPL. Это, возможно, и сужает применение Readline, но для нас это не потеря. В то же время по меньшей мере одно полезное приложение сделали свободной программой именно для того, чтобы оно могло использовать Readline, а это реальный выигрыш для сообщества.

У разработчиков несвободных программ есть преимущества, предоставляемые деньгами; разработчикам свободных программ нужно создавать преимущества друг для друга. Я надеюсь, наступит день, когда у нас будет большой сборник библиотек под GPL, у которых нет аналогов, доступных для несвободных программ. Этот сборник будет предоставлять полезные модули в качестве строительных блоков для новых свободных программ, дополняться и со временем станет серьезным рычагом для дальнейшего развития свободных программ.

(1) Эта лицензия сейчас называется Меньшей стандартной общественной лицензией GNU, чтобы не наводить на мысль, будто все библиотеки обязаны пользоваться ею. Подробности см. в статье “Почему вам не следует применять Меньшую GPL для своей следующей библиотеки”.

Творческий зуд?

Эрик Реймонд говорит, что “любая хорошая работа по программированию начинается с удовлетворения личного творческого зуда разработчика”. Может быть, иногда так и происходит, но многие важные программы GNU были разработаны для того, чтобы получить полную свободную операционную систему. Их породило стратегическое планирование, а не импульс.

Например, мы разработали библиотеку Си GNU, потому что в системе типа Unix нужна библиотека Си, BASH — потому что в системе типа Unix нужен командный интерпретатор, GNU tar — потому что в системе типа Unix нужна программа tar. То же самое верно и для моих собственных программ — компилятора Си GNU, GNU Emacs и GNU Make.

Некоторые программы GNU разработаны, чтобы бороться с конкретными угрозами нашей свободе. Так, мы разработали gzip, чтобы заменить программу Compress, которая была потеряна для общества из-за патентов на LZW. Мы нашли людей для разработки Lesstif, а позднее организовали GNOME [7] и Harmony, чтобы решать проблемы, вызванные определенными несвободными библиотеками (см. ниже). Мы разрабатываем GNU Privacy Guard, чтобы заменить популярную несвободную программу шифрования, потому что пользователи не должны выбирать между конфиденциальностью и свободой.

Конечно, у людей, писавших эти программы, появлялся интерес к этой работе, и разные люди добавили к этим программам много возможностей для удовлетворения своих собственных нужд и интересов. Но это не причина существования этих программ.

Неожиданные разработки

В начале проекта GNU я представлял себе, что мы разработаем всю систему GNU, а затем выпустим ее целиком. Но вышло по-другому.

Поскольку каждый компонент системы GNU был реализован в системе Unix, каждый компонент мог работать в системах Unix задолго до появления полной системы GNU. Некоторые из этих программ стали популярными, и пользователи начали расширять и переносить их — на различные несовместимые версии Unix, а иногда и на другие системы.

В процессе этого программы становились гораздо эффективнее и привлекали как финансовые, так и человеческие ресурсы в проект GNU. Но это также, вероятно, отдалило завершение минимальной работающей системы на несколько лет, поскольку время разработчиков GNU уходило на поддержку этих перенесенных версий и добавление возможностей к существующим компонентам, вместо того чтобы переходить к написанию одного недостающего компонента за другим.

GNU Hurd

К 1990 году система GNU была почти завершена; единственным серьезным недостающим компонентом было ядро. Мы решили реализовать свое ядро как собрание серверных процессов, выполняющихся на Mach. Mach — микроядро, разрабатывавшееся в Университете Карнеги-Меллона, а затем — в Университете Юты; GNU Hurd — собрание серверов (т. е. табун GNU [8]), которые работают на Mach и выполняют различные задачи ядра Unix. Начало разработки отдалилось, поскольку мы ждали, когда Mach выпустят в качестве свободной программы, как было обещано.

Одной из причин, по которым мы выбрали такую архитектуру, было желание избежать того, что казалось труднее всего в этой работе: отлаживать программу ядра, не имея для этого отладчика уровня исходного текста. Эта часть работы уже была выполнена в Mach, и мы собирались отлаживать серверы Hurd как пользовательские программы, с помощью GDB. Но на то, чтобы сделать это возможным, ушла масса времени, а многопоточные серверы, которые рассылали друг другу сообщения, оказались очень трудны в отладке. Достижение стабильной работы Hurd растянулось на долгие годы.

Alix

Сначала не предполагалось, что ядро GNU будет называться Hurd. Первоначальное название было “Alix” — в честь женщины, которая была в то время моей любимой. Она, будучи системным администратором Unix, обратила внимание, что ее имя укладывается в обычную схему наименования версий системы Unix; в шутку она сказала своим друзьям: “Кому-нибудь следовало бы назвать ядро в мою честь”. Я ничего не ответил, но решил сделать ей сюрприз, назвав ядро “Alix”.

Но потом положение изменилось. Майкл (теперь Томас) Бушнелл, главный разработчик ядра, предпочел название “Hurd” и перенес название Alix на определенную часть ядра — ту, что перехватывала системные вызовы и обрабатывала их, рассылая сообщения серверам Hurd.

Впоследствии мы с Эликс разошлись, а она сменила имя; независимо от этого архитектура Hurd изменилась так, что библиотека Си стала рассылать сообщения серверам напрямую, и в результате компонент Alix исчез из системы.

Но до того, как все это произошло, ее знакомый наткнулся на название “Alix” в исходном тексте Hurd и упомянул об этом в разговоре с ней. Так что возможность найти ядро, названное в ее честь, у нее была.

Linux и GNU/Linux

GNU Hurd непригодно для повседневного пользования, и мы не знаем, будет ли оно когда-нибудь пригодно. У архитектурного решения, принятого на основании потенциальных возможностей, есть проблемы, вытекающие непосредственно из гибкости архитектуры, и неясно, можно ли их решить.

К счастью, доступно другое ядро. В 1991 году Линус Торвальдс разработал совместимое с Unix ядро и назвал его Linux. Сначала оно было несвободное, но в 1992 году он сделал его свободной программой; соединение Linux с не совсем полной системой GNU дало полную свободную операционную систему. (Конечно, соединение было само по себе большой работой.) Именно благодаря Linux мы можем сегодня по-настоящему работать на одной из версий системы GNU.

Мы называем эту версию системы “GNU/Linux”, чтобы показать, что она составлена из системы GNU с Linux в качестве ядра. Не приобретайте, пожалуйста, привычку называть всю систему “Linux”, потому что это значит приписывать нашу работу кому-то другому. Упоминайте, пожалуйста, равным образом и нас.

Наши трудности в будущем

Мы доказали, что мы способны разрабатывать широкий спектр свободных программ. Это не значит, что мы непобедимы и неудержимы. Несколько препятствий вносят неопределенность в наше будущее; преодоление их потребует непреклонной стойкости и упорства, иногда на протяжении долгих лет. Это потребует решимости, какую выказывают люди, когда они ценят свою свободу и не дают никому отнять ее.

В следующих четырех разделах обсуждаются эти препятствия.

Секретная аппаратура

У производителей аппаратуры есть все возрастающая тенденция хранить спецификации аппаратуры в секрете. Это затрудняет написание свободных драйверов, нужных для того, чтобы Linux и XFree86 могли поддерживать новую аппаратуру. Сегодня у нас есть полные свободные системы, но у нас не будет их завтра, если мы не сможем поддерживать завтрашние компьютеры.

Есть два способа преодоления этой проблемы. Программисты могут проводить обратную разработку, чтобы выяснить, как поддерживать эту аппаратуру. Остальные из нас могут выбирать аппаратуру, которая поддерживается свободными программами; по мере того, как наши ряды будут пополняться, хранить спецификации в секрете будет становиться катастрофически невыгодно.

Обратная разработка — большая работа; будут ли у нас программисты, решимости которых хватило бы на ее осуществление? Да — если мы воспитаем стойкую убежденность, что свободные программы — дело принципа, а несвободные драйверы недопустимы. Потратят ли многие из нас лишние деньги или хотя бы немного времени, чтобы мы могли пользоваться свободными драйверами? Да, если решимость обладать свободой не будет редкостью.

(Замечание 2008 года: этот вопрос также касается BIOS. Есть свободная BIOS, называемая LibreBoot (дистрибутив coreboot); проблема состоит в получении спецификаций на машины, чтобы LibreBoot мог их поддерживать без несвободных “клякс”.)

Несвободные библиотеки

Несвободная библиотека, которая работает под управлением свободных операционных систем, действует как западня для разработчиков свободных программ. Привлекательные особенности библиотеки — это приманка; если вы пользуетесь библиотекой, вы попадаете в западню, потому что ваша программа не может быть полезной частью свободной операционной системы. (Строго говоря, мы могли бы присоединить вашу программу, но она не будет работать, если ей будет недоставать библиотеки.) Хуже того: если программа, которая пользуется несвободной библиотекой, становится популярной, она может заманить в западню других ничего не подозревающих программистов.

Первым случаем этой проблемы стала библиотека Motif, еще в восьмидесятых. Хотя свободных операционных систем еще не существовало, было ясно, какой проблемой станет для них Motif впоследствии. Проект GNU ответил двумя мерами: он просил отдельных разработчиков свободных программ поддерживать свободные библиотеки органов управления X, а не только Motif, и просил найти кого-нибудь, кто написал бы свободную замену Motif. Работа заняла много лет; Lesstif, разработанная группой “Голодные программисты”, стала достаточно эффективной, чтобы поддерживать большинство приложений Motif, только в 1997 году.

Между 1996 и 1998 годами другая несвободная библиотека графического интерфейса пользователя, названная Qt, применялась для значительного корпуса свободных программ, графической среды KDE.

Свободные системы GNU/Linux были не в состоянии пользоваться KDE, потому что мы не могли пользоваться этой библиотекой. Однако некоторые коммерческие поставщики систем GNU/Linux, которые не придерживались свободных программ строго, добавляли KDE в свои системы — получая систему с повышенными возможностями, но сниженной свободой. Группа KDE активно поощряла других программистов применять Qt, и миллионы новых “пользователей Linux” никогда не озаряла мысль, что здесь есть какая-то проблема. Положение было очень печально.

Сообщество свободного программного обеспечения ответило на проблему двумя мерами: средой GNOME и библиотекой Harmony.

GNOME, Сетевая объектная модельная среда GNU — проект графической среды GNU. Начатый в 1997 году Мигелем де Иказа и развивавшийся при поддержке Red Hat Software, GNOME задался целью предоставить сходные средства графической среды, но с применением исключительно свободных программ. У него есть и технические достоинства, такие, как поддержка нескольких языков, а не только Си++. Но главным его назначением была свобода: чтобы не требовалось пользоваться никакими несвободными программами.

Harmony — совместимая библиотека для замены, спроектированная для того, чтобы было возможно выполнять программы KDE без Qt.

В ноябре 1998 года разработчики Qt объявили о смене лицензии, которая, когда она будет проведена, должна сделать Qt свободной. Это невозможно доказать, но я думаю, что частично это было вызвано решительным откликом сообщества на проблему, которую Qt представляла, когда была несвободной. (Новая лицензия неудобна и несправедлива, так что до сих пор желательно избегать Qt.)

[Последующее замечание: в сентябре 2000 года Qt была перевыпущена под GNU GPL, что по существу решило эту проблему.]

Как мы ответим на следующую соблазнительную несвободную библиотеку? Будет ли все сообщество понимать необходимость избегать западни, или многие из нас променяют свободу на удобство и породят серьезную проблему? Наше будущее зависит от нашей философии.

Патенты на программы

Самая опасная угроза, вставшая перед нами, исходит от патентов на программы, которые могут выносить алгоритмы и особенности программ за пределы свободного программного обеспечения на срок до двадцати лет. Заявки на патенты на алгоритм сжатия LZW были поданы в 1983 году, и мы до сих пор не можем выпускать свободные программы для создания настоящих сжатых файлов GIF. [На 2009 год сроки действия патентов истекли.] В 1998 году свободную программу для создания сжатой звукозаписи в формате MP3 удалили из дистрибутива под страхом патентного иска.

Есть два способа борьбы с патентами: мы можем разыскивать свидетельства того, что патент недействителен, и можем искать альтернативные способы решения задачи. Но каждый из этих методов работает только иногда; когда не помогает ни то, ни другое, патент может принудить все свободные программы мириться с отсутствием какой-то особенности, которой хотят пользователи. Что мы станем делать, когда это случится?

Те из нас, кто ценит свободные программы ради свободы, все равно останутся со свободными программами. При выполнении работы мы будем обходиться без запатентованных особенностей. Но люди, которые ценят свободные программы потому, что ожидают от них технического превосходства, вероятно, скажут, что программы не оправдали надежд, когда патент задержит их развитие. Таким образом, хотя полезно говорить о практической эффективности “базарной” схемы разработки, надежности и эффективности каких-то свободных программ, мы не должны на этом останавливаться. Мы должны говорить о свободе и принципах.

Свободная документация

Наибольший дефицит, который испытывают наши свободные операционные системы, состоит не в программах — он заключается в недостатке хороших свободных руководств, которые мы можем включать в свои системы. Документация — существенная часть любого пакета программ; когда у важного пакета программ нет хорошего свободного руководства, это серьезный пробел. Сегодня у нас много таких пробелов.

Свободная документация, как и свободные программы, отличается свободой, а не стоимостью. Критерий свободы руководства почти совпадает с критерием свободы программы: это вопрос предоставления всем пользователям определенных свобод. Перераспространение (в том числе коммерческая продажа) должно быть разрешено, в электронном виде и на бумаге, с тем чтобы руководство могло сопровождать каждую копию программы.

Разрешение вносить изменения тоже жизненно важно. Вообще я не считаю, что важно, чтобы людям было разрешено изменять любого рода статьи и книги. Например, я не думаю, что вы или я обязаны давать разрешение изменять такие статьи, как эта, описывающая наши действия и наши взгляды.

Но есть отдельная причина, по которой свобода изменения критична для документации свободных программ. Когда люди осуществляют свое право изменять программы и добавляют или изменяют ее особенности, если они сознательны, они будут изменять и руководство — с тем чтобы предоставить с измененной программой точную и полезную документацию. Несвободное руководство, не позволяющее программистам быть сознательными и проделать работу до конца, не удовлетворяет нуждам нашего сообщества.

Некоторого рода ограничения на то, как вносятся изменения, не представляют проблемы. Например, требования сохранять замечание об авторских правах первоначального автора, условия распространения или список авторов вполне допустимы. Также не представляет проблемы требование включать в измененные версии замечание о том, что они были изменены, и даже требование о сохранении целых разделов в неизменном виде (до тех пор, пока эти разделы посвящены нетехническим темам). Такого рода ограничения не представляют проблемы, потому что они не мешают сознательному программисту дорабатывать руководство в соответствии с изменениями в программе. Другими словами, они не препятствуют сообществу свободного программного обеспечения пользоваться руководством в полном объеме.

Однако должно быть возможно изменять все техническое содержимое руководства, а затем распространять результат на всех обычных носителях по всем обычным каналам; в противном случае ограничения сообществу мешают, руководство не свободно и нам нужно другое руководство.

Достанет ли у разработчиков свободных программ осведомленности и решимости на то, чтобы произвести весь спектр свободных руководств? В этом случае наше будущее опять зависит от философии.

Мы должны говорить о свободе

По сегодняшним оценкам существует десять миллионов пользователей систем GNU/Linux, таких, как Debian GNU/Linux и Red Hat “Linux”. Свободные программы приобрели такие практические достоинства, что пользователи скучиваются вокруг них по чисто практическим причинам.

Хорошие последствия этого очевидны: рост интереса к развитию свободных программ, числа клиентов предприятий, занимающихся свободными программами, повышение возможности поощрения компаний к разработке коммерческих свободных программ вместо несвободных программных продуктов.

Но интерес к программам растет быстрее, чем известность философии, на которой они зиждутся, а это ведет к неприятностям. Наша способность отвечать на трудности и угрозы, описанные выше, зависит от нашей воли твердо стоять за свободу. Чтобы гарантировать, что у нашего сообщества будет такая воля, нам нужно передавать эту мысль новым пользователям по мере того, как они вступают в сообщество.

Но нам этого не удается: работы по привлечению новых пользователей в наше сообщество намного опережают работы по обучению их гражданским нормам нашего сообщества. Нам нужно делать и то, и другое, соблюдая баланс между двумя этими видами деятельности.

“Открытый исходный текст”

Рассказывать новым пользователям о свободе стало труднее в 1998 году, когда часть сообщества решила прекратить пользоваться термином “свободная программа” и вместо этого говорить “программа с открытым исходным текстом”.

Некоторые из тех, кто выступал за этот термин, стремились избежать путаницы между “свободным” и “бесплатным” — это была разумная цель. Однако другие стремились оставить в стороне дух принципов, которые мотивировали движение за свободное программное обеспечение и проект GNU, и апеллировать вместо этого к руководителям и предприятиям, многие из которых придерживались идеологии, которая ставит выгоду выше свободы, выше единства, выше принципиальности. Таким образом, аргументация “открытого исходного текста” сосредоточена на возможности получения высококачественных эффективных программ, но обходит стороной идеи свободы, единства и принципиальности.

Журналы о “Linux” — яркий пример такого подхода: они полны рекламы несвободных программ, работающих с GNU/Linux. Когда появится следующий Motif или Qt, будут ли эти журналы предостерегать программистов от него, или они будут его рекламировать?

Поддержка предпринимательства может обогащать сообщество с разных сторон; при прочих равных условиях она полезна. Но если завоевывать их поддержку, говоря еще меньше о свободе и принципах, это может привести к катастрофе; это еще больше увеличивает дисбаланс между популярностью и гражданским воспитанием.

“Свободные программы” и “открытый исходный текст” описывают одну и ту же категорию программ (более или менее), но о свободе, о ценностях они говорят разное. Проект GNU продолжает употреблять термин “свободная программа”, чтобы выразить мысль, что важна свобода, а не только техника.

Попытайся!

Афоризм Йоды (“‘Попыток’ не бывает”) звучит хорошо, но для меня он не подходит. Когда я делал свою работу, я почти всегда беспокоился, сумею ли я ее выполнить, и я не знал наверняка, будет ли достаточно для достижения цели, если я ее выполню. Но я все равно пытался, потому что между врагом и моим городом не было никого, кроме меня. К моему собственному удивлению, кое-что мне удавалось.

Кое-что мне не удавалось; некоторые из моих городов пали. Тогда я находил другой осажденный город и готовился к другой битве. Со временем я приучился искать угрозы и ставить себя между ними и моим городом, призывая других хакеров встать рядом со мной.

Сегодня я часто не одинок. С радостью и облегчением я вижу ряды хакеров, которые окапываются, чтобы держать линию обороны, и я осознаю, что этот город, возможно, выдержит осаду — на этот раз. Но опасности растут с каждым годом, и уже компания Microsoft открыто ополчилась на наше сообщество. Мы не можем думать, что будущее свободы обеспечено. Не думайте так! Если вы хотите сохранить свою свободу, вы должны быть готовы защищать ее.

Примечания переводчиков

  1. Massachusetts Institute of Technology (Массачусетский технический институт).
  2. Incompatible Timesharing System.
  3. GNU's Not Unix.
  4. Free University Compiler Kit; название может также интерпретироваться как “свободный университетский набор для компиляторов”.
  5. GNU Compiler Collection (сборник компиляторов GNU).
  6. Bourne Again Shell.
  7. GNU Network Object Model Environment (Сетевая объектная модельная среда GNU).
  8. По-английски “табун” (herd) звучит так же, как название ядра (Hurd).

[Эмблема ФСПО]“Наша задача — сохранение, защита и поддержка свободы использования, изучения, модификации, копирования и распространения компьютерных программ, а также защита прав пользователей свободных программ”.

Фонд свободного программного обеспечения — ведущая организация, ответственная за разработку операционной системы GNU. Поддержите GNU и ФСПО покупкой руководств и других товаров, присоединением к ФСПО в качестве члена-партнера или пожертвованиями, прямо в фонд или по Flattr.

к началу