Negyedéves tájékoztató anyag

Átírás

1 Negyedéves tájékoztató anyag Készítették: Balsai Péter Szél Miklós Tomka Gergely Bodnár Csaba

2 Készült: a Miniszterelnöki Hivatal Elektronikus Kormányzati Központja és a Linux felhasználók Magyarországi Egyesülete között évben létrejött szerződés részteljesítéseként, az LME és a Magyar Linux Alapítvány együttműködése keretében. Címszavakban Alkalmasak e a szabad szoftverek a közigazgatási használatra, alkalmas e közigazgatásunk a szabad szoftverek használatára?...8 Bevezető: Alkalmasak e a szabad szoftverek a tudatos közigazgatási használatra, alkalmas e közigazgatásunk a szabad szoftverek tudatos használatára? Szabad szoftver, Nyílt forrás Szabad szoftver Nyílt forrás A nyílt forráskódú licenc Tudatos szoftver választás, tudatos szoftver használat...11 Az átlag felhasználó tudatossága Sokan nem használják jól a napi munkájukhoz használt szoftvert...11 Nem általános technológiát, hanem egy egy kiválasztott eszközt tanulunk, s kevés a megmaradó tudás Hiányos tudásunk eredményeképpen nem költséghatékony a szoftver választásunk, használatunk Egy ügyes, bújtatott reklám és a tudásunk hiányossága az, ami szoftver választásunkat befolyásolja A szoftver fejlesztők, forgalmazók tudatossága...12 A tudományos és mérnöki munkában egymás ellenőrzése természetes...12 A szoftver fejlesztésben nem természetes a mérnöki munkában megszokott ellenőrzés...13 A szokott magyarázat Ez van, vagy semmi...13 A cégek valós célja a profit maximalizálása A fentiek alapján jelenleg elvárható tudatosság a szoftverbeszer zéseknél...13 A két oldal tudatos szempontjai összefoglalva A beszerzők tudatossága a szoftver beszerzésnél...14 A beszállítók, eladók tudatossága a szoftver eladásnál Az eddigi tudatosság eredménye Amit még tudomásul és figyelembe kell vennünk, mert együtt élünk vele / 86

3 Hogyan lesz, lehet általános, megszokott a szabad szoftver az állam és közigazgatásunkban?...18 Felismerések A szabad és a zárt licencű programok még sokáig együtt fognak élni...18 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...18 Nem mindig a nagyok a legjobbak számunkra...18 Nem lehet mindig biztosra játszani A szabad szoftver használata növeli a versenyt és ezzel esélyt ad a költség csökkentésre...20 A változáshoz központi akarat kell Lépések Szüntessük be az ingyen reklámot iskoláinkban, ahol lehet tanuljunk, és tanítsunk szabad szoftvert Támogassuk a felnőttképzésben a szabad szoftverek oktatását...20 Vezessük be a köz és államigazgatásunkba a ODF formátumot, az Open Office irodai csomagot 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 Indítsunk az állam és a közigazgatásban szabad szoftveres projekteket...21 Tapasztalataink és mások tapasztalatai alapján tanítsuk közintézményeinknek a szabad szoftveres projektek lebonyolítását Függelék Joel Spolsky: A Big MAC és a Mezítelen Séf...23 Zárótűz A Transparency International Hungary a korrupcióról...24 Synergy vezércikk IDABC egységvezető IDABC tevékenységek: mi van készülőben? Az IDABC az előző IDA program alatt kezdte meg munkáját a nyílt forrású szoftverekkel (Open Source Software OSS). Az IDABC programjában tervezett újabb fejlesztések a már megtett lépésekre, illetve a már felhalmozott tudásra fognak épülni...27 Nyílt forráskód az európai közigazgatásban felhasználás és fejlesztés...28 A nyílt forráskódú szoftver (Open Source Software, OSS) valóban beépül a közigazgatásba? Használata csak specifikus IT területekre korlátozódik? Mi motiválhatja a közigazgatási 2 / 86

