Prawo autorskie w software house
Prawo autorskie odgrywa ogromną rolę w dziedzinie tworzenia oprogramowania. Wynika to z faktu, że programy komputerowe, niezależnie od formy wyrażenia (czyli zarówno kod źródłowy, jak i wynikowy, a w pewnych przypadkach także dokumentacja projektowa programu), chronione są jak utwory literackie. Oprogramowanie nie jest jednak jedynym rezultatem pracy programisty zatrudnionego w software house, ponieważ w procesie tworzenia oprogramowania powstają również m.in. dokumentacja programu, projekty, plany, koncepty, analizy, czy raporty. Tego rodzaju rezultaty również mogą podlegać ochronie prawnoautorskiej.
W prawie autorskim wyróżnia się (i) autorskie prawa osobiste (np. prawo do oznaczenia dokumentacji programu nazwiskiem osoby, która ją sporządziła) zawsze przysługujące osobie, która stworzyła utwór oraz (ii) autorskie prawa majątkowe (tj. prawo do korzystania z utworu, np. prawo do udzielania licencji na korzystanie z programu komputerowego) przysługujące co do zasady twórcy, czyli osobie, która stworzyła utwór.
Problematyczne autorskie prawa osobiste
Autorskie prawa osobiste związane są z osobą twórcy i obejmują m.in. jego prawo do (i) autorstwa utworu, (ii) oznaczania utworu swoim nazwiskiem, pseudonimem lub anonimowego udostępnienia, (iii) prawo do nienaruszalności treści i formy utworu oraz jego rzetelnego wykorzystania, (iv) prawo do decydowania o pierwszym udostępnieniu utworu publicznie, (v) prawo do nadzoru nad sposobem korzystania z utworu. W przypadku programów komputerowych, autorskie prawa osobiste twórcy nie obejmują praw wymienionych w punktach (iii)-(v).
Powyższe prawa twórcy są nieograniczone w czasie, niepodlegające zrzeczeniu się oraz niemożliwe do przeniesienia, w tym zbycia. Bardzo często ich wykonywania przez osobę zatrudnioną w software house nie można pogodzić w ekonomicznymi interesami firmy i wobec tego, umowy o pracę lub o świadczenie usług powinny znacznie ograniczać możliwość wykonywania autorskich praw osobistych przez pracownika lub zleceniobiorcę oraz upoważniać pracodawcę do ich wykonywania i udzielania dalszych upoważnień, np. klientom, którym oprogramowanie i towarzysząca mu dokumentacja jest sprzedawane lub licencjonowane.
Często identyfikowanym ryzykiem jest nie tylko całkowite pominięcie regulacji autorskich praw osobistych w umowie z programistą, ale również ich nieprawidłowe uregulowanie, polegające np. na zawarciu w umowie postanowienia o zrzeczeniu się tych praw. Taka klauzula będzie w świetle obowiązującego prawa nieważna.
Pracodawca nie zawsze nabędzie prawa do utworów pracowniczych
Samo zatrudnienie pracownika nie oznacza, że prawa autorskie do wszystkich stworzonych przez niego utworów przechodzą na pracodawcę. Ustawa o prawach autorskich i prawach pokrewnych) nakłada wiele pułapek na pracodawcę. Brak dobrze przemyślanych postanowień w umowie o pracę dotyczących nabycia praw autorskich przez pracodawcę wiąże się z poważnym ryzykiem na etapie sprzedaży biznesu, wynikającym m.in. z:
a) wątpliwości co do zakresu obowiązków pracowniczych (pracodawca wg ustawy nabywa prawa do utwór stworzonych przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy);
b) wątpliwości co do pól eksploatacji, na których doszło do przeniesienia praw (w modelu ustawowym pracodawca nabywa autorskie prawa majątkowe w granicach wynikających z celu umowy o pracę i zgodnego zamiaru stron);
c) wątpliwościami co do przyjęcia utworu przez pracodawcę (w modelu ustawowym pracodawca nabywa prawa autorskie z chwilą przyjęcia utworu);
d) nie przystąpienia przez pracodawcę do rozpowszechniania utworu (w modelu ustawowym, jeżeli pracodawca, w okresie dwóch lat od daty przyjęcia utworu, nie przystąpi do rozpowszechniania utworu przeznaczonego w umowie o pracę do rozpowszechnienia, pracownik może wyznaczyć pracodawcy na piśmie odpowiedni termin na rozpowszechnienie utworu z tym skutkiem, że po jego bezskutecznym upływie prawa uzyskane przez pracodawcę wraz z własnością przedmiotu, na którym utwór utrwalono, powracają do twórcy-pracownika);
e) możliwością wykonywania przez pracownika praw osobistych do utworów (np. sprzeciwiania się wprowadzaniu zmian do utworów).
W przypadku utworów będących programami komputerowymi część z powyższych problemów odpada (regulacja ustawowa zapewnia wyższy poziom ochrony pracodawcy). Niemniej, dobrze skonstruowana umowa z twórcą oprogramowania ma bardzo istotne znaczenie, nie tylko dla zabezpieczenia praw autorskich do programów komputerowych, ale również praw do innych rezultatów pracy programisty (np. dokumentacji, projektów, analiz, planów).
Jeżeli w zawartych umowach o pracę są błędy, to warto je naprawić przed rozpoczęciem badania due diligence przez kupującego (o badaniu due diligence piszemy pod koniec wpisu). W praktyce spotkać się można z porozumieniami zawieranymi z pracownikami w trakcie przygotowania się do sprzedaży biznesu, gdzie pracownicy przenoszą na pracodawcę w szerokim zakresie prawa do stworzonych w przeszłości utworów.
Nagłówek odnoszący się do sekcji CTA wewnątrz bloga
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec vestibulum volutpat augue, ut scelerisque elit rutrum nec. Quisque tincidunt quam ut nunc gravida dapibus. Nulla non urna non tellus sodales euismod eget non sapien.
Programiści w formule B2B
Popularną formułą zatrudnienia w branży IT jest B2B (ang. business-to-business), czyli świadczenie usług na rzecz software house przez osobę posiadającą własną działalność gospodarczą. Z prawnego punktu widzenia taką relację opisuje najlepiej umowa zlecenia, a precyzyjniej, umowa o świadczenie usług lub umowa o dzieło w przypadku pracy projektowej. Niemniej jednak, wciąż spotkać się można z sytuacją gdzie programista i software house nie zawierają żadnej pisemnej umowy, wiążąc się jedynie ustnym lub mailowym porozumieniem.
Ponieważ prawo autorskie przewiduje, że umowa przenosząca autorskie prawa majątkowe musi być zawarta na piśmie, w przypadku niezawarcia pisemnej umowy, software house nie nabywa praw do żadnych rezultatów pracy osoby zatrudnionej w ten sposób. Zazwyczaj w takich przypadkach uznaje się, że programista udzielił firmie dorozumianej licencji na korzystanie z efektów jego pracy, ale taka licencja może zostać w każdym czasie wypowiedziana.
Należy również podkreślić, że regulacje dotyczące nabycia przez pracodawcę praw do utworów pracowniczych znajdują zastosowanie wyłącznie w przypadku zatrudnienia na umowie o pracę. W przypadku programistów pracujących w formule B2B konieczne będzie więc zawarcie umowy regulującej szczegółowo kwestie przeniesienia praw autorskich do efektów jego pracy.
Nieposiadanie praw autorskich do rezultatów pracy programistów świadczących usługi w formule B2B, a także konsultantów czy innych osób, niezatrudnionych w spółce na umowę o pracę, będzie stanowić bardzo istotne oraz trudne do usunięcia ryzyko transakcyjne.
Korzystanie z cudzego (i dawniej własnego) kodu
W praktyce programowania bardzo często korzysta się z komponentów lub całych bibliotek dostępnych w internecie, np. w serwisie GitHub. Może zdarzyć się również, że programista, wykorzysta fragmenty kodu, które opracował wcześniej, tworząc oprogramowanie dla innej firmy. Obie sytuacje narażają software house zatrudniający lub korzystający z usług takiego programisty na ryzyko w przypadku nieprawidłowego uregulowania kwestii korzystania z cudzego oprogramowania w umowie o pracę lub umowie B2B.
W pierwszym przypadku, włączenia do programu kodu pochodzącego z otwartych źródeł, tj. wolnego lub otwartego oprogramowania (ang. free and open-source software, FOSS) może dojść do naruszenia licencji, na jakiej taki kod został udostępniony, w szczególności jeżeli w komercyjnym projekcie wykorzystane zostanie oprogramowanie udostępnione na podstawie licencji zawierającej klauzulę copyleft, np. popularnej GNU GPL.
W razie wykorzystania przez programistę kodu, który opracował na potrzeby pracy w innej firmie, dojdzie do naruszenia praw autorskich przysługujących tej firmie, jeżeli programista przeniósł na tę firmę prawa autorskie do stworzonego programu.
Umowa z programistą powinna wyraźnie regulować kwestię wykorzystywania cudzego kodu, np. zupełnie zakazując takiej praktyki lub uzależniać możliwość skorzystania z kodu open source od zgody firmowego prawnika oraz określać odpowiedzialność programisty wobec software house, w przypadku gdyby osoba trzecia zwróciła się do firmy z roszczeniami z tytułu naruszenia praw autorskich.
Jak możemy Ci pomóc?
We wcześniejszych wpisach poruszaliśmy już szeroko temat badania spółki przed jej zakupem, czyli due diligence. W dużym skrócie, prawne due diligence polega na przeprowadzeniu analizy prawnych aspektów prowadzenia działalności, w tym np. tytułu prawnego do udziałów i kluczowych aktywów (np. praw autorskich) oraz umów z pracownikami i kontrahentami. Jego celem jest identyfikacja i ocena ryzyka związanego z zakupem spółki oraz weryfikacja jej wartości.
Wszelkie nieprawidłowości oraz ryzyka zidentyfikowane przez kupującego w toku badania due diligence wzmocnią jego pozycję negocjacyjną oraz mogą przełożyć się na obniżenie spodziewanej ceny za udziały. W przypadku zidentyfikowania istotnych ryzyk związanych z kluczowymi aktywami nabywanej spółki, kupujący może nawet zrezygnować z zakupu spółki. Z tego powodu warto rozważyć przeprowadzenie wewnętrznego badania due diligence (ang. vendor’s due diligence) i jeszcze przed transakcją, z pomocą prawnika, naprawić zidentyfikowane problemy.
W przypadku zidentyfikowania nieprawidłowości w obszarze prawa autorskiego możliwe będzie podjęcie działań w celu ich wyeliminowania lub zmniejszenia ryzyka, które się z nimi wiążę. Warto skorzystać przy tym z pomocy doświadczonego prawnika transakcyjnego, który pomoże przygotować spółkę do sprzedaży oraz poprowadzi negocjacje z kupującym. Skontaktuj się z nami, jeżeli zależy Ci na uzyskaniu profesjonalnej pomocy w procesie sprzedaży software house’u.