Na, a tegnapi első reakció után íme egy bővített, talán átgondoltabb verzió. Ezt most kivételesen továbbkattintósra csináltam meg, mert hosszú és biztos sokaknak unalmas. Hát ez nem jött össze.

Szívesen fogadok bármilyen észrevételt. Ha valaki tudna okosat írni a szabadalom részhez (vagy máshova), az tök jó lenne, nyílván társszerzésben lehetne gondolkozni. Aztán ha (egyszer talán) kész lesz, elküldöm a JF-nak. A határidő talán jövő hét vége - mondjuk hét közben annyira nincs idő ilyesmire.

Kevesen vitatják, hogy az informatikai infrastruktúra és az azt vezérlő szoftverek gazdasági jelentősége kiemelkedő. Közvetlen hatásuk mellett minden bizonnyal jelentős – és mérhetetlen – az ún. 'because of' hatás, azaz az olyan fejlemények, amelyek az IT létéből következnek, de statisztikai vagy egyéb módszerekkel nehezen köthetőek az ICT-hez.

A Szerző az egyáltalán nem új témát egy eleddig magyarul elvétve – ha egyáltalán – tárgyalt témakörrel szinesíti, az Egyesült Államok területén érvényes szerzői és szabadalmi jog bemutatásával a szoftverek vonatkozásában, belelértve a bírói gyakorlatot is.

A Szerző a számítógépi programalkotás (a továbbiakban szoftver) lehetséges fogalmi meghatározásaival indít, és korrekten felmutatja mind a magyar, mind az amerikai, mind a nemzetközi joforrásokban szereplő fogalmakat.

Ugyanakkor némileg bizonytalanság érezhető a forráskód és gépi kód közötti elhatárolás során, hiszen a forráskód és a tárgykód azonos, pusztán más megjelenési formában jelentkezik. Az, ami a szoftver kapcsán dinamikusan megjelenik, leginkább is adat, amely kategória sajnos a jogi szoftverfogalmak vázolása során gyakran elsikkad, bár a szoftvertől való elhatárolása gyakran problémás, szemben a hardverrel.. Pedig ennek jogi következményei is vannak, hiszen a szoftver és (például) az irodalmi mű védelme nem tökéletesen egyező. Említésre méltó még, hogy a Szerző által hivatkozott forrás¹ bár – úgy tűnik – némileg bonyolultan de kétségkívül helyesen állapítja meg: a forráskód és a gépi kód közötti kapcsolat a fordítás: “A forrásprogramból fordítóprogram (compiler) segítségével automatikusan gépi programmá alakul, ami nem más, mint a tárgyi program, ami képes arra, hogy a computer működését irányítsa a felhasználó utasításainak megfelelően”² De ez kétségkívül azt jelenti, hogy a forráskód és a gépi kód tartalmilag azonos, és a megfelelő fordítóprogram segítségével előállítható a forráskódból a tárgyi kód.

Az amerikai esetjog megítélését Recenzens nemcsak, hogy nem tudja elvégezni, de számára is rendkívül érdekes olvasmány volt.

A “Számítógépi programalkotások szerzői jogi védelme az Európai Unióban” c. fejezet központi szerepet kap a dolgozatban és Szerző ismét jogtörténeti szempontból közelíti a kérdést. Ugyanakkor a gondolatmenet nem fokuszált, többször elkalandozik. Az Európai Szabadalmi Hivatal (EPO) előhozása pedig rendkívül problémás, hiszen sem nem szerzői jogi sem nem úniós intezményről van szó (az Európai Szabadalmi Konvenció hozta létre (EPC) ³), majd pedig a számítógéppel megvalósított találmányok szabadalmi védettségéről szóló irányelvtervezet is előkerül. Olyan meg nem alapozott kijelentések szerepelnek, mint “Számos olyan vonással rendelkezik, ami

indokolttá tette volna, hogy szabadalmi védelem alá essen.”⁴ Továbbá nem mellékes az sem, hogy az EPO-nak a számítógéppel megvalósított találmányokkal kapcsolatos gyakorlatát nevezhetjük contra legemnek is, amely kimondottan az EPC Art 52. (2).-(3).-ba ütközik, amennyiben a szoftver valósítja meg az újító lépést. Ugyanakkor Recenzens nem kíván állást foglalni ebben a kérdésben. Szerzőnek problémát okoz a firmware fogalma is, amely körét túl szűken húzza meg, kizárva például a flash memóriában tárolt, optikai lemezmeghajtókat vezérlő drivereket.

