Рассказать о лицензии через ссылку на неё

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

Не существовало никакой единой всемирной сети документов, которая указывала бы на то, когда всё это было “решено”. Не было Интернета для массового потребителя. Теперь это есть. Теперь ссылаться на условия лицензии имеет такой же смысл, как и копировать их, с учетом изменения количества ссылок и стабильности постоянных ссылок. Иногда в этом больше смысла.

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

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

Лицензия MIT гласит:

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

“Включить в копию” звучит не слишком великодушно. Если бы вы спросили меня, юриста, что требует от вас лицензия MIT для вашего JavaScript-приложению, и я сказал бы вам “включить лицензию в программное обеспечение”, то подозреваю, вы бы услышали это как “скопировать и вставить её как комментарий в хэдер”. Это, пожалуй, лучшее, что у нас есть на данный момент.

Теперь лицензии BSD:

1. При распространении исходного кода должно сохраняться вышеуказанное уведомление об авторских правах, этот список условий и нижеследующий отказ от ответственности.

Это, по-видимому, предполагает, что лицензия изначально указана в виде комментария. Но не, скажем, в файле LICENSE в другом месте репозитория. Но вывод о том, что размещение лицензии в файлах NOTICE или README, а не в исходном коде, не является соблюдением условий лицензии о её "сохранении" видится уж слишком формальным. В данном контексте цель, очевидно, заключается в том, чтобы копии программного обеспечения, исходные или двоичные, должны сопровождаться условиями лицензии.

2. При распространении в двоичной форме в документации и/или других материалах, прилагаемых к дистрибутиву, должны быть воспроизведены вышеуказанное уведомление об авторских правах, этот список условий и нижеследующий отказ от ответственности.

Это, по-видимому, предполагает материальное, то есть осязаемое, распространение. Опять же, это имело смысл, когда дистрибутивы ПО можно было отправлять по почте в упаковках или футлярах для драгоценностей. Что касается отсылки [к тексту лицензии], а не копирования, то нам пришлось бы очень свободно читать “воспроизводить”, что означает что угодно, кроме “копировать”. Составители [текстов лицензий] просто не предвидели этого вопроса.

Ну, а как насчёт гораздо более новой лицензии? Традиция торжествует. Возьмем лицензию Apache 2.0:

Вы должны предоставить любым другим получателям Произведения или производных работ копию этой Лицензии

“Копию”, а не “ссылку на”. Похоже, это плохие новости. И это ещё не всё:

Если Произведение включает в себя текстовый файл “NOTICE” как часть своего распространения, то любые Производные произведения, которые Вы распространяете, должны содержать читаемую копию уведомлений об авторстве, содержащихся в таком файле "NOTICE", за исключением тех уведомлений, которые не относятся к какой-либо части Производных произведений, по крайней мере, размещается в одном из следующих разделов: в текстовом файле "NOTICE", распространяемом как часть Производных произведений; в форме Исходного кода или документации, если они предоставляются вместе с Производными произведениями; или в виде изображения, созданного Производными произведениями, если и где обычно появились бы такие уведомления третьих лиц.

В Apache 2.0 фиксированный текст лицензионных условий отделён от авторских прав и других уведомлений, относящихся к конкретному проекту. Но это требует копии и того, и другого.

Наконец, GPLv2 говорит, среди многого-многого другого:

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

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

Достаточно? Теперь сравните Blue Oak 1.0.0:

Вы должны убедиться, что каждый, кто получит от вас копию любой части этого программного обеспечения, с изменениями или без изменений, также получит текст этой лицензии или ссылку на нее https://blueoakcouncil.org/license/1.0.0.

Blue Oak признаёт, что ссылки на условия лицензии – обычное дело. Это специально позволяется делать. Это можно сделать с помощью постоянной ссылки, поскольку это позволяет избежать какого-либо уведомления об авторских правах или другого текста, который лицензиары должны заполнять или подготовить. Это превращает лицензию в фиксированный, стандартизированный текст, подобный Apache 2.0. Но, в отличие от Apache 2.0, здесь нет файла NOTICE или другого механизма для специальных уведомлений об авторских правах. В них нет необходимости.

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

Так что же делать?

На практике зависит от контекста. Может ли высокомотивированный лицензиар программного обеспечения утверждать, что распространение его JavaScript без указания лицензионных условий в комментарии к коду нарушает условия его условий MIT или BSD, отменяя действие лицензии, что приводит к нарушению договора или авторских прав? Я думаю, мог бы. Коллеги, которых я уважаю, разделяют эту точку зрения и опасаются возможных злоупотреблений.

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

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

Существует старый юридический козырь, позволяющий избежать судебного разбирательства, простые судьи используют его на латыни: “de minimis non curat lex” – закон не заботится о мелочах. Разница между комментарием к лицензии с URL-адресом и комментарием к лицензии с текстом лицензии и уведомлением об авторских правах кажется мне чертовски незначительной. Но вряд ли будет весело гадать и ждать, когда судья действительно напишет это в решении о закрытии дела, по которому вы являетесь ответчиком.

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

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