Modele korzystania z rozwiza IT i zagadnienia prawne

Modele korzystania z rozwiązań IT i zagadnienia prawne z nimi związane Magdalena Gąsowska, radca prawny EDU IT TRENDS Warszawa, 30 maja 2019 r.

Plan wystąpienia I. Wdrożenie dedykowanego rozwiązania IT II. Korzystanie z oprogramowania jako Saa. S III. Zakup oprogramowania standardowego COTS 2

I. Wdrożenie dedykowanego rozwiązania IT 3

Cykl życia projektu IT Analiza • Analiza wymagań • Modele konceptualne opisujące wymagania odnośnie danych funkcjonalności aplikacji Projektowanie Umowa na analizę przedwdrożeniową • Transformacja modeli pojęciowych do implementacyjnych • Modele implementacyjne bazy danych i aplikacji Implementacja • Implementacja bazy danych i aplikacji Wdrożenie Model kaskadowy (waterfall) • Umowa wdrożeniowa poprzedzone testowaniem Umowa serwisowa Utrzymanie Umowa na rozwój 4

Umowy IT (1) § § § § Umowa na analizę przedwdrożeniową Umowa wdrożeniowa Umowa hostingu Umowa utrzymaniowa Umowa serwisowa Umowa na rozwój systemu IT Umowa Saa. S … 5

Umowy IT (2) Charakter prawny umów IT: § Umowy nienazwane § Znaczenie zakwalifikowania elementów umów IT jako: • Umowa o dzieło • Umowa o świadczenie usług • Umowa o przeniesienie praw autorskich majątkowych • … § Konsekwencje dla uprawnień stron w kontekście: • Rozwiązania umowy • Uprawnień zamawiającego i dostawcy • Zobowiązań w zakresie współpracy • zapewnienia rezultatu albo starannego działania 6

Wdrożenie - dzieło czy usługa? (1) Wdrożenia - umowa zlecenia czy dzieło w orzeczeniach sądów § umowa o dzieło (np. wyrok SO w Szczecinie, VIII Ga 20/15) • przedmiotem umowy było wdrożenie systemu informatycznego przeprowadzenie szkoleń pracowników obsługujących system oraz • według SO umowa była umową o dzieło z elementami umowy o świadczenie usług § umowa „zbliżona do umowy o dzieło” (np. wyrok SA w Łodzi, I Aca 745/12) • umowa zawarta na wdrożenie systemu informatycznego jest umową określonego skutku, a zatem jeśli nie wprost, to zbliżoną do umowy o dzieło, nie zaś umową zlecenia, czyli starannego działania. • kryterium odróżnienia umowy o dzieło od umowy o świadczenie usług stanowi możliwość poddania umówionego rezultatu (dzieła) sprawdzianowi na istnienie wad fizycznych. 7

Wdrożenie – dzieło czy usługa? (2) Wdrożenia - umowa zlecenia czy dzieło w orzeczeniach sądów § umowa mieszana (np. wyrok SA w Gdańsku, I Aca 1054/14) • umowa mieszana łączącą elementy umowy sublicencji, umowy o dzieło, umowy o świadczenie usług, bez przewagi żadnego z nich § umowa o świadczenie usług (np. wyrok SO w Łodzi, XIII Ga 442/16) • umowę wdrożeniową można skonstruować w modelu umowy o dzieło i w modelu umowy o świadczenie usług • różnica sprowadza się do tego, że o ile w pierwszym z nich gotowy system jest rezultatem, to w drugim modelu wykonawca ma z należytą starannością wspierać proces wdrażania systemu przez zamawiającego, nie odpowiadając za sam rezultat 8

Uzasadnienie wyroku SO w Łodzi, XIII Ga 442/16 § § § W praktyce, umowę wdrożeniową można skonstruować zarówno w modelu umowy o dzieło, jak w modelu umowy o świadczenie usług. Różnica między tymi modelami sprowadza się w uproszczeniu do tego, że o ile • w pierwszym z nich gotowy system jest rezultatem, za którego osiągnięcie odpowiada wykonawca, • to w drugim modelu wykonawca ma z należytą starannością wspierać proces wdrażania systemu przez zamawiającego, nie odpowiadając za sam rezultat. Uzasadnione wątpliwości, co do poprawności kwalifikacji takiej umowy jako umowa o dzieło mogą wynikać z tego, że według tradycyjnego poglądu, rezultat umowy o dzieło powinien być ściśle określony, na co zresztą wskazał Sąd Rejonowy w uzasadnieniu zaskarżonego wyroku. Tymczasem praktycznie każde wdrożenie systemu informatycznego obejmuje daleko idącą konkretyzację przedmiotu umowy dopiero podczas jej realizacji; w wyniku analizy przedwdrożeniowej, opracowania projektu technicznego itp. (tak Bohdan Widła „Wdrożenia systemów informatycznych w orzecznictwie Sądu Najwyższego”). Rezultat umowy wdrożeniowej nie jest całkowicie zdeterminowany w chwili jej zawarcia. Nadto w rozpoznawanej sprawie przedmiotem umowy było wdrożenie programu pilotażowego, co w ocenie Sądu Okręgowego, przesądza o zakwalifikowaniu przedmiotowej umowy jako umowy o świadczenie usług. 9

