052.1 Lecke 1

Az ingyenes (free) és nyílt (open) forráskódú szoftverek már jó ideje léteznek, és ezek a kifejezések gyakran együtt jelennek meg. Azonban van némi eltérés aközött, amit egyesek “szabad szoftvernek” (free software) mondanak, és az ingyenes szoftver (free software), valamint a nyílt forráskódú szoftver (open source software) formális jelentése között. Spoiler: A “nyílt forráskód” nem csak azt jelenti, hogy bárki megnézheti a forráskódot — ez “elérhető forrású” (source available) szoftver lenne. Az ingyenes és nyílt forráskódú szoftverek ennél sokkal többet jelentenek.

A szabad és nyílt forráskódú szoftvereket szembeállítjuk más, jogvédettnek (proprietary) vagy zárt forráskódúnak (closed source) tekintett szoftverekkel, mivel ezek nem teszik lehetővé az ebben a leckében tárgyalt összes szabadságot.

A szabad szoftver talán legtöbbet idézett definíciója a következő:

A következő fejezetekben kibontjuk az ebben a kijelentésben rejlő részleteket. Fordítói megjegyzés: az angolban a szabad és az ingyenes fogalmakat ugyanaz a “free” szó jelöli.

Egyrészt a fejlesztők dönthetnek úgy, hogy egyszerűen lemondanak a szoftverük értékesítésével járó jutalmakról és nehézségekről, és egyszerűen csak ellenszolgáltatás nélkül adják tovább. Magyarul ez a szoftver “ingyenes” abban az értelemben, hogy senkinek sem kell fizetnie érte, de csak úgy ingyenes, mint a sör, amit elajándékoznak. Ez a költségmentes terjesztés nem mond semmit a további licencfeltételekről, és a felhasználóra hagyja azt a kötelezettséget, hogy mindig alaposan ellenőrizze: lehet, hogy nem kapta meg a szükséges jogokat például a szoftver módosításához vagy további terjesztéséhez.

Másrészt a fejlesztők dönthetnek úgy, hogy szoftverüket “szabad szoftverré” teszik Stallman értelmezésében. Ez a kifejezés (amelyet az 1980-as években talált ki) a felhasználó alapvető szabadságaira utal, amelyeket a következőképpen foglalhatunk össze:

A “szabad szoftver” ebben a meghatározásban a Free Software Foundation (FSF) által támogatott kifejezés, amely bevezette a copyleft kifejezést (amelynek nincs jogi jelentése, hanem filozófiai megfontolást fejez ki) a szabad szoftverek licencének jellemzésére.

A szabad szoftver mozgalomból a nyílt forráskód hívei az 1990-es évek végén váltak ki, hogy a szabad szoftvereket könnyebben érthetővé és népszerűbbé tegyék a mozgalmon kívüliek körében. 1998-ban megalakult egy nonprofit alapítvány, az Open Source Initiative (OSI), és Linus Torvalds, a Linux kernel eredeti szerzője támogatta a koncepciót. Az Open Source Initiative formalizálta a Open Source Definition-t, amely a következő kritériumokat tartalmazza:

A Free Software Foundation nem támogatta a “nyílt forráskód” kifejezést, mivel ragaszkodott hozzá, hogy az elrejti a szabadság kulcsfontosságú célját. Így, bár a szabad szoftver és a nyílt forráskódú szoftver hívei látszólag ugyanazt a koncepciót követik és támogatják, a mozgalmaknak külön motivációik vannak. Leegyszerűsítve, a szabad szoftverek hívei a fejlesztők és a felhasználók jogait hangsúlyozzák, míg a nyílt forráskód hívei a szoftverek széleskörű használatát és sikerét helyezik előtérbe.

Többé-kevésbé igaz az, hogy minden szabad szoftver nyílt forráskódúnak minősül, de számos olyan licenc létezik, amely nyílt forráskódúnak tekinthető (OSI által jóváhagyott), de az FSF szerint nem szabad.

Mivel a szabad és a nyílt forráskód közötti különbségek inkább a célokat és a motivációkat, mint a licencek tartalmát érintik, és mivel mindkét kifejezést továbbra is gyakran használják, sokan a szabad és nyílt forráskódú szoftver (FOSS) vagy szabad/ingyenes és nyílt forráskódú szoftver (free/libre and open source software — FLOSS) kifejezésekkel együtt használják a két meghatározást. A “libre” kifejezés számos latin nyelvben a szabadságra utal.

