Powszechna Licencja Publiczna GNU

Powszechna Licencja Publiczna GNU
GPLv3 Logo.svg
Autor Richarda Stallmana
Ostatnia wersja 3
Wydawca Fundacja Wolnego Oprogramowania
Opublikowany 25 lutego 1989 ; 33 lata temu ( 1989-02-25 )
identyfikator SPDX
  • GPL-3.0-lub nowsza
  • Tylko GPL-3.0
  • GPL-2.0-lub nowsza
  • Tylko GPL-2.0
  • GPL-1.0-lub nowsza
  • Tylko GPL-1.0
Kompatybilny z Debianem FSG Tak
Zatwierdzony przez FSF Tak
Zatwierdzony przez OSI Tak
Copyleft Tak Binarne lub oparte na kompilacji
Łączenie z kodu z inną licencją Oprogramowanie licencjonowane wyłącznie na podstawie licencji zgodnych z GPL, w zależności od używanej wersji.
Strona internetowa www.gnu.org/licenses/gpl.html _ _ _ _ _ Edit this at Wikidata

Powszechna Licencja Publiczna GNU ( GNU GPL lub po prostu GPL ) to seria powszechnie używanych licencji wolnego oprogramowania , które gwarantują użytkownikom końcowym cztery swobody uruchamiania, studiowania, udostępniania i modyfikowania oprogramowania. Licencja była pierwszą licencją typu copyleft do ogólnego użytku i została pierwotnie napisana przez założyciela Fundacji Wolnego Oprogramowania (FSF), Richarda Stallmana , dla Projektu GNU . Licencja przyznaje odbiorcom programu komputerowego prawa definicji wolnego oprogramowania . Wszystkie te serie GPL są licencjami typu copyleft, co oznacza, że ​​wszelkie prace pochodne muszą być rozpowszechniane na tych samych lub równoważnych warunkach licencyjnych. Jest bardziej restrykcyjna niż Mniejsza Powszechna Licencja Publiczna i jeszcze bardziej różni się od szerzej stosowanych licencji liberalnych na oprogramowanie BSD , MIT i Apache .

W przeszłości rodzina licencji GPL była jedną z najpopularniejszych licencji na oprogramowanie w domenie wolnego i otwartego oprogramowania . Wybitne wolne programy na licencji GPL obejmują jądro Linuksa i GNU Compiler Collection (GCC). David A. Wheeler argumentuje, że copyleft zapewnione przez GPL było kluczowe dla sukcesu Linuksie , dając programistom, którzy przyczynili się do powstania jądra, pewność, że ich praca przyniesie korzyści całemu światu i pozostanie wolna, a nie zostanie wykorzystana przez firmy programistyczne, które nie musiałyby nic oddawać społeczności.

W 2007 roku została wydana trzecia wersja licencji (GPLv3), aby rozwiązać niektóre problemy z drugą wersją (GPLv2), które zostały odkryte podczas jej długotrwałego użytkowania.

Aby licencja była aktualna, licencja GPL zawiera opcjonalną klauzulę „dowolna późniejsza wersja”, umożliwiającą użytkownikom wybór między oryginalnymi warunkami a warunkami w nowych wersjach zaktualizowanych przez FSF. Projekty oprogramowania objęte licencją z opcjonalną klauzulą ​​„lub późniejszą” obejmują Projekt GNU, podczas gdy na przykład jądro Linuksa jest objęte licencją wyłącznie na licencji GPLv2.

Klauzula „lub dowolnej późniejszej wersji” jest czasami nazywana klauzulą ​​łodzi ratunkowej, ponieważ umożliwia kombinacje różnych wersji oprogramowania licencjonowanego GPL w celu zachowania zgodności.

Historia

Licencja GPL została napisana przez Richarda Stallmana w 1989 roku do użytku z programami wydanymi w ramach projektu GNU. Oryginalna licencja GPL była oparta na ujednoliceniu podobnych licencji używanych we wczesnych wersjach GNU Emacs (1985), GNU Debugger i GNU C Compiler . Licencje te zawierały podobne postanowienia do współczesnej GPL, ale były specyficzne dla każdego programu, co czyniło je niekompatybilnymi, mimo że były tą samą licencją. Celem Stallmana było stworzenie jednej licencji, której można by użyć w dowolnym projekcie, umożliwiając w ten sposób współdzielenie kodu wielu projektom.

Druga wersja licencji, wersja 2, została wydana w 1991 roku. W ciągu następnych 15 lat członkowie społeczności wolnego oprogramowania zaniepokoili się problemami z licencją GPLv2, które mogły pozwolić komuś na wykorzystanie oprogramowania na licencji GPL w sposób sprzeczny z warunkami licencji. zamiar. Problemy te obejmowały tivoizację (włączenie oprogramowania na licencji GPL do sprzętu, który odmawia uruchamiania zmodyfikowanych wersji swojego oprogramowania), problemy ze zgodnością podobne do tych z Powszechnej Licencji Publicznej Affero oraz umowy patentowe między Microsoft a dystrybutorami wolnego i otwartego oprogramowania oprogramowanie, które niektórzy postrzegali jako próbę użycia patentów jako broni przeciwko społeczności wolnego oprogramowania.

Wersja 3 została opracowana w celu rozwiązania tych problemów i została oficjalnie wydana 29 czerwca 2007 r.

Wersja 1

Powszechna Licencja Publiczna GNU, wersja 1
Opublikowany 25 lutego 1989
Strona internetowa www.gnu.org/licenses/old-licenses/gpl-1.0.html _ _ _ _ _ _ _

Wersja 1 licencji GNU GPL, wydana 25 lutego 1989 r., zapobiegła dwóm wówczas głównym sposobom, w jakie dystrybutorzy oprogramowania ograniczali swobody definiujące wolne oprogramowanie. Pierwszym problemem było to, że dystrybutorzy mogą publikować pliki binarne — wykonywalne, ale nieczytelne ani modyfikowalne przez ludzi. Aby temu zapobiec, GPLv1 stwierdził, że kopiowanie i rozpowszechnianie kopii lub dowolnej części programu musi również udostępniać czytelny dla człowieka kod źródłowy na tych samych warunkach licencyjnych.

Drugi problem polegał na tym, że dystrybutorzy mogli dodawać ograniczenia, albo do licencji, albo łącząc oprogramowanie z innym oprogramowaniem, które miało inne ograniczenia dotyczące dystrybucji. Połączenie dwóch zestawów ograniczeń miałoby zastosowanie do połączonej pracy, dodając w ten sposób niedopuszczalne ograniczenia. Aby temu zapobiec, GPLv1 stwierdził, że zmodyfikowane wersje jako całość muszą być rozpowszechniane zgodnie z warunkami GPLv1. Dlatego oprogramowanie rozpowszechniane na warunkach GPLv1 mogłoby być łączone z oprogramowaniem na bardziej liberalnych warunkach, ponieważ nie zmieniałoby to warunków, na jakich całość mogłaby być rozpowszechniana. Jednak oprogramowania rozpowszechnianego na licencji GPLv1 nie można łączyć z oprogramowaniem rozpowszechnianym na bardziej restrykcyjnej licencji, ponieważ byłoby to sprzeczne z wymogiem, aby całość była dystrybuowana na warunkach GPLv1.

Wersja 2

Powszechna Licencja Publiczna GNU, wersja 2
Opublikowany czerwiec 1991
Strona internetowa www.gnu.org/licenses/old-licenses/gpl-2.0.html _ _ _ _ _ _ _

Według Richarda Stallmana główną zmianą w GPLv2 była klauzula „Wolność albo śmierć”, jak ją nazywa – sekcja 7. Sekcja mówi, że licencjobiorcy mogą rozpowszechniać dzieło objęte licencją GPL tylko wtedy, gdy są w stanie spełnić wszystkie zobowiązania wynikające z licencji , pomimo wszelkich innych zobowiązań prawnych, jakie mogą mieć. Innymi słowy, obowiązki wynikające z licencji nie mogą zostać rozdzielone z powodu sprzecznych zobowiązań. Postanowienie to ma na celu zniechęcenie jakiejkolwiek strony do korzystania z o naruszenie patentu lub innego postępowania sądowego w celu ograniczenia wolności użytkowników wynikającej z licencji.

W 1990 roku stało się jasne, że mniej restrykcyjna licencja byłaby strategicznie użyteczna dla biblioteki C i bibliotek oprogramowania, które zasadniczo wykonywały zadanie istniejących własnościowych; kiedy wersja 2 GPL (GPLv2) została wydana w czerwcu 1991 r., w związku z tym w tym samym czasie wprowadzono drugą licencję – GNU Library General Public License – i oznaczono ją numerem wersji 2, aby pokazać, że obie są komplementarne. Numery wersji rozeszły się w 1999 roku, kiedy wydano wersję 2.1 LGPL, która zmieniła jej nazwę na GNU Lesser General Public License, aby odzwierciedlić jej miejsce w filozofii. GPLv2 została również zmodyfikowana, aby odnosiła się do nowej nazwy LGPL, ale jej numer wersji pozostał taki sam, w wyniku czego oryginalna GPLv2 nie została rozpoznana przez Software Package Data Exchange (SPDX). [ nieudana weryfikacja ]

