Prawo autorskie w projektach programistycznych

Spotify

Apple Podcasts

RSS Feed

Youtube

Uczestnicy

Grzegorz Papaj

VP of Business ImpiCode

Opis odcinka

W dzisiejszym odcinku podcastu omówimy kwestię praw autorskich w projektach programistycznych z praktycznego punktu widzenia. Omówimy ogólny zamysł praw autorskich oraz najważniejsze zagadnienia, które muszą znaleźć się w umowie przekazania praw autorskich w kontekście projektów IT.

Omawiamy prawa autorskie majątkowe i osobiste, co wynika z faktu niezbywalności jednych z nich i jakie może mieć to konsekwencję w przyszłości. Kolejnym ważnym aspektem jest wyłączność do praw majątkowych.

Na końcu poruszamy kwestię przekazywania praw autorskich do projektu, w którym większość kodu to zewnętrzne biblioteki i frameworki, do których nie mamy praw majątkowych. Oraz jak rozwiązać kwestię udostępniania oprogramowania do testów dla klienta przed właściwym przekazaniem praw autorskich.

POZOSTAŁE ODCINKI

Transkrypcja

[ 00:00:28] Grzegorz Papaj: Cześć, nazywam się Grzegorz Papaj i jestem współzałożycielem firmy programistycznej ImpiCode. Jednym z moich głównych zajęć w firmie są rozmowy z leadami, czyli bardzo często jestem pierwszą osobą, z jaką potencjalny klient spotyka się z ImpiCode.

[ 00:00:42] Podczas takich spotkań często powracają te same pytania lub problemy, z którymi mierzą się przedstawiciele naszych klientów i potencjalnych klientów.

[ 00:00:51] Dziś chciałbym poruszyć temat aspektów prawnych w projektach IT, a w szczególności praw autorskich, które zdarza się, że bywają przyczyną bardzo poważnych problemów.

[ 00:01:04] Dodam tutaj, że nie jestem prawnikiem i mogę mieć niedokładny lub niepełny obraz pewnych zagadnień. Przedstawiam tutaj jedynie swoje osobiste doświadczenia, obserwacje i interpretacje, które mogą być jak to z laikami bywa, błędne. Zatem z pewnością nie należy podejmować ważnych decyzji bazując na tym, co tu powiem. Niemniej jednak wielokrotnie skonfrontowałem moje doświadczenia, obserwacje i opinie z prawnikami i raczej bym się nie spodziewał jakichś większych błędów czy uchybień z mojej strony.

[ 00:01:42] Przejdźmy zatem do rzeczy. Zaczniemy sobie od absolutnych podstaw. Zatem czym są prawa autorskie?

[ 00:01:51] Współcześnie sprawa wydaje się być dość oczywista, przynajmniej na jakimś podstawowym, intuicyjnym poziomie. Każdy o prawach autorskich słyszał i coś tam wie. Na przykład, że jest taki zbiór praw czy przepisów, które zabezpieczają twórców.

[ 00:02:07] No dobrze, ale kim jest twórca i przed czym te prawa go zabezpieczają? Twórca, czyli autor, to jest taki ktoś, kto stworzył jakieś dzieło. Proste.

[ 00:02:21] Tylko czym jest dzieło? Dzieło? Albo inaczej utwór. To jest takie specyficzne "coś". Specyfika tego czegoś jest taka, że owo coś nie ma formy materialnej, czyli może istnieć w oderwaniu od nośnika lub może być zapisane czy utrwalone na wielu różnych nośnikach.

[ 00:02:42] Na przykład melodia istnieje w oderwaniu od jej zapisu. Np. wiele melodii nigdy nie zostało zapisanych. Melodię można zapisać w postaci zapisu nutowego, albo po prostu ją nagrać. Przy czym jedna melodia może mieć wiele różnych, zupełnie innych wykonań, na różnych instrumentach przez różne osoby. Jedna melodia może brzmieć bardzo różnie, natomiast dalej może być rozpoznawalna.

[ 00:03:12] Dzieło nie ma takiej jasnej, klarownej, sztywnej definicji, co też bywa przyczyną problemów. Natomiast wydaje się, że jest to pojęcie w większości przypadków dość dobrze rozumiane. Problemy interpretacyjne w IT w obszarze oprogramowania z reguły nie są jakieś szczególnie istotne. Ale o tym co jest utworem, a co nie, sobie za chwileczkę powiemy.

[ 00:03:41] Jeszcze jedna ważna sprawa. Utwór musi być wytworem myśli ludzkiej. Nie może być efektem działania sił przyrody, albo wyłącznie sił przyrody, czynników losowych i tak dalej. Czyli musi być w to włożony jakaś intencja człowieka, jakiś zamysł, jakaś myśl. No to też jest trochę śliski temat tak naprawdę. Natomiast tak to określa w tym momencie prawo.

[ 00:04:12] Podsumowując tę część. Tak naprawdę definicja utworu nie jest do końca jasna i cały czas trwają dyskusje wokół tego, co jest utworem, a co nie. Ale nie będziemy tu wchodzić w takie dywagacje. Z perspektywy IT sprawa jest dość prosta. Nas interesują programy komputerowe, albo może raczej ich kod.

[ 00:04:33] Czyli twórca, autor to ktoś, kto tworzy dzieła i całe prawo autorskie w zamierzeniu powstało po to, aby chronić interesy twórców.

