Mára nyílt forráskódú szoftverkódok és adatbázisok használata elkerülhetetlen szoftverek és adatbázisok fejlesztése során. Ugyanakkor az ilyen nyílt forráskódú licencek inherens kockázatot rejthetnek magukban, mivel némely licence nem teszi lehetővé a kereskedelmi forgalomban való hasznosítást, a mesterséges intelligencia (AI) tanítását vagy más felhasználási célokat. Ezen törvényi előírásoknak megfelelő termék, azaz szoftver és/vagy adatbázis létrehozása céljából elengedhetetlen annak megértése, hogy a licencfeltételek megfogalmazása végsősoron milyen hatással lesz a fejlesztett termékre. A termékbe beépítendő szoftverkódok, illetve adatbázisrészek kiválasztásakor meg kell győződni arról, hogy azokat olyan licencfeltételek szabályozzák, amelyek lehetővé teszik a kereskedelmi forgalomban való felhasználásukat, megfelelnek a végső szoftvertermék céljának, valamint kompatibilisek más nyílt forráskódú licencfeltételekkel is. Nagy nyomás nehezedik a szakmai szereplőkre, hogy újabbnál újabb szoftvereket és adatbázisokat dobjanak piacra, de a felgyorsult verseny hozadékaként nem mindig veszik kellőképpen figyelembe a nyílt forráskódú licenceket. A jogi kockázat a cég felvásárlásának meghiúsulásához, befektetési lehetőségek elvesztéséhez, vagy alacsonyabb befektetési összegekhez vezethet, továbbá a licencfeltételek megsértése polgári peres eljárásba is torkollhat.

Jogi háttér

A szoftverlicencek értelmezéséhez együtt kell értelmezni az éppen alkalmazandó ország szerzői jogi törvényét és a licencszerződésben lévő kötelmi jogi rendelkezéseket. Emellett nem árt tisztában lenni a szabadalmakkal, formatervezési mintákkal, adatbázisokkal és üzleti titokkal kapcsolatos jogszabályi rendelkezésekkel is. 

A szoftverkód fejlesztője a szoftver szerzője, ezáltal ő a szerzői jog jogosultja. A világ számos országában a munkavállaló által létrehozott szoftvertermék szerzői vagyoni joga automatikusan a munkáltatót illeti meg, feltéve, hogy a munka elvégzése munkavállaló munkaköri kötelességének része volt vagy a feladatot megbízási jogviszony keretében látták el. A szerzői jog monopol jogot biztosít a jogosult számára, azaz a jogosult engedélye nélkül a szoftvert nem használhatják fel harmadik felek, beleértve a kereskedelmi vagy nem-kereskedelmi formában való felhasználást is. A szerzői jog jogosultja szerződésben, nevezetesen szoftverlicenc megállapodásban engedélyezheti a szoftver mások általi felhasználását. A szoftverlicenc megállapodás feltételei tartalmazzák azokat a felhasználási módokat, melyekre a felhasználási engedély kiterjed. Ilyen feltétel lehet például a felhasználás földrajzi területe, a rendeltetése vagy az engedélyezett felhasználók száma.

Amennyiben a szoftver vagy annak egy része szabadalommal, formatervezési mintaoltalommal védett és/vagy üzleti titoknak tekinthető, akkor azok jogosultja (feltételezve, hogy valamennyi jog jogosultja megegyezik) több licenc alapján teheti lehetővé a szoftver felhasználásának engedélyezését. Ha a szoftverhez adatbázis is kapcsolódik, akkor annak felhasználási feltételeit is tekintetbe kell venni. Nyílt forráskódú szoftverek esetén is lehetséges, hogy több párhuzamos licencnek kell egyidejűleg megfelelni. Abban az esetben, ha a szoftverhez és/vagy azok adatbázisaihoz kapcsolódó valamely licenc feltételei harmadik felek által megsértésre kerülnek, akkor az szerződésszegéshez, valamint a szerzői és/vagy más IP (iparjogvédelmi) jogok megsértéséhez vezet. Ha nem állt fenn szerződéses viszony a felek között, akkor a licencfeltételek megsértése „kizárólag” a szerzői és/vagy más IP jogok megsértését jelenti. A fenti jogok megsértése számos polgári jogi jogkövetkezménnyel járhat, többek között a jogsértéssel elért gazdagodás visszatérítését vagy kártérítéshez való jogot.

Toxikus elemek és nyílt forráskódú licencek