Licencja zawiera instrukcje, aby określić „wersję 2 Licencji lub (według własnego uznania) dowolną późniejszą wersję”, aby umożliwić elastyczne opcjonalne korzystanie z wersji 2 lub 3, ale niektórzy programiści zmieniają to, aby określić tylko „wersję 2”.

Wersja 3

Powszechna Licencja Publiczna GNU, wersja 3
Opublikowany 29 czerwca 2007
Strona internetowa www.gnu.org/licenses/gpl-3.0.html _ _ _ _ _ _

Pod koniec 2005 roku Free Software Foundation (FSF) ogłosiła prace nad trzecią wersją licencji GPL (GPLv3). 16 stycznia 2006 r. Opublikowano pierwszy „szkic do dyskusji” GPLv3 i rozpoczęły się konsultacje społeczne. Konsultacje społeczne były pierwotnie zaplanowane na dziewięć do piętnastu miesięcy, ale ostatecznie przedłużyły się do osiemnastu miesięcy i opublikowano cztery projekty. Oficjalna GPLv3 została wydana przez FSF 29 czerwca 2007 r. GPLv3 została napisana przez Richarda Stallmana we współpracy z radcą prawnym Ebenem Moglenem i Richardem Fontaną z Software Freedom Law Center .

Według Stallmana najważniejsze zmiany dotyczyły patentów na oprogramowanie , zgodności licencji wolnego oprogramowania , definicji „kodu źródłowego” oraz ograniczeń sprzętowych dotyczących modyfikacji oprogramowania, takich jak tivoizacja . Inne zmiany dotyczyły internacjonalizacji, sposobu obsługi naruszeń licencji oraz sposobu udzielania dodatkowych uprawnień przez właściciela praw autorskich. Pojęcie „rozpowszechniania oprogramowania”, jako określenie kopiowania i powielania oprogramowania, zostało wyraźnie zdefiniowane.

Proces konsultacji publicznych był koordynowany przez Free Software Foundation przy pomocy Software Freedom Law Center, Free Software Foundation Europe i innych grup wolnego oprogramowania. Komentarze zostały zebrane od opinii publicznej za pośrednictwem portalu internetowego gplv3.fsf.org, przy użyciu specjalnie napisanego oprogramowania o nazwie stet .

W trakcie procesu konsultacji społecznych do pierwszego projektu zgłoszono 962 uwagi. Do końca okresu zgłaszania uwag zgłoszono łącznie 2636 komentarzy.

Trzeci projekt został wydany 28 marca 2007 r. Ten projekt zawierał język mający na celu zapobieganie porozumieniom związanym z patentami, takim jak kontrowersyjna umowa patentowa Microsoft-Novell , i ograniczał klauzule anty-tivoizacyjne do prawnej definicji „użytkownika” i „ produkt konsumpcyjny”. Wyraźnie usunięto również sekcję „Ograniczenia geograficzne”, której prawdopodobne usunięcie zapowiedziano w momencie rozpoczęcia konsultacji społecznych.

Richard Stallman podczas premiery pierwszego szkicu GNU GPLv3 w MIT , Cambridge, Massachusetts, Stany Zjednoczone. Po jego prawej stronie siedzi profesor prawa Columbia, Eben Moglen , przewodniczący Software Freedom Law Center.

Czwarty szkic do dyskusji, który był ostatnim, został wydany 31 maja 2007 r. Wprowadził kompatybilność z licencją Apache w wersji 2.0 (poprzednie wersje są niekompatybilne), wyjaśnił rolę zewnętrznych wykonawców i zrobił wyjątek, aby uniknąć postrzeganych problemów z Microsoft- Umowa w stylu Novella, mówiąca w sekcji 11 ust. 6, że:

  Nie możesz przekazywać utworu objętego umową, jeśli jesteś stroną umowy ze stroną trzecią, która zajmuje się dystrybucją oprogramowania, w ramach której dokonujesz płatności na rzecz strony trzeciej na podstawie zakresu swojej działalności polegającej na przekazywaniu pracy, oraz na mocy którego strona trzecia udziela którejkolwiek ze stron, która otrzyma od ciebie dzieło objęte licencją, dyskryminującą licencję patentową ...

Miało to na celu uczynienie przyszłych takich transakcji nieskutecznymi. Licencja miała również spowodować, że Microsoft rozszerzy licencje patentowe udzielone klientom Novell na korzystanie z oprogramowania GPLv3 na wszystkich użytkowników tego oprogramowania GPLv3; było to możliwe tylko wtedy, gdy Microsoft był legalnie „przekaźnikiem” oprogramowania GPLv3.

Wczesne wersje robocze GPLv3 pozwalały również licencjodawcom na dodanie wymagania podobnego do Affero , które zatkałoby lukę ASP w GPL . Ponieważ wyrażano obawy co do kosztów administracyjnych sprawdzania kodu pod kątem tego dodatkowego wymogu, zdecydowano o oddzieleniu licencji GPL i Affero.

Inni, w szczególności znani twórcy jądra Linuksa , tacy jak Linus Torvalds , Greg Kroah-Hartman i Andrew Morton , wypowiadali się w środkach masowego przekazu i składali publiczne oświadczenia o swoich zastrzeżeniach do części omawianych wersji roboczych 1 i 2. Twórcy jądra odwoływali się do Projekt klauzul GPLv3 dotyczących DRM / Tivoization , patentów i „dodatkowych ograniczeń” oraz ostrzegał przed bałkanizacją „wszechświata Open Source”. Linus Torvalds, który zdecydował się nie przyjmować GPLv3 dla jądra Linuksa, powtórzył swoją krytykę kilka lat później.

GPLv3 poprawiła kompatybilność z kilkoma licencjami wolnego oprogramowania, takimi jak licencja Apache w wersji 2.0 i GNU Affero General Public License, z którymi GPLv2 nie można było łączyć. Jednak oprogramowanie GPLv3 można było łączyć i udostępniać kod z oprogramowaniem GPLv2 tylko wtedy, gdy używana licencja GPLv2 zawierała opcjonalną klauzulę „lub nowszą”, a oprogramowanie zostało zaktualizowane do GPLv3. Podczas gdy klauzula „GPLv2 lub dowolna nowsza wersja” jest uważana przez FSF za najpowszechniejszą formę licencjonowania oprogramowania GPLv2, Toybox , Rob Landley, opisał ją jako klauzulę łodzi ratunkowej . Projekty oprogramowania objęte licencją z opcjonalną klauzulą ​​„lub nowszą” obejmują Projekt GNU , [ potrzebne źródło ] , podczas gdy wyróżniającym się przykładem bez klauzuli jest jądro Linuksa.

Ostateczna wersja tekstu licencji została opublikowana 29 czerwca 2007 r.

Regulamin

Warunki GPL muszą być udostępnione każdemu, kto otrzymuje kopię dzieła, do którego zastosowano GPL („licencjobiorcy”). Każdy licencjobiorca, który przestrzega warunków, otrzymuje pozwolenie na modyfikację dzieła, a także na kopiowanie i redystrybucję dzieła lub dowolnej wersji pochodnej. Licencjobiorca może pobierać opłatę za tę usługę lub wykonywać ją nieodpłatnie. Ten ostatni punkt odróżnia GPL od licencji na oprogramowanie, które zabraniają komercyjnej redystrybucji. FSF argumentuje, że wolne oprogramowanie nie powinno nakładać ograniczeń na komercyjne wykorzystanie, a GPL wyraźnie stwierdza, że ​​dzieła GPL mogą być sprzedawane za każdą cenę.

GPL dodatkowo stanowi, że dystrybutor nie może nakładać „dalszych ograniczeń praw przyznanych przez GPL”. Zabrania to takich działań, jak dystrybucja oprogramowania w ramach umowy lub umowy o zachowaniu poufności.

Czwarta sekcja dla wersji 2 licencji i siódma sekcja dla wersji 3 wymagają, aby programom rozpowszechnianym jako prekompilowane pliki binarne towarzyszyła kopia kodu źródłowego, pisemna oferta rozpowszechniania kodu źródłowego za pomocą tego samego mechanizmu co wersja przed -skompilowany plik binarny lub pisemna oferta uzyskania kodu źródłowego, którą użytkownik otrzymał, gdy otrzymał wstępnie skompilowany plik binarny na licencji GPL. Sekcja druga wersji 2 i sekcja piąta wersji 3 wymagają również przekazania „wszystkim odbiorcom kopii niniejszej Licencji wraz z Programem”. Wersja 3 licencji umożliwia udostępnianie kodu źródłowego na dodatkowe sposoby w ramach realizacji punktu siódmego. Obejmują one pobieranie kodu źródłowego z sąsiedniego serwera sieciowego lub transmisję peer-to-peer, pod warunkiem, że w taki sposób skompilowany kod był dostępny i istnieją „jasne wskazówki”, gdzie znaleźć kod źródłowy.

