История возникновения свободного ПО

А-а-а! надо поудалять "патенты"!

Разработка ПО как научное исследование

Особенность программного обеспечения состоит в том, что оно производится в одной форме -- в виде исходного текста (source code), а распространяется и используется в другой -- в виде двоичной программы, машинных кодов, по которым невозможно однозначно восстановить исходный текст. Чтобы изменять программу, исправлять ошибки или даже просто точно установить, что и как делает программа, необходимо располагать её исходным текстом.

Первоначально создание программного обеспечения для компьютеров было в первую очередь академическим занятием. Для специалистов в области компьютерной науки (computer science) каждая программа представляла собой результат научного исследования, в некотором смысле аналогичный публикации статьи. Это означает, что исходный текст программы был обязательно доступен всему научному сообществу, поскольку любой научный результат должен быть верифицируем, т. е. подтверждаться другими исследователями и быть открытым для критики. Таким образом, процесс разработки программного обеспечения более принципиально схож с научным процессом: учёный брал существующие программы, исправлял их в соответствии со своими идеями и публиковал исправленные программы -- новый результат.

Однако технология производства компьютеров развивалась не менее активно, чем программное обеспечение для них. В 1970-е годы существует огромное разнообразие различных архитектур вычислительных машин, различавшихся также и производительностью, и ценой. Естественно, для каждой архитектуры приходилось разрабатывать отдельный набор программного обеспечения. С середины 1970-х в большинстве американских университетов (где преимущественно и развивалась компьютерная наука) для академических разработок использовались компьютеры архитектуры PDP-10, что позволило сотрудникам разных университетов использовать разработки друг друга на своих машинах. Сотрудники лаборатории искусственного интеллекта массачуссетского технологического института в конце 1970-х разработали для PDP-10 собственную операционную систему ITS (Incompatible Timesharing System, несовместимая система с разделением времени) и очень большой набор программ для неё. Исходные тексты написанных в МТИ программ были общедоступны, сотрудники других университетов пользовались их исходными текстами и присылали им исправления, всё программное обеспечение в этих лабораториях было полностью академическим, а среди учёных-разработчиков был настоящий дух сотрудничества.

ПО и защита от копирования

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

В ситуации, когда программное обеспечение является объектом продажи наравне с предметами обихода, на него автоматически распространяются уже не только законы научной разработки, но и свойства материальных предметов, которыми можно торговать, обмениваться, право владения и пользования которыми стоит охранять законодательно. Так, программное обеспечение попало в разряд интеллектуальной собственности: т. е. исходный текст программы стал рассматриваться как произведение, объект применения авторского права. Чтобы защитить свои интересы, производители компьютеров и программного обеспечения используют лицензии -- вид договора между обладателем авторских прав и пользователем (покупателем) программного обеспечения. Подобные договоры заключались и с университетами, например, университету передавались исходные тексты программ и право их изменять, но запрещалось распространять их за пределами университета. Подобные ограничения означали, что тексты соответствующих программ не могли открыто обсуждаться в сообществе, т. е. не существовали для научной разработки. Были у компьютеров и программного обеспечения покупатели и вне академической среды, например, банки. Таким пользователям не столь важно получить исходные тексты программ, они заинтересованы в программном обеспечении как в законченном продукте и готовы платить деньги за надёжные и удобные программы.

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

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

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

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

Здесь-то и становится видна другая сторона медали. Не надо быть семи пядей во лбу, чтобы увидеть, каким образом превратить "ущерб" от безущербного копирования в прибыль. Достаточно, воспользовавшись авторским правом, запретить как прямое копирование, так и частичное воспроизведение программного продукта, если это происходит без санкции правообладателя, а санкцию эту выдавать за деньги. Главный недостаток такого бизнеса в области программного обеспечения заключается в том, что придётся резко ограничить доступ к исходным текстам программ (чтобы никто другой не смог получить их них программный продукт). А это ограничение очень сильно бьёт по традиционной академической стратегии разработки программ, когда именно исходные тексты доступны совершенно свободно, и всякий, кто способен внести в них какое-либо улучшение, вправе это сделать.

