Historias
Slashboxes
Comentarios
 

Eben Moglen habla sobre la GPL 3: el proceso y los cambios para el siguiente borrador

editada por Candyman el 25 de Junio 2006, 23:16h   Printer-friendly   Email story
desde el dept. yo-estuve-allí,-y-vosotros-no
He tardado un par de días en pasar a limpio la conferencia de Eben Moglen sobre la GPLv3 y, sobre todo, las preguntas y respuestas. No tomé más notas de la conferencia porque el resto, pese a ser interesante, estaba muy fragmentado. El viernes se habló mucho de DRM, por ejemplo, y de cómo el DRM estorba el trabajo de los equipos que se ocupan de investigar las violaciones de la GPL. Pero confieso que yo seguía con la cabeza en Moglen y en sus explicaciones. Moglen habló de todas las novedades de la GPL con gran detalle, incluso describiendo las diferencias previstas para el tercer borrador (que se espera que se publique en julio), pero comenzó con una arenga que parecía una versión geek de la de Ricardo III.

"A por ellos, que son pocos y cobardes"

Soy Eben Moglen, soy un abogado que trabaja en la producción de la libertad, principalmente para un solo cliente, creo que ya lo conocéis. [risas]

Como ciudadanos de una república libre, os voy a dar un montón de explicaciones sobre nuestro trabajo. Pero antes de hacerlo, una noticia: el señor Gates se ha rendido. Cuando un ejecutivo en EEUU dimite, hay un proceso obligatorio de calmar al mercado. Uno no se retira en menos de dos años sin aviso, esto daría la sensación de discontinuidad. Dos años de aviso es el mínimo. No es "todo va bien, ha dado dos años de aviso". Es que menos de dos años sería catastrófico.

Este aviso se produce cinco meses antes del producto más crucial en diez años. Todo lo que sea otro análisis es irrelevante (promesas de seguir hasta los 50 años). Lo estoy describiendo con justicia cuando lo describo como rendición personal. No puede haber mejores noticias que esta otra: además le deja la compañía a Ballmer.

Nosotros vamos bien con nuestro proyecto más importante en 15 años. Y Stallman, con 54 años, no se retira. Gates se retira y le deja el campo a hombres más jóvenes, como el señor Stallman.

Sobre el proceso

Es un proceso de discusión, escuchamos lo que dice la gente sobre las licencias. Lo primero que a la gente le parecía, que es que la GPL v2 es perfecta. Todos los cambios les parecían malos, luego la licencia debía ser perfecta. Esto no me sorprende, a la gente le molestan los cambios. Pero esto significa que si todo se tuerce y no podemos lanzar la GPLv3 aún tendremos una licencia perfecta, pues a la gente así le parece. Pero nosotros queremos cambiarla.

Se dieron rumores de que no íbamos a escuchar a nadie, que todo era un truco, y que Stallman iba a tomar las decisiones él solo. Incluso algunos dijeron que yo tomaría todas las decisiones yo solo. Obviamente, quienes dicen esto último no conocen al señor Stallman.

Queremos un proceso en el que nadie se prive de opinar. Hicimos comités organizados por roles sociales: vendedores de hardware y software, lideres de proyectos de software, ejecutivos de compañías que usan software bajo la GPL, y de compañías que desarrollan y distribuyen software bajo la GPL, representantes institucionales, hackers individuales de prestigio...

Los comités funcionan de muchas maneras: el comité D (el de los hackers) funciona principalmente por IRC y listas de correo (que además tienen archivos públicos), pero otros comités más compuestos de ejecutivos de compañías hacen "conference calls" [algo así como partylines de negocios, N. del E.], cada uno usa los medios de interacción más cómodos o a los que más acostumbrados están.

El software que hemos desarrollado nos ha ayudado a realizar el proceso de comentario del borrador de la licencia. La herramienta visual permite ver dónde se concentran los comentarios, y es un software muy bueno para reducir el volumen de comentarios, e incrementó su detalle. La gente puede decir "estoy de acuerdo" o "estoy en desacuerdo". Esto hace que los comentarios triviales sean menos en número.

Tenemos unos mil comentarios no triviales, y podemos decir que alguna de las notas que hemos incorporado a la licencia vienen de comentarios puestos por comentaristas sin ningún tipo de afiliación.

Un ejemplo. Esto es lo que decía el comentario: "En la antigua GPLv2 la distribución del software era el punto en el que comenzaban las obligaciones con la comunidad. Una dirección. Si se distribuían los binarios, uno emitía y otro recibía. Esto tenía sentido en 1990. Ahora también lo tiene en muchos casos. Pero consideremos el P2P. Tenemos una ISO de binarios que un montón de gente se distribuyen mediante bittorrent. En realidad lo que están haciendo es distribuyéndoselo entre ellos. Pero no piensan como distribuidores, sino como usuarios que se lo están bajando, y ni siquiera tienen todo el binario para distribuir. Bajo la GPLv2 esto sería infringir la licencia. ¿Por qué no lo arreglan en la GPL v3?"

