Чому я повинен зберігати свою ліцензію на програмне забезпечення з відкритим кодом у корені?

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

Один юрист, з яким я говорив, припускає, що це спадщина епохи компакт-дисків, коли необхідно було включити повну ліцензію до справи коштовності.

Але сьогодні ми живемо у хмарну епоху. Чому я, наприклад, не можу просто розмістити повну ліцензію на своєму веб-сайті та включити заголовок + URL цієї ліцензії в заголовок моїх вихідних файлів?

Бонус: Якщо загальнозмінено, що встановлені ліцензії повинні залишатися недоторканими в корені, чому OSI FSF не затвердив ліцензію, на яку можна посилатися за URL-адресою, і що стримує когось від створення цієї ліцензії?

— саммбранд
джерело

Одне з питань, що спадає на думку, полягає в тому, що URL-адреси можуть змінюватися або скасовуватися.

— Аарон Куртжальс

"Інтернет не є всюдисущим", це було б найбільш очевидною причиною (навіть якщо хтось має Інтернет під час завантаження вашого програмного забезпечення, він може бути недоступний їм, коли вони хочуть розширити / змінити його).

— TZHX

Ви запитуєте, чому ЦІЛЬНА ЛІЦЕНЗІЯ ПОДАЄТЬСЯ ВКЛЮЧАТИ в корені або чому всю ліцензію потрібно включити до складу кореня?

— DougM

Тільки вказуючи, що ми, здається, говоримо тут про помилкову дихотомію; Ви запитуєте, чому ліцензія повинна бути в корені, і чому вона не може бути на сайті за адресою URL? Є третій варіант, про який ніхто не згадується; ліцензія постачається в комплекті з програмним забезпеченням, але в каталозі "docs" або щось інше, і коментар у заголовку файлів коду це відображає. Я погоджуюся з вагомими причинами, зважаючи на те, чому Ліцензію слід поставити в комплекті з програмним забезпеченням, але це не зупиняється в тому, щоб перейти в каталог документів.

— Джеймс

Причина, по якій вона майже завжди знаходиться в корені, так її легко знайти. Коли я завантажую ваш проект, я переглядаю корінь, і одне з перших речей, що я бачу, - це ліцензія. Просто так

— JohnL

Відповіді:

З питань поширених запитань про GPL (але порада стосується всіх ліцензій):

Чому GPL вимагає включення копії GPL з кожною копією програми?

Включення копії ліцензії до роботи є життєво важливим, щоб кожен, хто отримав копію програми, міг знати, які його права.

Це може бути спокусливо замість самої ліцензії включити URL-адресу, що посилається на ліцензію. Але ви не можете бути впевнені, що URL все ще буде дійсним через п'ять років чи десять років. Через двадцять років URL-адреси, як ми їх знаємо сьогодні, більше не можуть існувати.

Єдиний спосіб переконатися, що люди, які мають копії програми, надалі зможуть бачити ліцензію, незважаючи на всі зміни, що відбудуться в мережі, - це включити копію ліцензії до програми.

(наголос мій)

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

Ви можете відповісти на цю скаргу, сказавши: "Так що? Якщо URL-адреса знижується або недоступна, однозначного дескриптора на зразок" GNU GPL v3 "повинно бути достатньо. Повнотекстових копій GPL є багато; користувачі можуть шукати самі ліцензії ». Кілька проблем відразу виникають на увазі:

Це не узагальнює ліцензійні ідентифікатори, які є менш зрозумілими (на згадку приходить фраза "ліцензія BSD").
Це не добре узагальнює ліцензії, які є менш поширеними або налаштовані на замовлення (на думку: "GPL зі зв'язуючими винятками" на увазі: яке поєднання винятків?). Наскільки звичайною має бути ліцензія, перш ніж розумно очікувати, що користувач надійно знайде її по імені?
Це все ще вимагає від користувачів підключення до Інтернету, що може бути не так, навіть якщо вони мали з'єднання під час отримання програмного забезпечення. (І вони, можливо, не мали доступу до Інтернету, коли отримали програмне забезпечення: "вік компакт-дисків" ще не закінчився у багатьох частинах світу. Як додатковий випадок розглянемо національне населення, яке має широкий доступ до Інтернету, але цензує значну частину його .) Наслідком вільно-повторного розповсюдження програмного забезпечення є те, що одержувач може не отримувати копію вашого програмного забезпечення безпосередньо від вас або через канал розповсюдження, який ви спочатку очікували.

