Zmiana adresu

Dzięki uprzejmości redakcji Computerworld, uruchomiliśmy znacznie bardziej wzbogacony blog na stronach http://itlaw.computerworld.pl. Zapraszamy i czekamy na komentarze ...

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…

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

mp3 z sieci - część druga

Z poprzedniego odcinka wiemy, że wolno nam (chyba nam wolno - patrz wątek filozoficzny) ściągnąć mp3 czy filmy, nie wolno nam rozpowszechniać. W przypadku programów komputerowych nie wolno ani tego, ani tego.

Zanim odpowiemy co nam grozi jak złamiemy prawo, podkreślmy raz jeszcze: w przypadku mp3 muszą nam udowodnić, że rozpowszechnialiśmy pliki. Da się to zrobić, poprzez namierzenie naszego adresu ip (internetowe oznaczenie komputera) i śledzenie ruchu (czyli co wysyłamy), ale jest to czynność męcząca, poza tym namierzający musi mieć prawo żądania od providera (dostawcy internetu) informacji kto się kryje za danym ip (inaczej namierzający będzie wiedział że ktoś wysyła mamma mia ABBY z adresu xxx.xxx.xx.xx ale nie będzie wiedział kto jest "właścicielem" tego adresu). Takie prawo żądania ma - w skrócie - tylko policja. Praw tych nie ma autor ani producent - osoby takie musiałyby iść do sądu z prośbą, aby sąd zadał to pytanie providerowi. Co się da zrobić. Tak czy inaczej procedura kłopotliwa i będzie miała raczej medialny wydźwięk niż masowy charakter (zważywszy na ilość osób korzystających z peer-to-peer).

W przypadku programów komputerowych sytuacja jest prostsza - jak się znajdzie nielegalny program, mamy kłopoty. Nie ma dozwolonego użytku, tak więc nie można mieć kopii (poza kopią bezpieczeństwa, jak mamy też oryginał). Kontrola w domu jest zawsze groźna w przypadku trzymania nielegalnego softu, w przypadku mp3, oprócz kontroli, muszą mieć namierzony ruch z naszego komputera.

Dla dalszych rozważań warto zdać sobie sprawę, że w przypadku naruszenia praw autorskich mamy do czynienia z dwoma niezależnymi ścieżkami - prawem karnym (policja, prokuratura) oraz prawem cywilnym (producent, autor). W zakresie tego pierwszego będą nas karać (trudne słowo: penalizować :) za złamanie przepisów karnych, grozi nam więzienie, ograniczenie wolności (np. zakaz opuszczania kraju) lub grzywna. To drugie zajmie się roszczeniem odszkodowawczym, czyli autor może żądać od nas pieniędzy za naruszenie jego praw.

Kto może kontrolować? Policja. Tylko i wyłącznie (pomijam ABW czy CBA, bo oni raczej piratami się nie będą zajmować). Praw do tego nie ma ani producent, ani żaden "kontroler". Jak ktoś taki się zmaterializuje, znaczy się oszust - dzwonić na policję. Teoretycznie może do nas przyjść przedstawiciel autora i producenta i poprosić o prawo kontroli - ale nie mamy obowiązku go wpuścić. Policja powinna mieć nakaz od prokuratora, ale nie musi, są sytuacje kiedy może wejść "na blachę". Tak więc policję zawsze grzecznie wpuszczamy. Nikogo innego.

Co może policja? Może skontrolować nam komputer, może też go zatrzymać. NIE MOŻE nałożyć nam żadnych kar, mandatów, ani niczego takiego. Jak takie żądanie się pojawia, znaczy oszuści, znów powiadamiamy stosowne organy. Teoretycznie może się zdarzyć (choć formalnie nie powinno), że z policją przyjdzie przedstawiciel producenta (np. z organizacji BSA) i zaproponuje nam ugodę - płacimy x złotych za to, że producent nie będzie nas ścigać. Taka ugoda ma znaczenie w zakresie PRAWA CYWILNEGO, a nie karnego. Jak się zgodzimy nie grozi nam roszczenie odszkodowawcze w sądzie cywilnym, ale nie oznacza to końca kłopotów z prawem karnym.