Ugyan a nyílt forráskód azt jelenti, hogy a kód nyilvánosan elérhető, a különböző nyílt forráskódú licencek eltérő feltételekkel rendelkeznek, amelyek kihívást jelenthetnek kereskedelmi célú felhasználás vagy az AI alapú szoftverkódok használata szempontjából. Ilyen értelemben a korlátozott jogokat biztosító ó licencek hatálya alá tartozó kód- vagy adatbázis-komponensek „toxikusak” lehetnek, így jelentős jogi és üzleti kockázatokat hordozhatnak magukban.

Vegyünk egy egyszerű példát. Egy kereskedelmi forgalomban hasznosítandó szoftver fejlesztése során gyakori, hogy valamilyen nyílt forráskódú licenc alapján felhasználható kódot építenek be a fejlesztendő szoftverkódba. Ez a kód abban az esetben használható jogszerűen, ha a termék (szoftver) hasznosításakor egyértelműek a licencfeltételek és azok kiterjednek a kereskedelmi célú hasznosításra is. Azonban minél több különböző licence alatti kód kerül beépítésre a szoftverbe, annál több licencfeltételnek kell egyidejűleg megfelelni. Előfordulhat olyan az eset is, hogy a nyílt forráskódú szoftver egy főlicenc mellett további komponenslicenceket is tartalmaz, melyek csak bizonyos fájlokra vagy kódrészletekre terjednek ki.  Amennyiben ezeknek a speciális és komponens licencfeltételeknek – akár csak egyetlen beépített kód tekintetében is – nem vagy nem teljeskörűen felel meg a szoftvertermék, az a licencfeltételekhez kapcsolódó vitához vezethet, ami különösen a kereskedelmi felhasználás esetén fordul elő. 

Vegyünk egy másik életszerű példát: egy AI alapú szoftver fejlesztése során a fejlesztők általában összeállítanak egy tanuló adathalmazt (adatbázist), ami tartalmazhat speciális licenc alapján felhasználható adatokat. Amennyiben egy nyílt forráskódú licenc alapján felhasználható adathalmaz kerül beépítésre a tanuló adathalmazba és a nyílt forráskódú licenc egyedi feltételei korlátozásokat tartalmaz, például az tiltja az AI traininget vagy a kereskedelmi hasznosítást, akkor ezek a korlátozások hatással lesznek a végső szoftvertermékre is. Ennek az az oka, hogy a toxikus adatokat tartalmazó tanuló adathalmazzal való tanítást követően létrejön egy algoritmus, ami az utóbbi idők fejlesztéseinél leggyakrabban egy neurális háló – amely jogi szempontból szintén adatbázisnak tekinthető – akkor a tanuló adathalmazban lévő toxikus adatok “beszennyezik” a neurális hálót is, tehát az is toxikus lesz. Ez egyben azt is jelenti, hogy az AI alapú szoftver minden egyes futtatásakor – mivel az minden alkalommal használja a toxikus neurális hálót – maga is toxikussá válik és egyben toxikus kimentet is eredményez. Amennyiben verziókövetéssel nem azonosítható ez a toxikus (vagy további tanítás esetén az első toxikus) neurális háló, akkor a szoftvertermék sem lesz jogtiszta.

Jogsértő szoftver potenciális következményei

A jogsértő szoftverek számos üzleti kockázatot jelenthetnek, többek között: 

1. a nyílt forráskódú szoftver jogosultja pert indíthat a polgári jogi igények érvényesítése érdekében;
2. a terméket (szoftverkódot, adatbázist és/vagy neurális hálót) le kell cserélni vagy át kell írni, ezért a termék később kerülhet forgalomba, vagy akár szoftvertermék, illetve a szoftver tartalmazó hardver visszahívását is okozhatja;
3. ha a szoftverkód nem módosítható, akkor a szoftverlicenc feltételeinek a beágyazott szoftverkód feltételeit kell tükröznie (valamennyi ilyen beépített kód vonatkozásában), de ez egyes esetekben kizárhatja a végső szoftvertermék kereskedelmi forgalomban való hasznosítást;
4. a cég büntetésekkel és korlátozásokkal nézhet szembe, amíg a szoftver nem teljesíti a megfelelőségi követelményeket, különösen a szabályozott ágazatokban vagy a közbeszerzési eljárásokban.
5. a befektetések vagy a felvásárlások jelentős értékvesztést szenvedhetnek;
6. ez a cég és a szoftvertermék jó hírnevének elvesztéséhez vezethet.

Általánosságban kijelenthető, hogy minél később derül fény arra, hogy toxikus komponens van a szoftverben, annál költségesebb megoldani a problémát.

Lépésről lépésre - avagy nyílt forráskódú licenceknek megfelelő szoftver létrehozása

