Articol
Contracte software/IP în România: ce trebuie verificat
Software/IP în România trebuie să clarifice cine deține codul, ce cesiuni există, cum se transferă drepturile contractorilor și dacă termenii SaaS și open-source sunt aliniați.
Problemele de software/IP în România sunt descoperite adesea prea târziu: înainte de investiție, la verificarea unui client enterprise, într-o vânzare sau într-un conflict cu un dezvoltator. Compania presupune că deține codul, designul, documentația sau produsul pentru care a plătit. Juridic, răspunsul depinde de contracte.
Răspunsul scurt: contractele software în România trebuie să spună clar cine deține codul, ce cesiune IP există, ce licențe se aplică, cum sunt transferate drepturile contractorilor software, ce spun termenii SaaS către clienți și cum este controlat open-source compliance.
1. Porniți de la lanțul drepturilor
Prima întrebare este simplă: poate compania demonstra că deține sau poate folosi tot ce vinde, licențiază sau prezintă ca parte din produs?
O verificare utilă urmărește lanțul drepturilor de la idee la produs:
- fondatori și contributori inițiali;
- angajați și contractori;
- agenții și dezvoltatori externi;
- componente open-source;
- API-uri și instrumente terțe;
- dezvoltări pentru clienți;
- documentație, design, baze de date și conținut.
Aceasta este baza activității de software/IP. Problema nu este doar teoria drepturilor de autor. Problema este dacă societatea poate arăta o poziție clară când un cumpărător, investitor sau client enterprise întreabă.
2. Verificați fiecare contract de dezvoltare software
Un contract de dezvoltare software nu trebuie doar să descrie munca. El trebuie să facă poziția juridică utilizabilă. Contractul ar trebui să identifice livrabilele, etapele, acceptanța, accesul la codul-sursă, documentația, mentenanța, suportul, confidențialitatea și rezultatul IP.
Pentru companii românești care lucrează cu contractori, punctul important este dacă există o cesiune IP eficientă sau o licență suficient de largă pentru modelul de business. Dacă societatea trebuie să modifice, sublicențieze, vândă, găzduiască, integreze sau transfere software-ul, contractul trebuie să o spună clar.
Același lucru se aplică software-ului creat de fondatori înainte de înființare sau de dezvoltatori angajați prin aranjamente informale. Aceste goluri devin serioase în due diligence.
3. Faceți cesiunea IP explicită
Clauzele de cesiune IP trebuie să fie precise. Ele ar trebui să identifice drepturile transferate, operele sau livrabilele acoperite, teritoriul, durata, utilizările permise, legătura cu plata și includerea modificărilor viitoare.
Pentru produse software, contractul ar trebui să acopere cod-sursă, cod-obiect, baze de date, documentație, materiale de interfață, design și opere derivate. O clauză vagă potrivit căreia clientul deține rezultatul poate fi insuficientă pentru un produs valoros.
Când societatea nu are nevoie de proprietate, licența trebuie totuși să corespundă businessului. Un furnizor SaaS poate avea nevoie de drepturi de găzduire, operare, mentenanță, îmbunătățire, analiză și furnizare a serviciului către clienți din mai multe jurisdicții.
4. Aliniați termenii SaaS cu produsul real
Termenii SaaS sunt adesea copiați din template-uri care nu corespund produsului. Asta creează risc evitabil. Termenii trebuie să reflecte cum este livrat serviciul, ce date sunt prelucrate, ce uptime sau suport este promis, cum sunt administrate conturile, ce restricții se aplică și ce se întâmplă la încetare.
Clauzele importante comercial includ plata, reînnoirea, suspendarea, datele clientului, utilizarea acceptabilă, modificările serviciului, limitările de răspundere, garanțiile, securitatea, confidențialitatea și legea aplicabilă.
Termenii SaaS trebuie conectați cu contracte comerciale și protecția datelor, deoarece contractele cu clienții și documentele GDPR trebuie să descrie aceeași realitate operațională.
5. Nu ignorați open-source compliance
Open-source compliance nu este doar o problemă de dezvoltare. Unele licențe impun atribuire, includerea textului licenței, publicarea modificărilor sau alte obligații care pot afecta distribuția, vânzările enterprise sau due diligence-ul într-o achiziție.
Compania ar trebui să știe:
- ce componente open-source folosește;
- ce licențe se aplică;
- dacă este declanșată vreo licență copyleft;
- dacă sunt necesare notificări sau atribuiri;
- dacă promisiunile făcute clienților pot fi susținute de produs.
Asta nu înseamnă că open-source trebuie evitat. Înseamnă că societatea trebuie să știe ce folosește și ce obligații urmează.
6. Curățați drepturile contractorilor software înainte de due diligence
Drepturile contractorilor software sunt un punct vulnerabil frecvent. Startup-urile și companiile digitale folosesc deseori freelanceri, agenții sau colaboratori apropiați fondatorilor înainte ca documentația juridică să ajungă din urmă produsul.
Înainte de finanțare, vânzare, lansare internațională sau contractare enterprise, compania ar trebui să revizuiască acordurile cu contractorii și să repare cesiunile lipsă acolo unde este posibil. O curățare juridică scurtă este de obicei mai ușoară înainte ca întrebarea să apară într-o solicitare de due diligence.
Pentru un avocat sau cabinet de avocatură care consiliază companii software, obiectivul practic este clar: drepturi defensibile asupra produsului, contracte consistente cu clienții și mai puțină fricțiune când compania crește.