Egy kifinomult mechanizmus tartja kézben a zárt technológiai ökoszisztémák felhasználóit és intézményeit. Akkor is működik, amikor a felhasználók és az intézmények úgy érzik, szabadon döntenek, nyílt szabványokat használnak, és független diGitális infrastruktúrát építenek.

Nem erővel működik, hanem egy jóval finomabb és tartósabb stratégiával: a függőségek rétegezésével. Minden réteg eltakarja az alatta lévőt, így amikor a rendszer hibázik, a látszólagos ok egészen más, mint a valódi.

Ez egy jól felismerhető elemekből álló szerkezeti minta, előre látható hibamódokkal, és egyetlen politikai következménnyel: a kompatibilitási hibákat következetesen a nyílt alternatíváknak tulajdonítják, nem pedig azoknak a zárt függőségeknek, amelyek valójában okozzák őket.

Mindez létfontosságú annak, aki valódi interoperabilitási politikán dolgozik. Enélkül még a legjobb szándékú beavatkozások is csak a látható tünetet kezelik, miközben érintetlenül hagyják az alapvető architektúrát, amely továbbra is pontosan úgy működik, ahogy megtervezték.

A hibás működés érzete

Induljunk ki a felhasználói élményből, mert a politikai kár itt keletkezik.

Valaki Microsoft Wordben készít egy dokumentumot, és elküldi egy kollégájának, aki Linux asztali gépen LibreOffice-t használ. A kolléga megnyitja a fájlt. Valami nem stimmel: elcsúszott egy táblázat, máshogy tördelődik a szöveg, más a betűtípus, elmozdultak az oldaltörések.

Ezt az élményt intézményi környezetben emberek milliói ismerik, olyan helyeken, ahol már bevezették, vagy épp fontolgatják a nyílt forráskódú szoftverek használatát. Ebből lesznek a helpdeskes jegyek, a dühös e-mailek az informatikai osztálynak, a beszélgetések, amelyek úgy végződnek, hogy „inkább küldd el PDF-ben”, és az a szélesebb meggyőződés, amely idővel megszilárdul: a nyílt forráskódú szoftver nem alkalmas professzionális használatra.

Mi okozza ezt a hibát? A felhasználók a LibreOffice-t hibáztatják, az IT-vezetők a formátumok inkompatibilitását, a döntéshozók a nyílt szabványok éretlenségét.

Ezek mind rossz válaszok. Vagy inkább: mind rossz kérdésre válaszolnak, mert azt írják le, hol jelentkezik a hiba, nem pedig azt, hol keletkezik.

A valódi ok egymásra épülő technikai rendszerek együttese, amelyek mindegyike más típusú hibát visz a rendszerbe, de a felhasználó végül egyetlen látható eredményt érzékel.

A formátum olyan zárt struktúrákat tartalmaz, amelyeket csak a Microsoft saját megvalósítása kezel helyesen. A megjelenítés platformfüggő eltéréseket visz bele, amelyeket a formátumspecifikáció nem szabályoz. A zárt betűtípusokat pedig jogilag nem lehet nyílt forráskódú szoftverrel együtt terjeszteni.

Három különböző hibamód, ugyanazzal a tünettel, és mindhárom láthatatlan a felhasználó számára, aki csak annyit érzékel, hogy Wordben működött, LibreOffice-ban meg nem.

Ez a rétegzett függőség architektúrája. Minden réteg elnyeli az ok-okozati láncot, és más jelzést ad ki, olyat, amely a nyílt alternatíva felé mutat.

Első réteg: a formátum és a rejtett funkciók

Az első réteg a legtöbbet tárgyalt és a leginkább szem előtt lévő politikai kérdés: a dokumentumformátum. Az ODF és az OOXML közötti konfliktust alaposan dokumentálták, szabványügyi testületekben vitatták, és nemzeti parlamentekben, illetve az európai intézményekben is debták.

Még ezen a jól feltérképezett terepen is érdemes tisztázni, pontosan hogyan működik a homályosítás a formátumszinten.

Az OOXML, amelyet a Microsoft Office alapértelmezett formátumként használ, két megfelelőségi szinten létezik. A Strict viszonylag tiszta specifikáció. A Transitional viszont egészen más: olyan formátum, amelyet arra terveztek, hogy kódolja a korábbi Microsoft Office-verziók felhalmozott viselkedését, és évtizedes, zárt megvalósítási döntéseket emeljen be egy látszólag nyílt szabvány kötelező elemeiként.

Az OOXML Transitional tartalmazza a VML-t (Vector Markup Language), egy zárt rajzformátumot az 1990-es évek végéről, amely megelőzi és ellentmond a specifikáció más részein definiált DrawingML rendszernek.

