1. 1 Nota a la edición
2. 2 El proyecto gnu
3. 3 La primera comunidad que comparte software
4. 4 EL colapso de la comunidad
5. 5 Una elección moral radical
6. 6 Libre en su acepción de libertad
7. 7 El software GNU y el Sistema GNU
8. 8 Los inicios del proyecto
9. 9 Los primeros pasos
10. 10 Gnu emacs
11. 11 ¿Un programa es libre para cualquier usuario?
12. 12 El Copyleft y la GNU GPL
13. 13 La Free Software Foundation
14. 14 Los servicios relacionados con el software libre
15. 15 Los objetivos técnicos
16. 16 La donación de ordenadores
17. 17 La lista de tareas de GNU
18. 18 La librería GNU GPL
19. 19 ¿Un reto personal?
20. 20 Acontecimientos inesperados
21. 21 El gnu hurd
22. 22 Alix
23. 23 Linux y GNU/Linux
24. 24 Los retos futuros
25. 25 Hardware secreto
26. 26 Librerías no libres
27. 27 Patentes de software
28. 28 Documentación libre
29. 29 Es necesario hablar de libertad
30. 30 «Open Source» (código fuente abierto)
31. 31 ¡Inténtalo!
32. 32 Notas
33. 33 El manifiesto gnu
34. 34 ¿Qué es GNU? ¡Gnu No es Unix!
35. 35 Por qué... GNU
36. 36 Notas
37. 37 La definición de software libre
38. 38 Por qué el software no debe tener propietarios
39. 39 Notas
40. 40 ¿Qué encierra un nombre?
41. 41 Notas
42. 42 Por qué software libre es mejor que open source
43. 43 Relación entre el movimiento del software libre
44. 44 Comparación de los dos términos
45. 45 ¿Podría ayudar una marca registrada?
46. 46 Malentendidos del «open source»
47. 47 Notas
48. 48 Cómo promover el software libre si trabajas en la universidad
49. 49 Notas
50. 50 Vender software libre
51. 51 El software libre necesita documentación libre
52. 52 La canción del software libre
53. 53 El derecho a leer
54. 54 Malinterpretar el copyright
55. 55 El copyright en la Constitución de los Estados Unidos
56. 56 El «contrato2 de copyright»
57. 57 El primer error: «equilibrar la balanza»
58. 58 ¿Qué se contraequilibra?
59. 59 Mejor concesión que «equilibrio»
60. 60 El segundo error: maximizar la producción
61. 61 La retórica de la maximización
62. 62 El tercer error: maximizar el poder de los editores
63. 63 Resultados de los tres errores
64. 64 Encontrar el contrato adecuado
65. 65 Una nota personal
66. 66 Notas
67. 67 La ciencia debe desachar el copy right
68. 68 ¿Qué es el copy Left?
69. 69 Notas
70. 70 Copyleft: idealismo pragmatico
71. 71 Notas
72. 72 El peligro de las patentes de software
73. 73 Evitar la patente
74. 74 Obtener la licencia de la patente
75. 75 Revocar la patente en un juicio
76. 76 Notas
77. 77 ¿Pues confiar en tu ordenador?
78. 78 Postcriptum
79. 79 Porque el software debe ser libre
80. 80 Cómo los propietarios justifican su poder
81. 81 El argumento en contra de la propiedad del software
82. 82 El perjuicio ocasionado por obstaculizar el software
83. 83 Obstaculizar el uso de programas
84. 84 La cohesión social dañada
85. 85 Obstruir la adaptación personalizada de programas
86. 86 Obstaculizar el desarrollo del software
87. 87 No importa cómo se restringe el acto de compartir
88. 88 El software debería ser libre
89. 89 Por qué la gente desarrollara software
90. 90 Programar es divertido
91. 91 Financiar el software libre
92. 92 ¿Qué deben los usuarios a los desarrolladores?
93. 93 ¿Qué es la productividad del software?
94. 94 ¿Es inevitable la competencia?
95. 95 « ¿Por qué no nos vamos a Rusia?»
96. 96 La cuestión de las premisas
97. 97 Conclusión
98. 98 Notas
99. 99 Copyright y globalización en la era de las redes informaticas
100. 100 La historia del copyright
101. 101 Globalización
102. 102 Repensar el copyright
103. 103 Turno de preguntas
104. 104 Notas
105. 105 Software libre: libertad y cooperación
106. 106 Software libre: libertad y cooperación (I)
107. 107 Software libre: libertad y cooperación (II)
108. 108 Turno de preguntas
109. 109 Notas
110. 110 APÉNDICE A: Licencia Pública General GNU
111. 111 Términos y condiciones para la copia, distribución y modifica
112. 112 Apéndice. Cómo aplicar estos términos a sus nuevos pro
113. 113 APÉNDICE B: Licencia Pública General Menor
114. 114 Términos y condiciones para la copia, distribución y modifica
115. 115 Cómo aplicar estos términos a sus nuevas bibliotecas
116. 116 APÉNDICE C: Licencia de Documentación Libre GNU
117. 117 Aplicabilidad y definiciones
118. 118 Copia literal
119. 119 Copia en cantidades masivas
120. 120 Modificaciones
121. 121 Combinar documentos
122. 122 Colecciones de documentos
123. 123 Combinación con trabajos independientes
124. 124 Traducción
125. 125 Nulidad
126. 126 Futuras revisiones de esta licencia
127. 127 Addenda