Penetráns hibának kell tekintenünk, amikor a magyar szerzői jogi törvény (1999. évi LXXVI tv. a szerzői jogról) szabályozási technikáját pusztán példálózó felsorolásnak minősíti, miközben az 1. § (1).-(2). kifejezetten a következőt mondja:

“(1) Ez a törvény védi az irodalmi, tudományos és művészeti alkotásokat.

(2) Szerzői jogi védelem alá tartozik - függetlenül attól, hogy e törvény megnevezi-e - az irodalom, a tudomány és a művészet minden alkotása.”,

amelyet valóban egy exemplikatív felsorolás követ. Szerző túlzottan leegyszerűsíti az ideiglenes tárolás kérdését, amely nemcsak a Random Access Memoryban valósul meg, és az sem törlődik minden esetben a számítógép kikapcsolásakor. Az irányelv és a magyar törvény összevetése egyébként Recenzens véleménye szerint a továbbiakban kellően pontos.

Azonban ezt követi a dolgozat értékét alapjaiban megkérdőjelező másfél oldalas átvezetésnek szánt szöveg a szerzői jogi és a szabadalmi oltalom témák között. Sajnos Recenzens az ebben szereplő hibák és tévedések miatt kénytelen hosszabb terjedelemben foglalkozni az itt felvetett kérdésekkel.

Teljesen hiányzik az elméleti megalapozása a szabadalmi és a szerzői jogi védettségnek, illetve az ezek között meghúzódó eltérések kiemelése. Röviden az alábbiról lenne szó:

Egyfelől a szabadalmi védettség olyan, tipikusan országhoz esetleg országok egy csoportjához kötődő védettség, amely megadása egy – elméletileg leglábbis – gondos vizsgálathoz kötött, amely eredetkutatáson kívül magában foglalja a szabadalmazhatóság alapfeltételeit: alapuljon a találmány feltalálói lépésen, legyen új és iparilag alkalmazható⁵, továbbá legyen technikai karakterű. A TRIPS szerződés egyenértékűnek ismeri el a 'feltalálói lépés' kifejezést a 'nem nyilvánvaló' (non-obvious), az ipari alkalmazhatóságot pedig a hasznossággal (usefulness). Ezek után a mindenkori szabadalmas gyakorlatilag monopóliummal bír a szabadalom lejárásáig. Említésre méltó továbbá, hogy a szabadalmak nyilvánosak.

Másfelől a szerzői jog regisztrációtól mentes védelmet kínál irodalmi, tudományos és művészeti alkotásokra, feltéve, hogy ezek kielégítik az eredetiség követelményét. Ugyanakkor nincs szükség a mű publikálására, és jellemző a kölcsönös elismerés a művek tekintetében. Mindezek mellett a szerzői jog a másolás, terjesztés szabályozásán alapul.

De mi is ezeknek a jelentősége a szoftverekkel kapcsolatosan?

Előre kell bocsátani, hogy a Recenzens egyáltalán nem tartja magát a szabadalmak bármiféle szakértőjének. De nyilvánvalóan meg kell vizsgálnunk némileg a szoftverszabadalmak természetét.

A szoftverek esetén a szabadalom nem (csak) a kódot védi (a szerzői jog azt), hanem az igénypontokban rögzített funkciót, vagyis amit a program csinál. Így egy program általában több szabadalom védelmét élvezi, és egy szabadalom több programra vonatkozik. Vagyis a szabadalom által adott monopólium egy bizonyos tevékenység ellátására irányul, amit természetesen többféle szoftverrel is meg lehet csinálni. Kiváló példája ennek az ún. egyklikkes vásárlás. Nem lehet kétséges, hogy számtalan programmal meg lehet valósítani ezt, de az első gyakorlatilag monopóliumot, vagy legalább is vámszedési jogot kapott erre a tevékenységre. Mellesleg kiváló példája, hogy hová vezet a szabadalom feltételei küszöbének leszállítása, de ez nem tartozik szorosan a tárgyhoz.

