Mañana, se supone, iba a ser un día de celebración para todos los que nos interesa tener una ley de derechos de autor balanceada y moderna, que se aleje del extremismo que hace que la ley actual no solo ignore las necesidades básicas de creación y el acceso a la cultura, sino también la realidad tecnológica en que vivimos.

Pero una campaña liderada por el Diputado Gonzalo Arenas esta amenazando la aprobación de la ley con una campaña digital que esta saturando las casillas electrónicas de los diputados en el Congreso (menos la de él, uno asume).

Uno puede estar de acuerdo en que el mentado artículo está redactado pobremente. Pero recordemos que en Chile el alojar contenido protegido por derechos de autor ya es ilegal. Lo nuevo de la Ley no son los castigos, sino el ordenamiento de los procedimientos judiciales, y por supuesto, las excepciones. Y entonces, la solución a un lenguaje poco feliz de un solo artículo que está promoviendo el Diputado Arenas y sus seguidores en la red es totalmente absurda: el descarrilar un proyecto de Ley que por primera vez crea excepciones reales para ciudadanos comunes y corrientes para usar la cultura que todos creamos, que permite a las bibliotecas la posibilidad de poner a disposición de las obras que mantienen a personas minusválidas, y un largísimo et cétera.

Y es que aquí hay que ser bien claro: intereses ligados a la SCD y otras entidades de gestión se opusieron a prácticamente todas las excepciones que contiene el proyecto que se votará mañana. Y el retirar el proyecto a esta altura no solo significa, como algunos están ingenua o maliciosamente sugiriendo, tener la oportunidad de revisar un pequeño artículo: significa poner sobre la mesa todos los avances que contiene el proyecto, para ser discutidos y posiblemente eliminados de nuevo. Un comentarista en el blog de Christian decía que no estaba opuesto al proyecto como un todo, pero que el proyecto no se podía «rechazar por partes«. La otra cara de esa moneda es que el proyecto, una vez rechazado o retirado para ser revisado, no puede ser «revisado por partes«. [Actualización: Y otra cara más es que durante el proceso de aprobación en la Cámara, se podría votar la revisión de ese artículo solamente, según nos cuentan en los comentarios].

Y si alguno de esos activistas que supuestamente están defendiendo los derechos de todos nosotros creen que el resultado de otro proceso de discusión más, demorado y probablemente con un Congreso con composición distinta generaría un proyecto tan positivo como el que está sobre la mesa hoy, les recomiendo que además del artículo que tanta hiperventilación está generando, también se lean los otros artículos, que nos dan a todos derechos que si el proyecto se rechaza mañana se irán con el 85 T, tal vez para no volver. Y que se tomen una pastilla para curarse el serio caso de ingenuidad política que están teniendo.

La política, dicen por ahí, es el arte de lo posible. Una reforma de esta magnitud, que tiene que incluir los intereses de muchos, no puede ser perfecta. Pero es perfectible, y si el Diputado Arenas esta montando esta tremenda campaña no por ánimo electoral o por descarrilar un proyecto generado por el gobierno, debería inmediatamente promover un Proyecto de Ley que reforme ese artículo que tanto le molesta [O, como mencionaba en la actualización más arriba, juntar los votos para que el artículo maldito sea reescrito]. Pero rechazar o demorar toda la Ley nos significa quedarnos con una ley antidiluviana que nos hace a todos delincuentes. Y ese, irónicamente, sería el gran triunfo de la SCD y de una visión extremista de los derechos de autor.

Como ya había comentado, el Ministerio de Obras Públicas (MOP) de Chile ha publicado en la red un documento preliminar sobre el uso de tecnologías de la información en el ministerio y como se puede mejorar el proceso de selección de estas tecnologías y evaluar el impacto que estas decisiones tienen en el mismo MOP y en el resto del país. De más esta decir que estos esfuerzos – sobre todo poniendo el tema en la esfera pública antes de que se tomen decisiones finales – son más bien raros y muy bienvenidos. Un análisis completo está un poco afuera de mis intereses y capacidades (muchas de la infraestructura de TI del MOP funcionan a lo que podríamos llamar «escala corporativa»), pero acá de todos modos se pueden destacar algunos temas.

