Beacony

Beacony to niewielkie i tanie nadajniki, dzięki którym smartfon wie, w jakiej lokalizacji aktualnie się znajduje. Beacon poprzez bluetooth emituje sygnał, który aktywuje na smartfonie (w zainstalowanej tam aplikacji mobilnej) określone działania. Na marginesie jedynie wyjaśnię, że niekoniecznie beacony muszą być powiązane z smartfonem. Możliwe jest ich połączenie ze zwykłym komputerem. Jednak najlepiej, z uwagi na mobilność, sprawdzają się w tej roli właśnie smartfony.

Technologia beaconów jest bardzo prosta. Nierzadko brakuje jednak pomysłu na ich ciekawe wykorzystanie w praktyce. Niewątpliwie im bardziej skomplikowana funkcjonalność, tym problematyka prawna trudniejsza.

Warto dodać, że polscy dostawcy rozwiązań beaconowych radzą sobie relatywnie dobrze na rynków. Mogliby jednak jeszcze lepiej, gdyby nabywcy technologii potrafili ją dobrze wykorzystać. A z tym już gorzej. Niemniej perspektywy wydają się obiecujące.

Beacony w praktyce

Z kilku testowanych przeze mnie rozwiązań wykorzystujących beacony, pozytywnie oceniam te oferowane przez instytucje użyteczności publicznej. Są one po prostu funkcjonalne (przydatne). Nadto są łatwe w obsłudze.

Zdecydowanie gorzej prezentuje się obecne wykorzystanie beaconów przez podmioty komercyjne. Zachęcałbym te podmioty do zrewidowania swoich koncepcji. Zwłaszcza porzucenia kierunku skupiającego się na profilowaniu konsumentów (ta kwestia bezpośrednio wiąże się z problematyką prawną). Nie tędy droga. Nic z tego nie będzie w dłuższej perspektywie, ani dla klientów, ani też dla sklepu. Lepiej tak to skonstruować, aby poprzestać na zachęcaniu do dokonania zakupu towaru lub usługi.

Polecałbym beacony w szczególności galeriom handlowym i restauracjom. Stosowanie beaconów przez pojedyncze sklepy to jednak zbyt mało i istnieje ryzyko braku efektywności. W beaconach tkwi ogromny potencjał do poprawy obsługi klienta, w tym zachęcenia go do kolejnych zakupów. Dopiero jak już zostanie to dobrze zaimplementowane i sprawdzi się w praktyce, to można rozważyć profilowanie konsumentów.

Prawo a beacony

Kluczowy problem prawny z beaconami dotyczy szeroko rozumianego przesyłania informacji. Jeśli taka informacja nie jest zamawiana przez odbiorcę to jest SPAMem. Rozsyłanie zaś SPAMu jest zakazane. Samo zainstalowanie aplikacji mobilnej na smartfonie może nie być wystarczające do uznania, że została wyrażona zgoda na przesyłanie reklam. Zwłaszcza wobec faktu, że zgodna ta nie może być domniemana, a w takiej sytuacji właśnie dochodzi do domniemania. Projektując zatem komercyjne rozwiązania z beaconami należy oprzeć się na modelu, w którym zgoda na otrzymywanie reklam wyrażana jest wprost.

W przypadku profilowania konsumentów przy pomocy beaconów trzeba zaś uwzględnić prawne aspekty przetwarzania danych osobowych. Nie jest rekomendowane profilowanie. Jak wyżej wskazano, najcześciej psuje to użyteczność całego rozwiązania.

Ciekawym wątkiem prawnym związanym z beaconami jest wykorzystywania ich jako zabezpieczeń. Becony doczepione do przedmiotu mogą chronić ten przedmiot przed kradzieżą, gdyż ruch takiego przedmiotu może aktywować alarm. W takim stanie rzeczy rodzi się wątpliwość, czy odpowiedzialność karna za kradzież powinna być surowsza?

Szczegółowe kwestie prawne związane z beaconami opisałem w artykule pt. „Mikronawigacja przy wykorzystaniu beaconów” w prawniczym czasopiśmie naukowym „Monitor Prawniczy” (nr 10 z 2016 r.).

Filozofia Agile a elastyczna umowa

Kontynuując rozważania dotyczące prawnych aspektów realizacji projektu w ramach filozofii Agile warto rozważyć czy może umowa wdrożeniowa nie powinna być tak samo elastyczna jak „zwinna” jest przedmiotowa metodologia? Jak zatem powinna wyglądać umowa Agile? Oczywiście elastyczność nie oznacza bałaganu – wręcz przeciwnie. Jasne jest, że metodologia Agile zakłada zorganizowany sposób realizacji projektu. Niemniej w większym stopniu chodzi o samoorganizację, aniżeli o tworzenie formalnej hierarchii. Choć ona również może mieć, i najczęściej ma, miejsce.

Jak zatem wyglądać miałaby elastyczna umowa Agile?

Przede wszystkim przy elastycznej umowie z góry zakładane byłyby częste zmiany jej poszczególnych zapisów. Kluczową rolą prawa, w tym kontraktów, jest zapewnienie stabilności i przewidywalności. Tych wartości nie da się uwzględnić jeśli już na wstępie jest oczywiste, że umowa będzie modyfikowana. Na marginesie można zauważyć, że jest to pierwszoplanowa wskazówka co do treści umowy Agile. Właśnie jedynie to co absolutnie pewne powinno trafić do treści kontraktu.

Dlaczego elastyczne umowa jest niezbyt dobrym rozwiązaniem?

Problem mógłby zaistnieć już co do określenia technicznego sposobu zmiany elastycznej umowy, tak aby zapewniona została jej przejrzystość. Jeżeli zmiana umowy miałaby polegać na zawieraniu aneksów, to bardzo szybko narodziłby się problem braku klarowności. Być może również umowa stałaby się również niespójna. Już z tego względu, czyli z punktu widzenia całkowicie wizualnego i niemerytorycznego, częste zmiany umowy wydają się niedopuszczalne i sprzeczne z filozofią Agile jako komplikujące prowadzenie projektu z uwagi na rozrost dokumentacji.