[ 00:04:43] Jeśli ktoś spędza długie godziny, dni czy lata na przykład na napisaniu symfonii, to zadaniem prawa autorskiego jest zapewnić, że ten autor będzie mógł między innymi czerpać zyski dzięki tej symfonii. Albo w innym ujęciu. Nikt bez zgody lub z pominięciem tego autora nie będzie mógł czerpać zysku z tego utworu.

[ 00:05:05] I tu pojawia się bardzo ważny podział, na prawa autorskie osobiste i na prawa autorskie majątkowe. I na tym polu też bywa trochę nieporozumień.

[ 00:05:17] Wyjaśnijmy zatem sobie te pojęcia. Prawa autorskie majątkowe oznaczają, kto może utworem rozporządzać. Domyślnie jest to autor. Rozporządzać, a czego robić nie wolno.

[ 00:05:33] Oczywiście do pewnego stopnia, bo tu pojawiają się kwestie dozwolonego użytku, cytatu i tak dalej. Ale to zostawmy. Wracając do głównego wątku.

[ 00:05:46] Posiadacz praw autorskich majątkowych do symfonii może udzielić komuś prawa do jej wykonania. I może tego prawa udzielić odpłatnie lub na innych zasadach, z grubsza według własnego uznania.

[ 00:05:58] Co jest tu bardzo istotne prawa autorskie majątkowe mogą być przenoszone na inne osoby. Czyli nasz kompozytor może komuś sprzedać prawa do swojej symfonii i po dokonaniu tej sprzedaży niewiele będzie miał do powiedzenia na temat tego, co inni z nią zrobią. A w każdym razie co zrobi z nią nowy właściciel. Chociaż tutaj też są wyjątki i o tym opowiemy sobie za chwilę.

[ 00:06:24] Poza prawami autorskimi majątkowymi są też prawa autorskie osobiste i w największym skrócie oznaczają one, że autor ma prawo być przypisany jako twórca do danego utworu, nawet jeśli ma prawa majątkowe do utworu zostaną przeniesione np. sprzedane to nie można przypisać autorstwa nowemu właścicielowi, ponieważ prawa autorskie osobiste są nie transferowalne czy też inaczej niezbywalne.

[ 00:06:53] Czyli jeśli jakąś symfonię napisał Mozart i opublikował ją pod swoim nazwiskiem, a nie anonimowo, bo taka opcja też jest, to będzie on jej autorem na zawsze. Nawet jeśli skomponował ją na zamówienie jakiegoś lokalnego magnata, który za nią zapłacił.

[ 00:07:10] Oczywiście tu też mamy pewne niuanse, jak właśnie anonimowa publikacja. Pojawiają się zobowiązania do niewykonywania praw osobistych i tak dalej, ale to osobna historia. W to tutaj nie będziemy wchodzić.

[ 00:07:26] I to pewnie jest dobry moment, żeby opowiedzieć o jednej ciekawostce, tak trochę z boku głównego tematu. Prawa osobiste w teorii niezmienionej formie i treści. Co samo w sobie jest dosyć zagmatwanym zagadnieniem w największych ogólnikach chodzi o to, że nie można zmieniać czy zniekształcać wymowy dzieła.

[ 00:07:58] I tu mamy świetny przykład ze znanymi nowojorskimi rzeźbami Charging Bull i Fearless Girl. Cała historia zaczyna się od roku 1989, kiedy na nowojorskim Wall Street stanęła rzeźba byka, szarżującego byka. Stąd właśnie nazwa Charging Bull. Rzeźba została stworzona przez włoskiego artystę Arturo Di Modica i stała się symbolem, jednym z symboli Wall Street. Nawiązania są dosyć oczywiste. Byk jest w świecie giełdowym symbolem hossy.

[ 00:08:39] Kontrowersje wokół rzeźby zaczęły się w momencie, kiedy z inicjatywy, jak rozumiem, ruchów Okupacja Wall Street. Naprzeciw szarżującego byka stanęła kolejna rzeźba. Rzeźba Fearless Girl, czyli nieustraszonej dziewczynki, w założeniu promującej wartości feministyczne, różnorodności i tak dalej. Dziewczynka z brązu została umieszczona na wprost szarżującego byka.

[ 00:09:13] No i w zasadzie dla wszystkich obserwatorów było jasne, że z odwagą wychodzi naprzeciw szarżującemu zwierzęciu. Ta sytuacja nie spodobała się autorowi oryginalnej rzeźby, czyli właśnie szarżującego byka - Arturo Di Modica oprotestował całą tę sytuację.

[ 00:09:37] Jednym z argumentów było właśnie to, o czym tu wspominałem, czyli prawo do niezmienionej formy i treści. Zdaniem autora umieszczenie szarżującego byka na naprzeciwko rzeźby dziewczynki całkowicie zmieniało wydźwięk jego oryginalnego dzieła, zmieniało jego oryginalne zamysły i w związku z tym domagał się usunięcia dziewczynki.

[ 00:10:06] Cała historia skończyła się w ten sposób, że usunięty czy przemieszczony w inne miejsce został byk. Cała ta sytuacja świetnie ilustruje to, że autor ma prawo domagać się respektowania oryginalnego zamysłu i wydźwięku dzieła, które stworzył.

[ 00:10:26] Nawet jeśli to dzieło sprzedał i nie jest już jego własnością, nadal to dzieło jest firmowane jego nazwiskiem i autor może się w jakiś tam sposób wypowiadać na temat tego, jak to dzieło jest przedstawiane, czy nie jest zmodyfikowane, zniekształcone. Czy w tym wypadku roszczenia autora są zasadne czy nie? No to to już pozostawiam indywidualnej ocenie.