48 - Cómo promover el software libre si trabajas en la universidad

Curso gratis creado por Richard M. Stallman. Extraido de: http://sindominio.net/biblioweb/pensamiento/softlibre/

17 de Diciembre de 2005

< anterior | 1 ... 46 47 48 49 50 51 52 ... 127 | siguiente >

En el movimiento del software libre creemos que los usuarios de ordenadores deberían tener libertad para cambiar y redistribuir el software que utilizan. El adjetivo «libre» en el software libre hace referencia a la libertad: libertad del usuario para ejecutar, modificar y redistribuir software. El software libre contribuye al saber humano, al contrario que el software propietario. Por este motivo, las universidades deberían fomentar el software libre, para hacer una aportación al progreso del conocimiento humano, del mismo modo que deben animar a científicos y académicos a publicar sus obras.

---

Pero el software (y la ciencia) despiertan la codicia en un gran número de gerentes universitarios: consideran los programas como una potencial fuente de ingresos, y no como aportaciones al saber humano. Los programadores de software libre llevan conviviendo con esta tendencia desde hace casi veinte años.

---

Cuando comencé a desarrollar el sistema operativo GNU en 1984, lo primero que hice fue renunciar a mi trabajo en el MIT. Hice esto precisamente para que así la oficina de licencias del MIT fuera incapaz de interferir en la publicación de GNU como software libre. Había diseñado una estrategia para licenciar los programas contenidos en GNU que garantizaría que todas las versiones modificadas seguirían siendo software libre, una estrategia que acabaría convirtiéndose en la GNU General Public License (GNU GPL).2 No quería tener que rogarle a la administración del MIT que me permitiera usarla.

---

Con el paso de los años, varias filiales universitarias han acudido con frecuencia a la Free Software Foundation para asesorarse sobre la forma de negociar con los gerentes que opinan que el software es tan sólo algo que vender. Un buen método, aplicable incluso a proyectos específicamente financiados, consiste en basar su trabajo en un programa ya existente publicado con GNU GPL. De esta forma, se puede responder a los gerentes: «No podemos publicar la versión modificada, a menos que sea con GNU GPL, de otro modo estaríamos infringiendo el copyright». Una vez desaparecido cualquier rastro del símbolo del dólar de sus ojos, por lo general consentirán en publicarlo como software libre.

---

