W jaki sposób reguła łączenia statycznego i dynamicznego GPL ma zastosowanie do języków interpretowanych?

W moim rozumieniu GPL zabrania łączenia statycznego z kodu innego niż GPL do kodu GPL, ale zezwala na dynamiczne łączenie z kodu innego niż GPL do kodu GPL. Więc co to jest, gdy dany kod nie jest w ogóle połączony, ponieważ kod jest napisany w języku interpretowanym (np. Perl)?

Wydaje się, że korzystanie z reguły byłoby zbyt łatwe, jeśli uznano by to za dynamiczne łączenie, ale z drugiej strony wydawałoby się niemożliwe, aby legalnie odwoływać się do kodu GPL z kodu innego niż GPL, gdyby był uważany za statyczny! Języki skompilowane mają przynajmniej rozróżnienie między łączeniem statycznym i dynamicznym, ale kiedy całe „łączenie” uruchamia tylko skrypty, nie można powiedzieć, co to jest bez wyraźnej licencji!

Czy też moje rozumienie tego problemu jest nieprawidłowe, co sprawia, że ​​pytanie jest dyskusyjne? Słyszałem również o „wyjątku klasy”, który obejmuje dynamiczne łączenie; czy to nie jest część GPL, ale coś, co można do niej dodać, więc dynamiczne linkowanie jest dozwolone tylko wtedy, gdy licencja zawiera ten wyjątek?

Jeśli chodzi o konkretne pytanie dotyczące tłumaczonych języków, FAQ GPL jest bardzo jasne :

Zinterpretowany program dla tłumacza to tylko dane; licencja wolnego oprogramowania, taka jak GPL, oparta na prawie autorskim, nie może ograniczać danych, na których używasz tłumacza. Możesz uruchomić go na dowolnych danych (zinterpretowanym programie), w dowolny sposób i nie ma żadnych wymagań dotyczących licencjonowania tych danych nikomu.

Co do ogólnego pytania na temat łączenia dynamicznego vs. statycznego. Po pierwsze, pogląd FSF i Stallmana jest taki, że nie ma znaczenia, czy łączenie jest statyczne czy dynamiczne, GPL zaraża w obu kierunkach. Z FSF GPL FAQ:

Jeśli program dynamicznie łączy wtyczki i wykonuje wzajemne wywołania funkcji i współużytkuje struktury danych, uważamy, że tworzą one pojedynczy program, który należy traktować jako rozszerzenie zarówno programu głównego, jak i wtyczek. Oznacza to, że połączenie wtyczki objętej GPL z niewolnym programem głównym naruszy GPL.

i

Powiązanie [nazwa twojego programu] statycznie lub dynamicznie z innymi modułami stanowi połączoną pracę opartą na [nazwa twojego programu]. Zatem warunki Powszechnej Licencji Publicznej GNU obejmują całą kombinację

Jest to jednak wątpliwe z prawnego punktu widzenia. W jedynym przypadku, który faktycznie trafił do sądu w sprawie dynamicznego linkowania - Galoob przeciwko Nintendo - Sąd Apelacyjny orzekł, że dzieło pochodne „musi zawierać część dzieła chronionego prawem autorskim w jakiejś formie” . Nie jest tak w przypadku dynamicznego linkowania.

W każdym razie, niezależnie od tego, czy dynamiczne linkowanie rzeczywiście infekuje, czy nie, istnieje obejście. Jest używany na przykład przez Nvidię do dostarczania sterowników binarnych dla Linuksa. Tworzysz (L) opakowanie GPL, ale jako autor możesz dodać specjalny wyjątek, aby połączyć się z określonym zamkniętym źródłem. Vide FSF GPL FAQ .

Uwaga: jest to pytanie prawne. Programmers.SE nie jest forum prawnym, jest forum programowania. Chociaż ludzie tutaj wiedzą sporo o programowaniu, nie wiedzą nic o prawie. Jeśli chcesz zadać pytanie prawne, zadaj je na forum prawnym, na którym są ludzie, którzy faktycznie wiedzą coś na ten temat.

