Всі версії специфікації можна знайти за адресою <>.

Специфікація REUSE - версія 3.2

2024-07-03

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

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

Ця специфікація впроваджує IETF RFC 2119: Ключові слова для вживання у RFC для вказання рівнів вимог.

Історію редакцій цієї специфікації перегляньте у журналі змін.

Визначення

Ось визначення деяких термінів, що використовуються в цій специфікації:

  • REUSE Tool — допоміжний інструмент для дотримання цієї специфікації; доступний за адресою https://github.com/fsfe/reuse-tool.
  • Проєкт — будь-яка одиниця вмісту, яка може бути пов’язана з розповсюдженням програмного забезпечення. Як правило, проєкт складається з одного або кількох файлів. Також іноді називають пакунком.
  • Файл ліцензії — файл, що містить текст ліцензії, як визначено у Файлах ліцензій.
  • Інформація про ліцензування — інформація, яка містить перелік власників авторських прав на файл або роботу, а також описує, за якими ліцензіями файл або робота доступні.
  • Повідомлення про авторські права — рядок тексту, який повідомляє про авторські права правовласника. Його формат визначено у розділі Формат сповіщень про авторські права.
  • Покритий файл — файл, який повинен містити Ліцензійну інформацію, як визначено у розділі Покриті та ігноровані файли.
  • Файл, що коментується — звичайний текстовий файл, який може містити коментарі.
  • Фрагмент — частина тексту в коментованому файлі, до якої застосовується інша інформація про ліцензування.
  • Файл, що не коментується — або звичайний текстовий файл, який не може містити коментарів, або файл, який не є звичайним текстовим файлом.
  • Специфікація SPDX — Специфікація SPDX, версія 2.3; доступна на https://spdx.org/specifications.
  • Ідентифікатор ліцензії SPDX — ідентифікатор короткої форми SPDX, як визначено у специфікації SPDX. Перегляньте також https://spdx.org/ids для швидкого ознайомлення та прикладів.
  • Вираз ліцензії SPDX — як визначено у Специфікації SPDX, Додаток D, за адресою https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/.
  • Список ліцензій SPDX — список поширених ліцензій і винятків; доступний на https://spdx.org/licenses/.
  • DEP5 — Машиночитаний файл debian/copyright, версія 1.0; доступний на https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ і додатково описаний у DEP5 (застарілий). Якщо специфікація REUSE та DEP5 стверджують різні речі, специфікація REUSE має перевагу.
  • TOML — Формат файлу конфігурації, доступний за адресою https://toml.io/en/v1.0.0.

Покриті та ігноровані файли

Покриті файли — це будь-який файл, який повинен містити Ліцензійну інформацію. Це значення дорівнює всім файлам у проєкті, за винятком:

  • Файли ліцензії зберігаються у каталозі LICENSES/.
  • COPYING і LICENSE, з розширеннями файлів або без них.
  • Файли, що належать до системи контролю версій Проєкту (наприклад: .git/).
  • Файли, які ігноруються системою контролю версій (наприклад, файли, перелічені у .gitignore).
  • Підмодулі системи керування версіями проєкту та підпроєктів Meson. Кожен підмодуль і підпроєкт Meson розглядається як окремий проєкт.
  • Файли в каталозі .reuse/ в корені проєкту. Цей каталог повинен містити лише файли, що стосуються роботи засобу REUSE.
  • Символічні посилання та файли без даних (нульовий байт).
  • Документи SPDX у різних форматах, визначених у Специфікації SPDX, Пункт 4.4 (приклад: sbom.spdx.json).

Файли ліцензії

Проєкт ОБОВ’ЯЗКОВО повинен містити Ліцензійний файл для кожної ліцензії, за якою ліцензуються Покриті файли.

Кожен файл ліцензії повинен бути розміщений у каталозі LICENSES/ у кореневому каталозі проєкту. Назва файлу ліцензії ПОВИННА бути ідентифікатором ліцензії SPDX, а потім відповідним розширенням файлу (наприклад: LICENSES/GPL-3.0-or-later.txt). Файл ліцензії ПОВИНЕН бути у звичайному текстовому форматі.

Якщо ліцензія не існує у списку ліцензій SPDX, її ідентифікатор ліцензії SPDX МАЄ бути LicenseRef-[idstring], як визначено у Специфікації SPDX, Пункт 10, доступній за адресою https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/.

Проєкт НЕ МОЖЕ включати ліцензійні файли для ліцензій, за якими жоден з файлів у проєкті не є ліцензованим. Каталог LICENSES/ НЕ ПОВИНЕН містити жодних інших файлів.

