Liber dar încătușat - capcana Java

de Richard Stallman

12 aprilie 2004

Dacă programul dvs. este software liber, acesta este în pricipiu etic, dar există o capcană de care trebuie să fiți conștient. Programul dvs., deși liber, poate fi restricționat de software ne-liber de care depinde. Întrucât problema este proeminentă azi pentru programele Java, o numim Capcana Java.

Un program este software liber dacă utilizatorii săi au anumite libertăți cruciale. Pe scurt, acestea sunt: libertatea de a rula programul, libertatea de a studia și schimba codul sursă, libertatea de a redistribui codul sursă și binarele și libertatea de a publica versiuni îmbunătățite. (Vedeți http://www.gnu.org/philosophy/free-sw.html.) Dacă un anumit program este software liber depinde în întregime de înțelesul licenței sale.

Dacă programul poate fi folosit în Lumea Liberă, folosit de cei ce vor să trăiască în libertate, este o întrebare mai complexă. Aceasta nu este determinată numai de licența programului, pentru că un program nu funcționează în izolare. Fiecare program depinde de alte programe. De exemplu, un program trebuie compilat sau interpretat, așa că depinde de un compilator sau un interpretor. Dacă este compilat în byte code, programul depinde de interpretorul de byte code. Mai mult, aceste depinde de biblioteci pentru a rula și mai poate invoca alte programe separate care rulează în alte procese. Toate aceste programe sunt dependențe. Dependențele pot fi necesare pentru ca programul să ruleze, sau pot fi necesare numai pentru anumite capabilități. În ambele cazuri, părți din program sau tot programul nu pot opera fără dependențe.

Dacă unele dintre dependențele programului nu sunt libere, aceasta înseamnă că unele părți din program sau întreg programul nu pot rula într-un sistem liber în totalitate — el este de nefolosit în Lumea Liberă. Desigur, noi am putea redistribui programul și am putea avea copii în computerele noastre, dar n-ar fi de prea mare folos dacă nu l-am putea rula. Acel program este software liber, dar este în fapt încătușat de dependențele sale ne-libere.

Această problemă poate avea loc în orice tip de software, în orice limbaj. De exemplu, un program liber care rulează numai pe Microsoft Windows este în mod clar de nefolosit în Lumea Liberă. Dar software-ul care rulează pe GNU/Linux poate de asemenea fi de nefolosit dacă depinde de alt software ne-liber. În trecut, Motif (înainte de a avea LessTif) și Qt (înainte ca dezvoltatorii săi să-l facă software liber) au fost cauze majore ale acestei probleme. Cele mai multe carduri video 3D funcționează la parametrii nominali numai cu drivere ne-libere, care cauzează de asemenea această problemă. Dar sursa majoră a acestei probleme este azi Java, pentru că cei ce scriu software liber simt adeseori că Java este sexy. Orbiți de atracția lor pentru limbaj, ei neglijează chestiunea dependențelor și cad în Capcana Java.

Implementarea lui Sun de Java este ne-liberă. Blackdown este de asemenea ne-liberă pentru că este o adaptare a codului proprietar a lui Sun. Bibliotecile standard Java sunt de asemenea ne-libere. Noi avem implementări libere de Java, cum ar fi Compilatorul GNU pentru Java (GCJ) și GNU Classpath, dar ele încă nu suportă toate capabilitățile. Încă ne străduim să-i prindem din urmă.

Dacă dezvoltați un program Java pe platforma Java a lui Sun, sunteți în pericol să folosiți capabilități disponibile numai în versiunea Sun fără nici măcar să realizați acest lucru. Pe când vă dați seama ar putea trece luni de zile și repararea situației ar putea lua alte câteva luni. Ați putea spune: „E prea mult de lucru să o iau de la capăt.” și atunci programul dvs. a căzut în Capcana Java; el nu va putea fi folosit în Lumea Liberă.

Modul eficace în care puteți evita Capcana Java este să aveți doar o implementare liberă de Java pe sistemul dvs.. Atunci, dacă folosiți o capabilitate Java sau o bibliotecă pe care software-ul liber încă nu o suportă, vă veți da seama de acest lucru pe loc și veți putea rescrie codul imediat.

Sun continuă să dezvolte biblioteci Java „standard” adiționale și aproape toate sunt ne-libere; în multe cazuri, chiar și specificațiile bibliotecii sunt „trade secret” iar cea mai recentă licență a lui Sun pentru aceste specificații interzice lansarea/distribuirea a unor implementări incomplete ale specificațiilor. (Vedeți de exemplu http://jcp.org/aboutJava/communityprocess/JSPA2.pdf și http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html).

Din fericire, licența pentru specificații permite lansarea unei implementări ca software liber; cei care primesc biblioteca o pot modifica și nu sunt obligați să adere la specificație. Dar cerința are efectul de a interzice folosirea unui model de dezvoltare colaborativ de producere a implementației libere. Folosirea acelui model ar însemna publicarea de versiuni incomplete, ceea ce este interzis celor care au citit specificațiile.

La începuturile Mișcării pentru Software Liber, erau imposibil de evitat dependențele de programe ne-libere. Înainte de a avea compilatorul C GNU, fiecare program C (liber sau nu) depindea de un compilator C ne-liber. Înainte de a avea biblioteca C GNU, fiecare program depindea de o bibliotecă C ne-liberă. Înainte de a avea Linux, primul kernel liber, fiecare program depindea de un kernel ne-liber. Înainte de a avea BASH, fiecare script shell trebuia să fie interpretat de un shell ne-liber. A fost inevitabil ca primele noastre programe să fie inițial îngrădite de aceste dependențe, dar noi am acceptat această situație pentru că planul nostru includea salvarea lor ulterioară. Scopul nostru final, un sistem de operare GNU auto-susținut, includea înlocuitori liberi pentru toate acele dependențe; dacă atingeam scopul, toate programele noastre ar fi salvate. Acest lucru s-a întâmplat: cu sistemul GNU/Linux, noi putem rula aceste programe pe platforme libere.

Situația este diferită azi. Noi avem acum sisteme de operare libere puternice și multe unelte de programare libere. Orice lucru pe care ați dori să-l faceți poate fi făcut acum pe o pllatformă liberă; nu există nici o nevoie să acceptați o dependență ne-liberă, nici măcar temporar. Principalul motiv pentru care oamenii cad în capcană acum este faptul că nu se gândesc la aceasta. Cea mai ușoară soluție la problema Capcanei Java este educarea despre existența acesteia.

Pentru a ține codul dvs. Java în siguranță față de Capcana Java, instalați un mediu de dezvoltare Java și folosiți-l. În general, orice limbaj ați folosi, țineți ochii deschiși și verificați starea libertății a programelor de care depinde codul dvs.. Cel mai ușor puteți verifica dacă un program este liber căutându-l în Directorul de Software Liber (http://www.fsf.org/directory). Dacă un program nu este în director, puteți să-i verificați licența comparând-o cu lista de licențe pentru software liber (http://www.gnu.org/licenses/license-list.html).

Noi încercăm să salvăm programele Java căzute în capcană, așa că dacă vă place limbajul Java, vă invităm să ajutați la dezvoltarea lui GNU Classpath. Încercându-vă programele cu compilatorul GCJ și GNU Classpath și raportând problemele pe care le aveți în clasele deja implementate este de asemenea folositor. Totuși, ne va lua ceva timp să terminăm GNU Classpath; dacă adăugarea altor biblioteci ne-libere va continua, s-ar putea să nu le aveți niciodată pe cele mai recente. Așa că vă rugăm să nu puneți software-ul dvs. liber în lanțuri. Când scrieți o aplicație azi, scrieți-o să ruleze pe platforme libere de la început.

Vedeți și:

Incidentul ciudat cu soarele (Sun) în timpul nopții