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

Linux — это свободно распространяемое ядро Unix-подобной операционной системы.

Однако многие подразумевают под термином Linux всю операционную систему, основанную на ядре Linux.

Linux — это свободно распространяемая Unix-подобная операционная система, включающая ядро, системные инструменты, приложения и завершенную среду разработки.

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

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

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

Linux — это не просто еще одна система, подобная Unix. Это не просто хорошая платформа, куда можно переносить программы — это также хорошая платформа, на которой можно создавать и запускать приложения. Она широко используется во всем мире, помогая популяризировать концепцию открытого исходного кода (Open Source) или свободного программного обеспечения (Free Software). Краткий экскурс в историю поможет понять, как и почему это случилось.

 

1.1. Краткая история свободного программного обеспечения Unix

Предлагаемая история упрощена и основана на самых важных элементах системы Linux. Более длинную и равномерную историю можно прочесть в книге A Quarter Century of UNIX [29].

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

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

Ричард Столлман (Richard Stallman) из Массачусетсского технологического института (MIT) не хотел, чтобы инновации ПО во всем мире контролировались корпоративными амбициями, поэтому он основал Фонд свободного программного обеспечения (Free Software Foundation — FSF). Целью FSF стало поощрение разработки и использования ПО без ограничений на свободное распространение.

Однако слово "free" в этом контексте вызвало недоразумения. Под словом "free" Ричард Столлман подразумевал свободу, а не нулевую цену. Он твердо убежден, что ПО и связанная с ним документация должны быть доступны с исходным кодом, без ограничений на дополнительное распространение. Не так давно появился термин Open Source (открытый исходный код) для описания тех же целей (без слова "free", вызывающего недоразумения). Термины Open Source и Free Software (свободное ПО) обычно рассматриваются как синонимы.

С целью продвижения своей идеи Ричард Столлман не без помощи других создал общедоступную лицензию (General Public License — GPL). Эта лицензия оказала настолько большое влияние, что аббревиатура GPL вошла в жаргон разработчиков как глагол; вместо "применить условия GPL к создаваемому вами ПО" часто говорят "to GPL".

Лицензия GPL состоит из трех пунктов.

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

2. Любое ПО, производное от ПО, подпадающего под условия GPL, должно сохранить GPL в качестве лицензии для свободного распространения.

3. Любой владелец ПО, подпадающего под условия GPL, имеет право распространения этого ПО на условиях, не конфликтующих с GPL.

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

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

Основным проектом участников FSF является проект GNU's Not Unix (GNU), цель которого — создание свободно распространяемой Unix-подобной операционной системы. При запуске проекта GNU было очень мало высококачественного свободно распространяемого ПО, поэтому его участники начали с создания приложений и инструментов для будущей системы, а не с самой операционной системы. Поскольку лицензия GPL была также произведена FSF, ко многим ключевым компонентам операционной системы GNU применены условия GPL, но на протяжении многих лет проект GNU принял многие другие пакеты, например, X Window System, систему верстки ТЕХ и язык Perl, свободно распространяемые под другими лицензиями.