4 szerveket, hogy ingyenes/szabad/nyílt forrású szoftvereket (Free/Libre/Open Source Software FLOSS) alkalmazzanak? És milyen kilátás van a jövőbeli fejlődésre?...28 Együttműködésen alapuló szoftverfejlesztés a közszférában...30 Az együttműködésen alapuló szoftverfejlesztés úgy valósítható meg, hogy az európai közszféra igényeinek kielégítésére az ingyenes/nyílt forrású modellt alkalmazzuk. A belga kormány szakembere, Oliver Schneider az alábbiakban tisztázza ezt az elgondolást...30 Közösség létrehozása, avagy hogyan dolgozzunk együtt nyílt forráskódon...31 A nyílt forráskódú szoftver (Open Source Software, OSS) legnagyobb haszna nem az alacsony költség, vagy a kódhoz való szabad hozzáférés, hanem a tudás megosztása nagy közösségeken belül, együtt dolgozó emberek között. Hogy a közszféra szervezetei hasznát láthassák mindennek az IDABC megjelentetett egy tanulmányt Útmutató a szabad szoftverfejlesztőkkel való együttműködéshez a közszféra számára címmel...31 Vitás jogi kérdések az OSS szel kapcsolatban...32 A nyílt forrású szoftverek (Open Source Software OSS) használata nemcsak technikai és szervezési kérdéseket vet föl: a jogi vonatkozásokkal is foglalkozni kell. A licensszel kapcsolatos legfontosabb kérdések a garancia, felelősség, a szellemi tulajdonjogok megsértése stb Interjú Prof. Eben Moglennel Prof. Eben Moglen nemzetközileg ismert jogász és akadémikus, tagja az FSF (Free Software Foundation Szabad Szoftver Alapítvány) igazgatói bizottságának. Az 1985 ben Richard Stallmann által Bostonban (USA) alapított FSF a General Public License (GPL) tulajdonosa, mely a világon a legelterjedtebb szabad szoftveres licensz. Mint az FSF általános jogtanácsosa, Moglen kezeli az Alapítvány jogi ügyeit, így vezető szerepet tölt be a GPL fejlesztésében és terjedésének elősegítésében Holland útmutató a nyílt szabványok és a nyílt forrású szoftverek közbeszerzési folyamatáról...36 A holland kormány OSOSS (Open Standards and Open Source Software nyílt szabvány és nyíl forrású szoftver) programját bízta meg a gazdasági miniszter, hogy hozzon létre egy útmutatót a kormányzati szerveknek arról, hogyan kezeljék az OSOSS t a közbeszerzésekben Megegyezés az nyílt forráskód fejlesztéséről Londonban...38 Camden egy a 32 kerület közül Londonban, lakossal óta használ nyílt forráskódot, azóta vesz részt nyílt forráskódú szoftverfejlesztésben Valóban készen áll az üzleti felhasználásra a nyílt forráskód?...39 Az üzleti és közigazgatási szervezetek az ICT kihívásaira adott válaszainak középpontjában a célszerűség, a funkcionalitás és az értéket a pénzért elve állt. A nyílt szabvány teljes mértékű együttműködést tesz lehetővé az ICT gazdasági rendszerek számára a kereskedelmi 3 / 86

5 szoftverek és az OSS (Open Source Software nyílt forráskódú szoftverek) elemei között. Az OSS együttműködésen alapuló megközelítése új távlatokat nyit...39 Az Európai Biometrikus Portál Az Európa Tanács elindította a teljes mértékben nyílt forráskódon alapuló Európai Biometrikus Portált (EBP) IPM (Interactive Policy Making Interaktív Szabályzat Készítő): hamarosan elérhető a nyílt forráskódú verzió Beszámoló a II Open Source World Conference ről...42 Bevezető: A konferencia bevezető szövege: Első nap Michail Bletsas, MIT Tematikus szekció: Projects of OSS in commercial applications...44 José Luis Molina, IECISA Luis Alberto Amigo, Islanda José Camacho, BULL Javier Vinuales, Yaco Extremadura Walter Simonazzi, Telvent Nyílt forrású térképészeti megoldásokról beszélt.kerekasztal beszélgetés: Szabadalmak, licenszek, intellektuális tulajdonjogok Második nap Kerekasztal: A számítógépipar hosszútávú elképzelései...45 Adolfo Hernandez, SUN Michel Teyseddedre, IBM Bdale Garbee, HP Dr. Bernd Kosch, Fujitsu Siemens Omar Tazi, Open Source Evangelista, Oracle Venezuela Antonio Sajez, FON Tematikus szekció: Nyílt forráskódú üzleti modellek...47 Alexander Dymo, National University of Shipbuilding, Ukrajna...47 Carlo Daffara, Conecta, Olaszország Nyílt forráskódhoz kapcsolódó üzleti modellek fenntarthatósága / 86

