Nyílt forráskód: mit jelent valójában, és mit nem garantál
Van egy pillanat, amit valószínűleg te is ismersz. Keresel egy alkalmazást, végigfutod a leírását, és meglátod a jelzést, hogy nyílt forráskódú. Ez a szó megnyugtat. Utána már nem is nagyon keresel tovább.
Ezt a reflexet évekig működtettem magamon is, és nagyrészt jó irányba visz. A nyílt forráskód valódi és mérhető előnyöket ad, ezért lett nálam alapkövetelmény szinte minden eszköznél. Attól viszont még nem válaszol meg mindent, amit egy szoftverrel kapcsolatban érdemes végiggondolni.
A nyílt forráskód valóban fontos szempont, csak nem magától értetődő, mit jelent pontosan és meddig terjed. Ez a digitális önrendelkezés egyik gyakorlati kérdése, és néhány konkrét szemponton át a legjobban megfogható.
Mit jelent a nyílt forráskód
A forráskód az a réteg, amit a fejlesztő ír, és amit a felhasználó normál esetben soha nem lát. Ez határozza meg, hogy a program mit csinál, hogyan kezeli az adataidat, hová küld információt, és mit tárol el rólad. Zárt szoftvernél ez a réteg a gyártónál marad. Nyílt forráskódú szoftvernél hozzáférhető, megnézhető, letölthető, módosítható.
Van itt egy pontosítás, ami a magyar nyelvű forrásokból szinte mindig kimarad. A kód puszta publikálása önmagában még nem elég ahhoz, hogy valamit nyílt forráskódúnak nevezhessünk. Az Open Source Initiative által gondozott Open Source Definition tíz kritériumot sorol fel, amelyeknek a licencnek meg kell felelnie. Ide tartozik a szabad továbbterjeszthetőség, a származékos művek engedélyezése, és az, hogy a licenc nem tehet különbséget személyek, csoportok vagy felhasználási területek között. Létezik olyan szoftver, amelynek a kódja megnézhető a GitHubon, a licence viszont ezeknek a feltételeknek nem felel meg. Erre külön kifejezés is van, a source available, vagyis a forráskód elérhető, a minősítés viszont nem jár neki.
A másik gyakori félreértés az ingyenesség. A nyitottság a kód hozzáférhetőségére vonatkozik, az árra semmilyen kijelentést nem tesz. Számos nyílt forráskódú termék mellett fut fizetős vállalati változat, támogatási előfizetés vagy felhőszolgáltatás, ami a nyílt alapra épül. A projekt így tartja fenn magát, és ebben semmi ellentmondás nincs.
Mit ad neked a nyitottság
Négy dolog, amit a nyitottság ténylegesen ad, és amiért egyáltalán érdemes szempontnak tekinteni.
Ellenőrizhetőség. A program állításai összevethetők azzal, amit ténylegesen csinál. Egy adatvédelmi vagy titkosítási ígéret zárt szoftvernél bizalmi kérdés marad, hiszen nincs mód utánanézni. Nyílt forráskódnál legalább elvi lehetőség van arra, hogy valaki, aki ért hozzá, megnézze, tényleg úgy működik-e, ahogy a marketinganyag mondja.
Függetlenség egyetlen gyártótól. Ha a fejlesztő eltűnik, csődbe megy vagy egyszerűen más irányba indul, a kód megmarad. Ez a lock-in elleni legfontosabb szerkezeti védelem, és jóval erősebb, mint bármilyen szerződéses ígéret.
Hosszabb élettartam. Régi hardveren gyakran a nyílt forráskódú rendszerek maradnak az egyetlen élő út, miután a gyártói támogatás megszűnt. Van két telefonom a fiókban, amelyek hardveresen hibátlanok, mégis használhatatlanok, mert évekkel ezelőtt megkapták az utolsó rendszerfrissítésüket. Nem elromlottak, hanem lejártak. Egy nyitott rendszernél ez a lejárati dátum sokkal kevésbé van egyetlen cég kezében.
Nyilvános javítási ciklus. A biztonsági hibák és a javításuk folyamata is nyilvános. Nem attól lesz jobb a szoftver, hogy nincs benne hiba, hanem attól, hogy a hiba kezelése átlátható, és nem egyetlen cég belső ügye marad.
Ezek nem elméleti előnyök. Pont ezek miatt érdemes a nyitottságot alapkövetelménnyé tenni, amikor eszközt választasz.
Amit a nyílt forráskód nem garantál
A címke sok mindent takar, és ami alatta van, projektenként nagyon eltérő. Öt pont, amit a nyitottság önmagában nem árul el.
Megnézte-e valaki valójában. A sok szem elve csak akkor működik, ha a szemek ott is vannak. A Heartbleed néven ismertté vált hiba jó példa erre. Az OpenSSL könyvtárba 2011 decemberében került be, a kiadott változatokban 2012 márciusától volt jelen, és csak 2014 áprilisában fedezték fel. Ez a komponens akkoriban a webszerverek körülbelül kétharmadánál működött, a kódja végig nyilvános volt, és mégis nagyjából két évig senki nem vette észre. Kisebb projekteknél ez a probléma még súlyosabb, hiszen ott sokszor egyetlen fejlesztő ír és ellenőriz mindent.
Egyezik-e a futtatott program a közzétett kóddal. Ez a legkevésbé nyilvánvaló pont, és biztonságérzékeny területen a legfontosabb. Amit letöltesz, az általában egy lefordított program, nem maga a forráskód. A kettő közötti kapcsolat nem magától értetődő. A reprodukálható build az a gyakorlat, amivel bárki ellenőrizheti, hogy ugyanabból a forráskódból ugyanaz a bináris jön ki. Ahol ez nincs meg, ott a nyitottság inkább ígéret, mint bizonyíték.
Az irány feletti kontroll. A kód lehet nyílt úgy is, hogy a fejlesztési irányt, a prioritásokat és a hosszú távú stratégiát egyetlen cég határozza meg. Elméletben bárki elágaztathatja a projektet, ha nem tetszik az irány. A gyakorlatban ehhez erőforrás, közösség és éveken átívelő elkötelezettség kell, ami ritkán áll rendelkezésre.
A szolgáltatás zárt fele. Sok esetben a kliens nyílt forráskódú, a szerveroldal viszont zárt. Ilyenkor a nyitottság csak arra a rétegre igaz, ami a saját gépeden fut, arra viszont nem, ami a másik oldalon történik az adataiddal.
Amit a licenc megenged. A licenc a nyitottság mellett is szabhat olyan feltételeket, amelyek szűkítik a mozgástered, például azzal, hogy a módosított változataidat nem terjesztheted. Ez a kérdéskör önálló téma, a szabad szoftver fogalma erre válaszol, és külön cikket érdemel.
A nyitottság a gyakorlatban
A nyitottság minősége területenként nagyon eltérő, és ezt konkrét példákon lehet a legjobban látni.
Az operációs rendszereknél a Linux disztribúciók adják a legtisztább esetet. Aktív, széles közösség, több évtizedes fejlesztési előzmény, és valós alternatíva egy olyan gépen, amit a gyártó már leírt. Itt a nyitottság ténylegesen kihasznált, nem csak deklarált.
A böngészőknél árnyaltabb a kép. A Firefox motorja és a Chromium alapja is nyílt forráskódú, a rájuk épülő böngészők viszont nagyon eltérő mértékben adnak vissza kontrollt a felhasználónak, erről külön is írtam a böngészők adatvédelmi összehasonlításában. Ugyanaz a nyílt alap, gyökeresen eltérő adatkezelési gyakorlatokkal. Ez pont az a helyzet, ahol a címke önmagában semmit nem árul el a lényegről.
A mindennapi eszközöknél, mint a LibreOffice, a VLC vagy a Signal, a nyitottság mellé aktív közösség és rendszeres külső ellenőrzés társul. Ez az a kombináció, ami a nyílt forráskódot ténylegesen értékessé teszi.
A biztonságérzékeny területeken, például a hardveres tárcák firmware-énél, a nyitottság már alapfeltétel, nem pusztán előny. Ott a bizalom teljes egészében azon múlik, hogy a kód ellenőrizhető, és lehetőleg reprodukálhatóan is fordítható legyen. Ez közvetlenül összefügg azzal, hogyan tárolod biztonságosan a saját kulcsaidat.
Hogyan ellenőrizd egy projekt megbízhatóságát
Öt kérdés, ami néhány perc alatt sokkal többet mond, mint maga a címke.
| Kérdés | Jó jel | Gyenge jel |
|---|---|---|
| Él-e még a projekt? | Friss módosítások, több aktív fejlesztő, kezelt hibabejelentések | Egy-két éve nincs mozgás, sok válaszolatlan hiba |
| Ki tartja fenn? | Alapítvány vagy elosztott közösség | Egyetlen fejlesztő vagy egyetlen cég teljes kontrollal |
| Volt-e külső biztonsági audit? | Nyilvános auditjelentés, a talált hibákkal együtt | Nincs audit, vagy csak említés részletek nélkül |
| Van-e reprodukálható build? | A forráskódból bárki ugyanazt a binárist kapja | A letöltött program és a kód kapcsolata nem ellenőrizhető |
| Mi van a nyílt réteg körül? | A lényegi rész is nyílt, nincs kötelező zárt komponens | Zárt szerveroldal vagy kötelező szolgáltatás, ami nélkül használhatatlan |
Ezek a kérdések nem minden eszköznél számítanak azonos súllyal. Egy médialejátszónál a legtöbbjük fölösleges. Egy jelszókezelőnél vagy egy hardveres tárcánál mindegyik releváns.
Miért nem elég önmagában a nyílt forráskód
A nyitottság nálam alapkövetelmény lett, és ez azóta sem változott. A mérce viszont szigorodott, mert menet közben kiderült, hogy a címke túl sok mindent takar.
Két szoftver ugyanazzal a nyílt forráskódú megjelöléssel teljesen eltérő mértékű kontrollt adhat. Az egyik mögött aktív közösség, nyilvános audit és reprodukálható build áll. A másiknál egy cég publikálja a kódot, közben minden lényeges döntést maga hoz, és a szolgáltatás fele zárt marad. A különbség nem a kód nyitottságában van, hanem abban, ami körülötte történik.
A címke egyetlen dolgot állít, azt, hogy a kód elvileg látható. A többi, hogy ki nézte meg, ki dönt az irányáról, és mennyi marad belőle a te kezedben, már néhány perc utánanézésen múlik.
Gyakori kérdések
A nyílt forráskódú szoftver mindig ingyenes?
Nem. A nyitottság a forráskód hozzáférhetőségére vonatkozik, nem az árra. Számos nyílt forráskódú termék mellett létezik fizetős vállalati változat, támogatási előfizetés vagy felhőszolgáltatás.
Biztonságosabb egy nyílt forráskódú program, mint egy zárt?
Nem automatikusan. A nyitottság lehetőséget ad az ellenőrzésre, de nem garantálja, hogy valaki élt is vele. Egy aktívan karbantartott, auditált projekt jellemzően biztonságosabb egy zártnál, egy elhanyagolt viszont nem feltétlenül.
Mi a különbség a nyílt forráskód és a source available között?
A source available annyit jelent, hogy a forráskód megnézhető. A minősítéshez ezen felül a licencnek meg kell felelnie az Open Source Definition tíz kritériumának, például engednie kell a szabad továbbterjesztést és a származékos műveket.
Honnan tudom, hogy egy program tényleg nyílt forráskódú?
Nézd meg a licencét, ne csak a marketingszöveget. Az Open Source Initiative jóváhagyott licenceinek listája nyilvános, és ha egy projekt licence szerepel rajta, az egyértelmű jelzés.
A nyílt forráskód azt jelenti, hogy szabadon használhatom bármire?
Nem szükségszerűen. A licenc szabhat feltételeket a módosításra, a terjesztésre és a felhasználás módjára. Ez már a szabad szoftver kérdésköre, ami a felhasználó jogairól szól, nem pusztán a kód láthatóságáról.
Ha tovább mennél
Ez a cikk szándékosan nem merül el licencjogi részletekben. Aki közvetlenül az elsődleges forrásokból szeretné megérteni a nyílt forráskód pontos feltételeit, ezeken érdemes tovább olvasnia:
- Az Open Source Definition az Open Source Initiative-től, a tíz kritériummal, amelyeknek egy licencnek meg kell felelnie
- Az OSI által jóváhagyott licencek listája, ahol bármelyik projekt licence visszakereshető
- A Reproducible Builds projekt, a forráskód és a lefordított program közötti kapcsolat ellenőrzéséről
- A Heartbleed hiba hivatalos leírása, ha érdekel, hogyan maradhat évekig észrevétlen egy súlyos hiba nyilvános kódban