Powyższy tytuł to oryginalny tytuł jednego z cytowanych poniżej artykułów. Wybrałem go, bo obrazuje pewien problem na rynku IT (ale nie tylko na tym rynku). Ten problem to właśnie tak zwane “życzeniowe myślenie”. Dotyczy ono zarówno oczekiwań jak i zobowiązań, tak dostawców jak i nabywców oprogramowania. Celowo nie piszę usługodawców IT, bo znakomita większość tak zwanych “projektów IT” ma za cel tylko to, by nabywca zyskał oprogramowanie, którego użyje jako narzędzia w prowadzonej przez siebie działalności. To czy kupi gotowe i wdroży, czy zleci jego stworzenie dla siebie, czy też wydzierżawi, ma znaczenie drugorzędne, różnica jest tylko w ryzyku takiego projektu.

teza, że deweloper to grupa ekspertów, ludzi dobrej woli, którym wszystko się udaje bo obiecali, to niestety myślenie życzeniowe…

Wprowadzenie

Wszelkie projekty w obszarze inżynierii są związane z projektowaniem. Powstają projekty rozwiązań, potem zaś owe rozwiązania. Interdysplinarność inżynierii (mało co dzisiaj składa sie tylko z jednego materiału i wykonane jest z użyciem jednej tylko technologii) powoduje, że mówimy raczej o systemach (system, mechatronika) niż o urządzeniach czy przedmiotach jak kiedyś. Jednak inżynieria oprogramowania wyróżnia się w pewnym aspekcie na tle innych: jej produkty są niematerialne. W konsekwencji są one dla większości ludzi, z poza tej branży, niemierzalne i niezrozumiałe, a ich wytwarzanie jest relatywnie łatwe, bo nie wymaga żadnych materialnych (mierzalnych dla innych ludzi) surowców. Zaryzykuje tezę, że komputer i oprogramowanie dla wielu ludzi to wręcz magia. Konsekwencją tego jest to, że wiele umów zawieranych jest na dostarczenie czegoś, czego nikt nie rozumie, a już kupujący na pewno ;), z czego skrzętnie nie raz korzystają dostawcy oprogramowania. Doskonale ilustruje to znane w branży IT powiedzenie:

?Klient ma rację do momentu podpisania umowy wdrożeniowej. Po jej podpisaniu ? racja jest wyłącznie po stronie dostawcy?

