Tarkvaraarendusleping: täielik juhend + tasuta mall

Enamik tarkvaraprojekte ebaõnnestub mitte sellepärast, et arendajad oleksid halvad kodeerijad. Need ebaõnnestuvad, sest keegi ei kirjutanud alla, mida tähendab "valmis". Standish Groupi CHAOS raport seab tarkvaraprojektide edukuse määraks vaid 31% — ja ulatuse eriarvamused, ebaselged IP õigused ning vaidlustatud maksetingimused on kõige levinumad süüdlased.

Tarkvaraarendusleping lahendab kõik selle enne töö algust. See on leping kliendi ja arendaja (või agentuuri) vahel, mis määrab ära, mida ehitatakse, kes selle omab, kui palju see maksab ja mis juhtub, kui asi läheb valesti. Ilma selleta looted heale usule ja mälule — kohtud ei aktsepteeri kumbagi.

See juhend kata kõik: millal vajad tarkvaraarenduslepingut, neli lepingutüüpi ja millal igaüht kasutada, iga klausel, mis tegelikult loeb, ning tasuta allalaaditav mall, mida saad oma projekti jaoks kohandada. Kui tead juba põhitõdesid ja tahad otse malli juurde minna, liigu edasi malli sektsiooni. Muul juhul on kontekst oluline — eriti IP sektsioon, kus enamik lepinguid vaikselt ebaõnnestub. Laiema vaate jaoks, kuidas kokkulepped lepingutest erinevad, kata meie juhend lepingute vs kokkulepete kohta õiguslikud erinevused, mida on väärt teada.

Tarkvaraarendusleping (SDA) on õiguslikult siduv leping kliendi ja tarkvaraarendaja või arendusettevõtte vahel. See määrab ära töö ulatuse, maksestruktuuri, tarnetähtaja, intellektuaalomandi omandisuhte, konfidentsiaalsustingimused ja mis juhtub, kui üks pooltest soovib suhet lõpetada.

SDA ei ole pakkumus, projektiülevaade ega Slacki vestlus, mis töö kinnitab. See on ametlik õiguslik dokument, millesse mõlemad pooled nõustusid enne arenduse algust. Kui see on allkirjastatud, on see dokument, millele viidatakse vaidluse korral — ja mida kohus loeb, kui asi sinna jõuab.

Mida SDA kata

Korrektselt koostatud tarkvaraarendusleping käsitleb:

• Töö ulatust — mida arendaja ehitab, piisava täpsusega, et kolmas osapool saaks täitmise hinnata
• Tulemusi ja verstaposte — mida tarnitakse, mis kujul ja millal
• Maksetingimusi — kogutasu, maksegraafik ja mis iga makse käivitab
• IP omandit — kes koodi pärast selle kirjutamist omab
• Konfidentsiaalsust — millist ärisaladust informatsiooni iga pool peab privaatsena hoidma
• Vastuvõtutestimist — kuidas klient hinnab, kas tarnitud tarkvara vastab nõuetele
• Garantiisid — mida arendaja tarkvara funktsionaalsuse kohta garanteerib
• Lõpetamistingimusi — kuidas kumbki pool saab lepingu lõpetada ja mis juhtub juba tehtud tööga

Mõned kliendid ajavad SDA segamini tööülesannete dokumendiga (SOW). Nende vahel on kattuvusi, kuid need pole samad asjad — ja see erinevus loeb. MSA ja SOW suhe selgitab, kuidas need dokumendid pikemates koostöödes koos töötavad.

Lühike vastus: alati, kui maksad kellelegi tarkvara ehitamise eest või saad selle eest tasu.

Leping on oluline nii siis, kui palkad vabakutselise kahenädalaseks projektiks kui ka 20-inimeselise agentuuriga 12-kuuliseks tootearenduseks. Mõõtkava muutub; kirjalike tingimuste vajadus mitte.

Tarkvaraarenduslepingut vajad, kui:

