Czy w GPL istnieje luka, która umożliwia łączenie zastrzeżonego oprogramowania z bibliotekami GPL?

Przeanalizujmy hipotetyczny scenariusz:

Firma X pisze zastrzeżony program (A), który dynamicznie łączy się z zastrzeżoną biblioteką (B). Firma Y chce użyć biblioteki zastępczej (C) licencjonowanej na licencji GPL, dlatego pisze bibliotekę otoki (D), która dynamicznie łączy zarówno A, jak i C i tłumaczy wywołania API używane przez A na wywołania API używane przez C.

Ponieważ D jest przeznaczony do użycia z C i wykorzystuje wywołania API C, jest to pochodna praca C i dlatego musi być dystrybuowana zgodnie z warunkami GPL *. W rezultacie połączona praca A i D musi być również rozpowszechniana na warunkach GPL, co jest niemożliwe, biorąc pod uwagę, że Firma Y nie posiada kodu źródłowego dla A. To powiedziawszy, o ile Firma Y sama dystrybuuje D , nie ma problemu. Jednak niezależnie od działań Firmy Y, Firma X nie narusza GPL poprzez dystrybucję A, nawet bez B. Samo istnienie D nie oznacza, że ​​A jest nagle dziełem pochodnym C (do D), które musi być licencjonowane na podstawie GPL również.

To jest luka: nic nie stoi na przeszkodzie, aby Firma X napisała własną wersję D, dystrybuowała ją osobno od A i informowała użytkowników końcowych, aby używali D zamiast B podczas uruchamiania A. Wydaje się, że firma jest w stanie zaprojektowanie zastrzeżonego programu do korzystania z biblioteki GPL bez naruszania GPL, o ile moduł otoki służy do izolowania zastrzeżonego programu od biblioteki GPL, a moduł ten jest dystrybuowany osobno.

Czy mam rację w swoim rozumowaniu? Czy to prawdziwa luka w GPL?

* D jest również dziełem pochodnym A, ale na potrzeby tego scenariusza Firma X wyraźnie upoważniła do utworzenia D i zezwoliła na licencję na podstawie GPL.

IANAL, ale oto moja opinia na temat tego, co jest dozwolone w granicach GPL:

• rozpowszechniać połączone dzieło „A - B” publicznie: w porządku, można to zrobić na podstawie dowolnej licencji zastrzeżonej

• stwórz opakowanie lib D dla C przez Y: w porządku, nie oznacza to, że A musi być objęte GPL

• użyj połączonego produktu „A - D - C” wewnętrznie przez Y: również dobrze, GPL nie wymaga open source A, o ile kombinacja nie jest rozpowszechniana publicznie

• rozpowszechniać połączone dzieło „A - D - C” publicznie: będzie to wymagało, aby A miał otwarte źródła i był objęty licencją GPL (i nie ma znaczenia, czy X lub Y dystrybuują tę kombinację; dodatkowo, jeśli Y chce to zrobić to, że wymagałyby oczywiście licencji na dystrybucję dla A od X)

Interesujące pytanie brzmi: czy D&C może być dystrybuowane osobno jako oprogramowanie typu open source na licencji GPL, A&B (lub po prostu A bez B) może być dystrybuowane na podstawie licencji zastrzeżonej, a użytkownik końcowy samodzielnie zastępuje B przez D&C?

Tutaj końcowa modyfikacja „AB”, która uzależnia A od bibliotek D&C, jest wykonywana przez użytkownika końcowego - po dystrybucji . Można więc argumentować, że ostateczna modyfikacja jest wykonywana tylko wewnętrznie przez użytkownika końcowego. I wydaje się, że to rzeczywiście jest możliwe bez naruszenia GPL - a dostajesz działającą kombinację „AC&D”, gdzie A jest objęty licencją prawną i C&D na podstawie GPL.

Oczywiście prawnik lub sędzia może mieć inne zdanie na ten temat. Aby uzyskać ostateczną odpowiedź, myślę, że musisz poczekać, aż ktoś ją wypróbuje, a druga pozwie go.

Myślę, że w przypadku większości systemów trudno będzie stworzyć taką konstelację bez zaprojektowania „A” od początku w taki sposób, aby działała bezproblemowo z B lub C. W tym przypadku można by podejrzewać, że A pochodzi w jakiś sposób od C.

EDYCJA: zastanawiając się nad tym, przyszła mi do głowy podobna sytuacja: pisanie i dystrybucja wtyczek licencjonowanych przez GPL dla aplikacji zamkniętych. Weźmy na przykład Photoshopa. Nie sądzę, aby ktoś poważnie próbował wymusić Adobe na Photoshopie typu open source tylko dlatego, że istnieją pewne wtyczki GPL od zewnętrznych dostawców. Tutaj nie jest nawet potrzebny „wrapper lib”, ponieważ istnieje dobrze zdefiniowany interfejs. Czy zmieniłoby to jednak sytuację, gdyby Photoshop zawierał niektóre swoje centralne funkcje z wtyczki innej firmy GPL? Myślę, że w takim przypadku może być naprawdę trudno zdecydować, gdzie wytyczyć granicę, w którym momencie produkt o zamkniętym źródle jest dziełem „opartym” na bibliotece GPL.

