Czy kod źródłowy jest utworem w prawie?

Repozytorium Git może należeć do spółki, dostęp do niego może mieć kilku programistów, a umowa może przewidywać wynagrodzenie za wykonanie aplikacji. Żaden z tych faktów nie rozstrzyga jednak samodzielnie podstawowego pytania: czy kod źródłowy jest utworem w rozumieniu prawa autorskiego i kto może skutecznie decydować o jego wykorzystaniu. W sporach IT problem zwykle ujawnia się za późno – przy odejściu developera, inwestycji due diligence, sprzedaży produktu albo konflikcie z software housem.

Najkrótsza odpowiedź brzmi: co do zasady kod źródłowy programu komputerowego korzysta z ochrony prawnoautorskiej, ale nie dlatego, iż jest kodem. Ochrona wynika z tego, iż stanowi rezultat twórczej działalności o indywidualnym charakterze. Jednocześnie przepisy o programach komputerowych wprowadzają odrębne reguły dotyczące zakresu praw, ich przejścia na pracodawcę oraz dozwolonego korzystania.

Kiedy kod źródłowy jest utworem?

Ustawa o prawie autorskim i prawach pokrewnych chroni każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. Kod źródłowy spełnia warunek ustalenia, gdy został zapisany choćby w pliku, systemie kontroli wersji lub innym nośniku. Nie musi być opublikowany, ukończony ani wolny od błędów.

O twórczości nie przesądza też rozmiar projektu. Krótki skrypt automatyzujący proces może być utworem, a obszerna część aplikacji – niekoniecznie, jeżeli jest wyłącznie mechanicznym odtworzeniem narzuconej specyfikacji albo standardowego rozwiązania. W praktyce próg twórczości jest jednak relatywnie niski. Dobór struktur, organizacja funkcji, architektura modułów, sposób realizacji wymagań i autorska sekwencja poleceń często pozostawiają programiście dostateczną swobodę twórczą.

Prawo autorskie nie chroni natomiast idei, zasad działania, procedur, metod, funkcjonalności ani języka programowania. Konkurent może stworzyć program realizujący podobną funkcję, jeżeli nie kopiuje chronionej ekspresji cudzego rozwiązania. To rozróżnienie bywa najważniejsze dla spółek rozwijających produkty SaaS: monopol prawnoautorski nie obejmuje samego pomysłu na usługę ani modelu biznesowego.

Kod wynikający z konieczności technicznej

Granica ochrony pojawia się tam, gdzie autor nie miał realnej swobody wyboru. o ile określony fragment kodu jest jedynym albo praktycznie jedynym sposobem osiągnięcia danego efektu, argument za jego indywidualnym charakterem słabnie. Podobnie może być z prostymi konfiguracjami, banalnymi deklaracjami danych czy kodem generowanym według ściśle narzuconego wzorca.

Nie oznacza to, iż każdy plik konfiguracji albo fragment boilerplate pozostaje poza ochroną. Ocena dotyczy konkretnej postaci i konkretnych wyborów autora. W sporze sądowym znaczenie mogą mieć dokumentacja techniczna, historia commitów, wymagania projektowe oraz opinia biegłego. Sam fakt, iż kod jest „typowy”, nie zamyka jeszcze dyskusji.

Program komputerowy ma szczególną ochronę

Kod źródłowy jest jedną z postaci programu komputerowego. Ochrona obejmuje także kod wynikowy, czyli postać wykonywalną, a we właściwym zakresie również elementy przygotowawcze prowadzące do stworzenia programu. Polski ustawodawca wdrożył w tym obszarze rozwiązania unijne, dlatego konstrukcja ochrony jest bardziej szczegółowa niż przy wielu innych utworach.

W odniesieniu do programu komputerowego autorskie prawa majątkowe obejmują w szczególności zwielokrotnianie, tłumaczenie, przystosowywanie, zmianę układu i inne modyfikacje oraz rozpowszechnianie. Dla biznesu oznacza to, iż bez adekwatnego tytułu prawnego problematyczne może być nie tylko skopiowanie całej aplikacji, ale także rozwijanie cudzego kodu, utrzymywanie forków czy udostępnianie systemu kolejnym podmiotom.

Warto przy tym odróżnić nabycie egzemplarza lub dostępu do systemu od nabycia praw autorskich. Klient, który zapłacił za wdrożenie, nie uzyskuje automatycznie prawa do dowolnego kopiowania, modyfikacji lub przekazania kodu innej firmie. Zakres jego uprawnień zależy od umowy, a w pewnych sytuacjach także od ustawowych uprawnień legalnego użytkownika programu.

Kto jest właścicielem praw do kodu?

Potoczne określenie „własność kodu” bywa wygodne, ale prawnie nieprecyzyjne. Należy ustalić, komu przysługują autorskie prawa majątkowe, kto wykonuje autorskie prawa osobiste oraz jaki zakres licencji albo przeniesienia praw wynika z dokumentów projektowych.

Punktem wyjścia jest zasada, iż twórcą jest osoba fizyczna, która stworzyła utwór. Spółka nie tworzy kodu w sensie autorskoprawnym, ale może nabyć prawa majątkowe. W relacji pracowniczej program komputerowy ma szczególny reżim: prawa majątkowe co do zasady przysługują pracodawcy, o ile program został stworzony przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy. Nie trzeba wówczas każdorazowo podpisywać odrębnego przeniesienia praw.