Y tenía razón. Es un problema, y es fácil de arreglar, pero hay que hacerlo. Así que en la segundo borrador hicimos una provisión para estos usuarios que se pensarían receptores aunque en realidad están haciendo transmisión del código. Hay un par de comentarios más como este, que valen más que valen su peso en oro.

Los comités han pasado miles de horas refinando ideas, comentando, comunicando. Están acostumbrados a trabajar en estos formatos, en comités de estándares, y nos han dicho lo que necesitan de una licencia libre, y nos han ayudado a hacer una licencia que de confianza a los usuarios comerciales tanto como a los no comerciales.

Los meses de discusión del primer borrador han sido beneficiosos. Hay pocos artículos que no hayan sido reescritos sustancialmente. Aún me sorprende que la gente creyera que no íbamos a escuchar los comentarios de la gente.

Internacionalización de las licencias

En un mes entraremos en el proceso de discusión sobre el segundo borrador.

En el proceso de revisar el segundo borrador antes de publicarlo hemos trabajado sobre el problema de la internacionalización. Se ha preguntado mucho por la traducción, y ésta es una forma de tratar el problema de la internacionalización.Pero es como mucho la segunda mejor forma de internacionalizar las licencias.

Lo mejor que podamos hacer es copiar el proceso de la convención de Berna, hace como un centenar de años años. Lo bueno de la DMCA, por cierto, y algo tiene de bueno, es que los Estados Unidos han entrado de lleno en el universo de Berna. Ahora que todos vivimos en un universo de Berna, la forma correcta de internacionalizar es acercarnos lo más posible a los mecanismos de Berna: eliminar de las licencias todo vocabulario que sea específico de una legislación en particular, y generalizar las expresiones.

Un ejemplo que se observa en las licencias GPLv2 en ciertos países es que la GPLv2 dice que es una licencia perpetua. Los abogados alemanes decían que eso era un problema, que hay que definir un término. Hay otros sistemas legales como el USA donde se quieren licencias perpetuas. Una forma de arreglarlo es traducir las licencias a cada circunscripción. Eso es un problema. Otra es elegir un sistema, o perpetuo o términos. Otra forma es generalizar. El primer borrador dice "por un plazo, y el plazo es la longitud del plazo de copyright sobre el programa subyacente". Lo que hemos hecho es arreglar un problema sin elegir una expresión que pueda decir algo que función en un sistema legal y no en otro.

Con respecto a palabras como "distribución" de copias, un término legal en los Estados Unidos, la solución del primer borrador era hablar de "propagación" de copias, que es algo que afecta a la licencia con sus sistemas legales nacionales. El segundo borrador va más allá y habla de "conveying a copy", que es un término que no tiene ningún significado legal específico, pero sigue expresando algo que está sujeto a la ley de copyright. La licencia en su forma actual no usa términos USA, y ya no tiene ninguna dependencia del concepto estadounidense de la idea de "derivative work". Nos libraremos las quejas de los abogados de todo el mundo.

Compatibilidad, LGPL, Patentes y DRM

La internacionalización de las licencias ayuda a la compatibilidad, que era uno de nuestros objetivos principales. Le preguntaban al señor Stallman: "¿Qué pasa con la proliferación de licencias?". Nuestra respuesta es "usa la GPL, añade tus permisos, y si tus restricciones son compatibles con las de la sección 7, no necesitas otra licencia nueva". Si no te gusta el copyleft, no hay nada que podamos hacer. Pero si te gusta el copyleft, usa la GPL. [Nota: aquí explicaba cómo las licencias permisivas han proliferado más que las licencias copyleft, algo con lo que o no estoy de acuerdo o no he entendido bien (N. del E.)]

La GPLv3 permitirá más flexibilidad de uso en las licencias copyleft, haciendo más seguros los intereses de usuarios comerciales que quieren usar licencias libre, y añadiendo claridad para los desarrolladores.

Hemos adoptado un cambio no funcional con la LGPL. La LGPL es una GPL con permisos adicionales sobre la GPL, con lo que simplificamos nuestro propio panorama de licencias. Es la unificación electro débil. No creemos que podamos hacer lo mismo con las licencias permisivas, eso es la unificación con la gravedad, y eso es mucho más difícil.

Además, la compatibilidad de la nueva LGPL con la propia GPLv3 es un ejemplo de cómo el sistema de permisos añadidos del título 7 permite generar licencias sin añadir proliferación. Esto hace que el sistema de licencias GPL sea muy potente.

