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.

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ń.

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