Czy musisz dołączać informację o licencji do każdego pliku źródłowego?


111

Szukałem różnych licencji, których mogę użyć do mojego projektu typu open source, ale wszystkie projekty, które widziałem, z wszelkiego rodzaju licencjami, wydają się być gigantyczne, wstrętne (moim zdaniem) zauważ w każdym pliku źródłowym, że stwierdza, że ​​plik znajduje się na liście w ramach określonej licencji. Nie sądzę, że znalazłem projekt z jednego źródła, który nie jest domeną publiczną i nie ma takiego powiadomienia.

To po prostu wydaje się stratą czasu i przestrzeni na pliki. Planuję umieszczać @licensei @authortagi w moich projektach, ale nie rozumiem, dlaczego muszę wymieniać tak wielkie powiadomienie w każdym pliku, jeśli nie chcę, aby mój kod był domeną publiczną.

Czy jest jakiś powód, dla którego chciałbym zamieścić takie powiadomienie w moich projektach, czy po prostu zamieszczenie powiadomienia READMEi @licensetagu byłoby wystarczająco dobre? Czy wpływa to na „jasno określoną” zasadę większości licencji, czy jest to po prostu przesada, aby ludzie się nie sprzeczali?


10
Twój edytor powinien pozwolić ci złożyć / ukryć licencję w 1 linii.
Pubby

1
Realistycznie, gdyby ktoś ukradł twój kod, zmienił nazwę zmiennej i usunął prawa autorskie, czy sąd uznałby te 2 pliki za identyczne?
NoChance,

5
@Emmad: Nie, sąd nie powiedziałby, że są identyczne. (Ale mogą być „zasadniczo identyczne”). Tak, sąd powiedziałby, że narusza prawa autorskie.
Andrew Dalke,


Odpowiedzi:


39

W moim rozumieniu GPLv3 zdecydowanie sugeruje (a może nawet wymaga, przynajmniej tak rozumiem tekst Jak zastosować niniejsze warunki do nowych programów , po sekcji 17), informację o prawach autorskich w każdym pliku źródłowym. To mówi

W tym celu dołącz do programu następujące uwagi. Najbezpieczniej jest dołączyć je na początku każdego pliku źródłowego, aby najskuteczniej stwierdzić wyłączenie gwarancji; a każdy plik powinien mieć przynajmniej linię „prawa autorskie” i wskaźnik do miejsca, w którym znajduje się pełne powiadomienie.

<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/>.

Projekty GNU, które są własnością FSF, takie jak GCC, mają taką informację w każdym pliku.

Znam również program (system CAIA J.Pitrat), któremu odmówiono na stronie internetowej społeczności wolnego oprogramowania, ponieważ nie miał takiego powiadomienia w każdym pliku.

Nie jestem prawnikiem , ale uważam, że takie zawiadomienie jest praktycznie obowiązkowe w każdym pliku źródłowym programu GPLv3 .

(jeśli używasz innej licencji, zwłaszcza innej niż FSF, przeczytaj uważnie, jak ją zastosować; YMMV; jednak AFAIK napisanie zawiadomienia w każdym pliku nie zaszkodzi.)


16
Nie może być obowiązkowe, ponieważ istnieją systemy, takie jak obrazy Smalltalk, które nie wyrażają kodu źródłowego jako plików. Mówią „najbezpieczniej” i „powinien”, a nie „musi”. To, co zalecają, to łatwa do zrozumienia wytyczna z niewielką szansą popełnienia błędu, ale zdecydowanie nie jest „praktycznie obowiązkowa”.
Andrew Dalke,

Zgadzam się i celowo powiedziałem „plik źródłowy”. W rzeczywistości system CAIA przypomina trochę Smalltalk: obraz znajduje się w plikach danych, a wspomniane przeze mnie „pliki źródłowe” CAIA są generowane w postaci plików C. Jednak mój GCC MELT (oddział GCC, objęty prawem autorskim FSF) jest również meta-programowany i staram się generować komentarze do informacji o prawach autorskich w wygenerowanych plikach C (i umieszczam je w ręcznie napisanym kodzie C & MELT).
Basile Starynkevitch,

