История. Лицензионно-правовые аспекты.

Предыстория

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

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

В те времена, когда все программное обеспечение было составляющей частью компьютера (и не подлежало замене на другое), оно разрабатывалось с той же скоростью и в то же время, что и аппаратное обеспечение. Например, время проектирования ЭВМ Мир, начиная с теоретических разработок и заканчивая эксплуатационным образцом, составило 12 лет. И на протяжении всего этого времени параллельно с аппаратным разрабатывалось программное обеспечение, именно для "скрепления" аппаратуры, а не для решения пользовательских задач. Пользователи для решения своих задач писали программы сами. Ведущей компьютерной фирмой США --- IBM --- использовались аналогичные подходы: создание системы IBM System/360 от начала разработки до начала стабильной работы заняло так же около десяти лет и операционная система OS/360 была неотъемлемой частью этой ЭВМ.

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

Исторической и идеологической предшественницей GNU/Linux является операционная система UNIX. История UNIX весьма обширна и интересна, но мы заострим внимание лишь на трех вещах, её касающихся.

Разработка для себя

Исторически операционная система UNIX разрабатывалась "для себя". После того, как Bell Labs (исследовательское подразделение AT&T) отказалось от участия в проекте MULTICS, группа исследователей из Bell Labs, задействованная в этом проекте, хотела продолжить работу над созданием операционной системы с разделением времени. Название UNIX предложил Брайан Керниган, по ассоциациям с MULTICS. Предложение купить новый компьютер для проекта было отклонено и поначалу для экспериментов использовался относительно старый PDP-7.

Немного ранее, при работе над Multics, Кен Томпсон создал игру Space Travel, и был ею весьма увлечен, кроме того, он разработал язык B (предтечу языка С), компилятор которого был создан при участии Дениса Ритчи. Для работы Space Travel и был использован компьютер PDP-7 как обладающей неплохим текстовым дисплеем. В ходе работ по переносу Space Travel на PDP-7 была начата разработка утилит, необходимых для удобной разработки игры прямо на PDP-7. В результате этих работ была по сути создана однопользовательская операционная система, названная UNICS (в противоположность MULTICS). В дальнейшем в нее была добавлена многозадачность, и название изменилось на UNIX.

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

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

Кен Томпсон и Денис Ритчи продвинулись в реализации этой концепции. В начале 70-х задачей начал заниматься целый отдел, началось внедрение. Начальник отдела Дуглас Макилрой увлекался макроязыками и предложил идею конвейера, т.е. потоковую передачу данных между процессами и макроязыка для ее описания. В технологии конвеера отсутствует способ нормальной реализации механизма ветвления, однако, при использовании командной строки механизмы сложнее конвейера могут быть трудными для использования пользователем.

Затем в разработке начал принимать участие известный популяризатор науки Брайан Керниган. Он предложил, во-первых, добавить в язык B некоторые высокоуровневые средства из PL/I, например структуры. Во-вторых, Керниган предложил переписать операционную систему с PDP-ассемблера на язык C. Идея состояла в том, что при написании большей части операционной системы на неком языке программирования этой операционной системой потенциально можно оснастить любой компьютер, для которого существует компилятор использовавшегося языка.

В то время уже существовали языки программирования, такие как PL/I, FORTRAN, ALGOL и LISP. Но они были ориентированы больше на решение пользовательских задач, чем системных. FORTRAN (от FORmula TRANslator), первый высокоуровневый язык, был придуман математиками и ориентирован на решение математических задач. ALGOL-60 имел некоторые особенности, не позволявшие создавать нормальные реализации. PL/I только начинал приобретать законченную форму и также был ориентирован скорее на пользовательские задачи, хотя и содержал много интересных идей. В результате для написания ядра операционных систем использовался машинный язык соответствующей ЭВМ.