Konieczność zmian w umowie można nawet uznać za najlepsze kryterium określające, że umowa nie została sporządzona we właściwy sposób, czyli z odpowiednią dawka wyobraźni, która jest niezbędna w przypadku metodologii Agile. Inaczej na to patrząc, można byłoby powiedzieć, że częste zmiany oznaczają, że faktycznie mamy do czynienia z tradycyjną umową, a nie umową dostosowaną do charakteru metodologii Agile.

Jeszcze większym problemem, choć jak wskazano, już ten poprzedni jest niebagatelny, byłoby określenie sposobu dojścia do porozumienia pomiędzy stronami umowy w zakresie zmian. To właśnie przy aneksowaniu umów nierzadko objawia się dobitnie nierównowaga stron kontraktu, kiedy strona silniejsza jest w stanie (niby w drodze negocjacji) wymusić na słabszej stronie korzystne dla siebie rozwiązania. Najczęściej wiąże się to z okolicznością, że słabsza strona nie może dotrzymać pierwotnych warunków umowy, przy czym nierzadko z przyczyn od niej niezależnych i niezawinionych. Jednak faktycznie  stają się one wstępem do rozpoczęcia rozmów o zmianach, mogących prowadzić do rezultatów wcześniej przez słabszą stronę nieprzewidywanych.

Zmiany musiałyby mieć charakter obopólnej zgody. Trudno byłoby dopuścić wariant, jako sprzeczny ze swobodą kontraktową, że jedna ze stron zostałaby wyposażona, mocą przepisów pierwotnej umowy, w kompetencję do jednostronnej zmiany treści tej umowy.

Samo pojęcie zmiany umowy może być rozumiane jednak nie tylko jako faktyczne wstawianie w miejsce starych zapisów umownych nowych. Można ją ująć jako stwarzanie możliwości interpretacji poszczególnych przepisów stosownie do potrzeb. W gruncie rzeczy nie zmienia to w przedmiotowej kwestii zbyt wiele. Problemem byłoby przede wszystkim określenie kto byłby uprawniony do dokonywania, wiążącej obie strony, interpretacji umowy. Musiałoby do tego dochodzić, jak się wydaje, w drodze obopólnej zgody albo co do nowej interpretacji, albo poprzez zgodę na wyznaczenia bezstronnego podmiotu, który dokona interpretacji mającej na uwadze dobro projektu. Faktycznie takie rozwiązanie może doprowadzi do jeszcze większego chaosu aniżeli zwykłe zmiany umowy. Poza problemami właściwymi dla zastępowania starych przepisów nowymi, doszłyby kolejne. Nie byłoby bowiem jasne, które z przepisów konkretnie zmienia nowa interpretacja.

Stabilność umowy Agile jako gwarancja powodzenia projektu

Stosowanie metodologii Agile może nierzadko prowadzić do konfliktów lub nieporozumień, w szczególności w projektach o wysokim stopniu innowacyjności i kreatywności. W takiej sytuacji to właśnie umowa powinna być ostoją i punktem odniesienia dla rozwiązywania ewentualnych konfliktów. Rozwiązania prawne, w tym zapisy umowne, z natury są bezstronne. Powoduje to, że rozwiązania wyznaczane bezpośrednio przez prawo są możliwe do zaakceptowania przez wszystkie strony.

E-rozprawa w postępowaniu sądowym

Wczoraj prowadziłem zorganizowaną na Uniwersytecie Wrocławskim konferencję naukową poświęconą „e-rozprawie”, czyli najważniejszemu obecnie, według mnie, zagadnieniu w zakresie informatyzacji sądownictwa. Przedmiotem konferencji pn. „Rozprawa na odległość – wykorzystanie wideokonferencji  w postępowaniu sądowym” były dwie kwestie:

  • zorganizowaniu posiedzenia sądowego na odległość
  • i przeprowadzeniu dowodu na odległość.

W czasie konferencji problematykę e-rozprawy rozpatrywana na gruncie postępowania cywilnego, karnego i arbitrażowego.  Choć e-rozprawa z pozoru faktycznie polega na tym samym w każdym z tych postępowań, to w postępowaniu cywilny i postępowaniu karnym występują całkowicie różne regulacje (pod względem literalnym odmienne, ale traktujące mniej więcej o tym samym).

Konferencja była transmitowana na żywo w Internecie, ale nie to ją wyróżnia, lecz to, że transmisja odbywała się na Facebooku. Każdy mógł ją zobaczyć na facebookowym wydarzeniu dedykowanym konferencji. Konferencja w równym stopniu była adresowana do uczestniczących w niej jako słuchacze w uniwersyteckiej uniwersytecki sali, jak też do oglądających ją na Facebooku.

W mojej ocenie aktualnie nie ma potrzeby stawiania pytania czy wprowadzać e-rozprawy. W znacznym zakresie jest to już przecież zrobione. Rodzi się jednak problem jak e-rozprawa powinna wyglądać, aby przyczynić się do zwiększenia efektywności sądownictwa. Można postawić tezę że ustawodawca powinien znacznie złagodzić i uelastycznić niedawno ustanowione regulacje prawne dotyczące e-rozprawy. Wreszcie powinna być upowszechniona rozprawy opierająca się na wykorzystaniu zwykłych urządzeń, a nie jedynie na profesjonalnym sprzęcie sądowym.

Konferencja można zobaczyć pod linkiem: https://www.facebook.com/events/479137318950385/

Systemy identyfikacji elektronicznej w eIDAS

W dniu 5 maja 2016 prowadziłem w Warszawie zajęcia w ramach warsztatu poświęconego eIDAS, czyli unijnemu rozporządzeniu nr 910/2014. Moja prelekcja dotyczyła identyfikacji elektronicznej, a konkretnie systemów identyfikacji elektronicznej. A jeszcze precyzyjniej notyfikowanych systemów identyfikacji, przy czym nie mówiłem o zasadach, sposobach i warunkach notyfikacji systemów przez państwa członkowskie UE, lecz o skutkach „działania”  notyfikowanego systemu dla obrotu gospodarczego.