Ustawowa rękojmia Podstawa prawna: § prawo autorskie? art. 55 pr. aut § prawo cywilne? art. 638 k. c. w zw. z art. 556 i n. Prawo autorskie Kodeks cywilny dla przyjęcia odpowiedzialności konieczne jest wykazanie winy wystarczy samo stwierdzenie wady wygaśnięcia roszczeń z tytułu rękojmi za wady ‐ „przyjęcie utworu” (art. 55 ust. 3 pr. aut. ) 2 lata od dnia wydania rzeczy (art. 568 par 1) 10

Kody źródłowe i techniczna możliwość samodzielnego rozwoju oprogramowania Konieczność zapewnienia wydania kodów źródłowych: • • • Często opis, jak te kody mają wyglądać Kiedy ma nastąpić wydanie kodów Umowa depozytu kodów źródłowych Z żadnego z przepisów ustawy z 4. 2. 1994 r. o prawie autorskim i prawach pokrewnych (t. j. Dz. U. z 2006 r. Nr 90, poz. 631 ze zm. ) nie wynika, aby wykonanie umowy dotyczącej przeniesienia praw autorskich do programu komputerowego przez jego twórcę obejmowało także obowiązek wydania kodów źródłowych nabywcy takich praw, jak również by ich zbycie z mocy prawa uprawniało nabywcę do wykonywania modyfikacji zakupionego programu. Wyrok SA w Warszawie z 18 września 2014 r. , I ACA 315/14 11

Możliwość samodzielnego rozwoju oprogramowania Prawna podstawa do modyfikowania oprogramowania - Odpowiednia licencja lub odpowiedni zakres przeniesienia Techniczna możliwość modyfikacji: Posiadanie kodów źródłowych + Odpowiednia dokumentacja i transfer wiedzy Faktyczna możliwość rozwoju oprogramowani a przez Zamawiającego Brak zapewnienia sobie ww. uprawnień – ryzyko vendor lock-in 12

Vendor lock- in – problem uzależnienia od wykonawcy (1) Na czym polega „vendor lock-in”? Z czego może wynikać zjawisko vendor lock-in w przypadku dostawców systemów IT? • brak odpowiedniej wiedzy zamawiającego, aby właściwie • • • przygotować umowę na rozwój lub serwis eksploatowanego systemu, brak odpowiednich praw do eksploatowanego systemu (zbyt wąskie uprawnienia licencyjne lub nabyte prawa), brak kodów źródłowych do oprogramowania składającego się na eksploatowany system, ryzyko utraty zobowiązań gwarancyjnych w przypadku powierzenia modyfikacji systemu podmiotowi trzeciemu 13

Vendor lock- in – problem uzależnienia od wykonawcy (2) Jak zabezpieczyć się przed zjawiskiem vendor lock-in? Wraz z zapewnieniem zamawiającemu prawnej i faktycznej możliwości ingerencji w system informatyczny (integracja, modyfikacja, rozwój systemu) zamawiający powinien wymagać w ramach zawartych z wykonawcami umów: • wydania kompletu niezbędnych kodów źródłowych, • wydania kompletnej dokumentacji systemu oraz niezbędnych informacji dotyczących systemu (transfer wiedzy), • podjęcia niezbędnej współpracy z Zamawiającym lub wskazanym przez zamawiającego podmiotem trzecim (niezbędna kooperacja). 14

Wydanie kodów źródłowych dla możliwości samodzielnego rozwoju oprogramowania • • Techniczne znaczenie kodów źródłowych; Opis, jak wydane kody mają wyglądać; Kiedy ma nastąpić wydanie kodów; Umowa depozytu kodów źródłowych; Wykonawca nie ma obowiązku wydania kodów źródłowych, jeśli ta kwestia nie zostanie przewidziana umownie! Z żadnego z przepisów ustawy z 4. 2. 1994 r. o prawie autorskim i prawach pokrewnych (t. j. Dz. U. z 2006 r. Nr 90, poz. 631 ze zm. ) nie wynika, aby wykonanie umowy dotyczącej przeniesienia praw autorskich do programu komputerowego przez jego twórcę obejmowało także obowiązek wydania kodów źródłowych nabywcy takich praw, jak również by ich zbycie z mocy prawa uprawniało nabywcę do wykonywania modyfikacji zakupionego programu. Wyrok SA w Warszawie z 18 września 2014 r. , I ACA 315/14 15