FSF nie posiada praw autorskich do dzieła wydanego na licencji GPL, chyba że autor wyraźnie przeniesie prawa autorskie na FSF (co zdarza się rzadko, z wyjątkiem programów będących częścią projektu GNU). Tylko poszczególni posiadacze praw autorskich mają prawo wnosić pozew w przypadku podejrzenia naruszenia licencji.

Drukowane oświadczenia GPL dotyczące konsumenckich urządzeń rozrywkowych, które zawierają komponenty GPL

Korzystanie z licencjonowanego oprogramowania

Oprogramowanie na licencji GPL może być uruchamiane do wszystkich celów, w tym do celów komercyjnych, a nawet jako narzędzie do tworzenia oprogramowania własnościowego , na przykład przy użyciu kompilatorów na licencji GPL . Użytkownicy lub firmy, które rozpowszechniają dzieła na licencji GPL (np. oprogramowanie), mogą pobierać opłaty za kopie lub udostępniać je bezpłatnie. To odróżnia GPL od shareware , które zezwalają na kopiowanie do użytku osobistego, ale zabraniają komercyjnej dystrybucji lub licencji własnościowych, w których kopiowanie jest zabronione przez prawo autorskie . FSF argumentuje, że szanujące wolność wolne oprogramowanie nie powinno również ograniczać komercyjnego wykorzystania i dystrybucji (w tym redystrybucji):

W przypadku użytku czysto prywatnego (lub wewnętrznego) — bez sprzedaży i dystrybucji — kod oprogramowania może być modyfikowany, a części ponownie wykorzystywane bez konieczności udostępniania kodu źródłowego. W celu sprzedaży lub dystrybucji cały kod źródłowy musi być udostępniony użytkownikom końcowym, w tym wszelkie zmiany i dodatki w kodzie – w takim przypadku stosuje się copyleft, aby zapewnić użytkownikom końcowym zachowanie określonych powyżej swobód.

Jednak oprogramowanie działające jako program użytkowy w systemie operacyjnym objętym licencją GPL, takim jak Linux, nie musi być objęte licencją GPL ani być rozpowszechniane z dostępnością kodu źródłowego — licencjonowanie zależy wyłącznie od używanych bibliotek i komponentów oprogramowania, a nie od platformę bazową. Na przykład, jeśli program składa się wyłącznie z oryginalnego kodu źródłowego lub jest połączony z kodem źródłowym z innych składników oprogramowania , wówczas niestandardowe składniki oprogramowania nie muszą być objęte licencją GPL i nie muszą udostępniać swojego kodu źródłowego; nawet jeśli używany system operacyjny jest objęty licencją GPL, działające na nim aplikacje nie są uważane za dzieła pochodne. Tylko jeśli w programie używane są części objęte GPL (a program jest rozpowszechniany), cały inny kod źródłowy programu musi być udostępniony na tych samych warunkach licencyjnych. Mniejsza powszechna licencja publiczna GNU (LGPL) została stworzona, aby mieć słabsze prawa autorskie niż GPL, ponieważ nie wymaga udostępniania niestandardowego kodu źródłowego (różnego od części LGPL) na tych samych warunkach licencji.

Piąta sekcja wersji 3 stanowi, że żaden kod objęty licencją GPL nie może być uważany za skuteczny „techniczny środek ochrony” zgodnie z definicją zawartą w artykule 11 Traktatu WIPO o prawie autorskim oraz że ci, którzy przekazują dzieło, zrzekają się wszelkich uprawnień prawnych do zakazania obchodzenia techniczny środek ochrony „w zakresie, w jakim takie obejście jest realizowane poprzez wykonywanie praw wynikających z niniejszej Licencji w odniesieniu do utworu objętego licencją”. Oznacza to, że użytkownicy nie mogą zostać pociągnięci do odpowiedzialności za obejście DRM zaimplementowanego przy użyciu kodu na licencji GPLv3 zgodnie z przepisami takimi jak amerykańska ustawa Digital Millennium Copyright Act (DMCA).

Copyleft

Prawa dystrybucji przyznane przez GPL dla zmodyfikowanych wersji dzieła nie są bezwarunkowe. Kiedy ktoś rozpowszechnia dzieło na licencji GPL plus własne modyfikacje, wymagania dotyczące rozpowszechniania całej pracy nie mogą być większe niż wymagania na licencji GPL.

Ten wymóg jest znany jako copyleft. Swoją moc prawną czerpie z korzystania z praw autorskich do programów. Ponieważ dzieło GPL jest chronione prawami autorskimi, licencjobiorca nie ma prawa do jego redystrybucji, nawet w zmodyfikowanej formie (z wyjątkiem dozwolonego użytku ), z wyjątkiem warunków licencji. Przestrzeganie warunków licencji GPL jest wymagane tylko wtedy, gdy chce się korzystać z praw normalnie ograniczonych prawem autorskim, takich jak redystrybucja. I odwrotnie, jeśli ktoś rozpowszechnia kopie dzieła bez przestrzegania warunków licencji GPL (na przykład utrzymując kod źródłowy w tajemnicy), może zostać pozwany przez pierwotnego autora na mocy prawa autorskiego.

Prawo autorskie było w przeszłości stosowane w celu zapobiegania rozpowszechnianiu dzieła przez osoby nieupoważnione przez twórcę. Copyleft używa tych samych praw autorskich do osiągnięcia zupełnie innego celu. Przyznaje prawa do dystrybucji wszystkim stronom, o ile zapewniają one te same prawa kolejnym, a one następnym itd. W ten sposób GPL i inne licencje typu copyleft próbują wymusić swobodny dostęp do dzieła i wszystkich pochodnych.

Wielu dystrybutorów programów na licencji GPL łączy kod źródłowy z plikami wykonywalnymi . Alternatywną metodą realizacji copyleft jest złożenie na żądanie pisemnej oferty dostarczenia kodu źródłowego na nośniku fizycznym (takim jak płyta CD). W praktyce wiele programów na licencji GPL jest rozpowszechnianych przez Internet, a kod źródłowy jest udostępniany przez FTP lub HTTP . W przypadku dystrybucji internetowej jest to zgodne z licencją.

Copyleft ma zastosowanie tylko wtedy, gdy osoba chce redystrybuować program. Deweloperzy mogą tworzyć prywatne zmodyfikowane wersje bez obowiązku ujawniania modyfikacji, o ile nie rozpowszechniają zmodyfikowanego oprogramowania nikomu innemu. Copyleft dotyczy tylko oprogramowania, a nie jego danych wyjściowych (chyba że dane wyjściowe same w sobie są dziełem pochodnym programu). Na przykład publiczny portal internetowy, na którym działa zmodyfikowana pochodna systemu zarządzania treścią na licencji GPL, nie musi rozpowszechniać swoich zmian w oprogramowaniu bazowym, ponieważ zmodyfikowany portal internetowy nie jest redystrybuowany, ale raczej hostowany, a także dlatego, że portal internetowy dane wyjściowe nie są również dziełem pochodnym systemu zarządzania treścią na licencji GPL.

zaciemnionej formie jest naruszeniem GPL , na przykład w przypadkach, w których autor jest mniej chętny do udostępnienia kodu źródłowego. Konsensus był taki, że chociaż nieetyczne, nie zostało to uznane za naruszenie. Problem został wyjaśniony, gdy licencja została zmieniona w wersji 2, aby wymagać udostępnienia „preferowanej” wersji kodu źródłowego.

Licencja kontra umowa

GPL została zaprojektowana jako licencja , a nie umowa. W niektórych prawa zwyczajowego prawne rozróżnienie między licencją a umową jest ważne: umowy są wykonalne na mocy prawa umów , podczas gdy licencje są egzekwowane na mocy prawa autorskiego . Jednak to rozróżnienie nie jest przydatne w wielu jurysdykcjach, w których nie ma różnic między umowami a licencjami, takich jak systemy prawa cywilnego .

Ci, którzy nie akceptują warunków GPL, nie mają pozwolenia, zgodnie z prawem autorskim, na kopiowanie lub dystrybucję oprogramowania na licencji GPL lub dzieł pochodnych. Jeśli jednak nie będą redystrybuować programu objętego licencją GPL, mogą nadal używać oprogramowania w ramach swojej organizacji, jak im się podoba, a prace (w tym programy) utworzone przy użyciu programu nie muszą być objęte tą licencją.

Twórca oprogramowania Allison Randal argumentował, że licencja GPLv3 jest niepotrzebnie myląca dla laików i mogłaby zostać uproszczona przy zachowaniu tych samych warunków i mocy prawnej.

W kwietniu 2017 roku amerykański sąd federalny orzekł, że licencja typu open source jest wykonalną umową.

W październiku 2021 r. SFC pozwał Vizio za naruszenie umowy jako użytkownika końcowego w celu zażądania kodu źródłowego do telewizorów Vizio. W międzyczasie sędzia federalny orzekł, że GPL jest wykonalną umową użytkowników końcowych, a także licencją dla właścicieli praw autorskich.

pochodne

Sam tekst licencji GPL jest chroniony prawami autorskimi , a prawa autorskie należą do Fundacji Wolnego Oprogramowania.

