
Código abierto (del inglés open source) es el término con el que se conoce al software distribuido y desarrollado libremente. En la actualidad open source es utilizado para definir un movimiento nuevo de software (la Open Source Initiative).
Este término cada vez se utiliza más para todo aquello que no es software pero que persigue esta misma idea de compartir libremente por el bien común. Es difícil imaginarse la arquitectura como open source en nuestra sociedad, pero creo que no es imposible. La filosofía del Open Source centra su atención en la premisa de que al compartir la información, el producto resultante tiende a ser de calidad superior al producto propietario, es una visión meramente técnica. La arquitectura de propietario, al no poder compartirse, es antiética dado que prohibir compartir entre seres humanos va en contra de las leyes naturales.
El movimiento Open Source tiene un decálogo que debe cumplir un código para poder llamarse “Open Source” (es de hacer notar que estas 10 premisas son completamente equivalentes con las 4 libertades o principios del Software Libre). He adaptado el decálogo para poder aplicarlo a la arquitectura. Espero correcciones en vuestros comentarios. Estas son :
Libre redistribución: la documentación de un proyecto debe poder ser regalado o vendido libremente.
Fuente documental: toda la documentación debe estar incluida u obtenerse libremente.
Trabajos derivados: la redistribución de modificaciones debe estar permitida.
Integridad de la documentación técnica del autor: las licencias pueden requerir que las modificaciones sean redistribuidas sólo como “modificaciones del proyecto”.
Sin discriminación de personas o grupos: nadie puede dejarse fuera.
Sin discriminación de áreas de iniciativa: los usuarios comerciales no pueden ser excluidos.
Distribución de la documentación: deben aplicarse los mismos derechos a todo el que reciba la documentación del proyecto.
La documentación no debe ser específica de un producto: el proyecto no puede presentarse sólo como parte de un proyecto mayor.
La documentación no debe restringir otros proyectos: la documentación no puede obligar a que algún otro proyecto que sea distribuido con el proyecto abierto deba también ser de código abierto.
La documentación debe ser tecnológicamente neutral: no debe requerirse la aceptación de la documentación del proyecto por ningún medio.
No hay comentarios:
Publicar un comentario