[ 00:10:52] Wróćmy do bardziej praktycznej strony praw autorskich. Czym w praktyce są utwory?

[ 00:10:59] To oczywiście takie rzeczy jak wspomniana już muzyka, utwory literackie, plastyczne, w tym fotografie, utwory audiowizualne, czyli filmy, dzieła sztuk wizualnych różnego rodzaju i tak dalej.

[ 00:11:17] Z mniej oczywistych rzeczy mieszczą się w kategorii utworów takie byty jak kompozycje choreograficzne czy wzory przemysłowe. Z naszego podwórka IT oczywiście programy komputerowe, ale też co może być dla niektórych niespodzianką, projekty obwodów drukowanych.

[ 00:11:38] Ale uwaga! W wielu przypadkach programy wykorzystują również utwory plastyczne, np. ikony oraz muzykę. Łatwo też zapomnieć, że dokumentacja może być rozpatrywana jako utwór literacki, podobnie zresztą jak niektóre inne teksty czy też ich tłumaczenia, które też są czy mogą być interpretowane jako dzieła literackie.

[ 00:12:05] Dlatego chcąc zabezpieczyć prawa autorskie do programu komputerowego, warto pomyśleć również o tych wszystkich mniejszych i większych utworach, które powstają dookoła tej głównej części, czyli kodu źródłowego.

[ 00:12:18] Oczywiście w tym momencie zapewne mogliby się włączyć prawnicy i powiedzieć, że to jest dyskusyjne, że dokumentacja jest czymś innym niż kod. Że może wcale nie jest osobnym dziełem, bo bez kodu nie ma sensu i tak dalej. I być może będą mieli rację. Natomiast z praktycznego punktu widzenia raczej nie chcemy wchodzić w takie dyskusje.

[ 00:12:38] Raczej powinniśmy zadbać o przeniesienie praw autorskich z wyraźnym odniesieniem do dokumentacji, instrukcji i wszystkich innych dzieł, jakie powstają dookoła programu. Tak po prostu, dla świętego spokoju. Z reguły nie wiąże się to z żadnymi dodatkowymi obciążeniami, żadnymi dodatkowymi kosztami. Po prostu chcemy się upewnić, że jeśli kupujemy program, kupujemy prawa autorskie do programu, to kupujemy prawa autorskie do wszystkiego.

[ 00:13:07] Jedną z cech prawa autorskiego jest to, że tutaj nie ma domniemanego przekazania prawa autorskiego. Ale do tego jeszcze wrócimy.

[ 00:13:20] Wiemy już mniej więcej, czym od strony praktycznej są utwory, a zatem co jest objęte prawem autorskim. A co w takim razie prawem autorskim nie jest objęte?

[ 00:13:32] Oczywiście wszystko to, co nie zostało zakwalifikowane jako utwór, choć wiemy już, że definicje utworu są nieco rozmyte, ale od strony praktycznej te dyskusyjne przypadki nas raczej nie interesują. Interesuje nas natomiast coś innego, co bywa przedmiotem nieporozumień.

[ 00:13:51] Bardzo często pojawia się u nas jakiś startup, albo też czasem tak zwany człowiek z pomysłem, który mówi o prawach autorskich do pomysłu. Tu należy wyraźnie powiedzieć, że pomysły nie są objęte ochroną w rozumieniu praw autorskich.

[ 00:14:11] Pomysł jest tylko pomysłem. Natomiast prawo zapewnia ochronę prawnoautorską realizacją tych pomysłów. Czyli na przykład mogę mieć pomysł na namalowanie obrazu kobiety trzymającej na rękach gronostaja, ale koncepcja taka nie jest w żaden sposób chroniona, przynajmniej w myśl praw autorskich.

[ 00:14:32] Może sobie więc przyjść taki da Vinci i namalować Damę z gronostajem i to on będzie posiadał prawa autorskie do dzieła, a nie ja. Choć to ja ten pomysł zaproponowałem. Może się to wydawać niesprawiedliwe, ale takie mamy prawo. Zresztą czy to jest niesprawiedliwe? To jest temat na zupełnie osobną dyskusję.

[ 00:14:52] No i oczywiście mówię o tym z przymrużeniem oka. Jak już wspomniałem, temat ochrony praw autorskich do pomysłu od czasu do czasu wraca w rozmowach z klientami i myślę, że warto zaznaczyć, jeśli pomysł ma być chroniony, to na pewno nie na polu praw autorskich. Tutaj pewnie by należało powiedzieć trochę o umowach zachowania poufności NDA, ale to zostawimy sobie na inny odcinek.

[ 00:15:19] Ok, myślę więc, że wprowadzenie chyba już mamy za sobą. Omówiliśmy zgrubnie czym są prawa autorskie, jakie są, czym są utwory, co utworem nie jest.

[ 00:15:32] Teraz skupimy się chyba na najważniejszej kwestii związanej z prawami autorskimi, przynajmniej w ujęciu biznesu i IT. A mianowicie na ich przekazywaniu. Czyli w praktyce na sprzedawaniu praw autorskich.

[ 00:15:46] Przypomnę, że przekazać można tylko prawa autorskie majątkowe, osobiste są nie transferowane. Dlatego w dalszej części, kiedy będę mówić o prawach autorskich, będę miał na myśli prawa autorskie majątkowe. Tylko i wyłącznie.