Aunque el prólogo del Ministro Bitar es un poco preocupante, y temí que la discusión se reduciría a una simplemente de costos del software de código abierto vs. el software propietario ((Aquí, el informa usa equivocadamente el término «licenciado» como sinónimo de propietario, pero software de código abierto o «libre» puede tener licencias asociadas (i.e. Red Hat))), la discusión que viene después abarca varios temas. Una cosa interesante que emerge de la discusión inicial, por ejemplo, es el hecho de que el crecimiento más o menos orgánico de la infraestructura de TI en el MOP (y uno sospecha, en el resto del Estado) ha terminado en una situación actual donde hay una mezcla de una infraestructura central con una distribuida, con sistemas adquiridos en forma ad hoc para solucionar un problema específico, etc. Es decir, muchos de los problemas de falta de definición de criterios de compra o de uso de tal o cuál plataforma son históricos y no arrastrados por un buen tiempo, y en ese sentido, son un buen reflejo de lo que ha pasado con la industria del software en general.

La parte más interesante del informe es el capítulo 6, donde se entrega un  Manifiesto MOP relativo al software, que ayudaría a la toma de decisiones por parte del MOP. Así quedan plasmados, entonces, principios que demandan Imparcialidad Tecnológica, Buenos Prácticas de Seguridad, etc. El texto definiendo cada principio es, me parece, demasiado breve, y se deberían incluir en el informe algunos casos de estudio para que los lectores pudiéramos entender como se aplicarían. Más aún, la brevedad y/o ambigüedad de las definiciones abren a veces más interrogantes. Así, mientras creo que «Buenas Prácticas de Seguridad» pueden ser definidas y juzgadas sin demasiado problema, el principio de estándares públicos es más complicado:

Todo programa, componente de software, elemento de datos y servicios asociados debe desarrollarse bajo normas de programación, estándares de codificación y herramientas de aceptación universal.

No estoy seguro que significa aceptación universal. Por ejemplo, se podría medir como penetración en el mercado, o como que son accesibles universalmente. Esas dos definiciones pueden resultar en decisiones totalmente opuestas. En la primera, una tecnología podría ser utilizada simplemente porque es popular en un momento en particular, incluso si tecnologías alternativas muestran menor penetración pero han sido desarrolladas como soluciones abiertas o donde la competencia entre proveedores es mayor. Una aclaración parece necesaria en esta sección.

En el principio de Cada decisión en su mérito, se plantea que el Costo Total de Propiedad (o TCO – Total Cost of Ownership) debería ser un pilar fundamental al momento de elegir una solución de TI para el MOP. En general, creo que esa posición es razonable, pero cabe preguntarse también si el Ministerio, como un ente estatal, no debería también considerar en su análisis de impacto los que tendría en la sociedad en general el que un ministerio particularmente poderoso adquiriera tal o cuál solución. Y aunque el tema si se menciona en otras partes del informe (p.e. en la influencia que estas políticas pueden tener en la industria local del software), no hay que olvidarse que TCO es un concepto creado y aplicado en el sector privado, que poco o nada debe preocuparse del impacto social de sus decisiones. Para el Estado el estándar es – o debería ser – mas alto, y no hay duda de que las decisiones de adquisición de infraestructura TI por parte de este reverberan en muchas otros sectores de la sociedad.

Un último principio muy interesante mencionado es el de la Replicabilidad, definido como:

Todos los productos y soluciones de software que se liciten y/o adquieran como un paquete o para los que se soliciten su diseño y construcción, deberán permitir su intervención para adaptarlos a las necesidades de otros servicios del Ministerio o incluso para su adaptación para otras reparticiones públicas.