Eközben a szerzői jog más módon operál. A szerzői jog szerint teljesen legális a 'párhuzamos feltalálás', azaz amikor többen hoznak létre külön-külön tevékenységgel műveket, amelyek rendkívül hasonlítanak ad absurdum teljesen egyezőek. Nem is beszélve az azonos szerepet ellátó programok alkotásáról.

Szerző felhoz egynéhány érvet a szoftverszabadalmak ellen, de ezek közül egy érdemel igazán figyelmet: ez pedig a párhuzamos fejlesztések esete. Felveti, hogy csak az először elkészült fejlesztést védené a szabadalom, és ez igaz. Ugyanakkor ennek a következményei Recenzens szerint a következőek lennének leginkább: a minnél előbbi szabadalmazás miatti félkész programok, továbbá a monopolista helyzetből adódó lassú programjavítások, valamint a monopólium extraprofitja, amely leginkább is a verseny hiányából származna. Vagyis a szoftverek drágábbak lennének és rosszabbak.

Szerző a szoftverszabadalmak legfőbb ellenségét az ún. “open source társadalom”-ban véli megtalálni, amit a következőképpen definiál:

“Az open source nem jelent mást, mint nyílt kód. Az open source társadalmat olyan programozók ezrei adják, akik azt tűzték ki célul, hogy megalkotnak egy olyan operációs rendszert, amely nyílt forráskódú, azaz, ingyen hozzáférhető bárki számára. Azáltal hogy a rendszer forráskódja mindenki számára ismert lenne, véleményük szerint a szoftvergyártók is sokkal gyorsabban, kisebb költségvetéssel tudnának programokat előállítani, mivel nem jelentene többé problémát, hogy megteremtsék az interoperabilitást a programjuk, valamint a felhasználó által használt zárt kódú operációs rendszer között. Ez a programok előállítási költségét radikálisan leszorítaná. Egy esetleges szabadalom ezt az elképzelést sodorná veszélybe sokak szerint.”

Természetesen ez az elképzelés teljesen téves. Mivel Recenzensnek egyéb elfoglaltságai is vannak, ezért idemásolja a szakdolgozatának egy darabját:

IV.1 Definíciós és terminológiai problémák

Azon szoftverek körének meghatározása, amelyek az úgynevezett jogfenntartott (proprietary) szoftverekhez képest valami többet adnak a felhasználók és az esetleges fejlesztők számára, nem egyszerű feladat alapvetően két ok miatt. A dolog gyökerei az angol nyelv azon jellemzőjében lelhetőek fel, hogy pusztán a tartalmi környezet által eldönthető módón ugyanaz a szó jelöli a szabad és az ingyenes mellékneveket. A 'free' szó használata a szoftverekkel kapcsolatban pedig széles körű ellenállásba ütközött: végül is az esetek jelentős részében nem szabadidős tevékenység eredményei, legalább is ami a jelentősebb, hosszabb alkalmazásokat illeti. Az üzleti alkalmazásukat is meglehetősen hátrányosan érinthette. Ennek elkerülése érdekében került sor a nyílt forráskódú szoftverek elnevezés bevezetésére, amelynek idejéről megoszlanak a vélemények¹. Mindenesetre mára a nyílt forráskódú szoftver elnevezés tekinthető az általánosabbnak, mindemellett a kettőt gyakran szinonim elnevezésként használják, és kevesen utasítják el ezt a dualizmust. A dolgozat is e mellett kötelezi el magát.

Ezt követően voltak és vannak kísérletek a duális elnevezés feloldására, elsősorban a két terminológia összeházasításával, ám ezek nem igazán nyertek széleskörű elfogadottságot. Olyan próbálkozásokat sorolhatunk ide, mint a Free/Open Source Software, a Free/Libre/Open Source Software, és társaik.

A fenti problémából származik az a kérdés, hogy vannak-e a nyílt forráskódú szoftvereknek megkülönböztető jegyei a forráskód nyíltságán túl. Létrejöttek ugyanis olyan szituációk, amikor a forráskód ugyan hozzáférhető volt, de az úgynevezett négy szabadság (a forráskód megismerése, és általában a program működésének teljes körű tanulmányozása, a megváltoztatás, a terjesztés, a változatok terjesztése és természetesen a bármilyen célból történő futtatása) nem vagy nem teljes egészében érvényesült. Erre példa lehet a Sun Microsystem Solaris szerver operációs rendszerének shared source (megosztott forrású) licencváltozata, egészen a Solaris⁶ 10 verzióig (OpenSolaris), amikortól is a négy szabadság teljes mértékben érvényesül. Tipikusan megkülönbözető elnevezéseket használnak az ilyen programok sajátosságainak jelzésére. Másik vonásuk az instabilitás: általában nem jellemző, hogy a jogfenntartott és a nyílt forráskódú szoftverek között stabil köztes megoldások léteznének. Szintén alátámasztja ezt a Caldera⁷ Linux disztribúció kudarca.

