Mity umów wdrożeniowych. Mit 2 – odbiór końcowy końcem problemów

Jak wiadomo, zasadniczym celem każdego kierownika projektu jest doprowadzenie do szczęśliwego podpisania przez zamawiającego protokołu odbioru końcowego. Z niejasnych przyczyn większość dostawców systemów informatycznych uznaje, że jeżeli uda im się przekonać kontrahenta do złożenia podpisu na dokumencie potwierdzającym zakończenie realizacji umowy, to uzyskują tym samym niepodważalny dowód wywiązania się z umowy. Zła wiadomość jest taka, że wspomniana większość się myli.

Oczywiście podpisanie odpowiedniego protokołu jest istotnym zdarzeniem, ponieważ zazwyczaj oznacza uzyskanie dokumentu umożliwiającego domaganie się wynagrodzenia za wykonane prace, jest to jednak zdarzenie o charakterze czysto proceduralnym, a sam dokument ma jedynie walor dowodowy.

Jeżeli po „pozytywnym odbiorze końcowym” okaże się, że system nie spełnia któregoś ze zdefiniowanych umową wymagań, to nie oznacza to jeszcze, że klient automatycznie z tego wymagania rezygnuje. Trzeba pamiętać, że ocenie podlega stan faktyczny, a nie stan utrwalony w dokumentach – jeżeli zgodnie z umową ma zostać dostarczonych np. 6 serwerów, w rzeczywistości zostało dostarczonych 5, a klient podpisał protokół odbioru, z którego wynika, że otrzymał 6 urządzeń, to nie oznacza to, że umowa została należycie wykonana. W podanym powyżej przykładzie klient będzie miał roszczenie o dostarczenie szóstego serwera, choćby cały zarząd własną krwią podpisał się na protokole potwierdzającym odbiór sześciu sztuk. Umowa została bowiem wykonana nienależycie i klient może w związku z tym domagać się jej wykonania oraz naprawienia powstałej szkody (w tym może naliczyć kary umowne za zwłokę, o ile zostały one przewidziane na okoliczność nie dostarczenia w terminie całości sprzętu).

Powyższa sytuacja jest dość jednoznaczna, ale zasada oceniania faktów, a nie rzeczywistości papierowej, działa także w przypadku bardziej złożonych stanów faktycznych. Jeżeli klient potwierdził odbiór systemu, a np. miesiąc po odbiorze ujawniły się jego wady, to wykonawca będzie zobowiązany do ich usunięcia na jednej z kilku możliwych podstaw (w zależności od treści umowy, np. na podstawie przepisów o rękojmi lub o gwarancji), a także będzie odpowiedzialny za szkodę poniesioną przez klienta wskutek nienależytego wykonania umowy. Ponieważ doskonale wiadomo, że żaden system informatyczny nie jest wolny od wad, trzeba taką okoliczność uwzględniać w umowie. Wskazane jest określanie dopuszczalnego poziomu błędów i takie definiowanie treści zobowiązań, żeby nie narazić się na wielomilionowe odszkodowanie w związku z zawieszeniem się systemu pół roku po jego odbiorze… Wskazane jest oczywiście także tworzenie systemów, które się nie wieszają, ale jak na razie bardziej prawdopodobne jest chyba oswojenie klientów z myślą, że nie dostaną nigdy doskonałego i całkowicie pozbawionego błędów produktu informatycznego.

W następnym odcinku mit 3 – nie ma kar, nie ma problemu

Opis przedmiotu zamówienia w przetargach informatycznych cz.1

Każdy, kto kiedykolwiek miał do czynienia z przetargami informatycznymi wie, że opis przedmiotu zamówienia to jeden z trudniejszych aspektów przygotowania takiego postępowania. Dotyczy to w szczególności przetargów na zakup oprogramowania komputerowego Z jednej strony każdy chciałby zakupić oprogramowanie, którym jest w taki czy inny sposób zainteresowany, zdając sobie przy tym sprawę, że oprogramowanie oprogramowaniu nierówne. Z drugiej strony stoją jednak wymogi ustawy – Prawo zamówień publicznych, które w istotny sposób hamują różnego rodzaju zapędy zmierzające w kierunku wpisania do specyfikacji czy ogłoszenia nazwy konkretnego oprogramowania.

Jednym z takich ograniczeń jest wynikający z art. 29 ust. 3 pzp wymóg, użycia słów „lub równoważny”. Sam przepis brzmi stosunkowo prosto: „Przedmiotu zamówienia nie można opisywać przez wskazanie znaków towarowych, patentów lub pochodzenia, chyba że jest to uzasadnione specyfiką przedmiotu zamówienia i zamawiający nie może opisać przedmiotu zamówienia za pomocą dostatecznie dokładnych określeń, a wskazaniu takiemu towarzyszą wyrazy ". W istocie prostota tej regulacji jest tylko pozorna, a cytowany przepis zawiera cały szereg problemów.

Zacznijmy jednak od końca. Ilekroć zgodnie ze wskazanym przepisem będzie dopuszczalne użycie nazwy własnej określonego oprogramowania czy rozwiązania informatycznego, obok tej nazwy musi pojawić się magiczne sformułowanie "lub równoważny". Wymóg ten jest bezwzględny, co oznacza, że wskazane przez ustawodawcę słowa muszą się znaleźć obok nazwy produktu, choćby podmiot organizujący postępowanie miał 100% przekonanie, że w istocie nie ma produktu równoważnego. Kilku śmiałków na przestrzeni lat obowiązywania tego przepisu, usiłowało odstąpić od spełnienia tego wymogu, argumentując (skądinąd słusznie), że skoro produkt równoważny w przyrodzie nie występuje, to wpisywanie takiego wymogu do SIWZ jest zbędne i bezprzedmiotowe. O ile z punktu widzenia logiki mieli oni rację, to z punktu widzenia prawnego już nie. Ich kości do dzisiaj bieleją przez budynkiem Urzędu Zamówień Publicznych, gdzie polegli w toku arbitrażu. Polegli słusznie, gdyż jak wspomniałem, przepis nie przewiduje wyjątku do zastosowania słowa klucza. Jeszcze w poprzednio obowiązujących przepisach dopuszczalne było użycie określenia "lub równoważne" lub inne równoznacznych wyrazów, co – jakkolwiek nie rozwiązywało problemu – to przynajmniej pozwalało na bardziej elastyczne podejście językowe do opisu przedmiotu zamówienia. Możliwość tą zlikwidowano jednak w maju 2006 r., przy okazji ostatniej nowelizacji prawa zamówień publicznych.