FSF zezwala ludziom na tworzenie nowych licencji opartych na GPL, o ile licencje pochodne nie używają preambuły GPL bez pozwolenia. Jest to jednak odradzane, ponieważ taka licencja może być niezgodna z GPL i powodować postrzegane rozpowszechnianie licencji .

Inne licencje utworzone w ramach projektu GNU obejmują GNU Lesser General Public License , GNU Free Documentation License oraz Affero General Public License .

Tekst licencji GPL sam w sobie nie jest objęty licencją GPL. Prawa autorskie do licencji zabraniają modyfikacji licencji. Kopiowanie i rozpowszechnianie licencji jest dozwolone, ponieważ GPL wymaga od odbiorców otrzymania „kopii niniejszej Licencji wraz z Programem”. Zgodnie z często zadawanymi pytaniami GPL, każdy może sporządzić nową licencję, używając zmodyfikowanej wersji GPL, o ile używa innej nazwy licencji, nie wymienia „GNU” i usuwa preambułę, chociaż preambuła może być używana w zmodyfikowaną licencję, jeśli uzyskano pozwolenie na jej używanie od Fundacji Wolnego Oprogramowania (FSF).

Łączenie i prace pochodne

Biblioteki

Według FSF „GPL nie wymaga wydania zmodyfikowanej wersji ani żadnej jej części. Możesz swobodnie wprowadzać modyfikacje i używać ich prywatnie, nigdy ich nie publikując”. Jeśli jednak udostępni się publicznie podmiot objęty licencją GPL, pojawia się problem dotyczący łączenia: a mianowicie, czy zastrzeżony program korzystający z biblioteki GPL narusza GPL.

Ten kluczowy spór dotyczy tego, czy oprogramowanie inne niż GPL może legalnie łączyć się statycznie lub dynamicznie z bibliotekami GPL. Istnieją różne opinie w tej kwestii. Licencja GPL jasno wymaga, aby wszystkie pochodne kody na licencji GPL same podlegały licencji GPL. Pojawia się niejednoznaczność w odniesieniu do korzystania z bibliotek GPL i łączenia oprogramowania GPL w większy pakiet (być może zmieszany w plik binarny poprzez łączenie statyczne). Ostatecznie nie jest to kwestia samej licencji GPL , ale tego, jak prawo autorskie definiuje dzieła pochodne. Istnieją następujące punkty widzenia:

Punkt widzenia: linkowanie dynamiczne i statyczne narusza GPL

Fundacja Wolnego Oprogramowania (która posiada prawa autorskie do kilku znaczących produktów oprogramowania na licencji GPL oraz do samego tekstu licencji) twierdzi, że plik wykonywalny korzystający z dynamicznie połączonej biblioteki jest rzeczywiście dziełem pochodnym. Nie dotyczy to jednak oddzielnych programów komunikujących się ze sobą.

Fundacja Wolnego Oprogramowania stworzyła również LGPL , która jest prawie identyczna z GPL, ale z dodatkowymi uprawnieniami umożliwiającymi łączenie w celu „korzystania z biblioteki”.

Richard Stallman i FSF szczególnie zachęcają twórców bibliotek do udzielania licencji na licencji GPL, aby programy prawnie zastrzeżone nie mogły korzystać z bibliotek, starając się chronić świat wolnego oprogramowania, dając mu więcej narzędzi niż świat prawnie zastrzeżony.

Punkt widzenia: linkowanie statyczne narusza GPL, ale niejasne, jak w przypadku linkowania dynamicznego

Niektórzy uważają, że chociaż statyczne linkowanie tworzy dzieła pochodne, nie jest jasne, czy plik wykonywalny, który dynamicznie łączy się z kodem GPL, powinien być uważany za dzieło pochodne (patrz słaby copyleft ). Linuksowy autor Linus Torvalds zgadza się, że dynamiczne łączenie może tworzyć prace pochodne, ale nie zgadza się co do okoliczności.

Prawnik firmy Novell napisał, że dynamiczne łączenie, które nie jest pochodną, ​​„ma sens”, ale nie jest „jednoznaczne”, a dowodem na to, że dynamiczne łączenie ma dobre intencje, jest istnienie zastrzeżonych sterowników jądra Linuksa.

W sprawie Galoob przeciwko Nintendo Dziewiąty Okręgowy Sąd Apelacyjny Stanów Zjednoczonych zdefiniował utwór pochodny jako mający formę” lub trwałość” i zauważył, że „dzieło naruszające prawo musi zawierać część dzieła chronionego prawem autorskim w jakiejś formie”, ale istnieją nie było jasnych orzeczeń sądowych w celu rozwiązania tego konkretnego konfliktu.

Punkt widzenia: łączenie nie ma znaczenia

Zgodnie z artykułem w Linux Journal , Lawrence Rosen (były radca prawny Open Source Initiative ) twierdzi, że metoda łączenia jest w większości nieistotna dla pytania, czy oprogramowanie jest dziełem pochodnym ; ważniejsze jest pytanie, czy oprogramowanie miało współpracować z oprogramowaniem klienckim i/lub bibliotekami. Stwierdza: „Głównym wskaźnikiem tego, czy nowy program jest dziełem pochodnym, jest to, czy kod źródłowy oryginalnego programu został użyty [w sensie kopiuj-wklej], zmodyfikowany, przetłumaczony lub w inny sposób zmieniony w celu stworzenia nowego programu Jeśli nie, to argumentowałbym, że nie jest to praca pochodna” i wymienia wiele innych punktów dotyczących intencji, łączenia i mechanizmu powiązań. Dalej argumentuje na stronie internetowej swojej firmy, że takie „rynkowe” czynniki są ważniejsze niż technika łączenia.

Istnieje również specyficzna kwestia, czy wtyczka lub moduł (taki jak moduły jądra karty graficznej NVidia lub ATI ) muszą być również na licencji GPL, jeśli można je rozsądnie uznać za własne dzieło. Ten punkt widzenia sugeruje, że rozsądnie oddzielne wtyczki lub wtyczki do oprogramowania przeznaczonego do korzystania z wtyczek mogą być licencjonowane na podstawie dowolnej licencji, jeśli dzieło jest na licencji GPLv2. Szczególnie interesujący jest akapit GPLv2:

  Możesz modyfikować swoją kopię lub kopie Programu lub dowolnej jego części, tworząc w ten sposób dzieło oparte na Programie, a także kopiować i rozpowszechniać takie modyfikacje lub pracę na warunkach określonych w sekcji 1 powyżej, pod warunkiem spełnienia wszystkich tych warunków : ...

  b) Musisz spowodować, aby wszelkie rozpowszechniane lub publikowane przez ciebie dzieło, które w całości lub w części zawiera Program lub jego część lub pochodzi od Programu, było w całości bezpłatnie licencjonowane dla wszystkich stron trzecich na warunkach niniejszej Licencji . ... Wymagania te dotyczą zmodyfikowanej pracy jako całości. Jeśli identyfikowalne sekcje tej pracy nie pochodzą z Programu i można je rozsądnie uznać za niezależne i oddzielne prace same w sobie, wówczas niniejsza Licencja i jej warunki nie mają zastosowania do tych sekcji, gdy rozpowszechniasz je jako oddzielne prace. Ale kiedy rozpowszechniasz te same sekcje jako część całości, która jest dziełem opartym na Programie, dystrybucja całości musi odbywać się na warunkach niniejszej Licencji, której zezwolenia dla innych licencjobiorców rozciągają się na całą całość, a tym samym na każdą i każdą część niezależnie od tego, kto ją napisał.

GPLv3 ma inną klauzulę:

  Możesz przekazać pracę opartą na Programie lub modyfikacje mające na celu wytworzenie jej z Programu, w formie kodu źródłowego na warunkach określonych w punkcie 4, pod warunkiem, że spełnisz również wszystkie poniższe warunki: ...

  c) Musisz udzielić licencji na całe dzieło, jako całość, na podstawie niniejszej Licencji każdemu, kto wejdzie w posiadanie kopii. Niniejsza Licencja będzie zatem miała zastosowanie, wraz z wszelkimi mającymi zastosowanie dodatkowymi warunkami Sekcji 7, do całości dzieła i wszystkich jego części, niezależnie od sposobu ich zapakowania. Niniejsza Licencja nie zezwala na udzielanie licencji na dzieło w żaden inny sposób, ale nie unieważnia takiego pozwolenia, jeśli otrzymałeś je oddzielnie. ... Kompilacja utworu objętego licencją z innymi odrębnymi i niezależnymi utworami, które ze swej natury nie są przedłużeniem utworu objętego licencją i które nie są z nim połączone w taki sposób, aby tworzyły większy program, w tomie lub na tomie nośnik do przechowywania lub dystrybucji nazywany jest „agregatem”, jeśli kompilacja i wynikające z niej prawa autorskie nie są wykorzystywane do ograniczania dostępu lub praw użytkowników kompilacji poza to, na co zezwalają poszczególne utwory. Włączenie utworu objętego licencją do agregatu nie powoduje, że niniejsza Licencja ma zastosowanie do innych części agregatu.