• Välisedad tarkvaraarendust — eriti välismaiste või kaugmeeskondade puhul, kus jurisdiktsiooni erinevused muudavad suulised kokkulepped keeruliseks
• Ehitatakse kohandatud tarkvara — mida spetsiifilisem töö, seda rohkem vajab IP omandi selget dokumenteerimist
• On mitu arendusfaasi — verstapostipõhised maksed nõuavad kirjalikke vastuvõtukriteeriume iga faasi käivitamiseks
• Puudutatakse tundlikke andmeid või süsteeme — iga projekt, mis puudutab kliendiandmeid, vajab konfidentsiaalsus- ja turvaklausleid
• Ehitatakse proprietäärraamistike peale — olemasolev kood, mis lisatakse kohandatud tarnistesse, tekitab segadust omandi küsimustes ilma selge lepinguta
• Tööd tehakse piiriüliselt — kui arendaja ja klient on eri riikides, tuleb nimetada kehtiv õigus ja jurisdiktsioon

Ainus olukord, kus võid ilma täis SDA-ta hakkama saada: väga lühike, madala väärtusega töö, mida reguleerib põhjalik master service agreement, mis juba kata kõik asjakohased tingimused. Kuid isegi siis ütleksid enamik juriste, et tee paberitöö ära.

Ei ole olemas ühtegi SDA malli, mis sobib igale koostööle. Lepingustruktuur peab vastama projekti hinnastamise ja ulatuse määramise viisile — ja vale struktuuri valik loob stiimuleid, mis töötavad heade tulemuste vastu.

Fikseeritud hinnaga lepingud

Fikseeritud hinnaga SDA töötab, kui projekti nõuded on stabiilsed ja enne arenduse algust hästi mõistetavad. Arendaja kohustub tarnima määratletud ulatuse kokku lepitud kogutasu eest. Kulude kindlus on kliendi jaoks peamine eelis. Risk: kui nõuded osutuvad alamääratletuks, neelab arendaja ületamise või algavad vaidlused.

Aja ja materjalide lepingud

T&M lepingud mõtlevad uurivale tööle, varajase staadiumi toodetele või igale olukorrale, kus kogu ulatust ei saa ette määratleda. Klient maksab tegelike töötundide eest kokku lepitud tunnitasude alusel. Saad paindlikkust; kompromiss on kulude ebakindlus. Eelarvelimiidid ja igakuised ülempiiri aitavad seda riski hallata.

Pühendunud meeskonna lepingud

Ettevõtetele, kes vajavad pidevat kauginseneride meeskonda — mitte ühekordset projektitarne — seab pühendunud meeskonna leping pikaajalise suhte tingimused. IT-firmade lepingute haldus hõlmab tavaliselt seda mudelit väliste partneritega töötamisel.

MSA + SOW struktuur

Suuremad koostööd eraldavad sageli põhilise õigusliku raamistiku (MSA) projektispetsiifilistest tingimustest (SOW). MSA kata IP, konfidentsiaalsuse, vastutuse ja vaidluste lahendamise üks kord; iga SOW kata konkreetse projekti tarned, tähtaja ja makse.

Mitte kõik klauslid pole võrdse kaaluga. Need on need, kus puuduv või udune keel tekitab reaalseid vaidlusi.

1. Töö ulatus ja tulemused

Kirjelda, mida ehitatakse, piisava detailsusega, et keegi, kes projektis osalenud pole, saaks hinnata, kas see tarniti. Funktsionaalsed nõuded, tehnilised spetsifikatsioonid, toetatud platvormid ja jõudluse võrdlusnäitajad kuuluvad siia. Nimetage selgelt, mis on ulatusest väljas.

Udune ulatus on üksik levinuim tarkvaravaidluste allikas. "Ehita veebisait" pole ulatus. "Ehita responsiivne React/Next.js rakendus, millel on Lisa A-s loetletud funktsioonid, saavutades Lighthouse jõudlusskoori 90+ mobiilis" on ulatus.

2. Maksetingimused ja verstapostigraafik

