Ministerstwo Spraw Wewnętrznych i Administracji ul. Stefana Batorego 5 02-591 Warszawa W nawiązaniu do opublikowanego dnia 10 lutego 2011 roku zaproszenia do zgłaszania uwag w ramach opracowanego dokumentu Projekt rozporządzenia Rady Ministrów z dnia...2011 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych, z ramienia Fundacji Wolnego i Otwartego Oprogramowania przesyłam przygotowane we współpracy z Radą Ekspertów Fundacji niniejsze stanowisko. Część pierwsza dotyczy uwag prawnych, natomiast część druga technicznych. Uwagi prawne do Projektu Rozporządzenia w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych [dalej: Projekt] 1 Projekt nie jest do końca terminologicznie spójny z delegacją ustawową zawartą w art. 18 ust. 1 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. Nr 64, poz. 565, z późn. zm.) [dalej: Ustawa o informatyzacji] ten brak spójności naraża Projekt na zarzut przekroczenia lub nie wypełnienia zakresu delegacji ustawowej. Projekt w 1 pkt 3 a) zakłada jedynie minimalne skorzystanie z możliwości regulacji materii określonej w Ustawie o informatyzacji (por. art. 18 ust. 1 pkt a) Ustawy o informatyzacji. Niezrozumiałe zarówno od strony terminologicznej jak i zakresu merytorycznego jest rozbicie w 1 Projektu na punkty b) i c), przy jednoczesnym pominięciu kwestii sprawności wymiany informacji w postaci elektronicznej (por. art. 18 ust. 1 pkt b) Ustawy o informatyzacji. W 1 pkt 3 d) Projektu powinna być mowa zgodnie z dość niefortunną siatką terminologiczną rozporządzenia - o aktywach informacji a nie o nie treściach prezentowanych przez podmioty publiczne (por. art. 18 ust. 1 pkt c) Ustawy o informatyzacji. 2 2 należy uzupełnić o definicję: wolne i otwarte oprogramowanie, który powinien zostać zdefiniowany poprzez odniesienie do modeli licencyjnych, które zakładają, iż oprogramowanie raz udostępnione dla wszystkich wraz z kodem źródłowym (a dodatkowo nieodpłatnie) nie może później być licencjonowane na zupełnie innych warunkach. 3 W 3 pkt 2 ust. 1 a) należy doprecyzować pojęcie usług publicznych, iż chodzi o usługi świadczone przez administrację publiczną. Strona 1 z 7
4 W związku z budzącym wątpliwości interpretacyjne zapisem w 4 ust. 1 pkt 1 Projektu tego samego typu sprzętu, oprogramowania proponujemy nadać następujące brzmienie 4 ust. 1 pkt 1: ujednolicenie, rozumiane jako zastosowanie tych samych standardów, polityk, procedur i norm przez różne podmioty realizujące zadania publiczne.w 4 ust. 3, kropka powinna zostać zastąpiona przecinkiem, po którym powinno znaleźć się uzupełnienie:... ani prowadzić do zachwiania wolnej i uczciwej konkurencji na rynku podmiotów świadczących lub mogących świadczyć usługi lub dostawy w tym zakresie, z których korzystają lub mogą korzystać podmioty realizujące zadania publiczne. 5 W 5 ust. 2 pkt 3) zwrot: w jawnym i otwartym procesie uzgodnień z możliwie szerokim gronem interesariuszy jest na tyle niedookreślony, iż może wypaczyć w praktyce generalną zasadę Ustawy o informatyzacji zasadę neutralności technologicznej. 11.2 W 11 ust. 3 należy usunąć zwrot - adekwatnie do potrzeb wynikających z realizowanych zadań oraz aktualnego stanu technologii informatycznych, gdyż może to doprowadzić do braku stosowania jakichkolwiek standardów. należy dodać do pkt 1 - Best Current Practice, czyli publikowane w postaci Best Current Practice (BCP), ewentualnie w postaci publikowanej w postaci Request For Comments (RFC) Należy w pierwszej kolejności promować BCP ponieważ są one zgodne z RFC, ale są bardziej dopracowane. Należy dodać pkt 3. - Organization for the Advancement of Structured Information Standards (OASIS) i publikowane w postaci OASIS Standard OASIS ma podobny charakter jak World Wide Web Consortium, który na liście się znajduje, istnieje kilka standardów OASIS do których projekt się odwołuje należy usunąć...- adekwatnie do potrzeb wynikających z realizowanych zadań oraz aktualnego stanu technologii informatycznych, 12 12 ust. 1 powinien otrzymać brzmienie: Jeżeli dla pisma w formie dokumentu elektronicznego służącego do procedowania danej sprawy nie ustalono wzoru dokumentu elektronicznego lub nie ustalono rekomendacji interoperacyjności, systemy teleinformatyczne używane przez podmioty realizujące zadania publiczne powinny umożliwiać przyjmowanie dokumentów także w postaci elektronicznej w formatach plików, dla których dostępne jest wolne i otwarte lub nieodpłatne oprogramowanie służące do ich odczytania oraz otwarte specyfikacje tego formatu. Celem KRI (jak podano we wstępie) jest między innymi zmniejszenie obciążeń osób fizycznych i podmiotów gospodarczych. Podmioty realizujące zadania publiczne powinny przyjmować więc dokumenty przygotowane za pomocą nieodpłatnych programów jeśli ich format jest zgodny z choć z jednym wymienionym z Załączniku 2. Strona 2 z 7
14 1. Opis sposobów czy też metod na uzyskanie stanu bezpieczeństwa informacji w systemach teleinformatycznych zawarty w 14 ust. 2 pkt 9 zawiera zbyt wiele zwrotów niedookreślonych i nieprecyzyjnych, które sprawiają, iż regulacja ta ma bardziej charakter postulatywny niż konkretny. W szczególności: a) 14 ust. 2 pkt 9 powinien otrzymać brzmienie: zapewnienie, że pracownicy, wykonawcy i użytkownicy reprezentujący stronę trzecią odchodzą z podmiotu, zaprzestają wykonywania zadania lub zmieniają stanowisko w sposób zorganizowany, a w szczególności wydadzą danemu podmiotowi dokumentację opisującą architekturę systemu teleinformatycznego oraz dokumentację (specyfikację) dotyczącą oprogramowania i wykorzystanych standardów w danym systemie teleinformatycznym ; b) cały 14 powinien bazować na założeniu, iż jednym z głównych warunków bezpieczeństwa podmiotu jest posiadanie przez niego dokumentacji i specyfikacji dot. architektury systemu teleinformatycznego, w tym posiadanie kodów źródłowych (wraz z komentarzami) do wykorzystanego oprogramowania. Uwaga systemowa: Projekt odwołuje się do Europejskiej Strategii Interoperacyjności (EIS) dla Europejskich Usług Użyteczności Publicznej oraz Europejskich Ram Interoperacyjności (EIF) dla usług użyteczności publicznej, zaś pomija zupełnie zresztą tak samo jak EIS i EIF inną inicjatywę Komisji Europejskiej, mającej na celu stworzenie jednolitych ram interoperacyjności w sektorze morskim (administracja portowa, armatorzy, spedytorzy, załadowcy i inni). Dla porządku e- Maritime również powinno być brane pod uwagę bądź powinno zostać wyjaśnione, czy inicjatywa ta, z uwagi na rozwój EIS i EIF została zatrzymana. Uwagi pod kątem technicznym do Projektu Rozporządzenia w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych [dalej: Projekt] 3.1 pkt.2 ust. 1 a) zapewnienie obywatelom oraz podmiotom gospodarczym, dostępności usług publicznych, w postaci elektronicznej, przecinek po słowie publicznych powinien zostać usunięty. e) zapewnienie racjonalnego gospodarowania funduszami publicznym, słowo publicznym powinno zostać zastąpione słowem publicznymi. 4.1. pkt 1 3. zgodność, rozumianą jako przydatność produktów, procesów lub usług przeznaczonych do wspólnego użytkowania, pod specyficznymi warunkami zapewniającymi spełnienie istotnych wymagań i przy braku niepożądanych oddziaływań. Bardzo nieprecyzyjne i dopuszczające dowolność interpretacji Strona 3 z 7
7.1. pkt.2 1. umożliwienie publicznej dyskusji nad rekomendacjami interoperacyjności z zachowaniem zasady neutralności technologicznej i otwartości standardów oraz zgodności z normami zatwierdzonymi przez krajową jednostkę normalizacyjną lub normami i standardami rekomendowanymi lub ustalanymi jako obowiązujące przez organy Unii Europejskiej; Słowo lub po słowie normalizacyjną powinno być zastąpione wyrażeniem z uwzględnieniem 10 Stosowana jest terminologia oraz określane są właściwości wymagane dla podmiotów świadczących usługi informatyczne np. w trybie outsourcingu (rodzina ISO 20000). Nie wydają się one w całości odpowiednie dla wszystkich podmiotów realizujących zadania publiczne, ponieważ de facto nie świadczą one usług informatycznych. 10.1. pkt.2 1. incydentem rozumianym jako przywrócenie normalnego działania usługi w możliwie jak najkrótszym czasie, minimalizując zakłócenia w pracy właściciela usługi w taki sposób, aby zapewnić osiągnięcie możliwie najwyższego poziomu dostępności usługi oraz utrzymanie gwarantowanego poziomu usługi; Po słowie usługi powinno się dodać słowo oraz 14 Praktycznie nakłada na każdy podmiot realizujący zadania publiczne obowiązek nieformalnego wdrożenia norm rodziny ISO 27000 (ISO 17799) wyłączając jedynie audyt zewnętrzny oraz wymaganie uzyskania formalnego certyfikatu. Określenie zapewnienie stosowane w punktach tego paragrafie nie zostało zdefiniowane, a więc dopuszcza się zbyt daleką dowolność. 15.1. Retencja danych powinna być prowadzona w taki sposób,aby awaria systemu nie powodowała jej utraty. Strona 4 z 7
Załącznik 1 Należy dodać kolumnę lub kolumny, w której za pomocą typów XML Schema lub/i wyrażeń regularnych zostanie zapisane w postaci formalnej to co znajduje się w kolumnie Typ i zakres danej Formalny zapis nie zostawia wątpliwości i będzie dokładniejszy niż ten prezentowany w załączniku. Przykład 1: Lp. Nazwa obiektu Identyfikator obiektu Długość pola Typ i zakres danej Pełna nazwa rejestru publicznego zawierającego dane referencyjne opisujące obiekt Akt prawny stanowiący podstawę prawną funkcjonowani a rejestru, o którym mowa w kolumnie 6 1 2 3 4 5 6 7 8 1 Osoba fizyczna posiadająca nadany numer PESEL Numer PESEL 11 Pole znakowe, znaki z zakresu {0..9} Powszechny Elektroniczny System Ewidencji Ludności Ustawa z dnia 10 kwietnia 1974 r. o ewidencji ludności i dowodach osobistych (Dz. U. z 2006 r. nr 139, poz. 993, z późn. zm.) Wyrażenie regularne \d{11} Przykład 2: Lp. Nazwa obiektu Identyfikat or obiektu Długość pola Typ i zakres danej Pełna nazwa rejestru publicznego zawierającego dane referencyjne opisujące obiekt Akt prawny stanowiący podstawę prawną funkcjonowani a rejestru, o którym mowa w kolumnie 6 1 2 3 4 5 6 7 8 2 Podmiot Numer REGON 14 Pole znakowe, znaki z zakresu {0..9} Rejestr publiczny właściwy dla rodzaju podmiotu Ustawa właściwa dla rodzaju podmiotu Wyrażenie regularne \d{14} Analogicznie pkt 3. Strona 5 z 7
Załącznik nr 2 Należy usunąć: A.1.2 powód: w załączniku istnieją aż dwa standardy robiące to samo ODF i OOXML, jest to bardzo stary format, nie jest on standardem. A.1.4 powód: w załączniku istnieją aż dwa standardy robiące to samo ODF i OOXML, dodatkowo format jest bardzo stary, doc nie jest standardem A.1.5 powód: w załączniku istnieją aż dwa standardy robiące to samo ODF i OOXML, docx nie jest standardem A.2.2 powód: to nie jest standard można zastąpić standardem PNG A.3.4 powód: to nie jest standard, format jest zamknięty, można zastąpić formatem ZIP i 7Z (ten ostatni ma lepsze parametry) Należy dodać: Format danych lub skrócona nazwa standardu Oryginalna pełna nazwa standardu Opis standardu Organizacja określająca normę lub standard Nazwa normy, standardu lub dokumentu normalizacyjnego albo standaryzacyjnego 2 3 4 5 6.jp2 Joint Photographic Experts Group 2000 Format graficzny JPEG2000 ISO ISO 15444-1:2000.ogg.spx.flac.oga Ogg: Vorbis, Speex, Free Lossless Audio Codec Formaty dźwiękowe z rodziny Ogg IETF Xiph.Org RFC 3533 RFC 3534.ogv Theora Format wideo z rodziny Ogg IETF Xiph.Org RFC 3533 RFC 3534.webm WebM Pliki.webm IETF.rdf.owl Resource Description Framework, RDF Schema, Web Ontology Language Formaty do metadanych W3C.rng Regular Language for XML Next Generation Język schematów XML ISO, OASIS ISO/IEC 19757-2:2003.7z 7Z Pliki.z7 Uwagi do tabeli:.jp2 należy dodać do sekcji A.2 w tabeli.webm brak oficjalnego RFC, prace w toku.rng należy dodać do sekcji B.1 w tabeli.7z należy dodać do sekcji A.3 w tabeli Należy poprawić: punkt A.1.3, przedostatnia kolumna: ISO, ostatnia kolumna: ISO 32000-1:2008 (wyjaśnienie: format PDF jest już standardem ISO) Strona 6 z 7
punkt A.1.6, przedostatnia kolumna: ISO, ostatnia kolumna: ISO 32000-1:2008 (wyjaśnienie: ODF jest również standardem ISO) punkt A.2.3, przedostatnia kolumna: ISO, ostatnia kolumna: ISO 12234-2, ISO 12639 (wyjaśnienie: część formatu TIFF jest ustandaryzowana przez ISO) punkt A.4.2, druga kolumna: dodać.xht (wyjaśnienie:.xht to również rozszerzenie języka XHTML) Błędy edycyjne: w sekcji B pod koniec tabeli: zamiast 3.1 jest 1.2, zamiast 3.2 jest 1.3 itp w sekcji B pod koniec tabeli: w ostatnim pkt brak liczby porządkowej Główna uwaga do załącznika 2 Proponuje się aby znalazł się zapis, że dopuszczalne są nowe wersje danych formatów (i standardów). Wyjaśnienie: standardy i formaty ciągle żyją są poprawiane i uaktualniane pojawiają się ich nowe wersje. Nonsensem by było aby za każdym razem gdy pojawi się nowa wersja standardu lub formatu projekt był nowelizowany. Z wyrazami szacunku /Rafał Brzychcy/ Prezes Zarządu Fundacji Strona 7 z 7