Усе, що стосується ліцензій у цьому розділі, також стосується ліцензійних винятків, за винятком тих, що НЕ можуть мати ліцензійного винятку, якого немає у списку ліцензій SPDX.

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

Ви МОЖЕТЕ включити файли COPYING або LICENSE (з розширенням або без нього) у свій проєкт для відповідності іншим стандартам, конвенціям або інструментам. Ці файли МОЖУТЬ містити копію тексту ліцензії, коротку інформацію про ваше ліцензування або щось інше. Ці файли ігноруються інструментом REUSE.

Інформація про ліцензування

Кожен Покритий файл ПОВИНЕН мати пов’язану з ним інформацію про ліцензування. Ви можете пов’язати інформацію про ліцензування з файлом такими способами:

  • Коментарі в заголовку
  • REUSE.toml
  • DEP5 (застарілий)

REUSE.toml і DEP5 взаємозаперечні. Ви НЕ МОЖЕТЕ використовувати обидва одночасно.

РЕКОМЕНДОВАНО використовувати заголовки коментарів.

Крім того, ви можете пов’язати інформацію про ліцензування з фрагментами всередині файлів.

Коментарі в заголовку

Там, де це можливо, ви ПОВИННІ намагатися використовувати заголовки коментарів для передачі інформації про ліцензування файлу. Порівняно з іншими методами, заголовки коментарів чіткіші, а пов’язана з ними інформація про ліцензування стійкіша до переміщення або копіювання.

Щоб реалізувати цей метод, файл, що коментується, ПОВИНЕН оголосити інформацію про ліцензування файлу у заголовку коментаря. Інформація про ліцензування ПОВИННА бути якомога ближче до верхньої частини файлу в заголовку коментаря. Файл, що коментується, ПОВИНЕН використовувати кодування UTF-8.

Для файлів, що не коментуються, заголовок коментаря, який оголошує інформацію про ліцензування файлу, ПОВИНЕН бути в сусідньому текстовому файлі з тією ж назвою і додатковим розширенням .license (наприклад: cat.jpg.license, якщо початковий файл має назву cat.jpg). Сусідній файл ПОВИНЕН використовувати кодування UTF-8.

Файли .license МОЖНА використовувати з файлами, що коментуються, але все ж таки РЕКОМЕНДОВАНО розміщувати заголовки коментарів всередині файлів, що коментуються.

Заголовок коментаря ПОВИНЕН містити одне або декілька повідомлень про авторські права та одну або декілька пар тегів-значень SPDX-License-Identifier. Після тегу ставиться двокрапка, за якою йде текстове значення, і завершується тег новим рядком.

За тегом SPDX-License-Identifier ПОВИНЕН слідувати дійсний вираз ліцензії SPDX, що описує ліцензування файлу (наприклад: SPDX-License-Identifier: GPL-3.0-or-later OR Apache-2.0).

Приклад заголовка коментаря:

# SPDX-FileCopyrightText: 2016, 2018-2019 Джейн Доу <jane@example.com>
# SPDX-FileCopyrightText: 2019 Приклад Організації
#
# SPDX-License-Identifier: GPL-3.0-or-later

Вбудовані коментарі до фрагментів