Loetle iga makse: summa, käivitussündmus ja makseviis. Verstapostipõhised maksed peaksid olema seotud vastuvõetud tulemustega, mitte ainult kalendripäevadega. Määra valuuta, maksetähtaeg (Net-15 või Net-30 on standard) ja viivise tasu.

3. Intellektuaalomandi omand

See on klausel, mille enamik kliente liiga kiiresti loeb. Kes omab kohandatud koodi? Kes omab olemasolevat koodi, mille arendaja lisab? Kas avatud lähtekoodiga tarkvara on kaetud? SDA IP sektsioon määrab, kes saab tarkvara pärast tarnimist kasutada, muuta, müüa või litsentsida. Kui see valesti läheb, on tagajärjed kallid — vaata Cadence v. Avanti juhtumit allpool IP sektsioonis.

4. Konfidentsiaalsus

SDA peaks sisaldama vastastikuseid konfidentsiaalsuskohustusi. Arendaja ei tohi avaldada kliendi andmeid ega proprietäärbusinessloogikat; klient ei tohi avaldada arendaja proprietääprotsesse või tööriistu. Tugevamate NDA tingimuste jaoks eraldiseisvas lepingus tasub seda lugeda koos meie töövõtja NDA juhendiga tarkvaraettevõtetele.

5. Vastuvõtutestimine

Määra, kuidas klient iga tulemust üle vaatab ja vastu võtab. Ülevaateaken (5–10 tööpäeva on tavaline), tagasisidevorming, läbimise kriteeriumid ja mis juhtub, kui klient ei vasta ülevaateakna jooksul (loetakse vastuvõetuks).

6. Garantiid

Arendaja peaks garanteerima, et tarkvara töötab nii nagu spetsifitseeritud, et kood on originaalne (või korralikult litsentsitud) ja et tarne ei riku kolmandate osapoolte IP õigusi. Garantiaperiood pärast tarnimist vigade parandamiseks — tavaliselt 30–90 päeva — kaitseb klienti pärast käivitamist avastatud defektide eest.

7. Lõpetamistingimused

Mõlemal poolel peaks olema võimalus mõistliku etteteatamisega väljuda. Määra etteteatamisaeg (30 päeva on standard), mis juhtub poolelioleva tööga ja kuidas arvutatakse lõpetamise korral lõplik makse. Lõpetamine põhjusel klausel (hõlmates olulist rikkumist, pankroti või maksmata jätmist) peaks olema eraldi mugavusest lõpetamisest.

8. Kehtiv õigus ja jurisdiktsioon

Nimeta riik ja osariik/piirkond, mille õigus lepingut reguleerib. Kui arendaja ja klient on eri riikides, otsustab see klausel, millised kohtud vaidlust menetleksid. Ära jäta seda välja, sest see tundub formaalne — see on üks praktiliselt olulisemaid klausleid piiriüleses koostöös.

Kasuta seda malli oma lepingu alusena. Asenda kõik sulgudes väljad oma konkreetsete tingimustega. Keerukate projektide puhul palu tarkvarajuristil lõplik versioon üle vaadata — eriti IP ja garantii sektsioonid.

IT-firmadele, kes hallatavad lepinguid mitme arenduspartneriga, kõigi SDA-de tsentraliseerimine ühte dokumendihaldussüsteemi — versiooniajaloo ja võltsimiskindlate allkirjadega — eemaldab Wordi dokumentide edasi-tagasi saatmise kaose.

Ülaloleval mallil on rohkem kui tosin välja, mis tuleb täita. Siin on, kuidas igaühele läheneda, ilma et jätaksid lünki, mis hiljem vaidlusi tekitavad.

Samm 1: Määra ulatus enne lepingu puudutamist

Ära ava malli, enne kui oled dokumenteerinud, mida tarkvara tegelikult tegema peab. Funktsionaalsed nõuded, tehnilised piirangud, toetatud platvormid, integratsioonisõltuvused — kõik see. SDA ulatuse sektsioon on ainult nii hea, kui spetsifikatsioonidokument selle taga.

