Часті запитання

Ви читаєте неофіційний переклад оригінальної сторінки.

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

Загальне

Мені не вистачає часу. Чи можете ви дати мені якнайшвидші підсумки?

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

1. Виберіть і надайте ліцензії

Оберіть ліцензію Free Software для вашого проєкту. Знайдіть ідентифікатор SPDX вашої ліцензії в списку ліцензії SPDX. Завантажте текст ліцензії на вашу ліцензію з репозиторію license-list-data і покладіть її у каталог LICENSES/.

2. Додайте відомості про авторські права та ліцензування до кожного файлу

Потім для всіх файлів змініть заголовок, щоб він містив таке:

# SPDX-FileCopyrightText: [year] [copyright holder] <[email address]>
#
# SPDX-License-Identifier: [identifier]

3. Підтвердьте відповідність повторного використання

Використовуйте засіб REUSE щоб автоматизувати деякі з цих кроків, і перевірити, чи ви зробили все правильно.

Що таке SPDX?

SPDX розшифровується як Software Package Data Exchange. Це проєкт Linux Foundation і основа, на якій побудовано REUSE. SPDX визначає стандартизований спосіб обміну інформацією про авторські права та ліцензування між проєктами та людьми. Найважливішим для REUSE, що SPDX підтримує Список ліцензій SPDX, який визначає стандартизовані ідентифікатори для багатьох ліцензій.

Авторське право

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

Зазвичай автор є власником авторських прав, але часто авторські права передаються роботодавцю автора.

Creative Commons надає кращу та довшу відповідь у своїх Частих запитаннях.

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

Загалом, ми рекомендуємо використовувати SPDX-FileCopyrightText: [рік] [власник авторських прав] <[контактна адреса]>. Ви можете опустити всі елементи, окрім власника авторських прав, який завжди має бути включений. Однак ми рекомендуємо включати всі елементи.

Специфікація включає розділ із точним форматом повідомлення про авторські права. Дивіться специфікацію та наступне запитання.

Специфікація містить такі повідомлення про авторські права які вважаються чинними:

SPDX-FileCopyrightText: 2019 Джейн Доу <jane@example.com>
SPDX-FileCopyrightText: © 2019 Джейн Доу <john@example.com>
SPDX-FileCopyrightText: Учасники проєкту Приклад <https://project.example.com>
SPDX-FileCopyrightText: 2023 Аліса Хак та (інші) учасники Проєкту X <https://git.example.com/alicehack/projectx/CONTRIBUTORS.md>
SPDX-SnippetCopyrightText: (C) Приклад кооперативу <info@coop.example.com>
© Приклад Корпорації <https://corp.example.com>
Авторське право 2016, 2018-2019 Джо Будь-хто
Авторське право (c) Аліса, деякі права захищені

З них перші два — найрекомендованіші. Інші існують насамперед для сумісності з наявними конвенціями.

Загалом є чотири варіанти на вибір:

  1. Рік першої публікації.
  2. Рік останньої публікації.
  3. Всі роки публікації, або діапазоном (наприклад, 2017-2019), або окремими записами (наприклад, 2017, 2018, 2019).
  4. Не включати жодного року.

