From 1ae0306a3cf2ea27f60b2d205789994d260c2cce Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 11 Oct 2020 13:29:45 +0200 Subject: add i18n FSFS --- talermerchantdemos/blog/articles/es/free-doc.html | 239 ++++++++++++++++++++++ 1 file changed, 239 insertions(+) create mode 100644 talermerchantdemos/blog/articles/es/free-doc.html (limited to 'talermerchantdemos/blog/articles/es/free-doc.html') diff --git a/talermerchantdemos/blog/articles/es/free-doc.html b/talermerchantdemos/blog/articles/es/free-doc.html new file mode 100644 index 0000000..7afea5c --- /dev/null +++ b/talermerchantdemos/blog/articles/es/free-doc.html @@ -0,0 +1,239 @@ + + + + + + +Por qué el software libre necesita documentación libre - Proyecto GNU - Free +Software Foundation + + + +

Por qué el software libre necesita documentación libre

+ +

+ Únase a nuestra lista de +distribución sobre el peligro de los libros electrónicos (en inglés). +

+ + + +

+La mayor carencia de los sistemas operativos libres no se encuentra en el +software, sino en la falta de buenos manuales libres que los +acompañen. Muchos de nuestros programas más importantes no incluyen manuales +completos. La documentación es una parte esencial de cualquier paquete de +software. Cuando un paquete importante de software libre no incluye un +manual libre, ello supone una laguna significativa. Hoy en día existen +muchas lagunas de este tipo.

+ +

+Una vez, hace muchos años, se me ocurrió aprender Perl. Obtuve una copia de +un manual libre, pero me resultó difícil de leer. Cuando pregunté a los +usuarios de Perl si existían alternativas, me dijeron que existían mejores +manuales introductorios pero que no eran libres (no eran respetuosos con la +libertad).

+ +

+¿Por qué era así? Los autores de los buenos manuales los habían escrito para +O'Reilly Associates, que los publicaban con cláusulas restrictivas (no +copiar, no modificar, archivos fuente no disponibles) que hacían que no +fueran libres, lo que los dejaba fuera del mundo libre.

+ +

+No era la primera vez que pasaba algo así y, para gran pérdida de nuestra +comunidad, no fue, ni mucho menos, la última. Desde entonces, los editores +de manuales privativos han exhortado a muchos autores a restringir sus +manuales. En muchas ocasiones he escuchado a algún usuario de GNU hablarme +entusiasmado del manual que está escribiendo, con el que espera ayudar al +proyecto GNU, para luego truncar mis esperanzas al explicarme que ya había +firmado un contrato con una editorial que lo iba a restringir de tal modo +que no podríamos usarlo.

+ +

+Dado que escribir en un buen inglés es una habilidad poco frecuente entre +los programadores, no podemos permitirnos perder manuales de esta forma.

+ +

+ La documentación libre, como el software libre, es una cuestión de +libertad, no de precio. El problema con estos manuales no era que O'Reilly +Associates cobrara un precio por las copias impresas, pues eso de por sí no +está mal (la Free Software Foundation también vende copias impresas de manuales de GNU) que son libres. La diferencia es +que los manuales de GNU están disponibles en forma de código fuente, +mientras que esos manuales están disponibles únicamente en papel. Los +manuales de GNU se distribuyen con permiso para copiarlos y modificarlos, +mientras los manuales de Perl no incluyen tales permisos. Estas +restricciones son el problema.

+ +

+ El criterio para que un manual sea libre es prácticamente el mismo que para +el software: se trata de dar ciertas libertades a todos los usuarios. La +redistribución (incluida la redistribución comercial) debe permitirse, de +manera que cada copia de un programa pueda ir acompañada de su manual, en +línea o en papel. El permiso para modificarlo también es crucial.

+ +

+Como regla general, no creo que sea indispensable otorgar el permiso para +modificar todo tipo de artículos y libros. Las cuestiones relativas a los +escritos no son necesariamente las mismas que competen al software. Por +ejemplo, no creo que ni usted ni yo estemos obligados a otorgar permiso para +modificar artículos como este, que describen nuestras acciones y nuestros +puntos de vista.

+ +

+Pero hay una razón en concreto por la que la libertad para modificar es +crucial en la documentación del software libre. Cuando alguien ejerce su +derecho a modificar el software añadiendo o cambiando sus características, +también cambiará el manual, si se trata de una persona meticulosa. De este +modo proporcionará una documentación precisa y utilizable con el programa +modificado. Un manual que impide a los programadores ser meticulosos y +acabar el trabajo, o que, más precisamente, requiere que escriban un nuevo +manual desde cero si cambian el programa, no satisface las necesidades de +nuestra comunidad.

+ +

+Mientras que una prohibición general es inaceptable, ciertas limitaciones al +método de modificación no suponen ningún problema. Por ejemplo, establecer +requisitos para que se conserve la nota de copyright original del autor, los +términos de distribución o la lista de autores, está bien. Tampoco supone +ningún problema requerir que las versiones modificadas incluyan una nota +indicando que lo han sido, o incluso prohibir que se borren o modifiquen +secciones enteras, siempre que estas traten de temas que no sean técnicos +(algunos manuales de GNU las tienen).

+ +

+Este tipo de restricciones no suponen un problema porque, en la práctica, no +impiden que el programador adapte el manual al programa modificado. En otras +palabras, no impiden que la comunidad del software libre aproveche +plenamente el manual.

+ +

+ Sin embargo, tiene que ser posible modificar todo el contenido +técnico del manual, para luego distribuir el resultado utilizando +cualquiera de los soportes y canales habituales. De lo contrario, las +restricciones paralizan a la comunidad, el manual no es libre y, por tanto, +necesitamos otro.

+ +

+Desgraciadamente, a menudo es difícil encontrar a alguien que escriba otro +manual cuando ya existe uno privativo. El principal obstáculo es que muchos +usuarios consideran que un manual privativo es suficiente, así que no +sienten la necesidad de escribir uno libre. No ven que el sistema operativo +libre tiene una laguna que hay que cubrir.

+ +

+¿Por qué los usuarios piensan que basta con disponer de manuales privativos? +Algunos ni siquiera se han planteado la cuestión. Espero que este artículo +consiga de algún modo cambiar eso.

+ +

+Otros usuarios consideran que los manuales privativos son aceptables por la +misma razón que tanta gente considera que el software privativo es +aceptable. Consideran solo los aspectos puramente prácticos, sin atender al +criterio de la libertad. Estas personas tienen derecho a sus opiniones, pero +dado que estas opiniones se apoyan en valores en que no incluyen la +libertad, no pueden servir de guía a quienes sí la valoramos.

+ +

+Tenga a bien difundir este mensaje. Seguimos perdiendo manuales en beneficio +de las publicaciones privativas. Si difundimos el mensaje de que los +manuales privativos no son suficientes, quizás la siguiente persona que +quiera ayudar a GNU escribiendo documentación se dará cuenta, antes de que +sea demasiado tarde, de que ante todo debe hacerla libre.

+ +

+Podemos también alentar a las editoriales comerciales a vender manuales +libres, con copyleft, en vez de manuales privativos. Una forma de ayudar a +que esto ocurra es revisar los términos de distribución de un manual antes +de comprarlo y preferir manuales con copyleft a manuales sin copyleft.

+

+ [Nota: Tenemos una página con un +listado de libros libres de otros editores].

+ +
+ + +
+ + + + + + + + -- cgit v1.2.3