Otro problema es como inventar dando un rodeo al sistema de patentes. Algunos de nuestros usuarios que tienen patentes y quieren contribuir. También los hay que tienen miedo de las patentes de otra gente. Y los que quieren distribuir software y tiene miedo al "chilling effect" sobre los clientes, que no les contraten sus servicios. Son grupos distintos. Los primeros, que tienen muchas patentes también tienen ingresos a partir de ellas, y aparecen más de una vez. Todos tienen políticas de patentes propias, y posiciones de negociación. Aunque somos sofisticados, no hemos estado en esas negociaciones, no tenemos patentes y tampoco tenemos peso en el sector. En este momento tenemos algo de peso, porque estamos haciendo una licencia que necesitan. Pero no tenemos que abusar.

Durante las negociaciones, hemos hecho gran progreso en entender lo que nos piden y en explicar cuál es nuestra posición: hemos escuchado con mucho cuidado tanto a los titulares y a los que no lo son, y creemos que tenemos grandes propuestas que hacer. Y una vez estos asuntos se hayan resuelto tendremos que ir al siguiente problema.

Este nuevo problema es el control del software en el interés de la seguridad del entretenimiento. La gente entiende que RMS no les dice lo que quieren hacer. Los RIAA y MPAA creen que tienen derechos y tienen que hacerlos valer. Veamos, yo soy un ciudadano privado, y como ciudadano privado puedo tener opiniones. Pero como abogado de la FSF digo que nos intentan restringir la posibilidad de hacer software como queremos hacerlo, y esta restricción se hace por que ellos tienen un modelo de negocio.

Su modelo de negocio es irrelevante para nosotros, y no no porque creamos que no deba existir el copyright o por lo que sea. Algunos dicen que la cláusula sobre el DRM en la GPLv3 legisla algo que no tiene que ver con el software. Pero no es así. El uso de DRM para evitar que uno pueda cambiar el software licenciado con GPL a un dispositivo de hardware determinado es evasión de la licencia, aunque la evasión se haga mediante sistemas técnicos. Digamos que hago un PVR y le llamo TIVO. Te doy el código fuente bajo la GPL, pero te digo que si cambias el código yo te corto el servicio. Estoy cambiando las condiciones de la licencia, pero no las he cambiado cambiando la licencia, sino modificando el hardware. Esto es lo que intenta arreglar la nueva GPL versión 3. Si no se puede cambiar la licencia, tampoco te dejaremos cambiar el hardware.

Nos dicen: "nos preocupa nuestro negocio, ¡queremos hacer dinero!" Está bien, pero si para hacer dinero tienen que vulnerar nuestra licencia, no se lo permitiremos. La licencia debe prohibir medios técnicos de evadir sus reglas con la misma claridad con que prohíbe los medios legales. Esto no deja mucho margen de discusión, pero estamos dispuestos a negociar lo que sea negociable.

La licencia no prohíbe el uso de software GPL para implementar sistemas de DRM, esto estaría mal. No se imponen restricciones de uso, porque eso haría que el software no fuera libre, aunque el primer borrador era confuso). Por esta razón lo hemos aclarado en el segundo borrador.

También está cambiando el panorama legal en Europa. La EUCD y su implementación hace que tengamos que cambiar las términos de la licencia. En la versión 3 creemos que podremos tratar con la DMCA y la EUCD sin imponer restricciones de uso, y que también servirá para meterse en medio de las nuevas leyes de anti-elusión que se puedan dar en el futuro en otros países.

Antes de pasar a las preguntas, tengo que decir algo. Estamos a mitad de camino de un proceso muy largo. Esto les preocupará a ustedes más que a mí. Cuando esto se termine, en algún momento de enero que viene, habremos logrado, por colaboración internacional, construir las reglas que gobernarán el negocio del software libre. Reglas que permitirán a negocios de miles de millones de dólares colaborar en un sistema unificado. Y habremos hecho las reglas del software libre en un periodo de un año, siguiendo las reglas y principios que guían al software libre. Decenas de miles de personas de todo el mundo habrán colaborado para lograrlo.

El monopolio más grande y mejor financiado del mundo habrá fracasado en su intento de renovarse, y conseguido un fracaso comercial y financiero. El software privativo se habrá colapasado por su propia ineficiencia. Nosotros, todos habremos tenido éxito en acordar las reglas del negocio del software para la década que viene, mediante colaboración abierta, las reglas que gobiernan un negocio enorme, a Constitución del software del software libre. Tres documentos en uno. Las reglas que permiten que escuelas, pequeños negocios, instituciones, empresas multinacionales e individuos colaboren.

Las empresas, los gobiernos, las finanzas se darán cuenta de esa discrepancia. Se darán cuenta porque el estruendo del fracaso de Microsoft será más silencioso de que estamos acostumbrados. En Microsoft no hablarán tan alto. Se dirán "Solían ganar mil millones de dólares al mes en beneficios, y gastarlos en propaganda diciendo cómo su sistema era el mejor sistema. Es gracioso que no hablen tan alto. Que se hayan dado cuenta de que su forma de nacer negocios no era la mejor.