Ta reguła nie rozciąga się automatycznie na współpracownika B2B, członka zarządu, wspólnika, stażystę ani podwykonawcę software house’u. Przy kontrakcie B2B konieczne jest precyzyjne postanowienie o przeniesieniu praw albo licencji. o ile strony wybierają przeniesienie, umowa powinna mieć formę pisemną pod rygorem nieważności i wskazywać pola eksploatacji. Ogólne sformułowanie, iż „wszelkie prawa przechodzą na klienta”, może nie zapewnić oczekiwanego rezultatu.

Łańcuch praw w projektach zespołowych

W produkcie tworzonym przez zespół największym ryzykiem jest luka w łańcuchu praw. Spółka może mieć prawidłową umowę z głównym wykonawcą, ale wykonawca powinien równocześnie zapewnić skuteczne nabycie praw od własnych programistów i podwykonawców. W przeciwnym razie klient otrzymuje zapewnienie kontraktowe, którego realizacja może wymagać późniejszego dochodzenia roszczeń od dostawcy.

Szczególnej ostrożności wymagają projekty budowane na bazie wcześniejszych komponentów developera, bibliotek open source oraz kodu wygenerowanego przy użyciu narzędzi AI. W każdym z tych przypadków źródło kodu i warunki użycia mogą ograniczać możliwość jego zamknięcia, sublicencjonowania lub sprzedaży inwestorowi.

Open source nie oznacza braku praw autorskich

Licencja open source jest sposobem wykonywania praw autorskich, a nie rezygnacją z nich. Autor lub inny uprawniony udziela zgody na korzystanie z programu pod określonymi warunkami. Niektóre licencje są liberalne i pozwalają na szerokie wykorzystanie komercyjne, inne wymagają zachowania informacji o licencji, udostępnienia kodu źródłowego zmian albo objęcia dalszej dystrybucji podobnymi warunkami.

Dla zarządu istotne jest nie tylko pytanie, czy zespół korzysta z komponentów open source, ale także z jakich licencji, w jakiej części produktu i czy produkt jest dystrybuowany. Obowiązki licencyjne mogą wyglądać inaczej w modelu instalowanego oprogramowania, inaczej w usłudze chmurowej, a jeszcze inaczej przy przekazywaniu kodu klientowi. Z tego powodu polityka open source i ewidencja komponentów są elementem zarządzania IP, nie formalnością dla działu technicznego.

Kod wygenerowany przez AI: kto stworzył utwór?

Narzędzia generatywne komplikują analizę, ponieważ polskie prawo autorskie opiera się na założeniu ludzkiego twórcy. o ile wynik został wygenerowany automatycznie, bez twórczych wyborów człowieka dotyczących jego finalnej postaci, może nie powstać utwór chroniony prawem autorskim. To nie znaczy, iż taki kod można bez ryzyka traktować jako zasób wolny od ograniczeń.

Po pierwsze, warunki korzystania z danego narzędzia mogą regulować uprawnienia do outputu. Po drugie, kod wygenerowany przez model może zawierać elementy zbliżone do cudzych fragmentów albo prowadzić do naruszenia tajemnicy przedsiębiorstwa, gdy do promptów wprowadzono dane projektowe. Po trzecie, programista, który twórczo selekcjonuje, poprawia i integruje output z architekturą systemu, może stworzyć chroniony rezultat, choć sama automatyczna propozycja modelu ochrony nie uzyskała.

W praktyce warto dokumentować udział człowieka w procesie tworzenia, ustalić zasady używania narzędzi AI oraz wprowadzić przegląd licencyjny i bezpieczeństwa dla kodu trafiającego do produkcji. To bardziej użyteczne niż próba wpisania w umowę prostego zapewnienia, iż „AI nie była używana”.

Co powinna sprawdzić firma przed wdrożeniem lub transakcją?

Przed komercjalizacją produktu, audytem inwestorskim albo zmianą dostawcy należy ustalić, kto faktycznie tworzył najważniejsze elementy systemu i na jakiej podstawie firma korzysta z rezultatów tej pracy. Weryfikacja powinna objąć umowy pracownicze i B2B, postanowienia o podwykonawcach, zasady odbioru utworów, repozytoria, użyte komponenty zewnętrzne oraz warunki narzędzi AI.

Należy również zdecydować, czy spółce potrzebne jest przeniesienie praw, czy wystarczy licencja. Przeniesienie daje silniejszą pozycję przy sprzedaży aktywów i zmianie modelu biznesowego, ale licencja może być wystarczająca, gdy dostawca rozwija własną platformę dla wielu klientów. najważniejsze jest, aby zakres korzystania odpowiadał rzeczywistym planom: utrzymaniu, modyfikacji, skalowaniu, przekazaniu kodu inwestorowi i współpracy z kolejnym wykonawcą.

Dobrze przygotowana dokumentacja IP nie jest dodatkiem do developmentu. Jest warunkiem, by firma mogła bezpiecznie korzystać z technologii, którą finansuje i rozwija. Gdy kod staje się centralnym aktywem przedsiębiorstwa, pytanie o jego autorskoprawny status warto zadać na etapie pierwszego commitu, a nie dopiero wtedy, gdy dostęp do repozytorium przestaje działać.