Agilitás a szoftverfejlesztési szerződésekben

Valljuk be, jó szoftverfejlesztési szerződést nehéz írni. Még akkor is, ha egy jogilag könnyen értelmezhető, részletes specifikáción alapuló, vízesés modellben dolgozik a fejlesztőcsapat. Agilis módszertan alkalmazásával megvalósuló fejlesztési projekt szerződésbe foglalása azonban valóban embert próbáló feladat. 

A probléma (eleje)

Láttam persze erre is újszerű megközelítéseket, így többek között volt szerencsém egy teljes scrum módszertani útmutatót végigolvasni egy ilyen szerződésben, míg mások nemes egyszerűséggel kikerülik az agilitás problémáját és a szerzői jogok átruházását nemes egyszerűséggel két mondattal lerendezik. Teszem hozzá, a két mondat közül az egyik nagyon sokszor az, hogy „a szoftver a megrendelő tulajdona”. No persze. Szoftver esetében tulajdonjogot nem lehet szerezni, ez egész egyszerűen fogalmilag kizárt. Esetleg a műpéldány átadásával a műpéldány tulajdonjogát lehet megszerezni, de ez a szoftverjogi szerződések kapcsán valljuk be, egyre ritkább. Egy szoftverhez, mint szerzői műhöz szerzői jogok kapcsolódnak: ezek 

• a személyhez fűződő jogok, valamint 
• a vagyoni jogok. 

Kis kitérő a probléma megértéséhez vezető úton

A személyhez fűződő jogok a mű nyilvánosságra hozatalához való jog, a mű egységének védelme és a név feltüntetéséhez való jog. A személyhez fűződő jogokat nem lehet átruházni. Szintén érdekes ebben a körben, hogy a szerzői jog azt illeti, aki a művet megalkotta: ez pedig minden esetben kizárólag természetes személy lehet. Abban az esetben, ha egy céget (például kft.-t) bízunk meg egy szoftver lefejlesztésével, a munkáltató cég a szerzői jogi törvény (Szjt.) rendelkezései szerint mint jogutód megszerzi a szoftver vagyoni jogait, így a cég jogszerűen rendelkezhet a vagyoni jogokkal.

A szoftverre vonatkozó vagyoni jogokat tudja minden esetben a megrendelő megszerezni. Ilyen vagyoni jogok többek felhasználás, harmadik személy részére felhasználási jog engedése, többszörözés, másolás, terjesztés, és még sorolhatnám. A vagyoni jogok megszerzésének két módja van szoftver esetében: felhasználási jog átengedése (valamilyen terjedelemben) vagy a vagyoni jogok átruházása. 

A (fő) probléma

És ennél a pontnál - nem rövid bevezető után - vissza is kanyarodhatunk az agilitás problémakörére: a felhasználási szerződés alapján a szerző (jelen esetben nevezzük egyszerűen „a fejlesztő”-nek) engedélyt ad a felhasználónak (értsd: „megrendelő”) a művének a felhasználására. De hol a mű? Mikortól nevezzük műnek? És ha ez egy jövőben megalkotandó műre vonatkozó szerződés, mikor lesz „kész” a mű, amit át lehet adni? És itt van az igazi probléma az agilis fejlesztésekkel – természetesen kizárólag jogi szempontból. A mű ugyanis ebben az esetben kvázi soha nem készül el, sőt, jellemzően specifikáció sem készül, amibe kapaszkodni tudnánk.

A megoldás?

A probléma tehát két területet érint:

1. az Szjt. szerint az elkészült mű elfogadásáról a felhasználó szoftver esetén négy hónapon belül nyilatkozik;
2. a felhasználáshoz kell egy „mű”, amelyre a felhasználás vonatkozik.

Agilis (scrum) módszertan esetén jellemzően sprintekben történik a fejlesztés és az átadás is, azonban egy sprint keretében nem feltétlen készül el olyan szinten a szoftver, hogy azt már műként lehetne értelmezni.  Lényegében tehát itt is az a kérdés, mint a következőnél: mikor határozzuk meg a kész jogi (!) fogalmát, amely természetesen nem ugyanaz, mint a kész agilis/scrum módszerbeli fogalma.