Результатом проекта GNU стало несколько основных пакетов и множество второстепенных. Основные пакеты включают редактор Emacs, библиотеку GNU С, коллекцию компиляторов GNU (gcc, как изначально назывался компилятор GNU С перед добавлением С++), оболочку bash и gawk (GNU's awk). Второстепенные пакеты включают высококачественные утилиты оболочек и программы обработки текста, которые обычно присутствуют в системе Unix.

 

1.2. Разработка Linux

В 1991 году Линус Торвальдс (Linus Torvalds), в то время студент Хельсинкского университета, начал проект, целью которого было обучение низкоуровневому программированию для процессора Intel 80386. В то время он работал с операционной системой Minix, созданной Эндрю Таненбаумом (Andrew Tanenbaum), поэтому изначально совмещал свой проект с системными вызовами Minix и структурой дисковой файловой системы. Реализовав первую версию ядра Linux в Internet под довольно ограничивающей лицензией, вскоре он, однако, сменил эту лицензию на GPL.

Сочетание GPL и первоначального набора функций ядра Linux убедило других разработчиков предложить свою помощь при разработке ядра. Реализация библиотеки С, производная от потенциального в то время проекта библиотеки GNU С, позволила разработчикам создавать "родные" пользовательские приложения. Затем последовали собственные версии gcc, Emacs и bash. В 1992 году разработчик со средней квалификацией мог установить и загрузить версию Linux 0.95 на большинстве машин с процессором Intel 80386.

Проект Linux с самого начала был тесно связан с проектом GNU. Исходная база проекта GNU стала очень важным ресурсом сообщества Linux для создания завершенной системы. Хотя значительное количество систем, основанных на Linux, произведены из источников, которые включают свободно доступный код Unix Калифорнийского университета в Беркли и консорциума X Consortium, многие важные части функциональной системы Linux напрямую связаны с проектом GNU.

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

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

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

Одним из проектов, повлиявших на эту совместимость, является стандарт иерархии файловых систем (Filesystem Hierarchy Standard — FHS), ранее называемый стандартом файловых систем Linux (Linux Filesystem Standard — FSSTND), определяющий, где следует хранить множество файлов, и объясняющий в общих чертах, каким образом должна быть организована оставшаяся часть файловой системы. Позднее проект под названием стандартная база Linux (Linux Standard Base — LSB) был расширен без учета структуры файловой системы, определяя программные интерфейсы приложений (Application Programming Interface — API) и двоичные интерфейсы приложений (Application Binary Interface — ABI). Эти интерфейсы предназначены для возможности компиляции приложения один раз и развертывания его на любой системе, подчиняющейся определению LSB для данной архитектуры процессора. Эти и другие документы доступны на Web-сайте по адресу http://freestandards.org.

 

1.3. Важные факты в создании систем Unix

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

На заре восьмидесятых годов прошлого столетия разработчики Unix были разделены на два "лагеря": первый — Калифорнийский университет в Беркли, а второй — компания AT&T Bell Laboratories. Оба учреждения разрабатывали и поддерживали операционные системы Unix, которые происходили от исходной реализации Unix, созданной в Bell Laboratories.

Версия Unix от Беркли стала известной как программный дистрибутив Беркли (Berkeley Software Distribution — BSD) и приобрела популярность в научном сообществе. Система BSD впервые включила организацию сетей TCP/IP, что повлияло на ее успех и помогло убедить компанию Sun Microsystems основать на BSD первую операционную систему Sun — SunOS.

В компании Bell Laboratories также трудились над совершенствованием Unix, но, к сожалению, несколько другими способами, чем в Беркли. Разнообразные выпуски Bell Laboratories обозначались словом "System", сопровождаемым римским числом. Окончательным выпуском Unix от Bell Laboratories была System V (или SysV); UNIX System У Release 4 (SVR4) сегодня предоставляет кодовую базу для большинства коммерческих операционных систем Unix. Стандартным документом, описывающим System V, является System V Interface Definition (SVID).

Эта разветвленная разработка Unix значительно разнообразила системные вызовы, системные библиотеки и основные команды систем Unix. Одним из лучших примеров такого расщепления являются сетевые интерфейсы, сопровождающие приложения каждой операционной системы. Системы BSD использовали интерфейс под названием сокетов, позволяющий программам сообщаться друг с другом по сети. С другой стороны, System V предоставила интерфейс транспортного уровня (Transport Layer Interface — TLI), полностью несовместимый с сокетами, и официально определенный транспортный интерфейс X/Open (X/Open Transport Interface — XTI). Такая разнородная разработка значительно снизила переносимость программ между версиями Unix, увеличивая стоимость и уменьшая доступность сторонних продуктов для всех версий Unix.

Еще одним примером несовместимости систем Unix является команда ps, позволяющая запрашивать информацию о процессах операционной системы. В системах BSD команда ps aux выдает полный листинг всех процессов, работающих на машине; в System V эта команда недопустима, вместо нее необходимо использовать ps -ef. Форматы вывода так же несовместимы, как и аргументы командной строки. (Команда ps в Linux пытается поддерживать оба стиля.)

Пытаясь стандартизовать все аспекты Unix, которые разошлись из-за разных подходов к разработке в этот период (это еще известно как "войны Unix"), индустрия Unix спонсировала создание набора стандартов, которые определяют предоставляемые Unix интерфейсы. Часть стандартов, имеющая дело с интерфейсами программных и системных инструментов, была названа POSIX (технически это серия IEEE Std 1003, составленная из многих отдельных и черновых стандартов) и выпущена Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers — IEEE).

