1. Zacznij od mapy produktu i autorów
Działająca aplikacja nie jest jednym, jednorodnym przedmiotem prawa. Obejmuje kod własny, biblioteki, dokumentację, grafiki, interfejs, bazy danych i usługi zewnętrzne. Każdy element może pochodzić od innego autora i podlegać innej umowie. W audycie najpierw identyfikuje się wersję produktu, repozytoria, historię wkładów, twórców oraz podmiot, który ma dalej rozwijać, rozpowszechniać lub sprzedawać rozwiązanie. Sam dostęp do repozytorium nie dowodzi nabycia praw. [1] [2]
Dobrą jednostką analizy jest moduł powiązany z autorem, datą powstania, podstawą współpracy i dokumentem nabycia lub licencji. Faktura za „wykonanie aplikacji” potwierdza rozliczenie, ale nie odpowiada automatycznie na wszystkie pytania o pola eksploatacji, modyfikacje i dalsze licencjonowanie. W raporcie oddziela się prawa udokumentowane od zapewnień ustnych i od braków. Lista ta powinna obejmować również wkłady założycieli powstałe przed utworzeniem spółki.
2. Pracownik i wykonawca B2B to różne podstawy
W polskiej ustawie art. 74 ust. 3 przewiduje, co do zasady, że prawa majątkowe do programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, jeżeli umowa nie stanowi inaczej. Trzeba wykazać stosunek pracy i związek programu z obowiązkami. Nie należy rozszerzać tej szczególnej reguły na dowolną grafikę ani na każdy prywatny projekt osoby zatrudnionej w firmie. [1]
Przy współpracy B2B konieczna jest analiza treści umowy, uprawnienia wykonawcy do praw otrzymanych od podwykonawców i zachowania wymaganej formy. Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności; forma pisemna dotyczy też licencji wyłącznej. Umowa powinna wyraźnie obejmować ustalone pola eksploatacji. Skan podpisu, wiadomość e-mail i kwalifikowany podpis elektroniczny nie są tożsamymi kategoriami prawnymi. Konkretna forma zawarcia wymaga sprawdzenia. [1]
3. Sprawdź, czy umowa pozwala na planowany model biznesowy
Dla programu znaczenie mają zwielokrotnianie, tłumaczenie i przystosowanie, zmiany oraz rozpowszechnianie. Audyt powinien sprawdzać, czy klient może utrzymywać system, powierzyć rozwój nowemu dostawcy, udostępnić rozwiązanie w grupie kapitałowej i oferować je dalszym odbiorcom. Od prawa autorskiego oddziela się operacyjny dostęp: kod źródłowy, instrukcję budowania, konfigurację, domenę, konta i klucze. Prawo do korzystania niewiele pomaga, gdy brak możliwości uruchomienia aktualnej wersji. [1] [2]
Przykład hipotetyczny: spółka kupuje aplikację, lecz jeden moduł napisał nieobjęty umową podwykonawca. Zapewnienie głównego wykonawcy o „pełnych prawach” nie uzupełnia samo brakującego ogniwa. Należy ustalić autora i podstawę korzystania, uzupełnić dokumentację, uzyskać właściwe uprawnienie albo zastąpić moduł. Taki problem jest istotny przy sprzedaży produktu i inwestycji, nawet gdy aplikacja od lat funkcjonuje bez sporu.
4. SAS Institute: funkcja programu a chroniona forma wyrażenia
W wyroku SAS Institute, C-406/10, TSUE wskazał, że funkcjonalność programu, język programowania i format plików danych używany do wykorzystania jego funkcji nie stanowią jako takie formy wyrażenia programu chronionej na podstawie dyrektywy o programach komputerowych. To ważne rozróżnienie pomiędzy pomysłem lub zasadą działania a konkretną postacią kodu. Wyrok nie ustanawia jednak ogólnego prawa do kopiowania cudzych materiałów. [3]
Ochronie mogą podlegać konkretne elementy będące własną twórczością autora, w tym odpowiednia treść dokumentacji. Legalny użytkownik może w ustawowych granicach obserwować, badać i testować funkcjonowanie programu; dekompilacja dla interoperacyjności podlega odrębnym, ścisłym przesłankom. Projekt zgodnego narzędzia powinien dokumentować legalne źródła wiedzy i sposób pracy. Odrębnej oceny mogą wymagać poufność, umowy, dane oraz inne prawa. [2] [3]
5. UsedSoft: ostrożnie z „odsprzedażą licencji”
Sprawa UsedSoft, C-128/11, dotyczyła wyczerpania prawa do rozpowszechniania kopii programu pobranego z internetu przy określonym modelu transakcji: uprawnienie bez ograniczenia w czasie, opłata odpowiadająca wartości ekonomicznej kopii i pierwsze wprowadzenie do obrotu za zgodą uprawnionego w UE. TSUE analizował łącznie pobranie kopii oraz udzielenie licencji. Sama nazwa umowy nie rozstrzyga o skutkach. [4]
Przy dalszym zbyciu pierwotny nabywca powinien uczynić własną kopię niezdatną do użytku; wyrok zawiera też ograniczenia dotyczące dzielenia pakietów licencji. Nie należy wyprowadzać z niego automatycznej zbywalności każdej subskrypcji, usługi chmurowej ani każdego cyfrowego utworu. Dla audytu rynku wtórnego potrzebne są dokumenty pierwotnego nabycia, zakres uprawnienia, historia przeniesień i dowody zaprzestania używania. Brak tej historii jest konkretnym ryzykiem dowodowym. [4]
6. Open source: obowiązki ustala się dla konkretnej wersji
Wykaz zależności powinien obejmować nazwę, wersję, źródło, licencję, modyfikacje i sposób dystrybucji każdego komponentu. Standard SPDX pomaga wymieniać informacje o składnikach i licencjach; sam raport narzędzia nie jest opinią, że wszystkie warunki spełniono. Trzeba sprawdzić pliki licencyjne, wyjątki, podwójne licencjonowanie i zależności przechodnie. Osobno zapisuje się użycie wewnętrzne, udostępnianie kopii i dostęp sieciowy, ponieważ znaczenie tych zdarzeń zależy od tekstu licencji. [5]
Na przykład GPLv3 określa obowiązki przy przekazywaniu kodu obiektowego, w tym dotyczące odpowiedniego kodu źródłowego i informacji licencyjnych. Nie każda biblioteka open source ma taki sam model i nie każde użycie automatycznie nakazuje publikację całego produktu. Wniosek wymaga analizy konkretnego połączenia i dystrybucji. Wynikiem audytu powinny być także działania: uzupełnienie notices, dostarczenie źródeł, wymiana zależności albo uzyskanie innej licencji, z właścicielem zadania i terminem. [6]
Źródła i dalsza lektura
- 1Ustawa o prawie autorskim i prawach pokrewnych ↗
Dz. U. 2025 poz. 24 ze zm.; art. 41,53,67,74–77
Oficjalna metryka z odnośnikiem do tekstu ujednoliconego; prawa pracownicze i forma umów.
- 2Dyrektywa o ochronie prawnej programów komputerowych ↗
Dyrektywa 2009/24/WE; art. 1–6,9
Zakres ochrony, czynności legalnego nabywcy oraz przesłanki interoperacyjności.
- 3TSUE: SAS Institute przeciwko World Programming ↗
C-406/10, 2.05.2012, ECLI:EU:C:2012:259, pkt 39–46,54–61,66–70
Funkcjonalność, język, format danych i dokumentacja — różne przedmioty oceny.
- 4TSUE: UsedSoft przeciwko Oracle ↗
C-128/11, 3.07.2012, ECLI:EU:C:2012:407, pkt 42–49,69–71,78–88
Warunki wyczerpania prawa do rozpowszechniania kopii programu i ograniczenia odsprzedaży.
- 5SPDX — specyfikacje standardu ↗
SPDX: Software Package Data Exchange; specyfikacje projektu Linux Foundation
Dokumentowanie składników i informacji licencyjnych; nie zastępuje analizy prawnej.
- 6GNU GPLv3 — oficjalny tekst w dokumentacji GCC ↗
GNU General Public License, version 3, 29.06.2007; sekcje 4–6
Tekst licencji, a nie ustawa; przykład obowiązków konkretnej rodziny licencyjnej.
Rekel Patent — serwis o własności intelektualnej. Wydawca: Vadym Rekel.