Punkt wzięty. Znam teraz jeden akapit o MELT. Zasadniczo najlepiej jest, aby generowane pliki zawierały informację o prawach autorskich, ponieważ w przeciwnym razie bardzo trudno jest „dołączyć” licencję. Np. „Yacc” i „lex” mają ograniczone możliwości.
Andrew Dalke,

1
Z własnego doświadczenia: aby projekt został zaakceptowany w Savannah , musisz mieć licencję na każdy plik.
Mael

1
Właśnie w celu wyjaśnienia, zgodnie z GPL FAQ, #LicenseCopyOnly i #NoticeInSourceFile w chwili pisania tego tekstu, to nie muszą zawierać Jak ubiegać ... tekst do każdego pliku źródłowego; zauważ, że język używa „powinien”, a nie „musi”. Jednak zdecydowanie zalecają przestrzeganie tej praktyki.
ZeroKnight

37

Widziałem wiele projektów, które wspominają tylko o licencji w README lub w pliku LICENCJI lub KOPIOWANIA.

Twoje oprogramowanie jest automatycznie chronione prawem autorskim, zgodnie z prawem międzynarodowym. (Chyba że pracujesz dla rządu USA lub innej organizacji, do której prawa autorskie nie mają zastosowania).

Jeśli ktoś korzysta z Twojego oprogramowania, musi przestrzegać umowy licencyjnej lub ograniczeń dozwolonego użytku dotyczących tego, co może zrobić.

Załóżmy, że ta osoba chce użyć jednego z plików w dystrybucji kodu, co oczywiście wymaga kopii, a zatem obowiązują przepisy dotyczące praw autorskich. Domyślnie NIE mają prawa do korzystania z twojego oprogramowania zgodnie z prawem autorskim. Tylko wtedy, gdy znają i przestrzegają ograniczeń licencyjnych, mogą z nich korzystać.

Więc jeśli używają pliku bez licencji na oprogramowanie, łamią prawo autorskie. Ponieważ wszystkie licencje mówią coś w rodzaju „Powyższa informacja o prawach autorskich i ta informacja o zezwoleniu będą zawarte we wszystkich kopiach lub znacznych częściach Oprogramowania”, są oni zobowiązani do umieszczenia tej licencji gdzieś.

Może to znajdować się w samym pliku lub gdy użyłem kodu jako biblioteki, umieściłem odpowiednie części w swoim własnym katalogu i dodałem „README” lub „LICENCJA” do tego podkatalogu.

Krótko mówiąc, nie musisz umieszczać licencji w każdym pliku. Myślę, że to przesada. Nie ma przy tym dodatkowej ochrony prawnej. To trochę pomaga dalszemu użytkownikowi, ale niewiele.

Myślę, że tradycja wielu metadanych opartych na komentarzach (licencja, data utworzenia każdej funkcji, dziennik zmian itp.) To bardzo stare tradycje, które istnieją, ponieważ są łatwe do wykonania i które są bardziej talizmanem niż użytecznym.

Na przykład domyślny szablon Eclipse dodaje przed każdą funkcją coś, co uważam za bezużyteczne metadane, które moim zdaniem lepiej przechwytuje kontrola wersji. Ale taka praktyka jest powszechna w wielu sklepach.


2
Na przykład w ogóle nie widzę nic związanego z licencjonowaniem w plikach źródłowych Railsów.
Anton Barkovsky,

3
Z 200 plików w standardowej bibliotece najwyższego poziomu w Pythonie tylko 34 zawiera słowo „prawa autorskie”, a tylko 4 z nich dotyczą Python Software Foundation, która kontroluje prawa autorskie do Pythona.
Andrew Dalke,

tak, nie sądzę, że informacje o prawach autorskich dla poszczególnych plików będą trwać ... to po prostu o wiele za dużo ... to po prostu nie może być droga w przyszłości .. pomyśl SUCHA ... LICENCJA na poziomie głównym, i zacznijmy nazwij to dzień .. myślę, że głównie wszystko na npm robi to już w ten sposób
ChaseMoskal

13

