Avatud tarkvara juurutamise seaduseelnõud ei võetud vastu
Delfi kirjutab:
Riigikogus arutluse all olnud seaduseelnõu avatud lähtekoodiga tarkvara tõhusamaks juurutamiseks riigisektoris “Abinõud riigi infotehnoloogia kulutuste vähendamiseks ja infotehnoloogilise innovatsiooni soodustamiseks” lükati valitsuse vastuseisu tõttu tagasi.
Kohal oli 88 saadikut, vastu hääletas 42 ja poolt 7 (rohelised + Silver Meikar reformierakonnast).
16. detsembri hommik möödus riigikogus väga vastuoluliselt. Riigikogujate tööpäev hakkas pihta peaministri ettekande ja aruteluga teadus- ja arendustegevuse üle, kus leiti, et juba järgmine aasta on jõuavad riigieelarvest tehtud kulutused teadus- ja arendustegevusele 1,5 protsendi piirimaile SKP-st ja aastaks 2014 kuni 3 protsendini. Leiti, et seadus ja arendustegevus on Eesti majanduse jätkusuutlikkuse jaoks esmatähtsad, seda tuleb eelisfinantseerida.
Kui riigikogu ette jõudis rohelise erakonna ettepanek avatud lähtekoodiga tarkvara laiemast kasutamisest avalikus sektoris, siis oli riigikogujate uutele väljakutsetele ja innovatsioonile avatud meelsus kadunud.
Esitatud seaduseprojekti vastu leiti põhjendusi nagu „jalgratast pole mõtet ise leiutada“ (Hannes Astok) ja „Eestis pole mõtet maisi kasvatada“ (Taavi Rõivas). Samuti spekuleeriti toote elutsükli maksumuse (TCO, Total Cost of Ownership) ning väidetava avatud lähtekoodiga tarkvara koostöövõimetuse (Astok) üle.
Lisaks hirmutas Astok riigikogulasi vabavara töökindlusetusega: „Me võime saada odava asja, me võime saada mõne asja tasuta, aga kui see kokkuvõttes osutub kallimaks või, mis veel hullem, mittetöötavaks, siis me ei ole oma ülesannet nii või teisiti lahendanud“.
Eelnõule avaldas vastuseisu ka majanduskomisjonile saadetud kirjas suuremaid telekommunikatsiooni- ja infotehnoloogiaettevõtteid koondav Eesti Infotehnoloogia ja Telekommunikatsiooni Liit.
Istungi stenogrammi saab lugeda riigikogu kodulehelt. Eriti väärivad lugemist Hannes Astoki “pärlid”, mis võivad vähegi IT teadmisega inimese lihtsalt ahastusest käsi ringutama ja suuri kuumi pisaraid valama panna. Kurb, kui meie riigi IT poliitika üle otsustavad sellised “asjatundjad”. Eriti veel, kui nende asjatundjate nn argumentidest kumavad väga selgelt läbi teatud, M$ lühendiga tähistatava korporatsiooni ja selle edasimüüjate huvid.
Väga kurb, et see seaduseelnõu tagasi lükati, aga küll rohelised tulevad tagasi ja juba tugevamalt argumenteeritud vastuväidetega stagnantitele, kes on M$’i poolt lihtsalt ära ostetud.
Saagu sellest eelnõust mis saagu, aga oodanuks samuti asjalikku debatti – ka roheliste poolt oli asi põhjalikult läbimõtlemata ja argumenteerimata. Olemata ühe või teise “partei” pooldaja, võiks öelda, et praktiliselt debatti polnudki (äärmiselt nõrk). Räägiti mingist müstilisest tarkvarast, täpsustamata ikkagi, millises rakendusvaldkonnas. Lisaks aeti tihti segi tööriist ja tulem – tarkvara versus tulem-fail (see Astoki Hiina näide oli hea). Lõpupoole hakkas vesi selginema, aga siis sai aeg otsa.
St kas kommertskontoritarkvara versus avatud lähtekoodil tarkvara või kommertsplatvormil infosüsteem versus vabal platvormil infosüsteem. Mõlemal juhul pole täna selle kasutuselevõtuks reaalset takistust olnud ja seda on ka tehtud. Kontoritarkvara poolelt seesama Keskkonnaministeerium ja ka Andmekaitse Inspektsioon. Infosüsteemide poolelt enamik veebilehti (mis on juba selline kergemat sorti infosüsteem) ongi ju klassikalisel LAMP platvormil. Siiski ei saa 100% nõus olla, et kõik infosüsteemid peavad olema ainult avatud lähtekoodil põhinevad. Süsteeme, kuhu on vaja juurutada kõrged turvanõuded, on äärmiselt kulukas nullist üles ehitada. Oluliselt soodsam on seda kulu jagada ehk kasutada (kommerts)valmiskomponente. Ja loomulikult ei hakka keegi olemasolevaid süsteeme sellepärast ümber ehitama, et täita mingit reeglit.
Kui rääkida veel avatud lähtekoodist, siis siinsed vaba tarkvara arendajad on ehitanud süsteeme oma koostatud platvormile. Tõsilugu on see, et see platvorm on puhtalt arendaja enda tegemine-teadmine (dokumenteerimise tasemega on nagu on, see isegi ei määra – tihti küsimus põhimõtteline). Keegi teine arendaja ei ole tõenäoliselt huvitatud selle arenduse jätkamisest, mis viib lõpuks kliendi ikkagi hullemini arendaja pantvangiks. Kommertsplatvormide (J2EE, .NET jms) puhul leitakse teine arendaja, kes on võimeline jätkama enam-vähem sealt, kus üks pooleli jäi (vähemalt ei tule alusplatvormi ringi ehitada). Eestis on selles osas mitu näidet olemas kommertsi poolelt, vaba tarkvara poolelt tean pigem negatiivseid näited (oma nahalt). Teine pool on selles, et avatud lähtekoodil olevad komponendid on ka tihtipeale kontrollimatu päritoluga ja “avalike vigadega”, mis küll võivad saada parandatud mingi aja jooksul. Seni püsivad vead üleval (ka turvariskid) ja tähendades samas ka hiljem (kohati kapitaalselt) muu koodi kaasaaitamist (nt klassikalised PHP turvaaugud jms). Ehk siis Astoki TCO on tegelikult õige vaade – nii IT-juhti kui tippjuhte huvitab see, mitte asjade “odavalt käimaajamine”.
Selle teemaga haakub väga hästi järgmine Hr Tineke Egyedi avalik kiri:
Who pays for interoperability in public IT procurement?
A public letter to the IT industry about document format standards
Delft, 16 November 2008
It is not uncommon for governments to voluntarily head for vendor
lock-in[1]. As a citizen, however, I have a direct stake in my
government basing its public procurement of IT on open standards. This
stake may be most evident for ‘civil ICT standards’ (Andy Updegrove),
i.e., for standards that support access to government information and
exchanges with government such as document formats[2] (e.g.,
sustainable digital data). However, I also have a standards-related
stake in IT procured for government-internal processes because, first,
in practice government-internal and –external IT processes cannot be
separated[3]. Second, because of the increasing costs that accompany
vendor-lock-in. Third, because government procurement is good for 16%
of the European IT market and is therefore a means towards a more
competitive and sustainable IT market.
A main reason for voluntary vendor lock-in is the fear of lack of
interoperability of IT products in a multi-vendor environment.
Experience shows that standard-compliant products from different
vendors need not necessarily interoperate. As is known, a dominant
vendor may design in incompatibility to break the integrity of a
standard (e.g. Java platform). But usually incompatible standard
implementations are the unhappy outcome of good intentions.
Problem of document format standards
In the field of document formats there is an additional complexity.
For the external reader: ISO[4] has ratified two competing
XML-oriented standards for document formats. The first one, the Open
Document Format (ODF, ISO/IEC 26300) was ratified in 2006 and stems
from OASIS, a standards consortium. The second one, Office Open XML
(OOXML, ISO/IEC 29500) originally stems from Ecma International,
another standards consortium. Although ISO’s OOXML process has been
widely contested, which caused a delay in its final approval,
according to the ISO website the standards is to be published shortly.
ISO’s approval of a second, overlapping standard will not have
lessened government fears about interoperability in a multi-vendor
environment. The market has become less rather than more transparent
by means of this standards effort. To re-create some transparency
about the interoperability of applications and reduce the fear of post
hoc expenses in public procurement, conformance and interoperability
testing is needed. Plug-test events are needed to test the factual
interoperability of standards-based products from different vendors.
To be credible to all concerned, a neutral, independent testing centre
such as ETSI may need to be involved to e.g. develop test-suites and
coordinate plug test events.
Interoperability between multi-vendor OOXML applications
Current discussions on open standards highlight that multiple
implementations are an important sign that standards are really open
(see presentations by Rishab Gosh and by Thiru Balasubramaniam[5]).
Regarding ISO’s OOXML, the contention is that no company has yet
implemented the full standard, not even its primary sponsor Microsoft;
and that the six thousand page specification is too complex and too
inconsistent to implement. Are these contentions true? If not,
governments will want more than verbal claims to the contrary.
Moreover, they can easily be countered with third party conformance
and interoperability tests, including a plug-test event with multiple
OOXML-compliant IT vendors.
Interoperability between ODF applications
All major vendors, Microsoft included, have agreed to support ODF
ISO/IEC 26300, or are already doing so. That is, the availability of
multiple implementations is not a problem here. Moreover,
interestingly, two weeks ago OASIS initiated a technical committee to
organize conformance and interoperability tests. Given its scope[6],
this committee will provide transparency to governments about the
degree of conformance of applications to ODF and the interoperability
of ODF-documents. Less clear is whether the committee also intends to
address interoperability between standards versions, or more general:
what policy it has on standards change[7]. To my knowledge, such
policies have not yet been defined by any standards consortium or
standards body. They would befit the area of civil ICT standards.
The OASIS committee explicitly does not address “identifying or
commenting on particular implementations” or any certification
activities. Government procurement officers will ultimately need
testing at this level and want to involve an independent third party
testing centre for this purpose. Moreover, OASIS, too, might at a
later stage want to involve an independent third party in order to
avoid credibility problems.
Having two overlapping standards brings about its own problems, as
testifies a review of current ad hoc solutions – converters,
translators, plug-ins – to re-create compatibility between
ODF-products and Microsoft’s partial implementation of the OOXML
standard[8]. Those who develop a low quality and overlapping standard,
qualifications which also OOXML supporters use, are not the ones who
pay for the consequences. Regrettably, citizens will be paying the
price for lack of interoperability.
Although there is no formal accountability to fall back upon in
standardization[9], those who initiated the duplicating effort may
feel a – corporate social – responsibility for what happened. Their
help is needed to shift interoperability costs from governments and
citizens (post hoc) back to IT vendors (ex ante), the source of the
interoperability problem. As a start, will they fully cooperate and
support OASIS’ initiative of conformance and interoperability testing?
Are they prepared to shoulder the costs of independent, third party
conformance and interoperability tests, tests that are needed to
assure governments that no unexpected problems will arise ex post?
Kind regards,
Tineke Egyedi
Delft University of Technology