EDYCJA 2: Dostępne są biblioteki podwójnej licencji, z licencją GPL do użytku niekomercyjnego i licencją zastrzeżoną do użytku komercyjnego , na przykład taką jak ta . Tak więc twoja „luka” oznaczałaby opracowanie produktu opartego na takiej lib (przy użyciu wersji komercyjnej, więc GPL nie dotyczy twojego produktu), dostarczenie produktu jako zamkniętego źródła bez lib do publicznej wiadomości i pozwolenie użytkownik sam pobiera i instaluje wersję GPLed. W takim przypadku sądzę, że sprzedawca biblioteki lib będzie miał dużą szansę skutecznie pozwać cię za naruszenie licencji (jeśli oczywiście nie zapłacisz za jego bibliotekę). Czy warto się męczyć? Prawdopodobnie nie. Zwłaszcza w przykładzie, do którego nawiązałem, ty też musisz kupić bibliotekę, ponieważ cena nie zależy od tego, jak często sprzedajesz swój produkt, ale tylko od tego, ilu deweloperów używa biblioteki podczas tworzenia.

Wreszcie, ze względu na ryzyko prawne, jeśli zamierzam korzystać z bibliotek open source w ramach produktu o zamkniętym źródle, unikam bibliotek lib GPL, jeśli to możliwe, i nie próbuję korzystać z tej „luki”. LGPL lub GPL z wyjątkiem linkowania jest znacznie bezpieczniejsza lub jakakolwiek inna niewirusowa licencja na system operacyjny.

Praktycznym przykładem są zastrzeżone sterowniki graficzne dla systemu Linux, które użytkownik końcowy musi sam zainstalować. Co ważne, dla twórcy zastrzeżonego sterownika, jeśli użytkownik końcowy rozpowszechnia połączoną pracę, stwarza to prawne zobowiązanie dla użytkownika końcowego (którego nie jest możliwe do spełnienia), ale nie dla twórcy sterownika.

Inna odpowiedź głosi: „ponieważ program zależy od biblioteki, nadal jest to praca pochodna” - ale jeśli program tak naprawdę nie działa, ponieważ biblioteki nie ma, to nie jest pochodną.

Ale ostatecznie, jeśli polegasz na „lukach”, powinieneś wziąć pod uwagę, że twoje podejście może być niewłaściwe.

Łączenie określa pochodną GPL. Ta konkretna sytuacja jest obsługiwana przez LGPL: gdzie chcesz wydać bibliotekę jako GPL, ale zdefiniuj linkowanie jako wyraźny limit stosowanej licencji lub alternatywnie, gdzie chcesz połączyć się z jakimś kodem GPL, ale musisz mieć własny praca może być wydana na podstawie licencji innej niż GPL.

W przypadku, gdy użytkownik końcowy dokona połączenia (zbuduje swój własny kod ze źródeł innych niż GPL, które mogą łączyć się z biblioteką GPL), użytkownik końcowy nie stworzył skutecznie wersji GPL jakiegokolwiek produktu końcowego, ponieważ nie wolno mu zmieniać licencji części projektu innej niż GPL, ponieważ nie jest on jej właścicielem. Zasadniczo wyklucza to rozpowszechnianie przez użytkownika końcowego w jakiejkolwiek formie, ale nie zabrania używania.

To powiedziawszy, jeśli projekt wymaga, aby został zbudowany ze źródła i jest dystrybuowany tylko w ten sposób, nie ma znaczenia, na jakiej licencji znajduje się biblioteka połączona, ponieważ jest to całkowicie w rękach dewelopera spoza GPL. To znaczy, skąd możesz wiedzieć, że twoja dystrybucja tylko dla źródła zostanie zbudowana na gcc przeciwko glibc VS zbudowanemu na kompilatorze IBM przeciwko ich libc, chyba że określisz to na podstawie własnych warunków licencyjnych? To szybko wpada w dozwolony użytek i zakazy w stosunku do niemożliwych do wyegzekwowania warunków prawnych (nie to, że fantazja nie była ostatnio wielokrotnie zapisywana w prawie).

Nie jestem prawnikiem, ale o ile mogę powiedzieć, że nie masz racji, ponieważ program zależy od biblioteki - nadal jest to praca pochodna. Ten sam sposób, w jaki sekwencja jest dziełem pochodnym. Przynajmniej opiera się na interfejsach API zdefiniowanych w bibliotece.