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


111

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

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

Чи є якась причина, чому я хотів би включити таке повідомлення у свої проекти, чи просто включення повідомлення у тег READMEта @licenseтег було б достатньо хорошим? Чи впливає це на "чітко заявлене" правило більшості ліцензій, чи це просто надмірна кількість, щоб люди не сперечалися?


10
Ваш редактор повинен дозволити складати / приховувати ліцензію в 1 рядок.
Паббі

1
Реально, якщо хтось скраде ваш код, перейменує змінну та видалить авторські права, чи вважатиме суд ці 2 файли однаковими?
NoChance

5
@Emmad: Ні, суд не сказав би, що вони однакові. (Але вони можуть бути "принципово однаковими".) Так, суд скаже, що це порушення авторських прав.
Ендрю Далке


Відповіді:


39

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

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

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

А проекти GNU, які належать до ФСФ, як GCC, мають таке повідомлення у кожному файлі.

Я також знаю про програму (система CAIA Дж. Пітрата), якій відмовили на веб-сайті вільної програмної спільноти, оскільки вона не мала такого повідомлення в кожному файлі.

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

(якщо ви використовуєте іншу ліцензію, особливо не FSF), уважно прочитайте, як її застосувати; YMMV; однак AFAIK написання повідомлення у кожен файл не зашкодить.)


16
Це не може бути обов'язковим, оскільки існують такі системи, як зображення Smalltalk, які не виражають вихідний код у вигляді файлів. Вони кажуть "найбезпечніше" і "повинно", а не "повинно". Те, що вони рекомендують, - це легко зрозуміла настанова з малою ймовірністю того, що хтось помилиться, але це, безумовно, не "практично обов'язково".
Ендрю Далке

Я згоден, і я сказав "вихідний файл" спеціально. Насправді система CAIA трохи схожа на Smalltalk: зображення знаходиться у файлах даних, а «вихідні файли» CAIA, які я згадував, створюються файлами C. Однак мій GCC MELT (філія GCC, захищена авторським правом FSF) також метапрограмований, і я дбаю про створення коментарів із повідомленням про авторські права у створених C-файлах (і я вкладаю їх в рукописний код C & MELT).
Василь Старинкевич

Точка взята. Зараз я знаю один абзац про MELT. Як правило, найкраще, щоб генеровані файли містили повідомлення про авторські права, оскільки "важко" прикріпити "ліцензію в іншому випадку. Наприклад, "yacc" і "lex" обмежені тим, що вони можуть робити.
Ендрю Далке

1
З особистого досвіду: для того, щоб проект був прийнятий на Savannah, ти повинен мати ліцензію у кожному файлі.
Майл

1
Тільки для уточнення, відповідно до поширених запитань GPL, #LicenseCopyOnly та #NoticeInSourceFile під час написання цього тексту не потрібно включати текст " Як застосувати ..." до кожного вихідного файлу; зауважте, що мова використовує "повинен", а не "повинен". Однак вони настійно рекомендують дотримуватися цієї практики.
ZeroKnight

37

Я бачив багато проектів, які згадують лише ліцензію у README або у файлі LICENSE або COPYING.

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

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

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

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

Це може бути в самому файлі, або коли я використовую код як бібліотеку, я поміщаю відповідні частини у свою власну директорію і додаю "README" або "LICENSE" у цей підкаталог.

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

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

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


2
Наприклад, я взагалі не бачу нічого пов'язаного з ліцензуванням у вихідних файлах Rails.
Антон Барковський

3
І з 200 файлів у стандартній бібліотеці Python вищого рівня лише 34 містять слово "авторське право", і лише 4 з них - для програмного фонду Python, який контролює авторські права на Python.
Ендрю Далке

так, я не думаю, що повідомлення про авторські права на файли триватимуть ... це занадто багато ... це просто не може бути шляхом майбутнього .. подумайте, ДУЖЕ ... кореневий рівень ЛІЦЕНЗІЯ, і давайте назвіть це день .. я думаю, що в основному все в npm вже робиться так
ChaseMoskal