Jako studium przypadku, niektóre rzekomo zastrzeżone wtyczki i motywy / skórki dla oprogramowania GPLv2 CMS , takie jak Drupal i WordPress , znalazły się pod ostrzałem, przy czym obie strony argumentu zostały uwzględnione.

FSF rozróżnia sposób wywoływania wtyczki. Jeśli wtyczka jest wywoływana przez dynamiczne łączenie i wykonuje wywołania funkcji do programu GPL, najprawdopodobniej jest to praca pochodna.

Komunikacja i łączenie z programami innymi niż GPL

Sam akt komunikowania się z innymi programami sam w sobie nie wymaga, aby całe oprogramowanie było na licencji GPL; podobnie jak dystrybucja oprogramowania GPL z oprogramowaniem innym niż GPL. Należy jednak przestrzegać drobnych warunków, które zapewnią, że prawa oprogramowania GPL nie zostaną ograniczone. Poniżej znajduje się cytat z gnu.org GPL FAQ , który opisuje, w jakim stopniu oprogramowanie może komunikować się z programami GPL i być dołączane do nich:

Jaka jest różnica między „agregatami” a innymi rodzajami „zmodyfikowanych wersji”?

„Agregat” składa się z pewnej liczby oddzielnych programów, rozmieszczonych razem na tym samym dysku CD-ROM lub innym nośniku. Licencja GPL zezwala na tworzenie i dystrybucję agregatu, nawet jeśli licencje innego oprogramowania nie są wolne lub niezgodne z GPL. Jedynym warunkiem jest to, że nie można udostępnić agregatu na podstawie licencji, która zabrania użytkownikom korzystania z praw, które przyznałaby im indywidualna licencja każdego programu.

Gdzie przebiega granica między dwoma oddzielnymi programami a jednym programem składającym się z dwóch części? Jest to kwestia prawna, którą ostatecznie rozstrzygną sędziowie. Uważamy, że właściwe kryterium zależy zarówno od mechanizmu komunikacji (exec, potoki, rpc, wywołania funkcji w ramach współdzielonej przestrzeni adresowej itp.), jak i od semantyki komunikacji (jakiego rodzaju informacje są wymieniane).

Jeśli moduły są zawarte w tym samym pliku wykonywalnym, to na pewno są połączone w jeden program. Jeśli moduły są zaprojektowane do działania połączonego we wspólnej przestrzeni adresowej, prawie na pewno oznacza to połączenie ich w jeden program.

Natomiast potoki, gniazda i argumenty wiersza poleceń to mechanizmy komunikacji zwykle używane między dwoma oddzielnymi programami. Więc kiedy są używane do komunikacji, moduły są zwykle oddzielnymi programami. Ale jeśli semantyka komunikacji jest wystarczająco intymna, wymieniając złożone wewnętrzne struktury danych, to również może być podstawą do rozważenia połączenia tych dwóch części w większy program.

W ten sposób FSF wyznacza granicę między „biblioteką” a „innym programem” poprzez 1) „złożoność” i „intymność” wymiany informacji oraz 2) mechanizm (raczej niż semantykę), ale rezygnuje, że kwestia nie jest jednoznaczna i że w skomplikowanych sytuacjach rozstrzygać będzie orzecznictwo.

Status prawny

Pierwsze znane naruszenie GPL miało miejsce w 1989 roku, kiedy NeXT rozszerzył kompilator GCC , aby obsługiwał Objective-C , ale nie opublikował publicznie zmian. Po zapytaniu stworzyli publiczną łatkę . W związku z tym naruszeniem nie wniesiono żadnego pozwu.

W 2002 roku MySQL AB pozwał Progress NuSphere za naruszenie praw autorskich i znaków towarowych w sądzie okręgowym Stanów Zjednoczonych . NuSphere rzekomo naruszyło prawa autorskie MySQL, łącząc kod MySQL na licencji GPL z tabelą NuSphere Gemini bez przestrzegania licencji. Po wstępnej rozprawie przed sędzią Patti Saris w dniu 27 lutego 2002 r. strony rozpoczęły rozmowy ugodowe i ostatecznie zawarły ugodę. Po przesłuchaniu FSF skomentowało, że „sędzia Saris wyjaśniła, że ​​uważa GNU GPL za wykonalną i wiążącą licencję”.

W sierpniu 2003 roku SCO Group oświadczyła, że ​​wierzy, że GPL nie ma mocy prawnej i że zamierzają wszcząć procesy sądowe w związku z fragmentami kodu rzekomo skopiowanymi z SCO Unix do jądra Linuksa . Było to dla nich problematyczne stanowisko, ponieważ rozpowszechniali Linuksa i inny kod na licencji GPL w swojej Caldera OpenLinux i niewiele jest dowodów na to, że mieli do tego jakiekolwiek prawo, z wyjątkiem warunków GPL. [ potrzebne źródło ] W lutym 2018 r., po wydaniu wyroku federalnego sądu okręgowego, apelacji i (częściowym) przekazaniu sprawy do sądu okręgowego, strony ponownie przedstawiły swoje pozostałe roszczenia i przedstawiły plan zmierzający do wydania ostatecznego wyroku. Pozostałe roszczenia dotyczyły Projektu Monterey i zostały ostatecznie rozstrzygnięte w listopadzie 2021 roku przez IBM, który zapłacił 14,25 miliona dolarów syndykowi masy upadłościowej TSG (wcześniej SCO).

W kwietniu 2004 r. projekt netfilter / iptables otrzymał wstępny nakaz przeciwko Sitecom Germany przez Sąd Rejonowy w Monachium po tym, jak Sitecom odmówił zaprzestania dystrybucji oprogramowania Netfilter na licencji GPL z naruszeniem warunków licencji GPL. Haralda Welte z Netfilter reprezentował współzałożyciel ifrOSS , Till Jaeger. W lipcu 2004 r. niemiecki sąd potwierdził ten nakaz jako ostateczne orzeczenie przeciwko Sitecom. Uzasadnieniem sądu było to, że:

  Pozwany naruszył prawa autorskie powoda, oferując oprogramowanie „netfilter/iptables” do pobrania i reklamując jego dystrybucję, bez przestrzegania warunków licencji GPL. Wspomniane działania byłyby dopuszczalne tylko wtedy, gdyby pozwany miał przyznaną licencję. ... Jest to niezależne od pytań, czy warunki licencyjne GPL zostały skutecznie uzgodnione między powodem a pozwanym, czy nie. Gdyby GPL nie zostało uzgodnione przez strony, pozwany mimo to nie miałby niezbędnych praw do kopiowania, rozpowszechniania i publicznego udostępniania oprogramowania „netfilter/iptables”.

To dokładnie odzwierciedlało przewidywania podane wcześniej przez Ebena Moglena z FSF. To orzeczenie było ważne, ponieważ po raz pierwszy sąd potwierdził, że naruszenie warunków licencji GPL może stanowić naruszenie praw autorskich i ugruntowało orzecznictwo co do wykonalności licencji GPLv2 na mocy prawa niemieckiego.

W maju 2005 roku Daniel Wallace złożył pozew przeciwko Fundacji Wolnego Oprogramowania w południowym dystrykcie Indiany , twierdząc, że licencja GPL jest nielegalną próbą ustalenia cen (na poziomie zerowym). Pozew został oddalony w marcu 2006 r. Na tej podstawie, że Wallace nie przedstawił ważnego roszczenia antymonopolowego; sąd zauważył, że „GPL raczej zachęca niż zniechęca do wolnej konkurencji i dystrybucji komputerowych systemów operacyjnych, z których korzyści przechodzą bezpośrednio na konsumentów”. Wallace'owi odmówiono możliwości dalszego poprawiania swojej skargi i nakazano mu pokrycie kosztów prawnych FSF.

W dniu 8 września 2005 r. Centralny Sąd Rejonowy w Seulu orzekł, że licencja GPL nie ma znaczenia w sprawie dotyczącej tajemnic handlowych pochodzących z pracy na licencji GPL. Pozwani argumentowali, że skoro nie można zachować tajemnicy handlowej przy zachowaniu zgodności z licencją GPL i rozpowszechnianiu utworu, nie naruszają tajemnicy handlowej. Argument ten uznano za bezpodstawny.

W dniu 6 września 2006 r. Projekt gpl-violations.org zwyciężył w sporze sądowym przeciwko D-Link Germany GmbH w sprawie naruszającego prawa autorskie używania przez D-Link części jądra Linuksa w dystrybuowanych przez nich urządzeniach pamięci masowej . W orzeczeniu stwierdzono, że GPL jest ważna, prawnie wiążąca i obowiązuje w niemieckim sądzie.

Pod koniec 2007 roku programiści BusyBox i Software Freedom Law Center rozpoczęli program mający na celu uzyskanie zgodności z GPL od dystrybutorów BusyBox w systemach wbudowanych , pozywając tych, którzy się nie zgodzili. Twierdzono, że były to pierwsze zastosowania sądów w USA do egzekwowania zobowiązań GPL. (Zobacz pozwy BusyBox GPL ).