Esto es lo que pensaremos cuando hayamos acabado. El sistema alternativo fracasará en un campo de batalla que ellos mismos han elegido, habiendo fracasado en la tarea de convencer incluso a los propios usuarios que habían atrapado para que usaran su software.

Pero la capitulación de Microsoft no será de un día para otro, así que deberemos preguntarnos: ¿Qué deberíamos buscar en el futuro próximo como indicación de que esta capitulación ha tenido efecto?

Había un tipo en Microsoft llamado Martin Taylor cuya misión era "ganar a Linux". Este tipo se encontraba en el centro de la presión contra Linux: Después del segundo "reset" de longhorn lo llevaron a Windows Live, y esta semana lo han despedido. Taylor trabajó en Microsoft desde los 23 a los 36, tiene muchas acciones y no tiene trabajo. No sé si es la gota que colma el vaso, pero por lo que me dicen también era el preferido de Ballmer.

Este año estamos redactando la GPLv3, y no lo hemos elegido al azar. Hemos elegido este año porque Microsoft estaba ocupada haciendo otra cosa. Porque no pueden gastar tiempo y recursos hablando mal de los demás mientras toda su atención está en Vista.

Ahora creo que este año tiene aún más importancia. La ofensiva de "encanto" de Microsoft es más importante, y cada vez hay menos opciones alternativas [Recordad que para Moglen la GPL es "la regla que dice cómo funciona el negocio del software", y el software propietario son "las alternativas", N. del E.]. Mi trabajo como abogado es anticipar la guerra y ayudar a luchar en ella. Cuando se libere Samba 4, Microsoft tendrá la mejor razón para comenzar la guerra, porque competirán con algo que no sólo les arruina el negocio del servidor, sino que lo elimina.

Nunca han resuelto el problema del servidor, ni han satisfecho las necesidades en el cliente. Cuando actúen agresivamente, si lo hacen, lo harán con más debilidad. Ahora están más constreñidos (gracias a Carlo [Carlo Piana, abogado en el caso antimonopolio con Microsoft, N. del E.] y a otros en esta habitación). Por primera vez tienen la posibilidad de que las regulaciones les afecten y Carlo los demás saben lo que tiene que preguntar o testifica. No será fácil o sencillo, y no será la primera vez que a la Embajada de los Estados Unidos se le pida que interceda por Microsoft.

Nuestra capacidad para devolver el fuego es cada vez mayor. Nuestra capacidad estratégica es cada vez mayor. Nuestros aliados son cada vez más poderosos. En Google Microsoft tiene un adversario del que está aterrado. Para nosotros Google es tan sólo un usuario grande, pero un usuario más. Tenemos aterrado a Microsoft.

Somos su ansiedad primaria. A Bill Gates eso ya no le importa. Se ha retirado, y se dedica a la filantropía. Ballmer, sin embargo, tiene muchos asuntos sobre la mesa. Le vamos a levantar la tensión arterial hasta el máximo, y muy pronto.