6 Manon Van Leeuwen, FUNDECYT Frank van der Linden, Philips Medical Systems Bülen Özel, Istambul Bilgi Egyetem FLOSS Kompetenciaközpontok együttműködő hálózata az OSS elfogadtatása és terjesztése céljából...50 Ignacio Correas, Warp Networks Az OSS üzleti modellek természete...51 Kerekasztal beszélgetés: Technológia és a nemek kérdése nyílt forráskód esetén...51 Tematikus szekció: Rendszerfejlesztés és architektúra...51 Hector Migallón, Univ. Miguel Hernandez...51 Michael Manke, Council of Berlin Manţia András, Quanta Plus, Románia Kommander, egy segédeszköz bárki számára...52 David Santo: Kradview Pedro Jurado, spanyol KDE Freenx Imanol Tizón, Fujitsu Siemens Küldetéskritikus Linux az adatközpontokban...52 Kerekasztal beszélgetés: Szociális dilemmák, avagy: Új társadalmi modelleket építünk?...52 Francis Pisani, újságíró, El Pais Javier Bustamente, filozófus Harmadik nap Kerekasztalbeszélgetés: A guruk jövőképe Branden Robinson, Debian Bdale Garbee, HP Debian Simon Phipps, Sun Jeff Waugh, Ubuntu Linux Alan Robertson, Linux Technology Center...54 Francis Pisani, újságíró, El Pais Hírek, események negyedik negyedév Az MS licencek miatt vált Linux desktopra egy ausztrál adóhivatal...55 Két veszedelmes szabadalom vége Novell használhatósági tesztek FreeBSD logó verseny Nokia és a nyílt forráskód Öldöklő helyett egészséges verseny Kiszivárgott elemzés PostgreSQL Solarison / 86

7 Desktop Linuxok tesztje ENSZ, Microsoft és a szabad szoftverek Edubuntu Ubuntu fiataloknak Open Source az olimpián Macedónia és az Ubuntu millió soros forráskód adatbázis Nyílt forrású SPARC processzor Fejpénzek szabad szoftverekért első negyedév Francia rendőrök átállnak szabad szoftverre Nyitottabb forráskódot a szavazógépekre Brit bíró a szoftverszabadalmakról Taiwan elszakadna a Microsofttól Wikipédia plágium Szabad szoftver a NASA nál Első pillantás a Samba 4 re Egy szabad szoftveres telefonközpontról Debian és a GPLv CMS ek kiválasztása Firefoxszal biztonságosabb webet böngészni...59 Linux a harctereken Újabb védett rendszer lett védtelen Az Oracle bekeríti a MySQL t? Linux City Koreában Richard M. Stallman a GPLv3 ról Szabad szoftverek egy kisvárosban A brit vámhivatal gondja a Mozillával A brit kormány hátsóajtót tervez a Vistába Egymillió szócikk a Wikipédiában ODF Szövetség alakult Koffice felület ötletverseny A MAC OSX nehéz fél órája Nyílt forrású router BM GPFS AIX ra és Linuxra Vihar a zárt rendszerű szavazógépek körül / 86