Problem polega na tym, że bardzo łatwo jest rozpakować pojedynczy plik kodu źródłowego z jego większego projektu, takiego jak ktoś po prostu sprawdzający, wysyłający e-mailem, pobierający jeden plik, bez reszty, która zawiera pełne prawa autorskie. Następnie plik ten może zostać przekazany w nieskończoność w czasie, stronom trzecim, które mogą nie mieć pojęcia o pochodzeniu plików.

Informacja o prawach autorskich u góry przypomina każdemu, kto przeszukuje ten samotny plik, że tak naprawdę jest chroniony prawami autorskimi, a nie domeną publiczną, a zatem niektóre licencje mogą, ale nie muszą być zaangażowane w jego dystrybucję lub wykorzystanie. W przeciwieństwie do umożliwienia znajdującemu własne losowe założenia.


21
Czy rozkładanie i wklejanie różnych fragmentów pliku źródłowego nie jest tak proste? Co wtedy? Ten argument wydaje mi się niespójny.
Travis Griggs,

10
Problem stanowi założenie domeny publicznej dla dzieła bez informacji o prawach autorskich. Jeśli natrafisz na plik bez informacji o prawach autorskich, nie powinieneś kopiować go i wysyłać innym osobom.
Rich Remer

oczywiście istnieje problem polegający na tym, że „klonowanie i posiadanie” pliku jest legalne, umieściliśmy open source bezpośrednio w naszym repozytorium projektu, ponieważ czasami trudno jest naprawić błąd poza projektem upstream, ale nie możesz się doczekać je zwolnić. Nie mówię, że to dobry pomysł, ale już to zrobiliśmy.
Xenoterracide

8

W podziemnym bunkrze nie ma tajnego spotkania supermocarstwa, które mówi, co należy umieścić w każdym pliku źródłowym.

Wyjaśnia to użytkownikowi, że ten plik jest objęty dowolną licencją, a tak naprawdę większość oprogramowania GPL zawiera krótką preambułę z tekstem: license.txt. Pamiętaj, że projekty dzielą się, a pliki są ponownie wykorzystywane, więc umieszczenie wiadomości w jednym pliku może nie być dobrym pomysłem.

Jeśli w mało prawdopodobnym przypadku kiedykolwiek trafi do sądu, możesz mieć więcej roszczeń, jeśli wyraźnie oznaczysz każdy plik jako swoją pracę i pod jaką licencją był on objęty - wtedy nikt nie może twierdzić, że uważał, że ten prticular plik nie został objęty


6

Prawie zadałem niezwykle podobne pytanie. Mniej o irytacjach, a więcej o technicznych. TL; DR: Uważam, że odpowiedź jest kwestią priorytetów autora. Może zamiar byłby dokładniejszy niż priorytety ...

Uważam, że można odwoływać się do licencji w twoim źródle, w zależności od twojej definicji „w porządku”. Zgadzamy się, że termin „bez opieki” oznacza plik źródłowy, który jest częścią projektu, który został bezwzględnie oddzielony od jego kochającej bazy kodu. Wspomniany plik zawiera taką linię:

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

Lub o wiele fajniejsza linia:

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

