? · english · español  



Respuesta del senador Conde a la CESSI Argentina






Fuente: Referencias:




La Plata, 28 de noviembre de 2002

Señores:
Cámara de Empresas de Software
y Servicios Informaticos


De mi consideración:


Ante todo, agradezco su carta del 4 de octubre del 2002, en la que queda manifiesta la posición oficial de CESSI respecto del proyecto de ley E-135/02-03, referido a la utilización de software libre para el sector público de la Provicia de Buenos Aires. Dicha carta, en la que me place encontrar el explícito reconocimiento de las bondades del software libre, constituye un valioso aporte a la discusión de dicho proyecto. Con ese mismo espíritu me permito contestarles esperando aclarar algunos malentendidos, fomentar la continuidad del respetuoso intercambio de ideas sobre el uso de la tecnología en el sector público, y analizar algunos aspectos de esta iniciativa que su nota no contempla.

A los fines de este intercambio de ideas, daré por supuesto que las menciones que se hacen en el texto de su nota al "Estado Nacional" son producto de un error involuntario. Los alcances del Proyecto de Ley E-135/02-03, cuando resulte aprobado, se limitan al sector público de la Provincia de Buenos Aires.

Permítanme comenzar tranquilizándolos respecto de los dos items específicos que la citada misiva destaca como origen de vuestra oposición al proyecto. Ambos temores son injustificados, ya que el proyecto:

  1. no propone eliminar a nadie de la lista de proveedores del Estado. Por el contrario, el lenguaje ha sido cuidadosamente elaborado de manera que nadie quede excluído de la posibilidad de proveer al Estado, fijando al mismo tiempo condiciones claras e igualitarias para todos los interesados en hacerlo. Es cierto que quienes no deseen atenerse a esas condiciones, no podrán obtener contratos con el Estado, pero no es prerrogativa de los proveedores el dictar a sus clientes los términos en los que deben contratar.

  2. no crea ningún régimen de excepción, sino que, por el contrario, sienta las bases para que las futuras licitaciones de informática se vean libradas de la situación actual, en la que el software y el hardware a contratar se especifican por lo general con marca y modelo, o en su defecto exigiendo características que solo un proveedor está en condiciones de suministrar. Esta distorsión puede considerarse, en realidad, un régimen de excepción de hecho respecto del resto de las licitaciones del Estado, y su eliminación es uno de los efectos secundarios beneficiosos del proyecto.

Habiendo aclarado ambos puntos, debo mencionar que la redacción de su nota, centrada en aspectos comerciales y tecnológicos, parece haber sido redactada sin tener en cuenta la fundamentación, el espíritu y el texto del proyecto de ley. Vuestras objeciones serían válidas si el proyecto exigiera el uso del software libre basado en estimaciones de costo o de funcionalidad tecnológica, características a menudo difíciles de cuantificar y, por lo demás, variables en el tiempo.

Sin embargo, los fundamentos del proyecto de ley mencionan esos aspectos meramente como beneficios marginales, reconocen que no están presentes en todos los casos, y argumentan que, aún en aquellos casos en los que el uso de software libre implique mayores costos y/o funcionalidad más restringida, el Estado debe evitar usar software propietario, porque hacerlo pone en riesgo el adecuado cumplimiento de su misión.

Para mejor comprender esto, debemos recordar que la misión de la gestión informática por parte del Estado no es producir documentos bellos, ni crear sitios WWW animados (tareas que, por cierto, son realizables tanto con software libre como propietario), sino ser el guardián del registro público: mantener información actualizada y correcta acerca de la identidad y el patrimonio de los ciudadanos, de su interacción con el ciudadano, de su propio accionar, etc. Para cumplir adecuadamente con esta misión a través del uso de tecnologías de informática y comunicaciones, el Estado debe de preservar tres aspectos esenciales:

  1. Seguridad. En particular, el Estado debe extremar medidas para que sólo las personas autorizadas tengan acceso a los datos, y al mismo tiempo garantizar que el acceso por parte de estas personas no pueda ser denegado por terceros.

  2. Perennidad. El Estado administra datos cuya vida útil a menudo se mide en cientos de años, por lo que debe existir garantía de que los datos estarán disponibles y serán accesibles por períodos muy largos de tiempo.

  3. Transparencia. El Estado tiene la obligación de publicar todos sus actos, salvo aquellos cuya divulgación pueda afectar negativamente la seguridad nacional o el bienestar de sus ciudadanos.