Depozyt kodów źródłowych § Umowa o depozyt kodów źródłowych w praktyce: Ø Ø Deponent; Postać wydawanego kodu; Obowiązek aktualizacji kodów; Możliwość podjęcia kodów; 16

Przykładowe postanowienia § § § Kod źródłowy zostanie dostarczony Zamawiającemu na informatycznym nośniku danych lub zostanie wgrany na infrastrukturę informatyczną wskazaną przez Zamawiającego, w formie umożliwiającej Zamawiającemu jego swobodny odczyt, a także zapisanie kodu na innym nośniku i doprowadzenie tego Kodu Źródłowego do formy wykonywalnej (w szczególności w drodze kompilacji) na odpowiednio wyposażonym stanowisku komputerowym. Dostarczany Kod źródłowy powinien umożliwić Zamawiającemu zrozumienie działania Oprogramowania, którego ten Kod dotyczy oraz wykorzystanie go na potrzeby swobodnej modyfikacji i rozwoju Oprogramowania, dlatego też powinien zostać dostarczony wraz z wyczerpującą dokumentacją Kodu źródłowego, która będzie opisywać mechanizmy customizacji, sposób oraz zakres ich wprowadzenia, a także sposób wbudowania w rozwiązania konfigurowalne odpowiednich mechanizmów. W przypadku dokonywania jakichkolwiek modyfikacji Oprogramowania w toku wykonywania Umowy, Wykonawca będzie przekazywał Zamawiającemu, bez potrzeby uprzedniego wezwania, aktualizacje i poprawki Kodu źródłowego dokonane w danym kwartale, w terminie do 7 dnia pierwszego miesiąca następnego kwartału, a także na każdorazowe wezwanie Zamawiającego. 17

II. Korzystanie z oprogramowania jako Saa. S 18

Chmura obliczeniowa a outsourcing IT § Cloud Computing – brak definicji legalnej, jedyna definicja w polskim soft law (Rekomendacja D KNF w sprawie ze stycznia 2013 r. ): § Cloud Computing („przetwarzanie w chmurze”) ‐ model świadczenia usług zapewniający : § niezależny od lokalizacji, § dogodny dostęp sieciowy „na żądanie” do współdzielonej puli konfigurowalnych zasobów obliczeniowych (np. serwerów, pamięci masowych, aplikacji lub usług), § które mogą być dynamicznie dostarczane lub zwalniane przy minimalnych nakładach pracy zarządczej i minimalnym udziale dostawcy usług. 19

Iaa. S, Paas i Saas – różnice w kontroli zasobów § w modelu Iaa. S - infrastruktura jako usługa - niemal cała zasadnicza część infrastruktury informatycznej (serwerownia, magazyny danych) jest wynajmowana na zewnątrz, pod kontrolą użytkownika pozostają nadal jego dane i oprogramowanie § w modelu Paa. S ‐ platforma jako usługa - zwiększa się rola dostawcy chmury – wyposaża on usługobiorcę w środowisko operacyjne (wykonywalne), w którym użytkownik będzie operować na zainstalowanych przez siebie aplikacjach § w modelu Saa. S ‐ platforma jako usługa - pod kontrolą użytkownika znajdują się jedynie dane, całość infrastruktury wraz z oprogramowaniem znajduje się pod kontrolą usługodawcy, on też odpowiada za ich jakość i niezawodność działania 20

Chmura obliczeniowa - ramy prawne § brak odrębnych przepisów dotyczących chmury obliczeniowej § zastosowanie znajdują przede wszystkim: § przepisy o ochronie danych osobowych § przepisy dotyczące praw własności intelektualnej (prawo autorskie, ustawa o ochronie baz danych) § przepisy prawa cywilnego (umowa o świadczenie usług chmury obliczeniowej) 21

Chmura obliczeniowa – soft law § ochrona danych osobowych § § Kiedyś …. Dekalog Chmuroluba wydany przez GIODO w dniu 15 marca 2013 r. („Dziesięć zasad stosowania usług chmurowych przez administrację publiczną”) ISO/IEC 27018 – ochrona danych osobowych w chmurze publicznej § ochrona informacji – regulacje sektorowe, np. : § § § Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach ze stycznia 2013 r. Wytyczne KNF z dnia 16 grudnia 2014 r. dotyczące zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w ZU Komunikat Urzędu Komisji Nadzoru Finansowego dotyczący korzystania przez podmioty nadzorowane z usług przetwarzania danych w chmurze obliczeniowej z 23 października 2017 r. § treść umowy pomiędzy użytkownikiem i dostawcą: § Cloud Service Level Agreement – Standarisation Guidelines (z 24 czerwca 2014 r. ) 22

