Apropiándonos del Software. Módulo I. ¿Por qué Software Libre para el Sur?

José J. Contreras (1)

Muchas cosas se dicen a favor y en contra de la adopción del Software Libre por parte de los países del Tercer Mundo. No es un tema reciente, ya hace más de una década se discutían propuestas de diversos investigadores provenientes tanto del Norte como del Sur del planeta. En todos ellos, la posibilidad de la apropiación del software por parte de los países del Tercer Mundo aparece en una prospectiva promisoria. Resumamos algunas de ellas.

En primer lugar, hay que tomar en cuenta que, en el Tercer Mundo, el Estado es comúnmente la organización que hace uso más intensivo de las Tecnologías de Información y Comunicación (TIC). Esto ocurre porque en estos países, el Estado es la organización que mayor población emplea, mayores necesidades atiende y cuenta con una cierta cantidad de recursos. El sector privado es normalmente de menor escala. En muchos casos, no son más que empresas subsidiarias de transnacionales cuya casa matriz se encuentra en algún país del Primer Mundo. Allá, en esos países, las corporaciones sí invierten costosísimas sumas de recursos en la investigación y desarrollo de Tecnologías de Información y Comunicación. Pero las sucursales del Tercer Mundo son simples oficinas de venta. Oficinas que aportan a las ganancias de la corporación exclusivamente por sus ventas de productos terminados. Por estos lares no hay inversión significativa en investigación y desarrollo de TIC.

Es por esta razón que cuando pensamos en las TIC desde la perspectiva tercermundista, el Estado juega un papel fundamental. Nótese que al jugar el Estado un papel fundamental, estamos diciendo que desde la perspectiva tercermundista las TIC adquieren, de fondo, un carácter público. Esto no es un elemento “más” a tomar en cuenta, es que este carácter de “público” impregna el sentido de las TIC en su totalidad desde esta perspectiva.

Un nutrido grupo de gobiernos alrededor del mundo han venido adoptando el uso del software libre como política gubernamental. Una de las razones mayormente esgrimidas es de carácter económico. La adopción de software libre trae consigo, ipso facto, la eliminación total de los costosos pagos anuales por los contratos de licencia de uso del software privativo. Esto se ve aún más afectado dadas las crecientes medidas internacionales para el cumplimiento de los tratados internacionales de “propiedad intelectual”.

Pero sin disminuir lo anterior, hay también otras razones de importancia. Weber (2003) resume las principales razones para la adopción de “software libre” en tres: independencia, seguridad y autonomía (2). La “independencia” alude a que las organizaciones gubernamentales al usar software libre no quedan dependientes de las empresas extranjeras dueñas del software. De esta manera, las organizaciones estatales podrán cambiar de proveedor en cualquier momento que lo consideren conveniente sin mayores restricciones.

En este mismo sentido, la “seguridad” aparece como un factor de importancia en la utilización del software libre como política de estado. Cuando un estado adquiere una licencia de uso de un software de código cerrado no tiene posibilidad de conocer qué vulnerabilidades tiene, o puede tener, el software. Un ejemplo muy conocido fue revelado hace poco tiempo en los medios de comunicación. Los gobiernos estadounidense e israelita infectaron una instalación nuclear iraní a través de una red operada con el sistema de operación Windows (software privativo) de la corporación Microsoft. La infección se realizó utilizando un programa tipo “gusano” y conocido con el nombre de “stuxnet“. Una vez infectada la red Windows (que era un anillo externo de la instalación), fue sólo cuestión de tiempo para que a través de alguna memoria flash se infectará la red de seguridad interna en la cual corría el sistema “Step 7” (software privativo) de la corporación Siemens. Con el Step 7 se controlaban los circuitos de control PLC de las centrífugas en las que se enriquecía el uranio. Al lograr la infección de la red, se cambiaron los valores de las centrifugas, sin mostrar los cambios en los paneles de control. ¿El resultado? un retraso de años (algunos hablan de siete años) en el programa nuclear iraní (ver Broad y otros, 2011).

El principal error del gobierno iraní fue dejar su programa nuclear a la merced del software privativo. Software de código cerrado con vulnerabilidades no conocidas por los expertos del gobierno iraní, aunque sí muy bien conocidas por sus enemigos. Con Software Libre, en cambio, se tiene acceso al código fuente. Se puede revisar línea por línea de parecerle pertinente y necesario al usuario. Las vulnerabilidades pueden ser conocidas por todos y atendidas del modo que sea más pertinente.

Por último, Weber (2003) también nos habla del beneficio de la “autonomía”. Con el software libre, las entidades gubernamentales pueden hacer los cambios que ameriten los sistemas de manera autónoma. No se trata sólo de no depender de factores externos, sino también de promover la autonomía de los sistemas nacionales. Estas tres razones (independencia, seguridad y autonomía), pueden ser importancia relativa para organizaciones privadas con fines de lucro, pero innegablemente son cruciales para entidades gubernamentales dirigidas a la atención del bien público y la soberanía.