Si el Estado, en su afán de usar la tecnología más barata o más moderna, descuidara alguno de estos principios, estaría fallando en el cumplimiento de su misión.

La incompatibilidad entre el modelo de licenciamiento propietario y los principios de seguridad, perennidad y transparencia, proviene de la prohibición expresa, o de las insuperables restricciones de orden práctico que representa el mecanismo propietario para llevar a cabo las tareas que permitan fiscalizar y asegurar el cumplimiento de dichos principios. Algunas de las tareas requeridas son:

  1. Auditoría de la función del programa. Sin esta facultad, en la amplísima mayoría de los casos dificultada, cuando no expresamente prohibida por el modelo de licenciamiento propietario, es imposible garantizar ninguno de los tres aspectos mencionados anteriormente.

    1. Seguridad: existe en círculos académicos el debate acerca de si el software libre es inherentemente más seguro que el propietario, pero no es de esperar que esta cuestión si dirima a corto plazo. Sí existe consenso, sin embargo, sobre el hecho de que es muchísimo más sencillo esconder código malicioso (puertas traseras, bombas de tiempo, etc.) en sofware cuyo código fuente no está disponible públicamente que en software que puede ser inspeccionado por cualquier persona interesada, y existe numerosa evidencia de funcionalidad escondida en incontables programas propietarios, aún en aquellos producidos por las empresas más prestigiosas.

    2. Perennidad: sin la posibilidad de analizar el código fuente, también es imposible determinar si el autor del sistema incluyó mecanismos de inhabilitación temporales o remotos que puedan comprometer la posibilidad de acceso a los datos en el futuro. Asimismo, al usar software propietario, el usuario almacena sus datos mediante el uso de software desconocido, en un formato desconocido. Sin la posibilidad de inspección, es imposible saber si el formato utiliza tecnologías sujetas a patente o derechos de autor, que pudieran resultar en que el acceso a esa información en el futuro dependa de la posesión de las licencias correspondientes.

    3. Transparencia: cuando el Estado utiliza software como soporte operativo de sus procedimientos, el mismo pasa a ser parte indisoluble de dichos procedimientos, y por lo tanto está sometido al requerimiento de publicidad de los actos de gobierno. El Estado no puede, en estos casos, utilizar software cuyo código fuente no esté públicamente disponible, sin violar principios constitucionales básicos relegados en la Constitución Nacional y en la Constitución de la Provincia de Buenos Aires.

  2. Mejoría de la función del programa. Con un programa licenciado bajo el modelo propietario, sólo su autor original tiene la facultad de corregir errores, agregar funcionalidad, o quitarla. Además de la obvia e inaceptable dependencia de un único proveedor que esta restricción implica, esto implica que el Estado queda sin curso aceptable de acción en muchas situaciones. Algunos ejemplos:

    1. ausencia, o demora en la corrección de problemas: las prioridades del proveedor de software no son necesariamente las mismas de sus clientes. Si determinado problema de seguridad de un programa no está en la lista de prioridades del proveedor, o si éste se rehúsa a corregirlo o exige una compensación desmesurada para hacerlo (por ejemplo, exigiendo el pago de un upgrade), el Estado no tiene siquiera el recurso de utilizar sus propios medios para obtener una corrección por parte de un tercero.

    2. incompatibilidad con versiones previas: son conocidos los casos de versiones "mejoradas" de programas que tienen problemas leyendo datos de versiones anteriores. El cortísimo ciclo de obsolescencia del software, motivado mucho más por razones de marketing que por efectiva demanda de nuevas funcionalidades, obliga a los usuarios a mantener su software actualizado, y el precio de la actualización incluye (a menudo sin en conocimiento de los usuarios) la renuncia a acceder a datos valiosos almacenados en archivos.

    3. incongruencia entre el software y la ley: el Estado usa el software para implementar el mandato de la ley. El problema es que cuando existe un conflicto (fruto, quizás, de una diferencia de interpretación) entre el texto de la ley y la función del programa, el ciudadano se encuentra con que el software es más poderoso que la ley, ya que es aquél el que gestiona su trámite, y la solución del problema depende de que el proveedor del programa esté dispuesto a corregirlo, y a hacerlo en un tiempo, forma y presupuesto razonables.

    4. desaparición del proveedor o del producto: abundan los ejemplos de programas propietarios cuyos usuarios se vieron obligados a emprender costosísimas migraciones debido a la quiebra del proveedor, a su adquisición por otro más grande, o a la simple discontinuidad del producto por decisión unilateral del autor.

  3. Preservación de la neutralidad tecnológica. al emplear software licenciado bajo el modelo propietario, el usuario renuncia a la facultad de tomar ciertas decisiones, ya que éstas le son dictadas por el autor del programa. Estas decisiones van desde la plataforma de hardware (ya que el autor decide sobre qué plataformas ofrecerlo) hasta los programas a usar para tareas relacionadas (ya que el autor se asegura de que sus productos funcionen mejor, cuando no únicamente, al interactuar con otros de su misma factura). Esto lleva a dificultades para garantizar la perennidad de los datos, ya que la obligación de acompañar al proveedor en sus decisiones puede llevar a situaciones insostenibles (por ejemplo, a través de una carrera desenfrenada de actualizaciones de hardware). De la misma manera, la elección de determinado software propietario por parte del Estado limita la libertad de elección de ciudadano en materia de los productos que puede usar para interactuar electrónicamente con la administración pública, lo que constituye una violación de la igualdad de los ciudadanos ante la ley.

  4. Prestación de servicios independiente de detalles de licenciamiento. La prestación de los servicios del Estado no es optativa, ni admite demoras ni obstáculos. Los distintos modelos de licenciamiento propietario son fuente constante de confusión acerca de la legalidad de usar cierto programa para determinado propósito, en determinada computadora, por parte de un de un determinado grupo de usuarios, situación que se complica significativamente cuando hablamos de usar una combinación de varios programas. Esto conforma un grave riesgo a la continuidad de la prestación de los servicios, ya que un malentendido sobre términos de licenciamiento, un cambio en éstos, su caducidad o una suba de precios pueden llevar a que el Estado deba suspender la prestación de un servicio por carecer de las licencias necesarias.