Oczywiście można dyskutować nad sensem takiego rozwiązania. Problem jednak w tym, że wymóg ten pochodzi wprost z art. 23 ust. 8 – Specyfikacje techniczne, dyrektywy 2004/18/WE Parlamentu Europejskiego i Rady z dnia 31 marca 2004 r. w sprawie koordynacji procedur udzielania zamówień publicznych na roboty budowlane, dostawy i usługi, który wymóg ten ujął następującym wymaganiem: „8. Jeżeli nie uzasadnia tego przedmiot zamówienia, specyfikacje techniczne nie mogą zawierać odniesienia do konkretnej marki ani źródła ani też do żadnego szczególnego procesu, znaku handlowego, patentu, typu, pochodzenia lub produkcji, które mogłyby prowadzić do uprzywilejowania lub wyeliminowania pewnych przedsiębiorstw albo produktów. Odniesienie takie jest dopuszczalne wyłącznie w wyjątkowych sytuacjach, gdy dostatecznie precyzyjny i zrozumiały opis przedmiotu zamówienia, zgodny z ust. 3 i 4, nie jest możliwy; odniesieniu takiemu towarzyszą słowa ”. Zmiana regulacji polskich musiałaby oznaczać zmianę dopiero co przyjętej nowej dyrektywy „klasycznej”, co wydaje się mało prawdopodobne. Pozostaje więc polubić nasze rodzime rozwiązanie, co więcej – nauczyć się z nim żyć.

Samo użycie słów „lub równoważny” to nie jedyny wymóg w tym zakresie. O kolejnych – za kilka dni.

Batalia o mp3 trwa …

Jak ostatnio mogliśmy się dowiedzieć w kilku serwisach internetowych i prasie (np: tu), ściąganie muzyki i filmów z Internetu nie jest zabronione i ścigane policyjnie nie będzie. Wysiłki skupione będą na ściganiu tych, co pobierają programy (bo w takim przypadku nie ma dozwolonego użytku prywatnego) lub pliki rozpowszechniają (bo jest to zabronione wprost).

Wniosek, na gruncie prawa polskiego, wydaje się słuszny (patrz też nasz artykuł o mp3). Na świecie jednak batalia wciąż trwa. Na stronach Związku Producentów Audio – Video (tutaj) jest bardzo ciekawa notatka o procesie w Danii przeciwko serwisowi allofmp3.ru. Ciekawy to serwis, gdyż – w odróżnieniu od p2p – nie wymaga udostępniania plików na zewnątrz, można tylko ściągać, co według wielu osób jest przesłanką skorzystania z dobrodziejstw dozwolonego użytku prywatnego i legalnego pobierania muzyki. Wyrok dla abonentów serwisu niekorzystny, sąd nakazał providerowi zablokować do niego dostęp.

Jak widać, praktyka podejścia do dozwolonego użytku osobistego jest bardzo różna. Niby Unia, niby wspólne dyrektywy (acz bardzo nieprecyzyjne w tym zakresie), standardów prawnych brak. Może i dobrze, gdyż mam wrażenie, że standardy które udaje się uzgodnić, idą o jeden krok za daleko, a współczesna ochrona własności intelektualnej zaczyna mieć kagańcowy charakter. Może przynajmniej w zakresie swobód ściągania mp3 będziemy bardziej szczęśliwi niż Duńczycy, najbardziej (ponoć) zadowolony naród świata.

Kod Da Vinci i Kod binarny - Dan Brown a programy komputerowe

Kilkanaście dni temu media podały informację o oddaleniu przez angielski sąd apelacyjny powództwa Michaela Baigenta i Richarda Leigha przeciwko Danowi Brownowi (a konkretnie przeciw jego wydawcy) o rzekomy plagiat ich książki „Święta Krew i Święty Graal” (“The Holy Blood and the Holy Grail”). Autorzy zarzucali, że obecna megagwiazda pisarstwa skopiowała ich pomysł, akcje i rozwiązania twórcze, a nader sławny „Kod Leonarda Da Vinci” to tylko przeróbka ich dzieła. Wiadomość przemknęła przez media, wywołała chwilę zaciekawienia i sprawa ucichła. A szkoda.

Problem, który poruszyli Baigent i Leigh, to Święty Graal prawa autorskiego – odpowiedź na pytanie, jak daleko ma sięgać ochrona prawna, w jakim stopniu wolno czerpać z pracy innych osób. Jak wiemy, prawo autorskie nie chroni pomysłów, chroni sposób ich wyrażenia. W praktyce rozstrzygnięcie gdzie leży granica ochrony jest bardzo trudne. Przyjmijmy, że faktycznie pomysł związku Jezusa i Marii Magdaleny, ich ukrytego dziecka, tajnego stowarzyszenia chroniącego owa tajemnicę, to pomysł przegranych powodów. Czy gdyby książka Michaela Baigenta i Richarda Leigha opowiadała nie tylko o „świętej krwi”, ale była historią morderstwa kustosza muzeum i pościgu naukowca za mordercą, konfliktu z tajnymi stowarzyszenia i Opus Dei, to czy opisanie jej innymi słowami przez Dana Browna też uznalibyśmy za „inspirację pomysłem” (w końcu nie przepisano żadnej linijki wprost), czy jednak stwierdzilibyśmy, że takie kopiowanie nie może być chronione?

