054.3 Lesson 1

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.

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.

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:

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, SaaS-szerző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.

Mint láttuk, egy projekt tagjai néha nem értenek egyet a projekt ütemtervével, vezetésével vagy 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.

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.

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.

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.

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:

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 SBOM-ot e formátumok valamelyikében.

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.

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:

Az OSPO koordinálhatja ezen irányelvek kidolgozását és a megfelelőség biztosításához szükséges oktatást.

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.

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.

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:

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.