Externalizarea dezvoltării software. Cum vă puteți proteja proprietatea intelectuală?


Interconectarea adusă de IoT - din perspectivă (cvasi)juridică



Yüklə 225,84 Kb.
səhifə11/11
tarix08.01.2019
ölçüsü225,84 Kb.
#92587
1   2   3   4   5   6   7   8   9   10   11

Interconectarea adusă de IoT - din perspectivă (cvasi)juridică


DIVERSE

Internet of Things (Internetul Lucrurilor) - IoT este deja aici și nu poate fi ignorat. Termenul este folosit din ce în ce mai des și în România și se referă la diverse obiecte fizice conectate - prin Internet și aplicații software ce le permit să comunice unul cu celălalt (și cu noi, utilizatorii). Pe scurt, IoT aduce împreună lumea fizică și lumea virtuală.

Se preconizează că - până în anul 2020 - vom avea 200 miliarde de obiecte interconectate, potrivit estimărilor Intel; adică aproximativ 26 pentru fiecare individ de pe Terra. Cum vă sună această cifră?

Sigur, această interconectare a oamenilor și obiectelor dă naștere unor posibilități nelimitate; dar, în același timp, mă trec puţin fiorii când îmi imaginez cât de diferită va fi societatea în care va trăi fiica mea.

IoT deja influențează multiple aspecte ale vieții noastre - orașele și casele tind să devină mai "inteligente", mașinile sunt conectate, publicitatea targetată nu ne lasă prea mult spațiu respirabil, tehnologia ne monitorizează pulsul, activităţile zilnice sau nivelul glucozei cu ajutorul dispozitivelor purtabile, etc. . Iar liantul sau "poarta de acces", după cum preferați, sunt omniprezentele telefoane mobile … inteligente şi ele. Nu e de mirare, dacă ne gandim ca smartphone-ul apare în contexte sociale şi umane din cele mai diverse, unele aproape incredibile pentru unii.

Pe lângă potențialul de dezvoltare și aspectele etice (deloc de neglijat), IoT scoate la iveală și o multitudine de riscuri juridice nemaiîntâlnite. Așa că nu doar stilul nostru de viață și afacerile sunt (și vor fi) revoluționate de tehnologiile IoT, dar și legislația din diverse industrii.


IoT și datele personale


De ce aducem în discuție datele cu caracter personal în contextul IoT?

Pentru că telefoanele inteligente și dispozitivele purtabile ce stau la baza tehnologiilor IoT colectează permanent informații personale de la și despre utilizatorii lor.

Iar de anul acesta, avem un nou regulament UE privind protecția datelor cu caracter personal. Se vrea conceput pentru a acoperi noile tehnologii legate de Internet și urmează să se aplice și în România din mai 2018.

Pe lângă o serie de schimbări ce pot viza sectorul IoT, regulamentul introduce sancțiuni monetare care nu ne pot lăsa indiferenți: amenzi de până la 4% din cifra globală de afaceri.

Iar pentru tehnologiile IoT (care se "hrănesc" cu cantități uriașe de date), implementarea principiilor "privacy by design" și "security by design" devine mai mult decât o obligatie impusă de acest nou regulament; rămâne cam unica modalitate de protecție împotriva eventualelor sancțiuni.

Să luăm exemplul platformei de eHealth Medopad. Își propune să creeze o punte între medici și pacienți, punând la dispoziția medicilor informaţii de natură clinică (așadar, categorii speciale de date cu caracter personal ale pacienților persoane fizice, date a căror prelucrare este supusă unor reguli stricte). Medicul poate monitoriza de la distanță starea pacientului, îi poate accesa dosarul, rezultatele analizelor etc. .  Acum, imaginați-vă amploarea scandalului public care s-ar isca dacă ar avea loc o breșă de securitate sau un atac informatic privind tehnologia IoT folosită de Medopad.


Pentru că … nu este așa? Nu există software sau platformă care să fie 100% sigur(ă) pe Internet.


Cu toate îmbunătățirile și investițiile în securitate, mereu vor exista - probabil - anumite erori în software care să-l facă vulnerabil la un posibil atac informatic. Iar tehnologiile IoT cresc probabilitatea unor asemenea atacuri.

De aceea, companiile ar trebui să adopte și să implementeze practici și politici interne privind limitarea consecințelor și a răspunderii în cazul apariției unui astfel de atac care să compromită datele. Pentru că un atac informatic pare să fie o chestiune de când, nu de dacă - după cum, din păcate, mi s-a confirmat recent, în cazul unuia dintre clienții noștri.