Olyan hivatkozásokat is tartalmaz, hogy „mint a Microsoft Office korábbi verzióiban”, amelyek csak akkor értelmezhetők, ha valakinek hozzáférése van ezekhez a korábbi verziókhoz és a dokumentálatlan megvalósítási részleteikhez.

Olyan kiterjesztéseket is tartalmaz, amelyek lehetővé teszik, hogy a Microsoft zárt funkciókat ágyazzon a dokumentumokba. Ezek a nem Microsoft-megvalósítások számára láthatatlanok, viszont csendes megjelenítési eltéréseket okozhatnak, az apró vizuális különbségektől egészen a teljes tördelési összeomlásig.

A döntő szempont: a Microsoft Office alapértelmezésben OOXML Transitional formátumot hoz létre.

Valahányszor egy felhasználó elment egy Word dokumentumot anélkül, hogy más formátumot választana, olyan fájlt hoz létre, amelyet a Microsoft ökoszisztémára optimalizáltak, és amely finoman ellenséges minden más környezettel szemben.

A felhasználók nem tudnak erről, mert a választás a formátumszinten, automatikusan történik. Amikor a dokumentum LibreOffice-ban hibásan jelenik meg, a formátum szerepe ebben a hibában láthatatlan marad. A felhasználó megjelenítési hibát lát, nem formátumhibát.

Ez az első homályosító réteg: zárt formátumkonstrukciók, amelyeket „ipari szabvány” címkével látnak el, és olyan hibákat okoznak, amelyek úgy tűnnek, mintha a fogadó szoftver megvalósítási hiányosságai lennének.

Második réteg: a megjelenítés és a nem szabályozott viselkedés

A második rétegről kevesebb szó esik, kevésbé látszik a politikai vitákban, és éppen ezért tartósabb forrása a kompatibilitási hibáknak: a szövegmegjelenítés.

A dokumentumformátum-szabványok a tartalmat írják le. Meghatározzák, mit tartalmaz a dokumentum: szöveget, szerkezetet, logikai kapcsolatokat, beágyazott objektumokat és formázási utasításokat.

Azt viszont nem határozzák meg – és egyetlen nagy dokumentumformátum-szabvány sem határozta meg soha –, hogyan kell ezt a tartalmat megjeleníteni. A kódolt tartalom látható jelekké alakítása a képernyőn vagy a papíron a megvalósításra van bízva, és a különböző megvalósítások különböző döntéseket hoznak.

Ezek a döntések több alrendszeren keresztül hatnak.

A shaping engine-ök – azok a szoftverkomponensek, amelyek Unicode karakterek sorozatát alakítják át glifák sorozatává, és kezelik az olyan írásrendszerek bonyolult szabályait, mint az arab, a dévanágari vagy a thai – platformonként eltérnek.

A HarfBuzz, a nyílt forráskódú shaping engine, amelyet a LibreOffice és a legtöbb Linux-alkalmazás használ, helyes, szabványos kimenetet ad, de ez részleteiben eltérhet a Windows Uniscribe vagy DirectWrite engine-jeinek eredményétől, különösen az összetett, kontextusfüggő glifaválasztást igénylő írásrendszereknél.

Latin szövegnél ezek a különbségek szinte mindig láthatatlanok, de a nem latin írásrendszerek esetében – amelyeket az európai közszféra és az állampolgárok jelentős része használ – már komolyak lehetnek.

A hinting értelmezése is renderer-függő. A betűtípusok hinting utasításokat tartalmaznak – olyan algoritmusokat, amelyek alacsony felbontású kijelzőkön igazítják a glifák körvonalait –, de ezeket a különböző megjelenítők másképp értelmezik.

Egy betűtípust, amelyet a Windows GDI rendering engine-jére optimalizáltak, más vastagsággal és térközzel jeleníthet meg a FreeType Linuxon, még azonos méret mellett is.

Egyetlen karakter szintjén a különbségek aprók, összességükben viszont rontják a szöveg minőségének érzetét, és hozzájárulnak ahhoz a benyomáshoz, hogy a nyílt forráskódú környezetek egy árnyalattal kevésbé kiforrottak.

A sortörési és sorkizárási algoritmusok jelentik a legfontosabb megjelenítési eltérések forrását, és ők okozzák a dokumentumok újratördelődését a legközvetlenebbül.

Az algoritmus, amely eldönti, hol törjön sort – hogyan ossza el a szavakat egy adott szélességű sorban, mikor és hogyan válasszon el, hogyan kezelje a sorkizárt szöveget –, megvalósítási döntés, amelyet egyetlen formátumspecifikáció sem szabályoz.

A Microsoft Word sortörési algoritmusa zárt és nem dokumentált, és nagyon különbözik a LibreOffice-étól. Mindkettő leGititim megvalósítása ugyanannak a funkciónak, mégis eltérő sortöréseket adhatnak. Az eltérő sortörés eltérő oldaltörést jelent, az eltérő oldaltörés pedig azt, hogy a Wordben oldalakra tördelt dokumentum LibreOffice-ban nem ugyanúgy fog oldalakra esni.

