spyked bricks in the wall

proprietatea intelectuală, implicații tehnice

Dat fiind faptul că sunt filosof în aceeași măsură în care Ilie Moromete e filosof și dat fiind de asemenea faptul că nu sunt specialist în probleme de economie și cu atât mai puțin în probleme de drept, eu unul nu pot nici măcar să încep a concepe o etică a pirateriei. Eu doar am observat ceea ce mi se pare a fi o problemă gravă, iar mai departe cine are ochi să și-i belească.

Ceea ce pot face însă e să mă uit la problemă dintr-un unghi familiar mie, anume cel tehnic, unghi din care tot privesc lucrurile în ultimii șase ani sau mai mult. Scurta descriere a anatomiei modelului proprietar tratează deja o parte din aspectele care contribuie la toată această babilonie însă nu intră prea tare în detalii, astfel că rămâne ca dânsele să fie penetrate în cele ce urmează. Propun astfel să mergem în continuare pe linia produselor de tip software, în ideea că se pot face în principiu analogii cu restul lucrărilor mai mult sau mai puțin artistice care-s în același timp și proprietate intelectuală, dar mai ales deoarece software-ul pune cele mai mari probleme din acest punct de vedere.

Și voi începe direct cu motivul care stă la baza tuturor problemelor: software-ul în esența sa (și poate doar acolo) este fără dubiu o formă de exprimare aparținând domeniului public, în aceeași măsură în care pictura spre exemplu aparține domeniului public, în virtutea faptului că exprimarea denotă prin definiție comunicare. Diferența principală constă în faptul că expresia software-ului e îngrădită de rigoarea matematicii, orice algoritm convențional reducându-se la idiomuri/formalisme standard.

Acest lucru este în general de dorit, însă există situații – datând încă de la începuturile științei calculatoarelor – în care algoritmul nu e convențional și/sau creatorul nu dorește să îl facă public, dat fiind faptul că invenția acestuia îl constituie drept proprietate intelectuală [i]. Cu toate acestea trebuie să înțelegem că invențiile software standard, cum ar fi de exemplu protocoalele de comunicații, sunt prin natura lor publice, cazul contrar făcând implementarea lor imposibilă.

Revenind, poate exista și există totuși dorința creării unui software destinat comercializării, deci care (1) să aibă codul sursă secret și (2) să nu poată fi folosit decât de cei care plătesc pentru acesta. Formulând problema în felul ăsta putem afirma că un program pe calculator care respectă cu strictețe cele două condiții e „piracy-proof” prin însuși felul în care e proiectat, chestie care evident că nu-i complet realizabilă.

Plecând de la ideea că în general licențele sub care există codul proprietar sunt simple – codul e proprietatea companiei și nu poate fi folosit decât cu permisiunea acesteia și conform unor condiții bine definite etc. -, (1) poate fi la rândul său spart în două subpuncte:

• (1-a) Rareori se pornește cu implementarea unei soluții software de la zero, astfel că de obicei dezvoltarea se face fie folosind componente software care au codul ascuns și specificația liberă, fie plecând de la un cod (eventual public) care e deja sub o licență. Primul caz e mai ieftin, dar are dezavantajul că poate compromite design-ul proiectului prin specificația proastă, de exemplu, sau chiar prin implementare. Al doilea caz e o idee mai complicat, în sensul că licența poate fi una restrictivă precum GPL sau poate fi accesibilă contra cost, prețul fiind de obicei mai mare decât în cazul bibliotecilor binare, pentru că na, este oferit accesul la implementare. Alternativa e o implementare proprie, care la rândul ei costă timp și bani și care de obicei iese (inițial) mai prost decât cea existentă sau nu iese deloc, caz în care compania dă faliment.
• (1-b) Programele sunt dezvoltate de echipe de oameni, nu întotdeauna angajați ai companiei-mamă, cazul extrem fiind cel în care se face outsourcing masiv. Oamenii respectivi vor semna contracte de confidențialitate conform cărora se angajează să nu scuipe secretele către o a treia parte. Foarte des compania va implementa o politică de securitate, conform căreia echipa A nu va avea acces la ceea ce face echipa B și vice-versa, din multiple motive în care nu intrăm aici. Cert e că totuși trebuie să existe o punte de colaborare între A și B astfel încât să fie asigurată interoperabilitatea. Se ajunge în mod normal la dublarea specificației în codul propriu-zis, de exemplu sub forma headerelor publice/private.

