Cudne, cudne ...

Piękny artykuł na itbiznes.pl. Oczywiście pomysł ścigania rozpowszechniania numeru jest absurdalny, ale cudownie wskazuje na postępująca paranoizację ochrony tego, co niektórzy uważają za własność intelektualną ...

Kim jest twórca programu komputerowego, czyli opowieść na pograniczu schizofrenii

Prawo autorskie teoretycznie jest proste i intuicyjne – twórcą jest ten, który utwór stworzył. Sienkiewicz, Beethoven czy Klimt – nie mielibyśmy większych problemów z identyfikacją kreatora dzieła. Jeżeli zagłębimy się w przemysł IT, na pytanie kto stworzył oprogramowanie Windows odpowiedź brzmi „Microsoft”. Odpowiedź błędna, gdyż twórca musi być osobą fizyczną. Zachodzi tutaj ciekawy przypadek zacierania się pojęcia i doniosłości twórcy jako owego kreatora. Ponieważ od programów w mniejszym stopniu oczekujemy cechy twórczości, w mniejszym stopniu zwracamy uwagę na indywidualnych autorów. Jakość (lub jej brak) gwarantuje nam dana firma czy wręcz znak towarowy.

Jeśli chcemy odpowiedzieć na pytanie, kto tworzy Windows, szukamy dalej. Kolejna odpowiedź – pracownicy. Tym razem prawidłowa, pozostaje fundamentalne w IT pytanie – którzy? Analitycy, spece od algorytmiki, programiści sensu stricte, osoby testujące? Zgodnie z prawem każdy, kto ma „twórczy” wkład. Sprawa będzie jeszcze bardziej skomplikowana np. przy systemach ERP, gdy uwzględnimy rolę klientów, niejednokrotnie bardzo szczegółowo określających założenia i algorytmy rozwiązań.

W odróżnieniu od tradycyjnych utworów, programy są praktycznie bez wyjątku utworami zbiorowymi. Krąg osób tworzących (i uprawnionych co najmniej z autorskich praw osobistych) jest bardzo szeroki – nie do obrony jest stanowisko, że twórcą jest wyłącznie osoba kodująca program. Co więcej, możemy sobie wyobrazić, że taka osoba dostaje na tyle sprecyzowane założenia, że samo kodowanie ma bardziej techniczny niż twórczy charakter. W bardziej skomplikowanych przedsięwzięciach można zwariować opisując wszystkich potencjalnie uprawnionych.

Czy taka sytuacja czymś grozi? Oczywiście tak. Jeżeli twórcami będą tylko nasi pracownicy (a więc wykluczymy udział klientów i zleceniobiorców), problem jest mniejszej wagi i dotyczy tylko praw osobistych, w przypadku programów nader mizernych (autorstwo utworu oraz prawo oznaczenia utworu swoim nazwiskiem, pseudonimem lub anonimowo). Jeżeli w proces twórczy „zapląta” się osoba trzecia (klient, zleceniobiorca), ma ona także prawa majątkowe. Do chwili gdy praw takich nie kupimy (a często nie wiedząc, że np. analityk może być twórcą, nie przewidujemy takiej umowy), osoba trzecia jest współuprawnionym i jakiekolwiek dysponowanie programem wymaga jej zgody lub procesu w sądzie.

Pobieżny audyt tworzonego oprogramowania wskazuje, że w wielu przypadkach producenci zbyt wąsko patrzą na katalog twórców i podpisują umowy tylko z programistami lub osobami projektującymi dane rozwiązanie. Poza tym kręgiem pozostaje sporo osób, które wnoszą swój twórczy wkład i mogą podnieść roszczenia. O tyle nieprzyjemne, że – jeżeli uzasadni się „bycie twórcą” - stosunkowo łatwe do dochodzenia i grożące nawet nakazem wstrzymania dystrybucji i zapłaty odszkodowań. Co więcej, współtwórca może pozwać też użytkownika programu.

Jaka z tego nauka? Lepiej zabezpieczyć za dużo, niż za mało. Poszukujmy i podejrzewajmy istnienie twórcy wszędzie, na każdym etapie tworzenia programu. Identyfikujemy i nabywajmy od niego prawa majątkowe. Jednym słowem - czujność.

I na koniec jeszcze mała uwaga. Nie da się umówić z góry, kto jest twórcą. O tym decydują fakty. Umowy typu „ja dam pieniądze, ty napiszesz, a prawa mamy po połowie” są nic nie warte, prawa w całości ma ten, kto napisze. Możemy tylko od niego odkupić udział w tych prawach. A to zupełnie inna umowa …

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…