További kérdés, hogy elfogadható-e bármiféle korlátozása a négy szabadságnak. A Free Software Foundation gondot fordít rá, hogy összeállítsa a nyílt vagy nyíltnak nevezett licencek lehető legteljesebb listáját², és értékelje azokat a nyíltság szerint, általában mindenféle kompromisszumot elutasítva. Felvethető ugyanakkor, nem túlzott-e egy licenc elutasítása pusztán azon az alapon, hogy a program eredeti szerzője értesítést kér az esetleges változásokról emailben³. Véleményünk szerint a négy szabadság érvényesülése esetén inkább gyakorlatiasan, semmint dogmatikusan kell eljárni, különös tekintettel arra, hogy egy egyszerű és költségtakarékos értesítési megoldás (nem engedély!) mennyiben tekinthető korlátozó tényezőnek. Így inkább az egyedi esetekben kell megvizsgálni, jelent-e valódi korlátot a licencek sajátos feltétele. Mindesetre az FSF gyűjteménye alapvetően megbízható. Az Open Source Initiative szintén fenntartja az OSD-vel kompatíbilis licencek listáját.

A fentiek alapján tehát elmondhatjuk, hogy a nyílt forráskódú szoftverek körébe azon szoftverek tartoznak bele, amelyek esetében a forráskód hozzáférhető a felhasználó számára, és a négy szabadság is érvényesül, függetlenül attól, hogy nyílt forráskódú vagy szabad szoftvernek hívjuk-e. Ezt a csoportot – mint majd látni fogjuk – két elkülönülő csoport alkotja, amelynek jogi konzekvenciája is kellene, hogy legyen.

Említést érdemel még a copyleft is, mint a copyright módszereinek felhasználása a szoftver és módosításai hozzáférhetőségének megtartására. A copyleft nem engedélyezi, hogy egy eredetileg szabad szoftver a hozzáírt módosítások után klasszikus jogfenntartottá váljék, hanem arra kényszeríti a copyleftes szoftverhez író programozót, hogy saját módosítását – ha egyáltalán nyilvánosságra hozza – az eredeti feltételekkel tegye hozzáférhetővé: a forráskód megismerhetősége, a terjesztés, a megváltoztatás, a változat terjesztése nem válhat tiltottá. Megjegyzendő, hogy a copyleft a copyright szabályainak felhasználásával él. A GPL egyértelműen a copyleft módszerével él, ezért is hasonlították fertőzéshez⁸, netán egyenesen rákhoz⁹. A copyleft alatt lényegében arról van szó, hogy a származékos műveket nem lehet az eredeti mű licencétől eltérő feltételekkel közzétenni.

Az Open Source Initiative további feltételeket határoz meg, amelyeket egy nyílt forráskódú szoftvernek teljesítenie kell, mégpedig a szerzőnek a kód integritásához való jogát, a diszkrimináció tilalmát, érintse bár a felhasználó személyét, felhasználók egy csoportját, vagy a felhasználás területét. A licenceknek ezen kívül nem szabad csak egy termékre érvényesnek lenniük, nem korlátozhatják az egyéb szoftverek használatát, és technológiasemlegesnek kell lenniük. Az Open Source Definitionnak megfelelő szoftverlicencek listáját az Open Source Initiative vezeti.

A nyílt forráskódú szoftverek története egyidős a szoftverek történetével, lévén eredetileg az összes szoftver nyílt forráskódú volt. A forráskód zárttá válása összekapcsolódik az önálló szoftverpiac, a szoftver, mint önálló termék megjelenésével. Azonban nem mindenki tartja ezt pozitív változásnak. Richard F. Stallman, a LISP visszafejtője ennek ellensúlyozására, és a szoftver forráskódjának hozzáférhetősége visszaállítása érdekében elindította a GNU projektet 1981-ben és megalapították a Free Software Foundationt 1985-ben.