Problem dotyczy także IT. W przypadku programów komputerowych kwestia jest podwójnie zawiła, gdyż mamy do czynienia z teoretycznie niedostępną warstwą literalną (kod źródłowy) i niepoznawalnym bezpośrednio dla człowieka kodem wynikowym. Klasyczny plagiat polega na skopiowaniu warstwy literalnej – jeżeli tak uczynimy z kodem źródłowym, zarzut naruszenia praw jest bardzo prawdopodobny i stosunkowo łatwy do dowodzenia (choć też różnie oceniano zakres „kradzieży” w orzecznictwie zachodnim – w wielkim skrócie: musi to być zapożyczenie „znaczne” co do jakości lub ilości). Jeżeli nie dokonamy (niedozwolonej w większości przypadków) dekompilacji, nie mamy jak dokonać takiego literalnego plagiatu. Jedyne co możemy robić to dokładnie badać funkcjonowanie programu i odczytać stojące za nim pomysły i algorytmy. Podobnie, korzystając z kodów źródłowych, nie musimy ich kopiować, często największą wartością jest poznanie sposobu rozwiązania. Możemy więc tworzyć bardzo podobne programy, realizujące te same funkcje, posiadające ten sam interfejs (Apple vs Microsoft) nie naruszając warstwy literalnej. Takie działania są stosunkowo częste, nie zawsze wynikają ze złej woli – klasycznym przypadkiem są pracownicy wykorzystujący w nowej pracy swoje doświadczenia i wypracowane rozwiązania. Nie można wykluczyć, że w takiej sytuacji dojdzie do takiego skopiowania układu funkcjonalnego i algorytmów, że uzasadni to roszczenia o naruszenie praw autorskich. Dowodem takich zdarzeń jest stosunkowo duża ilość pozwów i spraw w sądach, przede wszystkim amerykańskich. Wydano tam kilka ważnych wyroków, niejednokrotnie sięgając bardzo głęboko w poszukiwaniu rozwiązania – omówienie poglądów judykatury wykracza poza ramy niniejszej notatki, ale kiedyś do tego chciałbym wrócić. Sprawa nie tylko o doniosłym znaczeniu praktycznym, ale prawniczo nader ciekawa.

Jaki wniosek wypływa ze sprawy Browna? Jak dla mnie, jest to kolejny przykład umacniania się praw autorskich i próby rozszerzenia ich ochrony (choć tym razem nieskutecznej). Prędzej czy później na polskim rynku IT dojdzie do podobnych sporów, a obserwując praktykę tworzenia softwaru nie mogę wykluczyć, że część takich roszczeń – w odróżnieniu od powództwa Baigenta i Leigha – zakończy się sukcesem. Rozmyślając nad ewentualnym pozwem warto jednak mieć na uwadze, że wspomniani powodowie muszą zwrócić koszty postępowania w wysokości 3 milionów funtów. Co nie zachęca do bezpodstawnych oskarżeń.

Umowy licencyjne w zamówieniach publicznych

Przepisy prawa zamówień publicznych (pzp) są, jak rzadko które, niedostosowane do prawa nowych technologii. I jak rzadko które mają rzeczywisty wpływ na branżę IT. Ciekawym przykładem na poparcie tej tezy jest fenomen umów licencyjnych.
Art. 142 ust. 1 pzp zakazuje zawierania umów na czas nieoznaczony. Jedyny wyjątek od tej zasady przewiduje kolejny art. 143 ustawy, dopuszczający umowy na czas nieoznaczony w branżach, które nie mają wiele wspólnego z kontraktami IT (umowy na dostawy wody za pomocą sieci wodno-kanalizacyjnej lub odprowadzanie ścieków do takiej sieci, energii elektrycznej itp.). Oznacza to, że wszystkie umowy winny być zawierane na czas oznaczony, a – zgodnie z art. 142 ust. 2 – umowy, których przedmiotem jest świadczenie okresowe lub ciągłe (czyli mówiąc praktycznie umowy, w których obowiązki wykonawcy są stale te same lub powtarzają się cyklicznie, jak najem, licencja czy serwis) co do zasady winny być zawierane na okres nie dłuższy niż 4 lata (z pewnymi wyjątkami).
Zasada ta (skutkująca co najmniej częściową nieważnością umów zawartych wbrew przepisom!) pozostaje w jaskrawej sprzeczności z warunkami większości umów licencyjnych. Prawie wszyscy producenci udzielają licencji na czas nieoznaczony. Mało kto się zastanawia nad tym problem, gdyż opłata licencyjna jest jednorazowa, interesy zamawiającego nie są narażone, ale w świetle prawa problem jest bardzo poważny. Jeżeli przyszło by komuś na myśl (np. Prezesowi Urzędu Zamówień Publicznych - art. 146 ust. 2 pzp) zakwestionować te umowy, obrona ich ważności byłaby bardzo trudna. A gdyby się nie powiodła, to mamy do czynienia z świadczeniami z bezpodstawnego wzbogacenia (z obowiązkiem zwrotu świadczeń), z olbrzymimi kłopotami podatkowymi etc etc. I, o ironio, podmiot publiczny nie mając ważnej umowy narusza prawo autorskie, za co grożą mu wysokie sankcje cywilne i – niewykluczone w pewnym zakresie – karne. Jakkolwiek absurdalne to się nie wydaje, tak jest w świetle przepisów.
Duża część umów licencyjnych nic nie mówi o czasie ich trwania – ale wtedy, zgodnie z 66 ust. 1 i 2 prawa autorskiego, licencja taka jest udzielona na 5 lat. Też sprzecznie z prawem zamówień publicznych, co może prowadzić do nieważność. Tu sytuacja jest jednak trochę lepsza, albowiem Zamawiający może zawrzeć umowę licencyjną na okres dłuższy niż 4 lata (ale dalej zawsze na czas oznaczony), jeżeli wykonanie zamówienia w dłuższym okresie spowoduje oszczędności kosztów realizacji zamówienia w stosunku do okresu czteroletniego lub jest to uzasadnione zdolnościami płatniczymi zamawiającego lub zakresem planowanych nakładów oraz okresem niezbędnym do ich spłaty. Zważywszy, że zwykle cena licencji na 4 lata będzie taka sama jak na 5 lat, przesłanka „oszczędności kosztów realizacji zamówienia” zwykle będzie spełniona.
Dodatkowo problem wynika z faktu, że w razie zawarcia umowy na czas nieokreślony, nie ma zgody co do zakresu nieważności takiej umowy. W myśl jednego stanowiska, nieważna jest cała umowa od samego początku, zgodnie z drugim poglądem, nieważna jest tylko ta część umowy, która wykracza poza zakres 4 lat. Drugi pogląd jest dla zamawiających nieco korzystniejszy, jakkolwiek szczerze powiedziawszy jest to mała pociecha, zważywszy, że i tak po 4 latach będzie miał problem, a dodatkowo nie wie, czy drugie stanowisko zostanie podzielone przez sąd orzekający. Niektórzy prawnicy stawiają tezę o „darowiźnie” licencji powyżej czwartego roku, lecz teza ta nie jest do obrony ani podatkowo ani w świetle zapisów umowy.
Co z tym zrobić? Niewiele. Można przygotowywać przetargi na 4 lata (i tak ściśle z prawniczo powinno być), można rezygnować z umów licencyjnych na rzecz nabycia „towarowego”, bezlicencyjnego – wtedy nie ma ograniczeń czasowych, a zakres uprawnień wyznacza art. 75 ust. 1 prawa autorskiego. Tego typu rozwiązania idą wbrew zwyczajom i praktyce rynku – takich ofert w zakresie profesjonalnego oprogramowania po prostu nie ma. I koło się zamyka. Pozostaje nam pocieszać się, że problem istnieje od samego początku zamówień publicznych, czyli od 1995 roku i nic się nie stało. Ale to marne i ryzykowne pocieszenie …