Однако исходные серии стандартов POSIX были не полностью завершены. Например, основные концепции UNIX вроде процессов считались необязательными. Более полный стандарт прошел через несколько версий и названий (например, серия стандартов руководства по переносимости X/Open (X/Open Portability Guide — XPG)) перед тем, как был переименован в одиночную спецификацию Unix (Single Unix Specification — SUS), выпущенную The Open Group (владельцем торговой марки UNIX). SUS после нескольких пересмотров была принята IEEE как самая новая версия стандарта POSIX, в настоящее время это IEEE Std 1003.1-2004 [25], и время от времени обновлялась несколькими поправками. IEEE Std 1003.1-2003 был также принят в качестве стандарта ISO/IEC 9945-2003. Самую новую онлайновую версию этого стандарта можно найти по адресу http://www.unixsystems.org/.

Более ранние стандарты, на основе которых был создан этот обновленный унифицированный стандарт, включают все ранние стандарты IEEE Std 1003.1 (POSIX.1 — программный интерфейс С), IEEE Std 1003.2 (POSIX.2 — интерфейс оболочки), а также все связанные стандарты POSIX наподобие расширений реального времени, определенных как POSIX.4, которые позже были переименованы в POSIX.1b, и несколько черновых стандартов.

Поскольку "POSIX" и "SUS" теперь являются синонимами, на комбинированную работу в этой книге мы будем ссылаться как на POSIX.

 

1.4. Происхождение Linux

"Широта выбора — самое лучшее качество, присущее стандартам". К услугам разработчиков Linux была двадцатилетняя история Unix, но более важным является то, что справочными материалами им служили высококачественные стандарты. Изначально Linux разрабатывался в соответствии с POSIX; там, где не было POSIX, Linux следовала практике System V, за исключением организации сетей, где и системные вызовы, и организация сетей придерживались намного более популярной модели BSD. Теперь, когда существует объединенный стандарт SUS/POSIX, дальнейшее развитие обычно совместимо с более новым стандартом POSIX, а прошлые отклонения от него по возможности откорректированы.

Самым существенным отличием между SVR4 и Linux с точки зрения программирования является то, что Linux не предоставляет столько же дублированных программных интерфейсов. Например, даже программисты, занимавшиеся написанием кода исключительно для систем SVR4, предпочитали сокеты Беркли интерфейсу транспортного уровня (TLI) из SysV; Linux избегает накладных расходов TLI и предоставляет только сокеты.

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

 

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

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

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

 

2.1. Авторское право

Сначала рассмотрим более простую проблему. Авторское право (copyright) — это простая защита владения определенными видами интеллектуальной собственности. В соответствии с новейшими соглашениями об авторском праве вам даже не понадобится требовать авторских прав на создаваемый вами материал. Пока вы явно не откажетесь от права собственности, другим лицам будет разрешено использовать вашу интеллектуальную собственность только в строго определенном порядке, называемом законным использованием, пока вы явно не предоставите им разрешение, называемое лицензией, на другие действия. Так что если вы напишете книгу или элемент ПО, вам не нужно помещать на них фразу типа "copyright © год", чтобы получить право собственности на них. Однако если вы не поместите эту фразу в свою работу, вам будет намного сложнее требовать защиты права собственности в суде, если кто-то нарушит либо ваши авторские права (заявляя о том или действуя так, как будто вам не принадлежат авторские права), либо ваши лицензионные условия.