Jak policja już nam zarekwirowała komputer (może, nie musi) czeka nas wizyta u prokuratora. W zależności od kwalifikacji naszych czynów (można wymyślić kilka zarzutów z różnych artykułów kodeksu karnego i prawa autorskiego) grozi nam grzywna lub do 2 - 5 lat więzienia (vide np. art. 116 i 117 prawa autorskiego). Jeśli nie zarabiamy na rozpowszechnianiu utworów, jest to nasz pierwszy raz, ryzyko więzienia jest niewielkie. Mogą sprawę warunkowo umorzyć, mogą skazać na więzienie z zawieszeniem (okres próby), mogą dać grzywnę. Sama procedura jest jednak wyjątkowo niemiła i szczerze polecam unikanie takich zdarzeń. Co ważne - znacząca część przestępstw związanych z naruszeniem praw autorskich w internecie jest ścigana na wniosek pokrzywdzonego - czyli jak dogadamy się z autorem i zapłacimy mu odszkodowanie, warto wynegocjować, aby wniosku o ściganie nas nie składał.

Sprawa karna nie jest - jak wspomniałem - jedyna. Może czekać nas też proces cywilny. Zdenerwowany autor czy producent może nas pozwać do sądu cywilnego i zażądać odszkodowania. W praktyce najprawdopodobniej zażąda na podstawie art. 79 prawa autorskiego "potrójnej wysokości stosownego wynagrodzenia z chwili jego dochodzenia" czyli mówiąc po ludzku trzy razy tyle, ile normalnie musielibyśmy zapłacić (może też zażądać jeszcze ekstra podwójnego wynagrodzenia na tzw. fundusz promocji twórczości, ale to poboczny wątek). Z odszkodowaniem jest jednak pewien problem. O ile z programami jest łatwo - jak masz nielegalną kopię, liczymy trzy razy wartość licencji i z głowy - trudniej jest określić co jest trzykrotną wartością mp3. Pamiętajmy, że ściąganie jest - przynajmniej tak zakładamy - legalne, nielegalne jest rozpowszechnianie. Producent mógłby więc teoretycznie żądać trzykrotności opłaty licencyjnej za ROZPOWSZECHNIANIE utworu, czyli trzy razy tyle, ile musielibyśmy mu zapłacić, by nam dał zgodę na umieszczenie pliku z internecie. A są to kwoty niebotycznie wyższe od ceny "kupna" mp3 w internecie. W krajach, gdzie ściągać nie wolno (USA) producent żądałby także trzykrotności za ściągnięcie (np. trzy razy cena w itunes) - mógłby takich kwot żądać nawet jakbyśmy mp3 nie rozpowszechniali. Procesów w Polsce na tym poziomie nie znam (chyba ich nie było, śledzę w miarę dokładnie), więc trudno się wypowiedzieć jak będzie wyglądać praktyka.

PODSUMOWANIE:

Bez wątpienia wolno nam, w ramach dozwolonego użytku osobistego, kopiować muzykę czy filmy z legalnie nabytego nośnika na inny nośnik, wolno nam też zrobić z płyty mp3 i mieć na komputerze. Wolno nam pożyczać takie utwory, ale tylko rodzinie i bliskim znajomym (stosunkowi towarzyskiemu :).

Raczej wolno, acz tu już pojawiają się wątpliwości i odmienne opinie - ściągnąć z internetu rozpowszechniony utwór (nigdy program komputerowy).

Nie wolno nam rozpowszechniać utworów (uwaga na peer-to-peer). Nigdy nie wolno kopiować czy pożyczać programów komputerowych.

Do domu może wejść nam tylko policja. Karną sankcję finansową (grzywnę) może wymierzyć tylko sąd - nie ma żadnych mandatów czy cenników za "nielegalne" mp3. Ale jest cywilne odszkodowanie - jak nie zawrzemy ugody z producentem (autorem), wysokość wyznaczy sąd.

(c) Marcin Maruta 2007

mp3 z sieci - próba uporządkowania dyskusji (część pierwsza)

O mp3 i nielegalności (?) ściągania muzyki z sieci, hordach policji i utajnionych agentów kontrolujących nasze mieszkania napisano krocie. I bardzo często w tym szumie medialnym albo wprost nieprawdziwie, albo przemilczając kilka ważnych informacji. Dla dobra ewentualnej dyskusji kilka słów wyjaśnień:

Utwory można kopiować i wymieniać się nimi w gronie rodziny i bliskich znajomych. Można też je nagrywać - jak nadaje w radiu trójka coś ciekawego, możemy włączyć "rec". Jak nadają coś w tv - w grę wchodzi video, dvd czy inny recorder. Oczywiste, prawda? Obecnie nie ma przepisu który INACZEJ traktowałby internet - jeśli coś jest w internecie, możemy teoretycznie z niego korzystać, tak jak z radia czy tv - innymi słowy możemy ściągnąć sobie film czy mp3. Cała ta konstrukcja nazywa się "dozwolonym użytkiem prywatnym (osobistym)" (art. 23 prawa autorskiego)