Керниган предложил реализовать язык программирования, ориентированный на системные задачи, и достаточно простой для того, чтобы реализация его компилятора на любой платформе не представляла собою сложную задачу, эдакий "переносимый ассемблер". Потенциальным результатом использования подобного подхода была возможность портирования операционной системы на компьютер с принципиально отличающейся архитектурой. В 1972 году ОС Unix была портирована на 32-разрядный Interdata-32 с 16-разрядного PDP-11. Небольшая часть ядра операционной системы, разумеется, реализовывалась и продолжает реализовываться на ассемблере, однако вся логика операционной системы была написана на языке C.

Переносимость программ

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

Коллективная разработка

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

После того, как UNIX получила распространение, в течение порядка десяти лет она развивалась вышеописанным способом. Люди писали программы, на конференциях обменивались ими, находили ошибки и дорабатывали, снова обменивались. Этот процесс затронул не столько UNIX, разрабатывавшийся Кеном Томпсоном и Денисом Ричи в Bell Labs (тот был производственным продуктом и принадлежал компании AT&T), сколько UNIX-подобную ОС, создававшуюся американскими университетами и получившую название BSD (Berkeley System Distribution, по названию самого известного кампуса Университета Калифорнии). Тогда же появилась концепция создания и распространения некоторого блока программ, написанных различными людьми, называющегося distribution. Авторы программ распространяли их затем, чтобы другие пользователи подправляли и дорабатывали программы. Такая форма разработки программного продукта хорошо себя зарекомендовала уже тогда, хотя в те времена, чтобы передать копию программы надо было записать её на ленту и либо отдать при личной встрече, либо выслать бандеролью. Программы тогда разрабатывались не слишком многочисленными учеными, которые постоянно встречались и общались на различных конференциях, обмениваясь не только идеями, но и их воплощениями.

Это счастливое время продолжалось до конца 70-х-начала 80-х годов, когда стала очевидно, что ОС UNIX и её подобия обладают с точки зрения бизнеса двумя очень важными свойствами:

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

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

Лицензионно-правовые аспекты

В 80-е годы стало выяснятся, что большинство программного кода UNIX-систем имеет правообладателей. Более того, если программа не была написана в свободное от работы время и иного не указано в контракте, правообладателем является работодатель программиста (им мог быть и университет). Многие правообладатели не хотели свободного распространения исходного кода. Это совершенно не согласовывалось с описанным выше академическим стилем создания программ. Разработчики UNIX-систем привыкли показывать свои работы заинтересованным коллегам, которые высказывали мнения, помогали, дополняли. Работа в сообществе сильно отличается от работы в одиночку. Также выяснилось, что многие не задумывались о принадлежности кода, и для большого количества программ установить писались ли они в рабочее время, и кто написал какую часть не представляется возможным. В результате значительная часть кода была признана принадлежащим компании AT&T (владельцу Bell Labs на момент появления UNIX). Кроме того, на основе BSD была создана закрытая коммерческая UNIX-система SunOS.

В результате указанных факторов в 80-х годах, параллельно с развитием университетских версий, произошел стремительный рост коммерческих UNIX-подобных систем: полное дерево родословной UNIX-систем занимает около 24 листов формата А4.

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

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

Стало ясно, что необходимо строго разделить свободное ПО, с которым можно делать что угодно (или почти что угодно) без ответственности перед правообладателем, и несвободное, распространение исходников которого незаконно. На собственном примере это понял одни из самых известных людей в области свободного ПО --- Ричарда Мэтью Столлмана (RMS). В частности, в начале 80-х он работал в над lisp-машиной (компьютером, имеющим язык lisp в качестве ассемблера), и вдруг выяснилось, что всё им разработанное, в том числе и текстовый редактор Emacs, написанный для личных нужд, принадлежит компании-работодателю, так как было сделано в рабочее время.

В результате, в истории UNIX-систем 80-е годы известны как UNIX wars, из-за двух конфликтов:

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

С точки зрения развития операционных систем, 80-е стали временем стагнации. Десятилетие прошло под лозунгом "компьютер в каждый дом", но при этом технологический прогресс приостановился. На 8-битных и 16-ти битных домашних компьютерах не было даже полноценных операционных систем. Внимание уделялось разработке интерфейсов, повышению usability (особенно это отличало Apple Macintosh), но как операционная система Mac OS не был новаторским продуктом: через 15 лет Mac OS X стал базироваться на все том же BSD. Технологии же не могут развиваться без исследований, а исследования не могут существовать без академической структуры.