Keerukate projektide puhul lisa täisspetsifikatsioon Lisa A-na ja viita sellele ulatuse klauslist. See hoiab peamise lepingu loetavana, samal ajal tagades, et kogu tehniline detail on õiguslikult manustatud.

Samm 2: Koosta verstapostigraafik

Tööta tagasi tarnetähtajast. Jaga projekt faasideks — avastus, disain, arendus, testimine, juurutamine — ja määra igale summa ja tähtaeg. Faasimaksed peaksid ligikaudu vastama igas etapis tarnitud väärtusele.

Õiglane hoiatus: see võtab kauem aega, kui enamik osapooli ootab, eriti esimestel koostöödel. Arvesta 1–2 tundi mõlema poole kohalolekuga, et verstapostid ja maksed õigeks saada.

Samm 3: Käsitle IP omandit selgelt

Loe Sektsiooni 3 hoolikalt ja täida kõik tühjad väljad. Kui arendaja kasutab proprietäärraamistikke või tööriistu, mille ta enne seda projekti ehitas, loetle need olemasoleva töö erandis. Kui kasutad avatud lähtekoodi teeke, nimeta litsentsid.

Kohandatud töö üleandmine (Sektsioon 3.1) on tavaliselt kliendi jaoks kõige olulisem klausel: see on see, mis kannab tarnitud koodi omandi arendajalt sinule üle. Ära jäta seda uduseks.

Samm 4: Sea ülevaateaken ja kriteeriumid

Otsusta ülevaateaken ära, enne kui sa selle täidad. Kümme tööpäeva on tavaline. Kaks nädalat annab hõivatud klientidele piisavalt aega tulemust tegelikult testida; lühem aeg tekitab tavaliselt vaidlusi, kui ülevaatajad on reisil või muul viisil hõivatud.

Sektsiooni 5 jaoks kuuluvad vastuvõtukriteeriumid Lisa A-sse. Kirjuta spetsiifilised, testitavad kriteeriumid: "Mobiilirakendus laadib armatuurlaua alla 3 sekundiga 4G ühendusel" on parem kui "rakendus peaks olema kiire."

Samm 5: Vali teadlikult kehtiv õigus

Siseriiklike projektide puhul kasuta arendaja koduosariigi/riigi õigust (nemad on kohalike kohtutega tuttavamad). Piiriüleste projektide puhul võib kumbki pool eelistada neutraalset jurisdiktsiooni. Delaware'i õigus on levinud USA-põhiste tehnoloogialepingute puhul; Inglise õigust kasutatakse sageli rahvusvaheliste tehnoloogialepingute puhul. Mida iganes valid, peavad mõlemad pooled selgesõnaliselt nõustuma — ära jäta seda tühjaks.

Samm 6: Allkirjasta vastavusega e-allkirjaga

Käsitööallkirja skaneeritud pilt PDF-il on enamikus jurisdiktsioonides õiguslikult nõrk. Elektroonilised allkirjad, mis genereerivad dokumendi räsi ja ajatembliga lõpetamistunnistuse, on palju raskemini tagasi lükatavad. Ameerika Ühendriikides ESIGN Act ja UETA alusel ning Euroopa Liidus eIDAS alusel omavad elektroonilised allkirjad täitmisele pööratavat jõudu ärilepingute jaoks. Allkirjastusplatvorm peaks siduma iga allkirja dokumendi krüptograafilise räsiga — nii et igasugune pärast-allkirjastamist muutmine on kohe tuvastatav.

Enamik mallid kata põhitõed. Need on klauslid, mis jäävad odavatest või kiirustades koostatud lepingutest välja — ja mis kipuvad kõige rohkem loema, kui midagi valesti läheb.

Vastuvõtutestimine läbimise/ebaläbimise kriteeriumidega

Sektsioon 5 ülalolevas mallis määrab ära, *millal* ja *kuidas* klient tulemusi üle vaatab. Mida enamik lepinguid vahele jätab: tegelikud läbimise kriteeriumid. Ilma mõõdetavate läbimise/ebaläbimise võrdlusnäitajateta muutub vastuvõtt läbirääkimiseks. Klient võib alati väita, et tarkvara pole "piisavalt hea." Kirjuta objektiivsed kriteeriumid Lisa A-sse enne arenduse algust.

