Ce clauze trebuie să conțină un contract software sau SaaS? Ghid juridic complet pentru firmele IT din România care dezvoltă sau achiziționează software la comandă, aplicații SaaS sau servicii cloud. Proprietate intelectuală, SLA, GDPR și limitarea răspunderii — explicate de avocați specializați.
De ce contractele IT sunt diferite față de contractele clasice de prestări servicii
Multe firme IT operează ani de zile cu contracte-tip descărcate de pe internet sau adaptate după modele din alte domenii. Această abordare funcționează… până când nu mai funcționează. Un contract de dezvoltare software implică particularități juridice unice pe care un contract de prestări servicii generic nu le acoperă:
- Produsul livrat este imaterial — nu poți „returna” software-ul sau verifica defectele cu ochiul liber
- Drepturile de proprietate intelectuală asupra codului nu se transferă automat la client, indiferent cine plătește
- Criteriile de acceptanță sunt adesea subiective dacă nu sunt definite explicit în contract
- Răspunderea pentru bug-uri poate fi nelimitată dacă nu există o clauză de limitare a daunelor
- GDPR se aplică dacă aplicația procesează date personale — iar obligațiile trebuie distribuite contractual
Cele 8 clauze esențiale ale unui contract de dezvoltare software
1. Obiectul contractului (Specificațiile tehnice)
Descrierea precisă a produsului: funcționalități, tehnologii folosite, platforme vizate. Ambiguitatea costă. Anexele tehnice sunt parte din contract.
2. Proprietatea intelectuală și cesiunea drepturilor
Cine deține codul sursă după finalizare? Dacă nu este stipulat explicit, drepturile rămân la dezvoltator conform Legii nr. 8/1996.
3. Criterii de acceptanță (Acceptance Testing)
Cum se definește că produsul este „finalizat”? Fără criterii clare, orice bug minor poate bloca recepția și plata.
4. Termene și jaloane (Milestones)
Livrările parțiale, termenele intermediare și consecințele întârzierilor — inclusiv dreptul clientului de a rezilia sau penalitățile aplicabile.
5. Limitarea răspunderii
Plafonarea daunelor la valoarea contractului sau la o sumă fixă. Fără această clauză, un bug critic poate genera daune nelimitate.
6. Garanție și mentenanță post-livrare
Perioada de garanție pentru defecte (obișnuit 3–12 luni), ce acoperă și ce nu acoperă, și tariful pentru mentenanță ulterioară.
7. Confidențialitate și NDA
Protecția know-how-ului clientului, a codului sursă și a datelor de business pe durata și după contract. Clauze de non-solicitare a angajaților.
8. GDPR – Acord de procesare a datelor (DPA)
Dacă aplicația procesează date personale, contractul trebuie să conțină sau să fie însoțit de un DPA conform Art. 28 GDPR.
Cel mai frecvent litigiu IT pe care îl vedem: clientul a plătit integral dezvoltarea unui software, dar firma de dezvoltare a rămas proprietara codului sursă — deoarece contractul nu conținea o clauză de cesiune a drepturilor patrimoniale de autor. Conform Legii nr. 8/1996, drepturile aparțin autorului (programatorului/firmei de dev) dacă nu există o prevedere contractuală contrară expresă.
Proprietatea intelectuală în software: ce spune legea română
Acesta este cel mai sensibil aspect juridic al oricărui contract de software și, din păcate, cel mai adesea ignorat.
Regula generală (Legea nr. 8/1996, art. 75): programele de calculator create de un angajat în exercitarea atribuțiilor de serviciu aparțin angajatorului. Dar aceasta se aplică relației angajat–angajator.
Relația B2B (firmă client – firmă de dezvoltare): nu există o prezumție legală că drepturile se transferă automat la cel care plătește. Drepturile patrimoniale de autor aparțin firmei de dezvoltare dacă contractul nu prevede altfel.
Un contract corect trebuie să conțină o clauză de tipul:
„Prestatorul cesionează Beneficiarului, cu titlu exclusiv și cu drept de transmitere ulterioară, toate drepturile patrimoniale de autor asupra produsului software, inclusiv dreptul de reproducere, distribuire, modificare și adaptare, cesiunea operând de drept la momentul recepției finale și achitării integrale a prețului contractual.”
Atenție: chiar și cu această clauză, trebuie să clarificați regimul componentelor open source folosite în produs, al librăriilor terțe și al codului reutilizabil (boilerplate) pe care dezvoltatorul îl folosește în mai multe proiecte.
Contractele SaaS: specificul juridic față de software-ul clasic
Modelul SaaS ridică provocări juridice distincte față de software-ul livrat clasic. Clientul nu primește nicio copie a produsului — el accesează serviciul. Aceasta înseamnă că:
| Aspect juridic | Software livrat (licență) | SaaS (abonament) |
|---|---|---|
| Ce primește clientul | Copie instalabilă + drept de utilizare | Acces la serviciu, fără copie |
| Proprietatea datelor | Date stocate local – risc mai mic | Date pe serverele furnizorului – clauze esențiale |
| Continuitate serviciu | Nu depinde de furnizor după livrare | Total dependentă de furnizor – SLA critic |
| GDPR | Depinde de funcționalități | Aproape întotdeauna necesar DPA (Art. 28) |
| Portabilitate la încetare | Codul rămâne la client | Trebuie reglementată explicit în contract |
SLA (Service Level Agreement) — ce trebuie să conțină
Într-un contract SaaS, SLA-ul este documentul care definește calitatea serviciului și consecințele nerespectării acestuia. Un SLA complet trebuie să specifice:
- Disponibilitatea garantată (uptime) — ex. 99,9% lunar (= maxim ~44 min downtime/lună)
- Timpii de răspuns pentru incidente critice, majore și minore
- Fereastra de mentenanță planificată — ore în afara programului de lucru
- Compensațiile pentru nerespectarea SLA (credite de serviciu sau reduceri)
- Excluderile — forță majoră, erori ale clientului, atacuri DDoS
- Modalitatea de raportare și accesul la date de monitorizare
Un SLA fără mecanism de compensare este inutil juridic. Și invers — compensații nelimitate pentru downtime pot falimenta un furnizor. Echilibrul legal înseamnă: compensații rezonabile (de regulă % din abonamentul lunar) plafonate la o valoare maximă anuală.
Întrebări frecvente ale firmelor IT despre contracte software
Legea aplicabilă și instanța competentă: de ce contează pentru firmele IT
Firmele IT lucrează frecvent cu clienți din alte țări. Alegerea legii aplicabile și a instanței/arbitrajului competent nu este o formalitate — poate decide dacă un litigiu poate fi câștigat și la ce costuri.
Recomandare generală pentru firme IT românești: stipulați legea română ca lege aplicabilă și Tribunalul Comercial sau arbitrajul CAB (Camera de Arbitraj Comercial de pe lângă Camera de Comerț și Industrie a României) pentru litigii.
Pentru contracte cu clienți din UE: Regulamentul Roma I se aplică automat și permite alegerea legii aplicabile în B2B. Atenție: în B2C, normele de protecție a consumatorilor din țara clientului se pot aplica indiferent de ce scrie în contract.
