Software Libre, mas no liberado.

En el país ha habido un reciente surgimiento del software libre en el uso institucional. Este es un surgimiento que lleva tiempo esperado ocurrir desde el momento que saliera a la luz del país el decreto 3390 del presidente Hugo Chavez, el cual llama al uso del Software Libre por parte de los entes gubernamentales.

El decreto tiene ya varios años de vida (desde el 2004) y la adopción del software libre parece haber sido cuesta arriba en la mayoría de las instituciones, afortunadamente esta situación parece estar cambiando lentamente ya que ha aumentado el nivel de adopción de tecnologías libres en el sector publico.

Libertades

El software libre propone varias libertades, libertades conceptuales que son importantes para nuestro gobierno, ya que las mismas aseguran que ninguna empresa tecnológica pueda controlar el uso de nuestra información y de nuestros procesos informáticos.

Las libertades promulgadas por el software libre, en especial por la licencia GPL y los ideales del grupo GNU detrás de esta licencia son las siguientes.

  • Libertad para usar el programa para cualquier fin que uno desee
  • Libertad para estudiar como funciona el programa, y de cambiarlo para hacer lo que uno necesite
  • Libertad para distribuir copias a fin de ayudar a los demás
  • Libertad para mejorar el programa y de distribuir estas modificaciones para que se beneficie la comunidad

Todas estas libertades se encuentran plasmadas en la licencia GPL, licencia que asegura que los trabajos publicados bajo la misma tengan estas libertades protegidas de modo que no puedan ser limitadas a los usuarios que reciban el programa, Esta licencia esta en proceso de análisis para su adaptación a la legislación Venezolana (en su forma GPLV).

“Software Libre”

El problema en nuestro caso, surge cuando analizamos que definimos como “Software Libre”.

En gran parte del uso gubernamental, los entes están aplicando el uso directo de programas de computación existentes, basados en licencias libres, tales como lo son el sistema operativo Linux, o el sistema de ofimática OpenOffice.

Sin embargo, en otros usos gubernamentales, el uso de “Software Libre”  no es un elemento tan simple o directo. Es difícil por ejemplo pretender que CADIVI consiga en internet un sistema existente para el manejo de solicitudes cambiarias bajo el régimen Venezolano.

Bajo este tipo de eventualidades y usos especiales, el primer camino que se toma es el uso de sistemas libres para el desarrollo de las aplicaciones requeridas, como por ejemplo el uso del lenguaje PHP en vez del sistema ASP de Microsoft, o el uso de librerías (frameworks) libres (como Rails, o OpenERP) en vez de soluciones cerradas (como SAP) para el desarrollo de la aplicación requerida.

Este desarrollo puede aun así confundirse con Software Libre, dado que se basa en un sistema libre, pero el mismo no debe ser considerado tal hasta que sea liberado al publico, mientras esto no ocurra, legalmente estaremos cumpliendo con la licencia GPL y posiblemente con el decreto 3390, pero moralmente estamos perdiendo valores del software libre, específicamente:

Compartir con la comunidad

Uno de los valores ideales básicos del Software Libre, al no compartir el esfuerzo realizado con el dinero del pueblo Venezolano, para cubrir necesidades del pueblo Venezolano, estamos obligando a otros entes o usuarios finales, Venezolanos o del mundo a duplicar el esfuerzo, perdiendo el trabajo hecho ya en un ente del estado y dificultando la integración con otros entes y sistemas.

Por supuesto este valor no siempre existe, usando el ejemplo del sistema de control cambiario de CADIVI, es dudoso que otro ente del país requiera poder hacer un registro y control de solicitudes cambiarias.

Sin embargo pueden haber elementos o módulos dentro del sistema como un todo que permita ahorrar trabajo y homogeneizar sistemas en otros entes del estado.

También el ente CADIVI al no compartir este trabajo, esta perdiendo una de las libertades practicas, una de las libertades que no están definidas en la ideología del software libre, pero que nacen como valores prácticos del uso del software libre. Una de estas “Libertades” es:

Libertad de recibir apoyo de la comunidad

Incluso si un sistema altamente especializado como el sistema de CADIVI puede no tener un interés en su globalidad para la comunidad, aun así, la comunidad tiene que dar al sistema.

Es común que empresas con fines de lucro hoy en día liberen una versión base totalmente funcional, o incluso su código completo a la comunidad para su uso.

A cambio de esto la comunidad siempre tiene un ojo en el código del sistema, descubriendo errores en el sistema, y aportando nueva funcionalidad al mismo de la cual todos se benefician.

Esta es una técnica que es muy usada y apoyada por los programadores de software libre para encontrar huecos de seguridad, de hecho existe un dicho en la comunidad de software libre que dice aproximadamente “Muchos pares de ojos llevan cualquier error a la superficie”, que es una ideología contraria a la ideología del software cerrado que piense que ocultando el código se hará mas difícil que los usuarios maliciosos encuentren fallos de seguridad, teoría que ha sido desmentida con la constante lista de fallos de seguridad que son encontrados y explotados en el sistema Windows.