Gdzie jest więc hak czy też haczyk? Ano, są co najmniej dwa, filozoficzny i bardziej praktyczny. Filozoficzny hak przejawia się wypowiedziami niektórych prawników (oraz prawie wszystkich producentów audio video), iż trzeba zmienić myślenie o dozwolonym użytku osobistym. Instytucja ta, zasłużona i dość wiekowa, kiedyś sprawdzała się wyśmienicie, ale w dobie cyfrowej musimy ją istotnie przeformułować. Kiedy kolega pożyczał od kolegi płytę winylową i nagrywał ją na grundigu na kasetę magnetofonową czy też korzystał z opcji nagrywania na poczciwym video, zarówno zasięg takich działań był ograniczony, jak i nie było wątpliwości, co jest oryginałem, a co kopią. W internecie sytuacja wygląda całkowicie inaczej - działania niszowe i koleżeńskie przerodziły się w masowy ruch, a bit oryginału jest tożsamy z bitem kopii. Stąd apel i tendencja do zmiany przepisów i interpretacji. Co wcześniej lub później nastąpi. Póki co jednak, można upierać się (i upór ten poparty jest wypowiedziami wielu profesorów prawa), że do czasu zmiany przepisów wolno nam ściągać pliki z internetu. Byle były to utwory uprzednio rozpowszechnione ("za zezwoleniem twórcy w jakikolwiek sposób udostępnione publicznie" - warunek ten wyłącza więc z użytku prywatnego nieopublikowane premiery i większość bootlegów);

Inaczej wygląda kwestia udostępnienia utworów. Rozpowszechniać pliki nam wolno, ale jak stanowi przepis - tylko w ramach rodziny i bliskich znajomych ("przez krąg osób pozostających w związku osobistym, w szczególności pokrewieństwa, powinowactwa lub stosunku towarzyskiego"). Innymi słowy: płytę z muzyką możemy dać siostrze lub koledze, nie możemy jej jednak dać do ściągnięcia każdemu przez internet, albowiem ów "każdy" nie pozostaje "w związku osobistym" (teoretycznie OK jest zamknięty serwer wpuszczający tylko znajomych po weryfikacji). Ale nam wolno ściągnąć (nie udostępnić!) od każdego, nawet jak nie pozostaje z nami w "związku osobistym".

Pozostaje hak drugi - techniczny. Korzystając z sieci peer-to-peer (np. emule) ściągając muzykę czy film jednocześnie je rozpowszechniamy - tak zbudowano tę sieć. Napster w dawnych dobrych czasach umożliwiał jedynie ściągnięcie plików, obecne programy "wymuszają" ich udostępnienie. A jak opisano powyżej, o ile pobranie da się usprawiedliwić, to udostępnienie wykraczające poza "związek osobisty" nie. Pozostaje nam więc albo zaniechanie korzystania z takich programów, albo znalezienie usługi, która nie wymusza jednoczesnego rozpowszechniania. Taką usługą są np. słynne rosyjskie serwisy typu allofmp3.ru czy gomusic.ru. Serwisy te są płatne, ale zapłata to ułamek kwot które musielibyśmy płacić w itunes czy podobnych sklepach. Cały dowcip opiera się na pewnej bezczelności - serwisy te opłacają się w rosyjskim ZAIKS-ie (organizacja zbiorowego zarządzania prawami, mniejsza z tym co to oznacza) i ponoć wedle rosyjskiego prawa uprawnia to do wystawienia plików w internecie. A nas - tym razem zgodnie z polskim prawem autorskim - teoretycznie uprawnia do skorzystania z dozwolonego użytku osobistego i pobrania pliku (jak już pisałem ściągać możemy od każdego, nawet "nieznanego").

Podsumowując jednym zdaniem - wolno nam ściągać mp3 z internetu, nie wolno nam rozpowszechniać (udostępniać). Sieci peer-to-peer (jak emule) "wymuszają" rozpowszechnianie więc korzystanie z nich pociąga za sobą istotne ryzyka.

UWAGA - powyższe - nie odnosi się do programów komputerowych. Programy nie mają dozwolonego użytku prywatnego. Programów nie wolno ani rozpowszechniać, ani ściągać, ani nawet pożyczać legalnej kopii (!). Jeśli macie nielegalne programy, nie obronicie się.

W następnym odcinku kto może nam zrobić krzywdę. Czyli opowieść o tym, kto i kiedy ma prawo skontrolować nasz komputer. Uprzedzając wypowiedź nie istnieje coś takiego jak "cennik" za mp3. O ewentualnym obowiązku zapłaty może zdecydować jedynie sąd (wedle uznania i przepisów, a nie "cennika"). Nigdy policja, BSA czy inne twory.

(c) Marcin Maruta 2007