Rozporządzenie eIDAS traktuje o dwóch generalnych kwestiach: identyfikacji elektronicznej oraz usług zaufania. Najczęściej uwaga koncentruje się na usługach zaufania – moim zdaniem niesłusznie, ponieważ to identyfikacja elektroniczna jest ważniejsza. Podobnie założenie przyjął również prawodawca unijny skoro w pełnej nazwie rozporządzenia eIDAS, jak też w treści tego aktu, wpierw mowa o identyfikacji, a dopiero potem o usługach zaufania.

Według mnie skupienie się na systemach identyfikacji elektronicznej może zwiastować nowe – lepsze – perspektywy dla korzystania z komunikacji elektronicznej, przede wszystkim w sferze informatyzacji podmiotów publicznych. Upowszechnienie w praktyce systemów identyfikacji elektronicznej jest relatywnie proste, a przez to realne. Inaczej w przypadku usług zaufania – w ich drożeniu muszą uczestniczyć z zasady podmioty komercyjne, co skutkuje odpłatnością takich usług. Odpłatność ta sama w sobie nie jest problemem, jednak stawia je w gorszej sytuacji wobec alternatywy jaka są prowadzone przez podmioty publiczne systemy identyfikacji elektronicznej, które z zasady są bezpłatne.

Slajdy z zajęć zamieściłem w Slideshare:

 

Pytań na zajęciach było sporo. Mocno przekroczyliśmy zaplanowany czas zajęć. Wielokrotnie odsyłałem do treści zamieszczonych na tym blogu (zachęcam do kliknięcia w poniższy tag eIDAS, aby poczytać o rozporządzeniu eIDAS).

Gotowe szablony regulaminów sklepów internetowych

Przedsiębiorca zakładający sklep internetowy musi zamieścić na swojej witrynie regulamin. Powinien on być dobrze skomponowany pod względem prawnym, czyli nie mieć ani za mało, ani za dużo treści. Jeśli będzie zbyt krótki, to prawdodpobnie nie zostaną zawarte w nim wszystkie informacje, których podanie konsumentowi jest wymagane przez prawo. Z kolei jeśli regulamin będzie rozbudowany, to istnieje spore ryzyko, że znajdą się w nim postanowienia sprzeczne z prawem, w szczególności z prawem konsumenckim.

Regulamin sklepu internetowego szczegółowo określa model sprzedaży (o ile nie jest całkowicie zwyczajny) i jak taki stanowi dla konsumenta opis sposobu dokonania zakupu. Jak stworzyć regulamin? Można albo napisać samemu, albo zlecić adwokatowi lub radcy prawnemu. W ostatnich latach często korzysta się z pomocy nieprawniczych podmiotów (tj. być może pracują w nim prawnicy, ale nie są to kancelarie prawne) sprzedających „gotowce”, czyli zestandaryzowany regulamin, który z uwagi na swą ogólność jest adekwatny do działalności wielu podmiotów. Właśnie tych ostatnich dotyczy niniejszy wpis.

Aby posługiwanie się gotowymi szablonami sklepów internetowych było jednoznacznie dobrym rozwiązaniem powinny być one:

  • idealne,
  • i nie naruszać cudzych praw autorskich (regulamin jako taki może być traktowany jako utwór podlegający ochronie prawnoautorskiej).

Główny problem z prawem konsumenckim, które bezpośrednio wpływa na treść regulaminów, wynika z niestałości tego prawa. Nawet gdyby uznać, że regulamin był idealny w danym dniu, to po kilku dniach, a tym bardziej po latach, może już okazać się błędny. Zmianie ulega nie tylko treść przepisów prawa konsumenckie, ale też twórczo rozwija się orzecznictwo.

W praktyce korzystanie z gotowych wzorców nie sposób jednoznacznie ocenić. Jako niewątpliwe zalety należy wskazać:

  1. niski koszt,
  2. szybki czas jego uzyskania,
  3. łatwość w zrozumieniu treści (z uwagi na zestandaryzowanie treści),
  4. zasadę „w grupie raźniej” (podświadomie przyjmuje się, że skoro inne sklepy mają takie same regulaminy, to pewnie są one dobre).

Natomiast do wad posługiwania się standardowymi szablonami regulaminów zaliczyć można:

  1. brak możliwości stworzenia sklepu, który wyróżniałby się na rynku pod względem sposobu świadczenia usługi (ten sam towar można przecież sprzedawać na różne sposoby),
  2. brak elastyczności, czyli niemożność dopasowania regulaminu do swoich potrzeb,
  3. nieuwzględnianie zmieniających się regulacji prawnych,
  4. ryzyko powtarzania błędów innych podmiotów.

Część wad jest eliminowana przez korzystanie z usług wspomnianych powyżej, nieprawniczych, ale wyspecjalizowanych, podmiotów zajmujących się kompleksową obsługą sklepów. Dostarczają one pakiety niezbędnych dokumentów, ale też je aktualizują w ramach abonamentu. Czasami nawet podmioty te nie tylko świadczą pomoc o charakterze formalnym, ale też zajmują się kwestiami logistycznymi i magazynowymi.

Prawdopodobnie najgorszym sposobem zdybycia regulaminu jest jego skopiowanie bezpośrednio ze strony innego sklepu internetowego. Pierwsze niebezpieczeństwo z tym związane, to narażenie się na zarzuty w zakresie naruszenia prawa autorskich do tego regulaminu. Drugi problem, bardzo częsty, to kopiowanie sprzecznych z prawem postanowień regulaminowych. Nawet największe sklepy internetowe mają nieprawidłowe regulaminy, zatem nie eliminuje tego ryzyka kopiowanie od największych.

Dobry regulamin musi charakteryzować się następującymi cechami:

  • zawierać wszystkie informacje wymagane przez prawo, w tym w zakresie obowiązków informacyjnych względem konsumenta,
  • nie zawierać niedozwolonych klauzul.

