Si una Administración Pública distribuye un programa libre, tiene cierta responsabilidad con los usuarios del mismo incluso en el caso de que la propia Licencia del programa indique lo contrario, ya que, al contrario que un distribuidor cualquiera, una A. P. sí tiene una obligación legal real de velar por los receptores del programa, que son sus ciudadanos. Dicha responsabilidad puede ser mayor aún en el caso de que el usuario del programa sea la propia A. P. de modo tal que un problema en el programa suponga para aquélla la pérdida de datos de los ciudadanos o cualquier otro resultado que les perjudique.
Al mismo tiempo, crear un programa al modo de los proyectos libres implica que varias personas (los desarrolladores en quienes se tiene confianza suficiente como para permitirles acceso de escritura al repositorio), algunas de las cuales no tendrán ningún tipo de relación contractual directa ni indirecta con la A. P. que promocione el programa, podrán realizar cambios al mismo, algunos de los cuales pueden ser perjudiciales, bona fide o maliciosamente.
Parece entonces que llegamos al dilema cruel de que una A. P. debe renunciar a liberar un programa y desarrollarlo a través de una comunidad o aceptar la responsabilidad de un programa que no se encuentra bajo su control.
Sin embargo, se trata de un falso dilema, ya que hay un paso intermedio entre el desarrollo y la publicación, que es el punto en el que la A. P. puede intervenir a fin de controlar el proceso conforme a su responsabilidad sin correr el riesgo de molestar a la comunidad de desarrolladores con injerencias. Dicho punto es la liberación de versiones oficiales del programa.
El flujo de trabajo correcto para bordear adecuadamente el problema es:
- que los desarrolladores trabajen libremente, hasta el punto en que tal cosa sea posible para que el programa no se aleje de las especificaciones, en el repositorio de código
- que un grupo seleccionado de desarrolladores, responsables ante la A. P. (funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.), seleccione regularmente el código de la rama «tronco» del repositorio, lo empaquete (a modo de paquete fuente o de paquetes fuente y binario) y lo publique
De este modo, los usuarios que lo deseen pueden obtener las versiones de desarrollo del código, lo cual es imprescindible para la detección de fallos en el mismo y su mejora, sin responsabilidad para la A. P., y ésta puede proporcionar versiones oficiales que hayan pasado el filtro de los desarrolladores contratados, con plena responsabilidad.
Es conveniente, pero no necesario, que la distinción entre estas dos maneras de proporcionar el código sea patente en la interfaz web del repositorio de código, con una mención del tipo «[La A. P.] no se hace responsable de los posibles fallos de estas versiones de desarrollo y niega toda responsabilidad sobre el mismo. Si no es usted un usuario avanzado, por favor utilice las versiones oficiales que puede encontrar en [sitio web].».
Ante un problema real que se produzca como consecuencia del uso del código, la estrategia de defensa de la A. P. debe variar en función de que dicho fallo se produzca en un código obtenido del repositorio o en un programa de la distribución oficial.
En el primer caso, la A. P. debe negar toda responsabilidad, indicando que el usuario sabía lo que hacía al descargar una versión de desarrollo, e indicando que el usuario asumió toda la responsabilidad al usar la interfaz web del repositorio de desarrollo del código (si lo hizo así) o indicando que el usuario era plenamente consciente del peligro de utilizar una versión de desarrollo, ya que es inconcebible que un usuario lo suficientemente avanzado como para utilizar el repositorio sin usar su interfaz web no lo sea.
En el segundo caso, la A. P. debe aceptar la plena responsabilidad por el perjuicio causado, ya que es, al menos, responsable civil subsidiario, pero al mismo tiempo debe averiguar qué desarrollador aceptó el cambio en el código que causó el problema e iniciar las acciones penales y, en su caso, disciplinarias adecuadas, ya que sin duda se trata de uno de los «desarrolladores de confianza» plenamente identificados por ser funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.
2 comentarios:
No sé, no sé ...
Sin reflexionar demasiado (que son las 02:23 de la mañana), yo propondría un modelo ligeramente diferente, que funcionaria de la siguiente manera:
* Cada A.P. tendría su repositorio de desarrollo, en donde unicamente tendrían permiso de escritura los programadores de confianza (bien directamente funcionarios, o bien subcontratados).
* Los repositorios deberían tener acceso anonimo activado, de manera que cualquier persona pudiera descargarse una copia de dicho repositorio.
* Los programadores ajenos a las A.P. que quisieran contribuir, podrían mandar los parches que quisieran, quedando en manos de los técnicos de la A.P. si aceptarlo o no.
Con este modelo, creo que todos estaríamos contentos y seguros, ya que el código puede ser auditado y reutilizado (cierto, no hemos hablado de licencias) y al mismo tiempo, las A.P. mantienen el desarrollo '''acotado'''.
No sé, ya digo, pero al menos para mi me parece suficiente...
Saludos
Luis
Hola lcabrera:
En breve leerás la segunda parte de mi artículo, más centrado en los detalles técnicos, pero quería explicarte que este artículo se basa en la premisa de que el desarrollo se produce con un modelo de comunidad abierto, precisamente sin que haya un grupo exclusivo de programadores.
Publicar un comentario