Egy másik fontos év 1998 a nyílt forráskódú szoftver történetében. 1998-ban a Netscape ugyanis nyilvánosságra hozta a korábbi Netscape Navigator¹⁰, a korábban piacvezető, ám addigra igencsak teret veszített böngészőjének a forráskódját. Ennek előzményeként keresett néhány ember, közöttük Bruce Perens és Eric Raymond, egy nevet, amelyet az új szoftvermozgalmuknak adhatnak, de nem ijeszti el azonnal az összes üzleti felhasználót. És megszületett az Open Source Software.

....

IV.4. A nyílt forráskódú szoftverek két világa: a „megaprojektek” és a milliónyi kis alkalmazás

A nyílt forráskódú programok legalább két markánsan eltérő csoportját határozhatjuk meg: egyrészt az általában egyedi szervezeti és hierarchikus továbbá jogi megoldásokat felvonultató „megaprojektek” világát, másrészt a leginkább a Sourceforge hálózaton csoportosuló, általában kevés szerző által készített kisebb programok körét, amelyek ugyanakkor gyakran épülnek más, korábbi programokra, kódalapra¹¹.

A nagy programok körébe tipikusan olyan szoftverek sorolhatóak, mint a Linux kernel, az Eclipse¹², az Openoffice, a Mozzila Firefox¹³ és Thunderbird¹⁴, a MySQL¹⁵, az Apache¹⁶, az OpenSolaris¹⁷. Ezeket sajátos, külön hierarchiájuk, infrastruktúrájuk, etc., és nagyobb résztvevő közösségük különbözteti meg. Gyakori, hogy alapítvány áll mögöttük, amely a fejlesztés koordinálására főállású alkalmazottakat foglalkoztat¹⁸, de van rá példa, hogy egy cég karolja fel valamely programot, vagy éppen teszi nyílt forráskódúvá korábban jogfenntartott szoftverét¹⁹. Gyakori a kötődő merchandise-ok forgalmazása, előfordul mozgalmi jelképpé válásuk, tipikus az adománygyűjtés.

Ezzel szemben a Sourceforge²⁰ hálózat, amely világszerte megtalálható szerverekből áll, tipikusan kisebb, specializáltabb szoftverek tárhelye, amelyek mögött nem áll saját infrastruktúra. Ezek gyakran a programozók pillanatnyi problémáinak megoldására készültek és egyébként sem várható, hogy valaha is komoly üzleti hasznot hozzanak szerzőjük számára. Emiatt a szerző számára nem ’éri meg’ klasszikus jogfenntartott terjesztésük, nyilvánosságra hozásukkal azonban bizonyos presztízshez, hírnévhez, elismeréshez juthatnak, azaz gyakorlatilag sokszor hobbitevékenység eredeteképpen jönnek létre. És amennyiben nem is válik elterjedté a szoftver, az, hogy hozzáférhető mind gépi, mind forráskódú verziójuk (vagy a forráskód és a fordítóprogram), gyakorlatilag bármennyi idő elteltével felhasználhatóvá teszi őket. Olyan, később jelentősebbé vált alkalmazások is ide sorolhatóak, mint a Bittorrent vagy a legnépszerűbb kliense, az Azureus. Általában 1-2 együttműködő, ismerős szerző ’követi el’ ezeket a műveket, és tipikusan jellemző a folyamatos evolúciójuk.

IV.5. A nyílt forráskódú szoftverek jellemzői: a közösség, a fejlesztés módja, összevetés a jogfenntartott szoftverekkel

A nyílt forráskódú szoftverek esetén sokkal kevésbé kötött a fejlesztők köre, mint a jogfenntartott szoftvereknél. Gyakorlatilag egy potenciálisan folyamatosan változó, viszonylag kevéssé formalizált kör járulhat hozzá egy-egy szoftver megszületéséhez. Ez magában foglalja, hogy senkit sem lehet kizárni, és bármikor bekövetkezhet, hogy, mint egy fa, elágazik az addig egységes projekt. Korábbi verziókból, módosításokból új, bár persze hasonló szoftver születhet. Ugyanakkor semmiképpen sem lehet biztosra venni az eredményt, hiszen a motivációs rendszere általában gyengébb a nyílt forráskódú szoftvernek, közvetlen anyagi érdekeltség híján, különösen, hogy a motiváció központi eleme – a hírnév – éppen a termék sikerének függvénye. Ez eredményezi azonban a fejlesztés költségeinek alacsonyabb voltát is. Megfelelő fejlesztői közösség kialakulása esetén azonban – a tapasztalatok szerint – ez a bizonytalanság kiegyenlítődik. Tipikus egy belső – hardcore – kódot író csoport és egy külső, elsősorban a hibák felismerésében részt vevő csoport kialakulása.