(tu polecam poprzedni artykuł: Zamawiający jest zawsze winny swojej porażki.

Dlaczego to robisz? Bo mogę.

Tak w skrócie można opisać i zamknąć temat dostawców oprogramowania i problemów z tym związanych. Prawdę mówiąc ja nie spotkałem się nigdy z sytuacją, by sądowy spór o jakość dostarczonego oprogramowania przegrał (i zwrócił pieniadze) dostawca realizujący projekt T&M (czyli agile).

Pamiętacie bajkę o żabie i skorpionie? Za chwilę się okaże jaki ma związek z IT. Nad brzegiem rzeki spotkała się żaba i skorpion. Oboje chcieli przedostać się na drugą stronę. Żaba obyta ze środowiskiem wodnym nie miała żadnych obaw. Gorzej ze skorpionem, nie potrafił przemieszczać się w wodzie. Postanowił przekonać żabę, aby mu pomogła i przepłynęła z nim na grzebiecie. Żaba w pierwszym odruchu odmówiła. Obawiała się, że skorpion ją ukąsi swoim śmiercionośnym żądłem w czasie tej przeprawy. ((1) ZASKAKUJĄCE ODKRYCIE: WISHFUL THINKING RZĄDZI W IT | LinkedIn)

Popatrzmy na to co opisuje autorka tekstu. Cały artykuł jasno pokazuje, że (IT) “robią co chcą i to bezkarnie”. Dlaczego? Moim zdaniem z prostego powodu: bo mogą. Dlaczego mogą? Bo im klient pozwala!

Negocjacje to ciekawy etap projektów IT: dwie strony dyskutują o czymś o czym tak na prawdę nie mają pojęcia, bo kupujący nie rozumie czym jest proces tworzenia oprogramowania a dostawca oprogramowania, w dniu podpisania umowy, nie wie co ma robić oprogramowanie. Dlaczego? No bo nie istnieje opis przedmiotu zamówienia. Umowy w rodzaju “będziemy się bardzo starali i bierzemy XXX zł za godzinę programisty” nie zawierają ani celu a nie opisu tego co powstanie. Tezy jakoby celem programistów był sukces ich klienta mozna włożyć między bajki, co wykazała autorka cytowanego tekstu.

Dostawca ma dobre referencje i jest długo na rynku, więc to się musi udać. Nic bardziej mylnego. Jeden z wielu faktów obalających tę tezę opisałem w tekście Porażka za 2 mld zł. Lidl wycofuje się z wdrożenia SAP. Więcej argumentów w raporcie Chaos Report .

Płacę wiec dostanę to czego chcę. Owszem, ale pytanie brzmi czy to będzie “to czego potrzebujesz”? To także dokładnie opisałem w niedawnym tekście o winie zamawiającego.

To moje oprogramowanie i mogę z nim zrobić co chcę. W przypadku tak zwanych wartości niematerialnych, przeświadczenie że coś “jest moje” może być bardzo trudne do wykazania, a nie raz jest po prostu ułudą. Więcej w dalszej części.

Autorka bardzo dobrze opisała fakty, z jakimi się spotyka. Tu oboje mamy praktycznie identyczne doświadczenie (a jak to mówią: gdy dwóch mówi to samo to już nie jest to samo). Pozostaje jednak kwestia praw autorskich i tego co tak na prawdę jest tu przedmiotem prawa autorskiego i co faktycznie jest dziełem w tych umowach.

A kto tu coś w ogóle tworzy?

Tego typu teksty prawie zawsze zaczynam od ustawowej definicji pojęcia utwór :

Przedmiot prawa autorskiego

Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności
twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci,
niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór).
2. W szczególności przedmiotem prawa autorskiego są utwory:
1) wyrażone słowem, symbolami matematycznymi, znakami graficznymi
(literackie, publicystyczne, naukowe, kartograficzne oraz programy
komputerowe);
2) plastyczne;
3) fotograficzne;
4) lutnicze;
5) wzornictwa przemysłowego;
6) architektoniczne, architektoniczno-urbanistyczne i urbanistyczne;

Kluczem jest sformułowanie “każdy przejaw działalności
twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia” a może być np. “wyrażone słowem, symbolami matematycznymi, znakami graficznymi”. Generalnie jakakolwiek przydatność do czegokolwiek nie ma tu żadnego znaczenia. Ma znaczenie unikalność i fakt utrwalenia (ustalenie). Kolejna rzecz: konsekwencją jest jednak to, że praca “pod dyktando” nie jest działalnością twórczą, gdyż ta z zasady nie jest pracą samodzielną. Jeżeli dopuszczamy tu (albo jest to celem) pewną samodzielność, to powstaje tak zwane utwór zależny (ta sama ustawa):

Art. 2. 1. Opracowanie cudzego utworu, w szczególności tłumaczenie,
przeróbka, adaptacja, jest przedmiotem prawa autorskiego bez uszczerbku dla prawa do utworu pierwotnego.
2. Rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego (prawo zależne), chyba że autorskie prawa majątkowe do utworu pierwotnego wygasły. W przypadku baz danych spełniających cechy utworu zezwolenie twórcy jest konieczne także na sporządzenie opracowania.
3. Twórca utworu pierwotnego może cofnąć zezwolenie, jeżeli w ciągu pięciu lat od jego udzielenia opracowanie nie zostało rozpowszechnione. Wypłacone twórcy wynagrodzenie nie podlega zwrotowi.
4. Za opracowanie nie uważa się utworu, który powstał w wyniku inspiracji cudzym utworem.
5. Na egzemplarzach opracowania należy wymienić twórcę i tytuł utworu pierwotnego.