Quisiera señalar tres aspectos de este análisis, por cierto incompleto:

  1. ninguno de los casos citados tiene interés meramente académico, sino que todos ellos son ejemplos concretos de problemas que se presentan en la práctica cada vez que la administración pública utiliza software licenciado bajo el modelo propietario, y ante los cuales el Estado, privado de una alternativa legítima de acción, termina actuando de manera desfavorable a sus propios intereses, y a los de los ciudadanos.

  2. dado que la ausencia de estas facultades no tiene su origen en características técnicas de los programas en cuestión, sino que surge directamente del modelo de licenciamiento propietario, es inmediato concluir que el modelo de licenciamiento es mucho más importante que el precio o las características técnicas, por lo que su sugerencia de dejarlo de lado como criterio prioritario de evaluación sería una irresponsabilidad por parte de la administración pública.

  3. La única manera mediante la cual el Estado puede utilizar software para llevar a cabo a conciencia su rol de guardián del registro público es a través de la aplicación de programas cuya licencia no afecte las facultades necesarias, es decir que le permita, sin límite en el tiempo ni en la cantidad ni tipo de computadoras, ejecutar, estudiar, corregir, mejorar, ampliar y adaptar el programa de acuerdo a sus necesidades, y no las del proveedor. No escapará a la atención de ustedes que precisamente esas son las facultades que las licencias libres otorgan.