Jak wcześniej zasygnalizowano prawo jest zmienne i raz stworzony regulamin powinien być stale monitorowany pod względem nowości w prawie. Co istotne, z zasady prawo konsumenckie zostało skontrowane w taki sposób, że w centralnym miejscu stawia konsumenta. W razie sporu pomiędzy przedsiębiorcą i konsumentem, wynikającego z niejasności w regulaminie pierwszorzędne znaczenie będzie miała zatem  ochrona konsumenta, a nie interes przedsiębiorcy.

Czy warto stosować umowy Agile?

W mojej ocenie warto opierać na umowach Agile przy wdrożeniach, zarówno tych dużych, jak i małych. Chyba nawet przy takich mniejszych i średnich jest szersze pole do skorzystania z dobrodziejstw umów Agile, ponieważ jest większa swoboda przy ustalaniu treści kontraktu. Na większe wdrożenia najczęściej ma wpływy szereg czynników zewnętrznych, co znacznie ogranicza zakres swobody kontraktowej pomiędzy stronami.

Krótko mówiąc, w dużych wdrożeniach, zazwyczaj jedna ze stron umowy ma narzucone, przynajmniej częściowo, wymagania lub warunki. W efekcie przy takich wdrożeniach umowa Agile musi posiadać niektóre elementy tradycyjnych umów wdrożeniowych. Inaczej na to patrząc, można również powiedzieć, że przy małych wdrożeniach umowy Agile są niepotrzebne, ponieważ posłużenie się tradycyjną umową jest wystarczające, nawet jeśli projekt prowadzi się w myśl filozofii Agile, gdyż w mniejszych projektach jest więcej możliwości dokonywania częstych zmian w kontrakcie. Może tak być. Ale jeśli można również wtedy posłużyć się lepszym typem umowy, to dlaczego tego nie zrobić od razu?

W tym miejscu drobne wtrącenie odnośnie samego rozumienia Agile. Moje uwagi dotyczą tzw. umowy Agile. Patrzę zatem na Agile przede wszystkim w kontekście prawa. Ale to wciąż chodzi o Agile. Nie chcę w tym wpisie zachęcać do metodologii Agile (choć uważam, że jest najlepsza, w każdym razie ja w pewnym sensie tak mam zorganizowaną swoją pracę zawodową), lecz zwrócić uwagę na konieczność specjalnego potraktowania obsługi prawnej, jeśli już zdecydowano się na taką filozofię wdrożenia. Innymi słowy, może się rodzić wątpliwość czy jest sens angażowania w środków w tworzenia specjalnej umowy Agile, skoro może wystarczyć zwykła umowa wdrożeniowa, pomimo że wdrożenia realizowana jest w myśl metodologii Agile.

Według mnie przede wszystkim trzy argumenty przemawiają za umowami Agile:

  1. Pozwalają zrealizować wdrożenie w sposób w najwyższym stopniu satysfakcjonujący obie strony. Umowa zawsze jest kompromisem, ale przy tradycyjnych umowach stronie silniejszej łatwiej narzucić swoje rozwiązanie, co jest konsekwencją okoliczności, że ta zazwyczaj taka strona przedstawia draft umowy, w którym niezbyt jest co zmieniać. W umowach Agile przygotowanie draftu wyłącznie przez jedną ze stron jest z zasady utrudnione i w pewnym sensie niemożliwe, ponieważ jeśli strony nie są w stanie na wstępie współpracy wypracować w drodze kompromisu kontraktu, to niezbyt dobrze wróżyłoby to prowadzeniu projektu w myśl filozofii Agile.
  2. Zapisy w tradycyjnycm umowach to często pustosłowie, a jak rodzi się konflikt, to okazuje się, że jednak jedna ze stron w sposób wcześniej „niewyobrażalny” wykorzystuje zapisy na swoją korzyść. W umowach Agile wprawdzie również musi być sporo treści, ale trzeba się w nich kierować konkretami. Czasami spotykam się również z sytuacjami, że dla stron umowy jakieś postanowienie wydaje się jasne, tymczasem dla mnie jest to, jak wspomniałem, pustosłowie, gdyż po głębszym zastanowieniu mógłbym je interpretować na wiele sposobów.
  3. Skutkiem ewentualnego niezrealizowania umowy Agile niekoniecznie musi być wieloletni spor sądowy (połączony z położeniem całego projektu), lecz wymiana kontrahenta na lepszego, połączona z wzajemnych, ale realnym. rozliczeniem się dotychczasowych stron.

Osobiście podoba mi się również w filozofii Agile rola prawnika, która nie jest marginalizowana do minimalizacji ryzyk prawnych na wypadek sporów, ale koncentruje się na doradztwie, czasami bardzo aktywnym, co do ułożenia zasad współpracy pomiędzy stronami. Tym samym jest to prewencja.

Z mojego doświadczenia wynika, że najczęściej główni aktorzy projektu (podmiot biznesowy i podmiot developerski) nie rozumieją się wzajemnie i w pewnym sensie uważają, że ich udział jest kluczowy. Takie wzajemne niezrozumienie prowadzi zazwyczaj do powstania tzw. „obszarów niczyich”. Podmiot biznesowy uważa, że jako inicjator i sprzedawca zleca pracę podmiotowi developerskiemu (dosłownie „zleca”, co jest równoznaczne, że sam w tym zakresie niewiele robi i po prostu chciałby gotowy produkt), a z kolei podmiot developerski uważa, że wie lepiej co można, a czego nie i robi jak uważa, samemu „urealniając” potrzeby podmiotu biznesowego. W efekcie zatraca się sens projektu. Mówiąc dobitnie – sens projektu przestaje odgrywać wiodącą rolę, a zaczyna liczyć się jedynie minimalizowanie tych niedoróbek, do których można „doczepić się” z punktu widzenia zapisów umownych.

