Krzysztof Siewicz. Prawne aspekty zamówień publicznych na oprogramowanie

Transkrypt

1 Krzysztof Siewicz Prawne aspekty zamówień publicznych na oprogramowanie FUNDACJA WOLNEGO I OTWARTEGO OPROGRAMOWANIA POZNAŃ 2010

2 Autor Krzysztof Siewicz Prawnik specjalizujący się w prawie autorskim oraz prawnych aspektach stosowania nowoczesnych technologii. Absolwent Wydziału Prawa i Administracji Uniwersytetu Warszawskiego oraz Central European University w Budapeszcie. Autor publikacji na temat kwestii prawnych związanych z wolnym oprogramowaniem oraz bloga poświęconego tej tematyce ( Koordynator prawny Creative Commons Polska. Redakcja i korekta Grzegorz Kmita Projekt Dariusz Stryniak Fotografie Archiwum sxc.hu Wydawca Fundacja Wolnego i Otwartego Oprogramowania ul. Wawrzyniaka 10, Poznań tel. +48 (61) , +48 (61) fax +48 (61) info@fwioo.pl Poznań 2010 DTP, druk i oprawa SORUS SC Wydawnictwo i Drukarnia Cyfrowa ul. Starołęcka 18, Poznań tel. (61) sorus@sorus.pl

3 Wprowadzenie O rgany administracji i inne organy władzy publicznej od dawna korzystają z systemów teleinformatycznych. Wykorzystywane są one na przykład do udostępniania informacji publicznych, załatwiania spraw indywidualnych, prowadzenia publicznych konsultacji, prowadzenia postępowań o udzielanie zamówień publicznych. Informatyzacja działalności podmiotów realizujących zadania publiczne służy nie tylko wspieraniu ich wewnętrznej działalności (w tym komunikacji między tymi podmiotami, tzw. A2A). Jest ona także środkiem do celu jakim jest usprawnienie komunikacji urzędów i obywateli (tzw. A2C, C2A) oraz urzędów i przedsiębiorców (tzw. A2B, B2A). Już na obecnym stopniu zaawansowania informatyzacji prawidłowe wykonanie wielu czynności urzędowych zależy w dużym stopniu od sprawności działania systemów teleinformatycznych. W przyszłości należy oczekiwać dalszej ekspansji tych systemów, a w konsekwencji sytuacji, w której władza publiczna będzie wspierana przez nie niemal na każdej płaszczyźnie swojej działalności. Istotnym składnikiem systemów teleinformatycznych są programy komputerowe. Programy działające źle lub niezdolne do realizacji wszystkich wymaganych funkcji muszą być niezwłocznie naprawiane, ulepszane lub zastępowane przez inne programy. W przeciwnym wypadku system nie będzie zdolny do realizacji swojego zadania lub wykona go nieprawidłowo. W praktyce często dochodzi do sytuacji, w której programy zawierają błędy albo zachodzi konieczność wyposażenia ich w dodatkowe funkcje. W związku z tym niezwykle rzadko zdarza się, że dany program jest wykorzystywany w niezmienionej postaci przez cały okres życia danego systemu. Na porządku dziennym jest dokonywanie modyfikacji programów i dostarczanie ich użytkownikowi w formie poprawek i ulepszeń (tzw. patches, updates, upgrades itd.), zazwyczaj na podstawie umów o wsparcie, serwis lub utrzymanie. Co do zasady, w celu dokonania modyfikacji programu konieczny jest dostęp do jego tzw. kodu źródłowego. Kod źródłowy to zapis programu przeznaczony dla człowieka. Z kolei do korzystania z gotowego programu wystarcza uzyskanie tzw. kodu wynikowego. 1 Kod wynikowy to nic innego jak kod źródłowy programu przetłumaczony (skompilowany) na komunikaty przeznaczone dla komputera. Po kompilacji kod wynikowy może być rozpowszechniany i uruchamiany bez udostępniania kodu źródłowego. Teoretycznie, bez dostępu do kodu źródłowego można próbować dokonać modyfikacji programu, np. za pomocą dekompilacji. W praktyce jednak dokonywanie modyfikacji nie jest możliwe bez dostępu do prawidłowo udokumentowanego kodu źródłowego. 1 Jest to zasadą przy programach pisanych w tzw. językach kompilowanych. Programy pisane w tzw. językach interpretowanych są wykonywane bezpośrednio, bez konieczności dokonywania kompilacji kodu źródłowego na kod wynikowy. Niemniej jednak kody źródłowe programów napisanych w językach interpretowanych są często poddawane szyfrowaniu i w takiej postaci udostępniane użytkownikowi. Szyfrowanie ma podobny efekt do kompilacji zaszyfrowany program można jedynie uruchamiać, a dokonanie modyfikacji nie jest łatwe lub jest po prostu niemożliwe. Dla uproszczenia taki zaszyfrowany kod będziemy w niniejszym dokumencie nazywać również kodem wynikowym. 3

4 Obecnie nawet proste zadania realizowane są poprzez wiele współdziałających ze sobą programów. Współdziałanie to może odbywać się w ramach jednego komputera, jednak coraz częściej systemy teleinformatyczne obejmują programy komputerowe zainstalowane na różnych komputerach, połączonych ze sobą poprzez sieć (np. Internet). Prawidłowe współdziałanie różnych programów jest niezwykle istotne z punktu widzenia władz publicznych. Zadania realizowane przez te władze polegają bowiem często na wykorzystywaniu różnych programów do komunikacji pomiędzy urzędami, obywatelami i przedsiębiorcami, z których każdy wykorzystuje własne oprogramowanie. Aby dany program sprawnie współdziałał z innym programem, oba muszą komunikować się w oparciu o wspólny protokół, interfejs lub format danych. Wprowadzenie do danego programu obsługi protokołu, interfejsu lub formatu danych wykorzystywanego przez inny program wymaga dokonania w nim stosownej modyfikacji, czyli zgodnie z powyższymi wyjaśnieniami dostępu do jego kodu źródłowego. Dostęp do kodu źródłowego programu jest to jednak tylko pierwszy warunek konieczny do zapewnienia prawidłowego współdziałania tego programu z innymi programami. Osoba, która chce zapewnić prawidłowe współdziałanie dwóch programów musi dodatkowo dysponować dokładnymi informacjami o protokole, interfejsie lub formacie danych, który programy te mają wykorzystywać do współdziałania. Informacje takie zawarte są zwykle w specyfikacji protokołu, interfejsu lub formatu danych. Teoretycznie, bez dostępu do specyfikacji można próbować uzyskać te informacje dokonując inżynierii wstecznej programu, który już obsługuje dany protokół, interfejs lub format danych. Jest to jednak równie niepraktyczne jak dekompilacja, która jest zresztą przykładem inżynierii wstecznej. W praktyce zatem, drugim warunkiem koniecznym prawidłowego współdziałania programów jest dostęp do specyfikacji protokołu, interfejsu lub formatu danych, który ma być wykorzystywany przez te programy do współdziałania. Podsumowując, zapewnienie prawidłowego działania programów komputerowych wymaga dostępu do (1) kodów źródłowych tych programów oraz (2) specyfikacji protokołów, interfejsów lub formatów danych, w oparciu o które programy te mają współdziałać. Dostęp do samych tylko kodów wynikowych wystarcza jedynie do korzystania z tych programów, bez większego wpływu na to, jak realizują one swoje funkcje. W takiej sytuacji istotnego znaczenia nabiera odpowiedź na pytanie, kto ma dostęp do kodów źródłowych i specyfikacji. Na rynku można zaobserwować różne podejścia do kwestii umożliwiania tego dostępu. Dwa skrajne podejścia w odniesieniu do udostępniania kodów źródłowych to: (1) oprogramowanie własnościowe oraz (2) wolne oprogramowanie. Producenci oprogramowania własnościowego zachowują daleko idącą kontrolę nad kodami źródłowymi. Utrzymują je w tajemnicy albo pozwalają je przeglądać tylko wybranym osobom, jednak zwykle bez udzielania zgody na dokonywanie modyfikacji i na rozpowszechnianie. Uprawnienia użytkowników do korzystania z własnościowego oprogramowania są też istotnie ograniczone. Z kolei producenci wolnego oprogramowania dążą do przekazania użytkownikowi pełnej kontroli nad oprogramowaniem. Użytkownik wolnego oprogramowania uzyskuje nie tylko kody wynikowe, ale przede wszystkim kody źródłowe. Ponadto udzielana jest mu zgoda na korzystanie z obu form wyrażenia programu bez ograniczeń, w tym również na dokonywanie jego modyfikacji i dalsze rozpowszechnianie. Natomiast dwa skrajne podejścia w odniesieniu do specyfikacji protokołów, interfejsów lub formatów danych to: (1) zamknięte protokoły, interfejsy i formaty danych oraz (2) otwarte standardy. Specyfikacje zamkniętych protokołów, interfejsów oraz formatów danych nie istnieją w ogóle albo nie są publicznie dostępne. Korzystanie z takich protokołów, interfejsów i formatów danych jest ponadto obwarowane ograniczeniami prawnymi, które wynikają między innymi z praw wyłącznych, takich jak patenty. Ich wdrożenie w danym programie jest możliwe, gdy podmiot kontrolujący 4

5 wyrazi na to swoją zgodę (lub gdy zostanie uruchomiony prawny mechanizm przymuszający go do wyrażenia takiej zgody, jak na przykład prawo ochrony konkurencji). Otwarte standardy natomiast to takie protokoły, interfejsy i formaty danych, które zostały poddane specjalnej procedurze standaryzacyjnej. Efektem tej procedury jest m.in. publiczna dostępność ich specyfikacji oraz usunięcie istotnych ograniczeń prawnych. Dokładniej rzecz ujmując, jeżeli z otwartym standardem związane są jakieś prawa wyłączne, to licencja na korzystanie z tych praw jest udzielana każdemu w sposób nieograniczający możliwości wdrożenia standardu. Pomiędzy zamkniętymi protokołami, interfejsami i formatami danych z jednej strony, a otwartymi standardami z drugiej, występuje w praktyce całe spektrum rozwiązań pośrednich. W ramach tego spektrum występują różnego rodzaju zamknięte standardy. Do powstania zamkniętego standardu dochodzi wtedy, gdy pomimo procedury standaryzacyjnej korzystanie ze standardu podlega nadal istotnym ograniczeniom technicznym lub prawnym. Może to być np. wynikiem istnienia patentów związanych ze standardem, na które nie są udzielane licencje, lub których licencje nie pozwalają na swobodne korzystanie. Pomimo dostępności specyfikacji, nie wszyscy producenci oprogramowania mogą zgodnie z prawem oferować na rynku oprogramowanie zgodne z zamkniętym standardem, nawet jeżeli wdrożenie tego standardu byłoby dla nich technicznie możliwe. Najczęstszą przyczyną powstania zamkniętego standardu jest brak otwartej procedury standaryzacyjnej lub brak wymagania, aby uczestniczące w niej podmioty informowały o posiadanych patentach związanych ze standardem wraz ze zobowiązaniem się do udzielenia niedyskryminujących licencji. Na rynku występuje wiele kombinacji pomiędzy podejściami odnoszącymi się do udostępniania kodów źródłowych programów a podejściami odnoszącymi się do udostępniania specyfikacji protokołów, interfejsów oraz formatów danych. Na przykład wielu producentów oprogramowania własnościowego wdraża w nim otwarte standardy. Użytkownik takich programów nie może łatwo wpływać na to, jak one działają, ze względu na brak lub ograniczone prawo do wykorzystania kodów źródłowych. Inny producent może jednak wtedy dostarczyć temu użytkownikowi substytucyjny program zdolny obsłużyć taki otwarty standard, gdyż nie ma istotnych ograniczeń we wdrażaniu otwartych standardów. Taki program może być wolnym oprogramowaniem albo innym programem własnościowym. Otwarte standardy istotnie przyczyniają się do sytuacji, w której różni użytkownicy mogą komunikować się za pomocą różnego oprogramowania, dostarczanego przez różnych producentów. Użytkownicy mają możliwość wyboru, a konkurencja na rynku nie jest ograniczona w sposób dyskryminujący. Jednak wielu producentów własnościowego oprogramowania projektuje je tak, aby obsługiwało ono dobrze tylko ich własne, zamknięte protokoły, interfejsy i formaty danych. Niektórzy wykorzystują też posiadaną kontrolę nad zamkniętymi standardami tak, aby bronić swoją pozycję rynkową przed konkurencyjnymi producentami. Utrudnia to lub wręcz uniemożliwia innym producentom produkcję programów zdolnych do sprawnego współdziałania. Dotyka to zarówno producentów innego oprogramowania własnościowego, jak i producentów wolnego oprogramowania. Niekiedy udaje się mimo wszystko wdrożyć zamknięte rozwiązanie, np. w drodze inżynierii wstecznej, jednak rzadko udaje się uzyskać satysfakcjonujący poziom współdziałania i jednocześnie zgodność z przepisami prawa, jeżeli podmiot kontrolujący to rozwiązanie nie zechce współpracować i udzielić stosownej licencji. Ale licencje na zamknięte protokoły, interfejsy, formaty danych oraz na zamknięte standardy nie są udzielane w sposób niedyskryminujący, zatem tylko niektórzy producenci mogą je wdrożyć we własnym oprogramowaniu. W praktyce informatyzacji działalności podmiotów realizujących zadania publiczne poszczególne urzędy dokonują wyboru programów, wyprodukowanych według jednej z wielu możliwych kombinacji opisanych wyżej podejść. Każdy z tych wyborów określa, czy i w jakim stopniu jest możliwe wpływanie na to, jak to 5

6 oprogramowanie działa, a w szczególności jakie inne oprogramowanie może z nim współdziałać, i kto może wpływać na jego działanie. Ma to istotne przełożenie na sposób i poprawność realizowania zadań publicznych. W największym skrócie, wybór oprogramowania własnościowego zdolnego do współdziałania tylko w oparciu o zamknięte protokoły, interfejsy lub formaty danych nie prowadzi do uzyskania przez urząd zbyt wielkiej kontroli nad oprogramowaniem. Ponadto, w ten sposób urząd utrudnia innym użytkownikom (obywatelom, przedsiębiorcom) współdziałanie za pomocą różnych, swobodnie wybranych przez nich programów. Natomiast jeżeli urząd wybierze oprogramowanie własnościowe zdolne do współdziałania w oparciu o otwarte standardy, to nie utrudnia żadnemu zainteresowanemu współdziałania w oparciu o swobodnie wybrane przez niego oprogramowanie, wolne lub własnościowe. Nadal jednak urząd nie uzyskuje nad zakupionym przez siebie oprogramowaniem zbyt wielkiej kontroli. Taką kontrolę zapewnia uzyskanie dostępu do kodu źródłowego wraz z szerokim zakresem uprawnień, co ma miejsce w sytuacji wyboru przez urząd wolnego oprogramowania. Dodatkowe wymaganie zgodności tego oprogramowania z otwartym standardem (co nie stanowi większego problemu, gdyż wolne oprogramowanie zwykle współdziała w oparciu o otwarte standardy) ma dodatkowo ten skutek, że nie ogranicza swobody wyboru oprogramowania przez użytkowników, którzy chcą lub muszą współdziałać z oprogramowaniem urzędu. Organy władzy publicznej nie mają jednak pełnej swobody wyboru dowolnej spośród wszystkich opisanych wyżej kombinacji. W odróżnieniu od podmiotów prywatnych, muszą one dokonywać takiego wyboru uwzględniając interes publiczny w sposób szczegółowo uregulowany w przepisach prawa, takich jak Konstytucja, ustawa o informatyzacji, Prawo zamówień publicznych. Celem niniejszego informatora jest przedstawienie wymagań wynikających z tych przepisów. Materiał podzielono na następujące części. W części pierwszej przedstawiono dokładniejsze definicje podstawowych pojęć wykorzystywanych w informatorze. W części drugiej omówiono przepisy regulujące publiczne zamówienia na oprogramowanie. Część trzecia zawiera opis najczęstszych nieprawidłowości i błędów, popełnianych przy ogłaszaniu takich zamówień. W części czwartej przedstawiamy wnioski i rekomendacje dotyczące poprawnego konstruowania i prowadzenia postępowań o udzielanie zamówień publicznych na oprogramowanie. 6

7 1 / Wyjaśnienie podstawowych pojęć W tej części informatora przedstawiamy dokładniejsze definicje najważniejszych wykorzystywanych tu pojęć. Są to: (1) wolne oprogramowanie (free software), (2) otwarte oprogramowanie (open source), (3) różne rodzaje oprogramowania własnościowego, (4) licencje wolnego oprogramowania, oraz (5) otwarte standardy. 1.1 / Wolne oprogramowanie (free software) Wolne oprogramowanie to programy komputerowe, które są dostępne dla użytkownika wraz z prawami do pełnej jego kontroli (dokonywanie modyfikacji, rozpowszechniania, używania bez ograniczeń). W tym celu jest ono udostępniane na specjalnych licencjach, a użytkownik uzyskuje dostęp nie tylko do kodu wynikowego, lecz również do kodu źródłowego programów. Autorem formalnej definicji wolnego oprogramowania jest Richard M. Stallman. 2 Zgodnie z tą definicją, wolne oprogramowanie to takie, którego każdy użytkownik może realizować wszystkie cztery poniższe uprawnienia: wolność uruchamiania programu, w dowolnym celu (...), wolność analizowania, jak program działa, i dostosowywania go do swoich potrzeb ( ), wolność rozpowszechniania kopii ( ), wolność udoskonalania programu i publicznego rozpowszechniania własnych ulepszeń ( ). 3 To, czy użytkownik może skorzystać z tych uprawnień zależy przede wszystkim od zakresu licencji udzielonej na program przez jego producenta lub inny podmiot praw autorskich. Powołana przez Stallmana Free Software Founda- 2 R.M. Stallman, Free Software Definition, pod: oraz: 3 Id. 7

8 tion (FSF) z siedzibą w USA zajmuje się m.in. sprawdzaniem, czy różne modelowe licencje są zgodne z tą definicją. Odnośniki do licencji uzna nych za zgodne, a także odnośniki do licencji, które nie przeszły testu zgodności wraz z komentarzami publikowane są na specjalnej stronie internetowej FSF. 4 W powszechnym obiegu funkcjonuje kilka istotnych nieporozumień. Mianowicie, wolne oprogramowanie jest często utożsamiane (1) z oprogramowaniem darmowym (freeware), (2) z oprogramowaniem do użytku niekomercyjego lub (3) z oprogramowaniem niechronionym prawem autorskim (public domain software). Ad 1. Wolne oprogramowanie jest zwykle nieodpłatnie udostępniane w Internecie przez samych producentów lub inne uprawione podmioty. Niemniej jednak istnieją przedsiębiorcy prowadzący różnego rodzaju działalność gospodarczą związaną z wolnym oprogramowaniem. Sprzedają oni często te same wolne programy, które udostępniają jednocześnie za darmo. Kluczem do zrozumienia tego pozornego paradoksu jest m.in. to, że tylko niektórym użytkownikom wystarcza uzyskanie programu jako takiego. Użytkownicy zwłaszcza ci, którzy nie są specjalistami wymagają zwykle również, aby program został odpowiednio skonfigurowany, skompilowany, zintegrowany z pozostałymi elementami ich systemów teleinformatycznych itd. Pozwala to na sprzedawanie wolnego oprogramowania zwłaszcza, gdy sprzedażą objęte są wszystkie lub niektóre z takich usług dodatkowych. Funkcjonuje tu wiele modeli biznesowych. Co istotne, przedsiębiorcy trudniący się sprzedażą wolnego oprogramowania lub odpłatnym świadczeniem usług dodatkowych są gotowi płacić swoim pracownikom lub innym osobom za to, aby pracowały nad wolnym oprogramowaniem, nawet jeżeli jest ono dostępnie nieodpłatnie w Internecie. Dlatego też istotna część twórców wolnego oprogramowania uzyskuje za nie wynagrodzenie. 4 Free Software Foundation, Various Licenses and Comments About Them, pod: oraz: Wobec powyższego, utożsamianie wolnego oprogramowania z oprogramowaniem darmowym (freeware) jest nieprawidłowe. Ad 2. Jak już wyjaśniono powyżej, wolne oprogramowanie jest udostępniane na licencjach, które nie wprowadzają ograniczeń w zakresie korzystania, modyfikacji i rozpowszechniania tego oprogramowania. W szczególności licencje te nie zakazują komercyjnego wykorzystania z wolnego oprogramowania można korzystać nie tylko do użytku osobistego lub domowego. Korzystanie z tego oprogramowania przez przedsiębiorców i urzędy nie wymaga uzyskania lub opłacenia dodatkowej licencji. Wobec powyższego, utożsamianie wolnego oprogramowania z oprogramowaniem do użytku niekomercyjnego jest nieprawidłowe. Ad 3. Wolne oprogramowanie jest chronione prawem autorskim. Udzielenie licencji zgodnej z wyżej przywołaną definicją wolnego oprogramowania nie prowadzi do wyzbycia się tych praw przez uprawniony podmiot. Licencje wolnego oprogramowania precyzują często obowiązki licencjobiorcy, które nie miałyby tak mocnej podstawy prawnej w sytuacji, gdyby przedmiot licencji nie był objęty ochroną prawno-autorską. Wobec powyższego, utożsamianie wolnego oprogramowania z oprogramowaniem nie objętym ochroną prawa autorskiego (public domain software) jest nieprawidłowe. 1.2 / Oprogramowanie open source Często słyszy się o oprogramowaniu otwartym lub oprogramowaniu open source. Istnieje również formalna definicja open source. 5 Jest ona stosowana przez organizację Open Source Initiative w celu certyfikacji modelowych licencji oprogramowania (podobnie jak to czyni Free Software Foundation). Definicja wolnego opro- 5 Open Source Initiative, Open Source Definition, pod: 8

9 gramowania i definicja open source różnią się sposobem formułowania wymagań w stosunku do uprawnień użytkownika. Jednakże same wymagania pozostają co do zasady takie same: zarówno wolne oprogramowanie, jak i oprogramowanie otwarte (open source) to programy komputerowe, które są dostępne dla użytkownika wraz z prawami do pełnej jego kontroli. Nie dziwi zatem, że większość popularnych modelowych licencji wolnego oprogramowania uznano równocześnie za zgodne z definicją open source. 6 Zatem, pojęcia wolne oprogramowanie i oprogramowanie open source ( otwarte oprogramowanie ) mogą być bez większego ryzyka uznawane za tożsame. 7 W niniejszym informatorze będzie używane pojęcie wolne oprogramowanie. 1.3 / Różne rodzaje oprogramowania własnościowego Oprogramowanie własnościowe to w największym skrócie przeciwieństwo wolnego oprogramowania. Użytkownik oprogramowania własnościowego nie ma tak szerokich uprawnień jak użytkownik wolnego oprogramowania. Zwykle ograniczają się one do uprawnienia do korzystania z programu na skończonej liczbie stanowisk (tzw. licencje stanowiskowe, per seat, per user). Niekiedy producent zezwala wybranym użytkownikom na przeglądanie kodu źródłowego, jednakże udzielenie licencji pozwalającej na modyfikacje jest wyjątkiem (dotyczy czasami oprogramowania stworzonego na specjalne zamówienie). Zezwolenia na rozpowszechnianie własnościowego oprogramowania (np. udostępnienie programu przez jeden urząd 6 Por.: Free Software Foundation, Various Licenses and Comments About Them, pod: z: Open Source Initiative, The Approved Licenses, pod: 7 Zob.: Richard M. Stallman, Why "Free Software" is better than "Open Source", pod: innemu urzędowi) nie są udzielane użytkownikom, lecz tylko autoryzowanym dystrybutorom. Oczywiście z formalnego punktu widzenia nic nie stoi na przeszkodzie, aby producent własnościowego oprogramowania i użytkownik wynegocjowali szerszy zakres uprawnień, w wyniku czego producent udostępni oprogramowanie użytkownikowi na jednej z licencji wolnego oprogramowania. Wtedy oprogramowanie to stanie się wolnym oprogramowaniem. Zależy to tylko od woli stron umowy licencyjnej. Producenci oprogramowania własnościowego stosują wiele różnych modeli biznesowych. Najprostszym modelem jest sprzedaż nośników z oprogramowaniem lub jego odpłatna dystrybucja drogą elektroniczną. W takim modelu nie ma dostępu do programu bez uiszczenia opłaty. Wielu producentów, dążąc do zachęcenia użytkowników do korzystania z ich oprogramowania lub dążąc do upowszechnienia się standardu wdrożonego w danym programie decyduje się jednak udostępniać to oprogramowanie za darmo (tzw. freeware). Korzystanie z freeware nie wymaga ponoszenia opłat, jednakże w odróżnieniu od wolnego oprogramowania freeware nie jest udostępniane na wolnych licencjach. Korzyścią użytkownika jest zatem uniknięcie konieczności zapłaty, ale nie uzyskanie szerokich uprawnień, jakimi cieszą się użytkownicy wolnego oprogramowania. Freeware nie może być swobodnie modyfikowane ani rozpowszechniane. Podobieństwo angielskich określeń freeware i free software może prowadzić do nieporozumień, jednak nie są to pojęcia tożsame z tego powodu należy zawsze dokładnie zapoznać się z postanowieniami licencji danego programu. Istnieje wiele modeli pośrednich pomiędzy sprzedażą oprogramowania własnościowego a freeware. Często stosuje się np. odroczone terminy płatności, tzn. użytkownik może korzystać z oprogramowania na próbę (trial), jednak np. po 30 dniach musi już wykupić licencję albo zaprzestać korzystania z programu. Z kolei licencje shareware pozwalają użytkownikom dzielić się oprogramowaniem z innymi i korzystać z niego na próbę, jednak 9

10 dalsze korzystanie wymaga już uiszczenia stosownej opłaty. Jeszcze inny sposób polega na udzieleniu zgody na nieodpłatne korzystanie jedynie do celów osobistych, niekomercyjnych (licencja ograniczona). Wtedy wykroczenie poza zakres licencji skutkuje bądź to jej naruszeniem, bądź zobowiązaniem do wykupienia pełnej licencji. Stosowane są też różne modele mieszane (np. shareware ze zgodą na 30-dniowe testowanie itp.), a pojęcia takie jak shareware bywają różnie rozumiane w praktyce, wobec czego często trudno zaliczyć dane oprogramowanie własnościowe do konkretnej grupy. Jednak w żadnym z omówionych przypadków (sprzedaż oprogramowania własnościowego, freeware, trial, shareware, licencja ograniczona) użytkownik nie uzyskuje tak szerokich uprawnień jak użytkownik wolnego oprogramowania. Tylko użytkownik wolnego oprogramowania może je dowolnie wykorzystywać, modyfikować i rozpowszechniać, i to niezależnie od tego, czy uzyskał je odpłatnie, czy nie. Z punktu widzenia instytucji publicznych kluczowe znaczenie ma zakres uprawnień do oprogramowania, a w tym dostęp do kodu źródłowego i prawo do jego modyfikacji. Wobec tego nie jest specjalnie istotne, w jakim modelu rozpowszechniane jest dane własnościowe oprogramowanie. 1.4 / Licencje wolnego oprogramowania W praktyce może pojawiać się pytanie jak odróżnić oprogramowanie wolne od własnościowego. Jest to często trudne dla laika, zwłaszcza w sytuacji, gdy znajduje program w Internecie (jest to popularny sposób dystrybucji zarówno wolnego oprogramowania jak i freeware). Często też użytkownik może nie mieć świadomości jakie dokładnie oprogramowanie jest mu dostarczane w ramach specjalnie zamówionego systemu (a korzystanie z wolnego oprogramowania jest powszechną praktyką wśród producentów oprogramowania, którzy tworzą na jego bazie całe systemy, na co zresztą wyraźnie pozwalają im stosowne licencje). W takiej sytuacji z pomocą przychodzą informacje publikowane przez organizacje takie jak Free Software Foundation lub Open Source Initiative. Jak już wyjaśniono powyżej, publikują one informacje o tym, które licencje modelowe są zgodne z określonymi definicjami czyli które z nich są licencjami wolnego oprogramowania. Najpopularniejsze licencje to np. GNU General Public License (GPL), GNU Lesser General Public License (LGPL), BSD License, MIT License, Mozilla Public License itd. Istnieje nawet specjalna modelowa licencja opracowana na zlecenie Komisji Europejskiej, zalecana do stosowania dla europejskich projektów informatycznych. Jest to European Union Public License (EUPL). Zatem, w przypadku znalezienia danego programu w Internecie jego status można względnie łatwo sprawdzić porównując treść jego licencji z treścią licencji zaakceptowanych przez Free Software Foundation lub certyfikowanych przez Open Source Initiative licencji modelowych. Z kolei w przypadku oprogramowania dostarczonego na zamówienie, informacji o jego komponentach powinien udzielić producent. Licencje wolnego oprogramowania wymagają bowiem między innymi informowania użytkowników o ich postanowieniach i przekazywania im tekstu licencji. Niektóre z nich wymagają wręcz, aby opracowania wolnego programu były udostępniane na takiej samej licencji (tzw. klauzule copyleft, występujące np. w GPL, LGPL, MPL i innych). Oznacza to, że producent, który zataja przed użytkownikiem infomację o wykorzystanym przez siebie wolnym oprogramowaniu, najprawdopodobniej narusza którąś z licencji. 1.5 / Otwarte standardy Dla wyjaśnienia pojęcia otwarty standard konieczne jest najpierw przybliżenie pojęcia standard. Nie ma jednej oficjalnej definicji tego pojęcia, jednak w analizowanym tu kontekście przez standard rozumie się zwykle wytyczne co do czynności lub efektów tych czynności, które zostały przyjęte w formie dokumentu (specyfikacji) przez uznaną organizację. 10

11 Często w różnych definicjach standardu pojawiają się dodatkowe elementy, takie jak cel standardu (zazwyczaj wskazuje się na uporządkowanie pewnej dziedziny) lub jakość dokumentu (np. możliwość wielokrotnego stosowania zawartych w nim wytycznych). 8 W niniejszym informatorze skupiamy się na standardach teleinformatycznych istotnych dla zapewnienia współdziałania programów komputerowych. Przez standardy rozumiane będą zatem wytyczne co do sposobów wdrażania w oprogramowaniu (1) interfejsów, (2) protokołów, lub (3) formatów danych, ujęte w dokumentach będących wynikiem procedur standaryzacyjnych. Istnieją różne, mniej lub bardziej formalne organizacje standaryzujące, stosujące różne procedury uchwalania standardów. Niektóre z nich są umocowane w różnego rodzaju aktach prawnych (jak np. Polski Komitet Normalizacyjny, działający na podstawie ustawy o normalizacji), a standardy przez nie uchwalane stają się normami. Niektóre organizacje to tylko luźne zrzeszenia przedsiębiorców i innych podmiotów zainteresowanych osiągnięciem współdziałania swojego oprogramowania. Sposób umocowania organizacji standaryzującej decyduje o tym, czy opracowane przez nie standardy są standardami de iure, czy też mają jedynie ewentualną szansę stania się standardami de facto (na skutek upowszechnienia na rynku). Niekiedy można spotkać inne kryterium rozróżnienia standardów de iure i standardów de facto. Niektórzy mianowicie za standardy de iure uznają standardy wskazywane przez prawo jako obowiązujące w danej dziedzinie (niekiedy bowiem standardy są wymagane w przepisach prawa, choć zasadą standaryzacji jest dobrowolność). Standardy de facto są natomiast często rozumiane jako wszelkie rozwiązania, które zyskały rynkową popularność. W takim ujęciu, standardem de facto może być nawet zamknięty protokół, interfejs lub format danych, który nie został poddany procedurze standaryzacyjnej, lecz po prostu jest używany w dominujących na rynku produktach. 8 Por. np. ISO/IEC Guide 2:2004 Standardization and related activities General vocabulary. W celu dokładnego zrozumienia, czym są otwarte standardy, istotne jest jednak traktowanie jako standardu wyłącznie wytycznych powstałych w toku pewnej procedury. Protokoły, interfejsy i formaty danych niepoddane takiej procedurze nie będą zatem uznawane w niniejszym informatorze za standardy, nawet jeżeli cieszą się dużą popularnością. Nie ma jednej, oficjalnej i legalnej definicji otwartego standardu. W różnych opracowaniach przewija się jednak pewien minimalny zestaw wymagań, jakie musi spełniać standard, aby być otwartym standardem. Wskazuje się m.in. na (1) otwartą procedurę uchwalania standardu, (2) publiczną dostępność dobrej jakości specyfikacji oraz (3) możliwość skorzystania z praw wyłącznych ewentualnie związanych ze standardem bez dyskryminujących ograniczeń. Standard, który nie spełnia tych wszystkich wymagań jednocześnie, jest standardem zamkniętym. Dla powstania otwartego standardu nie wystarczy zatem jakakolwiek procedura standaryzacyjna. Musi być ona odpowiednio zorganizowana, w tym powinna istnieć możliwość uczestniczenia w niej każdego zainteresowanego podmiotu. Taki pluralizm umożliwi bowiem uwzględnienie jak największej liczby rozmaitych interesów, co przekłada się na łatwiejsze wdrożenie standardu w różnych programach. Ponadto, specyfikacja otwartego standardu powinna być nie tylko dostępna publicznie, lecz również powinna zawierać jak najwięcej wysokiej jakości informacji. Jakość tej informacji wpływa bowiem również na łatwość wdrożenia standardu oraz na liczebność producentów oprogramowania, którzy będą mogli go wdrożyć. Wreszcie, poza samą dostępnością informacji, jej wykorzystanie nie powinno podlegać żadnym ograniczeniom. Oprócz wskazanych już wcześniej patentów związanych ze standardem, źródłem takich ograniczeń może być też np. prawo autorskie lub tajemnica przedsiębiorstwa. Żadne z tych uprawnień nie może być zatem wykorzystane w celu ograniczania możliwości wyprodukowania oprogramowania zgodnego z otwartym standardem. 11

12 Im więcej ograniczeń w korzystaniu ze specyfikacji standardów, tym mniej producentów może wykorzystać dany standard w swoim oprogramowaniu. Otwarte standardy pociągają za sobą jedynie minimalne ograniczenia, które nie mają charakteru dyskryminującego. Dzięki temu otwarte standardy mogą być wdrażane zarówno przez producentów własnościowego, jak i wolnego oprogramowania. Zamknięte standardy natomiast działają poprawnie zazwyczaj jedynie we własnościowym oprogramowaniu, a bardzo często dany zamknięty standard jest wdrożony w zadowalającym stopniu tylko w oprogramowaniu jednego producenta. Standard nie powinien być mylony z oprogramowaniem, które stanowi jego wdrożenie (implementację). Specyfikacja standardu zawiera wytyczne dla producenta oprogramowania, sama nie jest jednak programem (choć często specyfikacjom towarzyszą przykładowe lub wzorcowe implementacje, celem ułatwienia zadania osobom chcącym opracować własne implementacje). Warto pamiętać o tym istotnym rozróżnieniu zwłaszcza z uwagi na fakt, że często otwarte standardy są mylnie utożsamiane z wolnym oprogramowaniem. Powodem może być tu podobieństwo brzmienia anglojęzycznych zwrotów open standards i open source. Nie jest to jednak to samo, a otwarte standardy (open standards) mogą być wdrożone (implementowane) zarówno w wolnym oprogramowaniu (free software, open source software), jak i w oprogramowaniu własnościowym. 12

13 2 / Przepisy dotyczące zamówień publicznych na oprogramowanie W niniejszej części informatora omawiamy podstawowe przepisy i wynikające z nich normy prawne dotyczące zamówień publicznych na oprogramowanie. Są to: (1) konstytucyjna zasada równości, (2) ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne, (3) prawo zamówień publicznych. 2.1 / Konstytucyjna zasada równości i jej znaczenie dla informatyzacji Zasada równości została wyrażona w art. 32 Konstytucji RP, zgodnie z którym: 1. Wszyscy są wobec prawa równi. Wszyscy mają prawo do równego traktowania przez władze publiczne. 2. Nikt nie może być dyskryminowany w życiu politycznym, społecznym lub gospodarczym z jakiejkolwiek przyczyny. 13 Przepis ten był wielokrotnie stosowany przez Trybunał Konstytucyjny, który precyzował, że zasada równości to nakaz równego traktowania wszystkich podmiotów charakteryzujących się w równym stopniu daną cechą istotną. Zatem w poszukiwaniu wytycznych dla zamówień publicznych na oprogramowanie wynikających z zasady równości należy ustalić takie istotne cechy. Cechy te stanowią kryterium wyróżnienia grupy lub grup podmiotów, które muszą być w ramach swojej grupy równo traktowane. Następnie będzie można ustalić w jaki sposób zamówienie takiego lub innego oprogramowania sprawia, że podmioty te doznają różnego traktowania (dyskryminacji) pomimo faktu, że w równym stopniu wykazują się daną cechą istotną. Takie dyskryminujące zamówienia muszą zostać wyeliminowane, jako naruszające konstytucyjną zasadę równości.

14 W kontekście informatyzacji istnieją co najmniej dwie cechy istotne, pozwalające wyróżnić dwie grupy podmiotów. Grupy te to: (1) dostawcy oprogramowania oraz (2) użytkownicy. Cechą istotną pozwalającą umieścić dostawców oprogramowania w jednej grupie jest konkurowanie na danym rynku właściwym. Jest to np. rynek oprogramowania dla podmiotów realizujących zadania publiczne, ale też i rynek oprogramowania dla podmiotów korzystających z usług świadczonych przez władze publiczne (w tym dla obywateli i przedsiębiorców). Natomiast cechą istotną podmiotów należących do grupy użytkowników jest korzystanie z danej usługi oferowanej przez organy władzy publicznej. Do tej grupy należą, zależnie od usługi, obywatele (A2C), przedsiębiorcy (A2B), ale często też i same organy władzy publicznej (A2A). Ad 1. Nie jest dopuszczalne takie przeprowadzanie zamówień na oprogramowanie, które prowadziłoby do dyskryminacji jakiegokolwiek dostawcy oprogramowania konkurującego na danym rynku. Nie oznacza to oczywiście, że organy władzy publicznej nie mogą wybrać konkretnego programu spośród wielu ofert. Jasne jest, że dla danego zamówienia zamawiający musi wybrać jednego spośród wielu dostawców (ew. kilku działających wspólnie). Co więcej, w celu dokonania takiego wyboru zamawiający może i wręcz powinien formułować w stosunku do dostawców i ich ofert mniej lub bardziej szczegółowe wymagania. Istotne jest jednak, aby nie były to wymagania dyskryminujące. Zamawiający nie może zatem stawiać dostawcom wymagań, które zdolni są spełnić tylko niektórzy z nich, a które nie są obiektywnie uzasadnione. Przykładowo, do obiektywnie uzasadnionych wymagań można zaliczyć dysponowanie przez dostawcę odpowiednim zabezpieczeniem finansowym, wiedzą lub doświadczeniem. Ale nawet i te cechy muszą być istotne z punktu widzenia zasługujących na ochronę interesów zamawiającego. Obiektywnie uzasadnione w określonych przypadkach może być też wymaganie, aby dostawca udzielił urzędowi do oprogramowania szerokiej licencji, pozwalającej nie tylko na korzystanie z niego, ale też na rozpowszechnianie i dokonywanie modyfikacji. Będzie tak zwłaszcza w przypadku zamawiania systemów o kluczowym znaczeniu, co do których zamawiający powinien mieć pełną kontrolę oraz swobodę modyfikacji. Prawo do rozpowszechniania może być istotne w sytuacji, w której z oprogramowania będą musiały korzystać inne podmioty inne urzędy lub obywatele. Uzyskanie takiego prawa pozwoli w szczególności ograniczyć wydatki w przypadku konieczności zamówienia takiego samego programu przez wiele organów władzy publicznej (np. przez wszystkie gminy). Nie jest natomiast obiektywnie uzasadnione formułowanie przez organy władzy publicznej wymagań, które wykluczałyby z góry dostawców wolnego oprogramowania. Jak bowiem wyjaśniono już wcześniej, wolne oprogramowanie różni się od oprogramowania własnościowego szerszym zakresem uprawnień użytkownika. Nie ma jednak obiektywnych powodów, dla których nie mogłoby ono realizować takich samych lub podobnych funkcjonalności. Oznacza to, że zamawiający nie może odmówić wyboru wolnego oprogramowania tylko dlatego, że jest to wolne oprogramowanie. Zamawiający nie może też żądać, aby dostarczone mu oprogramowanie było oprogramowaniem własnościowym. Ad 2. Z punktu widzenia konstytucyjnej zasady równości nie jest dopuszczalne, aby organy władzy publicznej zamówiły oprogramowanie, którego działanie spowoduje, że niektórzy użytkownicy usług świadczonych przez te organy będą dyskryminowani w porównaniu do innych użytkowników. Do takiej dyskryminacji dojdzie, jeżeli niektórzy użytkownicy zostaną zmuszeni do korzystania z określonego oprogramowania bez obiektywnego uzasadnienia. Wymaganie takie niezwykle rzadko można uznać za obiektywnie uzasadnione, gdyż w zasadzie nie ma zadania, dla którego poprawnego zrealizowania wymagane jest korzystanie z konkretnego programu. Różni użytkownicy realizują takie same lub podobne zadania na różne sposoby, wybierając takie oprogramowanie, które najlepiej odpowiada ich potrzebom. Zasada równości zapewnia prawną gwarancję takiej swobody wyboru, bo poszanowanie różnorodności jest jedną z podstaw demokracji. 14

15 Z tego punktu widzenia niezwykle istotne jest, aby organy władzy publicznej nie przyczyniały się do ograniczania swobody wyboru użytkowników. W tym celu muszą one zamawiać oprogramowanie zdolne do współdziałania z różnego rodzaju programami dostępnymi na rynku, a nie tylko z niektórymi takimi programami. Innymi słowy, organy władzy publicznej zobowiązane są do formułowania zamówień, których skutki będą neutralne technologicznie. Sposobem na osiągnięcie tego celu jest wymaganie, aby zamawiane programy były zdolne do współdziałania z innym oprogramowaniem (w tym oprogramowaniem obywateli, przedsiębiorców i innych usługobiorców organów władzy publicznej) w oparciu o otwarte standardy. Jak bowiem wynika z wcześniejszych wyjaśnień, zamknięte standardy (jak też i zamknięte protokoły, interfejsy i formaty danych) mogą być wykorzystywane do współdziałania tylko niektórych programów (zwykle tylko określonych programów własnościowych). Zatem wymaganie zgodnościz zamkniętymi rozwiązaniami ogranicza różnorodność, mimo że możliwe jest realizowanie zadań publicznych bez jej ograniczania. Tym samym stanowi to nieuzasadnioną dyskryminację prowadzącą do naruszeń konstytucyjnej zasady równości. Zamawiające oprogramowanie organy władzy publicznej powinny wobec tego wymagać, aby było ono zdolne do współdziałania z innymi programami w oparciu o otwarte standardy. Tylko wtedy bowiem realizacja zamówienia nie doprowadzi do sytuacji, w której w sposób dyskryminujący zostanie ograniczona swoboda wyboru, rynkowa konkurencja oraz różnorodność, a w konsekwencji konstytucyjna zasada równości. Pobieżna analiza powyższych rozważań może sugerować istnienie następującego paradoksu. Mianowicie, organy władzy publicznej są zobowiązane nie dyskryminować ani dostawców oprogramowania, ani użytkowników. Najlepszym sposobem na uniknięcie nieuzasadnionej dyskryminacji użytkowników jest wymaganie, aby oprogramowanie dostarczane przez dostawców było zdolne do współdziałania w oparciu o otwarte standardy. Pojawia się zatem pytanie, czy takie wymaganie nie prowadzi jednak do dyskryminacji pewnej grupy dostawców. Chodzi mianowicie o tych dostawców, którzy nie wprowadzają do swojego oprogramowania funkcji umożliwiających mu współdziałanie za pomocą otwartych standardów. Paradoks jest jednak tylko pozorny, gdyż takie wymaganie nie stanowi dyskryminacji tych dostawców, a tym samym nie stanowi naruszenia zasady równości. Wymaganie, aby oprogramowanie zamawiane przez organy władzy publicznej było zdolne do współdziałania w oparciu o otwarte standardy jest obiektywnie uzasadnione z wielu powodów. Po pierwsze, jest to najlepszy sposób na uniknięcie dyskryminacji użytkowników (co wyjaśniono powyżej). Po drugie, jeżeli w ogóle doprowadzi ono do wykluczenia jakiegokolwiek dostawcy, to będzie to wynikiem decyzji samego tego dostawcy. Jest tak przede wszystkim dlatego, że otwarte standardy z definicji mogą być bez większych przeszkód wdrożone zarówno przez dostawców własnościowego oprogramowania, jak i dostawców wolnego oprogramowania. Taką możliwość gwarantują warunki otwartości standardu (otwarta procedura, dostępność specyfikacji i ich wysoka jakość, niedyskryminujące licencje na prawa wyłączne związane z otwartymi standardami). Każdy dostawca ma wobec tego realną możliwość opracowania i oferowania oprogramowania zdolnego do ich obsługi. Podmioty, które zdecydują się nie skorzystać z tej możliwości nie mogą powoływać się na naruszenie konstytucyjnej zasady równości. W przeciwnym bowiem wypadku, za naruszenie tej zasady trzeba by uznawać stawianie przez państwo jakichkolwiek wymagań (jak np. wykazanie się wiedzą i umiejętnościami w celu zdania egzaminu na prawo jazdy). Zawsze znajdzie się przecież podmiot, który z własnej woli decyduje się nie spełnić obiektywnie uzasadnionych wymagań nawet, gdy ma on realną możliwość ich wypełnienia. Dodatkowego argumentu na poparcie powyższego wywodu dostarcza analiza skutków sytuacji przeciwnej. Otóż, w przypadku zaniechania przez organ władzy publicznej wymagania, aby dostarczane mu oprogramowanie było zdolne do współdziałania w oparciu o otwarte standardy 15

16 istnieje duże prawdopodobieństwo, że do

17 istnieje duże prawdopodobieństwo, że dostarczone oprogramowanie będzie współdziałało w sposób prawidłowy jedynie za pomocą zamkniętych rozwiązań. Dojdzie wtedy do uzależnienia zamawiającego od jednego dostawcy (ang. vendor lock-in). 9 Jeżeli bowiem uda się danemu dostawcy wprowadzić do organu własne, zamknięte i kontrolowane przez siebie oprogramowanie, to zyska on wtedy niemal pewność, że kolejne zamówienia będą musiały zostać udzielone tylko jemu (być może nawet w trybie wolnej ręki). Jeżeli to oprogramowanie będzie wykorzystywane do współdziałania z oprogramowaniem innych użytkowników (np. obywateli, przedsiębiorców), to taki dostawca uzyska dodatkowo istotną gwarancję, że oni również będą musieli nabywać swoje oprogramowanie od niego. Uzależnienie od jednego dostawcy jest jaskrawym przykładem praktycznego wykluczenia pozostałych dostawców z możliwości konkurowania. Ogranicza ono też radykalnie swobodę wyboru rozwiązań zdolnych do współdziałania, jaką mieliby użytkownicy, gdyby organ władzy publicznej wymagał od zamawianego oprogramowania zdolności do współdziałania w oparciu o otwarte standardy. Innymi słowy, przez zaniechanie takiego wymagania dochodzi do naruszenia zasady równości. Naruszenie to dotyka zarówno dostawców, jak i użytkowników. Rozmiar tego naruszenia jest kolejnym argumentem na rzecz istnienia prawnego obowiązku organów władzy publicznej do wymagania od zamawianego oprogramowania zdolności do współdziałania w oparciu o otwarte standardy. W celu uniknięcia nieporozumień warto podkreślić, że nie jest to tożsame z zakazem nabywania przez organy władzy publicznej oprogramowania własnościowego, ani też 9 Pewną odmianą takiego uzależnienia jest uzależnienie się od określonego produktu, który może mieć różnych dostawców. Są to w takim przypadku dystrybutorzy autoryzowani przez producenta tego produktu. Często konkurują oni między sobą wysokością marży, jaką realizują na nabywanych od producenta produktach. Niemniej jednak wybór pomiędzy nimi jest tylko pozornie zachowaniem konkurencji, skoro niezależnie od tego wyboru wygrywającym jest zawsze jeden i ten sam producent, a pozostali producenci są faktycznie wykluczeni z możliwości ubiegania się o zamówienie. oprogramowania, które będzie dodatkowo obsługiwało jakieś zamknięte rozwiązania (np. takie, od których organ władzy publicznej wcześniej się uzależnił lub takie, które są popularne na rynku). Jak to bowiem wyjaśniono wcześniej, otwarte standardy mogą być wdrożone zarówno w wolnym, jak i we własnościowym oprogramowaniu. W szczególności, producent danego własnościowego programu obsługującego jego własne, zamknięte rozwiązanie może rozszerzyć jego funkcjonalność poprzez dodanie w programie obsługi otwartego standardu. Wobec powyższego, trudno znaleźć podmiot, który byłby dyskryminowany poprzez wymaganie zdolności do współdziałania w oparciu o otwarte standardy. Dyskryminacja taka wystąpi z dużym prawdopodobieństwem w sytuacji przeciwnej: zaniechania takiego wymagania lub wyraźnego wymagania zdolności do współdziałania wyłącznie w oparciu o zamknięte rozwiązania. Organy władzy publicznej powinny zatem wymagać od dostawców zamawianego przez siebie oprogramowania, aby było ono zdolne do współdziałania w oparciu o otwarte standardy. 2.2 / Ustawa o informatyzacji Istotne dodatkowe wytyczne co do tego, jakie oprogramowanie powinno być zamawiane przez organy władzy publicznej, zawiera ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne. Ustawa ta nie stosuje się do wszystkich organów władzy publicznej, lecz jedynie do tych, które wymienione są w jej art. 2 ust. 1 (zwanych podmiotami publicznymi). Pewne podmioty zostały wyraźnie wyłączone spod działania tej ustawy (ich listę zawiera art. 2 ust. 3) z tym jednak zastrzeżeniem, że stosuje się do nich art. 13 ust. 2 pkt 1 (w przypadku gdy w związku z realizacją zadań przez te podmioty istnieje obowiązek przekazywania informacji do i od podmiotów niebędących organami administracji rządowej). Z punktu widzenia niniejszego informatora istotny jest cały art. 13 ustawy. Ust. 1 tego 17

18 przepisu zobowiązuje podmioty publiczne do używania w celu realizacji zadań publicznych systemów teleinformatycznych spełniających minimalne wymagania dla systemów teleinformatycznych. Te minimalne wymagania zostały ujęte w stosownym rozporządzeniu i są to wskazane z nazwy protokoły i formaty danych, które muszą być obsługiwane przez systemy teleinformatyczne wykorzystywane przez podmioty publiczne. Wobec tego, dokonując zamówienia na oprogramowanie podmiot publiczny powinien wymagać, aby spełniało ono odpowiednie minimalne wymagania. Co istotne, niektóre formaty zostały wskazane w rozporządzeniu jako formaty tylko do odczytu. Wystarczające jest zatem, jeżeli zamawiane oprogramowanie jest zdolne do odczytania takiego formatu. Nie trzeba wymagać, aby potrafiło ono również zapisywać dokumenty w tym formacie, jeżeli taka funkcjonalność nie jest uzasadniona obiektywnymi potrzebami zamawiającego. Zgodnie z art. 1 pkt 2, celem minimalnych wymagań jest gwarancja otwartości standardów informatycznych. Jest to istotna wskazówka interpretacyjna uzupełniająca wcześniejszy wywód o konstytucyjnej zasadzie równości. Mianowicie, ustawa o informatyzacji potwierdza istnienie zobowiązania podmiotów publicznych do wymagania, aby dostarczane im oprogramowanie było zdolne do współdziałania za pomocą otwartych standardów. W tym celu podmioty te są zobowiązane wymagać zgodności z tymi minimalnymi wymaganiami, które są otwartymi standardami. Ponadto nie mogą one formułować dodatkowych wymagań, które doprowadziłyby do niezdolności zamawianego przez nie oprogramowania do współdziałania w oparciu o otwarte standardy. Pewne wątpliwości budzi fakt, że rozporządzenie o minimalnych wymaganiach wymienia nie tylko otwarte, lecz również i zamknięte standardy. Prowadzi to do pytań o zgodność rozporządzenia z ustawą (wymagającą gwarancji otwartości standardów) oraz z Konstytucją (wymagającą, aby zamawiane oprogramowanie było zdolne do współdziałania w oparciu o otwarte standardy). Należy zatem interpretować przepisy rozporządzenia jako zezwalające na dopuszczenie zamkniętych standardów jako uzupełniającej funkcjonalności zamawianego przez podmioty publiczne oprogramowania. Zdolność do współdziałania w oparciu o standardy otwarte musi być jednak zawsze zapewniona. Art. 13 ust. 2 rozszerza obowiązki podmiotów publicznych dokonujących zamówień oprogramowania w sytuacji, w której dochodzi do przekazywania danych pomiędzy podmiotem publicznym a podmiotem niebędącym organem administracji rządowej. Chodzi tu o komunikację z obywatelami, przedsiębiorcami i niektórymi innymi odbiorcami usług świadczonych przez podmioty publiczne (w tym również o komunikację podmiotów publicznych z podmiotami nienależącymi do administracji rządowej samorządami, sądami itp.). Konieczne jest wtedy łączne spełnienie dwóch dodatkowych wymagań: 1. podmiot publiczny musi zapewnić, aby system teleinformatyczny (poza minimalnymi wymaganiami) spełniał wymóg równego traktowania rozwiązań informatycznych; 2. podmiot publiczny musi opublikować w BIP zestawienie struktur dokumentów, formatów danych oraz protokołów komunikacyjnych i szyfrujących, a także testy akceptacyjne (uregulowane w innych przepisach ustawy). Pozostałe ustępy art. 13 precyzują szczegóły wykonania obowiązków ujętych w art. 13 ust. 2. Wymóg równego traktowania rozwiązań informatycznych, oprócz minimalnych wymagań dla systemów teleinformatycznych ujętych w rozporządzeniu jest szczególnie istotny z punktu widzenia niniejszego informatora. Stanowi on kolejne podkreślenie wynikającego z Konstytucji obowiązku podmiotów publicznych do działania tak, aby nie dochodziło do ograniczenia swobody wyboru, konkurencji oraz różnorodności rozwiązań funkcjonujących na rynku. Obowiązek ten jest szczególnie istotny w sytuacji opisanej w art. 13 ust. 2, czyli komunikacji pomiędzy podmiotem publicznym a podmio- 18

19 tem niebędącym organem administracji rządowej (obywatelem, przedsiębiorcą, samorządem lub innym podmiotem wyposażonym przez prawo w istotny zakres autonomii). Wymaganie, aby podmiot taki musiał komunikować się z podmiotem publicznym za pomocą zamkniętych standardów prowadziłoby de facto do ograniczenia autonomii tego podmiotu na rzecz podmiotu, który kontroluje dane zamknięte rozwiązanie. Innymi słowy, konkretny podmiot prywatny mógłby decydować o tym, w jaki sposób inny podmiot prywatny może realizować swoje publicznoprawne uprawnienia i obowiązki. Jest to sytuacja niedopuszczalna w demokratycznym państwie prawnym i wobec tego została wyraźnie zakazana. Omawiana ustawa zawiera również szereg innych wymagań, m.in. dotyczących rejestrów publicznych i prowadzenia wymiany informacji. Nie dotyczą one bezpośrednio kwestii zamawiania oprogramowania, jednak niekiedy mogą one wpłynąć na kształt takich zamówień. Z uwagi na ogólny charakter niniejszego informatora nie będą one tu omówione. W czasie przygotowywania niniejszej broszury Sejm pracuje nad nowelizacją ustawy o informatyzacji. Najistotniejsze propozycje zmian (z omawianego tu punktu widzenia) to wprowadzenie definicji neutralności technologicznej oraz dokumentu nazwanego Krajowymi Ramami Interoperacyjności (KRI). Komisja Europejska prowadzi również prace nad Europejskimi Ramami Interoperacyjności (ERI), które najprawdopodobniej uzyskają status niewiążących rekomendacji, choć mimo to o istotnym znaczeniu praktycznym. Wynikiem nowelizacji ustawy o informatyzacji oraz wprowadzenia KRI i ERI, w zależności od ostatecznego kształtu tych dokumentów, może być uzupełnienie omówionych tu wymagań o kolejne wymagania, jakie muszą zapewnić podmioty publiczne, dokonując zamówień oprogramowania. Co istotne, nowelizacja ustawy, ani tym bardziej akty podstawowe lub rekomendacje Unii Europejskiej nie mogą wpłynąć na obowiązki wynikające z norm o randze konstytucyjnej, takich jak omówiona wcześniej zasada równości. 2.3 / Prawo zamówień publicznych Dodatkowe szczegółowe wytyczne dla organów władzy publicznej zamawiających oprogramowanie zawierają przepisy ustawy Prawo zamówień publicznych. W zakresie istotnym z punktu widzenia niniejszego informatora chodzi tu o art. 7 ust. 1, art. 29 ust. 2 i 3, oraz art. 30 tej ustawy. Art. 7 ust. 1 odnosi się do wszystkich aspektów postępowań o udzielenie zamówienia, w tym do formułowania opisów zamawianych przedmiotów. Zobowiązuje on zamawiających do przygotowywania i przeprowadzania tych postępowań w sposób zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców. Nawiązuje on do omówionej wcześniej konstytucyjnej zasady równości i może być traktowany jako jej doprecyzowanie w kontekście zamówień publicznych. Jak wskazuje doktryna, wymaga on, aby zamawiający traktowali na równi podmioty ubiegające się o zamówienie publiczne przez zaniechanie m.in. wskazania warunków lub kryteriów preferujących niektóre podmioty. 10 Niedopuszczalne jest w związku z tym określenie warunków udziału w postępowaniu w sposób utrudniający bądź uniemożliwiający udział zainteresowanych podmiotów. 11 Art. 29 ust. 2 i 3 dotyczą już bezpośrednio sposobu opisu przedmiotu zamówienia. Pierwszy z nich zakazuje opisywania przedmiotu zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję. Jak jednak słusznie wskazano w orzecznictwie: prawie nigdy nie jest możliwe ( ) opisanie przedmiotu zamówienia, który w ten czy w inny sposób nie [uniemożliwi] części wykonawców w ogóle złożenie oferty, a niektórych [postawi] w uprzywilejowanej pozycji. Warunkiem nienaruszania konkurencji jest w takim przypadku brak uniemożliwiania z góry niektórym podmiotom udziału w postępo- 10 Paweł Granecki, Prawo zamówień publicznych. Komentarz, C.H. Beck 2007, s Paweł Granecki, Prawo zamówień publicznych. Komentarz, C.H. Beck 2007, s

20 waniu bez uzasadnienia w obiektywnych potrzebach i interesach zamawiającego oraz brak sytuacji, w której uprzywilejowanie danych wykonawców osiągnie rozmiary faktycznie przekreślające jakąkolwiek konkurencję. 12 Wszelkie wymagania muszą być zatem uzasadnione rzeczywistymi (obiektywnymi) potrzebami zamawiającego. Tylko bowiem takie potrzeby mogą prowadzić do ograniczenia kręgu potencjalnych dostawców w sposób zgodny z prawem. 13 Istotnie, zobiektywizowane potrzeby pozwalają zamawiającym nawet na takie opisanie przedmiotu zamówienia, które spowoduje, że tylko jeden dostawca może je wykonać. 14 Muszą to być jednak potrzeby obiektywne, gdyż formułowanie rygorystycznych wymagań bez uzasadnienia stanowi zakazaną omawianymi przepisami dyskryminację. 15 Art. 29 ust. 2 nie zakazuje zatem zamawiającemu uwzględniać przy formułowaniu opisu przedmiotu zamówienia własnych potrzeb. Możliwe jest też formułowanie wymagań dla zamawianego przedmiotu, których spełnienie będzie trudne, o ile tylko wymogi te będą obiektywnie uzasadnione. Naruszenie tego przepisu wystąpi jednak w sytuacji, gdy zamawiający wskaże konkretny produkt z góry eliminując w ten sposób dostawców innych produktów zdolnych spełnić obiektywnie uzasadnione potrzeby zamawiającego. 16 Zamawiający po- 12 Wyrok Krajowej Izby Odwoławczej z 28 maja 2009 r. (KIO/UZP 641/09, KIO/UZO 646/09). 13 Wyrok Krajowej Izby Odwoławczej z 5 sierpnia 2009 r. (KIO/UZP 961/09). 14 Wyrok Krajowej Izby Odwoławczej z 12 maja 2009 r. (KIO/UZP 547/09). 15 Wyrok Krajowej Izby Odwoławczej z 13 stycznia 2009 r. (KIO/UZP 1502/08). 16 Z tego punktu widzenia istotne są przepisy dopuszczające udzielenie zamówienia z wolnej ręki (art. 67 ust. 1 pkt 1 lit. a). Przepisy te stanowią wyjątek od zasady zachowania konkurencji, jednak ich stosowanie jest dopuszczone wyłącznie po spełnieniu rygorystycznych kryteriów. Zamawiający musi m.in. ustalić, że obiektywnie rzecz biorąc istnieje tylko jeden wykonawca danego zamówienia. Wystarcza zatem, aby na danym rynku funkcjonowało dwóch wykonawców zdolnych wykonać takie zamówienie, aby udzielenie zamówienia z wolnej ręki było wyłączone (Uchwała Krajowej Izby Odwoławczej z dnia 28 września 2008 r., KIO/KU 5/08). Co istotne, przepisy dotyczące wolnej ręki zostały poddane ostatnio istotnej nowelizacji, zgodnie z którą wykorzystanie tego trybu będzie podlegało dalej idącym ograniczeniom. winni bowiem opisywać przedmioty zamówień wskazując ich cechy, których spełnienie jest dla zamawiających kluczowe z punktu widzenia ich potrzeb. Co istotne, art. 29 ust. 2 musi być interpretowany zgodnie z Konstytucją, czyli m.in. tak, aby nie doszło do naruszeń zasady równości w sposób opisany powyżej. Innymi słowy, zapewnienie zgodności z tą zasadą będzie zawsze obiektywną i uzasadnioną potrzebą zamawiającego, któej uwzględnienie przy opisie przedmiotu zamówienia nie będzie prowadzić do naruszenia art. 29 ust. 2. Natomiast formułowanie wymagań w taki sposób, że może je spełnić tylko konkretne oprogramowanie własnościowe lub wręcz konkretny wskazany z nazwy program nie może być uznane za uzasadnione obiektywnymi i rzeczywistymi potrzebami producenta. Przecież o ile tylko potrzeby zamawiającego są dobrze opisane, to w zasadzie każdy producent może napisać oprogramowanie zdolne zaspokoić te potrzeby. Zaniechanie przez zamawiającego prawidłowego wyartykułowania własnych potrzeb nie stanowi wystarczającego uzasadnienia dla odstąpienia od stosowania przepisów Prawa zamówień publicznych. Jak jednak wiadomo, zamknięte protokoły, interfejsy oraz formaty danych, jak również i zamknięte standardy, często mogą być wdrożone poprawnie jedynie przez niektórych producentów oprogramowania. Wobec omówionych wcześniej wytycznych wynikających z konstytucyjnej zasady równości, zamawiający nie mogą zamawiać oprogramowania, które byłoby zdolne do współdziałania tylko w oparciu o takie zamknięte rozwiązania. Niemniej jednak, w praktyce występują sytuacje, w których zamawiający już dysponuje oprogramowaniem zdolnym do współdziałania jedynie w oparciu o zamknięte rozwiązania, a ponadto nie nabył do niego uprawnień pozwalających na jego dostosowanie do standardów otwartych (opisane już powyżej vendor lock-in). W takiej sytuacji może być ważne dla zamawiającego, aby zamawiane oprogramowanie było zdolne do współdziałania z już posiadanym przez zamawiającego oprogramowaniem właśnie za pomocą zamkniętych rozwiązań. 20