A FOSS és a szabadalmaztatott szoftverek széles kategóriái mellett számos más terjesztési stratégia is létezik. Néhány ilyen stratégia a következő:

Mindenekelőtt: Ha egy bizonyos forráskódfájlhoz vagy projekthez nem áll rendelkezésre licencinformáció, nem feltételezhetjük azt, hogy a fájl vagy a projekt ne rendelkezne szerzői jogi védelemmel. Valójában ennek éppen az ellenkezője a helyzet, legalábbis mióta a legtöbb nemzet világszerte aláírta az 1887 óta érvényes Berni Egyezményt (Berne Convention).

Ebben a szerződésben az aláíró nemzetek megállapodnak abban, hogy az irodalmi vagy művészeti alkotás szerzői jogi védelemben részesül, amint létezik (vagy más szóval, amint “rögzítik” valamely hordozóra). Ez azt jelenti, hogy a szerzőnek nem kell bejegyeztetnie vagy kérelmeznie a szerzői jogot. Néhány országban még mindig megtehetik, és a regisztrációra szükség lehet a jogsértési keresetekhez néhány joghatóságban, beleértve az Egyesült Államokat is.

Az aláírók továbbá vállalják, hogy tiszteletben tartják egy másik aláíró ország szerzőinek szerzői jogait, ami 2022 novemberében a világ 195 országából 181-et jelentett.

Azonban nem minden, valaha létrehozott alkotás áll szerzői jogi védelem alatt. Ahhoz, hogy az alkotás szerzői jog által védett munkának minősüljön, az alkotásnak meg kell felelnie néhány alapvető kritériumnak: például a tények és az ötletek nem részesülhetnek szerzői jogi védelemben, de egy ötletet kifejtő szöveg védelmet élvezhet, ha az eredetiség bizonyos fokát eléri. Az eredetiség mértéke világszerte eltérő, de sok esetben nagyon alacsony a védelemhez szükséges korlát. Számos joghatóság jelenleg azt mérlegeli, hogy a mesterséges intelligencia milyen mértékben használható fel ahhoz, hogy olyan művet hozzon létre, amely megérdemli az eredetiséget és ezáltal a szerzői jogot.

A számítógépes programok a joghatóságtól függően irodalmi művekként szerzői jogi védelemben részesülnek: vagyis a szerzői jog nem az ötletre vagy algoritmusra, hanem annak forráskódban történő megvalósítására vonatkozik.

A szerzői jog (többek között) a szerzőt kizárólagos jogokkal ruházza fel a mű másolására, módosítására, allicencbe adására, terjesztésére és közzétételére. A mű befogadása szabad, így nincs szükség engedélyre ahhoz, hogy valaki elolvasson egy könyvet vagy meghallgasson egy dalt a rádióban, amennyiben ez nem igényli állandó másolat készítését.

Mivel a szerzői jogok regisztráció nélkül keletkeznek, bárkinek, aki más szerző művét másolni, módosítani, allicencbe adni, terjeszteni vagy közzétenni kívánja, előbb engedélyt kell kérnie. Itt jönnek a képbe az engedélyek, mint szerződések a mű szerzője és az olyan személy között, aki a szerző egyes kizárólagos jogait gyakorolni kívánja.

A FOSS-licencek bárki számára díjmentesen elérhetők. Bárki létrehozhatja saját licencét, és megpróbálhatja azt az OSI vagy az FSF által jóváhagyatni. Erősen ajánlott azonban egy már létező FOSS licenc használata, mivel a licencek általánosan elfogadottak, és a szoftverek hozzáértő felhasználói jól ismerik a licenc tartalmát és kötelezettségeit. Valójában az FSF vagy az OSI által jóváhagyott számos licenc közül általánosan csak néhányat használnak.

A szerzői joggal ellentétben, amely nem védi az ötleteket, a szabadalom a találmányokat (ötleteket) védi anélkül, hogy az ötletet (még) gépben vagy eljárásban rögzíteni kellene. További különbség, hogy a feltalálóknak kifejezetten szabadalmat kell kérelmezniük, azt pedig be kell jegyeztetniük annak az országnak a szabadalmi hivatalánál, ahol az oltalmat igénylik.