Nowelizacje, nowelizacje (tym razem bazy danych)

Wczoraj podaliśmy informację o nowelizacji prawa autorskiego. Przydatnej, nie rewolucyjnej. Dzisiaj o nowelizacji - tą samą ustawą - ustawy o ochronie baz danych. Rewolucyjnej.
Bazy danych, które nie spełniały przesłanek utworu z prawa autorskiego (nie były twórcze, np. książka telefoniczna czy spis notowań z GPW) nie były aż do 2001 roku chronione. W ogóle. Frustrowało to wiele osób, które się napracowały, ale każdy mógł (mniej więcej) z tego dorobku korzystać bez zapłaty wynagrodzenia. W końcu Unia uchwaliła stosowną dyrektywę, a polski parlament ustawę. I - jak mawiał nieodżałowany Pan Kierownik Federowicza -"wszystko pozostało tak samo, tylko zamiast wpisano ". W wersji unijnej bazy danych podlegały ochronie niezależnie od ochrony z prawa autorskiego. A w Polsce nie - ustawa mówiła, że ochronie podlegają tylko te bazy, które nie są twórcze. Ochrona rozłączna, albo – albo.
Gdyby nie chodziło o poważne pieniądze, byłoby nawet śmiesznie. Jak ktoś poczuł, że prawa do jego bazy danych są naruszone i wybierał ochronę z baz danych (w wielu wypadkach jest to wybór rozsądniejszy niż prawo autorskie) to w sądzie jego przeciwnik udowadniał mu, że nie może tej ustawy stosować, bo przedmiotowa baza danych jest twórcza. Na co powód wytaczał szereg argument, że skąd, w jego pracy za grosz twórczości. Na co pozwany piał z zachwytu nad niebanalnością, indywidualnością i oryginalnością rozwiązania autora. Qui pro quo (stosowane odpowiednio :).

Teraz wracamy do normalności i ochrona baz danych powinna nabrać szerszego rozmiaru. Jeżeli ktoś jest producentem bazy danych, powinien bardzo poważnie rozważyć możliwość użycia tej ochrony zamiast prawa autorskiego. Nowela zmieniła także przepisy proceduralne na wzór rozwiązań z prawa autorskiego, co również jest ułatwieniem dla poszkodowanego.

Zmiana jak najbardziej słuszna, szkoda tylko, że zajęło to ustawodawcy sześć lat.

Nowelizacja prawa autorskiego

16 marca 2007 roku Sejm uchwalił nowelizację ustawy o prawie autorskim i prawach pokrewnych. Nowelizacja związana jest z implementacją 4 dyrektyw unijnych – Dyrektywy nr 93/83/EWG z dnia 27 września 1993 r. w sprawie koordynacji niektórych zasad dotyczących prawa autorskiego oraz praw pokrewnych stosowanych w odniesieniu do przekazu satelitarnego oraz retransmisji drogą kablową, Dyrektywy nr 93/98/EWG z dnia 29 października 1993 r. w sprawie harmonizacji czasu ochrony prawa autorskiego i niektórych praw pokrewnych; Dyrektywy nr 96/9/WE Parlamentu Europejskiego i Rady z dnia 11 marca 1996 r. w sprawie prawnej ochrony baz danych oraz Dyrektywy nr 2004/48/WE Parlamentu Europejskiego i Rady z dnia 29 kwietnia 2004 r. w sprawie egzekwowania praw własności intelektualnej.

Zakres nowelizacji obejmuje:

1. dodanie art. 6 (1) – dotyczącego rozpowszechniania utworu drogą emisji radiowej lub telewizyjnej prowadzonej w sposób satelitarny
2. modyfikacji przepisów dotyczących zasad odpowiedzialności za naruszenie prawa autorskich (art. 79 Prawa autorskiego).
3. modyfikacji zasad procesowych dotyczących ochrony praw autorskich (art. 80 Prawa autorskiego).
4. modyfikacji przepisów dotyczących ochrony fonogramów i wideogramów

Najbardziej interesującym IT zagadnieniem jest zmiana treści art. 79, kluczowego dla rozstrzygania sporów o naruszenie praw. W porównaniu z dotychczasową regulacją, twórca (podmiot uprawniony) uzyskał dodatkowe uprawnienie – „o usunięcie skutków naruszenia”. Dodatkowo – jeżeli zaniechanie niezawinionego naruszenia lub usunięcie jego skutków byłoby dla osoby naruszające niewspółmiernie dotkliwe, za zgodą uprawnionego i na wniosek naruszającego sąd może nakazać zapłatę stosownej sumy pieniężnej na rzecz uprawnionego. Na etapie sporu sądowego możliwe będzie również orzeczenie (na wniosek uprawnionego) o wycofaniu z obrotu, przyznaniu uprawnionemu na poczet należnego odszkodowania lub zniszczeniu bezprawnie wytworzonych przedmiotów, środków i materiałów użytych do ich wytworzenia.

Ciekawa jest też nowelizacja (de facto rozszerzenie) art. 80 prawa autorskiego – teraz w specjalnym 3 - dniowym trybie sąd będzie mógł zobowiązać inną niż pozwany osobę uczestniczącą w procesie naruszenia praw do udzielenia szeregu informacji.

