en Regulación

Un Derecho de código abierto

El movimiento del software de código abierto u open source, que surgió formalmente a inicios de los noventas y del que todos nos beneficiamos a diario al usar Internet, tiene muchísimo que enseñarnos a los abogados. [1] Al establecer sus principios, sus creadores no solo intentaban resolver el problema de cómo distribuir el software sino también el de cómo crearlo, mantenerlo y mejorarlo en forma colaborativa a lo largo del tiempo. En su aproximación hacia estos desafíos sentaron las reglas de un sistema de colaboración que ha sabido mantenerse por algunas décadas y ha influenciado otros espacios como la investigación científica, la producción cultural y hasta la moda. De espaldas a esta revolución, los operadores jurídicos nos hemos mantenido fieles a un sistema de producción normativo sacado de una época en que la circulación de información y la participación ciudadana eran totalmente distintas.

Este ejercicio parte de entender las políticas públicas expresadas en leyes como un software de código abierto. Resulta obvio que son dos géneros distintos pero tienen en común que ambos plantean resolver un problema, son (idealmente) producto del trabajo colaborativo y van a ser usadas por muchas más personas de las que participaron en su creacíón. Aplicando la metodología y las reglas que corresponden a los programas de código abierto a las leyes podemos apreciar diferentes aspectos de la producción y mantenimiento del software que podrían mejorar considerablemente nuestro proceso de producción de leyes.

El primer asunto relevante es la cultura de la sana imitación. El software de código abierto es creado no solo para ser usado por todos sino también para ser imitado y modificado. En este punto, a veces nuestro Congreso puede ser un campeón al momento de copiar leyes de otros países. Sin embargo, el fork o la modificación de un software para ser usado en otro contexto parte de entender el producto anterior, reconocer sus limitaciones y explotar sus potencialidades hacia una nueva finalidad. Respetando esta ética, si en Perú tenemos un problema que puede solucionarse con una ley salvadoreña o boliviana antes de proponer su implementación local deberíamos de ser conscientes de la historia legislativa de dicha disposición en su país de origen, de la estadística sobre su aplicación y de la forma en la que esta nueva norma se relacionaría con nuestra estructura legal. Esa es la sana imitación.

En relación con el primer punto, uno de los aspectos más valiosos de un software de código abierto que ha alcanzado su madurez es la calidad de su documentación. La documentación en el contexto de un software es un manual que acompaña el programa y explica en detalle los requisitos que necesita, el diseño o arquitectura de su funcionamiento, cómo funciona cada uno de sus componentes e incluso también puede incluir instrucciones para el usuario final. A cambio, nuestras leyes en el mejor de los casos solo tienen un informe previo (que casi siempre es secreto), una exposición de motivos que es redactada solo para cumplir con la formalidad y, en el mejor de los casos, un reglamento que intenta salvar la brecha entre lo normado y lo operatibizable pero termina complicándolo todo. Existen disposiciones legislativas que están mucho más documentadas, como las tributarias, pero sería ideal que ese mismo estándar de documentación fuese de obligatorio cumplimiento para todas las demás leyes de carácter general. Esta práctica también ayudaría a otros estados o gobiernos (incluso a nivel regional o local) a poder tomar una decisión mejor informada la momento de decidir incorporar esas leyes dentro de su legislación nacional.

Otro aspecto crucial que nuestro sistema de producción legislativo necesita aprender del software de código abierto es no tenerle miedo a la contribución. Por definición, cualquiera puede participar de un proyecto de código abierto y aportar soluciones, cambios o nuevas funciones que pueden ser incorporadas como oficiales en futuras versiones del software. En nuestro contexto, las leyes son vistas como un producto terminado y se cambian o se amplían casi siempre de manera inorgánica. No son la respuesta a la contribución externa de los ciudadanos sino una decisión vertical de algún operador jurídico autorizado que se limita a consultarla con sus pares antes de aprobarla. El software de código abierto asume honestamente que todo producto es perfectible y establece claramente las vías para la contribución externa, ya sea a través de la posibilidad de reportar bugs como a través de sistemas de control de versiones distribuidos que aceptan pull requests.

Finalmente, quizás la mejor enseñanza de la producción de software en general es la idea del beta o del periodo de prueba. Los productores de software reconocen que durante los primeros meses de uso de algún programa siempre van a existir errores y cosas que solucionar. Por eso, a menudo no solo lanzan productos en beta antes de las versiones estables sino que establecen plazos fijos de revisión en los que volverá a evaluarse la solvencia del código para resolver los particulares problemas planteados. Siguiendo esta mecánica, muchas de nuestras leyes podrían beneficiarse mucho si primero fuesen probadas dentro de jurisdicciones particulares o periodos de tiempo determinados. Luego de esta fase, y tras considerar los reportes de incidencias y los aportes de mejoras, tendría que existir una obligatoria revisión que permita volver a examinar si es que sigue siendo idóneo introducir esas normas. Incluso, podrían plantearse periodos de revisión obligatoria luego de dos o tres años de implementada una norma con la finalidad de comprobar si es que sigue siendo útil o si es que ha resuelto el problema planteado. Muchas normas que se aprueban simplemente por dar una respuesta política pero que nunca llegan a usarse porque son demasiado vagas o imposibles de aplicar bien podrían resultar derogadas luego de este periodo.

Un sistema legal que imite la producción de software de código abierto reduciría la brecha entre la ley y el ciudadano. Si encontramos algún error de traducción en Firefox, existe un mecanismo claro e inmediato para proponer una traducción alternativa o hacer notar el problema. De la misma manera, un ciudadano o un colectivo de ellos debería de sentirse empoderado formalmente para poder contribuir en la producción y revisión legislativa. Ver al sistema de producción legal con estos ojos nos ayudaría a cumplir la premisa según la cual las leyes son un auténtico producto de la sociedad y en constante evolución. 


  1. Estoy al tanto de que existe una diferencia ideológica entre software libre y software de código abierto que ha sido objeto de un debate encendido por muchos años. Sin embargo, para fines de este ensayo he elegido el término “código abierto” porque me interesa referirme a los aspectos metodológicos del desarrollo y no a su trasfondo filosófico.  ↩

Comentar

Comentario