Почему я должен держать мою лицензию на ПО с открытым исходным кодом в корне?

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

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

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

Бонус: если все согласны с тем, что установленные лицензии должны быть сохранены в корне, почему OSI FSF не одобрила лицензию, на которую вы можете ссылаться по URL, и что мешает кому-либо создать эту лицензию?

Из FAQ по GPL (но совет применим ко всем лицензиям):

Почему GPL требует включать копию GPL в каждую копию программы?

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

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

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

(акцент мой)

В тот момент, когда сайт, на котором у вас есть лицензия, выходит из строя или меняет свои URL-адреса, люди, имеющие копии вашего программного обеспечения, больше не могут проверять, какие права они могут безопасно использовать. Предположим даже, что вы можете каким-то образом гарантировать, что этот точный URL-адрес будет всегда онлайн: способность пользователей проверять законность использования вами вашего программного обеспечения по-прежнему зависит от возможности подключения к этому конкретному URL-адресу. Хотя это требование не может быть обременительным в вашем конкретном городе / стране / планете, оно может быть обременительным в других местах. Вы не должны навязывать это требование, особенно если обходной путь (включая полный текст лицензии) тривиален.

Вы можете ответить на эту жалобу, сказав: «И что? Если URL-адрес не работает или недоступен, достаточно однозначного дескриптора, такого как« GNU GPL v3 ». Полнотекстовых копий GPL предостаточно; пользователи могут искать лицензия сами ". Несколько проблем сразу приходят на ум:

1. Это не распространяется на идентификаторы лицензий, которые менее понятны (на ум приходит фраза «лицензия BSD»).

2. Это не распространяется на лицензии, которые являются менее распространенными или были настроены (на ум приходит «GPL с привязкой исключений»: какие связывания исключений?). Насколько распространенной должна быть лицензия, прежде чем разумно ожидать, что пользователь найдет ее надежно по имени?

3. Для этого по-прежнему требуется, чтобы у пользователей было подключение к Интернету, что может быть не так, даже если у них было подключение в момент получения программного обеспечения. (И у них, возможно, не было доступа к Интернету, когда они получили программное обеспечение: «эпоха компакт-дисков» еще не закончилась во многих частях мира. В качестве дополнительного случая рассмотрим национальные группы населения, которые имеют широко распространенный доступ в Интернет, но подвергают цензуре его значительную часть). .) Следствием свободно распространяемого программного обеспечения является то, что получатель может не получить копию вашего программного обеспечения непосредственно от вас или через канал распространения, который вы первоначально ожидали.

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

Так почему я должен хранить лицензию в корне проекта?

Я не юрист, но я никогда не видел каких - либо убедительные аргументы , что вам действительно нужно , чтобы сохранить лицензии в корне проекта. Даже GPL, в котором указано, что лицензия должна сопровождать каждую копию произведения, ничего не говорит о том, как оно должно сопровождать произведение. (Это может быть связано с тем, что GPL может применяться в не программных контекстах, где понятие «корневой каталог» не имеет смысла.)

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

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

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

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

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

Из самой лицензии Apache 2.0:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

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

Если вы прячете его за URL, нет абсолютной гарантии, что этот URL будет всегда доступен. Если это файл в корне проекта, по определению он всегда будет доступен.

Короче говоря, это самое эффективное и удобное место для размещения.