Przyjęli, opublikowali, a więc ogłosili nowe prawo: Szczęśliwego Nowego Roku 2009

Dziennik Ustaw nr 232  i sztuczne ognieW Dzienniku Ustaw nr 232 z 29 grudnia 2008 roku (poz. 1568), opublikowano właśnie rozporządzenie wydane 23 grudnia przez Ministra Spraw Wewnętrznych i Administracji, a dotyczące wymagań technicznych dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, elektronicznej formy dzienników urzędowych oraz środków komunikacji elektronicznej i informatycznych nośników danych. A więc "udało się" jeszcze przed końcem roku i wejściem w życie poprzedniego rozporządzenia... Czy czyn polegający na "odbezpieczaniu" oficjalnych, ale "zabezpieczonych" plików PDF z powszechnie obowiązującym prawem ma dużą społeczną szkodliwość?

Oczywiście można sięgnąć do papierowego Dziennika Ustaw, jeśli ktoś lubi. Na stronie MSWiA jeszcze treści nie można znaleźć. Ostatnio relacjonowałem prace nad tym rozporządzeniem w tekście Ogłaszanie aktów prawnych - Rządowe Centrum Legislacji mówi: tylko PDF. O planowanym wejściu w życie "poprzedniego" rozporządzenia: Wchodzi w życie rozporządzenie dot technicznych wymagań elektronicznego ogłaszania prawa.

Oczywiście na stronie Centrum Obsługi Kancelarii Prezesa Rady Ministrów można sobie obejrzeć spis treści (PDF) tego Dziennika Ustaw. Ale też pobrać go w całości (niestety również tylko jako PDF: Dz. U. Nr 232, poz. 1568 z 2008 r.; można też pobrać tylko jedną pozycję, tj. poz. 1568 - również PDF).

Rozporządzenie weszło w życie z dniem ogłoszenia. Sporo uchylono (m.in. uchylono załączniki 3-5 do "poprzedniego" rozporządzenia, które nie zdążyło wejść w życie), część przeredagowano.

Na wszelki wypadek z opublikowanych na stronie Centrum Obsługi Kancelarii Prezesa Rady Ministrów plików PDF nie można sobie tak po prostu zaznaczyć fragmentu tekstu i go skopiować. A to wymusza posiadanie narzędzi hackerskich i 3 lata potencjalnej odpowiedzialności karnej z art. 269b KK oraz odpowiedzialności karnej z art. 1181 ustawy o prawie autorskim i prawach pokrewnych. To przyczynek do pracy habilitacyjnej pt. Jak publikacja prawa w wykonaniu administracji publicznej wpędza obywateli w recydywę (por. 18 grudnia 2008 - potwierdzenie delegalizacji internetu w Polsce, Prezydent podpisał nowelę Kodeksu karnego. Czy można obejść coś, co nie istnieje?, Tak, tak, nowelizują kodeks karny... wizerunki małoletnich, hacking, 269b...).

Przeczytaj na ten temat również:

Opcje przeglądania komentarzy

Wybierz sposób przeglądania komentarzy oraz kliknij "Zachowaj ustawienia", by aktywować zmiany.

Czy jestem przestępcą?

Po lekturze powyższego tekstu (fragment dotyczący braku możliwości kopiowania) odnoszę wrażenie, że nieświadomie dokonałem przełamania zabezpieczeń przed kopiowaniem...

Jak to wyglądało? Klikając w zamieszczony w tekście odnośnik uzyskałem dostęp do informacji o miejscu przechowywania pliku z rozszerzeniem PDF. Moja przeglądarka WWW zaoferowała kilka opcji, z których wybrałem "Po zakończeniu pobierania: Otwórz za pomocą: Przeglądarka dokumentów". Po krótkiej chwili oczekiwania moim oczom ukazała się treść: "ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI z dnia 23 grudnia 2008 r."
Zaznaczyłem za pomocą myszki fragment tekstu, po czym kliknąłem środkowym klawiszem w okienku służącym do wpisywania komentarza. Tekst pojawił się w miejscu, w którym znajdował się kursor myszki.
Czy jestem posiadaczem oprogramowania służącego do przełamywania zabezpieczeń? Przecież użyłem tylko standardowych, dostępnych dla każdego bezpłatnie programów.

Teraz mam już świadomość, że moja przeglądarka dokumentów posiada cechy narzędzia służącego do przełamywania zabezpieczeń. Ale przecież jej podstawową funkcją jest wyświetlanie dokumentów. Czy w związku z odkrytą przypadkowo dodatkową cechą muszę zrezygnować z możliwości przeglądania dokumentów? A co mają zrobić ludzie, którzy nie wiedzą, że ich przeglądarka dokumentów ma taką cechę? Wreszcie, skąd mam wiedzieć, że dokument jest zabezpieczony, skoro przed jego otwarciem nie mam dostępu do takiej informacji, a po otwarciu - przepadło?