Wraz z prawem autorskim znowelizowano również Prawo własności przemysłowej, ustawę o ochronie baz danych, ustawę o ochronie prawnej odmian roślin oraz Kodeks Postępowania Cywilnego.

W chwili obecnej ustawa jest rozpatrywana w Senacie. Prawdopodobnie będzie omawiana na najbliższym posiedzeniu, tj. 12 i 13 kwietnia 2007r. Tekst ustawy przesłanej do Senatu dostępny jest pod niniejszym adresem.

Podsumowanie

Rewolucji nie ma, doprecyzowano i poszerzono zasady odpowiedzialności za naruszenia praw. Ciekawie może w praktyce wyglądać quasi-ugoda o naprawienie skutków niezawinionego naruszenia praw. Takie naruszenia są stosunkowo częste, teraz mamy wprost opisaną instytucję jak załatwić spór polubownie (choć jak ktoś chciał to i tak mógł).

Na pewno w sprawach „pirackich” będzie miał znaczenie przepis o zniszczeniu czy przekazaniu „bezprawnie wytworzonych przedmiotów”, zwłaszcza, że jego zakres jest szeroki. Ten przepis poniekąd istniał i wcześniej, ale teraz jest umieszczony we „właściwym” miejscu i poprawniej sformułowany.

Na pewno procesowo życie ułatwi rozszerzony art. 80 umożliwiający szybkie uzyskanie informacji od osób uczestniczących w procederze naruszania praw (np. przy procesie dystrybutora przesłuchanie osób które mają nielegalne kopie).

Legendy i mity świata umów wdrożeniowych (część I)

Wstęp – legenda o dobrej umowie wdrożeniowej

Jak doskonale wiadomo, umowy pisane są „na złe czasy”. Zazwyczaj wszelkie zabezpieczenia, kary umowne, ograniczenia odpowiedzialności itp. zapisywane są wyłącznie „na wszelki wypadek”. Regułą jest, że jeżeli obie strony współpracują i dochowują przy tym elementarnej staranności, realizacja umowy przebiega gładko i w umówionym terminie zamawiający czy też kupujący dostaje to, co zamówił. Nikt nie sięga do kar umownych, nie nalicza odszkodowań ani nie żąda dodatkowych pieniędzy. Wyjątkiem w tym zakresie są umowy, których przedmiotem jest wdrożenie systemów informatycznych. Zazwyczaj prędzej, czy później, okazuje się, że dostawca dostarcza wadliwy produkt, nie dochowuje umówionych terminów, a zamawiający liczy nerwowo dodatkowe pieniądze, które musi dodać do pierwotnego budżetu.

W takich przypadkach okazuje się, że trzeba sięgnąć do mechanizmów zabezpieczających i sankcyjnych. Obie strony sięgają do umowy i zwracają się do swoich prawników z konkretnymi pytaniami, sprowadzającymi się w większości przypadków do jednego zagadnienia – kto jest winny? Zazwyczaj prawnicy nie wiedzą, co odpowiedzieć, bądź też udzielają odpowiedzi wysoce niesatysfakcjonującej klienta, zaczynającej się przeważnie od „To zależy…”. Nasuwa się zatem pytanie – co jest przyczyną takiego stanu rzeczy? Oczywiście przedmiotem tej opowieści nie jest strona biznesowa wdrożeń informatycznych, więc nie będę próbował odpowiadać na pytania w rodzaju: „jak należy ustalić potrzeby klienta i jak dobrze wdrożyć system, którego on oczekuje?”. Zamierzam natomiast odpowiedzieć na pytanie: w jaki sposób i czy w ogóle da się napisać dobrą umowę wdrożeniową?

Krótka wersja odpowiedzi jest taka: nie istnieje coś takiego, jak doskonała umowa wdrożeniowa, ponieważ żaden inżynier, informatyk czy handlowiec nie jest w stanie w momencie zawierania umowy opisać dokładnie systemu, który powstanie w wyniku realizacji umowy. Po pierwsze, w większości przypadków szczegółowy opis systemu będzie tworzony dopiero w czasie realizacji umowy, a po drugie, nawet w maksymalnie szczegółowej analizie funkcjonalnej lub w projekcie technicznym niejednokrotnie znajdują się zapisy pozwalające na ich różną interpretację. Nie bez znaczenia jest też powszechna skłonność zamawiających do nadmuchiwania zakresu wdrożenia oczekiwaniami, które Szanownemu Klientowi przyszły do głowy już po zaakceptowaniu analizy systemowej (przy czym w takich przypadkach dostawca zazwyczaj słyszy, że „to przecież jest oczywiste, że taka funkcjonalność musi być w systemie i wcale nie trzeba było o tym pisać”).

W tłumaczeniu na język prawnika powyższe wątpliwości oznaczają tyle, że w 99% umów wdrożeniowych nie ma w pełni zdefiniowanego zakresu zobowiązań stron. Pozostały 1% „wdrożeń” to instalacja Windows na pojedynczych komputerach. Skoro zaś nie ma precyzyjnie opisanej kwestii tak elementarnej, jak przedmiot umowy, to jest naturalne, że w toku jej realizacji powstają pytania, na które nie ma dobrych odpowiedzi. No bo jak prawnik ma odpowiedzieć na pytanie: „Czy należy się klientowi kara umowna w związku z niewykonaniem w terminie danej funkcjonalności?”, skoro nie wiadomo, czy funkcjonalność ta w ogóle miała zostać wykonana? Zarówno dostawcy, jak i ich klienci, przeważnie zdają sobie sprawę z tego problemu, ale nie nazywają go po imieniu i usiłują stosować do wdrożeń systemów informatycznych przepisy, które nie do końca się do tego nadają, wymyślając przy tym konstrukcje prawne, które w świetle obowiązujących przepisów nie mają prawa zadziałać. Świat umów wdrożeniowych dorobił się w związku z tym swoistych mitów i przesądów. Ponieważ spotykam się z nimi nagminnie i zapewniam, że ogromnie utrudniają one życie prawnikom i negocjatorom, postanowiłem rozwiać niektóre z nich.

Mit 1 – odbiory jednostronne