A nyílt forráskódú szoftverek életében gyakorlatilag általánosnak mondható egy stabil, használatra szánt verzió léte mellett egy fejlesztői, a legújabb funkciókat is tartalmazó verzió léte, amely használata elsősorban debugging céllal javasolt. Így folyamatosan létezik egy fejlesztői és egy stabil, használatra szánt verzió, és ki-ki maga dönti el, melyiket használja. Ez némileg eltér a jogfenntartott szoftverek formalizáltabb életciklusától, az alfa-béta-release candidate-release to manufacture verziók fémjelezte ciklustól, félúton áll a web2.0 alkalmazta állandó béta és a hagyományos életút között.

A nyílt forráskódú szoftvernek eredendő gyengesége az, hogy nincs a hagyományos értelemben vett gazdája. Ez nemcsak a közvetlen felelősséget vállaló üzleti partner hiányéban mutatkozik meg, hanem tipikusan a folyamatos terméktámogatás, javítások elérhetőségét, a termékhez elérhető dokumentáció, képzések, tananyagok beszerzésének a nehézkességében is. Nem utolsó sorban, a jogi kockázatokat sem viseli senki. Természetesen egyes termékeknél éppen ebben rejlik az üzleti lehetőség, a jó minőségű terméktámogatás, mint szolgáltatás, netán jogi biztosítás nyújtásában. Nem mellékesen a jogfenntartott szoftverek is tipikusan legföljebb a kifizetett összeg erejéig vállalnak garanciát, legalábbis az EULA-k esetében, de magára a szoftver működésére nem.

A nyílt forráskódú szoftver hátrányai igazán akkor válhatnak előnnyé, amennyiben szakértő felhasználók kezébe kerülnek. Az alkalmazások módosíthatósága, testreszabhatósága, lokalizációs lehetőségei páratlanok, éppen a forráskód módosíthatósága miatt. A terméktámogatás hosszabb ideig elérhető, és gyakran több különböző forrásból, nincs olyan erős beszállítói függés, és végső soron maga a felhasználó is megoldhatja közvetlenül. Elkerülhetőek a kötelező upgrade-ciklusok (amik tipikusan komoly hardverberuházással is járnak). Azonban ez pusztán lehetőség: bizonyos feltételek teljesülése, mint például gazdasági méret szükségesek a kiaknázásukhoz.

Paradox módon azokban az esetekben is hátrány – lenne – a forráskód hozzáférhetősége, amikor az egyes szoftverekkel megvalósított technikai védőintézkedések – illegális – megkerüléséről van szó. Ugyanis az, hogy a forráskód nem ismert, nehezebbé teszi a biztonsági szoftverek, megoldások készítőinek, hogy termékeiket javítva kizárjanak korábban lehetséges megkerülési módokat.

IV.6. A nyílt forráskódú szoftverek és üzlet

A szabad szoftver mozgalom és a nyílt forráskódú szoftverek közötti különbség kulcskérdése az üzleti alkalmazás köre volt. A nyílt forrású szoftverekkel ugyanis, a szabadságokból kifolyólag nem lehet a klasszikus licenc-eladási gyakorlatra alapozott gazdasági tevékenységet folytatni. A kialakult üzleti gyakorlat tehát az ingyenes szoftverjuttatás – beleértve a forráskód legalábbis elérhetővé tételét is – mellé ellenszolgáltatásért nyújtott support, terméktámogatás. Ez vált a legtöbb Linux disztribúció mögött álló cég üzleti stratégiájává, olyanoké, mint a Redhat, a Suse vagy a Mandriva. Sajátos megoldás a kettős licencia (ún. dual licence-k) esete, amikor elérhető a program szabad licenc alatt, valamint üzleti felhasználók részére, terméktámogatással összekötve más licenc alatt is. Ez jellemző például a MySQL-re. Fő előnye a szoftver alacsony költsége, amely szerverfarmok esetén nem elhanyagolható szempont.

