Kié a forráskód? A szoftverfejlesztési szerződés 8 kritikus pontja

„Kifizettük, tehát a miénk.” — ez az egyik leggyakoribb félreértés az egyedi szoftverek körül. A forráskód körüli jogok azonban nem a számla kiegyenlítésével, hanem a szerződés szövegével dőlnek el. Ha a szerződés hallgat, a törvény szabályai lépnek be, és ezek nem feltétlenül a megrendelő szempontjait követik. Az alábbi nyolc pont abban segít, hogy a szerződéskötésnél a jó kérdéseket tedd fel — akár velünk, akár mással dolgozol.

Mit mond a törvény a szoftverről?

A szerzői jogról szóló 1999. évi LXXVI. törvény (Szjt.) kifejezetten a védett művek közé sorolja a számítógépi programalkotást és a hozzá tartozó dokumentációt, akár forráskódban, akár tárgykódban rögzítették. A szoftver tehát szerzői mű, a felhasználását pedig jellemzően felhasználási szerződés rendezi: a jogosult engedélyt ad a felhasználásra, a felhasználó ennek fejében díjat fizet. Néhány alapszabály, amelyet érdemes fejben tartani:

• Kizárólagosság csak kifejezett kikötéssel. Ha a szerződés nem mondja ki, hogy a felhasználási jog kizárólagos, akkor nem az — a jogosult elvileg másnak is engedélyezheti ugyanannak a műnek a felhasználását.
• Ami nincs leírva, az szűken értendő. Ha a szerződés nem jelöli meg a felhasználási módokat és a mértéket, az engedély a szerződés céljához elengedhetetlenül szükséges körre korlátozódik. Ha a tartalom nem állapítható meg egyértelműen, a törvény a szerző számára kedvezőbb értelmezést rendeli el.
• Továbbadás és módosítás csak kifejezett engedéllyel. A felhasználó a jogot harmadik személyre csak akkor ruházhatja át, illetve csak akkor adhat további engedélyt, ha ezt a szerző kifejezetten megengedte; az engedély pedig csak kifejezett kikötés esetén terjed ki a mű átdolgozására.
• Szoftvernél a vagyoni jogok átruházhatók. Az Szjt. a szoftverre külön kimondja ezt, így felhasználási engedély helyett a vagyoni jogok átruházásában is meg lehet állapodni. Hogy melyik konstrukció illik a helyzetedhez, azt ügyvéddel érdemes eldönteni.
• Írásbeliség. A felhasználási szerződést főszabály szerint írásba kell foglalni; a törvény kivételként említi például a szoftver nem kizárólagos felhasználására szóló szerződést. Egyedi fejlesztésnél ettől függetlenül minden lényeges pontot írásban rögzíts.

Jogok: mit kapsz pontosan?

1. A felhasználási jog terjedelme

Ez a szerződés szíve. Rögzítsd, hogy a jog kizárólagos-e vagy sem; milyen felhasználási módokra terjed ki (futtatás, többszörözés, módosítás, továbbfejlesztés, harmadik félnek történő átadás); milyen területre és mennyi időre szól. A törvény szerint eltérő rendelkezés hiányában az engedély Magyarország területére terjed ki, időtartama pedig a hasonló szerződéseknél szokásoshoz igazodik — ha a szoftvert külföldi leányvállalat, franchise-partner vagy a te ügyfeleid is használnák, ezt külön írd bele.

2. Módosítás és továbbfejlesztés — akár más fejlesztővel

Mivel az átdolgozás joga csak kifejezett kikötéssel jár, a szerződésben külön szerepeljen, hogy a szoftvert módosíthatod, továbbfejlesztheted, és ezt harmadik féllel is elvégeztetheted. E nélkül előfordulhat, hogy minden későbbi változtatáshoz az eredeti fejlesztő kell — ami addig nem gond, amíg elérhető és elégedett vagy vele.

3. Saját keretrendszer és korábban írt modulok

Sok fejlesztő korábban megírt modulokból vagy saját keretrendszerből dolgozik. Ez gyorsítja a munkát, és teljesen rendben van — de ezeket a részeket jellemzően nem adja át kizárólagosan, hiszen más ügyfeleinél is használja. A szerződésben váljon külön, mi készült kifejezetten neked, és mi a fejlesztő meglévő eszköze. Utóbbira olyan felhasználási jogot kérj, amellyel a rendszert akkor is tovább tudod üzemeltetni és fejleszteni, ha már nem ő dolgozik rajta.

4. Nyílt forráskódú és külső komponensek

Ma szinte minden szoftver tartalmaz nyílt forráskódú könyvtárakat, és ezek felhasználását a saját licencük szabályozza, nem a fejlesztővel kötött szerződésed. Az Open Source Initiative által jóváhagyott licencek között vannak megengedők, például az MIT vagy az Apache-2.0, és vannak copyleft licencek, például a GPL-család, amelyek a továbbterjesztett, módosított változatoknál ugyanazoknak a szabadságoknak a továbbadását írják elő. Belső használatnál ez ritkán okoz gondot, de ha a szoftvert értékesítenéd vagy ügyfeleidnek terjesztenéd, sokat számít.

