Introducció al programari lliure - Universitat Oberta de Catalunya

Jesús González Barahona 

Joaquín Seoane Pascual 

Gregorio Robles 

71Z799C01MO Código 

0,75 créditos 

Programari lliure 

Introducció 

al programari lliure 

U 

Formació de Postgrau

David Megías Jiménez Jordi Mas 

Coordinador Coordinador 

Enginyer en Informàtica per la UAB. Màster 

en Tècniques Avançades d’Automatització 

de Processos per la UAB. Doctor en 

Informàtica per la UAB. Professor dels 

Estudis d’Informàtica i Multimèdia de la 

UOC. 

Coordinador general de Softcatalà i 

desenvolupador del processador de textos 

lliure Abiword. 

Membre fundador de Softcatalà 

i de la xarxa telemàtica RedBBS. 

En qualitat de consultor, ha treballat 

en empreses com ara Menta, Telépolis, 

Vodafone, Lotus, eresMas, Amena i Terra 

España. 

Jesús González Barahona Joaquín Seoane Pascual 

Autor Autor 

Membre del Grup de Sistemes i 

Comunicacions (ESCET) de la Universitat 

Rey Juan Carlos de Madrid. 

jgb@gsyc.escet.urjc.es 

Gregorio Robles 

Autor 

Membre del Grup de Sistemes i 

Comunicacions (ESCET) de la Universitat 

Rey Juan Carlos de Madrid. 

grex@gsyc.escet.urjc.es 

Departament d’Enginyeria de Sistemes 

Telemàtics de la Universitat Politècnica 

de Madrid. 

joaquin@dit.upm.es 

Primera edició: març 2005 

© Fundació per a la Universitat Oberta de Catalunya 

Av. Tibidabo, 39-43, 08035 Barcelona 

Material realitzat per Eureca Media, SL 

© Autors: Jesús González Barahona, Joaquín Seoane Pascual i Gregorio Robles 

Dipòsit legal: B-15.563-2005 

ISBN: 84-9788-272-5 

Es garanteix permís per copiar, distribuir i que modifiqui aquest document segons els termes de la GNU Free Documentation License, 

Version 1.2 o qualsevol de posterior publicada per la Free Software Foundation, sense seccions invariants ni texts de coberta 

davantera o posterior. Es disposa d’una còpia de la llicència a l’apèndix A, junt amb una tradició no oficial a l’Apèndix B. Pot 

trobar-se una versió de l’última versió d’aquest document en http://curso-sobre.berlios.de/introsobre.

Índex 

Introducció al programari lliure 

Pròleg .......................................................................... 11 

Materials previs ......................................................... 11 

Agraïments .................................................................. 13 

1. Introducció al programari lliure ............................. 15 

1.1. El concepte de llibertat en el programari ............. 15 

1.1.1. Definició .................................................. 16 

1.1.2. Termes relacionats .................................... 17 

1.2. Motivacions ....................................................... 19 

1.3. Conseqüències de la llibertat del programari ....... 19 

1.3.1. Per a l’usuari final .................................... 20 

1.3.2. Per a l’administració pública ..................... 21 

1.3.3. Per al desenvolupador .............................. 22 

1.3.4. Per a l’integrador ..................................... 22 

1.3.5. Per al qui proporciona manteniment 

i serveis .................................................... 22 

1.4. Altres recursos lliures .......................................... 22 

1.4.1. Documentació de programes .................... 23 

1.4.2. Una altra documentació ........................... 24 

1.4.3. Articles científics ....................................... 24 

1.4.4. Lleis i estàndards ...................................... 25 

1.4.5. Enciclopèdies ........................................... 27 

1.4.6. Cursos ..................................................... 28 

1.4.7. Col·leccions i bases de dades .................... 29 

1.4.8. Maquinari ................................................ 29 

1.4.9. Literatura i art .......................................... 30 

2. Una mica d’història ................................................ 31 

2.1. El programari lliure abans del programari 

lliure .................................................................. 32 

2.1.1. I al principi va ser lliure ............................. 32 

2.1.2. Anys setanta i principi dels vuitanta ........... 34 

2.1.3. Desenvolupament primerenc de UNIX ....... 34 

2.2. El començament: BSD, GNU .............................. 35 

3 

ª FUOC • 71Z799C01MO 

ANOTACIONES


ANOTACIONES 

4 

Programari Lliure 

2.2.1. Richard Stallman, GNU, FSF: 

neix el moviment del programari lliure ...... 36 

2.2.2. El CSRG de Berkeley ................................ 37 

2.2.3. Els començaments d’Internet .................... 40 

2.2.4. Altres projectes ........................................ 43 

2.3. Tot en marxa ..................................................... 43 

2.3.1. A la recerca d’un nucli ............................. 43 

2.3.2. La família *BSD ....................................... 44 

2.3.3. GNU/Linux entra en escena ..................... 45 

2.4. Temps excitants ................................................. 46 

2.4.1. Final dels noranta .................................... 47 

2.4.2. Principi del 2000 ..................................... 51 

2.5. El futur: una cursa d’obstacles? .......................... 56 

2.6. Algunes dates de la història del programari 

lliure ................................................................. 57 

3. Aspectes legals ...................................................... 67 

3.1. Breu introducció a la propietat intel·lectual .......... 67 

3.1.1. Drets d’autor ........................................... 68 

3.1.2. Secret comercial ...................................... 70 

3.1.3. Patents i models d’utilitat .......................... 71 

3.1.4. Marques i logotips ................................... 72 

3.2. Llicències en el programari lliure ........................ 73 

3.2.1. Llicències de tipus BSD ............................. 74 

3.2.2. La Llicència pública general de GNU 

(GNU GPL) .............................................. 77 

3.2.3. La Llicència pública general menor 

de GNU (GNU LGPL) ............................... 79 

3.2.4. Altres llicències de programes ................... 79 

3.2.5. Distribució sota diverses llicències ............. 83 

3.3. Llicències d’altres recursos lliures ........................ 84 

3.3.1. Llicència de documentació lliure 

de GNU .................................................. 85 

3.3.2. Llicències de Creative Commons ............... 86 

3.4. Resum ............................................................... 87 

4. El desenvolupador i les seves motivacions ........... 89 

4.1. Introducció ........................................................ 89 

4.2. Qui són els desenvolupadors? ............................ 89 

4.3. Què fan els desenvolupadors? ........................... 91 

4.4. Distribució geogràfica ........................................ 92 

4.5. Dedicació .......................................................... 94 

4.6. Motivacions ....................................................... 96 

4.7. Lideratge ........................................................... 97 

4.8. Resum i conclusions ........................................... 99


5. Economia ................................................................ 101 

5.1. Finançament de projectes de programari 

lliure .................................................................. 101 

5.1.1. Finançament públic .................................. 102 

5.1.2. Finançament privat sense ànim de lucre .... 105 

5.1.3. Finançament per a qui necessita millores ... 106 

5.1.4. Finançament amb beneficis relacionats ...... 106 

5.1.5. Finançament com a inversió interna .......... 108 

5.1.6. Altres modes de finançament .................... 110 

5.2. Models de negoci basats en programari lliure ..... 113 

5.2.1. Més bon coneixement ............................... 115 

5.2.2. Més bon coneixement amb limitacions ....... 117 

5.2.3. Font d’un producte lliure ........................... 119 

5.2.4. Font d’un producte amb limitacions ........... 121 

5.2.5. Llicències especials ................................... 123 

5.2.6. Venda de marca ....................................... 123 

5.3. Altres classificacions de models de negoci ........... 124 

5.3.1. Classificació de Hecker ............................. 124 

5.4. Impacte sobre les situacions de monopoli ............ 126 

5.4.1. Elements que afavoreixen els productes 

dominants ................................................ 127 

5.4.2. El món del programari propietari .............. 128 

5.4.3. La situació amb programari lliure .............. 129 

5.4.4. Estratègies per a constituir-se en monopoli 

amb programari lliure .............................. 130 

6. Iniciatives públiques .............................................. 133 

6.1. Impacte del programari lliure 

en les administracions públiques ......................... 133 

6.1.1. Impactes principals ................................... 134 

6.1.2. Dificultats d’adopció ................................. 138 

6.2. Actuacions de les administracions públiques 

en el món del programari ................................... 140 

6.2.1. Com satisfer millor les necessitats 

de les administracions públiques? ............. 140 

6.2.2. Promoció de programari ........................... 144 

6.2.3. Foment de la investigació .......................... 145 

6.3. Iniciatives legislatives .......................................... 146 

6.3.1. Projectes de llei a França .......................... 146 

6.3.2. Projecte de llei al Brasil ............................. 148 

6.3.3. Projectes de llei al Perú ............................. 148 

6.3.4. Projectes de llei a Espanya ........................ 150 

6.4. Textos d’algunes propostes legislatives 

i documents relacionats ...................................... 151 

6.4.1. Projecte de llei de Laffitte, Trégouet 

i Cabanel (França)..................................... 151 

5 


ANOTACIONES


ANOTACIONES 

6 


6.4.2. Projecte de llei de Le Déaut, Paul i Cohen 

(França) ................................................... 154 

6.4.3. Projecte de llei de Villanueva i Rodrich 

(El Perú) ................................................... 160 

6.4.4. Cartes de Microsoft Perú i del congressista 

Villanueva ............................................... 172 

6.4.5. Decret de mesures d’impuls de la societat 

del coneixement a Andalusia .................... 190 

7. Enginyeria del programari lliure ........................... 193 

7.1. Introducció ........................................................ 193 

7.2. “La catedral i el basar” ...................................... 194 

7.3. Lideratge i presa de decisions al basar ............... 196 

7.4. Processos en el programari lliure ........................ 199 

7.5. Crítica a “La catedral i el basar” ......................... 201 

7.6. Estudis quantitatius ............................................. 202 

7.7. Treball futur ...................................................... 206 

7.8. Resum ............................................................... 208 

8. Entorns i tecnologies de desenvolupament ........... 209 

8.1. Caracterització d’entorns, eines i sistemes ........... 209 

8.2. Llenguatges i eines associades ........................... 210 

8.3. Mecanismes bàsics de col·laboració ................... 211 

8.4. Gestió de fonts ................................................. 213 

8.4.1. CVS ........................................................ 214 

8.4.2. Altres sistemes de gestió de fonts .............. 218 

8.5. Documentació ................................................... 220 

8.5.1. docbook .................................................. 222 

8.5.2. Wikis ....................................................... 223 

8.6. Gestió d’errors .................................................. 224 

8.7. Sistemes de gestió de flux de treballs .................. 226 

8.8. Suport per a altres arquitectures ......................... 226 

8.9. Llocs de suport al desenvolupament ................... 227 

8.9.1. SourceForge ............................................ 228 

8.9.2. Hereus de SourceForge ............................ 230 

8.9.3. Altres llocs i programes ............................ 230 

9. Estudi de casos ....................................................... 233 

9.1. Linux ................................................................. 235 

9.1.1. Història de Linux ...................................... 235 

9.1.2. La manera de treballar de Linux ............... 237 

9.1.3. Estat actual de Linux ................................. 238 

9.2. FreeBSD ............................................................ 240 

9.2.1. Història de FreeBSD ................................. 241


9.2.2. Desenvolupament en FreeBSD ................... 242 

9.2.3. Presa de decisions en FreeBSD .................. 242 

9.2.4. Empreses entorn de FreeBSD ..................... 243 

9.2.5. Estat actual de FreeBSD ............................ 244 

9.2.6. Radiografia de FreeBSD ............................ 244 

9.2.7. Estudis acadèmics sobre FreeBSD .............. 247 

9.3. KDE ................................................................... 247 

9.3.1. Història de KDE ........................................ 248 

9.3.2. Desenvolupament de KDE ......................... 249 

9.3.3. La Lliga KDE ............................................. 250 

9.3.4. Estat actual de KDE ................................... 252 

9.3.5. Radiografia de KDE .................................. 253 

9.4. GNOME ............................................................ 255 

9.4.1. Història de GNOME ................................. 256 

9.4.2. La Fundació GNOME ............................... 257 

9.4.3. La indústria entorn de GNOME ................. 259 

9.4.4. Estat actual de GNOME ............................ 261 

9.4.5. Radiografia de GNOME ........................... 262 

9.4.6. Estudis acadèmics sobre GNOME ............. 264 

9.5. Apache .............................................................. 265 

9.5.1. Història d’Apache ..................................... 265 

9.5.2. Desenvolupament d’Apache ...................... 266 

9.5.3. Radiografia d’Apache ............................... 267 

9.6. Mozilla .............................................................. 269 

9.6.1. Història de Mozilla .................................... 269 

9.6.2. Estat actual de Mozilla .............................. 272 

9.6.3. Radiografia de Mozilla .............................. 273 

9.7. OpenOffice.org ................................................. 274 

9.7.1. Història d’OpenOffice.org ........................ 275 

9.7.2. Organització d’OpenOffice.org ................ 276 

9.7.3. Radiografia d’OpenOffice.org ................... 276 

9.8. Red Hat Linux...................................................... 278 

9.8.1. Història de Red Hat .................................. 278 

9.8.2. Estat actual de Red Hat ............................. 280 

9.8.3. Radiografia de Red Hat ............................. 281 

9.9. Debian GNU/Linux ............................................ 283 

9.9.1. Radiografia de Debian .............................. 285 

9.9.2. Comparació amb altres 

sistemes operatius .................................... 288 

Bibliografia .................................................................. 291 

Appendix A. GNU Free Documentation License ........ 307 

A.1. PREAMBLE ......................................................... 307 

A.2. APPLICABILITY AND DEFINITIONS ...................... 308 

7 


ANOTACIONES


ANOTACIONES 

8 


A.3. VERBATIM COPYING ....................................... 310 

A.4. COPYING IN QUANTITY ................................. 310 

A.5. MODIFICATIONS ............................................ 311 

A.6. COMBINING DOCUMENTS ............................ 314 

A.7. COLLECTIONS OF DOCUMENTS .................... 314 

A.8. AGGREGATION WITH INDEPENDENT 

WORKS .......................................................... 315 

A.9. TRANSLATION ................................................ 315 

A.10. TERMINATION ................................................ 316 

A.11. FUTURE REVISIONS OF THIS LICENSE ............. 316 

A.12. ADDENDUM: How to use this License 

for your documents ......................................... 316 

Apèndix B. Llicència de documentació lliure de GNU 319 

B.1. PREÀMBUL....................................................... 319 

B.2. CAMP D’APLICACIÓ I DEFINICIONS ............... 320 

B.3. CÒPIES LITERALS ............................................ 322 

B.4. CÒPIES EN GRANS QUANTITATS ..................... 323 

B.5. MODIFICACIONS ........................................... 324 

B.6. COMBINACIÓ DE DOCUMENTS ..................... 326 

B.7. RECOPILACIONS DE DOCUMENTS ................. 327 

B.8. AGRUPAMENT AMB OBRES INDEPENDENTS .... 327 

B.9. TRADUCCIÓ ................................................... 328 

B.10. CLOENDA ...................................................... 328 

B.11. REVISIONS FUTURES 

D’AQUESTA LLICÈNCIA .................................. 328 

B.12. ADDENDA: Com utilitzar aquesta llicència 

per als vostres documents ................................ 329

Llista de taules 


4-1. Països amb més nombre de desenvolupadors 

de Debian ............................................................ 93 

4-2. Dedicació en hores setmanals ............................... 95 

4-3. Grau de coneixement de desenvolupadors 

importants ........................................................... 97 

9-1. Estat actual de Linux ............................................. 239 

9-2. Llenguatges de programació utilitzats en Linux ....... 240 

9-3. Estat actual de FreeBSD ........................................ 246 

9-4. Llenguatges de programació utilitzats en FreeBSD .. 247 

9-5. Estat actual de KDE .............................................. 254 

9-6. Llenguatges de programació utilitzats en KDE ........ 255 

9-7. Estat actual de GNOME ........................................ 263 

9-8. Llenguatges de programació utilitzats a GNOME ... 264 

9-9. Estat actual d’Apache ........................................... 268 

9-10. Llenguatges de programació utilitzats a Apache ..... 268 

9-11. Estat actual de Mozilla .......................................... 273 

9-12. Llenguatges de programació utilitzats a Mozilla ..... 274 

9-13. Estat actual d’OpenOffice.org ............................... 277 

9-14. Llenguatges de programació utilitzats 

en OpenOffice.org ............................................... 277 

9-15. Estat actual de Red Hat Linux ................................ 282 


en Red Hat ........................................................... 282 

9-17. Estat actual de Debian .......................................... 286 


en Debian GNU/Linux .......................................... 287 

9-19. Llenguatges més utilitzats en Debian ..................... 287 

9-20. Comparació amb sistemes propietaris ................... 289 

9 


ANOTACIONES

Pròleg 


La primera versió d’aquests apunts la van escriure Jesús M. González 

Barahona, Joaquín Seoane Pascual i Gregorio Robles entre els me- 

sos d’abril i setembre del 2003. Encara que feia temps que parlà- 

vem de preparar un material d’aquest tipus per a l’assignatura 

Programari lliure –que Joaquín i Jesús impartim en els programes de 

doctorat dels nostres departaments respectius–, la iniciativa va partir 

de la Universitat Oberta de Catalunya (UOC), que ens va encarregar 

un material per a l’assignatura d’introducció al seu màster de pro- 

gramari lliure, cosa que finalment va fer que ens decidíssim a posar 

fil a l’agulla. En aquest encàrrec va ser fonamental la tasca de Jordi 

Mas, coordinador acadèmic del màster, que no solament ens va pro- 

posar per a aquesta feina i ens va posar en contacte amb la UOC, 

sinó que ens va acompanyar en les relacions amb la Universitat du- 

rant el projecte. 

Materials previs 

Alguns textos d’aquests apunts estan basats en materials previs, 

normalment dels mateixos autors, però algunes vegades de terce- 

res persones (utilitzats amb permís, si no han estat completament 

reelaborats). Entre aquests materials podem esmentar els següents 

(a risc d’oblidar-ne algun d’important): 

• Hi ha alguns fragments (sobretot en els capítols d’història i eco- 

nomia) inspirats en el document Free Software / Open Source: 

Information Society Opportunities for Europe? que Jesús González 

Barahona va coeditar per a la Comissió Europea. Tanmateix, els 

fragments en qüestió han estat ampliats, retocats i actualitzats 

tant, que moltes vegades poden ser difícils de reconèixer. 

• L’apartat sobre els monopolis i el programari lliure està reelabo- 

rat a partir de l’article “Software libre, monopolios y otras yerbas”, 

de Jesús M. González Barahona. 

11 


Lectura complementària 

[Vegeu bibliografia, 

apartat 111] 

ANOTACIONS 



apartat 66]


ANOTACIONS 



apartat 84] 



apartat 67] 

12 


• Els apartats sobre iniciatives legislatives i iniciatives d’administra- 

cions públiques en relació amb el programari lliure estan basats 

en part en “Iniciatives de les administracions públiques en relació 

amb el Programari Lliure” (gràcies a Pedro de las Heras per per- 

metre’ns utilitzar aquest material, del qual és coautor). 

• Part de l’apartat sobre els motius per a usar programari lliure en 

les administracions públiques està basat en l’article de Jesús M. 

González Barahona. 

• L’apèndix B és una traducció no oficial al català de la Llicència de 

documentació lliure de GNU. 

• El capítol d’enginyeria del programari lliure és una adaptació 

d’un article sobre l’estat de l’art de l’enginyeria del programari 

aplicada al programari lliure de Jesús M. González Barahona i 

Gregorio Robles per a la revista Novática. 

• En el capítol d’estudis de casos, la part dedicada al desenvolupa- 

ment de Linux es basa en una presentació que va fer Juan-Mariano 

de Goyeneche durant el curs de doctorat “Programas Libres” de 

la Universitat Politècnica de Madrid durant el curs 2002-2003. 

• La part històrica de l’estudi detallat de GNOME s’ha agafat de la 

introducció històrica inclosa en el llibre Desarrollo de aplicaciones 

en GNOME2 elaborat per GNOME Hispano i feta per un dels au- 

tors d’aquest llibre. 

• El cas d’estudi de FreeBSD es basa en part en la ponència presen- 

tada per Jesús Rodríguez en el III Congrés HispaLinux organitzat 

a Madrid l’any 2000. 

• Els casos d’estudi de Debian i Red Hat parteixen del treball previ 

de González Barahona i altres, que han plasmat en diversos arti- 

cles els resultats de l’anàlisi quantitativa d’aquestes dues distribu- 

cions.

Agraïments 


Els autors agraeixen a la Fundació per a la Universitat Oberta de 

Catalunya (http://www.uoc.edu) el finançament de la primera edició 

d’aquesta obra, emmarcada en el Màster Internacional de Progra- 

mari Lliure ofert per aquesta institució. 

13 


ANOTACIONS

1. Introducció al programari lliure 


Què és el programari lliure? Què és i quines implicacions té la llicèn- 

cia d’un programa lliure? Com es desenvolupa el programari lliure? 

Com es financen els projectes de programari lliure, quins models de 

negoci s’experimenten relacionats amb aquests projectes? Què mo- 

tiva els desenvolupadors, especialment els voluntaris, a involucrar-se 

en projectes de programari lliure? Com són aquests desenvolupa- 

dors? Com es coordinen en els seus projectes, i com és el programari 

que produeixen? En resum, quina és la panoràmica general del pro- 

gramari lliure? Aquesta és la mena de preguntes que tractarem de 

respondre aquí. Perquè tot i que el programari lliure està cada vega- 

da més present en els mitjans de comunicació, en les converses dels 

professionals de la informàtica, i fins i tot comença a estar en boca 

dels ciutadans en general, encara és un desconegut per a molts. I 

moltes vegades els que el coneixen només en tenen informació d’al- 

guns aspectes i en desconeixen completament d’altres. 

Per començar, en aquest capítol presentarem els aspectes específics 

del programari lliure, centrant-nos fonamentalment a explicar-ne les 

bases per als que s’aproximin al tema per primera vegada, i a moti- 

var-ne la importància. Entre aquestes bases ens detindrem en la de- 

finició del terme (per saber de què parlarem) i en les conseqüències 

principals de l’ús (i la mera existència) del programari lliure. També 

presentarem altres recursos lliures diferents del programari, que han 

anat apareixent, en part, sota el seu impuls i el seu exemple. 

1.1. El concepte de llibertat en el programari 

Des de fa més de trenta anys ens hem acostumat al fet que qui ens 

ven un programa ens imposa les condicions sota les quals el podem 

utilitzar, prohibint-nos, per exemple, que el passem a un amic. Mal- 

grat que és programari, no el podem adaptar a les nostres necessi- 

tats, ni tan sols corregir-hi errors, i ens hem d’esperar que el fabricant 

els arregli. Això no té per què ser així, i és precisament el programari 

15 


ANOTACIONS


ANOTACIONS 



apartat 98] 

16 


lliure el que ens concedeix les llibertats que el programari propietari 

ens nega. 

1.1.1. Definició 

Així doncs, el terme programari lliure (o programes lliures) fa referèn- 

cia a la llibertat, tal com el va concebre Richard Stallman en la seva 

definició. En concret es refereix a quatre llibertats: 

1. Llibertat d’executar el programa en qualsevol lloc, amb qualsevol 

propòsit i per sempre. 

2. Llibertat d’estudiar-lo i adaptar-lo a les nostres necessitats. Això 

exigeix l’accés al codi font. 

3. Llibertat de redistribuir-lo, de manera que se’ns permeti col·labo- 

rar amb veïns i amics. 

4. Llibertat de millorar-lo i publicar-ne les millores. Això també exi- 

geix disposar del codi font. 

Aquestes llibertats es poden garantir d’acord amb la legalitat vigent 

per mitjà d’una llicència, com veurem en el capítol 3. En aquesta lli- 

cència es plasmen les llibertats, però també les restriccions que hi són 

compatibles, com donar crèdit als autors originals si el redistribuïm. 

Fins i tot ens pot obligar que els programes aliens que nosaltres mi- 

llorem també siguin lliures, i promoure així la creació de més progra- 

mari lliure. 

aaa 

L’ambigüitat de free 

‘Programes lliures’ és la traducció catalana del terme 

original en anglès free software. Tanmateix, en anglès 

el terme free a més de ‘lliure’ significa ‘gratis’, la qual 

cosa genera molta confusió. Per això sovint l’anglès 

manlleva paraules espanyoles i parla de libre software, 

en contraposició amb gratis software, de la mateixa 

manera que en castellà es pren prestada la paraula 

software (en català programari).


Per tant, ja no parlem de programari gratuït, i el programari lliure, 

si es vol, es pot vendre. Però a causa de la tercera llibertat, qual- 

sevol el pot redistribuir sense demanar-ne diners a canvi, ni permís 

a ningú, cosa que fa pràcticament impossible obtenir diners per 

distribuir-lo, llevat de la petita quantitat que es pugui carregar per 

gravar-lo en un suport físic i enviar-lo; cal dir, això no obstant, que 

rarament es demana, excepte per a grans volums, com és el cas 

de les distribucions. 

S’han formalitzat definicions més precises de programari lliure, com 

és el cas notable de les directrius de la distribució Debian. En aques- 

tes directrius es permet, a més a més, que l’autor exigeixi que els co- 

dis font distribuïts no es modifiquin directament, sinó que els originals 

s’acompanyin de pedaços separats i que es generin programes bi- 

naris amb un nom diferent de l’original. D’altra banda, exigeixen 

que les llicències no contaminin altres programes distribuïts en el ma- 

teix mitjà. 

1.1.2. Termes relacionats 

Sovint trobem el terme programari lliure com a equivalent del terme 

open source software (programes de font oberta), promogut per 

Eric Raymond i l’Open Source Initiative, equival al terme programa- 

ri lliure. Ara bé, des d’un punt de vista filosòfic, aquests termes són 

molt diferents, ja que el segon posa l’èmfasi en la disponibilitat del 

codi font, no pas en la llibertat, tot i que la definició és pràcticament 

igual que la de Debian. Aquest nom és més políticament asèptic i 

destaca un aspecte tècnic que pot donar lloc a avantatges tècnics, 

com ara millors models de desenvolupament i negoci, més seguretat, 

etc. Molt criticat per Richard Stallman i la Free Software Foundation, 

ha trobat molt més ressò en la literatura comercial i en les estratè- 

gies de les empreses que d’una manera o una altra donen suport 

al model. 

Altres termes relacionats amb el programari lliure són: 

• Programari gratuït o freeware 

Normalment se cedeix en binari i amb drets de redistribució. Tan- 

mateix, de vegades només es pot obtenir en un lloc oficial, normal- 

17 




apartat 85] 



apartats 162, 183 i 23] 

ANOTACIONS


ANOTACIONS 



apartat 153] 

18 


ment per promocionar altres programes o serveis, com és el cas 

dels equips de Java gratuïts que proporciona Sun Microsystems. 

• Programari de prova o shareware 

No és programari gratuït, sinó un mètode de distribució, ja que els 

programes, generalment sense fonts, es poden copiar lliurement, 

però no fer-los servir de manera continuada sense pagar-ne per l’ús. 

L’exigència de pagament es pot incentivar limitant-ne la funcionalitat 

o enviant missatges molestos, o amb una simple apel·lació a la mo- 

ral de l’usuari, a banda que les estipulacions legals de la llicència es 

podrien utilitzar en contra de l’infractor. 

• Charityware, careware 

Generalment és programari de prova el pagament del qual s’exigeix 

a una organització “caritativa” patrocinada. Moltes vegades, no 

s’exigeix el pagament, però se sol·licita una contribució voluntària. 

Algun programari lliure com ara Vim sol·licita contribucions voluntà- 

ries d’aquesta mena. 

• Domini públic 

L’autor renuncia absolutament a tots els seus drets, en favor del dret 

comú, circumstància que s’ha hagut de declarar explícitament en el 

programa, ja que si no es diu res, el programa és propietari i no s’hi 

pot fer res. En aquest cas, i si a més se’n proporcionen els codis font, 

el programa és lliure. 

• Copyleft 

Un cas particular de programari lliure amb una llicència que obliga 

que les modificacions que es distribueixin també siguin lliures. 

• Propietari, tancat, no lliure 

Termes utilitzats per a anomenar el programari que no és lliure ni de 

font oberta.

1.2. Motivacions 


Com hem vist, hi ha dues grans famílies de motivacions per al desen- 

volupament de programari lliure que donen lloc als dos noms amb 

què se les coneix: 

• La motivació ètica, amb la Free Software Foundation al capda- 

vant, hereva de la cultura hacker, i partidària del terme lliure, ar- 

gumenta que el programari és coneixement i s’ha de poder 

difondre sense traves. Ocultar-lo és una actitud antisocial i la pos- 

sibilitat de modificar programes és una forma de llibertat d’ex- 

pressió. Es pot aprofundir en aquest aspecte en els assajos de 

Stallman o en l’anàlisi de Pekka Himanen. 

• La motivació pragmàtica, amb l’Open Source Initiative al capda- 

vant, partidària del terme font oberta, argumenta avantatges tèc- 

nics i econòmics, que repassarem més avall. 

A part d’aquestes dues grans motivacions, la gent que treballa en 

programari lliure ho pot fer per moltes altres raons que van des de 

la diversió a la mera retribució econòmica, que és possible a causa 

dels models de negoci sostenibles. En el capítol 4 s’aprofundeix en 

aquestes motivacions a partir d’anàlisis objectives. 

1.3. Conseqüències de la llibertat del programari 

El programari lliure implica nombrosos avantatges i pocs desavan- 

tatges, molts exagerats (o falsejats) per la competència propietària. 

D’aquests desavantatges, el que té més fonament és l’econòmic, ja 

que, com hem vist, no és possible obtenir-ne gaires diners amb la 

distribució i aquesta la pot fer i la sol fer algú diferent de l’autor. Per 

aquest motiu es necessiten models de negoci i altres mecanismes de 

finançament, que es desenvolupen en el capítol 5. Altres desavantat- 

ges, com la falta de suport o l’escassa qualitat, estan relacionats amb 

el finançament, però a més moltes vegades són falsos, ja que fins i 

tot el programari sense cap tipus de finançament sol oferir molt bon 

suport per mitjà de fòrums d’usuaris i desenvolupadors, i moltes ve- 

gades té molta qualitat. 

19 




apartats 190 i 124] 



apartat 43] 



apartat 195] 

ANOTACIONS


ANOTACIONS 

20 


Tenint presents els problemes econòmics, hem d’observar que el mo- 

del de costos del programari lliure és molt diferent del propietari, ja 

que gran part s’ha desenvolupat fora de l’economia formal monetà- 

ria, moltes vegades amb mecanismes de canvi: “Jo et dono un pro- 

grama que t’interessa i tu l’adaptes a la teva arquitectura i hi fas les 

millores que t’interessen”. En el capítol 7 s’expliquen mecanismes 

d’enginyeria per a programari adequats per a aprofitar aquests re- 

cursos humans no pagats i amb característiques pròpies, mentre que 

en el capítol 8 s’estudien les eines utilitzades per a fer efectiva aques- 

ta col·laboració. Però, a més, gran part dels costos disminueixen pel 

fet de ser lliure, ja que els programes nous no tenen per què començar 

des de zero, sinó que poden reutilitzar programari ja fet. La distribu- 

ció també té un cost molt més baix, ja que es fa per Internet i amb 

propaganda gratuïta en fòrums públics destinats a això. 

Una altra conseqüència de les llibertats és la qualitat que es deriva 

de la col·laboració voluntària de gent que hi contribueix o que des- 

cobreix i reporta errors en entorns i situacions inimaginables pel 

desenvolupador original. A més, si un programa no ofereix la qua- 

litat suficient, la competència el pot agafar i millorar a partir del que 

hi ha. Així, dos poderosos mecanismes –la col·laboració i la compe- 

tència– es combinen en nom de la qualitat. 

Examinem ara les conseqüències beneficioses segons el destinatari. 

1.3.1. Per a l’usuari final 

L’usuari final, tant individual com empresa, pot trobar una autèntica 

competència en un mercat amb tendència al monopoli. En particu- 

lar, no depèn necessàriament del suport del fabricant del programa- 

ri, ja que hi pot haver múltiples empreses –potser petites– que, tot i 

disposar del codi font i de coneixements, poden fer negoci mantenint 

determinats programes lliures. 

Ja no es depèn tant de la fiabilitat del fabricant per a intentar deduir 

la qualitat d’un producte, sinó del fet que la guia ens donarà l’accep- 

tació de la comunitat i la disponibilitat dels codis font. Ens oblidem, 

a més, de les “caixes negres”, en les quals s’ha de confiar “perquè 

sí”, i de les estratègies dels fabricants, que poden decidir unilateral- 

ment deixar de mantenir un producte.


Avaluar els productes abans d’adoptar-los és molt més senzill, ja que 

n’hi ha prou d’instal·lar els productes alternatius en el nostre entorn 

real i provar-los. En el cas del programari propietari, cal fiar-se d’in- 

formes externs o negociar proves amb els proveïdors, cosa que no 

sempre és possible. 

Atesa la llibertat de modificar el programa per a ús propi, l’usuari el pot 

personalitzar o adaptar a les seves necessitats, i corregir-ne els errors, 

si els té. El procés de correcció d’errors descoberts pels usuaris en pro- 

gramari propietari sol ser extremadament penós, si no impossible, ja 

que si aconseguim que se solucionin, moltes vegades la solució s’incor- 

porarà en la versió següent, que pot trigar anys a sortir, i de vegades, 

a més a més, caldrà tornar-lo a comprar. Tanmateix, ho podem fer no- 

saltres, si estem qualificats, o podem contractar el servei a algú. També 

podem, directament o contractant serveis, integrar el programa amb 

un altre, o auditar-ne la qualitat (per exemple, la seguretat). El control 

passa, sobretot, del proveïdor a l’usuari. 

1.3.2. Per a l’administració pública 

L’administració pública és una gran usuària de característiques espe- 

cials, ja que té obligacions especials vers el ciutadà: tant si li ha de 

proporcionar serveis accessibles, neutrals respecte als fabricants, 

com si li ha de garantir la integritat, utilitat, confidencialitat i segure- 

tat de les seves dades a llarg termini. Tot això l’obliga a ser més res- 

pectuosa amb els estàndards que les empreses privades i a mantenir 

les dades en formats oberts i manipulats amb programari certificat 

com a segur per auditoria interna i que no depengui de l’estratègia 

de les empreses, generalment estrangeres. L’adequació a estàn- 

dards és una característica notable del programari lliure que no és 

tan respectada pel programari propietari, àvid, en casos molt cone- 

guts, de crear mercats captius. 

L’administració també té una certa funció d’aparador i guia de la in- 

dústria que fa que tingui un gran impacte, que s’hauria de dirigir a la 

creació d’un teixit tecnològic generador de riquesa nacional. Aquesta 

riquesa es pot crear fomentant empreses el negoci de les quals sigui, 

en part, el desenvolupament de nou programari lliure per a l’adminis- 

tració o el manteniment, adaptació o auditoria del programari exis- 

tent. En el capítol 6 ens estenem més en aquesta qüestió. 

21 


ANOTACIONS


ANOTACIONS 

22 


1.3.3. Per al desenvolupador 

Per al desenvolupador i productor de programari, la llibertat canvia 

molt les regles del joc. Amb el programari lliure li és més fàcil com- 

petir si és petit i adquirir tecnologia punta. Pot aprofitar la feina dels 

altres en el sentit que pot competir fins i tot amb un altre producte 

modificant-ne el codi, si bé també el competidor copiat s’aprofitarà 

del nostre codi (si és copyleft). Ben portat, un projecte pot aconseguir 

la col·laboració gratuïta de molta gent, del qual l’iniciat serà la refe- 

rència. La distribució també és barata i global. Això no obstant, com 

hem dit, el problema que té aquest desenvolupador és la manera 

d’obtenir recursos econòmics si la feina no és d’encàrrec. En el capí- 

tol 5 ho tractarem una mica. 

1.3.4. Per a l’integrador 

Per a l’integrador, el programari lliure és el paradís. No ha d’intentar 

encaixar més caixes negres, sovint amb enginyeria inversa. Pot llimar 

asprors i integrar trossos de programes per aconseguir el producte 

integrat necessari, i disposa d’un patrimoni ingent de programari 

lliure d’on extreure les peces. 

1.3.5. Per al qui proporciona manteniment i serveis 

Disposar del codi font ho canvia tot i ens situa gairebé en les mateixes 

condicions que el productor. Hem dit “gairebé” perquè fa falta un co- 

neixement profund del programa que només té el desenvolupador; 

per això és convenient que el mantenidor participi en els projectes 

que es dedica a mantenir. El valor afegit dels serveis és molt més 

apreciat, ja que el cost del programa és baix. De fet, actualment és 

el negoci més clar amb programari lliure i amb el qual és possible 

un grau de competència més alt. 

1.4. Altres recursos lliures 

Es poden estendre les idees dels programes lliures a altres recursos? 

En aquest sentit, podem pensar que altres recursos d’informació que


es poden copiar electrònicament amb facilitat també són de natura- 

lesa similar als programes, i per tant, s’hi poden aplicar les mateixes 

llibertats, regles i models de desenvolupament i de negoci. Hi ha, pe- 

rò, diferències, amb implicacions que han fet que aquests altres re- 

cursos no es desenvolupin amb la mateixa força que els programes. 

La principal diferència és que n’hi ha prou de copiar els programes 

perquè funcionin, mentre que des que es copia un altre tipus d’infor- 

mació fins que comença a ser útil s’ha de passar per un procés més 

o menys car, que pot anar des de l’aprenentatge d’un document a la 

producció d’un maquinari descrit en un llenguatge apropiat. Revisem 

els recursos lliures més importants. 

1.4.1. Documentació de programes 

La documentació que va amb un programa n’és una part integrant, 

com també ho són els comentaris del codi font. Així ho reconeix la 

Llei de propietat intel·lectual, i sembla lògic que s’hi apliquin les ma- 

teixes llibertats i que evolucioni de la mateixa manera. Qualsevol 

modificació que es faci d’un programa requereix un canvi simultani 

i consistent en la documentació. 

La major part d’aquesta documentació sol estar codificada com a 

fitxers de text sense format, ja que es pretén que sigui universalment 

accessible amb un entorn d’eines mínim, i ha d’incloure una petita 

introducció al programa documentat (README o LEEME), instruc- 

cions d’instal·lació (INSTALL), alguna història sobre l’evolució pas- 

sada i futura del programa (CHANGELOG i TOT), autoria i 

condicions de còpia (AUTHORS i copyright), com també les instruc- 

cions d’ús. Tots aquests elements, menys l’autoria i les condicions 

de còpia, s’haurien de poder modificar lliurement a mesura que el 

programa evoluciona. A l’autoria només s’hi haurien d’afegir noms 

i crèdits, però sense esborrar res, i les condicions de còpia només 

no s’haurien de modificar si aquestes mateixes ho permeten, com 

veurem en el capítol 3. 

Les instruccions d’ús solen estar codificades en formats més comple- 

xos, ja que normalment són documents més llargs i rics. El progra- 

mari lliure exigeix que aquesta documentació es pugui modificar 

fàcilment, cosa que al seu torn obliga a usar formats anomenats 

transparents, d’especificació coneguda i processables per eines lliu- 

23 


ANOTACIONS


ANOTACIONS 



apartat 36] 

24 


res, com són, a més del text pur i net, el format de pàgines de manual 

de UNIX, TeXinfo, LaTeX o dokbook, sens perjudici de distribuir tam- 

bé el resultat de transformar aquests documents font en formats més 

aptes per a visualitzar o imprimir, com HTML, PDF o RTF (formats 

opacs). 

1.4.2. Una altra documentació 

Tanmateix, moltes vegades terceres persones que no han intervingut 

en el desenvolupament elaboren documentació sobre programes. 

De vegades, es tracta de documentació de caràcter didàctic que fa- 

cilita la instal·lació i l’ús d’un programa concret (HOWTO o recepta- 

ris), de vegades es tracta de documentació més àmplia que inclou 

diversos programes i la seva integració, que compara solucions, 

etc., tant en forma tutorial com de referència. D’altres, es tracta 

d’una mera recopilació de preguntes freqüents (FAQ) amb les seves 

respostes. Un exemple notable és el Projecte de Documentació Linux. 

En aquesta categoria podem incloure altres documents tècnics, no ne- 

cessàriament sobre programes, com ara les instruccions per cablejar 

una xarxa local, construir una cuina solar, reparar un motor o selec- 

cionar un proveïdor de cargols. 

Aquests documents són una cosa intermèdia entre mera documenta- 

ció de programes i articles o llibres molt tècnics i pràctics. Sense de- 

triment de la llibertat de lectura, còpia, modificació i redistribució, 

l’autor pot voler expressar opinions que no desitja que es tergiversin, 

o almenys que no se li atribueixin aquestes tergiversacions. O pot vo- 

ler que es conservin paràgrafs, com els agraïments, o que necessà- 

riament se’n modifiquin d’altres, com el títol. Encara que aquestes 

inquietuds també es poden manifestar amb els programes per si ma- 

teixos, no s’han mostrat amb tanta força en el món del programari 

lliure com en el de la documentació lliure. 

1.4.3. Articles científics 

L’avenç de la ciència es deu en gran part al fet que els investigadors 

que la fan progressar per al benefici de la humanitat publiquen els 

resultats dels seus treballs en revistes d’àmplia difusió. Gràcies a 

aquesta difusió, els investigadors desenvolupen un currículum que


els permet progressar cap a llocs de més categoria i responsabilitat, 

alhora que poden obtenir ingressos a partir de contractes d’investi- 

gació que han aconseguit gràcies al prestigi obtingut. 

Així doncs, aquesta difusió d’articles representa un model de ne- 

goci, que s’ha demostrat molt fructífer, que necessita una difusió 

àmplia i una qualitat garantida perquè sigui possible. La difusió 

es veu obstaculitzada per la gran quantitat de revistes existents, de 

cost no menyspreable, que només es poden comprar amb pressu- 

postos generosos. La qualitat es garanteix mitjançant la revisió per 

especialistes. 

És per això que han sorgit nombroses iniciatives de revistes a la Xar- 

xa, entre les quals destaquen la veterana First Monday o el projecte 

Public Library Of Science. Al Directory of Open Access Journals se 

n’esmenten bastants més. S’ha de permetre que persones que no en 

són els autors publiquin una modificació d’un article? Hi ha objec- 

cions que al·leguen des d’una possible falta de qualitat o una tergi- 

versació d’opinions o resultats, fins al perill de plagi fàcil, que permet 

que alguns grimpin sense esforç i enfosqueixin els mèrits dels autèn- 

tics autors. Tanmateix, l’obligació de citar l’autor original i de passar 

una revisió en una revista de prestigi pot contrarestar aquests proble- 

mes (vegeu l’apartat 3.3.2). 

S’ha volgut establir un paral·lelisme entre el programari lliure i la ci- 

ència, ja que el model de desenvolupament del programari implica 

la màxima difusió, la revisió per d’altres, presumiblement experts, i la 

reutilització de resultats. 

1.4.4. Lleis i estàndards 

Hi ha documents el caràcter dels quals és normatiu, que definei- 

xen com s’han de fer les coses, tant per facilitar la convivència en- 

tre les persones com perquè els programes o les màquines operin 

entre ells. 

Aquests documents requereixen la màxima difusió, de manera que 

resulta contraproduent qualsevol mena d’obstacle. Per això es com- 

25 




apartats 22, 45 i 19] 



apartat 134] 

ANOTACIONS


ANOTACIONS 






apartat 55] 

26 


prèn que aquests documents normatius tinguin un tractament espe- 

cial, com passa amb la Llei de la propietat intel·lectual espanyola: 

aaa 

“No són objecte de propietat intel·lectual les disposi- 

cions legals o reglamentàries i els seus corresponents 

projectes, les resolucions dels òrgans jurisdiccionals i 

els actes, acords, deliberacions i dictàmens dels orga- 

nismes públics, i tampoc les traduccions oficials de 

tots els textos anteriors.” 

La variant tecnològica de les lleis són les normes, o estàndards. En 

programació són especialment importants els protocols de comuni- 

cacions, tant entre màquines remotes com entre diferents mòduls d’una 

mateixa màquina. És obvi que no se n’ha de limitar la difusió, espe- 

cialment si volem que floreixin els programes lliures que operin amb 

d’altres, però malgrat això, tradicionalment, els organismes de nor- 

malització, com l’ISO i l’ITU, venen les seves normes, fins i tot en for- 

mat electrònic, i prohibeixen que es redistribueixin. Encara que es 

pugui intentar justificar que això és per a cobrir parcialment les des- 

peses, la lliure difusió del text dels estàndards ha resultat molt més 

productiva. Aquest és el cas de les recomanacions del W3C i sobretot 

les que governen Internet, disponibles des del principi en documents 

anomenats RFC (demanda de comentaris o request for comments) en 

formats electrònics llegibles en qualsevol editor de textos. 

Però no és la disponibilitat l’única causa de l’èxit dels protocols d’In- 

ternet. També ho és el model de desenvolupament, molt similar al 

del programari lliure pel seu caràcter obert a la participació de qual- 

sevol interessat i per la utilització de llistes de correu i mitjans similars. 

S’ha de permetre la modificació del text de les lleis i les normes? Òb- 

viament no, si això dóna lloc a confusió. Per exemple, només s’admet 

que una RFC es modifiqui per a explicar-la o afegir-hi comentaris ex- 

plicatius, mentre que ni tan sols això es permet sense autorització ex- 

plícita per a les recomanacions del W3C. Les llicències també són 

documents legals no modificables. S’hauria de permetre la creació 

de normes noves derivades d’altres que ja existeixen a partir dels do- 

cuments originals? Segurament, fer això ens portaria a la proliferació


fàcil de normes similars i incompatibles que crearien confusió i po- 

drien ajudar les empreses que dominen el mercat a promoure la seva 

pròpia variant incompatible, com de fet ja està passant, especialment 

en l’àmbit de la Xarxa. Això no obstant, en el cas de les legislacions 

dels estats, moltes vegades s’han copiat literalment lleis d’altres paï- 

sos, adaptades amb petites modificacions a les particularitats locals. 

Hi ha un model de negoci per a les lleis i normes? Pel que fa a les 

lleis, hi ha nombrosos professionals que s’encarreguen de dissenyar- 

les, interpretar-les i forçar-ne l’aplicació (legisladors, advocats, pro- 

curadors, jutges, etc.). Quant a les normes, hi ha laboratoris que 

atorguen certificats de conformitat. Les organitzacions de normalitza- 

ció viuen, o haurien de viure, de les aportacions de membres interes- 

sats a promoure estàndards, perquè, per exemple, el seu negoci està 

format per productes que operen entre ells. 

De la mateixa manera que convé tenir una definició de programari 

lliure o obert, també cal que hi hagi una definició d’estàndards oberts. 

Bruce Perens n’ha proposat una basada en els principis següents: 

• Proporcionar, fins i tot, si és possible, una implementació lliure de 

referència (disponibilitat). 

• Maximitzar les opcions de l’usuari final. 

• No aplicar taxes sobre la implementació (però sí sobre la certifi- 

cació, encara que aconsella la disponibilitat d’eines lliures d’au- 

tocertificació). 

• No discriminar l’implementador. 

• Atorgar el permís d’extensió o restricció (no certificable). 

• Evitar pràctiques predatòries per fabricants dominants. Tota exten- 

sió propietària ha de tenir una implementació lliure de referència. 

1.4.5. Enciclopèdies 

El 1999, Richard Stallman llança la idea d’una enciclopèdia lliure com 

un mecanisme per a evitar l’apropiació del coneixement i proporcio- 

27 




apartat 14] 

ANOTACIONS 



apartat 189]


ANOTACIONS 






apartat 206] 

28 


nar accés universal a la documentació formativa. Estaria formada per 

articles aportats per la comunitat sense un control centralitzat, on ac- 

tors diferents assumirien rols diferents, entre els quals s’aconsella, però 

no es considera obligatori, el de revisor. Aquesta enciclopèdia no so- 

lament contindria text, sinó elements multimèdia i programari educatiu 

lliure. 

Han sorgit diverses iniciatives per a dur a terme aquesta proposta. 

Per exemple, la Nupedia ha tractat, de moment sense èxit, de cons- 

truir una enciclopèdia de qualitat, potser perquè requereix un for- 

mat relativament difícil d’aprendre (TEI), o potser perquè tots els 

articles necessiten un editor, revisors científics i d’estil, etc. Molt 

més èxit ha tingut la Wikipedia, que ha eliminat tots dos obstacles i 

s’aproxima més a la idea de Stallman. La Wikipedia fa servir una ei- 

na, el wiki, que permet que qualsevol persona editi qualsevol docu- 

ment per mitjà d’un sistema de text estructurat extraordinàriament 

simple, com veurem en l’apartat 8.5.2. A causa d’això han pogut re- 

collir més de cent vint mil articles en els dos primers anys de vida. 

Es pot destacar també la Concise Encyclopedia of Mathematics, que 

té un concepte de llibertat més limitat (només es pot consultar a la 

Xarxa) i un model de desenvolupament que fa passar totes les con- 

tribucions necessàriament per un comitè editorial. 

1.4.6. Cursos 

Amb la mateixa finalitat que les enciclopèdies, es pot produir mate- 

rial docent lliure, com apunts, transparències, exercicis, llibres, pla- 

nificacions o programari didàctic. Hi ha una tendència a veure les 

universitats com un negoci de producció i venda de coneixement que 

contradiu els seus principis. Els motius pels quals una universitat pot 

posar a disposició de tothom aquests materials són: 

• Complir la seva missió com a agent difusor del coneixement. 

• Fer accessible a tothom el material existent, cosa que no costa 

gaire. 

• El fet que aquests materials no substitueixen l’ensenyament pre- 

sencial.


• Divulgar-los com una publicitat que pot atraure alumnes i que 

contribueix al prestigi de la universitat. 

• Permetre que es creï una comunitat de docents que es revisin mú- 

tuament els materials i els millorin. 

La iniciativa més notable en aquest sentit és la del MIT, que preveu 

fer accessibles més de dos mil cursos de manera coherent, uniforme 

i amb una bona catalogació. 

1.4.7. Col·leccions i bases de dades 

La mera recollida d’informació seguint determinats criteris, ordenant- 

la i facilitant-ne l’accés és per si mateixa un producte d’informació va- 

luós, independent de la informació en si, subjecta per tant a autoria i 

a restriccions de les llibertats d’accés, modificació i redistribució. Per 

això, si volem informació lliure també podem voler col·leccions lliures. 

Per exemple, podem voler classificar la informació rellevant a Inter- 

net, organitzant i comentant enllaços. Això és el que fa l’ODP (Open 

Directory Project), operat per Netscape i mantingut per editors volun- 

taris organitzats segons un esquema jeràrquic. El directori complet es 

pot copiar lliurement en format RDF i es pot publicar modificat d’al- 

guna manera, com fan Google i molts altres cercadors que l’aprofi- 

ten. Netscape, propietari del directori, garanteix un contracte social 

inspirat en el de la distribució Debian que facilita la col·laboració ex- 

terior amb polítiques públiques, que és autoregulat per la comunitat 

i que té els usuaris com a primera prioritat, característiques que as- 

seguren que sempre serà lliure. 

Un altre exemple de col·leccions interessants per a nosaltres són les 

distribucions de programari lliure, amb els programes modificats 

perquè encaixin perfectament entre ells i precompilats per a una exe- 

cució fàcil. 

1.4.8. Maquinari 

La llibertat en el maquinari es pot analitzar des de dos aspectes: el 

primer és la necessitat que les interfícies i jocs d’instruccions siguin 

29 




apartat 154] 




ANOTACIONS 



apartat 41]


ANOTACIONS 



apartat 24] 

30 


oberts, de manera que qualsevol pugui fer un manejador de dispo- 

sitiu o un compilador per a una arquitectura. El segon és disposar 

de la informació i el poder suficients per a reproduir un disseny de ma- 

quinari, modificar-lo i combinar-lo amb d’altres. Els dissenys es poden 

considerar programari en un llenguatge apropiat (VHDL, Verilog, etc.). 

Tanmateix, fer-los funcionar no és fàcil, ja que s’han de fabricar i això 

és car i lent; malgrat aquests inconvenients, hi ha iniciatives en aquest 

sentit, entre les quals podem destacar l’organització Open Cores per 

a circuits integrats. 

1.4.9. Literatura i art 

Per acabar el nostre recorregut pels recursos lliures, no podem obli- 

dar l’art i la literatura, la fi última de la qual no és tant d’utilitat com 

estètica. Quines raons pot tenir un artista per a concedir llibertats de 

còpia, modificació i redistribució? D’una banda, donar a conèixer 

l’artista i afavorir la difusió de la seva obra, la qual cosa li pot per- 

metre obtenir ingressos per altres activitats, com ara concerts i obres 

d’encàrrec. D’altra banda, afavorir l’experimentació i la creativitat. 

En l’art passa el mateix que en la tècnica: la innovació és incremental 

i de vegades és difícil distingir el plagi de la pertinença a un movi- 

ment o corrent artístic. 

Òbviament no és el mateix la creació que la interpretació, ni la mú- 

sica que la literatura. La música, la pintura, la fotografia i el cinema 

són molt semblants als programes, en el sentit que se’ls fa “funcio- 

nar” immediatament en un ordinador, mentre que en d’altres, com 

l’escultura, no es pot. No hi ha gaires iniciatives en l’art i la literatura 

lliures, i són molt diverses. Podem esmentar les novel·les del col·lectiu 

Wu Ming.

2. Una mica d’història 


Encara que totes les històries relacionades amb la informàtica són 

forçosament breus, la del programari lliure és una de les més llar- 

gues. De fet, es podria dir que el programari va néixer lliure i va con- 

tinuar així durant la seva infantesa. Tanmateix, amb l’arribada de la 

joventut, la situació va canviar completament. Només ara, en arribar 

a la maduresa, està en vies de recuperar la llibertat. Això no deixa de 

ser curiós, ja que per a molts professionals informàtics, el programari 

propietari és el programari “en el seu estat natural”. Per sort, la situa- 

ció és més aviat la contrària, i les llavors del canvi que estem comen- 

çant a entreveure aquests darrers anys ja es van plantar a la primeria 

dels vuitanta. 

Suggeriment 

No hi ha gaires històries més o menys exhaustives so- 

bre el programari lliure, i les que hi ha són articles 

que es limiten a estudiar-lo amb més o menys exten- 

sió. En qualsevol cas, els que hi estigueu interessats 

podeu completar el que hem exposat en aquest capítol 

consultant les referències següents: History of the OSI 

d’Open Source Initiative (posa l’èmfasi en l’impacte 

en el món empresarial, entre els anys 1998 i 1999) 

o A brief history of free/open source software movement 

de Chris Rasch (que cobreix la història del programari 

lliure fins a l’any 2000) o The origins and future of open 

source software de Nathan Newman 1999 (que se 

centra sobretot en la promoció indirecta que el Govern 

dels Estats Units d’Amèrica ha fet del programari lliure 

o sistemes similars durant les dècades dels setanta i els 

vuitanta). 

31 




apartats 126, 169 i 157] 

ANOTACIONS


ANOTACIONS 



apartat 187] 

32 


2.1. El programari lliure abans del programari lliure 

El programari lliure com a concepte no va aparèixer fins al principi 

dels vuitanta. Tanmateix, se’n pot traçar la història des de bastants 

anys abans. 

2.1.1. I al principi va ser lliure... 

Durant els anys seixanta, el panorama de la informàtica estava do- 

minat pels grans ordinadors, instal·lats fonamentalment en empreses 

i centres governamentals. IBM era el fabricant principal, amb una 

gran diferència sobre els competidors. En aquesta època, quan s’ad- 

quiria un ordinador (maquinari), venia amb el programari incorpor- 

tat i mentre es pagués el contracte de manteniment, es tenia accés al 

catàleg de programari que el fabricant oferia. A més, no era habitual 

la idea que els programes fossin una cosa “separada” des d’un punt 

de vista comercial. 

En aquesta època, el programari sovint es distribuïa juntament amb 

el codi font (moltes vegades només com a codi font), i en general 

sense restriccions pràctiques. Els grups d’usuaris com SHARE (usuaris 

de sistemes IBM) o DECUS (usuaris de DEC) participaven en aquests 

intercanvis, i fins a cert punt els organitzaven. La secció “Algorithms” 

de la revista Communications of the ACM era un altre bon exemple de 

fòrum d’intercanvi. Es podria dir que durant aquests primers anys de la 

informàtica el programari era lliure, almenys en el sentit que els que 

hi tenien accés podien disposar del codi font, i estaven acostumats a 

compartir-lo, a modificar-lo i a compartir-ne les modificacions. En 

paraules de Richard Stallman, referint-se a la situació a l’Institut 

Massachusetts de Tecnologia (en anglès, Massachusetts Institute of 

Technology), un dels llocs amb més penetració d’ús i més prestigi en 

la investigació sobre informàtica en l’època: 

aaa 

“No anomenàvem programari lliure el nostre progra- 

mari perquè aquest terme no existia, però és el que era. 

Quan algú d’una altra universitat o d’una empresa vo- 

lia portar i utilitzar un programa, li ho permetíem amb

aaa 


El 30 de juny del 1969 IBM va anunciar que al començament del 1970 

començaria a vendre part del seu programari per separat. Això va 

representar que els seus clients ja no podien obtenir, inclòs en el preu 

del maquinari, els programes que necessitaven. El programari es va 

començar a percebre com una cosa amb valor intrínsec i, en conse- 

qüència, es va fer cada vegada més habitual restringir escrupolosa- 

ment l’accés als programes, i es van limitar, en la mesura possible 

(tant tècnicament com legalment), les possibilitats que els usuaris tenien 

per a compartir, modificar o estudiar el programari. En altres parau- 

les, es va passar a la situació que encara avui és comuna en el món 

del programari. 

molt de gust. Si veies algú utilitzant un programa inte- 

ressant i poc conegut, sempre li’n podies demanar el 

codi font per veure’l, de manera que el podies llegir, el 

podies canviar, o canibalitzar-ne certes parts per fer-ne 

un programa nou.” 

Suggeriment 

El lector interessat en aquesta època de transició pot 

llegir, per exemple: Larry Welke; Luanne Johnson 

(1998). How the ICP directory began. En aquest article 

Larry Welke comenta com va néixer un dels primers ca- 

tàlegs de programari no lligats a un fabricant, i com en 

aquest procés va descobrir que les empreses estaven 

disposades a pagar per programes no creats pel ma- 

teix fabricant dels ordinadors. 

A mitjan anys setanta era absolutament habitual trobar-se amb pro- 

gramari propietari en qualsevol àmbit informàtic. Això va representar 

un gran canvi cultural entre els professionals que treballaven amb 

programari, alhora que un gran nombre d’empreses florien entorn 

del nou negoci. Encara faltava gairebé una dècada perquè comen- 

cés a aparèixer, de manera organitzada i com a reacció a aquesta 

situació, el que avui coneixem com a programari lliure. 

33 




apartat 119] 

Lectura recomanada 


apartat 203] 

ANOTACIONS


ANOTACIONS 

34 


2.1.2. Anys setanta i principi dels vuitanta 

Fins i tot quan la tendència aclaparadorament majoritària era explorar 

el model de programari propietari, hi havia iniciatives que mostraven 

algunes característiques del que després es consideraria programari 

lliure. Alguna fins i tot va produir programari lliure segons la definició 

que utilitzem avui dia. Entre aquestes iniciatives, es poden destacar 

Spice i TeX, a més del cas molt més complex de UNIX. 

SPICE (Simulation Program with Integrated Circuit Emphasis) és un 

programa desenvolupat a la Universitat de Califòrnia, a Berkeley, 

per a simular les característiques elèctriques d’un circuit integrat. El 

va desenvolupar i posar en el domini públic el seu autor, Donald 

O. Pederson, el 1973. SPICE era originalment una eina docent, i com 

a tal es va estendre ràpidament a moltes universitats de tot el món, 

per la qual cosa el van utilitzar molts estudiants de la que en aquell 

temps era una disciplina de disseny de circuits integrats incipient. 

Com que era de domini públic, SPICE es podia redistribuir, modifi- 

car, estudiar, etc.; fins i tot es podia adaptar a unes necessitats con- 

cretes i vendre aquesta versió com a producte propietari (cosa que 

han fet en la seva història dotzenes de vegades moltes d’empreses). 

Amb aquestes característiques, SPICE tenia totes les paperetes per a 

convertir-se en l’estàndard de la indústria amb les diferents versions. 

I, de fet, això és el que va passar. Segurament aquest va ser el primer 

programa amb característiques de programari lliure que durant un 

temps va monopolitzar un mercat, el dels simuladors de circuits inte- 

grats, i sens dubte ho va poder fer, precisament, perquè tenia aquestes 

característiques (a més de les seves innegables qualitats tècniques). 

Donald Knuth va començar a desenvolupar TeX durant un any sabàtic, 

el 1978. TeX és un sistema de tipografia electrònica molt utilitzat per a 

la producció de documents de qualitat. Des del principi, Knuth va utilit- 

zar una llicència que avui es consideraria de programari lliure. Quan va 

considedar que el sistema era raonablement estable, el 1985, va man- 

tenir aquesta llicència. En aquella època, TeX era un dels sistemes més 

grans i més coneguts que es podia considerar programari lliure. 

2.1.3. Desenvolupament primerenc de UNIX 

UNIX va ser un dels primers sistemes operatius portables, creat origi- 

nalment per Thompson i Ritchie (entre d’altres) als Bell Labs de


l’AT&T. El seu desenvolupament no ha parat des que va néixer, cap 

al 1972, fins avui, amb innombrables variants comercialitzades per, 

literalment, desenes d’empreses. 

Durant els anys 1973 i 1974, UNIX va arribar a moltes universitats i 

centres d’investigació de tot el món, amb una llicència que en permetia 

l’ús per a finalitats acadèmiques. Encara que hi havia certes restricci- 

ons que n’impedien la distribució lliure entre les organitzacions que en 

tenien la llicència, el funcionament va ser molt similar al que es va veu- 

re més tard en moltes comunitats de programari lliure. Els que tenien 

accés a la font de UNIX van tenir un sistema que podien estudiar, mi- 

llorar i ampliar. Juntament amb aquest codi font, va aparèixer una co- 

munitat de desenvolupadors que aviat va començar a girar entorn del 

CSRG (Computer Science Research Center) de la Universitat de Cali- 

fòrnia a Berkeley i que va desenvolupar la seva pròpia cultura, que va 

ser molt important en la història del programari lliure, com veurem 

més endavant. UNIX va ser, fins a cert punt, un assaig primerenc del 

que es va veure amb GNU i Linux; uns anys més tard, UNIX estava 

confinat a una comunitat molt més petita, i era necessària la llicència 

de l’AT&T, però en altres aspectes el seu desenvolupament va ser simi- 

lar (en un món molt menys comunicat). 

Amb el temps, UNIX també va ser un exemple primerenc dels proble- 

mes que podien presentar els sistemes propietaris que a primera vista 

tenien “alguna característica del programari lliure”. Durant el final 

dels setanta, i sobretot durant els vuitanta, l’AT&T va canviar la seva 

política, i l’accés a noves versions de UNIX es va convertir en una cosa 

difícil i cara. La filosofia dels primers anys, que va fer tan popular UNIX 

entre els desenvolupadors, va canviar radicalment, fins al punt que el 

1991 l’AT&T va posar una demanda a la Universitat de Berkeley per 

publicar el codi de BSD UNIX que ells (el CSRG de Berkeley) havien cre- 

at. Però aquesta és una altra història, que reprendrem més endavant. 

2.2. El començament: BSD, GNU 

Tots els escenaris descrits fins ara són, o bé iniciatives individuals, o 

bé no compleixen els requisits del programari lliure. En qualsevol 

cas, fins al principi de la dècada dels vuitanta no van aparèixer, de 

manera organitzada i conscient, els primers projectes per a la creació 

35 


ANOTACIONS


ANOTACIONS 



apartat 187] 



apartat 96] 

36 


de sistemes compostos de programari lliure, i el que probablement és 

més important: els fonaments ètics, legals i fins i tot econòmics, que 

després es continuarien desenvolupant fins avui dia. D’aquesta època 

també és el terme programari lliure. 

2.2.1. Richard Stallman, GNU, FSF: neix el moviment 

del programari lliure 

Al començament del 1984, Richard Stallman, en aquella època em- 

pleat a l’AI Lab del MIT, va deixar la feina per començar el projecte 

GNU. Stallman es considerava un hacker dels que gaudien compar- 

tint les seves inquietuds tecnològiques i el seu codi. Veia amb desgrat 

com la seva negativa a firmar acords d’exclusivitat i no-compartició 

l’estaven convertint en un estrany al seu propi món, i com l’ús de pro- 

gramari propietari en el seu entorn el deixava impotent davant de si- 

tuacions que abans podia resoldre fàcilment. 

La seva idea en abandonar el MIT era construir un sistema de pro- 

gramari complet, de propòsit general, però completament lliure. El 

sistema (i el projecte que s’encarregaria que ho fes realitat) es va dir 

GNU (acrònim recursiu, GNU’s Not UNIX). Encara que des del prin- 

cipi el projecte GNU va incloure en el seu sistema programari ja dis- 

ponible (com TeX, o més endavant, el sistema X Window), quedava 

molt per construir. Richard Stallman va començar per escriure un 

compilador de C (GCC) i un editor (Emacs), tots dos encara en ús (i 

molt populars) avui dia. 

Des del principi del projecte GNU, Richard Stallman estava preocupat 

per les llibertats que tindrien els usuaris del seu programari. Estava in- 

teressat que no només els que rebessin els programes directament del 

projecte GNU, sinó qualsevol que el rebés després de qualsevol nom- 

bre de redistribucions i (potser) modificacions, continués gaudint dels 

mateixos drets (modificació, redistribució, etc.). Per a això, va escriure 

la llicència GPL, probablement la primera llicència de programari 

dissenyada específicament per a garantir que un programa fos lliure 

en aquest sentit. Richard Stallman va anomenar copyleft el mecanis- 

me genèric que utilitzen les llicències tipus GPL per a aconseguir 

aquestes garanties, que avui dia és el nom d’una gran família de lli- 

cències de programari lliure.


Richard Stallman també va fundar la Fundació per al Programari 

Gratuït (en anglès, Free Software Foundation; FSF) a fi d’aconseguir 

fons per al desenvolupament i la protecció del programari lliure, i va 

establir els fonaments ètics del programari lliure, amb documents 

com The GNU Manifesto i Why Software Should Not Have Owners. 

Des del punt de vista tècnic, el projecte GNU va ser concebut com un 

treball molt estructurat i amb metes molt clares. El mètode habitual es 

fomentava en grups relativament petits de persones (habitualment vo- 

luntaris) que desenvolupaven alguna de les eines que després encai- 

xarien perfectament en el trencaclosques complet (el sistema GNU). 

La modularitat de UNIX, en què s’inspirava el desenvolupament, en- 

caixava perfectament en aquesta idea. El mètode de treball implicava 

generalment l’ús d’Internet, però davant l’escassa implantació de la 

Xarxa d’aquells dies, la Fundació per al Programari Gratuït també ve- 

nia cintes en què gravava les aplicacions; probablement va ser una de 

les primeres organitzacions a beneficiar-se econòmicament (encara 

que de manera bastant limitada) de la creació de programari lliure. 

Al començament dels noranta, aproximadament sis anys després de 

néixer, el projecte GNU estava molt a prop de tenir un sistema com- 

plet similar a UNIX. Tot i així, fins aquell moment encara no havia 

produït una de les peces fonamentals: el nucli o kernel del sistema (el 

nucli del sistema operatiu que es relaciona amb el maquinari i per- 

met que tot funcioni). Tanmateix, el programari de GNU era molt po- 

pular entre els usuaris de les diferents variants de UNIX, per aquella 

època el sistema operatiu més usat en les empreses. A més, el pro- 

jecte GNU havia aconseguit ser relativament conegut entre els pro- 

fessionals informàtics, i molt especialment entre els que treballaven 

en universitats. En aquella època, els seus productes ja tenien una 

merescuda reputació d’estabilitat i qualitat. 

2.2.2. El CSRG de Berkeley 

El CSRG (Computer Science Research Group) de la Universitat de 

Califòrnia a Berkeley va ser, des del 1973, un dels centres on més es 

va desenvolupar tot el que estava relacionat amb UNIX durant els 

anys 1979 i 1980. No solament es van portar aplicacions i se’n van 

construir d’altres de noves perquè funcionessin sobre UNIX, sinó que 

es van fer importants millores al nucli, i s’hi va afegir molta funcio- 

37 





ANOTACIONS


ANOTACIONS 

38 


nalitat. Per exemple, durant la dècada dels vuitanta, diversos con- 

tractes de DARPA (que depenia del Ministeri de Defensa dels Estats 

Units d’Amèrica) van finançar la implementació del TCP/IP que ha 

estat considerat fins als nostres dies com la referència dels protocols 

que fan funcionar Internet (vinculant, de passada, el desenvolupa- 

ment d’Internet i l’expansió de les estacions de treball amb UNIX). 

Moltes empreses van utilitzar com a base de les seves versions de 

UNIX els desenvolupaments del CSRG, cosa que va donar lloc a sis- 

temes molt coneguts en l’època, com ara SunOS (Sun Microsystems) 

o Ultrix (Digital Equipment). D’aquesta manera, Berkeley es va con- 

vertir en una de les dues fonts fonamentals de UNIX, juntament amb 

l’”oficial”, AT&T. 

Per a poder utilitzar tot el codi que produïa el CSRG (i el dels col·la- 

boradors de la comunitat UNIX que ells d’alguna manera coordina- 

ven), feia falta la llicència de UNIX de l’AT&T, que cada vegada era 

més difícil (i més cara) d’aconseguir, sobretot si es volia accedir al 

codi font del sistema. Tractant d’evitar una mica aquest problema, el 

juny del 1989 el CSRG va alliberar la part de UNIX relacionada amb 

TCP/IP (la implementació dels protocols en el nucli i les utilitats) que 

no incloïa codi de l’AT&T. Va ser l’anomenada Networking Release 1 

(Net-1). La llicència amb què es va alliberar va ser la famosa llicència 

BSD, que, llevat de certs problemes amb les clàusules sobre obliga- 

cions d’anunci, ha estat sempre considerada com un exemple de lli- 

cència lliure minimalista (que a més de permetre la redistribució 

lliure, també en permetia la incorporació a productes propietaris). A 

més, el CSRG va provar un nou mètode de finançament (que ja pro- 

vava amb èxit l’FSF): venia cintes amb la seva distribució per 1.000 

dòlars. Encara que qualsevol, al seu torn, podia redistribuir el con- 

tingut de les cintes sense cap problema (la llicència ho permetia), el 

CSRG va vendre cintes a milers d’organitzacions i va aconseguir fons 

per continuar desenvolupant. 

Atès l’èxit de la distribució de Net-1, Keith Bostic va proposar rees- 

criure tot el codi que encara quedava del UNIX original de l’AT&T. 

Malgrat l’escepticisme d’alguns membres del CSRG, va fer un 

anunci públic demanant ajuda per fer aquesta tasca, i a poc a poc 

les utilitats reescrites a partir d’especificacions van començar a ar- 

ribar a Berkeley. Mentrestant, el mateix procés es va fer amb el 

nucli, i Berkeley o alguns col·laboradors voluntaris van reescriure


de manera independent la major part del codi que encara no 

s’havia fet. El juny del 1991, i després d’aconseguir el permís de 

l’Administració de la Universitat de Berkeley, es va distribuir la Ne- 

tworking Release 2 (Net-2), amb gairebé tot el codi del nucli i totes 

les utilitats d’un sistema UNIX complet. De nou, tot això es va distri- 

buir sota la llicència BSD, i se’n van tornar a vendre milers de cintes 

al preu de 1.000 dòlars la unitat. 

Només sis mesos després de l’alliberament de Net-2, Bill Jolitz va 

escriure el codi que faltava del nucli perquè funcionés sobre arqui- 

tectura i386 i va alliberar el 386BSD, que es va distribuir per Inter- 

net. A partir d’aquest codi van sorgir, en successió, tots els sistemes 

de la família *BSD. Primer va aparèixer NetBSD, com una recopila- 

ció dels pedaços que s’havien anat portant a la Xarxa per a millorar 

el 386BSD. Més endavant va aparèixer FreeBSD com un intent de 

suportar fonamentalment l’arquitectura i386. Uns quants anys més 

tard es va formar el projecte OpenBSD, que posava l’èmfasi en la 

seguretat. I també hi va haver una distribució propietària a partir de 

Net-2 (encara que era certament original, ja que oferia als seus clients 

tot el codi font com a part de la distribució bàsica), feta de manera 

independent per BSDI. 

En part com a reacció a la distribució feta per BSDI, UNIX System 

Laboratories (USL), subsidiària de l’AT&T que tenia els drets de la 

llicència de UNIX, va posar una demanda judicial, primer contra 

BSDI i després contra la Universitat de Califòrnia. En aquesta de- 

manda els acusava de distribuir sense permís la seva propietat in- 

tel·lectual. Després de diverses maniobres judicials (inclosa una 

contrademanda de la Universitat de Califòrnia contra la USL), la 

Novell va comprar els drets de UNIX a la USL, i el gener del 1994 

va arribar a un acord extrajudicial amb la Universitat de Califòrnia. 

Com a resultat d’aquest acord, el CSRG va distribuir la versió 

4.4BSD-Lite, que de seguida van utilitzar tots els projectes de la fa- 

mília *BSD. Poc després (després d’alliberar fins i tot la versió 

4.4BSD-Lite Release 2), el CSRG va desaparèixer. En aquell mo- 

ment hi va haver qui va témer que això representés el final dels sis- 

temes *BSD, però el temps ha demostrat que encara perduren, 

amb una nova forma de gestió, més típica de projectes lliures. Avui 

dia, els projectes que gestionen la família *BSD són dels més antics 

i consolidats en el món del programari lliure. 

39 


ANOTACIONS


ANOTACIONS 



apartat 149] 

40 


Suggeriment 

La història del desenvolupament de la BSD UNIX, des 

dels seus orígens en una cinta que va portar Bob Fabry a 

Berkeley amb una de les primeres versions del codi de 

Thompson i Ritchie per fer-la funcionar en un PDP-11 que 

van comprar conjuntament els departaments d’informà- 

tica, estadística i matemàtiques, fins a les demandes judi- 

cials de l’AT&T i els últims alliberaments de codi que van 

donar lloc a la família de sistemes operatius lliures 

*BSD, és molt il·lustrativa d’una certa manera de 

desenvolupar programari durant els anys setanta i 

vuitanta. Qui hi estigui interessat pot gaudir de la lectura 

de Marshall Kirk McKusick “Twenty Years of Berkeley 

UNIX. From AT&T-Owned to Freely Redistributable” 

(DiBona i altres, 1999), on es comenten molts detalls 

d’aquesta època. 

2.2.3. Els començaments d’Internet 

Gairebé des que va néixer, a la primeria dels anys setanta, Internet va 

tenir molta relació amb el programari lliure. D’una banda, des dels 

inicis, la comunitat de desenvolupadors que la van construir va tenir 

clars diversos principis que després es farien clàssics en el món del pro- 

gramari lliure. Per exemple, la importància de donar oportunitats als 

usuaris perquè ajudin a depurar els errors o la compartició del codi de 

les implementacions. La importància de BSD UNIX en el seu desenvo- 

lupament (en proporcionar durant els anys vuitanta la implementació 

més popular dels protocols TCP/IP) va fer que molts costums i formes 

de funcionament passessin fàcilment d’una comunitat (la de desenvo- 

lupadors al voltant del CSRG) a una altra (els que estaven construint 

NSFNet, i després simplement Internet), i viceversa. Moltes de les apli- 

cacions bàsiques en el desenvolupament d’Internet com Sendmail (ser- 

vidor de correu) o Bind (implementació del servei de noms) van ser 

lliures i fruit d’aquesta col·laboració entre comunitats. 

Finalment, la comunitat del programari lliure, durant el final dels vui- 

tanta i la dècada dels noranta, va ser una de les primeres a explorar


fins al fons les noves possibilitats que Internet permetia perquè col·la- 

boressin grups geogràficament dispersos. Aquesta exploració va fer 

possible la mateixa existència de la comunitat BSD, l’FSF o el desen- 

volupament de GNU/Linux. 

Un dels aspectes més interessants del desenvolupament d’Internet, 

des del punt de vista del programari lliure, va ser la gestió completa- 

ment oberta dels seus documents i les seves normes. Encara que avui 

ja pugui semblar una mica normal (atès que és l’habitual, per exem- 

ple, a l’IETF o el WWW Consortium), en el seu moment la lliure dis- 

posició de totes les especificacions i documents de disseny, incloses 

les normes que defineixen els protocols, va ser un fet revolucionari 

i fonamental per al desenvolupament d’Internet. Ho podem llegir 

en la referència següent: Michael Hauben; Ronda Hauben (1997). 

Netizens. On the History and Impact of Usenet and the Internet 

(pàg. 106). IEEE Computer Society Press. 

aaa 

Observeu que, gairebé amb tota seguretat, qualsevol desenvolupa- 

dor podria subscriure aquest paràgraf en referir-se al projecte de 

programari lliure en què col·labora. 

En una altra citació [Lawrence Roberts. “The evolution of packet 

switching”. Proceedings of the IEEE (vol. 66, pàg. 267)] podem llegir: 

aaa 

“Aquest procés obert promovia i portava a l’intercanvi 

d’informació. El desenvolupament tècnic només té èxit 

quan es permet que la informació flueixi lliurement i fà- 

cilment entre les parts interessades. La promoció de la 

participació és el principi fonamental que va fer possi- 

ble el desenvolupament de la Xarxa.” 

“Com que ARPANET era un projecte públic que connec- 

tava moltes de les principals universitats i institucions 

d’investigació, els detalls d’implementació i rendiment 

es publicaven àmpliament.” 

41 




apartat 118] 

ANOTACIONS 



apartat 174]


ANOTACIONS 



apartat 145] 

42 


Òbviament, això és el que passa avui dia en els projectes de progra- 

mari lliure, on tota la informació relacionada amb el projecte (i no 

solament la implementació) sol ser pública. 

En aquest ambient, i sobretot fins que Internet es va convertir en un ne- 

goci ja ben entrats els anys noranta, la comunitat d’usuaris i la seva 

relació amb els desenvolupadors era clau. En aquella època moltes 

organitzacions van aprendre a confiar, no en una única empresa pro- 

veïdora del servei de comunicació de dades, sinó en una complexa 

combinació d’empreses de serveis, fabricants d’equips, desenvolupa- 

dors professionals i voluntaris, etc. Les millors implementacions de 

molts programes no eren les que venien amb el sistema operatiu que 

es comprava amb el maquinari, sinó implementacions lliures que rà- 

pidament les substituïen. Els desenvolupaments més innovadors eren 

fruit, no de grans plans d’investigació en empreses, sinó d’estudiants 

o professionals que provaven idees i recollien la realimentació que els 

enviaven centenars d’usuaris que utilitzaven els seus programes lliures. 

Com ja s’ha dit, Internet també va proporcionar les eines bàsiques al 

programari lliure per col·laborar a distància. El correu electrònic, els 

grups de news, els serveis d’FTP anònim (que van ser els primers ma- 

gatzems massius de programari lliure), i més tard els sistemes de 

desenvolupament integrats basats en web han estat fonamentals (i 

imprescindibles) per al desenvolupament de la comunitat del progra- 

mari lliure tal com la coneixem, i en particular per al funcionament 

de la majoria dels projectes de programari lliure. Des del principi, 

projectes com GNU o BSD van fer un ús massiu i intens de tots 

aquests mecanismes i van desenvolupar, alhora que els usaven, ei- 

nes i sistemes nous que, al seu torn, milloraven Internet. 

Suggeriment 

El lector interessat en una història de l’evolució d’Inter- 

net, escrita per uns quants dels seus protagonistes, pot 

consultar la referència següent: Barry M. Leiner; Vinton 

G. Cerf; Robert E. Kahn; David D. Clark; Leonard 

Kleinrock; Daniel C. Lynch; Jon Postel; Larry G. Roberts; 

Stephen Wolff (1997). A brief history of the Internet. 

Communications of the ACM.

2.2.4. Altres projectes 


Durant la dècada dels vuitanta van veure la llum altres projectes lliures 

importants, entre els quals destaca, per la importància i la projecció 

futura, el sistema X Window (sistema de finestres per a sistemes de ti- 

pus UNIX), desenvolupat en el MIT, i que va ser un dels primers exem- 

ples de finançament a gran escala de projectes lliures amb recursos 

d’un consorci d’empreses. També val la pena esmentar Ghostscript, 

un sistema de gestió de documents postscript desenvolupat per una 

empresa, Aladdin Software, que va ser un dels primers casos de recer- 

ca de model de negoci produint programari lliure. 

En general, i sobretot al final dels anys vuitanta, funciona tota una 

sèrie de petits (i no tan petits) projectes lliures. Tots aquests projec- 

tes, juntament amb els grans projectes esmentats fins aquí, ja esta- 

blien les bases dels primers sistemes lliures complets que van 

aparèixer al començament dels noranta. 

2.3. Tot en marxa 

Cap al 1990, gran part dels components d’un sistema informàtic 

complet estaven ja llestos com a programari lliure. D’una banda, el 

projecte GNU i, de l’altra, les distribucions BSD havien completat la 

major part de les aplicacions que componen un sistema operatiu. I 

també projectes com X Window o el mateix GNU havien construït des 

d’entorns de finestres fins a compiladors, que eren dels millors del 

seu gènere (per exemple, molts administradors de sistemes SunOS o 

Ultrix substituïen per als seus usuaris les aplicacions propietàries del 

seu sistema per les versions lliures de GNU o de BSD). Per a tenir un 

sistema complet construït només amb programari lliure, faltava úni- 

cament un component: el nucli. Dos esforços separats i independents 

van omplir aquest buit: 386BSD i Linux. 

2.3.1. A la recerca d’un nucli 

Al final dels vuitanta i principi dels noranta, el projecte GNU disposava 

d’una gamma bàsica d’utilitats i eines que permetien tenir el sistema 

operatiu al complet. Ja llavors moltes aplicacions lliures eren les millors 

43 


ANOTACIONS


ANOTACIONS 



apartat 114] 

44 


en el seu camp (utilitats UNIX, compiladors), d’entre les quals era espe- 

cialment interessant el cas de X Window. Tanmateix, faltava una peça 

essencial per a completar el trencaclosques: el nucli del sistema opera- 

tiu. El projecte GNU buscava aquesta peça amb un projecte anomenat 

Hurd, que pretenia construir un nucli amb tecnologies modernes. 

2.3.2. La família *BSD 

Pràcticament en la mateixa època, la comunitat BSD també estava en el 

camí cap a un nucli lliure. En la distribució Net-2 només faltaven sis fit- 

xers per a tenir-lo (la resta ja havia estat construïda pel CSRG o els seus 

col·laboradors). Al començament del 1992 Bill Jolitz completa aquests 

fitxers i distribueix el 386BSD, un sistema que funciona sobre arquitectu- 

ra i386 i que amb el temps donarà lloc als projectes NetBSD, FreeBSD i 

OpenBSD. El desenvolupament durant els mesos següents és ràpid, i a 

final d’any ja és prou estable per a ser usat en producció en entorns no 

crítics, incloent-hi, per exemple, un entorn de finestres gràcies al projecte 

XFree (que havia portat X Window a l’arquitectura i386) o un compila- 

dor de gran qualitat, el GCC. Encara que hi ha components que usa- 

ven altres llicències (com els procedents del projecte GNU, que usaven 

la GPL), la major part del sistema es distribueix sota la llicència BSD. 

Suggeriment 

Alguns dels episodis d’aquesta època són il·lustratius de 

la potència dels models de desenvolupament de pro- 

gramari lliure. El cas de Linus Torvalds, que va desenvo- 

lupar Linux mentre era estudiant de segon curs de la 

Universitat de Hèlsinki, és ben conegut; però no és l’únic 

cas d’un estudiant que s’ha obert camí gràcies als des- 

envolupaments lliures. Per exemple, Thomas Roel, un 

estudiant alemany, va portar X11R4 (una versió del sis- 

tema X Window) a un PC basat en un 386. Aquest des- 

envolupament el va portar a treballar a Dell, i més 

endavant a ser fundador dels projectes X386 i XFree, bà- 

sics perquè GNU/Linux i els *BSD tinguessin aviat un en- 

torn de finestres. Es pot llegir més sobre la història d’XFree 

i el paper de Roel, a Michael J. Hammel (1991, desem- 

bre). “The history of xfree86”. Linux Magazine.


Després va venir la demanda d’USL, que va propiciar que molts usuaris 

potencials temessin al seu torn ser demandats si la Universitat de Ca- 

lifòrnia perdia el judici, o simplement que el projecte s’aturés. Potser 

aquesta va ser la raó perquè més endavant la base instal·lada de 

GNU/Linux fos molt més gran que la de *BSD combinats. Però 

aquesta qüestió és difícil d’assegurar. 

2.3.3. GNU/Linux entra en escena 

El juliol del 1991 Linus Torvalds (estudiant finlandès de 21 anys) posa 

el primer missatge on esmenta el seu (aleshores) projecte de fer un sis- 

tema lliure similar a Minix. Al setembre allibera la primeríssima versió 

(0.01), i cada poques setmanes van apareixent versions noves. El març 

del 1994 va aparèixer la versió 1.0, la primera que es va anomenar es- 

table, però el nucli que havia construït Linus era utilitzable des de 

força mesos abans. Durant aquest període, literalment centenars de 

desenvolupadors es bolquen sobre Linux, integrant al seu voltant tot 

el programari de GNU, XFree i molts altres programes lliures. A dife- 

rència dels *BSD, Linux (el nucli) i gran part dels components que s’hi 

integren al voltant es distribueixen amb la llicència GPL. 

Suggeriment 

La història de Linux és probablement una de les més in- 

teressants (i conegudes) en el món del programari lliure. 

Qui hi estigui interessat pot trobar molts enllaços a la in- 

formació sobre aquesta història en les pàgines comme- 

moratives del desè aniversari de l’anunci, http:// 

www.linux10.org/history/, encara que segurament la 

més interessant és Ragib Hasan. History of Linux. Com a 

curiositat, es pot consultar l’arxiu en què Linus Torvalds 

anunciava que començava a crear el que després va ser 

Linux (en el grup de news comp.os.minix) a http:// 

groups.google.comgroups?th=d161e94858c4c0b9. 

Aquí explica que treballa en el seu nucli des de l’abril, i 

que ja hi ha portat algunes eines del projecte GNU (con- 

cretament, esmenta bash i gcc). 

45 




apartat 117] 

ANOTACIONS


ANOTACIONS 

46 


Entre els molts desenvolupaments apareguts entorn de Linux, un dels 

més interessants és el concepte de distribució. Els primers ja van apa- 

rèixer el 1992 (MCC Interim Linux, de la Universitat de Manchester, 

TAMU, de Texas A&M, i el més conegut SLS, que més tard va donar 

lloc a Slackware, que encara es distribueix avui dia), i han representat 

l’entrada de la competència al món de l’empaquetatge de sistemes 

entorn de Linux. Cada distribució tracta d’oferir als seus usuaris ob- 

jectiu un GNU/Linux preparat per a ser utilitzat, i basant-se totes en 

el mateix programari, han de competir en millores que la seva base 

d’usuaris consideri importants. A més de proporcionar paquets pre- 

compilats i preparats per a utilitzar, les distribucions solen oferir les 

seves pròpies eines per gestionar la selecció, instal·lació, substitució 

i desinstal·lació d’aquests paquets, la instal·lació inicial en un ordi- 

nador i la gestió i administració del sistema operatiu. 

Amb el temps, unes distribucions n’han anat succeint unes altres com 

a més populars. Entre totes, en podem destacar algunes: 

• Debian 

• Red Hat 

• SuSE 

• Mandrake 

2.4. Temps excitants 

Des que GNU/Linux té una presència habitual en els mitjans, des que 

la majoria d’empreses utilitza programari lliure almenys per a alguns 

dels seus processos informàtics i des que és difícil ser un estudiant 

d’informàtica i no utilitzar programari lliure en grans quantitats, és 

clar que tot això ja no és un assumpte d’uns quants “setciències”, sinó 

que s’està convertint en una cosa molt important per al sector. En el 

fons batega una pregunta molt important: Estem davant d’un nou 

model d’indústria de programari? Perquè tot això del programari 

lliure podria ser una moda passatgera, que amb el temps només es re- 

cordarà amb nostàlgia, o bé un model nou que és aquí per a estar-s’hi, 

i potser per a canviar radicalment una de les indústries més joves, però 

també de les més influents.

2.4.1. Final dels noranta 


A mitjan dècada dels noranta el programari lliure ofereix entorns 

complets (distribucions de GNU/Linux, sistemes *BSD) que perme- 

ten la feina diària de molta gent, sobretot de desenvolupadors de 

programari. Encara hi ha assignatures pendents (la més urgent és 

millorar les interfícies gràfiques d’usuari en una època en què Win- 

dows 95 es considera l’estàndard), però també uns quants milers de 

persones a tot el món només usen programari lliure en la seva feina 

diària. Els anuncis de nous projectes se succeeixen i el programari 

lliure comença el llarg camí d’expansió cap a les empreses, els mit- 

jans de comunicació i el coneixement públic en general. 

També és d’aquesta època l’arrencada d’Internet com a xarxa per a 

tots, moltes vegades de la mà de programes lliures (sobretot en la in- 

fraestructura). L’arribada de la Xarxa a les llars de milions d’usuaris 

finals consolida aquesta situació, almenys pel que fa als servidors: els 

servidors web (HTTP) més populars sempre han estat lliures (primer 

el servidor de l’NCSA, després l’Apache). 

Potser el començament del camí del programari lliure fins a la seva 

posada de llarg en la societat es podria situar en el cèlebre assaig 

d’Eric Raymond, “La catedral i el basar”. Encara que molt del que s’hi 

exposava ja era ben conegut per la comunitat de desenvolupadors 

de programari lliure, el fet d’escriure-ho en un article i donar-hi una 

gran difusió fora de la comunitat “tradicional” el va convertir en una 

eina de promoció influent del concepte de programari lliure com a me- 

canisme de desenvolupament alternatiu al que utilitzava la indústria del 

programari tradicional. Un altre article molt important d’aquesta època 

va ser “Setting Up Shop: The Business of Open-Source Software”, de 

Frank Hecker, que per primera vegada va exposar els models de nego- 

ci possibles entorn del programari lliure i que va escriure per influir en 

la decisió sobre l’alliberament del codi del navegador de Netscape. 

De fet, si l’article de Raymond va representar una gran eina de difu- 

sió d’algunes de les característiques fonamentals del programari lliu- 

re, l’alliberament del codi del navegador de Netscape va ser el 

primer cas en què una empresa relativament gran d’un sector molt 

innovador (la llavors naixent indústria del web) prenia la decisió 

d’alliberar com a programari lliure un dels seus productes. En aque- 

47 




apartats 171, i 120] 

ANOTACIONS


ANOTACIONS 

48 


lla època, el Netscape Navigator estava perdent la batalla dels na- 

vegadors enfront del producte Internet Explorer de Microsoft, en part 

per les tàctiques de Microsoft de combinar-lo amb el seu sistema 

operatiu. Per a molts, Netscape va fer l’únic que podia fer: tractar de 

canviar les regles per poder competir amb un gegant. I d’aquest can- 

vi de regles (tractar de competir amb un model de programari lliure) 

va néixer el projecte Mozilla. Aquest projecte, no sense problemes, 

ha portat uns quants anys després a un navegador que, si bé no ha 

recuperat una part significativa de l’enorme quota de mercat que va 

tenir al seu dia el Netscape Navigator, sembla que tècnicament és al- 

menys tan bo com els competidors propietaris (inclòs el mateix Inter- 

net Explorer). 

En qualsevol cas, i amb independència de l’èxit posterior, l’anunci de 

Netscape d’alliberar el codi del Navigator va representar un fort im- 

pacte en la indústria del programari. Moltes empreses van començar 

a considerar el programari lliure com una qüestió digna d’estudi, i 

que podria interessar-los molt. 

Els mercats financers també es van començar a ocupar del progra- 

mari lliure. En plena eufòria de les puntcom, diverses empreses de 

programari lliure es converteixen en objectiu dels inversors. Potser 

el cas més conegut és el de Red Hat, una de les primeres empreses 

que van reconèixer que la venda de CD amb sistemes GNU/Linux 

preparats per a utilitzar-los podia ser un model de negoci. Red Hat 

va començar distribuint Red Hat Linux amb gran èmfasi (almenys 

per al que era habitual en l’època) en la facilitat d’utilització i el 

manteniment del sistema per persones sense coneixements especí- 

fics d’informàtica. 

Amb el temps, Red Hat va anar diversificant el negoci, mantenint- 

se en general en l’òrbita del programari lliure, i el setembre del 

1998 va anunciar que Intel i Netscape hi havien invertit. “Si és bo 

per a Intel i Netscape, segur que és bo per a nosaltres”, devien pen- 

sar molts inversors. I així, quan Red Hat va sortir a borsa l’estiu del 

1999, l’oferta pública d’accions va ser subscrita completament i 

aviat el valor de cada títol va pujar com l’escuma. Va ser la primera 

vegada que una empresa va aconseguir finançament del mercat de 

valors amb un model basat en el programari lliure. Però no va ser 

l’únic: aviat el van seguir d’altres com VA Linux o Andover.net

. 

Suggeriment 


Red Hat proporciona una llista de fites històriques re- 

lacionades amb la seva empresa amb motiu del desè 

aniversari (1993-2003) a 

http://www.redhat.com/ mktg/rh10year/ 

En aquesta època també neixen moltes empreses basades en models 

de negoci entorn del programari lliure. Sense sortir a borsa ni acon- 

seguir capitalitzacions formidables, han estat tanmateix molt impor- 

tants per al desenvolupament del programari lliure. Per exemple, van 

aparèixer moltes altres empreses que van començar distribuint versions 

pròpies de GNU/Linux, com SuSE (Alemanya), Conectiva (Brasil) o 

Mandrake (França). D’altres proporcionen serveis a empreses que ja 

demanen manteniment i adaptació de productes lliures: LinuxCare 

(EUA), Alcove (França), ANEU Pro (Alemanya), i moltes més. 

Per la seva banda, els gegants del sector també comencen a posici- 

onar-se davant del programari lliure. Algunes empreses, com IBM, 

l’incorporen directament a la seva estratègia. D’altres, com Sun 

Microsystems, hi mantenen una relació curiosa, de vegades de su- 

port, de vegades d’indiferència, de vegades d’enfrontament. La majo- 

ria (com Apple, Oracle, HP, SGI, etc.) exploren el model del programari 

lliure amb diverses estratègies, que van des de l’alliberament selectiu de 

programari fins a la simple aportació a Linux dels seus productes, pas- 

sant per tot un espectre d’actuacions, com l’ús més o menys intensiu de 

programari lliure en els seus productes o l’exploració de models de ne- 

goci basats en el servei de suport a productes lliures. 

Des del punt de vista tècnic, el més destacable d’aquesta època és, se- 

gurament, l’aparició de dos ambiciosos projectes amb l’objectiu d’acon- 

seguir portar el programari lliure a l’entorn d’escriptori (desktop) dels 

usuaris no gaire versats en la informàtica: KDE i GNOME. L’objectiu 

final era, dit d’una manera molt simplista, que no calgués fer servir la 

línia d’ordres per a interaccionar amb GNU/Linux o *BSD, ni amb els 

programes sobre aquests entorns. 

49 


ANOTACIONS


ANOTACIONS 



apartat 82] 



apartats 185, 85 i 98] 

50 


L’entorn KDE va ser anunciat l’octubre del 1996. Utilitzant les biblio- 

teques gràfiques Qt (en aquell temps, un producte propietari de l’em- 

presa Troll Tech, però gratuït per a fer-lo sevir sobre Linux), van 

iniciar la construcció d’un conjunt d’aplicacions d’escriptori que funci- 

onessin de manera integrada i presentessin un aspecte uniforme. El ju- 

liol del 1998 van alliberar la versió 1.0 del K Desktop Environment, 

que aviat va ser seguida per noves versions cada vegada més com- 

pletes i madures. Les distribucions de GNU/Linux aviat van incorpo- 

rar KDE com a escriptori per als seus usuaris (o almenys com un dels 

entorns d’escriptori que els seus usuaris podien triar). 

Sobretot, com a reacció a la dependència que tenia KDE de la biblio- 

teca propietària Qt, l’agost del 1997 s’anuncia el projecte GNOME, 

amb objectius i característiques molt similars a les del KDE, però amb 

l’objectiu explícit que tots els components siguin lliures. El març del 1999 

es va alliberar GNOME 1.0, que també s’aniria millorant i estabilitzant 

amb el temps. A partir d’aquell moment, la majoria de les distribucions 

de sistemes operatius lliures (i molts derivats de UNIX propietaris) van 

oferir com a opció l’escriptori de GNOME o el de KDE, i les aplicacions 

de tots dos entorns. 

Simultàniament, els principals projectes de programari lliure que ja 

funcionaven continuen amb bona salut i sorgeixen projectes nous 

cada dia. A diversos nínxols de mercat s’observa com la millor solu- 

ció (reconeguda per gairebé tothom) és el programari lliure. Per 

exemple, Apache ha mantingut gairebé des de la seva aparició 

l’abril del 1995 la quota de mercat més gran entre els servidors web. 

XFree86, el projecte lliure que desenvolupa X Window, és la versió de 

X Window més popular, amb diferència (i per tant, el sistema de fi- 

nestres per a sistemes de tipus UNIX més estès). GCC és reconegut 

com el compilador de C més portable i un dels de més qualitat. GNAT, 

sistema de compilació per a Ada 95, abasta la major part del mercat 

de compiladors Ada en pocs anys. I així successivament... 

El 1998 es va crear l’Open Source Initiative (OSI), que va decidir 

adoptar el terme open source software (‘programari de font oberta’) 

com una marca per a introduir el programari lliure al món comercial, 

i tractar d’evitar l’ambigüitat que en anglès representa el terme free 

(que significa tant ‘lliure’ com ‘gratis’). Aquesta decisió va ser (i en- 

cara és) un dels debats més enverinats del món del programari lliure,


ja que la Free Software Foundation i d’altres van considerar que era 

molt més apropiat parlar de programari lliure. En qualsevol cas, 

l’OSI va fer una fructífera campanya de difusió de la seva nova mar- 

ca, que ha estat adoptada per molts com la manera preferida de 

parlar del programari lliure, sobretot en el món anglosaxó. L’OSI va 

utilitzar com a definició de programari de font oberta una accepció 

derivada de la que fa servir el projecte Debian per a definir el pro- 

gramari lliure (que, d’altra banda, en reflecteix bastant aproximada- 

ment la idea de l’FSF), de manera que, des del punt de vista pràctic, 

gairebé qualsevol programa que es considera programari lliure tam- 

bé es considera de font oberta, i a l’inrevés. Tanmateix, les comuni- 

tats del programari lliure i del programari de font oberta (o almenys 

les persones que s’identifiquen com a part d’una o d’una altra) po- 

den ser profundament diferents. 

2.4.2. Principi del 2000 

A la primeria de la dècada de l’any 2000, el programari lliure és un 

seriós competidor en el segment dels servidors i ja comença a estar 

llest per a l’escriptori. Sistemes com GNOME 2.x, KDE 3.x i OpenOf- 

fice poden ser utilitzats per usuaris domèstics i són suficients per a les 

necessitats de moltes empreses, almenys pel que fa a l’ofimàtica. Els 

sistemes lliures (i fonamentalment els basats en GNU/Linux) són fà- 

cils d’instal·lar, i la complexitat de mantenir-los i actualitzar-los és 

comparable a la d’altres sistemes propietaris (inclòs Windows). 

En aquests moments, qualsevol empresa de la indústria del progra- 

mari té una estratègia respecte al programari lliure. La majoria de 

les grans multinacionals (IBM, HP, Sun, Corel, Apple, Oracle) incor- 

pora el programari lliure amb més o menys decisió. En un extrem po- 

dríem situar empreses com per exemple, Oracle, que reaccionen 

simplement portant els seus productes a GNU/Linux. En l’altre es po- 

dria situar IBM, que té l’estratègia més decidida i ha fet les campa- 

nyes més grans de publicitat sobre Linux. Entre els líders del mercat 

informàtic, només Microsoft ha destacat amb una estratègia clara- 

ment contrària al programari lliure, i en particular, al programari dis- 

tribuït sota llicència GPL. 

Quant al món del programari lliure en si mateix, malgrat els debats 

que de tant en tant sacsegen la comunitat, el creixement és enorme. 

51 


ANOTACIONS


ANOTACIONS 

52 


Cada vegada hi ha més desenvolupadors, més projectes de progra- 

mari lliure actiu, més usuaris, etc. El programari lliure està passant 

de ser una cosa marginal a convertir-se en un competidor que cal te- 

nir cada vegada més en compte. 

Davant d’aquest desenvolupament, apareixen noves disciplines que 

estudien específicament el programari lliure, com l’enginyeria del 

programari lliure. A partir de les seves investigacions, a poc a poc co- 

mencem a entendre com funciona en els diferents aspectes: models 

de desenvolupament, de negoci, mecanismes de coordinació, gestió de 

projectes lliures, motivació de desenvolupadors, etc. 

En aquests anys també es comencen a veure els primers efectes de la 

deslocalització que permet el desenvolupament de programari lliure: 

països considerats com a perifèrics participen en el món del progra- 

mari lliure de manera molt activa. Per exemple, és significatiu el 

nombre de desenvolupadors mexicans o espanyols (tots dos països 

amb poca tradició d’indústria de programari) en projectes com 

GNOME [lancashire:code-culture-cash]. I sens dubte és encara més 

interessant el paper del Brasil, amb empreses com Conectiva, una 

gran quantitat de desenvolupadors i experts en tecnologies de pro- 

gramari lliure i un suport decidit per part de les administracions pú- 

bliques. Menció a part mereix el cas de LinEx, molt significatiu de com 

una regió amb poca tradició de desenvolupament de programari pot 

tractar de canviar la situació amb una estratègia agressiva d’implan- 

tació de programari lliure. 

Des del punt de vista de la presa de decisions a l’hora d’implantar 

solucions de programari, cal destacar que hi ha certs mercats (com 

els serveis d’Internet o l’ofimàtica) on el programari lliure s’ha con- 

vertit en una opció natural, i és difícil de justificar el fet de no consi- 

derar-la quan s’estudia quin tipus de sistema cal fer servir. 

Com a aspecte negatiu, aquests anys han vist de quina manera l’entorn 

legal en què es mou el programari lliure està canviant ràpidament a tot 

el món. D’una banda, les patents de programari (patents de programa- 

ció) es consideren cada vegada més a més països. De l’altra, les noves 

lleis de protecció de drets d’autor dificulten o impedeixen el desenvolu- 

pament d’aplicacions lliures en alguns àmbits, el més conegut d’entre 

els quals és el dels visors de DVD (a causa de l’algoritme CSS d’ofusca- 

ció d’imatges que s’utilitza en aquesta tecnologia).

LinEx 


Al començament de 2002 la Junta d’Extremadura va donar a co- 

nèixer públicament el projecte LinEx. La idea és simple: promoure 

la creació d’una distribució basada en GNU/Linux amb l’objectiu 

fonamental d’utilitzar-la en els milers d’ordinadors que instal·larà en 

els centres educatius públics de tota la regió. Extremadura, situada a 

la part occidental d’Espanya, fronterera amb Portugal, té aproxima- 

dament un milió d’habitants i mai no s’ha destacat per les iniciatives 

tecnològiques. De fet, aquesta regió pràcticament no té indústria de 

programari. 

En aquest context, LinEx ha representat una aportació molt interessant 

en el panorama del programari lliure a escala mundial. Molt més enllà 

de ser una distribució de GNU/Linux nova basada en Debian (circums- 

tància que no deixa de ser relativament anecdòtica), i més enllà de 

l’enorme impacte que ha tingut en mitjans de comunicació (és la prime- 

ra vegada que Extremadura ha sortit a la portada del Washington Post, 

i una de les primeres que ho ha fet un producte de programari lliure, 

per exemple), l’extraordinari és la (almenys aparentment) sòlida aposta 

d’una administració pública pel programari lliure. La Junta d’Extrema- 

dura ha decidit provar un model diferent en l’ensenyament d’informà- 

tica, i a mitjà termini, segurament en el mateix ús de la informàtica 

dins de les seves competències. Aquest fet la converteix en la primera 

administració pública d’un país desenvolupat que pren decididament 

aquest camí. Arran de la iniciativa de la Junta ja es comença a produir 

moviment, tant dins com fora d’Extremadura: hi ha acadèmies que 

ensenyen informàtica amb LinEx, s’han escrit llibres per a donar su- 

port a aquest ensenyament i hi ha ordinadors que es venen amb LinEx 

preinstal·lat. En general, entorn d’aquesta experiència s’intenta crear 

tot un teixit docent i empresarial que hi doni suport. Així mateix, s’està 

començant a exportar l’experiència: la Junta d’Andalusia (vuit milions 

d’habitants) ja ha anunciat GuadaLinex, una iniciativa fins a cert punt 

similar. 

KNOPPIX 

Des del final dels anys noranta hi ha distribucions de GNU/Linux que 

s’instal·len fàcilment, però segurament KNOPPIX, la primera versió 

del qual va aparèixer el 2002, ha portat aquest concepte a la seva 

53 


ANOTACIONS


ANOTACIONS 

54 


màxima expressió. Un CD que arrenca pràcticament en qualsevol PC 

i el converteix (sense haver de formatar el disc, ja que en permet l’ús 

“en viu”) en una màquina GNU/Linux completament funcional, amb 

una selecció de les eines més habituals. KNOPPIX uneix una bona 

detecció automàtica de maquinari amb una bona selecció de pro- 

grames i un funcionament “en viu”. Permet, per exemple, una ex- 

periència ràpida i directa del que pot representar treballar amb 

GNU/Linux. I està donant lloc a tota una família de distribucions del 

mateix tipus, especialitzades en necessitats específiques d’un perfil 

d’usuaris concret. 

OpenOffice.org 

El 1999 Sun Microsystems va comprar una empresa alemanya ano- 

menada StarDivision, que tenia un producte estrella: l’StarOffice, un 

paquet ofimàtic d’eines similar en funcionalitat a l’Office, el paquet 

ofimàtic de Microsoft. Un any més tard, Sun va distribuir gran part 

del codi de l’StarOffice sota una llicència lliure (la GPL), fet que va 

donar lloc al projecte OpenOffice.org. Aquest projecte va alliberar la 

versió 1.0 de l’OpenOffice.org el maig del 2002. L’OpenOffice.org 

s’ha convertit en un joc d’aplicacions ofimàtiques de qualitat i funcio- 

nalitat similars a les de qualsevol altre producte ofimàtic, i el que és 

més important, opera molt bé amb els formats de dades d’MS Office. 

Aquestes característiques l’han convertit en l’aplicació de referència 

del programari lliure en el món de l’ofimàtica. 

La importància de l’OpenOffice.org, des del punt de vista d’extensió 

del programari lliure a un gran nombre d’usuaris, és enorme. Per fi, 

ja es pot canviar, pràcticament sense traumes, dels entorns propietaris 

habituals en ofimàtica (sens dubte l’aplicació estrella en el món em- 

presarial) a entorns completament lliures (per exemple, GNU/Linux 

més Gnome i/o KDE més OpenOffice.org). 

Mozilla, Galeon i els altres 

Pràcticament des de la seva aparició el 1994 fins al 1996, Netscape 

Navigator va ser el líder indiscutible del mercat de navegadors web, 

amb quotes de mercat de fins al 80%. La situació va començar a 

canviar quan Microsoft va incloure l’Internet Explorer en el seu


Windows 95, la qual cosa va representar que a poc a poc anés 

perdent quota de mercat. Al començament de 1998 Netscape va 

anunciar que estava a punt de distribuir gran part del codi del Navigator 

com a programari lliure, cosa que efectivament va fer el març del 

mateix any llançant el projecte Mozilla. Durant bastant de temps el 

projecte va estar envoltat d’incertesa, i fins i tot de pessimisme (per 

exemple, quan el líder del projecte, Jamie Zawinski, el va abando- 

nar), ja que el temps passava i no apareixia cap producte com a re- 

sultat del seu llançament. 

El gener del 2000, el projecte va alliberar Mozilla M13, que es va 

considerar com la primera versió raonablement estable. Però només 

el maig del 2002 es va publicar la versió 1.0, la primera oficialment 

estable, més de quatre anys després de l’alliberament del primer codi 

del Navigator. 

Suggeriment 

A Brian Wilson (Netscape navigator) es pot consultar 

una ressenya detallada de les principals versions del 

Netscape Navigator i el Mozilla, i també de les seves 

característiques principals. 

Per fi, Mozilla era una realitat. Encara que potser massa tard, tenint 

en compte les quotes de mercat que presenta durant el període 

2002-2003 l’Internet Explorer (líder indiscutible del mercat, que ha 

relegat Mozilla i els altres a una posició completament marginal). 

Però el projecte Mozilla, malgrat trigar tant, ha donat els seus fruits. 

No només els que es podien esperar (el navegador Mozilla), sinó 

molts altres que es podrien considerar “col·laterals”, com per exem- 

ple Galeon, un altre navegador basat en el mateix motor d’HTML. 

Mozilla ha ajudat a completar un gran buit en el món del programari 

lliure. Abans de l’aparició de Konqueror (el navegador del projecte 

KDE), no hi havia gaires navegadors lliures amb interfície gràfica. A 

partir de la publicació de Mozilla, ha anat apareixent una gran quan- 

titat de projectes que s’hi basen i que han produït una bona quantitat 

de navegadors. D’altra banda, la combinació de Mozilla més 

OpenOffice permet usar programari lliure per a les tasques més 

55 




apartat 211] 

ANOTACIONS


ANOTACIONS 

56 


quotidianes fins i tot en un entorn Windows (tots dos funcionen, no so- 

lament sobre GNU/Linux, *BSD i altres sistemes tipus UNIX, sinó tam- 

bé sobre Windows). Això permet que, per primera vegada en la 

història del programari lliure, la transició de programari propietari a 

lliure en entorns d’oficina sigui simple: es pot començar utilitzant 

aquestes dues aplicacions sobre Windows, sense canviar de sistema 

operatiu (en el cas dels que l’usen habitualment), i amb el temps eli- 

minar l’única peça no lliure passant a GNU/Linux o a FreeBSD. 

2.5. El futur: una cursa d’obstacles? 

Sens dubte, és difícil predir el futur. I no cal dir que aquí no ens hi de- 

dicarem. Per tant, més que tractar d’explicar com serà el futur del pro- 

gramari lliure, tractarem d’ensenyar els problemes que previsiblement 

haurà d’afrontar (i de fet ja fa temps que afronta). La situació que tin- 

drà el món del programari lliure d’aquí a uns quants anys dependrà 

de la capacitat que tingui de superar aquests obstacles. 

• Tècnica FUD (fear, uncertainity, doubt, o en català, ‘por’, ‘desco- 

neixement’, ‘dubte’). Són tècniques bastant habituals en el món 

de les tecnologies de la informació i que fins avui han fet servir els 

competidors de productes de programari lliure per a tractar de 

desacreditar-los, amb més o menys raó i amb èxit variable. En lí- 

nies generals, el programari lliure, potser a causa de la comple- 

xitat i dels diversos mètodes de penetració en les empreses, ha 

resultat bastant immune a aquestes tècniques. 

• Dissolució. Moltes empreses estan provant els límits del programari 

lliure com a model, i en particular, tracten d’oferir als seus clients 

models que presenten algunes característiques similars al progra- 

mari lliure. El principal problema que pot presentar aquest tipus de 

models és la confusió que generen en els clients i desenvolupadors, 

que han d’estudiar amb molt de detall la lletra petita per tal d’ado- 

nar-se que el que se’ls està oferint no té els avantatges que per a 

ells representa el programari lliure. El cas més conegut de models 

d’aquest tipus és el programa Shared Source de Microsoft. 

• Desconeixement. Moltes vegades, els usuaris arriben al progra- 

mari lliure simplement perquè creuen que és gratis. O perquè el


consideren de moda. Si no aprofundeixen més enllà, i estudien 

amb cert deteniment els avantatges que els pot oferir el progra- 

mari lliure com a model, corren el risc de no aprofitar-se’n. Moltes 

vegades, els supòsits de partida en el món del programari lliure 

són tan diferents dels habituals en el món del programari propie- 

tari que cal fer una mínima anàlisi per a comprendre que el que 

és habitual en un cas, pot ser impossible en l’altre, i viceversa. El 

desconeixement, per tant, no pot sinó generar insatisfaccions i 

pèrdua d’oportunitats en qualsevol persona i organització que 

s’aproximi al programari lliure. 

• Impediments legals. Sens dubte aquest és el principal problema 

amb què el programari lliure es trobarà en els pròxims anys. Enca- 

ra que l’entorn legal on es va desenvolupar durant la dècada dels 

vuitanta i la primera meitat de la dels noranta no era ideal, al- 

menys deixava prou espai perquè creixés en llibertat. Des de lla- 

vors, l’extensió de l’àmbit de la patentabilitat al programari (que 

s’ha produït en molts països desenvolupats) i les noves legislaci- 

ons sobre drets d’autor, que limiten la llibertat de creació del 

desenvolupador de programari, representen barreres cada vegada 

més altes a l’entrada del programari lliure en segments importants 

d’aplicacions. 

2.6. Algunes dates de la història del programari 

lliure 

Aquesta és només una llista de dates que es podrien considerar com 

a importants en la història del programari lliure. Està basada en la 

que apareix a Working Group on Free Software (1999), Free Software / 

Open Source: Information Society Opportunities for Europe?, i s’hi 

ofereix l’Open Source Initiative, que no pretén ser completa: segur 

que moltes dates importants no hi apareixen. Tanmateix, és molt pro- 

bable que ofereixi una visió prou completa del panorama històric de 

l’evolució del món del programari lliure. 

Dècades del 1950 i 1960: 

El programari es distribueix amb el seu codi font i sense restric- 

cions en grups d’usuaris com SHARE (IBM) i DECUS (DEC). 

57 





ANOTACIONS


ANOTACIONS 

58 


1969, abril: 

Es publica l’RFC número 1, que descriu la primera Internet (lla- 

vors ARPANET). La lliure disposició de les RFC, i en particular 

de les especificacions dels protocols utilitzats a Internet, va ser 

un factor clau del seu desenvolupament. 

1970, gener: 

IBM comença a vendre el seu programari per separat, fet que 

dóna lloc al començament de la indústria del programari pro- 

pietari. 

1972: 

UNIX comença a distribuir-se en universitats i centres d’investi- 

gació. 

1973: 

UNIX arriba a la Universitat de Califòrnia a Berkeley. Comença 

la història de BSD UNIX. 

1973: 

Donald O. Pederson posa SPICE a disposició del domini públic. 

Amb el temps es convertirà en la referència en el seu camp (si- 

muladors de circuits integrats). 

1978: 

Donald Knuth, de la Universitat de Stanford, comença a treba- 

llar en TeX, un sistema de composició electrònica que es distri- 

bueix com a programari lliure. 

1983: 

Richard Stallman escriu el Manifest de GNU, on demana la tor- 

nada a la compartició pública de programari. 

1984: 

Comença el projecte GNU. Els desenvolupadors que hi col·la- 

boren, inicialment coordinats per Richard Stallman, comencen 

a crear un gran nombre d’eines similars a les que hi havia a 

UNIX, incloent-hi un editor (Emacs) i un compilador (GCC). La 

meta és construir un sistema operatiu completament lliure.


X Consortium, basat en el MIT, distribueix el sistema X Window 

com a programari lliure, sota una llicència molt poc restrictiva. 

1985: 

Richard Stallman funda la Free Software Foundation. Entre al- 

tres finalitats, funcionarà com un centre receptor de fons i re- 

cursos que ajudin al desenvolupament del projecte GNU, i com 

a amo de la propietat intel·lectual generada pel projecte. 

1989: 

Es funda Cygnus, la primera empresa dedicada fonamental- 

ment a proporcionar serveis comercials per al programari lliu- 

re (entre els quals hi ha suport, desenvolupament i adaptació 

de programes lliures). 

1990: 

La Free Software Foundation anuncia el seu intent de construir 

un nucli que es dirà GNU Hurd. La meta d’aquest projecte és 

completar el buit més gran que queda en l’estratègia del pro- 

jecte GNU de construir un sistema operatiu complet. 

1991: 

William i Lynne Jolitz escriuen una sèrie a Dr. Dobbs Journal so- 

bre com portar BSD UNIX a PC basats en i386. 

1991, agost: 

Linus Torvalds, estudiant d’informàtica finlandès de vint-i-un anys 

anuncia que ha començat a treballar en un nucli de tipus UNIX 

lliure, usant eines de GNU, com GCC. La seva meta en aquella 

època és construir un Minix lliure. 

1991, octubre: 

Linus Torvalds allibera la primera versió del seu nucli, encara 

molt primitiva, que s’anomena Linux. 

1992: 

L’Exèrcit de l’Aire dels Estats Units d’Amèrica concedeix un con- 

tracte a la Universitat de Nova York per construir un compila- 

dor lliure per a la nova versió d’Ada (en l’època, llenguatge 

d’ús gairebé obligat en els contractes amb l’Exèrcit dels Estats 

59 


ANOTACIONS


ANOTACIONS 

60 


Units d’Amèrica), Ada 95. L’equip de la NYU escull GNU GCC 

per a la generació de codi, i anomena el seu compilador GNAT 

(GNU NYU Ada 95 Translator). 

1992, juliol: 

William i Lynne Jolitz alliberen 386BSD 0.1, que amb el temps do- 

narà lloc als projectes NetBSD, FreeBSD, i més tard, OpenBSD. 

1993: 

Es funda SuSE a Alemanya, que comença els negocis distribuint 

Slackware Linux traduït a l’alemany. 

1993, agost: 

Ian Murdock comença una nova distribució basada en Linux, 

anomenada Debian GNU/Linux. Es convertirà en la distribució 

construïda per desenvolupadors voluntaris amb més partici- 

pants. 

1993, desembre: 

FreeBSD 1.0, una de les primeres distribucions estables des- 

cendents del 386BSD dels Jolitz, s’allibera a Internet. 

1994: 

L’empresa Ada Core Technologies és fundada pels desenvolu- 

padors de GNAT, amb l’objectiu d’assegurar-ne el desenvolu- 

pament i l’evolució futures i amb un model de negoci basat a 

oferir serveis entorn del compilador i dels seus clients (i no a 

vendre el compilador, que continua essent programari lliure). 

Amb el temps, GNAT es convertirà en el líder del mercat de 

compiladors Ada. 

1994, gener: 

S’allibera la versió 0.91 de Debian GNU/Linux, fruit de l’esforç 

de dotze desenvolupadors. 

1994: 

Marc Ewing comença la distribució Red Hat Linux. Com en el 

cas de Debian, tracta de millorar els resultats de la distribució 

dominant a l’època, Slackware.

1994, març: 


Es publica el primer número de la revista Linux Journal. 


Alliberament de NetBSD 1.0. 

1995: 

Bob Young funda Red Hat Software després de comprar la distri- 

bució Red Hat Linux al seu autor Marc Ewing i de fusionar-la amb 

el seu propi negoci, l’ACC, que venia materials relacionats amb 

Linux i UNIX per catàleg des del 1993. Poc després es publica Red 

Hat Linux 2.0, la primera que inclou el format de paquets RPM. 

1995, gener: 

Alliberament de FreeBSD 2.0. 

1995, abril: 

Primer alliberament oficial d’Apache (0.6.2). 

1996: 

First Conference on Freely Redistributable Software (primer 

congrés sobre programari de lliure redistribució). Cambridge, 

Massachusetts, Estats Units d’Amèrica. 


Anunci del projecte KDE, un dels primers que ataca els proble- 

mes d’usabilitat en entorn UNIX i el primer que tracta de fer-ho 

a gran escala en el món del programari lliure. 

1997, gener: 

Eric S. Raymond presenta el seu article “The Cathedral and the 

Bazaar” (‘La catedral i el basar’), amb les seves opinions sobre 

per què funcionen certs models de desenvolupament del pro- 

gramari lliure. 

1997, agost: 

Miguel de Icaza anuncia el projecte GNOME, un “competidor” 

de KDE amb metes similars, però amb l’objectiu explícit que tot 

el sistema resultant fos programari lliure. Va néixer com a reacció de 

61 


ANOTACIONS


ANOTACIONS 

62 


la Free Software Foundation i d’altres als problemes de llicències que 

tenia KDE, on un component fonamental, la biblioteca Qt, no era 

programari lliure en aquella època. 

1998, 22 de gener: 

Netscape declara la seva intenció de distribuir com a progra- 

mari lliure el codi del seu Navigator, que havia estat el líder en 

el mercat de navegadors de web. 

1998, 3 de febrer: 

Chris Peterson, Todd Anderson, John Hall, Larry Augustin, Sam 

Ockman i Eric Raimond es reuneixen per estudiar les conseqüènci- 

es de l’anunci de Netscape d’alliberar el seu navegador i decidei- 

xen promoure el terme open source software (‘programari de font 

oberta’), com una marca que garanteixi que els productes que la 

porten són programari lliure. Els promotors d’aquest terme entenen 

que és més adequat que l’habitual fins aquell moment, free softwa- 

re (‘programari lliure’), per al món empresarial. Per a gestionar el 

terme, es crea l’Open Source Initiative. 

1998, 31 de març: 

Netscape publica a Internet gran part del codi font del seu na- 

vegador Navigator. 

1998, 7 de maig: 

Corel anuncia el Netwinder, un terminal d’ordinador per a treball 

en xarxa (network computer) basat en Linux. És la primera vegada 

que una gran empresa comercialitza un aparell amb programari 

bàsicament lliure. Poc després, Corel anuncia plans per portar 

el seu programari d’ofimàtica (entre el que hi ha WordPerfect) 

a Linux, que també és nou a l’època. 


Sun Microsystems i Adaptec entren a formar part de Linux Interna- 

cional. Són les primeres grans empreses informàtiques que ho fan. 

1998, juny: 

La conferència tècnica de USENIX, tradicionalment dedicada a 

UNIX, obre una sessió paral·lela anomenada FREENIX, centra- 

da en el programari lliure.

1998, 22 de juny: 


IBM anuncia que comercialitzarà i proporcionarà suport per a 

Apache, i l’utilitzarà com el servidor de la seva línia de produc- 

tes WebSphere. 

1998, juliol: 

S’allibera Debian GNU/Linux 2.0, construïda per més de tres- 

cents voluntaris. Aquesta distribució incloïa més de mil cinc-cents 

paquets. 

1998, juliol: 

S’allibera KDE 1.0, la primera versió distribuïda considerada 

“estable”. Diverses distribucions de GNU/Linux la incorporen 

poc després. 

1998, agost: 

Linus Torvalds i Linux apareixen a la portada de la revista Forbes. 

1998, 29 de setembre: 

Red Hat, aleshores l’empresa líder en el mercat de distribucions 

basades en Linux, anuncia que Intel i Netscape han adquirit 

una participació minoritària en el seu capital. El programari 

lliure comença a despertar l’interès dels inversors. 

1998, novembre: 

Es funda MandrakeSoft, que publica poc després Mandrake Linux, la 

seva distribució de GNU/Linux. 

1998, 1 de novembre: 

Publicació dels “documents de Halloween”, en què, presump- 

tament, Microsoft identifica GNU/Linux i el programari lliure 

com un competidor important i planeja com combatre’l. 

1999, 27 de gener: 

HP i SGI anuncien que suportaran Linux a les seves màquines, la 

qual cosa marca el començament d’una tendència: l’abandona- 

ment dels UNIX propietaris pels fabricants d’ordinadors que els 

usaven com el “seu” sistema operatiu, en favor de Linux. 

63 


ANOTACIONS


ANOTACIONS 

64 


1999, març: 

S’allibera GNOME 1.0, que més endavant va ser estabilitzada 

(October GNOME) i es va incorporar a diverses distribucions de 

GNU/Linux. 

1999, 15 de març: 

Apple allibera el nucli Darwin, que serà el component central 

del seu nou MacOSX, sota una llicència lliure. 

1999, agost: 

Red Hat surt a borsa. El preu de les accions puja enormement 

en els primers dies després de la sortida, i arriba a capitalitzar- 

se en quatre mil vuit-cents milions de dòlars. Més endavant sor- 

tirien a borsa altres empreses relacionades amb el programari 

lliure, com VA Linux i Andover.net. Totes aquestes empreses 

baixaran la cotització extraordinàriament uns quants anys més 

tard, quan explota la bombolla de les puntcom. 


Es funden dues empreses per a produir programari en el marc 

del projecte GNOME: Eazel (que va fer fallida el 2002, després 

de produir Nautilus, un gestor de fitxers per a GNOME) i Helix 

Code (més endavant rebatejada com a Ximian, que ha produït, 

entre d’altres, eines com Red Carpet o Evolution). 

1999, novembre: 

Red Hat Software compra Cygnus. L’empresa resultant és la 

més gran del món en el camp del programari lliure. 

2000, gener: 

Publicació del Mozilla M13, considerada com la primera versió 

raonablement estable de Mozilla, gairebé dos anys després de 

l’alliberament de gran part del codi de Netscape Navigator. 

2000, maig: 

S’allibera GNOME 1.2 (Bongo GNOME). 

2000, agost: 

S’anuncia la creació de la Fundació GNOME.

2001, gener: 

Es publica la versió 2.4 de Linux. 

2002, 3 d’abril: 


Es publica KDE 3.0, la tercera generació de l’entorn d’escrip- 

tori KDE. Els escriptoris lliures comencen a estar a l’altura dels 

escriptoris comercials tradicionals. 

2002, abril: 

Anunci públic del projecte LinEx, amb el qual la Junta d’Extre- 

madura pretén utilitzar la seva pròpia distribució de GNU/Li- 

nux per a informatitzar els col·legis públics de la regió. 

2002, maig: 

Publicació de Mozilla 1.0, la primera versió oficialment estable 

del projecte. 

2002, maig: 

Publicació de l’OpenOffice.org 1.0. Aviat aquesta aplicació es 

convertirà en la referència ofimàtica en el món del programari 


2002, 26 de juny: 

Es publica GNOME 2.0, que és un gran pas endavant amb vista 

a l’usuari amb una interfície més cuidada i atenció a la usabilitat. 

També s’introdueixen aspectes per a millorar-ne l’accessiblitat. 

2002, 28 de juliol: 

Es publica la versió 3.0 de KNOPPIX, una distribució d’avalua- 

ció que es pot instal·lar al disc dur de manera senzilla i ràpida. 

KNOPPIX es converteix en un èxit fulgurant. 

2002, desembre: 

Red Hat Software anuncia que ha tingut flux de caixa positiu els 

trimestres segon i tercer del 2002. 

2003, gener: 

MandrakeSoft, empresa productora de la distribució Mandrake 

Linux, es declara en suspensió de pagaments. 

65 


ANOTACIONS


ANOTACIONS 



apartat 197] 

66 



L’Ajuntament de Munic anuncia que reemplaçarà Windows per 

Linux en la major part del seu sistema informàtic. 

2003, juliol: 

MandrakeSoft anuncia que ha tingut flux de caixa positiu durant 

tot l’any i que espera sortir de la seva situació de suspensió de pa- 

gaments al final del 2003. 


Carta oberta a l’Organització Mundial de la Propietat Intel·lectual 

(WIPO, World Intellectual Proprierty Organization) perquè exami- 

ni els nous models de creació col·lectiva oberta (entre els quals hi 

ha el programari lliure, però també el projecte Genoma Humà o 

les revistes científiques obertes). 


Es funda la Mozilla Foundation. Netscape Inc. (propietat d’AOL) 

anuncia que deixarà de desenvolupar el navegador Netscape i, 

per tant, la tutela del projecte Mozilla. La Fundació Mozilla es 

constitueix amb una donació de dos milions de dòlars per part 

d’AOL i suport material i humà de diverses empreses, entre les 

quals hi ha la mateixa AOL, Red Hat i Sun Microsystems. 

2003, 4 d’agost: 

Novell compra Ximian Inc., una de les empreses líders en el 

desenvolupament de programari lliure –en especial per a 

GNOME–, com a part de la seva estratègia per a assentar-se 

en el mercat de solucions sobre Linux.

3. Aspectes legals 


En aquest capítol es presenten els principals aspectes legals relacio- 

nats amb el programari lliure. Per a posar-los en context, es comença 

per una petita introducció als conceptes més bàsics de la propietat 

intel·lectual i industrial, abans d’exposar la definició detallada de 

programari lliure, programari de font oberta i altres conceptes relaci- 

onats. S’analitzen també amb cert detall les llicències de programari 

lliure més habituals i el seu impacte sobre els models de negoci (que 

es tractaran amb més detall en el capítol 5) i els models de desenvo- 

lupament. També es comentaran llicències per a altres recursos lliu- 

res diferents del programari. 

3.1. Breu introducció a la propietat intel·lectual 

Amb el terme propietat intel·lectual s’agrupen diferents privilegis que 

s’atorguen sobre béns intangibles amb valor econòmic. D’aquests 

privilegis podem destacar els de drets d’autor (copyright) i similars, 

que protegeixen de la còpia no autoritzada els treballs literaris o ar- 

tístics, programes d’ordinador, recopilacions de dades, dissenys in- 

dustrials, etc.; les marques, que protegeixen símbols; les indicacions 

geogràfiques, que protegeixen denominacions d’origen; el secret in- 

dustrial, que consent l’ocultació d’informació; i les patents, que ator- 

guen monopoli temporal sobre un invent a canvi de revelar-lo. En 

moltes legislacions, entre les quals es pot esmentar l’espanyola, es 

distingeix la propietat intel·lectual –que es refereix als drets d’autor– 

de la propietat industrial –que inclou les figures restants. En l’àmbit 

internacional, l’OMPI o WIPO (Organització Mundial de la Propietat 

Intel·lectual, segons si les sigles són en català o en anglès) promou 

tots dos tipus de propietat en tots els aspectes, mentre que l’acord 

TRIPS (aspectes comercials de la propietat intel·lectual) estableix uns 

mínims de protecció i obliga tots els països membres de l’OMC o 

WTO (Organització Mundial del Comerç) a desenvolupar-los en uns 

terminis que depenen del nivell de desenvolupament del país. 

67 


ANOTACIONS


ANOTACIONS 

68 


Encara que la Declaració Universal dels Drets Humans (art. 27) re- 

coneix a les persones el dret que es protegeixin els interessos morals 

i materials que els corresponguin per raó de les produccions científi- 

ques, literàries o artístiques de les quals siguin autors, a la pràctica 

aquest dret se sol transferir a les empreses que ocupen els creadors 

o que comercialitzen les seves creacions. Malgrat això, la propietat 

intel·lectual no es justifica solament per raons morals, sinó també 

pràctiques, per a donar compliment a un altre dret: el de la societat 

a beneficiar-se de les creacions, incentivant-les amb beneficis i pro- 

tegint les inversions per a la creació, investigació i desenvolupament. 

Per a harmonitzar aquests dos drets, la propietat intel·lectual és tem- 

poral i caduca quan ha complert la seva funció de promoció. 

Però la caducitat no és l’única característica que diferencia la propietat 

intel·lectual de l’ordinària. Els continguts de l’ordinària es poden co- 

piar fàcilment i econòmicament, sense pèrdua de qualitat. La còpia 

no perjudica qui ja gaudeix del que s’ha copiat, al contrari que el ro- 

batori, que sí que priva de l’objecte al posseïdor original. La còpia sí 

que pot perjudicar el propietari, ja que el priva potencialment dels in- 

gressos d’una venda. El control de la còpia d’intangibles és molt més 

complicat que el del robatori de béns tangibles i ens pot portar a una 

societat policial, que necessiti controlar totes les còpies d’informació, 

i a una gran inseguretat jurídica perquè augmenten les possibilitats 

de violació accidental de drets. A més, la creativitat és incremental; 

en crear sempre copiem alguna cosa i la línia divisòria entre la vulgar 

còpia i la inspiració és subtil. Per aprofundir més en tot això, revisem 

algunes de les categories de la propietat intel·lectual. 

3.1.1. Drets d’autor 

Els drets d’autor (copyright) protegeixen l’expressió d’un contingut, 

no el contingut en si mateix, i es van desenvolupar per a recompen- 

sar els autors de llibres o d’art. Les obres protegides poden expressar 

idees, coneixements o mètodes lliurement utilitzables, però es prohi- 

beix reproduir-les sense permís, de manera total o parcial, amb mo- 

dificacions o sense. Aquesta protecció és molt senzilla, ja que entra 

automàticament en vigor en el moment de la publicació de l’obra, 

amb àmbit gairebé universal. Avui dia s’ha estès als programes d’or- 

dinador i a les recopilacions de dades.


La Llei de la propietat intel·lectual (LPI), a Espanya, i lleis similars en 

altres països, desplegades sobre la base del Conveni de Berna per a 

la protecció de treballs literaris i artístics del 1886, regulen els drets 

d’autor. Aquests drets es divideixen en morals i patrimonials: els pri- 

mers garanteixen a l’autor el control sobre la divulgació de la seva 

obra, amb nom o pseudònim, el reconeixement d’autoria, el respecte 

a la integritat de l’obra i el dret de modificació i retirada. Els segons 

donen dret a explotar econòmicament l’obra i es poden cedir de ma- 

nera total o parcial, de manera exclusiva o no, a un tercer. Els drets 

morals són vitalicis o indefinits, mentre que els patrimonials tenen 

una durada bastant llarga (setanta anys després de la mort de l’au- 

tor, si és una persona física, en el cas de la llei espanyola). 

La cessió de drets s’especifica amb un contracte anomenat llicència. 

En el cas de programes propietaris, generalment es distribueixen per 

mitjà de llicències d’ús no exclusiu que s’entén que s’accepten au- 

tomàticament en obrir o instal·lar el producte. No cal firmar el con- 

tracte, ja que, en cas que el receptor no ho accepti, regeixen 

automàticament els drets per omissió de la llei, és a dir, cap. Les 

llicències no poden restringir alguns drets, com ara fer còpies pri- 

vades d’art o de música, la qual cosa ens permet regalar una còpia 

d’un enregistrament a un amic, però aquest dret no és aplicable als 

programes. Segons l’LPI de 1996, sempre es pot fer una còpia de 

seguretat dels programes, aquests es poden estudiar per a fer-ne 

d’altres de compatibles i es poden corregir i adaptar a les nostres 

necessitats (difícil, perquè normalment no en tenim els codis font). 

Aquests drets no es poden restringir amb llicències, encara que les 

lleis estan en procés de revisió, en una tendència aparentment im- 

parable a reduir els drets dels usuaris. Les recopilacions organitza- 

des d’obres o dades alienes també estan sotmeses a drets d’autor, 

si bé els termes són diferents i la durada, menor. 

Les noves tecnologies de la informació, i en especial la Xarxa, han tras- 

tocat profundament la protecció dels drets d’autor, ja que les expres- 

sions de continguts són molt més fàcils de copiar que els continguts 

mateixos. I en el cas dels programes i algunes obres d’art (música, 

imatges, pel·lícules i fins i tot literatura) “funcionen” automàticament a 

l’ordinador, sense necessitat d’un esforç humà apreciable. En canvi, 

els dissenys o invents s’han de construir i, segurament, posar-los en 

producció. Aquesta possibilitat de crear riquesa sense cost ha portat 

gran part de la societat, en particular els països pobres, a duplicar 

69 




apartat 61] 

ANOTACIONS


ANOTACIONS 



apartat 191] 

70 


programes sense pagar llicència, perquè no hi ha una consciència 

social que actuar d’aquesta manera sigui una “mala acció” (per con- 

tra, sí que n’hi sol haver respecte al robatori de béns físics, per exem- 

ple). D’altra banda, els fabricants de programes, sols o en coalició 

(per exemple, la BSA o Business Software Alliance) pressionen forta- 

ment perquè les llicències es paguin i els governs persegueixin el que 

s’anomena pirateria. 

3.1.2. Secret comercial 

Un altre dels recursos que les empreses tenen per a rendibilitzar les 

seves inversions és el secret comercial, protegit per les lleis de propi- 

etat industrial, sempre que prenguin prou mesures per a ocultar la 

informació que no volen revelar. En el cas de productes químics o 

farmacèutics que requereixin aprovació governamental, l’estat es 

compromet a no revelar les dades lliurades que no sigui obligatori 

fer públiques. 

Una de les aplicacions del secret comercial més conegudes es troba 

en la indústria del programari propietari, que generalment comerci- 

alitza programes compilats sense donar accés al codi font, per impe- 

dir així el desenvolupament de programes derivats. 

Nota 

El terme pirateria s’ha popularitzat com a sinònim de 

violació de qualsevol forma de propietat intel·lectual, 

especialment en el cas de la còpia il·legal de progra- 

mes, música i pel·lícules. El terme sembla exagerat, i 

en el diccionari de la Reial Acadèmia Espanyola de la 

Llengua apareix com una accepció en sentit figurat, ja 

que el terme original es refereix a robatori amb violèn- 

cia al mar. És per això que Richard Stallman recomana 

evitar-la. 

A primera vista sembla que la protecció del secret comercial és per- 

versa, ja que pot privar indefinidament la societat de coneixements 

útils. D’alguna manera, així ho entenen algunes legislacions, que 

permeten l’enginyeria inversa per a desenvolupar productes substi- 

tuts, encara que la pressió de les indústries ha aconseguit que en


molts països sigui una activitat prohibida i en d’altres, només estigui 

permesa en nom de la compatibilitat. 

Sigui o no pervers el secret comercial, moltes vegades és millor que 

una patent, ja que permet un avantatge competitiu al qui posa un 

producte en el mercat, mentre la competència tracta d’imitar-lo amb 

enginyeria inversa. Com més sofisticat sigui el producte, més li cos- 

tarà a la competència reproduir-lo, mentre que si és trivial, el copiarà 

ràpidament. La imitació amb millores ha estat fonamental per al 

desenvolupament de les que avui són superpotències (els Estats Units 

i el Japó) i és molt important per a la independència econòmica dels 

països en desenvolupament. 

3.1.3. Patents i models d’utilitat 

L’alternativa al secret comercial és la patent. A canvi d’un monopoli 

de disset a vint-i-cinc anys i un determinat cost econòmic, un “invent” 

es revela públicament perquè sigui fàcilment reproduïble. Amb la pa- 

tent es pretén promoure la investigació privada sense cost per al con- 

tribuent i sense que el resultat es perdi. El posseïdor d’una patent pot 

decidir si permet que d’altres la utilitzin i el preu que ha de pagar per 

la llicència. 

La doctrina oficial és que el sistema de patents promou la innovació, 

però cada vegada se senten més veus que afirmen que la dificulta, 

tant perquè diuen que el sistema està mal implementat com perquè 

creuen que és pervers en si mateix. 

Allò que es considera un invent ha anat variant amb el temps, amb 

grans pressions per a ampliar la cobertura del sistema, incloent-hi al- 

goritmes, programes, models de negoci, substàncies naturals, gens i 

formes de vida, incloses plantes i animals. TRIPS exigeix que el siste- 

ma de patents no discrimini cap àmbit del saber. Les pressions de 

l’Organització Mundial de la Propietat Intel·lectual (OMPI o WIPO) 

pretenen eliminar la necessitat que l’invent tingui aplicació industrial 

i també rebaixar els estàndards d’inventiva exigibles en una patent. 

Els Estats Units són al capdavant dels països amb un mínim d’exigèn- 

cies sobre el que és patentable, i a més són els més bel·ligerants per- 

què altres països adoptin els seus estàndards, malgrat que no se’n 

71 





ANOTACIONS


ANOTACIONS 

72 


recorden que ells mateixos es van negar a acceptar les patents es- 

trangeres quan eren un país subdesenvolupat. 

Una vegada obtinguda una patent, els drets del posseïdor són inde- 

pendents de la qualitat de l’invent i de l’esforç invertit per a obtenir- 

lo. Atès el cost de manteniment d’una patent i els costos de litigació, 

només les grans empreses poden mantenir i mantenen una àmplia 

cartera de patents que la situen en una posició que els permet ofegar 

qualsevol competència. Com que és molt fàcil col·locar patents sobre 

solucions trivials o d’aplicabilitat molt àmplia, poden monopolitzar 

un espai molt ampli d’activitat econòmica. 

Amb les patents, moltes activitats, especialment la programació, es 

fan extremadament arriscades, ja que és molt fàcil que en el desen- 

volupament d’un programa complicat es violi accidentalment alguna 

patent. Quan dues o més empreses investiguen per a resoldre un 

problema, és molt probable que arribin a una solució similar gairebé 

alhora, però només una (generalment la de més recursos) aconse- 

guirà patentar el seu invent, i les altres perdran tota possibilitat de 

rendibilitzar la seva inversió. Tot desenvolupament tècnic complex es 

pot convertir en un malson si per cada una de les solucions de les 

seves parts és necessari investigar si la solució trobada està patenta- 

da (o en tràmit), per intentar obtenir la llicència o per buscar una so- 

lució alternativa. Aquest problema resulta especialment greu en el 

programari lliure, on les violacions de patents d’algoritmes són evi- 

dents per simple inspecció del codi. Tot i que a Europa encara és il·le- 

gal patentar un algoritme, podria ser legal en molt poc temps, potser 

quan el lector llegeixi aquestes línies. 

3.1.4. Marques i logotips 

Les marques i els logotips són noms i símbols que representen un pa- 

trimoni de qualitat (o una gran inversió en propaganda). No són gai- 

re importants dins del programari lliure, segurament perquè 

registrar-les representa un cost. Així, només alguns noms importants, 

com Open Source (per Open Source Foundation), Debian (per Sof- 

tware in the Public Interest), GNOME (GNOME Foundation), GNU 

(Free Software Foundation) estan registrats, i només en alguns paï- 

sos. Tanmateix, no registrar els noms ha provocat problemes. Per 

exemple, als Estats Units (1996) i a Corea (1997) hi ha hagut perso-


nes que han registrat el nom Linux i han demanat diners per fer-lo 

servir. La resolució d’aquestes disputes representa costos legals i la 

necessitat de demostrar l’ús del nom anterior a la data del registre. 

3.2. Llicències en el programari lliure 

Estrictament parlant, allò que diferència el programari lliure de la 

resta del programari és un aspecte legal: la llicència. Es tracta, en 

paraules d’ús comú, d’un “contracte” entre l’autor (o propietari dels 

drets) i els usuaris, que estipula què poden fer els usuaris amb la seva 

obra (ús, redistribució, modificació, etc.) i en quines condicions. 

Encara que en essència el programari lliure i el programari propie- 

tari es diferenciïn en la llicència amb què els autors publiquen els 

seus programes, és important posar l’èmfasi en el fet que les diferèn- 

cies entre les diverses llicències, encara que puguin semblar nímies, 

solen representar condicions d’ús i redistribució totalment diferents i, 

com s’ha pogut demostrar al llarg dels últims anys, han desembocat 

no solament en mètodes de desenvolupament totalment diferents, 

sinó fins i tot en una manera alternativa d’entendre la informàtica. 

La legislació sobre drets d’autor, plasmada en les lleis sobre propietat 

intel·lectual, assegura que per defecte no es pot fer gairebé res amb 

una obra (en el nostre cas, un programa) que es rep o es compra si el 

seu autor (o el qui en tingui els drets) no ens ho permet explícitament. 

Les llicències de programari lliure donen certs permisos explícits: quan 

reps un programa lliure el pots redistribuir o no, però si el redistribuei- 

xes, només ho pots fer perquè la llicència t’ho permet. Però per a això 

cal complir amb la llicència... En definitiva, la llicència conté les nor- 

mes d’ús a què han d’atenir-se usuaris, distribuïdors, integradors i al- 

tres parts implicades en el món de la informàtica. 

Les condicions i/o restriccions que imposen les llicències només les 

poden necessitar els mateixos autors que, segons la normativa de la 

propietat intel·lectual són els propietaris de l’obra. En qualsevol cas, 

la propietat de l’obra serà dels autors, ja que la llicència no implica 

transferència de propietat, sinó només dret d’ús i, a vegades, de dis- 

tribució. 

73 


ANOTACIONS


ANOTACIONS 

74 


Per a comprendre plenament tots els racons legals que es presenta- 

ran en aquest capítol (i que, sens dubte, són molt importants per a 

entendre la naturalesa del programari lliure), també cal saber que 

cada nova versió d’un programa es considera com una nova obra. 

L’autor té, una altra vegada, plena potestat per a fer el que li vingui 

de gust amb la seva obra, fins i tot distribuir-la en termes i condicions 

totalment diferents (és a dir, una llicència diferent de l’anterior). Així, 

si el lector és l’autor únic d’un programa podrà publicar una versió 

sota una llicència de programari lliure i, si li ve de gust, una altra de 

posterior sota una llicència propietària. En cas d’haver-hi més autors, 

i que la nova versió contingui codi l’autoria del qual els correspongui i 

es vulgui publicar amb altres condicions, tots han de donar el visti- 

plau al canvi de llicència. 

Un tema encara per discernir, i per tant obert, és conèixer la llicèn- 

cia que cobreix les contribucions “externes”. Generalment, se supo- 

sa que una persona que contribueixi al projecte accepta de facto 

que la seva contribució s’ajusti a les condicions especificades per la 

llicència del projecte, encara que suposem que això pot tenir poc su- 

port jurídic. La iniciativa de la Free Software Foundation de demanar 

mitjançant carta (física) la cessió de tots els drets de copyright a qual- 

sevol que contribueixi amb més de deu línies de codi a un subprojec- 

te de GNU és una bona mostra que això no té per què ser així. 

A partir de tot el que s’ha dit, en la resta d’aquest capítol ens centrarem 

en l’anàlisi de diverses llicències. Per a posar en context aquest estudi, 

cal recordar que d’ara endavant, quan afirmem que una llicència és 

de programari lliure, ho diem en el sentit que compleix les definicions 

de programari lliure que s’han presentat en l’apartat 1.1.1. 

3.2.1. Llicències de tipus BSD 

La llicència BSD (Berkeley Software Distribution) té el seu origen en la 

publicació de versions de UNIX fetes per la universitat californiana de 

Berkeley, als Estats Units d’Amèrica. L’única obligació que exigeix és 

que donin crèdit als autors, mentre que permet tant la redistribució 

binària com la dels codis font, encara que no n’obliga cap de les 

dues en cap cas. També dóna permís per a fer-hi modificacions i in- 

tegrar-la amb altres programes gairebé sense restriccions.


La llicència BSD és certament molt popular, com es pot veure a partir 

del fet que hi ha diverses llicències de condicions similars (X Window, 

Tcl/Tk, Apache), que s’han anomenat llicències de tipus BSD. Aques- 

tes llicències reben el nom de minimalistes, ja que les condicions que 

imposen són poques, bàsicament assignar l’autoria als autors origi- 

nals. La seva concepció es deu al fet que el programari publicat 

sota aquesta llicència era programari generat en universitats amb 

projectes d’investigació finançats pel Govern dels Estats Units; les 

universitats prescindien de la comercialització del programari creat, 

ja que assumien que el Govern l’havia pagat prèviament, per tant, 

amb els impostos de tots els contribuents, de manera que qualsevol 

empresa o particular podia utilitzar el programari gairebé sense res- 

triccions, fins i tot redistribuint-ne modificacions de manera binària 

sense haver de lliurar-ne les fonts. 

Aquest últim punt fa que a partir d’un programa distribuït sota una lli- 

cència de tipus BSD es pugui crear un altre programa (en realitat una 

altra versió del programa) propietari, és a dir, que es distribueixi amb 

una llicència més restrictiva. Els crítics de les llicències BSD veuen un 

perill en aquesta característica, ja que no es garanteix la llibertat de 

versions futures dels programes. Els partidaris d’aquesta llicència, per 

contra, hi veuen la màxima expressió de la llibertat i argumenten que, 

al cap i a la fi, amb el programari es pot fer (gairebé) el que es vulgui. 

Nota 

Una de les conseqüències pràctiques de les llicències 

de tipus BSD ha estat la difusió d’estàndards, ja que 

els desenvolupadors no troben cap obstacle per a fer 

programes compatibles amb una implementació de 

referència sota aquest tipus de llicència. De fet, aques- 

ta és una de les raons de l’extraordinària i ràpida di- 

fusió dels protocols d’Internet i de la interfície de 

programació basada en sockets, ja que la majoria 

dels desenvolupadors comercials va derivar la seva re- 

alització de la de la Universitat de Berkeley. 

Entre les llicències del tipus BSD podem trobar les d’X Window, Tcl/Tk 

i Apache. La majoria són una còpia calcada de l’original de Berkeley, 

excepte tot el referent a l’autoria, que es modifica. D’altres, com 

l’Apache, inclouen alguna clàusula addicional, com la impossibilitat 

75 


ANOTACIONS


ANOTACIONS 

76 


d’anomenar les versions redistribuïdes de la mateixa manera. Totes 

solen incloure, com l’Apache, la prohibició d’usar el nom del propie- 

tari dels drets per a promocionar productes derivats. 

Així, totes les llicències, siguin de tipus BSD o no, inclouen una limi- 

tació de garantia que és, en realitat, una negació de garantia, neces- 

sària per a evitar demandes legals per garanties implícites. Encara 

que s’ha criticat molt aquesta negació de garantia en el programari 

lliure, és una pràctica habitual en el programari propietari, que ge- 

neralment només garanteix que el suport és correcte i que el progra- 

ma en qüestió s’executa. 

aaa 

Esquema resum de la llicència BSD: Copyright © el 

propietari. Tots els drets reservats. 

Es permet la redistribució en font i en binari amb modi- 

ficació o sense, sempre que es compleixin les condici- 

ons següents: 

1. Les redistribucions en font han de tenir la nota de 

copyright i oferir una llista d’aquestes condicions i la 

limitació de garantia. 

2. Les redistribucions en binari han de reproduir la nota 

de copyright i oferir una llista d’aquestes condicions 

i la limitació de garantia en la documentació. 

3. Ni el nom del propietari ni el dels que hi han contri- 

buït es poden utilitzar sense permís per a promocio- 

nar productes derivats d’aquest programa. 

AQUEST PROGRAMA ES PROPORCIONA AIXÍ, SENSE 

GARANTIES EXPRESSES NI IMPLÍCITES, COM ARA 

L’APLICABILITAT COMERCIAL O L’ADEQUACIÓ PER A 

UN PROPÒSIT DETERMINAT. EN CAP CAS EL PROPIE- 

TARI NO SERÀ RESPONSABLE DE CAP DANY CAUSAT 

PER L’ÚS (INCLOENT-HI LA PÈRDUA DE DADES, DE 

BENEFICIS O LA INTERRUPCIÓ DEL NEGOCI).


3.2.2. La Llicència pública general de GNU (GNU GPL) 

La Llicència pública general del projecte GNU (més coneguda pel 

seu acrònim en anglès, GPL) és, amb diferència, la llicència més po- 

pular i coneguda de totes les llicències del món del programari lliure. 

L’autoria correspon a la Free Software Foundation (promotora del 

projecte GNU) i al principi es va crear per a ser la llicència de tot el 

programari generat per l’FSF. Tanmateix, la seva utilització ha anat 

més enllà fins a convertir-se en la llicència més utilitzada (més del 

70% dels projectes anunciats en el lloc web de FreshMeat estan lli- 

cenciats sota la GPL), fins i tot per projectes emblemàtics del món del 

programari lliure, com és el cas del nucli Linux. 

La llicència GPL és interessant des del punt de vista legal perquè fa 

un ús tan curiós de la legislació del copyright que, utilitzant el terme 

estrictament, arriba a una solució totalment contrària a l’original, pel 

qual també s’ha anomenat llicència copyleft. Algú amb una mica 

d’humor va arribar fins i tot a llançar l’eslògan “copyleft, all rights re- 

versed”. 

En línies bàsiques, la llicència GPL permet la redistribució binària i la 

de les fonts, encara que, en cas de redistribució binària, obliga que 

també es pugui accedir a les fonts. Així, també es permet fer modifi- 

cacions sense restriccions, encara que només es pugui integrar codi 

llicenciat sota GPL amb un altre codi que es trobi sota una llicència 

idèntica o compatible, cosa que s’ha anomenat l’efecte viral de la 

GPL, ja que el codi publicat aquestes condicions mai no pot canviar 

de condicions. 

Nota 

Una llicència és incompatible amb la GPL quan restrin- 

geix algun dels drets que la GPL garanteix, tant si con- 

tradiu explícitament alguna clàusula com si n’imposa 

alguna de nova implícitament. Per exemple, la llicència 

BSD actual és compatible, però l’original (o la 

d’Apache), que exigeix als materials de propaganda 

que s’esmenti explícitament que el treball combinat 

conté el codi de tots i cadascun dels titulars de drets, 

la fa incompatible. 

77 


ANOTACIONS


ANOTACIONS 

78 


La llicència GPL està pensada per a assegurar la llibertat del codi en 

tot moment, ja que un programa publicat i llicenciat sota les seves 

condicions mai no es podrà fer propietari. De fet, ni aquest progra- 

ma ni possibles modificacions no es poden publicar amb una llicèn- 

cia diferent de la mateixa GPL. Els partidaris de les llicències de tipus 

BSD veuen en aquesta clàusula una retallada de la llibertat, mentre 

que els seus seguidors hi veuen una manera d’assegurar que aquest 

programari serà sempre lliure. D’altra banda, es pot considerar que 

la llicència GPL maximitza les llibertats dels usuaris, i les de tipus 

BSD, les dels desenvolupadors. Tanmateix, noteu que en el segon cas 

estem parlant dels desenvolupadors en general, i no dels autors, ja 

que molts autors consideren que la llicència GPL és més beneficiosa 

per als seus interessos, perquè obliga els “competidors” a publicar- 

ne les modificacions (millores, correccions, etc.) en cas de redistribuir 

el programari, mentre que amb una llicència tipus BSD no té per què 

ser així. De qualsevol manera, podem veure que l’elecció de llicència 

no és una tasca fàcil i que cal tenir en compte molts factors. 

Quant a la naturalesa contrària al copyright, això es deu al fet que 

la filosofia que hi ha al darrere d’aquesta llicència (i al darrere de la 

Free Software Foundation) és que el programari no ha de tenir pro- 

pietaris. Encara que és cert que el programari llicenciat amb la GPL 

té autor, que és el que al cap i a la fi permet aplicar la legislació de 

copyright a la seva obra, les condicions sota les quals es publica 

l’obra hi donen tal caràcter que podem considerar que la propietat 

del programari correspon a qui el té i no pas a qui l’ha creat. 

Sens dubte, la llicència GPL també inclou negacions de garantia per 

a protegir els autors. I, per a protegir el bon nom dels autors origi- 

nals, qualsevol modificació d’un fitxer font ha d’incloure una nota 

amb la data i l’autor de cada modificació. 

La GPL també té en compte les patents de programari: exigeix que si 

el codi porta algoritmes patentats (com hem dit, una cosa legal i usual 

als Estats Units i pràctica irregular a Europa), o es concedeix llicència 

d’ús de la patent lliure de taxes, o no es pot distribuir sota la GPL. 

La llicència GPL es troba en l’actualitat, i des de fa més de deu anys, 

en la segona versió i és possible que aviat se’n publiqui una tercera. 

Generalment, això no comporta gaires problemes, ja que la majoria


dels autors solen publicar els programes sota les condicions de la se- 

gona versió de la GPL o qualsevol de posterior publicada per la 

Free Software Foundation. Com a anècdota, es pot dir que Linus 

Torvalds, creador de Linux, només publica el seu programari sota 

les condicions de la segona versió de la GPL, i busca desmarcar-se 

de les postures –de vegades massa radicals, segons ell– de la Free 

Software Foundation. 

3.2.3. La Llicència pública general menor de GNU 

(GNU LGPL) 

La Llicència pública general menor del projecte GNU (coneguda 

per les seves inicials en anglès, LGPL) és l’altra llicència de la Free 

Software Foundation. Pensada en els seus inicis per a utilitzar-la en 

biblioteques (la L, al començament, venia de library, ‘biblioteca’), es 

va modificar recentment perquè es considerés la germana menor 

(lesser, ‘menor’) de la GPL. 

L’LGPL permet l’ús de programes lliures amb programari propietari. 

El programa, per si mateix, es redistribueix com si estigués sota la lli- 

cència GPL, però es permet integrar-la a qualsevol altre programari 

gairebé sense cap limitació. 

Com podem veure, al principi aquesta llicència estava orientada 

a les biblioteques de manera que se’n pogués potenciar l’ús i el 

desenvolupament sense tenir els problemes d’integració que implica 

la GPL. Tanmateix, quan es va veure que l’efecte buscat de popula- 

ritzar les biblioteques lliures no es compensava per la generació de 

programes lliures, la Free Software Foundation va decidir el canvi 

de library a lesser i en va desaconsellar l’ús, excepte per a condicions 

molt puntuals i especials. Avui dia hi ha molts programes que no són 

biblioteques llicenciats sota les condicions de l’LGPL. Per exemple, el 

navegador Mozilla està llicenciat, entre altres, també sota l’LGPL. 

3.2.4. Altres llicències de programes 

La varietat de llicències lliures és gran, encara que per raons pràcti- 

ques la majoria dels projectes s’adapten a les comentades anterior- 

ment: en efecte, molts projectes no volen o no poden dedicar recursos 

79 




apartat 97] 

ANOTACIONS


ANOTACIONS 

80 


a dissenyar una llicència pròpia i la majoria dels usuaris prefereixen 

referir-se a unes sigles abans que llegir i analitzar llicències comple- 

tes. El fet que una llicència sigui lliure o no, depèn del concepte de 

llibertat que tingui el qui la classifica, encara que després hi hagi con- 

sens per a la majoria. 

Suggeriment 

Podeu veure recopilades i comentades, tant llicències 

considerades lliures com llicències considerades no 

lliures, o lliures, però incompatibles amb la GPL des 

del punt de vista de l’FSF a [fsf:licences]. El punt de vis- 

ta filosòfic diferent de l’Open Source Initiative es reflec- 

teix en la seva llista [osi:licenses]. Es poden veure 

discrepàncies en algunes llicències, com l’Apple Public 

Source License Ver. 1.2, considerada no lliure per l’FSF 

per l’obligació de publicar tots els canvis (encara que 

siguin privats), per haver de notificar a Apple les redis- 

tribucions, o per la possibilitat de revocació unilateral. 

Això no obstant, la pressió d’aquesta classificació ha 

fet que Apple publiqui la versió 2.0 l’agost del 2003, 

ja considerada lliure per l’FSF. 

Com a exemple, incloem a continuació dues petites llistes amb algu- 

nes llicències de programari lliure no tractades fins al moment. 

En la primera llista es poden trobar llicències que no imposen condi- 

cions especials en la segona redistribució: és a dir, que només espe- 

cifiquen que el programari es pot redistribuir o modificar, però no 

imposen condicions especials si es fa, la qual cosa permet, per exem- 

ple, que algú que rep el programa després el pugui redistribuir com 

a programari propietari. En la segona llista s’inclouen les que, a l’es- 

til de la GNU GPL, imposen condicions si es vol redistribuir el pro- 

gramari, que van en la línia de forçar que es continuïn complint les 

condicions de la llicència després de la primera redistribució. Mentre 

que el primer grup fa èmfasi en la llibertat de qui rep un programa, 

ja que li permeten fer gairebé el que vulgui (en termes de condicions 

de futures redistribucions), el segon ho fa en la llibertat que qualsevol 

pugui rebre algun dia un treball derivat del programa (ja que obliga


que les successives modificacions i redistribucions respectin els ter- 

mes de la llicència original). La diferència entre aquests dos tipus de 

llicències ha estat (i és) tema de debat en la comunitat del programari 

lliure. En la resta d’aquest apartat anomenarem llicències permissives 

o llicències de tipus BSD les del primer tipus, i llicències robustes o lli- 

cències copyleft, les del segon. En qualsevol cas, cal recordar que to- 

tes dues són llicències lliures. 

Algunes llicències permissives: 

• Llicència d’X Window versió 11 (X11) 

És la llicència usada per a la distribució del sistema X Window, el sis- 

tema de finestres més utilitzat en el món UNIX, i també en entorns 

GNU/Linux. És una llicència molt similar a la llicència BSD, que en 

permet la redistribució, l’ús i la modificació pràcticament sense res- 

triccions. De vegades, aquesta llicència s’anomena llicència MIT 

(amb poca precisió i perillosa, perquè el MIT ha usat altres tipus de 

llicències). Sota aquesta llicència es distribueixen també treballs deri- 

vats de X Windows, com XFree86. 

• Zope Public License 2.0 

Aquesta llicència (habitualment anomenada ZPL) s’utilitza per a la 

distribució de Zope (un servidor d’aplicacions) i altres productes re- 

lacionats. És una llicència similar a la BSD, amb el detall interessant 

que prohibeix expressament l’ús de marques registrades per Zope 

Corporation. 

• Llicència d’Apache 

Llicència sota la qual es distribueixen la major part dels programes 

produïts pel projecte Apache. És similar a la llicència BSD. 

Nota 

El terme copyleft aplicat a una llicència, utilitzat sobre- 

tot per la Free Software Foundation per a definir les se- 

ves llicències, té implicacions similars a les del terme 

llicència robusta, tal com l’utilitzem en aquest text. 

81 





ANOTACIONS


ANOTACIONS 



apartats 49, 50, 21, 20, 

62, 34 i 39] 

82 


Alguns programes lliures no es distribueixen amb una llicència espe- 

cífica, sinó que l’autor els declara explícitament public domain (‘de 

domini públic’). La principal conseqüència d’aquesta declaració és 

que l’autor renuncia a tots els seus drets sobre el programa, que per 

tant es pot modificar, redistribuir, utilitzar, etc., de qualsevol manera. 

A efectes pràctics, aquesta situació és molt similar a la d’un progra- 

ma que estigui sota una llicència tipus BSD. 

Algunes llicències robustes: 

• Llicència de Sleepycat 

És la llicència sota la qual l’empresa Sleepycat distribueix els seus 

programes (entre ells el conegut Berkeley DB). Obliga a complir cer- 

tes condicions sempre que es redistribueix el programa o treballs de- 

rivats del programa. En especial, obliga a oferir el codi font (incloses 

les modificacions, si es tracta d’un treball derivat), i que la redistribu- 

ció imposi les mateixes condicions al receptor. Encara que molt més 

curta que la GNU GPL, és molt similar en els seus efectes principals. 

• eCos License 2.0 

És la llicència sota la qual es distribueix eCos, un sistema operatiu de 

temps real. És una modificació de la GNU GPL, que no considera que 

el codi que s’enllaci amb programes que protegeix restin subjectes a 

les clàusules de la GNU GPL, si es redistribueixen. Des d’aquest punt 

de vista, els seus efectes són similars als de la GNU LGPL. 

• Affero General Public License 

Interessant modificació de la GNU GPL, que considera el cas dels 

programes que ofereixen serveis pel web, o en general, per xarxes 

d’ordinadors. Aquest tipus de programes plantegen un problema des 

del punt de vista de les llicències robustes. Com que l’ús del progra- 

ma no implica haver-lo rebut mitjançant una redistribució, encara 

que el programa estigui llicenciat, per exemple, sota la GNU GPL, 

algú el pot modificar i oferir un servei a la Xarxa utilitzant-lo, sense 

redistribuir-lo de cap manera, i per tant sense estar obligat, per 

exemple, a distribuir-ne el codi font. L’Affero GPL té una clàusula que 

obliga que, si el programa té un mitjà per a proporcionar el seu codi


font pel web a qui la utilitzi, aquesta característica no es pugui 

desactivar. Això significa que, si l’autor original inclou aquesta ca- 

pacitat en el codi font, qualsevol usuari el pot obtenir, i a més aques- 

ta redistribució està sotmesa a les condicions de la llicència. La Free 

Software Foundation està considerant incloure provisions similars en 

la versió 3 del seu GNU GPL. 

• IBM Public License Version 1.0 

És una llicència que permet la redistribució binària de treballs deri- 

vats només si (entre altres condicions) es preveu algun mecanisme 

perquè qui rebi el programa en pugui rebre el codi font. La redistri- 

bució del codi font s’ha de fer sota la mateixa llicència. A més, aques- 

ta llicència és interessant perquè obliga qui redistribueix el programa 

amb modificacions a llicenciar automàticament i gratuïtament les 

patents que puguin afectar aquestes modificacions, i obliga qui rebi 

el programa, que siguin propietat del redistribuïdor. 

• Mozilla Public License 1.1 

Exemple de llicència lliure amb origen en una empresa. És una evo- 

lució de la primera llicència lliure que va tenir Netscape Navigator, i 

va ser molt important en el seu moment perquè va ser la primera ve- 

gada que una empresa molt coneguda va decidir distribuir un pro- 

grama sota la seva pròpia llicència lliure. 

3.2.5. Distribució sota diverses llicències 

Fins ara hem anat suposant que cada programa tenia una única lli- 

cència en què s’especificaven, entre d’altres, les condicions d’ús i re- 

distribució. Tanmateix, un autor pot distribuir obres amb diferents 

llicències. Per a entendre-ho, hem de tenir present que cada publica- 

ció és una obra nova i que es pot donar el cas que es distribueixin ver- 

sions que només difereixen en la llicència. Com veurem, la majoria 

de vegades això comporta que, segons el que l’usuari vulgui fer amb 

el programari, haurà d’obeir una llicència o una altra. 

L’exemple més conegut de doble llicència és el de la biblioteca Qt, 

sobre la qual es fonamenta l’entorn d’escriptori KDE. Trolltech, una 

83 


ANOTACIONS


ANOTACIONS 



apartat 94] 




84 


empresa establerta a Noruega, distribuïa Qt amb una llicència pro- 

pietària, encara que eximia del pagament als programes que en fes- 

sin ús sense ànim de lucre. Per aquesta causa i per la seva potència 

tècnica va ser elegida a mitjan dècada dels noranta pel projecte KDE, 

la qual cosa va representar una àrdua polèmica amb la Free Software 

Foundation, ja que llavors KDE deixava de ser programari lliure en el 

seu conjunt, en dependre d’una biblioteca propietària. Després d’un 

llarg debat –en el qual, entre altres coses, va aparèixer GNOME com 

a competidor lliure de KDE en l’escriptori–, Trolltech va decidir utilit- 

zar el sistema de doble llicència per al seu producte estrella: els pro- 

grames que estaven sota llicència GPL podien fer ús d’una versió de 

Qt GPL, mentre que els que no ho estaven, els havien de comprar 

una llicència. Aquesta solució va satisfer totes les parts, per la qual 

cosa avui dia KDE es considera programari lliure. 

Altres exemples de llicències duals els podem trobar a StarOffice i 

OpenOffice.org, o en el ja desaparegut Netscape Communicator i a 

Mozilla. En tots dos casos el primer producte és propietari, mentre 

que el segon és una versió lliure (generalment sota les condicions de 

diverses llicències lliures). Encara que al principi els projectes lliures 

eren versions limitades dels seus germans propietaris, amb el temps 

han anat prenent el seu propi camí, i avui dia tenen un grau d’inde- 

pendència força gran. 

3.3. Llicències d’altres recursos lliures 

Les llicències de programari lliure han estat font d’inspiració per a al- 

tres recursos intel·lectuals, de manera que molts les han adoptat di- 

rectament, especialment en el cas de la documentació, mentre que 

en altres casos les han adaptat lleugerament, com és el cas de la pi- 

onera Open Audio License. La majoria són de tipus copyleft si per- 

meten treballs derivats. 

Fins i tot s’han utilitzat llicències de programes (GPL i LGPL) per a ma- 

quinari, encara que aquesta matèria és complexa i difícil de conciliar 

amb la legalitat vigent. En efecte, els dissenys i diagrames es poden 

utilitzar, sense copiar-los físicament, per a extreure idees que s’utilit- 

zin per a nous dissenys tancats. Per exemple, l’OpenIPCore Software


General Public License preveu la prohibició d’aquesta apropiació, 

però la seva legalitat és dubtosa. L’única possibilitat de protegir 

aquestes idees és per mitjà d’algun tipus de patent lliure, una cosa 

encara no desenvolupada i fora de l’abast dels que no tenen intenció 

o possibilitat de fer-hi negoci. 

3.3.1. Llicència de documentació lliure 

de GNU 

Una de les llicències de tipus copyleft més conegudes per a la docu- 

mentació tècnica, tant de programes com de qualsevol altra cosa, és 

la de la Free Software Foundation. Després d’adonar-se que un do- 

cument no és el mateix que un programa, Richard Stallman promou 

una llicència per als documents que acompanyen els programes i per 

a d’altres de caràcter tècnic o didàctic. 

Per a facilitar el desenvolupament de versions derivades, cal posar a 

disposició de qui ho requereixi una còpia transparent del document, 

a més de les còpies opaques, en una analogia entre els codis font i 

els objectes dels programes. 

Vegeu l’apartat 1.4.1 i l’apèndix B, apartat B.2. 

Una de les preocupacions de la llicència és reconèixer l’autoria i 

impedir que es tergiversin idees o opinions expressades per l’autor. 

Per a això, s’exigeix que les obres derivades exhibeixin en la porta- 

da un títol diferent del de les versions anteriors (llevat de permís ex- 

prés) i s’esmenti expressament on es pot aconseguir l’original. 

També s’ha de fer una llista dels autors, o bé dels originals, més 

importants –a més dels autors de les modificacions– i conservar to- 

tes les notes sobre els drets d’autor. S’han de conservar, així mateix, 

els agraïments i les dedicatòries, i respectar l’apartat d’història, si 

en té, afegint-hi les modificacions noves. Fins i tot, i això és el que 

més es critica de la llicència, es poden nomenar seccions invariants 

i textos de cobertes, que ningú no pot modificar ni eliminar, si bé la 

llicència només permet considerar invariant textos no tècnics, que 

anomena secundaris. 

Nota 

85 


ANOTACIONS


ANOTACIONS 




86 


Aquesta llicència ha generat una gran polèmica en el món del pro- 

gramari lliure, fins al punt que en la distribució Debian s’està dis- 

cutint (en el moment de publicar aquest text) si eliminar tots els 

documents o passar-los a la secció extraoficial no lliure. Fins i tot 

encara que no hi hagi seccions invariants, com que els treballs de- 

rivats es regeixen per la mateixa llicència, les poden afegir. S’argu- 

menta, per exemple, que algunes seccions invariants poden ser 

incorrectes o estar obsoletes, però malgrat tot, s’han de mantenir. 

En tot cas, la llicència és incompatible amb les directrius de progra- 

mari lliure de Debian, però la qüestió potser rau en si la documen- 

tació les ha de complir (per exemple, els textos de les llicències 

tampoc no es poden modificar). 

Suggeriment 

Aquest text està emparat en aquesta llicència, per la 

qual cosa s’inclou la versió original en l’apèndix A, i 

una traducció en l’apèndix B. Estudieu qualsevol de les 

versions i feu-vos-en una opinió. 

3.3.2. Llicències de Creative Commons 

El 2001 es va fundar Creative Commons, dirigit per experts en pro- 

pietat intel·lectual, dret en la societat de la informació i informàti- 

ca, per tal de fomentar l’existència, conservació i accessibilitat de 

recursos intel·lectuals cedits a la comunitat de diverses maneres. 

Un dels seus projectes més coneguts va ser el desenvolupament, al 

final del 2002, d’una sèrie de llicències no concebudes per a pro- 

gramari, sinó per a treballs literaris, artístics, didàctics, etc. La seva 

característica més excel·lent, a més del fet que estan avalades per 

professionals del dret, és que permeten que l’autor seleccioni quin 

tipus de llibertats cedeix, a més de la de còpia, segons quatre di- 

mensions: donar crèdit a l’autor original, permetre treballs derivats, 

permetre redistribució comercial i permetre canviar la llicència. Així, 

per exemple, la llicència dels cursos del MIT (MIT Open Courseware 

License Version 1.0) es basa en la de Creative Commons, que obliga 

a donar crèdit, n’impedeix l’ús comercial i obliga a conservar-ne la 

llicència en treballs derivats.

Suggeriment 


Malgrat que hi ha quatre dimensions, no hi ha setze lli- 

cències, sinó solament onze. En la taula següent s’ano- 

menen i es mostren els símbols utilitzats per a designar- 

les gràficament: 

Attribution 

3.4. Resum 

Attribution-NoDerivs 

Attribution-NoDerivs-NonCommercial 

Attribution-NonCommercial 

Attribution-NonCommercial-ShareAlike 

Attribution-ShareAlike 

NoDerivs 

NoDerivs-NonCommercial 

NonCommercial 

NonCommercial-ShareAlike 

ShareAlike 

Per què no n’hi ha setze? 

En aquest capítol hem pogut veure la importància que tenen les lli- 

cències dins del món del programari lliure i dels altres recursos lliu- 

res. També hem presentat la gran varietat de llicències existents, la 

seva motivació, les seves repercussions i els seus avantatges i incon- 

venients. En definitiva, podem dir que la GPL tracta de maximitzar les 

llibertats que té l’usuari del programari –tant si el rep directament de 

l’autor com si no–, mentre que les llicències de tipus BSD maximitzen 

les llibertats del desenvolupador o redistribuïdor. 

Pel que s’ha comentat en aquest capítol, es dedueix que és molt im- 

portant decidir d’hora quina llicència tindrà un projecte i conèixer-ne 

detalladament els avantatges i els inconvenients, ja que una modifica- 

ció posterior sol ser molt difícil, sobretot si el nombre de contribucions 

externes és molt gran. 

87 


ANOTACIONS


ANOTACIONS 

88 


Per acabar, volem posar l’accent en el fet que el programari lliure i 

el programari propietari es diferencien únicament i exclusivament 

per la llicència amb què es publiquen els programes. En els capítols 

següents veurem, tanmateix, que aquesta puntualització merament 

legal pot tenir conseqüències en la manera com es desenvolupa el 

programari i, per tant, donar lloc a un nou model de desenvolupa- 

ment més o menys diferent, segons el cas, dels mètodes de desenvo- 

lupaments “tradicionals” utilitzats en la indústria del programari 

propietari.


4. El desenvolupador i les seves motivacions 

4.1. Introducció 

El desenvolupament parcialment anònim i distribuït del programari 

lliure ha permès que, durant molts anys, els recursos humans amb 

què compta el programari lliure siguin desconeguts. Conseqüència 

d’aquest desconeixement ha estat la mitificació, almenys parcial, del 

món del programari lliure i de la vida dels qui hi ha al darrere, em- 

parant-se en tòpics més o menys estesos sobre la cultura hacker i els 

ordinadors. Des de fa uns quants anys, s’ha anat fet un gran esforç 

per part de la comunitat científica per conèixer més bé les persones 

que participen en projectes de programari lliure, la procedència, les 

motivacions, la preparació i altres aspectes que poden semblar inte- 

ressants. Des d’un punt de vista purament pragmàtic, conèixer qui 

s’implica i per què en aquest tipus de projectes pot ser molt útil per a 

la generació de programari lliure. Alguns científics, principalment 

economistes, psicòlegs i sociòlegs, han volgut anar més enllà i han 

vist en aquesta comunitat el germen de futures comunitats virtuals 

amb regles i jerarquies pròpies, moltes vegades totalment diferents 

de les que coneixem en la societat “tradicional”. Entre les incògnites 

més importants hi ha la de conèixer els motius que porten els desen- 

volupadors a ser partícips en una comunitat d’aquestes característi- 

ques, tenint en compte que els beneficis econòmics, almenys els 

directes, són pràcticament inexistents, mentre que els indirectes són 

difícilment avaluables. 

4.2. Qui són els desenvolupadors? 

Aquest apartat pretén oferir una visió global de les persones que dedi- 

quen el seu temps i el seu esforç a participar en projectes de progra- 

mari lliure. Les dades que es mostraran provenen majoritàriament 

d’estudis científics que s’han elaborat en els últims anys i que són els 

més significatius –encara que, sens dubte, no els únics. 

89 


ANOTACIONS 



apartats 104 i 176]


ANOTACIONS 

90 


Els desenvolupadors de programari lliure són en general persones 

joves: la mitjana d’edat se situa entorn dels vint-i-set anys. La va- 

riància de l’edat és molt gran, ja que el grup predominant es tro- 

ba en un interval que va dels vint-i-un als vint-i-quatre anys, i la 

mediana –el valor que apareix amb més freqüència– són els vint- 

i-tres anys. És interessant observar que l’edat d’incorporació al movi- 

ment de programari lliure té els seus màxims entre els divuit i els vint- 

i-cinc anys –es pronuncia especialment entre els vint-i-un i els vint-i-tres 

anys–, que equivaldria a l’edat universitària. Aquesta evidència con- 

trasta amb l’afirmació que el programari lliure és cosa principalment 

d’adolescents, encara que la seva presència és evident (entorn d’un 

20% dels desenvolupadors té menys de vint anys). En definitiva, els 

desenvolupadors solen estar majoritàriament en la vintena (un 60%), 

mentre que els menors de vint i els més grans de trenta es reparteixen 

el 40% restant a parts iguals. 

De l’edat d’incorporació es pot deduir que hi ha una gran influèn- 

cia universitària en el programari lliure. Això no ens ha d’estranyar 

gens, ja que, com hem pogut veure en el capítol d’història, el pro- 

gramari lliure –abans fins i tot de portar aquest nom– ha estat ínti- 

mament lligat a les institucions educatives superiors. Encara avui, 

l’autèntic motor de l’ús i expansió del programari lliure continuen 

essent les universitats i els grups d’usuaris estudiantils. No és, per 

tant, gens estrany que més d’un 70% dels desenvolupadors tinguin 

una preparació universitària. La dada té més importància si tenim 

en compte que, del 30% restant, molts no són universitaris perquè 

encara estan en la fase escolar. Tot i així, també hi tenen cabuda 

–i no per això són menys apreciats– desenvolupadors que no han 

accedit mai a estudis superiors, però que són amants de la informàtica. 

El desenvolupador de programari lliure és generalment home. Les 

xifres que es manegen en les diferents enquestes sobre la presèn- 

cia de dones en la comunitat varien entre un 1% i un 3%, quota 

que competeix amb el marge d’error de les enquestes. D’altra 

banda, una majoria (60%) afirma tenir parella, mentre que el 

nombre de desenvolupadors amb fills només és d’un 16%. Atesos 

els marges d’edat en què es comprenen els desenvolupadors de 

programari lliure, aquestes dades concorden bastant bé amb una 

mostra aleatòria, per la qual cosa es poden considerar “normals”. 

El mite del desenvolupador solitari, l’afició del qual per la infor-


màtica és l’únic al·licient en la seva vida, es demostra una excep- 

ció a la regla. 

4.3. Què fan els desenvolupadors? 

Professionalment, els desenvolupadors de programari lliure es defi- 

neixen com a enginyers de programari (33%), estudiants (21%), pro- 

gramadors (11%), consultors (10%), professors d’universitat (7%), 

etc. D’altra banda, no acostumem a formar part ni del departament 

comercial, ni del de màrqueting, més que a l’entorn d’un 1%). És in- 

teressant observar que molts es defineixen a si mateixos com a engi- 

nyers de programari abans que com a programadors –gairebé tres 

vegades més–, tenint en compte, com es veurà en el capítol dedicat 

a l’enginyeria del programari, que l’aplicació de les tècniques clàssi- 

ques d’enginyeria de programari (i fins i tot algunes de modernes) no 

sol estar gaire arrelada en el món del programari lliure. 

El vincle universitari que ja ha estat mostrat anteriorment torna a 

aparèixer en aquest apartat. Entorn d’un terç dels desenvolupa- 

dors és estudiant o professor d’universitat, cosa que demostra que 

hi ha una gran col·laboració entre gent provinent principalment 

de la indústria del programari (els dos terços restants) i l’àmbit 

acadèmic. 

D’altra banda, també s’ha pogut constatar una gran interdiscipli- 

narietat: un de cada cinc desenvolupadors prové de camps dife- 

rents del de les tecnologies de la informació. Això, unit al fet que 

també hi ha un nombre similar de desenvolupadors no universi- 

taris, reflecteix l’existència d’una gran riquesa quant a interessos, 

procedències i, en definitiva, a la composició dels equips de desenvo- 

lupament. És molt difícil trobar una indústria moderna en què el grau 

d’heterogeneïtat sigui tan gran com el que es pot veure en el progra- 

mari lliure, si és que existeix. 

A més d’aproximadament el 20% d’estudiants, la majoria dels 

desenvolupadors solen ser assalariats (64%), mentre que el per- 

centatge d’autònoms és del 14%. Finalment, només un 3% diu es- 

91 


ANOTACIONS


ANOTACIONS 



apartat 166] 

92 


tar a l’atur, dada que és significativa, ja que l’enquesta es va fer 

després del començament de la crisi de les puntcom. 

L’obtenció de dades geogràfiques dels desenvolupadors és una qües- 

tió que encara s’ha d’abordar de manera més científica. El problema 

que presenten els estudis que es mostren en aquest capítol és que, 

com que es tracta d’enquestes a Internet, obertes a tothom, la partici- 

pació depèn molt dels llocs on s’hagi anunciat i de la manera com es 

va anunciar. Per ser rigorosos, cal esmentar que les enquestes no bus- 

caven representativitat en aquest sentit, sinó més aviat obtenir la res- 

posta i/o l’opinió del nombre més gran possible de desenvolupadors 

de programari lliure. 

Nota 

El fet que el finançament del programari lliure, al con- 

trari del que passa amb el propietari, no es pugui fer 

mitjançant la venda de llicències ha generat des de 

sempre debats sempre acalorats entorn de com s’han 

de guanyar la vida els programadors. En les enquestes 

que es comenten en aquest capítol, més d’un 50% dels 

desenvolupadors deien que s’havien beneficiat econò- 

micament de manera directa o indirecta de la seva im- 

plicació en el programari lliure. Tanmateix, n’hi ha 

molts que no ho veuen tan clar. El mateix Richard 

Stallman, fundador del projecte GNU, davant de la 

pregunta de què ha de fer un desenvolupador de pro- 

gramari lliure per guanyar diners, sol respondre que 

pot treballar de cambrer. 

4.4. Distribució geogràfica 

Tanmateix, ens podem aventurar a fer-hi unes quantes afirmacions, 

sabent que les dades no són tan fiables com les exposades abans i 

que el marge d’error és, per tant, molt més gran. Sembla un fet cons- 

tatable que la gran majoria dels desenvolupadors de programari 

lliure provenen de països industrialitzats, mentre que la presència de 

desenvolupadors de països de l’anomenat Tercer Món és escassa. 

No és gens estrany, doncs, que el mapa de desenvolupadors del pro-


jecte Debian, per posar un exemple, concordi amb les fotografies de 

la Terra de nit: allà on hi ha llum –llegiu: on hi ha civilització indus- 

trialitzada– és on més se solen concentrar els desenvolupadors de 

programari lliure. Això que al principi podria semblar lògic, contrasta 

amb les possibilitats potencials que el programari lliure ofereix als 

països del Tercer Món. 

Un exemple clar el podem trobar en la taula 4-1, que conté els paï- 

sos d’origen més habituals per als desenvolupadors del projecte De- 

bian al llarg dels últims quatre anys. Es pot observar una tendència 

a la descentralització del projecte, que es constata en el fet que el 

creixement dels desenvolupadors als Estats Units –el país que més hi 

aporta– és inferior a la mitjana. I és que, en general, els països han 

aconseguit doblar el nombre de voluntaris en els últims quatre anys: 

França és l’exemple més clar en aquest sentit, ja que ha aconseguit 

multiplicar per cinc la seva presència. Considerant que els primers 

passos de Debian van tenir lloc al continent americà (en particular 

als Estats Units i el Canadà), podem veure que en els últims quatre 

anys ha sofert una “europeïtzació” del projecte. Suposem que el pas 

següent serà l’anhelada mundialització, amb la incorporació de pa- 

ïsos sud-americans, africans i asiàtics (tret de Corea i el Japó, ja ben 

representats), encara que les dades que manegem (dos desenvolu- 

padors a Egipte, la Xina i l’Índia, un a Mèxic, Turquia i Colòmbia el 

juny del 2003) no són gaire esperaçadores en aquest sentit. 

Taula 4-1. Països amb més nombre de desenvolupadors de Debian 

País 1.7.1999 1.7.2000 1.7.2001 1.7.2002 20.6.2003 

Estats Units 162 169 256 278 297 

Alemanya 54 58 101 121 136 

Regne Unit 34 34 55 63 75 

Austràlia 23 26 41 49 52 

França 11 11 24 44 51 

Canadà 20 22 41 47 49 

Espanya 10 11 25 31 34 

Japó 15 15 27 33 33 

Itàlia 9 9 22 26 31 

Països 

Baixos 

14 14 27 29 29 

Suècia 13 13 20 24 27 

93 


ANOTACIONS


ANOTACIONS 

94 


Dins del món del programari lliure (i no solament en el cas de Debian), 

es manté una àmplia discussió sobre la supremacia en el món del 

programari lliure entre Europa i els Estats Units. Gairebé tots els es- 

tudis que s’han anat fent mostren que la presència de desenvolupa- 

dors europeus és lleugerament superior a l’americana, efecte que 

queda mitigat pel fet que la població europea és més gran que l’ame- 

ricana. Ens trobem, doncs, davant d’una situació de guerra de xifres, 

ja que el nombre de desenvolupadors per capita afavoreix els nord- 

americans, però torna a ser favorable als europeus si en lloc de les 

xifres de població absolutes considerem només aquelles persones que 

disposen d’accés a Internet. 

Quant a països, les zones amb més implantació (en nombre de 

desenvolupadors dividit per població) són les del nord d’Europa 

(Finlàndia, Suècia, Noruega, Dinamarca i Islàndia) i centre-europees 

(Benelux, Alemanya i Txèquia), seguits d’Austràlia, el Canadà, Nova 

Zelanda i els Estats Units. La zona mediterrània, malgrat que és im- 

portant en magnituds absolutes (a causa de la gran població que te- 

nen França, Itàlia i Espanya), tanmateix, es troba per sota de la 

mitjana. 

4.5. Dedicació 

El nombre d’hores que els desenvolupadors de programari lliure de- 

diquen al programari lliure és un dels aspectes més desconeguts. Es 

tracta d’una de les grans diferències amb el programari generat per 

una empresa, en què es coneixen tant l’equip com la dedicació de 

cada membre de l’equip al desenvolupament. El temps que dedi- 

quen els desenvolupadors de programari lliure es pot prendre com 

una mesura indirecta del grau de professionalització. Abans de mos- 

trar les dades que tenim avui dia, és important fer notar que s’han 

obtingut de les estimacions que els mateixos desenvolupadors han 

proporcionat en diverses enquestes, per la qual cosa cal afegir, a la 

inexactitud inherent a aquest tipus de recopilació de dades, un marge 

d’error degut principalment al que cada desenvolupador entengui 

com a temps de desenvolupament. D’aquesta manera, segur que 

molts desenvolupadors no compten el temps que dediquen a llegir el 

correu (o potser sí) i només indiquen el temps que dediquen a pro-


gramar i depurar. Per això, totes les xifres que s’ensenyen a continu- 

ació s’han de prendre amb la deguda precaució. 

Els estudis que s’han fet fins ara mostren que, com a mitjana, cada 

desenvolupador de programari lliure dedica aproximadament onze 

hores setmanals. Tanmateix, aquesta xifra pot portar ràpidament a 

l’engany, ja que hi ha una gran variació en la dedicació dels desen- 

volupadors de programari. En l’estudi Rishab d’A. Ghosh, Ruediger 

Glott, Bernhard Krieger i Gregorio Robles (2002), Free/libre and 

open source software: Survey and study - part iv: Survey of developers, 

un 22,5% dels enquestats va indicar que la seva aportació era infe- 

rior a les dues hores setmanals, xifra que pujava al 26,5% per als que 

hi dedicaven entre dues i cinc hores setmanals. Entre sis i deu hores 

és el temps que hi dedica un 21,0%, mentre que el 14,1% ho feia en- 

tre onze i vint hores setmanals. El 9,2% i el 7,1% dels enquestats afir- 

maven que el temps que dedicaven a desenvolupar programari lliure 

era, respectivament, de vint a quaranta hores setmanals, i de més de 

quaranta hores setmanals. 

Taula 4-2. Dedicació en hores setmanals 

Hores setmanals Percentatge 

Menys de 2 hores 22,5% 

De 2 a 5 hores 26,1% 

De 5 a 10 hores 21,0% 

De 10 a 20 hores 14,1% 

De 20 a 40 hores 9,2% 

Més de 40 hores 7,1% 

Nota 

A més de poder veure la professionalització dels 

equips de desenvolupament de programari lliure, la 

dedicació en hores és un paràmetre molt important a 

l’hora de poder fer estimacions de costos i fer comparacions 

amb els models de desenvolupament propietaris 

que se segueixen en la indústria. En el programari 

lliure només comptem, per ara, amb productes acabats 

(nous lliuraments del programari, sincronització 

de codi nou en els sistemes de versions) que no ens 

permeten saber quant de temps ha necessitat el desenvolupador 

per a aconseguir-ho. 

95 





ANOTACIONS


ANOTACIONS 



apartat 72] 

96 


L’anàlisi d’aquestes xifres ens mostra que entorn d’un 80% dels desen- 

volupadors fan aquestes tasques en el temps lliure, mentre que no- 

més un de cada cinc es podria considerar que dedica tant de temps 

a aquesta activitat com un professional. Més endavant, en el capítol 

d’enginyeria del programari, podrem veure que aquesta dada con- 

corda amb la contribució dels desenvolupadors, ja que totes dues 

semblen seguir la llei de Pareto (vegeu l’apartat 7.6). 

4.6. Motivacions 

S’ha especulat i es continua especulant molt sobre les motivacions 

que hi ha al darrere del desenvolupament de programari lliure, so- 

bretot en el vessant d’activitat de temps lliure (que, com hem vist, cor- 

respon a prop d’un 80% dels desenvolupadors). Com en els apartats 

anteriors, només comptem amb les dades de les enquestes, per la 

qual cosa és important adonar-se que es tracta del que els desenvo- 

lupadors responen, que pot ser més o menys coherent amb la reali- 

tat. Els percentatges que es mostraran a continuació superen en total 

el 100%, ja que es donava la possibilitat als enquestats d’escollir en- 

tre diverses respostes. 

En qualsevol cas, de les respostes sembla desprendre’s que la majoria 

vol aprendre a desenvolupar noves habilitats (prop d’un 80%) i que 

molts ho fan per compartir coneixements i habilitats (50%) o per parti- 

cipar en una nova forma de cooperació (entorn d’un terç). La primera 

dada no sembla gens sorprenent, tenint en compte que un professio- 

nal amb més coneixements es cotitza més. Tanmateix, la segona dada 

no és tan fàcil d’explicar i fins i tot sembla anar en contra de l’afirmació 

de Nikolai Bezroukov, que afirma que els líders dels projectes de pro- 

gramari lliure tenen prou cura de no compartir tota la informació que 

posseeixen per a perpetuar el seu poder. Mentrestant, la tercera opció 

més freqüent és, sens cap dubte, un fidel reflex del fet que els mateixos 

desenvolupadors es mostren entusiasmats per la manera com es crea 

el programari lliure; és difícil trobar una indústria en què un grup de 

voluntaris poc organitzats pugui plantar cara tecnològicament a les 

grans companyies del sector. 

Mentre que la teoria “clàssica” per a explicar els motius pels quals els 

desenvolupadors de programari lliure es dediquen a portar projectes


de programari lliure gira entorn de la reputació i els beneficis econò- 

mics indirectes a mitjà i llarg termini, sembla que els desenvolupa- 

dors mateixos no hi estan d’acord. Només un 5% dels enquestats 

respon que desenvolupa programari lliure per guanyar diners, men- 

tre que el nombre de desenvolupadors que ho fan per obtenir repu- 

tació assoleix un 9%, lluny de les respostes que s’han presentat en el 

paràgraf anterior. En qualsevol cas, sembla que l’estudi de les moti- 

vacions que tenen els desenvolupadors per entrar a formar part de 

la comunitat del programari lliure és una de les tasques primordials 

amb què s’han d’enfrontar sociòlegs i psicòlegs en els pròxims 

temps. 

4.7. Lideratge 

Reputació i lideratge són dues característiques amb què s’ha tractat 

d’explicar l’èxit del programari lliure i en especial el del model de ba- 

sar, tal com veurem en el capítol dedicat a l’enginyeria del progra- 

mari. Com hem vist en un altre capítol, el dedicat a les llicències del 

programari, hi ha algunes diferències entre les llicències de progra- 

mari lliure i les seves homòlogues en el camp de la documentació. 

Aquestes diferències rauen en la manera com es preserven l’autoria 

i l’opinió de l’autor –més accentuada en textos que en programes. 

A Rishab A. Ghosh, Ruediger Glott, Bernhard Krieger i Gregorio Robles 

(2002), Free/lliure and open source programari: Survey and studypart iv: 

Survey of developers, es va incloure una pregunta en què s’instava 

els desenvolupadors a indicar les persones que coneixien d’una llista 

concreta, no necessàriament en persona. Els resultats es mostren en 

la taula 4-3, i determinen que aquestes persones es poden aglutinar 

en tres grups clarament diferenciats: 

Taula 4-3. Grau de coneixement de desenvolupadors importants 

Desenvolupador Conegut per 

Linus Torvalds 96,5% 

Richard Stallman 93,3% 

Miguel de Icaza 82,1% 

97 




apartat 104] 

ANOTACIONS


ANOTACIONS 



apartat 195] 


[Vegeu bibliografia, apartada 

185, 184, 187 i 95] 



apartat 214] 

98 


Un primer grup de gent amb clares connotacions filosoficohistòri- 

ques dins del món de programari lliure (encara que també tinguin, 

com es pot veure, aptituds tècniques notables): 

• Linus Torvalds: creador del nucli Linux del sistema operatiu 

GNU/Linux. Coautor de Just For Fun: the story of an accidental 

revolutionary. 

Desenvolupador Conegut per 

Eric Raymond 81,1% 

Bruce Perens 57,7% 

Jamie Zawinski 35,8% 

Mathias Ettrich 34,2% 

Jörg Schilling 21,5% 

Marco Presenti Gritti 5,7% 

Bryan Andrews 5,6% 

Guenter Bartsch 3,5% 

Arpad Gereoffy 3,3% 

Martin Hoffstede 2,9% 

Angelo Roulini 2,6% 

Sal Valliger 1,2% 

• Richard Stallman: ideòleg i fundador de la Fundació del Progra- 

mari Lliure i desenvolupador en diversos projectes GNU. Autor de 

diversos escrits molt importants dins del món del programari lliure. 

• Miguel de Icaza: cofundador del projecte GNOME i de Ximian 

Inc. Desenvolupador de part de GNOME i del projecte MONO. 

• Eric Raymond: impulsor de l’Open Source Initiative, autor de ”La 

catedral i el basar”. Desenvolupador principal de fetchmail. 

• Bruce Perens: antic líder del projecte Debian. Impulsor (convers) 

de l’Open Source Initiative. Desenvolupador de l’eina e-fence. 

• Jamie Zawinsky: exdesenvolupador de Mozilla, famós per una 

carta del 1999 en què deixava el projecte Mozilla argumentant 

que el model utilitzat mai no donaria fruits. 

• Mathias Ettrich: fundador de KDE. Desenvolupador de LyX i d’altres.


En el segon grup tenim desenvolupadors. Per a aquesta enquesta es van 

agafar els noms dels desenvolupadors principals dels sis projectes més 

populars en l’índex d’aplicacions de programari lliure FreshMeat. Es pot 

veure que (tret de Linus Torvalds, per raons òbvies, i de Jörg Schilling), 

el grau de coneixement d’aquests desenvolupadors és petit. 

• Jörg Schilling, creador de Cdrecord, entre altres aplicacions 

• Marco Presenti Gritti, desenvolupador principal de Galeon 

• Bryan Andrews, desenvolupador d’Apache Toolbox 

• Guenther Bartsch, creador de Xine 

• Arpad Gereoffy, desenvolupador d’MPEGplayer 

El tercer grup el componen els noms de les últimes tres “persones”. 

Aquests noms els va inventar l’equip de l’enquesta per poder com- 

provar el marge d’error de les respostes. 

Dels resultats es poden observar dues coses: la primera és que el 

marge d’error de les respostes es pot considerar petit (menys d’un 

3%). I la segona és que la majoria dels desenvolupadors de les apli- 

cacions de programari lliure més populars són tan coneguts com les 

persones que no existeixen. Aquesta dada pot fer pensar als que ad- 

dueixen el fet de buscar fama com una de les primeres causes per 

desenvolupar programari lliure. 

4.8. Resum i conclusions 

Aquest capítol ha pretès oferir una mica de llum sobre la força des- 

coneguda qüestió de la gent que dedica temps al programari lliure. 

En línies generals es pot afirmar que el desenvolupador de progra- 

mari lliure és un home jove amb estudis universitaris (o en via 

d’aconseguir-los). La relació del món del programari lliure amb la 

universitat (estudiants i professors) és molt estreta, encara que conti- 

nua predominant el desenvolupador que no té res a veure amb l’àm- 

bit acadèmic. 

Quant a la dedicació en nombre d’hores, s’ha mostrat que hi ha una 

gran desigualtat a l’estil de la postulada en la llei de Pareto. Les mo- 

tivacions dels desenvolupadors –segons ells mateixos–, lluny de ser 

99 


ANOTACIONS


ANOTACIONS 

100 


monetàries i egocèntriques, tal com solen assumir economistes i psi- 

còlegs, està més aviat centrada a compartir i aprendre. Per acabar, 

hem mostrat un quadre dels personatges del món del programari 

lliure més significatius (i d’altres de no tant, com s’ha pogut veure) i 

s’ha demostrat que la reputació en la gran comunitat del programari 

lliure sol dependre de més raons que no únicament la codificació 

d’una aplicació lliure reeixida.

5. Economia 


En aquest capítol es tracten alguns aspectes econòmics relacionats 

amb el programari lliure. Es comença mostrant com es financen els 

projectes de programari lliure (quan efectivament es financen, ja que 

moltes vegades es desenvolupen únicament amb treball i recursos 

aportats voluntàriament). A continuació, exposem els principals mo- 

dels de negoci que estan posant en pràctica les empreses relacionades 

directament amb el programari lliure. El capítol acaba amb un petit 

estudi sobre la relació entre el programari lliure i els monopolis en la 

indústria del programari. 

5.1. Finançament de projectes de programari 

lliure 

El programari lliure es desenvolupa de moltes maneres diferents, i 

amb mecanismes per a aconseguir recursos que varien molt d’un cas 

a l’altre. Cada projecte lliure té la seva manera de finançar-se, des 

del que està format completament per desenvolupadors voluntaris i 

utilitza només recursos cedits altruistament, fins al que duu a terme 

una empresa que factura el 100% dels seus costos a una entitat inte- 

ressada en el desenvolupament corresponent. 

En aquest apartat ens centrarem en els projectes on hi ha finança- 

ment extern, i no tota la feina feta és voluntària. En aquests casos, hi 

ha algun tipus de flux de capital amb origen extern al projecte que 

s’encarrega d’aportar recursos per al seu desenvolupament. Per tant, 

el programari lliure construït es pot considerar, d’alguna manera, 

com un producte d’aquest finançament extern. És per això que és 

normal que sigui aquesta font externa qui decideix (almenys parcial- 

ment) com i en què es gasten els recursos. 

D’alguna manera, aquest finançament extern per a projectes lliures 

es pot considerar com un tipus de patrocini, encara que aquest pa- 

101 


ANOTACIONS


ANOTACIONS 

102 


trocini no té per què ser desinteressat (i habitualment no ho és). En 

els apartats següents es comenten els tipus de finançament extern 

més habituals. Mentre el lector s’hi dediqui, convé, tanmateix, no 

oblidar que aquesta només és una de les maneres d’aconseguir re- 

cursos que tenen els projectes que construeixen programari lliure. 

N’hi ha d’altres, la més important: la feina de molts desenvolupadors 

voluntaris (com discutim en el capítol 4). 

5.1.1. Finançament públic 

Un tipus molt especial de finançament de projectes lliures és el pú- 

blic. L’entitat finançadora pot ser directament un govern (local, regio- 

nal, nacional o fins i tot supranacional) o una institució pública (per 

exemple, una fundació). En aquests casos, el finançament sol ser si- 

milar al dels projectes de recerca i desenvolupament, i de fet és molt 

habitual que provingui d’entitats públiques promotores d’R+D. Nor- 

malment, l’entitat finançadora no busca recuperar la inversió (o al- 

menys no de manera directa), encara que sol tenir objectius clars 

(afavorir la creació de teixit industrial i investigador, promoure certa 

tecnologia o un tipus determinat d’aplicacions, etc.). 

En la majoria d’aquests casos, no es troba explícitament el finança- 

ment de productes o serveis relacionats amb programari lliure, sinó 

que solen ser el subproducte d’un contracte amb altres finalitats més 

generals. Per exemple, la Comissió Europea, dins dels seus progra- 

mes d’investigació, finança projectes orientats a millorar la competi- 

tivitat europea en certes àrees. Alguns d’aquests projectes tenen com 

a part dels seus objectius utilitzar, millorar i crear programari lliure 

en el seu àmbit d’investigació (com a eina per a la investigació, o 

com a producte derivat). 

Les motivacions per a aquest tipus de finançament són molt variades, 

però podem destacar les següents: 

• Científica 

Aquest és el cas més habitual en projectes d’investigació finançats 

amb fons públics. Encara que el seu objectiu no és produir progra- 

mari, sinó fer recerca en algun camp determinat (relacionat o no


amb la informàtica), és molt possible que hi calgui desenvolupar 

programes que s’utilitzin com a eines necessàries per a assolir-ne 

els objectius. Normalment, el projecte no està interessat a comerci- 

alitzar aquestes eines, o fins i tot pot estar activament interessat per- 

què altres grups les utilitzin i millorin. En aquests casos, és bastant 

habitual distribuir aquestes eines com a programari lliure. Es pot dir 

que els recursos que va aconseguir el grup que duu a terme la re- 

cerca es van dedicar en part a la producció d’aquest programari, 

per la qual cosa es pot afirmar que es va desenvolupar amb finan- 

çament públic. 

• Promoció d’estàndards 

Tenir una implementació de referència és una de les millors maneres 

de promoure un estàndard. Moltes vegades això implica tenir pro- 

grames que formin part d’aquesta implementació (o que en siguin la 

implementació en si, si l’estàndard es refereix al camp del progra- 

mari); perquè la implementació de referència sigui d’utilitat en la 

promoció de l’estàndard, cal que estigui disponible, almenys per a 

comprovar-ne la interoperabilitat entre tots els qui vulguin desenvo- 

lupar productes que s’acullin a aquest estàndard. Moltes vegades 

també convé que els fabricants puguin adaptar directament la imple- 

mentació de referència per a usar-la, si volen en els seus productes. 

D’aquesta manera es van desenvolupar, per exemple, molts dels 

protocols d’Internet que avui s’han convertit en norma universal. En 

aquests casos, l’alliberament d’aquestes implementacions de refe- 

rència com a programari lliure pot ajudar molt a aquesta promoció, 

ja que el programari lliure és un subproducte de la promoció de l’es- 

tàndard, i habitualment, qui s’encarrega d’aquesta promoció és una 

entitat pública (encara que de vegades és un consorci privat). 

• Social 

El programari lliure és una eina molt interessant per a la creació de 

la infraestructura bàsica de la societat de la informació. Les entitats 

interessades a utilitzar programari lliure per a ajudar a proporcionar 

accés universal a aquesta societat de la informació poden finançar 

projectes relacionats amb el programari lliure (normalment projectes 

de desenvolupament de noves aplicacions o d’adaptació d’altres 

existents). 

103 


ANOTACIONS


ANOTACIONS 

104 


Nota 

Un exemple de finançament públic amb finalitat fonamentalment 

social és el cas de LinEx, promogut per la 

Junta d’Extremadura (Espanya) per a promoure la societat 

de la informació sobretot pel que fa a l’alfabetització 

informàtica. La Junta ha finançat el desenvolupament 

d’una distribució basada en Debian per tal d’aconseguir 

aquest objectiu. Un altre cas semblant és el del 

finançament per part del Govern alemany de desenvolupaments 

de GNUPG orientats a facilitar-ne l’ús als 

usuaris no experimentats, amb la idea d’afavorir l’ús 

del correu segur entre els ciutadans. 

El desenvolupament de GNAT 

Exemple 

Un cas famós de finançament públic per al desenvolupament 

de programari lliure va ser el del compilador 

GNAT. Es tracta d’un compilador d’Ada que va ser finançat 

pel projecte Ada9X del Departament de Defensa 

dels Estats Units d’Amèrica amb la idea de tenir un 

compilador de la nova versió del llenguatge de programació 

Ada (la que després va ser Ada95), l’ús del 

qual es tractava de promoure en aquella època. Un 

dels problemes per a l’adopció de la primera versió 

d’Ada (Ada83) per les empreses de programari era no 

haver disposat de seguida d’un compilador del llenguatge, 

i l’alt preu que tenia quan per fi va estar disponible. 

Per això es va intentar que no passés el mateix 

amb Ada95, i calia assegurar que hi hauria un compilador 

gairebé alhora que sortís la publicació del nou 

estàndard del llenguatge. 

Per a aconseguir-ho, el projecte Ada9X va contractar 

un equip de la Universitat de Nova York (NYU) per un 

import aproximat d’un milió de dòlars per a la realització 

d’una “prova de concepte” de compilador 

d’Ada95. Amb aquests fons, i aprofitant l’existència 

de GCC (el compilador de C de GNU, del qual es va 

aprofitar la major part del dorsal), l’equip de l’NYU 

va construir efectivament el primer compilador de 

l’Ada95, que va alliberar sota la GNU GPL. El compilador 

va tenir tant d’èxit que, en acabar el projecte, 

part dels constructors van fundar una empresa (Ada 

Core Tecnologies), que des de llavors s’ha convertit en


5.1.2. Finançament privat sense ànim de lucre 

Aquest és un tipus de finançament amb moltes característiques similars 

a les del cas anterior, en què el finançament sovint corre a compte de 

fundacions o organitzacions no governamentals. La motivació directa 

en aquests casos sol ser produir programari lliure per a utilitzar-lo en 

algun àmbit que l’entitat finançadora considera especialment relle- 

vant, però també es pot trobar la motivació indirecta de contribuir a 

resoldre un problema (per exemple, una fundació dedicada a pro- 

moure la investigació sobre una malaltia pot finançar la construcció 

d’un programa estadístic que ajudi a analitzar grups d’experimenta- 

ció on s’estudia aquesta malaltia). 

En general, tant els motius com els mecanismes d’aquest finança- 

ment són molt semblants als del finançament públic, encara que, na- 

turalment, sempre estan marcats pels objectius de l’entitat que els 

finança. 

líder del mercat de compiladors i eines per a la construcció 

de programes en Ada. 

És notable com en aquest projecte es pot veure la combinació 

d’elements d’investigació (aquest projecte va 

avançar en el coneixement sobre la construcció de frontals 

i de sistemes de temps d’execució per a compiladors 

de llenguatges tipus Ada) i de promoció d’estàndards 

(que era l’objectiu més clar del seu finançador). 

Nota 

Segurament, el cas paradigmàtic de fundació que 

promou el desenvolupament de programari lliure si- 

gui la Free Software Foundation (FSF). Des de la meitat 

dels vuitanta aquesta fundació es dedica a la promoció 

del projecte GNU, i a fomentar en general el desenvo- 

lupament del programari lliure. 

105 


ANOTACIONS


ANOTACIONS 

106 


Un altre cas interessant, encara que en un altre àmbit 

bastant diferent, és l’Open Bioinformatics Foundation. 

Entre les finalitats d’aquesta fundació hi ha la de pro- 

moure el desenvolupament dels programes informàtics 

bàsics per a investigar qualsevol de les branques de la bi- 

oinformática. I, en general, promou aquesta activitat fi- 

nançant i ajudant en la construcció de programes lliures. 

5.1.3. Finançament per a qui necessita millores 

Un altre tipus de finançament per al desenvolupament de programa- 

ri lliure, ja no tan altruista, és el que té lloc quan algú necessita mi- 

llores en un producte lliure. Per exemple, una empresa necessita per 

a ús intern certa funcionalitat en un programa concret. O bé, que es 

corregeixin determinats errors en un programa. En aquesta mena de 

casos, l’habitual és que l’empresa en qüestió contracti el desenvolu- 

pament que necessita. Aquest desenvolupament, molt sovint (perquè 

ho imposa la llicència del programa modificat o perquè l’empresa 

així ho decideix) és programari lliure. 

El cas de Corel i Wine 

5.1.4. Finançament amb beneficis relacionats 

Exemple 

Al final de la dècada dels noranta, Corel va decidir por- 

tar els seus productes a GNU/Linux. En el procés, va 

descobrir que un programari lliure dissenyat per a faci- 

litar l’execució de binaris per a Windows en entorns Li- 

nux li podria estalviar molt de desenvolupament. Però 

per a això calia millorar-lo, fonamentalment afegint-hi 

l’emulació d’una funcionalitat de Windows que els pro- 

grames de Corel utilitzen. 

Perquè es fessin aquestes millores, Corel va contractar 

Macadamian, que va contribuir amb les seves millores 

al projecte Wine. Amb això, tant Corel com Wine van 

sortir beneficiats. 

En aquest cas, l’entitat finançadora busca aconseguir beneficis en 

productes relacionats amb el programa al desenvolupament del qual


aporta recursos. Normalment, en aquests casos els beneficis que 

obté l’empresa finançadora no són exclusius, ja que altres empreses 

poden entrar al mercat de la venda de productes relacionats. Però, 

o la quota de mercat que té és suficient perquè no li preocupi gaire 

repartir el pastís amb altres empreses, o bé hi té algun avantatge 

competitiu clar. 

Alguns exemples de productes relacionats amb un programari con- 

cret són: 

• Llibres 

L’empresa en qüestió ven manuals, guies d’ús, textos per a cursos, 

etc., relacionats amb el programa lliure que ajuda a finançar. Sens 

dubte, hi ha altres empreses que també poden vendre llibres relacionats 

amb el programari, però normalment el fet de finançar el projecte li 

proporcionarà l’accés a desenvolupadors clau abans que als seus 

competidors, o simplement aconseguirà una bona imatge amb vista 

a la comunitat d’usuaris del programa en qüestió. 

• Maquinari 

Si una empresa finança el desenvolupament de sistemes lliures per a 

cert tipus de maquinari, es pot dedicar a vendre amb més facilitat 

aquest tipus de maquinari. De nou, en ser lliure el programari desenvo- 

lupat, poden aparèixer competidors que venguin aparells del mateix 

tipus usant aquests desenvolupaments però sense col·laborar en el fi- 

nançament. Tot i així, l’empresa en qüestió té diversos avantatges so- 

bre els competidors, i un en pot ser que la seva posició com a 

aportadora de recursos al projecte li permet influir per a aconseguir 

la prioritat en els desenvolupaments que més li interessin. 

• CD amb programes 

Segurament, el model més conegut és el de les empreses que finan- 

cen alguns desenvolupaments que després apliquen a la seva distri- 

bució de programari. Per exemple, tenir un bon entorn d’escriptori 

pot ajudar molt a vendre CD amb una certa distribució de GNU/Linux 

i, per tant, finançar-ne el desenvolupament pot ser un bon negoci per 

a qui els vengui. 

107 


ANOTACIONS


ANOTACIONS 

108 


És important adonar-se que, en aquest apartat, el finançament en 

qüestió ha de tenir finalitat de lucre. Tanmateix, en els casos reals és 

habitual que sempre hi hagi una combinació de finalitat de lucre i d’al- 

truisme quan una empresa aporta recursos per fer un programa lliure 

del qual espera beneficiar-se indirectament. 

5.1.5. Finançament com a inversió interna 

Nota 

Un cas molt conegut d’aportació de recursos a un pro- 

jecte, si bé de manera relativament indirecta, és l’ajuda 

que l’editorial O’Reilly presta al desenvolupament de 

Perl. Naturalment, no és casualitat que aquesta editori- 

al també sigui una de les principals editores sobre te- 

mes relacionats amb Perl. En qualsevol cas, és obvi que 

O’Reilly no té l’exclusiva de l’edició de llibres d’aquest 

tipus, i altres editorials competeixen en aquest segment 

de mercat, amb èxits diferents. 

VA Software (al seu començament VA Research, i més 

tard VA Linux) ha col·laborat activament en el desen- 

volupament del nucli de Linux. Amb això ha aconse- 

guit, entre altres coses, col·laborar a assegurar-ne la 

continuïtat, cosa que era especialment crític per als 

seus clients, quan el seu principal negoci era vendre 

equips amb GNU/Linux preinstal·lat. 

Red Hat ha finançat el desenvolupament de molts com- 

ponents de GNOME, amb la qual cosa ha aconseguit, 

sobretot, tenir un entorn d’escriptori per a distribuir 

aquests components, que ha contribuït a augmentar-ne 

les vendes. Com altres vegades, altres fabricants de dis- 

tribucions s’han beneficiat d’aquest desenvolupament, 

encara que molts no hagin col·laborat amb el projecte 

GNOME de la mateixa manera que Red Hat (i no en són 

pocs els que no han col·laborat en res). Malgrat això, 

Red Hat es beneficia de la seva contribució a GNOME. 

Hi ha empreses que desenvolupen programari lliure directament 

com a part del seu model de negoci. Per exemple, una empresa pot


decidir iniciar un nou projecte lliure en un àmbit on percep que hi pot 

haver oportunitats de negoci, amb la idea de rendibilitzar posterior- 

ment aquesta inversió. Aquest model es podria considerar una variant 

de l’anterior (finançament indirecte), en què els “beneficis relacionats” 

són els avantatges que obtingui l’empresa per la producció del pro- 

grama lliure. Però, perquè en aquest cas sigui el producte lliure en si 

mateix el que s’espera que produeixi els beneficis, sembla convenient 

obrir una classificació específica per a aquests casos. 

Aquest tipus de finançament dóna lloc a diversos models de negoci. 

Quan s’analitzin aquests models –en l’apartat 5.2– s’explicaran també 

els avantatges que una empresa obté normalment d’aquesta inversió 

en un projecte, i quins mètodes se solen utilitzar per a rendibilitzar-la. 

De tota manera, podem destacar que pot ser que algunes vegades 

el programari en qüestió es desenvolupi simplement per a satisfer les 

necessitats de la mateixa empresa, i que només després es decideixi 

alliberar-la, i potser obrir-hi una línia de negoci relacionada. 

Nota 

Digital Creations (avui Zope Corporation) és un dels ca- 

sos més coneguts d’empresa que es dedica al desenvo- 

lupament de programari lliure amb l’esperança de 

rendibilitzar-ne la inversió. El projecte lliure en què més 

està invertint és Zope, un servidor d’aplicacions que està 

tenint un cert èxit. La seva història amb el programari 

lliure va començar quan la llavors Digital Creations 

buscava capital de risc per a desenvolupar el servidor 

d’aplicacions propietari, cap al 1998. Un dels grups in- 

teressats a invertir-hi (Opticality Ventures) els va posar 

com a condició que el producte resultant havia de ser 

lliure, perquè en cas contrari no veien com podria 

aconseguir una quota de mercat significativa. Digital 

Creations es va decidir per aquest camí, i pocs mesos 

després anunciava la primera versió de Zope (uns 

quants anys després va canviar de nom). Avui dia Zope 

Corporation està especialitzada a oferir serveis de con- 

sultoria, formació i suport per a sistemes de gestió de 

continguts basats en Zope, i altres productes en què, 

sens dubte, Zope n’és la pedra angular. 

109 


ANOTACIONS


ANOTACIONS 



apartat 16] 

110 


5.1.6. Altres modes de finançament 

Hi ha altres modes de finançament difícils de classificar entre els an- 

teriors. En podem destacar, com a exemple, els següents: 

• Utilització de mercats per a posar en contacte desenvolupadors 

i clients 

Ximian (abans Helix Code) és un cas ben conegut de 

desenvolupament d’aplicacions lliures en entorn empresarial. 

Molt lligada des dels seus orígens al projecte 

GNOME, Ximian ha produït programari com Evolution 

(un gestor d’informació personal que té una funcionalitat 

relativament similar a la que ofereix MS Outlook), 

Red Carpet (un sistema fàcil d’usar per a la gestió de paqueteria 

en un sistema operatiu) i Mono (una implementació 

de gran part de .NET). L’empresa es va fundar 

l’octubre del 1999 i va atraure molts desenvolupadors de 

GNOME, que van passar a formar part dels seus desenvolupadors 

(moltes vegades, continuant la seva col·laboració 

amb el projecte GNOME). Ximian es va posicionar 

com una empresa d’enginyeria experta en adaptacions 

de GNOME, en construcció d’aplicacions basades en 

GNOME i, en general, en subministrament de serveis de 

desenvolupament basats en programari lliure, especialment 

d’eines relacionades amb l’entorn d’escriptori. 

L’agost del 2003, Ximian va ser adquirida per Novell. 

Cisco Enterprise Print System (CEPS) és un sistema de 

gestió d’impressió per a organitzacions amb gran 

quantitat d’impressores. Es va desenvolupar internament 

per a satisfer les necessitats de Cisco, i es va alliberar 

l’any 2000 sota la GNU GPL. És difícil estar segur 

dels motius que Cisco va tenir, però és possible que tingués 

a veure amb la recerca de contribucions externes 

(informes d’error, nous controladors, pedaços, etc.). En 

qualsevol cas, és clar que, en no tenir Cisco cap pla per 

a comercialitzar el producte i no estar-ne gaire clar el 

mercat potencial, no hi havia de perdre gran cosa. 

La idea que sosté aquest tipus de finançament és que, sobretot per a 

petits desenvolupaments, és difícil que un client que ho desitgi pugui


entrar en contacte amb un desenvolupador que ho pugui emprendre 

de manera eficient. Per a millorar aquesta situació, es postulen els 

mercats de desenvolupament de programari lliure en què els desen- 

volupadors publicarien les seves habilitats i els clients, els desenvolu- 

paments que necessiten. Quan un desenvolupador i un client es 

posen d’acord, tenim una situació similar a la ja descrita en l’apartat 

5.1.3 de “finançament per qui necessita les millores”. 

SourceXchange 

• Venda de bons per finançar un projecte 

Exemple 

SourceXchange va ser un exemple de mercat per a posar 

en contacte desenvolupadors amb els seus clients poten- 

cials. Per a oferir un projecte, un client escrivia una RFP 

(request for proposal, o ‘petició de proposta’), en la qual 

especificava quin desenvolupament necessitava i quants 

recursos hi estava disposat a proporcionar. Aquestes RFP 

es publicaven en el lloc web. Quan un desenvolupador 

en veia una que li interessava, hi feia una oferta. Quan 

un desenvolupador i un client es posaven d’acord en els 

termes del desenvolupament, el projecte començava. 

Normalment, cada projecte estava supervisat per un 

peer reviewer, o revisor, que s’encarregava d’assegurar- 

se que el desenvolupador complia les especificacions i 

que aquestes tenien efectivament sentit, que aconsellava 

sobre com tirar endavant el projecte, etc. SourceXchange 

(propietat de l’empresa CollabNet) s’encarregava d’ofe- 

rir el lloc, garantir la competència dels revisors, assegu- 

rar el pagament en cas que els projectes es completessin 

i oferir eines per al seguiment del projecte (serveis que el 

client facturava). El primer projecte mitjançat per Sour- 

ceXchange es va acabar el març del 2000, però poc més 

d’un any després, l’abril del 2001, el lloc va tancar. 

Aquesta idea de finançament és similar a la dels mercats de bons als 

quals acudeixen les empreses, però orientada al desenvolupament 

de programari lliure. Presenta unes quantes variants, però una de les 

més conegudes funciona com expliquem a continuació. Quan un 

111 


ANOTACIONS


ANOTACIONS 



apartats 132, 133 i 116] 

112 


desenvolupador (individual o empresa) té una idea un programa nou 

o una millora en un que que ja existeix, l’escriu amb forma d’especi- 

ficació, n’estima el cost que tindria i emet bons per a construir-lo. 

Aquests bons tenen un valor que només s’executa si el projecte final- 

ment s’acaba. Quan el desenvolupador ha venut prou bons, comen- 

ça el desenvolupament, que va finançant amb préstecs basats en els 

bons. Quan el desenvolupament acaba i alguna tercera part inde- 

pendent certifica que efectivament el que s’ha fet compleix les espe- 

cificacions, el desenvolupador “executa” els bons que havia venut, 

paga els deutes, i el que en queda són els beneficis que obté pel des- 

envolupament. 

Qui estaria interessat a adquirir aquests bons? Òbviament, els usuaris 

que volguessin que aquest nou programa o aquesta millora es fessin 

realitat. D’alguna manera, aquest sistema de bons permetria que les 

parts interessades fixessin (si més no, parcialment) les prioritats dels 

desenvolupadors mitjançant la compra de bons. Això permetria al 

mateix temps que no fes falta que una sola entitat assumís els costos 

de desenvolupament, sinó que es podrien repartir entre moltes (in- 

cloent-hi individus) que, a més, només haurien de pagar si finalment 

el projecte acaba amb èxit. Un mecanisme molt similar a aquest es 

proposa amb molt més detall a Chris Rasch (2001, maig). “The Wall 

Street performer protocol. using programari completion bonds to 

fund open source programari development”. First Monday (vol. 6, 

núm. 6). 

Nota 

El sistema de bons descrit està basat en l’Street Performer 

Protocol (protocol de l’artista de carrer), un mecanis- 

me basat en el comerç electrònic dissenyat per a faci- 

litar el finançament privat de treballs de creació lliures. 

En poques paraules, el sistema consisteix en el se- 

güent: qui estigui interessat en el desenvolupament 

d’un treball determinat prometrà formalment pagar-hi 

una certa quantitat si el treball es fa i es publica lliure- 

ment. La finalitat és buscar una nova manera de finan- 

çar treballs relativament petits que quedin a disposició 

de tothom, però es pot estendre de moltes maneres 

(els bons per a la construcció de programari lliure en 

són una).


Es pot veure un petit cas de posada en pràctica d’un 

derivat d’aquest protocol (el Rational Street Performer 

Protocol, protocol racional de l’artista de carrer, Paul 

Harrison) a: 

• Cooperatives de desenvolupadors 

En aquest cas, els desenvolupadors de programari lliure, en lloc de 

treballar individualment o per a una empresa, es reuneixen en algun 

tipus d’associació (normalment similar a una cooperativa). Fora d’ai- 

xò, el funcionament és similar al d’una empresa, matisat potser pel 

compromís ètic amb el programari lliure, que pot ser-ne part dels es- 

tatuts (encara que una empresa també ho pot fer). En aquest tipus 

d’organitzacions es poden trobar combinacions variades de treball 

voluntari amb treball remunerat. Un exemple d’aquest tipus d’orga- 

nització és Free Developers. 

http://thecircle.org.au/funding_results.html, 

on s’aplica a la consecució de fons per al finançament 

de part de The Circle, un projecte de programari lliure. 

5.2. Models de negoci basats en programari lliure 

A més dels mecanismes de finançament dels projectes, ja tractats, un 

altre aspecte molt relacionat amb l’economia que val la pena tractar 

és el dels models de negoci. Ja se n’han esmentat alguns breument 

en parlar d’aquests mecanismes de finançament, però ara, en 

aquest apartat, els descriurem de manera una mica més metòdica. 

En general, es pot dir que entorn del programari lliure s’estan explo- 

rant molts models de negoci, alguns de més clàssics i d’altres de més 

innovadors. Cal tenir en compte que entre els models més habituals 

en la indústria del programari no és fàcil utilitzar els models basats 

en la venda de llicències d’ús de programes produïts, ja que en el 

món del programari lliure aquest és un mecanisme de finançament 

molt difícil d’explotar. Tanmateix, sí que es poden utilitzar els que estan 

basats en el servei a tercers, amb l’avantatge que, sense ser necessària- 

ment el productor d’un programa, se li pot donar un suport complet. 

113 


ANOTACIONS


ANOTACIONS 

114 


aaa 

Venda de programari lliure a tant per còpia 

En el món del programari lliure és difícil cobrar llicències 

d’ús, però en general, no impossible. Normalment, no hi 

ha res en les definicions de programari lliure que impe- 

deixi que una empresa creï un producte i només es dis- 

tribueixi a qui li pagui una certa quantitat. Per exemple, 

un productor podria decidir distribuir el seu producte 

amb una llicència lliure, però només a qui li pagui mil 

euros per còpia (de manera semblant a com es fa en el 

món clàssic del programari propietari). 

Tanmateix, encara que això és teòricament possible, a 

la pràctica no acostuma a passar perquè, un cop el 

productor ha “venut” la primera còpia, qui la rep pot 

voler intentar recuperar la seva inversió venent més cò- 

pies a un preu més baix (una cosa que no pot prohibir 

la llicència del programa, si és lliure). En l’exemple an- 

terior, podria tractar de vendre deu còpies a cent euros 

cadascuna, amb la qual cosa el producte li sortiria gra- 

tis (i a més dificultaria molt que el productor original 

vengués una altra còpia a 1.000 euros, si el producte 

es pot obtenir legalment per la desena part). És fàcil 

deduir que aquest procés continuaria en cascada fins a 

la venda de còpies a un preu proper al cost marginal 

de còpia, que amb les tecnologies actuals és pràctica- 

ment zero. 

Tot i així, i tenint en compte que el mecanisme descrit propiciarà que 

normalment el productor no pugui posar un preu (especialment, un 

preu alt) al simple fet de la redistribució del programa, hi ha models 

de negoci que implícitament fan justament això. Un exemple és el de 

les distribucions de GNU/Linux, que es venen per un preu molt baix 

comparat amb els dels seus competidors propietaris, però superior (i 

normalment clarament superior) al cost de còpia (fins i tot quan es 

poden baixar lliurement d’Internet). Sens dubte, en aquests casos hi 

juguen altres factors, com ara la imatge de marca o la comoditat per 

al consumidor. Però aquest no és l’únic cas. Per tant, més que indicar


que el programari lliure “no es pot vendre a un tant per còpia”, cal 

tenir en compte que és més difícil de fer, i probablement se n’obtin- 

drà menys benefici, però que hi pot haver models basats justament 

en això. 

Ateses aquestes limitacions (i aquests avantatges) des de fa uns 

quants anys s’estan provant variants dels models de negoci habituals 

en la indústria que són viables amb programari, alhora que es bus- 

quen models innovadors, que tracten d’explotar les noves possibili- 

tats que ofereix el programari lliure. Sens dubte, en els pròxims anys 

veurem encara més experimentació en aquest camp, i també tindrem 

més informació sobre quins models poden funcionar bé, i en quines 

circumstàncies. 

En aquest apartat oferirem una panoràmica dels que ens trobem 

més habitualment avui dia, agrupats amb la intenció de mostrar al 

lector el que tenen en comú i el que els diferencia, centrant-nos en 

els models basats en el desenvolupament i els serveis entorn d’un 

producte de programari lliure. Els ingressos en aquest cas provenen 

directament d’aquestes activitats de desenvolupament i serveis per 

al producte, però no impliquen necessàriament desenvolupament 

de productes nous. Quan sí que es fa desenvolupament, aquests 

models tenen com a “subproducte” el finançament de productes de 

programari lliure, per la qual cosa són models especialment inte- 

ressants, i el seu impacte sobre el món del programari lliure en ge- 

neral pot ser gran. 

En qualsevol cas, i encara que aquí oferim una classificació relativa- 

ment estricta, no s’ha d’oblidar que gairebé totes les empreses utilitzen 

models mixtos, que són en realitat combinacions dels models que 

hem descrit, entre aquests i amb d’altres de més tradicionals. 

5.2.1. Més bon coneixement 

L’empresa que utilitza aquest model de negoci tracta de rendibilitzar 

el seu coneixement d’un producte (o conjunt de productes) lliure. Els 

seus ingressos provindran de clients a qui vendrà serveis relacionats 

amb aquest coneixement, típicament desenvolupaments basats en el 

producte, modificacions, adaptacions, instal·lacions i integracions 

amb d’altres. L’avantatge competitiu de l’empresa estarà molt rela- 

115 


ANOTACIONS


ANOTACIONS 

116 


cionat amb el més bon coneixement del producte que el que tenen 

els competidors: és per això que l’empresa estarà especialment ben 

situada si és productora del producte o participa en el projecte que 

el produeix. 

Aquesta és una de les raons per la qual les empreses que utilitzen 

aquest model solen participar activament en els projectes relacionats 

amb el programari del qual tracten de vendre serveis: és una manera 

molt eficient d’obtenir-ne coneixements, i el que és més important, 

que aquest coneixements siguin reconeguts. Sens dubte, explicar a 

un client que entre els empleats hi ha desenvolupadors del projecte 

que produeix el programari que, per exemple, es vol modificar, pot 

ser una bona garantia. 

aaa 

Relació amb els projectes de desenvolupament 

Per tant, aquest tipus d’empreses té un gran interès a 

donar la imatge de posseir un bon coneixement de 

determinats productes lliures. Una conseqüència interessant 

d’això és que el seu suport a projectes de programari 

lliure (per exemple, participant-hi activament o 

permetent que els empleats ho facin durant la jornada 

laboral) no és una cosa merament filantròpica. Al contrari, 

pot ser un dels actius més rendibles de l’empresa, 

ja que els seus clients ho valoraran molt positivament, 

com una mostra clara que coneixen el producte. A més, 

d’aquesta manera podran seguir-ne el desenvolupament 

molt d’a prop, i tractar d’assegurar-se, per exem- 

ple, que algunes de les millores demanades pels seus 

clients passen a formar part del producte desenvolupat 

pel projecte. 

Si s’analitza des d’un punt de vista més general, aquesta 

és una situació en què totes dues parts, l’empresa i 

el projecte de desenvolupament, hi guanyen. El projecte 

guanya pel desenvolupament que fa l’empresa, o 

perquè alguns dels seus desenvolupadors passen a ser 

remunerats (si més no, parcialment) per treballar-hi. 

L’empresa guanya en coneixement del producte, en 

imatge cap als seus clients i en una certa influència sobre 

el projecte.


Els serveis que proporcionen aquest tipus d’empreses poden ser molt 

variats, però normalment consisteixen en desenvolupaments a mida, 

adaptacions o integracions dels productes en què estan especialitza- 

des, o bé serveis de consultoria, on aconsellen als seus clients com 

utilitzar el producte per treure’n més profit (especialment si és complex, 

o si el seu correcte funcionament és crític per al client en qüestió). 

5.2.2. Més bon coneixement amb limitacions 

Exemple 

Alguns exemples d’empreses que fins a cert punt utilitzen 

aquest model de negoci són els següents: 

• LinuxCare 

Fundada el 1996, en els orígens proporcionava serveis 

de consultoria i suport per a GNU/Linux i programari 

lliure als Estats Units d’Amèrica i la seva plantilla estava 

composta fonamentalment per experts en GNU/Linux. 

Tanmateix, el 1992 va canviar els seus objectius, i des 

de llavors s’ha especialitzat a proporcionar serveis gairebé 

exclusivament a Linux executat sobre màquines 

virtuals z/VM en grans ordinadors d’IBM. El seu model 

de negoci ha canviat també a “més bon coneixement 

amb limitacions”, en oferir com a part fonamental dels 

seus serveis una aplicació no lliure, Levanta. 

• Alcove 

Fundada el 1997 a França, proporciona sobretot serveis 

de consultoria, consultoria estratègica, suport i 

desenvolupament per a programari lliure. Des de la 

seva fundació, Alcove ha mantingut en plantilla desenvolupadors 

de diversos projectes lliures, i l’ha tractat en 

general de rendibilitzar en termes d’imatge. També ha 

tractat d’oferir una imatge d’empresa vinculada a la 

comunitat de programari lliure, per exemple, col·laborant 

amb associacions d’usuaris i donant publicitat 

a les seves col·laboracions amb projectes lliures (per 

exemple, des d’Alcove-Labs). 

Aquests models són semblants als exposats en l’apartat anterior, però 

tracten de limitar la competència a què es poden veure sotmesos. Men- 

117 




apartat 84] 




ANOTACIONS


ANOTACIONS 



apartat 15] 

118 


tre que en els models “purs” basats en el més bon coneixement, qualse- 

vol pot, en principi, entrar en competència, ja que el programari utilitzat 

és el mateix (i lliure), en aquest cas es tracta d’evitar aquesta situació po- 

sant barreres a aquesta competència. Aquestes barreres solen consistir 

en patents o llicències propietàries, que normalment afecten una part 

petita (però fonamental) del producte desenvolupat. Per aquesta raó, 

aquests models es poden considerar en realitat com a mixtos, en el sentit 

que estan a cavall del programari lliure i el propietari. 

Moltes vegades, la comunitat del programari lliure desenvolupa la 

seva pròpia versió del component, amb la qual pot desaparèixer 

l’avantatge competitiu, o fins i tot tornar-se en contra de l’empresa, 

si el competidor lliure es converteix en l’estàndard del mercat i és de- 

mandat pels seus clients. 

Exemple 

Són molts els casos en què s’utilitza aquest model de 

negoci, ja que sovint se’l considera menys arriscat que el 

de coneixement “pur”. Tanmateix, les empreses que l’han 

utilitzat han tingut evolucions diverses. Algunes són: 

• Caldera 

La història de Caldera és complicada. En els seus inicis, 

va crear la seva distribució de GNU/Linux, orientada a 

empreses: Caldera OpenLinux. El 2001 va comprar la 

divisió de UNIX de SCO, i el 2002 va canviar el seu 

nom a “SCO Group”. La seva estratègia empresarial 

ha donat tants tombs com el seu nom, des del suport 

total a Linux fins a les demandes contra IBM i Red Hat 

el 2003, i l’abandonament de la seva distribució. Però 

pel que fa a aquest apartat, el negoci de Caldera, al- 

menys fins al 2002, és un clar exponent del més bon 

coneixement amb limitacions. Caldera tractava de fer 

explotar el seu coneixement de la plataforma GNU/Li- 

nux, però limitant la competència a què es podia veure 

sotmesa mitjançant la inclusió de programari propieta- 

ri en la distribució. Això feia difícil que els clients canvi- 

essin de distribució quan l’haguessin adoptat, ja que 

encara que les altres distribucions de GNU/Linux inclo- 

ïen la part lliure de Caldera Open-Linux, no hi trobaven 

la part propietària.

5.2.3. Font d’un producte lliure 


Aquest model és similar al de més bon coneixement, però se’n dife- 

rencia pel fet que s’especialitza de manera que l’empresa que l’uti- 

litza és, gairebé en la seva totalitat, productora d’un producte lliure. 

Naturalment, l’avantatge competitiu augmenta en ser aquests els 

desenvolupadors del producte, controlar-ne l’evolució, i tenir-lo 

abans que la competència. Tot això posiciona l’empresa desenvo- 

lupadora en un lloc molt bo amb vista als clients que vulguin serveis 

sobre aquest programa. A més, és un model molt interessant en ter- 

mes d’imatge, ja que l’empresa ha demostrat el seu potencial desen- 

volupador amb la creació i el manteniment de l’aplicació, la qual cosa 

pot ser molt interessant a l’hora de convèncer de les seves capacitats 

els possibles clients. Igualment, proporciona molt bona imatge amb 

vista a la comunitat del programari lliure en general, ja que reben un 

nou producte lliure de l’empresa, que passa a formar part del patri- 

moni comú. 

• Ximian 

Fundada el 1999 amb el nom d’Helix Code per desen- 

volupadors molt vinculats al projecte GNOME, va ser 

adquirida l’agost del 2003 per Novell. La major part 

del programari que ha desenvolupat ha estat lliure (en 

general, parteix de GNOME). Tanmateix, en un àmbit 

molt concret Ximian va decidir llicenciar un component 

com a programari propietari: el Connector for Exchange. 

Aquest és un mòdul que permet que un dels productes 

estrella, Evolution (un gestor d’informació personal que 

inclou correu electrònic, agenda, calendari, etc.) inte- 

ractuï amb servidors MS Exchange, molt utilitzats en 

grans organitzacions. D’aquesta manera, tracta de 

competir avantatjosament amb altres empreses que 

proporcionen serveis basats en GNOME, potser amb 

els productes desenvolupats per la mateixa Ximian, que 

no podrà interaccionar tan fàcilment amb Exchange. 

Excepte per aquest producte, el model de Ximian ha es- 

tat un model de “més bon coneixement”, basat alhora 

en el fet de ser la font d’un programa. 

119 




apartat 58] 

ANOTACIONS


ANOTACIONS 



apartat 59] 

120 


Exemple 

Són molts els productes lliures que van començar el 

desenvolupament dins d’una empresa, i molt habitual- 

ment ha estat la mateixa empresa qui n’ha guiat el 

desenvolupament posterior. Com a exemple, podem 

esmentar els casos següents: 

• Ximian 

Ja hem esmentat que, en part, ha usat el model de 

més bon coneixement amb limitacions. Però, en ge- 

neral, Ximian ha seguit un model clar basat en el fet 

de ser la font de programes lliures. Els seus princi- 

pals productes, com Evolution, RedCarpet o Mono, 

s’han distribuït sota llicències de GNU, i Ximian els 

ha desenvolupat gairebé en exclusiva des del comen- 

çament. L’empresa ha tractat de rendibilitzar aquest 

desenvolupament aconseguint contractes per fer-los 

evolucionar en determinats sentits, per a adaptar-los 

a les necessitats dels seus clients i oferir personalitza- 

ció i manteniment. 

• Zope Corporation 

El 1995 es funda Digital Creations, que desenvolupa 

un producte propietari per a la gestió d’anuncis clas- 

sificats pel web. El 1997 va rebre una injecció de ca- 

pital per part, entre d’altres, d’una empresa de capital 

risc, Opticality Ventures. L’estrany d’aquesta inversió 

(en aquella època) és que van posar com a condició 

que distribuís com a programari lliure l’evolució del 

seu producte, que més endavant va ser Zope, un dels 

gestors de continguts més populars a Internet. El mo- 

del de negoci de l’empresa des de llavors va ser 

produir Zope i els productes relacionats, i oferir ser- 

veis d’adaptació i manteniment per a tots aquests pro- 

ductes. Zope Corporation ha sabut, a més, crear una 

dinàmica comunitat de desenvolupadors de progra- 

mari lliure entorn dels seus productes, i col·laborar-hi 

activament.

5.2.4. Font d’un producte amb limitacions 


Aquest model és similar a l’anterior, però inclou mesures per limitar 

la competència o maximitzar els ingressos. Entre les limitacions més 

habituals podem considerar les següents: 

• Distribució propietària durant un temps, després lliure 

Amb promesa de distribució lliure posterior o sense, cada nova ver- 

sió del producte es ven com a programari propietari. Passat un 

temps (normalment, quan es comença a comercialitzar una versió 

nova, també com a programari propietari), aquesta versió passa a 

distribuir-se amb una llicència lliure. D’aquesta manera, l’empresa 

productora obté ingressos dels clients interessats a disposar de no- 

ves versions com més aviat millor, i alhora minimitza la competèn- 

cia, ja que qualsevol empresa que vulgui competir utilitzant aquest 

producte només ho podrà fer amb la versió lliure (disponible només 

quan ja hi ha una nova versió propietària, que se suposa més bona 

i més completa). 

• Distribució limitada durant un quant temps 

En aquest cas, el programari és lliure des que es comença a distri- 

buir. Però com que en una llicència lliure no hi ha res que obligui a 

distribuir el programa (això només ho pot fer qui té el programari), 

el productor el distribueix només als seus clients durant un temps, els 

quals l’hi paguen (normalment en forma de contracte de manteni- 

ment). Al cap d’aquest temps, el productor el distribueix a qualsevol, 

per exemple posant-lo en un arxiu d’accés públic. D’aquesta manera, 

el productor obté ingressos dels seus clients, que perceben aquesta 

disposició preferent del programari com un valor afegit. Naturalment, 

el model només funciona si els clients, al seu torn, no fan públic el 

programa quan el reben. Per a cert tipus de clients, això pot no ser 

habitual. 

En general, en aquests casos les empreses desenvolupadores n’ob- 

tenen els beneficis esmentats, però no a cost zero. El retard amb què 

el producte passa a estar disponible per a la comunitat del progra- 

mari lliure, fa pràcticament impossible que aquesta pugui col·laborar 

121 


ANOTACIONS


ANOTACIONS 



apartat 9] 



apartat 2] 

122 


en el seu desenvolupament, per la qual cosa el productor es benefi- 

ciarà molt poc de contribucions externes. 

Exemple 

Alguns casos d’empreses que utilitzen aquest model de 

negoci són el següents: 

• artofcode LLC 

Des de l’any 2000, artofcode comercialitza Ghostscript 

en tres versions (abans ho feia Alladin Enterprises, amb 

un model similar). La versió més actual la distribueix 

com a AFPL Ghostscript, sota una llicència propietària 

(que en permet l’ús i la distribució no comercial). La se- 

güent (amb un retard d’un any, més o menys) la distri- 

bueix com a GNU Ghostscript, sota la GNU GPL. Per 

exemple, l’estiu del 2003, la versió AFPL és la 8.11 (alli- 

berada el 16 d’agost), mentre que la versió GNU és la 

7.07 (distribuïda com a tal el 17 de maig, però la versió 

equivalent AFPL del qual és del 2002). A més, artofcode 

ofereix una tercera versió, amb una llicència propietà- 

ria que permet la integració en productes no compati- 

bles amb la GNU GPL (en aquest cas usa un model 

dual, que es descriurà més endavant). 

• Ada Core Technologies 

Va ser fundada el 1994 pels autors del primer compi- 

lador d’Ada 95, el desenvolupament del qual va ser fi- 

nançat en part pel Govern dels Estats Units d’Amèrica, 

i que estava basat en GCC, el compilador de GNU. 

Des del principi els seus productes han estat programari 

lliure. Però la majoria els ofereixen primer als seus clients, 

com a part d’un contracte de manteniment. Per exem- 

ple, el seu compilador, que continua estant basat en 

GCC i es distribueix sota la GNU GPL, s’ofereix als seus 

clients com a Gnat Pro. Ada Core Technologies no ofe- 

reix de cap manera aquest compilador al públic en ge- 

neral, i normalment no se’n troben versions a la Xarxa. 

Tanmateix, amb un retard variable (entorn d’un any), 

Ada Core Technologies ofereix les versions “públiques” 

del seu compilador, molt similars però sense cap tipus 

de suport, en un arxiu d’FTP anònim.

5.2.5. Llicències especials 


En aquests models, l’empresa produeix un producte que distribueix 

sota dues llicències o més. Almenys una és de programari lliure, però 

les altres són típicament propietàries i li permeten vendre el producte 

d’una manera més o menys tradicional. Normalment, aquestes ven- 

des es complementen amb l’oferta de consultoria i desenvolupa- 

ments relacionats amb el producte. Per exemple, una empresa pot 

distribuir un producte com a programari lliure sota la GNU GPL, 

però oferir-ne també una versió propietària (simultàniament, i sense 

retard per a cap de les dues) per a qui no vulgui les condicions de la 

GPL, per exemple, perquè vol integrar el producte amb un propietari 

(una cosa que la GPL no permet). 

5.2.6. Venda de marca 

Encara que es puguin aconseguir productes molt similars per menys 

diners, molts clients estan disposats a pagar l’extra per comprar 

una “marca”. Aquest principi l’utilitzen empreses que inverteixen en 

l’establiment d’una marca amb bona imatge i ben reconeguda, 

que més endavant els permeti vendre productes lliures amb prou 

marge. Moltes vegades, no solament venen aquests productes, sinó 

que els acompanyen de serveis que els clients acceptaran també 

com a valor afegit. 

Exemple 

Sleepycat Software es va fundar el 1996, i anuncia que 

des d’aquell moment ha tingut beneficis (la qual cosa sens 

dubte és notable en una empresa relacionada amb el 

programari). Els seus productes, incloent-hi Berkeley DB 

(un gestor de dades molt popular i que es pot encastar 

fàcilment en altres aplicacions), es distribueixen sota 

una llicència lliure que especifica que en cas d’encas- 

tar-se en un altre producte, s’ha d’oferir el codi font de 

tots dos. Sleepycat ofereix serveis de consultoria i 

desenvolupament per als seus productes, però a més 

els ofereix sota llicències que permetin encastar-los 

sense haver-ne de distribuir el codi font. Naturalment, 

això ho fa sota contracte específic i, en general, en rè- 

gim de venda com a programari propietari. 

123 




apartat 50] 

ANOTACIONS


ANOTACIONS 



apartat 46] 



apartat 120] 

124 


Els casos més coneguts d’aquest model de negoci són les empreses 

que comercialitzen distribucions GNU/Linux. Aquestes empreses 

tracten de vendre un producte que, en general, es pot obtenir a un 

cost bastant més baix a la Xarxa (o en altres fonts amb menys imatge 

de marca). Han d’aconseguir que el consumidor en reconegui la 

marca i estigui disposat a pagar-ne el sobrepreu. Per a això, no so- 

lament inverteixen en publicitat, sinó que també ofereixen avantatges 

objectius (per exemple, una distribució ben conjuntada o un canal de 

distribució que arribi a prop del client). A més, solen oferir una gran 

quantitat de serveis relacionats, per tractar de rendibilitzar al màxim 

possible aquesta imatge de marca (des de formació fins a programes 

de certificació per a terceres parts). 

Hi ha altres classificacions de models de negoci clàssiques en la lite- 

ratura sobre programari lliure. Com a exemple, a continuació n’ofe- 

rim una de les més clàssiques. 

5.3.1. Classificació de Hecker 

Exemple 

Red Hat Linux es va començar a distribuir el 1994 

(l’empresa es va començar a conèixer amb el nom ac- 

tual el 1995). Des de llavors, Red Hat ha aconseguit 

posicionar el seu nom com el de la distribuïdora de 

GNU/Linux per excel·lència. Avui dia, Red Hat comer- 

cialitza entorn d’aquest nom tot tipus de serveis relaci- 

onats amb la distribució, amb GNU/Linux, i amb 

programari lliure en general. 

5.3. Altres classificacions de models de negoci 

La classificació que s’ofereix a Frank Hecker (maig, 1998), Setting up 

shop: The business of open-source software, va ser la més utilitzada 

per la publicitat de l’Open Source Initiative i una de les primeres a 

tractar de categoritzar els negocis que estaven sorgint en aquella 

època. Tanmateix, inclou diversos models poc centrats en programa-


ri lliure (és poc més que un acompanyant del model principal). En 

qualsevol cas, els models que descriu són els següents: 

• Support seller (venda de serveis relacionats amb el producte) 

L’empresa promou un producte lliure (que ha desenvolupat o en el 

qual ha participat activament) i ven serveis com consultoria o adap- 

tacions a necessitats concretes. 

• Loss leader (venda d’altres productes propietaris) 

En aquest cas, el programa lliure s’utilitza per a promoure d’alguna 

manera la venda d’altres productes propietaris relacionats. 

• Widget frosting (venda de maquinari) 

El negoci fonamental és la venda de maquinari, i el programari lliure 

es considera un complement que pot ajudar l’empresa a obtenir un 

avantatge competitiu. 

• Accessorizing (venda d’accessoris) 

Es comercialitzen productes relacionats amb el programari lliure, 

com ara llibres, dispositius informàtics, etc. 

• Service enabler (venda de serveis) 

El programari lliure serveix per a crear un servei (normalment acces- 

sible en línia) del qual l’empresa obté algun benefici. 

• Brand licensing (venda de marca) 

Una empresa registra marques que aconsegueix associar amb pro- 

grames lliures, que segurament ha desenvolupat. Després obté ingres- 

sos quan ven els drets d’ús d’aquestes marques. 

• Sell it, free it (ven-lo, allibera’l) 

És un model similar al loss leader, però fet de manera cíclica. Primer, 

un producte es comercialitza com a programari lliure. Si s’aconse- 

125 


ANOTACIONS


ANOTACIONS 

126 


gueix que tingui cert èxit, la versió següent es distribueix com a pro- 

gramari propietari durant un temps i, passat aquest temps, també 

s’allibera. A partir d’aquell moment se’n comença a distribuir una 

nova versió propietària, i així successivament. 

• Software franchising (franquícia de programari) 

Una empresa franquicia l’ús de les seves marques, relacionades amb 

un programa lliure determinat. 

En el mercat informàtic hi ha la tendència que un producte domini en 

cada un dels segments. Els usuaris volen rendibilitzar l’esforç que fan 

per aprendre com funciona un programa, les empreses volen trobar 

gent formada en l’ús del programari, i tothom vol que les dades que 

es gestionen les puguin entendre tant els programes de les empreses 

com les persones amb qui es relacionen. Per aquesta raó, qualsevol 

iniciativa dedicada a trencar una situació de facto en què un produc- 

te domina clarament el mercat està destinada a produir-ne més: si té 

èxit, en vindrà un altre que ocuparà aquest buit, i en poc temps en 

tindrem un de nou dominant. Només els canvis tecnològics produei- 

xen durant un temps prou inestabilitat perquè ningú no domini cla- 

rament. 

Nota 

Haureu pogut observar que aquesta classificació és 

bastant diferent de la que hem ofert nosaltres, però tot 

i així, algunes de les seves categories coincideixen gai- 

rebé exactament amb algunes de les nostres. 

5.4. Impacte sobre les situacions de monopoli 

Però el fet que hi hagi un producte dominant no significa necessària- 

ment que hi hagi un monopoli empresarial. Per exemple, la gasolina 

és pràcticament el producte que domina el mercat de combustibles 

per a turismes, però (en un mercat de la gasolina lliure) hi ha moltes 

empreses que produeixen i distribueixen aquest producte. En realitat, 

el més preocupant quan parlem de programari és què passa quan 

un producte arriba a dominar el mercat, perquè aquest producte té 

una única empresa proveïdora. El programari lliure ofereix una


alternativa a aquesta situació: els productes lliures poden estar pro- 

moguts per una empresa en concret, però aquesta empresa no els 

controla, o almenys no ho fa fins a l’extrem a què ens té acostumats 

el programari propietari. En el món del programari lliure, un produc- 

te dominant no representa necessàriament un monopoli d’empresa. 

Al contrari, sigui quin sigui el producte que domina el mercat, moltes 

empreses poden competir per proporcionar-lo, millorar-lo, adaptar- 

lo a les necessitats dels clients i oferir-hi serveis relacionats. 

5.4.1. Elements que afavoreixen els productes dominants 

En informàtica és molt comú que hi hagi un producte clarament do- 

minant en cada segment de mercat. I això és normal per diversos 

motius, entre els quals podem destacar: 

• Formats de dades 

Moltes vegades el format de dades està fortament lligat a una apli- 

cació. Quan un nombre prou gran de gent l’utilitza, el seu format de 

dades es converteix en estàndard de facto i les pressions per utilitzar- 

lo (i utilitzar l’aplicació) són formidables. 

• Cadenes de distribució 

Normalment, un dels problemes per a començar a utilitzar un pro- 

grama és obtenir-ne una còpia. I és difícil trobar programes que no 

siguin líders en el seu mercat. Les cadenes de distribució són cares 

de mantenir, de manera que els competidors minoritaris ho tenen di- 

fícil per a arribar a la botiga d’informàtica, on l’usuari final els pugui 

comprar. Tanmateix, el producte dominant ho té fàcil: el primer in- 

teressat a tenir-lo serà la botiga d’informàtica. 

• Màrqueting 

El màrqueting “gratuït” que obté un producte quan l’utilitza una frac- 

ció significativa d’una població determinada és enorme. El boca a 

boca funciona molt bé, i també preguntar i intercanviar informació 

amb els coneguts. Però, sobretot, l’impacte en els mitjans és molt 

gran: les revistes d’informàtica parlaran constantment d’un producte 

si sembla que és el que més s’utilitza. Hi haurà cursos de formació, 

llibres que el descriguin, entrevistes als usuaris, etc. 

127 


ANOTACIONS


ANOTACIONS 

128 


• Inversió en formació 

Una vegada que s’ha invertit temps i recursos a aprendre com funcio- 

na una eina, s’està predisposat a no canviar-la. A més, normalment 

aquesta eina ja domina el mercat, perquè és més fàcil trobar perso- 

nal i material que ajudin a aprendre a utilitzar-la. 

• Programari preinstal·lat 

Rebre una màquina amb programari ja instal·lat sens dubte és un 

gran incentiu per a utilitzar-lo, encara que s’hagi de pagar a part. I 

normalment, el tipus de programari que el venedor de la màquina 

estarà disposat a preinstal·lar serà el més utilitzat. 

5.4.2. El món del programari propietari 

En el món del programari propietari l’aparició d’un producte domi- 

nant en un segment qualsevol equival a un monopoli per part de 

l’empresa que el produeix. Per exemple, tenim aquestes situacions 

monopolístiques de facto (o gairebé) de producte i empresa en els 

mercats de sistemes operatius, autoedició, bases de dades, disseny 

gràfic, processadors de text, fulls de càlcul, etc. 

I això és així perquè l’empresa en qüestió té un gran control sobre 

el producte líder; tan gran que només ells poden marcar l’evolució 

del producte, les línies fonamentals on es desenvoluparà, la qualitat, 

etc. Els usuaris tenen molt poc control, ja que estaran molt poc mo- 

tivats per a provar amb altres productes (pels motius que hem co- 

mentat en l’apartat anterior). Davant d’això, poc podran fer, llevat 

de tractar de desafiar la posició dominant del producte millorant ex- 

cepcionalment els seus productes (per tractar de contrarestar 

aquests mateixos motius), normalment amb poc èxit. 

Aquesta situació posa tot el sector a mans de l’estratègia de l’empresa 

dominant. Tots els actors en depenen, i fins i tot el desenvolupament 

de la tecnologia del programari en aquest camp estarà mediatitzat 

per les millores que facin en el seu producte. Generalment, en aques- 

ta situació apareixen els pitjors efectes econòmics del monopoli i, en 

particular, la falta de motivació de l’empresa líder per apropar el pro-


ducte a les necessitats (sempre en evolució) dels seus clients. Aquests 

clients s’han convertit en un mercat captiu. 

5.4.3. La situació amb programari lliure 

Tanmateix, en el cas del programari lliure un producte dominant no 

es tradueix automàticament en un monopoli d’empresa. Si el producte 

és lliure, qualsevol empresa hi pot treballar, el pot millorar i adaptar 

a les necessitats d’un client i, en general, ajudar en la seva evolució. 

A més, precisament per la seva posició dominant, hi haurà moltes em- 

preses interessades a treballar-hi. Si el productor “original” (l’empresa 

que ha desenvolupat originalment el producte) vol continuar en el ne- 

goci ha de competir amb totes aquestes empreses, i per això estarà 

molt motivat per a fer evolucionar el producte precisament en la línia 

que vulguin els usuaris. Naturalment, tindran l’avantatge d’un més 

bon coneixement del programa, però això és tot. Han de competir per 

cada client. 

L’aparició de productes dominants es tradueix, per tant, en el món 

del programari lliure, en més competència entre empreses. I amb 

això els usuaris reprenen el control: les empreses en competència no- 

més els poden fer cas si volen sobreviure. I precisament això és el que 

assegurarà que el producte millori. 

aaa 

Productes lliures que són dominants 

en el seu sector 

Apache és des de fa temps líder en el mercat de servi- 

dors de web. Però hi ha moltes empreses al darrere 

d’Apache, des d’algunes molt grans (com IBM) a d’al- 

tres molt petites. I cap no té més remei que competir mi- 

llorant-lo, i normalment contribuint al projecte amb les 

seves millores. Malgrat que Apache és gairebé un mo- 

nopoli en molts àmbits (per exemple, és gairebé l’únic 

servidor web que es considera sobre la plataforma 

GNU/Linux o *BSD), no depèn d’una sola empresa, 

sinó de, literalment, desenes d’empreses. 

129 


ANOTACIONS


ANOTACIONS 

130 


aaa 

Les distribucions de GNU/Linux també són un cas inte- 

ressant. Sens dubte, GNU/Linux no és un monopoli, 

però sí, potser, la segona opció en el mercat de sistemes 

operatius. I això no ha forçat la situació en què una em- 

presa en tingui el control. Al contrari, hi ha desenes de 

distribucions, fetes per empreses diferents, que compe- 

teixen lliurement en el mercat. Cadascuna tracta d’ofe- 

rir millores que els seus competidors han d’adoptar per 

no ser eliminats del mercat. Però a més no es poden se- 

parar gaire del que és “GNU/Linux estàndard”, ja que 

els usuaris rebutgen això com una “sortida de la nor- 

ma”. La situació després de diversos anys de creixement 

de la quota de mercat de GNU/Linux ens mostra dese- 

nes d’empreses competint i fent evolucionar el sistema. 

I de nou totes volen satisfer les necessitats dels usuaris. 

Només així es poden mantenir en el mercat. 

GCC és un producte dominant en el món de compila- 

dors C i C++ per al mercat GNU/Linux. I tanmateix, 

això no ha portat a cap situació de monopoli d’empre- 

sa, fins i tot quan Cygnus (avui Red Hat) s’ha encarregat 

durant molt de temps de coordinar-ne el desenvolupa- 

ment. Hi ha moltes empreses que fan millores en el sis- 

tema, i totes competeixen, cada una en la seva veta 

específica, per satisfer les demandes dels usuaris. De 

fet, quan alguna empresa o organització específica ha 

fallat en la feina de coordinació (o així ho ha percebut 

una part dels usuaris) hi ha hagut espai per a un fork 

(divisió) del projecte, amb dos productes en paral·lel du- 

rant un quant temps, fins que eventualment s’han tornat 

a unir (com està passant ara amb el GCC 3.x). 

5.4.4. Estratègies per a constituir-se en monopoli 

amb programari lliure 

Malgrat que el món del programari lliure és molt més hostil als mo- 

nopolis d’empresa que el món del programari propietari, hi ha es- 

tratègies que les empreses poden utilitzar per a intentar aproximar- 

se a una situació de domini monopolístic d’un mercat. Són pràctiques


comunes en molts altres sectors econòmics, i les entitats de regulació 

de la competència treballen per tal d’evitar-les, per la qual cosa no 

en parlarem en detall. Tanmateix, n’esmentarem una que fins a cert 

punt sí que és específica del mercat del programari, i que ja s’expe- 

rimenta en algunes situacions: l’acceptació de productes certificats 

per tercers. 

Quan una empresa vol distribuir un producte programari (lliure o 

propietari) que funcioni en combinació amb d’altres, “certifica” 

aquest producte per a una combinació determinada. El fabricant es 

compromet a oferir serveis (actualització, suport, resolució de proble- 

mes, etc.) només si el client li assegura que està usant el producte en 

un entorn que ell hagi certificat. Per exemple, un fabricant de gestors 

de bases de dades pot certificar el seu producte per a una determi- 

nada distribució de Linux, i per a cap altra. Això implicarà que els 

seus clients hauran d’utilitzar aquesta distribució de Linux o oblidar- 

se del suport per part del fabricant (la qual cosa pot ser impossible a 

la pràctica, si el producte és propietari). Si un fabricant aconsegueix 

una posició clarament dominant com a producte certificat de terceres 

parts, els usuaris no tindran cap altra opció que utilitzar-lo. Si la cer- 

tificació és important en aquest segment, som de nou davant d’una 

situació d’empresa monopolística. 

Nota 

Fins a cert punt, en el mercat de distribucions de GNU/ 

Linux es comencen a observar algunes situacions que 

tendeixen al monopoli de facto en la certificació. Per 

exemple, hi ha molts fabricants de productes propieta- 

ris que només certifiquen els seus productes sobre una 

distribució de GNU/Linux concreta (molt sovint Red 

Hat Linux). De moment, això no sembla que hagi de 

portar a una situació monopolística per part de cap 

empresa, però ho podria ser si en el mercat de distri- 

bucions de GNU/Linux la certificació tingués poca im- 

portància per als usuaris. Però només el futur dirà si 

en algun moment aquesta situació s’apropa a una de 

monopoli de facto. 

Ara bé, és important tenir en compte dos comentaris. El primer és 

que aquestes posicions monopolístiques no seran fàcils d’aconse- 

131 


ANOTACIONS


ANOTACIONS 

132 


guir, i en qualsevol cas ho seran per mecanismes en general “no in- 

formàtics” (a diferència de la situació de producte dominant, que 

com hem vist és relativament normal i s’hi arriba per mecanismes pu- 

rament relacionats amb la informàtica i els seus patrons d’ús). El se- 

gon és que si tot el programari utilitzat és lliure, aquesta estratègia té 

poques possibilitats d’èxit (si és que en té alguna). Un fabricant podrà 

aconseguir que moltes empreses certifiquin els seus productes, però 

els clients sempre podran buscar fonts de servei i suport diferents 

d’aquestes empreses que han certificat, si és que ho consideren con- 

venient.

6. Iniciatives públiques 


Les institucions públiques, tant les que tenen capacitat legislativa 

com les que es dediquen a administrar l’estat (les administracions 

públiques) tenen en general molt a dir pel que fa a l’adopció i la 

promoció de tecnologies. Encara que des del començament de la 

seva història fins a pràcticament l’any 2000 no hi havia hagut (tret 

de casos gairebé anecdòtics) interès per part d’aquestes institucions 

pel fenomen del programari lliure, la situació està canviant radical- 

ment a partir d’aquesta data. En primer lloc, les administracions 

públiques són cada vegada més usuàries del programari lliure. En 

segon lloc, en el seu paper de promotores de la societat de la in- 

formació, cada vegada hi ha més administracions que promouen 

directament o indirectament el desenvolupament de programari 

lliure. En tercer lloc, els ens legislatius a poc a poc es van ocupant 

del programari lliure, encara que no sempre per millorar l’entorn 

on es desenvolupa. 

Com que el món del programari lliure es va desenvolupar durant tant 

de temps al marge del suport explícit (i fins i tot de l’interès) de les 

institucions públiques, la situació actual crea polèmiques i proble- 

mes, no solament entre altres actors del sector de les tecnologies de 

la informació, sinó també dins de la comunitat del programari lliure. 

En aquest capítol tractarem d’exposar quina és la situació actual, i 

quines peculiaritats té el programari lliure quan es relaciona amb “el 

que és públic”. 

6.1. Impacte del programari lliure 

en les administracions públiques 

L’impacte potencial del programari lliure en les administracions públi- 

ques, tant en la faceta de consumidors com en la faceta de promotors 

(que estudiarem amb més detall més endavant, en l’apartat 6.2), pre- 

senta certs aspectes generals que veurem en aquest apartat. 

133 


ANOTACIONS


ANOTACIONS 

134 


6.1.1. Impactes principals 

Els impactes principals del programari lliure i les principals noves 

perspectives que permet, són els següents: 

• Aprofitament més adequat dels recursos 

Moltes aplicacions utilitzades o promogudes per les administracions 

públiques també les fan servir molts altres sectors de la societat. És 

per això que qualsevol inversió pública en el desenvolupament d’un 

producte lliure, que li interessa, donarà beneficis no solament a la 

mateixa administració, sinó a tots els ciutadans que podran utilitzar 

aquest producte per a les tasques informàtiques, probablement amb 

les millores aportades per l’administració. 

Nota 

Un cas molt especial, però de gran impacte, que mostra 

clarament aquest aprofitament dels recursos públics es 

pot trobar en la localització (adaptació als usos i costums 

d’una comunitat) d’un programa. Encara que l’aspecte 

més visible de la localització és la traducció de tots els 

textos que utilitza el programa, i de la seva documentació, 

n’hi ha molts altres que també estan afectats (des de 

l’ús de símbols per a la moneda local o la presentació de 

la data i hora en formats habituals en la comunitat en 

qüestió fins a l’ús d’exemples i formes d’expressió adequades 

als costums locals en la documentació). 

En qualsevol cas, és clar que si una administració pública 

dedica recursos perquè una determinada aplicació 

s’adapti a les seves necessitats, és més que probable que 

aquestes necessitats coincideixin amb les dels ciutadans. 

De manera que no solament aconsegueix tenir un programa 

informàtic que satisfaci les seves necessitats, sinó 

que també el pot posar, sense despeses addicionals, a 

disposició de qualsevol ciutadà que el pugui utilitzar amb 

profit. Per exemple, quan una administració pública finança 

l’adaptació d’un programa ofimàtic a una llengua 

que es parla en el seu àmbit d’actuació, no solament el 

podrà utilitzar en les seves pròpies dependències, sinó 

que també el podrà oferir als seus ciutadans, amb tot el 

que això pot representar en qüestió de foment de la societat 

de la informació.

• Foment de la indústria local 


Un dels avantatges més grans del programari lliure és la possibilitat 

de desenvolupar indústria local de programari. Quan s’utilitza pro- 

gramari propietari, tot el que s’ha gastat en llicències va directament 

al fabricant del producte, i aquesta compra fa que la seva posició s’en- 

forteixi; això no és necessàriament perjudicial, però sí poc eficient per 

a la regió vinculada a l’administració si analitzem l’alternativa d’usar 

un programa lliure. 

En aquest cas, les empreses locals podran competir proporcionant ser- 

veis (i el seu programa) a l’administració, en condicions molt similars 

a qualsevol altra empresa. Diguem que, d’alguna manera, l’adminis- 

tració està aplanant el camp de joc, i fent més fàcil que qualsevol hi 

pugui competir. I naturalment, aquest qualsevol podran ser les empre- 

ses locals, que tindran la possibilitat d’aprofitar els seus avantatges 

competitius (més bon coneixement de les necessitats del client, proxi- 

mitat geogràfica, etc.). 

• Independència de proveïdor 

És obvi que qualsevol organització preferirà dependre d’un mercat 

en règim de competència que d’un sol proveïdor que pot imposar les 

condicions en què proporciona el producte. Tanmateix, en el món de 

l’administració aquesta preferència es converteix en requisit fona- 

mental, i fins i tot en obligació legal en alguns casos. L’administració 

no pot, en general, triar contractar un subministrador concret, sinó 

que ha d’especificar les seves necessitats de manera que qualsevol 

empresa interessada, que compleixi unes certes característiques tèc- 

niques i que proporcioni el servei o el producte demanat amb una 

certa qualitat, pugui optar a un contracte. 

De nou, en el cas del programari propietari, per a cada producte no- 

més hi ha un proveïdor (encara que usi una varietat d’intermediaris). 

Si s’especifica un producte concret, també s’està decidint quin prove- 

ïdor contractarà l’administració. I moltes vegades és pràcticament 

impossible evitar especificar un producte concret quan parlem de 

programes d’ordinador. Raons de compatibilitat dins de l’organitza- 

ció, o d’estalvis en formació i administració, o molts d’altres, fan habi- 

tual que una administració decideixi utilitzar un producte determinat. 

135 


ANOTACIONS


ANOTACIONS 

136 


L’única sortida a aquesta situació és que el producte especificat sigui 

lliure. En aquest cas, qualsevol empresa interessada el podrà propor- 

cionar, i també qualsevol tipus de servei sobre el producte (subjecte 

únicament a les seves capacitats i als coneixements que en tingui). A 

més, en cas de contractar d’aquesta manera, l’administració pertinent 

en el futur podrà canviar immediatament de proveïdor si ho desitja, i 

sense cap problema tècnic, ja que encara que canviï d’empresa, utilit- 

zarà el mateix producte. 

• Adaptació a les necessitats exactes 

Encara que l’adaptació a les seves necessitats exactes és un requisit 

de qualsevol organització que depèn de la informàtica, les peculiari- 

tats de l’administració fan que sigui un factor molt important per a 

l’èxit de la implantació d’un sistema informàtic. En el cas d’usar pro- 

gramari lliure, l’adaptació es pot fer amb molta més facilitat, i el que 

és més important, servint-se d’un mercat amb competència, si fa fal- 

ta contractar-la. 

Quan una administració compra un producte propietari, modificar- 

lo passa normalment per assolir un acord amb el productor, que és 

l’únic que legalment (i moltes vegades tècnicament) ho pot fer. En 

aquestes condicions, és difícil fer bones negociacions, sobretot si el 

productor no està gaire interessat en el mercat que l’administració en 

qüestió li ofereix. Tanmateix, usant un producte lliure, aquesta admi- 

nistració el pot modificar al seu gust, si té personal per a fer-ho, o 

contractar la modificació de forma externa. Aquesta contractació la 

pot fer en principi qualsevol empresa que tingui els coneixements i 

les capacitats per a això, per la qual cosa és factible que hi hagi com- 

petència de diverses empreses. 

Aquest fet tendeix necessàriament a abaratir els costos i millorar la 

qualitat. 

• Escrutini públic de seguretat 

Per a una administració pública, el fet de poder garantir que els seus 

sistemes informàtics només fan el que està previst que facin és un re- 

quisit fonamental, i en molts estats, un requisit legal. No són poques 

les vegades que aquests sistemes gestionen dades privades, en què


podrien estar interessats molts tercers (per exemple, dades fiscals, 

penals, censals, electorals, etc.). Si s’utilitza una aplicació propietària 

sense codi font disponible, amb prou feines es pot assegurar que 

aquesta aplicació tracti les dades com cal. Però fins i tot si s’ofereix 

el codi font, les possibilitats que una institució pública tindrà d’asse- 

gurar que no conté codi “estrany” seran molt limitades. Només si 

aquesta feina es pot encarregar de manera habitual i rutinària a ter- 

cers, i qualsevol part interessada els pot escrutar, l’administració po- 

drà estar raonablement segura de complir aquest deure fonamental, 

o almenys de prendre-hi totes les mesures a l’abast. 

• Disponibilitat a llarg termini 

Moltes dades que gestionen les administracions i els programes 

que serveixen per a calcular-les han d’estar disponibles d’aquí a 

desenes d’anys. És molt difícil assegurar que un programa propie- 

tari qualsevol estarà disponible quan hagi passat aquest període de 

temps, i més si es vol que funcioni en la plataforma habitual en 

aquell moment futur. Al contrari, és molt possible que el seu pro- 

ductor hagi perdut interès en el producte i no l’hagi traspassat a 

plataformes noves, o que només estigui disposat a fer-ho a canvi 

de grans contraprestacions econòmiques. De nou cal recordar que 

només ell pot fer aquesta migració, i per tant, serà difícil negociar- 

hi. En el cas del programari lliure, en canvi, l’aplicació està dispo- 

nible amb seguretat perquè qualsevol la traspassi i la faci funcionar 

segons les necessitats de l’administració. Si això no succeeix de ma- 

nera espontània, l’administració sempre es pot dirigir a diverses 

empreses i buscar-hi la millor oferta. D’aquesta manera es pot ga- 

rantir que l’aplicació i les dades que gestiona estaran disponibles 

quan faci falta. 

Suggeriment 

El lector interessat en un informe sobre els avantatges del 

programari lliure per a l’administració, escrit en el context 

nord-americà del 1999, pot consultar “The Case for 

Government Promotion of Open Source Software”. 

137 


ANOTACIONS 



apartat 192]


ANOTACIONS 

138 


6.1.2. Dificultats d’adopció 

Si bé hi ha molts avantatges en la utilització del programari lliure en 

les administracions, també hi ha moltes dificultats quan s’enfronten 

a la posada en pràctica. Entre aquestes dificultats podem destacar: 

• Desconeixement i falta de decisió política 

El primer problema que es troba el programari lliure a l’hora d’in- 

troduir-se en les administracions és, sens dubte, un problema que com- 

parteixen altres organitzacions: el programari lliure encara és molt 

desconegut entre els qui prenen les decisions. 

Afortunadament, això va sent cada vegada menys freqüent, però en 

molts àmbits de les administracions el programari lliure encara es 

continua percebent com una cosa “estranya”, i prendre la decisió 

d’utilitzar-lo implica assumir alguns riscos. 

Juntament amb tot això hi sol haver un problema de decisió política. 

El principal avantatge del programari lliure en l’administració no n’és 

el cost (que continua essent important, sobretot quan cal desplegar-lo 

per una gran quantitat de llocs). Els principals avantatges són, sobre- 

tot, “de fons”, estratègics, i sovint cauen en l’àmbit de les decisions 

polítiques, més que no pas tècniques. Sense la voluntat política de 

canviar els sistemes informàtics i la filosofia amb què es contracten, 

és difícil avançar en la implantació de programari lliure en l’adminis- 

tració. 

• Poca adequació dels mecanismes de contractació 

Els mecanismes de contractació que es fan servir avui dia en l’admi- 

nistració, des dels models de concurs públic habituals fins a la divisió 

de la despesa en partides, estan pensats fonamentalment per a la 

compra de productes informàtics i no tant per a l’adquisició de ser- 

veis relacionats amb els programes. Cal tenir en compte que, quan 

s’utilitza programari lliure, sovint no es compra un producte, o aquest 

producte té un preu gairebé negligible. Tanmateix, per a aprofitar les 

possibilitats que ofereix el programari lliure, és convenient poder


contractar serveis relacionats. Això comporta que, abans d’utilitzar 

programari lliure seriosament, s’hagin dissenyat mecanismes buro- 

cràtics adequats que en facilitin la contractació. 

• Falta d’estratègia d’implantació 

Moltes vegades, el programari lliure es comença a utilitzar en una 

administració simplement perquè el cost d’adquisició és més baix. En 

aquests casos és molt habitual que el producte en qüestió s’incorpori 

al sistema informàtic sense planificació, i en general, sense una es- 

tratègia global d’ús i aprofitament. Això fa que la major part dels 

avantatges es perdin pel camí, ja que tot queda en utilitzar un pro- 

ducte “més barat”, quan ja hem vist que, en general, els avantatges 

més grans són d’un altre tipus. 

Si hi afegim que, si no es dissenya adequadament, el canvi a progra- 

mari lliure pot representar un cost de transició no menyspreable, 

aquestes experiències en l’administració, de forma aïllada i fora d’un 

marc clar, poden resultar fallides i frustrants. 

• Escassetat o absència de productes lliures en determinats seg- 

ments 

La implantació de programari lliure en qualsevol organització pot xo- 

car amb la falta d’alternatives lliures de qualitat adequada per a cert 

tipus d’aplicacions. En aquests casos, la solució és complicada: l’únic 

que es pot fer és tractar de promoure l’aparició del producte lliure 

que es necessita. 

Afortunadament, les administracions públiques estan en una bona 

posició per a estudiar seriosament si els convé fomentar, o fins i tot 

finançar o cofinançar, el desenvolupament d’aquest producte. Cal 

recordar que entre els objectius de les administracions públiques hi 

sol haver, per exemple, la facilitació de l’accés dels seus clients (els 

ciutadans) a la societat de la informació o el foment del teixit indus- 

trial local. Sens dubte, la creació de molts programes lliures incidirà 

positivament en tots dos objectius, per la qual cosa caldria sumar al 

mer càlcul de cost/benefici directe, els beneficis indirectes que aques- 

ta decisió causaria. 

139 


ANOTACIONS


ANOTACIONS 

140 


6.2. Actuacions de les administracions públiques 

en el món del programari 

Les administracions públiques actuen sobre el món del programari 

almenys de tres maneres: 

• Comprant programes i serveis relacionats amb les administracions, 

les quals, com a grans usuàries d’informàtica, són un actor fona- 

mental en el mercat del programari. 

• Promovent de diverses maneres la utilització (i adquisició) de de- 

terminats programes per la societat. Aquesta promoció es fa, de 

vegades oferint incentius econòmics (desgravacions fiscals, incen- 

tius directes, etc.), de vegades amb informació i recomanacions, i 

de vegades, per “l’efecte exemple”. 

• Finançant (directament o indirectament) projectes d’investigació i 

desenvolupament que dissenyaran el futur de la informàtica. 

En cada un d’aquests àmbits, el programari lliure pot presentar avan- 

tatges específics (a més dels que ja hem descrit), interessants tant per 

a l’administració com per a la societat en general. 

6.2.1. Com satisfer millor les necessitats 

de les administracions públiques? 

Les administracions públiques són grans consumidores d’informàti- 

ca. Pel que fa al programari, compren sovint tant productes de con- 

sum massiu com sistemes a mida. Des d’aquest punt de vista són, 

sobretot, grans centres de compres, similars a les grans empreses, 

encara que amb les seves peculiaritats. Per exemple, en molts àmbits 

se suposa que les decisions de compra de les administracions públi- 

ques no han de tenir en compte simplement paràmetres de cost en 

relació amb la funcionalitat, sinó també altres paràmetres que poden 

ser importants, com ara l’impacte de la compra en el teixit industrial 

i social, o en consideracions estratègiques a llarg termini. 

En qualsevol cas, avui dia el més habitual respecte al programari de 

consum massiu és utilitzar els productes propietaris líders del mercat. 

La quantitat de recursos públics que es gasten els ajuntaments, les


comunitats autònomes, l’administració central i les administracions 

europees a comprar llicències de Windows, Office o altres productes 

similars és realment considerable. Però les solucions lliures penetren 

cada vegada més en aquest mercat i cada vegada es consideren més 

solucions basades en programari lliure per als servidors. Productes 

com OpenOffice, i GNU/Linux amb GNOME o KDE són cada vega- 

da més considerats a l’escriptori. 

Què es pot guanyar amb aquesta migració a programari lliure? Per 

a il·lustrar-ho, considerem el següent escenari: suposem que amb 

una fracció del que totes les administracions europees (o probable- 

ment una de qualsevol estat desenvolupat de mida mitjana) han gas- 

tat en dos o tres productes propietaris “estrella”, es podria haver 

promogut un concurs públic per tal que una empresa (o unes quan- 

tes) millorés i adaptés els programes lliures ara disponibles perquè en 

el termini d’un o dos anys estiguessin llestos per a una utilització mas- 

siva, almenys per a certes tasques típiques. Imagineu, per exemple, 

aquest esforç coordinat, a escala nacional o europea, on totes les ad- 

ministracions participessin en un consorci que s’encarregués de la 

gestió d’aquests concursos. En poc temps hi hauria una indústria “lo- 

cal” especialitzada a fer aquestes millores i adaptacions. Les admi- 

nistracions podrien escollir entre les tres o quatre distribucions lliures 

produïdes per aquesta indústria. Per a fomentar la competència es 

podria recompensar econòmicament cada empresa segons la quan- 

titat d’administracions que escollissin utilitzar la seva distribució. I tot 

el resultat d’aquesta operació, en ser programari lliure, també estaria 

a disposició d’empreses i usuaris individuals, que moltes vegades tin- 

drien necessitats similars a les de les administracions. 

En el cas del programari fet a mida, de moment el procés habitual 

passa normalment per contractar a una empresa els programes ne- 

cessaris sota un model propietari, que es caracteritza pel següent: 

d’una banda, tot el desenvolupament fet a petició de l’administració 

és propietat de l’empresa que el desenvolupa. I, de l’altra, normal- 

ment l’administració contractant queda lligada al seu proveïdor per 

a tot el que tingui a veure amb millores, actualitzacions i suport, en 

un cercle viciós que dificulta molt la competència i alenteix el procés 

de modernització de les administracions públiques. I encara pitjor, 

moltes vegades el mateix programa es ven una vegada i una altra a 

administracions semblants, aplicant en cada nou cas els costos que 

hauria representat tornar a fer el desenvolupament des de zero. 

141 


ANOTACIONS


ANOTACIONS 

142 


Considerem de nou un escenari que mostri com serien les coses 

d’una altra manera. Un consorci d’administracions públiques amb la 

necessitat d’un cert programari a mida podria exigir que el resultat 

obtingut fos programari lliure. Això permetria que altres administra- 

cions també es beneficiessin del treball, i a mitjà termini estiguessin 

interessades a col·laborar amb el consorci perquè es tinguessin en 

compte les seves necessitats particulars. En ser lliure el programari 

resultant, no hi hauria l’obligació de contractar les millores i adapta- 

cions al mateix proveïdor, introduint d’aquesta manera la competèn- 

cia en aquest mercat (que ara com ara és gairebé captiu). I en 

qualsevol cas, el cost final per a qualsevol de les administracions im- 

plicades no seria mai més gran que si s’hagués utilitzat un model 

propietari. 

Són aquests escenaris ciència-ficció? Com veurem, ja hi ha algunes 

tímides iniciatives en direccions similars a les que s’exposen. A més 

d’ajudar a crear i mantenir una indústria en l’àmbit de l’administra- 

ció pública que fa la compra, el programari lliure té més avantatges 

específics en l’entorn públic. Per exemple, és la manera més efectiva 

de tenir programari desenvolupat en llengües minoritàries (preocu- 

pació essencial de moltes administracions públiques). També pot 

ajudar a mantenir la independència estratègica a llarg termini i a as- 

segurar l’accés a les dades que custodien les administracions públi- 

ques. Per tots aquests motius, les entitats públiques estan cada 

vegada més interessades en l’ús del programari lliure. 

Alguns casos relacionats amb administracions 

alemanyes 

Exemple 

El juliol del 2003 es va alliberar la primera versió es- 

table de Kolab, un producte del projecte Kroupware. 

Kolab és un sistema lliure d’ajuda informàtica al tre- 

ball en grup (groupware) basat en KDE. El motiu pel 

qual esmentem aquest projecte en aquest punt és que 

el seu origen va ser un concurs del Bundesamt für 

Sicherheit in der Informationstechnik (BSI) del Govern 

alemany (es podria traduir com Agència Federal de Se- 

guretat en Tecnologies de la Informació). El concurs de- 

manava


la provisió d’una solució que interoperés amb els en- 

torns Windows i l’Outlook d’una banda i GNU/Linux 

i KDE de l’altra. Entre les ofertes presentades, va gua- 

nyar la proposta conjunta de tres empreses, Erfrakon, 

Intevation i Klarälvdalens Datakonsult, que proposava 

una solució lliure basada parcialment en programari 

ja desenvolupat pel projecte KDE, completat amb 

desenvolupaments propis lliures, que van donar lloc 

a Kolab. 

El maig del 2003 l’Ajuntament de Munic va aprovar 

la migració a GNU/Linux com a sistema operatiu i a 

aplicacions d’ofimàtica lliures en tots els ordinadors 

utilitzats com a escriptoris, prop de catorze mil. La 

decisió no va ser només econòmica: també es van te- 

nir en compte aspectes estratègics i qualitatius, se- 

gons van declarar els responsables. En l’exhaustiu 

estudi que es va elaborar prèviament a la decisió, la 

solució finalment triada (GNU/Linux més OpenOffice, 

fonamentalment) va obtenir 6.218 punts (d’un màxim 

de deu mil) davant els poc més de cinc mil que van ob- 

tenir la solució “tradicional” basada en programari de 

Microsoft. 

El juliol del 2003, el Koordinierungs- und Bera- 

tungsstelle der Bundesregierung für Informations- 

technik in der Bundesverwaltung (KBSt), del Ministeri 

alemany de l’Interior, va fer públic el document Leitfaden 

für die Migration von Basissoftware komponenten auf 

Server- und Arbeitsplatzsystemen (‘Guia de migració 

per a components de programari bàsics en servidors i 

estacions de treball’), que ofereix a les entitats públi- 

ques alemanyes un conjunt d’orientacions sobre com 

poden migrar a solucions basades en programari lliu- 

re. Aquestes orientacions estan dissenyades perquè qui 

estigui a càrrec de la presa de decisions pugui avaluar 

si convé una migració a programari lliure, i en quines 

condicions s’ha de fer, si pren aquesta decisió. 

143 




apartat 88] 

ANOTACIONS


ANOTACIONS 

144 


6.2.2. Promoció de programari 

Les entitats públiques dediquen molts recursos a la promoció de 

plans que incentiven la despesa en informàtica. Aquesta publicitat és 

una eina formidable, que pot ajudar molt a l’extensió de les noves 

tecnologies en la societat, però també és una eina perillosa. Per 

exemple, pot no ser gaire bona idea promoure l’ús d’Internet en la 

societat recomanant un navegador determinat que fomenti la posició 

de monopoli de facto d’una empresa, la qual cosa a la llarga podria 

ser perjudicial per a la societat que s’intenta beneficiar. 

De nou, el programari lliure pot ajudar en aquestes situacions. En 

primer lloc, és neutre enfront dels fabricants, ja que cap no té l’exclu- 

siva de cap programa lliure. Si una administració vol promoure l’ús 

d’una família de programes lliures, pot fer concursos, als quals es pot 

presentar qualsevol empresa del sector per gestionar-ne el lliurament 

als ciutadans, la millora o l’ampliació amb les funcionalitats que es 

vulgui, etc. En segon lloc, pot ajudar molt en els aspectes econòmics. 

Per exemple, moltes vegades es pot utilitzar la mateixa quantitat de 

recursos per a adquirir una quantitat determinada de llicències d’un 

programa propietari perquè l’usin els ciutadans, o per a comprar-ne 

una còpia d’un de lliure, i contractar-hi suport o adaptacions; o fins 

i tot per a negociar la compra dels drets d’un producte amb un pro- 

ductor de programari propietari per a convertir-lo en programari lliure. 

En un altre àmbit, podem imaginar que una part de la quantitat des- 

tinada a un programa d’informatització d’escoles es dedica a crear 

una distribució de GNU/Linux adaptada a les necessitats de la do- 

cència en ensenyament primari. I amb la resta dels recursos es con- 

tracta suport per mantenir el programari en aquestes escoles, de 

manera que no sigui un simple programari “de decoració”, sinó que 

realment hi hagi gent que s’encarregui que funcioni correctament. 

D’aquesta manera no solament es cobreixen les necessitats del siste- 

ma educatiu, sinó que a més es genera un mercat per a empreses, 

habitualment d’àmbit local, capaces d’oferir serveis de manteni- 

ment. I sens dubte, es deixa completament obert el camí del futur: el 

programari no quedarà obsolet en pocs anys, cosa que obligaria a 

tornar a començar des de zero, sinó que es podrà anar actualitzant 

progressivament, any rere any, mantenint els beneficis del programa 

amb una inversió similar.

6.2.3. Foment de la investigació 


El programari també té avantatges interessants en política d’R+D 

que val la pena analitzar. Una gran quantitat de desenvolupaments 

de programari s’estan finançant amb diners públics, dels quals la so- 

cietat no se n’acaba beneficiant ni tan sols indirectament. Sovint, els 

programes públics de foment de la investigació i desenvolupament 

financen totalment o parcialment projectes que creen programes 

sense tenir en compte els drets del públic. Moltes vegades, per no te- 

nir un pla adequat de comercialització, els resultats simplement es 

queden en algun calaix cobrint-se de pols. Altres cops, les mateixes 

persones que han finançat un programa mitjançant els diners dels 

seus impostos, l’han de tornar a pagar si el volen utilitzar (per haver- 

ne d’adquirir llicències d’ús). 

Nota 

El lector coneixedor de les iniciatives públiques respec- 

te del programari lliure reconeixerà en aquest exemple 

el cas de LinEx. Al final del 2001 la Junta d’Extrema- 

dura va decidir utilitzar una distribució de GNU/Linux 

per a informatitzar tots els col·legis públics de la regió. 

Per a això, va finançar la construcció de LinEx, una dis- 

tribució basada en Debian GNU/Linux que es va 

anunciar a la primavera del 2002, i va decidir que fos 

un requisit en tots els concursos d’adquisició d’equipa- 

ment informàtic per a centres educatius. A més a més, 

va iniciar programes de formació i capacitació de pro- 

fessors, creació de materials docents i extensió de l’ex- 

periència a altres àmbits. A mitjan 2003, l’experiència 

sembla ser un èxit, que ja s’està estenent institucional- 

ment a altres regions (per exemple, a Andalusia, tam- 

bé a Espanya, amb el projecte GuadaLinex). 

El programari lliure ofereix una opció interessant que les autoritats 

encarregades de la política d’innovació en moltes administracions 

consideren cada cop amb més atenció. Especialment en els casos en 

què la investigació és precompetitiva (el més habitual en els casos de 

finançament públic), que els programes resultants siguin lliures per- 

met que la indústria en conjunt (i per tant la societat) es beneficiï dels 

diners públics gastats en R+D en el camp del programari. On una 

145 


ANOTACIONS


ANOTACIONS 



apartat 112] 




146 


empresa pot veure un resultat de comercialització impossible, una al- 

tra hi pot veure una oportunitat de negoci. Així, d’una banda, es ma- 

ximitzen els resultats dels programes d’investigació; i de l’altra, 

s’afavoreix la competència entre les empreses que vulguin utilitzar els 

resultats d’un projecte, ja que totes competiran amb els mateixos 

programes resultat del projecte. 

Aquest model no és nou, és el que ha permès, sobretot, el desenvolu- 

pament d’Internet. Si les administracions públiques exigeixen que els 

resultats de la investigació elaborada amb els seus fons es distribueixin 

en forma de programes lliures, no seria gens estrany que aparegues- 

sin casos similars en altres escales. O bé els resultats d’aquestes inves- 

tigacions són dolents o inútils (i en aquest cas hauria de replantejar-se 

la forma de selecció dels projectes), o bé la dinamització que repre- 

sentaria deixar-los enllestits perquè qualsevol empresa els pugués 

convertir en producte permetria desenvolupaments senzillament im- 

predictibles. 

6.3. Iniciatives legislatives 

En els apartats següents es repassen algunes iniciatives que els po- 

ders legislatius duen a terme a diversos països del món. Ens centra- 

rem en les iniciatives pioneres. Sens dubte, aquesta llista d’iniciatives 

no és exhaustiva. El lector interessat a completar-la pot consultar la Le- 

gislació sobre l’ús de programari lliure en l’estat (GrULIC), on s’es- 

menten moltes iniciatives a tot el món. 

6.3.1. Projectes de llei a França 

El 1999 i el 2000 es van presentar a França dos projectes de llei re- 

lacionats amb el programari lliure que van ser els pioners d’una llar- 

ga sèrie de debats legislatius sobre la matèria: 

• El Projecte de llei 1999-495, proposat per Laffitte, Trégouet i 

Cabanel, es va exposar al servidor web del Senat de la República 

Francesa a partir de l’octubre del 1999. Després d’un procés de 

discussió pública per Internet que es va prolongar durant dos me- 

sos, el projecte va experimentar algunes modificacions. El resultat


és el Projecte de llei número 2000-117, que advocava per l’ús 

obligatori de programari lliure en l’Administració i preveia excep- 

cions i mesures transitòries per a aquells casos en què encara no 

sigui tècnicament possible, en un marc més general, que intenta- 

va generalitzar l’ús d’Internet i del programari lliure en l’Adminis- 

tració francesa. 

• L’abril del 2000 els diputats Jean-Yves Le Déaut, Christian Paul i 

Pierre Cohen van proposar una nova llei amb objectius semblants 

al projecte de Laffitte, Trégouet i Cabanel: reforçar les llibertats i 

la seguretat del consumidor i millorar la igualtat de drets en la so- 

cietat de la informació. 

Tanmateix, a diferència del projecte de llei de Laffitte, Trégouet i 

Cabanel, aquest altre no obliga a utilitzar programari lliure en l’Ad- 

ministració. Aquest projecte de llei persegueix que el programari uti- 

litzat en l’Administració tingui el codi font disponible, si bé no 

n’obliga la distribució amb llicències de programari lliure. 

Per a assolir-ne els objectius, els legisladors pretenen garantir el “dret 

a la compatibilitat” del programari, proporcionant mecanismes que 

portin a la pràctica el principi d’interoperabilitat plasmat en la Direc- 

tiva del Consell Europeu relativa a la protecció jurídica de programes 

d’ordinador. 

Cap dels dos projectes francesos no es va convertir en llei, però tots 

dos han servit d’inspiració a la majoria de les iniciatives posteriors a 

tot el món, i per això és especialment interessant estudiar-los. El segon 

projecte (proposat per Le Déaut, Paul i Cohen) perseguia la compati- 

bilitat i la interoperabilitat del programari, i subratllava la disponibili- 

tat del codi font del programari utilitzat en l’Administració. Tanmateix, 

no requereix que les aplicacions desenvolupades siguin programari 

lliure, entès com el que es distribueix amb llicències que garanteixen 

la llibertat de modificació, ús i redistribució del programa. 

Més endavant (apartats 6.4.1 i 6.4.2) reproduïm de manera gairebé 

íntegra l’articulat i l’exposició de motius de tots dos projectes de llei. En 

particular, són d’un interès especial les exposicions de motius, ja que 

destaquen quins són els problemes que sotgen avui dia les administra- 

cions públiques en relació amb l’ús de programari en general. 

147 




apartat 92] 

ANOTACIONS


ANOTACIONS 



apartat 164] 


[Vegeu bibliografia, apartats 

163 i 199] 

148 


6.3.2. Projecte de llei al Brasil 

El diputat Walter Pinheiro va presentar el desembre del 1999 un pro- 

jecte de llei sobre el programari lliure a la Cambra Federal del Brasil. 

Aquest projecte (encara en tramitació l’agost del 2003) afecta a la 

utilització de programari lliure en l’Administració pública i en les em- 

preses privades controlades accionarialment per l’Estat. 

S’hi recomana l’ús de programari lliure en les entitats que no tingui 

restriccions de préstec, modificació o distribució. L’articulat de la llei 

descriu amb detall què s’entén per programari lliure i com han de ser 

les llicències que l’acompanyin. Les definicions coincideixen amb la 

definició clàssica de programari lliure del projecte GNU. En l’exposi- 

ció de motius es repassa la història del projecte GNU i se n’analitzen 

els avantatges i els èxits. També es fa referència a la situació actual 

del programari lliure, utilitzant com a exemple el sistema operatiu 

GNU/Linux. 

Una de les parts més interessants, l’article primer, deixa ben clar 

l’àmbit en què es proposa l’ús de programari lliure (tenint en compte 

que la definició de programari obert que s’ofereix en els articles pos- 

teriors és, com ja hem dit, programari lliure): 

aaa 

“L’Administració pública, en tots els nivells, els poders 

de la República, les empreses estatals i d’economia 

mixta, les empreses públiques i tots els altres organis- 

mes públics o privats subjectes al control de la societat 

brasilera estan obligats a utilitzar preferentment en els 

seus sistemes i equipaments d’informàtica, programes 

oberts lliures de restriccions propietàries quant a la 

seva cessió, modificació i distribució.” 

6.3.3. Projectes de llei al Perú 

Són diversos els projectes de llei relacionats amb l’ús del progra- 

mari lliure en les administracions públiques que s’han proposat al 

Perú. El primer i més conegut el va proposar el congressista Edgar 

Villanueva Núñez el desembre del 2001, en el qual es defineix pro


gramari lliure segons l’accepció clàssica de les quatre llibertats (pot- 

ser hi dóna una precisió legal més gran, atès que especifica sis 

característiques per a la definició d’un programa lliure), i en proposa 

la utilització exclusiva a l’administració peruana: 

aaa 

Encara que una mica més endavant, els articles 4 i 5 inclouen algu- 

nes excepcions a aquesta regla. 

En el seu dia aquesta proposta de llei va tenir una gran repercussió 

mundial. D’una banda, va ser la primera vegada que es va proposar 

l’ús exclusiu del programari lliure en una administració. Però encara 

més important va ser l’intercanvi epistolar entre el congressista 

Villanueva i la representació de Microsoft al Perú, que va fer al·legaci- 

ons a la proposta. També és interessant per la posició que hi va pren- 

dre l’ambaixada dels Estats Units d’Amèrica, que va arribar a enviar 

una notificació per conducte oficial (adjuntant-hi un informe elaborat 

per Microsoft) al Congrés peruà en la qual expressava “la seva pre- 

ocupació sobre les recents propostes del Congrés de la República per 

restringir les compres per part del Govern peruà de programari de 

codi obert o programari lliure”. Entre altres raons, tant les al·legaci- 

ons de Microsoft com les de l’ambaixada dels Estats Units d’Amèrica 

tractaven de mostrar com la proposta de llei discriminaria unes em- 

preses davant de les altres i faria impossible les inversions necessà- 

ries per a la creació d’una indústria nacional de creació de 

programari. Davant d’això, Villanueva argumenta que la seva pro- 

posició de llei no discrimina ni afavoreix de cap manera cap empre- 

sa en particular, ja que no especifica qui podrà ser proveïdor de 

l’Administració, sinó com (en quines condicions) s’haurà de fer la 

provisió de programari. Aquesta argumentació és molt clara per a 

entendre que la promoció del programari lliure en l’Administració 

no perjudica en cap cas la lliure competència entre les empreses 

subministradores. 

“Article 2. Els poders Executiu, Legislatiu i Judicial, els 

organismes descentralitzats i les empreses on l’Estat tin- 

gui majoria accionària empraran en els seus sistemes i 

equipaments d’informàtica exclusivament programes o 

programari lliures.” 

149 




apartat 127] 

ANOTACIONS


ANOTACIONS 



apartat 200] 



apartat 80] 



apartat 198] 

150 


Més endavant, els congressistes peruans Edgar Villanueva Núñez i 

Jacques Rodrich Ackerman van presentar un nou projecte de llei 

(2485, de 8 d’abril de 2002), que l’agost del 2003 continua el seu 

tràmit parlamentari. Aquest projecte és una evolució del Projecte de 

llei 1609, ja que hi recull diversos comentaris i millores i es pot con- 

siderar un bon exemple de projecte de llei que proposa l’ús exclusiu 

de programari lliure en les administracions públiques, llevat d’alguns 

casos excepcionals. Pel seu interès, n’incloem el text íntegre en 

l’apartat 6.4.3. Concretament, l’exposició de motius és un bon resum 

de les característiques que hauria de tenir el programari utilitzat per 

les administracions públiques i de com el programari lliure compleix 

aquestes característiques més bé que el propietari. 

6.3.4. Projectes de llei a Espanya 

A Espanya hi ha hagut diverses iniciatives legislatives relacionades 

amb el programari lliure. A continuació n’esmentem algunes: 

• Decret de mesures d’impuls de la societat del coneixement a 

Andalusia 

Una de les iniciatives legislatives més importants (perquè ha entrat en 

vigor) que han tingut lloc a Espanya ha estat sens dubte l’adoptada 

per Andalusia. En el Decret de mesures d’impuls de la societat del co- 

neixement a Andalusia es tracta l’ús de programari lliure, sobretot 

(però no solament) en l’entorn educatiu. 

Entre altres detalls, fomenta l’ús de programari lliure de manera pre- 

ferent en els centres docents públics, obliga que tot l’equipament ad- 

quirit per a aquests centres sigui compatible amb sistemes operatius 

lliures i obliga els centres de la Junta que ofereixin accés públic a In- 

ternet a fer el mateix. 

• Proposició de llei de programari lliure en el marc de l’Adminis- 

tració pública de Catalunya 

En altres comunitats s’han discutit proposicions més ambicioses, 

però sense que hagin aconseguit la majoria necessària. La més 

coneguda és probablement la debatuda en el Parlament de


Catalunya, a proposta d’Esquerra Republicana de Catalunya, 

molt similar a la que el mateix partit va presentar al Congrés dels Di- 

putats, i de la qual també parlem. Aquesta proposta no va prosperar 

quan es va sotmetre a votació. 

• Projecte de llei de Puigcercós Boixassa en el Congrés dels 

Diputats 

En el Congrés dels Diputats també hi ha hagut una iniciativa, propo- 

sada per Joan Puigcercós Boixassa (Esquerra Republicana de 

Catalunya). Aquesta iniciativa proposa la preferència per l’ús de pro- 

gramari lliure a l’Administració de l’Estat, i en aquest sentit és similar 

a altres iniciatives amb la mateixa finalitat. Tanmateix, té la peculia- 

ritat interessant de posar l’èmfasi en la disposició que presenten els 

programes lliures localitzats als idiomes cooficials (en les comunitats 

autònomes que els tenen). La iniciativa no va aconseguir ser aprova- 

da en el tràmit parlamentari. 

6.4. Textos d’algunes propostes legislatives 

i documents relacionats 

A continuació s’ofereixen les transcripcions literals d’algunes de les 

propostes legislatives esmentades en aquest capítol i el text d’alguns 

documents relacionats amb aquestes propostes. 

6.4.1. Projecte de llei de Laffitte, Trégouet i Cabanel 

(França) 

Reproduïm una traducció al català del projecte de llei dut a terme 

l’octubre del 1999 pels senadors francesos Pierre Laffitte, René 

Trégouët i Guy Cabanel. 

Exposició de motius 

(S’inclouen només aquells paràgrafs relatius al programari lliure) 

“[...] Per tal de garantir la perennitat de les dades accessibles, facili- 

tar-ne l’intercanvi i assegurar el lliure accés dels ciutadans a la infor- 

151 




apartat 167] 


[Veure bibliografia, 

apartat 140] 

ANOTACIONS


ANOTACIONS 

152 


mació, cal que la seva utilització en l’Administració no depengui de 

la bona voluntat dels fabricants de programari. Es necessiten siste- 

mes lliures l’evolució dels quals es pugui garantir gràcies a la dispo- 

nibilitat per part de tots del codi font utilitzat pel fabricant.” 

“El desenvolupament del programari lliure és actualment molt fort. 

Són moltes les grans empreses d’informàtica que reconeixen que el 

futur del seu negoci no estarà a vendre el programari, sinó a facilitar- 

ne l’ús mitjançant la prestació de serveis associats.” 

“El nostre projecte de llei preveu que després d’un període transitori 

definit per decret, l’ús de programari lliure en les administracions pú- 

bliques sigui obligatori.” 

“Només es podrà utilitzar programari propietari el codi font del qual 

no estigui disponible en casos concrets si hi ha una autorització d’una 

agència del programari lliure [...].” 

Articles 

• Article 1. Sobre la immaterialització dels intercanvis d’informació 

i dades entre les administracions públiques 

Els serveis de l’Estat, les administracions locals i els organismes pú- 

blics s’asseguraran d’intercanviar dades i informació en suport elec- 

trònic i amb xarxes electròniques, a partir de l’1 de gener del 2002. 

Les condicions que regularan la situació transitòria entre l’actual in- 

tercanvi en suport paper i l’intercanvi en suport i xarxes electròniques 

s’hauran de fer per decret. 

• Article 2. Sobre la desmaterialització dels processos dels mercats 

públics 

A fi i efecte d’aconseguir una gran transparència i un accés ràpid a 

la informació per part de les empreses, les convocatòries d’ofertes 

públiques i també els documents annexos seran objecte de publicitat 

en suport i xarxes electròniques a partir de l’1 de gener del 2002.


Així, s’haurà de respondre a les convocatòries d’ofertes públiques en 

suport electrònic i per xarxes electròniques. 

Un decret determinarà els mecanismes de transició als processos 

electrònics. 

• Article 3. Sobre les tecnologies obertes 

Els serveis de l’Estat, les administracions locals i els organismes pú- 

blics només podran utilitzar, a partir de l’1 de gener del 2002 (ex- 

cepció feta del que disposa l’article 4), programari l’ús (i la 

modificació) del qual siguin lliures i amb el codi font disponible. 

Un decret fixarà les condicions de transició. 

• Article 4. Sobre l’agència del programari lliure 

Es crearà l’Agència del Programari Lliure. S’encarregarà d’informar 

els serveis de l’Estat, les administracions locals i els organismes pú- 

blics de les condicions d’aplicació d’aquesta llei. L’Agència determi- 

narà les llicències d’utilització de programari que s’adeqüen al marc 

fixat per aquesta llei. 

L’Agència vetllarà per la interoperabilitat del programari lliure dins 

de les administracions públiques. 

L’Agència farà l’inventari, per sectors d’activitat, de les mancances 

del programari l’ús i la modificació del qual siguin lliures i el codi font del 

qual estigui disponible. En funció d’aquest inventari, l’Agència auto- 

ritzarà les administracions públiques a no aplicar aquesta llei. 

L’Agència del programari lliure estarà oberta als internautes i les seves 

decisions hauran d’estar precedides per consultes fetes per Internet. 

Es designarà una persona d’enllaç amb l’Agència del programari 

lliure en cada prefectura. 

Les modalitats de funcionament de l’Agència del programari lliure 

s’establiran per decret. 

153 


ANOTACIONS


ANOTACIONS 

154 


• Article 5. Sobre la difusió de les modificacions del programari uti- 

litzat en el marc d’aquesta llei 

L’Agència del Programari Lliure vetllarà, tot respectant els drets dels 

autors, perquè es difonguin les modificacions fetes al programari en 

el marc d’aquesta llei. 

• Article 6. 

Les despeses que faci l’Estat amb motiu d’aquesta llei seran compen- 

sades mitjançant un increment dels drets apuntats en els articles 575 

i 575 A del Codi general d’impostos. 

6.4.2. Projecte de llei de Le Déaut, Paul i Cohen (França) 

A continuació mostrem la traducció al català del text pràcticament ín- 

tegre del projecte de llei presentat per Jean-Yves Le Déaut, Christian 

Paul i Pierre Cohen l’abril del 2000: 


L’increment fulgurant de la utilització de les noves tecnologies de la 

informació i de les telecomunicacions necessita un acompanyament 

legislatiu. Els serveis públics i les administracions locals s’han de con- 

vertir en model i motor de la societat de la informació que sigui ga- 

rant de les llibertats individuals, de la seguretat del consumidor i de 

la igualtat d’oportunitats en la matèria que ens ocupa. 

Diversos exemples mostren que, malgrat alguns progressos impor- 

tants fets gràcies a l’acció del Govern en l’àrea de la societat de la 

informació, els serveis de l’Estat solen utilitzar estàndards de comu- 

nicació relacionats íntimament amb un proveïdor privat únic, la qual 

cosa obliga l’usuari o la col·lectivitat a ser client d’aquest proveïdor, 

reforçant així, de manera significativa, els fenòmens d’abús de posi- 

ció dominant. 

Els serveis de l’Estat utilitzen sovint programari el codi font del qual 

no està disponible, la qual cosa els impedeix que es corregeixin els


errors que els mateixos proveïdors es neguen a corregir o verificar si 

hi ha defectes de seguretat en les aplicacions sensibles. Els serveis de 

l’Estat utilitzen, de vegades sense saber-ho, programari que transmet 

secretament informació considerada a priori com a confidencial a 

societats o organismes estrangers. 

Ara bé, els models econòmics de la indústria del programari i de les 

telecomunicacions desenvolupats pel mercat es basen sobretot en 

l’apropiació d’una clientela i en la valoració exponencial de la cap- 

tació dels perfils dels usuaris. Aquests models econòmics afavoreixen 

estratègies d’incompatibilitat, de secret industrial, d’obsolescència 

programada i de violació de les llibertats individuals. Si bé l’Estat 

francès no pot pretendre eliminar per llei aquestes tendències subja- 

cents a causa del caràcter transnacional de les xarxes de comunica- 

ció, sí que pot afavorir, tanmateix, el desenvolupament en territori 

francès d’una societat de la informació que sigui respectuosa amb les 

llibertats públiques, amb la seguretat del consumidor i amb la igual- 

tat d’oportunitats, i es pot esperar que hi tingui un paper precursor a 

Europa i al món. 

La llei que proposem es fonamenta en cinc principis: el lliure accés 

del ciutadà a la informació pública, la perennitat de les dades públi- 

ques, la seguretat de l’Estat, la seguretat del consumidor en la societat 

de la informació i el principi d’interoperabilitat de la legislació sobre 

programari. 

Per a garantir el lliure accés del ciutadà a la informació pública, fa 

falta que la codificació de les dades informàtiques comunicades per 

l’Administració no estigui lligada a un proveïdor únic. Els estàndards 

oberts, és a dir, els que han fet públiques les regles de codificació de 

la informació, garanteixen aquest lliure accés en permetre, si és ne- 

cessari, el desenvolupament de programari lliure compatible. 

Per a garantir la perennitat de les dades públiques, cal que la utilit- 

zació i el manteniment del programari no depenguin de la bona in- 

tenció dels creadors del programari. Fan falta sistemes l’evolució 

dels quals sempre estigui garantida per la disponibilitat del codi font. 

El principi de disponibilitat del codi font en el marc dels contractes 

basats en llicències, principi present a data d’avui només com a op- 

ció en la legislació sobre compres públiques d’utilitats i paquets de 

155 


ANOTACIONS


ANOTACIONS 

156 


programari, s’ha de convertir en la regla i aplicar-lo a totes les com- 

pres públiques de programari. 

Hem rebutjat voluntàriament una aproximació legislativa basada ex- 

clusivament en l’ús de programari lliure. Seria inoportú que, fos qui- 

na fos la qualitat reconeguda del programari lliure, l’Estat afavorís 

un determinat model econòmic d’edició de programari. Al contrari, 

el recurs obligatori en estàndards de comunicació oberts i la publi- 

cació del codi font garanteixen una igualtat d’oportunitats segons el 

principi d’interoperabilitat de la legislació sobre programari. 

Per a garantir la seguretat nacional, fan falta sistemes desproveïts 

d’elements que permetin un control a distància o la transmissió invo- 

luntària d’informació a un tercer. Necessitem sistemes que tinguin un 

codi font accessible lliurement al públic per tal de permetre l’examen 

per un gran nombre d’experts mundials independents. El nostre pro- 

jecte de llei hauria d’aportar més seguretat a l’Estat, ja que el conei- 

xement del codi font eliminarà el nombre creixent de programari que 

conté “portes del darrere”. 

El nostre projecte de llei també hauria de reforçar la seguretat del 

consumidor en la societat de la informació, en permetre l’aparició 

d’una oferta de programari desproveït de “portes del darrere”, que 

amenacen el respecte de la vida privada i de les llibertats individuals. 

Però perquè emergeixi la igualtat d’oportunitats cal que es reafirmi i 

reforci el principi d’interoperabilitat introduït en la legislació sobre 

programari i en la legislació sobre la compatibilitat. Tots dos drets es- 

tan avui amenaçats pels actors que gaudeixen d’una posició domi- 

nant, que posen traves a l’aparició de la competència. 

Per a garantir la interoperabilitat del programari, cal que els drets de 

propietat intel·lectual o industrial d’un creador de programari no blo- 

quegin el desenvolupament del nou programari compatible que 

competeixi amb ell. El dret a la compatibilitat per a tots, és a dir, el 

dret a desenvolupar, publicar i utilitzar lliurement un programari ori- 

ginal compatible amb un altre, ha d’estar garantit per la llei. El prin- 

cipi d’interoperabilitat introduït pel dret europeu del programari 

també ha de prevaler sobre els altres drets eventuals de propietat in- 

tel·lectual o industrial. En particular, l’existència d’una marca sobre


un estàndard de comunicacions o d’una patent sobre un procés in- 

dustrial necessari per a implementar un estàndard de comunicacions, 

no hauria de permetre que el seu posseïdor bloquegi o limiti la difu- 

sió lliure de programari compatible. 

El nostre projecte de llei es pot aplicar immediatament. En efecte, la 

majoria dels editors de programari estan disposats a adoptar estàn- 

dards de comunicació oberts com els definits a París, Boston i Tòquio 

pel World Wide Web Consortium. Hi ha molts editors de programari 

propietari que estan igualment disposats a proporcionar a l’Adminis- 

tració francesa el codi font dels seus productes. A més, l’oferta de 

programari lliure entorn del sistema operatiu Linux cobrirà d’ara en- 

davant moltes de les necessitats de l’Administració. Tanmateix, les 

administracions i col·lectivitats no estan prou informades de l’existèn- 

cia d’estàndards oberts, o de l’oferta de programari publicat amb 

codi font. 

Per a facilitar l’adopció ràpida dels estàndards oberts, s’ha de refor- 

çar el paper de la comissió interministerial de suport tècnic per al 

desenvolupament de les tecnologies de la informació i la comunica- 

ció en l’Administració (Mission interministérielle de soutien technique 

pour le développement des technologies de l’information et de la 

communication dans l’administration), i confiar-li la missió de fer i di- 

fondre dins de l’Administració un cens de l’oferta d’estàndards oberts 

i programari amb codi font publicat. En cas que no hi hagi un mer- 

cat, la MTIC s’encarregarà de desenvolupar nous estàndards o nou 

programari publicat amb el seu codi font. Per a dur a terme aquestes 

noves missions, la MTIC es transformarà en l’Agència de Tecnologies 

de la Informació i la Comunicació (ATIC). 

Quan no hi hagi un mercat, l’ATIC s’encarregarà de desenvolupar 

nous estàndards o nou programari publicat amb el seu codi font. Per 

a aconseguir la igualtat d’oportunitats, els desenvolupaments de 

programari que es produeixin seran de domini públic; per tant, es 

podran comercialitzar com a programari propietari o com a progra- 

mari lliure, segons la llicència que esculli lliurement l’editor. L’ATIC 

també s’encarregarà d’avaluar el nivell d’interoperabilitat, de pe- 

rennitat i de seguretat del programari comprat per l’Administració 

francesa. 

157 


ANOTACIONS


ANOTACIONS 

158 


Més genèricament, els sistemes de comunicació oberts i la disponibili- 

tat del codi font són indispensables per a garantir, a escala europea, 

la interoperabilitat entre els sistemes d’informació de les administra- 

cions i dels organismes públics nacionals i per a evitar que la inter- 

connexió entre sistemes depengui només de la bona voluntat dels 

editors de programari. L’ATIC també s’encarregarà de participar en 

els treballs de cooperació internacional en el domini de les tecnolo- 

gies de la informació i les comunicacions, i d’afavorir la interopera- 

bilitat amb els sistemes d’informació dels altres països membres de 

la Unió Europea. 

El nostre projecte de llei respon a les preocupacions esmentades més 

amunt. Ens recorda que l’Estat pot tenir un paper en l’economia pre- 

servant l’interès nacional i europeu, defensant alhora l’economia de 

mercat. Aquest projecte de llei permetrà que França s’erigeixi en de- 

fensora de les llibertats dins de les noves tecnologies de la informació 

i les comunicacions. 

Articles 

• Article 1 

Per a tots els intercanvis de dades informàtiques, l’Administració de 

l’Estat, les administracions locals i els organismes públics, tenen 

l’obligació d’emprar estàndards de comunicació oberts, constituïts 

per regles i procediments públics d’intercanvi de dades digitals. 

• Article 2 

L’Administració, els organismes públics i les administracions públi- 

ques territorials estan obligats a utilitzar programari amb codi font 

accessible. 

• Article 3 

Tota persona física o jurídica té dret a desenvolupar, publicar o uti- 

litzar programari original compatible amb els estàndards de comu- 

nicació de qualsevol altre programari.

• Article 4 


Es crearà un organisme públic de l’Estat, anomenat Agència de les 

Tecnologies de la Informació i les Comunicacions. Aquest organisme 

serà tutelat pel Ministeri d’Indústria. L’ATIC té la missió d’informar i 

aconsellar els serveis de l’Estat, les col·lectivitats i els organismes pú- 

blics sobre la concepció i la identificació de les necessitats tècniques 

en matèria de tecnologies de la informació i les comunicacions. 

Identificarà les necessitats dels serveis públics en matèria d’equips 

i programari, vetllarà per l’harmonització dels estàndards de co- 

municació i proposarà les pràctiques tècniques a l’ús. Farà l’inven- 

tari per sectors d’activitat dels estàndards oberts i del programari 

disponible. 

En funció d’aquest inventari, donarà suport al desenvolupament 

d’estàndards oberts i de programari publicat amb el seu codi font, i 

n’afavorirà la utilització en el domini públic per a pal·liar les man- 

cances del mercat. 

L’ATIC afavorirà la interoperabilitat amb els sistemes d’informació 

d’altres països membres de la Unió Europea i participarà en els pro- 

jectes de cooperació internacional en el domini de les tecnologies de 

la informació i la comunicació. L’ATIC tindrà un interlocutor en cada 

prefectura. 

Les modalitats de funcionament de l’ATIC s’establiran mitjançant 

decret. 

• Article 5 

Les modalitats d’aplicació d’aquesta llei, com també les condicions 

de transició des de la situació actual, es fixaran mitjançant decret del 

Consell d’Estat. 

• Article 6 

Les despeses de l’Estat resultants de l’aplicació d’aquesta llei es pa- 

garan amb càrrec a les partides fixades en els articles 575 i 575 A 

del Codi general d’impostos. 

159 


ANOTACIONS


ANOTACIONS 



apartat 200] 

160 


6.4.3. Projecte de llei de Villanueva i Rodrich (El Perú) 

Transcripció de gran part del Projecte de llei número 2485, Llei d’ús 

de programari lliure en l’Administració pública, dels congressistes peru- 

ans Edgar Villanueva Núñez i Jacques Rodrich Ackerman. 


La complexitat del món en què vivim exigeix permanentment dels 

països una constant revisió i adaptació dels seus marcs institucionals, 

per la qual cosa, d’aquesta manera aconseguim mantenir-nos al dia 

dels nous reptes que ens imposa el sorprenent desenvolupament tec- 

nològic. 

El descobriment de noves tecnologies informàtiques, com la del pro- 

gramari lliure, s’ha configurat amb el pas del temps en un instrument 

perfecte per a assegurar d’una manera més idònia la protecció de la 

informació amb què compta l’Estat. 

D’aquesta manera, la tecnologia compleix la seva funció facilitadora 

de les diferents i múltiples activitats humanes, una de les quals és la 

manipulació d’informació reservada a l’Estat. 

Segons la Constitució Política del Perú, en l’incís 5 de l’article 2, “tota 

persona té dret a sol·licitar sense expressió de causa la informació 

que requereixi i a rebre-la de qualsevol entitat pública, en el termini 

legal, amb el cost que impliqui la comanda. Se n’exceptuen les infor- 

macions que afecten a la intimitat personal i les que expressament 

s’exclouen per llei o per raons de seguretat nacional”. 

De la mateixa manera, l’incís 6 del mateix article emfasitza el dret de 

qualsevol persona “que els serveis informàtics, computaritzats o no, 

públics o privats, no subministrin informacions que afectin a la inti- 

mitat personal i familiar”. 

En aquest ordre d’idees, és evident la preocupació que mostra la 

nostra carta fonamental per establir assegurances institucionals que 

d’una banda protegeixin la llibertat dels ciutadans per a accedir a in- 

formació pública i, de l’altra, la de guardar la reserva d’informació


pertinent que afecti a la intimitat personal i familiar, com també 

raons de seguretat nacional. 

La garantia d’aquests drets consagrats en la nostra Constitució no pas- 

sa únicament per la bona voluntat dels agents de l’Estat per al seu com- 

pliment normatiu, sinó també per l’ús de tecnologies que en uns casos 

coadjuven, però en d’altres no, a una efectiva protecció d’aquests drets 

ciutadans. 

En aquest context, és imperiós que l’Estat incorpori les tecnologies 

que ajuden a reforçar l’exercici del dret de la informació dels ciuta- 

dans i la pertinent reserva en els casos que la mereixen. 

La utilització del programari lliure en totes les institucions de l’Estat 

apunta en aquest sentit. Bàsicament, podem dir que els principis ele- 

mentals que animen aquest projecte de llei es vinculen a garanties 

bàsiques de l’Estat democràtic de dret i els podem resumir en els se- 

güents: 

1. Lliure accés del ciutadà a la informació pública 

2. Perennitat de les dades públiques 

3. Seguretat de l’Estat i dels ciutadans 

Per a garantir el lliure accés dels ciutadans a la informació pública, 

resulta indispensable que la codificació de les dades no estigui lliga- 

da a un únic proveïdor. L’ús de formats estàndard i oberts permet ga- 

rantir aquest lliure accés, aconseguint si fos necessària la creació de 

programari compatible. 

Per a garantir la perennitat de les dades públiques, és indispensable 

que la utilització i el manteniment del programari no depenguin de 

la bona voluntat dels proveïdors, ni de les condicions de monopoli 

que imposen. Es necessiten sistemes l’evolució dels quals es pugui 

garantir gràcies a la disponibilitat del codi font. 

Per a garantir la seguretat nacional, resulta indispensable disposar 

de sistemes desproveïts d’elements que permetin el control a distàn- 

cia o la transmissió no desitjada d’informació a tercers. Per tant, es 

161 


ANOTACIONS


ANOTACIONS 

162 


requereixen sistemes que permetin el lliure accés al codi del public, 

del mateix Estat, dels ciutadans i d’un gran nombre d’experts inde- 

pendents de tot el món. 

Aquesta proposta aporta més seguretat, ja que el coneixement del 

codi font eliminarà el nombre creixent de programes amb codi espia. 

De la mateixa manera, la iniciativa de llei potencia la seguretat dels 

ciutadans, tant en la seva condició de titulars legítims de la informa- 

ció que gestiona l’Estat, com en la condició de consumidors. En 

aquest últim cas permet l’aparició d’una extensa oferta de progra- 

mari lliure desproveït de potencial codi espia susceptible de posar en 

risc la vida privada i les llibertats individuals. 

L’Estat, amb la finalitat de millorar la qualitat de la gestió pública 

com a custodi i administrador d’informació privada, establirà les 

condicions en què els organismes estatals adquiriran programari en 

el futur, és a dir, d’una manera compatible amb les garanties cons- 

titucionals i els principis bàsics abans desenvolupats. 

El projecte expressa clarament que perquè qualsevol programa o 

programari sigui acceptable per l’Estat, no n’hi ha prou que el pro- 

grama sigui tècnicament suficient per a dur a terme una tasca, sinó 

que a més les condicions de contractació han de satisfer un seguit de 

requisits en matèria de llicència, sense els quals l’Estat no pot garan- 

tir al ciutadà el processament adequat de les seves dades, vetllant per 

llur integritat, confidencialitat i accessibilitat en el temps, aspectes crí- 

tics per al seu acompliment. 

L’Estat estableix condicions per a l’ús del programari per part de les 

institucions estatals, sense immiscir-se de cap manera en les transac- 

cions del sector privat. Constitueix un principi jurídicament recone- 

gut el fet que l’Estat no té l’ampli espectre de llibertat contractual 

del sector privat, ja que precisament està limitat en les seves accions 

pel deure de transparència dels actes públics, i en aquest sentit, la 

tutela del millor interès comú ha de tenir preeminència quan es le- 

gisla sobre la matèria. 

Així, el projecte garanteix el principi d’igualtat davant la llei, ja que 

cap persona natural i jurídica no està exclosa del dret de proveir


aquests béns, en les condicions fixades en aquesta iniciativa i sense 

més limitacions que les establertes en la Llei de contractacions i ad- 

quisicions de l’Estat (TUO per decret suprem núm. 012-2001-PCM). 

Addicionalment a aquests avantatges, podem destacar una sèrie de 

beneficis que com a conseqüència d’aquesta mesura es manifesta- 

ran immediatament després de ser executats. 

En primer lloc hi ha les oportunitats de feina per a programadors lo- 

cals. De l’univers de programari per a servidors que es va comercia- 

litzar l’any passat als Estats Units d’Amèrica, el 27% va correspondre 

a programes “lliures”, proporció veritablement significativa per a 

aquest enorme i exigent mercat. La xifra és eloqüent i és una resposta 

contundent als qui creuen que el programari lliure implicarà una for- 

ta limitació en l’ocupació dels programadors del país. Al contrari, la 

iniciativa permetrà alliberar una gran quantitat de recursos, i repre- 

sentarà un incentiu per a potenciar la creativitat humana. 

En emprar el programari lliure, els professionals poden analitzar a 

fons els problemes i millorar els desenvolupaments en tots els casos 

que sigui necessari, nodrint-se del programari lliure disponible glo- 

balment sota diferents llicències. Constitueix un camp ideal per a 

aplicar creativitat, aspecte en què els joves peruans assolirien bons 

resultats. 

D’altra banda, mitjançant el programari lliure s’elimina l’ús de pro- 

gramari il·legal que es “passeja” per algunes institucions de l’Estat. 

L’ús no permès de programari dins de l’Estat o la mera sospita 

d’aquest ús representa un incentiu poderós perquè qualsevol funcio- 

nari públic modifiqui aquesta situació, cosa que atemptaria contra 

els drets de propietat intel·lectual. 

Si bé és correcte dir que no cal adoptar programari lliure per a com- 

plir la llei, l’ús generalitzat reduirà dràsticament les situacions irregu- 

lars i obrarà com a “vector de contagi legal”, tant dins de l’Estat com 

en l’àmbit privat. 

Són molts els països que reconeixen formalment l’ús exclusiu del pro- 

gramari lliure en el sector estatal. 

163 


ANOTACIONS


ANOTACIONS 

164 


Entre aquests països hi ha França, on es discuteix una norma legal 

sobre la qüestió. El Govern de la ciutat de Mèxic ja ha iniciat una im- 

portant migració per a l’adopció de programari lliure de manera ge- 

neralitzada, país que és líder a Occident. També al Brasil, l’estat de 

Recife ha decidit adoptar-lo. La República Popular de la Xina ha 

adoptat des de fa uns quants anys el programari lliure com una po- 

lítica d’estat. Igual que els països escandinaus. Als Estats Units 

d’Amèrica, la NASA i la US NAVY, entre moltes altres organitzacions, 

han adoptat programari lliure per a alguna de les seves necessitats, 

entre altres iniciatives governamentals i del sector privat. 

Finalment, el projecte de llei en qüestió atorga a la Presidència del 

Consell de Ministres l’execució d’aquesta llei perquè sigui aquest or- 

ganisme el que concentri la direcció de totes les institucions governa- 

mentals. En aquest sentit, té un avantatge estratègic per a fer la 

reforma pertinent i el procés migratori de programari propietari a 

programari lliure. 

És en aquest ordre d’idees que s’han precisat aquests aspectes en la 

present proposició legislativa. 

Anàlisi cost-benefici 

Aquesta iniciativa no genera cap despesa a l’erari nacional. Això sí, 

per al compliment de les seves finalitats caldrà produir una reassig- 

nació de la despesa governamental, la incidència de la qual se cir- 

cumscriu a l’efectivament gastat per cada organisme governamental 

en els processos de contractacions i licitacions de l’Estat per a l’ad- 

quisició de programes informàtics. 

Si bé és cert que el programari lliure amb relació al programari pro- 

pietari representa un estalvi substancial a l’economia de l’Estat, no 

és el punt principal de suport. Com hem assenyalat abans, l’avantat- 

ge comparatiu es focalitza en les reassegurances tecnològiques que el 

programa atorga a la informació que té l’Estat, informació que moltes 

vegades és de caràcter reservat. 

En aquest sentit, una millor protecció dels drets ciutadans constitueix 

un benefici incommensurable que s’ha de reconèixer des del punt de 

vista de l’anàlisi cost-benefici.


Podem resumir els beneficis del projecte en els tòpics següents: 

• Seguretat nacional 

L’Estat, per a complir les seves funcions, ha d’emmagatzemar i pro- 

cessar informació relativa als ciutadans. La relació entre l’individu i 

l’Estat depèn de la privacitat i la integritat d’aquestes dades, que 

s’han de protegir adequadament contra tres riscos específics: 

1. Risc de filtració: les dades confidencials s’han de tractar de ma- 

nera que només hi tinguin accés les persones i institucions auto- 

ritzades. 

2. Risc d’impossibilitat d’accés: les dades s’han d’emmagatzemar de 

tal manera que l’accés per part de les persones i institucions au- 

toritzades estigui garantit durant tota la vida útil de la informació. 

3. Risc de manipulació: la modificació de les dades ha d’estar res- 

tringida a les persones i institucions autoritzades. 

Amb el programari lliure, aquests riscos s’atenuen considerablement. 

El programari lliure permet a l’usuari la inspecció completa i exhaus- 

tiva del mecanisme de processament de les dades. El fet que el pro- 

gramari lliure permeti la inspecció del programa és una mesura de 

seguretat excel·lent, ja que els mecanismes estan constantment a la 

vista de professionals capacitats, amb la qual cosa és molt més difícil 

ocultar funcions malicioses, encara que l’usuari final no es prengui 

ell mateix la molèstia de buscar-les. 

• Independència tecnològica 

Amb el programari propietari no hi ha llibertat de contractació refe- 

rent a ampliacions i correccions del sistema que utilitza; es produeix 

una dependència tecnològica en la qual el proveïdor està en condi- 

cions de dictar unilateralment termes, terminis i preus. 

Amb el programari lliure es permet a l’usuari el control, la correcció 

i la modificació del programa per a adequar-lo a les seves necessi- 

165 


ANOTACIONS


ANOTACIONS 

166 


tats. Aquesta llibertat no és només per als programadors: si bé són 

ells els que la poden capitalitzar de primera mà, els usuaris també 

se’n beneficien enormement, perquè poden contractar qualsevol 

programador (no necessàriament l’autor original) perquè hi corre- 

geixi errors o hi afegeixi funcionalitat. 

• El desenvolupament local 

En el cas del programari propietari, l’usuari està habilitat per a exe- 

cutar un programa, però no per a inspeccionar-lo ni modificar-lo: 

per tant, no en pot aprendre, es torna dependent d’una tecnologia 

que no solament no comprèn, sinó que li està expressament vedada. 

Els professionals del seu entorn, que el podrien ajudar a assolir les 

seves metes, també estan limitats: com el funcionament del progra- 

ma és secret i no es pot inspeccionar, no es pot arreglar. D’aquesta 

manera, els professionals locals veuen cada vegada més limitades 

les seves possibilitats d’oferir valor afegit, i els seus horitzons laborals 

s’estrenyen juntament amb les oportunitats d’aprendre més. Amb el 

programari lliure es neutralitzen enormement aquests desavantatges 

del programari propietari. 

• El cost del programari 

El cost del programari es redueix considerablement en ser lliure, ja 

que no hi ha necessitat d’anar sol·licitant sistemàticament les llicèn- 

cies del cas per continuar utilitzant el programa. Això passa amb el 

programari propietari. És important que l’usuari pugui mantenir el 

control d’aquests costos, que poden arribar a impedir-li l’assoliment 

dels objectius, a força de derogacions no planificades. Això demostra 

una vegada més que el programari lliure ajuda a combatre la de- 

pendència tecnològica. 

• Més fonts de treball 

El programari lliure alliberaria part de la mà d’obra que abans esta- 

va lligada com a conseqüència de la dependència tecnològica del 

programari propietari. Ara s’assignarien recursos dels usuaris (en 

aquest cas, les institucions de l’Estat) per al manteniment i el suport 

informàtic del programari lliure.

• Foment de la creativitat i iniciativa empresarial 

Costos 


El gran cost que representa el canvi de programari propietari a pro- 

gramari lliure se circumscriu al procés migratori. Si bé és cert que 

el procés migratori implica despeses per la substitució, presa de de- 

cisions per implementar els nous sistemes, mà d’obra per a imple- 

mentar el canvi, conversió de dades, reentrenament del personal i, 

eventualment, despeses en llicències i/o desenvolupament i temps; 

no és menys cert que tots aquests costos són fixos i es paguen una 

única vegada. En canvi, el programari propietari ara en funciona- 

ment també té un cost fix que es paga i no es recupera; però, a ban- 

da d’aquest cost, n’hi ha d’altres pel fet de ser programari 

propietari: actualitzacions permanents (de vegades accentuades 

per un monopoli autosostingut) i sobretot l’elevat preu que repre- 

senta per a l’Estat la pèrdua de les llibertats, que li garanteixen el 

control de la seva pròpia informació. Aquests costos són perma- 

nents, creixen al llarg del temps i, tard o d’hora, superen els costos 

fixos de fer una migració. 

De fet, són més grans els beneficis que els costos que representa el 

procés de migració. 

Fórmula legal 

Article 1. Objecte de la llei 

S’empra en totes les institucions de l’Estat l’ús exclusiu de progra- 

mes o programari lliures en els seus sistemes i equipaments d’infor- 

màtica. 

Article 2. Àmbit d’aplicació 

Els poders Executiu, Legislatiu i Judicial, els organismes autònoms i 

descentralitzats, regionals o locals, i les empreses on l’Estat tingui 

majoria accionària, faran ús de programes o programari lliures en 

els seus sistemes i equipaments d’informàtica. 

167 


ANOTACIONS


ANOTACIONS 

168 


Article 3. Autoritat d’aplicació 

L’autoritat encarregada de posar en execució aquesta llei serà la 

Presidència del Consell de Ministres. 

Article 4. Definició de programari lliure 

Als efectes d’aquesta llei s’entendrà per programa o programari 

lliure el que tingui una llicència d’ús que garanteixi a l’usuari, sense 

cost addicional, les següents facultats: 

1. Ús sense restricció del programa per a qualsevol propòsit. 

2. Accés sense restricció al codi font o d’origen respectiu. 

3. Inspecció exhaustiva dels mecanismes de funcionament del pro- 

grama. 

4. Ús dels mecanismes interns i de porcions arbitràries del programa 

per tal d’adaptar-los a les necessitats de l’usuari. 

5. Confecció i distribució lliure de còpies del programa. 

6. Modificació del programa i distribució lliure, tant de les alteraci- 

ons com del nou programa resultant, sota les mateixes condicions 

del programa original. 

Article 5. Excepcions 

En cas que no hi hagi una solució que utilitzi programari lliure i per- 

meti satisfer una necessitat determinada, les institucions de l’Estat 

podran adoptar les alternatives següents, segons aquest ordre de 

prelació: 

a) Si hi intervenen exigències de temps verificables per a atendre un 

problema tècnic i es troba disponible en el mercat programari 

propietari, l’organisme que el demani podrà gestionar davant 

de l’autoritat d’aplicació un permís d’excepció d’utilització de


programari propietari, sempre que reuneixi les característiques 

següents: 

• Se seleccionaran en primer terme els programes que compleixin 

tots els criteris enunciats en l’article 4 d’aquesta llei, excepte per 

la facultat de distribució del programa modificat. En aquest cas, 

el permís d’excepció podrà ser definitiu. 

• Si no es pot disposar de programes de la categoria precedent, 

s’hauran d’escollir els que tinguin un projecte de desenvolupa- 

ment avançat de tipus lliure. En aquest cas, el permís d’excepció 

serà transitori i caducarà automàticament quan el programari 

lliure passi a estar disponible amb la funcionalitat necessària. 

• Si no es troben productes que compleixin aquestes condicions, es 

podrà optar per programes propietaris, però el permís d’excepció 

emanat de l’autoritat d’aplicació caducarà automàticament als 

dos anys d’haver-se emès, i s’haurà de renovar després de la 

constatació que no hi ha una solució de programari lliure satisfac- 

tòria disponible en el mercat. 

b) L’autoritat d’aplicació atorgarà un permís d’excepció únicament 

si l’organisme estatal sol·licitant garanteix l’emmagatzemament 

de les dades en formats oberts, sens perjudici del pagament de 

les llicències propietàries respectives. 

Article 6. Permisos educatius 

Tota entitat educativa dependent de l’Estat està habilitada per a ges- 

tionar un permís de programari propietari per al seu ús en investiga- 

ció, després de pagar-ne els drets d’autor i les llicències del cas 

corresponents, sempre que l’objecte d’investigació estigui directa- 

ment associat a l’ús del programa en qüestió. 

Article 7. Transparència de les excepcions 

Les excepcions emanades de l’autoritat d’aplicació s’hauran de man- 

tenir i publicar a la pàgina web del portal de l’Estat. 

169 


ANOTACIONS


ANOTACIONS 

170 


La resolució que autoritza l’excepció haurà d’enumerar els requisits 

funcionals concrets que el programa haurà de satisfer. 

Article 8. Autorització excepcional 

En cas que s’autoritzi excepcionalment alguna entitat de l’Estat inclosa 

en l’article 2 d’aquesta llei a adquirir programari propietari per em- 

magatzemar o processar dades que calgui preservar, l’autoritat d’apli- 

cació haurà de publicar al portal de l’Estat un informe en què 

s’expliquin els riscos associats amb l’ús de programari d’aquestes ca- 

racterístiques per a aquesta aplicació en particular. 

Els permisos d’excepció atorgats als organismes de l’Estat relacionats 

amb la seguretat i la defensa nacional estan exempts de l’obligació 

anteriorment exposada. 

Article 9. Responsabilitats 

La màxima autoritat administrativa i autoritat tècnica i informàtica de 

cada institució de l’Estat assumeixen la responsabilitat del compli- 

ment d’aquesta llei. 

Article 10. Norma reglamentària 

El poder executiu reglamentarà en un termini de cent vuitanta dies, 

les condicions, el temps i les formes en què s’efectuarà la transició de 

la situació actual a una que satisfaci les condicions d’aquesta llei i 

orientarà, en aquest sentit, les licitacions i contractacions futures de 

programari efectuades a qualsevol títol. 

Així mateix, s’encarregarà de dirigir el procés migratori del sistema 

de programari propietari a lliure, en tots els casos que les circums- 

tàncies ho exigeixin. 

Article 11. Glossari de termes 

a) Programa o programari. Qualsevol seqüència d’instruccions usa- 

da per un dispositiu de processament digital de dades per a dur 

a terme una tasca específica o resoldre un problema determinat.


b) Execució o ús d’un programa. Acte d’utilitzar-lo sobre qualsevol 

dispositiu de processament digital de dades per fer una funció. 

c) Usuari. Aquella persona física o jurídica que fa servir el progra- 

mari. 

d) Codi font o d’origen, o programa font o d’origen. Conjunt com- 

plet d’instruccions i arxius digitals originals creats o modificats per 

qui els programa, més tots els arxius digitals de suport, com ara 

taules de dades, imatges, especificacions, documentació, i qual- 

sevol altre element que sigui necessari per a produir el programa 

executable. Com a excepció, es podran excloure d’aquest conjunt 

les eines i els programes que es distribueixin habitualment com a 

programari lliure per altres mitjans, com, entre d’altres, compila- 

dors, sistemes operatius i llibreries. 

e) Programa o programari lliure. Programa l’ús del qual garanteixi 

a l’usuari, sense cost addicional, les facultats següents: 

• Execució sense restricció del programa per a qualsevol propòsit. 

• Accés sense restricció al codi font o d’origen respectiu. 

• Inspecció exhaustiva dels mecanismes de funcionament del pro- 

grama. 

• Ús dels mecanismes interns i de qualsevol porció arbitrària del 

programa per a adaptar-lo a les necessitats de l’usuari. 

• Confecció i distribució pública de còpies del programa. 

• Modificació del programa i distribució lliure, tant de les alteraci- 

ons com del nou programa resultant, sota les mateixes condicions 

del programa original. 

f) Programari propietari (programa no lliure). Aquell que no reuneix 

tots els requisits assenyalats en el terme precedent. 

171 


ANOTACIONS


ANOTACIONS 




172 


g) Format obert. Qualsevol manera de codificar la informació digital 

que satisfaci tant els estàndards existents com les condicions se- 

güents: 

• que la documentació tècnica completa estigui disponible pública- 

ment. 

• que el codi font de, com a mínim, una implementació de referèn- 

cia completa estigui disponible públicament. 

• que no hi hagi restriccions per a la confecció de programes que 

emmagatzemen dades codificades d’aquesta manera, en trans- 

meten, en reben o hi accedeixen. 

6.4.4. Cartes de Microsoft Perú i del congressista 

Villanueva 

El 21 de març del 2002, Juan Alberto González, com a director ge- 

neral de Microsoft Perú, va enviar una carta al congressista Edgar 

Villanueva Núñez, amb motiu del seu projecte de llei sobre programari 

lliure. El 8 d’abril el congressista la hi va respondre. Aquí s’inclouen 

els textos literals i gairebé complets de totes dues cartes (se n’exclouen 

els paràgrafs no relacionats amb el projecte de llei). 

Carta de Microsoft Perú 

D’altra banda, com vam quedar en aquesta reunió, nosaltres vam as- 

sistir al Fòrum fet en el Congrés de la República el 6 de març, a pro- 

pòsit del projecte de llei que vostè lidera, on vam poder escoltar les 

diferents presentacions que avui ens porten a exposar la nostra posició 

a fi que vostè tingui un panorama més ampli de la situació real. 

El projecte estableix l’obligatorietat que qualsevol organisme públic 

hagi d’emprar exclusivament programari lliure, és a dir, de codi 

obert, la qual cosa transgredeix els principis de la igualtat davant de 

la llei, el de no-discriminació i els drets a la lliure iniciativa privada, 

llibertat d’indústria i contractació protegits a la constitució. 

El projecte, en fer obligatori l’ús de programari de codi obert, esta- 

bliria un tracte discriminatori i no competitiu en la contractació i ad-


quisició dels organismes públics i contravindria els principis de base 

de la Llei 26850, de contractacions i adquisicions de l’Estat. 

Així, en obligar l’Estat a afavorir un model de negocis que donaria su- 

port exclusivament al programari de codi obert, el projecte només es- 

taria descoratjant les companyies fabricants locals i internacionals que 

són les que veritablement fan inversions importants, creen un nom- 

bre significatiu de llocs de treball directes i indirectes, a més de con- 

tribuir al PBI; enfront d’un model de programari de codi obert que 

tendeix a tenir un impacte econòmic cada vegada més petit pel fet 

que, sobretot, crea llocs de treball en servei. 

El projecte de llei imposa l’ús de programari de codi obert sense tenir 

en compte els perills que això pot comportar des del punt de vista de 

la seguretat, la garantia i la possible violació dels drets de propietat 

intel·lectual de tercers. 

El projecte empra de manera errònia els conceptes de programari de 

codi obert, que no necessàriament implica que sigui programari lliu- 

re, o de cost zero, i arriba a conclusions equívoques sobre l’estalvi 

per a l’Estat, sense cap suport cost-benefici que en validi la posició. 

És desencertat pensar que el programari de codi obert és gratuït. In- 

vestigacions fetes per Gartner Group (important investigadora del 

mercat tecnològic reconeguda a escala mundial) han assenyalat que 

el cost d’adquisició del programari (sistema operatiu i aplicacions) es 

redueix a només el 8% del total de costos que les empreses i institu- 

cions han d’assumir com a conseqüència de l’ús racional i realment 

profitós de la tecnologia. L’altre 92% el constitueixen: costos d’im- 

plantació, capacitació, suport, manteniment, administració i inope- 

rativitat. 

Un dels arguments que sostenen el projecte de llei és la presumpta 

gratuïtat del programari de codi obert en comparació amb els costos 

del programari comercial, sense tenir en compte que hi ha modali- 

tats de llicència per volum que poden ser summament avantatjoses 

per a l’Estat, tal com s’ha aconseguit en altres països. 

Addicionalment, l’alternativa adoptada pel projecte (i) és bastant 

més cara pels alts costos que implica una migració i (ii) posa en risc 

173 


ANOTACIONS


ANOTACIONS 

174 


la compatibilitat i possibilitat d’interoperabilitat de les plataformes in- 

formàtiques dins de l’Estat, i entre l’Estat i el sector privat, atès el cen- 

tenar de versions que hi ha de programari de codi obert en el mercat. 

El programari de codi obert no ofereix majoritàriament els nivells de 

servei adequats ni la garantia de fabricants reconeguts per aconse- 

guir més productivitat per part dels usuaris, la qual cosa ha motivat 

que diverses entitats públiques hagin retrocedit en la decisió d’anar 

per una solució de programari de codi obert i es trobin, en canvi, uti- 

litzant programari comercial. 

El projecte desincentiva la creativitat de la indústria peruana de pro- 

gramari, que factura quaranta milions de dòlars per any, exporta 

quatre milions de dòlars (10è. país en el rànquing de productes d’ex- 

portació no tradicional, més que les artesanies) i és una font d’ocu- 

pació altament qualificada. Amb una llei que estimuli l’ús de 

programari de codi obert, els programadors de programari perden 

els drets de propietat intel·lectual i la principal font de retribució. 

El programari de codi obert, pel fet que es pot distribuir gratuïtament, 

tampoc no permet generar ingressos als desenvolupadors per mitjà 

de l’exportació. D’aquesta manera, es debilita l’efecte multiplicador 

de la venda de programari a altres països i, per tant, el creixement 

d’aquesta indústria quan, contràriament, les normes d’un govern 

han d’estimular la indústria local. 

Al Fòrum es va discutir sobre la importància de l’ús de programari 

de codi obert en l’educació, sense comentar el fracàs rotund 

d’aquesta iniciativa en un país com Mèxic, on precisament els funci- 

onaris de l’Estat que van fonamentar el projecte expressen que el 

programari de codi obert no va permetre oferir una experiència 

d’aprenentatge a alumnes a l’escola, no es van tenir en compte els 

nivells de capacitació en l’àmbit nacional per donar un suport ade- 

quat a la plataforma, i el programari no va disposar ni disposa dels 

nivells d’integració a la plataforma que hi ha a les escoles. 

Si el programari de codi obert satisfà tots el requeriments de les en- 

titats de l’Estat, per què cal una llei que l’adopti? No hauria de ser el 

mercat el qui decideixi lliurement quins són els productes que li do- 

nen més beneficis o valor?

Resposta del congressista Villanueva 


Abans que res, agraeixo la seva carta del 25 de març del 2002 on 

manifesta la posició oficial de Microsoft respecte al Projecte de llei 

núm. 1609, Programari lliure en l’Administració pública, que sens 

dubte es troba inspirada en el desig que el Perú aconsegueixi situar- 

se adequadament en el context tecnològic global. Animat per aquest 

mateix esperit i convençut que per mitjà de l’intercanvi d’idees clares 

i obertes hem de trobar les millors solucions, em permeto contestar 

amb aquesta carta els comentaris inclosos en la seva. 

Sense deixar de reconèixer que opinions com la seva constitueixen 

una aportació significativa, m’hauria resultat encara més valuós si, a 

més de formular objeccions d’índole general (que després analitza- 

rem amb detall), hagués afegit arguments sòlids sobre els avantatges 

que el programari propietari pot reportar a l’Estat peruà i als seus 

ciutadans en general, ja que això hauria permès un intercanvi sens 

dubte més aclaridor respecte de cada una de les nostres posicions. 

Amb l’objectiu d’ordenar el debat, assumirem que el que vostè ano- 

mena programari de codi obert és el que el projecte defineix com a 

programari lliure, ja que hi ha programari que distribueix els progra- 

mes juntament amb el codi, però que no encaixa en la definició es- 

tablerta en el projecte; i el que vostè anomena programari comercial 

és el que el projecte defineix com a propietari o no lliure, ja que hi ha 

programari lliure que es comercialitza en el mercat per un preu, com 

qualsevol altre bé o servei. 

També cal deixar clar que el propòsit del projecte a què ens referim 

no està directament relacionat amb la quantitat d’estalvi directe que 

es pugui obtenir per l’ocupació de programari lliure en les institucions 

estatals. Aquest és, en tot cas, un valor agregat marginal, però de 

cap manera el focus de l’objectiu del projecte. Els principis elemen- 

tals que animen el projecte es vinculen a les garanties bàsiques d’un 

estat democràtic de dret, com ara: 

• l’accés lliure del ciutadà a la informació pública. 

• la perennitat de les dades públiques. 

• la seguretat de l’Estat i dels ciutadans. 

175 


ANOTACIONS


ANOTACIONS 

176 


Per a garantir el lliure accés dels ciutadans a la informació pública, 

resulta indispensable que la codificació de les dades no estigui lliga- 

da a un proveïdor únic. L’ús de formats estàndard i oberts permet ga- 

rantir aquest lliure accés, i aconseguir, si fos necessari, la creació de 

programari lliure compatible. 

Per a garantir la perennitat de les dades públiques, cal que l’ús i el 

manteniment del programari no depenguin de la bona voluntat dels 

proveïdors, ni de les condicions monopòliques que imposen. Per 

aquesta raó, l’Estat necessita sistemes l’evolució dels quals es pugui 

garantir gràcies a la disponibilitat del codi font. 

Per a garantir la seguretat de l’Estat o seguretat nacional, resulta in- 

dispensable comptar amb sistemes desproveïts d’elements que per- 

metin el control a distància o la transmissió no desitjada d’informació 

a tercers. Per tant, es requereixen sistemes que tinguin un codi font 

lliurement accessible al públic per a permetre’n l’examen per part de 

l’Estat, els ciutadans, i un gran nombre d’experts independents al 

món. La nostra proposta aporta més seguretat, ja que el coneixement 

del codi font eliminarà el nombre creixent de programes amb codi 

espia. 

Així, la nostra proposta reforça la seguretat dels ciutadans, tant en la 

condició de titulars legítims de la informació tractada per l’Estat com 

en la condició de consumidors. En aquest últim cas, en permetre 

l’aparició d’una oferta extensa de programari lliure desproveït de po- 

tencial codi espia susceptible de posar en risc la vida privada i les lli- 

bertats individuals. 

En aquest sentit, el projecte de llei es limita a establir les condicions en 

què els organismes estatals adquiriran programari en el futur, és a dir, 

d’una manera compatible amb la garantia d’aquests principis bàsics. 

De la lectura del projecte quedarà clar que una vegada aprovada: 

• la llei no prohibeix la producció de programari propietari 

• la llei no prohibeix el comerç de programari propietari 

• la llei no dicta quin programari concret cal utilitzar


• la llei no dicta a quin proveïdor es compra el programari 

• la llei no limita els termes en què es pot llicenciar un producte de 

programari 

El que el projecte expressa clarament és que el programari, per ser 

acceptable per a l’Estat, no n’hi ha prou que sigui tècnicament sufi- 

cient per a dur a terme una tasca, sinó que a més les condicions de 

contractació han de satisfer un seguit de requisits en matèria de lli- 

cència, sense els quals l’Estat no pot garantir al ciutadà el processa- 

ment adequat de les seves dades, ni vetllar-ne per la integritat, 

confidencialitat i accessibilitat al llarg del temps, perquè són aspectes 

molt crítics per al seu acompliment normal. 

Estem d’acord, Sr. González, amb el fet que la tecnologia d’informa- 

ció i comunicacions té un impacte significatiu en la qualitat de vida 

dels ciutadans (sense que això vulgui dir que sempre és positiu o 

d’efecte neutre). També coincidirem segurament, que els valors bà- 

sics que he assenyalat més amunt són fonamentals en una nació de- 

mocràtica com el Perú. Sens dubte estem molt interessats a conèixer 

qualsevol manera alternativa de garantir aquests principis, que no si- 

gui la de recórrer a l’ús de programari lliure en els termes definits en 

el projecte de llei. 

Quant a les observacions que vostè formula, passarem ara a analit- 

zar-les en detall: 

En primer lloc, assenyala que: “1. El projecte estableix l’obligatorietat 

que tot organisme públic ha d’emprar exclusivament programari lliu- 

re, és a dir, de codi obert, la qual cosa transgredeix els principis de 

la igualtat davant de la llei, el de no-discriminació i els drets a la lliure 

iniciativa privada, llibertat d’indústria i contractació protegits en la 

constitució”. 

Aquesta apreciació és un error. El projecte no afecta de cap manera 

els drets que vostè enumera, només es limita a establir condicions 

per a l’ús del programari per part de les institucions estatals, sense 

immiscir-se en les transaccions del sector privat. És un principi ben 

establert que l’Estat no té l’ample espectre de llibertat contractual del 

sector privat, ja que precisament està limitat a les seves accions pel 

177 


ANOTACIONS


ANOTACIONS 

178 


deure de transparència dels actes públics; i en aquest sentit, la pre- 

servació del més bon interès comú ha de prevaler quan es legisla so- 

bre la matèria. 

El projecte protegeix la igualtat davant de la llei, ja que cap persona 

natural o jurídica no està exclosa del dret d’oferir aquests béns a l’Es- 

tat en les condicions fixades en el projecte i sense més limitacions que 

les establertes en la Llei de contractacions i adquisicions de l’Estat 

(TUO per decret suprem núm. 012-2001-PCM). 

El projecte no introdueix cap discriminació, ja que només estableix 

com han de proveir-se aquests béns (la qual cosa és una potestat es- 

tatal) i no qui els ha de proveir (la qual cosa resultaria realment dis- 

criminatòria si s’imposessin restriccions basades en origen nacional, 

raça, religió, ideologia, preferència sexual, etc.) Al contrari, el projecte 

és decididament antidiscriminatori. És així perquè en determinar sense 

cap dubte les condicions de provisió del programari, impedeix als or- 

ganismes estatals l’ús de programes que incloguin condicions discri- 

minatòries en les llicències. 

Resulta obvi per l’exposat en els dos paràgrafs anteriors, que el pro- 

jecte no atempta contra la lliure iniciativa privada, ja que la iniciativa 

privada sempre pot escollir amb quines condicions produirà el pro- 

gramari; algunes d’aquestes condicions seran acceptables per a l’Es- 

tat, i d’altres no ho seran perquè contrarien la garantia dels principis 

bàsics enumerats més amunt. Aquesta lliure iniciativa és, sens dubte, 

compatible amb la llibertat d’indústria i amb la llibertat de contrac- 

tació (en els termes delimitats en els quals l’Estat pot exercir aquesta 

última). Qualsevol subjecte privat pot produir programari en les con- 

dicions que l’Estat requereix, o se’n pot abstenir. Ningú no està forçat 

a adoptar un model de producció, però si desitja proveir de progra- 

mari l’Estat, haurà de proporcionar mecanismes que garanteixin els 

principis bàsics, i que són els manifestats en el projecte. 

Com a exemple: res en el text del projecte no impediria que la seva 

empresa oferís als organismes de l’Estat el seu paquet ofimàtic en les 

condicions definides en el projecte i fixant el preu que vostès consi- 

derin convenient. Si no ho fa, no serà per restriccions imposades per 

la llei, sinó per decisions empresarials respecte a la manera de co- 

mercialitzar els seus productes, decisions en què l’Estat no participa.


A continuació vostè assenyala que: “2. El projecte, en fer obligatori 

l’ús de programari de codi obert, establiria un tractament discrimina- 

tori i no competitiu en la contractació i l’adquisició dels organismes 

públics [...]”. 

Aquesta afirmació no és sinó una reiteració de l’anterior, i per tant es 

contesta més amunt. Però aturem-nos un moment en la seva aprecia- 

ció sobre el “tractament [...] no competitiu”. 

Certament, en definir qualsevol tipus d’adquisició, el comprador fixa 

condicions que es relacionen amb l’ús proposat del bé o servei. Sens 

dubte això exclou certs fabricants de la possibilitat de competir, però 

no els exclou a priori, sinó sobre la base d’una sèrie de principis de- 

cidits per la voluntat autònoma del comprador, mentre el procés es 

dugui a terme conforme a la llei. I en el projecte s’estableix que ningú 

no està exclòs de competir mentre garanteixi el compliment dels prin- 

cipis bàsics. 

A més, el projecte estimula la competència, ja que encoratja a gene- 

rar oferta de programari amb més bones condicions d’usabilitat, i a 

optimitzar treballs ja establerts, en un model de millora constant. 

D’altra banda, l’aspecte central de la competitivitat és l’oportunitat de 

proporcionar al consumidor opcions més bones. Ara bé, no es pot 

desconèixer que el màrqueting no té un paper neutral a l’hora de pre- 

sentar l’oferta al mercat (ja que admetre el contrari habilitaria a supo- 

sar que les inversions que les empreses fan en màrqueting no tenen 

sentit), i per tant una despesa significativa en aquest sentit pot influir en 

les decisions del comprador. Aquesta influència del màrqueting resulta 

en bona mesura mitigada pel projecte que propulsem, ja que l’elecció 

dins del marc proposat recau en el mèrit tècnic del producte i no pas 

en l’esforç de comercialització del productor; en aquest sentit, la com- 

petitivitat s’accentua, ja que el productor de programari més petit pot 

competir en igualtat amb la més poderosa de les corporacions. 

Cal recalcar que no hi ha posició més anticompetitiva que la dels 

grans productors de programari propietari, que sovint abusen de la 

seva posició dominant, perquè moltes vegades proposen com a so- 

lucions problemes plantejats pels usuaris: “actualitzi el seu progra- 

mari a la nova versió” (amb càrrec per a l’usuari, per descomptat); a 

179 


ANOTACIONS


ANOTACIONS 

180 


més, són comunes les interrupcions arbitràries d’assistència tècnica 

per a productes que, pel que diu el proveïdor, són “antics”; després, 

per a rebre algun grau d’assistència tècnica, l’usuari es veu obligat a 

migrar (amb cost no trivial, especialment perquè sol implicar canvis 

de la plataforma de maquinari) a versions noves. I com que tota la 

infraestructura està consolidada en formats de dades propietàries, 

l’usuari resta atrapat en la necessitat de continuar emprant els pro- 

ductes del mateix proveïdor, o fer l’enorme esforç de canviar a un al- 

tre entorn (també propietari, segurament). 

Vostè afegeix: “3. Així, en obligar l’Estat a afavorir un model de ne- 

gocis que donaria suport exclusivament al programari de codi obert, 

el projecte només estaria descoratjant les companyies fabricants lo- 

cals i internacionals que són les que veritablement fan inversions im- 

portants, creen un nombre significatiu de llocs de treball directes i 

indirectes, a més de contribuir al PBI; enfront d’un model de progra- 

mari de codi obert que tendeix a tenir un impacte econòmic cada ve- 

gada més petit pel fet de crear, sobretot, llocs de treball en servei”. 

No estic d’acord amb el que vostè afirma. En part pel que vostè ma- 

teix assenyala en el paràgraf 6 de la seva carta, respecte al pes relatiu 

dels serveis en el context de l’ús de programari. Aquesta contradicció 

invalidaria per si mateixa la seva actitud. El model de serveis, adoptat 

per un gran nombre de corporacions en la indústria informàtica, és 

molt més significatiu, en termes econòmics i amb tendència creixent, 

que el llicenciament de programes. 

D’altra banda, el sector privat de l’economia té una llibertat més àm- 

plia per a escollir el model econòmic que més convingui als seus in- 

teressos, encara que aquesta llibertat d’elecció quedi moltes vegades 

enfosquida de manera subliminal per les desproporcionades inversions 

en màrqueting dels productors de programari propietari. 

Addicionalment, de la lectura de la seva opinió es desprendria que 

el mercat estatal és crucial i imprescindible per a la indústria del pro- 

gramari propietari, fins al punt que l’opció que estableix l’Estat en 

aquest projecte eliminaria completament aquestes empreses del 

mercat. Si és així, deduïm que l’Estat estaria subsidiant la indústria 

del programari propietari. En el supòsit negat que això fos cert, lla- 

vors l’Estat tindria el dret a aplicar els subsidis a l’àrea que considerés


de més valor social; resultaria innegable, en aquesta improbable hi- 

pòtesi, que si l’Estat decideix subsidiar programari, ho hauria de fer 

escollint el lliure per damunt del propietari, tenint en compte l’efecte 

social i l’ús racional dels diners dels contribuents. 

Respecte dels llocs de treball generats pel programari propietari en 

països com el nostre, sobretot tracten tasques tècniques de poc valor 

afegit; en l’àmbit local, els tècnics que donen suport a programari 

propietari produït per empreses transnacionals no estan en condicions 

de solucionar un bug, no necessàriament per falta de capacitat tèc- 

nica o talent, sinó perquè no disposen del codi font que han de repa- 

rar. Amb programari lliure es crea feina tècnicament més qualificada 

i es genera un marc de lliure competència on l’èxit d’aquesta feina 

només està vinculat a la capacitat d’oferir un bon suport tècnic i qua- 

litat de servei, s’estimula el mercat i s’incrementa el patrimoni comú 

de coneixement, que obre alternatives per generar serveis de més va- 

lor agregat i un perfil de qualitat més bo que beneficia tots els actors: 

productors, prestadors de serveis i consumidors. 

És un fenomen comú als països en vies de desenvolupament que les 

indústries locals de programari obtenen la majoria dels seus ingressos 

en l’àrea de serveis, o en la construcció de programari ad hoc. Per 

tant, qualsevol impacte negatiu que l’aplicació del projecte pugui tenir 

en aquest sector es veurà compensat amb escreix per un augment de 

la demanda de serveis (a condició que es prestin d’acord amb alts es- 

tàndards de qualitat). Sens dubte, és probable que les empreses trans- 

nacionals de programari, si decideixen no competir conforme a 

aquestes regles de joc, pateixin alguna disminució d’ingressos en ter- 

mes de facturació per llicenciament; però si tenim en compte que 

aquestes empreses al·leguen sostenir que molt del programari emprat 

per l’Estat s’ha copiat il·legalment, es veurà que l’impacte no és gaire 

seriós. En realitat, en qualsevol cas, la seva fortuna estarà determinada 

per les lleis del mercat, els canvis de les quals no es poden evitar; mol- 

tes empreses tradicionalment associades amb el programari propietari 

ja han emprès un camí ferm (amb el suport d’inversions abundants) 

per prestar serveis associats amb el programari lliure, la qual cosa de- 

mostra que els models no són mútuament excloents. 

Amb aquest projecte l’Estat decideix que vol preservar certs valors fo- 

namentals. I ho decideix partint de la base de les seves potestats so- 

181 


ANOTACIONS


ANOTACIONS 

182 


biranes, sense afectar amb això cap de les garanties constitucionals. 

Si aquests valors es poden garantir sense haver d’escollir un model 

econòmic concret, els efectes de la llei serien encara més beneficio- 

sos. En tot cas, ha de quedar clar que l’Estat no escull un model eco- 

nòmic; si només hi hagués un model econòmic capaç de proveir 

programari que satisfaci les garanties bàsiques d’aquests principis, 

es tractaria d’una circumstància històrica i no d’una decisió arbitrària 

en favor d’un model concret. 

Prossegueix la seva carta: “4. El projecte de llei imposa l’ús de pro- 

gramari de codi obert sense considerar els perills que pugui compor- 

tar des del punt de vista de seguretat, garantia i possible violació dels 

drets de propietat intel·lectual de tercers”. 

Al·ludir de manera abstracta “als perills que pugui comportar”, sense 

especificar ni una sola instància d’aquests presumptes perills, deno- 

ta, si més no, un desconeixement del tema. Així, doncs, permeti’m 

il·lustrar-lo sobre aquests punts. 

Sobre seguretat: 

En termes generals, pel que fa a la seguretat nacional, ja es va es- 

mentar inicialment en els principis bàsics del projecte. En termes més 

puntuals respecte de la seguretat del programari per si mateix, és 

ben sabut que el programari (propietari o lliure) conté errors de pro- 

gramació o bugs (en l’argot informàtic) en les seves línies de codi. 

Però també és públic i notori que hi ha menys errors en el programari 

lliure i es reparen molt més ràpidament, que en el programari pro- 

pietari. No en va, nombrosos organismes públics responsables de la 

seguretat informàtica dels sistemes estatals en països desenvolupats 

prescriuen l’ús de programari lliure en iguals condicions de seguretat 

i eficiència. 

El que resulta impossible de provar és que el programari propietari 

sigui més segur que el lliure, si no es fa mitjançant l’escrutini públic i 

obert de la comunitat científica i els usuaris en general. Aquesta de- 

mostració és impossible perquè el mateix model de programari pro- 

pietari n’impedeix aquesta anàlisi, amb la qual cosa la garantia de 

seguretat es basa en la paraula ben intencionada (però sens dubte, 

parcial) del mateix productor o els seus contractistes.


Correspon recordar que, moltes vegades, les condicions de llicencia- 

ment inclouen clàusules de non-disclosure, que impedeixen que els 

usuaris revelin obertament els errors de seguretat trobats en el pro- 

ducte propietari llicenciat. 

Respecte a la garantia: 

Com vostè sap perfectament, o podrà determinar llegint l’End User 

License Agreement dels productes que llicencia, en l’amplíssima ma- 

joria dels casos, les garanties estan limitades a la reposició del mitjà 

d’emmagatzemament si fos defectuós, però en cap cas no es preve- 

uen compensacions per danys directes o indirectes, lucre cessant, etc. 

Si com a conseqüència d’un bug de seguretat en algun dels seus pro- 

ductes no oportunament reparat per vostès, un atacant comprometés 

sistemes crucials per a l’Estat: quines garanties, reparacions i com- 

pensacions proporcionaria la seva empresa d’acord amb les condi- 

cions de llicenciament? Les garanties del programari propietari, 

mentre que els programes es lliuren “AS IS”, és a dir, en l’estat en 

què es troben, sense cap responsabilitat addicional per al proveïdor 

respecte a la seva funcionalitat, no difereixen de cap manera de les 

habituals en el programari lliure. 

Sobre la propietat intel·lectual: 

Les qüestions de propietat intel·lectual són fora de l’àmbit d’aquest 

projecte, ja que es troben emparades per altres lleis específiques. El 

model de programari lliure no implica de cap manera desconèixer 

aquestes lleis i, de fet, l’amplíssima majoria del programari lliure 

està emparat pel copyright. En realitat, la sola inclusió d’aquesta 

qüestió en les seves observacions demostra la confusió que té respec- 

te del marc legal en què es mou el programari lliure. La incorporació 

de propietat intel·lectual aliena en obres que després s’atribueixen 

com a pròpies no és una pràctica de la qual es tingui registre en la 

comunitat del programari lliure; sí que ho és, lamentablement, en el 

terreny del programari propietari. Valgui a títol d’exemple la con- 

demna de la Cort Comercial de Nanterre, França, del passat 27 de 

setembre del 2001 a Microsoft Corp., per tres milions de francs en 

concepte de danys i interessos, per violació de la propietat intel·lec- 

tual (pirateria, segons el desafortunat terme que la seva empresa sol 

usar en la publicitat). 

183 


ANOTACIONS


ANOTACIONS 

184 


Prossegueix dient que: “5. El projecte empra de manera errònia els 

conceptes de programari de codi obert, que no necessàriament im- 

plica que sigui programari lliure, o de cost zero, i arriba a conclusi- 

ons equívoques sobre l’estalvi per a l’Estat, sense cap suport cost- 

benefici que en validi la posició”. 

Aquesta observació no és així; en principi la gratuïtat i la llibertat són 

conceptes ortogonals: hi ha programari propietari i onerós (per 

exemple, MS Office), programari propietari i gratuït (MS Internet 

Explorer), programari lliure i onerós (distribucions Red Hat, SuSE, 

etc., del sistema GNU/Linux), programari lliure i gratuït (Apache, 

OpenOffice, Mozilla), i fins i tot programari que es llicencia sota di- 

ferents modalitats (MySQL). 

És evident que el programari lliure no és necessàriament gratuït. I 

tampoc no es desprèn del text del projecte que ho hagi de ser, com 

bé haurà notat després de llegir la norma proposada. Les definicions 

incloses en el projecte determinen clarament què s’ha de considerar 

programari lliure; en cap moment no es refereixen a la gratuïtat. Si 

bé s’esmenten les possibilitats d’estalvi en termes del que es paga per 

llicències de programari propietari, els fonaments del projecte fan 

menció clara a les garanties fonamentals que es pretén preservar i a 

l’estímul del desenvolupament tecnològic local. Atès que un estat de- 

mocràtic ha de mantenir aquests principis, no li queda cap altra so- 

lució que emprar programari, el codi font del qual està públicament 

disponible, i intercanviar informació només en formats estàndards. 

Si l’Estat no emprés programari amb aquestes característiques, vulne- 

raria principis republicans bàsics. Per sort, a més, el programari lliure 

implica menys costos totals; però fins i tot en la hipòtesi (fàcilment ne- 

gada) que costés més que el propietari, la sola existència d’una eina 

de programari lliure eficaç per a una funció informàtica determinada 

obligaria l’Estat a utilitzar-la; no pas per imposició d’aquest projecte 

de llei, sinó pels principis elementals que enumerem al començament 

i que sorgeixen de l’essència mateixa de l’estat democràtic de dret. 

Vostè segueix: “6. És equivocat pensar que el programari de codi 

obert és gratuït. Investigacions fetes per Gartner Group (important in- 

vestigadora del mercat tecnològic reconeguda a escala mundial) han 

assenyalat que el cost d’adquisició del programari (sistema operatiu


i aplicacions) es redueix a només el 8% del total de costos que les em- 

preses i institucions han d’assumir com a conseqüència de l’ús racio- 

nal i realment profitós de la tecnologia. L’altre 92% el constitueixen: 

costos d’implantació, capacitació, suport, manteniment, administra- 

ció i inoperativitat”. 

Aquest argument repeteix el ja assenyalat en el paràgraf 5 i en part es 

contradiu amb el paràgraf 3. Per tant, ens remetrem al que s’hi diu en 

homenatge a la brevetat. Això no obstant, permeti’m assenyalar-li que 

incorre en una conclusió falsa en el pla lògic: que el cost de progra- 

mari segons Gartner Group només és el 8% de la mitjana del cost total 

d’utilització, no invalida de cap manera l’existència de programari 

gratuït, és a dir, aquell que té un cost zero de llicenciament. 

A més, en aquest paràgraf vostè indica encertadament que els com- 

ponents de servei i les pèrdues per indisponibilitat conformen la part 

substancial del cost total d’utilització de programari; cosa que, com 

pot veure, entra en contradicció amb la seva afirmació del valor mí- 

nim dels serveis suggerit en el paràgraf 3. Ara bé, l’ús de programari 

lliure contribueix significativament a disminuir els restants costos del 

cicle de vida. Aquesta reducció de l’impacte econòmic de desplega- 

ment, suport, etc., es registra en diversos camps; d’una banda, el 

model competitiu de serveis del programari lliure, el suport i el man- 

teniment del qual és possible contractar lliurement entre una oferta 

variada que competeix en funció de la qualitat i el menor cost. Això 

és vàlid per a la implantació, la capacitació i el suport i, en bona me- 

sura, per al manteniment. En segon lloc, per la característica repro- 

ductiva del model, fa que el manteniment que s’ha fet en una 

aplicació sigui replicable molt fàcilment, sense incórrer en més costos 

(és a dir, sense pagar més d’un cop pel mateix) ja que les modifica- 

cions, si així es vol, queden incorporades al patrimoni comú del co- 

neixement. En tercer lloc, perquè l’enorme cost causat per la 

inoperativitat (“pantalles blaves de la mort”, codi maliciós com ara 

virus, worms i troians, excepcions, falles generals de protecció i altres 

tants mals coneguts) es redueix significativament a emprar progra- 

mari més estable; i és ben conegut que una de les virtuts més desta- 

cables del programari lliure és l’estabilitat. 

Afirma després que: “7. Un dels arguments que sostenen el projecte de 

llei és la presumpta gratuïtat del programari de codi obert en compara- 

185 


ANOTACIONS


ANOTACIONS 

186 


ció amb els costos del programari comercial, sense tenir en compte que 

hi ha modalitats de llicenciament per volum que poden ser summament 

avantatjoses per a l’Estat, tal com s’ha aconseguit en altres països”. 

Ja he puntualitzat que el que es qüestiona no és el cost del programa- 

ri, sinó els principis de llibertat d’informació, accessibilitat i seguretat. 

Aquests arguments s’han tractat de manera extensa en paràgrafs an- 

teriors, per la qual cosa l’hi remeto. 

D’altra banda, en realitat, hi ha modalitats de llicenciament per vo- 

lum (encara que, per desgràcia, el programari propietari no en sa- 

tisfà els principis bàsics). Però com vostè acaba d’assenyalar 

encertadament en el paràgraf immediatament anterior de la seva 

carta, només apunten a reduir l’impacte d’un component que impor- 

ta no més del 8% del cost total. 

Prossegueix: “8. Addicionalment, l’alternativa adoptada pel projecte 

(i) és bastant més cara pels alts costos que implica una migració i (ii) 

posa en risc la compatibilitat i possibilitat d’interoperabilitat de les 

plataformes informàtiques dins de l’Estat, i entre l’Estat i el sector pri- 

vat, atès el centenar de versions que hi ha de programari de codi 

obert en el mercat”. 

Analitzem la seva afirmació en dues parts. El seu primer argument, 

que la migració implica costos alts, és en realitat un argument a favor 

del projecte. Perquè com més temps duri la migració a una altra tec- 

nologia més cara serà; i alhora s’incrementaran els riscos de segu- 

retat associats amb el programari propietari. D’aquesta manera, l’ús 

de sistemes i formats propietaris torna l’Estat cada vegada més de- 

pendent de proveïdors determinats. Per contra, una vegada implan- 

tada la política d’ús de programari lliure (implantació que, és cert, 

implica un cost), la migració d’un sistema a un altre es fa molt sen- 

zilla, ja que totes les dades estan emmagatzemades en formats 

oberts. D’altra banda, la migració a un entorn de programari obert 

no implica més costos que entre entorns diferents de programari pro- 

pietari, amb la qual cosa el seu argument s’invalida totalment. 

El segon argument es refereix a “dificultats d’interoperabilitat de les 

plataformes informàtiques dins de l’Estat, i entre l’Estat i el sector pri- 

vat”. Aquesta afirmació implica un cert desconeixement dels meca-


nismes de construcció de programari lliure, en el qual no es 

maximitza la dependència de l’usuari respecte d’una plataforma de- 

terminada, com succeeix habitualment en el camp del programari 

propietari. Encara que hi ha múltiples distribucions de programari lliure 

i nombrosos programes susceptibles de ser emprats per a una mateixa 

funció, la interoperabilitat queda garantida tant per l’ús de formats es- 

tàndard, exigida en el projecte, com per la possibilitat de construir pro- 

gramari interoperable a partir de la disponibilitat del codi font. 

Diu després que: “9. El programari de codi obert majoritàriament no 

ofereix els nivells de servei adequats ni la garantia de fabricants re- 

coneguts per aconseguir més productivitat per part dels usuaris, cosa 

que ha motivat que diferents entitats públiques hagin retrocedit en la 

decisió d’anar per una solució de programari de codi obert i es trobin 

utilitzant programari comercial en el seu lloc”. 

Aquesta observació és infundada. Respecte de la garantia, el seu ar- 

gument ha estat rebatut responent el paràgraf 4. Respecte dels ser- 

veis de suport, és possible utilitzar programari lliure sense aquests 

(com també passa amb el programari propietari), però els qui els re- 

quereixin poden adquirir suport independent, tant d’empreses locals 

com de corporacions internacionals, també en el cas de programari 

propietari. 

D’altra banda, contribuiria molt a la nostra anàlisi que ens informés 

sobre projectes de programari lliure implantats en entitats públiques 

que fins ara hagin estat abandonats en favor del programari propie- 

tari. Coneixem un bon nombre de casos en el sentit invers, però no 

tenim informació de casos en el sentit que vostè exposa. 

Continua observant que: “El projecte desincentiva la creativitat de la 

indústria peruana de programari, que factura quaranta milions de 

dòlars per any, exporta quatre milions de dòlars (desè país en el ràn- 

quing de productes d’exportació no tradicional, més que les artesa- 

nies) i és una font d’ocupació altament qualificada. Amb una llei que 

incentivi l’ús de programari de codi obert, els programadors de pro- 

gramari perden els drets de propietat intel·lectual i la principal font 

de retribució”. 

187 


ANOTACIONS


ANOTACIONS 

188 


És clar fora d’això que ningú no està obligat a comercialitzar el seu 

codi com a programari lliure. Tan sols haurà de tenir en compte que, 

si no ho fa, no podrà vendre al sector públic. Aquest, d’altra banda, 

no constitueix el principal mercat per a la indústria nacional de pro- 

gramari. Unes quantes línies més amunt hem abordat algunes qües- 

tions referides a la influència del projecte en la generació d’ocupació 

tècnica altament qualificada i en més bones condicions de competi- 

tivitat, per la qual cosa sembla innecessari insistir en aquest punt. 

El que segueix en la seva afirmació és erroni. D’una banda, cap autor 

de programari lliure no perd els drets de propietat intel·lectual, llevat 

que per la seva voluntat expressa desitgi col·locar la seva obra en el 

domini públic. El moviment del programari lliure sempre ha estat ex- 

tremadament respectuós amb la propietat intel·lectual, i ha generat re- 

coneixement públic extens als autors. Noms com el de Richard 

Stallman, Linus Torvalds, Guido van Rossum, Larry Wall, Miguel de 

Icaza, Andrew Tridgell, Theo de Raadt, Andrea Arcangeli, Bruce Perens, 

Darren Reed, Alan Cox, Eric Raymond, i molts altres, són reconeguts 

mundialment per les seves contribucions al desenvolupament de pro- 

gramari que avui utilitzen milions de persones a tot el món, mentre 

que els noms dels autors materials d’excel·lents peces de programari 

propietari continuen en l’anonimat. D’altra banda, afirmar que les re- 

galies pels drets d’autor són la principal font de retribució dels progra- 

madors peruans és en tot cas arriscat, en particular perquè no s’ha 

aportat cap prova a aquest efecte ni una demostració de com l’ús de 

programari lliure per l’Estat influiria en aquestes retribucions. 

Vostè continua dient que: “11. El programari de codi obert, pel fet que 

es pot distribuir gratuïtament, tampoc no permet generar ingressos als 

desenvolupadors per mitjà de l’exportació. D’aquesta manera, es de- 

bilita l’efecte multiplicador de la venda de programari a altres països 

i, per tant, el creixement d’aquesta indústria quan, contràriament, les 

normes d’un govern han d’estimular la indústria local.” 

Aquesta afirmació demostra novament un desconeixement total dels 

mecanismes i el mercat del programari lliure. Intenta asseverar que 

el mercat de cessió de drets no exclusius d’ús a títol onerós (venda de 

llicències) és l’únic possible per a la indústria informàtica quan, com 

vostè mateix ha assenyalat més amunt, ni tan sols no és el més im- 

portant. L’incentiu que el projecte presenta a l’aparició d’una oferta


de professionals més qualificats, en conjunt amb l’increment d’expe- 

riència que resultarà per als tècnics nacionals treballar a gran escala 

amb programari lliure a l’Estat, els col·loquen en una posició alta- 

ment competitiva per a oferir els seus serveis a l’estranger. 

Assenyala després que: “12. Al Fòrum es va discutir sobre la importàn- 

cia de l’ús de programari de codi obert en l’educació, sense comentar 

el fracàs rotund d’aquesta iniciativa en un país com Mèxic, on precisa- 

ment els funcionaris de l’Estat que van fonamentar el projecte avui ex- 

pressen que el programari de codi obert no va permetre oferir una 

experiència d’aprenentatge a alumnes a l’escola, no es van tenir en 

compte els nivells de capacitació en l’àmbit nacional per donar un su- 

port adequat a la plataforma, i el programari no va disposar ni dispo- 

sa dels nivells d’integració a la plataforma que hi ha a les escoles”. 

Efectivament, a Mèxic es va fer marxa enrere amb el projecte Red Es- 

colar. Això es va deure, precisament, al fet que els impulsors del pro- 

jecte mexicà van tenir el cost de les llicències com a principal 

argument, en comptes de les altres raons estipulades en el nostre 

projecte i que són molt més essencials. Per culpa d’aquest error con- 

ceptual, i com a conseqüència de la falta de suport efectiu per part 

de la SEP (Secretaria d’Educació Pública), es va assumir que per a im- 

plementar programari lliure a les escoles, n’hi havia prou de treure’ls 

el pressupost per a programari i, en canvi, enviar-los un CD-ROM 

amb GNU/Linux. Certament, això va fallar i no podia ser de cap altra 

manera, tal com fallen els laboratoris escolars en què s’usa programa- 

ri propietari si no hi ha pressupost per a la implementació i el man- 

teniment. És precisament per això que el nostre projecte de llei no es 

limita a indicar l’obligatorietat de l’ús de programari lliure, sinó que 

reconeix la necessitat i ordena la creació d’un pla de migració viable, 

en què l’Estat encamini ordenadament la transició tècnica per acon- 

seguir gaudir dels avantatges del programari lliure. 

Acaba amb una pregunta retòrica: “13. Si el programari de codi obert 

satisfà tots el requeriments de les entitats de l’Estat, per què cal una llei 

per a adoptar-lo? No hauria de ser el mercat el qui decideixi lliurement 

quins són els productes que li donen més beneficis o valor?”. 

Estem d’acord que en el sector privat de l’economia és el mercat qui 

ha de decidir quins productes s’utilitzen i no s’hi admetria cap intro- 

189 


ANOTACIONS


ANOTACIONS 

190 


missió estatal. Però en el cas del sector públic, el raonament no és el 

mateix: com ja hem establert, l’Estat emmagatzema, manipula i 

transforma informació que no li pertany, sinó que li ha estat confiada 

pels ciutadans que, per imperatiu de la llei, no els en queda més re- 

mei. Com a contrapartida a aquesta imposició legal, l’Estat ha d’ex- 

tremar les mesures per salvaguardar la integritat, la confidencialitat 

i l’accessibilitat d’aquestes informacions. L’ús de programari propie- 

tari planteja dubtes seriosos sobre el compliment d’aquests atributs, 

sense una evidència concloent que ho corrobori i, per tant, no és apte 

perquè l’utilitzi el sector públic. 

La necessitat d’una llei rau, d’una banda, en la materialització dels 

principis fonamentals abans enunciats en el camp específic del pro- 

gramari. De l’altra, en el fet que l’Estat no és una entitat ideal homo- 

gènia, sinó que està compost de múltiples organismes amb diversos 

graus d’autonomia de decisions. Com que el programari propietari 

no és adequat per a utilitzar-lo, el fet d’establir aquestes regles en la 

llei impedirà que la decisió discrecional de qualsevol funcionari posi 

en risc la informació que pertany als ciutadans. I, sobretot, perquè 

constitueix una reafirmació actualitzada en relació amb els mitjans 

de tractament i comunicació d’informació emprats avui dia sobre el 

principi republicà de publicitat. 

Segons aquest principi universalment acceptat, el ciutadà té dret a 

conèixer tota la informació en poder de l’Estat que no estigui empa- 

rada en una declaració fundada de secret conforme a la llei. Ara bé, 

el programari tracta informació i és en si mateix informació. Informa- 

ció en format especial, susceptible de ser interpretat per una màqui- 

na per a executar accions, però sens dubte informació crucial perquè 

el ciutadà té el dret legítim a saber, per exemple, com es computa el 

vot o es calculen els impostos. I per a això, ha de poder accedir lliu- 

rement al codi font i provar tant com vulgui els programes que s’uti- 

litzen per al còmput electoral o per al càlcul dels impostos. 

6.4.5. Decret de mesures d’impuls de la societat 

del coneixement a Andalusia 

Articulat relacionat amb el programari lliure del decret de mesures 

d’impuls de la societat del coneixement a Andalusia.


• Article 11. Materials educatius en suport informàtic 

1. Es dotarà els centres docents públics de materials i programes 

educatius en suport informàtic, basats preferentment en progra- 

mari lliure. En tot cas, rebran en aquest suport tot el material edu- 

catiu que elabori l’Administració de la Junta d’Andalusia. 

2. També s’incentivarà entre el professorat la producció de pro- 

grames i materials curriculars en suport informàtic o per a l’ús 

a Internet, especialment aquells desenvolupaments que es facin 

mitjançant programari lliure. 

• Article 31. Programari lliure 

1. En les adquisicions d’equipament informàtic destinat als centres do- 

cents públics per al seu ús en activitats educatives, s’exigirà que tot 

el maquinari sigui compatible amb sistemes operatius basats en 

programari lliure. Els ordinadors tindran preinstal·lat tot el progra- 

mari lliure necessari per a l’ús específic al qual estiguin destinats. 

2. L’equipament informàtic que l’Administració de la Junta d’Anda- 

lusia posi a disposició en els centres d’accés públic a Internet uti- 

litzarà productes de programari lliure per al seu funcionament. 

3. L’Administració de la Junta d’Andalusia fomentarà la difusió i utilit- 

zació orientades a l’ús personal, domèstic i educatiu del programari 

lliure. Per a aquesta finalitat s’establirà un servei d’assessorament per 

Internet per a la instal·lació i l’ús d’aquest tipus de productes. 

• Article 49. Objecte 

1. S’establiran ajuts per al desenvolupament de projectes innova- 

dors que facilitin la integració de les tecnologies de la informació 

i les comunicacions en la formació professional ocupacional. 

2. Aquests projectes es referiran a alguna de les modalitats següents: 

a) Elaboració de materials i continguts de formació professional 

ocupacional per a l’ús i difusió per Internet, especialment aquells 

desenvolupaments que es facin amb programari lliure. 

b) Realització d’accions formatives mitjançant metodologies in- 

novadores de tipus semipresencial i a distància. 

191 


ANOTACIONS

7. Enginyeria del programari lliure 


En els capítols anteriors hem vist per què el desafiament del progra- 

mari lliure no és el d’un nou competidor que, sota les mateixes re- 

gles, genera programari de manera més ràpida, barata i de més 

qualitat: el programari lliure es diferencia del programari “tradicio- 

nal” en aspectes més fonamentals, que comencen per raons i moti- 

vacions filosòfiques, que continuen per noves pautes econòmiques i 

de mercat, i que acaben amb una manera diferent de generar pro- 

gramari. L’enginyeria del programari no pot ser aliena a aquest es- 

deveniment i des de fa poc més d’un lustre s’ha anat aprofundint en 

la investigació de tots aquests aspectes. Aquest capítol pretén mostrar 

els estudis més significatius i les evidències que aporten amb l’objectiu 

d’oferir al lector una visió de l’estat de l’art i de les perspectives de futur 

en allò que hem acabat per anomenar enginyeria del programari lliure. 

7.1. Introducció 

Encara que fa ja unes quantes dècades que es desenvolupa progra- 

mari lliure, només des de fa uns quants anys s’ha començat a parar 

atenció als seus models i processos de desenvolupament des del punt 

de vista de l’enginyeria del programari. Igual que no hi ha un únic 

model de desenvolupament de programari propietari, tampoc no 

n’hi ha en el món del programari lliure, però tot i així es poden trobar 

característiques interessants que comparteixen gran part dels projec- 

tes estudiats i que podrien estar arrelades en les propietats dels pro- 

grames lliures. 

El 1997, Eric S. Raymond va publicar el primer article àmpliament di- 

fós, “La catedral i el basar”, en el qual es tractava de descriure algu- 

nes característiques dels models de desenvolupament de programari 

lliure i es posava un èmfasi especial en allò que diferencia aquests 

models dels de desenvolupament propietari. Aquest article s’ha con- 

vertit des de llavors en un dels més coneguts (i criticats) del món del 

193 


ANOTACIONS


ANOTACIONS 

194 


programari lliure, i fins a cert punt, en el senyal d’inici del desenvo- 

lupament de l’enginyeria del programari lliure. 

7.2. “La catedral i el basar” 

Raymond estableix una analogia entre la manera de construir les ca- 

tedrals medievals i la manera clàssica de produir programari. Argu- 

menta que en tots dos casos hi ha una clara distribució de tasques i 

rols, i en destaca que hi ha un dissenyador que està per damunt de 

tot i que ha de controlar en tot moment el desenvolupament de l’ac- 

tivitat. Així, la planificació està estrictament controlada i dóna lloc a 

uns processos clarament detallats en què, idealment, cada partici- 

pant en l’activitat té un rol específic molt delimitat. 

Dins del que Raymond anomena model de creació de catedrals no 

solament hi caben els processos pesats que podem trobar en la in- 

dústria del programari (el model en cascada clàssic, els diferents ves- 

sants del Rational Unified Process, etc.), sinó que també hi entren 

projectes de programari lliure, com és el cas de GNU i NetBSD. Per 

a Raymond, aquests projectes es troben fortament centralitzats, ja 

que només unes quantes persones fan el disseny i la implementació 

del programari. Les tasques i els rols que aquestes persones exercei- 

xen estan perfectament definits, i si algú volgués entrar a formar part 

de l’equip de desenvolupament caldria assignar-li una tasca i un rol 

segons les necessitats del projecte. D’altra banda, els lliuraments 

d’aquest tipus de programes es troben espaiats en el temps seguint 

una planificació bastant estricta. Això implica tenir pocs lliuraments 

del programari i cicles llargs entre els lliuraments i que consten de 

diverses etapes. 

El model antagònic al de la catedral és el basar. Segons Raymond, al- 

guns dels programes de programari lliure, en especial el nucli Linux, 

s’han desenvolupat seguint un esquema similar al d’un basar oriental. 

En un basar no hi ha una màxima autoritat que controli els processos 

que s’hi desenvolupen ni que planifiqui estrictament el que ha de passar. 

D’altra banda, els rols dels participants poden canviar de manera 

continuada (els venedors poden passar a ser clients) i sense indicació 

externa.


Però el més nou de “La catedral i el basar” és la descripció del procés 

que ha convertit Linux en un èxit dins del món del programari lliure; 

és una successió de “bones maneres” per a aprofitar al màxim les 

possibilitats que ofereix la disponibilitat de codi font i la interactivitat 

mitjançant l’ús de sistemes i eines telemàtiques. 

Un projecte de programari lliure sol sorgir arran d’una acció pura- 

ment personal; la causa s’ha de buscar en un desenvolupador que 

tingui limitada la capacitat de resoldre un problema. El desenvolupa- 

dor ha de tenir els coneixements necessaris per, almenys, començar- 

lo a resoldre. Un cop hagi aconseguit tenir alguna cosa usable, amb 

una mica de funcionalitat, senzilla i, si és possible, ben dissenyada o 

escrita, el millor que pot fer és compartir aquesta solució amb la co- 

munitat del programari lliure. És el que s’anomena publicació prime- 

renca (release early, en anglès) i que permet cridar l’atenció d’altres 

persones (generalment desenvolupadors) que tinguin el mateix pro- 

blema i hi puguin estar interessats. 

Un dels principis bàsics d’aquest model de desenvolupament és 

considerar els usuaris com a codesenvolupadors. Cal tractar-los 

amb una mica de cura, no solament perquè poden proporcionar 

publicitat per mitjà del boca a boca, sinó també perquè duran a ter- 

me una de les tasques més cares que hi ha en la generació de pro- 

gramari: les proves. Al contrari que el codesenvolupament, que és 

difícilment escalable, la depuració i les proves tenen la propietat de 

ser molt paral·lelitzables. L’usuari serà qui prengui el programari i 

el provi a la seva màquina amb unes condicions específiques (una 

arquitectura, unes eines, etc.), una tasca que, multiplicada per un 

gran nombre d’arquitectures i entorns, representaria un gran esforç 

per a l’equip de desenvolupament. 

Si es tracta els usuaris com a desenvolupadors, es pot donar el cas 

que algú hi trobi un error, el solucioni i enviï el codi millorat (pedàs o 

patch) al desenvolupador del projecte perquè el problema estigui so- 

lucionat en la versió següent. També pot passar, per exemple, que la 

persona que finalment entengui i corregeixi l’error sigui una persona 

diferent de qui el descobreix. Totes aquestes circumstàncies són molt 

profitoses per al desenvolupament del programari, per la qual cosa 

és molt beneficiós entrar en una dinàmica d’aquesta índole. 

195 


ANOTACIONS


ANOTACIONS 


[Vegeu bibliografia, apartat 

156] 



apartat 91] 

196 


Aquesta situació és més efectiva amb lliuraments freqüents, ja que la 

motivació per trobar, notificar i corregir errors és alta perquè se su- 

posa que s’atendran immediatament. A més a més, s’aconsegueixen 

avantatges secundaris, com el fet que en integrar-lo sovint –ideal- 

ment una o més vegades al dia– no faci falta una última fase d’inte- 

gració dels mòduls que componen el programa. Això s’ha anomenat 

publicació freqüent (en la terminologia anglosaxona es coneix com a 

release often) i possibilita una gran modularitat alhora que maximit- 

za l’efecte propagandístic que té el fet de publicar una versió nova 

del programari. 

Per a evitar que la publicació freqüent espanti usuaris que prioritzin 

l’estabilitat sobre la rapidesa amb què el programari evoluciona, al- 

guns projectes de programari lliure compten amb diverses branques 

de desenvolupament en paral·lel. El cas més conegut és el del nucli 

Linux, que té una branca estable –dirigida als qui els agrada la fia- 

bilitat– i una altra d’inestable –pensada per a desenvolupadors– amb 

les últimes innovacions i novetats. 

Nota 

La gestió de noves versions depèn lògicament de la 

mida del projecte, ja que la problemàtica a què cal 

enfrontar-se no és igual quan l’equip de desenvolupa- 

ment té dos components que quan en són centenars. 

Mentre que en els projectes petits en general aquest 

procés és més aviat informal, la gestió de lliuraments 

en els projectes grans sol seguir un procés definit no 

exempt de certa complexitat. Hi ha un article titulat 

Release Management Within Open Source Projects 

que descriu detalladament la seqüència que se se- 

gueix al servidor web Apache, el nucli del sistema 

operatiu Linux i el sistema de versions Subversion. 

7.3. Lideratge i presa de decisions al basar 

Raymond suposa que tot projecte de programari lliure ha de comptar 

amb un “dictador benevolent”, una espècie de líder –que general- 

ment coincideix amb el fundador del projecte– que ha de guiar el


projecte i que es reserva sempre l’última paraula en la presa de de- 

cisions. Les habilitats amb què ha de comptar aquesta persona són, 

sobretot, saber motivar i coordinar un projecte, entendre els usuaris 

i codesenvolupadors, buscar consensos i integrar-hi a tot aquell qui 

pugui aportar-hi alguna cosa. Com es pot observar, entre els requi- 

sits més importants no s’ha esmentat ser tècnicament competent, en- 

cara que mai no farà mal. 

Amb el creixement en mida i nombre de desenvolupadors d’alguns 

projectes de programari lliure, han aparegut noves maneres d’orga- 

nitzar la presa de decisions. Linux, per exemple, té una estructura je- 

ràrquica basada en la delegació de responsabilitats per part de Linus 

Torvalds, el “dictador benevolent”. D’aquesta manera, veiem que hi 

ha informes de Linux que tenen els seus propis dictadors benevolents, 

encara que vegin limitat el seu poder pel fet que Linus Torvalds sigui 

qui decideixi en darrer terme. Aquest cas és un exemple clar de com 

l’alta modularitat existent en un projecte de programari lliure ha pro- 

piciat una forma d’organització i presa de decisions específica. 

Nota 

Hi ha veus que diuen que la manera d’organitzar-se 

dins dels projectes de programari lliure s’assembla a la 

de l’equip quirúrgic proposada per Harlan Mills (d’IBM) 

a la primeria dels setanta i popularitzada per Brooks en 

el seu mític llibre The mythical man-month. Encara que 

es poden donar casos en què l’equip de desenvolupa- 

ment d’alguna aplicació de programari lliure estigui 

format per un dissenyador desenvolupador principal (el 

cirurgià) i molts codesenvolupadors que fan tasques au- 

xiliars (administració de sistemes, manteniment, tas- 

ques especialitzades, documentació, etc.), en cap cas 

no hi ha una separació tan estricta i definida com pro- 

posa Mills/Brooks. En qualsevol cas, com bé apunta 

Brooks en el cas de l’equip quirúrgic, en el programari 

lliure el nombre de desenvolupadors que s’han de co- 

municar per a crear un sistema gran i complex és més 

reduït que el nombre total de desenvolupadors. 

En el cas de la Fundació Apache ens trobem amb una “meritocrà- 

cia”, ja que té un comitè de directors format per persones que han 

197 




apartat 130] 

ANOTACIONS


ANOTACIONS 



apartat 69] 

198 


contribuït de manera notable al projecte. En realitat, no es tracta 

d’una meritocràcia rigorosa en la qual els que més contribueixen són 

els que governen, ja que el comitè de directors és elegit democràti- 

cament i periòdicament pels membres de la Fundació Apache (que 

s’encarrega de gestionar diversos projectes de programari lliure, en- 

tre els quals Apache, Jakarta, etc.). Per a arribar a ser membre de la 

Fundació Apache, s’han d’haver fet aportacions de manera continu- 

ada i important a un o més projectes de la fundació. Aquest sistema 

també s’utilitza en altres projectes grans, com és el cas de FreeBSD 

o GNOME. 

Un altre cas interessant d’organització formal és el GCC Steering 

Commitee. Va ser creat el 1998 per a evitar que ningú no aconseguís 

el control del projecte GCC (GNU Compiler Collection, el sistema de 

compilació de GNU), i ratificat per l’FSF (promotora del projecte 

GNU) pocs mesos després. En cert sentit, és un comitè continuador 

de la tradició d’un de similar que hi havia en el projecte EGCS (que 

durant un temps va ser paral·lel al projecte GCC, però que més tard 

s’hi va unir). La seva missió fonamental és assegurar-se que el pro- 

jecte GCC respecta la declaració d’objectius (mission statement) del 

projecte. Els membres del comitè ho són a títol personal, i són elegits 

pel projecte de manera que representin amb una certa fidelitat les di- 

ferents comunitats que col·laboren en el desenvolupament de GCC 

(desenvolupadors de suport per a diversos llenguatges, desenvolu- 

padors relacionats amb el nucli, grups interessats en programació 

encastada, etc.). 

El lideratge d’un projecte de programari lliure per part d’una ma- 

teixa persona no té per què ser etern. Hi pot haver bàsicament dues 

circumstàncies per les quals un líder de projecte deixi de ser-ho. La 

primera és la falta d’interès, temps o motivació per a continuar en- 

davant. En aquest cas, s’ha de passar el testimoni a un altre desen- 

volupador que prengui el rol de líder del projecte. Estudis recents 

demostren que en general els projectes solen tenir un lideratge que 

canvia de mans amb freqüència, i es poden observar diverses ge- 

neracions de desenvolupadors en el temps. El segon cas és més 

problemàtic: es tracta d’una bifurcació. Les llicències de programa- 

ri lliure permeten que qualsevol persona prengui el codi, el modifi- 

qui i el redistribueixi sense que calgui el vistiplau del líder del 

projecte. Això no se sol donar, en general, llevat dels casos en què 

es pretengui apartar deliberadament el líder del projecte (i un pos-


sible veto d’aquest a l’aportació). Estem certament davant d’una 

mena de “cop d’Estat”, d’altra banda totalment lícit i legítim. És per 

això que un dels objectius que busca un líder de projecte en man- 

tenir satisfets els seus codesenvolupadors és minimitzar la possibi- 

litat que hi hagi una bifurcació. 

7.4. Processos en el programari lliure 

Encara que el programari lliure no està necessàriament associat a un 

procés específic de desenvolupament de programari, hi ha un ampli 

consens sobre els processos més comuns que s’utilitzen. Això no vol 

dir que no hi hagi projectes de programari lliure que hagin estat creats 

utilitzant processos clàssics com el model en cascada. Generalment, 

el model de desenvolupament en projectes de programari lliure sol 

ser més informal, pel fet que gran part de l’equip de desenvolupa- 

ment fa aquestes tasques de manera voluntària i sense recompensa 

econòmica, almenys directa, a canvi. 

La manera com es capturen requisits en el món del programari lliure 

depèn tant de “l’edat” com de la mida del projecte. En les primeres 

etapes, el fundador del projecte i l’usuari solen coincidir en una ma- 

teixa persona. Més endavant, i si el projecte creix, la captura de re- 

quisits sol tenir lloc mitjançant les llistes de correu electrònic i es pot 

arribar a una clara distinció entre l’equip de desenvolupament –o al- 

menys els desenvolupadors més actius– i els usuaris. Per a projectes 

grans, amb molts usuaris i molts desenvolupadors, la captura de re- 

quisits es fa mitjançant la mateixa eina que s’utilitza per a gestionar 

els errors del projecte. En aquest cas, en comptes de parlar d’errors, 

es fa referència a activitats, encara que el mecanisme fet servir per a 

la gestió és idèntic al de la correcció d’errors (se la classificarà segons 

la importància, la dependència, etc., i es podrà supervisar si ha estat 

resolta o no). L’ús d’aquesta eina per a la planificació és més aviat 

recent, per la qual cosa es pot observar que en el món del progra- 

mari lliure hi ha una certa evolució des de la falta absoluta fins a un 

sistema centralitzat de gestió en l’àmbit de l’enginyeria d’activitats, 

encara que indubtablement sigui bastant limitat. En qualsevol cas, no 

sol ser comú un document que reuneixi els requisits tal com és nor- 

mal en el model en cascada. 

199 


ANOTACIONS


ANOTACIONS 



172] 

200 


Quant al disseny global del sistema, només els grans projectes el so- 

len tenir documentat de manera exhaustiva. En la resta de projectes, 

el més probable és que el desenvolupador o desenvolupadors prin- 

cipals siguin els únics que el posseeixin –de vegades només en la 

seva ment–, o que es vagi forjant en versions posteriors del progra- 

mari. La falta d’un disseny detallat no implica només limitacions a la 

possible reutilització de mòduls, sinó que també és un gran handicap 

a l’hora de permetre l’accés a nous desenvolupadors, ja que s’hau- 

ran d’enfrontar a un procés d’aprenentatge lent i costós. El disseny 

detallat, per la seva banda, tampoc no està gaire generalitzat. La 

seva absència implica que es perdin moltes possibilitats de reutilitza- 

ció de codi. 

La implementació és la fase en què es concentra el màxim d’esforç 

per part dels desenvolupadors de programari lliure, entre altres ra- 

ons perquè per als desenvolupadors és manifestament el més diver- 

tit. Per a això, se sol seguir el paradigma de programació clàssic de 

prova i error fins que s’aconsegueixen els resultats que al programa- 

dor li vé de gust des del punt de vista subjectiu. Històricament, és di- 

fícil trobar un cas en què s’incloguin proves unitàries conjuntament 

amb el codi, encara que facilitarien la modificació o inclusió de codi 

posterior per part d’altres desenvolupadors. En el cas d’alguns pro- 

jectes grans, com per exemple Mozilla, hi ha màquines dedicades ex- 

clusivament a baixar el codi més recent (repositoris) per compilar-lo 

en arquitectures diferents. Els errors detectats es notifiquen en una 

llista de correu de desenvolupadors. 

Tanmateix, les proves automàtiques no estan gaire arrelades. En ge- 

neral, seran els mateixos usuaris, dins de la gran varietat d’usos, ar- 

quitectures i combinacions, els qui les faran. Això presenta l’avantatge 

que es paral·lelitzen a un cost mínim per a l’equip de desenvolupa- 

ment. El problema que aquest model planteja és com organitzar que 

hi hagi realimentació per part dels usuaris i resulti tan eficient com si- 

gui possible. 

Pel que fa al manteniment en el món del programari lliure –ens refe- 

rim al manteniment de versions antigues–, és una tasca que depèn 

del projecte. En projectes que requereixen una gran estabilitat, com 

nuclis del sistema operatiu, etc., es mantenen versions antigues del 

programari, perquè un canvi en una nova versió pot resultar traumà-


tic. Però, en general, en la majoria dels projectes de programari lliu- 

re, si es té una versió antiga i s’hi troba un error, els desenvolupadors 

no se solen posar a corregir-lo i aconsellen utilitzar la versió més mo- 

derna amb l’esperança que l’error hagi desaparegut, ja que el pro- 

gramari ha evolucionat. 

7.5. Crítica a “La catedral i el basar” 

L’article “La catedral i el basar” manca de sistematització i rigor, 

d’acord amb la seva naturalesa més aviat assagística i realment poc 

científica. Les crítiques més freqüents es refereixen al fet que s’hi ex- 

plica bàsicament una experiència puntual –el cas de Linux– i que s’hi 

pretenen generalitzar les conclusions per a tots els projectes de progra- 

mari lliure. En aquest sentit, es pot veure a Sandeep Krishnamurthy 

[(2000, maig). “Cave or community? An empirical examination of 

100 mature open source projects”. First Monday (vol. 6, núm. 7)] que 

una comunitat tan àmplia com amb la que compta el nucli Linux és 

més aviat una excepció. 

Encara més crítics es mostren els que pensen que Linux és un exem- 

ple de desenvolupament que segueixi el model de les catedrals. Ar- 

gumenten que sembla evident que hi ha un cap pensant, o almenys 

una persona que té la màxima potestat, i un sistema jeràrquic amb 

delegació de responsabilitats fins a arribar als obrers programadors. 

Per tant, hi ha repartiment de tasques, encara que sigui implícit. 

Nikolai Bezroukov [(1998, desembre). “A second look at the cathe- 

dral and the bazaar”. First Monday (vol. 12, núm. 4)] va més enllà i 

sosté –no sense certa acritud i arrogància en l’argumentació– que la 

metàfora del basar és inherentment contradictòria. 

Un altre dels punts més criticats de “La catedral i el basar” és la 

seva afirmació que la llei de Brooks (“afegir desenvolupadors a un 

projecte de programari retardat el retarda encara més”) no és và- 

lida en el món del programari lliure. A Paul Jones [(maig, 2000). 

Brook’s law and open source: The more the merrier?] es pot llegir 

que, en realitat, les condicions de l’entorn són diferents i que allò 

que en principi sembla una incongruència respecte de la llei de Bro- 

oks, després d’un estudi més exhaustiu no deixa de ser un miratge. 

201 




139] 



72] 

ANOTACIONS 



130 i 128]


ANOTACIONS 



105, 161 i 125] 

202 


7.6. Estudis quantitatius 

El programari lliure permet endinsar-se en l’estudi quantitatiu del 

codi i de la resta de paràmetres que intervenen en la seva generació, 

atesa la seva accessibilitat. Això permet que algunes àrees de l’engi- 

nyeria del programari tradicional –com l’enginyeria del programari 

empírica– es puguin veure potenciades per l’existència d’una ingent 

quantitat d’informació a la qual es pot accedir sense necessitat d’es- 

tar molt introduït en el desenvolupament de programari lliure. Els au- 

tors estem convençuts que aquesta visió pot ajudar enormement en 

l’anàlisi i la comprensió dels fenòmens lligats a la generació de pro- 

gramari lliure (i de programari en general) i fins i tot pot arribar, en- 

tre altres possibilitats, a tenir models predictius del programari que 

es realimentin en temps real. 

La idea que hi ha al darrere és molt simple: atès que tenim la possi- 

bilitat d’estudiar l’evolució d’un gran nombre de projectes de progra- 

mari lliure, fem-ho! I és que, a més de l’estat actual d’un projecte, 

tota la seva evolució passada és pública, i tota aquesta informació, 

degudament extreta, analitzada i empaquetada, pot servir com una 

base de coneixement que permeti avaluar la “salut” d’un projecte, fa- 

cilitar-ne la presa de decisions i pronosticar-hi complicacions actuals i 

futures. 

El primer estudi quantitatiu de certa importància en el món del pro- 

gramari lliure té data del 1998, encara que es va publicar al comen- 

çament del 2000. La seva finalitat era obtenir un coneixement 

empíric de la participació dels desenvolupadors en el món del pro- 

gramari lliure. Per a això es volgueren del tractament estadístic de 

l’assignació d’autoria que els autors solen situar al capdavant dels 

fitxers de codi font. Es va demostrar que la participació segueix la llei 

de Pareto: el 80% del codi correspon al 20% més actiu dels desenvo- 

lupadors, mentre que el 80% de desenvolupadors restant té una 

aportació d’un 20% del total. Molts estudis posteriors han confirmat la 

validesa d’aquest resultat i l’han ampliat a altres formes de participa- 

ció diferents de l’aportació de codi font (missatges a llista de correu, 

notificació d’errors, fins i tot el nombre de descàrregues del promgra- 

mari) com es pot veure en la referència següent: Francis Hunt; Paul 

Johnson. (2002). On the Pareto distribution of sourceforge projects.


Technical report. Centre for Technology Management, Cambridge 

University Engineering Department, Mill Lane, Cambridge CB2 1RX. 

L’eina que es va utilitzar per a l’elaboració d’aquest estudi va ser pu- 

blicada pels seus autors amb una llicència lliure, fet que ofereix tant 

la possibilitat de reproduir-ne els resultats com d’efectuar-hi estudis 

nous. 

Nota 

El fet que apareguin molts termes propis de les ciències 

econòmiques en l’estudi d’enginyeria del programari 

lliure és conseqüència de l’interès que alguns econo- 

mistes han mostrat en els últims temps a conèixer i en- 

tendre els processos que porten alguns voluntaris a 

produir béns de gran valor sense obtenir-hi en general 

benefici directe. L’article més conegut, en què s’introdu- 

eix l’economia del regal a Internet, és Rishab A. Ghosh 

(1998, març). “Cooking pot markets: an economic mo- 

del for the trade in free goods and services on the inter- 

net”. First Monday (vol. 3, núm. 3). A Wikipedia 

(‘Pareto’) es pot obtenir més informació sobre el principi 

de Pareto i la seva generalització en la distribució que 

porta el seu nom. També són interessants la corba de 

Lorenz (que representa de manera gràfica la participa- 

ció en el projecte dels desenvolupadors) i el coeficient 

de Gini (que es calcula a partir de la corba de Lorenz 

que resulta en un nombre a partir del qual es pot veure 

la desigualtat en el sistema). 

En un estudi posterior, Koch va anar més enllà i va analitzar les in- 

teraccions que es duen a terme en un projecte de programari lliure. 

Les fonts d’informació eren la llista de correu i el repositori de ver- 

sions del projecte GNOME, però l’aspecte més interessant de l’es- 

tudi de Koch n’és l’anàlisi econòmica. Koch se centra en la 

comprovació de la validesa de predicció dels costos clàssics (punts 

de funció, model de COCOMO, etc.) i mostra els problemes que 

comporta aplicar-ho, encara que certament admet que els resultats 

que se n’obtenen –presos amb certes precaucions– s’ajusten parcial- 

ment a la realitat. Conclou que el programari lliure necessita mèto- 

des d’estudi i models propis, ja que els coneguts no s’adapten a la 

203 




103, 209, 208 i 207] 



apartat 138] 

ANOTACIONS


ANOTACIONS 






apartats 204, 205, 108, 70 

i 74] 

204 


seva naturalesa. Tanmateix, és evident que la possibilitat d’obtenir 

públicament moltes de les dades relacionades amb el desenvolupa- 

ment del programari lliure permet ser optimistes amb vista a aconse- 

guir-les d’aquests en un futur no gaire llunyà. El de Koch es pot 

considerar el primer estudi quantitatiu complet, encara que realment 

pateix d’una metodologia clara i, sobretot, d’unes eines ad hoc que 

permetin comprovar els resultats i l’estudi d’altres projectes. 

Mockus i altres presenten l’any 2000 el primer estudi de projectes 

de programari lliure que engloba la descripció completa del procés 

de desenvolupament i de les estructures organitzatives, incloent-hi 

evidències tant qualitatives com quantitatives. Utilitzen per a aquesta 

finalitat tant la història dels canvis del programari, com els informes 

d’error per a quantificar aspectes de la participació de desenvolu- 

padors, la mida del nucli, l’autoria de codi, la productivitat, la den- 

sitat de defectes i els intervals de resolució d’errors. D’alguna 

manera, aquest estudi no deixa de ser un estudi d’enginyeria de pro- 

gramari clàssic, amb l’excepció que l’obtenció de les dades s’ha fet 

íntegrament per la inspecció semiautomàtica de les dades que els 

projectes ofereixen públicament a la Xarxa. Igual que a Stefan Koch 

i Georg Schneider (2000) [“Results from programari engineering re- 

search into open source development projects using public data. 

Diskussionspapiere zum Tätigkeitsfeld Informationsverarbeitung und 

Informationswirtschaft”. A: H.R. Hansen; W.H. Janko (ed.). 

Wirtschaftsuniversität Wien (núm. 22)], amb aquest article no es va 

proporcionar cap eina ni cap procés automàtic que altres equips 

d’investigació poguessin reutilitzar en el futur. 

A David Wheeler (juliol, 2000). Estimating Linux’s size i David Wheeler 

(juny, 2001). More than a Gigabuck: Estimating GNU/Linux’s, trobem 

l’anàlisi quantitativa de les línies de codi i els llenguatges de progra- 

mació utilitzats en la distribució Red Hat. González Barahona i altres 

han seguit els seus passos en una sèrie d’articles dedicats a la distri- 

bució Debian (vegeu, per exemple, Jesús M. González-Barahona; 

Miguel Á. Ortuño Pérez; Pedro de las Heras Quirós; José Centeno 

González; Vicente Matellán Olivera (2001, desembre). “Counting 

potatoes: The size of Debian 2.2.”. Upgrade Magazine (vol. 6, núm. II, 

pàg. 60-66) i Jesús M. González Barahona; Gregorio Robles; 

Miguel Á. Ortuño Pérez; Luis Rodero Merino; José Centeno Gon- 

zález; Vicente Matellán Olivera; Eva M. Castro Barbero; Pedro de 

las Heras Quirós. “Anatomy of two GNU/Linux distributions”. A: Koch).


Tots ofereixen una mena de “radiografia” d’aquestes dues populars 

distribucions de GNU/Linux elaborada a partir de les dades que 

aporta una eina que compta el nombre de línies de codi reals (les lí- 

nies de codi que no són ni línies en blanc ni comentaris) d’un progra- 

ma. A part de l’espectacular resultat en línies de codi totals (l’última 

versió estable fins al moment, Debian 3.0 –coneguda com a Woody– 

supera els cent milions de línies de codi), es pot veure la distribució 

del nombre de línies en cada llenguatge de programació. La possi- 

bilitat d’estudiar l’evolució de les diferents versions de Debian al llarg 

del temps aporta algunes evidències interessants. Es pot observar 

que la mida mitjana dels paquets es manté gairebé constant en els 

últims cinc anys, de manera que la tendència natural dels paquets a 

anar creixent es veu neutralitzada per la inclusió de paquets més pe- 

tits. D’altra banda, es pot percebre que la importància del llenguatge 

de programació C, encara predominant, disminueix amb el temps, 

mentre que els llenguatges de guió (Python, PHP i Perl) i Java comp- 

tabilitzen un creixement explosiu. Els llenguatges compilats “clàssics” 

(Pascal, Ada, Modula, etc.) es troben en clara recessió. Finalment, 

aquests articles inclouen un apartat dedicat a mostrar els resultats 

obtinguts si s’aplica el model COCOMO –un model clàssic d’estima- 

ció d’esforços del principi de la dècada dels vuitanta que s’utilitza en 

projectes de programari propietari– per a fer una estimació de l’es- 

forç, la durada del projecte i els costos. 

Encara que en són els precursors, la majoria dels estudis presentats 

en aquest apartat estan bastant limitats als projectes que analitzen. 

La metodologia que s’ha utilitzat s’ajusta al projecte en estudi, és parci- 

alment manual i poques vegades la part automatitzada es pot utilit- 

zar de manera general amb la resta de projectes de programari 

lliure. Això comporta que l’esforç que cal per a estudiar un projecte 

nou és molt gran, ja que el mètode utilitzat s’ha de tornar a adaptar 

i les accions manuals s’han de repetir. 

Per aquesta raó, els últims esforços se centren a crear una infraes- 

tructura d’anàlisi que integri diverses eines de manera que el procés 

s’automatitzi al màxim. Hi ha dues raons força evidents per a fer-ho 

així: la primera és que una vegada que s’ha invertit molt de temps i 

esforç a crear una eina per analitzar un projecte –destacant especi- 

alment que sigui genèrica–, utilitzar-la per a altres projectes de pro- 

gramari lliure comporta un esforç mínim. D’altra banda, l’anàlisi 

mitjançant una sèrie d’eines que analitzen els programes des de di- 

205 


ANOTACIONS 



175, 102 i 68]


ANOTACIONS 




206 


ferents punts de vista –de vegades complementaris, altres vegades 

no– permet obtenir una perspectiva més àmplia del projecte. A Jesús 

M. González Barahona; Gregorio Robles. Libre software engineering 

web site es poden seguir aquestes iniciatives amb més deteniment. 

7.7. Treball futur 

Després de presentar la breu però intensa història de l’enginyeria del 

programari aplicada al programari lliure, podem afirmar que l’engi- 

nyeria del programari lliure encara fa els seus primers passos. Resten 

pendents d’estudi i anàlisi minuciosa diversos aspectes de gran im- 

portància per a aconseguir un model que expliqui, almenys en part, 

com es genera el programari lliure. Les qüestions que s’han d’afron- 

tar en un futur pròxim són: la classificació dels projectes de progra- 

mari lliure, la creació d’una metodologia basada en elements 

d’anàlisi automàtica en la mesura del possible i la utilització dels co- 

neixements adquirits per a l’elaboració de models que permetin en- 

tendre el desenvolupament de programari lliure, alhora que faciliti la 

presa de decisions a partir de l’experiència adquirida. 

Un aspecte que tampoc no s’ha de deixar de banda i que ja s’està 

abordant en l’actualitat, és l’avaluació de la validesa dels mètodes 

d’enginyeria clàssica en el camp del programari lliure en totes les in- 

tensificacions de l’enginyeria del programari. Així, per exemple, les 

lleis de l’evolució del programari postulades per Lehman al comença- 

ment dels setanta i actualitzades i augmentades als vuitanta i noranta 

sembla que no es compleixen incondicionalment en el desenvolupa- 

ment d’alguns projectes de programari lliure. 

Una de les deficiències més importants en l’actualitat és la falta d’una 

classificació estricta del programari lliure que permeti catalogar els 

projectes en diferents categories. Els criteris de classificació són mas- 

sa indefinits, ja que inclouen en el mateix sac projectes amb caracte- 

rístiques organitzatives, tècniques o de qualsevol altra índole molt 

diverses. L’argument que Linux –amb una vasta comunitat de desen- 

volupadors i un gran nombre d’usuaris– té una naturalesa diferent i 

no es comporta igual que un projecte molt més limitat en nombre de 

desenvolupadors i usuaris és molt encertat. En qualsevol cas, una 

classificació més exhaustiva permetria reutilitzar l’experiència adqui-


rida en projectes similars (llegiu “amb característiques semblants”), 

facilitaria les prediccions, possibilitaria el pronòstic de riscos, etc. 

El segon aspecte important a què s’ha d’enfrontar l’enginyeria del pro- 

gramari lliure, molt lligat al punt anterior i a les tendències actuals, és 

la creació d’una metodologia i d’eines que la suportin. Una metodo- 

logia clara i concisa permetrà estudiar tots els projectes amb els ma- 

teixos criteris, esbrinar-ne l’estat real, conèixer-ne l’evolució i, per 

descomptat, classificar-los. Les eines són essencials a l’hora de tractar 

aquest problema, ja que, un cop creades, permeten tenir a l’abast de 

la mà l’anàlisi de milers de projectes amb un esforç addicional mínim. 

Un dels objectius de l’enginyeria del programari lliure és que a partir 

d’un nombre limitat de paràmetres que indiquin on podem trobar a la 

Xarxa informació sobre el projecte (l’adreça del repositori de les ver- 

sions del programari, el lloc on s’emmagatzemen els arxius de les llis- 

tes de correu electrònic, la localització del sistema de gestió d’errors i 

una enquesta mínima) se’n pugui fer un estudi exhaustiu. Als gestors 

del projecte només els separaria un botó d’una anàlisi completa, una 

mena “d’anàlisi clínica” que permeti jutjar la “salut” del projecte que 

inclogui alhora una indicació sobre els aspectes que s’han de millorar. 

Un cop s’hauran aconseguit uns mètodes, una classificació i uns mo- 

dels, les possibilitats que ofereix la simulació i, més en concret, els 

agents intel·ligents, poden ser enormes. Tenint en compte que partim 

d’un sistema amb una complexitat molt coneguda, resulta interessant 

la creació de models dinàmics en què es puguin modelitzar els dife- 

rents ens que participen en la generació de programari. Evidentment, 

com més coneguem els diferents elements, més ajustat serà el model 

a la realitat. Encara que es coneixen unes quantes propostes de simu- 

lacions per al programari lliure, són bastant simples i incompletes. En 

certa manera, això es deu al fet que encara hi ha una gran llacuna 

de coneixement respecte a les interaccions que tenen lloc en la gene- 

ració de programari lliure. Si s’aconsegueix empaquetar i processar 

convenientment la informació dels projectes a través de tota la seva 

història, els agents poden ser crucials per a conèixer-ne l’evolució en 

el futur. Encara que hi hagi moltes propostes sobre com s’ha d’en- 

focar aquest problema, una de les més avançades ara per ara es 

pot trobar a: I. Antoniades; I. Samoladas; I. Stamelos; G.L. Bleris. 

“Dynamical simulation models of the open source development 

process” [64]. 

207 




64] 

ANOTACIONS


ANOTACIONS 

208 


7.8. Resum 

En aquest capítol hem pogut veure que l’enginyeria del programari 

lliure és un camp jove i encara per explorar. Els seus primers passos 

es deuen a escrits assagístics en què es proposava –no sense una de- 

terminada manca de rigor científic– un model de desenvolupament 

més eficient; però gradualment s’ha anat progressant en l’estudi sis- 

temàtic del programari lliure des d’una òptica d’enginyeria. Avui dia, 

després de diversos anys d’informes i estudis de projectes lliures com- 

plets quantitatius i qualitatius, s’està fent un esforç enorme en la con- 

secució d’una infraestructura global que permeti la classificació, 

l’anàlisi i la modelització dels projectes en un espai de temps limitat 

i de manera parcialment automàtica. Quan l’anàlisi dels projectes de 

programari lliure deixi de ser tan cara en temps i esforç com ho és 

avui dia, és molt probable que s’obri una nova etapa en l’enginyeria 

del programari lliure en què entrarà en escena un altre tipus de tèc- 

niques amb el propòsit principal de situar-se a l’entorn de preveure 

l’evolució del programari i el pronòstic de possibles complicacions.


8. Entorns i tecnologies de desenvolupament 

Aquí es fa una introducció a les tecnologies i entorns utilitzats habi- 

tualment per al desenvolupament de programari lliure i a l’impacte 

que exerceixen sobre la gestió i l’evolució dels projectes. 

8.1. Caracterització d’entorns, eines i sistemes 

Abans d’explicar eines concretes, definirem les característiques i pro- 

pietats generals d’aquestes eines, segons la feina que volem fer i la 

manera com s’organitzen els desenvolupadors. 

En primer lloc, encara que no és determinant, tant l’entorn i les eines 

de desenvolupament com la màquina virtual objectiu també haurien 

de ser lliures. Al principi això no va ser així. En efecte, el projecte 

GNU, amb l’objectiu de reemplaçar UNIX, va haver de desenvolu- 

par-se sobre i per a UNIX propietaris fins a l’aparició dels Linux i BSD 

lliures. Avui dia, especialment quan el programari lliure es desenvo- 

lupa com una part d’un model de negoci, la tendència és que la mà- 

quina objectiu també pugui ser un sistema propietari, sovint per mitjà 

de màquines virtuals interposades (Java, Python, PHP, etc.). En tot 

cas, l’entorn i la màquina virtual han d’estar prou difosos i ser prou 

econòmics per tal que es puguin reunir suficients codesenvolupadors 

que tinguin aquestes eines. 

En segon lloc, també per a atraure el màxim nombre de codesenvo- 

lupadors, les eines han de ser “senzilles”, molt “conegudes” i capa- 

ces de funcionar en màquines “econòmiques”. Possiblement per les 

raons anteriors, el món del programari lliure és relativament conser- 

vador en llenguatges, eines i entorns. 

En tercer lloc, el model de desenvolupament és eminentment distri- 

buït, amb molts col·laboradors potencials repartits per tot el món. 

Això requereix eines de col·laboració, generalment asíncrones, que 

209 


ANOTACIONS


ANOTACIONS 



182] 



30, 81, 35 i 7] 

210 


permetin, a més, que la feina avanci amb facilitat, independentment 

de la quantitat i el ritme de feina de cada col·laborador, sense fer en- 

darrerir ningú. 

Finalment, cal proporcionar als desenvolupadors aquells recursos 

que els falten, com ara màquines d’arquitectures diverses, on puguin 

compilar i provar els programes. 

8.2. Llenguatges i eines associades 

La majoria del programari lliure està desenvolupat en llenguatge C, 

no només perquè C és el llenguatge natural de qualsevol variant de 

UNIX (plataforma habitual del programari lliure), sinó per la gran di- 

fusió que té, tant en les ments com en les màquines (gcc és un com- 

pilador estàndard instal·lat per defecte en gairebé totes les 

distribucions). Precisament per aquestes raons i per la seva eficiència, 

Stallman el recomana en els projectes de GNU. Altres llenguatges 

que s’hi acosten bastant són C++, també suportat per gcc per de- 

fecte, i Java, amb certa semblança i bastant popular perquè permet 

el desenvolupament per a màquines virtuals disponibles en una gran 

varietat de plataformes. Generalment no es tenen en compte raons 

d’enginyeria del programari: a SourceForge (vegeu l’apartat 8.9.1), 

per cada cent setanta projectes en C n’hi ha un en Ada, llenguatge 

presumptament més apropiat per a desenvolupar programes de 

qualitat. De la mateixa manera, l’anglès és la lingua franca entre els 

desenvolupadors de programari lliure, malgrat que l’esperanto és un 

idioma molt més fàcil d’aprendre i amb una estructura més lògica. 

També són populars aquells llenguatges interpretats dissenyats per a 

prototipar ràpidament aplicacions normals i serveis web, com Perl, 

Python i PHP. 

Així com C és el llenguatge estàndard, make és l’eina estàndard de 

construcció de programes, ateses les seves fonts. El programador 

lliure utilitzarà normalment la versió de GNU molt més que no pas la 

de l’incompatible de BSD. Amb aquestes versions pot especificar ar- 

bres de dependències entre fitxers i regles per generar els fitxers de- 

pendents a partir d’aquells dels quals depenen. Així, es pot 

especificar que un fitxer objecte x.o depèn dels fitxers font x.c i x.h 

i que, per a construir-lo, cal executar gcc -c x.c. O que l’execu-


table del nostre programa depèn d’una col·lecció d’objectes i es 

munta d’una manera determinada. Quan es modifica un codi font i 

després s’executa make, es recompilaran només els mòduls afectats 

i es tornarà a muntar l’objecte final. És una eina de molt baix nivell, 

ja que, per exemple, és incapaç d’esbrinar per si mateixa quan s’ha 

de recompilar un mòdul en C, malgrat que podria esbrinar-ho exa- 

minant les cadenes d’include. També és molt potent, perquè pot 

combinar totes les eines disponibles de transformació de fitxers per a 

construir objectius molt complexos d’un projecte multillenguatge. 

Però és molt complicat i molt dependent d’entorns de tipus UNIX. 

Això no obstant, alternatives presumptament millors com Jam o Ant, 

són molt poc utilitzades. 

Atesa l’heterogeneïtat de sistemes, fins i tot en el món de UNIX, també 

es fan servir eines dedicades a ajudar-nos perquè els nostres progra- 

mes siguin portàtils. Les eines de GNU autoconf, automake i lib- 

tool faciliten aquestes tasques en entorns C i UNIX. Atesa 

l’heterogeneïtat d’idiomes, jocs de caràcters i entorns culturals, el pro- 

gramador de C (i de molts altres llenguatges), recorre a gettext i a 

les facilitats d’internacionalització de la biblioteca estàndard de C per 

fer programes fàcilment localitzables dinàmicament. 

Així, quan nosaltres rebem un paquet font, el més probable és que 

estigui escrit en C, empaquetat amb tar comprimit amb gzip, fet 

portàtil amb autoconf i eines associades, i construïble i instal·lable 

amb make. La seva instal·lació es durà a terme per un procés molt 

semblant al següent: 

tar xzvf paquet-1.3.5.tar.gz 

cd paquet-1.3.5 

./configure 

make 

make install 

8.3. Mecanismes bàsics de col·laboració 

El programari lliure és un fenomen possible a causa de la col·labo- 

ració de comunitats distribuïdes i que, per tant, necessiten eines que 

facin efectiva aquesta col·laboració. Encara que durant molt de 

temps es va utilitzar correu postal de cintes magnètiques, el desenvo- 

211 




10, 27, 29, 26 i 28] 

ANOTACIONS


ANOTACIONS 



apartat 38] 




212 


lupament àgil del programari lliure va començar quan es va poder 

comunicar ràpidament amb moltes persones i distribuir-los les fonts 

dels programes o respondre amb comentaris i millores de programari 

(pedaços o patches). Per conveniència, millor que enviar codi, en els 

missatges es podria difondre informació sobre un lloc on recollir-lo. 

De fet, molt al principi dels anys setanta, el correu electrònic va ser una 

extensió del protocol de transferència de fitxers d’ARPANET. 

En el món UNIX, a mitjan anys setanta, es desenvolupa uucp, el pro- 

tocol de transferència de fitxers de UNIX, apte per a comunicar mà- 

quines per línies commutades, a més de dedicades, sobre el qual es 

va muntar correu electrònic, i el 1979, el primer enllaç USENET sobre 

uucp. Les news (notícies) de USENET, un sistema de fòrum temàtic 

estructurat jeràrquicament i distribuït per inundació als llocs subscrits 

a una jerarquia, van tenir un paper fonamental en el desenvolupa- 

ment lliure de programari, enviant programes complets en font als 

grups de la jerarquia comp.sources. 

En paral·lel es van desenvolupar les llistes de correu, entre les quals es 

poden esmentar els gestors de llistes de BITNET (1981). Avui dia es 

tendeix a preferir les llistes de correu als grups de notícies de tipus 

USENET. La raó principal n’ha estat l’abús amb finalitats comercials i 

la intrusió de gent “despistada”, que introdueix soroll en les discussi- 

ons. A més, en les llistes de correu hi ha més control i poden arribar a 

més gent. Els destinataris s’han de subscriure i qualsevol adreça de 

correu és vàlida, encara que no hi hagi accés directe a Internet. L’ad- 

ministrador de la llista pot triar de conèixer qui s’hi subscriu o se’n 

dóna de baixa. L’Administrador pot restringir les contribucions als 

membres o moderar els articles abans que apareguin, encara que no 

són pràctiques gaire populars. L’administració de les llistes s’ha fet tra- 

dicionalment per correu electrònic, per mitjà de missatges especials 

amb contrasenya. Això permet que l’administrador no tingui accés 

permanent a Internet, encara que cada vegada és un fenomen més es- 

trany, de manera que el gestor de llistes de correu més popular avui 

dia, Mailman, no es pot administrar per correu electrònic i s’ha de fer 

necessàriament per web. Les llistes de correu tenen un paper crucial en 

el programari lliure i moltes vegades són l’únic mètode de contribució. 

Avui dia, amb la popularitat del web, molts fòrums són purs fòrums 

web o weblogs, sense cap altra interfície que la que s’ofereix pel na-


vegador. Aquests fòrums poden ser genèrics, com els populars SlashDot 

o BarraPunto, on s’anuncia nou programari lliure o s’hi discuteixen no- 

tícies relacionades, o especialitzats en un programa concret, que nor- 

malment estan integrats en llocs de col·laboració amb diverses eines 

addicionals (vegeu l’apartat 8.9). També hi ha interfícies web a grups 

de notícies i llistes tradicionals. 

També s’ha fet popular un mecanisme de col·laboració basat en 

wikis, sobretot quan es tracta d’elaborar un document conjunt, que 

pot ser l’especificació d’un programa, un mòdul o un sistema. En 

parlarem en l’apartat 8.5.2. 

Finalment, es poden esmentar els mecanismes d’interacció, on els des- 

envolupadors conversen en temps real. Per al programari lliure no sol 

ser un mecanisme pràctic perquè amb desenvolupadors distribuïts per 

tot el món no és fàcil trobar una hora apropiada per a tots. Això no 

obstant, hi ha diversos projectes que fan ús d’eines de xerrada textual, 

regularment o en “congressos virtuals” amb dates determinades. L’ei- 

na més usada és l’IRC (Internet relay chat), que normalment comunica 

gent per mitjà de “canals” temàtics establerts a partir d’una sèrie de ser- 

vidors col·laboradors. No és comú que s’utilitzin eines multimèdia (so, 

imatge), probablement perquè sovint requereixen connexions de quali- 

tat no disponibles per a tothom, i a més originen problemes de disponi- 

bilitat de programari lliure i ofereixen la dificultat de registrar-ne i editar- 

ne els resultats de les converses, amb el propòsit de documentar-se. 

8.4. Gestió de fonts 

A tot projecte de desenvolupament de programes li convé tenir arxiva- 

da la història, perquè alguna modificació ha pogut produir un error 

ocult que es descobreix tardanament i cal recuperar-ne l’original, al- 

menys per a analitzar-ne el problema, per exemple. Si el projecte es 

desenvolupa entre diverses persones, també s’ha de registrar-hi l’au- 

tor de cada canvi, amb les raons degudament argumentades. Si es 

van fent lliuraments del projecte per versions, cal saber exactament 

quines versions de cada mòdul formen aquests lliuraments. Sovint, un 

projecte manté una versió estable i una altra d’experimental; totes 

dues s’han de mantenir, corregir-ne els errors i transferir els errors 

corregits d’una versió a l’altra. Per fer això cal desar i etiquetar con- 

213 




apartat 131] 

ANOTACIONS


ANOTACIONS 




214 


venientment totes i cadascuna de les versions dels fitxers, cosa que 

generalment s’ha considerat un cost excessiu, encara que amb els 

discos actuals comenci a no ser tan cert. Un sistema de control de 

fonts, també anomenat sistema de gestió de versions, s’encarrega de 

registrar la història dels fitxers com un conjunt de diferències sobre 

un patró –normalment el més recent– per eficiència i d’etiquetar 

cada diferència amb les metadades necessàries. 

Però també volem que un sistema d’aquests serveixi perquè molts 

programadors col·laborin efectivament, sense que es trepitgin la fei- 

na i sense aturar el progrés de ningú. El sistema de gestió de versions 

ens ha de permetre que diversos programadors treballin conjunta- 

ment amb un cert control. Aquest control pot ser optimista o pessi- 

mista. Amb un control pessimista, un programador es pot reservar 

uns fitxers per a una millora per un temps, durant el qual ningú no 

els pot tocar. Aquest sistema és molt segur, però bloquejarà altres 

programadors i pot endarrerir el projecte, sobretot si qui ha bloque- 

jat els fitxers està ocupat en altres coses o se n’oblida. Permetre’n 

l’avanç a d’altres és més dinàmic, però més perillós, ja que hi pot ha- 

ver modificacions incompatibles. Un sistema optimista deixa avançar, 

però ens avisa quan hi ha conflictes i ens proporciona les eines per a 

resoldre’ls. 

8.4.1. CVS 

CVS (concurrent version system) és un sistema de gestió de fonts op- 

timista dissenyat al final dels vuitanta, que és el que s’utilitza en la 

majoria dels projectes lliures. En l’entorn de programari lliure es tre- 

balla normalment amb un repositori central al qual s’accedeix se- 

gons un sistema client/servidor. L’administrador del lloc decideix qui 

té accés al repositori o a parts d’aquest, encara que normalment, 

una vegada que un desenvolupador ha estat admès en el cercle de 

confiança, té accés a tots els fitxers. També es pot permetre un accés 

anònim, només de lectura, a tothom. 

El col·laborador anònim 

El CVS “anònim” és una eina fonamental per a executar el concepte 

de “lliurar aviat i sovint” defensat per Eric Raymond. Qualsevol usuari


frisós de provar l’última versió d’un programa la pot treure del CVS, 

descobrir-hi errors i reportar-los, fins i tot en forma d’arxius de millo- 

ra (patches) amb la correcció. I pot examinar la història de tot el des- 

envolupament. 

Vegem-ne una mica la mecànica. Un usuari avançat vol obtenir l’úl- 

tima versió del mòdul mod, amb un repositori accessible anònim a 

progs.org, directori /var/lliura/cvs i protocol pserver. La 

primera vegada declararà la seva intenció d’accedir-hi: 

cvs -d:pserver:anonymous@progs.org:/var/lib/cvs login 

Es demanarà una contrasenya, que serà la d’usuari anònim (normal- 

ment, un retorn de carro), que es registrarà en un fitxer local (real- 

ment aquesta operació no cal per a l’accés anònim, però el 

programa “es queixa” si no hi ha un fitxer amb la contrasenya). A 

continuació cal obtenir la primera còpia del mòdul: 

cvs -d:pserver:anonymous@progs.org:/var/lib/cvs co mod 

Això crearà un directori mod amb tots els fitxers i directoris del mòdul 

i certes metadades (continguts en subdirectoris anomenats CVS), que 

ens permetran, entre altres coses, no haver de repetir la informació 

ja donada. El nostre usuari avançat s’introdueix en el directori creat, 

genera el paquet, i prova: 

cd mod 

./configure 

make 


... 

Quan vol una versió nova, simplement actualitza la seva còpia dins 

de mod. 

cd mod 

cvs update 

./configure 

make 


... 

215 


ANOTACIONS


ANOTACIONS 

216 


Si descobreix un error, pot corregir-lo localment i enviar l’arxiu de 

millora per correu electrònic al mantenidor del programa (individual 

o llista de correu): 

cvs diff -ubB | mail -s "El meu patch" mod-maint@progs.org 

El desenvolupador normal 

El desenvolupador normal tindrà un compte al servidor. Pot utilit- 

zar el mateix mecanisme i protocol que l’usuari anònim, canviant 

anonymous pel seu nom de compte. 

Una vegada que té una còpia del treball del mòdul, pot fer-hi les 

modificacions necessàries i “enviar-ne” els canvis al repositori quan 

consideri que s’han estabilitzat. Per exemple, si modifica els fitxers 

part.h i part.c, els enviarà així: 

cvs ci part.h part.c 

Nota 

Per seguretat, per a comptes amb dret a escriptura, se 

sol usar ssh, que proporciona un canal autenticat i xi- 

frat. 

Abans d’acabar l’operació, el CVS ens demanarà una explicació del 

que s’ha fet, que s’adjuntarà a l’historial de tots dos fitxers. També 

incrementarà en una unitat el “número de revisió” de cada fitxer. 

Aquest número identifica cada moment important en la història d’un 

fitxer i es pot usar per a recuperar cada un d’aquests moments. 

Quan ha de fer un desenvolupador una operació de compromís? 

Aquesta és una qüestió metodològica que han d’acordar els mem- 

bres d’un projecte, però sembla evident que no s’han d’enviar canvis 

que no compilin. Però a més és millor que passin una bateria de pro- 

ves mínima. En molts projectes també s’ha de tenir l’aprovació d’un 

supervisor de projecte o subprojecte que examini la modificació.


Durant el desenvolupament de la modificació, algú pot haver alterat 

altres fitxers o fins i tot els mateixos. És per això que convé que el 

desenvolupador actualitzi la seva còpia amb relativa freqüència 

(operació cvs update). Si han modificat altres fitxers, pot haver 

canviat l’entorn i fallar en proves que abans passaven. Si han modi- 

ficat els mateixos fitxers, pot ser en llocs o rutines que no hem tocat 

o en codi que sí que hem modificat. En el primer cas no hi ha con- 

flicte (almenys aparent) i l’operació de modificació “barreja” la nos- 

tra versió amb la del repositori i com a resultat es generen fitxers 

combinats, amb totes les modificacions. Altrament, hi ha conflicte, i 

en aquest cas cal posar-se d’acord amb el desenvolupador que va 

fer els altres canvis i acordar una versió final. 

Per a identificar més bé cada component d’un projecte, convé que 

porti informació de revisió associada directament. CVS pot marcar 

els codis font i els objectes automàticament, sempre que observem 

una disciplina determinada. Per exemple, si en un comentari del 

codi font escrivim la paraula clau $Id$, cada vegada que el fitxer 

s’actualitzi en el repositori, aquesta paraula se substituirà per una 

cadena d’identificació, en què s’hi veurà el nom de fitxer, el número 

de revisió, la data i l’hora de l’enviament, i l’autor: 

$Id: part.c,v 1.7 2003/07/11 08:20:47 joaquim Exp $ 

Si incloem aquesta paraula clau dins d’una cadena de caràcters del 

programa, en compilar-lo la cadena apareixerà a l’objecte i a l’exe- 

cutable, i així es pot identificar amb una eina (ident). 

L’administrador 

Òbviament, els administradors són els que tenen i han de portar la 

part més complicada del manteniment del repositori. Per exemple, 

han de donar d’alta el projecte, concedir permisos als desenvolupa- 

dors i coordinar-los, etiquetar versions lliurades, etc. 

És pràctica comuna que tot projecte tingui una versió estable i una 

altra d’experimental, i per a això es creen branques: mentre que els 

que es dediquen al manteniment corregeixen errors de la branca es- 

table, els nous desenvolupaments es fan sobre la branca experimen- 

217 


ANOTACIONS


ANOTACIONS 

218 


tal. Quan aquesta branca s’estabilitza, cal passar-la a estable, no 

sense abans aplicar-hi les correccions fetes sobre la branca estable 

anterior. Aquesta operació s’anomena mesclar, és delicada i està su- 

portada en CVS, encara que potser de manera massa primitiva. 

Aquesta idea es pot estendre al concepte de branques experimentals 

que evolucionen en diferents adreces i arriben, o no, a bon port. En 

tot cas, llevat que siguin vies mortes, caldrà integrar de manera total 

o parcial el producte estable amb les branques experimentals. 

Un dret que ens dóna el programari lliure és modificar un programa 

per a ús privat. Encara que és desitjable contribuir al cabal comuni- 

tari amb qualsevol millora, moltes vegades les modificacions que vo- 

lem fer són massa específiques i no interessen al públic en general. 

Però sí que ens interessa incorporar l’evolució del programa original. 

Això es pot fer amb un tipus especial de ramificació i mescla (bran- 

ques de venedor). 

L’administrador també pot facilitar la coordinació de l’equip per mit- 

jà de mecanismes automàtics, com fer que es produeixin missatges 

de correu electrònic quan passin determinades coses, per exemple, 

les actualitzacions. O forçar que es facin determinades accions auto- 

màtiques abans de fer una actualització, com comprovacions auto- 

màtiques d’estil, compilacions o proves. 

8.4.2. Altres sistemes de gestió de fonts 

Tot i que CVS és el sistema de control de versions més àmpliament 

usat, té molts inconvenients, que no han estat suficients per a substi- 

tuir-lo, malgrat la necessitat manifesta de fer-ho. El sistema CVS: 

• No suporta canvis de nom o de directori de fitxers, ni tampoc me- 

tadades (propietaris, permisos, etc.) ni enllaços simbòlics. 

• En ser una evolució d’un sistema de control de versions de fitxers 

individuals, no suporta de manera natural el control de versions 

de grups complets. 

• No suporta conjunts de canvis coherents. En efecte, per tal d’afe- 

gir una característica o corregir un error, pot ser necessari canviar 

uns quants fitxers. Aquests canvis haurien de ser atòmics.


• En CVS és bastant complicat l’ús de branques i mescles. En efecte, 

si creem una branca experimental d’un projecte i volem incloure 

les correccions fetes en la branca estable, cal saber amb detall 

quines correccions s’han fet per tal de no repetir-les. 

• Encara que podem fer la major part de la feina desconnectats 

del servidor, en CVS necessitem estar-hi connectats per a qual- 

sevol operació que no sigui treballar amb la nostra còpia local 

de fitxers. 

• CVS no genera, sense l’ajuda d’altres eines, el fitxer changelog, 

que mostra la història global de canvis d’un projecte. 

• CVS no permet utilitzar amb facilitat qualssevol eines per veure les 

diferències entre versions o per mesclar fitxers que han donat lloc 

a algun conflicte. Això pot ser especialment important per a fitxers 

binaris que, encara que estan suportats per CVS, tenen un suport 

primitiu. Aquesta qüestió se solucionaria si poguéssim veure les 

diferents versions dels fitxers en el sistema de fitxers. 

• CVS no disposa d’una interfície gràfica, encara que hi ha alguns 

visors al web que faciliten la navegació per les diferents versions, 

la comparació gràfica, etc. 

Tanmateix, hi ha altres sistemes lliures que solucionen alguns 

d’aquests problemes. Per exemple, el veterà Aegis, proposat per 

primera vegada el 1991 per Peter Miller i gairebé tan veterà com 

CVS, però poc popular, potser perquè va aparèixer després, perquè 

imposa més controls –com l’obligació de passar les proves o de 

passar pel revisor de codi– o perquè és més difícil d’instal·lar un sis- 

tema de col·laboració distribuïda. Altres sistemes recents no han as- 

solit el grau de maduresa necessari o són complexos, poc portàtils 

o amb una cultura subjacent més pròpia del programari propietari. 

Vesta, per exemple, s’integra amb la generació de codi en una eina 

més monolítica (sistema de gestió de configuracions). 

Podem destacar Subversion, el ja designat com a successor de CVS 

–basat en extensions d’HTTP (WebDAV)–, o Arch –més ambiciós, que 

suporta repositoris distribuïts–. Aquesta és una característica molt in- 

teressant perquè permet que qualsevol tingui un repositori amb una 

branca privada o pública que després pot mesclar o no amb l’oficial. 

219 




apartats 151, 3 i 123] 

ANOTACIONS


ANOTACIONS 




220 


Així funciona BitKeeper, que Linus Torvalds va escollir per a mantenir 

el nucli de Linux, decisió molt criticada perquè el producte té una lli- 

cència que permet que els projectes lliures l’obtinguin gratuïtament, 

sempre que totes les operacions de compromís de canvis amb les se- 

ves metadades es registrin en un servidor públic designat pels propie- 

taris i accessible a tothom, i sempre que el llicenciatari no estigui 

desenvolupant cap altre sistema de control de fonts que hi pugui 

competir. Els arguments per a això són: no és possible un model de 

negoci de programari lliure basat en serveis per a aquest segment 

del mercat i no és possible desenvolupar un producte lliure de tanta 

qualitat sense que li copiïn les idees, la qual cosa es facilita donant 

accés al producte. 

En el món del programari lliure, amb prou feines es fan servir proces- 

sadors de text WYSIWYG (‘what you see is what you get’) i altres eines 

ofimàtiques que tant d’èxit tenen en altres entorns, malgrat que ja hi 

hagi eines lliures d’aquest tipus, com OpenOffice. Això es deu a diver- 

sos factors: 

Suggeriment 

Es poden veure les operacions fetes sobre els codis font 

de Linux amb BitKeeper a http://linux.bkbits.net. 

8.5. Documentació 

• Convé mantenir la documentació sota control de fonts, i els siste- 

mes de control de fonts, com CVS, encara que admeten formats 

binaris, prefereixen formats textuals transparents, que puguin ser 

editats per un editor de text normal i processats per eines desen- 

volupades per a programes que ens permetin veure fàcilment les 

diferències entre versions, generar i aplicar pedaços basats en 

aquestes diferències i fer operacions de mescla. 

Nota 

A UNIX, les eines més comunes que fan aquestes ope- 

racions són diffs, diff3, patch i merge.


• Algunes llicències de documentació lliure, especialment la GFDL 

(vegeu l’apèndix A), exigeixen formats transparents, sobretot per 

facilitar la feina als qui en facin documents derivats. 

• Les eines WYSIWYG no contenen generalment més informació 

que l’estricta de visualització, i fan molt difícil, si no impossible, el 

processament automàtic, com identificar autors o títol, o la con- 

versió a altres formats. Fins i tot encara que permetin convertir els 

formats, se sol fer de manera interactiva, i moltes vegades és im- 

possible automatitzar-la (amb make, per exemple). 

• Sovint, les eines ofimàtiques generen uns formats de fitxers molt 

voluminosos, que resulten molt desagradables per als desenvolu- 

padors o els repositoris. 

Per tot això, el programador lliure, acostumat també a programar i 

compilar, s’estima més formats de documentació transparents, mol- 

tes vegades simple text pur, o formats de documentació processa- 

bles. 

Els formats processables que s’utilitzen habitualment no són gaires. 

En el món UNIX els programes s’han documentat tradicionalment en 

els formats esperats per la família de processadors roff, amb versió 

lliure de Norman Walsh. Això no obstant, aquesta pràctica s’ha anat 

abandonant, excepte per a les pàgines de manual tradicionals, ja 

que és gairebé obligat preparar-les per a les eines més bàsiques del 

sistema. Pel fet que moltes pàgines de manual han crescut excessiva- 

ment, de manera que difícilment se’ls pot anomenar pàgines, va ser 

necessari elaborar un format hipertextual alternatiu que permetés se- 

guir documents estructurats amb índexs i referències creuades. El 

projecte GNU va dissenyar el format TeXinfo i el va convertir en el 

seu estàndard. Aquest format permet obtenir documents navegables 

amb l’eina info o dins de l’editor emacs, i al seu torn obtenir do- 

cuments impresos de qualitat amb l’ajuda del processador de textos 

TeX, de Donald Knuth. 

El format TeXinfo es pot traduir, si es vol, a HTML multipàgina; molta 

gent prefereix veure la informació amb un navegador web, tot i que 

es perd la capacitat de cerca de paraules en un document. Aquesta 

és una de les conseqüències indesitjables de la popularitat de 

221 




31, 53 i 136] 

ANOTACIONS


ANOTACIONS 






apartats 63, 201 i 202] 

222 


l’HTML, ja que els navegadors no implementen el concepte de docu- 

ment multipàgina, malgrat que hi ha elements link que permeten 

enllaçar-ne les parts. 

Hi ha una demanda imperiosa perquè els documents complexos es 

puguin veure com pàgines web multipàgina fàcilment navegables. Hi 

ha gent que escriu documentació en LaTeX, també una aplicació de 

TeX molt popular entre els científics, més expressiu que TeXinfo, i con- 

vertible a HTML multipàgina amb certes eines, sempre que es man- 

tingui una determinada disciplina. En efecte, les aplicacions de TeX 

són conjunts de macros que combinen operadors tipogràfics de nivell 

molt baix per convertir-los en llenguatges abstractes que treballen 

amb conceptes d’alt nivell (autor, títol, resum, capítol, apartat, etc.). 

Si només s’utilitzen les macros bàsiques, la conversió és senzilla. Però 

com que ningú no impedeix usar operadors de baix nivell i, a més, 

hi ha quantitats enormes de paquets de macros fora de la capacitat 

de manteniment dels mantenidors dels convertidors, és difícil acon- 

seguir que les conversions surtin bé. 

8.5.1. docbook 

El problema és que no hi ha separació entre contingut i presentació, ni 

en les aplicacions de TeX ni en les de nroff, ja que l’abstracció es 

construeix per capes. Aquesta separació la tenen les aplicacions 

d’SGML i XML, on la presentació s’especifica amb “fulls d’estil” com- 

pletament separats. Molt aviat es van començar a utilitzar aplicacions 

molt senzilles d’SGML com linuxdoc i debiandoc, però per l’escas- 

sa capacitat expressiva que tenien es va optar per anar a dokbook. 

docbook és una aplicació d’SGML originalment desenvolupada per 

a documentació tècnica informàtica, i avui amb una variant XML. 

Avui dokbook és l’estàndard de format de documentació lliure per a 

molts projectes (Linux Documentation Project, Kde, GNOME, Mandrake, 

etc.) i un objectiu per assolir en d’altres (Linux, *BSD, Debian, etc.). 

Tanmateix, dokbook és un llenguatge complex, farcit d’etiquetes, 

per la qual cosa convé tenir eines d’ajuda a l’edició, encara escasses 

i elementals; la més popular és psgml d’emacs. També és pesat de 

processar i els processadors lliures encara generen una qualitat de 

documents poc atractiva.

8.5.2. Wikis 


Molta gent troba massa complicat escriure documentació amb llen- 

guatges tan complexos com dokbook i mecanismes de col·laboració 

com CVS. Per això s’ha fet molt popular un nou mecanisme de col·la- 

boració per a l’elaboració de documents en línia pel web anomenat 

wiki: va ser inventat per Ward Cunningham [ward:wiki] i es va posar 

per primera vegada en servei el 1995. Avui s’utilitza àmpliament en 

variants molt diverses per a elaborar documents molt dinàmics, no 

destinats a ser impresos, i moltes vegades amb una vida curta (per 

exemple, l’organització d’una conferència). 

Al contrari que dokbook, un wiki té un llenguatge de marques molt 

simple i concís, que recorda la presentació final, sense ser exacta- 

ment com ella. Per exemple, els paràgrafs se separen amb una línia 

en blanc, els elements de llistes comencen per un guió, si no es nu- 

meren i per un zero, si es numeren, o les cel·les de taules se separen 

per barres verticals i horitzontals. 

Tampoc no existeix el concepte de document complet, sinó que un 

wiki és més aviat un conjunt de petits documents enllaçats que es van 

creant a mesura que cal explicar un concepte o tema nou. La creació 

dels documents és gairebé automàtica, ja que l’eina d’edició mostra 

molt clarament que hem introduït un concepte (per mitjà d’un 

NombreWiki, gairebé sempre dues paraules juntes amb la primera 

lletra en majúscules). Gairebé cap wiki no admet hiperenllaços dins 

de la mateixa pàgina. 

Al contrari que en CVS, qualsevol pot escriure en un wiki, encara que 

s’aconsella que l’autor s’identifiqui amb un registre previ. Quan se’n 

visita un, veiem que totes les pàgines tenen un botó per a perme- 

tre’n l’edició. Si es polsa, el navegador ens mostrarà en un formu- 

lari el codi font del document, que podrem canviar. No és una 

edició WYSIWYG, la qual cosa dissuadeix qui vulgui molestar, però 

és tan senzill que qualsevol interessat pot modificar documents amb 

molt poc esforç. 

Els wikis porten el seu propi control de versions de documents, de 

manera que generalment es pot accedir a totes les versions amb in- 

dicació de qui les ha fet i quan. També es poden comparar amb fa- 

223 


ANOTACIONS


ANOTACIONS 

224 


cilitat. Solen portar mecanismes de cerca, almenys per nom de 

pàgina i per paraula continguda. 

Normalment, l’autor original d’una pàgina es voldrà assabentar de 

les modificacions que s’hi fan. Per a això, es pot subscriure i rebre 

notificacions dels canvis per correu electrònic. De vegades, qui veu 

un document no s’atreveix a canviar-ne res, però pot fer-hi un co- 

mentari. Normalment, tota pàgina wiki té associat un fòrum de co- 

mentaris que s’adjunten al final del document i que, o l’autor 

original, o algú que assumeixi el rol d’editor, els pot emprar per a 

reformar el text original, potser movent frases dels comentaris als 

llocs oportuns. 

Suggeriment 

La millor manera d’entendre un wiki és accedir-ne a un i 

experimentar en una pàgina destinada a aquest efecte, 

anomenada sandbox. Podeu accedir a qualsevol, com 

per exemple: 

http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/ 

WikiSandBox. 

8.6. Gestió d’errors 

Un dels punts forts del model de desenvolupament lliure és que la 

comunitat contribueixi amb informes d’errors i que senti que els 

seus informes o solucions es tenen en compte. Per aquest motiu cal 

un mecanisme senzill que informi dels errors, de manera que els 

desenvolupadors rebin informació suficient, de manera sistemàtica 

i amb tots els detalls necessaris, ja siguin comentaris aportats pels 

col·laboradors, una explicació del que passa, el grau d’importància 

i la possible solució, o algun mecanisme automàtic que determini, 

per exemple, la versió del programa i de l’entorn en què treballa. 

També cal desar els errors en una base de dades que es pugui con- 

sultar per veure si un error ja ha estat reportat, corregit, el nivell 

d’importància que té, etc.


Hi ha uns quants d’aquests sistemes de filosofia diferent. Uns són 

per web, d’altres, per correu electrònic o per mitjà d’algun progra- 

ma intermediari. Tots tenen interfície web per a la consulta. Uns 

permeten informes anònims, d’altres requereixen identificació (una 

adreça de correu vàlida) per a evitar el soroll. Encara que els pro- 

cediments pel web semblen els més senzills, no es pot obtenir fàcil- 

ment informació automàtica de l’entorn de l’error. Per exemple, el 

sistema de Debian proporciona programes com reportbug, que 

després de preguntar el nom del paquet sobre el qual volem infor- 

mar d’un problema, consulta al servidor quins errors ja se n’han re- 

portat. Si no n’hi ha cap que es refereixi al nostre problema, ens en 

demana una descripció, un nivell d’importància (crític, greu, seriós, 

important, no es pot regenerar a partir dels codis fonts, normal, me- 

nor o algun suggeriment) i etiquetes sobre la categoria (per exemple, 

seguretat). Després d’això, si confirmem la petició, automàticament 

esbrina la versió del paquet i d’aquells del qual depèn, la versió i l’ar- 

quitectura del nucli. Òbviament, sap l’adreça electrònica, de manera 

que s’envia un informe al lloc correcte semblant a aquest: 

Package: w3m-ssl 

Version: 0.2.1-4 

Severity: important 

After reloading a page containing complex tables several dozen 

times, w3m had used all physical memory and thrashing 

commenced. This is an Alpha machine. 

-- System Information 

Debian Release: testing/unstable 

Kernel Version: Linux romana 2.2.19 #1 Fri Jun 1 18:20:08 PDT 

2001 alpha unknown 

Versions of the packages w3m-ssl depends on: 

libc6.1 2.2.3-7 GNU C Library: Shared libraries and Timezone 

data 

libgc5 5.0.alpha4-8 Conservative garbage collector for C 

libgpmg1 1.19.3-6 General Purpose Mouse Library [libc6] 

libncurses5 5.2.20010318-3 Shared libraries for terminal 

handling 

libssl0.9.6 0.9.6a-3 SSL shared libraries 

w3m 0.2.1-2 WWW browsable pager with tables/frames support 

Aquest missatge genera un número d’error, que és tornat, enviat al 

mantenidor i desat a la base de dades. Quan es resolgui l’error, tam- 

bé en rebrem una notificació. Cada error té una adreça electrònica 

assignada que es pot utilitzar per a proporcionar informació addi- 

225 


ANOTACIONS


ANOTACIONS 






apartat 44] 

226 


cional, per exemple. La base de dades d’errors es pot consultar en 

qualsevol moment a http://bugs.debian.org. 

De vegades, els sistemes de seguiment d’errors tenen mecanismes 

per a assignar la correcció a algú i posar-li un termini. En aquest 

cas, el sistema s’apropa a un sistema de gestió i a seguiment de flux 

de treballs, de vegades integrats amb el sistema de gestió de fonts. 

8.7. Sistemes de gestió de flux de treballs 

En programari lliure no s’empren mecanismes gaire sofisticats de 

gestió dels treballs que ha de fer cada desenvolupador. Al cap i a la 

fi, molts col·laboradors són voluntaris i no se’ls pot posar un esque- 

ma gaire rígid. Això no obstant, sí que es poden definir tasques i 

esperar que algú es doni d’alta en el sistema i les assumeixi, decla- 

rant-hi un termini. Es tingui o no control sobre el que poden fer de- 

terminades persones, sempre convé tenir controlades les tasques 

que cal fer, quines dependències tenen, el nivell d’importància i qui 

hi treballa. El sistema més sofisticat que es fa servir per a això és 

IssueZilla, una evolució propietària del sistema de gestió d’errors 

lliure pel web BugZilla. 

8.8. Suport per a altres arquitectures 

El suport mínim que podem voler per a fer el nostre programa por- 

tàtil a altres entorns diferents és l’accés a granges de compilació, que 

permeten compilar el nostre programa en altres arquitectures i siste- 

mes operatius. Per exemple, SourceForge (apartat 8.9.1) oferia, el 

2003, entorns GNU Linux Debian per a Intel x86, DEC Alpha, 

PowerPC i SPARC, a més d’entorns Solaris i Mac OS/X. 

A continuació, ens agradaria poder provar els nostres programes en 

aquests entorns. Quants més serveis de màquines alienes ofertes com 

a servei públic demanem, més difícil serà obtenir-los. El servei de com- 

pilació mateix pot ser problemàtic, ja que nosaltres el podem voler


desenvolupar per a llenguatges diversos, amb biblioteques diverses. 

La granja de compilació en pot proporcionar un nombre limitat. Però 

si volem provar un programa ordinari, les dificultats augmenten expo- 

nencialment, no solament perquè és molt difícil disposar dels progra- 

mes requerits, sinó per raons de seguretat, que poden fer molt 

complicat administrar aquests sistemes. Això no obstant, hi ha uns 

quants serveis de granja de servidors, amb instal·lacions estàndard 

d’arquitectures diverses, que ens poden permetre provar algunes co- 

ses. Per exemple, a part del que es pugui fer a la granja de servidors 

de SourceForge, podem trobar fins i tot granges de PDA. 

Les granges públiques que acabem de descriure són un servei d’ús 

manual. El desenvolupador convidat copia els fitxers en una d’aques- 

tes màquines, els compila i en prova el resultat. Segurament ho hau- 

rà de fer de tant en tant, en el moment previ a l’alliberament d’una 

versió important del programa. Molt més interessant pot ser que les 

compilacions i l’execució de les proves de regressió es facin sistemà- 

ticament de manera automàtica, per exemple, cada nit, si hi ha ha- 

gut algun canvi en els codis font. Així funcionen alguns projectes 

importants que proporcionen una infraestructura pròpia per a desen- 

volupadors externs, que se sol anomenar Tinderbox (‘caixa d’esca’). 

És el cas de Mozilla, finançat per Netscape, el Tinderbox del qual pre- 

senta una interfície web als resultats de la compilació i proves de 

components del seu navegador en totes les arquitectures on funcio- 

na. Aquesta interfície està íntimament relacionada amb el CVS i mos- 

tra aquests resultats per a diferents estats (entre versions), identifica 

el responsable dels errors, en facilita l’avenç, i defuig el problema 

fins que se solucioni. També utilitzen Tinderbox, si més no, els pro- 

jectes OpenOffice i FreeBSD. 

8.9. Llocs de suport al desenvolupament 

Els llocs de suport al desenvolupament proporcionen tots els serveis 

que acabem de descriure de manera més o menys integrada, junta- 

ment amb uns altres d’addicionals que permeten la cerca de projec- 

tes per categories i la classificació segons paràmetres d’activitat 

senzills. Això allibera el desenvolupador d’haver-se de muntar i ad- 

227 




apartat 40] 

ANOTACIONS


ANOTACIONS 



apartat 51] 

228 


ministrar tota una infraestructura de col·laboració per a concentrar- 

se en el seu projecte. 

8.9.1. SourceForge 

Un dels primers a establir aquest tipus de serveis i el més popular 

és SourceForge, gestionat per OSDN (Open Software Development 

Network, subsidiària de VA Software), que el juny del 2003 hostatja- 

va més de seixanta mil projectes. Està estructurat entorn d’un conjunt 

de programes del mateix nom que va ser programari lliure fins a la 

versió 2. 

Com a prototip d’aquests llocs, SourceForge ofereix una interfície 

web o portal global d’entrada (http://sourceforge.net/) i un subportal 

per projecte (http://proyecto.sourceforge.net). En la interfície global 

podem veure notícies, anuncis, enllaços i una invitació a fer-se’n 

membre o a entrar-hi, si ja se n’és. Per a col·laborar-hi, convé fer- 

se’n membre, i és imprescindible fer-ho si es vol crear un projecte 

nou o participar-ne en algun que ja existeix. Però no cal, per a ser-hi 

espectador, i com a tal podem veure quins són els projectes que ex- 

perimenten un desenvolupament més actiu o els que es baixen més 

sovint; podem buscar projectes per categories o donant una paraula 

de la seva descripció, i se’ns mostraran ordenats pel nivell d’activitat. 

Dins de cada projecte, podem veure’n la descripció, l’estat (alfa, be- 

ta, producció), els descriptors (llenguatge, sistema operatiu, temàti- 

ca, tipus d’usuaris, idioma, llicència), els errors i temes pendents o 

solucionats, detalls de la seva activitat en el temps, o ens els podem 

baixar. També podem participar en fòrums o informar-hi d’errors, 

fins i tot de manera anònima, tot i que això últim no és gaire conve- 

nient (perquè, per exemple, no ens poden respondre). 

Qualsevol usuari autenticat pot sol·licitar donar un projecte d’alta, 

que els administradors del lloc admetran si compleix les seves políti- 

ques, i que en el cas de SourceForge són bastant liberals. Una vega- 

da autoritzat, el creador pot donar d’alta altres usuaris registrats com 

a administradors addicionals o com a desenvolupadors, amb accés 

a la modificació de fonts. Després de l’autorització, no hi ha gaires 

controls més sobre el projecte, la qual cosa causa que hi hagi molts 

projectes “morts”. Això no confon gaire els usuaris perquè els projec- 

tes amb activitat baixa o nul·la amb prou feines són visibles, ja que


en les cerques es mostren ordenats segons aquest criteri. Aquests 

projectes corren el risc que els propietaris del lloc els eliminin. Els ser- 

veis que SourceForge proporciona a un projecte, i que podríem es- 

perar de qualsevol servei similar, són: 

• Hostatjament per a les pàgines web del portal del projecte, a 

l’adreça proyecto.sourceforge.net, en què es mostra al públic. 

Aquestes pàgines poden ser estàtiques o dinàmiques (amb CGI o 

PHP), i en aquest cas poden utilitzar una base de dades (MySQL). 

S’introdueixen directament mitjançant ordres de còpia remota i es 

poden manipular per mitjà de sessions interactives de terminal re- 

mot (ssh). 

• Opcionalment, un servidor virtual que respongui a adreces d’un do- 

mini obtingut a part, com www.proyecto.org o cvs.proyecto.org. 

• Tants fòrums web i/o llistes de correu com calgui, segons el criteri 

d’un administrador. 

• Un servei de notícies, en què els administradors anuncien novetats 

sobre el projecte. 

• Rastrejadors (trackers), per a informe i seguiment d’errors, peticions 

de suport, peticions de millores o integració de millores. Els admi- 

nistradors donen una prioritat a l’assumpte i n’assignen la solució 

a un desenvolupador. 

• Gestors de tasques. Similar a un rastrejador, permet definir sub- 

projectes amb una sèrie de tasques. Aquestes tasques, a més 

d’una prioritat, tenen un termini assignats. Els desenvolupadors 

als quals se’ls assignen poden manifestar de tant en tant un per- 

centatge de realització de la tasca. 

• Un CVS amb drets inicials d’accés per a tots els desenvolupadors. 

• Servei de pujada i baixada de paquets de programari. Porta un 

registre de les versions introduïdes i possibilita que els interessats 

rebin un avís quan passi. A més, la pujada comporta la creació 

de diverses rèpliques a tot el món, cosa que en facilita la distri- 

bució. 

229 


ANOTACIONS


ANOTACIONS 



47, 12 i 79] 



apartats 54, 25, 6 i 181] 

230 


• Servei de publicació de documents en HTML. Qualsevol els pot re- 

gistrar, però només seran visibles després que els aprovi un ad- 

ministrador. 

• Còpia de seguretat per a la recuperació de desastres, com ruptu- 

ra de disc, però no d’errors d’usuari, com pot ser esborrar un fit- 

xer accidentalment. 

Un usuari autenticat té una pàgina personal on hi reuneix tota la in- 

formació d’interès, com els projectes als quals està associat, els te- 

mes o tasques pendents, i també fòrums i fitxers que ha declarat que 

vol vigilar. A més, perquè un usuari no hagi d’estar pendent de la 

seva pàgina personal, rebrà per correu electrònic notificacions sobre 

allò que vol vigilar. 

8.9.2. Hereus de SourceForge 

El 2001 VA Software va estar a punt de fer fallida en plena crisi de 

les puntcom. Llavors va anunciar una versió nova del programari 

SourceForge amb llicència no lliure, en un intent de procurar-se una 

font d’ingressos, venent-lo a empreses per als seus desenvolupa- 

ments interns. També va eliminar mecanismes que permetien bolcar 

un projecte per portar-lo a un altre lloc. Tots dos fets es van veure 

com una amenaça per la qual els milers de projectes hostatjats a 

SourceForge quedarien en mans d’una sola empresa, que n’utilitza- 

ria la plataforma per a mostrar-hi programari no lliure. Davant d’ai- 

xò i de la possibilitat que el lloc tanqués, es van desenvolupar fills de 

la versió lliure i es van obrir portals basats en els fills, entre els quals 

destaquen Savannah, dedicat al projecte GNU i a altres programes 

amb llicència de tipus copyleft, o BerliOS, concebut com a punt de tro- 

bada entre desenvolupadors de programari lliure i empreses. Tanma- 

teix, això és només un pas encaminat a desenvolupar una plataforma 

distribuïda i replicada, en què ningú no tingui un control absolut dels 

projectes. 

8.9.3. Altres llocs i programes 

Naturalment, s’han desenvolupat i es continuen desenvolupant siste- 

mes de col·laboració i algunes empreses fan negoci amb el mante-


niment i el servei d’aquests llocs. Per exemple, el projecte Tigris, que 

només manté projectes d’enginyeria de programari lliure, usa un 

portal de col·laboració (SourceCast) mantingut per una empresa de 

serveis (CollabNet), que també manté llocs de projectes individuals, 

com OpenOffice. Els llocs nous van adoptant programari lliure nou, 

com ara GForce, utilitzat pel projecte Debian. Es pot veure una com- 

paració exhaustiva de molts llocs a Haggen So. Comparison of free/ 

open source hosting (fosphost) sites available for hosting projects ex- 

ternally from project owners. 

231 


ANOTACIONS

9. Estudi de casos 


Aquest capítol està dedicat íntegrament a estudiar més a fons els pro- 

jectes de programari lliure clàssics més interessants pel que fa a im- 

pacte en el món del programari lliure, resultats obtinguts, model de 

gestió, evolució històrica, etc. Sens dubte, el nombre de projectes que 

es presentaran és molt petit en comparació amb el nombre de pro- 

jectes lliures totals –que es calcula que ascendeix a uns cinquanta 

mil–, per la qual cosa aquest capítol no es podria considerar com- 

plet, ni s’hi podrà considerar mai. Tot i així, esperem que després de 

llegir-lo pugueu tenir almenys una percepció de com s’ha dut a la 

pràctica la teoria que s’ha presentat al llarg d’aquest curs. 

Els projectes escollits inclouen des d’aplicacions de baix nivell –les 

que interactuen més aviat amb el sistema físic de l’ordinador en 

comptes de l’usuari– fins a entorns de treball per a l’usuari final. 

També hem inclòs projectes de programari lliure que, en principi, no 

són íntegrament de desenvolupament. Aquest és el cas de les distri- 

bucions, que fan més aviat tasques d’integració, ja que es dediquen 

principalment a prendre un conjunt gran, però limitat, d’aplicacions 

independents i a crear un sistema on tot interactuï de manera efecti- 

va, incloent-hi també facilitats per a instal·lar, actualitzar i esborrar 

noves aplicacions si l’usuari ho desitja. 

Els projectes de més baix nivell que veurem seran Linux, el nucli del sis- 

tema operatiu més popular avui dia, i FreeBSD, que conjunta un nucli 

de la família BSD amb una sèrie d’aplicacions i utilitats desenvolupa- 

des per tercers projectes al més pur estil de les distribucions. Els entorns 

de treball de l’usuari final escollits per a l’estudi seran KDE i GNOME, 

certament els més estesos i populars. Els servidors –un dels punts 

forts dels sistemes lliures– estaran representats en aquest capítol per 

Apache, líder en el mercat dels servidors WWW. També comptarem 

amb la presentació de Mozilla, un dels clients WWW (en realitat, molt 

més que això) que hi ha en el món del programari lliure. L’últim pro- 

jecte que es veurà en aquest capítol és OpenOffice.org, un paquet 

ofimàtic lliure. 

233 


ANOTACIONS


ANOTACIONS 



apartat 74] 



apartat 212] 

234 


Per acabar, hem cregut convenient mostrar amb una mica més de 

profunditat dues de les distribucions més populars, Red Hat Linux i 

Debian GNU/Linux, i fer-ne una comparació pel que fa a la mida 

amb altres sistemes àmpliament utilitzats com poden ser els de Mi- 

crosoft Windows o Solaris. 

En acabar les presentacions dels diferents casos d’estudi, mostra- 

rem un quadre amb les característiques més notables de cada apli- 

cació o projecte. Un dels paràmetres que més pot sorprendre el 

lector són els resultats de l’estimació de cost, durada i nombre mitjà 

de desenvolupadors. Hem obtingut aquests resultats per mètodes 

tradicionals de l’enginyeria del programari, en especial el model 

COCOMO. El model COCOMO pren com a mesura d’entrada el 

nombre de línies de codi font i en genera estimacions del cost total, 

el temps de desenvolupament i l’esforç dedicat. COCOMO és un mo- 

del pensat per a processos de generació de programari “clàssics” 

(desenvolupament en cascada o en V) i per a projectes de mida mit- 

jana o gran, per la qual cosa les xifres que ens ofereix en el nostre 

cas s’han de prendre amb molt de compte. En qualsevol cas, els re- 

sultats ens poden donar una idea de l’ordre de la magnitud en què 

ens movem, amb informació sobre els esforços òptims necessaris si 

s’hagués utilitzat un model de desenvolupament propietari. 

En general, el que més sorprèn dels resultats de COCOMO n’és l’es- 

timació de costos. S’hi tenen en compte dos factors: el salari mitjà 

d’un desenvolupador i el factor de sobrecost (over-head). En el càlcul 

de l’estimació de costos, s’ha pres el salari mitjà per a un programa- 

dor de sistemes a temps complet d’acord amb l’enquesta de l’any 

2000, amb Computer World, Salary survey 2000. L’overhead és el 

sobrecost que tota empresa ha d’assumir perquè el producte surti 

al carrer amb independència del salari dels programadors. En 

aquest apartat s’inclouen des del sou de les secretàries i l’equip de 

màrqueting fins als costos de les fotocòpies, llum, equips de maqui- 

nari, etc. En resum, el cost calculat per COCOMO és el cost total 

que representaria a una empresa crear un programari de la mida 

especificada, i no s’ha de veure simplement com els diners que per- 

cebrien els programadors per fer el programari. Aleshores, els càl- 

culs dels costos deixen de semblar tan voluminosos.

9.1. Linux 


El nucli Linux és, sens dubte, l’aplicació estrella del programari lliure, 

fins al punt que, tot i ser una petita part del sistema, li n’ha donat el 

nom. Fins i tot es podria afirmar que el programari lliure mateix es 

confon de vegades amb Linux, fet que no deixa de ser una gran equi- 

vocació, ja que hi ha programari lliure que corre sobre sistemes que 

no es basen en Linux (de fet, una de les grans fites del moviment i de 

molts projectes de programari lliure és que les aplicacions es puguin 

executar en molts entorns). D’altra banda, també hi ha aplicacions 

que funcionen en Linux i que no són programari lliure (Acrobat Reader, 

el lector de documents PDF, també té una versió per a Linux). 

9.1.1. Història de Linux 

Nota 

Per a evitar l’associació del programari lliure única- 

ment amb sistemes Linux hi ha diversos projectes que 

es dediquen a integrar i distribuir aplicacions lliures 

que corren en sistemes Windows. Un d’aquests projec- 

tes, probablement el més conegut i complet, és 

GNUWin, que distribueix en un CD d’autoarrencada 

més d’un centenar d’aplicacions lliures per a sistemes 

Win32. La majoria d’aquestes aplicacions també es- 

tan disponibles en les distribucions GNU/Linux comu- 

nes, per la qual cosa són una bona eina per a anar 

preparant el canvi de sistemes Windows a GNU/Linux 

d’una manera més tranquil·la. 

La història de Linux és una de les més conegudes dins del món del 

programari lliure, segurament perquè s’assembla més a un conte 

que a la història d’un programa d’ordinador. El 1991, un estudiant 

finlandès que es deia Linus Torvalds va decidir que volia aprendre a 

utilitzar el mode protegit 386 en una màquina que la seva limitada 

butxaca li havia permès adquirir. Aleshores –i encara avui– en els 

cursos de sistemes operatius universitaris hi havia un nucli de sistema 

operatiu gestat amb finalitats acadèmiques anomenat Minix. Al capda- 

vant del grup de desenvolupament de Minix –basat en els sistemes 

235 


ANOTACIONS



ANOTACIONS 


apartat 193] 

236 


UNIX tradicionals– hi havia un dels professors d’universitat més pres- 

tigiosos, Andrew Tanenbaum. Minix era un sistema limitat, però bas- 

tant capaç i ben dissenyat, que comptava al seu voltant amb una 

gran comunitat acadèmica i d’enginyeria. 

Minix tenia una llicència de lliure distribució i es podia utilitzar sense 

problema per a finalitats acadèmiques, però tenia el gran inconvenient 

que no hi podien integrar millores persones alienes a la Universitat 

d’Amsterdam, sinó que ho havien de fer de manera independent, ge- 

neralment per mitjà d’arxius de millores. Això representava, a la pràc- 

tica, que hi hagués una versió de Minix oficial, que tothom utilitzava, i 

alhora una llarga sèrie de millores que calia aplicar-hi posteriorment 

per tal d’obtenir funcionalitats addicionals. 

A mitjan 1991, Linus –l’estudiant finlandès encara anònim– va enviar 

un missatge al grup de notícies de Minix, en què anunciava que co- 

mençava des de zero un nucli de sistema operatiu basat en Minix, però 

sense incloure-hi el codi. Linus –encara que no digués explícitament 

que el publicaria amb una llicència lliure– va apuntar que el sistema 

que volia crear no tindria les “barreres” que presentava Minix, i amb 

això –sense saber-ho, i probablement, sense voler-ho– feia el primer 

pas per quedar-se amb la comunitat que llavors s’aglutinava entorn de 

Minix. 

La versió 0.02 que data de l’octubre del 1991, encara que molt limita- 

da, ja podia executar terminals bash i el compilador GCC. En els mesos 

següents el nombre d’aportacions externes va anar creixent fins al punt 

que el març del 1992 Linus publicava la versió 0.95, que va ser àm- 

pliament reconeguda com a gairebé estable. El camí cap a la versió 1.0 

–que se sol associar amb l’estabilitat– tanmateix, encara va ser llarg: per 

exemple, el desembre del 1993 es publicaria la versió 0.99 pl 14 (que 

és com la catorzena versió corregida de la versió 0.99) i finalment 

Linux 1.0 va veure la llum el març del 1994. Ja aleshores, Linux es 

publicava sota les condicions de la llicència GPL –segons el mateix 

Torvalds, una de les millors decisions que ha pres– ja que va ajudar 

molt a la distribució i la popularització del nucli. A Michael W. Godfrey; 

Qiang Tu. (agost, 2000). “Evolution in open source software: A case 

study”. Proceedings of the 2000 International Conference on Programari 

Maintainance es pot trobar una anàlisi exhaustiva de l’evolució de les 

diferents versions del nucli de Linux quant a mida i modularitat.

9.1.2. La manera de treballar de Linux 


La manera de treballar de Torvalds no era gaire comuna en aquell 

temps. El desenvolupament es basava principalment en una llista de 

correu, en la qual no solament es discutia, sinó que també es desen- 

volupava, i a Torvalds li agradava molt que tota la vida del projecte 

s’hi veiés reflectida, per la qual cosa demanava que s’hi enviessin les 

millores. En contra del que es podria esperar –que s’enviés la millora 

com a adjunt–, Linus preferia que s’enviés el codi en el cos del mis- 

satge perquè ell i els altres el poguessin comentar. En qualsevol cas, 

encara que molta gent hi opinés i hi enviés correccions o noves fun- 

cionalitats, era indiscutible que l’última paraula, qui decidia el que 

entrava a Linux, corresponia a Linus Torvalds. 

Nota 

També resta per als annals de la història del programari 

lliure el debat que va tenir lloc al final de gener del 

1992 en el grup de notícies de Minix entre Andrew 

Tanenbaum i Linus Torvalds. Tanenbaum, segurament 

ja una mica molest per l’èxit de Torvalds amb la seva “joguina”, 

va atacar de manera una mica desproporcionada 

Linux i Linus. El punt essencial és que Linux era un 

sistema monolític (el nucli és una peça que integra tots els 

manejadors, etc.) i no pas un micronucli (el nucli té un 

disseny modular, que permet reduir-lo i carregar-hi 

mòduls sota demanda). Es pot seguir la discussió original 

tal com es va esdevenir en el grup de notícies 

a: Andrew Tanenbaum; Linus Torvalds (1999). The 

Tanenbaum-Torvalds debate. 

Nota 

La consolidació de Linus Torvalds com a “dictador benevolent” 

ha donat peu a un ampli anecdotari dins del 

projecte. Així, es comenta que si una idea agrada, 

s’ha d’implementar. Si no agrada, també s’ha d’implementar. 

El corol·lari és que les bones idees no serveixen 

per a res (sense codi, naturalment). D’altra 

banda, si la implementació no agrada, cal insistir-hi. 

És conegut el cas de Gooch, per a qui el sant Job era 

un aprenent. Gooch va fer fins a cent quaranta-sis millores 

paral·leles fins que Linus va decidir finalment integrar-lo 

a la branca oficial del nucli. 

237 


ANOTACIONS


ANOTACIONS 



apartat 165] 

238 


Una altra de les idees innovadores de Torvalds va ser el desenvolupa- 

ment paral·lel de dues branques del nucli: l’estable (el segon número 

de versió acostuma a ser parell, com per exemple 2.4.18) i la inestable 

(senar, com 2.5.12). Com no podia ser d’altra manera, Torvalds de- 

cideix què entra en una branca o en l’altra (precisament aquí podem 

ubicar moltes de les decisions més polèmiques). En qualsevol cas, Linux 

no té una planificació de lliuraments amb dates fixes: estarà enllestit 

quan ho estigui, mentrestant caldrà esperar. Segur que a hores d’ara 

el lector haurà assumit que la decisió de si està llest o, no correspon 

només a Linus. 

S’ha demostrat que el mètode de desenvolupament utilitzat en Linux 

resulta molt eficaç quant als resultats: Linux té una gran estabilitat i 

normalment hi ha un interval ínfim de correcció d’errors (de vegades 

de l’ordre dels minuts), ja que té milers de desenvolupadors. En aques- 

ta situació, la probabilitat que algú trobi algun error és molt alta i, en 

cas que el descobridor no el pugui resoldre, algú hi trobarà la solució 

de manera ràpida. En definitiva, Linux compta amb milers de persones 

al mes dedicades a desenvolupar-lo, de manera que aquest èxit no 

ens hauria de sorprendre gens. 

D’altra banda, aquesta manera de treballar és molt cara pel que fa 

als recursos. No és inusual que hi hagi moltes propostes mútuament 

excloents per a una funcionalitat nova o que es rebin una dotzena de 

millores per al mateix error. En general, a la fi, només una s’inclourà 

en el nucli, així que es pot considerar que la resta de temps i esforç 

dedicats pels desenvolupadors ha estat inútil. El model de desenvo- 

lupament de Linux és, per tant, un model que funciona molt bé en 

Linux, però que, certament, no tots els projectes es poden permetre. 

9.1.3. Estat actual de Linux 

Avui dia, Linux va camí de la versió 2.6, encara que aquesta dada 

no se sàpiga del cert, ja que hi ha veus que sol·liciten que la versió 

següent tingui un número de versió 3.0, sobretot per la inclusió de 

NUMA (accés a memòria no uniforme, utilitzada de manera habitual 

en multiprocessadors). Sens dubte, aquesta no serà l’única millora, 

sinó que es milloraran i inclouran moltes coses més, com ara siste- 

mes de fitxers, millores per a la comunicació en xarxes sense fil i ar- 

quitectures de so (ALSA), entre d’altres. Remetem el lector interessat


a l’article següent: Joseph Pranevich (2003). The wonderful world of 

Linux 2.6, que s’actualitza bastant sovint. 

Els últims anys, el model de desenvolupament de Linux ha experimen- 

tat alguns canvis. Encara que la llista de correu de desenvolupament 

continua essent l’”ànima” del projecte, el codi ja no hi ha de passar 

necessàriament. Hi ha contribuït molt BitKeeper, un sistema de control 

de versions propietari desenvolupat per la companyia BitMover 

d’acord amb les estrictes recomanacions de Linus Torvalds. L’ús d’una 

eina no lliure ha generat una gran polèmica, amb la qual altre cop s’ha 

pogut constatar la postura pragmàtica de Linus (per a ell, i per a molts 

més, el sistema lliure de control de versions CVS és molt antiquat). 

En la taula 9-1 oferim com a resum una radiografia del projecte Linux. 

Podem veure com fa poc que Linux ha superat la barrera dels tres mi- 

lions de línies de codi i es pot enquadrar en la categoria de projectes 

molt grans. De fet, Linux és, juntament amb Mozilla i OpenOffice.org, 

un dels projectes més grans dins del panorama del programari lliure. 

Pel que fa a l’estimació del temps d’execució en relació amb el nombre 

mitjà de desenvolupadors que el farien òptim, podem observar que el 

temps d’execució és bastant més petit que els deu anys d’història que 

té Linux. Això, d’altra banda, es compensa amb escreix tenint en comp- 

te que el nombre mitjà de desenvolupadors a temps complet que té 

Linux és superior. 

Taula 9-1. Estat actual de Linux 

Pàgina web http://www.kernel.org 

Inici del projecte 

Llicència GNU GPL 

Primer missatge a: 

news.comp.os.minix: agost 1991 

Versió actual de Linux 2.4.21 (versió estable del 16.6.2003) 

Línies de codi font 3.238.908 

Estimació de cost (segons 

COCOMO bàsic) 

Estimació de temps d’execució 

(segons COCOMO bàsic) 

Estimació del nombre mitjà de 

desenvolupadors (segons 

COCOMO bàsic) 

Nombre aproximat de 

desenvolupadors 

$ 131.000.000 

7,31 anys (87,71 mesos) 

132 

N’hi ha a milers (encara que en els 

crèdits només n’hi apareixen alguns 

centenars 

[http://www.jvc.es/~tuomiil/articles/ 

EvolutionOfTheLinuxCreditsFile.pdf] 

Eines d’ajuda al desenvolupament Llista de correu i BitKeeper 

239 


ANOTACIONS


ANOTACIONS 

240 


La composició de Linux pel que fa als llenguatges de programació 

mostra un clar predomini de C, considerat un llenguatge ideal per a 

sistemes crítics quant a velocitat. Quan la velocitat és un requisit tan 

estricte que ni tan sols C pot assolir, es programa directament en 

llenguatge assemblador; circumstancia que, com podem veure, és 

força habitual. Aquest llenguatge presenta el desavantatge que no és 

tan portable com C, cada arquitectura té un joc d’instruccions particu- 

lar, de manera que molt codi escrit per a una arquitectura en assem- 

blador s’ha de traduir a les altres arquitectures. La presència d’altres 

llenguatges és marginal i es limita a funcions d’instal·lació i utilitats de 

desenvolupament. La versió analitzada aquí ha estat Linux 2.4.21, tal 

com es va publicar el 16 de juny del 2003 (sense l’aplicació de cap 

millora posterior). 

Nota 

L’estimació de costos que ens ofereix COCOMO és de 

131 milions de dòlars americans, una xifra que, per po- 

sar-la en el context de les xifres que se solen manejar 

més assíduament, representa el doble del que els grans 

clubs de futbol solen pagar per una gran estrella. 

Taula 9-2. Llenguatges de programació utilitzats en Linux 

Llenguatge de programació Línies de codi Percentatge 

C 3.062.627 94,56% 

Assemblador 164.108 5,07% 

Shell 3.257 0,10% 

Yacc 3.224 0,10% 

9.2. FreeBSD 

Com ja hem comentat en el capítol dedicat a la història del progra- 

mari lliure, hi ha altres tipus de sistemes operatius lliures a més del 

popular GNU/Linux. Una altra família en són els “hereus” de les dis- 

tribucions de la Universitat de Berkeley, a Califòrnia (EUA): els siste- 

mes de tipus BSD. El més antic i conegut és FreeBSD, la història del 

qual es remunta al començament del 1993, quan Bill Jolitz va dei- 

xar de publicar les actualitzacions no oficials a 386BSD. Amb el su-


port de l’empresa Walnut Creek CDROM, que més tard va passar a 

anomenar-se BSDi, un grup de voluntaris va decidir prosseguir amb 

l’esforç de fer aquest sistema operatiu lliure. 

L’objectiu principal del projecte FreeBSD és la creació d’un sistema 

operatiu que es pugui utilitzar sense cap tipus d’obligacions ni lli- 

gams, però amb tots els avantatges de la disponibilitat del codi i d’un 

procés acurat que asseguri la qualitat del producte. L’usuari té lliber- 

tat per fer el que vulgui amb el programari, modificar-lo al seu gust 

o redistribuir-lo –de manera oberta o fins i tot tancada i sota les con- 

dicions que vulgui– amb modificacions o sense. Com el seu nom in- 

dica, el projecte FreeBSD es guia, per tant, per la filosofia de les 

llicències BSD. 

9.2.1. Història de FreeBSD 

La versió 1.0 va aparèixer al final del 1993 i estava basada en 4.3 

BSD Net/2 i en 386BSD. El sistema 4.3 BSD Net/2 comptava amb 

codi procedent dels anys setanta, quan UNIX era desenvolupat per 

AT&T, circumstància que, al cap i a la fi, va representar una sèrie de 

problemes legals que no es van resoldre fins que el 1995, FreeBSD 

2.0 va ser publicat sense incloure codi originari d’AT&T, aquesta ve- 

gada basant-se en 4.4BSD-Lite –una versió light (s’hi havien supri- 

mit molts mòduls per problemes legals i el port per a sistemes Intel 

encara estava incomplet) alliberada per la Universitat de Califòrnia 

de 4.4 BSD. 

La història de FreeBSD no seria completa si no s’expliqués res sobre 

les seves distribucions “germanes”, NetBSD i OpenBSD. NetBSD va 

aparèixer amb una versió 0.8 a mitjan 1993. El principal objectiu era 

que havia de ser molt portable –encara que al començament només 

fos un port per a i386, per això el seu lema és: “és clar que corre 

NetBSD”. OpenBSD va sorgir a partir d’una escissió de NetBSD per 

diferències filosòfiques (i també personals) entre desenvolupadors a 

mitjan 1996. El principal focus d’atenció d’aquest sistema operatiu 

és la seguretat i la criptografia –diuen que és el sistema operatiu més 

segur que hi ha–, encara que també conserva una gran portabilitat 

per basar-se en NetBSD. 

241 


ANOTACIONS


ANOTACIONS 

242 


9.2.2. Desenvolupament en FreeBSD 

El model de desenvolupament utilitzat pel projecte FreeBSD es basa 

sobretot en dues eines: el sistema de versions CVS i el sistema d’in- 

forme d’error GNATS. Tot el projecte gira entorn d’aquestes dues ei- 

nes, com es pot comprovar pel fet que a partir d’aquestes s’ha creat 

una jerarquia. Així, sobre els committers –els desenvolupadors amb 

dret a escriptura al CVS– és sobre qui recau tota la sobirania del pro- 

jecte, tant directament com indirectament mitjançant l’elecció del 

core group, tal com es veurà en l’apartat següent. 

Per a fer informes d’error en GNATS no cal ser committer, qualsevol 

qui ho vulgui hi podrà notificar una errata. Totes les contribucions 

obertes (open) en GNATS són avaluades per un committer, que po- 

drà assignar (analized) la tasca a un altre committer o demanar més 

informació a la persona que va emetre l’informe original (feedback). 

Hi ha situacions en què l’error ha estat solucionat en algunes bran- 

ques recents; en aquests casos, la branca s’especifica com a suspesa 

(suspended). En qualsevol cas, l’objectiu és tancar l’informe (closed) 

un cop corregit l’error. 

FreeBSD distribueix el seu programari de dues maneres. Per una ban- 

da, hi ha els ports, un sistema que baixa les fonts, les compila i instal·la 

l’aplicació a l’ordinador local, i per l’altra hi ha els paquets, que no 

són més que les fonts dels ports precompilats i, per tant, en binari. 

L’avantatge més important dels ports sobre els paquets és que els pri- 

mers permeten que l’usuari configuri i optimitzi el programari per al 

seu ordinador. El sistema de paquets, en canvi, ja està precompilat i 

permet instal·lar el programari d’una manera més ràpida. 

9.2.3. Presa de decisions en FreeBSD 

El consell de directors de FreeBSD, conegut popularment com el core 

team, s’encarrega de marcar la direcció del projecte, de vetllar per- 

què es compleixin els objectius del projecte FreeBSD, i d’intervenir, 

si hi ha conflictes entre els committers. Fins a l’octubre del 2000 era 

un grup tancat al qual només s’entrava a formar part per invitació 

expressa del mateix core team. A partir d’aleshores, els committers 

elegeixen els membres del core team de manera periòdica i demo-


cràtica. La normativa més important per a l’elecció del core team és 

la següent: 

• Podran votar els committers que hagin fet almenys un commit l’úl- 

tim any. 

• El consell de directors es renovarà cada dos anys. 

• Els membres del consell de directors podran ser “expulsats” amb 

el vot de dos terços dels committers. 

• Si el nombre de membres del consell de directors és menor de set, 

se celebraran noves eleccions. 

• Se celebraran noves eleccions si ho demana un terç dels committers. 

• El canvi de normativa requereix un quòrum de dos terços dels 

committers. 

9.2.4. Empreses entorn de FreeBSD 

Hi ha nombroses empreses que ofereixen serveis i productes basats 

en FreeBSD, que el projecte té en compte a la seva pàgina. En aques- 

ta presentació de FreeBSD coneixerem una mica més a fons les més 

significatives: BSDi i Walnut Creek CDROM. 

En part, FreeBSD va néixer perquè gent del CSRG (Computer Systems 

Research Group) de la Universitat de Berkeley va fundar el 1991 la 

companyia BSDi, que es dedicaria al suport comercial per al nou sis- 

tema operatiu. A més de la versió comercial del sistema operatiu 

FreeBSD, BSDi també va desenvolupar altres productes com un ser- 

vidor d’Internet i de passarel·la o gateway. 

Walnut Creek CDROM va néixer amb l’objectiu de comercialitzar 

FreeBSD com a producte acabat, i es pot considerar com una distri- 

bució a l’estil de les que hi ha per a GNU/Linux, però amb FreeBSD. 

El novembre del 1998, Walnut Creek va ampliar els seus horitzons 

amb la creació del portal FreeBSD Mall que es dedicaria a comercia- 

litzar tot tipus de productes sobre FreeBSD (des de la distribució a sa- 

243 


ANOTACIONS


ANOTACIONS 

244 


marretes, revistes, llibres, etc.), a anunciar productes de tercers a la 

seva pàgina web i a donar suport professional de FreeBSD. 

El març del 2000, BSDi i Walnut Creek es van unir sota el nom BSDi 

per fer front de manera conjunta al fenomen Linux, que deixava cla- 

rament a l’ombra els sistemes BSD en general, i FreeBSD, en parti- 

cular. Un any més tard, el maig del 2001, Wind River va adquirir la 

part dedicada a la generació de programari de BSDi, amb la clara 

intenció de potenciar el desenvolupament de FreeBSD per a ús en sis- 

temes encastats i dispositius intel·ligents connectats a la Xarxa. 

9.2.5. Estat actual de FreeBSD 

Segons les últimes dades de l’enquesta sobre servidors web que 

Netcraft fa periòdicament, el nombre de servidors web que executen 

FreeBSD s’apropa als dos milions d’unitats. Un usuari nou que vol- 

gués instal·lar-se FreeBSD podria escollir entre la versió 4.8 (que es 

podria considerar la versió estable) o la versió 5.1, més avançada 

(de desenvolupament). Mentre que la primera ofereix més estabilitat 

–sobretot en àrees com el multiprocessament simètric que han estat 

totalment reelaborades en les noves versions–, la segona permet gau- 

dir de les últimes novetats. També és important tenir en compte que les 

versions de desenvolupament solen incloure codi de proves, que afec- 

ta sensiblement a la velocitat del sistema. 

Una de les utilitats estrella de FreeBSD són les anomenades presons 

(jail, en anglès). Les presons permeten minimitzar el dany causat per 

un atac a serveis de xarxa bàsics com podrien ser sendmail per al 

correu electrònic o BIND (Berkeley Internet Name Domain) per a ges- 

tionar els noms. Els serveis s’introdueixen en una presó perquè s’exe- 

cutin en un entorn d’aïllament. La gestió de les presons es pot fer 

mitjançant una sèrie d’utilitats incloses en el FreeBSD. 

9.2.6. Radiografia de FreeBSD 

Com ja s’ha comentat, la tasca de BSD no es restringeix únicament 

al desenvolupament d’un nucli de sistema operatiu, sinó que també 

inclou la integració de multitud d’utilitats que es distribueixen conjun-


tament a l’estil de les distribucions de GNU/Linux. El fet que el procés 

de desenvolupament de FreeBSD estigui íntimament lligat al sistema 

de control de versions CVS ens pot donar una bona aproximació de 

tot el que conté. Les xifres que es donen a continuació són les corres- 

ponents a l’anàlisi de FreeBSD efectuat el 21 d’agost del 2003. 

Un dels aspectes més interessants de FreeBSD és que els seus núme- 

ros s’assemblen molt als que ja hem pogut observar en KDE i en 

GNOME: la mida del programari supera àmpliament els cinc milions 

de línies de codi, el nombre de fitxers ronda els dos-cents cinquanta 

mil i el nombre total de commits se situa entorn dels dos milions. Tan- 

mateix, és interessant observar que la principal diferència entre 

GNOME i KDE amb FreeBSD és l’”edat” del projecte. FreeBSD acaba 

de complir fa ben poc la dècada d’existència i gairebé dobla en 

temps els entorns d’escriptori amb què el comparem. Que la mida 

sigui similar, encara que el temps de desenvolupament hagi estat su- 

perior, es deu en gran part al fet que el nombre de desenvolupadors 

que ha atret FreeBSD és més petit. Amb dret d’escriptura en el CVS 

(committer) n’hi ha uns quatre-cents de comptabilitzats, mentre que 

els col·laboradors que s’esmenten en el manual de FreeBSD són 

prop d’un miler. Per aquesta raó, l’activitat que registra el CVS de 

FreeBSD és menor, en mitjana (cinc-cents commits diaris), que la que 

registraven tant GNOME (nou-cents) com KDE (mil set-cents comp- 

tant els commits automàtics). 

Hem considerat com a sistema bàsic de FreeBSD tot allò que penja 

del directori src/src del mòdul root del CVS. L’activitat que ha re- 

gistrat el sistema bàsic al llarg dels últims deu anys és de més de mig 

milió de commits. La seva mida supera els cinc milions de línies de 

codi, encara que no solament inclou el nucli, sinó multitud d’utilitats 

addicionals, i fins i tot, jocs. Si només tenim en compte el nucli (que 

es troba al subdirectori sys), té 1,5 milions de línies de codi font, 

predominantment en C. 

És interessant veure que l’estimació de temps que dóna COCOMO 

concorda perfectament amb el temps real que ha trigat el projecte 

FreeBSD, encara que l’estimació del nombre mitjà de desenvolupa- 

dors és, de llarg, més gran que la real. Observeu que en l’últim any, no- 

més uns setanta-cinc committers han estat actius, mentre que 

245 


ANOTACIONS


ANOTACIONS 

246 


COCOMO suposa que el nombre de desenvolupadors durant els deu 

anys de desenvolupament hauria de ser de dos-cents trenta-cinc. 

Finalment, podem destacar, com ja hem dit, que l’activitat principal 

de FreeBSD se situa entorn del CVS i del sistema de control d’errors 

i activitats GNATS. 

Taula 9-3. Estat actual de FreeBSD 

Pàgina web http://www.FreeBSD.org 

Inici del projecte 1993 

Llicència tipus BSD 

Versió actual de FreeBSD 

C és el llenguatge predominant en FreeBSD, i la distància amb C++ és 

superior a la dels altres casos que hem estudiat. És interessant observar 

que el nombre de línies de codi assemblador contingut en FreeBSD es 

corresponen en magnitud amb les que té Linux, encara que les que cor- 

responen al nucli només sumin unes vint-i-cinc mil línies en total. En re- 

sum, es podria dir que en FreeBSD manen els llenguatges més “clàssics” 

dins del programari lliure: C, Shell i Perl; i que no s’hi ha donat pene- 

tració dels llenguatges que hem anat observant en altres aplicacions i 

projectes –C++, Java, Python, etc.–. 

4.8 (estable), 5.1 (en 

desenvolupament) 


Línies de codi font (només nucli) 1.500.000 

Nombre de fitxers 250.000 

Estimació de cost $ 325.000.000 

Estimació de temps d’execució 10,5 anys (126 mesos) 

Estimació del nombre mitjà 

de desenvolupadors 



Nombre de committers actius l’últim 

any 

Nombre de committers actius 

en els dos últims anys 

235 

Nombre de commits en el CVS 2.000.000 

Nombre mitjà de commits (totals) 

al dia 

Eines d’ajuda al desenvolupament 

400 committers (1.000 

col·laboradors) 

75 (menys 20% del total) 

165 (entorn del 40% del total) 

Uns 500 

CVS, GNATS, llistes de correu i lloc 

de notícies


Taula 9-4. Llenguatges de programació utilitzats en FreeBSD 


C 7.080.000 92,0% 

Shell 205.000 2,7% 

C++ 131.500 1,7% 


Perl 90.900 1,20% 

Yacc 5.800 0,75% 

9.2.7. Estudis acadèmics sobre FreeBSD 

Tot i que, certament, és un projecte molt interessant –podem recons- 

truir-ne tota la història (des de fa deu anys!) mitjançant l’anàlisi del 

sistema de versions–, l’atenció que ha despertat FreeBSD entre la co- 

munitat científica ha estat més aviat petita. D’aquesta falta d’interès 

se salva un equip d’investigació que ha estudiat el projecte FreeBSD 

des de diversos punts de vista, posant una atenció especial en la ma- 

nera com es resolen els problemes de la integració de programari de 

manera incremental i descentralitzada. 

9.3. KDE 

Encara que segurament no va ser la primera solució en entorns d’es- 

criptori amigables per a l’usuari, la difusió a mitjan 1995 del sistema 

operatiu Windows95 TM va representar un canvi radical en la interac- 

ció dels usuaris normals amb els ordinadors. Dels sistemes unidi- 

mensionals de línia d’instruccions (els terminals), es va passar a la 

metàfora d’entorn de l’escriptori bidimensional, en què el ratolí va 

guanyar terreny al teclat. Windows95 TM , més que una innovació tec- 

nològica, es va acreditar com el sistema que es va aconseguir in- 

troduir en tots els entorns personals i d’oficina, i va marcar les pautes 

(regles tècniques i socials que, a principis del segle XXI, de vegades 

encara continuem patint). 

Abans dels sistemes d’escriptori, cada aplicació gestionava de ma- 

nera autònoma l’aparença i la manera d’interactuar amb l’usuari. 

247 




apartat 129] 

ANOTACIONS


ANOTACIONS 



apartat 95] 

248 


Amb els escriptoris, en canvi, les aplicacions han de tenir propietats 

comunes i un aspecte compartit entre aplicacions, de manera que 

això representi un alleujament per a l’usuari, que pot “reutilitzar la 

interacció” apresa d’una aplicació en una altra aplicació. També va 

resultar ser un alleujament per als desenvolupadors d’aplicacions, ja 

que no s’havien d’enfrontar amb la problemàtica de començar els 

elements interactius des de zero (una tasca sempre complicada), sinó 

que podien partir d’un marc i unes regles predefinides. 

9.3.1. Història de KDE 

Ràpidament, els seguidors de UNIX es van fer ressò de l’èxit notable 

de Windows 95 i, com que els entorns UNIX no tenien sistemes tan 

intuïtius com lliures, van decidir posar-se a treballar. Com a fruit 

d’aquesta preocupació va néixer, el 1996, el projecte KDE –K Desktop 

Environment– de les mans de Matthias Ettrich (creador de LyX, un pro- 

grama d’edició gràfica de TeX) i altres hackers. El projecte KDE es va 

plantejar els objectius següents: 

• Dotar els sistemes UNIX d’un entorn amigable que sigui alhora 

obert, estable, de confiança i poderós. 

• Desenvolupar un conjunt de biblioteques per escriure aplicacions 

estàndard sobre el sistema gràfic per a UNIX X11. 

• Crear una sèrie d’aplicacions que permetin que l’usuari empren- 

gui els seus objectius de manera eficaç. 

Nota 

Originàriament, el nom KDE corresponia a Kool Desktop 

Environment, però amb el temps es va decidir que 

s’anomenés simplement K Desktop Environment: l’ex- 

plicació oficial va ser que la K és la lletra que precedeix 

en l’alfabet llatí la L de Linux. 

Quan els integrants del projecte KDE de nova creació van decidir uti- 

litzar una biblioteca orientada a objectes anomenada Qt, propietat 

de la firma noruega Trolltech TM , que no estava emparada sota una 

llicència de programari lliure, es va originar una gran polèmica. Per


tant, tot i que les aplicacions de KDE estaven llicenciades sota la GPL, 

enllaçaven amb aquesta biblioteca i era impossible que es redistribuís. 

Consegüentment, es violava una de les quatre llibertats del progra- 

mari lliure enunciades per Richard Stallman en el Manifest del pro- 

gramari lliure. Des de la versió 2.0, Trolltech distribueix Qt sota una 

llicència dual que especifica que si l’aplicació que fa ús de la biblio- 

teca és GPL, llavors la llicència vàlida per a Qt és la GPL. Gràcies a 

això, un dels debats més calents i irats dins del món del programari 

lliure va tenir, per sort, un final feliç. 

9.3.2. Desenvolupament de KDE 

KDE és dels pocs projectes de programari lliure que compleixen un 

calendari de llançament de noves versions de manera generalitzada 

(recordem, per exemple, que hi ha una nova versió de Linux, “quan 

estigui llesta”, mentre que, com veurem més endavant, en el cas de 

GNOME hi hagut retards significatius a l’hora de publicar noves ver- 

sions). La numeració de les versions segueix una política perfecta- 

ment definida, segons la qual les versions de KDE consten de tres 

números de versió: un de gran i dos de més petits. Per exemple, en 

KDE 3.1.2, el número més gran seria el 3 i els més petits l’1 i el 2. 

Les versions amb el mateix número gran tenen compatibilitat binària, 

i no cal recompilar les aplicacions. Fins ara, el número gran s’ha 

canviat en paral·lel als canvis que s’han introduït en la biblioteca Qt, 

de manera que es pot veure que els desenvolupadors van voler apro- 

fitar les noves funcionalitats de la biblioteca Qt en la versió imminent 

de KDE. 

D’altra banda, les versions amb un únic número petit són versions 

en què s’han inclòs tant les noves funcionalitats com la correcció 

dels errors trobats. Les versions amb el segon número petit no inclo- 

uen noves funcionalitats sobre les versions amb el primer número 

petit i només contenen correccions d’errors. Per a aclarir-ho amb un 

exemple: KDE 3.1 és una versió de la tercera generació de KDE (nú- 

mero gran 3) al qual s’han afegit funcionalitats noves, mentre que 

KDE 3.1.1 és la versió anterior –amb les mateixes funcionalitats–, 

però amb els errors que s’han trobat, corregits. 

KDE es va constituir poc després de començar en una associació re- 

gistrada a Alemanya (KDE e.V.) i com a tal té uns estatuts que l’obli- 

249 


ANOTACIONS


ANOTACIONS 

250 


guen a tenir un consell directiu. La influència del consell directiu 

sobre el desenvolupament és nul·la, ja que la tasca és sobretot l’ad- 

ministració de l’associació, en especial de les donacions que el pro- 

jecte percep. Per a la promoció i la difusió de KDE –incloent-hi 

empreses interessades– es va crear la Lliga KDE, que s’introduirà a 

continuació. 

9.3.3. La Lliga KDE 

La Lliga KDE (KDE League, com es deia originalment en anglès) és 

un grup d’empreses i de particulars de KDE amb l’objectiu de facilitar 

la promoció, la distribució i el desenvolupament de KDE. Les empre- 

ses i els particulars que participen en la Lliga KDE no han d’estar di- 

rectament involucrats en el desenvolupament de KDE, encara que 

s’anima tots els membres a fer-ho, sinó que simplement representen 

un marc industrial i social amic de KDE. Els objectius de la Lliga KDE 

són els següents: 

• Promoure, proveir i facilitar l’educació formal i informal de les 

funcionalitats, capacitats i altres qualitats de KDE. 

• Animar corporacions, governs, empreses i individus a usar KDE. 

• Animar corporacions, governs, empreses i individus a participar 

en el desenvolupament de KDE. 

• Proveir coneixements, informació, adreça i posicionament entorn 

de KDE pel que fa a l’ús i el desenvolupament. 

• Promoure la comunicació i la cooperació entre els desenvolupa- 

dors de KDE. 

• Promoure la comunicació i la cooperació entre els desenvolupa- 

dors de KDE i el públic mitjançant publicacions, articles, llocs web, 

trobades, participació en congressos i exposicions, notes de 

premsa, entrevistes, material promocional i comitès. 

Les empreses que participen en la KDE League són principalment distri- 

bucions (SuSE, Mandrake, TurboLinux, Lindows i Hancom –una distribu- 

ció de programari lliure coreana–), empreses de desenvolupament 

(Trolltech i Klarälvdalens Datakonsult AB), a més del gegant IBM i una


empresa creada amb la finalitat de promoure KDE (KDE.com). Entre 

totes, es pot destacar per la implicació fonamental Trolltech, SuSE i 

Mandrake Software, el model de negoci del qual està íntimament lli- 

gat al projecte KDE: 

• Trolltech és una companyia noruega establerta a Oslo que desenvo- 

lupa Qt, la biblioteca que fa les vegades d’interfície gràfica d’usu- 

ari i API per al desenvolupament d’aplicacions, encara que també 

pot funcionar com a element encastat en PDA (com per exemple 

en els Sharp Zaurus). La importància del projecte KDE a Trolltech 

es pot constatar per dos elements molt importants de la seva estra- 

tègia comercial. D’una banda, reconeix KDE com la principal for- 

ma de promoció, n’encoratja el desenvolupament de l’escriptori i 

accepta i implementa les millores o modificacions proposades. 

D’altra banda, alguns dels desenvolupadors més importants de 

KDE treballen professionalment per a Trolltech –el cas més cone- 

gut és el de Mathias Ettrich, fundador del projecte– cosa que, sens 

dubte, beneficia tant el projecte KDE com la companyia mateix. 

La implicació de Trolltech en el projecte KDE no es limita només 

a la biblioteca Qt, com es pot veure pel fet que un dels desenvo- 

lupadors principals de KOffice –la suite d’oficina de KDE– hi tingui 

en l’actualitat un contracte a temps parcial. 

• SuSE sempre ha demostrat una predilecció especial pel sistema 

d’escriptori KDE, en part pel fet que una gran majoria dels desen- 

volupadors són d’origen alemany o centreeuropeu, com la matei- 

xa companyia. Coneixedora del fet que com millor i més fàcil 

sigui l’entorn d’escriptori que n’ofereixi la distribució, més gran en 

serà la implantació i, per tant, les vendes i la petició de suport, 

SuSE ha practicat sempre una política molt activa de dedicar un 

pressupost per a professionalitzar posicions clau dins del projecte 

KDE. Així, en l’actualitat, l’administrador del sistema de control de 

versions i un parell de desenvolupadors principals tenen nòmina 

de SuSE. Igualment, dins de la plantilla de SuSE hi ha una dotzena 

de desenvolupadors que poden dedicar part del seu temps labo- 

ral al desenvolupament de KDE. 

• La distribució Mandrake és un altre dels grans benefactors de KDE, 

que té a la plantilla uns quants desenvolupadors principals. La seva 

situació econòmica el 2003 –amb suspensió de pagaments inclo- 

sa– ha fet que en els últims temps hagi perdut influència. 

251 


ANOTACIONS


ANOTACIONS 

252 


9.3.4. Estat actual de KDE 

Després de la publicació de KDE el 3 el maig del 2002, l’opinió ge- 

neralitzada és que els escriptoris lliures es troben a l’altura dels com- 

petidors propietaris. Entre els seus grans èxits hi ha la incorporació 

d’un sistema de components (KParts) que permet encastar unes apli- 

cacions en altres (un tros de full de càlcul de KSpread en el proces- 

sador de textos KWord) i el desenvolupament de DCOP, un sistema 

de comunicació entre processos simple i amb autenticació. DCOP va 

ser l’aposta del projecte en detriment de les tecnologies CORBA, un 

tema d’ampli debat dins dels escriptoris lliures, en especial entre 

GNOME –que es va decidir per utilitzar tecnologies CORBA– i KDE. 

La història sembla haver posat cada tecnologia al seu lloc, com es 

pot veure amb la proposta de DBUS (una espècie de DCOP millorat) 

per part del FreeDesktop.org, un projecte interessat a fomentar la in- 

teroperabilitat i l’ús de tecnologies conjuntes en els escriptoris lliures, 

que casualment està liderat per un dels hackers de GNOME més re- 

coneguts. 

El quadre resum següent conté les característiques més importants 

del projecte KDE (taula 9-5). Les llicències que el projecte accepta de- 

penen de si es tracta d’una aplicació o una biblioteca. Les llicències 

de les biblioteques permeten una “flexibilitat” més gran a tercers; en 

altres paraules, possibilita que tercers puguin crear aplicacions pro- 

pietàries que enllacin amb les biblioteques. 

La versió actual de KDE és la 3.1.3, encara que es treballa activa- 

ment en la branca de la versió següent, KDE 3.2, amb la inclusió 

de noves funcionalitats. Per al 2004 s’espera la quarta generació 

de KDE, KDE 4, que es basarà en Qt4. Els canvis de generació re- 

presenten un gran esforç d’adaptació, una tasca avorrida i costosa 

en temps. Tanmateix, això no ha de representar que les aplicacions 

“antigues” deixin de funcionar. Generalment, perquè continuïn fun- 

cionant també s’inclouen les antigues versions de les biblioteques, 

encara que això impliqui haver de carregar diverses versions de les 

biblioteques en memòria alhora amb el malbaratament consegüent 

de recursos del sistema. Els desenvolupadors de KDE veuen aquest 

fet com una cosa inherent a l’evolució mateixa del projecte i, per 

tant, com un mal menor.

9.3.5. Radiografia de KDE 


Pel que fa a les dimensions de KDE, les xifres que es mostraran a con- 

tinuació corresponen a l’estat del CVS l’agost del 2003, per la qual 

cosa cal prendre les precaucions que ja hem comentat i encara una 

altra més: algun dels mòduls que s’han considerat en aquest estudi 

encara estan en fase de desenvolupament i no compleixen el requisit 

de ser un producte acabat. Això no ha de ser un obstacle per als nos- 

tres propòsits, ja que estem més interessats en l’ordre de magnitud 

dels resultats que en la xifra exacta. 

El codi font inclòs en el CVS de KDE suma en total més de sis milions 

de línies de codi en diferents llenguatges de programació. El temps 

que es necessitaria per a crear un projecte d’aquesta magnitud ron- 

daria els nou anys i mig –una xifra superior als set anys que té el pro- 

jecte– amb un nombre mitjà de desenvolupadors a temps complet 

estimat que rondaria els dos-cents. Si tenim en compte que, el 2003, 

KDE té unes vuit-centes persones amb accés d’escriptura al CVS (la 

meitat dels quals ha estat inactiva en els últims dos anys) i que el 

nombre de desenvolupadors de KDE contractats a temps complet no 

ha superat la vintena en cap moment, podem veure que la producti- 

vitat de KDE és, de llarg, superior a l’estimació que ofereix COCO- 

MO. 

Nota 

Una empresa que volgués desenvolupar un producte 

d’aquesta magnitud des de zero necessitaria invertir 

més de dos-cents cinquanta milions de dòlars, una xi- 

fra que, en comparació, és el que va invertir una firma 

d’automòbils en la creació d’una nova planta de pro- 

ducció a l’est d’Europa o el que una coneguda petro- 

liera planeja gastar per obrir dues-centes gasolineres 

a Espanya. 

És interessant observar que una gran part de l’esforç –gairebé la mei- 

tat que el del desenvolupament– del projecte KDE s’inverteix en la 

traducció de la interfície d’usuari i en la documentació. Encara que 

molt poques (uns quants milers) de les línies de programació es de- 

diquen a aquesta tasca, el nombre de fitxers dedicats a aquesta em- 

presa puja als setanta-cinc mil per a traduccions (xifra que s’eleva 

253 


ANOTACIONS


ANOTACIONS 

254 


fins als cent mil si incloem la documentació en els diferents formats), 

cosa que representa gairebé la quarta (tercera) part dels tres-cents 

deu mil fitxers que hi ha en el CVS. L’activitat conjunta del CVS és de 

mil dos-cents commits diaris, és a dir, el temps mitjà entre commits és 

de prop d’un minut. 

Pel que fa a les eines, llocs d’informació i esdeveniments d’ajuda al 

desenvolupament, veiem que el ventall de possibilitats que ofereix 

KDE és molt més ampli que l’usat en Linux. A més del sistema de con- 

trol de versions i de les llistes de correu, KDE compta amb una sèrie 

de llocs web on es pot trobar informació i documentació tècnica i no 

tècnica del projecte. Entre aquests llocs també hi ha un lloc de notí- 

cies, on es presenten noves solucions i es debaten propostes. Tanma- 

teix, el lloc de notícies no es pot considerar com un substitut de les 

llistes de correu –que, com en Linux, és on es troben els autèntics de- 

bats i la presa de decisions i estratègies de futur–, sinó com un punt 

de trobada amb els usuaris. Finalment, KDE organitza des de fa tres 

anys reunions periòdiques, en les quals els desenvolupadors i col·la- 

boradors s’ajunten durant aproximadament una setmana per presen- 

tar les últimes novetats, desenvolupar, debatre, conèixer-se en persona 

i passar-s’ho bé (no necessàriament en aquest ordre). 

Taula 9-5. Estat actual de KDE 

Pàgina web http://www.kde.org 


Llicència (per a aplicacions) GPL, QPL, MIT, Artistic 

Llicència (per a biblioteques) LGPL, BSD, X11 

Versió actual de KDE 3.1.3 


Nombre de fitxers 

(codi, documentació, etc.) 

310.000 fitxers 

Estimació del cost $ 255.000.000 

Estimació de temps d’execució 9,41 anys (112,98 mesos) 





Nombre de commiters actius 

l’últim any 



Nombre aproximat de traductors 

(actius) 

200,64 

Uns 900 committers 

Entorn de 450 (aproximadament 

el 50% del total) 

Uns 600 (65% del total) 

Uns 300 traductors per a més 

de 50 llengües (inclòs l’esperanto)

Nombre de commits (de 

desenvolupadors) en el CVS 

Nombre de commits (de traductors) 

en el CVS 



Eines, documentació 

i esdeveniments d’ajuda 

al desenvolupament 


Aproximadament 2.000.000 (xifra 

estimada sense commits automàtics) 

Aproximadament 1.000.000 (xifra 

estimada sense commits automàtics) 

1.700 

Pel que fa als llenguatges de programació utilitzats en KDE, predo- 

mina l’ús de C++. Això es deu principalment al fet que és el llen- 

guatge nadiu de Qt, encara que es fa un gran esforç per a fer 

enllaços que permetin el desenvolupament en altres llenguatges de 

programació. De fet, el nombre de línies de codi en els llenguatges 

minoritaris correspon gairebé íntegrament al projecte mateix de cre- 

ació de l’enllaç, encara que això no vol dir en absolut que no s’utilitzi, 

ja que hi ha nombrosos projectes externs al KDE que l’utilitzen. 

Taula 9-6. Llenguatges de programació utilitzats en KDE 

CVS, llistes de correu, lloc web, 

lloc de notícies, reunions anuals, etc. 


C++ 5.011.288 82,05% 

C 575.237 9,42% 

Objective C 144.415 2,36% 

Shell 103.132 1,69% 

Java 87.974 1,44% 

Perl 85.869 1,41% 

9.4. GNOME 

El projecte GNOME té com a principal objectiu crear un sistema d’es- 

criptori per a l’usuari final que sigui complet, lliure i fàcil d’usar. Tam- 

bé es pretén que sigui una plataforma molt potent amb vista al 

desenvolupador. GNOME és l’acrònim en anglès de GNU Network 

Object Model Environment. Des dels inicis de GNOME s’han propo- 

sat diverses formes de traduir-lo al castellà, però no se n’ha trobat 

cap que hagi satisfet tothom. Tanmateix, pel seu nom podem veure 

que GNOME és part del projecte GNU. Avui dia, tot el codi contingut 

255 


ANOTACIONS


ANOTACIONS 

256 


en GNOME ha d’estar sota llicència GNU GPL o GNU LGPL. També 

veiem que les xarxes i el modelatge orientat a objectes tenen una im- 

portància capital. 

9.4.1. Història de GNOME 

Mentre es continuava discutint sobre la llibertat de KDE, la història va vo- 

ler que, l’estiu del 1997, Miguel de Icaza i Nat Friedman coincidissin 

amb Redmond en unes jornades organitzades per Microsoft TM . És pro- 

bable que aquesta trobada propiciés en tots dos un gir radical que 

va representar tant la creació de GNOME per part de Miguel de 

Icaza quan va tornar a Mèxic (juntament amb Federico Mena 

Quintero), com la seva admiració per les tecnologies d’objectes 

distribuïts. Icaza i Mena van decidir crear un entorn alternatiu a 

KDE, ja que van considerar que una reimplementació d’una bibli- 

oteca propietària hauria estat una tasca destinada a fracassar. 

Havia nascut GNOME. 

Des d’aquells temps llunyans del 1997 fins a l’actualitat, GNOME 

ha anat creixent gradualment amb les seves contínues publicacions. 

El novembre del 1998 es va llançar la versió 0.99, però la primera 

realment popular distribuïda pràcticament per qualsevol distribució 

de GNU/Linux seria GNOME 1.0, el març del 1999. L’experiència 

d’aquesta primera versió estable de GNOME no va ser gaire satis- 

factòria, ja que molts la van considerar plena d’errors crítics. Per ai- 

xò, GNOME October (GNOME 1.0.55) es considera la primera 

versió de l’entorn d’escriptori GNOME realment estable. Amb 

GNOME October es van intentar evitar versions de publicació nu- 

merades per a no entrar en una “cursa” de versions amb KDE. La 

celebració de la primera GUADEC, la conferència de desenvolupa- 

dors i usuaris europeus de GNOME, organitzada a París l’any 

2000, no va coincidir, per poc, en el temps amb la publicació d’una 

nova versió de GNOME, anomenada GNOME April. Va ser l’última 

que va dur un mes com a nom de publicació, ja que es va demostrar 

que aquest sistema causava més confusió (per exemple, GNOME 

April és posterior a GNOME October, encara que el sentit comú ens 

faria pensar el contrari). L’octubre d’aquell any, després de deba- 

tre’s durant mesos en diferents llistes de correu, es va fundar la Fun- 

dació GNOME, que presentarem més endavant.


GNOME 1.2 va ser un pas endavant pel que fa a l’arquitectura utilit- 

zada per GNOME, que es va continuar utilitzant en GNOME 1.4. 

Aquesta etapa es va caracteritzar per la segona edició de la GUADEC, 

aquesta vegada a Copenhaguen. El que va començar essent una reu- 

nió minoritària d’alguns hackers, es va convertir en un gran esdeveni- 

ment que va atreure les mirades de tota la indústria del programari. 

Mentrestant, el litigi sobre la llibertat de KDE es va resoldre amb el 

canvi d’actitud de Trolltech TM , que va acabar llicenciant Qt sota una 

llicència dual, que era de programari lliure per a les aplicacions que 

són programari lliure. Avui dia no hi ha cap dubte que tant GNOME 

com KDE són entorns d’escriptori lliures, de manera que el desenvo- 

lupament de GNOME ha proporcionat un segon entorn d’escriptori 


9.4.2. La Fundació GNOME 

El punt més difícil de tractar quan se sent parlar de GNOME per pri- 

mera vegada és l’organització dels més de mil contribuents al pro- 

jecte. Resulta paradoxal que un projecte que té una estructura més 

aviat anàrquica arribi a fructificar i tiri endavant uns objectius com- 

plexos, que estarien a l’abast de poques multinacionals del sector de 

la informàtica. 

Encara que GNOME va néixer amb una clara intenció de fer un en- 

torn amigable i potent al qual s’anaven afegint programes nous, de 

seguida es va veure la necessitat de crear un òrgan que tingués certes 

competències que permetessin potenciar l’ús, el desenvolupament i 

la difusió de GNOME: d’aquesta manera, l’octubre del 2000 es va 

crear la Fundació GNOME, que té la seu a Boston. 

La Fundació GNOME no és un consorci industrial, sinó una organit- 

zació sense ànim de lucre, que té les funcions següents: 

• Coordina les publicacions. 

• Decideix quins projectes són part de GNOME. 

257 


ANOTACIONS


ANOTACIONS 

258 


• És la veu oficial (per a la premsa i per a organitzacions tant co- 

mercials com no comercials) del projecte GNOME. 

• Patrocina conferències relacionades amb GNOME (com GUADEC). 

• Representa GNOME en altres conferències. 

• Crea estàndards tècnics. 

• Promou l’ús i el desenvolupament de GNOME. 

A més, la Fundació GNOME permet la recepció de fons econòmics 

amb els quals patrocinar i impulsar aquestes funcions, cosa que era 

impossible fer de manera transparent abans de la seva creació. 

Avui dia, la Fundació GNOME té un empleat a temps complet que 

s’encarrega de resoldre totes les tasques burocràtiques i organitzati- 

ves que hi ha en una organització sense finalitats lucratives que es 

reuneix i fa conferències de manera periòdica. 

En termes generals, la Fundació GNOME s’estructura en dos grans 

consells: el Consell Directiu i el Consell Consultor. 

El Consell Directiu (board of directors) està integrat com a màxim per 

catorze membres elegits democràticament pels membres de la Fun- 

dació GNOME. Té un model meritocràtic, la qual cosa vol dir que per 

a ser membre de la Fundació GNOME s’ha d’haver col·laborat d’al- 

guna manera amb el projecte GNOME. L’aportació no té per què ser 

necessàriament de codi font, sinó que també hi ha tasques de traduc- 

ció, organització, difusió, etc., per les quals es pot sol·licitar ser mem- 

bre de la Fundació GNOME i tenir-hi dret de vot. Per tant, són els 

membres de la Fundació els qui es poden presentar al Consell Direc- 

tiu i els qui elegeixen democràticament els seus representants entre 

els qui s’hagin presentat. Avui dia, la votació es fa per correu electrò- 

nic. La durada del càrrec de conseller director és d’un any, al final 

del qual es tornen a convocar eleccions. 

Hi ha unes normes bàsiques per a garantir la transparència del Con- 

sell Directiu. La més vistosa és la limitació de membres afiliats a una


mateixa empresa, que no pot excedir de quatre empleats. És impor- 

tant destacar que els membres del Consell Directiu sempre ho són en 

representació personal, i mai d’una companyia. Tot i així, i després 

d’una llarga discussió, es va acceptar incloure aquesta clàusula per 

evitar suspicàcies. 

L’altre consell dins de la Fundació GNOME és el Consell Consultor: 

és un òrgan sense capacitat de decisió que serveix de vehicle de co- 

municació amb el Consell Directiu. Està compost per companyies co- 

mercials i no comercials de la indústria del programari. Avui dia els 

seus membres són Red Hat, Ximian, Hewlett-Packard, Mandrake, 

SUN Microsystems, Red Flag Linux, Wipro, Debian i la Free Softwa- 

re Foundation. Per a formar part del Consell de Consultors s’exigeix 

una quota a totes les empreses amb més de deu empleats. 

9.4.3. La indústria entorn de GNOME 

GNOME ha aconseguit introduir-se de manera substancial en la in- 

dústria, per això diverses empreses han participat molt activament en 

el seu desenvolupament. De totes, les més significatives són Ximian 

Inc., Eazel, els RHAD Labs de Red Hat i, més recentment, SUN Micro- 

systems. A continuació es descriuen per a cada cas tant les motivaci- 

ons de les companyies com les seves aportacions més importants a 

l’entorn d’escriptori GNOME: 

• Ximian Inc. (als seus començaments Helix Inc.) és el nom de l’em- 

presa que van fundar el 1999 Miguel de Icaza, cofundador de 

GNOME, i Nat Friedman, un dels hackers de GNOME. La tasca 

principal era reunir sota un mateix paraigua els desenvolupadors 

més importants de GNOME per potenciar-ne el desenvolupa- 

ment, per la qual cosa no és gens estrany que tingui o hagi tingut 

entre els seus empleats una vintena llarga dels desenvolupadors 

més actius de GNOME. L’aplicació en què Ximian va insistir més 

des del començament ha estat Evolution, un complet sistema de 

gestió d’informació personal a l’estil de Microsoft Outlook que in- 

clogui client de correu electrònic, agenda i directori de contactes. 

Els productes que Ximian comercialitzava són el Ximian Desktop 

(una versió de GNOME amb finalitats més corporatives), RedCar- 

pet (un sistema de distribució de programari, principalment, en- 

259 


ANOTACIONS


ANOTACIONS 

260 


cara que no exclusivament, de GNOME) i finalment MONO (una 

reimplementació de la plataforma de desenvolupament .NET), 

encara que aquest últim projecte no tingui res a veure, per ara, 

amb GNOME. Ximian també ha desenvolupat una aplicació que 

serveix perquè Evolution interactuï amb un servidor Exchange 

2000. Aquesta aplicació, encara que bastant petita, va ser molt 

polèmica perquè es va publicar amb una llicència no lliure. 

L’agost del 2003, Novell va comprar Ximian com a part de la seva 

estratègia per entrar en l’escriptori de GNU/Linux. 

• Eazel va ser fundada el 1999 per un grup de persones proce- 

dents d’Apple amb la finalitat de fer l’escriptori en GNU/Linux 

tan fàcil com ho és en Macintosh. L’aplicació en què van centrar 

el seu esforç va rebre el nom de Nautilus i havia de ser el gestor 

de fitxers que va jubilar el mític Midnight Commander desenvo- 

lupat per Miguel de Icaza. La falta de model de negoci i la crisi 

de les puntcom –els inversors de risc van retirar el capital neces- 

sari perquè Eazel pogués continuar funcionant– va provocar que 

el 15 de maig del 2001, Eazel es declarés en fallida i tanqués 

les portes. Encara va tenir temps de publicar la versió 1.0 de 

Nautilus, encara que la seva numeració fos més aviat artificial, 

ja que l’estabilitat que es pressuposa a una versió 1.0 no apa- 

reixia enlloc. Dos anys després de la fallida d’Eazel, es pot veure 

com Nautilus ha evolucionat i s’ha convertit en un gestor de fit- 

xers complet i manejable integrat en GNOME, per la qual cosa 

la història d’Eazel i Nautilus es pot considerar com un cas para- 

digmàtic d’un programa que sobreviu a la desaparició de l’em- 

presa que el va crear –una cosa gairebé només possible en el 

món del programari lliure. 

• Red Hat va crear els Red Hat Advanced Development Labs (labo- 

ratoris de desenvolupament avançat de Red Hat), RHAD, amb la 

intenció que l’escriptori GNOME guanyés en usabilitat i potència. 

Per a això, va contractar mitja dotzena dels hackers més impor- 

tants de GNOME i els va donar llibertat perquè desenvolupessin 

el que creguessin convenient. Dels RHAD Labs va sortir ORBit, la 

implementació de CORBA utilitzada pel projecte GNOME, cone- 

guda com “la més ràpida de l’oest”. També destaca la tasca que 

es va dur a terme en la nova versió de GTK+ i en el sistema de 

configuració de GNOME, GConf.


• SUN Microsystems es va involucrar tardanament en el desenvolu- 

pament de GNOME, ja que al setembre del 2000 GNOME era un 

producte relativament madur. La intenció de SUN era utilitzar 

GNOME com a sistema d’escriptori del sistema operatiu Solaris. 

Per a això, va crear un equip de col·laboració amb GNOME, els 

mèrits més importants del qual giren entorn de la usabilitat i l’ac- 

cessibilitat de GNOME. El juny del 2003, SUN va anunciar que 

distribuiria GNOME 2.2 amb la versió 9 de Solaris. 

9.4.4. Estat actual de GNOME 

GNOME es troba avui dia en la versió 2.2, i en camí cap a la se- 

güent, la 2.4. La majoria de les tecnologies clau en què es basa són 

prou madures, com se’n pot desprendre del número de la versió. Ai- 

xí, el broker CORBA utilitzat és ORBit2, mentre que l’entorn gràfic i 

API, GTK+, va acollir els canvis fruit de l’experiència acumulada en 

les versions de GNOME anteriors. Com a gran novetat, apareix la in- 

clusió d’una biblioteca d’accessibilitat proposada per SUN, que per- 

met que les persones amb problemes d’accessibilitat puguin utilitzar 

l’entorn GNOME. També requereix una menció especial Bonobo, el 

sistema de components de GNOME. Bonobo va marcar una època 

dins de GNOME alhora que s’anava desenvolupant el gestor d’infor- 

mació personal Evolution. Tanmateix, el temps ha demostrat que les 

expectatives aixecades per Bonobo van ser massa altes i la reutilitza- 

ció d’aquell esforç per l’ús de components no ha estat la que en prin- 

cipi s’esperava. 

Nota 

La biblioteca ATK és una biblioteca de classes abstractes 

que permet fer les aplicacions accessibles. Això vol 

dir que les persones amb alguna discapacitat (cecs, daltònics, 

gent amb problemes de vista, que no poden fer 

servir el ratolí o el teclat, etc.) puguin fer ús de GNOME. 

L’interès de SUN per l’accessibilitat neix del fet que per 

a poder oferir els seus productes al Govern dels Estats 

Units ha de complir una sèrie d’estàndards quant a accessibilitat. 

S’ho ha pres tan seriosament que l’equip de 

desenvolupament de GNOME que treballa a SUN té 

fins i tot un programador cec. L’arquitectura d’accessibilitat 

de GNOME va rebre el setembre del 2002 el premi 

Hellen Keller Achievement Award. 

261 


ANOTACIONS


ANOTACIONS 

262 


9.4.5. Radiografia de GNOME 

Les dades i les xifres que es mostren en la taula 9-7 ens permetran 

tancar la presentació de GNOME. Les xifres que es mostren corres- 

ponen a l’estat del CVS de GNOME el 14 d’agost del 2003. Aquell 

dia hi havia més de nou milions de línies de codi hostatjades en el 

repositori CVS que té el projecte GNOME. Encara que una compa- 

ració amb KDE seria el més natural, cal advertir que les diferències 

quant a l’organització dels projectes la desaconsellen, si es vol fer en 

igualtat de condicions. Per exemple, el CVS de GNOME inclou GIMP 

(un programa de creació i tractament de gràfics), responsable tot sol 

de més de sis-centes seixanta mil línies de codi, o de la biblioteca 

GTK+, sobre la qual se centra el desenvolupament en GNOME, que 

té al seu torn tres-centes trenta mil línies. Si a això s’afegeix que el re- 

positori CVS de GNOME és més procliu a obrir mòduls nous per a 

programes (en total en té set-cents) que el de KDE (que en té menys 

de cent), podrem entendre per què GNOME té un nombre de línies 

superior al de KDE, malgrat que és un any i mig més jove. El reposi- 

tori de GNOME acull més de dos-cents vint-i-cinc mil fitxers, que 

s’han afegit i modificat gairebé dos milions de vegades (mireu el 

nombre de commits unes quantes línia més avall en la taula). 

Nota 

Una empresa que volgués crear un programari de la 

magnitud de GNOME hauria de contractar una mitja- 

na de dos-cents cinquanta desenvolupadors durant 

més d’onze anys per a aconseguir un producte de 

magnitud similar, segons el model COCOMO utilitzat 

al llarg de tot aquest capítol. El cost associat ascendiria 

a uns quatre-cents milions de dòlars, una xifra sem- 

blant a la que una empresa de telefonia mòbil ja esta- 

blerta invertirà el 2003 per reforçar la seva capacitat 

de xarxa, o similar a la que desemborsarà una com- 

panyia d’automòbils per obrir una planta de produc- 

ció a Barcelona. 

GNOME té uns recursos humans de gairebé mil desenvolupadors 

amb accés de lectura al sistema de control de versions CVS, amb gai- 

rebé una vintena de desenvolupadors que es dediquen a GNOME de 

manera professional (a temps complet o parcial). D’aquests desen-


volupadors, només un 25% s’ha mostrat actiu l’últim any, xifra que 

puja al 40% si tenim en compte els dos últims anys. El nombre mitjà 

de commits al dia registrat des de l’inici del projecte arriba gairebé 

al miler. Les eines d’ajuda al desenvolupament que utilitza el projecte 

GNOME són bàsicament les mateixes que les que es fan servir en 

KDE, per la qual cosa no s’hi incidirà en aquest apartat. 

Taula 9-7. Estat actual de GNOME 

Pàgina web http://www.gnome.org 

Inici del projecte Setembre 1997 

Llicència GNU GPL y GNU LGPL 

Versió actual de GNOME 


Nombre de fitxers 

(codi, documentació, etc.) 

2.2 (encara que aviat apareixerà 

la 2.4) 

228.000 





250 aproximadament 

Nombre de subprojectes Té més de 700 mòduls en el CVS 




l’últim any 



Nombre de commits en el CVS 1.900.000 




Gairebé 1.000 amb accés 

d’escriptura al CVS 

Entorn de 500 (aproximadament 

el 55% del total) 

Uns 700 (75% del total) 

Uns 900 

CVS, llistes de correu, lloc web, 

lloc de notícies, reunions anuals, etc. 

Mentre que en KDE, C++ és indiscutiblement el llenguatge més uti- 

litzat, el lloc més alt en GNOME correspon a C. En GNOME, com 

en KDE, això es deu al fet que la biblioteca principal està escrita en 

C, ja que aquest n’és el llenguatge originari, mentre que per a pro- 

gramar amb la resta de llenguatges s’ha d’esperar que apareguin 

els enllaços. L’enllaç més avançat de GNOME és el que s’inclou en 

GNOME--, que no és més que el de C++, de manera que no sor- 

prèn que el segon llenguatge en la classificació sigui aquest. Perl ha 

263 


ANOTACIONS


ANOTACIONS 



138] 



101] 

264 


tingut des de sempre una àmplia acceptació dins de la comunitat 

GNOME i sempre s’ha posat com a exemple que en GNOME es pot 

programar en molts llenguatges. Tanmateix, la seva posada en 

pràctica no ha estat tan àmplia com es podria esperar i supera lleu- 

gerament Shell. D’altra banda, tant l’acceptació de Python com la 

de Lisp en GNOME ha estat bastant gran, com es pot comprovar per 

la importància relativa en aquesta classificació, mentre que Java 

mai no ha arribat a despuntar –segurament per culpa d’un enllaç 

incomplet. 

Taula 9-8. Llenguatges de programació utilitzats a GNOME 


C 7.918.586 86,10% 

C++ 576.869 6,27% 

Perl 199.448 2,17% 

Shell 159.263 1,73% 

Python 137.380 1,49% 

Lisp 88.546 0,96% 

9.4.6. Estudis acadèmics sobre GNOME 

Com a estudis més significatius de GNOME en l’àmbit acadèmic po- 

dem indicar els següents: 

• Stefan Koch and Georg Schneider 

És un dels primers grans estudis d’enginyeria del programari en el 

camp del programari lliure. Els autors d’aquest estudi van aprofitar 

que les dades del desenvolupament solen ser d’accés públic per a 

mesurar esforços i comparar-los amb els models d’estimació de cos- 

tos, esforços i temps clàssics. Un dels models clàssics que es va com- 

parar és el que s’ha utilitzat en aquest capítol, el model COCOMO. 

• Daniel Germán 

Fa un repàs ràpid dels objectius de GNOME, la seva breu història, i 

també l’ús de les tecnologies que fa el projecte GNOME.

9.5. Apache 


El servidor HTTP Apache és una de les aplicacions estrella del món 

del programari lliure, ja que és el servidor web de més implantació 

segons l’enquesta que fa en temps real. Així, el maig del 1999 el 57% 

dels servidors web corrien amb Apache, mentre que el maig del 

2003 el percentatge ha augmentat fins al 68%. Apache està disponi- 

ble per a tots els flavours o sabors de UNIX (BSD, GNU/Linux, Solaris, 

etc.), Microsoft Windows i altres plataformes minoritàries. 

9.5.1. Història d’Apache 

El març del 1989 Tim Berners Lee, un científic americà que treballa 

al CERN (Suïssa), proposa una nova manera de gestionar la ingent 

quantitat d’informació dels projectes del CERN. Es tracta d’una xarxa 

de documents hiperenllaçats (hipertext, tal com Ted Nelson el va 

anomenar el 1965); naixia el WWW. Va caldre esperar fins al no- 

vembre del 1990, fins que el primer programari WWW va veure la 

llum: en un paquet anomenat World Wide Web s’incloïa un navega- 

dor web d’interfície gràfica i un editor WYSIWYG (what you see is 

what you get, ‘el que veus és el que tens’). Dos anys després, la llista 

de servidors WWW tenia una trentena d’entrades, entre les quals ja 

hi havia l’NCSA HTTPd. 

L’autèntica història d’Apache comença quan el març del 1995, Rob 

McCool abandona l’NCSA. Apache 0.2 veuria la llum el 18 de març 

del 1995, basat en el servidor NCSA httpd 1.3 fet pel mateix Rob 

McCool durant la seva estada a l’NCSA. Durant aquells primers me- 

sos, Apache era una col·lecció de millores aplicades al servidor NCSA, 

fins que Robert Thau va llançar Shambhala 0.1, una reimplementació 

gairebé completa que ja incloïa l’API per als mòduls, que ha resultat 

tenir molt d’èxit. 

Nota 

El nom del projecte Apache es deu a la filosofia de 

desenvolupament i d’organització. Igual que la tribu 

dels indis apatxes americans, els desenvolupadors 

d’Apache van decidir que la seva forma d’organitza- 

ció s’havia de fonamentar en els mèrits personals dels 

265 


ANOTACIONS


ANOTACIONS 

266 


Caldria esperar al gener del 1996 per a poder gaudir de la primera 

versió estable d’Apache, l’Apache 1.0, que incloïa la càrrega de mò- 

duls en temps d’execució com a proves, a més d’altres funcionalitats 

interessants. Els primers mesos d’aquell any van ser especialment 

fructífers per al projecte, ja que la versió 1.1 es va publicar amb prou 

feines dos mesos després i tenia mòduls d’autenticació contra bases 

de dades (com MySQL). D’aleshores ençà, les fites més grans del 

projecte han estat la conformitat total amb l’estàndard HTTP 1.1 (in- 

clòs l’abril del 1997 l’Apache 1.2), la inclusió de la plataforma Win- 

dows NT (que ja va començar el juliol del 1997 amb les versions en 

proves d’Apache 1.3), la unificació dels arxius de configuració en un 

de sol (per a la qual caldria esperar a l’aparició d’Apache 1.3.3 l’oc- 

tubre del 1998) i el llançament, encara en proves, de la generació 

següent d’Apache, Apache 2. 

Mentrestant, el juny del 1998, IBM va decidir que el motor el seu pro- 

ducte WebSphere fos Apache, en lloc de desenvolupar un servidor 

HTTP propi. Això es va interpretar com un gran suport per part del 

gegant blau al projecte Apache i al programari lliure en general, en- 

cara que per a facilitar-ho calgués canviar lleugerament la llicència 

Apache original. 

desenvolupadors envers la resta de la comunitat 

Apache. S’ha estès, tanmateix, la llegenda que el nom 

Apache es deu en realitat al fet que en els primers temps 

no deixava de ser un servidor NCSA apedaçat (patchy 

server). 

9.5.2. Desenvolupament d’Apache 

El servidor HTTP Apache és el projecte central dins dels molts que ges- 

tiona l’Apache Software Foundation. El disseny modular d’Apache ha 

permès el desenvolupament d’una sèrie de projectes satèl·lit –alguns 

fins i tot de més magnitud que el mateix Apache– entorn d’Apache. 

D’aquesta manera, el servidor HTTP Apache conté el nucli del sistema 

amb les funcionalitats bàsiques, i els diversos mòduls hi aporten les 

funcionalitats addicionals. Els mòduls més coneguts són mod_perl 

(un intèrpret del llenguatge de guió Perl encastat al servidor web) i Ja- 

karta (un potent servidor d’aplicacions). En els paràgrafs següents, no


més descriurem el procés de desenvolupament seguit per al servidor 

HTTP, sense tenir en compte els altres mòduls, que poden tenir models 

semblants o no. 

El desenvolupament del servidor HTTP Apache es fonamenta en la 

feina d’un grup de desenvolupadors reduït anomenat Apache 

Group. L’Apache Group està constituït pels desenvolupadors que 

han col·laborat durant un període prolongat de temps, general- 

ment més de sis mesos. Un cop nomenat per un membre de 

l’Apache Group per a formar-ne part, se’n vota l’ingrés entre tots 

els membres. Inicialment, l’Apache Group tenia vuit desenvolupa- 

dors, després va augmentar a dotze, i avui dia en té vint-i-cinc. 

Sobre l’Apache Group recau la responsabilitat de l’evolució del ser- 

vidor web i, per tant, les decisions puntuals de desenvolupament en 

cada moment. Cal diferenciar l’Apache Group del nucli de desenvo- 

lupadors (core group) actiu en cada moment. El caràcter voluntari de 

la majoria dels desenvolupadors fa improbable que tots els desenvo- 

lupadors que componen l’Apache Group puguin estar actius tot el 

temps, per la qual cosa se’n defineix el core com aquelles persones 

que es poden ocupar de les tasques a Apache durant un interval de 

temps determinat. En línies generals, les decisions que han de pren- 

dre els desenvolupadors que formen el nucli es limiten a votar la in- 

clusió de codi –encara que en realitat això es reservi només per a 

grans canvis– i per a qüestions de disseny. D’altra banda, en gene- 

ral, solen tenir dret d’escriptura en el repositori CVS, de manera que 

serveixen com a porta d’entrada del codi i n’asseguren la correcció i 

la qualitat. 

9.5.3. Radiografia d’Apache 

Les xifres que s’exposen a continuació corresponen a la versió del ser- 

vidor HTTP Apache tal com es podia baixar del servidor CVS del pro- 

jecte Apache el 18 d’abril del 2003. No s’ha tingut en compte cap 

dels nombrosos mòduls amb què compta el projecte Apache. Com es 

pot observar, Apache és un projecte relativament petit en compara- 

ció amb els altres casos d’estudi considerats en aquest capítol. Enca- 

ra que ja ho hem comentat, és important destacar la modularitat 

d’Apache, que permet precisament això: que el nucli sigui petit i ma- 

nejable. El repositori CVS del projecte Apache, que conté el nucli del 

267 


ANOTACIONS


ANOTACIONS 

268 


servidor web i molts mòduls addicionals, acull en total més de quatre 

milions de línies de codi font, una xifra lleugerament inferior a pro- 

jectes com KDE i GNOME. 

La versió 1.3 d’Apache tenia poc més de vuitanta-cinc mil línies de 

codi font, una xifra que segons el model COCOMO demanaria l’es- 

forç de desenvolupament de vint desenvolupadors de mitjana a temps 

complet durant un any i mig. El cost total del projecte s’acostaria lla- 

vors a quatre milions de dòlars. En l’elaboració del servidor web 

d’Apache treballen fins a seixanta committers diferents, mentre que el 

nombre de desenvolupadors que han aportat es calcula que són qua- 

tre-cents aproximadament. 

Taula 9-9. Estat actual d’Apache 

Pàgina web http://www.apache.org 


Llicència Apache Free Software License 

Versió actual 1.3 (estable), 2.0 (en desenvolupament) 

Línies de codi font 85.000 


Estimació de cost 4.000.000 $ 

Estimació de temps d’execució 1,5 anys (18 mesos) 

Estimació de nombre mitjà 


Nombre aproximat 


Eines d’ajuda al 

desenvolupament 

Apache 1.3 està escrit gairebé íntegrament en el llenguatge C; la 

presència d’altres llenguatges de programació és escassa, sobretot si 

tenim en compte que la gran majoria de les línies escrites en el segon 

llenguatge, Shell, corresponen a fitxers de configuració i d’ajuda a la 

compilació. 

20 

60 committers (400 desenvolupadors) 

CVS, llistes de correu, sistema 

de notificació d’errors 

Taula 9-10. Llenguatges de programació utilitzats a Apache 

Llenguatges de programació Línies de codi Percentatge 

C 79.015 92% 

Shell 5.097 7% 

Perl 1.282 1,7%

9.6. Mozilla 


Mozilla és un paquet informàtic d’Internet lliure i multiplataforma que 

inclou un navegador WWW, un client de correu electrònic, un client 

de notícies i un editor, l’HTML. Tanmateix, en un futur, Mozilla deixa- 

rà de ser una aplicació per a passar a ser una plataforma de desen- 

volupament d’altres aplicacions, una cosa que en part ja s’ha anat 

fent. Així, molts altres navegadors utilitzen Gecko, el motor de Mozilla, 

per als seus propòsits, com és el cas de Galeon –un navegador web 

disponible per a GNOME. La generació següent d’eines basades en 

Mozilla, com el navegador web Mozilla Firebird, no solament utilit- 

zarà el motor Gecko, sinó que també farà ús de tecnologies d’inter- 

fície d’usuari proporcionades pel projecte Mozilla. 

9.6.1. Història de Mozilla 

La història de Mozilla és llarga i enrevessada, però també molt inte- 

ressant, perquè permet seguir la història del mateix WWW. I és que 

si seguim les persones i les institucions que han estat involucrades en 

el desenvolupament de Mozilla, arribarem al punt de partida de la 

web amb el llançament del primer navegador web complet. 

Com amb l’antecessor d’Apache, va ser a l’NCSA on també va 

“néixer” el primer navegador web complet, el 1993, anomenat 

Mosaic. Molts dels membres de l’equip de desenvolupament, amb 

Marc Andreesen i Jim Clark al capdavant, van crear una petita empre- 

sa per escriure, començant des de zero (ja que hi havia problemes 

amb els drets d’autor del codi de Mosaic, i el disseny tècnic del progra- 

ma tenia les seves limitacions), el que més tard seria el navegador 

Netscape Communicator, que va ser líder indiscutible del mercat dels 

navegadors web fins que va arribar el Microsoft Internet Explorer. A 

més de la innovació purament tecnològica que va representar el na- 

vegador Netscape, l’empresa Netscape Inc. també va ser innovadora 

en la manera d’aconseguir copar el mercat. Contra tot el sentit comú 

de l’època, la seva aplicació estrella, el navegador WWW, es podia 

obtenir (i distribuir amb algunes limitacions) de manera gratuïta. 

Aquest fet, fins llavors insòlit dins del món empresarial, va causar certa 

sorpresa, però a la llarga va demostrar ser un encert per a l’estratègia 

de Netscape Inc., que només un gegant com Microsoft va saber tallar 

269 


ANOTACIONS


ANOTACIONS 



113] 

270 


amb una tàctica més agressiva (i probablement lesiva per a la lliure 

competència). 

El 1997, la quota de mercat de Netscape havia caigut en picat a cau- 

sa de la implantació de Microsoft Explorer, i des de Netscape Inc. es 

van estudiar noves fórmules per a tornar-la a guanyar. Un informe 

tècnic de l’enginyer Frank Hecker [hecker:setting-up- shop:98] va 

proposar que la millor solució al problema era alliberar el codi font 

del navegador i beneficiar-se dels efectes de la comunitat del progra- 

mari lliure tal com Eric Raymond descrivia en “La catedral i el basar”. 

El gener del 1998, Netscape Inc. va anunciar oficialment que allibe- 

raria el codi font del seu navegador, fet que va marcar una fita molt 

important dins de la curta història del món del programari lliure: una 

empresa estava a punt de publicar tot el codi font d’una aplicació fins 

aleshores comercial sota una llicència de programari lliure. La data 

indicada per al llançament era el 31 de març del 1998. 

En els dos mesos que van de gener a març, l’activitat a Netscape per- 

què tot estigués a punt va ser frenètica. La llista de tasques era enor- 

me i complexa. En el pla tècnic, calia entrar en contacte amb les 

empreses que hi havien fet mòduls per demanar-los el consentiment 

pel canvi de llicència; en cas de negativa, calia eliminar el mòdul. A 

més, calia reimplementar totes les parts escrites en Java, ja que es va 

considerar que Java no era lliure. Es va decidir anomenar aquest pro- 

jecte lliure Mozilla, tal com els mateixos desenvolupadors de Netscape 

anomenaven el component principal de Netscape, i es va adquirir el 

domini Mozilla.org per a construir una comunitat de desenvolupa- 

dors i col·laboradors entorn d’aquest lloc web. Al final del procés, es 

va alliberar més d’un milió i mig de línies de codi font. 

Nota 

El nom de Mozilla és un joc de paraules amb un toc 

humorístic de l’equip de desenvolupament a Netscape 

Inc. Mozilla és el producte de l’adaptació de Godzilla, 

un monstre que causava pànic en pel·lícules de terror 

japoneses des de la dècada dels cinquanta, a una for- 

ma que sonés com Mosaic Killer, ja que es pretenia 

que Mosaic quedés obsolet gràcies als avenços 

d’aquest nou navegador amb tecnologies molt més 

avançades.


D’altra banda, hi havia el pla legal. Les llicències lliures en aquell 

moment no convencien els executius de Netscape, que consideraven 

que aquestes no “congeniaven” amb el caràcter comercial d’una 

companyia. Netscape volia una llicència més “flexible” que permetés 

arribar a acords amb tercers per a incloure-hi el seu codi indepen- 

dentment de la llicència o que altres desenvolupadors comercials hi 

poguessin contribuir i alhora defensar els seus interessos econòmics 

com volguessin. I encara que al principi no s’havia previst crear una 

nova llicència, es va arribar a la conclusió que era l’única manera 

d’aconseguir el que volien. Així es va forjar la Netscape Public License 

(NPL), una llicència que es basava en els principis bàsics de les llicèn- 

cies de programari lliure, però que concedia uns drets addicionals a 

Netscape Inc. –que alhora la feien una llicència “no lliure” sota el 

prisma de la Free Software Foundation. Quan es va publicar l’esbor- 

rany de l’NPL per a la seva discussió pública, van ploure les crítiques 

sobre la clàusula de drets addicionals per a Netscape. Netscape Inc. 

va reaccionar ràpidament davant d’aquests comentaris i va crear 

una altra llicència, la Mozilla Public Licence (MPL), que era idèntica a 

l’NPL, però sense que Netscape hi tingués cap dret addicional. 

La decisió final va ser alliberar el codi de Netscape sota la llicència 

NPL, que atorgava drets addicionals a Netscape, i que el codi nou que 

s’hi inclogués sota l’MPL (o compatible). Les correccions del codi origi- 

nal (llicenciat amb l’NPL) també havien de raure sota aquesta llicència. 

Nota 

Avui dia, Mozilla accepta contribucions sota la llicèn- 

cia pròpia MPL, la GPL i l’LGPL. El canvi de llicència no 

va ser gens fàcil, ja que va caldre buscar tothom qui 

en algun moment havia contribuït al codi perquè do- 

nés el vistiplau al canvi d’NPL/MPL a MPL/GPL/LGPL. 

Per tal de poder rellicenciar tot el codi, es va crear una 

pàgina web que contenia una llista de tres-cents “des- 

envolupadors perduts”. Avui, dos anys després del 

canvi de llicència, encara se’n busquen alguns. 

El desenvolupament amb el codi original del Communicator de Net- 

scape va ser, sens dubte, més complicat del que s’esperava inicial- 

ment. Les condicions de partida ja eren dolentes en si, perquè el codi 

que es va alliberar de vegades estava incomplet (s’hi havien eliminat 

271 




apartat 32] 

ANOTACIONS 



apartat 215]


ANOTACIONS 

272 


tots els mòduls de tercers que no havien donat el vistiplau a l’allibe- 

rament) i amb prou feines funcionava. Per si no fos prou, al proble- 

ma tècnic de pretendre que Mozilla treballés sobre una gran 

quantitat de sistemes operatius i plataformes, calia afegir-hi els vicis 

adquirits de Netscape Inc., amb cicles d’alliberament llargs i inefici- 

ents per al món d’Internet i que no distingia entre els seus interessos 

i els d’una comunitat entorn de Mozilla. Tot això va comportar que, 

just un any més tard, un dels programadors més actius abans i des- 

prés de l’alliberament, Jamie Zawinsky, decidís llançar la tovallola en 

una amarga carta en què mostrava la seva desesperació i desolació. 

Malgrat tots els dubtes suscitats i l’existència periòdica de rumors que 

aboquen al fracàs el projecte Mozilla, el projecte presenta bona salut 

uns quants anys després de l’alliberament del codi. La seva versatili- 

tat i portabilitat ha propiciat que, fins i tot essent una aplicació molt 

necessitada de recursos, se’l consideri la parella d’OpenOffice.org a 

l’hora de conquerir l’escriptori de l’usuari final. Amb això, Mozilla ha 

passat per diverses fases interessants: va començar com una fita his- 

tòrica a favor de la implantació i generalització del programari lliure, 

després va patir una llarga “travessia del desert” de la qual molts 

predeien que no sortiria mai i per fi ha esdevingut un projecte amb 

perspectives de convertir-se en una aplicació d’ús ampli. Podem afir- 

mar amb un grau d’incertesa bastant baix que si Netscape Inc. no 

hagués alliberat el codi font del seu navegador al començament del 

1999, avui seria una aplicació “morta”. 

9.6.2. Estat actual de Mozilla 

El 15 de juliol del 2003, Netscape Inc. (propietat d’American On-Line) 

va anunciar que deixaria de desenvolupar el navegador Netscape i, 

per tant, la tutela activa del projecte Mozilla. Com a “liquidació”, va 

aprovar la creació de la Fundació Mozilla.org, a la qual va donar su- 

port amb una aportació de dos milions de dòlars. També es va alli- 

berar tot el codi que es trobava sota l’NPL (la llicència pública de 

Netscape) amb les llicències promulgades abans pel projecte Mozilla: 

MPL, LGPL i GPL. 

Una de les primeres conseqüències de la creació de la Fundació 

Mozilla.org va ser el canvi d’estratègia del projecte Mozilla: si abans 

prevalia la plataforma de desenvolupament que possibilitava la crea-


ció d’aplicacions d’Internet, en especial web, ara es pretén que l’en- 

focament principal sigui l’usuari final. 

9.6.3. Radiografia de Mozilla 

Les mesures que es presentaran en aquest apartat corresponen a 

l’estudi del repositori CVS del projecte Mozilla tal com es podia ob- 

tenir el 22 d’agost del 2003. Els tres milions i mig de línies de codi 

font que trobem a Mozilla fan que aquesta aplicació pugui rivalitzar 

en magnitud amb el mateix nucli Linux i OpenOffice.org com a apli- 

cació més gran de programari lliure. De fet, no tot el codi inclòs en 

el repositori CVS correspon al paquet Mozilla, perquè també s’hi in- 

clouen eines d’ajuda al desenvolupament com Tinderbox i BugZilla, 

però a grans trets, no haurien d’anar més enllà d’un 5% del total de 

les línies computades. 

Segons les estimacions del model COCOMO, una companyia que 

volgués crear un programari d’aquestes dimensions hauria d’invertir 

uns cent quaranta milions de dòlars per obtenir-lo. El temps que cal- 

dria esperar se situaria entorn dels set anys i mig i el nombre mitjà 

de programadors a temps complet que hauria d’ocupar seria de cent 

quaranta, aproximadament. 

Taula 9-11. Estat actual de Mozilla 

Pàgina web http://www.mozilla.org 


Llicència MPL/LGPL/GPL 

Versió actual 1.4 






Nombre aproximat 


140 

50 committers 

Eines d’ajuda al desenvolupament CVS, llistes de correu 

273 


ANOTACIONS


ANOTACIONS 

274 


Els llenguatges de programació més utilitzats són C++ i C, en aquest 

ordre. Tanmateix, sorprèn que cap dels dos no arribi a quotes tan al- 

tes com les que solen tenir en altres aplicacions (en què el llenguatge 

principal acostuma a tenir una quota propera al noranta per cent del 

total). Això es deu en gran part al disseny modular adoptat per Mo- 

zilla, que proporciona certes llibertats d’implementació dels mòduls, 

entre les quals hi ha la possibilitat de triar el llenguatge que es con- 

sideri més adient. Per la mateixa raó, la presència de Java –un llen- 

guatge poc freqüent en el programari lliure– en el tercer lloc no 

hauria de sorprendre tant, fins i tot tenint en compte que totes aques- 

tes línies de codi es van afegir després de l’alliberament de Netscape 

el 1998, que no tenia codi en Java. 

La presència de Perl es deu en gran part al fet que les eines d’ajuda al 

desenvolupament fetes pel projecte Mozilla com BugZilla o Tinderbox 

estan implementades en aquest llenguatge. El que sí que resulta una 

mica sorprenent és l’alt nombre de línies de codi en assemblador en 

una aplicació d’usuari final. La inspecció del codi en el repositori ha 

mostrat que, efectivament, hi ha bastants fitxers codificats en llenguat- 

ge assemblador. 

Taula 9-12. Llenguatges de programació utilitzats a Mozilla 

eLlenguatge de programació Línies de codi Percentatge 

C++ 1.928.671 54,61% 

C 1.156.594 32,75% 

Java 248.802 7,04% 

Perl 126.534 3,58% 

Lisp 23.165 0,66% 


9.7. OpenOffice.org 

OpenOffice.org és una de les aplicacions estrella del panorama 

actual del programari lliure. Es tracta d’un paquet ofimàtic multi- 

plataforma que inclou les aplicacions clau en un entorn d’escriptori 

d’oficina, com ara processador de textos (Writer), full de càlcul 

(Calc), gestor de presentacions (Impress), un programa de dibuix


(Draw), un editor de fórmules matemàtiques (Math) i finalment un 

editor de llenguatge HTML (inclòs a Writer). La interfície que ofe- 

reix el paquet OpenOffice.org és homogènia i intuïtiva, similar en 

aspecte i funcionalitats a altres paquets ofimàtics, en especial al 

més difós avui dia, Microsoft Office. 

Escrit en C++, OpenOffice.org inclou l’API de Java i té el seu propi 

sistema de components encastables, que permet, per exemple, in- 

cloure taules del full de càlcul en el processador de textos d’una ma- 

nera senzilla i intuïtiva. Entre els seus avantatges, hi ha una gran 

quantitat de formats de fitxer, inclòs el de Microsoft Office. Els seus 

formats de fitxer natius, al contrari que els del paquet ofimàtic de Mi- 

crosoft, estan basats en XML, fet que demostra una aposta clara per 

la versatilitat, la facilitat de transformació i la transparència. Avui dia, 

OpenOffice.org està traduït a més de vint-i-cinc llengües i corre en 

Solaris (el seu sistema originari), GNU/Linux i Windows. En un futur 

no gaire llunyà se n’esperen versions per a FreeBSD, IRIX i MacOS X. 

OpenOffice.org va adoptar el seu nom definitiu (OpenOffice –tal 

com ho coneix tothom– més l’afegitó .org) després d’un litigi en què 

va ser demandat per usurpació de nom de marca per una altra em- 

presa. 

9.7.1. Història d’OpenOffice.org 

A mitjan dècada dels vuitanta, es va fundar a la República Federal 

d’Alemanya l’empresa StarDivision, que tenia com a objectiu princi- 

pal la creació d’un paquet ofimàtic: StarOffice. A l’estiu del 1999, 

SUN Microsystems –amb la clara intenció d’arrabassar-li mercat a 

Microsoft– va decidir adquirir l’empresa StarDivision i apostar fort 

per StarOffice. D’aquesta manera, el juny del 2000 va llançar la ver- 

sió 5.2 de StarOffice, que es podia baixar de manera gratuïta per la 

Xarxa. 

L’èxit de StarOffice va ser limitat, ja que el mercat estava fortament 

dominat pel paquet de Microsoft. SUN va decidir canviar d’estratègia 

i, com Netscape amb el projecte Mozilla, va decidir aprofitar els 

avantatges del programari lliure per a guanyar importància i implan- 

tació. Així, les versions futures de StarOffice (producte propietari de 

275 


ANOTACIONS


ANOTACIONS 

276 


SUN) es van crear utilitzant OpenOffice.org (producte lliure) com a 

font, respectant les interfícies de programació (API), els formats de fit- 

xer i servint com a implementació de referència. 

9.7.2. Organització d’OpenOffice.org 

OpenOffice.org pretén tenir una estructura decisòria en la qual tots els 

membres de la comunitat se sentin partícips. Per això, s’ha ideat un 

sistema perquè la presa de decisions tingui el màxim consens possible. 

El projecte OpenOffice.org es divideix en una sèrie de subprojectes 

que tenen assignats uns membres del projecte, els col·laboradors, i un 

únic líder. Per descomptat, tant els membres com el líder d’un projecte 

també poden participar en d’altres. Tanmateix, només es pot liderar 

un projecte al mateix temps. Els projectes, al seu torn, es divideixen en 

tres categories: 

• Projectes acceptats: tant poden ser de caràcter tècnic com no. Els 

líders de cada projecte acceptat compten un vot a l’hora de pren- 

dre decisions globals. 

• Projectes native-lang: tots els projectes d’internacionalització i 

localització d’OpenOffice.org. Avui dia, com s’ha dit, hi ha més 

de vint-i-cinc equips que treballen per traduir les aplicacions 

d’OpenOffice.org a les diferents llengües i convencions. En con- 

junt, native-lang compta un únic vot en la presa de decisions globals. 

• Projectes a la incubadora: es tracta de projectes patrocinats per la 

comunitat (generalment experimentals o petits). Es poden acceptar 

després d’un període de sis mesos. D’aquesta manera, la comuni- 

tat OpenOffice.org pot garantir que els projectes acceptats comp- 

ten amb el suport d’un interès real, ja que la “mortalitat” de 

projectes en el món del programari lliure és molt gran. En total, els 

projectes a la incubadora compten un vot en la presa de decisions. 

9.7.3. Radiografia d’OpenOffice.org 

El paquet d’ofimàtica OpenOffice.org es compon de prop de quatre 

milions de línies de codi font, distribuïdes en quaranta-cinc mil fitxers.


El model COCOMO estima que l’esforç necessari per a fer un clon 

d’OpenOffice.org representaria cent cinquanta programadors tre- 

ballant a temps complet durant gairebé vuit anys. El cost de desen- 

volupament ascendiria, segons les estimacions de COCOMO, a uns 

cent seixanta milions de dòlars. 

Els resultats que es comenten en aquest apartat s’han obtingut de 

l’estudi del repositori CVS del projecte OpenOffice.org del 20 d’abril 

del 2003. 

Taula 9-13. Estat actual d’OpenOffice.org 

Pàgina web http://www.OpenOffice.org 

Inici del projecte Juny del 2000 (primera versió lliure) 

Llicència LGPL i SISSL 

Versió actual 1.0.3 (en desenvolupament la 1.1) 




Estimació de temps d’execució 8 anys (95 mesos) 





150 

El primer lloc en els llenguatges de programació utilitzats a 

l’OpenOffice.org l’ocupa C++. És interessant observar que l’adqui- 

sició per part de SUN comporta la integració de molt codi Java al pa- 

quet ofimàtic, que fins i tot supera el C. De la resta de llenguatges més 

utilitzats, cal fer una menció especial del Pascal, ja que sol ser un llen- 

guatge poc utilitzat en el món del programari lliure i, en general, en 

la producció industrial de programari. 

200 committers 


Taula 9-14. Llenguatges de programació utilitzats en OpenOffice.org 


C++ 3.361.765 85,03% 

Java 251.191 6,35% 

C 222.533 5,63% 

Pascal 32.407 0,82% 

Perl 28.380 0,72% 

277 


ANOTACIONS


ANOTACIONS 



apartat 180] 

278 


9.8. Red Hat Linux 

Red Hat Linux va ser una de les primeres distribucions comercials de 

GNU/Linux. Avui dia n’és probablement una de les més conegudes, 

i segurament la que es pot considerar “canònica” d’entre les distri- 

bucions comercials. La feina dels distribuïdors es relaciona bàsica- 

ment amb tasques d’integració, i no tant, amb el desenvolupament 

de programari. Per descomptat, tant Red Hat com altres distribuci- 

ons poden tenir desenvolupadors entre els seus empleats, però la 

tasca d’aquests és secundària per als objectius de distribució. En ge- 

neral, s’assumeix que la feina que fan les distribucions és simplement 

prendre els paquets font (generalment els arxius que els mateixos 

desenvolupadors publiquen) i empaquetar-los de manera que com- 

pleixin uns criteris determinats (tant tècnics com organitzatius). El pro- 

ducte d’aquest procés és una distribució: una sèrie de paquets 

convenientment organitzats que possibiliten que l’usuari els instal·li, 

desinstal·li i actualitzi. 

Les distribucions també són responsables de la qualitat del producte 

acabat, un aspecte molt important tenint en compte que moltes de 

les aplicacions que inclouen han estat elaborades per voluntaris en 

el temps lliure. Per tant, els aspectes de seguretat i estabilitat són molt 

importants per a una distribució. 

9.8.1. Història de Red Hat 

Red Hat Software Inc. va ser fundada el 1994 per Bob Young i Marc 

Ewing. El seu principal objectiu era compilar i comercialitzar una dis- 

tribució GNU/Linux, que es va anomenar (i encara s’hi diu) Red Hat 

Linux [young:giving-it-away:99]. Bàsicament, es tractava d’una 

versió empaquetada del que hi havia a la Xarxa en aquells temps, 

incloent-hi documentació i suport. Durant l’estiu del 1995, va veu- 

re la llum la versió 1.0 d’aquesta distribució. Uns quants mesos més 

tard, a la tardor, se’n va publicar la versió 2.0, que incloïa la tecno- 

logia RPM (RPM package manager, gestor de paquets RPM). El siste- 

ma de paquets RPM s’ha convertit en un estàndard de facto per als 

paquets de sistemes GNU/Linux. El 1998 Red Hat va arribar al gran 

públic amb la versió 5.2. Per a una història completa dels noms de 

les diferents versions de Red Hat, vegeu Stephen J. Smoogen. The 

truth behind Red Hat names.


Nota 

Des de la versió 1.1 del Linux Standard base (una espe- 

cificació que té com a objectiu aconseguir compatibilitat 

binària entre les distribucions GNU/Linux de què s’en- 

carrega el Free Standards Group), RPM ha estat escollit 

com el sistema de paquets estàndard. El projecte Debian 

continua amb el seu format de paquet propi, com tam- 

bé moltes de les distribucions dependents del sistema de 

paquets Debian, i s’ajusten al format estandarditzat mit- 

jançant una eina de conversió que s’anomenava alien. 

Abans del sistema de gestió de paquets RPM, gairebé totes les distribu- 

cions de GNU/Linux oferien la possibilitat d’instal·lar el programari 

mitjançant un procediment guiat per menús; però modificar una ins- 

tal·lació, especialment agregar paquets de programari nous després 

de la instal·lació, no era una tasca fàcil. RPM va permetre fer aquest 

pas més enllà de l’estat de la tècnica en proveir als usuaris la possibi- 

litat de gestionar els paquets, la qual cosa permetria esborrar, ins- 

tal·lar o actualitzar qualsevol paquet de programari de la distribució 

d’una manera molt més senzilla. El sistema de paquets RPM continua 

essent el més utilitzat entre les diferents distribucions de GNU/Linux. 

Les estadístiques de Ladislav Bodnar (2003, Linux distributions - facts 

and figures, un lloc web que conté informació qualitativa i quantitativa 

sobre un gran nombre de distribucions), mostren que el maig del 2003 

una gran majoria de les cent divuit distribucions computades utilitzen 

el gestor RPM, en total seixanta-cinc (que és aproximadament un 55% 

del total). En comparació, únicament setze distribucions (un 14% del 

total) utilitzen el sistema de paquets Debian (conegut com deb). 

Tanmateix, Red Hat Inc. no solament és coneguda per la distribu- 

ció de programari basada en Linux. L’agost del 1999, Red Hat va 

sortir a borsa i les seves accions van obtenir el vuitè guany de pri- 

mer dia més gran en tota la història de Wall Street. Quatre anys 

més tard, el valor de les accions de Red Hat rau entorn d’una cen- 

tena part del valor màxim que havia assolit abans de la crisi de 

les puntcom. Tot i així, els seus començaments fulgurants en el 

mercat de valors van servir perquè Red Hat fos portada de diaris i 

revistes no directament relacionats amb temes informàtics. En 

qualsevol cas, sembla que Red Hat ha sabut superar els proble- 

279 





ANOTACIONS


ANOTACIONS 



apartat 194] 

280 


mes d’altres companyies del món dels negocis entorn del progra- 

mari lliure i en l’últim quart de l’any 2002 va anunciar nombres 

positius per primera vegada en la seva història. 

Un altre dels fets històrics més importants de Red Hat va ser l’adqui- 

sició de Cygnus Solutions el novembre del 1999, una empresa fun- 

dada una dècada abans i que ja havia demostrat que amb una 

estratègia integral basada en programari lliure es poden guanyar di- 

ners. Cygnus va escollir l’exigent mercat dels compiladors per a fer- 

s’hi un racó. La seva estratègia comercial es basava en el desenvo- 

lupament i l’adaptació de les eines de desenvolupament de progra- 

mari GNU (bàsicament GCC i GDB) a petició del client. 

9.8.2. Estat actual de Red Hat 

Els productes estrella de Red Hat Inc. avui dia són Red Hat Linux 

9 i Red Hat Network, un servei d’actualització de programari per 

la Xarxa. Aquest tipus de serveis estan més aviat orientats a l’usuari 

final, i no tant a l’entorn empresarial, però serveixen a Red Hat 

com a bon reclam i per a assegurar l’estratègia de marca. 

L’”autèntica” estratègia comercial de Red Hat rau en els seus pro- 

ductes orientats al món empresarial. Aquest tipus de productes 

són molt menys coneguts, però representen el gruix de la factura- 

ció de Red Hat, molt superior a la que percep pels seus productes 

estrella, més populars en el sentit literal. 

Red Hat té una distribució orientada a l’empresa, integrada a l’en- 

torn d’un servidor d’aplicacions i anomenada Red Hat Enterprise 

Linux AS. Amb l’adquisició d’aquest programari, el client té dret a 

manteniment. El servei anàleg a Red Hat Network per a usuaris co- 

mercials és Red Hat Enterprise Network, que inclou la gestió del sis- 

tema i la possibilitat d’actualitzacions. D’altra banda, Red Hat també 

ofereix serveis de consultoria informàtica i un programa de certifica- 

ció similar al que hi ha en el món Windows i ofert per Microsoft.

9.8.3. Radiografia de Red Hat 


Red Hat ha superat recentment la barrera dels cinquanta milions de 

línies de codi, que la converteixen en una de les distribucions més 

grans de programari que mai han existit –i superen, com veurem més 

endavant, la mida de sistemes operatius propietaris. La versió 8.1 de 

Red Hat estava constituïda per set-cents noranta-dos paquets i po- 

dem assumir que també haurà franquejat el llistó dels vuit-cents pa- 

quets en l’última versió, tenint en compte que aquest nombre se sol 

incrementar en cada versió. 

Com en els casos anteriors, s’ha aplicat el model COCOMO per a 

estimar la inversió i l’esforç que caldria per a la generació d’un pro- 

gramari d’igual magnitud. Tanmateix, en el cas de Red Hat s’ha tin- 

gut en compte que es tracta d’un producte fet a partir d’una colla 

d’aplicacions independents. Per això, se n’ha fet una estimació amb 

COCOMO independent per cada un dels paquets de Red Hat per a, 

després, sumar-hi el cost i el personal totals necessaris. En el cas de 

Red Hat, s’ha considerat el temps d’execució òptim del paquet més 

gran, ja que idealment tots els paquets són independents i es podrien 

executar en paral·lel en el temps. És per això que el temps d’execució 

òptim per a Red Hat és semblant al dels projectes que hem presentat 

en aquest capítol. 

Segons COCOMO, es necessitarien aproximadament set anys i mig 

i un equip de programadors compost per una mitjana de mil vuit- 

cents desenvolupadors per a fer la distribució Red Hat Linux 8.1 des 

de zero. El cost del desenvolupament final ascendiria a uns mil vuit- 

cents milions de dòlars. 

Nota 

1.800 milions de dòlars és el pressupost que el Minis- 

teri de Defensa espanyol ha destinat a renovar la seva 

flota d’helicòpters. De tot l’import, la meitat va desti- 

nada a l’adquisició de 24 helicòpters, de manera que 

el preu de Red Hat seria l’equivalent a 48 helicòpters 

de combat. Així mateix, 1.800 milions de dòlars és 

la xifra dels beneficis a nivell mundial de la pel·lícula 

Titanic. 

281 


ANOTACIONS


ANOTACIONS 

282 


Taula 9-15. Estat actual de Red Hat Linux 

Pàgina web http://www.redhat.com 


Llicència 

Versió actual 9.0 

Línies de codi font Més de 50.000.000 

Nombre de paquets 792 

Estimació de cost $ 1,800,000,000 

Estimació de temps d’execució 7,35 anys (88.25 mesos) 

Estimació de nombre mig 


Número aproximat 


La classificació de llenguatges en Red Hat té més diversitat que les 

que hem vist en les aplicacions de programari lliure més importants, 

pel gran nombre de paquets. En termes generals, es percep (taula 

9-16) la importància de C, amb més d’un seixanta per cent de les 

línies de codi. En segon lloc hi ha C++, amb més de deu milions 

de línies de codi, seguit de lluny per Shell. És interessant observar 

que a Perl s’hi uneixen després Lisp (sobretot a causa de l’ús a 

Emacs), el codi en assemblador (una quarta part del qual correspon 

al que ve amb Linux) i un llenguatge en clar retrocés pel que fa a 

l’ús, com és Fortran. 

1.800 

Empleats de Red Hat (generalment 

només integració) 


Taula 9-16. Llenguatges de programació utilitzats en Red Hat 


C 30.993.778 62,13% 

C++ 10.216.270 20,48% 

Shell 3.251.493 6,52% 

Perl 1.106.082 2,22% 

Lisp 958.037 1,92% 


Fortran 532.629 1,07%

9.9. Debian GNU/Linux 


Debian és un sistema operatiu lliure que avui dia es distribueix 

amb el nucli de Linux (encara que s’espera que hi hagi distribuci- 

ons Debian basades en altres nuclis, com és el cas en The HURD, en 

el futur). Actualment està disponible per a diverses arquitectures di- 

ferents, incloses Intel x86, ARM, Motorola, 680 x 0, PowerPC, Alpha 

i SPARC. 

Debian no és només la distribució GNU/Linux més gran avui dia, 

sinó també una de les més estables i gaudeix de diversos premis 

quant a preferència dels usuaris. Encara que la seva base d’usuaris 

sigui difícil d’estimar, ja que el projecte Debian no ven CD o altres 

mitjans amb el seu programari, i qualsevol en pot redistribuir el pro- 

gramari no aniriem gaire errats si suposem que es tracta d’una dis- 

tribució important dins del mercat de GNU/Linux. 

A Debian hi ha una categorització segons la llicència i els requisits de 

distribució dels paquets. El nucli de la distribució Debian (la secció 

anomenada main, que aglutina una gran varietat de paquets) està 

compost només per programari lliure d’acord amb les Debian Free 

Software Guidelines. Està disponible a Internet i molts redistribuïdors 

el venen en CD o altres mitjans. 

Prop d’un miler de voluntaris (generalment professionals de la infor- 

màtica) creen les distribucions de Debian. La tasca d’aquests volun- 

taris consiteix a configurar, compilar i empaquetar els programes 

font –la majoria de vegades dels seus autors originals–, de manera 

que un usuari típic d’una distribució Debian només hagi de seleccio- 

nar el paquet perquè el sistema l’afegeixi sense més problemes. Això, 

que a cop d’ull pot semblar simple, es torna força complex quan s’in- 

trodueixen els factors com ara les dependències entre els diferents pa- 

quets (el paquet A necessita el paquet B per a poder funcionar) i les 

diferents versions de cadascun. 

La tasca dels integrants del projecte Debian és la mateixa que en 

qualsevol altra distribució: la integració de programari perquè funci- 

oni correctament en conjunt. A més de la tasca d’adaptació i empa- 

283 




85] 

ANOTACIONS


ANOTACIONS 



apartat 87] 



apartat 86] 

284 


quetatge, els desenvolupadors Debian s’encarreguen del manteniment 

d’una infraestructura de serveis basats en Internet (lloc web, arxius en 

línia, sistema de gestió d’errors, llistes de correu d’ajuda, suport i 

desenvolupament, etc.), de diversos projectes de traducció i interna- 

cionalització, del desenvolupament de diverses eines específiques de 

Debian i, en general, de qualsevol element que la distribució Debian 

possibiliti. 

El projecte Debian, a part de la seva naturalesa voluntària, té una ca- 

racterística que el fa especialment singular: el contracte social de De- 

bian. Aquest document conté no solament els objectius principals del 

projecte Debian, sinó també els mitjans que s’utilitzaran per a dur- 

los a terme. 

Debian també és coneguda per la seva estricta política de paquets 

i versions, a fi d’aconseguir més qualitat del producte. Així, en tot 

moment Debian presenta tres sabors diferents: una versió estable, 

una d’inestable i una altra en proves. La versió estable, com el seu 

nom indica, és la indicada per a sistemes i persones no aptes per 

a sobresalts. El seu programari ha de passar un període de con- 

gelació en què només s’hi corregeixen errors. La norma és que en 

la versió estable de Debian no hi ha d’haver cap error crític cone- 

gut. Per contra, la versió estable de Debian no sol tenir les últimes 

versions del programari (el més nou). 

Per als qui vulguin tenir una versió amb el programari més actual 

hi ha dues versions més de Debian, coetànies de l’estable. La ver- 

sió inestable inclou paquets en via d’estabilització, mentre que la 

versió en proves és, com el seu nom indica, la més procliu a fallar 

i conté les últimes novetats pel que fa a programari. 

En el moment de redactar aquestes línies, la versió estable de Debian 

és la 3.0 (també coneguda com Woody), la inestable rep el sobrenom 

de Sid i la que es troba en proves és Sarge. Però en el passat, Woody 

va passar també per una etapa inestable i, abans d’això, per una altra 

etapa en proves. Això és important de tenir-ho present, perquè aquí 

considerarem les diferents versions estables de Debian des que es va 

publicar la versió 2.0 cap al 1998. Així, tenim Debian 2.0 (àlies


Hamm), Debian 2.1 (Slink), Debian 2.2 (Potato) i, finalment, Debian 

3.0 (Woody). 

9.9.1. Radiografia de Debian 

Com en el cas de Red Hat, el producte de programari final de Debian 

presenta resultats astronòmics. L’última versió estable de Debian, la 

versió 3.0 que va rebre el sobrenom de Woody, té 4.579 paquets 

font i entorn de deu mil paquets binaris. Arran d’aquests resultats 

podem considerar que Debian és la col·lecció de programari inte- 

grat més gran i que és probable que, a causa de la seva magnitud, 

s’hagi d’enfrontar en un futur no gaire llunyà a possibles problemes 

d’integració. 

Nota 

Els sobrenoms de les versions de Debian corresponen 

als protagonistes de la pel·lícula de dibuixos animats 

Toy Story, una tradició que es va implantar mig en 

broma quan se’n va publicar la versió 2.0 i Bruce 

Perens, l’aleshores líder del projecte i després fundador 

de l’Open Source Initiative i del terme Open Source, tre- 

ballava per a l’empresa que s’encarregava de realitzar 

aquesta pel·lícula. Es poden trobar més detalls sobre la 

història de Debian i la distribució Debian en general a 

Bdale Garbee; Hartmut Koptein; Nils Lohner; Will Lowe; 

Bill Mitchell; Ian Murdock; Martin Schulze; Craig Small, A 

brief history of Debian, al paquet Debian-history. 

El nombre de línies de codi a Debian 3.0 arriba a cent cinc milions. 

Segons el model COCOMO caldria desemborsar una quantitat 

aproximada de tres mil sis-cents milions de dòlars per a obtenir un 

programari com el que ve empaquetat amb aquesta distribució. 

Igual que en el cas de Red Hat, s’ha computat per separat l’esforç 

necessari per a cada paquet i després se n’han sumat totes les quan- 

titats. Per la mateixa raó, el temps de desenvolupament de Debian 

només són set anys, ja que es considera que cada paquet es pot exe- 

cutar en paral·lel als altres en el temps. Això sí, caldria mobilitzar 

285 




apartat 100] 

ANOTACIONS


ANOTACIONS 

286 


prop de quatre mil desenvolupadors de mitjana durant aquests set 

anys. 

El llenguatge de programació més utilitzat en Debian 3.0 és C, amb 

més d’un 60% de les línies de codi. Tanmateix, la importància de C 

remet amb el temps, ja que les primeres versions de Debian comp- 

taven fins i tot amb un 80% del codi en C. Bona part de la “culpa” 

d’aquest retrocés és del segon en qüestió, C++, però sobretot, de la 

irrupció dels llenguatges de guió (scripting) com Perl, Python i –enca- 

ra que no figura en aquesta taula– de PHP. Entremig, s’hi escolen 

llenguatges com Lisp o com l’una mica més exòtic Fortran. 

Nota 

3.600 milions de dòlars és el pressupost que té assig- 

nat el VI Programa Marc de la Comissió Europea per 

a activitats d’investigació i desenvolupament relacio- 

nades amb la Sociedad de la Informació. També és la 

xifra que Telefónica preveu invertir a Alemanya per a 

implantar UMTS. 

Taula 9-17. Estat actual de Debian 

Pàgina web http://www.debian.org 

Inici del projecte 16.8.1993 

Llicència Les que compleixin les DFSG 

Versió actual de Debian Debian 3.0 (àlies Woody) 


Nombre de paquets 4.579 

Estimació de cost 3.625.000.000 $ 

Estimació de temps d’execució 7 anys 

Estimació de nombre mig 


Número aproximat de 

desenvolupadors (maintainers) 


Prop de 3.950 

Prop de mil 

Llistes de correu, sistema 

de notificació d’errors


Taula 9-18. Llenguatges de programació utilitzats en Debian GNU/Linux 


C 66.549.696 63,08% 

C++ 13.066.952 12,39% 

Shell 8.635.781 8,19% 

Lisp 4.087.269 3,87% 

Perl 3.199.436 3,03% 

Fortran 1.939.027 1,84% 

Python 1.458.783 1,38% 

En la taula 9-19 es mostra l’evolució dels llenguatges més significa- 

tius –els que superen l’1% de codi– en Debian 3.0. Per sota de la 

frontera de l’1% s’hi situen, en aquest ordre, PHP, Ada, Modula3, 

Objective C, Java, Yacc i ML (tots amb percentatges entre el 0,30% i 

el 0,60%). 

Taula 9-19. Llenguatges més utilitzats en Debian 

Hi ha llenguatges que podríem considerar minoritaris que aconse- 

gueixen un lloc bastant alt en la classificació. Això es deu al fet que 

fins i tot trobant-se presents en un nombre reduït de paquets, aquests 

són bastant grans. Aquest és el cas d’Ada, que en tres paquets 

(gnat, un compilador d’Ada, libgtkada, un enllaç a la biblioteca 

GTK, i asis, un sistema per a gestionar fonts a Ada) n’aglutina qua- 

tre-cents trenta mil d’un total de cinc-cencs setanta-sis mil línies de 

codi font que s’ha comptabilitzat en Debian 3.0 per a Ada. Un altre 

cas semblant és el de Lisp, que només disposa de GNU Emacs i Xe- 

287 


Llenguatge Debian 2.0 Debian 2.1 Debian 2.2 Debian 3.0 

C 19.400.000 76,67% 27.800.00 74,89% 40.900.000 69,12% 66.500.000 63,08% 

C++ 1.600.000 6,16% 2.800.000 7,57% 5.980.000 10,11% 13.000.000 12,39% 

Shell 645.000 2,55% 1.150.000 3,10% 2.710.000 4,59% 8.635.000 8,19% 

Lisp 1.425.000 5,64% 1.890.000 5,10% 3.200.000 5,41% 4.090.000 3,87% 

Perl 425.000 1,68% 774.000 2,09% 1.395.000 2,36% 3.199.000 3,03% 

Fortran 494.000 1,96% 735.000 1,98% 1.182.000 1,99% 1.939.000 1,84% 

Python 122.000 0,48% 211.000 0,57% 349.000 0,59% 1.459.000 1,38% 

Tcl 311.000 1,23% 458.000 1,24% 557.000 0,94% 1.081.000 1,02% 

ANOTACIONS


ANOTACIONS 

288 


macs, amb més d’1.200.000 línies dels aproximadament quatre mi- 

lions de tota la distribució. 

9.9.2. Comparació amb altres sistemes operatius 

Si es diu que totes les comparacions són odioses, les de programari 

lliure amb programari propietari ho són més. Les radiografies tan 

detallades de Red Hat Linux i Debian han estat possibles per la seva 

condició de programari lliure. L’accés al codi (i a la resta d’informa- 

ció que ha estat exposada en aquest capítol) és indispensable per es- 

tudiar a fons les diferents versions pel que fa al nombre de línies, 

paquets, llenguatges de programació utilitzats, etc. Però els avantat- 

ges del programari lliure van més enllà perquè, a més, faciliten la re- 

visió de terceres persones, tant si són grups d’investigació com 

senzillament persones interessades. 

En general, els sistemes propietaris, en fer un estudi així és una tasca 

impossible. De fet, els comptes que s’ofereixen a continuació tenen 

les seves fonts en les mateixes companyies que hi ha al darrere del 

desenvolupament de programari, per la qual cosa no podem avalar- 

ne la veracitat. Per a més inri, moltes vegades no sabem si s’està par- 

lant de línies de codi font físiques tal com hem fet durant aquest ca- 

pítol o també hi inclouen les línies en blanc i les de comentaris. 

Tampoc no sabem amb seguretat què consideren en el programari, 

de manera que, per a algunes versions de Microsoft Windows, no sa- 

bem si inclouen el paquet de Microsoft Office o no. 

En qualsevol cas, i tenint en compte tot el que s’ha comentat en pa- 

ràgrafs anteriors, pensem que incloure aquesta comparació és inte- 

ressant, ja que ens ajuda a situar les diferents distribucions de Red 

Hat i de Debian dins d’un panorama més ampli. El que sembla estar 

fora de tot dubte és que tant Debian com Red Hat, però especialment 

el primer, són les col·leccions de programari més grans vistes mai 

fins al moment. 

Les xifres que es presenten a continuació procedeixen de Mark Lucovsky 

(2000), From NT OS/2 to Windows 2000 and beyond - a software- 

engineering odyssey (per a Windows 2000); SUN Microsystems


(2000), Sun Microsystems announces availability of StarOffice(TM) 

source code on OpenOffice.org (per a StarOffice 5.2); Gary McGraw, 

“Building secure software: How to avoid security problems the right 

way”, a: David A. Wheeler (per a Windows XP) i Bruce Schneier (2000), 

Software complexity and security (per a la resta de sistemes). En la tau- 

la 9-20 es mostra la comparació en ordre creixent. 

Taula 9-20. Comparació amb sistemes propietaris 

Sistema 

Data 

de publicació 

Línies de codi 

(aprox.) 

Microsoft Windows 3.1 Abril 1992 3.000.000 

SUN Solaris 7 Octubre 1998 7.500.000 

SUN StarOffice 5.2 Juny 2000 7.600.000 

Microsoft Windows 95 Agosto 1995 15.000.000 

Red Hat Linux 6.2 Marzo 2000 18.000.000 

Debian 2.0 Julio 1998 25.000.000 

Microsoft Windows 2000 Febrero 2000 29.000.000 

Red Hat Linux 7.1 Abril 2001 32.000.000 

Debian 2.1 Marzo 1999 37.000.000 

Windows NT 4.0 Julio 1996 40.000.000 

Red Hat Linux 8.0 Septiembre 2002 50.000.000 

Debian 2.2 Agosto 2000 55.000.000 

Debian 3.0 Julio 2002 105.000.000 

289 




147, 150, 148 i 179] 

ANOTACIONS

Bibliografia 


[1] About issues. http://www.openoffice.org/project_issues.html 

[2] Ada core technologies. http://www.gnat.com 

[3] Aegis. http://aegis.sourceforge.net/index.html 

[4] Alcove. http://www.alcove.com 

[5] Alcove-labs. http://www.alcove-labs.org 

[6] Alioth. http://alioth.debian.org 

[7] The apache ant project. http://ant.apache.org 

[8] Arch revision control system. http://arch.fifthvision.net/bin/view 

[9] artofcode LLC. http://artofcode.com 

[10] Autoconf. http://www.gnu.org/software/autoconf 

[11] Barrapunto. http://barrapunto.com 

[12] Berlios: The open source mediator. http://berlios.de. 

[13] Bitkeeper source management. http://www.bitmover.com/bitkeeper 

[14] Bruce perens. http://perens.org/OpenStandards 

[15] Caldera. http://www.sco.com 

[16] Cisco enterprise print system. http://ceps.sourceforge.net 

[17] Concurrent version system. http://www.cvshome.org 

[18] Creative commons. http://creativecommons.org 

[19] Directory of open access journals. http://www.doaj.org 

291 


ANOTACIONS


ANOTACIONS 

292 


[20] ecos. http://sources.redhat.com/ecos 

[21] ecos license 2.0. http://www.gnu.org/licenses/ecos-license.html 

[22] First monday: Peer rewiewed journal on the internet. 

http://www.firstmonday.dk 

[23] Free Software Foundation. http://www.fsf.org 

[24] Fundación wu ming. http://www.wumingfoundation.com 

[25] G-forge. http://gforge.org 

[26] Gettext. http://www.gnu.org/software/gettext 

[27] GNU automake. http://www.gnu.org/software/automake 

[28] GNU libc. http://www.gnu.org/software/libc 

[29] GNU libtool. http://www.gnu.org/software/libtol 

[30] GNU make. http://www.gnu.org/software/make/make.html 

[31] GNU troff. http://www.gnu.org/software/groff/groff.html 

[32] Have you seen these hackers? 

http://www.mozilla.org/MPL/missing.html 

[33] History of tex. http://www.math.utah.edu/software/plot79/tex/history.html 

[34] IBM public license version 1.0.http://oss.software.ibm.com/developerworks/ 

opensource/license10.html 

[35] Jam product information. http://www.perforce.com/jam/jam.html 

[36] The Linux documentation project. http://www.tldp.org 

[37] LinuxCare. http://www.linuxcare.com 

[38] Mailman, the GNU mailing list manager. http://www.list.org 

[39] Mozilla public license 1.1. http://www.mozilla.org/MPL/MPL-1.1.html 

[40] Mozilla TINDERBOX. http://www.mozilla.org/tinderbox.html

[41] Open cores. http://www.opencores.org 

[42] Open directory project social contract 

[43] Open Source Initiative. http://www.opensource.org 


[44] Public development cluster. http://handhelds.org/projects/skiffclus- ter.html 

[45] Public library of science. http://www.publiclibraryofscience.org 

[46] Red hat. http://www.redhat.com 

[47] Savannah. http://savannah.gnu.org i http://savannah.nongnu.org 

[48] Slashdot: news for nerds. http://slashdot.org 

[49] Sleepycat license. http://www.sleepycat.com/download/oslicense.html 

[50] Sleepycat software. http://www.sleepycat.com 

[51] Sourceforge: Open source software development website. 

http://sourceforge.net 

[52] Subversion. http://subversion.tigris.org 

[53] TeXinfo - the GNU documentation system 

[54] Tigris.org: Open source software engineering. http://tigris.org 

[55] W3c document license. http://www.w3.org/Consortium/Legal/2002/ 

copyright-documents-20021231 

[56] Wikipedia. http://www.wikipedia.org 

[57] X window system release 11 license. 

http://www.x.org/Downloads_terms.html 

[58] Ximian. http://ximian.com/ 

[59] Zope corporation. http://www.zope.com/ 

[60] Zope public license 2.0. http://www.zope.org/Resources/ZPL 

293 


ANOTACIONS


ANOTACIONS 

294 


[61] Ley de Propiedad Intelectual. Reial decret legislatiu 1/1996, de 12 

d’abril de 1996 

[62] Affero general public license (2002). http://www.affero.org/oagpl.html 

[63] ISO JTC 1/SC 34 (1986). Standard generalized markup language 

(SG- ML, iso 8879). 

[64] I. Antoniades; I. Samoladas; I. Stamelos; G.L. Bleris. Dynamical simulati- 

on models of the open source development process. A: Koch. 

http:// wwwai.wuwien.ac.at/˜koch/oss-book. 

[65] Edward C. Bailey (1998). Maximum rpm - taking the red hat package 

manager to the limit. http://rikers.org/rpmbook/ 

[66] Jesús M. González Barahona (2000). “Software libre, monopolios 

y otras yerbas”. Todo Linux (núm. 3). 

http://sinetgy.org/˜jgb/articulos/soft-libre-monopolios 

[67] Jesús M. González Barahona (2002). “¿Qué se hace con mi dinero?”. 

Todo Linux (vol. 17). http://sinetgy.org/˜jgb/articulos/sobre-administracion 

[68] Jesús M. González Barahona; Gregorio Robles. Libre software enginee- 

ring web site. http://libresoft.dat.escet.urjc.es 

[69] Jesús M. González Barahona; Gregorio Robles (maig, 2003). 

“Unmounting the “code god” assumption”. A: Proceedings of the Fourth 

International Conference on eXtreme Programming and Agile Processes in 

Software Engineering. Itàlia: Gènova. 

[70] Jesús M. González Barahona; Gregorio Robles; Miguel A. Ortuño 

Pérez. “Anatomy of two GNU/ Linux distributions”. A: Koch. 

http://wwwai.wuwien.ac.at/˜koch/oss-book 

[71] Matthew P. Barnson. The bugzilla guide. 

http://www.bugzilla.org/ docs214/html/index.html 

[72] Nikolai Bezroukov (desembre, 1998). “A second look at the cathedral 

and the bazaar”. First Monday (vol. 12, núm.4). 

http://www.firstmonday.dk/ issues/issue4_12/bezroukov/index.html 

[73] Ladislav Bodnar (2003). Linux distributions - facts and figures. 

http:// www.distrowatch.com/stats.php?section=packagemanagement


[74] Barry W. Boehm (1981). Software Engineering Economics. Prentice Hall. 

[75] Legal resources and tools for surviving the bad patents. 

http://www.bus- patents.com 

[76] S. Bradner (oct.,1996). The internet standards process - revision 3 

(rfc 2026, bcp 9). http://www.ietf.org/rfc/rfc2026.txt 

[77] Per Cederqvist and GNU (1993). CVS-concurrent versions system. 

http:/ /www.gnu.org/manual/cvs/index.html 

[78] Ward Cunningham. Wiki design principles 

[79] Loic Dachary (2001). Savannah the next generation. 

http://savannah.gnu.org/docs/savannah-plan.html 

[80] Junta de Andalucía. Decret 72/2003, de 18 de març, de mesures 

d’impuls de la societat del coneixement a Andalusia. març, 2003. 

http://boja.andaluciajunta.es/boja/cgi-bin/frame_pagina.cgi?2003-55-8 

[81] Adam de Boor. Pmake - a tutorial. 

http://docs.freebsd.org/44doc/psd/ 12.make/paper.html 

[82] Miguel de Icaza. The story of the gnome project. 

http://primates.ximian.com/˜miguel/gnome-history.html 

[83] Senat de la República Francesa. Forum sur la proposition de loi tendant 

a généraliser dans l’administration l’usage d’internet et de logiciels libres. 

http://www.senat.fr/consult/loglibre/index.htm 

[84] Pedro de las Heras Quirós; Jesús M. González Barahona (2000). 

“Iniciativas de las administraciones públicas con relación al software li- 

bre”. Bole.TIC, revista de ASTIC (vol. 14). 

[85] Debian. Debian free software guidelines. 

http://www.debian.org/ social_contract.html#guidelines 

[86] Debian. Debian policy manual. 

http://www.debian.org/doc/debian-policy 

[87] Debian. Debian social contract. 

http://www.debian.org/social_contract.html 

[88] Schriftenreihe der KBSt (juliol, 2003). Leitfaden für die migration von 

basissoftwarekomponenten auf serverund arbeits-platzsystemen. Technical 

295 


ANOTACIONS


ANOTACIONS 

296 


report, Koordinierungs-und Beratungsstelle der Bundesregierung für 

Informations-technik in der Bundesverwaltung (KBSt). 

http://www.kbst.bund.de/download/mlf_v1_de.pdf 

[89] Chris DiBona; Sam Ockman; Mark Stone (ed.) (1999). Open Sources. 

Voices from the Open Source Revolution. O’Reilly & Associates. 

http://www.oreilly.com/catalog/opensources 

[90] Open directory project. http://dmoz.org 

[91] Justin R. Ehrenkrantz (maig, 2003). “Release management within open 

source projects”. A: Proceedings of the 3rd Works-hop on Open Source 

Software Engineering at the 25th International Conference on Software 

Engineering. EUA: Portland. 

[92] Consell Europeu (1991). Directiva 91/250/cee del Consell, de 14 de 

maig de 1991, relativa a la protecció jurídica de programes d’ordinador. 

http://europa.eu.int/scadplus/leg/es/lvb/l26027.htm 

[93] Karl Fogel; Moshe Bar (2001). Open Source Code Development with 

CVS (2ª. ed.). Paragliph Press. http://cvsbook.red-bean.com 

[94] Electronic Frontier Foundation. Open audio. 

http://www.eff.org/IP/Open_licenses/eff_oal.html 

[95] Free Software Foundation (1985). The GNU manifesto. 

http://www.gnu.org/philosophy 

[96] Free Software Foundation (juny 1991). Gnu general public license, 

version 2. http://www.fsf.org/licenses/gpl.html 

[97] Free Software Foundation (febrer, 1999). Gnu lesser general public 

license, version 2,1. http://www.fsf.org/licenses/lgpl.html 

[98] Free Software Foundation. Free software definition. 

http://www.gnu.org/philosophy/free-sw.html 

[99] Free Software Foundation. Licencias libres. 

http://www.gnu.org/licenses/license-list.html 

[100] Bdale Garbee; Hartmut Koptein; Nils Lohner; Will Lowe; Bill 

Mitchell; Ian Murdock; Martin Schulze; Craig Small. A brief history of debian. 

En el paquet debian-history.


[101] Daniel Germán (maig, 2002). “The evolution of gnome”. A: Proceedings 

of the 2nd Workshop on Open Source Software Engineering at the 24th 

International Conference on Software Engineering. EUA: Florida. 

[102] Daniel Germán; Audris Mockus (maig, 2003). “Automating the 

measurement of open source pojects”. A: Proceedings of the 3rd Workshop 

on Open Source Software Engineering at the 25th International Conference on 

Software Engineering. EUA: Portland. 

[103] Rishab A. Ghosh (març, 1998). “Cooking pot markets: an economic 

model for the trade in free goods and services on the internet”. First Monday 

(vol. 3, núm. 3). 

http://www.firstmonday.dk/issues/issue3_3/ghosh/index.html 

[104] Rishab A. Ghosh; Ruediger Glott; Bernhard Krieger; Gregorio Robles 

(2002). Free/libre and open source software: Survey and study - part iv: Survey 

of developers. http://www.infonomics.nl/FLOSS/report/FLOSS_Final4.pdf 

[105] Rishab Aiyer Ghosh; Vipul Ved Prakash (juliol, 2000). “The Orbiten free 

software survey”. First Monday (vol. 7, núm. 5). 

http://www.firstmonday.dk/issues/issue5_7/ghosh/index.html 

[106] Michael W. Godfrey; Qiang Tu (agost, 2000). “Evolution in open 

source software: A case study”. Proceedings of the 2000 International 

Conference on Software Maintainance. 

[107] Juan Alberto González (març, 2002). Carta al congresista Villanueva. 

http://www.gnu.org.pe/mscarta.html 

[108] Jesús M. González-Barahona; Miguel A. Ortuño Pérez; Pedro de las 

Heras Quirós; José Centeno González; Vicente Matellán Olivera (desembre, 

2001). “Counting potatoes: The size of Debian 2.2”. Upgrade Magazine 

(vol. 6, núm. 2, pàg. 60-66). 

http://people.debian.org/˜jgb/debian-counting/counting-potatoes 

[109] Michel Goosens; Sebastian Rahtz (1999). The LaTeX Web Companion. 

Addison Wesley. 

[110] Burton Grad (gener-març, 2002). “A personal recollection: IBM’s 

unbundling of software and services”. IEEE Annals of the History of Computing 

(vol. 1, núm. 24, pàg. 64-71). 

[111] Working group on Libre Software (1999). Free software / open 

source: Information society opportunities for europe? 

http://eu.conecta.it/paper.pdf 

297 


ANOTACIONS


ANOTACIONS 

298 


[112] GrULIC. Legislación sobre el uso de software libre en el estado. 

http://proposicion.org.ar/doc/referencias/index.html.es 

[113] Jim Hamerly; Tom Paquin; Susan Walton (1999). Freeing the source - 

the story of mozilla. 

http://www.oreilly.com/catalog/opensources/book/netrev.html 

[114] Michael J. Hammel (desembre, 1991). “The history of xfree86”. Linux 

Magazine. http://www.linux-mag.com/2001-12/xfree86_01.html 

[115] S. Harris (agost, 2001). The tao of IETF: A novice’s guide to the internet 

engineering task force (RFC 3160, FYI 17). http://www.ietf.org/rfc/ 

rfc3160.txt 

[116] Paul Harrison (2002). The rational street performer protocol. 

http://www.logarithmic.net/pfh/RSPP 

[117] Ragib Hasan. History of Linux. http://ragib.hypermart.net/linux 

[118] Michael Hauben; Ronda Hauben (1997). Netizens. On the History 

and Impact of Usenet and the Internet. IEEE Computer Society Press. 

[119] Kieran Healy; Alan Schussman (gener, 2003). The ecology of 

open source software development. 

http://opensource.mit.edu/papers/healyschussman.pdf 

[120] Frank Hecker (maig, 1998). Setting up shop: The business of open- 

source software. http://www.hecker.org/writings/setting-up-shop.html 

[121] Frank Hecker (1998). Setting up shop: The business of open-source 

software. http://www.hecker.org/writings/setting-up-shop.html 

[122] Guido Hertel; Sven Niedner; Stefanie Herrmann (2003). 

Motivation of software developers in open source projects: An internet- 

based survey of contributors to the Linux kernel. 

http://opensource.mit.edu/papers/rp-hertelniednerherrmann.pdf 

[123] Allan Heydon; Roy Levin; Timothy Mann; Yuan Yu (2001). The vesta 

approach to software configuration management. Technical report, COMPAQ 

Systems Research Center. ftp://gatekeeper.research.compaq.com/pub/DEC/ 

SRC/research-reports/ SRC-168.pdf 

[124] Pekka Himanen (2001). The Hacker Ethic and the Spirit of the Information 

Age. Random House. http://www.hackerethic.org


[125] Francis Hunt; Paul Johnson (2002). On the pareto distribution of sour- 

ceforge projects. Technical report, Centre for Technology Management, 

Cambridge University Engineering Department, Mill Lane, Cambridge CB2 

1RX. http://www-mmd.eng.cam.ac.uk/people/fhh10/Sourceforge/Source- 

forge%20paper.pdf 

[126] Open Source Initiative. History of the osi. 

http://www.opensource.org/ docs/history.php 

[127] Ambaixador dels Estats Units al Perú John R. Hamilton (juny, 2002). 

Carta al presidente del congreso de la república. 

http://www.gnu.org.pe/lobbyu- sa-congreso.html 

[128] Paul Jones (maig, 2000). Brook’s law and open source: The more the 

merrier? http://www-106.ibm.com/developerworks/opensource/library/ os- 

merrier.html?dwzone=opensource 

[129] Niels Jorgensen. “Incremental and decentralized integration in freebsd”. 

A: Joe Feller; Brian Fitzgerald; Scott Hissam; Karim Lakhani (ed.) (2003). 

Making Sense of the Bazaar. O’Reilly. http://www.dat.ruc.dk/˜nielsj/research/ 

papers/bazaar-freebsd.pdf 

[130] Frederick P. Brooks Jr. The Mythical Man-Month: Essays on Software 

Engineering. Addison-Wesley, 1975 

[131] C. Kalt (abril, 2000). Internet relay chat: Architecture (rfc 2810). 

http:/ /www.ietf.org/rfc/rfc2810.txt 

[132] J. Kelsey; B. Schneier (novembre, 1998). “The street performer 

protocol”. En: Third USENIX Workshop on Electronic Commerce Proceedings. 

USE- NIX Press. http://www.counterpane.com/street_performer.html 

[133] J. Kelsey; B. Schneier (juny, 1999). “The street performer protocol and 

digital copyrights”. First Monday (vol. 6, núm. 4). 

http://www.firstmonday.dk/issues/issue4_6/kelsey 

[134] Christopher M. Kelty (desembre, 2001). “Free software/free science”. 

First Monday (vol. 12, núm. 6). 

http://firstmonday.org/issues/issue6_12/kelty/index.html 

[135] Jamil Khatib. Openipcore hardware general public license. 

http://www.opencores.org/OIPC/OHGPL_17.shtml 

[136] Donald Knuth (1989). The TeXboak. Addison Welsley. 

299 


ANOTACIONS


ANOTACIONS 

300 


[137] Stefan Koch (ed.) (2003). Free/Open Source Software Development. 

Idea Group Inc. http://wwwai.wu-wien.ac.at/˜koch/oss-book 

[138] Stefan Koch; Georg Schneider (2000). “Results from software 

engineering research into open source development projects using public 

data. Diskussionspapiere zum Tätigkeitsfeld Informationsverarbeitung und 

Informationswirtschaft”. A: H.R. Hansen; W.H. Janko (ed.). 

Wirtschaftsuniversität Wien (núm. 22). 

[139] Sandeep Krishnamurthy (maig, 2002). “Cave or community? an 

empirical examination of 100 mature open source projects”. First Monday 

(vol. 4, núm. 7). 

http://www.firstmonday.dk/issues/issue7_6/krishnamurthy/index.html 

[140] Laffitte, Trégouet; Cabanel (1999). Proposition de loi numéro 495. 

Senat de la República Francesa. 

http://www.senat.fr/consult/loglibre/texteloi.html 

[141] Laffitte; Trégouet; Cabanel (2000). Proposition de loi numéro 117. 

Senat de la República Francesa. 

http://www.senat.fr/consult/loglibre/texteloi.html 

[142] Leslie Lamport (1994). LaTeX user’s guide and reference manual. 

Addison Welsley, Reading, Mass (2ª. ed.). 

[143] David Lancashire (desembre, 2001). “Code, culture and cash: The 

fading altruism of open source development”. First Monday (vol. 12, núm. 6). 

http://www.firstmonday.dk/issues/issue6_12/lancashire/index.html 

[144] M.M. Lehman; J.F. Ramil; P.D. Wernick (novembre, 1997). “Metrics 

and laws of software evolution - the nineties view”. Proceedings of the 4th 

International Symposium on Software Metrics. 

http://www.ece.utexas.edu/˜perry/work/papers/feast1.pdf 

[145] Barry M. Leiner; Vinton G. Cerf, Robert E. Kahn; David D. Clark; 

Leonard Kleinrock; Daniel C. Lynch; Jon Postel; Larry G. Roberts; Stephen 

Wolff (1997). A brief history of the internet. Communications of the ACM. 

http://www.isoc.org/internet/history/brief.shtml 

[146] Netcraft Ltd. (agost, 2003) web server survey, 2003. http://news.ne- 

tcraft.com/archives/2003/08/01/august_2003_web_server_survey.html 

[147] Mark Lucovsky (2000). From nt os/2 to windows 2000 and beyond - a 

software-engineering odyssey. 

http://www.usenix.org/events/usenix-win2000/invitedtalks/lucovsky_html


[148] Gary McGraw. “Building secure software: How to avoid security 

problems the right way”. A: David A. Wheeler 

http://www.dwheeler.com/sloc 

[149] Marshall Kirk McKusick. “Twenty Years of Berkeley UNIX. From AT&T- 

Owned to Freely Redistributable”. A: DiBona i altres (1999). 

http://www.oreilly.com/catalog/opensources 

[150] SUN Microsystems (2000). Sun microsystems announces availability of 

StarOffice(TM) source code on OpenOffice.org. 

http://www.collab.net/news/press/2000/openoffice_live.html 

[151] Peter Miller (1993). Aegis a project change supervisor. 

http://aegis.sourceforge.net/auug93.pdf 

[152] Audris Mockus; Roy T. Fielding; James D. Herbsleb (juny, 2000). 

“A case study of open source software development: the apache server”. 

A: Proceedings of the 22nd International Conference on Software 

Engineering (ICSE 2000, págs. 263-272). Irlanda: Limerick. ACM Press. 

[153] Brian Molenaar. What is the context of charityware? 

http://www.moolenaar.net/Charityware.html 

[154] Mit opencourseware. http://ocw.mit.edu 

[155] Laurence W. Nagel (set., 1996). The life of SPICE. Presented at the 

1996 Bipolar Circuits and Technology Meeting. EUA: Minneapolis, MN. 

http://www.icsl.ucla.edu/aagroup/Life%20of%20SPICE.html 

[156] Alessandro Narduzzo; Alessandro Rossi (maig, 2003). Modularity in 

action: Gnu/Linux and free/open source software development model 

unleashed. http://opensource.mit.edu/papers/narduzzorossi.pdf 

[157] Nathan Newman (1999). The origins and future of open source 

software. http://www.netaction.org/opensrc/future 

[158] Nupedia. http://www.nupedia.com 

[159] Edgar Villanueva Núñez (2002). Carta a Microsoft Perú. 

http://www.gnu.org.pe/rescon.html 

[160] Open Source Initiative. Licencias de fuente abierto. 

http://www.opensource.org/licenses/index.html 

[161] Vilfredo Pareto. Course of Political Economy. Lausanne, 1896 

301 


ANOTACIONS


ANOTACIONS 

302 


[162] Bruce Perens and The Open Source Initiative. (1998). The open 

source definition. http://www.opensource.org/docs/definition_plain.html 

[163] GNU Perú. Projectes llei programari lliure en l’Administració pública del 

Govern peruà, Congrés de la República. http://www.gnu.org.pe/proleyap.html 

[164] Walter Pinheiro (desembre, 1999). Proposicao pl-2269/1999: 

Dispoe sobre a utilizacao de programas abertos pelos entes de direito 

público e de direito privado sob controle acionário da administracao 

pública. Câmara dos Deputados do Brasil. 

http://www.camara.gov.br/Internet/sileg/ Prop_Detalhe.asp?id=17879 

http://www.fenadados.org.br/software.htm 

[165] Joseph Pranevich (2003). The wonderful world of Linux 2.6. 

http://www.kniggit.net/wwol26.html 

[166] The Debian Project. Debian developer map. 

http://www.debian.org/devel/developers.loc 

[167] Joan Puigcercós Boixassa. (2002). Proposició de lllei de mesures per 

a la implantació del programari lliure en l’Administració de l’Estat. 

http://www.congreso.es/public_oficiales/L7/CONG/BOCG/B/B_244-01.PDF 

[168] Joshua Quittner; Michelle Slatalla (1998). Speeding the Net: The 

Inside Story of Netscape and How It Challenged Microsoft. Atlantic Monthly Pr. 

[169] Chris Rasch. A brief history of free/open source software 

movement. 

http://www.openknowledge.org/writing/open-source/scb/brief-open-sour- 

ce-history.html 

[170] Chris Rasch. (2001, maig). “The Wall Street performer protocol. Using 

software completion bonds to fund open source software development”. First 

Monday (vol. 6, núm. 6). 

[171] Eric S. Raymond. The Cathedral and the Bazaar, Musings on Linux and 

Open Source by an Accidental Revolutionary. O’Reilly & Associates (http:// 

www.ora.com), gener, 2001. 

http://catb.org/˜esr/writings/cathedral-bazaar 

[172] Christian Robottom Reis; Renata Pontin de Mattos Fortes (febrer, 

2002). An overview of the software engineering process and tools in the mozilla 

project. http://opensource.mit.edu/papers/reismozilla.pdf 

[173] Francois-René Rideau (2000). Patents are an economic absurdity. 

http://fare.tunes.org/articles/patents.html


[174] Lawrence Roberts (1978, novembre). “The evolution of packet switching”. 

Proceedings of the IEEE (vol. 66). 

[175] Gregorio Robles; Jesús M. González Barahona; José Centeno 

González; Vicente Matellán Olivera; Luis Rodero Merino (maig, 2003). 

“Studying the evolution of libre software projects using publicly available 

data”. A: Proceedings of the 3rd Workshop on Open Source Software 

Engineering at the 25th International Conference on Software Engineering. 

EUA: Portland. 

[176] Gregorio Robles; Hendrik Scheider; Ingo Tretkowski; Niels Weber 

(2001). Who is doing it? knowing more about libre software developers. 

http://widi.berlios.de/paper/study.pdf 

[177] Marc Rochkind (maig, 1986). Interview with dick haight. UNIX Review. 

[178] Walt Scacchi (2003). Understanding open source software evolution: 

Applying, breaking and rethinking the laws of software evolution. http:// 

www.ics.uci.edu/˜wscacchi/Papers/New/Understanding-OSS-Evolution.pdf 

[179] Bruce Schneier (2000). Software complexity and security. 

http:// www.counterpane.com/crypto-gram-0003.html 

[180] Stephen J. Smoogen. The truth behind red hat names. 

http:// www.smoogespace.com/documents/behind_the_names.html 

[181] Haggen So. Comparison of free/open source hosting (fosphost) sites 

available for hosting projects externally from project owners. 

http://www.ibiblio.org/fosphost/exhost.htm 

[182] Richard Stallman. GNU coding standards. 

http://www.gnu.org/prep/standards.html 

[183] Richard Stallman. Why Free Software is better than Open Source. 

http://www.fsf.org/philosophy/free-software-for-freedom.html 

[184] Richard Stallman (1998). Copyleft: Pragmatic idealism. 

http://www.gnu.org/philosophy/pragmatic.html 

[185] Richard Stallman (1998). Why “free software” is better than “open 

source”. http://www.gnu.org/philosophy/free-software-for-freedom.html 

[186] Richard Stallman (1998). Why software should not have owners. 

http://www.gnu.org/philosophy/why-free.html 

303 


ANOTACIONS


ANOTACIONS 

304 


[187] Richard Stallman. The GNU Project. En: DiBona y otros. 

http://www.fsf.org/gnu/thegnuproject.html 

[188] Richard Stallman (juny, 1999). “On free hardware”. Linux Today. 

http://features.linuxtoday.com/news_story.php3?ltsn=1999-06-22-005- 

05-NW-LF 

[189] Richard Stallman (2001). The free universal encyclopedia and learning 

resource. http://www.gnu.org/encyclopedia/free-encyclopedia.html 

[190] Richard Stallman (2002). Free Software, Free Society: Selected Essays 

of Richard M. Stallman. Joshua Gay. 

[191] Richard Stallman (2003). Some confusing or loaded words and phrases 

that are worth avoiding. http://www.gnu.org/philosophy/words-to-avoid.html 

[192] Mitch Stoltz (1999). The case for government promotion of open 

source software. http://www.netaction.org/opensrc/oss-report.html 

[193] Andrew Tanenbaum; Linus Torvalds (1999). The tanenbaum-torvalds 

debate. http://www.oreilly.com/catalog/opensources/book/appa.html 

[194] Michael Tiemann. “Future of cygnus solutions. an entrepreneur’s account”. 

A: DiBona i altres. 

http://www.oreilly.com/catalog/opensources/book/tiemans.html 

[195] Linus Torvalds; David Diamond (2001). Just For Fun: the story of an 

accidental revolutionary. Texere. 

[196] Ilkka Tuomi (2002). Evolution of the Linux credits file: Methodological 

challenges and reference data for open source research. 

http://www.jrc.es/ ˜tuomiil/articles/EvolutionOfTheLinuxCreditsFile.pdf 

[197] Diversos autors. Carta abierta al director de la wipo. 

http://www.cptech.org/ip/wipo/kamil-idris-7july2003.pdf 

[198] Pere Vigo i Sallent; Ernest Benach i Pascual; Josep Huguet i Biosca 

(2002, maig). Proposició de llei de programari lliure en el marc de l’adminis- 

tració pública de Catalunya. 

http://www.parlament-cat.es/pdf/06b296.pdf 

http://www.hispalinux.es/modules.php?op=modload&name=Secti- 

ons&file= index&req=viewarticle&artid=49 

[199] Edgar Villanueva Núñez (2001, desembre). Proyecto de ley software 

libre, número 1609. http://www.gnu.org.pe/proley1.html


[200] Edgar Villanueva Núñez; Jacques Rodrich Ackerman (2002, abril). 

Proyecto de ley de uso de software libre en la administración pública, número 

2485. http://www.gnu.org.pe/proley4.html 

[201] W3C (2000). Extensible markup language (xml) 1.0 (2a. edic.). 

[202] Norman Walsh; Leonard Muellner; Bob Stayton (2002). Docbook: 

The Definitive Guide. O’Reilly. http://docbook.org/tdg/en/html/docbook.html 

[203] Larry Welke; Luanne Johnson (1998). How the icp directory began. 

http://www.softwarehistory.org/history/Welke1.html 

[204] David A. Wheeler (2000, juliol). Estimating Linux’s size. 

http://www.dwheeler.com/sloc 

[205] David A. Wheeler (2001, juny). More than a gigabuck: Estimating 

gnu/Linux’s. http://www.dwheeler.com/sloc 

[206] Eric Wiesstein. Concise encyclopedia of mathematics. 

http://mathworld.wolfram.com 

[207] Wikipedia. Gini coefficient. 

http://www.wikipedia.org/wiki/Gini_coefficient 

[208] Wikipedia. Lorenz curve. http://www.wikipedia.org/wiki/Lorenz_curve 

[209] Wikipedia. Pareto. http://www.wikipedia.org/wiki/Pareto 

[210] Wikipedia. Tex. http://www.wikipedia.org/wiki/TeX 

[211] Brian Wilson. Netscape navigator. 

http://www.blooberry.com/indexdot/history/netscape.htm 

[212] Computer World (2000). Salary survey 2000. 

http://www.computerworld.com/cwi/careers/surveysandreports 

[213] Robert Young (1999). Giving it away. how red hat software stumbled 

across a new economic model and helped improve an industry. 

http://www.oreilly.com/catalog/opensources/book/young.html 

[214] Jamie Zawinski (1999). Resignation and postmortem. Why Mozilla 

project failed: http://www.jwz.org/gruntle/nomo.html 

[215] Jamie W. Zawinsky (1999). Resignation and postmortem. 

http://www.jwz.org/gruntle/nomo.html 

305 


ANOTACIONS


Appendix A. GNU Free Documentation License 

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 

Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is 

permitted to copy and distribute verbatim copies of this license docu- 

ment, but changing it is not allowed. 

A.1. PREAMBLE 

The purpose of this License is to make a manual, textbook, or other 

functional and useful document free in the sense of freedom: to 

assure everyone the effective freedom to copy and redistribute it, with 

or without modifying it, either commercially or noncommercially. 

Secondarily, this License preserves for the author and publisher a way 

to get credit for their work, while not being considered responsible for 

modifications made by others. 

This License is a kind of copyleft which means that derivative works 

of the document must themselves be free in the same sense. It 

complements the GNU General Public License, which is a copyleft 

license designed for free software. 

We have designed this License in order to use it for manuals for 

free software, because free software needs free documentation: a 

free program should come with manuals providing the same 

freedoms that the software does. But this License is not limited to 

software manuals; it can be used for any textual work, regardless 

of subject matter or whether it is published as a printed book. We 

recommend this License principally for works whose purpose is 

instruction or reference. 

307 


ANOTACIONS


ANOTACIONS 

308 


A.2. APPLICABILITY AND DEFINITIONS 

This License applies to any manual or other work, in any medium, 

that contains a notice placed by the copyright holder saying it can 

be distributed under the terms of this License. Such a notice grants 

a world-wide, royalty-free license, unlimited in duration, to use 

that work under the conditions stated herein. The Document 

below, refers to any such manual or work. Any member of the 

public is a licensee, and is addressed as you You accept the license 

if you copy, modify or distribute the work in a way requiring 

permission under copyright law. 

A Modified Version of the Document means any work containing the 

Document or a portion of it, either copied verbatim, or with 

modifications and/or translated into another language. 

A Secondary Section is a named appendix or a front-matter section 

of the Document that deals exclusively with the relationship of the 

publishers or authors of the Document to the Document’s overall 

subject (or to related matters) and contains nothing that could fall 

directly within that overall subject. (Thus, if the Document is in part a 

textbook of mathematics, a Secondary Section may not explain any 

mathematics.) The relationship could be a matter of historical 

connection with the subject or with related matters, or of legal, 

commercial, philosophical, ethical or political position regarding 

them. 

The Invariant Sections are certain Secondary Sections whose titles are 

designated, as being those of Invariant Sections, in the notice that 

says that the Document is released under this License. If a section 

does not fit the above definition of Secondary then it is not allowed to 

be designated as Invariant. The Document may contain zero 

Invariant Sections. If the Document does not identify any Invariant 

Sections then there are none. 

The Cover Texts are certain short passages of text that are listed, 

as Front-Cover Texts or Back-Cover Texts, in the notice that says 

that the Document is released under this License. A Front-Cover 

Text may be at most 5 words, and a Back-Cover Text may be at 

most 25 words.


A Transparent copy of the Document means a machine-readable 

copy, represented in a format whose specification is available to the 

general public, that is suitable for revising the document 

straightforwardly with generic text editors or (for images composed of 

pixels) generic paint programs or (for drawings) some widely 

available drawing editor, and that is suitable for input to text 

formatters or for automatic translation to a variety of formats suitable 

for input to text formatters. A copy made in an otherwise Transparent 

file format whose markup, or absence of markup, has been arranged 

to thwart or discourage subsequent modification by readers is not 

Transparent. An image format is not Transparent if used for any 

substantial amount of text. A copy that is not Transparent is called 

Opaque. 

Examples of suitable formats for Transparent copies include plain 

ASCII without markup, TeXinfo input format, LaTeX input format, 

SGML or XML using a publicly available DTD, and standard- 

conforming simple HTML, PostScript or PDF designed for human 

modification. Examples of transparent image formats include PNG, 

XCF and JPG. Opaque formats include proprietary formats that can 

be read and edited only by proprietary word processors, SGML or 

XML for which the DTD and/or processing tools are not generally 

available, and the machine-generated HTML, PostScript or PDF 

produced by some word processors for output purposes only. 

The Title Page means, for a printed book, the title page itself, plus 

such following pages as are needed to hold, legibly, the material this 

License requires to appear in the title page. For works in formats 

which do not have any title page as such, Title Page means the text 

near the most prominent appearance of the work’s title, preceding 

the beginning of the body of the text. 

A section Entitled XYZ means a named subunit of the Document 

whose title either is precisely XYZ or contains XYZ in parentheses 

following text that translates XYZ in another language. (Here XYZ 

stands for a specific section name mentioned below, such as 

Acknowledgements, Dedications, Endorsements, or History. To 

Preserve the Title of such a section when you modify the Document 

means that it remains a section Entitled XYZ according to this 

definition. 

309 


ANOTACIONS


ANOTACIONS 

310 


The Document may include Warranty Disclaimers next to the notice 

which states that this License applies to the Document. These 

Warranty Disclaimers are considered to be included by reference in 

this License, but only as regards disclaiming warranties: any other 

implication that these Warranty Disclaimers may have is void and has 

no effect on the meaning of this License. 

A.3. VERBATIM COPYING 

You may copy and distribute the Document in any medium, either 

commercially or noncommercially, provided that this License, the 

copyright notices, and the license notice saying this License applies to 

the Document are reproduced in all copies, and that you add no 

other conditions whatsoever to those of this License. You may not use 

technical measures to obstruct or control the reading or further 

copying of the copies you make or distribute. However, you may 

accept compensation in exchange for copies. If you distribute a large 

enough number of copies you must also follow the conditions in 

section 3. 

You may also lend copies, under the same conditions stated above, 

and you may publicly display copies. 

A.4. COPYING IN QUANTITY 

If you publish printed copies (or copies in media that commonly have 

printed covers) of the Document, numbering more than 100, and the 

Document’s license notice requires Cover Texts, you must enclose the 

copies in covers that carry, clearly and legibly, all these Cover Texts: 

Front-Cover Texts on the front cover, and Back-Cover Texts on the 

back cover. Both covers must also clearly and legibly identify you as 

the publisher of these copies. The front cover must present the full title 

with all words of the title equally prominent and visible. You may add 

other material on the covers in addition. Copying with changes 

limited to the covers, as long as they preserve the title of the 

Document and satisfy these conditions, can be treated as verbatim 

copying in other respects.


If the required texts for either cover are too voluminous to fit legibly, 

you should put the first ones listed (as many as fit reasonably) on the 

actual cover, and continue the rest onto adjacent pages. 

If you publish or distribute Opaque copies of the Document 

numbering more than 100, you must either include a machine- 

readable Transparent copy along with each Opaque copy, or state in 

or with each Opaque copy a computer-network location from which 

the general network-using public has access to download using 

public-standard network protocols a complete Transparent copy of 

the Document, free of added material. If you use the latter option, you 

must take reasonably prudent steps, when you begin distribution of 

Opaque copies in quantity, to ensure that this Transparent copy will 

remain thus accessible at the stated location until at least one year 

after the last time you distribute an Opaque copy (directly or through 

your agents or retailers) of that edition to the public. 

It is requested, but not required, that you contact the authors of the 

Document well before redistributing any large number of copies, to give 

them a chance to provide you with an updated version of the Document. 

A.5. MODIFICATIONS 

You may copy and distribute a Modified Version of the Document under 

the conditions of sections 2 and 3 above, provided that you release the 

Modified Version under precisely this License, with the Modified Version 

filling the role of the Document, thus licensing distribution and 

modification of the Modified Version to whoever possesses a copy of it. 

In addition, you must do these things in the Modified Version: 

A. Use in the Title Page (and on the covers, if any) a title distinct from 

that of the Document, and from those of previous versions (which 

should, if there were any, be listed in the History section of the Do- 

cument). You may use the same title as a previous version if the 

original publisher of that version gives permission. 

B. List on the Title Page, as authors, one or more persons or entities 

responsible for authorship of the modifications in the Modified 

Version, together with at least five of the principal authors of the 

311 


ANOTACIONS


ANOTACIONS 

312 


Document (all of its principal authors, if it has fewer than five), 

unless they release you from this requirement. 

C. State on the Title page the name of the publisher of the Modified 

Version, as the publisher. 

D. Preserve all the copyright notices of the Document. 

E. Add an appropriate copyright notice for your modifications adja- 

cent to the other copyright notices. 

F. Include, immediately after the copyright notices, a license notice 

giving the public permission to use the Modified Version under the 

terms of this License, in the form shown in the Addendum below. 

G. Preserve in that license notice the full lists of Invariant Sections and 

required Cover Texts given in the Document’s license notice. 

H. Include an unaltered copy of this License. 

I. Preserve the section Entitled History. Preserve its Title, and add to 

it an item stating at least the title, year, new authors, and publisher 

of the Modified Version as given on the Title Page. If there is no 

section Entitled History in the Document, create one stating the tit- 

le, year, authors, and publisher of the Document as given on its 

Title Page, then add an item describing the Modified Version as 

stated in the previous sentence. 

J. Preserve the network location, if any, given in the Document for 

public access to a Transparent copy of the Document, and likewise 

the network locations given in the Document for previous versions 

it was based on. These may be placed in the History section. You 

may omit a network location for a work that was published at least 

four years before the Document itself, or if the original publisher 

of the version it refers to gives permission. 

K. For any section Entitled Acknowledgements or Dedications Preser- 

ve the Title of the section, and preserve in the section all the subs- 

tance and tone of each of the contributor acknowledgements and/ 

or dedications given therein.


L. Preserve all the Invariant Sections of the Document, unaltered in 

their text and in their titles. Section numbers or the equivalent are 

not considered part of the section titles. 

M. Delete any section Entitled Endorsements Such a section may not 

be included in the Modified Version. 

N. Do not retitle any existing section to be Entitled Endorsements or to 

conflict in title with any Invariant Section. 

O. Preserve any Warranty Disclaimers. 

If the Modified Version includes new front-matter sections or 

appendices that qualify as Secondary Sections and contain no 

material copied from the Document, you may at your option 

designate some or all of these sections as invariant. To do this, add 

their titles to the list of Invariant Sections in the Modified Version’s 

license notice. These titles must be distinct from any other section 

titles. 

You may add a section Entitled Endorsements, provided it contains 

nothing but endorsements of your Modified Version by various 

parties–for example, statements of peer review or that the text has 

been approved by an organization as the authoritative definition of a 

standard. 

You may add a passage of up to five words as a Front-Cover Text, and 

a passage of up to 25 words as a Back-Cover Text, to the end of the 

list of Cover Texts in the Modified Version. Only one passage of Front- 

Cover Text and one of Back-Cover Text may be added by (or through 

arrangements made by) any one entity. If the Document already 

includes a cover text for the same cover, previously added by you or by 

arrangement made by the same entity you are acting on behalf of, you 

may not add another; but you may replace the old one, on explicit 

permission from the previous publisher that added the old one. 

The author(s) and publisher(s) of the Document do not by this License 

give permission to use their names for publicity for or to assert or 

imply endorsement of any Modified Version. 

313 


ANOTACIONS


ANOTACIONS 

314 


A.6. COMBINING DOCUMENTS 

You may combine the Document with other documents released 

under this License, under the terms defined in section 4 above for 

modified versions, provided that you include in the combination 

all of the Invariant Sections of all of the original documents, 

unmodified, and list them all as Invariant Sections of your 

combined work in its license notice, and that you preserve all their 

Warranty Disclaimers. 

The combined work need only contain one copy of this License, and 

multiple identical Invariant Sections may be replaced with a single 

copy. If there are multiple Invariant Sections with the same name but 

different contents, make the title of each such section unique by 

adding at the end of it, in parentheses, the name of the original 

author or publisher of that section if known, or else a unique number. 

Make the same adjustment to the section titles in the list of Invariant 

Sections in the license notice of the combined work. 

In the combination, you must combine any sections Entitled History in 

the various original documents, forming one section Entitled History; 

likewise combine any sections Entitled Acknowledgements, and any 

sections Entitled Dedications. You must delete all sections Entitled 

Endorsements. 

A.7. COLLECTIONS OF DOCUMENTS 

You may make a collection consisting of the Document and other 

documents released under this License, and replace the individual copies 

of this License in the various documents with a single copy that is 

included in the collection, provided that you follow the rules of this 

License for verbatim copying of each of the documents in all other 

respects. 

You may extract a single document from such a collection, and 

distribute it individually under this License, provided you insert a copy 

of this License into the extracted document, and follow this License in 

all other respects regarding verbatim copying of that document.


A.8. AGGREGATION WITH INDEPENDENT WORKS 

A compilation of the Document or its derivatives with other separate 

and independent documents or works, in or on a volume of a storage 

or distribution medium, is called an aggregate if the copyright 

resulting from the compilation is not used to limit the legal rights of 

the compilation’s users beyond what the individual works permit. 

When the Document is included in an aggregate, this License does 

not apply to the other works in the aggregate which are not 

themselves derivative works of the Document. 

If the Cover Text requirement of section 3 is applicable to these 

copies of the Document, then if the Document is less than one half 

of the entire aggregate, the Document’s Cover Texts may be placed 

on covers that bracket the Document within the aggregate, or the 

electronic equivalent of covers if the Document is in electronic form. 

Otherwise they must appear on printed covers that bracket the 

whole aggregate. 

A.9. TRANSLATION 

Translation is considered a kind of modification, so you may 

distribute translations of the Document under the terms of section 4. 

Replacing Invariant Sections with translations requires special 

permission from their copyright holders, but you may include 

translations of some or all Invariant Sections in addition to the 

original versions of these Invariant Sections. You may include a 

translation of this License, and all the license notices in the Document, 

and any Warranty Disclaimers, provided that you also include the 

original English version of this License and the original versions of 

those notices and disclaimers. In case of a disagreement between the 

translation and the original version of this License or a notice or 

disclaimer, the original version will prevail. 

If a section in the Document is Entitled Acknowledgements, 

Dedications, or History, the requirement (section 4) to Preserve its Title 

(section 1) will typically require changing the actual title. 

315 


ANOTACIONS


ANOTACIONS 

316 


A.10. TERMINATION 

You may not copy, modify, sublicense, or distribute the Document ex- 

cept as expressly provided for under this License. Any other attempt 

to copy, modify, sublicense or distribute the Document is void, and 

will automatically terminate your rights under this License. However, 

parties who have received copies, or rights, from you under this Li- 

cense will not have their licenses terminated so long as such parties 

remain in full compliance. 

A.11. FUTURE REVISIONS OF THIS LICENSE 

The Free Software Foundation may publish new, revised versions of 

the GNU Free Documentation License from time to time. Such new 

versions will be similar in spirit to the present version, but may differ 

in detail to address new problems or concerns. See http:// 

www.gnu.org/copyleft/. 

Each version of the License is given a distinguishing version number. 

If the Document specifies that a particular numbered version of this 

License or any later version applies to it, you have the option of 

following the terms and conditions either of that specified version or 

of any later version that has been published (not as a draft) by the 

Free Software Foundation. If the Document does not specify a version 

number of this License, you may choose any version ever published 

(not as a draft) by the Free Software Foundation. 

A.12. ADDENDUM: How to use this License for your 

documents 

To use this License in a document you have written, include a copy of 

the License in the document and put the following copyright and 

license notices just after the title page: 

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, 

distribute and/or modify this document under the terms of the GNU


Free Documentation License, Version 1.2 or any later version 

published by the Free Software Foundation; with no Invariant 

Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of 

the license is included in the section entitled GNU Free 

Documentation License 

If you have Invariant Sections, Front-Cover Texts and Back-Cover 

Texts, replace the with...Texts. line with this: 

with the Invariant Sections being LIST THEIR TITLES, with the Front- 

Cover Texts being LIST, and with the Back-Cover Texts being LIST. 

If you have Invariant Sections without Cover Texts, or some other 

combination of the three, merge those two alternatives to suit the 

situation. 

If your document contains nontrivial examples of program code, we 

recommend releasing these examples in parallel under your choice 

of free software license, such as the GNU General Public License, to 

permit their use in free software. 

317 


ANOTACIONS


Apèndix B. Llicència de documentació lliure de GNU 

This is an unofficial translation of the GNU Free Documentation License 

into Catalan. It was not published by the Free Software Foundation, and 

does not legally state the distribution terms for software that uses the 

GNU GFDL--only the original English text of the GNU GFDL does that. 

However, we hope that this translation will help Catalan speakers 

understand the GNU GFDL better. 

Aquesta és una traducció no oficial al català de la Llicència de docu- 

mentació lliure (GFDL) de GNU. No ha estat publicada per la Free 

Software Foundation, i no estableix legalment els termes de distribu- 

ció del programari que utilitza la GFDL de GNU, ja que això només 

ho fa el text original en anglès de la GFDL de GNU. Esperem, però, 

que aquesta traducció ajudi els catalanoparlants a comprendre mi- 

llor la GFDL de GNU. 

Llicència de documentació lliure de GNU. Versió 1.2, novembre de 

2002. Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 

59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 

Qualsevol pot copiar i distribuir còpies literals d'aquest document 

de llicència, però no és permès canviar-lo. 

B.1. PREÀMBUL 

La finalitat d’aquesta Llicència és crear manuals, llibres de text o al- 

tres documents, funcionals i útils, “lliures” pel que fa a la llibertat; per 

assegurar tothom la llibertat real de copiar-los i redistribuir-los, mo- 

dificant-los o no, amb finalitats comercials o no. Addicionalment, 

aquesta Llicència assegura l’autor i l’editor una manera d’obtenir 

crèdit per la seva obra sense ser considerat responsables de les mo- 

dificacions fetes pels altres. 

Aquesta Llicència és una mena de “copyleft”, el que significa que les 

obres que es derivin del document també han de ser lliures en el ma- 

319 


ANOTACIONS


ANOTACIONS 

320 


teix sentit, i complementa la Llicència pública general de GNU, que 

és una llicència de copyleft dissenyada per al programari lliure. 

Hem dissenyat aquesta Llicència per tal d’utilitzar-la en manuals de 

programari lliure, perquè el programari lliure necessita documenta- 

ció lliure: un programa lliure ha de venir amb manuals que tinguin 

les mateixes llibertats que té el programari. Però aquesta Llicència no 

es limita als manuals de programari; es pot utilitzar per a qualsevol 

obra de text, independentment del seu tema o de si s’ha publicat en 

forma impresa o no. Recomanem aquesta Llicència especialment per 

a obres la finalitat de les quals sigui formació o consulta. 

B.2. CAMP D’APLICACIÓ I DEFINICIONS 

Aquesta Llicència s’aplica a qualsevol manual o altra mena d’obra, 

en qualsevol suport, que inclogui un avís del propietari del copyright 

que digui que es pot distribuir sota els termes d’aquesta Llicència. 

Aquest avís garanteix una llicència a nivell mundial, lliure de drets 

d’autor, de durada il·limitada, per utilitzar l’obra sota les condicions 

que es detallen aquí. Amb “Document” ens referirem a aquest ma- 

nual o obra. Qualsevol membre del públic és un “autoritzat” i ens hi 

adreçarem com a “vós”. Accepteu la llicència si copieu, modifiqueu 

o distribuïu l’obra d’una manera que requereixi permís segons la llei 

de copyright. 

Una “Versió modificada” del document significa qualsevol obra que 

contingui el document o una part d’ell, ja sigui copiat literalment o 

amb modificacions i/o traduït a un altre idioma. 

Una “Secció secundària” és un apèndix amb títol o una secció preli- 

minar del Document que té a veure exclusivament amb la relació dels 

editors o autors del Document amb el tema general del Document (o 

amb temes relacionats) i no conté res que pugui entrar directament 

dins d’aquest tema general (així, si el Document és en part un llibre 

de matemàtiques, una Secció secundària pot no parlar gens de ma- 

temàtiques). La relació pot ser un assumpte de connexió històrica 

amb el tema o amb assumptes relacionats, o de posicions legals, co- 

mercials, filosòfiques, ètiques o polítiques relatives a ells.


Les “Seccions invariables” són determinades Seccions secundàries els 

títols de les quals indiquen que són Seccions invariables en l’avís que 

indica que el Document es distribueix sota aquesta Llicència. Si una 

secció no compleix amb aquesta definició de Secundària, no es pot 

designar com a Invariable. El Document pot no contenir cap Secció 

invariable. Si el Document no identifica cap Secció invariable, ales- 

hores no n’hi ha cap. 

Els “Textos de portada” són determinats fragments breus de text que 

consten com a Textos de portada o Textos de contraportada en l’avís 

que indica que el Document es distribueix sota aquesta Llicència. Un 

Text de portada ha de tenir un màxim de 5 paraules, i un Text de con- 

traportada un màxim de 25. 

Una còpia “Transparent” del Document significa una còpia que pu- 

gui ser llegida per una màquina, presentada en un format les espe- 

cificacions del qual siguin accessibles al públic en general, que es 

pugui revisar directament amb editors de text genèrics, o, per a imat- 

ges composades de píxels, amb programes gràfics genèrics, o, per a 

dibuixos, amb editors de dibuix fàcilment accessibles, i que es pugui 

introduir a formatadors de text, o a traductors automàtics en una va- 

rietat de formats que es puguin introduir a formatadors de text. Una 

còpia feta en un format de fitxer Transparent, l’etiquetatge o l’absèn- 

cia d’etiquetatge del qual s’hagi dissenyat per obstaculitzar o dissu- 

adir als lectors de fer-hi ulteriors modificacions no és Transparent. Un 

format d’imatge no és Transparent si s’utilitza per a una quantitat sig- 

nificativa de text. Una còpia que no és “Transparent” s’anomena 

“Opaca”. 

Alguns dels formats adequats per a còpies Transparents són: ASCII 

net sense etiquetatge, format d’entrada TeXinfo, format d’entrada 

LaTeX, SGML o XML que utilitzin un DTD accessible per a tothom, i 

HTML senzill que compleixi amb els estàndards, PostScript o PDF que 

estiguin dissenyats per a la modificació humana. Els formats trans- 

parents d’imatge inclouen PNG, XCF i JPG. Els formats opacs inclo- 

uen els formats de propietat que només es poden llegir i editar per 

processadors de textos de propietat, SGML o XML el DTD i/o eines de 

processament dels quals no siguin fàcilment accessibles, i HTML, 

PostScript o PDF generats automàticament per alguns processadors 

de textos només per a la sortida. 

321 


ANOTACIONS


ANOTACIONS 

322 


La “Pàgina de títol” significa, per a un llibre imprès, la pròpia pàgina 

de títol, més totes aquelles pàgines que siguin necessàries per conte- 

nir, de manera llegible, el material que aquesta Llicència requereix 

que aparegui a la pàgina de títol. Per a les obres que, a causa del 

format de les quals, no tinguin pròpiament una pàgina de títol, la 

“Pàgina de títol” significa el text proper a l’aparició més destacada 

del títol de l’obra, precedint el començament del cos del text. 

Una secció “titulada XYZ” significa una subunitat amb títol del Docu- 

ment que, o bé és precisament XYZ o bé conté XYZ entre parèntesis 

a continuació del text que tradueix XYZ a un altre idioma (XYZ indica 

el nom d’una secció determinada, com ara “Agraïments”, “Dedica- 

tòries”, “Aprovacions” o “Historial”). “Conservar el títol” d’una 

d’aquestes seccions quan modifiqueu el document significa que se- 

gueix existint una secció titulada XYZ segons aquesta definició. 

El Document pot incloure Descàrrecs de garantia al costat de l’avís 

que indica que aquesta Llicència s’aplica al Document. Es considera 

que aquests Descàrrecs de garantia s’inclouen en referència a 

aquesta Llicència, però solament quant a descarregar de garanties: 

qualsevol altra implicació que aquests Descàrrecs de garantia pu- 

guin tenir és nul·la i no té cap efecte en el significat d’aquesta Llicèn- 

cia. 

B.3. CÒPIES LITERALS 

Podeu copiar i distribuir el Document en qualsevol suport, de manera 

comercial o no, sempre que aquesta Llicència, els avisos de 

copyright, i l’avís de llicència que diu que aquesta Llicència s’aplica 

al Document, es reprodueixin en totes les còpies, i que no hi afegiu 

altres condicions que les d’aquesta Llicència. No podeu utilitzar mit- 

jans tècnics per impedir o controlar la lectura de successives còpies 

de les còpies que feu o distribuïu. Podeu acceptar, però, una com- 

pensació a canvi de les còpies. Si distribuïu un nombre prou gran de 

còpies també heu de seguir les condicions de la secció 3. 

També podeu prestar-ne còpies, amb les mateixes condicions es- 

mentades, i exhibir-ne còpies públicament.

B.4. CÒPIES EN GRANS QUANTITATS 


Si publiqueu més de 100 còpies impreses, o en un suport que habi- 

tualment tingui cobertes impreses, del Document, i l’avís de llicència 

del Document requereix Textos de portada, heu d’’acompanyar les 

còpies de cobertes que portin, clarament llegible, tots aquests Textos 

de portada: Textos de portada a la portada i Textos de contraportada 

a la contraportada. A totes dues cobertes s’ha d’indicar, clarament 

llegible, que sou l’editor d’aquestes còpies. La portada ha d’indicar 

el títol complet, i totes les paraules han de destacar i veure’s d’igual 

manera. Podeu afegir material addicional a les cobertes. Les còpies 

amb canvis només a les cobertes, mentre conservin el títol del Docu- 

ment i satisfacin aquestes condicions, es poden considerar còpies li- 

terals en altres aspectes. 

Si els textos requerits per a qualsevol de les cobertes són massa den- 

sos per encabir-los de manera que quedin llegibles, cal que poseu 

els primers (tants com sigui raonablement possible) en la coberta re- 

al, i la resta en pàgines adjacents. 

Si publiqueu o distribuïu més de 100 còpies Opaques del Document, 

heu d’incloure amb cadascuna d’elles una còpia Transparent, llegi- 

ble per una màquina, o bé incloure-hi, o indicar-hi, una ubicació de 

xarxa des d’on tothom que utilitzi la xarxa pugui baixar-se, utilitzant 

protocols de xarxa públics, una còpia Transparent completa del Do- 

cument i sense material afegit. Si utilitzeu aquesta darrera opció, en 

començar la distribució de gran quantitat de còpies Opaques heu de 

prendre les mesures raonablement necessàries per tal d’assegurar 

que la còpia Transparent a què s’accedeix seguirà disponible, en la 

ubicació indicada, com a mínim durant un any a comptar des del 

moment en que distribuïu al públic (directament o a través dels vos- 

tres representants o minoristes) l’última còpia Opaca d’aquesta 

edició. 

Es prega, però no s’exigeix, que us poseu en contacte amb els autors 

del Document abans de redistribuir un gran nombre de còpies; 

d’aquesta manera, els autors us podran facilitar una versió actualit- 

zada del Document, si és que n’hi ha alguna. 

323 


ANOTACIONS


ANOTACIONS 

324 


B.5. MODIFICACIONS 

Podeu copiar i distribuir una Versió modificada del Document 

d’acord amb les condicions de les seccions 2 i 3, més amunt, sempre 

que distribuïu la Versió modificada d’acord precisament amb aques- 

ta Llicència, amb la Versió modificada actuant com a Document, au- 

toritzant d’aquesta manera la distribució i modificació de la Versió 

modificada a qualsevol que en posseeixi una còpia. A més, a la Ver- 

sió modificada hi heu de fer el següent: 

A. Utilitzeu a la Pàgina de títol (i a les cobertes, si n’hi ha) un títol di- 

ferent del del Document i del de les versions anteriors (que, si n’hi 

ha, han d’estar detallades a la secció Historial del Document). Po- 

deu utilitzar el mateix títol d’una versió anterior si l’editor original 

d’aquesta versió ho autoritza. 

B. Relacioneu a la Pàgina de títol, com a autors, una o més persones 

o entitats responsables de la realització de les modificacions de la 

Versió modificada, juntament amb almenys cinc dels autors prin- 

cipals del Document (o tots els autors principals, si són menys de 

cinc), tret que ells us dispensin d’aquest requeriment. 

C. Indiqueu a la Pàgina de títol el nom de l’editor de la Versió modi- 

ficada, com a editor. 

D. Conserveu tots els avisos de copyright del Document. 

E. Afegiu, al costat dels altres avisos de copyright, un avís de 

copyright adequat per a les vostres modificacions. 

F. Incloeu, immediatament després dels avisos de copyright, un avís 

de llicència donant autorització pública per utilitzar la Versió mo- 

dificada d’acord amb els termes d’aquesta llicència, en el formu- 

lari que s’indica a l’addendum de més avall. 

G. Conserveu, en aquest avís de llicència, la relació completa de Sec- 

cions invariables i Textos de coberta necessaris que s’indiquen a 

l’avís de llicència del Document. 

H. Incloeu una còpia no alterada d’aquesta Llicència. 

I. Conserveu la secció titulada “Historial” amb el seu títol, i afegiu- 

hi almenys el títol, any, nous autors i editor de la Versió modifica-


da, com s’indica a la Pàgina de títol. Si al Document no hi cap 

secció titulada “Historial” creeu-ne una indicant-hi el títol, any, 

autors i editor del Document com s’indica a la seva Pàgina de tí- 

tol, descrivint-hi també la Versió modificada com s’indica al punt 

anterior. 

J. Conserveu la ubicació de xarxa, si n’hi ha, indicada al Document 

per a l’accés públic a una còpia Transparent del Document, i tam- 

bé les ubicacions de xarxa indicades al Document on es poden 

trobar les versions anteriors en què s’ha basat, que es poden in- 

cloure a la secció “Historial”. Podeu ometre les ubicacions de xar- 

xa d’obres publicades al menys quatre anys abans del propi 

Document, o si l’editor original de la versió a què fa referència us 

hi autoritza. 

K. En qualsevol secció titulada “Agraïments” o “Dedicatòries”, con- 

serveu-ne el títol, i conserveu-hi tota l’essència i to de cadascun 

dels agraïments dels col·laboradors i/o dedicatòries que hi apa- 

reguin. 

L. Conserveu totes les Seccions invariables del Document, sense 

canviar-ne els textos ni els títols. La numeració de seccions o sis- 

temes equivalents no es consideren part dels títols de secció. 

M. Suprimiu qualsevol secció titulada “Aprovacions”. Aquestes secci- 

ons no es poden incloure a la Versió modificada. 

N. No reanomeneu cap secció existent com “Aprovacions”, ni tam- 

poc de cap altra manera que pugui entrar en conflicte amb el títol 

de qualsevol Secció invariable. 

O. Conserveu tots els Descàrrecs de garantia. 

Si la Versió modificada inclou noves seccions preliminars o apèndixs 

que es considerin Seccions secundàries i no continguin material co- 

piat del Document, si ho voleu podeu anomenar totes o algunes 

d’elles com invariables. Per fer-ho, afegiu-ne els títols a la relació de 

Seccions invariables de l’avís de llicència de la Versió modificada. 

Aquests títols han de ser diferents de tots els altres títols de secció. 

Podeu afegir una secció titulada “Aprovacions”, sempre que contin- 

gui solament aprovacions de la vostra Versió modificada fetes per di- 

verses parts; per exemple, declaracions d’experts o afirmant que el 

325 


ANOTACIONS


ANOTACIONS 

326 


text ha estat aprovat per una organització com a definició autoritzada 

d’un estàndard. 

Al final de la relació de Texts de portada de la Versió modificada po- 

deu afegir un text de fins a cinc paraules com a Text de portada, i un 

altre de fins a 25 paraules com a Text de contraportada. Cada entitat 

només pot afegir (o arranjar) un Text de portada i un Text de contra- 

portada. Si el Document ja inclou un text de coberta per a la mateixa 

coberta, que hagueu afegit anteriorment o que s’hagi afegit mitjan- 

çant un arranjament efectuat per la mateixa entitat en nom de la qual 

actueu, no en podeu afegir cap més, però podeu reemplaçar l’antiga 

amb l’autorització expressa de l’editor anterior que la va afegir. 

Per virtut d’aquesta Llicència, el(s) autor(s) i editor(s) del Document no 

us autoritza(en) a utilitzar-ne el(s) nom(s) amb finalitats publicitàries, 

ni afirmen ni queda implícita l’aprovació de qualsevol Versió modifi- 

cada. 

B.6. COMBINACIÓ DE DOCUMENTS 

Podeu combinar el Document amb altres documents publicats 

d’acord amb aquesta Llicència, d’acord amb els termes exposats a 

la secció 4, més amunt, per a les versions modificades, sempre que 

incloeu a l’obra resultant totes les Seccions invariables de tots els do- 

cuments originals, sense modificar, les relacioneu com a Seccions in- 

variables de l’obra resultant en el seu avís de llicència, i en conserveu 

tots els Descàrrecs de garantia. 

A l’obra resultant només cal incloure una còpia d’aquesta Llicència, 

i diverses Seccions invariables idèntiques es poden substituir per una 

sola còpia. Si hi ha diverses Seccions invariables amb el mateix nom, 

però amb continguts diferents, feu que el títol de cadascuna d’elles 

sigui únic afegint-hi, al final i entre parèntesis, el nom de l’autor o 

editor original de la secció (si es coneix) o un nombre únic. Feu la 

mateixa operació als títols de la secció que són a la relació de Secci- 

ons invariables a l’avís de llicència de l’obra resultant.


A l’obra resultant podeu combinar totes les seccions titulades “Histo- 

rial” dels diversos documents originals, donant com a resultat una 

secció titulada “Historial”; combineu de la mateixa manera totes les 

seccions titulades “Agraïments” i totes les titulades “Dedicatòries”. 

Heu de suprimir totes les seccions titulades “Aprovacions”. 

B.7. RECOPILACIONS DE DOCUMENTS 

Podeu crear una recopilació que estigui formada pel Document i al- 

tres documents publicats sota aquesta Llicència, i reemplaçar les cò- 

pies individuals d’aquesta Llicència dels diversos documents per una 

de sola que quedi inclosa a la recopilació, sempre que seguiu les 

normes d’aquesta Llicència pel que fa a la còpia literal de cadascun 

dels documents en tots els altres aspectes. 

Podeu extreure un document individual d’aquesta col·lecció i distri- 

buir-lo individualment sota aquesta Llicència, sempre que inseriu una 

còpia d’aquesta Llicència en el document que ha estat extret i que se- 

guiu aquesta Llicència en tots els altres aspectes relatius a la còpia 

literal del document. 

B.8. AGRUPAMENT AMB OBRES INDEPENDENTS 

Una compilació del Document o els seus derivats amb altres docu- 

ments o obres separades i independents, en qualsevol mena de dis- 

tribució o suport d’emmagatzematge, s’anomena un “agrupament” 

si el copyright que resulta de la compilació no s’utilitza per limitar els 

drets legals dels usuaris de la compilació mes enllà del que permeten 

les obres individuals. Quan el Document inclogui un agrupament, 

aquesta Llicència no s’aplica a les altres obres de l’agrupament que 

no siguin en elles mateixes obres derivades del Document. 

Si el requeriment del Text de portada de la secció 3 és aplicable a 

aquestes còpies del Document, i si el Document és inferior a la meitat 

de tot l’agrupament, els Textos de portada del Document es poden 

327 


ANOTACIONS


ANOTACIONS 

328 


col·locar en cobertes que encerclin solament el Document dins de 

l’agrupament. En cas contrari, han d’aparèixer en cobertes impreses 

que encerclin tot l’agrupament. 

B.9. TRADUCCIÓ 

La traducció es considera una mena de modificació, i, per tant, po- 

deu distribuir traduccions del Document d’acord amb els termes de 

la secció 4. La substitució de les Seccions invariables per traduccions 

requereix un permís especial dels propietaris del copyright, però po- 

deu incloure traduccions d’algunes o totes les Seccions invariables a 

més de les seves versions originals. Podeu incloure una traducció 

d’aquesta Llicència, de tots els avisos de llicència del Document, i de 

tots els Descàrrecs de garantia, sempre que també incloeu la versió 

original en anglès d’aquesta Llicència i les versions originals 

d’aquests avisos i descàrrecs. En cas de desacord entre la traducció 

i la versió original en anglès d’aquesta Llicència, prevaldrà la versió 

original. 

Normalment, si una secció del Document es titula “Agraïments”, 

“Dedicatòries” o “Historial”, degut al requeriment (secció 4) de con- 

servar-ne el Títol (secció 1) caldrà canviar el títol real. 

B.10. CLOENDA 

No podeu copiar, modificar, subllicenciar ni distribuir el Document 

excepte en els casos previstos expressament per aquesta Llicència. 

Qualsevol altre intent de copiar, modificar, subllicenciar o distribuir 

el Document serà nul i causarà la finalització immediata dels vostres 

drets d’acord amb aquesta Llicència. No obstant això, les parts que 

hagin rebut còpies o drets a través vostre, d’acord amb aquesta Lli- 

cència, en seguiran gaudint, atès que aquestes parts en segueixen 

complint els acords.


B.11. REVISIONS FUTURES D’AQUESTA LLICÈNCIA 

De tant en tant, la Free Software Foundation pot publicar noves ver- 

sions revisades de la Llicència de documentació lliure de GNU. L’es- 

sència d’aquestes versions serà similar a la de la present, però poden 

diferir en els detalls per contemplar nous problemes o assumptes. 

Consulteu http://www.gnu.org/copyleft/. 

Cada versió de la Llicència té un número de versió únic; si el Docu- 

ment indica que s’hi aplica una determinada versió numerada 

d’aquesta Llicència “o qualsevol versió posterior”, teniu l’opció de se- 

guir els termes i condicions d’aquella versió o de qualsevol versió 

posterior que hagi estat publicada (no com a esborrany) per la Free 

Software Foundation. Si el Document no indica cap versió de la Lli- 

cència, podeu escollir qualsevol versió que hagi estat publicada (no 

com a esborrany) per la Free Software Foundation. 

B.12. ADDENDA: COM UTILITZAR AQUESTA 

LLICÈNCIA PER ALS VOSTRES DOCUMENTS 

Per utilitzar aquesta Llicència en un document que hagueu escrit, in- 

cloeu-hi una còpia de la Llicència i afegiu els avisos de copyright i de 

llicència següents immediatament després de la pàgina de títol: 

Copyright (c) [ANY] [EL VOSTRE NOM]. 

Permission is granted to copy, distribute and/or modify this do- 

cument under the terms of the GNU Free Documentation License, Ver- 

sion 1.2 or any later version published by the Free Software 

Foundation; with no Invariant Sections, no Front-Cover Texts, and 

no Back-Cover Texts. 

A copy of the license is included in the section entitled "GNU Free 

Documentation License". 

Si teniu Seccions invariables, Textos de portada i Textos de contrapor- 

tada, substituïu la línia “with... Texts.” per això: 

with the Invariant Sections being RELACIÓ DE TÍTOLS DE LES SECCIONS 

INVARIABLES, with the Front-Cover Texts being RELACIÓ DE TÍTOLS 

DELS TEXTOS DE PORTADA, and with the Back-Cover Texts being RELACIÓ 

DE TÍTOLS DELS TEXTOS DE CONTRAPORTADA. 

329 


ANOTACIONS


ANOTACIONS 

330 


Si teniu Seccions invariables sense Textos de portada, o alguna altra 

combinació dels tres, combineu aquestes dues alternatives per reflec- 

tir la situació. 

Si el vostre document conté exemples no trivials de codi de progra- 

ma, recomanem publicar-los de forma paral·lela sota una llicència 

de programari lliure, com ara la Llicència General Pública de GNU, 

per permetre’n l’ús en programari lliure. 

Traducció per Softcatalà

U 

Universitat Oberta 

de Catalunya 

Formació de Postgrau

Introducció al programari lliure - Universitat Oberta de Catalunya

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?