Programy komputerowe bazujące na oprogramowaniach typu open source intensywnie konkurują z oprogramowaniem korzystającym z tradycyjnego modelu rozwoju, a więc z oprogramowaniem własnościowym (prioprietary software).

Oprogramowania typu open source, z uwagi na swoją otwartość poprzez nadanie możliwości swobodnego dostępu do ich kodu źródłowego, umożliwiają uczestnictwo we wspólnym przedsięwzięciu niepowiązanym ze sobą osobom oraz wzajemne korzystanie ze stworzonych przez siebie rozwiązań. Udział nieograniczonej liczby uczestników projektu rodzi szereg wątpliwości związanych z zakresem nabywanych przez właściciela projektu uprawnień w zakresie korzystania i rozporządzania otrzymanymi rozwiązaniami w sytuacji, gdy na udział w tworzeniu rozwiązań miały wpływ często nawet tysiące osób. Pojawia się więc pytanie, jak sprawnie uporządkować sytuację praw do oprogramowania, aby zapewnić zarówno wykonawcy, jak i zamawiającemu prawo do korzystania ze stworzonych rozwiązań bez ograniczeń i bez ryzyka naruszania praw autorskich.

Licencje open source są powszechnie używane, ale należy pamiętać, że stoją za nimi różne konstrukcje prawne. Nie stanowią one „domeny publicznej”, kodu bez właściciela, ani nie oferują pełnej swobody korzystania, lecz są mniej lub bardziej rozbudowanymi zobowiązaniami prawnymi, które omawiam pokrótce poniżej.

Zacznijmy jednak od faktu, że nie każdy kod źródłowy, który został ulokowany w publicznym miejscu możemy uznać za rozwiązanie typu open source, a za tym że uprawnia on do dowolnego z niego korzystania. Jest dokładnie odwrotnie – opublikowany i rozpowszechniony utwór jest nadal chroniony, a decydowanie o tym jak można go wykorzystać stanowi co do zasady uprawnienie autora lub właściciela majątkowych praw autorskich.

Czym jest właściwie oprogramowanie typu open source?

W znacznym uproszczeniu oprogramowanie open source to takie oprogramowanie, które pozwala na udostępnienie użytkownikom kodu źródłowego, a wraz z udostępnieniem - uprawnienia do jego badania, zmiany i rozpowszechnienia zgodnie z licencją open source.

Jakie znamy licencje open source?

Zasadnicze kryterium podziału licencji open source bazuje na ocenie, czy efekty dalszego rozwijania rozwiązania i dokonywania w nim zmian mogą być również dalej swobodnie udostępniane, a zmodyfikowane rozwiązanie powinno być objęte taką samą licencją, jak program pierwotny. Wynikiem powyższej kwalifikacji jest rozróżnienie między licencjami typu „copyleft” („wirusowe”) i „non-copyleft”.

Jedną z kluczowych różnic pomiędzy nimi jest to, że w modelu copyleft najczęściej spotykane są rozbudowane warunki licencyjne, które nakładają zobowiązanie do dalszego stosowania warunków tej samej licencji dla całości kodu źródłowego, z którym połączony został uzyskany na licencji fragment lub komponent. W modelu non-copyleft zazwyczaj stosowane są zaś uproszczone warunki licencyjne, które nie przewidują obowiązku dalszego stosowania tej samej licencji dla całości stworzonego rozwiązania.

„Licencje wirusowe”, czyli licencje, których treść nakazuje – w przypadku tworzenia opracowań konkretnych rozwiązań – licencjonować te opracowania zgodnie z treścią restrykcyjnych warunków „licencji wirusowej”, którą stosuje się do licencjonowania rozwiązań, na których opracowanie bazuje. Jednocześnie niestosowanie się do tych zasad powoduje, że licencja wirusowa wygasa i korzystający z takich rozwiązań open source będzie zobowiązany do zaprzestania ich używania.

Rozróżnia się dwa rodzaje klauzul typu copyleft:

a) Silny copyleft – w tym przypadku warunki licencji muszą być zachowane dla każdej pracy pochodnej. Najbardziej znanymi przykładami są wszystkie wersje GNU GPL i GNU AGPL.

b) Słaby copyleft – w tym przypadku warunki licencji muszą być zachowane dla określonych dzieł pochodnych. Może się więc okazać, że mimo użycia oprogramowania copyleft, do „zarażenia” nie doszło. Licencje, które wykorzystują „słabą” klauzulę copyleft to między innymi GNU Lesser General Public License (LGPL) oraz Mozilla Public License.