Cheia constă în a putea dovedi că s-au luat măsurile necesare pentru respectarea legislației aplicabile, corelat cu reacția promptă în cazul unui atac cibernetic sau al unei breșe de securitate. Păstrarea clienților poate depinde (și) de acestea.

În ce industrii se găsesc cele mai multe obiecte “inteligente”? (sursa)

Măsurile de securitate


Printre obligațiile impuse de legislația actuală din domeniul datelor personale și privacy se găsește și aceea de a respecta un standard de securitate adecvat riscului ce poate apărea din prelucrarea datelor.

Dar ce implică, de fapt, acest standard adecvat de securitate? De multe ori, este o noțiune interpretabilă sau măcar relativă. În acest context, s-a vehiculat ideea certificării de către un organism de auto-reglementare al industriei locale de IT - ceea ce poate fi o soluție, chiar dacă un asemenea demers poate fi greoi. Pe de altă parte, investițiile în industria IoT necesită un anumit grad de încredere între jucători, precum și certitudine - ceea ce ar putea fi obținut prin standardizarea măsurilor de securitate și certificarea de către un asemenea organism de auto-reglementare.


Curând, vom pune mai mare preț pe detaliile pe care le lăsăm în eterul Internetului.


În luna octombrie 2016, a avut loc IoT Solutions World Congress (unul dintre cele mai importante evenimente din zona IoT).

Printre ideile lansate acolo, am citit despre o perspectivă interesantă: în câțiva ani, am ajunge să deținem foarte puține lucruri. Mașina, casa și mai toate lucrurile de uz cotidian vor deveni "as a service", ca urmare a adoptării IoT la scară largă. Astfel, activul nostru principal ar fi "identitatea digitală". De aici, două consecințe: se așteaptă ca oamenilor să le pese mai mult de datele lor personale, iar companiile vor începe să-și educe propriii consumatori (astfel încât costurile privind conformarea legală să rămână sustenabile).

Aproape inconștient, combin mental această perspectivă cu procentul imens al persoanelor care au acces la un smartphone, dar nu la o toaletă decentă. Trăim într-o lume ciudată, segregată. Vă las cu această imagine - mai ales, în contextul alegerilor din această lună. Cronologic, sunt mai apropiate de (și mai reale pentru) noi.

O posibilă soluție de back-up pentru companii – software escrow


Multe companii ajung să depindă de anumite soluții software de business din varii motive: fie ca urmare a utilizării îndelungate a acestora, fie ca urmare a unei adaptări (adeseori laborioase și de durată) a soft-ului la particularitățile respectivelor afaceri, fie pur și simplu pentru că softul în cauză este unul foarte bun în comparație cu celelalte soluții de pe piață.

Un exemplu poate fi cel al soluțiilor ERP (enterprise resource planning) adaptate în funcție de procesele de business ce prezintă interes pentru compania beneficiară. Aceste softuri ajung să fie particularizate și utilizate într-un asemenea grad ridicat, încât pentru unele companii este imposibil să-și desfășoare activitatea fără ele. (De exemplu: companiile de transport, companiile de distribuție, instituțiile financiare, etc.). Mai pot exista și alte exemple.

În acest mod se poate naște, în unele cazuri, un soi de simbioză între dezvoltatorul de aplicații și compania beneficiară.

Pentru dezvoltator, libertatea de alegere este ceva mai mare: faptul că un client nu își plătește facturile poate să nu fie o problemă atât de importantă, atât timp cât are fonduri suficiente pentru a-și continua activitatea.

Din perspectiva clienților, întreruperea dezvoltării sau a mentenanței de către dezvoltator poate fi o problemă mai serioasă. De exemplu, în cazul softurilor particularizate pentru susținerea businessului companiilor, o alternativă poate să nu fie accesibilă imediat, ceea ce poate duce la dificultăți majore și chiar la un blocaj al activității beneficiarului.

Se pune, deci, problema cum se pot proteja beneficiarii de asemenea soluții software, în situațiile în care dezvoltatorul își întrerupe serviciile. (De exemplu: în caz de faliment al dezvoltatorului, în caz de întrerupere a dezvoltării software-ului, în caz de nerespectare a obligației de mentenanță a softului, etc.)

