Egyszer volt, hol nem volt, volt egyszer egy okos leány, akinek a király megizente, hogy menjen el a leány őhozzá, de menjen is meg ne is, köszönjön is meg ne is, s vigyen is ajándékot meg ne is. És a leány ment is, meg nem is, köszönt is, meg nem is, vitt is ajándékot, meg nem is.1
Ilyen persze - ha jobban belegondolunk - csak a mesében létezik…
Bill Gates harmincöt évvel ezelőtti felvetése tehát, hogy hogyan "engedheti meg valaki magának, hogy professzionális munkát végezzen anélkül, hogy azért díjat kér", egyáltalán nem meglepő. Mert "ki az, aki pusztán kedvtelésből három évig fejleszt egy szoftvert, kijavítja valamennyi hibáját, dokumentációt készít a termékhez, és mindezt ingyen terjeszti?"2 Korunk kommentátorai szerint, ha módjában állna "Gates ma ki nem mondottá tenné a szavait, hisz a nyílt forráskódú mozgalom bebizonyította, hogy igenis lehet valamit úgy ingyen adni, hogy közben pénzt csinálunk belőle. A trükk mindössze annyi, hogy azoknak kell ingyen adni, akik úgysem fizetnének érte, és azoktól kell pénzt kérni, akik hajlandóak költeni."3
A nyílt forráskódú szoftverek értékesítésére kialakított üzleti modellek pontosan abban állnak, hogy a megfelelő ajánlattal kell megtalálni azokat, akik hajlandóak fizetni. Persze fizetni ők is csak akkor hajlandóak, ha az ingyenesen, szinte korlátlanul elérhető javak olyan értékkel egészülnek ki, mely "megéri a pénzüket". A szabad szoftvert díjért terjesztőknek tehát azt kellett kitalálni, hogyan lehet díjat kérni azért, ami ingyenes. Vagyis hogyan lehet menni is, meg nem is, köszönni is, meg nem is, vinni is ajándékot, meg nem is…
És ilyen nem csak a mesében van!
A szabad szoftver mozgalom atyjának tartott Richard Stallman sem tagadja, hogy a hackereknek4 is jogukban áll pénzt keresni, azonban ezt azzal együtt érti, hogy a szabad szoftverre vonatkozó alapelvek és eszmeiség sérülnének.5 A Free Software Foundation6 álláspontja szerint ugyanis a szabad szoftver felhasználója jogosult közzétenni a program másolatait, akár módosításokkal, akár eredeti formájukban, akár ingyen, akár pénzt kérve érte, akárkinek, akárhol,"7 de ez egyben kötelezettség is. A szervezet által támogatott ún. copyleft8 megközelítés szerint ugyanis a szabad szoftver átdolgozásával létrehozott mű felhasználását az eredeti mű felhasználási feltételei szerint kell engedélyezni (ennek leggyakoribb módja a GPL - General Public License,9 mint ÁSZF alkalmazása), azaz az alapszabadságok gyakorlására vonatkozó engedélyadással, mely kizárja, hogy a szabad szoftver módosítása útján létrejött új mű tulajdonosi szoftver legyen.10
Ebbe a klasszikus értelemben vett "szabad" gondolatvilágba tehát kizárólag az érthető bele, hogy az eredeti és valamennyi átdolgozott szoftver felhasználásának engedélyezése szigorúan a GPL feltételek szerint történik az idők végezetéig (így a gyakorlati tapasztalatok szerint - a közzétételi kötelezettség és a korlátlan hozzáférhetőség miatt - nehezen lehet kifejezetten a felhasználási jogért díjigényt érvényesíteni), azonban nem kizárt a szoftverhez kapcsolódó szolgáltatás vagy tárgyi kiegészítő térítés ellenében történő forgalomba hozatala.11
A FSF "szabad szoftver" fogalmát "nyílt forráskódú szoftverré" alakító Open Source Initiative (OSI),12 valamint a szabad és a nyílt forráskódú elnevezés közötti látszólagos eltérést feloldó FLOSS irányzat13 már nem ilyen szigorú.14 Egyrészt az általuk alkalmazott szemlélet szerint a copyleft licenszeken túli nyílt világ sem kevésbé jó, másrészt a szabadság és a hozzá kapcsolódó eszmeiség oltárán nem hajlandóak a profitábilis működés lehetőségét feláldozni.
"Ha a berlini fal összeomlása valamire megtanított bennünket, az az, hogy a szocializmus önmagában nem fenntartható gazdasági modell. A hangzatos szlogenek nem elegendőek ahhoz, hogy az emberek cselekvési kedvét megsokszorozzák, ha egy jó gazdasági modell nem motivál az erőfeszítésre. Úgy látszott, a Linux is híján van egy ilyen modellnek. Aztán arra jutottunk, hogy ez tulajdonképpen mázli. És ez a mázli elég pénzt termel ahhoz, hogy a saját kis üzletünk működjön és mások kis üzletei is működjenek, de ez még ezzel együtt is pusztán szerencse. De aztán azt láttuk, hogy ahelyett, hogy ez a furcsa Linux törekvés megbukna, egyre csak fejlődött. A felhasználók száma egyre csak nőtt, és a szoftver egyre tökéletesedett. Furcsa volt, de ez a modell egy olyan operációs rendszert hívott életre, mely az ügyfeleknek értéket, a részvényeseknek pedig bevételt jelent."16 - írja Robert Young a Red Hat - a FLOS szoftverértékesítéssel foglalkozó egyik legsikeresebb vállalkozás - egykori vezetője. A Red Hat felismerte a nyílt forráskódú szoftverek megbízható, rendeltetésszerű működése iránti piaci igényt, és bár alapvetően a Fedora projektben fejlesztett Linux17 (tehát tisztán nyílt forráskódú szoftver GNU GPL feltételek szerinti) terjesztésén alapul a társaság tevékenysége, annak érdekében, hogy a nyílt forráskódú fejlesztései modell hátrányait, bizonytalanságait kiküszöböljék, a Linuxot javításokkal, a biztonságos, kockázatmentes nagyvállalati működést garantáló kiegészítésekkel, folyamatos támogatási szolgáltatással ún. Enterprise Linuxként forgalmazzák.18 Teszik mindezt a hasonló funkcionalitású szoftverek felhasználási díjával nagyságrendileg azonos "szolgáltatási" díjért. Elérték tehát (a FSF szerinti alapszabadságok megtartása mellett), hogy pénzt csináljanak a szabad szoftverből.
A nyílt forráskódú szoftver terjesztése nem maradt meg azonban a klasszikus keretek között: bár fogalmilag pont a felhasználás FLOSS licenszfeltételek szerinti engedélyezése miatt tekintünk egy szoftvert nyílt forráskódúnak, a "modern" értelmezés áttöri ezt a keretet. Megjelent ugyanis a FLOS szoftverek kettős, párhuzamos licenszelése kifejezetten olyan szoftvereknél, ahol bár előnyös a közösségi fejlesztés, azonban a termék működése megkívánja annak más szoftverekkel való szoros együttműködését, így adott esetben egy tulajdonosi szoftverrel való összeolvadást. Ekkor az erős copyleft licenszelés - ún. "fertőző" jellege miatt - vitathatatlanul hátrányos, mivel tekintet nélkül arra, hogy a származékos mű milyen részben tartalmaz GPL feltételek szerint terjesztett kódot, az új mű csak GNU GPL szerint licenszelhető.19
Így a tisztán nyílt forráskódú (klasszikus) modell (vagyis a nyílt forráskódú szoftver felhasználásának kizárólag FLOSS licensz szerinti engedélyezése) mára kissé háttérbe szorult,20 és egyre inkább terjednek az ún. hibrid üzleti modellek,21 melyekben keverednek tulajdonosi és nyílt forráskódú koncepciók.
Jelen tanulmány a modellek bemutatása mellett arra mutat rá, melyek a FLOSS licenszelés "modern" értelmezését lehetővé tevő jogi lépések.
Ha a "klasszikustól" a "modern" felé vezető utat akarjuk leírni, azt mondhatjuk, hogy a legkorábban kialakított üzleti megoldások jellemzően a FLOS szoftverhez kapcsolódó (de annak részét nem képező) dolog, járulékos szolgáltatás értékesítésére irányulnak a szoftver díjmentes terjesztésével egyidejűleg. Ez a megoldás tehát nem teszi szükségessé a FLOSS koncepció egyfajta új értelmezését, nem alakít ki új szoftver felhasználási szerződéseket, a szoftver maga és felhasználásának engedélyezése "érintetlen" marad.
Az alapötletnek a gyakorlatban számos változata létezik:
1. Támogatási szolgáltatások modell (Support Sellers)
A (nyílt forráskódú) szoftverek használatát annak komplexitása miatt megkönnyíti (illetve átláthatóbbá, biztonságosabbá teszi) a professzionális támogatás. A Support Sellers modell lényege, hogy a szoftvert valamely FLOSS licensszel terjesztik, így annak felhasználásáért a felhasználó díjat nem fizet. Azonban a szoftverhez igényelhet olyan szolgáltatást, kiegészítést (így adathordozót, oktatást, tanácsadást, kiegészítő fejlesztést, testre szabást stb.), melyekért díjfizetésre köteles.
i. A Service Enabler modellben a nyílt forráskódú szoftverhez online szolgáltatások igényelhetőek, melyekhez előfizetőként - díj ellenében - férhetnek hozzá a felhasználók; vagy a díjakat nem a szoftver felhasználói, hanem azok a hirdetők fizetik, akik reklámokat helyeznek el a szolgáltató által kialakított, a felhasználók által elérhető felületen (ez utóbbit egyes források külön modellként - ún. advertising - említik).
ii. A Selling value added packages koncepció kizárólag nyílt forráskódú szoftverek FLOSS licenszfeltételek szerinti terjesztésére irányul, a felhasználók számára viszont értéket jelent az, hogy az egyes szoftverek, azok egyes komponensei a hozzájuk tartozó javításokkal, kiegészítésekkel együtt csomagként elérhetőek, és nem nekik kell egyenként követni és összeválogatni a kívánt működéshez szükséges elemeket, a díjat tehát a "csomagolásért" fizetik.
iii. Az előbbiek úgy is elképzelhetőek, hogy a felhasználó nem kizárólag az elérhető komponensek összeválogatására, hanem a szoftver elképzelései szerinti testre szabására is igényt tart. A Selling customized version modellben ezeket a kiegészítő fejlesztéseket végzi el a "szolgáltató", aki a fejlesztéssel - a szolgáltatások fogalmán túllépve - új szoftvert/szoftverrészt hoz létre, amely ha egyéni, eredeti jellegű, szerzői műnek minősül. Az új szoftver felhasználására - annak eredeti FLOS szoftverhez való viszonyától függően - szabad, vagy akár tulajdonosi licensszel kap engedélyt a felhasználó.22
2. Hardverértékesítés modell (Build Hardware/Widget Frosting)
Megközelítés kérdése, hogy a Widget Frosting esetében a hardver vagy a szoftver terjesztését tekintjük járulékosnak. A vásárló eredetileg hardvert akar (widget), így nézve a vele átadott előtelepített szoftver (pl. egy meghajtó vagy operációs rendszer) járulékos termék, amit a hardver vásárlója a számítógép mellé kap (frosting), és ezért külön díjat nem fizet (a szoftvert FLOSS licensszel terjesztik).23 A termék ára a vásárló számára így azonban (hasonló termékekhez képest) kedvezőbbnek látszik (hardvert és szoftvert is kap a hardver áráért), és az előtelepített szoftver az "összecsomagolás miatt" a versenytársak termékéhez képest előnyösebb helyzetbe kerül.24
3. Tulajdonosi szoftverkomponensek modell (Propietary Components)
Egyes esetekben a FLOSS közösség a nyílt forráskódú szoftver használatát segítő, működését támogató, vagy nyílt forráskódú platformon futó - egyébként különálló - szoftvereket tulajdonosi szoftverként, díjfizetés ellenében terjeszti. Így például előfordulhat, hogy az alapszoftver FLOSS licenszfeltételek szerint használható, de a hozzá tartozó menedzsment eszközt kereskedelmi szoftverként forgalmazzák, vagy az operációs rendszer szabad szoftver, az alkalmazás viszont tulajdonosi licensszel rendelkezik.
4. Védjegylicencia (Brand licensing)
Ha a jogosult szoftverének terjesztéséhez nyílt forráskódú licenszet választ, nem jelenti azt, hogy a kapcsolódó védjegyeit (például a termék neve, mint szóvédjegy, ábravédjegy stb.) is közkincsbe helyezi. Így azoknak, akik az eredeti FLOS szoftvert átdolgozzák, számolniuk kell azzal, hogy bár maga a kód szabad, de a származékos mű terjesztése további védjegyhasználati engedélyek szerzése és díjfizetés nélkül nem lehetséges.
5. Pingvines póló CD-vel (Accessorizing)
Kézikönyvek, pólók vagy egyéb, a nyílt forráskódú szoftverekhez kapcsolódó, azokat támogató tárgyi kiegészítők forgalmazása kapcsán kevésbé jut eszünkbe a szoftverértékesítés, de mivel a kiegészítők árusítása gyakran FLOS szoftverrel összecsomagolva történik, az accessorizing technikát is elterjedtként jegyzik a nyílt forráskódú üzleti modellek között.
Előfordulhat, hogy egy jogosult először kereskedelmi licensszel bocsátja ki az általa fejlesztett terméket, majd az adott szoftvert nyílt forráskódúvá minősíti. Ez a döntés célszerűen akkor következik be, amikor a szoftver FLOSS közösségben való további fejlesztése kedvezőbb a jogosult számára, mint a tulajdonosi modellben elérhető díjbevételek. A "felszabadított"szoftverek a jogosult kapcsolódó, tulajdonosi modellben forgalmazott termékei számára is közvetíthetnek értéket, illetve ha a részleges közkincsbe bocsátás gyenge copyleft licensszel történt (BSD-típusú licensz) a későbbiekben újabb kereskedelmi szoftver bocsátható ki a közösségi fejlesztés során elért eredmények alapján.
A kettős licenszelés a nyílt forráskódú és a tulajdonosi licenszek együttes alkalmazására épül. Azaz a szerzői jogi oltalom alatt álló kód azonos (vagy közel azonos…), a szoftver felhasználásának engedélyezése pedig párhuzamosan egy zárt és egy nyílt forráskódú licensz rendelkezései szerint történik. Azaz a felhasználó nem szoftvert, hanem licenszet választ; arról dönt, hogy akar-e díjat fizetni egy ingyenesen is elérhető szellemi termékért, amely díj számára tulajdonképpen a szigorúan fertőző copyleft klauzula elkerülésének váltságdíja; vagy GPL-kompatibilis feltételek szerint használja a szoftvert, s egyben kötelezi magát arra, hogy a kód átdolgozásával létrehozott saját szoftverét GPL feltételek szerint engedélyezi bármely érdeklődő felhasználó számára, azaz önként aláveti magát a fertőzésnek.
Joggal merül fel tehát a kérdés, hogy ha a szabadnak hitt szoftver felhasználása tulajdonosi licensz szerint is engedélyezhető, szabad-e a szabad szoftver? Nem áll-e ellentétben ez a kettős szemlélet akár a FSF által megfogalmazott alapszabadságok, akár az OSI által meghatározott nyíltság szellemiségével?
A kettős vagy többes licenszelést elemző szerzők véleménye sokféle.
Érdemes talán Robert Gomulkiewicz meglátásából kiindulni, aki szerint "a nyílt forráskódú licenszelés komoly reklámértéket hordoz a szoftverfejlesztők számára",25 ezért nem csoda, hogy - bár az adott jogosult alapvetően a hagyományos, kereskedelmi szoftverértékesítés híve - a FLOSS mozgalom keltette hullámot is meglovagolja, ha ehhez rendelkezésére állnak a megfelelő eszközök.
Sokan álságosnak tartják ezt a fajta hozzáállást, és úgy vélik, hogy "a kettős licenszeléssel a tulajdonosi szemléletet képviselő jogosultak learatják a nyílt forráskód babérjait, anélkül, hogy a hasznot megosztanák a közösséggel."26 Ez a kritika tükröződik a pseudo-open source elnevezésben is, ami egyre elterjedtebb az irodalomban; illetve egyre gyakoribb a commercial open source és a professional open source hivatkozás is, ami első hallásra egészen paradox módon hat.27
Olyan vélemények is elhangzanak, melyek szerint az egész kettős licenszelésben nincs semmi újdonság, hisz hasonló logikára épül a mára már teljesen hétköznapi shareware koncepció is: ugyanazt a szoftvert használjuk, csak egyszer fizetünk, máskor nem fizetünk érte.
A felhasználási szerződések és az engedélyezés szempontjából viszont merőben más, hogy a shareware esetében egyértelműen tulajdonosi szoftverről beszélünk, melyet adott ideig díjfizetés nélkül lehet használni (mintha freeware volna), ezen túl pedig a felhasználó díjfizetésre köteles (ahogy a kereskedelmi szoftvereknél az megszokott), azaz a választóvonal kizárólag a díjfizetés. A kettős licenszelésű FLOS szoftvereknél viszont pont az idézi elő a tudathasadásos állapotot, hogy az ÁSZF-ként használt akár BSD-, akár GPL-típusú felhasználási szerződés jogosít a forráskód megismerésére, a szoftver szabad másolására, módosítására és terjesztésére, sőt a GPL-kompatibilis licenszek ezen túl kötelezik a felhasználót, hogy a származékos mű felhasználását az eredeti licensz feltételei szerint engedélyezze. Így nehezen képzelhető el, hogy ugyanennek a kódnak a felhasználása valamiképp tulajdonosi licenszfeltételek szerint is engedélyezhető, hisz ekkor a régi szabadság elveszik; születik viszont egy új: nem kell a származékos mű felhasználását a FLOSS feltételek szerint engedélyezni, azaz nincs részleges közkincsbe bocsátás, a copyleft fertőzés megszűnik, a felhasználó által átdolgozott forráskód zárttá és tulajdonosi licensszel terjeszthetővé válik!
A tudathasadásos állapot feloldására a szerzői jogi szabályok és az alkalmazott szerződések áttekintése adhat magyarázatot. Ahogy a nagy igazságot a hackerek is megállapítják: "szabadnak maradni csak úgy lehet, hogy a szoftvereinket védi a szerzői jog, és megfelelő licenszeket használunk",28 vagy még érzékletesebben kifejezve "minden háborúk legszentebbike nem szövegszerkesztőkről, operációs rendszerekről és fordítóprogramokról szól, hanem a licenszekről."29
Még ha ezek az állítások kissé túlzóak is, az egészen biztos, hogy a FLOSS üzleti modellek sikerében alapvető szerepe van a jó szoftver, az ígéretes forráskód mellett annak hatékony fejlesztése és terjesztése érdekében a szerzői jogi rendelkezések betartásának, illetve a megfelelő felhasználási szerződések (rendszerint ÁSZF-ek) kialakításának és alkalmazásának.
Az alapvetően peer production30 alkotófolyamatokra épülő nyílt forráskódú szoftverfejlesztés és -terjesztés során még olyan egyszerű kérdések eldöntése is, hogy mi a szoftver, ki annak a szerzője, ki rendelkezik a szerzői jogokkal, azaz ki jogosult a mű felhasználására és a felhasználás engedélyezésére, a sokszereplős, sokműves közösségi alkotótevékenység miatt meglehetősen bonyolult lehet. A kettős licenszelés alkalmazhatóságához ezek viszont kötelezően megválaszolandó alapkérdések.
Kíséreljük meg a lehetséges alternatívák áttekintését az Szjt.31 szabályainak alkalmazásával.32
Érdemes abból kiindulni, hogy a kettős licenszelési modellt eredményesen alkalmazó társaságok rendszerint az alábbiak szerint működnek:
1. A szoftver fejlesztését egy szervezet irányítja, a szervezet által gyakorolt kontroll a fejlesztés folyamatára, irányára, a szoftver "termékként"33 való megjelenésének mikéntjére, illetve a szerzői jog gyakorlására is kiterjed. Tehát a fejlesztés irányítója, koordinálója maga a jogosult.
2. Azonos termék felhasználást engedélyezik FLOSS és kereskedelmi licensz szerint (esetenként ez utóbbi bővített funkcionalitású termék felhasználására jogosít). Nyílt forráskódú licenszként jellemzően GPL-típusú ÁSZF-et használnak, így a felhasználó köteles az eredeti forráskód átdolgozásával létrehozott származékos mű forráskódját azonos feltételek szerint elérhetővé tenni (elkerülve ezzel a kód "bezárását"). A kereskedelmi licensz díjfizetési kötelezettséget tartalmaz, "cserébe" a copyleft rendelkezés hiányzik belőle.
3. A kettős licenszelés olyan szoftverek esetében alkalmazható sikeresen, melyeket működésük során más rendszerekbe ágyaznak be, itt ugyanis különösen fontos, hogy az eredeti rendszer tulajdonosi licenszelését ne fertőzzék meg (ne tegyék súlytalanná) a beágyazott rendszer GPL feltételei.
A fentiek alapján tehát az üzleti sikerhez szerzői jogi szempontból két sarkalatos kérdés rendezése szükséges:
1. a szoftver (a "termék") vonatkozásában fennálló vagyoni jogok jogosultja egy személy/szervezet legyen;
2. ez a személy/szervezet olyan licenszfeltételek alkalmazásával engedélyezze (engedélyezhesse) a felhasználást, mely a szoftver közösségi fejlesztését, valamint üzleti alkalmazásba való beépíthetőségét is lehetővé teszi.
A közösségi szoftverfejlesztés sajátosságait és FLOSS licenszek adta lehetőségeket figyelembe véve a cél a sokszerzős szoftver felett egy jogosult rendelkezési jogának biztosítása, azaz az (egy termék + sok szerző) - X = egy jogosult egyenlet megoldása.
I. Az egyenlet megoldása. X=?
1. Egy termék
A szerzői jog azt illeti meg, aki a művet megalkotta.34
A nyílt forráskódú szoftverfejlesztés esetében sincs ez másképp, de mivel a FLOSS licenszek által garantált jogok lehetővé teszik, hogy a forráskódhoz bárki hozzáférjen, és annak felhasználásával származékos művet vagy más fejlesztőkkel együttműködve szorosan értelemben vett közös művet hozzon létre, a szerzőség kérdése - a szoftverfejlesztés különböző szakaszaiban - sokszor nehezen követhető. Sőt a fejlesztés közösségi jellegéből adódóan annak meghatározása sem magától értetődő, hogy mi is a mű (melynek szerzőségéről, jogosultjáról nyilatkozni kellene), mivel a FLOSS licenszfeltételek lehetőséget adnak az eredeti és származékos művek végeérhetetlen láncolta megalkotásának.
Annak definiálása, hogy pontosan mi is a szoftver, amely felett a szervezet "termékként" rendelkezni szeretne, alapvetően technikai és nem jogi kérdés. A technikai kérdés megválaszolásának nehézségeit viszont pont az a jogi helyzet adja, hogy a FLOSS licenszek széles körben lehetővé teszik a mindenki számára elérhető (a "szerződéses közkincs"35 részét képező) szoftver módosítását (szerzői jogi értelemben: átdolgozását), azaz mivel a FLOSS fejlesztések esetében tulajdonképpen a közkincs fejlesztéséről beszélünk, a "termék" definiálása a dinamikusan fejlődő közkincs egy darabjának pontos meghatározását, pillanatfelvétel készítését jelenti.
Technikai szempontból a szoftverfejlesztések részletes követelményspecifikáció szerint, pontos mérföldkövek rögzítésével zajlanak. A tényleges fejlesztést tervezési szakasz előzi meg, melyet a kódolás, aztán a tesztelés követ. Ezzel egyidejűleg zajlik a dokumentációkészítés, majd a szoftver kiadása.36 Ha a FLOSS licenszek adta lehetőségek teljes kiaknázását vennénk alapul, az eredeti művet a világ számtalan pontján módosító, hibákat kereső és javító fejlesztőt látnánk, akik nem, vagy alig tudnak egymásról, még ha az általuk módosított kódot egy központi helyre visszajuttatva, majd újra továbbfejlesztve tulajdonképpen egy szoftveren dolgoznak is ("bazár modell"). Ezzel szemben a szoftverfejlesztés komplexitása miatt a másik oldalról azt feltételezzük, hogy a specifikáció követése és a mérföldkövek elérése jól szervezett fejlesztőközösséget és határozott projektmenedzsmentet igényel ("katedrális modell").37 A kettős licenszelés esetében (a kettősségről való döntés és annak fenntarthatósága érdekében) kulcskérdés a kontroll, a mű feletti rendelkezési jog egy kézben tartása; a specifikációkészítés, a termék meghatározása, és annak kijelölése, hogy a fejlesztésben ki és hogyan vehet részt, a gyakorlatban a leendő jogosult döntése, így ilyen értelemben a fejlesztés folyamata katedrális modell-szerűen működik.38
Így a kettős licenszelésű szoftverek esetében azok elkészülte és kiadása - szemben a bazár modell forgatagával - nem meglepetésszerű, hanem egy jól irányított belső folyamat eredménye, vagyis pontosan ütemezhető és jól körülhatárolható. A pillanatfelvétel tehát - az előre megtervezett, jó beállítások miatt - biztosan nem lesz homályos…
2. Sok szerző…
A termék technikai meghatározását követi a szerzőt a mű létrejötte okán megillető szerzői jogok számbavétele,39 és azok egy jogosulthoz "telepítése".
Mivel a nyílt forráskódú termék technikai szempontból inkább adottság, mint választási lehetőség, adottságnak tekinthető az annak sokszerzős voltából adódó jogi helyzet is, és a jogok gyakorlásának megkönnyítése érdekében e helyzet rendezése iránti igény. A jogok gyakorlása szempontjából nem mindegy ugyanis, hogy miként minősül a mű.
Ha a fejlesztők együttes elhatározás alapján, közös célkitűzésként közösen fejlesztenek új szoftvert, melynek részei egymásra utaltak (egyik működésének feltétele a másik működése) szerzőtársak lesznek, szerzői jogaikat közösen gyakorolják (szoros értelemben vett közös művet alkotnak).40 Ha a célkitűzés és az együttműködés az előbbiek szerinti, de a részek önállóan is felhasználhatóak (pl. modulok rendszerként és külön is működnek), a saját rész tekintetében a szerzői jogok önállóan gyakorolhatóak (összekapcsolt művek).41
Ha a FLOS szoftver fejlesztését a fejlesztők valamely szervezet kezdeményezésére és irányításával hozzák létre, úgy, hogy 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, és a szervezet a szoftvert saját nevében hozza nyilvánosságra, a szervezetet illeti meg a szerzői jog (együttesen létrehozott mű).42
Származékos módon jön létre a többszerzős mű a szoftver átdolgozása esetén.43 A származékos jelleg azt jelenti, hogy az alapul fekvő szoftvernek szerzői műnek kell lennie, az átdolgozás eredményeképpen ettől eltérő, egyéni, eredeti jellegzetességgel bíró programnak kell létrejönnie, és az átdolgozásnak jogszerűnek kell lennie, vagyis az nem járhat az eredeti szoftver szerzője jogainak sérelmével.44 E feltételek teljesülése esetén a származékos mű szerzőjét is megilleti a szerzői jogi védelem.
A Kommentár utal rá, hogy a külföldi jogok igen eltérő módon és mértékben (és szóhasználattal) rendelkeznek a többszerzős művekről,45 továbbá kiemeli, hogy a bírói gyakorlatban többször lehet az átdolgozás fogalmának téves használatával találkozni.46
Az átdolgozás megítélése a FLOS szoftverek esetében sem egyértelmű.47 Bár a törvényi definíció (hasonlóan a BUE rendelkezéseihez48) megkívánja, hogy mind az eredeti, mind a származékos mű egyéni-eredeti jellegű legyen, a leggyakrabban használt FLOSS licensz (GPL v2.049) ennél tágabb definíciót tartalmaz. Azt mondja ugyanis, hogy a ">>mű, mely a Programon alapul<< jelenti egyrészt magát a Programot vagy a szerzői jog szerinti származékos műveket: vagyis azokat a műveket, melyek tartalmazzák a Programot vagy annak egy részét."50
A származékos mű fogalmának megalkotásakor a GPL szövegezői tehát láthatóan igyekeznek a szerzői jogi rendelkezésekkel összhangban fogalmazni, de mégis ellentmondásos definíciót alkotnak. Fogalmuk egyrészt lefedi a szerzői jogi szempontból származékos műnek tekinthető átdolgozást (tehát amely egyéni, eredeti jellegű, épp ezért új műnek minősül, és védelem illeti meg), továbbá minden olyan alkotást, mely az eredeti művet vagy annak akármilyen/akármekkora részét tartalmazza - tekintet nélkül arra, hogy az új szoftver egyéni, eredeti jellegű, vagy sem.51
A nyílt forráskódú fejlesztés eredményeképp létrejött termék esetében nem feltétlenül könnyen átlátható tehát, hogy ki rendelkezik a szerzői jogokkal; a leendő jogosult ezeket a bonyodalmakat igyekszik rendezni…
3. X=vagyoni jogok
… A helyzet rendezésének eszköze a jogátszállás, illetve a jogátruházás, vagyis a sokszerzős helyzet "egyszerzőssé" alakítása: a mű vonatkozásában fennálló vagyoni jogok megszerzése.52
Ha a fejlesztés munkaviszonyban folyik, a leendő jogosult helyzete meglehetősen egyszerű, mivel (eltérő megállapodás hiányában) valamennyi fejlesztő a szoftver (fejlesztés egyes szakaszának53) átadásával a munkáltatóra ruházza vagyoni jogait, ha a fejlesztés a munkaviszonyból folyó kötelessége.54 Elsőre talán bizarrnak hat a munkaviszonyban fejlesztett FLOS szoftver, de a valóságban egyre jellemzőbb, hogy a nyílt forráskódú közösségek és a nagy szoftvercégek kapcsolata szorosabbá válik. Például a Linux fejlesztésén is számos olyan fejlesztő dolgozik, aki közvetlenül az OSDL55 vagy azok valamely támogatójának alkalmazásában áll, a kettős licenszelés esetében pedig ahol a jogosult kifejezett célja a vagyoni jogok megszerzése,56 a jogszabály erejénél fogva bekövetkező jogátszállás sokkal előnyösebb, mint a többszerzős helyzetek jogátruházási szerződéssel való tisztázása, ezért gyakran alkalmazzák a fejlesztőket (például a rendkívül népszerű MySQL-t - "termékként" - szinte kizárólag munkavállalók fejlesztik).57
Szintén a törvény erejénél fogva, jogutódlással szállnak át a vagyoni jogok az együttesen létrehozott szoftver esetében: a fejlesztést kezdeményező, azt irányító és nyilvánosságra hozó szervezet válik jogosulttá. A jogosultra nézve ez a fajta jogátszállás - a munkaviszonyhoz képest - kevésbé biztonságos megoldás, mivel az, hogy a szoftver együttesen létrehozott műnek minősül-e, nem a felek elhatározásától függ, tehát a jogosult az átszállást nem tudja kiszámíthatóan befolyásolni.58 Tekintettel arra, hogy a szoftverfejlesztés egyes fázisai is külön védelmet élvezhetnek, a szoftver együttesen létrehozott műnek minősülése még bizonytalanabb.59
Ha a leendő jogosult a jogátszálláshoz szükséges feltételek biztosításáról előre nem gondoskodik (közösségi szoftverfejlesztés esetében ezt feltételeznénk általánosnak), a kettős licenszelési modell kialakítása és fenntartása, a szerzőtársi joggyakorlás, a közös felhasználás és a felhasználás közös engedélyezésének elkerülése érdekében a "termék" valamennyi fejlesztőjével (szerzőjével) a vagyoni jogok átruházását lehetővé tevő szerződést kell kötnie.
A FLOSS mozgalom kezdeti szakaszában a kifejezett jogátruházás nem volt jellemző. A közösségi szándék szerint az átruházást az ún. implied license-ek biztosították, vagyis olyan ráutaló magatartással kötött szerződések, melyek úgy jöttek létre, hogy a fejlesztő a közösség tagjainak "adományozta" művét (contribute), vagyis a további fejlesztések és a projekt előrehaladása érdekében tulajdonképpen bárki számára lehetővé tette a szoftver feletti rendelkezést, a másik fél pedig ennek elfogadását a cselekmények gyakorlásával végezte el.60 Ezt a meglehetősen bizonytalan megoldást váltotta fel a FLOSS fejlesztési gyakorlatban - a magyar jog szerint is - ténylegesen a vagyoni jogok átruházására irányuló szerződésnek tekinthető specific contributor agreement alkalmazása. 61
A Contributor Agreement (CA) 62célja, hogy a közösségi modellben dolgozó fejlesztő a szoftver vonatkozásában fennálló valamennyi (lehetséges) jogát a fejlesztést irányító szervezetnek adományozza (contribute), azaz közöttük jogátruházás történjék. 63
A jogátruházással a fejlesztőről (eredeti jogosult) a jogszerzőre száll a felhasználás és a felhasználás engedélyezésének joga is. Így a jogok átruházásával igyekeznek kiküszöbölni a GPL licensz copyleft rendelkezésének a fertőző hatását,64 mely a kettős licenszelési modell működésének kerékkötője lehetne, nevezetesen hogy bár a fejlesztő a szoftver átdolgozását a GPL engedély jogosítása mellett végezte el, és egyben kötelezettséget vállalt a származékos mű felhasználásának azonos feltételek szerinti engedélyezésére,65 a származékos mű vonatkozásában keletkező vagyoni jogainak az eredeti-új jogosultra való átruházásával,66 a copyleft szabályt mintegy megelőzik, a felhasználás engedélyezését megelőző stádiumban kerül sor a rendelkezési jog gyakorlására.
Az egyes jogosultak, illetve a FLOSS szervezetek által kialakított CA-k rendszerint (a felhasználási szerződésekhez hasonlóan) ÁSZF-ek. Mivel a világon tulajdonképpen bárki, bárhol adományozhat kódot, a CA-k többnyire rendezik azt az esetet is, ha az adott jogrendszerben a vagyoni jogok elidegenítése nem lehetséges. A szerződést ilyenkor úgy kell tekinteni, hogy a fejlesztő és az új jogosult között felhasználási szerződés jön létre, melyben a fejlesztő kizárólagos, minden felhasználási módra kiterjedő, időbeli és területi korlátozás nélküli felhasználási jogot enged a jogszerző számára a szoftver vonatkozásában.
A magyar jog a vagyoni jogok szerződéssel történő átruházását szoftver esetében lehetővé teszi. 67
Az Szjt. szabályai szerint a felhasználási szerződésre vonatkozó rendelkezéseket megfelelően alkalmazni kell a szerzői vagyoni jogok átruházására irányuló szerződésekre,68 így érdemes átgondolni a FLOS szoftverfejlesztés és a CA-k sajátosságait a felhasználási szerződésekre vonatkozó rendelkezésekkel összevetve.
A CA-k tárgya jellemzően nem egy konkrét szoftver, hanem a projekt során megalkotott/megalkotandó valamennyi kód.69 Az Szjt. szerint semmis a felhasználási szerződésnek az a kikötése, amellyel a szerző meghatározatlan számú jövőbeli művének felhasználására ad engedélyt.70 Továbbá ha a felhasználási szerződést jövőben megalkotandó művekre úgy kötik meg, hogy a jövőbeli műveket csak fajtájuk vagy jellegük szerint jelölik meg, a szerződés megkötésétől számított öt év elteltével és azt követően újabb öt-öt év elteltével bármelyik fél hat hónapra felmondhatja a szerződést.71
Szintén alkalmazandóak a rendeltetésellenes vagy szerződési célnak nem megfelelő joggyakorlással szemben szerzői felmondási jogot biztosító rendelkezések.72
Érdekes továbbá a magyar joggyakorlat annak a kérdésnek a megítélésében, hogy a vagyoni jogok átruházása esetén a jogszerző - külön kikötés nélkül - megszerzi-e az átdolgozás jogát. Az Szjt. ugyanis úgy rendelkezik, hogy a felhasználási engedély csak kifejezett kikötés esetén terjed ki a mű átdolgozására,73 a felhasználási szerződés szabályait pedig - a fentiek szerint - a jogátruházási szerződésre megfelelően alkalmazni kell. A Kommentár az Szjt. 4. §-ához fűzött magyarázatában azon az állásponton van, hogy "az átdolgozás jogát ebben az esetben is külön ki kell kötni"74, később azonban75 rámutat a Szerzői Jogi Szakértő Testület (a továbbiakban: SzJSzT) két véleményére76 és a bírói gyakorlatra, mely szerint a funkcionális művekre vonatkozó nem korlátozott vagyoni jogátruházási szerződés hatálya kiterjed az átdolgozás jogára is. Az átdolgozás jogának megszerzése a szabad szoftver esetében kulcskérdés - tekintve hogy a vagyoni jogok átruházásának egyik célja a szoftver további fejlesztése, így a szerződés szövegezésekor mindenképp érdemes e szempontra is figyelemmel lenni.
4. Egy jogosult!
Tekintve a jogátruházási szerződések körüli lehetséges bizonytalanságokat, a jogszerzés legegyszerűbb, legkevésbé kockázatos és a jogosult számára legkedvezőbb módja a jogátszállás. A kettős licenszelést alkalmazó társaságok gyakorlatában így az a megszokott, hogy bár nyílt forráskódú termék fejlesztése folyik, azt a majdani jogosult munkavállalói végzik; "kódadományozást" szélesebb fejlesztői körtől nem fogadnak el (így nincsenek kitéve az adományozás körüli esetleges problémáknak). Amennyiben pedig ilyenre mégis sor kerül (a jogszerzés jogátruházás útján történik), frissen szerzett rendelkezési jogát gyakorolva az új jogosult a kódot rendszerint (munkavállalóival) újraíratja.
Ilyen értelemben tehát a kettős licenszelésű szoftverekre alkalmazott terjesztési modell lehet részben vagy egészben nyílt, a fejlesztés folyamatáról ez - hagyományos értelemben véve - nem mondható el.
Az (egy termék + sok szerző) - vagyoni jogok = egy jogosult egyenlet jogosultja rendelkezik tehát a termék vagyoni jogaival, így dönthet a szerződés tartalmáról, melyben engedélyt ad a szoftver felhasználásra.
Visszatérve az okos lányra, mindezt úgy szeretné megtenni, hogy a szoftver szabad is legyen, meg ne is, vagyis adjon is ajándékot meg ne is. Hasonlóan tehát a leányhoz, aki otthon egy galambot megfogott, két szita közé tette, és elvitte magával a királyhoz, aztán mikor a király elébe ért, a galambot a szita közül elrepítette, a jogosult fogja a szoftvert és szita közé téve, zártan adja az üzleti felhasználóknak, közben a FLOSS közösségnek kinyitja a szitát, és ezzel a szoftvert elengedi.
Vagyis egyrészt egy tulajdonosi licensz rendelkezései szerint, díjazás ellenében engedélyezi a szoftver forráskódjának megismerését, továbbá annak tulajdonosi termékbe való beágyazását, majd az új termék kereskedelmi licensz szerinti terjesztését; másrészt ugyanazon szoftver felhasználására valamely FLOSS licensz feltételei szerint is engedélyt ad, vagyis díjfizetés nélkül, korlátozásmentes felhasználásra és módosításra, a származékos művekre vonatkozó közzétételi kötelezettséggel.
A BSD-típusú és a GPL-típusú licenszek közötti különbségek miatt77 a jogosultak rendszerint GPL-típusú licenszet választanak a kettős licenszelési modellben. Ennek oka a copyleft klauzula. Ez kizárja ugyanis, hogy a nyílt forrásból származó szoftver felhasználásával létrehozott bármilyen kód felhasználását78 kereskedelmi feltételek szerint lehessen engedélyezni.79 Mivel a copyleft rendelkezést nem tartalmazó BSD licensz lehetővé teszi, hogy az eredetileg nyílt forráskódú művet a fejlesztés folyamán "bezárják", a termék továbbfejlesztett ága tulajdonosi szoftverré, fejlesztése - az eredeti jogosult számára - kontrollálhatatlanná válhat. Vagyis BSD-típusú licenszcel egy új, szeparált, korábbi jogosult által nem ismert termékvonal kialakítására volna lehetőség, ráadásul a jogosult által biztosított, FLOSS alapból készült szoftver esetében.80
A szabad szoftverből is lehet üzletet csinálni, és ezt senki sem vitatja.
Kérdés, hogy mekkorát…
Hogy mi és hogyan fér a "szabadság" fogalmába a licensz pontos rendelkezései mellett vagy azon túl, az értelmezés és a rendelkezésre álló eszközök felhasználásának kérdése.
Szabadság vagy nyíltság?
GPL vagy BSD?
Járulékos szolgáltatások vagy kettős licenszelés?
A szabadság relatív.
Mindenki döntse hát el magában, szabad-e szoftver; felhívom a figyelmet arra, hogy a "szabad is meg nem is" válasz nem elfogadható! ■
JEGYZETEK
1 Az okos leány. Magyar népmese
2 Albert, Philip H.: Dual Licensing: Having Your Cake and Eating It Too. http://www.linuxinsider.com/story/38172.html (2011.01.05.)
3 Albert i. m.
4 A hacker szó eredetileg jól képzett fejlesztőkre és nem informatikai bűnözőkre utal.
5 A szabad szoftver felhasználóinak engedélyezni kell, hogy
1. futtassák a programot, bármilyen céllal;
2. tanulmányozzák a program működését, és azt a szükségleteikhez igazíthassák;
3. másolatokat tegyenek közzé; illetve
4. 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.
A free software kifejezés tehát nem az ingyenességre utal, hanem a szabadságra. "This is a matter of freedom, not price, so think of >>free speech<<," not >>free beer<<." http://www.gnu.org/philosophy/ (2011.01.05.)
6 A Free Software Foundation (a továbbiakban: FSF) egy, a szabad szoftvereket és a copyleft eljárást népszerűsítő szervezet, mely a szoftverek korlátozásmentes terjesztésének és fejlesztésének megvalósítását hirdeti. Bővebben: http://www.gnu.org/philosophy/free-sw.html (2011.01.05.)
7 http://www.gnu.org/philosophy/free-sw.hu.html (2011.01.05.)
8 A copyleft megnevezés nem a szerzői jogról való lemondást jelenti. A modell lényege az, hogy a jogtulajdonos a szerzői jogi szabályok alkalmazásával: felhasználási szerződés létrehozásával érje el célját, a szoftver közösséghez juttatását. (A cél teljesülése a szerzői jogi eszközök használata nélkül lehetetlen volna.)
9 A GNU GPL elérhető itt: http://www.gnu.org/licenses/gpl.html (2011.01.06.)
10 A "szabadság" a FSF álláspontja szerint nem kizárólag copyleft licensszel való terjesztést jelent, azonban ők elsősorban a copyleft licenszeket támogatják. (Noncopylefted free software also exists. We believe there are important reasons why it is better to use copyleft, but if your program is noncopylefted free software, it is still basically ethical. http://www.gnu.org/philosophy/free-sw.html 2011.01.06.)
11 A szabad szoftverek felhasználásának engedélyezése természetesen annyiféleképp történhet, ahányféleképp arról az érintett felek megállapodnak. Az általános cél az, hogy a szoftverek forráskódjának megismerhetősége, módosíthatósága, az azokhoz való közösségi hozzáférés garantált legyen. E cél megvalósítására számtalan felhasználási szerződés (ÁSZF) született, melyek rendelkezései többféle modell létét mutatják. A modellek közötti fő megkülönböztető ismérv az, hogy hogyan kezeli az eredeti szoftver jogtulajdonosa az átdolgozás eredményeképp létrejövő új (származékos) művet. Ez alapján két főbb licenszcsoportot lehet elkülöníteni:
A GPL-típusú (erős copyleft) licenszek az ún. copyleft megközelítés szerinti felhasználási szerződések úgy rendelkeznek, hogy szabad szoftver átdolgozásával létrehozott mű felhasználását az eredeti mű felhasználási feltételei szerint kell engedélyezni (harmadik személyre kiható kikötés).
A BSD-típusú (gyenge copyleft) licenszek az alapvető jogosultságok garantálásában megegyeznek a GPL-típusú licenszekkel, azonban e felhasználási szerződések nem kötelezik a származékos mű fejlesztőjét arra, hogy az új mű felhasználását az eredeti licensz feltételei szerint engedélyezze, és mivel nem követeli meg a származékos mű forráskódjának közzétételét, ezért az felhasználható zárt forráskódú szoftverek megalkotásához.
12 Az OSI a nyílt forráskódú szoftver fogalmát a FSF által a szabad szoftver esetében megfogalmazott 4 alapvető szabadsághoz képest 10 jellemzővel írja le. (Free Redistribution, Source Code, Derived Works, Integrity of The Author’s Source Code, No Discrimination Against Persons or Groups, No Discrimination Against Fields of Endeavor, Distribution of License, License Must Not Be Specific to a Product, License Must Not Restrict Other Software, License Must Be Technology-Neutral). Az Open Source Definition (OSD) elérhető: http://www.opensource.org/docs/definition.php (2011.01.06.).
A FSF szerint az alapvető jogok és kötelezettségek pontos megfogalmazása mellett a szabad szoftver definíció lényege a szabadság és az e mögött húzódó eszme sugallata. Véleményük szerint az OSI definíciójából elveszik ez az etikai tartalom. Vagyis a FSF szerint az OSI azonos célkitűzések mellett más értékrend és világszemlélet alapján működik: »…whether software should be open source is a practical question, not an ethical one. As one person put it, "Open source is a development methodology; free software is a social movement."« http://www.gnu.org/philosophy/free-software-for-freedom.html
(2011.01.06.)
13 A FLOSS (Free/Libre/Open Source Software) kifejezés azzal igyekszik feloldani a szabad és a nyílt forráskódú elnevezés közötti látszólagos eltérést, hogy a szabadságot és a nyílt forráskódot is kellőképpen hangsúlyozza a megnevezésben, rámutatva arra, hogy lényegi különbség nincs a szabad és a nyílt forráskódú szoftverek között.
14 Fentiek miatt - ahol kifejezett tartalmi különbségre nem hivatkozok - a tanulmányban a szabad szoftver, nyílt forráskódú szoftver és FLOS szoftver kifejezéseket szinonimaként alkalmazom.
15 FLOSS üzleti modellek leírása nem végleges és szilárd koncepciók ismertetését jelenti. Ebben a fejezetben az értékesítési stratégiák főbb jellemzőit és ehhez kapcsolódóan a licenszelés sajátosságait ismertetem a piacon legjellemzőbben alkalmazott gyakorlat figyelembevételével, valamint Gomulkievicz, Robert W.: Entrepreneurial Open Source Software Hackers: MySQL and Its Dual Licensing. Computer Law Review and Technology Journal Vol. IX:2004.; Hecker, Frank: Setting Up Shop: The Business of Open-Source Software. http://hecker.org/writings/setting-up-shop (2011.01.07.) és Doran, Andy: The Five Open Source Business Models http://www.informationweek.com/blog/main/archives/2008/01/the_five_open_s.html (2011.01.07.) című művei alapján.
16 Young, Robert: Giving It Away. How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry. http://oreilly.com/catalog/opensources/book/young.html (2011.01.10.) p.1.
17 http://en.wikipedia.org/wiki/Fedora_(operating_system) (2011.01.10.)
18 http://en.wikipedia.org/wiki/Red_hat (2011.01.10.); http://www.redhat.com/ (2011.01.10.)
19 Emiatt nevezik a GNU GPL licenszet infectious vagy viral license-nek.
20 Egyes angol nyelvű források szerint pure-play model.
21 Egyes angol nyelvű források szerint hybrid model.
22 Ennek feltételeire a 3. fejezet mutat rá, így arra is, ha a kiegészítő fejlesztés eredményeképp nem önálló szerzői mű, hanem közös mű keletkezik.
23 Itt látnunk kell, hogy a modell alkalmazói jellemzően hardvergyártók, -forgalmazók, akik a könnyebb piacra jutás és pozíciószerzés érdekében nyílt forráskódú szoftvereket terjesztenek, de maguk nem foglalkoznak szoftverfejlesztéssel.
24 Egyes szerzők meg is fogalmazzák ezzel kapcsolatos versenyjogi aggályaikat. Lásd Geraci, Jesse:
Misusing Open-Source? How Technology Companies Using the GPL Might Run Afoul of Antitrust Law. http://www.jonesday.com/files/News/b998b781-3719-4103-adfc-0395ee491c4d/Presentation/NewsAttachment/4c05b5f4-331b-44e4-8e6a-901c3d591eb2/Geraci_Misusing%20Open-Source_Swope%20Prize%20Submission.pdf (2011.01.15.)
25 Gomulkievicz, Robert W.: Entrepreneurial Open Source Software Hackers: MySQL and Its Dual Licensing. Computer Law Review and Technology Journal Vol. IX:2004. p. 205.
26 http://www.linuxinsider.com/story/38172.html (2011.01.12.)
27 Lásd például: Mann, Ronald J.: The Commercialization of Open Source Software: Do Property Rights Still Matter? Harvard Journal of Law & Technology, Vol.20 (1) 2006.
28 http://www.debian.org/intro/free (2011.01.12.)
29 http://www.itworld.com/LWD010523vcontrol4 (2011.01.12.)
30 Egyenrangú résztvevők által önkéntesen végzett, egyéni indíttatáson alapuló, az alkotást részben, vagy egészben közkincsbe bocsátó közösségi alkotótevékenység, mely az információs társadalomban vált jelentőssé. Részletesebben lásd: http://en.wikipedia.org/wiki/Peer_production , http://en.wikipedia.org/wiki/Commons-based_peer_production (2011.01.12.)
31 1999. évi LXXVI. törvény a szerzői jogról (a továbbiakban Szjt.)
32 Azaz tegyük fel, hogy magyarországi felhasználás esetén - jogválasztás hiányában - egy kettős licenszelési ügyre a magyar jogot kell alkalmazni.
33 A "termék" szó használata a szoftverek megnevezésére az informatika világában teljesen mindennapos. A jogosultak (szoftvergyártók) terméknek nevezik a publikált, felhasználók által elérhető programjaikat. A továbbiakban a "termék" szót arra a szoftverre használom, melynek kódját a kettős licenszelést alkalmazó társaságok központilag, az angol terminológia szerint core product-ként kezelik, vagyoni jogaival ők rendelkeznek; megkülönbözetve ezzel e központi változatot a FLOSS fejlesztés eredményeképp, ugyanazon kód alapján esetlegesen előálló módosított szoftververzióktól, fejlesztési ágaktól.
35 Bobrovszky Jenő szerint szerződéses közkincs nem a klasszikus közkincs fogalom szerinti (oltalom alatt nem álló) szellemi javakra, hanem az új, gyakran közösségi alkotómunka eredményeként létrejött, copyleft típusú üzleti modellek útján engedélyezett művekre utal. In: Bobrovszky, Jenő: Az enyém, a tied és a miénk a szellemi tulajdonban. Áttekintés a közkincs és a szellemi magántulajdon egyes összefüggéseiről az Internet tükrében. Liber Amicorum - Ünnepi dolgozatok Gyertyánfy Péter tiszteletére. ELTE ÁJK Polgári Jogi Tanszék, Budapest, 2008. p. 16. Lásd még: Samuelson, Pamela: Enriching discourse on public domains. Duke Law Journal Vol. 55:2006.
36 http://hu.wikipedia.org/wiki/Szoftverkiad%C3%A1s_%C3%A9letciklusa (2011.01.19.); http://hu.wikipedia.org/wiki/Sz%C3%A1m%C3%ADt%C3%B3g%C3%A9p-programoz%C3%A1s (2011.01.19.)
37 A két szélsőséget és azok kölcsönhatásait, gyakorlati alkalmazhatóságukat mutatja be Eric Raymond The cathedral and bazaar című művében a tulajdonosi szoftverek fejlesztési gyakorlatát a katedrális-építéshez, a nyílt forráskódú fejlesztést pedig a bazári forgataghoz hasonlítva. In: Raymond, Eric S.: The cathedral and bazaar. http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/578 (2011.01.15.)
38 A szoftverek komplexitása a gyakorlatban egy fejlesztőközösség tagjainak vagy több fejlesztőközösségek jól koordinált együttműködését igényli.
42 Szjt. 6. §
43 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. [Szjt. 4. § (2) bekezdés].
44 Gyertyánfy Péter (szerk.): A szerzői jogi törvény magyarázata. Complex Kiadó 2006. (továbbiakban: Kommentár) p. 43.
45 Kommentár p. 47.
46 Kommentár p. 45.
47 Ennek feltételezhetően oka, hogy a FLOSS licenszek többnyire a szerzői jogi és egyéb magánjogi szabályok felületes figyelembevételével, a dogmatikai szempontok vizsgálatának mellőzésével jöttek létre.
48 BUE 2. cikk (3) bekezdés, 12. cikk
49 A különböző FLOSS licenszek elterjedtségét, népszerűségét vizsgálta a Black Duck Open Source Research Center. A felmérésből látszik, hogy a GNU GPL licensz messze a leggyakrabban használt ÁSZF. http://www.blackducksoftware.com/oss/licenses/ (2011.01.20.)
50 GPL v2. Clause 0. (Teljes szöveg elérhető: http://www.gnu.org/licenses/gpl-2.0.html 2011.01.20.)
51 Ez az értelmezés - bár elvi szinten lehetséges volna - minimálisra csökkenti annak lehetőségét, hogy a GPL feltételek szerint engedélyezett szoftver közösségi fejlesztésekor önálló - az eredeti szoftvertől független - szerzői mű és ne közös mű jöjjön létre (lásd Selling customized version modell); bár ennek értékelése nyilvánvalóan technikai szempontú vizsgálatot is kíván.
52 Oksanen és Välimäki ezt a folyamatot rights clearingnek nevezi. In: Oksanen, Ville; Välimäki, Mikko: Evaluation of Open Source Licensing Models for a Company Developing Mass Market Software. http://www.cin.ufpe.br/~in953/lectures/papers/EvaluationOfOpenSourceLicensingModelsForSoftwareCompaniesOsLawtech2002.pdf p. 3.
53 BH 545.1993 szerint ha a szoftverfejlesztése egyes fázisai egyéni, eredeti művet eredményezhetnek, ezekre külön szerzői jog keletkezik.
54 Szjt. 30. §
55 Open Source Development Lab, ma már The Linux Foundation http://en.wikipedia.org/wiki/Open_Source_Development_Labs (2010.01.15.)
56 A Berni Uniós Egyezmény 6bis cikke (1) bekezdése értelmében [így hazai szabályozásunk szerint is - Szjt. 9. § (2) bekezdés] a szerző személyhez fűződő jogai elidegeníthetetlenek, így a jogátruházási szerződések tárgya kizárólag a vagyoni jogok lehetnek.
57 Egyes országokban nem szükséges az átadás, mivel a szerzői jog eleve annál a személynél/szervezetnél keletkezik, akinek/melynek a megrendelésére a művet megalkották (work for hire - pl. USA - 17 U.S.C. § 101)
58 A Kommentár szerint »a szerzőség, a szerzőt illető jogok, a közös jogkezelés és a jogsértés következményei tekintetében a törvény kógens. Csak a szerződések körében vannak diszpozitív szabályok, de az engedő jelleg nem terjed ki a szerző "jogállásának" minősítésére.« Lásd Kommentár p. 54.
59 BH 545. 1993 - lásd 51. jegyzet.
60 A koncepció a magyar szabályozásban a felhasználási szerződések alakiságára vonatkozó szabályok figyelembevételével egyértelműen érvénytelen szerződést eredményez. [Szjt. 45. § (1) bekezdés] A felhasználási szerződést - ha e törvény eltérően nem rendelkezik - írásba kell foglalni. Továbbá Szjt. 55. §. A felhasználási szerződésre vonatkozó rendelkezéseket megfelelően alkalmazni kell a szerzői vagyoni jogok átruházására irányuló szerződésekre, valamint az előadóművészi teljesítmények felhasználására vonatkozó szerződésekre is.
61 Például: http://oss.oracle.com/oca.pdf (2010.01.21.)
62 A FSFE az általa kialakított jogátruházási ÁSZF-et Fiduciary Agreement-nek nevezi.
63 A CA rendszerint nem csak a jogátruházás, hanem a fejlesztés során elvárt együttműködés kérdését is leegyszerűsíti, és ezzel szükségtelenné teszi, hogy az egyes projektekben bonyolult együttműködési megállapodások kerüljenek elfogadásra. Az átruházás miatt az együttműködés részletes rendezésének kérdése tulajdonképpen járulékossá válik, hisz a CA alkalmazhatósága jóval szélesebb, mint egy együttműködési megállapodásé.
64 A közösségi fejlesztés során a fejlesztő GPL feltételek szerint kap engedélyt a felhasználásra.
65 A GPL licensz hatálya a szoftver másolására, terjesztésére és módosítására terjed ki ( GPL v2.0 Clause 0. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.)
66 A jogosult rendelkezik az eredeti mű vagyoni jogaival, GPL engedélyt ad a fejlesztő számára, mely lehetővé teszi az eredeti szoftver átdolgozását; a fejlesztő az átdolgozással létrejövő származékos mű vonatkozásában keletkező vagyoni jogait átruházza az eredeti jogosultra, aki így már az eredeti és a származékos mű vagyoni jogaival is rendelkezik.
68 Szjt. 55. §
69 Sőt, tárgya lehet grafika, specifikáció, kézikönyv, dokumentáció vagy egyéb adomány. Lásd például: http://oss.oracle.com/oca.pdf (2010.01.21.)
74 Kommentár p. 43.
75 Kommentár p. 288-289.
76 SzJSzT 02/01, 35/02; EBH 2005/1201
77 Lásd 1. fejezet.
78 Lásd az átdolgozásról írtaknál.
79 Hacsak a vagyoni jogok elidegenítésével ki nem kerülik a copyleft szabályt a fentiek szerint.
80 A kettős licenszelés elemzésekor rendszeresen lehetséges kockázatként jelenik meg a forking kérdése, vagyis az, hogy a nyílt forráskódú fejlesztési modell nemcsak a terméket kontrolláló jogosult számára előnyös, hanem mindazon fejlesztőknek, akik a FLOSS licensz GPL feltételei szerint lehetőséget kapnak a termék átdolgozására és a származékos mű terjesztésére, nekik ugyanis az eredeti termék jogosultjához hasonlóan lehetőségük van "új termék" fejlesztésére (így alakul ki az új ág - fork). A gyakorlati tapasztalatok azt mutatják azonban, hogy az elágazás a szoftver komplexitása és a fejlesztés összetettsége miatt nem gyakori, illetve még ha sor kerül is rá, az eredetihez hasonlóan erős, versenyképes szoftvertermék megalkotása nem ily módon történik.
Lábjegyzetek:
[1] A szerző az IPR-Insights Kft. vezető tanácsadója, licenszelési területének szakmai irányítója; infokommunikációs szakjogász, valamint az ELTE ÁJK PhD hallgatója.
Visszaugrás