[ 00:16:03] Co jest ważne w przekazaniu praw autorskich? Określenie co przekazujemy. To się wiąże z tym, co wspomniałem przed chwilką. W przypadku praw autorskich nie ma domniemanego przekazania praw. Czyli musimy określić, do jakiego utworu prawa autorskie przekazujemy.

[ 00:16:26] Ten utwór w różny sposób można zdefiniować. Czasem to jest proste, czasem to jest trudne w przypadku programów komputerowych z reguły się tego nie definiuje jakoś strasznie ściśle, bo po prostu się nie da. Zwłaszcza jeśli ten program jeszcze nie powstał.

[ 00:16:47] Możemy oczywiście przekazać prawa autorskie do utworu, który dopiero powstanie. Jeśli program jeszcze nie powstał, no to oczywiście możemy sobie opisywać, jak on będzie działał i tak dalej. atomiast to samo w sobie nie jest dostatecznym opisem programu. Ale tam w praktyce w większości przypadków się nie przejmujemy w momencie, kiedy program powstanie wtedy bezdyskusyjnie mając umowę przekazania praw autorskich czy sprzedaży praw autorskich, będziemy mogli się do tej umowy odnieść i powiedzieć:

[ 00:17:23] OK, tu mamy program napisany przez Jana Kowalskiego, tu mamy umowę przekazania praw autorskich do tego programu napisanego przez Jana Kowalskiego i sprawa jest czysta.

[ 00:17:32] Oczywiście można tam nakreślać w taki czy inny sposób, jaki jest zakres funkcjonalny tego programu, co on ma robić, jak ma wyglądać i tak dalej. Natomiast jest to o tyle nieprecyzyjne, że Jan Kowalski może napisać wiele różnych programów dla wielu różnych klientów, robiących z grubsza te same rzeczy. Tak więc taki opis sam w sobie nie oznacza, że dostajemy prawa autorskie do wszystkiego. Wszystkich programów pasujących do opisu, które Jan Kowalski w swojej historii napisał w umowach przekazania praw autorskich.

[ 00:18:07] Bardzo często pojawia się taki taki, zwłaszcza szablonach dostarczanych przez prawników, takie coś, co moim zdaniem jest już takim mocnym archaizmem. Czyli taka informacja, że wraz z przekazaniem praw autorskich czy wraz z przekazaniem kodu programu przekazujemy klientowi również nośnik, na którym ten kod jest przekazany, czyli np. dyskietkę, płytę CD i tak dalej.

[ 00:18:37] No oczywiście wiemy wszyscy, że takie nośniki od lat już nie są stosowane. Niemniej jednak takie zapisy wynikają z tego, że gdzieś tam kiedyś w historii. Tworzenia prawa autorskiego zostało powiedziane, że przekazywanie praw autorskich nie oznacza automatycznego przekazania nośnika. Ponownie ten temat, że nie ma domniemanego przekazania praw. Chociaż na trochę na innej płaszczyźnie, ale nadal mniej więcej chodzi o tą samą zasadę.

[ 00:19:09] Dlatego też niektórzy dodają tam te nieszczęsne dyskietki czy inne nośniki, choć w praktyce w tej chwili pojęcie nośnika przestaje funkcjonować. Programy są umieszczane gdzieś tam w serwerach chmurowych. No wiadomo, że przekazując taki program nie przekazujemy prawa do serwera, na którym ten kod gdzieś tam jest zdeponowany.

[ 00:19:32] No ale to tylko tak zaznaczam jako ciekawostkę. Myślę, że jakby gdzieś tam jakiś jakiś temat miał się o to gdzieś rozbijać, no to sąd by rozstrzygał, co to w zasadzie taki zapis oznacza. Natomiast od strony praktycznej nie ma to kompletnie żadnego znaczenia.

[ 00:19:50] Też bywa trochę problematyczne i powoduje, że te zapisy o prawach autorskich w umowach o przekazaniu praw autorskich są strasznie rozbudowane, mianowicie chodzi o pola eksploatacji, pola eksploatacji, czyli tak najogólniej mówiąc.

[ 00:20:09] Czym jest pole eksploatacji? Jest tym, co można robić z programem, tak? Czyli to może być jego wprowadzanie do obrotu i rozpowszechnianie bezpłatne lub odpłatne, czyli sprzedawanie, wykonywanie dzieła albo jego pokazywanie, emitowanie, utrwalanie i kopiowanie.

[ 00:20:35] Cała masa tego typu rzeczy się pojawia w tych nieszczęsnych paragrafach dotyczących przekazania praw autorskich. Wynika to z tego, że nie można w umowie napisać, że przekazujemy prawa autorskie do wszystkich pól eksploatacji i zawsze jest ryzyko, że pojawi się jakieś nowe, nieznane dotąd pole eksploatacji i tam nabywca praw autorskich nie będzie mógł z niego korzystać.

[ 00:21:04] Na przykład przed upowszechnieniem się internetu zapewne w wielu umowach pojawiało się, że dystrybucja w internecie czy sprzedaż w internecie jest takim polem eksploatacji. No i być może to powodowało gdzieś tam potem jakieś roszczenia autorów. Czasem w umowach stosuje się zapisy które mówią, że jeśli pojawi się jakieś nowe, nieznane pole eksploatacji, to sprzedający czy też autor zobowiązuje się bezpłatnie udostępnić upoważnić do kolejnego tego nowego pola eksploatacji.