В результате образуется ситуация отчуждения программного продукта от его авторов: авторские права на такую несвободную программу принадлежат в большинстве случаев корпорациям и фирмам, которые продают её экземпляры, автор же ничего не может поделать с текстом, который, вроде бы, сам написал. Более того, сама корпорация вынуждена отказаться почти от всех выгод старого "академического" стиля разработки ради возможности извлекать прибыль из факта копирования. Отчуждённый таким образом программный продукт мы будем называть "правовладельческим" -- в силу того, что основная деятельность бизнеса вокруг него сосредоточена в манипуляции авторскими правами(1). Подразумевается наличие у правовладельческой программы собственника, который относится к ней как к материальному объекту.

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

Появление свободного ПО

Компьютеры развивались очень быстро, и бывшие вполне современными в 1970-е PDP-10 к началу 1980-х уже устарели, и значительно отставали по производительности от более современных машин. Однако ни для одной из новых архитектур уже не было операционной системы и прочего программного обеспечения, разработанного исключительно в академической среде. Университеты должны были покупать новые компьютеры с новым программным обеспечением и выполнять условия лицензии, ограничивающей их права на разработку и распространение ПО, иначе говоря, ограничивающей возможность научной модели разработки программного обеспечения.

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

Одному из сотрудников, оставшемуся в лаборатории искусственного интеллекта МТИ, Ричарду Столлману, такое положение дел казалось недопустимым нарушением открытого научного процесса разработки программного обеспечения. Он в одиночку пытался в рамках прежней академической модели развивать LISP-машины и открыто реализовывать изменения, аналогичные сделанным в рамках закрытой коммерческой разработки, чтобы LISP-машины МТИ могли конкурировать с правовладельческими аналогами. Конечно, эта попытка угнаться за активной разработкой целой компании была обречена на неудачу.

Тогда в поисках единомышленников Ричард Столлман создаёт некоммерческую организацию Фонд свободного программного обеспечения (Free Software Foundation, FSF). Своей основной целью Фонд ставит сохранение программного обеспечения, процесс разработки которого всегда будет гарантированно открытым, а исходные тексты всегда доступны. Более масштабная цель Фонда -- разработка операционной системы, целиком состоящей из открыто разрабатываемого программного обеспечения. Декларируя такую цель Столлман, фактически хотел вернуть представлявшееся ему идеальным состояние, когда в МТИ работали в собственной операционной системе для PDP-10.

Операционная система, разрабатываемая в рамках Фонда, должна была стать совместимой с операционной системой UNIX. Изначально UNIX был разработан в 1970-е годы Кеном Томпсоном и Деннисом Ричи в лаборатории компании AT&T и распространялся этой компанией (а впоследствии -- и другими) как коммерческая операционная система. К началу 1980-х UNIX очень широко использовался, в том числе и в академической среде, для этой операционной системы существовало много программ, свободно распространявшихся в научном сообществе, поэтому хотелось, чтобы эти программы работали и в новой -- свободной -- операционной системе. Эта будущая операционная систему получила название GNU(2).

Определение свободного ПО

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

• Программу можно использовать с любой целью ("нулевая свобода")(3).

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

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

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

Общественная лицензия GNU

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

