Prawa autorskie do oprogramowania - co tak naprawdę kupujesz, zlecając system IT?

Wprowadzenie do tematu – o co chodzi z prawami autorskimi?

Cześć, dzień dobry, z tej strony Grzegorz Tabor, a to jest podcast IT i biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menedżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia twojego biznesu świadomie z użyciem technologii, ten podcast jest dla ciebie. Odcinek 61. Prawa autorskie do oprogramowania. Co tak naprawdę kupujesz zlecając system IT? W tym odcinku poruszamy temat, który może uratować cię przed utratą kontroli nad własnym projektem IT.

Ryzyko: Kod działa, ale nie masz do niego żadnych praw

Wyobraź sobie, że przez miesiące rozwijasz system z wykonawcą.

Wszystko idzie dobrze, aż nagle coś się psuje. Szukasz innego partnera i wtedy okazuje się, że nie masz żadnych praw do tego co powstało. Kod działa, ale nie możesz go rozwijać, przekazać, ani nawet skorzystać z niego w jakikolwiek sposób.

Dlaczego? Bo nie zadbałeś bądź nie zadbałaś o prawidłowe przeniesienie majątkowych praw autorskich. I w tym odcinku właśnie poruszymy ten temat w szczegółach. Uważam, że jest to must have odcinek dla każdego, kto zleca tworzenie systemów, aplikacji czy rozwoju oprogramowania niezależnie od tego, czy jest to forma współpracy z software housem, freelancerem, czy też zespołem wewnętrznym.

Jeśli chcesz spać spokojnie i naprawdę posiadać to za co płacisz, to posłuchaj do końca. I tym oto krótkim wstępem serdecznie zapraszam do wysłuchania części głównej dzisiejszego odcinka.

Cześć, dzień dobry.

Serdecznie witam was w odcinku 61, w którym rozkładamy na czynniki pierwsze temat jakże istotny, a często zapominamy, czyli prawa autorskie. Wyobraź sobie, że przez kilka miesięcy tworzysz z wykonawcą swój system, aplikację, która ma wspierać twoją firmę, ułatwiać życie twoim klientom i pracownikom. Płacisz faktury, projekt się rozwija, jesteście coraz bliżej celu, aż w końcu coś się psuje.

Może komunikacja, może jakość, może przekroczony budżet. Rozważasz poszukiwanie innego partnera i wtedy orientujesz się, że tak naprawdę nie masz żadnych praw do tego co powstało. Kod jak najbardziej jest i nawet działa, ale formalnie nie możesz go dalej rozwijać, nie możesz przekazać go innemu wykonawcy.

I w tym odcinku rozmawiamy właśnie o tym, co naprawdę kupujesz, kiedy zlecasz tworzenie oprogramowania, dlaczego zapłacenie faktury to za mało, żeby móc powiedzieć to jest mój kod i mogę go używać. I nie będziemy tutaj oczywiście wchodzić w język prawniczy, bo nie taka jest nasza rola, natomiast chcielibyśmy tutaj w ramach tego odcinka bardzo mocno urealnić Was z tym, w jaki sposób podchodzić do kwestii praw autorskich, żeby zwyczajnie mówiąc i kolokwialnie mówiąc się nie naciąć. I teraz zobaczcie.

Wyobraźmy sobie, że zaczynamy w ten sposób, że nawiązujemy współpracę z jakimś software housem, programistą na przykład na umowy B2B. I zlecamy stworzenie systemu, aplikacji czy jakiegoś innego rodzaju oprogramowania. Rozliczamy się w modelu niezależnie jakim, czy to fixed price, czyli za cały projekt, czy też w formule bardziej godzinowej typu time and material.

Ale generalnie koniec końców płacimy za coś, za jakieś przepracowane godziny, za jakiś zrealizowany etap prac. No i zakładamy, że skoro płacimy, to produkt należy do Was, jako że to wypłacicie. I prosta logika.

Dlaczego zapłata faktury to za mało?