Lähtekoodi deposiit

Kui sinu äri sõltub kohandatud tarkvarast ja arendaja lõpetab tegevuse, vajad lähtekoodile juurdepääsu. Lähtekoodi deposiidi klausel nõuab, et arendaja paigutaks lähtekoodi neutraalse deposiidiagendi juurde. Kui arendaja lõpetab tegevuse või rikub lepingut oluliselt, vabastab deposiit koodi kliendile. Enamik kliente ei mõtle seda kunagi küsida — kuni nad seda vajavad.

Pärast-tarnet vastutuse periood

Sektsioon 7 piirab koguvastutust, kuid paljud mallid ei käsitle ajalist akent. Millal vastutus lõpeb? Kui defekt tekitab andmekao 18 kuud pärast tarnimist, kas arendaja on ikka vastutav? Määra selgelt garantiiaeg ja pärast-garantiilist vastutuse aken. Pärast garantiiaega on arendaja kohustus tavaliselt ainult parandada defekte, mille ta ise tekitas — mitte vead, mille kliendi muudatused sisse tõid.

Muudatuste kontrolli protsess

Sektsioon 9 nõuab allkirjastatud muudatustellimust (Change Order) ulatuse muudatuste jaoks. Mida enamik lepinguid vahele jätab: määratleda, kellel on õigus muudatustellimusi allkirjastada. Kui kliendi projektijuht palub suuliselt uue funktsiooni ja arendaja ehitab selle, kas arendajale on makse võlgnetav? Ainult siis, kui muudatustellimuse protsessi järgidi. Nimeta spetsiifilised rollid (mitte isikud, kelle tiitlid muutuvad), kellel on õigus muudatusi heaks kiita.

Avatud lähtekoodi litsentsi vastavus

Linux Foundation teatab, et 92% äritarkvarast sisaldab avatud lähtekoodi komponente. Iga komponendi litsents seab tingimused, kuidas tarkvara võib kasutada, muuta ja levitada. Näiteks GPL-litsentsiga teek võib käivitada copyleft kohustused, mis sunnivad sind oma proprietäärkoodi avama. SDA peaks nõudma, et arendaja avaldaks kõik avatud lähtekoodi komponendid ja kinnitaks nende ühilduvuse kliendi kavandatud kasutusega.

IP omand on klausel, mille enamik kliente kiiresti üle libiseb — ja see on see, kus valesti minemise tagajärjed on suurimad.

Cadence v. Avanti juhtum: 265 miljoni dollari õppetund

1. 2002.
   aastal leidis California kohus, et Avanti Corporation oli kasutanud varastatud Cadence lähtekoodi konkureerivas tootes. Kahjutasu ulatus 265 miljoni dollarini. Juhtumit viidatakse sageli tarkvara IP vaidlustes, sest see illustreerib, mis juhtub, kui lähtekoodi omand vaidlustatakse või, mis veel hullem, kui kood, mida tootesse kunagi lisama ei pidanud, seal lõpuks ikkagi on. Hästi koostatud IP klausel ei määra ainult seda, kes lõpptulemit omab — see nõuab, et arendaja garanteeriks, et ühtegi kolmanda osapoole IP-d pole ebaseaduslikult lisatud.

Nelja IP mudel

Olemasolev vs kohandatud töö

Enamik arendajaid toob kaasa tööriistad, raamistiku ja teegid, mille nad ehitasid enne sinu projekti algust. Need on "olemasolevad tööd" või "taust-IP." SDA peaks selgelt tuvastama, millist olemasolevat tööd lisatakse, andma kliendile litsentsi seda tarnitud tarkvara osana kasutada — ilma nende alusolevate tööriistade omandit üle andmata.

Sügavama vaate jaoks, kuidas IP üleandmine töötab individuaalsetes arendajalepingutes, kata IP üleandmise leping arendajatele juhend koodi omandi üleandmise ja litsentsimise mehhanisme.

