Zaczniemy od przykładu-zagadki: pracujesz w spółce A, która dostała zlecenie na napisanie oprogramowania dla spółki B. Piszesz oprogramowanie, korzystając z kodu opartego o licencję GPL – modyfikujesz go, dopisujesz własne rozwiązania, ale bezspornie jest to opracowanie oprogramowania pierwotnego, opartego na GPL. Spółka B jest zadowolona, płaci Twojemu pracodawcy wynagrodzenie, otrzymuje kody. I tutaj pojawia się pytanie: czy spółka B w momencie otrzymania oprogramowania zobowiązana jest do publikacji całego kodu źródłowego? Czy programista ze spółki C może żądać od spółki B udostępnienia tego kodu?

Otóż nie i nie. To jedna z pułapek ideologicznego myślenia o open source. Twórcy tych licencji dbają o to, aby twórca opracowania (czyli nasz programista ze spółki A, czy raczej sama spółka) nie „zamknęły” kodu takich opracowań. Ale nie oznacza to, że zmuszają, aby kod zawsze pokazać publicznie, nie oznacza, że świat „zewnętrzny” ma zawsze roszczenia. Open source działa w relacji licencjodawca – licencjobiorca. Jeżeli udzielana jest licencja, licencjobiorca (i tylko on) może żądać dostarczenia kodu źródłowego. Jeżeli żadna ze stron takiej umowy nie jest zainteresowana udostępnieniem kodu źródłowego innym osobom, nie mają takiego obowiązku. Dopiero gdy spółka B rozpowszechni oprogramowanie, które nabyła, będzie musiała udostępnić kod źródłowy każdemu z użytkowników tego oprogramowania.

Mechanizm ten ma szczególną wagę w grupach kapitałowych. Jeżeli jedna ze spółek ma charakter tzw. CUW/Centrum IT i opracowuje rozwiązania dla całej grupy – choćby i tysiąca spółek – to każda z tych spółek ma prawo do otrzymania kodu, ale nie mają obowiązku jego pokazywania na zewnątrz. Mimo objęcia kodu licencją GPL można więc cały czas kontrolować know-how i tajemnice przedsiębiorstwa, jeżeli są zawarte w kodzie.

A teraz druga zagadka: ten sam programista (spółka A) mówi „hola, hola, ale tam jest pełno mojego kodu – udostępnię na licencji GPL tylko to, co jest pierwotnie na GPL, a to co opracowałem, na własnościowej, komercyjnej licencji”. Czy taki „hybrydowy” mechanizm ma szansę zadziałać?

Ma, ale rzadko. Wszystko zależy od tego, co i jak połączył programista. Nie każde użycie kodu open source, nawet na GPL, zaraża. To wyzwanie zarówno od strony prawnej, jak i architektury systemu, ale bywa i tak, że możemy zaprojektować rozwiązanie w ten sposób, by ryzyka zarażenia uniknąć (IP by design). Jednak GPL ma tę cechę, że w zarażaniu jest bardzo skuteczny. Żeby wytłumaczyć, jak ten mechanizm zarażania działa, potrzeba trochę teorii.

Interfejs między prawem autorskim a klauzulą copyleft

Ochrona praw autorskich do utworów nie ogranicza się do ich dosłownej treści. Nie miałaby ona sensu, gdyby po dokonaniu prostych modyfikacji można było korzystać z utworu bez zgody autora. Dlatego też prawo autorskie pozwala autorowi kontrolować również wykorzystanie utworów zależnych (adaptacji, tłumaczeń, aranżacji i innych zmian, określanych łącznie mianem opracowań). Na poziomie międzynarodowym zostało to uregulowane w art. 8 i 12 Konwencji Berneńskiej, a w UE w odniesieniu do programów komputerowych w art. 4 (1) (b) dyrektywy 2009/24/WE. Na poziomie krajowym jest ono traktowane albo jako odrębne prawo (najczęściej określane jako „prawo do adaptacji”) [1], albo jako część szerszego prawa do zwielokrotniania [2]. W każdym przypadku, gdy mamy do czynienia z utworem zależnym (opracowaniem), korzystanie z niego wymaga zgody nie tylko autora utworu zależnego (opracowania), ale także autora utworu pierwotnego (oryginału).

Prawo autorskie nie definiuje, czym jest opracowanie. Najogólniej rzecz ujmując, jego istotą jest „twórcza ingerencja” w dzieło twórcy pierwotnego. Każde opracowanie, w tym opracowanie programu komputerowego, jest więc wynikiem twórczości intelektualnej, w której występują obok siebie elementy twórcze zaczerpnięte z utworu oryginalnego, a także elementy twórcze dodane przez twórcę utworu zależnego. W świecie innym niż rynek oprogramowania to na przykład tłumaczenie „Harry’ego Pottera” czy adaptacja filmowa książek J.K. Rowling. Niby coś innego, literka w literkę nie ma sensu porównywać, ale gdyby nie oryginał, opracowania by też nie było.

Możliwość kontrolowania korzystania z utworów w postaci opracowania zapewnia klauzula copyleft. Z prawnego punktu widzenia, klauzula copyleft to zezwolenie na korzystanie z opracowania programu pierwotnego (oryginału), udzielone przez pierwotnego autora (autorów) pod warunkiem, że opracowanie zostanie również udostępnione na tych samych warunkach. Klasyczny przykład takiej klauzuli znajdziemy w GNU GPL 2.0, która stanowi w paragrafie 2 (b), że: „Musisz spowodować, że jakakolwiek praca, którą rozpowszechniasz lub publikujesz, która w całości lub w części zawiera lub jest pochodną Programu lub jego części, będzie licencjonowana jako całość bez opłat dla wszystkich stron trzecich zgodnie z warunkami niniejszej Licencji”. Na pierwszy rzut oka proste. Jednak trudność tkwi w udzieleniu odpowiedzi na pytanie, kiedy w przypadku software’u dochodzi do powstania opracowania. Spróbujmy przejść przez kilka scenariuszy.