Czy dobrym pomysłem jest wypełniać umowę Agile obowiązkami w zakresie organizowania regularnych spotkań. Wydaje się, że nie. Pisanie o tych spotkaniach może często tworzyć złudzenie działania w ramach metodologii Agile, pomimo że wdrożenie faktycznie realizowane jest według tradycyjnych metod.

Na zakończenie w kilku słowach chciałem zwrócić uwagę na błędne posługiwanie się pojęciem odpowiedzialności, co dotyczy w szczególności tradycyjnych kontraktów, w mniejszym stopniu umów Agile. Nie-prawnicy posługują się nim jako synanimem słowa „kompetencja” lub „uprawnienie”. Zapisując w umowie, że ktoś jest odpowiedzialny za coś, znaczy dla nich tyle, że to jest jego działka (tym czymś ten ktoś się właśnie zajmuje). Idąc takim tokiem rozumowania, można dodać, że inne osoby nie powinny w ten obszar wkraczać, skoro ten ktoś jest za niego odpowiedzialny. Tak pojmowane pojęcie odpwiedzialności jest w świetle prawa „puste”, ponieważ nie wiąże się z nim sankcji. Dla prawnika powiedzenie, że ktoś jest odpowiedzialny np. za interfejs (ogólnie mówiąc) znaczy tyle, że jak w tym zakresie coś będzie nie tak, to osoba odowiedzialna ponosi konsekwencje niepowodzenia całego projektu, a nie tylko interfejsu.

Znowu o e-sądzie

Napisałem kolejny artykuł o elektronicznym postępowaniu upominawczym  (rozdział „Elektroniczne postępowanie upominawcze”, w książce „Informatyzacja postępowania cywilnego. Teoria i praktyka”, pod redakcją K. Flagi-Gieruszyńskiej, J. Gołaczyńskiego oraz D. Szostka). Ma ogólny tytuł, ponieważ poświęcony jest ocenie e-sądu na tle 6-letniej praktyki jego funkcjonowania. Nie opisywałem poszczególnych zagadnień w tym postępowaniu, ale głównie chciałem spojrzeć na to postępowanie jako całość z perspektywy wspomnianych sześciu lat.

Choć jestem związany z tym postępowaniem (napisałem choćby o nim książkę), to nie jestem bezkrytyczny.

Uważam, że w chwili powstania postępowanie to było fajne. Ale sześć lat to w świecie technologii bardzo długo. Wydaje mi się, że postępowanie to było w zbyt małym stopniu rozwijane przez ten czas. Zasadnicze mankamenty nie były zaś poprawiane. Co jednak szczególnie niepokojące, to kolejne zmiany legislacyjne dotyczące informatyzacji, w tym te wchodzące w życie za kilka miesięcy, nie zostały zbytnio skorelowane z regulacją dotyczącą elektronicznego postępowania upominawczego.

Umowa Agile w projekcie informatycznym

Mój autorski pomysł na umowę Agile zakłada odrzucenie dotychczas stosowanych wzorców umownych przy projektach informatycznych. Tylko wtedy możliwe jest osiągnięcie realnych korzyści z filozofii Agile. Bez nowatorskiej umowy Agile stosowanie metodologii Agile może okazać się pozorne, a tym samym nie stwarzać dobrych warunków dla realizacji projektu informatycznego.

Od razu wyjaśnię, że przedstawione poniżej założenia umowy Agile mają modelowy charakter. Nie udało mi się nigdy zrealizować ich w pełni, ale staram się w tym kierunku podążać. Tak czy inaczej, moja propozycja odrzucenia tradycyjnych standardów umownych wynika przede wszystkim z dwóćh przyczyn:

  1. chce uczestniczyć, jako prawnik, jedynie w projektach, których skutkiem jest dobry produkt i jako takie są udane (to podejście chyba wiąże się z moim drugim zawodem – jako naukowiec mam satysfakcje z tworzenia czegoś nowego),
  2. zamiast uczestniczyć w sporze sądowym o niewykonanie lub nienależyte wykonanie wdrożenia, w tym w zakresie stworzenia innowacyjnego produktu, wolę obsługiwać kolejny projekt (kwestia ograniczeń czasowych – jak się robi jedno, to trzeba zrezygnować z innych rzeczy).

Fundamentalna różnica pomiędzy tradycyjną umową projektową (związaną z Waterfall) a zaprezentowanymi poniżej ramowymi warunkach umowy Agile, tkwi w całkowitej rezygnacji z wiązania skutków prawnych z ostatecznym produktem. Znaczenie mają jedynie czynności (zadania) prowadzące do ostatecznego produktu. W takim stanie rzeczy, można powiedzieć, że umowa Agile obsługuje projekt, a nie spór sądowy po niepowodzeniach projektowych. Jest to umowa na dobre czasy projektu, a nie tylko na zły okres. Taka umowa Agile ma służyć bieżącemu zarządzenia projektem, a tym samym odgrywać wiodącą rolę w jego realizacji. Nie można rzucić jej w kąt w czasie prowadzenia projektu i sięgnąć do niej dopiero jak już wiadomo, że z projektu nic dobrego nie będzie. Umowa Agile powinna być taka, że każdy uczestnik projektu powinien móc jej konkretne postanowienia przepisać wprost do swojego kalendarza. Dlatego umowa Agile nie powinna być przegadana, a w szczególności posługiwać się banalnymi unormowaniami. Z tych też względów postuluję:

  • rezygnację z tzw. słowniczka na wstępie umowy,
  • jak też likwidację jakichkolwiek załączników do umowy.

Występowanie tych elementów, choć w założeniu ma służyć klarowności, to faktycznie utrudnia posługiwanie się umową na potrzeby realizacji projektu, gdyż ulokowanie jednego zagadnienia w wielu miejscach w umowie skutkuje niezrozumiałością kontraktu. Umowa jest wtedy może jasna dla prawników, ale mniej dla wykonawców. Tymczasem zakładam, że umowa ma przede wszystkim służyć organizacji prac w projekcie.

Zawartość umowy Agile

