¿Software libre, abierto u open source?

Ayer mismo, una pregunta en la lista ITSAS de promoción del software libre en la UPV/EHU me dejó pensativo:

«¿Estamos en esta lista para promover en la UPV/EHU el software libre (aunque quizá no abierto), el software abierto (aunque quizá privativo) o los estándares abiertos?»

Iba a responder directamente pero creo que es mejor filosofar y meditar públicamente al respecto en este blog, porque seguro que hay muchas opiniones diferentes al respecto y ya estábamos metidos en un flame como para iniciar otro 🙂

Primero de todo me gustaría aclarar qué es lo que se conoce como software de código abierto. Habrá distintas opiniones, yo ofrezco la mía: software de código abierto lo interpreto como la traducción de software open source. Y software open source lo interpreto como software con licencia aprobada por la OSI (Open Source Initiative), es decir, software que cumple los 10 requisitos establecidos por esta organización para que un software sea considerado Open Source.

Hay gente que interpretará software de código abierto como software en el que simplemente tienes acceso al código fuente. Aquí se englobarían engendros como el software bajo licencia Microsoft Reference Source License (Ms-Rsl) : una licencia que permite ver el código fuente de una aplicación pero no puedes modificar ni distribuir el código (ni siquiera con objetivos no comerciales) . Yo no considero este tipo software, bajo este tipo de licencias, como software de código abierto; bajo ningún concepto.

En el párrafo anterior surge una interesante pregunta : ¿es el software bajo licencia Ms-Rsl software privativo? Yo simplemente diría que es software no-libre y no-abierto. Pero no iría más allá. Aunque entiendo que haya gente que particione las licencias software en dos: libre o privativo. En ese caso no habría duda de que soft bajo Ms-Rsl sería privativo.

Sigamos con la reflexión. Hemos visto que hay una organización, la OSI que, a petición del interesado, determina si una licencia puede ser considerada Open Source (aprobada por la OSI) o no. De igual forma, existe una fundación, la Free Software Foundation, que decide, motu-propio, sin que el interesado lo tenga que solicitar, si una determina licencia puede considerarse libre o no. Para considerarse libre debe de cumplir las 4 libertades, que ya conocemos casi como el padrenuestro:

1) libertad para ejecutar el programa – con cualquier finalidad –
2) libertad para estudiar cómo funciona el programa y adaptarlo a tus necesidades – por tanto, para cumplir este requisito, es impepinable el acceso al código fuente –
3) libertad para distribuir copias del programa
4) libertad para mejorar el programa y redistribuir las modificaciones

(Realmente se empiezan a numerar desde 0. Este hecho se resalta como una manía de los programadores en el libro «Dreaming in Code»)

Una de las preguntas típicas es: ¿existe alguna licencia que haya sido aprobada por la OSI y que haya sido rechazada por la FSF? Este conjunto formaría la respuesta a «software de código abierto, pero no libre» (bajo la definición de código abierto de la OSI). Pues sí, existen al menos 2 ejemplos de licencias aprobadas por la OSI pero que la FSF ha rechazado como software libre:

* la «NASA Open Source Agreement» versión 1.3 ¿Por qué la rechazó? Porque esa licencia incluye una provisión que pide que los cambios que realices sobre el código han de ser «creaciones originales» tuyas. Según la FSF, el desarrollo de software libre se basa en combinar código proveniente de distintas fuentes (libres) y la licencia indicada no permitiría realizar esa combinación.

* la «Reciprocal Public License«. Esta licencia tiene varios puntos que la hacen NO libre. Uno de ellos es el indicado en el apartado 6.1, que viene a decir que no puedes solicitar una compensación económica por redistribuir software bajo esta licencia «si ésta compensación es superior al propio coste de duplicación y distribución» . Esto es muy interesante, y se puede poner de contra ejemplo a aquellos que confunden software libre con software gratuito. Este punto indica que no sólo es lícito pedir una compensación económica por la distribución de software libre, sino que no debe de imponerse ningún límite a esa cantidad o dejará de ser, desde ese momento, una licencia libre.

