054.2 Lecke 1

Ha a szolgáltatás teljes egészében vagy nagy részben nyílt forráskódú szoftveren alapul, akkor azt 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.

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.

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.

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 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és-ellenő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 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.

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.

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ő.

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ú 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.