[ 00:21:47] Ja myślę, że tutaj nie ma najczęściej wątpliwości w momencie, kiedy mówimy o oprogramowaniu, no bo inne dzieła mogą się rządzić zupełnymi, zupełnie innymi prawami. Natomiast w momencie, kiedy mówimy o oprogramowaniu najczęściej i jeśli oczywiście w ogóle mówimy o przekazaniu praw autorskich, w takiej sytuacji najczęściej intencją jest oddanie nabywcy praw i niech on sobie z tym robi, co chce, w taki sposób, jak chce.

[ 00:22:13] No ale prawo jest prawem. W związku z tym te akapity o kolejnych polach eksploatacji, czasem bardzo fantazyjnych, czasem archaicznych, pojawiają się w umowach.

[ 00:22:26] Prawa zależne. W uproszczeniu mówiąc prawo do zmiany danego utworu. Do zmiany modyfikacji, rozszerzenia, rozbudowy. Jest to w ujęciu praw autorskich bardzo ważne i powinno się znaleźć w dobrze sporządzonej umowie, ponieważ domyślnie jeżeli nabywamy prawa autorskie do jakiegoś utworu, to nie nabywamy automatycznie praw do jego zmiany.

[ 00:22:55] No i powiedzmy jeśli kupujemy sobie obraz, no to pewnie to prawo do zmiany nam nie będzie jakoś mocno potrzebne. Zwłaszcza jeśli chcemy ten obraz powiesić sobie na ścianie.

[ 00:23:09] Natomiast gdybyśmy chcieli kupić taki obraz, np. Mona Lisa, domalować jej wąsy i sprzedać za wyższą cenę, no to pewnie musielibyśmy się upewnić, że mamy prawa autorskie do zmiany tego dzieła. Oczywiście, Mona Lisa jest nieobjęta prawami autorskimi w tej chwili. Ale to zupełnie inna historia.

[ 00:23:33] W każdym razie w przypadku oprogramowania prawo do zmiany jest prawem krytycznym, ponieważ programy po pierwsze mogą nie działać idealnie, czyli mogą wymagać poprawek, modyfikacji i usprawnień, mogą wymagać aktualizacji w odpowiedzi na chociażby zmiany technologiczne, wymagania biznesowe w odpowiedzi na chociażby kwestie związane z bezpieczeństwem.

[ 00:24:08] Więc prawo do modyfikacji oprogramowania, czyli wytworzenia dzieła zależnego - utworu zależnego. Bo zmodyfikowane oprogramowanie jest tak naprawdę dziełem zależnym od tego oryginalnego.

[ 00:24:24] To jest krytyczne dla normalnego funkcjonowania oprogramowania. Tak więc w momencie, kiedy kupujemy prawa autorskie do oprogramowania, musimy się upewnić, że coś takiego mamy.

[ 00:24:33] Ważnym elementem jest określenie w umowie przekazania praw autorskich, że opłata, która musi być określona chyba że jest przekazanie bezpłatne

[ 00:24:52] wiąże się z wszystkimi wymienionymi w umowie polami eksploatacji, ponieważ tutaj znów nie ma tej takiej domniemanego przekazania praw.

[ 00:25:04] Dlatego jeśliby się pojawiło jakieś niewymienione pole eksploatacji, to sąd mógłby zinterpretować taką sytuację na niekorzyść kupującego, czyli powiedzieć, że kupujący nie zapłacił za jakieś konkretne pole eksploatacji i w związku z tym należy się jakaś dodatkowa opłata.

[ 00:25:30] W umowie też powinniśmy określić, na jak długo przekazujemy prawa autorskie. To jest raczej nie praktykowane, żeby to było ograniczone czasowo. Natomiast warto zaznaczyć, że taka możliwość jest. I upewnij się, że w umowie nie jest wskazane. No chyba, że jest to jakiś tam obszar negocjacji i obu stronom to pasuje. Natomiast w praktyce najczęściej te prawa autorskie są przekazywane nabywcy bezterminowo.

[ 00:26:00] Pojawia się kolejny temat, który bywa kontrowersyjny i bywa czasem taką trochę pułapką na nieostrożnych nabywców, a mianowicie prawa mogą być wyłączne lub nie wyłączne. Czyli jeśli nabywam wyłączne prawa do jakiegoś dzieła. No to wtedy ja jestem jego jedynym dysponentem i nikt inny nie może mieć tego samego programu, tego samego kodu i nim zarządzać tak jak ja to robię.

[ 00:26:32] Natomiast to samo prawo może być niewyłączne. Czyli może być sytuacja, że jeden sprzedawca sprzeda dokładnie ten sam kod i prawa do tego samego kodu różnym klientom i każdy z nich będzie mógł niezależnie tym kodem dysponować w takim zakresie, jaki jest określony w umowie.

[ 00:26:55] I tu warto zwrócić na to uwagę. Nie mówię, że takie niewyłączne przekazanie jest problematyczne. Czasem po prostu może być obojętne dla nabywcy. Natomiast no czasem też można się zdziwić, można się zdziwić.

[ 00:27:12] Mieliśmy do czynienia z takimi sytuacjami, kiedy ktoś był przekonany, że kupił od dostawcy jakieś rozwiązanie, jakieś oprogramowanie i to jest jego wyłączna własność, a po jakimś czasie konkurował, jak się okazało z oryginalnym dostawcą tego oprogramowania, z twórcą tego oprogramowania. Ponieważ prawa, które nabył były niewyłączne, czyli sprzedający mógł sobie nimi dysponować tymi prawami nadal według własnego uznania.