Otro tema totalmente distinto es si existen licencias aprobadas por una organización y no por la otra. Ésto, en efecto, ocurre, hay numerosos ejemplos, pero no debe confundirse el hecho de que no haya sido (aún) aprobado con el de haber sido denegado. Son dos cosas distintas: en el primer caso, tal vez aún no han estudiado si es «aprobable» o no. En el segundo, lo han estudiado y han decidido que NO lo es.

La lista completa, a fecha de Febrero de 2009, se puede encontrar aquí [people.debian.org]. Es un fichero .diff, entre el fichero de licencias aprobadas por la FSF y el de aprobadas por la OSI. Las líneas que empiezan por – son licencias que la FSF ha aprobado (y la OSI aún no ha dicho nada). Las que empiezan por + son licencias que la OSI ha aprobado (y la FSF aún no ha dicho nada, o en los 2 casos indicados antes, directamente las ha considerado NO libres).

Así que, volviendo a la pregunta original: no existe el concepto de software libre pero no abierto. Por definición de software libre, es prerequisito sine qua non que sea software de código abierto. La afirmación inversa es posible: existen licencias (al menos 2) aprobadas por la OSI (software de código abierto) que han sido directamente rechazadas por la FSF y tachadas de licencias NO libres.

Por otra parte, un aplicativo software bajo licencia de código abierto (en el sentido open source, aprobada por la OSI) ¿puede ser a la vez software privativo? Por definición de software privativo (según la Wikipedia) :
«se refiere a cualquier programa informático en el que los usuarios tienen limitadas las posibilidades de usarlo, modificarlo o redistribuirlo (con o sin modificaciones), o cuyo código fuente no está disponible o el acceso a éste se encuentra restringido». Por tanto, si el código fuente no está disponible o se encuentra restringido, infringe la segunda norma de la OSI para ser considerado open source, y si tiene limitadas las posibilidades de redistribuírlo, incumpliría la primera regla de las normas. Por tanto, en mi opinión, no existe tal engendro.

Otro tema de discusión más profundo serían aquellas aplicaciones software que se distribuyen bajo licencias duales o múltiples, caso de MySQL, por ejemplo. Estos casos habría que estudiarlos aparte, y no en este post, porque ya empieza a salirme humo de la mollera 🙂

Nota: todo lo escrito en este post es una opinión o reflexión personal. Aplíquese el consiguiente sentido común, las precauciones necesarias y considérese la ya famosa introducción para todas estas disquisiciones por parte de gente profana en leyes: IANAL (I am not a lawyer). Me interesa mucho recibir vuestros comentarios/críticas/etc. para ir mejorando y corrigiendo este texto, allá donde sea necesario.

How to install Flash Builder on Linux

Lately, I’ve been wondering how to use Flash Builder on Linux. You know, Adobe is apparently putting Flash Builder (formerly also known as Flex Builder) for Linux on hold. So, if you are a Linux user, you’d better look for alternatives to FB (and certainly, there are a few...) However, I think that FB is the most feature-packed IDE for Flex development. So, how could we use that tool in our beloved system? Well, I managed to install it using Wine 1.1.23 on Ubuntu 9.04. This is the process that I’ve followed.

Download Flash Builder for Windows from Adobe Labs. Before the installation, you will have to configure Wine and install some needed DLL files. To do that, first and foremost, you’ll need to download the winetricks application and make it executable:

$ wget http://www.kegel.com/wine/winetricks
$ chmod a+x ./winetricks
$ ./winetricks

Now, you must select vcrun2005 and vcrun2005sp1 to install the needed dependencies : MS Visual C++ 2005 libraries and the related service pack.

Ok, time to install Flash Builder under wine:

$ wine flashbuilder4_b1_win_060109.exe

After finishing the installation, if you try to execute the application, you’ll get the following error:

«Licensing for this product has stopped working . This product has encountered a problem which requires that you restart your computer before it can be launched»

Restart the computer? on Linux? No way! 🙂 Now comes the tricky part, because you have to copy from a Windows installment some needed files:

a) On Windows, open the regedit tool and export the following branches:
HKEY_LOCAL_MACHINESOFTWAREAdobe –> adobe.reg
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesFLEXnet Licensing Service –> flexnet.reg

b) Back on Linux, import the previously saved registry branches

$ wine regedit
(now import adobe.reg and flexnet.reg files)

Now, mount the windows partition and copy this folders to the related wine folder:

$ cp -R /mnt/windows/Program Files/Common Files/Adobe ~/.wine/drive_c/Program Files/Common Files/

$ copy -R «/mnt/windows/Program Files/Common Files/Macrovision Shared» ~/.wine/drive_c/Program Files/Common Files/

Voilá! After entering the Serial Number or choosing the trial version, you’ll be able to work with Flash Builder on Linux 🙂 Enjoy!

Note: don’t forget to visit the WineHQ AppDB page about Flash Builder, for learning some hacks&tweaks that will allow you to address some annoying issues with code completion and the use of spaces as tabs.

Certificados digitales: algunas ideas de uso

Estos días, sufro en mis carnes, con la llegada de mi hijo Jon, la pesadilla de la burocracia post-parto que el Agorante Aberrante ya nos adelantó hace unas semanas. A pesar de que lo tenía en mente, la pereza ha podido conmigo y he preferido pasar por el aro: comprarme una carpeta azul y a llenarla de fotocopias. Lo peor no son las fotocopias, sino la peregrinación por la Seguridad Social, ambulatorio, SAC, caja de ahorros, guardería, … para realizar numerosos trámites burocráticos CON PAPEL, BOLI Y FOTOCOPIAS. Sí, en pleno siglo XXI, con la cartera llena de certificados digitales (el certificado de ciudadano Izenpe, el certificado de pertenencia a empresa – UPV/EHU -, el certificado de la tarjeta sanitaria ONA, el certificado del DNI electrónico, el certificado de estudiante -de postgrado- de la UPV/EHU …) NO puedo usar ninguno de ellos para:

* apuntar a mi hijo a la guardería (Haurreskolak): necesario -fotocopias del libro de familia-, sello por triplicado de la caja de ahorros, asegurando que el número de cuenta que les paso es de mi propiedad, fotocopia del DNI de ambos padres, fotocopia de la última declaración de la renta de ambos padres, fotocopia del certificado de empadronamiento.

*solicitar la ayuda por hijo: fotocopia DNI de los padres, fotocopia del libro de familia, documento que acredite que la cuenta bancaria me pertenece, fotocopia del padrón.

El Agorante ya creó un grupo «Trámites sin fotocopias» en Facebook para protestar por este anquilosamiento de la administración. Realmente disponemos de la tecnología y los conocimientos necesarios para evitar TODOS los papeles, fotocopias, viajes, sellos y manguitos de los que hemos hablado: basta con hacer uso de alguno de los 5 o 6 certificados distintos que tenemos cada uno de nosotros en las carteras. Bastaría con que la administración se decidiera a apostar de verdad por una administración sin papeles, digital, propia del siglo XXI.

Mediante el certificado digital podría autenticarme ante la administración y firmar digitalmente cualquier documento. Las marcas de tiempo (timestamp) permitirían garantizar que el documento se firmó en los plazos convenidos. La firma múltiple permitiría que mi mujer y yo pudiéramos firmar el mismo documento digital. El identificador único de usuario debería de permitir cruzar nuestros datos con las bases de datos de la administración (ya existentes), de tal forma que se comprobara de forma automática que efectivamente somos ciudadanos vascos residentes en Irún, Donostia o Abaltzizketa, empadronados hace X años y con determinada cuenta corriente en el banco (esto último ni siquiera hay que comprobarlo con el banco, bastaría con verificar con el usuario que el mismo número que se ha dado a la administración en las 547 veces anteriores sigue siendo válido) Verbigracia: cójase el número de cuenta corriente de la última declaración de la renta.

