Лицензия GNU Affero General Public License версии 3.0, или сокращённо AGPLv3, имеет большое символическое значение. Это не самая строгая лицензия с авторским левым из когда-либо написанных, но она самая строгая благодаря своему названию и добросовестности старой школы. Это также одна из худших для чтения известных лицензий с открытым исходным кодом. Что отчасти объясняет, почему люди этого не делают и уходят, чувствуя себя совсем не уверенными в себе, когда пытаются это сделать.

Давайте прочитаем AGPLv3 вместе. Или, скорее, те её части, которые делают её именно AGPL, а не просто обычной старой GPL. Те части, которые пугают корпоративных юристов в Интернет-компаниях.

Разница

AGPLv3 – это всего лишь “исправленная” версия GPLv3. Правки добавляют одну “особенность”, но колоссальную.

Если вы скачаете официальные текстовые версии GPL и AGPL и сравните их, то обнаружите, что в основном изменения произошли в трёх местах:

• переименование с “GPL” на “AGPL”
• обновление преамбулы
• добавление нового абзаца в раздел 13

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

Остаётся раздел 13, который отправляет нас за правосудием.

Раздел 13

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

Мост GPL-AGPL

Второй абзац раздела 13 является своего рода особым “мостом” между GPLv3 и AGPLv3. Идея в том, чтобы убедиться, что разработчики могут смешивать код под этими лицензиями в проектах. Без этих пунктов в разделе 13 GPLv3 и AGPLv3, GPLv3 говорила бы, что вся программа должна быть под GPLv3, а AGPLv3 говорила бы, что должна быть под AGPLv3, создавая неразрешимый конфликт.

Было предложено использовать только одну лицензию, GPLv3, которая включала бы дополнительную функцию AGPL. Всё программное обеспечение, лицензируемое Фондом свободного программного обеспечения (FSF) по GPLv2, будет обновлено до GPLv3 с усиленной защитой от сетевого авторского лева. Но это не удалось, поэтому FSF пришлось иметь дело с возможностью и того, и другого.

Сетевое авторское лево

Суть в первом абзаце раздела 13. Он реализует то, что мы называем “сетевым авторским левом”, или авторское лево, которое затрагивает разработчиков сетевых сервисов (служб), таких как веб-приложения, а не только разработчиков распределённого программного обеспечения (ПО), такого как установленные приложения и клиентские скрипты.

Если у вас уже есть некоторое представление о том, как работает традиционное “строгое авторское лево” в GPLv2 или v3, это та часть AGPL, которую вам нужно прочитать. Просто попробуйте пройтись по ней хотя бы раз. Мы ещё несколько раз повторим это вместе.

Несмотря на любые другие положения настоящей Лицензии, если вы модифицируете Программу, ваша модифицированная версия должна явно предлагать всем пользователям, взаимодействующим с ней удалённо через компьютерную сеть (если ваша версия поддерживает такое взаимодействие), возможность получить соответствующий исходный код вашей версии, предоставив доступ к соответствующему исходному коду с сетевого сервера по адресу бесплатно, с помощью каких-либо стандартных или общепринятых средств, облегчающих копирование программного обеспечения. Этот Соответствующий Исходный код должен включать соответствующий исходный код для любого произведения, подпадающего под действие 3-й версии GNU General Public License, которая включена в соответствии со следующим пунктом.

В этом языке используется несколько терминов, определения которых содержатся в других разделах лицензии: “модификация”, “модифицированная версия”, “Соответствующий Исходный код” и “Программа”. Пока не ожидаем никаких сюрпризов. “Модифицировать” читаем естественно. Подумайте о “Программе” как о любом программном обеспечении, находящемся под лицензией AGPL. Замените “Соответствующий Исходный код” на “весь Исходный код” там, где вы его видите.

Давайте вернёмся к этому абзацу и немного разберём его, чтобы упростить понимание его структуры:

Несмотря на любые другие положения настоящей Лицензии,

если вы модифицируете Программу,

ваша модифицированная версия должна

явно предлагать всем пользователям,
взаимодействующим с ней удаленно
через компьютерную сеть

(если ваша версия поддерживает такое взаимодействие),

возможность получить Соответствующий [исходный код]
вашей версии,

предоставив доступ к Соответствующему [исходному коду]
с сетевого сервера по адресу бесплатно,
с помощью каких-либо стандартных или общепринятых средств,
облегчающих копирование программного обеспечения.

Этот [исходный код]
должен включать [исходный код]
любого произведения,
охватываемого условиями [GPLv3],
которое включено
в соответствии с [мостом GPL-AGPL].

В целом, то, что мы имеем здесь, – это одно очень многословное утверждение if. Если вы делаете то-то и то-то, вы должны делать то-то и то-то. Условие и следствие.

Это сложное условие. Вам нужно беспокоиться о пункте 1 раздела 13 только в том случае, если:

• "вы модифицируете Программу" и
• "ваша [модифицированная] версия поддерживает такое взаимодействие [удалённо через компьютерную сеть]"

Результатом является своего рода чек-лист:

• Вы должны сделать предложение.
• Вы должны сделать это “явно”.
• Вы должны сделать это "всем пользователям, взаимодействующим с [вашей модифицированной версией Программы] удалённо через компьютерную сеть".
• Ваше предложение должно касаться возможности получить Соответствующий Исходный код вашей изменённой версии.
• Соответствующий Исходный код, который вы предлагаете, должен содержать всё это:
• “с сетевого сервера”
• “бесплатно”
• с помощью каких-либо стандартных или общепринятых средств, облегчающих копирование программного обеспечения"
• Соответствующий Исходный код, который вы предлагаете, должен содержать исходные тексты для любого произведения под GPLv3, на которое распространяется мост GPL-AGPL.

Все ещё удивлены? Давайте копнём глубже.

Условие

Напомним, что это условие имело два аспекта: модификация программы и поддержка сетевого взаимодействия. Если вы думаете, что это был странный способ написать это, то вы были бы правы. Особенно, если мы немного узнаем о том, почему GPL была исправлена в первую очередь для создания AGPL. Что мы можем почерпнуть из преамбулы:

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

Лицензия GNU Affero General Public License разработана специально для того, чтобы гарантировать, что в таких случаях изменённый исходный код становится доступным сообществу. Она требует, чтобы оператор сетевого сервера предоставил исходный код запущенной на нём модифицированной версии пользователям этого сервера. Таким образом, публичное использование модифицированной версии на общедоступном сервере предоставляет общественности доступ к исходному коду модифицированной версии.

В двух словах: GPL – это лицензия с авторским левым, но GPL на самом деле не требует совместного использования и лицензирования исходного кода, если вы запускаете его для пользователей в качестве сетевой службы, а не предоставляете им для запуска на их собственных компьютерах. AGPL была написана для того, чтобы закрыть эту лазейку, часто называемую “ASP-лазейкой”, поскольку “ASP”, означающее “провайдер сервисного приложения”^[1], в то время было модным словом для того, что мы сейчас называем “SaaS”. Для тех, кто копается в блогах и архивах списков рассылки, вы также найдете упоминание о “проблеме Google”. Компании использовали ASP-лазейку и продолжают это делать. Если сложить всё это воедино: “AGPL был написан для того, чтобы решить проблему Google, закрыв ASP-лазейку”.

Из преамбулы мы узнаём, что AGPL предъявляет новые требования к операторам сетевых серверов. Но мы только что прочитали параграф о сетевом авторском лево в разделе 13, и в его условии не упоминалось о работе сетевого сервиса. Это срабатывает, когда мы модифицируем программу, и наша модифицированная версия поддерживает возможность использования для управления сетевой службой.

Наденьте свою хакерскую шляпу и атакуйте это условие. Как вы это обходите? Где это может функционировать не так, как ожидалось или предполагалось?

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

Обязанность доступа к исходному коду по лицензии AGPLv3

Рассуждения старшего юриста Red Hat об условиях лицензии AGPL v3: когда она требует раскрыть исходный код.

Denis DorotenkoDenis Dorotenko

Модификация

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

Люди, которые писали AGPL, предвидели это, и у них был очень хакерский ответ на этот вопрос: куайны, программы, которые печатают свой собственный исходный код. Хакерская культура любит куайны, как и любую форму рекурсии. Помимо веселья, блог-платформа, которая просто рассылает копии своего собственного исходного кода, была бы не очень полезна. Но ничто не мешает блог-платформе делать то, что она должна делать, — обслуживать записи в блоге и предлагать свой собственный исходный код.