Jeżeli kupujemy jakiś produkt w sklepie, to po transakcji ten produkt jest nasz. Tyle, że jeżeli chodzi o dobra niematerialne, takie jak na przykład oprogramowanie, to ta zasada zwyczajnie nie działa. Bo samo zapłacenie faktury nie oznacza jeszcze, że nabyłeś też prawa autorskie, majątkowe do kodu.

Kiedy twórca oprogramowania zachowuje prawa do kodu?

Dlaczego? Z punktu widzenia prawa taki kod, czy w ogóle napisany system, to utwór tak samo jak utwór literacki, muzyczny czy graficzny. I zgodnie z prawem autorskim, prawa majątkowe do utworu, przysługują twórcy, czyli osobie, która ten kod napisała. Są oczywiście od tego wyjątki.

Jakie umowy dają Ci pełne prawa do kodu?

Na przykład, jeśli programista jest zatrudniony na umowę o pracę w Twojej firmie, wówczas prawa autorskie dotworzonych przez niego dzieł, domyślnie przechodzą na Was, jako na pracodawcę. Ale w przypadku współpracy B2B, kiedy mamy tutaj do czynienia z takim w pewnym sensie zewnętrznym wykonawcą, co jest bardzo częstym modelem zatrudnień, jeżeli chodzi o obszar IT, to niestety nie jest tak prosto, bo tutaj trzeba ten etap przekazania praw autorskich wyraźnie uregulować w umowie. No i teraz, jak zadbać o to, żeby po zakończeniu projektu, a nawet jeszcze w jego trakcie, mieć te pełne prawa do stworzonego kodu? Bo pamiętajmy, że projekt tworzy trwać trzy miesiące, pół roku, ale czasem nawet i kilka lat.

I dlaczego nie warto czekać do końca współpracy, żeby na spokojnie dopiąć formalności? I teraz, ja tutaj skupię się na tym, że te prawa autorskie nie są naprawdę takie turbo proste. To znaczy, ja nie jestem oczywiście prawnikiem, ale przez lata przewinęło się u nas tyle różnych przypadków, naszych potencjalnych nowych klientów, którzy docelowo klientami zostawiali, że coś nieco już o tym wiem, dlatego chciałem się tym z wami podzielić. Tak, po ludzku.

No i teraz właśnie, jeżeli chodzi o kwestie prawa autorskie u nas, one zawsze przechodzą na klienta, czyli prawa autorskie majątkowe na bieżąco, na podstawie tego, co wykonujemy, przekazujemy na naszych klientów. Chciałbym, żebyście o tym też wiedzieli. Teraz to, o co jeszcze dbamy, to oczywiście dostęp do kodu źródłowego, do repozytorium, czy też do dokumentacji, żeby nikt nigdy nie był zaskoczony tym, jak system został wykonany, dlaczego taka nie inaczej, jak działa i wszelkie te plusy prowadzenia dokumentacji repozytorium i przekazywania praw autorskich majątkowych na bieżąco.

Jeżeli chodzi o kwestie w ogóle tego, co się spotyka w umowach, to bardzo często spotyka się różnego rodzaju licencje.

Czym różni się licencja wyłączna od przeniesienia praw?

To jest też dość ciekawy wątek, bo mamy na przykład licencję wyłączną. Jest to pewien rodzaj licencji, który daje jednej konkretnej osobie lub na przykład firmie wyłączne prawo do korzystania z oprogramowania w określony sposób i jednocześnie zabrania twórcy tego oprogramowania udzielania tej licencji komukolwiek innemu w tym samym zakresie.

Czyli takie przekazanie praw autorskich, ale jednak nie do końca, no bo jak to działa w praktyce? Wyobraźmy sobie taką sytuację. Rok temu rozpocząłeś współpracę z firmą, która miała stworzyć dedykowany system. Początki były obiecujące, jednak z czasem zaczęły się opóźnienia, przekroczenia budżetu i zaczynasz się zastanawiać, czy to ma jeszcze sens.