Іноді інформація про ліцензування стосується лише певного фрагмента, а не всього коментованого файлу. У цих випадках для цього фрагмента ПОВИННІ використовуватися теги фрагментів SPDX (як визначено у [Специфікація SPDX, Додаток H] (https://spdx.github.io/spdx-spec/v2.3/file-tags/#h3-snippet-tags-format)). Це означає, що повідомлення про авторські права всередині фрагментів МАЮТЬ мати префікс SPDX-SnippetCopyrightText.

Як і у випадку з коментарями заголовків, теги фрагментів SPDX ПОВИННІ бути прокоментовані.

Фрагмент ПОВИНЕН містити як повідомлення про авторські права, так і вираз ліцензії SPDX.

Приклад:

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

print("Hello, world!")

# SPDX-SnippetEnd

Ігнорувати блок

Якщо інформацію про ліцензування оголошено у файлі без опису власне ліцензії або авторських прав на файл або фрагмент (наприклад, як частину команди виводу або документації), такі випадки ПОВИННІ бути поміщені між двома коментарями: REUSE-IgnoreStart і REUSE-IgnoreEnd. Після цього інструмент REUSE ігнорує всю інформацію про ліцензування між цими коментарями. Цей метод НЕ МОЖНА використовувати для ігнорування дійсних відомостей про ліцензування.

Приклад для ігнорованого блоку:

# 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.toml

Інформація про ліцензування МОЖЕ бути пов’язана з файлом через файл REUSE.toml, який ПОВИНЕН бути дійсним файлом TOML. Передбачуваним випадком використання цього методу є великі каталоги, де включення заголовка коментаря до кожного файлу (або до супутніх файлів .license) є неможливим або небажаним.

Файл REUSE.toml МОЖЕ бути розташований у будь-якому каталозі і може охоплювати файли, що знаходяться у цьому каталозі або глибше. У вас МОЖЕ бути декілька файлів REUSE.toml у різних каталогах.

Ключ version (ОБОВ’ЯЗКОВИЙ) ПОВИНЕН мати цілочисельне значення, що представляє версію схеми файлу. Ця специфікація описує версію 1 файлу REUSE.toml.

Кожна таблиця [[annotations]] представляє зв’язок Ліцензійної інформації з нулем або більшою кількістю Охоплених файлів. Він має такі ключі:

  • path (ОБОВ’ЯЗКОВО), рядок або список рядків, що представляють шляхи. Шлях ОБОВ’ЯЗКОВО має використовувати пряму похилу риску роздільником шляху. Шлях ПОВИНЕН розпізнавати один або кілька покритих файлів відносно каталогу файлу REUSE.toml. Шлях, який призводить до відсутнього або непокритого файлу, ігнорується. Шлях ПОВИНЕН вказувати на місце в каталозі файлу REUSE.toml або глибше. Шлях МОЖЕ використовувати глобування для зіставлення кількох охоплених файлів в одному виразі. Це правила глобування та зіставлення:
    • * відповідає всьому, крім прямих скісних рисок (тобто роздільників шляхів).
    • ** та **/ збігається з усім, включно з прямими слешами (тобто роздільниками шляхів).
    • Щоб уникнути зірочки і включити текст дослівно, додайте до нього префікс \\. Ви не можете додавати до нього \, тому що це недійсний TOML. Щоб дослівно вказати зворотну косу риску, використовуйте \\\\. \\, за яким слідує будь-який інший символ, функціонально дорівнює простому введенню цього символу.
  • precedence (НЕОБОВ’ЯЗКОВО), буквений рядок. Він визначає порядок пріоритету Ліцензійної інформації між файлом REUSE.toml і Покритими файлами в таблиці, а також між декількома файлами REUSE.toml, якщо вони обидва містять Ліцензійну інформацію для одного і того ж Покритого файлу. Доступні значення такі:
    • closest, усталене значення, якщо precedence не визначено. Це інструкція для асоціювання Ліцензійної інформації всередині Покритих файлів (або сусіднього файлу .license), якщо така є. Якщо такої інформації про ліцензування не знайдено, то асоціюється інформація про ліцензування всередині таблиці найближчого REUSE.toml, що охоплює Файл. Цей алгоритм застосовується окремо для авторських прав і для ліцензування. Якщо таблиця для цього ж файлу у ближчому файлі REUSE.toml має пріоритет override, то застосовується цей пріоритет, а closest ігнорується. Це фактично запасний варіант.
    • aggregate. Це вказівка завжди пов’язувати Ліцензійну інформацію, визначену в таблиці, із зазначеними в таблиці Покритими файлами. Згодом, також застосовується логіка closest.
    • override. Це вказівка пов’язувати Ліцензійну інформацію, визначену в таблиці, із зазначеними в ній Файлами та ігнорувати будь-яку іншу Ліцензійну інформацію, яка знаходиться ближче до Файлів. Таблиця в REUSE.toml, яка знаходиться найближче до кореня проєкту, є авторитетною.
  • SPDX-FileCopyrightText (НЕОБОВ’ЯЗКОВО), рядок або список рядків. Кожен рядок ПОВИНЕН бути повідомленням про авторські права, щоб бути пов’язаним з Покритими файлами таблиці. Префікс Повідомлення про авторські права МОЖЕ бути опущений.
  • SPDX-License-Identifier (НЕОБОВ’ЯЗКОВО), рядок або список рядків. Кожен рядок ПОВИНЕН бути дійсним виразом ліцензії SPDX, що описує ліцензування вкладених файлів таблиці.

Ви МОЖЕТЕ включити інші ключі та таблиці для передачі додаткової інформації. Їх семантика не визначена цією специфікацією. Якщо ви бажаєте додати інші ключі, РЕКОМЕНДОВАНО використовувати наявні теги SPDX. Наприклад, ви можете використовувати SPDX-FileComment у таблиці [[annotations]], щоб додати контекст до того, що ви робите, або SPDX-FileContributor, щоб зарахувати додаткових дописувачів.

Хоча ключі для асоціювання Ліцензійної інформації з Покритим файлом є НЕОБОВ’ЯЗКОВИМИ, повна Ліцензійна інформація ПОВИННА бути асоційована з Файлом певним чином.

Якщо покритий файл охоплюється кількома таблицями [[annotations]] в одному файлі REUSE.toml, то для цього покритого файлу використовується виключно остання відповідна таблиця у файлі.

Приклад файлу REUSE.tml:

version = 1

[[annotations]]
path = ["po/*.po", "po/*.pot"]
precedence = "aggregate"
SPDX-FileCopyrightText = "2019 Translation Company"
SPDX-License-Identifier = "GPL-3.0-or-later"

[[annotations]]
path = "tests/resources/**"
precedence = "override"
SPDX-FileCopyrightText = "2019 Jane Doe"
SPDX-License-Identifier = "CC0-1.0"

DEP5 (застарілий)

Інформація про ліцензування МОЖЕ бути пов’язана з файлом за допомогою файлу DEP5, але ви ПОВИННІ створити замість нього файл REUSE.toml. Файл DEP5 є застарілим, тобто очікується, що він зникне з майбутніх ітерацій цієї специфікації.

Файл DEP5 ПОВИНЕН мати назву dep5 і зберігатися в каталозі .reuse/ у корені проєкту (тобто .reuse/dep5).

Після тегу Files ОБОВ’ЯЗКОВО слідує один або декілька шляхів, до яких застосовується інформація про ліцензування параграфа.

За тегом License ПОВИНЕН слідувати дійсний вираз ліцензії SPDX, що описує ліцензування пов’язаних файлів.

За тегом Copyright ОБОВ’ЯЗКОВО має слідувати одне або декілька повідомлень про авторське право. Префікси в повідомленнях про авторське право МОЖНА опускати.

Приклад файлу DEP5:

Формат: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Файли: po/*.po po/*.pot
Авторське право: 2019 Перекладацька Компанія
Ліцензія: GPL-3.0-or-later

Файли: tests/resources/*
Авторське право: 2019 Джейн Доу
Ліцензія: CC0-1.0

Порядок пріоритетності

Якщо файл, що коментується, містить інформацію про ліцензування, але також має суміжний файл .license, то інформація про ліцензування, визначена у файлі .license, має пріоритет, а вміст файлу, що коментується, ігнорується. Для всіх цілей, це вважається, що Ліцензійна інформація файлу .license міститься у файлі, що коментується.

Ліцензійна інформація, визначена у файлі .reuse/dep5, об’єднується з Ліцензійною інформацією, що міститься у Покритих файлах. Для ясності, це означає, що якщо вирази ліцензії SPDX у заголовку коментаря до файлу і в розділі для цього файлу в .reuse/dep5 не узгоджуються один з одним, то до файлу застосовуватимуться обидва вирази ліцензії SPDX.

Порядок пріоритету для файлів REUSE.toml описано у відповідному розділі, і ним можна керувати за допомогою ключа precedence.

Формат повідомлень про авторське право

Повідомлення про авторське право ПОВИННО починатися з тегу, слова або символу (разом: префікси) з наведеного нижче списку:

  • SPDX-FileCopyrightText (або SPDX-SnippetCopyrightText у Фрагментах)
  • Авторське право
  • ©

РЕКОМЕНДОВАНО використовувати тег SPDX-FileCopyrightText. Ви МОЖЕТЕ додавати ‘(C)’, ‘(c)’ або ‘©’ після префікса.

У файлах, що коментуються, повідомлення про авторське право закінчується новим рядком.

Повідомлення про авторське право ОБОВ’ЯЗКОВО має містити ім’я власника авторських прав. Повідомлення про авторське право ПОВИННО містити рік публікації та контактну адресу правовласника. Порядок цих пунктів ПОВИНЕН бути таким: рік, ім’я, контактна адреса.

Рік публікації МОЖЕ бути один рік, кілька років, або проміжок років.

Власник авторських прав ПОВИНЕН бути фізичною особою, списком осіб, групою осіб, юридичною особою або будь-яким іншим дескриптором, за допомогою якого можна легко ідентифікувати власника(ів) авторських прав.

Будь-яка контактна адреса ПОВИННА розміщуватися між кутовими дужками.

Ви МОЖЕТЕ додати будь-яку додаткову інформацію до Повідомлення про авторське право.

Приклади дійсних повідомлень про авторське право:

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) Аліса, деякі права захищені