Quantcast
Viewing all articles
Browse latest Browse all 5

Objetivos de GPLv3 con respecto a DRM

Ricardo Galli, en un intento por explicarme los objetivos y la forma en la cual el draft de la GPLv3 ataca el DRM, repite los objetivos de las cláusulas y cómo se espera que funcionen. No tengo dudas con eso, lo que yo planteo es que los objetivos no se cumplen, porque las cláusulas no funcionarán. Me hubiese gustado que se refiriera al ejemplo que planteo en el post que motivó su respuesta, así que replanteo los temas:

  • Me imagino que un sistema que entrega llaves para decriptar contenido (como un e-mail encriptado) a un programa en base a algún criterio, y si no cumple con ese criterio (por ejemplo, confianza en que no reenviará ese e-mail decriptado a toda la dirección en la agenda) no se le entrega la llave, debiera poder licenciarse bajo GPLv3.
  • Un criterio bien puede ser que exista una firma del binario por alguien que certificó el programa, sea el usuario mismo o alguien externo.

Si parece aceptable un esquema así, entonces es aceptable que ese programa esté en un sistema de DRM, y con eso no se logra el objetivo de desincentivar el uso de software libre en sistemas con DRM. Pero supongamos que no se considera aceptable el esquema. En tal caso, tampoco sería aceptable el sistema de manejo de mails encriptados que describí en el artículo anterior. Eso limitaría el campo de acción de cualquier programa derivado de código GPLv3, que es una consecuencia poco afortunada por decir lo menos.

Veamos entonces en qué nos afectaría la redefinición de “código fuente”. El sistema que menciono en el post anterior permite que se instale cualquier programa sin necesidad de una llave. Tampoco se requiere una llave para la ejecución del software. Simplemente, cuando se ejecuta un software no firmado (o el sistema operativo, o cualquier programa en la cadena, no está firmado), no se tiene acceso a ciertas llaves de decripción. Por lo tanto, el objetivo de “evitar el recorte de las libertades por mecanismos de hardware” no se cumple, y tampoco se cumple el “desincentivar sino impedir el uso de software libre en sistemas con DRM”.

Lo que nos resta es entonces que cualquier esquema de DRM no puede contener directamente ningún código que esté licenciado bajo GPLv3. Cualquier fabricante tendría por lo tanto que desarrollar su propio driver y software de manejo de claves para poder utilizar DRM, y sobre eso instala sin problemas software GPL. Vale la pena el costo que se está asumiendo solamente para obligar a algunos fabricantes a desarrollar su propio software? Sobre todo considerando que es muy poco probable que esos fabricantes ocuparan software GPL para eso, me parece que no.

Cuál es el costo del que hablo? Pues que muchos evitarán utilizar esa versión de la GPL por no estar de acuerdo. Y de paso, la GPL se estará “ensuciando” al salirse del marco técnico y definiendo qué cosas no se pueden hacer con el software. Comenzamos con “no se puede utilizar en sistemas DRM”, pero por favor cuál es exactamente la diferencia con “no se puede utilizar en la creación de material pornográfico”, “no se puede utilizar para generar documentos con errores de ortografía” o “no se puede utilizar para publicar ideas que vayan en contra del gobierno chino”?


Viewing all articles
Browse latest Browse all 5

Trending Articles