Szukasz więc innego partnera, który mógłby dokończyć projekt i co się okazuje? Nie możesz przekazać kodu innej firmie. Dlaczego? Bo nie masz do niego pełnych praw. Masz do niego jedynie tą ową licencję wyłączną.

Więc na papierze możesz rzutkować system, ale nie masz prawa udostępniać kodu innym, nawet jeśli chcesz tylko dokończyć rozpoczęty projekt. W związku z tym jesteś w pewnym sensie uwiązany od tego obecnego zestawcy i masz dwie opcje. Albo kontynuować tę nieefektywną współpracę w pewnym sensie zaciskając zęby, albo porzucić projekt i zbudować go zupełnie od nowa.

Inny typ licencji, który się spotyka jako zastępnik tego przekazania prawa autorskich, to licencja niewyłączna. Na pierwszy rzut oka brzmi ona trochę łagodniej, może nawet bezpieczniej, ale często jest tak, że to ona potrafi być najbardziej problematyczna, szczególnie gdy budujemy coś tylko dla siebie.

Licencja niewyłączna – cicha pułapka dla Twojego biznesu

Bo licencja niewyłączna jest takim w pewnym sensie przeciwnikiem licencji wyłącznej, czyli oznacza, że masz prawo korzystać z oprogramowania, ale nie jako jedyny podmiot.

I to jest bardzo częsta pułapka, w którą ludzie wpadają, bo autor lub firma, która stworzyła system, może wówczas ten sam kod sprzedać zwyczajnie w świecie innym klientom, np. waszej konkurencji, lub skorzystać z niego samodzielnie. Więc automatycznie wasza przewaga konkurencyjna, którą chcieliście zbudować skorzystając właśnie z takiej technologii, zwyczajnie idzie w las.

No i mamy też trzecią opcję, o której wspominamy od początku tego odcinka, obok tych licencji, czyli właśnie przeniesienie majątkowych praw autorskich. Czyli to, co w większości przypadku powinno nas interesować najbardziej, szczególnie jeśli budujemy coś dedykowanego, takiego autorskiego typowo dla nas, inwestujemy w to sporo czasu, sporo pieniędzy i chcemy mieć pełną kontrolę nad tym, co powstaje. I teraz co to oznacza w praktyce?

Przeniesienie majątkowych praw autorskich – co to oznacza w praktyce?

Po podpisaniu odpowiedniej umowy z wyraźnym zapisem o przeniesieniu praw autorskich majątkowych, to ty stajesz się właścicielem powstałego kodu, czy oczywiście twoja firma, twoja spółka. Możesz go rozwijać, możesz go przekazać komuś innemu, możesz go przebudować, a nawet możesz go sprzedać dalej. To tak, jakbyś kupił dom i nie tylko możesz w nim mieszkać, ale możesz go też wynająć, sprzedać, zburzyć, czy nawet sklonować i przekazać innym podmiotom, bo to jest twoja decyzja, twój kod, bo masz do niego pełne prawa autorskie, majątkowe. I tutaj jeżeli chodzi o kwestię przypadków z życia, bo dlaczego w ogóle ten temat poruszamy? Bo okazuje się, że dość często zdarza się, że na początku współpracy z potencjalnym klientem właśnie pytamy jak wyglądała ta poprzednia współpraca, staramy się z niej wyciągać wnioski po to, żeby z pewnością nie popełniać błędów poprzedników, ale jednocześnie też jeszcze lepiej zrozumieć sytuację klienta, no i bardzo często okazuje się, że natrafiamy na tak zwaną wadę prawną tego dzieła, które zostało wykonane, co powoduje, że nie zawsze można ten kod, z którym klient do nas przychodzi, no zgodnie z prawem wykorzystać.

Jak unikać błędów i naprawdę posiadać to, za co płacisz?