Kluczem są tu pkt. 2. i 5. mówiące, że autor dzieła pierwotnego zachowuje pełnie kontroli nad dziełem zależnym. Tu pierwsza ważna konkluzja, nie raz opisywana na moim blogu: jeżeli oprogramowanie powstaje na bazie ogólnego opisu funkcjonalności, jest ono samodzielnym utworem inspirowanym. Jeżeli jednak oprogramowanie powstanie “pod dyktando” projektu technicznego (jest on z zasady samodzielnym utworem), wyrażonego za pomocą wzorów matematycznych, algorytmów i schematów blokowych, to jest ono (to oprogramowanie) dziełem zależnym, podobnie jak tłumaczenie książki z innego języka czy dom zbudowany na podstawie projektu architektonicznego. Pewna burzę w sieci wywołał prawomocny wyrok z 2017 roku:

Sąd Najwyższy uznał, że jednorazowe wykonanie koncertu przez skrzypaczkę, która nie była solistką, objęte jest umową zlecenia, a nie umową o dzieło. Nawet jeśli wykonanie było artystyczne. Nakazał od takiej umowy odprowadzić składki na ubezpieczenie społeczne. Przedmiotem umowy było przygotowanie i wykonanie cudzego utworu. Czytaj: WSA: twórcy na etacie trzeba wyodrębnić autorskie wynagrodzenie (źr.: Wykonanie koncertu nie zawsze jest dziełem).

Pełne uzasadnienie sądu zawiera także opis mechanizmu kwalifikacji tego co jest utworem i jakim, który wyżej opisałem.

Niestety dostawcy oprogramowania często wykorzystują niewiedzę swoich klientów (i ich prawników także). Standardem są także zalecenia jakie developerzy dają swoim klientom: proszę nie zlecać nikomu analizy, my sami ją wykonamy za darmo. W konsekwencji dostawca oprogramowania, pod dyktando swojego klienta (agile itp.) najpierw tworzy dość ogólną listę wymagań (to ta darmowa analiza), a potem tworzy oprogramowanie. Klient dostarczył wszystkich niezbędnych informacji o sobie i swoich potrzebach, pokrył 100% wszystkich kosztów (i marżę) powstania tego oprogramowania (słynne i mityczne zarazem mendejsy) i na koniec słyszy, że ma jeszcze dodatkowo zapłacić za prawa majątkowe do tego kodu, jeżeli chce nim dysponować. Brzmi to dokładnie tak samo, jak stara anegdota o konsultancie, który na pytanie swojego klienta: “Która jest godzina”, prosi klienta o jego zegarek, odpowiada na pytanie Która godzina, i dodaje, że odda mu zegarek ale wraz z płatną licencją na jego dalsze używanie. Więcej o tym napisałem między innymi w 2012 roku w tekście Sprzedam Ci prawa do kodu czyli wielka ściema.

Drugim, jeszcze bardziej nieuczciwym zapisem w umowach, jest ten mówiący, że “wszelkie wartości intelektualne, jakie powstaną w toku realizacji projektu, przechodzą na własność dostawcy/wykonawcy oprogramowania”. W obu przypadkach jest to ordynarna kradzież know-how.

Body leasing czyli co?

Wynajem programistów, czy ogólnie “specjalistów IT”, to kolejny problem w obszarze praw autorskich. Pojęcie prawa autorskiego i sformułowanie tego co konkretnie jest przedmiotem pracy (świadczonej usługi) szczególnie tu wymaga precyzji.

Programistę można zatrudnić (wynająć) na umowę o dzieło, wtedy w tej branży najprawdopodobniej będzie ono (dzieło) utworem w rozumieniu Ustawy. Można także na umowę zlecenie, i wtedy już nie koniecznie. Specyfikę różnicy między realizacją usługi jako umowy starannego działania a umowy efektu, opisałem w tekście Kto winien porażki projektu?

Na czym polega wynajem programisty? Poniższy diagram, pokazuje model takiej usługi:

Kluczem jest tu jest sformułowanie przedmiotu umowy. Umowa na pośrednictwo jest prosta: pośrednik bierze prowizje za pośrednictwo w zaangażowaniu (wynajem) np. programisty. Współpraca ma miejsce pomiędzy Zleceniodawcą a Wynajmowanym do pracy programistą. To ich współpraca prowadzi do powstania oprogramowania. Niewątpliwie powstanie tu utwór. Kto i jakie ma do niego prawa? I tu pojawia sie słynne “to zależy”. Od czego? W 100% od treści komunikacji w toku współpracy, pomiędzy Zleceniodawcą a Wynajętym programistą.