Ричард Столлман занимался разработкой текстового редактора Emacs (о котором шла речь в лекции Текстовые редакторы) на основе исходных текстов Джеймса Гослинга (который впоследствии стал автором известного сегодня продукта Java). Тогда Гослинг свободно раздавал свои исходные тексты всем заинтересованным. Однако в некоторый момент Гослинг продал права на распространение Emacs компании UniPress (http://www.unipress.com) и компания попросила Столлмана прекратить распространение его версии Emacs, так как права принадлежат им. Этот инцидент заставил Столлмана переписать заново те части исходного текста Emacs, которые теперь принадлежали UniPress, после чего он разработал собственную лицензию на программное обеспечение.

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

Лицензия, содержащая такое условие, получила название "copyleft". Здесь игра слов: по-английски авторское право называется "copyright", буквально "копироватьправо", а "copyleft", соответственно, "копироватьлево". Действительно, условие "copyleft" прямо противоположно по смыслу авторскому праву: авторское право призвано ограничить пользователя в копировании и распространении копий продукта, а "авторское лево", наоборот, строго запрещает его ограничивать. Впоследствии лицензия Столлмана получила название "Общественная лицензия GNU" (GPL, GNU Public License).

В настоящее время помимо GPL известны и другие лицензии, под которыми может распространяться свободное ПО. Самая распространённая из таких лицензий -- BSD(4) License. Лицензия BSD отличается от GPL главным образом тем, что в ней отсутствует условие "copyleft", т. е. на основании свободного ПО, распространяемого под этой лицензией, можно производить несвободные модификации. Однако лицензия BSD и другие лицензии до тех пор будут оставаться лицензиями на свободное программное обеспечение, пока они соответствуют условиям, оговорённым принципами свободного ПО, объявленными Фондом.

Сообщество разработчиков и пользователей

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

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

Пользователь свободно распространяемой программы не получает вместе с ней никаких гарантий: автор сделал её исходный текст открытым для общества, но при этом не брал на себя обязательств объяснять всем, как работает программа(5). Поэтому получить ответ на свой вопрос пользователь может из двух источников: из документации, а если её недостаточно -- от более опытных пользователей. Хорошо, если такие пользователи есть среди знакомых, а если нет? В этом случае их всегда можно найти в списке рассылки в Internet, посвящённом данной программе.

Письмо, пришедшее на электронный адрес списка рассылки, будет отправлено всем подписчикам списка, любой из них может ответить на него в списке, и ответ также получат все подписчики и т. д. Так организуется нечто вроде виртуальной общей комнаты для разговоров(6). В настоящее время сложилось неписанное правило, что для каждой свободно распространяемой программы существует отдельный список рассылки. Найти адрес этого списка и подписаться на него можно в Internet (обычно на сайте, посвящённом данной программе). Любой пользователь свободной программы может направить свой вопрос в список рассылки. Списки рассылки читают разработчики программы и её активные пользователи, и обычно среди них находится тот, кто ответит на вопрос(7). Так получается, что пользователи свободных программ, в отсутствие централизованной службы поддержки, организуются в сообщество для взаимопомощи.

У пользователей программ вновь и вновь возникают одни и те же вопросы и сложности. Постоянным читателям списков рассылки это особенно очевидно, поскольку им приходится на эти вопросы отвечать не по одному разу. В таких ситуациях у них нередко возникает инициатива записать ответы на самые распространённые вопросы и открыть их для всеобщего обозрения. Так к свободной программе появляется новая документация в жанре FAQ (Frequently Asked Questions, ЧАсто задаваемые ВОпросы), представляющая собой список вопросов с ответами. Пользователи правовладельческих программ тоже задают одни и те же вопросы, только не в списке рассылки, а службе поддержки, в результате так же появляется документация типа FAQ, которая, почему-то, редко выходит за пределы внутреннего пользования производителя программы.

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

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

Разработчики и контролёры-испытатели правовладельческого продукта могут ходить на службу в один и тот же офис, и там обмениваться информацией или тратить определённую долю рабочего времени на составление и анализ строгих отчётностей, содержащих сообщения о ошибках и рапорты об устранении неисправностей. Такая организация труда эффективна, если круг разработчиков невелик, а ввести общую дисциплину относительно легко (например, угрожая рублём). Для открытого проекта круг потенциальных разработчиков не ограничен ничем, поэтому эффективность разработки в гораздо большей степени зависит от того, насколько просто всем членам сообщества договариваться между собой, а также от "сознательности" пользователей. Заметив ошибку в программе, сознательный пользователь не просто исправит её самостоятельно (что не всегда ему по силам), а оформит внятное сообщение об ошибке, а если исправление готово, приложит к сообщению и его.

Простому и упорядоченному приёму и перенаправлению сообщений об ошибках служат системы отслеживания ошибок (Bug Tracking System), самые известные из которых разработаны участниками больших проектов для себя, а благодаря свободным лицензиям используются повсеместно. Таковы GNUTS (разработанная в GNU), Bugzilla (mozilla.org), JitterBug (проект Samba) или Debian BTS. Более ранние версии ориентируются на электронную почту, более поздние включают в себя WWW-интерфейс. Например, при помощи Bugzilla организуется сайт в Internet, на котором пользователь может заполнить форму сообщения об ошибке. Каждое сообщение имеет свой номер, по которому можно попасть на "персональную" страницу данной ошибки, где отражаются все происходящие по её поводу события, от первоначального сообщения (открытия) до исправления (закрытия). При каждом изменении в состоянии ошибки Bugzilla рассылает всем заинтересованным лицам (включая, естественно, сообщившего об ошибке и занимающихся данной программой разработчиков) письма по электронной почте. Поскольку Bugzilla позволяет оставлять комментарии и прикладывать файлы, она является полноценным средством для общения пользователя с разработчиком по поводу ошибки в программе.

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

Чтобы облегчить и автоматизировать процесс внесения исправлений, Ларри Уолл (Larry Wall) в 1984 году разработал утилиту patch ("заплатка"), которая в формализованном (но хорошо понятном человеку) виде описывает операции редактирования, которые нужно произвести, чтобы получить новую версию текста. С появлением этой утилиты пользователь, обнаруживший и исправивший ошибку в программе, мог прислать автору небольшую заплатку, по которой автор мог понять, какие изменения предлагаются, и автоматически "приложить" их к своему исходному тексту. С появлением patch гораздо больше пользователей стало включаться в разработку программ с доступным исходным текстом, немалую роль и здесь сыграла сеть Usenet (см. об этом статью Тима ОРейли http://tim.oreilly.com/articles/paradigmshift_0504.html). Файлы-заплатки с исправлениями -- обязательный атрибут сегодняшней разработки свободных программ.

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

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

Написать большую программу в одиночку довольно сложно и даже не всегда возможно, особенно если автор занимается этим в свободное от работы время. Большинство современных свободных программ пишется группой разработчиков. Даже если начинал писать программу один человек, и она оказалась интересной, к разработке могут присоединиться активные пользователи. Чтобы они могли не только вносить отдельные исправления, но и вообще всю разработку вести совместно, нужны специальные инструменты. Помимо patch, для организации совместной разработки ПО применяются системы контроля версий. Функции системы контроля версий состоят в том, чтобы организовать доступ к исходным текстам программы для нескольких разработчиков и хранить историю всех изменений в исходных текстах, позволяя объединять и отменять изменения и пр. Самая ранняя свободная система контроля версий, RCS использовалась ещё на заре свободного ПО абонентами сети Usenet, затем на смену ей пришла более развитая CVS, но сегодня и она считается во многом устаревшей, и всё чаще заменяется Subversion, Arch и другими. К слову, названные системы контроля версий сегодня активно используются и разработчиками правовладельческого ПО для организации совместной разработки.

Нужно заметить, что преимущества свободной разработки для пользователя не следует преувеличивать. Не все свободные программы в равной степени доступны для изменения пользователям, и это совершенно не связано с лицензией на их распространение. Важный фактор здесь -- объём программы: если в ней десятки тысяч строк (как, например, в OpenOffice.org), то даже квалифицированному пользователю потребуется слишком много времени, чтобы разобраться, что к чему. А если при этом ещё нет толковой документации... Рассчитывать же на то, что разработчики ответят на все замечания и предложения пользователя немедленным исправлением программы тоже нельзя, поскольку они не несут перед пользователем никаких обязательств по качеству программы. В этом отношении пользователь несвободной программы может быть даже в лучшем положении.

Очень многие свойства сообщества разработчиков и пользователей свободных программ проистекают из того, что все его участники обычно занимаются этой программой из интереса или потому, что эта программа -- необходимый для них инструмент (например, зарабатывания денег). Время, потраченное ими на программу, не оплачивается, поэтому нет никакой надежды, что обстоятельства не переменятся и разработка не прекратится вовсе. Нередки случаи, когда разработка программы начинается благодаря одному автору-энтузиасту, который привлекает многих к участию в разработке, а потом энтузиазм лидера гаснет, а вместе с ним затухает и разработка. К сожалению, сегодня существуют тысячи свободных программ, так никогда и не достигших версии 1.0, хотя "выгорание" лидеров и не единственная этому причина. Кроме того, программа может быть необходимой, но "неинтересной", а потому не найдётся и свободных разработчиков.

Место свободных программ на сегодняшнем рынке ПО очень значительно, и многие коммерческие и государственные предприятия используют свободное ПО прямо или опосредованно. Собственно, опосредованно все пользователи Internet задействуют, например, свободную программу Bind, предоставляющую службу DNS. Многие организации, особенно предоставляющие услуги через Internet, используют свободный web-сервер Apache, от работы которого непосредственно зависит их прибыль, не говоря уже о серверах на платформе Linux. Выгода использования свободного ПО очевидна: за него не приходится платить, а если приходится -- оно стоит гораздо дешевле правовладельческих аналогов. Главный недостаток с точки зрения коммерческого пользователя: разработчики свободных программ не несут никаких обязательств по качеству программы, кроме моральных. Поэтому сегодня большие корпорации, например, Intel или IBM, находят необходимым поддерживать проекты по разработке свободного ПО, оплачивая сотрудников, которые работают в рамках этих проектов.

История Linux

GNU без Linux

К 1990 году в рамках проекта GNU были разработаны и постоянно развивались свободные программы, составляющие основной инструментарий для разработки программ на языке Си: текстовый редактор Emacs, компилятор языка Си gcc, отладчик программ gdb, командная оболочка bash, библиотека важнейших функций для программ на Си libc. Все эти программы были написаны для операционных систем, похожих на UNIX. Это означает, что в них использовался стандартный для UNIX механизм запроса ресурсов компьютера, необходимых программе -- системные вызовы, которые исполняются ядром операционной системы. При помощи системных вызовов программы получают доступ к оперативной памяти, файловой системе, устройствам ввода и вывода. Благодаря тому, что системные вызовы выглядели более-менее стандартно во всех реализациях UNIX, программы GNU могли работать (с минимальными изменениями или вообще без изменений) в любой UNIX-подобной операционной системе.

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

Linux -- ядро

В 1991 году Линус Торвальдс, финский студент, чрезвычайно увлёкся идеей написать совместимое с UNIX ядро операционной системы для своего персонального компьютера с процессором ставшей очень широко распространённой архитектуры Intel 80386. Прототипом для будущего ядра стала операционная система MINIX: совместимая с UNIX операционная система для персональных компьютеров, которая загружалась с дискет и умещалась в очень ограниченной в те времена памяти персонального компьютера. MINIX был создан Энди Танненбаумом в качестве учебной операционной системы, демонстрирующей архитектуру и возможности UNIX, но непригодной для полноценной работы с точки зрения программиста. Так же, MINIX можно было использовать только в некоммерческих целях. Именно полноценное ядро для своего ПК и хотел сделать Линус Торвальдс. Название для своего ядра он соорудил из собственного имени, заменив последнюю букву и сделав его похожим на анаграмму слова UNIX.

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

Важнейшую роль в развитии Linux сыграли глобальные компьютерные сети Usenet и Internet. На самых ранних стадиях он обсуждал свою работу и возникающие трудности с другими разработчиками в телеконференции comp.os.minix в сети Usenet, посвящённой операционной системе MINIX. Ключевым решением Линуса стала публикация исходных текстов ещё малоработоспособной первой версии ядра под свободной лицензией GPL. Благодаря этому и получавшей всё большее распространение сети Internet очень многие получили возможность самостоятельно компилировать и тестировать это ядро, участвовать в обсуждении и исправлении ошибок, и присылать исправления и дополнения к исходным текстам Линуса. Теперь над ядром работал уже не один человек, разработка пошла быстрее и эффективнее.

В 1992 году версия ядра Linux достигла 0.95, а в 1994 году вышла версия 1.0, что свидетельствует о том, что разработчики наконец сочли, что ядро в целом закончено и все ошибки (теоретически) исправлены. В настоящее время разработка ядра Linux -- дело уже гораздо большего сообщества, чем во времена до версии 0.1, изменилась и роль самого Линуса Торвальдса, который теперь не главный разработчик, но главный авторитет, который традиционно оценивает исходные тексты, которые должны быть включены в ядро и даёт своё добро на их включение. Тем не менее, общая модель свободной разработки сообществом сохраняется. В настоящее время параллельно всегда разрабатывается два варианта ядра. Стабильная версия, считающаяся достаточно надёжной и пригодной для пользователей, её номер заканчивается на чётное число, например, "2.4". Номер соответствующей экспериментальной версии ядра оканчивается на нечётное число -- "2.5". Экспериментальная версия адресована в первую очередь разработчикам ядра, тестирующим новые возможности.

GNU и Linux

Однако как нельзя сделать операционную систему без ядра, так и ядро будет бесполезно без утилит, которые использовали бы его возможности. Благодаря проекту GNU Линус Торвальдс сразу имел возможность использовать в Linux свободные утилиты: bash, компилятор gcc, tar, gzip и многие другие уже известные и широко используемые приложения, которые могли работать с его UNIX-совместимым ядром. Так Linux сразу попал в хорошее окружение и в сочетании с утилитами GNU представлял собой очень интересную среду для разработчиков программного обеспечения даже на самой ранней стадии своего развития.

Принципиальным шагом вперёд было именно то, что из ядра Linux и утилит и приложений GNU впервые стало возможно сделать полностью свободную операционную систему, т. е. работать с компьютером и, более того, разрабатывать новое программное обеспечение, пользуясь только свободным программным обеспечением. Идеал полностью некоммерческой разработки Столлмана теперь мог быть реализован в жизни.

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

Возникновение дистрибутивов

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

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

Когда задача получить компьютер с постоянно работающей на нём системой Linux стала востребованной и довольно распространённой, разработчики в хельсинкском и техасском университетах создают собственные наборы дискет, с которых скомпилированное ядро и основные утилиты можно записать на жёсткий диск, после чего загружать операционную систему прямо с него. Эти наборы дискет -- первые прототипы современных дистрибутивов Linux -- комплекты программного обеспечения, на основе которых можно получить работающую операционную систему на своём компьютере. Нужно отметить, что в дистрибутив Linux с самого начала входили программные продукты GNU. На самом деле, всякий раз, когда говорится "операционная система Linux", подразумевается "ядро Linux и утилиты GNU". Фонд свободного ПО даже рекомендует называть это операционной системой GNU/Linux.

Однако скопировать все нужные программы на жёсткий диск ещё недостаточно, чтобы получить подходящую для нужд пользователя операционную среду (пусть даже это очень профессиональный пользователь). Поэтому первые наборы дискет можно только условно назвать дистрибутивами. Чтобы получить работающую операционную систему, требуются какие-то специальные средства установки и настройки программного обеспечения. Именно наличие таких средств и отличает современные дистрибутивы Linux. Другое важнейшая задача дистрибутива -- регулярное обновление. Программное обеспечение, особенно свободное, -- одна из самых быстро развивающихся областей, поэтому мало один раз установить Linux, нужно ещё регулярно его обновлять. Первым дистрибутивом в современном понимании, получившим широкое распространение, стал Slackware, созданный Патриком Фолькердингом (кстати, этот дистрибутив сохранился и до наших дней). Он был широко известен пользователям Linux уже к 1994 году.

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

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

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

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

Практически одновременно с RedHat появился проект Debian. Его задача была примерно той же -- сделать целостный дистрибутив Linux и свободного программного обеспечения GNU(8), однако этот проект был задуман как принципиально некоммерческий, проводимый в жизнь сообществом разработчиков, нормы взаимодействия в котором полностью соответствовали бы идеалам свободного ПО. Сообщество разработчиков Debian -- международное, участники которого взаимодействуют через Internet, а нормы взаимодействия между ними определяются специальными документами -- полиси (policy).

Сообщество разработчиков не извлекает никакой прибыли от продажи Debian, его версии распространяются свободно, доступны в Интернет, могут распространяться и на твёрдых носителях (CD, DVD), но и в этом случае их цена редко сильно превышает стоимость носителя и наценку, окупающую затраты на издание. Первоначально разработка Debian спонсировалась Фондом свободного программного обеспечения. Адресатами дистрибутивов Debian всегда в первую очередь были профессиональные пользователи, так или иначе связанные с академической разработкой программного обеспечения, которые готовы читать документацию и собственными руками организовать нужный профиль системы, соответствующий именно их задачам. Ориентация на такую аудиторию предопределила некоторые тенденции развития Debian: в нём никогда не было обилия "простых" графических средств настройки среды, всевозможных мастеров, однако всегда уделялось много внимания средствам последовательной и единообразной интеграции программного обеспечения в единую систему. Именно в Debian появился менеджер пакетов (APT). В настоящее время Debian -- самый популярный дистрибутив Linux среди пользователей, являющихся профессионалами в области информационных технологий.

Всякий раз, когда свободное программное обеспечение оказывается востребованным, немедленно возникает множество альтернативных решений -- так произошло и с дистрибутивами Linux. После 1995 года возникло (и продолжает возникать) огромное количество коммерческих компаний и свободных сообществ, которые ставят своей задачей подготовку и выпуск дистрибутивов Linux. У каждого из них -- свои особенности, своя целевая аудитория, свои приоритеты. К настоящему времени на рынке дистрибутивов выделилось несколько лидеров, которые предлагают более или менее универсальные решения и наиболее широко известны и используются. Помимо уже названных RedHat и Debian следует назвать в ряду дистрибутивов, ориентированных на рядового пользователя, немецкий SuSE и французский Mandrake, среди адресованных специалистам -- Gentoo. Но помимо "крупных" игроков на рынке дистрибутивов есть гораздо большее количество менее распространённых дистрибутивов. Теперь перед пользователем, желающим установить Linux, встаёт вопрос выбора дистрибутива. Критерии выбора -- и задачи, которые предполагается решать с помощью Linux, и уровень подготовки пользователя, и технологии, и предстоящие контакты с тем сообществом, которое занимается разработкой дистрибутива.

История Linux в России

Получилось так, что в международном сообществе разработчиков, начинавших и продолжавших развивать Linux, все в той или иной степени могли объясниться по-английски. Это и неудивительно, поскольку исторически английский оказался языком компьютерной науки и операционной системы UNIX, глобальной сети Internet, программирования. В международном сообществе разработчиков программного обеспечения английский выполнял и выполняет роль, подобную латыни в научном сообществе средневековой Европы. Но если Linux предполагается использовать не только для программирования и общения с программистами, но и для повседневных задач, необходима локализация -- т. е. возможность общаться с компьютером и при помощи компьютера и на других языках.

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

Первой компанией, поставившей своей целью выпуск дистрибутивов Linux для русскоговорящих пользователей, была УрбанСофт, открытая в Петербурге в 1992 году. Весь её бизнес состоял в выпуске и продаже CD-дисков с дистрибутивами свободного программного обеспечения. В первую очередь это были дистрибутивы RedHat, а также Debian, в которые включались разработанные силами УрбанСофт пакеты для русификации.

Несколько позже в Москве IPLabs Linux Team выпускает Linux Mandrake Russian Edition -- модифицированный (чтобы соответствовать нуждам русского пользователя) вариант дистрибутива Mandrake Linux. Впоследствии эта команда начинает выпускать дистрибутивы, которые отличаются от Mandrake уже не только наличием пакетов для русификации, но и другими принципиальными возможностями. В конце концов команда разработчиков создаёт фирму ALT Linux и начинает выпускать дистрибутивы под маркой ALT Linux.

Также появляется компания ASPLinux, целью которой является выпуск RedHat с модификациями для поддержки русского языка, название продукта совпадает с именем компании.

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

(1) Предоставление автору (либо его работодателю) самих по себе авторских прав в большинстве законодательств гарантировано, речь идёт о том, как именно правообладатель распорядится этими правами.

(2) Это псевдоаббревиатура, для которой сам Столлман предлагал рекурсивную расшифровку: GNU's Not Unix ("Гну — Не UNIX").

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

(4) BSD -- Berkeley Software Distribution, пакет совместимого с UNIX программного обеспечения, разработанный в университете Беркли и распространявшийся свободно.

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

(6) Списки рассылки в Internet -- наследники телеконференций сети Usenet, возникшей до появления Internet. В Usenet существовали телеконференции буквально на любую тему, и, конечно же, многие были посвящены программному обеспечению.

(7) Задавший вопрос пользователь должен принимать в расчёт, что все подписчики списка рассылки участвуют в нём добровольно, и никто их них не обязан отвечать на какие-либо вопросы, поэтому предъявлять претензии на этот счёт бессмысленно и невежливо.

(8) Официальное название дистрибутива -- Debian GNU/Linux.