Czy projekt na licencji BSD potrzebuje podpisanego oświadczenia od każdego z autorów?


9

Dzisiaj czytam na Fossil SCM „s listy :

Problem z BSD polega na tym, że naprawdę powinieneś otrzymać podpisany formularz od każdego autora, który stwierdza, że ​​jego wkład to BSD. W przypadku GPL dzieje się to automatycznie, ponieważ wydanie wkładów na podstawie zgodnej licencji jest warunkiem koniecznym do przeglądania kodu w GPL. To sprawia, że ​​GPL jest świetnym rozwiązaniem dla środowiska opartego na współpracy, z wieloma współpracownikami. BSD jest bardziej liberalne (mniej uciążliwe) dla czytelników, ale to sprawia, że ​​jest trochę trudniejsze dla pisarzy, ponieważ teraz muszą wysłać jakieś dokumenty.

Czy ktoś mógłby wyjaśnić, dlaczego i jakie są możliwe konsekwencje braku takiego podpisanego oświadczenia od autorów projektu?

Odpowiedzi:


6

GPL nie zawiera żadnego wyraźnego oświadczenia na temat licencjonowania kodu przekazanego z powrotem do projektu. Można wywnioskować, że jakikolwiek wkład jest objęty GPL, ponieważ można go uznać za dzieło pochodne, a zatem musi być licencjonowany na licencji GPL, ale możliwe jest, że wkład jest już licencjonowany na podstawie niezgodnej licencji i nie można go łączyć z kodem GPL .

O ile mi wiadomo, jedyną licencją, która wyraźnie wspomina o licencjonowaniu kodu, jest Licencja Apache (patrz „Wkłady” i „Zgłaszanie wkładów ”).

To powiedziawszy, ogólnie dobrą praktyką jest, aby wszyscy uczestnicy projektu Open Source jawnie przypisywali prawa autorskie do swoich wkładów do projektu. Formularz przydziału zawiera również tekst, który potwierdza, że ​​autor jest właścicielem praw autorskich do wkładu i / lub jest upoważniony do przeniesienia praw autorskich.

Uwzględniając drugą część, projekt zyskuje pewną ochronę, gdy okaże się, że ktoś przekazał kod, do którego tworzenia nie został prawnie dopuszczony (np. Skopiował własny kod od swojego pracodawcy).

Innym ogólnym ryzykiem braku przeniesienia praw autorskich jest to, że jeśli w przyszłości chcesz zmienić licencję, nie możesz bez zgody wszystkich autorów, którzy posiadają prawa autorskie do ich wkładu. Na przykład, jeśli chcesz zmienić licencję z GPLv2 na LGPLv2, nie możesz bez pozwolenia.


1
Absolutnie poprawne. W rzeczywistości duże projekty Fundacji Wolnego Oprogramowania same w sobie wymagają od autorów przypisania praw autorskich do projektu. Jeśli twórcy GPL uważają to za konieczne, reszta z nas powinna zwrócić uwagę.
Ross Patterson

1
@RossPatterson Zrozumiałem, że głównym powodem, dla którego projekt GNU wymaga przeniesienia praw autorskich, jest to, że tylko właściciel praw autorskich może wnieść pozew o naruszenie: „ ...enforcement of copyright is generally not possible for distributors: only the copyright holder or someone having assignment of the copyright can enforce the license.” (Nie oznacza to, że wszystkie inne punkty tej odpowiedzi nie są również w pełni poprawne, ja właśnie zauważyłem, że nie jest tu uwzględniony jako jedna z głównych zalet przypisywania praw autorskich.)
apsillers

@apsillers Właściciele praw autorskich mają różne prawa, z których jednym jest pozwanie ich. Subtelniejsze jest to, że bez przypisania do projektu, prawa autorskie należą do autora, kropka. W przypadku FSF oznacza to, że jeśli zespół GCC chciałby zrobić coś „interesującego” z prawnego punktu widzenia, musiałby zaangażować również wszystkich nieprzypisanych właścicieli praw autorskich, z których wielu może być tylko pseudonimami (np. Adresy e-mail, nie nazwiska).
Ross Patterson

4

BSD zezwala na utwory pochodne, które jako całość nie posiadają licencji BSD. Niebezpieczeństwo polega na tym, że nowy współautor (lub, naprawdę, każdy współautor) mógłby przesłać wkład kodu, a następnie twierdzić, że jego wkład nie był licencjonowany przez BSD. To, czy wystąpi to w sądzie, prawdopodobnie zależy w dużej mierze od dokładnych okoliczności przeniesienia - wyobraź sobie niejednoznaczny przypadek, w którym ktoś umieszcza łatkę na liście mailingowej i po prostu mówi: „Spójrz na tę fajną nową funkcję, którą napisałem!” bez wyraźnego przyznania go projektowi na podstawie licencji BSD. (Projekt, który wymaga podpisanych umów, odpowiedziałby: „Dziękujemy, ale zanim zaakceptujemy to w naszej bazie kodu, prosimy prawnie potwierdzić, że Twój wkład jest licencjonowany przez BSD”).

Projekt na licencji GPL jest mniej podatny na takie dwuznaczności. Odpowiednie prawne zęby w GPL znajdują się w sekcji 8 :

Nie możesz rozpowszechniać ani modyfikować utworu objętego programem, z wyjątkiem przypadków wyraźnie określonych w niniejszej Licencji. Wszelkie próby jej rozpowszechnienia lub modyfikacji są nieważne i automatycznie wygasają Twoje prawa wynikające z niniejszej Licencji ...

W moim przykładzie niejednoznacznego wkładu w GPL nie ma dwuznaczności. Zmodyfikowane dzieło jest z konieczności licencjonowane przez GPL, a współtwórca nie mógł opublikować swojej modyfikacji na liście mailingowej bez przyznania do niej praw GPL (ponieważ opublikowanie jego zmodyfikowanej wersji stanowi przeniesienie). Każda próba argumentowania w inny sposób wymaga od niego aktywnego twierdzenia, że ​​naruszał GPL, co oznacza, że ​​całkowicie traci prawa do projektu, a jego zmodyfikowana praca jest prawnie nieważna .

(Nie jestem prawnikiem, więc nie jestem pewien, czy zabezpieczenia GPL są wystarczające, aby chronić projekt przed uczestnikiem procesu, który nie dba o jakiekolwiek szkody prawne dla siebie, ale z pewnością wystarczy, aby odstraszyć większość zdrowych ludzi od pilnych działań prawnych).


@Craig ma właściwą odpowiedź - chodzi o prawo autorskie, a nie licencjonowanie.
Ross Patterson

Zmodyfikowane dzieło jest z konieczności licencjonowane przez GPL, a współtwórca nie mógł opublikować swojej modyfikacji na liście mailingowej bez przyznania praw GPL (ponieważ opublikowanie jego zmodyfikowanej wersji stanowi przeniesienie). ” To jest dyskusyjne. Na początku Wolnego Oprogramowania kilka dużych i ważnych projektów twierdziło, że poprawki do ich kodu nie były dziełami pochodnymi, chyba że faktycznie zawierały oryginalny kod ( tzn. Dozwolone były tylko różnice w zerowym kontekście).
Ross Patterson
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.