К концу 80-х возросшая информационная связность позволила сформироваться свободному сообществу вокруг программных продуктов: при совместной работе над проектом людям более не приходилось платить за свой энтузиазм. В конце 80-х -- начале 90-х в связи с развитием интеренета стали отмирать такие вещи как система UUCP, FIDO, телефонные BBS-системы, в какой-то период не выпускались даже GNU Distributions (подборки свободного ПО). В России, в силу не очень широкого распространения Интернета, всё это использовалось намного дольше.

Вместе с со связностью, возросло и напряжение между свободным и несвободным. Появились случаи серьезного преследования, инициируемого проавообладателями, наиболее известным был иск AT&T к университету Berkeley, разрабатывающем BSD.

Свободное лицензирование программ

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

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

Используя американский механизм авторской лицензии, RMS и его коллеги из Free Software Foundation (FSF) добились юридической значимости свободной лицензии General Public License (GPL). Во многих странах GPL либо сама является значимой, либо, как в России, принимается во внимание. Таким образом, разработчики получили возможность распространять свои программные продукты по условиям лицензии, запрещающей делать свободное ПО менее свободным.

В рамках движения FSF было создано большое количество свободных программных продуктов, включая компилятор языка С GCC, однако долгое время не было ядра, лицензированного по GPL. В принципе, существовала теоретическая перелицензировать ядро BSD, но этого так и не произошло. Возможно по причине того, что ядро BSD имело код AT&T и BSD в итоге была втянута в UNIX wars, а возможно из-за каких-то разногласий между RMS и разработчиками BSD.

К началу 90-х годов у FSF были все основные части свободной операционной системы --- кроме работающего ядра. Один финский (этнически --- шведский) студент, Линус Торвальдс в то время экспериментировал с учебной ОС Minix. OC Minix распространялась с исходниками, но на тот момент была несвободной. Ее главным автором был академический классик в области построения ОС --- Э. Танненбаум. В ходе этих экспериментов Линус написал собственную маленькую UNIX-подобную ОС. ОС Линуса умещалась на дискете и, по обычаям того времени, была несвободной: её можно было изучать, но распространение допускалось только в университетах.

Главной ценностью работы Линуса было работоспособное ядро, хотя в тот момент и с очень скромными возможностями. Благодаря участию энтузиастов по всему миру, ядро росло и развивалось, а в 1992-м году для его кода была выбрана лицензия GPL. Таким образом. В 1993-м года Патрик Фолькердинк в качестве дипломной работы объединил свободное ядро Linux и свободные утилиты GNU, создав, всего за несколько месяцев, дистрибутив операционной системы, то есть нечто, что после установки чего на компьютере появляется операционная система. Это было беспрецедентное явление, так как ранее создание полноценных UNIX-подобных операционных систем считалось прерогативой крупных компаний. Благодаря активности заинтересованных в свободной ОС пользователей Патрик продолжал и продолжает делать релизы своего дистрибутива, названного им Slackware.

Как только процесс создания операционной системы стал занимать не несколько лет, а несколько месяцев, начали появляться и другие дистрибутивы --- Debian, SuSe, RedHat. Некоторые люди сочли, что создание дистрибутива это новая технология, позволяющая продавать услуги. В течение 90-х годов количество дистрибутивов, получивших название "операционная система GNU/Linux" неуклонно росло. Итак, дистрибутив --- это не свободные программы, и, тем более, не ядро. Дистрибутив --- это сделанная из разрозненного набора компонент операционная система с уникальными свойствами. Например, Ubuntu и ALT Linux далеко не одинаковы, хотя и то и то является операционной системой GNU/Linux.

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

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

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

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

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

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

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

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

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

Итак, что же теряют разработчики теряем, переходя на закрытый способ разработки?