Скажем, веб-сервер под AGPL, который мы находим в Интернете, поставляется с кодом, который в футере каждой веб-страницы добавляет ссылку на загрузку архивного файла (tar) с исходным кодом. И скажем, файл отвечает всем пунктам списка из пункта раздела 13 (про сетевое авторское лево). Допустим, мне не нравится предлагать посетителям исходный код моего блога. Я могу изменить программу, чтобы удалить код, который добавляет эти ссылки и обслуживает эти архивные файлы.

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

Есть ещё одна дыра.

Допустим, как пользователь, я случайно зашел на блог, и мне понравилось, как он выглядит и работает. Так получилось, что блог-платформа, на которой он работает, лицензирована по AGPL, но разработчики не включили в неё никаких куайн-функций. Блогер не модифицировал программу, и они не предлагали исходный код каким-либо другим способом. Полагаю, я мог бы попросить их сообщить мне, какую платформу они используют, чтобы я мог пойти и попытаться найти исходный код где-нибудь в другом месте. Может быть, я смог бы найти его правильную версию. А может, и нет.

По крайней мере, потенциально я могу в конечном итоге взаимодействовать с сетевым сервисом, для которого я не могу найти никакого доступного для разбора исходного кода. Это своего рода проблема свободы программного обеспечения, как её разъясняет FSF. Как пользователь, когда я использую ПО – работающее на моём компьютере или на чьём-либо другом – я должен получить исходный код и иметь возможность разобрать этот исходный код.

Есть также рычаг воздействия на неписаное предположение. Тот, кто изменяет программу, и тот, кто управляет изменённым сервисом, могут быть разными людьми. И никто не обязан принимать предложение о Соответствующем Исходном коде, требуемом в соответствии с разделом 13, или пресекать нарушения раздела 13 со стороны мейнтейнеров.

Если вы модифицируете блог-платформу под AGPL, чтобы добавить функцию, которая мне нравится, и делитесь со мной исходным кодом, но не предлагаете его никому другому, в AGPL нет ничего, что требовало бы от меня отправлять изменения обратно разработчику. Также, возможно, у меня нет никаких обязательств предоставлять исходный код, когда я запускаю программу для размещения своего собственного блога. Если мейнтейнер узнает об этом и придёт за мной, мой первый аргумент будет прост. Я не нарушал раздел 13. Я не вносил изменений в программу.

Вот как это написано.

Мейнтейнер может попытаться возразить, исходя из преамбулы, что смысл раздела 13 должен быть прочитан для достижения заявленных целей, независимо от того, написано это так или нет. Это долгая борьба, что судья или присяжные сочтут, что раздел 13 был понятен. Что вполне возможно, особенно учитывая, насколько более конкретна формулировка там, чем в преамбуле. В худшем случае вы в конечном итоге будете утверждать, что раздел 13 расплывчат, поэтому вы ссылаетесь на преамбулу, заставляете суд согласиться с этим и всё равно проиграете.

Усложнение

Достаточно ясно, чего хочет AGPL. Она хочет, чтобы люди, управляющие сетевыми службами, предоставляли пользователям копии исходного кода своих служб. Почему FSF просто не выступил прямо и не заявил об этом соответствующими юридическими терминами?

Несмотря на любые другие положения настоящей Лицензии, если вы используете Программу для работы с сетевым сервером, вы должны явно предлагать …

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

Первый – это вопрос политики. У FSF была и, вероятно, до сих пор остаётся аллергия на идею о том, что закон об авторском праве даёт владельцам авторских прав право устанавливать правила о том, как люди могут использовать ПО по лицензиям. Я бы сказал, что, по крайней мере, законодательство США решительно продвинулось в этом направлении, и у нас есть все основания ожидать, что оно пойдёт дальше, а не остановится и не развернётся вспять. Но AGPL написана более десяти лет назад, а FSF известен тем, что занимает довольно надуманную позицию лоббирования политики в области авторского права. Они любят говорить о мире, в котором свобода программного обеспечения гарантирована законом.

Существует также вопрос о внутренней доктрине FSF. Ключевой частью этого являются “четыре свободы”, которые составляют “свободу программного обеспечения”. Во-первых, “0-я свобода” – это “свобода запускать программу так, как вы пожелаете, для любых целей”.