Kérj listát a felhasznált külső komponensekről és azok licencéről, a fizetős külső szolgáltatásoknál (térkép, SMS, e-mail-küldés, AI-szolgáltatás) pedig arról, kinek a nevén és milyen díjjal futnak.

Gyakorlat: hozzáférés, átvétel, kilépés

5. Forráskód: hozzáférés, átadás, letét

A jog önmagában kevés, ha nincs a kezedben az, amit jogod van használni. Tisztázd, megkapod-e a teljes forráskódot a verziókezelés előzményeivel együtt, és mikor: folyamatosan, mérföldkövenként vagy csak a végén. Ha a fejlesztő nem adja át a kódot — például mert a saját termékét licencelik neked —, szóba jöhet a forráskód-letét: a kódot független harmadik félnél helyezik el, és meghatározott esetekben, például a fejlesztő megszűnésekor hozzáférsz. Ilyenkor azt is rögzítsd, milyen gyakran frissül a letétbe helyezett változat.

6. Dokumentáció, build és élesítés

A forráskód akkor ér valamit, ha más is fel tudja építeni és el tudja indítani. Rögzítsd, milyen dokumentációt kapsz: felhasználói leírást, üzemeltetési leírást, az architektúra áttekintését, valamint a build- és élesítési folyamat leírását — milyen beállítások, titkos kulcsok és adatbázis-migrációk kellenek. Ha a rendszer más szoftverekhez kapcsolódik, a rendszerintegráció interfészeinek leírása is legyen az átadott anyag része. Jó próba: egy független fejlesztő a dokumentáció alapján el tudná-e indítani a rendszert egy üres környezetben?

A gyakorlati hozzáférésekről se feledkezz meg. A kódtár, a felhőelőfizetés, a domain, mobilalkalmazásnál az Apple és a Google fejlesztői fiókja, valamint a külső szolgáltatások ideális esetben a céged nevén vannak, a fejlesztő pedig meghívott hozzáféréssel dolgozik bennük. Az alkalmazásbolti fiókokról a mobilalkalmazás-fejlesztés kapcsán külön is érdemes egyeztetni, mert egy app utólagos átvitele külön eljárást igényel.

7. Átadás-átvétel és garanciális hibajavítás

Mikor kész a szoftver? Ezt nem érdemes érzésre bízni. A szerződésben szerepeljenek az átadás-átvételi kritériumok: milyen tesztforgatókönyveknek kell sikeresen lefutniuk, mennyi időd van a tesztelésre és a hibák jelzésére, hogyan osztályozzátok a hibákat (blokkoló, súlyos, kozmetikai), és melyik kategória akadályozza az átvételt. Rögzítsd azt is, meddig és milyen határidővel javítja a fejlesztő díjmentesen az átadott funkciók hibáit, és mi számít új igénynek, ami már külön megrendelés.

8. Kilépési terv

Senki nem úgy kezd egy együttműködést, hogy a végére gondol — a jó szerződés mégis ettől lesz teljes. Mi történik, ha a fejlesztő megszűnik, ha elégedetlen vagy, vagy ha saját csapatra váltanál? Érdemes rögzíteni:

• a teljes forráskód és dokumentáció átadását meghatározott határidőn belül;
• az adatok exportját szabványos, más rendszerbe betölthető formátumban;
• az átmeneti támogatást az új csapatnak (tudásátadás, kérdések), előre rögzített feltételekkel;
• a karbantartási szerződés felmondási idejét és a hozzáférések visszaadásának rendjét.

Gyors ellenőrzőlista aláírás előtt

Ha a szerződés már alá van írva

Nem késő. Nézd át, mit rögzít a szerződés, kérd ki a forráskódot és a hozzáféréseket, és ha valami hiányzik, kezdeményezz kiegészítést — ezt is érdemes ügyvéddel előkészíteni. Ha a rendszert másik fejlesztőnek adnád át, előbb egy technikai átvilágítás mutatja meg, mi van valójában a kezedben: milyen állapotban van a forráskód, mennyire teljes a dokumentáció, és hogyan néz ki az üzemeltetési környezet.

Hogyan kezeljük ezt mi?

A LORZ-nál a forráskódhoz való hozzáférést és a felhasználási jogokat az ajánlatban és a szerződésben előre, írásban rögzítjük, így nem az átadáskor derül ki, mit kapsz. Ha egy korábban fejlesztett saját modulunkat építjük be, azt külön jelezzük. Az átadás dokumentációval és betanítással történik, utána pedig igény szerint mi üzemeltetjük és fejlesztjük tovább a rendszert. Ha más fejlesztő által készített szoftver karbantartását vesszük át, előbb átvilágítjuk a forráskódot, a dokumentációt és az üzemeltetési környezetet, és erről írásos összefoglalót adunk.

A fejlesztőpartner kiválasztásához a Szoftverfejlesztő cég választása: 12 kérdés, mielőtt aláírsz cikkünk ad szempontokat, a teljes munkamenetünket pedig az egyedi szoftverfejlesztés oldalon mutatjuk be. Kérdésed van a saját helyzeteddel kapcsolatban? Írj nekünk — a technikai oldalát szívesen átnézzük, a jogit ügyvéddel érdemes.