8 Mozilla Lightning Sun GRID mindenkinek Anyagi gondok az OpenBSDnél Nyílt kormányzat megoldás Irakban BM reklámkampány az Exchange ellen Linux clusterek az ILM nél Trustix egy biztonságos disztribúció negyedév Richard M. Stalman a DRM ről és másról A Microsoft Linux laborja GNU/Linux Indiában A Linux segíti az Oracle t Koffice 1.5, ODF támogatással Hét év a DMCA val Amerikai tanácsadó cég a szabad szoftverekről A Linux szabvány új támogatói Kanadai zenészek a túlzott jogvédelem ellen Egy sikeres átállás Az ODF ISO szabvány lett Egy szabad szoftveres kiadó A Motorola és a szabad szoftverek Sun/Ubuntu szövetség Az Ubuntu ú verziója A 100 dolláros laptop első prototípusa A Dell és a GNU/Linux Alsó Szászország adóhivatala átáll Linuxra...67 Mobiltelefon gyártók szövetsége a mobil Linuxért...68 A Microsoft is Linuxot használ Belgium ODF re vált Szabad szoftveres hurrikán / 86

9 Alkalmasak e a szabad szoftverek a közigazgatási használatra, alkalmas e közigazgatásunk a szabad szoftverek használatára? Írta: Balsai Péter 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 Bevezető: 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. 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 1 Ez a legtipikusabb használat 2 Honlap a MERIT megismeréséhez: 3 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, 4 FLOSS, azaz Free/Libre/Open Source Software magyarul ingyenes/szabad/nyílt forrású szoftver 8 / 86