Anélkül, hogy túl mélyen belemerülnénk a szabadalmi jogba és annak követelményeibe, csak egy nagyon központi kérdésre hívjuk fel a figyelmet: a szabadalmi oltalomhoz (más kritériumok mellett) egy bizonyos műszaki szempontú ötletre van szükség. Hagyományosan egy új ételrecept vagy egy új társasjáték ötlete nem jogosult szabadalmi oltalomra, míg egy új főzőgép vagy egy játékkonzol ötlete jogosult lehet.

A számítógépes programozással összefüggésben felmerül a kérdés, hogy a szoftverek szabadalmi oltalom alá vonhatók-e. Ez mind a joghatóságtól, mind az adott alkalmazástól függ: Németországban például a számítógépes programok, mint olyanok általában ki vannak zárva a szabadalmi oltalom alól. Ha azonban a programokat fizikai tárggyal kombinálják — például amikor a szoftver egy autó automatikus fékrendszerét vezérli --, akkor a szabadalmi oltalom a fék fizikai elemét tartalmazó alkalmazásra kérhető, nem pedig a szoftverre mint olyanra.

Más joghatóságokban, például az Egyesült Államokban, az esetjog alakulásától függően a számítógépes programokra, mint olyanokra is adható szabadalom.

A szabadalmi oltalom koncepcióját a FOSS-licencelés során is szem előtt kell tartani. Egyes licencek (mint például a GPLv3) lehetővé teszik a szabadalmaztatást a FOSS-szoftverekre, kifejezetten engedélyezve a szoftver használatát. Egyes licencek azonban nem is említik a szabadalmakat (mint például a BSD-3-Clause licenc), más licencek pedig kifejezetten kizárják azokat (mint például a Creative Commons licencek). Bizonyos körülmények között azonban a szabadalom megadása magában foglalhatja a licencet, vagy beleolvasható a licencbe.

Főként a beágyazott szoftverek, például az audioeszközökben lévő szoftverek esetében különös figyelmet kell fordítani a szoftverhez kapcsolódó szabadalmakra, például a szoftver szerzőinek szabadalmi ellenőrzésével.

Amint már említettük, a licencek szerződések egy mű szerzője és egy olyan személy között, aki a szerző kizárólagos jogainak egy részét gyakorolni kívánja. A kiterjedtebb FOSS-licencek némelyike, például a GNU General Public Licences 2. és 3. verziója tartalmaz rendelkezéseket a szerződés felmondására vonatkozóan. A FOSS-licencek mindig tartalmazzák a központi szabadságjogokra vonatkozó jogok biztosítását. Általában a következő jogok szerepelnek vagy olvashatók bele a licenc szövegébe:

A Licenc-stewardok olyan személyek, vagy sok esetben szervezetek, mint például az FSF, akik a licencek verzióit kezelik. A GPLv2 9. szakasza például az FSF-et nyilvánítja licencfelelősnek:

Egyes licenc-stewardok gyakran ismételt kérdéseket (GYIK, FAQ) is közzétesznek, hogy segítsenek megválaszolni az engedélyekkel kapcsolatos kérdéseket. Ezek hasznosak lehetnek az engedélyes (licensee) és az engedélyező (licensor) közötti beszélgetés elindítójaként.

Amikor a fejlesztők egy csoportja kódot épít be a saját projektjébe valaki más projektjéből, az eredmény lehet egy származékos (derivate) vagy származtatott (derived) munka. A részletek projektről projektre és licencről licencre változnak, és mivel a részletek a szoftverfejlesztési technikák némi kifinomultságát igénylik, mondjunk csak annyit, hogy a fejlesztőknek meg kell győződniük arról, hogy a kódot a licencnek megfelelően építik be.

A származékos művekkel kapcsolatos legfontosabb kérdés, hogy egyes licencek, például a GPL esetében a származékos műveket ugyanazon licenc alatt kell kiadni. Az ilyen licenceket reciprokálisnak nevezik.

A kölcsönös követelmény közvetlen gyakorlati jelentősége abban áll, hogy ha a GPL alá tartozó kódot úgy használjuk fel a saját projektünkben, hogy az származékosnak minősül, akkor fel kell fednünk a forráskódunkat, és hagynunk, hogy mások termékeket építsenek rá. Ezt a licencelési követelményt nagyon szeretik azok a fejlesztők, akik bátorítani akarják az embereket, hogy használjanak szabad licenceket. A licenc azonban csökkenti a GPL vonzerejét néhány olyan fejlesztő számára, akik potenciálisan felhasznáhatják a szabad kódot.