• Законодательно, для того, чтобы кто-то мог написать ограничивающее лицензионное соглашение о программном продукте, он должен оставаться хозяином всех копий программного продукта. Покупатель получает некоторые ограниченные права на использования программного продукта, но при этом не получает никаких прав собственности на него: основная фраза в несвободной лицензии на программное обеспечение --- "this software is licensed, not sold". Полным собственником всех копий программного продукта, организованных и разрабатываемых по закрытому способу, обязана оставаться некая единая организация. А уже это накладывает на весь процесс сильные технологические ограничения.
• Главное ограничение состоит в том, что, вообще говоря, мы не можем позволить утекать информации, особенно исходным текстам программного продукта. Информация становится главной коммерческой тайной и оберегаемой "интеллектуальной собственностью". Коммерческая тайна и "интеллектуальная собственность" становятся управляющим механизмом бизнес-процессов. Невозможно допустить ситуацию, когда наши конкуренты узнают о нашем программном продукте достаточно информации, чтобы воспроизвести его и начинать брать за копирование аналогичного программного решения на, допустим, 20% процентов меньшее денег.

Таким образом, большие деньги можно сделать только если всё, что может быть воспроизведено путём очень дешёвого копирования, держится в тайне, и защищается от копирования законодательством. В первую очередь это исходный текст программного продукта. В результате из-за ограничений в информационном плане обычно теряется качество программных продукта, поскольку открытое информационное пространство желательно для любого программного продукта. Любому продукту нужна реклама, нужно распространение информации о себе, нужна возможность изучения классифицированными пользователями для выявления ошибок и особенностей функционирования. Но в случае закрытой разработки информация, становящаяся открытой, жестко ограничивается. Не допускается разглашение того, что называется коммерческой тайной, либо предоставление доступа к этой информации возможно только на коммерческих условиях или условиях неразглашения. Например, преподаватели ВУЗов в последнее время теоретически могут получить ограниченный доступ к исходным текстом ядра ОС Windows --- на условиях довольно сложной и ограничивающей их лицензии. Неэффективными для создания открытого информационного пространства оказываются даже лицензии, подобные Microsoft Shared Source Reference License, запрещающие программирование с использованием взятой из исходных кодов информации для всех целевых платформ кроме некого множества.

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

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

Понятно, что для организации "торговли воздухом" в виде передачи пользователю некоторых ограниченных прав на использование программного продукта за вполне конкретные деньги необходимо иметь право собственности на программный продукт. В англосаксонском праве, в Америке и большей части Европы этому соответствует понятие лицензии (англ. license --- разрешать, разрешение). Заметим, что до вступления в силу нового Гражданского Кодекса 2008 года в законодательстве РФ понятие лицензии отсутствовало, вместо этого использовалось понятие договора между разработчиком и потребителем.

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

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

• Использование программы: пользователь может запускать программу и использовать ее результаты для любых своих целей. Заметим, что в текущем российском законодательстве данная свобода предоставляется пользователю автоматически: по факту получению программного продукта вас не могут заставить "что-либо не делать" (например, не использовать по субботам или воскресеньям).
• Изучение и модификация программного продукта. Когда Столман говорит "свобода", это значит, что ограничений в этом направлении быть не может. Данная свобода предполагает получение исходных текстов программы.
• Распространение программного продукта. Автор программного продукта не должен ограничивать как бесплатное, так и коммерческое его распространение.
• Распространение модифицированных версий. Эта свобода делает возможным организацию бизнес-модели на свободном ПО. Дело в том, что довольно часто можно встретить лицензии типа "я гениален, а вы не очень", вставляющие палки в колеса любому основанному на модификации программного продукта делу, например запрещающих продажу модифицированных версий. Наличие же данной свободы дает возможность зарабатывать деньги на внесении в продукт дополнительной, необходимой заказчику функциональности.

