Amén de lo ridículo que resulta acusar a la oposición de realizar fraude manipulando el sistema de escrutinio provisorio (que está bajo el control del Ministerio del Interior), cabe analizar por qué se dio esta situación en algunas mesas de votación.

Analicemos algunos casos a modo de ejemplo.

Cero votos para «Juntos por el Cambio»

La tuitera Ivana Günther dice:

La mesa donde votó mi hermana y una amiga arrojó cero votos a @mauriciomacri. Ambas lo votaron. Adjunto el telegrama.@elisacarrio @edufeiok @mariuvidal @elprestoOk pic.twitter.com/OZt9GjrxtJ

— Ivana Günther (@ivo_gunther) 14 de agosto de 2019

(Copia en archive.org)

Si vemos el telegrama correspondiente observamos que, en la categoría «presidente/vicepresidente», el partido «Juntos por el Cambio» no tiene votos.

Pero no es que tenga cero (0) votos, es que el presidente de mesa omitió escribir cuántos votos obtuvo efectivamente ese partido en esa categoría y el suplente no se dio cuenta del error (no hay fiscales partidarios que hayan firmado ese telegrama. Sin embargo, en el sitio oficial de publicación de resultados del Ministerio del Interior, el sistema informa que «Juntos por el Cambio» tiene 0 votos a presidente y vice.

Veamos otro caso:

Quiero denunciar a los fiscales que firmaron este telegrama, NO ESTA MI VOTO Y DE NINGUNO DE LOS QUE VOTAMOS A JUNTOS POR EL CAMBIO, CERO VOTO pic.twitter.com/LSXQKfz0M8

— pepe (@pepeoeste) 13 de agosto de 2019

(Copia en archive.org)

Y tiene razón pepeoeste en enojarse con los fiscales de esa mesa. Si uno mira la imagen del telegrama puede observar que el presidente de mesa también omitió los votos a presidente y vice de «Juntos por el Cambio», situación que no fue detectada por ninguno de los 5 fiscales firmantes.

Y al igual que en el caso anterior, en el sistema oficial el telegrama fue cargado asignando 0 votos a «Juntos por el Cambio».

Cero votos para el «Frente de Todos»

Pero también tenemos telegramas como este (firmado por el presidente de mesa, el suplente y dos fiscales) en donde los casilleros vacíos corresponden al «Frente de Todos».

Consistentemente con los casos anteriores, la página de resultados muestra 0 votos para el «Frente de Todos».

Veamos otro telegrama (para balancear los ejemplos) donde tampoco se han anotado los votos obtenidos por el «Frente de Todos» (también firmado por el presidente, el suplente y dos fiscales).

Y como siempre, en el sistema oficial esto aparece reflejado como 0 votos para el «Frente de Todos».

Cero votos para todos

Aquí tenemos un caso extremo:

Escuela 31, mesa 327: el telegrama más increíble de los que encontré hasta ahora. Firmado por múltiples autoridades, no tiene ni un solo número. Estos resultados están cargados al sistema como cero. pic.twitter.com/HebiuQAm2A

— Marcos (@hiperfalcon) 13 de agosto de 2019

(Copia en archive.org)

Efectivamente, en este telegrama (firmado por el presidente de mesa y 4 fiscales), ni siquiera se molestaron en colocar un número. Está completamente vacío. Sin embargo, fue cargado en el sistema de escrutinio con 0 votos en todos los partidos, para cada categoría, como si nadie hubiera votado en esa mesa.

El análisis de los datos

El especialista en bioinformática e investigador Rodrigo Quiroga descargó los datos finales del escrutinio provisorio y realizó un análisis para determinar la distribución de los votos a cada fuerza política en cada mesa de votación.

En el eje X (horizontal) está la cantidad de votos obtenida, y en el eje Y (vertical) la cantidad de mesas en la que se obtuvo cada cantidad de votos.

Los votos obtenidos por ambos partidos siguen una distribución normal (lo esperable en estos casos). La media de «Juntos por el Cambio» es un poco menor que la del «Frente de Todos», por lo que la campana está levemente desplazada hacia la izquierda (efecto de haber logrado menos votos). Lo que salta a la vista es la gran cantidad de mesas con 0 votos: 2.904 para «Juntos por el Cambio» y 2.768 para el «Frente de Todos» (las mesas con 0 votos para ambos son 2.497).

Claramente, el efecto «0 votos» que tanto llamó la atención de militantes e incluso algunos diputados como Fernando Iglesias y Elisa Carrió afectó a ambos partidos casi por igual (la leve diferencia contra «Juntos por el Cambio» puede deberse al corrimiento hacia la izquierda antedicho).

La causa

Los operadores de carga de los telegramas (unos 1.700 en total) son personas contratadas a través de dos consultoras de recursos humanos (Estrategia Laboral y Randstad). Si bien desempeñan sus funciones la noche de las elecciones en los centros de carga de Correo Argentino en Barracas (Ciudad de Buenos Aires) y Monte Grande (Provincia de Buenos Aires), reciben directivas del personal de la empresa Smartmatic.

Durante el simulacro de escrutinio realizado el 29 de junio de 2019, los operadores recibieron la instrucción de, ante un valor faltante o ilegible en los telegramas, introducir un asterisco (*). De esta forma, quedaba constancia en el sistema informático de que el telegrama en cuestión tenía un error o un dato no reconocible. Pero en el simulacro del 13 julio la directiva cambió. En adelante, cada vez que en un telegrama faltara algún valor numérico, o este resultara ilegible, debía introducirse un cero (0). En el simulacro siguiente, el 20 de julio, el software de carga ya había sido modificado para reflejar esta política, no permitiendo la introducción de asteriscos.

De esta forma, el operador de carga corrige (completa o enmienda) los telegramas, sin que en el sistema informático quede ningún registro del problema presentado por el telegrama. Esta es precisamente la causa de la gran cantidad de telegramas con valores nulos, que afecta proporcionalmente a cada partido político.

¿Cuáles son las razones que pueden haber llevado a tomar esta decisión? Probablemente, la intención de hacer más efectivo el escrutinio provisorio, procesando más telegramas en el menor tiempo posible. Las autoridades de la Dirección Nacional Electoral (dependiente del Ministerio del Interior) no pueden haber desconocido esta política de carga de datos. Sin embargo, hasta la fecha nadie lo ha aclarado públicamente. Mientras tanto, y a la espera de la finalización del escrutinio definitivo, las sospechas (infundadas) siguen circulando por las redes.

Adenda

El autor de este artículo ya había advertido de esta situación un día antes de las elecciones PASO del 11 de agosto de 2019.

ATENCIÓN: Los operadores de carga contratados por @smartmatic tienen órdenes de, ante un dato ilegible o incompleto (un valor faltante), ingresar un "0". No se deja constancia de que el operador tomó esa decisión y completó el telegrama, por lo que no se informa esa situación.

— Javier Smaldone (@mis2centavos) August 10, 2019

Hoy, ante múltiples irregularidades en el proceso de implementación de un nuevo sistema de transmisión de «telegramas» y escrutinio provisorio, muchos cuestionamos (entre otras cosas) el rol de Smartmatic. Casi inmediatamente, somos acusados de querer que Indra vuelva a hacerse cargo del proceso. La cuestión se plantea como un falso dilema, sin que nadie parezca plantearse la pregunta más obvia: ¿es necesario depender de una empresa privada para poder publicar los resultados provisionales de las elecciones el domingo por la noche?

¿Qué hace la empresa contratada para la realización del escrutinio provisorio?

Considerando el sistema que se usará en las elecciones presidenciales de 2019, primero enumeremos qué no provee la empresa contratada.

• Las impresoras multifunción que ofician de escáneres, las netbooks y los módems 3G/4G que son llevados a las 11.000 escuelas y 1.100 centros de transmisión de Correo Argentino son provistos por el Estado.
• La conectividad a Internet es provista por los 3 proveedores de telefonía celular de la Argentina.
• La infraestructura de servidores y red donde se reciben los «telegramas» digitalizados es provista por Correo Argentino.
• El espacio físico, los puestos de trabajo y las computadoras que utilizan los operadores que visualizan los «telegramas» y cargan los valores también son provistos por el Correo Argentino.
• Los servidores donde se publica el resultado del escrutinio provisorio también son provistos por el Correo Argentino.

Entonces, finalmente, ¿qué provee la empresa contratada para el escrutinio provisorio?

• El software que se ejecuta en las netbooks, que escanea los «telegramas» en papel, produciendo archivos con las imágenes correspondientes y transmitiéndolos luego de forma segura a un servidor central.
• El software que permite a los operadores visualizar las imágenes de los «telegramas» y cargar los valores correspondientes, realizando luego la totalización, que se ejecuta en los servidores de Correo Argentino.
• El software que publica los resultados obtenidos en el proceso, que también se ejecuta en los servidores de Correo Argentino.
• Los operadores de transmisión (en las escuelas) y de carga (en las instalaciones de Correo Argentino) de los «telegramas», que en realidad no son empleados de la empresa, sino personas contratadas por el día a través de consultoras de recursos humanos.

¿Hace falta una empresa para esto?

¿Hace falta una empresa privada para hacer un software que escanee y transmita imágenes, otro para que las muestre en una pantalla permitiendo la carga de datos y realizando la totalización, y otro para que publique los resultados? Claramente, no. ¿Hace falta una empresa para subcontratar unos 11.000 operadores de transmisión y 1.800 operadores de carga durante una noche (más la capacitación y las pruebas)? Seguramente tampoco.

De hecho, sin ir más lejos, tenemos en la Argentina dos buenos ejemplos recientes de provincias que se han encargado de esta tarea por sus propios medios. Uno es la Provincia de Chubut. Aquí podemos ver una foto del reducido equipo de informáticos que realizó el sistema de escrutinio provisorio para las elecciones provinciales de 2019:

El secretario de informática jurídica del Superior Tribunal Lic. Alejandro Biaggio, muy conforme con su equipo de trabajo y con él funcionamiento del sistema informático utilizado para estás elecciones. pic.twitter.com/FzWHTUmnPR

— Tribunal Electoral Chubut (@ChubutTribunal) 11 de junio de 2019

Otro ejemplo notable es el de la Provincia de Santa Fe, que a lo largo de 3 años desarrolló un sistema para transmitir los «telegramas» digitalmente desde las escuelas y realizar el escrutinio provisorio y la publicación de resultados, reuniendo personal informático estatal, investigadores y docentes universitarios e integrantes de ONGs para el diseño, el desarrollo y la implementación (realizada de forma progresiva). Aquí podemos ver la primera experiencia realizada en 2017:

Exitosa prueba piloto! Felicitamos a aut d mesa fiscales subdelegados q fueron parte c tablet y celular en las PASO2017 @GobSantaFe pic.twitter.com/PrehSnCkE4

— SantaFe Tecnologías (@STGSantaFe) 16 de agosto de 2017

Si un Estado provincial tiene los recursos técnicos, humanos y económicos para realizar esta tarea, ¿por qué no puede hacerlo el Estado nacional? En definitiva, los sistemas para transmitir los resultados de las casi 8.000 mesas de Santa Fe y los resultados de las casi 100.000 mesas de la Argentina no pueden ser demasiado diferentes (salvo cuestiones de escala y complicaciones de logística que de todas formas son resueltas por el Correo Argentino). ¿Por qué los gobiernos de los últimos 22 años (todos y cada uno) decidieron tomar el atajo de contratar a una empresa para «resolver el problema»?

Sería bueno que en vez de discutir si el escrutinio de las elecciones nacionales tiene que hacerlo Smartmatic, Indra o la próxima empresa que aparezca (por lo general, transnacional), el Estado argentino decidiera encarar el desarrollo de una solución para que los resultados del domingo a la noche no dependan del buen desempeño de una empresa. Y no es que una o varias empresas no puedan participar del desarrollo de las herramientas o de otras tareas como las pruebas y las auditorías, en tanto la solución resultante sea propiedad del Estado.

Y además se contaría con una ventaja adicional: el software utilizado podría distribuirse no sólo a los partidos políticos sino a la población en general, sin problemas de derecho de autor. En definitiva, no sería necesario violar ni el artículo 108 del Código Electoral Nacional ni la acordada 3/2017 de la Cámara Nacional Electoral. Todo por el mismo precio (pagado una sola vez, y no cada dos años).

Analizando la metadata de dichos archivos, además de encontrar múltiples vulnerabilidades en el proceso de generación de los mismos, notamos una discrepancia más que dudosa: la fecha de creación corresponde con la realización del simulacro anterior, 13 de julio de 2019. ¿Se trató de simular un simulacro —que no podía fallar— para dejar conformes a los partidos políticos y a la prensa?

El origen de los PDF

Las autoridades de la Dirección Nacional Electoral entregaron al periodista de Clarín Alejandro Alfie un pen drive conteniendo 800 archivos PDF, afirmando que era una muestra de los utilizados en ese simulacro, para que los distribuyera entre sus colegas de la prensa. Gracias al periodista de Perfil Cristian Riccomagno pudimos obtener una muestra de 60 de esos archivos. Es importante hacer hincapié en esto: los PDF no son los archivos desde los cuales se imprimieron los ‘telegramas’ de prueba, sino el resultado de un escaneo en formato TIFF y la posterior conversión a PDF usando la herramienta tiff2pdf, tal como resulta de la transmisión desde las escuelas y el posterior procesamiento anterior a la carga. En definitiva, no pueden ser los archivos desde los cuales se imprimieron los ‘telegramas’ de prueba, dado que contienen una imagen incrustada (producto de un escaneo).

Imagen incrustada dentro del PDF

De ser los archivos generados como resultado de la transmisión de los ‘telegramas’ digitalizados desde las escuelas, estos archivos PDF deberían haber sido generados durante la mañana del día 20 de julio de 2019, pero analizando la metadata resultan haber sido generados el 13 de julio de 2019 durante las 11:35 y las 11:38.

La verificación

1. Descargamos el archivo .zip conteniendo los 60 telegramas:

wget https://archive.org/download/telegramas-simulacro/telegramas.zip

2. Descomprimimos el archivo .zip:

unzip telegramas.zip

3. Extraemos la metadata de cada archivo PDF, usando la herramienta pdfinfo quedándonos sólo con la fecha de creación y ordenamos el resultado cronológicamente:

for i in $(ls telegramas/*); do
   pdfinfo $i | grep 'CreationDate';
done | sort

El resultado es el siguiente:

CreationDate:   Sat Jul 13 11:35:51 2019 -03
CreationDate:   Sat Jul 13 11:35:51 2019 -03
CreationDate:   Sat Jul 13 11:35:52 2019 -03
CreationDate:   Sat Jul 13 11:35:53 2019 -03
CreationDate:   Sat Jul 13 11:35:53 2019 -03
CreationDate:   Sat Jul 13 11:35:53 2019 -03
CreationDate:   Sat Jul 13 11:35:59 2019 -03
CreationDate:   Sat Jul 13 11:36:00 2019 -03
CreationDate:   Sat Jul 13 11:36:00 2019 -03
CreationDate:   Sat Jul 13 11:36:01 2019 -03
CreationDate:   Sat Jul 13 11:36:01 2019 -03
CreationDate:   Sat Jul 13 11:36:02 2019 -03
CreationDate:   Sat Jul 13 11:36:03 2019 -03
CreationDate:   Sat Jul 13 11:36:03 2019 -03
CreationDate:   Sat Jul 13 11:36:04 2019 -03
CreationDate:   Sat Jul 13 11:36:05 2019 -03
CreationDate:   Sat Jul 13 11:36:07 2019 -03
CreationDate:   Sat Jul 13 11:36:07 2019 -03
CreationDate:   Sat Jul 13 11:36:08 2019 -03
CreationDate:   Sat Jul 13 11:36:08 2019 -03
CreationDate:   Sat Jul 13 11:36:09 2019 -03
CreationDate:   Sat Jul 13 11:36:10 2019 -03
CreationDate:   Sat Jul 13 11:36:10 2019 -03
CreationDate:   Sat Jul 13 11:36:11 2019 -03
CreationDate:   Sat Jul 13 11:36:12 2019 -03
CreationDate:   Sat Jul 13 11:36:13 2019 -03
CreationDate:   Sat Jul 13 11:36:14 2019 -03
CreationDate:   Sat Jul 13 11:36:15 2019 -03
CreationDate:   Sat Jul 13 11:36:15 2019 -03
CreationDate:   Sat Jul 13 11:36:16 2019 -03
CreationDate:   Sat Jul 13 11:38:01 2019 -03
CreationDate:   Sat Jul 13 11:38:01 2019 -03
CreationDate:   Sat Jul 13 11:38:02 2019 -03
CreationDate:   Sat Jul 13 11:38:02 2019 -03
CreationDate:   Sat Jul 13 11:38:03 2019 -03
CreationDate:   Sat Jul 13 11:38:03 2019 -03
CreationDate:   Sat Jul 13 11:38:03 2019 -03
CreationDate:   Sat Jul 13 11:38:04 2019 -03
CreationDate:   Sat Jul 13 11:38:04 2019 -03
CreationDate:   Sat Jul 13 11:38:05 2019 -03
CreationDate:   Sat Jul 13 11:38:05 2019 -03
CreationDate:   Sat Jul 13 11:38:05 2019 -03
CreationDate:   Sat Jul 13 11:38:06 2019 -03
CreationDate:   Sat Jul 13 11:38:06 2019 -03
CreationDate:   Sat Jul 13 11:38:06 2019 -03
CreationDate:   Sat Jul 13 11:38:07 2019 -03
CreationDate:   Sat Jul 13 11:38:07 2019 -03
CreationDate:   Sat Jul 13 11:38:07 2019 -03
CreationDate:   Sat Jul 13 11:38:08 2019 -03
CreationDate:   Sat Jul 13 11:38:08 2019 -03
CreationDate:   Sat Jul 13 11:38:08 2019 -03
CreationDate:   Sat Jul 13 11:38:09 2019 -03
CreationDate:   Sat Jul 13 11:38:09 2019 -03
CreationDate:   Sat Jul 13 11:38:09 2019 -03
CreationDate:   Sat Jul 13 11:38:10 2019 -03
CreationDate:   Sat Jul 13 11:38:10 2019 -03
CreationDate:   Sat Jul 13 11:38:10 2019 -03
CreationDate:   Sat Jul 13 11:38:11 2019 -03
CreationDate:   Sat Jul 13 11:38:11 2019 -03
CreationDate:   Sat Jul 13 11:38:15 2019 -03

Como puede observarse, todos los PDF fueron generados el día 13 de julio de 2019 entre las 11:35:51 y las 11:38:15. Son el resultado de ‘telegramas’ transmitidos desde las escuelas, pero no el 20 de julio de 2019.

La conclusión

La Dirección Nacional Electoral entregó a la prensa archivos PDF supuestamente utilizados en el simulacro del 20 de julio, pero en realidad correspondientes a las transmisiones del simulacro del 13 de julio. Si esos fueron los PDF procesados por los operadores de carga, entonces el simulacro de escrutinio no se basó en lo que se estaba transmitiendo en ese momento desde algunas escuelas, sino en datos previamente recibidos. De este modo, se aseguraría que una falla en el sistema —como la ocurrida en el simulacro del 29 de junio de 2019— pasara desapercibida por quienes observaban el proceso en los centros de carga de Correo Argentino.

Casualmente, las vulnerabilidades están relacionadas con un componente del sistema sobre el que escribí hace unos días. A continuación, el texto completo.

ADVERTENCIA DE SEGURIDAD: Vulnerabilidades potencialmente explotables en el software de conversión de formato de los ‘telegramas’ electorales

Autores: Iván Arce, Enrique Chaparro <echaparro@vialibre.org.ar>, Javier Smaldone
2019-08-03

Resumen

El empleo de utilidades de software vulnerables para realizar la conversión de formato de los archivos con información para el escrutinio provisorio de las elecciones nacionales de 2019 pone en riesgo la integridad del proceso.

Contexto

La información de los escrutinios de mesa de las elecciones nacionales de 2019 es transmitida a Correo Oficial de la República Argentina S.A. (en adelante, Correo Argentino) que actúa por cuenta y orden del Ministerio del Interior para la realización del escrutinio provisorio y su información a las agrupaciones políticas y el público en general. La modalidad que se ha decidido emplear para las elecciones nacionales de 2019 implica en un número de casos (se ha informado públicamente alrededor de 11.000) la transmisión desde los establecimientos donde se ubican las mesas de archivos con la imagen del documento denominado «telegrama» directamente a los dos centros de procesamiento de Correo Argentino (ubicados en Barracas, Ciudad Autónoma de Buenos Aires, y Monte Grande, Provincia de Buenos Aires) para su carga por operadores y la presentación de resultados. De acuerdo con información de dominio público, entre el archivo transmitido y el presentado a los operadores (y posteriormente puesto a disposición para acceso público) se produce un cambio de formato de TIFF (Tagged Image File Format) a PDF (Portable Document Format). Analizando uno de estos documentos en formato PDF hecho público en un medio de prensa ^[1] hemos hallado que la utilidad de conversión empleada es el programa tiff2pdf, parte de la biblioteca libtiff. El campo de metadatos correspondiente indica "./Producer (libtiff / tiff2pdf - 20150912)", como puede observarse en las salidas de diversos comandos que se muestran en el Anexo 1. Esta fecha de ‘release’ corresponde a la versión 4.0.6 de las utilidades mencionadas, las que son vulnerables a numerosos ataques incluyendo ejecución remota de código y denegación de servicio. Luego de la comprobación inicial, se corroboró la presencia del mismo problema en un lote de 60 archivos entregados a la prensa como muestra del resultado de la recepción en el simulacro del 20 de julio.^[2][3]

Detalles

La biblioteca de utilidades libtiff versión 4.0.6 contiene un gran número de vulnerabilidades potencialmente explotables. Cuarenta y seis de ellas han sido documentadas a la fecha en el catálogo Common Vulnerabilities and Exposures (CVE) y son en su mayoría conocidas desde hace tres años.^[4] Un agente malicioso con acceso al sistema de transmisión o con capacidad de insertar un archivo espurio en el repositorio de los archivos de imagen recibidos podría emplear un archivo TIFF especialmente formateado para explotar una o más de estas vulnerabilidades. Esta acción le permitiría al atacante remoto producir denegación de servicio o ejecutar código arbitrariamente en el servidor donde se lleva a cabo la conversión.^[5] Adicionalmente, existen vulnerabilidades detectadas en versiones posteriores de la misma biblioteca que podrían también afectar a la versión instalada.

El Anexo 2 lista las vulnerabilidades del catálogo CVE con mayor probabilidad de ser explotadas en el entorno de referencia.

Impacto

Dependiendo de las vulnerabilidades explotadas, un potencial atacante podría impedir el correcto funcionamiento de los servidores que reciben la transmisión de telegramas, borrar o alterar los datos que se reciben de los centros de transmisión ubicados en los establecimientos donde se vota, retrasar el proceso de escrutinio provisorio por tiempo indeterminado, hasta que se identifique, diagnostique y corrija el problema en tan solo uno de cientos o miles de archivos TIFF recibidos, o utilizar el servidor afectado como plataforma para lanzar ataques «laterales» a otros componentes de la red. Para lanzar el ataque, el agente malicioso no requiere privilegios en el servidor donde se almacenan los archivos TIFF a convertir; le bastará con tener acceso o posibilidad de ejecutar un programa en cualquiera de las 11.000 estaciones (netbooks) que se utilizarán para transmitir los telegramas, o ejecutar el software de transmisión en otra computadora conectada a una red de los establecimientos desde donde se emiten los «telegramas», o transmitir el archivo TIFF «malformado» desde cualquier otro dispositivo que tenga conectividad con el servidor que recibe las transmisiones.

Análisis

El proceso de conversión de formatos agrega costo de procesamiento (tiempo y recursos computacionales) y dificulta o torna imposible la trazabilidad del documento digitalizado de extremo a extremo. No parece haber ningún supuesto razonable para efectuar este proceso, puesto que los archivos podrían tratarse desde el origen en formato PDF, que es soportado en modo directo por las impresoras multifunción Hewlett Packard LaserJet Pro M426fdw que se utilizarán en el sistema. La lógica de diseño de un sistema moderno debería incorporar además un mecanismo de autenticidad e integridad de cada documento transmitido, implementado idealmente con base en firma digital de la autoridad de mesa. Aún en el caso en que la conversión fuese indispensable por razones no obvias, se debería utilizar una herramienta de conversión desarrollada utilizando prácticas recomendadas de seguridad del software, por ejemplo usando un lenguaje de programación fuertemente tipado y con uso seguro de memoria, y probado exhaustivamente de manera automatizada y por revisión de código fuente.

Como referencia comparativa, puede tomarse como ejemplo el sistema desarrollado por el gobierno de la Provincia de Santa Fe y utilizado en las últimas elecciones provinciales, que permite implementar medidas de conservación de integridad y resuelve la transmisión desde los establecimientos de votación a los centros de cómputo a una fracción del costo del implementado por Correo Argentino.

Debe notarse que resulta imposible conocer la cantidad e impacto de otras vulnerabilidades en el sistema si no se llevan a cabo una o más auditorías de seguridad exhaustivas, de extremo a extremo, del sistema completo. La práctica de «seguridad por oscuridad» es desaconsejable en cualquier sistema crítico porque, como se ha visto en este caso, aún pequeños indicios pueden proporcionar pistas para potenciales vectores de ataque, y porque las características detalladas del sistema estarán siempre disponibles para un número significativo de potenciales adversarios internos. Por otra parte, el carácter crítico y eminentemente público de un sistema electoral se contradice abiertamente con estrategias de ocultamiento; en este sentido lo considera también la ley vigente (artículo 108 del Código Electoral Nacional, conforme a la ley 24.444^[6] y la Acordada Extraordinaria 3/2017 de la Cámara Nacional Electoral^[7]).

Mitigación

La medida más inmediata para mitigar el problema es instalar la versión más actualizada de libtiff, 4.0.10 (20181110). No obstante, debe tenerse en cuenta que podrían existir otras vulnerabilidades no reportadas o aún bajo investigación,^[8] por lo que la conversión de archivos debería realizarse en un entorno de ejecución controlado y restringido utilizando, por ejemplo, microvirtualización y contenedores.

Notificaciones

A diferencia de la práctica habitual, este aviso de vulnerabilidad no es publicado en modo de «difusión coordinada» con previo aviso a los responsables del sistema afectado. Ello, por dos razones:

• Los componentes informáticos del sistema electoral son una pieza clave en la transparencia de las elecciones, un proceso fundamental del estado de derecho y cuestión de interés público general; y
• El sistema no se halla actualmente en funcionamiento, por lo que no hay riesgo de que las potenciales vulnerabilidades sean explotadas inmediatamente al conocerse este aviso. El conocimiento público de este defecto contribuirá a que las medidas de mitigación sean ejecutadas en tiempo y forma para que las elecciones primarias, abiertas, simultáneas y obligatorias del próximo 11 de agosto puedan ser llevadas a cabo con normalidad, y a que todas las partes interesadas tengan la posibilidad de verificar la efectividad de dichas medidas.

En simultaneidad con la publicación de este aviso, se ha dado noticia por correo electrónico a:

• Dirección Nacional Electoral, <elecciones@elecciones.gob.ar>
  Director Nacional Electoral, Rodrigo Conte Grand <rconte@mininterior.gob.ar>
  Director de Procesos Electorales, Claudio Luján <claudiolujan@elecciones.gob.ar>
• Cámara Nacional Electoral,
  Alejandra Lazzaro, Secretaria de Cámara <alejandra.lazzaro@pjn.gov.ar>
• Secretaría de Gobierno de Modernización, Infraestructuras Críticas de Información y Ciberseguridad
  ICIC-CERT, <cert@icic.gob.ar>

No ha sido posible comunicar este texto al Correo Argentino debido a que su Dirección Electoral no ha hecho pública su dirección de correo electrónico.

Agradecimiento

Cristian Riccomagno, periodista de Perfil, quien fue el primero en publicar el ejemplar en que detectamos el problema y luego nos suministró los restantes archivos para corroboración.

Notas y referencias

[1] https://www.perfil.com/noticias/equipo-de-investigacion/el-simulacro-del-escrutinio-provisorio-sembro-mas-dudas-sobre-el-software-de-smartmatic.phtml

[2] Se encuentran disponibles para verificación como un archivo en formato .zip en https://archive.org/download/telegramas-simulacro/telegramas.zip. El hash SHA-256 del archivo .zip es 32f19ad530879da625d64d5c0c5204a30a42fa3f8b45cd2ace5cb56e73c9fe66.

[3] Como detalle adicional, es de notar que los datos de fecha de creación (/CreationDate) y de última modificación (/ModDate) en todos los archivos que inspeccionamos corresponden al 13 de julio de 2019 entre las 14:35:51 y las 14:38:15 UTC, una semana antes de la realización del simulacro en el que presuntamente se recibieron. Estos datos pueden comprobarse, por ejemplo, ejecutando el comando 'pdfinfo' en GNU/Linux sobre los archivos consignados en la nota [2].

[4] https://www.cvedetails.com/vulnerability-list/vendor_id-2224/product_id-3881/version_id-193339/Libtiff-Libtiff-4.0.6.html

[5] La posible extensión de estos ataques a otros servidores que formen parte de la red implementada por Correo Argentino no ha podido ser determinada a raíz de la ausencia de información pública a la que nos referimos en la sección «Análisis».

[6] http://servicios.infoleg.gob.ar/infolegInternet/anexos/15000-19999/19442/texact.htm

[7] https://www.pjn.gov.ar/cne/documentos/2017%20AE%20003-17%20(ESCRUTINIO%20PROVISORIO).pdf

[8] Ver los defectos con severidad «blo» (blocker) y «cri» (critical) en http://bugzilla.maptools.org/buglist.cgi?product=libtiff

Anexo 1

1. Salida del comando 'qpdf':

$ qpdf --show-object=2 6200100008X.pdf
<< /CreationDate (D:20190713143803) /ModDate (D:20190713143803)
/Producer (libtiff / tiff2pdf - 20150912) >>

2. Salida del comando 'xxd' mostrando los primeros 224 bytes del archivo:

$ xxd 6200100008X.pdf

0000000: 2550 4446 2d31 2e32 200a 25e2 e3cf d30a  %PDF-1.2 .%.....
0000010: 3120 3020 6f62 6a0a 3c3c 200a 2f54 7970  1 0 obj.<< ./Typ
0000020: 6520 2f43 6174 616c 6f67 200a 2f50 6167  e /Catalog ./Pag
0000030: 6573 2033 2030 2052 200a 3e3e 0a65 6e64  es 3 0 R .>>.end
0000040: 6f62 6a0a 3220 3020 6f62 6a0a 3c3c 200a  obj.2 0 obj.<< .
0000050: 2f43 7265 6174 696f 6e44 6174 6520 2844  /CreationDate (D
0000060: 3a32 3031 3930 3731 3331 3433 3830 3329  :20190713143803)
0000070: 0a2f 4d6f 6444 6174 6520 2844 3a32 3031  ./ModDate (D:201
0000080: 3930 3731 3331 3433 3830 3329 0a2f 5072  90713143803)./Pr
0000090: 6f64 7563 6572 2028 6c69 6274 6966 6620  oducer (libtiff 
00000a0: 2f20 7469 6666 3270 6466 202d 2032 3031  / tiff2pdf - 201
00000b0: 3530 3931 3229 0a3e 3e20 0a65 6e64 6f62  50912).>>.endob
00000c0: 6a0a 3320 3020 6f62 6a0a 3c3c 200a 2f54  j.3 0 obj.<< ./T
00000d0: 7970 6520 2f50 6167 6573 200a 2f4b 6964  ype /Pages ./Kid

3. Salida del comando 'pdfinfo'

$ pdfinfo 6200100008X.pdf
Producer:       libtiff / tiff2pdf - 20150912
CreationDate:   Sat Jul 13 14:38:03 2019
ModDate:        Sat Jul 13 14:38:03 2019
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      612 x 936 pts
Page rot:       0
File size:      290701 bytes
Optimized:      no
PDF version:    1.2

Anexo 2

ID: CVE-2016-5652
Type: Exec Code Overflow
Date: 2017-01-06
Score: 6.8
Description: An exploitable heap-based buffer overflow exists in the handling of TIFF images in LibTIFF’s TIFF2PDF tool. A crafted TIFF document can lead to a heap-based bufferoverflow resulting in remote code execution. Vulnerability can be triggered via a saved TIFF file delivered by other means.

ID: CVE-2016-8331
Type: Exec Code
Date: 2016-10-28
Score: 6.8
Description: An exploitable remote code execution vulnerability exists in the handling of TIFF images in LibTIFF version 4.0.6. A crafted TIFF document can lead to a type confusionvulnerability resulting in remote code execution. This vulnerability can be triggered via a TIFF file delivered to the application using LibTIFF’s tag extension functionality.

ID: CVE-2018-17795
Type: DoS Overflow
Date: 2018-09-30
Score: 6.8
Description: The function t2p_write_pdf in tiff2pdf.c in LibTIFF 4.0.9 allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted TIFF file, a similar issue to CVE-2017-9935.

ID: CVE-2018-16335
Type: DoS Overflow 2018-09-01
Score: 6.8
Description: newoffsets handling in ChopUpSingleUncompressedStrip in tif_dirread.c in LibTIFF 4.0.9 allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted TIFF file, as demonstrated by tiff2pdf. This is a different vulnerability than CVE-2018-15209.

ID: CVE-2018-15209
Type: DoS Overflow 2018-08-08
Score: 6.8
Description: ChopUpSingleUncompressedStrip in tif_dirread.c in LibTIFF 4.0.9 allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted TIFF file, as demonstrated by tiff2pdf.

ID: CVE-2018-12900
Type: DoS Overflow 2018-06-26
Score: 6.8
Description: Heap-based buffer overflow in the cpSeparateBufToContigBuf function in tiffcp.c in LibTIFF 4.0.9 allows remote attackers to cause a denial of service (crash) or possibly have unspecified other impact via a crafted TIFF file.

ID: CVE-2015-7554
Type: DoS
Date: 2016-01-08
Score: 7.5
Description: The _TIFFVGetField function in tif_dir.c in libtiff 4.0.6 allows attackers to cause a denial of service (invalid memory write and crash) or possibly have unspecified other impact via crafted field data in an extension tag in a TIFF image.

ID: CVE-2016-9533
Type: Overflow
Date: 2016-11-22
Score: 7.5
Description: tif_pixarlog.c in libtiff 4.0.6 has out-of-bounds write vulnerabilities in heap allocated buffers. Reported as MSVR 35094, aka «PixarLog horizontalDifference heap-buffer-overflow.»

ID: CVE-2016-9534
Type: Overflow
Date: 2016-11-22
Score: 7.5
Description: tif_write.c in libtiff 4.0.6 has an issue in the error code path of TIFFFlushData1() that didn’t reset the tif_rawcc and tif_rawcp members. Reported as MSVR 35095, aka «TIFFFlushData1 heap-buffer-overflow.»

ID: CVE-2016-9535
Type: Overflow
Date: 2016-11-22
Score: 7.5
Description: tif_predict.h and tif_predict.c in libtiff 4.0.6 have assertions that can lead to assertion failures in debug mode, or buffer overflows in release mode, when dealing with unusual tile size like YCbCr with subsampling. Reported as MSVR 35105, aka «Predictor heap-buffer-overflow.»

ID: CVE-2016-9537
Date: 2016-11-22
Score: 7.5
Description: tools/tiffcrop.c in libtiff 4.0.6 has out-of-bounds write vulnerabilities in buffers. Reported as MSVR 35093, MSVR 35096, and MSVR 35097.

ID: CVE-2016-9538
Type: Overflow
Date: 2016-11-22
Score: 7.5
Description: tools/tiffcrop.c in libtiff 4.0.6 reads an undefined buffer in readContigStripsIntoBuffer() because of a uint16 integer overflow. Reported as MSVR 35100.

ID: CVE-2016-9539
Date: 2016-11-22
Score: 7.5
Description: tools/tiffcrop.c in libtiff 4.0.6 has an out-of-bounds read in readContigTilesIntoBuffer(). Reported as MSVR 35092.

ID: CVE-2016-3991
Type: DoS Exec Code Overflow
Date: 2016-09-21
Score: 6.8
Description: Heap-based buffer overflow in the loadImage function in the tiffcrop tool in LibTIFF 4.0.6 and earlier allows remote attackers to causea denial of service (out-of-bounds write) or execute arbitrary code via a crafted TIFF image with zero tiles.

ID: CVE-2016-9540
Type: Overflow
Date: 2016-11-22
Score: 7.5
Description: tools/tiffcp.c in libtiff 4.0.6 has an out-of-bounds write on tiled images with odd tile width versus image width. Reported as MSVR 35103, aka «cpStripToTile heap-buffer-overflow.»

ID: CVE-2016-3632
Type: DoS Exec Code
Date: 2016-09-21
Score: 6.8
Description: The _TIFFVGetField function in tif_dirinfo.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds write) or execute arbitrary code via a crafted TIFF image.

ID: CVE-2016-3990
Type: DoS Exec Code Overflow
Date: 2016-09-21
Score: 6.8
Description: Heap-based buffer overflow in the horizontalDifference8 function in tif_pixarlog.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted TIFF image to tiffcp.

ID: CVE-2016-5314
Type: DoS Overflow
Date: 2018-03-11
Score: 6.8
Description: Buffer overflow in the PixarLogDecode function in tif_pixarlog.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted TIFF image, as demonstrated by overwriting the vgetparent function pointer with rgb2ycbcr.

ID: CVE-2016-6223
Type: DoS +Info
Date: 2017-01-23
Score: 6.4
Description: The TIFFReadRawStrip1 and TIFFReadRawTile1 functions in tif_read.c in libtiff before 4.0.7 allows remote attackers to cause a denial of service (crash) or possibly obtain sensitive information via a negative index in a file-content buffer.

ID: CVE-2016-3631
Type: DoS
Date: 2016-10-03
Score: 5.0
Description: The (1) cpStrips and (2) cpTiles functions in the thumbnail tool in LibTIFF 4.0.6 and earlier allow remote attackers to cause a denial of service (out-of-bounds read) via vectors related to the bytecounts[] array variable.

ID: CVE-2016-3633
Type: DoS
Date: 2016-10-03
Score: 5.0
Description: The setrow function in the thumbnail tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via vectors related to the src variable.

ID: CVE-2016-3634
Type: DoS
Date: 2016-10-03
Score: 5.0
Description: The tagCompare function in tif_dirinfo.c in the thumbnail tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via vectors related to field_tag matching.

ID: CVE-2016-3658
Type: DoS
Date: 2016-10-03
Score: 5.0
Description: The TIFFWriteDirectoryTagLongLong8Array function in tif_dirwrite.c in the tiffset tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via vectors involving the ma variable.

ID: CVE-2016-5323
Type: DoS
Date: 2017-01-20
Score: 5.0
Description: The _TIFFFax3fillruns function in libtiff before 4.0.6 allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted Tiff image.

ID: CVE-2016-9297
Type: DoS
Date: 2017-01-18
Score: 5.0
Description: The TIFFFetchNormalTag function in LibTiff 4.0.6 allows remote attackers to cause a denial of service (out-of-bounds read) via crafted TIFF_SETGET_C16ASCII or TIFF_SETGET_C32_ASCII tag values.

ID: CVE-2016-9448
Type: DoS
Date: 2017-01-27
Score: 5.0
Description: The TIFFFetchNormalTag function in LibTiff 4.0.6 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) by setting the tags TIFF_SETGET_C16ASCII or TIFF_SETGET_C32_ASCII to values that access 0-byte arrays. NOTE: this vulnerability exists because of an incomplete fix for CVE-2016-9297.

ID: CVE-2015-1547
Type: DoS Overflow
Date: 2016-04-13
Score: 4.3
Description: The NeXTDecode function in tif_next.c in LibTIFF allows remote attackers to cause a denial of service (uninitialized memory access) via a crafted TIFF image, as demonstrated by libtiff5.tif.

ID: CVE-2015-8665
Type: DoS Overflow
Date: 2016-04-13
Score: 4.3
Description: tif_getimage.c in LibTIFF 4.0.6 allows remote attackers to cause a denial of service (out-of-bounds read) via the SamplesPerPixel tag in a TIFF image.

ID: CVE-2015-8683
Type: DoS Overflow
Date: 2016-04-13
Score: 4.3
Description: The putcontig8bitCIELab function in tif_getimage.c in LibTIFF 4.0.6 allows remote attackers to cause a denial of service (out-of-bounds read) via a packed TIFF image.

ID: CVE-2016-3625
Type: DoS
Date: 2016-10-03
Score: 4.3
Description: tif_read.c in the tiff2bw tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted TIFF image.

ID: CVE-2016-5315
Type: DoS
Date: 2017-03-07
Score: 4.3
Description: The setByteArray function in tif_dir.c in libtiff 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted tiff image.

ID: CVE-2016-5317
Type: DoS Overflow
Date: 2017-01-20
Score: 4.3
Description: Buffer overflow in the PixarLogDecode function in libtiff.so in the PixarLogDecode function in libtiff 4.0.6 and earlier, as used in GNOME nautilus, allows attackers to cause a denial of service attack (crash) via a crafted TIFF file.

ID: CVE-2016-5318
Type: Overflow
Date: 2017-01-20
Score: 4.3
Description: Stack-based buffer overflow in the _TIFFVGetField function in libtiff 4.0.6 and earlier allows remote attackers to crash the application via a crafted tiff.

ID: CVE-2016-5321
Type: DoS Overflow
Date: 2017-01-20
Score: 4.3
Description: The DumpModeDecode function in libtiff 4.0.6 and earlier allows attackers to cause a denial of service (invalid read and crash) via a crafted tiff image.

ID: CVE-2016-5322
Type: DoS
Date: 2017-04-11
Score: 4.3
Description: The setByteArray function in tif_dir.c in libtiff 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted tiff image.

ID: CVE-2016-9273
Type: DoS
Date: 2017-01-18
Score: 4.3
Description: tiffsplit in libtiff 4.0.6 allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted file, related to changing td_nstrips in TIFF_STRIPCHOP mode.

ID: CVE-2016-9532
Type: DoS Overflow
Date: 2017-02-06
Score: 4.3
Description: Integer overflow in the writeBufferToSeparateStrips function in tiffcrop.c in LibTIFF before 4.0.7 allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted tif file.

ID: CVE-2016-10371
Type: DoS
Date: 2017-05-10
Score: 4.3
Description: The TIFFWriteDirectoryTagCheckedRational function in tif_dirwrite.c in LibTIFF 4.0.6 allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted TIFF file.

Filtraciones de información como Wikileaks y Panama Papers, ataques al sistema electoral de los EE.UU., secuestros de información por ransomware, hackeos a las fuerzas de seguridad de la Argentina, robo de cuentas de email y redes sociales. La lista de noticias relacionadas con la seguridad informática crece a diario. Así como la informática atraviesa cada vez más aspectos de nuestra vida y quehaceres, la vulneración de sistemas informáticos tiene cada día mayor impacto. Y así como la informática es una disciplina científica joven, más aún lo es la seguridad informática.

Desde individuos hasta gobiernos, pasando por organizaciones de diverso tipo y tamaño, todos pueden ser eventualmente víctimas de ataques. Cómo protegerse es un problema al que el mundo presta cada día más atención. Desde fabricantes de dispositivos informáticos hasta los brazos armados de los Estados destinan cada día mayor presupuesto y esfuerzo a resolver esta problemática.

La situación en nuestro país es tan variada como en el resto del mundo, incluso cuando la Argentina destaca por el nivel y la cantidad de profesionales dedicados a la materia. Tomemos como ejemplo el penúltimo gran ataque con ransomware: Wannacry. Este tuvo un gran impacto mundial, aún cuando se basaba en un problema de seguridad que había sido solucionado más de un mes atrás. Pero la situación en el país fue bastante heterogénea, ya que ciertas organizaciones tuvieron que realizar un «apagón informático», en tanto que otras no tuvieron inconveniente alguno.

El panorama en la Argentina es mejor en el ámbito privado, ya que las empresas de mayor envergadura acostumbran contratar auditorías externas para controlar el estado de la seguridad de sus sistemas y procesos. En el Estado, lamentablemente, esta no es una práctica generalizada; y aunque en algunas áreas puntuales haya equipos de profesionales capacitados, en otras hay un completo abandono en la materia. En los últimos meses hemos sido testigos de esto a la luz de los hackeos del Ministerio de Seguridad, la Policía de Seguridad Aeroportuaria y la Policía Federal Argentina.

La seguridad no es un producto, sino un proceso. No basta la adquisición de equipamiento (hardware) y de programas (software), ni siquiera la correcta implantación de éstos en el ámbito organizacional. Para mantener un nivel de seguridad adecuado es necesaria además una permanente revisión y actualización de las políticas y los procedimientos. Las técnicas de ataque a sistemas informáticos evolucionan a la par de éstos, por lo que la actualización de las defensas debe seguir el mismo ritmo.

A diario crece la utilización de dispositivos informáticos para controlar dispositivos físicos. Los automóviles modernos, los electrodomésticos, las redes de distribución de energía e incluso dispositivos médicos como marcapasos o bombas de insulina se basan cada vez más en sistemas informáticos. Esto hace que la posibilidad de ataques con «bits» tenga cada vez mayor repercusión en el mundo real y tangible. Por ello la ciberdefensa se ha convertido hoy en el cuarto brazo armado de los Estados más importantes del mundo.

Hace unos días, y desoyendo la voz de especialistas, la Legislatura de Córdoba aprobó una ley que ordena el uso de voto electrónico en las elecciones provinciales. Amén de implementar un sistema más que cuestionado, la norma pone en manos del CPCIPC la fiscalización (limitando la posibilidad de ser fiscal informático partidario a quienes estén matriculados) y seguramente sea también el CPCIPC quien asuma el rol principal en la realización de las auditorías del sistema informático a utilizar.

Lo que sigue es un ejemplo más del lamentable nivel de los informáticos nucleados en el CPCIPC.

El sitio web del CPCIPC

El programador Federico Heinz (que hace unos días publicó una excelente nota sobre el tema) hizo notar en Twitter que el sitio del CPCIPC tenía un ridículo sistema de autenticación para el acceso de los matriculados:

En https://t.co/i4jSOkpZqH el login requiere dos datos: # matrícula y DNI. Adiviná que hay en https://t.co/eeyuWAuVp6? #NoDanMasDeInútiles

— Fede Heinz (@fheinz) 9 de enero de 2017

No pasó mucho tiempo hasta que algunos tuiteros comenzaron a ingresar al sistema usando los números de matrícula de las autoridades del CPCIPC (publicados en el mismo sitio) y su DNI (dato fácilmente obtenible si se tiene el nombre completo de la persona).

@fheinz @mis2centavos Ya estoy logueado como el presidente. Me estoy tentando de hacer alguna maldad, muejejeje pic.twitter.com/WdqhBvVqdt

— Elvira de Musicardi (@pitersoap) 10 de enero de 2017

@pitersoap @mis2centavos POR FAVOR NO ENTREN. La seguridad es patética, pero no es razón para violarla.

— Fede Heinz (@fheinz) 10 de enero 2017

De nada sirvió el pedido de Federico Heinz, para algunos la tentación fue muy grande:

@mis2centavos jajajaja quien fue!? :P pic.twitter.com/HaZDAe4vVv

— Maxi Biscardi (@MaxiBiscardi) 10 de enero de 2017

Alguien más encontró un error todavía más grosero: en el sitio del CPCIPC había un script que permitía descargar cualquier archivo del sistema que fuese accesible por el servidor web:

@fheinz https://t.co/TlTh0J7ben y acá te dejan descargarte lo que quieras.

— Gonza Cabrera (@_gonzacabrera) 10 de enero de 2017

Este es el código del script «downloader.php» que se encontraba en el servidor:

(Clic para ampliar)

¿Cómo es que los sesudos profesionales del CPCIPC cometieron este error digno de un principiante? Fácil: copiando y pegando código de la documentación de PHP:

Pero evidentemente, los errores en el sitio del CPCIPC no se agotaban. Unos minutos después, ya alguien había modificado el contenido (reemplazando las fotos de las autoridades por la del dueño de la empresa MSA Sergio Angelini, vendedora de voto electrónico):

@mis2centavos Bue, se fueron al carajo.

Este es el actual estado de https://t.co/hHjsear4L9 pic.twitter.com/G7OCSFN4FZ

— Luciano Bello (@microluciano) 10 de enero de 2017

Más tarde, el sitio del CPCIPC ya estaba completamente «defaceado«:

Hoy por la mañana, parece que ya estaban solucionando los problemas (o al menos algunos de ellos):

Lo instalamos entre todos? pic.twitter.com/CZXHyB9UUy

— mdl (@MadlySeason) 10 de enero de 2017

Solución de los guardianes monopólicos de la seguridad informática: eliminar la posibilidad de que los usuarios/colegiados se logueen pic.twitter.com/5bjVKSH850

— Delia Ferreira (@DeliaFerreira) 10 de enero de 2017

¿Algo más? Sí. Como era de esperar, y para completar la vergüenza, el servidor del CPCIPC ya había sido crackeado con anterioridad, por alguien que lo infectó con software que lo convierte en parte de un red de máquinas esclavas (botnet):

@cpcipc buenas muchachos, se les metió una porquería en el webserver vaya uno a saber hace cuanto https://t.co/JSPG4br5LY

/lib/libudev.so

— mega (@iglosiggio) 10 de enero de 2017

@cpcipc de paso miren el crontab

— mega (@iglosiggio) 10 de enero de 2017

(Si, el servidor del CPCIPC podría ser usado por terceros para realizar ataques distribuidos de denegación de servicio. En definitiva, quienes lo descubrieron les hicieron un favor).

Conclusión

Esta es la gente que amenaza con denunciarme por «ejercicio ilegal de la informática» por presentarme en el Congreso de la Nación como programador y especialista en informática:

Es la gente que «tutela el ejercicio de la profesión» y realiza inspecciones en la Provincia de Córdoba para determinar quién puede trabajar en informática y quién no:

También es la gente que se dedica a promocionar el sistema de voto electrónico de la empresa MSA y se ofrece a auditarlo en las elecciones:

Y es la gente que, gracias a la nueva ley provincial, tendrá el monopolio de la fiscalización electrónica en las votaciones por venir.

Gente que no puede implementar razonablemente un sistema de usuario y contraseña para autenticar a sus matriculados. Gente que no puede escribir una aplicación siguiendo los lineamientos básicos de seguridad. Gente que no puede ni siquiera mantener un servidor web sin transformarse en el hazmerreír de los programadores del resto del país. Ese es el Consejo Profesional de Ciencias (o «Carencias«) Informáticas de la Provincia de Córdoba.

Río Cuarto, 27 de mayo de 2012

Sra. Presidente de la Nación Argentina
Dra. Cristina Fernández de Kirchner:

Con mucho pesar he leído la noticia, publicada y destacada en el sitio web de la Presidencia, de su reciente reunión en la Residencia de Olivos junto con los ministros Giorgi, De Vido y Barañao, con el Director General de Operaciones de Microsoft, Brian Turner.

En dicha reunión, el Gerente de Microsoft le presentó a Usted el llamado «Plan de Desarrollo Sustentable» de dicha compañía para la Argentina. El punto clave —según mi opinión— es definir qué se entiende por «desarrollo sustentable» y, particularmente, sobre el «desarrollo» de quién estamos hablando. El que un gerente de una empresa transnacional —que, dicho sea de paso, realiza escasas inversiones en la Argentina— sea recibido nada menos que por la Presidente y tres ministros, sumando a esto el lugar destacado que ocupa la noticia en el sitio web oficial, me dan la pauta de que Usted considera que Microsoft realmente es un actor importante para el desarrollo de nuestro país.

En Internet he encontrado declaraciones públicas suyas que confirman mis conjeturas sobre su valoración respecto del rol de Microsoft en el desarrollo local. Por esta razón he decidido escribir esta carta abierta, con el objetivo de ponerla sobre aviso de algunas cuestiones en las que —considero— está Usted equivocada.

En el Microsoft Research Faculty Summit, realizado el 13 de mayo de 2009 en Buenos Aires, dijo Usted lo siguiente:

[…] Y que también nos une con quien es el fundador de esta empresa —con Bill Gates— que siempre imaginó un mundo donde el conocimiento estuviera siempre al servicio del progreso, de la producción, del trabajo y de mejorar la calidad de vida de la gente; no porque fuera más vivo —para poder realizar una maniobra de especulación— sino porque realmente adquiriera el conocimiento para poder hacer valer ese conocimiento en términos económicos.

Este es, quizás, el origen de su apreciación errónea sobre Microsoft. Por lo dicho, considera Usted a Bill Gates como un filántropo, como alguien interesado en el progreso del mundo y como quien avisoró la importancia del conocimiento en esta nueva era. Humildemente, le sugiero que investigue un poco mejor y sin duda encontrará muchas otras personas —aunque dificilmente alguna de ellas sea multimillonaria— que han sido verdaderas visionarias y que han realizado enormes contribuciones al avance del conocimiento y la informática. Gates, por el contrario, solamente ha sido un gran comerciante y —como le mostraré más adelante— no siempre se ha valido de las prácticas más transparentes ni éticas para lograr su enorme fortuna.

En la inauguración de las instalaciones de Google Argentina, el 6 de junio de 2008, dijo Usted que:

El desafío que nos plantea la Red y todas las empresas vinculadas como Google a esto, es la de una nueva ética, hasta en la generación de la riqueza. ¿Por qué? Porque siempre la generación de la riqueza estuvo ligada —desde los comienzos de la humanidad— a quién tenía algo maś que el otro; el que tenía más oro, más tierras, el que las conquistaba, siempre significaba que alguien que era más rico era porque desapoderaba a otro de algo (de territorio, de riquezas, de posesiones). Por primera vez, a fines [principios] del siglo XXI, un hombre es el más rico del mundo porque tuvo más inteligencia y más conocimiento, que es el caso por ejemplo de Bill Gates.

Esto plantea en términos de ética, de conocimiento, de información, pero fundamentalmente de generación de riqueza —que es lo que nos debe preocupar a nosotros como generadores de puestos de trabajo— una ética diferente. Ya no hace falta desapoderar a alguien, ya no hace falta conquistarlo militarmente o económicamente sacarle sus recursos para generar riqueza. Es a partir de la inteligencia, del conocimiento, de cabezas importantes —como me gusta decirlo a mi— que podemos generar riqueza, trabajo, conocimiento, información y democratización.

Permítame comentarle un poco acerca de la «ética» de Bill Gates y su empresa en los negocios. Para comenzar, creo que olvida Usted las múltiples demandas que han sido presentadas contra Microsoft —y, en general, resueltas en su contra— en distintos países del mundo por prácticas desleales, monopólicas y por abuso de posición dominante. Lamento decirle que Bill Gates ha acumulado su riqueza de un modo similar a las formas que Usted enumera: apropiándose de algo que estaba en poder de otros. Principalmente, Gates se apropió de dos cosas:

• Ideas: No encontrará —sobre todo en los primeros quince años de existencia de Microsoft— ninguna idea «original». Esto es, ningún aporte técnico real al avance de la informática (o del conocimiento, si prefiere) por parte de esta empresa y mucho menos de Bill Gates, cuyo aporte como programador es completamente nulo. Gates fue un excelente apropiador (y vendedor) de ideas de otros. Esto le ha valido varias de las demandas antedichas.
• Libertad: El primer negocio importante de Microsoft fue un trato con IBM para nada conveniente para este último —se sospecha—, influido por la relación entre el por entonces CEO de IBM, John Opel, y la madre de Gates, Mary Maxwell. Sin embargo, la apropiación de la libertad más importante —y más rentable— ha sido la de los usuarios de los programas de Microsoft. Es un hecho ampliamente conocido que esta empresa siempre se ha caracterizado por realizar todo tipo de maniobras para, primero, imponer el uso de sus programas y, luego, dificultar o imposibilitar a sus usuarios el usar herramientas de otros proveedores. Nuevamente, me remito a los múltiples juicios en contra de Microsoft por este tipo de prácticas.

En definitiva, el éxito de Bill Gates y de su empresa puede resumirse de la siguiente manera: inicialmente, tomar conocimiento de otros; construir (o comprar) software de calidad apenas aceptable; a través de políticas agresivas y de maniobras no muy transparentes, lograr la colocación de dicho software en el mercado; finalmente, una vez establecidos sus productos, tratar de dificultar por todos los medios posibles a sus usuarios el migrar a productos de la competencia (o, incluso, atacar a directamente a ésta para eliminarla). No tiene por qué creerme, pero le pido por favor que indague un poco más al respecto con la promesa de que encontrará gran cantidad de evidencia.

En el ya citado Microsoft Research Faculty Summit de 2009, Usted también se pronunció respecto de la «Agenda Digital» argentina:

La Agenda Digital no se construye desde el Estado. La Agenda Digital es impulsada desde el Estado, pero se construye con funcionarios y con las empresas privadas; con el sector privado articulando con el sector público para poder potenciar las inversiones de cada empresa —y también las inversiones que hace el propio Estado— para achicar la brecha digital, en lo que yo denomino —y reitero— como la segunda alfabetización.

Comete Usted —nuevamente, según mi opinión— un grave error. La «Agenda Digital» —esto es, las estrategias a seguir por la Argentina a fin de maximizar el beneficio de las tecnologías informáticas y salvar la llamada «brecha digital»— no puede dejarse siquiera influir por empresas transnacionales. De la misma manera en que —supongo— no se permite que los laboratorios farmacológicos influyan en las políticas de salud, o que las editoriales de libros tengan demasiada injerencia en las políticas educativas; me tomo el atrevimiento de recomendarle que no preste demasiada atención a las aparentemente beneficiosas propuestas de empresas como Microsoft. Nuevamente, en referencia a la reunión que motivó esta carta, lo que ellos llaman «desarrollo sustentable» se refiere exclusivamente al desarrollo y la sustentabilidad de su negocio, no de nuestro país y, menos que menos, de nosotros sus pobladores. A Microsoft —como a tantos otros— no le interesa la «alfabetización digital» de los argentinos, sino solamente que utilicemos sus productos.

Le pido nuevamente que por favor se asesore sobre este tema. Se que entre los militantes de su partido hay varias personas que comparten las ideas que he expresado en este texto. Varios de ellos, reunidos bajo el eslogan «Software Libre con CFK», también le han escrito una carta abierta, con la cual coincido en términos generales.

Como referencias puntuales y particularmente relevantes, le sugiero indague sobre el incidente ocurrido en Venezuela cuando Microsoft entregó a la embajada de los EE.UU. documentos de la empresa PDVSA. También puede consultar al Dr. Hugo Scolnik (creador del Departamento de Computación de la UBA) sobre la relación entre Microsoft y la Agencia Nacional de Seguridad de los EE.UU. (NSA). Y luego, por favor, ponga estos hechos a la par de la decisión del Ministerio de Defensa, en el año 2010, de utilizar productos de Microsoft en toda la plataforma de comunicaciones de las Fuerzas Armadas.

También me permito sugerirle la lectura de un artículo de mi autoría —escrito hace ya nueve años— en el que podrá encontrar más información sobre Bill Gates, los comienzos de Microsoft y la construcción de su fortuna. (Las referencias citadas son mucho más valiosas que el texto propiamente dicho).

Es mi deseo que esta modesta carta contribuya a que revea su opinión sobre el rol de Bill Gates en el desarrollo de la informática y el conocimiento, pero fundamentalmente con respecto a la participación que Microsoft deba tener en la definición de la agenda digital y otras decisiones estratégicas de nuestro país.

Quedando a su disposición, me despido de Usted agradeciéndole el tiempo dedicado a la lectura de esta carta y saludándole muy atentamente.

Javier Smaldone

Adenda (20 de febrero de 2013)

Hoy, con mucho pesar, he recibido la siguiente noticia:

La empresa internacional Microsoft, que provee el software a las computadoras de este plan [Conectar Igualdad], estima un crecimiento por encima del 20% en la Argentina durante 2013.

Microsoft sigue avanzando en la Argentina, estimando un crecimiento de nada menos que un 20% en un solo año. Y esto es anunciado por una agencia de noticias gubernamental como un gran avance.

El uso de software bajo condiciones de licenciamiento restrictivas (como las del llamado software privativo) es inaceptable en un estado democrático y republicano. A continuación, el por qué.

Razones por las que el Estado debe usar software libre

Resumen

Existen dos modos predominantes de licenciamiento de software: el libre y el privativo. El libre es aquel que respeta el derecho del usuario de usar, distribuir y modificar los programas. El privativo es aquel que restringe los derechos del usuario al mero uso de la funcionalidad del programa, bajo condiciones determinadas al solo criterio del dueño de los derechos de autor. Los derechos otorgados al usuario bajo una licencia privativa son insuficientes para las necesidades operativas del Estado. El software libre ofrece ventajas de índole económica, social, operativa y de seguridad nacional que hacen imperativo su uso en forma exclusiva en todas las áreas de la administración pública.

Software libre y software privativo

El software, como mercadería, por lo general no está a la venta. Lo que el usuario adquiere, a través de una erogación monetaria o sin ella, es una licencia respecto de los usos que puede dar a los programas en cuestión. Nótese que esto es a diferencia de, por ejemplo, un libro o un disco, mercaderías en las que el cliente adquiere título real sobre algo que puede prestar, regalar, revender, citar, alquilar, resumir, etc.: al «comprar un programa», el usuario por regla general no adquiere derecho de propiedad alguno, en muchos casos ni siquiera pasa a ser propietario del medio magnético u óptico en el que el sofware es entregado, que continúa siendo propiedad del autor original.

La licencia de uso de un programa en particular regula las maneras en las que el usuario puede utilizarlo. Si bien la variedad de tipos de licencia abarca todo el rango de posibilidades, desde las condiciones más leoninas hasta las más liberales, se las puede clasificar en dos grandes categorías: por un lado están las licencias conocidas como «libres», y por otro las «privativas». La gran diferencia entre estos tipos de licencia consiste en que un software licenciado de modo privativo por lo general otorga al usuario solamente el derecho de ejecutar el programa «tal como es» (es decir, con errores incluídos) en determinada computadora, prohibiendo expresamente todo otro uso, mientras que el software gobernado por una licencia libre permite al usuario no solo ejecutar el programa en tantas computadoras como desee, sino también copiarlo, inspeccionarlo, modificarlo, mejorarlo, corregir errores y distribuirlo, o contratar a alguien para que lo haga por él.

Estos derechos adicionales son herramientas clave e indispensables de todo software que vaya a ser usado en el entorno de la administración pública.

El software y la Seguridad Nacional

Para cumplir con sus funciones, el Estado debe almacenar y procesar información relativa a los ciudadanos. La relación entre el individuo y el Estado depende de la privacidad e integridad de estos datos, que por consiguiente deben ser adecuadamente resguardados contra tres riesgos específicos:

• Riesgo de filtración: los datos confidenciales deben ser tratados de tal manera que el acceso a ellos sea posible exclusivamente para las personas e instituciones autorizadas.
• Riesgo de imposibilidad de Acceso: los datos deben ser almacenados de tal forma que el acceso a ellos por parte de las personas e instituciones autorizadas esté garantizado durante toda la vida útil de la información.
• Riesgo de manipulación: la modificación de los datos debe estar restringida, nuevamente, a las personas e instituciones autorizadas.

La concreción de cualquiera de estas tres amenazas puede tener consecuencias graves tanto para el Estado como para el individuo. Cuando los datos son procesados electrónicamente, su vulnerabilidad a estos riesgos está dada por el software que lo procesa.

El software libre atiende las necesidades de la Seguridad Nacional

El software libre permite al usuario la inspección completa y exhaustiva del mecanismo mediante el cual procesa los datos. El interés en el mecanismo de procesamiento es mucho más que académico. Sin la posibilidad de la inspección, es imposible saber si el programa cumple meramente con su función, o si además incluye vulnerabilidades intencionales o accidentales que permitan a terceros acceder indebidamente a los datos, o impedir que los usuarios legítimos de la información puedan usarlo. Este peligro puede parecer exótico, sin embargo es muy concreto, y hay antecedentes documentados.

El hecho de permitir la inspección del programa es una excelente medida de seguridad, ya que al estar expuestos los mecanismos, estos están constantemente a la vista de profesionales capacitados, con lo que se vuelve inmensamente más difícil ocultar funciones maliciosas, aún si el usuario final no se toma el trabajo de buscarlas él mismo.

Al adquirir una licencia de uso de software privativo, en cambio, el usuario obtiene el derecho a ejecutar el programa en una computadora, pero no a conocer el mecanismo mediante el que el programa opera. Un elemento esencial de toda licencia privativa es la prohibición expresa al usuario de acaso intentar descubrir la manera en la que el programa funciona. Esta limitación puede ser razonable para un programa de juego, pero es inaceptable en todos aquellos casos en los que el programa maneja información útil, ya que al estar impedido de inspeccionarlo, al usuario sólo le queda la posibilidad de confiar en que sus proveedores, y también todos y cada uno de los empleados de sus proveedores, e incluso las entidades gubernamentales bajo las que su proveedores operan, se comporten de manera impecable y priorizando la seguridad del cliente aún por encima de sus propios intereses comerciales, nacionales o estratégicos. Esta confianza ya ha sido rota repetidas veces. Valgan dos ejemplos de la larguísima lista, ambos ampliamente documentados:

La «puerta trasera» de Interbase

El sistema de base de datos conocido como «Interbase» fue comercializado por muchos años por la firma Borland bajo una licencia privativa, en la cual se prohibía al usuario la inspección del programa. Durante el año 2000, sin embargo, Borland decidió publicar el programa bajo una licencia libre, gracias a la cual el programa está hoy a disposición del público en general, y está siendo sometido a escrutinio por programadores de todo el mundo. Recientemente, este escrutinio arrojó como resultado que durante al menos seis años, Borland había entregado a sus clientes (clientes que habían pagado por el privilegio de usar su software) un programa que contenía una «puerta trasera», es decir un mecanismo oculto mediante el cual los conocedores del secreto podían forzar la entrada al sistema y manipular los datos del cliente a su antojo.

Nunca quedó claro si la puerta trasera había sido instalada con conocimiento de la dirección de la empresa o no. El hecho de haber hecho público el programa sin haber eliminado previamente esas funciones (en cuanto evidencia incriminatoria) sugiere que éstas fueron incorporadas al producto por algún programador anónimo, sin autorización de la empresa. De lo que no caben dudas es de que la intención fue maliciosa, y los usuarios de este producto estuvieron, sin saberlo, varios años a merced de los iniciados en el secreto. Hoy, gracias a que el programa está disponible bajo una licencia libre, la puerta trasera pudo ser cerrada.

[Fuente: http://www.kb.cert.org/vuls/id/247371]

Windows NT incluye una clave criptográfica atribuible a la NSA

La National Security Agency (Agencia de Seguridad Nacional, más conocida como NSA) de los EEUU es una poderosa entidad de contraespionaje, cuyas atribuciones incluyen, por ejemplo, la de dejar temporariamente sin efecto las garantías constitucionales de los ciudadanos, y que restringe fuertemente la comercialización de dispositivos de seguridad, en
particular de encripción de datos. Es gracias a la NSA que es ilegal exportar tecnología de encripción «fuerte» de datos desde de los EEUU, salvo algunas excepciones. Una de estas excepciones es el software de seguridad incluído con Microsoft Windows NT, que se comercializa bajo una licencia de tipo privativa.

El mecanismo de seguridad de NT permite agregar mecanismos de encripción al sistema, pero sólo si esos mecanismos han sido previamente «firmados» digitalmente por Microsoft Corp., lo que puede ser interpretado como una medida razonable para asegurar al usuario que el mecanismo está intacto y no ha sido alterado antes de la instalación.

El hecho de que esté prohibido analizar el funcionamiento de un programa no quiere decir que nadie lo haga, y menos cuando de seguridad se trata. Especialistas en seguridad inspeccionaron, con gran esfuerzo y probablemente en violación de la ley, el mecanismo de seguridad de Windows NT, y descubrieron el lugar donde está almacenada la «clave pública» mediante la cual el programa puede determinar si la «firma digital» es auténtica o no. Lo curioso es que descubrieron que, junto a esta clave pública, había almacenada una segunda, de origen y función desconocidos. Esto llamó la atención de alguna gente, pero siendo imposible determinar para qué servía la segunda clave, la cosa pasó relativamente inadvertida.

Un tiempo después, Microsoft liberó el fatídico «Service Pack 5», una actualización del sistema operativo, y lo puso a disposición del público a través de Internet. Lo particular del caso es que, durante el proceso de producción de esta actualización, algún empleado de Microsoft se olvidó de llevar a cabo un paso de «limpieza previa» de los programas. El objetivo de esta limpieza es eliminar del programa todo rastro de los nombres con los que el programa se refiere a cada elemento de datos. La omisión del paso de limpieza permitió a los especialistas originales corroborar que lo que habían encontrado era la clave pública de Microsoft, ya que el sistema se refería a ese item de datos bajo el nombre «MS_KEY» (abreviatra de «Microsoft Key», o «Clave de Microsoft»). La sorpresa fue grande, sin ambargo, cuando vieron que el nombre de la segunda clave era «NSA_KEY» («Clave de la NSA»).

Microsoft salió por cierto al cruce de la acusación de haber incluído una clave de la NSA en Windows NT, alegando que esa segunda clave era también de Microsoft, pero nunca ofreció una explicación satisfactoria para el nombre de la clave, ni indicación alguna de su función. Concretamente, no sabemos si la NSA tiene o no una puerta trasera a todas las computadoras que operan con Windows NT (y subsiguientes) del planeta, pero existe suficiente evidencia circunstancial como para preocuparse, sobre todo para entidades que manejan datos confidenciales, ya que la única suposición que puede hacerse sin comprometer su seguridad es que la NSA tiene completo acceso a ella.

[Fuente: http://www.f-secure.com/news/1999/19990906.htm]

El software y la dependencia tecnológica

Son muchas y conocidas las ventajas aportadas por la adopción de herramientas de procesamiento de datos. Pero una vez comenzada la informatización de una tarea, la computadora se vuelve imprescindible, y la tarea pasa a depender de su disponibilidad. Si la institución que usa la aplicación no tiene libertad de contratación en lo que se refiere a ampliaciones y correcciones del sistema, se produce una dependecia tecnológica en la que el proveedor está en condiciones de dictar unilateralmente términos, plazos y precios.

Una forma particularmente insidiosa de esta dependencia tecnológica se produce a través de la manera en que se almacenan los datos. Si el programa usa un formato de almacenamiento estándard, entonces el usuario puede estar seguro de que en el futuro podrá seguir descifrando la información. Si, por el contrario, los datos se almacenan en un formato secreto, el usuario queda atrapado en un determinado proveedor, que es el unico que puede ofrecer alguna garantía de acceso a ellos.

El software libre permite al usuario el control de su destino

Las licencias libres no sólo habilitan al usuario para la ejecución del software, sino que le permiten utilizarlo de muchas otras maneras. Entre ellas, el usuario tiene derecho a inspeccionar el programa a su antojo, y por ese sencillo mecanismo (si no por otros más poderosos, como la adhesión a standards), transparenta los formatos de almacenamiento de datos, de modo que el usuario tiene la tranquilidad de que siempre podrá acceder a ellos, y de que los desarrolladores de programas que interactúan con los suyos siempre dispondrán de documentación completa y correcta para asegurar una comunicación sin problemas.

Además, el software libre permite al usuario corregir y modificar el programa para adecuarlo a sus necesidades. Esta libertad no está destinada solamente a los programadores. Si bien son éstos los que pueden capitalizarla en primera mano, los usuarios también se benefician enormemente, porque de esta manera pueden contratar a cualquier programador (no necesariamente al autor original) para que corrija errores o añada funcionalidad. Las personas que puede contratar no sólo no tienen exclusividad alguna sobre la posibilidad de contratación, sino que tampoco la adquieren a partir de sus modificaciones. De esta manera, el usuario puede asignar sus recursos a resolver sus necesidades de acuerdo a sus propias prioridades, pidiendo varias cotizaciones y quedándose con aquella que le ofrezca mejor relación precio/prestación, sin exponerse a chantajes y extorsiones.

El efecto de red + formatos secretos = monopolio

Todo programa de computadora, y en especial aquellos que se utilizan para comunicar información (procesadores de texto, planillas de cálculo, administradores de correo electrónico, navegadores de Internet, gestores de bases de datos, etc.), exhiben lo que técnicamente se conoce como «network effect» o «efecto de red». Esto es: su utilidad aumenta con la cantidad de personas que lo usa, es decir con el tamaño de la «red de usuarios» del programa. Los proveedores de software privativo conocen esto muy bien, y todos ellos utilizan el mismo mecanismo para aprovecharlo: en cuanto alcanzan una porción significativa del mercado, comienzan a almacenar los datos en un formato secreto.

Detengámonos un momento en este punto, para saborear lo que esto implica: los datos del usuario, datos en los que el autor del software no tuvo ninguna participación, son codificados y almacenados en un formato secreto, propiedad del autor del programa, y que el usuario no tiene derecho a investigar.

Lo que ocurre aquí es que los datos del usuario están siendo tomados como rehén por el productor de software: dado que el formato es secreto, la única manera que el usuario tiene de asegurarse que aún en el futuro podrá acceder a esos datos, es a través de continuar usando programas de ese autor, y no de otro. Es cierto: muchos programas ofrecen la posibilidad de leer documentos codificados en formatos foráneos (por ejemplo, WordPerfect y Word pueden cada uno leer archivos creados por el otro), esta función es por lo general incompleta (es común la pérdida de imágenes, fuentes, etc.) y poco confiable, perdiendo a menudo información que estaba presente bajo la aplicación original, pero que no aparece en la nueva.

El objetivo que el autor de software privativo persigue con esta estrategia es que la comunicación más perfecta y sencilla se produzca exclusivamente entre usuarios del mismo programa. Lo peor es que la estrategia funciona. La razón más citada para usar Microsoft Word es que «es la única manera de intercambiar datos cómodamente con el resto del mundo», independientemente de la calidad o el precio del producto. Si Word almacenara los datos siempre en un formato público (lo que sería perfectamente factible), el usuario podría elegir cuál programa es el que mejor satisface sus necesidades, independientemente de cuánta gente lo usa. Por cierto, Word es solo un ejemplo. Si no fuera Word el programa dominante de la categoría, habría otro que estaría en su lugar, y el argumento seguiría valiendo con la misma fuerza, dado que el software privativo, como mecanismo, conduce inevitablemente al monopolio.

La licencia limitada de uso deja inerme al usuario

Es conocido que los programas de computadora a menudo contienen errores, y que no siempre se adecúan perfectamente a las necesidades del usuario. El cliente de software privativo, que ha adquirido meramente una licencia limitada de uso, no tiene otro remedio que recurrir al autor del programa, en la esperanza de que éste se sienta inclinado a corregir la situación en tiempo y forma (recordemos que la licencia de uso del software es «tal como está», de modo que el autor no tiene obligación de corregir eventuales errores). A veces, el usuario está en condiciones de incentivar al autor a corregir un error o agregar una función que necesita, pagándole por que lo haga, pero hay obstáculos:

• casi siempre, el usuario es una organización mucho más chica y menos poderosa que el autor, de modo que su capacidad de incentivarlo es muy limitada
• el autor es la única organización que tiene derecho a corregir y modificar el programa, por lo que puede dictar precio, condiciones y plazos a su antojo
• aún cuando el usuario pague por el desarrollo del arreglo o de la nueva función, la propiedad intelectual sigue siendo exclusivamente del autor, que seguirá lucrando con la nueva funcionalidad adquirida con el dinero del cliente

En otras palabras, el usuario está a merced del autor del software, que puede atender sus necesidades o no de acuerdo a su sola discreción.

Peor aún, al estar los datos codificados en un formato secreto, el usuario depende absolutamente de que el propietario del software continúe permitiéndole el uso de los programas, porque de otra manera no puede acceder a su propia información. El propietario del software tiene, a todos los efectos prácticos, la potestad de decidir si
un usuario determinado puede acceder o no a los datos que él mismo elaboró.

El software privativo fuerza decisiones que deberían ser del usuario

El software privativo se licencia de tal modo que sólo puede ejecutarse en un determinado tipo de computadora, o sistema operativo. La elección de qué combinación de computadora y sistema operativo queda enteramente a discreción del propietario del programa: nadie puede obligarlo a hacer que su programa esté disponible para tal o cual plataforma, y como la licencia es meramente de uso, y no de modificación, tampoco es posible llevarlo uno mismo a la plataforma de elección. Este hecho, combinado con el monopolio inevitable al que conduce el efecto de red, hace que la elección del usuario esté dictada por las decisiones del propietario del software dominante, en vez de ser hecha en base a sus propias necesidades. Esto es claramente visible en el mercado de computadoras de escritorio, en el que la predominancia de Windows ha convertido a las computadoras basadas en procesadores de la familia Intel aparezcan al ojo no entrenado como la única alternativa viable.

De la misma manera, valiéndose del mismo mecanismo de almacenar datos en formatos secretos que pueden cambiar a discreción, sin necesidad de autorización, los productores de software privativo periódicamente obligan a sus clientes a adquirir actualizaciones innecesarias de sus programas. El recurso es simple: comercializan una versión nueva del producto, y retiran la vieja del mercado. La nueva versión usa un nuevo formato, incompatible con el anterior. El resultado es que el usuario, aún si está conforme con las prestaciones de la versión con la que cuenta, no tiene más remedio que adquirir la versión más «moderna», porque es la única forma que tiene de leer los archivos que le envían sus conocidos y colegas que tienen la versión nueva.

Por cierto, a menudo estas actualizaciones forzadas traen aparejadas otras, porque el nuevo software tiene requerimientos de hardware más ambiciosos, y consume más memoria, o necesita un procesador más rápido, causando gastos innecesarios, etc.

El ciudadano argentino debe pagar una licencia a Microsoft para poder cumplir con sus deberes impositivos

Uno de los ejemplos más patéticos de esta dependencia tecnológica puede verse en la misma legislación argentina. Desde hace un tiempo, la AFIP exige a los contribuyentes la presentación de diversas declaraciones en formato digital. La idea, por cierto, es razonable, pero la manera en la que la AFIP la implementó es tal que exige que la presentación sea hecha exclusivamente a través de la ejecución de programas específicos provistos por esa organización. Estos programas, es cierto, son gratuitos, pero entre sus requerimientos de ejecución se incluyen, como sistemas operativos, exclusivamente «Windows 95, 98 o superior». Es decir que el Estado está exigiendo a los ciudadanos que compren un determinado producto de un determinado proveedor al sólo fin de poder cumplir sus obligaciones impositivas. Esto es equivalente a dictar que los formularios no digitales sólo pueden ser completados usando lapiceras fuente marca «Mont Blanc».

El software y el desarrollo local

Si el usuario está habilitado para ejecutar un programa, pero no para inspeccionarlo ni modificarlo, entonces no puede aprender de él, se vuelve dependiente de una tecnología que no sólo no comprende sino que le está expresamente vedada. Los profesionales de su entorno, que podrían ayudarlo a alcanzar sus metas, están igualmente limitados: como el funcionamiento del programa es secreto, y su inspección está prohibida, no es posible arreglarlo. De esa manera, los profesionales locales ven sus posibilidades de ofrecer valor agregado cada vez más limitadas, y sus horizontes laborales se estrechan junto con sus chances de aprender más.

Está roto, y no se puede arreglar

Probablemente toda persona que usa una computadora con software privativo conoce la situación: está trabajando, cuando de repente el programa que opera se «cuelga» sin razón aparente. Aquellos lo suficientemente afortunados como para contar con personal de soporte técnico, o con amigos enterados, suelen acudir a ellos en busca de ayuda, al menos las primeras veces. Pero ante esta situación el técnico apenas alcanza a diagnosticar «se colgó» (gracias, no nos habíamos dado cuenta) y a oprimir el botón de «reset». Los datos que el usuario había compilado laboriosamente a lo largo de las últimas cuatro horas están irremediablemente perdidos. La frustración es mucha. ¿Para qué estudian tanto y se dan aires de sabihondos, si no saben arreglar una cosa cotidiana como esta? La máquina ahora anda (rengueando), pero ¿cuánto tiempo va a pasar hasta que se descomponga de nuevo?

Lamentablemente, los profesionales locales no pueden dar respuesta a estos problemas, porque el conocimiento necesario para darla está restringido a los empleados del propietario de los programas en juego. Es cierto: los propietarios ofrecen onerosos cursos en los que capacitan profesionales para resolver problemas, pero ellos dictan la profundidad de esos cursos, nunca revelan todos los detalles, y no proveen ninguna manera de corroborar que lo que enseñan es realmente correcto. En suma, nadie sabe exactamente qué pasa, solamente sospecha. Y aún si una de estas sospechas fuera correcta, aún en el improbable caso de que alguien, fortuitamente, descubriera la causa de un determinado error y pudiera eliminarlo para siempre… ¡Tendría prohibido hacerlo!

El software privativo reduce a los profesionales locales al papel de «monos de apretar reset».

El software libre fomenta el desarrollo local y se nutre del global

El cliente que exige a un profesional local que le dé soporte sobre un programa privativo está pidiendo lo imposible. Si lo que necesita es un campo fértil de profesionales competentes, que conozcan a fondo los productos que soportan, y que estén en condiciones de ofrecer soluciones definitivas a los problemas que surjan, y no meros parches, estará en mucho mejores manos adoptando software libre para su operación.

Al usar software libre, que los profesionales pueden analizar a fondo, comprender y mejorar, el usuario queda en posición de poder exigirle al personal de soporte que los sistemas cumplan su tarea a la perfección. Ya no cabe la excusa «lo que pasa es que se cae el XXX», donde XXX es cada día una nueva y oscura componente sobre la que el profesional no tiene control, y por ende responsabilidad. Aquí está todo abierto, todo el que quiere puede aprender, todo el que quiere puede colaborar, y si alguien no sabe es porque no quiso aprender, no porque alguien le ocultó la información necesaria para cumplir con su tarea.

Es cierto que no existen aún soluciones libres para todas la necesidades de los usuarios. Si vamos al caso, tampoco existen soluciones privativas para todas las necesidades. En aquellos casos en que la solución libre no existe, hay que desarrollarla, lo que significa esperar a que alguien más tropiece con la necesidad y lo desarrolle, o desarrollarlo uno mismo (o lo que es igual, pagar para que alguien lo desarrolle). La diferencia está en que en aquellos casos en que sí hay una solución libre disponible, el usuario puede utilizarla inmediatamente y sin reparos de ningún tipo, mientras que con las soluciones privativas siempre tiene que pagar, y lo que obtiene a cambio es una «solución» cerrada y secreta, en vez de una herramienta que le permita crecer y operar con seguridad y libertad.

El software libre sienta las bases para un desarrollo sólido y autónomo de los profesionales locales que ofrecen soluciones.

El software y la capacidad operativa

Una vez que se introduce la informática en una tarea, comienza a hacerse imprescindible. Esto se debe en gran parte a que los datos almacenados en medios digitales son, a diferencia de aquellos registrados en papel, imposibles de descifrar cuando la computadora no está funcionando. Por ello, es esencial que los medios técnicos de procesamiento de datos estén a disposición del usuario, de lo contrario éste se ve imposibilitado de cumplir con su tarea.

«Se cayó el sistema»

Nadie se asombra ya de perder horas de trabajo porque debió reiniciar su sistema, ni de que sus datos desaparezcan (junto con los de varios colegas) debido a la acción de un virus, ni de las colas detenidas porque la computadora no responde. El usuario está resignado, y acepta estos problemas como parte del precio a pagar por el uso de la herramienta. Sin embargo, ninguna de estas fallas es inherente a las computadoras: son tan solo la expresión tangible de la impotencia del usuario final ante las fallas de un mecanismo sobre el que no tiene ningún control, y del que depende para poder llevar a cabo su tarea.

Esta falta de control alcanza niveles grotescos. Tomemos como ejemplo el sistema de emisión de pasaportes de la Policía Federal. Cuando argentinos que viven en el exterior tienen un hijo en un país que se rige por el Jus Sanguinis, digamos Alemania, el niño no es argentino ni alemán, es apátrida. Alemania se rehúsa a emitir un pasaporte para el niño. Argentina sí lo emite, pero a la hora de ingresar la nacionalidad del niño, el programa carece de la opción «apátrida», por lo cual se lo anota como alemán, decisión tan arbitraria como designarlo hindú. En síntesis, tenemos aquí un caso en el que el defecto de un programa de software modifica de hecho la legislación.

El software libre permite operar correcta y eficientemente

La clave de la operatividad está en el control. El software libre es en general mucho más robusto que sus contrapartes privativas sencillamente porque cuando los usuarios encuentran un defecto lo pueden arreglar (o hacer arreglar) de acuerdo a sus propios intereses. Y al ser la corrección libre, al igual que el programa original, basta con que algún usuario en el planeta encuentre méritos para resolver el problema para que esté solucionado para todos los demás. El usuario puede adaptar el programa a sus necesidades sin pedirle permiso a nadie, eligiendo plazos, presupuestos y proveedores de acuerdo a sus posibilidades y prioridades, y resolviendo sus problemas de una vez por
todas, en vez de continuar luchando contra ellos cotidianamente.

El costo del software

El software no sólo cuesta un precio de adquisición de licencia. También cuesta mantenerlo, operarlo, ajustarlo. Es importante para el usuario el poder mantener estos costos bajo control, pues de lo contrario puede llegar a verse impedido de llevar a cabo sus metas, a fuerza de erogaciones no planificadas.

El software libre es del usuario

Un detalle simpático del software libre, consecuencia directa de las características que ya hemos discutido, es que su uso es libre: todo aquel que lo tiene en su poder puede usarlo cuantas veces quiera, en cuantas máquinas quiera, a los fines que quiera. De esta manera, utilizando software libre, el usuario se libera de toda dependencia de un proveedor único, y puede administrar su crecimiento y operación con total autonomía, sin temor de costos ocultos ni extorsiones.

El dueño de la pelota

Todas las desventajas comparativas del software privativo respecto del software libre que hemos mencionado se traducen materialmente en perjuicios económicos para el usuario, en términos de horas de trabajo perdidas, falta de capacidad de reacción, decisiones forzadas, dependencia tecnológica, inseguridad de datos, actualizaciones innecesarias, etc. A esto se suman los costos de licencia, tanto los ostensibles como los ocultos.

La licencia limitada de uso bajo la que se comercializa el software privativo no solo es onerosa, sino que además coloca al usuario en multitud de problemas. Por ejemplo, la obligación de pagar nuevamente al proveedor del sistema cada vez que expande su operación, pese a que éste no aporta nada nuevo. Peor aún, el proveedor obliga al cliente a hacer su propia auditoría respecto de la correcta aplicación de las licencias. Este problema se agrava debido a la falta de provisión, por parte del titular de los derechos de autor, de herramientas efectivas para controlar el uso de software, de modo que, a medida que aumenta la cantidad de máquinas y usuarios, este mismo control se va haciendo cada vez más caro, hasta superar los costos de la misma licencia.

El software y el Estado

La argumentación citada es por cierto aplicable a todo tipo de organizaciones grandes y pequeñas. Pero lo que en el emprendimiento privado es mera conveniencia, para el Estado se vuelve crucial. El Estado administra información pública y privada acerca de los ciudadanos, y simultáneamente propiedad de los ciudadanos. La inseguridad intrínseca en la operación «secreta» del software privativo implica exponer estos datos a un riesgo injustificable de sustracción y alteración.

También desde los puntos de vista social y estratégico es imperativo el uso de software libre. Es la única manera de garantizar no sólo la democratización del acceso a la información y los sistemas del Estado, sino también la competitividad de la industria local de software, potencial fuente de trabajo de altísimo valor agregado. Creemos importante destacar que no es esta una medida proteccionista: independientemente de su origen, se trata de privilegiar aquel software cuya licencia alienta la participación y colaboración de profesionales del medio en vez de discriminarlos, a la vez que estimula la competencia.

La dependencia tecnológica emergente de la naturaleza del software privativo es claramente inaceptable para el Estado. Ya hay instituciones torciendo las leyes para adaptarlas al software que les vendieron. Los contribuyentes nos vemos forzados a adquirir software de una determinada marca y modelo al solo efecto de cumplir nuestras obligaciones tributarias. El Estado está expuesto al chantaje a través de la información que tiene almacenada en formatos privativos secretos, al sabotaje a través de vulnerabilidades deliberadas, y todo esto a pesar de estar disponibles las herramientas y los conocimientos necesarios para no estar expuestos a estos problemas.

El Estado, por su envergadura y por su papel de administrador de los bienes comunes, es particularmente vulnerable a los riesgos del software privativo, a la vez que está en una posición particularmente estratégica para beneficiarse con las ventajas del software libre, y también para contribuir a su desarrollo. Pongamos por ejemplo a las provincias, todas embarcadas en costosísimos programas de informatización, que podrían formar un conglomerado para financiar el desarrollo de una solución libre a su problemática, y compartirla entre todas. El Estado Nacional está en una situación similar, si contamos con el hecho de que las distintas reparticiones regionales de un mismo ente requieren licencias de uso de software adicionales.

Estado de desarrollo del software libre

Actualmente, existen soluciones de software libre listas para instalar y usar en las siguientes funciones, entre muchas otras:

• Estación de trabajo
• Infraestructura de red (para máquinas Linux, Windows, Macintosh, Unix, etc.)
  • Servidor de archivos
  • Servidor de impresoras
  • Servidor de correo electrónico
  • Servidor de WWW
  • Servidor de acceso a Internet
• Gestión de bases de datos
• Desarrollo de software
• Gestión de oficina (procesador de la palabra, hoja de cálculo, etc.)
• Correo electrónico y comunicaciones en general
• Navegación de Internet

Por cierto, no existen aún soluciones libres para todos y cada uno de las necesidades que podamos imaginar, pero eso también es cierto del software privativo. En estos casos, la respuesta es, claramente, desarrollarlo, creando una solución duradera, que nos permita crecer y administrar nuestros datos con seguridad y libertad.

Copyright

Copyright (c) 2001  Federico Heinz
Se garantiza el permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre GNU, versión 1.1 (GNU Free Documentation License, Version 1.1 ) o cualquier otra versión posterior publicada por la Free Software Foundation; este documento se presenta sin Secciones Invariables (no Invariant Sections), sin Textos de Tapa (no Front-Cover Texts) y sin Textos de Contratapa (no Back-Cover Texts).
Una copia de la licencia está incluida en la sección titulada «GNU Free Documentation License».

GNU Free Documentation License:http://www.gnu.org/copyleft/fdl.html

De lo que parecen no enterarse quienes exponen una y otra vez los mismos argumentos contra este tipo de iniciativas, es que ya han sido refutados hace mucho tiempo. Por esto, me pareció buena idea rescatar del recuerdo la excelente respuesta que en abril de 2002 enviara al Gerente de Microsoft Perú, el congresista peruano Edgar Villanueva Nuñez (haciendo gala de una simpleza y una lógica exquisitas) quien impulsaba un proyecto de ley de este tipo en su país.

Aclaración: Al final del artículo se incluye la carta original como referencia, pero la respuesta cita cada uno de los puntos expuestos, por lo que no es necesaria su lectura previa.

Respuesta del congresista Villanueva Nuñez a Microsoft Perú

Lima, 08 de Abril del 2002.

Señor Juan Alberto González
Gerente General de Microsoft del Perú
Presente

Estimado Señor.

Ante todo, agradezco su carta del 25 de Marzo del 2002 donde manifiesta la posición oficial de Microsoft respecto al Proyecto de Ley Nº 1609, Software Libre en la Administración Pública, que sin duda se halla inspirada en el deseo de que el Perú logre situarse adecuadamente en el contexto tecnológico global. Animado de ese mismo espíritu y convencido de que a través del intercambio de ideas claras y abiertas hemos de encontrar las mejores soluciones, me permito contestar mediante la presente los comentarios incluidos en su carta.

Sin dejar de reconocer que opiniones como la suya constituyen un aporte significativo, me hubiese resultado aun mas valioso si, además de formular objeciones de índole general (que luego analizaremos en detalle) hubiera agregado argumentos sólidos sobre las ventajas que el software propietario puede reportar al Estado Peruano y a sus ciudadanos en general, pues ello habría permitido un intercambio a todas luces más esclarecedor respecto de cada una nuestras posiciones.

Con el objetivo de ordenar el debate, asumiremos que lo que Ud. llama «software de código abierto» es lo que el Proyecto define como «software libre», puesto que existe software cuyo código es distribuido junto con los programas, pero no encaja en la definición establecida en el Proyecto; y lo que Ud. llama «software comercial» es lo que el Proyecto define como «propietario» o «no libre», puesto que existe software libre que se comercializa en el mercado por un precio como cualquier otro bien o servicio.

También es preciso dejar en claro que el propósito del Proyecto al que nos referimos no está directamente relacionado con la cantidad de ahorro directo que pueda obtenerse por el empleo de software libre en las instituciones estatales. Este es en todo caso, un valor agregado marginal, pero de ninguna manera el foco del objetivo del Proyecto. Los principios elementales que animan al Proyecto se vinculan a las garantías básicas de un Estado democrático de derecho, como:

• Libre acceso del ciudadano a la información pública.
• Perennidad de los datos públicos.
• Seguridad del Estado y de los ciudadanos.

Para garantizar el libre acceso de los ciudadanos a la información pública, resulta indispensable que la codificación de los datos no esté ligada a un único proveedor. El uso de formatos estándar y abiertos permite garantizar este libre acceso, logrando si fuera necesario la creación de software libre compatible.

Para garantizar la perennidad de los datos públicos, es indispensable que la utilización y el mantenimiento del software no dependan de la buena voluntad de los proveedores, ni de las condiciones monopólicas impuestas por éstos. Por ello el Estado necesita sistemas cuya evolución pueda ser garantizada gracias a la disponibilidad del código fuente.

Para garantizar la seguridad del Estado o seguridad nacional, resulta indispensable contar con sistemas desprovistos de elementos que permitan el control a distancia o la transmisión no deseada de información a terceros. Por lo tanto, se requieren sistemas cuyo código fuente sea libremente accesible al público para permitir su examen por el propio Estado, los ciudadanos, y un gran número de expertos independientes en el mundo. Nuestra propuesta aporta mayor seguridad, pues el conocimiento del código fuente eliminará el creciente número de programas con código espía.

Asimismo, nuestra propuesta refuerza la seguridad de los ciudadanos, tanto en su condición de titulares legítimos de la información manejada por el estado, cuanto en su condición de consumidores. En este ultimo caso, al permitir el surgimiento de una oferta extensa de software libre desprovisto de potencial código espía susceptible de poner en riesgo la vida privada y las libertades individuales.

En este sentido, el Proyecto de Ley se limita a establecer las condiciones en que los organismos estatales adquirirán software en el futuro, es decir, de un modo compatible con la garantía de esos principios básicos.

De la lectura del Proyecto quedará claro que una vez aprobada:

• la ley no prohibe la producción de software propietario
• la ley no prohibe el comercio de software propietario
• la ley no dicta cuál software concreto usar
• la ley no dicta a que proveedor se compra el software
• la ley no limita los términos en que se puede licenciar un producto de software.

Lo que el proyecto expresa claramente es que, el software para ser aceptable para el Estado, no basta con que sea técnicamente suficiente para llevar a cabo una tarea, sino que además las condiciones de contratación deben satisfacer una serie de requisitos en materia de licencia, sin los cuales el Estado no puede garantizar al ciudadano el procesamiento adecuado de sus datos, velando por su integridad, confidencialidad y accesibilidad a lo largo del tiempo, porque son aspectos muy críticos para su normal desempeño.

Estamos de acuerdo Sr. González, en el hecho de que la tecnología de información y comunicaciones tiene un impacto en la calidad de vida de los ciudadanos significativo (sin que por ello sea siempre positivo o de efecto neutro). También coincidiremos seguramente, en que los valores básicos que he señalado arriba son fundamentales en una nación democrática como el Perú. Desde luego estamos muy interesados en conocer cualquier forma alternativa de garantizar estos principios, que no sea la de recurrir al empleo de software libre en los términos definidos en el Proyecto de Ley.

En cuanto a las observaciones que Ud. formula, pasaremos ahora a analizarlas en detalle:

En primer lugar, señala que:

«1. El proyecto establece la obligatoriedad de que todo organismo público debe emplear exclusivamente software libre, es decir de código abierto, lo cual transgrede los principios de la igualdad ante la ley, el de no discriminación y los derechos a la libre iniciativa privada, libertad de industria y contratación protegidos en la constitución.».

Esta apreciación constituye un error. De ningún modo el proyecto afecta los derechos que Ud. enumera; sólo se limita a establecer condiciones para el empleo del software por parte de las instituciones estatales, sin inmiscuirse en modo alguno en las transacciones del sector privado. Es un principio bien establecido que el Estado no tiene el amplio espectro de libertad contractual del sector privado, pues precisamente esta limitado en su accionar por el deber de transparencia de los actos públicos; y en ese sentido, la preservación del mejor interés común debe prevalecer cuando se legisla sobre la materia.

El Proyecto protege la igualdad ante la Ley, pues ninguna persona natural o jurídica esta excluida del derecho de ofrecer estos bienes al Estado en las condiciones fijadas en el Proyecto y sin más limitaciones que las establecidas en la Ley de Contrataciones y Adquisiciones del Estado (T.U.O. por Decreto Supremo No. 012-2001-PCM).

El Proyecto no introduce discriminación alguna, pues sólo establece cómo han de proveerse estos bienes (lo cual es una potestad estatal) y no quién ha de proveerlos (lo que en efecto resultaría discriminatorio si se impusieran restricciones basadas en origen nacional, raza, religión, ideología, preferencia sexual, etc.) Por el contrario, el Proyecto es decididamente antidiscriminatorio. Es así porque al determinar sin lugar a dudas las condiciones de provisión del software, impide a los organismos estatales el uso de programas cuyo licenciamiento incluya condiciones discriminatorias.

Resulta obvio por lo expuesto en los dos párrafos previos, que el Proyecto no atenta contra la libre iniciativa privada, pues esta puede elegir siempre bajo que condiciones producirá el software; algunas de estas serán aceptables para el Estado, y otras no lo serán porque contrarían la garantía de los principios básicos enumerados arriba. Esta libre iniciativa es desde luego, compatible con la libertad de industria y con la libertad de contratación (en los términos acotados en que el Estado puede ejercer esta última). Cualquier sujeto privado puede producir software en las condiciones que el Estado lo requiere, o puede abstenerse de hacerlo. Nadie esta forzado a adoptar un modelo de producción, pero si desea proveer software al Estado, deberá proporcionar los mecanismos que garantizan los principios básicos, y que son los manifestados en el Proyecto.

A manera de ejemplo: nada en el texto del Proyecto impediría a su empresa ofrecer a los organismos del Estado su «suite» de oficina, en las condiciones definidas en el Proyecto y fijando el precio que ustedes consideren conveniente. Si no lo hiciera, no se deberá a restricciones impuestas por la ley, sino a decisiones empresariales respecto al modo de comercializar sus productos, decisiones, en que el Estado no tiene participación.

A continuación señala Ud. que:

«2. El proyecto, al hacer obligatorio el uso de software de código abierto, establecería un tratamiento discriminatorio y no competitivo en la contratación y adquisición de los organismos públicos…»

Esta afirmación no es sino una reiteración de la anterior, y por ende se encuentra contestada lineas arriba. Pero detengámonos un instante en su apreciación sobre el «tratamiento … no competitivo».

Por cierto, al definir cualquier tipo de adquisición, el comprador fija condiciones que se relacionan con el uso propuesto del bien o servicio. Desde luego ello excluye a ciertos fabricantes de la posibilidad de competir, pero no los excluye «a priori», sino en base a una serie de principios decididos por la voluntad autónoma del comprador, en tanto el proceso se lleve a cabo conforme a la ley. Y en el Proyecto se estable que nadie esta excluido de competir en tanto garantice el cumplimiento de los principios básicos.

Además el Proyecto estimula la competencia, pues alienta a generar oferta de software con mejores condiciones de usabilidad, y a optimizar trabajos ya establecidos, en un modelo de mejora constante.

De otro lado, el aspecto central de la competitividad es la oportunidad de proporcionar al consumidor mejores opciones. Ahora bien, es imposible desconocer que el marketing no juega un papel neutral a la hora de presentar la oferta al mercado (pues admitir lo contrario habilitaría a suponer que las inversiones que las empresas realizan en marketing carecen de sentido), y por consiguiente un gasto significativo en este rubro puede influir las decisiones del comprador. Esta influencia del marketing queda en buena medida mitigada por el proyecto que propulsamos, pues la elección dentro del marco propuesto recae en el mérito técnico del producto y no en el esfuerzo de comercialización del productor; en este sentido, la competitividad se acentúa, pues el más pequeño productor de software puede competir en un pie de igualdad con la más poderosa de las corporaciones.

Es necesario recalcar que no hay posición más anti-competitiva que la de los grandes productores de software propietario, que frecuentemente abusan de su posición dominante, porque en innumerables casos proponen como soluciones a problemas planteados por los usuarios: «actualice su software a la nueva versión» (con cargo para el usuario, por supuesto); además, son comunes las interrupciones arbitrarias de asistencia técnica para productos que al sólo juicio del proveedor, son «antiguos»; luego para recibir algún grado de asistencia técnica, el usuario se ve obligado a migrar (con costo no trivial, especialmente porque suele involucrar cambios de la plataforma de hardware) a nuevas versiones. Y como toda la infraestructura esta consolidada en formatos de datos propietarios, el usuario queda «atrapado» en la necesidad de continuar empleando los productos del mismo proveedor, o realizar el enorme esfuerzo de cambiar a otro ambiente (también probablemente propietario).

Agrega Ud.:

«3. Así, al obligar al Estado a favorecer un modelo de negocios que apoyaría exclusivamente el software de código abierto, el proyecto sólo estaría desalentando a las compañías fabricantes locales e internacionales que son las que verdaderamente realizan importantes inversiones, crean un significativo número de puestos de empleos directos e indirectos, además de contribuir al PBI vs. Un modelo de software de código abierto que tiende a tener un impacto económico cada vez menor debido a que crea principalmente empleos en servicio.»

No estoy de acuerdo con lo que Ud. afirma. En parte por lo que Ud. mismo señala en el párrafo 6 de su carta, respecto del peso relativo de los servicios en el contexto del uso de software. Esta contradicción, de por sí, invalidaría su postura. El modelo de servicios, adoptado por gran número de corporaciones en la industria informática, es mucho más significativo, en términos económicos y con tendencia creciente, que el licenciamiento de programas.

Por otra parte, el sector privado de la economía tiene la más amplia libertad para elegir el modelo económico que mas convenga a sus intereses, aunque esta libertad de elección quede muchas veces oscurecida de manera subliminal por las desproporcionadas inversiones en marketing de los productores de software propietario.

Adicionalmente, de la lectura de su opinión se desprendería que el mercado Estatal es crucial e imprescindible para la industria del software propietario, a tal punto que la
opción que el Estado establece en este proyecto, eliminaría completamente del mercado a estas empresas. Si es así, deducimos que el Estado estaría subsidiando a la industria del software propietario. En el supuesto negado que esto fuese cierto, entonces el Estado tendría el derecho en aplicar los subsidios al área que considere de mayor valor social; resultaría innegable, en esta improbable hipótesis, que si el Estado decide subsidiar software debería hacerlo escogiendo el libre por encima del propietario, atendiendo a su efecto social y al uso racional de los dineros de los contribuyentes.

Respecto de los puestos de trabajo generados por el software propietario en países como el nuestro, estos tratan mayoritariamente tareas técnicas de poco valor agregado; a nivel local, los técnicos que prestan soporte a software propietario producido por empresas transnacionales no están en condiciones de solucionar un bug, no necesariamente por falta capacidad técnica o talento, sino porque no disponen del código fuente a reparar. Con software libre se crea empleo técnicamente más calificado y se genera un marco de libre competencia donde el éxito esta sólo vinculado a la capacidad de brindar buen soporte técnico y calidad de servicio, se estimula el mercado y se incrementa el patrimonio común del conocimiento, abriendo alternativas para generar servicios de mayor valor agregado y mejor perfil de calidad beneficiando a todos los actores: productores, prestadores de servicios y consumidores.

Es un fenómeno común en los países en vías de desarrollo que las industrias locales de software obtienen la mayoría de sus ingresos en el área de servicios, o en la construcción de software «ad hoc». Por lo tanto, cualquier impacto negativo que la aplicación del Proyecto pueda tener en este sector se verá compensado con creces por un aumento de la demanda de servicios (a condición de que estos sean prestados conforme a altos estándares de calidad). Desde luego, es probable que las empresas transnacionales de software si deciden no competir conforme a estas reglas de juego, sufran alguna disminución de ingresos en términos de facturación por licenciamiento; pero considerando, que estas empresas alegan sostenidamente que mucho del software empleado por el Estado fueron copiados ilegalmente, se verá que el impacto no ha de ser extremadamente serio. Ciertamente, en todo caso su fortuna estará determinada por leyes del mercado, cuyos cambios no es posible evitar; muchas empresas tradicionalmente asociadas con el software propietario ya han emprendido un camino firme (apoyado por cuantiosas inversiones) para prestar servicios asociados con el software libre, lo cual demuestra que los modelos no son mutuamente excluyentes.

Con este Proyecto el Estado está decidiendo que requiere preservar ciertos valores fundamentales. Y lo decide en base a sus potestades soberanas, sin afectar con ello ninguna de las garantías constitucionales. Si estos valores pueden ser garantizados sin tener que escoger un modelo económico dado, los efectos de la ley serían aun más beneficiosos. En todo caso debe quedar claro que el Estado no elige un modelo económico; si sucediera que existe un sólo modelo económico capaz de proveer software tal que satisfaga la garantía básicas de estos principios, se trataría de una circunstancia histórica y no de una decisión arbitraria en favor de un modelo dado.

Prosigue su carta:

«4. El proyecto de ley impone el uso de software de código abierto sin considerar los peligros que esto pueda conllevar desde el punto de vista de seguridad, garantía y posible violación de los derechos de propiedad intelectual de terceros.»

Aludir de forma abstracta «los peligros que pueda conllevar», sin especificar siquiera una sola instancia de esos supuestos peligros, denota cuando menos un desconocimiento del tema. Así, pues, permítame ilustrarlo sobre estos puntos.

Sobre seguridad:

En términos generales respecto la seguridad nacional, ya se mencionó inicialmente en los principios básicos del Proyecto. En términos más puntuales respecto de la seguridad del software en sí, es bien sabido que el software (propietario o libre) contiene errores de programación o «bugs» (en la jerga informática) en sus lineas de código. Pero también es público y notorio que los bugs en el software libre son menos, y se reparan mucho mas rápidamente, que en el software propietario. No en vano numerosas organismos públicos responsables por la seguridad informática de los sistemas estatales en países desarrollados prescriben el uso de software libre a iguales condiciones de seguridad y eficiencia.

Lo que resulta imposible probar es que el software propietario sea más seguro que el libre, salvo mediante el escrutinio publico y abierto de la comunidad científica y los usuarios en general. Esta demostración es imposible porque el propio modelo del software propietario impide este análisis, con lo que la garantía de seguridad se basa en la palabra bienintencionada (pero a todas luces parcial) del propio productor o sus contratistas.

Corresponde recordar que, en numerosos casos, las condiciones de licenciamiento incluyen cláusulas de Non-Disclosure que impiden a los usuarios revelar abiertamente las fallas de seguridad halladas en el producto propietario licenciado.

Respecto a garantía:

Como Ud. sabe perfectamente, o podrá determinar leyendo el «End User License Agreement» de los productos que licencia, en la amplísima mayoría de los casos, las garantías están limitadas a la reposición del medio de almacenamiento si este fuera defectuoso, pero en ningún caso se prevén compensaciones por daños directos o indirectos, lucro cesante, etc.. Si como consecuencia de un bug de seguridad en alguno de sus productos, no oportunamente reparado por Uds., un atacante comprometiera sistemas cruciales para el Estado: ¿que garantías, reparaciones y compensaciones proporcionaría su empresa de acuerdo con sus condiciones de licenciamiento? Las garantías del software propietario, en tanto los programas se entregan «AS IS», es decir, en el estado en que se encuentran, sin ninguna responsabilidad adicional para el proveedor respecto a su funcionalidad, no difieren en modo alguno de las habituales en el software libre.

Sobre la propiedad intelectual:

Las cuestiones de propiedad intelectual están fuera del ámbito en este proyecto, pues se encuentran amparadas por otras leyes específicas. El modelo de software libre no implica en modo alguno desconocer estas leyes y de hecho, la amplísima mayoría del software libre está amparado por el copyright. En realidad, la sola inclusión de esta cuestión en sus observaciones demuestra su confusión respecto del marco legal en que se desenvuelve el software libre. La incorporación de propiedad intelectual ajena en obras que luego se atribuyen como propias no es una práctica de la que se tenga registro en la comunidad del software libre; si lo es, lamentablemente, en el terreno del software propietario. Valga a titulo de ejemplo la condena de la Corte Comercial de Nanterre, Francia, del pasado 27 de septiembre de 2001 a Microsoft Corp., por 3 millones de francos en concepto de daños e intereses, por violación de la propiedad intelectual (piratería, según el desafortunado término que su empresa suele usar en su publicidad).

Prosigue diciendo que:

«5. El proyecto maneja de manera errónea los conceptos de software de código abierto, que no necesariamente implica que sea software libre o de costo cero, llegando a realizar conclusiones equívocas sobre ahorros para el Estado, sin ningún sustento costo beneficio que valide la posición.»

Esta observación no es así, en principio la gratuidad y la libertad son conceptos ortogonales: hay software propietario y oneroso (por ejemplo, MS Office), software propietario y gratuito (MS Internet Explorer), software libre y oneroso (distribuciones RedHat, SuSE, etc. del sistema GNU/Linux), software libre y gratuito (Apache, OpenOffice, Mozilla), y aun software que se licencia bajo diferentes modalidades (MySQL).

Ciertamente que el software libre no es necesariamente gratuito. Y tampoco se desprende del texto del Proyecto que deba serlo como bien habrá notado después de leer la norma propuesta. Las definiciones incluidas en el Proyecto determinan claramente qué debe considerarse software libre, en ningún momento se refieren a la gratuidad. Si bien se mencionan las posibilidades de ahorro en términos de lo pagado por licencias de software propietario, los fundamentos del proyecto hacen clara mención a las garantías fundamentales que se pretende preservar y al estimulo del desarrollo tecnológico local. Puesto que un Estado democrático debe sostener estos principios, no le queda otra solución que emplear software cuyo código fuente está públicamente disponible e intercambiar información sólo en formatos standares.

Si el Estado no empleara software con esas características, estaría vulnerando principios republicanos básicos. Por fortuna, además, el software libre implica menores costos totales; pero aun en la hipótesis (fácilmente negada) de que costara más que el propietario, la sola existencia de una herramienta de software libre eficaz para una determinada función informática obligaría al Estado a usarla; no por imperio de este Proyecto de Ley, sino por los principios elementales que enumeramos al comienzo y que surgen de la esencia misma del Estado democrático de derecho.

Sigue Ud.:

«6. Es equivocado pensar que el Software de Código Abierto es gratuito. Investigaciones realizadas por Gartner Group (importante investigadora del mercado tecnológico reconocida a nivel mundial) han señalado que el costo de adquisición del software (sistema operativo y aplicaciones) se reduce a sólo 8% del total de costos que las empresas e instituciones deben asumir como consecuencia del uso racional y realmente provechoso de la tecnología. El otro 92% lo constituyen: costos de implantación, capacitación, soporte, mantenimiento, administración e inoperatividad.»

Este argumento repite lo ya señalado en el párrafo 5 y en parte se contradice con el párrafo 3. Por lo tanto nos remitiremos a lo allí dicho en homenaje a la brevedad. No obstante, permítame señalarle que incurre en una conclusión falsa en el plano lógico: que el costo de software según Gartner Group sea sólo el 8% en promedio del costo total de utilización, no invalida en forma alguna la existencia de software gratuito, esto es, aquel cuyo costo de licenciamiento es cero.

Además en este párrafo Ud. indica acertadamente que los componentes de servicio y las pérdidas por indisponibilidad conforman la parte sustancial del costo total de utilización de software; lo que, advertirá, entra en contradicción con su afirmación del valor mínimo de los servicios sugerido en el párrafo 3. Ahora bien, el empleo de software libre contribuye significativamente a disminuir los restantes costos del ciclo de vida. Esta reducción del impacto económico de despliegue, soporte, etc. se registra en varios campos; por un lado, el modelo competitivo de servicios del software libre, cuyo soporte y mantenimiento es posible contratar libremente entre una oferta variada que compite en función de la calidad y el menor costo. Esto es válido para la implantación, la capacitación y el soporte, y en buena medida para el mantenimiento. En segundo lugar, por la característica reproductiva del modelo, hace que el mantenimiento que se realizó en una aplicación sea replicable muy fácilmente, sin incurrir en mayores costos (es decir, sin pagar más de una vez por lo mismo) pues las modificaciones, si así se desea, quedan incorporadas al patrimonio común del conocimiento. En tercero, porque el enorme costo causado por la inoperatividad («pantallas azules de la muerte», código malicioso como virus, worms y troyanos, excepciones, fallas generales de protección y otros tantos males conocidos) se reduce significativamente al emplear software mas estable; y es bien sabido que una de las virtudes mas destacables del software libre es su estabilidad.

Afirma luego que:

«7. Uno de los argumentos que sustentan el proyecto de ley es la supuesta gratuidad del software de código abierto, comparado con los costos del software comercial, sin tener en cuenta que existen modalidades de licenciamiento por volumen que pueden ser sumamente ventajosas para el Estado, tal como se ha logrado en otros países.»

He puntualizado ya que lo que está en cuestión no es el costo del software, sino los principios de libertad de información, accesibilidad y seguridad. Estos argumentos se han tratado de manera extensa en párrafos anteriores, por lo que estimaré remitirse a ellos.

Por otra parte, ciertamente existen modalidades de licenciamiento por volumen (aunque infortunadamente, el software propietario no satisface los principios básicos). Pero, como Ud. acaba de señalarlo acertadamente en el párrafo inmediatamente anterior de su carta, sólo apuntan a reducir el impacto de un componente que importa no más del 8% del costo total.

Prosigue:

«8. Adicionalmente, la alternativa adoptada por el proyecto (i) es claramente más costosa por los altos costos que supone una migración y (ii) pone en riesgo la compatibilidad y posibilidad de interoperabilidad de las plataformas informáticas dentro del Estado, y entre el Estado y el sector privado, dada la centena de versiones que existen de software de código abierto en el mercado.»

Analicemos su afirmación en dos partes. Su primer argumento, el de que la migración supone altos costos es en realidad un argumento en favor del Proyecto. Porque cuanto más tiempo transcurra la migración a otra tecnología esta se tornará mas onerosa; y al mismo tiempo se irán incrementando los riesgos de seguridad asociados con el software propietario. De esta manera, el uso de sistemas y formatos propietarios va haciendo que el Estado se vuelva cada vez más dependiente de proveedores determinados. Por el contrario, una vez implantada la política de uso de software libre (implantación que, es cierto, implica un costo), la migración de un sistema a otro se hace muy sencilla, ya que todos los datos están almacenados en formatos abiertos. Por otra parte, la migración a un entorno de software abierto no implica más costos que la misma entre entornos distintos de software propietario, con lo que su argumento se invalida totalmente.

El segundo argumento refiere a «dificultades de interoperabilidad de las plataformas informáticas dentro del Estado, y entre el Estado y el sector privado». Esta afirmación implica un cierto desconocimiento de los mecanismos de construcción de software libre, en el que no se maximiza la dependencia del usuario respecto de una plataforma determinada, como sucede habitualmente en el campo del software propietario. Aun cuando existen múltiples distribuciones de software libre, y numerosos programas susceptibles de ser empleados para una misma función, la interoperabilidad queda garantizada tanto por el empleo de formatos estándar, exigido en el proyecto, como por la posibilidad de construir software interoperable a partir de la disponibilidad del código fuente.

Dice luego que:

«9. El software de código abierto en su mayoría no ofrece los niveles de servicio adecuados ni la garantía de fabricantes reconocidos para lograr mayor productividad por parte de los usuarios, lo cual ha motivado que diferentes entidades públicas hayan retrocedido en su decisión de ir por una solución de software de código abierto y se encuentren utilizando software comercial en su lugar.»

Esta observación es infundada. Respecto de la garantía su argumento ha sido rebatido respondiendo el párrafo 4. Respecto de los servicios de soporte, es posible usar software libre sin ellos (así como sucede también con el software propietario) pero quienes los requieran pueden adquirir soporte por separado, tanto de empresas locales cuanto de corporaciones internacionales, también como en el caso de software propietario.

Por otra parte, contribuiría en mucho a nuestro análisis que nos informase acerca de proyectos de software libre implantados en entidades públicas, que a la fecha hayan sido abandonados en favor del software propietario. Conocemos un buen número de casos en el sentido inverso, pero carecemos de información respecto de casos en el sentido que Ud. expone.

Continua observando que:

«10. El proyecto desincentiva la creatividad de la industria peruana de software, que factura US$ 40 millones/año, exporta US$ 4 millones (10mo. en ranking productos de exportación no tradicional, más que artesanías) y es una fuente de empleo altamente calificado. Con una Ley que incentive el uso de software de código abierto, los programadores de software pierden sus derechos de propiedad intelectual y su principal fuente de retribución.»

Esta claro por demás que nadie esta obligado a comercializar su código como software libre. Tan sólo deberá tener en cuenta que, si no lo hace, no podrá venderle al sector público. Este, por otra parte, no constituye el principal mercado para la industria nacional de software. Lineas arriba hemos abordado algunas cuestiones referidas a la influencia del Proyecto en la generación de empleo técnico altamente calificado y en mejores condiciones de competitividad, por lo que parece innecesario insistir aquí en el punto.

Lo que sigue en su afirmación es erróneo. Por un lado, ningún autor de software libre pierde sus derechos de propiedad intelectual, a menos que por su expresa voluntad desee colocar su obra en el dominio público. El movimiento del software libre siempre ha sido extremadamente respetuoso de la propiedad intelectual, y ha generado reconocimiento público extenso a los autores. Nombres como el de Richard Stallman, Linus Torvalds, Guido van Rossum, Larry Wall, Miguel de Icaza, Andrew Tridgell, Theo de Raadt, Andrea Arcangeli, Bruce Perens, Darren Reed, Alan Cox, Eric Raymond, y muchos otros, son mundialmente reconocidos por sus contribuciones en el desarrollo de software que hoy es utilizado por millones de personas en todo el mundo, en tanto los nombres de los autores materiales de excelentes piezas de software propietario, permanecen en el anonimato. Por otra parte, afirmar que las regalías por derechos de autor constituyen la principal fuente de retribución de los programadores Peruanos es en todo caso aventurado, en particular porque no se ha aportado ninguna prueba al efecto ni una demostración de como el empleo de software libre por el Estado influiría en esta retribuciones.

Prosigue Ud. diciendo que:

«11. El software de código abierto, al poder ser distribuido gratuitamente, tampoco permite generar ingresos para sus desarrolladores por medio de la exportación. De esta forma, se debilita el efecto multiplicador de la venta de software a otros países y por lo tanto el crecimiento de esta industria, cuando contrariamente las normas de un Gobierno deben estimular la industria local.»

Esta afirmación demuestra nuevamente un desconocimiento total de los mecanismos y el mercado del software libre. Intenta aseverar que el mercado de cesión de derechos no exclusivos de uso a titulo oneroso (venta de licencias) es el único posible para la industria informática cuando, como Ud. mismo lo ha señalado párrafos arriba, ni siquiera es el más importante. El incentivo que el proyecto presenta al surgimiento de una oferta de profesionales más calificados, en conjunto con el incremento de experiencia que resultará para los técnicos nacionales el trabajar a gran escala con software libre en el Estado, los colocan en una posición altamente competitiva para brindar sus servicios al extranjero.

Señala luego que:

«12. En el Foro se discutió sobre la importancia del uso de software de código abierto en la educación, sin comentar el rotundo fracaso de esta iniciativa en un país como México, en donde precisamente los funcionarios del Estado que fundamentaron el proyecto, hoy expresan que el software de código abierto no permitió brindar una experiencia de aprendizaje a alumnos en la escuela, no se contó con los niveles de capacitación a nivel nacional para dar soporte adecuado a la plataforma, y el software no contó y no cuenta con los niveles de integración para la plataforma que existen en las escuelas.»

Efectivamente, en México se dio marcha atrás con el proyecto Red Escolar. Eso se debió, precisamente a que los impulsores del proyecto mexicano tuvieron al costo de las licencias como principal argumento, en vez de las otras razones estipuladas en nuestro proyecto y que son mucho más esenciales. Debido a este error conceptual, y como consecuencia de la falta de apoyo efectivo por parte de la SEP (Secretaria de Educación Publica) se asumió que para implementar software libre en las escuelas, bastaba con quitarle a éstas el presupuesto para software y en cambio enviarles un CD ROM con GNU/Linux. Por cierto, esto falló y no podía ser de otro modo, tal como fallan los laboratorios escolares en los que se usa software propietario si no hay presupuesto para implementación y mantenimiento. Es precisamente por eso que nuestro proyecto de ley no se limita a indicar la mandatoriedad del uso de software libre, sino que reconoce la necesidad y ordena la creación de un plan de migración viable, en el que el Estado encamine ordenadamente la transición técnica para lograr disfrutar de las ventajas del software libre.

Finaliza Ud. con una pregunta retórica:

«13. Si el software de código abierto satisface todos lo requerimientos de las entidades del Estado ¿por que se requiere de una Ley para adoptarlo? ¿No debería ser el mercado el que decida libremente cuáles son los productos que le dan más beneficios o valor?»

Estamos de acuerdo que en el sector privado de la economía, es el mercado quien debe decidir que productos usar y allí no sería admisible ninguna intromisión estatal. Pero en el caso del sector público, el razonamiento no es el mismo: Como ya establecimos el Estado almacena, manipula y transforma información que no le pertenece, sino que la ha sido confiada por los ciudadanos que, por imperio de la ley, no tienen más alternativa que hacerlo. Como contraparte a esa imposición legal, el Estado debe extremar las medidas para salvaguardar la integridad, confidencialidad y accesibilidad de esa informaciones. El empleo de software propietario arroja serias dudas sobre el cumplimiento de estos atributos, a falta de evidencia concluyente al respecto y por lo tanto no es apto para ser usado en el sector público.

La necesidad de una ley estriba, por un lado, en la materialización de los principios fundamentales antes enunciados en el campo específico del software. Por otro, en el hecho de que el Estado no es una entidad ideal homogénea, sino que esta compuesto de múltiples organismos con diversos grados de autonomía de decisiones. Dado que el software propietario es inapropiado para ser empleado, el hecho de establecer estas reglas en la ley impediría que la decisión discrecional de cualquier funcionario ponga en riesgo la información que pertenece a los ciudadanos. Y, sobre todo, porque constituye una reafirmación actualizada en relación con los medios de tratamiento y comunicación de información empleados hoy en día, sobre el principio republicano de publicidad.

Conforme a este principio universalmente aceptado, el ciudadano tiene derecho a conocer toda información en poder del Estado que no esté amparada en una declaración fundada de secreto conforme a la ley. Ahora bien, el software trata información y es en sí mismo información. Información en formato especial, susceptible de ser interpretada por una máquina para ejecutar acciones, pero sin duda información crucial porque el ciudadano tiene legítimo derecho a saber, por ejemplo, como se computa su voto o se calculan sus impuestos. Y para ello, debe poder acceder libremente al código fuente y probar a su satisfacción los programas que se utilizan para el cómputo electoral o para el cálculo de sus impuestos.

Saludo a Ud. con las expresiones de mi mayor consideración, reiterando que mi despacho siempre estará abierto a que expongan sus puntos de vista al detalle que Ud. crea conveniente.

Atentamente,

Dr. Edgar David Villanueva Nuñez
Congresista de la República del Perú.

Fuentes

• http://www.gnu.org.pe/rescon.html
• http://pimientolinux.com/peru2ms/villanueva_a_ms.html

Referencias

• Proyecto de ley 1609/2001 (Villanueva Nuñez). Ref.: Congreso de la República del Perú
• Facsímil de la carta de Microsoft Peru con objeciones al proyecto de ley 1609/2001 (Copia del proyecto Proposición). Versión de texto (Copia del proyecto Proposición)
• Discusión en Barrapunto: «Proyecto de ley para software libre en Perú»
• Entrevistas con el Dr. Villanueva Nuñez: El Informante (CORPECE) – Linux Journal (en inglés)

Sorpresivamente, también se ha sumado a las mismas el Abogado cordobés Martín Carranza Torres. Se trata del representante local de la Business Software Alliance, quien publica una nota en su blog basada en los argumentos que expone el Doctor Mario Bunge cuando critica la convalidación de las pseudociencias en los ámbitos universitarios (en particular, el de la Universidad Nacional de Córdoba).

Quién es Martín Carranza Torres

Se trata, según puede verse en el sitio de su estudio jurídico de un abogado graduado en la Universidad Nacional de Córdoba que se desempeña como consultor de empresas y agrupaciones relacionadas con el software y los servicios informáticos. En particular, es representante local de la Business Software Alliance (organización que agrupa a las principales empresas productoras y distribuidoras de software privativo).

Martín Carranza Torres se presenta como un especialista en temas de propiedad intelectual, aunque su obra se limita a tres libros (uno de los cuales está dedicado a plantear una supuesta problemática jurídica del Software Libre) y una gran cantidad de notas en diarios y publicaciones no especializadas.

Un punto que es relevante, es que Martín Carranza Torres posee el título de «Abogado». Es una costumbre muy difundida (y aceptada, aunque ya hace tiempo ha comenzado a cuestionarse) en algunas partes del mundo llamar a médicos y abogados como «Doctores» (incluso esto es frecuente en el trato entre ellos mismos). En realidad, «Abogado» es un título de grado universitario (equivalente a una «licenciatura»), en tanto que el de «Doctor» es un título de postgrado. De esta manera, existen abogados y verdaderos doctores en leyes (quienes han realizado aportes originales a las Ciencias Jurídicas). Martín Carranza Torres está, por lo tanto, cuestionando el otorgamiento de un grado académico que él mismo no posee. Comparemos esto con el hecho de que quien presentó el otorgamiento de la distinción fue un reconocido científico, el Doctor en Ciencias de la Computación Javier Blanco y que el pedido de otorgamiento del título fue realizado por cinco Profesores Titulares, que tienen el grado académico de Doctor.

Qué critica Martín Carranza Torres

En el artículo de su blog, Martín Carranza Torres critica el otorgamiento del título de «Doctor Honoris Causa» a Richard Stallman, por parte de la Universidad Nacional de Córdoba. Para ello se basa en una entrevista realizada al conocido filósofo argentino Mario Bunge (quien más que haber escrito un libro de escasas 70 páginas, tal como lo presenta Carranza Torres, ha escrito un tratado de filosofía de 8 tomos). Sin embargo, incurre en varios errores y falacias, algunos de los cuales analizaremos a continuación.

En primer lugar, la referida entrevista trata sobre la iniciativa de crear en la Universidad Nacional de Córdoba una carrera de postgrado en «medicinas complementarias» (incluyendo, entre otras, a la homeopatía). En ella, Bunge abunda en explicaciones sobre por qué no debería permitirse que en una Universidad se otorguen títulos sobre disciplinas «pseudo científicas«. Cabe aclarar aquí que Bunge tiene una postura bastante estricta y rigurosa al respecto: también considera como pseudociencia -y no con pocos argumentos- al psicoanálisis freudiano.

Carranza Torres traslada el planteo de Bunge (referido a las medicinas alternativas) al caso de Richard Stallman, sin establecer ni mucho menos el punto de comparación. Se limita a decir que Stallman es «conocido por sus excentricidades, su aspecto desprolijo y desaliñado, su discurso repetido hasta el cansancio como un mantra y, sobre todo, por sus ‘dogmas’ que pretende erigir como principios de fe mesiánica para fundar una nueva sociedad«. Vamos a suponer que el abogado no llama «macaneador» (tal el término que suele utilizar Bunge) a Stallman por su comportamiento excéntrico, su aspecto personal o su discurso tal vez repetitivo. Analicemos entonces lo único relevante para tal acusación: sus ideas.

¿Cuáles son los «dogmas» que según este abogado hacen de Stallman un charlatán?

Porque para Stallman las empresas de software que ganan mucho debieran ser prohibidas, los programadores de software, caso que no les alcance con su trabajo, debieran trabajar de camareros y todo el software publicado debiera ser liberado para uso de cualquiera sin necesidad de pedir permiso o pagar regalías…

Stallman nunca ha dicho que ninguna empresa deba ser «prohibida» por ganar mucho dinero. De hecho, es difícil pensar cómo tal afirmación podría ser hecha seriamente sin quedar expuesto al ridículo en el acto.

Con respecto a lo de los programadores trabajando como camareros, Carranza Torres parece malinterpretar un chiste que suele hacer Stallman en sus conferencias, cuando recuerda el momento en que sus principios entraron en conflicto con los requerimientos de su empleador y evaluó la posibilidad de dejar la programación y buscar otro medio de sustento. En tal oportunidad, Stallman decidió renunciar a su trabajo, nada menos que en el renombrado Departamento de Inteligencia Artificial del MIT. (¿Se habrá enfrentado alguna vez este abogado a un caso en el que entraran en conflicto sus valores morales y sus intereses económicos?)

Lo que si plantea Stallman es que todo el software publicado debería poder ser usado por cualquier persona u organización, entendiendo por «uso» no sólo la ejecución del programa sino también su análisis, modificación, reutilización y redistribución.

Este último punto, que es la única parte de la acusación de Carranza Torres que resulta algo verosímil, no es afirmado como un «dogma» ni mucho menos como una cuestión de «fe mesiánica». A lo largo más de 20 años Stallman ha producido gran cantidad textos en donde abunda en fundamentos que respaldan su afirmación, principalmente desde el punto de vista ético. Más aún, varios reconocidos juristas (entre los más notables, los Doctores en Leyes Lawrence Lessig y Eben Moglen) han justificado sus afirmaciones y su filosofía desde el punto de vista jurídico y legal.

El currículum vitae de Stallman

Richard Stallman se graduó en física en la Universidad de Harvard en el año 1974. No sólo se trata de una de las universidades más reconocidas del mundo, y dificilmente pueda alguien decir que la «física» no es una disciplina científica bien establecida, sino que obtuvo tu título con la distinción «magna cum laude» (con grandes alabanzas, muy sobresaliente).

A lo largo de su trayectoria como programador y como impulsor de las filosofía del Software Libre, ha obtenido las siguientes distinciones:

• Membresía honoraria de por vida en la Chalmers Computer Society en 1986.
• Membresía en la MacArthur Foundation en 1990.
• Grace Hopper Award de la Association for Computing Machinery en 1991.
• Doctorado Honoris Causa del Royal Institute of Technology, Suecia, en 1996.
• Pioneer Award de la Electronic Frontier Foundation en 1998.
• Yuri Rubinsky Memorial Award en 1999.
• Takeda Award en 2001.
• Doctorado Honoris Causa por la Universidad de Salta, Argentina, en 2004.
• Primer galardonado con el Premio Internacional Extremadura de Conocimiento Libre por Junta de Extremadura en Badajoz, España, en 2007.
• Doctor Honoris Causa de la Universidad de Los Ángeles de Chimbote, Perú, en 2007.
• Doctor Honoris Causa de la Universidad de Pavia, Italia, en 2007.
• Doctor Honoris Causa de la Universidad Nacional de Trujillo, Perú, en 2008.
• Doctorado Honorario en Ciencias en la Universidad de Lakehead, Canadá, en 2009.

Con semejante lista, tal parece que el Abogado Martín Carranza Torres, antes que a la Universidad Nacional de Córdoba, debería primero calificar de poco rigurosas a varias otras instituciones educativas y asociaciones profesionales del mundo.

Conclusión

Dejando de lado su aspecto personal -que puede no ser del agrado de Carranza Torres- no se entiende qué le sorprende tanto a este abogado y, según él dice, también a Bunge (que dificilmente se haya enterado de la nueva aplicación de su entrevista) ante el otorgamiento de esta nueva distinción a Richard Stallman.

La duda que me queda es qué pensará realmente Mario Bunge sobre Richard Stallman, ya que ambos fueron conferencistas en el año 1996 en el marco del 13mo Congreso Mundial de Humanismo «Humanismo Global para la Ciber-Era». Martín Carranza Torres bien podría haber usado Google antes de hacer interpretaciones tan antojadizas.