Який варіант ви оберете, зрештою, вирішувати вам. [У цій статті(https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code) наведено вагомі аргументи на користь використання року першої публікації файлу.

Які файли захищені авторським правом?

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

Однак є деякі крайні випадки. Наприклад, програма print("Hello, REUSE!"), ймовірно, не відповідає критерію оригінальності. Аналогічно, файли даних і конфігураційні файли також можуть не відповідати цьому порогу. Про ці файли перегляньте це питання.

У цих ресурсах ми підтримуємо різницю між власником авторських прав і автором. Автор (також відомий як творець) — це людина, яка сіла і створила щось. Подумайте про автора як про програміста, письменника або художника.

Правовласником є особа, яка має виключні права на цей твір. Часто автор і власник авторських прав — це одна особа. Однак, якщо автору за створення твору платить роботодавець, тоді цей роботодавець часто є власником авторських прав.

Майте на увазі, що в деяких юрисдикціях слово «автор» часто вживається синонімом «власник авторських прав». В інших юрисдикціях автори зберігають деякі права на свою роботу, навіть якщо вони не є правовласниками.

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

Ліцензування

Що таке ліцензія?

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

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

Що таке ліцензія з копілефтом? Дозвільна ліцензія?

Існують дві широкі категорії ліцензій вільного програмного забезпечення: ліцензії з copyleft та дозвільні ліцензії.

Ліцензія з копілефтом дає вам право використовувати, вивчати, поширювати та вдосконалювати програмне забезпечення за однієї суворої умови. Якщо ви вносите будь-які зміни до програми та ділитеся своєю версією програми з кимось іншим, ви повинні ділитися своїми змінами під тією ж ліцензією, що й оригінал. Відомою ліцензією з copyleft є GNU General Public License версія 3.

Дозвільна ліцензія надає вам ті самі права на вільне програмне забезпечення, але не містить цієї умови. Хтось може взяти ліцензоване програмне забезпечення, внести до нього зміни і зберегти змінену версію як власність. Відомою дозвільною ліцензією є Ліцензія Apache версії 2.

Яку ліцензію слід обрати?

Завжди вибирайте ліцензію на вільне програмне забезпечення, тобто ліцензію, яка дає одержувачу свободу використовувати, вивчати, поширювати та вдосконалювати програмне забезпечення. Крім того, ліцензія, яку ви обираєте, залежить від вас. Якщо ви робите внесок в наявний проєкт, ви повинні випускати свої зміни під тією ж ліцензією, що і проєкт. В іншому випадку Free Software Foundation, choosealicense.com та joinup.eu мають кілька хороших рекомендацій. Зауважте, що ці ресурси наголошують на різних цінностях і мають власну упередженість.

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

Що таке ліцензійні винятки та що з ними робити?

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

Винятки трактуються майже однаково з ліцензіями. Щоб поєднати ліцензію з винятком, потрібно позначити файл таким тегом: SPDX-License-Identifier: GPL-3.0-or-later WITH GCC-exception-3.1.

Ви можете знайти список загальних винятків на сторінці Винятки з ліцензії SPDX.

Як працює сумісність ліцензій?

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

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

Деякі ліцензії мають взаємозаперечні вимоги. Наприклад, ліцензія CC-BY-NC-4.0 має пункт, який забороняє використовувати роботу з комерційною метою, а GPL-3.0- або новіша має пункт, який говорить, що ви не можете накладати додаткові обмеження, яких немає в ліцензії GPL. Оскільки в ліцензії GPL немає пункту про комерційні цілі, цих двох ліцензій не можна дотримуватися одночасно, і вони вважаються несумісними.

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

Зокрема, щодо GNU GPL, ця стаття GNU і список ліцензій GNU можуть допомогти вам розв’язати питання сумісності.

Важливо зазначити, що REUSE не допоможе вам розв’язати питання сумісності ліцензій. Мета REUSE — допомогти вам всебічно декларувати ваші метадані ліцензування, а не перевіряти, чи є ці метадані правильними або дійсними. Для цього потрібні різні інструменти та процеси.

Де ще можна розмістити відомості про ліцензію?

Позначення всіх окремих файлів тегами SPDX-License-Identifier проходить тривалий шлях до однозначної передачі ліцензійної інформації вашого проєкту, але це також допомагає донести інформацію про ліцензію природною мовою. У README вашого проєкту не соромтеся надавати підсумкові відомості про свою ліцензію або просто перенаправляйте читачів до вашого каталогу LICENSES/.

Крім того, багато сайтів хостингу пакунків очікують, що ви вкажете інформацію про ліцензування вашого пакунка. Наприклад, файл pyproject.toml інструменту REUSE декларує всі ліцензії, які він використовує, у форматі, очікуваному інфраструктурою пакунків Python.

У мене лише один файл ліцензії. Чи все одно потрібно створювати каталог LICENSES?

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

Однак, на додаток до цього, ви можете зберегти свій файл LICENSE/COPYING, якщо хочете. Перегляньте це питання.

Чи слід класти заголовки коментарів у файли ліцензій?

Не слід редагувати файли ліцензій. Перегляньте це питання.

Чи потрібно редагувати файли ліцензії?

Ніколи не редагуйте файли ліцензій. Коли ви використовуєте чинну ліцензію, ви завжди повинні копіювати її дослівно.

Деякі ліцензії, такі як MIT і сімейство ліцензій BSD, мають рядок “Авторське право (c) [рік] [власник авторських прав]”. Прочитайте це питання про те, як працювати з цими ліцензіями.

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

Якщо ви виявите, що якісь відомості неправильні, ви можете доповнити їх. В іншому випадку, як правило, краще лишити повідомлення про авторські права та ліцензії відмови від відповідальності недоторканими. Але тут немає єдиної відповіді.

Чи можу я вилучити ліцензію та відомості про авторські права з мініфікованого коду (наприклад, JavaScript)?

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

Чи потрібно включати до свого репозиторію і «GPL-3.0-or-later», так і «GPL-3.0-only»?

Ліцензії GPL перераховані окремо у списку ліцензій SPDX як -only, так і -or-later, навіть якщо тексти ліцензій ідентичні. Якщо у вас є код лише під однією з цих ліцензій, радимо включити лише таку ж ліцензію.

Якщо у вас є код і за ліцензією -only, і за ліцензією -or-later, радимо включити обидві ліцензії окремо.

Якщо я застосовую виключно LGPL-3.0 або новішу версію, чи повинен я також додавати текст GPL-3.0 або новішої версії?

Текст ліцензії LGPL є доповненням до тексту ліцензії GPL. Якщо ви надаєте лише текст ліцензії LGPL своїм подальшим користувачам, ви фактично не надаєте їм повну ліцензію. З цієї причини, вам також слід надати ліцензію GPL-3.0 або новішої версії у вашому каталозі LICENSES/. Лінтер REUSE може поскаржитися, що жоден з ваших файлів не використовує ліцензію GPL-3.0 або новішої версії. Щоб вирішити цю проблему, виберіть один файл, який буде ліцензовано на умовах LGPL-3.0- або новішої версії АБО GPL-3.0- або новішої версії.

Чи може REUSE допомогти мені з ліцензіями моїх залежностей?

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

Як мені …

… встановити інструмент REUSE?

Дивіться інструкції зі встановлення та супровідну документацію на https://reuse.readthedocs.io/en/stable/readme.html#install. Коротко кажучи:

$ pipx install reuse
$ pipx ensurepath
$ reuse --help

… створити специфікацію програмного забезпечення

Установіть засіб reuse та запустіть reuse spdx -o reuse.spdx у кореневому каталозі проєкту, щоб створити документ SPDX.

… додати інформацію про авторські права та ліцензування до некоментованого файлу?

Двійкові файли, такі як зображення чи відео, або певні текстові файли, такі як JSON, не можна коментувати за допомогою заголовка REUSE, але вони все одно повинні містити інформацію про авторські права та ліцензування.

Існує два способи пов’язати інформацію з таким файлом:

  1. Додайте поруч файл із суфіксом .license (наприклад, cat.jpg.license для файлу з назвою cat.jpg) і напишіть заголовок коментаря в цьому файлі. Вміст вихідного файлу ігнорується, що може бути зручно в деяких випадках.
  2. Ліцензуйте файл за допомогою REUSE.toml, файлу конфігурації REUSE.

… ліцензувати цілі каталоги?

Де це можливо, слід додавати заголовки REUSE до кожного файлу. Однак існують сценарії, коли додавання заголовка REUSE до кожного окремого файлу в каталозі є небажаним або неможливим. Наприклад:

  • Ви не маєте права редагувати файли (оскільки вони є тестовими або отримані від третьої сторони).
  • Додавання файлів .license порушить систему збирання, особливо для зображень та відео.

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

version = 1

# A simple glob of all files in resources/img/
[[annotations]]
path = "resources/img/*"
SPDX-FileCopyrightText = "2024 Jane Doe <jane@example.com>"
SPDX-License-Identifier = "CC0-1.0"

# All files in resources/vid/, with multiple copyright holders
[[annotations]]
path = "resources/vid/*"
SPDX-FileCopyrightText = [
    "2024 Джейн Доу <jane@example.com>",
    "2024 Джейн Доу <john@example.com>"
]
SPDX-License-Identifier = "CC-BY-4.0"

# A recursive glob of al	изначена.
[[annotations]]
path = "tests/resources/**"
precedence = "override"
SPDX-FileCopyrightText = "2024 Jane Doe <jane@example.com>"
SPDX-License-Identifier = "CC0-1.0"

# Два комп'ютерні файли.
[[annotations]]
path = [
    "poetry.lock",
    "requirements.txt"
]
SPDX-FileCopyrightText = "NONE"
SPDX-License-Identifier = "CC0-1.0"

У REUSE Specification докладніше описано, як можна використовувати REUSE.toml.

… перевизначити помилкову інформацію REUSE?

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

  1. Використовуйте теги REUSE-IgnoreStart і REUSE-IgnoreEnd всередині файлу.
  2. Використовуйте файл .license для заміни вмісту файлу.
  3. Використовуйте файл REUSE.toml з ключовим значенням precedence = "override".

… додати додаткову інформацію REUSE до файлу без редагування заголовка?

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

Ви можете додати додаткову інформацію за допомогою ключа-значення precedence = "aggregate" у вашому файлі REUSE.toml. Приклад виглядає так:

[[анотації]]
path = "po/*.po"
precedence = "aggregate"
SPDX-FileCopyrightText = "Учасники мого проєкту"
SPDX-License-Identifier = "GPL-3.0-or-later"

У наведеному вище прикладі до власників авторських прав файлу (якщо такі є) додано “Contributors to My Project”, а до ліцензій файлу (якщо такі є) додано “GPL-3.0-or-later”.

…копіювати чужу роботу?

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

Якщо твір має іншу ліцензію, ніж ваш проєкт, вам слід перевірити сумісність ліцензій і додати нові ліцензії до вашого проєкту.

… копіювати твір, опублікований під псевдонімом або ніком?

Ви можете вказати псевдонім як власника авторських прав. Деякі проєкти не дозволяють робити внески під псевдонімом.

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

Якщо ви не знайшли повідомлення про авторські права, ви можете спробувати додати його самостійно, відділивши правовласника від автора. Перегляньте це питання, щоб дізнатися подробиці про цю різницю. У разі виникнення сумнівів, зверніться до автора за роз’ясненнями.

Можливо, автор бажає залишитися анонімним, що є його правом. Ви можете написати NONE або NOASSERTION як правовласник.

Якщо робота не має ліцензії, то це означає, що ви не маєте права її копіювати. Якщо ви вважаєте, що це помилка, і автор явно мав на увазі, що ви можете скопіювати цю роботу, вам слід зв’язатися з автором і попросити його ліцензувати свої роботи. Не соромтеся посилатися на https://reuse.software.

… виключити файл з тестування на відповідність REUSE?

Якщо файл є артефактом збірки і ви використовуєте Git, просто переконайтеся, що він покривається вашим файлом .gitignore. Те саме стосується інших механізмів ігнорування VCS.

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

Якщо ви дійсно хочете виключити файл, подумайте про застосування для нього ліцензії CC0-1.0. Таким чином, ви переносите файл у [суспільне надбання або еквівалент у вашій країні] (https://fsfe.org/freesoftware/legal/faq.html#public-domain).

Якщо у вас є цілий каталог, який ви хочете “виключити” з перевірки на відповідність REUSE, ви можете використовувати REUSE.toml.

… виключити певні рядки з перевірки на відповідність REUSE?

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

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

Приклад для файлу, який містить команди або документацію, що заплутують інструмент REUSE:

# SPDX-FileCopyrightText: 2021 Джейн Доу
#
# SPDX-License-Identifier: GPL-3.0-or-later

echo "SPDX-FileCopyrightText: $(date +'%Y') John Doe" > file.txt
echo "SPDX-License-Identifier: MIT" >> file.txt

Розділ можна проігнорувати так:

# SPDX-FileCopyrightText: 2021 Джейн Доу
#
# SPDX-License-Identifier: GPL-3.0-or-later

# REUSE-IgnoreStart
echo "SPDX-FileCopyrightText: $(date +'%Y') John Doe" > file.txt
echo "SPDX-License-Identifier: MIT" >> file.txt
# REUSE-IgnoreEnd

… працювати з файлами без авторських прав?

Деякі файли, наприклад, згенеровані кодом або конфігураційні файли, які не містять творчого вираження, можуть не охоронятися авторським правом. Однак REUSE вимагає надання ліцензійної інформації для кожного окремого файлу, тому тут виникає конфлікт. Оскільки ми [не дозволяємо виключати файли] (#exclude-file), для таких файлів має бути записана певна інформація.

У вас два варіанти:

  1. Просто використовуйте свої звичайні авторські права та ліцензію для цього файлу. Ніщо не заважає вам “заявити” авторські права на власні роботи, навіть якщо суд гіпотетично може визнати такі файли такими, що не охороняються авторським правом.
  2. Відмовтеся від авторських прав, використовуючи ліцензію CC0-1.0 або іншу подібну ліцензію суспільного надбання.

Ви можете використовувати тег авторських прав, наприклад, `SPDX-FileCopyrightText: NONE", щоб засвідчити відсутність власника авторських прав.

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

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

… окремо декларувати авторське право та ліцензію на частину файлу?

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

Такий анотований блок фрагментів повинен починатися з SPDX-SnippetBegin, щоб позначити його початок, і закінчуватися SPDX-SnippetEnd, щоб позначити кінець фрагмента.

Зверніть увагу, що теги SPDX повинні починатися з SPDX-Snippet всередині фрагментів, що означає, що (єдиним) правильним повідомленням про авторські права у фрагменті є SPDX-SnippetCopyrightText. Винятком є SPDX-License-Identifier.

Приклад:

# SPDX-SnippetBegin
# SPDX-License-Identifier: MIT
# SPDX-SnippetCopyrightText: 2023 Джейн Доу <jane@example.com>

{$snippet_code_goes_here}

# SPDX-SnippetEnd

Фрагменти можуть вкладатися, і це позначається наявністю пар SPDX-SnippetBegin/SPDX-SnippetEnd всередині інших пар, подібно до того, як дужки вкладаються у математичних виразах. У випадку вкладених фрагментів вважається, що теги SPDX-файлу застосовуються до самого внутрішнього фрагмента. Приклад:

# SPDX-SnippetBegin
# SPDX-License-Identifier: MIT
# SPDX-SnippetCopyrightText: 2023 Джейн Доу <jane@example.com>

{$snippet_code_under_MIT}

# SPDX-SnippetBegin
# SPDX-License-Identifier: BSD-2-Clause
# SPDX-SnippetCopyrightText: Приклад компанії з авторським правом

{$snippet_code_under_BSD-2-Clause}

# SPDX-SnippetEnd

{$more_snippet_code_under_MIT}

# SPDX-SnippetEnd

Також вважається гарною практикою додатково вказувати походження фрагмента, наприклад, за допомогою коментаря на кшталт “Клас Foo скопійовано з проєкту Bar”.

Альтернативою використанню фрагментів є вилучення блоку коду з файлу і збереження його у власному файлі.

… використовуєте ліцензію, якої немає у списку ліцензій SPDX?

Якщо ви маєте власну або модифіковану ліцензію, якої немає у списку ліцензій SPDX, помістіть її у файл LICENSES/LicenseRef-MyLicense.txt. Якщо назвати вашу ліцензію з префіксом LicenseRef-, інструменти, які підтримують SPDX, зможуть розпізнати вашу ліцензію.

У цьому прикладі заголовок у файлах, на які поширюється ця користувацька ліцензія, може мати такий вигляд:

# SPDX-License-Identifier: LicenseRef-MyLicense
# SPDX-FileCopyrightText: 2017 Джейн Доу <jane@example.com>

Це також може знадобитися, коли ви маєте справу з кількома різними варіантами настроюваних текстових файлів ліцензії, як у MIT або BSD.

Зауважте: Наполегливо радимо використовувати встановлені та затверджені ліцензії.

… використовувати користувацький виняток з ліцензії?

Неможливо створити власний виняток. Замість цього ви можете створити власну ліцензію, яка вбудовує виняток.

… правильно декларувати мультиліцензування?

Ви завжди повинні включати всі ліцензії в каталог LICENSES/.

Правильний вираз ліцензії SPDX, який застосовується до файлу, залежить від способу. Якщо весь код всередині ліцензований під кількома ліцензіями, і ліцензіат може вибрати, за якою ліцензією він надає твір, використовуйте SPDX-License-Identifier: MPL-1.1 OR GPL-2.0-or-later OR LGPL-2.1-or-later, як це робить Firefox.

Якщо весь код у файлі ліцензовано кількома ліцензіями, і користувач повинен прийняти всі ліцензії одночасно, застосуйте SPDX-License-Identifier: LGPL-2.0-or-later AND AML, як це можна знайти в Simple DirectMedia Layer (SDL).

Якщо весь код у файлі ліцензовано під тією чи іншою ліцензією (наприклад, весь код ліцензовано лише під GPL-2.0, але одну функцію - під MIT), використовуйте snippets.

Ви можете прочитати більше про вирази SPDX у специфікації.

… мати справу з текстами ліцензій, які містять заяви про авторські права, як MIT/BSD?

Деякі тексти ліцензій, такі як ліцензії MIT або сімейства BSD, можуть бути змінені, щоб містити спеціальні повідомлення про авторські права.

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

Коли ви повторно використовуєте код з декількох джерел, які використовують ліцензію MIT/BSD, ви швидко зіткнетеся з проблемою. І ліцензія MIT, і сімейство ліцензій BSD містять пункт, який вимагає від розповсюджувача (тобто вас) відтворювати повідомлення про авторські права і текст ліцензії. Наприклад, Проєкт A і Проєкт Б можуть використовувати ліцензію MIT, але фактичні ліцензійні файли будуть відрізнятися, оскільки вони містять різні повідомлення про авторські права. Якщо ви хочете повторно використовувати код з обох цих проєктів, ви можете не знати, куди подіти свої копії ліцензійних файлів цих проєктів.

Ми рекомендуємо дві опції:

  1. Найпрагматичніше рішення — помістити незмінений текст ліцензії (тобто шаблон тексту ліцензії без жодних повідомлень про авторські права) до вашої теки LICENSES/. Потім ви вставляєте повідомлення про авторські права попереднього проєкту у відповідні файли початкового коду, які ви використовували повторно, як зазвичай.
  2. Ретельніше і трудомісткіше рішення полягає в тому, щоб розглядати будь-який з цих текстів ліцензії зі зміненими повідомленнями про авторські права як користувацьку ліцензію з використанням LicenseRef. Однак, якщо ви повторно використовуєте багато стороннього коду під цими ліцензіями, у вас може з’явитися багато таких нестандартних ліцензій.

Деякі файли змінюються багатьма користувачами й мають надзвичайно довгий список власників авторських прав у заголовку. Це може бути приємно, але не є неправильним.

Якщо ви не хочете мати справу з такою кількістю повідомлень про авторські права, деякі проєкти, такі як Chromium, обходять цю проблему, застосовуючи «Авторське право (c) 2013 Автори Chromium» міткою авторських прав. Ви можете розглянути такий спосіб, але тоді ви повинні тримати список правовласників і авторів в окремому файлі у вашому проєкті.

Чому REUSE

Чи потрібно додавати заголовки ліцензії та авторських прав до всіх файлів? Чому мене це повинно хвилювати?

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

Але навіть менші проєкти або проєкти з простим ліцензуванням отримують вигоду від REUSE. Добре це чи погано, але ліцензування — це наріжний камінь руху за вільне програмне забезпечення. Це те, що уможливлює спільне використання, а у випадку копілефту — дозволяє нам зберігати програмне забезпечення вільним. Правильне ліцензування дуже важливе, інакше люди не зможуть користуватися вашим програмним забезпеченням, і REUSE — це простий компонент, який допоможе вам у цьому.

Щобільше, навіть якщо ваш проєкт простий тепер, він не завжди може бути таким. Якщо ви копіюєте якийсь код з іншого проєкту, що має іншу ліцензію, ви часто зобов’язані правильно вказувати авторство та/або надавати супровідний текст ліцензії. Впровадивши REUSE на ранній стадії, набагато легше відрізнити свій код від коду сторонніх розробників і правильно відстежувати ці речі.

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

Для мене звично робити все інакше; хіба я не можу продовжувати робити те, що й завжди?

Деякі люди, коли вперше стикаються з REUSE, стикаються з кількома речами, які дуже відрізняються від того, до чого вони звикли. Їм не вистачає довгих юридичних написів у верхній частині файлів, не вистачає файлу COPYING/LICENSE у корені сховища, вони думають, що файли .license захаращують каталог, або вважають дуже дивним, що навіть незначні некодові файли отримують заголовки з ліцензіями. Таким чином, інакшість REUSE може здаватися своєрідною.

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

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

Чому REUSE не використовує поля метаданих у зображеннях, SVG, текстових документах тощо?

Деякі формати файлів підтримують зберігання інформації про метадані у самому файлі, а деякі навіть містять поля для зазначення авторських прав та ліцензії. Однак, ми не підтримуємо їх у REUSE з практичних міркувань:

  1. Як для людей, так і для машин не завжди просто розпізнати цю інформацію. REUSE має намір спростити пошук інформації про ліцензування та авторські права.
  2. Деякі інструменти редагують поля метаданих, наприклад, щоб зменшити розмір файлів або видалити потенційно чутливу особисту інформацію. Це також може стерти вашу або чиюсь іншу інформацію про авторські права, а виявити цю помилку складно.
  3. Для деяких типів файлів існують конкурентні та нестандартні методи зберігання метаданих.

Це питання також пов’язане з тим, чому ми не можемо використовувати керування версіями для запису авторських прав.

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

Інша проблема полягає можливій наявності помилок в історії керування версіями, а виправлення такої помилки вимагатиме переписування історії, в результаті чого всім дописувачам доведеться повторно завантажити свій внесок.

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

Що сталося з .reuse/dep5?

Наразі REUSE використовує REUSE.toml для файлів масових ліцензій. Але до версії 3.2 специфікації REUSE використовував .reuse/dep5, майже дослівну копію DEP5/debian/copyright.

У версії 3.2 .reuse/dep5 застарів, але досі підтримується, хоча і є взаємозаперечним з REUSE.toml. Ви можете використовувати reuse convert-dep5 для автоматичного перетворення файлу .reuse/dep5 у семантично еквівалентний файл REUSE.toml.

.reuse/dep5 було вилучено на користь REUSE.toml з різних причин:

  • debian/copyright ніколи не було цілеспрямованим поєднанням для REUSE. Debian використовує цей файл для цілісного декларування ліцензування пакунка; REUSE використовує його для заповнення прогалин у ліцензуванні.
  • .reuse/dep5 був неоднозначним щодо інформації про ліцензування файлу, якщо ця інформація була оголошена як у самому файлі, так і в .reuse/dep5. Яка інформація застосовується? У версії 3.2 ця інформація явно агрегується. Додавання нового ключа для явного оголошення пріоритету було б складним, оскільки…
  • .reuse/dep5 важко розбирати. Існує модуль Python у python-debian, але його формат нестандартний і негнучкий. Одна з основних цілей REUSE - бути машинозчитуваним, а цей нестандартний формат не сприяв досягненню цієї мети.
  • TOML більш гнучкий. Ви можете написати будь-яке значення ключа, що може бути корисним для користувацьких робочих процесів.
  • TOML набагато простіше писати. Розробники вже знають, як писати TOML, і їм не потрібно привчати себе до спеціального формату.
  • Файл REUSE.toml може бути розміщений у будь-якому місці відносно файлів і може бути вкладений. Це велика допомога для монорепозиторіїв або проєктів, схожих на монорепозиторії.

Для сумісності, .reuse/dep5 буде підтримуватися, незважаючи на його застарілість, протягом тривалого часу; принаймні до 2029 року.