В свободных лицензиях группы GPL (General Public License) существует также дополнительное требование, не входящее в классическое определение свободного программного обеспечения (Free and Open Source Software). Это требование вызвано тем, что и разработчиками, и пользователям продукта вряд ли будет приятна ситуация, когда на базе свободного продукта можно будет сделать закрытый продукт. В истории программного обеспечения встречались ситуации типа "был академический свободный программный продукт, пришла компания, заплатила деньги за доработку или выкупила права у университета, и затем закрыла продукт". Разработчики часто чувствовали себя обманутыми, поскольку нанесен удар по академической среде, а свобода пользователей и разработчиков в итоге уменьшена. Для устранения этого противоречия и недопущения уменьшения свободы пользователей Столман придумал специальное условие --- copyleft. Оно заключается в следующем: при модификации и распространении копий лицензия на модифицированный продукт должна быть "не хуже", чем исходная: она должна гарантировать все те же четыре свободы и сохранять условие copyleft. На практике это означает, прежде всего, свободный доступ к исходным текстам модифицированной программы. Отметим, что названные четыре свободы вместе с требованием copyleft и составляют лицензию GPLv2 (GNU General Public License version 2). Кроме "копилефт"-лицензий, существует множество свободных лицензий, не содержащих требования распространения модифицированых версий с исходными текстами, к ним относят лицензии BSD (старая и новая), MIT, Apache и многие другие.

Сделаем три замечания:

• Даже использование интерфейса GPL-библиотеки заставляет лицензировать программный продукт под не менее свободной лицензией. Данное требование для случая компоновки явно исключено, к примеру, в лицензии LGPL (GNU Lesser General Public License). Таким образом, LGPL-библиотеки защищены от создания своих закрытых модификаций, но могут использоваться программным обеспечением под иными лицензиями, в том числе и закрытыми.

• Существуют два несколько различающихся различных понятия: свободное ПО (free software) и ПО с открытым исходным кодом (open-source software). Определение ПО с открытым кодом по Реймонду (Eric Steven Raymond, ESR) состоит из десяти пунктов. Реймонд основал достаточно авторитетную организацию Open Source Initiative (OSI), которая определяет, является ли лицензия свободной. Это позволяет официально считать несвободными лицензии, предоставляющие доступ к исходным текстам, но, например, запрещающие продажу программного обеспечения.В рамках европейского законодательства понятия free software и open-source software можно считать эти понятия эквивалентными. Заметим, что в английском языке слово open более "сильное", чем free (которое часто означает "бесплатный", а не "свободный"), в русском же языке все наоборот: "свободный" и "открытый". В составленном для государственного проекта глоссарии оговаривается, что предпочтительный термин --- свободное ПО. Отметим также, что свободное программное обеспечение согласно определению не обязано быть бесплатным.

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

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

• предъявить упомянутое выше "уведомление о правах";
• предъявить купон технической поддержки с индивидуальным номером, зарегистрированным на специальном сайте.

Такие документы поставляются, к примеру, с коробочными версиями ПСПО "Линукс Мастер" и могут в описанной ситуации помочь.

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

Совместная разработка

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

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

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

Программы GNU/Linux --- пример совместной разработки

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

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

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

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

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

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

Разработка дистрибутива GNU/Linux

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

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

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

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

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

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

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

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

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

Последний пункт можно пояснить на прмере. Предположим, мы скачали какую-то программу на языке Си, в ней около ста файлов. Она была разработана, скажем, под ОС Sun Solaris и архитектурой Sparc64, и там у автора всё замечательно работает. А мы хотим скомпилировать её под GNU/Linux и архитектуру x86, поскольку других подобных программ нет. Сначала мы определяем, какие библиотеки и каких версий требуются для ее компиляции и работы. В итоге ментейнер собирает ее, дает команду make install, но в Solaris'e программы находятся в каталоге /opt/progname/, и ментейнер вынужден всё удалить, и дальше уже вносить изменения, чтобы она помещала свои файлы в правильные каталоги в соответствии с политикой дистрибутива, и там их и искала. Затем оказывается, что есть какая-то ошибка, которая у автора не проявляется в силу иной архитектуры и операционной системы. После ее исправления, наконец, наступает момент, когда программа работает нормально, но через 2 недели выходит ее новая версия... Чтобы избежать ситуации, когда этот процесс придется повторять каждый раз с нуля при выходе новой версии, необходимо помнить следующее: любые изменения необходимо протоколировать , кроме того, нужно указывать, что нужно для сброчного окружения. И только после этого можете спокойно это собирать.

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