También se puede pedir ayuda al patrocinador del proyecto. Cuando un equipo de la NYU (Universidad de Nueva York) desarrolló el compilador GNU Ada con fondos procedentes de las Fuerzas Aéreas de los EE.UU., el contrato especificaba que el código resultante se donaría a la Free Software Foundation. Primero se negocia el acuerdo con el patrocinador, luego se explica cortésmente a la administración de la universidad que no habrá renegociación de ninguna clase. Dado que la administración prefiere tener un contrato para desarrollar software libre antes que quedarse con las manos vacías, lo más probable es que acepten el trato.

---

Hagáis lo que hagáis, habrá que plantear la cuestión cuanto antes —desde luego, antes de que el programa esté a medio camino. Llegados este punto, la universidad todavía os necesita, así que podréis jugar duro: advertir a la administración de que el programa se terminará y se dejará listo para ser usado, siempre y cuando acuerden por escrito convertirlo en software libre —y acepten la licencia de software libre de vuestra elección. De lo contrario, sólo alcanzaréis a escribir una ponencia al respecto y nunca desarrollaréis una versión lo bastante buena para publicarse. Cuando los gestores comprendan que sus opciones se limitan a tener un paquete de software libre que aportará prestigio a la universidad o nada de nada, por lo general se decantarán por la primera opción.

---

No todas las universidades tienen políticas codiciosas. La política de la Universidad de Texas tiene una política que facilita que todo el software desarrollado en ella se publique como software libre bajo la licencia GPL. Univates en Brasil y el Indian Institute of Information Technology en Hyberabad, India, practican políticas de publicación de software con GPL. Si os ganáis primero el apoyo del profesorado, es posible que logréis instituir una política semejante en vuestra universidad. Exponedlo como una cuestión de principio: ¿tiene la universidad la misión de contribuir al progreso del saber humano o su único objetivo es perpetuarse a sí misma?

---

Sea cual sea vuestra postura, siempre conviene mostrar determinación y adoptar una perspectiva ética, tal y como lo hacemos nosotros en el movimiento del software libre. Si deseamos tratar al público éticamente, el software debería ser libre en el sentido de libertad para todos.3

---

Muchos programadores de software libre se limitan a alegar razones prácticas: defienden que el software se comparta con otros y se modifique como forma de acelerar la creación de un software potente y fiable. Si son estos valores los que os mueven a desarrollar software libre, muy bien, se agradece vuestra contribución. Pero no son la clase de valores que os permitirán hacer frente con firmeza a los gestores de la universidad que pretendan hacer propietario vuestro programa.

---

Por ejemplo, pueden aducir: «podríamos hacer mas potente y fiable el programa con todo el dinero que se obtenga de las ventas». Esto puede resultar cierto o no, pero a priori es difícil presentar argumentos en contra. Pueden sugerir una licencia que ofrezca copias «gratuitas, sólo para uso académico», y así lanzar el mensaje al público de que no merecen esa libertad y además alegar que de esta manera lograrías la cooperación de la comunidad académica, que es —razonarían— todo lo que necesitas.

---

Si se parte de unos valores «pragmáticos», es difícil plantear buenas razones para rechazar estas propuestas, que son en realidad un callejón sin salida, sucede lo contrario al fundamentar nuestra postura en valores éticos y políticos. ¿De qué serviría un programa potente y fiable a costa de la libertad de los usuarios? ¿No debería la libertad estar presente tanto fuera como dentro de la academia? Las respuestas resultan obvias siempre que la libertad y el bien de la comunidad figuren entre nuestros objetivos. El software libre respeta la libertad de los usuarios, mientras que el software propietario la niega.

---

Nada mejor que ser consciente, en este caso en concreto, para aumentar nuestra determinación de que la libertad de la comunidad depende de nosotros.

< anterior | 1 ... 46 47 48 49 50 51 52 ... 127 | siguiente >

Cursos gratis relacionados con 'Software libre para una sociedad libre'

Anuncios Google

Autor y licencia de 'Software libre para una sociedad libre'

Curso gratis de Richard M. Stallman. Extraido de: http://sindominio.net/biblioweb/pensamiento/softlibre/