Informatika | Tanulmányok, esszék » Nyílt forráskódú szoftverek közigazgatási alkalmazhatóságának vizsgálata

A nyílt forráskódú szoftverek közigazgatási alkalmazhatóságának vizsgálata II Közreműködők Bagoly Zsolt. Balsai Péter. Dr. Dudás Ágnes Dr. Iványi Péter Kósa Attila. Pandur Béla. Dr. Pázmándi Kinga Szegfű László. Tomka Gergely. Dr. Várady Géza Wéninger Ágnes. Közreműködő szervezetek ODF Alliance Magyarország Egyesület. Szabad Szoftver Intézet Kht. 2009. június 15 Tartalomjegyzék 1. Vezetői összefoglaló 1 2. A szoftver helye és szerepe a jogrendben 9 2.1 Jogalkotói keretek 9 2.11 Nemzetközi jogalkotás 10 2.12 A magyar szabályozás 13 3. Szerzői jogi alapfogalmak 3.1 Szerző 3.11 Szerzőtársak, társszerzők és a kollektív 3.12 Vagyoni jogi jogosult 3.13 Szoftverspecifikus rendelkezések 3.14 A jogsértés . művek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 17 27 28 32 4. A

szabad szoftver fogalma 4.1 A szabad szoftverrel kapcsolatos definíciók 4.2 A szabad szoftver és a nyílt forráskódú szoftverek elhatárolása 4.21 A nyílt forráskódú szoftverek definíciója 4.22 A nyitott forráskódú szoftverek 4.3 A FLOS szoftver és más szoftverek elhatárolása 4.31 Az ingyenes szoftverek 4.32 A felhasználói kör vonatkozásában korlátozott szoftverek . 4.33 Tisztaszoftver program 33 33 35 35 37 37 37 5. A szoftverek nemzetközi megítélése 5.1 FLOS szoftverek a kontinentális jogrendben 5.11 Az Európai Unió 5.12 Németország 5.13 Ausztria 5.14 Svájc 41 41 41 44 48 48 III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 38 IV 5.15 További példák . 49 6. A FLOS szoftverek helye és szerepe a

magyar jogrend tükrében 6.1 A felhasználási szerződés (licenc) és annak jelentősége 6.11 Formai követelmények 6.12 A licenc kötelező elemei 6.13 Egyedi fejlesztések megrendelése 6.14 Jelenleg ismert FLOS szoftverekkel kapcsolatos licencmodellek 6.15 A GPL v 2 licenc bemutatása 6.2 Adójogi vonatkozások 6.21 A számviteli szabályozás alapjai 6.22 Az adózás rendje 6.23 A társasági adóval kapcsolatos rendelkezések 6.24 Az általános forgalmi adóval kapcsolatos rendelkezések 6.25 A FLOS szoftverek közteher szabályokban való megjelenésére tett javaslatok 51 51 51 52 53 54 63 78 79 83 87 88 96 7. Felmérési eredmények 99 7.1 Válaszadók 99 7.2 A felmérés célja 100 7.3 Szoftverhasználati szokások 100 7.31

Felhasználási díjtól (licencdíjtól) mentes szoftverek ismerete 100 7.32 Felhasználási díjtól (licencdíjtól) mentes szoftverek használata 101 7.33 Az Internet Explorertől különböző böngésző ismerete, használata . 102 7.34 A Microsoft Windows termékcsaládján kívüli operációs rendszerek ismerete 104 7.35 Szabad szoftvert használó ismerősök 105 7.36 A számítógépen végzett leggyakoribb tevékenysége 107 7.37 Az egyes tevékenységekhez kapcsolódó célszoftverek megoszlása . 108 7.38 A FLOS szoftverek és a Microsoft vagy más kereskedelmi gyártó szoftvereinek jellemzése 112 7.39 Átlagosan a számítógép előtt töltött idő 128 7.310 Informatikai jártasság 128 7.311 A felmérésben részt vevő szervek sajátosságai 130 2009. június 15 V 7.4 Egy esetleges

átállással kapcsolatos tapasztalatok, félelmek . 7.41 Problémák, tapasztalatok 7.42 Fejlesztési javaslatok 7.43 Egy átállás tapasztalatai felvetések, . . . . . . . . 136 136 138 139 8. A FLOS szoftverek megjelenése a kormányzati stratégiákban és jogalkotásban 143 8.1 Stratégiai tervezés és a nyílt forráskódú szoftverek kormányzati felhasználásának lehetőségei 143 8.2 Az információs társadalommal összefüggő kormányzati tevékenység irányítása és eszközrendszere 148 8.3 Az elektronikus közigazgatás stratégiai jövőképe 154 8.4 Az eKS megvalósítását célzó programrendszer 160 8.5 Az e-közigazgatási keretrendszer és a nyílt rendszereken alapuló interoperabilitás megteremtésének követelménye 165 8.6 A MITS igazságügyi részstratégiája és a ténylegesen megvalósult fejlesztések

167 8.7 A belső piaci szolgáltatásokról szóló irányelv szerinti feladatok és azok megvalósítása . 171 9. A nyílt forráskódú szoftverek közigazgatásban való felhasználhatóságának jogszabályi háttere 175 9.1 Az elektronikus közigazgatási ügyintézés lehetővé tétele és keretrendszerének alakulása a magyar szabályozásban 175 9.2 A Ket 2008 évi módosítása és az elektronikus közszolgáltatásokról szóló új törvény előkészítése 181 9.3 A nyílt forráskódú szoftverek felhasználásának lehetőségei a központi rendszer útján történő elektronikus ügyintézésben . 186 9.4 Informatikai rendszerek együttműködése, informatikai biztonság193 9.5 Az elektronikus ügyintézési eljárásban alkalmazható dokumentumok, dokumentumkezelés, elektronikus irattározás 198 10.Az ODF formátum kezelésének lehetőségei az állam- és közigazgatásban 205 10.1 Az OpenDocument

Formátum, valamint az ODF Alliance Összefoglaló 205 10.11 Az Open Dokumentum Formátum legfontosabb előnyei 206 10.12 Az Open Dokumentum Formátum hátrányairól, a bevezetés problémáiról 206 2009. június 15 VI 10.2 „Miért éppen az ODF?” Az Open Document Formátum jelentősége a kormányzat számára 10.21 Az ODF hozzájárulása a back-office rendszerek korszerűsítéséhez 10.22 Az ODF az ISO által hivatalosan elfogadott nyílt fájlformátum szabvány 10.23 Az ODF-et választó kormányok és vállalatok 10.24 Előnyök a kormányzat számára 10.25 A nyílt szabványok, nyílt szabványú fájlformátumok jellemzői . 10.26 Az ODF támogatása elvi kérdés 10.27 Az ODF Alliance támogatást biztosító szervezet 10.3 Miért fontos a nyílt fájlformátum? 10.4 Az ODF áttekintése

10.41 Az ODF technikailag 10.5 Nyíltnak tervezve: az ODF előnyei 11.A Szabad Szoftver gazdasági hatása 11.1 A szabad szoftver megismert üzleti modellje 11.11 A szoftverfejlesztés modellje 11.12 A szabad szoftver költségmodellje . 207 . 208 . 208 . 209 . 209 . . . . . . . 211 211 212 213 215 215 216 221 . 222 . 222 . 224 12.Céges, üzleti világbeli tapasztalatok a szabad és nyílt forráskódú szoftverekkel kapcsolatban 229 12.1 BalaBit IT Biztonságtechnikai Kft 229 12.11 Nyílt forráskódú szoftverek használata a BalaBitban 230 12.2 Drescher Magyarország Kft 234 12.21 Szabad és /vagy nyílt forrású szoftverek használata 234 12.22 Szabad és vagy nyílt forrású szoftverek fejlesztése 234 12.23 A szabad / nyílt forráskódú szoftverek helyzete Magyarországon a magánszférában, illetve a közszférában 234 12.24 A költségmegtakarítás

és a szabad / nyílt forrású szoftverek használata 235 12.25 A TCO számítás alapja 235 12.26 Félelmek 235 12.27 A jó szakember fogalma 236 12.28 A szabad / nyílt forrású szoftverek preferálása állami szinten . 236 12.29 Személyes és céges adatok szabad / nyílt forrású szoftverekkel történő kezelése (például PostgreSql, Mysql, Linux, FreeBSD) . 237 2009. június 15 VII 12.210 Operációs rendszer, böngésző, irodai csomag használata . 12.211 Az OpenOffice bevezetésének lehetősége 12.212 A teljesen, vagy majdnem teljesen szabad szoftver alapú informatika lehetősége egy cégben 12.213 A szabad és nyílt forrású szoftverek előnyei 12.214 A szabad szoftverek térnyerése 12.215 A zárt forrású platformon futó szabad szoftverek, illetve a platformfüggetlen

alkalmazások kérdése 12.3 A Daten-Kontor Kft tapasztalatai, felvetései 12.31 A nyílt forrású és szabad szoftverek 12.32 Az állami szerepvállalás hatásai 12.33 Javaslat egy más megközelítésű állami szoftverfejlesztési megoldásra, stratégiára 12.4 DEJAHU Kft 12.41 Szerver és kliens oldali tapasztalatok 12.42 A szabad / nyílt forráskódú szoftverek helyzete Magyarországon a magán- és a közszférában 12.43 Versenyképesség és költségmegtakarítás 12.44 Annak következményei, ha az állam elsődlegesen a szabad / nyílt forrású szoftvereket preferálná . 12.5 Összefoglalás 13.Szabad szoftverek életciklusa 13.1 Projektirányítás a FLOS szoftverek létrehozásánál 13.2 A FLOSS életciklusa statisztikai megközelítésben 13.21 Első modell 13.22 Második modell 13.23 Harmadik

modell 13.24 Összefoglalás 13.3 Nyílt forrású fejlesztés szolgáltatás szemléletű vizsgálata 13.31 ALM – Application Lifecycle Management 13.32 Alkalmazási rendszerek teljes életciklusa 13.33 IT szolgáltatásmenedzsment 13.34 A szabad szoftver és az ITIL v3 13.35 Számítási példa . . . . . . . . . . . . . . . . . . . . . . . . . 237 . 238 . 238 . 239 . 239 . . . . 240 240 242 242 . 243 . 243 . 244 . 244 . 245 . 245 . 246 247 . 251 . 255 . 256 . 259 . 265 . 267 . 267 . 268 . 270 . 271 . 271 . 275 14.Milyen okok állhatnak a szabad szoftverekről zárt szoftverekre váltás mögött ? 279 14.1 Négy esettanulmány 281 14.11 Peng Hong Hardware 281 2009. június 15 VIII 14.12 Strathcona Baptist Girls Grammar School 281 14.13 Austereo 282 14.14 Nigériai Mandriva szerződés 282 15.A szabad

és nyílt forráskódú szoftverek elterjesztése az államés közigazgatás területén 285 15.1 Jogi környezet 285 15.2 Elsődlegesen Microsoft Windows alapú az állam- és közigazgatásunk 286 15.3 Az állami és közintézményi fejlesztések fokozzák a függőséget 286 15.4 Intézkedési terv 288 15.5 További lépések 291 15.6 Mi legyen a támogató központ feladata? 293 15.7 Hogyan válasszunk szabad és nyílt forráskódú szoftvert? 293 15.8 Hogyan vegyünk a szabad és nyílt forrású szoftverekhez támogatást? 295 15.9 Összefoglalva 296 16.A „back-office” rendszerek korszerűsítésének lehetősége szabad és nyílt forrású szoftverekkel 297 A A GPL v. 2 jogi szakfordítása 301 B Európai Uniós Nyílt Forráskódú Licenc v.11 309 C Az elektronikus közigazgatás, az

e-biztonság elsődleges, releváns jogszabályi környezete 317 D Linux, GNU, disztribúció 319 E Szegfű László vezető-tanácsos véleménye 323 F A Microsoft megvalósított ODF támogatása az Office 2007ben 333 G A szabad szoftverek használatának, ismertségének felmérése337 H Szabad szoftverekhez kapcsolódó adójogi kérdések 345 I 349 Az APEH hivatalos válasza J Részlet az LME IDA2 projektjének negyedéves tájékoztató anyagából 357 2009. június 15 IX K Comes vs. Microsoft 383 L Merit felmérés alapján a FLOSS-sal kapcsolatos félelmekről523 M Kommunizmus a szoftverfejlesztésben ? 527 N Az ODF története 531 O Gyakori tévhitek a Nyílt Dokumentum Formátumról (ODF)535 P Gyakran Ismételt Kérdések az ODF kapcsán 539 Q További információk az ODF-ről felhasználóknak és fejlesztőknek 545 R Az ODF alkalmazását előíró kormányok 547 S A Rambøll Report vezetői összefoglalója 551 T A Nyílt Forrás, Nyílt

Szabványok, valamint az újrahasznosítás : a brit kormány megvalósítandó tervei 555 U ODF bevezetési kérdőív 563 V ODF és bevezetése szempontjából fontos dokumentumok rövid leírással 577 W A Pénzügyminisztérium válasza 579 X Az Európai Unió Microsoft elleni tröszteljárásának ítélete 589 2009. június 15 X 2009. június 15 Táblázatok jegyzéke 8.1 A 2004–2006 közti időszakban az elektronikus ügyintézést érintő, a 2004–2006 közti időszakban megvalósítandó feladatok a MITS e-kormányzati stratégája szerint . 144 10.1 Az ODF előnyei 218 11.1 A modellünk adatai 224 11.2 A modellhez tartozó bérkalkuláció 225 13.1 A technikai tulajdonságok és felhasználói előnyök összefoglalása248 13.2 A teljes birtoklási költség egy adatbáziskezelő alkalmazásnál, 10 éves használattal számolva . 276 L.1 FLOS szoftverek

kormányzati felhasználása 524 L.2 FLOSS advantages 524 N.1 Az ODF története 531 R.1 Az ODF alkalmazását előíró kormányok 547 R.2 Az ODF használatának bevezetése regionális, tartományi vagy tagállami szinten . 548 R.3 ODF-támogató alkalmazásokra való átállással járó előzetes költségbecslések 548 U.1 ODF bevezetési kérdőív 563 XI XII 2009. június 15 Ábrák jegyzéke 4.1 A szoftverek elhelyezkedése . 35 5.1 A licenchasználat arányai . 42 7.1 Tisztában van-e azzal, hogy bizonyos szoftverek esetén nem kell jogdíjat fizetni? . Használ-e licencdíjtól mentes szoftvereket, és ha igen, hol? Az Internet Explorertől különböző böngésző ismerete . Az Internet Explorertől különböző böngésző használata . A Microsoft Windows

termékcsaládján kívüli operációs rendszerek ismerete . A Microsoft Windows termékcsaládján kívüli operációs rendszerek használata . Szabad szoftvert használó ismerősök . A számítógépen végzett leggyakoribb tevékenysége . A leggyakrabban használt szövegszerkesztők . A leggyakrabban használt táblázatkezelők . A leggyakrabban használt böngészők . A leggyakrabban használt levelezőrendszerek . Milyen mértékben jellemzi a gyorsaság a szoftvereket? . Milyen mértékben jellemzi a gyorsaság a szoftvereket? . Milyen mértékben jellemzi a biztonságosság a szoftvereket? Milyen mértékben jellemzi a biztonságosság a szoftvereket? Milyen mértékben jellemzi a könnyű kezelhetőség a szoftvereket? . Milyen mértékben jellemzi a könnyű kezelhetőség a szoftvereket? . Milyen mértékben jellemzi

a felhasználóbarátság a szoftvereket? . Milyen mértékben jellemzi a felhasználóbarátság a szoftvereket? . 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 XIII 101 102 103 104 105 106 106 107 108 110 110 112 113 114 115 115 116 116 117 118 XIV 7.21 7.22 7.23 7.24 7.25 7.29 7.30 7.31 7.32 7.33 7.34 7.35 7.36 7.37 7.38 7.39 7.40 7.41 7.42 7.43 7.44 7.45 7.46 7.47 7.48 Milyen mértékben jellemzi az időtállóság a szoftvereket? . 119 Milyen mértékben jellemzi az időtállóság a szoftvereket? . 119 Milyen mértékben jellemzi a hasonlóság más szoftverekkel? 120 Milyen mértékben jellemzi a hasonlóság más szoftverekkel? 121 Milyen mértékben alkalmasak az alapfeladatok ellátására a szoftverek? . 121 Milyen mértékben alkalmasak az alapfeladatok ellátására a szoftverek? . 122 Milyen mértékben alkalmasak a

bonyolult feladatok ellátására a szoftverek? . 123 Milyen mértékben alkalmasak a bonyolult feladatok ellátására a szoftverek? . 123 Milyen mértékben olcsó a szoftverek beszerzése? . 124 Milyen mértékben olcsó a szoftverek beszerzése? . 124 Milyen mértékben olcsó a szoftverek fenntartása? . 125 Milyen mértékben olcsó a szoftverek fenntartása? . 126 Milyen mértékben tehetők könnyen naprakésszé a szoftverek?126 Milyen mértékben tehetők könnyen naprakésszé a szoftverek?127 Milyen mértékben magyar nyelvűek a szoftverek? . 127 Milyen mértékben magyar nyelvűek a szoftverek? . 128 Milyen mértékben testreszabhatóak a szoftverek? . 129 Milyen mértékben testreszabhatóak a szoftverek? . 129 Átlagosan mennyi időt töltenek a számítógép előtt? . 130 A hírekről történő informálódás módja . 131 A gépfelhasználás százalékos mutatója .

132 A gépek száma . 132 A gépállomány megoszlása, a szerverek aránya . 133 A gépállomány megoszlása, a laptopok aránya . 133 Szoftverekkel összefüggő költségek . 134 Szoftverekkel összefüggő költségek . 135 Informatikus munkavállalók száma . 135 Külsős közreműködők száma . 136 10.1 10.2 10.3 10.4 10.5 Különböző ODF alkalmazások . Egy ODF szöveges dokumentum tartalma . Egy ODF számolótábla tartalma . Egy szöveges dokumentumhoz tartozó content.xml fájl Egy számolótáblához tartozó content.xml fájl 7.26 7.27 7.28 . . . . . . . . . . . . . . . 216 217 217 218 218 13.1 A projektirányítás általános modellje 252 2009. június 15 XV 13.2 A Netscape Navigator százalékos felhasználása a többi böngészőhöz képest az évek során 13.3 A kibocsátott verziók között

eltelt idő a GNU awk szoftver esetén . 13.4 A kibocsátott verziók között eltelt idő a GNU C fordító esetén . 13.5 A kibocsátott verziók között eltelt idő az Xemacs szoftver esetén . 13.6 Hype-görbe a Gartner csoport szerint 13.7 Letöltési adatok ACPI szoftver esetén 13.8 Letöltési adatok az Enlightenment window manager esetén 13.9 Letöltési adatok egy ICQ program esetén 13.10 Letöltési adatok a tcl programozási nyelv esetén 13.11 Letöltési adatok a JOE editor esetén 13.12 Letöltési adatok a pstoedit esetén 13.13 Letöltési adatok a 7-ZIP esetén 13.14 Letöltési adatok a MinGW esetén 13.15 Letöltési adatok az eGroupWare program esetén 13.16 Letöltési adatok a Qcad program esetén 13.17 A hivatkozások száma az egyes csomagokra a különböző

Debian verziók esetén . 13.18 Görbe típusok a hivatkozások száma alapján 13.19 Chappell szerinti ALM területek és aktivitásuk az idősíkon 2009. június 15 256 257 258 258 259 260 261 261 262 262 263 263 263 264 264 265 266 269 XVI 2009. június 15 1. fejezet Vezetői összefoglaló A tanulmány a 2. fejezetben kitér a nyílt forráskódú és szabad szoftverek elhatárolására, ugyanakkor törekszik arra, hogy ezen szoftvercsoportokat az egyes eltérések ellenére egységben kezelje, hiszen a vizsgált felhasználási körben e szoftvercsoportok vonatkozásában lényeges eltérés nem mutatkozik. A szabad és nyílt forráskódú szoftverek egységes megnevezésére ezért a Free / Libre / Open / Source / Software kifejezésekből képzett betűszóval (FLOSS) került sor. A FLOS szoftverek közigazgatásban történő felhasználásának egyik alappillére a szoftverekkel kapcsolatos jogi helyzet tisztázása. A jogi elemzés

négy pólusú: 1. Az általános szoftverekkel kapcsolatos szerzői jogi ismeretek körében fontos, hogy a szerző és a vagyoni jogi jogosult elhatárolásra kerüljön, hiszen nagyon sok esetben okoz nehézséget, hogy a szerző (fejlesztő) személye és jogosultságai keverednek a vagyoni jogi jogosult (munkáltató vagy megrendelő) jogosultságaival (17. oldal) A személyhez fűződő jogok (névviselés, a mű integritásának védelme) az alkotó személyéhez kötődnek, míg a többszörözés, terjesztés jogával – szerződéses alapon – rendelkezhet más személy is. 2. A nemzetközi kitekintés lehetővé teszi, hogy a környező országok jogalkotási, jogalkalmazási megoldásait megismerve a magyar jogszabályalkotás, ítélkezési gyakorlat támpontokra találjon Elengedhetetlen feltétel ugyanis, hogy a FLOSS közigazgatásba történő bevezetését megelőzően letisztuljanak alapvető modellek Tekintettel arra, hogy FLOS szoftverrel kapcsolatos döntést

magyar bíróság még nem hozott, annak elemeit a magyar jogrendhez rendkívül hasonló német szabályozásból érdemes megismerni. 1 2 3. A FLOSS helyzetének könnyebb megértése érdekében elemzésre kerül a leghíresebb és legelterjedtebb szoftverlicenc: a GPL v2. (63 oldal) Az elemzés pontról pontra követi a licenc szövegét, kitérve az egyes rendelkezések jogi hátterére és alkalmazhatóságára. 4. A FLOSS magyar jogrendben történő elhelyezésekor a legnagyobb problémát a szerzői jogi és közteher szabályok ellentmondásossága jelenti Az adóhatóság, illetve a Pénzügyminisztérium által adott állásfoglalásokból is kitűnik, hogy míg a szerzői jog a szoftverre, mint alkotásra tekint, amelyre felhasználási jog engedhető, illetve amelyhez kapcsolódóan a vagyoni jogok értékesíthetőek, addig az adójogi szabályozás a szoftveren szerzett tulajdonjogról beszél, a felhasználási jogviszony létrejöttét pedig szolgáltatásnak

minősíti. Súlyos problémát jelent továbbá, hogy a FLOSS fejlesztések esetében az adóhatóság értelmezésének tükrében a fejlesztést lefolytató vállalkozást hátrányos megkülönböztetés éri, hiszen a ráfordítások elszámolására a kialakult gyakorlat szerint nem jogosult, mivel azok használatát ingyenesen engedi harmadik személyeknek. Mindaddig, amíg a jogszabályi környezet nem teszi kifejezetten lehetővé, hogy legalább a vállalkozás érdekében történő fejlesztésnek lehessen tekinteni a FLOSS előállítását, ez a fejlesztési forma kockázatot jelent. A FLOS szoftverek közigazgatásba történő bevezetéséhez ideális jogi környezetet teremtene, ha a társasági adó szabályaiban található kutatási – fejlesztési szabályozás jelenne meg (akár csak szoftverspecifikusan is) a többi érintett adónemben. A Miniszterelnöki Hivatal által kijelölt közigazgatási intézményekben lefolytatott felmérések szerint a közigazgatás

jelentős része ismeri, ám nem, vagy csak böngészőként és szerver oldalon használja a FLOSS megoldásokat. A válaszadók kis százaléka keverte a FLOSS és más freeware (ingyenesen letölthető, ám forráskódot és átdolgozást nem engedő) megoldásokat. A felmérés egyértelműen kimutatta, hogy mindaddig, míg központi szinten nem történik döntés a FLOSS bevezetéséről, illetve amíg az egyes szervezetek úgyis „megkapják” a megszokott Microsoft termékek használati jogát, váltani nem fognak. A váltás nehézségével kapcsolatosan sok a tisztán feltételezéseken alapuló félelem Azt gondolják, hogy nehéz lenne a bevezetés/átállás, miközben a felhasználói szokások ismeretében (a számítógépet 80–90%-ban csak „okos írógép” minőségében használja a közigazgatás, oly mértékben, hogy például a dokumentumszerkesztés esetén szóközöket használnak, nem ismernek billentyűkombinációkat, nem tudnak táblázatkezelőben

képleteket megadni) megfelelő motiváció mellett az átállás nem jelentene tényleges problémát. Volt 2009. június 15 3 olyan válaszadó például, ahol az új gép igénylése esetében azt már OpenOffice csomaggal adták, és a felhasználó különösebb nehézség nélkül megtanulta annak alkalmazását. A felvetések között szerepelt, hogy az egyes területeken különös problémát jelent, hogy egyedi, specifikus szoftverekkel dolgoznak, amelyek esetében a szerződés megkötésekor nem fordítottak kellő figyelmet sem arra, hogy átdolgozási jogokat szerezzenek, sem arra, hogy platformfüggetlen vagy több platformon is működő1 megoldásokat rendeljenek meg. Egyértelműen látszik, hogy egy-egy rosszul megfogalmazott szerződéssel (például az adathozzáférések, adatállományok titkosítása olyan megoldással történik, amit csak és kizárólag az adott cég alkalmaz) az egyedi fejlesztések esetében is teljes függőség alakul ki a fejlesztő

cégtől. Egy ilyen (évek óta tartó) függő helyzetben pedig a váltás – központi segítség nélkül – elképzelhetetlennek tűnik. A központi irányítás korábbi – szoftverekkel kapcsolatos – rendeletei, határozatai azt mutatják, hogy e területen az előrelépés csak centralizált szabályozás mellett lehetséges. Ugyanakkor rendkívül komoly szerepe és felelőssége van a kormányzatnak abban, hogy egy-egy hiányosan, vagy átgondolatlanul megalkotott szabállyal ne tegye még nehezebbé a FLOSS kezdeményezések helyzetét. Az irányítás egyediesített szintjén jelentkeznek elsődlegesen a problémák, mikor rendelkezések – melyek eredendően nem tartoztak szoftverszabályozási területre, a technika fejlődése miatt szükségszerűen – szoftverelemeket határoznak meg A probléma az, hogy ezek a szoftverekkel kapcsolatos rendelkezések a már kialakult helyzetre optimalizáltak, ezáltal a változás, változtatás lehetőségét

ellehetetlenítik. Amennyiben ugyanis a részletszabályok nem funkcionalitási követelményeket határoznak meg, hanem egy adott operációs rendszer vagy böngésző használatát írják elő, az alternatív megoldások előtt a lehetőség sem nyílik meg. Az államnak fel kell lépnie a FLOSS bevezetése érdekében az oktatás területén is, hiszen mindaddig, míg az oktatási intézményekben a Campus és egyéb programok keretében csak a Microsoft alkalmazásait tanítják, amíg kisiskolás kortól ebben nőnek fel nemzedékek, addig az átlagfelhasználó számára az operációs rendszer fogalma a Windowst jelenti. Ugyanúgy, ahogy a nyelvoktatásra hangsúlyt fektetnek, figyelmet kell fordítani arra, hogy az informatikai oktatás is legalább duál platformú legyen. (Azaz a windowsos anyagok mellett tanítási segédleteket, oktatási anyagokat kell írni a közpon- 1 Több platformra is lefordítható (például OpenOffice, PostgreSql, Firefox, Mysql), vagy több

platformon futtatható (például Jdictionary). 2009. június 15 4 tilag kiválasztott és támogatott FLOSS megoldásokhoz2 , és a tantervben szerepeltetni kell az ezzel kapcsolatos elvárásokat.) A FLOSS használatával elérhető megtakarítás kérdése. Az állam négy fontos ponton takaríthat meg – akár részleges átállás esetén is – költséget. Első és nyilvánvaló ok, hogy amennyiben ingyenesen hozzáférhető szoftvereket használ, vagy olyan fejlesztéseket finanszíroz, amely végeredményeként ilyen szoftverek keletkeznek, akkor nem kell egy külföldi országban honos szoftvergyártónak – éves szinten – milliárdos nagyságrendben licencdíjat fizetnie. Amennyiben a FLOSS támogatására a K+F rendszerhez hasonló módon kerülne sor, az élénkítené a gazdaságot, és munkahelyeket teremtene, lehetővé tenné, hogy az egyetemről kikerülő fiatal informatikusok (programozók) az országban maradjanak. A FLOSS támogatásával és a

szükséges jogszabályi, oktatási háttér kialakításával lehetőség nyílna arra, hogy kis- és középvállalkozások ezen a területen lépjenek piacra. Az üzleti szféra tapasztalatairól szóló rész négy (egymástól eltérő méretű és más-más területen működő) cégnél lefolytatott interjún alapul. A válaszadók – befolyástól mentes – véleményeiből kitűnik, hogy nem minden esetben vannak teljesen tisztában a FLOSS nyújtotta lehetőségekkel. Azok a társaságok azonban, amelyek napi szinten (fejlesztés vagy support) dolgoznak ezekkel a szoftverekkel, teljesen működő modellként tekintenek ezekre a megoldásokra. Az ODF Alliance Magyarország véleménye szerint egy ISO szabványként is elfogadott, nemzetközi támogatással rendelkező gyártó- és platformfüggetlen dokumentum formátumnak (ODF), melyet több gyártó több alkalmazása támogat, s melyet több kormányzat használ, és egyre több kíván használni, nincsenek hátrányai.

A formátumot kezelő alkalmazásoknak lehetnek hátrányos tulajdonságaik, egymáshoz vagy más hasonló célú, de nem ODF formátumot kezelő alkalmazáshoz képest A mai kormányzati, közigazgatási munka és az állampolgári lét nélkülözhetetlen tartozékai a dokumentumok. A kormányzat a dokumentumokból tesz szert ismeretekre, dokumentumokban tárolnak kényes adatokat, valamint dokumentumokkal tartanak kapcsolatot az egyes részlegek egymás között, illetve az üzleti partnerekkel és az állampolgárokkal. A papír alapú dokumentumokat egyre inkább felváltja az elektronikus forma. Ahhoz, hogy a kormányok alkalmazni tudják az állandóan változó technológiát és üzleti folyamatokat, bizonyosságra van szükségük, hogy most és bármikor a jövőben hozzáférhetnek, helyreállíthatják és használhatják kényes adataikat. Az 2 Nem célszerű egy disztribúció vagy csak egy kizárólagos megoldás kiválasztása, inkább technológiát kellene tanítani

(például adatbáziskezelés : PostgreSql, Mysql, berkeleydb). 2009. június 15 5 OpenDocument Formátum (ODF) a szabványos fájlformátumával biztosítja ezeket a követelményeket, és dokumentumaik fölött teljes körű rendelkezési lehetőséget nyújt. A szoftver életciklusának meghatározására sokféle kísérletet tettek. A hagyományosnak tekinthető meghatározás szerint a szoftver életciklusának akkor van vége, ha a fejlesztő megszünteti a szoftver további követését, nem portolja az új platformokra. A szoftver fejlesztését és felhasználását alapvetően projekt szemlélettel közelíthetjük meg, hiszen a szoftver fejlesztés célszerűen egy projekt keretében valósítható meg a gyártó (a terméket létrehozó) oldaláról. A felhasználó oldaláról nézve a kérdést azt találjuk, hogy a felhasználónak egy informatikai szolgáltatásra van szüksége A szoftverfejlesztéssel kapcsolatos projekt célja egy gazdasági, műszaki,

vezetési probléma megoldása informatikai támogatással. Ebben a szemléletben azt kell vizsgálnunk, hogy egy termék ki tudja-e elégíteni a felhasználó szolgáltatással kapcsolatos igényeit, vagy sem. Ha az „elfogadott legjobb gyakorlatot” tekintjük mérvadónak, akkor leszűkíthető a vizsgálat arra a kérdésre, hogy a felhasználó igényei kielégíthetőek-e az adott termékkel. Formálisan: teljesíthetők-e az ITIL (IT Infrastructure Library) elvárásai. A vizsgálat három modellt vett alapul Az első modell felállítása során az volt a feltételezés, hogy a szoftververziók kibocsátásai (release-ei) között eltelt idő mérőszámként szolgálhat arra, hogy egy project mennyire aktív, mennyire érett, illetve fejlesztés alatt áll-e még. A második modell a Gartner csoport által kidolgozott Hype-görbét használja. A harmadik modell a másodikhoz hasonló, és azt próbálja vizsgálni, hogy egyes programokat, technológiákat mennyire

használnak a felhasználók. Összességében kitűnik, hogy míg zárt kódú szoftvereket a gyártók szükségszerűen (az újabb változatok piacra kerülés esetén) támogatás nélkül hagynak (például Windows 3.1) vagy próbálják megvonni a támogatást (ennek jelenlegi példája az XP – Vista esete) addig egy FLOS szoftvernél a kód hozzáférhetősége miatt – szükség esetén – bármeddig található hozzá támogatás. A teljes birtoklási költségre vonatkozó számításból kitűnik (276. oldal), hogy egy adatbáziskezelő szoftver 10 éves használata esetén a „dobozos” termék bekerülési költsége hozzávetőleg kétszerese a FLOSS alkalmazás költségének. A zárt forráskódú szoftverekre történő visszatérés négy fő oka: a felhasználói nyomás (a felhasználó nem érzi a szoftverlicenc költségeit, csupán saját kényelmi szempontjai és rutinjai motiválják – lásd a Strathcona Baptist Girls Grammar School eset, 281. oldal), a

felkészültség hiánya (az átállás bonyolult és alapos tervezést igénylő folyamat – lásd Peng Hong Hardware eset, 281. oldal), lobbierő (a legkevésbé dokumentált és mégis legjelentősebb visszaállási tényező, amikor valamelyik gyártó pénzért piacot vesz – lásd nigériai példa, 282. oldal), a FLOSS megoldás hiánya (a monopolhelyzetben lévő hardver és 2009. június 15 6 szoftvergyártók együttműködése ellehetetleníti bármilyen konkurens piacra lépését – lásd Austereo eset, 282. oldal) Intézkedési terv 1. Központi döntés (lehetőség szerint törvény) és ennek végrehajtási rendeletei, amely keretében a Magyar Állam a FLOSS fejlesztések és rendszerek mellett foglal állást Méghozzá nem disztribútor vagy szoftververzió kijelölésével, hanem oly módon, hogy a közpénzekből (állami és közigazgatási keretek) fejlesztett szoftvereknek egy, az Állam által kijelölt licencet ír elő. A fejlesztéseknek egyrészt a

licencben rögzített „szabadságokat” kell adniuk, másrészt teljesíteniük kell egy minimális interoperabilitási, platformfüggetlenségi követelményt. 2. Egyértelmű jogszabályi környezetet kell teremteni a szoftveripar és a szabad és nyílt forrású szoftvereket fejlesztők, felhasználók számára, ide értve a közteher-szabályok és az oktatási rendeletek reformját is. 3. Be kell vezetni a szabad és nyílt forráskódú szoftvereket az államilag finanszírozott valamennyi képzési területre, így a köz- és felsőoktatásba, valamint a felnőttképzésbe is. Ennek az a módja, hogy központilag, szakértők bevonásával ki kell dolgozni a komplett oktatási anyagot, amelyet minden iskola, tanár számára elérhetővé kell tenni. 4. Ki kell dolgozni egy magyar, a szabad és nyílt forrású szoftverekkel kapcsolatos vizsgarendszert, mely disztribúció-független, legalább háromszintű, és amely a fent nevezett tananyagra épül. 5. Képzéseket

kell szervezni – disztribúció-független módon – az állam- és közigazgatás informatikusainak, valamint az informatikát oktató tanároknak, melyeken a részvétel támogatott, és amelyek vizsgával, minősítéssel végződnek. 6. Az ECDL hazai gyakorlatát képzésekkel alátámasztva is alkalmassá kell tenni arra, hogy szabad és nyílt forrású szoftverekkel (például GNU/Linux, OpenOffice, PostgreSql) segítségével lehessen tanítani és vizsgázni belőle. 7. Az állam és közigazgatás szoftvereit és adatait fel kell térképezni, egyértelmű előírásokat kell kialakítani a minimálisan kötelező adattartalmakra Szintén ki kell alakítani és elő kell írni a kötelezően kezelendő 2009. június 15 7 adatcsere-formátumot, vagy formátumokat, amelyek nem csak a kötelező adattartalmat képesek tartalmazni, hanem a bővített adatokat is. Ezek a lépések az előfeltételei az oktatásban, az állam- és közigazgatásban a FLOS szoftverek és az

ehhez tartozó tudás bevezetésének. A lépések végrehajtásának koordinálásához a megfelelő jogszabályi háttér szükséges Az első lépések megtételét követően fel kell állítani olyan támogató központot, amely a további lépések végrehajtásában segédkezik. Azonban a felállítás megfelelő előkészítés és háttér nélkül magában hordozza a nem megfelelő, az esetlegesen az elérni kívánt célt eltévesztő működés veszélyét, amely adminisztrációés költségnövekedést, az újonnan a piacra belépni kívánoknak a piacra lépés nehezítését okozhatja, és esetlegesen még egyéb olyan nem kívánt mellékhatásokkal járhat, melyek a verseny csökkenését okozzák. 2009. június 15 8 2009. június 15 2. fejezet A szoftver helye és szerepe a jogrendben 2.1 Jogalkotói keretek A szoftver fogalmának meghatározásakor a jogalkotó csak a definíció kereteit vállalta fel, a jogalkalmazókra bízva ezáltal az

értelmezésből adódó nehézségeket, hiszen az informatika e gyorsan változó területén egyedi elbírálást igényel, hogy meddig terjedhet a jogi védelem. Ám egyes esetekben előfordulhat, hogy a jogalkalmazó túl szűkmarkúnak bizonyul (például a német bíróságok1 ), vagy jogharmonizációs célok teszik kötelezővé a gyakorlatban kialakult védelem minimális szintjének meghatározását, ezáltal mégiscsak törvényhozási szinten megkívánva a beavatkozást. A szabad és nyílt forráskódú szoftverek fogalma a köznyelvben keveredik. Jelen tanulmány célja, hogy azon szoftverek helyzetét elemezze, amelyek egyrészt a szabadság 4 követelményének, másrészt a nyílt forráskód definíciójának eleget tesznek. Ezen szoftverek megjelölése a tanulmány során a FLOSS betűszóval történik, amely a Free / Libre / Open / Source / Software kifejezések rövidítéséből2 adódik. A free és nyílt forráskódú szoftverek megkülönböztetésének

részletes leírására a tanulmány a 4.2 fejezetében térünk ki 1 2 Inkasso-program döntés in : NJW 1986. 192 o, vagy in : CR, 1985 22–32 o http://en.wikipediaorg/wiki/Free and open source software 9 10 2.11 Nemzetközi jogalkotás Szerzői jogi megközelítés A szoftverszabályozásra vonatkozó jelentősebb nemzetközi megállapodások képezik a kapcsolódó joganyag egyik bázisát3 : A Berni Uniós Egyezmény (1886) 1971-ben (Párizsban) módosított szövege szerint az „. irodalmi és művészeti művek kifejezés felöleli az irodalom, a tudomány és a művészet minden alkotását, tekintet nélkül a mű létrehozatalának módjára vagy alakjára”. Valamint az 5 cikk kimondja a nemzeti elbánás elvét, amely szerint amennyiben az állam saját jogrendjében védte a szoftvert, a vele kapcsolatba kerülő államok szerzőinek is nyújtania kellett a védelemnek ezen fokát.4 Így tehát az 1980-as évek végére a jelentősebb országok BUE tagsága

és belső szabályokból eredő szoftvervédelme miatt „elterjedt” a szoftverek szerzői jogi védelme. Az 1952-ből származó Egyetemes Szerzői Jogi Egyezményhez5 és annak Párizsi Okmányához6 csatlakozó államok ugyancsak vállalták, hogy bármelyik szerződő állam állampolgárának megjelent műveit (az irodalmi, tudományos és művészeti műveket, ideértve az írói műveket, a zeneműveket, a színpadi műveket és a filmeket, a festményeket, a metszeteket és a szobrokat7 ), valamint ezen államok területén első ízben megjelent műveket nemzeti elbánásban részesítik.8 Az előzőekben említett tág kategóriákat követően a WIPO9 modell törvény adja a legátfogóbb nemzetközi meghatározást (1978-ból). E szerint a szoftver a következő részeket tartalmazza: 3 A 2.11 és 212 fejezetek egyes részei Dr Dudás Ágnes : A szoftver szerzői jogi védelme c tanulmányán alapulnak In: Iparjogvédelmi és Szerzői Jogi Szemle, Budapest, 2005.

április, 2005 június 4 1975. évi 4 törvényerejű rendelet az irodalmi és a művészeti művek védelméről szóló 1886. szeptember 9-i Berni Egyezmény Párizsban, az 1971 évi július hó 24 napján felülvizsgált szövegének kihirdetéséről, 2. cikk (1) bekezdés valamint 5 cikk (1) bekezdés. 5 1971. évi 4 törvényerejű rendelet az 1952 évi szeptember hó 6 napján Genfben aláírt Egyetemes Szerzői Jogi Egyezmény kihirdetéséről 6 1975. évi 3 törvényerejű rendelet az Egyetemes Szerzői Jogi Egyezmény Párizsban, 1971. évi július hó 24 napján felülvizsgált szövegének kihirdetéséről 7 1. cikk 8 2. cikk, azaz „ugyanolyan védelemben részesülnek, mint amilyen védelmet az illető állam saját állampolgárainak azon művei számára biztosít, amelyek először a saját területén jelentek meg. ” 9 Szellemi Tulajdon Világszervezete, http://www.wipoorg – World International Property Organisation 2009. június 15 11 1. Számítógép

programot magát, azaz olyan parancsok (utasítások) sorozatát, amelyet egy gépi olvasásra alkalmas hordozóra víve elérhetjük, hogy egy – információfeldolgozásra képes – gép meghatározott műveletet, feladatot, eredményt jelezzen, kivitelezzen vagy végrehajtson (elérésre bírjon). 2. A program dokumentációját Ez egy eljárás átfogó ismertetése (szóban, sematikusan vagy egyéb módon) elegendő részletességgel ahhoz, hogy egy meghatározott számítógépi programot alkotó utasítássorozatot létrehozzuk. 3. Kiegészítő leírás mindazon dokumentáció, amely a program megértését és alkalmazását segíti. (Értelemszerűen nem tartozik ide a program maga, sem annak leírása.10 ) A TRIPS Egyezmény11 (1994) 10. cikkelye 1 bekezdése szerint a számítógépi programok – mindegy, hogy forráskódban vagy gépi kódban kerülnek kifejezésre – a Berni Egyezmény alapján irodalmi műként élveznek védelmet. A szoftverek jogi megítélésének

igen lényeges elemeit képezik Pálos György meglátása szerint a TRIPS Egyezményben lefektetett elvek.12 Pálos különösen kiemeli a legnagyobb kedvezmény elv bevezetésének13 , illetve a kizárólagos jog indokolt korlátozásának jelentőségét14 A szerződés legszembetűnőbb jellegzetessége azonban, hogy kizárólagosan a vagyoni jogosultságok helyzetéről rendelkezik. Az 1996-ban Genfben aláírt WCT15 4. cikkelyében kimondja, hogy a számítógépi programok – függetlenül megjelenésük módjától és formájától – a Berni Egyezmény 2. cikkelye értelmében – mint irodalmi alkotások – védettek 10 Mustervorschriften für den Schutz von Computersoftware in : GRUR Int. 1978 286– 291. o 11 A Szellemi tulajdon kereskedelemmel összefüggő kérdéseit szabályozó, a GATT Uruguay-i fordulójában létrejött egyezmény (Trade Related Aspects of Intellectual Property Rights) 12 Pálos György: A TRIPS, és a számítógépi program védelme in :

Magyar Iparjogvédelmi és Szerzői jogi Egyesület Közleményei 1997/38. sz 13 4. cikk 14 13. cikk 15 A WIPO- Szerzői Jogi Szerződés, 1996. december 20 in : Urheber und Verlagsrecht 2002, 9. kiadás, Beck Verlag, München 2009. június 15 12 Az USA Copyright Act16 szabályozása szerint a számítógépes program olyan utasítások sorozata, melyek számítógépben történő közvetlen vagy közvetett alkalmazása meghatározott eredmény létrehozását célozza.17 Az Amerikai–Magyar Megállapodás18 védeni rendeli a Berni Uniós Egyezmény szerint irodalmi műnek minősülő számítógépi programok akár forráskódban, akár tárgyi kódban rögzített minden fajtáját (ebbe beleértve a felhasználói programokat és operációs rendszereket egyaránt), valamint a számítógéppel vagy számítógép segítségével alkotott műveket.19 A számítógépi programok jogi védelméről szóló 91/250/EGK irányelv – amelyet jelenleg egységes kodifikált

szerkezetben 2009/24 EK Irányelv néven20 tartanak számon (továbbiakban Szoftver irányelv21 ) – célja is az volt, hogy harmonizálja a tagállamokban megjelenő számítógépi programokra vonatkozó szabályozást, hiszen az ezen a téren megnyilvánuló különbségek károsan hatnak az egységes piac működésére, esetenként akadályozhatják az áruk szabad áramlását. A preambulum a következő szabályozási pontokat tette kötelezővé:22 1. A számítógépi programoknak, a szerzői jog alapján, mint irodalmi alkotásnak kell védelmet nyújtani 2. Definiálni kell a védelem tárgyát23 és alanyait24 , valamint ezek kizárólagos jogosultságait25 , illetve 3. a védelem idejét26 16 http://www.copyrightgov/title17/circ92pdf I fejezet 5 o „A computer program is a set of statements or instructions to be used directly or indireclty in a computer in order to bring about a certain result.” 18 Megállapodás a Magyar Köztársaság Kormánya és az Amerikai

Egyesült Államok Kormánya között a szellemi tulajdonról – 1993/26. Nemzetközi Szerződés a Nemzetközi Gazdasági Kapcsolatok Minisztériuma közigazgatási államtitkárától 19 II. cikk, 1 a, 20 AZ EURÓPAI PARLAMENT ÉS A TANÁCS 2009/24/EK IRÁNYELVE (2009. április 23.) a számítógépi programok jogi védelméről 21 Közvetlenül erről: Thomas Dreier : Rechtschutz von Computerprogrammen, Die Richtlinie des Rates der EG vom 14. Mai 1991 in : CR 10/1991 577–584 o 22 A számítógépi programok jogi védelméről szóló 91/250/EGK irányelv 6. célkitűzés 23 1. cikk 1 24 2. cikk 25 4. cikk, valamint az ez alóli kivételek : 5 cikk 26 Az irányelvet követően megalkotott A szerzői jog és egyes szomszédos jogok védelmi idejének összehangolásáról szóló 93/98/EGK irányelv 15. célkitűzése rendelkezik a szoftverirányelv 8. cikkében foglalt ideiglenes rendelkezésekről, és a szerzői jogok időtartamát az 1. cikkben egységesen a Berni Egyezménynek

megfelelő „a szerző életének végéig és halála után 70 évig” tartó időintervallumban állapítja meg. 17 2009. június 15 13 Az említett kötelezettségek közül e helyen a védelem tárgyának pontosabb körülírása szükséges. Az irányelv a „számítógép-program” fogalma alá tartozónak tekinti annak előkészítő tervezési anyagát is, továbbá védeni rendeli a számítógépi program valamennyi megjelenési formáját.27 Kizárja azonban a védelem köréből úgy a program, mint az interface28 alapjául szolgáló ötleteket és elveket. 2.12 A magyar szabályozás Szerzői jog A magyar jogalkotó már 1983-ban – a világelsők között29 – a 9/1969-es számú végrehajtási rendelet módosításával a védelem tárgyai közé felvette a „számítógépi program-alkotások és a hozzájuk tartozó dokumentációk (a továbbiakban : szoftver)” kategóriát is. 1999-ben, az új szerzői jogi törvény megalkotásakor egészítette ki az

alpontot a most is hatályos formában, megfelelve ezzel a nemzetközi elvárásoknak.30 Az Amerikai–Magyar Megállapodásból már ismert kritériumok mellett – azaz ennek forráskódban, tárgykódban vagy bármilyen más formában rögzített minden fajtáját, úgy a felhasználói programot mint az operációs rendszert – tehát önállóan nevesítette, mint a szerzői jogi védelem tárgyát. Mint az a törvény indokolásából kiderül, ezen egyedi megoldás – azaz mikor a törvény nem minősíti a szoftvert „irodalmi műnek” – elszakad a TRIPS Egyezmény 10. cikke, a 91/250/EGK irányelv 1 cikke és a WIPO Szerzői Jogi Szerződésének 4. cikke által megjelölt csapásiránytól (ezek ugyanis a már említett módon – irodalmi műként, írásműként – rendelik védelemben részesíteni a számítógépi programalkotást, a szoftvert). A törvényalkotó nézete szerint ezen elszakadás azonban csak látszólagos, hiszen „az irodalmi művekre is

vonatkozó általános szabályok irányadóak 27 Ide sorolva tehát az adathordozón megjelenő, illetve hardverre integrált programokat, a program gépi-, tárgy- vagy forráskódban megjelenő változatát (lásd Wandtke, Artur – Axel – Bullinger, Winfried : Praxiskommentar zum Urheberrecht, Verlag C.H Beck München, 2002 (továbbiakban : Kommentar) Grützmacher : 643 o 28 csatlakozó- vagy illesztési felület 29 Gyertyánfy Péter : Kandidátusi Értekezésében a következő szoftvernevesítőket jelölte meg: első a Fülöp szigetek, majd az USA 1980, ezt követően hazánk 1983, majd fej-fej mellett Anglia 1985, NSZK 1985, Franciaország 1985, végül pedig Japán 1986 6–7. o 30 1. §, (2) „ c) a számítógépi programalkotás és a hozzá tartozó dokumentáció (a továbbiakban : szoftver) akár forráskódban, akár tárgykódban vagy bármilyen más formában rögzített minden fajtája, ideértve a felhasználói programot és az operációs rendszert is,”

2009. június 15 14 azonban a szoftverre is, azokkal a különös szintű szabályokkal együtt, amelyeket a törvény VI. fejezete állapít meg a szoftver védelmére Az említett nemzetközi egyezmények és a közösségi irányelv rendelkezései pedig tartalmilag ezt követelik meg.” 31 Az egységes szabályozást mutatja, hogy a törvény a jogvédelemre jogosultság feltételeként ugyanazon elvárást (egyéni, eredeti jelleg) támasztja szoftver esetében is, mint más műveknél.32 A magyar szabályozás – szemben a nemzetközi megoldással (amely irodalmi műnek tekintve helyezi oltalom alá) – a már említett sui generis védelmet33 biztosítja tehát a szoftver számára, és pont ezért már az általános részben definiálja34 azt. Így a szerzői jogi védelem tárgya: a számítógépi programalkotás és a hozzá tartozó dokumentáció (a továbbiakban: szoftver) akár forráskódban, akár tárgykódban vagy bármilyen más formában rögzített minden

fajtája, ideértve a felhasználói programot és az operációs rendszert is. ”35 Az egyedi oltalmi forma kialakulásának hátterében az állhat, hogy „a régi Szjt-ben a nem színpadra szánt irodalmi művek nyilvános előadására vonatkozó, tulajdonképpen kötelező közös jogkezelést előíró szabály a szoftverre semmiképpen nem volt alkalmazható.” 33 De bármennyire is pontos és előremutató volt a megfogalmazás, az továbbra sem érintette a műszaki szemlélet által olyannyira hangsúlyozott funkcióját36 a szoftvernek. 31 Az 1999. évi LXXVI törvény indokolása a szerzői jogról (a továbbiakban : Indokolás) ugyanígy: Lontai Endre: A szellemi alkotások joga, Eötvös József Könyvkiadó, Budapest, 2001, 43. o 33 Faludi Gábor: A szoftver szerzői jogi védelme c. írásában in: Darázs Lénárd – Faludi Gábor – Kisfaludi András – Pajor-Bytomsky Magdolna – Vékás Lajos : Európai közösségi jogi elemek a magyar magán- és

kereskedelmi jogban. KJK Kerszöv, Budapest 2001. 305 o 34 A német szabályozás csak egy szóval jelöli meg a védelem tárgyát, azt írja „Zu den geschützten Werken der Literatur. gehören insbesondere : Computerprogramme” UrhG 2. §, (1) 1 pont a német szabályozás csak egy szóval jelöli meg a védelem tárgyát, azt írja „Zu den geschützten Werken der Literatur. gehören insbesondere : Computerprogramme” UrhG 2 §, (1) 1 pont 35 1999. évi LXXVI törvény a szerzői jogról, a továbbiakban : Szjt 36 „A szoftver (számítógépi programalkotás és a hozzá tartozó dokumentáció) funkcionális mű. A szoftver arra szolgál, hogy segítségével valamilyen feladatot végezzenek el, legyen ez például munka, játék, oktatás vagy információterjesztés.” Faludi Gábor: A felhasználási szerződés, Közgazdasági és Jogi Könyvkiadó, Budapest, 1999 95. o 32 2009. június 15 15 Szabadalmi jog Az úgynevezett funkcióközpontú szemlélet a

iparjogvédelmi oltalommal kapcsolatos törekvések között jelent meg. A szabadalmi irányelvtervezettel37 kapcsolatos Tanácsban képviselt – sok ellenzést kiváltó – magyar álláspont rendkívül kusza és nehézkes folyamatban került kialakításra. Az, hogy az Európai Parlament végül elutasította a tervezetet, inkább az egyes magánkezdeményezések parlamenti képviselőkre gyakorolt hatásának volt köszönhető A szabadalmi oltalommal kapcsolatos részletes okfejtésre jelen tanulmány terjedelmi korlátai miatt nem kerül sor.38 Büntetőjog Egy további jogterület is behatóan kénytelen foglalkozni a számítástechnika fejlődésével kapcsolatban kialakult jogi helyzettel, ez pedig a büntetőjog, mely reagálva a fejlődés következtében megjelent új helyzetre külön tényállásokat tartalmaz. Bár a szoftvert magát nem, de az annak futtatására alkalmas rendszert meghatározza a Büntető Törvénykönyv39 (továbbiakban Btk.) 300/F §-ában: „

számítástechnikai rendszer az adatok automatikus feldolgozását, kezelését, tárolását, továbbítását biztosító berendezés vagy az egymással kapcsolatban lévő ilyen berendezések összessége.” A másik fontos – jelen tanulmányoz kapcsolódó – tényállás a 329/A. §-ban szabályozott szerzői vagy szerzői joghoz kapcsolódó jogok megsértését rögzíti. Itt érdemes megjegyezni, hogy egy FLOS szoftver licencének megsértése és egy kereskedelmi szoftver licencének megsértése között legfeljebb a büntetés mértékét tekintve lehet különbség. Ugyanis a bűncselekmény elkövetésének feltételei: az, hogy valaki másnak a szerzői jogról szóló törvény alapján fennálló szerzői vagy ahhoz kapcsolódó jogát haszonszerzés végett, vagy vagyoni hátrányt okozva megsértse. Bár az eddig ismert bírósági gyakorlat e pontban a bűnösség megállapításához a jogdíj megfizetésének elmaradását veszi ala37 Proposal for a Directive

of the European Parliament and of the Council on the patentability of computer-implemented inventions, Brussels, 20. 02 2002, COM (2002) 92 final, 2002/0047 (COD), elemzések : http://www.linuxvilag hu/content/files/cikk/55/cikk 55 80 81.pdf, http://www.mszhhu/kiadv/ipsz/200504/05−hirek−ficsorhtml 38 Ezzel kapcsolatos részletes irodalom : Dudás Ágnes, Gyenge Anikó, Kabai Eszter : A kereskedelmi és a szabad szoftver szerzői jogi és szabadalmi oltalmáról (MTA Jogtudományi Intézet Infokommunikációs Jogi Centrum) megjelenés alatt (KJK KERSZÖV). Külföldön : Axel H. Horns : Der Patentschutz für softwarebezogene Erfindungen im Verhältnis zur „Open Source”-Software, in : JurPC Web-Dok. 223/200 Abs 1–80, http://www.jurpcde/aufsatz/20000223htm 39 1978. évi IV törvény a Büntető Törvénykönyvről 2009. június 15 16 pul, az nem korlátozódhat erre. Kötött licencű FLOS szoftverek esetében a licenc cseréje például jogsértés, ahogy jogsértés az

is, ha a szerző nevét nem tüntetik fel.40 Polgári jog Ugyancsak érintett területnek kell tekintenünk a polgári jogot – hiszen a szerzői jogi törvény mint háttérjogszabályát rendeli alkalmazni41 –, valamint az internet használatának következtében a nemzetközi magánjogot is. A tanulmány folyamán többször utalunk majd az említett törvényeknek – a problémák megoldásához feltétlenül szükséges – részleteire. Amennyiben a FLOS szoftverek a közigazgatásban bevezetésre kerülnek, ki kell dolgozni alternatív megoldási lehetőségeket arra, hogy a felhasználók irányában miként biztosíthatóak a szavatossági kötelezettségek. Ide értve a hibás teljesítéseken alapuló igényeket csakúgy, mint egy-egy elmaradt fejlesztés jogkövetkezményeinek szabályozását. Köztudott, hogy angolszász mintára épülő felhasználási szerződésekben (ez igaz mind a kereskedelmi, mind a FLOS szoftverekre) többnyire kizártak vagy erősen

mérsékeltek a szavatossági igények. Egy további kutatás keretében vizsgálandó az ezzel kapcsolatos magyar és nemzetközi ítélkezési gyakorlat, annak esetleges nehézségei, és az ítélkezési problémák feloldásának lehetőségei. Adójog Ahogy arra egy korábbi tanulmány is rámutatott: „a közterheket előíró szabályokban – értelemszerűen elsősorban a törvényekben – a lehető legnagyobb mértékben igazodni kellene a szerzői jogi, iparjogvédelmi törvényekben meghatározott fogalmak használatához, és az adott oltalmi tárgy megkerülhetetlen jellegzetességeihez.” 42 Ahogy az jelen tanulmány egy későbbi pontjában részletesen is kifejtésre kerül, az adójogi szabályozás a szoftverekkel kapcsolatos adójogi rendelkezések kezelésére nem készült fel. Sajnálatos módon több helyen olyan eltéréseket tartalmaz, amelyek érhetetlenné, értelmezhetetlenné teszik az egyes rendelkezéseket. Az adójogi szabályozás részletes

elemzését a 6.2 fejezet tartalmazza 40 A kérdés részletesebb elemzése meghaladja jelen tanulmány kereteit. Szjt. 3 § 42 Faludi Gábor, Kiss Zoltán : A statisztikai besorolások, közteher jogszabályok és a szellemi tulajdon viszonya. A Magyar Szellemi Tulajdonvédelmi Tanács részére készített anyag Összefoglaló : http://wwwmszh hu/testuletek/msztt/MSZTTbeszamolo2006.pdf 41 2009. június 15 3. fejezet Szerzői jogi alapfogalmak A tanulmány könnyebb érthetősége érdekében a gyakran használt kifejezések magyarázata elkerülhetetlenül szükséges. 3.1 Szerző „A szerzői jog azt illeti, aki a művet megalkotta (szerző).” 1 Szerző csak természetes személy lehet. Az alkotás mögött tehát mindig egy ember áll Hiába van például szoftverek esetén lehetőség arra, hogy a vagyoni jogok a szerzőtől különböző személyre szálljanak át, a szerzői minőség ettől még nem változik. Szerző a fejlesztő maga A másik, a FLOS szoftverek

kapcsán kiemelten fontos jelentőséggel bíró tétele e szerzői jognak az alábbi: „Szerzői jogi védelem alatt áll – az eredeti mű szerzőjét megillető jogok sérelme nélkül – más szerző művének átdolgozása, feldolgozása vagy fordítása is, ha annak egyéni, eredeti jellege van.” 2 Ez teszi lehetővé, hogy a FLOS szoftverek ne egy szerzős/egy fejlesztős alkotások legyenek, hanem szerzői minőséget nyerjen mindenki, aki az alapprogramhoz „érdemi”, azaz egyéni, eredeti jelleggel bíró kiegészítést, kódrészt ad, azaz a származékos műben szerzőként közreműködik. 3.11 Szerzőtársak, társszerzők és a kollektív művek Több szerző esetén (legyen ennek oka együttes fejlesztés vagy átdolgozás következtében létrejövő származékos mű) a szerzőtárs és a társszerző fogal1 2 Szjt. 4 §, (1) bekezdés Szjt. 4 §, (2) bekezdés 17 18 mait kell megkülönböztetni. A különbségtétel alapja, hogy az egyes szerzők

által létrehozott alkotások egymástól elválaszthatóak-e. Szerzőtársak „Több szerző közös művére, ha annak részei nem használhatók fel önállóan, a szerzői jog együttesen és – kétség esetén – egyenlő arányban illeti meg a szerzőtársakat ; a szerzői jog megsértése ellen azonban bármelyik szerzőtárs önállóan is felléphet.” 3 Azokat tehát, akik egy közös fejlesztés részmoduljait fejlesztik, ám összességében mégis egy ,művet” hoznak létre, Társszerzőnek nevezzük. Egy kernel fejlesztése tipikusan társszerzős. Társszerzők „Ha a közös mű részei önállóan is felhasználhatók (összekapcsolt művek), a saját rész tekintetében a szerzői jogok önállóan gyakorolhatók. Az összekapcsolt művekből álló, együtt alkotott közös mű valamely részének más művel való összekapcsolásához az eredeti közös mű valamennyi szerzőjének hozzájárulása szükséges.” 4 Ha az alkotások önmagukban

oltalomképesek és alkalmasak a felhasználásra, akkor alkotóik egyenként szerzők, akik „társultak”. Egy office csomagban például a levelezőrendszer fejlesztője és a szövegszerkesztő programozója szerzőtársak, hiszen a levelezés és a dokumentumszerkesztés nem egymástól függő alkotások, és mindegyik működhet a másik alkalmazás futtatása nélkül is. Kollektív mű A kollektív mű iskolapéldája az olyan szoftverfejlesztés, amelyet egy beruházó szervezet kezdeményez, irányít és finanszíroz. Amennyiben nagy mennyiségű szerző vesz részt a fejlesztésben – és tevékenységük nem határolható el (tipikusan, mikor szinte kódsoronként változik a fejlesztő) –, akkor keletkezik kollektív, azaz együttesen létrehozott mű. „Együttesen létrehozottnak minősül a mű, ha a megalkotásában együttműködő szerzők hozzájárulásai olyan módon egyesülnek a létrejövő egységes műben, hogy nem lehetséges az egyes szerzők jogait

külön-külön meghatározni.” 5 3 Szjt. 5 §, (1) bekezdés Szjt. 5 §, (2) bekezdés 5 Szjt. 6 §, (2) bekezdés 4 2009. június 15 19 „Az együttesen létrehozott műre (például nemzeti szabványra) a szerzők jogutódjaként azt a természetes vagy jogi személyt, illetve jogi személyiséggel nem rendelkező gazdasági társaságot illeti meg a szerzői jog, amelynek kezdeményezésére és irányításával a művet létrehozták, és amely azt a saját nevében nyilvánosságra hozta.” 6 Ha azonban az együttesen alkotott szoftver egyes fejlesztési fázisaiból a fent nevezett módon egyéni eredeti jellegű művek születnek, azokra külön szerzői jog keletkezik.7 A kollektív mű létének alapja tehát, hogy a szerzői hozzájárulásokat ne lehessen elkülöníteni. A Kommentár indokolása szerint a szoftver kollektív műkénti feltüntetésében „szerepet játszhat az is, hogy az összetett szoftver-művek fejlesztésében jelentősek a végeredmény

létrehozásához nyújtott nem alkotói jellegű hozzájárulások is, amelyek eredménye gyakran beleolvad az alkotói jellegű teljesítményekbe.” 8 E körben kell többek között a rendszertervezők, a tesztelők munkájára gondolni Itt érdemes megjegyezni azonban, hogy FLOS szoftverek esetében a tesztelési feladatokat többnyire a szoftverhez kapcsolódó közösség végzi el (ezért jelennek meg ezek a szoftverek tesztelését követő úgynevezett „stabil verziókban”, illetve alfa, béta stb. megoldásokban9 ) Személyhez fűződő jogok „A személyhez fűződő szerzői jogok fajtái, tartalma mutatja, hogy ez a jog a kulturális értékek egyik közvetlen biztosítéka. A szellemi alkotás és különösen a szerzői mű nem kezelhető puszta anyagi fogyasztási cikként a kulturális forgalomban.” 10 Névfeltüntetéshez való jog Az egyik legalapvetőbb joga a szerzőnek, mely őt (elvileg) mindig és minden körülmények között megilleti. Lévén

azonban speciális jogtárgyról szó, a kommentárokban azzal a nézettel találkozhatunk, hogy a szerzők nevének feltüntetésének elmaradása – amennyiben kereskedelmi szoftverről van szó, esetlegesen több száz szerzőt is érintő műnél – nem sérelmes, hiszen a szoftver dobozán tagadhatatlanul nehezen férnének el, ahogy az sem sérelmes, hogy helyettük a copyright jogosultját (azaz a c tulajdonosát) nevezik meg. A szerzőként való elismerés további buktatója, hogy a jogi irodalom egy része11 a szerzőség megjelölését elegendőnek tartja 6 Szjt. 6 §, (1) bekezdés (BH 1993/545) idézi : Szjt. Kommentár 55 o 8 Szjt. Kommentár 55 o 9 http://en.wikipediaorg/wiki/Software versioning 10 Szjt. Kommentár 63–64 o 11 Lehmann FS Schricker: 543, 562, 7 2009. június 15 20 abban az esetben is, ha a neveket csak a szoftverhez tartozó kézikönyvben tüntetik fel. Ez azonban abból a szempontból aggályos, hogy a szoftver fogalma nem foglalja magába a

kézikönyvet, hiszen arra külön védelmet (írásmű) rendel a törvény. A kézikönyvnek a kézikönyv alkotóit kell tartalmaznia, a számítógépes programnak pedig a programét. Általánosan elfogadott módszer, hogy a forráskódban nevezik meg magukat az alkotók. Ez azonban szintén vitatott megoldás lehet, ha a forráskód egyáltalán nem kerül nyilvánosságra, hiszen – teljesen ellehetetlenítve ezáltal a szerzőnek a név feltüntetéséhez való (egyébként vitathatatlan) jogát – azt üzleti titokként, vagy know-how miatt védik. Előremutatva a FLOS szoftverekkel kapcsolatos jogviszonyok elemzésére: ott a szerzőség feltüntetése elemi érdek, hiszen a fejlesztők egy része azért csatlakozik egy-egy ilyen projekthez, hogy tudását/tehetségét megmutassa a világnak. A GPL licenc kifejezetten előírja, hogy egy-egy átdolgozás esetén az átdolgozó köteles magát és az átdolgozás dátumát a forráskódban megjelölni.12 Más kérdés, amikor

a szerző maga alkot álnév13 (programozók esetében nickname) alatt, illetve ragaszkodik nevének elhallgatásához. Külön érdekessége lehet ezen eseteknek, ha a munkavállalói szerződés eleve rögzíti, hogy a szerző névtelenül kíván alkotni.14 Ugyancsak a magyar Kommentár utal arra, hogy számítógépes programok esetében megfigyelhető gyakorlat, hogy a szerzők nevét nem tüntetik fel. A szerzők hallgatólagos tudomásulvétele ebben az esetben nem érvényes, hiszen ez esetben a művükkel kapcsolatos semmilyen más jogot, érdekvédelmet nem gyakorolhatnak.15 A név feltüntetésének vagy éppen fel nem tüntetésének joga még egyszer nevesítetten is felmerül, mikor is egy másik személyhez fűződő jogtól, a mű alapos okból történő visszavonáshoz kapcsolódó jogtól fosztja meg a szerzőt a törvény, amennyiben munkaviszonyban alkotott műről van szó. Nehézsége azonban jelen jogosultság érvényesítésének, hogy a bírói gyakorlat

ezzel kapcsolatos szoftveralkotásra vonatkozó állásfoglalása nem ismert és a fejlesztők az esetek jelentős részében egyáltalán nem tudnak arról, hogy ilyen jellegű joguk van. A „tudatos szerző” megteremtésének feladata közvetetten állami kötelezettség, hiszen a jogkövetés/jogérvényesítés alapvető feltétele, hogy ezen jogosultságokat az érintett felek ismerjék. 12 GPL 2. pont, a, bekezdés Szjt. 12 §, (3) bekezdés 14 Tisztességtelen szerződési feltétel gyanús eset. 15 i.m 82 o 13 2009. június 15 21 Nyilvánosságra hozatal joga Alapesetben a szerző nyilvánosságra hozatali jogát egyoldalú jognyilatkozattal is gyakorolhatja, különösképpen a törvény által is említett speciális – a felhasználási szerződés írásba foglalása alól is mentesítő – esetekben, így a napilapban vagy folyóiratban való közlés, illetve a szoftver kereskedelmi értékesítése vagy az online közzététel.16 Érdekes kérdést vet fel,

hogy vajon korlátozott funkciójú szoftverek reklám célú (nem kereskedelmi) forgalombahozatala „nyilvánosságra hozatalt” vagy „előzetes tájékoztatást a mű tartalmáról” jelent-e? Ha egy számítógépes játék alkotója a tájékoztatásra engedélyt ad, vagy az esetlegesen a már megkötött felhasználási szerződés alapján az arra jogosult tájékoztatja a nyilvánosságot „megfelelő módon”, akkor minden rendben lévőnek látszik, kérdéses azonban, hogy mi minősül megfelelő módú tájékoztatásnak. Egy számítógépes újságban a játék leírása, vagy annak demo cd-n való rövidített, korlátozott funkciójú (már a nyilvánosságra hozatal határait súroló) bemutatása is? A nyilvánosságra hozatallal kapcsolatos személyhez fűződő jogot szintén korlátozza a törvény azon rendelkezése, mely szerint, ha a mű megalkotása munkaviszonyból eredő kötelesség, annak átadása a mű nyilvánosságra hozásához való

hozzájárulásnak minősül. A kérdés persze ismételten csak az, hogy mit tekintünk átadásnak.17 Félrevezető lehet a szerzői jogi törvény kommentárjának azon álláspontja, mely szerint a visszavonáshoz, illetve a mű további felhasználásának megtiltásához való jog az egyik olyan jogosultság, melyből a szoftver megalkotóját, ugyanúgy, ahogy az adatbázis alkotóját vagy más, munkaviszonyban alkotott művek szerzőit kizárják méghozzá olyan módon, hogy a törvény csak az utóbbiak (azaz a munkaviszonyban alkotók) számára teszi lehetővé, hogy személyes, a visszavonást egyéb esetekben lehetővé tevő (alapos) ok fennállta esetén, alkalmuk legyen visszavonási nyilatkozatba foglaltan legalább nevük mellőzését kérni.18 A kommentár gondolatmenetét követve, konkrét esetben arra a következtetésre juthatunk, hogy ha egy szoftverfejlesztő vállalkozási szerződés keretében ír egy programot, melynek kizárólagos terjesztési és

többszörözési jogát felhasználási szerződés keretében átengedi, akkor nem 16 Szjt. 45 §, (2)–(3) bekezdés, 60 §, (5) bekezdés A munkaviszonyban alkotott szoftverek jogi helyzetének elemzése kapcsán még visszatérünk a problémára. 18 „Eleve nem illeti meg a szerzőt a visszavonás és a további felhasználás megtiltásának joga egyrészt a munkavállalóval szemben a munkaviszonyban alkotott művekre (30. §), másrészt a felhasználóval szemben az olyan művekre, amelyekre az a vagyoni (engedélyezési) jogokat is megszerezte (a 30 § mellett az 58, 61, 63, 66 § esetei).” im 78 o 17 2009. június 15 22 marad lehetősége arra (semmiféle esetben sem), hogy az esetleges későbbi programpéldányokról legalább nevének mellőzését kérhesse. Ugyanakkor észre kell venni, hogy ez csak a klasszikus visszavonási jog kizárását jelenti, amennyiben a név feltüntetésének vagy fel nem tüntetésének kérdése a személyhez fűződő jogokat

érinti, az alkotónak lehetősége van rá, hogy eldöntse, vajon kívánja-e a nyilvánosságra hozott művön feltüntetni a nevét19 , és amennyiben érdekmúlás következtében neve fel nem tüntetését kéri – az önrendelkezési jog figyelembevétele mellett – erre számára lehetőséget kell biztosítani.20 A mű integritásának (egységének) védelme Ha valamely művet eltorzítanak, megcsonkítanak, illetve más olyan módon megváltoztatnak, vagy csorbítanak, amely a szerző becsületére vagy hírnevére sérelmes, az a szerző személyhez fűződő jogainak sérelmét jelenti. A törvény pontos szövege két értelmezést enged21 , de ezek közül (véleményem szerint) – lévén, hogy szintén a szerző érdekeit szem előtt tartva kíván értelmezést a szöveg – a becsületre és hírnévre sérelmes kitétel nem vonatkozik az első felsorolásra, azaz a műbe történő közvetlen beavatkozás (szoftverek forráskódjának károsító

megváltoztatása) eltorzítás, megcsonkítás minden esetben sérti a szerző jogait, a második kategória feltételez egy többlet elemet, azaz (az általános személyhez fűződő jogok védelméből már ismert) becsület és hírnév megsértését. (A FLOS szoftverek freeware vagy shareware termékként, esetleg kereskedelmi szoftverként való bemutatása.) Érdekes kérdést vet fel azonban, hogy ha a fejlesztők egymással nem egyeztetnek, és az átdolgozás joga a licenc alapján bármilyen átdolgozásra jogosít, élhet-e integritásvédelemmel kapcsolatos jogával az eredeti szerző, amennyiben a mű átdolgozását sérelmesnek találja? Itt két jog ütközik meg egymással: egyrészt a mű eltorzítása elleni védelem, illetve másik oldalról az átdolgozás jogos igénye között húzódik a határ. A német törvény kimondja, hogy a mű felhasználási jogosultságot nyert személy általi olyasforma meg19 Szjt. 12 § Tegyük fel, hogy egy ismert és elismert

nevű szabad szoftver programozó egy közös mű egyik alkotója. A szoftver olyan jól sikerül, hogy az eredeti tervtől eltérően nem csak belső használatra kívánják a szerzőtársak alkalmazni. A szabad szoftveres programozó, hogy hírnevét megőrizze, nem kíván kereskedelmi forgalomban megjelenő szoftver szerzőjeként feltűnni. Ha nem akar a joggal való visszaélés csapdájába esni, nem marad más megoldás, minthogy nevének mellőzését vagy álnéven történő megjelenését kérje. Ennek joga pedig a szerzői jog szellemiségéből kiindulva meg kell, hogy illesse. 21 i.m 88 o 20 2009. június 15 23 változtatásai, melyekhez a szerzőnek a „treu und glauben” elvet követve hozzájárulását meg kellene adnia, engedélyezettek.22 A magyar szabályozásban szintén jelen van ez a részlet23 , habár csak áttételesen, a polgári jog általános szabályait figyelembe véve, hiszen amennyiben a mű megváltoztatásához való hozzájárulás

megtagadása az integritásvédelemre hivatkozva történik, és ezzel a programon felhasználási jogot nyert személy az őt megillető – a szerzői jogi törvény speciális szabálya által nyert24 – jogát (jogot a szoftver rendeltetésével összefüggő átdolgozásra) nem érvényesítheti25 , az ismert joggal való visszaélés26 esete látszik kirajzolódni. A bíróságnak szakértők rendelésével kell majd megállapítania, hogy a kívánt változtatás valójában minek minősül Azaz szükségszerű módosításnak minősüle, melyről való rendelkezés az alkotó rendelkezési jogán túlmutat, és amely adott esetben a felhasználóra szállt át, vagy személyhez fűződő jogosultságot sértő cselekmény, melyről rendelkezni kizárólagosan a szerző joga. Mivel e kérdésben szoftverek vonatkozásában a jogalkalmazó nem foglalt állást, az első néhány döntés különös jelentőséggel bírhat. Ugyancsak érdekes kérdés, hogy milyen jogi

megítélés alá tartozik a probléma, mikor egy munkaviszonyban álló programozó munkaviszonya pont azért szűnik meg, mert nem hajlandó az általa alkotott programot a munkáltató utasításának megfelelő módon átírni, hiszen nézete szerint az az eredeti művet sértő változtatás. Az egyet nem értő szerző esetében is fenntartja a munkáltató változtatási jogát a szerzői jogi törvény, felkínálva azonban a lehetőséget a név mellőzésére. Viszont – és kérdésünk erre vonatkozik – mi történik, ha a szerző ahelyett, hogy élne az anonimitás jogával, munkaviszonyát megszünteti. Várhatóan a rá szignált feladatot egy másik programozóra osztják, aki erkölcsi aggályok nélkül fogja – átdolgozóként szintén szerzői jogot nyerve – módosítani a művet. Vajon mennyire jelenti a mű egységének sérelmét, ha a későbbiekben – törvény adta felhatalmazással – a programot az alkotójánál kevésbé szakavatott személy

módosítja, tevékenységével eltüntetve esetlegesen egyes funkciókat. Felhasználói oldalról nézve arra a problémára kell megoldást találni, hogy míg kereskedelmi forgalomban értékesített szoftvereknél a programban ilyen 22 § 39 (2) „Änderungen des Werkes und seines Tietels, zu denen der Urheber seine Einwilligung nach Treu und Glauben"nicht versagen kann, sind zulässig.” 23 Szjt. 50 § Ha a szerző a mű felhasználásához hozzájárult, a felhasználáshoz elengedhetetlen vagy nyilvánvalóan szükséges, a mű lényegét nem érintő változtatásokat köteles végrehajtani. Ha e kötelezettségének nem tesz eleget, vagy nem tud eleget tenni, a felhasználó a változtatásokat hozzájárulása nélkül is végrehajthatja. 24 59. §, (1) bekezdés 25 Például abban az esetben, ha a szerződő felek a törvényi lehetőséggel élve mégis a szerző kizárólagos jogát állapították meg az átdolgozásra vonatkozóan. 26 Ptk. 5 § 2009. június 15

24 módon generált hibákért, szerzőktől függetlenül, így is, úgy is a gyártót (azaz a szoftverházat magát, aki c nevét adja hozzá) vonhatjuk – vonhatnánk felelősségre27 , addig olyan szoftvereknél, ahol nem áll a fejlesztők mögött gyártó vagy támogató szervezet, a szavatossági jogok érvényesítése jelenleg nehézkes vagy lehetetlen.28 S bár egyesek szerint a harmadik évezred hajnalán megállapíthatóvá vált, hogy a copyright rendszerre jellemző védelem, azaz a szoftverekkel kapcsolatos jogosultságok elvesztik a személyhez fűződő jogok jellegzetes szerzőhöz kötöttségét, és inkább a befektetők védelmét helyezik előtérbe29 , a folyamat nem tűnik visszafordíthatatlannak, hiszen a FLOS szoftverek támogatása és elterjedése esetén a személyhez fűződő jogok visszanyerhetnék eredeti fényüket tekintettel arra, hogy ezeknél a fejlesztéseknél kifejezetten nagy jelentősége van az alkotó személyének. Vagyoni jogok

Jelen esetben a vagyoni jogi jogosultságok közül csupán azok a jogosultságok kerülnek kiemelésre, amelyek a szoftverek felhasználásánál alapvető szerepet játszanak. Többszörözés A Szoftver Irányelv 4. cikkely, (1) bekezdés a, pontja értelmében: „a számítógépi program bármely eszközzel és bármely formában, részben vagy egészben történő tartós vagy időleges többszörözése. Amennyiben a számítógépi program betáplálása, megjelenítése, futtatása, továbbítása vagy tárolása szükségessé teszi az ilyen többszörözést, az ilyen cselekményhez szükséges a jogosult engedélye.” A többszörözés – függetlenül attól, hogy milyen módon történik – engedélyköteles. Kivételt képeznek ez alól a biztonsági másolat30 készítések, azon többszörözések, amelyek a szoftver rendeltetésével összhangban történnek31 , illetve a szoftverek közötti együttműködés feltételeinek megteremtéséhez elengedhetetlenül

szükséges mértékben történő többszörözés32 . 27 Elegendő csak a termékfelelősség, illetve az alkalmazottért való felelősség szabályaira gondolni. 28 Nyilvánvalóan abban az esetben, ha FLOS szoftvereket kíván a kormányzat a közigazgatásba bevezetni, gondoskodnia kell arról, hogy a megfelelő szintű támogatás, illetve a fejlesztések biztosítása megoldott legyen. 29 Thomas Dreier: Urheberrecht an der Schwelle des 3. Jahrtausends in : CR 2000/1 46. o (45–49) 30 Szjt. 59 §, (2) bekezdés 31 Szjt. 59 §, (1) bekezdés 32 Szjt. 60 §, (1) bekezdés 2009. június 15 25 Többszörözésnek minősül tehát a szoftver egyes hordozókra, merevlemezre, bármilyen online tárhelyre másolása. Terjesztés A szerző kizárólagos joga, hogy művét terjessze, és hogy erre másnak engedélyt adjon. Terjesztésnek minősül a mű eredeti példányainak a nyilvánosság számára történő hozzáférhetővé tétele forgalombahozatallal vagy

forgalombahozatalra való felkínálással.33 A terjesztés megvalósulásának formái többek között: – a műpéldány tulajdonjogának átruházása; – a műpéldány bérbeadása; – a műpéldánynak az országba forgalombahozatali céllal történő behozatala; – a mű egyes példányainak nyilvánosság részére történő haszonkölcsönbe adása. A többszörözés és terjesztés joga gyakorlatilag összeolvad, hiszen a terjesztés előfeltétele, hogy a műpéldányok létrejöjjenek, illetve a többszörözésre34 terjesztési célzattal kerül sor. A „forgalombahozatal” fogalma nem egyenlő a kereskedelmi forgalombahozatal fogalmával, hiszen a műpéldány az adásvételen kívül még számtalan formában kerülhet „forgalomba”, ahogy ez a FLOS szoftverek esetében történik is. Jogkimerülés35 „A program valamely példányának a jogosult által vagy az ő hozzájárulásával a Közösségen belül történő első eladása kimeríti az adott

példány Közösségen belüli terjesztésére vonatkozó jogot, a számítógépi program vagy valamely másolata további bérbeadásának ellenőrzéséhez való jog kivételével.” 36 Gyakran előfordul szoftverlicencekben, hogy a jogkimerüléssel kapcsolatos szabályok megkerülésére törekszenek a szoftverházak, különféle szankciókhoz kapcsolva a továbbértékesítést. Ugyanakkor a nemzetközi jogalkalmazói döntések azt mutatják, hogy e kikötések semmisek (A magyar szabályok szerint is az ilyen jellegű korlátozás törvényi szabályozásba ütköző kitétel.37 ) 33 Szjt. 23 §, (1) bekezdés Szjt. 47 §, (4) bekezdés 35 A jogkimerülés szoftverekkel kapcsolatos részletes elemzését lásd Dr. Dudás Ágnes : Szerződésszövevény avagy a licencekkel kapcsolatos joggyakorlat aktuális kérdései. in : Infokommunikáció és jog 2009. február 36 Szoftver Irányelv 4. cikkely (2) bekezdés 37 Ptk. 200 §, (2) bekezdés 34 2009. június 15 26

Nyilvánossághoz közvetítés lehívás útján38 Ez az interneten való közzétételt meghatározó jogosultság, ez az a vagyoni jog, amely leginkább érinti és meghatározza a FLOS szoftverek körülményeit. A felhasználás szabályait itt határozzák meg a GPL vagy más licenc keretében, amely a felhasználás módját, mértékét, formáját meghatározó engedély Átdolgozás Szoftverek esetében az átdolgozás joga az egyik legfontosabb jogosultság. Ha a felhasználó ezt a jogot nem nyeri el, kiszolgáltatott helyzetbe kerülhet, hiszen a szerző/vagyoni jogi jogosult egy-egy egyedi szoftver esetében a kódot nem adja ki, az egyes fejlesztéseket (átdolgozásokat) pedig egyre magasabb díjért hajtja végre. A törvény próbál enyhíteni az átdolgozási jogtól való függőségen, amikor kimondja, hogy eltérő megállapodás hiányában a szerző kizárólagos joga nem terjed ki az átdolgozásra, fordításra, a szoftver bármilyen módosítására – ide

értve a hiba javítását is –, valamint ezek eredményének többszörözését annyiban, amennyiben e felhasználási cselekményeket a szoftvert jogszerűen megszerző személy a szoftver rendeltetésével összhangban végzi.39 Megfelelően nagy rendszerek esetében a kiváltás lehetősége egy idő után már nem merül fel alternatívaként, hiszen az eredeti fejlesztési beruházáshoz szükséges költségkeret többé nem áll rendelkezésre. Ezért maradnak a megalkuvások, illetve azok a „kontár” megoldások, mikor az eredeti szoftvert próbálják funkcionalitásában más fejlesztőkkel – külső modulokkal – bővíttetni. Megdöbbentő, hogy egy-egy rosszul megfogalmazott szerződés miatt végrehajtók jelenhetnek meg a Magyar Államkincstárnál40 , vagy akár százmilliós nagyságrendeket is képes elveszíteni a közigazgatás. A forráskód Az átdolgozás jogához hozzátartozik a forráskód megismerésének joga is. A forráskód átadásának

szerepe igen jelentős Piaci viszonyok között a kód kiadása és az átdolgozási jog átadása 5–10-szeres szorzót jelent a jogosítás esetén. További növelő tényező, ha az átdolgozott állományra vonatkozóan a területileg korlátlan többszörözési és terjesztési jogokat is megszerzi a felhasználó. Amennyiben a felek a kód átadásának és átdolgozásának lehetőségét speciális feltételekhez kötik – például a fejlesztő cég megszűnése, felszámolása, valamely hibajavítási idő indokolatlan elhúzódása – a kódot ügyvédi letétbe helyezik. 38 Szjt. 26 §, (8) bekezdés Szjt. 59 §, (1) bekezdés 40 http://hvg.hu/itthon/20090312 allamkincstar vegrehajto szoftveraspx 39 2009. június 15 27 Természetesen FLOS szoftverek esetében ez a probléma nem áll fenn, hiszen a kód igény esetén átadásra kerül. 3.12 Vagyoni jogi jogosult A szoftver megrendelője Ahogy arra a kollektív mű fogalmának magyarázatánál utaltunk, egy-egy

nagyobb szoftvermegrendelés esetében a vagyoni jogi jogosultságok átszállásáról beszélhetünk. A közteherszabályok értelmezésénél játszik majd nagyon fontos szerepet, hogy a szoftverrel kapcsolatosan a megrendelő vagyoni jogokat vagy csak a felhasználási jogok széles tárházát szerezte-e meg. A programozó munkáltatója A legegyszerűbb módja annak, hogy a szoftveren fennálló legteljesebb jogosultságokat valaki megszerezze, az az, ha a fejlesztőt munkavállalóként alkalmazza, ugyanakkor a közteher szabályok miatt előfordul, hogy alkalmazásban álló fejlesztőkkel is külön felhasználási szerződést köt a munkáltató. A szerzői jogi törvények általában véve munkaviszonyban alkotottnak minősítik azokat a műveket (így a szoftvereket is), melyek elkészítője és később vagyoni jogi jogosultja közötti, a munkavégzést rendező viszonyt a Munka törvénykönyve41 , a Közalkalmazotti42 , illetve a Köztisztviselői törvény43

rögzíti. Ám az ezekhez pusztán hasonlító szerződési formák esetében (ellentétben az APEH iránymutatásaival) nem állapítható meg munkaviszony léte, s így a művekre vonatkozó vagyoni jogosultságok automatikus átszállása sem. Ennek oka a szerzői jogi törvény szerzővédő értelmezési elve lehet A Legfelsőbb Bíróság egyik döntésében44 kimondta, hogy: Az APEH „az Art. 1 §, (7) bekezdése alapján valóban elvégezheti a megkötött szerződések adóügyi minősítését, de helyesen jutott az elsőfokú bíróság arra a következtetésre, hogy ez önkényes értelmezésre nem vezethet. Az Szjt 30. §, (1) bekezdés, 58 §, (4) bekezdés alapján helytállóan jutott arra a következtetésre, a jogszabály nem zárta ki, hogy a felperes és a szerzők felhasználási szerződést kössenek, amely értelmében a szerzőket szerzői jogdíj illette meg. A felperes a bírósági eljárás során megfelelő gazdasági indokát adta annak, hogy a

fejlesztőknél ezt a fajta jövedelmezést alkalmazta. A felperes megfelelően igazolta a perben, hogy szerzőhöz köthető fejlesztések történtek.” 41 1992. évi XXII törvény 1992. évi XXXIII törvény 43 1992. évi XXIII törvény 44 Legf. Bír Kfv I 35 489/2006 42 2009. június 15 28 Nyilván olyan esetekben, ahol a szerzői teljesítmény külön-külön nem állapítható meg, ott az egyedi szerződéskötésnek nem lehet helye. A szerzői jogi törvény jelenlegi változata azonban nem teszi lehetővé, hogy a munkavállaló fejlesztő „megfelelő díjazásban” részesüljön abban az esetben, ha a munkáltató harmadik személyt jogosít a szoftver használatára45 , döntését azzal magyarázva, hogy a szoftvergyártók oldalán tetemes beruházást igényel a szoftverek előállítása, és ezen befektetés megtérülésének akadályozója lenne, amennyiben a szoftverkereskedelem lényegi elemét érintve a befolyó díjból a szerzőt is részesíteniük

kellene. FLOS szoftverek esetében ez a helyzet nem áll fenn, hiszen itt a fejlesztési költségek a későbbi megrendelések (támogatás, egyedi fejlesztési igény stb.) reményében – vagy egyedi megrendelés alapján – történnek. 3.13 Szoftverspecifikus rendelkezések46 A szoftver visszafejtése A szerző engedélye nélkül is jogosult a program használatára a licencben vagy más módon jogosított felhasználó, vagy ennek megbízottja (tehát nem akárki) – programozó akár munkaköri kötelességként is –, a kód többszörözésére vagy (vissza)fordítására egy speciális információhoz való hozzájutás érdekében. Ezen információ kizárólagosan azon célt szolgálhatja, hogy a visszafejtett szoftvert más szoftverekkel együtt tudja működtetni a felhasználó. A központi fogalom tehát az „interoperabilitás” megteremtése FLOS szoftverek esetében erre nincsen szükség, így az erre fordított idő és költség megtakarítható. A reverse

engineering Azon eljárást, melynek keretében a tárgykódból különféle, a továbblépéshez szükséges információkat nyernek, reverse engineering-nek nevezzük. Ennek egyik eszköze a dekompiláció, ami a tárgykódnak egy visszafordítóprogram segítségével forráskódba visszafordítását jelenti. Ám – lévén, hogy rengeteg fordító (kompiláló) program létezik – amennyiben a visszafordításhoz nem jó dekompiláló programot (azaz nem az eredeti kódolásnak megfelelőt) használunk, a kívánt információk helyett egy értelmetlen és értelmezhetetlen karaktersorhoz jutunk. Ezért általában (ha a fordító program 45 „A szerző munkaviszonyból folyó kötelessége teljesítéseként elkészített szoftverre a 30. §, (3)–(4) bekezdésben foglalt rendelkezések nem vonatkoznak” Szjt 58 §, (4) bekezdés 46 A 3.13 fejezet Dr Dudás Ágnes : A szoftver szerzői jogi oltalma c írása alapján készült 2009. június 15 29 „ujjlenyomata”

(fingerprint) alapján nem képes a fordítást végző azonosítani a programot) egy alap programozási nyelvre, assembly-be fordítunk.47 Ezen lehetőség bármiféle tárgykód esetében fennáll, ám azzal a kockázattal, hogy a szerző kommentár sorait nem nyerjük vissza, és az assembly csak szakember számára olvasható programnyelv. A dekompilált sorokat aztán az esetleges változtatásokat követően természetesen lehet rekompilálni, amely eljárást követően újra tárgykódban lévő programhoz jutunk. A de-, rekompiláció lényegi elemei tehát egyrészt a fordítás, másrészt pedig egy speciális többszörözés. Ezen eljáráshoz való hozzájárulás tehát a szerzőknek általában nem is áll érdekükben. Érthető tehát, hogy a szoftverirányelv elfogadásakor ezen pontok körül alakult ki a legnagyobb vita Különböző előfeltételek együttállása esetében lehet egyáltalán szó ezen eljárások jogszerű alkalmazásáról. Az információhoz

való alternatív hozzájutás hiánya Amennyiben a megkívánt információkhoz szabad hozzájutást biztosít a szerző, a programot nem kell felfejteni. Ahogy erre a FLOS szoftverek esetében példát találunk, hiszen kötelező jelleggel megadják a kódot magát, vagy elérhetővé teszik az Interneten. Ezzel kapcsolatos kérdésként merül fel, hogy milyen tágan értelmezhető az a kitétel, hogy a megkívánt információt „könnyedén megismerhető”-nek tekintjük. Ide soroljuk a régebben nyilvánosságra hozott, ám kis kutatással fellelhető információkat. Azonban a könnyen hozzáférhetőség mindig egyedi mérlegelést megkívánó fogalom. Ellenpéldaként viszont ide tartozhat, ha az az információt további ellenszolgáltatásért cserébe kínálják fel. Az információ megszerzésének oka Alapvető feltétel, hogy a megszerzett információk ténylegesen a programok együttműködtetésének lehetőségét biztosítsák. Minden más céllal történő

visszafejtés engedélyköteles Ugyanúgy nem szabad ötletek megszerzése céljából dekompilálni, mint ahogy jogsértés bizonyítása sem megengedett48 ezen a módon. A felhasználó arra sem jogosult, hogy a szoftver hibáját ezúton bizonyítsa, hiszen – bár az is nemes cél – mégsem felel meg az irányelv és a törvény szövegének, mely egyértelműen csak „önállóan megalkotott szoftver más szoftverekkel való együttes működtetéséhez szükséges információ meg47 Érdekességként megjegyzendő, hogy az első disassembler körülbelül 1950-ből származik. 48 Dreier: GRUR 1993, 781–785 o. 2009. június 15 30 szerzés érdekében” járhat el. A szabályozáson látszik, hogy alku eredménye, hiszen a visszafejtés nem használható sem a felhasználó érdekeit közvetlenül szolgáló testre szabás céljából, sőt még kutatási célokból sem. Érdekes azonban, hogy a kompatibilitás követelményéből kifolyólag a viszszafejtés abban az

esetben engedélyezett, ha a szoftvert egy konkurens programmal akarják együttműködésre bírni.49 Ugyancsak speciális eset a hardverrel való együttműködés, „együttműködtetés”, hiszen a szöveg szó szerint csak szoftverekhez való illesztést engedi. A mai modern hardverelemek lehetővé teszik a szoftverek hardveres implementálását, azaz szoftver feladatok hardverben történő ellátását. Ez pedig indokolttá tenné a dekompilálás engedélyezését ebben az esetben is Hiszen ennek elmaradása a piac megosztásához50 vezethetne, ami versenyjogi aggályokat vetne fel A szoftvergyártók általában ellátják terméküket egy interface specifikációval, mely esetenként azonban nem teljes körű, így a visszafejtés elkerülhetetlen. Ám az abból nyert információk (akár az interface alkotó kódja is) a visszafejtő rendelkezésére állnak. Ezek közül azonban a szabályozás alapelvének megfelelően elsődlegesen a specifikációt kell

kiegészíteni és azt használni, nem pedig a konkrét kódot átemelni. A személyi kör A dekompilálás három személyt érinthet: 1. A felhasználási szerződésben jogosítottat, vagy 2. a szoftver felhasználására jogosult más személyt (például munkaviszony alapján eljárót), illetve 3. ezek megbízottját, aki semmiféle közvetlen viszonyban nem áll a szerzővel Ezen személy eljárási jogosultságát elég egy polgári jogi jogviszonnyal igazolni A személyi kör utolsó elemmel való kibővítését az tette szükségessé, hogy a dekompilálás speciális tudást igényel. Az információ terjedelme A szükséges programrészek jelentik az információ megismerésének határát. Feltétlen megismerést igénylő, tehát az együttműködéshez szükséges 49 50 Kommentar – Grützmacher : Rn. 10 746 o Egyes hardverelemek csak bizonyos szoftvercsoportokkal futnának együtt, ami termék összekapcsolódásokhoz vezetne. 2009. június 15 31 információt

tartalmaznak, például a (hivatalos és nem hivatalos51 egyaránt) csatlakozófelületek (interface).52 A dekompilációt végző személytől elvárható, hogy a kézikönyvek és a rendelkezésre álló irodalom információi alapján kiderítse, hogy melyik programrészt kell dekompilálni. Egyes – az újabb programokra egyre jellemzőbb – megoldások esetében (melyek könyvtárak bevonásával dolgoznak) ez a hely könnyebben meghatározható, azaz nem kell valamennyi könyvtárat visszafordítani. Más esetekben viszont, mikor szorosan összefüggő programszövegről van szó, felmerülhet a teljes fordítás elkerülhetetlensége. A vizsgálat terjedelmi korlátait mindig speciális vizsgálat keretében kell ellenőrizni, vizsgálni kell, hogy adott szakértelem mellett előre látta-e vagy láthatta-e, hogy a program mekkora részének visszafordítása szükséges. Azonban még annak sincs kialakult gyakorlata, hogy a terjedelmi korlátok „túl nem lépését” ki

köteles bizonyítani. A megismert információ szabadsága A szerző érdekeinek védelme szükségessé teszi, hogy a visszafordítás keretében elnyert információ ne legyen továbbadható. Ezen védelmi szint még abban az esetben is fenntartandó, ha más felhasználók ismételt visszafordításokra lesznek kénytelenek, melyek végeredményeként természetesen ugyanazon eredményeket kapják. Ezen korlátozás olyannyira kereteket jelent, hogy a megtalált interface nem adható közre a szakirodalomban, ugyanakkor az általunk írt program kézikönyvében megjelenhet, hogy hogyan tehető kompatibilissé adott esetben egy operációs rendszerrel a programunk. Egyedi megoldás, hogy ha a szerzői oldalról visszaélést tapasztalnak vagy piacuralmi helyzet áll fenn, a kartelljogi szabályokra hivatkozva követelhető a lényeges információk közreadása.53 51 Ezen megkülönböztetés versenyjogilag lehet releváns, hiszen a nem hivatalos interface-ek arra szolgálnak,

hogy azokat csak maga a gyártó használhassa. Más programok esetlegesen az operációs rendszerrel való együttműködése megkívánhat rövidebb válaszidőket, mint amit a hivatalos változat lehetővé tesz, ám a program maga, pont fejlesztői igények miatt képes a rövidebb válaszidők produkálására, és ez a dekompilálás folyamatában felismerhetővé válik. Kérdés, hogy az ilyen „javítása” a program teljesítményének, vajon nem ütközik-e az engedélyköteles átdolgozás kategóriájába. Ennek ellentmondani látszik, hogy ezen lehetőségek szemfüles felhasználása a program mellett futtatható segédprogrammal – tehát az eredeti forráskód érintetlenül hagyása mellett lehetséges. 52 Lietz, Bernd: Technische Aspekte des Reverse Engineering in : CR 1991/9 564. o 53 Kommentar – Grützmacher: Rn. 28 752 o 2009. június 15 32 Az utánozási tilalom Ismételt tilalomként jelenik meg, a nyomatékosság kedvéért, hogy a megszerzett

ismeretek alapján nem lehet egy, az eredetihez hasonló programot létrehozni, sem olyat, mely hasonló elvekre épülne, vagy hasonló funkciókkal lenne ellátva. Ez voltaképpen versenyjogi kérdésnek tekinthető Kétségtelenül tisztességtelen piaci magatartást testesítene meg a fél, aki az említett módon hozzájutva az információkhoz kezdi meg konkurens szoftver terjesztését.54 Ez azonban nem jelenti azt, hogy ne lehetne – az eredeti használata nélkül – alkotni egy másikat, hasonló céllal, hiszen ezen tilalom léte teljesen monopolizálttá tenné a piacot. Egyetlen operációs rendszer működne, amin egyetlen szótárprogramot és egyetlen könyvelőprogramot lehetne futtatni, de mivel az ötletek nem védettek, így lehetőséget kell biztosítani másnak is hogy egy adott probléma megoldására szoftvert fejlesszen. Így kerülhetett tehát sor arra, hogy a kereskedelmi szoftvereknek megjelentek FLOS alapú párjai, és szinte valamennyi területen el

is terjedtek. 3.14 A jogsértés Jogainak megsértése esetén a szerző vagy a vagyoni jogok jogosultja a jogsértővel szemben polgári jogi igényeket55 támaszthat.56 FLOS szoftverek esetében a többnyire a következő igények érvényesítésére kerül sor: – követelheti többek között a jogsértés megtörténtének bírósági megállapítását, – követelheti a jogsértő cselekmény abbahagyását, és a jogsértő eltiltását a további jogsértéstől, – követelheti, hogy a jogsértő adjon elégtételt. Az eddigi ítéletek alapján a jogsértést megállapította a bíróság minden alkalommal, mikor egy GPL alá tartozó szoftvert anélkül használtak fel, hogy a GPL szerződést mellékelték és a szerzőket megjelölték volna. 54 1996. évi LVII törvény a tisztességtelen piaci magatartás és a versenykorlátozás tilalmáról „2. § Tilos gazdasági tevékenységet tisztességtelenül – különösen a versenytársak, a fogyasztók törvényes

érdekeit sértő vagy veszélyeztető módon vagy az üzleti tisztesség követelményeibe ütközően – folytatni.” 55 Szjt. 94 §, (1)–(2) bekezdés 56 A szoftverrel kapcsolatos jogérvényesítés nehézségeinek elemzésével kapcsolatos részletes irodalom: Dudás Ágnes, Gyenge Anikó, Kabai Eszter : A kereskedelmi és a szabad szoftver szerzői jogi és szabadalmi oltalmáról (MTA Jogtudományi Intézet Infokommunikációs Jogi Centrum) megjelenés alatt (KJK KERSZÖV) 2009. június 15 4. fejezet A szabad szoftver fogalma Az interneten egyre gyakrabban találkozhatunk a szabad szoftverek köznyelvi meghatározásaival, kitűnik az is, hogy az „ingyenesség” és a „szabadság” fogalma keveredik. Ennek kapcsán Richard M Stallman híres mondását idézném, aki azt hangsúlyozza, hogy a szabad szoftver a „szabadság” és nem pedig az ár kérdése. Ebben az értelemben a szabadságra, mint a szólásszabadságra kell gondolnunk, nem pedig mint az ingyen

sörre1 4.1 A szabad szoftverrel kapcsolatos definíciók A szabad szoftvernek négy fogalmi eleme van, amelyek együttállása esetén az elvárt „szabadság” megvalósul. A fogalmi kritériumokat a Free Software Foundation2 határozta meg, és a szoftverek minősítését is ő végzi. Ezek a következők: – A program bármilyen céllal történő futtatásának joga. – A program működésének tanulmányozásához való jog, valamint jog arra, hogy a programot a szükségleteikhez (precondition) igazíthassák. Ennek előfeltétele a forráskód elérhetősége.3 1 „Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer.” http://wwwgnu org/philosophy/free−sw.html fordítás : „a szabad szoftver a szabadság és nem pedig az ár kérdése. Ebben az értelemben a szabadságra, mint a szólásszabadságra kell gondolnod, nem pedig mint az ingyen sörre” (Angolban a free kifejezés

egyaránt jelenti, hogy valami ingyenes és szabad.) Stallman ezért az „ingyenes” fogalom angol megfelelőjeként tudatosan, mint a „gratis” kifejezést használja. 2 http://www.fsforg/ 3 Ez valójában egyezik a szerzői jogból ismert „átdolgozás” jogával. 33 34 – Másolatok terjesztésének joga, a felebarátok megsegítése érdekében.4 – A program tökéletesítésének, módosításának joga, valamint ezen javított kiadás – az egész közösség javát szolgálandó – közzétételének joga. Ennek előfeltétele a forráskód elérhetősége. Az angolszász modell szerint 3 fő vonulatát különböztethetjük meg a szabad licenceknek: 1. Közkincs (Public Domain) – e körbe (magyar viszonylatban) azok a művek tartoznak, amelyekre vonatkozóan az oltalmi idő lejárt Az angolszász jogrend lehetővé teszi emellett, hogy az alkotó a művét közkinccsé nyilvánítsa. (Ennek magyar megfelelője, ha az alkotó olyan általános felhasználási

engedélyt ad, amely következtében a public domain-nel azonosan – teljeskörűen – jogosít. 2. BSD jellegű licencek – az eredeti BSD ( „Berkeley Software Distribution”) licenc5 alapján azokat a licenceket soroljuk ide, amelyek lehetővé teszik többek között azt is, hogy az általuk jogosított tartalmat más licenc alatt tegye közzé az azt felhasználó személy. 3. Copyleft irány – ez jelenti a GPL-típusú licencmodelleket, ahol a felhasználás feltételei meghatározott mértékben korlátozottak A Szabad Szoftver Alapítvány (FSF) a 4.1 ábrával6 szemlélteti a szoftverek elhelyezkedését A fent nevezett angolszász modell mellett létezik az EU saját „megoldása”, az Európai Uniós Nyilvános Licenc ( „European Union Public Licence – EUPL”), amely kidolgozására az IDABC7 közösségi program keretében került sor, és amelynek jelenlegi aktuális állapota az 1.1 verzió A licenc magyar nyelvű szövege a B mellékletben olvasható Az

IDABC célja az, hogy a páneurópai e-kormányzati szolgáltatások közigazgatási szervek, üzleti vállalkozások és polgárok részére az interoperabilitás lehetőségét nyújtsa. 4 Ez a szerzői jogi szabályozás körében a többszörözés és a terjesztés jogának megfelelője. 5 http://www.opensourceorg/licenses/bsd−licensehtml 6 Chao-Kuei ábrája, http://www.fsforg/licensing/essays/categorieshtml 7 Az IDABC a korábbi IDA-program (a közigazgatási rendszerek közötti elektronikus adatcsere) folytatása és továbbfejlesztése. 2009. június 15 35 Free Software Proprietary Public domain XFree86 Style Closed Copylefted GPL’ed Shareware Open Source Free Download 4.1 ábra A szoftverek elhelyezkedése 4.2 A szabad szoftver és a nyílt forráskódú szoftverek elhatárolása A szabad szoftverek és a nyílt forráskódú szoftverek – dacára annak, hogy a köznyelvben gyakorta szinonimaként használják őket – nem azonosak. A nyílt forráskód

követelménye a 2.1 pontban ismertetett modellnek egy lényegesen leegyszerűsített változata A Szabad Szoftver Alapítvány honlapján folyamatosan közzétesz egy listát, amelyen feltünteti, hogy mely licencek nem felelnek meg a „szabadság négy alapelvének.” 8 4.21 A nyílt forráskódú szoftverek definíciója A nyílt forrás nem csak a forráskódhoz való hozzáférést jelenti. A nyílt forráskód fogalmának meghatározása, valamint a szoftverek minősítése az Open Source Initiative9 által történik, melynek alapítói: Eric S. Raymond és Bruce Perens. 8 9 http://www.fsforg/licensing/licenses/#NonFreeSoftwareLicense http://www.opensourceorg 2009. június 15 36 A nyílt forrású szoftver terjesztési feltételeinek meg kell felelniük az alábbi követelményeknek: 1. Szabad terjeszthetőség A licenc nem korlátozhatja a szoftver értékesítését vagy továbbadását több, különböző forrásból származó programot tartalmazó gyűjtemény

elemeként. A licenc nem követelhet meg ilyen jellegű terjesztés vagy eladás után fizetendő jogdíjat, egyéb díjat vagy illetéket. 2. A forráskód elérhetősége A programnak tartalmaznia kell a forráskódot is, valamint engednie kell a forráskód és a lefordított, futtatható kód terjesztését is. Ha a terméket a forráskód nélkül terjesztik, akkor a forráskódnak méltányos áron elérhetőnek kell lennie (az ár nem lehet magasabb, mint a másolás indokolt költsége). Ajánlott megoldás, hogy a forráskódot az Interneten külön díj nélkül letölthetően közzétegyék. A forráskód formája olyan legyen, ahogyan azt egy programozó írná. Szándékosan összekuszált forráskód nem engedélyezett. A forráskód továbbá nem lehet semmiféle köztes formátum, például előfeldolgozó (preprocesszor) vagy kódátalakító (transzlátor) kimenete. 3. Származtatott művek létrehozásának engedélyezése A licencnek lehetővé kell tennie a

módosításokat és a származtatott művek előállítását, valamint ezek terjesztését az eredeti program licencével megegyező feltételek mellett. 4. A szerző forráskódja sértetlenségének biztosítása A licenc csak abban az esetben korlátozhatja a módosított forráskód terjesztését, ha megengedi, hogy a forráskódot a fordításkori változtatásokat szolgáló módosító „patch”-állományokkal együtt terjesszék. A licenc megkövetelheti, hogy a származtatott műveknek más nevet vagy verziószámot adjanak. 5. Személyek vagy csoportok megkülönböztetésének tilalma A licenc nem tehet megkülönböztetést személyek vagy személyek csoportjai tekintetében. 6. Különböző felhasználási területek megkülönböztetésének tilalma A licenc nem korlátozhatja a program használatának területét vagy szándékát. Például nem korlátozható az üzleti célok megvalósítására, vagy genetikai kutatás céljára történő felhasználás. 2009.

június 15 37 7. A licenc terjeszthetősége A program felhasználását illető jogoknak bármiféle külön engedélyezési eljárás nélkül kell vonatkozniuk minden felhasználóra. 8. A licenc nem vonatkozhat kizárólag egy szoftverre A programhoz fűződő jogok nem függhetnek attól, hogy a program része-e egy adott programcsomagnak. Ha az eredeti programcsomag részét képező programot külön terjesztik, akkor az eredeti programcsomagot használókra érvényes jogoknak kell vonatkoznia azokra is, akik a programhoz külön jutottak hozzá. 9. A licenc nem korlátozhat más szoftvert A licenc nem tartalmazhat olyan korlátozásokat, amelyek a programmal együtt terjesztett más programokra vonatkoznak. Például a licenc nem írhatja elő, hogy az azonos adathordozón található többi program is nyílt forrású legyen. 4.22 A nyitott forráskódú szoftverek Pusztán a tény, hogy egy szoftver kódja megismerhető, nem minősíti a szoftvert sem szabaddá, sem

„nyílt forráskódúvá”, csak nyitott forráskódúvá. Vannak például olyan Microsoft szoftverek, amelyek esetében a licenc (Microsoft Reference Source Licence10 ) a kódot nyilvánosságra hozza, azonban azzal kapcsolatosan további jogosultságokat nem enged. 4.3 A FLOS szoftver és más szoftverek elhatárolása 4.31 Az ingyenes szoftverek Az egyik fontos – a felmérések által igazoltan11 a közigazgatásban is terjedő tévhit –, hogy a FLOS szoftverek azonosak az ingyenes szoftverekkel. Az, hogy bizonyos felhasználási módok ellentételezéseként nem kér az adott szoftver jogosultja díjat, messze nem jelenti azt, hogy a szoftver teljesítené az alapszabadság említett 4 kritériumát. 10 11 http://referencesource.microsoftcom/referencesourcelicenseaspx A megkérdezettek egy része a szabad szoftvereket azonosította valamennyi, az internetről ingyenesen letölthető programmal. 2009. június 15 38 4.32 A felhasználói kör vonatkozásában

korlátozott szoftverek Több licencmodellnél is található felhasználói kör korlátozás. Alapeset, hogy például a Microsoft Home kiadású szoftvereit üzleti környezetben a szoftvert közvetlenül a jogosulttól vásárló személy nem futtathatja.12 4.33 Tisztaszoftver program A School és Campus Agreementek (licencek) keretében megszerzett felhasználási jogot – amellett, hogy időben is korlátozott – csak meghatározott felhasználói körben lehet gyakorolni. School program és Campus program: „A Miniszterelnöki Hivatallal kötött megállapodás értelmében tehát valamennyi felsőoktatási intézmény államilag finanszírozott hallgatója és oktatója jogosult díjmentesen a Microsoft Windows frissítés és az Office 2007 program használatára intézményében és otthonában egyaránt. Ugyanígy jogtiszta az intézmények által működtetett és az államilag finanszírozott hallgatók által használt szervertermékek igénybevétele is. Valamennyi

magyarországi közoktatási intézmény (óvoda, általános iskola, középiskola, kollégium,) jogosult a szoftverek használatára Ehhez jönnek továbbá a tanárok, akik jogtisztán használhatják az asztali szoftvercsomagot az otthonukban is.” 13 Ennél egy kicsit pontosabb meghatározással: „Továbbra is legálisan használhatók a közoktatásban és a felsőoktatásban a Microsoft egyes termékei, miután a Gazdasági és Közlekedési Minisztérium (GKM) és a Microsoft 1 évre szóló licencmegállapodást kötött. A Tisztaszoftver Program keretében 2009. március 1-jéig szóló licencmegállapodást kötött a GKM és a Microsoft A megállapodás értelmében a köz- és felsőoktatási intézmények számítógépein, a felsőoktatási intézmények oktatói, hallgatói és dolgozói, valamint az általános és középiskolák pedagógusai otthoni számítógépein is jogtisztán használhatók a Microsoft Windows Frissítés (upgrade), valamint a Microsoft

Office termékek, valamint Core Cal klienshozzáférési licencek. 12 Érdemes lenne egy kutatás keretében megvizsgálni azt, hogy a jogkimerülés szabályai értelmében lehetőség nyílik-e az ilyen és ehhez hasonló korlátozások semmissé tételére. 13 Meglepő, hogy a közoktatási csomagot bemutató oldalon is csak a felsőoktatási „ingyenes” használat lehetősége került feltüntetésre, de ez nyilván csak elírás. Közoktatás: http://wwwtisztaszoftverhu/index068bhtml?akt menu=238 Felsőoktatás: http://wwwtisztaszoftverhu/index1d3fhtml?akt menu=248 2009. június 15 39 A megállapodás értelmében valamennyi középiskola és Térségi Integrált Szakképző Központ (TISZK) részére 1 példányban biztosított a Középiskolai Tisztaszoftver Szervercsomag, Windows Standard Server, Exchange Standard Server, ISA Standard Server, SQL Server, Office Sharepoint Server. Az ezer hallgatót meghaladó felsőoktatási intézményekben a Felsőoktatási

Tisztaszoftver Szervercsomag, Windows Enterprise Server, Exchange Server, ISA Enterprise Server, SQL Enterprise Server, Office Sharepoint Server. A Tisztaszoftver Program keretében minden, a közoktatásról szóló 1993. évi LXXIX. törvény 20 § és 21 § hatálya alá eső intézmény jogosult a szoftvereket igénybe venni” Az, hogy az oktatási intézményekbe „Tisztaszoftver program” keretében kizárólag a Microsoft által jogosított szoftverek jutnak el, jelentős mértékben hátráltatja az alternatív lehetőségek megismerését és szükségszerűen termékfüggőséget alakít ki. Az, hogy az állam az időben korlátlan felhasználási engedélyeket – amelyek egyébként úgynevezett „használtszoftverként” forgalomképesek voltak – kiváltotta évente megújítandó bérleti viszonnyal, hosszú távon nem feltétlenül jelentkezik, mint „jelentős megtakarítás”. A jelenlegi állapot évről-évre kényszerpályán tartja a Kormányt, hiszen

amennyiben nem újítja meg a megállapodásokat körülbelül 2 000 000 jogosulatlan felhasználást eredményez. A jelenleg hatályos szabályozás alapján ennek komoly büntetőjogi szankciói lehetnek, amelyek a School programban részes kiskorú személyek esetében a szülőket is hátrányosan érintenék. Nyilván egy ilyen súlyú kriminalizálódását a lakosságnak egyetlen kormány sem vállalja/vállalhatja fel, így – amennyiben nem kerül sor az alkalmazások FLOS szoftverekkel történő kiváltására – marad az eredeti koncepció, amelyben milliárdos nagyságrendben kell éves szinten bérleti díjat fizetni. 2009. június 15 40 2009. június 15 5. fejezet A szoftverek nemzetközi megítélése Ahogy Cory Doctorow rendkívül találóan megjegyezte: „When copyright and technology collide, it’s copyright that changes.” 1 A következő példák azt személtetik, hogy azonos (vagy hasonló) jogrendű államok – amelyek a technika fejlődésében

(vagy a fejlődés felismerésében) előrébb járnak, miként szabályozzák a FLOS szoftverek kérdését. 5.1 FLOS szoftverek a kontinentális jogrendben Jelen tanulmány célja, hogy a magyarhoz rendkívül hasonló jogrendszerrel rendelkező államok szabályozástechnikáján át mutassa be a nemzetközi helyzetet. 5.11 Az Európai Unió Az Európai Unió, illetve a Bizottság több részletes tanulmányban foglalkozott az Unió által fejlesztetett nyílt forráskódú szoftverek közzétételének kereteivel. 2003. novemberében az IDA migrációs irányelveinek2 közzététele jelentette az áttörést 1 Ez azt jelenti, hogy amikor a technológiai fejlődés következtében a szerzői jog és a technológia összeütközésbe kerülnek, akkor szükségszerűen a szerzői jogi szabályozásnak kell változnia, hiszen a fejlődés megállíthatatlan. 2 http://blade.eurodyncom/idabc/en/document/2623/5585#migration „IDA Open Source Migration Guidelines” 41 42 Ezt

követte egy tanulmány3 2004 decemberében, amely azt taglalja, hogy a CIRCA licenc leváltása érdekében megvizsgálták a jelentősebb FLOSS4 licenceket (BSD, GPL, MPL, OSL és CeCILL), azonban nem találtak közöttük olyat, amely megfelelne a Bizottság által támasztott igényeknek. Érdekessége még ennek a tanulmánynak, hogy az „open source” kifejezést a „free” kifejezés szinonimájaként használják, azonban a „free” itt sem jelent ingyenességet. A kutatásból, amelyet e körben lefolytattak, kitűnt, hogy a licenchasználat arányai 57 097 projektből kiindulva az 5.1 ábrán láthatóan oszlanak meg. 5.1 ábra A licenchasználat arányai A GPL licenc alá tartozó projektek száma: 39 647 volt, és 6 305 projekthez tartozott LGPL licenc.5 3 Report on Open Source Licensing of software developed by The European Commission, 16th December, 2004, http://ec.europaeu/idabc/servlets/Doc?id= =24394 4 A free/open source software rövidítése 5 i.m Report 6 o

2009. június 15 43 A tanulmány elemzi továbbá, hogy a CIRCA licenc mely okok miatt nem felel meg az alapszabadságokkal kapcsolatos elvárásoknak.6 A tanulmány bemutatja többek között a fent ismertetett választott licencek összehasonlítását táblázatba foglaltan. E megoldás által a licencbeli különbségek könnyen áttekinthetővé váltak.7 Amennyiben Magyarország a közigazgatás területén a FLOS szoftverek használata mellett dönt, értelemszerűen döntenie kell majd arról is, hogy melyik licencet – licenc típust kívánja választani, illetve alkot-e saját modellt a már ismertetett szabadságjogokra építve. A harmadik átfogó tanulmány8 2005-ben készült, és a szabadalmak és nyílt forráskódú szoftverek viszonyát elemzi. Az Európai Unió központi szoftverhasználattal, illetve migrációval kapcsolatos stratégiáját az IDA, később az IDABC projekt tartalmazza.9 Az EUPL licenc megalkotása – ahogy arra korábban már utaltunk –

az IDABC közösségi program keretében történt. „Az IDABC a korábbi IDAprogram (a közigazgatási rendszerek közötti elektronikus adatcsere) folytatása és továbbfejlesztése. Az IDA és IDABC programok keretében különféle szoftveralkalmazásokat fejlesztettek ki, például a zárt csoportokon belüli dokumentummegosztás céljára szolgáló CIRCA nevű groupware-t, IPM nevű eszközt, amely közelebb hozza a közigazgatási szerveket és partnereiket azáltal, hogy hatékony és egyszerűen használható eszközt biztosít az interneten keresztüli közvetlen konzultációhoz, vagy az eLink eszközt, amely hálózati infrastruktúrán keresztül biztosítja a távoli szolgáltatások azonosítását, illetve megbízható és biztonságos üzenetszolgáltatások nyújtását.” 10 Az Európai Közösség a szoftverek kifejlesztését lehetővé tevő szerződések alapján vagyoni jogi jogosultja lett a szoftvereknek (ide értve a forráskódokat és a futtatható

állományokat). Az ilyen IDA és IDABC keretében kifejlesztett eszközöket/programokat az európai intézményeken kívüli közigazgatási szervek az Európai Bizottság által adott licenc alapján használják, mivel az eszközökre vonatkozó vagyoni jogok az Európai Közösséget illetik meg, amelyet a Bizottság képvisel. Egy ideje megnövekedett az érdeklődés a szoftverek forráskódjának olyan licenc alapján történő nyilvánosságra hozatala iránt, amely nem korlátozná a forrás6 i.m Report 7 o Im : Report 32–36. o 8 Enterprise Directorate General IDABC/GPOSS Encouraging Good Practice in the use of Open Source Software in Public Administrations, Patents and Open Source Software: What public authorities need to know, http://www.osoreu/idabc− −studies/expert−docs/patents−and−open−source−software 9 http://blade.eurodyncom/idabc/en/document/2623/5585#migration 10 Az EUPL Preambuluma 7 2009. június 15 44 kód felhasználását és

módosítását. Az eredeti EUPL licencet az IDABC célkitűzéseivel összhangban ilyen szoftverekhez hozták létre A licenc szövegezése általános, így használható származékos alkotásokhoz, egyéb alkotásokhoz, és használhatják más licenciaadók is. E licenc haszna az, hogy a közszféra szoftvereinek összességéhez létrehozott közös keret elfogadásával megerősíti a jogi interoperabilitást.10 5.12 Németország A magyar jogrendszer részben történelmi, részben jogtechnikai okokból – felépítésében és részletszabályaiban is – leginkább a német rendszerhez hasonlít. Szerencsés helyzetben van tehát a magyar jogalkotó, hogy – bár a magyar jogi irodalom e téren szegényes – a FLOS szoftverekkel kapcsolatos szabályozási megoldásokat nem kell a semmiből megteremtenie, és az esetlegesen a bíróságokon kijelölt szoftveres ügyekben eljáró bírói tanácsokat a német joggyakorlat ismertetésével felkészítheti ezekre az

ügyekre.11 Általánosságban A német szerzői jogi törvény12 (a továbbiakban UrhG) 2. §, (1) bekezdés 1, pontjában a szoftvert az írásművek és beszédek mellett a szövegművek „Sprachwerk” kategóriájába sorolja. Ezen besorolásnak az sem mond ellent, hogy a szoftverek egy programozási (azaz mesterséges) nyelven íródnak.13 A német bírói gyakorlat szoftverekhez kapcsolódó két leghíresebb (utólag sokak által kritizált14 ) ítélete az úgynevezett Inkasso-program15 , illetve a Nixdorf– Betriebssystem16 döntés, melyekben a bíróság megállapította, hogy a szoftverek jogi besorolásához a szerzői jog szabályait kell irányadónak tekinteni, továbbá meghatározott bizonyos – a védelmi szint eléréséhez fontos – kritériumokat. Az első döntés, mely közel egy évtizeden át meghatározta a védelem fokát egy inkasszó programmal kapcsolatos, ahol a megrendelő (egy beszedési 11 Az 5.12 rész Dr Dudás Ágnes : A szoftver szerzői

jogi oltalma c írása alapján készült. 12 Gesetz über Urheberrecht und verwandte Schutzrechte vom 9. September 1965 in : Urheber-und Verlagsrecht, Deutsche Taschenbuch Verlag. München 2002 13 Koch: Computer-Vertragsrecht Rn. 1901 14 Kritizálja többek között : Manfred Kindermann : Urheberrechtschutz von Computerprogrammen, Kritische Anmerkung zum Bericht der Bundesregierung zur Urheberrechtsnovelle 1985 in : CR 10/1989 880–887. o 15 Inkasso-program döntés in : NJW 1986 192. o, CR, 1985 22–32 o 16 Betriebssystem döntés in : NJW 1991. 231 o, CR, 1991, 80 o 2009. június 15 45 megbízásokkal foglalkozó cég) megbízott egy másik cégnél dolgozó programozót, hogy számára – az inkasszó eljárást megkönnyítendő – hozzon létre egy szoftvert. A programozó szabadidejében, majdnem kizárólagosan a megbízó telephelyén fejlesztette a programot, melyet aztán forráskódban is, a kapcsolódó dokumentációval együtt átadott a megbízónak. A

szoftvert egy akkor népszerű programozási nyelvben, COBOL-ban írták A programozáshoz szükséges információkat a megbízó bocsátotta a programozó rendelkezésére. A dolgok egészen eddig rendben mentek. Majd a megbízó licencszerződést kötött egy céggel az általa fejlesztetett inkasszóprogramra, a szerzőt pedig megbízta, hogy írjon hozzá kiegészítő programokat. A keletkezett bevételből pedig 10 000 márkát a szerzőnek átadott, aki ezt, mint a licencezéshez való hozzájárulásának ellenértékét tekintette. A gond akkor kezdődött, mikor egy másik, potenciális vevő visszalépett a megbízóval való szerződéskötéstől, mert megegyezett a szerzővel ugyanannak a programnak a megvásárlásáról. A megbízó úgy tekintette, hogy őt a programon kizárólagos használati jog illeti meg, valamint magát társszerzőnek vélte, hiszen a program mintegy fele nem ezen megbízás keretében került megalkotásra. A másik oldal ellenben, mint

egyszerű használati jog átruházását értelmezte a köztük fennálló szerződést, mivel a program „piacra dobásáról” nem volt szó, így az erre vonatkozó rendelkezések hiányoztak a szerződésből. Valamint azt állította, hogy egy jobb, javított programot hozott forgalomba. A per ítélete több ponton is befolyásolta a szoftverekkel kapcsolatos jogi nézőpont kialakulását17 , de jelen részben a Szövetségi Bíróság azon álláspontja kerül csak ismertetésre, mely a számítógépes programok lényegi voltára vonatkozik. Az ítélet első pontként megállapította, hogy a számítógépes programok szerzői jogi védelmet élveznek, függetlenül attól, hogy grafikus vagy szöveges formában kerülnek megjelenítésre, az írásművek között vagy a tudomány és technika megjelenítéseként (a német szerzői jog külön nevesít ilyen kategóriát18 ) rendeli védeni őket. Kimondta, hogy nem feltétel a mű teljessége, és lévén, hogy a

számítógépi program fejlesztése elkülöníthető fejlesztési fokokon nyugszik, azokat részleteiben is megilleti a védelem. A döntés leglényegesebb részét, mely meghatározta a – Szoftver irányelvet követően aztán módosult19 – szintet, úgy foglalhatnánk össze, melyet a bíróság egy olyan teljesítményben határozott meg, amely meghaladta az átlagos programozó képességeit, azaz az információk és utasítások egy tisz- 17 Többek között : átdolgozás problematikája, megszerezhető használati jogok. UrhG §, 2. (7) 19 A védelem foka lényegesen alacsonyabb szinten kerül már meghatározásra. 18 2009. június 15 46 tán technikai, mechanikai (kiválasztás, összegyűjtés, elrendezés és felosztás műveletekre épülő) egymás mellé rendelésénél többet kívánt meg.20 Ugyancsak ezt a meghatározást találhatjuk meg egy 1990-es esetben, ahol az operációs rendszerek továbbértékesítése szolgált a per okául. A bíróság itt

is a rutinszintet meghaladó programalkotást szabta a szerzői jogi védelem feltételéül21 , minden ilyen esetben szakértőkre bízva, hogy mit is jelent a számítástechnika állása szerint az átlag programozói tudás. Hiszen, a programozónyelvek fejlődésével a programok alkotása leegyszerűsödött, az úgynevezett „könyvtárak” megjelenése pedig lehetővé tette, hogy a programok egyes részeit – mintegy a könyvtár részeire való utalással helyettesítve – még rövidebb formában el lehessen készíteni. Az érem másik oldala, hogy egyre bonyolultabb problémák megoldására vált képessé a szoftver, és a számítástechnikai eszközök fejlődése lehetővé tette, hogy akár komolyabb anyagi megterhelés nélkül is olyan felszereltséghez juthassanak a programot írni vágyók, mely gondolataik megvalósításához lehetőséget nyújt. A FLOS szoftverek vonatkozásában 2002-ben fogadta el a német Bundestag a Szabad és Nyílt Forráskódú

Szoftverek jogkérdéseivel foglalkozó intézet (Institut für Rechtsfragen der Freien und Open Soursce Software)22 törvényszöveg-javaslatát, amely – a német szerzői jogi törvény részeként – mint a „Linux Klauzula” 23 híresült el világszerte. A méltányos díjazást taglaló rendelkezés 3 bekezdésének utolsó 20 „Erst in einem erheblich weiteren Abstand beginnt die untere Grenze der Urheberrechtschutzfähigkeit, die ein deutliches Überragen der Gestaltungstätigkeit in Auswahl, Sammlung, Anordnung und Einleitung der Informationen und Anweisungen gegenüber dem allgemeinen Durchscnittskönnen voraussetzt.” BGH, NJW 1986 192. o 21 „Software ist erst dann urheberrechtsfähig, wenn das alltägliche, durchschnittliche Programmiererschaffen, das auf einer mehr oder weniger routinemäßigen, mechanisch-technischen Aneinanderreihung und Zusammenfügung des Materials beruht, deutlich überstiegen wird.” BGH : Urheberrechtschutzfähigkeit eines

Computerprogramms in: CR 2/91 80–86 o 22 http://www.ifrossde 23 „Der gesetzliche Vergütungsanspruch ist im Interesse des Urheberschutzes im Voraus unverzichtbar, soweit der Urheber nicht jedermann unentgeltlich ein einfaches Nutzungsrecht einräumt (Absatz 4 Satz 1). Die aufgenommene Einschränkung beugt einer befürchteten Rechtsunsicherheit für »Open Source« Programme und anderem »Open Content« vor ; im Bereich derartiger Lizenzbeziehungen, bei denen der Urheber sein Werk der Allgemeinheit unentgeltlich zur Verfügung stellt, kann weder eine zu Lasten des Urhebers gestörte Vertragsparität vorliegen, noch sind insofern Missbrauchsmöglichkeiten denkbar.” http://www.urheberrechtorg/UrhGE−2000/download/1406433pdf 2009. június 15 47 mondata ugyanis lehetőséget biztosít arra, hogy a szerző mindenkire egyszerű használati jogot jogdíj nélkül (ingyenesen) is átruházhasson. Problémát jelentett ugyanis, hogy a német szabályozás a szerzőt még a szerző

akarata ellenére is meg kívánta védeni. Az itt megjelölt kivétel nélkül ugyanis nem lett volna lehetőség arra, hogy a szerző felhasználási jogosultságot ingyenesen engedjen át. A nyílt forráskódú szoftverek használatának közigazgatásban történő elterjesztése végett, illetve az EUPL licenc bevezetése kapcsán 2005-ben több jelenős egyeztetést (workshop-ot) is tartottak a témában. Ahogy arra Ulrich Sandl rámutat: a német közigazgatásban több alkalommal felmerült az OSS bevezetése, még a 2005-ös e-Europe tervet megelőzően. A Zöld párt programjában 2000-ben jelent meg célkitűzésként a „szabad szoftver mindenkinek”, ennek hatására több elemzés is született.24 2001-ben az SPD frakció vetette fel, hogy a közigazgatásban mindenütt OSS-t kellene a költségcsökkentés érdekében használni, 2002-ben az CDU-Internet Bizottság zárójelentésében is kitértek arra, hogy csak olyan szoftverek lennének alkalmazhatóak a

közigazgatásban, amelyek kódja szabadon hozzáférhető.25 2005-ben látott napvilágot Roman Sedlmaier és Jan Gigerich szabad szoftverekkel kapcsolatos (a szabadalmi irányelvtervezetben rejtett) kockázatot elemző szakmai állásfoglalása26 , amely elkészítésére München tartományi főváros adott megbízást. A „LiMux szabad szoftverek Münchenben” program részletes dokumentációja, az ezzel kapcsolatos tapasztalatok és elért sikerek München központi oldalán http://www.muenchende/linux elérhetőek el A két éves tapasztalatokat Florian Schießl, a projekt egyik vezetője foglalta össze A tapasztalatok azt mutatták, hogy első lépésként – mivel az OpenOffice csomag bevezetését tervezték körülbelül 21 000 munkaállomáson – egy office alkalmazásokra koncentráló supportközpontot kell létrehozniuk. A legfontoAz alapul szolgáló tanulmány: http://www.ifrossde/ifross html/urhebervertragsrechtpdf UrhG 32. §, (3) bekezdés: „Auf eine

Vereinbarung, die zum Nachteil des Urhebers von den Absätzen 1 und 2 abweicht, kann der Vertragspartner sich nicht berufen. Die in Satz 1 bezeichneten Vorschriften finden auch Anwendung, wenn sie durch anderweitige Gestaltungen umgangen werden. Der Urheber kann aber unentgeltlich ein einfaches Nutzungsrecht für jedermann einräumen.” http: ://bundesrecht.jurisde/urhg/ 32html 24 Open Source in der Verwaltung CR 2000/11 793. o 25 http://www.governetde/alotta/user/governetde/img/000/001/1346pdf 26 Roman Sedlmaier, Jan Gigerich: Rechtliche Bedingungen und Risiken der Landeshauptstadt München für den Einsatz von Open-Source Software in: JurPC WebDok. 10/2005, Abs 1–192 http://wwwjurpcde/aufsatz/20050010htm 2009. június 15 48 sabb kritériumként a Microsoft Office és az OpenOffice.org közötti adatcsere biztosítása jelent meg. Az átjárhatóság biztosítása érdekében fejléc standardokat, mintákat határoztak meg (ezzel a használt makrók 20%-ra csökkentek),

először ajánlásokat, majd nyomtatványokat és dokumentum-mintákat vezettek be.27 Végleges office megoldásként az EUPL licenc alá tartozó WollMuxot28 fejlesztették ki, amely szabad szoftver. E program keretében került az ODF formátum29 is bevezetésre. 5.13 Ausztria A szabad szoftverekkel kapcsolatos kutatás központja Ausztriában a Wirschafts Universität Wien. Itt készítették el az EUPL fordítását és magyarázatát30 , alkották meg a nyílt forráskódú szoftverek és az osztrák szerzői jog viszonyait tisztázó tanulmányt, illetve publikáltak ezzel kapcsolatos anyagokat.31 5.14 Svájc A svájci rendszer32 sok tekintetben megegyezik a német modellel. 27 Erről bővebben: LiMux und WollMux : Zwei Jahre freie Software in München, http://www.muenchende/cms/prod1/mde/ de/rubriken/Rathaus/40 dir/limux/01 ueberblick/OCA LiMux 2008 11 12.pdf 28 http://www.muenchende/wollmux, http://wollmuxprojectsforgeosoreu 29 Erről részletesebb elemzést a 10. fejezet

tartalmaz 30 Univ. Prof Dr Andreas Wiebe, LLM, Dr Roman Heidinger, M. A : European Union Public Licence – EUPL V02 Kommentar, 2006. Wirtschaftskammer Wien, http://www2.wu−wienac at/informationsrecht/Rechtsinformationen/Abteilung/OpenSource/EUPL− −Broschuere WEB.pdf 31 Andreas Wiebe und Felix Prändl: Open source Software in : Österreichische Juristischen-Zeitung 628–637. o. http://www2.wu−wienac at/informationsrecht/Rechtsinformationen/Abteilung/OpenSource/Artikel WiebeOEJZHeft1704.pdf, Mag. Roman Heidinger, M A : Opensource Software – Grenzenlose Freiheit? Was beim Einsatz von Linux & Co zu beachten ist, http://www2.wu−wienac at/informationsrecht/Rechtsinformationen/Abteilung/OpenSource/open source presse langtext.pdf 32 Ursula Sury: Open-source-Software und das schweizerische Urheberrecht, http://www.ch−opench/html/events/2001/oss rechthtml 2009. június 15 49 5.15 További példák Az itt említett példákon túl világszerte33 találhatunk

törekvéseket abba az irányba, hogy a szabad szoftverek alkalmazását a közigazgatásban és egyéb adminisztratív hálókon is elterjesszék. Továbbá érdemes megjegyezni, hogy – bármilyen hihetetlen – a szabad szoftvereknek dinamikusan fejlődő piacát elemzi az ENSZ (UNCTAD34 2003-as jelentésének35 negyedik fejezete36 ). A 2003-as jelentést követően folyamatosan szerveztek rendezvényeket, mutattak be esettanulmányokat a nyílt és open source szoftverek hasznosításával kapcsolatosan.37 33 Francia példa: http://www.senatfr Nr 117, Peru : http://wwwtheregister co.uk/content/archive/25157html, Kína http://wwwasiaoscorg/topic 9 html 34 United Nations Conference on Trade and Development 35 „E-Commerce and Development Report 2003” http://www.unctad org/en/docs/ecdr2003ch4 en.pdf 36 „Free- and open-source software : Implications for ICT policy and development” 37 http://r0.unctadorg/ecommerce/ 2009. június 15 50 2009. június 15 6. fejezet A

FLOS szoftverek helye és szerepe a magyar jogrend tükrében 6.1 A felhasználási szerződés (licenc) és annak jelentősége Ahhoz, hogy egy más személy által létrehozott szoftvert jogszerűen használhassunk: 1. meg kell szereznünk az adott szoftverhez kapcsolódó vagyoni jogokat; 2. a szoftver műpéldány vonatkozásában felhasználási jogot kell nyernünk A vagyoni jogok megszerzése a 3.12 pontban rögzítettek szerint történik A felhasználási engedélyt (köznapi néven licencet) pedig az alábbiak szerint nyerhetjük el. 6.11 Formai követelmények „A felhasználási szerződést – ha e törvény eltérően nem rendelkezik – írásba kell foglalni.” 1 Ezen kógens szabály alól – köszönhetően a 2005 évi CLXV törvénynek – már három kivételt enged a jogalkotó: 1. Nem kötelező a szerződés írásba foglalása napilapban vagy folyóiratban történő közzétételre kötött szerződés esetén. (Itt ugyanis az újsághoz való beküldése

a cikknek elegendő ahhoz a vélelemhez, hogy a cikket közlésre, felhasználásra szánták). 1 Szjt. 45 §, (1) bekezdés 51 52 2. Nem kötelező a szoftver felhasználására vonatkozó szerződés írásba foglalása a szoftver műpéldányának a kereskedelmi forgalomban történő megszerzése esetén. 3. Valamint 2006 január 1-je óta tartalmazza a törvény azt a megdönthetetlen törvényi vélelmet, amely alapján: ha a lehívásra hozzáférhetővé tételt2 (interneten való közzétételt) a szerző maga gyakorolja, a felhasználási szerződést írásba foglaltnak kell tekinteni, amennyiben a műre a szerző elektronikus úton kötött és rögzített szerződéssel (online formában) enged további felhasználást. Egészen 2006-ig ugyanis a FLOS szoftverek jogosításában oly gyakran használt, online formátumú licencek alaki okból érvénytelennek minősültek. Ezt megelőzően ugyanis az a korlátozás, amely a „kereskedelmi forgalomban történő

megszerzés” körére szűkítette a szoftverekre vonatkozó felhasználási engedélyek megszerzését, hátrányos megkülönböztetéshez vezetett. A jogi szabályozás az informatika változásait nagyon lassan követi. 7 évnek kellett eltelnie ahhoz, hogy a törvény kommentárjában3 foglaltakat – a technika és a világ előrehaladtának ismeretében – aktualizálják. Jelen szabályozás egyaránt teret nyit a már említett licenc modelleknek, csakúgy, mint a creative commons4 törekvéseinek. 6.12 A licenc kötelező elemei Felhasználási szerződés alapján a szerző engedélyt ad a szoftver felhasználására, a felhasználó pedig köteles ennek fejében díjat fizetni.5 FLOS szoftverek esetében a díjfizetésre azért nem kerül sor, mert a törvény lehetővé teszi, hogy a felhasználási szerződés tartalmát a felek szabadon állapítsák meg, és a felhasználási szerződésre vonatkozó rendelkezésektől egyező akarattal eltérjenek. A licencek

kötelező értelmezése, hogy amennyiben a felhasználási szerződés tartalma nem állapítható meg egyértelműen, a szerző számára kedvezőbb értelmezést kell elfogadni. 2 Szjt. 26 §, (8) bekezdés „A szoftverek általános gyakorlatként a kereskedelmi forgalomban értékesülnek. Ahhoz, hogy a felhasználó felhasználási jogszerzése valóban jogszerű lehessen, és ugyanakkor a szabályozás megfeleljen a mindennapi élet gyakorlatának, követelményeinek, szükséges, hogy a jogalkotó az ilyen esetekre tekintettel kivételt engedjen a felhasználási szerződések szigorú alakszerűségi szabályai alól, azaz eltekintsen az írásbeliség általános követelményétől (Dr. Faludi Gábor : A felhasználási szerződés, Kézirat, 1999.)” KJK KERSZÖV Complex Jogtár 4 http://www.creativecommonshu 5 Szjt. 42 § 3 2009. június 15 53 FLOS szoftverek esetében a kizárólagos jog6 átadása nem merül fel, hiszen ezen szoftverek alapelve, hogy a

jogosítás korlátozhatatlan. A FLOSS licencek között is található olyan, amely – például szabadalmi védettség miatt – területi korlátozást tartalmaz, azonban ezen szoftverek esetében nem jellemző sem az időtartamra, sem a felhasználási módra, sem a felhasználás meghatározott mértékére vonatkozó korlátozás. Fontos – és a későbbiekben kifejtésre is kerülő – rendelkezés, hogy a licenc megkötésekor ismeretlen felhasználási módra vonatkozó felhasználási engedély érvényesen nem adható.7 6.13 Egyedi fejlesztések megrendelése A szoftverfejlesztési (= jövőben megalkotandó műre vonatkozó) szerződés alapján átadott szoftver elfogadásáról a felhasználó a mű átadásától számított négy hónapon belül köteles nyilatkozni.8 Ha a szoftvert a felhasználó kijavításra visszaadta, a határidő a kijavított mű átadásától számít. Ha a felhasználó az elfogadásra nyitva álló határidőn belül nem nyilatkozik, a

művet elfogadottnak kell tekinteni. Fejlesztési szerződés esetében a megrendelő jogosult az elkészült szoftvert – indokolt esetben, megfelelő határidő kitűzésével – a szerzőnek kijavítás végett ismételten is visszaadni. A jogalkalmazás keretében többnyire az a kérdés, hogy ilyen esetben mi minősül megfelelő határidőnek. Ha a fejlesztő a kijavítást alapos ok nélkül megtagadja vagy határidőre nem végzi el, a felhasználó a szerződéstől díjfizetés kötelezettsége nélkül elállhat. Elállás esetében az eredeti állapot kerül helyreállításra9 Azonban – figyelemmel a szerzői alkotások különleges voltára – az elállás joga csak kivételes esetben gyakorolható. Még abban az esetben is, mikor a mű javítás után sem alkalmas a felhasználásra, megilleti a szerzőt egy mérsékelt díjazás. A szoftverekkel kapcsolatos másik fontos rendelkezés, hogy ha a fejlesztő vagy a vagyoni jogi jogosult a szoftver felhasználásához

hozzájárult, a felhasználáshoz elengedhetetlen vagy nyilvánvalóan szükséges, a program lényegét nem érintő változtatásokat köteles végrehajtani. Ha e kötelezettségének nem tesz eleget, vagy nem tud eleget tenni, a felhasználó a változtatásokat hozzájárulása nélkül is végrehajthatja. A fejlesztési szerződésben egyébként kikötésre kerülhet, hogy a további jogosítási forma valamely FLOSS licenc lesz. 6 Szjt. Szjt. 8 Szjt. 9 Szjt. 7 43. 44. 49. 49. § §, (2) bekezdés §, (1) bekezdés és a 60. §, (4) bekezdés együttes alkalmazása §, (3) bekezdés 2009. június 15 54 6.14 Jelenleg ismert FLOS szoftverekkel kapcsolatos licencmodellek Amennyiben a kormányzat be kívánja vezetni a FLOS szoftvereket a közigazgatásba, célszerű megvizsgálni és áttekinteni a jelenleg fellelhető licencmegoldások széles tárházát. A már említett Institut für Freie und Open Source Software10 többek között11 az alábbi kategóriákba sorolja

a licenceket: Copyleft-hatás nélküli licencek BSD típusú licencek BSD licencek, a Berkeley egyetemről kikerült szoftverek licence, ahol alapvető követelményként jelent meg ezen információnak minden licencben való szerepeltetése, ám ezen licencezési típusból hiányzik az az elem12 , mely kizárná a felhasználási díj ellenében történő értékesítést. 1. Apache License (v 10), http://www.apacheorg/licenses/LICENSE−10 2. Apache License (v 11), http://www.apacheorg/licenses/LICENSE−11 3. Apache License (v 20), http://www.apacheorg/licenses/LICENSE−20html 4. Attribution Assurance License, http://eepatents.com/privaria/#license 5. Berkeley Database Product License, http://www.oraclecom/technology/documentation/berkeley−db/db/licen se/license db.html 6. 44 BSD Copyright (Original BSD-Lizenz), http://www.defreebsdorg/copyright/licensehtml 7. FreeBSD Copyright (Modifizierte BSD-Lizenz), http://www.defreebsdorg/copyright/freebsd−licensehtml 8. BSD License

(Original), http://www.xfree86org/336/COPYRIGHT2html#6 9. Christian Software Public License, http://www.geocitiescom/ResearchTriangle/Node/4081/csplhtml 10. Cougaar Open Source License, http://cougaar.org/docman/viewphp/17/126/old cosl licensehtml (Einordnung umstritten) 10 http://www.ifrossde Valamennyi licenckategória megemlítése meghaladja jelen tanulmány kereteit. 12 GPL 2 b, pont 11 2009. június 15 55 11. Cryptix General License, http://www.cryptixorg/LICENSETXT 12. Eiffel Forum License (v 10), http://www.eiffel−niceorg/license/forumtxt 13. Eiffel Forum License (v 20), http://www.eiffel−niceorg/license/eiffel−forum−license−2html 14. Entessa Public License (EPL) (v 10), http://www.opensealorg/epl 15. Free Fuzzy Logic Library Open Source License, http://ffll.sourceforgenet/licensetxt 16. Intel Open Source License for CDSA/CSSM Implementation, http://www.opensourceorg/licenses/intel−open−source−licensephp 17. Lua Copyright notice,

http://www.luaorg/licensehtml 18. MIT License, http://www.opensourceorg/licenses/mit−licensephp 19. Mozart License, http://www.mozart−ozorg/LICENSEhtml 20. OpenLDAP Public License (v 23), http://www.mibsoftwarecom/librock/librock/license/oldap2 3txt 21. OpenLDAP Public License (v 25), http://www.covalentnet/legal/docs/license openldaptxt 22. OpenLDAP Public License (v 27), http://www.openldaporg/doc/admin21/licensehtml 23. OpenLDAP Public License (v 28), http://www.openldaporg/software/release/licensehtml 24. Open Media Group Open Source License, http://www.openmediagroupcom/licensehtml 25. Pangeia Informatica Copyright (v 12), http://www.chkrootkitorg/COPYRIGHT 26. Phorum License (v 20), http://phorum.org/licensetxt 27. PHP License (v 30), http://www.phpnet/license/3 0txt 28. Python Copyright, http://http://www.pythonorg/download/releases/242/license/ 2009. június 15 56 29. skyBuilders Open Source License, http://www.skybuilderscom/OpenSourceLicensehtml 30. SpeechWorks

Public License – Software (v 11), http://www.speechcscmuedu/openvxi/OpenVXI 1 4/Licensetxt 31. 4Suite License (v 11), http://4suite.org/COPYRIGHTdoc 32. Tea Software License, http://teatrove.sourceforgenet/licensehtml 33. Udanax Open-Source License, http://udanax.xanaducom/licensehtml 34. Vovida Software License, http://www.vovidaorg/document/VOCAL−140/licensetxt 35. W3C Software Notice and License, http://www.w3org/Consortium/Legal/copyright−softwarehtml 36. Wide Open License (WOL), http://www.dspgurucom/wol2htm 37. XNet License, http://www.xnetinccom/xiua/copyrighthtm 38. X Window System License, http://www.xorg/Downloads termshtml 39. XFree86 Project Licence, http://www.xfree86org/legal/licenseshtml 40. The License of ZLib, http://www.gziporg/zlib/zlib licensehtml 41. The SpeechWorks Public License (v 11), http://www.speechcscmuedu/openvxi/OpenVXI 1 4/Licensetxt Egyéb licencek 1. Academic Free License (AFL) (v 11), http://opensource−definition.org/licenses/afl−11txt 2.

Academic Free License (AFL) (v 12), http://opensource−definition.org/licenses/academichtml 3. Academic Free License (AFL) (v 20), http://opensource−definition.org/licenses/afl−20html 4. Academic Free License (AFL) (v 21), http://opensource−definition.org/licenses/afl−21html 2009. június 15 57 5. Academic Free License (AFL) (v 30), http://www.rosenlawcom/AFL30htm 6. CeCILL-B License, http://www.cecillinfo/licences/Licence CeCILL−B V1−entxt 7. Condor Public License (v 11), http://www.cswiscedu/condor/licensehtml#condor 8. CNRI Open Source License Agreement (bis Python 16), http://www.handlenet/python licenses/python16 9−5−00html 9. FreeType Project License, http://www.freetypeorg/FTLTXT 10. Galen Open Source License (GOSL), http://www.opengalenorg/goslhtml 11. Globus Toolkit Public License, http://tyne.dlacuk/StarterKit/gt2/toolkit/download/licensehtml 12. Globus Toolkit Public License (GTPL) (v 20), http://www.unixglobusorg/toolkit/licensehtml 13. ICU License,

http://source.icu−projectorg/repos/icu/icu/trunk/licensehtml 14. ISC License, http://mirbsd.org/ISC−Licence 15. MirOS License, http://mirbsd.org/MirOS−Licence 16. Open Group Test Suite License, http://www.opengrouporg/testing/downloads/The Open Group TSLtxt 17. PSF License Agreement (Python), http://www.pythonorg/201/licensehtml 18. Ruby License, http://www.ruby−langorg/en/LICENSEtxt 19. Sendmail License, http://www.sendmailorg/ftp/LICENSE 20. SFL License Agreement (iMatix), http://legacy.imatixcom/html/sfl/sfl4htm 21. Standard ML of New Jersey Copyright Notice, http://cm.bell−labscom/cm/cs/what/smlnj/licensehtml 22. Suneido Free Software License, http://www.suneidocom/free software licensehtm 2009. június 15 58 23. Tcl/Tk License Terms, http://www.tcltk/software/tcltk/licensehtml 24. xinetd License, http://www.xinetdorg/cgi−bin/cvswebcgi/xinetd/COPYRIGHT?rev=1111 ;content−type=text%2Fplain 25. Zope Public License (v 21), http://www.zopeorg/Resources/ZPL Szigorúan

copyleft alapú licencek GPL-típusú licencek 1. Affero General Public License, http://www.afferoorg/oagplhtml 2. Alternate Route Open Source License (v 11), http://www.wsdotwagov/eesc/bridge/alternateroute/aroslhtm 3. CeCILL License (v 2), http://www.cecillinfo/licences/Licence CeCILL V2−entxt 4. CrossPoint Quelltextlizenz, http://www.crosspointde/srclicensehtml 5. eCos License (v 20), http://www.gnuorg/licenses/ecos−licensehtml 6. FreeCard License, http://freecard.sourceforgenet/website/licence/licensephp 7. GNU Classpath – GPL with special exception, http://www.gnuorg/software/classpath/licensehtml 8. GNU Emacs General Public License, http://www.free−softorg/gpl history/emacs gplhtml 9. GNU General Public License (GPL) (v 10), http://www.gnuorg/copyleft/copying−10html 10. GNU General Public License (GPL) (v 20), http://www.gnuorg/licenses/old−licenses/gpl−20html 11. GNU General Public License (GPL) (v 30), http://www.fsforg/licensing/licenses/gplhtml 12. GNU General

Public License (GPL) (v 30) – Inoffizielle deutsche Übersetzung, http://www.gnude/gpl−gerhtml 13. GNU Affero General Public License (GPL) (v 30), http://www.fsforg/licensing/licenses/agpl−30html 2009. június 15 59 14. Honest Public License (HPL) (10), http://www.projectpierorg/manual/tour/licence 15. Honest Public License (HPL) (11), http://www.opensourcestrategiescom/HPLv11txt 16. Open RTLinux Patent License, http://www.rtlinuxfreecom/openpatentlicensehtml Egyéb licencek 1. Apple Public Source License (v 20), http://www.opensourceapplecom/apsl/20txt 2. Arphic Public License, http://ftp.gnuorg/non−gnu/chinese−fonts−truetype/LICENSE 3. Boost Software License, http://www.boostorg/LICENSE 1 0txt 4. Common Public License, http://www.eclipseorg/legal/cpl−v10html 5. Deutsche Freie Softwarelizenz (d-fsl), http://www.d−fslorg 6. Eclipse Public License (v 10), http://www.eclipseorg/legal/epl−v10html 7. European Public License (v 10),

http://ec.europaeu/idabc/en/document/6523 8. IBM Public License, http://www−128.ibmcom/developerworks/opensource/library/os−i18n2/ os−ipl.html 9. Jabber Open Source License, http://www.jabberorg/about/joslshtml 10. Lucent Public License Version (v 102), http://plan9.bell−labscom/plan9/licensehtml 11. Nethack General Public License, http://www.nethackorg/common/licensehtml 12. Open Group Public License, http://www.opengrouporg/openmotif/license 13. Open Software License (OSL) (v 21), http://opensource.org/licenses/osl−21php 2009. június 15 60 14. Red Hat eCos Public License (v 11), http://ecos.sourcewareorg/old−licensehtml 15. Red Hat eCos Public License (v 11), http://sources.redhatcom/ecos/license−overviewhtml 16. Salutation Public License, http://www.salutationorg/lite/lite licensehtm 17. Software AG License Terms (Quip License) (v 13), http://www.cseuconnedu/~dqg/cse350/xml/quip/Licensetxt 18. Vim License, http://www.vimorg/htmldoc/ugandahtml Licencek

korlátozott copyleft hatással MPL típusú licencek Az MPL – azaz a Mozilla13 – jellegű licencek olyan felhasználási szerződéseket takarnak, melyek nem zárkóznak el attól a lehetőségtől, hogy bizonyos részleteiket olyan szoftverekben használják fel, melyek felhasználási díj ellenében is megjelennek a piacon. A licenccsoport második legismertebb eleme a Netscape Public Licence, mely alatt 1998-ban a Navigátor forráskódját nyilvánosságra hozták. 1. Common Development and Distribution License (CDDL) (v 10), http://www.suncom/cddl/cddlhtml 2. Erlang Public License (v 11), http://www.erlangorg/EPLICENSE 3. ICS Open Source Public License, http://www.opencontrolorg/OSPLhtm 4. Interbase Public License, http://www.borlandcom/devsupport/interbase/opensource/IPLhtml 5. Mozilla Public License (v 10), http://www.mozillaorg/MPL/MPL−10html 6. Mozilla Public License (v 11), http://www.mozillaorg/MPL/MPL−11html 7. NASA Open Source Agreement (v 13),

http://worldwind.arcnasagov/worldwind−nosa−13html 8. Netizen Open Source License (NOSL), http://web.archiveorg/web/20000815212105/bitsnetizencomau/licen ses/NOSL 13 http://www.mozillaorg/MPL/MPL−11html 2009. június 15 61 9. Nokia Open Source License, http://www.opensourceorg/licenses/nokiaphp 10. Open Telecom Public License, http://www.opentelecomorg/otpl/otplhtml 11. Ricoh Source Code Public License, http://www.risourceorg/RPL/RPL−10Ashtml 12. Sun Public License, http://java.suncom/splhtml 13. Sun Industry Standards Source License (v 11), http://www.openofficeorg/licenses/sissl licensehtml 14. Zenplex Public License, http://web.archiveorg/web/20041010201945/wwwzenplexorg/zpl txthtml 15. Zimbra Public License (ZPL) (v 12), http://www.zimbracom/license/zimbra public license 12html Egyéb licencek 1. Bremer Lizenz für freie Softwarebibliotheken (OSCI-Lizenz) (v 10), (.pdf-Dokument), http://www1.oscide/sixcms/mediaphp/13/Bremer Lizenzpdf 2. CeCILL-C License,

http://www.cecillinfo/licences/Licence CeCILL−C V1−entxt 3. Cougaar Open Source License Agreement, http://cougaar.org/docman/viewphp/17/126/old cosl licensehtml (Einordnung umstritten) 4. Hi-Potent Open Source License, http://web.archiveorg/web/20030804175518/wwwhi−potentcom/licensehtml 5. GNU Library General Public License (LGPL) (v 20), http://www.gnuorg/copyleft/libraryhtml 6. GNU Lesser General Public License (LGPL) (v 21), http://www.gnuorg/licenses/old−licenses/lgpl−21html 7. GNU Lesser General Public License (LGPL) (v 30), http://www.gnuorg/licenses/lgplhtml 8. GNU Lesser General Public License (LGPL) (v 30) – Inoffizielle deutsche Übersetzung, http://www.gnude/lgpl−gerhtml 2009. június 15 62 9. Microsoft Reciprocal License (Ms-RL), http://www.microsoftcom/resources/sharedsource/licensingbasics/recip rocallicense.mspx 10. Microsoft Limited Reciprocal License (Ms-LRL), http://www.microsoftcom/resources/sharedsource/licensingbasics/limit

edreciprocallicense.mspx 11. Motosoto Open Source License (v 091), http://opensource.org/licenses/motosotophp 12. Sybase Open Watcom Public License, http://downloads.openwatcomorg/ftp/licensetxt 13. wxWindows Library License (v 30), http://www.freiburglinuxde/~wxxt/licencehtml 14. Yahoo ! Public License (YPL) (v 11), http://www.zimbracom/license/yahoo public license 11html Választási lehetőséget biztosító licencek Az Artistic típusú licencek14 semmilyen más licencfajtába nem sorolható felhasználási szerződések. Legismertebb képviselőjük egy programozási nyelvhez, a Perl-hez köthető, mely 1994 óta párhuzamosan kerül terjesztésre GPL és Perl Artistic Licenc alatt. A licenc jellegzetessége, hogy korlátozza az átdolgozás jogát, ugyanis a programokon csak kisebb jellegű változtatásokat engedélyez. 1. Artistic License (v 10), http://foundation.perlorg/legal/licenses/artistic−1 0html (Einordnung umstritten) 2. Artistic License (v 20),

http://foundation.perlorg/legal/licenses/artistic−2 0−plainhtml 3. Clarified Artistic License, http://www.statisticaunimibit/utenti/dellavedova/software/ artistic2.html 4. Keith Devens’ Open Source License, http://www.keithdevenscom/software/license/ 5. LaTeX Project Public License (LPPL) (v 10), http://www.latex−projectorg/lppl/lppl−1−0html 6. LaTeX Project Public License (LPPL) (v 11), http://www.latex−projectorg/lppl/lppl−1−1html 14 http://www.perlcom/language/misc/Artistichtm 2009. június 15 63 7. LaTeX Project Public License (LPPL) (v 12), http://www.latex−projectorg/lppl/lppl−1−2html 8. LaTeX Project Public License (LPPL) (v 13c), http://www.latex−projectorg/lppl/lppl−1−3chtml 9. LaTeX Project Public License (LPPL) (v 13b) (Inoffizielle deutsche Übersetzung), http://www.latex−projectorg/lppl/lppl−1−3b−dehtml 10. Microsoft Public License (Ms-PL), http://www.microsoftcom/resources/sharedsource/licensingbasics/publi clicense.mspx 11.

Physnet Package License, http://web.archiveorg/web/20060821203230/http://35969219/home/mod ules/license.html 12. SGI Free Software License B (v 10), http://oss.sgicom/projects/FreeB/SGIFreeSWLicB10html (Einordnung umstritten) 13. SGI Free Software License B (v 11), http://oss.sgicom/projects/FreeB/ (Einordnung umstritten) 14. Sleepycat Software Product License, http://genome.jouyinrafr/doc/docs/sleepycat/licensehtml 6.15 A GPL v 2 licenc bemutatása Jelen tanulmányban a GNU General Public License 2-es verziójának ismertetésére kerül sor. Ahogy a korábbi ábrán bemutatásra került – dacára a licencek rendkívül széles tárházának – ez a copyleft típusú licenc teszi ki a FLOS szoftver licencelés közel háromnegyedét.15 Ismert még a GNU GPL v. 3 verziója16 , bár annak elterjedése „fiatal” korára tekintettel még nem jelentős. A licenc szövege – amely felhasználási szerződésként – maga is egy szellemi alkotás, méghozzá – mint korábban

említésre került – R. M Stallman műve, aki szintén a copyright rendszerben felnőtt, ám azzal egyet nem értő amerikai. Éppen ezért a licenc szövegében az alább elemzésre került példához hasonlóan szintén találunk majd a kontinentális jogrendszertől idegen 15 A szabad szoftverek és nyílt forrású licencek vezetői között fennálló ellentétek tárgyalása nem képezi jelen tanulmány tárgyát. 16 Jelen tanulmány keretei között csak az egyik licenc ismertetése volt lehetséges, ezért a GPL v2, mint a kor legjellemzőbb licence került bemutatásra. Fontosnak tartjuk azonban, hogy a szabad szoftverek bevezetése esetén a választható licencek szaknyelvi fordítása magyar nyelven hozzáférhető legyen. 2009. június 15 64 részeket. A licenchez tartozó központi oldalon17 16 nyelven van lehetőség a szerződés letöltésére, többek között magyarul18 is hozzáférhető. A közzétett szöveg pár ponton jogi pontosítást igényel.19 A

német szerzők esetében is vitára ad okot, hogy a GPL-t, mint kétoldalú felhasználói szerződést vagy mint egyoldalú jognyilatkozatot értelmezzék, ám jogrendjük szerint a ráutaló magatartás a szerződéskötés elégséges feltétele.20 Előszó „A legtöbb szoftver licenceit azzal a szándékkal készítették, hogy Öntől a szoftver átdolgozásának és terjesztésének szabadságát elvonják. Ezzel szemben a GNU General Public License célja az, hogy garantálja az Ön számára a szabad szoftver átdolgozásának és terjesztésének szabadságát, ezáltal biztosítva a szoftver szabad használatát minden felhasználó számára. Ennek a General Public Licensenek a szabályai vonatkoznak a Free Software Foundation szoftvereinek nagy részére, illetve minden olyan programra, melynek szerzője úgy dönt, hogy ezt a licencet használja a felhasználási mód megjelölésekor. (A Free Software Foundation szoftvereinek egy másik részére a GNU LesserGeneral

Public License vonatkozik.) Bárki engedélyezheti programjai felhasználását a General Public License-szel.” 21 A GPL a Free Software Foundation szoftvereire, valamint azon szoftverekre vonatkozik, melyek szerzői ezen felhasználási szerződés alkalmazását kötötték ki. A licenc minden olyan programra vagy műre vonatkozik, mely tartalmaz utalást arra, hogy a munka a GPL-ben szereplő feltételek betartása mellett terjeszthető. Érdekessége a licencnek, hogy egyszerre kezeli a licenc olvasóját „Önt”, mint szerzőt (átdolgozót), és mint felhasználót. A licenc központi eleme a szoftverek terjesztése, a szerzői jog felől nézve azonban több ponton is hiányos a szabályozás.22 17 http://www.gnuorg/copyleft/gplhtml http://gnu.hu/gplhtml Ezen ponttal kapcsolatban felmerül a hiteles fordítás kérdése, illetve ennek igénye. Kérdés, hogy amennyiben az eredeti dokumentum kizárólagosan az angol eredeti szerződést, vagy annak (számozott) változatait

tekinti irányadónak, vajon kielégíti-e az eredetivel való egyenértékűség követelményét, amennyiben a szöveg „hiteles fordítás”-ára hivatkozunk, illetve az angol nyelű licenc mellett, tekintettel a felhasználók esetleges nyelvtudási nehézségeire hivatkozási alapul azt biztosítjuk. 19 A GPL v. 2 jogi szempontból lektorált, egységes szövegű változatát az A melléklet tartalmazza. 20 BGB § 151 21 A GPL jogi fordítását Dr. Dudás Ágnes készítette el, elérhető : http://www drdudas.hu/gpl v2 magyarul 22 Nem rendezi többek között a futtatáshoz fűződő alap jogosultságot. 18 2009. június 15 65 „A szabad szoftver megjelölés a szabadságra vonatkozik, és nem az árra. A General Public License-szek célja, hogy biztosítsa az Ön számára a szabad szoftver többszörözésének és terjesztésének jogát (és e szolgáltatásért akár díj felszámítását), a forráskód átadását (vagy igény szerint hozzáférést ehhez a

kódhoz), a szoftver átdolgozásának lehetőségét, illetve hogy a szoftver egyes részeit új szabad programokban használhassa fel, és hogy e lehetőségekkel tudatosan élhessen. Az Ön jogai védelmében hozott korlátozások azok, amelyek megtiltják/megakadályozzák, hogy valaki e jogok gyakorlását Önnek megtilthassa, vagy Önt ezekről lemondásra/tartózkodásra kényszeríthesse. Az ezekből a korlátozásokból eredő felelősség Önt is terheli, amennyiben a szoftver műpéldányokat terjeszti, illetve átdolgozza.” R. M Stallman minden előadásán és írásában hangsúlyozza a négy alapszabadság23 fontosságát, illetve azt, hogy a szabadság nem egyenlő az ingyenességgel Stallman magyarázatai24 mögött részben az angolszász ideológia húzódik meg. Az általa tett kijelentések és a kontinentális jogrend sajátosságai között feszülő ellentétek miatt megoszlanak a vélemények a tekintetben, hogy „a szoftverekért” kérhető-e díj. A

kérdés szerencsére árnyalhatóbb, és valójában sokkal inkább úgy hangzik, hogy a felhasználás ellentételezéseként megjelenik-e a jogdíj, bármilyen formában. Utóbbi kérdésre a válasz: nem Természetesen a műpéldány továbbításáért kérhető úgynevezett postázási költség vagy a stallman-i értelmezés szerint bármilyen olyan díj, amit a szoftvert használni vágyók hajlandóak a többszörözött példányért megfizetni, ez azonban nem azonos a felhasználás engedélyezése fejében fizetett díjjal, amelyet a szerzői jogi törvény 16. §, (5) bekezdése rögzít A jogdíj ugyanis a szerzőt 25 illeti, és ennek „beszedésére” mást csak írásban jogosíthat (bízhat meg vagy hatalmazhat fel), ezek viszont nyilvánvalóan nem történnek meg egy általános szerződési feltétel keretében. A másik nehézséget az jelentené, hogy a beszedett díjat – amennyiben nem egy szerző jegyzi a szoftvert – teljesítményarányosan kellene

visszaosztani, ami szintén lehetetlen lenne. E probléma áthidalására született a már ismertetett Linux-klauzula a német szerzői jogi törvényben. A szoftverhez kapcsolódó tényleges jogdíjat az a személy szedhet, aki a szoftvert vagy annak egy egyedileg értékelhető modulját létrehozta. Amit ebben az esetben a felhasználó megfizet (megfizethet) az – kicsit hasonlóan az 23 Lásd 4.1 fejezet http://www.gnuorg/philosophy/sellinghtml 25 „Ha e törvény másképp nem rendelkezik, a szerzőt a mű felhasználására adott engedély fejében díjazás illeti meg, amelynek – eltérő megállapodás hiányában – a felhasználáshoz kapcsolódó bevétellel kell arányban állnia. A díjazásról a jogosult csak kifejezett nyilatkozattal mondhat le. ” 24 2009. június 15 66 iparjogvédelmi oltalmi formákhoz – a használat elsőbbségének joga. A díj fejében ő az első, aki a szoftverhez hozzájut Amennyiben a szoftvert harmadik személynek nem adja

át és a fejlesztővel kötött szerződése azt lehetővé teszi, a GPL szabályai szerinti „nyilvánossághoz közvetítés” (distribution) nem valósult meg, így a licencben foglalt – hozzáférhetővé-tételi – kötelezettségek sem léptek életbe. Szabad szoftverek esetében a fejlesztő célja a fejlesztés, amiért óradíjat, vagy havi rendszerességgel fizetést kíván kapni. Más – munkaviszonyban vagy vállalkozói jogviszonyban – fejlesztő személyekhez hasonlóan nem rendelkezik a jogokkal, hiszen az esetek jelentős részében nem maradnak jogai, amikről rendelkezhetne. „Amennyiben Ön például ilyen [licenccel ellátott] program másolatait terjeszti – akár ingyenesen, akár bizonyos díj fejében – a szoftverrel kapcsolatos valamennyi jogot köteles átruházni a [harmadik személy] felhasználónak. Meg kell továbbá győződnie arról, hogy a [harmadik személy] felhasználó számára a forráskód, vagy a kódhoz jutás lehetősége

rendelkezésre áll/biztosított. És annak érdekében, hogy a [harmadik személy] felhasználó megismerje jogait, ismertetnie kell vele a felhasználás kereteit meghatározó jelen licencet.” A magyar szerzői jogi törvény a harmadik személyek jogosításának lehetőségeiről az alábbiak szerint rendelkezik: „A felhasználó az engedélyt harmadik személyre csak akkor ruházhatja át, illetve csak akkor adhat harmadik személynek további engedélyt a mű felhasználására, ha azt a szerző kifejezetten megengedte.” 26 A GPL 4. cikkelye tartalmaz további – nem csak utalás szintű – rendelkezéseket a harmadik fél jogosításával kapcsolatosan „Az Ön jogait két lépésben védjük: (1) a szoftvereket szerzői oltalom alá helyezzük, és (2) felkínáljuk Önnek jelen licencet, amely jogosítja Önt a szoftver többszörözésére, terjesztésére és/vagy átdolgozására. A szerző és a magunk [FSF] védelmében biztosítani kívánjuk továbbá, hogy

mindenki megtudja : hogy erre szabad szoftverre nincs garancia. Ha a szoftvert átdolgozták és továbbadták, akkor mindenkinek, aki az átdolgozott változatot kapja, tudnia kell, hogy az nem az eredeti, így a mások által okozott hibák nem sérthetik az eredeti szerző hírnevét. Végül és utolsó sorban, valamennyi szabad szoftver létét folyamatosan fenyegetik a szoftverszabadalmak. El kívánjuk kerülni annak veszélyét, hogy a szabad programra terjesztői egyedileg szabadalmi oltalmat igényelhessenek, és ezáltal a programra vonatkozóan kizárólagos szellemi tulajdonjoguk keletkezzen. Ennek megakadályozásához tisztázni kívánjuk: szabadalom szabad szoft26 Szjt. 46 §, (1) bekezdés 2009. június 15 67 verrel kapcsolatban csak mindenkire vonatkozó hasznosítási joggal jegyezhető be, vagy egyáltalán nem jegyezhető be.” A többszörözésre, terjesztésre, átdolgozásra vonatkozó konkrét feltételek és kikötések Szerződési alapok :

fogalommeghatározás, a jogosítás köre „0. Ez a licenc minden olyan programra vagy más műre vonatkozik, amelyen a vagyoni jog jogosultja utal arra, hogy a mű a General Public License-ben foglaltak alapján terjeszthető. Az továbbiakban a »Program« kifejezés bármely ilyen programra vagy műre vonatkozik, a »Programon alapuló mű« pedig magát a programot, illetve bármely, annak a szerzői jog által védett átdolgozását jelenti: vagyis olyan művet, amely tartalmazza a Programot vagy annak egy részletét, átdolgozott vagy átdolgozástól mentes formában és/vagy más nyelvre fordítva. (A továbbiakban a fordítás minden egyéb megkötés nélkül beletartozik az átdolgozás fogalmába) Minden felhasználási engedély jogosultjának (licencbevevő) megjelölése a továbbiakban: »Ön«. A jelen licenc a többszörözésen, terjesztésen és átdolgozáson kívül más felhasználási módra nem vonatkozik, azok az engedélyezési körön kívül esnek A

Program futtatása nincs korlátozva, illetve a Program eredményeire is csak abban az esetben vonatkozik ez a szabályozás, ha az tartalmazza a Programon alapuló mű egy részletét (függetlenül attól, hogy ez a Program futtatásával jött-e létre). Ez tehát a Program működésétől függ.” A szoftver szerzői jogi védelme mellett a licenc, mint felhasználási szerződés engedélyezi a program másolását, terjesztését és módosítását. Tehát a GPL csak azokban az esetekben lehet érvényes, ha a jogosult ezt (vagy ezt is27 ) megjelölte, mint szerződési feltételt. Program alatt értve minden szoftvert valamint az ezeken alapuló műveket is. Adott esetben a programot vagy annak részét tartalmazó, módosításokkal ellátott változata, vagy annak fordítása.28 A szerzői jogi törvény 58 §, (2) bekezdésében rögzíti, hogy szerzői jogi védelem alatt áll a szoftvernek eredeti programnyelvből eltérő programnyelvre történő átírása is,

méghozzá – az eredeti mű szerzőjét megillető jogok sérelme nélkül – ha annak egyéni, eredeti jellege van.29 A módosítás valójában átdolgozásnak minősül. A futtatás joga pedig olyan jogosultság, mely annyira magától értetődő, hogy csak közvetetten kerül megemlítésre és erre vonatkozóan semmiféle korlátozás nem létezik. 27 A dual licencelés lehetősége természetesen fennáll. A licenc szövege az első definíción túl – a szerzői jogi törvénnyel összhangban – átdolgozásnak/módosításnak nevezi valamennyi fordítást. 29 4. §, (2) bekezdés 28 2009. június 15 68 Ahogy az a korábbiakban már kifejtésre került – új alkotásnál a szerző maga dönt a jogosítás feltételeiről, átdolgozás esetében pedig az eredeti művel kapcsolatosan megszerzett jogok határolják be az átdolgozó lehetőségeit. A licenc bevezető sorait követően egy tételes (pontokba foglalt) listát találunk, amely megfelelően a szerzői

jogi szabályoknak a felhasználási jogok gyakorlásának feltételeit ismerteti. Az „alap” jogosítás és annak feltételei „1. Ön a Program forráskódját átdolgozás nélkül többszörözheti és tetszőleges adathordozón terjesztheti, feltéve, hogy minden egyes példányon szembetűnően pontosan feltünteti a megfelelő szerzői jogi megjegyzést, illetve a garanciavállalás kizárását; érintetlenül kell hagynia minden erre a licencre és a garancia teljes hiányára utaló szöveget, továbbá a jelen licencfeltételeket is el kell juttatnia mindazokhoz, akik a Programot kapják.” Alapnak nevezett a jogosítás, mivel ez a rendelkezés érinti valamennyi felhasználót, aki egyszerűen csak szeretné a szoftvert másokkal megosztani. A freeware és shareware szoftverektől eltérően (ahol csak a futtatható állomány érhető el) tehát itt maga a forráskód is átadásra kerül. Nyilván a GPL alatt terjesztett licencek esetében is felmerül a

jogkimerülés kérdése. Természetesen ahogy a kereskedelmi forgalomba hozott szoftverek jogosultjai nem befolyásolhatják a szoftver „utóéletét”, úgy nem lehet már például a már egyszer forgalomba került Linux-disztribúció műpéldányára sem örökké ráhatása a jogosultnak. Tehát a GPL licenc előírásai nem vonatkoznak arra, aki egy más által már licencbevevőként (felhasználóként) megszerzett szoftver-műpéldányt szerez meg. Ez azt jelenti, hogy ő már nem minősül „Ön”-nek a szerződés értelmében. Fontos azonban megjegyezni, hogy a jogkimerüléssel kapcsolatos tétel csak egyes műpéldányokra, és csak a terjesztéssel összefüggésben, és csak az „alap” esetben értelmezhető.30 Hiányzik a felhasználó számára adott kifejezett engedély mind a nyilvánosságrahozatal, mind a nyilvánossághoz való közvetítés tekintetében, ideértve magát az on-line terjesztést is, ugyanakkor a körülmények vizsgálata (hogy az

online terjesztés a szoftver elsődleges terjesztési formája) arra enged következtetni, hogy ezen engedélyt is megadottnak kell tekinteni. „A másolati példányok fizikai továbbítása fejében díjat kérhet, a Programhoz nyújthat anyagi ellentételezése fejében garanciális támogatást.” Annak érdekében, hogy a GPL egy „élhető” és éltető modell legyen, lehetőség van arra, hogy a hordozóért a másolatot készítő díjat számoljon fel (ahogy lehet egyébként díjat kérni más kapcsolt és nem GPL alatt jogosított termékért, például kézikönyv), vagy a szavatossági jogok biztosításáért és tá30 Die kommentierte GPL 46. o 2009. június 15 69 mogatásért, amelyet a rendelkezésre álló szoftver mellé nyújthat a vállalkozó szellemű felhasználó. A szavatossági kérdések innentől fogva a hatályos magyar jogszabályok szerint tetszőleges szerződési formában (például support vagy SLA) rendezik majd a felek viszonyait.

Fontos azonban, hogy mivel a szoftvert az eredeti jogosult jogosítja, és a szerződéses viszony mindig közötte és az adott felhasználó ( „Ön”) között jön létre, harmadik személy nem jogosult „licencdíjat” kérni, hiszen jogosítani sem jogosíthat. „Magasabb szintű” jogosítás „2. Ön jogosult a Program másolatának vagy másolatainak vagy egy részének átdolgozására, amely következtében egy, a Programon alapuló mű jön létre. Az így keletkezett, átdolgozott művet ezt követően az 1. szakaszban adott feltételek szerint többszörözheti és terjesztheti, amennyiben az alábbi feltételek is teljesülnek:” Az átdolgozás szabályai természetesen szűkebben értelmezendőek az egyszerű terjesztési szabályoknál. Hiszen itt nem csak a vagyoni jogok érintettek, hanem a személyhez fűződő jogok is Elég, ha csak arra gondolunk, hogy milyen komoly presztízsvesztést jelenthet egy híresebb fejlesztőnek, ha e szabályok megsértése

mellett valaki a kódjába kontárkodik, és az továbbra is az ő neve alatt terjed. „a) Az átdolgozott fájlokat el kell látnia olyan feltűnő megjegyzéssel, amely tartalmazza, hogy Ön végezte az átdolgozást és rögzíti az átdolgozás dátumát.” Az imént jelzett okból kifolyólag kell tehát mindig és pontosan megjelölni az átdolgozás körülményeit. Amennyiben az átdolgozó ezt nem vagy nem így teszi, a licencből fakadó jogosultságokat automatikusan elveszíti.31 „b) Gondoskodnia kell arról, hogy minden, az Ön által terjesztett vagy nyilvánosságra hozott mű, amely részben vagy egészben tartalmazza a Programot, illetve a Program átdolgozásával jött létre, valamennyi harmadik személy számára, egységként jelen licencben meghatározott feltételek szerint díjmentesen kerüljön engedélyezésre.” E pont jelenti a „copyleft” elgondolás kulcsát. Itt kerül rögzítésre a korábban már hivatkozott „díjmentességi” kikötés,

amely keretében harmadik személyek részére a felhasználási jogokat biztosítani kell. Kérdés persze, hogy amennyiben a programot nem kívánja sem terjeszteni sem nyilvánosságra hozni, arra kötelezhető-e? Vegyük mondjuk azt a helyzetet, hogy GPL alapokon nyugvó fejlesztést rendel meg egy tejdobozolással foglalkozó cég, és a fejlesztő a kódot átadja. Első kérdésként felmerül, hogy ezáltal a „distribution” fogalmát kimerítették-e. Ha nem32 – a GPL 31 32 GPL 4. pont Die kommentierte GPL 48. o 2009. június 15 70 licencet nem kell alkalmazni. Ha igen, és a szoftver átadására a GPL licenc mellékelésével került sor: Az „A” tejdobozoló cég jogosult lesz az „A+” baracklédobozoló üzletágat is ellátni ezzel a szoftverrel, de egyáltalán nem lesz köteles átadni azt a konkurens „B” tejdobozolónak. Akkor sem, ha az ezt kéri A GPL értelmében senkit nem lehet arra kötelezni, hogy a szoftver terjesztésétől zárkózzon el,

vagy harmadik személyek részére az átadást tagadja meg, de arra sem lehet, hogy akarata ellenére vegyen részt a terjesztési láncolatban. A GPL tehát nem jelent szerződési kötelezettséget, hanem azt jelenti, hogy ha a felek között – az átdolgozott, és ezáltal önálló alkotásnak minősülő műre vonatkozóan – létrejön szerződés, annak GPL-nek kell lennie. „c) Ha az átdolgozott Program alapesetben futtatáskor interaktív parancsokat olvas be, gondoskodnia kell arról is, hogy amennyiben ilyen interaktív felhasználás a megszokott módon kerül indításra, jelenítsen meg vagy nyomtasson ki egy, a szerzői jogi kitételeket tartalmazó megjegyzést, valamint egy utalást a szavatosság igények kizárására (vagy éppen arra, hogy Ön milyen feltételekkel biztosítja a garanciát), illetve arra, hogy e feltételek betartása mellett a felhasználó terjesztheti a Programot. A felhasználót tájékoztatni kell arról is, hogy miként ismerheti meg a

licenc egy példányát. (Kivétel: ha a Program interaktív ugyan, de normál körülmények között nem jelenít meg hasonló megjegyzést, akkor a Programon alapuló műnek sem kell ezt tennie.)” Ez a kikötés érint minden programot, amely nem háttérprogramként fut. Bár a kötelezettség fennáll, annak statisztikai valószínűsége, hogy valaki a megjelent licencfeltételeket (kivéve, ha jogász) végigolvassa – elég alacsony. Az, hogy a feltételeket valamely módon (például egy „pipa bekattintásával”) el kellene fogadni, nem került a kikötések közé. Ugyanakkor a szoftver használatából következik, hogy a felhasználó a licenc tartalmát megismerte és elfogadta. „Ezek a feltételek az átdolgozott műre, mint egészre vonatkoznak. Ha a mű azonosítható részei nem a Programon alapulnak/nem vezethetőek le a Programból és önálló műként elkülönülten azonosíthatók, akkor ez a felhasználási engedély nem vonatkozik ezekre a részekre,

amennyiben ezeket Ön önálló műként terjeszti.” A GPL „vírushatásnak” 33 nevezett terjedése tehát nem érinti azokat a műveket (szoftvermodulokat), amelyek önállóan azonosíthatóak. Ezeket nyilvánvalóan nem kell GPL alá helyezni „De ha ugyanezeket a részeket egy olyan mű részeként terjeszti, amely a Programon alapul, az egész terjesztésének ezen a szerződésen kell alapulnia, 33 Die kommentierte GPL 64. o 2009. június 15 71 amely szerződésnek az engedélyei a többi felhasználóra is mint teljes egészre kiterjednek, és így minden részre is, függetlenül attól, hogy ki írta azokat.” Ha azonban az azonosítás nem lehetséges, a GPL szabályait kell alkalmazni. Érdemes tehát „időben”, még a fejlesztés tervezésekor eldönteni, hogy melyik licencet kívánja a jogosult alkalmazni. „E bekezdésnek tehát nem az a célja, hogy a művekkel kapcsolatos szerzői jogokat érvényesítse, vagy hogy a jogait az Ön által alkotott

művel kapcsolatban vitassa. Sokkal inkább az a cél, hogy a Programon alapuló származékos, vagy gyűjteményes művek terjesztésének ellenőrzésére vonatkozó jogokat gyakorolja.” „E felhasználási engedély nem vonatkozik más művekre, amelyek nem a Programon alapulnak, de a Programmal (vagy a Programon alapuló művel) azonos adathordozón kerülnek tárolásra, terjesztésre.” Semmilyen ráhatással nincsen tehát a GPL azon szoftverekre, amelyek azonos hordozón kerülnek terjesztésre. A hordozón tehát bármilyen szoftver lehet, a hozzá tartozó felhasználási feltételekkel, az egyes szoftverek ily módon „összekeveredni” nem fognak. Részletszabályok „3. Ön jogosult a Program (vagy a 2 szakasz értelmében a Programon alapuló mű) többszörözésére és terjesztésére tárgykódú vagy futtatható kódú formában az 1. és 2 szakaszban foglaltak szerint, feltéve, hogy az alábbi feltételeket is teljesíti : a) A programhoz mellékelje a

teljes, gép által értelmezhető forráskódot egy jellemzően e célt szolgáló adathordozón, amely az 1. és 2 szakaszban foglaltak szerint kerül terjesztésre, vagy b) a programhoz mellékeljen egy legalább 3 évre vonatkozó írásbeli kötelezettségvállalást, amely alapján bármely harmadik személy rendelkezésére bocsátja a teljes gép által értelmezhető forráskódot a hordozó eljuttatásának költségét meg nem haladó díj fejében, amely az 1. és 2 szakaszban foglaltak szerint kerül terjesztésre, jellemzően e célt szolgáló adathordozón; vagy c) a Programhoz mellékelje azt a forráskód rendelkezésre bocsátására vonatkozó írásbeli kötelezettségvállalást, amelyet Ön is megkapott. (Ez az alternatíva csak nem kereskedelmi terjesztés esetén alkalmazható, és akkor is csak abban az esetben, ha Ön a Programot tárgyi vagy futtatható kódban a b. cikkelynek megfelelő írásbeli kötelezettségvállalással kapta.)” Ahogy arra a GPL 2.

pontjának magyarázatánál már utaltunk: a többszörözés és terjesztés feltételekhez kötött lehetőség és nem pedig kötelezettség A feltételek részletezését olvashatjuk a 3. pontban E pont hívja fel a figyelmet arra, hogy a program terjesztése vagy módosítása (a futtatás maga nem!) csak a feltételek elfogadása mellett tör2009. június 15 72 ténhet. Bár egy külső szemlélő számára úgy tűnhet, hogy ez a szabályozás is túlzott, hiszen a szabadságot ilyen programok esetében felesleges bármilyen módon korlátozni, és ezen programok megsértésére úgysem kerül sor. Ugyanakkor nem árt felfigyelni arra a reális, és hazánkban sajnálatos módon ismétlődően bekövetkezett34 jogsértésre, mely keretében az eredeti licenc eltávolítása35 és a program szerzőinek a forráskódból való kitörlése mellett bizonyos programok kereskedelmi forgalomban jelentek meg, és jogdíjkötelessé váltak, ugyanakkor sértették a licencnek még

azon pontját is, mely a forráskód megismerhetővé tételét, mint minimumkövetelményt jelölte meg. Nehézséget jelent azonban a jogvédelem, hiszen bár a magyar fordítások esetében a fordítók, mint szerzők fellelhetők, az eredeti mű jogosultjai vagy nem értesülnek a jogsértésről, vagy nem hisznek a nemzetközi perlekedésben és nem lépnek fel saját érdekük védelmében. Még ha el is tekintünk attól a programozók részéről jelentkező „természetes idegenkedéstől”, mellyel a jog felé fordulnak, láthatjuk, hogy a jogsértések között újabb és újabb esetek36 kerekednek az egyes szabad szoftverekhez kapcsolódó licencek megsértéséből. Magyarországon ilyen precedens döntésre még nem került sor, hiszen a magyar fejlesztők/szerzők jelenleg nem rendelkeznek olyan jogvédő szervezettel, mely képes volna a szabad szoftverek felhasználási szerződéseit megsértőkkel szemben fellépni, ugyanakkor vélhetően problémát jelentene a

jog érvényesítése is, hiszen még nincsen magyar bíróság által adott olyan „minta” ítélet sem, amely a szerződés érvényessége mellett foglalna állást. „Egy mű forráskódja a műnek azt a formáját jelenti, amely az átdolgozásra elsődlegesen alkalmas. Egy futtatható program a teljes forráskódot jelenti: valamennyi a program által tartalmazott modul forráskódját, továbbá a csatlakozófelületek (interface) leírásait tartalmazó fájlokat éppúgy, mint a fordítóés telepítőszkripteket. Mindazonáltal, speciális kivételként, a terjesztett forráskódnak semmi olyasmit nem kell tartalmaznia, amit általában a binárist futtató operációs rendszer fő komponenseivel (fordító, kernel stb.) terjesztenek (forráskód vagy bináris formában), kivéve, ha maga az adott komponens a futtatható állományt kíséri. 34 http://www.fsfhu/indexphp/eurolinux Az EuroOffice, mint az OpenOfficeorg magyar változatának átvétele, még a fordítási

hibák is egy az egyben megtalálhatóak(!); a Mandrake disztribúció, mint EuroLinux, illetve a Mozilla böngésző, mint Eurowebmester – ezen szoftverek (bár más és más licencelésűek) valamennyien kötelezővé teszik a forráskód megismerhetővé tételét, valamint annak lehetőségét, hogy a szerzők neve feltüntetést nyerhessen. 35 Ezen pont megsértésével kapcsolatosan indult a már említett első (még folyamatban lévő) német per is, ahol a bíróság ideiglenes intézkedés keretében eltiltotta a jogsértőt a szoftver további (licenc nélküli) terjesztésétől. 36 http://www.ifrossde/Fremdartikel/LGMuenchenUrteilpdf, http://www.ifrossde/ifross html/Druckfassung/Ziffer%204pdf 2009. június 15 73 Ha a futtatható program vagy tárgykód terjesztése akként történik, hogy egy erre kijelölt helyen másolási jogot biztosítanak, a forráskód terjesztésének minősül. Akkor is terjesztésről beszélünk, ha a kódhoz (forráskódként, illetve

futtatható formában) ezzel egyenértékű hozzáférést biztosítanak abban az esetben is, ha harmadik személyek nem kötelesek a forráskódot a tárgykóddal együtt lemásolni.” A licenc a könnyebb érthetőség érdekében tartalmazza a magyarázó rendelkezéseket. Kikötések „4. Ön a nem jogosult a Programot többszörözni, átdolgozni/megváltoztatni, tovább [harmadik személy részére] licencelni (allicencbe adni) vagy terjeszteni, amennyiben Önt e licenc erre kifejezetten nem jogosítja. A többszörözés, átdolgozás, allicencbe adás, terjesztés valamennyi más módja semmis és automatikusan a licenc által megszerzett jogok elvesztését vonja maga után. Mindazonáltal azon harmadik személyek jogviszonya/felhasználási engedélye, akik Ön által e licenc hatálya alatt másolatot vagy jogot szereztek, nem szűnik meg, mindaddig, amíg e licencet teljes mértékben elismerik és betartják.” „6. Minden alkalommal, amikor Ön a Programot (vagy az

azon alapuló művet) továbbadja, a fogadó fél automatikusan az eredeti vagyoni jogi jogosulttól (licencbeadó) kap felhasználási engedélyt (licenc) arra, hogy a Programot az itt meghatározott feltételeknek megfelelően többszörözhesse, terjeszthesse, és átdolgozhassa. Ön nem jogosult semmilyen módon a fogadó felet (felhasználót) megillető jogokat a továbbiakban korlátozni. Ön nem felel azért, hogy harmadik személyek jelen licencet betartsák.” Ahogy az már korábban kifejtésre került, a GPL-féle jogosítás direkt (közvetlen) jogosítás, felhasználóvá (licencbevevővé) válik az, aki az adott szoftvert az 1. és 2 pontokban rögzített módon kívánja felhasználni azaz gyakorolni kívánja: a többszörözés, terjesztés, átdolgozás jogát Puszta használat mellett nem lesz a licenc értelmében felhasználó az adott személy. A harmadik személy részére történő licencbeadásnak a szerzői jogi törvényben rögzített szigorú

előfeltételei vannak: – Csak akkor adhat a felhasználó további engedélyt a felhasználásra harmadik személynek, ha azt a szerző kifejezetten megengedte.37 – Ha a szerző beleegyezése nélkül ad további felhasználási engedélyt, a felhasználó és a jogszerző egyetemlegesen felelnek a felhasználási szerződés teljesítéséért.38 37 38 Szjt. 46 §, (1) bekezdés Szjt. 46 §, (3) bekezdés 2009. június 15 74 A GPL az itt megkívánt konkrét jogosítást azonban nem tartalmazza, sőt, a 6. pontban kifejezetten rögzíti, hogy a szerződéses jogviszony keretében az eredeti jogosult jogosít. Az a felhasználó, aki a GPL-lel licencelt szoftvert és a GPL-t harmadik személynek átadja valójában a szerződéskötésben működik közre. Így a felhasználó esetleges jogsértése a közvetített jogviszony esetében a harmadik féllel kapcsolatosan jogkövetkezménnyel nem jár. Ahogy korábban a jogkimerülés esetéről szó volt, az jelen esetben is

érvényes. Ha valamely számítógépet GPL alá tartozó operációs rendszerrel és irodacsomaggal hoznak forgalomba, a forgalombahozatalakor a GPL rendelkezéseit be kell tartani (például mellékelni kell a licencet és a forráskód hozzáférésének lehetőségét megjelölő nyilatkozatot). Azonban, ha a gépet megvásárló személy ezt az eszközt szoftverestől tovább kívánja adni, neki már a GPL rendelkezéseinek nem kell megfelelnie (azaz például nem kell mellékletet csatolnia). Az írásbeliségre vonatkozó rendelkezés és más jogkövetkezmények „5. Ön nem köteles ezen licencet elfogadni, hiszen nem írta alá Azonban semmilyen más módon nem nyílik joga, hogy a Programot vagy a Programon alapuló művet átdolgozza vagy terjessze. E cselekményeket – amennyiben e licencet nem ismeri el – a törvény tiltja. Azáltal, hogy a Programot (vagy a Programon alapuló művet) átdolgozza vagy terjeszti, jelen licenccel és annak minden a Program

többszörözésére, terjesztésére és átdolgozására vonatkozó feltételével való egyetértését nyilvánítja ki.” A szerződés létrejöttének tehát nem az aláírás a feltétele, hanem a közös szerződéses akarat. A felek között ugyan nem jön létre a szerződéses egyeztetés, hiszen általános szerződési feltételekkel dolgozik a jogosult, ugyanakkor a szerződés szabadsága jelen esetben is fennáll. A választás lehetősége adott: a szoftver meghatározott feltételek szerinti felhasználása, vagy teljes mértékben tartózkodás a felhasználástól. Korlátozások „7. Amennyiben Önnek egy bírósági ítélet, szabadalomsértés vélelme, vagy más (nem szabadalmi kérdésekre korlátozódó) okból olyan feltételeknek kell megfelelnie (akár bírósági határozat, akár egyezség vagy bármi más eredményeképp) amelyek jelen Licenc feltételeivel ellentétesek, Ön nem mentesül jelen licenc rendelkezései alól. Amennyiben nem lehetséges,

hogy a Programot egyidejűleg a licenc feltételeinek és a másrészről keletkezett kötelezettségeinek figyelembe vétele mellett terjessze, akkor Ön a Program terjesztésére egyáltalán nem jogosult. Ha például egy szabadalom nem teszi lehetővé, hogy azok, akik a Programot közvetlen vagy közvetett módon Öntől kapták meg a díjmentes továbbterjeszthessék, az egyetlen választható megoldás az marad, 2009. június 15 75 annak érdekében, hogy a szabadalmi jogot és ezen licencet is kövesse, ha a program terjesztésétől teljes mértékben tartózkodik/eláll.” Arra tekintettel, hogy a licenc angolszász megoldáson alapul – ahol a szoftverek szabadalmazása ismert és gyakorlott eljárás – került bele a jogi kikötéseket tartalmazó rendelkezés, amely a GPL v. 3 esetében sokkal részletesebben és alaposabban került kifejtésre Az egyes országok jogrendjéhez való igazítás módját és menetét más licenc modellek eltérő módon

szabályozzák. A Creative commons például minden egyes területileg érintett ország esetében újra és újra meghatározza a szerződés tartalmi elemeit. Ezeket az adott ország hivatalos nyelvén és angolul is közzéteszik, lehetővé téve ezáltal, hogy a felhasználók egy – a licenc használatát nagymértékben megkönnyítő – szöveggel dolgozzanak. A GPL esetében nehézséget jelent az a korábban is említett sajátosság, hogy az egyetlen, eredeti szerződésszövegnek az angol nyelvű verzió tekinthető. A GPL, mint általános szerződési feltétel39 minősül Abban az esetben, ha a felek egyike nem tud angolul – és így a szerződés tartalmával nincsen tisztában –, a felek között a szerződés érvényesen nem jöhetett létre.40 „Ha ezen paragrafusok egy része érvénytelennek vagy bizonyos körülmények között érvényesíthetetlennek minősülne, ezen Paragrafust értelemszerűen kell alkalmazni ; a többi esetben a Paragrafust, mint

egészet kell érvényesíteni.” A részleges érvénytelenség szabályozása ismert szerződéstechnikai elem. A polgári törvénykönyv is szabályozza az ezzel kapcsolatos jogkövetkezményeket.41 „Ezen Paragrafusok célja nem az hogy Önt valamely szabadalom vagy más tulajdonjogi igény megsértésére ösztönözze, illetve hogy ezen igények hatályosságát/jogosságát vitassa ; e Paragrafus egyetlen célja, hogy a szabad szoftverek terjesztési rendszerének integritását – amely a nyilvános licencek gyakorlata által valósul meg – megóvja. Jelen rendszer keretében terjesztett szoftverek jelentős kínálatához sok ember nagylelkű felajánlással, a rendszer következetes működésében bízva járult hozzá; a Szerző/Vagyoni jogi jogosult joga eldönteni, hogy a szoftvert valamely másik rendszer keretében is terjeszteni kívánjae, a felhasználónak (licencebe vevőnek) erre a döntésre semmilyen ráhatása nincs. E szakasz célja az, hogy pontosan

tisztázza, mit kell következtetésként / következményként a licenc hátralévő részéből figyelembe venni.” 39 Ptk. 205/A §, (1) bekezdés Die kommentierte GPL 101. o 41 Ptk. 239 § 40 2009. június 15 76 A copyleft szabályok működésének magyarázata mellett e rész rendelkezik arról is, hogy a művel/szoftverrel kapcsolatos bármilyen jogosítás lehetősége a szerzőket, illetve a vagyoni jogokat megszerzőt illeti. A licenc nem zárja ki, hogy egymás mellett több engedélyezési megoldás valósuljon meg, ennek azonban speciális (részben a 10. pontban megjelölt) feltételei vannak Területi korlátozás „8. Ha a Program terjesztése és/vagy használata egyes országokban akár szabadalmak, akár szerzői jogi oltalom alatt álló csatlakozó felületek (interface) miatt korlátozott, akkor a Program szerzői jogi jogosultja, aki a Programot e licenccel tette közzé/e licenc alá helyezte, a terjesztést kifejezett területi korlátozással láthatja

el. Amelyben bizonyos országok kizárásra kerülnek, a terjesztés csak olyan országokra vonatkozóan lesz engedélyezett, amelyek nincsenek kizárva. Ilyen esetben a korlátozás a licenc részét képezi, mintha ezen szöveg részeként került volna megfogalmazásra.” Ahogy arra utaltunk már, a licenc nagyon kevés korlátozása közül az egyik egy területi korlátozás. A kizárt területeket (vagy egyes esetekben az engedélyezett területeket, ha ezekből van kevesebb) a szoftver ismertető adatai között is feltüntetik amellett, hogy a licenc részét képezi az ezzel kapcsolatos megjegyzés. A GPL változatai „9. A Free Software Foundation időről időre kiadja/nyilvánosságra hozza a General Public License dokumentum átdolgozott és/vagy új változatait. Ezek az újabb változatok alapvetően a korábbiak szellemében készülnek, de részletekben eltérhetnek, annak érdekében, hogy új problémákat vagy kihívásokat is kezeljenek Jelen licenc minden

változatának egy egyedi megkülönböztető verziószáma van. Ha a Program szerzői jogi megjegyzésében egy bizonyos verziószám vagy »valamennyi újabb verzió« van megjelölve, akkor Önnek lehetősége van arra, hogy akár a megjelölt, akár a Free Software Foundation által kiadott későbbi verzióban leírt feltételeket kövesse. Ha nincs ilyen megjelölt verzió, akkor Ön jogosult a Free Software Foundation által valaha kibocsátott bármelyik licencet választani.” Érdekessége a licencnek, hogy ezen a ponton választási lehetőséget enged a felhasználónak, hiszen engedélyezi az alap vagy az újabb változatok választását. Mivel a licencek részlegesen eltérnek egymástól (egyre szélesebb körben szabályozottak), ezért a választás lehetősége ténylegesen megadatik. A változtatás szükségszerűsége az „ismeretlen felhasználási módok” ismerté válásából is következik, hiszen ismeretlen felhasználási módra jogosítani a szerzői

jogi törvény értelmében nem lehet: 2009. június 15 77 „A szerződés megkötésekor ismeretlen felhasználási módra vonatkozó felhasználási engedély érvényesen nem adható. A felhasználásnak a szerződés megkötését követően kialakuló módszere nem tekinthető a szerződés megkötésekor ismeretlen felhasználási módnak pusztán azért, mert a korábban is ismert felhasználási mód megvalósítását hatékonyabban, kedvezőbb feltételekkel vagy jobb minőségben teszi lehetővé.” 42 Eltérés a GPL-től „10. Amennyiben a Programot más szabad szoftverben kívánja felhasználni, amelynek a terjesztéssel kapcsolatos feltételei eltérőek, írjon a Szerzőnek, és kérje ehhez a hozzájárulását. Olyan szoftverek esetében, ahol szerzői jogi jogosultként a Free Software Foundation van megjelölve, írjon a Free Software Foundation-nek Néha teszünk kivételt A döntést a következő célok szem előtt tartásával hozzuk meg: maradjon meg a

szabad szoftvereinken alapuló művek szabad állapota, valamint segítse elő általában véve a szoftver újrafelhasználását és megosztását.” Ahogy arra korábban utaltunk, a szerző/vagyoni jogok jogosultja – amenynyiben nem adott kizárólagos jogosultságot át – dönthet arról, hogy a művet az eredeti felhasználási engedélytől eltérő formában teszi közzé. Éppen ezért, ha fontos, egyedi licenccel rendelkező projekthez szeretnének GPL-lel védett részeket felhasználni, a szerzőt megkeresve, az ő engedélyével lehetőség van egy másik licenc használatára. Nyilván a Free Software Foundation csak az általuk elismert „szabadság” megtartása mellett ad engedélyt. A felelősség kizárása „11. Mivel jelen program díjmentesen kerül engedélyezésre, a jogszabályokban meghatározott keretekig kizárjuk a programmal kapcsolatos garanciát. Amennyiben írásban ettől eltérően nem rendelkeznek, a szerzői jogi jogosultak és/vagy harmadik

személyek a programot »jelen állapotában« (ahogy van) bocsátják rendelkezésre, bármilyen garancia nélkül, sem kifejezetten, sem belefoglalva, ide értve – de nem korlátozva – forgalombahozatal vagy egy bizonyos célra történő alkalmazhatóságra vonatkozó garanciákat. A program minőségéből és működéséből/teljesítményéből fakadó összes kockázatot ön viseli. Amennyiben a program hibásan működik, önnek kell vállalni a szükséges szerviz, javítás vagy kiigazítás költségeit.” „12. Semmilyen esetben sem – kivéve, ha a hatályos jogszabályok megkívánják vagy írásban rögzítésre került – köteles a vagyoni jogi jogosult vagy valamely, a programot a fentebb rögzített engedély alapján átdolgozó vagy terjesztő harmadik személy önnel szemben kárért, ide értve az általános vagy különös károkért, károk mellékhatásaiért vagy következményeiért, amelyek a program használatából vagy

használhatatlanságából eredtek (ide értve, de 42 Szjt. 44 §, (2) bekezdés 2009. június 15 78 nem korlátozva az adatvesztésre, az adatok hibás feldolgozására, veszteségekre, amit önnek vagy harmadik félnek kell viselnie, vagy olyan hibára, amely következtében a program más programmal nem tud együttműködni) nem felel, abban az esetben sem, ha a vagyoni jogi jogosult vagy harmadik személy figyelmét ezen károk bekövetkezésének lehetőségére felhívták.” A szerződésszegés külön szabályai szerint43 sem lehet érvényesen kizárni a szándékosan, súlyos gondatlansággal vagy bűncselekménnyel okozott, továbbá az életet, testi épséget, egészséget megkárosító szerződésszegésért való felelősséget. A szerződésszegésért való felelősséget – ezen szintet meghaladóan – azonban ki lehet zárni, amennyiben az ezzel járó hátrányt kompenzálják Míg kereskedelmi szoftverek esetében a magas licencárak mellett ez (a

felhasználási szerződésben így megjelölt kritérium ellenére) nem ismerhető el, a GPL alatt közzétett, a licencdíj teljes hiánya következtében helytálló kitétel lehet. Mivel a szabad szoftverek terjesztése az ajándékozással analóg megoldás, az arra vonatkozó felelősségi szabályokat kell alkalmazni.44 Ahogy arra utaltunk, az egyes szoftverekhez kapcsolódóan helytállás vállalható (ezzel kapcsolatos szerződés keretében például support, SLA). 6.2 Adójogi vonatkozások Habár a jogalkotásról szóló 1987. évi IX törvény 24 §, (1) bekezdésében foglaltak szerint „Az igazságügyminiszter felelős azért, hogy a jogszabály összhangban álljon más jogszabályokkal, megfeleljen a jogpolitikai elveknek, illeszkedjen be az egységes jogrendszerbe, és feleljen meg a jogalkotás szakmai követelményeinek.” Ennek ellenére évek óta problémát jelent a szellemi alkotásokkal kapcsolatos közterhek szabályozásában, hogy az e területre

vonatkozó törvények figyelmen kívül hagynak45 alapvető szerzői jogi, és iparjogvédelmi viszonyokat, illetve e viszonyokra a „definíciós kényszer” elvével46 az adott jogterülettől idegen kifejezéseket használnak. 43 Ptk. 314 §, (1) bekezdés Ptk. 581 §, (2) bekezdés 45 „. a különböző közterheket előíró jogszabályok alkotói absztrakt szemlélettel fogalmazzák meg a normákat, vagyis rendszerint eltérő szempontjaik miatt nincsenek tekintettel a szellemi alkotások értékesítésének sajátosságaira.” Faludi Gábor : A felhasználási szerződés, Közgazdasági és Jogi Könyvkiadó, Budapest 1999., 213 o 46 A törvényi fogalommeghatározás keretében a bevett és közismert jogi fogalmaktól eltérő, gyakran megtévesztő fogalmakat vezetnek be. 44 2009. június 15 79 6.21 A számviteli szabályozás alapjai A számviteli törvény hatálya A számvitelről szóló 2000. évi C törvény (a továbbiakban: Sztv) hatálya néhány

kivételtől eltekintve kiterjed a gazdaság minden olyan résztvevőjére, amelynek működéséről a nemzetgazdaság más szereplői tájékoztatást igényelnek, valamint a gazdálkodóra (a továbbiakban: vállalkozó). A törvény hatálya nem terjed ki többek között47 a fejlesztőkre (szerzőkre), ha egyéni vállalkozók, akkor sem, ha őket egyéni cégként a cégbíróságon bejegyezték, valamint az egyszerűsített vállalkozói adó hatálya alá tartozó jogi személyiség nélküli gazdasági társaságokra. Magánszemélyek esetében tehát ez a probléma nem áll fenn, ugyanakkor, ha a törvény hatálya alá tartozó gazdasági szereplő gazdálkodásában megjelenik egy szoftver, az alábbi nehézségekkel szembesül. A mérleg Az Sztv. 23 §, (1) és (4) bekezdése kimondja, hogy: „A mérlegben eszközként kell kimutatni a vállalkozó rendelkezésére, használatára bocsátott, a vállalkozó működését szolgáló befektetett eszközöket és

forgóeszközöket – a bérbe vett eszközök kivételével –, függetlenül attól, hogy azok tulajdonjoga csak törvényben, szerződésben rögzített feltételek teljesítése után kerül át a vállalkozóhoz, továbbá az aktív időbeli elhatárolásokat. Az eszközöket rendeltetésük, használatuk alapján kell a befektetett eszközök vagy a forgóeszközök közé sorolni.” E rendelkezés alapján tehát eszköz oldalon kellene felmutatni valamennyi szoftvert, amelyeket a vállalkozó a működésének biztosítására, elősegítésére szerzett be. Ez a szabályozási modell első ránézésre egyszerűnek tűnik Azonban, ha belegondolunk a részletekbe, sok egyéb mellett a következő kérdésekkel találhatjuk magunkat szemközt: Hangsúlyosan jelentkezik ebben a körben, hogy létezik-e értékhatár (például 500 vagy 1000 forint), amely alatt a beszerzés körébe tartozó szoftvert (illetve az erre vonatkozó felhasználási jogosultságot) mégsem kell

megjelölni a könyvelésben? Valóban elvárható-e a vállalkozótól (vagy a könyvelőjétől), hogy valamennyi – használatában álló – szoftver vonatkozásában pontos nyilvántartást vezessen? Elvárható-e, hogy ezeket az egyes – akár automatikus – upgrade-ket követően frissítse? 47 Nem állnak a törvény hatálya alatt továbbá : a polgári jogi társaság, az építőközösség, a külföldi székhelyű vállalkozás magyarországi kereskedelmi képviselete. 2009. június 15 80 Elvárható-e, hogy meg tudjon különböztetni oltalom alá tartozó valós alkotásokat, amelyek esetében a használat engedélyezésére jogot kell szerezni olyan szoftverektől, szoftver moduloktól, amelyek az elvárt oltalmi szintet nem érik el – tehát engedély nélkül felhasználhatóak? A vagyoni jogi jogosultság és a vagyoni értékű jog megkülönböztetése A kutatások, és könyvelőkkel, könyvvizsgálókkal folytatott interjúk rámutattak arra, hogy a

közteher szabályok és a szerzői jog konfrontációja alapvetően egy fogalmi tévedésre vezethető vissza. Bár a köznyelvben és – sajnos – az APEH állásfoglalásában is keveredik két fogalom. A számviteli törvény meghatározása szerint: „25. §, (6) Az immateriális javak között vagyoni értékű jogként azokat a megszerzett jogokat kell kimutatni, amelyek nem kapcsolódnak ingatlanhoz. Ilyenek különösen : a bérleti jog, a használati jog, a vagyonkezelői jog, a szellemi termékek felhasználási joga, a licencek, továbbá a koncessziós jog, a játékjog, valamint az ingatlanhoz nem kapcsolódó egyéb jogok.” Ez azt jelenti, hogy azokban az esetekben, amikor a cég egy vagyoni jogi jogosulttól felhasználási engedélyt szerez, az engedély maga bír vagyoni jogi értékkel. A szerzői jogi vagyoni jogi jogosultság a számviteli törvény fogalmai közül a „szellemi termék” fogalma alá tartozik. „Szellemi termékek közé sorolandók: a

találmány, az iparjogvédelemben részesülő javak közül a szabadalom és az ipari minta, a szerzői jogvédelemben részesülő szoftver termékek, az egyéb szellemi alkotások, a jogvédelemben nem részesülő, de titkossága révén monopolizált javak közül a know-how és gyártási eljárás, a védjegy, függetlenül attól, hogy azt vásárolták vagy a vállalkozó állította elő, illetve használatba vették-e azokat vagy sem.” Értelmezési nehézséget jelent itt is, hogy bár maga a szerzői jogvédelemben részesülő szoftvertermék, mint mű élvezi az oltalmat, a számviteli törvény a mű értékére utal, ami megegyezik a vagyoni jogi jogosultság értékével. A vagyoni jogi jogosultság értékét többnyire a társaság maga állapítja meg könyvvizsgáló közreműködésével. A mérlegben szellemi termék és vagyoni értékű jog két külön soron kerül feltüntetésre. Gyakorlati vonatkozás Az idézett jogszabályhelyek az alábbi

vonatkozásokban vizsgálandóak: 2009. június 15 81 1. A vállalkozó vagyoni jogokat szerez48 egy szoftveren, és az adott szoftver vonatkozásában felhasználási jogokat értékesít. Ebben az esetben a szoftver – pontosabban a szoftver feletti rendelkezési jogot biztosító jogosultság megszerzése – befektetett eszköznek minősül, és mint szellemi termék kerül könyvelésre. A harmadik személynek nyújtott felhasználási engedély pedig annak könyveiben vagyoni értékű jogként jelenik meg. 2. A vállalkozó értékesíteni kívánja korábban a vállalkozási tevékenység folytatásához vásárolt szoftverét. Ebben az esetben a befektetett eszköz forgó eszközzé történő átminősítését követően kerülhet sor az értékesítésre. A szoftverhez kapcsolódó felhasználási jogosultság feltüntetésére a könyvekben, mint vagyoni értékű jog kerül sor. 3. A vállalkozó más vagyoni jogi jogosult által forgalmazott szoftverek

viszonteladásával foglalkozik. Itt a raktárkészlet részét képező forgóeszköz állományról van szó. A felhasználási jog a vállalkozót sosem illette meg, szerződéses jogviszony közte és a vagyoni jogok jogosultja (például szoftvergyártó) között nem jött létre. 4. A vállalkozás szoftverbérleti szerződés keretében használ egy szoftvert E körben érdemes megvizsgálni a 84/2003. számviteli kérdést: „Vállalkozásunk bérli a vállalatirányításhoz használt szoftvert. A szoftver használatának megkezdése óta cégünk működésében, valamint a jogszabályi környezetben is több fontos változás következett be, ezért szükségessé vált a bérelt szoftver fejlesztése A fejlesztést nem a szoftver tulajdonosa, hanem vállalkozásunk fizette Hogyan kell a fejlesztésért fizetett összeget elszámolni ? Lehetséges-e – a bérelt ingatlanokon végzett beruházás elszámolásához hasonlóan – a fejlesztést immateriális jószágként

aktiválni ?” A kérdés megválaszolásakor maga az adóhatóság is analógia alkalmazásához folyamodik: „A számvitelről szóló 2000. évi C törvény (a továbbiakban: számviteli törvény) valóban nem említi konkrétan a bérelt szoftveren végzett beruházás 48 Akár oly módon, hogy fejlesztőket munkaviszonyban foglalkoztat, akár erre vonatkozó szerződés útján. 2009. június 15 82 fogalmát, a törvény előírásaiból azonban kitűnik, hogy a bérelt szoftveren végzett beruházás elszámolása hasonlít a bérelt ingatlanon, a bérelt egyéb eszközökön végzett beruházás elszámolásához. A számviteli törvény 23 §-ának (3) bekezdése szerint az eszközök között kell kimutatni a bérelt eszközökön végzett beruházást is. Bár a számviteli törvény a bérelt ingatlanokat, gépeket, valamint berendezéseket nevesíti, ez természetesen nem jelenti azt, hogy a szoftver e tekintetben ne minősülne eszköznek. Ily módon indokolt,

hogy a bérelt szoftveren végzett beruházás értékét a vállalkozás az immateriális javak között aktiválja. Ebben az esetben meg kell határozni az adott beruházás hasznos élettartamát, valamint maradványértékét, és ennek megfelelően terv szerinti értékcsökkenést kell utána elszámolni. Fontos, hogy a beruházás bekerülési értékébe valóban csak a szoftverrel szoros kapcsolatban lévő és a számviteli törvény bekerülési értékre vonatkozó előírásait kielégítő tételek kerülhetnek.” 49 Szerzői jogi megközelítésből: a határozott időre szóló felhasználási jog keretében (bérlet) átadott szoftver átdolgozására történt jogosítás. Amennyiben az átdolgozás következtében – az alkotáskénti elismeréshez szükséges minimál szintet meghaladja – az eredeti jogosult és az átdolgozó szerzőtársakká váltak, innentől fogva részben vagyoni jogokkal rendelkezik a szoftverrészlet fejlesztője is, tehát a szoftver

egy része ezen okból kifolyólag részben szellemi termék, részben viszont vagyoni értékű jogként kellene, hogy feltüntetésre kerüljön. Ez a példa is mutatja, hogy egy jó szándékú, tagadhatatlanul irányadó állásfoglalás is lehet egyértelműen téves. A szoftver egyik elemi tulajdonsága, hogy nem hasonlítható egy ingatlanhoz Egy szoftver nagyobb mértékű átdolgozására külön jogosítás esetében kerülhet csak sor, hiszen ennek következtében nem csak felhasználási, hanem vagyoni jogok is keletkezhetnek. A szoftverbérlet szabályainak koherenciája az egyes jogterületek között a jogalkotó feladata. Figyelemmel ugyanis a jogkimerülés elvére50 , várható (és 49 50 2000. évi C törvény 23 §, (3) bekezdés „Ha a műpéldányt a jogosult vagy az ő kifejezett hozzájárulásával másvalaki adásvétellel vagy a tulajdonjog más módon történő átruházásával az Európai Gazdasági Térségben forgalomba hozta, a terjesztés joga az

így forgalomba hozott műpéldány tekintetében – a bérbeadás, a haszonkölcsönbe adás és a behozatal joga kivételével – a továbbiakban nem gyakorolható.” Szjt 23 §, (5) bekezdés E szabály lényege ugyanis, hogy a már forgalomba került műpéldányok (felhasználási engedélyek) vonatkozásában az eredeti jogosult további korlátozási joggal nem rendelkezik, tehát lehetőség nyílik arra, hogy egy valaki az általa (időben korlátlan felhasználási engedély alapján) korábban használt szoftvert az eredeti jogosult engedélye nélkül harmadik személyre ruházza át. E téma részletes kifejtése, az ezzel kapcsolatban kialakult nemzetközi gyakorlat bemutatása, e lehetőségnek a közigazgatásra gyakorolható hatása külön tanulmány tárgyát képezheti. 2009. június 15 83 az új licencmodellek alapján tapasztalható is), hogy a nagyobb szoftverházak a „bérleti viszony”, azaz a határozott időre történő jogosítás irányában

mozdulnak el az elkövetkező években. Az „egy éves szabály” A számviteli törvény rendelkezései szerint: „Befektetett eszközként olyan eszközt szabad kimutatni, amelynek az a rendeltetése, hogy a tevékenységet, a működést tartósan, legalább egy éven túl szolgálja. A befektetett eszközök közé az immateriális javakat, a tárgyi eszközöket, a befektetett pénzügyi eszközöket kell besorolni.” 51 „A tárgyi eszközök között a mérlegben azokat a rendeltetésszerűen használatba vett, üzembe helyezett anyagi eszközöket (földterület, telek, telkesítés, erdő, ültetvény, épület, egyéb építmény, műszaki berendezés, gép, jármű, üzemi és üzleti felszerelés, egyéb berendezés, ingatlanokhoz kapcsolódó vagyoni értékű jogok), tenyészállatokat kell kimutatni, amelyek tartósan – közvetlenül vagy közvetett módon – szolgálják a vállalkozó tevékenységét, továbbá az ezen eszközök beszerzésére (a

beruházásokra) adott előlegeket és a beruházásokat, valamint a tárgyi eszközök értékhelyesbítését.” 52 Joggal merülhet fel az a kérdés, hogy milyen módon kell eljárni, ha az immateriális javak egy évnél rövidebb időszakig szolgálják a tevékenységet, működést? Mi a helyzet azokban az esetekben, mikor egy szoftvert csak egy projektre fejlesztenek? Ha a szoftvert valamely egyedi alkalom kapcsán készítik el? Ha a felhasználási jogot időben korlátozva (például néhány hónap) engedik át a vállalkozás részére? Vagy, ha a vállalkozás jár el hasonlóan, azonban ez alatt a rövidebb idő alatt keletkezett bevétele teljes mértékben igazolja a szoftverhez fűzött előzetes várakozásokat?53 6.22 Az adózás rendje Alapelvek Az adózás rendjéről szóló 2003. évi XCII törvény (a továbbiakban: Art) az 1. §-ban foglalt alapelvek között rögzíti, hogy – „az adózó és az adóhatóság e törvénynek és más törvényeknek

megfelelően gyakorolhatja jogait és teljesíti kötelezettségeit. Ha a törvény az 51 Sztv. 24 §, (1)–(2) bekezdés Sztv. 26 §, (1) bekezdés 53 E kérdések megválaszolásához egyeztetni kellene a jogalkotó, valamint a jogalkalmazó hatóságok e kérdésekre vonatkozó nézeteit. 52 2009. június 15 84 adóhatóságot mérlegelésre jogosítja fel, azt csak a felhatalmazás céljának megfelelően, a törvényes keretek között gyakorolhatja.” E ponton rögzíti a törvény, hogy az adóhatóság nem csak és kizárólagosan egy törvény vizsgálatára köteles. Az adóhatóságnak – még abban az esetben is, ha az adózó erre a figyelmét nem hívja fel – figyelemmel kellene lennie más, a közteher törvények körét meghaladó jogszabályokra, amennyiben azok szerzői-, iparjogvédelmi oltalomra visszavezethető jogosultságokat érintenek. Ahogy arra a kommentár rámutat: „Az adózás természeténél fogva beavatkozás a természetes személyek és

szervezeteik autonómiájába, annak sajátos, törvénnyel szabályozott korlátozása. Az adózó garanciális érdeke is azt kívánja, hogy ez az intervenció ne történhessen szabályozatlanul, parttalanul. A magánszemélyek, jogi személyek és egyéb szervezetek érdekeit tehát nem az életviszonyok szabályozatlanul hagyása vagy csak töredékes keretszabályozása szolgálja, hanem az, ha törvény rögzíti az adózók és az adóhatóság teendőit, cselekvési lehetőségeit és annak hatásait.” 54 Ennek értelmében tehát egy dinamikusan fejlődő iparágat, az informatika területét nem lehet régi, rossz sablonok alapján megítélni. Elkerülhetetlen, hogy egyrészről a szellemi alkotások helyét, szerepét, felhasználásaik módját rögzítő, másrészről a közteher szabályokat megállapító törvények harmonizációjára sor kerüljön. Figyelemmel azonban arra, hogy jelen esetben például a szerzői jogi törvény rengeteg nemzetközi szabályon

és megállapodáson nyugszik, célszerű a jogszabályok rendezésekor erre figyelemmel lenni, és a szerzői jogi szabályokat etalonként megőrizve formálni az adózással kapcsolatos kötelezettségeket. Adózási kérdéseknél „a jogok és kötelességek kölcsönössége más jellegű, mint a szerződéses jogviszonyokban, mégis az adóhatóságok és az adózók kapcsolata e jogokra és kötelességekre tekintettel törvényesen rendezett.” 54 Az adózás rendjének nyilvánvalóan egyidejűleg kell törvényesnek és eredményesnek lennie. Az a fajta eredményesség azonban, mikor – tekintettel arra, hogy sem az ellenőr, sem az adózó nem érti, nem is értheti – az alapul szolgáló szabályokat, és a közös bizonytalanság bírság kiszabásához vezet, sérti a törvényesség szellemét. Itt kell megjegyezni, hogy a FLOS szoftverek használata során sosem merült fel és nem is merülhet fel, hogy ennek használói vagy fejlesztői – az ellenőrzés

lehetősége nélkül – kivonják magukat a közteherviselés alkotmányos kötelezettsége alól. A FLOS szoftverek megjelenése a gazdaságban nem lehetetleníti el az ezzel kapcsolatos adók kivetését, csupán az adóztatási szabályok pontosítását kívánja meg. Bár eddig is akadtak problémák a szerzői joggal kapcsolatos jogviszonyok kezelésében, de ezek halmozottan fognak 54 KJK Kerszöv, Complex Jogtár, Art – Kommentár 2009. június 15 85 megjelenni, amennyiben a FLOS szoftverek fejlesztése, terjesztése, az ezzel kapcsolatos szolgáltatás nyújtása általánossá válik. A szoftverek ugyanis a korábban kifejtettek szerint a szellemi alkotások között is egyedi helyet foglalnak el, és válnak ezáltal halmozottan problémássá. – „az adóhatóság minden ügyben megkülönböztetés nélkül, a törvényeknek megfelelően köteles eljárni és intézkedni.” Ahogy arra a korábbi pontban rámutattunk, a törvények ismerete a jelenlegi

jogalkalmazói gyakorlatban nem teljes. A jogértelmezések egyedi vonása következtében az ügyek, adózók között megkülönböztetésre kerül sor, hiszen egy-egy adott probléma megítélése akár régiónként változhat. Egyrészt hiányzik a koherens jogi szabályozás, másrészt hiányzik a bírói kontroll Az esetek jelentős részében ugyanis az érintett felek nem kezdeményeznek ezzel kapcsolatos jogvitát, hiszen az ügyvéd vagy jogtanácsos – akit felkeresnek – sincsen tisztában a mögöttes viszonyokkal. – „az adóhatóság az adózónak a törvények megtartásához szükséges tájékoztatást megadja, az adóbevallás, az adóbefizetés rendjét vele megismerteti, az adózót jogainak érvényesítésére figyelmezteti. Az adózó köteles a jogait jóhiszeműen gyakorolni és elősegíteni az adóhatóság feladatainak végrehajtását” Jelen alapelv nehézsége abban rejlik, hogy a tájékoztatáshoz szükséges szakismeret hiányzik. Sajnos

jelenleg Magyarországon nincsenek sem a szerzői jogban, sem a szoftverjogban járatos revizorok, hiszen – ismereteink szerint – aki képzést kap, az csak a BSA által tanított nézeteket ismeri meg, amelyek egy FLOS szoftver adózási kérdéseinek elbírálásánál teljességgel alkalmazhatatlanok. – „Az adóhatóság köteles méltányosan eljárni, és ha a törvényekben, illetve e törvényben meghatározott feltételek fennállnak, az adótartozást mérsékli, illetve fizetési könnyítést engedélyez.” Felmerül a kérdés, hogy van-e helye méltányosságnak, ha a törvényekben meghatározott feltételek értelmezéséhez szükséges tudás egy átlagos állampolgár, vagy akár egy átlagos adójogi szakértő ismereteit jóval meghaladja? Van-e helye a bírság55 mérséklésének, ha a jogi helyzet megítélése egyáltalán nem triviális, és maga a Hatóság (illetve a Hatóság egyes regionális szervei) is több ponton félreértelmezi(k) azt? 55

Art. 170 §, (1) bekezdés Adóhiány esetén adóbírságot kell fizetni Az adóbírság mértéke – ha e törvény másként nem rendelkezik – az adóhiány 50%-a. Adóbírságot állapít meg az adóhatóság akkor is, ha az adózó jogosulatlanul nyújtotta be támogatási, adó-visszaigénylési, adó-visszatérítési kérelmét, vagy igénylésre, támogatásra, visszatérítésre vonatkozó bevallását, és a jogosultság hiányát az adóhatóság a ki- 2009. június 15 86 – „A szerződést, ügyletet és más hasonló cselekményeket valódi tartalmuk szerint kell minősíteni. ” A szerződések valódi tartalmának megállapításánál ismételten kiemelt figyelmet kell fordítani a szerzői jogi törvényre, amely szintén rendelkezik a felhasználási szerződések értelmezéséről. Az Szjt által nyújtott értelmezési támpont szerint: „Ha a felhasználási szerződés tartalma nem állapítható meg egyértelműen, a szerző számára kedvezőbb

értelmezést kell elfogadni.” 56 utalás előtt megállapította. A bírság alapja ilyen esetben a jogosulatlanul igényelt összeg. Az alábbi mulasztások alapjaként szolgálhat a szabad szoftverek kezelésének hibás volta: 172. §, (1) A magánszemély adózó 200 ezer forintig, más adózó 500 ezer forintig terjedő mulasztási bírsággal sújtható, ha a) a bejelentési (bejelentkezési, változásbejelentési), adatszolgáltatási kötelezettségét késedelmesen, hibásan, valótlan adattartalommal vagy hiányosan teljesíti, b) a bevallási, vagyonszerzési illetékkel kapcsolatos bejelentési (a továbbiakban együtt: bevallási) kötelezettségét a bevallás határidejét követően, de az adóhatóság felszólítását, ellenőrzését megelőzően késedelmesen teljesíti és késedelmét nem menti ki (bevallási késedelem), c) bejelentési (bejelentkezési, változásbejelentési), adatszolgáltatási, bankszámlanyitási kötelezettségét, továbbá

bevallási kötelezettségét nem teljesíti, e) a jogszabályokban előírt bizonylatok kiállítását, illetve könyvek, nyilvántartások vezetését elmulasztja, a bizonylatokat az előírásoktól eltérően állítja ki, a könyveket, nyilvántartásokat hiányosan vagy az előírásoktól eltérően vezeti, vagy a számviteli törvényben meghatározott pénzkezelési szabályzatra vonatkozó rendelkezéseket megsérti, f) iratmegőrzési kötelezettségének nem tesz eleget, g) az ellenőrzés időpontjában az áru eredetét tanúsító bizonylattal vagy annak másolatával nem rendelkezik, h) az e törvény felhatalmazása alapján kiadott külön jogszabályban meghatározott feltételek megsértésével állít elő és/vagy hoz forgalomba nyomtatványt, i) a nyilatkozattételt elmulasztja, a tanúvallomást jogosulatlanul megtagadja, j) a költségvetési támogatás (adó-visszaigénylés, adó-visszatérítés) igénylésénél a fennálló köztartozásáról valótlan

tartalmú nyilatkozatot tesz, k) a járulékfizetési kötelezettség felső határának eléréséről valótlan tartalmú nyilatkozatot tesz, l) az ellenőrzést, az üzletlezárást, illetőleg a tevékenység felfüggesztésének alkalmazását vagy a végrehajtási eljárást a megjelenési kötelezettség elmulasztásával, az együttműködési kötelezettség megsértésével vagy más módon akadályozza, különösen ilyennek minősül, ha a becslés során az adózó bizonyítékként más adózót is érintő szerződéses kapcsolatra vagy egyéb ügyletre hivatkozik, és az ez alapján lefolytatott kapcsolódó vizsgálat az adózó bizonyítási indítványában foglaltakat nem támasztja alá. Bár az egyes példák levezetése jelen tanulmány kereteit meghaladja, amennyiben a terület és az itt tárgyalt adójogi viszonyok felülvizsgálatára sor kerül, e pontok vonatkozásában részletesebb kutatás lefolytatása válik indokolttá. 56 42. §, (3) bekezdés 2009.

június 15 87 Következik-e az imént bemutatott párhuzamból, hogy ez a komplex értelmezési struktúra végső soron azt az elvárást támasztja az adóhatóság felé, hogy az adójogi szabályok alkalmazása esetén a szerződés valós tartalmának megállapításakor is a szerző részére kedvező értelmezést vegyék alapul? 6.23 A társasági adóval kapcsolatos rendelkezések A társasági adóval kapcsolatos szabályok állnak legközelebb a FLOS szoftverek fejlesztési elveihez, ezek ugyanis megfelelnek a kutatás-fejlesztésről és a technológiai innovációról szóló 2004. évi CXXXIV törvényben foglalt kritériumoknak: „c) kísérleti (vagy pre-kompetitív) fejlesztés: a kutatásból és/vagy a gyakorlati tapasztalatokból nyert, már létező tudásra támaszkodó tevékenység, amelynek célja új anyagok, termékek, eljárások, rendszerek, szolgáltatások létrehozása, vagy a már meglévők lényeges továbbfejlesztése (a továbbiakban:

kísérleti fejlesztés) ;” az ezzel kapcsolatos műveletek pedig azonosíthatóak a technológiai innováció fogalmával: „2. technológiai innováció : a gazdasági tevékenység hatékonyságának, jövedelmezőségének javítása, illetve kedvező társadalmi és környezeti hatások elérése érdekében végzett tudományos, műszaki, szervezési, gazdálkodási, kereskedelmi műveletek összessége, amelyek eredményeként új vagy lényegesen módosított termékek, eljárások, szolgáltatások jönnek létre, új vagy lényegesen módosított eljárások, technológiák alkalmazására, piaci bevezetésére kerül sor, beleértve azokat a változásokat, amelyek csak adott ágazatban vagy adott szervezetnél minősülnek újdonságnak;” A társasági adó szabályai ugyanis lehetővé teszik az alábbiakat: „Az adózás előtti eredményt csökkenti [. ] az adózó az adóévben az alapkutatás, az alkalmazott kutatás vagy a kísérleti fejlesztés közvetlen

költségei között, továbbá a szoftverfejlesztő alkalmazására tekintettel elszámolt bérköltség 10 százalékának megfelelő összegű adókedvezményt vehet igénybe, amelyet az adóévben és az azt követő három adóévben, egyenlő részletekben érvényesíthet, azzal, hogy a megelőző adóév(ek)ben – adó hiányában – nem érvényesített adókedvezmény az említett időszakon belül igénybe vehető. Az adókedvezmény igénybevétele független attól, hogy az adózó az alapkutatás, az alkalmazott kutatás vagy a kísérleti fejlesztés közvetlen költségeivel csökkentette adózás előtti eredményét az adóalap megállapításakor.” 57 Valamint: 57 Tao 7. § 2009. június 15 88 „Az adózó adókedvezményt vehet igénybe a jelenértéken legalább 100 millió forint értékű, az alapkutatást, az alkalmazott kutatást vagy a kísérleti fejlesztést szolgáló beruházás, üzembe helyezése és a kormányrendeletben foglaltak szerinti

üzemeltetése esetén, feltéve, hogy a beruházás új létesítmény létrehozatalát, meglévő létesítmény bővítését vagy – az alapkutatást, alkalmazott kutatást vagy kísérleti fejlesztést szolgáló beruházást kivéve – az előállított termék, a nyújtott szolgáltatás, illetve a termelési, szolgáltatási folyamat alapvető változását eredményezi.” 58 Amennyiben elterjedne a FLOS szoftverek „kísérleti fejlesztés”-kénti értelmezése, az segítené a FLOS szoftverek elterjedését. 6.24 Az általános forgalmi adóval kapcsolatos rendelkezések A törvény hatálya Az általános forgalmi adóról szóló 2007. évi CXXVII törvény (a továbbiakban: Áfa tv) hatályára vonatkozó rendelkezései59 a különféle fogalommagyarázatokkal kiegészítve rendkívül összetettek Jelen esetben csak szűk értelemben a szoftverekkel kapcsolatos rendelkezések kerülnek bemutatásra. Általános forgalmi adót kell fizetni: „a) adóalany által

– ilyen minőségében – belföldön és ellenérték fejében teljesített termékértékesítése, szolgáltatásnyújtása után” Amennyiben a szerzői jogi szabályokat is segítségül hívjuk jelen pont értelmezéséhez, akkor kitűnik, hogy adóköteles ezen felül valamennyi ellenérték fejében történő felhasználás engedélyezése, valamint a vagyoni jogi jogosultság ellenérték fejében történő átengedése is.60 „b) terméknek az Európai Közösségen (a továbbiakban: Közösség) belüli egyes, belföldön és ellenérték fejében teljesített beszerzése után” Adóköteles továbbá a felhasználási jog a Közösségen belüli, ellenérték fejében történő megszerzése.60 „c) termék importja után.” 61 Adóköteles továbbá az az eset, mikor külföldi jogosult engedélyez felhasználást.60 58 Tao. 22/B § Áfa tv. 2–24 § 60 Az e helyen vázolt probléma levezetése jelen tanulmány kereteit meghaladja, amennyiben a terület és az

itt tárgyalt adójogi viszonyok felülvizsgálatára sor kerül, e pont vonatkozásában részletesebb kutatás lefolytatása válik indokolttá. 61 Áfa tv. 2 § 59 2009. június 15 89 Gazdasági tevékenység Az Áfa törvény értelmében: „Gazdasági tevékenység : valamely tevékenység üzletszerű, illetőleg tartós vagy rendszeres jelleggel történő folytatása, amennyiben az ellenérték elérésére irányul, vagy azt eredményezi, és annak végzése független formában történik.” 62 Feltételek tehát: – üzletszerű, illetőleg tartós vagy rendszeres jelleg Az üzletszerűség fogalmát a Büntető törvénykönyv63 alapjai szerint a következők szerint határozhatjuk meg: üzletszerűen jár el az, aki ugyanolyan vagy hasonló jellegű cselekmény révén rendszeres haszonszerzésre törekszik. Ez azt jelenti, hogy a haszonszerzési célra törekvés, annak tartós vagy rendszeres jelenléte közül az egyik fennállása elegendő ahhoz, hogy a többi

szempont megvalósulása esetében a tevékenység áfakörbe tartozónak minősüljön.64 – cél vagy eredmény: ellenérték elérése FLOS szoftverek esetében rendkívül komoly jelentősége van ennek a kitételnek, hiszen a licencek jelentős részében a felhasználási jogok átengedése nem közvetlen ellenérték biztosítása fejében történik. Tehát e kitétel szerint sem célként, sem eredményként nem jelenhet meg közvetlenül ellenérték. A szoftver közvetett haszna azonban igen jelentős lehet. Kérdés, hogy elegendő-e például egy GPL alapú szoftver továbbfejlesztési költségeiben jelentkező ÁFA tartalom levonására, hogy a fejlesztést megrendelő célja, hogy közvetetten kapjon ellenértéket a felhasználásért? Tisztázandó lenne az a kérdés, hogy miért van különbség a között, hogy egy zárt forráskódú szoftver fejlesztése történik, amely azonban a szoftver tényleges használatbavételekor már nem piacképes és így a piaci

bevezetésére nem is kerül sor, és a között, hogy FLOS szoftvert fejlesztenek, majd tesznek közzé? A fejlesztés költsége (x fejlesztői munkaóra) 62 Áfa tv. 6 §, (1) bekezdés 1978. évi IV törvény a Büntető Törvénykönyvről, 137 §9 pont 64 Annak vizsgálata, hogy e törvényhely alkalmazás során (az adóhatóság gyakorlatában) előfordul-e – az „illetőleg” kifejezés folytán az üzletszerűség valamint a tartós vagy rendszeres jelleg – fent meghatározott értelmezésétől eltérő értelmezés, meghaladja jelen tanulmány kereteit. 63 2009. június 15 90 és az elért közvetlen bevétel (0 forint) azonos. Más kérdés, hogy közvetett bevétel (egyrészt telepítési, támogatási díjakból, másrészt reklámértékből) az utóbbi esetben még realizálódhat – függetlenség Nem tartozik tehát e körbe az a tevékenység, amelyet munkaviszony, munkaviszony jellegű jogviszony, vagy olyan munkavégzésre irányuló egyéb jogviszony

keretében végeznek, amelyben a jogosult irányítása és felelőssége mellett a kötelezett alárendelt helyzetben van a tevékenység végzése eredményének, díjazásának, valamint egyéb feltételeinek és körülményeinek meghatározásában.65 Érdekes kérdést vet fel, hogy azon fejlesztések esetében, mikor a megrendelő teljes irányítása keretében készül az adott szoftver66 , alkalmazhatóak-e az ÁFA tv. szabályai67 A fogalom megértéséhez nyújtott törvényi magyarázat alapján: „Gazdasági tevékenység körébe tartozik különösen a termelésre, forgalmazásra irányuló ipari, mezőgazdasági és kereskedelmi tevékenység, valamint az egyéb szolgáltatói tevékenység, ideértve a szellemi szabadfoglalkozásként folytatott tevékenységeket is.” 68 Ez alapján gazdasági tevékenység a fejlesztő által végzett fejlesztői munka, ha ezt nem munkaviszony keretében valósítja meg. „Gazdasági tevékenység az is, ha az adóalany az

egyébként a vállalkozásának részét képező, illetőleg a vállalkozása folytatásának eredményeként keletkező vagyont (vagyonrészt) és vagyoni értékű jogot ellenérték fejében hasznosítja.” 69 Gazdasági tevékenységnek minősül továbbá a cég mindazon szoftverének hasznosítása, amelyekre vonatkozóan vagyoni jogokat szerzett (akár munkaviszony, akár szerződés alapján). Tehát a tevékenység lényege, hogy a vagyoni jogok birtokában felhasználási engedélyek kiadására jogosult A törvény szövege itt ismételten pontatlan, hiszen a megjelölt „vagyoni értékű jog” ellenérték fejében történő hasznosítása csak azt az esetet vizsgálja, mikor a felhasználó az adott szoftverre vonatkozóan jogosult további felhasználási engedélyeket (allicenceket) kiadni harmadik személyek részére. A vállalkozás eredményeként keletkező vagyon része lehet esetleg a fentebb említett vagyoni jogi jogosultság. 65 ÁFA tv. 6 §, (5)

bekezdés Szjt. 6 §, (1) bekezdés 67 Az e helyen vázolt probléma levezetése jelen tanulmány kereteit meghaladja, amennyiben a terület és az itt tárgyalt adójogi viszonyok felülvizsgálatára sor kerül, e pont vonatkozásában részletesebb kutatás lefolytatása válik indokolttá. 68 Áfa tv. 6 §, (2) bekezdés 69 ÁFA tv. 6 § 66 2009. június 15 91 A szolgáltatás fogalma „(1)Szolgáltatás nyújtása : bármely olyan ügylet, amely e törvény értelmében nem termék értékesítése. (2) Az (1) bekezdésben említett ügylet magában foglalja az alábbiakat is: a) vagyoni értékű jogok időleges vagy végleges átengedését; b) kötelezettségvállalást valamely tevékenység egészbeni vagy részbeni abbahagyására, vagy annak végzésétől való tartózkodásra, illetőleg valamely helyzet tűrésére. (3) Nem minősül szolgáltatás nyújtásának az ellenérték megtérítése, ha az pénzzel, készpénz-helyettesítő fizetési eszközzel vagy

pénzhelyettesítő eszközzel történik. (4) Nem minősül szolgáltatás nyújtásának az sem, ha a termék értékesítője, szolgáltatás nyújtója a teljesítésével keletkezett, pénzbeni követeléseként fennálló ellenértéket harmadik félre engedményezi, feltéve, hogy a harmadik fél a követelés megvásárlásával nyújt szolgáltatást az engedményezőnek.” 70 Az e paragrafusban megjelölt és „szolgáltatásnyújtássá” minősített „vagyoni értékű jogok időleges vagy végleges átengedése” feltételezhetően a felhasználási jogok – fentebb elemzett – időleges vagy végleges átengedését jelentheti. Figyelemmel arra, hogy a „vagyoni értékű jog”-ot az Áfa tv. nem definiálja, az adózás rendjéről szóló 2003 évi XCII törvényben – mint az adójogi szabályok háttérjogszabályában – kereshetünk választ, azonban ilyen fogalom magyarázatát itt sem találhatjuk meg, a vagyoni értékű jog ugyanis részben

magyarázat nélkül, részben valamely ingatlanhoz kapcsolódó jogosultságként jelenik meg (például 21. §, (2) bekezdés b, pont) Célszerű lenne tehát e kérdés szabályozását is jogszabályban rögzíteni, hogy az esetleges analógiák alkalmazásai ne vezessék félre az állampolgárokat. E rendelkezések tisztázása valamennyi szoftver vonatkozásában szükséges, függetlenül attól, hogy mely licencelési forma keretében kerülnek közzétételre. A termékértékesítés fogalma Ahogy azt már említettük, az Áfa tv. egyáltalán nem rendezi azt a helyzetet, mikor a vagyoni jogok kerülnek átruházásra, és nem pedig időleges vagy időben korlátlan felhasználási engedélyek nyújtására kerül sor. Mivel a számviteli törvény e helyzetet a tulajdonátruházással tekintette analógnak, abból kell kiindulnunk, hogy a közteher szabályok megalkotása körében a jogalkotó – mivel az egyes jogviszonyok alapjául szolgáló törvények figyelmen

kívül hagyásával, egy általános analógia használata mellett 70 Áfa tv. 13 § 2009. június 15 92 dolgozott – jelen esetben a „quasi tulajdonoskénti” (a szerzői jogi értelemben vett legteljesebb) rendelkezési lehetőség esetén a termékértékesítési szabályok kerülhetnek alkalmazásra. Ez a megoldás azonban csak átmeneti mankót jelenthet, hiszen a helyzet tisztázása az informatikai fejlődés ütemének ismeretében elkerülhetetlen és halaszthatatlan. Az ellenérték nyújtása nélküli ügyletek Nem tartoznak az Áfa tv. hatálya alá azok az ügyletek, amelyekben valamely termékértékesítésre71 vagy szolgáltatás nyújtására ellenérték szolgáltatása nélkül kerül sor Az ilyen „ingyenes” ügyletek általában a polgári törvénykönyv ajándékozási szabályai szerint minősülnek. Kivételek Az Áfa tv. azonban több kivételt is feltüntet, amely körében valamely ingyenes ügyletet mégis, mint ellenérték fejében

teljesítettet kell értelmezni. „Ellenérték fejében teljesített termékértékesítés [2. §, a) pontja] az is, ha az adóalany a terméket vállalkozásából véglegesen kivonva, azt saját vagy alkalmazottai magánszükségletének kielégítésére vagy általában, vállalkozásától idegen célok elérésére ingyenesen felhasználja, illetőleg azt más tulajdonába ingyenesen átengedi, feltéve, hogy a termék vagy annak alkotórészeinek szerzéséhez kapcsolódóan az adóalanyt egészben vagy részben adólevonási jog illette meg.” 72 Szoftver esetében, ha egy – az adóhatóság által gyakorlatban megjelenő – analógiával elfogadjuk egy-egy műpéldány esetében a „termék” megjelölést, felmerül annak kérdése, hogy mi módon lehet a szoftvert a vállalkozásból véglegesen kivonni? Elég-e, ha a szoftver futtatható változatát törlik? Mi a helyzet azokkal a biztonsági másolatokkal, amelyek egy-egy régebbi mentés részeként

fellelhetőek? Álláspontunk szerint a törvény jelen rendelkezései alapján még analógia által is a „termék” megjelölés csak a szoftverhez tartozó vagyoni jogok összességére vonatkozhat. „Szintén ellenérték fejében teljesített termékértékesítés: a) az adóalany vállalkozásán belül végzett saját beruházása, ha ennek eredményeként tárgyi eszközt állít elő; b) az adóalany 71 Bár fogalomzavarhoz vezethet az „értékesítés” megjelölés ingyenes juttatás esetén, a törvény szövegét követve ezt a kifejezést alkalmazzuk. 72 Áfa tv. 11 §, (1) bekezdés 2009. június 15 93 ba) vállalkozásában kitermelt, előállított, összeállított, átalakított, megmunkált, illetőleg bb) vállalkozásához vásárolt vagy importált termék felhasználása gazdasági tevékenységének folytatásához, feltéve, hogy ha a terméket ilyen állapotában másik adóalanytól szerezte volna be, adólevonási jog nem illetné meg ; c)

tárgyi eszköznek nem minősülő termék felhasználása adólevonásra nem jogosító tevékenység folytatásához, feltéve, hogy a termék beszerzéséhez vagy b) pont szerinti felhasználásához kapcsolódóan az adóalanyt egészben vagy részben adólevonási jog illette meg; d) az adóalany megszűnése, ha az adóalany a megszűnés időpontjában olyan terméket tart tulajdonában, amelynek beszerzéséhez vagy b) pont szerinti felhasználásához kapcsolódóan egészben vagy részben adólevonási jog illette meg.” 73 Megmaradva a fent említett értelmezés (vagyoni jogi jogosultság = termék) mellett, a törvény szellemében ellenérték fejében teljesített termékértékesítésnek minősül az eljárása, – ha egy társaság saját munkavállalói révén szoftvert fejlesztet – az Áfa tv. 11 §, (2) bekezdés a, pontja, – vagy szerződéses jogviszonyban megszerzi a szoftverhez kapcsolódó vagyoni jogokat – az Áfa tv. 9 §, (1) bekezdése A

levezetés szépséghibája az a már többször említett probléma, hogy szoftver esetén nem keletkezik „birtokba vehető dolog”. Mindaddig, amíg ez a kérdéskör az adójogi szabályozásban nem kerül – a szerzői jogi törvénnyel összeegyeztethetően – rendezésre, a jogalkalmazó csak félmegoldásokban gondolkodhat. A jogszabályhelyhez kapcsolódó kommentárban ezt olvashatjuk: „Az áfa jellegénél fogva a végső fogyasztás során realizálódik költségvetési bevételként. A felsorolt esetekben, bár a beszerzés eredetileg az adóalany gazdasági tevékenység folytatása céljából történt (ezért volt az adó levonható), az végső soron mégsem azt a célt szolgálta, vagy olyan gazdasági tevékenységet szolgál, mely nem keletkeztet adófizetési kötelezettséget, így levonható adó sem kapcsolódhat hozzá. Tehát itt az adóalany kvázi végső fogyasztóként jelenik meg. A törvény ismertetett rendelkezéseinek a célja, hogy

korrigálja az áfát, de nem az által, hogy a levonási jogot tagadja meg visszamenőleg, hanem azáltal, hogy előírja az adófizetési kötelezettséget.” Az általános forgalmi adó rendelkezések alapja tehát az, hogy a végső soron fogyasztónak minősülő személy (vagy szervezet) fizesse meg az adóterhet. 73 Áfa tv. 11 §, (2) bekezdés 2009. június 15 94 „Nem minősül ellenérték fejében teljesített termékértékesítésnek, ha az adóalany – vállalkozásának céljára tekintettel – más tulajdonába ingyenesen enged át árumintát és kis értékű terméket.” 74 FLOS szoftverek esetében nyilván valamennyi – az ingyenes juttatásra utaló – rendelkezést figyelembe kell venni. Ez a rendelkezés a FLOS szoftverek kezelésére alkalmas lehetne, azonban annak megítélése, hogy mennyi egy adott szoftver értéke, amelyre vonatkozóan a vállalkozás céljára (szoftvertámogatás, egyedi igényekhez igazítás) tekintettel más részére

ingyenesen felhasználási jogot enged, ismételten kérdéses. Befolyásolja-e a szoftver értékét, hogy az adott – a fejlesztés alapjául szolgáló – kódhoz a vállalkozás szintén anyagi ráfordítások nélkül jutott hozzá? A szoftver értéke mindig egyedileg, a ráfordított idő, illetve a piaci konkurens értékének figyelembevételével kerülhet megállapításra. Felmerül ugyanakkor az a kérdés is, hogy ha egy-egy felhasználó kap engedélyt, vajon a felhasználási engedélyek értéke mennyit tesz ki? Milyen értékbeli jelentősége lehet annak, hogy a felhasználó elsőként jut hozzá egy szoftver használati jogához?75 A jogi elemzés alapján feltétlenül meg kell különbözteti az eredeti fejlesztéseket az átdolgozásoktól76 , hiszen az első esetben kizárólag az adott jogosulthoz kapcsolható a fejlesztés és az erre vonatkozó jogok, a második esetben viszont egy több szerzős modellben kell gondolkodnunk. „Ellenérték fejében

teljesített szolgáltatásnyújtás [2. §, a) pontja] az is, ha az adóalany a terméket vállalkozásából időlegesen kivonva, azt saját vagy alkalmazottai magánszükségletének kielégítésére vagy általában, vállalkozásától idegen célok elérésére ingyenesen használja, illetőleg azt másnak ingyenesen használatba adja, feltéve, hogy a termék vagy annak alkotórészeinek szerzéséhez kapcsolódóan az adóalanyt egészben vagy részben adólevonási jog illette meg. Szintén ellenérték fejében teljesített szolgáltatásnyújtás, ha az adóalany saját vagy alkalmazottai magánszükségletének kielégítésére vagy általában, vállalkozásától idegen célok elérésére másnak ingyenesen nyújt szolgáltatást, feltéve, hogy a szolgáltatás igénybevételéhez kapcsolódóan az adóalanyt egészben vagy részben adólevonási jog illette meg.” 77 E szövegrész értelmezésében sarkalatos kérdést jelent, hogy a „vállalkozástól idegen

célok elérése” miként minősül, hiszen a FLOS szoftverek jelentős 74 Áfa tv. 11 §, (3) bekezdés A használati jog elsőbbségéről azaz a nyilvánosságra hozatal módjáról és menetéről lásd a 20. oldalt 76 Lásd a 26. oldalt 77 Áfa tv. 14 § 75 2009. június 15 95 részénél a fejlesztés közzététele és az arra vonatkozó felhasználási engedély jogosítása – a licenc rendelkezéseit követve – ingyenesen történik. Mindaddig, amíg központi „iránymutatás” keretében nem kerül rögzítésre, hogy a FLOS szoftverek fejlesztése nem nemzetgazdaságilag káros cselekmény, sőt, a cég érdekeit szolgálhatja, hogy FLOS szoftverek fejlesztésére áldozzon és ezt követően ezek üzembehelyezéséből, supportjából bevételt szerezzen, addig az eljáró hatóságok78 ilyen és ehhez hasonló döntéseket hoznak, lényegesen megnehezítve a FLOS szoftvereket fejlesztő cégek helyzetét. „A . Kft a szabad szoftver folyamatos

használatát rendelte meg az adózótól, amelynek értékében a szoftver az adózónál elszámolt beszerzési ára nem térült meg, mert annak használatát az adózó – a hivatkozott licenc előírásainak megfelelően – ingyenesen biztosította [. ] Eljárásával megsértette az általános forgalmi adóról szóló 1992. évi LXXIV törvény (a továbbiakban: Áfa tv.): 33 §, (1) bekezdés b, pontját, miszerint nem vonható le előzetesen felszámított adó, ha az adóalany a terméket és a szolgáltatást teljes egészében az adóalanyiságot nem eredményező gazdasági tevékenységi körön kívüli célra használja fel, hasznosítja, ide nem értve azt az esetet, ha a terméket és a szolgáltatást a 7. §, (3) bekezdésében vagy a 9 §-ban meghatározott célok elérése érdekében használja fel, hasznosítja.” Ez a határozat egy másik hasonlattal élve azt mondja, hogy például egy „rock kocsma” nem vonhat le előzetesen felszámított adót sem

a megvásárolt cd lemezek, sem az ARTISJUS felé befizetett jogdíj (amelyet a zeneszoltáltatás kapcsán köteles befizetni), sem a meghívott rockbanda fellépési díja után, mert a rockzene szolgáltatása a gazdasági tevékenység körén (vendéglátás) kívül eső tevékenység. Az, hogy a vendégek azért ezt a kocsmát választják, mert itt jófajta rock zene szól, ezek szerint nem vehető figyelembe. „Ha egy cég a szabad szoftveres közösségre támaszkodva kezd szoftveres fejlesztést, és a közösség tagjai a fejlesztésért pénzbeli vagy más juttatásbeli ellentételezést nem kapnak, az ügylet az áfatörvény alkalmazási hatályán kívüli. [. ] Azon ügyletek nem tartoznak az áfatörvény hatálya alá, melyek keretében szoftverek továbbfejlesztése, bővítése, módosítása történik, és a szoftver tulajdonosa és a továbbfejlesztő között nem történik ellenértékes ügylet, és a szoftver tulajdonosa a szoftver elkészítésével

kapcsolatosan az áfatörvény szerint nem vonhatott le adót. Amennyiben történik ellenérték megfizetése akár a fejlesztés előtt, akár utána, az ingyenesség okán az ügylet már nincs az 78 Észak-magyarországi Regionális Igazgatóság 2009. június 15 96 áfatörvény hatályán kívül. Ez esetben áfa szempontból az ügylet pontos ismeretében dönthető el annak adójogi megítélése” 79 E helyen is összemosódik a fejlesztés fogalma a jogosítással. Az, hogy valaki „fejleszt”, még nem jelenti azt, hogy az adott fejlesztéssel kapcsolatosan a jogokat is át fogja ruházni. Fejlesztések esetében a teljes vagyoni jogi jogosultság megszerzése mérhető a fejlesztésért kifizetett díjban A fejlesztés megrendelője jogosultságot szerez arra, hogy a szoftver nyilvánosságra hozataláról döntsön. A szoftver feletti rendelkezési jog piaci előnyt jelent 6.25 A FLOS szoftverek közteher szabályokban való megjelenésére tett javaslatok

Általánosságban Ahogy arra korábban már kitértünk, a közteher jogszabályok és a szerzői jogi törvény harmonizálása nélkül a szoftverfejlesztések, szoftverekhez kapcsolódó jogosultságok tisztázása nem lehetséges. A módosításokat átfogóan kell kezelni. A FLOS szoftverek helye, megjelölése Amennyiben a kormányzat támogatni kívánja a FLOS szoftverek fejlesztését, minimális szinten arról kell gondoskodnia, hogy a FLOS szoftvert fejlesztők ne kerüljenek a közjó szolgálata végett hátrányos helyzetbe. Mindaddig, amíg FLOS szoftverek fejlesztését megrendelni, az ezzel kapcsolatosan kifizetett áfát vagy egyéb költséget leírni nem lehet, a fejlesztések hátrányos megkülönböztetésben részesülnek. Tény, hogy a FLOS szoftverek fejlesztési modellje nem tükrözi a korábban elterjedt – szigorú titoktartásra épülő – modelleket, de a FLOS szoftverek fejlesztése és támogatása pontosan annyira szolgálhatja egy cég érdekeit,

mint amennyire egy saját szoftver kereskedelmi forgalombahozatala. A FLOS szoftverek ugyanis hozzásegítik a céget a széleskörű ismertséghez. Ha speciális szaktudással párosul a fejlesztési ismeret, akkor a FLOS szoftverek segítségével elért célközönség pontosan az lesz, akit egyébként marketing keretében próbálhatna elérni. Célszerű lenne a társasági adó szabályaihoz hasonlóan kutatás, fejlesztés keretében értelmezni, és ezzel kapcsolatos adókedvezményekben része79 APEH állásfoglalás 2278801012/2009, Tárgy: szoftverekhez kapcsolódó adójogi kérdések 2009. június 15 97 síteni azokat, akik fejlesztéseikkel egyaránt szolgálják saját érdekeiket és „felebarátaik javát”.80 80 Lásd Stallman filozófiáját : http://www.gnuorg/philosophy/free−swhuhtml 2009. június 15 98 2009. június 15 7. fejezet Felmérési eredmények 7.1 Válaszadók A Miniszterelnöki Hivatal által kijelölt alábbi intézmények: –

Országos Egészségbiztosítási Pénztár – Bevándorlási és Állampolgársági Hivatal – Nemzeti Hírközlési Hatóság – Központi Statisztikai Hivatal – Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatala – Központi Szolgáltatási Főigazgatóság – Nemzeti Fejlesztési Ügynökség – Magyar Államkincstár – Vám- és Pénzügyőrség Országos Parancsnoksága – Foglalkoztatási és Szociális Hivatal – Országos Munkavédelmi és Munkaügyi Főfelügyelőség – Országos Nyugdíjbiztosítási Főigazgatóság1 valamint: – Szeged Város Önkormányzata 1 A PSZÁF kijelölt kapcsolattartója az interjú elől elzárkózott. 99 100 – Országos Kardiológiai Intézet vettek részt a kutatásban. Utóbbi két intézmény kiválasztásánál fontos szerepet játszott, hogy valóban FLOS programokat használnak működésük során, így tényleges tapasztalattal rendelkeznek e téren. 7.2 A felmérés célja A felmérés

célja az volt, hogy a FLOS szoftverek elterjedésének előmozdítása érdekében a közigazgatáson belül – a szoftverhasználattal kapcsolatos szokásokat, – a FLOS szoftverek • ismertségét, használatát, • a használat lehetőségét, – az átállásokkal kapcsolatos • tapasztalatokat, illetve • várható problémákat felmérje. A kutatás keretében a G. mellékletben csatolt – vonalvezető – kérdőív alapján lefolytatott strukturális mélyinterjúk az alábbi megállapításokhoz vezettek.2 7.3 Szoftverhasználati szokások 7.31 Felhasználási díjtól (licencdíjtól) mentes szoftverek ismerete A válaszadók tisztában voltak azzal, hogy bizonyos esetekben egy szoftver használatakor nem kell jogdíjat (licencdíjat) fizetni (lásd 7.1 ábra) Példának hozták fel a Linux disztribúciókat, pdf olvasókat. Ugyanakkor nagy részüknek komoly problémát jelentett a freeware, FLOS szoftver elhatárolás. Többen azokra a szoftverekre,

amelyeknél nem ők (az általuk képviselt intézmény) fizették meg a jogdíjat (hanem mondjuk az állam) is úgy tekintettek, mintha „ingyen lenne”. Volt azonban olyan válaszadó is, 2 Az elemzés a kérdőív rendszerét követi. 2009. június 15 101 aki több példát fel tudott sorolni azokra az esetekre, amikor a szoftver használata a jogdíjfizetéstől bizonyos feltételek mellett mentes lehet. 7.1 ábra Tisztában van-e azzal, hogy bizonyos szoftverek esetén nem kell jogdíjat fizetni? 7.32 Felhasználási díjtól (licencdíjtól) mentes szoftverek használata A kérdés célja az volt, hogy felmérje, vajon mennyire vannak tisztában a válaszadók azzal, hogy esetlegesen az általuk irányított rendszerben is szerepelnek jogdíj megfizetésétől mentes szoftverek. A válaszok ebben az esetben árnyaltabbak voltak 78,57% használta mind munkahelyen mind otthoni körülmények között, az alábbi értékek mellett: 85,71% csak otthon, 85,71% csak

munkahelyen, 7,14% nem használ sehol (7.2 ábra) Érdekes, hogy a „nem használok” választ adók egyike tartózkodását a vírusoktól való félelmével indokolta, egy esetben pedig a közintézmény a válaszadó tudtával is használt FLOS szoftveres alkalmazásokat, csak maga a megkérdezett személy ebben nem vett részt. 2009. június 15 102 7.2 ábra Használ-e licencdíjtól mentes szoftvereket, és ha igen, hol? A felmérésből kitűnt továbbá az is, hogy a műszaki végzettséggel rendelkező válaszadók valamennyien otthon és munkahelyi környezetben is használtak FLOS szoftvereket. 7.33 Az Internet Explorertől különböző böngésző ismerete, használata Az alternatív böngészők közül Mozilla Firefox ismerete volt a legkiemelkedőbb (92,86%). A használattal kapcsolatos számok is tükrözik azt a nyilvános statisztikát3 , amely szerint a Firefox elterjedése az Explorerrel egyenértékű. Az Opera főként mobil eszközökön (telefon)

történő felhasználás kapcsán került bejelölésre. Több intézményben az Internet Explorer és a Firefox használata együtt kötelező, ugyanis az általuk használt weblap tartalmak nem böngészőfüggetlenek. Az ismertségi, illetve felhasználási arányokat a 7.3 és a 74 ábrák szemléltetik Az ábrákból kitűnik, hogy a Netscape-et egyetlen megkérdezett sem használta, illetve az, hogy a megkérdezettek 6–7%-a nem is próbált soha más 3 http://www.w3schoolscom/browsers/browsers statsasp 2009. június 15 103 böngészőt, mint az Internet Explorert. Az arányokból az is kitűnik, hogy a vállalkozó szelleműbbek viszont több böngészővel is próbálkoztak már. 7.3 ábra Az Internet Explorertől különböző böngésző ismerete 2009. június 15 104 7.4 ábra Az Internet Explorertől különböző böngésző használata 7.34 A Microsoft Windows termékcsaládján kívüli operációs rendszerek ismerete A felmérés azt mutatta, hogy a

műszaki végzettséggel rendelkező válaszadók ismerték és használták/használják valamelyik Linux disztribúciót. Természetesen az egyes intézmények eltérő feladatkörei más és más rendszerek használatát teszik szükségessé, így felmerült a kérdőíven eredetileg nem nevesített (és jelenleg már nem is üzemelő) BS2000 rendszer, valamint az SCO Unix és a VMS. A válaszadók 50,68%-nál az ismert és használt szoftverek köre egyezett. Átlagosan 49,32% több szoftvert ismertek a válaszadók, mint amennyit valójában próbáltak már. Az egyes rendszerekkel kapcsolatos ismeretek, illetve felhasználások mértéke a 7.5 és a 76 ábrákon látható Ebből kitűnik, hogy a Black Panther OS, illetve a Frugalware rendszerek ismeretlenek a közigazgatásban. Általánosságban elmondható, hogy az ismert szoftverek köre lényegesen meghaladja a tényleges használtakét, ami arra enged következtetni, hogy a válaszadók információikat nem teljesen valós,

tapasztalati alapon, hanem (azon szoftverek esetében, melyeket nem próbáltak) inkább feltételezések alapján adják. 2009. június 15 105 7.5 ábra A Microsoft Windows termékcsaládján kívüli operációs rendszerek ismerete 7.35 Szabad szoftvert használó ismerősök Ahogy a 7.7 ábrából is kitűnik, olyan válaszadó, aki senkit sem ismert, aki próbált – használt volna már szabad szoftvert, nem volt. Egy válaszadó jelezte, hogy az ismeretségi körében csak olyan személy található, aki a szabad szoftvert próbálta, de nem használja rendszeresen, megjegyezte továbbá, hogy ezzel az ismerősével egyébként erről nem szoktak beszélgetni. (Ez a válaszadó azonos azzal, aki a szabad szoftverek használatától a vírusoktól való félelmében tartózkodott). A további kérdések alapján kitűnt, hogy a rendszeresen FLOS szoftvert használó ismerősök köre az alábbi létszám és összetételi adatok szerint alakul: a minimum létszám tucat

volt, ezt követte a tízes nagyságrend, majd a „sokan” és a „rengetegen” kifejezésekkel utaltak az ismeretségi kör méretére. Azon válaszadók esetén, akik ismeretségi köre rendszeresen használ szabad szoftvert, az ismeretségi kör létszámára és összetételére adott válaszok alapján a minimum létszám tucat volt, ezt követte a tízes nagyságrend, a sokan és a rengetegen. Összetételüket tekintve: elsődlegesen a szakmai körök, barátok, rendszergazda ismerősök, majd a saját rokonság (például a gyerekei) merültek fel. 2009. június 15 106 7.6 ábra A Microsoft Windows termékcsaládján kívüli operációs rendszerek használata 7.7 ábra Szabad szoftvert használó ismerősök 2009. június 15 107 7.36 A számítógépen végzett leggyakoribb tevékenysége Valamennyi megkérdezett végez szövegszerkesztési tevékenységet, a megkérdezettek 92,86% ban kezelnek táblázatot, 28,57%-ban használnak fórumokat, 50%-ban

hírportálokat olvasnak, 85,71%-ban használják webböngészésre a számítógépet. Mivel a válaszadók többnyire magasabb beosztásban dolgoztak, az iktatórendszer használata csak 21,43%-ot érintett, míg könyvelőrendszerrel közvetlenül senki sem dolgozott. A levelezőrendszer használata szintén 92,86%-os, klasszikus játékra a válaszadói korosztály már nem használja a gépet, az instant messaging szolgáltatás korlátozottan népszerű (21,43%), ahogy az online telefonálás is visszaszorított értéket mutat (21,43%). A 78 ábrán látható a százalékos értékeket ábrázoló diagram 7.8 ábra A számítógépen végzett leggyakoribb tevékenysége Megjelent azonban egy elég magas felhasználási arányt mutató, a kérdőívben eredetileg nem rögzített tétel: a multimédia vezérlés (zene, dvd lejátszás) valamint a fényképszerkesztés, mint jellemző kiegészítő tevékenység. Felmerült még intézményközpontú tevékenységként a

programozás és a vállalatirányító rendszerek használata, magánéleti vonatkozásban pedig a térkép és csillagász szoftverek használata. 2009. június 15 108 7.37 Az egyes tevékenységekhez kapcsolódó célszoftverek megoszlása Szövegszerkesztő A közigazgatásban – a interoperabilitási kötelezettséggel magyarázva – a Microsoft Word a központi szövegszerkesztő alkalmazás. Érdekes volt tapasztalni, hogy míg egyes intézményekben megvalósult a váltás, addig más helyeken fel sem merült, vagy felmerült, de elenyészett a módosítási törekvés A felhasználók saját IT szabályzatukkal, „házirendjükkel” magyarázták a Microsoft Word hegemóniáját, illetve azzal, hogy a hivatalnak/intézményrendszernek biztosítania kell, hogy a hozzá forduló ügyfeleket technológiai alapon hátrány ne érje. (A válaszadók egy része nem tudta, hogy az OpenOffice képes doc kiterjesztésű, vagy más, mindkét szövegszerkesztő által olvasható

formátum előállítására.) Abban az esetben azonban, mikor a válaszadó nem csak „átlag felhasználóként” kezelte a rendszerét, az OpenOffice is feltelepítésre került, hiszen bizonyos megoldásokat (például gyors pdf konvertálás) azzal sokkal könnyebben tudott kivitelezni. 7.9 ábra A leggyakrabban használt szövegszerkesztők Felmerült a szövegszerkesztő-váltás lehetősége kapcsán egyes válaszadóknál, hogy központi iránymutatásra, utasításra várnak, mert tekintettel arra, hogy az Állam folyamatosan megújításra kerülő megállapodást kötött az iro2009. június 15 109 dai alkalmazások beszállítására, a felhasználási jogosultság külső szerv vagy szervezet (például BSA) általi ellenőrzésére nem kerül sor, így közvetlen motiváció a változtatásra nincsen. Önszántukból nem kívánják felvállalni azt a konfliktust, illetve azt a plusz terhet, ami egy új rendszer bevezetésével járna. Azt tapasztaltuk, hogy azon

válaszadók, ahol a költségvetés ténylegesen szűk, már vagy átálltak, vagy legalább megvizsgálták az átállás lehetősét. Volt olyan válaszadó, aki arról számolt be, hogy az átállás lehetősége (illetve már maga a felvetés) felső vezetői (privát) érdekek miatt hiúsult meg. A felmérés alapján kitűnt, hogy az intézmények ügyintézői átlagosan 90– 95%-ban minősülnek átlagos vagy átlag alatti felhasználónak (ez hozzávetőleg azt jelenti, hogy a szövegszerkesztés keretében a formázást szóköz és tabulátor használatával oldják meg, illetve a táblázatkezelésben műveletsorokat, függvényeket nem tudnak megadni.) Nehézséget jelent azonban, hogy bár az átállás az átlagos felhasználók esetében a tényleges felhasználást nem nehezítené meg (hiszen azokat a funkciókat, amelyben a rendszerek eltérnek, ők nem használják) a kiemelt felhasználók esetében, és a bonyolultabb területeken létrehozott egyéb alkalmazás

szoftverek futtatása miatt a szoftverváltást rendkívül alapos előkészítés mellett, csak évek alatt (egy ideig párhuzamos működéssel) lehet megvalósítani. Táblázatkezelő A táblázatkezelésben is visszaköszönnek a szövegszerkesztésből ismert adatok (7.10 ábra) A FLOS szoftverek a közigazgatási környezetben csak kisegítő szerepet (35,71%) játszanak. (Más vizsgált területen, így a Szegedi Önkormányzatnál, elsődlegesnek tekinthető az OpenOffice csomag használata.) Webböngésző Az alkalmazások közül a webböngészők területén jelenik meg leggyakrabban a FLOSS alternatíva (7.11 ábra) Amellett, hogy a gépek 78,57%-án Internet Explorer fut, a megkérdezettek 42,86% válaszolta azt, hogy emellett Mozilla Firefoxot is telepített. Vannak kifejezetten Mozillára optimalizált oldalak is a közigazgatásban, így például a Szabadalmi Hivatal iparjogvédelmi adatbázisa, a PIPACS. Iktatórendszer Az egyik legjelentősebb eltérés az

iktatórendszerek körében tapasztalható. Indulva onnan, hogy a szervezet nem használ elektronikus iktatórendszert, a licencelt szoftvereken keresztül (Secreter, Lotus Notes), a megrendelésre 2009. június 15 110 7.10 ábra A leggyakrabban használt táblázatkezelők 7.11 ábra A leggyakrabban használt böngészők fejlesztetten át, egészen a saját fejlesztésig (IRKA), valamint a kormányzat által támogatott megoldásig (például KIR). 2009. június 15 111 Az egyéni fejlesztésű szoftvereket használó szervezetek álláspontja szerint a végzett feladatok rendkívül széles köre nem teszi lehetővé, hogy ismert piaci modellekből válasszanak. Az egyéni megrendelések esetén azonban csak nagyon ritkán szereztek jogot a forráskód szabad felhasználására. A beszélgetések során kitűnt, hogy a közbeszerzés szabályainak betartása mellett arra már csak kivételesen ritka esetben fordítanak figyelmet, hogy a szoftverek jogi háttere (például

az aktuális szerződési időtartamon túlmutató felhasználás lehetősége) is rendezett legyen. Könyvelőrendszer A könyvelőrendszerek területe egységesebb, a FORRÁS SQL és a FOKUSZ több intézményben is megjelenik, van ezen kívül SAP, Mondoc, Ecostat, illetve ismét pár egyedi fejlesztés. Az egyedi fejlesztések kapcsán jelenhet meg továbbá nehézségként az adatállomány tárolása. A vizsgált hatóságokhoz, hivatalokhoz hasonló méretű szervezet esetében rendkívüli nehézséget jelenthet a teljes könyvelést kezelő szoftver cseréje. Hiszen egy-egy esetleges adatvesztésnek rendkívül súlyos következményei lehetnek Mivel a gyártók/fejlesztők abban érdekeltek, hogy magukhoz láncolják a megrendelőt, amennyiben a rendszerleírásokban nem szerepel pontosan, hogy milyen ismert állományokban kell az adatoknak rendelkezésre állniuk, megtörténhet, hogy egy-egy titkosítással vagy egyedi adatformátummal láncolja magához a

gyártó/fejlesztő a szervezetet, hiszen egy másik rendszer bevezetése ezáltal a fenntartási díj sokszorosát jelentheti. Azon a helyen, ahol SAP rendszert használtak, az OpenOffice bevezetési tesztjeinél komoly problémák adódtak abból, hogy a táblázatkezelő másként működött, mint az Excel. Levelezőrendszer A levelezőrendszerek 50%-ot meghaladóan Microsoft alapokon működnek. Érdekes, hogy nem minden Outlook levelezőprogram mögött áll azonban háttérszerverként Microsoft Exchange. 21,43%-ban Lotus Notes, 7,14% Novell Groupwise (712 ábra) A többi „irodai” levelezőcsomag emellett elenyésző További fontos tanulság, hogy a közigazgatási intézmények alkalmazottai vagy nem folytatnak privát levelezést, vagy nagyobb részben a hivatalos email címükről folytatják ezt (hiszen a webes levelezést megjelölők száma 20% körüli), amely azonban hosszabb távon adatkezelési problémákat vethet fel. 2009. június 15 112 7.12 ábra A

leggyakrabban használt levelezőrendszerek Egyéb Az egyik szervezetben valamennyi gépre telepítettek KMplayert, amely freeware, és amely esetén a kereskedelmi célú felhasználás lehetőségét egyébként a licenc kizárja4 . A licenchez fűződő kommentárok alapján a céges környezetben privát célú felhasználás továbbra is ingyenes 7.38 A FLOS szoftverek és a Microsoft vagy más kereskedelmi gyártó szoftvereinek jellemzése A kérdőív ezen részénél nehézséget jelentett, hogy rendkívül széles szoftverpalettát kellett összehasonlítani. Természetesen FLOS szoftverek és kereskedelmi szoftverek között is vannak olyan elemek, amelyek rendkívüli mértékben „kilógnak” a sorból Nehezítette továbbá a válaszadást, hogy nem minden válaszadónak volt tapasztalata mindkét szoftvercsoportra vonatkozóan, így feltételezéseik szerint értékelték az adott tulajdonságot. A kimutatások ezért két grafikonon készültek. Az elsők mutatják

a válaszok és válaszadók százalékos eloszlását A második ábrák az adott vála4 http://www.kmplayercom/forums/showthreadphp?t=9118&highlight= =license 2009. június 15 113 szok értékének átlagát FLOS szoftverek és Microsoft (vagy más kereskedelmi) szoftverek vonatkozásában. Gyorsaság A gyorsaságra vonatkozó kérdést a válaszadók főleg a Windows operációs rendszerrel kapcsolatos tapasztalataik alapján válaszoltál meg. Így adódott, hogy egyetlen válaszoló sem gondolta azt, hogy a kereskedelmi szoftverek nagyon gyorsak lennének, míg a válaszadók 50%-a ítélte a FLOS szoftvereket annak (7.13 és 714 ábra) (Előfeltételként páran leszögezték, hogy a jellemzés előfeltétele, hogy a hardver-körülmények azonosak.) A 714 ábráról kitűnik, hogy összességében a FLOS szoftvereket lényegesen gyorsabbnak tartották a válaszadók. 7.13 ábra Milyen mértékben jellemzi a gyorsaság a szoftvereket? Biztonságosság A felmérés

rámutatott arra, hogy amennyiben a válaszadó informatikai képzettséggel rendelkezik, nincsenek a FLOS szoftverek vonatkozásában biztonsággal kapcsolatos aggályai (7.15 és 716 ábra) A kód megismerésének lehetőségét ebben az esetben, mint a biztonság zálogát tekintették, és a FLOS szoftvereket 57,14%-ban nagyon biztonságosnak minősítették. A felmérésekből az tűnt ki, hogy a kereskedelmi gyártók szoftvereiben – általában véve – 2009. június 15 114 7.14 ábra Milyen mértékben jellemzi a gyorsaság a szoftvereket? kevésbé bíznak, ugyanakkor többen is megemlítették, hogy a gyártói garancia és támogatás megléte miatt fontosabb rendszerek kezeléséhez ezekből választanak (például adatbáziskezelés esetén az Oracle megoldásokat). Volt olyan válaszadó, aki véleményét két – általa jól ismert – szoftver annyira megosztotta, hogy több minősítést is adott. Az alkalmazások könnyű kezelése A válaszadók 90%-ot

meghaladó mértékben tartják a kereskedelmi szoftvereket legalább közepes mértékben könnyen kezelhetőnek (7.17 és 718 ábra) A kérdés megválaszolásánál a válaszadókat részben saját szoftverfelhasználási szokásaik befolyásolták A nagyon könnyű kezelést a jól használható GUI felületek szerint értékelték, ahol az egyes programrészek, alkalmazások könnyen megtalálhatóak és futtathatóak, a közepesen könnyű kezelést jelentette a billentyűkombinációk ismerete és használata. A FLOS szoftverekkel kapcsolatos véleménynyilvánítást erősen befolyásolta, hogy valójában a válaszadók dolgoznak-e, dolgoztak-e valaha ilyen szoftverekkel, és rendelkeznek-e azzal a szakértelemmel, amely mellett például a korlátozottabb GUI funkciókkal ellátott szoftverek is jól irányíthatóak. A FLOS szoftverek nagyon könnyű kezelése mellett azok foglaltak állást, akik ténylegesen rendelkeztek ilyen tapasztalattal. 2009. június 15 115 7.15

ábra Milyen mértékben jellemzi a biztonságosság a szoftvereket? 7.16 ábra Milyen mértékben jellemzi a biztonságosság a szoftvereket? Felhasználóbarátság Felhasználóbarátságnál a felhasználói komfortérzet került értékelésre, ide értve az egyes operációs rendszerekhez tartozó alkalmazások körét. A FLOS 2009. június 15 116 7.17 ábra Milyen mértékben jellemzi a könnyű kezelhetőség a szoftvereket? 7.18 ábra Milyen mértékben jellemzi a könnyű kezelhetőség a szoftvereket? szoftverek esetében a felhasználóbarátság magas fokát megjelölők azzal magyarázták döntésüket, hogy ezeknél a szoftvereknél a telepítést végző eldönt2009. június 15 117 heti, és optimalizálhatja saját felhasználói igényeihez a rendszert. A kereskedelmi szoftvereket pártolók pedig azzal érveltek, hogy esetükben még valamennyi igényre volt megoldás A közepes minősítést adók szerint az alkalmazások túlzott száma miatt nem

annyira felhasználóbarát a kereskedelmi szoftver, míg a FLOSS a telepítésnél igényelt extra közreműködés miatt kapott 64,29%-ban közepes minősítést. Nem volt olyan válaszadó, aki kereskedelmi szoftver estében azt egyáltalán nem érezte volna felhasználóbarátnak, míg FLOSS esetén ez körülbelül 8% körüli értéket adott. Érdekes, hogy a felhasználóbarátság átlaga mindkét szoftvercsoport esetében azonos volt (7.19 és 720 ábra) 7.19 ábra Milyen mértékben jellemzi a felhasználóbarátság a szoftvereket? Időtállóság A válaszadást nehezítette ebben az esetben, hogy a kereskedelmi szoftverek esetében volt olyan rendszer, amelyet időtállónak (Microsoft XP), és olyan, amelyet bevezetésre is alkalmatlannak (Microsoft Vista) minősítettek a kérdezettek. FLOSS esetében a „nem időtálló” válaszok magyarázata az volt, hogy ezeknél a fejlesztéseknél a rendszer támogatása, egy-egy disztribúció léte erősen függ a

magánszemély fejlesztők kedvétől és lelkesedésétől. A közepes minősítést (40-50%) az indokolta, hogy az informatika és a hardver változásai szükségszerűen fejlesztési / módosítási / változtatási kö2009. június 15 118 7.20 ábra Milyen mértékben jellemzi a felhasználóbarátság a szoftvereket? vetkezményekkel járnak mindkét szoftvercsoport vonatkozásában (7.21 és 7.22 ábra) Nagyon (20%-ot meghaladó mértékben) időtállónak azok a válaszadók minősítették a FLOS szoftvereket, akik azt hangsúlyozták, hogy amennyiben egy fejlesztést valaki felad, azt megfelelő szakemberekkel át lehet venni, míg egy zárt kód esetében a cég megszűnésekor erre nincsen lehetőség. Hasonlóság más szoftverekkel A más szoftverekkel való hasonlóság megítélésénél szintén problémás volt a viszonyítási alapok megállapítása. Több válaszadó döntött aszerint, hogy az általa korábban használt rendszerhez hasonlította annak

újabb kiadásait. (Itt az XP és annak előzményei kerültek értékelésre) Azok, akik a Vista, XP viszonyáról nyilatkoztak (körülbelül 30%) a közepes hasonlóság mellett foglaltak állást. Érdekes, hogy az Office 2007 esetében többen (akik valamennyi rendszert ismerték) említették, hogy az Office 2003-ra az OpenOffice jobban hasonlít, mint az Office 2007. A hasonlóság magas fokát megállapítók (50-60% feletti részaránnyal) azzal is magyarázták döntésüket, hogy mivel a szoftverfejlesztők felmerülő igényeknek felelnek meg és az adott problémakörrel összefüggő igények egymásra hasonlítanak (szövegszerkesztés, kiemelés 2009. június 15 119 7.21 ábra Milyen mértékben jellemzi az időtállóság a szoftvereket? 7.22 ábra Milyen mértékben jellemzi az időtállóság a szoftvereket? lehetősége, kereszthivatkozás lehetősége), nyilvánvalóan a kivitelezési megoldások is hasonlóak (7.23 és 724 ábra) 2009. június 15 120

Többen megjegyezték e pontnál továbbá, hogy az igények hasonlósága arra is vezet, hogy a piac oligopol módon alakul, hiszen ha egy adott problémára már 2-3 jó megoldás létezik, újabb fejlesztésre az adott területen nem kerül sor. 7.23 ábra Milyen mértékben jellemzi a hasonlóság más szoftverekkel? Alapfeladatok ellátására alkalmas A FLOSS-t alkalmatlannak minősítő válaszadó egyáltalán nem próbált, és nem is látott még FLOS alapú operációs rendszert működés közben. A képzete szerint ezen szoftverek kizárólag parancssorból vezérelhető, rendkívül összetett és bonyolult rendszerek. A válaszadók 21,43%-a minősítette a kereskedelmi szoftvereket alapfeladat ellátására közepesen, 78,57% pedig kifejezetten alkalmasnak. Az eltérés az „alapfeladat” fogalmának definiálásán alapul. Egy válaszadó például a szövegszerkesztő alkalmazástól a beépített pdf konvertálást „elvárná” FLOSS esetén az OpenOffice

kapcsán merültek fel olyan szintű formázási, illetve változáskövetési (korrektúrára vonatkozó) kiemelt igények, amelyek a közepes minősítést 28,57%-ban indokolták, a többi válaszadónál az alapfeladatok ellátása megoldottnak minősült (7.25 és 726 ábra) 2009. június 15 121 7.24 ábra Milyen mértékben jellemzi a hasonlóság más szoftverekkel? 7.25 ábra Milyen mértékben alkalmasak az alapfeladatok ellátására a szoftverek? Bonyolult feladatok ellátására alkalmas Az, hogy a válaszadók a bonyolult feladatok elvégzésére a FLOS szoftvereket lényegesen alkalmasabbnak (71,43% szemben a 28,57%-kal) tartják 2009. június 15 122 7.26 ábra Milyen mértékben alkalmasak az alapfeladatok ellátására a szoftverek? két okra vezethető vissza: 1. személyes tapasztalat, 2 mivel ők maguk ilyen feladatokat nem végeznek, de az általuk ismert és bonyolult feladatokat elvégző személyek köre azonos az általuk ismert FLOS szoftvereket

használó személyek körével, ezekre ezt kivetítik. A kereskedelmi szoftvereket bonyolult feladatok ellátására nagyon alkalmasnak minősítők (28,57%) többnyire az Oracle adatbáziskezelő alkalmazásait említették (7.27 és 728 ábra) Beszerzés szempontjából olcsó A válaszadók szinte egyöntetűen nyilatkoztak úgy, hogy a FLOS szoftverek beszerzésére ingyenesen vagy nagyon olcsón kerülhet sor, míg a kereskedelmi szoftverek esetében ezt egyáltalán nem olcsónak (drágának) minősítették (7.29 és 730 ábra) Fenntartás szempontjából olcsó A fenntartási költséggel kapcsolatos kérdés megosztotta a válaszadókat, hiszen e rendszerek fenntartása, üzemeltetése vagy a rendszerhez értő munkavállaló, vagy külső szakértő igénybevételével történhet. Nyilvánvalóan a FLOSS esetében a javítások, upgrade-ek hozzáférhetőek, a saját üzemeltetés pedig olcsó (64,29%), a kereskedelmi szoftverek esetében azonban folya2009. június 15

123 7.27 ábra Milyen mértékben alkalmasak a bonyolult feladatok ellátására a szoftverek? 7.28 ábra Milyen mértékben alkalmasak a bonyolult feladatok ellátására a szoftverek? 2009. június 15 124 7.29 ábra Milyen mértékben olcsó a szoftverek beszerzése? 7.30 ábra Milyen mértékben olcsó a szoftverek beszerzése? matosan jelentkező upgrade, support és más fenntartási költségek miatt a szoftverek megítélése „nem olcsó”. 2009. június 15 125 Olyan válaszadó, aki a FLOS szoftverek fenntartását egyáltalán nem tartotta olcsónak, vagy csak kis mértékben, nem volt (7.31 és 732 ábra) 7.31 ábra Milyen mértékben olcsó a szoftverek fenntartása? Könnyen naprakésszé tehető Egy szoftver naprakész változatának megítélését a válaszadók az alapján ítélték meg, hogy az egyes (nem kizárólag biztonsági) hibák javítása milyen időtartam alatt történik, illetve a szoftver bizonyos külső körülmények (például

felhasználói igények) változásaira mennyire gyorsan reagál. 64,29% gondolta úgy, hogy a FLOSS kifejezetten alkalmas arra, hogy naprakésszé alakítsák, míg az egyes zárt kódú szoftverek esetében a fejlesztői-tesztelői monstrum szervezet miatt az átalakíthatóságot csak 35,71% ítélte jónak (733 és 7.34 ábra) Magyarnyelvűség A válaszadók több, mint 90%-a értékelte jól fordítottnak a kereskedelmi szoftvereket, míg 30% alatt maradt azok száma, akik FLOSS viszonylatban gondolták ugyanezt (7.35 és 736 ábra) Ez a kérdés egyértelműen rámutatott arra, hogy a „magyarításban” szükséges volna a központi támogatás, hiszen a magyar nem világnyelv, így a fordítást (szemben a fejlesztésekkel) „saját erőből” kell megoldani. 2009. június 15 126 7.32 ábra Milyen mértékben olcsó a szoftverek fenntartása? 7.33 ábra Milyen mértékben tehetők könnyen naprakésszé a szoftverek? A FLOS szoftverek esetén többen

megemlítették, hogy az OpenOffice v3. fordítása sokat segített abban, hogy a szoftvert legalább részlegesen bevezessék. 2009. június 15 127 7.34 ábra Milyen mértékben tehetők könnyen naprakésszé a szoftverek? 7.35 ábra Milyen mértékben magyar nyelvűek a szoftverek? Testreszabhatóság A válaszadók a FLOS szoftvereket találták a leginkább testreszabhatónak (7.37 és 738 ábra) A válaszokat természetesen befolyásolta, hogy a 2009. június 15 128 7.36 ábra Milyen mértékben magyar nyelvűek a szoftverek? válaszadónak voltak-e telepítési ismeretei az egyes szoftvertípusokra vonatkozóan. A testreszabhatóság mértékének megítélésekor a skálázásnál az alábbi szempontok voltak irányadóak: kicsit testreszabhatónak minősítették a szoftvert, amely esetén a színek beállításával kapcsolatos változtatás lehetőségéről tudtak, nagyon testreszabhatónak pedig, ha egyes alkalmazástípusok feltelepítésével kapcsolatosan

adott a döntés lehetősége, hogy az csomagok formájában sor kerül-e, azaz azon alkalmazáskomponenseket, melyeket nem kívánnak használni, nem telepítik fel. 7.39 Átlagosan a számítógép előtt töltött idő A válaszadók 35,71%-a átlagosan 6–8 órát tölt gép mellett, 28,57% 4–6 óra között. Egyetlen (magas beosztású) válaszadó volt, aki ennél kevesebbet, és 28,57%, aki 8 óránál többet tölt gép előtt. Ebben egyrészt a munkaidő, másrészt a munka esetleges otthoni folytatása, valamint a számítógéphez kapcsolt szórakozási lehetőségek is feltüntetésre kerültek (7.39 ábra) 7.310 Informatikai jártasság Eredendően a válaszadó informatikai ismereteinek ellenőrzését szolgálta egyrészt a háttérkép beállításával kapcsolatos kérdés, másrészt a hírekkel 2009. június 15 129 7.37 ábra Milyen mértékben testreszabhatóak a szoftverek? 7.38 ábra Milyen mértékben testreszabhatóak a szoftverek? kapcsolatos.

Azonban a felmérés során kiderült, hogy valamennyi válaszadó részére ismert és alkalmazott megoldás a háttérkép megváltoztatásának mód2009. június 15 130 7.39 ábra Átlagosan mennyi időt töltenek a számítógép előtt? ja, így ez alapján közöttük különbséget tenni nem lehetett. A szakmai járatosság tesztkérdése ezért a 13 pontban rögzített RSS feed lett, amely esetén a válaszadók közül többen (30%) visszakérdeztek, hogy az mi és miként működik, és csupán a válaszadók 14,29%-a használta a mindennapokban. A hírekről történő informálódás módja a következők szerint oszlik meg: neten hírportálon: 100%, újságban 50%, televízión: 42,86%, rádión: 42,86%, RSS feed alapján: 14,29% (7.40 ábra) 7.311 A felmérésben részt vevő szervek sajátosságai A felmérés vizsgálta továbbá a válaszadókhoz tartozó szervezet, szervezetrendszer méretét. Az elemző kérdések során felmerült, hogy a vizsgálat csak a

központi vagy a teljes átfogó rendszerre vonatkozik-e. A kérdésre adott válaszok a jelenlegi állapotot szemléltetik, és becsült értékeket tartalmaznak A válaszadók egy része titokvédelmi okokból bizonyos információk szolgáltatását megtagadta. 2009. június 15 131 7.40 ábra A hírekről történő informálódás módja Munkavállalók és számítógép-használat A vizsgált szervezeteknél az átlagos gépfelhasználás (irodai munkavégzés) 90,26%-os. Nem végeznek számítógéphez kötött munkát a sofőrök és a kisegítő személyzet A foglalkoztatottak száma és a gépfelhasználás százalékos mutatója a 7.41 ábrán láthatóak szerint alakul A számítástechnikai rendszer összetétele A számítástechnikai rendszer összetételével kapcsolatosan egyrészt felmérésre került a teljes gépállomány, másrészt annak összetevői: asztali gép, szerver és laptop. Ezek megoszlása a 742 a 743 és a 744 ábrán látható Ahogy kitűnik,

igen nagy számú szervert használnak a közigazgatásban. A FLOS szoftverek felhasználásának egyik legjelentősebb platformja a szerver oldal. Szinte minden helyen már jelenleg is dolgoznak FLOS szoftveres környezettel. A legjellemzőbb felosztás, hogy a szerverek egy része (például internetes alkalmazáskezelők) FLOS szoftver alapokon, és a Windows levelezés háttérszerverei pedig Microsoft alapokon futnak A szerver oldalon egyébként azok a szoftverek jelentek meg, amelyekhez „gyártói” támogatás vehető igénybe, így például a SuSe és Debian, valamint a Red Hat. A hálózati forgalom figyelése több helyen szintén FLOS szoftverekkel történik 2009. június 15 132 7.41 ábra A gépfelhasználás százalékos mutatója 7.42 ábra A gépek száma (Nagios), bár volt olyan válaszadó, aki nem volt tisztában azzal, hogy ez a szoftver FLOSS-nek számít. Adatbáziskezelőként azokban az esetekben, ahol az adatok elvesztése felbecsülhetetlen kárt

jelentene, az Oracle merült fel. 2009. június 15 133 7.43 ábra A gépállomány megoszlása, a szerverek aránya 7.44 ábra A gépállomány megoszlása, a laptopok aránya Kitűnt azonban, hogy a fejlesztések csak részben mutatnak ebbe az irányba. Több informatikai vezető említette, hogy fejlesztési irányként Sun Ray vékonykliensekben gondolkodik. 2009. június 15 134 Szoftverbeszerzésre költött összeg Szoftver licenc vásárlása A már meglévő szoftverállomány bővítésére, upgrade és egyéb licencekkel összefüggő költségekre a megkeresett szervezetek összesen 1618 millió forintot költenek. Ennek eloszlása látható a 745 ábrán 7.45 ábra Szoftverekkel összefüggő költségek Szoftverfejlesztésre költött összeg A szoftverek karbantartására, bővítésére, speciális feladatot ellátó szoftverek fejlesztésére szánt keret összesen 3650 millió forint, ennek eloszlása látható a 7.46 ábrán Érdekesség, hogy míg egyes

szervezetekből a fejlesztési munkát kiszervezik, addig más helyen az elmúlt időszakban fejlesztő kollégákat vettek állományba annak érdekében, hogy a kód a szervezet sajátja legyen, és a harmadik féltől való függést minimalizálni lehessen. Informatikus munkavállalók száma A munkavállalók számának megoszlása a 7.47 ábrán látható A felmérés érintőlegesen vizsgálta, hogy egy-egy szervezetnél mekkora a valós fejlesztési potenciál, illetve hogy a több száz, néha több ezer gép supportját miként oldják meg. Külsős cég részvétele az informatikában A hálózat üzemeltetése a Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatala és/vagy 2009. június 15 135 7.46 ábra Szoftverekkel összefüggő költségek 7.47 ábra Informatikus munkavállalók száma más külső szervezet közreműködésével történik. A külsős közreműködők szá2009 június 15 136 ma – ide értve a fejlesztéssel megbízott

cégeket is – a 7.48 ábrán láthatóak szerint alakul. 7.48 ábra Külsős közreműködők száma Eszközbeszerzés Az eszközbeszerzések (és licenc beszerzések is) közbeszerzési eljárás keretében történnek. 7.4 Egy esetleges átállással kapcsolatos tapasztalatok, felvetések, félelmek 7.41 Problémák, tapasztalatok – A felmérés során kitűnt, hogy több helyen a változtatást az akadályozza, hogy más szervezetek elavult rendszereihez kell alkalmazkodni, hogy az adatcsere megfelelően működjön. Akadályt jelentenek továbbá a saját korábbi fejlesztések is, hiszen azok Microsoft platformra lettek optimalizálva, így azt átalakítani csak abban az esetben lehetne, ha az átdolgozás jogát megszerezték volna, viszont erre az esetek nagy részében nem került sor. Például tipikusan ilyen probléma, hogy az intranet (vagy a jövedéki rendszer és a vámügyes rendszer) csak Internet Explorerben fut, és soha nem is került kikötésre egyetlen

megrendelt fejlesztésnél sem, hogy más platformon futnia kellene. 2009. június 15 137 – Problémát jelent továbbá, hogy egyes intézmények rendkívül nagy számú űrlappal dolgoznak, amelyek kezelése (a folyamatos változások átvezetése stb.) is igen nagy erőforrást igényel, az űrlapok – amelyek bizonyos szinten működhetnének sablonok szerint – különféle makrókat használnak, amelyek viszont nem platformfüggetlenek. – Gondot jelentene az is, hogy egyes helyeken SAP kulcsoltak az alkalmazások, az SAP pedig a Microsoft Excelből exportált adatokkal dolgozik (bár van esély arra, hogy az OpenOffice függvénykezelésben felzárkózzon). – Problémát jelent, hogy nem homogén hálózatot üzemeltetni sokkal nehezebb. Érdekes, hogy valós problémaként – és nem csak kényelmi szempontok okán – nem a Microsoft termékeitől, hanem az Oracle adatbázisszoftvereitől való elszakadást jelölték meg – Voltak olyan válaszadók, akik a

terminál-rendszerek felé kívántak elmozdulni, ott viszont – állításuk szerint – a szoftverek hardverkapcsoltak, így azok ismételten elzárják a változtatás lehetőségeit. Volt olyan, aki azt mondta, hogy az Office 2003-ról 2007-re történő váltás legalább olyan körülményes, mint amilyen az OpenOffice-ra történő átállás lehetne, hiszen itt is nagyon megváltozik a kiszolgálófelület. Az irodai csomagokkal kapcsolatos tapasztalat azt mutatja, hogy a profi felhasználók (akik már nem tabulátorral és szóközzel formázzák a szöveget, illetve Excelben minimális mértékben értenek a műveletekhez) elég kis százalékban vannak (5–30% között). Számukra kellene oktatást tartani Azok azonban, akik mint „okos írógépet” használják a szoftvert, könnyen átállíthatóak. – A válaszadók között többen próbálták az OpenOffice bevezetését. Az egyik helyen a jobb hardvert igénylők kapták ezt az irodai csomagot, illetve a mobil

munkaállomásokra telepítették eleve ezt. A tapasztalatok azt mutatják, hogy a support-igény nem növekedett meg (Viszont a jobb hardver iránti igény eleve a tapasztaltabb felhasználóknál jelentkezett, így külön oktatási költségek nem jelentkeztek.) – Más helyen az OpenOffice 2.0 óta nem kísérleteztek az újabb verziókkal, azonban egy jól előkészített központi döntés esetén erre nyitottak lennének, akár tesztelői munkával is segítenék az átállás előkészítését. 2009. június 15 138 7.42 Fejlesztési javaslatok – A FLOS szoftverek jelenlegi elterjedése azt mutatja, hogy szerver oldalon egyre növekvő a jelenlétük. A desktop részen való átállás körülményesebb, és ez az, amit kötelezettség vagy kilátásba helyezett juttatás (például prémium kitűzése5 azokon a helyeken, ahol ez megvalósul) nélkül nem lépnek meg. – A tapasztalat azt mutatja, hogy ikonfüggőek az emberek, így ha hasonló ikonokkal hasonló

alkalmazásokat lehetne elérni, és az alapfelület is hasonló lenne, az áttérés nem lenne zavaró vagy nehézkes. Sőt, a basic felhasználók között általános tévképzet, hogy valamennyi ablakos rendszert „Windows” alkalmazásnak tartanak, és egyedi fejlesztéseknél is ezt az elrendezést igénylik. – Szinte valamennyi válaszadó szerint az átállás csak központi akarat alapján, hatalmi szóval lenne megvalósítható, hiszen amíg nincsenek egységesítési törekvések, addig mindenki saját ötletei és igényei szerint valósítja meg az elképzeléseit. – Össze kell hangolni a közigazgatási szervezeteken belüli informatikai stratégiákat például oly módon, hogy ezzel kapcsolatosan használható sablont biztosít a kormányzat. Az egyik válaszadó szerint: amíg a MEH nem mutat független fájlokat, amelyek bármelyik rendszerben olvashatóak, addig az átállás kérdését elméleti szinten sem fogják megvizsgálni, addig olyan rendszer kell,

amin Microsoft Office fut. – Amennyiben szabványok szerint meghatározott formátumok és nem a formátum előállítására alkalmas szoftver lenne előírva, szélesebb lenne a választható alkalmazások köre. – Több olyan válaszadó is volt, aki egy esetleges váltás (nyitás) következtében a visszaélések visszaszorítására lát lehetőséget. Egyetlen válaszadó sem határozta ezt meg rövid távon kivitelezhető váltásként Legalább 1–1,5 éves előkészítést, 2 éves átállási szakaszt jelöltek meg. 5 Ily módon elkerülhető lenne a munkavállalói ellenkezés, és az erre fordított pénzösszeg nem vándorolna ki az országból jogdíj formájában, hanem közvetve visszaforgatásra kerülhetne, élénkítve a gazdaságot. Bővebben : a 11 fejezetben 2009. június 15 139 7.43 Egy átállás tapasztalatai Tekintettel arra, hogy Szeged Önkormányzata közel 500 géppel állt át a FLOS szoftverek használatára6 , az esetükben megjelenő

valós tapasztalatokat külön kiemelve ismertetjük. Magyarország Münchene Szegeden a szabad és nyílt forrású szoftverek bevezetése három lépcsőben történt. Az átállás lépései: 1. A nyílt forráskód alkalmazásának elfogadása a közgyűlés által (2004 évben). 2. A közös döntésre hivatkozva a képviselőtestületi döntések meghozatala 3. Tényleges bevezetés Az eddig elért eredményekhez erős központi, vezetői támogatás volt szükséges, melyet itt az alpolgármester biztosított, s melynek háterét a 2004. évi döntés adta meg. Az átállás lépcsői gyakorlatilag az alábbiak voltak: 1. OpenOffice Windows környezet alatt 2. Egy nagyobb, integrált, web-alapú, munkát segítő platform fejlesztése (böngészőből kezelhető). 3. Amikor megszokták az OpenOffice használatát és a webes alkalmazás használatát, akkor jött a linuxos környezet (Ubuntu) bevezetése A linuxos átállás még most is tart (körülbelül 1 éve kezdődött).

Tapasztalatok 1. Az oktatásról: nagyon nagy oktatás nem volt, mert webbezni mindenki tudott, az office-t meg senki sem ismeri, nagyjából csak a képviselőtestületet kellett tanítani. 2. A Linuxról: itt jól bevált az Ubuntu disztribúciójú kliens oldal – grafikus felületek (azaz ablakkezelők) Xfce, Gnome, KDE (Windows skin mellett), van olyan kolléga, aki nem is tudja, hogy Linuxot használ. 6 Az összes gépen OpenOffice irodai csomag és Mozilla Firefox van használatban. A Windows (OEM) licenceket addig nem dobják el, amíg a hardver alatta működik, de új licenc már nem kerül beszerzésre. Ennek a – viszonylag lassú, a hardverek kihalására alapozott – stratégiának az eredménye az, hogy közel 200 gépen van már Linux. 2009. június 15 140 A környezet ahol ezek a lépések végbementek Szegeden az önkormányzatban közel 600 gép (516 + 43) van, jellemzően minden ügyintézőnek van gépe. A rendszerüzemeltetői létszám 10 fő, akiknek

feladata az összes program összes baja. Szerver oldalon jelenleg SuSe és Debian disztribúciójú Linux van, de a tervek szerint teljesen Debian disztribúciójú Linux lesz. Az önkormányzati intézmények (középiskola, bölcsőde, óvoda stb.) hálózati üzemeltetése is hozzátartozik az élethez Ez a RITEK (RITEK Rt – azaz a Regionális Információ TEchnológiai Központ Rt.7 ) segítségével történik A RITEK – amely maga is használ szabad szoftvert8 – feladata a hardver és szoftver üzemeltetés, 160 telephely ADSL hozzáféréssel rendelkezik. Ezek felől (a 2013-ig tartó IT stratégia szerint) VPN segítségével történik a központhoz a csatlakozás. A telephelyeken jelenleg nem folyik az átállás, mert az operációs rendszer cseréje (fizikailag maga a munka) egyelőre nem éri meg, ráadásul az itteni munkaállomások jelentős része OEM-szoftverrel fut, melyek lecserélése most (mivel a szoftver árra már kifizetésre került) nem okozna

költségcsökkenést. Amennyiben OEM licenccel rendelkező gép cserére szorul, azt már Linux-szal tervezik rendszerbeállítani. Mai állapot szerint tehát használják a már meglevő szoftvereket. Az intézményi gépek többsége nem nagyon jut ki az internetre, minimális a nem a központ felé VPN-en, vagy helyben folyó tevékenység, ami csökkenti a Windows támadhatósága miatti kockázatot. Összességében az intézményi hálózatban az átállás valószínűleg csak akkor fog megkezdődni, ha nagyobb gépcserék lesznek. Problémák 1. A jogtár (az önkormányzat gyakorlatában a Complex) egy nagyon fontos dolog – jó lenne, ha szabad szoftver alól is működne minden funkciója Segítség a jogszabályok elérésében a magyarorszaghu oldal, de a történeti követés (változáskövetés) nem alkalmas a használatra. Erre (változások követése, múltbeli törvényállapotok elérése) egy önkormányzatnak elkerülhetetlenül szüksége van, ezért a

Complex jogtár jelenleg nem kiváltható 2. Szegeddel ellentétben kis önkormányzatoknál feltehetően csak olyan gépek vannak, amelyeken a Windows környezetet igénylő célszoftverek futnak, így itt a csere nehezebb vagy lehetetlen. 7 Teljesen (100%-ban) az önkormányzat tulajdonában álló cég, amely hardvert forgalmaz, szervizel, rendszert üzemeltet, szoftvert fejleszt. 8 Szerver oldalon Debian disztribúciójú Linux, és adatbáziskezelőnek jellemzően PostgreSql. 2009. június 15 141 3. Nincs közös tudástár, így mindenkinek egyesével kell rájönnie a jó megoldásra A tudástár megvalósításához közös pont, támogatás kellene 4. Az egyéb feladatok mellett sajnos nem fér bele a dolgozók idejébe, hogy leüljenek és kitalálják a jó megoldásokat, ezért azt használják, ami van. 5. Nincs költségvetés és kapacitás arra, hogy ezekből megfelelő publikáció, dokumentáció készüljön. Ha volna erre anyagi keret, megoldható lenne a

tudástár felépítése, központi elérhetősége. 6. Nincs olyan központi koncepció, hogy a kötelezően használandó programokat az állam több platformon tegye hozzáférhetővé, vagy hogy eleve így készüljenek el (fejlesztési javaslatok). Volt valami hasonló „bevált gyakorlatok műhelye” 2–3 éve. 7. Az Excel makrók OpenOffice-ba konvertálása nehézséget okoz, bár a táblázatkezelő programok eleve sok nehézséget okoznak (a felhasználók képtelenek kezelni). 8. A felhasználók úgy tekintenek egy számítógépre, mint egy okos írógépre (a Word – OpenOffice kompatibilitási hiba leggyakrabban az, hogy tabokkal és szóközökkel tördelik a dokumentumokat a felhasználók sablonok használata helyett). Összefoglalás – Az informatika kiszolgáló terület, az ott megtakarított összegeket az önkormányzat szempontjából hasznosabb célokra is lehetne fordítani. – Az e-önkormányzat szabad szoftver alapra helyezése itt Szegeden

pártfüggetlenül támogatást élvez. 2009. június 15 142 2009. június 15 8. fejezet A FLOS szoftverek megjelenése a kormányzati stratégiákban és jogalkotásban 8.1 Stratégiai tervezés és a nyílt forráskódú szoftverek kormányzati felhasználásának lehetőségei A Magyar Információs Társadalom Stratégia készítéséről, a további feladatok ütemezéséről és tárcaközi bizottság létrehozásáról szóló 1214/2002. (XII. 28) kormányhatározat elfogadta a magyar információs társadalom stratégia legfontosabb céljait, az ágazati feladatokra vonatkozó részstratégiák kidolgozását az ágazati miniszterek felelősségévé, a MITS elkészítését az informatikai miniszter feladatává tette. A feladat végrehajtásának összehangolására létrejött az Információs Társadalom Koordinációs Tárcaközi Bizottság, 2003 nyarán – az IHM által előzetesen meghatározott szempontok figyelembe vételével – elkészültek az ágazati

részstratégiák, 2003 augusztusában pedig az azokat egységes egészbe integrálni kívánó nemzeti stratégia. A MITS-val párhuzamosan született meg az eKormányzat 2005. Stratégia és Programterv, mely a kormányzati informatika körében mérte fel és ütemezte az elvégzendő feladatokat. Az elkészült stratégia a „hármas korszakváltás” (EU-csatlakozás, információs társadalom útjára lépés, a magyar közigazgatás átfogó reformja) alapkövetelményeinek figyelembe vételével kerül kimunkálásra. A koncepció az e-kormányzat fogalmát a modern, szolgáltató állam megvalósításának középpontba állításával (az EU tagállami gyakorlatával összhangban) tágan értelmezte, az elektronikus ügyintézés összefüggé143 144 sében minden, elektronikusan intézhető ügytípusra egyaránt irányadó alapelvek megfogalmazására törekedett. Ezt az egységes szemléletű kezelésmódot azonban a MITS egészében nem támogatta, az elektronikus

ügyintézésre vonatkozó ambiciózus elképzelések nagy része sem teljesült. 8.1 táblázat: A 2004–2006 közti időszakban az elektronikus ügyintézést érintő, a 2004–2006 közti időszakban megvalósítandó feladatok a MITS e-kormányzati stratégája szerint FO08 FO09 FO010 FO011 FO012 FO31 FO33 FO432 FO44 FO27 FO28 Országosan egységes közigazgatási fogalomtár és adatbázis, valamint ügyintézést segítő adattár kidolgozása, folyamatos karbantartása és használatának megvalósítása. A különböző (miniszteriális, központi, regionális, kistérségi, települési) közigazgatási rendszerek együttműködésének és adatbázisok közös használatának feltételei, megvalósítási feladatainak és azok ütemezésének meghatározása. A személyi adatok interneten történő mozgása esetében az adatvédelem és az elektronikus kommunikáció biztonságának vizsgálata az Európai Unió direktívái és a nemzetközi gyakorlat

elemzésével. Az önkormányzatok ügyfeleinek azonosítására, adatok „mobil” tárolására smart kártya kibocsátása és használata lehetőségének elemzése, a kártya alkalmazásának megvalósítása. Országos önkormányzati portál megvalósítása (a Kormányzati Portál önkormányzati „megfelelője”). Kistérségi informatikai együttműködések kialakítása, közös rendszerfejlesztések megvalósítása, rendszerek közös üzemeltetése. Az önkormányzatok részére alkalmazás-szolgáltatás megvalósítása, bevezetése. „e-ügyintézők az e-önkormányzatban” képzési program. Közösségi internet hozzáférési pontok létrehozása – információ-szolgáltatás, e-Ügyintézés. e-Ügyintézés – az ügyintézéshez szükséges űrlapok online kitöltése, hitelesítése, megküldése. e-Ügyintézés – teljes elektronizált közigazgatási ügyintézés (döntés, kézbesítés, illeték). 2009. június 15 145 A MITS, s vele

egyidőben az eKormányzat 2005. elfogadása (A Magyar Információs Társadalom Stratégiáról és annak végrehajtásáról szóló 1126/2003. (XII 12) Korm határozat) a továbblépés szempontjából mégis döntő fontosságú mozzanatnak minősült. A stratégiai célok azonosításra, ütemezésre kerültek, megvalósításuk tárgyában pedig – egyedi kormányhatározatokkal – konkrét, a felállított prioritásokat visszatükröző feladatszabásokra, illetőleg folyamatban lévő, korábbi kormányhatározatokban előírt feladatteljesítésekkel (Az Elektronikus Kormányzati Gerinchálózatról és az Informatikai Közhálóról szóló 1188/2002 (XI 7) Korm határozat, A 2003 január 1 és 2006. december 31 közötti időszakra szóló középtávú terv a köztisztviselők továbbképzéséről és a közigazgatási vezetőképzésről szóló 1020/2003 (III 27.) Korm határozat) való összehangolására is sor kerülhetett Az eKormányzat 2005 Elektronikus

Kormányzat Stratégiában és Programtervben, illetve az eEurope 2005 akciótervben meghatározott, a szolgáltató állam létrehozásához kapcsolódó reformfolyamatok felgyorsítása érdekében a közigazgatási reformfolyamat felgyorsításával kapcsolatos feladatokat összehangoló Koordinációs Bizottság [2124/2003. (VI 6) Korm határozat] irányítása alatt az E-kormányzat Operatív Bizottság létrehozásával megteremtődött a tárcaközi koordináció gyakorlati működtetésének talán leglényegesebb feltétele. A MITS elfogadásával párhuzamosan a kormány konkrét jogalkotási feladatokat is meghatározott [Az elektronikus kormányzat megvalósításával öszszefüggő egyes szabályozási feladatokról szóló 2316/2003. (XII 10) Korm határozat], illetőleg több, az EU-csatlakozás összefüggésében felmerülő információs társadalmi feladatok megvalósításáról [A Magyar Köztársaság Kormánya és az Európai Közösség között a műszaki

szabályok és az információs társadalom szolgáltatásai terén követendő információszolgáltatási eljárásról szóló Megállapodás létrehozásáról és megkötéséről szóló 2294/2003. (XII 9) Korm. határozat, Az Európai Unió döntéshozatali tevékenységéhez kapcsolódó kormányzati koordináció informatikai és adatkezelési hátterének kialakításáról szóló 2329/2003 (XII 16) Korm határozat] hozott döntést E célok elérése a kormányzati informatikai fejlesztésektől megkövetelte a MITS és az eKormányzat 2005. Stratégia célkitűzéseivel való összhangot, a KIETB által elfogadott célkitűzéseknek, ajánlásoknak való megfelelést, a célszerűség, egységesség, harmonizáltság, költséghatékonyság, átláthatóság és ellenőrizhetőség magas szintű biztosítását, és az informatikai biztonság elérhető legmagasabb szintjének és a kormányzati informatikai rendszerek együttműködtetésének lehetővé tételét, a

személyes adatok védelmére vonatkozó jogszabályok, és az információs önrendelkezési jog érvényre juttatását. Az EU által az eEurope 2005 akciótervben meghatározott 20 alapvető szolgáltatás megvalósításának koordinálása terén a MeH EKK tevékenységét segítette a 1126/2003. (XII 12) Kormányhatározattal létrehozott E2009 június 15 146 Kormányzat Operatív Bizottság (EKOB), melynek összetételét és feladatait a 1054/2004. (VI 3) Korm határozat szabályozta Az EKOB a 2124/2003 (VI. 6) Korm határozat alapján létrehozott Koordinációs Bizottság irányítása alatt működött Az elektronikus ügyintézést érintő összkormányzati koordinációs tevékenységét a Kormányzati Informatikai Egyeztető Tárcaközi Bizottság (KIETB) segítette. A KIETB az 1991-ben a 3296/1991 kormányhatározattal létrehozott Informatikai Tárcaközi Bizottság (ITB) jogutódjaként módosított elnevezéssel, módosított hatáskörrel és ügyrenddel

működött. A jogelőd ITB működésére vonatkozott még az 1039/1993. (V 21) Korm határozat a központi államigazgatási szervek informatikai fejlesztéseinek koordinálásáról, az 1106/1995. (XI 9) Kormányhatározat a központi államigazgatás informatikai koordinációjának továbbfejlesztéséről, valamint az államigazgatási informatika koordinációjának továbbfejlesztéséről szóló 1066/1999. (VI 11.) Korm határozat is) A KIETB-re vonatkozó szabályozást, valamint a tárcaközi bizottság feladatait a 1054/2004. (VI 3) Korm határozat tartalmazta A KIETB keretei között már 2003-ban megkezdődött a nyílt forráskódú szoftverek kormányzati felhasználási lehetőségeinek vizsgálata. A bizottság által 2003 március 18-án tárgyalt vitaindító anyag szerint az utolsó néhány év gyakorlata bebizonyította, hogy a nyílt forráskódú, ingyenes eszközök használata nem csak lelkes egyetemisták múló fellángolása – ahogy ezt a

monopóliumukat féltő szoftvergyárak állítják –, hanem az informatikai ipar egy új, erős és versenyképes trendje. Ezt az állítást támasztja alá az is (ami miatt tulajdonképpen a közelmúltat az áttörés éveinek nevezhetjük), miszerint a legnagyobb cégek, meglátván a FLOS szoftverekben az üzleti lehetőséget, teljes erőbedobással támogatni kezdték azt. A szabad szoftver mozgalom és a részben Linux alapú rendszerek terjedésének trendszerűségét bizonyító fenti tények is nagyban hozzájárultak, hogy kormányzati szinten is foglalkozni kell a szabad és nyílt forráskódú szoftverek felhasználási lehetőségeivel. A FLOS szoftverek felhasználása az általános trendet követve növekszik mind az üzleti, mind a költségvetési szférában. A felmérés is rámutatott arra, hogy ahhoz, hogy utóbbiban ez ne csak alkalomszerű és bátortalan egyéni kezdeményezésekre történjen, egyértelmű kormányzati állásfoglalásra és

támogatási rendszerre van szükség. Ezek kialakítása komoly és összetett feladat, mely pontos tervezést igényel. Az első és legfontosabb teendő az „érvényben lévő magyar jogrend és a szabad szoftver licencek kompatibilitásának vizsgálata”. Ennek eredményei alapján, ha kell törvénymódosítást is meglépve, megalkotható lenne a kormányzat által hivatalosan támogatott FLOS alapú szoftver licenc, melynek megalkotása után ennek használata a kormányzat által finanszírozott 2009. június 15 147 szoftverfejlesztésekben javasolt, a nyílt szabványok és a platformfüggetlenség támogatása pedig kötelező lenne. Ennek megfelelően a vitaanyag javasolta a nyílt forráskódú, teljesen magyar nyelvű Linux disztribúció kormányzati szintű támogatását. Itt magyarított külföldi (például: SuSe, Red Hat, Mandrake) és teljesen magyar terjesztést (UHU Linux projekt) is elfogadhatónak ítélt Az előbbiek magasabb fejlettségi szinten

vannak, míg utóbbi előnye, hogy fejlesztési iránya kézben tartható, illetve támogatása is teljesen magyar.1 A preferált eszközök kiválasztása után szükséges az ehhez kapcsolódó szakkönyvek, oktatási segédanyagok és egységes felhasználói tanfolyam-, valamint vizsgarendszer kidolgozása Az anyag úgy ítélte meg, hogy amint ezek mind rendelkezésre állnak és elérhetők, „a személyi számítógép forgalmazóktól elvárható” lesz, hogy – akár jogi kötelezettség terhével sújtva – komplett gépet csak előre installált jogtiszta operációs rendszerrel értékesítsenek. Alapvető kérdéseknek mindazonáltal a vitaanyag annak vizsgálatát tartotta, hogy miért nem terjed az államigazgatásban/közigazgatásban a nyílt rendszereken alapuló megoldások, szabad szoftverek alkalmazása, miért lenne jó, ha terjedne – ezek összefüggésében törekedett a következő lépés meghatározására. Ezt lényegében a szoftvermonopóliumok

megszüntetésében jelölte meg, ezt elérni csak támogatással, népszerűsítéssel, a pályázatoknál, kormányzati felhasználásnál a nyílt szabványok használatának preferált szempontként történő előírásával vélte megvalósíthatónak Az anyag arra is felhívta a figyelmet, hogy zárt forrásokat használó termékek gyártói komoly lobbyerővel rendelkeznek, ennek letörése ugyancsak fontos feladatnak minősül.2 A – nyilvánvalóan jó szándékkal – készült anyag ugyan valós helyzetértékelésből indult ki, a probléma természetét is helyesen azonosította, a javasolt megoldás – a piaci viszonyokba való közvetlen beavatkozás – egyrészt a közösségi és magyar versenyjoggal feltehetően összeegyeztethetetlen megoldást jelentett volna. A nyílt forráskódú szoftvereknek a közigazgatásba való bevezetés támogatásának összefüggésében Uniós csatlakozásunkat követően került kimunkálásra egy olyan kompetencia-központ

felállítására vonatkozó javaslat, mely a fejlesztések összehangolására, tudásbázisra alapozva valós alternatíváját jelenthette volna a „zárt” forráskódú szoftverek szinte kizá1 Időközben rendkívül széles körben elterjedt, és a felmérés keretében is ismertnek minősített disztribúció lett az „Ubuntu”, amely egy kifejezetten egyszerű, az eddigi leginkább felhasználóbarát megoldás. 2 Vitaindító anyag a KIETB ülésére az Open Source Software-ek (nyílt forráskódú szoftver) kormányzati felhasználási lehetőségeiről, http: ://www.mehhu/szervezet/hivatalok/ekk/kietb/dokumentumok/open− −source20041104.html 2009. június 15 148 rólagos kormányzati felhasználásának.3 A kompetencia-központ felállítására 2006 januárjában került sor, ám tevékenysége még ugyanebben az évben meg is szűnt.4 A 1188/2002. (XI 7) Korm határozattal a kormány korábbi szándékát megerősítve [1122/2001. (XI 22) Korm határozat]

rendelkezett arról, hogy a kormányzati és közigazgatási adatbázisok és informatikai rendszerek összekapcsolása, az általuk nyújtott szolgáltatások elérhetőségének biztosítása, valamint az elektronikus kormányzat megvalósítása érdekében ki kell alakítani az elektronikus kormányzat alapinfrastruktúráját képező nagysebességű országos adattovábbító Elektronikus Kormányzati Gerinchálózatot, és az ahhoz csatlakozó központi közigazgatási szervek részére nagysebességű külső internet-csatlakozást szükséges biztosítani. A központi rendszer felügyeletét és üzemeltetését A Miniszterelnöki Hivatalról, valamint a Miniszterelnöki Hivatalt vezető miniszter feladat- és hatásköréről szóló 176/2007. (VII 1) Korm. rendelet alapján a Miniszterelnöki Hivatal látta el 8.2 Az információs társadalommal összefüggő kormányzati tevékenység irányítása és eszközrendszere A központi rendszer a még 2003-ban elfogadott

eKormányzat 2005. stratégia szerint a hatósági közigazgatási ügyintézés követelményein túlmutató feladatokat is ki kellett, hogy szolgáljon Az eKS keretében az EU-ban egységesen elfogadott négy szolgáltatási szintnek megfelelően a Kormány a 1044/2005. (V 11) Korm határozatban meghatározta a szolgáltatások 2005 december 31-ig tartó kiépítési ütemét. A kormányzati portál szolgáltatási menüjében 2009-re több, mint 80 intézmény részvételével nyújtott szolgáltatások érhetők el. Ugyanakkor a szolgáltatások tartalmilag kevésbé valósítják meg az ügyfélközpontúságot, valamint a szolgáltatások hátterét adó intézményrendszer fejlesztésére csak kismértékben került sor Az egységes e-fizetés hiánya miatt teljes körű elektronizáltságról általában nem lehet beszélni, valamint a szolgáltatások egyelőre még inkább az ügyintézések elektronikus elérését biztosítják, kevésbé nyújtanak hozzáadott értéket

teremtő szolgáltatásokat. Az intézményrendszer elektronizálása és interoperabilis működésének megteremtése, valamint az e-kormányzás kialakításához szükséges tudás és e-kormányzati kultúra 3 4 Lásd http://misc.mehhu/binary/6783 kompetencia kozpontpdf Lásd http://misc.mehhu/binary/7853 szkkpdf 2009. június 15 149 megteremtése a ténylegesen rendelkezésre álló időhöz és forrásokhoz képest, azokkal arányban valósulhatott meg.5 A központi rendszer elemei közül az EKG 2001–2004 között, a kormányzati portál 2002-ben már kialakításra került, az ügyfélkapu szolgáltatásai 2005. április 1. óta vehetők igénybe A Ket-ben szereplő egyes feladatok végrehajtásának biztosítása érdekében hozott 1044/2005 (V 11) Korm határozat 5 pontjának megfelelően megkezdte működését a kormányzati ügyféltájékoztató központ, a KÜK is. A központi rendszer alapvetően az elektronikus kormányzati gerinchálózat (EKG) révén

biztosítja az alapinfrastruktúrát a kommunikációhoz és az együttműködéshez. A kormányzati portál feladata a tájékoztatás és a bárki számára hozzáférhető közérdekű szolgáltatások nyújtása A kormányzati portál részeként működő ügyfélkapu az azonosítást igénylő közigazgatási, hatósági ügyek intézését, és az ezekhez kapcsolódó szolgáltatások elérését biztosítja az állampolgárok számára; a hivatali kapu révén pedig a csatlakozott szervek hitelesen fogadni tudják az elektronikus üzeneteket, illetve a hivatalok elektronikus üzenetei a hitelesen azonosított ügyfelekhez eljuttathatók. A kormányzati portálon és az ügyfélkapun keresztül jelenleg már több száz szolgáltatás érhető el. A Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007. (IV 25) Korm rendelettel, illetőleg A Központi Elektronikus Szolgáltató Rendszerről szóló 182/2007.

(VII. 10) Korm rendelettel – a Ket szabályaival összhangban – lefektetésre került az ügyfélkapu köré kiépült, központosított elektronikus ügyintézés alapvető jogi és informatikai biztonsági feltételrendszere. A Kormány a közigazgatás átalakításának előkészítésével kapcsolatos egyes feladatokról szóló 1054/2006. (V 26) Korm határozatában, illetőleg az államháztartás hatékony működését elősegítő szervezeti átalakításokról és az azokat megalapozó intézkedésekről szóló 2118/2006. (VI 30) Korm határozatban döntött az Elektronikus Közszolgáltatások Központjának létrehozásáról Az EKK létesítésének előkészítése – az elektronikus kormányzat megvalósításával, a közigazgatási informatika országos szintű fejlesztésével és működtetésével kapcsolatos egységes kormányzati tevékenység irányításával összefüggő feladatai ellátása mellett – a közigazgatási informatikáért felelős

kormánybiztos kinevezéséről és feladatairól szóló 1066/2006. (VI 29) Korm határozat értelmében a kormánybiztos feladata lett.6 5 6 E-Közigazgatás 2010 Stratégia, 19–20. o Miután a miniszteriális és a végrehajtási feladatokat egy középszintű irányító szervbe összevonni nem lehetett, az EKK tervezett feladatkörének ellátása a későbbiek során ténylegesen a KEK KH.-hoz került 2009. június 15 150 A közigazgatási szolgáltatások korszerűsítési programjának kormányzati koordinálásáról szóló 2124/2003. (VI 6) Korm határozatot és a kormányzati informatika fejlesztésének koordinálásával kapcsolatos egyes feladatokról szóló 1054/2004. (VI 3) Korm határozatot felváltó, a közigazgatási informatikai feladatok kormányzati koordinációjáról szóló 1026/2007 (IV 11) Korm. határozat több lényeges területen erősítette meg a koordináció jogi, szervezeti intézményrendszerét. A Miniszterelnöki Hivatalról, valamint a

Miniszterelnöki Hivatalt vezető miniszter feladat- és hatásköréről szóló 176/2007. (VII 1) Korm rendelet, illetőleg annak Melléklete határozta meg a miniszter a közigazgatási informatikával összefüggő feladat- és hatásköreit. A 2008 elején bekövetkezett újabb kormányzati átszervezéseket követően e kérdéseket a Miniszterelnöki Hivatalt vezető miniszter feladat- és hatásköréről szóló 29/2008. (II 19) Korm rendelet szabályozza, mely a közigazgatási informatikával kapcsolatos feladatok ellátásának irányítását a hivatkozott jogszabály a Miniszterelnöki Hivatalt vezető miniszterhez, mint a közigazgatási informatikáért felelős miniszterhez telepítette. A Kormány az 1026/2008. (IV 29) Korm határozatban az információs társadalommal összefüggő kormányzati tevékenység irányítására kétéves időtartamra kormánybiztost nevezett ki. A kormányhatározat értelmében tehát a Miniszterelnöki Hivatalt vezető miniszter a

közigazgatási informatikával kapcsolatos feladatok ellátásának irányítását az informatikáért felelős kormánybiztos útján látja el. A Miniszterelnöki Hivatal Szervezeti és Működési Szabályzatának kiadásáról szóló 1/2008. (MK 57) ME utasítás értelmében az infokommunikációért felelős kormánybiztos – mint a Miniszterelnöki Hivatal államtitkára – irányítja az infokommunikációért és e-közigazgatásért felelős szakállamtitkár [lásd Az infokommunikációért és e-közigazgatásért felelős szakállamtitkár kinevezéséről szóló 26/2008. (V 14) ME határozat] tevékenységét. 2008 májusában tehát a Miniszterelnöki Hivatal Szervezeti és Működési Szabályzata módosításra került, a kiadásáról szóló 4/2008. (MK 74) ME utasítás létrehozta a MeH infokommunikációért és e-közigazgatásért felelős szakállamtitkár posztját, így a korábbi Elektronikuskormányzat-központ elnevezés megszűnt, s az egységes

kormányzati informatikai irányítás kialakítása érdekében a korábban a Gazdasági és Közlekedési Minisztérium feladatkörébe tartozó információs társadalommal és e-gazdasággal összefüggő infokommunikációs feladatok is a Miniszterelnöki Hivatalhoz kerültek. E szervezeti rendszer (valamint az államtitkár, szakállamtitkár és a kormánymegbízott 2009. június 15 151 személye) a 2009. április 16-án megalakult kormányban is lényegében változatlan maradt7 A közigazgatási modernizációs feladatok kormányzati szintű egységes kezelése, a tárcaközi bizottsági struktúra egyszerűsítése, valamint a döntési kompetenciák szélesítése érdekében a Kormány által a korábbi bizottságok (ITKTB – ELKA, KIETB, EKOB) feladatainak egyesítése céljából létrehozott KIB [lásd 1026/2007. (IV 11) Korm határozat] zavartalan működését biztosító adminisztratív és szakmai jellegű feladatok ellátása az új szervezeti rendszerben a

Szakállamtitkárság feladatkörébe tartozik. Mint arra fentebb már utaltunk, a KIB, mint koordinációs fórum feladatköre a közigazgatási informatika egészére kiterjed, ezért tagjainak köre magában foglalja a központi államigazgatási szervek és az önkormányzati igazgatás képviselőit egyaránt. A KIB tagjai a közigazgatási informatika fejlesztésében érintett valamennyi intézmény legnagyobb szakmai tapasztalattal rendelkező képviselői. A teljes feladatkör lefedéséhez a tudományos és az üzleti szféra mellett elengedhetetlen volt valamennyi önkormányzati szövetség és a jegyzők szövetségének meghívása is. A KIB elnöke a közigazgatási informatikáért felelős kormánybiztos, titkára a Szakállamtitkárság E-Közigazgatási Főosztályának vezetője A MeH Infokommunikációs és E-közigazgatási Szakállamtitkárság közigazgatási informatikával összefüggő feladatai a szolgáltató állam kiépítéséhez szükséges

e-közigazgatás kialakításához és fejlesztéséhez, valamint a védelemszervezéshez kapcsolódnak. Ezek átfogó feladattervét, az annak végrehajtásával kapcsolatos követelményrendszert (ide értve a jogalkotással, a jogszabályi környezet deregulációjával és modernizációjával kapcsolatos kérdéseket is) a korábbi munkafázisok során született eredmények – a Központi Elektronikus Szolgáltató Rendszeren nyújtandó e-kormányzati szolgáltatások körének meghatározása (2007. január), az E-Közigazgatás fejlesztési koncepció (2007. március), a hazai elektronikus szolgáltatások fejlettségének áttekintése (2007. április) nyomán kialakított elektronikus közigazgatási szolgáltatások fejlesztésének koncepciója (2007 május) tapasztalatait összegző – az E-közigazgatás 2010 Stratégia és kapcsolódó anyagai bontják ki. A közel másfél évig tartó szakmai előkészítés, a szinte minden területre kiterjedő alapos

állapot-felmérések, az informatikai részfejlesztések összehangolása, a feladatok végrehajtásával összefüggő erősödő koordináció, az ügyintézési folyamatok technológiai értelemben való biztonságosabbá tétele és centralizációja tette lehetővé az „E-közigazgatás 2010 Stratégia”, illetőleg az „Informatikai Átfogó Stratégia” [IÁS] megalkotását. 7 Vö. : államtitkár kinevezéséről szóló 52/2009 (IV 16) KE határozat, az infokommunikációért felelős kormánybiztos kinevezéséről és feladatairól szóló 1053/2009 (IV. 17) Korm határozat, szakállamtitkárok kinevezéséről szóló 16/2009 (IV 21) ME határozat. 2009. június 15 152 Az „E-közigazgatás 2010 Stratégia” – amelyről szóló jelentést 2008. július 2-án vette tudomásul a Kormány – célja, hogy olyan, minden résztvevő számára közösen megvalósítani kívánt e-közigazgatási jövőképet fogalmazzon meg, amely az elkövetkezendő évek

fejlesztéseinek részletes céljaihoz egységes keretet ad, és megfogalmazza a célok eléréséhez vezető legfontosabb stratégiai tényezőket. Mint a Stratégia bevezetője rámutat, a Kormány azzal az alapvető célkitűzéssel indította el az E-közigazgatás 2010 stratégia kidolgozását, hogy az államreform keretében a hazai közigazgatás is megragadja a technológia nyújtotta lehetőségeket a közigazgatási működés átalakításában, továbbfejlesztésében, és Magyarország megtartsa helyét az EU tagországok IKT fejlettségi középmezőnyében. A stratégia négy területet célzott meg különös súllyal annak érdekében, hogy ezen területek tekintetében átfogó iránymutatást adjon. 1. A közszolgáltatások átalakítása az állampolgárok, a vállalkozások és a velük közvetlen kapcsolatban dolgozó köztisztviselők érdekében. 2. A közigazgatás szervezetei és a közszolgáltatások háttérrendszerei számára elosztott szolgáltatások

bevezetése a közigazgatás átlátható és hatékony működése érdekében. 3. A közszféra szakmai hozzáértésének (technológia-befogadó képességének, technológiai felkészültségének) növelése a vezetés és a megvalósítás szintjein a közszolgáltatások hatékony nyújtása érdekében. 4. A vállalkozások, az állampolgárok és kiemelten az információs társadalom szempontjából hátrányos helyzetűek e-közigazgatás alkalmazási képességének fejlesztése. Az Informatikai Átfogó Stratégia az elektronikus közszolgáltatások jogszabályi hátteréről szólva tömör, problémakerülő, a Ket. alaprendelkezéseit ismertető értékelést ad. Következtetései szerint a közigazgatás főbb működési gondjainak kezelését és az elektronikus ügyintézés lehetőségének megteremtését szolgálja a Magyarországon 2005 novemberében hatályba lépett, a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló

2004. évi CXL. törvény, melynek rendelkezései – amennyiben az ágazati jogszabályok ezt a lehetőséget nem csorbítják – biztosítják az állampolgárok részére az elektronikus ügyintézés igénybevételének lehetőségét. Az alapvető elektronikus szolgáltatások esetében meghatározott ötödik szint eléréséhez a Ket biztosítja az interoperabilitás és a proaktivitás bizonyos jogi feltételeit, előírja a közigazgatás kezelésében már meglévő adatok felhasználását, külön jogszabályi felhatalmazás alapján lehetővé teszi a közigazgatás számára a proaktív 2009. június 15 153 ügyindítást is.8 Az egységes proaktív szolgáltatói modellek mellett szükséges a folyamatok integrálási lehetőségeinek feltárása, és az esetleges átfedések kiszűrése. Kiemelt cél az ügyféligények által vezérelt folyamatok kialakítása, az ügyféloldali adatszolgáltatás, és az ügyfél részvételének minimalizálása az

ügyintézési folyamatokban, valamint az élethelyzethez, vagy egymáshoz kapcsolódó folyamatok összekapcsolása. A Stratégia más helyütt azonban már azt is érzékelteti, hogy a hatályos szabályozási környezet komoly funkcionális zavarokkal küzd, annak felülvizsgálata, egy új szolgáltatási kultúrát kiszolgálni tudó jogszabályi környezet kialakítása aligha kerülhető meg, az ezzel kapcsolatos pontosabb követelmények a 2008–2010-es évekre vonatkozó E-közigazgatás programban (2008. október 27.) kifejtett, egy-egy átfogó program végrehajtását ütemező, a megvalósulás feltételrendszerét pontosan definiáló követelményrendszeréből vezethetők le. A Ket. megfogalmazza az ügyfélorientált szolgáltató állam alapcéljait Ezen célok elérését az ügyfelek jobb kiszolgálásához, a folyamatok elektronizáltságához, az ügyféloldali ügyintézés egyszerűsítéséhez, a háttérintézmények interoperabilis működésének

kialakításához köti, de az ügyfélközpontú szolgáltatások átfogó programjának megvalósítása érdekében is számos konkrét követelményt fogalmaz meg. E követelmények jelentős része ugyan technológiai természetű, ám azok megvalósítására a jogszabályi környezet változásait, új alapokra helyezését is megköveteli. Az e-közigazgatás keretrendszerét érintő interoperabilitási átfogó program az e-közigazgatás keretrendszerének felülvizsgálatát, a nyilvántartások interoperabilitásának biztosítását jelenti. Az ügyfélközpontú szolgáltatások átfogó programjában kiemelt cél az egyablakos vámügyintézés megvalósítása, a cégbírósági rendszerek korszerűsítése, a civil szervezetek nyilvántartásának, valamint a csőd és felszámolási eljárásoknak a modernizációja, a családtámogatási ellátások folyósításának korszerűsítése, a földhivatali adatok elektronikus non-stop szolgáltató rendszerének, az

anyakönyvi nyilvántartás reformja projektjének megvalósítása. Az on-line infrastruktúra átfogó programjában elsődleges célok az elektronikus fizetés megvalósítása és az elektronikus azonosítás fejlesztése, valamint a Központi Elektronikus Szolgáltató Rendszer bővítése, a kapcsolódó informatikai biztonsági feltételek javítása. Az integrált ügyfélszolgálat átfogó programja a többcsatornás ügyfélszolgálat kialakítására törekszik, de itt kapnak kiemelten fontos szerepet a szolgáltatási irányelv megvalósításával összefüggő feladatok is. Az integrált kormányzati funkciók átfogó programjának első nagy célkitűzése a Központi Gazdálkodási Rendszer, a KGR kiépítése. Hasonlóan jelentős célkitűzés azonban az adóalany-centrikus adatszolgáltatási modell (ACM) megvalósítá8 Stratégia 18–19. o, 54–62 pont 2009. június 15 154 sa, a biztonságos elektronikus összeköttetés lehetővé tétele is. Az

elosztott e-közigazgatási szolgáltatások átfogó programjának keretében kerülne sor az elektronikus levéltár kialakítására, a területi alkalmazási központok (ASPk) kiépítésére. Végezetül a tudásmenedzsment átfogó program a tudásportál megvalósításában és az e-közigazgatási motivációs képzések biztosításában kíván a tárgyidőszakban komoly előrelépést megvalósítani. Mindeme célok megvalósításának egyik legjelentősebb gátját az elektronikus ügyintézésre, elektronikus közszolgáltatások nyújtására vonatkozó – mára már sok szempontból elavultnak tekinthető – jogszabályi környezet, illetőleg annak hiányosságai jelentik. A jogalkotóval szemben ez kettős kihívást támaszt Egyrészt deregulációval, a meglévő párhuzamosságok megszüntetésével, a gyakorlatban alkalmazhatatlannak bizonyult megoldások kiiktatásával el kell bontania a hatékony és ügyfélbarát elektronikus ügyintézés elől a jog

által támasztott akadályokat, másrészt a szükséges mértékben jogi kereteket kell biztosítani a programokban megjelenő új, proaktív, ügyfélbarát, interoperabilitást előmozdító lehetőségek gyakorlati alkalmazásához. E folyamat egyik alapját a Ket. az elektronikus hatósági ügyintézésre vonatkozó szabályait is átfogóan érintő, a 2008 évi CXI törvénnyel történő módosítása, a másikat a Ket. módosításának előkészítésével lényegében párhuzamosan zajló, az elektronikus közszolgáltatásokról szóló új törvény megalkotása jelentheti. E változások (melyek azonban a végrehajtási rendeletek teljes körű revízióját, illetőleg számos új, a ma még szabályozatlan kérdésekre vonatkozó rendelet megalkotását is igénylik) várhatóan 2009 októberétől lépnek majd hatályba. 8.3 Az elektronikus közigazgatás stratégiai jövőképe Az „E-közigazgatás 2010 Stratégia” segítségével az állam a saját

munkafolyamatainak, igazgatási és szolgáltató szervezeti rendszerének hatékonyabb megszervezésével, az elektronikus közigazgatási eszközökön keresztül elérhető közjavak – a lehetőségekhez mérten tértől és időtől független – hozzáférésének biztosításával, továbbá a társadalmi tőke növelésével járul hozzá a tartós, fenntartható fejlődés eléréséhez, és a jobb minőségű munkahelyek megteremtéséhez. A stratégia a közigazgatási fejlesztések egységes elvek alapján, egységes keretrendszerben történő megvalósítását segíti elő A dokumentum célja az volt, hogy átfogja az összes olyan lényegi szempontot és megközelítést, amelyet az intézményeknek saját szolgáltatásaik kialakításánál figyelembe kell venniük, illetve azokat a horizontális és integrációs programokat, ame2009. június 15 155 lyek – a kormányzat egészére vonatkozóan – megalapozzák és elősegítik az e-közigazgatás

rendszerszerű működését. A stratégia összefoglalóan mutatja be az e-közigazgatás jövőképét és a jelenlegi helyzetet, részletesen kifejti a változási hajtóerőket, és meghatározza a jövőkép elérésének stratégiáját is. Annak érdekében, hogy a szolgáltatások az állampolgárok és a vállalkozások igényei köré szerveződjenek, a stratégia öt horizontális és egy ágazati részcélt, illetve ezekhez rendelt programot határoz meg. A felhasználói érdekek fókuszáltabb előtérbe helyezése, valamint a rendszeren belüli valódi hatékonyság megteremtése intézményi érdekeken és működési körön túlnyúló, horizontális megközelítést igényel. A horizontális programok megadják az iránymutatást és azokat az egységes kereteket az intézményi szolgáltatások számára, amelyek mentén azok a szolgáltatás tartalmát, folyamatait és informatikai megvalósítását illetően egységes keretek figyelembevételével fejleszthetők

tovább. Az átfogó programok (interoperabilitási átfogó program, ügyfélközpontú szolgáltatások átfogó program, online infrastruktúra átfogó program, integrált ügyfélszolgálat átfogó program, integrált kormányzati funkciók átfogó program, elosztott e-közigazgatási szolgáltatások átfogó program, tudásmenedzsment átfogó program) önálló célokat tartalmaznak, amelyek elérését az átfogó programban meghatározott akciók támogatják. Az integrált és elosztott kormányzati szolgáltatások körében az Elektronikus Kormányzati Gerinchálózat, az EKG fejlesztésének céljaként a Stratégia célul tűzte ki, hogy a központi kormányzati és közigazgatási szervek mellett a közigazgatás minden szerve részére elérhetővé tegye az EKG szolgáltatásait, és költségtakarékos, hatékony és ellenőrzött módon internet-kapcsolatot biztosítson az elektronikus ügyintézéshez. Magas színvonalú biztonsági rendszer kialakításával

nyújtsa a KR szolgáltatásait az önkormányzatok és más közigazgatási intézmények számára. Mint arra az Informatikai Átfogó Stratégia rámutat, az elmúlt években a tudásalapú szolgáltató állam és az IKT gazdaság hazai kiépítését egymás mellett futó, egymásra építő, de egymással közvetlen kapcsolatban nem álló programok célozták meg. A programok megvalósítása és a megvalósítás terén szerzett tapasztalatok nem kellő mértékben és nem megfelelő módon kerültek megosztásra. Összehangolásra, egyeztetésre – és ebből adódóan a párhuzamosan futó programok közti szinergiák kiaknázására – nem volt lehetőség Tekintettel arra, hogy mindegyik program különböző fókuszú, de egymással összefüggő és egymásra épülő fejlesztést takar, a tervezés és a megvalósítás koordinációjának hiánya mindegyik egyedi programra nézve előnytelen.9 A változtatás lehetőségét teremtette meg a 26/2008. (V 14) ME határo9

Informatikai átfogó Stratégia, Vezetői összefoglaló 2009. június 15 156 zat és a 4/2008 ME utasítás, melynek értelmében az infokommunikáció és eközigazgatás szakterületek azonos intézményi kereten belül, közös irányítással működnek tovább. Az EKG a KR alapelemeként biztosítja a központi közigazgatás számára a KR szolgáltatásainak elérését, egyben az EU-s informatikai rendszerek (például TESTA) és a hazai informatikai rendszerek közötti kapcsolat kizárólagos infrastruktúrája. A központi közigazgatás részére biztosítja a védett szolgáltatások nyújtását és elérhetőségét. Az EKG díjtalan alapszolgáltatásokat (IP, DNS, levelezés, EU-kapcsolat, internet) és költségtérítéses, emelt szintű szolgáltatásokat (VoIP, videokonferencia stb.) biztosít a felhasználók részére. Az EKG biztonságos üzemeltetése érdekében ki kell építeni a területi kapcsolatok és központi elemek redundanciáját.

Stratégiai cél, hogy bővíteni kell a rendszeren elérhető szolgáltatásokat. A területi informatikai szolgáltató központok kiépülésével párhuzamosan szükséges a szolgáltatások redundanciájának megtervezése, a környezet kialakítása, és a hálózati és IT elemek beszerzése, telepítése és konfigurálása. Az informatika, információtechnológia és a távközlés fejlődésével, a rendszerek egyre nagyobb számban történő alkalmazásba vételével párhuzamosan egyre nagyobb jelentőségűvé válik a biztonsági szempontok érvényesítése. A tárolt és kezelt adatok, információk egyre nagyobb mértékben tartalmaznak érzékeny, a személyiségi jog vagy más jogszabály rendelkezése által védett információkat. A közigazgatási ügyeket intéző hivatalok egyre nagyobb mértékben támaszkodnak az elektronikusan tárolt és kezelt információkra, és egyre inkább csak elektronikusan lesz majd elérhető az információ, ami egyben

függést is jelent az elektronikus információk rendelkezésre állásától. A korábbi években – elsősorban költségvetési okok miatt – a biztonsági kérdések háttérbe szorultak. A legszükségesebb védelmi intézkedések (vírusvédelem, mentések) mellett a közigazgatásban általában kevés figyelmet fordítottak az informatikai biztonság többi tényezőjére. A KR biztonságának megfelelő szintű garantálása szükségessé teszi mind a KR, mind a csatlakozó ágazati rendszerek tekintetében a központi menedzsment, üzemeltetési és műszaki intézkedések bevezetését. A Stratégia itt hármas célt tűzött ki. Az első a közigazgatás egészére érvényes „Közigazgatási informatikai biztonságpolitika” című dokumentum kidolgozása, a második olyan informatikai biztonsági mintaszabályzat kiadása, amely útmutatást nyújt a közigazgatás intézményei számára saját biztonsági szabályzatuk megalkotásához, végezetül a harmadik

olyan informatikai biztonsági központ kialakítása, amely támogatást nyújt a közigazgatási intézmények számára a támadások elleni felkészülésre, gyakorlati tanácsokat ad, és konkrét eljárásokat dolgoz ki a védelem lehetséges proaktív megoldásaira, valamint segítséget nyújt a támadások okozta károk felszámolásában, a 2009. június 15 157 veszteségek minimalizálásában. E követelmények alkalmazását az informatikai biztonság megújuló jogszabályi követelményrendszere hivatott elsősorban biztosítani.10 A központi online ügyintézés körében a teljes körű elektronikus ügyintézés infrastruktúrájának megteremtése érdekében a Kormány célul tűzi ki az e-fizetés infrastruktúrájának, alkalmazásának, valamint a fokozott biztonsági követelményeket kielégítő állampolgári azonosító eszközrendszernek a megvalósítását. A rendszer kiépülésével megteremtődnek az állampolgári és vállalkozási

e-ügyintézés költséghatékony és ügyfélbarát infrastrukturális feltételei. A rendszer továbbfejlesztésének kiemelt szempontja a biztonság és az állampolgári bizalom megtartása.11 Az integrált ügyfélszolgálati hálózat kiépítésének fő célja, hogy a többcsatornás ügyfélszolgálat megvalósítása érdekében a kormány az elkövetkező években országos lefedettséggel kiépítse integrált ügyfélszolgálati hálózatát. Az ügyfélszolgálati központok az állampolgárok jobb kiszolgálásának, az állampolgárok fokozottabb bevonásának és az elektronikus ügyintézés támogatásának céljával személyes és telefonos ügyintézési lehetőséget nyújtanak, hozzáférést biztosítanak az elektronikus ügyintézés eszközrendszeréhez, valamint az esélyegyenlőség biztosítása érdekében támogatást adnak egyes élethelyzetekben előállt probléma, vagy feladat megoldásához. Az állampolgárok ügyeik gyors és egyszerű

megoldását várják el a modern közigazgatástól. Kevésbé fontos számukra az ügyek egyes közintézmények közti felosztásának és az ügyintézési lehetőségek típusainak megértése. A szolgáltatások egyszerű működését várják el, megfelelően informatív belépési pontokat, és probléma esetén szakszerű, több csatornás támogatást és iránymutatást. A hagyományos ügyintézés jellemzően a különböző nyomtatványok kitöltésén és az állampolgárok személyes megjelenésén alapult. Az eKS keretében az online ügyintézés lehetőségének megteremtése mellett elindult a kormányzati ügyfélszolgálat és ügyfél-tájékoztatás fejlesztése is. Jelenleg az állampolgárokkal való kapcsolattartáshoz kötődő feladatok egymástól elkülönülten valósulnak meg a hazai közigazgatás egyes intézményeinél, csak kezdeti fázisban tart az integráció. Személyes ügyfélkapcsolatot az okmányirodák, ágazati és önkormányzati

ügyfélszolgálatok nyújtanak. Központi, telefonra alapozott ügyfélszolgálatot a központi közigazgatás hatáskörébe tartozó ügyek esetén a kormányzati ügyfél-tájékoztató központ, a KÜK biztosít. Mellette több ágazati és önkormányzati Call Center is részt vesz a telefonos tájékoztatásban, illetve az ágazati Call Centerek egy része már a KÜK működésével integráltan, azt szakmailag kiegészítve működik. A stratégiai cél egy olyan integrált 10 11 E-Közigazgatás 2010 Stratégia, 32–33. o E-Közigazgatás 2010 Stratégia, 33–34. o 2009. június 15 158 közigazgatási ügyfélszolgálati hálózat kiépítése, mely az állampolgárok számára a különböző élethelyzetekből adódó problémák, ügyek megoldásához a személyes, telefonos és webes ügyfélszolgálatot összehangoltan nyújtja. Az ügyfélszolgálat célja, hogy minden állampolgár, civil szervezet és vállalkozás a létrehozott tudásbázis lehetőségeit

kihasználva vehesse igénybe a közigazgatás szolgáltatásait, felkészültségtől, technikai körülményeitől függetlenül. Ezt a lehetőséget az állampolgárok számára az eMagyarország Pontok és más közösségi hozzáférési helyek hálózatán keresztül is lehet biztosítani, mint decentralizált Front Office hálózaton, ahol egységes színvonalon, minőségbiztosítottan elérhetők az e-szolgáltatások, valamint a szakképzett eTanácsadók segítségével biztosított a szolgáltatások egyenlő esélyű használata. Az ügyfélszolgálat az ügyfelek előzetes felkészítésével, a releváns szolgáltatások kiválasztásával az ügyindításban, az ügyintézésben nyújtott támogatással javítsa a közigazgatási szolgáltatások hatékonyságát Kiemelt cél, hogy, az ügyfélszolgálati munka járuljon hozzá az állampolgárok és vállalkozások e-közigazgatás alkalmazási képességeinek javításához, valamint az információs társadalom

szempontjából hátrányos helyzetben levők e-közigazgatás alkalmazási esélyegyenlőségének kialakításához (elsősorban a szakképzett eTanácsadói személyes szolgáltatás biztosításával).12 Az integrált kormányzati funkcionális rendszerek kiépítésének célja az átlátható és hatékony kormányzat kialakítása, a belső kormányzati működés integrált alapjainak megteremtése, a pénzügyi és a személyzeti gazdálkodás, illetve a dokumentummenedzsment terén. A Költségvetési Gazdálkodási Rendszer, KGR legfontosabb feladata a pénzforgalommal és a gazdálkodással kapcsolatos feladatoknak egy szervezetbe, a Magyar Államkincstárba való koncentrálása. A központi igazgatás személyügyi reformját szolgáló Kormányzati Személyügyi Szolgáltató és Közigazgatási Képzési Központ (MeH KSZK) kialakításának fő célja a stratégiai humánerőforrás-gazdálkodás szervezeti és szakmai kereteinek, tartalmainak kialakítása, a

teljesítménymérés és teljesítménynövelés megvalósítása, a kultúraváltás elősegítése, valamint a komplex közigazgatási átalakulási folyamat változáskezelése. A KGR program legfontosabb célja, hogy az államháztartási reformok keretében megfogalmazott célok eléréséhez, a korszerű szolgáltató típusú állam elvárásainak teljesítéséhez az elmúlt évek tapasztalatainak figyelembevételével, azok eredményeire építve, a kincstári folyamatok reorganizációjával, valamennyi – a költségvetés végrehajtásához kapcsolódó – folyamat korszerűsítésének az eredményeire építő, a folyamatot támogató, azokat egységes keretben kezelő, a legmodernebb infokommunikációs technológiát felhasználó, integrált, on-line rendszert alakítson ki. A kialakított rendszer azon túl, 12 E-Közigazgatás 2010 Stratégia, 34–36. o 2009. június 15 159 hogy az integráció és az elektronizálás révén növeli a működési

hatékonyságot, és naprakész információt nyújt a pénzügyi kormányzat számára, lehetővé teszi a közpénzek és az EU fejlesztési források felhasználásának nyomonkövetését is.13 A minisztériumi humánpolitikai szervezeti egységekben a munkavégzés arányát tekintve jelenleg az adminisztratív jellegű feladatok dominálnak, és az időráfordítás legnagyobb részét is az ilyen jellegű feladatok teszik ki, még a stratégiai jellegű folyamatok esetében (például oktatás, képzés) is. Alapvetően hiányzik a hatékony adminisztratív támogatás ahhoz, hogy a minisztériumi humánpolitikai területek a kívánt arányban tudják idejüket megosztani a stratégiai és végrehajtási jellegű feladatok között. Az adminisztratív munkát, az időráfordítást növeli, illetve az átláthatóságot csökkenti az egységes informatikai háttér, adatbázisok hiánya. A közigazgatási szervezetrendszer átalakításának és új intézményi struktúrák

kialakításának a jogszabályi kereteit a 1054/2006. (V 26) Korm határozat és a 2118/2006 (VI 30) Korm határozat adja meg Előbbi c) pontja előírja, hogy a közigazgatás hatékonyabb rendszerének kialakítását szolgáló intézkedések további megalapozása érdekében készüljön javaslat a Kormány részére a Kormányzati Személyügyi Szolgáltató és Közigazgatási Képzési Központ (KSZK) kialakítására. A KSZK létrehozásával járó legfontosabb előnyök a következők: magasabb minőségű szolgáltatások, egyszerűbb, átlátható eljárások, tiszta felelősségi rend, gyorsabb és pontosabb végrehajtás.14 Az elosztott e-közigazgatási szolgáltatások kiépítésének célja, hogy mind a központi, mind az önkormányzati intézményeknél egységes és hatékony módon kiépüljenek az intézmények belső elektronikus működését támogató szolgáltatások. Ezen belül a központi kormányzat számára a cél egy olyan egységes

dokumentumkezelő rendszer kialakítása és alkalmazása, amely megteremti a kormányzaton belüli szabványos kommunikáció, egymás közötti átjárhatóság és interoperabilitás alapját Az önkormányzatok, illetve a központi, területi államigazgatási szervek számára a cél olyan alkalmazás-szolgáltató központok (ASP-k) kialakítása, amelyek az informatikai rendszereket központilag üzemeltetve hatékonyan és jó minőségben képesek az egyes önkormányzatok számára a működésükhöz szükséges informatikai szolgáltatásokat biztosítani.15 Az egyes átfogó programok önálló célokat tartalmaznak, amelyek elérését meghatározott akciók támogatják 13 E-Közigazgatás 2010 Stratégia, 36–37. o E-Közigazgatás 2010 Stratégia, 37–38. o 15 E-Közigazgatás 2010 Stratégia, 38–40. o 14 2009. június 15 160 8.4 Az eKS megvalósítását célzó programrendszer Az E-közigazgatás 2010 Stratégia és Programterv, eKS világos fejlesztési

célokat határoz meg az elektronikus közigazgatás számára az elkövetkezendő két évre vonatkozóan. Az eKS stratégiai koncepciója alapján került összeállításra az Átfogó Programokat meghatározó E-közigazgatási Mátrix (eKM), amely az elérni kívánt kompetenciák, és az átalakulás által érintett területek alapján hét átfogó programot azonosít. Az Interoperabilitási Átfogó Program hátterét az e-Közigazgatás Stratégia 2010-ben megfogalmazott azon célkitűzés megvalósításának szándéka képezi, mely szerint az egységes proaktív szolgáltatói modellek mellett a folyamatok integrálási lehetőségeinek feltárása, és az esetleges átfedések kiszűrése is szükséges. Ezen belül kiemelt cél az ügyféligények által vezérelt folyamatok kialakítása, az ügyféloldali adatszolgáltatás és az ügyfél részvételének minimalizálása az ügyintézési folyamatokban, valamint az élethelyzethez, vagy egymáshoz kapcsolódó

folyamatok összekapcsolása. A Ket. megfogalmazza az ügyfélorientált szolgáltató állam alapcéljait Ezen célok elérését az ügyfelek jobb kiszolgálásához, a folyamatok elektronizáltságához, az ügyféloldali ügyintézés egyszerűsítéséhez, a háttérintézmények interoperabilis működésének kialakításához köti. A gyakorlati megvalósítás a háttérintézményi rendszerek standardizációját és az interoperabilis kapcsolatok megteremtését illetően még az első lépéseknél tart. A felhasználói érdekek fókuszáltabb előtérbe helyezése, valamint a rendszeren belüli valódi hatékonyság megteremtése, intézményi érdekeken és működési körön túlnyúló, horizontális megközelítést igényel. Ilyen horizontális fejlesztésekre van szükség annak érdekében, hogy a klasszikus ügyintézési hagyományok fejlődjenek, és növekedjen a közigazgatáson belül az együttműködés, az intézmények közti hatékony kommunikáció az

ügyfelek jobb kiszolgálása érdekében. Az Interoperabilitási Átfogó Program keretében kialakított akciócsomag fő célja, hogy a Kormány megtegye az első lépéseket az informatikai standardizáció és az adatok interoperabilitásának megteremtésében. Az Interoperabilitási Átfogó Program az E-közigazgatási keretrendszer és szolgáltatási folyamatok egyszerűsítése és a nyilvántartások interoperabilitása projektjeire épül. 2003 óta az EU 20 szolgáltatása terén folyó fejlesztések eredményeként minden szolgáltatási területen történt előrelépés a szolgáltatások elektronizáltságának fokozásában. Jelentős különbségek vannak azonban az egyes szolgáltatás-csoportokban elért elektronizáltsági szinteket, és az állampolgár 2009. június 15 161 által elektronikusan intézhető eljárási cselekményeket tekintve. Kedvező tapasztalat, hogy azokon a területeken – mint például a személyi jövedelemadóbevallás –, ahol a

szolgáltatások elektronizálása mellett az intézmény proaktívan éri el az ügyfeleket, lényegesen nagyobb az elektronikus ügyintézésbe bevont ügyfelek aránya. Az Ügyfélközpontú Szolgáltatások Átfogó Program fő fejlesztési feladata a leggyakrabban keresett EU 20 szolgáltatás teljes körű elektronizáltságának megteremtése. A fejlesztések során ugyanakkor az új kihívásoknak megfelelően nagy hangsúlyt kap a személyre szabott, személyre szóló proaktív megközelítés kialakítása is. A program keretében az egyablakos vámügyintézés megvalósítása, a cégbírósági rendszerek korszerűsítése, a civil szervezetek nyilvántartásának, valamint a csőd- és felszámolási eljárások modernizációja, a családtámogatási ellátások folyósításának korszerűsítése, a földhivatali adatok elektronikus non-stop szolgáltató rendszere és az anyakönyvi nyilvántartás reformja projekt megvalósítása várható. Ebben a körben az

egyes, már bevezetésre került eljárásokhoz (például cégeljárás) szükséges nyomtatványok lekérése csak Windows operációs rendszer alól megy, és egy ideig a Vista használata sem volt megoldott. A negyedik szofisztikációs szintű szolgáltatások megvalósítása, valamint az informatika előnyeinek, hatékonyságának kihasználása érdekében szükséges a központi online ügyintézés fejlesztése, az e-fizetés és az állampolgári kártya bevezetése. A szolgáltatások nyújtásában részt vevő, vagy azokat alkalmazó közigazgatási intézmények részére biztosítani kell a biztonságos és nagy kapacitású gerinchálózatot. E cél megvalósítását kívánja előmozdítani az Online Infrastruktúra Átfogó Program, mely az EKG fejlesztésével és a központi online ügyintézés elemeinek bővítésével biztosítja a közigazgatás belső működésének hatékonyság javulását, valamint az e-közigazgatási szolgáltatások fejlesztésének

infrastruktúráját. A stratégiai célkitűzés szerint olyan egységesen szabályozott állampolgári közmű rendszer kialakítására van szükség, ahol konzisztens módon valósul meg a szereplők hitelesítése, a rendszerben kezelt, tárolt adatok, információk és dokumentumok bizalmassága, a végzett műveletek letagadhatatlansága. Általános célú azonosító eszköz bevezetése csak középtávon látszik reális célnak. Az elektronikus rendszer kiépülésével megteremtődnek az állampolgári és vállalkozási szolgáltatások ügyintézésének költséghatékony és ügyfélbarát infrastrukturális feltételei. Az Online Infrastruktúra Átfogó Program az elektronikus fizetés megvalósítása, az elektronikus azonosítás fejlesztése, a Központi Elektronikus Szolgáltató Rendszer bővítése, valamint a Központi Rendszerhez kapcsolódó Informatikai Biztonsági Központ (IBK) továbbfejlesztése (PAJZS) projektjeire épül. Az állampolgárok ügyeik

gyors és egyszerű megoldását várják el a modern közigazgatástól. Kevésbé fontos számukra az ügyek egyes közintézmények közti felosztásának és az ügyintézési lehetőségek típusainak megértése 2009. június 15 162 A szolgáltatások egyszerű működését várják el, megfelelően informatív belépési pontokat, és probléma esetén szakszerű, többcsatornás támogatást és iránymutatást. A hagyományos ügyintézés jellemzően a különböző nyomtatványok kitöltésén és az állampolgárok személyes megjelenésén alapul Jelenleg az állampolgárokkal való kapcsolattartáshoz kötődő feladatok egymástól elkülönülten valósulnak meg a hazai közigazgatás egyes intézményeinél, csak kezdeti fázisban tart az integráció. Az Integrált Ügyfélszolgálat Átfogó Program megalapozásához hozzájárulnak az EU által az i2010 program keretében – az elektronikus szolgáltatások kiépítésével kapcsolatban – megfogalmazott

alapelvárások, az esélyegyenlőség biztosítása és az ügyfelek minél nagyobb arányú bevonása. Ezen elvárások teljesítéséhez az elektronikus szolgáltatás igénybevétele előtt kapcsolatba kell kerülni a potenciális felhasználókkal és segíteni kell számukra, hogy „eltaláljanak” a releváns szolgáltatásokig. Az Átfogó Program célja olyan integrált közigazgatási ügyfélszolgálati hálózat kiépítése, mely az állampolgárok számára a különböző élethelyzetekből adódó problémák, ügyek megoldásához a személyes, telefonos és webes ügyfélszolgálatot összehangoltan nyújtja. Az ügyfélszolgálat kialakításának fontos szempontja, hogy minden állampolgár, civil szervezet és vállalkozás a létrehozott tudásbázis lehetőségeit kihasználva vehesse igénybe a közigazgatás szolgáltatásait, felkészültségétől, technikai körülményeitől függetlenül, valamint az ügyfélszolgálat az ügyfelek előzetes

felkészítésével, a releváns szolgáltatások kiválasztásával, az ügyindításban, az ügyintézésben nyújtott támogatással javítsa a közigazgatási szolgáltatások hatékonyságát. Az Integrált Ügyfélszolgálat Átfogó Program a többcsatornás ügyfélszolgálat kialakítása és a szolgáltatási irányelv megvalósítása projektjeire épül. Megvalósítására – az EKOP finanszírozási kereteken belül – 2008–2010 között 4300 mFt áll rendelkezésre.16 Jelenleg a közigazgatási működés több területén a belső információs rendszerek tartalmilag és technológiailag is elavultak, nem teszik átláthatóvá és eredményeiben értékelhetővé az egyes közigazgatási ágazatok, az intézmények és a tisztviselők feladatainak végrehajtását, az egyes szolgáltatások megvalósulásának hatékonyságát. Általában nem léteznek valós idejű online kapcsolatok az intézmények között Az államreform ÚMFT-ben megfogalmazott és az

eKS-ben megerősített célja szerint „a közigazgatással szembeni alapvető elvárás, hogy az eredményesség kerüljön a tevékenység középpontjába”. A fentiek szerint a Programterv fontos eleme a nagyobb – a közigazgatás belső funkcionális működését biztosító – rendszerek újragondolása, és integrált, központi online rendszerek kialakítása. Az Integrált Kormányzati Funkciók Átfogó Program keretében a belső kormányzati működés integrált alapjai16 E-Közigazgatás Program 2008–2010, 24–26. o 2009. június 15 163 nak megteremtése várható a pénzügyi gazdálkodás, a jogalkotás és a kiemelt adatszolgáltatási területeken. A Program eredményeként várhatóan lerövidül a belső folyamatok lebonyolítási ideje, az on-line rendszer adta lehetőségek alkalmazásával nagy mennyiségű papírbizonylat kiváltására kerül sor, és felgyorsul az információszolgáltatás és az intézményi kommunikáció. A Program a

Központi Gazdálkodási Rendszer (KGR) kiépítését, az adóalany-centrikus adatszolgáltatási modell (ACM) és a biztonságos elektronikus összeköttetés kialakítását célozza. Az e-Közigazgatás 2010 Stratégia egyik alapvető tézise szerint az elosztott e-közigazgatási szolgáltatások kiépítésének célja, hogy mind a központi, mind az önkormányzati intézményeknél egységes és hatékony módon kiépüljenek az intézmények belső elektronikus működését támogató szolgáltatások. Ezen belül a központi kormányzat számára a cél egy olyan egységes dokumentumkezelő rendszer kialakítása és alkalmazása, amely megteremti a kormányzaton belüli szabványos kommunikáció, egymás közötti átjárhatóság és interoperabilitás alapját. Az önkormányzatok, illetve a központi, területi államigazgatási szervek számára a cél olyan alkalmazás-szolgáltató központok (ASP-k) kialakítása, amelyek az informatikai rendszereket központilag

üzemeltetve hatékonyan és jó minőségben képesek az egyes önkormányzatok számára a működésükhöz szükséges informatikai szolgáltatásokat biztosítani. Az Elosztott e-Közigazgatási Szolgáltatások Átfogó Program e célokhoz kötődően két fő területen tartalmaz fejlesztéseket. Az egyik terület a maradandó értékű elektronikus iratok megőrzése, kezelése és hozzáférésük biztosítása, mely jelenleg nem megoldott. Ezt a hiányt oldja meg a program eredményeképpen kialakuló elektronikus levéltári rendszer, amely elősegíti az e-levéltári szolgáltatást igénybe venni kívánó állampolgár/közigazgatási szerv, és a tényleges szolgáltatást nyújtó e-levéltár közötti adat- és szolgáltatás-áramlást. Az informatika által generált e-közigazgatási változások megvalósításához nélkülözhetetlen a szakmai hozzáértés folyamatos bővítése. A technikai fejlesztések sikere nagy mértékben múlik azon, hogy az

e-közigazgatási kultúra, képességek és tudás mennyiben épül be a szervezetek és a köztisztviselők napi gyakorlatába. A tudás összegyűjtésének, rendszerezésének és terjesztésének jelenleg nincs hatékony eszköze. A Tudásmenedzsment Átfogó Program ezt a hiányt pótolja. A projekt hatékony eszköz mind a stratégiai tervezéshez és koordinációhoz, mind a végrehajtáshoz szükséges tudásháttér és kompetenciák biztosításához. A program szinte valamennyi kormányzati informatikai projekt megvalósulását támogatja, tudáshátteret nyújt, és megjelenési felületet is biztosít az informatikai fejlesztések eredményeinek disszeminálásához. A tudásmenedzsment célja, hogy a közigazgatás széles köre számára az elektronikus működéshez és az ügyfélközpontú szolgáltatások kialakításához szük2009. június 15 164 séges alapvető képességek és kultúra kiépüljön a központi kormányzatban és a regionális és lokális

önkormányzati szinteken. A tudásmenedzsment számos feladatot ölel át. Ezek közül a legfontosabbak a kormányzati informatikai szakemberek számára folyamatos kommunikációs program kialakítása, a hálózatépítés, mentorálás, motiváció, a hiányzó kompetenciák kiépítésében a vezetői képzések megvalósítása, az eközigazgatási szolgáltatások nyújtásában közreműködő humánerőforrás fejlesztése, ismereteik bővítése, kompetenciafejlesztés, a bevált gyakorlatok megosztása, valamint a technológiai standardizáció támogatása minősül. A Program eredményeként a közigazgatás modernizációjának és az eközigazgatás fejlesztésének támogatására, az érintett intézmények együttműködéshez szükséges tudásszintjének biztosítására létrejön és folyamatosan bővül az e-közigazgatás tudásbázisa. A tudásbázis biztosítja, hogy a fejlesztések tervezésekor, az intézményi stratégiák kialakításakor az érintettek

figyelembe vehessék a már működő szolgáltatásokat, alkalmazhassák az elért eredményeket. Így mind a közigazgatási szféra érintettjei, mind a magánszemélyek és a vállalkozások könnyen és gyorsan juthatnak megbízható információhoz. A Tudásmenedzsment Átfogó Program a Tudásportál, illetőleg az e-közigazgatási motivációs képzések projektjeire épül. A stratégiai célok professzionális megvalósításához szoros ütemterv, irányított és ellenőrzött projektmenedzsment, projekt- és beszállítói szabványok kialakítása, a stratégiai irányítás és a programmenedzsment megszervezése, az IT-tudásmenedzsment kialakítása, mindenekelőtt azonban rögzített (és számonkérhető) ütemterv kialakítása szükséges. A végrehajtás stratégiai irányítását alapvetően a Miniszterelnöki Hivatalt vezető miniszter látja el, aki az informatikáért való felelőssége körében előkészíti az információs társadalom

kiteljesedéséhez, valamint az infokommunikációs szektor fejlesztéséhez kapcsolódó stratégiákat, továbbá gondoskodik az azokhoz kapcsolódó programok végrehajtásáról. A kormánybiztos feladata az információs társadalommal összefüggő kormányzati tevékenység irányítása, mely magába foglalja a szolgáltató állam kialakításához szükséges közigazgatási informatika stratégiájának előkészítését, és a stratégia végrehajtásának összehangolását is. Az e-közigazgatási stratégia kialakítása és a végrehajtáshoz szükséges feltételek megteremtésének kezdeményezése is az informatikáért felelős kormánybiztos feladata. Annak érdekében, hogy a stratégiában lefektetett jövőkép és a stratégiai programok hatékony menedzselése, megvalósítása, illetve kommunikációja megvalósuljon, az egész közigazgatásra kiterjedő koherens irányításra van szükség a megvalósítás minden szintjén. 2009. június 15 165 8.5

Az e-közigazgatási keretrendszer és a nyílt rendszereken alapuló interoperabilitás megteremtésének követelménye Az E-közigazgatás 2010 Stratégia abból indul ki, hogy az i2010 az interoperabilitást az egységes európai információs térség kialakításához szükséges négy fő feladat egyikeként említi, és az IKT-alapú közszolgáltatások elengedhetetlen feltételének tartja. Az interoperabilitás technikai szintjén közzé kell tenni, és folyamatosan aktualizálni kell egy olyan szabványkatalógust, amely megfelel a releváns EU szabványoknak. Ebben nagy hangsúlyt kell fektetni a nyílt szabványok elterjesztésére a közszolgáltatásban Az egységesítést igénylő, de nemzetközi vagy hazai szinten még nem szabványosított technikai megoldásokra ajánlásokat, szabványokat kell kidolgozni, illetve a már meglévőket szükség esetén aktualizálni.17 Az Informatikai Átfogó Stratégia szerint a közigazgatási informatika többsége a múltban

általában egymástól elszigetelt fejlesztések eredményeként jött létre. A jövőbeni fejlesztések hatékonyabb megvalósítása és az egyes rendszerek közötti automatizált együttműködés kialakítása érdekében a kormány szükségesnek tartja a jövőbeni informatikai fejlesztések egységes alapokon történő megvalósítását, ehhez a megfelelő szabályozó rendszer előkészítését. Ennek érdekében szükséges egységes és szabványos informatikai rendszerek alkalmazásának bevezetése, illetve újabb, szabvány értékű előírások kidolgozása és alkalmazása a közigazgatásban. Az IKT szabványosítás elsődlegesen az európai (CEN, CENELEC és ETSI) és nemzetközi (ISO) szabványok bevezetésével biztosítja a lehetőséget az interoperabilitás hálózati, szolgáltatási és alkalmazási szinteken történő megvalósításához. Az e-közigazgatási stratégia és program18 , valamint az IÁF szerint javasolt e-közigazgatási keretrendszer

projekt fontos lépés abban, hogy lehetővé tegye Magyarország csatlakozását az IDABC program keretében meghatározott szabványosítási cselekvési tervhez, melynek célja az e-kormányzati szolgáltatások szabványokon, nyílt rendszereken alapuló pán-európai interoperabilitásának megvalósítása. A projekt fő célja az interoperabilis és biztonságos e-közigazgatási rendszer létrehozásához minimálisan szükséges szabványok és követelmények meghatározása, és a betartatásukhoz szükséges koordináció és ellenőrzés biztosítása. A projekt eredményeként az IÁF 20 új szabvány ki- 17 18 E-Közigazgatás Program 2008–2010, 29–30. o E-Közigazgatás Program 2008–2010, 5–8. o 2009. június 15 166 alakításával, és a témában készülő legalább 100 új publikációval, valamint legalább 4 új fejlesztési keretrendszerrel számolt.19 Az e-közigazgatási keretrendszer szempontjából alapvető fontosságú dokumentum a BME – IK

által szakmailag előkészített Magyar E-Közigazgatási Architektúra20 (a továbbiakban MEKKA 2009). A MEKKA 2009 célja, hogy megadja a magyar e-közigazgatási architektúra leírását, amelynek alapján a jelentősebb fejlesztések tervezhetők. A dokumentum az e-közigazgatás szereplőinek kapcsolódási rendszerét, az e-közigazgatási rendszer tipikus komponenseit, az ügyfelek és szolgáltatók kapcsolódási módjait, az egységes kapcsolatrendszert biztosító e-közigazgatási szolgáltatási sín csatlakozási felületének leírását, a csatlakozás adminisztratív feltételeit tárgyalja. A MEKKA 2009 kiindulási pontját annak felismerése képezi, hogy a magyar közigazgatás kialakult struktúrájában – a világban nem egyedülállóan – a szakrendszerek (minisztériumok, jelentősebb háttérintézmények stb.) nagy önállósággal működnek, így fejlesztéseiket is önállóan bonyolítják.21 Az integrált back-office kialakításához azonban

szükségessé vált a fejlesztési követelmények egységesítése és annak az architektúrának a kidolgozása, amely biztosítani tudja a szakrendszerek önállóságának megtartása mellett azok zökkenőmentes együttműködését.22 Az architektúra tervezésekor figyelembe vették a technológiai lehetőségeket és az e-kormányzati fejlesztések nemzetközi trendjeit. Ezek alapján választották a szolgáltatás-orientált architektúrát és a szolgáltatási sín kialakítását. Ezek a nemzetközi irodalom Service Oriented Architecture (SOA) és Enterprise Service Bus (ESB) fogalmainak mintáját követik. Az architektúra alapján végzett fejlesztésekhez számos szállító kínál szoftver-csomagokat. Az egyes szállítók SOA és ESB modelljei azonban jelentősen eltérhetnek egymástól, így a különböző SOA és ESB csomagok együttműködése sem triviális. Az architektúra kidolgozása során az informatikai szakemberek kísérleteket végeztek

különböző SOA és ESB csomagokkal. Az architektúra megtervezésekor lényeges szempontnak számított, hogy az jól elkülönített, nyílt szabványokon alapuló rétegeket definiáljon, gyártófüggetlenek és igény esetén lecserélhetők, s akár egy későbbi, új technológia bevezetésekor a rétegek lépésről lépésre kiválthatók legyenek.23 Az architektúra részét képező, a rajta keresztül küldött üzenet egyszer, és csakis egyszer történő kézbesítését biztosítani tudó szol19 Az időközben közzétételre került dokumentum-csomag egységes elérhetőséget a http://kovetelmenytar.complexhu/ biztosítja 20 Letölthető: http://kovetelmenytar.complexhu/docphp?docid=EKZ EKK EKOZIG MAGYAR KO−ZIG RENDSZER ARCHITEKTURA 081203 V3.DOC&docdb=koz 21 Ezt igazolja a most lefolytatott felmérés is. 22 MEKKA 2009, 9. o 23 MEKKA 2009, 27. o 2009. június 15 167 gáltatási sínre kapcsolódó szakrendszerek is nyílt szabványok szerint

definiálják az általuk nyújtott szolgáltatásokat, és a szolgáltatások igénybevételéhez szükséges üzeneteket (adatszerkezeteket).24 A nyílt szabványok használatának e-kormányzati politika szintjére emelt alkalmazási követelménye természetesen nem azonos a nyílt forráskódú szoftverekre épülő alkalmazásokra való áttérés iránti elkötelezettséggel. Jelzi azonban a kormányzati elkötelezettséget, a korábbi gyakorlat változásának lehetőségét és irányát25 8.6 A MITS igazságügyi részstratégiája és a ténylegesen megvalósult fejlesztések A 2003-ban elfogadott MITS keretei között az Igazságügyi Minisztérium ösztönözni kívánta az információs és kommunikációs technológiák széles körű felhasználását, valamint új technológiai megoldások kifejlesztését. Megfelelő ellenőrzési, szabályozási és szabványosítási intézmények segítségével pedig biztosítani a piaci verseny megteremtését és

fenntartását. Ehhez kapcsolódva az igazságügyi részstratégia kiemelt jelentőségű, hiszen az információs társadalom elterjedésének és működésének alapfeltétele a megfelelő jogi környezet kialakítása. Az elektronikus kormányzás az információs társadalom kívánalmainak megfelelő, a közigazgatási szervek és magánszemélyek, szervezetek közötti, 24 MEKKA 2009, 34. o Az e-közigazgatás vonatkozásában elkészült Fejlesztési útmutató és menetrend (a továbbiakban roadmap) ugyancsak az architektúráról szólva a nyílt szabványok és specifikációk alkalmazását alapvető követelményként jelöli meg. A szakrendszerekben működő informatikai rendszerek különböző platformokon épülhetnek fel Ezen heterogén rendszer elemeinek összekapcsolásához gyártófüggetlen, nyílt, lehetőleg elterjedten alkalmazott, szabványokon alapuló megoldásokra kell építeni Ez a megoldás csökkenti a szállítófüggőséget, a gyártóknak való

kiszolgáltatottságot. Egyben biztosítja a rugalmas továbbfejleszthetőséget és a szállítói verseny lehetőségét (Roadmap, 18–19. o) 25 Ezt a változást legmarkánsabban a Közbeszerzési Értesítő 2009. április 20-i számában megjelent, a közigazgatási szoftverlicencek beszerzésére vonatkozó tender mutatja, melynek értelmében a hazai költségvetési, valamint a köz- és felsőoktatási intézmények 6 milliárd forint értékben először pályázhatnak nyílt forráskódú szoftverek beszerzésére. A nyílt szabványokon keresztüli teljes együttműködést biztosító közigazgatási szoftver beszerzése 4 milliárd forint keretösszeg, a nyílt szabványokon keresztüli teljes együttműködést biztosító, oktatási szoftverlicencek keretszerződésére 2 milliárd forint fordítható. Ugyanezen tender a Microsoft, illetve Novell (vagy azzal egyenértékű) szoftverek beszerzésére 18 milliárd forintos összegben biztosít lehetőséget. 2009.

június 15 168 gyors és költségkímélő államigazgatási eljárások megvalósítását jelenti, amely távollévők között megfelelő informatikai biztonsággal valósítható meg. Ehhez kapcsolódóan az elektronikus demokrácia megteremtésének alapja, hogy a közigazgatás mellett az igazságszolgáltatási szerveknek is be kell kapcsolódniuk az információs társadalom által kívánt és kínált szolgáltatások nyújtásába. Az igazságügyi részstratégia megvalósulásának feltételrendszereként az IM a megfelelő jogszabályok megalkotását, módosítását, az anyagi erőforrások biztosítását, a résztvevők (közigazgatási, igazságszolgáltatási szervek munkatársai, magánszemélyek, jogi személyek és jogi személyiség nélküli gazdasági társaságok, civil szervezetek) hozzáállásának, az infokommunikációs eszközök használatával összefüggő képzettségének javítását, a kompetencia növelését jelölte meg. További,

alapvető cél volt a közigazgatási, igazságszolgáltatási szervek informatikai felszereltsége, a szabványok elfogadása, az együttműködés rendjének kialakítása, a tevékenység racionalizálása, a felelősségi körök és a jogosultsági szintek meghatározása. A jogalkotási feladatokhoz kapcsolódóan az IM kiemelkedő jelentőségűnek tartotta az információs társadalomban a demokrácia mind szélesebb körű elterjesztését, ennek érdekében – a jogalkotás nyilvánossága, valamint a jogkövetés szintjének emelése céljából – a jogszabályok elérhetővé tételének biztosítását. Konkrét, zömében 2006-ig megvalósítandó feladatként a részletes IMstratégia kidolgozását, az információs társadalom működését biztosító jogalkotási, jogszabály-módosítási feladatok elvégzését, a minisztérium webportálján a tartalomfejlesztést, az adatbázisok felépítését, az elektronikus információkérés és jogsegély

biztosítását, a hatályos jogszabályok és jogszabálymagyarázatok interneten keresztüli elérhetővé tételét jelölte meg. Mindezek összességében az elektronikus ügyintézés lehetőségének biztosítását és átláthatóságának garantálását, az állampolgári bizalom növekedését, a hiteles és biztonságos információcsere feltételeit voltak hivatva megteremteni. Sajátos, és mindenképpen hangsúlyos összefüggésként elemezhető az elektronikus cégeljárás, mint a mai hatályos gyakorlatban az egyetlen olyan jogi eljárás, amelynek elektronizációja „felhasználói oldalról” teljes körűen került bevezetésre. A cégek adataiban bekövetkező nemperes eljárás kezdeményezésére 2008 nyarától kötelezően, és kizárólag elektronikusan van lehetőség Ebben az eljárásban a felhasználói „egyablakot”, azaz a vállalkozási szféra és a bíróság közötti elektronikus „közvetítő közeg” a jogi képviselői személyi kör,

azaz az ügyvédi és a közjegyzői kar jelenti (ide értve a vállalatok jogtanácsosait is, akik azonban a jelenleg hatályos, ellentmondásosnak mondható 2009. június 15 169 eljárási szabályok szerint az egyszerűsített bejegyzési eljárásokban nem láthatják el a jogi képviseletet). A szabályozási modell szerint az informatikai közvetítő alanyi kör (jogi képviselők) számára végrehajtási szintű jogi szabályok – és részben szakmai, kamarai önszabályozás körébe tartozó, de ebben a körben kötelező normák – írják elő az elektronikus eljárás informatikai és biztonsági követelményeit (például elektronikus aláírás, elektronikus ellenjegyzés elektronikus archiválás). A szabályozás általános rendszertana, hogy a hagyományos, speciális cégeljárási szabályokat az elektronikus úton gyakorolt eljárási cselekményekre vonatkozó részletes végrehajtási szabályok egészítik ki. Az új, azóta többször – 2007

júniusában már novellisztikus nagyságrendben is – módosított Cégtörvény (2008. évi V tv, Ctv) részben újraszabályozta az elektronikus cégeljárásról szóló 2003 évi LXXXI törvényben, illetve az azt módosító 2004. évi LXXVII törvényben foglalt eljárási rendet A cél az volt, hogy az ott kialakított szabályokat lehetőség szerint egyszerűsítse, illetve megoldja a technikai-informatikai szabályozás kialakítása során felmerült, jogi szabályozást igénylő kérdéseket is. Az új társasági- és cégjogi szabályozás – már eredeti állapotában is – bizonyos területeken jelentős változásokat hozott. Kibővítette a lehetséges eljárási cselekmények körét, új jogintézményeket (például a jelentősen meggyorsított, „egyszerűsített” cégeljárás) teremtett meg Az új Ctv.-hez kapcsolódva 2007–2008-ban a végrehajtási rendeletek is teljes körűen megújultak [lásd a cégbejegyzési eljárás és a cégnyilvántartás

egyes kérdéseiről szóló 21/2006. (V 18) IM rendelet, a cégbejegyzési eljárás és a cégnyilvántartás egyes kérdéseiről szóló 24/2006. (V 18) IM rendelet, a cégeljárásban és más cégügyekben az illeték és a közzétételi költségtérítés elektronikus úton történő megfizetéséről szóló 25/2006. (V 18) IM rendelet, a Céginformációs és az Elektronikus Cégeljárásban Közreműködő Szolgálat működéséről, valamint a céginformáció költségtérítéséről szóló 1/2006. (VI 26.) IRM rendelet] Az új Ctv hatályba lépését követően egyes eljárási kérdéseket illetően újabb módosítás átvezetésére került sor, melynek rendelkezései lépcsőzetesen léptek hatályba (a cégjogi „novellaként” elhíresült 2007. évi LXI. törvény 2007 szeptember 1-jével, de egyes rendelkezései csak 2008 január elsejétől, az elektronikus cégeljárás kizárólagosságát kimondó módosítás pedig 2008. július elsejétől lépett

életbe26 ) A cégeljárással kapcsolatos legújabb végrehajtási szabályozási fejlemény eredményeként – melynek során megváltozott az eljáráshoz kapcsolt illetékés költségtérítés megfizetésének elektronikus rendje – 2009. március 16 után 26 A cégnyilvánosságról, a bírósági cégeljárásról és a végelszámolási eljárásról szóló 2006. évi VI törvény és egyéb törvények módosításáról szóló 2007 évi LXI törvényt az Országgyűlés 2007. június 1-jén fogadta el, a Magyar Közlöny 2007/75 számában került kihirdetésre. Hatálybalépéséről a 28 § rendelkezik 2009. június 15 170 az igazolás kiadására vonatkozó kérelmet – a korábbiaktól eltérően – közvetlenül a fogadóhoz (a Magyar Államkincstárhoz) kell benyújtani, a kérelmet (utalványminta) az erre a célra szolgáló weboldal segítségével kell elektronikusan aláírni. Ehhez – mint a korábbi eljárás folyamán a rendszerhez való

kapcsolódáshoz – első alkalommal az Internet Explorer segítségével telepíteni kell egy új aláíró modult (alkalmazást) a felhasználó jogi képviselő számítógépére. Az új rendszer jelenleg nem működik Windows Vista operációs rendszer alatt, ami az átállás miatt igen lényeges, nem platformsemleges megoldást nyújt! Azzal, hogy az eljárásban az aláíró program és a háttérben működő kincstári rendszer megváltozott, a felhasználóknak irányított informatikai rendben kell ehhez alkalmazkodniuk, amin nem segít, hogy a kompatibilitást, platformsemlegességet az átállást követően később biztosítja a szabályozó közeg. 2008. január elsején lépett hatályba a jogügyletek biztonságának erősítése érdekében az ügyvéd által végzendő személyazonosság- és igazolványellenőrzéssel kapcsolatos eljárás részletes szabályairól és az ellenőrzéssel kapcsolatos ügyek nyilvántartásáról szóló 54/2007 (XII 21) IRM

rendelet (rövidítve: JÜBüR) A JÜBüR – az ügyvédi törvény (az ügyvédekről szóló 1998 évi XI törvény; továbbiakban Ütv) felhatalmazása alapján (Ütv 133/A. §-ának a) és b) pontja) – rögzíti azokat a részletes végrehajtási szabályokat, melyeket az ügyvédnek azokban az ügyekben kell alkalmaznia, ahol a jogügyletek biztonságának védelmében megalkotott JÜBtv. – és annak átvezetésére szolgáló külön törvényi rendelkezés, például Ütv – alapján a JÜB rendszerhez kapcsolódva adatellenőrzést végez. A JÜB rendszer olyan központi adatszolgáltatást végző, központi informatikai rendszer, melyen keresztül az arra elektronikusan „csatlakozó” felhasználók (ügyvédek, közjegyzők, bírósági végrehajtók) az előttük fekvő ügy kapcsán az ügyfeleik által bemutatott okmányokban szereplő adatokat összehasonlíthatják a különböző hatósági nyilvántartások ténylegesen fennálló, naprakész adataival. A

jogi képviselők tehát a bemutatott okmányok adatainak megadásával a JÜB rendszeren keresztül igényelhetik a nyilvántartásokban szereplő adatokat, a JÜB rendszeren keresztül érkezett válasz összehasonlításával ellenőrizhetik az ügyfelek személyazonosságát, illetve adataik (például lakcímadatok) valódiságát, okmányaik érvényességét. A JÜB rendszerhez az ügyvédeken kívül felhasználóként kapcsolódhatnak a közjegyzők is – akik a cégeljárásban szintén eljárhatnak jogi képviselőként –, továbbá a bírósági végrehajtók is (a végrehajtási eljárásokkal összefüggésben). Ezen különböző felhasználói körök a JÜB rendszeren keresztül egyúttal nem azonos adatcsoport szolgáltatását igényelhetik A JÜBtv.-ből eredő közjegyzői feladatokat átültették a közjegyzőkről szóló külön törvénybe (a 1991. évi XLI tv, továbbiakban Köjtv) 2009. június 15 171 8.7 A belső piaci szolgáltatásokról szóló

irányelv szerinti feladatok és azok megvalósítása Az Európai Közösséget létrehozó szerződés 43. és 49 cikke gyakorlati átültetésének érdekében az Európai Unió megalkotta – és 2006 december 28-án hatályba lépett – az Európai Parlament és Tanács 2006/123/EK irányelve (2006. december 12) a belső piaci szolgáltatásokról (továbbiakban Szolgáltatási Irányelv) A Szolgáltatási Irányelv elsődleges célja a szolgáltatók letelepedési szabadsága gyakorlásának biztosítása és a szolgáltatások szabad mozgásának megkönnyítése az Európai Unió tagállamaiban, a szolgáltatások magas színvonalának megőrzése mellett. Az irányelv részét képezi a lisszaboni stratégia által elindított reformfolyamatnak Mivel az EU gazdaságának dinamizmusa túlnyomó többségben a szolgáltatási ágazat függvénye, a gazdasági növekedéshez elengedhetetlen a szolgáltatások valódi belső piacának megvalósítása a szolgáltatási

tevékenységek jogi és igazgatási akadályainak felszámolásával. A Szolgáltatási Irányelv a szolgáltatók letelepedési szabadsága és a szolgáltatások szabad áramlása érdekében elsősorban a szolgáltatási tevékenység nyújtására való jogosultságra és annak gyakorlására alkalmazandó eljárások és alaki követelmények egyszerűsítésére (5. cikk), az egyablakos ügyintézési pontok létrehozására (ahol a szolgáltatók minden, a Szolgáltatási Irányelv vonatkozó szabályozási hatókörébe tartozó eljárást és alaki követelményt teljesíthetnek, 6. cikk), valamint meghatározott információk a szolgáltatók és a szolgáltatás igénybevevői számára az egyablakos ügyintézési pontokon keresztül történő, egyszerűen hozzáférhetővé tételére (7. cikk) vonatkozó kérdéseket szabályozza A tagállamoknak azt is biztosítaniuk kell, hogy minden eljárás és alaki követelmény egyszerűen teljesíthető legyen távolról és

elektronikus úton az érintett egyablakos ügyintézési pontoknál és az érintett illetékes hatóságoknál (8. cikk) A Szolgáltatási Irányelv implementációjára irányuló projekt hatókörébe elsősorban a szolgáltatási irányelv 6–8. cikke, 11 cikk (3) bekezdése és 21. cikke előírásainak teljesítése, illetve az ezek teljesítéséhez szükséges jogi háttér megteremtése tartozik. A tagországoknak a Szolgáltatási irányelv hatályba lépését követően 3 év állt rendelkezésére, hogy fölkészüljenek a Szolgáltatási Irányelv előírásainak teljesítésére. Tehát a fentiekben idézett előírásoknak való megfelelést és az ezt biztosító jogi környezetet a Szolgáltatási Irányelv implementációjára irányuló projektnek 2009. december 28-ig biztosítania kell A Szolgáltatási irányelvből adódó, fenti követelmények megvalósítása a Ket. az elektronikus 2009. június 15 172 ügyintézésre, elektronikus kapcsolattartásra

vonatkozó – a 2008. évi CXI törvénnyel módosított – szabályaival összhangban történik.27 A szolgáltatási irányelvből fakadó – az illetékes hatóságokat érintő – feladatok köre két nagy csoportba sorolható (figyelmen kívül hagyva a fent már említett, jogalkotást is végző illetékes hatóságok átvilágítási és jelentéstételi kötelezettségét). Ezek az egyablakos ügyintézés biztosítása és az eljárások elektronikus úton történő teljesíthetősége, illetőleg az illetékes hatóságok közötti igazgatási együttműködés biztosítása. Az egyablakos ügyintézés feladata, hogy a magyar és tagállami szolgáltatók annak keretében az irányelv hatálya alá tartozó szolgáltatások tekintetében minden olyan eljárást és alaki követelményt teljesíthessenek, amelyek a szolgáltatási tevékenység nyújtására való jogosultsággal és a szolgáltatási tevékenység gyakorlásával kapcsolatosak, akár letelepedés

keretében, akár ideiglenesen, határon átnyúló jelleggel nyújtanak szolgáltatásokat. Az egyablakos ügyintézési pontoknak ezen túlmenően feladata a tájékoztatás is, vagyis az irányelvben előírt információknak a szolgáltatók részére történő hozzáférhetővé tétele. Az illetékes hatóságoknak a szolgáltatási irányelv rendelkezéseiből adódó másik fontos kötelezettsége az egymás közötti igazgatási együttműködés. Az irányelv 28. cikke értelmében a tagállamoknak kölcsönösen segítséget kell nyújtaniuk egymásnak, és a hatékony együttműködés érdekében intézkedéseket kell hozniuk a szolgáltatók és az általuk nyújtott szolgáltatások felügyeletének biztosítására. Ezzel összefüggésben az irányelv számos kötelezettséget állapít meg. Az irányelv értelmében a tagállamoknak a tájékoztatást elektronikus úton kell biztosítaniuk (28 cikk (6) bekezdés) Az irányelv jogi kötelezettségként írja elő a

tagállamok számára az igazgatási együttműködés keretében egy, az Európai Bizottság által kialakítandó elektronikus információs rendszer használatát. Az együttműködés eszköze egy internetes alapú 27 E szabályok értelmében minden kérelemre induló (nem csak a Szolgáltatási Irányelv hatóköre alá tartozó) hatósági eljárás esetében biztosítani kell az ügyfelek számára az elektronikus kapcsolattartás lehetőségét a hatóságokkal [Ket. 28/B §, (2) bekezdés]. A hatósági eljárásokban az egyedüli írásbeli kapcsolattartással egyenértékű elektronikus kapcsolattartási formaként a központi elektronikus szolgáltató rendszer használatával történő kapcsolattartást nevezi meg. A központi elektronikus szolgáltató rendszer tehát a hatósági eljárások elektronikus ügyintézése során egy egyablakos ügyintézési pont szerepét tölti be [Ket. 28/B §, (1) bekezdés] A Ket 164. §, (1) bekezdése előírja az összes

hatósági eljárásra vonatkozóan az elektronikus információszabadságról szóló törvényben definiált közérdekű adatok figyelembevételével meghatározott tartalmú elektronikus ügyintézési tájékoztatók közzétételét. Az ügyfél a Ket. 28/C §, (1) bekezdése szerint az összes hatósági eljárás vonatkozásában valamennyi Ket-ben meghatározott kapcsolattartási formát (rövid szöveges üzenet, elektronikus levél, telefon stb.) használhatja tájékoztatáskérés céljából 2009. június 15 173 szoftver, a belső piaci információs rendszer (IMI, Internal Market Information System).28 A hálózat az Európai Unió valamennyi hivatalos nyelvén működik. Az irányelv a nemzeti jogba való átültetéséből eredő feladatok különböző megvalósítási lehetőségeinek elemzése eredményeként Magyarország az elektronikus egyablakos ügyintézési pont központi rendszer bázisán történő megvalósítása mellett döntött. Emellett pedig

(külön projekt keretében) a többcsatornás ügyfélkiszolgálás biztosítása érdekében gondoskodni kíván a központi rendszer által biztosított elektronikus ügyintézési szolgáltatások telefonon és interneten elérhető központi ügyfélszolgálat általi támogatásáról is.29 28 Az IMI-t a tagállamok közigazgatási rendszerei közötti kommunikáció javítása érdekében fejlesztik ki. Az információcseréhez biztosít egy olyan rendszert, amely segítségével a tagállamok a belső piaci jogszabályok végrehajtásakor hatékonyabban tudnak napi szinten együttműködni. Az IMI-t arra szánják, hogy olyan jelentős gyakorlati akadályokat segítsen áthidalni, mint a közigazgatási és munkahelyi kultúrák különbségei, a különböző nyelvek, illetve a pontosan meghatározott partnerek hiánya más tagállamokban. Célja az adminisztratív terhek csökkentése és a tagállamok közötti napi együttműködésben a hatékonyság, illetve az

eredményesség növelése A kezdeti szakaszban az IMI a szakmai képesítések elismeréséről szóló irányelv (2005/36/EK) kölcsönös segítségnyújtásra vonatkozó rendelkezéseinek alkalmazását igyekszik majd elősegíteni. 2009 decemberétől az IMI-rendszerben valósulhat meg a belső piaci szolgáltatásokról szóló irányelv (2006/123/EK) keretében folytatott igazgatási együttműködés is. Az IMI általános eszköz, amely egyidejűleg több belső piaci jogterületen is támogatni tudja a hatóságok közötti adatcserét, ezért a Bizottság azt tervezi, hogy a későbbiekben további jogterületekre is kiterjeszti használatát. 29 A projekt megvalósítása az elektronikus ügyintézésre vonatkozó hatályos [különösen A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. törvény és annak végrehajtási rendeletei, 24/2006 (IV 29) BM – IHM – NKÖM együttes rendelet a közfeladatot ellátó

szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekről, 335/2005. (XII 29) Korm rendelet a közfeladatot ellátó szervek iratkezelésének általános követelményeiről, 193/2005. (IX 22) Korm rendelet az elektronikus ügyintézés részletes szabályairól, 195/2005. (IX 22) Korm rendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról, 1995 évi LXVI törvény a köziratokról, a közlevéltárakról és a magánlevéltári anyag védelméről, 182/2007 (VII 10) Korm rendelet a központi elektronikus szolgáltató rendszerről, 84/2007. (IV 25) Korm Rendelet a Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről] és várható változásokra (az elektronikus közszolgáltatásról szóló törvényjavaslat és annak végrehajtási rendeletei, a szolgáltatási tevékenység

megkezdésének és folytatásának általános szabályairól szóló törvényjavaslat és annak végrehajtási rendeletei, a hivatalos iratok elektronikus kézbesítéséről és az elektronikus tértivevényről szóló törvényjavaslat és annak esetleges végrehajtási rendeletei) követelményeknek megfelelően kerül sor. 2009. június 15 174 2009. június 15 9. fejezet A nyílt forráskódú szoftverek közigazgatásban való felhasználhatóságának jogszabályi háttere 9.1 Az elektronikus közigazgatási ügyintézés lehetővé tétele és keretrendszerének alakulása a magyar szabályozásban Az elektronikus ügyintézést korlátozó tényezők körében az egyik legjelentősebbiket (a megfelelő technológiai feltételrendszer és a közigazgatás személyi állományának informatikai felkészültségének hiányai mellett) a 2000-es évek elején az akkor hatályos jogszabályi környezet jelentette, mely a hagyományos, papír alapú ügyintézés

elektronikus eszközökkel való kiváltását nem, vagy csak igen korlátozott mértékben tette lehetővé. Közigazgatási eljárásjogunkban Az államigazgatási eljárás általános szabályairól szóló 1957. évi IV törvény módosításával elméletileg legalábbis lehetővé vált – akár elektronikus formanyomtatvány rendszeresítése mellett is – a kérelem a közigazgatási szervhez elektronikus dokumentumban való benyújtása [Áe. 16 §, (1) bekezdés], az elektronikus dokumentum iratkénti elismerése [Áe. 28 §, (3) bekezdés], a határozat elektronikus dokumentumba foglalása [Áe 43 §, (2) bekezdés] és a határozat elektronikus dokumentumban való kézbesítése [Áe 45 §, (1) bekezdés] Az Áe konstrukciója az elektronikus ügyintézést azonban csak akkor engedte meg, ha az adott eljárástípusra tekintettel azt ágazati jogszabály kifejezetten lehetővé tette, ille175 176 tőleg – az önkormányzati igazgatás terén – ha annak

technológiai feltételei megvannak, és az önkormányzat illetékességi területére az elektronikus ügyintézést rendeletben tette lehetővé (2001. évi XXXV tv 3 §) A közigazgatási hatósági eljárások vonatkozásában a szükséges jogszabályok megalkotására az Áe. biztosította ugyan a felhatalmazást (az ágazati miniszterek, illetőleg a helyi önkormányzatok a technikai lehetőségek függvényében egy-egy területen, saját illetékességi körükben lényegében bármikor bevezethetik az elektronikus ügyintézést), ám ilyen jogszabályok megalkotásának elősegítése érdekében nagyon kevés konkrét lépés történt (például a BM részéről a közigazgatási szolgáltató rendszer felállítása, a rendszer működéséhez szükséges jogszabálymódosítások előkészítése). Az Áe.-szerinti e-ügyintézési modell központi elemét az elektronikus aláírás alkalmazása képezte A kormányzati elektronikus aláírási rendszer kiépítésével

összefüggő egyes feladatokról és a kormányzati hitelesítés-szolgáltató felállításáról szóló 1026/2002. (III 26) Korm határozat előírta, hogy a jogi szabályozásnak biztosítania kell az elektronikus aláírásról szóló 2001 évi XXXV. törvény szerinti minősített elektronikus aláírással és minősített időbélyegzővel ellátott elektronikus dokumentumok teljes körű elfogadását A 2002-es választások után elfogadott kormányprogram külön kiemelte az ügyfélkapcsolatok fejlesztésének célját. Az önkormányzati és a központi közigazgatás, valamint az ügyfelek kommunikációjának modern alapokra helyezését: ennek megvalósítása – az elektronikus levelezés széles körű felhasználása és az internet biztosította lehetőségek kiaknázása – felé bizonyos jogi, adminisztrációs és technikai lépések is történtek. 2002–2003-ban az elektronikus ügyintézés problémájának megoldása – a közigazgatás megújulását

célzó, jelentős elméleti háttérre épülő, fő irányaiban már a kilencvenes évek derekán meghatározott reformtörekvésekkel, mindenekelőtt az államigazgatási eljárási törvény korszerű követelményeknek megfelelő megújításával összhangban – egyrészt az alakuló nemzeti információs társadalmi stratégia központi elemévé vált, másrészt beépült a közigazgatási rendszer és szolgáltatások korszerűsítésével összefüggő programokba is. A már folyamatban lévő törvényalkotási munkához kapcsolódva is megjelentek egyes, az e-kormányzatot közvetlenül érintő, konkrét feladatszabások. Jogpolitikai igényű követelményként fogalmazódott meg az is, hogy az elektronikus kormányzásnak a központi közigazgatásban történő – megfelelő ütemű – elterjesztése, és az eKormányzat 2005. stratégia megvalósításának érdekében részletes elemzés kimunkálása szükséges az elektronikus ügyintézést korlátozó

tényezők felszámolási lehetőségeiről, az erőforrások koncentrálási módjáról, az elektronikus ügyintézés hatékony bevezetésének ütemezéséről, a köztisztviselői kar felkészítésének és a lakosság tájékoztatásának teendőiről. (Az elektronikus kormányzat megvalósításával összefüggő egyes szabályozási 2009. június 15 177 feladatokról szóló 2316/2003. (XII 10) Korm határozat h 1 pont) A határozat az elektronikus ügyintézés mielőbbi bevezetése érdekében elrendelte, hogy ki kell dolgozni, és 2004. március 31-ig a Kormány elé kell terjeszteni az elektronikus hatósági ügyintézés lehetővé tételéről szóló kormányrendelet tervezetét. Az ezen előkészítő munka alapján megszületett, Az elektronikus közigazgatási ügyintézésről és a kapcsolódó szolgáltatásokról szóló 184/2004. (VI 3) Korm. rendelet – meghatározott ügytípusokban – az elektronikus közigazgatási ügyintézés lehetőségét az Áe

keretei között, viszonylag korlátozottan, az államigazgatási eljárásról szóló 1957. évi IV törvényben kifejezetten lehetővé tett eljárási cselekményekre nézve, alternatívaként nyitotta meg. A szabályozási modell az érintett szolgáltatásnyújtók együttműködését, az ügyfél ügyintézési lehetőségét a kölcsönös előnyök és az információs önrendelkezési jog alapján kívánta elősegíteni. Az esetleges adatkezelés kizárólag a szolgáltatás igénybevevőjének beleegyezésével történhetett, a felhatalmazásában meghatározott terjedelemmel, feltételekkel. A szabályozás figyelemmel volt az EU elektronikus kormányzatot érintő politikáira – ezen belül is a technológiasemlegesség, illetve a zárt és nyílt forráskódú szoftverek versenysemleges felhasználásának követelményére –, a kapcsolódó egyes részterületekre (informatikai biztonság, adatvédelem stb.), a normatív és az ajánlások szintjén létező,

illetőleg szabványokban testet öltő szabályozás követelményeire és várható fejlődésére, az elektronikus kormányzati megoldásokban jelentős eredményeket elért tagállamok tapasztalataira, működő modelljeire. A kormányrendeletben megjelenő szabályozás azonban – tudatosan – átmeneti jellegű volt. Élettartamát a jogalkotó a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló törvény hatályba lépéséig tervezte, s abban bízott, hogy a megszerzett tapasztalatok birtokában egy pontosabb, a még felmerülő szabályozatlan, vagy nem megfelelően szabályozott kérdéseket is rendező jogszabály válik majd kibocsáthatóvá. A kormányrendeletben kialakított megoldások a magyar jogban akkor még hiányzó, de részben már előkészítés alatt álló további jogintézmények (elektronikus archiválás, elektronikus ügyiratkezelés) megszületése után is olyan konstrukciót kínálhattak volna, mely a

legnagyobb számban jelentkező közigazgatási ügyek gyors elintézését biztosítani tudja. Az Európai Parlament által elfogadott, a helyes közigazgatási gyakorlat kódexének és az Európai Unió Alapjogi Kartájának elveit szem előtt tartva készült el, s került 2004. júniusában a Parlament elé a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló törvény tervezete A tervezetben megjelenő szabályozási koncepció a fokozott biztonságú elektronikus aláírást tekintette az elektronikus kapcsolattartás alapvető módjának. Az ilyen aláírással nem rendelkező ügyfelek esetében is lehetővé kívánta tenni 2009. június 15 178 az ügyfél-hatóság kapcsolattartást, melynek feltétele az ügyfél azonosítása és egy központi elektronikus szolgáltató rendszer útján történő kommunikáció. Az elektronikus kommunikációval együtt járó ügyfélazonosítás a szabályozás alapvető irányultsága szerint

azonban nem járhatott együtt az azonosításon túli célt lehetővé tevő adatbázis létrehozásával. A kodifikációs munka eredményeként megszületett, s a Parlament által 2004. december 20-án elfogadott, A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004 évi XCL törvénnyel az elektronikus ügyintézés összefüggésében minden olyan kérdést érinteni kívántak, mely a szabályozás tárgyánál fogva törvényi szintű rendezést igényel (adatvédelem és információhoz jutás szabadsága, a főszabály alóli kivételek lehetőségének szűkítése, alapvető eljárási mozzanatok rögzítése, ügyféljogok és garanciák), másfelől – e rendelkezésekkel összhangban – keretet kívántak biztosítani a részletes, gyakorlatban is alkalmazható szabályozási környezet kialakításához. A Ket. az elektronikus ügyintézésre vonatkozó szabályokat csak a legszükségesebb mértékben rögzítette

Felhatalmazást biztosított viszont az elektronikus hatósági ügyintézési szabályok alkalmazásához szükséges részletszabályok megalkotása Az elektronikus ügyintézés részletes szabályairól szóló 193/2005. (IX 22) Korm rendelet a Ket 174 §, (1) bekezdésének b) pontjában foglalt, Az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról szóló 195/2005. (IX 22) Korm rendelet a Ket 174 §, (1) bekezdésének e) pontjában foglalt, A közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről szóló 194/2005. (IX 22) Korm rendelet pedig az Eat 27 §-a (1) bekezdésének b) pontjában foglalt felhatalmazás alapján került megalkotásra 2005. decemberében e rendeletekhez kapcsolódva az Informatikai

és Hírközlési Minisztérium az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságának, együttműködési képességének és egységes használatának támogatása érdekében az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról szóló 195/2005. (IX 22) Korm rendelet 3 §, (1) bekezdésében foglaltak alapján hat témában (tanúsítványformátumok, időbélyegzőformátum, e-aláírás formátumok, aláírási szabályzatok, hitelesítési rendek és viszontazonosítás) tett közzé ajánlást. Az elektronikus ügyintézés jogi feltételrendszerének biztosítása nem képzelhető el anélkül, hogy az elektronikus dokumentumokkal, iratokkal szemben támasztott formátum-követelményekről, illetőleg az ilyen iratok – a papír alapú dokumentumokkal együttes, de azok elektronikus voltából adódó, speciális 2009. június 15 179

követelményekre is tekintettel levő – kezelésének szabályozásáról ne történjék rendelkezés. A Ket 174 §, (3) bekezdés a) pontjával az informatikai és hírközlési miniszter arra kapott felhatalmazást, hogy az elektronikus ügyintézési eljárásban alkalmazható dokumentumok technológiai követelményeire figyelemmel a részletes technikai szabályokat megállapítsa. E felhatalmazás alapján született meg a Ket. negyedik „elektronikus végrehajtási rendelete”, Az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól szóló 12/2005. (X 27) IHM rendelet A köziratokról, a közlevéltárakról és a magánlevéltári anyag védelméről szóló 1995. évi LXVI törvény (Ltv) módosítása felhatalmazta a Kormányt arra, hogy az egységes közigazgatási ügykezelési szabályokat, a közfeladatot ellátó szervek iratkezelésének általános követelményeit rendeleti úton szabályozza [lásd A

közfeladatot ellátó szervek iratkezelésének általános követelményeiről szóló 335/2005. (XII 29) Korm rendelet] A belügyminiszter, az informatikai és hírközlési miniszter, valamint a nemzeti kulturális örökség minisztere ugyanitt kapott felhatalmazást, hogy a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben és az elektronikus iratok levéltárba adásával, tárolásával kapcsolatban támasztott követelményeket együttes rendeletben állapítsák meg.1 A Ket. 160 §, (1) bekezdése elvi éllel mondta ki, hogy törvény, kormányrendelet, önkormányzati rendelet eltérő rendelkezése hiányában a hatóság a közigazgatási hatósági ügyeket elektronikusan is intézi. A Ket maga nem tartalmaz rendelkezéseket arra vonatkozóan, hogy mely típusú hatósági eljárásokban, s milyen feltételek mellett van lehetőség az elektronikus út korlátozására, a kivételeket alapvetően az egyes ágazati jogszabályoknak kell

meghatározniuk. Értelemszerűen mindazon esetekben, ahol az ágazati jogszabály nem tartalmaz korlátozó vagy kizáró rendelkezést, az elektronikus úton történő ügyintézés lehetőségét 2005. november 1 napjától az ügyfelek számára igénybe vehetővé kellett (volna) tenni. A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL törvény hatálybalépésével összefüggő egyes törvények módosításáról szóló 2005 évi LXXXIII törvény az egyes ágazati jogszabályok tekintetében megjelent kivételek egyrészt az elektronikus ügyintézési lehetőség teljes körű kizárásáról, másrészt az elektronikus úton történő eljárási cselekmények körének korlátozásáról, részleges kizárásáról rendelkeztek. Az ilyen kizárásokat, korlátozásokat (az ügyfél elektronikus úton csak bejelentést tehet, illetve tájékoztatás iránti kérelmet terjeszthet elő, az ügyfél kérelme

elektronikus úton előterjeszthető ugyan, más eljárási cselekmény azonban elektronikus úton nem bonyolítható), ezek okait és esetköreit az egyes 1 lásd 24/ 2005. BM – NKÖM – IHM rendelet 2009. június 15 180 törvénymódosításokhoz fűzött miniszteri indokolások az informatikai felkészültség, jogszabályi, pénzügyi feltételek hiányával, az eljárás során benyújtandó okiratokkal szemben támasztott materiális követelményekkel, illetve az eljárás egyes, a személyes ügyintézéshez szorosan kötődő sajátosságaival támasztották alá. Önkormányzati hatáskörben maradt továbbá annak az eldöntése is, hogy a helyi közigazgatás szintjén intézhető hatósági (államigazgatási, tehát nem csak önkormányzati) ügyekben az elektronikus módozat bevezetését ki kívánják-e zárni. Az önkormányzatok az informatikai ellátottságukra, felkészültségükre tekintettel igen nagy arányban (mintegy 83%-ban) a számukra könnyebbik

utat választották, teljes körűen kizárták az elektronikus ügyintézést, amely az elektronikus út. A Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007. (IV 25) Korm rendelettel, illetőleg A Központi Elektronikus Szolgáltató Rendszerről szóló 182/2007 (VII 10.) Korm rendelettel – a Ket szabályaival összhangban – lefektetésre került az ügyfélkapu köré kiépült, központosított elektronikus ügyintézés alapvető jogi és informatikai biztonsági feltételrendszere. E szabályozás – szándékoltan és tudatosan – egyfelől többet nyújt, mint ami a Ket. alapján szükséges és elvárható lenne (rendelkezései a nem hatósági közigazgatási ügyintézés eseteire is alkalmazhatók), másrészt kevesebbet is: szabályai csak jelentős továbbfejlesztéssel (és az e-ügyintézésre vonatkozó további követelmények deregulációjával) válhatnak alkalmassá arra, hogy a

helyi, önkormányzati elektronikus ügyintézésben is alkalmazhatóvá váljanak. A KSZR-rendelet – a 84/2007 Korm. rendeletben foglalt biztonsági rendelkezésekkel együtt – olyan szabályozási konstrukciót vezetett be, mely egyfelől biztosítja a központi elektronikus szolgáltató rendszer(ek) működésének jogi feltételrendszerét (belső regulatív funkció), másfelől a szolgáltatásnyújtás szabályainak, az alapszolgáltatásoknak meghatározásával a szolgáltatások igénybevételével kapcsolatos követelményeket is pontosan rögzíti (külső regulatív funkció). A rendelet a rendszer „belépési pontjaira” (az ügyfélkapu, a hivatali kapu) vonatkozó szabályok, illetőleg a rendszerhez való csatlakozás követelményeinek rögzítésével a központosított elektronikus ügyintézés és a KR (Kormányzati Gerincháló) révén elérhető szolgáltatások igénybevételének lehetőségét, ezen túlmenően a szolgáltatásnyújtásba való

bekapcsolódást, szolgáltatás-közvetítést, valamint a mindezen tevékenységekkel összefüggő felelősségi kérdéseket fogja át. A modell a már adott informatikai keretek között, technológia-semlegességre törekedve az ügyintézés feltételrendszerét a lehető legszélesebb alanyiszervezeti kör számára hosszabb távon tudja biztosítani, de megteremtette ezzel a szolgáltatások továbbfejlesztéséhez szükséges, szilárd jogszabályi ala2009. június 15 181 pokat is. Ehhez a jogalkotó olyan szabályozási kereteket választott, mely az alkalmazott hardver- és szoftverelemekkel (alkalmazásokkal, formátumokkal stb.) kapcsolatosan csak a funkcionális és biztonságossági követelményeket határozza meg (nagy pontossággal), ugyanakkor az e követelményeknek eleget tevő bármely technológia alkalmazását lehetővé teszi. 9.2 A Ket 2008 évi módosítása és az elektronikus közszolgáltatásokról szóló új törvény előkészítése A

közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló törvény hatálybalépésével kapcsolatos feladatok ütemezéséről szóló 1145/ 2004. (XII 22) Korm határozat 12 pontja megszabta a Ket hatályosulásának 2007 május 1-jéig tartó időszakra kiterjedő vizsgálatát és a szükséges jogszabálymódosítások előkészítését. Az ÖTM 2007-ben elkészítette a módosítás tervezetét, amelyet több körben közigazgatási egyeztetésre bocsátott A tervezet előkészítésének idején látott napvilágot az „Új rend és szabadság” programjának megvalósításáról szóló 3071/2007. Korm határozat, ám az a kormányzati deregulációs programról és a vállalkozói környezet javítását szolgáló az „Üzletre hangolva” program intézkedéseiről szóló kormánydöntéshez is kapcsolódott. A Ket módosítását követően mind tartalmi, mind formai szempontból az egyes ágazatokért felelős tárcáknak – az

Igazságügyi és Rendészeti Minisztérium közreműködésével – felül kell vizsgálnia a Ket.-tel összefüggő valamennyi ágazati jogszabályt. A Ket. módosítási javaslata egyszerűbbé, gyorsabbá és hatékonyabbá kívánta tenni a közigazgatási eljárást A változtatás nem egyoldalúan, a hatóságok terheit növelve kívánta ezt a célt elérni, hanem a tervezet egyaránt érinti az ügyfelek és a hatóságok jogait és kötelezettségeit. E cél érdekében a módosítás – több lépcsőben – jelentősen csökkenti az eljárási határidőket, csökkenti az ügyfelek terheit és kötelezettségeit, a jelenleginél szélesebb körben teszi lehetővé az egyablakos ügyintézést, és – előbb fakultatívan, majd bizonyos körben kötelezően is – alkalmazni rendeli az elektronikus eljárást. A 2008. évi CXI törvény koncepcionálisan változtat a Ket szabályain az elektronikus kapcsolattartás tekintetében. Az elmúlt évek tapasztalatai

egyértelműen azt tükrözik, hogy a Ket.-nek az elektronikus eljárást lehetővé tévő rendelkezése – néhány kivételtől eltekintve – nem valósult meg a gyakorlatban. Ez a tervezet előterjesztői szerint két okra vezethető vissza Jelentős probléma egyrészt, hogy az ágazati jogszabályok számos esetben éltek a Ket. által biztosított azon lehetőséggel, hogy az elektronikus eljárás lehetősége ki2009. június 15 182 zárható. Másrészt a technikai feltételek jelenleg még több hivatal esetén nem adottak az elektronikus eljáráshoz (a hivatal nem csatlakozott a központi elektronikus szolgáltató rendszerhez, nem rendelkezik minősített elektronikus aláírással stb.) Ez azonban mára egyre kevesebb hivatal esetén igaz Számos hivatal rendelkezik 2005–2006 óta minősített elektronikus aláírással, és egyre több hatóság csatlakozott a központi elektronikus szolgáltató rendszerre, így minősített aláírással ellátott elektronikus

dokumentum és hivatali kapu útján is egyre több hivatallal tartható kapcsolat. Tény ugyanakkor, hogy azokban az eljárásokban sem terjedt el széles körben az elektronikus úton történő kapcsolattartás, ahol azt jogszabály nem zárja ki. Tekintettel az elengedhetetlen technikai fejlesztésekre és az ágazati jogszabályok felülvizsgálatának szükségességére, csak 2011. január 1-jén lép hatályba az a módosítás, amely a hatóságokat elektronikus úton való kapcsolattartásra kötelezi Az elektronikus kapcsolattartás alól a tervezet szűk körben enged kivételt: ha valamilyen külső, objektív oknál fogva lehetetlen az elektronikus kommunikáció, vagy ha az az eljárás elhúzódásával járna. Lehetetlen az elektronikus kapcsolattartás, ha például üzemzavar keletkezett a küldő vagy a fogadó hatóság informatikai rendszerében. Az elektronikus kapcsolattartást a módosítás a hatályos szabályozástól eltérően, annál egyszerűbb és

költségkímélőbb módon szabályozza. A hatályos szabályozás ugyanis azt várta el a hatóságoktól, hogy azok amellett, hogy a központi rendszerhez csatlakoznak és ügyfél- vagy hivatali kaput nyitnak, legyenek képesek elektronikus aláírással ellátott dokumentumok fogadására és a küldő viszontazonosítására. Ez a megoldást amellett, hogy drága, feleslegesnek is tűnik, mivel a tapasztalatok alapján csupán néhány száz, a közigazgatásban alkalmazható elektronikus aláírás létezik, a közigazgatásban alkalmazható minősített aláírással történő ügyintézés nem terjedt el. A tervezet ezért az elektronikus kapcsolattartást teljes mértékben a központi rendszerre szabja. A módosítás figyelemmel volt arra, hogy a technológiai megoldások az elektronikus kommunikáció terén rendkívül gyorsan változnak. Nem tartalmazza ezért az elektronikus úton való kapcsolattartás részletes szabályait, csupán keretszabályokat alkot arra, hogy

mely követelményeknek kell megfelelnie az elektronikus azonosításnak ahhoz, hogy írásbelinek minősüljön. A tervezet nem kívánt a működő, biztonságos azonosítást végző technikák közül választani, egyenrangúként kezeli a biztonsági követelményeknek megfelelő ügyfélkaput és a fokozott biztonságú elektronikus aláírással ellátott elektronikus dokumentumot, és az ügyfélnek is szabad választási jogot biztosít. E szabályozás révén a közigazgatási eljárás képes lesz a technikai fejlődésre gyorsan reagálni, hiszen a szabályozás megváltoztatásához a Ket. módosítására nem lesz szükség, új biztonságos elektronikus kapcsolattartási forma 2009. június 15 183 bevezetése kormányrendeleti szinten megoldható. A Ket X fejezete azonban továbbra is szabályozza az ügyfélkapu létesítésére és a kapcsolódó adatkezelésre vonatkozó szabályok azon részét, amelyek törvényi szintet igényelnek. A módosítás

újraszabályozta a Ket. elektronikus tájékoztató szolgáltatásról szóló fejezetét A szabályozás megteremti a Ket és az elektronikus információszabadságról szóló 2005. évi XC törvény (Eitv) összhangját E körben a tervezet egyrészt meghatározza, hogy a hatóságnak az Eitv.-ben meghatározottakon túl milyen adatokat kell honlapon közzétennie, másrészt pedig előírja, hogy – az Eitv.-nek a tevékenységre, működésre vonatkozó adatokkal kapcsolatos előírásával összhangban – a hatóság teljesítményének és hatékonyságának mérésére ügyforgalmi statisztikát kell készítenie. A Ket.-tel összhangban a határidőkre és az elektronikus kapcsolattartásra vonatkozó ágazati rendelkezéseket újra kell szabályozni, a hatósági ügyintézők felkészítése is hosszabb felkészülési időt tesz szükségessé. Egyes módosítások hatályba lépéséhez ugyanakkor jelenleg még nem adott valamennyi feltétel, azok mindenekelőtt

informatikai fejlesztéseket és az ügyintézők továbbképzését igénylik. A módosítások hatályba lépése a hatályosnál egyszerűbb feltételekkel teszi lehetővé az ügyfél és a hatóság, valamint a hatóságok egymás közötti elektronikus kapcsolattartását. A folyamatban lévő technikai fejlesztésekre tekintettel ugyanakkor a hatóságok közötti kötelező elektronikus kapcsolattartást előíró szabály csak 2011-ben lép hatályba. Ahol viszont ennek a lehetőségei adottak, ott az általános szabályoknak megfelelően már korábban is igénybevehető, és élvezhető az ebből származó hatékonysági előny. A Ket. – különös tekintettel a 2008 végén elfogadott módosításokra – alapvetően biztosítja az elektronikus hatósági ügyintézés és szolgáltatás jogszabályi feltételeit, az elektronikus kormányzás fogalma azonban ennél lényegesen szélesebb körű szolgáltatásokat fed le. Ide tartoznak például a hatósági

ügyintézés körébe nem tartozó elektronikus ügyintézés támogatása, tájékoztató szolgáltatások. Az ügyfelek – a lehető legáltalánosabban értelmezett – elektronikus támogatása céljából a Kormány létrehozta a központi elektronikus szolgáltató rendszert, amely magában foglalja az elektronikus kormányzati gerinchálózatot, a kormányzati portált, a kormányzati ügyfél-tájékoztató központot, az ott megjelenő szolgáltatásokat és ügyintézési lehetőségeket, valamint azok fenntartóit és üzemeltetőit, továbbá biztosítja az ügyfelek számára az elektronikus ügyfélkapu, a csatlakozott szervek számára a hivatali kapu létesítésének lehetőségét. E feladatok támogatását az állampolgárok magasabb színvonalú kiszolgálását lehetővé tevő, az egész országot átfogó, korszerű eszközöket alkalmazó, szolgáltató szemléletű elektronikus ügyintézési, ügyfél-tájékoztatási rendszer szolgálja. A központi

rendszer ma egységesen biztosítja az állampolgárok, a 2009. június 15 184 közigazgatási és egyéb csatlakozó szervek számára az elektronikus alapszolgáltatásokat, amelyhez szabványosított felületeken csatlakoznak a kormányzati elektronikus szolgáltatások, továbbá lehetőséget biztosít az önkormányzati szolgáltatások csatlakoztatására is. Felügyeletét és működtetését a Miniszterelnöki Hivatalt vezető miniszter feladat- és hatásköréről szóló 29/2008 (II. 19) Korm rendelet alapján a Miniszterelnöki Hivatal látja el Az ügyfélkapu köré kiépült központosított elektronikus ügyintézés alapvető jogi és informatikai biztonsági feltételrendszerre vonatkozó részletszabályokat – a Ket. szabályaival összhangban – a Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007 (IV. 25) Korm rendelet, illetőleg a Központi elektronikus szolgáltató rendszerről

szóló 182/2007 (VII 10) Korm rendelet állapítja meg A Kormányprogramban célul tűzött, modern, új típusú, szolgáltató állam kialakításának igénye, az elektronikus közigazgatással, az állampolgárok, vállalkozások, civil szervezetek ügyeinek elektronikus úton történő intézésével kapcsolatos kérdések köre a jogi szabályozás szintjén azonban nem kizárólag a hatósági közigazgatási eljárás magasabb szintű „elektronizáltságának”, az eljárási cselekmények elektronikus út igénybe vételével történő gyakorolhatóvá tételének igényét veti fel (aminek irányait a Ket. elfogadott módosítása határozza meg), de az e-közigazgatás alapjaira építve – azon mégis túlnyúlva – az elektronikus közszolgáltatások fejlesztésének szükségességére is rámutat. A Kormányprogram ezen céljainak összefüggésében alapvető feladatként határozható meg, hogy mindenki számára biztosítani lehessen az alapvető

információs közszolgáltatásokhoz, az elektronikus kommunikációs hálózathoz, a közhasznú információkhoz való biztonságos hozzáférést, az állampolgárok, vállalkozások, civil szervezetek számára pedig hivatalos ügyeik elektronikus úton történő intézésének, az állam az ügyintézésben közreműködő szerveinek több csatornás (személyes, internetes, mobilos stb.) elérési lehetőségét Ez összességében az elektronikus közszolgáltatások szemléletváltást is jelentő átalakítását követeli meg. Az ügyek elektronizálásáról a hangsúly az ember és családja, üzleti vállalkozása, civil képviselete támogatásának irányába, mindennapi igényei személyre szabott kiszolgálására, az ügyek intézéséhez szükséges információk teljes körű biztosítására kell, hogy áttevődjék. Mindehhez – egységes alapokon, a már kialakított e-közszolgáltatási alapinfrastruktúrára építve – olyan, központilag kialakított

működési infrastruktúrát kell kiépíteni, mely középtávon megoldja a rendszerek fizikai, informatikai szempontból történő elhelyezését és védelmét, lehetőséget ad a tudásmegosztásra. Szükséges olyan szabványosított ügyintézési felületek kialakítása is, amelyeken keresztül az ügyfél ezen egységes közszolgáltatási struktúra keretei között találkozik az állammal, az állam szerveivel. 2009. június 15 185 Az elektronikus közszolgáltatásokról szóló törvény a Parlamenti tárgyalás szakaszában lévő tárgyalt, de még el nem fogadott javaslata (a továbbiakban: Eksztj.) számos szempontból kiegészíti, illetve felváltja a Ket – az elektronikus hatósági ügyintézésre vonatkozó, az eljárási törvény módosításával átfogóan érintett – szabályait. Az informatikai közmű igénybevételének összefüggésében (például azonosítás, biztonságosság, informatikai rendszerek együttes működtetése) kifejezetten a

Ket.-re épülő hatályos szabályozási modell helyébe lépnek Az elektronikus közigazgatás és közszolgáltatás összehangolt fejlesztésére irányuló törekvések formálódó szabályozási környezetére alapvető hatást gyakorolnak a közelmúltban elfogadott, előkészített, és elfogadásra váró jogszabály-tervezetek, illetve jogszabály módosítások. Az Eksztj.-n túlmenően elsősorban az informatikai biztonságról szóló törvénytervezet, valamint az egészségügyi kártya bevezetéséről szóló előterjesztés tartoznak ide. A közeljövő jogalkotási szempontból leglényegesebb feladata az Eksztj. végrehajtási rendeleteinek szakmai előkészítése, illetőleg – a Ketben, valamint az elektronikus aláírásról szóló törvényben biztosított, a már meglévő felhatalmazások alapján – az e törvények hatálya alá tartozó rendeleti kör felülvizsgálata.2 A nemzetközi példáknak megfelelően az ügyfelek igényeire válaszoló

elektronikus közszolgáltatások kialakításának feltételrendszerét egy egységes, átfogó, a jelenleg fennálló irányítási és koordinációs hatásköri átfedéseket felszámoló elektronikus közszolgáltatási törvény formájában szükséges rendezni. Az elektronikus közszolgáltatásokról szóló törvényjavaslat elsődleges célja az volt, hogy az elektronikus közszolgáltatások infrastrukturális (szervezetiintézményi, működési, biztonságossági, interoperabilitási stb.) feltételrendszerét kialakítsa Ugyancsak alapvető követelmény volt, hogy a szabályozásnak – szolgáltató szemléletű, egységes folyamatszabályozással, a szolgáltatások egyetemleges elérhetőségével – biztosítania kell a nyilvánosság és a társadalmi kontroll feltételeit A csatlakozott szerveknek, szervezeteknek lehetővé kell tenniük az ügyintézési folyamatok átláthatóságát, a közérdekű adatok megismerhetőségét, a személyes adatok védelmét,

az informatikai biztonság, a más informatikai rendszerekkel való együttműködés követelményének az 2 A 2008. évi CXI törvény 128 §, (1) bekezdése értelmében a Ket 174 §, (1) bekezdése szerint részben módosított, részben újonnan beiktatott felhatalmazások alapján a Kormányt illeti a jog, hogy az elektronikus kapcsolattartás részletes eljárási szabályait, az elektronikus kapcsolattartást lehetővé tévő és elektronikus hatósági szolgáltatást nyújtó informatikai rendszerek biztonságát, együttműködési képességét (interoperabilitását), valamint egységes használatát biztosító részletes előírásokat meghatározza. A felhatalmazások a közigazgatási informatikáért felelős minisztert jogosítják továbbá arra, hogy rendeletben állapítsa meg az elektronikus kapcsolattartás során alkalmazható iratok technológiai követelményeire figyelemmel a részletes technikai szabályokat. 2009. június 15 186 üzemeltetés

folytonosságát lehetővé tevő teljesülését, a digitális esélyegyenlőség és az elektronikus közszolgáltatások társadalmi elfogadottságának erősítését. Ugyancsak alapelvi követelmény, hogy az elektronikus közszolgáltatások elősegítése a közigazgatás minden szervének kötelezettsége, melynek teljesítése során e szervek együttműködésre kötelezettek. A szabályozás alapvető jellegéből (az elektronikus közszolgáltatásokra vonatkozó keretszabályok kialakítása) adódóan a Javaslat egyrészt csak az alkalmazás szempontjából legszükségesebb fogalmak meghatározására, a közszolgáltatási struktúra, a folyamatok legalapvetőbb, garanciális szempontból törvényi szabályozást igénylő kérdései lényegi elemeinek rögzítésére törekszik, másrészt viszont biztosítja a részletszabályok rendeleti szintű megalkotásához szükséges felhatalmazásokat. Kormányrendelet határozná meg az elektronikus közszolgáltatások

együttműködésével, az általuk működtetett informatikai rendszerek együttes működtetésével kapcsolatos részletes szabályokat, a központi rendszer működésével, szolgáltatásainak igénybevételével összefüggő részletes informatikai biztonsági, adatbiztonsági követelményeket, a központi rendszerhez való csatlakozás követelményeit, az e követelményeknek való megfelelés tanúsításának szabályait. A Javaslat az ügyfelek (felhasználók) elektronikus úton történő azonosításának, a hatósági nyilvántartásokból történő adatkérésre és adatszolgáltatásra, a központi rendszer szolgáltatásaként nyújtott központi e-irattári és e-levéltári szolgáltatásra, ezen szolgáltatások igénybevételére, illetőleg a központi rendszer cím használatára vonatkozó – zömében technikai természetű – részletszabályokat ugyancsak kormányrendeleti szinten állapítaná meg.3 9.3 A nyílt forráskódú szoftverek

felhasználásának lehetőségei a központi rendszer útján történő elektronikus ügyintézésben Mint arra korábban rámutattunk, úgy a költséghatékonyság, mint az alkalmazott informatikai rendszerek biztonsága szempontjából lényeges, hogy az egyre szélesebb körben lehetővé váló elektronikus ügyintézés egységes, a központi rendszer alapszolgáltatásainak (azonosítás, adattovábbítás stb.) 3 E rendeletek szakmai előkészítése folyamatban van. Lényeges, hogy e számos vonatkozásban elavult, diszfunkcionális szabályozást olyan, a Központi Szolgáltató Rendszer széleskörűen kidolgozott, s alapvetően kormányrendeleti szinten meghatározott működési feltételeire figyelemmel lévő rendeletek váltsák fel, melyek kifejezetten támogatják a nyílt forráskódú szoftverek alkalmazásának elterjedését, a nyílt rendszerekre épülő interoperabilitás követelményének érvényesülését. 2009. június 15 187 igénybevételének

útján valósuljon meg. A Ket-hez kapcsolódó „elektronikus” rendeletek – Az elektronikus ügyintézés részletes szabályairól szóló 193/2005. (IX. 22) Korm rendelet, Az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról szóló 195/2005 (IX 22) Korm rendelet, A közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről szóló 194/2005. (IX 22) Korm rendelet és Az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól szóló 12/2005. (X 27) IHM rendelet – egy ma már meghaladottnak tekinthető, s a rendeletek gyakorlati alkalmazását is gátló szabályozási szemléletet tükröznek. E szabályoknak azonban az elektronikus (közigazgatási)

ügyintézés minden formája esetén (ide értve az önkormányzati ügyeket is) érvényesülniük kellett volna. E rendeletekre a túlszabályozás, a sokszor értelmezhetetlen és betarthatatlan biztonsági követelmények előírása volt a jellemző – alkalmazásukat az IHM által kibocsátott, a közigazgatás tényleges lehetőségeire kevés figyelmet fordító ajánlásai sem könnyítették meg. A kormányzati informatikai stratégia fejlesztése, illetőleg az elektronikus közigazgatósági ügyintézés igényének megfelelő, speciális követelmények meghatározásában előbb a 3296/1991. Korm határozattal létrehozott Informatikai Tárcaközi Bizottság, majd az ennek helyébe lépő, A kormányzati informatika fejlesztésének koordinálásával kapcsolatos egyes feladatokról szóló 1054/2004. (VI 3) Korm határozat alapján létrehozott Kormányzati Informatikai Egyeztető Tárcaközi Bizottság által kibocsátott Ajánlások játszottak döntő szerepet.4 Az

ITKTB Elektronikus közigazgatási Albizottsága 4 Vö. : Az ITB 2 számú ajánlása az informatikai stratégia irányításának irányelveiről 1993, az ITB 3. számú ajánlása az informatikai stratégiai tervezésről a gyakorlatban, 1993, az ITB 4 számú ajánlása az SSADM strukturált rendszerelemzési és tervezési módszerről, 1993, az ITB 5. számú ajánlása a PRINCE projektirányítási módszertanba történő bevezetésről, 1993, az ITB 6 számú ajánlása az X/Open specifikációknak megfelelő nyílt rendszerű termékek útmutatójáról, 1993–1995, az ITB 7. számú ajánlása a beszerzési ajánlásokról az X/Open XPG4 (XPG3) specifikációi és a GOSIP4 kormányzati OSI profil, 1994, az ITB 9 számú ajánlása a minőségirányításról, az ITB 9. számú ajánlása a minőségirányításról, 1997, az ITB 12. számú ajánlása az informatikai rendszerek biztonsági követelményeiről, 1996, az ITB 13. számú ajánlása az Intranetről, mint

internet a kormányzatban, 1997, az ITB 15. számú ajánlása az infrastruktúra menedzsmentről,1996, az ITB 16 számú ajánlása a Common Criteria (CC), az informatikai termékek és rendszerek biztonsági értékelésének módszertanáról, 1996, az ITB 17. számú ajánlása az elektronikus adatcseréről, 1997, a KIETB 18. számú ajánlása a 148/2002 (VII 1) Korm rendelet alapján történő projektkövetésről, 2002, a KIETB 19 számú ajánlása a központi államigazgatás szervezeteinek internet-tevékenységéről, valamint az általuk működ- 2009. június 15 188 (ELKA), a Kormányzati Informatikai Egyeztető Tárcaközi Bizottság (KIETB), valamint az Elektronikus Kormányzat Operatív Bizottság (EKOB) feladatainak egyesítésével az 1026/2007. (IV 11) Korm határozattal létrehozott Közigazgatási Informatikai Bizottság részben a korábbi Ajánlásai felülvizsgálatát, modernizációját célozták5 , részben a központi elektronikus ügyintézés

kormányrendeleti szintű szabályaihoz – A Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007. (IV 25) Korm rendelet, illetőleg A Központi Elektronikus Szolgáltató Rendszerről szóló 182/2007. (VII 10) Korm rendelet – kapcsolódva állapítottak meg egy-egy területre vonatkozó specifikációkat6 A nyílt forráskódú szoftverek használata, illetőleg az ennek esetleg jogi vagy műszaki specifikációs akadályok elhárítása azoknak a kérdéseknek összefüggésében merülhet fel, melyek egyfelől a KR operatív-technikai működésével, másfelől a KR-en keresztül zajló adatcsere-formátum meghatározásával, harmadsorban az adatok archiválásával, tartós megőrzésével, konverziójával kapcsolatosak. A közigazgatási (vagy éppen bírósági) ügyintézés speciális, a papír alapú ügyintézéstől eltérő, vagy egyedi szabályozást igénylő eljárásjogi kérdései (ide értve

a regisztrációval, az azonosítással, az ügyfélkapu vagy hivatali kapu használatával, beadványok elektronikus fogadásával vagy az ügyfél számára történő kézbesítésével) „technológia-semlegesek”, tetett honlapok tartalmi és formai követelményeiről (Verzió : 2.0), 2004, a KIETB 21 számú ajánlása az ügyfélkapu szolgáltatásaihoz történő kapcsolódás műszaki specifikációjáról, 2006, a KIETB 22. számú ajánlása a kormányzati intézmények informatikai stratégiájának készítéséről, 2005, a KIETB 23 számú ajánlása az informatikai szerződések általános követelményeiről, 2005, a KIETB 24. számú ajánlása a központi közigazgatási szervek szoftverfejlesztéseihez kapcsolódó minőségbiztosításról és minőségirányításról, 2005. Ezek közül az ITB 6 és 7 számú Ajánlásai – a korabeli kormányhatározatokkal összhangban – elsőként deklarálták a nyílt rendszerek használatának preferálását, mint a

közigazgatási informatikai beszerzésekre általában vonatkozó követelményt. A KIETB szoftverbeszerzésekre, szoftverfejlesztésre vonatkozó Ajánlásai egységes követelményeket állítottak fel, melyeknek a szoftverek vonatkozásában általában érvényesülniük kellett, a nyílt rendszereken alapuló együttműködési követelmény biztosítását azonban kiemelt célnak tekintették. 5 A KIB 25. számú ajánlásaként megjelent Magyar Informatikai Biztonsági Ajánlások (MIBA) ajánlássorozat az ITB 8., 12 és 16 számú ajánlásait váltotta fel 6 A KIB 26. számú ajánlása : A Magyarországon elektronikus azonosításra, hitelesítésre, aláírásra és elektronikus azonosítók hordozására alkalmas eszközök követelményei (HUNeID) 10 verzió, 2008 június, a KIB 21 számú ajánlása: Az ügyfélkapu és hivatali kapu kapcsolódás műszaki specifikációja 2.0 verzió, 2008 augusztus, a Közigazgatási Informatikai Bizottság 27. számú ajánlása :

Útmutató a közigazgatási eljárások során használt nyomtatványok elektronizálásához 10 verzió, 2008 október, végül a korábban már részletesebben hivatkozott a Közigazgatási Informatikai Bizottság 28. számú Ajánlásaként az E-Közigazgatási Keretrendszer projekt eredményeként létrehozott Követelménytár. 2009. június 15 189 „szoftverfüggetlenek”. Ugyancsak „technológia-semlegesek” az informatikai biztonságra vonatkozó előírások is. A vonatkozó rendeletekben, szabályzatokban és műszaki specifikációkban meghatározott követelményeknek eleget tevő zárt, illetve nyílt forráskódú szoftverek egyaránt használhatók. A Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007. (IV 25) Korm rendelet, a rendszer „belépési pontjaira” (az ügyfélkapu, a hivatali kapu) vonatkozó szabályok, illetőleg a rendszerhez való csatlakozás követelményeinek

rögzítésével a központosított elektronikus ügyintézés és a KR révén elérhető szolgáltatások igénybevételének lehetőségét, ezen túlmenően a szolgáltatásnyújtásba való bekapcsolódást, szolgáltatás-közvetítést, valamint a mindezen tevékenységekkel összefüggő felelősségi kérdéseket fogja át. A modell a már adott informatikai keretek között az ügyintézés feltételrendszerét a lehető legszélesebb alanyi-szervezeti kör számára hosszabb távon tudja biztosítani, de megteremtette ezzel a szolgáltatások továbbfejlesztéséhez szükséges, szilárd jogszabályi alapokat is. A szolgáltatás nyújtásának általános szabályai körében a rendelet egyfelől rögzíti a központi rendszer működtetéséért és informatikai biztonságáért, a központi rendszer által közvetlenül nyújtott szolgáltatások rendelkezésre állásáért, a csatlakozott szervezetek által nyújtott közvetített elektronikus szolgáltatás központi

rendszer útján történő elérhetőségéért való felelősség, illetőleg a közvetített elektronikus szolgáltatások koordinálásával összefüggő feladatokat, jogosítványokat. Az egyes szervekhez (feladataik ellátási összefüggésében) ugyanakkor további, különös felelősségi konstrukciókat is rendel Az Eksztj II. Fejezete Az elektronikus közszolgáltatások nyújtásának szabályai körében – bár a hatályos rendeleti szabályozást sok szempontból irányadónak tekinti a jövőre nézve is – ehhez képest tartalmaz eltéréseket, pontosításokat Ha törvény vagy kormányrendelet eltérően nem rendelkezik, a közigazgatási hatóságok kötelesek a hatósági eljárásokban az elektronikus kapcsolattartást és az e törvény hatálya alá tartozó más szolgáltatásaikat a központi rendszer útján az e törvényben meghatározott módon megvalósítani, illetve hozzáférhetővé tenni. A bíróság, az ügyészség és a nyomozóhatóság

által lefolytatott eljárásokban a jogi képviselő, a védő és a bíróság, illetve az ügyészség, illetve a nyomozó hatóság közötti írásbeli kapcsolatot, valamint a törvény által meghatározott más írásbeli kapcsolatot a központi rendszer útján kell tartani. A közüzemi szolgáltatást nyújtók kötelesek ügyfélszolgálatukat hozzáférhetővé tenni a központi rendszeren keresztül is, és a közigazgatási hatóságokkal e rendszeren keresztül tartani a kapcsolatot. Azok a költségvetési szervek, amelyek törvény alapján nem kötelezettek arra, hogy a központi rendszerhez csatlakozzanak, jogosultak a központi rendszeren keresztül szolgáltatásaikat az ügyfeleik számára elérhetővé tenni, és 2009. június 15 190 egymással, illetve más, a rendszerben részt vevő szervezetekkel a rendszeren keresztül kapcsolatot tartani. A központi rendszerhez szerződés alapján csatlakozhat az a szerv vagy szervezet, amely szolgáltatásait a

központi rendszeren kívánja nyújtani. Az elektronikus közszolgáltatások nyújtása tehát a törvényben meghatározott állami szervek számára kötelezettség. A törvényjavaslat három kötelezetti kategóriát különít el Az elsőbe a közigazgatási hatóságok tartoznak, amely fogalomba valamennyi közigazgatási hatósági feladatot ellátó államigazgatási, illetve önkormányzati hatósági szervezet, valamint a hatósági jogköröket külön törvény alapján ellátó köztestületek, illetve más jogszabályban erre felhatalmazott szervezetek beletartoznak. A második kör a bíróságok és ügyészségek kommunikációját, illetve elektronikus szolgáltatásait célozza meg. A harmadik előírás a fogyasztóvédelmi törvény szerinti közszolgáltatók ügyfélszolgálati tevékenységére vonatkozik, ezt is elérhetővé kell tenni a központi elektronikus szolgáltató rendszeren keresztül. Más költségvetési szervek jogosultak a központi

rendszerhez csatlakozni. A közszolgáltatás követelményeivel összhangban az Eksztj. rögzíti, hogy valamennyi csatlakozásra kötelezett szervezeti körrel, valamint a költségvetési szervekkel szemben a központi rendszert szolgáltatási kötelezettség terheli. Ugyanakkor a felkészülés, illetve az igények változásához való alkalmazkodás érdekében lehetővé teszi, hogy a kapacitások kiépülésére tekintettel a csatlakozást, a szolgáltatások bővítését ütemezni lehessen. Ennek mintegy ellentételeként, a kötelezett szervek számára is felkészülési időt biztosít a törvényjavaslat, a különböző kötelezetti körök, szolgáltatások vonatkozásában a kötelezés eltérő időpontban lép hatályba, biztosítva a felkészülés lehetőségét. Az ellátás biztonsága követelményének megfelelően a törvény rögzíti, hogy a központi rendszernek a kötelezetti és a jogosulti kör számára nyújtott szolgáltatásainak elsőbbséget kell

biztosítania, elsődlegesen az ő igényeiket kell kielégítenie, csak ezután nyújthat mások számára szolgáltatásokat. A másik oldalról viszont a megkötött szerződések biztonsága érdekében előírja, hogy a központi rendszer a kötelezett, illetve csatlakozásra a törvény erejénél fogva jogosult szolgáltatók részéről fellépő újabb igények esetén sem hivatkozhat vis maiorra a már önkéntesen (jellemzően ellenérték fejében) megkötött szerződések teljesítésénél. Azaz nem mentesülhet következmények nélkül a már megkötött szerződéseiben rögzített kötelezettségek alól. Az EKG a felhasználó számára – főszabályként – térítésmentesen biztosítja a 182/2007. Korm rendeletben meghatározott zártcélú elektronikus hírközlési és egyéb szolgáltatásokat. Az EKG a felhasználó számára nyújtott alapszolgáltatásai: az egyes felhasználók EKG infrastruktúrához való hozzáférését és zárt intraneten

keresztül történő kommunikációját lehetővé tevő kapcsolódási pont, hozzáférés, virtuális magánhálózat (VPN) létrehozása, a felhasználói támogatás (Help Desk), az internet hozzáférés, a – minden 2009. június 15 191 csatlakozott felhasználó számára domain-név, cím- és névfeloldást biztosító – domain-név szolgáltatás (Domain Name Service – DNS), a kormányzati címtár és elektronikus levelek továbbítása. Ezen alapszolgáltatások a felhasználók számára az EKG-hoz csatlakozás után automatikusan érhetők el. Az EKG-val összefüggő használati követelményeket, valamint az EKG-val összefüggő biztonsági követelményeket a 182/2007. Korm rendelet 3 mellékletében foglalt hálózat használati szabályzat és 4 mellékletét képező EKG informatikai biztonsági szabályzat együttesen tartalmazza. Az EKG Informatikai Biztonsági Szabályzatának célja az Elektronikus Kormányzati Gerinchálózat üzembiztonságát

megteremtő szabályok és intézkedések meghatározása. Az IBSz a biztonsági kérdésekben alapszabályzat, ugyanakkor nem tér ki részletesen az üzembiztonság minden aspektusára. Szervesen illeszkedik viszont a – más jogszabályok alapján (például államtitkokról szóló rendeletek) és szabványokból (például Országos Építési Szabályzat, ITSEC) kialakult – szabályzati rendszerbe, kiegészíti továbbá az EKG működési szabályzatát és megteremti az alapot az üzembiztonság egyes aspektusaival (például biztonsági szervezet működési szabályzata, katasztrófa terv) részletesen foglalkozó szabályzatok létrehozásához. A kormányzati portál – mint a központi rendszer egyik eleme – olyan hozzáférési hely, amely biztosítja a központi rendszer internetes megjelenését, egységes hozzáférési felületet ad az elektronikus ügyintézéshez, az ügyfelek tájékoztatásához, a bejelentési, panasz- és javaslattételi,

vélemény-nyilvánítási jog gyakorlásához. Állandó szolgáltatásai a központi, területi és helyi közigazgatási szervek, valamint az egyéb állami költségvetési szervek elérhetőségi adatai [postai és elektronikus cím(ek), telefonszámok (központ és ügyfélszolgálat), ügyfélfogadási idő], ügyleírások, letölthető formanyomtatványok, minták közzététele, az elektronikusan intézhető közigazgatási ügyek listája, az eljáró szerv megnevezése és elektronikus elérhetősége, az ügyfélkapu, a személyes azonosításon alapuló fórum. A biztonságos elektronikus dokumentumtovábbító szolgáltatás a központi elektronikus szolgáltató rendszer azon szolgáltatása, amely lehetővé teszi a csatlakozott szervezet és az ügyfél egymás közötti kétirányú hiteles és az átvétel tényét tanúsító, dokumentumalapú, biztonságos kommunikációját. A BEDSZ az ügyfél számára az ügyfélkapun keresztül, a csatlakozott szervezet

számára pedig a hivatali kapun keresztül érhető el. A központi rendszer a BEDSZ útján fogadja az ügyfélkapun keresztül benyújtott, elektronikus aláírással el nem látott, illetve ellátott dokumentumokat, és az ügyfélkapu használata nélkül benyújtott, elektronikus aláírással ellátott dokumentumokat. A BEDSZ keretében a benyújtásra kerülő dokumentumokra a befogadásuk esetén azonnal érkeztető szám és időbélyeg kerül, amely utóbbi tanúsítja 2009. június 15 192 a dokumentum beérkezésének időpontját, és biztosítja a dokumentum sértetlensége utólagos ellenőrzésének lehetőségét. A csatlakozott szervezetnek küldött dokumentum tekintetében a jogszabályokban szereplő eljárási határidőket a központi rendszer által kiadott befogadási igazolásban rögzített időponttól kell számítani. A Ket. hatályos szabályozási modelljében a magánszemély ügyfél-azonosításra elsődlegesen az Eat szerinti, legalább fokozott

biztonságú aláírása szolgál. Amennyiben a természetes személy ügyfél ilyen elektronikus aláírással nem rendelkezik, számára az elektronikus hatósági ügyintézés lehetőségét a központi rendszer biztosítja. A Ket módosítása7 Elektronikus kapcsolattartás az ügyfélkapun keresztül cím alatt számos részletkérdést újraszabályozott, gyökeres változásokat azonban e téren nem hozott A Ket X fejezete továbbra is szabályozza az ügyfélkapu létesítésére és a kapcsolódó adatkezelésre vonatkozó szabályok azon részét, amelyek törvényi szintet igényelnek. Az ügyfélkapura vonatkozó, törvényi szintet nem igénylő kérdéseket a Ket. módosításával párhuzamosan előkészített kormányrendelet tartalmazza, amely várhatóan kiegészül az elektronikus kapcsolattartás új rendszerének végrehajtási szabályaival. Az e-Kormányzat 2010 Stratégiában megjelenített álláspont szerint a távolról történő ügyintézés

elengedhetetlen feltétele az állampolgárok megbízható azonosítása. Az állampolgárok biztonságos azonosítására alkalmas eszközrendszer bevezetésének célja, hogy akár a KR-en keresztül történő elektronikus ügyintézés során, távoli elérésnél, akár egyéb feladatnál megfelelő biztonságot garantáló eszköz álljon rendelkezésre az állampolgár azonosításához, adatainak eléréséhez, a vele való hiteles és letagadhatatlan kommunikációhoz, valamint az ügyek intézéséhez. A különböző hordozók ésszerű kombinációjával kell biztosítani, hogy az azonosítás minden ügyintézési helyzetben megfelelő biztonságot nyújtson, és ne jelentsen a felhasználók számára indokolatlan anyagi és szellemi megterhelést. Az Eksztj. az azonosítás – az elektronikus hatósági ügyintézés keretei között szabályozott – jelenlegi modelljétől eltérően az azonosítás módjának meghatározását az ügyintézés jogszabályban előírt

biztonsági követelményszintjéhez kapcsolja. A legtöbb elektronikus közszolgáltatás esetén az azonosítás előírása nem indokolt, arra csak abban az esetben van szükség, ha az elektronikus közszolgáltatás igénybevételének feltétele az eljáró természetes személy kilétének megállapítása. Az államigazgatás oldaláról az azonosítási funkciókhoz, adatbázisokhoz történő hozzáférést értelemszerűen az elektronikus kormányzati gerinchálózatnak kell biztosítania. 7 Ket. mód 118 §, (2) bekezdés 2009. június 15 193 A Ket. meghatározta a kérelem8 elküldésének, a megérkezés a hatóság részéről való visszaigazolásának módját, szabályozza azt az eljárási határidők szempontjából lényeges kérdést, hogy az elektronikus úton elküldött kérelem mikor tekintendő a közigazgatási szervhez benyújtottnak. A közigazgatási szerv visszaigazolása automatikusan, emberi beavatkozást nem igénylő módon történik, az

elektronikus küldemény megérkezésének nyugtázásán túl az ügyhöz rendelt egyedi azonosítószámot is tartalmazza. Az elektronikus dokumentum megérkezéséről a hatóság a külön jogszabályban meghatározott módon elektronikus érkeztető számot tartalmazó automatikus értesítést küld a dokumentum feladójának. A hatóság a dokumentum megérkezését követő három napon belül megvizsgálja, hogy az megfelel-e a jogszabályban előírt követelményeknek. Az ügyfél beadványának megérkezéséhez fűződő jogkövetkezmények elektronikus beküldés esetén az érkeztetésről szóló automatikus visszaigazolásnak az ügyfél részére való elküldésével állnak be. 9.4 Informatikai rendszerek együttműködése, informatikai biztonság Az elektronikus kapcsolattartással és tájékoztatással szembeni követelményekről rendelkező, a Ket. a 2008 évi CXI törvénnyel módosított 166 § szerint a hatóságnak az eljárása során – a biztonságos

és átlátható kapcsolattartás érdekében – az elektronikus kapcsolattartás informatikai támogatásával gondoskodik az ügyfél által elektronikus úton előterjesztett és a hatóság által készített iratok biztonságos kezeléséről. Ennek érdekében a hatóság az ügyintézés hatáskörébe eső folyamatában biztosítja az elektronikus irat sértetlenségét, megváltoztathatatlanságát. Akár kötelező alkalmazás előírásával is biztosítja továbbá azt, hogy az ügyfél számára olyan informatikai megoldások igénybevétele váljék lehetségessé, melyek a hatósággal való, az ügyfél számára az elektronikus kapcsolattartáshoz biztosított levélcíméről kezdeményezett, vagy e levélcímre irányuló kommunikációt, az ügyintézéssel összefüggő adatai megőrzését és az ügyfél számára az általa megismerhető adatokhoz való hozzáférést, illetőleg a hatósággal való elektronikus kapcsolattartás biztonságosságát teszik

lehetővé. Ezen túlmenően a hatóságnak azt is biztosítania kell, hogy az irat visszakereshető és jogszabályban meghatáro8 Az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól szóló 12/2005. (X 27) IHM rendeletben foglalt követelményeknek már a kérelem vonatkozásában is eleget kell tenni, azaz a hatósággal való kapcsolattartásban (elektronikus) formakényszer érvényesül, mely azonban – mint a következő alpontban részletesen tárgyalni fogjuk – a nyílt forráskódú szoftverek használatát viszonylag széles körben lehetővé teszi. 2009. június 15 194 zott formában és ideig megőrizhető legyen. Az ügyfél az ügyintézés folyamán kérheti, hogy a hatóság küldje meg részére elektronikusan az általa elektronikusan beküldött információkat, és eltérés esetén a megküldéstől számított három napon belül kérheti annak korrekcióját. A hatóság az elektronikus

kapcsolattartás, illetve tájékoztatás teljesítéséhez csak olyan informatikai rendszert vehet igénybe, amely biztosítja a hatóságok egymás közötti, valamint az ügyfelekkel való biztonságos kapcsolatát, az adatvédelmi szabályoknak megfelelő adatkezelést és a hiteles dokumentumcserét, továbbá az elektronikus iratoknak a jogszabályban meghatározott formában és a levéltári szabályokban meghatározott ideig történő archiválását, továbbá alkalmas más, az említett célt szolgáló informatikai rendszerekkel történő együttműködésre. E – kifejezetten technológia-semleges – követelményrendszer magában foglalja a szolgáltatások nyújtásához igénybe vett informatikai eszközökkel, alkalmazásokkal, számítógépes programokkal, az ügyfelek számára szükséges tájékoztatásokkal és azok hozzáférhetővé tételével, az egyes szolgáltatások együttes működtetésének biztosíthatóságával, az elektronikus úton benyújtott

kérelemhez rendelt elektronikus érkeztető szám képzésével kapcsolatos előírásokat [Ket. módosított 167 §, (1)–(2) bekezdés] A Ket. új szövegű 168 §-a értelmében törvény és kormányrendelet az ügyfélkapun keresztül történő elektronikus kapcsolattartásra az ügyfélkapun keresztüli kapcsolattartásra vonatkozó 160. §-ban foglaltaktól eltérő szabályokat állapíthat meg, s elrendelheti az elektronikus tájékoztatásra vonatkozó 164. §-ban meghatározottaktól való eltérés módját is Ezzel a nem üzenetekkel történő elektronikus kapcsolattartás szabályai teljes terjedelmükben kikerültek a szabályozásból. Helyükre egy, a központi elektronikus szolgáltató rendszerre vonatkozó általános eltérésre vonatkozó felhatalmazás került annak érdekében, hogy a már előkészület alatt álló elektronikus közszolgáltatásról szóló törvénnyel az összhang biztosítható legyen. A fentiek szerinti követelményrendszer magában

foglalja a szolgáltatások nyújtásához igénybe vett informatikai eszközökkel, alkalmazásokkal, számítógépes programokkal, az ügyfelek számára szükséges tájékoztatásokkal és azok hozzáférhetővé tételével, az egyes szolgáltatások együttes működtetésének biztosíthatóságával, és az elektronikus úton benyújtott kérelemhez rendelt elektronikus érkeztető szám képzésével kapcsolatos előírásokat.9 Az interoperabilitásra, informatikai biztonságra vonatkozó részletes követelményrendszert Az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról szóló 9 Az ezzel kapcsolatos részletszabályokat a 193/2005. (IX 22) Korm rendelet állapította meg A rendelkezéseket a 182/2007 Korm rendelet az Evr melléklete helyébe léptetett 5. melléklete váltotta fel 2009. június 15 195 195/2005. (IX 22) Korm rendelet10 , a KR-re vonatkozó

különös előírásokat A Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007. (IV 25) Korm rendelet állapította meg A rendelet személyi hatálya a közigazgatási hatóságra terjed ki (1. §) Fogalomhasználatában informatikai célrendszernek a hatóság által elektronikus ügyintézés nyújtása céljából igénybe vett informatikai eszközök (szoftver és hardver eszközök) olyan összessége minősül, amelyek a közigazgatási hatósági eljárásban az ügyféllel vagy más hatósággal kapcsolatot tartanak, vagy amelyek a közigazgatási hatósági üggyel kapcsolatos adatot kezelnek. Eljárási és biztonsági követelmények alatt a rendelet V. fejezetében meghatározott biztonsági követelményeket, a biztonsági követelmények teljesülését alátámasztó, a rendelet IV. fejezetében meghatározott követelményeket, valamint a Ket-ben és a külön jogszabályban az informatikai

célrendszerre vonatkozóan meghatározott követelmények összességét kell érteni [2 §, a)–b) pont]. A műszaki egységesítés eszközrendszere összefüggésében a rendelet az informatikai és hírközlési miniszter számára biztosítja ajánlások kibocsátásának jogát. Az ajánlások célja annak meghatározása, hogy a rendszereknek az elektronikus ügyintézés biztosításához milyen műszaki feltételeknek kell megfelelniük. A kormányzati informatikai rendszerekre vonatkozó különleges követelmények körében a Miniszterelnöki Hivatalt vezető miniszter jogosult ajánlás kibocsátására, ahol tehát a rendelet a miniszter ajánlását említi, ott a Miniszterelnöki Hivatalt vezető miniszter ajánlását is érteni kell [3. §, (1)–(3) bekezdés]. A biztonsági követelmények teljesülését alátámasztó követelményekről és az informatikai célrendszerre vonatkozó minőségirányítási követelményekről a rendelet IV. fejezete tartalmaz

előírásokat Ennek körében meghatározza a hatóság az informatikai célrendszer tervezésére, elemeinek beszerzésére, valamint előállítására vonatkozó kötelezettségeit, s rendelkezik minőségirányítási követelményekről is. A hatóság az ügyfelek számára az egyes eljárási cselekmények elektronikus úton történő végzését biztonságos informatikai célrendszer útján teszi lehetővé A biztonsági követelményekről szólva a rendelet V fejezete meghatározza a biztonsági követelmények alkalmazására és használatára vonatkozó konkrét követelményeket, így a biztonsági követelmények általános szabályait (14. §), az ügyfél azonosításával kapcsolatos biztonsági kötelezettségeket (15. §), az informatikai célrendszer folyamatainak naplózását, megbízható üzemeltetését, a mentési és archiválási rendjét (16–19 §), az 10 A rendelet 2005. november 1-jén lépett hatályba Azon informatikai célrendszerek esetében,

amelyekre vonatkozóan a rendelet hatálybalépését megelőzően a közbeszerzési eljárást már megindították, az e rendeletben megfogalmazott követelményeket 2007. november 1-ig kellett (volna) teljesíteni 2009. június 15 196 informatikai rendszer védelmével, az adattárolás, adattovábbítás biztonságosságával (20–22. §), valamint a rendszer hozzáférési és fizikai biztonságával és egyes elemeinek kezelési biztonságával (23–25. §) összefüggő elvárásokat A 6–8. §-ban foglaltakon túlmenő, a biztonsági követelmények teljesülését alátámasztó, további előírásokat a Korm. rendelet az informatikai biztonsági irányításra és kockázatfelmérésre, az informatikai célrendszer segítségével elektronikus úton végezhető eljárási cselekmények biztonsági osztályaira és az informatikai célrendszer üzemeltetésének kiszervezésével kapcsolatos követelményekre vonatkozó szabályai rögzítik. A rendelet 27–30 § –

önálló fejezetben – a célrendszerek együttműködéséről szólva meghatározza azoknak a központi elektronikus szolgáltató rendszerhez való csatlakozásával összefüggő egyes követelményeket és szabályozzák az informatikai célrendszerek egységes használatának feltételeit. A Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeiről szóló 84/2007. (IV 25) Korm rendelet e szabályokat kiegészítve, a KR vonatkozásában esetlegesen speciális, eltérő előírásokat megfogalmazva alapvetően a Központi Rendszer üzembiztonsága és a kezelt adatok biztonsága érdekében a Központi Rendszer és a kapcsolódó rendszerek egységes informatikai biztonsági követelményrendszerét, valamint a Központi Rendszer Informatikai Katasztrófa-elhárítási Tervének alapelveit határozza meg. A rendelet egyfelől – garanciális ügyféljogokat is rögzítve – nevesíti azokat a dokumentumtípusokat, az ezek

elkészítésével, alkalmazásával összefüggő kötelezettségeket, melyek a mellékletekben felállított pontos követelményrendszer érvényesülését biztosítani hivatottak, másfelől rendezi a működtetéssel, a rendszerhez való kapcsolódással összefüggő, alapvető felelősségi kérdéseket. A rendelet szerinti biztonsági követelményrendszert három dokumentumtípusban kell érvényesíteni. Az első a biztonsági irányelv, mely meghatározza az informatikai infrastruktúra teljes életciklusára (tervezésnél, beszerzésnél, fejlesztésnél, üzemeltetésnél és selejtezésnél) alkalmazandó általános biztonsági elvárásokat. A második a biztonsági szabályzat, mely leírja a biztonsági intézkedéseket, azok dokumentálásának és ellenőrzésének feladatait, a végrehajtás felelősét és a végrehajtás gyakoriságát vagy idejét. Végül a harmadik körbe a végrehajtási eljárásrendek tartoznak, melyek részletesen leírják a

szabályzatban meghatározott feladatok végrehajtásának, ellenőrzésének módját, folyamatát E dokumentumokat a Központi Rendszert működtető, illetve üzemeltető szervezetek, valamint a Központi Rendszeren keresztül elektronikus szolgáltatást nyújtó szervezetek (szolgáltatók) készítik el, akik gondoskodnak azok karbantartásáról is. A – rendeletben meghatározott – biztonsági követelményrendszertől, illetve az informatikai katasztrófaelhárítási terv alapelveitől akkor lehet eltérni, ha a követelmény nem értelmezhető 2009. június 15 197 vagy nem alkalmazható. Ebben az esetben az eltérést indokolni és a dokumentumokban rögzíteni kell Az interoperabilitásra, informatikai biztonságra vonatkozó szabályok esetében lényeges a technológia-semlegesség elvi követelményének teljesülésére vonatkozó szabályozói törekvés. Ennek lényeges eleme, hogy a szabályozás kizárólag az értékelési szempontok felállítására

összpontosít, s nem tesz különbséget a szerint, hogy ennek például a szoftverek esetében az érintett szervek nyílt vagy zárt forráskódú megoldások igénybevételével tesznek-e eleget. Az elfogadás előtt álló Ekszjt. előírja, hogy a biztonságos és átlátható ügyintézés érdekében a központi rendszer kizárólag olyan infokommunikációs rendszereket vehet igénybe, amelyek biztosítják a szolgáltatásokat igénybe vevőkkel való biztonságos és folyamatos kapcsolatát. A szolgáltatás nyújtásához pedig kizárólag olyan, a vonatkozó szabványoknak és műszaki előírásoknak megfelelő, megbízható és a külön jogszabály szerint tanúsított informatikai rendszereket és termékeket használhat, amelyek lehetővé teszik a hiteles dokumentumcserét, az elektronikus dokumentumok sértetlenségét és védettségét, valamint az informatikai rendszerekben tárolt adatok archiválását. Az elektronikus közszolgáltatás során minden, a

szolgáltatásnyújtásban közreműködő szereplőt érintő általános kötelezettség, hogy biztosítani kell a személyes adatok védelméről, a közérdekű adatok nyilvánosságáról szóló jogszabályokban foglalt követelmények érvényre juttatását. Az Ekszjt már az elektronikus közszolgáltatás alapelvei körében általános követelményként írja elő a személyes adatok védelme, informatikai biztonság, a más informatikai rendszerekkel való együttműködés, az üzemeltetés folytonossága követelményének érvényesülését. Az elektronikus közszolgáltatások feltételrendszere körében a törvény azt is kifejezett feltételként jelöli meg, hogy a központi rendszerhez való csatlakozásra kötelezett vagy jogosult szervezet a csatlakozás előfeltételeinek, a szolgáltatásnyújtás folyamatosságával, biztonságosságával, hatékonyságával és hitelességével kapcsolatos követelményeknek megfeleljen, és ezt a szolgáltatás megkezdése

előtt, illetőleg rendszeres időközönként a szolgáltatásnyújtás során megfelelő szakértővel tanúsítsa. A követelményrendszer meghatározása, az alkalmazott szabványok, működési előírások meghatározása állami feladat, a tanúsítás műszaki része azonban független szakértői tevékenység. Az elektronikus közszolgáltatásokkal szemben támasztott hitelességi és minőségi követelmények érvényesülését, a hálózat informatikai biztonságát, az elektronikus szolgáltatások rendelkezésre állását a Kormány a közigazgatási informatikáért felelős miniszter útján ellenőrzi [Ekszjt. 18– 31. §] 2009. június 15 198 9.5 Az elektronikus ügyintézési eljárásban alkalmazható dokumentumok, dokumentumkezelés, elektronikus irattározás Az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól szóló 12/2005. (X 27) IHM rendelet hatálya a közigazgatási hatósági eljárás

ügyfeleire, az eljárás egyéb résztvevőire és a hatóságra terjed ki. A jogszabály az elektronikus eljárásokban elfogadható dokumentumokat és az ettől való eltérés lehetőségét rögzíti, elsősorban a hatóságokat kötelezi a megfelelő dokumentumok elfogadására és kezelésére. A rendelet alkalmazásában speciális fogalmakat is bevezet (az elektronikus dokumentum formátuma, az elektronikus dokumentumnak minősülő beadvány, a szabvány, az elektronikus ügyintézési eljárás, az elektronikus tájékoztatási szolgáltatás, a közigazgatási hatósági eljárás és az informatikai szempontból értelmezhető beadvány). Az elektronikus dokumentum formátuma az a műszaki előírás, amely az elektronikus dokumentum értelmezhetőségének biztosítása céljából összefüggő módon rögzíti a dokumentumfajta műszaki jellemzőit, felépítését, adatszerkezetét, vagy a dokumentumot tároló elektronikus adathordozóval szemben támasztott

követelményeket. A rendelet 1 mellékletében közzéteszi az alkalmazható formátumokat, amelyek az adatmegjelenítésre, elektronikus levelezésre és elektronikus aláírásra vonatkoznak, a 2. melléklet, pedig a rejtjelezés és visszaállítás, valamint az elektronikus adathordozóval kapcsolatos formátumokat írja elő (1. §) A hatóság által elfogadhatónak minősül az a beadvány, amelyet nemzetközi szabványügyi szervezet vagy az Egyesült Nemzetek Szervezetének valamely szakosított intézménye tett közzé, vagy a formátum követelménye ingyenesen és nyilvánosan hozzáférhető, továbbá széleskörűen elterjedt. Az ilyen beadványt a hatóság a Ket. 161 §, (1) bekezdése értelmében informatikai szempontból értelmezhetőnek tekinti, ha a korlátlan hozzáférést nem akadályozzák olyan műszaki intézkedések, mint például a rejtjelezés, a nyomtatási korlátozás, amelyeket az ügyfelek előre nem közöltek a hatósággal, vagy a hatóság

előzetesen nem járult hozzá a használatukhoz. Ha a hatóság külön jogszabályban meghatároz adott tulajdonságú beadványt, akkor az értelmezési kötelezettség erre a beadványra érvényét veszti. Ez a kitétel vonatkozik az 193/2005. (IX 22) Korm rendeletben vagy a 195/2005 (IX 22) Korm rendelet 22. §, (2) bekezdésében leírt esetekre A hatóság elektronikus tájékoztatót ad ki, amelyben kifejti, hogy a rendelet 2 mellékletében felsorolt szabványok szerinti formátumokat is értelmezhetőnek tekinti, ha erről előzetesen így döntött (2. §) 2009. június 15 199 A hatóság a 2. §-ban foglalt követelményeknek nem megfelelő beadványokat is elfogadja és értelmezi, ha az informatikai és hírközlési miniszter és a Miniszterelnöki Hivatalt vezető miniszter is egyetért ezzel. Ennek érdekében a hatóság a miniszterekhez benyújtja a formátum meghatározását, részletes leírását, a szabvány megnevezését és annak a közigazgatási

hatósági eljárásnak a megnevezését, amelyben elfogadja a formátumot. A miniszterek olyan elveket érvényesítenek a beadványokat illetően, amelyek elősegítik a közigazgatási informatika rendszerei közötti együttműködést, ezek egységes használatát és előnyben részesítik a nyílt és nemzetközi szabványokat. Ezen – a 3. §, (2) bekezdésben található – elvek érvényesülését segítik elő a miniszterek gyűjtése, rendszeres felülvizsgálatai, és a 7. § szerinti előírásoknak megfelelő közzététele A formátumra vonatkozó közzétételekben megjelölik a szabvány megnevezését, az érintett közigazgatási hatósági eljárás megnevezését, a szabvánnyal kapcsolatos korlátozásokat és egyéb jellemzőket. A formátum tartalmának megváltoztatása esetén az előző formátum az új formátum közzétételétől számított 60 napig értelmezhetőnek tekinthető. A hatóság a miniszterek egyetértése nélkül is közzétehet más

formátumot, ami a miniszterek által nyilvánosságra hozott listán szerepel, ha ez a rendeletben egyébként meghatározott módon történik (3. §) A hatóság az ügyféllel történő előzetes írásbeli megállapodása alapján a 2. §-ban és a 3 §-ban leírt formátumoknak nem megfelelő egyéb beadványt is elfogad (4. §) A hatóság külső szervnek vagy személynek a 2. § szerinti követelményeknek megfelelő formátumban, vagy a következő feltételek szerint küldhet elektronikus dokumentumot Ha az ügyfél a 3 § szerint a hatóság által az adott eljáráshoz közzétett listán szereplő, illetve a 4. § szerinti formátumú beadványt nyújt be a hatóságnak, akkor a hatóság az ügyfélnek az általa benyújtott formátumú elektronikus dokumentumot küldhet Abban az esetben, ha az ügyfél előre jelzi, hogy ezen formátumokat nem tudja értelmezni, a hatóság nem küldhet ilyen formátumú dokumentumot. Ügyfélnek nem minősülő külső szerv részére

a hatóság csak a miniszterek listáján szereplő formátumú dokumentumot küldhet. Eltérő formátumú elektronikus dokumentum a 6 §, (1) bekezdése szerint átalakítható a 2. § szerinti követelményeknek megfelelő formátumú dokumentummá, és ezt a hatóság már elküldheti külső szervnek vagy személynek (5. §) A hatóság biztosítja azt, hogy fogadni és értelmezni tudja a 2–4. §-ban leírt feltételeknek megfelelő elektronikus dokumentumokat, illetve azt is, hogy képes legyen a fogadott és a saját informatikai rendszerében használt elektronikus dokumentumokat műszaki lehetőségtől függően a 2. § szerinti feltételeknek megfelelően átalakítani A 2 § és 3 § szerint nem értelmezhető dokumentumokat legkésőbb a levéltárba adásig a hatóságnak át kell alakí2009. június 15 200 tania e paragrafusok szerinti feltételeknek megfelelő formátumú elektronikus dokumentummá (6. §) A hatóság a közzététellel egyidejűleg

tájékoztatja a Miniszterelnöki Hivatalt vezető minisztert a rendeletben meghatározott szabványok szerinti formátumnak megfelelő és nem megfelelő formátumokkal kapcsolatos közzétételről. A Miniszterelnöki Hivatalt vezető miniszter gondoskodik az előbb említett közlések, valamint az informatikai és hírközlési miniszterrel való egyeztetés alapján készült lista közzétételéről és frissítéséről Ha a hatóság a Ket 8. §, (3) bekezdése alapján nem nyújt elektronikus tájékoztató szolgáltatást, akkor a tájékoztatási kötelezettségének a honlapján, és a fent említett hatósági és miniszteri közzététel útján tesz eleget. A miniszteri listát az informatikai és hírközlési miniszter által üzemeltetett honlapon is közzéteszik és frissítik (7. §) A Ket. az elektronikus ügyintézés összefüggésében bizonyos, az eljárással összefüggő cselekmények – az elektronikus módozatból adódóan sajátos követelményeket is

felvető – gyakorolhatóságáról is rendelkezik Ilyen, a – kormányrendeleti szintű – végrehajtási rendeletekben részletesen kibontott, alapvetően azonban a Ket.-ben szabályozott követelmény, hogy az elektronikus ügyiratba történő betekintés az általános betekintési szabályok megtartásával és a betekintés dokumentálásával történhet, illetőleg hogy a hatóság az eljárás során keletkezett elektronikus dokumentumról a másolat készítésére jogosult személy kérésére, a jogosult választása szerint, hitelesített elektronikus, illetve hagyományos, papír alapú másolatot ad ki.11 A hagyományos és elektronikus eljárások összekapcsolását biztosító eljárásoknak minősülnek: a papír alapú dokumentumról elektronikus másolat készítése, elektronikus dokumentumról papír alapú másolat készítése, elektronikus adathordozón nem elektronikus úton benyújtott elektronikus dokumentumról elektronikus másolat készítése. Ha

jogszabály ezt nem írja elő, az ügyfél nem köteles ugyanazt a dokumentumot a fentiek közül többféle módon a hatóságnak benyújtani. Amennyiben az eredeti beadvány papír alapú vagy elektronikus adathordozón érkezett, és erről készült elektronikus másolaton alapul az elektronikus ügyintézés, akkor az elektronikus másolatot készítő hatóság más hatóság számára köteles azt hivatalból átadni. Az elektronikus kormányzati ügyintézési platform megvalósítása iránti igény felerősödésével egyidejűleg, és az időközben bekövetkezett, illetőleg tervbe vett jogalkotási törekvésekkel, felhatalmazásokkal összhangban12 alapvető követelményként jelent meg egy egységes, új (a papír alapú és elektro11 12 Lásd 193/2005. (IX 22) Korm rendelet 24–27 §, illetve 30–31 § Lásd különösen Eat. 27 §, (3) bekezdés, A kormányzati elektronikus aláírási rendszer kiépítésével összefüggő egyes feladatokról és a kormányzati

hitelesítésszolgáltató felállításáról szóló 1026/2002. (III 26) Korm határozat 4 pont, A 2009. június 15 201 nikus módozatot egyaránt átfogó) iratkezelési rend kialakítása. Erről A közigazgatási szervek egységes iratkezelésének koncepciójáról szóló 2205/2003 (IX. 4) Korm határozat rendelkezett E határozat 2 pontja – a határozat mellékleteként közzétett koncepció alapján – 2004. június 30-ai határidővel elrendelte, hogy az érintett miniszterek feladat- és hatáskörüknek megfelelő felelősségi körben dolgozzák ki az iratkezelés egységességéhez szükséges jogszabályokat. A feladat megvalósítására a MeH EKK 2003 november 11én indított (az IHM, a BM, az NKÖM, az IM és a HM közreműködésével lebonyolított) „Közigazgatási szervek egységes iratkezelési szabályozása” témájú projektjével került sor. Az ennek eredményeként kialakult szabályozási modell az indokoltnak tartott

jogszabály-módosításokra és új jogszabályok megalkotására egyaránt javaslatot tett. A javasolt – többrétegű – szabályozás lehetőséget kívánt teremteni arra, hogy olyan iratkezelési gyakorlat alakuljon ki, amely hatékonyan segíti a közfeladatot ellátó szervek rendeltetésszerű működését, feladataik gyors és eredményes megoldását, illetőleg biztosítani tudja a papír alapú és az elektronikus iratok egységes alapelvre épülő együttes kezelését, a közfeladatot ellátó szervek tevékenységének biztonságos és hiteles dokumentálását, átláthatóságát, irataik épségben és használható állapotban történő megőrzését és használatát. A köziratokról, a közlevéltárakról és a magánlevéltári anyag védelméről szóló 1995. évi LXVI törvény módosításáról szóló 2005 évi CXLIX törvény, 2006. január 1-el hatályba lépett rendelkezéseivel elérni kívánt legfontosabb cél – a szolgáltató

közigazgatás elvének megfelelően – az elektronikus ügyintézés lehetőségének megalapozása, elsősorban a hatósági ügyintézés szakszerűségének és gyorsaságának növelése, a maradandó értékű információk fennmaradásának és megőrzésének biztosítása volt. E cél elérése érdekében alapkövetelménynek tekintette a hagyományos (papír alapú) és az elektronikus iratok kezelésére egyaránt alkalmas, az európai gyakorlathoz illeszkedő, a folyamatosan fejlődő informatikai technológia fogadására képes és az elektronikus levéltár kialakításához alapot adó szabályozás megteremtését. Az Ltv. 9 §-ának (1) bekezdése a köziratok kezelésének alapvető követelményeit az irat anyagától, a készítéséhez használt eszköztől és eljárástól függetlenül határozza meg E rendelkezések az elektronikus iratokra is alkalmazhatók, ám esetükben ezek a követelmények nem tekinthetők teljes körűnek Az elektronikus iratok

esetében további, alapvető követelmény az is, hogy a közfeladatot ellátó szerv megfelelő és biztonságos adatátvitelt, valamint a gazdaságos adattárolást, megőrzést és hozzáférést biztosító szoftvereket alkalmazzon iratkezelési célra. A törvénymódosítás felhatalmazta a Kormányt közigazgatási hatósági eljárás általános szabályairól szóló törvény szabályozási koncepcióját meghatározó 1005/2003. (I 30) Korm határozat 1/g pont 2009. június 15 202 arra, hogy rendeletben szabályozza a közfeladatot ellátó szervek iratkezelésével összefüggő követelményeket [Ltv. új szövegű 35/A §, (1) bekezdés] E felhatalmazás alapján került elfogadásra A közfeladatot ellátó szervek iratkezelésének általános követelményeiről szóló 335/2005. (XII 29) Korm rendelet, mely főszabály szerint 2006 január 1-jével lépett hatályba Az Ltv. tehát minden közfeladatot ellátó szerv számára kötelezővé tette a külön

jogszabályban meghatározott tanúsítvánnyal rendelkező iratkezelési szoftver alkalmazását. Az ily módon meghatározott követelmények teljesítéséért, valamint az iratok szakszerű és biztonságos megőrzésére alkalmas irattár kialakításáért és működtetéséért, továbbá az iratkezeléshez szükséges egyéb tárgyi, technikai és személyi feltételek biztosításáért, valamint a megfelelő tanúsítvánnyal rendelkező iratkezelési szoftver használatáért a közfeladatot ellátó szerv vezetője felelős. Ezzel összefüggésben kapott felhatalmazást a belügyminiszter arra, hogy az informatikai és hírközlési miniszterrel, valamint a nemzeti kulturális örökség miniszterével együttesen, rendeletben állapítsa meg a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftvereknek, valamint az elektronikus iratok tárolásával és levéltárba adásával kapcsolatos követelményeket. A közfeladatot ellátó szerveknél

alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekről szóló 24/2006. (IV 29) BM – IHM – NKÖM együttes rendelet hatálya a közfeladatot ellátó szervekre és a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverek megfelelésének külön jogszabály szerinti tanúsítását végző szervezetekre terjed ki. A közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekre vonatkozó követelményeket a rendelet melléklete határozza meg A rendeletben megadott előírásokat a minősített adatok kezelésére vonatkozó iratkezelési szoftverekre csak abban az esetben kell alkalmazni, ha külön jogszabály erről rendelkezik. Az Iratkezelési Szoftver (ISZ) kommunikációs felületére (export/import interface) vonatkozó pontos leírást (a kötelező vagy használható adatformátumokra, az adathordozók minőségi előírásaira és a metaadatok megnevezésére, sorrendjére, ismételhetőségére, kitöltésére

vonatkozó információk, használható irattípusok stb.) a belügyminiszter az informatikai és hírközlési miniszterrel, és a Miniszterelnöki Hivatalt vezető miniszterrel egyetértésben állapítja meg, és tájékoztatóban teszi közzé a Belügyminisztérium honlapján, illetve hivatalos lapjában. A rendelet előírt formátumnak az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól szóló 12/2005. (X. 27) IHM rendeletben (formátum rendelet) előírtak szerinti olyan formátumot tekinti, amelyet a közigazgatásban, az elektronikus kapcsolattartásban el kell fogadni A rendelet alkalmazásában iratkezelési szoftvernek az iratkezelési rendszer működését támogató, iktatási funkcióval rendelkező szá2009. június 15 203 mítástechnikai program vagy programok egymást funkcionálisan kiegészítő rendszere minősül. Ennek általánosságban meg kell felelnie a közfeladatot ellátó szervek

iratkezelésének általános követelményeiről szóló 335/2005 (XII 29.) Korm rendeletben megfogalmazottaknak, különösen pedig az együttes rendeletben meghatározott, komplex – az iktatókönyvvel, irattári tervvel, iktatással, iratkezeléssel, informatikai- és adatbiztonsággal, selejtezéssel, megjelenítéssel stb. – összefüggő előírásoknak Az iratkezelési szoftverek Rendeletnek való megfelelését az Önkormányzati és Területfejlesztési Minisztérium kijelölése alapján független tanúsító szervezetek ellenőrzik és tanúsítják.13 Az ISZ-ek esetében természetesen a követelményeknek megfelelő, nyílt szabványokon alapuló technológiák is alkalmazhatók. A gyakorlatban ugyanakkor komoly problémát jelent, hogy az általánosabban elterjedt rendszerek általában csak a – közigazgatási célra is felhasználható – elektronikus aláírások Windows XP, illetve Windows 20022003 környezetben működő alkalmazását támogatják. 13

Lásd a Kormányzati Iratkezelési Felügyelet honlapját : http://www. bm.hu/web/portalnsf/html/kifhtml, illetve http://www.otmgov hu/web/portal.nsf/html/kifhtml A tanúsított szoftverek listája a http: ://www.bmhu/web/portalnsf/web iktszoft?OpenView, illetve a http: ://www.otmgovhu/web/portalnsf/web iktszoft?OpenView címen, a tanúsított szervezetek felsorolása a http://www.otmgovhu/web/portal nsf/html/7E8CB8D1A90A0D61C1257147003D814A/$file/KIFtanus%C3%ADt%C3% B3szervezetek.pdf?OpenElementcímen érhető el A szoftverek beszerzéséhez kiadott szakmai útmutató (a szoftvereket beszerző szervezetek a jogszabályi keretek közötti döntési szabadságát tiszteletben tartva) az OSS-szoftverekkel szemben sem kliensoldalon, sem a szerver vagy adatbázis operációs rendszerek esetében közvetlenül nem preferálja az „üzleti” alkalmazásokat, a kliensoldali szoftverek (iratkezelési programok) az OSS-megoldások esetében azonban hangsúlyozza a Windows-verziókkal való

kompatibilitás érvényesítésének igényét. A szoftverek beszerzését célzó szerződésekkel szembeni követelmények – a biztonságossági, interoperabilitási, jogszabályi előírásokkal egyébként összhangban – úgy kerültek kialakításra, hogy azok a licencia átadására való jogosultságot, a terméktámogatást, a működésre vonatkozó gyártói/forgalmazói garanciát tartalmazzák (Lásd http://www.otmgovhu/web/portal nsf/dokumentumtar/9CD35478D2E7B7C1C125757500488AE1/$file/Szakmai%20% C3%BAtmutat%C3%B3%20az%20iratkezel%C3%A9si%20szoftverek%20beszerz% C3%A9s%C3%A9hez.pdf?OpenElement) 2009. június 15 204 2009. június 15 10. fejezet Az ODF formátum kezelésének lehetőségei az állam- és közigazgatásban 10.1 Az OpenDocument Formátum, valamint az ODF Alliance Összefoglaló Az irodai alkalmazások egyik hivatalosan (ISO által) elfogadott szabványa az OpenDocument Formátum (ODF). Ez a formátum, konkurenseivel ellentétben ráadásul

platform- és gyártófüggetlen. Fejlesztése egy nyílt, több forgalmazóból, részvényesekből álló szervezet, az OASIS (Organization for the Advancement of Structured Information Standards) nevéhez fűződik. Az ODF egy nyílt, XML alapú fájlformátum, amely irodai dokumentumok, tehát táblázatkezelő dokumentumok, diagrammok, valamint bemutatók megjelenítésére, tárolására és szerkesztésére használatos. Használata teljes mértékben ingyenes, mindenféle licenc-, jogdíj és egyéb korlátozástól mentes. 2006 májusában egyhangú döntéssel az International Organization for Standardization (ISO) és az International Electrotechnical Commission (IEC) szabvánnyá minősítette (ISO/IEC 26300). Az ODF lehetővé teszi, hogy az információáramlást ne befolyásolja a platform, az alkalmazás, illetve a technológia, vagy a gyártó változása. Akik adataik tárolására a nyílt dokumentum formátumot választják, nem kényszerülnek rá, hogy egy

szoftvergyártó mellett maradjanak, hanem szabadon válthatnak, ha az adott forgalmazó kivonul a piacról, árat emel, megváltoztatja a kínált alkalmazást, megváltoztatja a licencfeltételeket, vagy egyéb, a felhasználó számára kedvezőtlen döntést hoz. Az ODF elfogadása különöskép205 206 pen az állami szférában indokolt, mivel garantálja, hogy a jelenleg készített hivatalos dokumentumok nem esnek a technológiai fejlődés áldozatává. A fenti előnyöket és lehetőségeket belátó kormányok már világszerte átállnak az ODF1 használatára. Több, mint negyven, az ODF formátumot támogató alkalmazás közül választhatunk a piacon.2 A 2006 márciusában alakult ODF Alliance támogatja és terjeszti az ODF használatát azzal a céllal, hogy a közszféra nagyobb felügyelettel és közvetlenebb kezeléssel bírjon saját dokumentumai fölött. Az ODF mögötti jelentős háttérerőt mutatja az ODF Alliance egyre növekvő taglétszáma is. A

növekedésre jellemző, hogy a kezdeti 36 tag után mára 58 országból több, mint 530 szervezetet mondhat tagjának. 10.11 Az Open Dokumentum Formátum legfontosabb előnyei Időállóság. Nyílt szabványként teljes körű hozzáférést kínál a dokumentum tartalmához, szerkezetéhez. Ezzel garantálva, hogy a jövőben bárki, bármikor használni fogja tudni a dokumentumot.3 Választási lehetőség. Az egyes irodai csomagok között formátum szempontjából átjárhatóságot és kompatibilitást nyújt, ezzel az ODF a kormányoknak a versenyt élénkítő választási lehetőséget kínál az egyes forgalmazók között, beleértve mind a kereskedelmi licencű, mind pedig a szabad, valamint nyílt forrású alkalmazásokat. Versenyteremtés. Azzal, hogy a dokumentum formátum az ODF által egységesül, támogatja a piacon szereplő irodai alkalmazások fejlesztését, a felhasználó jobb kiszolgálását célzó versenyét. 10.12 Az Open Dokumentum Formátum

hátrányairól, a bevezetés problémáiról Szervezetünk – az ODF Alliance Magyarország – véleménye szerint egy ISO szabványként is elfogadott nemzetközi támogatással rendelkező gyártóés platformfüggetlen dokumentum formátumnak (ODF), melyet több gyártó, 1 http://www.odfallianceorg/resources/Adoptions−ODF−Aug2008pdf http://www.odfallianceorg/resources/AppSupport20Dec2007pdf 3 Semmiféle jogi akadálya nincs és nem lehet (az ODF nyílt szabvány) a jövőben sem annak, hogy bárki ODF formátumot kezeljen. Így a dokumentum a technika változásaitól függetlenül olvasható maradhat, mivel bárki bármikor készíthet ODFkezelő alkalmazást. 2 2009. június 15 207 több alkalmazása támogat, s melyet több kormányzat használ, és egyre több kíván használni, nincsenek hátrányai. A formátumot kezelő alkalmazásoknak lehetnek hátrányos tulajdonságaik, egymáshoz vagy más hasonló célú, de nem ODF formátumot kezelő alkalmazáshoz

képest. A bevezetés során felmerülő problémák – Törvényi, jogszabályi támogatottság hiánya. – Nem problémamentes együttműködés, más nem ODF formátumot használó szervezetekkel. – Nem jó szerkezetű, automatikusan nem konvertálható dokumentumok. – Olyan alkalmazások, melyek kizárólag csak egy ODF-et nem, vagy nem jól kezelő szoftverrel képesek együttműködni. – Olyan alkalmazások, melyek ugyan ismert, az ODF-et kezelő alkalmazással is kezelhető formátumot adnak ki magukból, de az általuk készített állományok az ODF-et kezelő alkalmazással mégsem jól kezelhetőek. – Felhasználói ellenállás. • Presztízsből. • Tudatlanságból. – ODF-kezelő alkalmazás oktatásának túlhangsúlyozottsága, s e miatti magas költsége.4 – Nyelvi problémák, amennyiben a használni kívánt nyelven a használni kívánt alkalmazás nem érhető el.5 10.2 „Miért éppen az ODF ?” Az Open Document Formátum jelentősége a

kormányzat számára A mai kormányzati, közigazgatási munka és az állampolgári lét, nélkülözhetetlen tartozékai a dokumentumok. A kormányzat a dokumentumokból 4 Ez egyszerűen nem lehet indokolt, a szegedi példa is a kevés oktatás elegendőségét igazolja. 5 Ennek kevés kivétellel a gyártófüggőség vagy a rossz alkalmazás választása az oka. 2009. június 15 208 tesz szert ismeretekre, dokumentumokban tárolnak kényes adatokat, valamint dokumentumokkal tartanak kapcsolatot az egyes részlegek egymásközt, illetve az üzleti partnerekkel és az állampolgárokkal. A papír alapú dokumentumokat egyre inkább felváltja az elektronikus forma Ahhoz, hogy a kormányok alkalmazni tudják az állandóan változó technológiát és üzleti folyamatokat, bizonyosságra van szükségük, hogy most és bármikor a jövőben hozzáférhetnek, helyreállíthatják és használhatják kényes adataikat. Az OpenDocument Formátum (ODF) a szabványos

fájlformátumával biztosítja ezeket a követelményeket, és dokumentumaik fölött teljes körű rendelkezési lehetőséget nyújt. 10.21 Az ODF hozzájárulása a back-office rendszerek korszerűsítéséhez Könnyen implementálható az ODF kezelés a különböző alkalmazások kimeneti, illetve bemeneti formátumaként, mivel az ODF egy szabványos, mégpedig nyílt szabványban rögzített formátum. Az ODF formátum használata lecsökkenti a rendszert használó munkaállomások szoftver-költségeit, mivel ODF formátumot kezelő irodai csomagot, a valós verseny miatt kedvező áron, az OpenOffice csomagot például költség nélkül is beszerezhetjük. Az ODF formátum platform- és gyártófüggetlen, ezért ennek használata nem köti platformhoz (operációs rendszerhez) és gyártóhoz az ezt kezelő, kezelni kívánó rendszereket. Összefoglalva: – Szabványos formátumot biztosít a rendszerek ki- és bemeneti dokumentumainak. – Nem akadálya a

platformfüggetlenségnek szerver oldalon. – Nem akadálya a platformfüggetlenségnek kliens oldalon. – Csökkenti a rendszer elérésének, használatának költségeit. 10.22 Az ODF az ISO által hivatalosan elfogadott nyílt fájlformátum szabvány Az ODF az irodai alkalmazások nyílt szabványa, mely teljes mértékben gyártófüggetlen. Fejlesztése egy nyílt, több gyártóból, részvényesekből álló szervezet, az OASIS (Organization for the Advancement of Structured Information Standards) nevéhez fűződik. Az ODF egy nyílt, XML alapú fájlformátum, amely irodai dokumentumok (táblázatok, diagrammok, bemutatók, 2009. június 15 209 szövegek) megjelenítésére, tárolására és szerkesztésére alkalmas. Az ODF formátum használata teljes mértékben ingyenes, mindenféle licenc-, jogdíj és egyéb korlátozástól mentes. Az ODF 10 formátumot 2006 májusában egyhangú döntéssel az International Organization for Standardization (ISO) és az

International Electrotechnical Commission (IEC) szabvánnyá minősítették. 10.23 Az ODF-et választó kormányok és vállalatok Az ODF támogatottsága és használata folyamatosan nő, ezzel bizonyítva, hogy az irodai alkalmazások terén az egész világon szükség van a teljes körű hozzáférésre és az alkalmazások közötti választás lehetőségére. Az ezt belátó kormányok például már világszerte meghozták az ODF-re átállással kapcsolatos döntésüket. Az ODF és a nyílt szabványok használatát az elsők között vezette be Belgium, Brazília, a Massachusetts-i Nemzetközösség, Dánia, Norvégia, Franciaország, valamint Thaiföld.6 Ezeken a kormányokon kívül más országokban is sikerrel használják az ODF támogatású alkalmazásokat. Ma már világszerte több, mint 50 központi felügyelet és állami/helyi szervezet használ ODF támogatású alkalmazást. A kormányok és a felhasználók igényeinek megfelelni szándékozó, és a

szabványokat követő cégek sorra megvalósították termékeikben az ODF szabványú állományok kezelését. Számos ODF támogatást tartalmazó alkalmazás található, kezdve a nyílt forrású OpenOffice.org-tól és Koffice-től a Google Docs-hoz hasonló web-alapú alkalmazásokon át egészen a kereskedelmi termékekig, mint például a Sun StarOffice-a, vagy az IBM Lotus Symphony alkalmazása, hogy csak párat megemlítsünk a több, mint 40 alkalmazásból.7 10.24 Előnyök a kormányzat számára 1. Adatok birtoklása Ma a nem ODF-et használó kormányzatok valójában nem rendelkeznek saját dokumentumaik fölött A jövőben elveszthetik a hozzáférés, módosítás és mentés lehetőségét archív dokumentumaik esetében Az ODF – mint nyílt és állandó szabvány – biztosítja, hogy a technológia fejlődése során a ma készült dokumentumok a jövőben mindig használhatók maradnak, valamint a kormányok sose függjenek egyetlen gyártótól sem, ha az

adataikat szeretnék használni. 2. Hozzáférés A régebbi dokumentumokhoz való hozzáférés valós probléma, a kormányzatok és az állampolgárok is fölöslegesen sok problémával 6 7 http://www.odfallianceorg/resources/Adoptions20Dec2007pdf http://www.odfallianceorg/resources/AppSupport20Dec2007pdf 2009. június 15 210 találkoznak, ha meg akarnak nyitni egy régebbi fájlt. Amikor esetleg sikerül, akkor is előfordul, hogy a változásnak, fejlődésnek köszönhetően olvashatatlan, de legalábbis nehezen olvasható. Az ODF teljes nyíltsága megoldást jelent erre a problémára. 3. Kompatibilitás Az ODF segít abban, hogy a dokumentumot (adatokat) teljesen elkülönítsük a készítő alkalmazástól, így a dokumentum bármilyen egyedi változtatástól, vagy korlátozástól függetlenül pontosan és megfelelően használható más alkalmazásokkal is. 4. Verseny Mivel az ODF teljesen nyílt szabvány, az ezt kezelő alkalmazások funkcionalitás és ár

terén versenyeznek 5. Választás lehetősége A kormányokat gyakran köti meg egyetlen cég a frissítés menetével, stratégiájával és árával. Az ODF a verseny léte miatt választási lehetőséget nyújt a gyártók között, ideértve a nyílt forrású és szabad alkalmazásokat is. 6. Kedvező ár Az ODF használata költséghatékony, mivel az ODF-kezelő alkalmazások közti verseny több megoldást kínál (köztük a nyílt forrású és szabad megvalósításokat). Ez kedvező az állampolgároknak is, mivel nem kell egy bizonyos alkalmazást megvenniük ahhoz, hogy hozzáférjenek a kormányzati dokumentumokhoz, ők is akár szabad, nyílt forrású – gyakran ingyenes – termékeket is használhatnak. 7. Innováció Az ODF platformfüggetlen formátumot kínál, melyhez bármely cég fejleszthet, vagy kínálhat új alkalmazásokat, vagy szolgáltatásokat Mivel nyílt szabvány, még a jövőbeni kiegészítések hozzáadása után is hozzáférhetőek maradnak

a dokumentumok. 8. A kulturális örökség megőrzése Ma egyre több történelmi jelentőségű dokumentumot készítenek, tesznek át és tárolnak digitális formátumban Elvárás, hogy ne csak a mai, hanem a következő generációk számára is elérhetőek legyenek ezek. Ennek a követelménynek az ODF megfelel, mert nyílt, XML alapú formátum. 9. Vészhelyzeti együttműködés A nyílt szabványok a vészhelyzetben kialakuló együttműködés során is elengedhetetlenek A thaiföldi szökőár pusztítása során a kormány, a hazai és a nemzetközi egységek nem tudták egymással megosztani az adatokat, illetve a kormány nem volt képes biztosítani a mentőegységek számára a hozzáférést az alapvető adatokhoz, mivel mindannyian más adat és dokumentumformátumot használtak. Vészhelyzetben a résztvevők számára a hozzáférés nem korlátoz2009 június 15 211 ható egyetlen szoftver használatára, mert ez plusz munkát és szervezést kíván, mely a

valós probléma kezelésétől von el erőforrásokat. 10.25 A nyílt szabványok, nyílt szabványú fájlformátumok jellemzői Közösségi, demokratikus, nyitott kialakítás, fejlesztés, gondozás. Csak jól meghatározott, együttműködő, demokratikus fejlesztő- és vezetőrészleggel rendelkező, nyílt, szabványügyi szervezet fejlesztheti, módosíthatja és ellenőrizheti. A nyílt és megfelelő hozzáférés szavatolásával és rögzítésével a követelmények a specifikációban megadhatók, előtérbe helyezhetők és egyesíthetők. Az egységes felépítés segíti a specifikáció megfelelő fejlődését a kapcsolódó és kiegészítő nyílt szabványok szélesebb környezetében, ezért egyetlen gyártó sem tudja mások hátrányára, kizárólag a saját igényeinek megfelelően megváltoztatni a szabványt. Korlátozások és jogdíjak nélkül hozzáférés. Bárki, beleértve a kormányokat is, szabadon betekinthet a specifikációba, illetve a

dokumentumok létrehozásához, módosításához és mentéséhez szabadon készíthet eszközöket, kiegészítőket. A szoftverek felhasználását semmi a szabványból származó megkötés nem korlátozhatja, legyen szó akár egyedi fejlesztésű kódról, egy gyártó nem ingyenes szoftveréről, vagy bármilyen közösség nyílt forrású alkalmazásáról. A nyílt szabvány szabad felhasználású. Bárki, bármilyen szoftverben, bármikor használhatja a szabvány által meghatározott megoldást, eszközt. A nyílt szabvány platformfüggetlen. Az egyes szoftvergyártók eszközeiket, melyek a szabványos formátumot kezelik, különféle platformokon fejlesztik. Ez nem okozhat a szabványból származó minőségbeli hátrányt A különféle gyártók által fejlesztett nyílt fájlformátumok növelik a választékot, hosszabb termékciklust ígérnek és ösztönzik az innovációt, de a többféle alkalmazást támogató specifikáció a kompatibilitást is javítja.

A nyílt fájlformátumnak megfelelő fejlesztések más termékekkel is teljes mértékben kompatibilisek, valamint biztosítják a felhasználók egymás közti könnyebb kapcsolattartását és az adatmegosztást. 10.26 Az ODF támogatása elvi kérdés Az ODF támogatása, használata elvi kérdés. Ahhoz hogy a nyílt szabvány előnyei gyorsabban érvényesüljenek, a következőkre kell figyelemmel lenni. 2009. június 15 212 – Az alkalmazásokban alapértelmezett formátumként a beépített ODFbe kellene „menteni”. – Az OASIS technikai bizottságában erősíteni kellene a részvényesek és a felhasználók részvételét, támogatni a megfelelő technikai közleményeket (például anyagi segítséggel), valamint a teljesen nyílt szabványok fejlődésében aktívabb részvételre lenne szükség. – Közvetíteni kellene a felhasználói igényeket az OASIS ODF Technikai Bizottsága felé. 10.27 Az ODF Alliance támogatást biztosító szervezet Az ODF

Alliance 2006 márciusában jött létre az Egyesült Államokban azzal a céllal, hogy képzéssel, információ-átadással, szakmai tudásbázissal segítse a közszolgálatban tevékenykedőket és törvényalkotókat abban, hogy az exponenciálisan növekvő mennyiségű elektronikus dokumentumokat elsődlegesen Open Document (ODF) formátumban tárolják. Az ODF mögötti erő nagyságát mutatja az ODF Alliance egyre növekvő taglétszáma is. A tagok száma a kezdeti 36-ról mára 56 országból több, mint 500 szervezetre gyarapodott. A szervezet honlapja információforrás azoknak, akik csatlakozni szeretnének, többet szeretnének tudni, vagy kormányuk be szeretné vezetni az ODF technológiát. Az ODF Alliance rendelkezik magyar tagozattal A nemzetközi szövetség tagjai közül néhányan az ODFA Magyarország megalakulásában is részt vettek. Ez az elfogadott világszabvány (ISO/IEC DS 26300) és nyílt platform, amelyet az informatikai ipar legfontosabb

szereplői egyként támogatnak, lehetővé teszi, hogy bármiképp is változzék a technológia, az elektronikus iratok teljes mértékben elérhetők, szerkeszthetők és menthetők legyenek akár évtizedek múlva is. Az ODFA magyar tagozatának tervei: 1. Az állam- és közigazgatás folyamatos ellátása információval és összehasonlító tanulmányokkal annak érdekében, hogy hazánkban is mielőbb ODF legyen az általános és alapértelmezett állami dokumentum formátum. 2. Olyan szervezetként működni, amely képes bárkinek – akár a civileknek is – segítséget nyújtani. 3. Tagok és a célokat támogatók bevonása 2009. június 15 213 4. Szoftverfejlesztők elérése 5. A társadalmi tudatosság növelése kampányok és rendezvények segítségével 10.3 Miért fontos a nyílt fájlformátum ? Életünkre egyre erőteljesebb hatást gyakorolnak az elektronikus adóbevallások, online pályázati űrlapok, internetes vásárlások és elektronikus

könyvtárak. A jövő tudástárai virtuálisan formálódnak, de hogy mi marad fenn a töménytelen információból és hogyan férhetünk majd hozzá néhány évtized múlva is, az most dől el. A zárt rendszerekben tárolt adatok súlyos következményeivel csak akkor szembesülnek a felhasználók, amikor már túl késő és már kiszolgáltatott helyzetbe kerültek. Milyen lenne olyan világban élni, ahol GSM telefonunkat nem használhatnánk korlátok nélkül, villanykörténket nem tudnánk bármelyik gyártó által készített lámpánkba becsavarni, CD-nket nem tudnánk az autóban és otthon a különböző készülékekben egyaránt lejátszani, a laptopunkon a betűk elrendezése gyártótól függően teljes összevisszaságot mutatna, a zongorákon pedig – készítőtől függően – más-más hang tartozna ugyanahhoz a billentyűhöz. A mindenki által elfogadott és támogatott egységes szabványok megkönnyítik az életünket, elősegítik a piaci

versenyt, és lehetővé teszik az összehasonlíthatóságot, így kordában tartják az árakat. A dokumentum formátumok tekintetében jelenleg még nem értük el ezt a világos és tiszta helyzetet. Monopolizált kvázi-szabványok uralják a piacot, amelyek segítségével bizonyos gyártók privilegizált helyzetet és monopolárat tarthatnak fent magunknak Ez többletkiadásokat jelent az államnak, az adófizetőknek és a cégeknek egyaránt. Ezen túl hosszú távon semmiképpen sem tekinthető biztonságosnak az egyetlen cégtől függő formátumok melletti elkötelezettség, mert így a felhasználó folyamatos, licenchez kötött fejlesztésekre kényszerülhet, és abban sem lehet biztos, hogy a különböző verziókkal elmentett dokumentumai kompatibilisek lesznek egymással. Más iparágakban a nyílt szabványok győzelmét nézve, alighanem az ODF is sikerre ítéltetett. Brazília, India és az USA egyes államai már kötelező érvénnyel be is vezették az

államigazgatásban. Az Európai Közösség 2010től irányelvben szabályozza, hogy a közbeszerzési eljárásokon csak a nyílt szabványoknak megfelelő termékekkel lehet indulni. Az, hogy a teljes siker, a függetlenség a formátumoktól – következésképpen a szoftverforgalmazóktól – a közeli, vagy távoli jövőben következik be, tőlünk függ. 2009. június 15 214 Egy olyan világban, ahol a papír alapú dokumentumokat egyre inkább helyettesítik az elektronikus adatok, nagyon fontos, hogy ezen adatok hozzáférhetőségét és használhatóságát hosszú távon is biztosítani lehessen. Ez különösen igaz a jogi szövegek és kormányzati dokumentumok esetében, amelyek évtizedekig, vagy akár évszázadokig is érvényben maradhatnak. De ugyanez lehet a helyzet személyes dokumentumok esetében is. Ahogyan papírt és tollat is lehetett kapni különböző gyártóktól, nem csak egyetlen forrásból, az elektronikus dokumentumok formátumának és az

azokat használó alkalmazásoknak is több, független gyártótól beszerezhetőnek kell lenni. Ez garantálhatja hosszabb távon is az adatokhoz való hozzáférést, még akkor is, ha egyik-másik cég időközben megszűnik, megváltoztatja az üzletpolitikáját, vagy ugrásszerűen megemeli az árait. Az ODF használatából adódóan – az azt kezelő alkalmazások közti választási lehetőséggel – a felhasználó fenntarthatja az általa alkotott dokumentum feletti ellenőrzést és rendelkezési lehetőséget, nem függ többé egyetlen gyártótól sem, meglesz az a lehetősége, hogy olvashassa és szerkeszthesse a saját művét. A nyílt szabványok – amelyek egyformán elérhetőek – nem részesítik előnyben egyik gyártót sem, segíthetnek fenntartani a különböző független gyártók rendszerét. Ugyanakkor létük ezáltal versenyképes árakhoz is vezet, elősegítve ezzel a befektetők vagy az adófizetők pénzének leghatékonyabb

felhasználását. A nyílt szabványok csökkentik az induló költségeket, így új gyártók is megjelenhetnek a piacon. Ezt történt például az SQL szabvány esetében, amely különböző implementációk megjelenését eredményezte, köztük nyílt forráskódú rendszerekét és speciális, nagy teljesítményű adatbáziskezelő rendszerekét is. Mindaddig, amíg csak szabványos SQL-t használnak, az adatbázisokban tárolt adatokat különösebb nehézség nélkül lehet átvinni egyik rendszerből a másikba. A felhasználó akár választhat egy olyan implementációt is, amely speciális, nem szabványos elemeket is alkalmaz, de ez az ő – és nem más – szabad döntése. Így az egy gyártótól függés saját szabad (jó vagy rossz) választás, nem pedig szerencsétlen szükségszerűség miatt lesz A kormányok által az állampolgárok számára készülő nyilvános dokumentumok esetében az is fontos, hogy egyetlen állampolgár se legyen kizárva az

anyagokhoz való hozzáférésből. Senkit sem volna szabad arra kényszeríteni, hogy megvásároljon egy kizárólagos gyártóhoz, vagy egyetlen operációs rendszerhez kötődő programot. A nyilvános adatokhoz minden állampolgárnak hozzá kell tudni férni, a jövedelmi helyzetétől vagy fizikai képességeitől függetlenül. 2009. június 15 215 10.4 Az ODF áttekintése Az OpenDocument Formátum (ODF) egy nyílt, XML alapú dokumentum fájlformátum olyan irodai alkalmazások számára, amelyek szöveget, számolótáblát, diagramokat és grafikus elemeket is tartalmazó dokumentumokat hoznak létre és szerkesztenek. A fájlformátum a más formátumokba való átalakítást, ahol csak lehet, egyszerűen a már létező szabványok felhasználásával oldja meg. Az ODF-et egy nyílt és átlátható eljárási rend alapján az OASIS (Organization for the Advancement of Structured Information Standards) határozza meg, és egyhangú szavazással fogadta el az ISO

(International Standards Organization) és az IEC (International Electrotechnical Commission) Együttes Technikai Bizottsága (Joint Technical Committee 1, JTC1) mint Nemzetközi Szabványt (IS) 2006 májusában. A szabvány mindenféle korlátozás, licencvagy egyéb fizetési kötelezettség nélkül, szabadon felhasználható 10.41 Az ODF technikailag Technikai szempontból az ODF egy ZIP archívum, amely XML fájlokat tartalmaz, amelyek a dokumentum tartalmát és megjelenítését írják le. Bináris fájlokat csak beágyazott objektumoknál (például képek esetén) használ A szabványos XML használata (bár az XML maga is ISO szabvány, mégis lehet nem a szabványnak megfelelően használni, bár ilyen esetben már az is kérdésé válik, hogy valóban XML-e, vagy csak tévesen annak nevezik) megkönnyíti a dokumentum tartalmának elérését, hiszen bármely egyszerű szövegszerkesztővel meg lehet nyitni, vagy módosítani, ha szükséges (ehhez – az egyszerű

szövegszerkesztővel történő kezeléshez – szakértelem kell). Ezzel ellentétben az eddig használt kizárólagos bináris formátumok esetében ez egy nehéz és bonyolult feladat volt. A tömörítés viszonylag kis fájlméreteket tesz lehetővé, ami csökkenti a tárolási kapacitás és az átviteli sávszélesség iránti igényt is, így könnyebbé válik a fájlok cseréje is. (Az ODF volt az első széles körben elterjedt dokumentum fájlformátum, amely becsomagolt XML fájlokat alkalmazott) Az ODF a különböző alkalmazástípusok esetén is ugyanazokat az XML fájlokat alkalmazza. Ezen felül, az egyes elemek (mint például a táblázatok) meghatározása is független az alkalmazástípustól 2009. június 15 216 10.1 ábra Különböző ODF alkalmazások 10.5 Nyíltnak tervezve : az ODF előnyei Az OpenDocument Formátumot gyártó- és alkalmazásfüggetlennek tervezték. Az volt a cél, hogy a lehető legtöbb alkalmazás használni tudja A szabvány,

ahol csak lehet, felhasznál már meghonosodott szabványokat is (például XHTML, SVG, XSL, SMIL, XLink, XForms, MathML és Dublin Core), hogy ezzel elősegítse az alkalmazásfüggetlenséget és a használhatóságot. A különböző alkalmazás-típusokhoz (például szövegszerkesztő, táblázat2009 június 15 217 kezelő) tartozó ODF fájlokban (azaz ZIP archívumokban) ugyanazokat az XML fájlokat találjuk. A 102 ábrán egy egyszerű szöveges dokumentumot és a hozzá tartozó ZIP archívum tartalmát láthatjuk. 10.2 ábra Egy ODF szöveges dokumentum tartalma A 10.3 ábra egy egyszerű ODF számolótábla tartalmát mutatja Látható, hogy mind a szöveges, mind pedig a számolótábla dokumentumnak ugyanaz a szerkezete, például mindkettő tartalmaz egy content.xml, egy stylesxml és egy meta.xml fájlt 10.3 ábra Egy ODF számolótábla tartalma A 10.4 és a 105 ábrák azt mutatják be, hogy egy szövegben elhelyezett és egy számolótáblában elhelyezett

táblázatot ugyanazokkal az XML elemekkel lehet megadni. A különböző típusú ODF dokumentumokban alkalmazott azonos nevű fájlok és a hasonló dokumentumelemekhez tartozó azonos XML elemek használata megkönnyíti az ODF dokumentumok feldolgozását és átalakítását. A 104 ábrán egy szöveges dokumentumba illesztett táblázathoz tartozó content.xml fájl tartalmát láthatjuk A 10.5 ábra egy számolótábla táblázatdefinícióját mutatja Ugyanezeket az XML elemeket láthattuk a szövegbe ágyazott táblázatnál is. 2009. június 15 218 10.4 ábra Egy szöveges dokumentumhoz tartozó contentxml fájl 10.5 ábra Egy számolótáblához tartozó contentxml fájl 10.1 táblázat: Az ODF előnyei Jellemző OASIS szabvány. Elfogadott ISO/IEC 26300 szabvány. ISO szabvány Relax-NG sématípusok (ISO/IEC 19757-2:2003). Előny Nyílt, átlátható specifikációs eljárás, több gyártó részvételével. Jól ismert és elfogadott szabvány. Jól ismert és

elfogadott szabvány. 2009. június 15 219 10.1 táblázat: (folytatás) Jellemző Többféle alkalmazás támogatja. Előny Választási lehetőség nyílt, ingyenes és kereskedelmi alkalmazások között, úgymint OpenOffice.org, StarOffice, KOffice, IBM Workplace, Textmaker, Abiword/Gnumeric, Google Docs & Spreadsheet és AjaxWrite. Széleskörű támogatottság. Az ODF garantálja a hosszú távú alkalmazhatóságot. Az OASIS ODF TC, az OASIS ODF Adoption TC és az ODF Alliance tagjai közé tartozik az Adobe, BBC, Bristol City Council, Bull, Corel, EDS, EMC, GNOME, IBM, Intel, KDE, Mysql AB, Novell, Oracle, Red Hat, Software AG, Sun Microsystems és Bécs Város Tanácsa. 2006 decemberében az ODF Alliance már több mint 350 tagot számlált. 2005 szeptembere óta elérhető ter- Az ODF fájlformátumot alkalmazó mékek. programok már 2005 szeptembere óta elérhetők. Ingyenes, nyílt forráskódú „referen- Az ODF fájlformátumot több incia” alkalmazások.

gyenes, nyílt kódú irodai alkalmazás is támogatja. Ilyen például az OpenOfficeorg, a KOffice és az Abiword/Gnumeric. Például az OpenOffice.org-ot egy széles közösség fejleszti, beleértve az olyan cégeket is, mint például a Sun Microsystems, a Novell, az Intel és a Red Hat. Mivel a forráskód szabadon hozzáférhető, ezért bárki kiegészítheti a támogatott operációs rendszereket. 2009. június 15 220 10.1 táblázat: (folytatás) Jellemző Minden jelentős PC operációs rendszerre elérhető alkalmazások. Űrlapoknál a W3C XForms technológiát használja. Létező szabványok alkalmazása. Nagy múltra tekint vissza. Előny ODF-et támogató alkalmazások léteznek a következő operációs rendszerekre: Microsoft Windows, Linux, Solaris OS, Apple Mac OS X és FreeBSD. Az ODF-be beépített űrlap definíció a W3C XForms szabványára épül, melyet szintén nagyon sok gyártó és alkalmazás támogat. Az ODF beépítette a következő

szabványokat: XHTML, SVG, XSL, SMIL, XLink, XForms, MathML és Dublin Core. Az ODF fájlformátum első munkálatai már 1999-ben elkezdődtek (lásd az ODF történetét az N.1 táblázatban) 2009. június 15 11. fejezet A Szabad Szoftver gazdasági hatása A szabad szoftverek alkalmazása és fejlesztése a jelenlegi világgazdasági helyzetben potenciális megoldási lehetőséget kínál a nemzetgazdaságok védelmére, erősítésére. Ez a modell növeli a szoftverek versenyképességét, mivel csökkenti a kereskedelmi szféra hasznát, a nemzeti nyelv használata miatt segíti a nemzetgazdaságoknak a belső szakemberek foglalkoztatottságát, lényegesen lazítja a szerzői jogok túlszabályozottságát. A szabad szoftver fogalom és licenc megalkotója – Stallman – alapvetően a szabadságjogok1 védelme érdekében alkotta meg ezt az ideológiát és hozzá a szoftver licenc típust, ám ezzel együtt megteremtette egy szoftverekkel kapcsolatos gazdasági modell

alapját is. 1 http://www.gnuorg/philosophy/free−swhuhtml A „szabad szoftver” elnevezés a felhasználók szabadságára utal. Azt jelenti, hogy a felhasználóknak szabad futtatni, másolni, közzétenni, tanulmányozni, megváltoztatni és tökéletesíteni a szoftvert. Pontosabban kifejtve a felhasználók négy különböző jogát jelöli : – A jogot arra, hogy futtassák a programot, bármilyen céllal. – A jogot arra, hogy tanulmányozzák a program működését, és azt a szükségleteikhez igazíthassák. Ennek előfeltétele a forráskód elérhetősége – A jogot arra, hogy másolatokat tegyenek közzé a felebarátaik segítése érdekében. – A jogot arra, hogy tökéletesítsék a programot, és a tökéletesített változatot közzétegyék, hogy az egész közösség élvezhesse annak előnyeit. Ennek előfeltétele a forráskód elérhetősége. 221 222 11.1 A szabad szoftver megismert üzleti modellje 11.11 A szoftverfejlesztés modellje A

közérthetőség okán a szoftverfejlesztést hasonlítsuk az árokásáshoz. A feladat specifikációja adott: X hosszú, K széles, Z mély árok szükséges. Ezt az árokásó – szemrevételezve a körülményeket – N összegért ássa ki. A munkája után megkapja a pénzét, s a továbbiakban nem érdekli, hogy valaki esetleg ás mellé még egy X vagy akár Y hosszúságú árokrészt. Azt persze reméli, hogy mivel jól (jó áron) dolgozott, legközelebb is őt hívják, s másoknak is ajánlják a munkáját, ezért igyekszik korrekten dolgozni, és olyan munkát végezni, melyet bárki megnézhet. Ez az árokásós példa a következők miatt szemlélteti a FLOS szoftverek üzleti modelljét. A szabad szoftveres cégek, illetve a szabad szoftverek fejlesztői hiszik a stallman-i elvet, amely szerint: a fejlesztői teljesítményért érdemes fizetni2 , és a fejlesztés eredményeként létrejött alkotást érdemes megosztani másokkal. Ezek a fejlesztők tehát a

munkájukért kívánnak pénzt kapni, és kaphatnak is, hozzávetőleg ugyanannyit, mint ha kereskedelmi szoftvereket fejlesztenének, hiszen a fejlesztői teljesítmény óradíjban, kódsorban vagy projekt-alapon mérhető. Stallman maga is említ példákat erre a modellre: „Néhány szabadszoftver-fejlesztő azzal keres pénzt, hogy support (technikai segítség) szolgáltatásokat nyújt. A Cygnus Support-nak körülbelül 50 alkalmazottja van [e cikk születésekor], és becslése szerint munkatársai tevékenységének körülbelül 15 százaléka szabad szoftver fejlesztése – ez elfogadható arány egy szoftvercégnél. Néhány vállalat, többek között az Intel, a Motorola, a Texas Instruments és az Analog Devices együttesen támogatják a C nyelvhez tartozó szabad GNU fordítóprogram további fejlesztését. Eközben az Ada nyelvhez tartozó GNU fordító fejlesztését az USA légierő finanszírozza – úgy gondolták, hogy ez a leginkább költséghatékony

módszer arra, hogy szert tegyenek a jó minőségű fordítóra. [A légierő által történő finanszírozás egy ideje 2 „Amíg egy ösztöndíj nem tette ezt szükségtelenné, évekig abból éltem, hogy megrendelésre kiegészítéseket írtam az általam írt szabad szoftverekhez. Minden ilyen kiegészítés bekerült a következő rendesen kibocsátott verzióba, és így végül az egész közösség számára elérhetővé vált. A megrendelők azért fizettek nekem, hogy az általuk áhított kiegészítéseken dolgozzam, és ne azokon a funkciókon, amelyeket én a legfontosabbaknak tartottam volna.” http://wwwgnuorg/philosophy/why− −free.huhtml 2009. június 15 223 befejeződött; a GNU Ada Fordító már üzemel, és a karbantartását kereskedelmileg finanszírozzák.]” 3 De ismertek ilyen magyar fejlesztések is4 A szabad szoftver hatásai egy ország gazdaságára Ha egy ország gazdaságát nézzük, akkor megint csak érdekes dolgokat jelent a

szabad szoftverek terjedése, s különösen érdekeseket az állam és közigazgatásbeli lehetséges térnyerésük. Ugyanis a szabad szoftverek használata: – az állam számára licencdíj megtakarításával jár, – élénkíti a gazdaságot, – munkahelyeket teremt, – megkönnyíti egy szabad, nyílt forráson alapuló szoftvervállalkozás elindítását. A licenc ára (külföldi szoftver esetén) nagyrészt kikerül a gazdaságból A kereskedelmi licencek esetén a vagyoni jogi jogosult többnyire egy – a kedvező adózást lehetővé tevő külföldi állami székhellyel rendelkező – leányvállalat. Ez azt jelenti, hogy a szerződéses viszony soha nem a magyarországi kereskedelmi képviselettel jön létre, hanem az amerikai vagy ír5 képviselettel, tehát az adóköteles bevétel ott keletkezik. Köztudott, hogy Magyarország az elmúlt években komoly, függő helyzetet alakított ki egyrészt az oktatásban, másrészt az állam és közigazgatásban

használt alapszoftverek többségénél.6 E szoftverek után valamely külföldi jogosultnak licencdíjat fizet A kereskedelmi licencek az esetek nagy részében minimális felhasználási módot engedélyeznek. Az engedélyezett használat joga a legtöbb esetben szintén korlátozott, az egyidejű futtatások számával, vagy akár a felhasználó személyével is összefüggésbe hozható. 3 http://www.gnuorg/philosophy/why−freehuhtml Lásd például a BalaBit Kft-ről e tanulmányban közzétett anyag (229. oldal) 5 A Microsoft esetén Európa területére a Microsoft Ireland Ltd. jogosít: „A GVH vizsgálata megállapította, hogy a Microsoft Magyarország Kft alapvetően csak marketinggel foglalkozik, feladata, hogy a termékek ismertségének a növelésével és oktatással segítse a viszonteladókat, továbbá az ügyfeleknél keresletet generáljon A Microsoft magyarországi nagykereskedelmi partnereivel (hivatalos disztribútoraival) szemben alkalmazott szerződéses

feltételek tárgyalását, valamint a Microsoft Office termékek magyarországi értékesítését (ideértve a viszonteladóknak az ahhoz kapcsolódó kedvezmények nyújtását is) az írországi Microsoft Ireland Operations Limited végzi.” http://www.gvhhu/gvh/alpha?do=2&pg=133&st=2&m5 doc=5514&m5 lang=hu 6 http://index.hu/gazdasag/magyar/msvskok11/ 4 2009. június 15 224 Arra, hogy az egyes dobozos szoftverektől eltérő mennyiségekre – volumen licencek keretében – az esetek nagy részében külföldi szerződő partner jogosít, a felhasználónak nincsen ráhatása. A gyártónak (vagyoni jogi jogosultnak) pedig nyilván nem áll érdekében, hogy a szerződésláncban nem szükségszerűen résztvevő személyeket felhasználási engedély nyújtására jogosítson. 11.12 A szabad szoftver költségmodellje A szabad szoftverek esetén a harmadik fél jogosítására licencdíj nélkül kerül sor. A modellben a könnyebb számítás kedvéért

1000 egységet fogunk használni. Az 1000 egységet nettó, szolgáltatásért nyújtott ellenértéknek vesszük (az Áfa-t az állam végső soron visszakapja). Azért szolgáltatásért nyújtott ellenértéknek, mert a szabad szoftver felhasználási joga nem kerül pénzbe. Az ilyen típusú informatikai szolgáltatásoknak az a jellemzőjük, hogy magas az élőmunka hányaduk, ezért magas az élőmunka mértéke, költsége (60%) modellünkben. Ugyanakkor ebben az egyszerű modellben azt feltételezzük a bérkalkuláció szempontjából, hogy a munkát egy személy végezte (aki alkalmazott). A kezelhetőség és áttekinthetőség kedvéért feltételezzük, hogy a cég tulajdonosai magyar magánszemélyek. Az Áfa-t az áttekinthetőség kedvéért úgy tekintjük, hogy az állam végső soron visszakapja (tudjuk, hogy nem teljesen, de most nem vizsgáljuk az Áfa hozzáadott érték miatti „kopását”). Az osztaléknál eltekintünk a 14% EHO hatásától, mivel az

maximalizálva van, és egy jól működő cég tulajdonosai gyakran részben vagy teljesen kikerülnek alóla. Azt is feltételezzük, hogy a tulajdonosok teljesen kiveszik az osztalékot. Az így felállított modellünk nem teljesen pontos, viszont az arányokat – álláspontunk szerint – eléggé jól tükrözi. A 111 táblázatban láthatóak a modellünk adatai. 11.1 táblázat: A modellünk adatai Sorszám 1 2 3 4 Megnevezés Százalékos érték Egység Teljes összeg 100,00% 1000 Teljes bérköltség 60,00% 600 Egyéb költség 10,00% 100 Az állam visszakap bérjáru36,40% 364 lékai miatt 2009. június 15 225 11.1 táblázat: (folytatás) Sorszám 5 6 7 8 9 Megnevezés Százalékos érték Egység Az állam visszakap nyere20,00% 60 ségből (300 egységből 16% adó, 4% különadó A dolgozónak kifizetett net16,67% 40 tóból (236 egységből) az állam az Áfa miatt (Áfa 20%, azaz vissza 16,67% APEH) visszakap, amikor a dolgozó a pénzét költi. (Az

állam nem kapja vissza közvetlenül és azonnal az Áfa-t.) Az állam a nyereségből 25,00% 60 (240) visszakap, mikor a tulajdonosok (magyar magánszemélyeket feltételezve tulajdonosnak) osztalékként felveszik (az osztalékadó: 25% meg az EHO 14% (Az EHO értéke maximalizálva van, elhanyagoljuk.)) A tulajdonosok osztaléká16,67% 30 nak (180) költésekor az Áfat (Áfa 20%, azaz vissza 16,67% APEH) az állam visszakapja. (Az állam nem kapja vissza közvetlenül és azonnal az Áfa-t.) Az állam visszakap összesen 55,40% 554 A modellhez tartozó bérkalkuláció a 11.2 táblázatban látható 11.2 táblázat: A modellhez tartozó bérkalkuláció Bruttó havi munkabér Éves bruttó jövedelem Gyermekek száma Munkaadói járulék (3%) Munkaadói TB járulék (29%) 2009. június 15 448 000 Ft 5 376 000 Ft 0 13 440 Ft 129 920 Ft 226 11.2 táblázat: (folytatás) Egészségügyi hozzájárulás Szakképzési alap hozzájárulás (1,5%) Munkavállalói járulék (1,5%)

Munkavállalói egészségügyi járulék (6%) Állami nyugdíjjárulék (1,5%) Magánnyugdíjpénztári befizetés (8%) GYES Családi adókedvezmény Számított SZJA Családi adókedvezménnyel csökkentett SZJA Különadó Összes adó Adójóváírás Nyugdíjjárulék utáni kedvezmény Összes kedvezmény Havi összes levonás a bruttó bérből Havi összes munkaadói járulék Összesen havonta az államnak fizetendő Munkaadó összes havi költsége Nettó havi munkabér Családi pótlék Havi összes nettó jövedelem 1 6 6 26 6 35 135 135 135 211 152 363 600 236 236 950 720 720 880 720 840 0 0 780 780 0 780 0 0 0 940 030 970 030 060 0 030 Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Ft Forrás7 (2009. áprilisi állapot szerint) Az állam számára pénz megtakarításával jár A modell számaiból kitűnik, hogy az állam az elköltött 1000 egységből – mivel a helyi gazdaságba tette – visszakap 554 egységet, tehát több, mint a felét. A

modell alapján látható, hogy a külföldről történő licencvásárlással szemben a szabad szoftvereken alapuló, elegendően jó megoldás – azonos költség esetén, modellünk szerint – feleannyiba kerül az államnak. Ez igazolja azt az állítást, hogy ugyanannyi pénz elköltése esetén – amennyiben a szabad szoftveres megoldáson alapuló szolgáltatásra költi – az állam valójában pénzt takarít meg. 7 http://www.hrportalhu/indexphtml?page=berkalkulator&edt brutto= =448000&edt gyerekek=0&edt egyedulnevel=0&btn submit=+Kisz%E1mol+ +%3E%3E+ 2009. június 15 227 Az is megtakarítási forrás, hogy szabad szoftver esetén, ha valami egyszer megoldásra kerül X költséggel egy helyen, az a probléma N helyen további költség nélkül (vagy minimális költséggel) megoldható, ellentétben a kereskedelmi licencű szoftverekkel, melyeknél a licenc költsége a felhasználók számának növekedésével csak lassan csökken. Élénkíti

a gazdaságot A modell szerint a szabad szoftveren alapuló szolgáltatásra költött pénz nem megy ki az országból, hanem a bérek és a kivett nyereség elköltésekor fordul még egyet gazdaságunkban. Ennek élénkítő hatása egyértelmű, mivel vásárlóerő jelenik meg a piacon Munkahelyeket teremt A szabad szoftveren alapuló szolgáltatások (mint a szoftverek fejlesztése, bevezetése, oktatása, támogatása) élőmunka igényesek. Az ilyen szolgáltatásokra megjelenő igény munkahelyeket hív életre Megkönnyíti egy szabad, nyílt forráson alapuló szoftvervállalkozás elindítását Mivel az alapszoftverek (operációs rendszer, irodai alkalmazások, szerver oldali alkalmazások), fejlesztői eszközök, fordítók és rengeteg modul, komponens elérhető az interneten, így ezek költség nélkül, vagy kis költséggel megszerezhetőek. Ez pedig komoly költségcsökkentési lehetőség egy induló vállalkozás számára, hiszen sok eszközt kipróbálhat,

mások tudására építhet, szinte belépési költség nélkül. 2009. június 15 228 2009. június 15 12. fejezet Céges, üzleti világbeli tapasztalatok a szabad és nyílt forráskódú szoftverekkel kapcsolatban Négy – bizonyos szempontból – különböző területen kértünk lehetőségeket arra, hogy a cég vezetőivel és/vagy dolgozóival, informatikusaival irányított beszélgetést folytassunk a szabad és nyílt forrású szoftverek helyzetéről. Mind a négy cég hozzájárult, hogy a beszélgetések jóváhagyott kivonatát, illetve a hivatkozott anyagot anyagunkban közöljük. 12.1 BalaBit IT Biztonságtechnikai Kft A BalaBit Kft. működése és üzletvitele kapcsán alapvetően nyílt forrású és szabad szoftvereket használ, valamint több szabad szoftver fejlesztését irányítja, illetve ezekben működik közre. A jelen tanulmányban közzétett anyag Scheidler Balázs ügyvezető nyilatkozatán, valamint az általuk közzétett

„Kommunizmus a szoftver fejlesztésben?” című íráson1 alapul, melyben a Free és Open Source szoftverek használatának előnyeit részletezik, és amely – véleményük szerint – segíthet álláspontjukat megérteni. 1 Lásd az M. mellékletet 229 230 12.11 Nyílt forráskódú szoftverek használata a BalaBitban A cégről A BalaBit Kft. (a továbbiakban: BalaBit) magyar tulajdonú fejlesztő cég, alapítása (2000) óta fejleszt informatikai biztonsággal kapcsolatos szoftvereket. Mára már a magyar piac elismert szereplője számos európai képviselettel, minden kontinensről vásárolnak ügyfelei A társaság tavalyi árbevétele megközelítőleg 600 millió Ft volt A BalaBit számára a nyílt forráskódú szoftverek használata, integrálása és publikálása a kezdetek óta természetes, magától értetődő stratégia volt, lévén az alapító tulajdonosok jelentős közösségi munkát tudhatnak a hátuk mögött. A szabad és nyílt forrású

programok használatát több különböző terület vezérli a BalaBiton belül. Az egyes területek igényeit, és az általuk használt nyílt forrású megoldást a következő fejezetekben ismertetjük. Iroda Mint minden cég, a BalaBit is használ irodai számítógépeket, melyeken a kereskedők ajánlatokat írnak és adnak ki, a marketing weblapot fejleszt, illetve nyomdai anyagokat készít elő, a teljes cég internetezik, levelezik, kommunikál. A fenti a feladatokat különböző nyílt forrású alkalmazásokkal oldjuk meg: – Munkakörnyezet: GNOME. – Szövegszerkesztés: OpenOffice.org – Böngészés: Mozilla Firefox. – Levelezés: Evolution. – Instant Messaging: Pidgin. – Grafikai munkák: GIMP. Jelen körülmények között azonban néhány feladat csak Windows alapú munkaállomásokkal oldható meg (tipikusan ilyen a nyomdai munkák színre bontása), azonban a cég vezetése méltán büszke arra, hogy az irodai rész többsége Linux alapú

munkaállomásokon dolgozik. Informatikai infrastruktúra A cég informatikai infrastruktúrája kizárólag Linux alapú szervereket használ, a Green Computing jegyében virtuális gépként. – Disztribúció: Ubuntu (korábban Debian). 2009. június 15 231 – Címtár: OpenLDAP. – Levelezőszerver: Postfix és Cyrus. – Fájlszerver: Samba és NFS. – Webszerver: Apache. – IM szerver: Jabber. – Csoportmunka: TUTOS. – Virtualizáció: KVM. A társaság igényeit a fenti infrastruktúra kielégíti. A cég növekedése miatt a csoportmunka-terület az egyetlen, ahol felmerül kereskedelmi licencű szoftver használata, amennyiben ezen alkalmazásra nem találnak megfelelő nyílt forrású vagy szabad megoldást. Termékintegráció A Társaság a termékeit – természetükből adódóan – szükségszerűen operációs rendszerrel együtt terjeszti. Szabad forráskódú háttér nélkül, egy teljes operációs rendszer fejlesztésére egy magyar kisvállalat

ésszerűen nem vállalkozhat, a Microsoft Windows alapú megoldásnak pedig a következő hátrányai vannak: – Kisebb flexibilitás: egy GNU Linux alapú disztribúció tetszőlegesen testre szabható, a komponensek szabadon választhatók, a rendszer egy telefontól egy szuperszámítógépig skálázható. – Forráskód hiánya: egyrészt a rendszer megérthetőségének, transzparenciájának rovására megy, másrészt megakadályozza az esetleges hibák javítását, így kiszolgáltatottságot teremt az integrált szoftver fejlesztőjétől. – Példányonként fizetendő jogdíj: a Linux integrálását semmi nem akadályozza meg. Pénzügyi tranzakció hiányában nincs szükség bonyolult riportokra, mely a gyártó felé történő elszámolást teszi lehetővé, emellett csökken a továbbértékesített komponensek értéke, így a profit növekszik. Természetesen operációs rendszer mellett számos egyéb, külső komponenst (könyvtárat) használunk fel

termékeinkben, melyek önálló fejlesztése jelentős beruházást igényelt volna. A legfontosabb ilyen komponensek: 2009. június 15 232 – OpenSSL: teljes körű titkosítás a különböző titkosítási algoritmusoktól az SSL támogatásig. – PostgreSql: SQL alapú adatbázis szerver. – Python: programozási nyelv, mely segítségével termékeink testreszabhatók. – Gtk+: grafikus eszközcsomag, mely segítségével GUI alapú programjaink Linux és Windows környezetben egyaránt használhatók. – libxml és libxslt: minden, ami az XML formátummal kapcsolatos műveletekhez szükséges. A BalaBit fejlesztései során – az esetek döntő többségében – a szabványos megoldások használatát preferálja, melyekhez szinte mindig kötődik jó minőségű, nyílt forrású megvalósítás, ennek köszönhetően a fejlesztési kapacitásokat nem kell feleslegesen lekötniük. Fejlesztőeszközök A BalaBit fejlesztéseinek szinte minden UNIX platformon

működnie kell (Linux, BSD és egyéb kereskedelmi UNIX-ok), emellett néhány rendszerünknél a Windows operációs rendszer támogatása is szükségszerű (jelenleg ezek jelentik a kisebbséget). A fejlesztések alapvetően Linux alapú fejlesztői környezetben történnek, a következő eszközök használatával: – Gnu Compiler Collection (gcc): C, C++ és számos egyéb nyelv fordítóprogramja. – Vim és Emacs: szövegszerkesztés, programozási környezet. – Autotools és WAF: programjaink fordításának vezérlése. – git: verziókezelő. – Microsoft Visual C++: Windows alapú alkalmazások fordítása. A fenti stratégia előnyei a nyílt forrású megoldások, komponensek használata. Valamint a nyílt forrású termékek publikálása számos megélt előnyt, sikert jelentett a BalaBit számára. 2009. június 15 233 Marketing A BalaBit neve világszinten elismert. Egy magyar kisvállalat számára az ilyen mértékű globális ismertség pénzügyi

okokból kifolyólag általában elérhetetlen. Ugyanez az ismertség teszi lehetővé, hogy a BalaBitnak ma már a Föld minden kontinenséről van ügyfele – saját iroda, viszonteladó, illetve bármilyen jelenlét nélkül. Mennyi lehetősége van egy magyar informatikai fejlesztő cégnek kereskedelmi szoftverét eladni mondjuk Thaiföldön vagy Új-Zélandon? Ezek a területek nem tekinthetők „divatpiacnak”, mint az USA vagy Kína, ezért bármiféle beruházás a kereskedelmi csatornák kiépítésére ritka. Egy ismert név, valamint egy jó webes jelenlét azonban mindezt elérhetővé teszi. Minőség Termékeink sokkal nagyobb bázis számára elérhetők mint kereskedelmi társaik, illetve minden felhasználónknak lehetősége nyílik fejlesztéseink legbelsőbb működését is megismerni, megérteni, ez jótékonyan hat termékeink minőségére. Ennek több oka is van: – több felhasználó, több környezet, javítja a problémák megtalálásának esélyét;

– nyílt forrású termékek esetén sokkal nagyobb a felhasználók aktivitása, a visszajelzés hajlandósága; – mivel a forráskód publikus, a fejlesztők „büszkeségből” igyekeznek a lehető legjobb megoldást választani, hiszen a forráskód mellett ők személyesen is megjelennek. Biztonság Mivel a biztonság is „csak” egy minőségi jellemző, így általános javulása jótékonyan hat a termékek biztonságára is. A biztonságot a fejlesztés és a forráskód transzparenciája is javítja, hiszen bármely felhasználó megbizonyosodhat arról, hogy a programban nincsenek szándékos hátsó ajtók vagy véletlen biztonsági hibák. Hasonló okokból követelik meg, hogy a tőzsdei cégek könyvei publikusak legyenek: a vállalat pénzügyeinek publicitása megakadályozza azt, hogy a vállalat könyvelésébe vállalhatatlan, bizonytalan tételek kerülhessenek, emiatt a vállalat pénzügyi vezetése is számonkérhető. ROI Az Free és Open Source

szoftverek/komponensek használata végső soron csökkenti a cég számára szükséges beruházásokat (fejlesztés, marketing stb.), így drámaian képes növelni a pénzügyi világban csak „Return of Investment” néven ismert mutatót, amely a cég profitábilitása szempontjából fontos. Végső soron a közösségben való részvétel, a pénzért fejlesztett szoftverek ingyenesként való publikálása így megéri üzleti szempontból is 2009. június 15 234 12.2 Drescher Magyarország Kft A Drescher Magyarország Kft. informatikai stratégiájának bemutatására az informatikai igazgatójával készült interjú alapján kerül sor. A Drescher Magyarország Kft. (a továbbiakban: Drescher Kft) teljesen magyar tulajdonú, saját területén jelenleg piacvezető (2 milliárd körüli árbevétellel rendelkező), nem informatikai cég 12.21 Szabad és /vagy nyílt forrású szoftverek használata A Drescher Kft. informatikai rendszere több helyen is szabad

szoftverekkel működik. 12.22 Szabad és vagy nyílt forrású szoftverek fejlesztése A Drescher Kft. jelenleg nem fejleszt, és nem is tervezi szabad, illetve nyílt forráskódú szoftver fejlesztését. A cél, hogy a piacon szolgáltatásnyújtással jelenjen meg, és ennek érdekében elképzelhetőek fejlesztési beruházások. A jelenlegi fejlesztések azonban mind saját használatra történnek. 12.23 A szabad / nyílt forráskódú szoftverek helyzete Magyarországon a magánszférában, illetve a közszférában Tekintettel arra, hogy a Drescher Kft. teljes mértékben magyar vállalkozás, nemzetközi összehasonlításra nincsen módja Az azonban a cég számára kitűnt, hogy Magyarországon a FLOSS vonatkozásában a magán- és a közszféra között igen jelentős az eltérés. A szabad szoftverek a mögöttük meghúzódó elméleti háttérből adódóan a magánszférában jelentkeznek és terjednek elsősorban, ugyanakkor ezek üzleti felhasználása – főleg

szerveroldalon – egyre jelentősebb. A szabad szoftver fejlesztése, használata a versenyszférában üzleti döntés. A szabad szoftverek világa ugyanis egy quasi üzleti modell. Az, hogy egy beruházáskor ki, mit, miért tart fontosnak, mindig egyedi döntés eredménye. A döntések, a döntési alternatívák pedig nehezen hasonlíthatóak össze. 2009. június 15 235 12.24 A költségmegtakarítás és a szabad / nyílt forrású szoftverek használata Az ismert előfeltételek alapján egy üzleti modellben ezeknek a szoftvereknek a használata nem költségmegtakarítást, hanem sokkal inkább más típusú költségeket jelent. Összességében a TCO (total cost of ownership) nem térhet el jelentősen. Ugyanakkor a szoftverek támogatásával kapcsolatos tapasztalat azt mutatja, hogy sokkal hatékonyabbak a hibajavítások és lényegesen gyorsabb a hibákkal kapcsolatos reakció. Egy közösség mindig gyorsan és jobban ítéli meg, hogy egy hiba kritikus-e, és ha

igen, akkor hamar javítják. 12.25 A TCO számítás alapja Az informatika – de különösen a szabad szoftver – nagyon kompetencia alapú világ. Kompetenciát pedig csak a piacról lehet megszerezni Komoly gondot jelent, hogy FLOS szoftvereknél nincsen például gyártói oktatás. Kereskedelmi szoftvereknél a gyártó által kibocsátott terméknek ma már része a marketing, az oktatási anyag stb. Szabad szoftverek esetében – gyártó hiányában – olyan társaságok fognak oktatásokat tartani, akik az adott szoftver használatában nagyon komoly tapasztalatokat szereztek (best practice átvétele). Zárt forrású kereskedelmi termékek esetén formális és piacképes módszerekkel lehet a termékhez (a szoftverhez) embereket találni, akik megfelelő minőségű képzésben vettek részt (oktatás, marketing). Ezen „termék” árának jó esetben része az oktatás, képzés is Szabad szoftver esetében a fejlesztésnek, projektnek többnyire nem része az

oktatás vagy oktatási tananyag. Ezt vagy létrehozza a fejlesztő csapat vagy nem, vagy kinőnek a fejlesztői felhasználói táborból az oktatók vagy nem. Megfontolásra érdemes javaslat lehet az önszerveződő oktatási környezet kialakítása 12.26 Félelmek A kockázatot szabad szoftverek esetében az jelenti, hogy nem garantált a szakemberállomány, amivel működtetni lehet a rendszert. Ehhez hiányoznak a megfelelő minőségű tananyagok és a megfelelő képzés (minősítés). Ezért jelenthet megoldást az, ha vállalkozói jogviszony keretében együttműködik egy céggel, amelyik rendelkezik a rendszerüzemeltetéshez szükséges kompetenciával, és elvállalja az informatikai rész supportját. A nehézség persze az, hogy a nem megfelelő képzettségű megrendelő nem tudja eldönteni, hogy ki milyen szinten ért hozzá, az pedig, ha egy munkára 2009. június 15 236 magukat szakértőnek valló kontárok jelentkeznek, nagyon negatív reklámot jelent.

Összességében: a szabad szoftveres kompetencia mérése sokkal nehezebb (hiszen nincsenek központi minősítő vizsgák), nagyobb tudást igényel tehát annak megállapítása, hogy ténylegesen alkalmas-e egy cég vagy egy személy az üzemeltetésre. A Microsoft és más kereskedelmi szoftverek gyártói azzal, hogy vizsgarendszert építenek ki, leveszik a döntéshozó válláról a felelősséget. 12.27 A jó szakember fogalma Az elmúlt néhány évben nagy keveredés van a szabad szoftver és kereskedelmi szoftvereknél – ha magas szinten képzett a mérnök, akkor minimális befektetéssel át lehet képezni egyik területről a másikra. Ez vezet oda, hogy nagy, multi cégek (hagyományosan korábban homogén szoftverkörnyezettel rendelkező) környezetében megjelennek a linuxos implementációk, mert van olyan munkaerő, aki megfelelő minőségben üzemelteti a rendszert. Az egyik terület a tűzfal és kommunikációs vezérlés (határvédelem), a másik ilyen a

webes alkalmazás-környezetek, illetve óvatosan, lassan, de kezd ilyen lenni az adatbáziskezelők világa. 12.28 A szabad / nyílt forrású szoftverek preferálása állami szinten Rövidtávon nem lenne jó, ha egy piacot ilyen preferencia határozna meg. A saját felhasználás és az alkalmazások környékén azért nem jelentene előnyt vagy hátrányt – mert hosszú távon szintén nem lenne olcsóbb. Összességében tehát komoly változást nem jelentene. Ugyanakkor a szabad szoftver nyújtotta – a dolog működése által adott – előnyöket az államnak ki kellene tudnia használnia, például átláthatóság, auditálhatóság, gyártófüggetlenség. Emiatt az egyenlő elbírálás, az esélyegyenlőség megteremtése fontos A két modell (szabad és nyílt forrású / kereskedelmi szoftverek) költségszerkezete lényegileg eltér. Nemzetgazdaságban használt szabad szoftver esetén a szolgáltatási modell miatt az üzemeltetésre, használatra fordított

pénz országon belül marad, a külföldi gyártótól licencelt termékek esetében nagy eséllyel jórészt kivándorol. A belső piacok élénkítésére kiválóan alkalmas lehet. A szabad szoftver közép-hosszú távon gazdasági előnyt jelenthet. Bekerülési értéke nagyon hasonló más eszközökhöz Nagyságrendi eltérés ebben 2009. június 15 237 valószínűleg nem mutatható ki. Minél nagyobb egy rendszer, annál költségesebb az üzemeltetése, annál meghatározóbb a szakértői, bér-jellegű költség Érdekes probléma a közösségtől való függőség: az üzleti szférában lévő fejlesztőcégektől való függőséghez képest valószínűleg senki sem tudja mit jelent egy közösségtől függeni. Ma az állami felhasználás degenerált. Nem annak kellene döntenie, hogy milyen szoftvert szereznek be, hogy egyes döntéshozók milyen esetleges juttatásokat kapnak saját felhasználásra, hanem annak, hogy az adott funkcióknak milyen

eszközrendszer felel meg jobban, vagy legalább elegendően (esetleg költséghatékonyan, vagy kedvezőbb eloszlású költséggel). Mivel ahogy korábban említésre került: a kompetencia beszerzése a legnagyobb kockázat (hiszen ezt a legnehezebb megítélni), érhető, hogy a kormányzat nem attól fél, hogy a szoftver beszerzési költsége alacsony vagy magas, hanem attól, hogy ha egyszer rossz támogatást állít mögé, és a rendszer – vagy egy része – összeomlik, akkor politikai értelemben támadhatóvá válik. Amíg az oktatási és üzemeltetési kompetencia megszerzése nagy kockázatot jelent, addig a nem kockázati körülmények közötti rendszerek – tipikusan nagy állami rendszerek (TB, Államkincstár) – nem könnyen nyitnak felé. 12.29 Személyes és céges adatok szabad / nyílt forrású szoftverekkel történő kezelése (például PostgreSql, Mysql, Linux, FreeBSD) Jelenleg is szabad szoftveres környezetben kezeli a cég az ilyen jellegű

adatállományait. 12.210 Operációs rendszer, böngésző, irodai csomag használata Az operációs rendszerek és az irodai csomagok teljes mértékben Microsoft alapúak, bár a levelezés egyeseknél kivételt képez, mivel 200 000-nél több levél a Microsoft levelező kliensen nem kezelhető. Szabad szoftverekkel kapcsolatos tapasztalatszerzés a magánszférában, hobbi alapon történik. Annak oka, hogy a cég Microsoft alapú klienst használ a munkához, a következő: A cég a következő stratégiát alakította ki: szerver oldalon szinte homogén szabad szoftveres megoldás van (ami nem az, az azért van, mert olyan alkalmazás fut, aminek nincs módja, lehetősége szabad szoftver alatt futni, s nem lehet szabad szoftver az alapja – ez a szervereinket tekintve 10% alatti). 2009. június 15 238 Viszont kliens oldalon az üzleti világ (a cég által ismert szelet, amit az üzletfeleik reprezentálnak) mai jellemző követelményeihez illeszkedően hagyományos

Microsoft alapú kultúra van, persze segédprogramok szintjén néhány százalékban előfordulnak szabad szoftverek. Ez a Microsoft kultúra két lábon áll – a felhasználókon, akik, ha hazamennek, otthon is ezt használják, a kézügyesség, amit megszereznek innen származik. Szerintem, ha valaki szabad szoftvereken ki akarná használni a lehetőségeket és képességeket, az nagyon komoly átállást igényelne, hiszen ma a felhasználóink, alkalmazottaink (és gyerekeik is), már az iskolában is a microsoftos kultúrát, eszközöket tanulják, nyilván a változtatást az oktatási rendszer alapjainál kellene kezdeni. A másik láb amelyen a Drescherben a Microsoft kultúra áll, a kapcsolatrendszer. Amíg a partnerek ebben vannak, a cég szükségszerűen rászorul arra, hogy Microsoft alapú dokumentumokat kezeljen. 12.211 Az OpenOffice bevezetésének lehetősége Az OpenOffice esetén az első néhány évben biztosan sok lett volna az inkompatibilitás. A

Drescher számára (ide értve a céget és partnereit is) egyelőre túl nagy kockázat az – esetleges olvasási hibákból eredő – információvesztés. Az üzleti tapasztalatok azonban azt mutatják, hogy a költséghatékonyság jegyében a cégek Microsofton belül sem váltanak (ez világtendencia), mert az is sokba kerülne (az Office 2007 csomaggal a felhasználó ugyanúgy elveszíti a jól megszokott kezelési felületet, ahogy egy más irodai csomagra történő átállásnál elveszítené). 12.212 A teljesen, vagy majdnem teljesen szabad szoftver alapú informatika lehetősége egy cégben Úgy gondolom, vannak cégek, ahol az egész informatikát át lehet állítani munkaállomás szinten is teljesen (vagy szinte teljesen) szabad szoftveres alapokra. Az átállítás nem méret, hanem sokkal inkább funkciófüggő Át lehet állítani egy nagy céget is, ha a munkavállalói korlátozott, behatárolható funkciókat használnak. Ehhez kapcsolódó, most divatos

probléma a mobil eszközök köre. Létük látszólag érintőleges, de kapcsolatok, interface-ek vannak közöttük (pc – mobil eszköz). Sok eszköz csak Microsoft alapon tud együttműködni (például a telefon cím- és névjegyzéke az Outlook hasonló részével). Szabad szoftvernél (ha megvan az eszközhöz) hamarabb és töményebben készülnek el a javítások és az összehangolások, azonban az új eszköz (mo2009. június 15 239 biltelefon, PDA stb.) kibocsátója képes ezt visszafogni, hiszen csak a piacra kerülést követően kezdődhet meg az illesztés. A szabad szoftver tehát szükségszerűen késni fog a piaci konkurenshez képest, amelyet elve integrálnak a készülékbe. Van ennek ellenpéldája is. Egyes gyártók a szabad szoftveres világot is figyelembevették, hogy szülessen eszközükre ilyen megoldás is. Ha a hardvergyártók majd nem akarják kizárni a fél világot, akkor fognak erre gondolni (az Intel, HP, IBM). 12.213 A szabad és

nyílt forrású szoftverek előnyei A nyílt forráskód, a szabad szoftver a bizalommal azonosul – megvan az a potenciál, hogy bármikor auditálható, úgynevezett „Damoklész kardja” típusú szabályozás. A bizalom az ellenőrzés lehetősége és a korábbi tapasztalatok köré épül. Vannak olyan területek, ahol egy feladatra nem jött létre n db megoldás, hanem csak néhány nagyon jó megoldás, ezért a szabad szoftveres világ bizonyos részein olyan, mint egy oligopol (3–10 közötti) versenyző piac. A másik központi probléma, hogy szabad szoftvernél nincsenek könyvbe tehető termékek. A könyvekben megjelenő ezzel kapcsolatos tétel: szolgáltatás Ám jelenleg itt a kompetencia értékelése kockázatosabb. A megfelelő szolgáltatás megszerzése szerintem nehezebb 12.214 A szabad szoftverek térnyerése Elsősorban szerver és központi mag oldalon van nagyobb tere a FLOSSnak. Lehet, hogy munkaállomás szinten el fog terjedni, de közgazdasági

értelemben – úgy gondolom – a szervereken történő eluralkodás lesz meghatározó Én úgy látom, hogy nagy stratégiai rendszereket még nem mernek teljesen szabad szoftverekre alapozni. Az ilyen rendszereknél a felelősség szétterítése az elsődleges Ellenben a szigetrendszerek (nem ügyviteli rendszer értelemben, hanem például nem országos, hanem helyi) fejlesztői és üzemeltetői nagyon könnyen váltanak egy könnyen uralható, jobban menedzselhető PostgreSql, Mysql alapú terület felé. 2009. június 15 240 12.215 A zárt forrású platformon futó szabad szoftverek, illetve a platformfüggetlen alkalmazások kérdése Zárt forrású platformon, például Windows alatt, a szabad szoftver létrejötte érdekes, van rá sok példa. Arra is van példa, hogy nem szabad fejlesztői környezetben, például Delphi vagy Microsoft Visual Stúdió alatt készülnek szabad szoftverek. A zárt forrású platform nem teljes dokumentáltsága ezeket a projekteket

vissza tudja fogni. Észlelhető, hogy egyre több fizetős, zárt forrású, kereskedelmi licencű alkalmazás jelenik meg szabad szoftveres platformra, konkrétan Linuxra. A hozzáférés-oldali platformfüggetlenség üzleti követelménnyé vált: a piacról élő cég nem akar piacrészt kizárni. A hírekből azonban úgy tűnik: az állam még ezt nem tudja, vagy ha tudja nem csinálja jól. Az állami fejlesztések között sok a csak Microsoft eszközzel teljes értékűen használható szolgáltatás. A kiszolgáló oldalon (futtatási oldalt jelenti, például webszerveren, IISen) is futhat olyan alkalmazás, amely mindenhonnan (vagy legalább több operációs rendszer és böngésző alól) tökéletes. 12.3 A Daten-Kontor Kft tapasztalatai, felvetései A cég teljesen magyar tulajdonú, a cégcsoport több együttműködő részből áll. Mind a magyar piacon – beleértve az állami megrendeléseket is –, mind külföldön eredményes, elsődlegesen fejlesztői és

támogatói munkából élő cég hozzávetőleg 150 fejlesztőjével az egyik a legnagyobb magyar tulajdonú, és elsődlegesen a magyar piacra dolgozó cég. Egy rövid részlet bemutatkozójukból: A Daten-Kontor cégcsoport (DK) magyar magánszemélyek által jegyzett informatikai vállalkozás. A Cégcsoportot 3 cég alkotja: – Daten-Kontor Kft. – DK-Telecom Szoftverház Zrt. – DK-Consulting Zrt. Immár 20 éve nyújt egyedi, testre szabott szoftvermegoldásokat, saját fejlesztésű, illetve harmadik fél által fejlesztett dobozos megoldásokat és kap2009. június 15 241 csolódó szolgáltatásokat a gazdaság különböző területein tevékenykedő ügyfelei számára, a telekommunikációs szektortól az elektronikai iparon át az államigazgatásig. 1988 óta, a néhány főt foglalkoztató egyedi alkalmazások fejlesztésével foglalkozó vállalkozásból stabil szakmai és pénzügyi háttérrel rendelkező informatikai megoldásszállítóvá fejlődött.

Alaptevékenysége az egyedi megoldások, valamint dobozos termékek fejlesztése, ám szolgáltatási portfólióját harmadik fél által fejlesztett szoftverek bevezetése, a kapcsolódó rendszerkövetési, támogatási és tanácsadási szolgáltatás, valamint rendszerintegrációs tevékenység gazdagítja.2 A stratégia meghatározásában többen vettek részt, a fejlesztőtől az üzletág igazgatóig, a stratégia kialakítói azonban nem azonosak a cég végső álláspontját meghatározó, felelősen kijelentő első számú vezetőkkel. A Daten-Kontor csoport fejlesztései, tevékenysége során érintett számítógéppark mérete3 az alábbiak szerint alakul: – Szerver: ∼300–400 – Kliens: ∼2000–5000 Az egyes hardvereken futó környezet megoszlása: – Szerverek: ∼50% de inkább több a Windows alapú, viszonylag sok a HP-UX. – Kliensek: ∼99% Windows (nagyrészt XP). A cégcsoport fő irányvonalként windowsos alkalmazásokat futtat és használ,

ettől csak egyedi igény esetén térnek el. Ennek legfőbb oka az, hogy éles környezetben ezekkel a rendszerekkel kell együttműködniük a fejlesztéseknek, ezért célszerű erre a környezetre optimalizálni. A cégcsoport ezen kívül fejleszt webes (internetes és intranetes) megoldásokat. A fejlesztés jellemzően JAVA (J2EE) és net (dotnet), valamint PHP alapú, de vannak Delphi-ben, és egyéb fejlesztői eszközben végzett fejlesztéseik is. Tapasztalataik azt mutatják, hogy a két legelterjedtebb böngészővel (Internet Explorer és Firefox) kompatibilisek a webes technológiát használó rendszereik, azonban sem w3c teszteket, sem böngészőnkénti teszteket nem végeznek rendszeresen, módszeresen. A paraméterezésnél – mióta a Google kiadta Chrome nevű böngészőjét – erre is figyelnek, és időnként az azzal való működést is vizsgálják. 2 3 http://www.dkhu/daten/ Becsült értékek. 2009. június 15 242 12.31 A nyílt forrású és

szabad szoftverek A jelenlévő szakértők közül senki nem tudta pontosan, hogy mi is a nyílt forrás (Open Source), vagy azt, hogy mi a szabad szoftver (Free Software). Itt is visszaköszönt az a – felmérés során is kitűnt – jelenség, hogy ezen fogalmakat jellemzően keverik a zárt és nem szabad szoftver licencekkel (például freeware), melyek lehetővé teszik a szoftver licencdíj nélküli használatát. Egyértelmű, hogy a cégcsoport használ szabad és/vagy nyílt forrású szoftvereket, például Firefox-ot, PostgreSql-t, Jquery-t, és egyéb fejlesztői eszközöket (például editorok), könyvtárakat. Fejlesztői oldalon merült fel az a szabad szoftverek fejlesztésével kapcsolatos aggodalom, mely szerint egy-egy ilyen fejlesztés esetén a konkurencia megtudná, hogy milyen saját könyvtárakat, „motorokat” fejlesztettek és fejlesztenek, és ezáltal piaci pozíciót veszítenének. Ugyanakkor annak fényében, hogy valójában nem ismerik a

konkurencia belső fejlesztéseit ők sem, és előfordulhat, hogy nem is az általuk ismert és használt megoldás a legjobb a piacon, valamint arra még nem fordítottak erőforrásokat, hogy a nyílt forrású megoldásokat megismerjék, nem derült ki, hogy FLOSS megoldásként nincs-e már most is hasonló, esetleg jobb kivitelezés. Összességében elmondható, hogy amennyiben az információcsere kölcsönös lenne – és a konkurencia fejlesztései hasonló formában megismerhetővé válnának, az csak javítaná a versenyt, hiszen ez esetben ténylegesen a jobb fejlesztők kerülnének piaci előnybe, és ők határozhatnák meg a fejlesztési irányokat, illetve diktálhatnák az árakat. A másik álláspont szerint nagy bátorság kell szabad, illetve nyílt forrású szoftver fejlesztéséhez, s ma Magyarországon a körülmények miatt szabad, illetve nyílt forrású szoftvert fejleszteni könnyen lehet üzleti hiba. 12.32 Az állami szerepvállalás hatásai

Érdekes módon annak kérdése, hogy jelentene-e a cégcsoport vonatkozásában változást, ha szabad vagy nyílt forráskódú fejlesztéseket is elfogadna az állam, a válasz nemleges volt. Mivel a Daten-Kontor nagyon sok megrendelője jelenleg is minden jogot kizárólagosan kíván megszerezni – elsődlegesen nem azért, hogy bármit tegyen vele, hanem azért, hogy más ne kapja meg a szoftvert –, mert számukra a nekik fejlesztett szoftver versenyelőnyt jelent, a kód kiadására és a szoftverrel való szabad rendelkezés jogának átadására most is sor kerül, tehát a fejlesztői oldalon ez érezhető változást nem eredményezne. Érdekes következtetés volt azonban, hogy – a piac ismeretében – amennyiben az állam következetesen szabad szoftvert és/vagy nyílt forrású szoftvert 2009. június 15 243 kérne, fejlesztetne magának, az nem okozna jelentős áremelkedést, viszont rengeteg – eddig lefedetlen – területre születhetne megoldás. 12.33

Javaslat egy más megközelítésű állami szoftverfejlesztési megoldásra, stratégiára Egy felvetés alapján – a sok éves szoftverfejlesztési tapasztalatokból – kitűnt, hogy valószínűleg sokkal hatékonyabb lenne az állami szoftvermegrendelés, ha az állam elvégezné a rendszerszervezésnek legalább a tervezés részét, meghatározná az egyes részek műszaki tartalmát, specifikálná a kapcsolódási felületeket (adattartalom és -formátum), és olyan összetett megoldásokat, mint egy önkormányzat teljes informatikájának szoftveres része, darabokban (részegységekben) pályáztatna, s egy-egy egységre kettő-három megoldást engedne nyerni, mert ekkor vetélkednének a részmegoldások egymással, és a felhasználók összeválogathatnák a nekik legjobban megfelelő részeket. Mivel állami forrásból finanszírozott fejlesztés esetén a szoftverek forráskódja is megismerhetővé válna, nagyon könnyű lenne teljesen fejlesztőfüggetlen

megoldásokat kialakítani, ahol a fejlesztők, támogatók versenghetnének a megrendelőkért. 12.4 DEJAHU Kft A társaság 10 éves ipari tapasztalatra alapozva 2006 óta folytat web- és VPS-hosting, IT tanácsadói, és rendszerfelügyeleti tevékenységet. A DEJAHU Kft.4 a Canonical Marketplace-en jegyzett Ubuntu Support Provider, és az ODF Alliance tagja. Közösségi tevékenységének része a magyar Critical Mass mozgalom (és a bővebb kerékpáros mozgalom) webes hátterének biztosítása, valamint közösségi konferenciák támogatása. A cég jelenleg közel 600 weboldal hostingját biztosítja. A társaság használ nyílt forráskódú és szabad szoftvereket, hiszen fő profilként szabad szoftver tanácsadással, rendszerfelügyelettel, szerver- és webhostinggal foglalkozik. Ezen tevékenységekre a legkézenfekvőbb a szabad szoftverek használata Ezen felül az elmúlt több, mint 10 évben jelentős knowhow-ra tett szert a szabad szoftverekre vonatkozóan, az

azokkal kapcsolatos tanácsadási és támogatási feladatok során. Ezen felül a társaság webes tartalomkezelő szoftverekhez végez fejlesztéseket. Ezek kivétel nélkül szabad szoftverek Ezt a fejlesztési modellt tartjuk 4 http://www.dejahu 2009. június 15 244 a legjobban működőnek, ügyfeleink felé extra selling point, a sokkal flexibilisebb támogatási lehetőségek miatt. Mivel bárki megismerheti a szoftver forráskódját, az ügyfél sokkal szabadabban választhatja meg, hogy kire bízza a szoftver üzemeltetését, támogatását, így nem létezik a vendor lock-in fogalma sem. 12.41 Szerver és kliens oldali tapasztalatok A társaság saját célra (Ubuntu Support Provider-ként) szerveroldalon kizárólag szabad szoftvert használ, és bár megbízás esetén foglalkozik nem szabad UNIX-alapú rendszerekkel is, ha az ügyfél kikéri a véleményünket beszerzés előtt, mindig a szabad szoftvereket ajánljuk. Ennek oka: stabil, biztonságos, gyors,

flexibilis. Nem mellesleg ingyenes, és sokkal professzionálisabb támogatás nyújtható rá (hiszen nem egy „fekete dobozt” kell adminisztrálni) Tapasztalatlan felhasználók esetében a szabad szoftver alapú desktop rendszerek nem minden területen érik el egyes „fizetős” rendszerek minőségét/használhatóságát, de a stabilitásuk és biztonságuk miatt mindenképp megfontolandó alternatívát jelentenek. Terméktámogatással pedig (amire üzleti környezetben fizetős szoftver esetén is szükség van) bárkinek ajánlható Gyakori kifogás/akadály a felhasználók oldaláról, hogy például egy Ubuntu felhasználói felület „nem olyan”, mint egy Windows felület, ezért nagyon fontos, hogy rendelkezésre álljon olyan alapszintű oktatás ezekhez a rendszerekhez, ahol az alapvető tudnivalókat megkapja a felhasználó, illetve megteheti az első lépéseket a valóban „nem olyan” rendszerben. Az ezzel kapcsolatos tapasztalatok azt mutatják, hogy a

tényleges, a legnagyobb akadály – az addigitól eltérő, szokatlan felület – egy kis gyakorlással elhárul. 12.42 A szabad / nyílt forráskódú szoftverek helyzete Magyarországon a magán- és a közszférában A magánszférában – bár a fizetős szoftverek drágasága és az illegális szoftverhasználat kriminalizálása miatt sokan kipróbálják (és sokan „meg is ragadnak”, többnyire persze a „geek” szférán belül) – a tapasztalat azt mutatja, hogy kevésbé elterjedtek a szabad szoftverek, mint pár másik kelet-európai országban. A közszférában a felhasználás módja és mikéntje rossz, de vannak biztató jelek. A Microsoft Campus szerződés, és a közbeszerzési eljárások kiírásának módja sajnos hosszú időre kényszerpályára terelte a szabad szoftverek közszférában lehetséges bevezetését-elterjesztését, illetve a jelek szerint egyszerűen hiányzott ehhez a szándék a döntéshozók oldalán. Ez mindenképpen 2009.

június 15 245 óriási hátrányt jelent Magyarországnak olyan országokkal szemben, mint például Macedónia, Horvátország, vagy sok nyugati EU-állam, ahol kormányzati szinten döntöttek a nyílt szabványokra való átállásról, illetve a szabad szoftverek közszférában való felhasználásról. A fenti gyászos helyzet most változni látszik, és szándék mutatkozik a szabad/nyílt forrású szoftver felhasználásának lehetővé tételére a magyar közszférában is, úgyhogy bizakodva tekintünk a következő fél év eseményei elé. 12.43 Versenyképesség és költségmegtakarítás Mi mindenképpen versenyelőnyként tekintünk rá, az ügyfelek visszajelzéseiből is ez szűrődik le. Egyrészt nem kell fizetni licencekért, tehát a kezdeti befektetés kisebb. Másrészt az ügyfélnek elmagyarázhatók a szabad szoftveres fejlesztés előnyei, a támogatással kapcsolatos tág lehetőségek Költségmegtakarítással feltétlenül számolni kell, hiszen

nincs licencköltség. Magánszemélyek, kisebb cégek akár fizetős terméktámogatás nélkül is tudják használni, hiszen (a forráskód megismerhetősége miatt) nagyon kiterjedt felhasználói önsegélyező hálózat áll rendelkezésre az interneten. A hibák felfedezése és javítása is gyorsabb ebben a környezetben. 12.44 Annak következményei, ha az állam elsődlegesen a szabad / nyílt forrású szoftvereket preferálná Egy ilyen döntés mindenképpen költségmegtakarításhoz vezetne, beszerzésiés üzemeltetési-költség csökkenést okozna, illetve az állam kevésbé lenne kiszolgáltatva szoftvergyártóknak. A hazai informatikai KKV szektor is sokat nyerne a dolgon, hiszen a szabad / nyílt forráskódú szoftverek támogatását tipikusan kisebb cégek is tudják-szokták végezni. És akkor még nem is említettük a lakossági felhasználásra tett kedvező hatást, amivel csökkenhet a szoftverlopás, illetve nőhet az általános internetes

biztonság stb. Személyes és céges adatok kezelése jelenleg is szabad / nyílt forrású szoftverrel történik. Számlázási rendszerünk HTTPS felületen kommunikáló, PostgreSql backenddel üzemelő szoftver, ezen felül minden céges adat Ubuntu desktopokon és szervereken van. A cégnél használt rendszerek: – Operációs rendszer: Ubuntu Linux. – Böngésző: Firefox. – Irodai csomag: OpenOffice.org 2009. június 15 246 12.5 Összefoglalás A közigazgatási felhasználási szokások mellett célszerűnek mutatkozott a versenypiaci szereplők körében a szoftverhasználati szokások felmérése. Bár a minta nem reprezentatív, az alábbi következtetések levonására alkalmas: 1. Lehet bizonyítottan sikeres vállalkozást alapozni szabad és nyílt forrású szoftverre informatikában, és informatika-igényes területen is. 2. Egy – elsősorban a kliensei igényeit kielégítő, fejlesztésekkel foglakozó – cégnél is megjelennek a szabad és nyílt

forrású szoftverek, de jelenleg nem meghatározóak. 3. Mind az elsősorban szabad / nyílt forrású szoftverekre alapozó, a napi ügyvitelt kiszolgáló modell (lásd BalaBit), mind a szerver oldalon szabad és nyílt forrást használó, de kliens oldalon a jellemzően fizetős és zárt forráskódú, összességében tehát vegyes szoftvereket preferáló megoldás életképes a piacon. Bár feltűnő, hogy a megtakarítás csak az elsődlegesen szabad és nyílt forráskódú szoftvereket használó cégnél5 bizonyított. 4. A szabad és nyílt forráskódú szoftver mind a három alkalmazónál megbízhatónak bizonyult 5. A fejlesztők nem nagyon igazodnak ki a licencek között, az informatikusoktól távol áll az informatikához kapcsolódó jog 6. Piaci szereplők is látnak olyan előnyöket, melyet az állam – mint nagy megrendelő – ki tudna használni, ha él a szabad és nyílt forrású licencek adta lehetőséggel. 7. A szabad és nyílt forrás szerver

oldali előretörése, terjedése egyértelműnek és egyelőre meghatározónak látszik, kliens oldalon sokkal lassabb a változás. 5 Igaz, itt a legmagasabb az informatikai szakismeretek mennyisége is a dolgozóknál. 2009. június 15 13. fejezet Szabad szoftverek életciklusa A szoftverek életciklusa hagyományosan lineáris modellel írható le, ahol a támogatás megszűnése egyben a termék életciklusának végét is jelenti. A szabad szoftverek („Free/Libre and Open Source Software”, továbbiakban FLOSS) életciklusára sokkal inkább a spirálmodell jellemző, ahol a tulajdonságok folyamatos javítása, és a funkciók bővítése jellemző. A sikertelen termékek elhalnak, a sikeres termékeknél többször végigjárják a minőséghurok ciklusait. Egy FLOSS termék életciklusa vizsgálataink szerint soha nem fejeződik be, csak alvó állapotba kerül. Az alvó állapot azt jelenti, hogy egy felhasználói igény bármikor életre hívhatja. Célszerű

lenne a termékek élettartamát a hagyományos megközelítés helyett gyártó által vezérelt, illetve felhasználó által vezérelt csoportra bontani. Csak FLOSS termék esetén van működtetés időkorlátja a felhasználó hatáskörében. A statisztikai megközelítés azt mutatta, hogy a felhasználói igények kielégítettségére legjellemzőbb az új felhasználók száma. Ez tűnt a vizsgált életciklus modellek közül a legjellemzőbbnek Ebből megítélhető, hogy az adott termék az életciklusának fejlődő, vagy leszálló ágában van. A közigazgatási alkalmazás szempontjából lényeges, hogy a termék életciklusának vége a gyártó elhatározásától független, és a felhasználó kezében van. Ez a hosszútávú adattárolás és felhasználás kulcskérdése A technológiai fejlődés mellett az alkalmazott szintaktika és szemantika megőrzése az alkalmazások hosszútávú használatának alapja. Oktatási rendszereknél számottevő előnyt

jelent, hogy legálisan terjeszthetők olyan tananyagok, melyeknek használatához szoftver szükséges (szimulációs, grafikai programok). 247 248 A harmadik fél érdekeit sértő szabadalmi jogok kezelése* , a komponensek összehangoltsága, továbbá a garantált támogatás miatt az államigazgatásban a „fizetős1 ” disztribúciók alkalmazását tekinthetjük az optimális megoldásnak, kiegészítve az egyedi „ingyenes2 ” megoldásokkal, és a felhasználó egyedi igényeire fejlesztett termékekkel. A szerzők a projektirányítás, a felhasználói statisztikák, illetve az üzemeltetés oldaláról vizsgálták az életciklus meghatározásának lehetőségeit. A 13.1 táblázatban látható a technikai tulajdonságok és a felhasználói előnyök összefoglalása 13.1 táblázat: A technikai tulajdonságok és felhasználói előnyök összefoglalása Tulajdonság A kód tetszőlegesen sokszor, ingyenesen használható. Eredmény a felhasználónál –

Alacsonyabb induló beruházási költség. – A szoftver teljes funkcionalitással tesztelhető vásárlás nélkül. – Nem kell foglalkozni bonyolult licenc és upgrade konstrukciókkal, csökkent adminisztráció. – Hálózati alkalmazásoknál az esetlegesen beépített kulcs nem akadályozza a virtuális hálózatok kialakítását. * A szoftverszabadalmak az Európai Unióban nem legálisak, tehát az Európai Unió tagjai számára az ellenük történő védelem teljes mértékben érdektelen. – A szerkesztő 1 Nem a licencért kell fizetni, hanem magáért a támogatásáért. Ezzel kapcsolatban lásd a 221. oldalon A szabad szoftverek gazdasági hatásai című fejezetet 2 Ez nem azt jelenti, hogy zárt forrású, de ingyen megkapható, hanem azt, hogy – adott esetben – a közigazgatási felhasználó számára már ingyenes (például a fejlesztés költségét a központ, vagy éppen egy másik szervezet már kifizette). 2009. június 15 249 13.1

táblázat: (folytatás) Tulajdonság Eredmény a felhasználónál Hozzáférhető, jogszerűen módosítható forráskód. – A szoftver életciklusának vége a felhasználótól függ. Nem kell kötelezően váltanunk egy tőlünk független, ellenérdekelt szervezet döntése miatt. – Hosszú távon garantálható a dokumentumok olvashatósága. – Speciális alkalmazások, eszközök könnyen illeszthetők a rendszerbe. (Egyáltalán illeszthetők!) – A fejlesztésekkel bárki megbízható, piaci verseny alakulhat ki. 2009. június 15 250 13.1 táblázat: (folytatás) Tulajdonság Nagy informatikai cégek támogatta disztribúciók. Eredmény a felhasználónál – Garantált problémamegoldás és összehangolt komponensek. – Jó minőségű dokumentáció. – Felelősségvállalás azért, hogy az alkalmazott szoftverek és szabadalmak harmadik fél jogait nem sértik. – A fejlesztést és karbantartást a disztribúciótól független szervezetek is

végezhetik. – Szerződésekkel lefedhetők az üzemeltetésben megkövetelt szolgáltatások. Szakismeret szükséges az üzembehelyezéshez. – Minden termék hatékony üzemeltetéséhez szakismeret szükséges. Az ismertség annak kérdése, hogy az informatikaoktatás mit favorizál. A nem teljesen kommersz alkalmazásoknál ez a különbség nem jelenik meg, mert a dobozos termék üzembeállítása is speciális ismereteket igényel (például Oracle szerver). 2009. június 15 251 13.1 Projektirányítás a FLOS szoftverek létrehozásánál3 A szoftver életciklusának meghatározására sokféle kísérletet tettek. A hagyományosnak tekinthető meghatározás szerint a szoftver életciklusának akkor van vége, ha a fejlesztő megszünteti a szoftver további követését, nem portolja az új platformokra. A szoftver fejlesztését és felhasználását alapvetően projektszemlélettel közelíthetjük meg, hiszen a szoftverfejlesztés célszerűen egy projekt

keretében valósítható meg a gyártó (terméket létrehozó) oldaláról. A felhasználó oldaláról nézve a kérdést azt találjuk, hogy a felhasználónak egy informatikai szolgáltatásra van szüksége. A szoftverfejlesztéssel kapcsolatos projekt célja egy gazdasági, műszaki, vezetési probléma megoldása informatikai támogatással. Ebben a szemléletben azt kell vizsgálnunk, hogy egy termék ki tudja-e elégíteni a felhasználó szolgáltatással kapcsolatos igényeit vagy sem. Ha az „elfogadott legjobb gyakorlatot” tekintjük mérvadónak, akkor leszűkíthető a vizsgálat arra a kérdésre, hogy a felhasználó igényei kielégíthetőek-e az adott termékkel. Formálisan: teljesíthetők-e az ITIL (IT Infrastructure Library) elvárásai. Amennyiben igazolható, hogy a „szabad” (GNU licensz feltételeivel publikált) szoftverekkel az ITIL elvárásai teljesíthetők, akkor a FLOSS alkalmazása csak gazdasági és biztonsági megfontolások kérdése, a

működtetés és támogatás megoldottnak tekinthető. Az ITIL előnye, hogy lefedi a fejlesztést követő időszakot is. Az ITIL főbb elemei: – Szolgáltatásbiztosítás: • szolgáltatási menedzsment, • rendelkezésre állás menedzsment, • informatikaszolgáltatás-folytonosság menedzsment, • kapacitásmenedzsment, • informatikaszolgáltatás pénzügyi irányítása. – Szolgáltatástámogatás: 3 A felhasznált irodalom : A Guide to Project Management Body of Knowledge: PMBOOK guide Project Management Institute, Inc. 2004 Conference reports/FLOSS, South Africa 2005/Workshop FLOSS Deployment in Education – FLOSS and i-communities in South Africa and India, Clive Smith, HP 2009. június 15 252 • ügyfélszolgálat, • incidensmenedzsment, • problémamenedzsment, • változáskezelés, • konfigurációkezelés, • kiadáskezelés. Vizsgáljuk meg egy szoftverprojekt életciklusát. A projektirányítás általános modellje

látható a 131 ábrán 13.1 ábra A projektirányítás általános modellje A kisméretű, egyszemélyes projekteket leszámítva a projekt előkészítése, indítása nem különbözik a FLOSS és a kereskedelmi termékek vonatkozásában. A szabad szoftverek világában is létezhet az ügyfél – szállító kapcsolat. A felhasználónak lehetnek speciális igényei, amit a szoftverfejlesztést koordináló személy vagy szervezet megold. Tipikusnak tekinthető az az eset, amikor a FLOSS-t előállító (koordináló) szervezet a támogatási szolgáltatást pénzért nyújtja, a kereskedelmi termékekkel azonos tartalmú szerződés alapján. A projekt előkészítésének alapja a projektindító okirat. Mit tartalmaz általában a projektindító okirat (Projekt hivatkozási alap, Terms of Reference)? A TOR tartalmazza: – a projekt célját; – az elvégzendő feladat meghatározását; 2009. június 15 253 – az ügyfélnek a projektre vonatkozó elvárásait; –

az ügyfél és a vállalkozó közötti felelősségmegosztás világos definícióját; – a szereposztást mindkét oldalon, az egyéni felelősségek, a beszámolási kötelezettségek szerkezetét (ki kinek jelent); – a projektben felhasználandó erőforrásokat; – a szerződéses jogi és pénzügyi megállapodásokat; – az időkereteket; – a projektvezetési eljárásokat; – a projektkommunikáció módját (kommunikáció-menedzsment terv); – az átadandó eredmények definícióját; – a projekt dokumentálásának módját; – a projekttervezési elemeket úgy, mint szakaszokra bontást, mérföldköveket, hálóterveket, diagramokat, lebontási szerkezeteket; – minőségbiztosítási tervet, benne például követelmény-, változás-, konfiguráció-, kockázatkezelési tervvel, tervezési útmutatóval, programozási előírásokkal, tesztelési stratégiával; – esetleges logisztikai követelményeket (például a projekttagok elhelyezésének, a

szükséges eszközök átadásának, átvételének, szállításának a módját); – az ügyfél által biztosítandó információkat és feltételeket; – bármilyen egyéb előfeltételt vagy követelményt; – használandó szoftver-és hardvereszközöket; – minden olyan tényezőt, amely a projekt végrehajtása szempontjából fontos; – a TOR mind a két fél részéről történő elfogadását. A projekt tervezésénél nincs számottevő különbség a szabad szoftverek és a kereskedelmi terméket előállító cégek között. Szembetűnő, hogy a FLOSS fejlesztésében egyre több számítástechnikai cég vesz részt. Például: 2009. június 15 254 – Irodai rendszerek – SUN – Operációs rendszer – Novell, IBM – Adatbáziskezelők – SUN – Tartalomkezelő – Plain Black Ezeknél a termékeknél teljesen nyilvánvaló a projekt szemléletű tervezés, és nincs eltérés a „kereskedelmi” és a szabad szoftverek között. Az első

eltéréseket akkor tapasztaljuk a kereskedelmi és a FLOSS termékek között, amikor a termék használatba kerül. A termékből hiányzó funkciókat a felhasználói közösség fejleszti, vagy fejlesztési igényt jelent be a projektet irányító szervezetnek A termékbe általában akkor kerül be a fejlesztés, ha azt a projektirányító jóváhagyja. Ez nem zárja ki annak lehetőségét, hogy a fejlesztett funkciót, modult stb. a szerző publikálja, terjessze Ez nagyban megkönnyíti az új elvek, megoldások elterjedését. A legkritikusabb kérdés a projekt zárásának problémája. Ez a klasszikus projektirányítás esetén akkor következik be, mikor a terméket a felhasználó használatba vette. Ez valójában mérföldkő, és tényleges zárás akkor következik, ha a terméket a továbbiakban nem követjük A szabad szoftvereknél ezt a pillanatot nehéz megállapítani, hiszen a termék a projekt korábbi létrehozójától függetlenül is fejlődhet. A

„halál” pillanata a dobozos kereskedelmi termékeknél is kezd bizonytalanná válni A Microsoft a termékeit bejelentett módon 5 évig szándékozott követni. Tehát ez az élettartam – mindenféle statisztikai, felhasználói vizsgálat nélkül – 5 év. A felhasználó számára azonban ha egy termék megfelelő (elegendően jó), akkor a váltás indokolatlan, és csak többletköltségekkel jár. A Windows XP népszerűsége töretlen, és a gyártó törekvései ellenére a piac nem fogadta el a kiváltására tervezett új szoftvereket. A Microsoft tervei szerint az újabb desktop operációs rendszerek „lebutíthatók” lesznek az XP szintjére és méretére. Az XP szoftverkövetése további 4 évre elhatározott üzleti stratégia A felhasználói közösség ki tudta kényszeríteni a termék további követését. Nyílt forráskódú rendszerek esetén nem kell „kikényszeríteni” a terméktámogatást, ha a szoftver használati értéket képvisel, mert

a felhasználói közösség megteszi ezt akkor is, ha a projekt elindítója nem foglalkozik vele, vagy megszűnt. A leglényegesebb vonása a nyílt forráskódú rendszernek, hogy megszűnik az egy gyártótól való függés. Más kérdés, hogy azoknak a cégeknek, akik nyílt forráskódú terméket hoznak létre, elemi érdeke a szolgáltatások nyújtása, hiszen ez hozza az árbevételt. Mikor fog a termék életciklusának végére érni? 2009. június 15 255 A kérdés akkor válaszolható meg, ha nem a kereskedelmi logika oldaláról közelítjük a problémát. Olyan műszaki jellemzőket kell találnunk, melyek bármilyen szoftverre jellemzőek. Például: – megjelenő új verziók száma időegység alatt, – technológiai fejlődés okozta verzióváltások megjelenése, – új funkciók beépülésének gyakorisága, – új felhasználók száma. Bármely szoftver életciklusának végét jelzi, ha például a fejlesztők, vagy a fejlesztők közössége nem

jelenik meg az új technológiákat követő verzióval, nem javítják a feltárt biztonsági hibákat, túlhaladottá vált az alap, amire a termék épült (például Dos bázisú alkalmazást ma már nehéz lenne elfogadtatni a felhasználókkal). Megjegyezzük, hogy a FLOSS felhasználója minden esetben kedvezőbb helyzetben van, mint a „dobozos” termék vásárlója, ha a rendszerét a termék élettartama után is üzemben akarja tartani. A forráskóddal rendelkező felhasználó szinte minden új platformra portolhatja, lefordíthatja a rendelkezésre álló forráskódot. Erre nem csak technikailag van lehetősége, hanem jogilag is elfogadott az eljárás. Összefoglalóan megállapíthatjuk, hogy a szoftverek projekt szemléletű vizsgálata jól használható a szoftverek fejlesztési szakaszában, de nem ad megfelelő információkat az üzemeltetési szakasz tulajdonságaira. 13.2 A FLOSS életciklusa statisztikai megközelítésben Ez a fejezet olyan módon

közelíti meg a szabad szoftver életciklusának meghatározását, hogy egy szoftver esetén feltételezi, hogy egy szoftver projekt elindul, különböző fázisokon megy keresztül, majd „megszűnik”, vagy „elhal”, vagy befejeződik. Ez utóbbi feltételezés, vagyis hogy egy szoftver „megszűnik”, igaz kereskedelmi szoftverek esetén, hiszen egy cég beszüntetheti a fejlesztését és támogatását. Például a Microsoft már évek óta nem támogatja a Windows 3.1 verzióját, és így – bár lehetnek irodák, cégek ahol még mindig kifejezetten ezt a verziót használják, de – a szoftver projekt tulajdonképpen „halottnak”, befejezettnek tekinthető. 2009. június 15 256 Egyedi lehetőséget nyújt a Netscape Navigator (böngésző) életciklusának megfigyelése4 , mivel egy olyan szoftverről van szó, amely esetén a szoftver életét nem a fejlesztők határozták meg teljesen, hanem a szoftver felhasználása. A 13.2 ábra azt mutatja, hogy az

évek során milyen volt a Netscape Navigator százalékos felhasználása a többi böngészőhöz képest Ez azért érdekes információ, mivel a későbbiekben látható lesz, hogy egy szoftver felhasználása nagyon nehezen mérhető, inkább a fejlesztői adatok érhetők el könnyebben. 13.2 ábra A Netscape Navigator százalékos felhasználása a többi böngészőhöz képest az évek során A másik oldalról nézve egy FLOSS soha nincs befejezve, mivel bár lehet, hogy az adott fejlesztő gárda befejezte a fejlesztést, de napokkal, hónapokkal vagy évekkel később bárki előveheti és továbbfejlesztheti azt. A fentieket figyelembevéve egy szabad szoftverek életciklusának megállapítására három, egyszerű modell került megvizsgálásra. 13.21 Első modell Az első modell felállítása során az volt a feltételezés, hogy a szoftververziók kibocsátásai (release-ei) között eltelt idő mérőszámként szolgálhat arra, hogy egy projekt mennyire aktív,

mennyire érett, illetve fejlesztés alatt áll-e még. Például ha egy szoftver projekt nem „élő”, akkor nem adnak ki új verziót belőle A 133, a 134 és a 135 ábra a szoftver kibocsátások között eltelt időt mutatja a GNU awk, a GNU gcc és az XEmacs projektek esetén. Az ábrákon a függőleges tengely a verziók között eltelt napok számát mutatja, a vízszintes tengelyen az egész számok csak a verziót jelölik (de a verzió számához nincs köze a tengelyen megjelenő számnak). A 134 ábrán a negatív 4 http://en.wikipediaorg/wiki/Netscape Navigator 2009. június 15 257 érték annak köszönhető, hogy a GCC és az EGCS projekt össze lett vonva, és a kibocsátási dátumok között jelentős eltérés volt. Az ábrák azt mutatják, hogy sajnos ez a modell nem használható, mivel a kibocsátások között gyakran több, mint egy év telik el (két évnél hosszabb idő is eltelhet). A modellel az is a probléma, (mint ahogy az XEmacs esetén a

13.5 ábrán látható), hogy bár a kibocsátások közötti idő az utóbbi időben egyre nagyobb, de a projekt még lehet élő, aktív (Hiszen lehet, hogy éppen egy nagyobb léptékű fejlesztés zajlik, például GTK toolkit használata a szerkesztőben.) 13.3 ábra A kibocsátott verziók között eltelt idő a GNU awk szoftver esetén 2009. június 15 258 13.4 ábra A kibocsátott verziók között eltelt idő a GNU C fordító esetén 13.5 ábra A kibocsátott verziók között eltelt idő az Xemacs szoftver esetén 2009. június 15 259 13.22 Második modell A második modell a Gartner csoport5 által kidolgozott Hype-görbét használja, lásd 13.6 ábra A Hype-görbe azt próbálja bemutatni, hogy a technológia milyen fejlődési fázisban van, mennyire felkapott A Gartner csoport szerint a fázisok a következők lehetnek: – Technológia elindítása. – Legnagyobb elvárások. – Illúzióvesztés. – Felvilágosodás, megértés. – Termelékenységi

plató. 13.6 ábra Hype-görbe a Gartner csoport szerint Sajnos a Gartner csoport nem tárgyalja, hogy hogyan állítják elő a Hypegörbét, de a népszerűség (vagy „hype”) egyik mérőszáma lehet, hogy mennyire használják. Ebben az esetben felhasználói adatokra lenne szükség, olyan 5 http://www.gartnercom/DisplayDocument?doc cd=130115 2009. június 15 260 adatra, mint a Netscape Navigator esetén.6 Sajnos ilyen adatot szinte lehetetlen beszerezni, de élhetünk azzal a feltételezéssel, hogy egy szoftver letöltése körülbelül megfelel egy felhasználásnak. Szerencsére a sourceforgenet web oldalról beszerezhetők letöltési adatok különböző szabad szoftverekre. A 13.7, a 138 és a 139 ábrák olyan szoftverek esetén mutatják a letöltési adatokat, melyek már régóta fejlesztés alatt vannak, vagy a hozzájuk kapcsolódó technológia több éves. Ha egy görbét illesztünk a letöltésekre, akkor a kapott görbék hasonlóságot mutatnak a

Gartner csoport által kidolgozott Hype-görbével. Lényegében egy felfutás (legnagyobb elvárások) után egy hosszabb lecsengés (illuzióvesztés) figyelhető meg, majd nagyjából konstans (termelékenységi plató), vízszintes alakú lesz a görbe. (A szabad szoftverek esetén a lecsengés nagyon sok okra vezethető vissza: lehet tényleges illuzióvesztés, a fejlesztő felhagy a fejlesztéssel valamilyen ok miatt stb.) 13.7 ábra Letöltési adatok ACPI szoftver esetén Vannak olyan technológiák, melyek akkor kerültek fel a sourceforge.net oldalra, amikor már stabil programnak és technológiának számítottak, például: tcl nyelv (13.10 ábra), Joe editor (1311 ábra), pstoedit (1312 ábra) A 13.13 és a 1314 ábrák olyan programokat mutatnak, melyek még fejlődnek, fejlődés alatt állnak, és így a „felfutási” szakaszban vannak, vagy esetleg éppen a csökkenés előtt állnak. Sajnos a viszonylag „rövid” ideig tartó csökkenés vagy emelkedés az

ábrákból nem jósolható meg, csak hosszútávú tendenciákra lehet következtetni. Végül vannak projektek, melyek esetén hirtelen az érdeklődés, és hirtelen az illuzióvesztés is. Erre mutat két példát a 1315 és a 1316 ábra 6 http://en.wikipediaorg/wiki/Netscape Navigator 2009. június 15 261 13.8 ábra Letöltési adatok az Enlightenment window manager esetén 13.9 ábra Letöltési adatok egy ICQ program esetén 2009. június 15 262 13.10 ábra Letöltési adatok a tcl programozási nyelv esetén 13.11 ábra Letöltési adatok a JOE editor esetén 2009. június 15 263 13.12 ábra Letöltési adatok a pstoedit esetén 13.13 ábra Letöltési adatok a 7-ZIP esetén 13.14 ábra Letöltési adatok a MinGW esetén 2009. június 15 264 13.15 ábra Letöltési adatok az eGroupWare program esetén 13.16 ábra Letöltési adatok a Qcad program esetén 2009. június 15 265 13.23 Harmadik modell A harmadik modell a másodikhoz hasonló, és

azt próbálja vizsgálni, hogy egyes programokat, technológiákat mennyire használnak a felhasználók. Ebben a modellben a Debian Linux disztribúció különböző verziói kerültek megvizsgálásra A különböző disztribúciókban az lett megvizsgálva, hogy egyes csomagok/programok mennyire vannak „beágyazva” a rendszerbe, mennyire használják a felhasználók vagy „kénytelenek” használni azt. Ez a modell feltételezi, hogy egy mélyen beágyazott program elérte a termelékenységi platót. A beágyazottság mértékét úgy mérjük, hogy egy csomagra/programra hány más csomag hivatkozik. A hivatkozások alakulását a 13.17 ábra mutatja néhány alapvető technológia, programcsomag esetén Az ábrában látható a tcl programozási nyelvre történő hivatkozások alakulása. A tcl programozási nyelv érett technológiának számít, és nagyjából konstans görbét produkál Az ábrából az is látható, hogy a Java, Qt, GTK és XML esetén viszonylag

meredek emelkedés figyelhető meg, vagyis fejlődési szakaszban vannak. Ezzel szemben érdekes, hogy a 13.17 ábra azt sugallja, hogy a Gnome és KDE technológiák stabilizálódni látszanak, vagyis a hozzájuk tartozó görbék már túl vannak a csúcson és átfordulnak. Sajnos ezen modellből – az eddigiek alapján – nem lehet megjósolni, hogy a görbék csökkenni fognak, vagy vízszintes alakra állnak be A 13.18 ábra a 3 megfigyelhető görbe alakot ábrázolja 13.17 ábra A hivatkozások száma az egyes csomagokra a különböző Debian verziók esetén 2009. június 15 266 13.18 ábra Görbe típusok a hivatkozások száma alapján 2009. június 15 267 13.24 Összefoglalás Az első modell csak arra ad választ, hogy a szabad szoftverek esetén a verziók között eltelt idő nagyon nagy lehet, és így tulajdonképpen egy szabad szoftver soha nem nevezhető befejezettnek, csak legfeljebb alvó projektnek. A 2. és 3 modell érdekes megállapításokra

ad alkalmat A 2 modell alapján úgy tűnik, hogy egy viszonylag egyszerű görbével reprezentálható egy szoftver élete, de ugyanakkor a görbe hosszára, nyúltságára és paramétereire az eddigiek nem adnak választ. További vizsgálatot igényel (több projekt részletes feltérképezésével) hogy a görbe hosszát, paramétereit befolyásoló tényezők megállapításra kerüljenek. A 3. modell szintén egy egyszerű görbe modellt eredményez, de ebben az esetben hosszabb időtartamra lenne szükség, vagy több verzióra, hogy a görbe részletessége jobb legyen, és helyessége igazolható legyen. Érdemes lenne megfontolni más disztribúciók vizsgálatát is, amelyeket az évek során többször adtak ki. 13.3 Nyílt forrású fejlesztés szolgáltatás szemléletű vizsgálata Ami a nyílt forrású szoftverfejlesztést fürgévé teszi, a személyes kapcsolatok előtérbe hozása a folyamatokkal és eszközökkel szemben, a részletes dokumentáció alapján

való munka, a megrendelő aktív bevonása és a változásokra való terv szerinti reagálás.7 Ami még gyorsabbá teszi, az a gyors reakció és fejlesztési ciklus, valamint a YAGNI (You Aren’t Gonna Need It – Nem lesz rá szükség). Ez utóbbi filozófiája az, hogy kizárólag az aktuálisan szükséges funkciókat implementáljuk, a lehetséges jövőbeliekkel ne foglalkozzunk.8 Ez utóbbi hozzáállás az extrém programozás egyre többször alkalmazott egyik irányelve. A nyílt forrású életciklust egyes vélemények szerint egy tetszőlegesen sokszor tekeredő spirális formában lehet elképzelni, ahol a spirál négy szegmense 1. a kezdeti célok és feladatok kitűzése, 2. a lehetséges megoldások összehasonlítása, prototípus elkészítése, 3. a fejlesztés, 7 Alexander Dymo, Open Source Software Engineering, II Open Source World Conference, Malaga, 15–17 February 2006. 8 Ron Jeffries, „You’re NOT gonna need it !”, X-programming practices,

http://www. xprogramming.com, 1997, 1998 2009. június 15 268 4. a támogatás A késztermék támogatása mellett újabb és újabb köröket járhatunk be, ahol a kezdeti ötlet helyét átveszi a kiegészítések listája. A megrendelők kérdése a beszerzés előtt többnyire az árra és a támogatásra utal. Ez a kettő tulajdonképpen a vételi árat és a támogatás díját jelenti, amelyek részei a teljes birtoklási költségeknek (TCO). A TCO kiszámításának alapja a szoftver életciklusa lehet 13.31 ALM – Application Lifecycle Management Az ALM-et (Application Lifecycle Management – Alkalmazás Életciklus Menedzsment) sokan összekeverik az SDLC-vel (Software Development Lifecycle – Szoftverfejlesztés Életciklus), pedig a kettő nem ugyanaz, illetve az ATM magába foglalja az SDLC-t is. Az ALM a szoftverek azon életútját jelenti, ami alatt egy megrendelő pénzt költ a szoftverre Ez a kezdeti ötletektől a szoftver életciklusának végéig tart.

Ez a fajta definíció eleve feltételezi, hogy a szoftverek életciklusának van egy vége is, de ezt a véget nem feltétlenül az jelenti, ha a szoftvert leváltjuk. Az ALM-et Chappell9 szerint három területre oszthatjuk (13.19 ábra): 1. vezetés (governance), 2. fejlesztés (development), 3. üzemeltetés (operations) Az alkalmazások Chappell szerinti életciklusának fő állomásait valamilyen jelentős események határolják be. Az első ilyen esemény az ötlet kipattanása, amikor felmerül, hogy készíteni kellene egy szoftvert, amely valamilyen problémánkat megoldja. A következő nagy esemény a hadrendbe állítás, a szoftver beléptetés, amikor a terméket elkezdjük sokszorosítani. Végül, amikor a szoftvernek már nincs üzleti jelentősége, kivonjuk a szolgáltatásból A vezetés a szoftver egész életciklusán keresztül aktív, projektmenedzselési és döntési feladatokat lát el. A fejlesztés az ötleti mérföldkőtől a hadrendbe állásig aktív

A legtöbb szoftver életciklusa ezen a szakaszon ismétlődik, fejlesztések formájában. Az üzemeltetési terület a hadrendbe állítás előtt röviddel kezdődik, és a szoftver életciklusának végéig kitart A vezetés feladata alapvetően az, hogy a szoftver mindig az üzlet célját szolgálja. Az első fázisban egy üzletfejlesztési tervet készít, amelyben definiálja azokat a célokat és ehhez tartozó funkciókat, amelyeket a fejlesztés 9 David Chappell, „What is Application Lifecycle Management ?”, Chappell & Associates in San Francisco, California, 2008. 2009. június 15 269 13.19 ábra Chappell szerinti ALM területek és aktivitásuk az idősíkon folyamán figyelembe kell venni. A fejlesztés fázisában a vezetés feladata a projekt állománykezelése. Ez sokszor abból áll, hogy egy vezetőt neveznek ki a fejlesztőcsapat fölé, vagy egy fejlesztőt neveznek ki erre a posztra. A fejlesztés végeztével a késztermék a cég

portfóliójába kerül, az alkalmazásportfoliómenedzsment felügyelete alá Így biztosíthatjuk, hogy azonos funkciók nem kerülnek újbóli implementálásra. A vezetés az egyetlen réteg, amely az alkalmazás életciklus menedzsment teljes egészére rálát A fejlesztés az üzleti fejlesztési terv befejeztével kezdődik. Ebben a fázisban már tudjuk, mit szeretnénk, mik a pontos célok A fejlesztés több darabra tagolódva helyezkedik el az életciklus alatt. Az első nagy egybefüggő tag a szoftver első verziójának kifejlesztése A fejlesztés ezen szakasza a modern szoftverfejlesztési metódusok szerint iterációk sorozata lenne. Ezen iterációk nem mindig szolgálják a végtermék használhatóságának javát, de a bevett szokás egyre inkább ez. Az első verzió után a fejlesztés nem áll meg, sorra jönnek a tesztelési fázisokkal feldarabolt javítások és módosítások. Ez utóbbiakra fordított összegek sokszor az eredeti fejlesztés

költségeinek sokszorosára rúghatnak. A szoftvertermékek üzemeltetési fázisa a fejlesztési fázis utolsó szakaszában indul, még a fejlesztés befejezése előtt. A fejlesztés ebben a fázisban már figyelembe veszi az üzemeltetési igényeket. Az üzembehelyezés az első nagy feladata az üzemeltetésnek. Az üzemeltetés közben a szoftver monitorozása, valamint az újabb verziók telepítése történik, egészen a szoftver életciklusának a végéig. A fejlesztés mind a három fenti aspektusa fontos. Alapvető hiba, ha a vezetés rossz irányt szab meg, ha a jó szoftver üzemeltetése helytelen, vagy szimplán rossz a szoftver. 2009. június 15 270 13.32 Alkalmazási rendszerek teljes életciklusa10 Az alkalmazási rendszerek teljes életciklusa alapvetően az ötlet, kezdeti majd további fejlesztés és üzemeltetés hármas tevékenységi körét jelenti. A fejlesztési módszerek javulása és sokrétűsége sem jelenti azt, hogy a felhasználók

többnyire elégedettek a megoldásokkal. Ennek egyik fő oka az, hogy a fejlesztő cégek sokszor dobozos, kész termékeket árulnak, és a vállalt támogatás és továbbfejlesztés sokszor elgyengül, esetleg meg is szűnik. Ez a fajta tendencia az egyre növekedő igények mellett nem jó irányba mutat. A nyílt forráskódú szoftverek térhódításának egyik oka pont az, hogy a fejlesztői réteg egy nyitott közösség, melynek tagjai sikeresen fejlesztik és javítják az adott alkalmazást. Az alkalmazásokkal szembeni követelmények gyors változása, valamint a gyors fejleszthetőség igénye olyan új módszerek és modellek felé mutat, melyben az alkalmazás előállításával szemben a szolgáltatásszerű szempontok kerülnek előtérbe. Elsődleges kérdés a szolgáltatás minősége, és az erre vállalt garancia. Ez a tendencia megfigyelhető abban, ahogy a hagyományos programkészítést leváltják a kész komponensekből – gyakran webes

szolgáltatásokból – összeállított, testreszabott rendszerek. Ezzel párhuzamosan megjelennek az alkalmazás- és infrastruktúraüzemeltető cégek Az alkalmazásfejlesztéssel kapcsolatos problémák főleg a változtatások miatti inkompatibilitással hozhatók összefüggésbe. A nagy változások, illetve nem megfelelően dokumentált változások jelentősen nehezítik az üzemeltetést, illetve a verzióváltásokat Az egymáshoz nyílt és szabványos felületen kapcsolódó szolgáltatásokból épített architektúrák a korábbi megoldásoknál rugalmasabbak (SOA – Service Oriented Architecture). A termelékenység javulása azoktól a nyílt és elterjedt keretrendszerektől várható, melyeket a gyártók és fejlesztők elfogadnak. Az e minta alapján működő szoftverbevételek a hagyományos licencdíjak irányából a szolgáltatás előfizetés irányába mozdulnak. A nyílt forráskódú szoftverfejlesztés előretörése érezhető nyomást fejt ki a

szoftverpiacon. A hangsúly a közösség kívánt céljain és erőfeszítésein van Ez a fejlesztés és támogatás fázisaiban is érezhető. Ez a fajta hozzáállás szintén a szolgáltatás alapú kereskedelmi modelleket támogatja. A felhasználó nem egy licencért, hanem a szolgáltatás igénybevételéért fizet. A SOA rendszerek a tesztelést is felgyorsítják, hisz az egyes komponensek helyes működésének vizsgálata párhuzamosan és függetlenül is bonyolódhat. 10 Nemzeti Hírközlési és Informatikai Tanács – Információs Társadalom Technológiai Távlatai (IT3), Fejlesztés és Működtetés, www.nhit−it3hu 2009. június 15 271 13.33 IT szolgáltatásmenedzsment Az IT szolgáltatásmenedzsment eredetileg az informatikai infrastruktúra fenntartásával és fejlesztésével foglalkozott. Manapság azonban ez már az IT rendszerek teljes életciklusára kiterjed. Ez érinti a fejlesztés, bevezetés, üzemeltetés fázisokat is A jó IT

szolgáltatásmenedzsment előnye a hatékonyabb működés. Az ITIL (IT Infrastructure Library) az egyik legismertebb és legjobban elterjedt megközelítése az IT szolgáltatásmenedzsmentnek Az ITIL egy „best of practice”, a legjobban bevált módszerek gyűjteménye. 13.34 A szabad szoftver és az ITIL v3 A következő fejezetek a szabad szoftverek és az ITIL v3 kapcsolatáról szólnak. Az ITIL v3 azon részei kerülnek szóba, ahol a szoftvereknek szerepe van. ITIL v3 Általános fogalmak Az ITIL aktuális verziója a hármas, mely az előző verzió két könyve helyett öt könyvbe szedi az informatikai infrastruktúra üzemeltetésének bevált módszereit. Az ITIL v3 az IT-szolgáltatásokhoz ad támogatást úgy, hogy a kiszolgált területek hatékonyságát növeli. Az ITIL nyílt, bevált gyakorlat, „de facto” és egyre inkább „de jure” globális szabvány. Az ITIL v3 szolgáltatással szembeni követelményei: – a használhatóság, megfelelőség

(utility), – garancia (warranty) (SLA – Service Level Agreement – szolgáltatás szintű megállapodás). Az SLA-t támogató háttér-megállapodást (Operational Level Agreement, Underpinning Contract) létező, stabil szervezetekkel lehet kötni. Kis cégek is alkalmasak, de a számonkérés, felelősségrevonás, illetve kérés utáni reakció a nagyobb cégek esetében nagyobb eséllyel sikeres és gyors. A szolgáltatási garancia jelentése: – a szolgáltatás a célnak megfelelő, – a szolgáltatással kapcsolatos alkalmazásokban és infrastruktúrában nem lesznek hibák, – a szolgáltatással kapcsolatos minden problémát egy ideig ingyen javítanak. 2009. június 15 272 A használhatóság definíciója a célra való alkalmasság. A kettő együtt (használhatóság + garancia) adja ki az „érték”-et. A szolgáltatás: – Irányelvekből, célokból (szolgáltatás stratégia), – szolgáltatás képesség és kockázati profil értékelésből

(szolgáltatásbevezetés), – tanulásból, továbbfejlesztésből (állandó szolgáltatás fejlesztés) áll. A szolgáltatás az üzleti szolgáltatás alatti szolgáltatási felületen keresztül érhető el. Ez a felület az, melynek meg kell felelnie az adott célnak, funkciókat kell szolgáltatnia, gyakorlatilag ezen keresztül dől el, hogy ez, vagy a többi szint megfelelő-e, hasznos-e. Ezt a következő szinten álló garancia biztosítja, a szolgáltatásszintű megállapodás (SLA) és szolgáltatásszintű jelentés (SLR) segítségével. Természetesen a szolgáltatást eszközök, erőforrások és infrastruktúra segítségével lehet nyújtani, ahol az alkalmazásoknak kulcsszerepe van. Szoftveres szempontból ez az a szint, ahol a szolgáltatás minőségét erősen befolyásolják a felhasznált alkalmazások. Természetesen az alkalmazásokat a kellő gondossággal megtervezett IT-folyamatok alapján kell üzemeltetni, és ehhez a szállítók és szakértők

munkája kell. Sok esetben felmerül, hogy az ilyen szinten szükséges garanciákat az „ingyenes” szabad szoftverek piacán ki és milyen módon tudja megadni? Itt fontos megjegyezni, hogy a szabad szoftverek a legtöbb esetben nem ingyenes megoldást adnak, hisz a támogatást, esetleges fejlesztést nyilván nem ingyen végzik el a szakemberek. A szabad szoftverek sokkal inkább abban különböznek a dobozos megoldásoktól, hogy forráskódjuk nyílt, bármikor szabadon módosítható, illetve újra felhasználható, a megfelelő licencszerződésben leírtak szerint. Ez olyan lehetőségeket és szabadságot kínál, amit a zárt forráskódú szoftverek csak nagyon bonyolult és végtelenül optimista, a valóságban kivitelezhetetlen licencszerződéssel tudnának megközelíteni. A fentiek alapján minden lehetőségünk megvan arra, hogy a nyílt forrású alkalmazásainkhoz olyan támogató és fejlesztő csapattal szerződjünk, amely, lévén van jogi és gyakorlati

lehetősége rá, garanciákat tud vállalni a fejlesztéseire és a támogatásra. Ezekből világosan látszik, hogy a nyílt forrással nem teljesen „ingyenes” megoldást kapunk, de a zárt forrású megoldások „pénzes szoftver + támogatás” árukapcsolásából elmozdulhatunk egy „ingyenes szoftver” + „pénzes támogatás” irányba, ami a teljes belekerülés (TCO) tekintetében kedvezőbb. Az ITIL ajánlásban minden egyes szolgáltatáshoz egy személy, a szolgáltatásgazda van kötve, aki a háttér-technológiai komponensek szintjétől függetlenül felel a szolgáltatásért. Ez természetesen csak akkor kivitelezhető, ha 2009. június 15 273 a felelősséglánc valamilyen módon az alkalmazásfejlesztőkig leér. Ez azonban a szoftver nyílt- vagy zárt forrású mivoltától független, sőt. A nyílt forrású szoftverek átvilágítására, tesztelésére sokkal több lehetőség van, mint a zárt forrású szoftverek esetében. Ez a lehetőség a

rövid reakcióidők lehetőségét is magában foglalja, hiszen nem csak az adott gyártó szűk fejlesztőcsapatának van belelátása a forrásokba. Ezen túl a zárt forrású szoftverek szerződéseiben ritkán szerepel örökös, platformfüggetlen életciklus garancia a jövő tekintetében. A nyílt forráskód gyakorlatilag ennek a lehetőségét biztosítja, azaz a nyílt forrású szoftverek életciklusa nem zárul le, ezek az alkalmazások nem kerülnek a süllyesztőbe, legfeljebb alvó állapotban várják a teljes vagy részleges újrafelhasználást. Az ITIL ajánlásaiban a folyamatokhoz párosítva szerepel egy Folyamatgazda, aki azért felelős, hogy az adott folyamatot a szerződésben rögzítettek szerint hajtsák végre, valamint hogy ez a folyamat a célok elérésében segítsen. Az ő feladata ezek mellett a személyzet oktatása is Az oktatáshoz azonban a működő és folyamatosan változó alkalmazások széleskörű ismerete szükséges. Ez a zárt

forrású szoftverek esetében csak a gyártó által adott oktatásokon keresztül lehetséges Nyílt forrás esetében a gyártói oktatás sokat segít, de van lehetőség a változások megismerésére ezen kívül is (még akkor is, ha esetleg az eredeti gyártó már rég befejezte a fejlesztést, esetleg el is tűnt a piacról). ITIL v3 – Szolgáltatásüzemeltetés A szolgáltatásüzemeltetés célja az eredményesség és hatékonyság elérése a szolgáltatások nyújtásában és támogatásában. A szolgáltatásüzemeltetés feladatai közé tartozik többek között a technológia felügyelete, illetve a teljesítmény figyelemmel kísérése, az adatgyűjtés, és a mérőszámok kiértékelése. Ezek mellett egy fontos tevékenység az alkalmazásmenedzsment Ez utóbbi feladata az alkalmazások életcikluson át tartó felügyelete, a támogatáshoz szükséges műszaki tudás dokumentálása és fenntartása. Az alkalmazásmenedzsment feladata még az is, hogy új

szolgáltatások szükségessége esetén a szoftveres háttérben fejlesztés vagy vásárlás történjen. Ez utóbbi a nyílt forrású szoftverek esetében módosulhat arra, hogy ki végezze a fejlesztést: saját vagy külső csapat. Nyílt forrású, közismert szoftverek esetében a szakmai tudás és dokumentáció jó eséllyel eleve adott, és folyamatosan bővül a felhasználói közösségi oldalak által. Ez ugyan a belső dokumentációt nem váltja ki, de jelentős és azonnali, szabadon elérhető szakmai tudást ad. Az incidensmenedzsment a szolgáltatásban fellépő hibák és rendellenességek kezelésével foglalkozik. Az incidensekre való reakció fontos mérőszáma 2009. június 15 274 a megoldási idő, mely az incidens prioritásától függ. Tipikus értékek az 1, 8, 24, 48 óra, illetve ütemezett (belátható időn belüli megoldás). A gyors reakció eleve feltételezi, hogy az esetleges szoftveres javításokhoz szerződött vagy saját támogatói

bázis legyen. Ez a zárt és nyílt forrású szoftverek esetében egyaránt meg kell legyen, de a korábbiak alapján meg is oldható Az ITIL v3 szerint az incidensek egyik gyors, de áthidaló megoldása a megkerülés. Ilyenkor a technikai személyzet egy korábbi incidens alapján olyan megkerülő eljárást használ, amellyel korábban már sikerült a szolgáltatást a kívánt működési szintre visszaállítani. Ehhez a módszerhez, valamint a végleges helyreállításhoz is nagyban hozzájárul az adott technológia alapos ismerete. Itt a technológia nyíltsága sokat segíthet, mert a gyártói reakción túl lehetőség van a nem dokumentált viselkedés próbálkozásos/találgatásos módszertől eltérő módon való felderítésére is. ITIL v3 – Állandó szolgáltatásfejlesztés Az állandó szolgáltatásfejlesztés (CSI – Continual Service Improvement) célja az érték megteremtése és fenntartása az ügyfél számára. Ezt a szolgáltatások

állandóan javuló tervezésével, bevezetésével és üzemeltetésével lehet elérni A változó üzleti folyamatokhoz folyamatosan hozzá kell szabni a kiszolgáló IT-szolgáltatásokat. Ez továbbfejlesztési lehetőségek feltárását és kivitelezését jelenti. További cél a hatékonyság javítása A szolgáltatás-fejlesztés lépéseiben mérési célokat, mérőszámokat kell meghatározni, begyűjteni és feldolgozni. Ezek alapján lehet a javulást megtervezni és elérni Ebben a folyamatban kétségtelen előnyt jelent a működés pontos ismerete. Ezt a felhasznált alkalmazások szintjén a nyílt forrás nagyban elősegítheti A fejlesztés fő kérdése a szoftverek életciklusának meghatározása, mivel a zárt és nyílt forrású szoftverek közti fő különbség a továbbfejlesztés elvi lehetőségének a megléte, illetve hiánya. A zárt forrású, dobozos szoftverek gyártói a kért fejlesztéseket sokszor bizonyos kritikus tömeg felett hozzák meg,

nagy késedelmi időkkel. Ez sokszor akkor is így van, ha szerződések mást sugallnak. A nyílt forrású szoftverek más perspektívát adnak Itt megvan a jogi-, elvi lehetőség a saját vagy harmadik fél által végzett fejlesztésre Természetesen ez sem ingyenes, de van mód tender kiírására, a fejlesztő nincs monopolhelyzetben. A módosításra, fejlesztésre való jog felpörgeti a Deming-féle minőségjavítási ciklust (PDCA – Plan, Do, Check, Act – Tervezés, Végrehajtás, Ellenőrzés, Beavatkozás). 2009. június 15 275 A szolgáltatásmenedzsment technológiája A szolgáltatás mögött álló technológiai eszköz kiválasztása a következő lépésekből épül fel: – követelmények meghatározása, – kritériumok kiválasztása, – értékelés, – választás. A harmadik lépésnél – az értékelésnél – szoftvereszköz esetében a megfelelést a gyártó specifikációira hagyatkozva, esetleg tesztekkel megtámogatva dönthetjük el. A

nyílt forrás tanulmányozása már ebben a fázisban tiszta képet adhat, mert a nyilvánvalóan nem létező vagy nem jól működő funkciókat saját vizsgálatunk alapján felderíthetjük. 13.35 Számítási példa Tanszéki csoportunk az élettartam vizsgálattal foglalkozott, és nem az oktatás, támogatás kérdéseivel. Amint a tanulmány végén jeleztük, a számítás minden konkrét esetre elvégezhető, de „általában” elvégezve sok a bizonytalansági faktor. Az államigazgatás számára mi mindig disztribúcióban elérhető termékekre gondoltunk, és a példában is ilyen termék szerepel. Szándékosan nem akarunk konkretizálni disztribúciókat, mert az árösszehasonlítások egyedi szerződések esetén nem jellemzőek, és üzletpolitikai céloktól függenek Vizsgáljuk meg, hogyan alakul a teljes birtoklási költség egy adatbáziskezelő alkalmazásnál, 10 éves használattal számolva (13.2 táblázat) A példát szándékosan nem nevesítjük,

mivel a komponensek bemutatása a cél. Feltételezések: 1. A számítógép hardvere 5 év alatt elévül és cserére szorul Ára a dobozos termékkel egyenlő (HW/SW=1, tehát 1200e Ft, mint a 2 sorban szereplő tétel). 2. A dobozos adatbáziskezelő 1200eFt (1 db szoftver, általában 3 db felhasználói licenccel) 3. 50 felhasználói licencet vásárolunk 50 ∗ 40eFt = 2000eFt 4. A dobozos termék követése 5 évig 5% (Nagyon optimista terv, mert szállítótól függően a követési díj az alapár 8–70%-a is lehet.) 2009. június 15 276 5. 5 év után az upgrade az alapár 70%-a 6. Szabad szoftver támogatással 80eFt (Ez például egy SuSe szerver és alkalmazáscsomag ára, ami tartalmaz egy adatbáziskezelőt is, továbbá garanciát a komponensek együttes működésére, továbbá egy olyan garanciát, hogy a termék nem sérti harmadik fél jogait.) 7. Éves támogatási szerződés 80eFt 8. Szoftver bevezető képzés a FLOSS termékre 100eFt

(rendszeradminisztrátor képzési költsége) A felhasználók képzése az alkalmazást szállító feladata, és praktikusan a szállítási szerződés része Az alkalmazás bevezetése független attól, hogy az adatbáziskezelőt milyen forrásból szereztük be. Lehet nagyon hosszadalmas, de rövid is Az egyetemi vizsgáztatási rendszer oktatását például egy demó-videóval eredményesen megoldotta a szállító. 9. Alkalmazás 1000eFt (például raktárgazdálkodási rendszer, rendelésnyilvántartással) 10. Alkalmazás upgrade új verziójú dobozos szoftverre 500eFt (A rendszert módosítani kell, és újra kell tesztelni, ha az adatbáziskezelő megváltozott). 13.2 táblázat: A teljes birtoklási költség egy adatbáziskezelő alkalmazásnál, 10 éves használattal számolva Időtartam 1. év 2. 3. 4. 5. 6. év év év év év 7. év 8. év 9. év 10. év Teljes költség (ezer Ft) Dobozos eredmény FLOSS 5 400 2 380 1+2+3+9 1+6+8+9 5400=1200+1200+2000+1000

2380=1200+80+100+1000 5 460 2 460 5 520 2 540 5 580 2 620 5 640 2 700 8 180 3 980 5. év+5+10+1 5. év+6+1 8 240 4 080 8 300 4 160 8 360 4 240 8 420 4 320 2009. június 15 277 A számított értékek erősen kedveznek a „dobozos” termékeknek. Valós esetben nem tipikus, hogy az alkalmazást egyetlen gépen telepítjük. A FLOSS termék esetén a képzési és követési költség több rendszeren oszlik meg. Dobozos termék esetén a szerverek számának növelése nem csökkenti észrevehetően az egységre jutó költségeket. Az államigazgatásban az azonos alkalmazások futtatása több helyen a tipikus, ezért a FLOSS termékek alkalmazása a bemutatottnál sokkal kedvezőbb arányokat eredményez. Még kedvezőbben alakulnak a FLOSS költségek, ha nem tételezünk fel egyedi alkalmazást. A felhasználások nagy hányada irodai szövegszerkesztő, táblázatkezelő szoftver, ahol az alkalmazásra jutó költség töredéke a dobozos termékének. Egy szokásos irodai

szövegszerkesztő, táblázatkezelő alkalmazásnál a tapasztalatok szerint a felhasználók minden gond nélkül át tudtak térni egy másik rendszerre. A használatos Microsoft termékek két verziójának felhasználói felülete is jelentősen eltér, és nem okoz kevesebb gondot, mint bármely más termékre való átállás. Az árak konkretizálása csak meghatározott termék esetén lehetséges. Nevesített termék esetén azonban fennáll annak a veszélye, hogy a szállító jogtalannak, hibásnak ítéli a számítást, mert a konkrét esetre kedvezőbb konstrukciót ajánl meg A gyakorlatban ez azt jelenti, hogy esetenként a katalógusár 20%-án értékesítenek terméket. Ez természetesen igaz a szabad szoftvereket disztribúcióban szállító vállalkozásokra is. Egy tömeges átállás támogatására a disztribúciók speciális támogatási szerződéseket kötnek, melyeknek árai nem becsülhetők az egyedi termékeladások áraiból. A számítási modell

példájából kiindulva, nagyjából kétszer annyiba kerül a dobozos megoldás választása, ez igen szembetűnő költség-különbség. 2009. június 15 278 2009. június 15 14. fejezet Milyen okok állhatnak a szabad szoftverekről zárt szoftverekre váltás mögött ? Míg a számítástechnikában a szabad szoftverekre váltás ma már mindennapos jelenség, az ellenkező irányú mozgás ritkább. Mégis – köszönhetően a zárt szoftverek fejlesztőinek rendelkezésére álló kereskedelmi és marketingeszközöknek – ez a kis számú eset jelentős sajtóvisszhangot kaphat. Különösen akkor, ha egy szervezet saját szabad szoftverre váltását készíti elő, érdemes mások hibáiból tanulni. Az egyetlen nehézség ebben, hogy a híradások sokszor torzítják az eseményeket, vagy a résztvevő feleknek közös érdeke, hogy eltitkolják a részleteket. A felidézésre kerülő négy esettanulmány bemutatja a szabad szoftverekről zárt szoftverekre

való visszatérés főbb okait. Felhasználói nyomás. Első helyen kell említenünk a felhasználók részéről érkező nyomást. Ha a felhasználó nem érzi a zárt rendszer költségeit és üzemeltetési nehézségeit, ellenben a zárt rendszer határozott – nem feltétlenül a szervezet céljaival egyező – előnyöket nyújt számára (például játékprogramok futtatása), akkor a felhasználó törekedni fog a zárt rendszerek megtartására. Amennyiben a szervezet nincs kellőképpen motiválva a szabad szoftverek mellett (például mert a licencdíjak nem a szervezet költségvetésében jelennek meg, vagy mert a döntéshozók nem tudják felmérni a zárt szoftverekkel együtt járó gazdasági és jogi kockázatokat), akkor a visszatérés, mégoly sikeres, több éves „próbaüzem” után is megtörténhet. A felkészültség hiánya. A második leggyakoribb ok a megfelelő felkészültség hiánya Egy alapvető változtatást aprólékosan meg kell

tervezni, 279 280 előkészíteni, tesztelni. Ez egy nem ritkán nem olcsó, és sosem gyors folyamat, amit egyes szervezetek a várható költségmegtakarítások reményében igyekeznek megspórolni. A zárt szoftvereket értékesítő cégek ezzel tisztában is vannak, amint azt az EU Microsoft elleni tröszteljárásában megállapította: „(463) A Microsoft a valóságban képes felhasználóitól függetlenül működni. Ezzel a cég teljesen tisztában is van, amint az alábbi kivonat mutatja: A Windows API1 olyan mindenre kiterjedő, olyan alapos és olyan hasznos, hogy a legtöbb alkalmazásfejlesztő bolond lenne nem használni. És olyan mélyen bele van ágyazva különböző Windows[on futó] alkalmazásokba, hogy a más operációs rendszerre váltás költségei igen magasak lennének. Ez a költség az, ami felhasználóinkat hozzánk köti, függetlenül minden hibánktól, hibás meghajtóprogramoktól, magas TCO-tól, kilátástalan jövőképünktől.”

Segítséget jelent viszont, hogy a szabad szoftverek alkalmat adnak a rugalmasabb váltásra. A legfontosabb szerverszoftverek és a legtöbb felhasználói alkalmazás kiválóan együttműködik más szoftverekkel és operációs rendszerekkel, ezért az átállást kisebb, könnyebben kezelhető lépésekben is meg lehet valósítani. Lobbierő. A harmadik, igen nehezen felmérhető hatású visszaváltási ok a zárt szoftvereket fejlesztő és terjesztő cégek lobbiereje. Ennek része az is, hogy a szabad szoftverekre váltás fenyegetésével lehet jelentős árengedményt elérni, de olykor teljesen egyszerű pénzért-piacot akciók is történnek, amint a nigériai esetnél láthatjuk. Az ilyen esetek dokumentáltsága csekély A szabad szoftveres megoldás hiánya. Végül nem szabad megfeledkeznünk annak lehetőségéről sem, hogy bizonyos feladatokra nincsen megfelelő szabad szoftver Ezek közül az egyik legfájóbb a csoportmunkaszoftverek területe, ahol a Microsoft

Exchange még nem talált megfelelő kihívóra, de számtalan olyan kisebb terület van, ahol a szabad szoftverek esélyei rosszak. Különösen, ha az adott területen szintén monopolhelyzetben lévő cég található, mint például a Blackberry2 esetében a RIM, a szabad szoftvereknek nem terem babér. 1 2 API – Application Programming Interface. A Blackberry egy olyan rendszer, amely lehetővé teszi, hogy az irodából kilépve is utánunk érkezzenek a céges leveleink, azokra válaszolhassunk, és a naptárunkat is online szinkronizáljuk. 2009. június 15 281 14.1 Négy esettanulmány 14.11 Peng Hong Hardware3 A cég – létszámra – egy viszonylag kicsi acélkereskedés Malajziában. Ötven alkalmazottjukból húsz használ számítógépet 2003-ban Linuxra, nevezetesen Red Hat 9-es Linuxra cserélték irodai nyomtató- és fájlszerverüket, majd mivel számos probléma merült föl, újra váltottak, ezúttal Microsoft Small Business Serverre. A legfőbb

probléma a szakértelem hiánya volt, rendszeresen kellett külső szakembert hívni olyan apróságokhoz is, mint egy új e-mail cím létrehozása, vagy egy nyomtató beüzemelése. Megakadtak ott is, hogy az új hálókártyát és nyomtatót (driverek híján) nem kezelte a Red Hat 9. Amikor kiderült, hogy a Red Hat 9 támogatása hamar véget ér, elviselhetetlen kockázatnak értékelték, hogy biztonsági frissítések nélkül védtelenek lesznek az interneten, és bevezették a Microsoft SBS-t. Ebben4 a cikkben elemzik ezt az esettanulmányt. A történet részleteit megvizsgálva látható, hogy a Linux ismerete nélkül íródott az esettanulmány, vagy az esettanulmány szereplői nem tudtak semmit a Linuxról. Például a Red Hat részletes kompatibilitási listával rendelkezik, ebből választva hardvert garantáltan nincsenek problémák a hiányzó meghajtóprogramokkal. E-mail címet hozzáadni a rendszerhez – még ha csak parancssoros felületet használ is a

helyi rendszergazda – roppant egyszerű, és természetesen vannak grafikus alkalmazások is erre a célra. A végkövetkeztetés, hogy ha a történet igaz, akkor a cég nem volt felkészülve az átállásra – felkészülés és körültekintés nélkül beszereztek egy GNU/Linux szoftvert futtató szervert. 14.12 Strathcona Baptist Girls Grammar School5 Ez a memphisi iskola 2001-ben váltott Linuxra. A váltás melletti érvek a biztonság, megbízhatóság, egyszerűbb adminisztráció és jóval kisebb beszerzési költség voltak. A „biztonság” itt nem csak a vírusokra vonatkozik, hanem a kísérletező kedvű diákokra is. Az adminisztráció terén a központi felhasználó-azonosítás és az egyszerű frissítés volt igen hasznos. Szakmailag az átállás sikeres volt, hat évig így működött az iskola, az elengedhetetlenül 3 http://www.microsoftcom/malaysia/business/casestudies/ linkpage4206.mspx 4

http://www.linuxcom/?module=comments&func=display&cid=1118402 5 http://www.itwirecom/content/view/16721/1090/ 2009. június 15 282 szükséges Microsoft alkalmazásokat Citrix-en, vagy néhány Windows XP-vel szerelt PC-n érték el. Azok, akik otthon a Windows XP szabadságához szoktak, nehezen viselték, hogy az iskolai asztali gépek igen erősen korlátozva voltak, és amikor az új laptopokkal együtt megjelentek az újabb Microsoft rendszerek, elérték, hogy az iskola visszaálljon Windowsra, mégpedig az új Microsoft operációs rendszerre, a Windows Vistára, hogy a laptopokon és a desktopokon ugyanaz a rendszer legyen. A visszaállás egybeesett a Vista bevezetésével, tehát továbbra sem érezhetik magukat „otthon” a felhasználók. Ellenben a visszaállással összefüggésbe hozhatóan az iskola IT-költségvetése négyszeresére nőtt. 14.13 Austereo6 Az ausztrál rádióscég három évig használt Red Hat GNU/Linuxot, de nem volt minden

zökkenőmentes. Például a védett hálózatba kívülről bejelentkezéshez három különböző jelszó kellett, egy elromlott merevlemez miatti adatmentés 24 órán át tartott. A GNU/Linux rendszer a Blackberry rendszerrel7 sem tudott együttműködni Sok munka árán sikerült a korábbi rendszer adatait és funkcióit átvinni az új rendszerre. A szerverek számát is lecsökkentették, hétről kettőre Megszűnt sok kellemetlen, apró hiba is, amit sosem tudtak megjavítani a GNU/Linux rendszeren. A felhasználók használhatnak Blackberry-t, egyszerűen bejelentkezhetnek távolról, és új multimédiás szolgáltatásokon dolgozhatnak. Az esetnek része, mint oly sokszor, a szakértelem korlátozott volta, de a visszaállás fő oka az, hogy ennek a cégnek olyan szolgáltatásra volt szüksége (Blackberry), amit akkor még szabad szoftverrel nem lehetett nyújtani. 14.14 Nigériai Mandriva szerződés8 A nigériai kormányzat úgy döntött, hogy fejleszteni fogja az

informatikaoktatást. Az ehhez szükséges számítógépeket és operációs rendszerüket hoszszas válogatás után választották ki Az értékes pályázat nyertese az Intel 6 http://www.itwirecom/content/view/16721/1090/ A Blackberry egy olyan rendszer, amely lehetővé teszi, hogy az irodából kilépve is utánunk érkezzenek a céges leveleink, azokra válaszolhassunk, és a naptárunkat is online szinkronizáljuk. A mobil internet terjedése és sávszélességének növekedése fokozatosan csökkenti a Blackberry rendszer többi megoldással szembeni előnyét. 8 http://www.computerworldukcom/management/government−law/ public−sector/news/index.cfm?newsid=6124 7 2009. június 15 283 Classmate laptop lett, az operációs rendszert pedig a Mandriva disztribúciót fejlesztő cég szállítja majd. Az első 17 ezer gép beszerzése meg is kezdődött Hirtelen a TSC (a cég, amely intézi a beszerzést) bejelentette, hogy ugyan kifizetik az operációs rendszer

számukra történő testreszabását, ám a laptopokra megérkezésük után rögtön Microsoft Windows rendszer kerül. A döntés, amely rettentően pazarló, kívülállók számára igen nehezen volt érthető, értelmezhető. Nem sokkal később derült fény arra, hogy a TSC szerződést kötött a Microsofttal, mely szerint a TSC marketingszolgáltatásokat nyújt, és kap 400 000 dollárt. Ez az információ értelmezhetőbbé tette történetet A helyzetet – és a Microsoft Windows rendszerre váltást – az is bonyolítja, hogy az egyik legnagyobb felhasználó, az USPF (nemzeti technológiai fejlesztést koordináló szervezet) ragaszkodik a Mandriva Linuxhoz – valahogy valakinek még őt is meg kell győznie. 2009. június 15 284 2009. június 15 15. fejezet A szabad és nyílt forráskódú szoftverek elterjesztése az állam- és közigazgatás területén 15.1 Jogi környezet Kutatásaink során az is egyértelművé vált, hogy a szoftverekkel

kapcsolatos törvényi szabályozás bizonyos területeken nem zárja ki a nyílt forrású és szabad szoftverek használatát.1 Más területeken2 azonban önmagával a szoftverrel, mint létező, valóságos dologgal kapcsolatban is vannak az irányítási célnak nem megfelelő, nem, vagy nehezen értelmezhető szabályozások, és ennek folyományaként bizonytalanságok és hibás gyakorlati alkalmazások. 1 Rendeleti szinten már vannak problémák, például iratkezelés, ahol nem a gyártói, felhasználói felelősségvállalásra épül a szabályozás, hanem minősítést végző szervezetek növelik a költséget, és igazolnak egyfajta szoftver-jóságot, megfelelőséget. Ez a megoldás minimum megnehezíti, de inkább lehetetlenné teszi a nyílt forrású és szabad szoftverek e területen történő elterjedését. Ellenben például a számlázó szoftverek készítésére vonatkozó szabályozással, mely a gyártói (felhasználói) felelősségre épít. Itt a

jogszabályi megfelelőségről nyilatkozik a gyártó, illetve logikusan szabad vagy saját fejlesztésű szoftver esetén maga a felhasználó, ezzel vállalva a felelősséget. Ennek a szabályozásnak is van, lehet olyan értelmezése, hogy szabad szoftver, a gyártói felelősségvállalás hiánya miatt, nem használható számlázásra – persze ez esetben egy szabad, nyílt forrású szoftverekkel dolgozó cég, aki a szoftver támogatását is vállalja, kiadhatja a szükséges nyilatkozatot. 2 Adózás, számvitel. 285 286 15.2 Elsődlegesen Microsoft Windows alapú az állam- és közigazgatásunk Ma az állam- és közigazgatásunk elsődlegesen Microsoft Windows alapokon, és az ezen a platformon futó szoftverekkel működik. A fejlesztések irányát a központi akarat és a már rendelkezésre álló szoftverkörnyezet határozzák meg. 15.3 Az állami és közintézményi fejlesztések fokozzák a függőséget Az elmúlt évek informatikai fejlesztései –

különös tekintettel az Ügyfélkapura, valamint a központilag a működéshez biztosított szoftverekre – kevés kivétellel3 erősítették ezt az irányt. Ahogy az a felmérésekből is kitűnik, szerver oldalon vannak Linux alatt működő kiszolgálók, sőt, az is előfordul, hogy az informatikai vezető maga nem is tud arról, hogy az általa irányított rendszerben FLOS szoftvereket is használnak. A felmérések azt mutatják, hogy a 2009-ben folyó fejlesztésekben nem jelenik meg döntő szempontként sem a több-platformosság, sem a platformfüggetlenség. Jelen tanulmánnyal egy időben fejlesztésre kerül például az ONKA (Az önkormányzat által kivetett adókat kezelő szoftver), amelynek kiadás előtt álló verziója (WONKA) is a lehető legerősebben kötődik4 a Microsoft Windows platformhoz. Mivel a Microsoft bizonyítottan sok energiát fektet abba, hogy termékei csak más Microsoft termékekkel működjenek együtt (lásd EU trösztellenes döntés,

463. bekezdés, kivonata az X mellékletben), ezért a Microsofton alapuló közigazgatási fejlesztések könnyen válhatnak vendor lock-in helyzetté, ahol a kormányzat egy külső cégre van utalva Egy másik, bevezetés alatt álló, webes technológián alapuló központi szoft- 3 Ilyen kivétel az ABEV, melynek JAVA-s verziója futtatható és használható Linux alatt. 4 MS SQL szerverre, valamint dotnet-re épülő alkalmazás. 2009. június 15 287 ver5 oktatásán hangzott el az a mondat is, hogy csak IE7, IE86 alatt garantált a helyes működés. A központi akaratban nem, vagy nem egyértelműen látszik a szabad és nyílt forrású szoftverek elterjesztésének szándéka. Habár Novell terjesztésű7 (SuSe) Linux és mások által terjesztett például Red Hat terjesztésű Linux beszerzésére is nyílik lehetőség8 , az jelen feltételek mellett nem mozdítja előrébb sem a gazdaság, sem a FLOS szoftverek helyzetét, hiszen a központi fejlesztésekben

készülő programok többségükben nem alkalmasak linuxos munkaállomáson történő futtatásra, illetve az sem ritka, hogy szerver oldalon is Linuxtól idegen megoldásokat követelnek. A beszerzett Linuxok használhatósága az alkalmazások inkompatibilitása miatt kicsi Ennek eredményeképpen sok helyen csak újabb érvek, tapasztalatok keletkeznek arról a „próba évben”9 hogy a Linux egyelőre csak kalandnak jó, de az érdemi, akadálymentes munkához Windowst kell és lehet használni. Már a sikertelenség magyarázata is borítékolva van a rendszerben, mivel a támogatási keretösszeg csak a licencekre vonatkozik, az átképzési költségeket az adott szervezetnek kell állnia.10 Ez azért baj, mert hazánkban elterjedt az a máshol, és az Európai Unió által is megcáfolt városi legenda11 , hogy a Linuxra való átállás drága része az oktatás. 5 A Szociális és Foglalkoztatási Hivatal a foglalkoztatás elősegítéséről és munkanélküliek

ellátásáról szóló 1991. évi IV tv, illetve a 73/2009 (IV 8) Kormányrendelet alapján újabb informatikai rendszert tett használandóvá. Eleinte azt gondoltuk, hogy nem lesz gond, mert webes fejlesztésről van szó, azonban az egyik ügyintézőnk a szoftver használatáról szóló tanfolyamon a fejlesztő szájából azt a mondatot hallotta elhangzani, miszerint „a program működése kizárólag Internet Explorer 6.x és 7.x verziókkal biztosítható megfelelően” – az idézet a kutatás során folytatott levelezésből származik. 6 Internet Explorer 6 az előző, mára már a gyártó által lecserélésre javasolt, nem támogatott böngésző verzió. Az aktuális az Internet Explorer 70, mely a jelenleg támogatott Windows operációs rendszerek részeként az operációs rendszer alapértelmezett böngészője, s melynek használata egyértelműen (mind jogilag, mind technikailag) Microsoft operációs rendszert kíván a böngészőt futtató gépre. A IE8 a

most legfrissebb verzió. 7 disztribúciójú 8 Baja Ferenc bejelentése (2009. 04 02) szerint 12 milliárd jut nyílt forráskódú alkalmazásokra, és 12 milliárd a Microsoft és a Novell szoftvereire 9 Forrás: Bódi Gábor, a Miniszterelnöki Hivatal szakállamtitkára. „Az idei próbaév lesz, a kezdeményezésnek sokféle végeredménye lehet, elképzelhető, hogy nem sikerül élni a lehetőségekkel, de az is lehet, hogy nem remélt mértékben történnek meg a lehívások”. 10 Forrás : Bódi Gábor nyilatkozata. 11 Lásd a J. mellékletben a Floss Poll felmérés eredményeiről szóló LME jelentés részletet 2009. június 15 288 15.4 Intézkedési terv 1. Központi döntés (lehetőség szerint törvény) és ennek végrehajtási rendeletei, amely keretében a Magyar Állam a FLOSS fejlesztések és rendszerek mellett foglal állást Méghozzá nem disztribútor12 vagy szoftververzió kijelölésével, hanem oly módon, hogy a közpénzekből (állami és

közigazgatási keretek) fejlesztett szoftvereknek egy, az Állam által kijelölt licencet13 ír elő. A fejlesztéseknek egyrészt a licencben rögzített „szabadságokat” kell adniuk, másrészt teljesíteniük kell egy minimális interoperabilitási14 , platformfüggetlenségi követelményt15 . 2. Egyértelmű jogszabályi környezetet kell teremteni a szoftveripar és a szabad és nyílt forrású szoftvereket fejlesztők, felhasználók számára16 , ide értve a közteher-szabályok és az oktatási rendeletek reformját is. 3. Be kell vezetni a szabad és nyílt forráskódú szoftvereket az államilag finanszírozott valamennyi képzési területre, így a köz- és felsőoktatásba, valamint a felnőttképzésbe, is. Ennek az a módja, hogy központilag, szakértők bevonásával ki kell dolgozni a komplett oktatási anyagot, amelyet minden iskola, tanár számára elérhetővé kell tenni. A teljes körű oktatási anyag alatt értjük többek között a tananyagot, a

tantervet, a tanári kézikönyvet, az óravázlatokat, a feladatgyűjteményt stb., mert ezek hiánya jelenleg egyértelmű hátrány, hiszen a látszólag ingyenes17 Windowshoz már mindez rendelkezésre áll, és az adott területen (Windows és alatta futó szoftverek) az oktatók már tapasztalattal is bírnak. Egyetemi szintű jegyzetek és 12 Linuxnak sok disztribútora van, például Uhu, Black Panther, Frugalware, Debian, Novell, Red Hat, Mandriva, Ubuntu, Cent OS. A disztribúciók tevékenységének leírását lásd a D. mellékletben 13 Vannak olyan eretnek, de egyébként logikusan hangzó gondolatok, hogy a közpénzből fejlesztett szoftvereknek a köz tagjai számára elérhetőnek kell lenniük, de legalább az azonos tevékenységet végzők számára térítés nélkül elérhetőnek kellene lenniük, s közintézményeinknek nem szabad a gyártófüggőség csapdájába kerülni. 14 Az interoperabilitás nem összekapcsolhatóságot vagy szimpla együttműködési

képességet jelent, hanem ennél többet. 15 Itt nem szabad olyannak szerepelni, hogy Novell (SuSe) Linux, vagy éppen Red Hat vagy Mandriva. Hiba megkötni a disztribúciót, egy esetet kivéve, amikor van nevesített állami disztribúció. 16 Igen hasznos lenne az is, ha nem csak a BSA képezné az APEH szakembereit a szoftverjoggal kapcsolatban, mivel ők (a BSA) lényegüknél fogva elfogultak. 17 A központilag megvásárolt licencek ára a tanároknál már nem érzékelhető. Számukra gyakorlatilag a Windows, a Microsoft Office éppen olyan költségmentesen elérhető, mint a különböző Linux disztribúciók, s ráadásul a windowsos világhoz van gyakorlatuk és segédanyaguk. 2009. június 15 289 szabadon elérhető segédanyagok18 jelenleg is állnak rendelkezésre, de az oktatás alapjai teljes mértékben hiányoznak. 4. Ki kell dolgozni egy magyar, a szabad és nyílt forrású szoftverekkel kapcsolatos vizsgarendszert, mely disztribúció-független, legalább

háromszintű, és amely a fent nevezett tananyagra épül. 5. Képzéseket kell szervezni – disztribúció-független módon – az állam és közigazgatás informatikusainak, valamint az informatikát oktató tanároknak19 , melyeken a részvétel támogatott, és amelyek vizsgával, minősítéssel végződnek. 6. Az ECDL20 hazai gyakorlatát egyértelműen képzésekkel alátámasztva is alkalmassá kell tenni arra, hogy szabad és nyílt forrású szoftverekkel (például GNU/Linux, OpenOffice, PostgreSql) segítségével lehessen tanítani és vizsgázni belőle. 7. Az állam és közigazgatás szoftvereit és adatait fel kell térképezni, egyértelmű előírásokat kell kialakítani a minimálisan kötelező adattartalmakra21 Szintén ki kell alakítani és elő kell írni a kötelezően kezelendő adatcsere-formátumot22 , vagy formátumokat, amelyek nem csak a kötelező adattartalmat képesek tartalmazni, hanem a bővített adatokat is. Ez a csereformátum teszi

lehetővé a szoftverek versenyét, akár a szabad, nyílt forrású megoldásra váltást, hiszen az adattartalom egyik szoftverből a másikba a mainál jóval könnyebben, és főleg olcsóbban átvihetővé válik. 18 Egy példa: „Egy elképzelt hálózat összeállítása a Debian GNU/Linux Etch verziójának segítségével”, http://www.mithrandirhu/hu/konyvek publikaciokhtml 19 Ahhoz hasonló modell is elképzelhető, mint amilyen modellel a rendszerváltáskor az orosz nyelvet tanító tanárok átképzése folyt. 20 ECDL : Európai Számítógép-használói Jogosítvány – European Computer Driving Licence. Az ECDL az Európai Unió által támogatott, egységes európai számítógéphasználói bizonyítvány, amely nem elsősorban az informatikai, hanem a felhasználói ismereteket, az informatikai írástudás meglétét hivatott igazolni. 21 Van már példa erre. A számla adattartalma törvényileg van rögzítve, az iktatórendszereké rendeletben 22 Az, hogy

XML, önmagában – az XML szabvány volta ellenére is – kevés, mert az XML egy leíró nyelv. Tehát ha azt mondjuk XML-ben, az nem jelent többet, mint ha azt mondjuk magyarul, azaz csak a közlés formáját és szókészletét határozzuk meg nagyjából. 2009. június 15 290 Ezek a lépések az előfeltételei az oktatásban23 , z állam- és közigazgatásban történő szabad és nyílt forrású szoftverek és az ehhez tartozó tudás bevezetésének. A lépések végrehajtásának koordinálására a megfelelő jogszabályi háttér szükséges. Az első lépések megtételét követően fel kell állítani olyan támogató központot, amely a további lépések végrehajtásában segédkezik. A támogató központ felállításánál figyelemmel kell lenni arra, hogy – Ne az első két lépes megléte előtt, megfelelő törvényi háttér nélkül jöjjön létre.24 – Ne legyen elfogult, támadható. Csak szigorú ellenőrzésű állami intézmény tud

ellenállni25 a mai gyakorlat szerinti manipulációknak (példa a K. melléklet – „comes”), melyek erősödése várható Ennek az az oka, hogy a szabad és nyílt forráskód egy eltérő üzleti modell, mely bármely más modellel dolgozó cég érdekeit sérti (tehát nem csak a hagyományos zárt, hanem a kevert modellt használókét is). Jelenleg a Linux leginkább a zárt forrású Unixok piacát csökkenti, valamint a Microsoft Windows piacán jelentkezik, helyet követelve magának. Ugyanakkor például a Mysql, PostgreSql páros az adatbáziskezelő piacon üzleteket vesz el az Oracle, az MS SQL, a DB2 és egyéb zárt forrású adatbáziskezelők elől. Tehát a szabad és nyílt forrású szoftverek állam- és közigazgatásbeli terjedése sok cégből26 fog ellenállást, ellenlépést kiváltani. – Ne vállaljon fel olyan feladatokat, amelyeket disztribúciók elvégeznek (lásd: D. melléklet) – Ne jelentsen újabb gazdasági terhet az önkormányzatok,

közintézmények számára. – Ne akadályként jelenjen meg a vállalkozások piacra lépésében. 23 A közoktatásban történő bevezetés nélkül nagyon nehézzé válhat hosszabb távon is eredményesen alkalmazni a szabad és nyílt forrású szoftvereket az állam- és közigazgatás területén. 24 Mert elszigetelődik, akár az előző – a MEH berkein belül létrejött – kompetencia központ. 25 Egy PPP (public-private partnership) konstrukcióban történő megvalósítás magában rejtheti azt a kockázatot, hogy a privátszférából érkezett partner – ilyen vagy olyan okok (például felvásárlás, illetve kedvezőbb jövedelmezőséget mutató más irány) miatt – befolyásával eltéríti a projektet valamely – az állami partner számára már közép- és hosszútávon – nem kedvező irányba (lásd 282. oldal) 26 Ezek a cégek ma úgy gondolják, hogy a zárt forrású megoldásaikhoz kiváló alap a szabad és nyílt forrású szoftver (például

a Linux), de maguk maradnak a zárt forrás mellett. 2009. június 15 291 – Ne alakítson ki jelentős költséggel olyan technikai hátteret, amely már az állami oldalon rendelkezésre áll. Például e-learning rendszer, levelezőlista, wiki (ezeket együtt szokták más néven tudásbázisnak nevezni) – Ne dönthessen arról, hogy mekkora a piac és arra ki léphet be és ki nem. – Ne a terület (állam- és közigazgatás) ismerete nélkül, vagy éppen csak a központi rész (minisztériumok, budapesti intézmények és hivatalok) problémáit ismerve adjon tanácsokat. – Ne egyfajta, visszatetsző agyelszívást végezzen, tehát ne csak az különböző helyeken összegyűlt tudást szedje össze és ossza szét (terjessze), hanem maga is rendelkezzen képzett, a problémák megoldásában eredményesen dolgozó szakemberekkel. 15.5 További lépések 1. El kell dönteni, hogy saját disztribúciót27 készítünk, vagy disztribúciókat elfogadunk28 az állam-

és közigazgatásunkba, vagy járunk egy harmadik utat. Ez a harmadik út az, hogy szolgáltatásokat és arra alkalmas szoftvereket listázunk be, és ezek azok amik használhatóak Ez esetben nem szükséges meghatározni disztribúciót. 2. Be kell vezetni az ODF formátumot, mint általánosan használt dokumentumformátumot, s elő kell írni, hogy mely alkalmazásokkal szabad ezt kezelni29 , valamint használati útmutatóval ellátott iratmintákat kell készíteni. 3. Érdekelté kell tenni az állam- és közigazgatásban az érintetteket abban, hogy a tudásukat, tapasztalataikat megosszák Ehhez kevés csak a lehetőség biztosítása, egyértelmű motiváció kell. 27 A világon erre is van több példa (Németország, Kína stb.), s számunkra is jól járható út lehet egy Debianra alapozott magyar állami disztribúció (azért Debianra,mert az nagy és független). 28 Ez sem példa nélküli. Sőt, lehetnek akár ágazati eltérések is (például a rendőrség

használhat teljesen mást, mint az önkormányzatok). Igaz Németország akkor sem választotta a SuSe Linuxot (ez – mielőtt a Novell megvette – német cég volt), amikor még saját belső piacán, s jórészt belső piacából élő cég volt, mert nem akarta azt megkockáztatni, hogy valaki felvásárolja az állami alapszoftvert biztosító céget, vagy éppen azt, hogy a cég ha eltűnik (megszűnik), akkor a szoftverét használó állami hivatalok támogatás nélkül maradjanak. 29 Ennek szükségességét magyarázza az F. melléklet, amely a Microsoft ODF támogatásáról szól 2009. június 15 292 4. Az adattartalmak és a csereformátumok kidolgozása folyamán amint egy területhez egy verzió elkészül azt ki kell adni, és valamilyen időhatárral (jogszabályilag) kötelezővé kell tenni a területen levő szoftverek számára. 5. Azt a szándékot, hogy hazánk ilyen mértékben nyit a szabad és nyílt forráskódú szoftverek felé, a piac irányába

egyértelműen publikálni kell, hogy legyen a piaci szereplőknek lehetőségük a megfelelő kompetenciákat kialakítani. 6. A közbeszerzést alkalmassá kell tenni arra, hogy tudja kezelni a licencvásárlás helyett a szolgáltatás-vásárlást, valamint arra, hogy a kis hazai cégeket is mint partnereket kezelje, és a beszerzést indító intézményeket is motiválni kell abban, hogy ne csak a nagyokban és a multikban bízzanak.30 7. Az újonnan induló, vagy a jelenlegi szoftveren módosítást hozó, közpénzből vagy a közszféra számára történő fejlesztésekben a szabad és/vagy nyílt forrású licencet kell előírni, valamint vagy platformfüggetlenséget, vagy multiplatformosságot.31 30 Lásd a 223. oldalon a szabad és nyílt forráskódú szoftverek gazdasági hatásairól szóló részt. 31 Az, hogy valamit JAVA-ban fejlesztenek sem platformfüggetlenséget, sem multiplatformosságot nem jelent magában. Sok szabályt be kell JAVA alatt is tartani ezek

eléréséhez. A teljesség igénye nélkül, csak érdekességként Multiplatformos fejlesztés lehetséges – C, C++ nyelven, – Pascal és OO Pascal nyelven, – ADA, COBOL, Fortran stb. nyelveken Platformfüggetlen fejlesztés történhet – Perl, – Ruby, – Python, – TCL, – PHP és egyéb szkriptnyelveken, mindig nagyjából ugyanannyi megkötést kell betartani mint JAVA esetén, hogy a kívánt célt elérjük. 2009. június 15 293 15.6 Mi legyen a támogató központ feladata ? – Részvétel az adat feltérképezésben és a csereformátum kialakításban32 , ezek verzióinak gondozása. – Részvétel az oktatási anyagok kialakításában, gondozásában. – Részvétel a vizsgarendszer kialakításában, karbantartásában. – Részvétel a szabad szoftverek honosításában, elvárás, hogy működésük eredményeképpen a honosítás az eredeti projektbe bekerüljön. – Fordítói, honosítói szótár, kifejezésgyűjtemény építése és

rendelkezésre bocsájtása a szoftverek és dokumentációk fordításához. – Részvétel az ODF iratminták kialakításában33 és karbantartásában34 . – Részvétel a tudásbázis építésében, karbantartásában. – A saját disztribúció gondozása, amennyiben saját disztribúció kialakítása lesz a döntés. – Saját, magyar vonatkozású kiegészítések (patch-ek) készítése (például megoldani, hogy az OpenOffice ne „ábra 1.”, hanem „1 ábra” jelölést használjon), és fejlesztőknek történő visszajuttatása35 . 15.7 Hogyan válasszunk szabad és nyílt forráskódú szoftvert ? A jó szoftverválasztás fontos feltételei a következők: 32 Az, hogy XML, önmagában – az XML szabvány volta ellenére is – kevés, mert az XML egy leíró nyelv. Tehát ha azt mondjuk XML-ben, az nem jelent többet, mint ha azt mondjuk magyarul, azaz csak a közlés formáját és szókészletét határozzuk meg nagyjából. A csere formátumnak

részletesen specifikáltnak kell lennie Ilyen adatcsere formátumra példa a könyvtárak által használt HUNMARC (http://www. bdtf.hu/konyvtar/oktatas/marc/Hunmarchtm) 33 Az iratminták (például önkormányzati beszámoló) létezése a sikeres ODFbevezetésnek elengedhetetlen feltétele. 34 Bár az ODF 1.0 az ISO szabvány, az alkalmazások tudhatnak többet is, például 1.1 vagy magasabb verziót Az újabb szoftververziók akár azonos verziójú ODF támogatás esetén is tartalmazhatnak új lehetőségeket, például számolótábla esetén új függvényeket, ezért a karbantartás szükséges és indokolt. 35 Jellemzően nem elég kódot küldeni, hanem kell magyarázat és vannak betartandó szabályok is. A látszattal ellentétben nem feltétlenül egyszerű dolog ez 2009. június 15 294 – Szakértelem, és elegendően teljes kép a területről, amelyet a szoftverrel kívánunk támogatni. – Szubjektivitásoktól mentes igénylista. – Minél teljesebb

információ az elérhető megoldásokról. – Információ mások azonos vagy hasonló területen szerzett tapasztalatairól. – Képesség, készség arra, hogy felismerjük a megszokottól eltérő jóságát céljainkhoz36 , valamint, hogy felismerjük az informatika alárendelt szerepét, és e tény figyelembevételével az elégséges és gazdaságilag optimális megoldást válaszuk. A fenti feltételek szabad és nyílt forrású szoftverek esetén is igazak. Annyival könnyebb a helyzet, hogy – lehetséges a szoftvereket kipróbálni, alapos tesztelésnek alávetni; – tanulmányozásukkal (a forráskód átnézésének lehetősége) azt is megvizsgálni, hogy számunkra érzékelhető hiányosságaik miként orvosolhatóak. Ez lehetővé teszi, elősegíti a szakmailag alaposan megalapozott, saját tapasztalatainkon is alapuló választást. További könnyebbség, hogy nem kell feltétlenül figyelembe vennünk azt, hogy – a gyártó mennyire stabil; – van-e hazai

képviselet; – van-e kézikönyv stb. 36 Azaz felvállaljuk a döntés kockázatát. Volt már reklám is, mely a döntési kockázat felvállalásának kerülésére játszott. Az egyik nagynevű izraeli cég tűzfal termékét reklámozták olyan szlogennel, hogy annak választása esetén a rendszergazda nyugodt lehet. S valóban, még baj esetén is az a helyzet, hogy senki nem vonhatja személyes felelősségre, hogy valami ismeretlen terméket választott, támogatott. Ő egy, a piacon jól bevezetett márkát választott, amit mindenki ismer, sőt a tévében is reklámoznak. Ez természetesen nem jelenti azt, hogy soha nem a legreklámozottabb, vagy éppen piacvezető termék a megfelelő, de azt mindenképpen, hogy nem biztos, hogy nem mindig a legreklámozottabb és/vagy piacvezető az optimális választás. 2009. június 15 295 mert a jogok és a forrás birtokában kialakíthatunk saját magunk is megfelelő kompetenciát a továbbfejlesztéshez, támogatáshoz,

vagy vásárolhatunk szakértelmet a piacon.37 Ráadásul miként az életciklus elemzés (247 oldal) rámutat, a nyílt forrású és szabad szoftverek nem tűnnek el, szűnnek meg, csak alvó állapotba kerülnek, melyből van visszatérés. 15.8 Hogyan vegyünk a szabad és nyílt forrású szoftverekhez támogatást ? Elsődleges forrás még mindig a közösség, az internet.38 A disztribúciók többsége rendelkezik megvásárolható támogatással, mely a disztribúció elemeire vonatkozik. Tudnunk kell, hogy a disztribúciós támogatás is épít a közösségre és a fejlesztőkre. Megkereshetőek a fejlesztők, akikkel általában lehet támogatásról szóló szerződést kötni, de az sem ritka, sőt, sok projektre inkább jellemző, hogy a bejelentett hibákat gyorsan, presztízsből javítják. Hardverek esetén kicsit más a helyzet. – A gyártók egy része zárt forrású,de befordítható szoftvert ad, – más része dokumentációt, – harmadik része

dokumentációt és nyílt forrású szoftvert, – a negyedik – egyelőre még jelenetős tábor – nem biztosít Linuxhoz, vagy egyéb (a Windowstól eltérő) operációs rendszerekhez támogatást. Meg kell jegyezni, hogy ezen eszközök egy része is használható Linux alatt, mert egy felületen keresztül (ndiswrapper39 ) képes a Linux Windows alá írt meghajtókat kezelni. Az, hogy egy adott kernel (adott disztribúcióban szereplő kernel) milyen hardvereket támogat, a disztribúció oldalán jellemzően feltüntetik, valamint tematikus linuxos oldalakon40 is taglalják. 37 Téves elképzelés, hogy lehet olyan kódot írni, melyet az íróján kívül senki nem ért meg. A szabad és nyílt forrású szoftverek esetén a kódmanipulálás (olvashatatlanná tétel) nem is megengedett, és nem is megtűrt. 38 Ezt az úgynevezett üzleti Linuxok (disztribúciók) képviselői nem szeretik elismerni, de a nyílt forrás és a szabad szoftver sajátosságai miatt ez így

van. 39 Az ndis magyarázatát lásd a http://en.wikipediaorg/wiki/Network Driver Interface Specification címen. 40 A http://www.linuxfoundationorg/en/OpenPrinting egy nyomtatókkal foglalkozó oldal A http://www.linux−laptopnet/ egy laptopokkal foglakozó oldal 2009. június 15 296 15.9 Összefoglalva Hardvertámogatást úgy a legkönnyebb kapni, hogy megfelelő hardvert szerzünk be (vagy a gyártó, vagy a disztribúció, vagy a tematikus oldalak alapján igazoltan működő eszközt érdemes választani). Szoftvertámogatást vehetünk a disztribúció képviselőjétől, készítőjétől41 , de bármely Linuxszal, vagy az adott szabad forrású szoftverrel már foglakozó cégtől (lásd Drescher (234. oldal) példája) Ezek jellemzően nem nagy cégek, de ez a szabad és nyílt forrású szoftver sajátosságai miatt nem lehet akadály. Illetve annak sincs akadálya, miként a Szegedi önkormányzat (139. oldal) példája, vagy BalaBit Kft. (229 oldal) példája

mutatja, hogy magunk alakítsunk ki elégséges szakértelmet az internetes közösségre támaszkodva Ma Magyarországon még egy multinak is szüksége van a kis magyar cégekre, amennyiben az egész országra kiterjedő, helyszíni megjelenést is biztosító támogatást akar ésszerű áron biztosítani. Állami, nemzetgazdasági szinten jelentős költség takarítható meg (223. oldal – szabad szoftverek gazdasági hatása), ha a támogatásra közvetlenül ezekkel a cégekkel szerződik az állam. 41 http://uhulinux.hu/termektamogatas 2009. június 15 16. fejezet A „back-office” rendszerek korszerűsítésének lehetősége szabad és nyílt forrású szoftverekkel Az állam és közigazgatás lehetőségeinek elemzése Kedvező – és főleg olcsó – alternatívát jelent a szabad és nyílt forrású szoftverek használata például a következő területeken: – szerver operációs rendszerek (például Linux és BSD Unixok), – webszerverek (Apache stb.),

– mailszerverek (Postfix, Exim, Sendmail stb.), – fájlszerverek (Samba stb.), – adatbáziskezelők (PostgreSql, Mysql, Nosql, berkeleydb stb.), – IP-telefon rendszerek (Asterisk), – webes tartalom-menedzsment (Plon, Drupal, OpenCms), – csoportmunka (Twiki, Flos Wiki, Média Wiki stb.), – gép- és hálózat-menedzsment (OCS Inventory stb.), – titkosítás, védett kapcsolatok (OpenVPN, Openswan stb.), 297 298 – desktop operációs rendszerek (Linux X felülettel és KDE, Gnome, vagy egyéb ablakkezelővel), – levelezés (Claws, Kmail, mutt stb.), – szövegszerkesztés (Koffice, OpenOffice stb.), – editorok (Emacs, Joe, Judy, piko, vi, vim, Kedit stb.), – webböngészés (Firefox, Konquerror stb.), – adattitkosítás (openpgp stb.), és még sorolhatóak a lehetőségek a CD írástól a képszerkesztésen, a kiadványszerkesztésen át a fejlesztői eszközökig. Megfelelő szervezettségi és törvényi háttérrel a szabad és nyílt forrású

szoftverek lényegesen olcsóbbá1 , a nyílt szabványok és közkézen levő elterjedt RFC2 -k betartása esetén átjárhatóbbá, és mindenképpen gyártófüggetlenné teszik a rendszereket. Ma azonban a közigazgatásban ez pontosan az egyértelmű szándék (nincs központi döntés) és a szervezettség hiánya (szétfolyó, nem egyeztetett fejlesztések, gyenge specifikációk) miatt egyszerűen, komoly előkészítés nélkül nem valósítható meg. Lehet elérni eredményeket (lásd szegedi példa3 – 139 oldal), de ezeket egy nem szerencsés, bár technikailag akár még indokolható4 döntés5 nagyon könnyen visszafordíthatja. 1 Lásd a BalaBit példáját, ahol a szervezettséget a cég vezetése adja, azért működik. Szeged példája is tanulságos, ahol a szándék és a szervezettség helyi szinten megvan, komoly számszerűsíthető eredmények vannak, de mert egy nagyobb rendszer (államés közigazgatás) részei, melyben jelenleg ez (a szabad és nyílt

forrású szoftver) nem prioritás, köztes, bármikor visszabillenő állapot állt elő. 2 Az RFC a Request For Comment rövidítése. Ezek protokollok és alkalmazások leírásának gyűjteménye Minden RFC-nek van egy száma, amely az RFC-t azonosítja Néhány példa: RFC765 : File Transfer Protocol (Ftp), RFC768: User Datagram Protocol (UDP), RFC791 : Internet Protocol (IP), RFC792: Internet Control Message Protocol (ICMP), RFC793 : Transmission Control Protocol (TCP), RFC822: Fejléc-, dátum- és időformátumok, RFC826 : Address Resolution Protocol (ARP), RFC903: Reverse Address Resolution Protocol (RARP), RFC1034 és RFC1035 : Domain Name System (DNS), RFC1939 : Post Office Protocol (POP3), RFC2068 : Hypertext Transfer Protocol (HTTP 1.1), RFC2821: Simple Mail Transfer Protocol (SMTP). 3 Átállás OpenOffice irodai alkalmazásra és részben Linux operációs rendszerre. 4 „A legújabb dotnet környezettel sokkal gyorsabb a fejlesztés, s már a középszerű programozók

is képesek vele működő alkalmazást fejleszteni” hangzott el egy interjúban egy fejlesztő szájából. 5 Például egy kötelezően használt szoftvernek új, csak Microsoft technológiával – mely Microsoft operációs rendszerhez kötődik – működő változata, melyet X millióért K év alatt fejlesztettek, s most már muszáj bevezetni. 2009. június 15 299 Így tehát arra a kérdésre, hogy „A nyílt forráskódú szoftverek miként járulhatnak hozzá a közigazgatás szervek – kiemelten az önkormányzatok – back-office rendszereinek korszerűsítéséhez?” kutatásaink alapján az a válasz adható, hogy központi döntés, jogi háttér, megfelelő szervezés és szervezettség, és a célt figyelembe vevő végrehajtás nélkül csak kismértékben. Az például egy Microsoft alapú6 közigazgatás és önkormányzati informatika esetében is lehetőség, hogy a fejlesztések nyílt forrású és/vagy szabad licencek alatt legyenek a jövőben

megvalósítva és kiadva. Ennek a döntésnek és modellnek is lehet valamelyest gazdasági haszna7 (például egy elkészült megoldás több területre is adaptálható, továbbfejleszthető lehet), de függőségünket, gyártóknak való kiszolgáltatottságunkat ez az alaprendszerek és eszközök zárt forrású, üzleti licencei miatt nem csökkenti. Ellenben egy központi döntésen alapuló, megfelelő jogi háttérrel rendelkező, jó szervezésű és szervezettségű, és a célt8 figyelembe vevő végrehajtás, a kezdeti problémák és költségek után rugalmas, gazdaságosan üzemeltethető9 , az állam, a nemzetgazdaság számára kedvező árú10 , gazdaságélénkítő hatású10 , a magyar tulajdonú informatikai vállalkozásokat lehetőségekhez juttató állami, önkormányzati informatika alakítható ki. A megfelelő előkészítés nélküli11 átállás sem eredményességben, sem közép és hosszú távú megtakarításban, sem gazdaságélénkítésben nem

lehet igazán hasznos és eredményes, leginkább arra alkalmas, hogy a szabad és nyílt forrás ellenzői számára újabb érveket szolgáltasson. 6 Ma jellemzően ilyenek az állam és közigazgatás rendszerei. Kutatásunkban az üzleti szféra esetén van ehhez hasonló modell (234. oldal, Drescher), ott nem megtakarításról, hanem időben másképpen jelentkező költségekről beszélnek. 8 Feladatainkat – ha csak lehet – szabad és/vagy nyílt forrású szoftverekkel oldjuk meg. 9 357. oldal, LME anyag, amely a Flosspol eredményekről szól 10 221. oldal, a szabad szoftverek gazdasági hatásai 11 Központi döntés, jogszabályi változások stb. 7 2009. június 15 300 2009. június 15 A függelék A GPL v. 2 jogi szakfordítása 1 Ez a GNU General Public License nem hivatalos magyar fordítása. A fordítást nem a Free Software Foundation tette közzé és jogi értelemben nem határozza meg a GNU GPL révén jogosított szoftverek terjesztési

feltételeit – e tekintetben csak a GNU GPL angol nyelvű verziója irányadó. http://www.gnuorg/licenses/old−licenses/gpl−20html GNU General Public License (GPL) Copyright c 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA Copyright c 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Előszó A legtöbb szoftver licenceit azzal a szándékkal készítették, hogy Öntől a szoftver átdolgozásának és terjesztésének szabadságát elvonják. Ezzel szemben a GNU General Public License célja az, hogy garantálja az Ön számára a szabad szoftver átdolgozásának és terjesztésének szabadságát, ezáltal biztosítva a szoftver szabad használatát minden felhasználó számára. Ennek a General Public Licensenek a szabályai vonatkoznak a Free Software Foundation szoftvereinek nagy részére, illetve minden olyan programra, melynek szerzője úgy dönt, hogy ezt a licencet használja a

felhasználási mód megjelölésekor. (A Free Software Foundation szoftvereinek egy másik részére a GNU LesserGeneral Public License vonatkozik.) Bárki engedélyezheti programjai felhasználását a General Public License-szel. 1 A fordítást Dr. Dudás Ágnes készítette, elérhető : http://wwwdrdudashu/gpl v2 magyarul 301 302 A szabad szoftver megjelölés a szabadságra vonatkozik, és nem az árra. A General Public License-szek célja, hogy biztosítsa az Ön számára a szabad szoftver többszörözésének és terjesztésének jogát (és e szolgáltatásért akár díj felszámítását), a forráskód átadását (vagy igény szerint hozzáférést ehhez a kódhoz), a szoftver átdolgozásának lehetőségét, illetve hogy a szoftver egyes részeit új szabad programokban használhassa fel, és hogy e lehetőségekkel tudatosan élhessen. Az Ön jogai védelmében hozott korlátozások azok, amelyek megakadályozzák, hogy valaki e jogok gyakorlását Önnek

megtilthassa, vagy Önt ezekről lemondásra/tartózkodásra kényszeríthesse. Az ezekből a korlátozásokból eredő felelősség Önt is terheli, amennyiben a szoftver műpéldányokat terjeszti, illetve átdolgozza. Amennyiben Ön például ilyen [licenccel ellátott] program másolatait terjeszti, akár ingyenesen, akár bizonyos díj fejében, a szoftverrel kapcsolatos valamennyi jogot köteles átruházni a [harmadik személy] felhasználónak. Meg kell továbbá győződnie arról, hogy a [harmadik személy] felhasználó számára a forráskód, vagy a kódhoz jutás lehetősége biztosított. És annak érdekében, hogy a [harmadik személy] felhasználó megismerje jogait, ismertetnie kell vele a felhasználás kereteit meghatározó jelen licencet. Az Ön jogait két lépésben védjük: (1) a szoftvereket szerzői oltalom alá helyezzük és (2) felkínáljuk Önnek jelen licencet, amely jogosítja Önt a szoftver többszörözésére, terjesztésére és/vagy

átdolgozására. A szerző és a magunk [FSF] védelmében biztosítani kívánjuk továbbá, hogy mindenki úgy értelmezi, hogy erre a szabad szoftverre nincs szavatosság. Ha a szoftvert átdolgozták és továbbadták, akkor mindenkinek, aki az átdolgozott változatot kapja, tudnia kell, hogy az nem az eredeti, így a mások által okozott hibák nem sérthetik az eredeti szerző hírnevét. Végül és utolsó sorban, valamennyi szabad szoftver létét folyamatosan fenyegetik a szoftverszabadalmak. El kívánjuk kerülni annak veszélyét, hogy a szabad program terjesztői egyedileg szabadalmi oltalmat igényelhessenek, és ezáltal a programot kisajátítsák. Ennek megakadályozásához tisztázni kívánjuk: szabadalom szabad szoftverrel kapcsolatban csak mindenkire vonatkozó hasznosítási joggal jegyezhető be, vagy egyáltalán nem jegyezhető be. A többszörözésre, terjesztésre, átdolgozásra vonatkozó konkrét szabályok és feltételek: a többszörözésre,

terjesztésre és átdolgozásra vonatkozó feltételek és kikötések 0. Ez a licenc minden olyan programra vagy más műre vonatkozik, amelyen a vagyoni jog jogosultja utal arra, hogy a mű a General Public 2009. június 15 303 License-ben foglaltak alapján terjeszthető. A továbbiakban a „Program” kifejezés bármely ilyen programra vagy műre vonatkozik, a „Programon alapuló mű” pedig magát a programot, illetve bármely, annak a szerzői jog által védett átdolgozását jelenti, vagyis olyan művet, amely tartalmazza a Programot vagy annak egy részletét, átdolgozott vagy átdolgozástól mentes formában és/vagy más nyelvre fordítva. (A továbbiakban a fordítás minden egyéb megkötés nélkül beletartozik az átdolgozás fogalmába.) Minden felhasználási engedély jogosultjának (licencbevevő) megjelölése a továbbiakban: „Ön”. A jelen licenc a többszörözésen, terjesztésen és átdolgozáson kívül más felhasználási módra nem

vonatkozik, azok az engedélyezési körön kívül esnek. A Program futtatása nincs korlátozva, illetve a Program eredményeire is csak abban az esetben vonatkozik ez a szabályozás, ha az tartalmazza a Programon alapuló mű egy részletét (függetlenül attól, hogy ez a Program futtatásával jött-e létre). Ez tehát a Program működésétől függ 1. Ön a Program forráskódját átdolgozás nélkül többszörözheti és tetszőleges adathordozón terjesztheti, feltéve, hogy minden egyes példányon szembetűnően pontosan feltünteti a megfelelő szerzői jogi megjegyzést, illetve a garanciavállalás kizárását; érintetlenül kell hagynia minden erre a licencre és a garancia teljes hiányára utaló szöveget, továbbá a jelen licencfeltételeket is el kell juttatnia mindazokhoz, akik a Programot kapják. A másolati példányok fizikai továbbítása fejében díjat kérhet, a Programhoz nyújthat anyagi ellentételezése fejében garanciális támogatást. 2.

Ön jogosult a Program másolatának vagy másolatainak vagy egy részének átdolgozására, amely következtében egy, a Programon alapuló mű jön létre Az így keletkezett, átdolgozott művet ezt követően az 1. szakaszban adott feltételek szerint többszörözheti és terjesztheti, amennyiben az alábbi feltételek is teljesülnek: a) Az átdolgozott fájlokat el kell látnia olyan feltűnő megjegyzéssel, amely tartalmazza, hogy Ön végezte az átdolgozást, és rögzíti az átdolgozás dátumát. b) Gondoskodnia kell arról, hogy minden, az Ön által terjesztett vagy nyilvánosságra hozott mű, amely részben vagy egészben tartalmazza a Programot, illetve a Program átdolgozásával jött létre, valamennyi harmadik személy számára egységként, jelen licencben 2009. június 15 304 meghatározott feltételek szerint díjmentesen kerüljön engedélyezésre. c) Ha az átdolgozott Program alapesetben futtatáskor interaktív parancsokat olvas be, gondoskodnia

kell arról is, hogy amennyiben ilyen interaktív felhasználás a megszokott módon kerül indításra, jelenítsen meg vagy nyomtasson ki egy, a szerzői jogi kitételeket tartalmazó megjegyzést, valamint egy utalást a szavatossági igények kizárására (vagy éppen arra, hogy Ön milyen feltételekkel biztosítja a garanciát), illetve arra, hogy e feltételek betartása mellett a felhasználó terjesztheti a Programot. A felhasználót tájékoztatni kell arról is, hogy miként ismerheti meg a licenc egy példányát. (Kivétel: ha a Program interaktív ugyan, de normál körülmények között nem jelenít meg hasonló megjegyzést, akkor a Programon alapuló műnek sem kell ezt tennie.) Ezek a feltételek az átdolgozott műre, mint egészre vonatkoznak. Ha a mű azonosítható részei nem a Programon alapulnak/nem vezethetőek le a Programból és önálló műként elkülönülten azonosíthatók, akkor ez a felhasználási engedély nem vonatkozik ezekre a részekre,

amennyiben ezeket Ön önálló műként terjeszti. De ha ugyanezeket a részeket egy olyan mű részeként terjeszti, amely a Programon alapul, az egész terjesztésének ezen a szerződésen kell alapulnia, amely szerződésnek az engedélyei a többi felhasználóra is – mint teljes egészre – kiterjednek, és így minden részre is, függetlenül attól, hogy ki írta azokat. E bekezdésnek tehát nem az a célja, hogy a művekkel kapcsolatos szerzői jogokat érvényesítse, vagy hogy a jogait az Ön által alkotott művel kapcsolatban vitassa. Sokkal inkább az a cél, hogy a Programon alapuló származékos, vagy gyűjteményes művek terjesztésének ellenőrzésére vonatkozó jogokat gyakorolja. E felhasználási engedély nem vonatkozik más művekre, amelyek nem a Programon alapulnak, de a Programmal (vagy a Programon alapuló művel) azonos adathordozón kerülnek tárolásra, terjesztésre. 3. Ön jogosult a Program (vagy a 2 szakasz értelmében a Programon alapuló

mű) többszörözésére és terjesztésére tárgykódú vagy futtatható kódú formában az 1. és 2 szakaszban foglaltak szerint, feltéve, hogy az alábbi feltételeket is teljesíti: 2009. június 15 305 a) A programhoz mellékelje a teljes, gép által értelmezhető forráskódot egy jellemzően e célt szolgáló adathordozón, amely az 1. és 2 szakaszban foglaltak szerint kerül terjesztésre, vagy b) A programhoz mellékeljen egy legalább 3 évre vonatkozó írásbeli kötelezettségvállalást, amely alapján bármely harmadik személy rendelkezésére bocsátja a teljes gép által értelmezhető forráskódot a hordozó eljuttatásának költségét meg nem haladó díj fejében, amely az 1. és 2 szakaszban foglaltak szerint kerül terjesztésre, jellemzően e célt szolgáló adathordozón; vagy c) A Programhoz mellékelje azt a forráskód rendelkezésre bocsátására vonatkozó írásbeli kötelezettségvállalást, amelyet Ön is megkapott. (Ez az

alternatíva csak nem kereskedelmi terjesztés esetén alkalmazható, és akkor is csak abban az esetben, ha Ön a Programot tárgyi vagy futtatható kódban a b. cikkelynek megfelelő írásbeli kötelezettségvállalással kapta.) Egy mű forráskódja a műnek azt a formáját jelenti, amely az átdolgozásra elsődlegesen alkalmas. Egy futtatható program a teljes forráskódot jelenti: valamennyi a program által tartalmazott modul forráskódját, továbbá a csatlakozófelület (interface) leírásait tartalmazó fájlokat éppúgy, mint a fordító- és telepítőszkripteket. Mindazonáltal, speciális kivételként, a terjesztett forráskódnak semmi olyasmit nem kell tartalmaznia, amit általában a binárist futtató operációs rendszer fő komponenseivel (fordító, kernel stb.) terjesztenek (forráskód, vagy bináris formában), kivéve, ha maga az adott komponens a futtatható állományt kíséri. Ha a futtatható program vagy tárgykód terjesztése akként

történik, hogy egy erre kijelölt helyen másolási jogot biztosítanak, az a forráskód terjesztésének minősül. Akkor is terjesztésről beszélünk, ha a kódhoz (forráskódként, illetve futtatható formában) ezzel egyenértékű hozzáférést biztosítanak abban az esetben is, ha harmadik személyek nem kötelesek a forráskódot a tárgykóddal együtt lemásolni. 4. Ön nem jogosult a Programot többszörözni, átdolgozni/megváltoztatni, tovább [harmadik személy részére] licencelni (allicencbe adni) vagy terjeszteni, amennyiben Önt e licenc erre kifejezetten nem jogosítja. A többszörözés, átdolgozás, allicencbe adás, terjesztés valamennyi más módja semmis, és automatikusan a licenc által megszerzett jogok elvesztését vonja maga után. Mindazonáltal azon harmadik személyek jogviszonya/felhasználási engedélye, akik Ön által e licenc hatálya alatt 2009. június 15 306 másolatot vagy jogot szereztek, nem szűnik meg mindaddig, amíg e

licencet teljes mértékben elismerik és betartják. 5. Ön nem köteles ezen licencet elfogadni, hiszen nem írta alá Azonban semmilyen más módon nem nyílik joga, hogy a Programot vagy a Programon alapuló művet átdolgozza vagy terjessze. E cselekményeket – amennyiben e licencet nem ismeri el – a törvény tiltja Azáltal, hogy a Programot (vagy a Programon alapuló művet) átdolgozza vagy terjeszti, jelen licenccel és annak minden – a Program többszörözésére, terjesztésére és átdolgozására vonatkozó – feltételével való egyetértését nyilvánítja ki. 6. Minden alkalommal, amikor Ön a Programot (vagy az azon alapuló művet) továbbadja, a fogadó fél automatikusan az eredeti vagyoni jogi jogosulttól (licencbeadó) kap felhasználási engedélyt (licenc) arra, hogy a Programot az itt meghatározott feltételeknek megfelelően többszörözhesse, terjeszthesse, és átdolgozhassa. Ön nem jogosult semmilyen módon a fogadó felet (felhasználót)

megillető jogokat a továbbiakban korlátozni. Ön nem felel azért, hogy harmadik személyek jelen licencet betartsák. 7. Amennyiben Önnek egy bírósági ítélet, szabadalomsértés vélelme, vagy más (nem szabadalmi kérdésekre korlátozódó) okból olyan feltételeknek kell megfelelnie (akár bírósági határozat, akár egyezség vagy bármi más eredményeképp) amelyek jelen Licenc feltételeivel ellentétesek, Ön nem mentesül jelen licenc rendelkezései alól. Amennyiben nem lehetséges, hogy a Programot egyidejűleg a licenc feltételeinek és a másrészről keletkezett kötelezettségeinek figyelembevétele mellett terjessze, akkor Ön a Program terjesztésére egyáltalán nem jogosult. Ha például egy szabadalom nem teszi lehetővé, hogy azok, akik a Programot közvetlen vagy közvetett módon Öntől kapták meg azt díjmentesen továbbterjeszthessék, az egyetlen választható megoldás az marad, annak érdekében, hogy a szabadalmi jogot és ezen licencet is

kövesse, ha a program terjesztésétől teljes mértékben tartózkodik/eláll. Ha ezen paragrafusok egy része érvénytelennek vagy bizonyos körülmények között érvényesíthetetlennek minősülne, ezen Paragrafust értelemszerűen kell alkalmazni; a többi esetben a Paragrafust, mint egészet kell érvényesíteni. Ezen Paragrafusok célja nem az, hogy Önt valamely szabadalom vagy más tulajdonjogi igény megsértésére ösztönözze, illetve hogy ezen igények hatályosságát/jogosságát vitassa; e Paragrafus egyetlen célja, hogy 2009. június 15 307 a szabad szoftverek terjesztési rendszerének integritását – amely a nyilvános licencek gyakorlata által valósul meg – megóvja. Jelen rendszer keretében terjesztett szoftverek jelentős kínálatához sok ember nagylelkű felajánlással, a rendszer következetes működésében bízva járult hozzá; a Szerző/Vagyoni jogi jogosult joga eldönteni, hogy a szoftvert valamely másik rendszer keretében is

terjeszteni kívánja-e, a felhasználónak (licencbe vevőnek) erre a döntésre semmilyen ráhatása nincs. E szakasz célja az, hogy pontosan tisztázza, mit kell következtetésként/következményként a licenc hátralévő részéből figyelembe venni. 8. Ha a Program terjesztése és/vagy használata egyes országokban akár szabadalmak, akár szerzői jogi oltalom alatt álló csatlakozó felületek (interface) miatt korlátozott, akkor a Program szerzői jogi jogosultja, aki a Programot e licenccel tette közzé/e licenc alá helyezte, a terjesztést kifejezett területi korlátozással láthatja el. Amennyiben bizonyos országok kizárásra kerülnek, a terjesztés csak olyan országokra vonatkozóan lesz engedélyezett, amelyek nincsenek kizárva. Ilyen esetben a korlátozás a licenc részét képezi, mintha ezen szöveg részeként került volna megfogalmazásra. 9. A Free Software Foundation időről időre kiadja/nyilvánosságra hozza a General Public License dokumentum

átdolgozott és/vagy új változatait. Ezek az újabb változatok alapvetően a korábbiak szellemében készülnek, de részletekben eltérhetnek annak érdekében, hogy új problémákat vagy kihívásokat is kezeljenek. Jelen licenc minden változatának egy egyedi megkülönböztető verziószáma van. Ha a Program szerzői jogi megjegyzésében egy bizonyos verziószám, vagy „valamennyi újabb verzió” van megjelölve, akkor Önnek lehetősége van arra, hogy akár a megjelölt, akár a Free Software Foundation által kiadott későbbi verzióban leírt feltételeket kövesse. Ha nincs ilyen megjelölt verzió, akkor Ön jogosult a Free Software Foundation által valaha kibocsátott bármelyik licencet választani. 10. Amennyiben a Programot más szabad szoftverben kívánja felhasználni, amelynek a terjesztéssel kapcsolatos feltételei eltérőek, írjon a Szerzőnek, és kérje ehhez a hozzájárulását. Olyan szoftverek esetében, ahol szerzői jogi jogosultként a

Free Software Foundation van megjelölve, írjon a Free Software Foundation-nek. Néha teszünk kivételt A döntést a következő célok szem előtt tartásával hozzuk meg: maradjon meg a szabad szoftvereinken alapuló művek szabad állapota, valamint segítse elő – általában véve – a szoftver újrafelhasználását és megosztását. 2009. június 15 308 garanciavállalás hiánya 11. mivel jelen program díjmentesen kerül engedélyezésre, a jogszabályokban meghatározott keretekig kizárjuk a programmal kapcsolatos garanciát. amennyiben írásban ettől eltérően nem rendelkeznek, a szerzői jogi jogosultak és /vagy harmadik személyek a programot „jelen állapotában” (ahogy van) bocsátják rendelkezésre, bármilyen garancia nélkül, sem kifejezetten, sem belefoglalva, ide értve – de nem korlátozva – forgalombahozatal vagy egy bizonyos célra történő alkalmazhatóságra vonatkozó garanciákat. a program minőségéből és

működéséből/teljesítményéből fakadó összes kockázatot ön viseli amennyiben a program hibásan működik, önnek kell vállalni a szükséges szerviz, javítás vagy kiigazítás költségeit. 12. semmilyen esetben sem – kivéve, ha a hatályos jogszabályok megkívánják vagy írásban rögzítésre került – köteles a vagyoni jogi jogosult vagy valamely, a programot a fentebb rögzített engedély alapján átdolgozó vagy terjesztő harmadik személy önnel szemben kárért, ide értve az általános vagy különös károkért, károk mellékhatásaiért vagy következményeiért, amelyek a program használatából vagy használhatatlanságából eredtek (ide értve, de nem korlátozva az adatvesztésre, az adatok hibás feldolgozására, veszteségekre, amit önnek vagy harmadik félnek kell viselnie, vagy olyan hibára, amely következtében a program más programmal nem tud együttműködni) nem felel, abban az esetben sem, ha a vagyoni jogi jogosult vagy

harmadik személy figyelmét ezen károk bekövetkezésének lehetőségére felhívták. feltételek és szabályok vége 2009. június 15 B függelék Európai Uniós Nyílt Forráskódú Licenc v.11 EUPL c Európai Közösség 2007 Az Európai Uniós Nyílt Forráskódú Szoftver Licencet (a továbbiakban: „EUPL”)1 arra az alábbiakban meghatározott Műre vagy Szoftverre kell alkalmazni, amelyet e Licenc feltételei szerint bocsátanak rendelkezésre. A Mű e Licencben engedélyezettől eltérő felhasználása tilos (amennyiben a Mű szerzői jogi jogosultjának valamely joga e felhasználásra kiterjed). Az Eredeti Művet e Licenc rendelkezései szerint bocsátják rendelkezésre, ha (az alábbi meghatározás szerinti) Jogosult az Eredeti Műre vonatkozó szerzői jogkezelési adat után közvetlenül feltüntette az alábbi közleményt: Licenc az EUPL v.11 verziója szerint vagy bármilyen egyéb formában az EUPL szerinti felhasználásra vonatkozó nyilatkozatot

tett. 1. Fogalommeghatározások E Licencben az alábbi fogalmak jelentése a következő: Licenc. E Licenc (felhasználási engedély) Eredeti Mű vagy Szoftver. A Jogosult által e Licenc alapján terjesztett vagy nyilvánossághoz közvetített szoftver, amely Forráskódként, egyes esetekben Végrehajtható kódként hozzáférhető. 1 EUPL: „European Union Public Licence” 309 310 Származékos Művek. Az Eredeti Mű vagy annak átdolgozásai alapján a Felhasználó által alkotott művek vagy szoftverek. E Licenc nem határozza meg, hogy az Eredeti Mű milyen mértékű átdolgozása vagy a Származékos Műtől való milyen mértékű függése szükséges ahhoz, hogy egy mű Származékos Műnek minősüljön; ezt a mértéket a 15. cikkben említett ország szerzői joga határozza meg. Mű. Az Eredeti Mű és/vagy annak átdolgozásai alapján létrejött Származékos Művek Forráskód. A mű ember számára olvasható változata, amely az ember által való

tanulmányozásra és a módosításra a legalkalmasabb. Végrehajtható kód. A Műnek bármely - általában - fordított kódban létező formája, amelynek rendeltetése, hogy azt a számítógép programként értelmezze. Jogosult. Az a természetes vagy jogi személy, aki/amely a Művet a Licenc alapján terjeszti és/vagy a nyilvánossághoz közvetíti. Közreműködő(k). Az a természetes vagy jogi személy, aki/amely a Licenc alapján átdolgozza a Művet, vagy más módon hozzájárul a Származékos Mű megalkotásához. Felhasználó (Ön). Az a természetes vagy jogi személy, aki/amely a Licenc feltételei szerint felhasználja a Szoftvert. Terjesztés és/vagy Nyilvánossághoz Közvetítés. A Mű példányának adásvétele, birtokba adása, haszonkölcsönbe adása, bérbe adása, terjesztése, nyilvánossághoz közvetítése, átvitele vagy bármely egyéb, online vagy offline módon történő hozzáférhetővé tétele, illetve alapvető funkcióihoz való

hozzáférés biztosítása harmadik, természetes vagy jogi személy részére. 2. A Licenc által biztosított jogok terjedelme A Jogosult az Eredeti Mű szerzői jogi védelmének időtartamára az egész világra kiterjedő, díjmentes, nem kizárólagos és harmadik személyeknek továbbengedélyezhető engedélyt ad Önnek az alábbi cselekményekre: – a Mű felhasználása tetszőleges körülmények között és bármilyen célra, – a Mű többszörözése, 2009. június 15 311 – az Eredeti Mű átdolgozása, és a Műből Származékos Művek létrehozása, a Műnek vagy másolatainak a nyilvánossághoz közvetítése, ideértve a nyilvánosság számára történő hozzáférhetővé tételt vagy képernyőn történő nyilvános megjelenítést, illetve adott esetben a Mű nyilvános előadását, – a Mű vagy a Mű másolatainak terjesztése, – a Mű vagy a Mű másolatainak haszonkölcsönbe adása vagy bérbeadása, – a Művön vagy Mű másolatain

fennálló jogok harmadik személynek történő továbbengedélyezése. Az említett jogok gyakorlása lehetséges bármilyen jelenleg létező vagy még ismeretlen médium, hordozó és formátum igénybevételével, amennyiben ezt az alkalmazandó jog megengedi. Azokban az országokban, ahol elismerik a személyhez fűződő jogokat, a Jogosult az alkalmazandó jog által megengedett mértékben a fentiekben megnevezett vagyoni jogokra vonatkozó engedély akadálytalan gyakorlása céljából lemond a személyhez fűződő jogainak gyakorlásáról. A Jogosult díjmentes és nem kizárólagos engedélyt ad a Felhasználó számára a Jogosultat megillető szabadalmak hasznosítására olyan mértékben, amely szükséges a Művön fennálló, e Licencben meghatározott jogok gyakorlásához. 3. A Forráskód nyilvánossághoz közvetítése A Jogosult a Művet Forráskód, vagy Végrehajtható kód formájában bocsáthatja rendelkezésre. Ha a Művet Végrehajtható kódként

bocsátotta rendelkezésre, a Jogosult a mű általa terjesztett valamennyi példányához köteles rendelkezésre bocsátani a Mű Forráskódjának géppel olvasható példányát, vagy a Műhöz csatolt szerzői jogi nyilatkozatot követő közleményben megadja azt a helyet, ahol a Forráskód egyszerűen és ingyenesen hozzáférhető mindaddig, amíg a Jogosult folytatja a Mű terjesztését és/vagy nyilvánossághoz közvetítését. 4. A szerzői jog korlátai E Licencben semmi sem irányul arra, hogy megfossza a Felhasználót azoktól a kedvezményektől, amelyek az Eredeti Mű vagy Szoftver jogosultjainak kizárólagos jogai alóli kivételeken vagy azok korlátjain, kimerülésén, vagy egyéb alkalmazandó korlátozásain alapulnak. 2009. június 15 312 5. A Felhasználó kötelezettségei A fent felsorolt jogok gyakorlásának engedélyezése a Felhasználót terheli, alábbi korlátozások és kötelezettségek tiszteletben tartásától függ. E kötelezettségek

a következők: Feltüntetéshez való jog. A Felhasználó köteles sértetlenül hagyni minden szerzői jogi jogkezelési adatot, szabadalmi vagy védjegyjogra, továbbá minden más, a Licencre utaló, valamint a szavatosság korlátozásával kapcsolatos nyilatkozatot. A Felhasználó köteles e nyilatkozatok és a Licenc egy példányát a terjesztett és/vagy nyilvánossághoz közvetített Mű valamennyi másolatához hozzácsatolni. A Felhasználó köteles jól látható nyilatkozatot elhelyezni az általa átdolgozott Származékos Művön a Mű átdolgozására és az átdolgozás időpontjára vonatkozóan. „Copyleft”-kikötés. Amennyiben a Felhasználó az Eredeti Mű példányait vagy az Eredeti Művön alapuló Származékos Művet terjeszti és/vagy nyilvánossághoz közvetíti, e Terjesztés és/vagy Nyilvánossághoz Közvetítés csak e Licenc, illetve e Licenc egy későbbi verziójának feltételei szerint történhet, kivéve ha az Eredeti Mű a Licencnek

kizárólag e verziója alapján terjeszthető. A Felhasználó (ebben az esetben Jogosultként) nem ajánlhat, illetve nem köthet ki a Műre vagy a Származékos Műre vonatkozóan olyan járulékos feltételeket, amelyek megváltoztatják vagy korlátozzák a Licenc feltételeit. Kompatibilis Licenc alkalmazása. Amennyiben a Felhasználó az Eredeti Műből és egy másik, Kompatibilis Licenc alapján felhasznált Műből létrehozott Származékos Művet vagy e Származékos Mű másolatait terjeszti és/vagy nyilvánossághoz közvetíti, e terjesztés és/vagy nyilvánossághoz közvetítés történhet a Kompatibilis Licenc feltételei alapján. E kikötés alkalmazásában Kompatibilis Licenc az e Licenchez csatolt függelékben felsorolt licenceket jelenti. Amennyiben a Felhasználó Kompatibilis Licenc szerinti kötelezettségei ellentétesek az e Licenc szerinti kötelezettségeivel, a Kompatibilis Licenc szerinti kötelezettségeket kell alkalmazni. A Forráskód

rendelkezésre bocsátása. A Felhasználó a Mű példányainak terjesztése és/vagy nyilvánossághoz közvetítése során köteles rendelkezésre bocsátani a Forráskód géppel olvasható példányát vagy megjelölni azt a helyet, ahol a Forráskód egyszerűen és ingyenesen hozzáférhető mindaddig, amíg a Felhasználó a Mű terjesztését és/vagy nyilvánossághoz közvetítését folytatja 2009. június 15 313 Jogvédelem. A Licenc nem ad engedélyt a Jogosultat illető kereskedelmi név, védjegy, szolgáltatási védjegy, illetve a Felhasználó nevének használatára, kivéve a Mű eredetének leírásához szükséges ésszerű és rendeltetésszerű, valamint a szerzői jogkezelési adat többszörözéséhez szükséges használatot. 6. Szerzőségi láncolat (jogszavatosság) Az eredeti Felhasználó helytáll azért, hogy ő a felhasználásra engedélyezett Eredeti Mű szerzői jogosultja, vagy a szerzői jogok gyakorlására engedéllyel rendelkezik, és

jogosult a Licenc szerinti engedély megadására. Valamennyi Közreműködő helytáll azért, hogy ő a Művön az általa végrehajtott átdolgozások szerzői jogosultja, vagy a szerzői jogok gyakorlására engedéllyel rendelkezik, és jogosult a Licenc szerinti engedély megadására. Minden alkalommal, amikor Ön elfogadja a Licencet, az eredeti Jogosult és az őt követi Közreműködők a Műhöz általuk nyújtott hozzájárulás felhasználására e Licenc feltételei szerinti engedélyt adnak Önnek. 7. A szavatosság korlátozása A Mű, amelyet számos közreműködő fejleszt, folyamatosan változik. Nem tekinthető befejezett műnek, emiatt az ilyen típusú szoftverfejlesztésre jellemző hiányosságokat vagy hibákat tartalmazhat. A fenti okok miatt a Művet a Licenc feltételei szerint „ahogy van” alapon és a Műre vonatkozó bármiféle szavatosság vállalása nélkül bocsátják rendelkezésre, ideértve különösen a piacképességre, valamely

meghatározott célra való alkalmasságra, a hibák, hiányok, tévedések fennállására, a pontosságra és a Licenc 6. cikkében említett szerzői jogon kívüli szellemi tulajdonjogok sértetlenségére vonatkozó helytállás kizárását. A szavatosság korlátozására vonatkozó nyilatkozat a Licenc lényeges rendelkezése és feltétele a Művön fennálló bármely jog gyakorlása engedélyezésének. 8. Felelősségkorlátozás A szándékosság vagy a természetes személyeknek okozott közvetlen károkozás esetét kivéve a Jogosult még abban az esetben sem felel a Licencből vagy a Mű felhasználásából eredő bármilyen közvetlen vagy közvetett, vagyoni vagy nem vagyoni kárért, ideértve különösen az üzleti jóhírnév csor2009. június 15 314 bításából, a termelés szüneteltetéséből, számítógépes meghibásodásból vagy üzemhibából, adatvesztésből eredő vagy kereskedelmi jellegű károkat, ha a Jogosultat előzetesen

figyelmeztették e károk bekövetkezésének lehetőségére. A Jogosult azonban a jogszabályban előírt kellékszavatossággal tartozik, amennyiben e szabályok a Műre alkalmazandók. 9. Kiegészítő megállapodások Az Eredeti Mű vagy a Származékos Művek terjesztése során Ön díjfizetés ellenében támogatás nyújtására, szavatosság, jótállás vagy egyéb, felelősségvállalási kötelezettség vállalására és/vagy e Lincenccel összhangban álló egyéb szolgáltatások nyújtására vonatkozó kiegészítő megállapodást köthet. E kötelezettségeket azonban Ön nem az eredeti Jogosult vagy az egyéb Közreműködő nevében és terhére, hanem csak a saját nevében és felelősségére vállalhatja el, és kizárólag akkor, ha vállalja, hogy a Közreműködőket kártérítésben részesíti, illetve mentesíti azon felelősség, illetve a velük szemben érvényesített azon igények alól, amelyek az Ön által vállalt szavatossági helytállás

vagy kiegészítő felelősség következtében keletkeztek. 10. A Licenc elfogadása E Licenc rendelkezéseit Ön elfogadhatja úgy, ha az e Licenc szövegét tartalmazó ablak alatt található „Elfogadom” feliratú ikonra kattint, vagy ha az alkalmazandó jog rendelkezéseivel összhangban bármely más hasonló módon kifejezi a beleegyezésre irányuló akaratát. Ha Ön az ikonra kattint, az a Licenc és az abban foglalt valamennyi feltétel egyértelmű és visszavonhatatlan elfogadását jelenti. Ehhez hasonlóan e Licenc és az ebben foglalt valamennyi feltétel visszavonhatatlan elfogadását jelenti a Licenc 2. cikkében az Önnek biztosított jogok gyakorlása, többek között a Mű felhasználása, Származékos Műnek az Ön általi létrehozása, valamint a Műnek vagy példányainak az Ön által történő terjesztése vagy nyilvánossághoz közvetítése. 11. A nyilvánosság tájékoztatása Amennyiben Ön a Művet elektronikus úton közvetíti

nyilvánossághoz (például a távolból való letöltésre kínálja fel a Művet), a terjesztési csatornának vagy médiumnak (például weboldal) legalább az alkalmazandó jog által előírt, a Jogosultra, valamint arra vonatkozó tájékoztatást kell közzétennie, 2009. június 15 315 hogy a Felhasználó miként férhet hozzá a Lincenchez, azt hogyan fogadhatja el, tárolhatja, illetve többszörözheti. 12. A Licenc megszűnése A Licenc és az abban biztosított jogosultságok automatikusan hatályukat vesztik, ha a Felhasználó a Licenc feltételeit bármely módon megszegi. E megszűnés nem eredményezi azon személyeknek adott engedélyek hatályának megszűnését, akiknek a Felhasználó a Licenc keretében bocsátotta rendelkezésre a Művet, feltéve hogy e személyek továbbra is teljes mértékben eleget tesznek a Licenc feltételeinek. 13. Vegyes rendelkezések A 9. cikk sérelme nélkül a Licenc a tárgyát képező Műre nézve a felek közötti

teljes és mindenre kiterjedő megállapodás. Ha a Licenc valamely rendelkezése az alkalmazandó jog szerint érvénytelen vagy kikényszeríthetetlen, ez nem érinti a Licenc mint egész érvényességét vagy kikényszeríthetiségét. Az ilyen rendelkezést az érvényességéhez és kikényszeríthetőségéhez szükséges módon kell értelmezni vagy módosítani. Az Európai Bizottság szükséges és indokolt esetben nyilvánosságra hozhatja e Licenc más nyelvű fordításait és/vagy újabb változatait, ezek azonban nem korlátozhatják a Licenc által biztosított jogok hatályát. A Licenc új változatait egyedi verziószámmal teszik közzé E Licenc bármely az Európai Bizottság által jóváhagyott más nyelvű fordítása azonos joghatással rendelkezik. A szerződő felek szabadon használhatják a Licenc általuk választott nyelvre fordított változatát. 14. Hatáskör Az e Licenc értelmezéséből eredő bármely, az Európai Bizottság mint Jogosult és

bármely Felhasználó közötti jogvita az Európai Közösséget létrehozó szerződés 238. cikkének megfelelően az Európai Közösségek Bíróságának hatáskörébe tartozik. Az Európai Bizottságon kívüli szerződő felek közötti, e Licenc értelmezéséből eredő bármely jogvita azon ország megfelelő hatáskörrel rendelkező bíróságának kizárólagos illetékessége alá tartozik, ahol a Jogosult székhelye található, vagy ahol fő tevékenységét folytatja. 2009. június 15 316 15. Alkalmazandó jog E Licencre az Európai Unió azon tagállamának a joga alkalmazandó, ahol a Jogosult lakóhelye vagy nyilvántartásba vett székhelye található. A Licencre a belga jog irányadó, amennyiben: – a jogvita az Európai Bizottság mint Jogosult és bármely Felhasználó között keletkezik; – az Európai Bizottságon kívüli Jogosult az Európai Unió egyetlen tagállamában sem rendelkezik lakóhellyel vagy nyilvántartásba vett székhellyel.

Függelék Az EUPL 5. cikke szerinti „Kompatibilis licencek”: – GNU General Public License (GNU GPL) v. 2 – Open Software License (OSL) v. 21, v 30 – Common Public License v. 10 – Eclipse Public License v. 10 – Cecill v. 20 2009. június 15 C függelék Az elektronikus közigazgatás, az e-biztonság elsődleges, releváns jogszabályi környezete Elsődleges jogi szabályok: – 2004. évi CXL törvény A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket.) – 195/2005. (IX 22) Kormányrendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról – 193/2005. (IX 22) Kormányrendelet az elektronikus ügyintézés részletes szabályairól • in: ügyfélazonosítás végrehajtási szintű szabályai – 84/2007. (IV 25) Kormányrendelet a Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek

biztonsági követelményeiről • egységes biztonsági követelmények rögzítése. A rendelet előírásait mindazoknak is teljesíteni kell, akik csatlakozni szeretnének például az Elektronikus Kormányzati Gerinchálózathoz (EKG), vagy az Ügyfélkapu rendszeréhez. – 44/2005. (III 11) Kormányrendelet A kormányzati informatika koordinációjáról és a kapcsolódó eljárási rendről – 1995. évi LXV tv Az államtitokról és a szolgálati titokról 317 318 • in: releváns, kapcsolódó titokvédelmi szabályok – 1992. évi LXIII tv A személyes adatok védelméről és a közérdekű adatok nyilvánosságáról • in: releváns, kapcsolódó titokvédelmi szabályok – 43/1994. (III 29) Kormányrendelet A rejtjeltevékenységről • in: releváns, kapcsolódó titokvédelmi szabályok – 1992. évi LXXII tv A távközlésről – 1995. évi LXVI tv A közokiratokról, a közlevéltárakról és a magánlevéltári anyag védelméről – 1978.

évi IV tv Büntető törvénykönyvről • B) Biztonsági ajánlások, szabványok – A KIETB 22. sz ajánlása a kormányzati intézmények informatikai stratégiájának készítésére – Az MSZ – ISO/IEC 27001:2006 Informatika. Biztonságtechnika Az információbiztonság irányítási rendszerei Követelmények – MSZ – ISO/IEC 17799-2003, Információ technika. Az informatikai biztonság eljárás rendje – MSZ ISO/IEC 15408 Az informatikai biztonságértékelés közös szempontjai 2009. június 15 D függelék Linux, GNU, disztribúció Mi a Linux ? A „Linux” elnevezés szigorú értelemben véve a Linux-rendszermagot jelenti, amelyet Linus Torvalds kezdett el fejleszteni 1991-ben.1 Mi a GNU ? A GNU (ejtsd: géenú vagy gnú) egy kizárólag szabad szoftverből álló számítógépes operációs rendszer. A rövidítés jelentése rekurzív (önhivatkozó) módon „GNU’s Not Unix”, azaz „a GNU nem Unix”. Ez arra utal, hogy a GNU egy Unix-szerű

(Unix jellegű) operációs rendszer, viszont nem tartalmaz Unixból származó kódot, és a Unix-szal ellentétben szabad szoftver.2 A GNU-t a GNU Projekt keretében fejlesztik. A projekt szárnyai alatt kiadott programokat pedig GNU csomagoknak vagy GNU programoknak hívják A rendszer alapvető összetevői közé tartozik a GNU Compiler Collection (GCC, GNU fordítóprogram-gyűjtemény), a GNU Binary Utilities (binutils), a Bash rendszerhéj, a GNU C library (glibc), és a GNU Core Utilities (coreutils). A GNU projekt 1983-ban Richard M. Stallman vezetésével indult azzal a céllal, hogy teljes értékű, Unix-szerű, de szabad operációs rendszert fejlesszenek ki. A GNU-t folyamatosan fejlesztik. Bár szinte minden része régóta teljes, a hivatalos rendszermagja (kernel) – a GNU Hurd – még mindig félkész, és nem minden GNU összetevő működik vele. Emiatt általában egy külső 1 2 Forrás: http://hu.wikipediaorg/wiki/Linux Forrás:

http://hu.wikipediaorg/wiki/GNU 319 320 magot, a Linux kernelt szokták használni helyette. Az ilyen rendszert általában egyszerűen Linuxnak nevezik, egyesek szerint viszont pontosabb lenne a GNU/Linux elnevezés. Ezt a magot hivatalosan nem fogadta be a GNU projekt, de más külső szoftvereket igen. Mi a disztribúció ? A számítástechnikában a „distribution” szó hagyományosan az ügyfelekhez elküldésre felkészített szoftvert jelenti. A szoftver a szükséges dokumentációval, telepítőkészlettel, esetleg hardverelemekkel (például titkosítókulcs) együtt, offline szállítás esetén ízlésesen csomagolva kerül az ügyfélhez, nem pedig valamilyen nehezen kezelhető formátumban, például kinyomtatott forráskódként (bár ez bő három évtizede még bevett gyakorlat volt). A „GNU/Linux disztribúció” ennek megfelelően a GNU/Linux, felhasználásra alkalmas módon csomagolva. Ahogy a GNU/Linux rendszer túllépett a tudományos-technikai

érdekesség állapotán, felmerült az igény, hogy lehessen kísérletezni vele igen magas szintű szakmai ismeretek nélkül. Az első GNU/Linux disztribúciók 1992-ben jelentek meg. Hogy pontosan mi van egy ilyen „csomagban” az változó, de bizonyos alapelemek és vezérelvek közösek. A két legfontosabb alapelem a Linux kernel és a számtalan különböző, GNU/GPL vagy hasonló licenc alatt terjesztett szabad szoftver, kezdve a fájlrendszer alapvető kezelését biztosító ls parancstól a disztribúció céljától függően webböngészőkig vagy adatbázis-szerverekig. A többi elem opcionális, de valamilyen formában általában megtalálható: Csomagkezelés. A legtöbb disztribúció lényegesen több alkalmazást tartalmaz, mint amennyire a felhasználónak szüksége van A Debian GNU/ Linux például tucatnyi kisebb-nagyobb adatbázis-szervert tartalmaz, többet, mint amennyire egy számítógépen bárkinek is szüksége lehet. A legegyszerűbb csomagkezelő

lehet egy lista a tömörített állományokról, az igazán kifinomultak képesek kezelni a csomagok közötti összefüggéseket, az operációs rendszer frissítését, a csomagok közötti keresést stb. Nevezetesebb csomagkezelő megoldások a Red Hat-tól eredő RPM, a Debian GNU/Linux-tól eredő DEB, és a különböző BSD-ktől eredő PORTS rendszer. Telepítő. Általában szükséges egy különálló alkalmazás, amely gondoskodik arról, hogy a disztribúció felkerüljön egy számítógépre. Ez lehet végtelenül egyszerű, például egy CD-ről bootoló diagnosztikai célú rendszer 2009. június 15 321 esetében, és lehet szerteágazó, mint a Debian GNU/Linux esetében, amit tucatnyi fajta hardverre lehet telepíteni, sok különböző módon, beleértve a mágnesszalagról telepítést mainframe gépekre. Dokumentáció. A legtöbb szabad szoftverhez tartozik dokumentáció: kézikönyv (man) oldalak, info oldalak, gyakorlati útmutatók (howto), olykor

egészen komoly, olvasmányos tankönyvek (például a Gimp rajzolóprogram vagy a LaTeX dokumentumszerkesztő tartalmaz grafikai és tipográfiai elméletről írásokat). Ezek tárolásáról, megjelenítéséről, a megjelenítéshez szükséges alkalmazásokról szintén a disztribúciónak kell gondoskodnia. Forráskód. A nagyobb disztribúciók gondoskodnak arról, hogy az általuk terjesztett szabad szoftverek forráskódja is könnyen elérhető legyen. A Red Hat és Debian alapú rendszerek például a bináris, futtatható csomagokkal párhuzamosan tartalmazzák a forráskódot is, megfelelően csomagolva, a konfiguráláshoz és lefordításhoz szükséges eszközökkel együtt. A Gentoo GNU/Linux disztribúció pedig, mint szélsőséges példa, minden szoftverterjesztést forráskódként végez, és a célgépen állítja elő a forráskódból a bináris, futtatható állományokat. Repository. Jobb magyar szó híján ez egy interneten elérhető szerver, ahol egy

disztribúció összes csomagja és kiegészítője megtalálható. Ez tényleg csak a nagyobb, általános célú disztribúciók sajátja, és rendkívüli módon megkönnyíti a rendszer frissítését vagy új alkalmazások telepítését. Megfelelő repositorykkal lehetséges, hogy ne a teljes disztribúciót kelljen magával hordania a felhasználónak (például 4-5 DVD lemezen), hanem egy pendrive-on vagy egy névjegykártya méretű cd-n egy minimális telepítőrendszert, ami aztán képes az összes szükséges elemet letölteni az internetről. GNU/Linux disztribúció számtalan van. Vannak nagy, széles körben elterjedt, általános célú disztribúciók, mint a Red Hat, Debian, Ubuntu, Gentoo, és vannak kisebb, speciális célúak, mint a Gibraltar (egy CD-ről bootoló tűzfal), a ClusterKnoppix (amellyel OpenMosix clustert lehet egyszerűen összeállítani), vagy a Damn Small Linux (amely egy kifejezetten elavult számítógépeken történő használatra

tervezett, kisméretű és kis teljesítményigényű szoftvereket tartalmazó disztribúció). A kisebb disztribúciókat akár egy ember is össze tudja állítani, a (számítástechnikai) katasztrófaelhárításra való kis disztribúciók nagy része egy ember, vagy egy pár fős csapat alkotása. Ugyanakkor a nagyobb disztribúciókon több száz vagy ezer fős önkéntes csapat (Debian), vagy cég (Ubuntu, Red Hat, SuSe) dolgozik. 2009. június 15 322 Sok disztribúcióval foglalkozó cég – például Novell (SuSe), Red Hat – közösségi változatú Linux disztribúcióval működik együtt, ilyenek például Open SuSe, Fedora. Olyanok is vannak, amelyek egyenesen a Debianra építenek, ilyen például a Knoppix és az Ubuntu. A Debian különlegessége, hogy nincs mögötte cég, csak a „Debian közösség”, s mégis a legtöbb csomaggal rendelkező, legtöbb platformot támogató (30 feletti processzor), és sokak szerint szerver oldalon a legstabilabb,

legbiztonságosabb disztribúciót készítik. S még egy érdekessége a Debiannak, annak ellenére, hogy nem áll mögötte cég, a Hewlett-Packard (HP) – de más cégek is – saját hardver-platformjukon biztosítanak hozzá támogatást. 2009. június 15 E függelék Szegfű László vezető-tanácsos véleménye Szeged Megyei Jogú Város Polgármesteri Hivatalának Informatikai Vezetőjének, Szegfű László vezető-tanácsos, osztályvezetőnek a véleménye a tanulmányunk által érintett kérdésekről. A szegedi környezet: Szeged M. J Város Polgármesteri Hivatalban közel 600 db számítógép és 20 db szerver üzemel. Érvek és ellenérvek a szabad és nyílt forráskódú szoftverekkel kapcsolatban Érvek a szabad és nyílt forráskódú szoftverek mellett – Nem kell licencet vásárolni, a licencköltség megmarad. – A hivatalok többségében a számítógépet még mindig „okos írógép”ként használják. Ha csak ebben a kérdéskörben

vizsgáljuk a költségmegtakarítást, akkor is megmutatható a licencárak kiesése miatt, hogy jelentős költségmegtakarítás érhető el (ha a kliens számítógépeket nézzük: egy Windows XP Professional OEM ára1 körülbelül 30 000 Ft, egy Microsoft Office 2007 OEM ára1 körülbelül 90 000 Ft. 600 gépre 1 Az OEM termékár csak becslés, ennél alacsonyabb áron is elérhető lehet a piacon az adott szoftver OEM változata. Néhány szállító OEM szoftverrel szállítja a gépeit, és csak úgy. 323 324 72 000 000 Ft. Az OEM termékek csak adott gépre szólnak, így a gépek cseréjekor újabb költségekkel kell számolni2 ). – Az önkormányzatunknál a megtakarítás számszerűen a következőképpen néz ki. A kliens számítógépek esetében a licencdíjak fent már jelezve lettek, ezeket nem kellett kifizetnünk Ezeket lehet kevesebbnek mondani, vagy éppen gondolni, de semmiképpen nem tekinthetőek nullának. Tehát az elmúlt 5–6 évben a

lecserélt számítógépeket – illetve azokat a felhasználókat segítő alkalmazásokat, amelyeknek létezik nyílt kódú alternatívája is – beleszámítva közel 230 000 000 Ft (kétszázharminc millió) megtakarítást eredményezett3 a szabad szoftver és a nyílt forrás Szeged M. J Város Önkormányzata részére Szerveroldalon a szolgáltatások bonyolultsága miatt ilyen összehasonlítást eddig nem készítettünk. Fontos, hogy kiadási, illetve kár oldalon többlet nem keletkezett, a számítógépek javítását, az oktatást, a támogatást ugyanazok a kollégák végzik, akik eddig a fizetős szoftverekkel működő rendszerek esetén végezték ugyanezt. – Célszerűség az intézmény feladatainak szempontjából. Az önkormányzatok a településen lakó adófizetők pénzével gazdálkodnak Az egyik legfontosabb dolog, hogy a „gondos gazda” szerepével az adófizetők forintjait olyan fejlesztésekre fordítsa az önkormányzat, amelyeket a

település polgárai szívesen látnak. Jellemzően az informatikai fejlesztések nem látványosak, viszont nagyon sok pénzbe kerülnek Ezért fontosnak tartom, hogy azokért az informatikai fejlesztésekért, amelyek ingyenesen, vagy nagyon olcsón is kivitelezhetők, ne fizessünk „piaci” költségeket. – Árletörő hatású verseny a fejlesztésben és a továbbfejlesztésben. Ha speciális fejlesztésre van igény, egy nyílt kódú rendszernél a fejlesztést bárki elvégezheti, egy nyilvános pályázat alapján a speciális fejlesztések árát jelentősen le lehet törni, míg a zárt kódú alkalmazások fejlesztésénél a fejlesztő kizárólagos helyzetben van, bármilyen árat kérhet a 2 A Microsoft OEM szerződése szerint a szoftver más hardveren nem használható, tovább nem adható. Ennek jogszerűsége legalábbis vitatott, de betartása esetén valóban ismét megjelenik a beszerzési költség. 3 Ennyi pénzt lehetett másra költeni, például arra,

hogy az önkormányzatban a bejövő hívásokat automata helyett ember fogadja, aki az idős, az önkormányzati fellépést nem ismerő lakosok számára is megfelelő segítséget ad, a probléma ismertetése alapján jó helyre kapcsol. 2009. június 15 325 fejlesztésért. Az elmúlt időszakban jelentős mennyiségű olyan jogszabályváltozás történt, ami különösen a GVOP 431 pályázat keretében nyertes önkormányzatokat sújtotta, hiszen ezek jó része kiszolgáltatott helyzetbe4 került a korábbi fejlesztő által. A költségeket hosszabb távon tovább csökkenti a szerveroldalon használt szabad, nyílt kódú operációs rendszer, és az azokon futó szolgáltatások, valamint a speciálisan fejlesztett alkalmazások árletörési, és későbbi független továbbfejlesztési lehetősége5 , akár több önkormányzat összefogásával. – Egyszerű telepítés. Egyes gyakran használt zárt forrású, üzleti licencű termék (például OEM Windows XP)

esetében 1 licenc csak 1 konkrét gépre (jellemzően csak 1 alkalommal) telepíthető. Amennyiben a gép újratelepítésre vagy fődarabcserére szorul, külön procedúra az egyébként jogosan megvásárolt szoftver-licenc újratelepítése (aktiváltatás, telefonálgatás stb.) Tapasztalatunk szerint maga a telepítés is jóval kevesebb időt vesz igénybe a nyílt forrású, szabad szoftveres rendszereknél, mint a Microsoft termékek, például Windows XP esetében. – Jogkövető magatartás könnyebbsége. Az üzleti licencű, zárt forrású termékeket (OEM Microsoft termékek, például XP, Office) jegyenként és kódonként nyilván kell tartani, ez 600 db folyamatosan változó számítógép esetén nem lesz pontos. A jogszerűen feltelepített szoftverek esetében is elképzelhető nézetkülönbség a szoftver tulajdonosa és a használati jogot vásárolt felhasználó közt A nyílt forráskódú, szabad szoftverek esetén sem nyilvántartani, sem a

jogszerűségéről vitát nyitni nem kell. – Frissítés. Tapasztalataink szerint a nyílt kódú rendszerekhez folyamatosan elérhető frissítések tartoznak, amelyek szintén ingyenesen elérhetők A fizetős szoftvereknél ezek a frissítések nem feltétlenül gyakoriak, telepítésük sokszor körülményes, a nagyobb verzióugrások esetében gyakran nem is ingyenes. – Megbízhatóság. A széles körben elterjedt, és általunk használt szoftverek esetében a stabilitás és a megbízhatóság – tapasztalataink szerint – jóval meghaladja a Microsoft termékek ilyen tulajdonságait. 4 A zárt forrású, nem szabad szoftver terméken csak az eredeti fejlesztő tudja a változásokat átvezetni. Az árat ő diktálja 5 Amennyiben eredetileg a módosítani vagy továbbfejleszteni kívánt programok szabad vagy nyílt forrású licenc alatt vannak. 2009. június 15 326 – Áttekinthetőség, ellenőrizhetőség. Bár egy közigazgatási intézmény jellemzően nem

nézi és nem nyúl bele a forráskódba, megnyugtató az a tudat, hogy a forrást mindenki ismerheti, így nem lehetnek benne6 olyan szándékosan belefejlesztett vagy véletlenül benne maradt rutinok, amelyek a felhasználó által „nem kívánt” cselekményeket hajtanának végre, vagy engednék ilyenek lefutását. – Megoszthatóság és a költségek eloszthatósága. Előny a szabad és nyílt forrású szoftvereknél a zárt forrású, hagyományos üzleti licencekkel szemben a hozzáférhetőség, a forrás közzététele, amely alapján egy új fejlesztés, vagy egy régi módosításának költsége jelentősen letörhető a forráskód birtokában. A két dolog lévén használható az a megoldás, hogy több önkormányzat összefog a hasonló fejlesztés érdekében, és közösen finanszírozzák. A nyílt kódú fejlesztések esetén a költségek egyértelműen oszthatók, mivel nincs licenc-számhoz kötve a felhasználás – Elhagyható vírusvédelem. Az a

tapasztalat jelenleg, hogy a szabad és nyílt forráskódú rendszereken futó férgek és vírusok összehasonlíthatatlanul kisebb számban vannak jelen a Microsoft termékekre írt vírusokkal és férgekkel szemben. Így ezek terjedése, és az általuk okozott kár sem olyan mértékű, nem beszélve a vírusirtó szoftverek költségéről és a rendszerek vírusirtók általi terhelésének mértékéről.7 – „Tudás”. Mi azt tapasztaltuk, hogy sok esetben a nyílt kódú rendszerek több kényelmi lehetőséget rejtenek magukban. Életszerűbb problémák orvosolhatók velük egyszerűen, egyszerűbben. A kiegészítő szolgáltatásokat nem kell külön „vadászni”, nem kell költséges segédprogramokat telepíteni a kényelmes működés érdekében. Érvek a szabad és nyílt forráskódú rendszerek ellen – Inkompatibilitás. Szabad és nyílt forrású operációs rendszerek inkompatibilisek, még WINE, DosEMU stb megoldásokkal sem teljesen kompatibilisek

az elterjedt Microsoft operációs rendszerekkel A Kincstár és az egyéb központi szervek által a Hivatal számára kötelezővé tett szoftverek többsége, illetve a speciálisan használt szoftverek valamilyen Dos 6 Pontosabban, ha vannak, akkor – ha valaki nézi a forrást, és ilyesmit keres – felfedezhetőek, eltávolíthatóak. 7 Ez csökkenti a hardver költséget, késlelteti a hardver – felhasználás szempontjából történő – avulását. 2009. június 15 327 vagy Microsoft Windows platformra készülnek. Ezek futtatása nyílt forráskódú alapokon meglehetősen bonyolult és olykor kockázatos, főleg hálózatos alkalmazások esetén.8 Az OpenOffice.org alkalmazáscsomag a legtöbb esetben beolvassa a Microsoft Office-ban készített dokumentumokat, táblákat, prezentációkat, azonban jó néhány esetben előfordul, hogy a formázás szétesik, a szöveges dokumentumba illesztett táblázatok cellái nem olvashatók, a képek nem akkorák, és nem

oda kerülnek, ahova a készítője szánta. Ezek a hibák jellemzően a Microsoft termékek közt is problémát okozhatnak9 , hiszen jórészt szerkesztési hibából adódnak, de az OpenOffice esetében valóban több eltérés mutatkozik meg, mint két Microsoft termék közt. Sajnos a felhasználók nincsenek kiképezve a megfelelő szerkesztésre10 , és a széteső dokumentumok egyszerű és gyors helyreállítására. – Szándékosan nem sorolom ide a terméktámogatás hiányát. Egyrészt azért, mert a fizetős szoftverek esetében sem vagyok megelégedve a terméktámogatással, másrészt az interneten jellemzően hozzáférhetők az egyes problémák kezelése és a hibák megoldásai. Terméktámogatás az általunk használt szoftverek esetén Szerencsére a legtöbbet használt alkalmazások esetében mind a dokumentáció mind a magyarítás megfelelőnek, elegendőnek bizonyult (ahhoz képest mindenképpen, hogy ezek költség nélkül hozzáférhetők).

Tapasztalataink szerint a legtöbb esetben a felmerülő problémákra már létezik megoldás, ezek 8 Nem ritkán itt is a nem megfelelő programozás, rossz programozási stílus teszi nehézzé a más platformon történő futtatást. Elég gyakori példa, hogy a Clipper programozók az állomány elejére pozicionálás helyett bezárás nélkül újra megnyitják az állományt, ami talán gyorsabb megoldás, de valójában – ha az operációs rendszer helyesen kezeli az állományokat – hibás, hiszen egy helyett több állomány lesz nyitva még akkor is, ha csak egyet használunk, ez pedig gondot okoz, hiszen helyesen minden nyitott állományt be kell zárni (vagy program vége esetén az operációs rendszer ezt erőszakkal teszi meg, ami bizony akár okozhat adatkonzisztencia problémát. 9 A Microsoft Office esetén is gond, ha nincs telepítve a kívánt betűtípus, vagy ha más a nyomtató, mert a betű, illetve a nyomtató miatti újratördelés megváltoztatja a

dokumentumot, és ha nem megfelelő a szerkesztése (például szóköz, tabulátor, új sor a formázásban) akkor a kinézet megváltozik, a dokumentum szétesik. 10 Az oktatás nem megfelelőségének eredménye – elvek és alaptechnológiák helyett a szoftverkezelés oktatása – tapasztalataink szerint mind a közigazgatásban, mind a magánszektorban visszatérő probléma. 2009. június 15 328 különféle internetes fórumokon hozzáférhetők. Természetesen mind az oktatás, mind a terméktámogatás, mind egyéb szolgáltatások mindenképpen nagyon hasznosak lennének a hivatal számára. Azt is vizsgálni kell azonban, hogy ezek mekkora többletköltséget jelentenek Ismerve a piaci szereplők árait, előfordul, hogy maga a támogatás vagy az oktatás, nem beszélve a dokumentációk elkészítéséről, jelentősebb költséget eredményeznek, mint ha támogatott szoftvert vásárolnánk. Sajnos meg kell jegyeznem, hogy a fizetős termékek támogatásánál is

csak olyan esetben kértem a helpdesk segítségét, amelyben ők maguk sem tudtak kielégítő válasszal szolgálni ( „Really? I’ve never seen this before.”) Azt gondolom, hogy ebből a szempontból mindegy, hogy mire nincs igazi terméktámogatás. Segítség lenne egy tudásbázis, ha olcsóbb, mint amennyi költségbe a támogatott szoftverek kerülnek éves szinten, akár a kormányzat, akár az önkormányzatok számára. A tudásbázist önszorgalomból is építhetővé kellene tenni valamilyen wiki – például dokuwiki – formában. Bevált gyakorlatokkal rendelkező intézményeket/hivatalokat fel lehetne kérni a tudásközpont tudásbázisának mélyítésére. Bár nem jellemző, vannak jó tapasztalataink – különösen a fiatalabb korosztály felhasználói között – az online tudásbázis önálló használatában. Ma nem támogatott a szabad és nyílt forráskódú megoldások használata a közigazgatásban Az állam ma nem támogatja a szabad és

nyílt forráskódú megoldások használatát a közigazgatásban, pedig ezek támogatása az állam részéről szükséges és hasznos. A közigazgatásban jellemzően két probléma gátolja a szabad és nyílt forrású alkalmazások elterjedését: 1. A szabad és nyílt forrású szoftverek tudomásulvételének hiánya A központi szervek által kötelezően előírt alkalmazások platformfüggősége (például IMI, K11, KSZNY, Önkadó11 stb.) 11 A tanulmány készítése közben derült ki, hogy az Önkadó új verziója a Wonkado gyakorlatilag nem lesz linuxos gépen futtatható, mivel adatbáziskezelőnek MS SQL-t (Microsoft termék, csak Windows alatt működik) használ, és a felhasználói oldalon levő üzleti logika, valamint a megjelenés pedig a dotnet (Microsoft termék, kifejezetten a Windows fejlesztésekhez) olyan verziójával működik együtt, amelyet jelenleg a MONO (szabad szoftveres csomag, a dotnet alapú programok nem Windows alatti futtatásához) nem

tud helyettesíteni. 2009. június 15 329 Ha ezeket az alkalmazásokat lehetne webes, vagy más módon platformfüggetlenné tenni, vagy például az OpenOffice, illetve Firefox szoftverhez hasonlóan több platformon futtathatóra fejleszteni, illetve léteznének olyan központi előírások, esetleg szabványosítások, amelyek lehetővé tennék a saját fejlesztésű, vagy saját elképzelés alapján fejlesztetett programok és a központi programok közötti kommunikációt (például XML export), az nagyban hozzájárulna a nyílt kódú alkalmazások terjedéséhez. 2. Ma az ODF nem elfogadott, pedig előállítása, kezelése olcsó, és gyakorlatilag operációs rendszertől független Nagy segítség lenne az OpenDocumentFormat dokumentumformátum elfogadása központi szinten is. A megoldás nem az, hogy ezentúl egycsapásra a Microsoft termékek felhasználásával készített dokumentumokat, illetve az ODF-től eltérő formátumú dokumentumokat ne fogadják el,

hanem az, hogy a hivatalok számára tegyék lehetővé a dokumentumok, pályázati űrlapok stb. ODF formátumban történő hozzáférését (ez jellemzően csak annyi többlet energiaráfordítás, hogy a dokumentum készítője elmenti másik formátumban is), illetve az ugyanilyen formátumú visszaküldést, levelezést, kommunikációt. Javaslatom szerint tegyék lehetővé – akár jogszabályi szinten –, hogy a hivatalok használhassák a külső „ügyleteik” lebonyolítására az ODF formátumot.12 Ez semmilyen külső magánszemély, cég, hivatal számára nem jelentene többletköltséget, mivel a formátumot használó alkalmazások közül sok szabadon hozzáférhető. Az ODF előnyeiről és hátrányairól Előnyök: – Az ODF egy szabvány. Ahol támogatják, ott egyforma az értelmezése – Használatával platformfüggetlenül készíthetünk irodai dokumentumokat. 12 Van egy máig érvényes IHM rendelet (12/2005. (X 27)), amely alapján az

intézmények, önkormányzatok akár ma is használhatnák, befogadhatnák az ODF formátumú anyagokat, de ma nem ez a gyakorlat, és a megszokás miatti tehetetlenségi erő, valamint a vélt vagy valós technikai problémák nem is engedik általánosan elfogadottá válni az ODF kezelését. 2009. június 15 330 – Az ODF szabvány, ezért a szerveralkalmazások, back-office alkalmazások számára egyszerű export-import felületeket kialakítani. Az összes iratminta kitölthetővé tehető, a táblázatban foglalt adatok beolvashatók. Az iratminták változását egyszerű szövegszerkesztővel alakítani lehet, nem kell a back-office alkalmazást átírni emiatt Az egyszerűbb lekérdezések és kényelmesebb platform miatt az adatok exportálhatók táblázat vagy szöveges dokumentum formában stb. Hátrányok (jelenleg): – A közigazgatásban kevesen használják a formátumot, és nem hajlandók váltani, akkor sem, ha ez ingyenesen megtehető. – Nem lehet

beolvasni a zárt kódú irodai alkalmazásokkal.13 – Nem támogatja magyar függvények használatát15 a táblázatkezelőben16 . A mi szabad és nyílt forrású szoftvereink kiválasztása A szabad, nyílt forrású programok, megoldások kiválasztásánál a hivatalban az a bevált gyakorlat, hogy különböző fórumokon tájékozódunk az elérhető disztribúciókról, és azok használhatóságáról. A beváltnak tűnő szoftvereket kipróbáljuk, teszteljük, akár szélesebb körben, a felhasználók bevonásával is. Azokat a szoftvereket, amelyek a teszteken sikeresnek bizonyulnak, széleskörűen bevezetjük A támogatást szintén tájékozódást követően vesszük igénybe – amennyiben ez szükséges, és ár/érték arányban jónak ítéljük meg. A már említett központi tudásbázis létrehozása mindenképpen hasznos lenne bármely szoftver (szabad vagy fizetős) vagy támogatás igénybevétele esetén is. 13 Azóta megjelent a Microsoft Office

javító csomagja, mely telepítése után a gyártó állítása szerint az Office helyesen kezeli az ODF 1.0 formátumot14 (ez az ISO szabványosított formátum). 15 Szegeden kevesen használnak táblázatkezelőt, és még kevesebben olyan szinten, hogy függvényeket használnának. Ha kérdés van, akkor legtöbb esetben azonnal tudjuk mondani az angol párját, és van egy hosszú lista, ami a függvények fordítását tartalmazza. 16 A román-magyar kormánytalálkozóra biztosított gépeken (ott Microsoft Office volt) sem az angol, sem a román függvényeket nem fogadta be a magyar Excel. A Microsoft támogatás szerint olyan nyelvűt kell venni, amilyet használni szeretnénk, vagy multilanguage változatot, mivel a nyelv átállítására nincs mód. 2009. június 15 331 A tudásbázis létrehozásakor, építésekor figyelembe kellene venni, hogy a hivatali felhasználók túlnyomó többsége vagy autodidakta módon, vagy a kollégáktól ellesve tanulja/tanulta

meg a rendszerek használatát. Nyilván ez is eredményezi a helytelenül szerkesztett dokumentumokat, amelyek aztán más környezetbe történő beolvasásukat követően szétesnek. A terméktámogatást, a fizetős szoftverek támogatási lehetőségét semmiképpen nem veszik igénybe. A fizetős programok szakszerű használata érdekében ugyanúgy szükséges (lenne) tehát a végfelhasználói oktatás, ahogyan a nyílt kódú alkalmazások esetén is. Meggyőződésem, hogy az informatikában járatlan személyek számára teljesen mindegy, hogy melyik rendszert tanítjuk meg, ha így is, úgy is fizetni kell az oktatásért. Javaslataink17 Ahhoz, hogy a szabad szoftver, a nyílt forráskód terjedjen, mindenképpen kormányzati szintről18 várnánk olyan javaslatokat, ajánlásokat, jogszabályokat, tetteket, amelyek lehetővé teszik a speciális programok platformfüggetlenné tételét, az irodai dokumentumok szabványosítását. 1. Első lépésként – a

legegyszerűbb és legolcsóbb megoldásként – lehetővé kellene tenni az állami és közigazgatási szervek által közzétett dokumentumok ODF formátumban történő hozzáférhetőségét. 2. Ezt követően az állami és közigazgatási szervek számára előírhatnák – akár jogszabály formájában is –, hogy a hivatalok közötti és a hivatalokkal történő kommunikáció szabványos módon történjen, preferálva az ODF19 formátumot (ehhez az állami és közigazgatási szerveknél a megfelelő ingyenes szoftverek telepítésére szükség lenne). 3. Harmadik lépésként a kötelező adatszolgáltató és egyéb kommunikációs szoftverek átalakítása történhetne vagy szabványos export-import for17 Ezek a szegedi javaslatok. A közigazgatás erősen centralizált, talán a legerősebben informatikai szempontból. A központi döntések, szoftverfejlesztések, kötelezően használandóvá tett megoldások erősen befolyásolják – kisebb önkormányzat

esetén teljesen meghatározzák – az informatika milyenségét. Így az alulról induló változás csak korlátozottan tud elterjedni, s bármikor elhalhat. 19 Van egy máig érvényes IHM rendelet, amely alapján akár az intézmények, önkormányzatok ma is használhatnák, befogadhatnák az ODF formátumú anyagokat, de ma nem ez a gyakorlat, és a megszokás miatti tehetetlenségi erő, valamint a vélt vagy valós technikai problémák nem is engedik általánosan elfogadottá válni az ODF kezelését. 18 2009. június 15 332 mátumokkal (például XML20 ), vagy platformfüggetlen (például webes) szoftverek bevezetésével. 4. Mindenképpen hasznos lenne a nyílt forráskódú rendszerekhez a tudásbázis kialakítása21 , források hozzárendelése22 20 Az XML valóban szabvány, de önmagában nem garantálja a platformfüggetlenséget, sőt, még a kezelhetőséget sem. Csak akkor segítség, ha részletes publikált és betartott leírás is tartozik az XML

export és import funkciókhoz. 21 Ennek bizonyos mértékig célzottnak kellene lenni, hogy a közigazgatásban felmerülő problémákat, megoldásokat tartalmazzák. Az általános problémák megoldásának csak hivatkozásait érdemes beletenni. 22 Szabad, nyílt forráskódú szoftvert nem érdemes venni, maximum szolgáltatást hozzá, ezt azonban az eszközbeszerzésre adott források nem teszik lehetővé. 2009. június 15 F függelék A Microsoft megvalósított ODF támogatása az Office 2007-ben Milyen az, amikor a Microsoft kompatibilis egy rivális eszközzel ? A Microsoft – amint az a rendszeresen induló trösztellenes eljárásokból is kiderül – erősen ellenséges magatartást tanúsít a riválisaival szemben. Nem volt ez máshogy az OpenOffice.org szabványos fájlformátumával, az ODF-fel sem, a szabványosítás után évekig megtagadta a Microsoft Office felhasználóktól az ODF formátumú dokumentumok kezelését. De a piaci realitás az a nagy

cégekre is hat. Az ODF mellett megmutatkozó támogatás mostanra olyan széleskörű lett1 , hogy a Microsoft is beadta a derekát, és csatlakozott az eddigi hat nagyobb irodai rendszerhez, és támogatást ígért az ODF fájlokhoz.2 A hír megjelenése után természetesen sokan kipróbálták az új kiegészítőt, és az ítélet lesújtó. 1 2 http://www.odfallianceorg/memberlistphp http://www.microsoftcom/presspass/features/2009/Apr09/ 04−2800Office2007SP2QA.mspx Érdemes megjegyezni, hogy ezzel a frissítéssel a Microsoft Office 2007 lett az első olyan irodai rendszer, amely támogatja a Microsoft OOXML szabványt. 333 334 Rob Weir elemzése Rob Weir3 kipróbálta mind a hét ODF-et támogató alkalmazást és kiegészítőt4 , és arra az eredményre jutott, hogy míg nem minden alkalmazás kezeli tökéletesen az ODF-et, egy olyan van, ami csakis saját magával kompatibilis, és ez a Microsoft Office 2007. Az egyik legelső és legsúlyosabb probléma, hogy egy

táblázatot elmentve az Office 2007 nem abba a tárolóba menti a formulákat, mint ahová az összes többi alkalmazás, hanem egy általuk kitaláltba. Ez azzal jár, hogy az Office 2007-ben elmentett ODF Chart fájl csak az Office 2007-tel lesz megnyitható, ezáltal kötve a felhasználót a Microsoft alkalmazásához. A Microsoft első védekezése szerint az ODF 1.1 szabvány nem elég precíz, és bár a cég fejlesztői mindent megtettek a kompatibilitásért, ez nem sikerülhetett nekik. Rob Weir egy következő írásában5 ennek az állításnak a cáfolatát közölte. Az ODF 11 szabvány világosan leírja, hogy a formulákban a táblázatmezők címeit [ és ] jelek közé kell tenni (813 fejezet a szabványban). A különböző ODF alkalmazások a következőképpen tárolják a címeket: Symphony 1.3 =[E12]+[C13]-[D13] Microsoft/CleverAge 3.0 =[E12]+[C13]-[D13] Google Spreadsheets. =[E12]+[C13]-[D13] OpenOffice 3.01 =[E12]+[C13]-[D13] Sun Plugin 3.0 =[E12]+[C13]-[D13]

Excel 2007 SP2. =E12+C13-D13 Látható, hogy pontosan egy fejlesztőcsapatnak okozott problémát a megértés. Hasonló probléma van a jelszóvédelemmel is, amit a Microsoft szerint nem ismer az ODF szabvány, pedig a 17.3 fejezetben leírja, és az összes többi alkalmazás kezeli is. Az ilyen sok tévedésre Rob Weir csak egy magyarázatot tud: „I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2’s poor ODF 3 Az IBM fő ODF szakembere, és a cég delegáltja az OASIS ODF-fel foglalkozó munkacsoportjaiban. 4 http://www.robweircom/blog/2009/05/update−on−odf−spreadsheethtml 5 http://www.robweircom/blog/2009/05/follow−up−on−excel−2007−sp2s− −odf.html 2009. június 15 335 support boggles the mind and leads me to further uncharitable thoughts. So I must stop here.” „Úgy tanítottak, hogy sose tételezzek fel rosszindulatot ott, ahol a tudatlanság egyszerűbb

magyarázat. De a tudatlanságnak olyan magas foka szükséges az SP2 szegényes ODF támogatásának megmagyarázásához, hogy megáll az eszem, és nagyon negatív gondolataim támadnak.” Reméljük, a Microsoft hamarosan kijavítja ezeket a hibákat. Addig pedig nem szabad használni az ODF verziójukat, mert adatvesztéssel jár. 2009. június 15 336 2009. június 15 G függelék A szabad szoftverek használatának, ismertségének felmérése 1. Ismer-e ön olyan szoftvereket, amelyekért nem kell a használati jog ellentételezéseként díjat fizetni? – Igen – Nem 2. Használ-e ilyen szoftvert, ha igen, hol? – Nem használok – Munkahely – Otthon 3. Ismer-e az Internet Explorertől különböző böngészőt? – Igen, mégpedig • • • • • Mozilla Firefox Opera Google Chrome Konqueror Egyéb, éspedig . – Nem 4. Használ-e az Internet Explorertől különböző böngészőt? 337 338 – Igen, mégpedig • • • • • Mozilla Firefox

Opera Google Chrome Konqueror Egyéb, éspedig . – Nem 5. Hallott-e már a Microsoft Windows termékcsaládján kívüli operációs rendszerről? Ha igen, melyikről? (Többet is megjelölhet.) – Knoppix – Ubuntu Linux – Red Hat Linux – Debian Linux – SuSe Linux – UHU Linux – Frugalware – Black Panther OS – Mac OS X – Solaris – HP-UX – AIX (IBM) – OS9 – OS400 – MS DOS – IBM DOS – FreeDos – QNX – OS2 – Egyéb, éspedig . 6. Használt-e már a Microsoft Windows termékcsaládján kívüli operációs rendszert? Ha igen, melyiket? (Többet is megjelölhet.) 2009. június 15 339 – Igen, mégpedig • • • • • • • • • • • • • • • • • • • • Knoppix Ubuntu Linux Red Hat Linux Debian Linux SuSe Linux UHU Linux Frugalware Black Panther OS Mac OS X Solaris HP-UX AIX (IBM) OS9 OS400 MS DOS IBM DOS FreeDos QNX OS2 Egyéb, éspedig . – Nem 7. Vannak-e ismerősei, akik szabad szoftvert használnak? – Nincs

ilyen ismerősöm – Van ismerősöm, aki már próbált szabad szoftvert – Van ismerősöm, aki rendszeresen használ szabad szoftvert 8. Melyek azok a tevékenységek, amelyeket leggyakrabban végez a számítógépen? (Több válasz is adható) – Szövegszerkesztés – Táblázatkezelés – Webböngészés – Iktatórendszer használata 2009. június 15 340 – Könyvelőrendszer használata – Levelezőrendszer használata – Játék – Instant messaging szolgáltatás (Google Talk, MSN, ICQ, Skype stb. használata) – Fórumok olvasása – Hírportálok olvasása – Online telefonálás (Skype, Google Talk stb.) – Egyéb, éspedig . 9. Amennyiben tudja, kérjük adja meg az Ön által leggyakrabban használt szoftverek nevét (csoportonként egyet adjon meg): – szövegszerkesztő (például Microsoft Word, OpenOffice, MagyarOffice, EuroOffice) . – táblázatkezelő (például Microsoft Excel, OpenOffice, OxygenOffice, StarOffice, IBM Lotus Symphony,

MagyarOffice, EuroOffice) . – webböngésző (például Internet Explorer, Mozilla Firefox) . – iktatórendszer . – könyvelőrendszer . – levelezőrendszer (például Google Mail, Microsoft Outlook, Mozilla Thunderbird, Evolution, Lotus Notes, Novell Groupwise) . – Egyéb, éspedig . 10. Az alábbi tulajdonságok Ön szerint milyen mértékben jellemzik a szabad szoftvereket? (0 = egyáltalán nem, 1 = kicsit, 2 = közepesen, 3 = nagyon) – gyors – biztonságos (kevés kritikus biztonsági rést tartalmaz) 2009. június 15 341 – könnyű az alkalmazásokat megtalálni és kezelni – felhasználóbarát – idegen (nem hasonlít más, általam ismert alkalmazásokra) – testreszabható (saját felhasználói igényekhez alakítható) – időtálló (nem változik túl gyakran) – alap feladatokra (például szövegszerkesztés, internet) alkalmas – bonyolult feladatokra (például parancssori irányítás) alkalmas – a beszerzés szempontjából olcsó –

drága fenntartani – könnyen naprakésszé tehető – magyar nyelvű 11. Az alábbi tulajdonságok Ön szerint milyen mértékben jellemzik a Microsoft, vagy más kereskedelmi gyártó szoftvereit? (0 = egyáltalán nem, 1 = kicsit, 2 = közepesen, 3 = nagyon) – gyors – biztonságos (kevés kritikus biztonsági rést tartalmaz) – könnyű az alkalmazásokat megtalálni és kezelni – felhasználóbarát – idegen (nem hasonlít más, általam ismert alkalmazásokra) – testreszabható (saját felhasználói igényekhez alakítható) – időtálló (nem változik túl gyakran) – alap feladatokra (például szövegszerkesztés, internet) alkalmas – bonyolult feladatokra (például parancssori irányítás) alkalmas – a beszerzés szempontjából olcsó – drága fenntartani – könnyen naprakésszé tehető – magyar nyelvű 12. Hány órát tölt egy munkanapon átlagosan a számítógép előtt? – 2-nél kevesebbet – 2–4 között 2009. június 15 342

– 4–6 között – 6–8 között – 8-nál többet 13. Tudja, miként lehet saját háttérképet beállítani? – Igen – Igen, mert a kérdés alapján kíváncsi lettem, és megnéztem – Nem – Mi az a háttérkép? 14. Milyen módon informálódik a hírekről? (Több választ is megjelölhet) – neten, hírportálon – újságban – televízión, rádión – RSS feed alapján 15. A szervezet, ahol dolgozik, tudomása szerint hány munkavállalót foglalkoztat, és ezek hány százaléka végez irodai (számítógéphez kötött) munkát? . 16. A szervezetnél, ahol dolgozik, tudomása szerint hány gépből áll a hálózat? (Nagyságrendileg becsülje meg) . 17. A szervezetnél, ahol dolgozik, tudomása szerint éves szinten mekkora összeget költenek szoftvervásárlásra? (Nagyságrendileg becsülje meg.) . 18. A szervezetnél, ahol dolgozik, tudomása szerint éves szinten mekkora összeget költenek szoftverfejlesztésre? (Nagyságrendileg becsülje meg.) .

19. A szervezetnél, ahol dolgozik, tudomása szerint hány informatikust foglalkoztatnak? – Nincs informatikus munkavállaló – 1 2009. június 15 343 – 2 – 3–5 – 6–10 – 10-nél több – 30-nál több 20. A szervezetnél, ahol dolgozik, tudomása szerint hány informatikával foglalkozó külsős cég szolgáltatását veszik igénybe? . 21. Milyen módon intézik az informatikai eszközök beszerzését? – Központosított közbeszerzés szerint – Egyéb közbeszerzés szerint – Versenyajánlatok alapján – Van saját, leszerződött beszállítónk – Egyéb, éspedig . 22. A szervezetnél, ahol dolgozik, tudomása szerint mely programokat kötelező használni, és azok milyen funkcionalitást látnak el? . 23. A szervezetnél, ahol dolgozik, egy-egy program kötelező használatának mi az oka? (Jogszabályi előírás, banki előírás, gyakorlati okok stb.) Amennyiben tudja esetleg, hogy melyik szoftver használatát milyen formában teszik

kötelezővé, pár mondatban fejtse ki. . A A A A kitöltés dátuma: kitöltő neve: kitöltő beosztása: kérdező neve: 2009. június 15 344 2009. június 15 H függelék Szabad szoftverekhez kapcsolódó adójogi kérdések Számviteli törvény vonatkozásában 1. Mi a különbség a szerzői vagyoni jogi jogosultság és a számviteli törvény által használt vagyoni értékű jog között a hivatal álláspontja szerint? (Felmerült-e a jogalkotóban, hogy a közteherre vonatkozó szabályok és a szerzői jogi törvény között ellentmondás fedezhető fel, utóbbi értelmében ugyanis a „tulajdonjog” a szoftver vonatkozásában nem értelmezhető fogalom?) 2. Igaz-e, hogy a vagyoni jogi jogosultság a „szellemi termék” kategóriába sorolható, a felhasználási jog viszont vagyoni értékű jognak minősül? (Felmerült-e esetleg az, hogy a használati jog és a tulajdonjog közötti különbség valójában a használati jog és a szerzői jogi

törvény által is ismert vagyoni jogi jogosultság különbsége?) 3. A számviteli szabályok alkalmazásakor mi a megítélése a szoftvernek, ha – saját fejlesztés? – a felhasználásért licencdíjat kérnek? – a szoftvert szabad szoftverként – ennek megfelelő licenccel – teszik elérhetővé? A kérdéssel kapcsolatosan a „szabad szoftver” fogalmának magyarázatához az alábbi rendelkezési jogok összességét kell érteni: 345 346 – A program – bármilyen céllal történő – futtatásának joga. – A program működésének tanulmányozásához való jog, valamint jog arra, hogy a programot a szükségleteikhez igazíthassák. Ennek előfeltétele a forráskód elérhetősége. – Másolatok terjesztésének joga, a felebarátok megsegítése érdekében. – A program tökéletesítésének, módosításának joga, valamint ezen javított kiadás – az egész közösség javát szolgálandó – közzétételének joga. Ennek előfeltétele a

forráskód elérhetősége 4. Lehet-e a szabad szoftvert kereskedelmi áruként kezelni? 5. Mi a bekerülési érték, ha egy már létező szoftverhez – amely megfelelő felhasználási engedély birtokában (licenc) az internetről került letöltésre – hozzáfejlesztünk saját (belső erőforrási) fejlesztésként, illetve „külsős” (nem alkalmazotti státuszú) fejlesztő igénybevételével? 6. A szabad szoftvert melyik mérlegsor alá kell besorolni? 7. Milyen analógiával kezeltetné a Minisztérium azt a problémát, hogy a szerzői alkotások egy részén nem lehet tulajdonjogot szerezni, csak felhasználási jogot? Ez esetben a könyvekbe milyen módon kell felvenni? 8. Az ilyen művekhez hozzákapcsolódó jogok kimutatása a könyvekben hogyan történik meg? 9. Ha értékesítésre kerül egy hozzátartozó jog, akkor annak mi lesz a költségvonzata? 10. Ha nem lehet áru, és értékesítjük, akkor mi lesz az ellenoldala költség szempontjából? Az

általános forgalmi adó vonatkozásában 1. A szabad szoftver mikor minősülhet termékként és mikor szolgáltatásként? (Figyelemmel arra, hogy a szoftver esetén a különleges sui generis oltalom miatt nem csak a felhasználási engedély megadásáról, hanem a vagyoni jogosultságok átadásáról is szó lehet.) 2. Ha nem termék, mert nincs hozzá kapcsolható tulajdonjog, akkor a szolgáltatásként besorolás nem mond ellen a számviteli tv szellemi termék kategóriájának? 2009. június 15 347 3. Ha szolgáltatás és „eladásra kerül”, akkor ugyanazt többször milyen módon lehet szolgáltatni? Egyetért-e a jogalkotó azzal a teóriával, mely szerint csak terméket lehet többszörösen szolgáltatni, szoftver esetében azonban a tulajdonjog szerzése – a fentebb vázolt okokból – értelmezhetetlen. Ha viszont nem minősül terméknek a szoftver, akkor „ugyanazt” a szolgáltatást nem lehet ismételten nyújtani, csak „ugyanolyat”? 4. Lehet-e

a hozzá kapcsolódó jogok átadása az általános forgalmi adóról szóló 1992. évi LXXIV törvény (a továbbiakban: régi ÁFA tv) 9 §, (3) a) és c) pontja szerinti ügylet, miként minősül ez az általános forgalmi adóról szóló 2007. évi CXXVII törvény (a továbbiakban: új ÁFA tv) alapján? 5. Alkalmazható-e – és ha igen, milyen feltételek esetén – a jogok átadására a régi ÁFA tv 13 §, 35 pontja, illetve az új ÁFA tv 11 §, (3) bekezdés? 6. Ha a vagyoni jogi jogosult a szabad szoftverre vonatkozó felhasználási jogot annak érdekében engedi át ingyenesen, hogy a későbbiek során ennek kapcsán szolgáltatást (például üzemeltetés, tanácsadás, szakértés) nyújtson, a szoftver felhasználási jogának ingyenes átruházása gazdasági körön belüli vagy kívüli tevékenységnek minősül-e az ÁFA tv. szabályai szerint? És ha igen, mi okból kifolyólag került ez így meghatározásra? Társasági adótörvény vonatkozásában

1. Minősülhet-e szolgáltatásnak a szabad szoftver? Ha igen, akkor a bekerülési értéke költség és nem aktiválandó szellemi termék? Általánosságban 1. A szabad szoftverek fejlesztésének, illetve a szabad szoftverekre vonatkozó felhasználási jogok engedélyezése vonatkozásában tervezi-e a jogalkotó a szabályozás újragondolását? 2. Mely adójogi rendelkezések vonatkoznak arra az esetre, mikor egy cég a szabad szoftveres közösségre támaszkodva kezd szabad szoftveres fejlesztést? Változtat-e ezen a megítélésen, ha a közösség tagjai különféle állampolgárságú személyek? (Jelen esetben feltételezzük azt, hogy a 2009. június 15 348 közösség tagjai a fejlesztésért pénzbeli vagy más juttatásbeli ellentételezést nem kapnak.) 3. Mely adójogi rendelkezések vonatkoznak arra az esetre, ha magánszemély készít egy szabad szoftvert, majd ezt egy cég tovább folytatja, de az első ezzel kapcsolatban keletkező bevétel (például

szakértői munkából) több éves fejlesztési munka után jelentkezik? 4. Mely adójogi rendelkezések vonatkoznak arra az esetre, mikor a cég által vállalt valamely feladatát megfelelően teljesítésének szükségszerű velejárója, hogy egy szabad szoftvert módosítson/kiegészítsen? (Például az ügyfele egy integrált biztonsági rendszert kér (kamerák, kapuk, kártyák, tűzfalak stb.), és ebben felhasználásra kerül egy GPL 2x licencű szoftver, melybe az ennek a célnak megfelelő működés érdekében 200 embernap munka kerül belefejlesztésre.) 5. Van-e valamilyen adójogi feltétele vagy korlátja annak, hogy egy cég által vezetett szabad szoftver fejlesztéshez harmadik személy ingyenesen kódot/kódrészletet adjon? 6. Ellenőrzi-e – és milyen jogcímen – az APEH a szoftvernyilvántartásokat? Amennyiben igen, a cég által használt szabad szoftvereket, illetve annak egyes változatait, kiegészítéseit stb. milyen formában kötelező

nyilvántartani? 7. Milyen adójogi vonatkozásai vannak annak az esetnek, ha egy szabad szoftver fejlesztése a cég számára sikertelenül fejeződik be? A cél – amely miatt a cég úgy dönt, hogy vállalja a fejlesztést – meghiúsul. A fejlesztésben a cég a továbbiakban nem kíván részt venni. A kód nem készül el, viszont a félkész kódot a közösség – vagy más cég – elvileg bármikor folytathatja. 8. Milyen módon lehet kivezetni a könyvekből a szoftvert? Van-e különbség ehhez képest a szabad szoftver kivezetésénél? 9. Ha egy cég nem saját részre, hanem megrendelésre fejlesztet szabad szoftvert, akkor a fejlesztés költsége alvállalkozói tevékenységnek, vagy igénybevett szolgáltatásnak minősül? 2009. március 24 2009. június 15 I függelék Az APEH hivatalos válasza 349 350 Adó- és Pénzügyi Ellenőrzési Hivatal Elnök Iktatószám: Ügyiratszám: Tárgy: 2278802023/2009. szoftverekhez kapcsolódó adójogi

kérdések Bódi Gábor, Infokommunikációért és E-közigazgatásért Felelős Szakállamtitkár részére MINISZTERELNÖKI HIVATAL Budapest Szilágyi Erzsébet fasor 11/b. 1024 Tisztelt Szakállamtitkár Úr! Tárgybani témában írt levelére a következők szerint tájékoztatom. I. A szoftverek számviteli elszámolásához kapcsolódóan az alábbiakra kell figyelemmel lenni. A számvitelről szóló 2000. évi C törvény (a továbbiakban: Szt) 23 § (4) bekezdése szerint az eszközöket rendeltetésük, használatuk alapján kell a befektetett eszközök vagy a forgóeszközök közé sorolni. Befektetett eszközként a vállalkozó tevékenységét, működését tartósan, legalább egy éven túl szolgáló eszközöket kell kimutatni. A befektetett eszközök közé tartoznak többek között az immateriális javak, melyek körében külön kategóriát képeznek a vagyoni értékű jogok és a szellemi termékek. Az Szt. 25 § (6) bekezdése értelmében az

immateriális javak között vagyoni értékű jogként kell kimutatni – többek között – a szellemi termékek felhasználási jogát. Szellemi terméknek minősülnek az Szt. 25 § (7) bekezdése szerint a szerzői jogvédelemben részesülő szoftver termékek. A szoftvereknek az eszközök közötti kimutatását lényegesen befolyásolja az, hogy a szoftver tulajdonjogát veszi-e meg a gazdálkodó vagy csak a használati jogát. 1054 Budapest, Széchenyi u. 2 Kérjük, válaszlevelében szíveskedjék iktatószámunkra hivatkozni. 2009. június 15 351 2 A szoftvereket jellemzően akkor indokolt a szellemi termékek között állományba venni, amikor a szoftver tulajdonjogát szerzi meg a vállalkozó (például a szoftver-terméket az ő megrendelésére, kizárólagos használatára állították elő, készítették el), és ez legalább egy éven túl szolgálja a tevékenységet, a működést. Saját vállalkozásban előállított, fejlesztett szoftver esetén

a szellemi termék bekerülési értéke az előállítás közvetlen önköltsége. Amennyiben pedig a szoftverfejlesztés megfelel az Szt. 3 § (4) bekezdés 4 pontja szerinti kísérleti fejlesztés követelményeinek, és a szoftverfejlesztés költségei a jövőbeni hasznosításkor az árbevételben vagy egyéb módon megtérülnek, akkor a szoftverfejlesztés költségei a kísérleti fejlesztés aktivált értékeként is állományba vehetőek az immateriális javak között. A gyakorlatban általában a szoftver felhasználási jogát veszik meg a gazdálkodók, ebben az esetben – az Szt. egyéb előírásaira is figyelemmel – a felhasználási jognak a vagyoni értékű jogok között történő számbavétele indokolt. A szerzői jogról szóló 1999 évi LXXVI. törvény szerinti, a gazdálkodók által megszerzett vagyoni jogokat az Szt hivatkozott rendelkezésére tekintettel kell besorolni. Az Szt. 80 § (2) bekezdése alapján a vállalkozónak – döntése

alapján – lehetősége van arra is, hogy a 100 ezer forint egyedi beszerzési, előállítási érték alatti vagyoni értékű jogok, szellemi termékek, tárgyi eszközök bekerülési értékét a használatbavételkor értékcsökkenési leírásként egy összegben elszámolja (így a bekerülési érték „azonnal” költségként jelentkezik). A szoftverek kereskedelmi áruként (készletként) történő kezelése az Szt. 28 § (2)-(3) bekezdéseiben foglaltak teljesülése esetén törtéhet. A hivatkozott jogszabályhelyek értelmében – többek között – azok az eszközök minősülnek készletnek, amelyeket a rendszeres üzletmenet keretében értékesítési céllal szereztek be, és azok a beszerzés és az értékesítés között változatlan állapotban maradnak; amelyek az értékesítést megelőzően a termelés, a feldolgozás valamely fázisában vannak, vagy már feldolgozott, elkészült állapotban értékesítésre várnak; illetve a befektetett

eszközök közül átsorolt eszközöket. Az ingyenesen megszerzett, például az internetről letölthető szoftverek esetében, amennyiben azoknak piaci értéke nulla, alkalmazható az Szt. említett 80 § (2) bekezdése; amennyiben a szoftvernek van piaci értéke, akkor annak állományba vétele a piaci értéken az Szt. 86 § (4) bekezdés c) pontja szerint – térítés nélküli eszközátvétel címén – a rendkívüli bevételek között halasztott bevételkénti könyveléssel történik. A szoftverek számviteli elszámolása során a fentiekben hivatkozott szabályok figyelembevételével, mindig az adott gazdasági esemény egyedi sajátosságaira figyelemmel kell eljárni. 1054 Budapest, Széchenyi u. 2 Kérjük, válaszlevelében szíveskedjék iktatószámunkra hivatkozni. 2009. június 15 352 3 II. A nyílt forráskódú szabad szoftverek felhasználási joga átadásának, mint ügyletnek áfabeli megítélésénél mindig szükséges az adott ügylet

körülményeinek, jellegének vizsgálata, mivel az ügylet adójogi megítélése ezek tükrében változhat. A szoftverek felhasználási jogának az értékesítése az általános forgalmi adóról szóló 2007. évi CXXVII törvény (a továbbiakban: áfatörvény) 13 § (1)-(2) bekezdése alapján szolgáltatásnyújtásnak minősül. A jogszabályhely értelmében szolgáltatás nyújtás bármely olyan ügylet, amely e törvény értelmében nem termék értékesítése. A szoftver felhasználási jogának átadása vagyoni értékű jog átadásának minősül, ami szolgáltatásnyújtás. Ha az ügylet kapcsán a szolgáltatást igénybevevő a szoftver forráskódját is szabadon felhasználhatja, az ügylet továbbra is szolgáltatásnyújtásnak minősül. Ennek oka, hogy az áfatörvény 9 § (1) bekezdése szerint csak a birtokba vehető dolog átengedése minősül termékértékesítésnek, amely az átvevőt tulajdonosként való rendelkezésre jogosítja. Magának a

szoftvernek a számviteli megítélése, hogy azt akár szellemi termékként, akár vagyoni értékű jogként kezelik számvitelileg, nem zárja ki azt, hogy a szoftver felhasználási jogának átadása az áfatörvény tekintetében szolgáltatásnyújtásnak minősüljön. A szoftver felhasználási joga több személynek is értékesíthető, ez a tény nem mond ellent annak, hogy a tevékenység vagyoni értékű jog átengedésének, szolgáltatásnak minősüljön, vagyis úgymond többször is lehet szolgáltatásként nyújtani ugyanazt a felhasználói jogot más személynek. A szabad szoftver felhasználási joga átadásának adójogi megítélése függ attól, hogy a szolgáltatást nyújtó bír-e adóalanyisággal, külföldi vagy belföldi személy, illetve a szolgáltatást ellenérték fejében nyújtja-e vagy ingyenes. Az ingyenes ügyletek nem tartoznak az áfatörvény 2. §-a, mint főszabály alapján az áfatörvény alkalmazási hatálya alá, így az

ingyenes szolgáltatások sem, kivéve, ha az áfatörvény 14. § (2) bekezdésében meghatározott feltételek megvalósulnak. Az áfatörvény 14 § (2) bekezdése értelmében, szintén ellenérték fejében teljesített szolgáltatásnyújtás, ha az adóalany saját vagy alkalmazottai magánszükségletének kielégítésére vagy általában, vállalkozásától idegen célok elérésére másnak ingyenesen nyújt szolgáltatást, feltéve, hogy a szolgáltatás igénybevételéhez kapcsolódóan az adóalanyt egészben vagy részben adólevonási jog illette meg. 1. Belföldi szolgáltatásnyújtó Abban az esetben, ha a szolgáltatást nyújtó belföldi, és ellenérték fejében adja át a szoftver felhasználási jogát, a szolgáltatás az áfatörvény hatálya alá tartozik és adóköteles. (Függetlenül attól, hogy előtte adóalany volt-e, mivel ezen tevékenységével adóalannyá válik.) Ha belföldi nem adóalany személy ingyenesen adja át a felhasználási

jogot, illetve belföldi adóalany úgy adja át a felhasználási jogot, hogy nem valósítja meg az 1054 Budapest, Széchenyi u. 2 Kérjük, válaszlevelében szíveskedjék iktatószámunkra hivatkozni. 2009. június 15 353 4 áfatörvény 14. § (2) bekezdésében leírtakat, az ügylet az áfatörvény alkalmazási hatályán kívüli, így nem keletkezik a szolgáltatásnyújtónak adófizetési kötelezettsége. Azonban, ha a belföldi adóalany szolgáltatásnyújtónak előzetesen adólevonási joga keletkezett az áfatörvény alapján a szoftver elkészítésével kapcsolatban, az áfatörvény 14. § (2) bekezdése alapján adóköteles szolgáltatásnyújtásnak fog minősülni a szoftver felhasználási jogának ingyenes átadása. 2. Külföldi szolgáltatásnyújtó Ha külföldi adóalany nyújtja a szoftver felhasználási jog átadásának szolgáltatását a költségvetési szervnek, önkormányzatnak, az ügylet az áfatörvény 46. § (1) bekezdés a)

pontja, (2) bekezdés k) pontja, valamint (5) bekezdés b) pontja szerint belföldi teljesítési helyű ügyletnek minősül, ha az igénybevevő költségvetési szerv önkormányzat áfa adóalany. Az ügylet az áfatörvény 46 § (2) bekezdése k) pontja értelmében elektronikus úton nyújtott szolgáltatásnak minősül. Ha a szolgáltatást igénybevevő költségvetési szerv, önkormányzat nem adóalany, az ügylet teljesítési helye az áfatörvény 36. §-a alapján nem Magyarország, így az ügylet az áfatörvény területi hatályán kívüli. Kivéve azt az esetet, ha a szolgáltatást nyújtó nem tagállami adóalany, ez esetben az áfatörvény 47. §-a értelmében a szolgáltatás teljesítési helye Magyarország Azonban ha a szabad szoftver felhasználói jogát ingyenesen adják át, az ügylet a belföldi teljesítési hely esetén is az áfatörvény hatályán kívüli, csak nem a területi hatályán, hanem az alkalmazási hatályán kívülinek

minősül. Ez esetben nem vizsgálandó az áfatörvény 14. § (2) bekezdése, mivel a külföldi adóalany valószínűleg nem vonhatott le áfát a szoftver elkészítésével kapcsolatban a magyar áfatörvény szerint, így az ügylet nem minősül a 14. § (2) bekezdés értelmében adóköteles szolgáltatásnyújtásnak. Ha a szoftver felhasználási jogának átadója nem adóalany külföldi személy (nem is válik adóalannyá, mivel ingyenesen adja át a szoftver felhasználási jogát), az ügylet az áfatörvény területi hatályán kívüli. Tehát külföldi szolgáltatásnyújtása esetén akkor lesz adóköteles az ügylet, ha a szolgáltatás teljesítési helye Magyarország, és az ügylet ellenértékes. Ez esetben az adót az áfatörvény 140. § b) pontja alapján a fordított adózás szabályai szerint a szolgáltatás igénybevevőjének kell a Költségvetés felé befizetni. Más esetben nem keletkezik adófizetési kötelezettsége Magyarországon. Az

általános forgalmi adóról szóló 1992. évi LXXIV törvény (a továbbiakban: régi áfatörvény) 9. § (3) bekezdés a) és c) pontja szerinti ügyletek esetén, mely szerint a szolgáltatás ellenérték nélkül történő nyújtására törvény vagy kormányrendelet alapján kerül sor, illetve ha a szolgáltatást vállalkozási célból ingyenesen nyújtják (ide nem értve a gazdaságilag nem független felek közötti szolgáltatásnyújtást), a régi áfatörvény szerint nem minősültek szolgáltatásnyújtásnak. A 2008 január 1-jétől hatályos áfatörvény nem vette át ezt a szabályozást, így ezen ingyenes ügyletek is adóköteles ügyletnek minősülnek, feltéve, hogy a szolgáltatással kapcsolatban a szolgáltatást nyújtónak a magyar áfatörvény szerinti adólevonási joga keletkezett. 1054 Budapest, Széchenyi u. 2 Kérjük, válaszlevelében szíveskedjék iktatószámunkra hivatkozni. 2009. június 15 354 5 A régi áfatörvény 13. §

35 pontja szerinti vállalkozási célból ingyenesen nyújtott értékesítés fogalom a hatályos áfatörvény szerint nem alkalmazható. Az áfatörvény 11 § (3) bekezdése szerinti szabályozás jelen esetben nem alkalmazható, mivel az csak áruminta és kis értékű termék ingyenes átadására vonatkozik. Ha a vagyoni jog jogosultja a szabad szoftverre vonatkozó felhasználási jogot annak érdekében engedi át ingyenesen, hogy a későbbiek során ennek kapcsán szolgáltatást nyújtson, a szoftver ingyenes átadása ellenérték fejében történő szolgáltatásnyújtásnak minősül, mivel az ingyenes átadás nem közvetlenül vállalkozási célból történik. Ez esetben az ügylet adóköteles, ha előzetesen a szolgáltatással kapcsolatban a szolgáltatást nyújtó levonhatta az áfát. Ha a szoftver ingyenes átadása, és az azt követő ellenértékes szolgáltatás egymással közvetlen, ok-okozati kapcsolatban áll, azaz már az ingyenes szolgáltatás

nyújtásánál biztos, hogy a szolgáltatást nyújtó ehhez kapcsolódóan ellenértékes szolgáltatást nyújt, akkor az ingyenes és az ellenértékes szolgáltatásnak együtt, mint szolgáltatáscsomagnak az ellenértéke lesz a kapott pénzösszeg. III-IV. Ha egy cég a szabad szoftveres közösségre támaszkodva kezd szoftveres fejlesztést, és a közösség tagjai a fejlesztésért pénzbeli vagy más juttatásbeli ellentételezést nem kapnak, az ügylet az áfatörvény alkalmazási hatályán kívüli. Azon ügyletek nem tartoznak az áfatörvény hatálya alá, melyek keretében szoftverek továbbfejlesztése, bővítése, módosítása történik, és a szoftver tulajdonosa és a továbbfejlesztő között nem történik ellenértékes ügylet, és a szoftver tulajdonosa a szoftver elkészítésével kapcsolatosan az áfatörvény szerint nem vonhatott le adót. Amennyiben történik ellenérték megfizetése akár a fejlesztés előtt, akár utána, az ingyenesség

okán az ügylet már nincs az áfatörvény hatályán kívül. Ez esetben áfa szempontból az ügylet pontos ismeretében dönthető el annak adójogi megítélés. A szoftverfejlesztés számviteli elszámolása, illetve a szabad szoftver továbbfejlesztése tekintetében az I. pontban leírtak megfelelően irányadók, az állampolgárságnak e tekintetben nincs jelentősége. A személyi jövedelemadóról szóló, többször módosított 1995. évi CXVII törvény (a továbbiakban: szja-törvény) nem tartalmaz speciális szabályt a jogdíjból származó jövedelmekre, így arra az esetre sem, ha egy szoftverhez kapcsolódó jogból származik a magánszemélynek jövedelme. Éppen ezért, ha a szoftvert magánszemély fejleszti ki (ide nem értve természetesen azt az esetet, amikor a magánszemély egy vállalkozás munkavállalójaként végzi a fenti tevékenységet), és annak fejében bármilyen formában ellenértékben részesül, akkor ez a bevétel a magánszemély

önálló tevékenységéből (szoftverfejlesztéshez kapcsolódó tevékenységet folytató egyéni vállalkozó esetén az egyéni vállalkozásból) származó bevételének minősül. Az adókötelezettség alakulását az sem befolyásolja, ha a magánszemély korábbi, akár több éves munkájáért részesül 1054 Budapest, Széchenyi u. 2 Kérjük, válaszlevelében szíveskedjék iktatószámunkra hivatkozni. 2009. június 15 355 6 egy összegű juttatásban. Amennyiben a magánszemély nem a saját fejlesztésű szoftveréhez kapcsolódó, például örökölt jog fejében részesül bevételben, ez a magánszemély egyéb jövedelmének minősül. Tekintettel arra, hogy az szja-törvény a magánszemély jövedelméhez kapcsolódó szabályokat tartalmazza, így, ha a magánszemély a tevékenységét ingyenesen végzi, vagy a szoftverhez kapcsolódó jogát ingyenesen adja át más személynek, a személyi jövedelemadóval kapcsolatos kötelezettsége nem

keletkezik. Ahhoz, hogy szabad szoftver fejlesztéséhez kódot/kódrészletet adjon, adójogi akadálya nincs. harmadik személy ingyenesen Az ellenőrzések során az adózó nyilvántartásait az adóhatóság az adózás rendjéről szóló 2003. évi XCII törvény és az Szt előírásaira figyelemmel ellenőrzi; a szoftverek nyilvántartása az e jogszabályoknak megfelelően vezetett nyilvántartások keretében történik. Az eszköznek könyvekből való kivezetése a tárgyi eszköz könyv szerinti értékén (vagyis a kivezetés időpontjáig elszámolt terv szerinti értékcsökkenéssel csökkentett bekerülési értékén) történik, terven felüli értékcsökkenés elszámolása útján, melyet az egyéb ráfordítások között kell kimutatni, s melyhez – a társasági adó alanyai esetén – adóalap-korrekciós tételek is kapcsolódnak. A kivezetés jogcíme az adott gazdasági eseménynek megfelelően lehet például értékesítés, térítés nélküli

átadás, selejtezés. A megrendelésre végzett szoftverfejlesztés álláspontom szerint nem minősülhet alvállalkozói teljesítménynek, közvetített szolgáltatásnak pedig csak akkor, ha az Szt. 3 § (4) bekezdés 1. pontjában foglalt feltételek teljesülnek (a megrendelővel kötött szerződésből a közvetítés lehetősége, a számlából a közvetítés ténye egyértelműen megállapítható). Egyéb esetekben a szolgáltatást az igénybevett szolgáltatások vagy az egyéb szolgáltatások között kell kimutatni. Budapest, 2009. március „ ” Tisztelettel: Dr. Szikora János Erről értesülnek: 1. címzett 2. központi irattár 1054 Budapest, Széchenyi u. 2 Kérjük, válaszlevelében szíveskedjék iktatószámunkra hivatkozni. 2009. június 15 356 2009. június 15 J függelék Részlet az LME IDA2 projektjének negyedéves tájékoztató anyagából 357 358 Alkalmasak-e a szabad szoftverek a közigazgatási használatra, alkalmas-e

közigazgatásunk a szabad szoftverek használatára? „A bürokrácia két dolgot utál, a függést (függőséget) és a változást.” ismeretlen bürokrata a szervezetről Jelen tanulmány egyfajta képet próbál adni az informatikai kereskedelem és fejlesztés jelenlegi magyarországi helyzetéről, különös tekintettel az állam- és közigazgatás területére, és megpróbálja felvázolni azt a folyamatot, mely esetlegesen lehetővé teszi az állam- és közigazgatásunk érdemi nyitását a szabad szoftverek és a szabad szoftveres megoldások irányába. Előrebocsátjuk, hogy az anyagban sok dolog feltételezéseken és véleményeken alapul, tekintettel arra, hogy egy átfogó felmérés messze meghaladja szervezetünk lehetőségeit. 2009. június 15 359 Címszavakban Alkalmasak-e a szabad szoftverek a tudatos közigazgatási használatra, alkalmas-e közigazgatásunk a szabad szoftverek tudatos használatára?.6 Szabad szoftver, Nyílt forrás.6 Szabad

szoftver.6 Nyílt forrás.7 A nyílt forráskódú licenc.7 Tudatos szoftverválasztás, tudatos szoftverhasználat.8 Az átlag felhasználó tudatossága.8 Sokan nem használják jól a napi munkájukhoz használt szoftvert.8 Nem általános technológiát, hanem egy-egy kiválasztott eszközt tanulunk, s kevés a megmaradó tudás.8 Hiányos tudásunk eredményeképpen nem költséghatékony a szoftver választásunk, használatunk.9 Egy ügyes, bújtatott reklám és a tudásunk hiányossága az, ami szoftverválasztásunkat befolyásolja.9 A szoftverfejlesztők, -forgalmazók tudatossága.10 A tudományos és mérnöki munkában egymás ellenőrzése természetes.10 A szoftverfejlesztésben nem természetes a mérnöki munkában megszokott ellenőrzés.10 A szokott magyarázat „Ez van, vagy semmi”.10 A cégek valós célja a profit maximalizálása.10 A fentiek alapján jelenleg elvárható „tudatosság” a szoftverbeszerzéseknél.11 A két oldal „tudatos” szempontjai

összefoglalva.11 A beszerzők tudatossága a szoftver beszerzésnél.11 A beszállítók, eladók tudatossága a szoftver eladásnál.12 Az eddigi „tudatosság” eredménye.13 Amit még tudomásul és figyelembe kell vennünk, mert együtt élünk vele.14 Hogyan lesz, lehet általános, megszokott a szabad szoftver az állam- és közigazgatásunkban?. 15 Felismerések.15 25 / 1 2009. június 15 360 A szabad és a zárt licencű programok még sokáig együtt fognak élni.15 Kevesebb, de legalábbis nem nő eléggé az informatikára költhető pénz, ellenben nőnek a feladatok, és biztosítani kell az esélyegyenlőséget.15 Nem mindig a nagyok a legjobbak számunkra.16 Nem lehet mindig biztosra játszani.16 A szabad szoftver használata növeli a versenyt és ezzel esélyt ad a költség csökkentésre.17 A változáshoz központi akarat kell.17 Lépések.18 Szüntessük be az ingyen reklámot iskoláinkban, ahol lehet tanuljunk és tanítsunk szabad szoftvert.18

Támogassuk a felnőttképzésben a szabad szoftverek oktatását.18 Vezessük be a állam- és közigazgatásunkba az ODF formátumot, az OpenOffice irodai csomagot.18 Hozzuk létre és támogassuk megfelelő jogosultságokkal azt a szervezetet, mely vizsgálja az állam - és közigazgatás jelenleg használt szoftvereit; felügyeli, támogatja és segíti a szabad szoftveres megoldásokra történő átállást.19 Indítsunk az állam- és a közigazgatásban szabad szoftveres projekteket.19 Tapasztalataink és mások tapasztalatai alapján tanítsuk közintézményeinknek a szabad szoftveres projektek lebonyolítását.19 Függelék.21 Joel Spolsky: A Big MAC és a Mezítelen Séf.21 Zárótűz.22 A Transparency International Hungary a korrupcióról.23 25 / 2 2009. június 15 361 Egy 2004-ben készült - mára már a fejlődés és a valóság miatt kicsit meghaladottá vált - Gartner tanulmány szerint a következő területeken, esetekben javasolt a kormányzatoknak

szabad szoftvert használniuk: Ahol a TCO megtakarítás világosan jelentkezik, illetve ahol az OSS különlegesen kiforrott már. Ahol az OSS nagyon hasonló a meglévő rendszerhez és jól használható a meglévő tudás. Új, házon belüli fejlesztésekre. A kinézett kereskedelmi megoldások árának leszorítását segítő fegyverként.1 Mostanra a címben szereplő mindkét kérdés már-már eldőlt. Alkalmas, és használja Ezt bizonyítja egy a MERIT2 által az Európai Unióra reprezentatívan végzett felmérés3. Ennek eredményeképpen tudjuk, hogy a helyi kormányzatok fele már használt legalább néhány FLOSS4-t. Van még valami, ami bár meglepő, mégis mutatja a FLOSS-használat mindennaposságát, a FLOSS szoftverek használhatóságát. Ez pedig az a tény, hogy további 29% nem volt tudatában annak, hogy ilyen licencelésű szoftvert használ, tehát nemmel válaszolt arra a kérdésre, hogy használ-e FLOSS-t, majd a használt szoftverei

között felsorolt FLOSS kategóriás szoftvereket5. Figyelembe véve azt, hogy Magyarország az Európai Unió része, és az Európai Unióban már használnak a közigazgatásban szabad szoftvereket, azt lehet következtetésként levonnunk, hogy a szabad szoftverek alkalmasak a közigazgatási használatra, s a közigazgatás is alkalmas lehet a szabad szoftverek használatára6. Csak megjegyzésként (ahogy mi látjuk) állami és közigazgatási intézményeinkre jellemző a licenc-túlhasználat7. Ez a szállítók által tudott és tűrt dolog, valószínűleg azért, mert növeli a licenc-túlhasználó függőségét tőlük. A „lehet” magyarázatát könnyebben megleljük, ha kicsit átfogalmazzuk a kérdést. 1 2 3 4 5 6 7 Ez a legtipikusabb használat Honlap a MERIT megismeréséhez: http://www.meritunuedu Ez az eddigi legnagyobb és legkiterjedtebb felmérés a FLOSS használatáról a közigazgatási intézményekben, a felmérés a következő tagállamokra

terjedt ki: Ausztria, Belgium, Csehország, Dánia, Franciaország, Németország, Görögország, Olaszország, Hollandia, Lengyelország, Spanyolország, Svédország, Egyesült Királyság, FLOSS, azaz Free/Libre/Open Source Software magyarul ingyenes/szabad/nyílt forrású szoftver GNU/Linux, Apache stb. Persze az átlag állam-, közigazgatási felhasználó nem látványosan találkozik a szabad szoftverekkel a munkahelyén, mert jelenleg elsősorban szerver megoldások (webszerver, fájlszerver, tűzfalak stb.) azok, amelyek ezen a területen elterjedtek Azaz több példányt használnak, mint amennyiért fizettek. Természetesen nem mindenhol, nem mindenkor, és nem mindenki 25 / 3 2009. június 15 362 Alkalmasak-e a szabad szoftverek a tudatos közigazgatási használatra, alkalmas-e közigazgatásunk a szabad szoftverek tudatos használatára? Jól látható, hogy a tudatos8 használat az, amit a kérdés feszeget. Érdemes a kérdést két külön kérdésre bontani

és azokat egyenként megválaszolni. Tehát a továbbiakban erre a két kérdésre kell választ találnunk: 1. Alkalmasak-e a szabad szoftverek a tudatos közigazgatási használatra? 2. Alkalmas-e közigazgatásunk a szabad szoftverek tudatos használatára? Tulajdonképpen a tudatosság a központi kérdés, és ez az, aminek megléte mindent megváltoztat. Hiszen jelenleg az elfogadott szoftverválasztási szempontok között a magyar közigazgatásban jellemzően nem szerepel általában a szabad szoftver kitétel9. Úgy gondolom, hogy ennek a feltételnek a használata10 a kulcs. A tudatos törekvés a FLOSS besorolású szoftverek használatára nagyon sok mindent megváltoztat. Hogy könnyebben tudjunk tovább haladni, tisztázzuk, hogy mi is az a szabad szoftver. Szabad szoftver, Nyílt forrás Szabad szoftver Legelőször is nézzük a Wikipédiát11, melyben a következőket olvashatjuk: A szabad szoftver kifejezés olyan számítástechnikai dolgokat (általában

programokat) jelent, melyek szabadon felhasználhatóak. A fogalmat a licenc fogalmával kapcsolatban, a szerzői jogilag védett, zárt forráskódú szoftverekkel szemben használjuk, azoktól való megkülönböztetésre. A szabad programok szabadságát a szabad licencek biztosítják. A „szabad szoftver” elnevezés a felhasználók szabadságára utal. Ez a szabadság az alábbi négy pontban foglalható össze: 8 1 jelentés (melléknév): akinek tudata van. Az ember tudatos lény A tudat részvételével végbemenő (lelki folyamat) A tudaton alapuló illetve a tudatban világosan jelenlevő (jelenség, cselekvés, magatartás), tudatos törekvés 2 jelentés (melléknév): megfontolt, szándékos. (Tudatos hazugság) 3. ritkább jelentés: Öntudatos, pl öntudatos magatartás tudatosít (ige) tudatossá tesz valamit valakiben Tudatosítja valaminek a jelentőségét Tudatosodik (ige) Valami fokozatosan tudatossá válik valakiben. (Még nem tudatosodott benne, hogy

árva) 9 Ellenben Peruban igen. „Peruban a kormányzati feladatokhoz szükséges szoftvereket ki fogják váltani szabad szoftverekkel Peru nemrég hozta meg a szabad szoftverek terjesztését és kormányzati használatát előíró törvényét. A kormányzati feladatokhoz szükséges szoftvereket minél nagyobb mértékben ki fogják váltani szabad szoftverekkel. Legfontosabb okuk erre az, hogy Peru alkotmánya kötelezővé teszi az információkhoz való szabad hozzáférés biztosítását, korlátozás nélkül.” Forrás: Szabad Szoftver Intézet (http://www.szszihu/kozlemenyek/sajat/2005/10/19/OSS a kormanyzatokban/index3html) 10 Vélhetően nem ennyire egyértelműen és mellbevágóan kell és lehet fogalmazni, de mindenképpen ez kell, hogy az irányultság legyen 11 A Wikipédia, egy szabad enciklopédia, amit bárki szerkeszthet. A Wikipédia többnyelvű projekt, melynek célja egy teljes és pontos, nyílt tartalmú enciklopédia elkészítése. Elérhető:

http://huwikipediaorg/wiki/Kezdőlap 25 / 4 2009. június 15 363 1. A felhasználóknak szabad tetszőleges célra, tetszőleges számú számítógépen futtatni a szoftvert, azaz a felhasználást semmi nem korlátozza. 2. A felhasználó szabadon másolhatja és terjesztheti, illetve közzéteheti a szoftvert 3. A felhasználó szabadon módosíthatja, testre szabhatja, javíthatja, tökéletesítheti a szoftvert. 4. A felhasználó szabadon közzéteheti a szoftver általa módosított verzióját A 3. és 4 pont előfeltétele a forráskód hozzáférhetősége A szabad nem feltétlenül jelent „ingyenest”: bárki bármennyiért árusíthatja12 a kérdéses programokat; az egyetlen feltétel, hogy a fenti négy alapjogot garantálja vevői számra. Nyílt forrás Az, hogy egy szoftvernek hozzáférhető a forrása még nem jelenti azt, hogy szabad szoftver, sőt, még azt sem, hogy a szoftver „Nyílt forráskódú licenc”13 alá tartozik. Belátható, hogy attól,

hogy elolvashatjuk a forráskódot még nem biztos, hogy: – A felhasználóknak szabad tetszőleges célra, tetszőleges számú számítógépen futtatni a szoftvert, azaz a felhasználást semmi nem korlátozza. – A felhasználó szabadon másolhatja és terjesztheti, illetve közzéteheti a szoftvert. – A felhasználó szabadon módosíthatja, testre szabhatja, javíthatja, tökéletesítheti a szoftvert. – A felhasználó szabadon közzéteheti a szoftver általa módosított verzióját. Ezt azért is fontos tudnunk, mert az utóbbi időben egyes szoftvercégek hozzáférhetővé teszik egyes szoftvereik forrását részben vagy egészben felhasználóik számára, de mint látjuk ez nem jelenti azt, hogy az adott szoftver (pl.: Windows XP) nyílt forráskódú licenc alá került A nyílt forráskódú licenc A nyílt forráskódú licenc olyan licenc, mely biztosítja a licencelt dolog - ami legtöbbször egy számítógépes program vagy szoftver -

forráskódjának nyitottságát. Formálisabban egy licencet 12 Miért venné meg bárki is (a szabad szoftvert)? Azért, mert például nem képes azt magának lefordítani, szüksége van kézikönyvre, CD-n vagy DVD-n szeretné a programokat megkapni, vagy mert támogatásra van szüksége. Az is elképzelhető, hogy valaki egyedi fejlesztést, testreszabást, adott hiba kijavítását, adott funkció beépítését végezteti el pénzért egy programozóval. 13 Az OSI 2003-ban az alábbi licenceket ismeri el nyílt forráskódot támogatónak: Academic Free License, Apache Software License, Apple Public Source License, Artistic license, Common Public License, Eiffel Forum License, BSD License, GNU General Public License (GPL), GNU Lesser General Public License (LGPL), Historical Permission Notice and Disclaimer, IBM Public License, Intel Open Source License,Jabber Open Source License, MIT License MITRE Collaborative Virtual Workspace License (CVW License), Motosoto License,

Mozilla Public License 1.0 (MPL), Mozilla Public License 11 (MPL 11), NetHack General Public License Nokia Open Source License, Open Software License, Open Group Test Suite License, Python license, Python Software Foundation License, Q Public License (QPL), Ricoh Source Code Public License, Sleepycat License, Sun Industry Standards Source License (SISSL), Sun Public License, Vovida Software License v. 10, W3C License, XNet License, zlib-libpng license, Zope Public License 25 / 5 2009. június 15 364 nyíltnak tekintünk, ha azt az Open Source Initiative jóváhagyja, mint ilyet, a Nyílt forrás definíció alapján. A közkincsként terjesztett programok (vagyis azok, melyeket nem korlátoz a szerzői jog) is megfelelnek ezen követelményeknek, amennyiben a teljes forráskód elérhető, és így jogosult az OSI „service mark” (szolgáltatási védjegy) használatára. A nyílt forráskódú licencek szabad licenceknek számítanak.14 Tudatos szoftverválasztás, tudatos

szoftverhasználat Ezt a témát azért kell körüljárnunk, mert ennek megrágása nélkül bizony nem juthatunk megfelelő következtetésre. Az átlag felhasználó tudatossága Országunkban az emberek általában „wordben” írnak dokumentumokat15. Legyen a cél 10 soros levél vagy 300 oldalas tanulmány. Ezen, ennek okain és következményein gondolkodjunk egy kicsit. Sokan nem használják jól a napi munkájukhoz használt szoftvert Mindannyian láttunk már olyat, hogy a Word „sablonban”16 néhány soremeléssel ki volt hagyva a céges fejléc / logó helye, mert a nyomtatás az előre nyomott céges papírra történt. Olyat is láttunk, hogy valaki sok soremeléssel éri el, hogy valami új lapon kezdődjön, vagy éppen szóközökkel alakítja ki a dokumentum formátumát.Gondolom a fentieket együtt is sokan és sokszor látták már17. Erre így a „Word” helyett a Windows beépített eszköze a „wordpad” nevű programocska is sok, de legalábbis elég

lenne, de mégis a Word az, ami kell. Nem általános technológiát, hanem egy-egy kiválasztott eszközt tanulunk, s kevés a megmaradó tudás De miért van ez így? Mert már az iskolában megtanuljuk és megtanítjuk, hogy „Word18”-öt kell használni, ahelyett, hogy szövegszerkesztést tanítanánk, hogy „Excel”-t19 kell használni, ahelyett, hogy számolótábla-használatot tanítanánk. Iskolában általában nem sortöréseket javasolnak / oktatnak az új oldal eléréséhez, de kevés marad meg a tanultakból. Felhasználóink egyébként is eredmény orientáltak, márpedig kinyomtatva úgy sem látszik az, mi, hogyan készült elektronikusan! Azt gondolom, hogy a tanultakból megmaradó kevésnek mindig része, hogy mihez mi kell. Tehát az, hogy „Word”, „Excel”, „Photoshop”, „Coreldraw” stb. kell Sajnálatos, de tény, hogy a hogyan, 14 Forrás: Wikipédia 15 Rajzolni meg Corel Draw-ban „kell”, s a „legjobb” a fényképi piros szem ellen

az Adobe PhotoShop 16 Nagyon sokszor az igazi sablon helyett csak egy minta állomány (.doc) van, vagy éppen megnyitnak egy régi, már megírt állományt, és törlik annak tartalmát. 17 Lehet azt mondani, hogy az állam- és a közigazgatás dolgozói ECDL vizsgával rendelkeznek. Ez így van, viszont sajnos az ECDL vizsga megléte nem akadályozza a szakszerűtlen használatot. 18 A Microsoft Word programja egy nagyon nagy tudású és viszonylag drága szövegszerkesztő. Általában az emberek a Microsoft Office szoftvercsomag részeként találkoznak vele. 19 A Microsoft Excel programja egy nagyon nagy tudású és viszonylag drága táblázatkezelő. Általában az emberek a Microsoft Office szoftvercsomag részeként találkoznak vele. 25 / 6 2009. június 15 365 tehát a szakértelem, melyhez gyakorlás is kell, nehezebben tanulható, és könnyebben elvész. Hiányos tudásunk eredményeképpen nem költséghatékony a szoftver választásunk, használatunk Miért

nem annyira jó dolog ez? Nos, mert nem mind vagyunk részvényesek az adott cégben, cégekben, s nem mind élünk az ezen termékek eladása után járó jutalékból. Az sem utolsó szempont a „nemjóság” indoklásában, hogy korlátozott tudásunknak hála, nem mindig az elégséges / gazdaságos / megfelelő eszközt használjuk az adott feladatra. Ez pedig drága dolog. Mert meg kell venni a drága számítógépet, a drága nyomtatót és a drága szoftvert Vagy éppen el kell lopni20 a szoftvert, hiszen nekünk a munkánkhoz az, és pont az kell. Általában, még ha van sem tudunk, ismerünk alternatívát21. No meg kockázatos is mást venni, mert ha nem jó, nem elég, akkor bizony kidobtuk a ráköltött pénzt az ablakon22. Az is motiváció, hogy az idő pénz, a mi időnk, ha nem saját zsebből kell a szoftvert fizetnünk, pedig drága23, tehát nem fogjuk saját drága időnket szoftver próbálgatással, tanulgatással tölteni. Egy ügyes, bújtatott reklám

és a tudásunk hiányossága az, ami szoftverválasztásunkat befolyásolja Tehát tudatosan választjuk azt a szoftvert, melyet már az iskolában is tanultunk, s tudatosan használunk belőle annyit, amennyire szerintünk szükségünk van24. Ez a fajta tudatosság25, nagyon kellemes dolog az adott szoftvertermékeket gyártó és forgalmazó cégeknek. Gondoljunk bele, milyen álságos dolog, hogy kedvezményes áron (vannak akik ingyen) adnak terméket az oktatásnak, hiszen ez valójában egy nagyon hatékony reklám. A reklámért a piacon, bizony a reklámozott termék gyártója szokott közvetlenül fizetni, nem pedig a célközönség26. 20 Ez nem biztatás az illegális szoftver használatra, mert az komoly, hazánkban hivatalból üldözendő bűncselekmény! 21 Még ha hallottunk is arról, hogy valami mással is lehet ilyesmit csinálni, akkor is a barátaink és ismerőseink is ezt használják, tehát ez a jó. 22 Van már reklám is, mely erre a kockázatra játszik

rá. Az egyik nagynevű izraeli cég tűzfal termékét reklámozzák olyasmi szlogennel, hogy annak választása esetén a rendszergazda nyugodt lehet.S valóban, még baj esetén is az a helyzet, hogy senki nem vonhatja személyes felelősségre, hogy valami ismeretlen terméket támogat. Ő egy a piacon jól bevezetett márkát választott, amit mindenki ismer, sőt a tévében is reklámoznak A szoftveriparban ismeretlenek a gyógyszeriparban általános perek, melyek rákényszerítik a gyártót a termékért történő helytállásra. Néha azt gondolom, sajnálatos, hogy ez így van. 23 Egyszerűen nincs a legtöbb felhasználónak arányérzéke, az Ő ideje minden pénzt megér. Néhány éve tanácsadói munkám során fordult elő, hogy egy könyvtár beszerzésre javasolt szoftverei között AutoCAD-et is (2 felhasználó) találtam. Megkérdeztem, hogy ez mire kell? Vonalkód nyomtatásra. Kis kutakodás után lett olcsóbb (beszerzési ár szempontjából) megoldás,

mely minden vonalkóddal kapcsolatban felmerülő igényt kiszolgált. 24 A legtöbbet felhozott ellenérv, mikor valakinek mondom, hogy stílusokkal, sablonokkal sokkal eredményesebben tudna dolgozni, ha megtanulná, az az, hogy: Túl sok idő lenne. És ez nem igaz, mert a nem használat miatt elvesztegetett időszeletek nagyságrendekkel több elveszett időt (pénzt) jelentenek, mint a megtanulásra egyszer ráfordított idő. 25 Ez mostanra egyre inkább a márkanévhez ragaszkodó fogyasztói tudatosság sajnos. 26 A célközönség a termék árában fizeti meg a reklám költségét, vagy nem, ha nem tetszik neki a termék. Az oktatás ilyen módon történő reklámcélú használata hatékonyabb megtérülést, nyereséget biztosít, mint a hagyományos reklám. 25 / 7 2009. június 15 366 A szoftverfejlesztők, -forgalmazók tudatossága A tudományos és mérnöki munkában egymás ellenőrzése természetes Az eddig összegyűjtött tapasztalataink szerint

megbízható eredményt a mérnöki vagy a 27 természettudományok területén csak kölcsönös ellenőrzés segítségével érhetünk el. Az igazi kutatók, tudósok nem rejtegetik kísérleteik terveit mások elől, hanem kétkedően ellenőrzik egymás munkáját. A felelős mérnökök sem építenek gátakat vagy hidakat anélkül, hogy tervrajzukat ne ellenőriztetnék más – az eredeti tervezőcsoporttól független – mérnökökkel. A szoftverfejlesztésben nem természetes a mérnöki munkában megszokott ellenőrzés Azt is tényként vehetjük tudomásul, hogy a megbízhatóság a szoftveriparban nem elegendően jó. A rendszerösszeomlások, a lefagyások és az adatvesztés még mindig mindennaposak. Ez annak is következménye, hogy nem alkalmazzuk a már jól bevált mérnöki és tudományos módszert, nem alkalmazzuk a kölcsönös kódvizsgálatot. A szokott magyarázat „Ez van, vagy semmi” De miért nem? Hiszen a mérnöki tervezésben, a tudományos

munkában ez megszokott dolog, s a racionális gondolkodás szerint, mivel ez fajta megközelítés már előbb kialakult, mint az informatika, s azon belül a szoftveripar, itt a szoftverek területén is így kellene lennie. Ésszerű, tudatos gondolkodással elfogadható magyarázata az ellenőrzés hiányának, azok után, hogy a számítástechnika ilyen mértékben beépült mindennapjainkba, számunkra, felhasználók számára nincs. Ismert28 magyarázat az, hogy „ez van, vagy a semmi” A cégek valós célja a profit maximalizálása29 Ám ez a magyarázat valójában csak jövedelemszerzéssel, profittal, és azzal a feltételezéssel összekapcsolva értelmezhető, hogy „lop” mindenki30. Azt a magyarázatot, hogy a fejlesztő / forgalmazó azért nem ad forráskódot, hogy egyértelműen felelősséget tudjon vállalni, ebben az esetben nincs31 (máskor se nagyon van) értelme figyelembe venni. Általános szokás, hogy a szoftver fejlesztője, forgalmazója

megtagadja vagy erősen korlátozza a termék (szoftver) használatából adódó következmények miatti felelősség vállalását. 27 Az informatika kezdeti időszakában megszokott volt, hogy a programok forrása is jár a programhoz, sőt nem voltak ritkák a forrásban történő terjesztések sem. Magát az eredeti Unixot is forrásban (C nyelven) adták, s mindenki magának fordította le 28 A szabad szoftverek terjedésével egyre több alkalmazás egyre több területen kínál reális alternatívát, cáfolva az „ez van, vagy semmi” kijelentést, hiszen ma már nem csak operációs rendszerek, fejlesztői eszközök léteznek, hanem például szabad ügyviteli rendszer is. 29 A profitmaximalizálás nem alapvetően elítélendő. Pozitívan vagy negatívan értékelni a felhasznált módszert kell és lehet 30 Nagyon érdekes, hogy fel sem merül az ártatlanság vélelme, az sem, hogy a többség nem lop, és az sem, hogy elég a csak a bűnösöket büntetni. Az

alapvetés az, hogy mind bűnözők, szoftvertolvajok vagyunk. 31 Pont úgy nincs, mint az, hogy egy vállalkozás valamilyen (pl.: üzleti) titokra hivatkozvadja a tevékenységének számviteli / adó ellenőrzését 25 / 8 2009. június 15 367 Ezt mi - felhasználók - egyes területeken (PC használat) még elfogadjuk, ugyanakkor pl. az autóiparban mondjuk egy ABS vezérlőszoftver esetén teljességgel elfogadhatatlannak tartjuk. Összegezve: a kódvizsgálat nem alkalmazása, a forráskód nem biztosítása, a hagyományos (zárt forráskódú elveket követő) fejlesztők részéről többségében tudatos profit maximalizálását célzó magatartás32, melyet az utóbbi időkig mi felhasználók, vevők is elfogadtunk. A fentiek alapján jelenleg elvárható „tudatosság” a szoftverbeszerzéseknél Jelenleg (szerintünk) a következő szempontok érvényesülnek szándékosan vagy akaratlanul a szoftverbeszerzéseknél: A két oldal „tudatos” szempontjai

összefoglalva33 Beszerző Beszállító - alkalmasság teljesítmény kényszer - referencia dobozmozgatás - tudás a drágábbat kell eladni - személyi kockázat minimalizálás márka irányos tudás - támogatottság projekt eredményesség kényszer - „maceramentesség” A beszerzők tudatossága a szoftver beszerzésnél − Alkalmasság: ez azt eredményezi, hogy elvárjuk, hogy a mi meglévő ismereteink szerint legyen alkalmas a feladatra. − Referencia: ez azt eredményezi, hogy elvárjuk, hogy a szoftver ismert legyen, vagy legalább álljon mögötte egy jó nevű, megbízható, tőkeerős cég. − Tudás: ez azt eredményezi, hogy a saját, magunkkal hozott ismereteink miatt márkahűséghez hasonló viselkedés; egyfajta csőlátás alakul ki. Ilyet alakíthat ki egy megkérdőjelezhetetlen szaktekintély véleménye is, akitől felismerve - hogy mi nem tudunk eleget - tanácsot kérünk. Természetesen szerencsés esetben ez, mármint a

tanácskérés, mivel a szaktekintély igazi (valóban egy területhez és nem egy gyártó termékeihez ért), valójában hasznos dolog. − Személyi kockázat minimalizálás: ez azt eredményezi, hogy a szakmai és pénzügyi szempontokat gyakran alárendeljük saját „biztonságunknak”, s ennek eredményképpen 32 Ennek a profit maximalizálási, eddigi legszélsőségesebb törekvése a Számítógéppel megvalósított találmányok álnéven futó direktíva tervezete volt, mely valójában Európában is bevezette volna a szoftver szabadalmakat. 33 A felsorolás nem teljes, és nem tükrözi a sorrend ez egyes szempontok súlyát 25 / 9 2009. június 15 368 működik a „nyáj-hatás”, hiszen ha valamit utánozunk, ott kisebb az esélye a hibának, vagy legalább lehet arra hivatkozni, hogy mások is csinálják, s mi példát követtünk. − Támogatottság: ez azt eredményezi, hogy mi azt várjuk, legyen valaki, aki ha bajban vagyunk segít, akitől

lehet kérdezni, és aki nagyon tud. Sajnos ez az elvárás illuzórikus Ennek alapvető oka, hogy az átlag felhasználó tudása olyan hiányosságokat is tartalmaz, melyek akár súlyos problémákat is okoznak, annak ellenére, hogy egyszerű kézikönyv olvasással, vagy a működés logikájának megértésével, vagyis tanítással, képzéssel megszüntethetőek lennének. Ez pedig azt okozza, hogy a támogatás, még ha van is, gyakran nem, vagy csak sok munkával tud velünk mit kezdeni, mert még a problémánk általunk történő megfogalmazását sem érti meg, de az is előfordul, hogy a „sas nem fogdos legyeket” elv miatt a helyi informatikushoz, illetve a kézikönyvhöz küldenek minket. Egy tipikus példa a támogatás által kezelhetetlen probléma bejelentésre: „Nem működik a számítógép, nincs hálózat”. − Maceramentesség34: ez azt eredményezi, hogy még a jobb végeredmény sem elég indok arra, hogy konfrontálódjunk. Ez egy feladat, amit

nekünk a saját egészségünk érdekében a lehető legkevesebb konfliktussal és kielégítő35 eredménnyel kell megoldanunk. − Minősített forráskihasználás: ez azt eredményezi, hogy ha van egy szoftvervásárlásra fordítható keret, akkor azt csak arra tudjuk fordítani, és azt arra lehet is fordítani. Nem vagyunk érdekeltek abban, hogy alternatív megoldásokkal rövid vagy hosszú távon pénzt takarítsunk meg. Ez az összeg erre (szoftverbeszerzésre) van Az sem ritka, hogy a forrástervezéskor már valamilyen szoftver árát (és nyilván magát a szoftvert is figyelembe vette valaki), ez pedig nem kis ösztönzés arra, hogy azt is szerezzük be. A beszállítók, eladók tudatossága a szoftver eladásnál − Teljesítménykényszer: ma a kereskedői és a műszaki tevékenységek meglehetősen elválnak egymástól. A kereskedők - akik eladnak - teljesítménykényszerben vannak, hiszen a fizetésük és/vagy a prémiumuk függ az eladástól. Az

eladás érdekében minden megengedett. Az eredmény mindent igazol (ha kisebb-nagyobb szabálytalanság, törvénytelenség történt , már ha történt, nem derül ki). A kereskedők eredményességébe nem szokott beszámítani a projekt műszaki eredményessége. Tehát a kereskedőnek azt a terméket kell eladnia, amije van. − Dobozmozgatás: ma többségében a szoftverfelhasználók és a kereskedők is az uniformizált megoldásokban hisznek. A kereskedőnek legjobb „y”-ért venni és