Guía de adquisición de software para gobiernos y grandes organizaciones


8 de marzo 2005

Versión 0.28

Se puede encontrar la última versión de éste trabajo en sus diferentes formatos y sus fuentes en:
http://www.hipatia.info/docs/diccionario/ o en o en http://bo.unsa.edu.ar/docacad/softwarelibre/articulos/

Primera versión: 20 de febrero del 2005

Archivo Postscript: diccionario.ps, archivo PDF: diccionario.pdf, fuentes: diccionario.tar.bz2.

Diego Saravia

http://www.ututo.org/dsa

mailto:dsa@unsa.edu.ar.
Inenco; Dpto. Física; Fac. Cs. Exactas; Universidad Nacional de Salta.
Hipatia: http://www.hipatia.info
Solar: http://www.solar.org.ar

Necesidad

Ya que los gobiernos:

Parece necesario discutir cuales son las pautas para la adquisición de software en este tipo de organizaciones. Esta guía pretende ser una ayuda para aplicar correctamente las normas públicas en la adquisición de software.

El software -que no sea del derecho público o sin copyright- se adquiere mediante contratos entre el usuario y el derecho-habiente del mismo. Es fundamental definir claramente este tipo de contrato en los pliegos de adquisiciones. Los estados no tienen porque aceptar contratos de adhesión, tal cual es la costumbre ahora. A medida que se termine con el Monopolio de Microsoft -tarea de los gobiernos- será posible mejorar las condiciones de adquisición.

Adquirir software no implica necesariamente una compra, puede adquirirse sin necesidad de ningún trámite, como suele suceder con el Software Libre. Habitualmente se lo baja de Internet. Otras veces tendrá, -aún para software libre-, que contratar servicios para grabar cds, empaquetar manuales, instalarlo, configurarlo, adaptarlo, formar a su gente, etc..

Se debe tener claro y separar correctamente, que son varios los items habitualmente involucrados en la adquisición de software: adquisición de derechos de uso (para el software libre, con el hecho de bajarlo de Internet habitualmente se lo adquiere), contratación de servicios diversos vinculados: instalación, medios de distribución (cds, dvds, etc.), manuales, configuración y adaptación, cursos de formación, etc..

Entonces, ante la necesidad de software, la primera consideración, es si es necesario realizar un trámite formal de adquisición de derechos, sea por pedido de precios, o licitaciones. O directamente se instruye a las oficinas técnicas correspondiente para utilizar software libre disponible en repositorios públicos.

Sólo cuando se requieran servicios adicionales o se necesite software no disponible por esta vía, sera pertinente recurrir a procesos formales de adquisición. Así podrá decidirse crear software nuevo, ya sea por personal propio o contratado, o adquirir derechos para usar, inspeccionar, modificar y redistribuir software preexistente. Sólo en éste último caso será necesario un proceso formal de adquisición.

Debe tenerse en cuenta el costo de este proceso: convocatoria, compulsa, impugnaciones, y luego el costo de mantener la infraestrutura legal y de auditoría del correcto uso del software con restricciones privativas.

Leyes y Normas

No siempre sera necesaria una ley especial para regular la adquisición de software por los estados. Puede ser recomendable modificar las normas vigentes sobre compras, fijar una política de estado, adaptar las normas técnicas, o ``instruir'' a los funcionarios. El instrumento a adoptar dependerá de la cultura política de cada país: una ley, un decreto, una resolución, o simplemente una formación adecuada para los responsables de las adquisiciones en cada oficina.

Han existido casos de planteos judiciales de inconstitucionalidad sobre normas legislativas que disponen el uso obligatorio de Software Libre, o simplemente lo promueven. El fundamento de tales planteos es que las normas discriminarian a las ``empresas de software privativo''. En realidad estos planteos no tienen fundamento pues cualquier proveedor puede ofertar su software con la licencia que le pidan. Ni las empresas de software, ni el mismo software, son libres o privativos por sí. Es cada contrato entre cada usuario y cada derecho-habiente el que fija como se licencia cada software en determinada situación.

Pero por otro lado el plantear las leyes de esta forma es invitar a una acción de inconstitucionalidad. La recomendación es que las normas -sean leyes o normas técnicas u otras- no especifiquen sus requerimientos imponiendo un modelo de licenciamiento concreto o incluso una categoría o conjunto de modelos concretos, sino que se especifiquen los requerimientos legales que sean convenientes para el estado: indicando libertad de instalación en todas las máquinas, libertad de inspección, modificación, compilación, distribución, etc.. Lo mismo en cuanto a los efectos, pero redactado en forma diferente.

Sí es necesaria una ley, para administrar el derecho intelectual del estado, los copyrights que este tiene y el tipo de restricciones que establece a terceros sobre los programas de los que es derecho-habiente. Así debe fijarse por ley:

Requisitos en los pliegos de condiciones y/o normas técnicas

  1. Comprar las mayores cantidades posibles. Un principio de la compra pública indica que se deben juntar los requerimientos de muchas oficinas en uno solo pedido para mejorar las condiciones de compra.

    Como existe software que debe ser usado en ``todo el estado'', conviene adquirirlo de una sola vez para cada ``estado'', en cada período de tiempo.

    Se recomienda especificar en el contrato que regule la adquisición (en particular el licenciamiento) que el software podrá ser instalado en todas las computadoras del estado sin límite y que el precio ofertado incluye esa posibilidad.

  2. No adquirir hardware y software juntos o en forma combinada.

    Un buen software se caracteriza por ser compilable en muchas arquitecturas. Adquirir software que pueda funcionar en muchos tipos de máquinas, permitirá al gobierno que cuando cambie la tecnología de hardware sus inversiones en software puedan seguirse usando, con mínimos cambios.

    Los pliegos de condiciones de las licitaciones de hardware indicarán que los equipos se entregarán sin software. Y que el software sera instalado por el estado o mediante contratos separados bajo estricta supervisión del estado.

    Esto garantiza que se recibe y resguarda todo el software necesario para operar y para reinstalar si se requiere. No existirán drivers ocultos que luego no se puedan conseguir.

    En las adquisiciones de licencias de software se debe especificar que éste deberá operar en toda la gama de equipos que el estado usa y que puede llegar a usar. Se debe pedir código fuente que pueda ser recompilado en diferentes arquitecturas. Siempre será mas fácil añadir una nueva arquitectura a un software que funciona en varias, que convertir un software mono-arquitectura en multi-arquitectura.

    Así se podrá mover el software de una computadora a otra.

    Durante la vida útil de un equipo suele ser necesario instalar varias veces diversas versiones del mismo software.

    Este es un principio de toda compra pública, separar lo más posible las compras, no favorecer las combinaciones de productos y la formación de monopolios cruzados del estilo Intel-Microsoft.

  3. Conviene separar la prestación de servicios de mantenimiento o instalación, de la adquisición de licencias. De esta forma muchos proveedores podrán competir en este rubro. Se propendrá la existencia de proveedores que puedan manejar entornos diversos de software.

  4. Se debe especificar que se debe proveer el código fuente y el derecho a adaptarlo y recompilarlo. Esto es necesario por varios motivos, en primer lugar para saber que hace el software en cuestión y poder auditar su real función. Luego para poder modificarlo y adaptarlo en condiciones cambiantes, sin depender de contratos particulares con la empresa proveedora. Luego para poder adaptarlo a nuevas arquitecturas, de haber obsolescencia tecnológica.

  5. Se debe especificar que el estado debe poder redistribuir ese software a otras personas jurídicas. Pues así podrá usarlo en programas de gobierno electrónico, educación publica e interacción con los ciudadanos.

  6. Las licencias no pueden caducar en determinado período de tiempo.

  7. Se debe inventariar las licencias de software por separado del hardware y llevar un estricto control de donde y como se usa cada licencia privativa. Un ejemplo:``Registro de programas de uso restringido, UNSa''[2].

  8. Los estados deben designar a los responsables de mantener a resguardo los medios de instalación, las facturas y las obleas o certificados cuando se compran licencias privativas. Se deberá prever si los manuales quedan con el usuario o van a bibliotecas comunes.

  9. Se debe instruir a las auditorías y organismos de contralor para que informen sobre incumplimientos a estas normas, realicen planes sistemáticos y periódicos de control e impulsen los sumarios correspondientes.

    Este trabajo es muy costoso, pero indispensable en caso de usar software privativo.

  10. Se debe indicar claramente a los funcionarios del estado, que usar software ilegal implica sumarios, y que no se debe regularizar software por acuerdos privados con empresas, sin iniciar causas penales a los responsables de la violación de la ley en primer lugar. Tampoco es legal contratar planes globales o realizar acuerdos de éste tipo sin licitación pública.

  11. No se debe indicar marcas en las especificaciones de los pliegos o normas técnicas. Windows, es una Marca, GNU/Linux es una marca. Se debe especificar requerimientos necesarios o convenientes, sean técnicos, económicos o contractuales de licenciamiento. Todo lo que se pida debe ser directamente vinculable a las necesidades del organismo.

  12. No se debe solicitar productos que sólo son necesarios para una marca en particular, por ejemplo productos antivirus. Pedir que estos productos sean parte del item particular en que esa marca puede concurrir.

    Así se debe solicitar sistemas operativos que garanticen un razonable funcionamiento sin virus. Así quien provea Windows, deberá entregar y hacerse responsable de solucionar estos problemas típicos de esta plataforma entregando sistemas antivirus y firewalls.

Derechos y estándares

Este documento:

puede ser utilizado por cualquiera bajo los términos de la GFDL. No contiene secciones invariantes;

VALID HTML 3.2! cumple los estándares de la w3c.

Bibliografía

1
Diego Saravia y Comunidad de Hipatia.
Software libre en la administración pública: Desafíos y oportunidades, 2003.

http://bo.unsa.edu.ar/docacad/softwarelibre/articulos/ica

http://www.hipatia.info/docs/dsl.

2
UNSa.
Resolución 326/2001 sobre el uso de software.

http://bo.unsa.edu.ar/dr/R2001/R-DR-2001-0326.html.

Sobre este documento...

This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -init_file latex2html-init main.tex

The translation was initiated by root on 2005-03-08




Diego Saravia, dsa@unsa.edu.ar