[ 00:27:47] Oczywiście są rzadkie przypadki, skrajne. W niektórych przypadkach to pasuje obu stronom. To może dotyczyć. To może tyczyć się np. jakiś bibliotek wykorzystywanych hurtowo przez dostawców w różnych sytuacjach u różnych klientów. Nie chcemy wtedy sprzedawać tego wyłącznego prawa. Nie chcemy za każdym razem pisać dla każdego klienta osobno tej biblioteki, więc to jest jakieś rozwiązanie, które samo w sobie nie jest złe.

[ 00:28:14] Natomiast należy mieć na uwadze podpisując taką umowę. Czy to jest to, o co nam w danym momencie chodzi.

[ 00:28:23] W umowie ważne jest i nie można tego pominąć kiedy następuje to przekazanie i ten moment musi być w jakiś tam sposób określony. To może być oczywiście proste na zasadzie w chwili podpisania umowy. To jest trochę trudniejsze w sytuacji, kiedy na przykład jeszcze nie mamy utworu, do którego prawa kupujemy, czyli w naszej sytuacji kodu, który dopiero zostanie napisany.

[ 00:28:50] W takiej sytuacji najczęstszą, najczęstszą praktyką jest określenie, że te prawa przechodzą na klienta w momencie, kiedy uiści płatność. No i to jest rozwiązanie, które zwykle satysfakcjonuje wszystkich.

[ 00:29:06] Natomiast to jest jeszcze tak, że jeśli na przykład napisaliśmy jakiś system, jakiś duży system serwerowy dla dużej instytucji państwowej, podlegającej różnego rodzaju kontrolą, audytom i tak dalej. No to chcemy w którymś momencie wdrożyć to u nich testowo. Może być tak, że z umowy wynika, że oni nam jeszcze nie zapłacą, w związku z tym nie mają praw.

[ 00:29:39] I wtedy mamy klienta, który w jakiś tam sposób użytkuje program, mimo że do niego nie ma praw autorskich. I co to oznacza? No w zasadzie w praktyce nic to nie oznacza. Bo mamy mamy w tej sytuacji do czynienia nie tyle z przekazaniem praw autorskich, co z udzieleniem licencji.

[ 00:30:01] I w przeciwieństwie do praw autorskich licencji można udzielić domyślnie. Na przykład, jeśli ja sobie wchodzę na jakąś stronę Internetową, która coś tam robi, kalkulator walut to jest oprogramowanie, do którego ja nie mam jakiś tam licencji, nie mam dokumentu licencyjnego. Natomiast mam domyślne przekazanie licencji w momencie, kiedy ja z tego korzystam. Bo taka jest intencja autora, że każdy, kto wejdzie na stronę, może taką licencję uzyskać.

[ 00:30:32] W przypadku tej sytuacji, o której tutaj w wyimaginowanej sytuacji z urzędem. Jest też ta licencja domyślna. Bo naszą intencją jest oddanie testowej wersji oprogramowania do testu. Licencji, czyli prawa do użytkowania. Nie oznacza to przekazania praw autorskich. Nie oznacza to możliwości dysponowania kodem. Natomiast jest licencja, która pozwala na testowanie tego kodu.

[ 00:30:58] Ale oczywiście zdarza się, że urzędnicy chcą być zabezpieczeni przed tym, że właśnie wpadnie jakiś audyt i powie macie tu oprogramowanie, nie macie do niego żadnych praw. I w takiej sytuacji pojawiają się w umowach zapisy takie, że w momencie, kiedy klient będzie sobie testował oprogramowanie, do którego nie ma przekazanych praw autorskich, to to oprogramowanie jest objęte licencją, której udziela wykonawca w momencie, na przykład instalacji tego oprogramowania.

[ 00:31:31] Tego typu obejścia tej sytuacji się zdarzają, zwłaszcza właśnie w sytuacjach współpracy z instytucjami państwowymi albo w jakiś tam sposób zależnymi od Skarbu Państwa, ponieważ one są w ten sposób często weryfikowane. W przypadku podmiotów prywatnych z reguły nikt się takimi rzeczami nie przejmuje i ta domniemana licencja wystarcza. Natomiast no, warto wiedzieć, że tego typu problem może zaistnieć i nie jest on taki całkiem bezpodstawny, natomiast dotyczy z reguły tej sfery urzędniczej.

[ 00:32:10 ] Warto się upewnić, że ten, kto przekazuje prawa autorskie, te prawa ma. Tak naprawdę to upewnić się nie możemy, ale warto, żeby w umowie znalazł zapis, że ten sprzedający oświadcza, że te prawa ma.

[ 00:32:30 ] Jeśli dostawcą jest jakaś firma, firma zatrudnia programistów. Ci programiści pracują bez umowy przekazania praw autorskich. Firma sprzedaje to oprogramowanie do swojego klienta, a za jakiś czas programiści się zbierają do kupy i pozywają klienta i mówią: "Korzystacie z oprogramowania, za które zapłaciliście, ale nie nam, więc nie macie żadnych praw."

[ 00:32:53] Bo nie było skutecznego przekazania praw autorskich na nabywcę, czyli w tym wypadku firmę wykonawczą. W związku z tym nie było skutecznego przeniesienia praw autorskich na klienta. No i taka sytuacja może zaistnieć.

[ 00:33:08] Nie możemy sprawdzać każdej jednej umowy, z każdym jednym podwykonawcą, pracownikiem. Czy ona obejmuje przekazanie praw autorskich. No to z praktycznego punktu widzenia nie ma sensu. Nie ma racji bytu. Pracownicy się zmieniają. Przy dużych projektach w ogóle nie ma, nie ma na to nadziei.

[ 00:33:29] Natomiast no pewno to takie minimum higieny, które możemy, o które możemy zadbać, to właśnie to oświadczenie, oświadczenie od dostawcy, że on te prawa ma, te, które będzie odsprzedawał.

[ 00:33:44] No i teraz po co takie oświadczenie? Po pierwsze to może zwrócić uwagę takiemu wykonawcy, że no faktycznie warto się o to zatroszczyć. Po drugie, jeśli taki wykonawca dokona takiej, w tym wypadku nieudanej sprzedaży praw autorskich, do których tak naprawdę nie posiada, to będzie działał w sposób oczywisty, w złej wierze.

[ 00:34:10] Nie wiem na ile nam to pomoże tak naprawdę. Jeśli będziemy mieli oprogramowanie, do którego nie mamy praw i sytuacja tego typu byłaby mocno skomplikowana, natomiast da nam to jakiś argument. Da nam to jakąś informację, da nam, przynajmniej na takim etycznym ściśle poziomie powie okej, ten tutaj to my jesteśmy oszukani. Tak, też jesteśmy oszukani, Nie jesteśmy częścią tego oszustwa.

[ 00:34:42 ] I to w zasadzie chyba chyba tyle. Na koniec bardzo istotna i czasem nie do końca też dobrze rozumiana.

[ 00:34:54] Przekazanie praw autorskich musi mieć formę pisemną. W przypadku praw autorskich nie ma ponownie domniemanego przekazania praw autorskich, musi być zachowana forma pisemna. Musi być określone to wszystko, o czym mówiliśmy w tej umowie. Nie może to być w żadnym wypadku umowa ustna. Jeżeli coś pominęliśmy, to w umowie zakupu, to nie mamy do tego prawa.

[ 00:35:22] Forma pisemna oznacza, że musimy mieć papier z podpisem. Lub ekwiwalent jakim jest dokument podpisany elektronicznie podpisem kwalifikowanym. Też warto od razu powiedzieć, że w przypadku przeniesienia praw autorskich takie praktykowane czasem wysyłanie skanów podpisanych dokumentów, które w sumie nie jest złe, samo w sobie jest nieskuteczne, jest nieskuteczne, ponieważ taki podpisany dokument, taki skan podpisanego dokumentu wymiany między firmami bez formy papierowej, nie jest dokument w formie pisemnej. Można to uznać za pewnego rodzaju potwierdzenie umowy ustnej. Natomiast tej formy pisemnej brak. W związku z tym przeniesienie praw autorskich w ten sposób uregulowane nie ma żadnych podstaw prawnych, jest nieskuteczne. Więc albo dokument papierowy, albo podpis kwalifikowany.

[ 00:36:26] Podsumowując część o umowach przekazania praw autorskich. Po pierwsze forma pisemna, po drugie określenie co przekazujemy, bo nie ma tutaj domyślnego przekazania. Warto wymienić te pola eksploatacji możliwie dużo. Można dodawać zapisy związane z jakimiś nowymi polami eksploatacji. Określenie kwoty przekazania. Określenie czasu. Najlepiej w naszym przypadku, żeby to było bezterminowe przekazanie praw. Jasne ustosunkowanie się do praw zależnych, czy dostajemy, czy nie. Jeśli nie jest powiedziane, że dostajemy, to znaczy, że nie dostajemy. Podobnie z kwestią wyłączności. Jeśli nie mamy powiedzianego jasno, że mamy wyłączne prawo, to zakładamy, że mamy niewyłączone. No i oczywiście ten moment przekazania. I to są te najważniejsze kwestie związane z samą umową.

[ 00:37:25] Teraz przejdźmy sobie do kolejnych aspektów. W praktyce oprogramowania, kiedy się tworzy coś dla klienta? Firma programistyczna oczywiście pisze masę kodu, tworzy też dokumenty pomocnicze, różnego rodzaju analizy, pliki z dokumentacją, pliki readme, jakieś skrypty różnego rodzaju i tak dalej, i tak dalej. Ale poza tym i do tego wszystkiego powinno być przekazane prawo autorskie.

[ 00:37:59] Natomiast poza tym taka firma korzysta też z różnego rodzaju narzędzi, bibliotek i frameworków, do których nie ma praw, w sensie nie ma praw własności. Z reguły ma jakieś licencje. Może mieć prawo do kodu, może mieć prawo do zmiany tego kodu. To wszystko zależy od licencjonowania. Nie będziemy tu wchodzić w szczegóły różnego rodzaju modeli licencyjnych.

[ 00:38:30] Natomiast warto zwrócić uwagę na to, że jeśli kupujemy od kogoś jakiś system, dajmy na to zrobiony w Pythonie, na frameworku Django, no to możemy się spodziewać, że naszą własnością jest tylko ten kawałek tego całego systemu, który został napisany dla nas.

[ 00:38:47] Natomiast nie uzyskujemy żadnych praw własności do samego frameworku Django i do wielu innych bibliotek Pythona, które zostały zapewne w projekcie wykorzystane. Dostajemy licencję na korzystanie z niego. e licencje mogą być różne, ograniczone, nieograniczone w taki czy inny sposób.

[ 00:39:05] Natomiast jeśli współcześnie, jeśli się kupuje program, to tak naprawdę kupuje się taką hybrydę, trochę kodu ma się na własność, trochę kodu ma się licencjonowanego. No i te licencje bywają bardzo różne. W większości przypadków twórcy dbają o to, żeby te licencje były, że tak powiem, przyjazne biznesowo.