Powyższe oznacza często, że korzystając z kodu z „silną” licencją prawie na pewno „zarazimy” nasz kod warunkami takiej licencji. W przypadku „słabej” licencji standardowe zastosowanie danego komponentu może pozwolić na uniknięcie takiego ryzyka.

Jak zgodnie z prawem korzystać z open source?

Co do zasady znane nam obecnie licencje open source udzielają stosunkowo szerokiego uprawnienia pozwalającego na swobodne korzystania z rozwiązań objętych licencją (zostało to przewidziane również przez najbardziej restrykcyjne licencje copyleft).

Sprawy nieco komplikują się, jeżeli chcemy tworzyć na bazie oprogramowania open source opracowanie, z którego będziemy korzystać komercyjnie. W takim bowiem przypadku zawarcie przez twórcę opracowania umowy z jakimkolwiek podmiotem trzecim jest możliwe tylko w granicach, na jakie zezwala właściwa klauzula copyleft.

W tym miejscu jednak niektóre licencje mogą niestety okazać się pułapką, która uniemożliwi komercjalizację finalnego rozwiązania. Kluczową więc kwestią jest weryfikacja warunków licencyjnych przed rozpoczęciem projektu. Licencje copyleft wymagają, aby utwór zależny (pochodny, czyli stworzony na podstawie lub przy wykorzystaniu pierwotnego utworu) był również objęty taką samą licencją jak utwór pierwotny. Innymi słowy, licencja taka narzuca wykorzystanie dokładnie takich samych postanowień we wszystkich utworach, które zostaną stworzone na podstawie utworu, który jest utworem pierwotnym. Skutkuje to zaś objęciem odpowiednią licencją open source każdego projektu, w którym zastosujemy rozwiązanie oparte o taką licencję. W praktyce uniemożliwia to wykorzystanie takich rozwiązań w komercyjnych, zamkniętych programach, bowiem nie pozwala na dalsze komercyjne wykorzystanie lub sprzedaż.

Powyższa analiza odnosi się do utworu zależnego, którego kwalifikacja wymaga zaś indywidualnego podejścia i zbadania przesłanek, zakresu wpływu i zakresu różnic, w tym stopnia integracji utworu pierwotnego i ewentualnego utworu zależnego. Uznaje się bowiem, iż brak kwalifikacji utworu jako utworu zależnego wyklucza zastosowanie klauzuli copyleft.

Prawo autorskie nie definiuje, czym jest opracowanie, jednakże zgodnie przyjmuje się, iż 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, oraz elementy twórcze dodane przez twórcę utworu zależnego.

Jak wiemy, nie każda zmiana w cudzym programie to od razu dzieło zależne. Kilka prostych zmian (np. paru pojedynczych instrukcji czy pojedynczych wartości) nie musi być na tyle twórcze, żeby prowadzić do powstania opracowania, jednakże przesłanki ochrony prawnoautorskiej są interpretowane przez sądy bardzo liberalnie i nawet dość proste zmiany, zwłaszcza w przypadku ich większej ilości, stosunkowo łatwo zostają zakwalifikowane jako opracowanie.

W uproszczeniu, jeżeli nasz wkład jest oryginalny, powstanie opracowanie (utwór zależny). Wynika więc z tego, iż opracowanie jest nowym utworem. Jego związek z tym, co było materiałem wyjściowym wyraża się w konieczności uzyskania zezwolenia na „korzystanie i rozporządzanie opracowaniem”. Brak zezwolenia będzie skutkował naruszeniem autorskich praw majątkowych do utworu pierwotnego.

W tym miejscu zastosowanie ma omawiana klauzula copyletft, która zezwala zarówno twórcy opracowania, jak i dalszemu użytkownikowi na korzystanie i rozporządzanie opracowaniem wyłącznie na warunkach właściwej licencji.

Dlaczego oparcie opracowania na licencji open source może być ryzykowne?

Przyjmując za przykład licencję GNU GPL wskazuję, iż podmiot dystrybuujący rozwiązanie zobowiązany jest do dalszego udostępnienia kodu źródłowego oprogramowania. Utarło się więc mówić, że dochodzi do „zainfekowania” zmodyfikowanego software’u licencją open source. W związku z powyższym obowiązkiem, oprogramowanie to jest nazywane często oprogramowaniem opartym na jawnym kodzie źródłowym, co w wielu przypadkach stanowi tzw. „czerwoną flagę” w perspektywie ochrony know-how i tajemnic przedsiębiorstwa wykonawcy, który to stworzył opracowanie rozwiązania.

