Проект GNU
(The GNU Project)

 [изображение What's GNU]

Ричард Столлмен (Richard Stallman)

Сергей Короп (пер. с англ.)

впервые опубликовано в книге "Open Sources"

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

Когда я начинал работать в MIT Artificial Intelligence Lab (Лаборатория искусственного интеллекта Массачусетского Технологического Института, далее AI Lab) в 1971, я стал членом общества "программной взаимопомощи" (software-sharing community), существовавшего уже много лет. Подобная взаимопомощь не была ограничена нашим сообществом: она была столь же стара, как сами компьютеры, подобно тому, как привычка делиться рецептами---ровесница кулинарии. Но мы делали это более активно, чем другие.

В AI Lab использовалась операционная система с разделением времени, называемая ITS (Несовместимая Система Разделения Времени, Incompatible Timesharing System), которую хакеры1, работавшие в лаборатории, спроектировали и реализовали на ассемблере Digital PDP-10, одного из тогдашних компьютеров. Мне, как члену этого общества и системному хакеру AI lab, предстояло развивать систему.

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

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

Ситуация резко изменилась в начале 1980-х, когда Digital отказалась от дальнейшего развития семейства PDP-10. Ее архитектура, элегантная и мощная для 60-х, не позволяла легко увеличить размер адресного пространства, что стало возможным в 80-х. Это значило, что почти все программы, составляющие ITS, устарели.

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

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

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

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

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

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

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

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

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

Объем публикации не оставляет места для более подробного разъяснения этого вывода, поэтому читателям следует обратиться к странице http://www.gnu.org/philosophy/why-free.ru.html.

Проблема морального выбора

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

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

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

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

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

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

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

Как разработчик операционных систем, я обладал требуемыми для этой работы навыками. Поэтому, хоть я и не ожидал непременного успеха, я чувствовал, что могу выполнить ее. Было решено сделать систему совместимой с Unix и переносимой, так что пользователи Unix могут легко перейти к ней. Название GNU было выбрано согласно хакерским традициям, как рекурсивный акроним "GNU's Not Unix" (GNU, не Unix).

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

Позднее я услышал такие слова, автором которых считается Гиллель2:

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

Решение начать разработку проекта GNU основано на похожих принципах.

"Свободный"---не значит "даром"

Термин "свободное ПО" часто понимают неправильно---он не имеет общего с ценой. Речь ведется о свободе. Таким образом, вот определение свободного ПО: программа является свободной для вас, конкретного пользователя, если:

Поскольку "свободный" подразумевает свободу, а не цену, нет противоречий между продажей копий и свободным ПО. Фактически, свобода продажи копий является существенной: продажа коллекций свободного ПО на CD-ROM важна для общества и является хорошим способом получить средства на разработку свободного ПО. Следовательно, программы, которые невозможно включить в такие коллекции, не являются свободными.

Вследствие неоднозначности слова "free" (которое в английском языке употребляется как в значении "свободный", так и "бесплатный",--- прим. перев.) многие пытались найти ему замену, но пока что это никому не удалось. Английский язык содержит множество различных способов отображения самых тонких нюансов, но в нем нет простого, однозначного слова, которое подразумевало бы "free", как свободу; ближе всего по смыслу к этому приближается "unfettered" ("лишенное оков", "нестесненное"). Такие альтернативы, как "liberated" (освобожденный), "freedom" (свобода) и "open" (открытость) имеют либо неверное значение, либо иные недостатки.

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

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

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

Зарождение проекта

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

В то же время профессор Уинстон (Winston), глава MIT AI Lab, любезно предложил мне продолжать пользоваться возможностями лаборатории.

Первые шаги

Вскоре после начала проекта GNU я услышал о Free University Compiler Kit (Набор Компиляторов Свободного Университета), также известном как VUCK. (Голландское слово, обозначающее "free", т.е. "свободный", пишется через V.) Этот компилятор был разработан для поддержки множества языков, включая C и Pascal, и множества целевых платформ. Я запросил у автора разрешение использовать его для GNU.

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

В надежде избежать разработки компилятора целиком, я раздобыл исходники компилятора Pastel, многоплатформного компилятора, разработанного Lawrence Livermore Lab. Он поддерживал (и сам был написан) расширенный диалект языка Pascal, предназначенный для системного программирования. Я добавил в него поддержку C, и начал переносить его на Motorola 68000. Но мне пришлось отказаться от этого, когда я обнаружил, что компилятору требуются мегабайты под стек, в то время, как доступная на 68000 Unix-система ограничивается лишь 64k.

Оказалось, что компилятор Pastel сначала строил по всему входному файлу дерево разбора, далее конвертировал его в цепочку "инструкций", а затем генерировал целиком выходной файл, вовсе не освобождая памяти. На этом этапе я заключил, что все-таки придется написать новый компилятор с самого начала. Новый компилятор известен сегодня как GCC; никакие части Pastel в нем не использованы, но мне довелось адаптировать и использовать уже написанный мной код поддержки C. Но все это случилось несколькими годами позднее, а в то время я работал над GNU Emacs.

GNU Emacs

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

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

Я мог бы им сказать: "Найдите того, кто имеет доступ в Сеть и может скачать его для вас." Еще я мог поступить, как это было с оригинальной версией Emacs для PDP-10 и заявить: "Вышлите мне ленту и я верну ее вам с Emacs." Но я не имел работы и разыскивал способы зарабатывать на свободном ПО. Поэтому я объявил, что вышлю всем желающим ленту за $150. Тем самым было положено начало бизнесу, связанному с распространением свободных программ, предшественник фирм, которые сегодня распространяют завершенные системы GNU/Linux.

Свободен ли каждый пользователь программы?

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

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

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

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

Принцип "авторского лева" и GNU GPL

Целью GNU было дать пользователям свободу, а не только завоевать популярность. Следовательно, нам были нужны условия распространения, которые защитят программы GNU от превращения в собственнические. Используемая методика получила название "авторское лево" (в противоположность "праву"), или "copyleft"3.

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

Центральная идея "авторского лева" в том, что мы даем каждому разрешение запускать, копировать, изменять программу и распространять измененные версии---но не разрешение добавлять ограничения от себя. Этим критические свободы, которые определяют "свободное ПО" гарантируются каждому, кто имеет копию, они становятся неотчуждаемыми.

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

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

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

Частная форма "авторского лева" используется для большинства программ GNU --- это Универсальная Общественная Лицензия GNU (GNU General Public License, или GNU GPL). Мы также имеем другие виды "авторского лева" для особых случаев. Документация GNU также подчинена "авторскому леву", но в значительно более мягкой формулировке, поскольку изощренность GNU GPL избыточна для документации.

Фонд Свободного ПО

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

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

Персоналом Free Software Foundation разработаны и сопровождаются многочисленные программные пакеты, к примеру, C-библиотека и командный интерпретатор (shell). Библиотека GNU C используется всеми программами в системе GNU/Linux как посредник в общении прикладной программы с Linux. Она была разработана сотрудником FSF Роландом МакГрафом (Roland McGrath). Командный интерпретатор, использующийся в большинстве систем GNU/Linux --- BASH, Bourne Again Shell4, написанный служащим FSF Брайаном Фоксом (Brian Fox).

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

Поддержка свободного ПО

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

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

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

Однако, будьте осторожны---многие из тех, кто заявляет о следовании идее "открытых исходных текстов" в действительности основой своего бизнеса делают несвободные программы, которые работают совместно со свободными. Эти компании далеки от свободного ПО, это разработчики собственнических программ, которые искушают пользователей позабыть свободу. Они называют это "добавлением стоимости" (value added), отражая этим ценности, которые хотят навязать нам: удобства превыше свободы. Если мы предпочитаем свободу, нам следует называть подобные программы "с уменьшением свободы" (freedom subtracted).

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

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

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

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

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

Пожертвование компьютеров

С ростом репутации проекта GNU нам стали жертвовать машины с системой Unix. Это было очено полезно, поскольку простейшим способом разработать компоненты системы GNU было сделать это на Unix-системе и заменить ее компоненты одну за одной. Но при этом возникло этическое противоречие: можем ли мы использовать для этой работы Unix?

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

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

Список задач проекта GNU

По мере развития проекта GNU и роста количества системных компонент, которые мы разыскивали либо разрабатывали, стало желательным сделать список остающихся прорех. Мы использовали его для привлечения желающих написать недостающие компоненты. Этот список стал известным как "список задач проекта GNU" (GNU project task list). В дополнение к отсутствующим компонентам Unix мы включили в него другие полезные проекты разработки программ и документации, которые, по нашему мнению, должна иметь действительно завершенная система.

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

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

Библиотечная Лицензия GNU

Библиотека GNU C использует особую разновидность "авторского лева", называемую Библиотечной Лицензией GNU (GNU Library General Public License, в настоящий момент изменила свое название на GNU Lesser General Public License---Прим. перев.), которая дает разрешение компоновать библиотеку с собственническими программами. Зачем сделано это исключение?

Это не было делом принципа: нет принципа, согласно которому разработчикам собственнического ПО дается право использовать наш код. (Зачем нам участвовать в развитии проекта, который определенно не будет сотрудничать с нами?) Использование LGPL для стандартной C-библиотеки либо другой, является стратегическим ходом.

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

Одна система является исключением: в системе GNU (включая GNU/Linux), библиотека GNU C --- единственная C-библиотека. Поэтому условия распространения библиотеки GNU C определяют, в каких случаях допустима компиляция собственнической программы под систему GNU. Нет повода способствовать появлению собственнических приложений в ее составе, было бы стратегически неверным запрещать их, что лишь сократило бы применение системы GNU, а не поощряло разработку свободных программ.

Вот почему использование Библиотечной Лицензии GNU удобно для C-библиотеки. В случае других библиотек, стратегия их лицензирования должна выбираться индивидуально. Когда библиотека реализует специфические возможности, которые помогают в написании определенных видов программ, то выпуск ее на условиях обычной GPL ограничит сферу ее применения исключительно свободным ПО и даст этим преимущество разработчикам свободных программ над разработчиками собственнических.

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

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

Профессиональный зуд?

Эрик Реймонд (Eric Raymond) сказал, что: "Работа над каждой хорошей программой начинается автором для удовлетворения своего профессионального зуда" (scratching a developer's personal itch). Возможно, так иногда и бывает, но многие важные составляющие GNU были разработаны с целью создать полноценную свободную ОС. Они появились на свет благодаря нашему видению проблемы и плану действий, а не вследствие импульсивного решения.

Например, мы разработали библиотеку GNU C потому, что Unix-подобная система требует такой библиотеки, и Bourne-Again Shell (bash), поскольку Unix-подобная система требует командного интерпретатора, а также GNU tar, так как аналог Unix должен иметь программу tar. То же самое справедливо и в отношении моих собственных программ --- компилятора GNU C, GNU Emacs, GDB и GNU Make.

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

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

Незапланированные разработки

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

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

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

GNU Hurd

В 1990 система GNU была почти завершена; единственной важной нехваткой было ядро. Мы решили реализовать его как набор процессов-серверов, работающих поверх Mach. Mach --- это микроядро, разработанное в университете Карнеги-Меллон (Carnegie Mellon University) и позднее в университете штата Юта (University of Utah); GNU HURD --- коллекция серверов, (или ``стадо гну'', ``herd of gnus''), выполняемая поверх Mach и реализующая различные функции ядра Unix. Начало работ было задержано ожиданием выпуска Mach как свободного ПО, как нам пообещали.

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

Alix

Изначально ядро GNU не планировалось называть HURD. Его первым названием было Alix (Аликс)--имя женщины, которую я любил тогда. Она была администратором Unix-системы и однажды заметила, как хорошо ее имя подходит под общий принцип именования клонов Unix. В шутку она сказала своим друзьям: "Кому-то следует назвать ядро в мою честь." Я промолчал, но решил сделать ей сюрприз, назвав свое ядро Alix.

Но все произошло по-другому. Майкл Бушнел (Michael Bushnell, ныне Thomas), главный разработчик ядра, предпочитал название HURD, и назвал Alix некоторую часть ядра, которая перехватывала системные вызовы и обрабатывала их посылкой сообщений серверам HURD.

В конце концов, Аликс и я разошлись, она сменила имя; в то же время дизайн HURD также изменился и C-библиотека смогла посылать сообщения непосредственно серверам, так что компонент Alix исчез.

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

Linux и GNU/Linux

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

Мы назваем такую версию GNU/Linux, выражая тем самым, что она скомбинирована из системы GNU и Linux в качестве ядра.

Угрозы нашему будущему

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

Эти угрозы обсуждаются ниже.

Засекречивание оборудования

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

Есть два пути решить эту проблему. Программисты могут делать реконструкцию (reverse engineering) устройств, чтобы понять, как с ними работать. Все остальные в состоянии выбирать только те устройства, которые поддерживаются свободным ПО. С ростом нашего сообщества засекречивание спецификаций обернется против его инициаторов.

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

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

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

Первым примером этой проблемы, проявившимся еще в 1980-е годы, был Motif. Хотя в те времена не было свободных ОС, было ясно что Motif создаст множество проблем позднее. Проект GNU ответил двумя путями: призывал разработчиков использовать в своих проектах альтернативные свободные библиотеки X widgets наряду с Motif, и обратился к желающим создать свободный заменитель Motif. Работа потребовала многих лет: LessTif, разработанный Hungry Programmers, приобрел возможности, достаточные для большинства Motif-приложений, лишь в 1997 г.

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

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

Ответом общества свободного ПО были GNOME и Harmony.

GNOME (Модель Сетевой Объектной Среды GNU, GNU Network Object Model Environment) является проектом создания GNU-десктопа. Начатый в 1997 Мигелем де Иказа (Miguel de Icaza) и разрабатываемый при поддержке Red Hat Software, GNOME будет поддерживать схожие со своими аналогами возможности, но исключительно при помощи свободного ПО. У него есть и технические преимущества, такие, как поддержка широкого спектра языков, не только C++. Но главной целью была свобода --- исключение зависимости от несвободных программ.

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

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

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

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

Серьезнейшей угрозой для нас являются патенты, которые лишают разработчиков свободного ПО права использовать алгоритмы и возможности на срок до 20 лет. Патенты на алгоритм сжатия LZW были выданы в 1983, и мы по-прежнему не можем выпустить свободное ПО, генерирующее правильные файлы формата GIF. В 1998 свободная программа сжатия аудиозаписей методом MP3 была исключена из дистрибутива под угрозой патентного иска.

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

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

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

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

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

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

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

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

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

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

Мы должны пропагандировать свободу

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

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

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

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

"Открытые исходные тексты"

Обучать свободе новых пользователей стало еще труднее, когда в 1998 часть нашего сообщества решила не использовать более термин "свободное ПО" ("free software"), а вместо него предложила понятие "ПО с открытыми исходными текстами" ("open source software").

Некоторые из сторонников нового термина намеревалась устранить путаницу "свободного" ("free") с "бесплатным" ("gratis")---хорошая цель. Другие, в то же время, собирались отправить за борт дух нашего сообщества и те принципы, которые служат мотивацией для движения за свободу ПО и проекта GNU, а вместо них ориентироваться на руководителей компаний и предпринимателей, многие из которых ставят прибыль превыше свободы, превыше интересов общества, превыше моральных принципов. Поэтому ораторские способности сторонников "открытых исходных текстов" направлены на перспективы создания высококачественных и мощных программ, но не на идеи свободы и сотрудничества.

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

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

Термины "свободное ПО" и "ПО с открытыми исходными текстами" описывают, более или менее, одну и ту же категорию ПО, но различаются в том, что именно говорится о программах и о моральных ценностях. Проект GNU продолжает использование понятия "свободное ПО", выражая тем самым, что важна идея свободы, а не просто технологии.

Пытайтесь!

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

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

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


Примечания автора

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

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

3) В 1984 или 1985 Дон Хопкинс (Don Hopkins) (обладатель очень богатого воображения) прислал мне письмо. На конверте он написал несколько забавных фраз, включая такое: "Copyleft--all rights reversed." Я использовал слово "copyleft", чтобы назвать концепцию распространения программ, котрую разрабатывал в это время.

4) "Bourne again Shell" --- шуточная переделка ``Bourne Shell'', названия обычного командного интерпретатора под Unix.


Переводчик искренне благодарит Марию Суханову за конструктивное обсуждение и советы.
Возврат к титульной странице GNU (Англ.).

Вопросы о деятельности FSF и проекте GNU направляйте по адресу gnu@gnu.org, либо свяжитесь с FSF иным способом.

Внимание! Эта страница НЕ поддерживается FSF, который не несет никакой ответственности за ее содержание и/или оформление.

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

Copyright (C) 1998 Richard Stallman.

© 1999 Перевод на русский язык: Сергей Короп <svk@lib.ru>.

Разрешается копирование и распространение этой статьи любым способом без внесения изменений, при условии, что это разрешение сохраняется.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Перевод выполнен по версии статьи от 29 июля 1999.