A szabad szoftverek üzleti alkalmazásának az utóbbi időben megfigyelhetőek újabb megoldásai is, amelyek azon alapulnak, hogy a hálózaton, szoftverek felhasználásával nyújtott szolgáltatások esetén nincs jelentősége a szoftverek „árának”, az beépül a komplex szolgáltatáscsomagba. Ez az ún. Software-as-a-Service egyik alfajtája, amikor a licenc és a használati díjak nem különülnek el, és tipikusan komplex hardware-software-network szolgáltatásról van szó.

A fentiek ellenére nem beszélhetünk a nyílt forráskódú szoftverek dominanciájáról. Ez egyrészt magyarázható a szükséges technikai tudás hiányával, amely ilyen programok elfogadható üzemeltetéséhez szükséges, és leginkább is asztali számítógépek esetében gyakran hiányzik, másrészt bizonyos területeken nincs is nyílt forrású alternatíva. A könnyű használhatóság, user-friendly-ség sem tartozik a nyílt forráskódú szoftver előnyei közé. Tipikusan gyenge a komoly grafikai-zenei tartalmat magába foglaló játékszoftverek körében.

A nyílt forráskódú szoftverek a tapasztalatok szerint leginkább is a szoftverek piacának olyan szegmenseibe tudtak megkapaszkodni, ahol komoly verseny nélkül egy termék volt a meghatározó, illetve amelyek gyakorlatilag túl kicsik egy komolyabb üzleti környezet eltartásához, netán egyáltalán nem profitorientáltak. A felhasználók informatikai szakismeretének magas szintje szintén kedvez általában a nyílt szoftverek elterjedésének.

Mindezek ellenére a nyílt forráskódú szoftverek felhasználásának komolyabb terepe az oktatás, valamint a fejlődő országok informatikai infrastruktúrájának kiépítése során jellemző, ahol a közvetlen licencdíjnak nagyobb szerepe van.

...

A nyílt forráskódú szoftverkészítő cégek egyébként szívesen halmoznak fel maguk is szabadalmat (bár Recenzens nem tud olyan esetről, amikor offenzíven használták volna). Elmondhatja magáról a Red Hat, a Novell, a Sun Microsystems vagy az IBM, akik mind többé-kevésbé érintettek a nyílt forráskódú szoftverek témájában, miközben egyiküknek sem deklarált célja egy nyílt forráskódú operációs rendszer előállítása. Például azért, mert már van ilyen, a különböző Linux disztribúciók, vagy az OpenSolaris. A szoftverszabadalmak leginkább az egyéni fejlesztőket, illetve hobbyprogramozókat, kis- és középvállalkozásokat hoznák nehéz helyzetbe. Az interoperabilitással ugyanakkor azonos kernelt használó Linux-disztribúciók sem rendelkeznek egymás vonatkozásában.

Szerzőnek meggyőződése, hogy a szabadalmak melletti legfőbb érv, hogy serkenti az innovációt, amely állítással ugyancsak vitatkoznunk kell, különösen, hogy semmiféle lábjegyzeti hivatkozással ez alátámasztva nincsen.

Egy megelőző kérdés, hogy hogyan definiáljuk az innovációt, amely gyakorlatilag egy országos problémának nevezhető. Szerző erre javaslatot nem tesz. Recenzens a következőt ajánlja: innováció=K+F és ipari alkalmazás. Ez az egyszerű megoldás alkalmas arra, hogy a fejlesztések mellett azok bevezetését is inkorporálja az innováció fogalmába.

Sajnos azonban ezzel még nincsen megoldva az innováció mérésének a problémája. Erre Recenzens semmiféle objektív mértéket nem tud felajánlani, különösen hogy a schumpeteri kreatív pusztítás elmélete alapján a gazdasági növekedés jelentős eltéréseket rejhet, és így ez még hozzávetőlegesen sem alkalmas az innovativitás mérésére.

Felmerülhet, hogy a szabadalmak számát használjuk fel mérőszámként, ámde ez ördögi körhöz vezet, hiszen ezt legegyszerűbb jogi eszközökkel növelni (vagyis a szabadalmazhatóság korlátait enyhíteni, az üzleti cégek megbízhatóan hajlandóak monpóliumokat kialakítani), illetve a szabadalmak bevezetésére semmiképpen nem jó érv,