Jak wiadomo, jednym z najstraszliwszych koszmarów obydwu stron umowy wdrożeniowej jest sen o odbiorach (zwłaszcza o testach prowadzonych przez użytkowników). Odbiór jest bowiem tym momentem, w którym najczęściej okazuje się, że to, co zostało wykonane, nie jest tym, czego oczekuje klient. Niezależnie od tego, czy klient ma rację, czy nie, jego standardową reakcją na taki problem jest odmowa podpisania protokołu odbioru systemu lub jego części. Ponieważ zaś w umowie zapisano, że bez podpisanego obustronnie protokołu nie można wystawić faktury VAT, dostawca ma problem z uzyskaniem zapłaty za wykonany system. Aby jakoś zneutralizować problem, dostawcy walczą jak lwy o wpisywanie do umów klauzul sprowadzających się do stwierdzenia, że jeżeli zamawiający bez powodu odmówi podpisania protokołu odbioru, to dostawca może „wystawić protokół jednostronny” i na jego podstawie żądać zapłaty. Pech polega na tym, że tzw. „protokół jednostronny” nie ma żadnego znaczenia prawnego ani jakiegokolwiek waloru, poza czysto psychologicznym. Zamawiający nie będzie zobowiązany do zapłaty tylko dlatego, że klient dostarczył mu jednostronny protokół, czyli swoje własne oświadczenie co do wykonania umowy.

Patrząc na to od drugiej strony, brak zapisu o protokole jednostronnym w żaden sposób nie uniemożliwia dostawcy domagania się zapłaty za należycie zrealizowane prace. Prawo cywilne jest bowiem – w tym akurat zakresie – boleśnie proste. W największym uproszczeniu, Kodeks cywilny mówi tyle: jeżeli wykonałeś świadczenie, do którego byłeś zobowiązany, to twój kontrahent ma obowiązek wykonać swoje świadczenie (wzajemne). Czyli jeżeli wykonałeś system zgodnie z umową, to możesz żądać zapłaty. Jeżeli klient zapłacić nie chce, możesz go pozwać o zapłatę. Jeżeli klient nie chce zapłacić, ponieważ uważa, że system jest źle wykonany, to oczywiście też go możesz pozwać, przy czym niestety będziesz musiał bronić się w sądzie przed zarzutem niewykonania zobowiązania. Tak, czy inaczej, możliwość domagania się zapłaty wynika wyłącznie z faktu wykonania zobowiązania, a nie z tego, czy zostało to potwierdzone jakimkolwiek dokumentem. Na marginesie wypada przypomnieć, że identycznie podchodzi do sprawy ustawa o VAT – obowiązek podatkowy powstaje bowiem, co do zasady, w momencie faktycznego wykonania świadczenia, a nie z chwilą potwierdzenia wykonania przez drugą stronę transakcji. Powstaje więc pytanie – czy dostawcy powinni walczyć o protokoły jednostronne? Odpowiedź jest typowo prawnicza – to zależy. Zależy od tego, jaką mamy sytuację negocjacyjną i jakiego mamy kontrahenta. W skrajnie sformalizowanych dużych strukturach, walka o protokół jednostronny ma dla dostawcy sens o tyle, że taki protokół, jeżeli jest wyraźnie opisany w umowie, może czysto faktycznie ułatwić uzyskanie zapłaty, bądź też sama umowna możliwość „wystawienia” takiego protokołu może być motywująca dla strony ociągającej się z odbiorem. Nie warto jednak za protokół jednostronny umierać. Jeżeli klient stawia twarde veto, to pamiętajmy o tym, że brak upragnionego zapisu o protokole jednostronnym nie uniemożliwia dostawcy żądania zapłaty za należycie wykonane prace. Równocześnie protokołem jednostronnym dostawca nie zrobi żadnej „sztuczki” umożliwiającej uzyskanie zapłaty, jeżeli swoje zadanie wykona nienależycie, bowiem w wypadku niewykonania zobowiązania zamawiający nie jest zobowiązany do zapłaty nawet wówczas, gdy otrzyma dziesięć protokołów jednostronnych. Prawdę powiedziawszy, zamawiający w takiej sytuacji nie będzie zobowiązany do zapłaty nawet wówczas, gdy sam podpisze protokół, z którego będzie wynikać, że wykonano zobowiązanie, którego nie wykonano. Ale to już zupełnie inna historia…

Freeware, shrink-wrap, public domain, open source, free software, trial, adware, shareware etc etc – o co tu chodzi?

Zamieszanie na rynku licencyjnym jest ogromne. Zarówno w zakresie (głównie anglojęzycznego) nazewnictwa, jak i metod udostępniania oprogramowania. Warto więc przyjrzeć się, co za poszczególnymi pojęciami stoi.

Prawo autorskie posługuje się ideą „monopolu twórczego”. W wielkim skrócie oznacza to, że twórca i tylko twórca decyduje zarówno o fakcie udostępnienia, jak i zakresie udostępnienia swojego utworu. Przy czym ma kilka dróg do wyboru – może utwór sprzedać (a dokładnie sprzedać prawa majątkowe do niego - nie mylić ze sprzedażą nośnika, chodzi tutaj o sprzedaż praw), może na korzystanie z utworu udzielić licencji (w różnym zakresie wedle uznania, płatnej lub nieodpłatnej, przy czym istnieje domniemanie, że licencja jest płatna), może też „puścić” utwór w obieg bez zawierania żadnych umów (i wtedy użytkownik korzysta albo z koncepcji dozwolonego użytku osobistego albo - w odniesieniu do programów komputerowych - z tzw. licencji ustawowej z art. 75 ust. 1 prawa autorskiego). Metodę pierwszą pomijamy, gdyż nie występuje na rynku konsumenckim, trzecią też, bo wymaga odrębnego omówienia, skupmy się na licencjach.

Twórca ma (prawie) pełną swobodę kształtowania warunków licencyjnych. W praktyce można wyodrębnić trzy modele (podział mój): (i) licencje „pełne” (komercyjne), (ii) licencje nieodpłatne z ograniczeniami co do zakresu używania (z silnym monopolem autorskim), (iii) licencje nieodpłatne, bardzo szerokie co do zakresu korzystania (open source). Wszystkie jednak są licencjami, czyli złamanie warunków, na jakich zostały udzielone może skutkować odpowiedzialnością prawną.