Por cierto, si bien estoy convencido de que el respeto de los derechos del ciudadano es un principio superior a las consideraciones comerciales, éstas también han sido consideradas cuidadosamente a la hora de redactar el proyecto. De su lectura surge claramente que nadie está obligado a entregar al Estado sus productos y servicios libre de cargo. Los montos de las contrataciones están deliberadamente fuera del marco del proyecto, dejando este aspecto liberado a la acción del mercado. También quiero tomar excepción respecto de la afirmación de vuestra carta de que el Estado tiene la misma libertad de acción en materia económica y tecnológica que cualquier otro usuario. Muy por el contrario, las contrataciones del Estado deben respetar normas mucho más restrictivas que las que debe cumplir una entidad privada. Eso se debe, nuevamente, a que la misión del Estado es muy distinta de la de el resto de las entidades que componen la sociedad, y por lo tanto todas sus acciones deben reflejar esa misión y esas diferencias.

Adicionalmente, como ustedes lo señalan muy claramente, el Estado Provincial tiene la capacidad y el derecho de optar por soluciones de software libre en cuantas ocasiones lo considere conveniente. Esta capacidad, y este derecho, no son distintos en el fondo de los que tiene cualquier persona, o cualquier empresa, de fijarse una política respecto de la tecnología de información que emplea. Ahora bien, en función de los principios esenciales que he sintetizado más arriba, estas ocasiones son todas aquellas en que sea posible emplear software libre. Y corresponde a la rama legislativa, en tanto representante del conjunto de las voluntades de los electores, fijar los lineamientos fundamentales de políticas públicas a través de las leyes.

Me alegra enormemente, por cierto, la brillante perspectiva que vuestra carta vaticina para el software: un crecimiento proyectado del 60% en puestos de trabajo, en una coyuntura económica en la que se espera, con mucho optimismo, un crecimiento del 6%, es por cierto un objetivo muy alentador. Más aún, estoy convencido de que el proyecto E-135/02-03 encierra en sí, lejos de una amenaza, una gran oportunidad para alimentar ese crecimiento: un análisis de la lista de los 149 miembros que integran su organización muestra que muchos de ellos se dedican, en forma prominente o exclusiva, a la prestación de servicios. En consecuencia, una Ley como la proyectada resultaría particularmente beneficiosa para sus miembros, pues se les abre la posibilidad de competir libremente en la prestación de servicios asociados con el software libre, sin más requisito que la idoneidad.

El argumento principal que manifiesta su nota es que "el Estado debe elegir sus proveedores en base a los méritos de sus productos [...] y no discriminarlos por su modelo de licenciamiento de productos." Quizás sea necesario repetir aquí que el proyecto no discrimina entre proveedores. El hecho de comercializar programas mediante el modelo propietario no descalifica a ninguna empresa como potencial proveedor del Estado, siempre y cuando los términos de sus contratos con el Estado se atengan a las condiciones previstas por el proyecto.

Por otra parte, compartimos ampliamente la convicción de que el Estado debe escoger el software que emplea en función de su mérito. Pero el mérito del software es, sin duda, una percepción relativa del usuario. Así, por ejemplo, para un usuario con dificultades de visión o de motricidad será practicamente indispensable software con interfaz vocal; y al mismo tiempo este software carecerá de mérito (y probablemente resulte inútil) para un usuario con dificultades auditivas. En concordancia con ello, el software más meritorio para el Estado es el que permita hacer efectivas las garantías de seguridad, perennidad y transparencia previamente mencionadas, haciendo así posible el cumplimiento de la misión de las instituciones públicas. Ahora bien, como he señalado anteriormente, el modelo de licenciamiento propietario es incompatible con la preservación de esas garantías, y por lo tanto el tratamiento diferencial entre programas propietarios y libres en la administración pública se vuelve inevitable.

Saludo a Uds. expresándoles nuevamente mi agradecimiento por el aporte a la discusión, e invitándolos a continuar el debate para el beneficio de toda la sociedad.

Atentamente,

Senador Alberto Conde (UCR)

H. Cámara de Senadores
Provincia de Buenos Aires

 


Hospedado por GrULiC Valid HTML 4.01! Última modificación: 10/11/03