“A szerzői jog védelemben részesült programok fejlesztői a technikai részleteket, fejlesztéseket titokban tartják, ezáltal a kisebb fejlesztő cégeknek az alapoktól kell kezdeniük minden egyes program megírását, mivel nem ismerik a más, nagyobb fejlesztő cégek által elért esetleges technikai újításokat. A szabadalom ezt az egyenlőtlenséget szüntetné meg azáltal, hogy számos programozási eredmény, módszer kerülne nyilvánosságra, amelyet mások további szabadalmak megalkotására használhatnának fel.”,

írja a Szerző. Ugyanakkor itt válik az elképzelés irrealitása nyilvánvalóvá: Szerző álláspontja nem egyértelmű abban a kérdésben, hogy a szerzői jogi védelem mellett vagy a helyett képzeli el a szabadalmi oltalom bevezetését.. Ennek jelen pillanatban semmiféle realitása nincsen, és az Egyesült Államokban sem történt meg. Mert ennek hiányában a forráskód megismerése és felhasználása (a “technikai újítások”) jogsértő. A szoftverek írásának technológiája pedig nem sokat változott az 1980-as évek óta, vagyis ilyen rejtett programozási eredmények, módszerek nemigen léteznek.

Ezen felül nyilvánvaló, hogy Szerző nincsen tisztában az amerikai szabadalmi rendszer legújabb fejleményeivel²¹. Némileg szórakoztató, hogy éppen a közösség bevonásával (kvázi open source módszerekkel) kívánja az amerikai szabadlmi rendszer javulását elérni az USPTO²².

Minezek után azonban ismét az ameikai esetjog leírása következik, és itt Recenzens csak ismételni tudja a korábban elmondottakat: minden bizonnyal nóvum a témáról magyar nyelven összefoglalót olvasni. Sajnálatos, hogy a legújabb szoftvrerszabadalmi események hiányoznak, mint például a Microsoft két veresége²³ (az egyiket a Supreme Court megváltoztatta).

A következő fejezet az EPO szoftverszabadalmi irányvonalának alakulását ismerteti, amely minden bizonnyal pontos, ugyanakkor nem tekinthető objektívnek, hiszen egy lehetséges contra legem gyakorlatról van szó, a puszta lehetőség felvetése nékül. Az EPO számítógéppel megvalósított találmánya egy jogi fogalom, ami a USPTO, az EPO és a JPTO egy 2000-es találkozásának dokumentuma 6. mellékletében jelent meg²⁴, vagyis maga az EPC nem is ismeri. 2002-re az EPO-nak sikerült több tízezer ilyen szabadalmat elfogadtatnia.

Szerző ezután az EU direktívatervezetére tér rá, amely elfogadására a Parlament és a Bizottság egyetértésének hiánya miatt nem került sor. A szerző helyesen állapítja meg, hogy az irányelv nem tartalmazott volna mást, mint az EPO gyakorlatának szentesítését, amely ugyanakkor egy erősen aggályos és az EPC-től eltérő gyakorlatot kívánt volna adoptálni azt jogharmonizációnak, jogegységesítésnek álcázva. Ugyanakkor szerző ismét az innováció, illetve a verseny serkentését várta volna az irányelvtől, sajnos továbbra sem megalapozva ezen vélekedését. Szerző sajnos az irányelv kialakítását, és majdem elfogadásának háttér(lobby)történetét sem rögzíti, pedig az rendkívül tanulságos. Szerző az összegzésben jól mutat rá, hogy a szoftverek felhasználásukat illetően sok szempontból közelebb állnak az ipari termékekhez, mint az irodalmi művekhez, ám a szoftverek jogi szabályozását gyerekcipőben járónak minősíteni irreális.

Ami kimaradt, pedig szerepelnie kellett volna:

1. Szerző nem teszi nyilvánvalóvá, hogy az alternatívák nem a szerzői jog vagy a szabadalmi jog, hanem a szerzői jog, vagy a szerzői jog ÉS szabadalmi jog.

2. Az amerikai gyakorlat legújabb, igencsak aggasztó fejleményei, például az ún. Patent Trollok²⁵ megjelenése, vagy a tömeges keresztlicencelési gyakorlat a szoftverszabadalmakat illetően.