Код свободный — используйте кто хотите? Лицензии опенсорсных зависимостей в проприетарной разработке

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

Сразу отмечу, что эта статья не является юридической консультацией; в рамках обзора я лишь обозначаю лицензии как менее и более «проблемные», оставляя окончательную оценку за вами.

Опенсорс: принципы и классификация

Когда вы используете платную библиотеку, очевидно, вы платите за определенные возможности и условия использования. Однако с открытым доступом к коду может возникнуть заблуждение, что этот код свободен для любого использования. Действительно, существует код в общественном достоянии, Public Domain, для его объявления могут применяться лицензии CC0 или The Unlicensed. Тем не менее очень немногие разработчики решаются выпустить свой код с такими условиями. Чаще всего открытый исходный код публикуется под специальными лицензиями, которые предоставляют правообладателям некоторый контроль над его применением, и, как минимум, требуют указания авторства оригинала при повторном использовании.

Опенсорсные лицензии можно условно разделить на две категории: пермиссивные (разрешительные) и копилефтные (вирусные). В основе разделения на эти категории лежит принцип свободы использования открытого кода, но в зависимости от категории понятие «свободы» трактуется по-разному.

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

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

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

Популярные виды опенсорсных лицензий и их применение

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

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

К числу популярных пермиссивных лицензий относятся:

• MIT
• Apache 2.0
  
• BSD 3-Clause
  
• BSD 2-Clause
  

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

По сравнению с пермиссивными лицензиями, нужно быть особенно внимательным с библиотеками под так называемыми «слабыми» копилефтными лицензиями. Как я упоминал ранее, копилефтные лицензии отличает требование использовать ту же лицензию для производного софта. «Слабые» же копилефтные лицензии при определенных условиях допускают, что производный софт может иметь другую лицензию. Например, таким условием для лицензии Microsoft Public License является отсутствие конфликтов лицензий других частей кода с лицензией исходного кода. Но это слишком общее условие, его можно применить для всех лицензий. Возможно, именно поэтому Ms-PL по некоторым классификациям относят к пермиссивным.

Библиотеки под лицензией Mozilla Public License 2.0 (MPL 2.0) можно использовать в рамках проприетарного проекта, но при любой модификации библиотеки измененная версия должна быть опубликована под MPL, что включает в себя обязательство открыть код с изменениями. Аналогичным образом это работает с зависимостями под лицензией Eclipse Public License 2.0, но также EPL требует защиты авторов зависимостей от судебных исков, связанных с вашим продуктом.

GNU Lesser General Public License (LGPLv3), несмотря на свою принадлежность к семейству лицензий GPL, известных своей вирусностью, относится к «слабым», поскольку специально была разработана для лицензирования библиотек (L ранее означало Library, сейчас L = Lesser). Библиотеки под данной лицензией совместимы с проприетарным кодом, но только при условии динамической линковки — статическая линковка обязывает применить лицензию LGPL ко всему слинкованному коду.

Может показаться, что рассматривать «сильные» копилефтные лицензии в рамках этой статьи нет никакого смысла, но это не так. Да, согласно общей рекомендации, зависимостей под лицензией GNU General Public License v3/v2 следует избегать для проприетарной разработки. Но есть любопытный нюанс: существует юридическая лазейка, известная под термином Application Service Provider loophole, позволяющая не открывать код под лицензиями GPLv3/GPLv2. Поскольку лицензия требует открывать код только при распространении софта, а облачные SaaS продукты формально не поставляются пользователю, следовательно, нет обязательств для открытия исходного кода. Однако такой подход требует тщательной оценки возможных рисков. Например, стоит учесть, что копилефтные лицензии могут быть несовместимы с лицензиями других зависимостей, которые могут потребоваться для проекта в будущем.

Важно также не путать лицензию GPL с GNU Affero General Public License (AGPL): усиленная версия GPL предусматривает ASP loophole и требует открытия кода даже при использовании в облачных сервисах.

Выводы

Небольшой опрос, проведенный в 2017 году, показал, что только в 64% рассматриваемых сценариев ответы программистов совпадают с ответами экспертов-юристов. Разработчик может ошибаться при использовании лицензий, но как же уберечь себя от рисков и не оказаться в ситуации Cisco?

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