Proprietatea codului și a datelor în software personalizat
Ce trebuie să prevadă contractul privind codul sursă, datele, bibliotecile, accesul, livrarea și continuarea unui proiect de software personalizat.
De Η ομάδα της Argonstack, TechIns Group
Fraza „software-ul ne va aparține” nu este suficientă. Într-un proiect personalizat trebuie separate codul sursă, datele, design-ul, documentația, bibliotecile preexistente, licențele terților, infrastructura și dreptul de a continua dezvoltarea printr-o altă echipă.
Dacă acestea nu sunt definite înainte de începerea proiectului, disputa apare de obicei atunci când clientul cere acces la repository, schimbarea partenerului sau exportul datelor. Problema nu se rezolvă prin faptul că cineva a plătit dezvoltarea. Se rezolvă prin contract și legea aplicabilă.
Acest articol este un ghid de afaceri și nu o opinie juridică. Contractul final trebuie verificat de un avocat cu cunoștințe de proprietate intelectuală și tehnologie.
Ce înseamnă proprietatea codului sursă
Codul sursă este materialul folosit de dezvoltatori pentru a crea și modifica aplicația. Accesul la cod nu se identifică neapărat cu transferul tuturor drepturilor. O companie poate avea o copie a repository-ului, dar un drept limitat de utilizare. Poate de asemenea avea o licență exclusivă de utilizare fără a fi achiziționat fiecare element folosit.
Directiva 2009/24/CE europeană protejează programele de calculator prin proprietate intelectuală. Contractul trebuie să definească cu precizie ce drepturi sunt transferate, când sunt transferate, pentru ce teritoriu și dacă există o restricție de utilizare sau modificare.
Patru categorii de cod
Codul unui proiect de obicei nu este un lucru unitar. Include cod nou scris special pentru client, instrumente preexistente ale furnizorului, biblioteci open source și servicii comerciale ale terților.
Codul nou special poate fi transferat clientului sau licențiat. Framework-urile preexistente ale furnizorului rămân de obicei la furnizor, cu drept de utilizare în cadrul livrabilului. Bibliotecile open source urmează propriile licențe. Serviciile terților, precum cloud, hărți, e-mail sau API-uri AI, sunt guvernate de termenii furnizorilor respectivi.
Dacă contractul declară pur și simplu că „clientul obține tot codul”, fără aceste excepții, poate promite ceva care nu este posibil din punct de vedere tehnic sau legal.
Datele clientului
Contractul trebuie să declare că datele operaționale ale clientului rămân sub controlul acestuia. Trebuie să definească modul în care sunt introduse, unde sunt stocate, cine are acces, cum se creează copii de siguranță și cum sunt exportate după încheierea colaborării.
Pentru datele cu caracter personal este necesară în plus stabilirea rolurilor conform GDPR și, acolo unde furnizorul acționează ca persoană împuternicită de operator, un Acord de Prelucrare a Datelor corespunzător. „Proprietatea datelor” nu înlocuiește obligațiile de protecție a datelor cu caracter personal.
Ce trebuie livrat
Posibilitatea reală de a continua un proiect necesită mai mult decât un zip cu cod sursă. Este nevoie de acces la repository, instrucțiuni de instalare, variabile de mediu fără dezvăluirea secretelor netransferabile, schema bazei de date, documentația API, lista dependențelor, procesul de deployment, procesul de backup și lista conturilor terților.
Trebuie de asemenea definit cine controlează domeniul, contul cloud, conturile din app store, analytics, serviciile de e-mail și cheile de semnare. Acolo unde este posibil, conturile critice trebuie să aparțină clientului, iar furnizorul să obțină acces controlat.
Când se transferă drepturile
O logică comercială obișnuită este transferul drepturilor convenite după achitarea integrală. Acest lucru trebuie să fie explicit. În paralel, trebuie definit ce se întâmplă dacă proiectul este întrerupt înainte de finalizare, ce livrabile au fost plătite și ce drept de utilizare obține clientul pentru munca deja livrată. Termenii comerciali relevanți sunt descriși în Termenii și Condițiile ale Argonstack.
Vendor lock-in și dreptul de ieșire
Dependența de furnizor nu este întotdeauna rea. Fiecare sistem complex necesită specializare. Devine însă periculoasă atunci când clientul nu poate obține datele, documentația sau accesul la conturile critice.
Un contract serios include un plan de ieșire. Definește formatul de export, timpul de livrare, perioada de tranziție, costul suportului suplimentar și ștergerea copiilor după expirarea obligațiilor legale de păstrare.
Escrow pentru codul sursă
În sisteme critice se poate conveni un escrow pentru codul sursă. O copie actualizată a codului și a documentației este păstrată de o parte independentă și eliberată doar în cazuri specifice, precum încetarea activității furnizorului sau incapacitatea gravă de a oferi suport.
Escrow-ul nu înlocuiește documentația și arhitectura corectă. Dacă materialul nu este actualizat sau nu poate fi instalat, existența sa are o valoare limitată.
Ce trebuie să ceară clientul înainte de a semna
Clientul trebuie să ceară o definiție clară a livrabilelor, a drepturilor asupra codului special, a excepțiilor, a licențelor terților, a accesului la repository, a proprietății conturilor, a exportului de date, a documentației, a mentenanței și a planului de ieșire.
Argonstack organizează fiecare proiect personalizat cu un scope clar și o arhitectură tehnică. Termenii de proprietate și livrare trebuie consemnați în contractul special al proiectului și trebuie să reflecte modelul real de colaborare.
Pasul următor
Definiți scope-ul, drepturile, accesul și planul de ieșire înainte de a începe dezvoltarea.
Întrebări frecvente
Dacă plătesc dezvoltarea, îmi aparține automat codul?
Nu neapărat. Plata și transferul drepturilor sunt aspecte diferite. Contractul trebuie să definească exact ce obține clientul.
Îmi pot aparține bibliotecile open source?
Nu în sensul proprietății exclusive. Sunt folosite conform licențelor lor. Furnizorul trebuie să declare dependențele critice și obligațiile corespunzătoare.
Contul cloud trebuie să fie pe numele clientului?
Pentru infrastructura personalizată critică este adesea opțiunea cea mai sigură, cu condiția să existe o gestionare corectă a accesurilor. Într-un produs SaaS de obicei nu este aplicabil, deoarece infrastructura comună aparține furnizorului.
Ce este mai important decât fraza „codul îmi aparține”?
Capacitatea reală de funcționare, export de date, mentenanță și tranziție. Fără documentație, conturi și proces de deployment, proprietatea teoretică poate avea o valoare practică redusă.