Правовая политика и доктрина FSF пересекаются в вопросе “лицензия или контракт”. С самого начала FSF и его юристы утверждали, что единственным законом, который имеет значение для публикуемых лицензий, является закон об авторском праве – набор имущественных прав, налагаемых на общество для выплаты компенсации создателям. Не договорное право, а право частных, добровольных соглашений, которое во многих отношениях даёт больше власти и гибкости. В GPLv3 даже есть специальный 9-й раздел, в котором делается попытка обсудить и установить это. AGPLv3 дословно наследует этот раздел от GPLv3.

Тем не менее, в последние годы компании, выпускающие программное обеспечение по лицензиям FSF, подали несколько судебных исков о применении авторского лева против конкурентов или тех, кто, по их мнению, должен был быть их клиентами. В Соединенных Штатах эти компании подали в суд как за нарушение авторских прав, так и за нарушение условий контракта. И суды в этом контексте пришли к выводу, что GPL может быть применена в качестве контракта между разработчиком и пользователем способами, которые видятся широко применимыми. Опять же, 13 лет назад многих из этих исков, а также исков о лицензиях с некоммерческими и другими правилами, ещё не было.

Все это складывается в своего рода головоломку. Как нам реализовать это правило в отношении операторов серверов, не говоря при этом, что есть что-то, чего они не могут сделать, или что закон об авторском праве должен позволять разработчикам указывать, что должны сделать другие, или что наша лицензия – это контракт, который явно может это сделать? Не говоря прямо, что мы имеем в виду.
Закон об авторском праве в подавляющем большинстве случаев чётко дает владельцам авторских прав право вносить изменения в свои произведения и публиковать их. И это именно те полномочия по защите авторских прав, которые FSF использовал для внедрения несетевого авторского лева в лицензии GPL, начиная с её 1-й версии. Грубо говоря, в разделах 5 и 6 GPLv3 говорится, что если вы модифицируете программу и делитесь своей модифицированной версией в виде исходного кода или двоичного файла, вы также должны делиться исходным кодом и лицензировать его по лицензии GPL. В приблизительном переводе на язык авторского права, если вы “создаёте производное произведение” от ПО, защищенного авторским правом, и “распространяете копии”, то в качестве условия вашей лицензии на эти действия вы также должны распространять и лицензировать исходный код под лицензией GPL.

Судя по всему, что я видел, FSF изложил “четыре свободы” в печатном виде задолго до публикации первых лицензий GPL. И, естественно, FSF не рассматривал свои собственные лицензии с авторским левым как проблему с 0-й свободой. В конце концов, вы “запускали” программу не для создания несвободного программного обеспечения. Вы модифицировали программное обеспечение, чтобы создать несвободное ПО. Распространение (2-я свобода) и распространение модифицированных версий (3-я свобода) были особыми случаями, поскольку лицензии на “свободное программное обеспечение” могли накладывать на них определённые условия. Условия, требующие совместного использования и лицензирования полного исходного кода в качестве свободного ПО.

Таким образом, по разным причинам FSF мог бы по-другому подойти к задаче внедрения AGPL: как нам преобразовать “управление сетевым сервисом” с точки зрения 3-й свободы — внесения изменений и совместного использования исходного кода — вместо 0й-й свободы — использования ПО? С технической точки зрения, сделайте совместное использование исходного кода чем-то таким, что программа делает при вашем использовании. С юридической точки зрения, предоставление исходного кода через программу или иным образом является условием права на внесение изменений в программу. Или, в идеале, и то, и другое.

Если вам кажется, что это сильно усложняет задачу, если вы думаете, что это объясняет, почему абзац из двух предложений, скрытый в разделе 13, было так трудно понять, то вы не одиноки.

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

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

Представьте, что чувствуют люди, которые не разбираются в программном обеспечении, юриспруденции, составлении юридических документов, архитектуре программного обеспечения, культуре хакеров или самозваных “философских” размышлениях некоего Ричарда М. Столлмана. С таким же успехом нетрезвые инопланетяне могли передать это из космоса в качестве своего рода розыгрыша.

