Pojęcie nadzoru autorskiego budzi wiele emocji, w branży IT jest to chyba temat tabu, głównie z powodu nadużyć twórców i dostawców oprogramowania, a także dlatego, że tu (branża IT) prawo nie zabrania pełnienia przez jeden podmiot roli projektanta i wykonawcy.
Z danych Panorama Consulting wynika, że zaledwie 12% przedsiębiorstw nie wprowadza żadnych modyfikacji systemu ERP jednak 70% firm wprowadza modyfikacje w aplikacji sięgające 25% (źr. 2017-ERP-Report):
Na budowie
Autor pewnego bloga prawnego poruszył ciekawy problem, który występuje także w projektach IT. Tu niezbyt często (a szkoda) ale występuje prawie zawsze w moich projektach, bo ja akurat realizuje projekty, w których jestem zewnętrznym projektantem. Inwestorzy to moi klienci, developer realizuje mój projekt.
Warto tu zwrócić uwagę na to, że projekty programistyczne są w prawie (prawo autorskie i ochrona know-how) pełną analogią projektów budowlanych, i przepisy te stosuje się odpowiednio. Więcej napisałem o tym w artykule o ochronie know-how.
Problem, o którym pisze autor jest zarządzanie zmianą (w IT mówimy o kastomizacji systemów np. ERP):
Wybudowanie obiektu to złożony i długotrwały proces. Od projektu do obiektu upływa dużo czasu, a inwestor często zmienia zdanie co do ostatecznego kształtu powstającego budynku. Czy inwestor może żądać wprowadzenia wszelkich zmian, wedle własnego uznania? Czy może zlecić dokonanie zmian innemu projektantowi? Czy twórca może się zmianom sprzeciwić? Jak wygląda ta sprawa na gruncie prawa autorskiego? Wcześniej pisałem o zmianach na etapie projektowania, dziś o zmianach na etapie budowania.
Projekt z dziedziny inżynierii oprogramowania, prowadzony zgodnie z najlepszymi praktykami, ma etap analizy problemu, projektowania architektury rozwiązania oraz tworzenia (dostarczenia i dostosowania) samego rozwiązania, które realizuje wybrany wykonawca. Tu także ma miejsce nadzór autora projektu nad jego realizacją (wytwarzaniem, dostosowaniem aplikacji).
To czego faktycznie inwestor może się obawiać, a z czego niestety nagminnie korzystają twórcy oprogramowania, to nadużywanie pozycji monopolu autorskiego:
[…] Warto zasygnalizować jeszcze jeden aspekt związany ze źródłem potencjalnego konfliktu między projektantem, a inwestorem. Mianowicie zdarzają się w praktyce sytuacje, gdy architekci uzależniają wprowadzenie zmiany do projektu zgodnie z zamysłem inwestora od ustanowienia dodatkowego wynagrodzenia. W takim przypadku, projektant powołuje się na swoje autorskie prawa osobiste, które zakazują osobą trzecim zmieniać jego utwór, chcąc uzyskać dodatkową korzyść majątkową. Inwestor w takich sytuacjach często byłby zupełnie pozbawiony ochrony. W literaturze pojawiły się sugestie, mimo licznych wątpliwości, żeby w takich przypadkach powoływać się na art. 5 kc, zarzucając projektantom nadużycie swoich praw. (Źródło: Prawa autorskie w ARCHITEKTURZE – Potencjalny konflikt inwestora z projektantem na tle prawa autorskiego – część 2 | IPblog – o prawie własności intelektualnej i nowych technologii)
Oprogramowanie
W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię praw autorskich do kodu jaki tworzy a jego klient żadnych mimo, że jest inwestorem! Poniżej przykład zapisu w umowie, którą niedawno audytowałem:
Wykonawca nie przenosi na Zamawiającego jakichkolwiek autorskich praw majątkowych do Oprogramowania (co dotyczy także wszystkich adaptacji, modyfikacji i kopii Oprogramowania oraz jego Dokumentacji).
Ten zapis oznacza, że dostawca oprogramowania, np. opracował (udokumentował) jakiś mechanizm działania swojego klienta (na podstawie wywiadów z nim) i zaimplementował go w wytwarzanym (rozwijanym, kastomizowanym) oprogramowaniu, jednak staje się także posiadaczem praw autorskich osobistych i majątkowych do tak opracowanej logiki biznesowej, którą potem sprzedaje (a konkretnie tylko licencjonuje) swojemu sponsorowi (i innym swoim klientom, nie raz także konkurentom sponsora). Ta logika bardzo często stanowi know-how sponsora projektu!
Zapis w innej audytowanej umowie dotyczący prac kastomizacyjnych w systemie ERP, dokonywanych przez firmę wdrażająca a nie przez producenta producenta:
W przypadku wykonania modyfikacji i dostosowania oprogramowania do potrzeb Zamawiającego, Wykonawca z dniem zapłaty wynagrodzenia za Usługi dodatkowe obejmujące ww. modyfikacje, udziela Zamawiającemu licencji na korzystanie z tych modyfikacji przez Zamawiającego, na warunkach na jakich udzielono uprzednio licencji na korzystanie z Oprogramowania. Wynagrodzenie za wykonanie przedmiotowych modyfikacji wskazanych powyżej wydzielonych części oprogramowania, obejmuje wynagrodzenie z tytułu udzielenia licencji.
To już jest kuriozum, znane z anegdot w rodzaju: “konsultant, by odpowiedzieć na pytanie Która jest teraz godzina, prosi Klienta o jego zegarek, odpowiada na pytanie, a zabrany Klientowi zegarek wypożycza mu za sowitym wynagrodzeniem”.
Ta wadliwa sytuacja, jaką tu opisałem, to np. cecha wszystkich projektów agile i tych gdzie programista jest także analitykiem i projektantem (jeżeli taki etap jest w projekcie). W efekcie projektant/wykonawca bardzo często wykorzystuje swoją pozycję podwójnie: nie wprowadza zmian dla siebie niekorzystnych (np. trudna i kosztowna realizacja) i narzuca zmiany poprawiające marże na realizowanym projekcie (upraszczanie), z czego sponsor z reguły nie zdaje sobie sprawy. Trzecim “narzędziem” budowy marży jest godzenie się na wszelkie propozycje inwestora mając kontrakt T&M, bez ostrzegania go o konsekwencjach wprowadzanych zmian dla całego projektu (a jest nią z reguły dodatkowa pracochłonność).
Bardzo wiele projektów programistycznych kończy się nie dlatego, że uzyskano oczekiwaną funkcjonalność a dlatego, że wyczerpano budżet lub czas, lub oba te zasoby.
Czy można inaczej? Oczywiście.
W umowie należy zaznaczyć, że wszelkie prace programistyczne poprzedzane są udokumentowaną analizą i projektowaniem, i że prawa majątkowe do treści tych dokumentów przechodzą na Zamawiającego. Taka sytuacja nadal jest jednak niezdrowa, bo nadal wykonawca łączy rolę projektanta i developera (czego np. prawo budowlane zabrania z uwagi na powstałą tak uprzywilejowaną pozycję developera).
Ideałem, który można łatwo osiągnąć, jest całkowite oddzielenie analizy i projektowania od realizacji (dla projektów IT zaleca to UZP w dokumencie z 2009 roku). W razie braku takich kompetencji po stronie Zamawiającego, wystarczy zatrudnić projektanta. Po prawej stronie powyżej, ilustracja z 1985 roku: MODEL to owa precyzyjna dokumentacja (to znaczy musi być precyzyjna, by można ją było uznać za projekt – utwór – chroniony prawem).
Co ciekawe, można to zrobić w dowolnej chwili nawet po podpisaniu niekorzystnej umowy (zawierającej zapisy jak te omówione powyżej). W takiej sytuacji, wykonawca, realizując projekt, otrzymuje od Zamawiającego, nie ustne czy nawet pisemne, ogólne idee swoich potrzeb, a dokumenty zawierające dokładne opracowanie projektu implementacji (logika biznesowa i architektura), którą Wykonawca ma zgodnie z umową zrealizować. Warunkiem powodzenia jest to, by autorskie prawa majątkowe do tych dokumentów były przy Zamawiającym (projektant powinien przekazać prawa majątkowe do projektu w pisemnie zawartej umowie). W takiej sytuacji Wykonawca wykonuje prawa zależne do utworu i mimo, że jest autorem implementacji, nie ma żadnych praw do dysponowania nią.
Autor cytowanego artykułu powołuje się pod jego koniec na ważny, i często zapominany paragraf Kodeksu Cywilnego:
Art. 5. Nie można czynić ze swego prawa użytku, który by był sprzeczny ze społeczno-gospodarczym przeznaczeniem tego prawa lub z zasadami współżycia społecznego. Takie działanie lub zaniechanie uprawnionego nie jest uważane za wykonywanie prawa i nie korzysta z ochrony. (KC)
I tym akcentem, zakończę ten krótki wpis 🙂 i polecam też lekturę całego cytowanego artykułu.
