www-es-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-traductores] Actualizacion /philosophy/java-trap.es.html


From: Exal de Jesus Garcia Carrillo
Subject: Re: [GNU-traductores] Actualizacion /philosophy/java-trap.es.html
Date: Wed, 27 Dec 2006 17:45:32 -0500
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Antonio Regidor Garc?a <address@hidden>  wrote:
> Hola:
> 
> De momento te comento lo que llevo mirado:
> 
> Para los lenguajes de programación, en este tipo de frase yo siempre he visto 
> «del», no «de» (del
> C, del Pascal, del Java, ...). «De Java» se usa con la isla, pero no con el 
> lenguaje. Pasa lo
> mismo con los idiomas: del español, del inglés, ...
> 
> «Libre pero encadenado. La trampa de Java»: Le falta el punto al final. Si el 
> título es una sola
> frase se suele poner sin punto, pero si son dos queda un poco raro que la 
> primera lleve punto y la
> segunda no.
> 
> «ético — pero hay una trampa de la que debe estar atento —.» -> «ético —pero 
> hay una trampa a la
> que debe estar atento—.» (espacios y «a»).
> 
> «(vea http://www.gnu.org/philosophy/free-sw.es.html)» -> «(véase
> http://www.gnu.org/philosophy/free-sw.es.html)».
> 
> «Que un programa dado sea software libre, depende únicamente de los términos 
> de su licencia.»: La
> coma sobra. Entre el sujeto y el verbo de una frase nunca hay coma, salvo que 
> haya una expresión
> incidental en medio.
> 
> «Si el programa se puede usar» -> «Que el programa se pueda usar» (igual que 
> en la frase
> anterior).
> 
> «mundo Libre» -> «mundo libre».
> 
> «la propia licencia del programa» -> «la licencia del propio programa»: 'Own' 
> se refiere al
> programa, no a la licencia. La licencia del propio programa se contrapone a 
> las licencias del
> programa y el compilador de Java (aquí pongo «de», pasa lo mismo con los 
> idiomas: profesor de
> español <-> Historia del español).
> 
> «funcionalidades» -> «funciones»: La funcionalidad es la cualidad de ser 
> funcional.
> 
> «libre—es inusable en el mundo Libre—.» -> «libre —es inusable en el mundo 
> libre—.»
> 
> «causas de este problema» -> «causantes de este problema».
> 
> «sienten que Java es sexy» -> «cree que el Java es sexy»: «Sentir» se emplea 
> para emociones o
> percepciones de los sentidos, mientras que «creer», para opiniones o 
> creencias, y debe ir en
> singular para concordar con «gente».
> 
> «atracción hacia el lenguaje» -> «atracción por el lenguaje».
> 
> «descuidan el asunto» -> «descuidan el problema».
> 
> «dependencias, y caen» -> «dependencias y caen».
> 
> «La implementación de Sun de Java» -> «La implementación de Java de Sun» 
> (menos confusa).
> 
> «Tenemos implementaciones» -> «Sí que tenemos implementaciones» (traducción 
> del «do»).
> 
> «el compilador de Java de GNU GCJ»: Si lo pones en ese orden tienes que poner 
> comas, «el
> compilador de Java de GNU, GCJ,», ya que GNU solo tiene un compilador de 
> Java. Si cambias el orden
> puedes dejarlo sin comas, «el compilador de Java GCJ de GNU», porque hay 
> muchos compiladores de
> Java.
> 
> «GNU Classpath» -> «Classpath de GNU», igual que «GPL de GNU».
> 
> «soportan todas las funcionalidades» -> «tienen todas las funciones»: 
> 'Soportar' no tiene ese
> significado en español, http://www.xcastro.com/errores.html
> 
> «Pero estamos detrás de ellas.» -> «Estamos detrás de ellas.»: No hay 'pero' 
> en el original.
> También se podría poner «estamos poniéndonos a su altura» o «estamos 
> intentando alcanzarlas», etc.
> 'Estar detrás de ellas' no indica un avance, como creo que hace el original, 
> simplemente que se va
> por detrás.
> 
> Ya he dicho otras veces que «desarrollar» no es sinónimo de «construir», como 
> el inglés 'develop',
> sino de «aumentar», que no es lo mismo. Para un programa yo no diría 
> «desarrollar» sino
> «escribir», «elaborar», «construir», etc.
> 
> «y casi todas ellas»: «ellas» se puede quitar; aunque no está mal, no es 
> necesaria.
> 
> El texto inglés cambia de «specification» a «specifications» y luego otra vez 
> a «specification» en
> la misma frase. Seguramente es una errata, habría que ponerlas todas iguales 
> en la traducción.
> 
> La raya larga del final del artículo está mal colocada, va después del enlace.
> 
> 
> 
> Todavía me faltan 6 o 7 párrafos pero por hoy tengo que dejarlo aquí. Un 
> saludo.
> 
> Antonio Regidor García
> 


Gracias Antonio, estoy de acuerdo contigo en los puntos que mencionas,
te envío el archivo corregido.


Libre pero encadenado. La trampa del Java.

por Richard Stallman

Nota

En diciembre de 2006, Sun está en pleno relanzamiento de su plataforma Java bajo la GPL de GNU. Cuando este cambio de licencia haya terminado, esperamos que Java ya no sea una trampa. A pesar de eso, el problema general descrito aquí seguirá siendo importante, porque cualquier biblioteca no libre o plataforma de programación puede causar un problema similar. Debemos aprender una lección de la historia del Java, para poder evitar otras trampas en el futuro.

12 de abril de 2004

Si su programa es software libre, básicamente es ético — pero hay una trampa de la que debe estar atento —. Su programa, aunque en sí mismo libre, puede estar limitado por software no libre del que dependa. A día de hoy este problema es notable, sobre todo, en los programas en Java, por lo que lo llamamos «la trampa del Java».

Un programa es software libre si sus usuarios tienen ciertas libertades esenciales. Sin entrar en detalles, éstas son: la libertad de usar el programa, la libertad de estudiar y modificar el código fuente, la libertad de distribuir el código y los binarios, y la libertad de publicar versiones mejoradas (véase http://www.gnu.org/philosophy/free-sw.es.html). Que un programa dado sea software libre depende únicamente de los términos de su licencia.

Que el programa se pueda usar en el mundo libre, por la gente que quiere vivir en libertad, es una pregunta más compleja. Esto no lo determina la licencia del propio programa, porque ningún programa funciona aislado. Todos los programas dependen de otros programas. Por ejemplo, un programa necesita ser compilado o interpretado, así que depende de un compilador o un intérprete. Si es compilado a byte code, depende de un intérprete de byte code. Además, necesita bibliotecas para ejecutarse, y también puede invocar a otros programas aparte que se ejecutan en otros procesos. Todos estos programas son dependencias. Las dependencias pueden ser necesarias para que el programa pueda ejecutarse, o pueden ser necesarias solamente para ciertas funciones. En cualquier caso, todo o parte del programa no puede funcionar sin las dependencias.

Si algunas de las dependencias de un programa no son libres, entonces todo o parte del programa no se puede ejecutar en un sistema completamente libre —es inusable en el mundo Libre—. Ciertamente podemos distribuir el programa y tener copias en nuestras máquinas, pero eso no sirve de mucho si no podemos ejecutarlo. El programa es software libre, pero en la práctica está encadenado por sus dependencias no libres.

Este problema puede suceder en cualquier tipo de software, en cualquier lenguaje. Por ejemplo, un programa libre que solamente funcione sobre Microsoft Windows es claramente inusable en el mundo Libre. Pero el software que funciona sobre GNU/Linux también puede ser inútil si depende de otro software no libre. En el pasado, Motif (antes de que tuviéramos LessTif) y Qt (antes de que sus desarrolladores lo hicieran software libre) fueron importantes causantes de este problema. La mayoría de las tarjetas gráficas 3D solamente funcionan a pleno rendimiento con controladores no libres, que también originan este problema. Pero hoy, la mayor fuente de este problema es Java, porque la gente que escribe software libre a menudo cree que el Java es sexy. Cegados por su atracción por el lenguaje, descuidan el problema de las dependencias y caen en la trampa del Java.

La implementación del Java de Sun no es libre. Blackdown tampoco es libre; es una adaptación del código privativo de Sun. Las bibliotecas estándar del Java tampoco son libres. Sí que tenemos implementaciones libres del Java, como el compilador de Java GCJ de GNU y Classpath de GNU, pero todavía no tienen todas las funcionalidades. Estamos intentando alcanzarlas.

Si usted escribe un programa en Java sobre la plataforma Java de Sun, está expuesto a usar funcionalidades exclusivas de Sun sin ni siquiera darse cuenta. Para cuando se dé cuenta, quizás las haya estado usando durante meses, y rehacer el trabajo le tomaría más meses. Podría decir «volver a empezar es demasiado trabajo». Entonces su programa habrá caído en la trampa del Java; será inusable en el mundo Libre.

La manera fiable de evitar la trampa del Java es tener en su sistema solamente una implementación libre del Java. Así, si usted usa una funcionalidad o biblioteca del Java que el software libre todavía no soporta, se dará cuenta en seguida, y podrá reescribir ese código de inmediato.

Sun continúa desarrollando bibliotecas «estándar» del Java adicionales, y casi todas son no libres; en muchos casos, incluso la especificación de la biblioteca es un secreto comercial, y la última licencia de Sun para esta especificación prohíbe publicar nada que sea menos que una implementación completa de la especificación (véase http://jcp.org/aboutJava/ communityprocess/JSPA2.pdf y http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html, para encontrar ejemplos).

Afortunadamente, la licencia de esa especificación permite publicar una implementación como software libre; a otros que reciban la biblioteca se les permite modificarla y no se les exige adherirse a la especificación. Pero el requisito tiene el efecto de prohibir el uso de un modelo cooperativo de desarrollo para producir la implementación libre. El uso de ese modelo implicaría la publicación de versiones incompletas, que aquellos que han leído la especificación no están autorizados a hacer.

En los primeros días del Movimiento del Software Libre, era imposible evitar depender de programas no libres. Antes de que tuviéramos el compilador de C de GNU, todos los programas en C (libres o no) dependían de un compilador de C no libre. Antes de que tuviéramos la biblioteca de C de GNU, todos los programas dependían de una biblioteca de C no libre. Antes de que tuviéramos Linux, el primer núcleo libre, todos los programas dependían de un núcleo no libre. Antes de que tuviéramos Bash, todos los scripts de shell tenían que ser interpretados por un intérprete de órdenes no libres. Era inevitable que nuestros primeros programas estuvieran afectados al principio por estas dependencias, pero lo aceptamos porque nuestro plan incluía su posterior rescate. Nuestra meta final, un sistema operativo GNU autosuficiente, incluía sustitutos libres para todas estas dependencias; si alcanzábamos la meta, todos nuestros programas serían rescatados. Y así sucedió: con el sistema GNU/Linux, ahora podemos ejecutar estos programas en plataformas libres.

La situación hoy es diferente. Tenemos potentes sistemas operativos libres y muchas herramientas libres de programación. Cualquier trabajo que usted quiera hacer, lo puede hacer en una plataforma libre; no hay necesidad de aceptar una dependencia no libre ni siquiera temporalmente. La principal razón por la que la gente cae hoy en la trampa es porque no piensan en ello. La solución más fácil al problema de la trampa del Java es enseñar a la gente a no caer en ella.

Para mantener su código Java a salvo de la trampa del Java, instale un entorno de desarrollo del Java libre y úselo. De forma más general, cualquiera que sea el lenguaje que use, mantenga sus ojos abiertos, y compruebe el estado de libertad de los programas de los que dependa su código. La manera más fácil de verificar que un programa es libre es buscarlo en el Directorio de Software Libre. Si un programa no está en el directorio, puede comprobar si su licencia está en la lista de licencias de software libre.

Estamos intentando rescatar a los programas en atrapados en el Java, así que si a usted le gusta el lenguaje Java, le invitamos a ayudar en eldesarrollo de GNU Classpath. También es útil probar sus programas con el compilador (GJC) y GNU Classpath, e informar de cualquier problema que encuentre en clases ya implementadas. Sin embargo, finalizar GNU Classpath tomará tiempo; si se siguen añadiendo más bibliotecas no libres, nunca podremos tener todas las últimas. Así que, por favor, no encadene su software libre. Cuando escriba una aplicación, escríbala para que funcione desde el principio sobre componentes libres.

Véase también:

The Curious Incident of Sun in the Night-Time


Traducciones de esta página


reply via email to

[Prev in Thread] Current Thread [Next in Thread]