Привет! С вами снова я, QA-специалист SimbirSoft, Максим. В прошлой статье рассказал, зачем разработчикам, бизнесу и широкой аудитории пользователей программного обеспечения нужно изучать вопрос лицензирования. В этой части обсудим несколько популярных лицензий, а также их возможное влияние на итоговый продукт. Подчеркну, при создании коммерческого ПО необходимо учитывать все используемые лицензии, а после релиза лицензировать и сам продукт.
Дисклеймер: эта статья не может служить справочником и прямым руководством к действию. В первую очередь, она основана на личном опыте автора и его взгляде на основные конфликты лицензирования и способы их разрешения. Помните, что правовые нормы меняются. Проверяйте их с учетом особенностей ПО и законодательства страны (стран), на территории которых оно будет распространяться.
В комментариях к предыдущей статье поступали разные вопросы, в том числе о применении нелицензированного продукта. Тут есть два момента:
При этом еще раз отмечу, лицензии, насколько бы они ни были запрещающими, не только описывают правила использования продукта, но и помогают понять, как их правильно применять.
Например, вы решили взять библиотеку а для микросервиса, но она запечатана под GPL лицензией. Проблему можно решить. Эту часть приложения можно выделить в отдельный микросервис А. Далее лицензировать весь микросервис и выложить в открытый доступ (например, на GitHub). При этом из него нужно будет исключить ключевые бизнес-процессы. Если вы не можете этого сделать нельзя выкладывать данные, содержащие коммерческую тайну.
Также можно работать с Standalone-приложением: выделить часть кода в отдельный модуль и подгрузить его в процессе работы системы как внешнюю библиотеку и заменить её уже после сборки.
Далее рассмотрим возможности и ограничения наиболее популярных лицензий.
Первая версия изначально выпускалась как пародия на «свободную» лицензию GPL. Автор хотел показать, чем она отличается от псевдо свободной GPL, которая накладывает ограничение на сокрытие исходного кода.
Использование этой лицензии я бы не рекомендовал из-за их пародийности – первая версия написана не юридически точным языком и может быть разночтение. Вторая версия исправлена, но также может вызвать множество вопросов при судебном разбирательстве. Если нужен уровень «public domain», можно обратиться к лицензии Creative Commons Zero.
Это нелицензируемая лицензия. Нежелательно выбирать для лицензирования своего продукта и при использовании библиотек под этой лицензией из-за большой возможности двойной трактовки. Если нужен уровень «public domain», также можно обратиться к лицензии Creative Commons Zero.
Creative Commons – некоммерческая организация, которая создала бесплатные для использования типовые договора – свободные и несвободные публичные лицензии.
По моему мнению, у Creative Commons самая понятная система. Тут я бегло перечислю, какие и где использовать. Более подробную информацию о лицензиях можно прочитать у них на сайте. Один из огромных плюсов этих лицензий – они применимы не только к ПО, но и любым другим произведениям (музыка, текст, изображение, видео).
Читать лицензии довольно просто – по обозначениям и их комбинациям:
X11, MIT-0, MIT – полностью совместимы с закрытым коммерческим продуктом
Проблема данной группы лицензий в том, что изначально (лицензия существует с 1980 года) было несколько вариантов с разными ограничениями и требованиями. Поэтому каждую лицензию следует рассматривать отдельно (кроме X11, которая уже стандартизирована), поскольку в одних необходимо упоминание автора и продукта, в других нет. При этом у таких лицензий чаще всего общее наименование.
Есть особое условие – продукт не должен быть использован «для зла, только для добра». При этом этические рамки «добра» и «зла» не уточняются, а это осложняет ситуацию – разработчик ПО может подать в суд за любую мелочь. Проблемы при совместимости возникают из-за неоднозначности трактовки терминов.
Группа лицензий, утвержденная и созданная советом регентов Калифорнийского университета. Проблема этой группы – большое разнообразие наименований. У всех есть менее распространенные названия, которые могут использоваться в сопутствующий артефактах проекта. Лучше обращаться к лицензии в исходниках или в готовом приложении.
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов, лицензии, а также предварительного уведомления авторов продукта и получении разрешения на упоминании их. Не рекомендуем к использованию.
Проблемная лицензия. Условия: во всех материалах необходимо упоминать все части ПО, которые добавлены в итоговый продукт, а также связываться с изначальным правообладателем и информировать его, спрашивать разрешение на использование.
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов, лицензии, а также предварительного уведомления авторов продукта и получении разрешения на упоминании их. Не рекомендуем к использованию.
Могут возникнуть проблемы из-за пункта условий, по которому необходимо письменно уведомить автора об использовании его продукта, а также получить письменное разрешение от автора или правообладателя.
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта и его авторов.
Лицензия 0BSD совместима с коммерческим использованием в закрытых продуктах.
Отличие версий — в удобстве использования условий. Процесс указания продукта и авторов под второй лицензией упрощен и более предпочтителен из-за меньшей бумажной волокиты.
The GNU Project – проект изначально создан для разработки свободного ПО и придерживается манифеста. Для такого проекта понадобились собственные лицензии, которые были приняты обществом и используются во многих проектах.
Основная цель большинства лицензий GNU – сохранить открытость и доступность исходного кода, документации и сопутствующих артефактов проекта.
Лицензии несовместимы с закрытым коммерческим продуктом
Лицензии не запрещают использование для коммерческих целей, но обязывают выкладывать, поддерживать и актуализировать доступность исходных инструкций, что позволяет полностью копировать итоговый продукт. Использование библиотеки, распространяемой под лицензией, обязывает лицензировать весь код приложения под такой же или совместимой лицензией.
Единственный способ обойти ограничение на выкладывание в общий доступ исходников – использование самого продукта только в личных целях. Например, в качестве бэкенд-сервиса, предоставляющего готовые данные для другого приложения или в артефактах проекта, или иным способом, который не подразумевает прямую связь с закрытым продуктом. Владельцем клиентского приложения должен быть тот же правообладатель.
Интересно, что из-за изменений, внесенных в тексты лицензий, даже разные версии этой лицензии несовместимы друг с другом.
Лицензии несовместимы с закрытым коммерческим продуктом
Данный тип лицензий полностью перекрывает все возможности расширенного использования, указанные во всех GPL. Если вы создаете ПО на основе продукта с такой лицензией, вы обязаны лицензировать его под подобной лицензией.
Если сервис, предоставляющий погоду и карты городов, покрыт лицензией AGPL, то и клиентское приложение, получающее эти данные и выводящее их для пользователя, должно распространяться под лицензией AGPL или совместимой GPL (GPL-3.0-or-later, GPL-3.0-only).
Лицензия несовместима с закрытым коммерческим продуктом
Если вы думали, что AGPL – строгая лицензия, можете почитать условия этой вирусной лицензии. По её тексту до сих пор есть множество вопросов и она настолько «вирусная», что я не знаю ни одного проекта, написанного с использованиям этой лицензии, кроме MongoDB «бесплатной» версии. Если вы используете MongoDB, которая распространяется по двойному лицензированию (об этом – ниже), проверьте – приобретена ли у вас нормальная лицензия или в разработке используется open source версия.
Эта лицензия во всём копирует лицензию AGPL, но является более строгой в определениях границ работы лицензии и более вирусной — она обязывает лицензировать остальную часть продукта под этой же лицензией.
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов и доказательной базы «библиотечности» и доступности исходников библиотеки
Измененная и расширенная лицензия GPL позволяет использовать ПО в закрытых коммерческих продуктах на особых условиях: подключение LGPL-приложений (библиотек) в качестве отдельных модулей (компонентов) с упоминанием продуктов и авторов в конечном продукте (его артефактах).
Оно не отменяет правила, что сами библиотеки должны также распространяться под LGPL-лицензией. Но определить, что такое подключаемая библиотека и в каком виде необходимо предоставлять исходники, непросто.
BSL v1.1 License несовместима с коммерческим использованием в закрытых продуктах, необходимо использовать библиотеки, лицензируемые под коммерческой лицензией
Отличный пример постепенного замещения старой лицензии на новую (двойную). На текущий момент все новые релизы выходят под лицензией BSL, но по прошествии трех лет собираются возвращать старую лицензию Apache 2.0.
Невнимательное обновление версий может привести к нарушению новой лицензии. Условия: продукт недоступен для коммерческого использования, можно только в качестве «песочницы». Но можно использовать в продуктах, лицензируемых под GPL (старше второй версии).
Для закрытого коммерческого ПО необходимо запрашивать коммерческую версию, у которой есть ограничение: ПО бесплатно только для компаний, зарабатывающих в год менее 25 млн долларов. Для других компаний необходимо оформлять подписку.
Двойное лицензирование продукта рассмотрим отдельно. Поскольку такие продукты вводят в заблуждение своими двойными стандартами. Пример: Oracle’s MySQL, Qt, MongoDB.
Суть: исходники лицензируются под двумя лицензиями, создавая как бы две ветки развития продукта. Одна обычно распространяется под GPL (AGPL) лицензией или уникальной лицензией (например, SSPL), которая ограничивает использование в коммерческом закрытом продукте. Вторая (чаще всего платная, иногда с дополнительной поддержкой и расширенными возможностями) распространяется под специальной коммерческой лицензией.
Важно, чтобы разработчики не перемешивали эти продукты вместе, иначе вирусная лицензия GPL нивелирует коммерческую версию или будет прямое нарушение уникальной лицензии.
Хочу упомянуть еще об одном важном моменте в лицензировании – EULA (End-user license agreement) – это конечный договор, заключаемый с пользователем. Для больших и сложных продуктов в нем должны быть указаны все права пользователя, правообладателя и автора.
Это очень важная часть сделки, ведь именно здесь происходит «закрытие огромной матрёшки» всех лицензий, используемых в продукте. Здесь указаны обязательные упоминания ПО, библиотек в соответствии с их лицензиями, а также информация о правилах применения продукта. Здесь необходимо убедиться, использует ли приложение стороннее API и какие именно данные оно может передавать в другие источники.
В большинстве случаев сверка лицензий производится при добавлении новых библиотек и частей в продукт, а также при обновлении существующих зависимостей, поскольку в новых версиях может быть изменена лицензия. Этот процесс можно частично автоматизировать с помощью Black Duck и схожих инструментов. Но результаты работы этих инструментов также необходимо перепроверять. К тому же, сверку они делают только по исходному коду и поиску паттернов (это часто приводит к сбоям и неправильной идентификации), а не медиафайлам.
Важно проверять совместимость с конечной лицензией и лицензиями другого ПО, используемого в продукте – не только импорт, от которого будет зависеть продукт, но и вложения в нем. У вновь добавляемого ПО могут быть свои зависимости. А если вы делегируете юридические вопросы поставщику приложения или консультанту, убедитесь в их опыте и будьте внимательны – все могут ошибаться, а отвечать вам.
Многие организации занимаются вопросами лицензирования и совместимости лицензий. Как пример можно посмотреть на сравнительную таблицу совместимостей от Open Source Automation Development Lab (OSADL), взятую из их презентации:
В нормальном разрешении схема доступна после регистрации на сайте организации. Копия – на imgur.
На лицензирование необходимо проверять не только исходный код, но и тексты, графику, музыку, звуки. Для медиаматериалов должно быть подтверждение использованной лицензии или отказ от прав (в идеале – в письменном виде и храниться вместе с артефактами проекта). Также при проверке важно подключать юристов и специалистов, которые понимают существующие проблемы, например, проблему патентов (computational idea patents).
Важно сверять все файлы, включенные в исходный код. Некоторые из них могут содержать сокращенную версию лицензии, так называемую «шапку», с указанием ссылок на развернутую версию.
Лицензии учитываются всегда, даже если просто вписаны как часть файла исходников. Кроме того, должна легко прослеживаться граница лицензирования – файлы, распространяемые под разными лицензиями, перемешивать нельзя. Однако есть лицензии, которые позволяют лицензировать не только файл целиком, но и отдельные функции или части. Особенно это важно для ПО и инструментов, которые распространяются под двойной лицензией из-за их большой схожести между собой.
При создании ПО чем раньше будет рассматриваться вопрос лицензирования, тем проще исправить ошибки, и тем меньше работы предстоит выполнить во время тестирования ПО. Это особенно важно учитывать при разделении коммерческого приложения и библиотек.
Понимание необходимости лицензирования и стандартов определения данного типа договоров позволяет правообладателям удерживать свои позиции, авторам становиться более заметными в сообществе, а пользователям видеть границу прав и обязательств.
Права любого человека заканчиваются там, где начинаются права другого. Видеть эту границу необходимо каждому, и лицензии – место, где они показаны. Сейчас любое приложение состоит из произведений множества авторов и правообладателей. Знать, как работать с такой сложной структурой, – обязанность любого разработчика. Сообщества сейчас упрощают эти взаимодействия, объединяя множество разных видов договоров в единые стандартные лицензии, работать с которыми становится значительно удобнее.
Надеюсь, статья открыла для вас что-то новое.
Больше кейсов и полезных материалов в наших каналах:
Дисклеймер: эта статья не может служить справочником и прямым руководством к действию. В первую очередь, она основана на личном опыте автора и его взгляде на основные конфликты лицензирования и способы их разрешения. Помните, что правовые нормы меняются. Проверяйте их с учетом особенностей ПО и законодательства страны (стран), на территории которых оно будет распространяться.
В комментариях к предыдущей статье поступали разные вопросы, в том числе о применении нелицензированного продукта. Тут есть два момента:
- Нелицензирование ранее лицензированного ПО. Любое использование такого продукта незаконно. Поскольку изначально продукт (полностью или частично) был лицензирован. Когда с него убрали лицензии, это стало прямым нарушением.
- Изначальное нелицензирование продукта. Использовать такое ПО (в США оно регламентируется правовой доктриной Fair Use, в РФ – статьями Гражданского Кодекса, объединенных институтом Свободного использования произведений) можно, если не нарушаются права автора и правообладателя, т.е. объемы и цели такого использования всё равно ограничены законами. На проде применение такого ПО неприемлемо, поскольку несет в себе риски.
При этом еще раз отмечу, лицензии, насколько бы они ни были запрещающими, не только описывают правила использования продукта, но и помогают понять, как их правильно применять.
Например, вы решили взять библиотеку а для микросервиса, но она запечатана под GPL лицензией. Проблему можно решить. Эту часть приложения можно выделить в отдельный микросервис А. Далее лицензировать весь микросервис и выложить в открытый доступ (например, на GitHub). При этом из него нужно будет исключить ключевые бизнес-процессы. Если вы не можете этого сделать нельзя выкладывать данные, содержащие коммерческую тайну.
Также можно работать с Standalone-приложением: выделить часть кода в отдельный модуль и подгрузить его в процессе работы системы как внешнюю библиотеку и заменить её уже после сборки.
Далее рассмотрим возможности и ограничения наиболее популярных лицензий.
Лицензии, совместимые с коммерческим использованием в закрытых продуктах
WTFPL
Первая версия изначально выпускалась как пародия на «свободную» лицензию GPL. Автор хотел показать, чем она отличается от псевдо свободной GPL, которая накладывает ограничение на сокрытие исходного кода.
Использование этой лицензии я бы не рекомендовал из-за их пародийности – первая версия написана не юридически точным языком и может быть разночтение. Вторая версия исправлена, но также может вызвать множество вопросов при судебном разбирательстве. Если нужен уровень «public domain», можно обратиться к лицензии Creative Commons Zero.
Unlicense
Это нелицензируемая лицензия. Нежелательно выбирать для лицензирования своего продукта и при использовании библиотек под этой лицензией из-за большой возможности двойной трактовки. Если нужен уровень «public domain», также можно обратиться к лицензии Creative Commons Zero.
Creative Commons
Creative Commons – некоммерческая организация, которая создала бесплатные для использования типовые договора – свободные и несвободные публичные лицензии.
- CC0 полностью совместима с закрытым коммерческим продуктом
- CC-BY совместима с закрытым коммерческим продуктом при сохранении и указании имени автора модуля.
- CC-BY-ND совместима с закрытым коммерческим продуктом, как и CC-BY, но с дополнительным условием: нельзя вносить изменения в модуль, лицензируемый под этой лицензией
- CC-BY-SA, CC-BY-NC, CC-BY-NC-SA, CC-BY-NC-ND несовместимы с закрытым коммерческим продуктом
По моему мнению, у Creative Commons самая понятная система. Тут я бегло перечислю, какие и где использовать. Более подробную информацию о лицензиях можно прочитать у них на сайте. Один из огромных плюсов этих лицензий – они применимы не только к ПО, но и любым другим произведениям (музыка, текст, изображение, видео).
Читать лицензии довольно просто – по обозначениям и их комбинациям:
- СС (Creative Commons): показывает, какая это лицензия.
- BY (Attribution): обязательно указание авторства, ссылки на лицензию и обозначение изменений, если таковые были сделаны. Это можно сделать любым разумным способом.
- SA (Share Alike): при изменении материала или использовании его для другого произведения, необходимо переделанные части материала на условиях той же лицензии, в соответствии с которой распространяется оригинал.
- NC (Non Commercial): запрет на использование в коммерческих целях или получение коммерческого преимущества.
- ND (No Derivatives): запрет на распространение преобразованного или производного материала, кроме случаев изменения формата.
MIT
X11, MIT-0, MIT – полностью совместимы с закрытым коммерческим продуктом
Проблема данной группы лицензий в том, что изначально (лицензия существует с 1980 года) было несколько вариантов с разными ограничениями и требованиями. Поэтому каждую лицензию следует рассматривать отдельно (кроме X11, которая уже стандартизирована), поскольку в одних необходимо упоминание автора и продукта, в других нет. При этом у таких лицензий чаще всего общее наименование.
Лицензии, совместимые с коммерческим использованием при определенных условиях
JSON Licence
Есть особое условие – продукт не должен быть использован «для зла, только для добра». При этом этические рамки «добра» и «зла» не уточняются, а это осложняет ситуацию – разработчик ПО может подать в суд за любую мелочь. Проблемы при совместимости возникают из-за неоднозначности трактовки терминов.
BSD
Группа лицензий, утвержденная и созданная советом регентов Калифорнийского университета. Проблема этой группы – большое разнообразие наименований. У всех есть менее распространенные названия, которые могут использоваться в сопутствующий артефактах проекта. Лучше обращаться к лицензии в исходниках или в готовом приложении.
BSD-4-Clause
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов, лицензии, а также предварительного уведомления авторов продукта и получении разрешения на упоминании их. Не рекомендуем к использованию.
Проблемная лицензия. Условия: во всех материалах необходимо упоминать все части ПО, которые добавлены в итоговый продукт, а также связываться с изначальным правообладателем и информировать его, спрашивать разрешение на использование.
BSD-3-Clause
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов, лицензии, а также предварительного уведомления авторов продукта и получении разрешения на упоминании их. Не рекомендуем к использованию.
Могут возникнуть проблемы из-за пункта условий, по которому необходимо письменно уведомить автора об использовании его продукта, а также получить письменное разрешение от автора или правообладателя.
BSD-2-Clause
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта и его авторов.
Лицензия 0BSD совместима с коммерческим использованием в закрытых продуктах.
Apache License
Отличие версий — в удобстве использования условий. Процесс указания продукта и авторов под второй лицензией упрощен и более предпочтителен из-за меньшей бумажной волокиты.
- Apache v1.0 совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта и его авторов в конечном EULA.
- Apache v1.1 совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов в документации проекта.
- Apache v2.0 совместима с коммерческим использованием в закрытых продуктах.
Лицензии, несовместимые с использованием в коммерческих продуктах
Лицензии GNU
The GNU Project – проект изначально создан для разработки свободного ПО и придерживается манифеста. Для такого проекта понадобились собственные лицензии, которые были приняты обществом и используются во многих проектах.
Основная цель большинства лицензий GNU – сохранить открытость и доступность исходного кода, документации и сопутствующих артефактов проекта.
GPL
- GPL-3.0-or-later
- GPL-3.0-only
- GPL-2.0-or-later
- GPL-2.0-only
- GPL-1.0-or-later
- GPL-1.0-only
Лицензии несовместимы с закрытым коммерческим продуктом
Лицензии не запрещают использование для коммерческих целей, но обязывают выкладывать, поддерживать и актуализировать доступность исходных инструкций, что позволяет полностью копировать итоговый продукт. Использование библиотеки, распространяемой под лицензией, обязывает лицензировать весь код приложения под такой же или совместимой лицензией.
Единственный способ обойти ограничение на выкладывание в общий доступ исходников – использование самого продукта только в личных целях. Например, в качестве бэкенд-сервиса, предоставляющего готовые данные для другого приложения или в артефактах проекта, или иным способом, который не подразумевает прямую связь с закрытым продуктом. Владельцем клиентского приложения должен быть тот же правообладатель.
Интересно, что из-за изменений, внесенных в тексты лицензий, даже разные версии этой лицензии несовместимы друг с другом.
AGPL
- AGPL-3.0-or-later
- AGPL-3.0-only
Лицензии несовместимы с закрытым коммерческим продуктом
Данный тип лицензий полностью перекрывает все возможности расширенного использования, указанные во всех GPL. Если вы создаете ПО на основе продукта с такой лицензией, вы обязаны лицензировать его под подобной лицензией.
Если сервис, предоставляющий погоду и карты городов, покрыт лицензией AGPL, то и клиентское приложение, получающее эти данные и выводящее их для пользователя, должно распространяться под лицензией AGPL или совместимой GPL (GPL-3.0-or-later, GPL-3.0-only).
SSPL
Лицензия несовместима с закрытым коммерческим продуктом
Если вы думали, что AGPL – строгая лицензия, можете почитать условия этой вирусной лицензии. По её тексту до сих пор есть множество вопросов и она настолько «вирусная», что я не знаю ни одного проекта, написанного с использованиям этой лицензии, кроме MongoDB «бесплатной» версии. Если вы используете MongoDB, которая распространяется по двойному лицензированию (об этом – ниже), проверьте – приобретена ли у вас нормальная лицензия или в разработке используется open source версия.
Эта лицензия во всём копирует лицензию AGPL, но является более строгой в определениях границ работы лицензии и более вирусной — она обязывает лицензировать остальную часть продукта под этой же лицензией.
LGPL
- LGPL-3.0-or-later
- LGPL-3.0-only
- LGPL-2.1-or-later
- LGPL-2.1-only
- LGPL-2.0-or-later
- LGPL-2.0-only
Лицензия совместима с коммерческим использованием в закрытых продуктах при условии указания самого продукта, его авторов и доказательной базы «библиотечности» и доступности исходников библиотеки
Измененная и расширенная лицензия GPL позволяет использовать ПО в закрытых коммерческих продуктах на особых условиях: подключение LGPL-приложений (библиотек) в качестве отдельных модулей (компонентов) с упоминанием продуктов и авторов в конечном продукте (его артефактах).
Оно не отменяет правила, что сами библиотеки должны также распространяться под LGPL-лицензией. Но определить, что такое подключаемая библиотека и в каком виде необходимо предоставлять исходники, непросто.
Business Source License
BSL v1.1 License несовместима с коммерческим использованием в закрытых продуктах, необходимо использовать библиотеки, лицензируемые под коммерческой лицензией
Отличный пример постепенного замещения старой лицензии на новую (двойную). На текущий момент все новые релизы выходят под лицензией BSL, но по прошествии трех лет собираются возвращать старую лицензию Apache 2.0.
Невнимательное обновление версий может привести к нарушению новой лицензии. Условия: продукт недоступен для коммерческого использования, можно только в качестве «песочницы». Но можно использовать в продуктах, лицензируемых под GPL (старше второй версии).
Для закрытого коммерческого ПО необходимо запрашивать коммерческую версию, у которой есть ограничение: ПО бесплатно только для компаний, зарабатывающих в год менее 25 млн долларов. Для других компаний необходимо оформлять подписку.
Двойное лицензирование
Двойное лицензирование продукта рассмотрим отдельно. Поскольку такие продукты вводят в заблуждение своими двойными стандартами. Пример: Oracle’s MySQL, Qt, MongoDB.
Суть: исходники лицензируются под двумя лицензиями, создавая как бы две ветки развития продукта. Одна обычно распространяется под GPL (AGPL) лицензией или уникальной лицензией (например, SSPL), которая ограничивает использование в коммерческом закрытом продукте. Вторая (чаще всего платная, иногда с дополнительной поддержкой и расширенными возможностями) распространяется под специальной коммерческой лицензией.
Важно, чтобы разработчики не перемешивали эти продукты вместе, иначе вирусная лицензия GPL нивелирует коммерческую версию или будет прямое нарушение уникальной лицензии.
Пользовательское соглашение
Хочу упомянуть еще об одном важном моменте в лицензировании – EULA (End-user license agreement) – это конечный договор, заключаемый с пользователем. Для больших и сложных продуктов в нем должны быть указаны все права пользователя, правообладателя и автора.
Это очень важная часть сделки, ведь именно здесь происходит «закрытие огромной матрёшки» всех лицензий, используемых в продукте. Здесь указаны обязательные упоминания ПО, библиотек в соответствии с их лицензиями, а также информация о правилах применения продукта. Здесь необходимо убедиться, использует ли приложение стороннее API и какие именно данные оно может передавать в другие источники.
Проверка лицензий
В большинстве случаев сверка лицензий производится при добавлении новых библиотек и частей в продукт, а также при обновлении существующих зависимостей, поскольку в новых версиях может быть изменена лицензия. Этот процесс можно частично автоматизировать с помощью Black Duck и схожих инструментов. Но результаты работы этих инструментов также необходимо перепроверять. К тому же, сверку они делают только по исходному коду и поиску паттернов (это часто приводит к сбоям и неправильной идентификации), а не медиафайлам.
Важно проверять совместимость с конечной лицензией и лицензиями другого ПО, используемого в продукте – не только импорт, от которого будет зависеть продукт, но и вложения в нем. У вновь добавляемого ПО могут быть свои зависимости. А если вы делегируете юридические вопросы поставщику приложения или консультанту, убедитесь в их опыте и будьте внимательны – все могут ошибаться, а отвечать вам.
Многие организации занимаются вопросами лицензирования и совместимости лицензий. Как пример можно посмотреть на сравнительную таблицу совместимостей от Open Source Automation Development Lab (OSADL), взятую из их презентации:
В нормальном разрешении схема доступна после регистрации на сайте организации. Копия – на imgur.
На лицензирование необходимо проверять не только исходный код, но и тексты, графику, музыку, звуки. Для медиаматериалов должно быть подтверждение использованной лицензии или отказ от прав (в идеале – в письменном виде и храниться вместе с артефактами проекта). Также при проверке важно подключать юристов и специалистов, которые понимают существующие проблемы, например, проблему патентов (computational idea patents).
Важно сверять все файлы, включенные в исходный код. Некоторые из них могут содержать сокращенную версию лицензии, так называемую «шапку», с указанием ссылок на развернутую версию.
Лицензии учитываются всегда, даже если просто вписаны как часть файла исходников. Кроме того, должна легко прослеживаться граница лицензирования – файлы, распространяемые под разными лицензиями, перемешивать нельзя. Однако есть лицензии, которые позволяют лицензировать не только файл целиком, но и отдельные функции или части. Особенно это важно для ПО и инструментов, которые распространяются под двойной лицензией из-за их большой схожести между собой.
При создании ПО чем раньше будет рассматриваться вопрос лицензирования, тем проще исправить ошибки, и тем меньше работы предстоит выполнить во время тестирования ПО. Это особенно важно учитывать при разделении коммерческого приложения и библиотек.
Понимание необходимости лицензирования и стандартов определения данного типа договоров позволяет правообладателям удерживать свои позиции, авторам становиться более заметными в сообществе, а пользователям видеть границу прав и обязательств.
Права любого человека заканчиваются там, где начинаются права другого. Видеть эту границу необходимо каждому, и лицензии – место, где они показаны. Сейчас любое приложение состоит из произведений множества авторов и правообладателей. Знать, как работать с такой сложной структурой, – обязанность любого разработчика. Сообщества сейчас упрощают эти взаимодействия, объединяя множество разных видов договоров в единые стандартные лицензии, работать с которыми становится значительно удобнее.
Надеюсь, статья открыла для вас что-то новое.
Больше кейсов и полезных материалов в наших каналах:
