Zenelejátszó program – Szoftverjogi gyorstalpaló
Az elkészülő zenelejátszó programért nem szeretnék pénzt kérni, valamint azt szeretném, hogy szabadon használható és módosítható legyen. Ez a definíció hétköznapi nyelven érthető, de a jog sajna nem ennyire egyszerű. Éppen ezért, mielőtt belevágunk a fejlesztésbe, egy picit foglalkoznunk kell szoftverjogi kérdésekkel.
A jog nem egy egyszerű téma és én nem is vagyok jogász. Éppen ezért már az elején szeretném leszögezni, hogy amit írok, azt a saját fejlesztői tapasztalataimból és az interneten fellelhető információkból raktam össze. Ez nem helyettesít egy komoly szoftverjogi tanácsadást.
Ha szoftvert fejlesztünk, akkor a kód tekintetében beszélhetünk zárt forráskódú és nyílt forráskódú szoftverekről.
A zárt forráskód azt jelenti, hogy a program fejlesztője rendelkezik annak a forráskódjával, amit nem oszt meg mással. Tipikusan ilyen a kereskedelmi forgalomban kapható szoftverek többsége.
A zárt forráskód egyik problémája, hogy ha találok egy hibát a rendszerben, akkor a program készítőjére vagyok utalva, hogy azt kijavítsa nekem. Ez, ha fizettünk a programért, jogos elvárás, de számos olyan program is van, ami ingyenesen használható, de zárt forráskódú.
Zárt forráskódú termékekkel általában akkor szokott probléma lenni, ha a készítő már nem támogatja a programot és/vagy a fejlesztő már rég feledésbe merült. Ebben az esetben hiába rendelkezünk a tudással, ami a hiba kijavításához kellene, mégsem tudjuk megtenni, mivel a forráskódot nem ismerjük.
Természetesen manapság már tart ott a technika, hogy akár C/C++ nyelven íródott programok binárisaiból is vissza lehet nyerni az eredeti kódot (Pl.: „Rekonstruálták a legendás Diablo játék forráskódját” vagy „Visszafejtették több Grand Theft Auto játék forráskódját, beindulhatnak a modderek„). Ezt a folyamatot szokás reverse engineering-nek nevezni, de általában a végfelhasználói (licensz) szerződés ki szokta kötni, hogy ezt nem szabad, illetve ha nem is köti ki, akkor sem biztos, hogy jogszerű (Pl.: „Korai volt a modderek öröme, a Take-Two lecsapott a GTA forráskódokra„).
A végfelhasználói (licensz) szerződés minden zárt forráskódú program velejárója. Ezt a szoftver használója a szoftver használatával elfogadja és lényegében definiálja, hogy az adott szoftver milyen feltételek teljesülése mellett használható. Ezek feltételek lehetnek akár komolyan korlátozóak is.
A hiba kijavítás lehetősége, a program működésének megismerhetősége elvek mentén született meg a nyílt forráskódú szoftver gondolata. Ez az ötlet nem új keletű. Valamikor az 1980-as évek elejéhez és a számítógépek tömeges elterjedéséhez köthető. A szabad szoftver mozgalom egyik ikonikus alakja Richard Matthew Stallman 1985-ben alapította meg a Free Software Foundation (FSF) alapítványt, azzal a céllal, hogy támogassa a szabad szoftver mozgalmat és a GNU projektet.