GPL nie mówi nic o łączeniu statycznym lub dynamicznym. To nawet nie mówią nic o łączenie w ogóle . Każdy prawnik lub sędzia, z którym rozmawiałem, mówi, że kwestia statycznych i dynamicznych połączeń jest całkowicie nieistotna.

Prawo autorskie dotyczy kreatywności. Łączenie statyczne vs. dynamiczne to techniczny szczegół implementacji. Niezależnie od tego, czy coś jest statycznie lub dynamicznie powiązane, nie jest aktem twórczym, nie może zmienić statusu praw autorskich utworu.

W swoim pytaniu mówisz o „tłumaczonych językach”. Ale ten termin nie ma sensu: nie ma czegoś takiego jak interpretowany język. Język to abstrakcyjny zestaw reguł i ograniczeń matematycznych. Język nie jest interpretowany ani kompilowany. Po prostu jest język . Termin „język interpretowany” jest nie tylko błędny , ale także nie sensualny . Gdyby angielski był językiem pisanym, byłby to błąd pisowni.

Interpretacja i kompilacja to cechy tłumacza lub kompilatora (duh!), A nie język. Każdy język można zaimplementować za pomocą interpretera, a każdy język można zaimplementować za pomocą kompilatora. Większość języków ma oba. Większość nowoczesnych implementacji językowych łączy nawet oba w jednym silniku wykonawczym.

Implementacja Rubyus Ruby, na przykład, zawiera statyczny kompilator z wyprzedzeniem, który kompiluje kod Ruby do kodu bajtowego Rubinius, interpreter, który interpretuje kod bajtowy Rubinius, oraz dynamiczny kompilator just-in-time, który kompiluje kod bajtowy Rubinius do LLVM IR, które z kolei infrastruktura LLVM kompiluje do natywnego kodu maszynowego. Implementacja Ruby MacRuby wcale nie zawiera interpretera, kompiluje kod Ruby bezpośrednio do LLVM IR, a następnie do natywnego kodu maszynowego.

Z drugiej strony istnieją interpretery dla C lub C ++.

Wszystko to są tylko szczegóły techniczne. Jest to całkowicie nieistotne dla praw autorskich.

Po prostu nie ma sensu, że to, czy ktoś narusza czyjeś prawa autorskie, zależy od tego, czy osoba trzecia zdecyduje się uruchomić program z tłumaczem ustnym lub najpierw go skompilować.

Pytanie brzmi, czy praca pochodzi z innej pracy. Można go dynamicznie łączyć i nadal uzyskiwać, i można go łączyć statycznie i w ogóle nie uzyskiwać.

Nie mam pojęcia, ile w tym prawdy, IANAL itp .; ale w mojej interpretacji ważne jest to, czy biblioteka, do której prowadzi łącze, jest w jakiejś formie zawarta w „binarnym” (gdzie „binarny”, w przypadku dynamicznych języków programowania, jest tylko kodem źródłowym w postaci, w jakiej jest rozpowszechniany; jest to co robię z definicji FSF „binarnej” w tym kontekście).

Jeśli więc odwołujesz się do bibliotek ze swojego kodu bez włączania ich do swojej dystrybucji, uważam to za ekwiwalent „dynamicznego łączenia”, podczas gdy jeśli połączysz biblioteki z produktem lub skopiujesz i wkleisz części biblioteki do własnego kodu, obowiązywałby scenariusz „łączenia statycznego”. Jest to przynajmniej zgodne z duchem GPL: możesz swobodnie używać (uruchamiać, sprawdzać, odwoływać się) oprogramowania GPL bez ograniczeń, ale jak tylko zaczniesz z niego czerpać (łącząc lub kopiując jego części do swojego własny produkt do dystrybucji), wirus staje się wirusowy, a twoje oprogramowanie musi być również objęte licencją GPL.