Ennek feloldása érdekében azt szoktam elsősorban javasolni, hogy már a szerződés előtt, bár nincs részletes követelmény-specifikáció, legyen legalább egy „megrendelői igény- vagy feladatleírás”, amelyben legalább fő funkcióiban meghatározzuk, hogy mi a megrendelő elvárása. Modernebb kifejezéssel, mi lesz az MVP, amire azt tudja mondani a megrendelő, hogy oké, akkor innentől elindul a buli, élesítjük a rendszert. Miért fontos ez? Mert ebben az időpontban fogunk – jogilag – csinálni egy átadást (akár konkrét UAT-t, én szoktam javasolni), amely időponttól kezdve a felhasználási jogokat már a megrendelő (felhasználó) gyakorolja, ebben az időpontban szerzi meg a jogokat, itt mondjuk azt (tényleg csak jogilag), hogy készen van a szoftver, tessék, itt a forráskód, itt a dokumentáció, indulhatunk. A felhasználásnak természetesen ellenértéke van, amely a felhasználási díj, amely miatt még havi díjas elszámolásban is javasolni szoktam, minden, a késznek tekintett mű kapcsán felmerült, de még ki nem fizetett óradíjat (= felhasználási díjat) a forráskód átadását megelőzően legyen kiszámlázva és kifizetve, még akkor is, ha egyébként nem lenne számlázási „idő” (pl. havi elszámolás esetén), hogy a felhasználást jogszerűen meg tudja kezdeni a megrendelő.

Innentől tehát van egy felhasználási joga a megrendelőnek, a fejlesztő pedig – ahogy az agilisnál lenni szokott – folytathatja a munkát, amely egészen pontosan a szoftver továbbfejlesztése, amely során származékos mű keletkezik, a felhasználási jogok pedig éppúgy átszállnak majd a felhasználóra – legalábbis, ha a szerződésben rendelkezünk erről.

+1 A garancia, bugok javítása

Nem kizárólag az agilis fejlesztéseknél, hanem általában kérdés a garancia, bugok javításának helyes kezelése szerződési szempontból. A főszabály az, hogy minden ilyen megrendelésre készült műre az Szjt. felhasználási szerződésekre irányadó passzusai az irányadóak, nem pedig a Ptk. szabályai. Sajnos sok olyan fejlesztési szerződést láttam, amelyben a Ptk. szabályait keverik bele az átadási és hibajavítási folyamatokban – amit persze lehet, azonban akkor érdemes az Szjt. szabályainak alkalmazását kizárni, hiszen a Ptk.-hoz csak akkor nyúlunk szerzői műveknél, ha és amennyiben az Szjt. nem rendezi a kérdést. 

Nézzük tehát a bugok javítását. Amennyiben a szerződés jövőben megalkotandó műről rendelkezik (azaz a megrendelőnek van egy elképzelése, milyen szoftvert szeretne, a fejlesztő pedig előállítja neki), a mű elfogadásáról 4 hónapon belül nyilatkozhat a felhasználó. Ezalatt a négy hónap alatt jogosult visszaadni hibajavításra a kész művet, aki pedig köteles a hibákat javítani – amennyiben ezt nem teszi meg, vagy a javítás után sem működőképes a szoftver, csupán mérsékelt díjazásra jogosult. Ettől el lehet térni. Én személy szerint el is szoktam, főleg, mivel jellemzően havi számlázás van agilis fejlesztéseknél, így a mérsékelt díjazás nem feltétlen értelmezhető. Mégis foglalkozni kell a kérdéssel, hogy egy meghatározott időtartamon belül előjövő hibák javítása a fejlesztő feladata – és ezért főszabály szerint nem szokás ellenértéket kérni. Az időszakot természetesen növelhetjük és csökkenthetjük, ha akarjuk, akár a garanciát is használhatjuk ehelyett – a legtöbb általam véleményezett „garanciás” szerződésben azonban az Szjt. vonatkozó rendelkezései nem kerültek kizárásra. Sőt, itt kiemelt figyelmet kell fordítani nem csupán a hibajavításra, mint fogalomra, hanem arra is, hogy mi nem hiba, így például nem tekinthetjük hibának, ha az elfogadott tervhez képest 5 pixellel jobbra szeretné látni a megrendelő a CTA gombot. Szintén nem hiba, ha az üzemeltetést nem a fejlesztő végzi és a szerverrel akadnak problémák. (Mondjuk az üzemeltetési szerződés egyébként is egy teljesen önálló szerződés, de legalább ilyen szinten érdemes foglalkozni vele egy fejlesztési szerződésben is). Kinek a hibája, ha vírusos a szoftver?

Szintén fontos kitérni a szerződésben arra, hogy egy számla megfizetése bár a felhasználási díj megfizetését is jelenti, nem jelenti feltétlenül azt, hogy az Szjt. szerinti előírásoknak megfelelően elfogadta az elkészült művet (azaz teljesítést) a felhasználó.

Ha Ptk. szerinti jótállást szeretnénk a szerződésben („mert az ügyfél ezt ismeri” – szokott hangzani az indok), ott szintén nagyon kell figyelni a fentiekre és a jótállás Szjt.-hez igazítására.

Természetesen még számos kérdés és probléma merülhet fel egy agilis fejlesztés szerződésének megírása kapcsán, hiszen nem ejtettünk még szót olyan apróságokról, mint harmadik fél szoftverének beépítése, open source szoftver(rész) beépítése, közös mű létrehozása, kódok és felhasználói fiókok átadása...de kell maradjon téma a következő cikkekhez is.