Scenariusz 3: integracja

Dwa przedstawione wyżej scenariusze są dość oczywiste i łatwe do ogarnięcia od strony prawnej. Oczywiste jest, że jeżeli bierzemy kod na GPL-u, to produkt, który na jego podstawie napiszemy, też powinien być na GPL-u. Ale wyobraźmy sobie, że bierzemy binarkę jakiejś biblioteki programistycznej (niech będzie to nadal licencja GPL). Nie zmieniamy w niej ani linijki, ale piszemy program, który w swoim przebiegu wywołuje funkcje zawarte w tej bibliotece. Połączenie jest dynamiczne, a biblioteka i program wykorzystujący bibliotekę to dwa oddzielne pliki. Czy w takim przypadku GPL zarazi nasz kod? Otóż niewykluczone.

Niewiele programów komputerowych działa w całkowitej izolacji od swojego środowiska – większość z nich musi być połączona z innymi programami, aby można było z nich sensownie korzystać. To, jakie rodzaje połączeń prowadzą do „aktywacji” klauzuli copyleft, a więc kiedy połączone oprogramowanie zostaje „zainfekowane” zasadami licencji GNU GPL, jest jedną z trudniejszych kwestii przy wykorzystywaniu copyleftowego oprogramowania w projektach komercyjnych i jest różnie oceniana zarówno wśród prawników, jak i programistów.

Zgodnie z interpretacją konsekwentnie przyjmowaną przez Free Software Foundation, utwór zależny (opracowanie) powstaje, gdy procedury w zewnętrznych plikach są ściśle włączone w wykonywanie (przepływ) programu. FSF kładzie nacisk na granicę procesu, gdy rozważa zakres copyleft, oraz na mechanizm i semantykę komunikacji między wieloma komponentami oprogramowania, aby określić, czy są one wystarczająco ściśle zintegrowane, by uznać je za pojedynczy program dla celów GPL. Przykładem łączenia komponentów w jeden program może być użycie dynamicznie łączonych bibliotek oprogramowania. W ten sam sposób FSF ocenia również użycie wtyczek, których sposób połączenia z danym programem zakłada wzajemne wywoływanie funkcji lub współdzielenie złożonych struktur danych, a także modułów Perla lub klas Javy połączonych w podobny sposób.

W literaturze prawniczej pojawia się czasem argument, że dynamiczne linkowanie nie powinno być klasyfikowane jako utwór zależny. Podejście Free Software Foundation ma jednak pewne wsparcie w orzecznictwie sądów amerykańskich. W sprawie Bradstreet Software Servs. przeciwko Grace Consulting spór dotyczył tego, czy program pozwanego, który wprawdzie nie zapożyczał bezpośrednio z programu powoda, ale wymagał uruchomienia programu powoda i odwoływał się do funkcji zawartych w bibliotekach programistycznych, które były częścią programu powoda, może być uznany za utwór zależny. Sąd Apelacyjny Stanów Zjednoczonych dla Trzeciego Okręgu, uchylając wyrok sądu procesowego, odpowiedział na to pytanie twierdząco.

Powyższy wyrok został odczytany jako wskazówka, że powstanie utworu zależnego może nastąpić już w wyniku stworzenia programu wywołującego funkcje zawarte w zewnętrznej bibliotece programistycznej łączonej dynamicznie. Ze względu na zbliżony stan prawny w tym zakresie można założyć, że rozstrzyganie takich spraw w UE byłoby analogiczne.

Brak efektu wirusa  

Inne kombinacje programów niż opisane w artykule nie prowadzą do stworzenia dzieła zależnego, więc klauzula copyleft nie będzie miała zastosowania. Przykłady podane przez Free Software Foundation obejmują:

  • tzw. „mere aggregation“ (GPL 2.0) lub „aggregate“ (GPL 3.0) programów, tj. umieszczanie ich na jednym nośniku lub na jednym urządzeniu, nawet jeśli są one rozpowszechniane razem lub funkcjonalnie powiązane;
  • wymianę danych i komunikację pomiędzy dwoma oddzielnymi programami, działającymi jako oddzielne procesy; na przykład w systemach Unix mechanizmy komunikacji zwykle używane pomiędzy dwoma oddzielnymi programami to rury, gniazda i argumenty wiersza poleceń;
  • zwykłe użycie programu objętego copyleft do przetwarzania pewnych danych (np. edytor programistyczny, w którym edytuje się kod źródłowy innego programu); to samo dotyczy interpretera języka programowania objętego copyleft, dla którego interpretowany program jest tylko przetwarzanymi danymi.

W powyższych przypadkach, nawet jeśli kilka różnych programów współpracuje ze sobą w celu osiągnięcia określonego rezultatu, nie prowadzi to do połączenia ich w jeden program, a tym samym uznania go za utwór zależny. Przykładem mogą być dystrybucje Linuxa, w których komponenty systemu objęte licencją copyleft są połączone z komponentami objętymi innymi licencjami (w tym licencjami prawnie zastrzeżonymi).

  

Przeczytaj pierwszą część artykułu: Open source: trochę dłuższa analiza (cz. I).

Marcin Maruta, Zbigniew Okoń

Autorzy są Partnerami w Kancelarii Maruta Wachta.