Esto, de nuevo, parece muy razonable ((aunque «Replicabilidad» parece un nombre equivocado, porque sugiere copia o repetición, que no tiene mucho que ver con adaptación)), pero creo que este principio abre la puerta a lo que debe ser una discusión mucho más amplia sobre derechos de autor y el uso de software – de cualquier tipo – en el Estado, una discusión que – con todo respeto al panel de expertos informáticos que ayudaron a crear este informe – requiere invitar a otros profesionales. Esta bien claro que el desarrollo del software propietario se ha basado en la idea que este es inmodificable y que, de hecho, el que paga una licencia es un mero arrendador (por es eso es que el nombre «usuario» es el que compra la licencia, y el «dueño», el que lo escribe). Entonces, este principio parece, a simple vista, cementar una idea que personalmente me parece necesaria cuando hablamos de usar dineros públicos para desarrollar TI en el Estado: que los resultados de ese esfuerzo deberían estar disponibles para otras entidades en el Estado mismo, y como una extensión natural, a toda la ciudadanía. Me pregunto, eso sí, si esa es la idea que tenían en la cabeza los autores del Manifiesto.

Hay otras cosas interesantes en el informe, y vale la pena leerlo. Desde afuera, e interactuando con lo que frecuentemente son páginas web pobremente diseñadas, se nos olvida lo compleja que es la infraestructura que está detrás y que ocupa mucho de los recursos y las tareas que ocupan al Estado, y el informe es un paso interesante en abrir la discusión sobre un tema tan importante, que va mucho más allá de la cuestión de si deberían usar Windows o Linux (pregunta con respecto a la cuál se declaran agnósticos, en todo caso).  Esperemos que continúe.

He estado usando Twhirl como mi cliente para Twitter por bastante tiempo, pero hace poco estoy usando un PC con Ubuntu Jaunty 64bit y me encontré con el problema de que aunque podía instalar y correr Adobe Air e instalar Twhirl, el programa solo guardaba el usuario de una sola cuenta y no guardaba ninguna contraseña.

Después de buscar por aquí y por allá, descubrí que el problema no es de Twhirl sino de Air y que algunos pasos relativamente sencillos, pero que requieren el uso de la temida consola, solucionan el problema (la solución sacada de acá). Si tienes Twhirl/Adobe Air instalado, mejor desinstalar todo (y borrar /home/usuario/.appdata) y partir de cero. Acá va, entonces:

Instalar soporte para librerias 32bit en Ubuntu:

$ sudo apt-get install ia32-libs lib32nss-mdns

Instalar Adobe Air (recuerda hacelo ejecutable con ‘chmod +x AdobeAIRInstaller.bin):

$ sudo ./AdobeAIRInstaller.bin

Descargar Twhirl (¡tienes que bajar el instalador de la red!)

$ wget -c http://d.seesmic.com/twhirl/twhirl-0.9.2.air

E instalarlo:

$ GTK_PATH=/usr/lib32/gtk-2.0 Adobe\ AIR\ Application\ Installer /directorio/donde/guardaste/el/instalador/twhirl-0.9.2.air

(La clave está en la sección en negrita, que hace que Adobe Air use las librerías 32bit) Hasta aquí vamos bien, pero todavía tenemos el problema de guardar las contraseñas correctamente, que se soluciona instalando otra libreria de 32bit:

$ wget http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-keyring/libgnome-keyring0_2.26.1-0ubuntu1_i386.deb

Para no dejar un desastre, queremos primero abrir el archivo .deb localmente:

$ dpkg-deb -x libgnome-keyring0_2.26.1-0ubuntu1_i386.deb libgnome-keyring0_2.26.1-0ubuntu1_i386

Y después copiar un archivo al directorio donde están guardadas todas las librerias de 32bit:

$ sudo cp libgnome-keyring0_2.26.1-0ubuntu1_i386/usr/lib/* /usr/lib32

Y listo. Más complicado de lo que debería ser, pero bueno. Peor es nada.