1) Deklaracja ogólnego celu

Wprawdzie, jak wskazałem powyżej, z ostatecznym produktem nie powinny być wiązane z zasady skutki prawne, to jednak warto opisać we wstępie umowy (preambule) cel projektu, czyli wskazać do jakiego dąży się produktu. Raczej należy się posługiwać w tym zakresie potocznym językiem. Nie chodzi o opis od strony informatycznej, lecz ogólne wskazanie jak finalny produkt ma działać, czy inaczej ujmując, jakie potrzeby użytkowników ma zaspokajać.

2) Opis czynności (zadań)

Umowa Agile w proponowanym kształcie powinna składać się głównie z szczegółowego opisu czynności, które w założeniu stron umowy, potencjalnie mogą doprowadzić do stworzenia dobrego produktu. Posługuję się pojęciem opisu czynności, ale nie jest to precyzyjne określenie. Chodzi mi o swoisty zbiór zadań lub szczegółowych celów, a nie opis sposobów dojścia do tego celu (procedur służących wykonaniu zadania). Wreszcie tak ujmowany opis czynności nie musi być chronologiczny, ponieważ gdyby tak było, to mielibyśmy do czynienia z typową kaskadowością, a tym samym zbliżylibyśmy się do modelu Waterfall. Tak rozumiany opis czynności nie musi również pokrywać się z iteracjami (sprintami). Opis czynności może być od nich szerszy lub węższy. Nie jest jednak wykluczone, przynajmniej częściowe, pokrywanie się tych elementów. Zależy to od konkretnego produktu. Niezmiernie ważną kwestią jest racjonalność opisu i adekwatność konkretnych czynności dla projektu.

W mojej ocenie samo ogólne zapisanie w umowie potrzeby odbywania spotkań lub powołanie komitetów sterujących nie jest wystarczająco konkretne. Należy rozsądnie wpisywać takie rzeczy do umowy Agile, gdyż może to służyć stworzeniu iluzji posługiwania się metodologią Agile. Swoistego zamaskowania rzeczywistego działania w ramach Waterfall.

Trzeba ze spotkaniami wiązać z góry konkretne zadania. Nie chodzi o to, żeby umowa stanowiła opis ogólnej filozofii Agile, lecz ma porządkować prace w ramach danego projektu. Umowa Agile ma służyć obsłudze projektu, a zatem musi konkretyzować metodologię Agile. Kształt umowy sam powinien wymusić spotkania i współprace poszczególnych osób. Istnieje realne niebezpieczeństwo, że ogólne zadeklarowanie w umowie spotkań, doprowadzi, w trakcie projektu, do rozmycia ich znaczenia.

Najistotniejszą kwestią jest jednoznaczne powiązania z daną czynnością podmiotu (osoby) mającego ją zrealizować oraz odpowiedzialności za ewentualny brak realizacji w odpowiednim czasie. Kary w tym zakresie nie powinny być szczególnie dotkliwe, ale powinny być egzekwowane. Na pewno jednak kary muszą być instrumentem o charakterze ostatecznym, gdyż dążyć powinno się do polubownego rozwiązywania problemów, w szczególności poprzez współpracę. Ważne jest jednak, aby było jasne kiedy pojawia się widmo kary, aby stymulowało to do wczesnego podjęcie środków zaradczych. W zakresie odpowiedzialności zawsze problemem pozostanie ustalenie kto jest winny. Rozwiązania umowne w tym zakresie powinny wymuszać, aby osoba, która ma zrealizować zadanie robiła wszystko co możliwe, w celu zapobiegnięcia niepowodzeniom. Nie może zatem mieć łatwego wytłumaczenia w postaci „przerzucenia” winy na innego członka zespołu lub podmiotu.

Ktoś może powiedzieć, że w umowie Agile nie powinno być w ogóle kar, lecz dominować powinno nastawienia na współpracę i rozwiązywanie problem. Niby racja. Jednak, w jakimś miejscu kary powinny być określone. Zwracam uwagę, że w prezentowanym modelu umowy Agile, kary nie są wiązane z ostatecznym produktem. Następuje zatem ich przesunięcie na niższy poziom realizacji projektu.

3) Końcowe przepisy techniczne

Ze struktury tradycyjnej umowy wdrożeniowej warto zaadoptować na potrzeby umowy Agile tzw. przepisy końcowe. Zwłaszcza w kwestii czasu obowiązywania umowy i sposobu dokonywania jej zmian. Chodzi zatem o unormowania, które są typowe dla każdej umowy.

Zalety

Pierwszorzędna zaleta tak skonstruowanej umowy jest możliwie pełne urzeczywistnienie filozofii Agile, a tym samym wszelkie pozytywy tej filozofii można wprost przypisać umowie Agile.

Uważam, że stosowanie metodologii Agile, ale bez umowy Agile, w efekcie spowoduje, wcześniej lub później, konieczność powrotu do tradycyjnych metod pracy, w tym sposobu zarządzania projektem informatycznym. Nie bez przyczyny Waterfall określa się mianem „tradycyjnej” metodologii. Jeśli nie dba się o Agile, następuje ciąg do kierowania się przyzwyczajeniami.

Wydaje się, że proponowany model umowy zapewnia wysoki stopień elastyczności. Daje choćby możliwość łatwej zmiany podmiotu (osoby), który sobie nie radzi. Zastąpić może go ktoś lepszy. Tym samym nie jest zagrożone stworzenie finalnego produktu.

Wady

Przedstawiony kształt umowy ma również pewne wady. Jak też wskazano, samo dokonania opisu czynności jest niezmiernie czasochłonne i trudne. Wymaga od prawnika tworzącego umowę Agile nie tylko znajomości prawa, ale też posiadanie „wyobraźni” co do przebiegu projektów informatycznych. Co oczywiste, prawnik przy sporządzaniu umowy musi współpracować z innymi podmiotami zaangażowanymi w projekt. Poza tym rola prawnika nie ogranicza się wtedy do doradzania jak „gasić pożary” w projekcie, lecz konieczne jest stałe monitorowanie realizacji projektu.