Egy szoftver fejlesztése során fontos megérteni, hogy hogyan működnek a különböző típusú licencek, azaz milyen feltételeket kell teljesíteni a felhasználásuk során. Az is elengedhetetlen, hogy megfelelő eszközök és protokollok álljanak rendelkezésre a szoftverben felhasznált valamennyi licenc azonosításához és kezeléséhez. Ma már számos online eszköz létezik, ami alkalmas ezen licencek szoftverkódban való nyomon követésére és azonosítására.

A nyílt forráskódú szoftvereknek való megfelelés akkor teljesíthető, ha a szoftver minden komponense megfelel az adott licenc követelményeinek. Az alábbiakban összefoglaljuk hogyan teljesíthetők, illetve ellenőrizhetők ezen követelmények a fejlesztés előtt, során, illetve után. 

A fejlesztés előtt, illetve annak során a fejlesztőcsapat valamennyi tagját megfelelően kell tájékoztatni és oktatni arról, hogy az egyes licencek, beleértve a nyílt forráskódú licenceket, milyen tartalommal bírnak, azaz pontosan mik a következményeik. Ennek legjobb módja egy nyílt forráskódú licencek kezelésére vonatkozó szabályzat létrehozása. A szabályzatnak egyértelműen és átlátható módon kell összefoglalnia: a szoftverkódban hogyan kell azonosítani és megjelölni az adott licenceket, melyek a leggyakrabban előforduló licencek, illetve milyen típusú licencek kell előnyben részesíteni és melyek jelenthetnek kockázatot, azaz melyeket kell kerülni a termék szempontjából.

A szoftverkód vagy adatbáziselemek nyílt forráskódú elemeinek auditálásakor nem elég magát a licencet azonosítani. Az is kulcsfontosságú, hogy megértsük, hogyan használják a nyílt forráskódú kódot vagy adatbázist a termékben és milyen kapcsolat van a felhasználás és a licencfeltételek között. Előfordulhat, hogy a licenc csak a termék validálásához szükséges, azaz nem jelenik meg a végső termékben, ezért másként kell kezelni. Sok esetben a szoftvertermék és licencfeltételek értelmezéséhez szakértő bevonása szükséges.

Amennyiben a fejlesztés után kiderül, hogy a szoftvertermék nem felel meg az összes licencefeltételnek, akkor a probléma megoldására több mód van. Első lépésben érdemes felmérni, hogy a különböző megoldások előnyeit és hátrányait. Kézenfekvő a „toxikus” szoftverkód vagy adatbázis cseréje, azonban ez nem lehetséges, ha az érintett komponens a szoftver „magját” adja vagy a helyettesítés túl sok időt és erőforrást venne igénybe. Másik lehetőség egy alternatív licence beszerzése a jogsértő komponens szoftvertermékben való felhasználására. Ez a lehetőség problémás lehet, mivel a kereskedelmi (vagy más eredetileg nem engedélyezett) felhasználással járó költségek túlzottak lehetnek. Szélsőséges esetben, például, ha a toxikus komponens nem használható fel alternatív licencfeltételek alapján pályázati vagy egyéb támogatási függés miatt, akkor ez az út nem járható, azaz mindenképp törölni kell a termékből a komponenst. 

A bioinformatikai és az élettudományokhoz kapcsolódó szoftverek gyakran kapcsolódnak olyan adatbázisokhoz, például preklinikai és klinikai vizsgálati eredményeket tartalmazó adatbázisokhoz, amelyek csak speciális licenc alapján használhatók fel. Amennyiben a szoftvertermék egy orvostechnikai eszközhöz kapcsolódik, akkor magának az eszköznek a forgalmazása is érintett lehet a licencfeltételeknek való megfeleléstől.

Az orvostudományi fejlesztések körében gyakoriak a szabadalmi bejelentések. Amikor egy szoftverhez vagy adatbázishoz kapcsolódó műszaki know-how-t nyilvánosságra hoznak egy szabadalmi bejelentésben vagy egy kapcsolódó szakcikkekben, de végül a szabadalmat nem adják meg, akkor ez az információ közkinccsé válik. Következésképpen, bár nem szabadalmaztatható ez a műszaki fejlesztés és általános felhasználásra bárki számára elérhetővé válik, a szerzői jogok és az adatbázisjogok továbbra is védhetik azt. Ezen fejlesztéseket védő jogok azonosítása a vonatkozó műszaki publikációk vizsgálatával vagy egy erre a célra irányuló háttérkutatással határozható meg.

Összefoglalva, már a szoftver vagy adatbázis fejlesztésének kezdetén érdemes meghatározni azt a szabályrendszert, ami biztosítja a jogtiszta szoftver létrehozásának kereteit. Ennek elmulasztása súlyos, potenciálisan helyrehozhatatlan problémákat okozhat, amelyek akár a projekt meghiúsulásához is vezethetnek.