Turno de preguntas: permisos y condiciones, más patentes, más DRM, privacidad, licencias y contratos, cláusula Affero,

  • Diferencias entre permisos y condiciones que se añaden según la sección 7, la que se dedica a la compatibilidad:

    "En el nuevo sistema los permisos son un conjunto abierto, y son eliminables. Si uno basa su software en un programa GPL con permisos adicionales puede quitarlos si quiere.

    Por el contrario, los requisitos o condiciones añadidos son de un menú fijo, y el copyleft se les aplica también, así que no son eliminables, y hay que conservarlos en las obras derivadas de programas bajo la licencia GPLv3 que incluyan esas cláusulas."

  • Cómo se tratan las patentes de software:

    "Los permisos para usar patentes propias no irán en los permisos añadidos según la sección 7 (ya que éstos son eliminables), sino en la sección 11, donde dice "Grants of allocations, non-assertions". Así que los permisos de uso de patentes irán en la licencia base.

    Las "Patent retaliation clauses" o cláusulas de contraataque por pleitos de patentes van en la categoría de condiciones adicionales permitidas en ocasiones, en la sección 7. Este tipo de cláusulas sobre patentes se aceptan sólo si el propósito es sólo repeler ataques, no por un interés de compatibilidad con el mayor número de licencias posibles. La cláusula de patentes que se acepte será la de la otra licencia [por ejemplo la de Apache, N. del E.]. Si la licencia es está en Debian, la GPL será buena para Debian. Usamos los términos de "retaliation" de las otras licencias. En la GPLv3 no mencionamos la lista de licencias, sino que describimos los términos que hacen que otra licencia sea compatible con la GPL."

  • Sobre compatibilidad con Debian:

    "Si alguien sugiriera que hay problemas con las DFSG lo trataríamos, pero no se nos ha mencionado."

  • Sobre la cláusula del DRM y su efectividad:

    "Espero que a los tribunales USA se les instruya para que lean la parte de la licencia llamada "intenta" [exposición de motivos, N. del E.] que rechazan acogerse a la "protección" que les da la DMCA.. Pero para la EUCD usaremos otro sistema que se ve en el segundo borrador. Hay dos países que están implementando la EUCD en las próximas semanas [España y Francia, creo. N. del E.], así que me reservo el derecho de hacer cambios. Tengo la certeza al 95% de que sé lo que vamos a hacer, pero a mi cliente se le conoce por intentar evitar los errores. Si esta fuera la hora de revelar esos términos, lo haría y los discutiría, pero no lo es."

  • Sobre el "spyware" y la cláusula de privacidad:

    "Este es un caso en el que las víctimas son individuos, y los beneficiarios son ricos. Microsoft fracasa en resolverlo, y las empresas que se benefician de la falta de seguridad tendrán que buscar otros sistemas de enriquecerse [creo que se refería a intentar atacar a usuarios de software libre. N. del E.]. Pensé que era necesario dar a los desarrolladores individuales la posibilidad de hacer de fiscales de este problema con la licencia GPL. Veo ahora que a la gente no le gusta esa parte de la licencia, y no es difícil quitarla, pero no se si les gustará el resultado. La gente deseará que lo hubiéramos hecho como desearía que hubiéramos arreglado lo de las patentes en 1991, y como nos agradecerá que hayamos arreglado lo del DRM hasta el punto en el que va a estar arreglado ahora."

  • Sobre la compatibilidad con licencias arbitrarias:

    Siempre se puede usar un permiso adicional para combinar el código GPL con otra licencia que uno quiera. Estos permisos son eliminables, y es la compatibilidad trivial que más allá puede volverse sólo GPL pura. Lo mismo con la LGPL, cuyo código se puede relicenciar bajo la GPL, y al convertir nosotros la LGPL en una GPLv3 con un permiso añadido, no pierde esa característica.

  • ¿Son contratos las licencias?

    "La propia GPL dice que es una licencia, y no un contrato. Y algunas mentes legales de fuera de los Estados Unidos están en desacuerdo. Yo estoy en desacuerdo con ellos: son duros de mollera y mal aconsejados. Uso adecuadamente el género masculino porque casi todos son varones de pelo gris y mentes caducas.

    En cada uno de sus sistemas legales, estoy seguro de que pueden buscar, aunque tengan que llegar al Códice de Justiniano, y encontrarán que la GPL es lo que llamamos una licencia: un permiso unilateral, no una obligación. Su visión merece un respeto, aunque yo no se lo doy en mis comentarios personales. Como abogado que la redacta, simplemente les señalaré la parte que dice "no es necesario aceptar la licencia para recibir y ejecutar copias" ("acceptance is not required to receive and run copies"), que reduce para el caso del mero usuario la necesidad de descansar sobre hechos legales, ya que el permiso está dado de facto."

  • Cuáles son las consideraciones que les han hecho tener compatibilidad con las licencias tipo Affero. Es algo importante ya que las compañías web 2.0 pueden ser nuestro próximo enemigo [estas fueron las palabras del que hacía la pregunta, N. del E.]:

    "Hay dos puntos de vista éticos sobre tomar el código de otro, modificarlo, y entrar en un negocio compitiendo con el autor original. Una posición ética es que se te debería obligar a dar tus cambios al mundo, que esos cambios deberían volver al procomún. El otro punto de vista ético es que ésta es una situación distinta en la que cualquier intento de restringir tu derecho a ejecutar privadamente el código sería una injerencia inaceptable. No hay beneficio en elegir ninguna de estas posturas, es un dilema clásico, y hay argumentos de los dos lados. Esto nos afecta a todos, y si nosotros tomáramos esa decisión, la gente nos preguntaría cómo hemos hecho esa decisión.

    Imaginen que quitásemos de la sección 7 la parte que permite la compatibilidad con Affero. Ahora cualquiera podría hacer esa licencia por su cuenta (como hicieron los de Affero), y no podría usar código GPL, porque la licencia se lo impediría. Por otro lado, si decidiéramos que todos los programas GPL deberían tenerla, muchos negocios no la usarían, y no querrían usarla porque querrían guardarse su código fuente para sí, y con todo derecho.

    Así que no vamos a obligar ni a impedir que nuestros usuarios pongan en sus licencias términos similares a los de la Affero GPL. En el borrador hemos hecho un requisito añadido (condición) sobre la parte que ofrece servicios remotos, y será optativo para el desarrollador que quiera usarla. Si otro desarrollador quiere usar su código, tiene dos opciones: o sigue distribuyendo todo el código de la aplicación según la licencia Affero, o reimplementa esa parte del código (que es la que está bajo licencia Affero), y lo enlaza con el resto del código, que es GPL y por tanto puede reutilizar privadamente.

    Esta es la única solución que ofrece la máxima libertad de innovación, y máximo requisito de mínima reimplementación. Si alguien ha escrito una aplicación "Affero-izada", no tienes derecho a quitarle el derecho de exigir la redistribución del código fuente. Si tienes que reimplementar para obtener la libertad, ese es el precio de no usar código de otro. La desventaja es mínima a cambio de la ventaja de aumentar la compatibilidad de ambos tipos de aproximaciones éticas."

  • Sobre el tema de la traducción de las licencias, un japonés [creo que es un representante de Debian Japón, y/o de la FSF Asia, pero no lo sé seguro porque lo pude ver, N. del T.] dijo que en su país sólo son legales las licencias traducidas, y que por qué la FSF no abría la posibilidad de traducciones oficiales.

    "Hemos viajado a Tokio y nos han dedicado mucho tiempo para hablar de las licencias. Necesitamos abogados japoneses que entiendan este negocio, y que nos den sus opiniones sobre cada palabra. Sin embargo las grandes empresas con abogados que saben de y hablan inglés perfectamente (y lo sé porque he trabajado con ellos durante cuatro años) no hicieron nada porque no querían exponer sus abogados a conversaciones sin privilegio de confidencialidad. Si es importante, es importante, si lo es luego lo es ahora. Si sería importante para hacer una traducción oficial más tarde, los necesitamos ahora para poder hacer una licencia en inglés que se pueda traducir bien.

    El problema no es el idioma, es que se han mantenido fuera del proceso demasiado tiempo. Si mis amigos japoneses esperan hasta el último minuto hasta pedirnos lo que quieren, se encontrarán con un desencanto, no porque no escuchemos, sino porque será demasiado tarde para responder a sus peticiones.

    Si su condición para hablar es la seguridad de que haya una version oficial en japonés más tarde, eso no es el sistema. Hablemos ahora."

  • Pregunta por la posibilidad de que las cláusulas de contraataque de patentes y de la obligatoriedad de la descarga en programas que funcionen por red hagan que las licencias sean no libres. La pregunta referencia a Debian y la "prueba del dictador".

    "No debería meterme en la "Debian-legal way of life". Pero en este país, no soy abogado, así que quizá pueda entender la Debian-legal way of life" como alguien que no sabe de leyes.

    Si los abogados hubiesen sido hackers... pero no lo eran, o no del todo. La consistencia legal que se asume por parte de los hackers es demasiado grande. La exigencia libertaria de consistencia y la visión hacker crean un marco de análisis muy particular, especialmente para determinadas cuestiones. Y esto no funciona, porque hay que tener en cuenta que la ley es mullida, elástica, y si la aprietas verás que tiene un interior blando.

    Los problemas de las cláusulas de patentes no son un problema para la GPL, ni en Debian ni en ningún sitio. Las cláusulas que aceptaremos están ya en la licencia Apache. Así que no veo por qué pueden causar ningún problema si Apache está en Debian.

    En cuanto a la licencia Affero, lo que dice es que está prohibido eliminar la parte interactiva que gestiona la descarga del código fuente del mismo modo que está prohibido eliminar la parte que declara el copyright. Es un asunto de seguridad de la atribución de la obra. La FSF dice de la licencia Affero que el fundamento del copyleft es que se desea limitar mínimamente la libertad para poder defender la libertad en el largo plazo.

    Para la FSF, la cuestión no es si esta restricción de libertad es buena, sino una elección entre estas tres posibilidades: a) ¿Es esta restricción la restricción menor que permite proteger la libertad a largo plazo? b) ¿Hay otra restricción aún menor que cumpla la misma función?, o c) ¿Vale más la pena dejar que la libertad se pierda que poner esta restricción en este momento?

    Stallman no un contrario a las restricciones, sino un minimalista de las restricciones. El software necesita algunas restricciones. Es como la ley que obliga a recoger cuando los perros defecan en las calles: es una restricción necesaria para garantizar la higiene y el bien común."

  • ¿Por qué es para algunos tan difícil entender que las licencias son permisos unilaterales y no contratos?

    "Post-Edison, las licencias de copyright son una forma de extraer al usuario más de lo que la ley le daba. Las compañías querían más de lo que el copyright les daba. Por eso se pusieron a incluir términos contractuales en las licencias, en apartes que tras los permisos que se concedían enumeraban las obligaciones añadidas. En las décadas siguientes, las licencias dejaron de ser meramente licencias de copyright, sino listas de las obligaciones que deseaba la parte que escribía las licencias.

    Nosotros dijimos que no queríamos esos problemas, y no queremos darles más obligaciones, ni sacarles cosas. Y por primera vez estábamos haciendo un modelo de negocio basado en una licencia pura. Eso es algo que no se entiende por parte de estos seguidores de Thomas Edison. Dicen que todas las licencias tienen que tener obligaciones, y eso son bobadas. Los usuarios tienen sus derechos, y no se los tenemos que quitar, porque no nos hace falta."