Rola dokumentacji w metodologii Agile

Wprawdzie filozofia Agile zakłada odejście od generowania stosów dokumentów, to dotyczy to w szczególności dokumentacji projektowej, w tym włączanej do kontraktów. Nie oznacza to jednak, że nie ma potrzeby stworzenia kontraktu. Musi być. Ale niekoniecznie należy tworzyć go na kształt dokumentacji projektowej. Wydaje mi się, że obsługa prawna w metodologii Agile nie powinna bazować na dokumentacji projektowej w tak wielkim stopniu jak przy Waterfall. Kluczowe powinny być dokumenty przygotowane przez prawnika, a nie zespół projektowy. Koresponduje to ze wskazanym na wstępie postulatem w zakresie pozbawienia umowy jakichkolwiek załączników, lecz zamieszczanie wszystkiego w treści umowy. Precyzyjny język prawny, który z natury jest syntetyczny, świetnie nadaje do zorganizowania prac w ramach projektu.

Krajowe i transgraniczne skutki rozporządzenia eIDAS

Prawne skutki rozporządzenia eIDAS (unijnego rozporządzenia 910/2014) można rozpatrywać w różnych aspektach. Uważam, że kluczowy, choćby dla zrozumienia istoty eIDAS, jest podział na skutki krajowe i transgraniczne. Choć taki podział nie rzuca się od razu w oczy, to w istocie stanowi stanowi sedno całego rozporządzenia eIDAS. Chodzi zarówno o skutki rozporządzenia eIDAS co do identyfikacji elektronicznej, jak też usług zaufania. Na marginesie warto przypomnieć, że rozpoczęcie stosowania rozporządzenia eIDAS przypada na dzień 1.7.2016 r.

Przede wszystkim rozporządzenie eIDAS traktuje o skutkach na płaszczyźnie transgranicznej. To tutaj będą one bezpośrednio odczuwalne. Efektywność regulacji w tym zakresie nie jest uzależniona od państw członkowskich Unii Europejskiej. Odmiennie zaś w przypadku skutków krajowych. Można sobie wyobrazić wariant, w którym dane państwo członkowskie pozbawia faktycznej skuteczności części rozporządzenia w sprawach wewnętrzny. Byłoby to wprawdzie sprzeczne z interesem tego państwa, ale nie jest wykluczone. Oznaczałoby niewykorzystanie szansy w zakresie cyfryzacji, stwarzanej przez przedmiotowe rozporządzenie. Nadto oddałoby krajowy rynek podmiotom zagranicznym, które korzystaąć mogą z transgranicznej skuteczności eIDAS.

Choć nie ma możliwości absolutnego i całkowitego pozbawienia skuteczności prawnej w sprawach o wyłącznie wewnątrzkrajowym charakterze. Niemniej można w tym zakresie zdegradować eIDAS do podobnej roli jaką obecnie odgrywa ustawa o podpisie elektronicznym (implementująca zresztą unijną dyrektywę). Kolokwialnie ujmując – roli dość mizernej. Takie rozwiązanie byłoby jednak nie tylko zniszczeniem potencjału rozporządzenia eIDAS. Doszłoby zapewne do zmarnowania także  środków. Pewne nakłady będą musiały i tak zostać poniesione przez podmioty prywatne i publiczne na zapewnienie transgranicznej skuteczności rozporządzenia eIDAS na terytorium Polski. Na marginesie dodam, że nie chcę w tym miejscu wnikać w ocenę prawną obecnej ustawy o podpisie elektronicznym. Chcę jedynie zwrócić uwagę, że w praktyce narzędzia ustanowione w tej ustawie znajdują niezmiernie rzadkie zastosowanie. Ograniczając się do sytuacji, w których polski ustawodawca narzucił obowiązek posługiwania się nimi. W szczególności dotyczy to używania bezpiecznego podpisu elektronicznego weryfikowanego kwalifikowanym certyfikatem.

Transgraniczne skutki eIDAS sprowadzają się do akceptowalności i dopuszczalności posługiwania się rozwiązaniami technologicznymi opisanymi w rozporządzeniu eIDAS, a pochodzącymi z innych państw członkowskich, we wszystkich innych państwach członkowskich Unii Europejskiej. Skutki krajowe to z kolei przypisanie do rozwiązań technologicznych konkretnych skutków prawnych. Konkretnych, czyli takich, które wskażą jaka jest konkretna moc prawna skorzystania z tych rozwiązań. Czy inaczej przedstawiając – w jaki sposób ta moc prawna będzie szczególna wobec skorzystania ze zwykłej komunikacji elektronicznej, jak choćby wysłania normalnego e-maila. Rozporządzenie eIDAS tylko w niewielkim zakresie określa te skutki (jeden wskazuje w kolejnym akapicie). Co do reszty sprawa jest otwarta dla poszczególnych państw członkowskich.

Oczywiście skutki krajowe i transgraniczne są ze sobą w swoisty sposób powiązane, ponieważ jeśli nie ma tych pierwszych, to poza skutkami wprost statuowanymi w rozporządzeniu (jak w przypadku zrównania kwalifikowanego podpisu elektronicznego z podpisem własnoręczny, o czym w art. 25 ust. 2 rozporządzenia eIDAS), nie mają racji bytu skutki transgraniczne.

W kontekście nieodległego wejścia w życie przedmiotowego rozporządzenia eIDAS i prawdopodobnie niedopełnienia przez Polskę w odpowiednim czasie stosownych czynności, w tym legislacyjnych, wyłania się również kwestia efektów opóźnienia. Jak wspomniano powyżej, na gruncie wyłącznie krajowym, skutkiem będzie przede wszystkim marnotrawstwo potencjału. Z kolei w odniesieniu do transgraniczności, konsekwencje niedochowania terminu nie są w pełni jasne. Wprawdzie można precyzyjnie wskazać sankcje związane z niestosowaniem przez państwo członkowskie prawa unijnego, to jednak wyciąganie konsekwencji w nieodległym czasie nie wydaje się prawdopodobne co najmniej z dwóch względów.