Por supuesto, el sitio web que albergara estos formularios, dispuestos para ser cumplimentados y firmados digitalmente, debería de ser accesible para todos los ciudadanos (evitando situaciones bochornosas por muchos botoncitos WAI que se pongan).

Y ya puestos a rizar el rizo, dado que la cumplimentación sería digital, podríamos hacer un seguimiento del estado por el que pasa cada documento (la petición de ayuda económica ha sido cumplimentada en Irún, ha llegado a Donostia, ha sido aprobada, el ingreso se ha realizado…) vía web…

Adelantándome a los «peros» que siempre oigo al proponer el uso masivo de la firma digital:

* «pero es que la ley de protección de datos no haría posible que _póngase_aquí_aquello_que_no_se_quiere_ver_implementado»

Espero que la ley de protección de datos permita que el usuario, libremente, de su consentimiento a que sus datos puedan ser usados por la administración pública (todas ellas) para facilitarle la vida burocrática. Es decir, que si Salud quiere comunicarse con Hacienda para validar mi última declaración, o mi última cuenta bancaria, lo pueda hacer.

* «pero es que las bases de datos de las administraciones no se comunican bien entre sí…»

Y mientras sigan así nos tiraremos los próximos 2000 años con la misma excusa…

* «Pero es que el certificado de Izenpe no es válido, este documento sólo se puede firmar con el de la FNMT»

¡Aaaaargghhh! Reino de Taifas… ¿Por qué cada autoridad de certificación se quiere colgar sus propias medallas? ¿Por qué no hay un reconocimiento global de autoridades Izenpe/FNMT/Camerfirma…?

* «pero es que los funcionarios no saben usar los certificados digitales esos…»

[BIS] Y mientras sigan así nos tiraremos los próximos 2000 años con la misma excusa…

Sí, lo sé, a veces da la impresión de que vivo en otro mundo – de Yuppy? – , pero dificilmente conseguirás aquello que ni siquiera consigues visualizar en sueños.

Extiende Firefox 3.5 y gana un MacBook Pro

La fundación Mozilla vuelve a organizar un concurso de desarrollo de plugins para Firefox. En esta ocasión, aprovechando la inminente publicación de Firefox 3.5 (el pasado día 16 salió a la luz la RC1), se ha abierto un apartado especial para premiar a las extensiones que hagan un mejor uso de las novedades de Firefox 3.5.

Todas las entradas participantes serán juzgadas por un panel de expertos, dividiéndose el concurso en 6 categorías: mejor plugin de nueva creación, mejor actualización de plugin, mejor plugin orientado a la compra online, mejor plugin en categoría de juegos y entretenimiento. Los premios a los ganadores de cada categoría incluyen un MacBook Pro de 15″ entre otros regalos. También habrá premios para los 6 siguientes clasificados en la categoría de mejor plugin de nueva creación.

El plazo de inscripción comenzó hace 3 días (16 de Junio) y se extiende hasta el 2 de Octubre de 2009. El 9 de noviembre se darán a conocer los nombres de los ganadores. ¡Anímate a participar!

Puedes leer las normas completas en la web del concurso.

Marcas de tiempo en el historial bash

Apunte rápido para que no se me olvide. De todos es conocido que cuando tecleas:

$ history

en la linea de comandos, se te muestra un listado con todos los comandos bash que hayas ejecutado hasta el momento. Pero, ¿a qué hora los ejecutaste? A veces esa información puede ser muy útil… El caso es que la marca de tiempo de ejecución de cada comando se guarda internamente en el historial, pero por defecto, no se muestra. ¡Ah! ¿Y cómo podemos mostrarla?

Fácil:

$ HISTTIMEFORMAT=’%F %T ‘
$ export HISTTIMEFORMAT
$ history

526 2009-06-11 00:06:04 man history
527 2009-06-11 00:06:42 man -a history
528 2009-06-11 00:09:51 HISTTIMEFORMAT=’%F %T ‘
529 2009-06-11 00:09:56 export HISTTIMEFORMAT
530 2009-06-11 00:10:08 history

¡tachaaaaaán!