Być może i ja...

Niestety i ja popełniłem ten błąd i skopiowałem cały plik do cache-a przeglądarki, następnie otworzyłem plik używając ogólnie dostępnych narzędzi i bez problemu skopiowałem pierwsze 23 strony tego dokumentu, żeby resztę dokumentu skopiować - musiałbym użyć innego ogólnie dostępnego narzędzia do rozpoznawania tekstu (czego już mi się nie chciało robić). Czy w związku z tym (będąc obywatelem, który powinien przestrzegać prawo) powinienem iść do jednostki policji i zgłosić moją winę, winę programisty danego oprogramowania, winę udostępniającego ten dokument, czy winę autora, który podał bezpośredni odnośnik do tego dokumentu?

Cieszyć się czy martwić?

Bez pisemnej zgody już samo zapoznanie się z dokumentem zahacza o nieuprawniony dostęp do informacji. A fakt, że użyty został program inny niż Adobe Reader (tak podejrzewam, bo też mi evince i xpdf pozwalają na zaznaczanie wcale nie przyznałem się właśnie do popełnienia przestępstwa), a więc specjalistyczne narzędzie (bo większość społeczeństwa używa do otwierania dokumentów pdf Adobe Readera, a jako przeglądarki internetowej Mozilli Firefox lub Google).

Nie pozostaje nam nic tylko się cieszyć/martwić* z tego, że wiemy więcej niż przeciętny Kowalski, czyli odróżniamy dysk twardy od obudowy ATX. :)

*niepotrzebne skreślić

Dokument jest wewnętrznie sprzeczny

Zgodnie z §1 p.1b PDF - format plików PDF (Portable Document Format) generowany w sposób umożliwiający przeszukiwanie tekstu dokumentu i jego wydruk.

Tymczasem nie sposób go przeczytać i wydrukować. Oznacza to, że nie spełnia warunków jakie precyzuje. Ciekawe, czy przez to przestaje być dokumentem oficjalnym, czy tylko powstałym z naruszeniem prawa?

Ale wszak da się go

Ale wszak da się go zarówno przeszukać, jak i wydrukować, kwestia tylko ilości poświęconej temu pracy i wysiłku. W celu wyszukiwania można na przykład przeczytać dokument, aż do natrafienia na szukany fragment. Wydruk możliwy jest na przykład przez przyłożenie monitora komputera do kserokopiarki...

Czy też może "przeszukiwanie tekstu dokumentu" i "wydruk" to osobno zdefiniowane terminy prawnicze i popełniam błąd interpretując je w sposób naiwny?

1. Pragnę uspokoić

1. Pragnę uspokoić wszystkich: "Evince to prosta przeglądarka dokumentów PDF, PostScript, DVI, TIFF przeznaczona dla środowiska graficznego GNOME" (http://pl.wikipedia.org/wiki/Evince)
File->Properties i już wiemy, że "Security" dokumentu posiada wartść "No", zatem dokument nie posiada żadnych zabezpieczeń i nie ma tu mowy o przełamywaniu czegokolwiek.

2. Nie widzę też "bezpiecznego podpisu elektronicznego", który wynika z par. 3 ust. 2 zmodyfikowanego aktu [w Rozporządzeniu par. 1, 2), a)], zatem trudno traktować ten "Dziennik Ustaw" jako dokument elektroniczny zawierający akty normatywne i inne akty prawne, elektroniczną formę dzienników urzędowych...

3. Jeżeli jakiś program pokazuje, że plik:
http://www.cokprm.gov.pl/files/strony/Wydawnictwa/dzienniki/2008/dziennik/DU2322008-72.pdf
posiada jakieś zabezpieczenia to może być to błąd oprogramowania.

4. We właściwościach pliku możemy dowiedzieć się, że:
- Tytuł dokumentu: "Dz.U. Nr (s.001-126)#3064"
- Autorem jest niejaki(a): "l-p",
- Temat: "none",
- Producer: "Acrobat Distiller 8.0.0 (Windows)"
- Twórca (Creator) to "QuarkXPress Passportâ—¢: LaserWriter 8 8.7.3:"
I tu jest chyba pies pogrzebany. Jak wiadomo czcionki z Quarka są dobre w Quarku. Po skopiowaniu tekstu z takiego pdf-a polskie litery zamieniają się w zwykłe krzaki.

Co wtedy trzeba zrobić? Zablokować możliwość kopiowania. A co!
Nie będą się czepiać, że bez polskich liter.