Tööpalga doktriin

Ameerika Ühendriikides on töötaja poolt tööülesannete raames kirjutatud kood automaatselt tööpalga teos, mille omandab tööandja. Sõltumatu töövõtja poolt kirjutatud kood *ei ole* automaatselt tööpalga teos — töövõtja säilitab autoriõiguse, kui leping seda selgesõnaliselt ei ütle üle. See erinevus komistab kliente üles, kes arvavad, et nad omavad koodi, sest nad selle eest maksid. Nad ei oma, ilma üleandmise klauslita.

Neid kolme dokumenti aetakse pidevalt segamini. Igal on erinev roll ja vale dokumendi kasutamine — või nende segamine — tekitab vastutuse lünki.

Ühekordsete projektide puhul kata iseseisev SDA (nagu selles juhendis olev mall) kõik. Pidevate koostööde puhul arenduspartneriga — kus aja jooksul käitatakse mitmeid projekte — on MSA + SOW struktuur efektiivsem. MSA läbiräägib õigusliku raamistiku üks kord; iga projekt lisab uue SOW. Meie täielik juhend tööülesannete dokumentide kohta kata SOW struktuuri detailselt.

Allkirjastatud SDA saamine tähendas varem printimist, skaneerimist, e-kirjade saatmist ja lootust, et teise poole versioon sinuga klapib. Selleks pole enam head põhjendust.

Mis teeb elektroonilise allkirja õiguslikult kehtivaks

ESIGN Act (USA) ja eIDAS (EL) alusel on elektrooniline allkiri ärilepingute jaoks õiguslikult kehtiv, kui see:

• On rakendatud kellegi poolt, kellel on kavatsus allkirjastada
• On seotud konkreetse allkirjastatava dokumendiga
• On võimeline viitama allkirjastajale
• Kirje on salvestatud vormis, mida saab hiljem taastada

Krüptograafilised allkirjad lähevad kaugemale: iga allkiri on matemaatiliselt seotud dokumendi räsiga. Muuda ükski tähemärk pärast allkirjastamist ja räsi muutub, tehes võltsimise kohe tuvastatavaks. See tagasilükkamatuse omadus teeb lepingu kohtus kaitsmiseks — ükski pool ei saa hiljem väita, et dokumenti muudeti.

Kuidas allkirjastamise töövoog töötab

IT-firmade dokumendihaldus haldab tavaliselt mitut SDA-d, SOW-i ja NDA-d samaaegselt. Spetsiaalselt loodud töövoog väldib e-kirjapõhise allkirjastamise versioonikontrolli õudustunnet:

1. 1.
   Lae lõplik SDA lepinguhaldusplatvormile
2. 2.
   Lisa iga allkirjastaja e-posti aadress ja allkirjastamise järjekord
3. 3.
   Iga pool saab turvalise allkirjastamise lingi — allkirjastamiseks pole kontot vaja
4. 4.
   Allkirjad rakendatakse; platvorm genereerib lõpetamistunnistuse ajatemplite, IP aadresside ja dokumendi räsigaa
5. 5.
   Mõlemad pooled saavad automaatselt täielikult täidetud dokumendi
6. 6.
   Auditeerimisjälg on muutumatult salvestatud, juurdepääsetav tulevikuks või vaidluste lahendamiseks

Verstapostimaksed, mis on seotud allkirjastamisega

Kõige kasulikum omadus kaasaegses lepinguplatvormis pole mitte allkiri ise — see on allkirja sidumine sellega, mis järgmiseks juhtub. Kui arendaja tarnib verstaposti ja klient allkirjastab vastuvõtuvormi, käivitub makse käivitaja automaatselt. Pole käsitsi arvete tagaajamist, pole "ma arvasin, et sa saadad arve eraldi" segadust. Meeskondadele, kes hallatavad lepinguga seotud makseid, see eemaldab vastuvõtu ja arvelduse vahelise lünki.

Täieliku lepinguhaldusplaanide hinnakirja jaoks kata Chaindoc'i hinnaleht, mis sisaldub igal tasemel.