Ez nem a megvalósítás minőségi hibája, hanem a különböző megjelenítési döntések normális és előre látható következménye, amelyet a dokumentumformátum-szabványok nem szabályoznak. A felhasználók mégis mindig a dokumentumot fogadó szoftvernek tulajdonítják a hibát, mert ott látszik a különbség, nem pedig a specifikációknak, amelyek valójában okozzák.

A megjelenítési réteg a rétegzett függőség legösszetettebb technikai eleme, és a legnehezebben kezelhető, ugyanakkor ez mutatja meg a legvilágosabban a probléma valódi méretét: két projekt eltérő döntése hoz létre hibát, amelyet kizárólag a nyílt forráskódú szoftver számlájára írnak, pusztán egy teljesen indokolatlan, már-már hitbéli tRust alapján a zárt szoftver minőségében.

Harmadik réteg: betűtípusok és a függés a zárt erőforrásoktól

A harmadik réteg teszi teljessé a képet, és a gyakorlatban sokszor ez okozza a legnagyobb kárt: a betűtípusok. Itt most nem magát a betűtípus-szintű bezárást elemezzük, hanem azt, hogyan működik a betűtípus-réteg a rétegzett függőség modelljében.

A betűtípusok mindkét felső réteggel kölcsönhatásban állnak. A formátumszinten névvel hivatkoznak rájuk: a dokumentum kijelenti, hogy a törzsszöveg Calibriben, a címsorok pedig Cambria betűtípussal készültek. Ha ez a két betűtípus nem elérhető a fogadó rendszeren – márpedig minden olyan rendszeren ez a helyzet, amelyre nem vásároltak licencet ezekhez a zárt betűtípusokhoz –, a szoftvernek helyettesítenie kell őket.

A helyettesítés megváltoztatja a metrikát, a metrika pedig a geometriát. A megváltozott geometria újratördelést, széteső elrendezést, a margókon túlcsúszó űrlapokat eredményez. Itt is a dokumentumot megnyitó alkalmazást hibáztatják a felhasználók.

A megjelenítési szinten a betűtípusok a shaping engine-nel, a hinting rendszerrel és az antialiasing pipeline-nal lépnek kölcsönhatásba, minden egyes betűtípus saját tervezési elvei és beágyazott utasításai szerint. Egy betűtípus, amelyet a Windows rendering stackjére optimalizáltak, már a helyettesítés előtt is máshogy fog kinézni FreeType alatt, és ez is hozzájárul a környezetek közötti vizuális eltéréshez.

A betűtípus-réteg azért különösen hatékony bezárási mechanizmus, mert a jogi elérhetetlenség és a felhasználók tájékozatlansága együtt érvényesül. A probléma középpontjában álló zárt betűtípusok – a Calibri és a Cambria, korábban az Arial és a Times – nem érhetők el semmilyen nyílt forráskódú licenc alatt.

Ezt a jogi korlátot a nyílt forráskódú szoftverek nem tudják átlépni. A felhasználók azonban nem licencproblémaként érzékelik, hanem szoftverhibaként – nem egy tudatos stratégia következményeként, hanem bizonyítékként arra, hogy a nyílt forráskódú szoftver „nem tud megbirkózni” a hétköznapi dokumentumokkal.

Csak a aptos, a Microsoft legújabb zárt betűtípusa az, amelyet részben korlátozó licenc alatt adtak ki, mivel a használatot a Microsoft oldaláról történő letöltéshez kötik. Így Linux-felhasználók is telepíthetik és jogszerűen használhatják, de ezt nem kommunikálták elég széles körben, ezért a bezárási mechanizmus csak gyengült, nem szűnt meg.

Miért kulcsszó az, hogy „láthatatlan”

A három réteg mindegyike kezelhető probléma lenne, ha látható lenne, és a felhasználók világosan látnák, hogy a hiba a zárt formátumból, az elégtelen megjelenítési specifikációkból vagy a zárt betűtípusból ered. A látható problémákat pontos diagnózis és célzott beavatkozás alapján lehet kezelni és megoldani.

Ennek a sémának az ereje éppen a homályban rejlik. Minden réteg jelátalakító

Egy olyan rendszer, amely a versenytársakkal való érintkezési pontokon hibákat generál, mégpedig úgy, hogy ezeket a hibákat mindig a versenytársaknak tulajdonítják, versenyelőnyt jelent.

Itt a szándék kérdése kevésbé fontos, mint a struktúráé: függetlenül attól, mi motiválta az eredeti tervezési döntéseket, a kialakult architektúra korlátozásként működik, és a hatásai megfigyelhetők és mérhetők.

Hogyan reagált a szabályozás, és hol vallott kudarcot