W tym miejscu należy zaznaczyć, iż od powyższego występują wyjątki w zależności od faktycznego układu opracowania. Nie każde bowiem 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żliwe jest zaprojektowanie rozwiązania w sposób pozwalający na uniknięcie ryzyka zakażenia.

W modelu dystrybucji zwanym „non-copyleft”, podmiot modyfikujący oprogramowanie może swoje modyfikacje dystrybuować poza modelem wolnego oprogramowania. Na tym ostatnim założeniu opiera się np. licencja Berkley Software Distribution. W jej przypadku wymogami używania i modyfikowania kodu, bez obowiązku udostępniania tych modyfikacji innym użytkownikom, jest tylko poinformowanie o autorach, o wyłączeniu odpowiedzialności oraz warunkach licencyjnych.

Komu przysługują majątkowe prawa autorskie?

Opracowanie rozwiązania opartego na licencji open source i prawo do korzystania z niego nie oznacza jeszcze, że wykonawca posiada majątkowe prawa autorskie – to nadal czyjś utwór, prawa autorskie majątkowe są własnością kogoś innego, kto jedynie zezwala wykonawcy na określone (szerokie) wykorzystanie takiego utworu. Powyższe okazuje się być oczywistym jedynie w teorii. Często jest bowiem tak, że wykonawcy sprzedając lub licencjonując oprogramowanie, oświadczają w zawieranych z klientami umowach, że wszelkie autorskie prawa majątkowe do całego programu przysługują właśnie im, a więc że to oni są twórcami rozwiązania w całości. Powyższe nie jest jednak prawdziwym stwierdzeniem, jeżeli elementem takiego programu są utwory oparte o licencję open source. Zaznaczyć zaś należy, iż wpisywanie takich oświadczeń do umów jest powszechne, co oczywiście nie znajduje właściwego odzwierciedlenia w stanie faktycznym.

Z kolei, aby odpowiedzieć na pytanie, komu przysługują majątkowe prawa autorskie do programu komputerowego, konieczne jest poznanie faktów i rzeczywistego procesu tworzenia danego oprogramowania. Majątkowe prawa autorskie powstają bowiem z mocy prawa, zaś wykonawca nie może przenieść więcej praw niż sam posiada – nawet, gdyby zamawiający działał w dobrej wierze.

Z perspektywy zamawiającego niezwykle istotne jest umieszczenie w treści umowy stosownych obowiązków po stronie wykonawcy w zakresie zwolnienia zamawiającego z odpowiedzialności za naruszenie praw autorskich, jak również obowiązków sanowania ewentualnych wad prawnych. Powyższe stanowi element zabezpieczający zamawiającego przed pojawianiem się roszczeń ze strony prawdziwych lub rzekomych twórców oprogramowania. Wykonawca zaś powinien być zainteresowany tym, aby osoby trzecie, które współpracowały w pisaniu programu komputerowego nie podnosiły roszczeń wobec jego kontrahenta.

Kto jest odpowiedzialny za wady?

Warunki licencyjne typu open source zazwyczaj przewidują bardzo daleko idące ograniczenie odpowiedzialności za wady takiego oprogramowania komputerowego. Umowa powinna zatem regulować, biorąc pod uwagę interesy wykonawcy, adekwatne zasady jego odpowiedzialności za usterki serwisu internetowego spowodowane błędnym działaniem oprogramowania komputerowego.

Jakie wynagrodzenie należne jest wykonawcy?

Regulacje wskazujące na zakres uprawnień wykonawcy do wynagrodzenia obejmującego dostarczenie rozwiązań objętych licencją open source są indywidualnie określone dla każdej z licencji. Poglądowo, na podstawie licencji GNU GPL i podobnej wykonawca nie może żądać zapłaty za samo prawo korzystania z oprogramowania przyznane na podstawie licencji. Może jednak pobierać opłaty za dostarczenie kopii oprogramowania, jak również za serwisowanie oprogramowania i świadczenia gwarancyjne (powyższe stanowi jedno z podstawowych źródeł dochodów podmiotów, które zajmują się produkcją i dystrybucją programów komputerowych z wykorzystaniem elementów oprogramowań typu open source).

Kluczowym zadaniem zamawiającego, jak i wykonawcy, jest więc identyfikacja indywidualnych zagrożeń prawnych odnoszących się do produktów wykorzystujących w swoich ramach fragmenty oprogramowań open source regulowanych przez właściwe warunki licencyjne, które to są tworzone, dystrybuowane lub wykorzystywane w ramach prowadzonej przez nich działalności gospodarczej.

Katarzyna Ożga - radca prawny w Kancelarii KSZ Smart Legal