Один остаточний аргумент проти ліцензійних посилань відзначається коментарем MichaelT нижче: це може дозволити вам динамічно, заднім числом змінювати ліцензію. Це можна зробити навмисно, але це також можна зробити випадково, якщо ви змінили ліцензію між версіями програмного забезпечення, але використали одне і те ж ліцензійне посилання для обох версій, тим самим припинивши існування старої ліцензії. Такий перехід додасть труднощів людям, яким потрібно довести, що вони отримали свою стару копію за іншою ліцензією, ніж поточна версія.

То чому я повинен зберігати ліцензію в корені проекту?

Я не юрист, але я ніколи не бачив яких - або переконливі аргументи , що вам дійсно потрібно , щоб зберегти ліцензії в корені проекту. Навіть GPL, де зазначено, що ліцензія повинна супроводжувати кожну копію твору, мовчить про те, як вона повинна супроводжувати роботу. (Це може бути тому, що GPL може застосовуватися в непрограмному контексті, де поняття "кореневий каталог" не має сенсу.)

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

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

Підсумовуючи, використання кореня файлу - справа зручності та ясності. Я не бачив жодного юридично обов'язкового тексту ліцензії з відкритим кодом, який цього вимагає, і я не знаю жодної причини, чому це було б вимагати юридично. Ваша ліцензія повинна бути досить простою для виявлення одержувача; включаючи ліцензію в корені проекту достатньо, але не потрібно, щоб задовольнити цей критерій.

— апсилери
джерело

Розглянемо також можливість, що ви посилаєтесь на віддалений сайт для сайту.com.com/foo/license.txt, який ви отримали за ліцензією BSD, але з тих пір він отримав ліцензію під GPL v3 і ось що site.com/foo/license. txt тепер містить. Але завантажена вами версія має різні права.

Цю відповідь я відзначив правильною, оскільки, здається, викладається загальноприйнята та юридична мудрість щодо ліцензування ОСС. Однак , це мислення вважає мене трохи параноїчним для цього резервного, контрольованого версією світу, в якому ми живемо. Я не впевнений, що ризик канонічного підробки вмісту URL-адрес є більшим, ніж ризик того, що хтось випадково видалить частину ліцензія, що міститься в корені. І навіть якщо ризик більший, я скептично налаштований на те, що він настільки великий, що змусити розробників включати в своє програмне забезпечення повні ліцензії, на відміну від, скажімо, посилань на ліцензії, котрі розміщені зовні, у коментарях до коду.

— samthebrand

FYI, можливо, ознака майбутнього для ліцензування OSS: Creative Commons 4.0 дозволяє ліцензіатам посилатися на окрему сторінку, що включає інформацію про віднесення.

— samthebrand

Але сьогодні ми живемо у хмарну епоху. Чому я, наприклад, не можу просто розмістити повну ліцензію на своєму веб-сайті та включити заголовок + 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.

— Чадверсарі
джерело

Я думаю, що додаток є неповним або принаймні працює з припущенням, що ви вже включаєте копію ліцензії. З самого тексту 2.0 , коли розповсюджуєте роботу з ліцензією Apache:4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;

— apsillers

Немає вимоги, щоб вона була в корені проекту. Це просто найпоширеніше місце, і, таким чином, перше місце люди будуть шукати, щоб знайти ліцензію. З цього питання, навіть якщо це не було звичайним явищем, все-таки, найперше, люди будуть виглядати. Оскільки ліцензія існує для інформування, приховувати інформацію не має особливого сенсу.

Якщо ви ховаєте його за URL-адресою, немає абсолютної гарантії того, що ця URL-адреса буде завжди доступною. Якщо це файл у корені проекту, за визначенням він завжди буде доступний.

Коротше кажучи, це найефективніше, найбільш зручне для користувача місце.

— Брайан Оуклі
джерело

Корінь проекту - це перше місце, на яке можна було б виглядати: це верхівка дерева, корінь ієрархії папок. Вся документація верхнього рівня повинна надходити туди: readme, ліцензія тощо. Ці файли можуть спрямовувати читача копатися глибше в іншому місці проекту, але корінь - це перше місце, де я шукаю що-небудь.