"Ale poczekaj!" , wykrzykujesz, „właśnie powiedziałeś, że plik został oddzielony od swojego projektu! I goodlics.com przekierowuje do squattera domen! Przestań być trixy!” Masz rację, powiedziałem to, ale to może być w porządku i przestań na mnie krzyczeć. Oto moje uzasadnienie nie-prawnika:

  • Prawie każdy kraj zgodził się na [czuć] Konwencję Berneńską, co AFAIK oznacza, że ​​jeśli coś stworzysz, masz do niej prawa autorskie, kropka. Nie potrzebujesz linii (c) ani żadnego takiego badziewia, ale takie rzeczy (plus VCS innych firm, jak GitHub) ułatwiają udowodnienie , że je stworzyłeś i kiedy je stworzyłeś.
  • Dlatego jeśli opublikujesz soczysty kod 1337, który utworzyłeś, masz do niego prawa autorskie. Nikomu nie wolno (legalnie) kopiować. Wiem, że to rzadkie i szokujące, ale słyszałem, że ludzie czasami łamią prawo. To wciąż możliwe.
  • Ten niesamowity nyancat-bcminer-algo.qbasicplik, który napisałeś i opublikowałeś na LiveJournal, to, wierz lub nie, nie domena publiczna. Nie, chyba że powiesz, że to domena publiczna. Domyślnie jest twój i tylko ty. To jest ... Drogocenne . (Przynajmniej przez 25-50 lat, chyba że jesteś Disneyem.)
  • Ludzie umownie komunikują ten zamiar (czyniąc niektóre lub wszystkie prawa nie twoje i tylko twoje) za pośrednictwem licencji, ale musisz ogłosić ten zamiar; to opt-in opt-out (HAHA OTRZYMAŁO? decyduje się na rezygnację z praw autorskich? NIESAMOWITE). Zdobądź bilety, już prawie jesteśmy!
  • Jeśli jest w porządku, że wyżej wspomniane pliki bez opieki są domeną prywatną - to znaczy, że nie można ich kopiować zgodnie z prawem, to użycie potencjalnie uszkodzonego odniesienia jest całkowicie w porządku. Jeśli jednak nie jest to w porządku , myślę, że musisz dołączyć tekst licencji do każdego pliku źródłowego. W ten sposób pliki bez nadzoru nadal będą licencjonowane w sposób, jaki zamierzałeś . Tak, tak jest lepiej.

To rozumowanie przyjmuje dwa epickie i prawdopodobnie błędne założenia:

  • „Zepsute” odniesienie do licencji opiera się na domyślnym (chronionym prawem autorskim) zachowaniu, które może nie być prawidłowym założeniem.
  • Ta witryna, na której opublikowałeś, nie ma żadnych zasad publikowania (takich jak StackExchange), które czynią wszystko domeną publiczną.

Dziękujemy za jazdę po drogach oddechowych małpiego mózgu.

Oświadczenie: Wydaje mi się to logiczne, bo jestem w 90% pewien, że w 100% się mylę.


6

Istnieje różnica między licencją a preambułą .

W niektórych moich projektach korzystam z Powszechnej Licencji Publicznej GNU, wersja 3.0 . GNU GPL wymaga posiadania preambuły dla każdego pliku kodu źródłowego:

Preambuła i instrukcje są integralnymi częściami GNU GPL i nie można ich pominąć.

Źródło: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

Oto co robię:

1. Dodaj License.txt

Aby przestrzegać zasad, umieściłem LICENSE.txt w katalogu głównym repozytorium mojego projektu. Jest to również sugerowane przez GitHub (patrz „ Gdzie mieszka licencja” ).

2. Dodaj preambułę, używając automatycznego składania

Następnie umieszczam preambułę GPL na wierzchu każdego pliku kodu źródłowego, ALE, aby nie było to trudne, ukryłem go w IDE. Większość IDE ma funkcję automatycznego składania bloków kodu. NetBeans obsługuje niestandardowe składanie kodu, a WebStorm obsługuje również składanie komentarzy .

Oto jak to wygląda:

//<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.');

Myślę, że jest to bardzo dobry kompromis między wygodą a bezpieczeństwem prawnym.

Jeśli masz wiele projektów, w których musisz dodać licencję, http://www.addalicense.com/ może ci pomóc.

Uwaga: moja rada dotyczy GPLv3. Inne typy licencji mogą nie wymagać preambuły.


7
«GNU GPL wymaga, aby każdy plik kodu źródłowego miał preambułę:» Nie ma. Część, którą zacytowałeś, po prostu uniemożliwia usunięcie preambuły z LICENSEpliku, tzn. Nie możesz zmienić tekstu GPL, upuszczając go.
Andrea Lazzarotto,

6

Jest jeszcze jeden praktyczny sposób, o którym jeszcze nie wspomniano.

SPDX-License-Identifieretykietka. https://spdx.org/using-spdx

Dzięki temu „legalny szablon” w każdym nagłówku pliku źródłowego ogranicza się do zaledwie dwóch wierszy:

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

Ponadto osoby automatyzujące analizy łańcucha dostaw oprogramowania będą wdzięczne za przestrzeganie wspólnego standardu opisu licencji do odczytu maszynowego.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.