Sok más szabad és nyílt forráskódú licenc nem írja elő ezt a követelményt. Ezeket általában engedélyező (permisszív) licenceknek nevezik.

Ha a terjesztés időpontjában a licencfeltételek nem teljesülnek (pl. ha a GPLv3 licenc alatt álló, bináris formában terjesztett szoftverhez nem csatolják a forráskódot), akkor a licencszerződés megszegésre kerül. A licenc megsértésének következményei a licenctől függnek. A GPLv3 licenc megsértése például a licenc felmondásához vezethet. Minden további, a szerző engedélyét igénylő művelet, például a szoftver terjesztése, szerzői jogsértésnek minősül.

Ha egy vállalat GPLv3 licencű szoftvert épít be egy termékbe, és megsérti a licencet, akkor a vállalatot a termék visszahívására kötelezhetik. A szerzői jogok szándékos megsértése akár büntetőjogi felelősségre vonást is eredményezhet.

Egyes engedélyek külön záradékot tartalmaznak, amely lehetővé teszi az engedélyes számára, hogy a jogsértést az értesítéstől számított 30 napon belül orvosolja. Ha a szoftvert forgalmazó személynek sikerül ezen időszakon belül betartania a licencben foglaltakat, a licenc újra érvénybe lép.

A nagy szoftverprojektek gyakran különböző licencek alá tartozó szoftvereket tartalmaznak, amelyek mindegyike egyedi követelményeket határoz meg. Az ilyen projektek akadályokba ütközhetnek, ha olyan szoftvert használnak, amely megköveteli, hogy a licencét a származékos művekre is alkalmazzák. Ennek oka, hogy az ilyen copyleft licencek licencfeltételei eltérhetnek egymástól, ami összeegyeztethetetlenné teszi őket. Egy olyan szoftverprojekt közzététele vagy terjesztése, amely különböző copyleft licencek alá tartozó komponenseket integrál, nem biztos, hogy lehetséges anélkül, hogy az egyik licencet megsértené.

Néhány copyleft licenc kifejezetten felsorolja a kompatibilis licenceket, ami megkönnyíti egy copyleft licencű komponens használatát egy másik copyleft licenc alatt.

A legtöbb megengedő licenc kompatibilis más licencekkel. Például az MIT-licenc alatt álló komponensek felhasználhatók egy GPLv3 licenc alatt álló projektben anélkül, hogy a licencek megsértését kockáztatnánk. Ugyanakkor egy GPLv3 licencelt komponens nem minden esetben használható egy MIT licencelt projektben anélkül, hogy megsértené a GPLv3 feltételeit. A kompatibilitás tehát nem mindig működik mindkét irányban.

Mielőtt egy szoftverprojektet piacra dobnának, a fejlesztőknek és jogi tanácsadóiknak alapos licenckompatibilitási ellenőrzést kell végezniük, hogy elkerüljék a licencjogok megsértését. A nyílt forráskódú megfelelőség-menedzsmentet már a szoftverfejlesztési folyamat korai szakaszába be kell építeni, hogy elkerülhető legyen a szoftver terjesztésének késedelme, amelyet például a licenc-kompatibilitási problémák okoznak. Alaposan át kell kutatni a forráskódot az alkalmazandó licencek után (pl. szoftverellenőrző eszközök segítségével), és ellenőrizni kell, hogy minden licencfeltétel teljesül-e.

Egyes szoftverek többféle licenc alatt is elérhetők. Például egy engedélyező dönthet úgy, hogy kettős licenceléssel licenceli a projektjét egy copyleft licenc, például a GPLv3 és egy zárt licenc alatt is. A zárt licencre például akkor lehet szükség, ha a potenciális licencvevő a kódot saját jogvédett termékébe építi be. Minden fejlesztő maga dönti el, hogy betartja a GPLv3 feltételeit, vagy beszerzi a szabadalmi licencet, és valószínűleg licencdíjat fizet.

Amint arra már korábban rámutattunk, egyes szoftverek különböző licencek alá tartozó komponenseket tartalmazhatnak, eltérő licencfeltételekkel. Bár a legtöbb licenc gyakran nem okoz inkompatibilitást, a különböző licencek eltérő követelményeket támaszthatnak a szoftver különböző részeivel szemben.