Despre (2) am mai discutat în articolul anterior: soluțiile pur software mai noi folosesc scheme de tipul Digital Rights Management, care încearcă să asigure că piratarea produsului – fapt ce implică de obicei și modificarea acestuia într-o mică măsură, prin crack-uri – îl va face pe acesta din urmă inutilizabil. Cazul cel mai interesant și mai dezbătut este cel al intervenției directe asupra efectelor, deci acțiunea în instanță împotriva piraților. Aceasta se justifică cel puțin în cazul în care acuzatul obține beneficii comerciale de pe urma produsului/produselor, în caz contrar acesta fiind teoretic acoperit de „fair use”.

Dacă a doua acțiune e una de natură legală, prima prezintă interes din punct de vedere tehnic mai ales prin faptul că nu există un așa-zis „silver bullet” în acest sens. Plecând de la afirmația anterioară, cea conform căreia software-ul este prin natura sa în domeniul public, observăm că acesta poate fi cu ușurință decompilat, modificat și aranjat în așa fel încât produsul final să fie foarte aproape de experiența inițială. Singura șansă de reușită a unei scheme anti-piraterie integrată în software este adăugarea suportului în hardware, astfel că unii producători de software caută să îl dezvolte integrat cu platforme hardware proprietare [ii].

În fine, există un avantaj tehnic remarcabil al software-ului din domeniul public (fie el și sub o licență restrictivă cum e GPL) asupra celui proprietar. Ilustrarea nu se poate face decât prin exemplul deja clasic al nucleului Linux, care este un proiect de succes al comunității open-source și al întregii industrii de calculatoare, cel puțin prin simplul fapt că multă lume are un telefon [iii] cu Linux fără să fie conștientă de aspectul ăsta. La polul opus, Windows necesită o investiție titanică pentru a se menține pe picioare, pentru că e aproape imposibil să obții peer review pe cod proprietar, rezultând în șanse foarte mari să scoți pe piață un produs plin de bug-uri, acela purtând de exemplu numele de Windows Me sau Vista.

Firește că toate problemele și subproblemele prezentate mai sus au complicațiile lor care depind de situații precum cadrul legal – bunăoară legile țării în care sunt făcute cercetarea și dezvoltarea. Companiile mari ajung astfel să angajeze echipe de oameni pricepuți în ale legilor pentru a lua la ochi totul de la cod până la interacțiunea cu alte companii și cu publicul și a se asigura că totul e ca la carte [iv]. Aceleași probleme ajung să afecteze uneori indirect inclusiv software-ul din domeniul public, pentru că hardware-ul nu are foarte multe implementări open-source de exemplu.

A se lua în considerare faptul că cele de mai sus nu sunt formulate cu intenția de a fi o critică la adresa software-ului proprietar și/sau open-source, nici nu sunt adevăruri imuabile și nici nu caută să particularizeze problemele proprietății intelectuale și a pirateriei. Toate acestea sunt prezente sub diverse forme în tot ceea ce înseamnă proprietate intelectuală și reprezintă o mică parte din ideile necesare oricui va încerca să înceapă a înțelege dilemele puse de proprietatea intelectuală în vremurile Internetului.

1. Și nu numai. De exemplu în trecut s-a încercat conceperea unor metode de criptare folosind algoritmi secreți, metode care au fost toate sparte rând pe rând – nu comentăm aici contextul și alte detalii. Drept urmare, în ziua de astăzi algoritmii de criptare sunt în general publici și doar cheile de criptare sunt păstrate secrete. [↩]
2. Acest control fin este de fapt motivul pentru care Apple au politica restrictivă în ceea ce privește platformele lor hardware și software. Sigur, „oferirea unei experiențe integrate” este o fraiereală superbă pentru care Steve Jobs merită tot respectul. [↩]
3. Sau un cuptor cu microunde, frigider, televizor, calculator de bord etc. [↩]
4. O documentare și punere în practică ca la carte e totuși imposibil de realizat în Statele Unite cred. [↩]