Jeżeli programista dostaje szczegółowe instrukcje (projekt) co ma “zakodować”, wtedy sprawa jest prosta: rozliczenie jest godzinowe (zlecenie czyli umowa starannego działania) i jest on wyłącznie “dobrym rzemieślnikiem” (polecam literaturę na temat software craftsmanship). Autorskie prawa majątkowe i osobiste ma twórca projektu czyli szczegółowych instrukcji dla programisty (podobnie jak na budowie: prawa autorskie majątkowe i osobiste do projektu budowli zachowuje architekt a nie wykonawca inwestycji). Programista albo nie ma żadnych praw do tego co “napisał pod dyktando”, albo jest twórcą dzieła zależnego (co może tu mieć miejsce).

Jeżeli programista dostaje ogólne informacje i sam rozwiązuje problemy, staje się także projektantem, jest on więc autorem utworu pierwotnego, który stworzył (tu ma miejsce pierwotne ustalenie utworu). Tak więc konieczne jest (o ile chce tego Zleceniodawca), przeniesienie praw majątkowych do kodu wraz z prawem zlecania tworzenia dzieł zależnych (bez tego rozwój oprogramowania może być niemożliwy, migracja do innej technologii na pewno nie będzie możliwa, warto tu jednak zwrócić uwagę na to, że prawa do kodu mogą być bezwartościowe, jeżeli jest on nieudokumentowany lub niskiej jakości).

Tak więc sam fakt “wynajęcia” programisty absolutnie nie rodzi konsekwencji w postaci powstania obowiązku zbycia praw majątkowych do produktu pracy tego programisty:

Jak wyjaśnił Sąd Apelacyjny w Krakowie w wyroku z dnia 22 lutego 2017 r. (I ACa 1061/16) przedmiotem umowy body leasing w IT jest wykonanie usług outsourcingu kadrowego pracowników polegających na udostępnieniu pracowników będących wykwalifikowanymi informatykami ? programistami w sposób i na warunkach przewidzianych tą umową.
W związku z powyższym, w ocenie Sądu, nie ma zatem żadnych podstaw do przyjęcia, że umowy taka jest umową na wykonanie dzieła w postaci wytworzenia określonego oprogramowania. Dalej Sąd wyjaśnił, że przedsiębiorca delegujący pracowników do innego przedsiębiorcy w związku z wykonaniem umowy leasingu pracowniczego nie jest odpowiedzialny za rezultat świadczonych przez te osoby usług, w szczególności powstanie i funkcjonowanie programu komputerowego.

(źr. https://prawodlabiznesu.eu/it/body-leasing-w-it/)

Moim zdaniem najlepszym rozwiązaniem problemu praw autorskich, jest dodatkowa (opcjonalna) odrębna umowa pomiędzy Zleceniodawcą a Programistą, na przeniesienie praw majątkowych, w ramach wynagrodzenia jakie ten otrzymuje. Wariant, w którym w przekazaniu praw majątkowych między Zleceniodawcą a Programistą pośredniczyłby Pośrednik, jest bardzo skomplikowany i z tego powodu chyba najgorszy.

W przypadku takiej umowy (przeniesienie praw majątkowych do kodu) pojawia się jednak dodatkowy problem autorskich praw osobistych: są one niezbywalne. Bardzo rzeczowo opisuje to autorka tego tekstu:

Tego typu klauzule stosujemy bardzo często w przypadku przenoszenia praw do utworów tworzonych na zamówienie, lub przeznaczonych do przypisania innej osobie już na etapie jego tworzenia. Klauzula poufności W przypadku ustalenia przez strony, że twórca zobowiązuje się do niewykonywania autorskich praw osobistych jednocześnie zawiera się postanowienia dotyczące poufności. Mogą mieć one charakter dodatkowej umowy, lub stanowić część umowy o przeniesienie praw autorskich. Takie umowy często określa się skrótowo NDA lub CDA od angielskich nazw umów o zachowanie poufności. Obowiązek zachowania tajemnicy również najczęściej zabezpiecza się wysoką karą umowną. W efekcie twórca otrzymuje wynagrodzenie, ale zobowiązuje się to niewykonywania autorskich praw osobistych oraz jednocześnie zachowania pełnej tajemnicy. Dotyczy ona zarówno tego co stworzył jak i dla kogo, kto nabył prawa majątkowe itd. Nie może więc pochwalić się swoim dorobkiem przed przyszłymi klientami, nie rośnie też jego renoma. (źr. Zobowiązanie do niewykonywania praw autorskich – Legalni Twórcy).

Pozostaje tu jedynie moralna ocena takich klauzul/umów (zrzekanie się wykonywania autorskich praw osobistych). I mamy tu dwa aspekty: wymuszanie takich zapisów na autorach gdy zleceniodawca ma przewagę negocjacyjną (masz tę robotę albo nie masz), oraz świadoma zgoda na podszywanie się innych ludzi pod własną pracę, czyli świadome okłamywanie innych co do tego kto tak na prawde “to wymyślił”. I ten wątek, etyki, pozostawię czytelnikom, bo jest to indywidualna sprawa każdego z nas. W moim “Regulaminie świadczenia usług” przeczytacie, że “nie zrzekam się wykonywania autorskich praw osobistych”. O umowach o poufności więcej pisałem w tekście Czy umowy o poufności mają sens.

Kwestie umów o zakazie konkurencji są tu także wątpliwe, gdyż umowa taka wymaga wskazanie rodzaju “zakazanych” prac na rzecz danego podmiotu, bo nie mozna komuś zakazać “jakiejkolwiek pracy” na rzecz kogoś. Zakaz konkurencji na wysokich stanowiskach menedżerskich jest dość powszechny i dotyczy umów o pracę lub kontraktów menedżerskich. Jego skuteczne egzekwowanie jest jednak bardzo wątpliwe (podobnie jak umowy NDA), gdyż nie da się skutecznie zakazać ludziom jakichkolwiek kontaktów (oczywiście pozostaje jak zawsze kwestia uczciwości, ale tej nie da sie egzekwować umową).

Na zakończenie

Wielu prawników, nie zna i nie rozumie branży inżynierskiej (projektowanie itp.) mimo, że wiele lat pomaga w tego typu umowach. Większość znanych mi prawników z zasady uznaje pisanie oprogramowania za twórczość, co nie zawsze jest prawdą. Jestem projektantem oprogramowania, w 100% przypadków programiści w moich projektach albo po prostu piszą implementację (to praca rzemieślnicza pod dyktando, programista nie ma tu żadnej swobody, a więc nie powstaje żadne JEGO dzieło o indywidualnym charakterze). Jeżeli programista faktycznie autorsko rozwiązuje jakieś problemy technologiczne, wtedy tworzy tak zwany utwór zależny (podobnie jak tłumacz tłumaczący cudzą książkę).

Nie planowałem tu wykładu z etyki biznesu, jednak uważam, że etyka jest ważna. Zainteresowanym niuansami umów starannego działania i o dzieło polecam opracowanie: Umowa o dzieło jako zobowiązanie rezultatu .

Na koniec w kwestii złożoności i życzeniowego myślenia polecam także opracowanie: BOILING FROGS? Technology organisations need to change radically to survive increasing technical and business disruption. .

Etyka jest czymś co wymyka się prawu: jest jedynie dobra wolą. Oczywistym jest, że jest ona ważna, także w biznesie, jednak to tylko dobra wola. Budowanie modelu biznesowego na dobrej woli jest niewątpliwie szczytne, ale życie uczy że także bardzo ryzykowne. Możliwe jest wyrobienie sobie dobrej marki i zaufania na rynku, ale trwa to długo. Taką markę może sobie np. wyrobić pośrednik, ale oczekiwanie, że rzesze przypadkowych klientów pośrednika zawsze zachowają etykę jest niestety wysoce naiwne.

Tak więc teza, że deweloper to grupa ludzi dobrej woli, którym wszystko się udaje w myśl zasady chcieć to móc, to niestety faktycznie myślenie życzeniowe. Wiara w etykę wszystkich na rynku, także.

Źródła