W dniu 11 grudnia 2008 r. Fundacja Wolnego Oprogramowania pozwała firmę Cisco Systems, Inc. za naruszenie praw autorskich przez jej oddział firmy Linksys do licencjonowanych przez FSF pakietów oprogramowania coreutils , readline , Parted , Wget , GNU Compiler Collection , binutils i GNU Debugger , które Firma Linksys dystrybuuje w systemie Linux oprogramowanie układowe swoich routerów bezprzewodowych WRT54G , a także wielu innych urządzeń, w tym modemów DSL i kablowych, urządzeń Network Attached Storage, bramek Voice-Over-IP, urządzeń wirtualnej sieci prywatnej oraz kina domowego/odtwarzacza multimedialnego.

Po sześciu latach powtarzających się skarg składanych do Cisco przez FSF, twierdzenia Cisco, że naprawią lub naprawiają swoje problemy ze zgodnością (niedostarczanie pełnych kopii całego kodu źródłowego i ich modyfikacji), wykryto i zgłoszono powtarzające się nowe naruszenia więcej produktów i brak działań ze strony Linksys (proces opisany na blogu FSF jako „trwająca od pięciu lat gra Whack-a-Mole”), FSF pozwała ich do sądu.

Cisco rozstrzygnęło sprawę sześć miesięcy później, zgadzając się „wyznaczyć Dyrektora ds. Wolnego Oprogramowania dla Linksys”, aby zapewnić zgodność, „powiadomić poprzednich odbiorców produktów Linksys zawierających programy FSF o ich prawach wynikających z licencji GPL”, swobodnie udostępniać kod źródłowy programów FSF dostępnych na swojej stronie internetowej oraz do wniesienia wkładu pieniężnego na rzecz FSF.

W 2011 roku zauważono, że GNU Emacs przez dwa lata przypadkowo wypuszczał niektóre pliki binarne bez odpowiedniego kodu źródłowego, wbrew zamierzonemu duchowi GPL, co skutkowało naruszeniem praw autorskich . Richard Stallman opisał ten incydent jako „bardzo poważny błąd”, który został natychmiast naprawiony. FSF nie pozwała żadnych dalszych redystrybutorów, którzy również nieświadomie naruszyli GPL poprzez dystrybucję tych plików binarnych.

W 2017 roku Artifex, twórca Ghostscript , pozwał firmę Hancom , twórcę pakietu biurowego zawierającego Ghostscript. Artifex oferuje dwie licencje na Ghostscript; jedna to licencja Affero GPL, a druga to licencja komercyjna. Hancom nie nabył licencji komercyjnej od Artifex ani nie udostępnił swojego pakietu biurowego jako wolnego oprogramowania. Artifex pozwał Hancom do Sądu Okręgowego Stanów Zjednoczonych i złożył dwa pozwy. Po pierwsze, użycie Ghostscript przez firmę Hancom stanowiło naruszenie praw autorskich; a po drugie, użycie Ghostscript przez Hancom było naruszeniem licencji. Sędzia Jacqueline Scott Corley stwierdziła, że ​​licencja GPL była wykonalną umową, a firma Hancom naruszyła umowę.

Stockfish o otwartym kodzie źródłowym pozwali ChessBase , twórcę oprogramowania szachowego, za naruszenie licencji GPLv3. Twierdzono, że Chessbase dokonał tylko niewielkich modyfikacji kodu Sztokfisza i sprzedał swoim klientom nowe silniki (Fat Fritz 2 i Houdini 6). Dodatkowo Fat Fritz 2 był sprzedawany tak, jakby był innowacyjnym silnikiem. ChessBase naruszyło warunki licencji, nie rozpowszechniając tych produktów jako Wolnego Oprogramowania zgodnie z licencją GPL.

Rok później, 7 listopada 2022 roku, obie strony doszły do ​​porozumienia i zakończyły spór. W najbliższym czasie ChessBase nie będzie już sprzedawać produktów zawierających kod Stockfish, informując o tym swoich klientów stosownym komunikatem na swoich stronach internetowych. Jednak rok później licencja Chessbase zostanie przywrócona. Sztokfisz nie domagał się odszkodowania ani rekompensaty finansowej.

Kompatybilność i multilicencjonowanie

Krótki przewodnik dotyczący zgodności licencji z GPLv3 zgodnie z FSF. Linia przerywana wskazuje, że GPLv2 jest kompatybilna tylko z GPLv3 z klauzulą ​​„lub jakąkolwiek nowszą wersją”.

Kod objęty licencją na kilku innych licencjach można bezkonfliktowo łączyć z programem objętym licencją GPL, o ile połączenie ograniczeń na dzieło jako całość nie nakłada żadnych dodatkowych ograniczeń poza to, na co pozwala GPL. Oprócz zwykłych warunków licencji GPL istnieją dodatkowe ograniczenia i zezwolenia, które można zastosować:

  1. Jeśli użytkownik chce połączyć kod objęty licencją na różne wersje GPL, jest to dozwolone tylko wtedy, gdy kod z wcześniejszą wersją GPL zawiera stwierdzenie „lub dowolną nowszą wersję”. Na przykład biblioteka GNU LibreDWG na licencji GPLv3 nie może być już używana przez LibreCAD i FreeCAD , które mają zależności tylko na GPLv2.
  2. Kod licencjonowany na licencji LGPL może być łączony z dowolnym innym kodem, bez względu na to, jaką licencję ma ten kod, chociaż LGPL dodaje dodatkowe wymagania dotyczące połączonej pracy. Dlatego zwykle nie można łączyć LGPLv3 i GPLv2-only, ponieważ połączone prace nad kodem dodałyby dodatkowe wymagania LGPLv3 oprócz oprogramowania licencjonowanego tylko na GPLv2. Kod licencjonowany na licencji LGPLv2.x bez stwierdzenia „dowolna późniejsza wersja” może podlegać ponownej licencji , jeśli cała połączona praca jest objęta licencją GPLv2 lub GPLv3.

FSF prowadzi listę licencji wolnego oprogramowania zgodnych z GPL , zawierającą wiele najpopularniejszych licencji wolnego oprogramowania, takich jak oryginalna licencja MIT/X , licencja BSD (w obecnej formie 3-klauzulowej) oraz Licencja artystyczna 2.0.

Począwszy od GPLv3, jest jednostronnie kompatybilny z materiałami (takimi jak tekst i inne media) objętymi międzynarodową licencją Creative Commons Attribution-ShareAlike 4.0 do remiksowania w materiałach na licencji GPL (głównie oprogramowanie), a nie odwrotnie, w niszowych przypadkach użycia, takich jak gry silnik (GPL) ze skryptami gry (CC BY-SA).

David A. Wheeler opowiadał się za tym, aby twórcy oprogramowania wolnego / otwartego oprogramowania używali tylko licencji zgodnych z GPL, ponieważ w przeciwnym razie utrudnia innym uczestnictwo i współtworzenie kodu. Jako konkretny przykład niezgodności licencji, ZFS firmy Sun Microsystems nie może być zawarty w jądrze Linuksa na licencji GPL, ponieważ jest licencjonowany na podstawie niezgodnej z GPL licencji Common Development and Distribution License . Ponadto ZFS jest chroniony patentami, więc dystrybucja niezależnie opracowanej implementacji na licencji GPL nadal wymagałaby zgody Oracle.

Wiele firm korzysta z multilicencji w celu dystrybucji wersji GPL i sprzedaży zastrzeżonej licencji firmom, które chcą połączyć pakiet z zastrzeżonym kodem, używając dynamicznego linkowania lub nie. Przykładami takich firm są MySQL AB , Digia PLC ( Qt framework , przed 2011 r. od Nokii ), Red Hat ( Cygwin ) i Riverbank Computing ( PyQt ). Inne firmy, takie jak Mozilla Foundation (produkty obejmują Mozilla Application Suite , Mozilla Thunderbird i Mozilla Firefox ), używały multilicencji do dystrybucji wersji na licencji GPL i niektórych innych licencjach open source.

Tekst i inne media

Możliwe jest użycie GPL dla dokumentów tekstowych zamiast programów komputerowych, lub ogólniej dla wszystkich rodzajów mediów, jeśli jest jasne, co stanowi kod źródłowy (określany jako „preferowana forma pracy do wprowadzania w nim zmian”) . Jednak w przypadku podręczników i podręczników FSF zaleca licencję GNU Free Documentation License (GFDL), którą stworzyła w tym celu. Niemniej jednak Debiana zalecili (w uchwale przyjętej w 2006 r.) licencjonowanie dokumentacji swojego projektu na licencji GPL, ze względu na niezgodność GFDL z GPL (tekst objęty licencją GFDL nie może być włączony do oprogramowania GPL). Również FLOSS Manuals , organizacja zajmująca się tworzeniem podręczników do wolnego oprogramowania, zdecydowała w 2007 roku zrezygnować z GFDL na rzecz licencji GPL dla swoich tekstów.