Estructura

Por ende, vemos que existe un valor tanto en el compartir las mejora hechas por nuestros usuarios a programas existentes, como lo es compartir sistemas específicos o de origen local, tanto para los usuarios como para los creadores del sistema.

El problema que surge ahora es que el compartir el software, nuevamente, cumple con los requisitos legales del GPL y del software libre, pero sin una infraestructura especifica, se pierde su valor practico como software libre.

Les ofrezco un ejemplo. En la institución donde trabajo, se usa por orden de nuestro ente rector, un sistema administrativo (De orden contable, presupuestario y de RRHH) creado por una empresa venezolana, y que fuera “liberado” a nuestro ente rector y entes adscritos por un acuerdo con esta empresa.

Este software es efectivamente libre bajo la definición de Software Libre (aunque no se encuentra legalmente licenciado bajo ninguna licencia, de software libre o no, situación que es común a una informalidad o desconocimiento del proceso del software libre aun visible en nuestro país). El mismo ha sido modificado para arreglar errores y para extender su funcionalidad en innumerables formas por parte de nuestro ente rector, y nuestros entes adscritos incluido aquel donde trabajo.

Esta versión modificada es, aun así, manejada por nuestro ente rector, quien mantiene copias de las modificaciones, mas la empresa creadora del sistema se ha “retirado” del intercambio con el ente gubernamental, no han establecido un mecanismo ni publico ni privado mediante el cual las modificaciones puedan subir “upstream” (rio arriba) hacia el código “central” que maneja esta empresa para que otros usuarios se beneficien.

Al mismo tiempo la empresa, ha mantenido un proceso aparentemente dual, mezclando la ideología de la empresa de software libre (cobro a sus clientes por el servicio de instalación, modificación y asistencia técnica sobre el programa) con el del software propietario (vendiendo licencias o copias del software o versiones de este a algunos de los clientes).

Todo esto ha creado lo que se conoce como “forks” o derivaciones, un proceso que aveces es positivo y vital en el software libre, pero que en un estado de anarquía alrededor del programa lo que genera es una de-valoración de la utilidad del programa.

Lo que ocurre básicamente en un “fork” es que cada usuario, o grupo pequeño de usuarios crea su propia versión del sistema, lo usa, y lo modifica, manteniendo las modificaciones de manera interna, no por deseo de acaparar las mismas si no por el costo de infraestructura y de organización que requiere el mantener una copia publica del sistema. Esto termina en innumerables copias disjuntas, donde existen cambios que solo se han implementado en algunos lugares mas no en otros.

La manera de evitar esto es tener un ente central, un sitio donde se pueda de forma coherente: Reportar fallos y problemas, Aportar cambios y extensiones al código fuente y realizar solicitudes y respuestas de soporte por parte de los usuarios a la comunidad.

Existen varias teorías sociales sobre como controlar este tipo de aspecto, desde la figura conocida como la del “Dictador Benevolente” utilizada en algunos proyectos libres como en el lenguaje de programación Perl, o en el sistema de transmisión de correo electrónico Postfix. Sistemas de aportes mas abiertos y manejados por grupos designados de colaboradores como lo es el núcleo Linux o el trabajo en muchas distribuciones de linux, y el trabajo mas anarquico, basado en sistemas como github donde no existe necesariamente un control central, pero donde todos los forks tienen aun una relación entre si y no son enteramente disjuntos.

La base de todos estos sistemas es aun así, la infraestructura, un sitio donde se puedan reportar errores, aportar código e intercambiar con la comunidad.

Esta infraestructura es mas económica de mantener si la misma se centraliza a nivel horizontal entre los productores de software libre, y la misma puede ser centralizada en el exterior fácilmente (servicios como github, sourceforge y muchos otros), pero existen también ventajas a realizar una centralización de manera local en Venezuela, ya que permitiría observar todos los proyectos allí alojados, dando una vista a los sistemas que son importantes o adecuados a nuestra realidad social, estructural y legal como país.

Ya existe un servicio así en Venezuela, y es la forja provista por el cnti a través del portal forja.softwarelibre.gob.ve

Mensaje final

Resumiendo todo este articulo, mi mensaje final no es exactamente “usen la forja”, ya que este es un sistema pero no es el único existente, mi mensaje general es el siguiente.

  • Usar una plataforma libre para un desarrollo no compartido podrá ser legal, pero es una perdida tanto para el desarrollador como para el publico
  • No dupliquemos esfuerzos, vamos a coordinar
  • Si el sistema es libre, publiquen el código
  • No dejen el sistema al aire, que siempre haya alguien dedicado a recibir aportes, a mantener un orden en la faceta publica del proyecto.
  • No reinventen la rueda, busquen, puede que la solución ya haya sido creada por alguien
  • Si necesitan hacer cambios a una aplicación, y estos cambios pueden ser útiles para otros, compartan estos aportes con los desarrolladores originales.
  • Trabajemos en comunidad

Leave a Reply

Your email address will not be published. Required fields are marked *