A dokumentumokhoz kötődő bezártságra adott szabályozási válasz a formátumra koncentrált: előírták az ODF és a nyílt formátumok használatát a közbeszerzésben, és garantálták, hogy a kormányzati dokumentumok létrehozhatók és megtekinthetők legyenek zárt szoftverek nélkül. Ezeket az intézkedéseket azonban szinte soha nem párosították szankciókkal, így a szabályokat gyakran figyelmen kívül hagyták.

Ráadásul ezek az előírások nem foglalkoztak a zárt betűtípusok használatával a dokumentumsablonokban. Így csak a felső réteget javították ki, az alsó réteget pedig érintetlenül hagyták, ahol továbbra is zavartalanul működik, kevésbé látható és kevésbé politikai kérdés, ezért tartósabb is.

A dokumentumok továbbra is elbuknak a nyílt forráskódú szoftverekkel való érintkezési pontokon, a felhasználók pedig továbbra is ezeket hibáztatják. A formátumokra vonatkozó előírások mögötti politikai akaratot fokozatosan aláássák a felhasználói panaszok az interoperabilitási problémákról, amelyek látszólag ellentmondanak a nyílt, szabványos formátumokra vonatkozó ígéretnek.

Az az intézmény, amely bevezeti a LibreOffice-t, de nem foglalkozik a megjelenítés következetességével – vagyis hagyja, hogy a Windows és a Linux vegyes infrastruktúrája úgy cseréljen dokumentumokat, hogy közben nem ismeri fel: a megjelenítés eltérése nem szoftverhiba –, azzal kockáztat, hogy belső interoperabilitási problémát hoz létre, amelyet aztán felhasználhatnak a visszatérés igazolására az egységes, egyplatformos környezethez.

A megjelenítési réteg gyakorlatilag semmilyen szabályozási figyelmet nem kapott. Egyetlen jelentős diGital szuverenitási keretrendszer sem ír elő követelményeket a megjelenítés hűségére. Egyetlen közbeszerzési szabvány sem határozza meg a megfelelést a különböző megvalósítások közötti vizuális következetesség alapján.

A probléma kezeléséhez szükséges eszközök – referencia-megjelenítési megvalósítások, megjelenítési tesztcsomagok, hűségmérő tesztek – legfeljebb prototípusként vagy javaslatként léteznek, és egyetlen komoly szabályozási keretrendszer sem építette be őket.

Ennek a mintázatnak az ismerete politikai tett

A függőségek láthatatlan rétegződése közel ötven évnyi, gyakorlatilag szabályozatlan fejlődés eredménye a személyes produktivitást szolgáló szoftverek területén, és azzal fenyeget, hogy a diGital szuverenitás felé vezető utat rendkívül bonyolulttá teszi.

Fontos nevet adni ennek a mintázatnak, hogy használni lehessen a szabályozási vitákban, parlamenti kérdésekben, közbeszerzési specifikációkban és a diGital szuverenitásról szóló nyilvános debate-ban, minden szinten, a médiát is beleértve.

A függőségek láthatatlan rétegződése olyan jelenségeket kapcsol össze, amelyek első ránézésre nem függnek össze – formátumincompatibilitásokat, megjelenítési eltéréseket, betűtípus-helyettesítési hibákat –, és megmutatja, hogy mind ugyanannak az alapvető architektúrának a megnyilvánulásai.

Amint ezeket a jelenségeket nem elszigetelt technikai problémákként, hanem mintázatként kezdjük látni, világosabbá válik, milyen szabályozási válaszra van szükség. Nem elég egyetlen réteget kijavítani és egyetlen szabványt előírni – még ha ez alapvető első lépés is.

Az összes függőséget átláthatóvá kell tenni, és be kell építeni az interoperabilitási politikákba, amelyek kifejezetten és részletesen foglalkoznak a formátummal, a megjelenítéssel és a betűtípusokkal, és mindhárom rétegre kiterjedő kikényszerítési mechanizmusokat határoznak meg.

A nyílt forráskódú és nyílt szabványos közösség már megteremtette a valódi interoperabilitás technikai alapjait: a nyílt formátumok kiforrottak és megbízhatók, a nyílt forráskódú alkalmazások teljes mértékben alkalmasak a feladatra, és több száz szabadon licencelt betűtípus létezik, köztük sok olyan, amely méretben kompatibilis a zárt betűtípusokkal.

A bezártság architektúrája nem azért maradt fenn, mert az alternatívák elégtelenek. Azért maradt fenn, mert a szabályozás még nem tanult meg a formátum-megfelelés látható felszíne mögé nézni, és felismerni azokat a mélyebb rétegeket, ahol a zárt függőségek tovább működnek – láthatatlanul és figyelmen kívül hagyva –, és végzik azt a munkát, amelyre eredetileg tervezték őket.