Po pierwsze, nieprzestrzeganie prawa unijnego, a zwłaszcza nieimplementowanie na czas prawa unijnego, jest relatywnie częstym zjawiskiem. Szczerze mówiąc, to nie jestem nawet sobie w stanie na szybko przypomnieć jakiekolwiek unijnego aktu prawnego z mojej działki prawnej, który byłby w Polsce stosowany „od razu”. Czyli tak, aby dostosowanie prawa polskiego nie było opóźnione.

Po drugie wreszcie, co ważniejsze, opóźnienie akurat w przypadku eIDAS dość łatwo racjonalnie uzasadnić. Przedmiot tego aktu prawnego jest na tyle technicznie skomplikowany i wymagający współdziałania wielu podmiotów, w tym prywatnych i publicznych, że nakreślenie odpowiedniej argumentacji służącej usprawiedliwieniu opóźnienia nie byłoby zadaniem trudnym. Ponadto niewykluczone, że również inne państwa członkowskie będą w podobnej sytuacji jak Polska. Wydaje się nawet, że inne kraje wskutek znacznie bardziej zaawansowanej cyfryzacji, paradoksalnie, będą bardziej narażone na zarzuty w przedmiotowym zakresie. Innymi słowy, ogólne opóźnienie technologiczne Polski, w szczególności na gruncie informatyzacji podmiotów publicznych, stanowi mocny argument za opóźnianym akceptowaniem transgranicznych skutków rozporządzenia eIDAS.

Czy zatem rozporządzenia eIDAS zrewolucjonizuje komunikację elektroniczną? Nie jest to wykluczone, ale raczej nie nastąpi to 1.7.2016. Nie jest też pewne czy nastąpi później. Jednak prawdopodobne jest również, że bez efektywnego wykorzystania możliwości stwarzanych przez eIDAS nie uda się w dłuższej perspektywie istotnie zwiększyć stopnia cyfryzacji obrotu gospodarczego.

Dane podlegające ustawie o ochronie danych osobowych

W ostatnim czasie kilkukrotnie byłem pytany przez startup’owców o prawne możliwości posługiwania się danymi osobowymi na użytek prowadzonych przez nich portali internetowych. Najczęściej kwestie te dotyczą albo danych zbieranych przy zakładaniu konta (profilu) na tym portalu, albo prezentowaniu danych osobowych w celach informacyjnych. Oba przypadki są wielowątkowe i nie sposób zwięźle ukazać je w oderwaniu od struktury, funkcjonalności oraz przyczyn powstania konkretnego portalu internetowego.

Przedstawić chciałbym tylko jedną kwestię, która jest kluczowa, gdyż na tym polu często następuje niezrozumienie czym w ogóle jest ochrona danych osobowych. Pomyłki często wynikają z mylenia jej z ochroną dóbr osobistych (imię i nazwisko to również dobro osobiste), gdy tymczasem jest to całkowicie odrębne zagadnienie. Dla ochrony danych osobowych nie ma znaczenia czy narusza się czyjeś dobra osobiste. Działa to też w drugą stronę – działanie w interesie osoby, której dotyczą dane osobowe, np. reklamując ją, nie powoduje, że nie trzeba stosować ustawy o ochronie danych osobowych. Na marginesie jedynie wspomnę, że argument o bezpłatnym reklamowaniu kogoś, chyba kompletnie nigdy nie ma znaczenia prawnego, a tym samym taka linia obrony nie będzie skuteczna.

Wracając jednak do meritum – jednym z głównych problemów jest niewłaściwe pojmowanie danych osobowych. Czasami mogłoby się wydawać, że jak tych danych osobowych jest mało lub są one niezbyt istotne, to nie ma potrzeby stosowania ustawy o ochronie danych osobowych. To błędne podejście. Choć zakres danych ma znaczenie dla oceny proporcjonalności i celowości przetwarzania danych (co wynika z reguły niegromadzenia danych osobowych ponad potrzebę), to w zasadzie nie odgrywa większej roli dla określenia czy stosuje się ustawę czy nie (ze wszystkim tego konsekwencjami, jak choćby obowiązek rejestracji u GIODO, umożliwienia dostępu do danych i bezpieczeństwa).

Dla przedmiotowego zagadnienia miarodajny jest art. 6 ustawy o ochronie danych. Zgodnie z nim za dane osobowe uważa się wszelkie informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. Ustawa nie wymienia zatem konkretnych kategorii danych, lecz określa tak generalnie. Wskutek tego  zmniejszenie stopnia identyfikacji nie powoduje, że takie dane przestają być danymi osobowymi. Ponadto zwrócić należy uwagę, że zgodnie z przywołanym przepisem osobą możliwą do zidentyfikowania jest osoba, której tożsamość można określić bezpośrednio lub pośrednio, w szczególności przez powołanie się na numer identyfikacyjny albo jeden lub kilka specyficznych czynników określających jej cechy fizyczne, fizjologiczne, umysłowe, ekonomiczne, kulturowe lub społeczne. Wreszcie trzeba mieć na uwadze, że specyfika internetu spowodowała powstanie szczególnych informacji identyfikujących, jak choćby numer IP. Co więcej, wiele identyfikujących tego typu danych internetowych nierzadko „narzuca się” samych. Nie trzeba ich zatem ustalać lub pobierać manualnie, ale wyskakują one jako funkcjonalność systemów obsługujących infrastrukturę przestrzeni wirtualnej.

Nie każde przetwarzanie danych osobowych podlega jednak ustawie o ochronie danych osobowych. Przewidzianych jest kilka wyłączeń co do podmiotowego i przedmiotowego zakresu zastosowania ustawy o ochronie danych osobowych, przy czym zazwyczaj raczej nie będą one zachodziły w obecnych realiach przedsięwzięć internetowych. Zwłaszcza, że są to wyjątki i jako takie należy je interpretować ściśle.