I zdarzały nam się sytuacje, w których klient musiał, zanim zaczniemy działać, ustalić z poprzednim wykonawcą formę przekazania praw autorskich po fakcie, czyli po wykonaniu tego systemu danego, z którym klient do nas przychodził, co powodowało, że znacznie trudniej ustala się takie rzeczy, kiedy pojawia się być może potencjalne rozliczenie dodatkowe za to przekazanie praw autorskich, bo często z tym to się wiąże, jeżeli ta kwestia nie jest uregulowana na początku, no i jest to znacznie trudniej po prostu zrealizować, co powoduje, że przeniesienie kodu do innego wykonawcy jest po prostu znacznie trudniejsze. Mieliśmy też w historii sytuację, w której nasz klient, kiedy do nas trafił, mógł z nami rozwijać, czy mógłby z nami rozwijać system, z którym do nas przyszedł, tam był akurat to dedykowany e-commerce, natomiast okazało się, że jednak nie może, bo właśnie nie ma do niego praw autorskich, ani nawet jakiejś konkretnie opisanej licencji, co powodowało, że tak naprawdę koniec końców, kiedy tutaj akurat dział prawny ze strony klienta zainteresował się tym tematem, a to był taki stary system, który po czasie ktoś właśnie chciał rozbudowywać, ale z inną właśnie firmą, okazało się, że nie dało się tego zrobić, no bo była to właśnie pewna forma licencji wyłącznej, czy nawet niewyłącznej, w sumie nie do końca pamiętam, ale generalnie forma licencji, w której nie można przekazywać tego kodu dalej do nikogokolwiek innego. No i to jest też taka właśnie tutaj przestroga, że w tym konkretnym wypadku, przez tę wadę prawną budowaliśmy system zupełnie od nowa.

No i oczywiście dla nas ciekawa sprawa, mogliśmy ten system zbudować, na nowo zaprojektować. Koniec końców pewnie wyszło to dość dobrze dla klienta z perspektywy czasu patrząc, bo wiele rzeczy w tym starym systemie musielibyśmy po prostu w cudzysłowie zaorać i zbudować od nowa, co powodowało, że tutaj jeżeli od razu budowaliśmy od nowa, ale projektując na nową architekturę, no to też części rzeczy po prostu nie przenosiliśmy i to koniec końców wyszło dobrze, natomiast no biznesowo było to trochę bardziej ryzykowne, bo jednak budowaliśmy coś, co w pewnym sensie klient już miał i co działało i co można byłoby potencjalnie zrefaktoryzowaćać i rozbudowywać dalej. Dlatego na to bardzo mocno zwracamy wam uwagę, bo te historie naprawdę dobrze pokazują jak łatwo wpaść w taką pułapkę założeń, że skoro płacimy, no to wszystko jest oczywiste i należy do nas, zwyczajnie w świecie, a jednak to co łączy wszystkie te przypadki, to brak jasnych zapisów w umowach ustalonych na etapie podpisywania tych umów, bo często jakby dla tych starych systemów, zwyczajnie w świecie umów brakowało, bo były to bardziej umowy ustne.

Checklista: 4 kluczowe zapisy, które muszą znaleźć się w Twojej umowie

I dlatego na koniec tego odcinka zebrałem jeszcze taką krótką listę rzeczy, które warto sprawdzić, niezależnie od tego czy dopiero zaczynacie nowy projekt, czy jesteście już w jego trakcie. Im wcześniej dowiecie się na czym stoicie w kontekście tych właśnie różnych kwestii związanych z prawami autorskimi czy licencjami, tym łatwiej będzie podjąć decyzję, która zminimalizuje ryzyko. I teraz szybki przegląd tego, co powinno się znaleźć w umowie, jeśli naprawdę chcecie mieć kontrolę nad kodem. Jeśli w twojej umowie nie ma zapisu o przeniesieniu majątkowych praw autorskich, to najprawdopodobniej masz tylko licencję niewyłączną, czyli prawo do korzystania z kodu, ale bez żadnej kontroli nad tym, co się dzieje z nim dalej. No i bez możliwości jego dalszego modyfikowania bez zgody autora tego kodu. Samo zlecenie wykonania systemu i opłacenie faktury to naprawdę za mało, żeby uzyskać prawa do kodu.