Licencje „pełne” to umowy szczegółowo określające obowiązki stron, odpłatne, w obrocie profesjonalnym negocjowane i uzgadniane indywidualnie. W obrocie „end userskim” najczęściej spotykamy się z umowami adhezyjnymi – czyli tekstem jednostronnie narzuconym przez producenta (Microsoft, Adobe, wszyscy inni), który musimy zaakceptować w całości, aby móc korzystać z oprogramowania. Kiedyś umowy te były schowane w folii, której rozdarcie powodowało zawarcie umowy, stąd nazwa „shrink-wrap” wypierana obecnie przez internetowe „click-on” czy „click wrap”. Czy takie „kliknięciowe” umowy też są ważne? Trudne pytanie – przyjmuję, że tak, ale z licznymi zastrzeżeniami – począwszy od klauzul konsumenckich (np. umowa musi być sporządzona w języku zrozumiałym dla konsumenta, nie może pozbawiać konsumenta pewnych praw przyznanych przez ustawy itp.), zagadnień prawa właściwego (który system prawa stosować przy transakcjach transgranicznych), jak i szeregu okoliczności faktycznych (otwarcie programu przez osobę nie mogącą skutecznie zawrzeć umowy, np. dziesięcioletnie dziecko). Poniekąd taką „pełną” umową jest shareware – jest to płatne oprogramowanie, z określonym czasem na jego przetestowanie, podobne w istocie do trial-a (wersji próbnej).

Licencje nieodpłatne, ale z silnym monopolem autorskim to wszystkie rodzaje freewaru. Nie musimy za nie płacić, ale nie mamy zbyt szerokich uprawnień – z reguły ogranicza się ono do „używania” programu (zwielokrotniania w pamięci operacyjnej), bez prawa do modyfikacji czy włączania do własnych prac. Licencje freeware mogą wprowadzać szereg innych ograniczeń, podobnie jak licencje „pełne”, choć nadal są bezpłatne. Odmianą freewaru jest adware (uwaga – zdjęcie reklamy z takiego programu to załamanie warunków licencji!).

Najciekawszy jest open source – specyficzny rodzaj licencji (właściwie szeregu licencji o różnym stopniu uprawnień i zobowiązań), która zezwala na bardzo szerokie korzystanie z programu, w szczególności z prawem do jego modyfikacji i włączania do własnych rozwiązań bez opłat z tego tytułu. Ciekawostką są konsekwencje dla osoby modyfikującej open source oparty na tzw. modelu copy-left (przede wszystkim GPL i pochodne) – otóż jeśli chcemy dystrybuować zmieniony przez nas program lub włączamy w nasz soft rozwiązania oparte na GPL, to „wirus GPL” zaraża to zmodyfikowane, nowe oprogramowanie i musimy je w całości dalej rozpowszechniać wyłącznie jak GPL (czyli nieodpłatnie). Na rynku istnieje sporo autorskich projektów opartych na GPL, które istotnym nakładem pracy zostały przystosowane do określonych celów i są odpłatnie licencjonowane. Ich autorzy łamią prawo i – jak to się zdarzyło np. w Niemczech – mogą zapłacić z tego tytułu odszkodowanie. Open source nie oznacza pełnej wolności, to nadal jest licencja, w wielu aspektach zaskakująco restrykcyjna.

I jeszcze jedno w sprawie nazw – open source jest mieszany czasem z free softwarem (wolnym oprogramowaniem) – to trochę inne koncepcje filozoficzne (pierwsza nastawiona na optymalność techniczną kodu, druga na wolność jako taką), ale w dużej mierze zbieżne w efektach prawnych (zasadach licencjonowania).

Do omówienia zostało pewne dziwo - public domain. Jest to koncepcja, w myśl której program nie podlega prawu autorskiemu, nikt nie ma do niego praw, nie ma żadnych ograniczeń w jego używaniu. Klasyczny przykład to utwory, których okres ochrony upłynął (obecnie 70 lat od śmierci twórcy), choć w przypadku programów nie ma to, póki co, zastosowania. Program teoretycznie mógłby znaleźć się w „publicznej domenie” jeśli autor zrzekłby się praw do niego. I tu mamy duży problem – polskie prawo nie przewiduje takiej możliwości (przynajmniej wprost, pomijam doktrynalną dyskusję). A więc „zrzeczenie się prawa” w praktyce jest wątpliwe – można osiągnąć podobny skutek udzielając bardzo szerokiej licencji (szerszej niż open source), tylko nie znam nikogo, komu by się chciało :) A jak „puści” się program bez żadnej licencji, nie oznacza to bynajmniej domeny publicznej – oznacza to, że zamiast licencji wejdzie w życie tajemniczy art. 75 ust. 1 prawa autorskiego. O czym kiedy indziej.

Czy program komputerowy jest utworem autorskim?

Program komputerowy to utwór, jest chroniony prawem autorskim, o czym zresztą świadczy dobitnie art. 1 ust. 2 pkt. 1 prawa autorskiego. Pogląd, który wszyscy akceptują praktycznie w ciemno. Nieliczne orzecznictwo RP nigdy tezy tej nie zakwestionowało, ba, uznawało program za utwór nawet przed wejściem w życie obecnej ustawy o prawie autorskim. Roma locuta, causa finita. Warto jednak się zastanowić, czy opinia ta jest zawsze prawdziwa – kwestia równie ważna teoretycznie, jak i praktycznie. Problem można rozważyć co najmniej w dwóch aspektach – spełnienia przez program przesłanki twórczości wynikającej z art. 1 ust. 1 prawa autorskiego oraz wytyczenia granicy, które elementy programu są chronione, a które nie. Ten drugi aspekt chwilowo odkładam na bok (choć jest ultraciekawy), chciałbym skupić się na niezwykle kontrowersyjnej przesłance roli twórczości (ściśle ujmując także przesłance „indywidualnego charakteru”, ale dla dobra bloga pozostaję przy samej „twórczości”) w procesie tworzenia programu komputerowego.