Ларри Розен, юрист организации Open Source Initiative в своё время, указывал на чрезмерное усложнение, в частности, с помощью своей лицензии Open Software License, последней версией которой является версия 3.0. Чтобы получить дополнительные баллы, внесите раздел 5 из OSL 3.0 в свой список для прочтения после того, как мы закончим с AGPL. Она позволяет достичь иных результатов и иным способом, чем AGPL, устраняя при этом те же “ASP- лазейки” и “проблемы Google”.

Чек-лист

Если вас подцепило условие, указанное в пункте "Сетевое авторское лево" раздела 13, вы должны выполнить его требования. Как уже упоминалось, вы можете воспринимать это как чек-лист. Ещё короче, чем ранее:

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

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

В приведенном выше “чек-листе” AGPL не упоминается. Там даже не упоминается лицензирование. Но это не такая уж большая и уродливая ошибка. Для выполнения этой работы раздел 13 опирается на некоторые другие, глобальные положения лицензии.

В частности, раздел 13 основан на разделе 5, который является частью стандарта авторского лева GPL. Очень кратко, в разделе 5 излагаются правила совместного использования или “передачи” исходного кода с изменениями. Это еще один чек-лист. Среди задач:

б) Произведение должно содержать заметные уведомления о том, что оно выпущено в соответствии с настоящей Лицензией и любыми условиями, добавленными в соответствии с разделом 7. …

в) Вы должны лицензировать всё произведение в целом в соответствии с настоящей Лицензией любому, кто получит его копию. …

Вот оно. В разделе 13 говорится, что когда вы изменяете веб-сервис, вы должны предложить поделиться изменённым исходным кодом. В разделе 5 говорится, что когда вы делитесь изменённым исходным кодом, вы должны лицензировать его в соответствии с AGPL. Люди упускают эту связь, и, честно говоря, её легко не заметить. Особенно программистам, и особенно тем, кто не являются программистами на C++, которые привыкли к тому, что подпрограммы запускаются при их вызове, а в остальном сидят тихо.

Продолжаем поиск по недрам

Суть AGPLv3 заключается в добавлении сетевого авторского лева к авторскому леву GPLv3, но это далеко не всё, что там есть.

AGPL унаследовала от GPL множество терминов, определений, причудливую редакцию и необычное поведение. Честно говоря, хороших вопросов о GPLv3 и AGPLv3 гораздо больше, чем хороших ответов, даже если исключить все те, которые имеют значение только для любителей авторского права, и принять за чистую монету все комментарии, опубликованные FSF в Интернете.

Некоторые из актуальных вопросов действительно связаны с законодательством об авторском праве. Например, определение “модифицировать” и, как следствие, “модифицированная версия” на самом деле просто указывает на объём полномочий, которые закон предоставляет владельцам авторских прав:

“Модифицировать” произведение означает копировать или адаптировать всё произведение или его часть способом, требующим разрешения авторского права, за исключением создания точной копии. Получившееся в результате произведение называется “модифицированной версией” более раннего произведения или произведением, “основанным” на более раннем произведении.

В лицензии не указано “производное произведение”, которое является термином, который есть в законе США об авторском праве. Но в нём используется слово “на основе”, которое используется в юридическом определении “производного произведения”. Означает ли “изменённая версия” просто “производное произведение”? Если да, то что это значит? И, во-первых, на что распространяется авторское право? Только на новый и оригинальный код? Его API?

Это включает в себя юридический анализ, а юридический анализ – это не просто поиск по делу, о котором вам говорит судья. В США суды в основном рассматривают конфликты до тех пор, пока они не будут урегулированы. Они не выдают ответы на юридические вопросы, как вендоматы.

Аналогичная история с “Соответствующим Исходным кодом”. Если вы создаете более крупный веб-сервис, объединяя сетевые службы, которые вызывают друг друга по HTTP-протоколу, а не библиотеки или фрагменты кода, связанные или вставленные вместе, включает ли “Соответствующий Исходный код” исходный код для этих других служб? Что, если каждая служба контейнеризирована, инкапсулирована в свою собственную операционную систему? Считаются ли эти операционные системы “Системными библиотеками” или “общедоступными программами”, которые защищают код приложения, которое они запускают?

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

Частые вопросы о Linux и лицензиях GPL

Разбираем правовые вопросы о Linux и лицензиях семейства GNU General Public License (GPL).

Denis DorotenkoDenis Dorotenko