[ 00:39:28] Natomiast warto też powiedzieć, że jest grupa licencji, która jest biznesowo nieprzyjazna. Jeśli korzystamy z jakichś bibliotek, to automatycznie zgadzamy się na to, że to, co wytworzyliśmy, musi być publicznie i bezpłatnie dostępne dla innych. To są przede wszystkim biblioteki z grupy GNU, licencje z grupy GNU, które właśnie w ten sposób działają.

[ 00:39:57] One w tej chwili nie są już tak bardzo popularne jak kiedyś. Natomiast być może warto gdzieś tam zwrócić uwagę na ten aspekt. One miały, były nazywane wirusowymi właśnie z tego powodu, że w momencie, kiedy ktoś skorzystał z jakiejś biblioteki, z jakiegoś kodu, no to po prostu był prawnie, licencyjne zobowiązany do udostępnić całego swojego program dokładnie na tej samej licencji.

[ 00:40:25] Oczywiście to są zamierzchłe czasy. Aktualnie stosuje się różnego rodzaju inne inne licencje typu MIT i tak dalej. Które są znacznie bardziej przyjazne z biznesowego punktu widzenia.

[ 00:40:37] Na co warto jeszcze zwrócić uwagę? Przychodzą do nas klienci, którzy mają jakiś program i chcą, żebyśmy z nim pracowali, żebyśmy go jakoś zmodyfikowali, rozszerzyli i tak dalej. No i cóż, my zwykle pytamy o to, czy mają kod źródłowy i prawa do tego kodu.

[ 00:40:57] Pytamy o te dwie rzeczy, ponieważ to nie idzie w parze. Można mieć kod źródłowy i nie mieć praw. To już po części zaznaczyłem. Czyli możemy mieć kod źródłowy, ale nie mieliśmy skutecznego przeniesienia praw autorskich, bo na przykład nie zachowaliśmy formy pisemnej, bo mieliśmy umowę na gębę z kimś, kto nam coś tworzył przez lata i dostawał co prawda za to pieniądze, ale nigdzie nie było powiedziane, że on nam przekazuje prawa autorskie. W takiej sytuacji nie mamy tych praw autorskich.

[ 00:41:23] Próba takiego nabycia praw autorskich może skutkować tym, że nagle twórca zwęszy tu interes życia i powie OK, ale to będzie was słono kosztować. I to są sytuacje z życia wzięte.

[ 00:41:35] Więc warto się upewnić, że toprzekazanie praw autorskich faktycznie ma miejsce. Czyli możemy mieć kod źródłowy bez praw. Zdarza się też odwrotnie i też nie tak rzadko, że nie możemy mieć prawa do kodu źródłowego, a nie samego kodu. No to oczywiście ma zastosowanie w językach kompilowalnych typu Java, C#i tak dalej. Z reguły ten kod powinniśmy dostać, natomiast zdarza się w różnych sytuacjach, że ten kod jest nieosiągalny, że jego twórca gdzieś tam go miał, ale mu się skasowało, a przez lata były używane kompilatory, więc źródła gdzieś tam zaniknęły i nie były nikomu potrzebne aż do teraz.

[ 00:42:23] Bo teraz trzeba coś zmienić czy naprawić. Tak i z takimi sytuacjami też mieliśmy do czynienia. Jeżeli mamy prawa autorskie do takiego kodu, no to wtedy nawet jeśli nie mamy samego kodu, no to wtedy bezdyskusyjnie możemy przeprowadzić dekompilację takiego kodu. Czy możemy próbować?

[ 00:42:43] Bo nie zawsze jest to takie proste. Tak, dekompilację, czyli odtworzenie na podstawie pliku binarnego kodu źródłowego aplikacji, który gdzieś tam potem możemy modyfikować po to, żeby naprawić błąd. No i takie sytuacje też nam się zdarzały w historii ImpiCodu.

[ 00:43:01] No to są ciekawe przypadki, fajnie się o tym opowiada, natomiast no to jest koszt zawsze dla klienta. Także należy się upewnić, że poza przekazaniem praw faktycznie dostajemy też ten kod źródłowy, bo dostawca, który nam go udostępnia, no to teraz jest i może to zrobić, a za 5 lat może się okazać, że nie istnieje i tego kodu nie ma.

[ 00:43:27] Myślę, że chyba opowiedziałem najważniejsze kwestie związane z prawami autorskimi, czyli opowiedzieliśmy sobie pokrótce co to właściwie jest to dzieło, jakie są takie fundamenty czy podstawy funkcjonowania praw autorskich, po co one są i jak działają. W szczególności w prawach autorskich praktycznie nic nie działa domyślnie i jak coś ma zadziałać, to musi być powiedziane, że działa.

[ 00:43:55] Omówiliśmy sobie najważniejsze elementy budowy skutecznej umowy przekazania praw autorskich plus kilka jakichś po drodze przypadków czy ciekawostek. Mam nadzieję, że cała ta historia będzie dla Was i pouczająca i że była ciekawa.

[ 00:44:17] Jeśli tego typu tematy Was interesują, dajcie znać, zasubskrybujcie, lajkujcie, zostawcie komentarz, gdziekolwiek tego słuchacie. Będziemy bardzo wdzięczni. Będzie to dla nas jasna informacja, że warto dalej tworzyć tego typu treści.

[ 00:44:37] To ja już się z Wami żegnam. Wielkie dzięki! Do usłyszenia!

Rozwiń całość