Information Technology | UNIX / Linux » Open Source Essentials, 1.0

Table of Contents TÉMAKÖR 051: SZOFTVER ALAPISMERETEK . 1 051.1 Szoftverkomponensek 2 Lecke 1 . 3 Bevezetés . 3 Mi az a szoftver? . 3 Programozási nyelvek . 4 Programozási paradigmák . 13 Gyakorló feladatok . 15 Gondolkodtató feladatok. 16 Összefoglalás. 17 Válaszok a gyakorló feladatokra. 18 Válaszok a gondolkodtató

feladatokra . 19 051.2 Szoftverarchitektúra 21 Lecke 1 . 22 Bevezetés . 22 Szerverek és kliensek . 23 Webalkalmazások . 24 Alkalmazásprogramozási interfész (API). 26 Architektúra típusok. 28 Gyakorló feladatok . 32 Gondolkodtató feladatok. 33 Összefoglalás. 34 Válaszok a gyakorló feladatokra.

35 Válaszok a gondolkodtató feladatokra . 37 051.3 On-premise és felhőalapú számítástechnika 38 Lecke 1 . 39 Bevezetés . 39 Helyi és felhőalapú számítástechnika . 39 Gyakori felhő-üzemeltetési modellek . 41 A felhőszolgáltatások gyakori típusai . 43 A felhőalapú számítástechnika és a helyhez kötött IT-infrastruktúra főbb előnyei és kockázatai . 44 Gyakorló feladatok . 47 Gondolkodtató feladatok.

48 Összefoglalás. 49 Válaszok a gyakorló feladatokra. 50 Válaszok a gondolkodtató feladatokra . 51 TÉMAKÖR 052: NYÍLT FORRÁSKÓDÚ SZOFTVERLICENCEK . 52 052.1 A nyílt forráskódú szoftverlicencek fogalma Lecke 1 . Bevezetés . A nyílt forráskódú szoftver és a szabad szoftver definíciói . Szabad, mint a beszéd: Igazi szabadság a felhasználók számára. Nyílt forráskódú szoftver . Szabadság vs nyílt forráskód . A

pénzügyileg szabad szoftverek egyéb fajtái . A szerzői jog alapelvei és azok hatása a nyílt forráskódú szoftverlicencekre . A szabadalmi jog alapelvei . Licencszerződések . Származékos munkák . A licenc megsértésének következményei . Licenc kompatibilitás és inkompatibilitás . Kettős licencelés és többszörös licencek . Gyakorló feladatok . Gondolkodtató feladatok. Összefoglalás. Válaszok a gyakorló feladatokra.

Válaszok a gondolkodtató feladatokra . 052.2 Copyleft szoftverlicencek Lecke 1 . Bevezetés . A Copyleft és a GNU General Public License (GPL) . A GNU Affero General Public License (AGPL) . A copyleft licencek kompatibilitása . Kombinált és származékos művek. Gyengébb copyleft . Gyakorló feladatok . Gondolkodtató feladatok. Összefoglalás.

Válaszok a gyakorló feladatokra. Válaszok a gondolkodtató feladatokra . 052.3 Megengedő szoftverlicencek Lecke 1 . Bevezetés . A permisszív szoftverlicencek jogai és kötelezettségei. A legfontosabb engedélyköteles szoftverlicencek jellemzői . Permisszív szoftverlicencek és más nyílt forráskódú licencek viszonya. Gyakorló feladatok . 53 55 55 56 56 57 58 58 59 60 61 62 63 63 64 65 67 68 69 71 72 74 74 74 79 80 80 81 84 85 86 87 88 90 91 91 92 92 97 99 Gondolkodtató feladatok .

Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . TÉMAKÖR 053: NYÍLT TARTALMI LICENCEK . 053.1 A nyílt tartalmi licencek koncepciója Lecke 1 . Bevezetés . A szerzői jog alapjai . Származékos művek. A nyílt tartalmi licencek általános jellemzői . A nyílt tartalmi licencek jelentősége . Védjegyek és szerzői jogok .

Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 053.2 Creative Commons licencek Lecke 1 . Bevezetés . A Creative Commons eredete és céljai . A Creative Commons licenc moduljai . A Creative Commons alaplicencek. Creative Commons Zero (CC0) és a Public Domain Mark.

Licencek kiválasztása és a művek jelölése . Nemzetközi és portolt licencek. Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 053.3 Egyéb nyílt tartalmi licencek Lecke 1 . Bevezetés . Licencek (szoftver) dokumentációhoz . Licencek adatbázisokhoz.

Open Access . Gyakorló feladatok . Gondolkodtató feladatok . 100 101 102 104 105 106 108 108 109 111 111 112 113 114 115 116 117 118 119 120 120 121 122 124 127 128 131 132 133 134 135 136 137 138 138 138 140 144 147 148 Összefoglalás . Válaszok a gyakorló feladatokra . TÉMAKÖR 054: NYÍLT FORRÁSKÓDÚ ÜZLETI MODELLEK . 054.1 Szoftverfejlesztési üzleti modellek Lecke 1 . Bevezetés . A szoftver vagy tartalom nyílt licenc alatt

történő kiadásának céljai és okai . Gyakori üzleti modellek és bevételi források . Nyílt forráskódú szoftverek használata más technológiákban és szolgáltatásokban . A nyílt forráskódú szoftverek szempontjai az ügyfél szemszögéből . Költségstruktúrák és beruházások . Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 054.2 Szolgáltatói üzleti modellek Lecke 1 .

Bevezetés . Bevételi források. A licencek hatása . Biztonsági és adatvédelmi megfontolások. Gyakori megállapodások a szolgáltató és az ügyfél között . Költségstruktúrák és beruházások . Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 054.3 Compliance és kockázatcsökkentés

Lecke 1 . Bevezetés . A nyílt forráskódú komponenseken alapuló szoftverek kiadásának követelményei . A nyílt forráskódú szoftverek kockázatai . Szoftver darabjegyzék: tudjuk, mit használunk . Hivatalos irányelvek és megfelelőség . Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . 149 150 152 153 155 155 156 157 159 160 161 163 164 165 166 167 168 170 170 170 173 173 175 176 178 179 180 181 182 183 185 185 185

188 191 193 196 197 198 199 Válaszok a gondolkodtató feladatokra . TÉMAKÖR 055: PROJEKTMENEDZSMENT . 055.1 Szoftverfejlesztési modellek Lecke 1 . Bevezetés . Szerepkörök a szoftverfejlesztésben . Tervezés és ütemezés . Általános eszközök . Vízesésmodell . Agilis szoftverfejlesztés, Scrum és Kanban. DevOps. Gyakorló feladatok .

Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 055.2 Termékmenedzsment / Release menedzsment Lecke 1 . Bevezetés . A releasek jellemzői . Szoftver verziózás: Major, minor, és patchek. A szoftvertermék életciklusa. A termékverziók dokumentációja . Gyakorló feladatok .

Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 055.3 Közösségi menedzsment Lecke 1 . Bevezetés . Szerepkörök a nyílt forráskódú projektekben . Gyakori feladatok nyílt forráskódú projektekben . A nyílt forráskódú hozzájárulások fajtái . A nyílt forráskódú közreműködők típusai. A szervezetek szerepe a nyílt

forráskódú projektekben. A jogok átruházása. Szabályok és irányelvek . Hozzájárulás és átláthatóság . Sokszínűség, egyenlőség, befogadás és diszkriminációmentesség. 200 201 202 203 203 203 205 205 205 208 214 216 217 218 219 220 221 222 222 222 225 226 227 229 230 231 232 233 234 236 236 236 238 239 240 240 242 243 244 244 Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . TÉMAKÖR 056:

EGYÜTTMŰKÖDÉS ÉS KOMMUNIKÁCIÓ . 056.1 Fejlesztőeszközök Lecke 1 . Bevezetés . A fejlesztés céljai . Általános fejlesztési folyamatok . Általános szoftverfejlesztési eszközök. A szoftvertesztelés általános típusai . Általános telepítési környezetek . Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás .

Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 056.2 Forráskódmenedzsment Lecke 1 . Bevezetés . Forráskódmenedzsment-rendszer és a repository . Commitok, tagek és branchek . Subrepositoriek. A forráskódmenedzser-rendszer általános használata . Gyakori verziókezelő rendszerek . Gyakorló feladatok . Gondolkodtató feladatok .

Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . 056.3 Kommunikációs és együttműködési eszközök Lecke 1 . Bevezetés . A kommunikáció formái . Kommunikációs eszközök . Kollaborációs eszközök . Forráskód menedzsment (Source Code Management SCM) . Dokumentáció. 246 247 248 249 250 251 252 254 254 254 255 258 262 264 266 267 268 269 270 271 272 272

273 274 276 276 277 279 280 281 282 283 284 286 286 287 289 293 297 298 Gyakorló feladatok . Gondolkodtató feladatok . Összefoglalás . Válaszok a gyakorló feladatokra . Válaszok a gondolkodtató feladatokra . Impresszum . 299 300 301 302 303 304 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 1 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek 051.1 Szoftverkomponensek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0511 Súlyozás 2 Kulcsfontosságú

ismeretek • A forráskód és a kódvégrehajtás fogalmának megértése • A fordítóprogramok és az értelmezők fogalmának megértése. • A szoftverkönyvtárak fogalmának megértése A használt fájlok, kifejezések és segédprogramok listája • Forráskód • Futtatható programok • Bájtkód • Gépi kód • Fordító • Linker • Interpreter • Futásidejű virtuális gép • Algoritmus • Szoftverkönyvtárak • Statikus és dinamikus linkelés 2 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 051 Szoftver alapismeretek Fejezet: 051.1 Szoftver komponensek Lecke: 1/1 Bevezetés A szabad (free) és nyílt forráskódú szoftvereket (open source software) gyakran rövidítik FOSSnak mindennapi életünk szerves részévé váltak, többnyire anélkül, hogy ennek tudatában

lennénk. A FOSS például minden internetes tevékenységünk mögött megtalálható valamilyen formában: a számítógépen, ahol a böngészőben weboldalakat nézegetünk, vagy a szervereken, amelyek tárolják ezeket a weboldalakat, és amint meghívjuk, azonnal megjelenítik őket. Mi az a szoftver? Mielőtt azonban megvizsgálnánk a szabad és nyílt forráskódú szoftverek sajátosságait, tisztáznunk kell, hogy mi is valójában a szoftver. Kezdjük egy nagyon általános leírással: a szoftver bármilyen formában a számítógépek nem fizikai, immateriális része. A szoftver biztosítja, hogy a számítógép fizikai részei (a hardver) kölcsönhatásba lépjenek egymással, és azt, hogy a számítógép képes legyen parancsokat fogadni és feladatokat végrehajtani. Egy okostelefon, egy laptop vagy egy szerver az adatközpontban csak egy fémből és műanyagból készült gép, ha kikapcsolják. Amint bekapcsolják, elindul a szoftver, olyan kódolt

parancssorozatok formájában, amelyek ennek a gépnek az egyes komponenseit vezérlik, amelyek Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 3 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek lehetővé teszik, hogy a felhasználó interakcióba lépjen a géppel, és amelyek az egyes alkalmazások meghívásával nagyon specifikus feladatokat hajtanak végre. A szoftverfejlesztők dolga, hogy elemezzék azokat a feladatokat, amelyeket a számítógépnek végre kell hajtania, és úgy határozzák meg azokat, hogy képes is legyen azokat elvégezni. A fejlesztők által használt eszközök olyan sokfélék és változatosak, mint a szoftver által végrehajtott feladatok. Egyes szoftveres feladatok nagyon szorosan kapcsolódnak a hardverhez és a számítógép architektúrájához, például a memória címzése és kezelése vagy a különböző processzek (folyamatok) kezelése. A rendszerprogramozók ezért a

hardverhez közel dolgoznak Az alkalmazásfejlesztők ezzel szemben inkább a felhasználóra összpontosítanak, és olyan alkalmazásokat programoznak, amelyek lehetővé teszik a felhasználók számára, hogy hatékonyan és intuitív módon végezzék feladataikat. Egy összetett alkalmazásra példa lehet egy szövegszerkesztő program, amely a szövegformázáshoz szükséges összes funkciót menükben vagy gombokban biztosítja, és a szöveget úgy is megjeleníti, ahogyan az végül nyomtatásra kerülhet. Általában az algoritmus egy probléma megoldási módja. Például egy átlag kiszámításához a szokásos algoritmus az, hogy összeadjuk értékek gyűjteményét, és az összeget elosztjuk az értékek teljes számával. Bár az algoritmusokat hagyományosan programozók tervezik és hajtják végre, manapság már a mesterséges intelligencia is generál algoritmusokat. Az ebben a fejezetben található fogalmak segíthetnek megérteni a FOSS erősségeit és

kockázatait, megalapozott döntéseket hozni, és akár azt is eldönteni, hogy szoftverfejlesztővé szeretnénk-e válni. Programozási nyelvek A programozási nyelvek erősen strukturált, mesterséges nyelvek, amelyek megmondják a számítógépnek, hogy mit tegyen. A programokat általában szöveges formában írják, de egyes nyelvek grafikus formájúak. A szoftverfejlesztők ezen a mesterséges nyelven írnak utasításokat (úgynevezett kódot) a számítógépnek. A számítógép hardvere azonban nem hajtja végre közvetlenül ezt a kódot. A hardver közvetlenül csak a memóriában tárolt bitminták sorozatát, az úgynevezett gépi kódot vagy gépi nyelvet tudja végrehajtani. Minden programozási nyelvet vagy egy compiler (fordító) alakít át gépi kóddá, vagy egy másik gépi kódú program, az úgynevezett interpreter (értelmező) értelmezi, hogy a hardver végre tudja hajtani ezeket az utasításokat. A jelenleg legelterjedtebb programozási nyelvek

közé tartozik a Python, a JavaScript, a C, a C++, a Java, a C#, a Swift és a PHP. Mindegyik programozási nyelvnek megvannak a maga egyedi erősségei és gyengeségei, a nyelv kiválasztása pedig a projekttől és a fejlesztő igényeitől függ. A Java például népszerű választás nagyvállalati alkalmazások fejlesztésekor, míg a Pythont gyakran 4 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek használják tudományos számításokhoz és adatelemzéshez. A fejlesztők lenyűgöző kreativitásról tettek tanúbizonyságot a programozási nyelvek megtervezése során. Eredetileg alacsony szintű nyelvek voltak, amelyek a számítógép utasításaihoz hasonlítottak. A nyelvek egyre inkább magas szintűvé váltak, ami azt jelenti, hogy az utasítások erőteljes kombinációit rövid kifejezésekkel próbálják ábrázolni. Egyes nyelvek az emberek természetes

gondolkodásmódját tükrözik, miközben megőrzik a helyes futtatáshoz szükséges szigort. Jelenleg körülbelül 400 programozási nyelvet ismernek, bár sokat közülük csak nagyon szűk piaccal rendelkező alkalmazásokban vagy legacy (hagyaték) környezetben használnak. Mindegyiket bizonyos feladatok megoldására fejlesztették ki. A programozási nyelvek karakterisztikája, szintaxisa és felépítése A programozási nyelv kiválasztása jelentős hatással lehet egy szoftverprojekt teljesítményére, skálázhatóságára és könnyű fejleszthetőségére. Ezek a szakaszok a nyelvek fontos elemeit ismertetik. A programozási nyelvek karakterisztikája A programozási nyelvek néhány közös jellemzője és tulajdonsága a következő: Párhuzamosság (concurrency) A párhuzamosság több feladat egyidejű kezelését jelenti, akár különböző hardverprocesszorokon történő futtatással, akár egyetlen processzor váltakozó használatával. A programozási

nyelv által támogatott párhuzamosság mértéke nagymértékben befolyásolhatja a nyelv teljesítményét és skálázhatóságát, különösen a valós idejű feldolgozás vagy nagy adatmennyiséget igénylő alkalmazások esetében. Az egyes különálló elemeket nevezhetjük folyamatnak (process), feladatnak (task) vagy szálnak (thread). Memóriakezelés (memory management) A memóriakezelés a memória kiosztása és felszabadítása egy programban. A nyelvtől vagy a futási környezettől függően a memóriakezelést a programozó végezheti manuálisan, vagy automatikusan. A megfelelő memóriakezelés kulcsfontosságú annak biztosításához, hogy a program hatékonyan használja a memóriát, és hogy az ne fogyjon el, illetve ne okozzon egyéb problémákat. Ha egy program nem szabadítja fel a fel nem használt memóriát, akkor a program memóriaszivárgást (memory leak) okoz, amely fokozatosan növeli a memóriahasználatot, amíg a program össze nem omlik, vagy

a teljesítményben negatív hatások nem jelentkeznek. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 5 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Megosztott memória (shared memory) A megosztott memória a folyamatok közötti kommunikációs mechanizmus egy típusa, amely lehetővé teszi, hogy több processz olvassa és kezelje a memória egy közös régióját. A megosztott memória gyakori a hardverekben, például a lemezmeghajtókban és hatékony módja lehet a folyamatok közötti adatmegosztásnak is. A mechanizmus azonban gondos szinkronizálást és kezelést igényel az adatsérülések megelőzése érdekében. A race condition néven ismert hiba akkor lép fel, ha az egyik folyamat váratlanul megváltoztatja az adatokat, miközben egy másik processz használja azokat. Üzenettovábbítás (message passing) Az üzenettovábbítás egy olyan kommunikációs mechanizmus a folyamatok között, amely

lehetővé teszi számukra az adatcserét és tevékenységeik koordinálását. Ezt általában a párhuzamos programozásban használják a folyamatok közötti kommunikáció megvalósítására, és különböző mechanizmusokon keresztül valósítható meg, például socketekkel, csővezetékekkel (pipe) vagy üzenetsorokkal (message queue). Szemétgyűjtés (Garbage collection) A szemétgyűjtés egy automatikus memóriakezelési technika, amelyet egyes programozási nyelvek használnak a folyamat futása közben, a már nem használt memória visszanyerésére. Ez segíthet a memóriaszivárgások megelőzésében, és megkönnyítheti a fejlesztők számára a helyes és hatékony kód írását, de teljesítménybeli többletköltséget is okozhat, és megnehezítheti a program pontos viselkedésének ellenőrzését. Adattípusok (data types) Az adattípusok határozzák meg, hogy a programban milyen típusú információ jeleníthető meg. Az adattípusok lehetnek a

nyelvben előre meghatározottak vagy felhasználó által definiáltak, és lehetnek egész számok, lebegőpontos számok (azaz a valós számok közelítései), sztringek, tömbök és egyebek. Bemenet és kimenet (input és output) (I/O) A bemenet és a kimenet olyan mechanizmusok, amelyekkel adatokat olvashatunk és írhatunk egy programba, illetve egy programból. A bemenetnek különböző forrásai lehetnek, például felhasználói kattintások és billentyűleütések, egy fájl vagy hálózati kapcsolat, míg a kimenet különböző célállomásokra küldhető, például egy kijelzőre, egy fájlba vagy egy hálózati kapcsolatra. Az I/O lehetővé teszi a programok számára, hogy kölcsönhatásba lépjenek a külvilággal, és információt cseréljenek más rendszerekkel. Hibakezelés (error handling) A hibakezelés a program végrehajtása során fellépő hibákat észleli, és reagál azokra. Ide tartoznak az olyan hibák, mint a nullával való osztás vagy a nem

talált kért fájl. A hibakezelés 6 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek lehetővé teszi, hogy a programok hiba esetén is folytassák a futást, javítva ezzel megbízhatóságukat és robusztusságukat. Az imént felsorolt fogalmak alapvető fontosságúak a programozási nyelvek működésének megértéséhez, valamint a hatékony és karbantartható kód megírásához. A programozási nyelvek szintaxisa Egy programozási nyelv szintaxisa a program utasítások és kifejezések írására vonatkozó szabályokat jelenti. Fontos, hogy a szintaxis jól definiált és konzisztens legyen, hogy a programozó hatékonyan tudja megírni és megérteni a kódját. A legtöbb programozási nyelv építőkövei a következők: Eljárások (procedures) és függvények (functions) Az eljárásokat és függvényeket újrafelhasználható kódblokkok definiálására

használják, amelyek többször is meghívhatók. Változók (variables) A változók a memória darabjait képviselik, és olyan manipulálhatók és átadhatók eljárások és függvények között. adatokat tárolnak, amelyek Operátorok (operators) Az operátorok olyan kulcsszavak vagy szimbólumok (például + és -), amelyek értékeket rendelnek a változókhoz és aritmetikai műveleteket végeznek el. Vezérlési szerkezet (control structure) A programkód általában abban a sorrendben hajtódik végre, ahogyan meg van írva, de a feltételes utasítások (conditional statement) megváltoztatják a végrehajtás menetét. Az, hogy melyik kódot hajtjuk végre legközelebb, különböző feltételeken alapul, például a memória tartalmán, a billentyűzet állapotán, a hálózatról érkező csomagokon stb. Az iterációs utasítás (loop statement) a feltételes utasítás egy speciális formája, arra alkalmas, hogy ugyanazokat a műveleteket hajtsa végre egy sor

adathalmazon. A kivétel (exception), amely hiba esetén speciális kódot hív elő, egy másik vezérlési struktúra. Ezeknek a konstrukcióknak a szintaxisa és viselkedése programozási nyelvenként eltérő lehet, a nyelvválasztás pedig nagy hatással lehet a kód olvashatóságára és karbantarthatóságára. Könyvtárak Egy jó programozási nyelvnek meg kell könnyítenie a programok fejlesztését és a meglévő kód újrafelhasználását. Sok programozási nyelv rendelkezik olyan mechanizmussal, amellyel az Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 7 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek eljárásokat és függvényeket más programokban újrafelhasználható részekre lehet szervezni. A könyvtár (library) egy adott funkciót vagy célt támogató eljárások és funkciók gyűjteménye, egyetlen fájlban egyesítve. Az egyik nagyon fontos követelmény egy jó programozási nyelvvel

szemben, hogy sok könnyen használható könyvtár álljon rendelkezésre. A Python például széles körben elismert jó nyelv a mesterséges intelligenciával kapcsolatos programok fejlesztéséhez, mivel számos, mesterséges intelligencia feldolgozására alkalmas könyvtárral rendelkezik. A programok méretének és összetettségének növekedésével a könyvtárak, mint kész építőelemek egyre fontosabbá válnak. Ez különösen igaz a nyílt forráskódú világban, ahol az emberek szívesen veszik át és használják újra a mások által készített kódot. Ennek eredményeképpen minden programozási nyelvhez kialakult egy könyvtárakból álló ökoszisztéma, és az olyan csomagkezelők, mint a PHP esetében a composer, a Python esetében a pip és a Ruby esetében a gems, megkönnyítik a könyvtárak telepítését. A könyvtárak szintén fontosak a fordított nyelvek számára. Az egy futtatható fájl lérehozásához szükséges, több bináris fájl és

előre lefordított könyvtár kombinálását linkelésnek, és az ezt a műveletet végző eszközt linker-nek nevezik. A linkelésnek két típusa van: A statikus linkelés, amikor csak a szükséges könyvtárkódot tartalmazza a végleges alkalmazás végrehajtható fájlja, és a dinamikus linkelés, amikor a rendszerbe telepített könyvtárat az azt használó összes alkalmazás megosztja. Jelenleg a dinamikus linkelés az előnyben részesített megközelítés, amelyet a kisebb méretű futtatható alkalmazások és a kisebb memóriahasználat jellemez futásidőben. Vegyük figyelembe, hogy mivel ugyanazokat a könyvtárakat több program is használhatja, a könyvtárak változatai közötti különbségek még nagyobb problémát jelenthetnek, mint az alkalmazások esetében. Kalandozzunk el egy kicsit és idézzük fel, hogyan kell nézni a verziószámokat. Általánosan használatos a Semantic versioning, amely a verziókat három, pontokkal elválasztott számmal

jelöli. Egy tipikus verzió lehet a 23916, ami egy 2-es főverziót jelöl (ez a szám valószínűleg csak néhány évente egyszer változik), egy 39-es mellékverziót a főverzión belül (ami néhány havonta frissülhet, és fontos funkcióváltozásokat tartalmazhat), és egy 16-os gyorsváltású revíziót (ami egyetlen hibajavítás (bugfix) miatt változhat). A későbbi verziók és revíziók magasabb számokkal rendelkeznek. Egy egyszerű példa Nézzünk meg egy nagyon egyszerű példát egy számítógépes programra Python nyelven, hogy nagyjából képet kapjunk az említett elemek közül néhányról. Természetes nyelven megfogalmazva, a programnak a következőket kell tennie: “Kérje meg a felhasználót, hogy adjon meg egy számot, és ellenőrizze, hogy ez a szám páros vagy páratlan! Végül írja ki az eredményt!” 8 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511

Szoftverkomponensek És itt van a kód, amit elmenthetünk az simpleprogram.py fájlba: num = int(input("Adjon meg egy szamot: ")) if (num % 2) == 0: print("A megadott szam PAROS.") else: print("A megadott szam PARATLAN.") Még ebben a néhány sornyi kódban is megtalálhatjuk a fent említett jellemzők és szintaxiselemek nagy részét: 1. Az 1 sorban beállítjuk a num változót és hozzárendelünk egy értéket az = operátorral 2. A hozzárendelt érték megfelel a felhasználó bemenetének (az input() függvényen keresztül) Ezenkívül az int() függvény biztosítja, hogy ez a bemenet lehetőség szerint egész szám adattípussá konvertálódjon. A függvénynek zárójelben átadott kifejezést paraméternek vagy argumentumnak nevezzük. 3. Ha a felhasználó egy betűsorozatot ír be, a Python a hibakezelés részeként hibát ír ki Ha egy tizedes számot adunk meg, az int() függvény átalakítja azt az egész számra, például az

5.73 -at 5-re. 4. A következő sorokban a vezérlési szerkezet egy feltétel, az if és else kulcsszavakkal szabályozza, hogy mi történik a két lehetséges eset (a szám páros vagy páratlan) mindegyikében. 5. Először a modulo operátor azt vizsgálja, hogy ha (if) a beírt szám 2-vel való osztása 0 értéket ad (azaz nincs maradék) akkor a szám páros. A megduplázott == az “egyenlő” összehasonlító operátor, amely különbözik az 1. sorban szereplő = hozzárendelési operátortól 6. A másik esetben (else), azaz amikor a 2-vel való osztás eredménye nem 0, a beírt számnak páratlannak kell lennie. 7. Mindkét esetben a print() függvény az eredményt, vagyis kimenetet szöveges formában adja vissza. És így néz ki, amikor futtatjuk a programot a parancssorban: $ python simpleprogram.py Adjon meg egy szamot: 5 A megadott szam PARATLAN. Ha belegondolunk, hogy már ebben a kis példában is mennyi nyelvi logika van, akkor képet kapunk arról, hogy

mire képesek a több ezer fájlra elosztott komplex szoftverek; például az olyan Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 9 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek operációs rendszerek, mint a Microsoft Windows, a macOS vagy a Linux, amelyek egy számítógép összes hardverét elérhetővé teszik, ugyanakkor biztosítják, hogy a felhasználók minden más kívánt alkalmazást telepíteni tudjanak, és azokat munkára vagy szórakozásra használhassák. Gépi kód, Assembly nyelv és az assemblerek Mint korábban említettük, a hardver közvetlenül csak egy sor bitmintát, az úgynevezett gépi kódot képes végrehajtani. A CPU egy bitmintát szóegységekben (8-64 bit) olvas be a memóriából, és végrehajtja a hozzá tartozó utasítást. Az egyes utasítások meglehetősen egyszerűek, például: “A memóriahely tartalmának átmásolása a B memóriahelyre,” “C memóriahely

tartalmának szorzása a D memóriahely tartalmával,” vagy "az X címre érkezett adat beolvasása az eszközre.`" A 8 bites CPU-k korában egyesek képesek voltak megjegyezni a gépi kódban használt összes bitmintát, és közvetlenül programokat írni. Manapság az utasításminták száma nagyságrendekkel megnőtt, és az összes ilyen minta megjegyzése nem túl praktikus. A gépi kód bitminták, azaz 0-k és 1-ek sorozata, ami az ember számára egyáltalán nem intuitív. A programozás intuitívabbá tételére hozták létre az assembly nyelvet, amelyben az utasítások nevet kaptak, és sztringekkel adhatók meg. Az assembly nyelven az utasításokat, amelyek egy az egyben megfelelnek a gépi kódnak, egyenként írják le. Az utasítások így nézhetnek ki: move [B], [A] az A memória tartalmának másolása a B memóriába multi R1, [C], [D] C memória tartalmának megszorzása a D memória tartalmával. input R1, [X] az X címre érkezett adatok

beolvasása. Egy utasítás az assembly nyelven egy utasításnak felel meg a gépi kódban, ami pontosan annak az utasításnak felel meg, amelyet a hardver megért és végre tud hajtani. Az assembly nyelv előnyei a gépi nyelvvel szemben a következők: Jobb olvashatóság és karbantarthatóság A gépi kódnál sokkal könnyebb olvasni és írni. Ez megkönnyíti a programozók számára a kód megértését, valamint a hibakeresést és a karbantartást. Címszámítás automatizálása A gépi kódú programozás is használhatja a változók és függvények fogalmát, de mindent memóriacímekben kell kifejezni. Az assembly nyelv neveket is rendel a memóriacímekhez, ami megkönnyíti a program logikájának kifejezését. Mivel az assembly nyelv hozzáfér a hardver összes funkciójához, általában a következő esetekben használják: 10 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511

Szoftverkomponensek Az operációs rendszer architektúrafüggő része Az inicializálási és biztonsági funkciókhoz való hozzáférésre szolgáló, egy adott CPUarchitektúrára jellemző utasítások használata csak assembly nyelven lehetséges. Alacsony szintű rendszerelemek fejlesztése A számítógép hardverével közvetlenül együttműködő rendszerelemek, például az eszközillesztőprogramok, a firmware és az alapvető input/output rendszer (BIOS) fejlesztésére használják az Assembly nyelvet. Különösen azokhoz a nagysebességű eszközökhöz, amelyek a hardver teljesítményének határait feszegetik, gyakran assembly nyelven programozott illesztőprogramokra és firmware-re van szükség. Mikrokontrollerek programozása Ezek kis, alacsony teljesítményű számítógépek, amelyeket a beágyazott rendszerek széles skáláján használnak a játékoktól az ipari vezérlésig. Egyes mikrokontrollerek memóriakapacitása mindössze néhány száz bájt,

és általában assembly nyelven programozzák őket. Az assembly nyelvi kódot egy asszembler nevű alkalmazás gépi kóddá alakítja át, mielőtt végrehajtaná. Az assembler a legrégebbi programozási eszköz, és számos olyan előnnyel jár, amely a gépi kódú programozásban elképzelhetetlen volt. A zűrzavar kedvéért néha az emberek az assembly nyelvet assemblerként emlegetik. A gépi kód és az assembly nyelv hardveres processzoronként eltérő. Azért nevezik őket “alacsony szintű nyelveknek” (low-level languages), mert közvetlenül a hardveren működnek. A számítás és a bemenet/kimenet fogalma azonban minden processzoron ugyanaz. Ha a közös fogalmakat az emberek számára könnyebben érthető módon lehet kifejezni, a programozás hatékonysága drámaian javulhat. Itt jönnek a képbe a “magas szintű nyelvek” (high-level languages) Fordított nyelvek A fordított nyelvek (compiled languages) olyan programozási nyelvek, amelyeket vagy gépi

kódra, vagy egy köztes formátumra, az úgynevezett bytecode-ra (bájtkód) fordítanak le. A bytecode-ot a célszámítógépen egy futásidejű virtuális gép hajtja végre. A virtuális gép lefordítja a bytecode-ot az egyes számítógépeknek megfelelő gépi kódra. A bytecode lehetővé teszi, hogy a programok platformfüggetlenek, és bármely kompatibilis virtuális géppel rendelkező rendszeren futtathatóak legyenek. A magas szintű programozási nyelven írt forráskód gépi kódra vagy bytecodera történő lefordítását egy fordító (compiler) végzi. A közvetlenül gépi kódot előállító fordított nyelvekre példa a C és a C++. A bytecodeot előállító nyelvek közé tartozik a Java és a C# Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 11 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek A gépi kód és a bytecode közötti választás a projekt követelményeitől függ, például a

teljesítménytől, a platformfüggetlenségtől és a fejlesztés egyszerűségétől. Értelmezett nyelvek Az értelmezett nyelvek (interpreted languages) olyan programozási nyelvek, amelyeket egy értelmező (interpreter) hajt végre, ahelyett, hogy gépi kódba fordítaná. Az interpreter beolvassa a forráskódot és végrehajtja a benne szereplő utasításokat. Az interpreter képes közvetlenül feldolgozni a forráskódot, anélkül, hogy azt más fájlformátumba alakítaná át. Így a compilerrel ellentétben, amely a teljes programot a végrehajtás előtt gépi kóddá fordítja le, az interpreter minden egyes kódsort beolvas és azonnal végrehajt, lehetővé téve a programozó számára, hogy az egyes sorok eredményét végrehajtás közben lássa. Az értelmezett nyelveket általában scriptelésre (scripting) használják, ami a feladatokat automatizáló rövid programokra, parancssori interfészekre, valamint batch és jobok vezérlésére utal. Az

interpreteres nyelveken írt scriptek könnyen módosíthatók és újbóli fordítás nélkül is végrehajthatók, így jól alkalmazhatók olyan feladatokhoz, amelyek gyors prototípus-fejlesztést vagy rugalmas és gyors iterációt igényelnek. Ezzel a kényelemmel együtt jár néhány lehetséges hátrány is. Például egy értelmezett program lassabban fut, mint a vele egyenértékű fordított program, valamint a forráskód bárki számára hozzáférhető, aki a script birtokában van. Az értelmezett nyelvek közé tartozik például a Python, a Ruby és a JavaScript. A Pythont széles körben használják a tudományos számítástechnikában, az adatelemzésben és a gépi tanulásban, míg a Rubyt gyakran használják a webfejlesztésben és automatizálási scriptek készítéséhez. A JavaScript egy kliensoldali scriptnyelv, amely a webböngészőkbe ágyazva dinamikus és interaktív weboldalak létrehozására szolgál. Adatorientált nyelvek Az adatorientált

nyelvek (data-oriented languages) olyan programozási nyelvek, amelyeket nagy mennyiségű adat feldolgozására és kezelésére optimalizáltak. Úgy tervezték őket, hogy hatékonyan kezeljenek nagy mennyiségű strukturált vagy strukturálatlan adathalmazt, valamint biztosítják az adatbázisokkal, adatstruktúrákkal, és az adatfeldolgozáshoz és -elemzéshez szükséges algoritmusokkal való munkavégzéshez szükséges eszközkészletet. Az adatorientált nyelveket számos alkalmazásban használják, többek között az adattudományban, a nagy adatelemzésben (big data) , a gépi tanulásban és az adatbázis-programozásban. Jól alkalmazhatók olyan feladatokhoz, amelyek nagy mennyiségű adat feldolgozásával és elemzésével járnak, például adattisztítás és -átalakítás, adatvizualizáció és statisztikai modellezés. Az adatorientált nyelvek közé tartozik például az SQL (a Structured Query Language rövidítése), 12 | learning.lpiorg | CC

BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek az R és a MATLAB. Az SQL a relációs adatbázisok kezelésére használt szabványos nyelv, amelyet széles körben használnak az üzleti és ipari életben. Az R egy statisztikai számításokhoz és grafikákhoz használt programozási nyelv és környezet, amelyet széles körben használnak az adattudományban és a gépi tanulásban. A MATLAB egy numerikus számítási környezet és programozási nyelv, amelyet számos alkalmazásban használnak, többek között a jelfeldolgozásban, a képfeldolgozásban és a pénzügyi számításokban. Programozási paradigmák A programozási nyelvek sajátosságai mellett a programozási paradigmák határozzák meg az adott megoldási megközelítést. Egy paradigmára gondolhatunk úgy, mint egy alapvető stratégiára, amellyel egy feladatot megközelítünk, a konkrét követelményektől és feltételektől

függően. Hasonló példa lehet egy ház építése: Az, hogy a falakat téglánként kőművesek húzzák fel, vagy a helyszínen kész betonelemeket állítanak össze, alapvető döntés, amely az igényektől és a körülményektől függ. Milyen tulajdonságokkal rendelkezzen a ház? Hol helyezkedik el? Összekapcsolódik-e más házakkal? Hasonló módon a paradigmák határozzák meg a programozás irányát: hogy például egy szoftverprojektet kisebb, különálló részekre bontanak-e és ha igen, milyen módon. Minden programozási nyelv egy adott paradigmához illeszkedik a legjobban. Ezért a paradigmaválasztás szorosan összefügg a programozási nyelv kiválasztásával. A következő paradigmák gyakoriak a programozásban: Objektumorientált programozás (OOP) Az OOP az objektumok koncepcióján alapul, amelyek az osztályok példányai, amelyek adatokat és viselkedést foglalnak magukba. Például lehet egy nyelvben a téglalap egy osztály, hogy segítsen a

programozónak egy doboz megjelenítésében a képernyőn. Az OOP az adatok objektumszintű manipulációjára összpontosít. Az OOP megkönnyíti a karbantartható, újrafelhasználható és bővíthető kód írását, és széles körben használják desktop és webes alkalmazásokban, videojátékokban. Az objektumorientált programozási nyelvek közé tartozik például a Java, a C# és a Python. Procedurális programozás A procedurális programozás a feladatokat eljárások, azaz meghatározott sorrendben végrehajtható kódblokkok segítségével hajtja végre. Ez megkönnyíti a könnyen követhető, strukturált kód írását, de a projekt méretének és összetettségének növekedésével kevésbé rugalmas és nehezebben karbantartható kódot eredményezhet. A procedurális programozási nyelvek közé tartozik például a C, a Pascal és a Fortran. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 13 Open Source Essentials

(Version 1.0) | Témakör 051: Szoftver alapismeretek A szoftverfejlesztésnek ma más megközelítései is használatosak, amelyekhez egyes nyelvek jobban alkalmazhatók, mint más nyelvek. Emellett a drag-and-drop felületek lehetővé teszik, hogy a nem programozók is írhassanak programokat, valamint a közelmúltban számos online szolgáltatás elkezdett kódot generálni mesterséges intelligencia segítségével, egyszerű nyelvi utasításokból. Összefoglalva, minden programozási paradigmának megvannak a maga erősségei és gyengeségei, és a paradigma kiválasztása gyakran függ a projekt igényeitől, a fejlesztő tapasztalatától és preferenciáitól, valamint a platform és a fejlesztési környezet korlátaitól. A paradigmák különböző típusainak megértése segíthet az igényeknek megfelelő paradigma kiválasztásában, és lehetővé teheti a jobb és hatékonyabb kód írását. 14 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve |

Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek Gyakorló feladatok 1. Mi a függvények célja? 2. Mi az előnye a bytecodenak a gépi kódú fájlokkal szemben? 3. Mi az előnye a gépi kódú fájlnak a bytecode-dal szemben? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 15 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Gondolkodtató feladatok 1. Milyen hátrányai vannak annak, ha egy programot nagyszámú folyamatokra vagy feladatokra osztunk? 2. Számos olyan nyílt forráskódú csomagot találhatunk, amelyek különböző verziókban kínálnak olyan funkciókat, amelyekre szükségünk van a programunkhoz. Milyen szempontok alapján kell kiválasztanunk egy csomagot? 3. Az OOP és a procedurális fejlesztési paradigmákon kívül milyen más szoftverfejlesztési megközelítések léteznek, és melyik az a programozási nyelv, amelyik a legjobban támogatja az

egyes megközelítéseket? 16 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek Összefoglalás Ebben a leckében megtanultuk, hogy mi az a szoftver és hogyan fejlesztik a programozási nyelvek segítségével. A számos programozási nyelv nemcsak a szintaxisukban különbözik, hanem például a hardveres erőforrások vagy az adatszerkezetek kezelésében is. A programozási nyelvek abban is különböznek, hogy az ember által olvasható forráskódot egy értelmező vagy fordítóprogram hogyan alakítja át a számítógép által feldolgozandó végleges gépi kóddá. A programozási paradigmák meghatározzák a szoftverprojektek stratégiáját, és így a megfelelő programozási nyelvek kiválasztását is, az adott projekt követelményeitől és méretétől függően. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 17 Open Source

Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Válaszok a gyakorló feladatokra 1. Mi a függvények célja? A függvények bizonyos általános tevékenységeket, például egy sztring kiírását foglalják magukba. Egy függvény létrehozásával lehetővé tehetjük, hogy a programunk és más programok kényelmesen és ismételten elvégezhessék a funkciót anélkül, hogy saját kódot kellene írniuk hozzá. 2. Mi az előnye a bytecodenak a gépi kódú fájlokkal szemben? A bytecode fájl több különböző számítógépen is futtatható, ahol egy virtuális gép a kódot gépi kóddá alakítja. A JavaScript például sok böngészőben, sokféle számítógépen fut 3. Mi az előnye a gépi kódú fájlnak a bytecode-dal szemben? A gépi kód a lehető leggyorsabban fut. A bytecode lassabban fut, mert a virtuális gépnek a bytecode futtatása közben gépi kóddá kell azt alakítania. 18 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve |

Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0511 Szoftverkomponensek Válaszok a gondolkodtató feladatokra 1. Milyen hátrányai vannak annak, ha egy programot nagyszámú folyamatra vagy feladatra osztunk? Amikor egy program folyamatokra van osztva, azoknak kommunikálniuk kell egymással. Ha sok közös adaton dolgoznak, akkor a folyamatok sok költséget fordíthatnak az adatcserére és az adatok védelmére a többszörös, egyidejű változásoktól (versenyfeltételek, race conditions). A folyamatok indításkor és befejezéskor is többletköltséget okoznak. Minél több folyamat van, annál összetettebbé válik a program és annak kölcsönhatásai, így a hibákat nehezebb lehet megtalálni. A funkcionális paradigma általában megkönnyíti a programok sok folyamatra való felosztását, a megváltoztathatatlanság miatt. A megváltoztathatatlan adatok nem szenvednek a versenyfeltételektől. 2. Számos olyan nyílt forráskódú csomagot

találhatunk, amelyek különböző verziókban kínálnak olyan funkciókat, amelyekre szükségünk van a programunkhoz. Milyen szempontok alapján kell kiválasztanunk egy csomagot? Ellenőrizzük a hibajelentéseket és a csomagokra vonatkozó biztonsági tanácsokat, mert némelyik nagyon hibás és akár az is lehet, hogy nem biztonságos! Nem mindig a legújabb verzió a legjobb, mert lehet, hogy biztonsági hiba van benne. Nézzük át a fórumot, ahol a fejlesztők beszélgetnek a csomagról, hogy lássuk, aktívan karbantartják-e! A programunkat valószínűleg hosszú ideig fogjuk használni, és azt akarjuk, hogy a csomag később is elérhető és robusztus legyen. Próbáljunk ki különböző csomagokat, hogy ellenőrizzük a teljesítményüket, valamint a helyességüket. A legtöbb csomag más csomagokban található függvényektől (függőségek, dependencies) függ, így az egyik függőség gyengesége hatással lehet a programunkra. 3. Az OOP és a

procedurális fejlesztési paradigmákon kívül milyen más szoftverfejlesztési megközelítések léteznek, és melyik az a programozási nyelv, amelyik a legjobban támogatja az egyes megközelítéseket? Az OOP és a procedurális fejlesztési paradigmák mellett a következő típusok is előfordulnak. A funkcionális programozás a függvények és matematikai fogalmak, például lambdák és lezárások használatát hangsúlyozza, hogy olyan kódot írhassunk, amely inkább a kifejezések Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 19 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek kiértékelésén, mint az utasítások végrehajtásán alapul. A funkcionális programozás a függvényeket első osztályúként kezeli tehát a program által manipulálhatóak --, és hangsúlyozza az immutabilitást, vagyis az olyan változókkal való munkát, amelyek a kezdeti beállítás után nem változhatnak. Ez

megkönnyíti a kód átgondolását és tesztelését, valamint az egyidejű és párhuzamos alkalmazások írását. A funkcionális programozási nyelvek közé tartozik például az Erlang, a Haskell, a Lisp és a Scheme. Az imperatív nyelvek a program különböző állapotokból és különböző állapotokba való átmenetek áramlásának vezérléséhez szükséges utasításokra összpontosítanak. A deklaratív nyelvek leírják azt, hogy milyen műveleteket kell végrehajtani, valamint az utasítások mögötti logikát. Az utasítások végrehajtásának sorrendje nincs meghatározva Ezeket az utasításokat, függvényhívásokat és egyéb utasításokat a fordítóprogramok átrendezhetik és optimalizálhatják, amíg megőrzik a mögöttes logikát. A természetes programozás olyan programozási paradigma, amely természetes nyelvet vagy más emberbarát reprezentációkat használ a program kívánt viselkedésének leírására. Az elképzelés lényege, hogy a

programozást olyan emberek számára is elérhetővé tegye, akik nem rendelkeznek formális informatikai képzéssel. A természetes programozási nyelvekre példa a Scratch és az Alice. 20 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0512 Szoftverarchitektúra 051.2 Szoftverarchitektúra Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0512 Súlyozás 2 Kulcsfontosságú ismeretek • Az kliens- és szerver-számítástechnika fogalmainak megértése • A vékony és vastag kliensek fogalmának megértése • A monolitok és mikroszolgáltatások fogalmának és főbb különbségeinek megértése • Az alkalmazásprogramozási interfészek (API-k) fogalmának megértése. • A szoftverkomponensek fogalmának megértése és integrációjuk vagy szétválasztásuk (szolgáltatások, modulok, API-k) A használt fájlok, kifejezések és segédprogramok

listája • Kliensek és szerverek • Vékony és vastag kliensek • Webes alkalmazások • Egyoldalas alkalmazások • Monolitikus architektúrák • Mikroszolgáltatási architektúrák • Alkalmazásprogramozási interfészek (API-k) • RESTful API-k Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 21 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 051 Szoftver alapismeretek Fejezet: 051.2 Szoftverarchitektúra Lecke: 1/1 Bevezetés Modern világunkban mindenütt jelen van az internet, akárcsak a mobil- és webalapú alkalmazások. Ezeket az eszközöket a világ lakosságának nagy része zökkenőmentesen használja; és ezek működtetnek mindent az azonnali üzenetküldéstől kezdve az olyan összetettebb tevékenységekig, mint a nagyvállalatok bányászati berendezéseinek beszerzése. Mindezen látszólag egyszerű

felületek és online szolgáltatások mögött egy olyan architektúra együttműködő szoftverrészek elrendezése áll, amelyet gyakran természetesnek veszünk. Egy kicsit ismernünk kell ezt az architektúrát ahhoz, hogy megértsük, hogyan illeszkedik egymáshoz az internet összes darabja, és hogyan tud a szoftver valódi értéket nyújtani a felhasználóknak. Ebben a leckében megnézzük a webes alkalmazások, azaz a szerveralapú szoftverrendszerek mögött álló szoftverarchitektúrákat, és azt, hogyan használják őket olyan rendszerekben, 22 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 amelyeket szinte mindenki ismer. Szerverek és kliensek Ha online rendszereket használunk, minden valószínűség szerint találkoztunk már olyan üzenettel, mint a Példa képernyő, amely válaszadás közben jelenik meg. Figure 1. Példa képernyő, amely válaszadás közben jelenik

meg Lépjünk egy kicsit hátrébb, és nézzük meg a kontextust, amelyben ezt az üzenetet látjuk. Tegyük fel, hogy a bankszámlánkhoz próbálunk hozzáférni a bank weboldalán keresztül. Amikor a laptopunkon megpróbálunk belépni a bank weboldalára, egy olyan típusú szoftvert (azaz alkalmazást) használunk, amelyet webböngészőnek nevezünk, például a Google Chrome-ot vagy a Firefoxot. Ebben az esetben a számítógépünkön lévő böngésző kérést küld egy másik számítógépnek, amely otthont ad a webhelynek. Ezt a fajta számítógépet nevezzük szervernek Kifejezetten arra tervezték, hogy a nap 24 órájában, a világ minden tájáról érkező új kéréseket kiszolgálja. A szerver tehát egy számítógép, olyan, mint amit mi is használunk, amikor videojátékokkal játszunk vagy programozunk. Van azonban egy fő különbség: a szerver általában minden erőforrását a rajta futó szoftveralkalmazásnak adja. Ebben a példában a szoftver egy

webes alkalmazás, egy számítógépes program, amely a szerveren fut. A Példa képernyő, amely válaszadás közben jelenik meg esetében a szerver kapott egy kérést egy böngészőtől, és a szerveren futó alkalmazás végrehajtja a kapott műveletet. Ez a művelet lehet egy Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 23 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek adatbázis lekérdezése a felhasználó banki adatairól, vagy egy másik szerverrel való kommunikáció egy speciális kedvezmény igazolása érdekében a felhasználó következő hiteléhez. Ebben a példában a gépeden futó böngészőt kliensalkalmazásnak, vagy egyszerűen csak kliensnek nevezzük. A kliens lép kapcsolatba a távoli szerverrel A kliens és a szerver közötti hálózati kommunikáció történhet egy vállalati hálózaton belül, vagy az interneten keresztül az egész világon. A kliens-szerver interakció közös

jellemzője, hogy egy szerver több klienssel is több kapcsolatot létesíthet. Gondoljunk csak az előző példára: egy szerveren elhelyezett bank weboldala percenként több ezer kérést fogadhat több helyről, amelyek mindegyikében egy-egy felhasználó próbál hozzáférni a személyes bankszámlájához. Nem minden eset történik úgy, mint amikor egy böngésző interakcióba lép egy szerverrel, amely szinte az összes feldolgozást elvégzi. Bizonyos esetekben a kliens lehet a feldolgozás elsődleges példánya; ezt a koncepciót fat client-nek (vagy thick client vastagkliens) nevezik, ahol a kliens tárolja és dolgozza fel a feladatok többségét ahelyett, hogy a szerver erőforrásaira támaszkodna. Ezzel szemben a banki példánkban a böngésző egy thin client (vékonykliens), amely a szerverre támaszkodik a számítások elvégzésében és az információk hálózaton keresztüli visszaküldésében. A vastagkliensre példa lehet egy videojáték asztali

alkalmazása, ahol az adattárolás és feldolgozás nagy része helyben történik; a számítógép GPU-ját, RAM-ját, CPU-ját és lemezterületét használva az információk feldolgozásához. Egy ilyen alkalmazás ritkán támaszkodik külső szerverre, különösen, ha a játékot offline játsszák. Mindkét megközelítésnek vannak előnyei és hátrányai: a vastagkliens esetén a hálózat instabilitása kevésbé jelent problémát, mint a távoli szerverre támaszkodó vékonykliens esetében, de a szoftverfrissítések megvalósítása nehezebb lehet, és a vastagkliens több számítógépes erőforrást igényel. Egy vékonykliens esetében az alacsonyabb költségek nagy előnyt jelenthetnek Bármelyik klienstípus esetén problémát jelenthet a személyes adatok átadása egy harmadik féltől származó alkalmazásnak. Webalkalmazások A webalkalmazás olyan szoftver, amely egy szerveren fut, feldolgozza a felhasználói interakciókat, és amellyel a vastag-

vagy vékonykliensek számítógépes hálózaton keresztül lépnek kapcsolatba. Nem minden weboldal tekinthető webes alkalmazásnak: az egyszerű, interaktivitás nélküli statikus weboldalak nem minősülnek webalkalmazásnak, mivel a szerver nem futtat alkalmazást a kliens által kért műveletek feldolgozására. Sok webes alkalmazás két csoportba sorolható: a single page application (SPA egyoldalas alkalmazás) és a multi-page application (MPA többoldalas alkalmazás). Az SPA esetén egy oldal 24 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 van, ahol minden adatcsere és betöltés anélkül történik, hogy a felhasználót át kellene irányítani egy másik lapra az alkalmazáson belül. Az MPA az SPA-val ellentétben több oldallal rendelkezik Egy adatváltozás vagy ugyanazt az oldalt frissíti, amelyről a művelet származik, vagy átirányítja a felhasználót egy másik

lapra. Vegyük az előző példát, amikor egy felhasználó az internetbank oldalán szeretné ellenőrizni a legutóbbi számlaforgalmát. Képzeljük el, hogy egy tranzakció a weboldal betöltése után történik Ha a banki webalkalmazás egy SPA, akkor az új tranzakció automatikusan megjelenik ugyanazon az oldalon, anélkül, hogy a felhasználót új oldalra irányítaná át. Ha a felhasználó ellenőrzi a hiteleit, az új információ szintén ugyanazon az oldalon jelenik meg, így nem kell a felhasználót új weboldalra átirányítani. Az oldal módosítása a felhasználó átirányítása nélkül teszi zökkenőmentessé a navigációt. Egy MPA esetében, amikor a felhasználó megnyitja a hitelekkel kapcsolatos oldalt, a szervernek át kell irányítania a felhasználót egy új helyre, ami egy másik oldalt jelent. Az SPA webalkalmazás híres példája a Google Mail (Gmail). Ez nem irányítja át a felhasználót teljesen új oldalra, amikor például a

felhasználó a spam mappát szeretné megjeleníteni; az alkalmazás csupán frissíti a kijelzőnek azt a részét, amely az összes spam üzenetet mutatja, és ugyanazon az oldalon marad. Híres MPA alkalmazás például az Amazon.com, az e-kereskedelmi óriás, ahol minden egyes termék egy külön weboldalon található. Az MPA egyik előnye a SPA-val szemben, hogy a webes analitika sokkal könnyebben gyűjthető és mérhető. Ez kulcsfontosságú ahhoz, hogy a fejlesztők optimalizálni tudják az internetes keresési eredményeket. Általában egy webes alkalmazás két különálló részre oszlik: frontend és backend. A frontend a nézeti (view) réteg, ahol a felhasználó a böngészővel interakcióba lép az oldal elemeinek használatával, kattintással, kiválasztással vagy gépeléssel. Ez az a rész, ahol a szervertől érkező adatok fogadásra, formázásra kerülnek és a böngészőn keresztül megjelennek a felhasználónak. A backend általában a webes

alkalmazás nagyobb része. Ez tartalmazza az üzleti logikát, a kommunikációs kezelőket, az adatfeldolgozás nagy részét és az adattárolást. Az adattárolás egy külön adatbáziskezelő rendszert használ, amely a backendhez kapcsolódik. A frontend és a backend kommunikál egymással. Az adatkéréseket a frontend továbbítja a backendnek, a backend által visszaküldött adatokat pedig a frontend fogadja, formázza és megjeleníti a felhasználónak. Egyszerű példánkban, amikor a felhasználó bankszámlájának legutóbbi tranzakcióját keressük, a Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 25 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek műveletet az alkalmazás frontendje értelmezi, amely a felhasználó asztali gépén lévő böngészőben fut. Ezt a kérést ezután az interneten keresztül elküldi az alkalmazás backendjéhez, amely ellenőrzi, hogy a felhasználó jogosult-e a

művelet végrehajtására, lekérdezi az adatokat, és visszaküldi a tranzakciók listáját a böngészőben betöltött frontendnek. A böngésző ezután formázza és megjeleníti az adatokat. Alkalmazásprogramozási interfész (API) Egyetlen szoftver sem hasznos, ha nem tud a belső és külső komponensekkel kommunikálni. Hogyan kommunikálhat tehát a kliens a webes alkalmazással? Hogyan tud a frontend adatokat küldeni a backendnek? A szoftveralkalmazások egymással az alapvető internetes kommunikációs protokollokon keresztül futó alkalmazásprogramozási interfészen (Application Programming Interface API) keresztül kommunikálnak. A protokollok olyan szabványok és szabályok, amelyeket azért dolgoztak ki, hogy két vagy több alkalmazás parancsokat és adatokat cseréljen egymással. Az API fő előnye, hogy az alkalmazás különböző részeit szétválasztja, miközben lehetővé teszi számukra, hogy együttműködjenek az adatok feldolgozásában. Az

API-k az adatáramlást is központosítják előre meghatározott csatornákon, és olyan átjáróként működnek, amelyek biztosítják, hogy mindenki ugyanazt az utat használja a be- és kilépéshez. A webes alkalmazásokban az API-k létfontosságúak az alkalmazás funkcionalitása szempontjából, mivel lehetővé teszik a felhasználói interakciót, a feldolgozott információk átadását, az adattárolás iránti kérelmeket és sok más feladat végrehajtását. Egy API segítségével a kliens például olyan műveleteket kérvényezhet, amelyek a szerveren kerülnek végrehajtásra. Térjünk vissza a banki webes alkalmazás példájához. Egy webes alkalmazáson keresztül történő bejelentkezéshez a felhasználó általában bizonyos szövegmezőkbe beírja az adatokat, például a felhasználónevet és a jelszót, majd rákattint a “Bejelentkezés” gombra. A böngésző lekérdezi ezeket az információkat, és meghív egy backend API-t. A távoli

kiszolgálón futó webes alkalmazás megkapja a felhasználói adatokat, validálja a felhasználót, ellenőrzi a felhasználó hozzáférési jogát, és végül visszaküldi a választ a böngészőnek. Ahhoz, hogy a felhasználó kommunikálni tudjon a szerverrel, a kliens és a szerver számára is kötelező az adatok oda-vissza küldése. Ezt teszik lehetővé az API-k. Vegyük észre, hogy a bank webes alkalmazása nem tesz közzé más érzékeny információkat; csak azokat a mezőket jeleníti meg a felhasználónak, amelyek a kívánt interakcióhoz engedélyezettek és szükségesek a többi el van rejtve a felhasználó elől. Az API-k közötti kommunikáció nagyon különböző kialakításokon és protokollokon alapulhat. Messze a leggyakrabban használt protokoll a webes alkalmazásokban a hypertext transfer 26 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 protocol (HTTP). A

Hypertext más szövegekre mutató hivatkozásokkal ellátott szöveg, a HTML weboldalak linkjeinek alapkoncepciója. A hiperhivatkozások képezik tehát a weboldalak felépítésének és böngészőkben való megjelenítésének alapját. A HTTP-t kliens-szerver alkalmazásokhoz tervezték, ahol az erőforrásokat egy szervertől kérik, majd a HTTP protokoll által definiált, előre meghatározott struktúra segítségével a hálózaton keresztül visszaküldik a kliensnek. Egy strukturált webes alkalmazás esetében a szoftvermérnökök az alkalmazást különálló részekből vagy modulokból tervezik. Ez a felelősség szétválasztása lehetővé teszi a feladatok és felelősségi körök egyértelmű meghatározását, ami gyorsabb fejlesztést és jobb karbantartást eredményez. Vegyünk példaként egy olyan alkalmazást, amely két belső modullal rendelkezik: az egyik az üzleti logikát valósítja meg, a másik pedig egy harmadik féltől származó integrációra

támaszkodik. Ez a harmadik fél egy külső vállalat, amely az API-ját valamilyen konkrét céllal például időjárás-előrejelzés bocsátja rendelkezésre. Ha az időjárás-szerver nem működik, lehetetlen az időjárási adatokhoz hozzájutni, márpedig ha ezek az adatok kulcsfontosságúak a végső feldolgozott kimenet szempontjából, akkor a hiányuk átmenetileg fejfájást okozhat a felhasználónak, ha nincs alternatív adatforrás. Most képzeljük el, hogy ezt a third-party szolgáltatót lecserélik, és az új szolgáltató másképp kezeli ugyanazt az API-t. A modulok szétválasztása azt jelenti, hogy a fejlesztőknek csak az egyik modult kell frissíteniük. A másik modulban lévő üzleti logikához egyáltalán nem kell hozzányúlni, vagy csak minimális frissítést igényel. A világos folyamatstruktúrák szükségessége az API-k kialakítását is befolyásolja, hogy azok használata könnyebbé váljon. A representational state transfer (REST)

koncepció egy architekturális stílus, amely egy sor irányelvet tartalmaz az adatokhoz való hozzáférés megtervezésére és megvalósítására egy alkalmazásban. Hat REST-elv létezik. Az egyszerűség kedvéért csak hármat fogunk ismertetni, amelyek a lecke szempontjából a legfontosabbak: Kliens-szerver szétválasztása (decoupling) A kliensnek csak az erőforrás URI-ját kell ismernie, amelyen keresztül a szerverrel való kommunikáció történik. Ez az elv nagyobb rugalmasságot tesz lehetővé Például, ha az alkalmazás backend oldala átdolgozásra kerül, vagy ha a backend adatbázisában jelentős architektúrális változás történik, a frontendet nem kell ezzel együtt frissíteni. Egyszerűen továbbra is ugyanazokat a HTTP-kéréseket küldi a backendnek. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 27 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Állapotnélküliség

(statelessness) Minden új kérés független az előzőektől. Nem véletlen, hogy a HTTP protokollt széles körben használják a REST elveket követő alkalmazásokhoz, mivel a HTTP nem ismeri a korábbi HTTPkéréseket; minden új kérés esetén minden szükséges információt el kell küldeni a kérés helyes feldolgozásához. Az ezt az elvet megvalósító webes alkalmazás például nem tudja, hogy a kliens be van-e jelentkezve (authenticated). Ezért a kliensnek minden egyes HTTP-kérelemhez el kell küldenie egy hitelesítési tokent. A szerver ezt a tokent tudja használni annak ellenőrzésére, hogy a kérést blokkolni vagy feldolgozni kell-e. Ennek az elvnek az egyik fő előnye a könnyebb skálázás, mivel a szerver több millió kérést tud feldolgozni a felhasználói adatok ellenőrzése nélkül. Többrétegű architektúra (layered architecture) Az alkalmazás több rétegből áll, és minden rétegnek saját logikája és célja lehet, például a

biztonság vagy az adatgyűjtés. A kliens soha nem tudhatja, hogy hány réteg létezik, vagy azt, hogy közvetlenül egy adott réteggel kommunikál-e az alkalmazáson belül. A REST alapelveket követő API-kat RESTful-nak nevezik, és a modern weben számos webes alkalmazás követi a REST designt. Bár egy RESTful API-nak nem kell ezeket az elveket a HTTP protokoll segítségével megvalósítania, a REST-modell robusztussága, egyszerűsége és a világhálós környezetben való elterjedtsége miatt szinte általánosan használják. Architektúra típusok Több tucatnyi architekturális stílus és szabvány létezik, amelyek megpróbálják megszervezni a webes alkalmazások struktúráját. Mint a számítógépes világban szinte mindig, itt sincs “győztes”, csak vannak az egyes modelleknek előnyei és hátrányai. Fontos paradigma az úgynevezett mikroszolgáltatás-architektúra (microservice architecture), amely a régebbi monolitikus architektúra

alternatívájaként jött létre. A mikroszolgáltatás-architektúra olyan szoftvermodell, amely több, egymástól függő szolgáltatásból áll, amelyek együtt alkotják a végső alkalmazást. Ennek az architektúrának a célja a kódbázis decentralizálása: A szoftver több rétegét több kisebb alkalmazásra bontják a jobb karbantarthatóság érdekében (Mikrszolgáltatás-architektúra). 28 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 Figure 2. Mikrszolgáltatás-architektúra Ezzel szemben a monolitikus architektúra az alkalmazás összes szolgáltatását és erőforrását egyetlen alkalmazásban tartalmazza (Monolitikus architektúra). Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 29 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Figure 3. Monolitikus architektúra A képeken látható, hogy a

mikroszolgáltatási modell decentralizált, és az alkalmazás több szolgáltatásra támaszkodik, amelyek mindegyike saját adatbázissal, kódbázissal és még szerver erőforrásokkal is rendelkezik. Ahogy a név is jelzi, minden egyes mikroszolgáltatásnak kisebbnek kell lennie, mint monolitikus megfelelőjének, amely az összes szolgáltatásért felelősséget vállal. A monolitikus alkalmazás minden erőforrását egyetlen egységbe foglalja. Az összes üzleti logika, adat és kódbázis egyetlen hatalmas blokkban van központosítva, ezért is hívják “monolitnak”. A felhasználók nehezen veszik észre, hogy egy webes alkalmazás monolitikus vagy mikroszolgáltatásos modellben fut-e; a választásnak átláthatónak kell lennie. A banki alkalmazásunk például lehet monolit, ahol a fizetésekre, tranzakciókra, kölcsönökre stb. vonatkozó összes üzleti logika ugyanabban a kódbázisban található, amely egy vagy több szerveren fut. Másrészt, ha a banki

alkalmazás mikroszolgáltatási stílust használ, akkor valószínűleg van egy mikroszolgáltatás a fizetések feldolgozására, és egy másik mikroszolgáltatás csak a hitelek kiadására. Ez utóbbi mikroszolgáltatás egy másik mikroszolgáltatást hív, hogy 30 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 elemezze annak valószínűségét, hogy a kérelmező nem fog fizetni. Az alkalmazásnak több ezer kisebb szolgáltatása lehet. A monolitikus megközelítés több karbantartási költséget igényel, ha az alkalmazás nagyobbra nő, különösen, ha több csapat (team) kódol ugyanabban a kódbázisban. Tekintettel a központosított szoftverforrásokra, nagy a valószínűsége, hogy az egyik team olyasmit változtat, ami tönkreteszi az alkalmazás másik team által fejlesztett részét. Ez igazi fejfájást okozhat a nagyobb csapatoknak, különösen, ha sok csapatról van szó.

A mikroszolgáltatások ebből a szempontból sokkal rugalmasabbak, mivel minden egyes szolgáltatást csak egy csapat kezel persze egy csapat egynél több szolgáltatást is kezelhet. A kódmódosítások könnyen elvégezhetők, és a versengő erőforrások nem jelentenek igazi problémát. Mivel minden egyes szolgáltatás összekapcsolódik, bármely hibapont negatív hatással lehet az egész alkalmazásra. Továbbá, mivel több adatbázis-példány, szerver és külső API kommunikál egymással, az egész alkalmazás ellenálló képessége csak annyira jó, mint a leggyengébb mikroszolgáltatásé. A monolitikus megközelítés egyik előnye, hogy egyetlen központi adatforrással rendelkezik, ami megkönnyíti az adatok duplikálásának elkerülését. A megközelítés csökkenti a felhőerőforrások felhasználását is, mivel egy nagyobb szerver kevesebb számítógépes erőforrást igényel, mint több decentralizált szerver. Egy nagyjából azonos méretű

mikroszolgáltatásos alkalmazás nagyobb terhet ró a felhőre. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 31 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Gyakorló feladatok 1. Mik a legfőbb különbségek egy vastag- és egy vékonykliens között? 2. Helyes-e az a feltételezés, hogy minden weboldal egy webalkalmazás? 3. Mi az a REST modell? 4. Mi az előnyben részesített modell a nagy és modern webes alkalmazások fejlesztésére több fejlesztőcsapat esetén? Miért? 5. Mi a leggyakrabban használt protokoll a webes alkalmazások közötti adatcserére? 6. Nevezzük meg a többoldalas alkalmazások két hátrányát az egyoldalas alkalmazásokkal szemben! 7. Írjuk le a monolitikus rendszer egy előnyét a mikroszolgáltatási rendszerrel szemben, valamint a mikroszolgáltatási rendszer egy előnyét a monolitikus rendszerrel szemben! 32 | learning.lpiorg | CC BY-NC-ND 4.0 alatt

licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 Gondolkodtató feladatok 1. 2021-ben landolt a NASA Perseverance Rover a Marson, amelynek egyik célja annak megállapítása, hogy létezett-e valaha élet a bolygón. Bár a rover itt a Földön távolról irányítható, a legtöbb helyzetben önmagát is képes irányítani. Miért jó ötlet egy ilyen járművet vastagkliensként projektálni? 2. Gondoljunk egy modern, önvezető személyautóra, amely adatcsere céljából csatlakozik egy külső szerverhez. Vastag- vagy vékonykliens legyen? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 33 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Összefoglalás Ez a lecke a webes alkalmazások szoftverarchitektúrájának alapfogalmait ismertette. A lecke elmagyarázta azt, hogy hogyan strukturálják és szervezik őket általában, valamint a főbb különbségeket a monolitikus és

a mikroszolgáltatásos modellek között. Kitértünk a szerverek és kliensek fogalmára, valamint a webalkalmazások kliensek és más szoftverprogramok közötti kommunikációjának alapjaira. 34 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 Válaszok a gyakorló feladatokra 1. Mik a legfőbb különbségek egy vastag- és egy vékonykliens között? A vastagkliensnek nincs szüksége állandó kapcsolatra egy távoli szerverrel, amely kritikus információkat ad vissza a futó kliensnek. A vékonykliens nagymértékben támaszkodik a külső forrás által feldolgozott információkra. További különbség, hogy a vastagkliens felelős az adatfeldolgozás nagy részéért, így több számítási erőforrást igényel, mint a vékony megfelelője. 2. Helyes-e az a feltételezés, hogy minden weboldal egy webalkalmazás? Nem. Vannak olyan weboldalak, amelyek nem szoftveralkalmazások Egy

webalkalmazás kölcsönhatásba lép a felhasználóval, aki valós időben adhat meg adatokat és használhat webes funkciókat. Az olyan egyszerű weboldalak, mint például egy közösségi esemény hirdetése, amely úgy működik, mint egy banner, nem webalkalmazások. Ezeket a nem interaktív weboldalakat könnyebb karbantartani, és tárolásukhoz és megjelenítésükhöz apró számítási erőforrásokra van szükség. Egy webalkalmazás sokkal több számítási erőforrást, robusztusabb szervereket és a felhasználókat kezelő funkciókat igényel, például korlátozott hozzáférést és állandó adattárolást. 3. Mi az a REST modell? A REST-modell egy szoftverarchitektúra-modell, amely az alkalmazások számára fejlesztési útmutatót nyújt a jobb használhatóság, áttekinthetőség és karbantarthatóság érdekében. A REST-irányelvek egyik alapelve a többrétegű architektúra, amelyet elsősorban a kohézió és a különböző API-k belső

összetevőinek függőségének csökkentése érdekében használnak. 4. Mi az előnyben részesített modell a nagy és modern webes alkalmazások fejlesztésére több fejlesztőcsapat esetén? Miért? A mikroszolgáltatásos szoftvermodell olyan rugalmas keretet biztosít, amelyben a csapatok ugyanazon a szoftveralkalmazáson dolgoznak együtt, így könnyebb párhuzamosságot biztosít két vagy több csapat számára, amelyek egy nagy webes alkalmazást tartanak fenn. Mivel a keretrendszer decentralizált, minden csapat frissíthet egy adott üzleti területet anélkül, hogy más komponenseket kellene frissítenie. 5. Mi a leggyakrabban használt protokoll a webes alkalmazások közötti adatcserére? A HTTP a leggyakrabban használt protokoll szerverek és kliensek közötti adatcsere esetén. 6. Nevezzük meg a többoldalas alkalmazások két hátrányát az egyoldalas alkalmazásokkal szemben! Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg |

35 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Egy többoldalas alkalmazás ahelyett, hogy csak a megváltozott elemeket frissítené, a felhasználó által kezdeményezett műveletek hatására a weboldal összes elemét újratölti. Ez a megvalósítás azonban a teljesítmény rovására megy. Az MPA másik hátránya a nehézkesebb felhasználói interaktivitás, mivel az egyes oldalbetöltések kevésbé felhasználóbarátak. Ezzel szemben SPA esetén a vizuális hatás folyamatos lehet. 7. Írjuk le a monolitikus rendszer egy előnyét a mikroszolgáltatási rendszerrel szemben, valamint a mikroszolgáltatási rendszer egy előnyét a monolitikus rendszerrel szemben! Egy monolitikus rendszer megkönnyítheti az adatkezelést, mivel az adatok egyetlen nagy adatbázisban találhatók, ahelyett, hogy több adatbázisban lennének szétszórva. Egy mikroszolgáltatásos alkalmazás viszont javíthatja a kódfejlesztést és a karbantartást;

több csapat dolgozhat különböző üzleti logikákon anélkül, hogy akadályozná a többi csapat munkáját. 36 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Lecke 1 Válaszok a gondolkodtató feladatokra 1. 2021-ben landolt a NASA Perseverance Rover a Marson, amelynek egyik célja annak megállapítása, hogy létezett-e valaha élet a bolygón. Bár a rover itt a Földön távolról irányítható, a legtöbb helyzetben önmagát is képes irányítani. Miért jó ötlet egy ilyen járművet vastagkliensként projektálni? Az idő, amíg egy kommunikációs jelet a Földről elküldenek és a Marson fogadnak, a bolygók helyzetétől függően változó lehet, de akár húsz percig is eltarthat. Így egy mozgásban lévő, távoli rover irányítása és ellenőrzése lehetetlen, különösen a váratlan helyzetekben. Ideális esetben a rovernek a legtöbb helyzetben saját magát kell irányítania.

Ezt a mesterséges intelligencia (AI) fejlesztésével (gépi tanulás) érik el, így a rover egyre függetlenebbé válik a manuális parancsoktól. Annak érdekében, hogy ez lehetővé váljon és kevésbé támaszkodjon távoli jelekre, a rovert úgy tervezték, hogy saját erőforrásokkal rendelkezzen, és a számítási folyamatok többsége rajta fusson, ami megfelel a vastagkliens definíciójának. 2. Gondoljunk egy modern, önvezető személyautóra, amely adatcsere céljából csatlakozik egy külső szerverhez. Vastag- vagy vékonykliens legyen? Egy autonóm jármű a nehéz adatfeldolgozást egy külső és megbízható szerverre is átruházhatná, de ez érzékeny lenne azokban az offline időszakokban, amikor a kritikus adatok feldolgozásra van szükség. Ezért elengedhetetlen, hogy az autonóm jármű oldja meg a feladatok többségét és ehhez egy többszörös redundanciával rendelkező vastagkliensnek kell lennie. Version: 2024-08-12 | CC BY-NC-ND 4.0

alatt licencelve | learning.lpiorg | 37 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek 051.3 On-premise és felhőalapú számítástechnika Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0513 Súlyozás 1 Kulcsfontosságú ismeretek • Az on-premise és a felhőalapú számítástechnika fogalmának megértése • A gyakori felhőüzemeltetési modellek megértése • A felhőszolgáltatások gyakori típusainak megértése • A felhőalapú számítástechnika és az on-premise IT-infrastruktúra főbb előnyeinek és kockázatainak megértése A használt fájlok, kifejezések és segédprogramok listája • Felhőalapú számítástechnika • Helyszíni IT-infrastruktúra • Adatközpont • Nyilvános, privát és hibrid felhő • Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) • Költségmodellek • Biztonság • Adattulajdonjog • A

szolgáltatás rendelkezésre állása 38 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 051 Szoftver alapismeretek Fejezet: 051.3 Helyi és felhőalapú számítástechnika Lecke: 1/1 Bevezetés Manapság mindenki a felhőről beszél. A vállalkozások számos cég ajánlatait értékelik ki köztük olyan nagyvállalatok, mint az Amazon.com és a Microsoft --, hogy lássák, mit tud kínálni a felhő A felhőalapú számítástechnika ötlete azonban csak a 2000-es évtized végére nyúlik vissza. A kifejezés pedig annyira homályos, hogy sokan köztük a Free Software Foundation is, elzárkóznak a használatától. A felhőalapú számítástechnika gondolata azonban néhány konkrét, hasznos fogalmat testesít meg, és a modern számítástechnika egyik legfontosabb

trendje. Ez a lecke azt mutatja be, hogy mi is az a felhő, és magas szinten hogyan működik mind technikailag, mind pénzügyileg. Megvizsgáljuk a felhő előnyeit és kockázatait, eközben pedig megnézzük, hogy miért kapcsolódik ez a téma az open source világhoz. Helyi és felhőalapú számítástechnika Ha olyan szervezetben dolgozunk vagy tanulunk, amely néhány számítógépes rendszernél többel rendelkezik, akkor szinte biztosan van adatközpontja (data center): egy külön helyiség, ahol a Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 39 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek szervereket tartják, általában klimatizálva és elzárva. Az on-premises (vagy on-premise helyi) adatközpont egyszerűen egy olyan központ, amelyet a szervezet saját használatra tart fenn. Az adatközpont helyben történő üzemeltetésének számos alternatívája van. Az általunk “felhőalapú

számítástechnikának” nevezett trend előtt évtizedekkel a vállalkozások olyan adatközpontokat hoztak létre, amelyekben az ügyfelek nevében számítógépeket üzemeltettek. Így előfordulhatott, hogy licenceltünk öt szervert a vállalkozástól és különböző specifikációkkal határoztuk meg elvárásainkat a CPU-val, a memóriával és a tárhellyel kapcsolatban, majd feltöltöttük a szoftverünket ezekre a szerverekre. Ez az üzleti modell a távoli tárhelyszolgáltatás (remote hosting). A távoli tárhelyszolgáltatás számos előnnyel jár. A szervezet hatékonyan kiszervezheti a szerverek megvásárlásával és beállításával kapcsolatos adminisztratív szakértelmet a távoli tárhelyszolgáltató vállalkozásnak, amely tömeges beszerzéseket kaphat. Más szóval, elkerülhetjük a helyben lévő IT-infrastruktúrával járó felelősséget. A távoli tárhelyszolgáltató vállalkozás gondoskodik a fizikai biztonságról, és ettől az

aggodalomtól is megszabadítja az ügyfelet. Végül pedig egy új szerver beállítása a tárhelyszolgáltató vállalkozásnál sokkal gyorsabb, mint a szerver megvásárlása, szállítása és beállítása a telephelyen. A szervezet fenntarthat egy helyben lévő adatközpontot is, miközben több szervert licencelhet a távoli környezetben például a katasztrófák utáni helyreállításhoz, vagy biztosíthat velük extra számítási teljesítményt a nagy igénybevételű időszakokban. Meg kell jegyeznünk, hogy a távoli számítástechnika esetén feltételezzük, hogy gyors és megbízható hálózattal rendelkezünk. Ezt a kérdést más előnyökkel és gyengeségekkel együtt egy másik szakaszban fogjuk megvizsgálni. A távoli tárhely minden előnye a felhőalapú számítástechnikára is vonatkozik. A felhőalapú számítástechnika technikailag tér el, mivel nem egy adott fizikai számítógépet kap a szervezet. Ehelyett a felhőszolgáltató minden egyes

fizikai rendszeren több rendszert futtat több kliens számára, egy extra szoftverréteg, az úgynevezett virtuális gépek segítségével. Egy felhőszolgáltatás tehát ugyanúgy üzemeltet egy adatközpontot, mint bármely más szervezet, de saját maga helyett (vagy mellett) más szervezeteket szolgál ki. Az adatközpontban több ezer fizikai számítógépet tárol. Minden egyes fizikai számítógépen egy operációs rendszert (általában hypervisor-nak nevezik) futtat, amely több virtuális gépet támogat. Minden egyes virtuális gép gyorsan létrehozható és törölhető. Minden virtuális gép egy-egy kliens által futtatott operációs rendszert támogat (Felhőalapú számítástechnika). 40 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika Figure 4. Felhőalapú számítástechnika Hol jön a képbe a szabad szoftver és a nyílt

forráskód? Amikor egy vállalkozás rengeteg számítógépet üzemeltet, és menet közben telepít operációs rendszereket, fontos, hogy ne hátráltassa az, hogy foglalkoznia kell a licencekkel. Bár léteznek licencelési modellek a felhőben használt szabadalmaztatott operációs rendszerekhez, ezek bonyolultabbak, mint egy nyílt forráskódú virtuális gép és operációs rendszer egyszerű futtatása. A nyílt forráskódú rendszerek általában ráadásul ingyenesek is. A felhőalapú számítástechnika kezdetét általában az Amazon.com 2006-os Amazon Web Services (AWS) elindításához kötik. Ma már több tucat felhőszolgáltató cég létezik, köztük olyan nagy gyártók ajánlatai, mint a Microsoft, a Google, az Alibaba és az IBM. Azonban még mindig az AWS nyújtja a legnagyobb kínálatot. A gyártók éles versenyben állnak egymással az új funkciók és szolgáltatások fejlesztésében, mivel mindannyian erősek a költségek és a megbízhatóság

terén. A felhőalapú számítástechnika előnyei a távoli (remote) számítástechnika előnyeire épülnek. A költségek alacsonyabbak, mivel egy fizikai rendszer több kliens számára működtethet több szervert, és folyamatos kihasználtsága lehet. Egy olyan kliens, akinek gyorsan több számítási teljesítményre van szüksége a használat megugrása miatt, másodpercek alatt új rendszereket hozhat létre. A rendszereket automatikusan lehet kezelni egy alkalmazásprogramozási interfészen (API) keresztül. Az előnyöket és a kockázatokat a későbbiekben ismét megvizsgáljuk közelebbről. Gyakori felhő-üzemeltetési modellek Mielőtt részleteznénk az üzemeltetési modelleket, érdemes megjegyezni, hogy számos vállalat Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 41 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek olyan felhőmodelleket alkalmaz, amelyek teljesen megváltoztatják a

programozás és a szolgáltatások kínálatának módját. Ahelyett, hogy évente egyszer vagy kétszer frissítenének minden egyes alkalmazást, a vállalatok gyors frissítéseket tesznek lehetővé. Ezt azért tehetik meg, mert a felhő lehetővé teszi számukra, hogy a virtuális gépeket leállítsák, és szinte azonnal újakat indítsanak az alkalmazás új verziójával. A szervezet emellett gyorsan tud skálázódni, ezért szeretik az alkalmazásokat sok moduláris részre bontani, amelyeket néha mikroszolgáltatásoknak (microservices) neveznek. Ebben a részben azonban a mindennapi felhőmodellekre összpontosítunk. A felhő költségmodellje nagyban különbözik a helyi felmerülő költségeitől. A helyi adatközpontokban egyszeri szervervásárlásra van szükség, valamint az áramellátás, a légkondicionálás és az adminisztráció folyamatos költségeire. Ezek megszűnnek, ha egy felhőszolgáltatótól licenceljük a rendszereket, ehelyett azonban

fizetnünk kell a felhasználásért. A felhőszolgáltatók a számítógéphasználatot időszakokra osztják, és minden egyes időszak után felszámítják a díjat. Emellett a rendszereiken tárolt adatok mennyisége után is díjat számítanak fel. Eddig olyan gyártókról beszéltünk, amelyek számítási teljesítményt ajánlanak az ügyfeleknek; ezt nevezzük nyilvános felhőnek (public cloud). De létezhet privát felhő (private cloud) is Egyes nagy szervezetek saját, helyben lévő adatközpontjaikat felhőként működtetik. Csak a saját részlegeiknek vagy alosztályaiknak nyújtanak szolgáltatásokat, de minden egyes részlegüket úgy kezelik, mintha egy felhőszolgáltató ügyfelei lennének. Az adatközpont nyomon követi, hogy az egyes részlegek mennyi számítási időt, adatot stb. használnak, és a használatért díjat számít fel Sok szervezet több felhőszolgáltatást használ különböző okokból, például a gyártói hibák kivédése

érdekében, az adatok egy adott földrajzi régióban való tárolása vagy egy adott szolgáltató által kínált speciális funkciók kihasználása érdekében. Emellett gyakori, hogy egy helyben lévő adatközpontot és a felhőben lévő szervereket is fenntartanak, ezt a gyakorlatot nevezik hibrid számítástechnikának (hybrid computing). A felhőszolgáltatásra feliratkozó kliens kiválaszthatja, hogy mely földrajzi régiókban fusson. Az Amazon például jelenleg az Egyesült Államok nyugati és keleti részén, Európában, valamint a világ minden részén kínál régiókat. Normális esetben a felhasználó a hozzá legközelebbi régiót választja. Sok szervezet azonban több régióban is szeretne működni, mivel nemzetközi jellegű A szervezeteknek néha egy adott helyen kell adatokat tárolniuk, hogy megfeleljenek az európai általános adatvédelmi rendeletnek (General Data Protection Regulation GDPR) vagy a kínai személyes adatok védelméről szóló

törvénynek (Personal Information Protection Law PIPL). Minden régiót általában zónákra vagy elérhetőségi zónákra osztanak. A több zónában történő futtatás ajánlott arra az esetre, ha egy katasztrófa miatt valamelyik zóna leállna. 42 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika Bár a felhő arról ismert, hogy a fizikai számítógépeket több kliens között lehet megosztani, egyes gyártók egyetlen számítógépet is tudnak szentelni egy adott ügyfélnek, ha az aggódik a biztonság miatt. Mivel más szervezet nem használja a számítógépet, az ügyfél egy kicsit biztonságosabbnak érzi az érzékeny szolgáltatásainak futtatását és az adatainak a felhőbe való feltöltését. Ez a lehetőség a felhőalapú számítástechnikát közelebb hozza a régimódi távoli tárhelyszolgáltatáshoz. A

felhőszolgáltatások gyakori típusai Különböző szinteken a felhőalapú számítástechnika nagyon eltérően néz ki, és különböző típusú felhasználóknak szól. Az Infrastructure as a Service (IaaS, infrastruktúra mint szolgáltatás) az a kategória, amellyel a rendszergazdák általában foglalkoznak. Az IaaS csak a hardvert és a virtuális gépeket támogató szoftvert biztosítja. Az ügyfél rendszergazdáin múlik, hogy a virtuális gépre feltöltsenek egy operációs rendszert és a szükséges alkalmazásokat. A rendszergazda szinte mindent ugyanúgy kezel, mint egy helyben lévő adatközpontban. A Platform as a Service (PaaS, platform mint szolgáltatás) egy újabb találmány, amelyet főként programozók használnak. Itt a programozó nem foglalkozik az operációs rendszerrel, és nem kell betöltenie a program által használt könyvtárakat. Mindezt a felhőszolgáltató biztosítja A programozó csak feltölti a függvényeket, amelyek a platformon

futnak. Kapcsolódó fogalom a szervermentes (serverless) számítástechnika. A Software as a Service (SaaS, szoftver mint szolgáltatás) egy felhőrendszerben futó alkalmazás. Minden alkalommal, amikor bejelentkezünk egy közösségi médiaoldalra, megrendelünk egy terméket egy online áruházból, meglátogatunk egy weboldalt, hogy beírjuk az óráinkat egy munkaidő-nyilvántartásba, vagy kitöltünk egy űrlapot egy kormányzati oldalon, SaaS-t használunk. Az alkalmazás nagy része a távoli rendszeren fut, és a mi számítógépünkön csak a böngészőnk által megjelenített weboldal fut. Az előző kategóriákhoz gyakran hozzáveszik a Database as a Service-t (DaaS, adatbázis mint szolgáltatás). Az adatszolgáltatás, az Amazon S3 valójában az első felhőszolgáltatás volt A DaaS lehet egyszerűen egy népszerű adatbázis-kiszolgáló, például a MySQL, az Oracle vagy a MongoDB felhőben futó példánya. A nagy felhőszolgáltatók saját adatbázisokat

is kínálnak, amelyek csak a saját felhőjükben futnak. Az adatbázist minden esetben úgy olvassuk és írjuk, mintha a saját rendszereinkben lenne. Egyes vállalatok ezen alapkategóriák egyéb változatait kínálják, mint például a Security as a Service. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 43 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek A felhőalapú számítástechnika és a helyhez kötött ITinfrastruktúra főbb előnyei és kockázatai Mielőtt részletesen megvizsgálnánk a felhőalapú számítástechnikát, nézzünk meg egy hasonlatot. Egy helyhez kötött adatközpont üzemeltetése olyan, mintha házat vásárolnánk. Ha a pincét elönti az árvíz, vagy a kazán leáll, találni kell valakit, aki megjavítja. Ezzel szemben a távoli tárhely és a felhőalapú számítástechnika olyan, mintha egy lakást bérelnénk: a bérbeadó felelős a kazán megjavításáért. Ráadásul

a felhőben gyorsan hozzáadhatunk és eltávolíthatunk adatterheket, ahogyan a bérelt lakást is gyorsabban elhagyhatjuk, mint a saját tulajdonunkban lévő házat. Egy lakásban a bérbeadó akár készülékeket és bútorokat is biztosíthat. A mi hasonlatunkban ez olyan, mint a felhőszolgáltatók által kínált számos szolgáltatás, például az adatbázisok és az analitika. Most megvizsgálhatjuk a felhő használatának előnyeit és kockázatait a saját adatközpont használata mellett vagy helyett. A felhőbe való átköltözés mellett talán a flexibilitás a legnyomósabb indok. Ha például kereskedők vagyunk, akinek karácsony környékén több szervert kell futtatnia, vagy könyvelők, akik az adószezonban dolgoznak a legtöbbet, akkor felhőre lesz szükségünk, hogy egy pillanat alatt új szervereket indíthassunk be, majd később törölhessük a virtuális gépeket. A költségek több okból is alacsonyabbak lehetnek a felhő esetén. Egy fizikai

szerveren sok más alkalmazással osztozunk, így a számítógépek hatékonyabban kerülnek kihasználásra. Mivel a felhőszolgáltatók nagyok, méretgazdaságosságot érhetnek el a beszerzések, az adminisztráció, a hűtés és más infrastrukturális követelmények terén. Végül pedig az ügyfelek számos adminisztrációs feladattól mentesülnek bár a rendszeradminisztráció korántsem szűnik meg. Az ügyfeleknek továbbra is szükségük van rendszergazdákra a szoftvereik (a felhőben instances néven ismertek) létrehozásához és feltöltéséhez, a felhasználók engedélyezéséhez és egyéb, az üzleti működéshez kapcsolódó feladatokhoz. A rendszergazdáknak meg kell tanulniuk a szolgáltató API-ját és a szolgáltatás használatának szabályait, és ezt a képzési költséget be kell kalkulálni a tervekbe. Másrészt viszont óvatosnak kell lennünk, hogy mennyire használjuk a felhőt. Nehéz lehet nyomon követni, hogy mennyi számítógépes

energiát használunk, ha gyorsan felpörgetjük a szervereket, különösen, ha automatizáljuk a skálázást. Előfordulhat, hogy a periódus végén kellemetlenül nagy számlát kapunk. Hatékonyabb-e a felhő szén-dioxid-kibocsátás szempontjából, mint a saját számítógépek üzemeltetése? A kutatások szerint a felhőszolgáltatók sokkal hatékonyabban tudják működtetni a rendszereiket, mint mi. Nekünk azonban egy hálózaton keresztül kell kommunikálnunk ezekkel a 44 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika rendszerekkel, ami rengeteg áramot igényel az összes hálózati berendezés működtetéséhez, így sajnos a felhő növeli a karbonlábnyomunkat. A szolgáltatás rendelkezésre állása néha jobb a felhőben. Természetesen, ha a saját, helyben lévő adatközpontunktól függünk, akkor mindenféle problémának ki

lehetünk téve, a természeti katasztrófáktól kezdve a rosszindulatú belső szabotőrökig. De természetesen a felhőben lévő adatközpontok is leállnak. Ezért érdemes kihasználni a különböző rendelkezésre állási zónákat, és megosztani a kockázatot. Vannak olyan eszközök, amelyek lehetővé teszik, hogy szolgáltatásainkat egy meghibásodott zónából egy működő zónába helyezzük át. Ha a felhőszolgáltató által kínált szolgáltatásokat, például egy felhőben lévő adatbázist használunk, akkor az adott szolgáltatásban található hibáknak is ki vagyunk téve. Természetesen a rendszerbe betöltött szoftverben lévő hibák is érinthetnek minket. A gyártók szolgáltatásainak igénybevételével járó nagyobb kockázat a bezártság. Találhatunk egy automatizált konverziós eszközt, amellyel adatainkat áthelyezhetjük a szolgáltató rendszeréből az új rendszerbe, de egyáltalán nem biztos, hogy az az eszköz tökéletesen

végzi majd el a munkát. Felhő esetén nagyobb lehet a biztonság, mert a szolgáltató munkatársai valószínűleg jobb szakértők, mint a mi biztonsági csapatunk. Másrészt a felhőszolgáltatók nagyok és jól ismertek, ami nyilvánvaló célpontot jelent a támadásokhoz. Emellett egy további szoftver a virtuális gépeket vezérlő hypervisor hozzáadása új, potenciális veszélyt jelent. A kutatók találtak már sebezhetőségeket a hypervisorokban. Bár az ügyfél továbbra is az adatainak jogi tulajdonosa marad, az adatok felhőben történő tárolása elméletileg sebezhetőbbé teszi azokat. Általában az ügyfél titkosítja az adatokat, hogy betörés esetén megvédje azokat. Az adatvédelmi előírások, például a korábban említett GDPR, megkövetelik, hogy az adatokat biztonságosnak ítélt régióban lévő adatközpontban tárolják. Végső soron a legtöbb biztonsági támadás magas szinten kezdődik, például rosszindulatú szoftvereket

tartalmazó e-maileket küldenek egy gyanútlan alkalmazottnak. Nem számít, hogy helyben vagy a felhőben fut-e a rendszerünk. Azonban egy rosszindulatú behatoló, aki átveszi egy alkalmazott fiókját, nem jut sokkal messzebbre, hacsak nem tudja kihasználni a szervereken található sebezhetőségeket; így ismét nem egyértelmű, hogy a felhőben való futtatás nagy különbséget jelent-e, mivel a legtöbb sebezhetőséget inkább a szoftverben, mint a felhőszolgáltatásban találják meg. Végezetül vegyük figyelembe a sávszélességet és a hálózati költségeket! Az ügyfelei és valószínűleg a munkatársai is olyan szerverekkel kommunikálnak, amelyek akár több száz kilométerre is lehetnek egymástól. Ha a hálózati kapcsolat megbízhatatlan vagy lassú, a felhőalapú szerverek teljesítménye rosszabb lesz, mint helyben lévő adatközpont esetén. Manapság azonban mindenki távmunkásokkal, SaaS-szolgáltatásokkal és más, földrajzilag távol

lévő rendszerekkel tart Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 45 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek kapcsolatot. A hálózati teljesítménye szinte minden tevékenységet befolyásol, függetlenül attól, hogy a felhőt használjuk-e vagy sem. 46 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika Gyakorló feladatok 1. Miért hatékonyabb egy felhőközpontban lévő fizikai számítógép kihasználtsága, mint egy hagyományos, helyben lévő adatközpontban tárolt számítógépé? 2. Mi az a hibrid felhő? 3. A felhőalapú számítástechnika melyik típusa rendszergazda munkájára a kliens oldalán? esetén van szükség leggyakrabban a 4. Hogyan védhetjük meg szolgáltatásunkat a leállástól, ha felhőszolgáltatót használunk? Version:

2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 47 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Gondolkodtató feladatok 1. Hasonlítsuk össze a szerverek felhőben történő futtatása során felmerülő különböző költségeket a helyben történő futtatás költségeivel! 2. Tegyük fel, hogy a Közel-Keleten tevékenykedünk, de sok ügyfelünk van Európában és a TávolKeleten Hol helyeznénk el szolgáltatásainkat egy felhőalapú rendszer esetén? 48 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika Összefoglalás Ez a lecke felvázolta, hogyan működik a felhőalapú számítástechnika, és milyen kompromisszumokat jelent a felhő használata a saját adatközpontban, helyben futtatott rendszerekkel szemben. Megtanultuk a különböző üzleti és költségmodelleket, beleértve a

nyilvános, a privát és a hibrid felhők közötti különbségeket. Megtanultuk továbbá a felhőszolgáltatások különböző főbb típusait, és azt is, hogy mire használják őket. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 49 Open Source Essentials (Version 1.0) | Témakör 051: Szoftver alapismeretek Válaszok a gyakorló feladatokra 1. Miért hatékonyabb egy felhőközpontban lévő fizikai számítógép kihasználtsága, mint egy hagyományos, helyben lévő adatközpontban tárolt számítógépé? A felhőben minden egyes számítógépen több operációs rendszer példánya is futhat, sőt, akár különböző kliensek által feltöltött példányok is futtathatók, ezért a számítógép gyakrabban van használatban. 2. Mi az a hibrid felhő? A hibrid felhő használja egy felhőszolgáltató adatközpontjait és egy vagy több helyi adatközpontot is. 3. A felhőalapú számítástechnika melyik típusa rendszergazda

munkájára a kliens oldalán? esetén van szükség leggyakrabban a Az Infrastructure as a Service (IaaS) megköveteli, hogy a kliens végezze el a rendszergazdai feladatokat, például az operációs rendszer és az alkalmazások példányainak létrehozását és feltöltését. 4. Hogyan védhetjük meg szolgáltatásunkat a leállástól, ha felhőszolgáltatót használunk? Válasszunk több zónát minden régióban, ahol a szolgáltatást futtatjuk, mert nagyon valószínűtlen, hogy egyszerre több zóna is meghibásodjon. 50 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0513 On-premise és felhőalapú számítástechnika Válaszok a gondolkodtató feladatokra 1. Hasonlítsuk össze a szerverek felhőben történő futtatása során felmerülő különböző költségeket a helyben történő futtatás költségeivel! Felhő esetén a CPU-használatért és az adattárolásért fizetünk a

szolgáltató által mért minden egyes időszakra, de nem fizetünk hardverköltséget. Helyi futtatás esetén nekünk kell állni a hardver állandó költségeit, valamint egyéb eszközökét, például a légkondicionáló berendezésekét; továbbá olyan ismétlődő költségeink is vannak, mint az áramellátás és a fizikai karbantartás. Tegyük fel, hogy a Közel-Keleten tevékenykedünk, de sok ügyfelünk van Európában és a TávolKeleten. Hol helyeznénk el szolgáltatásainkat egy felhőalapú rendszer esetén? + Használjunk egy közel-keleti régiót a saját irodáink és közel-keleti ügyfelek számára! Egy európai régió fontos az általános adatvédelmi rendeletnek (GDPR) való megfelelés érdekében. Szükség lehet egy kínai régióra, hogy megfeleljünk a kínai személyes adatok védelméről szóló törvénynek (PIPL). Mindenesetre a távol-keleti és európai régiók megléte értékes a jobb teljesítmény érdekében, amikor az ottani

ügyfelekkel érintkezünk. + Az egyes régiókon belül válasszunk több zónát, hogy védelmet nyújtsunk egyetlen zóna meghibásodása ellen! Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 51 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Témakör 052: Nyílt forráskódú szoftverlicencek 52 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma 052.1 A nyílt forráskódú szoftverlicencek fogalma Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0521 Súlyozás 3 Kulcsfontosságú ismeretek • A nyílt forráskódú szoftver és a szabad szoftver fogalmának megértése • A pénzügyileg ingyenes szoftverek egyéb fajtáinak ismerete • A nyílt forráskódú szoftverek történetének fontos eseményeinek megismerése • Annak

megértése, hogy mi a licenc és milyen jogokat kezelnek a licencek általában • Annak megértése, hogy a meglévő szoftverek hogyan használhatók fel származtatott művek létrehozására • A licencek kompatibilitásának és inkompatibilitásának megértése • A kettős licencelés és a feltételes licencelés megértése • A licencszegések következményeinek megértése • A szerzői jog és a szabadalmi jog elveinek, valamint annak megértése, hogy a nyílt forráskódú szoftverlicencek hogyan befolyásolják ezeket A használt fájlok, kifejezések és segédprogramok listája • A Free Software Foundation (FSF) szabad szoftver definíciója • Az Open Source Initiative (OSI) nyílt forráskódú szoftver definíciója • Licencek • Szerződések Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 53 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek • Közkincs szoftverek •

Freeware • Shareware • Licencfelelősök • A kód és a szoftverek használatának, módosításának és terjesztésének engedélyei • Származékos művek és a kód újrafelhasználása • Zárt forráskódú/védett szoftverek • Fizetős terjesztés • Módosított és nem módosított szoftverek terjesztése • Hosting szoftver fizetős szolgáltatásként • Licenc-kompatibilitás • Kettős és többszörös licencelés • Feltételes licencelés • Szoftverszabadalmak • Explicit és implicit szabadalmi licencnyújtás 54 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 052 Nyílt forráskódú szoftverlicencek Fejezet: 052.1 A nyílt forráskódú szoftverlicencek fogalma Lecke: 1/1 Bevezetés Minden szoftverfejlesztő értékeli, ha egy problémát

hatékonyan megoldottak már korábban. Ha a megoldás elérhető az interneten, érthető reflex, hogy kipróbáljuk: bemásoljuk vagy belinkeljük a meglévő forráskódot a saját kódbázisunkba, teszteljük, és ha működik, ott is hagyjuk majd megfeledkezünk róla. De némi óvatosságra van szükségünk. Az interneten elérhető szoftverek forráskódja legtöbbször a szabad és nyílt forráskódú (FOSS) licencek hatálya alá tartozik. Ez a fejezet jogi szempontból tárgyalja a FOSS néhány alapfogalmát, valamint azt, hogy miért jobb ötlet a licencfeltételeket alaposan betartani és nem magától értetődőnek venni a FOSS forráskódot. A szoftverekkel kapcsolatos jogi kötelezettségeink megértéséhez tudnunk kell, hogy szinte minden szoftverre licenc vonatkozik. A licenc egyfajta szerződés Minden szoftvert, beleértve a weboldalakat is, a licenc írásos változatával együtt kell terjeszteni (gyakran “terms and conditions” (felhasználási

feltételek)). Egyes programok és weboldalak megkérnek minket arra, hogy pipáljuk be a jelölőnégyzetet, amely szerint elolvastuk a feltételeket (és ezt meg is kellene tennünk, habár a legtöbb ember soha nem teszi meg). Mindenesetre a szoftver használatával Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 55 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek hallgatólagosan elfogadjuk a licencet. A nyílt forráskódú szoftver és a szabad szoftver definíciói 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ő: Think of “free speech,” not “free beer.” (A szólásszabadságra és ne az ingyen sörre gondoljunk.) Richard Stallman, Selling Free Software 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. Szabad, mint a beszéd: Igazi szabadság a felhasználók számára 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: 1. A szoftver futtatása 56 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source

Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma 2. Tanulmányozása 3. Másoknak való átadása (redistribute) 4. A módosított változatok másolatainak továbbterjesztése 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. Nyílt forráskódú szoftver 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:

1. A szabad továbbterjesztés: Szabadon dönthetünk arról, hogy hogyan terjesztjük tovább a programot, akár ingyen, akár eladásra, mindaddig, amíg nem követelünk jogdíjat vagy licencdíjat. Ez a szabadság magában foglalja a programnak egy másik programba való beépítését is. 2. Forráskód elérhetősége, akár online, akár a szoftverrel együtt mellékelve 3. A származtatott munkák és módosítások létrehozásának és terjesztésének engedélyezése 4. A szerző forráskódjának integritása: A módosítások korlátozhatók, ha a felhasználók számára engedélyezik a program módosítását javításokkal (patch), és ezeket a patcheket a forráskóddal együtt terjeszthetik. A módosított forráskódból buildelt (épített, built) szoftver terjesztése nem korlátozható. 5. Zéró diszkrimináció személyek vagy csoportok irányába: Például egy olyan licenc, amely engedélyezi, hogy a szoftvert “csak tanárok” használhassák, nem felel meg

az Open Source Definitionnek. 6. Nincs megkülönböztetés a tevékenységi területek között: Például ne korlátozza a kereskedelmi felhasználást. 7. A licenc terjesztése: Mindenki, aki megkapja a programot, ugyanazt az eredeti licencet kapja 8. A licenc nem lehet termékspecifikus 9. A licenc nem korlátozhat más szoftvereket: Például a szoftverrel járó más szoftverek más licenccel rendelkezhetnek. 10. A licencnek technológiasemlegesnek kell lennie Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 57 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Szabadság vs nyílt forráskód 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 pénzügyileg szabad szoftverek

egyéb fajtái 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ő: Shareware Ez a kifejezés általában olyan jogvédett szoftverekre utal, amelyek megvásárolhatók, de bizonyos korlátozott funkciói ingyenesen használhatók, amíg a felhasználó úgy nem dönt, hogy megvásárolja a teljes verziót. Freeware Ez a kifejezés olyan szoftvereket jelöl, amelyeket ingyenesen és a felhasználás korlátozása nélkül terjesztenek, de nem feltétlenül a szabad szoftver hivatalos definíciójának megfelelően. A freeware sok esetben jogvédett, és a forráskódot gyakran egyáltalán nem adják ki. Source available software Néha a zárt forráskódú szoftverek fejlesztői elérhetővé teszik forráskódjukat (például a jobb hibajelentések megkönnyítése érdekében), de a forráskód más projektekben való felhasználásának feltételeként szabják meg a védett

licenc megszerzését. Ez a fajta szigorú korlátozásokkal történő rendelkezésre állás nem tévesztendő össze a tényleges nyílt forráskódú szoftverekkel. 58 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma Shared source software A Microsoft 2001-ben vezette be ezt a kifejezést, amikor a vállalat úgy döntött, hogy a szoftverek forráskódjának egy részét online elérhetővé teszi kutatás és tesztelés céljából. Ne tévesszük össze ezt a szűk definíciót a shareware vagy a forráskóddal elérhető szoftverekkel (source available software)! Public-domain software Ez olyan szoftver, amelynek szerzői lemondtak minden szerzői jogról. Ez a meghatározás nem minden joghatóságban érvényes (különösen azokban, ahol a szerzőnek “droit d’auteur” vagy “szerzői jog” jogokat biztosítanak, mint például

Franciaországban vagy Németországban). Olyan licenceket vezettek be, mint például az “Unlicense”, amelyek ugyanezt a hatást hivatottak kifejteni. Ezen túlmenően a szoftverek akkor is közkinccsé válhatnak, ha a szerzői jog időtartama lejárt. A szerzői jog alapelvei és azok hatása a nyílt forráskódú szoftverlicencekre 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. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 59 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek 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 szabadalmi jog alapelvei 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 60 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma 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. NOTE A különböző FOSS licencekről a következő leckékben lesz szó. 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. Licencszerződések 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: the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software (a Szoftver használatának, másolásának, módosításának, egyesítésének, közzétételének, terjesztésének, allicencelésének és/vagy eladásának jogát) MIT license 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: The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. (A Free Software Foundation időről-időre kiadhatja a General Public License felülvizsgált és/vagy új verzióit. Ezek az új verziók

szellemiségükben hasonlóak lesznek a jelenlegi verzióhoz, de az új problémák vagy aggályok kezelése érdekében részletekben eltérőek lehetnek.) GNU General Public License version 2 Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 61 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek 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. Terjesztés (distribution) A szoftver terjesztése (különösen bináris vagy forráskód formájában) a legtöbb FOSS licenc központi eleme, mivel a FOSS szoftverek puszta használata általában nem von maga után licencelési kötelezettséget: Activities other than copying, distribution and modification are not covered by this

License; they are outside its scope. The act of running the Program is not restricted (A másoláson, terjesztésen és módosításon kívüli más tevékenységekre a jelen Licenc nem terjed ki; ezek kívül esnek a licenc hatályán. A Program futtatása nem korlátozott) GNU General Public License version 2 A legtöbb licencelési kötelezettség csak a terjesztés, azaz a módosított vagy változatlan példány továbbadása esetén keletkezik, akár tárgyi adathordozón, például CD-n, akár letöltés útján történik. Bizonyos esetekben a licencfeltételek akkor is felmerülhetnek, ha a szoftver egy szerveren fut (azaz a forráskód terjesztése nélkül), miközben a felhasználó interakcióba lép a szoftverrel. A futtatható szoftverek terjesztéséhez a FOSS-licenc típusától függően szükséges lehet a forráskód, a licenc szövege és a szerzői jogi megjegyzések átadása is. Egyes licencek megkövetelik, hogy a megváltoztatott kód terjesztése esetén a

forráskódban módosítási megjegyzéseket helyezzenek el. Distribution could also trigger copyleft effects; i.e, upon distribution of GPLv3 licensed software that has been modified, the source code of the entire modified software may have to be released under the GPLv3. Bár FOSS esetén lehet értékesíteni, általában licencdíjat nem lehet kivetni. Ez például azt jelenti, hogy valaki a GPLv3 licenc alatt árulhat egy szoftvert csak bináris formában, de mivel a forráskód elérhető (vagy fel kell ajánlani), a szoftver iránt érdeklődők bármikor dönthetnek úgy, hogy beszerzik a forrásokat (esetleg valaki mástól, ingyen), és ezekből a forrásokból építik fel a szoftvert. Származékos munkák 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 62 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma 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. A licenc megsértésének következményei 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. Licenc kompatibilitás és inkompatibilitás 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

Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 63 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek 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. Kettős licencelés és többszörös licencek 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. 64 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma Gyakorló feladatok 1. Mit jelent a FOSS mozaikszó? 2. Az alábbiak közül melyek tartoznak kifejezetten a szabad szoftverek felhasználóinak alapvető szabadságjogai közé? Szoftver futtatása Szoftver tanulmányozása Szoftver másolása Szoftver módosítása Szoftver közzététele Szoftver

továbbterjesztése 3. Az interneten található, licencinformáció nélküli forráskódot bárki szabadon módosíthatja és terjesztheti? A választ fejtsük is ki! 4. Szabadalmaztatható-e a szoftver? Igen Nem Attól függ 5. Mi az a licenc-steward? Ugyanaz, mint az engedélyező Valaki, aki javaslatot tehet egy licenc jövőbeli verzióira Valaki, aki megszüntethet egy licencet Valaki, aki a repülőgépek szoftverét kezeli 6. A licenckompatibilitás mindig működik mindkét irányban? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 65 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Igen, ha két licenc kompatibilis, akkor nem számít, hogy A benne van-e B-ben, vagy B benne van A-ban. Nem, bizonyos esetekben előfordulhat, hogy az A licenc szerepelhet egy B licencű projektben, de a B-t nem lehet A licenc alatt terjeszteni. Nem, a licenc kompatibilitás mindig egyirányú. 66 |

learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma Gondolkodtató feladatok 1. A GPLv2 és az LGPLv21 licenc kompatibilis? Röviden fejtsük is ki a választ! 2. Lehet-e Open Content licencek (például CC-BY) alatt közzétenni a szoftvereket? Igen, a CC-licencek bármilyen szerzői jogi védelem alatt álló munkára alkalmazhatók. Nem, a szoftvereket csak szabadalmakkal lehet védeni. Nem, a CC-licencek nem alkalmazhatók szoftverekre. 3. Miért fontos a terjesztés a FOSS licenceléssel kapcsolatosan? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 67 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Összefoglalás Ez a lecke bevezetést nyújt a szabad és nyílt forráskódú szoftverek alapfogalmaiba, valamint a szerzői jog és a szabadalmak mögöttes fogalmaiba. Ismerteti

mind a szabad szoftverek, mind a nyílt forráskódú szoftverek alapjait és történetét, és segít megkülönböztetni mindkettőt a védett licencelés koncepcióitól. Az OSI nyílt forráskódú definíciója segít kategorizálni a licenceket nyílt forráskódú licencekként. Bár már több tucat FOSS licenc létezik, bárki szabadon bevezethet további licenceket. A licencelés fogalmát nem szabad alábecsülni: a licencek engedélyt adnak arra, hogy a szoftverrel olyan módon foglalkozzunk, amely egyébként kizárólag a szerzőnek van fenntartva. A licencek megsértése jogi vitákat eredményezhet. Ezért a szoftver terjesztése vagy más projektkódba való beépítése előtt jogi tanácsot kell kérni a licencek betartásával kapcsolatban. 68 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma Válaszok a gyakorló feladatokra 1. MMit

jelent a FOSS mozaikszó? Free and Open Source Software 2. Az alábbiak közül melyek tartoznak kifejezetten a szabad szoftverek felhasználóinak alapvető szabadságjogai közé? Szoftver futtatása X Szoftver tanulmányozása X Szoftver másolása Szoftver módosítása X Szoftver közzététele Szoftver továbbterjesztése X 3. Az interneten található, licencinformáció nélküli forráskódot bárki szabadon módosíthatja és terjesztheti? A választ fejtsük is ki! Nem. A forráskód, ha eléri az eredetiség küszöbét, alapesetben irodalmi műként szerzői jogi védelem alatt áll. Mivel a módosítás és a terjesztés a szerző kizárólagos jogát képezi, a szerzőn kívül senki más nem teheti ezt meg, illetve nem adhat rá engedélyt. 4. Szabadalmaztatható-e a szoftver? Igen Nem Attól függ X 5. Mi az a licenc-steward? Ugyanaz, mint az engedélyező Valaki, aki javaslatot tehet egy licenc jövőbeli verzióira X Valaki, aki megszüntethet egy

licencet Valaki, aki a repülőgépek szoftverét kezeli Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 69 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek 6. A licenckompatibilitás mindig működik mindkét irányban? Igen, ha két licenc kompatibilis, akkor nem számít, hogy A benne van-e B-ben, vagy B benne van A-ban. Nem, bizonyos esetekben előfordulhat, hogy az A licenc szerepelhet egy B licencű projektben, de a B-t nem lehet A licenc alatt terjeszteni. X Nem, a licenc kompatibilitás mindig egyirányú. 70 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0521 A nyílt forráskódú szoftverlicencek fogalma Válaszok a gondolkodtató feladatokra 1. A GPLv2 és az LGPLv21 licenc kompatibilis? Röviden fejtsük is ki a választ! Ha az A szoftver a GPLv2 licenc alatt, a B szoftver pedig az LGPLv2.1 licenc alatt áll, akkor

lehetséges a B használata az A-ban, mivel az LGPLv2.1 lehetővé teszi a használatot a GPLv2 licenc feltételei mellett. Az A azonban nem használható B-ben az LGPLv21 feltételei szerint Ha A-t B-ben használjuk, akkor a teljes szoftvert a GPLv2 licenc alatt kell licencelni, ami lehetséges, mivel az LGPLv2.1 lehetővé teszi a szoftver használatát a GPLv20 licenc alatt 2. Lehet-e Open Content licencek (például CC-BY) alatt közzétenni a szoftvereket? Igen, a CC-licencek bármilyen szerzői jogi védelem alatt álló munkára alkalmazhatók. X Nem, a szoftvereket csak szabadalmakkal lehet védeni. Nem, a CC-licencek nem alkalmazhatók szoftverekre. 3. Miért fontos a terjesztés a FOSS licenceléssel kapcsolatosan? Számos FOSS licenckötelezettség a szoftver terjesztésekor keletkezik. Ha a szoftvert soha nem terjesztik, hanem csak módosítják és használják egy zárt rendszerben (például egy vállalat részlegénél), akkor lehetséges a szoftver használata a

licenckötelezettségek betartása nélkül. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 71 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek 052.2 Copyleft szoftverlicencek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0522 Súlyozás 3 Kulcsfontosságú ismeretek • A copyleft szoftverlicencek koncepciójának megértése • A copyleft szoftverlicencek által biztosított jogok megértése • A copyleft szoftverlicencek által teremtett kötelezettségek megértése • A copyleft szoftverlicencek főbb tulajdonságainak megértése • A copyleft szoftverlicencek és más szoftverlicencek kompatibilitásának megértése • A “reciprocal license” és a “restrictive license” kifejezések ismerete A használt fájlok, kifejezések és segédprogramok listája • Copyleft • Distributing • Conveying • Tivoization • GNU General Public

License, version 2.0 (GPLv2) • GNU General Public License, version 3.0 (GPLv3) • GNU Lesser General Public License, Version 2 (LGPLv2) • GNU Lesser General Public License, Version 3 (LGPLv3) 72 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek • GNU Affero General Public License, Version 3 (AGPLv3) • Eclipse Public License (EPL), version 1.0 • Eclipse Public License (EPL), version 2.0 • Mozilla Public Licence (MPL) Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 73 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 052 Nyílt forráskódú szoftverlicencek Fejezet: 052.2 Copyleft szoftverlicencek Lecke: 1/1 Bevezetés A licencek fontosságát már ismertettük mind a szoftverek használata, mind a fejlesztés

szempontjából. Ezért nem meglepő, hogy a szabad szoftvereket a kezdetektől fogva a licencelés új megközelítései is jellemezték: a szoftverek korlátlan használatának vagy közös fejlesztésének feltételeit jogilag kell meghatározni ahhoz, hogy védelmet és érvényt lehessen szerezni. Annak tudatában, hogy a szerzői jog, amely a világ szinte valamennyi jogrendszerében szilárdan rögzült, nem kérdőjelezhető meg és nem helyettesíthető, a szoftverfejlesztők már az 1980-as években olyan megközelítést alkalmaztak, amely tiszteletben tartja a szerzői jogi szabályokat, de kiegészíti azokat a “szabadság” elvét hangsúlyozó új szabályozásokkal: copyleft. A Copyleft és a GNU General Public License (GPL) Richard Stallman, aki akkoriban a híres MIT fejlesztője volt, 1983-ban megalapította a GNU Projectet, hogy kifejlesszen egy szerinte “szabad” operációs rendszert. Hamarosan világossá vált, hogy a projekt által kifejlesztett kódot

jogilag védeni kell, hogy azt ne tudják egyszerűen átvenni a kereskedelmi szolgáltatók, és így “non-free”-vé (nem-szabaddá) váljon. 74 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek Stallman ezért 1985-ben megalapította a nonprofit Free Software Foundation (FSF) alapítványt, amely a következőképpen foglalja össze küldetését a honlapján: “The Free Software Foundation is working to secure freedom for computer users by promoting the development and use of free (as in freedom) software and documentation” (A Free Software Foundation a számítógépfelhasználók szabadságának biztosításán dolgozik a szabad (mint a szabadság) szoftverek és dokumentációk fejlesztésének és használatának előmozdításával) E küldetés kulcsfontosságú eszköze egy olyan licenc, amely egyrészt tiszteletben tartja az alkalmazandó jogszabályokat

(különösen a szerzői jogokat), másrészt jogilag tiszta módon valósítja meg a szabadságról alkotott elképzeléseit. Ennek eredménye volt a GNU General Public License (GPLv1) első változata 1989-ben. Ez a licenc és számos cikk mint például a “What is Free Software?” (Mi a szabad szoftver?), amelyet Stallman 1992-ben írt világossá teszi a szabad szoftverfejlesztők motivációit és értékeit, akik ma már “mozgalomként” is tekintenek magukra. A programozási magot továbbra is a Stallman által a fent említett cikkben megfogalmazott “négy alapvető szabadság” alkotja, amelyek számozása 0-val kezdődik: • The freedom to run the program as you wish, for any purpose (freedom 0). (A program tetszés szerinti futtatásának szabadsága, bármilyen célra (szabadság 0)) • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this (A szabadság a

program működésének tanulmányozásához, és megváltoztatásához úgy, hogy a számítást úgy végezze, ahogy szeretnénk (1. szabadság) Ennek előfeltétele a forráskódhoz való hozzáférés.) • The freedom to redistribute copies so you can help others (freedom 2) (A másolatok továbbterjesztésének szabadsága, hogy segíthessünk másokon (2. szabadság)) • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this. (A szabadság, hogy a módosított változatok másolatait másoknak is terjeszthessük (3. szabadság) Ezzel az egész közösségnek esélyt adhatunk arra, hogy profitáljon a változtatásainkból. Ennek előfeltétele a forráskódhoz való hozzáférés.) Richard Stallman, What is Free Software? Unlike licenses for commercial products, which place restrictions on use in the foreground,

free software is about maximum freedom for users and developers. A GNU GPLv1 preambuluma ezt a következőképpen foglalja össze: Specifically, the General Public License is designed to make sure that you have the freedom Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 75 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek to give away or sell copies of free software, that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. (Specifikusan, a General Public License célja, hogy biztosítsa, hogy a szabad szoftverek másolatait szabadon továbbadhassa vagy eladhassa, hogy a forráskódot megkaphassa vagy megszerezhesse, ha szeretné, hogy a szoftvert megváltoztathassa vagy darabjait új szabad programokban felhasználhassa; és hogy tudja, hogy ezeket a dolgokat megteheti.) GNU General

Public License, version 1 Ez azt jelenti, hogy mindenkinek joga van a GPL alá tartozó szoftverek korlátozás nélküli használatára, terjesztésére és módosítására (ami azért lehetséges, mert a forráskód hozzáférhető, azaz “nyílt”), cserébe a módosítások terjesztéséért. Még az is lehetséges, hogy pénzt kérjenek a szoftver továbbadásáért: Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license.Free programs are sometimes distributed gratis, and sometimes for a substantial price. Often the same program is available in both ways from different places The program is free regardless of the price, because users have freedom in using it. (Valójában arra bátorítjuk azokat, akik szabad szoftvereket terjesztenek, hogy annyit kérjenek értük, amennyit csak akarnak vagy tudnak. Ha egy licenc nem teszi lehetővé, hogy a

felhasználók másolatokat készítsenek és eladják azokat, akkor az nem szabad licenc.A szabad programokat néha ingyenesen, néha pedig jelentős összegért terjesztik. Gyakran ugyanaz a program mindkét módon, különböző helyeken elérhető. A program az árától függetlenül szabad, mert a felhasználók szabadon használhatják.) Free Software Foundation, Selling Free Software But if the freedoms are so far-reaching, to what extent is software protected under this license, for example from being incorporated into proprietary products? Ez a szerepe a korábban említett copyleft elvnek, amelyet a GPL már az 1. verzióban is alkalmaz, még ha a kifejezés még nem is szerepel kifejezetten: You may not copy, modify, sublicense, distribute or transfer the Program except as expressly provided under this General Public License. (A Programot nem másolhatja, módosíthatja, nem adhat allicencet, nem terjesztheti és nem ruházhatja át, kivéve a jelen General Public

Licenseben kifejezetten meghatározottak szerint.) GNU General Public License version 1 This means that all these freedoms are linked to the condition that users preserve these freedoms 76 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek in everything they do with the software. A Copyleft tehát nemcsak szabadságjogokat garantál, hanem minden felhasználótól megköveteli, hogy ezeket a szabadságjogokat másoknak is biztosítsa. Ezt úgy érik el, hogy a copyleft licenc alá tartozó szoftverek (mint például a korai GPLv1) csak akkor módosíthatók és terjeszthetők, ha a módosításokat ugyanolyan feltételek mellett, azaz ugyanezen licenc alatt teszik közzé. A szabad szoftverek eszménye, nevezetesen a szoftverek kollektív használata és továbbfejlesztése ezért elsőbbséget élvez az egyének szoftverrel kapcsolatos személyes igényeivel szemben. A

kölcsönösség elve kulcsfontosságú: aki él a szabadsággal, annak meg is kell adnia azt másoknak. A copyleft licenceket ezért gyakran nevezik reciprokális licenceknek. A szoftverlicencnek ez a teljesen új megközelítése már a GPL 1. verziójában is jogilag megalapozottnak és megvalósíthatónak bizonyult, így a GPL a modern informatikai piac fejlődésének közel 40 éve alatt mindössze két nagyobb módosításon esett át. GPLv2 és GPLv3 1991-ben a Free Software Foundation bemutatta a GNU General Public License 2. verzióját (GPLv2), amely hosszú éveken keresztül a szabad szoftverprojektek legnépszerűbb licenceként vált ismertté. A Linux operációs rendszer kernele például ma is a GPLv2 licenc védelmét élvezi Ha összehasonlítjuk a 2-es verziót az 1-es verzióval, azt látjuk, hogy a kétértelműségek elkerülése érdekében pontosabb meghatározásokat tartalmaz. Például a 2-es verzió sokkal részletesebben megmagyaráza, hogy mit jelent a

“forráskód”. Szintén érdekes az új 7. Szakasz (Section), amely a szabadság elvét és így a licenc érvényességét abszolútnak tekinti, és nem enged meg semmilyen kompromisszumot például kevésbé szabad részek beépítését a szoftverbe: If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. (Ha Ön nem tudja úgy terjeszteni a Programot, hogy a jelen Licenc szerinti kötelezettségeinek és bármely más vonatkozó kötelezettségének egyszerre eleget tegyen, akkor ennek következtében a Programot egyáltalán nem terjesztheti. Például, ha egy

szabadalmi licenc nem tenné lehetővé a Program jogdíjmentes továbbterjesztését mindazok számára, akik közvetlenül vagy közvetve Önön keresztül másolatokat kapnak, akkor az egyetlen módja annak, hogy ezeknek és a jelen Licencnek is eleget tegyen, az lenne, ha teljesen tartózkodna a Program terjesztésétől.) Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 77 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek GNU General Public License version 2 Csak 16 évvel később, 2007-ben tette közzé az FSF a GPL új változatát, hogy figyelemmel legyen a technikai újításokra például a szoftverszolgáltatások interneten keresztül történő biztosítását --, valamint a más FOSS licencekkel való kompatibilitás kérdéseit. A licenc azonban az alapvető kijelentéseit tekintve stabil maradt, és csupán a további pontosítás érdekében újabb részletekkel egészült ki. Nézzünk

meg néhány ilyen kiegészítést közelebbről! Míg a GPLv2 még mindig általánosságban terjesztésként (distribution) említi a szoftver rendelkezésre bocsátását, a GPLv3 két új kifejezéssel pontosítja ezt a folyamatot: propagálás (propagation) és átruházás (conveying). Ennek fő oka az, hogy a “terjesztés” kifejezést világszerte számos szerzői jogi törvény határozza meg. A félreérthetőség és a konfliktusok elkerülése érdekében a GPLv3 ezeket az új kifejezéseket használja, és a következőképpen határozza meg őket: To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. (Egy munka “propagálása” azt

jelenti, hogy bármi olyat tesz vele, ami engedély nélkül közvetlenül vagy másodlagosan felelőssé teszi Önt a vonatkozó szerzői jogi törvények szerinti jogsértésért, kivéve a számítógépen történő végrehajtását vagy egy magánmásolat módosítását. A propagálás magában foglalja a másolást, a terjesztést (módosítással vagy anélkül), a nyilvánosság számára hozzáférhetővé tételt, és egyes országokban egyéb tevékenységeket is.) To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. (Egy munka “átruházása” minden olyan propagálást jelent, amely lehetővé teszi más felek számára, hogy másolatokat készítsenek vagy kapjanak. A felhasználóval való puszta interakció egy számítógépes hálózaton keresztül, másolat átadása nélkül, nem minősül átruházásnak.)

GNU General Public License version 3 Mivel jelentősen megnőtt azon kereskedelmi szoftvertermékek száma, amelyek forgalmazását a gyártók olyan technikai intézkedésekkel korlátozzák, mint a regisztrációs kódok vagy hardverkomponensek (úgynevezett dongles), az 1990-es évek végén számos nemzetközi jogi kezdeményezés született az ilyen intézkedések megkerülésének kriminalizálására. Ez az úgynevezett digitális jogkezelés (Digital Rights Management DRM), amelyet az ellenzők lekicsinylően digitális korlátozások menedzselésének is neveznek. Ez szálka az FSF szemében, mivel az intézkedések alapvetően ellentmondanak a szoftverek szabad terjesztésének igényének. 78 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek Válaszul a GPL 3. verziója tartalmaz egy olyan passzust, amely kimondja, hogy a GPL alá tartozó szoftverek nem

módosíthatók a DRM jogi követelményeire hivatkozva. Ez azt is jelenti, hogy a GPLv3 alatt licencelt szoftverek használhatnak DRM-et, de mások meg is kerülhetik ezeket az intézkedéseket. A tivoizálás (tivoization) kifejezést is gyakran használják ebben az összefüggésben. A szó kifejezetten szerepelt a GPLv3 első tervezeteiben, de a végleges változatba nem került bele. A kifejezés a TiVo nevű cégre vezethető vissza, amely a digitális videomagnójában GPLv2-licencű szoftvert használt, ugyanakkor technikailag megakadályozta, hogy módosított szoftvereket telepítsenek és használjanak a készülékre. Az FSF véleménye szerint ez ellentmondott a GPL elveinek, és némi vita után a GPLv3 ezt figyelembe veszi az úgynevezett felhasználói termékekre (user products) vonatkozó bekezdéssel. Ez általánosságban előírja, hogy a GPLv3 licencelt szoftvert használó termékeknek tájékoztatást kell adniuk arról is, hogyan lehet ezt a szoftvert

módosítani. Egy további kiegészítés a szabadalmakra vonatkozik, amelyeket az FSF a szoftverekkel kapcsolatban a szabadság és az innováció akadályozására hivatkozva alapvetően elutasít. Ez már a GPLv3 preambulumában is szerepel: Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. (Végezetül, minden programot folyamatosan fenyegetnek a szoftverszabadalmak. Az államoknak nem szabadna megengedniük, hogy a szabadalmak korlátozzák a szoftverek fejlesztését és használatát az általános célú számítógépeken, de azokban az államokban, ahol igen, szeretnénk elkerülni azt a különleges veszélyt, hogy a

szabadalmak egy szabad programra alkalmazva azt ténylegesen jogvédetté tehetik. Ennek megakadályozása érdekében a GPL biztosítja, hogy a szabadalmak nem használhatók fel arra, hogy a program ne legyen szabad.) GNU General Public License version 3 A licenc szövege több olyan passzust is tartalmaz, amely lehetővé teszi a szabadalom alá tartozó kód beillesztését a licencadó “nem kizárólagos, világméretű, jogdíjmentes szabadalmi licencével” annak érdekében, hogy megvédje az ilyen kód felhasználóit a szabadalmi jogosultak és a licencjogosultak közötti vitáktól. A GNU Affero General Public License (AGPL) Az internet növekvő elérhetőségével és sebességével egyre több olyan szolgáltatás jelenik meg, Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 79 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek amelyekben a szoftvert csupán telepítik a szolgáltató az

alkalmazásszolgáltató (Application Service Provider ASP) szervereire, és amelyek ügyfelei az interneten keresztül lépnek kapcsolatba a szolgáltatásokkal. Ez a trend a Software as a Service (SaaS) elnevezést kapta Ilyen esetekben a GPLv2 nem adott egyértelmű tájékoztatást arról, hogy a (szolgáltató által esetleg módosított) forráskódot hozzáférhetővé kell-e tenni, és ha igen, hogyan. A GPL 3 verziója ezt a ASP-loophole-nak nevezett kiskaput azzal zárja be, hogy a 13. szakaszban kifejezetten utal az FSF által 2007-ben kiadott másik licencre: a GNU Affero General Public License 3. verziójára (GNU AGPLv3). A név az Affero cégre vezethető vissza, amely kifejlesztette és kiadta ennek a licencnek az első két változatát. Ez az AGPLv3 alapvetően megfelel a GPLv3-nak, de kifejezetten szabályozza az ASP-problémát a “távoli hálózati interakció” (remote network interaction) szakaszban. Továbbá mindkét licenc kifejezetten kimondja, hogy

korlátozás nélkül kombinálhatók egymással. Összefoglalva, a GNU AGPL a GPL kiegészítő kiegészítője. Az AGPL kiterjeszti a GPL hatályát azáltal, hogy a copyleftet olyan szoftverekre is alkalmazza, amelyeket már nem helyi telepítésben, hanem kizárólag hálózaton keresztül továbbított szolgáltatások formájában használnak. A copyleft licencek kompatibilitása A szabad szoftverek fejlesztése mások munkájára építve, azaz mások forráskódjának integrálásával, módosításával és megosztásával virágzik. Ha egy módosított vagy újonnan lefordított szoftver minden része ugyanazon copyleft licenc, például a GPLv3 alatt áll, akkor ez jogi problémák nélkül lehetséges. A licenc egyszerűen megköveteli, hogy az eredményt ugyanezen licenc alatt terjesszék. A dolgok bonyolultabbá válnak, amikor a szoftver a különböző licencek hatálya alatt áll. Ebben az esetben több tényezőt kell figyelembe venni. Kombinált és származékos

művek A szabad szoftverek néha nagyon eltérő feltételek mellett jönnek létre. A változtatások az egyszerű hibajavításoktól a több millió sornyi kódot tartalmazó összetett projektekig terjednek. A terjedelemtől függetlenül a licencelés tekintetében alapvetően kétféle munkát különböztetünk meg: származékos és kombinált. Tegyük fel például, hogy az A szoftverprojektből hiányzik egy bizonyos funkció. Ahelyett, hogy ezt a funkcionalitást a semmiből fejlesztenénk ki, érdemes egy másik, pontosan ezt a funkcionalitást nyújtó B projekt kódját kombinálni A-val. A B-ből származó szoftvert ehhez nem is kellene megváltoztatni, hanem egyszerűen hozzá lehetne adni A-hoz. Ez tehát egy kombinált projekt Ha 80 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek mind az A, mind a B ugyanazzal a copyleft licenccel rendelkezik, akkor a

kombinált projekt nem jelent problémát. Ha A és B különböző copyleft licencek alatt áll, óvatosságra van szükség: az A és B kombinációja már különálló munka? És ha igen, akkor melyik licenc alatt lehet vagy kell licencelni? Vagy elkerülhető a konfliktus azáltal, hogy az A és B részek külön-külön megmaradnak a saját licencükkel, és nem alkotnak új munkát? Ez még nehezebbé válik a származékos művek esetében, azaz amikor az A projekt csak úgy tudja felhasználni a B funkcionalitását, hogy a B kódját közvetlenül beépíti az A kódjába. Ez az integráció egy új, származékos projektet hoz létre, amelynek részeit már nem lehet szétválasztani. A copyleft a származékos projektek esetében lép életbe. Ha például az A copyleft licenc alatt áll, mint például a GPLv3, akkor a kölcsönösség elvének megfelelően az új, származékos munkának is a GPLv3 alatt kell állnia. De mi van akkor, ha B más licenc alatt áll? Ez is

copyleft licenc, és kompatibilis a GPLv3-mal? Vagy ha más típusú licencről van szó, akkor B-t is lehet-e más licenc alatt közzétenni, azaz újralicencelni? Vagy A és B licencek kategorikusan kizárják egymást? Ebben a leckében nem az a cél, hogy felsoroljuk a lehetséges kombinációkat és a lehetséges megoldásokat. A lényeg az, hogy bemutassuk a probléma összetettségét, amely a nagyon különböző kérdések kombinációjából adódik. Technikailag az első dolog, amit tisztázni kell, hogy a szoftver különböző részei (példánkban A és B) hogyan működnek együtt: elválaszthatók-e egymástól, vagy vannak-e olyan folyamatok, amelyek végrehajtása már nem rendelhető egyértelműen egyik vagy másik részhez? Jogi szempontból kérdésként merül fel, hogy milyen viszonyban állnak egymással A és B licencei. Összeegyeztethetőek-e egymással, vagy csak részben, vagy csak az egyik irányba? Lehetséges-e az újralicencelés? Itt csak utalni

tudunk ezeknek a kérdéseknek a bonyolultságára, megoldani nem tudjuk őket. Az ilyen döntésekhez alapos jogi ismeretekre van szükség. Ezért az új munkákra, de különösen a kombinált és származékos projektekre vonatkozó engedélyezési döntéseket korán, gondosan és mindig részletes jogi tanácsadás után kell meghozni. Gyengébb copyleft A copyleft rendkívül robusztusnak bizonyult az elmúlt évtizedekben, különösen a GPL 2-es és 3-as verziójaként. Azonban különleges technikai követelmények miatt az FSF-nek adaptálnia kellett a licenceit; a GNU Affero General Public License például ilyen. A következő alfejezetekben további példákról lesz szó. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 81 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek A GNU Lesser General Public License (LGPL) Gyakran használt módszer szoftverfejlesztés során, hogy kis modulokat

használnak standard feladatokhoz, mint például fájlok megnyitása vagy mentése. Ezeket a modulokat vagy az ilyen modulok gyűjteményeit szoftverkönyvtáraknak (software library) nevezik. Ezek általában nem független végrehajtó alkalmazások, de rutinok, hogy a tényleges alkalmazás tudja integrálni azt, ami szükséges. Az integrációs folyamatok linking néven ismertek, ahol megkülönböztetés van a két módszer között. A statikus könyvtárak esetében a tényleges alkalmazás (segédprogramokon és köztes lépéseken keresztül) szilárdan integrálja a modulok kódját az alkalmazás futtatható fájljába. Ezzel szemben a dinamikus könyvtárak esetén az alkalmazás csak akkor integrál egy modult, amikor az a futáskor szükséges ekkor tölti be azt az aktív memóriába. Ez felvet egy kérdést a copyleft és a licencelés tekintetében: milyen licencjogi következményei vannak a linkelésnek? Például az átvételnek ez a formája megköveteli-e,

hogy a GPL alatti könyvtárat használó alkalmazás maga is átvegye a GPL-t? És ez vonatkozik-e mind a statikus, mind a dinamikus linkelésre? A linkelési folyamat annyira mindennapos a szoftverfejlesztésben, valamint a reciprokális copylefthez kapcsolódó problémák annyira kiterjedtek, hogy az FSF már korán olyan licencelési megoldást keresett, amely lehetővé teszi a linkelést a GNU Lesser General Public License (LGPL) segítségével. Az LGPL a GPL minden egyes új verziójával egy időben frissül A licenc neve az 1 verzióban GNU Library General Public License volt, ami rávilágított arra az eredeti problémára, ami a licenc létrehozásához vezetett. A 2 és 3 verzió a “Library” helyett a “Lesser” (kisebb/kevesebb) szóval jelzi, hogy valójában miről is van szó, nevezetesen a copyleft elv pragmatikus gyengítéséről. Az LGPL alatt licencelt könyvtárat tehát használhatja egy szoftver anélkül, hogy maga a szoftver automatikusan a copyleft

hatálya alá tartozna. Az úgynevezett permisszív (megengedő) licencek alá tartozó szoftverprojektek (amelyekről egy másik leckében lesz szó) különösen profitálnak ebből a kompromisszumból, mivel ez olyan megközelítések kombinációjának teremt jogi védelmet, amelyek a licencjog szerint önmagukban nem lennének kompatibilisek. Az LGPL-licenc alatt álló szoftvereken végrehajtott változtatások továbbra is a copyleft hatálya alá tartoznak, azaz szintén az LGPL alatt kell állniuk. Az LGPL-licenc alatt álló könyvtárnak azonban cserélhetőnek kell lennie, hogy a szoftver felhasználója egy módosított verzióval helyettesíthesse azt. Ehhez megfelelő feltételeket kell teremteni, azaz tájékoztatást kell adni arról, hogy hogyan lehet ilyen cserét végrehajtani. 82 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek Egyéb copyleft licencek Más

FOSS-projektek és szervezetek is keresik a saját igényeiknek legmegfelelőbb jogi keretet, ezért pedig saját licenceket fejlesztenek ki. Ilyen például az 1998-ban alapított Mozilla Foundation, amely ma leginkább az általa támogatott két projektről ismert: a Firefox internetböngészőről és a Thunderbird e-mail kliensről. A Mozilla Public License (MPL) 1. verziója 1998-ban jelent meg, a jelenlegi (2024) 20 verzió pedig 2012-ben. Az LGPL-hez hasonlóan az MPL-t is gyakran nevezik “weak copyleft” (gyenge copyleft) licencnek. Valójában egyensúlyt próbál teremteni a copyleft szigorú követelményei és a kereskedelmi termékekkel való integráció lehetőségei között. Ezt többek között a file-level copyleft néven ismert elvvel éri el: ha módosítunk egy olyan fájlt, amely az MPL alá tartozó szoftverhez tartozik, akkor ezt a fájlt integrálhatjuk a zárt szoftverekbe mindaddig, amíg maga a módosított fájl az MPL alatt marad, és így

hozzáférhető. Egy másik példa a gyenge copyleft licencre az Eclipse Foundation Eclipse Public License (EPL). A jelenlegi, 2017-es 2.0-s verzió nagyon hasonlít az MPL-re, és gyakran a leginkább “üzletbarát” copyleft licencként emlegetik. A különböző copyleft licencek és az itt említetteken kívül vannak még mások is azonban gyakran inkább a történelmi fejlődés, mintsem egyértelmű jogi különbségek miatt keletkeztek. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 83 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Gyakorló feladatok 1. Minek a rövidítése a GPL? 2. Miért hívják a copyleft licenceket reciprokálisnak is? 3. Melyik FSF copyleft licenc alkalmas szoftverkönyvtárakhoz? 4. Mely angol szavak váltották a “distribution” kifejezést a GPLv3-ban és miért? 5. Az alábbi copyleft licencek közül melyiket adta ki a Free Software Foundation? GPL

version 3 AGPL version 1 LGPL version 2 MPL 2.0 EPL version 2 84 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek Gondolkodtató feladatok 1. Az alábbiak közül melyek copyleft licencek? GPL version 2 3-clause BSD License LGPL version 3 CC BY-ND EPL version 2 2. Létrehozható-e tipikusan olyan származékos projekt, amely két olyan szoftverprojekt részeit egyesíti, amelyek különböző erős copyleft licencek védelme alatt állnak? Indokoljuk meg! 3. Az alábbi licencek közül melyek strong copyleft és melyek a weak copyleft licencek? Common Development and Distribution License (CDDL) 1.1 GNU AGPLv3 Microsoft Reciprocal License (MS-RL) IBM Public License (IPL) 1.0 Sleepycat License 4. Describe some compatibility issues that could arise when combining software under a weak copyleft license with software under a non-copyleft license. Version: 2024-08-12 | CC BY-NC-ND

4.0 alatt licencelve | learning.lpiorg | 85 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Összefoglalás Ez a lecke a copyleft elvét követő szoftverlicencek jellemzőivel foglalkozik. Jelenleg az 1980-as években a Free Software Foundation által kifejlesztett GNU General Public License (GPL) a legnépszerűbb, erős szerzői jogvédelemmel rendelkező licenc. Az aktuális 3 verzióig többször átdolgozott változata ellenére alapvető követelményei gyakorlatilag változatlanok maradtak: a licenc által biztosított, a szoftver korlátozás nélküli használatára, továbbterjesztésére és módosítására vonatkozó szabadságot mindenkor meg kell őrizni. Ez azt jelenti, hogy a módosított szoftver csak azonos feltételek (azaz azonos licenc) mellett terjeszthető. A technikai újítások, valamint a más projektekkel való együttműködés során a jogi mozgástér iránti igény arra késztette az FSF-et, hogy

kiegészítő vagy alternatív licenceket dolgozzon ki. A GNU Lesser General Public License (LGPL) például figyelembe veszi a szoftverfejlesztés során gyakran használt szoftverkönyvtárak statikus vagy dinamikus összekapcsolását. A GNU Affero General Public License (AGPL) arra a technikai trendre reagál, hogy a szoftvereket nem helyi telepítésben, hanem hálózaton (különösen az interneten) keresztül, szolgáltatások formájában használják. Az FSF mellett más projektek, például a Mozilla Foundation és az Eclipse Foundation is kifejlesztett copyleft licenceket. Ezek szintén kompromisszumot keresnek a licenc által biztosított szabadságjogok biztosítása és a más licencek alá tartozó szoftverekhez való egyszerűbb viszony között egy gyengébb copyleft révén. A licencek kompatibilitása elvileg fontos kérdés a copyleft licencek esetében, mivel a szabad, közös szoftverfejlesztés elvét össze kell egyeztetni az adott licenc által meghatározott

jogi feltételekkel. A különböző licencek alá tartozó szoftverek bármilyen kombinációja esetén a jogi feltételeket minden egyes esetben gondosan meg kell vizsgálni. 86 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek Válaszok a gyakorló feladatokra 1. Minek a rövidítése a GPL? General Public License 2. Miért hívják a copyleft licenceket reciprokálisnak is? A copyleft elve megköveteli, hogy korlátozás nélkül adjuk meg a licenc által biztosított szabadságokat másoknak. Ha például a GPL védelme alatt módosítjuk a szoftvert, akkor kötelesek vagyunk ezeket a módosításokat mások számára is hozzáférhetővé tenni ugyanilyen feltételekkel, a kölcsönösség elve alapján. 3. Melyik FSF copyleft licenc alkalmas szoftverkönyvtárakhoz? GNU Lesser General Public License (GNU LGPL) 4. Mely angol szavak váltották a “distribution” kifejezést

a GPLv3-ban és miért? A “convey” és “propagate” kifejezések váltották a “distribution” szót. Ennek hátterében az áll, hogy a “distribution” kifejezés szilárdan rögzítve van a nemzetközi szerzői jogban. A konfliktusok és félreértések elkerülése érdekében a GPL 3. verziója nem használja ezt a kifejezést. 5. Az alábbi copyleft licencek közül melyiket adta ki a Free Software Foundation? GPL version 3 X AGPL version 1 LGPL version 2 X MPL 2.0 EPL version 2 Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 87 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Válaszok a gondolkodtató feladatokra 1. Az alábbiak közül melyek copyleft licencek? GPL version 2 X 3-clause BSD License LGPL version 3 X CC BY-ND EPL version 2 X 2. Létrehozható-e tipikusan olyan származékos projekt, amely két olyan szoftverprojekt részeit egyesíti, amelyek különböző erős

copyleft licencek védelme alatt állnak? Indokoljuk meg! Nem. Az erős copyleftet tartalmazó licencek általában megkövetelik, hogy a módosított verziók ugyanezen licenc alatt legyenek. Ez kizárja az újbóli licencelést is A licencek kombinációja feloldhatatlan ellentmondást jelent, ha mindkettő ezeket az elveket követi. 3. Az alábbi licencek közül melyek strong copyleft és melyek a weak copyleft licencek? Common Development and Distribution License (CDDL) 1.1 weak GNU AGPLv3 strong Microsoft Reciprocal License (MS-RL) weak IBM Public License (IPL) 1.0 weak Sleepycat License strong 4. Mondjunk néhány kompatibilitási problémát, amelyek akkor merülhetnek fel, ha gyenge copyleft licencű szoftvert kombinálnak nem copyleft licencű szoftverrel! Míg az erős copyleft megköveteli, hogy a módosított szoftvert ugyanazon licenc alatt terjesszék, addig a gyenge copyleft esetében a feltételek “lazábbak”. Mindazonáltal minden más licenccel való

kombináció alapvető kompatibilitási kérdéseket vet fel. E kérdések megválaszolásakor fontos szempontokat kell figyelembe venni: a két szoftverprojekt eredeti részei egyértelműen elkülönülnek-e az új projektben, és ha szükséges, akkor továbbra is különböző licencekkel rendelkeznek-e? Milyen szinten történik valójában a kapcsolat a két eredeti szoftverprojekt között? A forráskódot közvetlenül átveszik, vagy “csak” dinamikusan linkelik a másik szoftverrel (könyvtárral)? A két licenc közül az egyik általában lehetővé teszi az újbóli licencelést? Minden ilyen jellegű kérdésre csak a vonatkozó licencek pontos elemzése után és 88 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0522 Copyleft szoftverlicencek jogi szakértelem birtokában lehet választ adni. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 89 Open Source

Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek 052.3 Megengedő szoftverlicencek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0523 Súlyozás 3 Kulcsfontosságú ismeretek • A megengedő szoftverlicencek fogalmának megértése • A megengedő szoftverlicencek által biztosított jogok megértése • A megengedő szoftverlicencek által teremtett kötelezettségek megértése • Az általános engedélyező szoftverlicencek főbb tulajdonságainak megértése • A megengedő szoftverlicencek és más licencek kompatibilitásának megértése A használt fájlok, kifejezések és segédprogramok listája • 2-Clause BSD License • 3-Clause BSD License • MIT License • Apache License, version 2.0 90 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek Lecke 1 Tanúsítvány: Open Source

Essentials Verzió: 1.0 Témakör: 052 Nyílt forráskódú szoftverlicencek Fejezet: 052.3 Permisszív szoftverlicencek Lecke: 1/1 Bevezetés A permisszív (megengedő) licencek jelenleg a legszélesebb körben használt nyílt forráskódú licencek, szemben a korlátozó (restrictive) licencekkel, mint amilyen például a GNU General Public License (GPL). A megengedő szoftverlicencek általában egyszerűek és rugalmasak, és széles körű szabadságot biztosítanak a szerzőknek talán a legszélesebb körű szabadságot a nyílt forráskódú licencek között. Ez a fajta licenc széleskörű szabadságot biztosít a szoftverfejlesztőknek a szoftver felhasználása, módosítása és terjesztése tekintetében, feltéve, hogy elismerik az eredeti szerzőt. Például általában valaki terjeszthet egy származékos művet zárt forráskódú licenc alatt, feltéve, hogy a projekt tartalmazza azon munka szerzőjének a megnevezését, amelyből az új termék

származik. Ennek a logikának az az elve, hogy a szoftver lehető legnagyobb mértékű terjesztését tegye lehetővé. A megengedő licencek azt állítják, hogy a szoftver kereskedelmi felhasználásának megkönnyítése révén az egyének és a nyilvánosság javát szolgálják, miközben a szerzői jogok a tulajdonosi jogok megadásával megmaradnak. Nem véletlen, hogy az első és legfontosabb megengedő szoftverlicenceket az akadémiai területen Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 91 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek fejlesztették ki, mint például a kaliforniai Berkeley Egyetem BSD-szerű licenceit vagy a Massachusetts Institute of Technology MIT/X11 licencét. Ezeket akadémiai nyílt forráskódú licenceknek nevezik. Az iparágon belüli hatásuk olyan mértékű volt, hogy megalapozták a hasonló, akadémiai kontextuson kívül született permisszív

szoftverlicencek, például az Apache Software Foundation Apache License-ének alapjait. A permisszív szoftverlicencek jogai és kötelezettségei Általában a legnépszerűbb megengedő szoftverlicencek korlátlan jogot biztosítanak az engedélyesnek a következőkre: A szoftver használata A permisszív szoftver licenc által lefedett szoftvert bárki használhatja (az egyéni felhasználók, a kereskedelmi vállalatok, a hatóságok) és bármilyen céllal, legyen az akár személyes vagy professzionális. A szoftver módosítása A szoftver továbbfejleszthető, adaptálható, vagy akár komponensként (pl. könyvtár) más szoftverekbe integrálható. A szoftver továbbterjesztése Ha a szoftvert származékos munka formájában módosítják, akkor a különböző licencek, beleértve a zárt licenceket is, alapján továbbterjeszthető. A permisszív szoftverlicencek egyetlen kötelezettsége általában a tulajdonosi hozzájárulás: az engedélyes köteles feltüntetni a

szoftver eredeti szerzőjének nevét a származékos munkában, és a szoftver továbbterjesztésekor a licenc szövegének másolatát is tartalmaznia kell. A legfontosabb engedélyköteles szoftverlicencek jellemzői Ez a szakasz elmagyarázza a különbségeket az MIT/X11 licenc, a legelterjedtebb BSD licencek és az Apache 2.0 licenc között, melyek manapság széles körben használatosak MIT/X11 licenc A MIT/X11 licenc (szövege: https://opensource.org/license/mit), más néven X11 licenc, egyike a korábban említett tudományos licenceknek. A licenc nevét a Massachusetts Institute of Technology által 1987-ben kifejlesztett X Window System szoftverről kapta. Ez a licenc az egyik legrégebbi és legnépszerűbb permisszív szoftverlicenc, részben egyszerű, világos nyelvezete miatt. 92 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek Ez a licenc biztosítja az

engedélyes számára a következő jogokat: • A szoftver használata, módosítása és terjesztése • A szoftver kereskedelmi forgalomba hozatala, módosításokkal vagy anélkül • Származékos munkák kiadása más licenc alatt, akár zárt forráskódú szoftverként is Az engedélyes kizárólagos kötelezettsége, hogy a szerzői jogi közleményt és a licenc szövegét a szoftver vagy annak származékos munkái forráskódjába beépítse. A MIT/X11 licenc kompatibilisnek tekinthető az összes legfontosabb copyleft licenccel, mind a weak, mind a strong licencekkel. Az MIT/X11 licenc különösen kompatibilis a következő licencekkel • GNU General Public License (GPL), 2.0 és 30 verzió • GNU Lesser General Public License (LGPL), 2.0 és 30 verzió • Mozilla Public License (MPL) Ez azt jelenti, hogy az eredetileg MIT/X11 licenc alatt licencelt szoftverek származékos munkái a fent említett licencek valamelyike alatt is terjeszthetők, vagy beépíthetők a

fent említett licencek valamelyike alatt kiadott projektekbe. 2 klauzulás BSD licenc A 2-Clause BSD License (2 záradékos/klauzulás BSD licenc) (szövege: https://opensource.org/ license/bsd-2-clause) az eredeti BSD licencből származik. 1980-ban hozta létre a Berkeley Egyetem Kaliforniában a BSD licenceként (ami egy Unix-szerű operációs rendszer). A licenc egyszerűségéről ismert és ahogy a neve is mutatja, mindössze két rövid záradékból áll. Lényegében azonos az MIT/X11 licenccel. Mint az MIT/X11 licenc, ezt is fel kell tüntetni a szoftverben. Ezenkívül a 2 klauzulás BSD licenc megköveteli, hogy a licenc jogosultja a kód továbbterjesztésekor a dokumentációban és egyéb átadott anyagokban is szerepeltesse a licenc szövegét. Összefoglalva a 2 klauzulás BSD licenc biztosítja a jogokat: • A szoftver használatára, módosításéra és terjesztésére • A szoftver kereskedelmi forgalomba hozatalára, módosítással vagy anélkül •

származékos művek kiadására más licenc alatt, akár zárt forráskódú szoftverként is Az engedélyes köteles: Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 93 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek • Hozzáadni a szerzői jogi közleményt és a licenc szövegét a szoftver vagy az abból származékos munkák forráskódjához és bináris változatához • Hozzáadni a szerzői jogi közleményt és a licenc szövegét a szoftverrel együtt szállított dokumentációjához vagy egyéb anyagokhoz A 2 klauzulás BSD licenc kompatibilisnek tekinthető az összes főbb copyleft licenccel, mind a weak, mind a strong licencekkel. A 2 klauzulás BSD licenc különösen kompatibilis a következőkkel: • GNU General Public License (GPL), 2.0 és 30 verzió • GNU Lesser General Public License (LGPL), 2.0 és 30 verzió • Mozilla Public License (MPL) Ezért az eredetileg a 2

klauzulás BSD licenc alatt licencelt szoftverek származékos munkái a fent említett licencek valamelyike alatt is terjeszthetők, vagy beépíthetők a fent említett licencek valamelyike alatt kiadott projektekbe. 3 klauzulás BSD licenc A 3-Clause BSD license (3 klauzulás BSD licenc) (szövege: https://opensource.org/license/bsd-3clause) egy újabb változata az eredeti BSD licencnek, amely mindössze három záradékból áll A fő jellemző, ami megkülönbözteti ezt a licencet nővérétől, a 2 klauzulás BSD licenctől, a “nonendorsement clause”, amelynek célja, hogy megakadályozza az eredeti szerző nevének felhasználását a származékos művek terjesztésére vagy eladására. A 3 klauzulás BSD licenc biztosítja az engedélyes számára a következő jogokat: • A szoftver használata, módosítása és terjesztése • A szoftver kereskedelmi forgalomba hozatala, módosításokkal vagy anélkül • Származékos munkák kiadása más licenc alatt, akár

zárt forráskódú szoftverként is Az engedélyes köteles: • Hozzáadni a szerzői jogi közleményt és a licenc szövegét a szoftver vagy az abból származékos munkák forráskódjához és bináris változatához • Hozzáadni a szerzői jogi közleményt és a licenc szövegét a szoftverrel együtt szállított dokumentációjához vagy egyéb anyagokhoz • Tartózkodni a szerzői jogtulajdonos vagy a közreműködők nevének feltüntetésétől a szoftverből származó termékek támogatása vagy népszerűsítése céljából, külön előzetes 94 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek írásbeli engedély nélkül Az utóbbi kötelezettség a “non-endorsement clause” (nem-jóváhagyási záradék) értelmezéséhez képzeljünk el egy olyan forgatókönyvet, amelyben egy vállalat vagy magánszemély egy szabad szoftverlicenc alapján

engedélyezett szoftverből kiindulva készít egy származékos munkát. E záradék hiányában az engedélyes azzal népszeűsíthetné az új terméket, hogy jelzi, hogy az egy ismert fejlesztő szoftveréből származik, így profitálva annak presztízséből. A testvér licencéhez hasonlóan a 3 klauzulás BSD licenc is kompatibilisnek tekinthető az összes legfontosabb copyleft licenccel, legyen az weak vagy strong. A 3 klauzulás BSD licenc különösen kompatibilis a következőkkel: • GNU General Public License (GPL), 2.0 és 30 verzió • GNU Lesser General Public License (LGPL), 2 és 3 verzió • Mozilla Public License (MPL) Ezért az eredetileg a 3 klauzulás BSD licenc alatt licencelt szoftverek származékos munkái a fent említett licencek valamelyike alatt is terjeszthetők, vagy beépíthetők a fent említett licencek valamelyike alatt kiadott projektekbe. Apache 2.0 licenc Az első Apache licencet az Apache Software Foundation, egy 1999-ben alapított

nonprofit szervezet fejlesztette ki, hogy szoftvereit terjeszteni tudja, valamint más projektekbe könnyen beépíthetővé tegye. A küldetés az volt, hogy üzletbarát szemlélettel karöltve garantálja a kollaboratív szoftverfejlesztést, a nyílt forráskódú filozófiát. Az Apache 2.0 licenc (szövege: https://wwwapacheorg/licenses/LICENSE-20), amely valószínűleg a legelterjedtebb a permisszív szoftverlicencek között, néhány lényeges szempontban eltér a korábban tárgyalt licencektől. A fő szempont a szabadalmi jogok minden egyes engedélyesnek való tulajdonítását érinti, beleértve a szabadalmi licenc megszüntetésére vonatkozó záradékot; ezzel korlátozva és megakadályozva a szabadalombitorlás miatti kártérítési igényeket. Van két másik fontos kötelezettség is. Az engedélyesnek ugyanezen Apache 20 licenc alatt kell kiadnia a szoftver minden olyan részét vagy komponensét, amelyet az engedélyes nem módosított. Továbbá az

engedélyesnek minden módosított fájlban feltűnő módon kell elhelyeznie egy közleményt, amely jelzi, hogy az engedélyes módosította az adott fájlokat. A korlátozó licenceket népszerűsítő Free Software Foundation az Apache 2.0-t ajánlja a legjobbként a permisszív szoftverlicencek közül kis mennyiségű szoftver, valamint könyvtárak terjesztésére. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 95 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Az Apache 2.0 licenc biztosítja az engedélyes számára: • A szoftver használatának, módosításának és terjesztésének jogát • A szoftver kereskedelmi forgalomba hozatalának jogát, módosításokkal vagy azok nélkül • A származékos munkák más licenc alatt történő kiadásának jogát, akár zárt forráskódú szoftverként is • A szabadalmi licencet a szabadalom által lefedett szoftver használatára,

értékesítésére, importálására és egyéb módon történő átruházására • A szabadalmi licencet a szoftver használatára, értékesítésére, importálására és egyéb módon történő átruházására, amely egyébként sértheti a közreműködő szabadalmi igényét. Az engedélyes köteles: • Szembetűnő értesítéseket helyezni minden módosított fájlba, amelyek jelzik, hogy a fájlok módosításra kerültek • Az eredeti szoftver minden változatlan részét az Apache 2.0 licenc alatt kiadni • Feltüntetni a szerzői jogi közleményt és a licenc szövegét a szoftver és a származékos munkák forráskódjában is • Feltüntetni a szerzői jogi közleményt és a licenc szövegét a dokumentációban és más, a szoftverhez mellékelt anyagokban The Apache 2.0 license is considered to be compatible with only some of the most important copyleft licenses. In particular, the Apache 20 license is compatible with: • GNU General Public License (GPL),

3.0 verzió, de a 20-val nem • GNU Lesser General Public License (LGPL), 3.0 verzió, de a 20-val nem • Mozilla Public License (MPL), 2.0 verzió, de az 11-el nem Ez azt jelenti, hogy az eredetileg az Apache 2.0 licenc alatt licencelt szoftverek származékos munkái a fent említett kompatibilis licencek valamelyike alatt továbbterjeszthetők, vagy beépíthetők a fent említett kompatibilis licencek valamelyike alatt kiadott projektekbe. Az Apache 2.0 licenc és más nyílt forráskódú licencek közötti korlátozott kompatibilitás elsősorban a szabadalmi licencnek az engedélyes részére történő megadására vonatkozó záradékok jelenlétének köszönhető. 96 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek Permisszív szoftverlicencek és más nyílt forráskódú licencek viszonya Most, hogy áttekintést kaptunk a megengedő szoftverlicencek közös és

alapvető jellemzőiről, megvizsgálhatjuk, hogy miben különböznek a szabad felhasználású szoftverektől és a copyleft licencektől. Összehasonlítás a Public Domain szoftverekkel Az első különbség a permisszív szoftverlicencek és a köztulajdonban lévő szoftverek kiadása között a puszta létezésükben rejlik. A közkincs (public domain) nem egy tényleges licenc, hanem csak egy módja a szoftverek kiadásának. Más szóval, a definíció szerint a köztulajdonban lévő munkák nem rendelkeznek licenccel. A következő különbség a permisszív licencek által az engedélyesre rótt kötelezettségekben rejlik. Valójában a köztulajdonban lévő kiadvány felhasználóját semmilyen kötelezettség nem terheli. Azonban bárki, aki egy szoftver felhasználása, módosítása vagy továbbterjesztése során a szabad felhasználású szoftverlicenc alapján jár el, köteles eleget tenni a korábban kifejtett attribúciós kötelezettségnek: az eredeti szerző

nevének és a licenc szövegének másolatát a fel kell tüntetnie a szoftverben. Az attribúciós kötelezettség következménye az, hogy egy permisszív szoftverlicenc alá tartozó szoftverből származékos munka nem adható ki közkincsként, mivel ez sértené (vagy legalábbis megkerülné) az eredeti szerző attribúcióhoz való jogát. Összehasonlítás a copylefttel A permisszív szoftverlicencek és a korlátozó, copyleft licencek közötti különbségtétel összetettebb, különösen a különböző copyleft licencek közötti különbségeket figyelembe véve. Amint azt az előző leckékben láttuk, az egyik fő különbség a strong copyleft licencek (beleértve a GNU General Public License (GPL) 2.0 és 30 verzióját) elválasztása a weak copyleft licencektől (beleértve a GNU Lesser General Public License (LGPL) 2.0 és 30 verzióját, valamint a Mozilla Public License-t) A korlátozó és a permisszív licencek közötti fő különbség a copyleft

elvében rejlik, amely a korlátozó licencek központi eleme. Ennek az elvnek megfelelően az engedélyes, aki a szoftvert copyleft licenc alapján módosítja, majd terjeszti, szükségszerűen részben vagy egészben ugyanolyan licenccel kell kiadnia a származékos munkát, mint az eredeti szoftvert. E kötelezettség elmulasztása a szerzői jog megsértését eredményezi, ami jogi következményekkel jár. Ezzel szemben a megengedő szoftverlicencek nem írnak elő ilyen kötelezettséget. Azok, akik ilyen Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 97 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek típusú licencek alatt használnak vagy terveznek szoftvereket kiadni, szabadon dönthetnek a származékos munkájuk licencéről, beleértve a szabadalmi licenceket is. Strong Copyleft A megengedő szoftverlicencek és a strong copyleft licencek közötti különbség sokkal markánsabb, mint a

weak copyleft licencek esetében. A lényeges különbség az, hogy a strong copyleft licencek megkövetelik, hogy a származékos műveket ugyanazon licenc alatt adják ki, mint az eredeti szoftvert. Ez akkor is érvényes, ha a copyleft-licenc alatt álló szoftvert egy másik projektbe integrálják: a teljes származékos munkát ugyanazon strong copyleft licenc alatt kell kiadni. Weak Copyleft A strong copyleft licencekkel ellentétben a weak licencek csak részben írják elő, hogy a származékos munkát ugyanezen licenc alatt kell kiadni. Pontosabban, a weak copyleft licenc alatt kiadott szoftvert továbbterjesztő engedélyesnek ugyanezt a licencet kell alkalmaznia a munkájának az eredeti licencből származó részre. Például egy LGPL alatt licencelt könyvtáron alapuló könyvtárat szintén az LGPL alatt kell licencelni. A gyenge copyleft-licenceket pontosan azért találták ki, hogy jellemzőiket közelebb hozzák a megengedő szoftverlicencek jellemzőihez.

Mindazonáltal abban különböznek a megengedő szoftverlicencektől, hogy az utóbbiak semmilyen körülmények között nem írják elő azt a kötelezettséget, hogy a származékos vagy integrált munkákra is ugyanazt a licencet kell fenntartani. 98 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek Gyakorló feladatok 1. Milyen két kötelezettséget írnak elő általában a permisszív szoftverlicencek? 2. Az alábbi licencek közül melyik nem permisszív szoftverlicenc? Apache 2.0 licenc LGPL licenc MIT/X11 licenc 3-Clause BSD 3. Mi különbözteti meg a permisszív szoftverlicencet a copyleft licenctől? A copyleft licenc alatt kiadott szoftverek nem terjeszthetők, míg a permisszív szoftverlicenc alatt kiadott szoftverek igen. A copyleft licenc alatt álló szoftverekből származó munkák nem adhatók ki védett licenc alatt, míg a permisszív licenc alatt

álló szoftverek igen. A copyleft licenceket csak az Amerikai Egyesült Államokban ismerik el jogilag, míg a permisszív szoftverlicencek világszerte elismertek. 4. Melyik megengedő szoftverlicenc ad szabadalmi engedélyt a szabadalom által lefedett szoftver használatára, értékesítésére, importálására és egyéb módon történő átruházására? Apache 2.0 licenc 2-Clause BSD licenc MIT/X11 licenc 3-Clause BSD licenc 5. Ha egy szoftver az MIT/X11 licenc alatt kerül kiadásra, terjeszthetjük-e azt saját licenc alatt, és értékesíthetjük-e a szoftveren alapuló származékos munkát? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 99 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Gondolkodtató feladatok 1. Módosítjuk az Apache 20 licenc alatt terjesztett szoftvert, és a származékos munkát saját licenc alatt terjesztjük tovább. Milyen lépéseket kell tennünk, hogy

megfeleljünk az Apache 20 licenc kötelezettségeinek? 2. Nevezzünk meg legalább három példát népszerű, megengedő szoftverlicencek alatt kiadott projektekre! 3. Why can’t you distribute, under a LGPL 20 license, software that includes components that were originally released under the MIT/X11 license, the Apache 2.0 license, and the 2-Clause BSD license? What different weak copyleft license can be used to release the software? 100 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek Összefoglalás Ebben a leckében megtanultuk: * Mik azok a permisszív szoftverlicencek és mik az általuk biztosított jogok és az általuk előírt kötelezettségek * A permisszív szoftverlicencek és más nyílt forráskódú licencek közötti különbségeket * A legnépszerűbb permisszív szoftverlicencek jellemzőit * A permisszív szoftverlicencek kompatibilitását más nyílt

forráskódú licencekkel Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 101 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Válaszok a gyakorló feladatokra 1. Milyen két kötelezettséget írnak elő általában a permisszív szoftverlicencek? Kötelezettség a szoftver eredeti szerzőjének nevének feltüntetésére és a licenc szövegének másolatának csatolására a származékos munkához. 2. Az alábbi licencek közül melyik nem permisszív szoftverlicenc? Apache 2.0 licenc LGPL licenc X MIT/X11 licenc 3-Clause BSD 3. Mi különbözteti meg a permisszív szoftverlicencet a copyleft licenctől? A copyleft licenc alatt kiadott szoftverek nem terjeszthetők, míg a permisszív szoftverlicenc alatt kiadott szoftverek igen. A copyleft licenc alatt álló szoftverekből származó munkák nem adhatók ki védett licenc alatt, míg a permisszív licenc alatt álló szoftverek igen. X A

copyleft licenceket csak az Amerikai Egyesült Államokban ismerik el jogilag, míg a permisszív szoftverlicencek világszerte elismertek. 4. Melyik megengedő szoftverlicenc ad szabadalmi engedélyt a szabadalom által lefedett szoftver használatára, értékesítésére, importálására és egyéb módon történő átruházására? Apache 2.0 licenc X 2-Clause BSD licenc MIT/X11 licenc 3-Clause BSD licenc 5. Ha egy szoftver az MIT/X11 licenc alatt kerül kiadásra, terjeszthetjük-e azt saját licenc alatt, és értékesíthetjük-e a szoftveren alapuló származékos munkát? 102 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0523 Megengedő szoftverlicencek Igen. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 103 Open Source Essentials (Version 1.0) | Témakör 052: Nyílt forráskódú szoftverlicencek Válaszok a gondolkodtató feladatokra 1. Módosítjuk az

Apache 20 licenc alatt terjesztett szoftvert, és a származékos munkát saját licenc alatt terjesztjük tovább. Milyen lépéseket kell tennünk, hogy megfeleljünk az Apache 20 licenc kötelezettségeinek? Az alábbiakat: ◦ Minden egyes módosított fájlba be kell illeszteni egy értesítést, amely igazolja, hogy a fájlokat módosították ◦ Az eredeti szoftver minden, változtatás nélküli részét az Apache 2.0 licenc alatt kell kiadni ◦ A szerzői jogi közleményt és a licenc szövegét be kell építeni a szoftver vagy a származékos munkák forráskódjába ◦ A szerzői jogi közleményt és a licenc szövegét fel kell tüntetni a dokumentációban és az egyéb, a szoftver terjesztéséhez mellékelt anyagokban 2. Nevezzünk meg legalább három példát népszerű, megengedő szoftverlicencek alatt kiadott projektekre! ◦ Angular web framework MIT/X11 licenc ◦ Ruby on Rails MIT/X11 licenc ◦ Apache HTTP Server Apache 2.0 licenc ◦ Kubernetes Apache

2.0 licenc 3. Why can’t you distribute, under a LGPL 20 license, software that includes components that were originally released under the MIT/X11 license, the Apache 2.0 license, and the 2-Clause BSD license? What different weak copyleft license can be used to release the software? Even though the MIT/X11 license and 2-Clause BSD license are compatible with the LGPL 2.0 license, the Apache 2.0 license is not Software that includes components released under MIT/X11 license, Apache 2.0 license, and 2-Clause BSD license can be released under LGPL 30 license, because it is compatible with all those permissive software licenses. 104 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 105 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek 053.1 A nyílt tartalmi

licencek koncepciója Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0531 Súlyozás 2 Kulcsfontosságú ismeretek • A nyílt tartalom típusainak megértése • Annak megértése, hogy mi minősül szerzői jogi védelem alá eső tartalomnak • A szerzői jogi védelem alatt álló anyagok származékos műveinek megértése • A nyílt tartalmi licencek szükségességének megértése • A védjegyek ismerete A használt fájlok, kifejezések és segédprogramok listája • Dokumentáció • Képek • Művészeti alkotás • Térképek • Zene • Videók • Hardvertervek és specifikációk • Adatbázisok • Adat streamek 106 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0531 A nyílt tartalmi licencek koncepciója • Adat feedek Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 107 Open Source Essentials

(Version 1.0) | Témakör 053: Nyílt tartalmi licencek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 053 Nyílt tartalmi licencek Fejezet: 053.1 A nyílt tartalmi licencek koncepciója Lecke: 1/1 Bevezetés Gondoljunk bele az alábbi a hipotetikus helyzetbe: Frank egy író, aki bizonyos feltételek mellett bárki számára elérhetővé akarja tenni néhány történetét az interneten. Azt szeretné, ha a művei ingyenesen hozzáférhetőek lennének. Azt szeretné, ha bárki engedélykérés nélkül felhasználhatná a történeteket, de nem szeretné, ha a munkáját kereskedelmi célokra használnák fel. Végül pedig azt is szeretné, hogy az emberek megfelelően hivatkozzanak rá, ha a történeteket bármilyen célra felhasználnák. Ezt anélkül szeretné megtenni, hogy bonyolult jogi eljárásokba keveredne. Később azt is látni fogjuk, hogy egy író miért akarja ezeket a dolgokat Emma filmkészítő, aki néhány diákot

rövidfilmek készítésére tanít. A diákoknak többek között szükségük van egy történetre, hogy elkészíthessék alkotásaikat. Emma ismeri Frank történeteit, és úgy gondolja, hogy azok tökéletesen megfelelnek az osztályának. Mit tehet Frank, hogy Emma felhasználhassa a történeteit? Ez és még sok más helyzet megoldható egy nyílt tartalom licencelési modell alkalmazásával. Napjainkban szerzői jogi védelem alatt álló művek milliói használhatók fel újra bárki számára a szerzői jogtulajdonos kifejezett hozzájárulása vagy licencdíj fizetése nélkül, köszönhetően a nyílt tartalomú licencek alapján történő terjesztésüknek. Az olyan források, mint a Wikipedia, a Flickr, az OpenStreetMap, az Unsplash és a 108 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0531 A nyílt tartalmi licencek koncepciója Jamendo csak néhány példa az ilyen licencmodellt

használó számos platform közül. Egy nagyon tág meghatározás szerint a nyílt tartalom minden olyan művet jelent (beleértve például a filmeket, zenéket, képeket, szövegeket, adatbázisokat, adatállományokat, dokumentációt, térképeket és hardverterveket), amelynek szabad felhasználása és terjesztése a szerzői jog alapján megengedett. Ide tartoznak azok az eredetileg védett művek is, amelyek védelmi ideje lejárt, ezért pedig közkinccsé váltak. Egy némileg szűkebb meghatározás feltételezi, hogy a művet a szerzője kifejezetten nyílt tartalmi licenc alá helyezte, amely lehetővé teszi a mű használatát és terjesztését mindenféle fizetés vagy engedély nélkül. A nyílt tartalom modellje tehát nem ellentétes a szerzői joggal, hanem kiegészíti azt. A szerzői jog alapjai Mivel a nyílt tartalmi licencek a szerzői jogon (copyright) alapulnak, meg kell ismernünk a szerzői jog néhány aspektusát ahhoz, hogy megértsük, miért van

szükség a licencekre és azok mit tesznek lehetővé. A szerzői jog a szellemi tulajdon (intellectual property) néven ismert jogi kategória része. A szerzői jog az eredeti műveket védi azáltal, hogy az alkotóknak kizárólagos jogokat biztosít a műveik más személyek és vállalatok általi bizonyos felhasználásának ellenőrzésére. Általában ez azt jelenti, hogy a szerzői jog jogosultjának engedélye nélkül a művet senki más nem másolhatja, nem terjesztheti, nem adhatja elő nyilvánosan, nem adaptálhatja, és a mű megtekintésén vagy olvasásán kívül szinte semmi mást nem tehet. Az ebben a szakaszban megvizsgálandó alapelvek közé tartozik, hogy mi a szerzői jog, valamint az, hogy ki ellenőrzi a jogokat, és ki adhat engedélyt a szerzői joggal védett művek újrafelhasználására, ahogyan azt Emma a példánkban szeretné tenni. Ahogyan azt a Szellemi Tulajdon Világszervezete (World Intellectual Property Organization) kifejezetten kimondta:

Copyright protects two types of rights. Economic rights allow right owners to derive financial reward from the use of their works by others. Moral rights allow authors and creators to take certain actions to preserve and protect their link with their work. The author or creator may be the owner of the economic rights or those rights may be transferred to one or more copyright owners. Many countries do not allow the transfer of moral rights Copyright only protects the expression of facts or ideas. It does not allow the copyright holder to own or control the idea exclusively. For example, an illustration can be copyrighted but not the idea that originated it. (A szerzői jog kétféle jogot véd A gazdasági jogok lehetővé teszik a jogtulajdonosok számára, hogy műveik mások általi felhasználásából anyagi haszonra tegyenek szert. Az erkölcsi jogok lehetővé teszik a szerzők és alkotók számára, hogy bizonyos Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve |

learning.lpiorg | 109 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek lépéseket tegyenek a művükhöz fűződő kapcsolatuk megőrzése és védelme érdekében. A szerző vagy alkotó lehet a gazdasági jogok tulajdonosa, vagy e jogok átruházhatók egy vagy több szerzői jogtulajdonosra. Sok ország nem teszi lehetővé az erkölcsi jogok átruházását A szerzői jog csak a tények vagy eszmék kifejezését védi. Nem teszi lehetővé, hogy a szerzői jog jogosultja kizárólagosan birtokolja vagy ellenőrizze az ötletet. Például egy illusztráció szerzői jogi védelemben részesülhet, de az azt létrehozó ötlet nem.) World Intellectual Property Organisation, Understanding Copyright and Related Rights A szerzői jog által védett gazdasági jogok hosszú ideig, általában évtizedekkel az alkotó halála után is fennállnak. Az erkölcsi jogok soha nem évülnek el A szerzői jog olyan kreatív alkotásokhoz, például

irodalmi és művészeti alkotásokhoz biztosít jogokat, amelyeknek meg kell felelniük az eredetiség bizonyos követelményeinek. A műnek az alkotó alkotásának kell lennie, és nem másolhatja más műből. (Folyamatos viták folynak arról, hogy mennyi mesterséges intelligencia kerülhet egy műbe, hogy még mindig eredeti műnek legyen tekinthető.) A szerzői jog csak a tények vagy eszmék kifejezését védi. Nem teszi lehetővé, hogy a szerzői jog jogosultja kizárólagosan birtokolja vagy ellenőrizze az ötletet. Például egy illusztráció szerzői jogi védelemben részesülhet, de az azt létrehozó ötlet nem. A szerzői jog automatikusan keletkezik, amikor egy művet (például egy digitális műalkotást vagy egy dalt) létrehoznak és valamilyen kézzelfogható formában rögzítenek. Ez azt jelenti, hogy a jogokat az alkotó anélkül kapja meg, hogy a művet hivatalosan be kellene jegyeztetni. Azok, akik a nyílt tartalom licencelését támogatják, a

szabad kultúrát és a digitális közkincs kialakulását akarják elősegíteni. A szerzői jogi rendszert túlságosan korlátozónak és merevnek találták mind a felhasználók, mind az alkotók számára. A nyílt tartalom védelmezői a könnyen használható szabványos licencek létrehozásával egyszerűsítik a szerzői jog által védett művek használatát és terjesztését. Mit lehet szerzői joggal védeni? A szerzői jogi törvények országonként eltérőek, vannak azonban nemzetközi megállapodások a szerzői jogi törvények egységesítésére. Az eredeti irodalmi és művészeti alkotások szerzői jogi védelemben részesülhetnek: például a művészeti, zenei, fényképészeti, filmes, televíziós, irodalmi és programozási alkotások. Az annak eldöntésére vonatkozó konkrét szabályok, hogy mi védhető szerzői joggal, és hogy egy mű mennyire eredeti, régiónként eltérőek. Néha ezek a kategóriák nagyon általánosak lehetnek, és olyan

művekre is vonatkoznak, amelyek alkotói és szigorúan funkcionális elemeket egyaránt tartalmaznak: például egy rövidfilm művészi 110 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0531 A nyílt tartalmi licencek koncepciója alkotásnak minősül. Ennek egyes részei azonban nélkülözhetik a szerzői jogi védelmet, ha nem felelnek meg az eredetiség követelményének. Származékos művek Folytassuk a lecke elején leírt elképzelt szituációval: Frank végül úgy döntött, hogy történeteit nyílt tartalmi licenc alatt teszi közzé, így azok az általa választott feltételek szerint használhatók. Mivel a történetek ilyen licenc alá kerültek, Emma felhasználta őket az osztályában, és úgy döntött, hogy egy filmfesztiválon bemutatja néhány diákja rövidfilmjét. Ebben az esetben a diákok által létrehozott tartalom származékos műnek tekinthető. A származékos mű

vagy adaptáció olyan mű, amely már létező műveken alapul, például fordítás, zenei feldolgozás, dramatizálás, fikcionalizálás, mozgóképes változat, hangfelvétel, művészi reprodukció vagy bármely más olyan forma, amelyben az eredeti művet átalakítják vagy adaptálják. A származékos mű egy második, különálló, az elsőtől formailag független művé válik A mű átalakításának, módosításának vagy átdolgozásának jelentősnek kell lennie ahhoz, hogy eredeti és így szerzői jogi védelem alatt álló műnek minősüljön. A nyílt tartalmi licencek általános jellemzői Minden nyílt tartalmi licenc megerősíti a szerző szerzői jogait, és megállapítja, hogy a szerző engedélye nélkül a művet használó bármely személy megsérti ezeket a jogokat. Ezért az ilyen licencek a globális szerzői jogi rendszeren belül működnek, ahelyett, hogy megpróbálnák azt felborítani. A nyílt tartalmi licencek azt is biztosítják, hogy a

mű szerzőjének megfelelő forrásmegjelölést meg kell adni. Ha a mű befogadói a művet harmadik félnek továbbítják, gondoskodniuk kell arról, hogy az eredeti szerzőt elismerjék és megemlítsék. Továbbá, ha módosítják a művet, a származékos műben egyértelműen meg kell említeni az eredeti szerzőt, és meg kell említeni, hogy az eredeti mű hol található meg. A legtöbb szerzői jogi licenccel ellentétben, amelyek korlátozó feltételeket szabnak a mű felhasználására, a nyílt tartalmi licencek bizonyos szabadságokat biztosítanak a felhasználóknak azáltal, hogy jogokat garantálnak számukra. E jogok némelyike gyakorlatilag minden nyílt tartalomra vonatkozó licencben közös, ilyen például a mű másolásának és terjesztésének joga. A licenctől függően a felhasználónak joga lehet továbbá a mű módosítására, származékos művek létrehozására, a mű előadására, a mű bemutatására és a származékos művek

terjesztésére. A nyílt tartalmi licencek szabályozhatják a származékos műveket. Ezek a licencek általában tartalmazzák a jogot a származékos művek létrehozására és bármilyen médiában történő terjesztésére. Ha valaki egy festményt nyílt tartalmi licenc alapján licencel, akkor az a jog is Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 111 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek megadható, hogy egy másik képet alapozzon rá. Ezeket az engedélyeket azzal a feltétellel adják meg, hogy a származékos művet, akárcsak az eredetit, mások szabadon használhatják. Ezért a nyílt tartalmi licenc általában biztosítja, hogy a származékos műveket ugyanazon nyílt tartalmi licenc feltételei szerint licencelik. Ez a kötelezettség azonban nem alkalmazandó, ha a mű egy összeállításban szerepel. Ha például valaki egy dalokból álló albumot készít, amelyek közül az

egyik nyílt tartalmi licenc alatt jelenik meg, nem kell az összes dalt ugyanazon feltételek szerint licencelni. A nyílt tartalmi licencek másik fontos szempontja a mű kereskedelmi felhasználásának ellenőrzése. Az emberek nyílt tartalmi licenc alatt licencelhetik műveiket, miközben a jogokat nem kereskedelmi célokra korlátozhatják. Alternatíva lehet az is, hogy az emberek minden jogot megadhatnak, beleértve a mű kereskedelmi célú felhasználásának jogát is. A nyílt tartalmi licencek nem akadályozzák meg az embereket abban, hogy pénzt keressenek a munkájukkal. Ha egy mű nem kereskedelmi licenc alatt áll, egy kiadó vagy más kereskedelmi szervezet közzéteheti a művet, ha előtte megállapodást köt a szerzői jogtulajdonosokkal. Más szóval, a szerzők még a mű nem kereskedelmi alapon történő kiadása után is eladhatják a szerzői jogokat egy nyereségérdekelt szervezetnek, feltéve, hogy a folyamatos, nem kereskedelmi célú felhasználást

nem zárják ki. A nyílt tartalmi licencek jelentősége Milyen előnyei vannak a nyílt tartalom modellnek, és miért használnának az emberek nyílt tartalmi licencet kreatív munkáik terjesztésére, ahelyett, hogy a hagyományos szerzői jogi modellre hagyatkoznának? A nyílt tartalomlicencek lehetővé teszik a művek szélesebb körben való terjedését, mintha alapértelmezés szerint korlátoznák őket. Ezért az új művészek is profitálhatnak ezekből az engedélyekből, mivel népszerűbbé és elismertebbé válhatnak. Bizonyos ellenőrzések (és esetleg az ezekkel együtt járó bevételek) feladásával a tartalomkészítők több műsorba hívhatók meg, több szponzort kaphatnak, több együttműködést köthetnek stb. A nyílt tartalmi licencek praktikusak lehetnek az internet korában, mivel az alkotók anélkül tehetik közzé műveiket, hogy egy másik személyre vagy intézményre támaszkodnának. Például egy fotós, aki ki akarja állítani a

képeit, közzéteheti azokat személyes weboldalán. Így anélkül is megalapozhatják magukat, és szélesebb közönség előtt is ismertté válhatnak, hogy ehhez egy ügynökséghez vagy galériához kellene szerződniük. A megfelelő licenc kiválasztásával a jogtulajdonosok maximalizálhatják a terjesztést, és megtarthatják a műveik kereskedelmi forgalomba hozatala feletti ellenőrzést. Ha az emberek 112 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0531 A nyílt tartalmi licencek koncepciója kereskedelmi céllal kívánják felhasználni a művet, a tartalom létrehozója megőrizheti a jogot, hogy engedélyt adjon vagy megtagadjon. Még ha másoknak meg is tiltják a kereskedelmi felhasználást, a jogtulajdonosok akkor is felhasználhatják művüket kereskedelmi célokra. A nyílt tartalmi licencek a mű sokkal szélesebb körű terjesztésének lehetősége mellett a felhasználók

jogbiztonságát is növelik, és jelentősen csökkentik a jogi tranzakciós költségeket. Az emberek olyan finanszírozási modelleket is használhatnak, amelyek nem függnek a nem kereskedelmi licenc használatától. Sok művész és alkotó például crowdfundingot használ a művének finanszírozására, mielőtt azt szabad felhasználású licenc alapján kiadná. Mások olyan modellt használnak, ahol az alaptartalom ingyenes, de az olyan extrák, mint a nyomtatott változat vagy a csak tagoknak szóló weboldalhoz való különleges hozzáférés csak a fizető ügyfeleknek jár. A nyílt tartalmi licencek lehetővé teszik, hogy az emberek korlátozások nélkül terjeszthessék műveiket bárki számára, bármilyen adathordozón és formátumban, például weboldalakon, fénymásolatokon, CD-ken vagy könyvekben. A nyílt tartalmi licencek automatikusan licencet hoznak létre a szerzők és a felhasználók között. nyílt tartalmi licenc nélkül a művek más online

forráson keresztül történő megosztásához egyedi szerződéses megállapodásra lenne szükség a szerzők és a felhasználók között. Védjegyek és szerzői jogok A védjegy (trademark) a szerzői joghoz hasonlóan a szellemi tulajdon egyik fajtája. A védjegyet védő törvény azonban eltér a szerzői jogot védő törvénytől. A védjegyek a márkákat, a kapcsolódó szavakat, például a márkaneveket, a logókat, a szimbólumokat, sőt még a hangokat és a színeket is védik, amelyeket arra használnak, hogy megkülönböztessenek bizonyos árukat és szolgáltatásokat másoktól. Bármilyen különleges elem, amelyet a vállalkozások és az értékesített szolgáltatások vagy termékek népszerűsítésére és másoktól való megkülönböztetésére használnak, védjegy lehet. A védjegyjogosult általában megakadályozhatja, hogy ezeket a védjegyoltalom alatt álló termékeket mások is használhasság, ha az emberek összetéveszthetik őket. A

védjegyjog segít az áruk és szolgáltatások előállítóinak hírnevük védelmében, és védi a nyilvánosságot azáltal, hogy egyszerű lehetőséget biztosít a hasonló termékek és szolgáltatások megkülönböztetésére. A védjegyeket hivatalosan be lehet jegyeztetni, vagy a szokásjog alapján automatikusan oltalomban részesülhetnek. Ez azt jelenti, hogy a védjegy létezik, amint használják, de a szokásjog szerinti védjegy nem nyújt ugyanolyan jogi védelmet, mint a bejegyzett védjegy. Ezért sok vállalat bejegyezteti védjegyét. A szerzői jog és a védjegyek egymás mellett létezhetnek. A Wikipedia például bejegyzett védjegy, és logója eredeti műalkotásként vagy alkotásként szerzői jogi védelem alatt áll. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 113 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Gyakorló feladatok 1. Használhatók-e a nyílt tartalmi licencek a

szerzői jogok megkerülésére? 2. Mi számít nyílt tartalomnak? 3. Mi az a származékos mű? 114 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0531 A nyílt tartalmi licencek koncepciója Gondolkodtató feladatok 1. Mit tennénk, ha ki akarnánk adni egy művet, és megengednénk az embereknek, hogy bármilyen célra felhasználják, amíg a művet ugyanazon jogok és feltételek mellett terjesztik tovább? 2. Terjeszthetünk-e nyílt tartalmi licenc alatt közzétett műveken alapuló kereskedelmi célú származékos műveket? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 115 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Összefoglalás Ebben a leckében megtanultuk: • A szerzői jog alapjait • Mi tekinthető szerzői jogi védelem alatt álló tartalomnak • Mi a származékos mű vagy adaptáció • A nyílt tartalmi

licencek általános jellemzőit • A nyílt tartalom típusait • A nyílt tartalom licencelési modell fontosságát és előnyeit • A szerzői jogot és a védjegyeket, mint szellemi tulajdon típusokat 116 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0531 A nyílt tartalmi licencek koncepciója Válaszok a gyakorló feladatokra 1. Használhatók-e a nyílt tartalmi licencek a szerzői jogok megkerülésére? A nyílt tartalmi licencek nem használhatók fel a szerzői jogok megkerülésére. A nyílt tartalmi licencek a szerzői jogi licencek egy olyan típusa, amely bizonyos feltételek mellett bizonyos jogokat biztosít, ugyanakkor fenntartja a szerzői jogtulajdonos kizárólagos jogait. 2. Mi számít nyílt tartalomnak? Nyílt tartalom lehet bármely szerzői joggal védett mű, amelyet nyílt tartalmi licenc alapján tesznek közzé. Ilyen tartalom lehet film, zene, kép, szöveg, adatbázis,

dokumentáció, térkép, hardverterv és egyéb alkotás. Az ilyen típusú licencek olyan jogokat biztosítanak, mint a felhasználás, a továbbterjesztés, a származékos művek készítése, valamint a kereskedelmi vagy nem kereskedelmi célú felhasználás, külön engedély nélkül. 3. Mi az a származékos mű? A származékos mű, más néven adaptáció, olyan mű, amely egy meglévő művön alapul, és amelyben az eredeti művet átalakítják vagy adaptálják. Példák a származékos művekre a fordítások, zenei feldolgozások, dramatizálások, filmváltozatok, hangfelvételek és művészeti reprodukciók. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 117 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Válaszok a gondolkodtató feladatokra 1. Mit tennénk, ha ki akarnánk adni egy művet, és megengednénk az embereknek, hogy bármilyen célra felhasználják, amíg a művet ugyanazon jogok

és feltételek mellett terjesztik tovább? A művet copyleft típusú licenc alatt is elérhetővé tehetjük. Ilyen módon az eredetiből származó összes műnek is nyíltnak kell lennie, ami megköveteli, hogy ugyanazon vagy bármely más kompatibilis licenc alatt tegyék közzé őket. 2. Terjeszthetünk-e nyílt tartalmi licenc alatt közzétett műveken alapuló kereskedelmi célú származékos műveket? Ez attól függ, hogy az eredeti mű milyen licenc alatt érhető el. Ha a licenc kimondja, hogy a származékos műveket bármilyen célra, akár kereskedelmi célokra is felhasználhatjuk, akkor igen. 118 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek 053.2 Creative Commons licencek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0532 Súlyozás 2 Kulcsfontosságú ismeretek • A Creative Commons licencek koncepciójának

megértése • A Creative Commons licenctípusok és kombinációik megértése • A Creative Commons licencek által biztosított jogok megértése • A Creative Commons licencek által létrehozott kötelezettségek megértése A használt fájlok, kifejezések és segédprogramok listája • Public Domain Dedication (CC0) • Creative Commons Attribution (CC BY) • Creative Commons Attribution-ShareAlike (CC BY-SA) • Creative Commons Attribution-NonCommercial (CC BY-NC) • Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA) • Creative Commons Attribution-NoDerivatives (CC BY-ND) • Creative Commons Attribution-NonCommercial-NoDerivatives (CC BY-NC-ND) Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 119 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 053 Nyílt tartalmi licencek Fejezet: 053.2 A Creative Commons

licencek Lecke: 1/1 Bevezetés A szabad szoftverek 1990-es évek óta tartó sikere és az internet egyidejű diadalmenete más ágazatokban is felébresztette az igényt arra, hogy hasonló feltételek mellett támogassák a kreatív alkotások azaz az alapvetően szerzői jog hatálya alá tartozó alkotások fejlesztését és terjesztését. Ezek a vágyak különböző érdekeket tükröznek Az alkotóművészek maguk akarják meghatározni, hogy műveiket milyen feltételek mellett használhatják fel mások. Ugyanakkor azonban abban is érdekeltek, hogy mások munkáját saját céljaikra használhassák fel, ahogyan azt az alkotói folyamatok mindig is tették, például idézéssel, szerkesztéssel vagy adaptálással. A művek befogadóiban felmerülhetnek a felhasználás lehetőségeivel kapcsolatban kérdések, például, hogy egy művet lehet-e és milyen formában sokszorosítani vagy továbbadni. Az ilyen gyakorlati kérdések tisztázásán túlmenően a

szabályozást úgy kell megalkotni, hogy az összhangban legyen az alkalmazandó jogi normákkal elsősorban a szerzői joggal --, amit megnehezítenek a szerzői jog nemzetközi szabályozásának eltérő módjai. Végül, de nem utolsósorban a szabályoknak könnyen érthetőnek és egyszerűen alkalmazhatónak 120 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek kell lenniük, hogy felgyorsítsák a kreatív folyamatokat, és jogbiztonságot nyújtsanak az alkotóknak és a befogadóknak. A Creative Commons eredete és céljai A szabad szoftverek területén a korai licencek, mindenekelőtt a GNU General Public License, úttörő munkát végeztek, mivel sikerült megbízható jogi keretet biztosítaniuk a szoftverek közös fejlesztését körülvevő teljesen új folyamatokhoz. 2001-ben a Lawrence Lessig (Stanford Egyetem) jogászprofesszor által vezetett csoport a

szabad szoftverek mintájára megalapította a Creative Commons (CC) nevű nonprofit szervezetet. A szervezet célját a projekt honlapján a következőképpen foglalják össze: Creative Commons is a global nonprofit organization that enables sharing and reuse of creativity and knowledge through the provision of free legal tools. (A Creative Commons egy globális nonprofit szervezet, amely ingyenes jogi eszközök biztosításával lehetővé teszi a kreativitás és a tudás megosztását és újrafelhasználását.) Creative Commons, Website (FAQ) A “commons” (közös) kifejezéssel, amely a közösségi gazdasági tevékenységnek már a középkorban dokumentált formájára utal, a szervezet egy történelmileg igazolható, mély emberi igényt hangsúlyoz a közös jóra irányuló kollektív cselekvésre. Önmaguk által kitűzött feladatuk ezért az alkotó munka modern jogi kereteinek megteremtése. A Creative Commons a szabad szoftverek mozgalmának igényeit és

megoldásait más kreatív területekre is átviszi, mint például az irodalom, az előadóművészet (festészet, grafika, fotózás, videó stb.) és a zene, de a dokumentáció és a tudományos munka is nagyjából minden olyan alkotásra, amely szerzői jogvédelem alá tartozik. A Free Software Foundationhöz hasonlóan a Creative Commons is úgy döntött, hogy céljait licenceken keresztül valósítja meg: szabványosított, jogilag kötelező érvényű specifikációk gyűjteménye, amelyeket az alkotók kifejezetten hozzárendelnek műveikhez, általában mielőtt “kiadják”, azaz publikálják azokat. Az amerikai szerzői jogban rögzített “minden jog fenntartva” (all rights reserved) elv túlságosan korlátozónak tűnik, tekintettel a kreatív folyamatokban rendelkezésre álló, folyamatosan bővülő technikai lehetőségekre. Maguk az alkotók gyakran nincsenek tisztában azzal, hogy milyen mértékben építhetnek mások munkájára anélkül, hogy

túllépnék a szerzői jog korlátait, és legrosszabb esetben akár büntetőeljárás alá vonva magukat. A Creative Commons ezt a keménykezű rendszert a “néhány jog fenntartva” (some rights reserved) elvével állítja szembe: az alkotók megnevezik azokat a jogokat, amelyeket fenntartanak és így lemondanak minden másról. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 121 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek A mindössze négy egyszerű alapfeltétel (modul) kombinációja összesen hat licencet eredményez, amelyek közül a szerzők kiválaszthatják és hozzárendelhetik a munkájuknak megfelelőt. A Creative Commons licenc moduljai Az imént említett négy modul négy egyszerű alapdöntésnek felel meg, amelyeket a szerző a mű felhasználásával és terjesztésével kapcsolatban hoz. Minden modul kétbetűs rövidítéssel és egy szimbólummal ábrázolható. A vonatkozó

meghatározás nagyon rövid és a jogi laikusok számára is érthető, ami nagyban hozzájárul a CC-licencek népszerűségéhez. Egyedi esetekben azonban a záradékok megoldatlan kérdésekhez vagy szürke zónákhoz vezethetnek. Nevezd meg! (Attribution BY) You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. (A szerzőt megfelelően fel kell tüntetned, hivatkozást kell létrehoznod a licencre és jelezned ha a művön változtatást hajtottál végre. Ezt bármilyen ésszerű módon megteheted, kivéve oly módon ami azt sugallná hogy a jogosult támogat téged vagy a felhasználásod körülményeit.) Creative Commons, Attribution Az angol “by” szó azt jelzi, hogy a szerzőket meg kell nevezni, azaz ha a művet bármilyen formában felhasználják, sokszorosítják vagy továbbadják, egyértelműen a

szerzőknek kell azt tulajdonítani. A BY modul az egyetlen, amely minden CC licencben kötelező Más szóval, a hat szabványos CC licenc alatt nincs olyan mű, amely megúszhatná a megnevezést. Ez az egyszerű követelmény okozhat gyakorlati problémákat az interneten fejlesztett kollaborációs projektek esetén. Például a Wikipedia online enciklopédia alapján létrehozott munkák esetében meglehetősen kérdéses, hogy a hozzászólók ezreinek közreműködése miatt hogyan lehet “megfelelően” elvégezni a “megnevezést”. Ne add el! (NonCommercial NC)) You may not use the material for commercial purposes. (Nem használhatod a művet üzleti célokra.) Creative Commons, NonCommercial A NonCommercial modul szándéka első pillantásra egyértelműnek tűnik: célja, hogy megakadályozza, hogy egy szabadon hozzáférhető művet mások kereskedelmi célokra kisajátítsanak. Ez gyakran olyan műveket érint, amelyeket közpénzekből fejlesztettek ki,

például 122 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek egyetemeken. Ezeket “védeni” kell a kereskedelmi forgalomba hozataltól, hogy biztosítsák minőségüket és hosszú távú szabad elérhetőségüket. Az NC-modul a gyakorlatban gyakran okoz bizonytalanságot, mivel az egyes esetekben egyáltalán nem egyértelmű, hogy egy adott felhasználás ténylegesen kereskedelmi célú-e. Azok a tanárok, akik például CC licenc alatt, NC modullal ellátott anyagokat használnak, máris jogi szürke zónába kerülnek, ha olyan magániskolában vagy magánegyetemen tanítanak, amelyért a diákoknak fizetniük kell. Az NC-modul számos kritikusa elutasítja azt az érvet is, hogy az ingyenes anyagok a kereskedelmi felhasználás miatt “nem-ingyenessé” (non-free) válnak, mivel a művek továbbra is ingyenesen hozzáférhetők. Ne változtasd! (NoDerivs ND) If

you remix, transform, or build upon the material, you may not distribute the modified material. (Ha feldolgozod, átalakítod vagy gyűjteményes művet hozol létre a műből akkor a létrejött művet ugyanazon licencfeltételek mellett kell terjesztened mint az eredetit.) Creative Commons, NoDerivs A származékokról (derivatives, röviden: Derivs), azaz a származékos művekről már volt szó más leckékben. A Creative Commons kontextusában a kifejezés a szerzői jog által védett, meglévő művek alapján történő új művek létrehozására is utal; ezek lehetnek például olyan tananyagok, amelyeket egy tanár adaptál az óráihoz; vagy egy regény más nyelvre történő fordítása. A NoDerivs kategorikusan kizárja az ilyen jellegű módosítások vagy adaptációk terjesztését: a mű csak a szerző által közzétett formában adható tovább. Így add tovább! (Share Alike SA) If you remix, transform, or build upon the material, you must distribute your

contributions under the same license as the original. (Ha feldolgozod, átalakítod vagy gyűjteményes művet hozol létre a műből akkor a létrejött művet ugyanazon licencfeltételek mellett kell terjesztened mint az eredetit.) Creative Commons, ShareAlike A ShareAlike modul azt jelzi, hogy a művet csak a hozzárendelt licencben foglaltakkal azonos feltételek mellett lehet megosztani. Az SA-t a szabad szoftverlicencek copyleft elvének megfelelőjének tekintik, amely biztosítja, hogy a licenc által biztosított szabadságok változatlanul érvényesek legyenek a származtatott művekre is. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 123 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Az SA modul különösen érdekes más modulokkal kombinálva, mivel az SA követelmény más meghatározott feltételeket is frissít, amint azt a különböző licencek bemutatásakor látni fogjuk . A Creative Commons

alaplicencek Az imént bemutatott modulok kombinációi összesen hat licencet eredményeznek. Azért csak hat, mert a négy modul nem minden lehetséges kombinációjának van értelme: például a módosított művek azonos feltételek melletti megosztásának követelménye (ShareAlike) és az adaptációk tilalma (NoDerivs) kölcsönösen kizárják egymást. Következésképpen nincs olyan licenc, amely mindkét modult tartalmazza. Mivel a szerző feltüntetése szintén minden licencnek része, az eredmény az úgynevezett core licencek, amelyekről most lesz szó. Ezeknek a licenceknek a listája úgy is elképzelhető, mint egy skála a “sok szabadság” és a “kevés szabadság” között, mivel a szerző lépésről lépésre válaszol a felhasználási lehetőségekre vagy azok korlátozásaira vonatkozó kérdésekre a művével kapcsolatban, és így végül megkapja a kívánt licenct. Creative Commons Nevezd meg! (Attribution CC BY) A szerző megnevezését már

említettük, mint az összes licenc kötelező elemét, így az első licenc, a CC Attribution csak ezt a modult tartalmazza. A mű így bármilyen felhasználási, módosítási és terjesztési formára felszabadul, amíg a megnevezési követelmény teljesül. Figure 5. CC BY Icon Ha például egy szerző CC BY alatt tett közzé egy verset, a kiadó a szerzővel való egyeztetés és pénzügyi kötelezettségek nélkül is felveheti azt egy versgyűjteménybe, és terjesztheti például könyvesboltokban, feltéve, hogy a verset egyértelműen a szerző műveként tünteti fel. Creative Commons Nevezd meg! - Így add tovább! (Attribution-ShareAlike CC BY-SA) A CC Attribution-ShareAlike megfelel a CC BY-nek, de kiegészíti azt a ShareAlike követelményeivel, azaz a mű módosított változatainak azonos feltételek mellett történő terjesztésével. 124 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version

1.0) | 0532 Creative Commons licencek Figure 6. CC BY-SA Icon Ha például egy énekesnő CC BY-SA licenc alá helyezi a dalát, egy másik zenekar feldolgozhatja vagy átdolgozhatja ezt a művet, feltéve, hogy a saját verzióját CC BY-SA vagy más, azzal kompatibilis licenc alatt teszi közzé. Creative Commons Nevezd meg! - Ne add el! (Attribution-NonCommercial CC BY-NC) A CC Attribution-NonCommercial az első licenc a sorozatban, amely a kereskedelmi célú terjesztés és adaptáció kizárásával a mű felhasználását tilalomhoz köti. Figure 7. CC BY-NC Icon Például egy zenekarnak megengedett lenne, hogy feldolgozza az énekes dalát, de nem használhatja ezt a feldolgozást kereskedelmi célokra, például nem adhatja el a saját lemezein, vagy nem játszhatja azt olyan koncerteken, amelyekért díjat kap. A zenekarnak azonban megengedhető lenne, hogy ezen felül megtiltsa a saját verziójának adaptációját, azaz azt, hogy az adaptációt CC BY-NC-ND licenc

alatt tegye közzé. Creative Commnons Nevezd meg! - Ne add el! - Így add tovább! (AttributionNonCommercial-ShareAlike CC BY-NC-SA) A CC Attribution-NonCommercial-ShareAlike esetében a kereskedelmi felhasználás tilalma ugyanezen feltételek mellett kapcsolódik a terjesztéshez. Hogy példánknál maradjunk: bár a zenekar feldolgozhatja az énekesnő dalát, a feldolgozáshoz nem adhat ND-t, mert a feldolgozást ugyanezen feltételek mellett kell terjeszteni. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 125 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Figure 8. CC BY-NC-SA Icon Creative Commons Nevezd meg! - Ne változtasd! (Attribution-NoDerivs CC BY-ND) A NonCommercialhez hasonlóan a CC Attribution-NoDerivs is egy tilalmon alapul ebben az esetben a mű módosításának vagy átdolgozásának tilalmán. A példánkban szereplő zenekar tehát nem terjeszthetné az énekesnő dalának feldolgozott

változatát. Figure 9. CC BY-ND Icon Az ND záradékkal ellátott CC licencek (azaz a CC BY-ND és a hamarosan ismertetett CC BY-NC-ND licenc) használatát különösen a tudományos területen fogadták szkeptikusan, mivel akadályozhatják a tudományos fejlődéshez szükséges tudáscserét. Még a Creative Commons weboldalán is úgy írják le az ND-modullal rendelkező licenceket, hogy azok összeegyeztethetetlenek a tudományban népszerű nyílt hozzáférés elvével. Az ND túlságosan korlátozó tendenciájára példaként említik, hogy még a tudományos cikkek fordításai is származékos műveknek minősülnek, és ezért tiltottak. Creative Commons Nevezd meg! - Ne Add el! - Ne változtasd ! (AttributionNonCommercial-NoDerivs CC BY-NC-ND) A CC-licencek közül a legszigorúbb, a CC Attribution-NonCommercial-NoDerivs licenc a kereskedelmi felhasználás tilalmát a származéos művek terjesztésének tilalmával kombinálja. Pozitív értelemben ez azt jelenti,

hogy a művet csak a szerző által közzétett formában lehet sokszorosítani és terjeszteni, és csak nem kereskedelmi célokra lehet felhasználni. 126 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek Figure 10. CC BY-NC-ND Icon Az énekesnő a példánkban így megakadályozza, hogy egy zenekar feldolgozza a dalát (ND), ugyanakkor azt kockáztatja, hogy a dalát kizárják minden olyan platformról, amely vásárlókból vagy reklámokból származó bevételt termel. Creative Commons Zero (CC0) és a Public Domain Mark Már említettük, hogy a szerzői jog a különböző országokban és joghatóságoknál nagyon eltérő módon van szabályozva. Az amerikai jog szerint például a jogtulajdonos teljesen lemondhat a szerzői jogáról. Ezzel átadja művét az úgynevezett public domainnek (közkincs), azaz általános és korlátlan használatra. A legtöbb európai

országban azonban a szerzői jog a puszta felhasználási jogokon túlmenően személyhez fűződő jogokat is tartalmaz, amelyek általában nem átruházhatók, és ezért a szerző nem mondhat le róluk. Ha a szerző nyilvánosságra kívánja hozni a művét, akkor lemond minden felhasználási jogáról, de továbbra is ő marad a szerző. Ezen túlmenően vannak olyan művek, amelyek felhasználása önmagában semmilyen korlátozás alá nem esik. Ide tartoznak például azok a művek, amelyek jogi védelmi ideje lejárt (például egy regény 70 évvel a szerző halála után), vagy olyan művek, amelyek elvileg soha nem voltak védettek (például jogi szövegek). A Creative Commons két úgynevezett public domain eszközt biztosít a nagyközönség számára korlátozás nélkül hozzáférhető művek azonosítására. A Creative Commons Zero (CC0) gyakorlatilag nulla feltételhez köti a művek sokszorosítását, terjesztését és módosítását. A CC-licencek

esetében a szerző kötelező feltüntetése is elmarad A licenc lehetővé teszi a jogtulajdonosok számára, hogy műveiket a lehető legtöbb jogrendszerben közkincsként jelöljék meg. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 127 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Figure 11. CC0 Icon Vegyünk például egy oktatási célokra kidolgozott tanulási dokumentumot. A szerző vagy szerzők a CC0-címkét használhatják annak biztosítására, hogy az anyagot bárki korlátozás nélkül felhasználhassa: részben vagy egészben másolható, ingyenesen vagy térítés ellenében terjeszthető, és részben vagy egészben más dokumentumokba integrálható. Az eredeti szerzőket sehol sem kell megnevezni. A szerzői jogi korlátozásoktól mentes művek azonosítására a Creative Commons a Public Domain Mark jelölést ajánlja: The Public Domain Mark operates as a tag or a label, allowing

institutions like those as well as others with such knowledge to communicate that a work is no longer restricted by copyright and can be freely used by others. (A Public Domain Mark tag vagy label formájában működik, amely lehetővé teszi az ilyen és ehhez hasonló intézmények, valamint más, ilyen ismeretekkel rendelkező személyek számára, hogy közöljék, hogy a művet már nem korlátozza a szerzői jog, és mások szabadon felhasználhatják.) Creative Commons, Public Domain Mark Figure 12. Public Domain Mark Icon Licencek kiválasztása és a művek jelölése Már említettük, hogy a Creative Commons célja az, hogy a lehető legegyszerűbb legyen mind az engedélyezők (tartalomkészítők), mind az engedélyesek (a művek címzettjei) számára. A szervezet rengeteg segítséget nyújt a megfelelő licenc kiválasztásától kezdve a művek címkézéséig és felhasználásáig. 128 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version:

2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek A szervezet honlapján található CC License Chooser lépésről lépésre vezet el a megfelelő licenc ajánlásához egyszerű kérdések feltevésével, amelyekre a szerző válaszol a művének kívánt felhasználásával kapcsolatban (CC License Chooser). Figure 13. CC License Chooser Ha a javasolt licenc megfelel a szerző szándékainak, akkor a szerző ennek megfelelően jelölheti művét. A License Chooser például HTML-kódot biztosít, amelyet a szerző közvetlenül hozzáadhat a művet megjelenítő weboldalhoz (HTML kód linkkel a licenchez). Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 129 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Figure 14. HTML kód linkkel a licenchez Az eredmény egy szabványosított megjegyzés a megfelelő licencre mutató linkkel (Licencmegjegyés linkkel a licenchez). Figure

15. Licenc-megjegyés linkkel a licenchez A licenc-specifikus ikonok, amelyeken a beépített modulok közvetlenül láthatók, már bevezetésre kerültek. Ezek “szembeötlők”, amelyekkel azonosítani lehet az interneten található ingyenes tartalmakat. 130 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek Nemzetközi és portolt licencek A Creative Commons kezdettől fogva a lehető legáltalánosabb, azaz világszerte érvényes licencek kifejlesztésére összpontosított, amit az “international” (korábban “unported”) kiegészítéssel jelöl. Másrészt léteznek olyan változatok, amelyek figyelembe veszik egy regionális vagy nemzeti jogrendszer sajátosságait, és "`ported"` néven jelölik őket. Például a CC BY-SA 30 Unported licenc mellett létezik egy speciális, Németországra vonatkozó változat is CC BY-SA 3.0 Germany néven A

CC-licencek jelenleg érvényes 4.0-s verziójával a Creative Commons további szabványosításra törekszik, és (eddig) teljesen lemondott a portolt változatokról. A 40 verzióban az “international” licenc kifejezetten ajánlott: We recommend that you use a version 4.0 international license This is the most up-to-date version of our licenses, drafted after broad consultation with our global network of affiliates, and it has been written to be internationally valid. There are currently no ports of 40, and it is planned that few, if any, will be created. (Javasoljuk, hogy a 40-s verziójú nemzetközi licencet használja. Ez a licencek legfrissebb változata, amelyet a globális partnerhálózatunkkal folytatott széles körű konzultációt követően állítottunk össze, és úgy írtuk meg, hogy nemzetközileg is érvényes legyen. A 40-ás verzióból jelenleg nincs portolás, és tervben is csak kevés van, ha lesz egyáltalán.) Creative Commons, FAQ Version:

2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 131 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Gyakorló feladatok 1. A Creative Commons licencrendszer melyik modulja része mind a hat Creative Commons licencnek? 2. A Creative Commons licencrendszer melyik modulja írja elő a mű azonos feltételek melletti terjesztését? 3. Miben különbözik a CC0 a hat CC-alaplicenctől? 4. Mi a különbség az “international” és a “ported” licencek között? 132 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek Gondolkodtató feladatok 1. Lehetséges-e CC licenc alá helyezni egy olyan műről készült fényképet, amely köztulajdonban van? 2. Egy szerző kiadhatja-e CC-licenc alatt a regényét, amelybe teljes egészében beépít egy Shakespeare-szonettet? 3. Egy felhasználó CC licenc alatt közzétesz egy

fényképet magáról Megakadályozhatja-e a kép terjesztését a személyiségi jogaira hivatkozva? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | a learning.lpiorg weboldalán. | 133 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Összefoglalás A 2001-ben alapított Creative Commons szervezet célja, hogy ingyenes jogi eszközökkel támogassa a kreatív, azaz a szerzői jog hatálya alá tartozó alkotások megosztását és felhasználását. A középpontban négy modul áll (Attribution, NonCommercial, NoDerivs és ShareAlike), amelyeket hat, úgynevezett alaplicencben egyesítenek, és amelyeket a szerzők választhatnak műveikhez. 134 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0532 Creative Commons licencek Válaszok a gyakorló feladatokra 1. A Creative Commons licencrendszer melyik modulja része mind a hat Creative Commons licencnek? Az

“Attribution” (Nevezd meg!) modul, rövidítve “BY.” 2. A Creative Commons licencrendszer melyik modulja írja elő a mű azonos feltételek melletti terjesztését? A “Share Alike” (Így add tovább!) modul, rövidítve “SA.” 3. Miben különbözik a CC0 a hat CC-alaplicenctől? A CC0-val a szerző nem biztosít bizonyos jogokat mint a többi CC-licenc esetében --, hanem lemond minden jogáról a művével kapcsolatban az adott joghatóság lehetőségeinek keretein belül. Ez a “nincs jog fenntartva” (no rights reserved) elv megfelel a mű közkinccsé nyilvánításának. 4. Mi a különbség az “international” és a “ported” licencek között? A 3.0-s verzióig a Creative Commons olyan licencváltozatokat kínált, amelyek figyelembe vették a regionális vagy nemzeti joghatóság sajátosságait. A 40 óta a CC lemondott ezekről az úgynevezett “ported” változatokról, és a vonatkozó licenc globálisan érvényes "international`"

változatát ajánlja. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 135 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Válaszok a gondolkodtató feladatokra 1. Lehetséges-e CC licenc alá helyezni egy olyan műről készült fényképet, amely köztulajdonban van? Ez attól függ, hogy a fénykép megfelel-e azoknak a kritériumoknak, amelyek alapján maga is szerzői jogi védelem alatt áll. Más szóval, magának a fényképnek felismerhetőnek kell lennie, mint kreatív alkotásnak és védelemre érdemesnek, például a perspektíva, a háttér, a szűrők stb. révén Ha ez a helyzet, akkor CC licenc alá helyezhető, és ekkor a CC licenc feltételei érvényesek. Az eredeti rész, azaz a tényleges motívum azonban továbbra is köztulajdonban marad. 2. Egy szerző kiadhatja-e CC-licenc alatt a regényét, amelybe teljes egészében beépít egy Shakespeare-szonettet? Igen, de csak a szerző saját

alkotói részeire vonatkozik a szerző által választott CC licenc. A szonett, amely köztulajdonban van, köztulajdonban marad. 3. Egy felhasználó CC licenc alatt közzétesz egy fényképet magáról Megakadályozhatja-e a kép terjesztését a személyiségi jogaira hivatkozva? a weboldalán. Egy fénykép CC licenc alatti közzétételével a tulajdonos általában hozzájárul a fénykép terjesztéséhez. A határértéket az jelenti, ha a fénykép felhasználása sérti a tulajdonos személyiségi jogait, például ha a képet durván eltorzítják, vagy ha a tulajdonos beleegyezése nélkül használják fel reklámcélokra vagy politikai kontextusban. A tulajdonos személyiségi jogait nem érinti a felhasználási jogok CC-licenc általi szabályozása, így ilyen esetekben jogi lépéseket tehet a fotója felhasználása ellen. 136 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb

nyílt tartalmi licencek 053.3 Egyéb nyílt tartalmi licencek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0533 Súlyozás 1 Kulcsfontosságú ismeretek • A dokumentáció licencelésének megértése • Az adatkészletek és adatbázisok licencelésének megértése • A nyílt tartalmi licencek által biztosított jogok megértése • A nyílt tartalmi licencek által teremtett kötelezettségek megértése A használt fájlok, kifejezések és segédprogramok listája • GNU Free Documentation License, version 1.3 (GFDL) • Open Data Commons Open Database License (ODbL) • Community Data License Agreement – Permissive, version 1.0 (CDLA) • Community Data License Agreement – Sharing, version 1.0 (CDLA) • Nyílt hozzáférés Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 137 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Lecke 1 Tanúsítvány: Open

Source Essentials Verzió: 1.0 Témakör: 053 Nyílt tartalmi licencek Fejezet: 053.1 Egyéb nyílt tartalmi licencek Lecke: 1/1 Bevezetés A korábbi leckék már bemutatták a nyílt tartalom fogalmát, a Creative Commons licencekre összpontosítva. A Creative Commons licenceken kívül azonban léteznek más nyílt tartalmi licencek is, amelyek közül néhány konkrét tartalomra vonatkozik, és amelyeket rendszeresen használnak nyílt forráskódú projektek “melléktermékeire” (például dokumentációra) is. Licencek (szoftver) dokumentációhoz A nagy szoftverrepositoryk a kódon kívül rendszeresen tartalmaznak dokumentációt vagy kézikönyveket (manual) is a szoftverhez. A dokumentáció általában különböző szerzői jogi védelem alá eső elemeket tartalmaz, például magyarázó szövegeket, szemléltető grafikákat vagy kódpéldákat. A repository tartalmára vonatkozó nyílt forráskódú licencek általában az ilyen szövegekre is

vonatkoznak, ha más információ nem áll rendelkezésre; a GPLv3.0 például “minden szerzői jogi védelem alatt álló műre” vonatkozik, és nem korlátozódik csak a kódra. A dokumentációra azonban gyakran eltérő licencfeltételek vonatkoznak. Ennek több okból is lehet értelme, mivel a dokumentáció előállítása és használata eltér a kódétól. A számítógépes programok szigorú copyleft licencének feltételei például megakadályozhatják a dokumentáció 138 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb nyílt tartalmi licencek egyes részeinek más programok számára történő átvételét. Az sem világos, hogy mit jelent, amikor a GPLv3.0 licenc alatt álló dokumentáció esetében a “forráskódot” kell megadni Ráadásul régebben bevett gyakorlat volt a programok dokumentációjának vagy kézikönyveinek nyomtatott változatainak terjesztése. Ezt a

körülményt jobban figyelembe lehet venni a speciális dokumentációs licenceknél (például ha bizonyos licenckötelezettségek a terjesztett példányok bizonyos számához kapcsolódnak). A Creative Commons licenceket gyakran használják a dokumentációra, de léteznek speciális copyleft licencek is erre a célra, mint például a Free Documentation License (FDL), amely a preambulumában kifejti a célját: The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. (Ennek a licencnek az a célja, hogy egy kézikönyvet, tankönyvet vagy más funkcionális és hasznos dokumentumot a szabadság

értelmében “szabaddá” tegyen: biztosítsa mindenki számára a tényleges szabadságot a másolásra és az újraelosztásra, módosítással vagy anélkül, akár kereskedelmi, akár nem kereskedelmi céllal. Másodsorban, ez a licenc a szerzőnek és a kiadónak lehetőséget biztosít arra, hogy munkájáért elismerésben részesüljön, miközben nem tekinthető felelősnek a mások által végzett módosításokért.) This License is a kind of “copyleft,” which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. (Ez a licenc egyfajta “copyleft”, ami azt jelenti, hogy a dokumentumból származó műveknek ugyanebben az értelemben szabadnak kell lenniük. Kiegészíti a GNU General Public License-t, amely egy szabad szoftverekhez tervezett copyleft licenc.) We have designed this License in order to use it for manuals for free

software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. (Ezt a licencet azért terveztük, hogy a szabad szoftverek kézikönyveihez használhassuk, mert a szabad szoftvereknek szabad dokumentációra van szükségük: egy szabad programhoz olyan kézikönyveknek kell tartoznia, amelyek ugyanolyan szabadságot biztosítanak, mint a szoftver. Ez a licenc azonban nem korlátozódik a szoftver kézikönyvekre; bármilyen szöveges műre alkalmazható, függetlenül a témától vagy attól, hogy nyomtatott könyvként jelenik-e meg. Ezt a icencet elsősorban olyan Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg |

139 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek művekhez ajánljuk, amelyek célja oktatás vagy hivatkozás.) Free Documentation License, Preamble A licenc nagyon specifikus a dokumentációra; például a nyomtatott változatokra is vonatkozik. A copyleft licenc kifejezetten nem érinti azt a kódot, amellyel együtt szállítják a dokumentációt. Bár a dokumentáció GPLv3.0 alatt is terjeszthető lenne MIT-licencű kóddal együtt: mivel ebben az esetben két független műről lenne szó, a dokumentáció GPLv3.0-ás licencének nem kellene a kódot is GPLv3.0-ás licenc alá helyezni A dokumentációra vonatkozó külön licenc azonban egyértelműbbé teszi ezt a kérdést. Licencek adatbázisokhoz Az adatbázisokhoz is léteznek speciális licencek. Ezek többek között figyelembe veszik az adatbázisnak egy program forrásaként való használatát, valamint az adatbázisok szerzői jogi védelmének sajátosságait. Mikre

vonatkozik az “Adatbázis” kifejezés A szerzői jogban egyes jogrendszerekben (beleértve Európát is) különbséget tesznek az adatbázisalkotások között, amelyek más szerzői jogi védelem alatt álló alkotásokhoz (képek, szövegek stb.) hasonlóan személyes szellemi alkotás (elemek kiválasztása és elrendezése) alapján élveznek védelmet, és az adatbázisok között, amelyek előállításához (beszerzés, ellenőrzés, bemutatás) jelentős beruházásra volt szükség (adatbázisjog). Mindkét esetben az oltalom tárgya független elemek (például különálló művek vagy adatok) gyűjteménye, amelyek szisztematikusan vagy módszeresen vannak elrendezve és külön-külön elektronikusan vagy más módon hozzáférhetők. Maguknak az elemeknek a szerzői jogi védelemre való alkalmassága nem fontos, így azok lehetnek egyszerű számértékek is. Az adatok gyűjteménye ezért adatbázis-műként vagy (az EU-ban) adatbázisjog alapján szerzői jogi

védelemben részesülhet. Ahhoz, hogy egy adatbázis-mű védelmet élvezzen, az elemek elrendezésének és kiválasztásának személyes szellemi alkotást kell kifejeznie. Ez nem valószínű, hogy így van a szoftverek alapjául szolgáló adatgyűjtemények esetében de ezek adatbázisjog alapján védelmet élvezhetnek. E jog megszerzéséhez az elemek összegyűjtésébe és elrendezésébe jelentős befektetést kell eszközölni. Ez a befektetés időből és emberi erőforrásokból is állhat Az adatbázisokhoz és adatgyűjteményekhez ma már különböző licencek állnak rendelkezésre, amelyek jobban lefedik az adatok felhasználását, mint a “klasszikus” nyílt forráskódú szoftverlicencek. Nézzük meg a különbséget egy példán keresztül! Egy tudományos kutatási projekt részeként egy szerző összes versét összegyűjtik és közzéteszik 140 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials

(Version 1.0) | 0533 Egyéb nyílt tartalmi licencek egy weboldalon, ahol cím szerint ábécérendbe rendezve, egyenként is elérhetők. A projekt azonban megköveteli, hogy a versek terjesztéséhez és sokszorosításához a szerzőtől megszerezzék a vonatkozó szerzői jogokat. Ezért licencdíjat fizetnek A licencdíjak “jelentős beruházásnak” minősülhetnek. Mivel a versek egyenként visszakereshetők és szisztematikusan (az ábécé szerint) elrendezhetők, a verseket tartalmazó adatbázis az adatbázisjog alapján védhető. Az elemek (versek) azonban nem konkrétan kerültek kiválasztásra (a kiválasztás a teljesség alapján történt), és a rendezés nem alkotó jellegű, hanem pusztán szisztematikus. Az adatbázissal kapcsolatban tehát nincs személyes szellemi alkotás, így az adatbázis nem minősül adatbázis-műnek. Ha viszont a verseket bizonyos szempontok szerint rendezték és válogatták össze például azért, hogy a szerző

munkásságának bizonyos motívumait dokumentálják az alkotói időszak kontextusában --, akkor személyes szellemi alkotásról lehet szó, és akkor ez a versgyűjtemény adatbázis-műként védhető lenne. A két kategóriát azonban a szerzői jog eltérően kezeli, különösen a védelmi idő tekintetében: az adatbázisjog hatálya alá tartozó adatbázisok csak az előállítás/kiadás után 15 évig élveznek védelmet, míg az adatbázis-művek esetében a szerző halála után 70 évig. Az adatok elhatárolása A benne lévő adatokat (példánkban a verseket) mindig külön kell vizsgálni az adatbázis egészétől, mivel azok önállóan is jogosultak lehetnek (de nem feltétlenül) védelemre, és ezért eltérő licencfeltételek vonatkozhatnak rájuk. Például a versgyűjteményre vonatkozhat az Open Database License (lsd. alább), míg az egyes versekre vonatkozhat Creative Commons licenc vagy saját licenc Az adatbázis-kezelő rendszer (DBMS) elhatárolása

Ezenkívül az adatok kezelésére szolgáló szoftvert, az úgynevezett adatbázis-kezelő rendszert (database management system DBMS), amely a szerzői jog értelmében nem tekinthető az adatbázis részének, hanem az adatokhoz való hozzáférés eszközeként, a szerzői jog értelmében külön kell kezelni. Az ilyen alkalmazások mint például a MySQL, PostgreSQL, MariaDB és mások külön számítógépes programoknak tekintendők, és mint ilyenek védhetők. Adathalmazok a gépi tanulási modellek képzéséhez Különböző adatgyűjtemények tölthetők le olyan weboldalakról, mint a huggingface.co vagy a kaggle.com, például gépi tanulási modellek képzése céljából Az ilyen gyűjtemények, más néven adatkészletek (dataset), általában adatbázis-használati jog alá tartoznak, feltéve, hogy előállításukba “jelentős beruházást” eszközöltek (ami kívülről általában nem látható). Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve

| learning.lpiorg | 141 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek A “dataset” kifejezés kissé homályos, mivel utalhat egy adatbázis egy sorára azaz egy bejegyzésre vagy egy meghatározható elemre --, de vonatkozhat adatok vagy adathalmazok gyűjteményére is. Open Database License (ODbL) Ezek a különbségek az adatbázis-ágazatban széles körben használt Open Database License (ODbL) licencben is megjelennek. Az ODbL-t az Open Data Commons, az Open Knowledge Foundation projektje dolgozta ki. A licenc a preambulumában egyértelmű különbséget tesz az adatbázis védelme és az adatbázis egyes tartalmainak védelme között. A licenc csak az előbbire vonatkozik, míg a tartalom ettől függetlenül máshol is licencelhető. Természetesen továbbra is lehetséges, hogy ugyanazt a licencet válasszuk az adatbázis és a tartalom számára, például, hogy CC-BY-4.0 licenc alatt engedélyezett művek gyűjteményét

állítsuk össze egy adatbázisban, amely CC-BY-4.0 licenc alatt áll Az adatbázis legjobb licencének kiválasztása az adatbázis gyártójának célkitűzéseitől függ. Maradjunk a versgyűjtemény példájánál: ha a költészeti adatbázis tetszőlegesen módosítható, és más licencfeltételek mellett is terjeszthető, az ODbL nem lenne megfelelő választás. Az ODbL ugyanis az adatbázisokra vonatkozóan copyleftet tartalmaz, ami azt jelenti, hogy egy ODbL-licenc alatt álló adatbázisból származtatott adatbázis (pl. egy olyan adatbázis, amely átveszi az eredeti adatbázis összes elemét és elemeinek elrendezését, és másokat hozzáad) csak ugyanezen feltételek mellett terjeszthető tovább. Ebben az esetben a szerkesztési jogokkal rendelkező Creative Commons licenc (pl. CC-BY) a jobb választás Az ODbL azt is világossá teszi, hogy semmiképpen sem vonatkozik az adatbázist kezelő számítógépes programokra (azaz a DBMS-re): “This License does not

apply to computer programs used in the making or operation of the Database.” ("Ez a licenc nem vonatkozik az adatbázis készítésében vagy működtetésében használt számítógépes programokra.") A licenc azonban előírja, hogy az adatbázis tartalmából létrehozott és nyilvános használatra hozzáférhető műnek (az úgynevezett előállított műnek) legalább azt meg kell jelölnie, hogy melyik adatbázist (nem DBMS-t) használták hozzá, és hogy maga az adatbázis az ODbL feltételei szerint használható. Ilyen előállított műre példa az adatbázisban összegyűjtött koordinátákból készített utcatérkép. Ha egy adatbázisra az ismert (szoftverspecifikus) copyleft licencek valamelyikét, például a GPLv3.0-t használnák, akkor feltételezhető, hogy az adatbázist használó számítógépes program (például egy áruházrendszerhez) csak a GPLv3.0 feltételei szerint terjeszthető Másrészt egy DBMS licencét valószínűleg

függetlenítenék az adatbázis licencétől, mivel a DBMS nem tekinthető az adatbázis “származtatott művének”; csupán a hozzáférést és a szerkesztést teszi lehetővé, és ezért 142 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb nyílt tartalmi licencek független műnek minősül. Community Data License Agreements (CDLA) A Community Data License Agreements (Közösségi adatlicenc-megállapodások CDLA), a Linux Foundation projektje, szintén az adatok licencelésére összpontosít (a szoftverektől eltérően). A gépi tanulási rendszerek képzési adatgyűjteményei szintén képezhetik a CDLA-k tárgyát. Our communities wanted to develop data license agreements that could enable sharing of data similar to what we have with open source software. The result is a large scale collaboration on licenses for sharing data under a legal framework which we call the Community Data

License Agreement (CDLA). (A közösségeink olyan adatlicencmegállapodásokat akartak kidolgozni, amelyek lehetővé teszik az adatok megosztását, hasonlóan a nyílt forráskódú szoftverekhez. Az eredmény egy nagyszabású együttműködés az adatok megosztására vonatkozó licencek kidolgozásában egy olyan jogi keretrendszerben, amelyet mi közösségi adatlicenc-megállapodásnak (Community Data License Agreement, CDLA) nevezünk.) These licenses establish the framework for collaborative sharing of data that we have seen proven to work in open source software communities. (Ezek a licencek létrehozzák az adatok közös megosztásának keretét, amely a nyílt forráskódú szoftverközösségekben már bevált.) CDLA website (cdla.dev) A CDLA ezért olyan keretrendszeren alapul, amely figyelembe veszi az engedélyezési kérdések különböző szintjeit, különösen akkor, ha az adatokat több forrásból, különböző szerzők állítják össze. Példánkban ez

lehet egy olyan gyűjtemény, amelyben különböző szerzők saját verseikkel járulnak hozzá egy közös költészeti adatbázis létrehozásához. A CDLA különbséget tesz a gyűjteménybe felvett adatokra vonatkozó “inbound licenc” (bejövő) és az adatok felhasználására vonatkozó “outbound licenc” (kimenő) között. Harmadik szinten meghatározza az adatokat tároló vagy birtokló szervezetre vonatkozó követelményeket. Hogy a költészet példájánál maradjunk: egy szerző, aki hozzáadja a versét, az “inbound licenc” előírásai szerint jár majd el. Az “outbound licenc” a versgyűjtemény egészének szerkesztői által elfogadott feltételekre vonatkozik. A nyílt forráskódú szoftverlicencekhez hasonlóan a CDLA-k is elérhetőek permisszív és sharing (megosztó) kategóriákban, amelyeket röviden bemutatunk. A fent említett kagglecom vagy huggingface.co honlapok meglátogatása képet ad arról, hogy milyen licenceket használnak

adatbázisok vagy adatkészletek esetében: szűrők segítségével például megtudhatjuk, hogy mely adatgyűjtemények érhetők el a CDLA alapján. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 143 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Community Data License Agreement Permisszív A CDLA permisszív, 2.0 verziója 2021 óta elérhető, és sokkal tömörebb és világosabban van megfogalmazva, mint az 1.0 verzió Az 1.0 verzió jogot biztosít a licencelt adatok felhasználására és közzétételére, beleértve az úgynevezett “bővített adatok” (enhanced data) közzétételét, amely magában foglalja az adatkészlet módosításait vagy kiegészítéseit is. Az adatok továbbadása vagy közzététele során az alapvető licenckötelezettségeket be kell tartani; többek között a licenc szövegét tovább kell adni, a változtatásokat jelölni kell, és a szerzői jogi megjegyzéseket meg

kell őrizni. Az adatok további vagy más licencfeltételek mellett is továbbadhatók. A 2.0 verzióban már nem használják az “enhanced data” kifejezést; ehelyett a jogok megadása pontosabban van megfogalmazva: A Data Recipient may use, modify, and share the Data made available by Data Provider(s) under this agreement if that Data Recipient follows the terms of this agreement. (Az adatátvevő felhasználhatja, módosíthatja és megoszthatja az adatszolgáltató(k) által e megállapodás alapján rendelkezésre bocsátott adatokat, ha az adatátvevő betartja e megállapodás feltételeit.) Community Data License Agreement - Permissive, version 2.0 A 2.0 verzióban az adatok megosztásának egyetlen feltétele a licenc szövegének vagy a licenc szövegére mutató linknek a továbbadása. Community Data License Agreement Megosztó A CDLA sharing (megosztó) változata, amely jelenleg csak az 1.0 verzióban érhető el, az adatokra vonatkozóan copyleftet tartalmaz oly

módon, hogy a “bővített adatok” transzferálása (“publish” (közzététel)) csak azonos feltételek mellett engedélyezett. The Data (including the Enhanced Data) must be Published under this Agreement in accordance with this Section 3; (Az adatokat (beleértve a bővített adatokat is) e megállapodás alapján a jelen 3. szakasznak megfelelően kell közzétenni;) Community Data License Agreement -- Sharing, version 1.0 Open Access A nyílt tartalommal kapcsolatban gyakran használt kifejezés a nyílt hozzáférés (open access). Bár a fogalom jogi értelemben nincs meghatározva, a Budapesti Nyílt Hozzáférési Kezdeményezés (Budapest Open Access Initiative BOAI) nyilatkozata világossá teszi a nyílt hozzáférés mögötti 144 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb nyílt tartalmi licencek szándékot. A kezdeményezés egy 2001-es budapesti konferenciából

született, és a nyílt hozzáférés érdekében tett nemzetközi erőfeszítéseket foglalja össze: The literature that should be freely accessible online is that which scholars give to the world without expectation of payment. Primarily, this category encompasses their peer-reviewed journal articles, but it also includes any unreviewed preprints that they might wish to put online for comment or to alert colleagues to important research findings. There are many degrees and kinds of wider and easier access to this literature. By “open access” to this literature, we mean its free availability on the public internet, permitting any users to read, download, copy, distribute, print, search, or link to the full texts of these articles, crawl them for indexing, pass them as data to software, or use them for any other lawful purpose, without financial, legal, or technical barriers other than those inseparable from gaining access to the internet itself. The only constraint on

reproduction and distribution, and the only role for copyright in this domain, should be to give authors control over the integrity of their work and the right to be properly acknowledged and cited. ("Legyen szabadon hozzáférhető a számítógépes hálózaton a szakirodalomnak az a része, amelyet a tudósok átadnak a világnak anélkül, hogy ezért díjazásra tartanának igényt. Ebbe a körbe elsősorban a lektorált folyóiratcikkeik tartoznak, de köztük vannak olyan lektorálatlan preprintjeik is, amelyeket azért tesznek közzé, hogy kollégáik észrevételeit összegyűjtsék, vagy felkeltsék figyelmüket fontos kutatási eredményeikre. Többféleképpen, szélesebb körben és könnyebben is hozzá lehet férni ezekhez az írásokhoz. Szabad hozzáférésen azt értjük, hogy mindenki számára ingyenesen olvashatók, letölthetők, lemásolhatók, kinyomtathatók, terjeszthetők ezek a cikkek, bennük keresés végezhető, a cikkek teljes szövegéhez

csatolások fűzhetők, keresőmotorral indexelhetők, adat formájában valamely szoftverrel kezelhetők, vagy egyéb törvényes célra felhasználhatók pénzügyi, jogi vagy műszaki korlátozás nélkül, kivéve azokat a korlátozásokat, amelyek egyébként az internethez való hozzáférés velejárói. A reprodukálás és terjesztés egyedüli korlátja az legyen, és a szerzői jogvédelem szerepe ezen a területen abban nyilvánuljon meg, hogy a szerzők ellenőrizhessék műveik integritását, továbbá jogosultak legyenek arra, hogy megfelelően elismerjék munkájukat, és hivatkozzanak rájuk.") Declaration of the Budapest Open Access Initiative A nyílt hozzáférés tehát különösen a tudományos irodalomhoz és más internetes tartalmakhoz való szabad hozzáférésre vonatkozik. A nyílt hozzáférés mozgalma az 1990-es években indult azzal a céllal, hogy a tudományos publikációkat a nagyközönség számára is hozzáférhetővé tegyék. A nyílt

hozzáférés tehát nem egy konkrét engedélyre vagy bizonyos engedélyezési feltételekre utal, hanem inkább az engedélyezés koncepciójára. Amikor egy cikket nyílt hozzáféréssel tesznek közzé, az első lépés a nyílt tartalom licencének kiválasztása, például a Creative Commons licencek egyike. A CC licenc kiválasztása azonban nem Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 145 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek kötelező a nyílt hozzáféréshez. Az évek során kialakult a különböző nyílt hozzáférési stratégiák kategorizálása, amelyek a kettős licencelést is figyelembe veszik például átfogó licenc megadása a kiadónak, miközben a szerző egyidejűleg a tartalmat saját weboldalán kínálja letöltésre. Mind a BOAI, mind a két évvel később elfogadott Berlini Nyilatkozat (Berlin Declaration) fontos mérföldkőnek számít a nyílt hozzáférés

mozgalmában. A Berlini Nyilatkozat preambuluma kimondja: In accordance with the spirit of the Declaration of the Budapest Open Access Initiative, the ECHO Charter and the Bethesda Statement on Open Access Publishing, we have drafted the Berlin Declaration to promote the Internet as a functional instrument for a global scientific knowledge base and human reflection and to specify measures which research policy makers, research institutions, funding agencies, libraries, archives and museums need to consider. (A Budapesti Nyílt Hozzáférés Kezdeményezés Nyilatkozatának, az ECHO Chartának és a Bethesda Nyílt Hozzáférés Kiadói Nyilatkozatnak a szellemével összhangban elkészítettük a Berlini Nyilatkozatot, hogy előmozdítsuk az internetet mint a globális tudományos tudásbázis és az emberi reflexió funkcionális eszközét, és hogy meghatározzuk azokat az intézkedéseket, amelyeket a kutatáspolitikai döntéshozóknak, kutatóintézeteknek, finanszírozó

ügynökségeknek, könyvtáraknak, archívumoknak és múzeumoknak figyelembe kell venniük.) Berlin Decalaration 2003 146 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb nyílt tartalmi licencek Gyakorló feladatok 1. A “klasszikus” nyílt forráskódú licencek használhatók dokumentációra és adatbázisokra is? Igen Nem Attól függ, nincs egyértelmű válasz 2. Van értelme külön licenceket használni a dokumentációhoz? Miért? 3. Van értelme külön licenceket használni az adatbázisokhoz? Miért? 4. Az alábbi licencek közül melyik alkalmas dokumentációhoz? CC-BY-4.0 FDL ODbL GPL-3.0 BSD-3-Clause 5. Mit jelent a “nyílt hozzáférés” kifejezés? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 147 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Gondolkodtató feladatok 1. Vannak speciális licencek

a betűtípusokhoz? 2. Fejtsünk ki röviden két nyílt hozzáférési stratégiát vagy modellt! 3. Mit jelent a “nyílt definíció” (open definition)? 148 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb nyílt tartalmi licencek Összefoglalás A jól ismert Creative Commons licencek mellett léteznek más, még inkább az adott adattípusokra szabott koncepciók is a tartalom licencelésére: a szoftverdokumentáció vagy az adatbázisok esetében az FDL vagy az ODbL licencek állnak rendelkezésre, amelyek figyelembe veszik az ilyen típusú művek jellemzőit. Ez a lecke áttekintést nyújt néhány ilyen licencről, és kitér a nyílt hozzáférés fogalmára is. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 149 Open Source Essentials (Version 1.0) | Témakör 053: Nyílt tartalmi licencek Válaszok a gyakorló feladatokra 1. A “klasszikus”

nyílt forráskódú licencek használhatók dokumentációra és adatbázisokra is? Igen X Nem Attól függ, nincs egyértelmű válasz 2. Van értelme külön licenceket használni a dokumentációhoz? Miért? Igen, mert ezek általában más tartalmat is tartalmaznak, mint maga a program. Szabályozzák például azt is, hogyan kell kezelni a dokumentáció kinyomtatott példányait. 3. Van értelme külön licenceket használni az adatbázisokhoz? Miért? Igen, hasznos lehet. Különösen egy speciális adatbázis-licenccel lehet elérni az adatbázis copyleft hatását anélkül, hogy a copyleft hatással lenne a környező kódra. Ezen túlmenően az adatbázis-licencek az adatbázisok védelmére vonatkozó szerzői jogi törvények által előírt különleges rendelkezésekkel foglalkoznak. 4. Az alábbi licencek közül melyik alkalmas dokumentációhoz? CC-BY-4.0 X FDL X ODbL GPL-3.0 BSD-3-Clause 5. Mit jelent a “nyílt hozzáférés” kifejezés? A kifejezés a

tudományos irodalomhoz és egyéb internetes tartalmakhoz való szabad hozzáférést írja le. 150 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0533 Egyéb nyílt tartalmi licencek == Válaszok a gondolkodtató feladatokra 6. Vannak speciális licencek a betűtípusokhoz? Igen, létezik például a SIL Open Font License (OFL), amely kifejezetten a betűtípusokra vonatkozó copyleftet tartalmaz, de ennek nincs hatása, ha a betűtípusokat változatlan formában használják. 7. Fejtsünk ki röviden két nyílt hozzáférési stratégiát vagy modellt! A “Gold” nyílt hozzáférésű stratégia esetében a kiadványt közvetlenül a kiadó teszi hozzáférhetővé nyílt tartalmi licenc alapján, általában (de nem kizárólag) Creative Commons licencek használatával. A “Green” nyílt hozzáférési modell akkor alkalmazható, amikor a kiadó nem terjeszti a kiadványt nyílt hozzáférés

keretében, de a szerző lehetőséget kap arra, hogy a kiadványt letölthetővé tegye, például a saját weboldalán, nyílt licenc alapján. 8. Mit jelent a “nyílt definíció” (open definition)? A “nyílt definíció” az Open Knowledge Foundation által megfogalmazott közös értelmezése a “nyílt” kifejezésnek a “nyílt adat” (open data), “nyílt tudás” (open knowledge) és “nyílt tartalom” (open content) fogalmakra. A definíció különösen azokat az alapvető szabadságokat írja le, amelyeket biztosítani kell ahhoz, hogy egy licenc a definíció értelmében “nyílt” legyen. Ezek közé tartozik a hozzáférés, a használat, a szerkesztés vagy módosítás és a megosztás. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 151 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Témakör 054: Nyílt forráskódú üzleti modellek 152 | learning.lpiorg | CC

BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek 054.1 Szoftverfejlesztési üzleti modellek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0541 Súlyozás 2 Kulcsfontosságú ismeretek • A szoftver vagy tartalom nyílt licenc alatt történő kiadásának a céljainak és okainak megértése • A nyílt forráskódú szoftvereket és nyílt tartalmakat fejlesztő szervezetek általános üzleti modelljeinek és bevételi forrásainak megértése • A nyílt forráskódú szoftverek nagyobb technológiai összetevőjeként való használatának következményei termékek és szolgáltatások • A licencek szoftverfejlesztési üzleti modellekre gyakorolt hatásának megértése • A nyílt forráskódú szemszögéből szoftverekkel kapcsolatos megfontolások megértése az ügyfél • A nyílt forráskódú szoftverfejlesztési

üzleti modellekhez szükséges költségszerkezetek és beruházások ismerete A használt fájlok, kifejezések és segédprogramok listája • Térítés ellenében történő fejlesztés • Open-core és fizetős kiegészítők • Freemium • Vállalati és közösségi verziók • Önálló terjesztés Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 153 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek • Előfizetések • Ügyféltámogatás 154 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 054 Nyílt forráskódú üzleti modellek Fejezet: 054.1 Szoftverfejlesztési üzleti modellek Lecke: 1/1 Bevezetés Hagyományosan a jogvédett szoftvereket (más néven zárt forráskódú szoftvereket)

forgalmazó vállalatok üzleti modellje viszonylag egyszerű volt: a szoftver használatára vonatkozó licencet adták el, akár egyszeri díjazással, akár folyamatos alapon, előfizetéses modellben. Az évtizedek során azonban a szoftverek piaca gyökeresen megváltozott, az ügyfelek ma már elvárják, hogy néhány dollárt fizessenek egy alkalmazásért, majd életük végéig ingyenes frissítéseket kapjanak. Ennek eredményeképpen a szabadalmaztatott szoftverek régimódi megközelítése már nem nyereséges, és még azok a vállalatok is, amelyek korábban a teljes üzleti modelljüket a szoftverlicencek értékesítésére építették, mára a szállítói integráció, a támogatás, a szolgáltatások, a Software-as-a-Service (SaaS), a felhő/konténer hosting és a szoftvereket futtató hardvertermékek (telefonok, laptopok, szerverek, nyomtatók, autók, okosórák stb.) felé diverzifikálódtak Ezzel szemben a szabad és nyílt forráskódú szoftverek

licencei bárkinek jogot adnak a szoftver használatára, tanulmányozására, módosítására és újraelosztására díjfizetés nélkül. A nyílt forráskódra épülő vállalkozásoknak tehát soha nem volt lehetőségük arra, hogy a szoftver Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 155 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek használatához licencet adjanak el. Nem várhatjuk el, hogy egyszerűen átvegyük mások munkáját egy nyílt forráskódú projektből, és hatalmas profitot termeljünk azzal, hogy ezt a nyilvánosan elérhető munkát az ügyfeleinknek adjuk, mert ők ugyanazt a szoftvert ingyenesen megkaphatják közvetlenül a projektből. Ehelyett az ingyenes és nyílt forráskódú szoftvereket kínáló vállalatok alternatív üzleti modelleket alkalmaznak. A legsikeresebb szoftver üzleti modellek gyakran az ügyfélérték többféle formáját ötvözik. Ez a

lecke azt vizsgálja, hogy egy vállalat miért választja a nyílt forráskódú szoftverekkel kapcsolatos üzleti modellek némelyikét, és milyen kompromisszumokkal járnak ezek a lehetőségek. A szoftver vagy tartalom nyílt licenc alatt történő kiadásának céljai és okai Számos oka van annak, hogy a fejlesztők a nyílt forráskódra épülő vállalkozást választják: a szoftver kielégíthet egy igényt, megoldhat egy problémát, vagy biztosíthat bizonyos funkciókat, amelyeket a fejlesztők az ügyfeleknek szállítanak. Egy vállalat időt és pénzt takaríthat meg azzal, hogy a szoftveren végzett munkát megosztja más fejlesztőkkel, ahelyett, hogy ugyanazt a szoftvert a nulláról írná meg. A projektben való részvétel egy befektetés, amely remélhetőleg használható, stabil, megbízható, biztonságos, jól karbantartott szoftverben térül meg. Sok nyílt forráskóddal dolgozó fejlesztő reméli, hogy hibajavításokat kap az ügyfelektől.

Néhány ügyfél még magasabb szintre emeli a hozzájárulását azzal, hogy új funkciókat ad hozzá, új környezetbe portolja a szoftvert, vagy más jelentős fejlesztéseket hajt végre. Mind a hibajavítások, mind a magasabb szintű fejlesztések javítják az eredeti szoftvert. Ha az ügyfelek ezeket visszaadják az eredeti fejlesztőknek, a változtatások a kódot vonzóbbá tehetik más potenciális ügyfelek számára, és ösztönzik annak adaptálását. Egy vállalat azonban nem számíthat hozzájárulásra és figyelemre pusztán azzal, hogy a kódját egy olyan webhelyen helyezi el, mint a GitHub vagy a GitLab. Egy dolog a fejlesztőket arra ösztönözni, hogy csatlakozzanak egy projekthez, de sokkal nagyobb kihívás őket lelkesedésükben tartani ezért ne becsüljük alá a közösségi hozzájárulások által megkövetelt munka mennyiségét. Egy vállalatnak erőfeszítéseket kell tennie a fejlesztők toborzására, mentorálására, motiválására és a

kódjuk hibakeresésére. Egy másik ok a kód nyílttá tétele mellett egy ipari szabvány létrehozása. A kód nyílt módon történő megosztása jobb interoperabilitást és egyéb előnyöket eredményezhet. A kódot fejlesztő csapat értékes szakértelemmel rendelkezik, amely lehetővé teheti számukra, hogy irányítsák a projekt jövőjét, és fizetést kapjanak a kódot használók támogatásáért. Egyes vállalatok azért nyitják meg kódjukat, hogy bizalmat keltsenek az ügyfelek körében. Először 156 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek is, az ügyfelek tudják, hogy továbbra is használhatják és fejleszthetik a kódot, ha a vállalat kudarcot vall, vagy úgy dönt, hogy más piacra lép, és hátrahagyja a kódot. Másodszor, az ügyfelek maguk is ellenőrizhetik a kód minőségét és biztonságát, vagy független

szakértőt kérhetnek fel egy audit elvégzésére, ami a zárt, védett szoftverek esetében általában nem lehetséges. Végül pedig előfordulhat, hogy egy vállalat már nyílt forráskódú kódbázist fogad el, és kereskedelmi üzletet tervez rá építeni. A licenc előírhatja a vállalat számára, hogy a változtatások forráskódját a program bármely végfelhasználója számára terjessze. Röviden, néhány ok, amiért érdemes nyílttá tenni egy cég kódját: • Egy meglévő szabad szoftver projektre építkezés • Az ügyfelek innovációjának és hozzájárulásainak kihasználása • Bizalom kialakítása az ügyfelek körében • A kód ipari szabványként való népszerűsítése Gyakori üzleti modellek és bevételi források A szoftveripar az elmúlt évtizedek során számos üzleti modellt fedezett fel, amelyek alkalmasak a saját tulajdonú és a nyílt forráskódú vállalkozások számára egyaránt. Ez a szakasz a nyílt forráskódú

fejlesztők körében jelenleg használt legnépszerűbbekre összpontosít. Az egyik üzleti modell, amely a szabadalmaztatott és a nyílt forráskódú szoftverek esetében egyaránt elterjedt, a támogatásért felszámított díj. Az ügyfeleknek gondot okozhat a szoftver telepítése és konfigurálása, a hibák kijavítása, amint azok előkerülnek, új funkciók hozzáadása a saját kizárólagos használatukra, valamint a rendszerük kezelése. A szoftvert fejlesztő munkatársak kiváló támogatási források. Valószínűleg ez a csapat már most is ingyenes támogatást nyújt azokon a fórumokon, ahol a szoftvert megvitatják. Így a támogatási modellben az ügyfél fizet a szállítónak, hogy telepítse a nyílt forráskódú szoftvert az ügyfél hardverére (ezt nevezik self-hosting disztribúciónak), vagy hozzáférést kap a szoftverhez a szállító hardverén (felhőalapú modell). A támogatási szerződések biztosítják, hogy az ügyfelek időben

segítséget kapjanak a vállalattól a bonyolultabb igényeikhez. Az ezt a modellt alkalmazó vállalatok általában előfizetéseket kínálnak, amelyekért az ügyfelek rendszeresen fizetnek. A szabadalmaztatott szoftverek egy másik üzleti modellje valójában egy sor egymást átfedő modell az úgynevezett freemium, amelyet 2009-ben a szerző és szerkesztő Chris Anderson népszerűsített, és amely egy sokkal régebbi üzleti modellen, a razor and blades-en (borotva és pengék) alapul. A razor and blades modellben az ügyfelek nagyon keveset fizetnek az alaptermékért (mint egy borotváért vagy egy nyomtatóért), majd felárat fizetnek a szükséges, Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 157 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek elhasználódásra tervezett alkatrészekért (pengék a borotvához, tintapatronok a nyomtatóhoz). A freemium modellben az ügyfelek egy

bizonyos szinten ingyenesen használhatják a terméket, és arra ösztönzik őket, hogy fizessenek a további funkciókért, ha hasznosnak találják a terméket. Bizonyára ismerjük azokat az online híroldalakat, amelyek bizonyos számú ingyenes cikket kínálnak, és arra kérik az olvasókat, hogy a teljes hozzáférésért fizessenek elő; ez a freemium modell jól ismert példája. Egy másik példa egy olyan játékplatform, amely az alapjátékot ingyenesen biztosítja, de pénzt kér az egyes eszközökért. Más szabadalmaztatott szoftvercégek a freemium modelljüket az időre alapozzák: három hónapig ingyenesen ki lehet próbálni a szoftvert, majd fizetni kell a további használatért. A szabadalmaztatott szoftvercégek néha a freemium modell egy változatát használják, amelyet open core néven ismerünk. Az open core esetében bizonyos alapfunkciók (a termék “magja” (core)) nyílt forráskódúak, és a további saját fejlesztésű funkciók

licencelhetők. Gyakran előfordul, hogy a nyílt rész teljesen működőképes, de kutatók vagy az egyéni felhasználók számára működik a legjobban, és nehezen kezelhetővé válik, ha sokan megosztják azt egy vállalaton belül. Ezért a védett funkciók tartalmazhatnak kényelmes webes felületeket az adminisztrációhoz, számviteli és együttműködési eszközöket, valamint egyéb, a nagy létesítmények számára különösen érdekes dolgokat. Még ha a nyílt üzleti modellek némi nyílt forráskódú szoftvert is használnak, az ügyfelek elég okosak ahhoz, hogy felismerjék, hogy az egész termék tulajdonképpen védett. Így, bár a nyílt magnak megvan az az előnye, hogy meglévő nyílt forráskódú projektre épül, a nyílt forráskódú szoftverek egyéb előnyeit nem biztosítja. Az open core üzleti modell nem épít bizalmat az ügyfelekkel, nem ösztönzi őket arra, hogy hozzájáruljanak az alapszoftverhez, nem ad hozzáférést az ügyfeleknek

a kód vizsgálatához, nem épít ki a fő vállalaton kívüli képzett fejlesztők hálózatát, és nem működik iparági szabványként. Még rosszabb, hogy az open core fejlesztési modellnek ugyanazok a fejlesztési költségei vannak, anélkül, hogy olyan előnyökkel járna, amelyek miatt megérné. Azok a vállalatok, amelyek kipróbálják az open core üzleti modellt, általában csalódnak az eredményekben, és sokan később áttérnek a tisztán szabadalmaztatott modellre. A vállalatok nyílt forráskódú vagy jogvédett kódbázisra is építhetnek webszolgáltatást, a Software as a Service (SaaS) modellben. Az ügyfelek pedig havi vagy éves alapon fizetnek Sok SaaS webes szolgáltatást nyújtó vagy mobilalkalmazásokat kínáló vállalat a hirdetéseken keresztül keres pénzt. Egyes vállalatok a szolgáltatáson vagy alkalmazáson keresztül adatokat is gyűjtenek a felhasználókról, és ezeket az adatokat harmadik feleknek adják el, akik azokat

reklámozásra használhatják. A reklámok azonban idegesítőnek is tekinthetők Az adatok értékesítése ellentmondásos, és egyes országok korlátozzák az adatgyűjtést. 158 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek Végezetül a vállalatok fejleszthetnek és kiadhatnak nyílt forráskódú szoftvereket anélkül, hogy egyáltalán megpróbálnának bevételre szert tenni belőlük. Ez a modell olyan vállalatok számára elérhető, amelyek a szoftveren kívül más dolgokból is bevételre tesznek szert. Például az autógyárak együttműködnek, hogy nagy mennyiségű szabad szoftvert hozzanak létre, amelyek az autóikban futnak (amelyek ma már igen csak komputerizáltak). Azok a nagy szoftvercégek, amelyek bevételeiket saját fejlesztésű ajánlatokból szerzik, mint például a Google és az Amazon, néha nyílt forráskódú szoftvereket

vagy más hasznos eszközöket adnak ki, mivel ezek a nyílt forráskódú eszközök nem játszanak központi szerepet az alaptevékenységükben. Azok a szervezetek, amelyek nyílt licenc alatt adják ki a kódot, profitálnak a nyílt forráskódú közösség által nyújtott visszajelzésekből, hibajelzésekből és funkciófejlesztésekből. Nyílt forráskódú szoftverek használata más technológiákban és szolgáltatásokban Sok vállalat épít be nyílt forráskódú szoftvereket termékeibe vagy webes platformjaiba. Elvégre a nyílt forráskódú szoftverek ingyenesek! De nem ez a legfontosabb (és talán nem is a legjobb) ok az adaptálásukra. Sokkal fontosabb, hogy sok ilyen szoftver kiváló minőségű (bár a fejlesztőcsapatnak alaposan át kell vizsgálnia, mielőtt implementálná), és akár iparági szabvány is lehet. A nyílt forráskódú szoftverek másik előnye, hogy akkor is elérhetőek maradnak, ha a fejlesztők vagy az őket körülvevő

közösség megszűnik. A szabad és nyílt forráskódú szoftverek azonban felelősséggel járnak. Ebben a szakaszban röviden felsoroljuk a legfontosabb kérdéseket, amelyeket figyelembe kell venni, mielőtt adaptálnánk. Az első kérdés minden olyan harmadik féltől származó szoftverre vagy eszközre vonatkozik, amelynek adaptálását fontolgatják: megfelel-e a felhasználók igényeinek most és a vállalat fejlődése során? Támogatja-e a szoftvert egy erős közösség, amely technikai támogatást tud nyújtani és továbbfejleszti a szoftvert? Vannak-e a szoftverben jelentős biztonsági rések? Ezután a vezetőségnek mérlegelnie kell a vállalat felelősségét, ha egy nyílt forráskódú projektet beépít a saját szoftverébe. Ha a fejlesztők új kódot építenek a nyílt forráskódú kód köré, akkor ellenőrizniük kell, hogy a nyílt forráskódú szoftver licencének értelmében mit kell tenniük. Egyes licencek megkövetelik a fejlesztőktől,

hogy a saját változtatásaik forráskódját ugyanolyan szabad licenc alatt osszák szét a végfelhasználók között, mint az eredeti kódbázist. Még ha egy fejlesztőnek nem is kell a módosított forráskódját terjesztenie, és a nyílt forráskódra építve egy saját terméket hoz létre, lehet, hogy bizonyos dolgokat vissza akar adni, például Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 159 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek hibajavításokat és fejlesztéseket a nyílt forráskódhoz. Azzal, hogy a fejlesztő hozzájárul ezekhez a javításokhoz és fejlesztésekhez, lehetővé teszi, hogy a projekt beépítse azokat (ha a fő fejlesztők úgy döntenek, hogy így tesznek) és karbantartsa őket. Azoknak a fejlesztőknek, akik nem járulnak hozzá visszaadással a fejlesztésekhez, esetleg újra kell csinálniuk a javításokat és fejlesztéseket minden alkalommal,

amikor az eredeti kód új verziójára frissítenek. Emiatt a függőség miatt és más okokból is a vállalat munkatársainak fontolóra kell venniük, hogy aktív tagjai legyenek a kódot fejlesztő közösségnek. A fejlesztők a részvétel révén sokat tanulhatnak a kódról, és segíthetnek meghatározni a jövőbeli fejlesztés irányát. Természetesen a szervezetnek fizetnie kell a fejlesztők közösségi tevékenységekkel töltött idejéért. Egy olyan vállalat számára, amely komolyan gondolja a szabad szoftverek használatát, ez nincs ingyen. A nyílt forráskódú szoftverek szempontjai az ügyfél szemszögéből A nyílt kód több okból is nagyon előnyös az ügyfelek számára, de más kapcsolatra van szükség a vállalat és az ügyfelek között. Az ügyfeleknek meg kell érteniük a kapcsolat előnyeit és következményeit is. A leckében korábban említett fő előnye az ügyfél számára az, hogy jobban megbízhat a szoftverben. Tudják, hogy az

nem fog eltűnni Sok szabadalmaztatott cég bezár vagy hirtelen új irányba indul el, magára hagyva az ügyfeleket, akiknek talán csak rövid idő áll rendelkezésükre, hogy áttérjenek egy olyan termékre, amelyet esetleg nem szeretnek. A nyílt forráskódú szoftver ezzel szemben nem függ egyetlen szervezettől sem. Ha a projekt számít, a közösségben más emberek folytatják a projektet, amikor az eredeti fejlesztők továbblépnek. Az ügyfelek ellenőrizhetik a nyílt forráskódú szoftverek minőségét és biztonságát is. Megállapíthatják, hogy mennyire könnyen tudnak saját funkciókat hozzáadni vagy átportolni egy új környezetbe. Mivel egy nyílt forráskódú projekt forráskódja mindenki számára hozzáférhető, a fejlesztők széles köre megismerkedhet vele. Egy olyan projektnél, amelynek aktív közössége van, sokan nyújtanak támogatást a fórumon. Gyakran könnyű felvenni embereket a szoftver támogatására vagy a szoftver vállalaton

belüli adminisztrálására és használatára, mivel az új alkalmazottak már ismerik a kódot. Nagyon megnyugtató az ügyfelek számára, akiknek a mindennapi működése függ a kódtól, ha tudják, hogy egy hibát saját maguk is kijavíthatnak, vagy alkalmazhatnak valakit, hogy ezt megtegye. Egy homályos, csak néhány ügyfelet érintő hiba kijavítása évekig is eltarthat, mire a fejlesztőcsapat kijavítja, ami a zárt forráskódú szoftverek felhasználóinak állandó frusztrációt okoz. Ráadásul, ha a forráskód elérhető, a hiba és a javasolt javítás gyorsabban azonosítható 160 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek Mi a helyzet a vállalat és az ügyfél közötti kapcsolattal? A vállalat dönthet úgy, hogy pontosan olyan kapcsolatot alakít ki, mint amilyet egy tipikus saját szoftvergyártó cég kínál, rendszeres

frissítéseket és támogatási szerződést biztosítva az ügyfélnek. Az ügyfélnek soha nem kell megnéznie a forráskódot, vagy csatlakoznia a közösségi fórumokhoz. A legtöbb ügyfél azonban profitálna a nyílt forráskódú projektek által kínált egyedülálló lehetőségekből. Lehetővé tehetik saját fejlesztőik számára, hogy mind az információkkal, mind a kóddal hozzájáruljanak a munkához. Az ilyen részvétel elmélyíti munkatársaik ismereteit, segít nekik új embereket toborozni, és beleszólást biztosít számukra a jövőbeli fejlesztésekbe. Költségstruktúrák és beruházások A programozók iránt nagy a kereslet, így minden szoftveres erőfeszítés drága lesz. A nagyobb nyílt forráskódú projektek ismerői még keresettebbek, mivel ezeket a kódbázisokat széles körben használják. Egy nyílt forráskódú projekt potenciális költségmegtakarítást tesz lehetővé, mivel a különböző szervezetek és magánszemélyek

közös kódbázisban egyesíthetik erőfeszítéseiket. Egy ilyen projekt működtetése azonban új költségeket is okoz. Ha egy vállalat megnyit egy saját fejlesztésű projektet, a vállalatnak be kell fektetnie abba, hogy az egy nagyobb (esetleg világméretű) közösséget szolgáljon ki. Egyes funkciókat, amelyek a vállalat szűk üzleti igényeinek feleltek meg, esetleg újra kell gondolni, hogy más vállalkozásoknak is megfeleljenek. Ha a kód rossz vagy zavaros, a vállalatnak valószínűleg nem kellene nyílttá tennie. A potenciális közreműködőket és a potenciális ügyfeleket egyaránt befolyásolja a minőség. A fejlesztőknek amúgy is javítaniuk kell ezeket a problémákat, mert a rosszul kódolt szoftver törékeny: nehéz új funkciókkal frissíteni, és olyan összetett hibák alakulhatnak ki benne, amelyeket nehéz kijavítani. Ezeket a problémákat nevezzük technikai adósságnak (technical debt), és minél hamarabb kijavítják őket, annál

jobb minden felhasználónak. Végezetül pedig meglepő lehet, hogy milyen gyakran fordul elő, hogy egy vállalat üzleti titkokat, jelszavakat, személyekre való személyes utalásokat vagy más érzékeny információkat ágyaz be a kódba. A fejlesztőknek időt kell fordítaniuk az ilyen sebezhetőségek eltávolítására A jelszavaknak, API-kulcsoknak, tanúsítványoknak és felhő-hozzáférési hitelesítő adatoknak amúgy sem szabadna a kódban lenniük; ezeket külsőleg, egy biztonságos szolgáltatáson keresztül kell kezelni. Tegyük fel, hogy egy vállalat nyílttá tette a kódját, és azt reméli, hogy a külső hozzájárulásokból haszonra tehet szert. Egyes ügyfelek fizetnek a fejlesztőknek a karbantartásért és az új funkciókért. Mások a saját fejlesztőiket fogják a projektre küldeni, de az alap fejlesztőcsapatnak Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 161 Open Source Essentials (Version 1.0) |

Témakör 054: Nyílt forráskódú üzleti modellek időt kell szánnia a támogatásukra. Az alap fejlesztőcsapatnak a külsősöket is oktatni kell a kódról és a kapcsolódó kódolási szabványokról. Ennek a csapatnak kell irányítania a külső közreműködőket is, hogy mit kell hozzáadniuk, és hova kell visszaküldeniük a kódjukkal kapcsolatos megjegyzéseket. Vegyük észre a tehetségesnek mutatkozó kívülállókat! Ezek az egyének értékes tagok lehetnek az alapcsapatban. Lehet, hogy szívesen csatlakoznak a csapathoz, és jelentős tudással rendelkeznek Ha egy fejlesztőcsapat fizetést kap, míg mások önkéntes munkát végeznek, az önkéntesek úgy érezhetik, hogy kihasználják őket, vagy megkérdezhetik, miért kellene segíteniük. Minden egyes közreműködőnek, legyen az egyéni önkéntes vagy szervezet, át kell esnie a leckében korábban leírt gondolkodási típusokon, hogy eldöntse, miért vesz részt a folyamatban. A szabad kód nem

ingyenes, még akkor sem, ha nem jár licencköltséggel. Egyszerűen csak egy másik fejlesztési modellről van szó. 162 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek Gyakorló feladatok 1. Hogyan növeli a nyílt forráskód az ügyfelek szoftverbe vetett bizalmát? 2. Miért csábítják a vállalatokat, hogy kipróbálják az open core üzleti modellt, és miért nem hozza a modell a nyílt forráskódú szoftverek előnyeit? 3. Mi a saját hosztolású terjesztés (self-hosted distribution)? 4. Milyen típusú segítséget nyújtanak általában a fejlesztők a nyílt forráskódú projektjeikben közreműködő külsősöknek? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 163 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Gondolkodtató feladatok 1. Fontolgatjuk, hogy egy

nyílt forráskódú projektre egy zárt forráskódú terméket alapozunk Milyen tényezőket vegyünk figyelembe a döntés meghozatala során? 2. Több, előfizetési díjas terméket építettünk egy nyílt forráskódú projektre Mit kell tennünk, ha a nyílt forráskódú licenc megköveteli, hogy az összes kódunkat visszaadjuk a projektnek? Néhány új kommunikációs protokoll támogatását is hozzáadtuk a nyílt forráskódú projekthez, hogy megfeleljen a saját igényeinknek. Ha van lehetőségünk rá, megkérjük-e a nyílt forráskódú projektet, hogy integrálja ezt a protokolltámogatást a kódbázisba? 164 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek Összefoglalás Ebben a leckében meganultuk a forráskód nyílttá tételének az értékét. Áttekintettük a ma használatos általános üzleti modelleket, valamint azt, hogy miért

fontos megérteni a kód licencének a hatását. Olvastunk a nyílt forráskódnak a vállalkozásába való beépítésével kapcsolatos megfontolandó kérdésekről, valamint arról, hogy a nyílt forráskód milyen előnyökkel jár az ügyfeleink számára. Azt is megtudtuk, hogy a nyílt forráskódú fejlesztés költségei miben térnek el a védett szoftverek költségeitől. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 165 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Válaszok a gyakorló feladatokra 1. Hogyan növeli a nyílt forráskód az ügyfelek szoftverbe vetett bizalmát? Az ügyfelek ellenőrizhetik a kód minőségét és biztonságát. Abban is bízhatnak, hogy továbbra is használhatják a kódot, ha az eredeti fejlesztők nem támogatják azt tovább. 2. Miért csábítják a vállalatokat, hogy kipróbálják az open core üzleti modellt, és miért nem hozza a modell a

nyílt forráskódú szoftverek előnyeit? Első pillantásra úgy tűnik, hogy a nyílt magnak a nyílt forráskódú szoftverek összes előnyét kínálnia kell, miközben lehetővé teszi a vállalat számára, hogy továbbra is saját üzleti modellt használjon, amely licencet ad el a szoftver használatára. A gyakorlatban az open core üzleti modell nem nyújtja a nyílt forráskódú szoftverek előnyeit, miközben fennállnak a nyílt fejlesztés megnövekedett költségei is. 3. Mi a saját hosztolású terjesztés (self-hosted distribution)? A saját hosztolású disztribúció a szoftver olyan verzióját jelenti, amely az ügyfél saját eszközein futtatható. 4. Milyen tipikus segítséget nyújtanak általában a fejlesztők a nyílt forráskódú projektjeikben közreműködő külsősöknek? Egy projekt fejlesztői általában oktatják és mentorálják a külső közreműködőket, és ellenőrzik, hogy hozzájárulásuk megfelel-e a csapat minőségi és

kódolási szabványainak. 166 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0541 Szoftverfejlesztési üzleti modellek Válaszok a gondolkodtató feladatokra 1. Fontolgatjuk, hogy egy nyílt forráskódú projektre egy zárt forráskódú terméket alapozunk Milyen tényezőket vegyünk figyelembe a döntés meghozatala során? Először is döntsük el, hogy a nyílt forráskódú szoftver megfelel-e az igényeinknek! Ellenőrizzük a minőségét, a nyilvánosan bejelentett biztonsági hibákat és a szoftvert körülvevő közösség állapotát! Alaposan nézzük meg a licencet, hogy szükséges-e megosztanunk a kódon végzett módosításainkat! Határozzuk meg, hogy mennyire szeretnénk részt venni a nyílt forráskódú projekt közösségében, és hogyan határozzuk meg a fejlesztők szerepét ebben a körben! 2. Több, előfizetési díjas terméket építettünk egy nyílt forráskódú

projektre Mit kell tennünk, ha a nyílt forráskódú licenc megköveteli, hogy az összes kódunkat visszaadjuk a projektnek? Néhány új kommunikációs protokoll támogatását is hozzáadtuk a nyílt forráskódú projekthez, hogy megfeleljen a saját igényeinknek. Ha van lehetőségünk rá, megkérjük-e a nyílt forráskódú projektet, hogy integrálja ezt a protokolltámogatást a kódbázisba? Ha a projekt nem követeli meg, hogy megosszuk a kódváltozásokat, akkor valószínűleg ezt nem fogjuk megtenni, mert egy jogvédett termék esetében könnyebben felszámíthatunk előfizetési díjat. Ha mégis meg kell osztanunk a kódot, kínáljunk előfizetést egy saját üzemeltetésű disztribúcióra. Még ha nem is kell megosztani a kódot, valószínűleg meg szeretnénk kérni a projektet, hogy integrálja a kommunikációs protokollok támogatását, hogy ne kelljen minden alkalommal implementálnunk a támogatást, amikor a nyílt forráskód új verzióját

telepítjük. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 167 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek 054.2 Szolgáltatói üzleti modellek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0542 Súlyozás 2 Kulcsfontosságú ismeretek • A nyílt forráskódú szoftverekhez és nyílt tartalmakhoz kapcsolódó szolgáltatásokat nyújtó szervezetek általános üzleti modelljeinek és bevételi forrásainak megértése • A licencek szolgáltatói üzleti modellekre gyakorolt hatásának megértése • A szolgáltatási szintű célkitűzések és a szolgáltatási szintű megállapodások megértése • A biztonság és az adatvédelem szükségességének megértése • A nyílt forráskódú szoftverek szolgáltatási üzleti modelljeihez szükséges költségszerkezetek és beruházások ismerete A használt fájlok, kifejezések és

segédprogramok listája • Hostolt szolgáltatások • Felhő • Tanácsadás • Képzés • Hardver értékesítés • Felhasználói támogatás • Terms of Service (ToS) • Service Level Objectives (SLO) 168 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek • Service Level Agreements (SLA) • Adatfeldolgozási megállapodások Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 169 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 054 Nyílt forráskódú üzleti modellek Fejezet: 054.2 Szolgáltatói üzleti modellek Lecke: 1/1 Bevezetés A szolgáltatók (service provider) jelentik a gerincét minden olyan vállalatnak vagy szervezetnek, amely bármilyen módon hálózaton keresztül működik. A

globális internethez való hozzáférést biztosító internetszolgáltatótól (Internet Service Provider ISP) kezdve az olyan speciális alkalmazásokig, mint az e-mail vagy az ügyfélkezelés, a szoftveralapú szolgáltatások teszik lehetővé a tényleges üzleti tevékenységet. A nyílt forráskódú szoftverek számos különböző szolgáltatói üzleti modell részét képezik. Például egy nyílt forráskódú operációs rendszer képezheti egy tárhelyszolgáltatási üzletág alapját. Egy nyílt forráskódú orchesztrációs eszköz lehet egy Infrastructure-as-a-Service (IaaS) vagy Platformas-a-Service (PaaS) vállalkozás, például egy nyilvános felhőszolgáltató vagy konténerplatform gerince. Egy nyílt forráskódú alkalmazást online Software-as-a-Service-ként (SaaS) lehetne elérhetővé tenni. Egyes szolgáltatók a nyílt forráskódú szoftverekhez kapcsolódó kiegészítő szolgáltatásokat is kínálnak, például tanácsadást, képzést vagy

ügyféltámogatást. Bevételi források Ha a szolgáltatás teljes egészében vagy nagy részben nyílt forráskódú szoftveren alapul, akkor azt 170 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek nyitott forráskódú üzleti modellnek (open source business model) nevezhetjük. Mivel a nyílt forráskódú szoftverek díjfizetés nélkül letölthetők és használhatók, a nyílt forráskódú szolgáltatási üzleti modellek sajátos termékeket és szolgáltatásokat alakítottak ki, többek között attól függően, hogy a tényleges termékben mekkora a szabad szoftverek aránya. Ha a teljes szoftver szabad licenc alatt áll, az üzleti modell lehet a hosting, azaz a szoftver megbízható és biztonságos platformon való rendelkezésre bocsátása. Ez kiküszöböli az ügyfelek saját szerverek üzemeltetésével járó erőfeszítéseket és kockázatokat.

Cserébe az ügyfelek használati díjat fizetnek a szolgáltatónak. A díjakat a felhasználói fiókok számához, a tárolt vagy továbbított adatok mennyiségéhez vagy bizonyos időintervallumokhoz lehet kötni. Egyes esetekben több különböző szolgáltató is kínál fizetős szolgáltatásokat ugyanahhoz a nyílt forráskódú szoftverhez. Ez a népszerű üzleti modell gyakran foglal magába előfizetéseket (subscription), ahol az ügyfelek havi vagy éves díjat fizetnek a szolgáltatáshoz való hozzáférésért. A hozzáférést gyakran további szolgáltatásokkal vagy funkciókkal kombinálják. A szolgáltatók több előfizetési szintet is kínálhatnak, magasabb díjat kérve a több funkcióért, több felhasználóért, átfogóbb szolgáltatásokért vagy erősebb megbízhatósági garanciáért. Egyes szolgáltatók a szolgáltatás egy alapszintjét ingyenesen is kínálhatják, ami a “freemium” modell egyik változata. A nyílt forráskódú

szolgáltatók üzleti modelljének másik népszerű bevételi forrása mindig is a támogatás (support) nyújtása volt. A support magában foglalja a tanácsadást, a dokumentációt és a képzést a felhasználók számára, akiknek problémáik vannak a szoftver használatával. Ha az ügyfél inkább a saját szerverén hosztolja az ingyenes szoftvert, különösen a telepítés gyakran nehézségekbe ütközhet, mert a felhasználónak esetleg más támogató eszközöket és könyvtárakat is telepítenie kell. Az is lehet, hogy nem tudja, hova tegye őket, hogy minden rész működjön, vagy problémákba ütközhet az adott hardveren és operációs rendszeren. Ezért értékes a szolgáltató által nyújtott támogatás és képzés. Extra szolgáltatások, például további funkcionális vagy biztonsággal kapcsolatos jellemzők szintén fejleszthetők és biztosíthatók ügyfélspecifikusan. A szoftver ilyen funkciói vagy az ügyfél nagyon speciális igényeihez

való igazítása az üzleti modell kifinomult és jövedelmező kiegészítője. Ezután a szolgáltató és az ügyfél dönti el, hogy a kiegészítések szabad szoftverként visszaáramlanak-e az alapprojektbe, vagy védetté válnak. Néhány nyílt forráskódú projekt kettős licencmodellt kínál. A szoftver szabad szoftverlicenc alatt érhető el, ami sok felhasználó igényeit szolgálja ki. Néhány felhasználó azonban be akarja építeni a szoftvert egy védett termékbe, ami kölcsönös licenc alatt nem lehetséges. Ezért ezeknek a felhasználóknak egy szabványos, szerzői jogi alapú licencet biztosítanak. A kettős licencmodell az adatbázisok esetében a leghatékonyabb, mivel sok vállalat szeretne egy saját szoftvertermék részeként egy funkciógazdag és hatékony adatbázist kínálni. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 171 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti

modellek A reklámbevételi modellben (advertising revenue model) az ügyfelek nem fizetnek a szolgáltatáshoz való hozzáférésért. Ehelyett a szolgáltató hirdetéseket jelenít meg a szolgáltatást használó ügyfelek számára, és a hirdetések elhelyezéséért a vállalatoknak számol fel díjat. A nyílt forráskódú szolgáltatók a felhasználók adatvédelmével kapcsolatos aggályok miatt gyakran kerülik a saját hirdetési szolgáltatások használatát. Az alternatív nyílt forráskódú hirdetési szolgáltatások azonban nem vesznek részt invazív reklámkövetésben. A jutalékalapú modellben (comission-based model) a szolgáltató százalékos arányban vagy díjban részesül az online szolgáltatásán keresztül lebonyolított tranzakciók kezeléséért. Ez a modell az alapja a legtöbb e-kereskedelmi oldalnak, utazási foglalási oldalnak és fizetéseket feldolgozó felületnek. Számos nyílt forráskódú projekt ezen a területen olyan

általános célú platform, amelyet vagy a szolgáltató saját maga hosztol, vagy másodlagos jutalékalapú szolgáltatásként kínál, ahol az ügyfél által használt weboldal százalékot vagy díjat fizet a nyílt forráskódú platform hosztolt változatáért. A nyílt tartalom üzleti modell (open content business model) magában foglalja a tartalom létrehozását és terjesztését olyan licencek alapján, mint például a Creative Commons, hogy mások szabadon használhassák, módosíthassák és megoszthassák azt. A felhasználókat arra ösztönzik, hogy hozzájáruljanak a tartalomhoz, és idővel javítsák azt. Míg maga a tartalom ingyenes, a bevételt kiegészítő termékekkel vagy szolgáltatásokkal lehet előteremteni, például adományokkal, hirdetések megjelenítésével, freemium funkciók kínálásával, kapcsolódó termékek értékesítésével, illetve tanácsadás, képzés vagy támogatási szolgáltatások nyújtása révén. Választás a

hosztolt és a saját üzemeltetésű szolgáltatások között A hosztolt szolgáltatások ideálisak azon szervezetek számára, amelyek az egyszerű használatot, az alacsonyabb kezdeti költségeket, a skálázhatóságot és a professzionális biztonsági menedzsmentet keresik anélkül, hogy mélyreható műszaki szakértelemre lenne szükségük. Ezek a szolgáltatások azonban potenciális hátrányokkal járnak az ellenőrzés, a testreszabhatóság, az adatvédelem és a szolgáltatótól való függőség tekintetében. A hosztolt szolgáltatások általában minimális telepítést igényelnek, és a szolgáltató gondoskodik a karbantartásról, a frissítésekről és a rendszer biztonságáról. Gyakran globális adatközpontokat tesznek elérhetővé, így jobb teljesítményt és megbízhatóságot biztosítanak a nemzetközi felhasználók számára. A szolgáltatók az ügyfelek minimális erőfeszítései mellett képesek az erőforrásokat az igények alapján fel-

vagy lefelé skálázni. A hosztolt szolgáltatások emellett gyakran rendelkeznek külön biztonsági csapatokkal a fenyegetések kezelésére és az azokra való reagálásra, és a szolgáltatók különböző szabályozási előírásoknak való megfelelést is kínálhatnak. Másrészt a hosztolt szolgáltatások az ügyfelek érzékeny adatait off-premise módon tárolják, ami aggályokat vethet fel az adatvédelemmel és a bizalommal kapcsolatban. A megosztott 172 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek tárhelykörnyezet további biztonsági kockázatokat jelenthet. A szolgáltató kiesése vagy leállása közvetlenül befolyásolja az ügyfél szolgáltatásának rendelkezésre állását. Az egyetlen szolgáltatótól való függés problémás lehet, ha a szolgáltató megváltoztatja a feltételeket vagy megszünteti a szolgáltatást. A saját

üzemeltetésű szolgáltatások így olyan szervezetek számára alkalmasak, amelyek rendelkeznek az infrastruktúrájuk kezeléséhez szükséges műszaki szakértelemmel és erőforrásokkal. Az önálló hosztolás azonban magasabb kezdeti költségekkel, folyamatos karbantartással és skálázhatósági kihívásokkal jár. A hosztolt és a saját üzemeltetésű szolgáltatások közötti választás végső soron az egyes ügyfelek igényeitől, technikai képességeitől, költségvetésétől, valamint az ellenőrzésre, testreszabásra és adatvédelemre vonatkozó prioritásoktól függ. A licencek hatása Alapvetően a nyílt forráskódú szoftverlicencek jól működnek a szolgáltatók üzleti modelljeivel, mivel az ügyfélnek nem kell a szolgáltatást nyújtó szoftver tulajdonosának lennie, ehelyett a szolgáltatáshoz való hozzáférésért fizet. Másrészt a nyílt forráskódú szoftverek használata olyan szolgáltatásokban, mint az IaaS, SaaS vagy PaaS,

gyakran tisztázatlan jogi kérdéseket vet fel. Csak néhány licenc, nevezetesen a GNU Affero General Public License szabályozza kifejezetten a szabad szoftverek használatát “hálózati szerverszoftverek esetében”. Más népszerű licencek akár a szigorúbb copyleft licencek, mint például a GNU General Public License, akár az olyan megengedő licencek, mint a BSD licencek esetében mérlegelési lehetőség van arra vonatkozóan, hogy mi tekinthető “másolásnak” (copying), “átruházásnak” (conveying) vagy “terjesztésnek” (distribution), amikor a szoftvert a hálózaton keresztül használják. Az ilyen meghatározásoktól függnek a hozzárendelési követelmények vagy az, hogy a forráskódot hozzáférhetővé kell-e tenni az alkalmazás számára, és ha igen, milyen formában. A védett szoftverkomponensekkel való kapcsolatot vagy a saját fejlesztésű kiegészítő komponensek licencelését jogilag szintén tisztázni kell. Ezen okokból

kifolyólag a szolgáltatók üzleti modelljeivel összefüggésben alapvető fontosságú a szabad szoftverek használatával kapcsolatos licencelési kérdések tisztázása. Jó gyakorlat, hogy a szolgáltatók nyilvánosan felsorolják az összes általuk használt nyílt forráskódú szoftvert és a hozzájuk tartozó licencet, még akkor is, ha erre nem kötelesek. Biztonsági és adatvédelmi megfontolások A szolgáltatói üzleti modell sikere nagymértékben függ a kielégítő ügyfélélménytől, különösen a Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 173 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek nyílt forráskódú szoftverek esetében, ahol az ügyfelek szabadon választhatják meg a szoftver saját tárhelyét, vagy választhatnak egy konkurens szolgáltatót ugyanahhoz a szoftverhez. Így a nyílt forráskódú szolgáltatók legfőbb versenyelőnye az általuk kínált

ügyfélélmény, amely lehet kényelmesebb, költséghatékonyabb, megbízhatóbb, biztonságosabb vagy teljesítőképesebb, mint a saját hosztolás. Ennek ellentételezése azonban az, hogy az ügyfeleknek meg kell osztaniuk az adatokat a szolgáltatóval, ami adatvédelmi aggályokat vethet fel a személyes vagy érzékeny adatok esetében. A biztonság érdekében az ügyfeleknek meg kell győződniük arról, hogy a szolgáltató megbízható eljárással rendelkezik a biztonsági javítások azonnali alkalmazására. Érdemes értékelni, hogy a szolgáltatás hogyan kezeli a más nyílt forráskódú projektektől való függőségeket, hogy biztosítsa az összes szoftver naprakészségét és biztonságát. Az ügyfélnek értékelnie kell a szolgáltató biztonsági irányelveit is, beleértve azt is, hogyan kezelik az adattitkosítást, a hozzáférésellenőrzést és az incidensek kezelésére vonatkozó intézkedéseket. A nyílt forráskódú szoftverek

átláthatósága lehetővé teszi, hogy a közösség alaposan felülvizsgálja a kódot, ami a sebezhetőségek azonosítása és javítása révén növelheti a biztonságot. Az ügyfeleknek tehát érdemes a szoftverek felülvizsgálatát vagy auditálását a közösségen belül elismert harmadik felek vagy biztonsági szakértők által végeztetni. Ezeknek az ellenőrzéseknek meg kell erősíteniük, hogy a szolgáltató a fejlesztési folyamat során a biztonságos kódolási gyakorlatokat és szabványokat követi, és figyelembe kell venniük, hogy a szolgáltató használ-e integrált biztonsági ellenőrzéseket tartalmazó CI/CD-csatornákat a sebezhetőségek korai észlelése érdekében. A magánélet védelme érdekében az ügyfeleknek meg kell győződniük arról, hogy a szolgáltatás csak a működéséhez szükséges adatokat gyűjti és tárolja, minimalizálva az adatok kiszolgáltatottságának kockázatát. A szolgáltatásnak erős módszerrel kell

titkosítania az adatokat mind a szállítás, mind a tárolás során. A hozzáférés-ellenőrzési mechanizmusoknak biztosítaniuk kell, hogy csak az arra felhatalmazott személyzet férhessen hozzá az érzékeny adatokhoz. Az ügyfélnek ellenőriznie kell, hogy a szolgáltatás biztosítja-e a felhasználók számára az adatok feletti ellenőrzést, például az adatok törlésének vagy exportálásának lehetőségét. A szolgáltatásnak meg kell felelnie a vonatkozó adatvédelmi szabályoknak, például az Európai Unió általános adatvédelmi rendeletének (General Data Protection Regulation GDPR) és a kaliforniai fogyasztói adatvédelmi törvénynek (California’s Consumer Privacy Act CCPA), és átláthatóságot kell biztosítania az adatkezelési gyakorlatáról. Fontos ellenőrizni, hogy a szolgáltató rendelkezik-e egyértelmű irányelvekkel és eljárásokkal az adatvédelmi incidensekre való reagálásra, beleértve az értesítési követelményeket is.

Az ügyfélnek át kell tekintenie a szolgáltató adatvédelmi szabályzatát is, hogy megértse, hogyan történik az adatok gyűjtése, felhasználása, megosztása és védelme, valamint figyelembe kell 174 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek vennie a szolgáltató által esetlegesen megosztott adatokat harmadik felekkel, és biztosítania kell, hogy ezek is tartsák be a szigorú adatvédelmi előírásokat. Általánosságban elmondható, hogy a közösségi visszajelzések és vélemények alapján érdemes felmérni a szoftver és a szolgáltató hírnevét és megbízhatóságát. Egy erős közösségnek vagy szervezetnek aktívan fenn kell tartania és támogatnia kell a nyílt forráskódú projektet. Az ügyfélnek meg kell győződnie arról, hogy a szolgáltató rendszeres adatmentési eljárásokkal és robusztus katasztrófa-helyreállítási

tervekkel rendelkezik-e, és ellenőriznie kell, hogy a szolgáltatás adatredundanciát alkalmaz-e a rendelkezésre állás és megbízhatóság biztosítása érdekében. A szolgáltatóknak tisztában kell lenniük azzal, hogy az ügyfelek értékelni fogják biztonsági és adatvédelmi gyakorlataikat, közösségi hírnevüket, a szabályozásoknak való megfelelésüket és az adatkezelés átláthatóságát, ezért lépéseket kell tenniük a legjobb gyakorlatok követésére. Gyakori megállapodások a szolgáltató és az ügyfél között A szolgáltatók általában olyan jogi feltételeket és megállapodásokat fogadnak el, amelyek a vállalat és ügyfeleik közötti kapcsolat jogi és működési gerincét képezik. Ezek a megállapodások segítenek az egyértelmű kommunikáció biztosításában, az elvárások, valamint felelősségek meghatározásában, és mindkét fél számára jogi védelmet nyújtanak. Egy szolgáltatás Szolgáltatási Feltételei (Terms of

Service ToS), más néven Általános Szerződési Feltételek (Terms and Conditions T&C) vagy Használati Feltételek (Terms of Use), jogi megállapodások a szolgáltató és a szolgáltatás ügyfelei vagy felhasználói között. A ToS meghatározza a szolgáltatás használatára vonatkozó szabályokat, felelősségi köröket és korlátozásokat. Mind a szolgáltatót, mind az ügyfelet védi azáltal, hogy egyértelműen meghatározza, hogy a felek mit tehetnek és mit nem tehetnek a szolgáltatás nyújtása vagy használata során. A ToS-megállapodás néhány gyakori eleme annak megerősítése, hogy a felhasználó beleegyezik a feltételek betartásába, az elfogadható viselkedésre és a tiltott tevékenységekre vonatkozó iránymutatásokba. Része még a felhasználók által létrehozott vagy feltöltött tartalmak tulajdonjogának részletezése, a fiók létrehozására, biztonságára és megszüntetésére vonatkozó információk, a konfliktusok

megoldására szolgáló választottbírósági vagy közvetítői eljárások, valamint a szolgáltató kártérítési felelősségének korlátozása. Az Adatvédelmi Szabályzat (Privacy Policy) egy olyan nyilatkozat, amely ismerteti, hogy a szolgáltató hogyan gyűjti, használja, tárolja és védi a felhasználói adatokat. Az adatvédelmi irányelvek néhány gyakori eleme a szolgáltató által gyűjtött adatok típusa és gyűjtési módszerei, az adatok felhasználásának módja, azok a feltételek, amelyek mellett a szolgáltató az adatokat harmadik felekkel megoszthatja, valamint a felhasználóknak az adataikkal kapcsolatos jogaira vonatkozó információk, mint például a hozzáférés, a korrekció és a törlés. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 175 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek A Szolgáltatási Szintű Megállapodás (Service Level Agreement SLA)

egy hivatalos, dokumentált megállapodás a szolgáltató és az ügyfél között, amely meghatározza a szolgáltatás elvárt szintjét, beleértve a konkrét teljesítménymutatókat, felelősségeket és elvárásokat. Az SLA meghatározza a szolgáltatásnyújtás szabványait, és egyértelmű keretet biztosít a szolgáltatási teljesítmény méréséhez és kezeléséhez. Az SLA néhány gyakori eleme a nyújtott szolgáltatások részletes leírása, a szolgáltatási teljesítményre vonatkozó konkrét célok, mint például az üzemidő és a válaszidő, a teljesítmény mérésének és jelentésének módszerei, a teljesítménycélok teljesítésének elmulasztása esetén alkalmazandó következmények, valamint az SLA felülvizsgálatára és frissítésére vonatkozó eljárások. A Szolgáltatási Szintű Célkitűzés (Service Level Objective SLO) a Szolgáltatási Szintű Megállapodás kulcsfontosságú eleme, amely mérhető célokat vagy célkitűzéseket

határoz meg a szolgáltatás teljesítményére vonatkozóan. Ezek a célkitűzések számszerűsítik a szolgáltató és az ügyfél közötti szolgáltatás elvárt szintjét, és azt szolgálják, hogy a szolgáltatás következetesen megfeleljen a megállapodásban rögzített előírásoknak. Az SLO-k néhány közös eleme tartalmazza a szolgáltató által a szolgáltatás teljesítményének értékeléséhez mérendő konkrét mérőszámokat (például üzemidő, válaszidő, megoldási idő és átviteli sebesség), az egyes teljesítménymérők kívánt vagy elvárt értékeit, a teljesítménymérők mérésére és nyomon követésére használt technikákat és eszközöket, a szolgáltatás konkrét összetevői vagy szempontjai, amelyekre az SLO kiterjed (például hardver, szoftver, hálózati összetevők vagy konkrét folyamatok), valamint a következmények vagy jutalmak, amelyek azon alapulnak, hogy a szolgáltatás teljesíti-e az SLO-kat vagy sem (például

pénzbüntetések, szolgáltatási kreditek vagy teljesítménybónuszok). Az Adatfeldolgozási Megállapodás (Data Processing Agreement DPA) a személyes adatok feldolgozásában részt vevő ügyfél (az adatkezelő) és a szolgáltató (az adatfeldolgozó) közötti szerződés. Az adatvédelmi megállapodás részletezi mindkét fél felelősségét és kötelezettségeit az adatvédelmi jogszabályoknak, például a GDPR-nek való megfelelés biztosítása érdekében. Egyes joghatóságokban a szolgáltató és az ügyfél közötti adatvédelmi megállapodás kötelező. Költségstruktúrák és beruházások A szolgáltatói üzleti modellben a legjelentősebb kiadások a szolgáltatások hosztolásához kapcsolódó állandó költségek, például a szerverhardverek beszerzése, az adatközpontok helyének kifizetése, a szerverek áramellátásához és hűtéséhez szükséges áram, a hálózati sávszélesség, valamint a telepítő és karbantartó személyzet

fizetése. Egyes szolgáltatóknak változó költségei is lehetnek a szoftverlicencek vagy harmadik féltől származó szolgáltatások tekintetében. Azok az ügyfelek, akik saját hosztolást választanak, ezeket a költségeket közvetlenül viselik. A nyílt forráskódú szoftverek választásával a szolgáltatók és az ügyfelek csökkenthetik vagy megszüntethetik a licencköltségeket a védett szoftverekhez képest, mivel a nyílt forráskódú szoftverek definíciójuk szerint nem számítanak fel díjat a szoftverlicencért. A nyílt forráskódú 176 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek szoftverek alkalmazása a szolgáltatások kialakításához a fejlesztési időt és erőforrásokat is megtakaríthatja, a közösség által irányított karbantartás és frissítések pedig csökkenthetik a hosszú távú költségeket. Fontos azonban

figyelembe venni a nyílt forráskódú szoftverek teljes tulajdonlási költségét (total cost of ownership TCO), beleértve a lehetséges támogatási, karbantartási és integrációs költségeket is. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 177 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Gyakorló feladatok 1. Nevezzünk meg néhány módszert, amellyel a szolgáltatók bevételre tehetnek szert anélkül, hogy a szolgáltatás felhasználóitól díjat kérnének! 2. Milyen okok miatt ajánlhatja fel egy szolgáltató a szoftverét az ügyfelek általi saját hosztolásra? 3. Miért adná ki egy szolgáltató a szoftverét a GNU Affero GPL licenc alatt? 178 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek Gondolkodtató feladatok 1. Mi az Elfogadható Használati Irányelv

(Acceptable Use Policy AUP)? 2. Mi az a végfelhasználói licencszerződés (End User License Agreement EULA)? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 179 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Összefoglalás Ez a lecke a nyílt forráskódú szoftverekre támaszkodó szolgáltatói üzleti modelleket és a különböző bevételi forrásokat tárgyalta, beleértve az előfizetési, hirdetési, óradíjas és jutalékalapú modelleket. Kiemelte a nyílt forráskódú szoftverlicencek hatását a szolgáltatókra, hangsúlyozva azok előnyeit és kötelezettségeit. Kitért a szolgáltatások biztonságával, adatvédelmével és megbízhatóságával kapcsolatos megfontolásokra, valamint a szolgáltatási feltételek (ToS), a szolgáltatási szintű megállapodások (SLA) és az adatfeldolgozási megállapodás (DPA) fontosságára is. 180 | learning.lpiorg | CC BY-NC-ND 4.0

alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0542 Szolgáltatói üzleti modellek Válaszok a gyakorló feladatokra 1. Nevezzünk meg néhány módszert, amellyel a szolgáltatók bevételre tehetnek szert anélkül, hogy a szolgáltatás felhasználóitól díjat kérnének! A szolgáltatás hirdetéseket kínálhat, amelyekért a hirdetők fizetnek. A szolgáltatás jutalékot számíthat fel azoknak az eladóknak, akik termékeket vagy szolgáltatásokat kínálnak az oldalon, például kiskereskedelmi vagy utazási szolgáltatásokat. A szolgáltató eladhatja az ügyfelek adatait, ami egy olyan gyakorlat, ami ellen sok ügyfél tiltakozna, és amit a szolgáltatási feltételekben (Terms of Service) ki kell fejteni. 2. Milyen okok miatt ajánlhatja fel egy szolgáltató a szoftverét az ügyfelek általi saját hosztolásra? A potenciális ügyfelek kipróbálhatják a szoftvert, hogy ellenőrizzék annak funkcióit és megbízhatóságát,

mielőtt a szolgáltatóval szerződnének. Az ügyfelek hibákat is találhatnak, és akár javításokat is javasolhatnak. 3. Miért adná ki egy szolgáltató a szoftverét a GNU Affero GPL licenc alatt? Az Affero GPL megköveteli, hogy más szolgáltatók a szoftveren végzett változtatásokat ugyanezen licenc alatt adják ki. Ez a rendelkezés megakadályozza, hogy a versenytársak kihasználják a szolgáltató előnyeit azzal, hogy néhány olyan fejlesztést adjanak hozzá, amelyeket saját maguknak tartanak fenn, majd a szolgáltatás saját verzióját az eredetinél jobbnak hirdetnék. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 181 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Válaszok a gondolkodtató feladatokra 1. Mi az Elfogadható Használati Irányelv (Acceptable Use Policy AUP)? Az Elfogadható Használati Irányelv (AUP) egy olyan szabályzat, amely meghatározza a

szolgáltatás elfogadható és elfogadhatatlan felhasználási módját, hogy megelőzze a visszaéléseket, és biztosítsa a biztonságos és megbízható környezetet. Az AUP néhány gyakori eleme tartalmazza a tiltott tevékenységek leírását, mint például a spammelés vagy a hackelés, a felhasználók kötelezettségeit a szolgáltatás felelősségteljes használatára, a jogsértések esetén a szolgáltató által hozható intézkedéseket, például a felhasználói fiók felfüggesztését, valamint a jogsértések bejelentésére és kezelésére vonatkozó eljárásokat. 2. Mi az a végfelhasználói licencszerződés (End User License Agreement EULA)? A végfelhasználói licencszerződés (EULA) egy jogilag védett szoftver szállítója és a végfelhasználó (nem vállalat vagy szervezet) közötti szerződés, amely a felhasználónak bizonyos feltételek mellett jogot biztosít a szoftver használatára. Az EULA-k néhány gyakori eleme tartalmazza a licenc

hatályát és korlátait (például személyes használat vagy nem átruházható licenc), a tiltott tevékenységeket (például visszafejtés vagy újraelosztás), a licenc megszüntetésének feltételeit, valamint a szellemi tulajdonjogok tulajdonjogát és védelmét. A teljesen nyílt forráskódú szolgáltatások nyílt forráskódú szoftverlicenccel helyettesítik a védett EULA-t. 182 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés 054.3 Compliance és kockázatcsökkentés Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0543 Súlyozás 3 Kulcsfontosságú ismeretek • Az licencek megfelelőségének biztosítása • Az licencekkel kapcsolatos információk karbantartásának megértése • A nyílt forráskódú programirodák koncepciójának megértése • A szerzői jog, a szabadalmak és a védjegyek

nyílt forráskódú üzleti modellekre gyakorolt hatásának megértése • A nyílt forráskódú üzleti modellekkel kapcsolatos jogi kockázatok ismerete • A nyílt forráskódú üzleti modellekkel kapcsolatos pénzügyi kockázatok ismerete A használt fájlok, kifejezések és segédprogramok listája • Software Composition Analysis (SCA) • Software Bill Of Materials (SBOM) • Software Package Data Exchange (SPDX) • OWASP CycloneDX • Open Source Program Offices (OSPO) • Termékgarancia • Termékfelelősség • Exportszabályok Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 183 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek • Az egyesülések és felvásárlások hatása 184 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés Lecke 1 Tanúsítvány: Open Source

Essentials Verzió: 1.0 Témakör: 054 Nyílt forráskódú üzleti modellek Fejezet: 054.3 Compliance és kockázatmérséklés Lecke: 1/1 Bevezetés Egy régi vicc a nyílt forráskóddal kapcsolatban azt mondja: “A szabad szoftverek nem ingyen vannak.” (Free software doesn’t come for free) Míg a szabad és nyílt forráskódú szoftverek nagyszerű innovációt és kreativitást tesznek lehetővé, a felhasználóknak és a fejlesztőknek számos szabálynak kell megfelelniük. Ez a lecke a nyílt forráskódú szoftverek megfelelőségével és kockázataival foglalkozik. Ez a lecke felsorolja a fejlesztők számára a licenceknek való megfeleléshez szükséges alapvető lépéseket, a nyílt forráskódú szoftverek használatának kockázatait, valamint a szervezet által használt szoftverek nyomon követésének és katalogizálásának módjait. Megnézzük, hogyan lehet ezeket a feladatokat irányelvekké alakítani és egy nyílt forráskódú programiroda

(Open Source Program Office OSPO) által támogatni. A nyílt forráskódú komponenseken alapuló szoftverek kiadásának követelményei Ha a szervezet belsőleg használja a szoftvert, a szabad és nyílt forráskódú szoftverlicenceknek Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 185 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek nincsenek követelményeik. A szervezet meghatározhatja saját szabályait a sebezhetőségek megelőzése, vagy annak biztosítása érdekében, hogy mindenki ugyanazokat az összetevőket használja, esetleg egyéb okokból. De ez már túlmutat ennek a leckének a keretein Minden olyan követelményt, amelyet a nyílt forráskódú licencek vagy maga a szervezet támaszt a szoftverek használatával szemben, dokumentálni kell, és a szervezetnek képzést kell biztosítania a szabályairól. Még ha a szervezet a webszerverén futtat is szoftvert, és olyan

szolgáltatásokat kínál, amelyekkel a szervezeten kívüli személyek kapcsolatba lépnek, a legtöbb szabad és nyílt forráskódú szoftverlicenc nem támaszt követelményeket. A GNU Affero Public License azonban a szolgáltatásként futó szoftverek esetében is megköveteli a copyleft követelmények betartását. Az egyes főbb szabad és nyílt forráskódú szoftverlicencek jogi követelményeit más leckékben már részletesen megvizsgáltuk, így ez a rész csak egy listát vázol fel azokról a lépésekről, amelyeket a fejlesztőknek és a menedzsereknek meg kell tenniük a megfelelés érdekében: Nyílt forráskódú komponensek ellenőrzése A szervezetnek világos irányelvekre és oktatásra van szüksége azzal kapcsolatban, hogy milyen nyílt forráskódú szoftvereket használjon, és hol építse be azokat a termékekbe. Az ilyen irányelvek kiterjednek a megfelelőségre, valamint más kérdésekre, például a biztonság garantálására és a szoftvert

fejlesztő közösségben való részvételre is. Az eredeti licenc megtartása a kódban A fejlesztők nem távolíthatják el a licencet az általuk használt komponensből. A licencnek a forráskódban való feltüntetése általában követelmény a licencben. Valójában a licenc eltávolítása plágiumnak minősülhet, mivel a fejlesztő úgy állítja be, mintha ő írta volna a kódot. A licenc eltávolítása később komoly bajokhoz is vezethet, mert a szervezet megsértheti a licencet, amikor a kódot beépíti a termékeibe. A licencek nyomon követése A szervezetnek katalógust kell vezetnie, amely listázza az általuk használt minden egyes fájl vagy csomag licencét, annak érdekében, hogy megbizonyosodhassunk arról, hogy a szervezet megfelel a licenceknek. A szerző elismerése Majdnem minden licenc megköveteli, hogy a szerzői jog tulajdonosát (gyakran “author”-nak (szerző) nevezik) említsék a szoftverről szóló beszélgetések és a szoftver

népszerűsítése során. Minden licenc elmagyarázza, hogy mit kell tartalmaznia ennek a megjegyzésnek: a licencek általában egy szabványos szerzői jogi közleményt írnak elő, amely tartalmazza a szerzői jog tulajdonosának nevét és az évszámot. Ennek az értesítésnek meg kell jelennie a komponenst használó termékkel kapcsolatos minden dokumentációban, beleértve az eszköz vagy program 186 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés reklámját és weboldalát is. A jóváhagyás látszatának elkerülése A BSD licencek némelyike megköveteli, hogy a komponensekkel együtt terjesztett termék terjesztője ne sugallja, hogy a szerzői jog tulajdonosa támogatja a terméket. Még ha a követelmény nincs is kimondva, etikus dolog betartani. A forráskód felajánlása copyleft licencekhez Ha egy szervezet olyan bináris fájlt terjeszt, amely

copyleft-védett komponenseket tartalmaz, akár szoftver disztribúciókén vagy eszközön, a szervezetnek fel kell ajánlania a nyilvánosság számára a komponensek forráskódját. Ha a szervezet megváltoztatja a kódot, és a származtatott művet bináris formában terjeszti tovább, akkor a megváltoztatott ( származtatott) változat forráskódját is fel kell ajánlania a nyilvánosságnak. A terjesztés történhet bármilyen olyan módon, amely a nyilvánosság számára kényelmesen hozzáférhetővé teszi a kódot, például közzéteszik azt egy weboldalon, vagy lemezen, USB-sticken kínálják fel. Copyleft komponensek ne kerüljenek beépítésre szabadalmaztatott termékekbe Ha a szervezet copyleft-védett komponenseket épít be egy termékbe, bizonyos körülmények között a szervezetnek az egész terméket ugyanazon copyleft licenc alatt kell kiadnia. Az ezt a követelményt kiváltó feltételek licencenként eltérőek. Néha azonban nem egyértelmű, hogy

milyen felhasználás váltja ki a copyleft követelményt. Így az olyan egyértelmű helyzetek kivételével, mint például egy nyílt forráskódú könyvtár használata (amely nem válthatja ki a copyleft kölcsönös követelményét), a fejlesztőknek nagyon óvatosnak kell lenniük a copyleft alá tartozó komponensek felhasználásával kapcsolatban, hacsak a szervezet nem hajlandó a saját termékét ugyanezen licenc alatt kiadni. Kódváltozások dokumentálása A kód módosított változatainak terjesztésekor egyértelműen jelezni kell a szervezet által végrehajtott változtatásokat. Szabadalmi jogok megadása Egyes ingyenes vagy nyílt forráskódú szoftverlicencek szabadalmi jogokat várnak el a szoftver használatához. Így ha egy szervezet ilyen licenc alapján ad ki kódot, és szabadalommal rendelkezik a kódban szereplő valamely eljárásra, akkor a szervezet nem számíthat fel díjat vagy nem gyakorolhat más, a szabadalmán alapuló ellenőrzést

bárkivel szemben, aki a kódot használja vagy adaptálja. A védjegyek tiszteletben tartása A nyílt forráskódú szoftverek egy része védjegyoltalom alatt áll. A védjegyek szavakra és kifejezésekre, logókra és egyéb képekre, valamint sok más dologra terjedhetnek ki. Egyrészt Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 187 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek egy szervezetnek megfelelően kell kezelnie a védjegyet minden általa használt szoftver esetében: gyakori jogsértés a védjegy engedély nélküli parodizálása, megváltoztatása vagy egyszerű megjelenítése. Másrészt, ha a szervezet használni akarja a védjegyet, meg kell felelnie a védjegyjogosult követelményeinek, ami kizárhatja a szoftver módosítását. A nyílt forráskódú szoftverek kockázatai Ez a lecke a megfelelőségről (compliance) szól, ezért e terület kockázataira

összpontosítunk, de néhány más témát is érintünk. Licenc megsértése A szabad és nyílt forráskódú szoftverlicenceket ugyanolyan komolyan kell kezelni, mint más licenceket és szerződéseket. Szervezetek érvényesítik ezeket, például a Software Freedom Conservancy, amely azon a kis copyleftes projektek nevében jár el, amelyeknek nincsenek saját végrehajtási mechanizmusaik. Ezek a szervezetek általában végső megoldásként közelítenek a perhez. A legtöbb jogsértés nem szándékos, és oktatással könnyen megoldható. Mégis, árt egy szervezet hírnevének, ha tudatlannak és érzéketlennek tartják azokkal a közösségekkel szemben, akiknek a szoftverétől függ. És valóban indítottak már pert, amikor a szoftver felhasználója kirívóan megtagadta az együttműködést, és amikor a szoftver és az alperes kellően fontos volt. Még ha egy szervezetet nem is büntetnek perrel, az engedély megsértése jelentős károkat okozhat a

közösséggel való kapcsolatában és a hírnevében. Egy projektet akár olyan egyszerű dolog is kisiklathat, mint az, hogy a fejlesztők kérdései megválaszolatlanul maradnak az általuk használni kívánt szoftverrel foglalkozó fórumokon. Katasztrófa lehet, ha valaki copyleftelt szoftvert talál egy szabadalmaztatott termékben. A licencnek való megfelelés érdekében a fejlesztőknek vagy el kell távolítaniuk az összes copyleftes kódot, vagy a terméküket a copyleft licenc alatt kell megjeleníteniük. A szoftverük ingyenessé tétele a forráskóddal együtt szörnyű hatással lehet a licencdíjakon alapuló üzleti modellekre vagy a termék értékének más módon történő monopolizálására. Bizalom és hírnév Láttuk, hogy az engedélyek megsértése nagyon káros lehet. A bizalmat és a hírnevet megzavaró egyéb magatartásformák szintén kockázatot jelentenek. 188 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12

Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés Egyes szervezetek szabad vagy nyílt forráskódú szoftverlicenc alatt adnak ki szoftvereket, majd egy bizonyos ponton bejelentik, hogy a jövőbeli verziók jogvédett licenc alá kerülnek. Ez a váltás csábító lehet, mivel sok nyílt forráskódú projekt nem kap elég ügyféltől pénzügyi támogatást. Az ilyen licencváltozások azonban mind az ügyfelek, mind a projekthez hozzájáruló külső fejlesztők körében haragot váltanak ki. Előfordul, hogy a külső fejlesztők átveszik az ingyenes verziót, és önállóan fejlesztik tovább, ezt a lépést nevezik a projekt forkolásának. Az ingyenes verzió versenyképessé válhat a vállalat saját fejlesztésű változatával szemben, és elvonhatja az ügyfeleket a vállalattól. A projektfórumokon való részvételnek is vannak kockázatai. A vállalatnak meg kell tanulnia, hogyan lehet jó polgárként viselkedni. A gyakori

problémák közé tartoznak: • Megpróbálják egy vállalat pénzügyi vagy kód-hozzájárulását arra használni, hogy a projektet olyan irányba kényszerítsék, amit a többi fejlesztő nem akar • Túl sok követelményt támaszt a közösséggel szemben, például túl sok funkciókéréssel vagy akár túl sok kérdéssel nyomást gyakorolva rá • Durva viselkedés más módon és a projekt magatartási kódexének megsértése • Megpróbálja uralni a nyilvánosságot, vagy más módon próbál tőkét kovácsolni a projekt sikeréből Nem kifizetődő beruházások Az üzleti modelleket egy másik leckében tárgyaljuk; ez a szakasz csak a nyílt forráskódú projektekben való részvétel pénzügyi kockázatát említi. A vállalatok azzal a várakozással indíthatnak nyílt forráskódú projekteket, vagy csatlakozhatnak azokhoz, hogy valamilyen mechanizmuson keresztül például támogatási szerződések, SaaSszerződések, adatgyűjtés, vagy akár

adományok és támogatások révén bevételre tesznek szert. Sajnos azok, akik nyílt forráskódú projekteket működtetnek, gyakran a reméltnél kevésbé jövedelmezőnek találják azokat. Természetesen minden vállalkozás kockázatot vállal, amikor új projektet indít, de a nyílt forráskódú projektek esetében különösen nehéz megbízható bevételi forrást találni. A nyílt forráskód akkor tűnik a leginkább fenntarthatónak, ha valamilyen más bevételi formát támogat, például hardvereszközök, autók, nyomtatók stb. értékesítését Forkok Mint láttuk, egy projekt tagjai néha nem értenek egyet a projekt ütemtervével, vezetésével vagy Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 189 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek más szempontokkal kapcsolatban, és létrehoznak egy alternatív projektet ugyanazon a kódbázison. Ezt az úgynevezett forkingot

egy szervezet is elvégezheti a szoftver egy speciális verziójának létrehozása érdekében. Az Android például a Linux egy speciális változatát használja, amelyet a Google tart fenn. (A Google a Linux alapverziójához is sok hozzájárulást tesz, és ezeket nem mindig fogadják el). A szervezetek különböző okokból hozhatnak létre forkot. Előfordulhat, hogy változtatásokat nyújtanak be az alapprojekthez, amiket elutasítanak, mert más fejlesztők nem akarják azokat. Egy permisszív licenccel rendelkező vagy csak a szervezeten belül használt projekt esetében előfordulhat, hogy titokban akarják tartani a változtatásokat. A fork kockázata az, hogy a forkolt projekt fejlesztői felelősek a teljes termék karbantartásáért. Ha fontos hibajavítások vagy új funkciók kerülnek az alapprojektbe, a forkolt projekt fejlesztőinek duplikálniuk kell a változtatásokat, vagy le kell mondaniuk azok előnyeiről. Ahogy telik az idő, és a projektek egyre

távolabb kerülnek egymástól, egyre nehezebb lépést tartani az alapprojektben bekövetkező változásokkal. Inkompatibilis licencek Amint azt más leckékben is elmagyaráztuk, egyes szabad és nyílt forráskódú szoftverek licenceinek vannak egymással összeegyeztethetetlen záradékai. Az ilyen komponensek nem használhatók együtt egy termékben. Ez a probléma valószínűleg egy egyesülés vagy felvásárlás során merül fel. Előfordulhat, hogy az egyes vállalatok egy adott licenccel rendelkező szoftvert használtak, és ha a kódot egyesíteni akarják a projektjeikben, meg kell győződniük arról, hogy a licencek kompatibilisek. Termékfelelősség Számos nyílt forráskódú szoftver licencében (és számos védett szoftver és szolgáltatás felhasználási feltételeiben) kifejezetten kizárják a szoftver használatáért való felelősséget. Ezt úgy is mondhatjuk, hogy a licenc vagy a szolgáltatási feltételek nem nyújtanak garanciát vagy

jótállást. A szoftvergyártókat ritkán vonják felelősségre a szoftverükkel kapcsolatos problémákért, de az ügyfelek időnként beperelik őket, vagy más büntetési formákkal próbálkoznak. A bíróságoknak nem kell elismerniük a “nincs jótállás” (no warranty) záradékokat. A törvények és rendeletek egyre inkább felelősséget rónak a szoftverek készítőire. Ezek a jogi korlátozások vagy legalábbis a korlátozásokra vonatkozó javaslatok most főképp a mesterséges intelligenciára vonatkoznak, de néha szélesebb körűek. 190 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés Exportszabályozás Sok ország korlátozza az áruk és a szoftverek exportját. A szoftverek esetében az ilyen előírások leggyakrabban a biztonsági termékekre, és különösen a kriptográfia használatára vonatkoznak. Az Egyesült Államokban

korábban szigorú ellenőrzéseket alkalmaztak a kriptográfiát tartalmazó szoftverekre, de a nyílt forráskódú projektek esetében az ellenőrzéseket enyhítették. A vállalatoknak tisztában kell lenniük az exportszabályokkal ott, ahol szoftvert készítenek, abban az esetben, ha ezek a szabályok befolyásolják termékeik értékesítését és forgalmazását. Szoftver darabjegyzék: tudjuk, mit használunk Sok termékhez tartozik egy darabjegyzék, ami csak egy lista az összes alkotóelemről. Ha például egy fogyasztási cikket vásárolunk, akkor tartozhat hozzá egy papírlap, amely az összes alkatrészt felsorolja, egészen az anyákig és csavarokig. A lista tartalmazhat hasznos információkat, például az alkatrész méreteit és a cikkszámot, hogy új alkatrészt rendelhessünk. A nyílt forráskódú projektek ma már tartalmaznak egy Software Bill of Materials-t (szoftver darabjegyzék SBOM, ejtsd: “S-bomb”). Az SBOM legalább felsorolja a

csomagokat, fájlneveket, licenceket, szerzőket vagy tulajdonosokat és verziószámokat. Sok SBOM tovább megy, és a biztonsági résekkel kapcsolatos információkat is tartalmaz. A projektek minden egyes kiadáshoz automatikus eszközökkel generálnak SBOM-ot. A felhasználók átvizsgálhatják az SBOM-ot, hogy megtalálják a szükséges információkat. A licencek kinyerése például segít a szervezetnek gyorsan eldönteni, hogy az összetevők kompatibilisek-e, valamint jogilag megengedett-e a használatuk a saját kódjukkal. Hasonlóképpen, az egyes csomagokra vonatkozó verzióinformációk kinyerése segít a szervezetnek felfedezni, hogy a termék különböző részei egy adott könyvtár különböző verzióitól függnek-e. A könyvtár két verziójának használata legalábbis bővülést okoz Emellett zavart és hibákat is eredményezhet, ha egy komponens rossz verzióval épül be. SBOM szabványok Mivel a számítástechnikai környezetek hatalmas

mennyiségű (néha több tízezer) alkatrészt használnak, és gyakran változnak, a SBOM-oknak rendkívül strukturáltnak kell lenniük, hogy az információk automatikusan és gyorsan kinyerhetők legyenek. Ez a szakasz a nyílt forráskódú világ két legnépszerűbb formátumát ismerteti: Software Package Data Exchange (SPDX) A formátum minden egyes csomagot és annak összes tartalmát egy fa struktúrában ábrázolja. A Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 191 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek formátum dokumentálja a fájlok közötti függőségeket és egyéb kapcsolatokat. Az információra mutató mutatók, úgynevezett “snippetek” hozhatók létre, amelyeket aztán az egész dokumentumban lehet használni, hogy az információt csak egy helyen kelljen definiálni. Ezt a formátumot a Linux Foundation fejlesztette ki. CycloneDX Ez egy nagyobb formátum,

részletesebb mezőkkel, különösen a sebezhetőségre vonatkozó információk esetében. A formátumot az Open Worldwide Application Security Project (OWASP) hozta létre, és népszerű a hadseregben és más, a biztonságra összpontosító szervezetekben. Egy fájlra vonatkozó bejegyzés például tartalmazhatja a biztonsági rés nevét, a sebezhetőséggel kapcsolatos információk forrását, az érintett célpontokat és egyebeket. Ezt a formátumot olyan felhőalapú telepítésekhez is tervezték, amelyek több ezer különböző rendszert tartalmazhatnak. Mind az SPDX, mind a CycloneDX hierarchikus struktúrákat hoz létre különböző formátumokban, többek között JSON és XML formátumban. Mindkét szabványhoz számos eszköz létezik, mind a formátumok létrehozásához, mind a létrehozott fájlok információk kereséséhez. A népszerű verziókezelő repositoryk segítségével a fejlesztők egy gombnyomással létrehozhatnak egy SBOMot e formátumok

valamelyikében. Szoftverösszetétel-elemzés Annak ismerete, hogy egy szervezet mit használ, megköveteli a szoftver értékelését, amely magában foglalja annak megértését, hogy honnan származik, milyen sebezhetőségeket tartalmaz, milyen licenceket használ, és egyéb olyan tényezőket, amelyek segítenek az egyénnek vagy a szervezetnek eldönteni, hogy használja-e a szoftvert. Ezt a feladatot nevezik Software Composition Analysis-nak (szoftver-összetétel elemzés, SCA), és számos eszköz létezik a SBOM-ok és magának a szoftvernek a kifinomult vizsgálatára. Egyes eszközök kivonatolják a licencinformációkat, amelyek segítenek a szervezetnek eldönteni, hogy a szoftver biztonságosan beépíthető-e a termékbe, és hogy a különböző komponensek kompatibilis licencekkel rendelkeznek-e. Bizonyos eszközök még a kódrészleteket is összehasonlítják a gyakori nyílt forráskódú projektek könyvtáraival, hogy kiderítsék, nem vették-e át a kódot

a nyílt forráskódú projektekből a megfelelő attribúció nélkül. Ezeknek az eszközöknek a működtetése különösen fontos egy egyesülés vagy felvásárlás során. A felvásárló vállalat rájöhet, hogy az általa megvásárolni kívánt szoftver kevésbé értékes, mint amire számított, mivel olyan nyílt forráskódú komponenseket tartalmaz, amelyek olyan követelményeket támasztanak, amelyek zavarják az új szervezetben történő tervezett felhasználást. 192 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés Hivatalos irányelvek és megfelelőség Az ebben a leckében leírt folyamatokat és technikákat a vezetőknek kell kialakítaniuk a fejlesztők, ügyvédek és más hozzáértők közreműködésével. Ez a szakasz néhány olyan szakpolitikai döntést ismertet, amelyeket a szervezeteknek meg kell hozniuk a nyílt forráskódú

szoftverekkel kapcsolatban. A fejezetet egy Open Source Program Office (OSPO) leírásával zárjuk, amely az irányelvek szószólója és információs forrása lehet. A nyílt forráskódú szoftverek használatát és hozzájárulását szabályozó elvek A szervezetek nagy hasznot húzhatnak a nyílt forráskódú szoftverek használatából és a hozzájuk való hozzájárulásból, de ezt úgy kell tenniük, hogy saját érdekeiket védjék, és a nyílt forráskódú projektek számára is előnyös legyen. Meg kell határozni a következő irányelveket: • Hol érdemes nyílt forráskódú szoftvereket használni (műveletek, belső projektek, ügyfélbarát termékek stb.) • Mitől lesz egy nyílt forráskódú projekt megfelelő a szervezet számára: funkciók, teljesítmény, biztonság, a jövőbeli bővítések ütemterve és a közösség életképessége • Szoftverösszetétel-elemzésre vonatkozó vizsgálatok, és hogy hol kell tárolni a keletkező

dokumentációt • A nyílt forráskódú szoftverekhez hozzájáruló fejlesztők jutalmazása, beleértve a nyilvános fórumokon való részvételüket is • Irányelvek a projektekhez való hozzájáruláshoz, beleértve azt is, hogyan lehet a vállalatot nyilvánosan képviselni • Dokumentációs követelmények, hogy a core csapaton kívüli fejlesztők is megértsék, hogyan kell hozzájárulni és együttműködni Az OSPO koordinálhatja ezen irányelvek kidolgozását és a megfelelőség biztosításához szükséges oktatást. Közreműködői megállapodások A nyílt forráskódú projekteknek biztosítaniuk kell, hogy a hozzájárulások jogszerűek legyenek: például, hogy a kódot nem vették át valamilyen szabadalmaztatott termékből vagy egy olyan nyílt forráskódú projektből, amelynek a licencével nem kompatibilis. Sok nyílt forráskódú projekt megköveteli a fejlesztőktől, hogy a hozzájárulásuk jogszerűségének biztosítása érdekében egy

dokumentumot, az úgynevezett Contributor License Agreement-et (hozzájárulói licencszerződés CLA) nyújtsanak be. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 193 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Egy szervezet fejlesztői, akik hozzájárulnak az ilyen projektekhez, felkérhetik a szervezet jogászait, hogy vizsgálják felül és hagyják jóvá a CLA-t. Ezért az ügyvédeknek meg kell érteniük a CLA-k záradékainak relevanciáját, és fel kell készülniük azok ellenőrzésére. A CLA-kat számos kritika érte, többek között a bonyolultságuk és a kiskapuk miatt, amelyeket a projektek számára hagynak, hogy a hozzájáruló kódot a hozzájáruló által nem kívánt módon használják fel. Sok projekt a CLA helyett egy rövid dokumentum, a Developer Certificate of Origin (fejlesztői eredetigazolás DCO) aláírását kéri a fejlesztőtől, amely igazolja, hogy a

fejlesztőnek joga van a kódhoz való hozzájárulásra. A DCO-t, amelyet egy másik leckében tárgyalunk, általában nem nyújtják be ügyvédnek felülvizsgálatra. Egyes projektek egyszerűen csak arra kérik a közreműködőket, hogy írják alá a kódjuk szerzői jogát a projektnek egy Copyright Assignment Agreement-ben (szerzői jogátruházási megállapodás CAA). Sok közreműködő azonban nem kedveli ezt a gyakorlatot, mert nem használhatják a kódot egy saját, jogvédett projektben, valamint mert ez nagy hatalmat ad a projektnek. Az Open Source Program Office (OSPO) A nyílt forráskódú projektek szokatlan társadalmi, technikai, jogi és szervezeti tényezőket egyesítenek. Jelenleg ezeknek a tényezőknek az ismerete még nem terjedt el annyira a szervezetekben, hogy minden vezető, fejlesztő, jogász és más személy mélyen megértse őket. Ezért a szervezeteknek nagy hasznára válhat egy Open Source Program Office (nyílt forráskódú programiroda

OSPO) létrehozása, amely az érdekérvényesítés, az irányelv-alkotás, az irányelv érvényre juttatása és az oktatás központjaként működik. Az OSPO-k egyfajta univerzális részlegként számos szerepet tölthetnek be, például: A nyílt forráskód támogatása Az OSPO-k a szervezetükben terjeszthetik mind a nyílt forráskódú mozgalom mögött álló koncepciókat, mind a nyílt forráskód használatára vonatkozó javaslatokat. Emlékeztethetik a fejlesztőket, hogy keressenek nyílt forráskódú megoldásokat az általuk megoldandó problémákra, és ösztönözhetik őket a megfelelő szoftverek bevezetésére. Sürgethetik a vezetőket, hogy biztosítsanak időt a fejlesztőknek a nyílt forráskódú projektekben való részvételre, és ismerjék el ezt a részvételt, amikor a fejlesztőket fizetésemelés és előléptetés szempontjából értékelik. Az irányelvek meghatározása Az OSPO-k mozgósíthatják a vezetőket, hogy hozzanak létre

irányelveket és hozzanak létre 194 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés repositorykat számukra. Az irányelvek végrehajtása Az OSPO-k emlékeztethetik a fejlesztőket a szoftverek és a SBOM-ok átvizsgálására, valamint a nyílt forráskód használatára vonatkozó vállalati szabályok betartására. Az OSPO-k megőrizhetik az elfogadott szoftverekkel kapcsolatos dokumentációt és a vállalati használat egyéb szempontjait. Oktatás Az OSPO-k elmagyarázhatják a fejlesztőknek, hogyan értékeljék a nyílt forráskódú projekteket és hogyan vegyenek részt bennük, elmagyarázhatják a jogászoknak a licencek és egyéb jogi megfontolások részleteit, és segíthetnek a vállalatnak megérteni azokat a szervezeti és kulturális változásokat, amelyek megkönnyítik a nyílt forráskódú szoftverek használatát. Az OSPO

létrehozásához számos dokumentum és online forrás áll rendelkezésre. Egy kis szervezet a feladatot át is ruházhatja egy olyan harmadik félre, aki szakértője az adott területnek. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 195 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Gyakorló feladatok 1. Miért nem vehet ki egy fejlesztő egyszerűen egy nyílt forráskódú projektből egy neki tetsző kódot, és miért nem illesztheti be a saját kódjába a licenc megőrzése nélkül? 2. Milyen dokumentumokat írna alá egy fejlesztő, amikor hozzájárul egy nyílt forráskódú projekthez? 3. Találunk néhány nyílt forráskódú szoftvert, amely kiváló alapot adna a kereskedelmi weboldalunknak. Ráhúzhatjuk-e a népszerű logójára a sajátunkat, hogy egy figyelemfelkeltő képet készítsünk a weboldalhoz? 196 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve |

Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés Gondolkodtató feladatok 1. Milyen megfontolások vezethetnek arra, hogy forkot hozzunk létre egy nyílt forráskódú projekt saját használata érdekében, a forkok hátrányai ellenére? 2. Ha találunk egy olyan nyílt forráskódú szoftvert, amely megfelel az igényeinknek, milyen okok miatt vethetjük el? 3. Egy copyleftelt naplózóeszközt szeretnénk használni saját fejlesztésű termékünkben Van olyan módja a kombinálásuknak, amely nem követeli meg, hogy a terméket copyleft licenc alatt terjesszük? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 197 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Összefoglalás Ez a lecke számos olyan szempontot tartalmaz, amelyet figyelembe kell venni, mielőtt szabad és nyílt forráskódú szoftvereket használunk. Elmagyaráztuk, hogy

hogyan kell betartani a licenceket, a különböző jogi, hírnevet érintő és pénzügyi kockázatokat, valamint azt is, hogy hogyan kell meghatározni a fontos irányelveket, és hogyan lehet azokat a szervezeten belül érvényesíteni. 198 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0543 Compliance és kockázatcsökkentés Válaszok a gyakorló feladatokra 1. Miért nem vehet ki egy fejlesztő egyszerűen egy nyílt forráskódú projektből egy neki tetsző kódot, és miért nem illesztheti be a saját kódjába a licenc megőrzése nélkül? Ez általában a nyílt forráskódú licenc megsértése, valamint plágiumnak és szerzői jogok megsértésének minősül. Gyakorlatilag a szervezetet rákényszeríthetik a licenc betartására, aminek következményei a szégyentől és a jó hírnév csorbításától kezdve az üzleti modelljük tönkretételéig terjedhetnek, ha a copyleftes kódot a

jogvédett kóddal keverik. 2. Milyen dokumentumokat írna alá egy fejlesztő, amikor hozzájárul egy nyílt forráskódú projekthez? A Contributor License Agreement egy jogi dokumentum, amely a nyílt forráskódú szervezet számára a kód használatára vonatkozó jogokat biztosítja. A Developer Certificate of Origin egy rövidebb és egyszerűbb dokumentum, amely megígéri, hogy a fejlesztőnek joga van a kódhoz való hozzájárulásra. A Copyright Assignment Agreement minden jogot biztosít a fogadó szervezetnek. 3. Találunk néhány nyílt forráskódú szoftvert, amely kiváló alapot adna a kereskedelmi weboldalunknak. Ráhúzhatjuk-e a népszerű logójára a sajátunkat, hogy egy figyelemfelkeltő képet készítsünk a weboldalhoz? Ha a projekt védjegyeztette a logóját, a változtatás valószínűleg sérti a védjegyet. Még ha a logó nincs is védjeggyel védve, a változtatásunk tiszteletlen és összezavaró lehet. Version: 2024-08-12 | CC BY-NC-ND 4.0

alatt licencelve | learning.lpiorg | 199 Open Source Essentials (Version 1.0) | Témakör 054: Nyílt forráskódú üzleti modellek Válaszok a gondolkodtató feladatokra 1. Milyen megfontolások vezethetnek arra, hogy forkot hozzunk létre egy nyílt forráskódú projekt saját használata érdekében, a forkok hátrányai ellenére? Ha elégedettek vagyunk a kód jelenlegi állapotával, akkor nem biztos, hogy folyamatosan követnünk kell az alapprojekt változásait. Lehet, hogy olyan terméket szeretnénk létrehozni, amely lényegesen különbözik az alapprojekt felhasználásától, és ezért hajlandóak vagyunk elválni az alapprojekttől. Lehet, hogy a kód elég értékes az üzleti tervben ahhoz, hogy a csapat hajlandó legyen teljes felelősséget vállalni a fejlesztéséért és karbantartásáért. 2. Ha találunk egy olyan nyílt forráskódú szoftvert, amely megfelel az igényeinknek, milyen okok miatt vethetjük el? Előfordulhat, hogy a kód túl sok

hibát és biztonsági rést tartalmaz, a projekt fejlesztői közössége nem működik jól, esetleg nem tetszik a kód fejlődésének iránya, vagy a licenc nem kompatibilis a termékünk más kódjaival. 3. Egy copyleftelt naplózóeszközt szeretnénk használni saját fejlesztésű termékünkben Van olyan módja a kombinálásuknak, amely nem követeli meg, hogy a terméket copyleft licenc alatt terjesszük? Az eszköz kódjának a saját kódunkba való integrálása a copyleft kölcsönös követelményét válthatja ki, attól függően, hogy melyik licenc van érvényben. A naplózóeszközt el kell különíteni a saját termékétől, hogy a mi termékünket ne tekintsék származékosnak. Biztonságos lehet például, ha a copyleft alatt álló eszközt különálló folyamatként futtatjuk és üzenettovábbításon keresztül kommunikálunk vele. 200 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version

1.0) | Témakör 055: Projektmenedzsment Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 201 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment 055.1 Szoftverfejlesztési modellek Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0551 Súlyozás 3 Kulcsfontosságú ismeretek • A projektmenedzsment jelentőségének és céljainak megértése a szoftverfejlesztésben • A vízesés szoftverfejlesztés alapvető megértése • Az agilis szoftverfejlesztés alapvető ismerete, beleértve a Scrumot és a Kanbant is • A DevOps fogalmának megértése A használt fájlok, kifejezések és segédprogramok listája • A vízeséses projektek fázisai (követelménytervezés, üzleti elemzés, szoftvertervezés, fejlesztés, tesztelés, üzemeltetés) • Szerepek vízeséses projektekben (projektmenedzserek, üzleti elemzők, szoftverarchitektek, fejlesztők, tesztelők) • A

Scrum-projektek szervezése (sprintek és sprinttervezés, termék- és sprintbacklog, napi scrum, sprintértékelés és sprint retrospektív) • Szerepek a Scrum-projektekben (product ownerek, fejlesztők, scrum masterek) • Kanban projektek szervezése (kanban táblák) 202 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 055 Projektmenedzsment Fejezet: 055.1 Szoftverfejlesztési modellek Lecke: 1/1 Bevezetés Az élet tele van projektekkel. Projekt lehet egy moziest, egy kirándulás, egy családi esemény vagy a gyerekek hetének megtervezése, vagy akár egy hobbi tökéletesítése. Nem számít, hogy mit szeretnénk megvalósítani: terveket kell készítenünk és intézkedéseket kell tennünk. Általában több forgatókönyvet készítünk, B tervvel, C tervvel stb. Nincs ez

másképp a szoftverfejlesztés világában sem. Szerepkörök a szoftverfejlesztésben A sikeres projektmenedzsmenthez sokféle készségre van szükség, ezért hasznos, ha különböző embereket találunk a jól meghatározott szerepek betöltésére. A következő szakaszok a szoftverprojektekben gyakran előforduló szerepek közül néhányat ismertetnek. Projektmenedzser Egy projekt irányítása rendkívül összetett feladat. Egyes helyzetek elsőre könnyűnek tűnnek, de a helyes megoldásukhoz gondosságra és tapasztalatra van szükség. Az ezt végző személy a projektmenedzser (project manager). Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 203 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment A projektmenedzser felelősségi körébe tartozik annak biztosítása, hogy a projektet időben, a költségvetésen belül és elfogadható minőségben fejezzék be. Még ha nem is írnak egyetlen sor kódot sem,

a projektmenedzserek azok, akik felelősek és elszámoltathatók a csapat eredményeiért. A határidőkkel kapcsolatban egyeztetniük kell az ügyfelekkel Emellett beszélnek a más szerepkörökben dolgozókkal is, hogy megbizonyosodjanak arról, hogy minden rendben van. Business analyst és requirement engineer Nincs helye a mikromenedzsmentnek legalábbis egy egészséges munkahelyen nincs. A business analyst-ok (üzleti elemző BA) és requirement engineer-ek (követelménymérnök RE), a projektcsapat belső vagy külső munkatársai, a projektmenedzserek jobb kezei. Ők felelősek a követelményekről szóló gazdag és egyértelmű dokumentáció létrehozásáért. Ők képezik a hidat az ügyfelek és a fejlesztők között. Az ügyfelek közérthető nyelven kommunikálnak, amelyet a BA/RE világos és egyértelmű dokumentációvá alakít, ezzel biztosítva, hogy a fejlesztők hatékonyan végezhessék munkájukat. Képzeljük el, hogy megkérnek, hogy vigyünk egy

“nagy tortát” egy partira. Mit jelent az, hogy “nagy”? Tíz szelet vagy húsz? Talán egy nagy esküvő tortájáról van szó, és száz szeletesnek kellene lennie. A BA/RE-nek pontosan meg kell határoznia az olyan követelményeket, mint például a mennyiségek, hogy a fejlesztők tudják, hogy egy alkalmazást egy bizonyos számú felhasználóra terveztek. Még csak a követelmények meghatározásának elején járunk, de már most láthatjuk, milyen fontos a világos kommunikáció. Minden közös munkához elengedhetetlen, de egy nyílt forráskódú projekt esetében talán még fontosabb, mivel a projekt egyes részein nagyon eltérő háttérrel rendelkező emberek dolgozhatnak. Lehet, hogy valaki diákként, valaki más szülőként, nyugdíjasként vagy két munkahely között lévő személyként stb. dolgozik Még így is zökkenőmentesnek kell lennie a haladásnak ebben a környezetben tehát a kommunikáció nem hátráltathatja a haladást. Fejlesztők,

architektek és tesztelők A követelmények megvalósításához egy szoftverprojektnek fejlesztőkre (developer) van szüksége, akik a dokumentáció és a tervezési döntések alapján hozzák létre a terméket. Munkájukat az architect bírálja el, aki általában a projektben részt vevők közül a legszélesebb körű technikai és szakterületi ismeretekkel rendelkezik. Minden fejlesztő, különösen a vezető fejlesztők, felelősek a saját kódjukért, de a nagy döntéseket az architekt hozza meg vagy hagyja jóvá. Néha az embereket kifejezetten tesztelőknek nevezik ki, akik felelősek mindenféle tesztelésért, az eredmények dokumentálásáért és hibajegyek létrehozásáért. 204 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek Tervezés és ütemezés Most, hogy az alapvető szerepekről megbeszéltünk, jöhetnek a projekt fázisai: tervezés,

ütemezés, megvalósítás, karbantartás/tesztelés és átadás. Néhány fázis a különböző szoftverfejlesztési modellek esetén eltérő lehet, de a tervezés és az ütemezés olyan általános témák, amelyeket megvitatunk, mielőtt mélyebben belemerülnénk a különböző modellekbe. A tervezésre (planning) azután kerül sor, hogy a BA-k/RE-k rendelkezésre bocsátják a követelmények listáját. A tervezés egy vagy több megbeszélésből áll, amelyeken megvitatják, hogy a csapat mit szeretne elérni, hogyan tervezik azt megvalósítani, és mennyi időbe telik. Általában ezeken a megbeszéléseken kerül sor némi kockázatelemzésre (risk analysis) is. A tervezőknek ezután be kell ütemezniük (schedule) a munkát, és mérföldköveket (milestone) kell létrehozniuk. Minden egyes mérföldkőnél tudja a csapat, hogy egy nagy, fontos rész elkészült A hosszútávú komponensek vagy funkciók hónapokig is eltarthatnak, ezért a tervezőknek be kell

számolniuk a szabadságokat, ünnepeket és különösen a hideg évszakokban némi betegszabadságot, hogy biztosítsák a pontos szállítási időt, és elkerüljék a rohanást és a pánikot a határidő közeledtével. Egy jó ütemterv mellett a fejlesztők nyugodtabbak, és időben, összeomlások nélkül tudnak minőségi megoldásokat szállítani. Általános eszközök Két olyan eszköz, amely minden modell és általában a projektmenedzsment számára is előnyös, a verziókezelő rendszer (version control system VCS) és az alkalmazás-életciklus-kezelő (application lifecycle management ALM) platform. A verziókezelést egy másik leckében tárgyaljuk részletesen, ezért ejtsünk néhány szót az ALM-ekről. Az ALM egy olyan átfogó keretrendszer, amely a szoftveralkalmazások életciklusát kezeli a kezdeti fejlesztéstől a karbantartáson át az esetleges nyugdíjazásig. Az ALM integrálja az embereket, a folyamatokat és az eszközöket az

együttműködés és a hatékonyság fokozása érdekében, biztosítva, hogy a szoftver életciklusának minden szakasza jól koordinált és az üzleti célokkal összhangban legyen. Ez a megközelítés segít fenntartani az alkalmazások minőségét, teljesítményét és megbízhatóságát azok teljes élettartama alatt. Most, hogy általános áttekintést kaptunk a szerepekről és az életciklus fázisairól, térjünk rá a modellekre! Vízesésmodell Ez az egyik legkorábbi és legegyszerűbb módszertan a szoftverfejlesztésben. Úgy képzelhetjük el, mint egy lépcsőt, ahol minden lépcsőfokot be kell fejezni, mielőtt továbblépnénk. A modell Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 205 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment azonban csak egy irányba halad, így olyan projektekhez alkalmas, amelyekben egyértelmű követelmények vannak, és egyáltalán nem várható változás vagy

csak minimális. Bár e modell egyszerűsége előnyös lehet, a merev metodológia hátrányt jelenthet, amikor rugalmasságra és alkalmazkodóképességre van szükség. Márpedig manapság általában minden változik, miközben egy projekten dolgozunk. Amint azt az előző szakaszok kifejtették, a fejlesztés megkezdéséhez a projektnek rendelkeznie kell a követelményekkel, egy kész tervvel és egy véglegesített ütemtervvel, amelyek tartalmazzák a mérföldköveket. A vízesésmodellben ezek a követelménytervezés és az üzleti elemzés eredményei. Requirement Engineering (követelmények meghatározása) Ebben a kezdeti fázisban összegyűjtik és dokumentálják a projekt összes követelményét. Ez a munka kiterjedt megbeszéléseket foglal magában a projektmenedzser és az érdekelt felek között, hogy megértsék igényeiket és elvárásaikat. Az eredmény egy átfogó követelményspecifikációs dokumentum, amely felvázolja, hogy a rendszernek mit kell

tennie. Business Analysis (üzleti tervezés) Az üzleti elemzők üzleti szempontból vizsgálják meg a követelményeket, hogy azok összhangban legyenek a szervezeti célokkal. A BA-k megvalósíthatósági tanulmányokat, kockázatértékeléseket és költség-haszon elemzéseket végeznek annak megállapítására, hogy a projekt életképes-e és érdemes-e megvalósítani. Az így nyert ismereteket a projekt hatókörének és célkitűzéseinek finomítására használják fel. Software Design (szoftvertervezés) A szoftvertervezés az a lépés, amikor az architect részletes tervezési specifikációt készít, amelyet a fejlesztők követhetnek. E specifikáció birtokában a csapat elkezdheti a követelmények megvalósítását más szóval a fejlesztési fázis megkezdését, amely ezután következik. Development (fejlesztés) A fejlesztési fázis az, ahol a varázslat történik ahol a kódot írják. A dokumentációt és a tervezési döntéseket szorgalmasan

követve a fejlesztők megírják a részüket. Miután a fejlesztők a többi fejlesztővel vagy az architecttel átnézik és ellenőrzik a kódot, ez a fázis befejezettnek tekinthető. 206 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek Testing (tesztelés) A fejlesztést egy tesztelési szakasz követi, amelyet a tesztelők irányítanak. A tesztelésnek különböző típusai vannak, amelyeket egy másik leckében ismertetünk, mint például az egységtesztelés (unit testing), az integrációs tesztelés (integration testing), a rendszertesztelés (system testing) és az átvételi tesztelés (acceptance testing). Ezeknek a teszteknek az a célja, hogy még a kiadás előtt felszínre hozzák a problémákat, és lehetővé tegyék a fejlesztők számára, hogy időben kijavítsák azokat nem pedig azután, hogy a projektet már telepítették és publikálták, és

a felhasználókat a hibák irritálják és frusztrálják. Operations (tevékenységek) A tesztek lebonyolítása és a hibák kijavítása után a projekt kiadható –- azaz üzembe helyezhető az éles környezetben. Ez a fázis tartalmazhat telepítést, konfigurálást és néha még a felhasználói oktatást is. Miután a projekt használatra kész, karbantartási fázisban van, ahol a csapat kezelheti a felhasználók problémáit, és szükség esetén frissítéseket is biztosíthat. A vízesésmodell értékelése Mit vettünk észre, miközben erről a modellről olvastunk? Hatékonynak találjuk? Hiányzik valami? Lássuk az előnyöket és hátrányokat! A vízesésmodell előnyei: Tiszta szerkezet A lineáris folyamat megkönnyíti a kezelést, megértést és követést. Aprólékos dokumentáció Részletes és alapos dokumentáció minden fázisban segít a csapatnak megérteni, hogy mire van szükség a fejlesztés és a későbbi karbantartás során.

Kiszámíthatóság Az egyértelmű, meghatározott költségvetést biztosítani. mérföldkövek segítenek előre látható ütemtervet és Egyszerűbb projektmenedzsment A modell lineáris és egyszerű folyamatának köszönhetően könnyen kezelhető. A vízesésmodell hátrányai: Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 207 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Merevség A modell lineáris rugalmatlansága megnehezíti a változtatások végrehajtását a követelményfázis befejezése után. Késői tesztelés A fejlesztési fázisban a tesztelés rendszertelen vagy hiányzik, ami a fontos problémák késői felismeréséhez vezethet. Tökéletes követelmények feltételezése A modell megköveteli és feltételezi, hogy minden követelmény helyes és egyértelmű, ami nagyon irreális lehet. A modell nem ad teret a fejlesztés során történő ellenőrzésnek, hogy megbizonyosodjunk

arról, hogy a követelmények pontosak és a fejlesztők megértették azokat. A visszajelzés hiánya Az ügyfél csak az utolsó fázisban mondhat bármit is a termékkel kapcsolatban. Ha tehát valami (vagy sok minden) nem felel meg az elvárásainak, a probléma csak a legvégén derül ki. Agilis szoftverfejlesztés, Scrum és Kanban A modernebb szoftverfejlesztési modellek ezen halmazának felfedezéséhez kezdjük a agilis szóval: Mit is jelent? Az agilitás a gyors reagálási és mozgási képességet fejezi ki, mind a fizikai, mind a szellemi világban. A cél ugyanaz a szoftverfejlesztésben is Az agilis szoftverfejlesztés olyan módszertan, amely az iteratív fejlesztésre, a rugalmasságra és az együttműködésre épül. Az apró fejlesztésekre összpontosít, miközben mindig visszajelzéseket gyűjt és azokat a fejlesztés során megvalósítja. Ez a megközelítés gyors reakciókat, kiigazításokat és válaszokat tesz lehetővé, időt takarít meg, és

biztosítja, hogy a projekt megfeleljen a felhasználók és az ügyfelek elvárásainak. Az agilis mozgalom 2001-ben indult útjára egy online Manifesto for Agile Software Development (Manifesztó az agilis szoftverfejlesztésről) című dokumentummal, amely az alábbi alapelveket tartalmazza: We are uncovering better ways of developing software by doing it and helping others do it. (A szoftverfejlesztés hatékonyabb módját tárjuk fel saját tevékenységünk és a másoknak nyújtott segítség útján.) Through this work we have come to value: (E munka eredményeképpen megtanultuk értékelni:) • Individuals and interactions over processes and tools (Az egyéneket és a személyes 208 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek kommunikációt a módszertanokkal és eszközökkel szemben) • Working software over comprehensive documentation (A működő

szoftvert az átfogó dokumentációval szemben) • Customer collaboration over contract negotiation együttműködést a szerződéses egyeztetéssel szemben) (A megrendelővel történő • Responding to change over following a plan (A változás iránti készséget a tervek szolgai követésével szemben) That is, while there is value in the items on the right, we value the items on the left more. (Azaz, annak ellenére, hogy a jobb oldalon szereplő tételek is értékkel bírnak, mi többre tartjuk a bal oldalon feltüntetetteket.) Manifesto for Agile Software Development Scrum A Scrum az egyik legnépszerűbb keretrendszer talán a szoftverfejlesztésen belül. A Scrum a következő építőelemekre épül: legnépszerűbb az agilis In a nutshell, Scrum requires a Scrum Master to foster an environment where: (Dióhéjban, a Scrum egy Scrum Mastert követel meg, aki olyan környezetet elősegítésében vesz részt, ahol:) 1. A Product Owner orders the work for a

complex problem into a Product Backlog (Egy Product Owner a komplex problémához tartozó munkát egy Product Backlogban sorrendezi.) 2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint (Egy Scrum Team a munka kiválasztott részét egy értéket képviselő Inkrementummá alakítja egy Sprint folyamán.) 3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint (A Scrum Team és az érdekelt felek megvizsgálják az eredményeket és ezekhez igazítják a következő Sprintet.) 4. Repeat (Az előző lépések ismétlődnek újra és újra) The 2020 Scrum Guide De ki a scrum master és a product owner? Mi az a product backlog és a sprint? Merüljünk el a szerepekben és folyamatokban! Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 209 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Sprintek és sprint planning A sprint egy jellemzően 2-4 hétig

tartó fejlesztési fázis, amely során néhány előre egyeztetett feladatot és/vagy funkciót fejeznek be. A feladatokról való megállapodás érdekében jelenik meg a sprint planning (sprint tervezés). Ebben a folyamatban a csapat döntéseket hoz arról, hogy mely feladatokat lehet elvégezni a következő sprint során. Ezek a döntések a projektet irányító és gyakran a finanszírozást is biztosító product owner (terméktulajdonos PO) által meghatározott prioritásokon alapulnak. Product Backlog és Sprint Backlog Amint az imént kifejtettük, a PO kezeli a prioritási listát, amely a projekt összes kívánt munkáját tartalmazza. A Scrumban ezt a listát product backlog-nak nevezik Minden sprint backlog az aktuális sprinthez a product backlog-ból kiválasztott feladatokat tartalmazza. A sprint backlog azokat az elemeket tartalmazza, amelyeket a csapat a sprinttervezés során kiválasztott. Daily Scrum vagy Stand-up A daily Scrum vagy stand-up megbeszélések

rövid, hatékony meetingek, ahol a csapatok megbeszélik az előrehaladásukat, kiemelik a problémákat és az akadályokat, és megosztják a napi terveiket. A stand-upot általában a munkanap legelején tartják Increment Az increment egy sprint során elért cél. Minden sprintnek egy vagy több inkrementumot kell eredményeznie. Az incrementtel elért feladat vagy funkciók helyességét teszteléssel kell ellenőrizni. Sprint Review A sprint review a sprint eredményének ellenőrzésére szolgáló megbeszélés. Ezek az értekezletek általában többről szólnak, mint a demók a cél a Scrum-csapat eredményei alapján történő visszajelzés. Mivel a cél a termékcél elérése, az érdekeltek véleményt és javaslatokat adnak a jövőbeli kiigazításokkal kapcsolatban. Ezeknek a meetingeknek az eredménye lehet a product backlog módosítása vagy kiegészítése. Sprint Retrospective A sprint retrospective célja a minőség és a hatékonyság javítása és nem

csak az aktuális termékben. A retrospektívnek fel kell tárnia a csapaton belüli rejtett feszültségeket, a folyamatokat lassító információhiányt, a külső függőségeket, amelyeket enyhíteni kellene a csapat 210 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek terheinek csökkentése érdekében stb. A csapat megbeszéli, mi ment jól, milyen problémákkal szembesültek, és milyen megoldásokat találtak (vagy nem találtak) ezekre a problémákra. Az eredmény a problémák és a lehetséges megoldások listája, amelyet a felelős személyhez rendelnek. Scrum Master Az összes ilyen megbeszélést a Scrum master vezeti. Minden Scrum-csapatnak szüksége van rájuk Ők felelősek a Scrum-folyamatok facilitálásáért, és segítenek a csapatnak a termékcél felé haladni, miközben a sprintek során problémák merülnek fel. A Scrum-master nemcsak

irányítja a folyamatokat, hanem coachként is funkcionál, hogy biztosítsa a hatékony kommunikációt a csapaton belül. Product Owner A product owner felelős a Scrum-csapat által létrehozott termék értékének maximalizálásáért. Ez a szerepkör különböző szervezetekben és csapatokban változhat. Még a feladatok delegálása esetén is a product owner marad felelős az eredményekért. A sikerhez a product owner döntéseinek szervezeti tiszteletben tartása szükséges, ami a product backlogban és a sprint felülvizsgálatának inkrementumában tükröződik. A product owner egyetlen személy, aki a különböző érdekelt felek igényeit képviseli a termékháttérben. Bárkinek, aki változtatni szeretne a backlogon, a product ownert kell meggyőznie erről. Ő határozza meg és rangsorolja a termékvíziót és a backlogot, és biztosítja a product backlog átláthatóságát, láthatóságát és érthetőségét. A Scrum-master és a product owner

együttműködik a projekt sikere érdekében. Partnerségük segíti a fejlesztőcsapatot abban, hogy hatékonyan és eredményesen szállítson értékes funkciókat. Fejlesztők A fejlesztők az elfogadott sprint backlogot követve valósítják meg a követelményeket. Dolgozhatnak önállóan is, de számos alkalommal előfordulhat, hogy együttműködnek: például páros programozás vagy egy másik fejlesztő kódjának felülvizsgálata (review) során. A Scrum modell értékelése A Scrum a szoftvercsapatok körében népszerűvé vált, de megvannak a maga előnyei és hátrányai. A Scrum modell előnyei: Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 211 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Flexibilitás A folyamatok rugalmasak változtatásokat. és iteratívak, lehetővé téve a visszajelzéseken alapuló Ügyfelek bevonása Az érdekelt felek rendszeres visszajelzései biztosítják az

ügyfelek igényeihez való igazodást. Javított minőség A gyakori tesztelés és felülvizsgálat javítja a termék minőségét. Csoportszintű együttműködés A modell a csapatmunkát és a kommunikációt hangsúlyozza a napi megbeszélések és a rendszeres megbeszélések révén. A Scrum modell hátrányai: Szükséges diszciplína A Scrum szigorúan betartatja a gyakorlatokat, ami kihívást jelenthet. Terjedelmi korlátok Fennáll annak a veszélye, hogy egyre több ügyfélkérés kerül hozzáadásra a product backloghoz, ami hátráltatja a releaset, ha a product backlog nincs megfelelőn menedzselve. Szerepzavar A standard szerepek, mint például a Scrum master és a product owner, félreérthetők vagy rosszul alkalmazhatók. Erőforrás-intenzivitás A napi megbeszélések és a gyakori felülvizsgálatok (review) időigényesek lehetnek. Kanban A Kanban egy másik népszerű agilis keretrendszer, amely a munka vizualizálására, a munkafolyamatok

irányítására és a folyamatok javítására helyezi a hangsúlyt. Az egyik nagy különbség a Scrum és a Kanban között az, hogy a Kanban nem igényel fix hosszúságú iterációkat, így rugalmasabbá teszi a folyamatos szállítást, és képes egyensúlyt teremteni a különböző munkaprioritások között. A következő alfejezetekben megvizsgáljuk, hogy mire van szüksége a csapatoknak egy Kanban projekt megvalósításához. 212 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek Kanban boardok A Kanban board egy olyan vizuális eszköz, amely nyomon követi a munka szakaszokon keresztül történő haladását. A fő és legfontosabb oszlopok a “To Do” (teendők), “In Progress” (folyamatban), és “Done” (kész). További oszlopok is hozzáadhatók, de ennek a három fő oszlopnak mindenképpen szerepelnie kell a táblán. Ez a vizualizáció segít a

csapatoknak abban, hogy felismerjék a szűk keresztmetszeteket, és egy szempillantás alatt lássák a feladatok állapotát. Work in Progress Limit A work in progress limit (folyamatban lévő munka WIP) korlátozása segít elkerülni a multitaskingot és javítja a koncentrációt. Ezzel a korlátozással van egy pont, amikor már nem lehet több feladatot hozzáadni a “Folyamatban” oszlophoz. Így a fejlesztők nem lesznek túlterhelve feladatokkal, és azokra tudnak koncentrálni, amelyeken éppen dolgoznak. Csapattagok A csapattagok felelősek a feladatok elvégzéséért és a Kanban-rendszeren belüli zökkenőmentes folyamatok kialakításáért. Együttműködnek a munkák rangsorolásában, valamint a felmerülő problémák kiemelésében és kezelésében. Kanban Manager A Kanban manager felügyeli a Kanban folyamatot, és biztosítja, hogy a csapat a Kanban elveket és gyakorlatokat kövesse. Ez a menedzser segíti a megbeszéléseket, felügyeli a

munkafolyamatokat, és segít megoldani minden felmerülő problémát. A Kanban modell értékelése A modell lényege egyszerű. Nézzük az előnyöket és hátrányokat! A Kanban modell előnyei: Visual workflow (vizuális munkafolyamat) A kanban boradok előrehaladásáról. egyértelmű láthatóságot biztosítanak a munka állapotáról és Flexibilitás Mivel a modell nem tartalmaz rögzített iterációkat, jelentős alkalmazkodóképességgel támogatja a folyamatos szállítást. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 213 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment A feladatokra vonatkozó korlátozások A WIP-korlátozás segít megelőzni a csapattagok túlterheltségét, és ezáltal javítja a koncentrációt és a hatékonyságot. Folyamatos fejlesztés A modell ösztönzi a rendszeres értékelést és a folyamatok javítását. A Kanban modell hátrányai: Időkeretek hiánya Az

időgazdálkodás meghatározott határidők nélkül kihívást jelent. Kevesebb szerkezet A modellből hiányozhat az a struktúra, amelyre néhány csapatnak szüksége van ahhoz, hogy szervezett maradjon. Szükséges diszciplína A hatékony WIP-korlátok és a board irányítása gondos figyelmet igényel. Lehetséges túlegyszerűsítés A feladatleírások túlságosan leegyszerűsíthetik az összetett projekteket, ha nem átgondoltan hajtják őket végre. DevOps A DevOps egy olyan szoftverfejlesztési megközelítés, amely integrálja a fejlesztői (Dev) és az üzemeltetési (Ops) csapatokat az együttműködés, a hatékonyság és a szállítási sebesség növelése érdekében. A DevOps elsődleges célja a szoftverfejlesztési életciklus lerövidítése és a folyamatos szállítás biztosítása magas szoftverminőség mellett. A DevOps hangsúlyt fektet az automatizálásra, a folyamatos integrációra és a folyamatos szállításra (CI/CD), valamint a

hagyományosan elszigetelt csapatok közötti szoros együttműködésre. Az automatizálás kulcsfontosságú olyan DevOps feladatok esetében, mint a kódintegráció, a tesztelés, a telepítés és az infrastruktúra kezelése. Az ismétlődő feladatok automatizálása csökkenti a hibákat, felgyorsítja a folyamatokat, és lehetővé teszi a csapatok számára, hogy a stratégiai szempontból fontosabb munkára összpontosítsanak. A folyamatos felügyelet és naplózás elengedhetetlen a rendszer állapotának és teljesítményének fenntartásához. A DevOps-gyakorlatok közé tartozik az átfogó felügyeleti és naplózási rendszerek felállítása a problémák észlelése, a trendek elemzése és a rendszer megbízhatóságának javítása érdekében. 214 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek A DevOps modell értékelése Bár a DevOps erősen

ajánlott a modern szoftverprojektek számos típusa esetén, az előnyöket és hátrányokat figyelembe kell venni. A DevOps modell előnyei: Gyorsaság és hatékonyság A modell felgyorsítja a fejlesztési és telepítési ciklusokat az automatizálás segítségével. Javított együttműködés A modell áthidalja a szakadékot a fejlesztési és az üzemeltetési csapatok között. Folyamatos szállítás A modell biztosítja, hogy a szoftver mindig telepíthető állapotban legyen, ami gyakoribb releaseket eredményez. Nagy megbízhatóság Az automatizált tesztelés és felügyelet növeli a megbízhatóságot és csökkenti a hibák számát. A DevOps modell hátrányai: Kulturális váltás A modell jelentős kulturális változást és a szervezet egészének részvételét igényli. Komplexitás A CI/CD-csatornák és az automatizált infrastruktúra kezelése összetett lehet. Biztonsági kockázatok A folyamatos telepítés biztonsági résekkel járhat, ha nem kezelik

gondosan. Eszköztúlterhelés A DevOps az eszközök és technológiák sokasága miatt túlterhelő lehet. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 215 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Gyakorló feladatok 1. Mit jelent az agilitás? 2. Mi a Scrum definíciója a Scrum Guide szerint? 3. Miért tud a Scrum jobban teljesíteni a vízesésmodellnél az ügyfelek visszajelzései tekintetében? 4. Mik a DevOps pozitív aspektusai? 216 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek Gondolkodtató feladatok 1. Gyorsan változó környezet esetén miért nem a vízesésmodell a legjobb? 2. Mi történhet, ha a Scrum master szerepe rosszul van megvalósítva? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 217 Open Source Essentials (Version 1.0) | Témakör

055: Projektmenedzsment Összefoglalás A projektmenedzsment jelentősége a szoftverfejlesztésben, különösen a nyílt forráskódú projektekben, abban rejlik, hogy képes struktúrát biztosítani, javítani a kommunikációt, meghatározni a szerepeket, kezelni a kockázatokat és biztosítani a minőséget. Ezek az elemek döntő fontosságúak a projektek sikeres befejezéséhez, valamint az együttműködő és produktív fejlesztési környezet elősegítéséhez. Ebben a leckében a vízesésmodellt, az agilis módszertanokat és a DevOps-ot tekintettük át. E modellek ismerete elengedhetetlen a szoftverfejlesztés projektmenedzsmentjének megértéséhez. Nincs tökéletes helyes munkamódszer minden projekt más és más. Ebben a leckében megismerhettük a különböző megközelítések szerepeit, folyamatait, valamint előnyeit és hátrányait, ami a jövőben segíthet megérteni és esetleg kiválasztani a megfelelő modellt egy projekthez. 218 |

learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0551 Szoftverfejlesztési modellek Válaszok a gyakorló feladatokra 1. Mit jelent az agilitás? Az agilitás a gyors reagálási és mozgási képességet fejezi ki, mind a fizikai, mind a szellemi világban. 2. Mi a Scrum definíciója a Scrum Guide szerint? ◦ Egy Product Owner a komplex problémához tartozó munkát egy Product Backlogban sorrendezi. ◦ Egy Scrum Team a munka kiválasztott részét egy értéket képviselő Inkrementummá alakítja egy Sprint folyamán. ◦ A Scrum Team és az érdekelt felek megvizsgálják az eredményeket és ezekhez igazítják a következő Sprintet. ◦ Az előző lépések ismétlődnek újra és újra. 3. Miért tud a Scrum jobban teljesíteni a vízesésmodellnél az ügyfelek visszajelzései tekintetében? Mivel a visszajelzéseket a fejlesztés során gyűjtik, a végtermék jobban megfelelhet az ügyfelek

elvárásainak. 4. Mik a DevOps pozitív aspektusai? Gyorsaság és megbízhatóság hatékonyság Jobb Version: 2024-08-12 együttműködés Folyamatos | CC BY-NC-ND 4.0 alatt licencelve | szállítás Magas learning.lpiorg | 219 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Válaszok a gondolkodtató feladatokra 1. Gyorsan változó környezet esetén miért nem a vízesésmodell a legjobb? A vízesésmodell csak a fejlesztés végén gyűjt visszajelzéseket, így minden olyan követelményt, amelyet a fejlesztők félreértettek, a legvégén kell kijavítani. Ha a környezet nagyon gyorsan változik, ezt a modellt nem szabad használni, mert a fejlesztési ciklus közepén nincs lehetőség a visszajelzésre. 2. Mi történhet, ha a Scrum master szerepe rosszul van megvalósítva? A rosszul bevezetett Scrum master szerep akadályozhatja a csapat képességét a magas minőségű termékek hatékony előállítására, és alááshatja a

Scrum bevezetésének előnyeit. A csapat nem kaphat megfelelő útmutatást a Scrum-gyakorlatokról és -elvekről, ami a keretrendszer következetlen vagy helytelen alkalmazásához vezethet. Ha nincs hatékony Scrum master, aki elhárítja az akadályokat, azok lelassíthatják a haladást és csökkenthetik a csapat termelékenységét. A csapattagok és az érdekelt felek között félreértésekhez és nem összehangolt elvárásokhoz vezető kommunikáció alakulhat ki. A csapatban csökkenhet a morál és a motiváció a megoldatlan problémák, a támogatás hiánya és a Scrum-rendezvények nem hatékony facilitálása miatt. Hatékonysági problémák adódhatnak a rosszul lebonyolított megbeszélésekből, a fókusz hiányából, valamint a sprinttervezés és a reviewk eredménytelenségéből. 220 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment 055.2

Termékmenedzsment / Release menedzsment Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0552 Súlyozás 2 Kulcsfontosságú ismeretek • A általános release típusok megértése • A szoftver verziószámának és a major vagy minor releasek okainak megértése • A szoftvertermékek életciklusának megértése a tervezéstől, a fejlesztésen és a kiadáson át a visszavonásig • A termékverziók dokumentációjának megértése A használt fájlok, kifejezések és segédprogramok listája • Alfa és béta verziók • Release candidates • Feature freeze • Major és minor releasek • Szemantikus verziószámozás • Roadmapek és mérföldkövek • Changelogok • Long Term Support (LTS) • End of Life (EOL) • Backward compatibility Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 221 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Lecke 1 Tanúsítvány:

Open Source Essentials Verzió: 1.0 Témakör: 055 Projektmenedzsment Fejezet: 055.2 Termékmenedzsment / Release menedzsment Lecke: 1/1 Bevezetés A legtöbb szoftver idővel sokféleképpen fejlődik. Valójában ez az egyik csodálatos dolog a szoftverekben: könnyen változtathatók, és csak egy hálózaton keresztül történő átvitelre van szükség ahhoz, hogy mindenki, aki használja a terméket, frissíteni tudja. A fejlesztők tehát új funkciókat adnak hozzá, kijavítják a hibákat és a biztonsági hiányosságokat, új hardverekre portolják a szoftvert, és interfészeket adnak a népszerű programokhoz és szolgáltatásokhoz. Ahogy a szoftver változik, új verziók vagy revíziók (revision) jelennek meg. Ez a lecke a szoftverek tervezésének és módosításának logisztikájával, a több verzióval zsonglőrködő csapatokkal, a verziók elnevezésének konvencióival és a fejlesztés egyéb szervezési aspektusaival foglalkozik, amelyek a

projektmenedzsment tevékenységének egy részhalmazát képezik. A kifejezetten a kiadások (release) időzítésére, elnevezésére és ellenőrzésére vonatkozó logisztikát nevezzük release menedzsmentnek. A releasek jellemzői A kiadások a stabilitás, a visszafelé kompatibilitás (backward compatibility) és a támogatás 222 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment (support) szempontjából eltérőek. A következő szakaszokban megvizsgáljuk az egyes fogalmakat Stabil és instabil releasek A felhasználók által leginkább elvárt egyik tulajdonság szoftver stabilitása. Az első kérdés, amit sokan feltesznek egy új release (kiadás) hallatán, az, hogy “Mennyire stabil?”. Más szóval, megbízhatóan fog-e működni, vagy összeomlik, elrontja az adatokat, vagy hibás eredményeket produkál? A stabilitás egy spektrumon

mérhető, és sokan szívesen használnak egy szoftvert akkor is, ha még vannak benne hibák. A fejlesztőcsapatok azonban hajlamosak a dolgokat egyszerűen kezelni, és binárisan beszélnek stabil (stable) és nem stabil (unstable) kiadásokról. A stabilitás egyszerre utal a szoftver hibáira másrészt annak valószínűségére, hogy a kívülállók számára látható módon megváltozik. A fejlesztők instabilnak tekinthetik egy szoftverkönyvtár egyik kiadását, mert például megváltoztatták a programozók által hívott funkciókat (vagyis mert a programozóknak a következő releaseig esetleg újra kell írniuk a szoftverüket). A felhasználó szempontjából azért is lehet instabil egy szoftver, mert a fejlesztők eltávolítottak egy funkciót. Van valami oka annak, hogy kiadnak egy instabil verziót? Igen: értékesek, mert a felhasználók a projekt korai szakaszában kipróbálhatják az új funkciókat, és tesztelhetik hibakeresés céljából. Azért, hogy

a legfontosabb ügyfelek kipróbálhassák, a legtöbb projekt releaseli a szoftver nagyon korai változatait; ezeket nevezik alfa releasenek. Ezeket senki sem használhatja valódi munkára csak tesztelésre szolgálnak. Valójában a tesztelőknek olyan számítógépeken kell futtatniuk őket, amelyeken nem végeznek fontos munkát, mert az ezekben a releasekben található hibák ténylegesen károsíthatják a számítógépen tárolt adatokat. Amikor a szoftver már közel van ahhoz, hogy stabilnak minősüljön, a projekt általában kiad egy újabb tesztverziót, az úgynevezett béta releaset. Ezeket továbbra is csak tesztelni lehet, nem szabad őket éles (production) környezetben használni. Mind az alfa-, mind a béta-kiadások esetében a fejlesztők rendelkezésére áll egy folyamat a hibák bejelentésére és a hibák kijavítása érdekében tett lépések nyomon követésére. Egyes projektek tartalmaznak még egy szakaszt a béta és a stabil release között,

amikor a fejlesztők már minden hibát kijavítottak, és úgy gondolják, hogy a termék kész. Ez a verzió a release candidate (kiadásra jelölt), amit megmutatnak a kulcsfontosságú ügyfeleknek vagy érdekelteknek, hogy megtervezhessék, hogyan használják majd az új funkciókat. Végül, néhány projekt olyan funkciókat is beépít, amelyek nem teljesen stabilak, mert fontos felhasználók kérték őket. A fejlesztők célja, hogy a felhasználók kipróbálják ezeket a funkciókat, és Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 223 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment elmondják, hogy tetszenek-e nekik, mielőtt a fejlesztők véglegesítenék az interfészeket, és energiát fektetnének a funkciók stabilizálására. Backward Compatibility A legtöbb projekt a backward compatibility-re (visszafelé kompatibilitás) törekszik, ami azt jelenti, hogy nem próbálja eltávolítani a régebbi

verziókban meglévő funkciókat vagy képességeket. A kompatibilitás több szinten is létezhet. Ha például a fejlesztők fenntartják a backward compatibilityt az alkalmazásprogramozási interfésszel (API) kapcsolatban, akkor azt ígérik, hogy a régi forráskód továbbra is működhet, de lehet, hogy újra le kell fordítani. Ha a hardvergyártók vagy az operációs rendszer fejlesztői fenntartják a visszafelé kompatibilitást az alkalmazás bináris interfészére (ABI) vonatkozóan, akkor azt ígérik, hogy ezen felül a régi futtatható fájlok a hardver új verzióin is futtathatók. Később megnézzük, hogyan kezelik a projektek a backward compatibility hiányát, amikor úgy döntenek, hogy a régi interfész valóban nem működik az új funkciókkal vagy környezetekkel, amelyeket támogatniuk kell. Támogatás és End of Life (EOL) A szoftver ideális esetben egyre jobb és jobb lesz, ahogy a fejlesztők felfedezik és kijavítják a problémákat. Idővel

azonban a szoftver környezetében bekövetkező változások miatt a funkciók nem működnek, valamint olyan új hibák is felfedezésre kerülnek, amelyek korábban rejtve maradtak. Az új verziók gyakran kombinálják a biztonsági és hibajavításokat új funkciókkal. Lehet, hogy nekünk ezek az új funkciók nem kellenek (sőt, lehet, hogy jobban tetszik valamelyik régi, amit a fejlesztők eltávolítottak, hogy helyet csináljanak az újaknak), de az emberek általában azért frissítenek az új verzióra, hogy megkapják a biztonsági javításokat, amelyek megvédik őket a rosszindulatú támadásoktól. Vannak, akik a szoftverek régi verzióit használják, és nem hajlandóak frissíteni. Ennek oka általában az, hogy az új verzió tönkretesz valamit, ami eddig működött náluk. Amikor a vállalatok pénzt kérnek a frissítésekért, néhány ügyfél nem hajlandó frissíteni, mert nem akarja kifizetni a plusz pénzt, de a nyílt forráskódú szoftvereknél

ritkán kell fizetni a frissítésekért. A fejlesztők a régi verziók felhasználói igényeket úgy elégítik ki, hogy a régi verziókban lévő hibákat javítják, anélkül, hogy a szoftvert tönkretevő funkciókat adnának hozzá. Természetesen a fejlesztők ezt nem tehetik meg örökké, mert ez időt és energiát von el az új munkától. Eljön az idő, amikor megtagadják a régi verzió javítását, és azt mondják a felhasználóknak, hogy vagy frissítsenek, vagy készítsenek saját javításokat. 224 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment A hibák és biztonsági hiányosságok kijavítását a szoftver supportjának (támogatás) nevezik. Ez különbözik a helpdeskek és más, a felhasználókat a szoftver megértésében segítő személyek által nyújtott támogatástól. A release menedzsment szempontjából a supported

release az, amikor a fejlesztők megígérik, hogy kijavítják a hibákat, míg az unsopported release az, amikor nem teszik meg. Megjegyzendő, hogy a “support” fogalma leginkább a vállalatok vagy nagy szervezetek által készített szoftverekre vonatkozik. A kisebb nyílt forráskódú projektek, amelyek nagymértékben függnek az önkéntesektől, gyakran csak azt ígérik, hogy a lehető legtöbbet teszik a hibák kijavításáért és az új verziók kiadásáért. Nem látják szükségét annak, hogy a régi verziókat javítsák. Mivel a kód nyílt forráskódú, azok a felhasználók, akik nem akarnak frissíteni, fizethetnek valakinek a régi verzió javításáért. Ha van support, a fejlesztők közzétesznek egy ütemtervet, amelyben jelzik, hogy meddig támogatják az egyes verziókat. A dátumot, amikor a támogatás megszűnik, a szoftver életciklusának végének (end of life EOL) nevezik. A felhasználók az EOL-ig megtarthatják a régi verziót, és

számíthatnak a hibák kijavítására, de az EOL után frissíteniük vagy kockáztatniuk kell. A nagyobb projektek, mint például a GNU/Linux Debian disztribúciója, hosszú távú támogatású (long term support LTS) verziókat kínálnak. Ez egyszerűen azt jelenti, hogy a fejlesztők bizonyos számú évig folyamatosan javítják a hibákat. Azok az ügyfelek, akik nagyra értékelik a stabilitást, valószínűleg félnek telepíteni a sok változtatást tartalmazó szoftverek verzióit, ha a változtatások miatt olyan folyamatok sérülnek, amelyekre az ügyfelek támaszkodnak. Az ilyen ügyfelek, különösen a nagy intézmények, szeretik az LTS verziók biztonságát. Szoftver verziózás: Major, minor, és patchek Láttuk, hogy a verziókezelés bonyolult: egyes verziók hibákat javítanak, míg mások új funkciókat adnak hozzá, és a verziók stabilitása is eltérő lehet. A fejlesztők címkékkel próbálják jelezni, hogy az egyes verziókban mekkora

változás történt a szoftverben. A szinte minden projekt által elfogadott konvenciókat a verziók címkézésére szemantikus verziókezelésnek (semantic versioning) nevezik. Vegyük példának a Linux kernel korai történetét. Linus Torvalds az első stabil kiadást 10-nak címkézte. Ahogy fejlesztette a kernelt, a következő verziók az 11-es, 12-es lettek és így tovább A kezdő 1 volt a major verzió, a pont utáni számok pedig a minor verziókat jelölték. Feltételezhetjük, hogy az 1.2-es verzió több funkcióval rendelkezett és többet kínált, mint az 11-es verzió Számtalan kisebb release is volt azonban, néha csak néhány hiba kijavítására. Hogy megmutassa, hogy a változtatások csak kis mértékben befolyásolták a kernel használatát, Torvalds egy harmadik számot, az úgynevezett patch-et is beiktatott. Így az 10-ból 101 lett, majd 102, és így Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 225 Open Source

Essentials (Version 1.0) | Témakör 055: Projektmenedzsment tovább. A patchek száma 0-ról indul, amikor egy új minor verzió jelenik meg, és a minor verziók száma 0ról indul, amikor egy új major verzió jelenik meg. A fejlesztők a verziókat egy “x”-szel csoportosítják, hogy ezzel jelezzék, hogy több verzióról van szó, például az 1.x az 1 major verzió alatti összes verziót jelenti De mi a különbség egy olyan változtatás között, amely egy új kisebb verzióhoz vezet, és egy olyan között, amely megérdemli, hogy egy új major verziót kapjon? Általában évek telnek el egy új major verzió kiadása előtt, és annak egy nagyon jelentős frissítést kell jelenteni. A fejlesztők általában igyekeznek fenntartani a backward compatibilityt a verziók változtatása során. Ha a backward compatibility nem tartható fenn, a fejlesztőknek növelniük kell a major verziót. Néha nullánál kisebb verziószámot láthatunk, általában 0.9-et A vezető

nulla a szoftver korai verzióját jelzi, amely instabil és nem alkalmas éles környezetben történő használatra. Nincs garancia a backward compatibilityre, amíg a fejlesztők ki nem adják az 1-el kezdődő verziókat. Az alfa verziókat általában úgy jelölik, hogy a release számához hozzáadjak az “a” betűt vagy az “alpha” szót, például 3.6alpha Hasonlóképpen, a béta verzióknál a release száma után “b” vagy “beta” szerepel. A szoftvertermék életciklusa Ne gondoljuk azt, hogy a fejlesztők élete egyszerű. Mindenki akar tőlük valamit Én azt akarom, hogy ez a hiba a képernyő elrendezésében minél előbb kijavításra kerüljön, míg valaki más azt mondja, hogy a fájlnevek hibája elsőbbséget élvez. A felhasználók új funkciókért kiáltanak, és amikor különböző fejlesztők párhuzamosan dolgoznak különböző funkciókon, azt tapasztalják, hogy az egyikük változtatásai eltaposhatják a másikukét. A

projektmenedzsment és e feladatok release menedzsmentnek nevezett részhalmaza foglalkozik ezekkel a kérdésekkel. Általában egy vezető projekttag vállalja a felelősséget ezért a menedzselési feladatért. Az emberekhez hasonlóan a szoftververziók is életcikluson mennek keresztül. Mindegyik az új funkciók és egyéb szükséges változtatások megvitatásával kezdődik, majd fejlesztési és tesztelési fázisokon megy keresztül, és tervezett módon kerül bevezetésre. 226 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment Tervezés és roadmapek A fejlesztők igyekeznek jóval előre megtervezni, hogy milyen változtatásokat szeretnének végrehajtani egy terméken. A kereskedelmi cégeknél a marketingesekkel beszélnek, akik szűrik és összefoglalják, amit az ügyfelek mondanak nekik. A nyílt forráskódú projektek inkább a fejlesztők és

a felhasználók által benyújtott ötletekre támaszkodnak, amelyeket egy issue tracker nevű adatbázisban rögzítenek. Ha ki kell javítani egy hibát, vagy egy új funkciót szeretnénk, akkor kitöltünk egy issue-t. A fejlesztők ezután rangsorolják a változtatásokat, és eldöntik, hogy melyiket ki fogja kezelni. Hogyan választják ki és rangsorolják a változtatásokat? Ez zűrös folyamat lehet. A nyílt forráskódú projektek jó projektmenedzserei azonban ösztönzik a széles körű hozzájárulást, miközben biztosítják, hogy megszülessenek a döntések. Egyes projektek még konferenciákat is tartanak, ahol a résztvevők megvitatják a prioritásokat. Egy közzétett roadmap (ütemterv) tartalmazza a fejlesztésekre és változtatásokra vonatkozó terveket. Ez több kiadásra és több évre is kiterjedhet Minden egyes lépést mérföldkőnek (milestone) nevezünk, és lehet, hogy céldátum is társul hozzá, de lehet, hogy nem. Release ütemezés A

releasek ütemezésének két alapvető módja van: idő- és funkcióvezérelt. Egy projekt ígérhet rendszeres időközönként például félévente egy releaset, és tartalmazhat mindent, ami addigra elkészül. Alternatív megoldásként a projekt ígérhet bizonyos funkciókat egy kiadásban, és hagyhatja, hogy a fejlesztők annyi időt szánjanak a funkciók befejezésére, amennyire szükségük van. Ahogy közeledik a kiadás időpontja, a release menedzser meghatározza az alfa, béta és stabil releasek időpontját. A csapattagok rendszeresen áttekintik a hibajelentéseket, és igyekeznek úgy megtervezni a munkájukat, hogy ezeket a mérföldköveket tartani tudják. A release befejezéséhez a projektnek fel kell hagynia az új funkciókkal kapcsolatos ötletek elfogadásával, és a meglévő funkciók megfelelő működésére kell összpontosítania. Ezt a pillanatot nevezzük feature freeze-nek (funkció befagyasztás). A termékverziók dokumentációja A

roadmapek, mint már említettük, ismertetik azokat a funkciókat, amelyeket a fejlesztők az egyes releasekbe terveznek beépíteni. A releaset a változtatások listája, az úgynevezett changelog kíséri Ez a changelog általában felsorolja az új funkciókat, a meglévő funkciók módosításait, az eltávolított funkciókat, azokat a funkciókat, amelyeket a fejlesztők a jövőben el kívánnak Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 227 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment távolítani (az úgynevezett deprecated (elavult) funkciókat), valamint a hibajavításokat. A changelogok ezért elég hosszúak és részletesek lehetnek. A felhasználóknak különös figyelmet kell fordítaniuk az eltávolított vagy deprecated funkciókra, mivel lehet, hogy meg kell változtatniuk a programjaikat vagy a termék használatának módját. Nyilvánvaló, hogy a fejlesztők igyekeznek csak azokat a

funkciókat eltávolítani, amelyekre már senkinek sincs szüksége. A termékdokumentációt minden release esetén módosítani kell a termékben bekövetkezett változásoknak megfelelően. Ez a feladat időigényes lehet, és a fejlesztők könnyen kihagyhatnak egy-egy változtatást, vagy elmaradhatnak a dokumentáció elkészítésével. 228 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment Gyakorló feladatok 1. Mi különbözteti meg a stabil releaset az instabiltól? 2. Számíthatunk-e funkcióváltozásra a 2614 és a 2615 nevű release között? 3. Számíthatunk-e funkcióváltozásra a 260beta és a 260 nevű release között? 4. Miért számíthatunk arra, hogy az 10 release esetén nem lesz backward compatibility a 09 release-vel? 5. Ha biztonsági hibát fedezünk fel egy verzióban a feature freeze után, de még a release előtt,

kijavíttathatjuk a hibát? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 229 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Gondolkodtató feladatok 1. Tegyük fel, hogy a nyílt forráskódú szoftver egyik verzióját az EOL után is használni szeretnénk, mert van benne egy olyan funkció, amelyre szüksége van. Mit tehetünk, hogy továbbra is használható maradjon a verzió? 2. Melyek azok a kritériumok, amelyek alapján egy hibajavítást vagy funkciókérést választanak ki a többi helyett? 230 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment Összefoglalás Ez a lecke a releaseket megkülönböztető fő jellemzőket ismertette: stabilitás, backward compatibility és support. Szó volt a verziónevek és -számok jelentéséről, valamint a release menedzsment legfontosabb

szempontjairól, beleértve a dokumentációról is. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 231 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Válaszok a gyakorló feladatokra 1. Mi különbözteti meg a stabil releaset az instabiltól? A kiadások kétféleképpen tekinthetők stabilnak: Jól működnek anélkül, hogy összeomlanának vagy hibás eredményeket adnának, és a felhasználók vagy programozók számára bemutatott interfész várhatóan visszafelé kompatibilis a korábbi verziókkal. 2. Számíthatunk-e funkcióváltozásra a 2614 és a 2615 nevű release között? Nem. A harmadik szám a szemantikus verziószámozásban egy patchet jelöl, amely egy hiba kijavítására vagy más kisebb feladat elvégzésére, például újraformázásra készült. A funkcióváltásnak minor vagy major releasehez kell vezetnie. 3. Számíthatunk-e funkcióváltozásra a 260beta és a 260 nevű release

között? Nem. A béta verzió egy tesztverzió, amely tartalmazza az összes olyan funkciót, amely a végleges kiadásba kerül. 4. Miért számíthatunk arra, hogy az 10 release esetén nem lesz backward compatibility a 09 release-vel? A 0.9-es szám kifejezetten figyelmezteti a potenciális felhasználókat, hogy a szoftver még tervezés alatt áll, és nagy valószínűséggel más lesz a kezelőfelülete, amikor stabilizálódik az 1.0 verzió. 5. Ha biztonsági hibát fedezünk fel egy verzióban a feature freeze után, de még a release előtt, kijavíttathatjuk a hibát? Minden bizonnyal. A feature freeze és a release közötti időszakot arra szánják, hogy felfedezzék és kijavítsák a hibákat, beleértve a biztonsági hibákat is. 232 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0552 Termékmenedzsment / Release menedzsment Válaszok a gondolkodtató feladatokra 1. Tegyük fel, hogy a

nyílt forráskódú szoftver egyik verzióját az EOL után is használni szeretnénk, mert van benne egy olyan funkció, amelyre szüksége van. Mit tehetünk, hogy továbbra is használható maradjon a verzió? Az EOL után a projekt fejlesztői nem kötelezik el magukat a hibák javítására és ebbe a biztonsági hibák is beletartoznak. Ezért érdemes szorgalmasan követni a projekt hibakövetőjét és levelezési listáit, hogy megtudjuk, milyen hibák merülnek fel. Mivel a kód elérhető, javíthatjuk és javítanunk is kell azokat a hibákat, amelyek a mi verziónkban vannak. Elméletileg még új funkciókat is beépíthetünk a verziódba. Ez gyakorlatilag az eredeti verzió elágazását (fork) jelentené. 2. Melyek azok a kritériumok, amelyek alapján egy hibajavítást vagy funkciókérést választanak ki a többi helyett? A hibajavítások esetében a kritériumok közé tartozik a hiba súlyossága (amelyet a hibakövetőbe való bekerülése után rendelnek

hozzá) és a hiba által érintett felhasználók száma. Egy funkció esetében a kritériumok közé tartozik a funkciót igénylő felhasználók száma, a kódolás nehézsége és a program más részeire gyakorolt lehetséges hatása. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 233 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment 055.3 Közösségi menedzsment Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0553 Súlyozás 2 Kulcsfontosságú ismeretek • A nyílt forráskódú projektekben betöltött szerepek megértése • A nyílt forráskódú projektek általános feladatainak megértése • A nyílt forráskódú projektekhez való hozzájárulás különböző fajtáinak megértése • A nyílt forráskódú projektekhez hozzájáruló különböző személyek megértése • A szervezetek szerepének megértése a nyílt forráskódú projektek

fenntartásában • A jogok átruházásának megértése az egyénekről a projektet fenntartó szervezetre való átruházása • A nyílt forráskódú projektekre vonatkozó szabályok és irányelvek megértése • A hozzájárulások tulajdonításának és átláthatóságának megértése • A sokszínűség, a méltányosság, szempontjainak megértése a befogadás és A használt fájlok, kifejezések és segédprogramok listája • Szoftverfejlesztés • Dokumentáció • Dizájnok és művészeti alkotások • Felhasználók támogatása 234 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 a megkülönböztetésmentesség Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment • Fejlesztők • Release menedzserek • Felhasználók • Projektvezetők és jószándékú diktátorok • Magánszemélyek és vállalatok • Lelkes érdeklődők és szakemberek • Alapcsapattagok és alkalmi közreműködők

• Kód és dokumentáció hozzájárulás • Hibajelentés • Forkok • Alapítványok és szponzorok • Hozzájárulási megállapodások • Developer Certificates of Origin (DCO) • Kódolási irányelvek • Magatartási kódexek Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 235 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 055 Projektmenedzsment Fejezet: 055.3 Közösségi menedzsment Lecke: 1/1 Bevezetés Egy nyílt forráskódú projekt létrehozásának egyik fő oka, hogy sok különböző ember hozzájárulását vonzza. A nyílt forráskód megkönnyíti a projekt felhasználóinak különböző igényeire és érdeklődési körére való reagálást, és megkönnyíti, hogy hasznosítani tudjuk a különböző készségeket. Ezért a sokszínű közösség központi szerepet játszik a projekt sikerében A közösség az

a hely, ahol a kreatív erők összefognak a projekt sikeréért. Ez a lecke a szabad szoftverek és a nyílt forráskódú közösségek alapvető elemeit, valamint a bennük dolgozók együttműködését ismerteti. Természetesen, mivel a közösségek különböző emberekből állnak, és mivel a projekteknek különböző céljaik és követelményeik vannak, minden közösség egyedi. Szerepkörök a nyílt forráskódú projektekben A legtöbb nyílt forráskódú projekt fő kimenete a szoftver, így az ilyen projektekhez legalább programozókra, szoftvertervezőkre vagy architektekre, tesztelőkre, release menedzserekre és más kódfejlesztési szakértőkre van szükség. A dokumentáció általában szintén része az ilyen projekteknek, így a közösségnek szerzőkre, szerkesztőkre és véleményezőkre is szüksége van. 236 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0553 Közösségi

menedzsment Más projektek esetleg nem kódot, hanem más “kézbesítendő termékeket”, például könyvet, művészeti vagy zenei projektet, vagy egy politikai jelentést hoznak létre. A Wikipédia jól ismert példája a szöveges dokumentumokra és médiára összpontosító nyílt forráskódú projektben való együttműködésnek. Ezekben a projektekben szakértőkre van szükség a tervezéshez, a gyártáshoz és a végtermék kiszállításához. A közösségek számos más általános készségből is profitálnak, mint például a marketing és az igehirdetés, az adminisztráció, a jogi tanácsadás, a művészi tehetség a logók vagy a dokumentációban szereplő ábrák elkészítéséhez, valamint a projekt weboldalának és egyéb kommunikációs eszközeinek karbantartásához szükséges készségek. A nyílt forráskódú projektek szervezhetnek fizikai összejöveteleket, sőt konferenciákat is, ebben az esetben pedig szervezőkre van szükségük, akik

életre keltik ezeket az eseményeket. Az alábbi bekezdésekből megtudhatjuk, hogy milyen típusú készségeket keres egy közösség. Ezek az általános szerepek tovább oszthatók különböző célzott feladatokra. Ilyen feladat például az, hogy egyes írók más írók munkáját szerkesztik. A programozók között sokféle tapasztalat létezik. Egy egészséges projektnek mindig szüksége van néhány veterán programozóra (vagy senior programozóra), akik jól ismerik a kódot és a kódolási szabványokat, valamint újoncokra (newbie), akik új ötleteket és egyszerű segítséget nyújtanak, például hibajavításokban. Néhány újoncból remélhetőleg a veteránok következő generációja lesz A kód minősége gondos ellenőrzést igényel abból a szempontból, hogy mi kerül a felhasználókkal megosztott központi repositoryba. Ezért néhány veterán committer státuszt kap Ők felelősek a hozzájárulások minőségének, hasznosságának és a

kódolási szabványoknak való megfelelésének ellenőrzéséért. Ők rendelkeznek azzal a kiváltsággal, hogy a javasolt kódot elfogadják és hozzáadják a trusted (megbízható) repositoryba. Más közreműködők a kódot a committereknek nyújtják be felülvizsgálatra. Sok committer és más veterán is mentorálja az új közreműködőket, hogy megtanítsa nekik a szabványokat és gyakorlatokat, amelyek szükségesek ahhoz, hogy kódjuk elfogadásra kerüljön. Egyes committerek nem értékelik azt ajándékot, amit a közreműködők adnak. Ha a hozzájárulás nem felel meg a minőségi vagy kódolási szabványoknak, a committer egyszerűen elutasíthatja azt. Az elutasítás azonban elriasztja a leendő közreműködőt, és így értékes oktatási lehetőséget veszít el. Ne feledjük, hogy a jó committerek egyben mentorok is Ezért tippeket adnak a közreműködőnek arra vonatkozóan, hogy hogyan hozhatja a kódot a szabványoknak megfelelő szintre, és

idővel együtt dolgoznak. Ha a hozzájárulás valóban használhatatlan, akkor legalább meg kell köszönni a közreműködőnek, és arra kell bátorítani, hogy dolgozzon valami máson a projektben. Fontos segíteni az embereket abban, hogy felfedezzék és fejlesszék a képességeiket Amikor egy vállalat nyílt forráskódú projektet indít, néha saját munkatársai közül választ Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 237 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment committereket, hogy ellenőrizni tudja a projekt irányát és minőségét. Gyakran azonban a vállalatok lehetővé teszik, hogy nem alkalmazottak is committerekké váljanak, ha azok készségesnek és elkötelezettnek bizonyulnak. A projektvezetők (project lead) kritikus döntéseket hoznak, például arról, hogy milyen új funkciókat támogassanak. Ezeknek a projektvezetőknek gyakran nem kódolási döntéseket is meg kell

hozniuk, például arról, hogy hogyan népszerűsítsék a projektet, hogyan oldják meg a nagyobb nézeteltéréseket, és hogyan szerezzenek finanszírozást. A projektvezetők és a committerek szorosan együttműködnek a release menedzserekkel, hogy eldöntsék, mikor stabil a kódbázis és mikor áll készen arra, hogy megosszák a felhasználókkal. Néhány projektnek egyetlen projektvezetője van, akit gyakran jóindulatú diktátornak (benevolent dictator) neveznek. Ez gyakran egy olyan személy, aki a projektet elindította (jól ismert példa Linus Torvalds a Linux esetén), és aki nagy tekintéllyel, sőt karizmával rendelkezik. A legtöbb projekt azonban inkább a projektvezetők kis bizottságát hozza létre egyetlen jóindulatú diktátor helyett. Még a Linux projekt is áttért a bizottsági megközelítésre A projektek arra is felkérhetnek bizonyos közreműködőket, hogy nyújtsanak felhasználói támogatást a projekt fórumain. Az egészséges

projekteknek azonban sok hozzáértő felhasználóval kell rendelkezniük, akik támogatják egymást. Ezt a szakaszt egy nagyon fontos szereppel zárjuk: a közösségi menedzserrel. Ez az a személy, aki felelős a nyílt és konstruktív kommunikáció fenntartásáért, valamint azért, hogy a közösség haladjon a célja felé. A közösségi menedzser tudja, hogyan kell a közreműködőket felvenni és motiválni, a vitákat megoldani, a közösség tagjait megvédeni a visszaélésekkel szemben, és képes egyéb, a közösség egészségének megőrzését szolgáló feladatokat ellátni. Gyakori feladatok nyílt forráskódú projektekben A nyílt forráskódú projektek sok szempontból ugyanazokat a feladatokat tartalmazzák, mint az egyetlen szervezeten belül megvalósuló hagyományos projektek. Például minden kód tesztelést igényel. A nyílt forráskódú projektek azonban bizonyos szempontból különböznek a zárt forrósákódúaktól, ahol csak korlátozott

számú ember változtathatja meg a kódot, és ahol a forráskódot gyakran elrejtik a nyilvánosság elől. A vállalatok például általában képzett minőségbiztosítási (QA) munkatársakat bíznak meg a kód tesztelésével. Sok nyílt forráskódú projekt azonban csak megkéri a felhasználókat, hogy teszteljenek minden egyes kiadást. (A saját fejlesztésű projektek a QA mellett a felhasználókat is bevonják a tesztelésbe.) Egy másik példa a különbségekre: egy zárt projekt általában fizetett fejlesztőket rendel ki konkrét 238 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment feladatokhoz, és megmondja nekik, hogy hetente mennyi időt kell a feladatokra fordítaniuk. Néhány nyílt forráskódú projektben olyan közreműködők dolgoznak, akiket a munkáltatójuk fizet, sőt néha maga a projekt alkalmazza őket, és akiknek ugyanúgy feladatokat

osztanak ki, mint a védett fejlesztőknek. A legtöbb egészséges projektben azonban a hozzájárulások nagy része önkéntesektől származik, akik csak akkor végzik el a feladatokat, amikor az idejük engedi. Mivel a projekt nem támaszkodik arra, hogy minden önkéntes határidőre befejezi a projektet, előfordulhat, hogy egy nyílt forráskódú kiadás addig késik, amíg a fejlesztők úgy érzik, hogy a funkciók elkészültek, vagy pedig fix időpontokban adják ki, bármilyen, addig elkészült funkcióval. A kommunikáció mind a szabadalmaztatott, mind a nyílt forráskódú projektek esetében kritikus fontosságú, de gyakran eltérő módon zajlik. A saját fejlesztésű projektek gyakran egy irodában gyűjtik össze a csapatot, és rendszeresen ütemezett megbeszéléseket tartanak egy fejlesztési módszertan, például a SCRUM alapján. Mivel a nyílt forráskódú projektek földrajzilag szétszórtak, az ilyen módszertanok ritkák. Ehelyett a kommunikáció

aszinkron módon, online zajlik Röviden, a szabad szoftverek és a nyílt forráskódú projektek gyakran ugyanazokat a célokat érik el, mint a szabadalmaztatott projektek, de eltérő módon. A hibajelentés a szoftverfejlesztés kritikus része, amely saját szerepkörökkel jár. Valakinek figyelemmel kell kísérnie a hibaadatbázist, és ki kell jelölnie a prioritásokat. Ha egy hiba kritikus (és különösen, ha gyengítheti a szoftver biztonságát), akkor egy kompetens szakembert kell megbízni a javításával. A projektvezetőknek és a közösségi menedzsereknek át kell tekinteniük a projektben való részvételt, és meg kell nézniük, hol vannak hiányosságok. Túl kevesen hajlandóak tesztelni a kódot? Hiányzik a dokumentáció? Túl sok veterán vagy vezető projekttag távozik anélkül, hogy pótolnák őket? A projektvezetők és a közösségi menedzserek a szükséges szerepek betöltéséhez szükséges emberek toborzására összpontosíthatnak. A nagy

projektek projektvezetői és közösségi menedzserei gyakran gyűjtenek mérőszámokat is, hogy fontos dolgokat tudjanak meg, például azt, hogy a jelentős hibákat időben kijavítják-e. A nyílt forráskódú hozzájárulások fajtái Amint azt egy korábbi szakaszban már kifejtettük, azokat az embereket, akik kódot, dokumentációt vagy más elemeket tesznek a központi repositoryba, úgy hívjuk, hogy contributors (közreműködők). A projekt azon tagjait, akik jóváhagyják a hozzájárulásokat és hozzáadják azokat a repositoryhoz, committers-nek nevezzük. Egyes tagok a szoftverfejlesztés során más általános szerepeket is betöltenek. Bár a contributor kifejezést általában annak tartják fenn, aki kódot vagy a projekt hivatalos Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 239 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment kínálatának más részét fejleszti, mindenki, aki részt vesz a

projekt sikerében, valamilyen módon hozzájárul, és ezt meg kell köszönni neki. Ezen nem hivatalos hozzájárulások közé tartozik egy hiba bejelentése, egy kérdés megválaszolása egy fórumon, adományozás vagy pénzgyűjtés, és a projekt népszerűsítése kívülállók számára. Akárcsak a zárt forráskódú projektek, a nyíltak is megkérdezik a felhasználókat, hogy mit szeretnének a funkciók, a teljesítmény javítása vagy a projekt egyéb változtatásai tekintetében. Ezek a felhasználók fontos hozzájárulásokat tesznek azzal, hogy hangot adnak véleményüknek. A nyílt forráskódú közreműködők típusai Sok közösség nem csak magánszemélyektől, hanem olyan vállalatoktól is kap hozzájárulásokat, amelyek fizetnek az alkalmazottaiknak, hogy hozzájáruljanak egy olyan projekthez, amelyet a vállalat fontosnak tart az üzleti tevékenysége szempontjából. Néha feszültséget okozhat, ha a fizetett munkatársak közvetlenül az

önkéntesek mellett vannak. Az önkéntesek úgy érezhetik, hogy kihasználják őket, vagy attól tarthatnak, hogy a fizetett közreműködők megpróbálják a projekt irányát a munkaadóik érdekeinek megfelelően alakítani. A közösségi menedzsernek és a projekt vezetőinek garantálniuk kell, hogy minden elfogadott hozzájárulás az egész projekt és a felhasználók számára előnyös legyen. Az önkénteseket is motiválni kell arra, hogy személyes okokból vegyenek részt, akár a közösség iránti lojalitásból, akár saját igényeik kielégítése miatt. Vannak, akik rendszeresen hozzájárulnak egy projekthez, és hosszú távú felelősséget vállalnak; ezeket nevezzük core csapattagoknak. Az egészséges közösségekben is vannak alkalmi közreműködők, akik hibákat jelentenek vagy tanácsokat írnak a fórumokon, de nem várható el tőlük, hogy felelősséget vállaljanak a projektért. Hasonlóképpen, egyes közreműködők a saját

területükön profik függetlenül attól, hogy egy vállalat fizet-e nekik a projektben való munkáért --, míg mások amatőrök, akiket gyakran enthusiasts-nak (lelkes közreműködő) neveznek. De nem kell profinak lenni ahhoz, hogy fontos szerepet vállaljunk. Akár core csapattgá vagy projektvezetővé is válhatunk A szervezetek szerepe a nyílt forráskódú projektekben Bár sok nyílt forráskódú projektet lelkes egyének vagy önkéntesek kis csoportjai hoznak létre, általában amikor a projektek nagyobb méretűvé válnak, szervezeti támogatást keresnek. A szervezeti támogatás sokféle formát ölthet. Általában a szervezetek azért járulnak hozzá, mert egy nyílt forráskódú projekt olcsóbban és megbízhatóbban tudja kielégíteni üzleti igényeiket, mintha ugyanazokat a funkciókat saját kódban valósítanák meg újra. Az ingyenes vagy nyílt forráskódú 240 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12

Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment licenc által nyújtott garanciákat sok szervezet nagyra értékeli. Egyes idealisták nem bíznak a vállalatokban vagy más nagy szervezetekben, és a nyílt forráskódú projekteket inkább teljesen mentesítenék a befolyásuktól. Az évek során ez a meglehetősen leegyszerűsítő hozzáállás egyre kevésbé vált általánossá. A legtöbb nyílt forráskódot támogató úgy véli, hogy a vállalatok és más szervezetek döntő fontosságú alapokat nyújthatnak a nyílt forráskódú projektek számára. Sok nyílt forráskódú projekt egy szervezeten belül indul, és akár saját, zárt kódon is alapulhat, amit a vállalat nyílttá tesz. A pénzszerzés érdekében a vállalat dönthet úgy, hogy szilárdan ellenőrzi a projektet, és nyílt és védett részekre bontja azt: ezt nevezzük open core modellnek. Sok projektalapító nyílt forráskódúként indul, de egy céget alapít köré, amely

vagy alkalmazza, vagy nem alkalmazza az open core modellt. Más projektek arra törekednek, hogy ne egyetlen vállalat szabja meg az irányt. A függetlenség fenntartásához általában több szervezeti támogatót kell szerződtetni, hogy senki se legyen elég erős ahhoz, hogy diktatórikus döntést hozzon. Hogyan támogatják a szervezetek a nyílt forráskódot? Ahogy korábban említettük, sokan fizetett munkatársakat küldenek a projektekbe. Ezen túlmenően felvehetnek olyan rendkívül produktív egyéneket is, akik önkéntesként járultak hozzá a projekthez, és a projekthez kapcsolódó szakértelmet fejlesztettek ki. Ez a munkavállaláshoz vezető út értékes módja annak, hogy a diákok és más önkéntes közreműködők előrébb jussanak karrierjükben. Azoknak a vállalatoknak, amelyek olyan bővítéseket szeretnének, amik más felhasználókat nem érdekelnek, nem kellene nyomást gyakorolniuk a nyílt forráskódú projektre, hogy adják hozzá ezeket az

extra funkciókat, hanem fizetniük kellene az alkalmazottaiknak, hogy megírják a funkciókat anélkül, hogy részt vennének a projektben. A vállalati igények által keltett lehetséges feszültségre érdekes példa a híres Android operációs rendszer, amely Linuxon alapul, és amelyet a Google fejlesztett ki mobileszközei vezérlésére. A Google által a Linuxon végrehajtott egyes változtatásokat a Linux-közösség visszakapja, míg más változtatások csak az Androidban jelennek meg. A Linux fejlesztői néha elutasítják a Google által hozzájuk eljuttatott változtatásokat, ahogyan minden projekt eldönti, hogy miket épít be. Számos oka lehet annak, hogy egy vállalat vagy fejlesztők egy csoportja külön verziót készítsen a kódjából. Ideális esetben egy opcionális könyvtár vagy kódsorozat hozzáadásával elégíthetik ki igényeiket, amelyet a fordítás során ki lehet zárni. Néha azonban egy csoport olyan komoly igényt érez, amely nem

összeegyeztethető a projekt vezetői által választott irányvonallal. Amikor egy különálló verzió készül, azt fork-nak (elágazás) nevezzük. Régebben a forkokat az együttműködés hibáinak tekintették, de manapság már sokkal Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 241 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment elfogadottabbak. Általában azok, akik forkot készítenek, új repositoryt hoznak létre és új projektet indítanak. Vannak, akik az eredeti projekten és a forkon is dolgoznak (Megjegyzendő, hogy a GitHub a “fork” szót egy egészen más jelenségre használja: a projekt kódjának klónozására vagy másolására azért, hogy külön dolgozhassunk rajta.) A kód mellett számos vállalat anyagilag is hozzájárul a működéshez. Olyan erőfeszítéseket finanszírozhatnak, mint a marketing és a konferenciák. Csatlakozhatnak az igazgatótanácshoz, és szakértői

tanácsot adhatnak a projekt irányával és stratégiájával kapcsolatban. Az ilyen “puha támogatás” (soft support) fontosságára a történelmi Apache webszerver szolgáltat példát. A projekt nagyot ugrott előre a létezésének korai szakaszában, amikor az IBM érdeklődést mutatott iránta. Az IBM jogászai megmutatták a projektnek, hogyan hozzanak létre jogi biztosítékokat, és egy, az IBM által fizetett találkozó segített az Apache vezetőségének egy erős szervezet létrehozásában. A függetlenség megőrzése érdekében sok nyílt forráskódú projekt nonprofit alapítványt hoz létre, vagy csatlakozik egy meglévő alapítványhoz. A nyílt forráskódú projekteket irányító alapítványok híres példái közé tartozik a Linux Foundation, az Apache Foundation és az Eclipse Foundation. Az alapítványok támogatása azért értékes, mert olyan logisztikai feladatokat tudnak ellátni, amelyekkel a legtöbb szoftverfejlesztő nem akar

foglalkozni: jogi támogatás, például a védjegyek, kártérítések és licencek ügyében; segítség a pénzszerzésben; infrastruktúra, például hibaadatbázisok és weboldalak; és így tovább. A jogok átruházása A könyvekhez, zenéhez és más kreatív erőfeszítésekhez hasonlóan a szoftverek esetében is bonyolult kapcsolat van a fejlesztők, a hozzájárulásaikat terjesztő szervezetek és a nagyközönség között. Lényegében a közreműködőknek lépéseket kell tenniük annak érdekében, hogy egy nyílt forráskódú projekt formalizálja a kódjuk felhasználásának és terjesztésének jogát. Ezért sok nyílt forráskódú szervezet kéri a közreműködőket, hogy írjanak alá egy közreműködői licencszerződést (contributor license agreement CLA). Néha a közreműködő egyszerűen csak átadja a kódot a projektnek. A projekt tulajdonában van a kód és az ahhoz fűződő minden jog, ugyanúgy, ahogyan egy zártkörű vállalat

tulajdonában van az a kód, amelynek kifejlesztéséért a munkatársait fizette. Más CLA-k bizonyos jogokat az egyes közreműködők kezében hagynak, akiknek tetszhet ez a rugalmasság, mert ugyanezt a kódot egy másik projekthez is hozzáadhatják, vagy saját vállalkozást építhetnek rá. 242 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment A különböző emberek különböző hozzájárulásainak összehangolása érdekében a kódhoz rendelt licenc döntő fontosságú. A Linux kernel egyike azoknak a projekteknek, amelyek a tulajdonjogot a közreműködők kezében hagyják, így mára sok ezer ember rendelkezik a Linux kódhoz fűződő jogokkal. A core kódot azonban minden hozzájáruló a GNU General Public License (2 verzió) alá helyezi, így a Linux mindenki számára szabadon használható, módosítható és terjeszthető. Egyetlen licenc használata a

projektben található összes kódra a legegyszerűbb módja annak garantálására, hogy semmilyen teher nem akadályozza a kód terjesztését és használatát. Néha azonban egy projekt lehetővé teszi, hogy a kód különböző részei különböző licencek alatt legyenek elérhetőek, általában azért, mert a projekt ki akarja használni a már létező, más licenc alatt kiadott kód előnyeit. A licencszakértőknek meg kell győződniük arról, hogy a licencek kompatibilisek. Szabályok és irányelvek Sok online közösségben a korlátlan beszéd (a “bármi mehet” (anything goes) gondolat) hírneve verbális bántalmazáshoz és civakodáshoz vezet. Manapság a legtöbb nyílt forráskódú közösség küzd ezzel a tendenciával, amely túlságosan könnyen elragadja az embereket. Ezzel szemben a modern közösségek azt akarják, hogy az emberek konstruktívak, civilizáltak, tisztelettudóak és mindenkit befogadóak legyenek: minden nemet, etnikai csoportot,

személyiségtípust stb. beleértve. A csoporttagokkal szemben támasztott elvárásokat általában kifejezetten egy magatartási kódexben (code of conduct) határozzák meg, amely elmagyarázza, hogyan kell a projektben részt vevő többi emberrel online és személyesen együttműködni. Ahhoz, hogy ez a magatartási kódex hatékony legyen, a közösségi menedzsernek és a projektvezetőknek kell ennek érvényt szereznie. Előfordul, hogy azt a személyt, aki durván kigúnyolja vagy becsmérli a közösség valamelyik tagját, véglegesen vagy ideiglenesen kizárják a közösségből. Máskor a közösségi menedzser vagy egy kolléga egyszerűen nyilvánosan bejelenti, hogy a viselkedés sérti a magatartási kódexet, és esetleg a fórumon kívül beszélget a szabálysértővel. Gyakran előfordul, hogy az elkövető korábban frusztrációt, a figyelem hiányát vagy kiégést érzett, és a közösségi tagok segíthetnek neki, hogy jobb módon fejezze ki magát. A

társadalmi viselkedés mellett a közösségek minőségi normákat is megállapítanak. A legformálisabbak a kódolási irányelvek (coding guideline), amelyek azt próbálják biztosítani, hogy minden kód hasonlóan nézzen ki. Az irányelvek emlékeztethetik a fejlesztőket a helyes gyakorlatokra, például a kódblokkok körüli kapcsos zárójelek használatára, vagy részletesen meghatározhatják, hogy hogyan nevezzük el a változókat és milyen behúzásokat használjunk. A nyílt forráskódú közösségeknek is vannak szabályaik a kód vagy más termékek kiadására Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 243 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment vonatkozóan. Néhány projekt a releasekre vonatkozóan rögzített időpontokat határoz meg; az Ubuntu például kétévente ígér egy új, hosszú távú támogatást nyújtó (LTS) verziót, valamint gyakoribb időközi releaseket. Más

projektek listát vezetnek az új funkciókról és hibajavításokról, amelyeket a következő kiadásban szeretnének, és akkor hagyják jóvá a kiadást, ha mindent kipipáltak a listáról. A legtöbb vállalattól eltérően azonban a nyílt forráskódú közösségek általában nem határoznak meg határidőket a résztvevők számára, mivel nem lehet túl sokat kérni az önkéntesektől. Hozzájárulás és átláthatóság A korábban említett hozzájárulási licencszerződésen kívül néhány projekt arra kéri a közreműködőket, hogy írjanak alá egy fejlesztői eredetigazolást (developer certificate of origin DCO). A DCO-ban a közreműködő megígéri, hogy törvényes joga van a kód eladományozására. Miért fontos a DCO? Képzeljük el a következő forgatókönyvet: ha egy programozó kódot vesz át egy, a munkáltatója által gyártott zárt forráskódú termékből, és azt egy nyílt forráskódú projekthez adja hozzá, akkor a programozó

megsérti a munkáltató licencét, és jogi kockázatnak teszi ki a nyílt forráskódú projektet. A DCO-nak azt kell biztosítania, hogy valóban a közreműködő írta a kódot, vagy legálisan szerezte meg. A nyílt forráskódú projekt a tanúsítványt kitöltő közreműködő őszinteségétől függ Sokszínűség, egyenlőség, befogadás és diszkriminációmentesség A társadalomtudósok azt állítják, hogy a projektek és a vállalatok számára előnyös, ha sok különböző nemű, származású, gazdasági hátterű, nemzetiségű és képességű ember vesz részt bennük. Minden szervezetben természetes emberi tendencia, hogy olyan emberekhez kötődik, mint annak a tagjai, ezért egy olyan közösségnek, amely értékeli a sokszínűséget és a méltányosságot, tudatosan arra kell nevelnie a tagjait, hogy nyitottabbak legyenek olyan emberek iránt, akik nem olyanok, mint ők. Az ezt az eszményt megvalósító mozgalmat sokszínűségnek, egyenlőségnek

és befogadásnak (diversity, equity, inclusion DEI) nevezik. A magatartási kódex a DEI kiindulópontja. Ennek kifejezetten üdvözölnie kell a különböző nemű, származású stb. embereket A magatartási kódex minden megszegését azonnal, egyértelmű rosszallással kell kezelni. Ez azért van így, mert egyes kisebbségek egész életükben szenvedtek a kirekesztéstől és a negatív megjegyzésektől, és a fórumunkon egyetlen rossz interakció arra késztetheti őket, hogy úgy döntsenek, többé nincs okuk részt venni a projektben. Az agresszióra adott gyors válasz megnyugtathatja őket afelől, hogy a közösség támogatja őket. 244 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment A DEI azonban sokkal tovább megy. A közösségnek el kell érnie azokat a csoportokat, amelyeknek nagyobb képviseletre van szükségük. Ha például álláskereső alkalmazást

fejlesztünk, gondoskodnunk kell arról, hogy az alacsony jövedelműek, valamint a felső- és középosztálybeliek számára is mutasson állásokat. Az alkalmazást az alacsony jövedelmű közösségek körében is hirdetnünk kell, és ezekből a közösségekből kell tagokat toborozni a teszteléshez. A közösség számára hasznos lehet, ha találunk olyan szervezeteket, amelyek marginalizált csoportokból származó embereket képeznek, és amelyekből új tagokat toborozhatunk a csapatunkba. Sok ilyen szervezet helyi szinten jött létre, és országos vagy nemzetközi szinten nem ismert. A marginalizált közösségek igényeinek megértése kulcsfontosságú. Elérhető a honlapunk a látássérültek számára is? Lefordítjuk a dokumentációt olyan nyelvekre, amelyeket a célközösség ismer? Esetleg hozhatunk létre külön fórumokat más nyelveken. A nyílt forráskódú közösségekben a kommunikáció nagy része aszinkron és online zajlik. De ha

találkozókat vagy szinkron chat-sessionöket tartunk, gondoljunk arra, hogy az emberek hol helyezkednek el földrajzilag, és találjunk módot arra, hogy mindenkit bevonjunk. Ha például sok országból és régióból származó emberek kommunikálnak angolul, próbáljuk meg a szókincset és a nyelvtant leegyszerűsíteni. Végezetül, ha a csapatnak vannak kisebbségből származó tagjai, mindenképpen hallgassuk meg őket. A kirekesztés egyik jól ismert tünete, hogy a kisebbségek mondanivalóját nem veszik figyelembe, vagy egyszerűen csak alábecsülik annak fontosságát. Másrészt ne terheljük a kisebbségi tagokat azzal, hogy magyarázatot kell adniuk a közösségük igényeire ezt a kutatást mindenkinek el kellene végeznie. A kisebbségi tagok értékes felvilágosító munkát végezhetnek, de ne gyakoroljunk rájuk nyomást. Mindenkinek egyenlő lehetőséget kell biztosítani, hogy úgy vegyen részt a munkában, ahogyan szeretne, anélkül, hogy a

kisebbség jelképe legyen. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 245 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Gyakorló feladatok 1. Miért nem adja át minden közreműködő a kódját a projektnek, és miért nem mond le a kódhoz való minden jogáról? 2. Ha valaki segíteni akar a projektben, de nem tud programozni, milyen módon tud segíteni? 3. Miért csatlakozik sok nyílt forráskódú projekt egy alapítványhoz? 246 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment Gondolkodtató feladatok 1. Commiterek vagyunk a projekten Valaki olyan kódot küld be, amelyet egy másik projektből vett át (de a közreműködőnek megvannak ehhez a jogai). A kód teljesen másképp van formázva, mint a saját kódunk. Mit teszünk? 2. Létrehoztunk egy zárt szoftverterméket, és egy nyílt

forráskódú projekthez szeretnénk hozzájárulni annak egyes részeivel. Milyen körülmények között forgalmazhatjuk továbbra is a zárt termékünket? 3. Két ember a levelezőlistán vitatkozni kezd a kód egy tulajdonságán A vita fokozatosan egyre hevesebbé válik, míg végül az egyik személy idiótának nevezi a másikat. Hogyan tudjuk kezelni a helyzetet? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 247 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Összefoglalás Ebben a leckében megtanultuk, milyen egy közösség részének lenni, és hogyan maradnak ezek a közösségek produktívak. Megtanultuk a különböző típusú hozzájárulásokat, közreműködőket és szerepeket. Megtanultuk, hogy hogyan ellenőrzik a közösségek a közreműködések felhasználási jogát. Megtanultuk, hogy milyen szabályok vannak egy közösségben, és hogyan védenek meg mindenkit a szóbeli bántalmazástól,

beleértve a különböző származású és nemű embereket is. 248 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0553 Közösségi menedzsment Válaszok a gyakorló feladatokra 1. Miért nem adja át minden közreműködő a kódját a projektnek, és miért nem mond le a kódhoz való minden jogáról? Előfordulhat, hogy a közreműködő ugyanazt a kódot egy másik projekthez kívánja felhasználni, vagy a kódon alapuló terméket akar kiadni, és ezért bizonyos jogokat meg akar tartani. 2. Ha valaki segíteni akar a projektben, de nem tud programozni, milyen módon tud segíteni? A kódoláson kívül a közreműködők számos más szerepet is betölthetnek. Néhány ilyen szerepkör például a dokumentálás, a tesztelés és hibajelentés, a közösség menedzselése, formokban való részvétel, a projekt népszerűsítése és a művészeti munkák készítése. 3. Miért csatlakozik sok

nyílt forráskódú projekt egy alapítványhoz? Az alapítvány számos olyan jogi, pénzügyi és egyéb feladatot lát el, amelyet a projektközösség nehezen tudna elvégezni. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 249 Open Source Essentials (Version 1.0) | Témakör 055: Projektmenedzsment Válaszok a gondolkodtató feladatokra 1. Commiterek vagyunk a projekten Valaki olyan kódot küld be, amelyet egy másik projektből vett át (de a közreműködőnek megvannak ehhez a jogai). A kód teljesen másképp van formázva, mint a saját kódunk. Mit teszünk? A projekt kódolási szabványainak világosan le kell írniuk azt, hogy hogyan kell formázni a kódot. Köszönjük meg a közreműködőnek, mutassunk rá a szabványokra, és kérjük meg, hogy formázza meg a kódot. Néha léteznek olyan automatizált eszközök, amelyekkel a kódot a kívánt módon átformálhatja. Ha a közreműködőnek nincs ideje az újraformázásra,

keressünk egy fiatalabb tagot a csapatból, aki el tudja végezni ezt a munkát. 2. Létrehoztunk egy zárt szoftverterméket, és egy nyílt forráskódú projekthez szeretnénk hozzájárulni annak egyes részeivel. Milyen körülmények között forgalmazhatjuk továbbra is a zárt termékünket? A válasz a közreműködői licencszerződéstől függ. Ha a CLA megköveteli, hogy átadjuk a kódot a projektnek, ezzel minden jogot átengedve nekik, akkor lehet, hogy nem tudjuk tovább forgalmazni a saját fejlesztésű termékünket. Ha azonban engedik, hogy megtartsuk a kódhoz fűződő jogainkat, akkor bármilyen licenc alatt kiadhatjuk a kódot a saját termékünkben. 3. Két ember a levelezőlistán vitatkozni kezd a kód egy tulajdonságán A vita fokozatosan egyre hevesebbé válik, míg végül az egyik személy idiótának nevezi a másikat. Hogyan tudjuk kezelni a helyzetet? Bárki, aki észreveszi az eszkalációt és a sértő megjegyzést, a lehető leggyorsabban

kell, hogy reagáljon. A kár helyreállításáért végső soron a közösségi menedzser a felelős A közbelépő személynek a teljes listára ki kell írnia egy megjegyzést, amelyben közli, hogy a viselkedés sérti a projekt magatartási kódexét (amely remélhetőleg kizárja az ilyen viselkedést.) A közbelépő személy külön-külön is felkeresheti a két oldalon álló személyeket, hogy megbizonyosodjon arról, hogy elégedettek a vita megoldásával, és megértették, hogyan lehet a nézeteltéréseket konstruktívan megvitatni. 250 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 251 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció 056.1 Fejlesztőeszközök Hivatkozás az LPI célkitűzésre Open Source

Essentials version 1.0, Exam 050, Objective 0561 Súlyozás 2 Kulcsfontosságú ismeretek • A általános szoftverfejlesztési eszközök megértése • A általános üzembe helyezési környezetek megértése • A szoftvertesztelés általános típusainak megértése • A Continuous Integration és a Continuous Delivery (CI/CD) fogalmának megértése A használt fájlok, kifejezések és segédprogramok listája • Integrált fejlesztői környezetek (IDE-k) • Linterek • Fordítók • Debuggerek • Reverse engineering • Refaktorálás • Egységtesztelés • Integrációs tesztelés • Elfogadó tesztelés • Teljesítménytesztelés 252 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök • Smoke tesztelés • Regressziós tesztelés • Gyártási, staging és fejlesztési rendszerek • Helyi fejlesztési rendszerek • Távoli fejlesztési rendszerek • CI/CD

pipelineok Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 253 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 056 Kollaboráció és kommunikáció Fejezet: 056.1 Fejlesztői eszközök Lecke: 1/1 Bevezetés Több ezer szoftverfejlesztő eszköz (tool) létezik, nyílt és zárt forráskódú egyaránt. És miért is ne? A programozók szeretnek eszközöket fejleszteni maguknak és kollégáiknak; természetes, hogy sok időt fordítanak arra, hogy olyan toolt találjanak, amely jobban működik, kiküszöböl valamilyen bosszúságot a munkafolyamatból, vagy megkönnyíti a telepítést, beüzemelést (deployment). Ez a lecke a fejlesztési folyamatra összpontosít, és elmagyarázza, hogy a különböző típusú fejlesztési eszközök hogyan illeszkednek ebbe a folyamatba. Kevés konkrét eszközt fogunk megnevezni,

mert bármelyikkel megtörténhet, hogy mire ezt a leckét publikáljuk, elavultnak (deprecated) vagy korszerűtlennek (obsolate) lesznek megjelölve, és egy új kedvenc váltja fel őket. A fejlesztés céljai A programozási eszközök több céllal zsonglőrködnek, amelyek néha egymással ellentétesek. Íme néhány példa a fejlesztési célokra: • Robusztus, pontos programok készítése. • Gyorsan futó programok készítése. 254 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök • Jól skálázható programok készítése. • Olyan programok készítése, amelyek jól alkalmazkodnak a különböző típusú felhasználókhoz, különböző eszközökhöz (például laptopokhoz, mobiltelefonokhoz és táblagépekhez) és különböző környezetekhez. • A fejlesztési folyamat felgyorsítása. • Az újonnan kifejlesztett funkciók vagy hibajavítások

telepítésének felgyorsítása. • A fárasztó munka, valamint az olyan programozási hibák számának csökkentése, amelyek átcsúsznak a program tesztelési szakaszaiba. • Olyan régebbi (legacy) kódok és eszközök támogatása, amelyeket a szervezet nehezen tud lecserélni. • Együttműködés más, ismert eszközökkel. • A könnyű visszaállítás (roll-back) lehetővé tétele hibák vagy tervmódosítások esetén. Ezek és más célok vezetnek az ebben a leckében leírt folyamatokhoz és az ezekből származó fejlesztési eszközökhöz. Általános fejlesztési folyamatok Ez a szakasz két általános, történelmi jelentőségű modellt állít szembe egymással: a vízesés modellt (waterfall model, amelyet egy korábbi leckében mutattunk be) és a continuous integration/continuous delivery (folyamatos integráció/folyamatos szállítás CI/CD) modellt. Vízesés modell Bár a vízeséses modellt még mindig széles körben használják, főleg nagy

szervezetek, sok fejlesztőnek kiesett a kegyeiből. Ez a modell az 1950-es évektől az 1970-es évekig volt népszerű A modell elemei ma is széles körben megtalálhatók, például a követelmények formális meghatározása és a programok tesztelése közvetlenül a kiadásuk előtt (minőségbiztosítás (quality assurance)). Már akkor széles körben hiteltelenné vált, amikor a “vízesés” kifejezést alkalmazták erre a modellre. A problémák közé tartozott: • A követelmények megváltoztatása nehéz volt, miután a fejlesztés megkezdődött. • A követelményeket és a terveket gyakran félreértették, mivel az egyszerű szöveg kétértelmű lehet. Ez a probléma olyan termékekhez vezetett, amelyek nem feleltek meg az elvárásoknak, és hónapokig tartott a javításuk. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 255 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció • A

folyamat lassú volt. Egy új release csak évente egyszer, vagy még ritkábban valósulhatott meg. • A különböző modulok kölcsönhatása által okozott hibákat nehéz volt észrevenni a folyamat késői szakaszáig, ami további késésekhez vezetett. • A folyamat falakat emelt a szervezet különböző részei közé, ami rossz hatással volt a termék minőségére és a szervezeti csapatszellemre (espirit de corps). A Continuous Integration/Continuous Delivery (CI/CD) alapelvei A vízesés-modellt az 1970-es években egy sor mozgalom támadta meg, amelyek a ma leghíresebb (bár nem általánosan használt) modellhez vezettek: CI/CD. A CI/CD gyakorlatok átvételének állomásai közé tartozik a 2001-ben kiadott Agile Manifesto, a SCRUM és a DevOps. Az új modell a csapattagok közötti szoros kommunikáció, a végfelhasználó vagy ügyfél bevonása, a hibajavítások és új funkciók gyors bevezetése, valamint a minőség megőrzését célzó szigorú

folyamatos tesztelés elveire épül a gyorsan változó néha kaotikus környezetben. A CI/CD a lehető legtöbb lépést automatizálja a kódírástól a kész program végfelhasználóknak történő telepítéséig tartó szakaszokban. A CI/CD megköveteli az egyes lépések formális meghatározását és az emberi tevékenység (például a szoftver kézzel történő telepítése) helyettesítését egy program által lefuttatott eljárással. A CI/CD tehát része annak a mozgalomnak, amelyet a “minden, mint kód” (everything as code) és az “infrastruktúra, mint kód” (infrastructure as code) kifejezésként ismerünk. Továbbá, ha egy csapat egyszer már beépítette a folyamatokat a kódba, ezeket a folyamatokat ugyanúgy lehet javítani, frissíteni és rögzíteni, mint a kódot. Bármit, amit a csapat ír, legyen szó programokról, automatizált eljárásokról vagy dokumentációról, egy verziókezelő rendszerben kell tárolni, amelyet egy következő

leckében ismertetünk. Ha több eljárást automatizálunk, azok egymás után is lefuthatnak. Ezért a csapatok gyakran beszélnek CI/CD pipeline-ról, ami azt jelenti, hogy a pipeline egy sikeres lépése automatikusan elindít egy vagy több következő folyamatot. A pipelinet automatizált módon kell felügyelni, hogy a folyamat során felmerülő bármilyen hiba esetén leálljon és értesítse a csapattagokat a hibáról. Bár a következő szakaszokban külön-külön tárgyaljuk a CI-t és a CD-t, ezek általában összekapcsolódnak, és közöttük lévő határvonal elmosódik. Continuous Integration (CI) A continuous integration (folyamatos integráció) a kis változtatások gyors beépítését jelenti a kódba. A végfelhasználóknak szánt termék létrehozásához használt központi tárolóhelyet core repository (vagy core repo) néven ismerjük. Minden programozó létrehoz egy személyes 256 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version:

2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök munkaterületet (gyakran sandbox (homokozó) néven ismert) a számítógépén, és a core repositoryból húzza le a javítandó vagy frissítendő fájlokat. A programozó használhat egy személyes laptopot vagy asztali számítógépet (úgynevezett lokális fejlesztőrendszert (local development system)), letöltheti a core repository megfelelő részeit, majd a helyi tesztelés után feltöltheti a változtatásokat. Alternatív megoldásként a programozó kihasználhatja a “felhőalapú számítástechnikának” nevezett népszerű irányzatot, és dolgozhat egy, a szervezete által üzemeltetett, megosztott rendszeren, a távoli fejlesztőrendszeren (remote development system). A programozó általában egy debugger segítségével ellenőrzi a hibákat, amely egy külön program, ami ellenőrzött környezetben futtatja a programozó munkáját. Később megnézzük a hibakereső programokat

és a hibák felderítésére szolgáló egyéb eszközöket. Annak érdekében, hogy a hibákat a lehető legkorábban kiszűrje a fejlesztési folyamat során, a programozó teszteket is futtat a kódon, mielőtt feltöltené azt a core repositoryba. Ezeket unit teszteknek nevezik, mert mindegyik a kód egy-egy apró elemére összpontosít: például, hogy egy függvény megfelelően inkrementált-e egy számlálót? A CI utolsó fázisa a programozó változtatásainak ellenőrzése a core repositoryba. Ebben a szakaszban az eszközök integrációs teszteket futtatnak, hogy megbizonyosodjanak arról, hogy a programozó nem tört meg semmit a projekt egészében. Bármilyen messzire is jutott az automatizálás, a csapat valamelyik szakértő tagjának az integrációnál közbe kell avatkoznia, hogy megbizonyosodjon arról, hogy ezt a változtatást szeretné a csapat. Az automatizált tesztek megállapíthatják, hogy semmi sem romlott el, sőt, azt is, hogy a változás a

kívánt hatást hozza-e létre a programban. Ezek a tesztek azonban nem tudják ellenőrizni a csapat által fontosnak tartott összes alapelvet. Ezért, mielőtt a csapattagok megkezdenék a telepítést, ellenőrizniük kell a biztonságot, a kódolási szabványok betartását, a megfelelő dokumentációt és egyéb elveket. (Nem meglepő, hogy ezek közül néhány feladatra is léteznek eszközök; a lecke későbbi részében megnézzük őket.) A CI során rengeteg tesztelésre kerül sor, és ennek gyorsan és megbízhatóan kell történnie, hogy támogassa a modern fejlesztés ütemét. Ezért a kód integrálására és a tesztek futtatására szolgáló modern eszközök automatizáltak. A programozónak képesnek kell lennie arra, hogy egyetlen parancs vagy gombnyomás segítségével futtasson egy egész unit teszt-csomagot. Általában egy részleges vagy teljes integrációs teszt mindig lefut, amikor a programozó feltölti a kódot a core repositoryba. A tesztek

által észlelt hibákat gyorsan jelenteni lehet a programozónak Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 257 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Continuous Delivery (CD) Amint az előző szakaszban kifejtettük, a CI olyan automatizált eljárásokból áll, amelyek a program új verziójához vezetnek a core mappában. A continuous delivery (folyamatos szállítás) arra utal, ami ezt a szakaszt követően történik, hogy az új verzió kikerüljön a terepre (field), ahol a végfelhasználók használhatják. A CD-ben a D-t néha a “development” (fejlesztés) vagy a “telepítés” (deployment) mellett a “szállítás” (delivery) szóra is kiterjesztik. A CD fő feladata a kód alapos tesztelése és feltöltése a felhasználók számítógépére vagy egy alkalmazás repositoryba. A CD-fázisban egy sor tesztet végeznek el, hogy maximálisan biztosítsák a termék

megfelelő működését. Az integrációs tesztek nagyobb csoportját lehet lefuttatni, valamint számos más tesztet is, azért, hogy meghatározzák a felhasználókra, a teljesítményre és a biztonságra gyakorolt hatásokat. A lecke egy későbbi szakaszában ismertetünk néhány ilyen tesztet A tesztelést a felhasználókat kiszolgáló éles rendszerektől eltérő rendszereken kell végezni. Egy katasztrofális hiba nem csak a production rendszert teheti tönkre, hanem a felhasználói adatokat is. Ezen túlmenően a tesztek versenyeznek a rendszeridőért, és rontják a felhasználóknak jutó teljesítményt. A teszteléshez tehát a legjobb, ha egy olyan teljes számítógépes környezetet hozunk létre, amely tükrözi az éles környezetet, hasonló hardverrel és szoftverrel. A köztes környezetet, ahol a tesztelés a telepítés előtt fut, gyakran nevezik staging környezetnek. Természetesen nem lenne praktikus, ha a tesztkörnyezet ugyanolyan méretű lenne,

mint az éles, de annak alapvető elemeit (például az adatbázisokat) tartalmaznia kell. A CD-automatizálás egyik követelménye a teszt- és az éles környezet megkülönböztetése. Minden kódtelepítést és folyamatot a célkörnyezethez kell igazítani. A CD akkor kínálja a legtöbb lehetőséget a gyors fejlesztésre, ha a kód a szervezet saját rendszerein futó szolgáltatás. Ha például egy kiskereskedelmi egység létrehoz egy interaktív weboldalt, akkor hozzáférhet az összes webszerverhez. Ha akarjuk, naponta többször is frissíthetjük őket, és gyorsan visszavonhatjuk a változtatásokat, ha kiderül, hogy azok problémákat okoznak a felhasználók számára. Általános szoftverfejlesztési eszközök Ezek a szakaszok három szinten mutatják be a programozói csapatok által használt általános eszköztípusokat: kódgenerálás, tesztelés és telepítés. 258 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open

Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök Fordítók Az alapvető programozási eszköz a compiler (fordító), amely a nagyon kifinomult, magas szintű programozási nyelveket a számítógép processzorán futó utasításokká alakítja. A számítógépek gépi kódot futtatnak, amely bitek (egyesek és nullák) sorozataiból áll, amelyeket a processzor utasításokká és adatokká alakít: egy érték betöltése a memóriából egy regiszterbe, két regiszter értékének összeadása stb. A processzorokat a különböző formátumok és utasításkészletek különböztetik meg, így a gépi kódjuk is különböző. A gyártók megpróbálnak olyan új processzorokat kitalálni, amelyek ugyanazt a gépi kódot használják, hogy a vásárlók régi programjaikat az új processzorokon is futtathassák. Amikor a gyártók ezt teszik, akkor beszélhetünk processzorcsaládokról. A programozás korai éveinek következő állomása az assembly nyelv volt,

amely ember által olvasható kifejezésekkel, például ADD-dal (hozzáad) látta el az egyes utasításokat. A programozók assembly nyelven kódoltak, és kódjukat egy assembler nevű eszköznek adták át, amely az assembly nyelvet gépi kódra fordította. A gépi kódot gépi nyelvnek is nevezik Ezután jöttek létre a magasabb szintű nyelvek. Manapság összetett vezérlőfolyamatokat hozhatunk létre anélkül, hogy azok részleteit specifikálnánk; csak a kívánt eredményeket kell megadnunk. Ezekhez a programokhoz fordítóprogramra van szükség, amely a forráskódot gépi kóddá alakítja. A fordítók egészen intelligens átalakításokat és optimalizálásokat tudnak végezni Sok nyelv több fordítóprogrammal is rendelkezik. A nagyon népszerű nyelvekhez, mint például a C és a Java, többféle fordítóprogramot is találhatunk. A szabad és nyílt forráskódú közösségben a legtöbben a GNU Compiler Collection (GCC) vagy az LLVM fordítót használják

C és C++ nyelvekhez. Eredetileg a fordító minden egyes forráskódfájlt lefordított, hogy egy köztes objektumfájlt hozzon létre, majd az összes objektumfájlt egy programba egyesítette egy másik eszköz, a linker meghívásával. A modern fordítók egyszerre több fájlt is lefordíthatnak, hogy a fájlok határait átlépő optimalizálásokat hajtsanak végre. A fordítók korábban assembly nyelvre fordítottak, ami azért lehetett hasznos, mert annak ellenére, hogy minden egyes processzortípus más-más gépi kódot támogatott, támogathatta ugyanazt az assembly nyelvet. Az assembly nyelveknek több változata létezik A fordítás és a linkelés utolsó lépése a gépi kód előállítása volt. A linkeléshez hasonlóan a modern fordítóprogramok tudják, hogyan kell összerakni a kódot gépi kóddá. Sok modern nyelvben azonban van egy másik szakasz is: a köztes kód, amelyet általában bájtkódnak neveznek. Ezt a kódot olyan bináris formátumba

fordították, amely elég magas szintű ahhoz, hogy hordozható legyen. A Java nyelvet például bájtkóddá fordítják, hogy a program számos különböző típusú processzorra betölthető legyen. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 259 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció A forráskódból történő bájtkód előállítása során a fordító elvégezte a munka nagy részét. Ezután minden számítógépen megtalálható a program saját verziója, az úgynevezett virtuális gép (virtual machine), amely a bájtkódból a virtuális gép által végrehajtható utasításkészletté alakítja a programot. Néha a bájtkódot is gépi kóddá fordítják A végfelhasználók számára kényelmesebb a bájtkódból az utasításkészletbe való átmenet, mint a magas szintű programozási nyelvből a gépi kódba való átmenet. Amikor bevezették, ez volt a Java nagy

előnye, mert a tervezői azt akarták, hogy a Java egy virtuális gépi plug-inben fusson a webböngészőkben, ahol a felhasználó processzora és operációs környezete nagyon változatos lehet. A Java tervezői a bájtkód előnyeit a “Compile once, run anywhere.” (fordítsa egyszer, futtassa bárhol) marketingmondattal hirdették. A bájtkód néhány további előnye később jelent meg Új nyelveket lehetett létrehozni, amelyek egészen más élményt nyújtottak a programozóknak (remélhetőleg megkönnyítve a programozási munkát és karbantarthatóbb kódot produkálva), miközben ugyanazt a bájtkódot hozták létre, amelyet a Java virtuális gépek is támogattak. E nyelvek függvényei könnyen keverhetők voltak a meglévő Java programokkal. Végezetül pedig vannak olyan nyelvek, mint például a Python, amelyeknél egyáltalán nem kell forráskódot fordítanunk: egyszerűen csak beírjuk az utasításokat egy interpreter (értelmező) nevű feldolgozó

eszközbe, amely a kódot közvetlenül gépi kóddá alakítja és végrehajtja. Az értelmezők lassabbak, mint a fordítóprogramok, de egyesek elég hatékonyak ahhoz, hogy ne jelentsenek nagy teljesítménybeli hátrányt. Mégis, a Python nyelv néhány népszerű könyvtára olyan függvényeket tartalmaz, amelyek a fejlesztők számára az értelmezett nyelven elérhetőek, de azért, hogy felgyorsítsák a végrehajtást, C nyelven lettek leprogramozva. Sok értelmezett nyelv is biztosít fordítóprogramokat. Ezek vagy bájtkódot, vagy gépi kódot állítanak elő, amely aztán gyorsabban fut, mint az interpreter. A programozóknak a fájlok és funkciók kezelését segítő build eszközök állnak rendelkezésre. Egy összetett program több száz fájlt tartalmazhat, és a programozónak különböző időpontokban (például a hibakeresés támogatása érdekében) különböző fájlkombinációkat kell lefordítania különböző opciókkal. Egy build eszköz

lehetővé teszi a programozók számára, hogy különböző opciókat és fájlkombinációkat tároljanak, és könnyen kiválaszthassák a kívánt build típusát. A Java és a rokon nyelvei esetén a Maven és a Gradle gyakori build eszközök. Kódgeneráló eszközök A programozónak nem kell üres képernyővel kezdenie a kódolást. Nemrégiben olyan szolgáltatások jelentek meg, amelyek kódot generálnak a kívánt program egyszerű szöveges leírása alapján. Ez a generatív mesterséges intelligencia egy formája, és más ilyen szolgáltatásokhoz hasonlóan egyesek panaszkodnak, hogy korábbi programozók munkáját használja fel, és (eddig) kevésbé robusztus forráskódot állít elő. Az etikai vitáktól eltekintve sok 260 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök programozó szerint az automatikus kódgenerálás jelentősen javította a

termelékenységüket. A kódgenerálás egyik formája, amely sok programozási nyelvben már évek óta elérhető, a refactoring. Ez egy nagy programot vizsgál meg, amely idővel könnyen fájlok és függvények kusza összevisszaságává alakulhat. A refaktorálás a függvényeket áthelyezi, hogy a program logikusabb struktúrát kapjon a jobb karbantarthatóság és a forráskód duplikációjának csökkentése érdekében. Egyes programozók feladata más kódok működésének reprodukálása. Előfordulhat, hogy új programot kell írniuk egy olyan régebbi program helyett, amelynek hiányzó forráskódja visszavonásra szorul; vagy egy versenytárs programját kell utánozniuk. Az ilyen jellegű kutatást reverse engineering-nek nevezik. Az egyik hasznos eszköz erre a célra a disassembler, amely a gépi kódot assembly nyelvvé alakítja. Bájtkódhoz is léteznek disassemblerek Debuggerek A legtöbb programozó több időt tölt hibakereséssel (debugging), mint

kódolással. Az emberek egyszerűen nem gondolkodnak tökéletesen logikusan, ezért elfelejtenek néhány olyan részletet, amelyet a számítógép megkövetel ahhoz, hogy a program úgy fusson, ahogyan szeretnénk. Valószínűleg a kódunk már az első próbálkozásnál elbukik, egy debugger pedig nagy segítség lehet a hiba feltárásához. A hibakereső segíti az intenzív kutatómunkát, így órákkal csökkenthetjük a hibák megtalálásának folyamatát. A programozó megkérheti a programot, hogy a program egy kulcsfontosságú helyen (breakpoint (megszakítási pont)) álljon meg, például egy függvény vagy ciklus elején. A hibakereső képes megjeleníteni a változók és akár a számítógép regisztereinek értékeit a program aktuális pontján. A programozó az egyes utasításokat egyenként is lefuttathatja, és láthatja az eredményeket (single stepping). Ha a programozó látni akarja, hogy egy változó mikor és hogyan változik a futás során,

akkor beállíthat egy watchpoint-ot. A szabad és nyílt forráskódú világban a legjelentősebb debugger (különösen a C és C++ nyelvek esetében), a GNU debugger, amely a korábban említett GNU fordítóval működik. Más nyelveknek is van dedikált debuggerük. Analitikai eszközök Bár a hibakeresés általában viszonylag gyorsan feltárja a hibákat, jobb, ha az elírásokat és más alapvető problémákat már a programozási folyamat elején ki tudjuk küszöbölni. A program ellenőrzéséhez számos ötletes elemző eszköz létezik. A statikus elemzés (static analysis) a program kódját vizsgálja. A dinamikus elemzés (dynamic analysis) lefuttat egy programot és a végrehajtás Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 261 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció során ellenőrzi a problémákat. A statikus elemzés egyik legkorábbi formáját linternek nevezték. Ez

képes felismerni például, ha egy lebegőpontos változó értékét egy egész szám (integer) típushoz rendeljük. Ez vagy problémát okoz, vagy nem, valamint a fordítóprogram is vagy észreveszi, vagy nem. Éles környezetben azonban hibás eredményekhez vezethet. Manapság a legtöbb fordítóprogram képes elvégezni a linterek munkáját. Néhány fordító, mint például a Rust nyelvhez készült fordító, szigorúan elutasítja a rosszul megírt kódot. Sok más típusú analitikai eszköz a fordítóprogramtól külön fut. A biztonsági elemző eszközök például megtalálhatják azokat a problémákat, amelyek a programot sebezhetővé teszik a hackerek számára. Gyakori fejleszőti hiba például az, amikor a kód meghív egy függvényt, és nem ellenőrzi, hogy az adott-e vissza hibát. Integrált fejlesztőkörnyezetek (IDE-k) Sok programozó szövegszerkesztőt használ a kód bevitelére és szerkesztésére. A szövegszerkesztők különböznek a

szövegfeldolgozó programoktól, amelyek sok formázási lehetőséget (például dőlt és félkövér betűket, gömböket, számozott listákat stb.) alkalmaznak A szövegszerkesztő formázatlan szöveget állít elő, amit a programozási nyelvek meg is követelnek. Vannak olyan kifinomult eszközök is, amik segítik a programozókat a programok fejlesztésében. Ezek az eszközök a használt programozási nyelvre figyelnek. Ha például egy változó vagy függvény nevét kezdjük el begépelni, az eszköz felajánlja a lehetséges befejezést. Ezek az eszközök kódolás közben ellenőrizhetik a hibákat, konzisztens és tetszetős módon formázhatják a kódot, analitikai eszközöket és hibakereső programokat futtathatnak, lefordíthatják a kódot, kezelhetik a verziókezelő rendszerekbe történő bejelentkezéseket, és egyéb feladatokat is el tudnak végezni helyettünk. Ezért nevezik őket integrált fejlesztőkörnyezeteknek (integrated development

environments IDE). Az Eclipse egy népszerű nyílt forráskódú IDE. A szoftvertesztelés általános típusai A tesztelés a szoftverfejlesztés fontos része. A programozók a kód fejlesztése során unit teszteket futtatnak. Más típusú tesztek általában vagy akkor futnak, amikor a programozó a kódot felrakja (visszacheckolja) a core repositoryba, vagy pedig a deployment során. 262 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök Unit tesztelés Láttuk, hogy a programozónak nagy figyelmet kell fordítania a hibák megtalálására, mielőtt a kódot elküldi a core repositoryba való integrálásra. A hibák felderítéséhez elengedhetetlenek a unit tesztek (egységtesztek). A tesztek írása egyszerre művészet és tudomány, és a tesztkód mennyisége meghaladhatja a programkód mennyiségét. Létezik még egy tesztvezérelt fejlesztés (test-driven development

TDD) nevű fejlesztési modell is, amelyben a programozók a teszteket a tesztelni kívánt kód megírása előtt írják meg. A TDD hívei azt állítják, hogy ez kitölti a tesztelés hiányosságait, és segít biztosítani, hogy a kód azt csinálja, amit a programozó akar. Fontos, hogy teszteljük a program végrehajtása során elromló dolgokat, de a jól működő dolgokat is. Ha a felhasználó vagy a program egy másik része érvénytelen bemenetet küld egy függvénynek, fontos, hogy a függvény észlelje a problémát, és megfelelő hibaüzenetet küldjön. A JUnit egy népszerű nyílt forráskódú eszköz a Java programok unit tesztjeinek futtatására. Integrációs, regressziós és smoke tesztelés Míg a unit tesztek az egyes funkciók egyes műveleteire összpontosítanak, a csapatnak magasabb szintű teszteket is kell futtatnia, hogy megbizonyosodjon arról, hogy a termék egésze megfelelően működik. A tesztek általában a felhasználói viselkedést

imitálják Például egy étteremkezelő alkalmazásban a tesztek ellenőrizhetik, hogy a felhasználó megkapja-e a kért terméket. Amikor egy program módosítása megszakít egy korábban működő funkciót, a hibát regressziónak (regression), a teszteket pedig regressziós teszteknek (regression test) nevezzük. Amikor egy csapat a terméket releasre készíti elő, a tesztelés első szakasza gyakran nagyon rövid. A csapat a program által végzett legfontosabb tevékenységeket ellenőrzi, és hiba esetén leállítja a tesztelést, így időt takarít meg. Ezt a fajta tesztelést smoke tesztnek nevezik, mert egy ilyen könnyen meghibásodó alkalmazás olyan, mint egy rossz készülék, ami felgyullad. Egyes termékek felhasználói interakciót igényelnek; a webes és mobil alkalmazások gyakori példák erre. Ezért hoztak létre olyan eszközöket, amelyekkel a felhasználói interakciókat lehet utánozni. A teszt automatikusan lefut, és elindítja azt a kódot,

amely akkor futna le, ha a felhasználó megnyomná a gombot. A Selenium például népszerű eszköz ebben a kategóriában Elfogadási tesztelés A felhasználói felülettel rendelkező programoknak a tesztelés egy extra szintjére van szükségük, amely túlmutat annak bizonyításán, hogy megfelelően reagálnak bizonyos bemenetekre. A Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 263 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció programoknak a képernyőn is jól kell kinézniük. Az acceptance testing (elfogadási teszt) a program felhasználóra gyakorolt hatását ellenőrzi. A minőségbiztosítási csapatok általában azután futtatják ezeket a teszteket, hogy az integrációs és regressziós tesztek bizonyítják, hogy a program formailag helyes és megfelel a felhasználói elvárásoknak. Biztonsági tesztelés Nyilvánvalóan kritikus fontosságú szempont a biztonság, és még

egy apró biztonsági hiba is komoly károkat okozhat egy szervezetnek. Láttuk, hogy a programozók analitikai eszközöket futtathatnak a kód biztonságának ellenőrzésére. A minőségbiztosítási szakaszban a tesztek azt is megállapíthatják, hogy a programban vannak-e sebezhetőségek. A tesztek rosszindulatú bemenetekkel futtatják a programot, és meggyőződnek arról, hogy a program visszautasítja a bemenetet anélkül, hogy hibázna, nem kívánt műveleteket hajtana végre, vagy érzékeny információkat fedne fel. Az egyik fajta teszt, amely bizonyos helyzetekben értékesnek bizonyult, a fuzz testing. A tesztelési keretrendszer egyszerűen véletlenszerű szemétből álló karakterláncokat generál, és azokat bemenetként elküldi a programnak. Ez időpocsékolásnak tűnhet, de gyakran olyan sebezhetőségeket tár fel, amelyeket a szokásos tesztelés nem. Teljesítménytesztelés Miután úgy ítélték meg más tesztek alapján, hogy a program helyesen

működik, a csapatoknak meg kell határozniuk, hogy elég gyorsan fut-e. A performance testing-hez (teljesítménytesztelés) olyan környezetre van szükség, amely hasonló ahhoz, ahol a felhasználók interakcióba lépnek a programmal. Ha például a felhasználók nagy távolságból, hálózaton keresztül küldik majd a kéréseket, a teljesítménytesztelést is nagy távolságú hálózaton kell elvégezni. Egyes programkönyvtárak tesztelése benchmarkok segítségével történik: különböző könyvtárak vagy ugyanazon könyvtár különböző verzióinak összehasonlítására használt szabványos tesztek. Általános telepítési környezetek Egy CI/CD eszköz kifinomult módon teszi lehetővé a pipelineok felépítését. A számítógépes programokhoz hasonlóan egy pipeline is tartalmazhat teszteket és ágakat (branch). A leágazásokkal a tevékenységek egy részét a tesztkörnyezetben, egy másik részét pedig az éles környezetben végezhetjük el. Az

eszköz segítségével automatikusan telepíthetjük a különböző programokhoz szükséges megfelelő adatbázist vagy más szoftvert. A CD átfedésben van a DevOps-szal. A felhőben a CD és a DevOps eszközök automatizált módon hozzák létre a virtuális számítógépes rendszereket a programok futtatásához szükséges összes 264 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök komponenssel. Az automatizált eszközök (néha orchestration eszközöknek is nevezik őket) ellenőrzik a virtuális rendszerek meghibásodását, és automatikusan újraindítják azokat. A CD eszköz fő feladata az egyes pipelineok elindítása és végigjárása. Az eszköz ellenőrzi a pipeline minden egyes szakaszának eredményeit, és dönt a folytatásról vagy a leállításról. Az eszköz lehetővé teszi az ütemezést is, és naplózza a tevékenységeit. Gyakran előfordul, hogy

egy feladatot kisebb változtatásokkal többször is le kell futtatnunk. A csapatok például különbséget tesznek a tesztkörnyezetbe való telepítés és az éles környezetbe való telepítés között. Ezért a CD-eszközök olyan paramétereket biztosítanak, amelyeket a pipeline futtatásakor különböző értékekkel tölthetünk ki. Néha egy folyamat olyan parancsokat igényel, amelyeket hagyományosan a terminálon adtak meg. Ezért a CD-eszközök tetszőleges parancsok futtatásához biztosítanak mechanizmusokat Általában olyan pontokat, mint a preprocess a pipeline egy adott szakasza előtti parancsok futtatásához, és a postprocess, a pipeline egy adott szakasza utáni parancsok futtatásához. Az ebben a fejezetben ismertetett automatizáláshoz a Jenkins az egyik ilyen legismertebb nyílt forráskódú eszköz. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 265 Open Source Essentials (Version 1.0) | Témakör 056:

Együttműködés és kommunikáció Gyakorló feladatok 1. Milyen módokon lehet ellenőrizni egy program biztonságosságát? 2. Miért írhatnánk több unit tesztet egyetlen függvényhez a programban? 266 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök Gondolkodtató feladatok 1. Csapatunk egy régi alkalmazást örökölt, amely lassan fut és nehezen bővíthető Milyen módon lehetne javítani az alkalmazáson anélkül, hogy kidobnánk és újat írnánk a semmiből? 2. Nagy projekteknél gyakran előfordul, hogy az A csapat egy funkciót a B csapat által karbantartott rendszer egy részében szeretne megvalósítani, de a B csapat nem tekinti ezt a funkciót prioritásnak. Hogyan kódolhatja az A csapat a funkciót a B csapat projektjének részeként? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 267 Open Source Essentials (Version

1.0) | Témakör 056: Együttműködés és kommunikáció Összefoglalás Ez a lecke a fejlesztés során használt eszköztípusokat ismertette: fordítók és más kódgeneráló eszközök, elemzők, tesztek, valamint az integrációt és a szállítást automatizáló CI/CD-eszközök. Mindegyik tevékenység végrehajtására számos lehetőség van, és egy ma még népszerű eszköz egy éven belül lecserélődhet. Annak megértése, hogy ezek az eszközök hogyan illeszkednek egymáshoz a fejlesztési folyamatban, segít azonosítani, hogy mire van szükségünk. 268 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0561 Fejlesztőeszközök Válaszok a gyakorló feladatokra 1. Milyen módokon lehet ellenőrizni egy program biztonságosságát? Először is, szakértők megvizsgálhatják a kódot. Számos statikus és dinamikus elemző eszköz létezik a programozást veszélyeztető rossz

programozási gyakorlatok kiszűrésére. Más eszközök rosszindulatú bemenetet küldenek a futó programoknak, és ellenőrzik a reakciókat. 2. Miért írhatnánk több unit tesztet egyetlen függvényhez a programban? Egy függvénynek általában sokféle bemeneti adatot kell kezelnie, és mindegyik típus megérdemli a saját tesztjét. A függvény például speciális módon kezelheti a nulla bemeneti értéket. Az érvénytelen bemenetet is előre kell látnunk, és teszteket kell írnunk, amelyek megmutatják, hogy a függvény megfelelően kezeli-e azokat. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 269 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Válaszok a gondolkodtató feladatokra 1. Csapatunk egy régi alkalmazást örökölt, amely lassan fut és nehezen bővíthető Milyen módon lehetne javítani az alkalmazáson anélkül, hogy kidobnánk és újat írnánk a semmiből?

Először is győződjünk meg róla, hogy a projekt verziókezelt, ha korábban nem lett verziókezelő alá helyezve! Egy új funkció hozzáadása után futtassunk regressziós teszteket, hogy megállapítsuk, hol hibázik a program, és bízzuk meg a programozókat, hogy kiderítsék, mely funkciók a felelősek! Ezeket a függvényeket szelektíven ki tudjuk cserélni. A teljesítményteszteléssel azonosíthatók a lassan futó egyes funkciók, így az erőfeszítéseket a legkevésbé hatékony kód javítására vagy cseréjére összpontosíthatjuk. Ha a kód olyan nyelven készült, amely már nem népszerű, fontoljuk meg, hogy a funkciók a csapat által kedvelt nyelven adjuk hozzá. Győződjünk meg arról, hogy az új nyelven megírt funkciók integrálhatók a régi funkciókhoz. 2. Nagy projekteknél gyakran előfordul, hogy az A csapat egy funkciót a B csapat által karbantartott rendszer egy részében szeretne megvalósítani, de a B csapat nem tekinti ezt a

funkciót prioritásnak. Hogyan kódolhatja az A csapat a funkciót a B csapat projektjének részeként? A B csapat engedélyezheti az A csapatnak, hogy új branchet hozzon létre, kódolja a funkciót, és fogadtassa el ezt a branchet a B csapattal, hogy az egyesítse (mergelje) a saját projektjébe. Az A csapat azonban nem kaphat felhatalmazást arra, hogy bármit megtehessen. A B csapatnak dokumentációt és segítséget kell nyújtania az A csapatnak a projekt szabványainak betartásához. A B csapat egyik tagjának át kell néznie az A csapat munkáját, és az integrációs tesztelés minden szokásos formáját el kell végeznie. Az együttműködésnek ezt a formáját néha InnerSource-nak nevezik, mert hasonlít a nyílt forráskódhoz, de egyetlen szervezeten belül zajlik. 270 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment 056.2 Forráskódmenedzsment Hivatkozás

az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0562 Súlyozás 3 Kulcsfontosságú ismeretek • A forráskód repositoryk (nyilvános és privát) megértése • A forráskódkezelés és a repositoryk szervezésének alapelveinek megértése • Az elterjedt SCM rendszerek (Git, Subversion, CVS) ismerete • A Version Control System (VCS), Revision Control System és Source Code Management rendszerek (SCM) fogalmának ismerete A használt fájlok, kifejezések és segédprogramok listája • Forráskód repositoryk • Commitok, branchek és tagek • Feature, fejlesztési és kiadási branchek • Subrepositories • Kód-merge Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 271 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 056 Kollaboráció és kommunikáció Fejezet: 056.2

Forráskódmenedzsment Lecke: 1 of 1 Bevezetés Bárki, aki valaha is szerkesztett már szöveges dokumentumot egy csapat tagjaként, ismeri az együttműködéssel kapcsolatos problémákat: melyik verzió az aktuális? Hol van ez a verzió elmentve? Éppen most szerkeszti valaki? Ki milyen megjegyzéseket vagy változtatásokat tett a szöveghez mikor és miért? Eredményként gyakran a dokumentumuk különböző változatait kapjuk, legrosszabb esetben pedig a változatok olyan gyűjteménye jön létre, amelyet senki sem ismer. Most képzeljünk el egy több száz fájlból álló szoftverprojektet, amelyen fejlesztők a világ minden tájáról dolgoznak, új funkciókat fejlesztve, hibákat javítva, részeket leválasztva és azokon külön dolgozva, és így tovább. Egy ilyen fejlesztési folyamat megfelelő eszközök nélkül már nem kezelhető. A forráskódmenedzser (soruce code management SCM), más néven verziókezelő rendszerek (version control system VCS)

vagy revíziókezelő rendszerek (revision control systems RCS) speciális szoftverek, amelyek erre nyújtanak megoldást. Ez kiküszöböli a fentebb vázolt problémákat. 272 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment A szoftverfejlesztés világában az SCM alapvető pillérként védi a kódbázis integritását. Képzeljük el úgy, mint egy szorgalmas őrt, aki aprólékosan nyomon követi a forráskód minden egyes változtatását és módosítását az idők során. Forráskódmenedzsment-rendszer és a repository A forráskódmenedzsment-rendszer a szoftverprojekt szíve. Bár fontos munka folyik a fórumokon és egyéb helyeken is, az SCM rendszer képviseli a projekt történetét és jelenlegi állapotát, mint élő entitást. A forráskód repository egyfajta digitális műhelye a projektnek. Ahogyan egy fizikai műhely egy munkadarab gyártásához

szükséges összes szerszámot és tárgyat tárolja, a repository egy szoftverprojekthez kapcsolódó összes fájlt, dokumentumot és kódot. Strukturált környezetet biztosít a projekt eszközeinek szervezéséhez és kezeléséhez. Az információkat általában könyvtárfa formájában tárolják. Az SCM-rendszerek jellemzően kliens-szerver modellt használnak, ahol bármely felhasználó lehúzhat (pull) adatokat a tárolóból, és fel is tölthet (push) oda. A rendszer nyomon követi, hogy ki és mikor hajtott végre egy-egy változtatást, így biztosítva az átláthatóságot és az elszámoltathatóságot a csapaton belül. Képzeljük el, hogy egy projekten dolgozunk több fejlesztővel együtt, és hibát fedezünk fel a kódban. Egy SCM segítségével könnyedén megvizsgálhatjuk a változatok közötti változásokat, hogy pontosan meghatározhassuk a hibáért felelős kódváltozást. Mivel a rendszer megjegyzi a fájlok minden egyes verzióját, ahogy azok

változnak, a felhasználó hozzáférhet bármelyikhez, és visszaállíthatja a korábbiakat (például abban az esetben, ha a módosítások hibásak lennének). A repository tehát egyfajta archívum is, amely hozzáférést biztosít a projektben valaha végrehajtott minden változtatáshoz, valamint a projekt állapotához annak történetének bármely pillanatában. Az SCM-rendszerek úgy takarítanak meg tárhelyet, hogy a fájl módosításait követik nyomon, ahelyett, hogy minden egyes módosításkor eltárolnák a teljes fájlt. Ez a hatékony módszer biztosítja azt, hogy a korábbi verziók túlzott erőforrás-igény nélkül is elérhetők legyenek. Számos eszköz, például a continuous integration/continuous delivery (CI/CD), és a tesztelés is az SCM-rendszer körül forog. Az emberek ezen a rendszeren keresztül építik a reputációjukat is, mivel hozzájárulásaik mindenki számára láthatóvá válnak. A forráskódmenedzsment tehát nem csupán a

változások nyomon követéséről szól; a kódbázis integritásának megőrzéséről és a fejlesztők közötti együttműködés elősegítéséről, biztosítva, hogy a projektek a dinamikus és folyamatosan változó környezetben is fejlődni tudjanak. Népszerű SCM rendszer például a Git, a Subversion és a CVS. Sok más szoftverfunkcióhoz Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 273 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció hasonlóan az SCM-et is gyakran speciális gyártók biztosítják. Más szóval, ez egy Software as a Service (SaaS) vagy “felhő” szolgáltatás: A felhasználók a helyi rendszereiken rendelkeznek a szoftverrel a saját módosításaik kezeléséhez, de a változtatásokat egy központi repositoryba töltik fel, amely biztosítja a felhőre jellemző funkciókat, például a 24/7 üzemidőt, a biztonsági mentéseket és a biztonságos hozzáférést.

Fejlesztők milliói használják a felhőszolgáltatásokat, különösen a GitHubot. A GitLab egy nyílt forráskódon alapuló alternatíva. Mind a GitHub, mind a GitLab lehetővé teszi, hogy az emberek a gyártó felhőalapú repositoryjaiban dolgozzanak, vagy telepítsék az SCM-rendszer helyi verzióját. Az ilyen környezetben végzett munka egyik előnye a hírnév, amelyet a “star” rendszereken keresztül szerezhetünk, amik lehetővé teszik a felhasználók számára, hogy egymás munkáját értékeljék. A felhőszolgáltatások olyan extra érdekességekkel bővültek, mint a változtatási kérelmek nyomon követése, az értékelési rendszerek, a wikik és a fórumok. A repositoryk tartalmazhatnak személyes és céges projekteket egyaránt, vagyis nem feltétlenül kizárólag vállalati használatra szolgálnak. Bármely programozó, aki bele akar kezdeni egy fejlesztésbe, vagy egy nyílt forráskódú projekten akar dolgozni, másolva és módosítva azt az

igényeinek megfelelően, megteheti. Ezekben az esetekben fontos szigorúan ellenőrizni, hogy ki férhet hozzá a repositoryhoz. A verziókezelést és a forráskód-kezelést körülvevő terminológia megértése alapvető fontosságú a használatában való eligazodáshoz. A következő szakaszokban közelebbről megvizsgálunk néhány ilyen fogalmat és kifejezést. Commitok, tagek és branchek A fejlesztő minden egyes alkalommal létrehoz egy commit-ot, amikor egy módosítást feltölt a repositoryba. A commitok a kódbázisban egy adott időpontban végrehajtott változtatások pillanatfelvételeit jelentik. Minden commit olyan metaadatokat tartalmaz, mint a szerző neve, egy időbélyeg és egy tájékoztató üzenet, amely a változásokat magyarázza. A commitok segítségével a fejlesztők nyomon követhetik a kódbázis fejlődését és megérthetik az egyes változtatások történetét. Képzeljünk el egy webes alkalmazáson dolgozó fejlesztőcsapatot! Minden

alkalommal, amikor módosításokat hajtanak végre a kódbázisban, létrehoznak egy commitot, hogy dokumentálják a változtatásokat. Például, ha valaki új funkciót ad hozzá az alkalmazáshoz, létrehozhat egy commitot a következő üzenettel: “Added user authentication feature.” (Felhasználói hitelesítés funkció hozzáadva.) Ez a commit rögzíti a kódbázis állapotát a funkció bevezetése után Amikor egy fejlesztő kijavít egy hibát, a commit üzenet általában a hiba azonosítószámára utal a projekt hibakövetési rendszerében. 274 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment A tag-ek (címkék) névre szóló hivatkozások bizonyos commitokra. Általában a projekt történetének jelentős pontjait jelölik, például releaseket vagy mérföldköveket. A tagekkel a kódbázis fontos verzióit lehet megjelölni és hivatkozni rájuk,

megkönnyítve ezzel a projekt történetének kezelését és a benne való navigációt. A branch-ek (ágak) akkor jönnek szóba, amikor a fejlesztőknek különböző feladatokon kell egyidejűleg dolgozniuk. A branchek független fejlesztési vonalak, amelyek eltérnek a fő kódbázistól. Lehetővé teszik a fejlesztők számára, hogy elszigetelten dolgozzanak a funkciókon vagy javításokon anélkül, hogy befolyásolnák a fő kódot, amíg készen nem állnak az integrációra. Segítenek megszervezni a fejlesztést és megkönnyítik a csapattagok közötti együttműködést. Ha például az egyik fejlesztő egy új funkció hozzáadásán dolgozik, míg egy másik egy hibát javít, mindketten külön bancheket hozhatnak létre a változtatások elkülönítése érdekében. Ha a munkájuk befejeződött, a brancheiket tudják egyesíteni (merge) a fő kódbázisba (Branches). Figure 16. Branches Amikor több ember dolgozik ugyanazon a fájlon, vagy egy másik branchre

checkolja be a változtatásokat, előfordulhat, hogy két ember változtatott ugyanazon a soron egy fájlban. Amikor a második változtatást végző személy megpróbálja becheckolni a változtatást, a rendszer conflict -ra figyelmeztet. Néhány VCS egyszerűen nem engedi meg a fejlesztőnek, hogy akkor checkoljon be egy fájlt, ha az conflictot tartalmaz a repositoryban lévő aktuális verzióval. A fejlesztőnek meg kell néznie az aktuális verziót, és ki kell találnia, hogyan oldja fel a conflictot, majd be kell checkolnia egy új verziót. A felhőalapú rendszerek merge vagy pull requesteket biztosítanak. Ezeket egy olyan fejlesztő hozza Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 275 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció létre, aki egy lokális rendszeren vagy branchen dolgozott, és úgy gondolja, hogy a változtatásai alkalmasak arra, hogy azokat beépítsék egy másik

branchbe. A cél-branch fejlesztői döntenek arról, hogy elfogadják-e a kérést. Subrepositoriek Gyakran előfordul, hogy egy másik, független projekt (pl. egy médialejátszó) kódjára van szükség egy szoftverprojekt (pl. egy komplex weboldal) fejlesztéséhez Ahelyett, hogy a médialejátszó kódját részben vagy egészben átmásolnánk a saját projektünkbe, sok VCS kínálja a subrepositoryk, más néven submodulok funkciót. Példánkban a médialejátszó repositoryja a weboldaléba van integrálva, mint egy subrepository. Ezután külön mappaként jelenik meg a könyvtárfában. Ez azt jelenti, hogy a médialejátszó kódbázisa teljes mértékben elérhető, de független marad. Szükség esetén akár a médialejátszó eredeti repositoryjából is frissíthető. Ez a képesség értékesnek bizonyul a számos függőséget tartalmazó bonyolult projektek kezelésében vagy harmadik féltől származó könyvtárak és keretrendszerek kódbázisba történő

integrálásában. Az almodulok javítják a projektszervezést és megkönnyítik az együttműködést, mivel lehetővé teszik a fejlesztők számára, hogy hatékonyan dolgozzanak egymással összekapcsolt kódbázisokon keresztül. A forráskódmenedzser-rendszer általános használata A projekt minden résztvevője egy identitás létrehozásával kezd, amely általában a résztvevő egyedi e-mail címéhez kapcsolódik. Egy felhőalapú rendszer fiókokon keresztül kezeli az identitásokat, ahogyan azt a közösségi médiaoldalak és más szervezetek is teszik. Az új fejlesztők egy SCM rendszer használatakor a következőkön mennek keresztül: 1. Az SCM szoftver telepítése, ha az még nincs az operációs rendszerben 2. A teljes projekt egyszeri átvitele a helyi rendszerre, más néven klónozás (cloning) 3. Ettől a lépéstől kezdve lokálisan dolgozik (egy vagy több branchen, ha szükséges), és pusholja a változtatásokat a repositoryba. 4. A következő

munkamenet előtt lehúzza (pull) legfrissebb verziót a repositoryból A projektvezetők döntik el, hogy kiben bíznak meg, és kinek adnak hozzáférést a repositoryhoz. A vezető fejlesztők fontos feladata eldönteni, hogy a többi közreműködő által benyújtott változtatások mikor kerülhetnek be a fő branchbe. 276 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment A felhőalapú rendszerekben a projekt tulajdonosa szabályozhatja a repository hozzáférhetőségét azáltal, hogy a láthatóságot nyilvános vagy privát állapotra állítja. A nyilvános repositoryk az interneten bárki számára olvasási hozzáférést biztosítanak. A privát repositoryk viszont kizárólag a tulajdonosra, valamint azokra a személyekre korlátozzák a hozzáférést, akikkel a tulajdonos kifejezetten megosztotta azt, szervezeti repositoryk esetében pedig a szervezet meghatározott

tagjaira. Képzeljünk el egy fejlesztőcsapatot, amely egy e-kereskedelmi weboldalon dolgozik. Úgy döntenek, hogy hozzáadnak egy új funkciót, amely lehetővé teszi a vásárlók számára, hogy nyomon kövessék a rendeléseiket. A funkció megvalósításához létrehoznak egy feature branchet, például order-tracking néven, ahol a szükséges kódmódosításokon dolgozhatnak anélkül, hogy a fő kódbázist befolyásolnák. Amint a funkció elkészült és tesztelve lett, ezt az branchet mergelik a fő development branchbe további integráció és tesztelés céljából. A fő development branch központi hubként szolgál, ahol az összes új funkciót összegyűjtik a teszteléshez. Ha például több fejlesztő egyidejűleg dolgozik különböző funkciókon, akkor a fejlesztési branchbe mergelhetik a funkció brancheket, hogy minden zökkenőmentesen működjön együtt. Ez az integrációs folyamat segít az esetleges conflictok vagy kompatibilitási problémák

korai felismerésében és megoldásában. Amikor eljön az ideje annak, hogy kiadják az e-kereskedelmi weboldal új verzióját, a csapat létrehoz egy release branchet a development branchről, például v2.0-t A zökkenőmentes release érdekében a kódbázis stabilizálására, az utolsó pillanatban felmerülő hibák kijavítására és alapos tesztelésre összpontosítanak. Amint a release elkészül, a release branch kódját élesítik, és a ciklus kezdődik elölről. Gyakori verziókezelő rendszerek A legismertebb verziókezelő rendszerek a Git, a Subversion (más néven SVN) és a CVS. Ezek mindegyike nyílt forráskódú. A Git egy elosztott verziókezelő rendszer, amelyet széles körben használnak a szoftverfejlesztésben és más területeken. A Git használatakor minden fejlesztőnek megtalálható a saját számítógépén a kódbázis egy teljes másolata. Ez a decentralizált megközelítés lehetővé teszi a fejlesztők számára, hogy offline

dolgozzanak és zökkenőmentesen együttműködjenek anélkül, hogy központi szerverre támaszkodnának. Vagyis a fejlesztők egymástól függetlenül dolgozhatnak különböző funkciókon vagy javításokon, és változtatásaikat zökkenőmentesen egyesíthetik. Még ha a központi szerver offline is megy, a fejlesztők folytathatják a munkát, és megoszthatják egymással a frissítéseket. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 277 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Vegyük például a Linux kernel fejlesztését, amely kezdetben a BitKeeper nevű központi verziókezelő rendszerre támaszkodott. Amikor a BitKeeper ingyenes státuszát visszavonták, Linus Torvalds és a Linux közösség kifejlesztette a Git-et, mint elosztott alternatívát. Ez a döntés lehetővé tette a nem-lineáris fejlesztést és az olyan nagy projektek hatékony kezelését, mint a Linux kernel.

A Git sikere a Linux kernel esetében egy rendkívül összetett projekt több ezer fejlesztővel és számtalan branchhel prezentálja a Git erejét és skálázhatóságát. A legtöbb szoftverfejlesztés manapság a Git-et használja. Rendkívül népszerű SaaS termékek épülnek rá. A Git úgy kezeli a conflictokat, hogy a fejlesztőnek egy fájlt ad a módosított sor mindkét verziójával, egyértelműen megjelölve, hogy a sorok a fájl melyik verziójából származnak. A fejlesztőnek el kell döntenie, hogyan oldja fel a conflictot, és be kell checkolnia a fájl koherens verzióját. A Subversion (SVN) valószínűleg a legnépszerűbb SCM rendszer volt a Git feltalálása előtt. A Gittől eltérően a Subversion centralizált: a verziótörténet egy központi szerveren található. A fejlesztők ezen a szerveren végzik el a változtatásokat, így biztosítva azt, hogy mindenki a kódbázis legfrissebb verziójával dolgozik. Tegyük fel, hogy egy olyan csapat

tagjai vagyunk, amely egy Subversiont használó projekten dolgozik. Minden alkalommal, amikor változtatásokat kell végrehajtanunk a kódbázisban, csatlakozunk a központi SVN-kiszolgálóhoz, hogy ellenőrizzük a kód egy működő példányát. Ez biztosítja, hogy a projekt legfrissebb verziójával dolgozunk. Miután elvégeztük a módosításokat, commitoljuk azokat a szerverre, frissítve a központi repositoryt a változtatásokkal. A központosított munkafolyamat segít fenntartani a következetességet, és biztosítja, hogy mindenki ugyanazokért a célokért dolgozik. A Subversion előtt a CVS egy nagyon népszerű, központosított verziókezelő rendszer volt. Tervezési problémái voltak, ezek vezettek a Subversion, mint alternatíva megtervezéséhez. 278 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment Gyakorló feladatok 1. Nevezzük meg az SCM-rendszerek

három fő jellemzőjét! 2. Ismertessük a tagging (címkézés) fogalmát az SCM-rendszerekben, és magyarázzuk el, miért fontos ez a szoftver releasek kezelésében! 3. Mi a különbség egy SCM rendszer esetén a branch és a subrepository között? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 279 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Gondolkodtató feladatok 1. Hasonlítsuk össze a Git és a Subversion (SVN) architektúráját és workflowját! 2. Mi az az “index” vagy “staging area” a Gitben? 3. Vázoljuk fel a Git trunk-alapú branchelési stratégiáját! 4. Az alábbi SCM rendszerek közül melyik nyílt forráskódú? Git Mercurial Subversion GitHub Bitbucket GitLab 280 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment Összefoglalás Ez a lecke a

forráskódmenedzser rendszerek központi szerepét ismertette a modern szoftverfejlesztésben. Megtanultuk az alapvető kifejezéseket és a rendszer használatának módjait, beleértve a repositoryt, a brancheket, a tageket és a mergeket. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 281 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Válaszok a gyakorló feladatokra 1. Nevezzük meg az SCM-rendszerek három fő jellemzőjét! ◦ A forráskód módosításainak naplózása ◦ A fejlesztők forráskódhoz való (egyidejű) hozzáférésének kezelése ◦ A fájlok vagy a teljes projekt bármely fejlesztési állapotának visszaállítása 2. Ismertessük a tagging (címkézés) fogalmát az SCM-rendszerekben, és magyarázzuk el, miért fontos ez a szoftver releasek kezelésében! A címkézés az a gyakorlat, amelynek során a kódbázisban található egyes commitokhoz leíró címkéket vagy

neveket rendelünk, amelyek a projekt történetének fontos pontjait, például releaseket vagy mérföldköveket jelölnek. Ezek a címkék kényelmes megoldást kínálnak a kódbázis egyes verzióira való hivatkozáshoz és a projekt időbeli fejlődésének nyomon követéséhez. 3. Mi a különbség egy SCM rendszer esetén a branch és a subrepository között? A branch egy párhuzamos fejlesztési vonal a projektben, például hibajavítás vagy új funkciók fejlesztése céljából, amelyet általában visszamergelnek a fő branchbe, amint a feladattal végeztek. A subrepository vagy sumbmodul egy független projekt, amelynek repositoryját egy projektbe integrálják, hogy hozzáférjenek annak kódbázisához. A subrepository mappaként jelenik meg a projekt könyvtárfájában, és független marad. 282 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0562 Forráskódmenedzsment Válaszok a

gondolkodtató feladatokra 1. Hasonlítsuk össze a Git és a Subversion (SVN) architektúráját és workflowját! A Git egy elosztott verziókezelő rendszer (distributed version control system DVCS), amely lehetővé teszi, hogy minden fejlesztő rendelkezzen a kódbázis teljes másolatával, és akár offline is dolgozhasson a forráskódon. A Git széles körű népszerűségre tett szert a fejlesztők körében a gyorsasága, rugalmassága és robusztus branching és merging képességei miatt. Az SVN egy központosított VCS, a verziótörténet egy központi szerveren található. Központosított jellege és kiforrott funkciókészlete miatt továbbra is népszerű bizonyos vállalati környezetekben. 2. Mi az az “index” vagy “staging area” a Gitben? Az index vagy a staging area egy köztes réteg a projekt helyi munkapéldánya és a szerveren lévő aktuális verzió között. Ez egy olyan fájl, amelyben a felhasználó következő commitjához szükséges összes

információ tárolódik. 3. Vázoljuk fel a Git trunk-alapú branchelési stratégiáját! A trunk-alapú fejlesztés olyan stratégia, amely a változások gyakori integrálását hangsúlyozza a fő kódbázisba (trunk). A fejlesztők rövid életű funkcióbrancheken dolgoznak, és ezeket naponta többször mergelik a trunkba, így biztosítva a folyamatos integrációt és a gyors visszajelzést. 4. Az alábbi SCM rendszerek közül melyik nyílt forráskódú? Git X Mercurial X Subversion X GitHub Bitbucket GitLab X Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 283 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció 056.3 Kommunikációs és együttműködési eszközök Hivatkozás az LPI célkitűzésre Open Source Essentials version 1.0, Exam 050, Objective 0563 Súlyozás 2 Kulcsfontosságú ismeretek • A általános kommunikációs eszközök megértése • A tudás rögzítésének és

biztosításának általános módjainak megértése • Az információkezelés és közzététel általános eszközeinek megértése • A dokumentáció általános típusainak megértése • A forráskód-kezelő platformok általános együttműködési jellemzőinek megértése • Az önálló, a föderált és a központosított menedzselt alkalmazások és platformok fogalmának megértése A használt fájlok, kifejezések és segédprogramok listája • Azonnali üzenetküldők • Chat platformok • Levelezőlisták • Hírlevelek • Problémakövetők és hibakövetők • Hibajelentések • Merge requestek és pull requestek • Helpdesk és jegyrendszerek 284 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök • Wikik • Dokumentumkezelő rendszerek (DMS) • Dokumentációs weboldalak • Termék-weboldalak • Tartalomkezelő

rendszerek (CMS) • Arcihtektúra dokumentáció • Felhasználói dokumentáció • Adminisztrátori dokumentáció • Fejlesztői dokumentáció Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 285 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Lecke 1 Tanúsítvány: Open Source Essentials Verzió: 1.0 Témakör: 056 Kollaboráció és kommunikáció Fejezet: 056.3 Kommunikációs és kollaborációs eszközök Lecke: 1/1 Bevezetés Számos nyílt forráskódú projektnek vannak aktív résztvevői a világ minden tájáról. Az együttműködés többnyire a “virtuális térben” történik, és az érintettek gyakran különböző országokban, kontinenseken és időzónákban vannak, ráadásul általában különböző anyanyelvűek. Ez azt jelenti, hogy attól, hogy a világ bármely pontján is tartózkodunk, hozzájárulhatunk egy nyílt forráskódú projekthez, függetlenül az

országunktól vagy az anyanyelvünktől! Bár ez a sokszínűség rendkívül kifizetődővé teszi a nyílt forráskódú projektekhez való hozzájárulást, mivel bővítheti a tevékenységi körünket és sokat tanulhatunk, azonban nagy kihívást jelent a kommunikáció és a koordináció. A hatékony és eredményes kommunikáció kulcsfontosságú minden nyílt forráskódú projekt sikeréhez és fenntarthatóságához. A jó kommunikáció biztosítása érdekében a nyílt forráskódú projektek olyan struktúrákat hoztak létre és számos olyan eszközt használnak, amelyek megkönnyítik a hozzájárulást és hatékonyabbá teszik az együttműködést. További kihívást jelent, hogy a nyílt forráskódú projektek, amelyeket gyakran főként önkéntesek 286 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök irányítanak, a részvétel

szempontjából fluktuációval néznek szembe. Az emberek élete és hobbija változik, és egyesek elveszíthetik érdeklődésüket, vagy egyszerűen kifutnak az időből. Lehet, hogy évekig hozzájárulunk egy nyílt forráskódú projekthez, de lehet, hogy már nincs elég időnk az önkéntes munkára, amikor munkahelyet váltunk, megnősülünk vagy gyereket nevelünk. Ezért a megfelelő eszközökkel történő hatékony kommunikáció biztosítása mellett a nyílt forráskódú projekteknek biztosítaniuk kell a tudás megőrzését és megosztását, hogy elkerüljék azt, hogy “újra fel kelljen találni a kereket”. Az információ megőrzése segít a közreműködőknek abban is, hogy tanuljanak más közreműködők múltbeli hibáiból, és ők már ne kövessék el ugyanazokat a hibákat. Ez a lecke bemutatja a nyílt forráskódú projektben való együttműködés általános eszközeit, és megismertet minket a nemzetközi közösségben való kommunikáció

módjaival. Felfedezhetjük, hogy mindenki számára elérhető az a lehetőség, hogy megtegye első hozzájárulását! A kommunikáció és az információmegosztás példájaként a LibreOffice-t fogjuk megvizsgálni. A LibreOffice egy nyílt forráskódú irodai csomag, amely több, mint száz nyelven érhető el. Végfelhasználói az alkalmi otthoni felhasználóktól a nagy kormányzatokig és vállalatokig terjednek. Hasonlóképpen, széles a közreműködők skálája is nem csak fejlesztők, hanem honosítók, dokumentációs szerzők, marketingesek, minőségbiztosítási mérnökök, infrastruktúraadminisztrátorok, grafikusok és UX-tervezők, és még sokan, sokan mások. Más szóval: A LibreOffice esetén, ahogy sok más nyílt forráskódú projekt esetén is, a saját képességeinket és tehetségünket azon a területen hozhatjuk be, ahol jól érezzük magunkat. Nem kell feltétlenül technikailag képzett embernek vagy fejlesztőnek lennünk a

kreativitásunkat és művészi tehetségünket vagy nyelvtudásunkat is bevethetjük. A projekt elindított egy weboldalt is, amely bemutatja a különböző hozzájárulási területeket: https://whatcanidoforlibreoffice.org A LibreOffice tehát szépen illusztrálja a közösségi munka számos aspektusát. A kommunikáció formái Mielőtt a kommunikációs eszközök részleteivel foglalkoznánk, fontos megérteni, hogyan működik a kommunikáció általában, mivel ezek a szempontok meghatározzák az eszközök kiválasztását. A nyílt forráskódú projektek a kommunikáció két különböző fő módját élvezik. A szinkron kommunikációval az emberek egyszerre kommunikálnak. Ilyen például természetesen a közvetlen beszélgetés, de a videokonferencia vagy a telefonhívás is. Az aszinkron kommunikációval az emberek különböző időpontokban kommunikálnak. Ilyen például az e-mail és az SMS, de a postai levél vagy a telefax is. Ezt a különbséget azonban

nem mindig könnyű megérteni. Például egy mobiltelefonon lévő Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 287 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció messenger alkalmazás, mint a WhatsApp, a Telegram, a Signal vagy az Element technikailag aszinkron kommunikációs mód. Ha azonban mindkét beszélgetőpartner egy időben online van, és azonnal válaszol, akkor közvetlen beszélgetésbe kezdenek. Ez a példa azt mutatja be, hogy a kommunikáció egy része attól is függ, hogy az emberek hogyan használják az eszközeiket, és milyen elvárásaik vannak. Minden feladat más-más kommunikációs eszközkészletet igényelhet. A következő szakaszok részletesen kifejtik ezeket a gondolatokat Szinkron kommunikáció A szinkron kommunikáció nagyon hatékony, de egyben nagyon igényes módja a kommunikációnak. Egyszerre hozza össze az embereket ugyanabban a fizikai vagy virtuális

térben. A közvetlen találkozó ideális arra, hogy interaktív módon beszéljük meg a dolgokat, ahelyett, hogy hosszú, félreértések kockázatával járó e-maileket küldenénk. Képzeljük el, hogy szeretnénk többet megtudni egy nyílt forráskódú projektről, és megismerni a közösség tagjait. Az e-mailek és a weboldalak segíthetnek a bemutatkozásban, és alacsonyabb a belépési korlát, de igazán tartalmas első benyomás akkor alakul ki, ha személyesen is beszélhetünk valakivel általában ezek a közvetlen interakciók azok, amelyek lenyűgözik az embereket egy nyílt forráskódú projekt esetén, és arra késztetik őket, hogy ők is hozzájáruljanak. A szinkron találkozók az ismerkedés mellett arra is kiválóak, hogy interaktív módon beszéljük meg a dolgokat, például konfliktusok vagy problémák esetén, vagy amikor egy negatív üzenetet kell megosztani. A hátránya az, hogy a nemzetközi projektek olyan kihívással szembesülnek,

amelyet a technológia nem tud leküzdeni: az időzónák. Ha a közreműködők különböző kontinenseken élnek, akkor nagyon nehéz lesz olyan időpontokat találni, amelyek mindenkinek megfelelnek. Lehet, hogy valaki Ausztráliában épp akkor ébred fel, amikor valaki Európában már közel van ahhoz, hogy befejezze a munkát. További kihívást jelent, hogy egyesek csak éjszaka vagy hétvégén tudnak dolgozni, míg mások inkább munkanapokon. Ráadásul az angol nyelvet nem mindenki beszéli folyékonyan, és még nem állnak rendelkezésre széles körben elérhető élő fordítási eszközök, ami további akadályt jelenthet. Ennek ellenére a videokonferencia a nyílt forráskódú projektek egyik leggyakoribb kommunikációs eszköze. A LibreOffice projekt, amely példaként szolgál ehhez a leckéhez, rendszeresen tart online megbeszéléseket a közösséggel, például a fejlesztőkkel, a marketinggel, az infrastruktúrával, a minőségbiztosítással, a

felhasználói élménnyel és a tervezéssel. 288 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök Aszinkron kommunikáció Az aszinkron kommunikáció lehetővé teszi, hogy a nekünk megfelelő időben és sebességgel vegyünk részt a beszélgetésben. A legismertebb példa erre valószínűleg az e-mail: akkor válaszolhatunk egy üzenetre, amikor csak akarunk, akár a következő percben, a következő napon vagy a következő órában. Aszinkron kommunikáció esetén a tartalom általában írott, ami ráadásul lehetővé teszi a gépi fordítást. Ez segít elolvasni és megérteni az anyanyelvünktől eltérő nyelven írt üzeneteket, és még a válaszunkat is lefordítja. Ezenkívül a már leírt tartalom sokkal könnyebbé teszi a tudás megőrzését és a dokumentáció elkészítését. Képzeljük el, hogy egy szoftver adott

funkciójának használatáról szeretnénk támogató dokumentumot írni. Ha telefonon magyarázzuk el egy felhasználónak, sokkal nehezebb lesz a beszédből megfelelő dokumentációs oldalt készíteni, mintha írott szövegben magyaráztuk volna el az eljárást. Belső vs külső kommunikáció Végül, de nem utolsósorban a kommunikáció a címzettektől is függ, azaz attól, hogy belső vagy külső címzettről van-e szó. Másképp írunk meg egy belső, technikai jellegű közleményt a rendszergazdáknak, mint egy sajtóközleményt, amelyet több száz újságírónak küldünk el. Ne feledjük azonban, hogy egy nyílt forráskódú projekt jellegéből adódóan az olyan kommunikáció, amelyet esetleg nem kifejezetten nyilvános közönségnek szánnak, mégis publikusan elérhető lesz, például a levelezőlisták archívumában (a LibreOffice esetében a https://listarchives.documentfoundationorg/) Kommunikációs eszközök A kommunikáció ezen különbségek

általános szempontjait szem előtt tartva a következő fejezetekben számos olyan kommunikációs eszközzel ismerkedhetünk meg, amelyeket általában nyílt forráskódú projektekben használnak. E-mail, levelezőlisták és hírlevelek Az egyik első eszköz, amellyel akkor találkozunk, amikor részt veszünk egy nyílt forráskódú projektben, a “klasszikus” e-mail. Sok projekt levelezőlistákat üzemeltet, amelyek lényegében email terjesztési listák: egyetlen e-maillel több száz vagy akár több ezer feliratkozót érhetünk el, akiket érdekelnek bizonyos témák. A levelezőlisták minden nyílt forráskódú projekt esetén a legrégebbi ismert eszközök közé Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 289 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció tartoznak, és a projekten belüli koordinációra, valamint a felhasználókkal való kapcsolattartásra is használják

őket. Ha kérdésünk van a szoftverrel kapcsolatban, vagy hibát szeretnénk jelenteni a programban, nagy az esélye annak, hogy van olyan levelezőlista, amely lehetővé teszi ezt. A LibreOffice közösség például számos nemzetközi és helyi levelezőlistát kínál különböző témákra (https://www.libreofficeorg/get-help/mailing-lists/), a felhasználói támogatástól kezdve a fejlesztői megbeszéléseken át az infrastruktúra koordinálásáig (A LibreOffice levelezőlistáinak weblapja). Figure 17. A LibreOffice levelezőlistáinak weblapja A későbbi felhasználás érdekében minden elküldött üzenetet általában eltárolnak egy nyilvános levelezőlista-archívumban is. Az egyszer elküldött üzenetet már nem lehet egykönnyen törölni Egy gyakori mondás szerint “Az internet sosem felejt”. Ezért ajánlatos óvatosan bánni azzal, amit írunk, mert valószínűleg nem tudjuk visszavonni. Vannak például, akiknek az aláírásukban szerepel a

privát címük vagy telefonszámuk, vagy bizalmas dokumentumokat küldenek csatolmányként, amit gondosan kerülni kell. A levelezőlisták egyik hátránya, hogy kezelésük a levelezőprogramban nem mindig egyszerű. Az üzenet bizonyos elemei, például a tárgy előtagja alapján úgynevezett szűrőket (filter) kell létrehozni. A nagy mennyiségű e-mail kezelésének finomságai akadályokat jelenthetnek a 290 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök tapasztalatlan felhasználók számára különösen, ha egy egyszeri üzenetről van szó. Ezért egyre több projekt tér át a fórumokra, amelyekről hamarosan lesz szó. A levelezőlista egy speciális formája a hírlevél. Ha naprakészek akarunk maradni a projekt legújabb fejlesztéseiről és értesülni az új szoftverkiadásokról, akkor feliratkozhatsunk a hírlevélre, és ha

valami fontos történik, kapunk egy e-mailt. Fórumok Attól eltekintve, hogy a levelezőkliensben problémás a levelezőlisták kezelése, az e-mail másik hátránya, hogy egyre több ember, különösen a fiatalabb generáció már nem annyira kedveli a kommunikáció ezen formáját. Emiatt és más okok miatt egyre több nyílt forráskódú projekt helyezi át a kommunikációját fórumokra (discussion forum). Az általános elképzelés nagyon hasonló az emailhez: minden fórumnak vannak különböző kategóriái, amelyekben meghatározott témákról lehet vitát folytatni, úgynevezett thread-ek (szálak). Az emailhez hasonlóan a fórumon is kapcsolatba léphetünk a nyílt forráskódú projekttel, és koordinálhatjuk a tevékenységeket, javaslatokat tehetsünk a projekt irányára vonatkozóan, valamint végfelhasználóként jelenthetjük a hibákat. A fórumra feltöltött üzenetek általában a nagyközönség számára is láthatóak, akárcsak egy

levelezőlistán; de a fórum konfigurációjától függően a fórum tartalma később is szerkeszthető vagy törölhető. A fórumok használhatósága, különösen a tapasztalatlan felhasználók számára, gyakran egyszerűbb, mint a levelezőlistáké. A LibreOffice projekt több levelezőlistáját kezdte fórummá alakítani (https://community.documentfoundationorg/), és azóta megnőtt a vitákban résztvevők száma. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 291 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Figure 18. A LibreOffice fórumainak weblapja Azonnali üzenetek és chat platformok Egy másik módja a nyílt forráskódú közösséggel való kapcsolatfelvételnek az azonnali üzenetek és a chatplatformok. Az olyan népszerű eszközök, mint a WhatsApp, a Telegram, a Signal és a Matrix elterjedésével szinte mindenki telepítette már valamelyik népszerű alkalmazást az

eszközére, ami sokkal alacsonyabbá teszi a belépési korlátot. Az azonnali üzenetek a fiatalabb generáció körében is sokkal népszerűbbek, mint az e-mail vagy a fórumok. Ezért nem meglepő, hogy manapság sok nyílt forráskódú projekt alkalmazza őket. A csevegések résztvevői üzeneteket írnak, amelyeket az összes többi résztvevőnek elküldenek, hasonlóan az e-mailhez. A csevegőplatformtól függően az üzenetet formázással, grafikákkal és mellékletekkel lehet gazdagítani. Szerkezetileg az üzenőalkalmazások a fórumokhoz vagy az e-mailekhez hasonlóan szerveződnek. Számos csoport vagy csatorna áll rendelkezésre, így a minket érdeklő témákról szóló beszélgetésekhez csatlakozhatunk. Az üzenetek általában szerkeszthetők vagy törölhetők, és gyakran vannak olyan, csak bejelentésre szolgáló csatornák is, amelyek az e-mail formátumú hírlevelekhez hasonló funkcióval rendelkeznek. Az azonnali messenger (üzenetküldő)

alkalmazások egyik hátránya, hogy az emberek általában a telefonjukra telepítik őket, így minden elküldött üzenetről értesítést kapnak. Ez gyorsan 292 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök információ túlcsordulásba vagy “riasztási fáradtságba” (alert fatigue) torkollhat. Megfelelő konfigurációval azonban kordában tarthatók ezek az értesítések. Egy másik hátránya, hogy sok messenger alkalmazás zárt és egy gyártó kezében van. Ez megnehezíti a tudás hosszú távú megőrzését, ha az adatok nem szabadon hozzáférhetők. Önálló, szövetségi és központosított kommunikáció A nyílt forráskódú projektek nyíltan, nyílt szabványok és nyílt eszközök alapján működnek. Ezért kritikus fontosságú annak megértése, hogy a különböző eszközöket hogyan tervezték meg az

interoperabilitás szempontjából. A lehetőségek három fő kategóriába sorolhatók A stand-alone (önálló) platform egy közösség elszigetelt felülete. Ilyenek például a fórumok vagy a wikik, amelyek általában nem kapcsolódnak más projektek példányaihoz. A decentralizált vagy federated (szövetségi) rendszerek minden közösség számára külön-külön működnek, de kapcsolódhatnak egymáshoz. Egy példa erre az e-mail, mert egy helyi e-mail szerver a világ bármelyik másik e-mail szerverére küldhet e-mailt. További példák a Nextcloud és az ownCloud, amelyek képesek “megosztani” a fájlmegosztásokat más szerverekkel; valamint az Element messenger szolgáltatás, amellyel más szerverek felhasználóival lehet kommunikálni. Ugyanezek az elvek érvényesek a Mastodon közösségi hálózatra is. Mind az önálló, mind az elosztott platformoknak van egy hatalmas előnye: a nyílt forráskódú projekt továbbra is teljes mértékben ellenőrzi a

tartalmat és a funkciókat. Az ilyen rendszerben tárolt összes tudás a nyílt forráskódú közösség tulajdona marad, és nem kerül harmadik felek kezébe. A centralizált rendszert viszont egy szolgáltató működteti, és nem lép kapcsolatba harmadik felekkel. Klasszikus példák erre a közösségi platformok, mint a Facebook vagy az Instagram, vagy az messenger alkalmazások, mint a WhatsApp vagy a Telegram. Minden tartalom a külső szolgáltató szerverein tárolódik, és az ő feltételei vonatkoznak rá. Ha aktívan részt veszünk egy nyílt forráskódú közösségben, valószínűleg mindhárom lehetőséggel találkozunk. A központosított rendszerek kiválóan alkalmasak az emberek elérésére, mivel gyakran népszerűek és nagy felhasználói bázissal rendelkeznek. A projektben végzett tényleges munkához azonban a közösség ellenőrzése alatt álló, szövetségi vagy önálló rendszer a legjobb. Kollaborációs eszközök A kommunikációs és a

kollaborációs eszközök közötti különbségtétel nem mindig egyértelmű. E lecke szempontjából a kommunikációs eszközök fő célja, hogy lehetővé tegyék a különböző résztvevők közötti általános kommunikációt, míg a kollaborációs eszközök fő célja, hogy segítsék Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 293 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció az emberek együttműködését. A megfelelő kollaborációs eszközök lehetővé teszik a fájlok tárolását, a valós idejű együttműködést dokumentumokon, a dokumentumverziók és a szoftver releasek közötti változások nyomon követését, és még sok minden mást. Míg az e-mail vagy a fórumok általános célú tárolásra szolgálhatnak, a speciális eszközök könnyebben hozzáférhetővé teszik a tudást és sokkal hatékonyabbá az együttműködést. Más szóval, ezek speciális

eszközök speciális feladatokra. Ha hozzá szeretnénk járulni egy nyílt forráskódú projekthez, nagyon hamar találkozunk majd velük. Wikik Az együttműködés egyik legrégebbi és legnépszerűbb eszköze a wiki. A wiki, amelyet különösen a Wikipedia tett híressé, lehetővé teszi a felhasználók számára, hogy együtt dolgozzanak egy olyan weboldalon, amely több dokumentumból vagy “cikkből” áll össze. Ezeket különböző kategóriákba lehet csoportosítani, nyelv szerint szűrni, és tartalmazhatnak formázásokat, táblázatokat és képeket. A wikiket gyakran használják tudásbázisként, amihez mindenki hozzájárulhat. Ha egy nyílt forráskódú projekthez szeretnénk valamilyen tartalommal hozzájárulni, a legegyszerűbb mód a wiki szerkesztésében való részvétel. Átvehetjük a meglévő tartalmat, és lefordíthatjuk azt az anyanyelvünkre, szerkeszthetjük és frissíthetjük a meglévő cikkeket, vagy létrehozhatunk új tartalmat. A

LibreOffice projekt wikijében (https://wiki.documentfoundationorg) marketinganyagokat, vezetőségi ülések jegyzőkönyveit, telepítési utasításokat és konferenciák terveit találhatjuk meg, ráadásul több nyelven (LibreOffice Wiki). 294 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök Figure 19. LibreOffice Wiki Sok nyílt forráskódú projekt a dokumentációját és a programjukba integrált súgórendszert is egy wikiben tárolja. Ezen kívül egy oldal régi verzióit az úgynevezett revíziókat archiválják a későbbi hivatkozás céljából. Bár a wikik is képesek projektfájlok tárolására, erre a célra léteznek jobb eszközök, amint azt ebben a leckében meg fogjuk tanulni. Bug és issue trackerek Egy másik gyakran használt eszköz egy nyílt forráskódú projektben a bug tracker (hibakövető), más néven issue

trackers (problémakövető). Ha problémát fedezünk fel a szoftverben, vagy egy új funkciót szeretnénk javasolni, gondolhatunk arra, hogy egyszerűen küldünk róla egy e-mailt. Egy olyan dedikált eszközzel azonban, mint a bug tracker, strukturáltan megadhatjuk a probléma reprodukálásához szükséges összes információt és lépést, ami megkönnyíti a fejlesztők számára a probléma reprodukálását. Az ilyen strukturált jelentést hibajelentésnek (bug report) nevezzük Ráadásul az információ nem vész el, és a projekt nem feledkezik meg a problémáról; a megfelelő személyhez rendelhetik azt, és láthatjuk, hogy hány hibát dolgoznak fel vagy javítanak ki. A LibreOffice projekt egy olyan bug trackert biztosít, amely mindenki számára nyitott Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 295 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció

(https://bugs.documentfoundationorg) Figure 20. LibreOffice bug tracker Helpdeskek és ticketing rendszerek Nagyon hasonló eszköz a helpdesk vagy ticketing system. Ennek középpontjában kevésbé áll a szoftverproblémák bejelentése, hanem inkább a felhasználók segítése mindenféle problémával és kéréssel kapcsolatban, például a projekt weboldalával összefüggésben. A klasszikus helpdesk egy ügyfélszolgálati forródrót. Az ügyfél telefonál és jelzi a problémáját, amelyből ticket (jegy) lesz. A helpdesk rendszer munkafolyamata általában a prioritások, az eszkalációs szintek és a válaszidő körül forog. Nem minden nyílt forráskódú közösség biztosít ilyen rendszert, de sok kereskedelmi vállalat igen. A LibreOffice projektben például van egy jegyrendszer az infrastruktúra számára a szerverekkel és webes szolgáltatásokkal kapcsolatos problémák bejelentésére. Tartalomkezelő rendszer (Content Management System CMS) Az

együttműködés másik fontos eszköze a tartalomkezelő rendszer (CMS). Amint a neve is mutatja, ez segít a tartalom kezelésében, leginkább a weboldalak esetében. Ha hozzá szeretnénk járulni egy projekt weboldalának tartalmához vagy tervezéséhez, akkor érdemes megismerkednünk a CMS-sel. A wikikhez hasonló CMS-rendszerek segítenek a tartalom kategóriák és nyelvek szerinti strukturálásában. Gyakran biztosítanak WYSIWYG (“what you see is what you get`”, “amit látunk, azt kapjuk”) szerkesztőt, és mindent megfelelő sablonba ágyaznak: a címek, címsorok, az oldal elrendezése és a menübejegyzések automatikusan elkészülnek, így teljes mértékben a tartalomra koncentrálhatunk. Ráadásul az oldal újratervezése esetén a tartalom nem tűnik el, hanem az új sablonhoz igazodik. 296 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési

eszközök Dokumentumkezelő rendszer (Document Management System DMS) A dokumentumkezelő rendszer nem tévesztendő össze a tartalomkezelő rendszerrel. Míg egy CMS-t arra terveztek, hogy a tartalmat egy előre meghatározott sablonban jelenítse meg, például egy weboldal esetén, addig egy DMS-t dokumentumok, például szerződések, számlák, bizonylatok, e-mailek és mindenféle egyéb levelezés kezelésére használnak. Egy másik különbség az, hogy a CMS-t gyakran használják nyilvános prezentációk esetén, míg a DMS-t többnyire olyan belső dokumentumok kezelésére használják, amelyeket nem a nagyközönségnek szánnak. Egy nyílt forráskódú projektben kevésbé valószínű, hogy közreműködőként találkozunk a dokumentumkezelő rendszerrel, mivel az gyakran speciális szerepkörök, például a könyvelés vagy a jogi osztály számára van fenntartva. Forráskód menedzsment (Source Code Management SCM) Ha fejlesztőként veszünk részt egy

nyílt forráskódú projektben, az egyik legfontosabb eszköz, amellyel talákozunk, a forráskód-menedzser platform. Az SCM-eket a dokumentáció szerzőinek wikijéhez hasonlóan a szoftverfejlesztők használják a kóddal való közös munkára. A történelmi SCM-ek közé tartozik a CVS és a Subversion, de manapság leginkább a Git-et használják, többek között a LibreOffice közösség is (https://git.libreofficeorg/) Ezek az eszközök parancssorban is elérhetők, de grafikus felületük is van, hogy (különösen a kezdők számára) megkönnyítsék a kezelésüket. A forráskód-kezelő platformok nyomon követik az egyes fájlok különböző verzióit, kezelik a kód módosításait és szerkesztéseit, rögzítik, hogy ki milyen módosítást végzett, és ideális esetben teljes történetet adnak a szoftver fejlesztéséről. A fejlesztők “kicheckolhatják” (check out) a szoftver egy adott állapotát, helyben dolgozhatnak rajta, például egy hiba

kijavításával vagy egy új funkció megvalósításával, majd kérhetik, hogy ezt a változtatást egy úgynevezett merge request, más néven pull request segítségével a szoftver fő fejlesztési vonalához adják hozzá. A merge vagy pull request elfogadása “összevonja” (merge) az egyik szerző által elvégzett változtatásokat a fő kóddal. Vannak olyan központi platformok (GitHub és GitLab), amelyek integrálják az SCM-et a wikivel, a problémakövetéssel és más kollaboratív eszközökkel. A forráskód-menedzser platformok nem korlátozódnak szigorúan a programkódra! Például ezen a leckén is egy Git repositoryban dolgoztak közösen a résztvevők. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 297 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Dokumentáció Minden nyílt forráskódú projekt sikerének kulcsa a megfelelő dokumentáció, ideális esetben több

nyelven. A LibreOffice projekt naprakész könyveket, útmutatókat és referenciakártyákat (https://documentation.libreofficeorg) biztosít a szoftveréhez, valamint egyedi segédoldalakat az egyes funkciókhoz (https://help.libreofficeorg) Általánosságban elmondható, hogy a dokumentációnak különböző fajtái vannak, amelyeket a következő fejezetekben tárgyalunk. Felhasználói dokumentáció A legismertebb a végfelhasználóknak szóló dokumentáció, amely elmagyarázza, hogyan kell használni a szoftvert. Ha nem ismerjük a program valamely funkcióját vagy tulajdonságát, a dokumentáció amely az egyszerű súgóoldalaktól a teljes könyvig terjedhet az első hivatkozási pont. A dokumentációs weboldal, ahol a szoftver használatát magyarázzák el, gyakran az egyik leglátogatottabb weboldal a termék weboldal mellett, amely áttekintést nyújt a szoftverről és annak közösségéről. Adminisztrátori dokumentáció Nagyobb környezetekben,

például vállalati telepítések esetén a rendszergazdai dokumentáció minden lényeges információt megad a szoftver nagyobb léptékű telepítéséhez. Ez magában foglalja a felhasználói adatbázisokhoz és fájltárolókhoz való csatlakozást, a központi konfigurációkezelést és a frissítések kezelését. Fejlesztői és architektúra dokumentáció A dokumentáció egy másik kategóriája a fejlesztőket célozza meg, és fejlesztői dokumentációnak vagy architektúra dokumentációnak nevezik. Ha fejlesztőként szeretnénk hozzájárulni egy program kódjához, ez a dokumentáció tájékoztat minket a szoftver architektúrájáról, a kódolási szabványokról, valamint a szoftveren való munkavégzéshez használt eszközökről és munkafolyamatokról. A LibreOffice projekt közzétett egy fejlesztői útmutatót a wikin, hogy segítse az érdeklődő fejlesztőket a közösséghez való csatlakozásban (https://wiki.documentfoundationorg/

Documentation/DevGuide). 298 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök Gyakorló feladatok 1. Miért kell különösen a nyílt forráskódú projekteknek kommunikációs és együttműködési eszközökről? gondoskodniuk a megfelelő 2. Nevezzünk meg egy-egy példát a szinkron és aszinkron kommunikációra! 3. Mi a messenger alkalmazások hátránya és hogyan lehet ezt elkerülni? 4. Nevezzük meg a wiki két funkcióját! 5. Mi a különbség a bug tracker és a helpdesk rendszer között? 6. Mi a különbség a tartalomkezelő és a dokumentumkezelő rendszer között? 7. Mi az önálló vagy szövetségi rendszerek előnye a központosított rendszerekkel szemben? Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 299 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és

kommunikáció Gondolkodtató feladatok 1. Mi az egyik fő különbség egy helyi sportklub és egy nemzetközi nyílt forráskódú projekt között? 2. Miért lehet különösen kifizetődő egy nyílt forráskódú projekthez való hozzájárulás? 3. Melyik bug tracker szoftvert használja az Ubuntu projekt? 4. Mi a neve annak a weboldalnak, ahol a Linux kernel levelezési listái találhatók? 300 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök Összefoglalás Ebben a leckében megismerkedtünk a nyílt forráskódú projektekben való kommunikációra és együttműködésre használt különböző eszközökkel. Láthattuk, hogy mi a különbség a szinkron és az aszinkron kommunikáció, valamint a decentralizált, a centralizált és az önálló eszközök között. Azt is megtudtuk, hogy miért lehetnek hasznosak bizonyos eszközök

bizonyos feladatokhoz, annak érdekében, hogy a nyílt forráskódú projekthez való hozzájárulás szórakoztató és kifizetődő legyen. Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 301 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Válaszok a gyakorló feladatokra 1. Miért kell különösen a nyílt forráskódú projekteknek kommunikációs és együttműködési eszközökről? gondoskodniuk a megfelelő Egyrészt a világ különböző pontjain lévő csoportokban való együttműködésnek megvannak a maga kihívásai, amelyek kezelésében a megfelelő eszközök segíthetnek. Másrészt az önkéntesek nem biztos, hogy a végtelenségig maradnak, így a tudás megőrzése és megosztása egy másik fontos szempont a kommunikációs és együttműködési eszközök használatában. A hozzájárulások megkönnyítése segíti a projekt fenntarthatóságát. 2. Nevezzünk meg egy-egy

példát a szinkron és aszinkron kommunikációra! A szinkron kommunikáció lehet közvetlen beszélgetés, telefonhívás vagy videokonferencia. Az aszinkron kommunikációra példa az e-mail, az SMS, a postai levél és a fax. 3. Mi a messenger alkalmazások hátránya és hogyan lehet ezt elkerülni? A telefonra való telepítés után sok értesítést kaphatunk, minden egyes új üzenetről egyet. A megfelelő konfiguráció segíthet ezt elkerülni. További hátrány, hogy sok messenger alkalmazást saját fejlesztésű gyártók futtatnak. 4. Nevezzük meg a wiki két funkcióját! Cikkek közös szerkesztése és fordítása. 5. Mi a különbség a bug tracker és a helpdesk rendszer között? A bug tracker egy speciális szoftver tool, amellyel hibákat jelenthetünk be vagy funkciókat kérhetünk a szoftverhez. A helpdesk rendszer a megkeresések támogatására és mindenféle probléma és kérés kezelésére összpontosít, pl. a weboldalon 6. Mi a különbség a

tartalomkezelő és a dokumentumkezelő rendszer között? A CMS-t a tartalom meghatározott módon vagy sablonban történő bemutatására használják, többnyire nyilvánosan. A DMS-t a meglévő levelezés tárolására használják, többnyire belsős környezetben. 7. Mi az önálló vagy szövetséges rendszerek előnye a központosított rendszerekkel szemben? A központosított rendszer egy külső szolgáltató ellenőrzése alatt áll. Minden tartalom a külső szolgáltató szerverein tárolódik, és az ő feltételei vonatkoznak rá. 302 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12 Open Source Essentials (Version 1.0) | 0563 Kommunikációs és együttműködési eszközök Válaszok a gondolkodtató feladatokra 1. Mi az egyik fő különbség egy helyi sportklub és egy nemzetközi nyílt forráskódú projekt között? A nyílt forráskódú projektek nem kötődnek egy adott nyelvhez vagy helyhez. A közreműködők

különböző országokban és kontinenseken élhetnek, anyanyelvük, sőt, még az időzónák is eltérhetnek. A nyílt forráskódú projektekben végzett tevékenység nagy része virtuálisan történik, nem pedig személyesen. 2. Miért lehet különösen kifizetődő egy nyílt forráskódú projekthez való hozzájárulás? Nyílt forráskódú projektekben általában sokféle ember vesz részt. Ha együttműködünk velük, tanulhatunk tőlük, új dolgokat fedezhetünk fel, és szélesíthetjük a látókörünket. 3. Melyik bug tracker szoftvert használja az Ubuntu projekt? Launchpad 4. Mi a neve annak a weboldalnak, ahol a Linux kernel levelezési listái találhatók? https://lkml.org/ Version: 2024-08-12 | CC BY-NC-ND 4.0 alatt licencelve | learning.lpiorg | 303 Open Source Essentials (Version 1.0) | Témakör 056: Együttműködés és kommunikáció Impresszum 2024 Linux Professional Institute: Learning Materials, “Open Source Essentials (Version 1.0)”

PDF generálva: 2024-08-12 Ez a mű a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC BY-NC-ND 4.0) alatt jelenik meg A licenc másolata az alábbi helyen érhető el: https://creativecommons.org/licenses/by-nc-nd/40/ Míg a Linux Professional Institute jóhiszemű erőfeszítéseket tett annak biztosítására, hogy az ebben a munkában szereplő információk és instrukciók pontosak legyenek, a Linux Professional Institute nem vállal felelősséget a hibákért vagy kihagyásokért, beleértve a mű használatából vagy a rá való hagyatkozásból származó károkat. Az ebben a munkában szereplő információk és instrukciók felhasználása saját felelősségre történik. Abban az esetben, ha bármilyen példakód vagy egyéb technológia, amelyet ez a mű tartalmaz vagy leír, nyílt forráskódú licencekre vagy szellemi tulajdonjogokra vonatkozik, akkor az Ön felelőssége, hogy úgy használja ezeket, hogy az megfeleljen az ilyen

licenceknek és/vagy jogoknak. Az LPI Learning Materials a Linux Professional Institute (https://lpi.org) kezdeményezése A tananyagok és a fordításaik a https://learning.lpiorg oldalon érhetők el Ezzel a kiadással és az egész projekttel kapcsolatos kérdéseket és megjegyzéseket az alábbi e-mail címre küldheti el: learning@lpi.org 304 | learning.lpiorg | CC BY-NC-ND 4.0 alatt licencelve | Version: 2024-08-12