Na początek definicja z ustawy: „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)”. Nie miejsce tutaj na dogłębne rozważanie jak prawo i teoria definiują twórczość, zwłaszcza, że poglądów sporo. Niezłą propozycją jest teza, iż o twórczości (i jej indywidualnym charakterze) możemy mówić, kiedy jest nieprawdopodobne, aby taki sam rezultat osiągnęły osoby o podobnych zdolnościach, postawione przed tym samym problemem. Twórczość jest zaprojektowaniem i wyborem ścieżki przy możliwości wyboru z niezliczonej ilości ścieżek. Twórcze nie będzie rozwiązanie optymalne, jedynie możliwe (czy też jedynie rozsądne w danych okolicznościach) – do takiego rozwiązania prędzej czy później dojdzie każda grupa specjalistów, choć oczywiście nie wyklucza to, iż osiągnięcie danego rezultatu wymaga ogromnej ilości pracy (amerykanie ładnie to nazywają „doktryną potu z czoła”). Tak samo ogromnej ilości pracy wymagałoby stworzenie książki telefonicznej wszystkich mieszkańców Ziemi, choć rzecz jasna twórczości w tej książce za nic (przyjmując, że byłaby ułożona alfabetycznie).

Owa cecha twórczości jest niezbędna, abyśmy mogli mówić o utworze i ochronie prawnoautorskiej. Przemysł softwarowy zawsze miał z tym problemy. Tworząc programy komputerowe, zwłaszcza o biznesowym zastosowaniu, rzadko kiedy prace są ukierunkowane na „eksplozję” artystyczną – chcemy szybko i skutecznie realizować w środowisku cyfrowym pewne zadania. I o ile trudno sobie wyobrazić skonstruowanie skomplikowanego programu bez żadnej przesłanki twórczości (chcąc nie chcąc będziemy ścieżki wybierać), to w przypadku potrzeb ściśle zdefiniowanych, programów prostszych, a zwłaszcza skryptów konfiguracyjnych, parametryzacji, programów tworzonych w ABAP-ie, wątpliwości się mnożą. Śmiem postawić tezę, że w wielu takich przypadkach nie mamy do czynienia w ogóle z utworami w rozumieniu prawa autorskiego, tylko odrębnym tworem własności intelektualnej nie spełniającym przesłanki twórczości. Twory takie nie są chronione prawem autorskim, a ponieważ katalog dóbr intelektualnych jest „numerus clausus”, w konsekwencji w ogóle nie są chronione (pomijam nieuczciwą konkurencje i inną „miękką” ochronę). Czyli wolno je m.in. kopiować, rozpowszechniać i wykorzystywać do różnych, zaskakujących (zwłaszcza dla twórcy) celów.

W przypadku częstym i wyraźnie obrazującym zagadnienie, podczas wdrożenia systemów do zarządzania przedsiębiorstwem (mySAP.com, Oracle Aplications, inne systemy ERP, systemy bankowe i dedykowane), istnieje konieczność dopasowania istniejącego programu komputerowego do potrzeb konkretnego użytkownika. Dopasowanie takie składa się z analizy sytuacji klienta, jego potrzeb, przełożenia tych potrzeb na język programu komputerowego i stworzenia odpowiednich skryptów, programów, wyboru parametrów konfiguracji itp. Owe prace programistyczne (swoją drogą niekoniecznie mające charakter oddzielnego programu komputerowego sensu stricto) ukierunkowane są na ścisły biznesowo-techniczny cel: jak zapewnić w danym środowisku realizację założeń funkcjonalnych. Jak sprawić, aby faktura wprowadzona na stanowisku sprzedaży pojawiła się w określonym czasie przed oczyma dyrektora handlowego. Tego typu zadania w wielu przypadkach nie są twórcze w znaczeniu autorskim – w praktyce istnieje bardzo wąska grupa rozwiązań, które prowadzą w racjonalny sposób do celu. Wybór między nimi wynika z pewnych założeń organizacyjnych czy technicznych, ale nie z potrzeby wyrażenia własnego „ja” – każda firma wdrożeniowa postawiona przed tym samym problemem wykonałaby tę część prac programistycznych w bardzo zbliżony sposób, choć sama praca wymaga dużego nakładu intelektualnego. Opisywany fenomen pojawia się też w przypadku niektórych rozwiązań naukowych. Programy komputerowe ze swojej istoty w dużej mierze nie są i nigdy nie będą nakierunkowanie na twórczość – twórczość o „indywidualnym charakterze” może pojawić się „mimo woli”, ale może się zdarzyć, ze nie pojawi się w ogóle.

Jak wspomniałem, własność intelektualna jest chroniona na zasadzie „numerus clausus”, czyli jest chronione tylko to, co jest wyraźnie wymienione w ustawach – np. utwory, wynalazki, znaki towarowe, topografia układów scalonych itd. Jeśli jakiś przedmiot nie ma „swojej ustawy”, nie ma wyspecjalizowanej ochrony (tak np. było z bazami danych nie spełniającymi cech utworów , które ochrony doczekały się dopiero w 2001 roku). W konsekwencji opisane powyżej programy czy skrypty, parametryzacje, konfiguracje itp. będą poza ochroną do jakiej jesteśmy przyzwyczajeni. Klient nie ograniczony w prawie do modyfikacji czy rozpowszechniania naszych rozwiązań. Co gorsza, nasza konkurencja, będzie mogła z takich rozwiązań korzystać nie narażając się na zarzut naruszania praw autorskich. Podobnie nie będzie tych praw naruszał nasz były pracownik, który identyczną pracę wykona u swojego nowego pracodawcy, wykorzystując zdobytą wiedzę.

Czy powyższy scenariusz jest realny? Jak najbardziej. Słynna bitwa o patenty to m.in. przejaw powyższego problemu, niedopasowania prawa autorskiego do ochrony programów komputerowych i obaw producentów. Taka sytuacja wymusza na prawnikach niezwykłą uwagę przy konstruowaniu umów wdrożeniowych i licencyjnych (część zabezpieczeń można wprowadzić umową, choć jest to półśrodek), a na biznesie rozważenie innych niż prawo metod ochrony takiej własności intelektualnej (np. szyfrowanie rezultatów prac). A przy okazji to niezły przykład, jak trudno klasycznymi konstrukcjami prawnymi uregulować współczesny przemysł IT.

(c) Marcin Maruta 2007