Chmura obliczeniowa – soft law § Administracja publiczna ‐ Opinia w przedmiocie dopuszczalności używania w jednostkach administracji publicznej rozwiązania chmurowego w modelu Saa. S wspierającego komunikację wewnętrzną i zarządzanie dokumentami w zakresie prac wewnętrznych i projektów ministerstwa z dnia 4 lipca 2017 r. https: //www. gov. pl/cyfryzacja/chmura‐publiczna‐w‐administracji ‐ Projekt Rekomendacji Ministra Cyfryzacji dotyczących warunków technicznych i organizacyjnych powierzenia danych administracji publicznej do przetwarzania w publicznej chmurze obliczeniowej opublikowany 19 lipca 2018 r. ‐ https: //www. gov. pl/cyfryzacja/konsultacje‐projektu‐rekomendacji‐ ministra‐cyfryzacji‐dotyczacych‐warunkow‐technicznych‐i‐ organizacyjnych‐powierzenia‐danych‐administracji‐publicznej‐do‐ przetwarzania‐w‐publicznej‐chmurze‐obliczeniowej ‐ Dalsze działania i plany Ministerstwa Cyfryzacji 23

Certyfikacja dostawców chmury obliczeniowej przez osoby trzecie § niezależna weryfikacja i certyfikacja przez (renomowane) osoby trzecie może być dla dostawców usług sposobem wykazania, że przestrzegają obowiązków zabezpieczenia danych przewidzianych w przepisach o ochronie danych § dostawcy usług mogliby wykazywać, że mogą zapewnić: § kopie certyfikatu potwierdzającego kontrolę dokonaną przez osobę trzecią § kopię sprawozdania z kontroli weryfikującej certyfikację + audyt § powszechnie uznane standardy bezpieczeństwa: § normy Międzynarodowej Organizacji Normalizacyjnej (np. normy ISO/IEC 27000) § standard Amerykańskiego Instytutu Audytorów ISAE 3402 § certyfikacja jest również przewidziana w RODO i uodo 24

Saa. S a licencja Art. 74 ustawy o prawie autorskim i prawach pokrewnych : trwałe lub czasowe zwielokrotnienie tłumaczenie, przystosowywanie, zmiany układu lub jakiekolwiek inne zmiany § Użytkownik Saa. S nie utrwala programu § Saa. S nie jest korzystaniem z oprogramowania on‐ premise § zastrzeżenie: plug‐ins § kontrowersja? 25

III. Zakup oprogramowania standardowego COTS 26

Dyspozycja majątkowymi prawami autorskimi Przeniesienia całości praw Przeniesienie udziału w prawie Dyspozycja majątkowymi prawami autorskimi Licencja wyłączna Licencja niewyłączna 27

Przeniesienie praw a licencja (1) Przeniesienie prawa: Licencja: Art. 65 pr. aut. „W braku wyraźnego postanowienia o przeniesieniu praw, uważa się, że twórca udzielił licencji” 28

Przeniesienie praw a licencja (2) Przeniesienie praw a udzielenie licencji: • Do przeniesienia praw dochodzi tylko w przypadku wyraźnego zastrzeżenia umownego (domniemanie udzielenia licencji – art. 65 pr. aut. ) • Forma umowy: • forma pisemna pod rygorem nieważności w przypadku licencji wyłącznej i przeniesienia praw (art. 53 pr. aut. i art. 67 ust. 5 pr. aut. ) • licencja niewyłączna – dowolna forma 29

Prawo do rozwoju oprogramowania § Modyfikacja - monopol autorski ‐ modyfikacja „nietwórcza” ‐ modyfikacja „twórcza” (= opracowanie) § Konieczność zapewnienia: ‐ prawa do modyfikacji oprogramowania oraz ‐ prawa do wykonywania praw zależnych (licencja lub przeniesienie) § Przyjmowane konstrukcje: ‐ przeniesienie prawa wykonywania zależnego prawa autorskiego + przeniesienie praw autorskich do modyfikacji ‐ udzielenie zezwolenia na wykonywanie zależnego prawa autorskiego + licencja na modyfikowanie oprogramowania 30

Dziękuję za uwagę! Magdalena Gąsowska Radca prawny magdalena. gasowska@traple. pl Zapraszam na bloga http: //traple. pl/blog/ oraz do zapisania się na newslettera TMT Legal Alert