Los autores de origen srilanqués Weewarana y Weeratunga (2004) aportan un aspecto distinto al presentado por Weber (2003) relacionado con las razones por las cuales invertir en desarrollo de software de código abierto en los países del Tercer Mundo. Los autores ven en el desarrollo de la industria del software una oportunidad para participar exitosamente en el mercado global. El software de código abierto puede servir de palanca para el desarrollo de una industria competitiva. No sólo busca esta industria atender las necesidades domésticas gubernamentales, sino también exportar productos y servicios de software. Tal y como lo entiendo, la propuesta de Weewarana y Weeratunga (2004) es la de promover maquilas de software en los países del Tercer Mundo. Al igual que las políticas de “externalización de la producción” de lo que se trata es de “externalizar” las actividades de desarrollo de software para que sean realizadas en países con mano de obra y costos más baratos.

Weewarana y Weeratunga sostienen que el mercado del software se divide en dos grandes ramas. La primera está relacionada con el desarrollo del Linux y del software de operación de más bajo nivel. La segunda rama refiere a las aplicaciones de más alto nivel, con utilidades más específicas y los servicios relacionados con el mantenimiento. Los autores consideran que en los primeros momentos, el aporte de los desarrolladores del Tercer Mundo se dirigirá principalmente hacia el desarrollo de aplicaciones específicas y servicios. Sin embargo, es de esperar que sea sólo cuestión de tiempo para que los aportes significativos al kernel y a las aplicaciones de bajo nivel del sistema de operación provengan principalmente de desarrolladores provenientes de los países del Tercer Mundo.

Quisiera proponer un aporte distinto al de los autores arriba mencionados. El software libre no debe ser visto como una palanca para incorporarnos a la Globalización y sus modos de explotación ultracapitalista. El software libre es liberador. Si no, no es libre. Tener como fin hacer que Sri Lanka sea a las empresas multinacionales del software lo que es Bangladesh a las multinacionales del vestido no es liberador. Jamás podrá considerarse que una maquila de explotación capitalista que haga uso de las cuatro libertades del software libre esté en consonancia con la filosofía del Software Libre.

Ahora bien, en lo que sí coincidimos con Weewarana y Weeratunga es que el software libre abre fuertes posibilidades para la conformación de una industria regional competente en creación, desarrollo y mantenimiento de software. En estos tiempos de integración de bloques internacionales regionales, el software libre puede ser una herramienta importante para el fortalecimiento colaborativo entre las industrias de los diversos países de tal modo de ahorrar costos de inversión en desarrollo y aprender en conjunto. En un escrito anterior revisamos cómo fieros competidores del mercado del software se reunían en espacios de colaboración para el desarrollo y mantenimiento del kernel de Linux. En este caso, queremos proponer espacios de fortalecimiento colaborativo entre desarrolladores, instituciones gubernamentales y empresas del Sur.

El software libre puede servirnos de espacio para atender nuestras necesidades a partir del trabajo colaborativo en base a nuestras complementariedades. No se trata de enfatizar la competencia mercantilista. Se trata de enfatizar el desarrollo colaborativo entre los creadores de los diversos países. Esta colaboración puede provenir de la empresa privada, del gobierno, de la academia, de las comunidades de software libre o puede ocurrir a partir de la iniciativa propia y hasta individual.

La oportunidad de apalancar nuestros desarrollos, desde nuestras propias perspectivas y necesidades sureñas; la posibilidad de promover nuestros repositorios desde nuestras propias particularidades; la posibilidad de hacerlo, sin que tenga que estar necesariamente la mediación de organizaciones internacionales es única.

Aunque podría sonar lejano creemos que esto ya está ocurriendo. Es posible que en el desarrollo del middleware Ginga estemos presenciando una de estas primeras experiencias de colaboración sureña. Sin embargo, deberemos atender este asunto posteriormente porque se nos está haciendo demasiado extenso este escrito.

—-

Notas

(1) Investigador del Centro Nacional de Desarrollo e Investigación en Tecnologías Libres (Cenditel): jcontreras@cenditel.gob.ve

(2) Los autores aquí citados hablan de software de “código abierto” y no de “software libre”. Ambos conceptos son distintos. Sin embargo, en el presente escrito utilizaremos “software libre” y “código abierto” como si lo fuesen. En todo caso, el significado dominante en nuestro escrito será el de “software libre” es decir, software en el cual se mantienen las libertades de uso, distribución, acceso y modificación del código fuente. En otro momento deberemos abordar la discusión de las diferencias entre estos conceptos desde una perspectiva sureña.

Referencias

Broad, W., Markoff, J. y Sanger, D. (2011) Israeli Test on Worm Called Crucial in Iran Nuclear Delay. Periódico The New York Times. Edición del 25 de Enero de 2011.

Weber, Steven (2003). Open Source Software in Developing Economies.

Weerawarana, S. y Weeratunga J. (2004). Open Source in Developing Countries. Swedish International Development Cooperation Agency (SIDA). Estocolmo. Suecia.