Что aбсолютно каждый разработчик должен знать о лицензиях и Copyright

Привет, Хабр!

В Axelix мы в последнее время начали получать contribution-ы извне. И как по приватным обсуждениям, так и по GitHub я могу сделать вывод, что у очень многих людей есть довольно серьёзное непонимание того, что означает та или иная лицензия, что вообще такое “Open Source” и даже что такое Copyright.

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

Позже я, возможно, ещё напишу про CLA, Open Core и про то, как AI Agents и AI в целом вписываются в эту картину. Так что, если вам интересно, дайте знать 🙂

Прежде чем мы начнём: я не юрист, и я не советую вам выбирать ту или иную лицензию, или подход. Я всего лишь Software Engineer, который писал много кода под разными лицензиями, в том числе проприетарными и Open Source.

Давайте я попробую объяснить, как вообще вся юридическая часть вокруг софта устроена, шаг за шагом.

Просто Небольшой Web Server

Допустим, вы типичный JavaScript разработчик, и вот в воскресенье вечером вы решили написать свой собственный JavaScript Web Server — потому что, а почему бы и нет, правда? И, возможно, позже вы задумаетесь о том, чтобы сделать enterprise distribution этого веб-сервера и продавать его. Может быть, вы даже сможете зарабатывать на жизнь, создавая открытый софт. Было бы здорово!

Для простоты давайте пока предположим, что этот код вы написали в одиночку, вечерами. Не для работодателя и не в рабочее время.

Итак, согласно Berne Convention, в большинстве стран мира (где-то в 180 или около того) самим фактом написания этого Web Server вы уже становитесь обладателем Copyright на данный софт. Иными словами — вы теперь “Copyright Holder” (Владелец Copyright). Давайте на минуту об этом поговорим, потому что это важно.

Copyright. Краеугольный Камень.

С момента, когда вы создали исходный код, примерно 180 стран мира признают, что вы являетесь “Copyright Holder” этого произведения.

Copyright — это одна из ветвей “Intellectual Property” (или просто “IP”). Он возникает у вас автоматически, потому что вы создали исходный код. Есть и другие аспекты IP, например “Patents” (патенты). И вот “Copyright” особенно интересен в том смысле, что это та ветвь IP, которая, в отличие от условного “Software Patent”, на который нужно отдельно подаваться, возникает у вас автоматически, как только вы написали этот JavaScript Web Server.

Но что именно (вот прямо на самом деле) такое Copyright? Говоря простыми словами, это набор прав, которыми обладаете ТОЛЬКО ВЫ как Copyright Holder. И вот эти права:

1. Право на Воспроизведение и Копирование

Это означает, что ТОЛЬКО ВЫ, как Copyright Holder, имеете юридическое право использовать копии этого кода в программе. Всем остальным по умолчанию нельзя использовать копии вашего кода в своих программах. Возникает вопрос — а что такое “использовать копии”? Обычно имеется в виду вот прямо физический акт дублирования, скачивания или copy-paste вашего кода. Юридически также признаётся, что, например, включение вашего Web Server как библиотеки — это тоже акт копирования, то есть реализация именно этого права, которого, ещё раз, у других по умолчанию нет.

2. Право на Создание Derivative Works.

Только вы имеете право изменять, адаптировать или развивать свой софт. Никто, кроме нас! вас. Например, если кто-то возьмёт ваш исходный код, переименует переменные, поправит пару багов, добавит две новые фичи и назовёт это “Web Server Васи Пупкина” — это создание дериватива. Несмотря на то, что это не прямая копия один в один, это всё равно нарушение copyright.

3. Право на Распространение

Только у вас есть исключительное право делать этот код доступным публике. Например, именно вы определяете, как этот софт будет распространяться: будет ли он продаваться, и если да, то в каком виде и так далее.

4. Право на Публичный Показ или “Исполнение”

Допустим, у вашего Web Server есть UI. У Axelix, например, тоже есть визуальный user interface для людей. И право на публичный показ означает, что, по умолчанию, без разрешения (например, данного через лицензию, об этом ниже), никто не может, скажем, записывать коммерческие видео с использованием UI вашего Web Server-а.

Но как Software Engineer, который просто хочет сделать Open Source проект и может даже заработать что-то на нём, вы также хотите, чтобы люди вашим софтом пользовались. В случае с Axelix OSS, например, вы можете легально использовать его прямо как есть на GitHub в коммерческих целях без каких-либо обязательств.

По сути, часть своих прав под какими-то условиями Вы готовы передать другим. Как это достигается? Здесь нам нужно поговорить про лицензирование.

Лицензирование Софта

Помните: именно вы, как Copyright Holder вашего JavaScript Web Server, определяете точные условия, на которых другие люди смогут использовать ваш софт.

У этого набора условий есть название — лицензия.

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

Существует целая куча известных лицензий: Apache License, MIT, BSD, GPL, SSPL и так далее.

Итак, если вы хотите, чтобы другие люди “использовали” ваш Web Server (например, включали его как библиотеку в свой продукт или ставили на Linux machine), вам нужно решить, под какой лицензией вы свой софт будете распространять.

Может быть так, что людям придётся заплатить вам деньги, чтобы получить определённый набор условий на использование кода. А может быть так, что лицензия позволит использовать ваш софт бесплатно. Например, прямо сейчас Axelix распространяется под LGPL, и эта лицензия допускает свободное использование, в том числе и в коммерческих целях.

Open Source Лицензия

Очень многие люди думают, что если они просто выложили код на GitHub — значит, код уже Open Source. Это не так. При этом ядро Axelix является Open Source, и он тоже лежит на GitHub. Тогда возникает вопрос — а что именно делает проект “Open Source”?

На это есть вполне конкретный ответ. Существует Open Source Initiative (OSI), которая сформулировала определение “Open Source Software”. И это определение подразумевает, что для того, чтобы софт считался “Open Source”, он должен в обязательном порядке удовлетворять определённому набору критериев. На практике стандартный способ эти критерии соблюсти — выпустить софт под одной из лицензий, одобренных OSI. Axelix распространяется под LGPL, LGPL в этом списке есть, следовательно, Axelix можно считать “Open Source”.

В общем, Вы не можете просто сделать код публичным и заявить, что это “Open Source” — это не так. Вы явно не дали никому никакие права на то, чтобы что-либо с этим кодом делать, а значит, хотя код и публичен, он не “Open Source”. Знайте об этой разнице, пожалуйста.

Пару Слов Про Copyleft

Open Source лицензии обычно делятся на copyleft и non-copyleft. Copyleft — это специальная юридическая техника, применяемая в лицензировании, которая предназначена для того, чтобы определённые права “переезжали” и в деривативы. Сейчас поясню.

Это означает, что если продукт A создаёт и распространяет дериватив продукта B, а продукт B является copyleft-библиотекой, то copyleft-обязательства могут (вот тут важен тип copyleft лицензии) распространиться и на соответствующие части продукта A, которые используют дериватив. Точный объём этого эффекта зависит от конкретной лицензии и от того, как именно продукты A и B между собой комбинируются.

Copyleft-лицензии делятся на weak copyleft и strong copyleft.

Strong copyleft-лицензии жёстко реализуют саму идею copyleft, то есть если проект создаёт и распространяет дериватив с участием strongly-copyleft библиотеки, то соответствующая “часть проекта” должна быть выпущена для потребителей под этой же самой лицензией. Именно поэтому strong-copyleft когда-то называли “viral” лицензией — как вирус, она распространяется там, где юридические условия copyleft действительно срабатывают. Например, Grafana лицензируется под AGPL, а это strong-copyleft лицензия.

Weak copyleft-лицензии, с другой стороны, хотя и содержат идею распространения лицензии на деривативы, всё же имеют определённые исключения из этих правил.

Например, как уже было сказано, Axelix сейчас лицензируется под LGPL, а это weak copyleft лицензия. Она “слабая”, потому что если вы просто хотите использовать софт, не создавая из него дериватив, — вы можете это делать совершенно спокойно, и никаких проблем с этим нет. Подключить Axelix Spring Boot starter, настроить его, установить Axelix Master из Helm Chart или Docker — ничего страшного, ваш код никому ничего не должен.

А когда же тогда наступает этот самый эффект copyelft в LGPL, например?

Вот если большая компания решит форкнуть Axelix, а потом продавать этот модифицированный форк среди клиентов, то на этот форк уже повлияет copyleft (т.к. компания создала и распространяет дериватив), и этот форк придётся выпускать под LGPL. Заметьте, однако, что форк на GitHub для контрибьюшена — это абсолютно нормально, потому что форк тоже лицензирован под LGPL.

Другой популярный проект, который лицензирован под LGPL, — это Sonar Qube, например. Думаю, у большинства из вас он так или иначе есть как часть Quality Gate.

“Enterprise” Игра

Давайте вернёмся к вашему JavaScript Web Server.

Вы, как Copyright Holder этого JavaScript Web Server, приняли решение выпустить его публично под AGPL лицензией — strong-copyleft.

Идёт время, ваш продукт постепенно становится всё популярнее. И где-то на заднем плане у вас сидит мысль о том, что однажды вы сможете зарабатывать на жизнь, монетизируя этот софт, при этом всё ещё оставаясь приверженным Open Source.

И вот в четверг вечером, в 19:37 UTC+3, вы получаете письмо от крупного облачного провайдера. И этот провайдер пишет вам следующее:

“Hey, we really like your JavaScript Web Server. And we want to allow it to be able to sell it in the SaaS manner in our cloud. But we do not want our internal cloud infrastructure to be released to our customers under AGPL”

Одно из “условий” AGPL состоит в том, что если кто-то модифицирует софт под AGPL и позволит пользователям взаимодействовать с этой модифицированной версией по сети, а именно это SaaS часто и подразумевает, то эти “кто-то” должны предоставить своим пользователям исходный код этой модифицированной версии под AGPL. Это прямое следствие copyleft.

При этом это не означает автоматически, что SaaS-провайдер должен будет раскрыть вообще всю свою внутреннюю облачную инфраструктуру клиентам под AGPL. Но это вполне может означать, что ему придётся раскрыть исходный код модифицированного AGPL софта, а возможно, и некоторых плотно интегрированных covered parts вокруг него. Для крупных компаний это, как правило, очень серьёзный стоп-фактор.

Поскольку вы и раньше планировали как-то монетизировать свой Web Server, вы начинаете думать, как вообще можно решить эту проблему. Итак, что вы делаете? Как зарабатывать на своём продукте и при этом оставаться приверженным Open Source-у?

Вы начинаете изучать тему. И вот какие решения вы находите.

Решение 1. Двойное Лицензирование

Некоторые продукты идут по пути “dual-licensed”. Что это значит?

Это означает, что существует несколько наборов условий, на которых люди могут использовать ваш софт, не только AGPL в вашем случае. Говоря по-простому, двойное лицензирование означает, что пользователи могут “использовать” этот софт либо по лицензии A, либо по лицензии B. Заметьте, что часто один из этих наборов условий не является бесплатным, и за него нужно платить.

Именно так, например, Oracle поступает с MySQL. MySQL — это известный Open Source проект с моделью двойного лицензирования. Обычно он предоставляется бесплатно под GPL. Но если компаниям не нравятся или не подходят условия GPL, они могут купить у Oracle проприетарную лицензию, в которой этих ограничений (в частности, “strong copyleft”) уже нет.

Решение 2. Source Available Лицензии

Это другой подход. Вы можете адоптировать, это так называемый “re-licensing” (перелицензирование) вашего Web Server.

Перелицензирование фактически означает смену лицензии (то есть набора условий, на которых вы распространяете софт) с одной на другую, например переход с AGPL на MIT, BSD или что угодно ещё.

Таким образом, ещё один доступный вам вариант — перевыпустить проект под какой-то другой лицензией. И в идеале, предположим, если вы хотите зарабатывать, создавая open source, эта лицензия должна по-прежнему держать код “открытым”, чтобы любой человек всё так же мог его читать, отправлять Pull Request-ы и так далее. Но при этом такая лицензия должна запрещать только определённые коммерческие способы использования вашего Web Server, например предлагать его как конкурирующий Cloud Service.

Именно это и представляют собой “Source Available” (SA) лицензии. Категория SA лицензий, говоря простыми словами, означает, что исходный код публичен — любой может его видеть, но есть какие-то ограничения на то, как именно этот софт может использоваться. То есть source как бы “available”, но обычно есть небольшой нюанс. И этот нюанс обычно состоит в запрете на определённое коммерческое использование вашего софта при некоторых условиях.

Это, например, то, что Moderne сделали с частью экосистемы OpenRewrite. Ядро OpenRewrite осталось под Apache License V2, но некоторые recipe modules были переведены на определённые Source Available или проприетарные условия. И сделали они это, по их объяснению, как ответ на “недружеские” действия AWS.

Note: Теоретически может быть и так, что “Source Available” лицензия вообще запрещает любое коммерческое использование, хотя это, конечно, бывает редко.

Довольно много популярных проектов в какой-то момент выбрали те или иные варианты “Source Available” лицензий, например MongoDB, Redis, Sentry и так далее.

Пару Слов Про BSL Лицензии

Source Available лицензии вообще довольно сильно отличаются друг от друга, но среди них есть одна группа, которая довольно распространена и становится всё популярнее — Business Source License (или BSL).

Думаю, про них тоже стоит сказать пару слов. BSL лицензии это типичные Source Available лицензии, у которых есть одна очень важная черта: спустя определённый период времени они автоматически превращаются в конкретную “Open Source” лицензию (MIT, ALV2, GPL и т.д.).

В нашем случае, например, вы выпустили JavaScript Web Server версию 1.0.0 под BSL. И в BSL написано, что через 3 года после релиза, софт становится лицензированным под ALV2. Это означает, что через 3 года версия 1.0.0 автоматически “переключится” на ALV2.

Именно поэтому BSL лицензии часто называют “springing” лицензиями, потому что через некоторое время они как бы “срабатывают” автоматически.

Решение 3. Комбинация

В некоторых сложных случаях возможна и комбинация двойного лицензирования и SA-лицензирования. Например, мы уже вскользь упоминали Redis. На момент написания этой статьи Redis не просто dual-licensed, а triple-licensed (то есть доступен под 3 разными лицензиями). Две из этих трёх лицензий являются Source Available, а третья — AGPL.

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

Заключение

Я планирую написать ещё пару статей про важность и роль CLA (Contributor License Agreement) и DCO (Developer Certificate of Origin), про Open Core, а также про то, как AI повлиял на лицензирование в целом. Пока что мы с вами предполагали, что вы — единственный Copyright Holder. Но во многих крупных Open Source проектах это не так.

В больших Open Source проектах есть множество людей, которые контрибьютят регулярно или время от времени, ещё и используя AI Агентов. Даже у Axelix уже есть несколько внешних контрибьюторов (кстати, мы им очень рады!).

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

Спасибо!