I to jest naprawdę jeden z takich najczęstszych błędów. I teraz w umowie musi się znaleźć jasny pisemny zapis o przeniesieniu majątkowych praw autorskich. I co powinno się w ramach tego zapisu znaleźć? Wyraźne sformułowanie o przeniesieniu majątkowych praw autorskich wraz z wyszczególnieniem pól eksploatacji. Moment, w którym następuje przeniesienie praw, na przykład w chwili zapłaty faktury, czy podpisania jakiegoś protokołu odbioru. Uważam, że z perspektywy klienta im łatwiejszy moment przeniesienia praw autorskich, na przykład powiązany z zapłaceniem faktury, tym lepiej, no bo wtedy na bieżąco klient płacąc otrzymuje prawa autorskie do tego, co powstało w ramach faktury, za którą dokonano zapłaty, co powoduje, że w razie jakiejkolwiek potrzeby zmiany wykonawcy, da się ją zrobić i nie ma problemu tutaj, jeżeli chodzi o kwestię wady prawnej.

Repozytorium, dokumentacja i dostęp – co musi znaleźć się w umowie?

Trzecia kwestia to obowiązek przekazania kodu źródłowego dostępu do repozytorium i dokumentacji technicznej.

Jest to rzecz obok praw autorskich, natomiast warto też na to w umowie zwrócić uwagę. No i czwarta rzecz ostatnia to zapis, że wykonawca nie zachowuje żadnych praw do korzystania z kodu w przyszłości. I co ważne, takie przeniesienie musi być w pewnym sensie konkretne, to znaczy nie wystarczy ogólnikowy zapis typu, że kod będzie do nas należał czy będzie naszą własnością.

Co oznacza „pełne prawa”? Pola eksploatacji w praktyce

Trzeba wskazać szczegółowo, do czego masz prawo, na przykład do modyfikacji, utrwalania, publikacji, komercjalizacji czy też dalszego rozwoju tego konkretnego kodu. I tutaj oczywiście prawnicy różne zapisy wstawiają, natomiast polecam to sprawdzić, czy na wasz system umowa w ogóle jakiś, jeżeli to jest system starszy, to czy umowa istnieje? A też jeżeli już jakiś system budujecie, to czy tam na pewno to przekazanie praw autorskich się znalazło, bo jeśli nie to może warto to nadrobić szybciej niż później. I mam nadzieję, że te informacje, o których tutaj sobie poopowiadaliśmy pozwolą spojrzeć wam na umowy i kwestie własności kodu z taką większą świadomością, bo nawet jeśli dziś wszystko idzie zgodnie z planem, a współpraca z wykonawcą układa się świetnie, to warto być zabezpieczonym po prostu.1

Spokój, kontrola i skalowalność dzięki dobrej umowie

To nie jest kwestia braku zaufania, tylko to jest kwestia minimalizacji ryzyk biznesowych. W świecie technologii wiele rzeczy może się zmienić z dnia na dzień, a mając dobrze skonstruowaną umowę i jasne zapisy, zyskujesz spokój, kontrolę i możliwość działania niezależnie od tego, co się wydarzy.

Masz wątpliwości? Czas na rozmowę o Twoim projekcie

Jeśli chcesz skonsultować swoją sytuację, albo potrzebujesz wsparcia w przejęciu projektu, jak co tydzień zachęcam Cię do rozmowy o Twojej sytuacji.

Chętnie sprawdzę, czy i jak możemy pomóc w dalszym rozwijaniu Twojego projektu, czy też w ogóle całej firmy. Dzięki serdeczne za wysłuchanie dzisiejszego odcinka. Mam nadzieję, że temat prawa autorskich po ludzku i nieprawniczo, a jednocześnie konkretnie udało mi się Wam przedstawić.

Jeżeli mielibyście do tego jakiekolwiek pytania, serdecznie zapraszam do kontaktu. Dzięki raz jeszcze i do usłyszenia za tydzień we wtorek. Cześć.