
Jeśli prowadzisz software house, tworzysz oprogramowanie lub zarządzasz zespołem deweloperskim, prawa autorskie wpływają na każdą umowę, którą podpisujesz. Brak odpowiednich zapisów oznacza ryzyko utraty praw do kodu, sporu z klientem lub współpracownikiem i realnych strat finansowych. Poniżej znajdziesz konkretne zasady: czym różnią się prawa osobiste od majątkowych, kiedy wybrać licencję zamiast przeniesienia praw i jak zabezpieczyć się w umowach z pracownikami, kontrahentami B2B oraz zleceniobiorcami.
Copyright Law określa relację twórcy z dziełem, które stworzył. Reguluje, kto może korzystać z utworu, na jakich zasadach i kto czerpie z niego korzyści. W praktyce dzieli się na dwie kategorie, które rządzą się odmiennymi regułami.
Majątkowe prawa autorskie to ekonomiczna strona utworu. Dotyczą korzystania z niego i czerpania korzyści finansowych.
Autorskie prawa osobiste regulują więź twórcy z dziełem. Obejmują m.in.:
Tych praw nie da się przenieść. Nie wygasają też z upływem czasu.
Mimo że praw osobistych nie przeniesiesz, możesz je uregulować w umowie. Twórca może zobowiązać się, że nie będzie z nich korzystał – np. nie będzie domagał się oznaczenia autorstwa w kodzie przekazanym klientowi. Jeśli tego nie uregolujesz, twórca zachowuje pełną swobodę w wykonywaniu tych praw.
Masz dwie ścieżki: przeniesienie praw w całości albo udzielenie licencji. Każda z nich wymaga innego podejścia i daje inne możliwości.
Przeniesienie praw autorskich to trwałe przekazanie wszystkich majątkowych praw do utworu – np. do kodu źródłowego lub jego fragmentu. Po zawarciu umowy nabywca korzysta z utworu tak, jakby był jego twórcą.
Co to oznacza w praktyce:
Bezwzględny wymóg: forma pisemna. Umowa o przeniesienie praw autorskich musi być zawarta na piśmie. Ustalenia ustne, mailowe czy w komunikatorze nie wystarczą – umowa bez formy pisemnej jest nieważna z mocy prawa. To jeden z najczęstszych błędów w branży IT.
Licencja to zgoda na korzystanie z utworu w określonym zakresie, bez przenoszenia praw. Twórca nadal pozostaje właścicielem majątkowych praw autorskich.
Licencjobiorca:
| Cecha | Licencja wyłączna | Licencja niewyłączna |
|---|---|---|
| Liczba licencjobiorców | Jeden – twórca nie udziela licencji nikomu innemu | Bez ograniczeń – twórca może licencjonować utwór dowolnej liczbie podmiotów |
| Forma umowy | Pisemna pod rygorem nieważności | Dowolna (choć pisemna zalecana) |
| Pozycja licencjobiorcy | Wyłączny dostęp do utworu | Współdzielony dostęp |
Nie ma jednej odpowiedzi. Decyzja zależy od modelu biznesowego i roli, jaką pełnisz w danym projekcie.
Niezależnie od tego, czy przenosisz prawa, czy udzielasz licencji, w umowie ureguluj:
Zasady nabywania praw autorskich zależą od rodzaju umowy łączącej Twoją firmę z twórcą. To częste źródło problemów – szczególnie gdy brakuje odpowiednich zapisów.
Pracodawca nabywa majątkowe prawa autorskie do utworu stworzonego przez pracownika w ramach jego obowiązków służbowych. Dzieje się to z mocy prawa – nie potrzebujesz dodatkowej umowy.
Ale uwaga – w umowie o pracę warto mimo to uregulować:
Jeśli zakres obowiązków jest opisany ogólnikowo, pojawia się ryzyko sporu o to, czy dany kod w ogóle podlega automatycznemu przejściu praw.
Przy współpracy B2B nie następuje automatyczne przeniesienie praw autorskich. Musisz to wprost uregulować w umowie.
W umowie B2B zadbaj o:
Tak samo jak w B2B – zamawiający lub zleceniodawca nie nabywa automatycznie praw autorskich od wykonawcy. Umowa musi zawierać postanowienia o przeniesieniu praw. Bez nich prawa pozostają przy twórcy, nawet jeśli zapłaciłeś za wykonanie dzieła.
Zanim podpiszesz jakąkolwiek umowę dotyczącą praw autorskich, sprawdź:
Jeśli prowadzisz software house lub zespół deweloperski:
Każdy miesiąc bez uregulowanych praw autorskich to okres, w którym kod w Twojej firmie formalnie może nie należeć do Ciebie. Im szybciej uporządkujesz dokumentację, tym mniejsze ryzyko sporu o prawa do oprogramowania.
Jaka jest różnica między autorskimi prawami osobistymi a majątkowymi do kodu? Majątkowe prawa autorskie to ekonomiczna strona utworu – można je przenieść na inny podmiot, licencjonować i czerpać z nich korzyści finansowe. Autorskie prawa osobiste chronią więź twórcy z dziełem (np. prawo do oznaczenia autorstwa) – nie da się ich przenieść ani zrzec, ale w umowie twórca może zobowiązać się, że nie będzie z nich korzystał.
Kiedy lepiej dać licencję do oprogramowania, a kiedy przenieść prawa autorskie? Licencję wybierz, gdy budujesz produkt SaaS lub aplikację udostępnianą wielu użytkownikom – zachowujesz prawa i możesz udzielać kolejnych licencji. Przeniesienie praw wybierz, gdy nabywasz kod od współpracowników i potrzebujesz pełnej kontroli nad utworem, żeby go dalej rozwijać, sublicencjonować lub przenieść prawa na klienta końcowego.
Czy przeniesienie praw autorskich do kodu musi być zawsze na piśmie? Tak – umowa o przeniesienie majątkowych praw autorskich wymaga formy pisemnej pod rygorem nieważności. Ustalenia ustne, mailowe czy w komunikatorze nie wystarczą, a umowa zawarta bez zachowania tej formy jest nieważna z mocy prawa.
Czy przy współpracy B2B prawa autorskie do kodu przechodzą automatycznie na firmę? Nie. Przy współpracy B2B nie następuje automatyczne przeniesienie praw autorskich – musisz to wprost uregulować w umowie, wskazując przeniesienie praw lub udzielenie licencji, pola eksploatacji, moment przejścia praw oraz zasady wynagrodzenia. Ta sama zasada dotyczy umów o dzieło i umów zlecenie – bez odpowiednich zapisów prawa pozostają przy twórcy, nawet jeśli zapłaciłeś za wykonanie kodu.
Co musi znaleźć się w umowie, żeby skutecznie zabezpieczyć prawa autorskie do oprogramowania? W każdej umowie dotyczącej praw autorskich ureguluj pięć elementów: zakres praw (jakie konkretnie prawa przenosisz lub licencjonujesz), pola eksploatacji (np. kopiowanie, modyfikowanie, dystrybucja), wynagrodzenie z zasadami rozliczeń, moment przeniesienia praw (np. z chwilą odbioru lub zapłaty) oraz zobowiązanie twórcy do niewykonywania autorskich praw osobistych. Pominięcie któregokolwiek z tych punktów generuje ryzyko sporu – np. brak wskazania pól eksploatacji oznacza, że nabywca nie może korzystać z utworu w niewymienionych polach.