Бернское соглашение об авторском праве (http://www.wipo.org), международный договор о соглашениях об авторском праве и смежных правах, требует от стран-участниц придавать авторским правам законную силу только в случае:

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

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

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

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

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

 

2.2. Лицензирование

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

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

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

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

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

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

 

2.3. Лицензии на свободное ПО

 

Как описывалось в главе 1, термин открытый исходный код (Open Source) был создан как результат попытки разрешить споры вокруг слов "свободный" и "открытый" (free) в словосочетании "свободное ПО" ("free software"). Для управления понятием "открытый исходный код" была создана Инициатива открытого исходного кода (Open source Initiative — OSI) и, несмотря на то, что ее попытки зарегистрировать торговую марку термина (для защиты его значения) были отклонены Службой патентов и торговых знаков США (US Patent and Trademark Office), OSI получила в свое распоряжение знак сертификации "свободное ПО, сертифицированное OSI". (Законных ограничений на использование термина открытый исходный код не существует, но они существуют относительно знака сертификации "свободное ПО, сертифицированное OSI".)

OSI поддерживает определение открытого исходного кода (Open Source Definition — OSD) — описание прав, предоставляемое лицензиями открытого исходного кода; она также поддерживает полный список сертифицированных ею лицензий, чтобы удовлетворить запросы OSD, среди которых — доступность исходного кода, отсутствие ограничений на свободное распространение продукта, разрешение производных работ, а также запрет дискриминации лиц, групп или областей для попыток. Полное OSD вместе со списком лицензий, сертифицированных как "свободное ПО, сертифицированное OSI", доступно на сайте http://opensource.org/.

 

2.3.1. Общедоступная лицензия GNU

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

Кроме того, простое агрегирование другой работы, не основанной на Программе, с Программой (или с работой, основанной на Программе) с помощью тома внешней памяти либо носителя дистрибутива не помещает другую работу в область действия данной Лицензии.

Если вы рассматриваете исполняемый файл как "том внешней памяти", можете прибегнуть к полному агрегированию.

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

 

2.3.2. Общедоступная лицензия библиотеки GNU

Общедоступная библиотечная лицензия GNU (GNU Library General Public Licence — LGPL) предназначена для увеличения общей полезности библиотек. Цель LGPL — разрешить пользователям обновлять или улучшать свои библиотеки без необходимости получения новых версий программ, компонуемых с этими библиотеками. С этой целью LGPL не пытается установить какие-то лицензионные ограничения на программы, компонуемые с библиотекой, до тех пор, пока эти программы скомпонованы с совместно используемыми версиями библиотек, к которым применены условия LGPL, или которые снабжены объектными файлами для приложения, позволяя пользователю заново связывать приложение с новыми либо усовершенствованными версиями библиотеки.

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

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

 

2.3.3. Лицензии стиля MIT/X/BSD

Лицензии стиля MIT/X намного проще, чем GPL или LGPL; их единственным ограничением является (если по простому) поддержка всех существующих уведомлений об авторских правах и лицензионных условий в исходном либо двоичном распространении, и запрет использования имени любого автора без его письменного соглашения в целях подтверждения либо продвижения производных работ.

 

2.3.4. Лицензии старого стиля BSD

Лицензии старого стиля BSD добавляют к условиям лицензий MIT/X существенное ограничение, которое состоит в том, что рекламные материалы, упоминающие свойства ПО, включают подтверждение. Сама лицензия BSD была изменена с целью устранения этого ограничения, но некоторое ПО продолжает пользоваться лицензиями, смоделированными по старой лицензии BSD.

 

2.3.5. Лицензия Artistic License

Исходный код языка Perl распространяется под действием лицензии, позволяющей соблюдать условия или GPL, или альтернативной лицензии с причудливым названием Artistic License (Творческая лицензия). Основной целью этой лицензии является сохранение прав на неограниченное открытое распространение и предотвращение продажи пользователями усовершенствованных патентованных изменений, выдающих себя за официальные версии. Другие авторы ПО приняли соглашение Perl, позволяющее пользователям следовать условиям либо GPL, либо Artistic License; к некоторым применяются условия лишь Artistic License.

 

2.3.6. Несовместимости лицензий

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

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

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

Если код, к которому применены условия GPL или LGPL, включен в работу, производную от лицензии стиля BSD/MIT/X, ко всей производной работе (для всех практических целей) должны быть применены условия GPL либо LGPL соответственно.

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

 

Web-сайт, посвященный этой книге и доступный по адресу http://ladweb.net, содержит дополнения к тексту книги, детальную информацию по темам, выходящим за рамки книги, и ссылки на дополнительные сведения в Internet.

 

3.1. Оперативные страницы руководства

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

Доступ к оперативным страницам руководства предоставляется тремя программами. Программа man отображает отдельные оперативные страницы руководства, а команды apropos и whatis ищут ключевые слова в наборе оперативных страниц руководства. Команды apropos и whatis производят поиск в одной и той же базе данных; различие состоит в том, что whatis отображает только строки, в точности соответствующие слову, которое вы ищете, a apropos отображает любую строку, содержащую слово, которое вы ищете. К примеру, если вы ищете man, apropos отобразит manager и manipulation, в то время как whatis отобразит лишь слово man, отделенное от других букв пробелом либо знаком пунктуации, например, man.config. Попробуйте запустить команды whatis man и apropos man, чтобы увидеть разницу.

Многие оперативные страницы руководства в Linux являются частью большого пакета, собранного процессором лингвистической информации (language data processor — LDP). А именно, страницы разделов 2 (системные вызовы), 3 (библиотеки), 4 (специальные файлы или файлы устройств) и 5 (форматы файлов) принадлежат в основном к коллекции оперативных страниц руководства LDP и являются наиболее полезными в программировании. Если необходимо выяснить, какой раздел следует просмотреть, укажите номер этого раздела перед названием оперативной страницы руководства, которую вы намереваетесь просмотреть.

Например, man man предоставляет оперативную страницу руководства для команды man из раздела 1; если вы хотите просмотреть спецификацию о написании оперативных страниц руководства, укажите раздел 7 — man 7 man.

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

Также обратите особое внимание на то, что оперативные страницы руководства библиотеки поддерживаются отдельно от самой библиотеки С. Поскольку библиотека С обычно не меняет своего поведения, это не является проблемой. Все дистрибутивы Linux теперь используют библиотеку GNU С, которая рассматривается в главе 6. К библиотеке GNU С прилагается полная документация. Эта информация доступна в форме Texinfo.

 

3.2. Информационные страницы

В проекте GNU для представления документации был принят формат Texinfo. Документацию Texinfo можно распечатать (используя преобразование в ТЕХ) либо прочитать в онлайне (в формате "info", очень раннем гипертекстовом формате, предшествующем World Wide Web). В Linux существует множество программ для чтения информационной документации. Ниже приведен небольшой перечень.

• В редакторе Emacs есть режим чтения информации; наберите X info для входа в этот режим.

• Программы info и pinfо являются небольшими программами текстового режима для быстрого просмотра информационных страниц.

• Большинство программ системной документации (например, программы yelp от GNOME и khelpcenter от KDE) могут отображать информационные страницы. Мы рекомендуем эти инструменты, поскольку они предоставляют гипертекстовый интерфейс к информационным страницам, более знакомый всем, кто умеет использовать Web-браузер, чем интерфейс, предоставляемый Emacs, info или pinfо. (Эти инструменты также предлагают другую системную документацию, например, оперативные страницы руководства и документацию по системе, частью которой они являются.)

 

3.3. Прочая документация

Каталог /usr/share/doc представляет собой всеохватывающее место для несобранной иными способами документации. Большинство пакетов, установленных в вашей системе, инсталлируют внутри каталога /usr/share/doc файлы "README", документацию в разных форматах (включая простой текст, PostScript, PDF и HTML) и примеры. У каждого пакета имеется свой собственный каталог, носящий имя этого пакета и номер его версии.