Debugging Licenses отладка лицензионной политики

История комментариев к событиям вокруг ошибки в библиотеке zlib достаточно поучительна.

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

Необычен масштаб: сжатие по Зиву-Лемпелю и, соответственно, декомпрессия сжатых данных - один из наиболее интенсивно используемых протоколов как в Сети, так и при локальном сохранении данных. «Ширина» открывшегося «коридора уязвимости» очень велика, хотя «угол наклона» его, к счастью, не столь велик, как того опасались.

Дыра была обнаружена Маттиасом Класеном, тестировавшим одну из библиотек Gnome, зависящую от библиотеки работы с популярным графическим форматом png, в свою очередь, зависящей от zlib, в конце февраля, две недели обсуждалась в ряде закрытых листов рассылки, и 11-12 марта была закрыта согласованной публикацией «заплаток» от ведущих поставщиков дистрибутивов ОС (включая российских) и отдельных пакетов.

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

Однако же дело с уязвимостью систем обстоит прямо противоположным образом: в типичном «большом» дистрибутиве той же Linux потенциально попало под угрозу, наверное, под сотню программ, пакетов и библиотечных модулей. Но если вы обратите внимание на выпущенные пакеты заплаток, то обнаружите, что заменить или «пропатчить» нужно лишь чуть более десятка программ. Почему? Потому что в большинстве случаев функциональность zlib задействуется с помощью динамической компоновки: достаточно «пофиксить» саму библиотеку, а программы трогать не надо. Это «UNIX way» и стиль свободной разработки.

И даже если команда поддержки свободного пакета или дистрибутива была в эти весенние дни занята чем-то более сезонно уместным, диагностика проста: одной командой поискать «zlib» в исходниках и, если они по какой-то причине прикомпоновывают ее статически, - проверить версию. Все. Ответ однозначный: «да/нет».

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

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

Если авторы хотят (или обязаны в соответствии с контрактом или грантом) сделать библиотеку доступной к использованию авторами как свободного, так и проприетарного софта, им стоит обратить внимание на GNU Lesser General Public License (LGPL; ранняя версия этой лицензии называлась Library GPL, то есть «Универсальная общественная лицензия для библиотек» ²).

В частности, это хороший вариант для лицензирования софта, созданного с привлечением общественных (государственных) средств, - в большинстве случаев сегодня он лицензируется «в стиле BSD» ³.

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

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

1. если функциональность и качество библиотеки полностью удовлетворяют авторов значительного количества нового кода, ее спецификация будет «естественно» приобретать качества фактического стандарта с единой доминирующей реализацией (и совокупный объем кода, эксплуатируемого конечным пользователем, будет уменьшаться);

2. если автор нового кода видит недостаток функциональности или ошибки в библиотеке, он будет (при прочих равных) стараться контрибутировать свой вклад в общее дерево разработки ⁵, и качество общедоступного кода будет расти;

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

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