10 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. 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. 5 GNU/Linux, Apache stb. 6 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 (web szerver, fájl szerver, tűzfalak stb.) azok amik ezen a területen elterjedtek. 7 Az az több példányt használnak, mint amennyiért fizettek. Természetesen nem mindenhol, nem mindenkor, és nem mindenki. 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 ( 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 9 / 86

11 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: 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. 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ő: 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. 10 / 86

12 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ú licenc13 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 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 megfelel 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 szoftver választás, tudatos szoftver haszná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. 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 1.1 (MPL 1.1), 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. 1.0, W3C License, X.Net License, zlib libpng license, Zope Public License 14 Forrás: Wikipédia 11 / 86

13 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, 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 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 szoftver csomag részeként találkoznak vele. 19 A Microsoft Excel programja egy nagyon nagy tudású és viszonylag drága táblázat kezelő. Általában az emberek a Microsoft Office szoftvercsomag részeként találkoznak vele. 12 / 86

14 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 szoftver vá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 szoftver termé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ég Ez nem bíztatá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. 13 / 86

15 A szoftver fejlesztő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 szoftver fejleszté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övedelem szerzéssel, profittal és azzal a feltételezéssel összekapcsolva értelmezhető, hogy lop mindenki30. Azt a magyarázatot, hogy a fejlesztő / 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 profit maximalizálás nem alapvetően elítélendő. Pozitívan vagy negatívan értékelni a felhasznált módszert, módszerek fényében 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. 14 / 86

16 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. 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 szoftverbeszer zé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 31 Pont úgy nincs, mint azt, hogy egy vállalkozás valamilyen titokra (pl.: üzleti) hivatkozva megtagadja a tevékenységének számviteli / adó ellenőrzését. 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 15 / 86

17 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 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 (szoftver beszerzé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ény ké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, 34 Nem biztos, hogy ez a legjobb szó, de remélhetőleg kifejezi a problémát 35 Gyakran az is kielégítőnek számít, ha nem mi vagyunk, akik felelőségre vonhatók. 16 / 86

18 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 x ért eladni sokat, hiszen jobb a sűrű fillér, mint a ritka forint. A szoftver gyártó számára sem a folyamatos szoftver fejlesztés, javítás a gazdasági optimum, hanem az, ha egy szoftverállapotból minél többet elad, és ezzel minél magasabb eredményt ér el. a drágábbat kell eladni: ez azt jelenti, hogy ha egy problémára két vagy több szoftver is megoldás, és mindet ugyanaz a cég tudja szállítani, akkor érdeke a drágábbat eladni. Ez azért van így, mert a projektre fordított idő jobban megtérül a drágább esetén36, és drágább termékhez drágább kapcsolt szolgáltatás értékesíthető. márkairányos tudás: ez is egy márkahűséghez hasonló viselkedés, a képviselt termékeket ismerjük elsődlegesen, és mindent azokkal tudunk, akarunk megoldani. Elmondható, hogy egyfajta csőlátás alakul ki. projekteredményesség kényszer: nem jó, ha híre megy, hogy valami nem sikerült, valamit elrontottunk, az ügyfélnek nem megfelelőt adtunk. Ezt el kell kerülni, persze szigorúan gazdaságosan és profit maximalizálással. Az eddigi tudatosság eredménye Jelenleg, számunkra úgy tűnik, hogy az állam és a közigazgatás mind a fejlesztések, mind a beszerzések terén azt a stratégiát követi, hogy többségében zárt forráskódú termékeket vásárol és fejlesztet, lehetőleg minél nagyobb, nevesebb cégektől37. Ez a fentebb leírtak fényében mindenképpen logikus, és biztonságérzetet adó megoldás. Ezt a viselkedési mintát támasztja alá a MERIT által megjelentetett felmérés elemzése is A nem használók többnyire vonakodnak elsőként váltani a FLOSS szoftverek használatára a hasonló szervezetek közül. A legtöbb közigazgatási szervezet szeretne látni egy hasonló szervezetet, aki előttük adoptálja a FLOSS szoftvereket A másik akadály a képzés állítólagosan nagy költsége. Azonban ez csak a nem használókat nyugtalanítja; a jelenlegi felhasználók tapasztalata, akik a nem használóknál jobban 36 Egy régi projekt kapcsán kifejlesztettünk egy szoftvert, és két évvel később egy nagyobb cég felfigyelt rá. Javasolta, hogy működjünk együtt: ő értékesít, mi mondjuk meg a termék árát. Mi naivak azt mondtuk, hogy a termék ára 100 egység. Nem adott el egyetlen egyet sem a cég. Idővel egy vacsora utáni sztorizgatás közben megtudtam a dolog okát. Az illetékes kereskedő elmondta, hogy neki nem érte meg, mert túl kevés Ft járt neki egy eladás után, ezért ő nem is akarta eladni, tehát semmi energiát nem fektetett bele.( annyi pénzért nem nyitom ki a számat ) A vevők meg így persze nem tudták, hogy ez van, ezért nem is vették. A történet pikantériája, hogy cégszinten a vezetés akarta a termék forgalmazását, mert számukra üzleti előnyt (nem engednek be egy lehetséges vetélytársat egy idegen termékkel) jelentett volna az, hogy lefedik ezt az igényt azoknál a cégeknél, ahol már egyébként is jelen vannak. 37 Természetesen van kivétel, de mennyiségileg nem jellemző mondhatni a néhány hivatkozható kivétel erősíti igazán a szabályt. 17 / 86

19 értékelték az előnyöket, azt mutatja, hogy a képzés költségeitől és a támogatás hiányától való félelem jogosságát a gyakorlat nem igazolja. Gyakran felmerül az az aggály, hogy míg a licenc költségeit csökkenti a FLOSS, addig a fenntartás kiadásai növekednek, ami a költségek emelkedéséhez vezet. Ez egyébként mármint hogy a fenntartás kiadásai növekednek nem igaz, ezt a felmérés is cáfolja, de elterjedt és indokként jól használható hiedelem. A felmérésből levonhatjuk azt a következtetést, hogy az Európai Unió többi tagországának közigazgatására is jellemző a biztonsági játék ha szabad szoftverekről van szó. Annak ellenére, hogy a testreszabás fontos tényező, a helyi közigazgatási szervezeteknek csak kis része fejleszt saját szoftvert vagy járul hozzá a FLOSS projektekhez és közösségekhez. Ez a stratégia, még az egyébként meglehetősen szabadgondolkodásúnak tartott Hollandiát is jellemzi, mert bár terjed, de még ott sem történt meg a teljes FLOSS áttörés: A holland közigazgatási szervezetek 12% a olyan saját szoftvereket használ, melyek terjeszthetők FLOSS licenc alatt. Csupán a közigazgatási szervezetek 7% a tette közzé a kódot vagy alkalmaz nyílt forrású licenc alatt. Amit még tudomásul és figyelembe kell vennünk, mert együtt élünk vele Korrupció38: közéleti züllöttség olyan közszellem, melyben a vesztegetés, a dolgok elintézésének elterjedt módjává lesz, már már természetesnek tűnik. Miért kell ezt figyelembe vennünk? Mert a mi országunkban is létezik a korrupció39. Mindannyian tapasztaljuk, a médiában halljuk. Mert nem logikus feltételezni, hogy pont az informatika területén nem létezik, nem találkozunk vele. Mert a szabad szoftverek használata ezt vélelmezhetően értékben, az adott területen csökkentené, s ezzel a korrupció egyesek számára pozitív oldalából (többlet jövedelem) részesülőket alapvetően ellenérdekelté tesszük. Mert a korrupció egy lehetséges eszköz, melyet használni lehet a szabad szoftverek ellen. Az utolsó két gondolatot nézzük meg részletesen. A korrupciót a szabad szoftverek használata vélelmezhetően, értékben az adott területen csökkenti. Ez a dolog azért lehet igaz, mert a szabad szoftverek esetében nem jellemző a licenc díj, valamint ellenőrizhető pl. a fejlesztési munkára kifizetett összeg ellenértéke. Tehát egy tipikus költség 38 A meghatározás forrása: Magyar Értelmező Kéziszótár (ISBN ) Merényi Könyvkiadó Kft 39 Hazánk 2004 ben az EU tag államok között a legkorruptabbak közé sorolódott a TI besorolás szerinti 42. helyével (forrás: Legáltalánosabb definíció szerint a korrupció közhatalommal való visszaélést jelent privát haszonszerzés céljából. Bővebben lásd a függelékben. 18 / 86

20 eltűnik a képből, ezáltal az elköltött összeg csökken, márpedig az belátható, hogy valami x összeg 10% nál valami y x nél kisebb összeg 10% a az kisebb. Kevesebből pedig kevesebbet lehet költeni, tehát kevesebb fordítható korrumpálásra is. Ráadásul, amennyiben a szabad szoftverekre jellemző módon a fejlesztéseknél a forráskód nyilvánosságra, de legalább a megrendelőhöz kerül, ellenőrizhetőbbé válik az ár/érték arány. A korrupció egy lehetséges eszköz, melyet használni lehet a szabad szoftverek ellen. Ez azért lehet igaz, mert pl. a jelenleg legelterjedtebb operációs rendszer és irodai alkalmazás csomag gyártójának és partnereinek magyarországi kereskedői eredményességét is az összegszerű eredménnyel (esetleg piaci részesedéssel) mérik. Ez pedig egyértelműen elegendő indíttatás a korrumpálásra. Hiszen létrejön az a korrupciós helyzet, melynek megértéséhez a moralitást, az etikát, a valláserkölcsöt kell kiindulási alapnak tekintenünk. Ez pedig azt jelenti, hogy pénzmegta karítással elérhető kitűzött cél, mely valójában a KÖZJÓ, indukálja a korrupciót, mely mindenképpen " KÖZROSSZ ", de egyben megkérdőjelezhetetlenül, "MAGÁNJÓ" is, hiszen a kereskedő és az őt alkalmazó cég szempontjából a megvalósuló KÖZJÓ az a "MAGÁNROSSZ". Természetesen lesznek olyan cégek (kereskedők) akik a monopol helyzetben levő világcég és partnerei visszábbszorulása kapcsán juthatnak, jutnak piachoz. Ám ezek jelenleg, bár saját szintjükön vélhetően szintén korrumpálnak valamilyen mértékben, korrumpálási képességükben messze gyengébbek a jelenlegi monopóliumnál és annak képviselőinél. Ez pedig azt jelenti, hogy ezen a területen nem tudnak a monopóliummal érdemben harcba szállni. 19 / 86