Czy jak dotąd mało było narzekań na pośpieszne choć radosne tworzenie prawa? Chociaż, jeżeli Twórcą (Creator) elektronicznej wersji Dziennika Ustaw jest QuarkXPress, a nie kompetentne osoby, to czego można się spodziewać.

Jednak

Jednak przeszedłem się do sąsiada, który jest posiadaczem komercyjnego, zamkniętego systemu operacyjnego (ok. 800 PLN), żeby zobaczyć jak tam prezentuje się ów elektroniczny "Dziennik Ustaw".

Rzeczywiście, jest kłódka i napis "ten dokument nie może być edytowany, drukowany ani kopiowany" ale ponieważ ten system operacyjny ma zamknięty kod źródłowy myślę, że jest to błąd.

Wyjaśniłem też problem polskich liter. We właściwościach dokumentu (zakładka czcionki) można przeczytać:
Kodowanie: "Własne"
!?!
I to jest chyba nowa, świecka tradycja. Minimalne wymagania dla systemów teleinformatycznych (http://prawo.vagla.pl/node/5750) nareszcie przestały obowiązywać. UTF-8 do lamusa.

Zabrakło vacationis legis

    W pedeefach kodowanie ogoniastej części alfabetu prawie zawsze będzie „własne”, chodzi o to, żeby nie osadzać całego fontu a tylko znaki używane (bo rzadko we współczesnych polskich tekstach zdarzają się litery „ř”, „ß”, „ū”, „ſ” itp., więc szkoda na nie miejsca), czasem też wynika z użycia wariantów liter (np. ligatur). W poprawnie wygenerowanym pedeefie można przeszukiwać tekst o całkiem nawet wymyślnej formie typograficznej (chociaż i ten plik najlepiej wygenerowany nie jest). Tyle tylko, że optymalne przygotowanie pliku do druku różni się od przygotowania pliku jako „produktu końcowego”: oczywiście da się dobrać sposób generowania pedeefa tak, żeby miał zarówno logiczną strukturę jak i był strawny dla rządowych maszyn drukarskich. Nie da się tego jednak zrobić używając quarka tak jak do tej pory — żeby dobrze wyglądało na papierze; najzwyczajniej konieczna jest zmiana organizacji pracy redakcji wydawnictw promulgacyjnych, i w wielu przypadkach prawdopodobnie też używanie innych niż dotychczas narzędzi, a to oznacza dodatkowe koszty.

    Poza tym to, że w pedeefie atrybut „security” wa wartość negatywną, nie znaczy, że korzystanie zeń nie jest ograniczone (są jeszcze „document restrictions”).

    PS.: Wiem, że prawnicy słów łacińskich nie odmieniają, ale jakoś klawiatura mnie swędzi, gdy widzę nie zdeklinowane rzeczowniki…

Tyle tylko, że optymalne

Tyle tylko, że optymalne przygotowanie pliku do druku różni się od przygotowania pliku jako „produktu końcowego”: oczywiście da się dobrać sposób generowania pedeefa tak, żeby miał zarówno logiczną strukturę jak i był strawny dla rządowych maszyn drukarskich.

A kto powiedział, że to ma być ten sam PDF? Zresztą było by to bez sensu, choćby ze względu na "wagę" plików (wprawdzie Dz.U. to głównie tekst).

Nie da się tego jednak zrobić używając quarka tak jak do tej pory — żeby dobrze wyglądało na papierze; najzwyczajniej konieczna jest zmiana organizacji pracy redakcji wydawnictw promulgacyjnych, i w wielu przypadkach prawdopodobnie też używanie innych niż dotychczas narzędzi, a to oznacza dodatkowe koszty.

To zastraszające, ale wychodzi na to, że wydawanie Dz.U. odbywa się jak za króla Ćwieczka. Zgadzam się z przedmówcą: wymagana jest duuuża zmiana. Przede wszystkim narzędzi mentalności (umiejętności) ludzi. A w ogóle dlaczego do składu tego typu wydawnictw używany jest quark, a nie np. FrameMaker, który o niebo lepiej przystosowany do tego typu zadań. Nie mówię o nowszym oprogramowaniu. Szczerze mówiąc, zastanawiam czy OpenOffice by się lepiej nie spisał. Nie było by problemu z XML'em i generowaniem PDFów...

I gdzie są te wszystkie

I gdzie są te wszystkie workflow'y wypluwające treść równocześnie na kilka mediów: poligrafia, internet, drukarka. Takie rozwiązania mają już kupę lat! A tam pewnie manufaktura poligraficzna jak za danych czasów.

Z królem Ćwieczkiem to

Z królem Ćwieczkiem to przesada, nikt przecież nie przekłada kawałków ołowiu z kaszt na szpalty. Siedzą sobie oto państwo w redakcji przed komputerami i doglądają, czy to co wypluł komputer jest zgodne z tym co wypluć powinien — czy zgadzają się literki, cyferki, czy nie zjadło jakiegoś fragmentu. Ich praca to z grubsza rzecz biorąc dbanie, by właściwe znaki znalazły się na właściwym miejscu. Nie sądzę, by przygotowywanie materiałów do publikacji w formie elektronicznej w jakikolwiek sposób wiązało się z koniecznością istotnej zmiany kwalifikacji tych ludzi. Zaś zmiana mentalności mogłaby być czasem nawet szkodliwa (np. gdyby korektorzy zmienili swój stosunek do bŁędów…).

Skoro Dz. U. był wydawany na papierze, to chyba jasne jest, że redakcja pracuje tak, żeby produkt jej pracy (plik PDF!) był strawny dla drukarni. A że przyszło opublikować pedeefa, to zapewne wrzucili, co mieli.

Co do struktury dokumentu: jestem niemal pewien, że jako tako otagowany tekst powstaje dopiero po zaimportowaniu tekstu z edytora do quarka, bo jest to zwyczajnie potrzebne, żeby numeracja się nie sypała i listy były właściwie wyjustowane (mam nadzieję, że się mylę). Do przygotowania pliku o poprawnej strukturze potrzebna jest stosowna staranność już krok wcześniej. No i odpowiednie narzędzia — w sumie z open-officem to całkiem niezły pomysł.

Ale istoty pracy redakcji zasadniczo to nie zmienia — redakcja jest od tego, żeby czuwać nad tym by nie wkradły się błędy do tekstu. Pytanie tylko, czy Centrum Obsługi Kancelarii Prezesa Rady Ministrów znajdzie kogoś, kto będzie potrafił wskazać właściwe narzędzia i przedstawić te kilka procedur koniecznych dla weryfikacji poprawności struktury XML-a w sposób który nie spowoduje, że jeden tekst będzie opracowywany dwukrotnie.

Nie sądzę, by

Nie sądzę, by przygotowywanie materiałów do publikacji w formie elektronicznej w jakikolwiek sposób wiązało się z koniecznością istotnej zmiany kwalifikacji tych ludzi. Zaś zmiana mentalności mogłaby być czasem nawet szkodliwa.

Zmiana mentalności, lub inaczej mówiąc, sposobu pracy, powinna polegać na tym, że redakcja i osoby zajmujące się przygotowaniem materiałów do druku na każdym etapie mieli na uwadze wszystkie media docelowe. Tak, by nie było konieczne dodatkowe dodatkowe przetwarzanie, bo to i dodatkowy czas i koszty. Drzewiej bywało, że ostatnie poprawki nanoszone były na blachach drukarskich. Idealnie byłoby, gdyby już na etapie projektu powstawał plik XML, esencja utworu jakim jest akt prawny, ustawa, itp. Powinien on sobie mieszkać bezpiecznie w bazie danych z historią modyfikacji i dostępu. Na nim powinna odbywać się praca, wprowadzanie zmian i on powinien być zatwierdzany (zabezpieczany - podpisywany elektronicznie). Finalna wersja może trafić prosto na stronę internetową, do wydawnictwa, lub, praktycznie automatycznie do wersji PDF. To oczywiście spore uproszczenie, ale pięknie brzmi, prawda? Ale tak to się odbywa we współczesnym świecie.

Co do struktury dokumentu: jestem niemal pewien, że jako tako otagowany tekst powstaje dopiero po zaimportowaniu tekstu z edytora do quarka.

I to błąd. Jak pisałem wyżej, obecnie wiele materiałów (głównie jeśli chodzi o wydawnictwa encyklopedyczne, dokumentacje techniczne, itp.) trafia do przygotowalni poligraficznej w formie XML'i lub wręcz SGML'a. Plus DTD, XSL i przy obecnie dostępnych narzędziach "jako takie" otagowanie gotowe jest z automatu.

Ale istoty pracy redakcji zasadniczo to nie zmienia — redakcja jest od tego, żeby czuwać nad tym by nie wkradły się błędy do tekstu.

Zgadza się. Ale redakcja merytoryczna dba o poprawność formalną i to ona powinna od razu pilnować właściwej struktury i metainformacji związanej ze źródłami. Redakcja techniczna na etapie konwersji na media wyjściowe ma jedynie pilnować aby w produkcie finalnym znalazło się dokładnie to co w materiale źródłowym.

Pytanie tylko, czy Centrum Obsługi Kancelarii Prezesa Rady Ministrów znajdzie kogoś, kto będzie potrafił wskazać właściwe narzędzia i przedstawić te kilka procedur koniecznych dla weryfikacji poprawności struktury XML-a w sposób który nie spowoduje, że jeden tekst będzie opracowywany dwukrotnie.

Właśnie! Obserwując prace legislacyjne związane z informatyką obawiam się, że może być to zadanie, które przerośnie naszą administrację. Obym się mylił.

Nie jak za króla Ćwieczka, tylko jak za komuny

Dz.U. i inne tego typu materiały są składane w drukarni rządowej mieszczącej się wewnątrz więzienia na Rakowieckiej, przez słabo opłacanych pracowników cywilnych oraz więźniów-ochotników. Urządzenia, które tam widziałem, to pochodzące z lat osiemdziesiątych ubiegłego wieku, maszyny dostosowane do składu, ze specjalnymi ekranami, ustawionymi pod kątem 90 stopni (zielone literki na czarnym tle, a jakże), gdzie wszelki justunek wykonuje się na sztywno i oczywiście nie ma mowy o takich uprzyjemnieniach jak automatyczna punktacja wyliczeń, czy automatyczny rozkład poziomy tekstu, nie mówiąc już o pionowym.
Tekst z takiej maszyny wędruje prosto do naświetlarki i już jako folia do offsetu. Aby więc można było zamienić te dane na format nieco bardziej zaawansowany, taki jak np. PDF, sądzę, że zhakowano format przekazywanych plików, rozbierając je, jak to się mówi, na części w edytorze binarnym i utworzono całkowicie nielicencjonowany konwerter, który przekształca plik w formacie utworzonym w maszynie (trudno to inaczej nazwać) składającej, na format PDF. Możliwe zresztą, że zostały do tego wykorzystane konwertery TAG-a, albo przerobione oprogramowanie naświetlarki. Przynajmniej sam bym od tego zaczął. Stąd w dokumencie wyjściowym brak danych niezbędnych do poruszania się w nim, takich jak np. zakładki.

Przypuszczam, że producent tamtego osprzętu mógłby się do tego wszystkiego przyczepić, choć na jego miejscu (o ile jeszcze istnieje), wykorzystałbym raczej ten fakt do celów reklamowych, a muzealne odpowiedniki wymienił bezpłatnie na nowoczesny sprzęt. Tyle, że trzeba by było operatorów szkolić od nowa...

A z jakiej wersji

1. Cytat:
są jeszcze "document restrictions"
koniec cytatu
A z jakiej wersji Evince kolega korzysta? Sprawdziłem także w wersji polskiej Evince 2.24.2
W menu Plik->Właściwości, zakładka "Ogólne" -> "Zabezpieczenia: Nie"
Zatem dokument nie posiada żadnych zabezpieczeń. A samo Rozporządzenie nie wskazuje jaką przeglądarkę plików pdf należy stosować. Jako ciekawostkę dodam, że urzędy zmuszane są przez różne firmy "tworzące" dla urzędów (z najwyższego nadania) do stosowania IE, która nie stosuje się do specyfikacji HTML. Czyli nosił wilk razy kilka.

Ale oczywiście te wszystkie sprawy zapewne zostały omówione przy okazji tworzenia prawa. Ciekaw jestem jak tam tłumaczono różnice w zachowaniu różnych przeglądarek pdf-ów, decydując się na ten standard? Czy jest jakieś uzasadnienie przyjęcia "standardu", który nie zawsze i nie wszędzie wygląda i funkcjonuje tak samo?

2. Skąd pomysł, że dokument elektroniczny ogłaszający prawo musi nadawać się do drukarni? W Rozporządzeniu nie ma takiego wymogu. Czy mamy rozumieć, że w omawianym przypadku nie dołożono należytych starań i wyprodukowano 2 w jednym?
Zazwyczaj normatywy przewidują koszty wprowadzenia uregulowań. Czy tym razem było inaczej, nie wyliczono kosztów wyprodukowania prawidłowego pdf-a?

Ciekaw jestem jak tam

Ciekaw jestem jak tam tłumaczono różnice w zachowaniu różnych przeglądarek pdf-ów, decydując się na ten standard? Czy jest jakieś uzasadnienie przyjęcia "standardu", który nie zawsze i nie wszędzie wygląda i funkcjonuje tak samo?

Myślę, że to nieuprawnione twierdzenie. To nie wina standardu, tylko implementacji przeglądarki. Za Wikipedią:

Dostępna jest bezpłatnie pełna specyfikacja formatu PDF. 29 stycznia 2007 firma Adobe postanowiła w całości otworzyć format PDF i przekazać jego pełną specyfikację organizacji AIIM. 2 lipca 2008 Międzynarodowa Organizacja Standaryzacyjna ogłosiła uznanie PDF 1.7 za obowiązujący standard ISO 32000-1:2008.

Więc format PDF nie jest "standardem" tylko standardem, a porównanie do IE chybione lub co najmniej niestosowne.
Mogę się mylić, ale z praktyki wiem, że PDF zapewnia najbliższe wierne odwzorowanie treści w formie zaplanowanej przez autora, inne niż obraz w formie bitmapy. Być może istnieją inne rozwiązania, ale są one zbyt niszowe, żeby miały sens ich wdrażania w takim przypadku ten. Jeśli są jakieś alternatywy, chętnie poczytam o nich. Inna sprawa: czy publikacja prawa tego wymaga? W większości przypadków nie, ale zdarzają się załączniki do ustaw zawierające wzory dokumentów, symboli graficznych itp., które muszą również zostać opublikowane w niezmienionej postaci.

2. Skąd pomysł, że dokument elektroniczny ogłaszający prawo musi nadawać się do drukarni?

Zgadzam się w zupełności, że nie musi. Musi nadawać się do wydruku. Do samej publikacji w formie elektronicznej wystarczyłby XML, ale należy pamiętać, że to publikowane elektronicznie prawo nie może być poddawane w wątpliwość (choćby słynne przecinki zmieniające treść ustawy diametralnie) i musi pozwalać na łatwą weryfikację jego spójności i zgodności z "oryginałem". Oczywiście rozwiązaniem jest podpis elektroniczny. Tyle, że dla normalnego człowieka XML, do tego podpisany, jest nieużywalny. Wymaga dodatkowych narzędzi, nie typowych na komputerach domowych.

I tu rozwiązaniem znów jest format PDF, który umożliwia również podpisywanie i weryfikację spójności i integralności dokumentu, zabezpieczenie przed modyfikacją, daje się łatwo przeszukiwać (mówimy o prawidłowo wygenerowanym pliku w nowej wersji formatu PDF), umożliwia wydruk, kopiowanie treści, a przeglądarka plików PDF jest w praktyce na każdym komputerze.

Proszę nie traktować moich wypowiedzi jako promocji formatu PDF czy firmy za nim stojącej. Po prostu uważam, że jest to bardzo dobry wybór, który świetnie uzupełni podstawowy format elektronicznej publikacji prawa jakim powinien być XML. Smutne jedynie jest to, że nasz ustawodawca nie potrafi wykorzystać możliwości drzemiących w nowych technologiach, których wykorzystanie jest proste i oczywiste dla lekko zorientowanego gimnazjalisty.

"Więc format PDF nie jest

Więc format PDF nie jest "standardem" tylko standardem, a porównanie do IE chybione lub co najmniej niestosowne

HTML też jest standardem, a jak realizuje go IE wszyscy wiemy.

Tyle, że dla normalnego człowieka XML, do tego podpisany, jest nieużywalny. Wymaga dodatkowych narzędzi, nie typowych na komputerach domowych

Dla normalnego człowieka, nie posiadającego przeglądarki pdf - pliki pdf też będą nieużywalne. Mówiąc o "typowym komputerze domowym" musimy dodać "w roku...." Nie będę się rozwodził nad tym jakie narzędzia były typowe w ciągu ostatnich 15 lat. Dość, że produktów dla wielu z tych narzędzi dawno już nie ma, a rozwój w tej dziedzinie polega na dodawaniu tychże nowych narzędzi i zastępowaniu byłych "typowych"

"Standard" PDF - domyślam się, że osoby odpowiedzialne za przyjęcie tegoż wiedzą o tym iż zmienia się on jak w kalejdoskopie (rozumiem, że jest doskonalony) i proponują ustawiczne gonienie króliczka (http://www.adobe.com/devnet/pdf/pdf_reference_archive.html) jako najlepsze rozwiązanie dla polskiego prawa.

Lepsze (czytaj przyszłościowe) rozwiązania, a zwłaszcza ich odrzucenie było już tu omawiane (http://prawo.vagla.pl/node/8268#comment-13533)

Wydaje mi się, że przyjęcie pdf-a było podyktowane tym, że z nim będzie łatwiej niż z XML-em, XSD, tymi wszystkimi metadanymi, strukturami itd. Mniej roboty i na dzisiaj działa jako tako.

Zobaczymy za lat pięć. Bo prawo jest stanowione po to aby działało za lat pięć i dziesięć, a nie doraźnie.

PS.

Proszę o ewentualne połączenie postów.

Tu garść informacji na temat pdf-a: Wikipedia, Portable Document Format

Krótko mówiąc PDF służy do jak najbardziej wiernego oddania wyglądu dokumentu: czcionka, interlinia, justowanie etc., a chyba nie o to chodzi.

Przecinki nie są przysłowiowe lecz istotne. Przysłowiowa może stać się przymusowa czcionka lub interlinia w pdf-ie, których nie będę mógł sobie zmienić do czytania. Podpisać elektronicznie można też ODT, a do czytania dowolnie sobie formatować.

A jak, w przeciwieństwie do jednorazowych XML-XSD, będą wyglądały prawa autorskie i majątkowe do każdego pdf-a?

ważna jest treść rozporządzenia

Komentarze skupiają się zasadniczo na formalnej stronie uprawnień i sposobów odczytu i kopiowania rozporzadzenia.
Wersja publikowawana w MSWiA od 2.01.2009 nie daje się także łatwo kopiować fragmentami. Przepiszę więc tekst, który będę musiał przytoczyć poniżej. To mi zawsze wolno.

Brakuje mi jednak zainteresowania zawartością oraz trybem przyjęcia rozporządzenia. Czy ktoś potrafi wytłumaczyć tworzenie aktów w XML, załaczników w czymkolwiek o charakterze binarów a publikacji w PDF. Nie zdefiniowano struktury dziennika urzędowego zaś wymieniono składowe części aktu. Jutro będę musiał wytłumaczyć gminom co miał na myśli rozporządzający pisząc:

Włączone w treść aktu elementy zewnętrzne określone w ust 2 pkt 4 są przechowywane w postaci plików binarnych do których odwołanie następuje w postaci względnego odnośnika opatrzonego etykietą z informacją na temat danego zbioru. Bezpośrednio w kodzie XML dokumentu elektronicznego wprowadza się skrót kryptograficzny danego pliku binarnego wyliczanego za pomocą funkcji skrótu.

Niby wszystko jasne ale wchodząc w szczegóły nie tak bardzo. Np:

wybór funkcji skrótu i oprogramowania do tego służącego (MD5 MD4, SHA1);

czy zasady konstruowania aktu w jakiś sposób przenoszą się do publikowanego Dz.Urz. a jeżeli tak, to czy na opisanych zasadach, a może jednak obowiązuje publikacja PDF dużego obejmującego cały dziennik.
itd
KJM

No i rozgorzał spór.

Witam.

Jak widzę, również tutaj pojawiła się kwestia dyskusji na temat co "jest lepsze od czego".

Dostrzegłem także w dwóch postach po jednej linijce na temat mi bliski.

Pojawiło się słowo "OpenOffice". Zaskakującym wciąż jest dla mnie faktem, że pomimo "bezpłatności" tego pakietu, wielkie głowy legislacyjne poświęcają mnóstwo czasu na wyważanie wręcz otwartych już dawno drzwi. Aż wręcz dziw bierze, że narzędzie dostępne za przysłowiowe darmo i będące w zasięgu ręki, jest wciąż wypierane z umysłów. OpenOffice bowiem generuje pliki PDF, pozwala złożyć podpis elektroniczny pod wynikiem pracy "writer'a", "calc'a" czy "impress'a". W przypadku wyeksportowanego pliku PDF, podpis elektroniczny trzeba złożyć zewnętrznie, ale tu przyznam się, że nie sprawdzałem jak wychodzi konwersja do PDF'a, pliku np. ODT podpisanego cyfrowo.

Wracając jednak do ODT, ODS, ODP, są to jedynie używane przez większość urzędów produkty wytwarzane za pomocą aplikacji biurowych. W urzędach wytwarza się pisma (ODT), arkusze zestawieniowe (ODS) albo prezentacje (ODP). Każdy z tych plików może zostać podpisany cyfrowo i jest to wbudowane za darmo w aplikację. Wersje OpenOffice'a są dostępne za darmo i na chyba wszystkie systemy operacyjne. A skoro tak jest, to aż groteskowym staje się fakt, że urzędy dowolnego szczebla brną w pakiety MS Office i inne rozwiązania wymagające tworzenia nowych zamkniętych aplikacji umożliwiających wprowadzenie informatyzacji.

Wspomnę też przy okazji pomysł jaki zastosowali Norwegowie. Ustanowili prawo w którym dokumenty mają jedynie 3 formaty.

  1. Format OASIS dla dokumentów które mają funkcjonować jako pisma na których obywatel ma mieć możliwość wpisania swoich np. danych. Stanowi to analogię do formularzy papierowych drukowanych, które wypełnia się we wskazanych miejscach.
  2. Format PDF dla tych dokumentów, które mają zachować wierne odwzorowanie wizualne postaci drukowalnej. Dokumenty bez możliwości edycji.
  3. Format HTML dla dokumentów zamieszczanych na stronach internetowych.

Postawili także wymóg, że do roku 2014, wszystkie dokumenty już istniejące, mają zostać przekonwertowane do właściwych formatów.

No i proszę. Jeden pakiecik jakim jest OpenOffice, załatwia tak wiele spraw za jednym podejściem. Przy okazji, konstrukcja plików jakie generuje OpenOffice zbudowana jest na XML'ach właśnie. Możliwe, że między innymi tym kierowali się Norwegowie ustalając to prawo. Jak widać Norwegowie potrafią. :-)

Ciekawe tylko, dlaczego nikt ze sprawujących władzę w Polsce, nie chce dostrzec, że coś niezłego jest tuż pod ręką. Czyżby jednak wiara w cenę była silniejsza od zdrowego rozsądku? A może jest po prostu tak, że są zobowiązania wobec kogoś i kasę podatnika trzeba wydawać na odpłatne rozwiązania czegoś, co każdy może sobie pobrać z internetu za darmo zainstalować na swoim komputerze w domu czy pracy.

Pozdrawiam.

Przyjęli, opublikowali, ogłosili i ...

Przyjęli, opublikowali, ogłosili i ... zapomnieli?

1. Tylko w jednym miejscu, na stronie właściwego organu (http://www.cokprm.gov.pl/files/strony/Wydawnictwa/dzienniki/DziennikUstaw2009.html) znalazłem Dzienniki Ustaw w postaci "dokumentów elektronicznych zawierających akty normatywne i inne akty prawne"
Od 29 grudnia 2008 roku wydano już 13 Dzienników Ustaw. Żaden z nich nie nie jest zgodny z Rozporządzeniem ponieważ nie jest opatrzony "bezpiecznym podpisem elektronicznym organu" (§ 3 ust. 2 Zarządzenia)
Być może źle szukałem i ktoś mi pomoże.

2. Tu (http://www.cokprm.gov.pl/2,63,g,dzienniki_ustaw_2009,oferta_wydawnicza.html) mogę dowiedzieć się, że "Treść niniejszych Dzienników Ustaw nie stanowi źródła prawa, lecz jest tylko ich zapisem elektronicznym" (?) (...) "Jedyne źródło prawa na terenie Rzeczypospolitej Polskiej stanowią (...) akty normatywne ogłaszane w Dziennikach Ustaw"
Prawda, że ciekawe?

3. Najlepsze na koniec. Pod tym samym adresem możemy się dowiedzieć, że "Z uwagi na niedoskonałość zabezpieczeń chroniących przed nieuprawnionym dostępem do internetu wydawca nie ponosi odpowiedzialności za treść publikowanych tu aktów prawnych"

W kontekście wcześniejszej informacji, że siedziba Internetu mieści się w Warszawie, trzeba chyba w końcu zadać to pytanie:
Czy leci z nami pilot?

Piotr VaGla Waglowski

VaGla
Piotr VaGla Waglowski - prawnik, publicysta i webmaster, autor serwisu VaGla.pl Prawo i Internet. Ukończył Aplikację Legislacyjną prowadzoną przez Rządowe Centrum Legislacji. Radca ministra w Departamencie Oceny Ryzyka Regulacyjnego a następnie w Departamencie Doskonalenia Regulacji Gospodarczych Ministerstwa Rozwoju. Felietonista miesięcznika "IT w Administracji" (wcześniej również felietonista miesięcznika "Gazeta Bankowa" i tygodnika "Wprost"). Uczestniczył w pracach Obywatelskiego Forum Legislacji, działającego przy Fundacji im. Stefana Batorego w ramach programu Odpowiedzialne Państwo. W 1995 założył pierwszą w internecie listę dyskusyjną na temat prawa w języku polskim, Członek Założyciel Internet Society Poland, pełnił funkcję Członka Zarządu ISOC Polska i Członka Rady Polskiej Izby Informatyki i Telekomunikacji. Był również członkiem Rady ds Cyfryzacji przy Ministrze Cyfryzacji i członkiem Rady Informatyzacji przy MSWiA, członkiem Zespołu ds. otwartych danych i zasobów przy Komitecie Rady Ministrów do spraw Cyfryzacji oraz Doradcą społecznym Prezesa Urzędu Komunikacji Elektronicznej ds. funkcjonowania rynku mediów w szczególności w zakresie neutralności sieci. W latach 2009-2014 Zastępca Przewodniczącego Rady Fundacji Nowoczesna Polska, w tym czasie był również Członkiem Rady Programowej Fundacji Panoptykon. Więcej >>