13

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

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


21
Чи не так просто розібрати агрегат за допомогою копіювання та вставки різних фрагментів вихідного файлу? Що потім? Цей аргумент здається мені непослідовним.
Тревіс Гріггс

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

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

8

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

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

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


6

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

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

# This file is covered by the LICENSING file in the root of this project.

Або набагато крутіша лінія на кшталт цієї:

* @license OMGBBQ <http://goodlics.com/bbq>

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

  • Майже кожна країна погодилася на [відчувати] Бернську конвенцію, що AFAIK означає, що якщо ви щось створюєте, у вас є авторські права на це, період. Вам не потрібна лінія (c) або будь-яке лайно подібне, але цей матеріал (плюс сторонній VCS, як GitHub) полегшує доказ того, що ви його створили і коли ви створили його.
  • Тому, якщо ви опублікуєте якийсь соковитий код 1337 в Інтернеті, який ви створили, у вас є авторські права на нього. Ніхто не може (законно) копіювати його. Це рідко, і шокуюче, я знаю, але я чув, що люди іноді порушують закон. Це все-таки можливо.
  • Цей дивовижний nyancat-bcminer-algo.qbasicфайл, який ви написали та опублікували на LiveJournal, є, вірите чи ні, не загальнодоступним надбанням. Якщо ви не скажете, що це суспільне надбання. За замовчуванням - це тільки ваше. Це ... дорогоцінний . (Принаймні протягом 25-50 років, якщо ви не Дісней.)
  • Люди умовно повідомляють про цей намір (роблячи деякі або всі права не лише вашими і лише вашими) за допомогою ліцензій, але вам потрібно оголосити про цей намір; це відмова від відмови (HAHA GET IT? включення для відмови від авторських прав? AWESOME). Дістаньте квитки, ми майже там!
  • Якщо це нормально, що вищезазначені файли без супроводу є приватним доменом - тобто не можуть бути скопійовані на законних підставах, то використання потенційно зламаної посилання цілком чудово. Однак якщо це не в порядку , я думаю, що вам потрібно включити текст ліцензії до кожного вихідного файлу. Таким чином, файли без супроводу, як і раніше, обов'язково ліцензуються так, як ви призначили пріоритет . Так, це краще.

Це міркування робить два епічні та, ймовірно, недійсні припущення:

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

Дякую, що їхали по мавпоподібних дихальних шляхах.

Відмова: Це мені здається логічним, я на 90% впевнений, що я на 100% помиляюся.


6

Існує різниця між ліцензією та преамбулою .

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

Преамбула та інструкції є невід’ємними частинами GPL GPL і не можуть бути опущені.

Джерело: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

Отже ось що я роблю:

1. Додати ліцензію.txt

Для дотримання правил я помістив LICENSE.txt у корінь мого сховища проекту. Це також пропонує GitHub (див. " Де живе ліцензія" ).

2. Додайте преамбулу за допомогою автоматичного складання

Далі я включаю преамбулу GPL поверх кожного файлу вихідного коду, АЛЕ важко заважати, я приховую її в IDE. Більшість IDE мають функцію автоматичного складання блоків коду. NetBeans має підтримку спеціального складання коду, а WebStorm також підтримує складні коментарі .

Отже ось як це виглядає:

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

Я думаю, що це дуже хороший компроміс між зручністю та юридичною безпекою.

Якщо у вас є багато проектів, де вам потрібно додати ліцензію, то http://www.addalicense.com/ може допомогти.

Зверніть увагу: моя порада стосується GPLv3. Для інших типів ліцензій може не потрібна преамбула.


7
«GNU GPL вимагає створення преамбули для кожного файлу вихідного коду:» Це не так. Частина, яку ви цитували, просто заважає вам видалити преамбулу з LICENSEфайлу, тобто ви не можете змінити текст GPL, скинувши його.
Андреа Лацаротто

6

Тут ще не згадується ще один практичний спосіб.

SPDX-License-Identifierтег. https://spdx.org/using-spdx

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

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.