Dr. mogyorósi istván
- ügyvéd
- irodája
Open Source jog
A modern szoftverfejlesztésben a legritkább esetben fordul elő, hogy egy szoftvertermék minden egyes sora saját, nulláról írt fejlesztés. A legtöbb üzleti alkalmazás és felhőplatform számos külső építőelemet nyílt forráskódú (open source) könyvtárakat, keretrendszereket, SDK-kat, API-kat, bővítményeket (pluginokat) és harmadik félhez tartozó modulokat tartalmaz, amelyek technológiailag rendkívül értékesek, ám jogszerűen csak a rájuk irányadó licencfeltételek maradéktalan betartása mellett hasznosíthatók.
Az Open Source jog legfontosabb alapelve, hogy a nyílt forráskód nem jelent korlátozás nélkül, szabadon felhasználható közkincset. Az egyes open source licencek szigorú kötelezettségeket írhatnak elő: a szerzői jogi nyilatkozatok és licencszövegek továbbadásától kezdve a módosítások dokumentálásán át egészen addig a fertőző (copyleft) hatásig, amely a saját üzleti forráskód nyilvánosságra hozatalát is kikényszerítheti.
Jogi támogatást nyújtok szoftverházaknak, SaaS-szolgáltatóknak, technológiai startupoknak és szoftvert beszerző vagy felvásárló nagyvállalatoknak a nyílt forráskódú komponensek jogi átvilágításában, a licenc-kompatibilitás biztosításában és a befektetői (M&A due diligence) felkészítésben.
Miben segítek az Open Source jog területén?
Licenc kompatibilitás: GPL, AGPL, LGPL, MIT és Apache licencek elemzése
Kereskedelmi szoftver fejlesztésekor és értékesítésekor alapvető különbséget kell tenni az eltérő nyílt forráskódú licencmodellek között. A jogi elemzés során a szoftver architektúrája és terjesztési modellje alapján vizsgálom az egyes komponensek összeférhetőségét:
- Megengedő (Permissive) licencek (pl. MIT, BSD, Apache 2.0): jellemzően széles kereskedelmi mozgásteret biztosítanak és zárt forráskódú üzleti termékbe is beépíthetők, de a forrásmegjelölési, licencszöveg-továbbadási, módosítás-jelölési és szabadalmi klauzulákat itt is pontosan teljesíteni kell;
- Gyenge copyleft licencek (pl. LGPL, MPL): lehetővé teszik a kereskedelmi szoftverrel való összekapcsolást, amennyiben a műszaki illesztés (pl. dinamikus linkelés, elkülönített könyvtárak) és a cserelehetőség megfelel a licenc szigorú technikai feltételeinek;
- Erős copyleft licencek (pl. GPL v2 / v3): ha a saját fejlesztésű szoftver a GPL-komponenssel szoros egységet alkot és terjesztésre kerül, a licenc előírhatja, hogy a teljes kombinált szoftvertermék forráskódját hozzáférhetővé kell tenni ugyanazon GPL licenc alatt;
- Hálózati copyleft és SaaS kockázatok (AGPL, SSPL): míg a klasszikus GPL kötelezettségek a szoftverpéldány terjesztéséhez kötődnek, az AGPL már akkor is kiválthatja a forráskód-megosztási kötelezettséget, ha a szoftvert nem adják át, hanem felhőalapú szolgáltatásként (SaaS) hálózaton keresztül teszik elérhetővé.
Forráskód-védelem: a saját üzleti kód nyilvánosságra hozatali kényszerének elkerülése
Egy technológiai vállalkozás számára a legértékesebb vagyonelem a saját fejlesztésű, zárt forráskód (proprietary code). Az Open Source jogi tanácsadás kiemelt célja, hogy megakadályozza az üzleti szoftver akaratlan megfertőzését copyleft kötelezettségekkel:
- Műszaki és jogi szeparáció vizsgálata: annak elemzése, hogy a nyílt forráskódú elem hogyan kapcsolódik a saját szoftverhez (statikus vagy dinamikus linkelés, API-hívás, különálló mikroszerviz, konténerizáció), és ez keletkeztet-e származékos művet;
- Belső fejlesztői jóváhagyási folyamat (OSS Policy): egyértelmű szabályrendszer kialakítása arra, hogy a fejlesztők milyen licencű könyvtárakat építhetnek be szabadon, melyek igényelnek előzetes jogi/CTO engedélyt, és melyek tiltottak;
- Kettős licencelés (Dual-licensing) és kereskedelmi kivételek: saját fejlesztésű nyílt forráskódú projektek üzleti modelljének kialakítása (nyílt közösségi verzió + fizetős vállalati licenc), illetve külső copyleft komponensekhez kereskedelmi licenc beszerzése;
- Third-Party Notices és dokumentáció: a szoftverhez vagy SaaS-szolgáltatáshoz kötelezően mellékelendő szerzői jogi nyilatkozatok, licencszövegek és forrásmegjelölési listák jogszerű összeállítása.
Open Source megfelelőség: cégfelvásárlási (M&A) és befektetői átvilágításra való felkészítés
Egy szoftver open source elemeinek kockázata leggyakrabban befektetői átvilágítás (due diligence), vállalatfelvásárlás (M&A) vagy nagyvállalati szoftverértékesítés során kerül a felszínre. Ha a kulcsfontosságú szoftver olyan nyílt forráskódú komponenst tartalmaz, amelynek licencfeltételei ütköznek az üzleti modellel, az súlyos értékcsökkentő tényező vagy akár tranzakciós akadály (deal-breaker) is lehet:
- Software Bill of Materials (SBOM) jogi kiértékelése: a szoftver összes összetevőjét, külső könyvtárát, függőségét és azok egymáshoz való viszonyát felsoroló strukturált nyilvántartás (SBOM) jogi átvilágítása;
- Fejlesztői jogszavatosság védelme: amikor a szoftverház szerződésben garantálja a megrendelőnek, hogy a termék harmadik személy jogait nem sérti és kizárólagos vagyoni jogokat biztosít, ezt a vállalást összhangba kell hozni a beépített open source komponensek licencfeltételeivel;
- Kockázatmentesítés (Remediation) tranzakció előtt: a problémás copyleft komponensek azonosítása, jogi-architekturális leválasztása vagy kiváltása még a befektetői adat-szoba (data room) megnyitása előtt.
Külső szoftverkomponensek, SDK-k, API-k és AI-kódgenerálás
Az open source könyvtárak mellett a modern szoftverek gyakran építenek kereskedelmi SDK-kra, harmadik fél API-jaira, ingyenesen letölthető (freeware, de nem open source) modulokra és AI-kódasszisztensek által javasolt kódrészletekre. Ezeknél külön vizsgálni kell a továbbterjesztési (redistribution) jogokat, a végfelhasználói korlátokat, valamint azt a kockázatot, hogy a generatív AI-eszközök a tanítóadatokból származó, copyleft licenc alá eső kódrészleteket emelhetnek be a saját forráskódba.
Miért igényel külön jogi kontrollt az Open Source komponensek használata?
A fejlesztői gyakorlatban a külső csomagok és függőségek (dependencies) behúzása néhány másodperces technikai művelet, amelynek azonban évekkel később súlyos jogi következményei lehetnek. Egyetlen nem megfelelően kiválasztott és közvetlenül beépített GPL vagy AGPL komponens megkérdőjelezheti a szoftvercég kizárólagos szellemi tulajdonjogát, és szerződésszegést eredményezhet a nagyvállalati megrendelők felé vállalt jogszavatossági klauzulákban.
A tudatos Open Source licenc-megfelelőség (OSS Compliance) ezzel szemben lehetővé teszi, hogy a vállalkozás biztonságosan használja ki a nyílt forráskódú ökoszisztéma előnyeit anélkül, hogy veszélyeztetné a saját forráskódja védelmét vagy a cég piaci értékét.
Referenciák és szakmai háttér
- szoftvertermékek és SaaS-platformok nyílt forráskódú komponenseinek (SBOM) és licenc-kompatibilitásának jogi átvilágítása;
- copyleft (GPL, AGPL, LGPL, SSPL) és permissive (MIT, Apache, BSD) licencek elemzése és kockázatcsökkentő strukturálása;
- szoftverfejlesztési és licencszerződések open source és harmadik fél komponensekre vonatkozó jogszavatossági klauzuláinak kidolgozása;
- vállalati Open Source Compliance szabályzatok, fejlesztői jóváhagyási folyamatok és Third-Party Notices dokumentációk kialakítása;
- befektetés és cégfelvásárlás (M&A) előtti szoftverjogi és open source due diligence támogatás.
Jogi támogatás Open Source ügyekben
1. Open Source licenc-audit és SBOM jogi kiértékelés
- Kinek ajánlott? Szoftverterméket vagy SaaS-szolgáltatást fejlesztő vállalkozásoknak, amelyek szeretnék tisztázni a beépített külső könyvtárak és függőségek jogi kockázatait.
- Eredmény: Írásos kockázatelemzés a komponenslista (SBOM) alapján, a copyleft kockázatok azonosítása, a licenc-kompatibilitás vizsgálata és a kötelező licencnyilatkozatok (Third-Party Notices) összeállítása.
- Következő lépés: A szoftverben használt külső komponensek listájának és a termék értékesítési/terjesztési modelljének áttekintése.
2. Vállalati Open Source Policy és szerződéses védelem kialakítása
- Kinek ajánlott? Szoftverházaknak és fejlesztői csapatoknak, amelyek megelőznék a nem engedélyezett open source licencek beépülését és védenék a megrendelők felé vállalt jogszavatosságot.
- Eredmény: Belső Open Source felhasználási szabályzat (zöld/sárga/piros licenclistával), valamint a fejlesztési és alvállalkozói szerződések open source klauzuláinak pontosítása.
- Következő lépés: A fejlesztési folyamatok és az ügyfélszerződésekben vállalt IP-garanciák összehangolása.
3. Befektetés és M&A előtti Open Source Due Diligence felkészítés
- Kinek ajánlott? Tőkebevonás, cégértékesítés vagy szoftverátruházás előtt álló technológiai társaságoknak, illetve szoftvercéget felvásárló befektetőknek.
- Eredmény: Tranzakciós fókuszú jogi átvilágítás, az értékcsökkentő licenckockázatok feltárása és a problémás komponensek jogi-műszaki kiváltási tervének kidolgozása.
- Következő lépés: Konzultáció a tervezett tranzakcióról és a szoftverportfólió fejlesztési előzményeiről.
Gyakran Ismételt Kérdések az Open Source jogról
Sok esetben igen, de mindig az adott komponensre irányadó konkrét licenc feltételeit kell megvizsgálni. Az open source megjelölés önmagában nem jelenti azt, hogy a kód minden feltétel nélkül beépíthető egy zárt forráskódú kereskedelmi termékbe: még a megengedő (permissive) licencek is előírják a szerzői jogi nyilatkozatok és a licencszöveg feltüntetését.
Nem minden GPL-használat eredményez automatikusan ilyen kötelezettséget. Külön kell elemezni a konkrét licencverziót (pl. GPL v2, GPL v3 vagy LGPL), a nyílt forráskódú komponens és a saját szoftver közötti műszaki kapcsolatot (linkelés, architektúra, önálló programként való működés), valamint azt, hogy történik-e szoftverterjesztés.
Igen. Bár a hagyományos copyleft licencek (mint a standard GPL) kötelezettségei jellemzően a szoftverpéldány átadásához (terjesztéséhez) kapcsolódnak, az olyan hálózati copyleft licencek, mint a GNU AGPL (vagy az SSPL), már akkor is előírják a teljes forráskód hozzáférhetővé tételét, ha a felhasználók csak böngészőn vagy API-n keresztül, SaaS-modellben érik el a szoftvert.
Mert egy nem megfelelően kezelt copyleft licenc korlátozhatja a szoftver kizárólagos kereskedelmi hasznosítását, kikényszerítheti az üzleti titoknak minősülő forráskód megnyitását, vagy megsértheti a nagyvállalati ügyfélszerződésekben vállalt IP-jogszavatosságot mindez pedig közvetlenül csökkenti a céltársaság értékét.
Az SBOM (szoftver-összetevőjegyzék) egy olyan rendszerezett nyilvántartás, amely részletesen felsorolja a szoftverbe épített összes külső komponenst, könyvtárat, verziószámot, függőséget és a rájuk vonatkozó licenceket. Ez a dokumentum az alapja mind a kiberbiztonsági sérülékenységek követésének, mind a fejlesztői jogszavatosság és a licenc-megfelelőség igazolásának.
Ilyenkor többféle jogi és műszaki megoldás létezik: a komponens helyettesítése megengedő (pl. MIT vagy Apache) licencű alternatívával, az adott modul saját kóddal történő újraírása, a szoftverarchitektúra átalakítása (hogy a komponens elkülönült, önálló egységként működjön), vagy ha a jogtulajdonos biztosít ilyet kereskedelmi (dual) licenc megvásárlása.
Előzetes jogi kontroll Open Source licencekhez és szoftvertermékekhez
Szoftvertermék értékesítése, nagyvállalati licencszerződés aláírása vagy befektetői átvilágítás (due diligence) előtt célszerű előzetesen felmérni a beépített nyílt forráskódú komponensek jogi kockázatait. Egy célzott áttekintés segít megvédeni a saját fejlesztésű forráskódot és biztosítani a szoftver jogtisztaságát.
Következő lépés: Személyes vagy online konzultáció keretében áttekintjük szoftvere külső komponenseit, licencmodelljét és az Open Source megfelelőség lépéseit.