Jeśli licencja GPL jest używana do czcionek komputerowych , wszelkie dokumenty lub obrazy utworzone za pomocą takich czcionek mogą również wymagać rozpowszechniania na warunkach GPL. Inaczej jest w krajach, które uznają kroje pisma (wygląd czcionek) za użyteczny artykuł i tym samym nieobjęty prawami autorskimi , ale pliki czcionek są oprogramowaniem komputerowym chronionym prawem autorskim (co może komplikować osadzanie czcionek, ponieważ dokument można uznać za „połączony ' do czcionki; innymi słowy, osadzenie czcionki wektorowej w dokumencie mogłoby wymusić udostępnienie jej na licencji GPL, ale zrasteryzowane renderowanie czcionki nie podlegałoby licencji GPL). FSF przewiduje wyjątek dla przypadków, w których nie jest to pożądane.

Przyjęcie

W przeszłości rodzina licencji GPL była jedną z najpopularniejszych licencji na oprogramowanie w domenie FOSS .

Ankieta przeprowadzona w 1997 roku przez MetaLab , wówczas największe archiwum wolnego oprogramowania, wykazała, że ​​GPL stanowiła około połowy licencjonowanego tam oprogramowania. Podobnie badanie Red Hat Linux 7.1 z 2000 roku wykazało, że 53% kodu źródłowego było objęte licencją GPL. Od 2003 r. około 68% wszystkich projektów i 82,1% licencjonowanych projektów open source z certyfikatem branżowym wymienionych na SourceForge.net pochodziło z rodziny licencji GPL. W sierpniu 2008 r. rodzina GPL stanowiła 70,9% z 44 927 wolnego oprogramowania wymienionych na Freecode .

Po wydaniu GPLv3 w czerwcu 2007 r., wiele dyskutowano o przyjęciu tej nowej wersji GPL, a niektóre projekty zrezygnowano z aktualizacji. Na przykład jądro Linuksa, MySQL , BusyBox , AdvFS , Blender , VLC media player i MediaWiki zdecydowały się nie przyjmować GPLv3. Z drugiej strony, w 2009 roku, dwa lata po wydaniu GPLv3, kierownik biura programów open source w Google , Chris DiBona, poinformował, że liczba licencjonowanego oprogramowania projektowego open source, które przeszło z GPLv2 na GPLv3, wyniosła 50%, licząc projekty hostowane w Google Code .

W 2011 roku, cztery lata po wydaniu GPLv3, 6,5% wszystkich projektów licencji open source to GPLv3, a 42,5% to GPLv2, według danych Black Duck Software. W 2011 roku 451 Group, Matthew Aslett, argumentował w poście na blogu, że licencje typu copyleft spadły, a licencje zezwalające wzrosły, na podstawie statystyk z Black Duck Software. Podobnie w lutym 2012 r. Jon Buys poinformował, że wśród 50 najlepszych projektów na GitHub pięć projektów było na licencji GPL, w tym projekty z podwójną licencją i projekty AGPL.

Statystyki użytkowania GPL w latach 2009-2013 zostały wyodrębnione z danych Freecode przez Waltera van Holsta podczas analizy rozpowszechniania licencji .

Wykorzystanie licencji rodziny GPL w % na Freecode
2009 2010 2011 2012 2013 2014-06-18
72% 63% 61% 59% 58% około. 54%

W sierpniu 2013 r., Według Black Duck Software, dane serwisu pokazują, że rodzina licencji GPL jest używana przez 54% projektów open source, z podziałem na poszczególne licencje przedstawionym w poniższej tabeli. Jednak późniejsze badanie przeprowadzone w 2013 roku wykazało, że oprogramowanie licencjonowane na licencji GPL wzrosło, a nawet dane z Black Duck Software wykazały całkowity wzrost projektów oprogramowania na licencji GPL. W badaniu wykorzystano informacje publiczne zebrane z repozytoriów Projektu Debian , a badanie skrytykowało Black Duck Software za niepublikowanie ich metodologii wykorzystywanej do zbierania statystyk. Daniel German, profesor na Wydziale Informatyki na Uniwersytecie Wiktorii w Kanadzie, wygłosił w 2013 roku wykład na temat wyzwań metodologicznych w określaniu, które licencje wolnego oprogramowania są najczęściej używane, i pokazał, w jaki sposób nie może powtórzyć wyniku z Black Oprogramowanie kaczki.

W 2015 roku, według Black Duck, GPLv2 straciła pierwszą pozycję na rzecz licencji MIT i jest teraz druga, GPLv3 spadła na czwarte miejsce, podczas gdy licencja Apache utrzymała trzecią pozycję.

Wykorzystanie licencji z rodziny GPL w domenie FOSS w % według Black Duck Software
Licencja 2008-05-08 2009-03-11 2011-11-22 2013-08-12 2015-11-19 2016-06-06 2017-01-02 2018-06-04
GPLv2 58,69% 52,2% 42,5% 33% 23% 21% 19% 14%
GPLv3 1,64% 4,15% 6,5% 12% 9% 9% 8% 6%
LGPLv2.1 11,39% 9,84% ? 6% 5% 4% 4% 3%
LGPLv3 ? (<0,64%) 0,37% ? 3% 2% 2% 2% 1%
Rodzina GPL razem 71,72% (+ <0,64%) 66,56% ? 54% 39% 36% 33% 24%

Analiza repozytoriów GitHub z marca 2015 r. wykazała, że ​​w przypadku rodziny licencji GPL odsetek wykorzystania projektów objętych licencją wynosi około 25%. W czerwcu 2016 r. analiza projektu Fedora wykazała, że ​​najpopularniejszą licencją jest GNU GPLv2 lub nowsza, a najpopularniejszą rodziną licencji jest rodzina GNU GPL (następnie rodziny MIT, BSD i GNU LGPL).

W analizie whitesourcesoftware.com z kwietnia 2018 r. ekosystemu FOSS GPLv3 znalazł się na trzecim miejscu (18%), a GPLv2 na czwartym miejscu (11%), za licencją MIT (26%) i licencją Apache 2.0 (21%).

Przyjęcie

Bariera prawna dla sklepów z aplikacjami

Licencja GPL jest niezgodna z wieloma cyfrowymi systemami dystrybucji aplikacji , takimi jak Mac App Store i niektórymi innymi platformami dystrybucji oprogramowania (zarówno na smartfony, jak i na komputery PC). Problem tkwi w prawie „wykonania kopii dla sąsiada”, gdyż prawo to jest łamane przez wbudowane w platformę systemy zarządzania prawami cyfrowymi, zapobiegające kopiowaniu płatnego oprogramowania. Nawet jeśli aplikacja jest bezpłatna w danym sklepie z aplikacjami, może to spowodować naruszenie warunków tego sklepu z aplikacjami.

Istnieje rozróżnienie między sklepem z aplikacjami , który sprzedaje oprogramowanie z ograniczeniami DRM na licencji zastrzeżonej, a bardziej ogólną koncepcją dystrybucji cyfrowej za pośrednictwem jakiejś formy repozytorium oprogramowania online. Praktycznie wszystkie nowoczesne systemy Unix i dystrybucje Linuksa mają repozytoria aplikacji, w tym NetBSD , FreeBSD , Ubuntu , Fedora i Debian . Wszystkie te specyficzne repozytoria aplikacji zawierają aplikacje na licencji GPL, w niektórych przypadkach nawet wtedy, gdy główny projekt nie zezwala na kod na licencji GPL w systemie podstawowym (na przykład OpenBSD). W innych przypadkach, takich jak Ubuntu App Store , zastrzeżone aplikacje komercyjne i aplikacje na licencji GPL są dostępne za pośrednictwem tego samego systemu; powód, dla którego Mac App Store (i podobne projekty) jest niekompatybilny z aplikacjami na licencji GPL, nie jest nierozerwalnie związany z koncepcją sklepu z aplikacjami, ale raczej wynika z wymagań Apple dotyczących warunków użytkowania, zgodnie z którymi wszystkie aplikacje w sklepie wykorzystują Ograniczenia Apple DRM. Sklep z aplikacjami Ubuntu nie wymaga takiego wymogu: „Te warunki nie ograniczają ani nie ograniczają twoich praw wynikających z jakichkolwiek obowiązujących licencji na oprogramowanie typu open source”.

Microsoftu

W 2001 roku dyrektor generalny Microsoftu , Steve Ballmer , nazwał Linuksa „rakiem, który przyczepia się w sensie własności intelektualnej do wszystkiego, czego dotknie”. W odpowiedzi na ataki Microsoftu na GPL, kilku prominentnych programistów i zwolenników Wolnego Oprogramowania wydało wspólne oświadczenie popierające tę licencję. Microsoft wydał Microsoft Windows Services for UNIX , który zawiera kod na licencji GPL. W lipcu 2009 r. sam Microsoft wydał około 20 000 wierszy kodu sterownika dla systemu Linux na licencji GPL. Kod Hyper-V , który jest częścią przesłanego kodu, wykorzystywał komponenty open source objęte licencją GPL i pierwotnie był statycznie połączony z zastrzeżonymi częściami binarnymi, które są niedopuszczalne w oprogramowaniu na licencji GPL.

„Wirusowy” charakter

Opis licencji GPL jako „wirusowej” , gdy nazywa się ją „General Public Virus” lub „GNU Public Virus” (GPV), sięga roku po wydaniu GPLv1.

W 2001 roku termin zyskał szerszą uwagę opinii publicznej, kiedy Craig Mundie , starszy wiceprezes firmy Microsoft, opisał GPL jako „wirusową”. Mundie argumentuje, że GPL ma efekt „wirusowy”, ponieważ pozwala tylko na przenoszenie całych programów, co oznacza, że ​​programy, które zawierają linki do bibliotek GPL, same muszą być objęte licencją kompatybilną z GPL, w przeciwnym razie nie można ich łączyć i rozpowszechniać.

W 2006 roku Richard Stallman odpowiedział w wywiadzie, że metafora Mundiego dotycząca „wirusa” jest błędna, ponieważ oprogramowanie na licencji GPL nie „atakuje” ani „infekuje” innego oprogramowania. W związku z tym Stallman uważa, że ​​porównywanie licencji GPL do wirusa jest niewłaściwe, a lepszą metaforą oprogramowania na licencji GPL byłaby roślina- pająk : jeśli ktoś weźmie jej kawałek i umieści go gdzie indziej, to też tam wyrośnie.

Z drugiej strony, koncepcja wirusowego charakteru licencji GPL została później podjęta przez innych. Na przykład w artykule z 2008 roku stwierdzono: „Licencja GPL jest„ wirusowa ”, co oznacza, że ​​​​każda praca pochodna, którą tworzysz, zawierająca nawet najmniejszą część oprogramowania objętego wcześniej licencją GPL, musi być również objęta licencją GPL”.

Bariera komercjalizacji

W projekcie FreeBSD stwierdzono, że „mniej nagłośnione i niezamierzone użycie licencji GPL polega na tym, że jest ona bardzo korzystna dla dużych firm, które chcą podkopać firmy produkujące oprogramowanie. Innymi słowy, GPL dobrze nadaje się do użycia jako broń marketingowa, potencjalnie zmniejszając ogólną korzyść ekonomiczną i przyczynianie się do zachowań monopolistycznych” oraz że GPL może „stanowić prawdziwy problem dla tych, którzy chcą komercjalizować oprogramowanie i czerpać z niego korzyści”.

Richard Stallman napisał o praktyce sprzedaży wyjątków licencyjnych od licencji wolnego oprogramowania jako przykładu etycznie akceptowalnej praktyki komercjalizacji. Sprzedawanie wyjątków oznacza tutaj, że właściciel praw autorskich do danego oprogramowania udostępnia je publicznie (wraz z odpowiednim kodem źródłowym) na licencji wolnego oprogramowania, „a następnie pozwala klientom płacić za pozwolenie na używanie tego samego kodu na różnych warunkach, na przykład zezwalając jego włączenie do zastrzeżonych aplikacji”. Stallman uważał sprzedawanie wyjątków za „dopuszczalne od lat 90. i czasami sugerowałem to firmom. Czasami takie podejście umożliwiało ważnym programom stanie się wolnym oprogramowaniem”. Chociaż FSF nie praktykuje sprzedaży wyjątków, proponuje się porównanie z licencją X11 (która nie jest licencją wolnego oprogramowania typu copyleft) w celu zasugerowania, że ​​tę technikę komercjalizacji należy uznać za etycznie akceptowalną. Wydanie danego programu na licencji wolnego oprogramowania, która nie jest copyleft, pozwoliłoby na osadzenie kodu w oprogramowaniu własnościowym. Stallman komentuje, że „albo musimy dojść do wniosku, że wydawanie czegokolwiek na licencji X11 jest złe – wniosek, który uważam za niedopuszczalnie skrajny – albo odrzucić tę implikację. Korzystanie z licencji innej niż copyleft jest słabe i zwykle jest gorszym wyborem, ale nie jest źle. Innymi słowy, sprzedaż wyjątków pozwala na pewne osadzenie w zastrzeżonym oprogramowaniu, a licencja X11 pozwala na jeszcze większe osadzenie. Jeśli to nie sprawia, że ​​licencja X11 jest nie do zaakceptowania, nie oznacza to, że sprzedaż wyjątków jest niedopuszczalna ”.

Krytyka open source

W 2000 roku programista i autor Nikolai Bezroukov opublikował analizę i wszechstronną krytykę podstaw GPL i modelu rozwoju oprogramowania Stallmana, zatytułowaną „Labirynt wolności oprogramowania”.

Wersja 2 licencji WTFPL (Do What The Fuck You Want To Public License) została stworzona przez lidera projektu Debiana Sama Hocevara w 2004 roku jako parodia GPL.

  W 2005 roku rzecznik oprogramowania open source , Eric S. Raymond, zakwestionował znaczenie licencji GPL dla ekosystemu FOSS, stwierdzając: „Nie potrzebujemy już licencji GPL. Opiera się ona na przekonaniu, że oprogramowanie open source jest słabe i należy je chronić Otwarte oprogramowanie odniosłoby sukces szybciej, gdyby GPL nie denerwowało wielu ludzi przed jego przyjęciem”. Richard Stallman odpowiedział: „GPL ma na celu… zapewnienie każdemu użytkownikowi programu podstawowych swobód — jego uruchamiania, studiowania i zmiany kodu źródłowego, redystrybucji kopii i publikowania zmodyfikowanych wersji… [ Raymond ] rozwiązuje ten problem w kategoriach różnych celów i wartości — tych związanych z „otwartym oprogramowaniem”, które nie obejmują obrony wolności użytkowników oprogramowania do udostępniania i zmiany oprogramowania”.

W 2007 roku Allison Randal , która brała udział w pracach komisji projektowej GPL, skrytykowała GPLv3 za niezgodność z GPLv2 i brak jasności w sformułowaniu. Podobnie Whurley przepowiedział w 2007 r. Upadek GPL z powodu braku skupienia się na programistach z GPLv3, co doprowadzi ich do uzyskania liberalnych licencji.

W 2009 roku David Chisnall opisał w artykule InformIT „The Failure of the GPL” problemy z GPL, między innymi niezgodność i złożoność tekstu licencji.

W 2014 roku deweloper dtrace i Joyent CTO Bryan Cantrill nazwał licencję GPL typu copyleft „korporacyjnym antywzorcem Open Source ”, będąc „przeciwnym współpracy” i zalecając zamiast tego liberalne licencje na oprogramowanie.

Krytyka GPLv3

Już we wrześniu 2006 roku, w procesie opracowywania wersji GPLv3, kilku znanych twórców jądra Linuksa, na przykład Linus Torvalds, Greg Kroah-Hartman i Andrew Morton , ostrzegało przed podziałem społeczności FOSS: „wydanie GPLv3 zwiastuje bałkanizację całego wszechświata Open Source, na którym polegamy”. Podobnie Benjamin Mako Hill argumentował w 2006 roku w sprawie wersji roboczej GPLv3, zauważając, że zjednoczona, współpracująca społeczność jest ważniejsza niż pojedyncza licencja.

Po wydaniu GPLv3 w 2007 roku niektórzy dziennikarze i deweloper Toybox , Rob Landley, skrytykowali, że wraz z wprowadzeniem GPLv3 podział między społecznością open source i społecznością wolnego oprogramowania stał się szerszy niż kiedykolwiek. Ponieważ znacznie rozszerzona GPLv3 jest zasadniczo niekompatybilna z GPLv2, kompatybilność między obiema jest zapewniona tylko w ramach opcjonalnej klauzuli GPL „lub nowszej”, która nie została wzięta na przykład przez jądro Linuksa. Bruce Byfield zauważył, że przed wydaniem GPLv3, GPLv2 była elementem jednoczącym między społecznością open source a społecznością wolnego oprogramowania.

W przypadku LGPLv3 opiekun GNU TLS , Nikos Mavrogiannopoulos, podobnie argumentował: „Jeśli założymy, że jego głównym celem [LGPLv3] jest wykorzystanie przez wolne oprogramowanie, to rażąco to zawodzi”, po tym, jak ponownie uzyskał licencję GNU TLS z LGPLv3 z powrotem na LGPLv2.1 ze względu na problemy ze zgodnością licencji.

Lawrence Rosen , prawnik i specjalista komputerowy, chwalił w 2007 roku, w jaki sposób społeczność korzystająca z licencji Apache mogła teraz współpracować ze społecznością GPL w sposób kompatybilny, ponieważ problemy zgodności GPLv2 z licencjonowanym oprogramowaniem Apache zostały rozwiązane dzięki GPLv3. Powiedział: „Przewiduję, że jednym z największych sukcesów GPLv3 będzie uświadomienie sobie, że cały wszechświat wolnego i otwartego oprogramowania można w ten sposób połączyć w kompleksowe rozwiązania open source dla klientów na całym świecie”.

W lipcu 2013 r. Programista Flask , Armin Ronacher, wyciągnął mniej optymistyczny wniosek na temat zgodności GPL w ekosystemie FOSS: „Kiedy w grę wchodzi GPL, złożoność licencjonowania staje się zabawną wersją zagadki”, zauważając również, że konflikt między licencją Apache 2.0 i GPLv2 nadal mają wpływ na ekosystem.

Zobacz też

Notatki

Linki zewnętrzne