Historias relacionadas

[+] Software Libre: Richard Stallman habla sobre la GPLv3 y el pacto Novell/Microsoft 37 comentarios
pobrecito hablador nos cuenta: "via Fresqui, llego a la Charla de Richard Stallman en la Conferencia Internacional GPLv3 realizada en Tokyo el 21 de Noviembre. Aunque la charla está en inglés, no tiene desperdicio. Dejo acá un extracto traducido de lo que dijo R. Stallman sobre el Pacto Microsoft/Novell: "(...) Resulta que quizá sea una buena cosa que Microsoft haya hecho esto ahora, porque descubrimos que el texto que habíamos escrito para la versión 3 del GLP no lo habría bloqueado, sino que es demasiado atrasado y vamos a cerciorarnos de que cuando salga la versión 3 del GLP realmente bloqueará tales maniobras (...)" La traducción es un poco apresurada, pero vale para enterarse de lo que dice Stallman, y que es lo mismo que decía Eben Moglen sobre el pacto de Novell (y lo que dijo también en la reunión de la GPL3 en Barcelona).
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Colaborad ahora con el borrador

    (Puntos:4, Informativo)
    por clemente (7062) el Lunes, 26 Junio de 2006, 01:13h (#767137)
    ( http://www.danielclemente.com/ | Última bitácora: Sábado, 08 Octubre de 2005, 18:08h )
    El sistema de comentarios del que habla la noticia es éste: comentarios al borrador de GPLv3 [fsf.org].

    Cualquier frase o párrafo que no se entienda, se puede seleccionar con el ratón, y añadir un comentario. También se puede estar de acuerdo o desacuerdo con los comentarios ya puestos.

    En las conferencias todos recordaron lo importante que es que participe la mayor cantidad de gente posible; entiendan o no de licencias: usuarios, programadores, abogados, ...
    Pero para que sea útil, ¡esto hay que hacerlo ahora!. Cuando la GPLv3 ya se haya publicado, será demasiado tarde.

    Recordad que es la licencia de software libre más usada del mundo; vale la pena asegurarse de que no tendrá problemas.

    Hay más datos sobre el proceso a seguir [fsf.org].
  • por Qt_TQ (24526) el Lunes, 26 Junio de 2006, 01:28h (#767141)
    Hay que agradecértelo:

    Muchas gracias.
  • Hablando de DRM

    (Puntos:3, Informativo)
    por sorrill (13858) el Lunes, 26 Junio de 2006, 06:30h (#767161)
    ( http://barrapunto.com/ )
    Os recomiendo que veais este video donde se explica de una forma muy clara el porque no debe progresar el DRM:

    Trusted Computing [youtube.com]

    A ver si alguien se anima a subtitularlo (o doblarlo de forma "profesional"!) y lo distribuimos lo maximo posible.

    Saludos.
  • Licencias permisivas

    (Puntos:2, Interesante)
    por anv (15549) el Lunes, 26 Junio de 2006, 07:38h (#767189)
    ( http://barrapunto.com/ )
    [Nota: aquí explicaba cómo las licencias permisivas han proliferado más que las licencias copyleft, algo con lo que o no estoy de acuerdo o no he entendido bien (N. del E.)]

    Las licencias permisivas son las tipo BSD, Xfree86, Apache o cosas por el estilo. A las empresas que quieren aprovecharse del trabajo de la comunidad les resultan muy cómodas porque permiten hacer trabajos derivados sin devolver nada de lo que recibieron.

    Un ejemplo claro de a lo que lleva la licencia BSD es lo que ha hecho Apple: se aprovechó del núcleo de BSD y ahora decidió cerrarlo, probablemente para poder agregar DRM sin que los usuarios puedan tener control sobre sus propias máquinas.
  • Vaya...

    (Puntos:1)
    Como ciudadanos de una república libre [...] ¿Donde vive este tio?
    --
    Property is a nuisance -- Paul Erdös
    • Re:Vaya... de baltab2k (Puntos:1) Lunes, 26 Junio de 2006, 22:25h
      • Re:Vaya... de Candyman (Puntos:2) Martes, 27 Junio de 2006, 16:09h
  • por ces (13189) el Lunes, 26 Junio de 2006, 07:16h (#767178)
    ( Última bitácora: Jueves, 14 Diciembre de 2006, 08:40h )
    Hay que tener en cuenta que la GPL no otorga obligación (restricción) alguna si no distribuyes el software. Mientras sea para tu propio uso, no hay imposiciçon de ninguna obligación. Sólo las impone en un caso de uso, en el de la distribución.
    [ Padre ]
  • por dbpp (15670) el Lunes, 26 Junio de 2006, 07:46h (#767194)
    ( Última bitácora: Viernes, 28 Julio de 2006, 15:12h )
    Ya lo dice él: En El Ombligo del Universo™, EUA, no es un contrato, es una licencia. Los demás están equivocados o tienen (tenemos) mentes caducas. Que aquí los permisos unilaterales se acepten o no por el receptor no les cabe en la cabeza: es un regalo de El Ombligo del Universo™ y tú no puedes rechazarlo. Supongo que no pensaría lo mismo si a los autores que usan una licencia libre los demandasen algún usario (esos que no tienen que aceptar la licencia, y por tanto tampoco la limitación de responsabilidad).
    [ Padre ]
  • Re:Una licencia es un contrato

    (Puntos:3, Interesante)
    por Candyman (7) el Lunes, 26 Junio de 2006, 08:00h (#767210)
    ( Última bitácora: Jueves, 09 Diciembre de 2010, 01:17h )
    Muy sencillo. Diría que no impone ninguna obligación, sino que las condiciones de la licnecia son la demarcación o contorno del permiso.

    Tomemos por ejemplo la obligación de distribuir el código fuente de las obras modificadas. Yo hago un programa, y lo hago GPL. El programa original es el código fuente, que te entrego (te lo bajas de mi servidor) junto con una copia de la licencia.

    Según la LPI tú no puedes hacer nada con ese código, ni distribuirlo ni hacer transformación de él. Pero la GPL te da permiso para que lo hagas. Lo que pasa es que la GPL te da un permiso que no es para que hagas cualquier cosa con él, sino sólo ciertos permisos.

    Por ejemplo, puedes distribuir binarios acompañados del código fuente (o una oferta escrita de distribuirlo, ya lo sé, pero para acortar) y una copia de la licencia, pero no distribuir binarios solos.

    La prohibición de distribuir binarios solos no te la da la licencia (si lo hiciera sería un contrato, como dices). Esa prohibición te la da la ley, que prohibe distribuir la obra bajo copyright de ninguna manera. Ninguna de las aparentes obligaciones de la licencia son obligaciones en las que entres por conformidad, sino que son prohibiciones que están en la ley. Yo las llamo "la forma del permiso".

    Por poner un ejemplo: yo tengo un coche y te lo presto hasta el lunes. Si el martes aún no me lo has devuelto, no estás rompiendo ningún contrato, sino la ley, porque el coche es mío, y andar conduciendo por ahí en ausencia de mi permiso es robo de vehículos (o lo que sea). El devolver el coche antes del martes no es una obligación contactual, es el límite (en este caso temporal) de mi permiso unilateral.

    Sin embargo, si te presto mi coche pero sólo si lo lavas antes de devolvérmelo, eso sería un contrato, porque nada en la ley dice que tengas que lavar el coche de quien te lo presta: sólo el acuerdo entre las partes (tú y yo) te obliga a hacerlo.

    Como último experimento mental, vamos a suponer que yo hago un programa, lo pongo bajo la GPL, y tú decides que te pasas la licencia por el forro, porque no la has firmado ni estás de acuerdo con ella. Así que estás distribuyendo un binario modificado trivialmente (sólo le has puesto el logo de tu empresa) con tus ordenadores, sin cumplir con la obligación de distribuir también el código fuente.

    Yo te llevo a juicio por vulnerar la GPL, y tu defensa va a ser que dado que no diste tu conformidad con el contrato, éste no es válido, porque un contrato es un "acuerdo de voluntades", y éste contrato, que está escrito en inglés, idioma que desconoces, no lo has podido aceptar. Olvidemos tu teoría de que es un contrato de adhesión, y veamos cómo se puede hacer cumplir la GPL siendo un mero permiso unilateral.

    La respuesta de Moglen, y lo sé porque se lo he oido decir: "bien, si la GPL no es válida en este caso porque usted no ha aceptado el contrato, dígame qué le da a usted el derecho de distribuir mi trabajo. Nadie va a admitir que la GPL no es válida."

    Para más detalles tendrás que molestar a Moglen, al que le encanta dar lecciones (en Barcelona se hizo un corrillo a su alrededor cada vez que aparecía). Pero a mí me ha convencido de que, aunque la fórmula "licencia" no aparezca en la legislación española del modo codificado en que aparece en la norteamericana, la GPL carece de las obligaciones de la segunda parte que caracterizan a un contrato.

    Resumiendo: para quien recibe un programa con la GPL, todo son permisos (algunos, es verdad, con una forma un poco retorcida) y no hay ninguna obligación añadida a las prohibiciones que impone la ley.
    [ Padre ]
  • 3 respuestas por debajo de tu umbral de lectura actual.