A GNU projekt célja egy bárki által szabadon használható és fejleszthető Unix-szerű, de nem Unix (a GNU rekurzív mozaikszó a GNU is Not Unix rövidítése) operációs rendszer létrehozása volt. Az 1990-es évek elejére a projekt rendelkezett nagyjából mindennel, ami a kor operációs rendszerétől elvárás volt, csak egy rendszermag nem volt hozzá. Ezt szállította 1991-ben egy Linus Torvalds nevezetű fiatalember a Linux kernel segítségével. A többi pedig már történelem.
A GNU projekt definiált egy licensz szerződést magának, ami a GNU GPL lett. Ebből több változat is született az évek alatt. Jelenleg a 3-as változata a legfrissebb és leginkább használt.
A GPL fő kikötése az, hogy ha ez alatt adod ki a programod forráskódját, majd valaki ezt módosítja, akkor a módosítást végző illetőnek is kötelessége a GPL feltételei szerint továbbadnia a program kódját.
De nem csak a GPL létezik, ha nyílt forráskódról beszélünk. Vannak kevésbé korlátozó licenszek is, mint például az MIT Licensz. Ez röviden és tömören a program készítőjét rögzíti, azt, hogy szabadon módosítható a kód, illetve azt, hogy a programra a készítője semmi felelősséget nem vállal (A GPL is kiköti ugyanezt, illetve nagy általánosságban a legtöbb nyílt forráskód licensz).
Ez attól lesz megengedő, hogy a leszármazott művekre nem kell alkalmazni a licensz megkötéseit. Ezt jelenti, hogy a kód teljes egészét vagy részleteit is beépíthetem akár egy másik nyílt forráskódú vagy zárt forráskódú projektbe is. Egyetlen kikötés, hogy ha a kódunk MIT licenszelt kódrészleteket tartalmaz, akkor fel kell tüntetni az eredeti szerzőt is a végfelhasználói licenszben, hogy az ő munkája alapján készült a program.
Hasonlóan megengedőek a BSD típusúak is, amiből igazából négy fajta is létezik a kikötések tekintetében. A 0 kikötéses mindent megenged: módosítást, másolást, továbbterjesztést, minden célra való felhasználást.
A két kikötéses változat leginkább az MIT licenszre hasonlít. Ha ilyen kódot használ fel a program, akkor fel kell tüntetni az eredeti készítő nevét.
A három, illetve négy megkötéses változatok a reklámozásra való megkötéseket tartalmaznak.
A BSD típusú licenszeket nem meglepő módon leginkább a BSD operációs rendszerek szokták alkalmazni. A 3 és 4 megkötéses licensz megszületésének az volt az apropója, hogy voltak olyan kereskedelmi terméket gyártó cégek, akik egy az egyben BSD-t alkalmaztak a termékben és nyíltan ezzel is reklámozták a terméket, viszont a szoftver eredeti készítőit semmilyen módon nem támogatták, ami jogilag persze lehetséges, de semmiképpen sem menő lépés.
Ha ez még mindig nem lenne elég jogi megkötésekből, léteznek még a „Mozilla” típusba sorolandó licenszek. Ezek közös jellemzője az, hogy egy adott márka felhasználásáról, pontosabban fel nem használhatóságáról rendelkeznek. Tipikusan ilyen szoftver a Firefox. Szabadon módosítható, akár zárt forráskódú program is készülhet belőle, de az így létrejött szoftvert nem lehet Firefox-nak nevezni.
Egy jó összefoglaló a különböző licenszek megkötéseiről a https://choosealicense.com/licenses/ oldalon található.
Ezen felül vannak még olyan nyílt forráskódú licencek, amik a szabadalmak felhasználhatóságáról vagy fel nem használhatóságáról nyilatkoznak. Ezekbe most csak röviden mennék bele, mert nem kis téma és radikálisan eltér a világ különböző részein. Például Amerikában (USA) szabadalmaztatható egy algoritmus, általánosan megfogalmazott eljárás is, feltéve ha van elég pénzünk a jogi procedúrára. Röviden és tömören ezeket nevezzük szoftver szabadalmaknak. Európában szerencsére picivel komplikáltabb a helyzet. Nem lehet bármit leszabadalmaztatni.
Az hogy pontosan mi is szabadalmaztatható vagy mi nem, azt általában szabadalom jogász bevonásával érdemes eldönteni, de általános iránymutatás, hogy csak olyan szoftvert lehet leszabadalmaztatni, ami közvetlenül kötődik a fizikai világhoz.
Így fordulhat elő, hogy a MP3 tömörítés és kitömörítés algoritmusa bárki által megismerhető, de ha ezt az algoritmust egy célhardverre ültetem át és erre terméket építek, akkor elképzelhető, hogy valaki ezt már leszabadalmaztatta és fizetnem kell neki jogdíjíjat.
A legutolsó példa kicsit sántít, mivel az MP3-ra vonatkozó szabadalom 2017-ben lejárt. Ami lényeg azonban, hogy ha szabadalmakról is szó van, akkor mindenképpen kérjük ki egy szabadalmi ügyekben járatos jogász véleményét, mert nagyon nem triviális téma.
Az elkészülő programot az MIT licensz szerint fogom közzétenni. Személy szerint a választásom azért esett erre, mert oktató jelleggel készül a cikksorozat. A tudás meg mindenkié kellene, hogy legyen. Ha azonban a sorozat alapján egy sikeres terméket készítesz, vagy hasznosnak találod, akkor egy kávéra vagy sörre is meghívhatsz.
Ezzel a gondolattal zárnám is a cikket, amiből tudom sok minden kimaradt, esetleg pontatlan (kommentben ér jelezni), de így is hosszúra nyúlt ez a rész. Folytatása következik.
2021.09.15. @ 13:35
Szia!
Nagyon tetszik az oldal, rengeteg hasznos info van itt, a könyvről nem is beszélve.
A cikk kapcsán érdekelne, hogy pontosan miként kell megírni kiadott program kapcsán a felhasznált lib-eknél az Apache és az MIT által megköveteli LICENSE.txt és NOTICE fájlokat, ha egyszerre több lib is érintett. Szívesen látnék a témába cikket.
Üdvözlettel T-Bácsi