O asemenea soluție de protecție poate fi software escrow-ul sau source-code escrow-ul. În esență, acest mecanism este același cu escrow-ul din tranzacțiile obișnuite. Pentru cine nu este familiarizat cu acesta, mecanismul poate fi rezumat în felul următor: vânzătorul și cumpărătorul unui bun desemnează o terță parte (de obicei o bancă), pentru a depozita o sumă de bani (prețul) în numele ambelor părți, și o mandatează să elibereze respectiva sumă de bani, în funcție de îndeplinirea anumitor condiții. (De exemplu: dacă cumpărătorul prezintă un anumit document stabilit de părți la bancă, aceasta îi va transfera banii; în caz contrar, aceștia se vor întoarce la vânzător.)

În mod similar funcționează și software escrow-ul, părțile contractuale implicate fiind de această dată dezvoltatorul aplicației, compania beneficiară și o companie specializată în servicii de software escrow - agentul escrow.

În cadrul aranjamentelor de software escrow, dezvoltatorul transmite către agentul escrow elementele esențiale ale aplicației - codul sursă și alte elemente software, precum și documentația aferentă acestora. În măsura în care aplicația este actualizată cu noi versiuni, se actualizează corespunzător și materialele depozitate de către agentul escrow.

Agentul escrow va fi însărcinat să păstreze materialele în condiții de securitate și confidențialitate și să le pună la dispoziția uneia dintre părți, în anumite cazuri foarte clar delimitate prin contract. Situația tipică este cea a intrării în faliment a dezvoltatorului, caz în care agentul escrow va pune aceste date și documente la dispoziția companiei beneficiare, pe baza unor documente oficiale cu privire la falimentul dezvoltatorului.

Prin acest mecanism, compania beneficiară are posibilitatea să dezvolte aplicația în mod independent, în cazul în care dezvoltatorul inițial nu se mai implică voit sau nu în această activitate.

Alegerea unui agent escrow poate fi destul de grea. Din căutările mele pe Internet, nu am reușit să găsesc o companie românească ocupându-se cu așa ceva; nimic nu împiedică să se apeleze la un agent escrow străin, mai ales că vorbim de transmiterea de informații pe suport electronic, când distanțele nu mai contează. Trebuie luate în calcul o serie de variabile: experiența agentului escrow în domeniu, capacitățile tehnice și infrastructura agentului, mediul de stocare a datelor și protocoalele de securitate, etc..

De asemenea, o atenție deosebită trebuie acordată contractului de escrow și asupra modului în care este formulat. De exemplu, dezvoltatorul va căuta să restrângă drastic cazurile în care materialele sunt transmise utilizatorului aplicației, în vreme ce clientul va avea o tendință contrară.

Desigur, dacă clauzele vi se par neclare sau prea tehnice, nu va sfiiți să apelați la un specialist cu experiență juridică în domeniul IT. În paranteză fie spus, SRL-urile "specializate" în domeniul juridic nu sunt o soluție (activitatea lor este chiar în afara legii), așa cum nici un avocat "ieftin" nu vă va face neaparăt o treabă bună.

În final, ne putem pune întrebarea (poate nu singura): ce se întâmplă dacă și agentul escrow nu mai poate să-și îndeplinească obligațiile (de exemplu, dacă dă și el faliment)? Răspunsul nu poate fi decât unul specific domeniului IT: facem back-up la back-up.

Mentenanța software-ului la comandă – Gratis sau contra cost ?


Dezvoltatorii de software la comandă așteaptă uneori cu nerăbdare perioada de mentenanță. La acest moment _software-_ul e deja instalat local pe echipamentele/infrastructura clientului, iar treaba mai laborioasă a adaptării lui la procesele și nevoile clientului este în bună măsură încheiată. 

Dacă etapele de dezvoltare și implementare au fost bine gestionate și finalizate, în perioada de mentenanță efortul dezvoltatorului de software ar trebui să fie diminuat semnificativ, iar profitabilitatea sa să crească. Cu puțin noroc (sau poate că nu doar norocul e la mijloc), în această etapă a mentenanței, intervențiile dezvoltatorului și resursele alocate vor fi minime, în timp ce onorariile de mentenanță (unele deosebit de generoase) vor compensa profitabilitatea scăzută a proiectului din etapele anterioare. 

De aceea, odată efectuată predarea-primirea finală a _software-_ului, mulți dintre dezvoltatori vor (pe bună dreptate) să factureze serviciile de mentenanță prestate. La baza acestei concepții stă și ideea (eronată) că produsul software este transmis (cesionat) către client ca atare, fără niciun fel de garanție cu privire la funcționarea sa ulterioară. Prin urmare, serviciile de mentenanță ar trebui să fie prestate contra cost. 

Există și cazuri de dezvoltatori (nu puțini la număr, dar minoritari ca pondere, din experiența noastră) care își asumă o perioadă de garanție a produsului software, în interiorul căreia serviciile de mentenanță sunt prestate în mod gratuit. Abia după expirarea perioadei de garanție asumate, serviciile de mentenanță sunt prestate contra cost. 

Pornind de la aceste tendințe practice, apar desigur întrebări firești cum ar fi: dacă există o obligație legală de a acorda o asemenea mentenanță în mod gratuit și pentru cât timp, dacă se poate înlătura această obligație prin acordul părților, etc. .

Răspunsurile la aceste întrebări nu sunt simple din mai multe motive.

O primă dificultate este dată de lipsa unei definiții general-acceptate a noțiunii de "mentenanță" a software-ului. De exemplu, clienții cu care am lucrat includ în general în această categorie activități precum: diagnosticarea și remedierea erorilor de funcționare, adaptarea software-ului la schimbările "ecosistemului" software sau hardware cu care acesta interacționează și upgrade-uri ale software-ului în cauză. Totuși, industria IT pare să aibă o concepție laxă asupra activității de mentenanță, fiind incluse în sfera acesteia (pe criterii mai mult sau mai puțin arbitrare) orice intervenții ale dezvoltatorului asupra software-ului după predarea sa finală către client. 

Pe de altă parte, nu există (din cunoștințele noastre) nici o definiție legală a conceptului de "mentenanță" a produsului software, ceea ce complică și mai mult răspunsul la întrebările de mai sus. 

Cu toate acestea, sunt reglementate obligații legale de intervenție/remediere/corectare/ajustare a produselor vândute, care pot să conducă la ideea că cel puțin unele activități de mentenanță (în sensul cel mai larg posibil) sunt obligatorii pentru producătorul software în temeiul legii și, în unele cazuri, acestea trebuie efectuate în mod gratuit. Mai jos, am menționat câteva asemenea reglementări care ar putea fi relevante.

Un prim exemplu apare în Codul Civil în privința garanției pentru viciile ascunse. Orice vânzător (cum ar fi dezvoltatorul de software) răspunde față de cumpărător pentru viciile ascunse ale produsului vândut (software-ul dezvoltat la comandă). Viciile ascunse sunt orice defecte grave (care nu pot fi sesizate fără un examen amănunțit) ale produsului în cauză, care fac bunul vândut impropriu întrebuințării la care este destinat sau care îi micşorează în asemenea măsură întrebuințarea sau valoarea încât, dacă le-ar fi cunoscut, cumpărătorul nu ar fi cumpărat sau ar fi dat un preț mai mic. În cazul nostru, se poate imagina situația descoperirii unor defecțiuni majore în funcționarea software-ului ulterior predării sale către client, care pot atrage obligația dezvoltatorului de a le remedia pe cheltuiala sa. 

Un alt exemplu (probabil ceva mai rar în industria dezvoltării software-ului la comandă) este dat de legea nr. 449/2003, în relația cu consumatorii (persoane fizice). Astfel, vânzătorul este răspunzător pentru lipsa conformității produsului vândut. Obligația de conformitate are un sens destul de larg, prin ea impunându-se vânzătorului să se asigure că respectivul produs corespunde oricărui scop specific solicitat de către consumator, scop făcut cunoscut vânzătorului și acceptat de acesta la încheierea contractului de vânzare-cumpărare. De asemenea, orice lipsă a conformității rezultată dintr-o instalare incorectă a produselor va fi considerată echivalentă cu o lipsă a conformității produselor, dacă instalarea face parte din contractul de vânzare a produselor și produsele au fost instalate de vânzător sau pe răspunderea sa. Practic, din cauza ambiguității noțiunii de "conformitate", în relația cu consumatorii, multe din disfuncționalitățile software-ului apărute după predarea finală către clientul (consumator) ar putea să fie considerate neconformități pe care dezvoltatorul să fie obligat să le remedieze fără vreo plată suplimentară din partea clientului. 

Desigur, există și unele excepții sau limitări ale acestor obligații de "mentenanță" impuse de lege dezvoltatorilor de software, dar pe care le vom trata cu o altă ocazie. 



Subiectul pe care am încercat să-l atingem este unul foarte generos, iar paleta de întrebări ce pot apărea este practic nelimitată. Nu ne-am propus să tratăm întreaga problematică ce se poate ivi în legătură cu activitatea de mentenanță software, ci mai curând să lansăm o invitație la o dezbatere mai largă pe această temă pe care sperăm să o avem cât de curând.


Yüklə 225,84 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9   10   11




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin