Для команды разработчиков выбор операционной системы (ОС) является одним из важнейших решений, которое в итоге определяет возможности продукта. От архитектуры и особенностей выбранной ОС в немалой степени зависит, каким образом конечный продукт будет описан, разработан и внедрен. Это в особенности относится к встраиваемым системам, которые, как правило, имеют увеличенные сроки службы и повышенные требования к уровню готовности. Ключевым, но часто недооцененным моментом при выборе ОС в таких случаях является форма лицензирования на ее использование. Существуют разные типы лицензирования — от полностью проприетарного метода до метода на основе открытого исходного кода: например, GNU General Public License версии 3 (GPLv3), Berkely Software Distribution (BSD).

Характер лицензии оказывает значительное влияние на весь процесс разработки встраиваемого устройства. Например, если в устройстве используется программное обеспечение GNU/Linux или иное ПО, лицензированное по условиям GNU General Public License версии 2 (GPLv2), то управление правами на интеллектуальную собственность становится критически важным элементом в течение всего процесса разработки. Аналогичным образом обязательства по распространению, налагаемые условиями лицензии на открытый исходный код, часто бывают невыполнимыми на рынках встраиваемых устройств. Ограниченная постоянная ответственность за использование кода и, следовательно, риск остановки производства оказываются просто неприемлемыми для производителей встраиваемых устройств.

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

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

Обязательства по лицензиям с открытым исходным кодом

Открытый исходный код подразумевает не только его общедоступность, но и набор определенных обязательств со стороны пользователя, которые являются ключом к сохранению целостности модели разработки. Если лицензиат не выполняет эти обязательства, он лишается лицензии. Воспроизведение компьютерного ПО без лицензии от обладателя авторских прав — есть нарушение авторского права. Этот подход лежит в основе деятельности таких все более активных групп по защите авторских прав, как Compliance Lab организации Free Software Foundation (FSF) и gpl-violations.org. Таким образом, обладатели авторских прав на открытый исходный код имеют хорошую защиту, которая мешает приобретателям лицензии поставлять продукты без соблюдения ограничивающих запретов.

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

В проектах, в которых применяется ОС с открытым исходным кодом, в конечном итоге неизбежно используются компоненты с открытым исходным кодом из других различных источников. Это означает, что для надлежащего лицензирования потребуется не только учитывать происхождение кода, но и проводить оценку совместимости разных лицензионных условий. Для оказания помощи в этом процессе организация Open Source Initiative (OSI) рассматривает и сертифицирует лицензии на предмет наличия в них определенных основополагающих элементов, характерных для модели с открытым исходным кодом. В составленный этой компанией список в настоящее время включено 60 утвержденных лицензий. Конечно, это пока немного, и значительное количество лицензий еще предстоит рассмотреть.

Лицензии на открытый исходный код во встраиваемых системах

Условия лицензирования на открытый исходный код имеют огромное значение в тех случаях, когда этот подход применяется к созданию программных продуктов. В некоторых случаях разработчики должны открыть весь модифицированный и связанный код для сообщества пользователей открытого исходного кода, в результате фактически раскрыв свою технологию дифференциации продукта. Чтобы понять, почему это происходит, рассмотрим более детально GPLv2, которая была разработана FSF под руководством Ричарда Столлмана.

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

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

Организация FSF 29 июня 2007 г. выпустила в свет лицензию GPLv3, частично устраняющую неясности в GPLv2. Большая часть ПО, лицензированного по условиям GPLv2, вполне допускает применение последующих версий GPL. К сожалению, код, ограниченный исключительно условиями GPLv2 (например, ядро Linux), несовместим с условиями GPLv3.

Разработка ПО для встраиваемых систем и лицензия GPL

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

Каждый исполняемый компонент является результатом компиляции исходного кода и его связывания с различными библиотеками. Чтобы полностью понять лицензионный статус исполняемого файла, необходимо изучить все лицензионные условия, относящиеся, во-первых, к коду в базовом файле исходного кода; во-вторых, к содержимому каждого заголовочного файла, включенному в промежуточную версию объектного кода в процессе компиляции (т. е. как результат применения “include” в исходном коде); в-третьих, к любым статически связанным библиотекам, инкорпорированным в исполняемую версию кода во время стадии компоновки; в-четвёртых (в зависимости от интерпретации GPL), к любым динамически связанным компонентам, используемым программой во время исполнения.

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

Принято считать, что интерфейс системных вызовов отделяет код приложения от кода ядра для реализации Copyleft-условий лицензии GPLv2 в отношении ОС (например, GNU/Linux). Оба вида кода взаимодействуют между собой только через прозрачный API на основе механизма обмена сообщениями. Программы, находящиеся на противоположных сторонах интерфейса системных вызовов, не требуют подробных сведений о собственной работе. Эта изоляция привела к распространенному мнению, что проприетарные приложения могут работать с ОС, распространяемой на основе GPL, не нарушая проприетарных лицензионных условий.

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

Как было сказано выше, большая часть преимуществ во встраиваемых устройствах создается посредством оптимизации и настройки кода на низком уровне. Усовершенствованные графические драйверы, функции управления электропитанием, оптимизированные сетевые драйверы — все это примеры такого кода. В архитектуре операционной среды Linux данные компоненты располагаются в пространстве ядра. В большинстве случаев функциональность такого типа связана непосредственно с ядром, в результате чего вступают в действие условия Copyleft лицензии GPLv2.

Однако не все компании и разработчики отказываются от своих авторских прав на драйверы и оптимизированные компоненты ОС. Они выделяют свой проприетарный код в отдельные исполняемые компоненты, которые называются “загружаемые модули ядра” (Kernel Loadable Modules — KLM).

Для того чтобы управлять допустимым поведением экосистемы, сообщество Linux выработало интерфейс Kernel Module Interface API, который служит для вызова KLM. Идея состоит в том, чтобы вывести проприетарные KLM из-под условий GPLv2 таким же образом, как интерфейс системных вызовов изолирует проприетарные приложения.

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

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

Эволюция лицензии GPL — GPLv3

Возникшая в 1991 г. лицензия GPLv2 оставалась без изменений в течение 16 лет. Однако в 2007-м организация FSF выпустила в свет GNU General Public License версии 3 (GPLv3), которая представляет собой неоднозначное продолжение лицензии GPL, вызвавшее жаркие споры. Лицензия GPLv3 является попыткой интернационализировать содержание GPL, улучшить ее совместимость с другими лицензиями на ПО с открытым исходным кодом и прояснить многие неоднозначные положения в GPLv2.

Первое важное уточнение в GPLv3 — прямое утверждение, что динамическое связывание вызывает нарушение правил применения GPL. Если лицензия GPLv3 будет принята сообществом Linux (прямо или косвенно, как результат несовместимости GPLv2- и GPLv3-кодов), продавцы и производители оборудования, ранее использовавшие KLM для работы проприетарных модулей ОС, должны будут сделать нелегкий выбор.

Первоначальный запрет на использование в проектах GPLv3 спецификации Digital Rights Management (DRM) в результате полуторагодичного публичного обсуждения был снят, и в целом лицензия GPLv3 не допускает использования производителями потребительских устройств специальных технических средств, препятствующих пользователям модифицировать ПО производителя. В окончательной версии лицензии запрещено лишь то, что было названо “тивоизацией” кода (“TiVo-ization”), соответствующего условиям GPLv3, в потребительских устройствах (компания TiVo запрещает пользователям применять в своих устройствах модифицированное встраиваемое ПО, используя для этого специальные ключи с подписью). Положения патентной лицензии GPLv3 также были пересмотрены. В частности, предоставлять лицензии на соответствующие патенты обязаны не все дистрибьюторы, а только те, кто распространяет модифицированные версии кода, лицензированного по условиям GPLv3.

Заключение

Для ИТ-инфраструктуры использование программного обеспечения с открытым исходным кодом даёт много преимуществ. Незащитные лицензии (например, Apache, BSD и MIT) способствуют совместным действиям, которые полезны для всей индустрии. Однако производители встраиваемых систем, которые применяют ПО на условиях защитных лицензий (например, GPL), существенно рискуют. Эти компании должны соблюдать осторожность и приложить усилия к обеспечению тщательного управления проектами и защите проприетарного кода. Компания, которая использует KLM для защиты проприетарных технологий, подвергает себя риску судебных разбирательств.

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