Código abierto: libertad, responsabilidad y elección

El código fuente es la forma legible por personas de un programa, y ese acceso es lo que separa el software que solo puede usarse del software que puede examinarse. Sin la forma legible puede observar cómo se comporta un programa y pedir más a quien lo escribió; con ella, usted o quien usted contrate puede ver por qué se comporta así, qué envía por la red, dónde está un fallo y dónde iría un cambio.

El código abierto no describe cómo se fabrica el software ni promete que el código esté visible por casualidad: es un conjunto de permisos que una licencia concede, y existe una definición escrita y ampliamente aceptada de cuáles deben ser. La Open Source Initiative la mantiene y decide con ella qué licencias cuentan como código abierto: exige, entre otras cosas, redistribución libre, disponibilidad del código en la forma que de verdad hace falta para cambiarlo, permiso para crear y distribuir versiones modificadas, ninguna restricción sobre quién lo usa ni para qué, y ninguna dependencia de una tecnología o interfaz concreta. De ahí se sigue una distinción práctica: una licencia que permite leer el código pero prohíbe el uso comercial o compartir cambios es de código disponible, no de código abierto.

La tradición del software libre formula la misma idea con más concreción, como cuatro libertades: ejecutar el programa para cualquier propósito, estudiar cómo funciona y cambiarlo, redistribuir copias y distribuir versiones modificadas. Una licencia concede esas libertades y puede añadir condiciones, casi siempre conservar los avisos o mantener la misma licencia en las versiones que se distribuyan.

Hay dos formas habituales. Las licencias permisivas, como la Apache 2.0 que se usa aquí, ponen pocas condiciones: permiten usar, modificar y redistribuir conservando los avisos, e incluyen una licencia de patentes expresa. Las licencias copyleft añaden una condición destinada a mantener el software abierto para quienes lo reciben: quien distribuye una versión debe hacerlo bajo la misma licencia. La familia más conocida es la GNU General Public License. El copyleft no es idéntico en todas ellas y las diferencias importan: lo habitual es que el detonante sea la redistribución, y en licencias concretas también el uso a través de una red —la GNU Affero General Public License exige entonces que los usuarios puedan obtener el código de la versión que se está ejecutando—. Es una particularidad de esas licencias, no una regla general del código abierto. Lo que ninguna licencia de código abierto exige es publicar su propio trabajo privado: un cambio que usted guarda para sí y no distribuye no activa esas obligaciones.

Compartir software es casi tan antiguo como programarlo. En las primeras décadas de la informática, buena parte del software lo escribían quienes lo usaban, los programas circulaban entre usuarios y los centros de investigación daban por normal intercambiar código. La práctica se fue perdiendo cuando el software empezó a venderse como producto independiente: en los años ochenta, la gran mayoría del software era propietario, y el código dejó de llegar a quien lo compraba.

La respuesta vino del proyecto GNU. Richard Stallman lo anunció en septiembre de 1983, el trabajo comenzó en enero de 1984 y en 1985 se fundó la Free Software Foundation. La GNU General Public License nació de un motivo concreto: el software no debía liberarse al dominio público, donde una versión posterior podría volverse propietaria, sino permanecer libre para todas las personas que lo recibieran. En 1991 Linus Torvalds empezó un núcleo tipo Unix que, junto al sistema GNU ya casi completo, dio un sistema operativo utilizable libremente; el desarrollo se hacía en público, con cambios enviados y discutidos a la vista de cualquiera.

El mismo patrón se repite en otras herramientas. Cuando el desarrollo del servidor NCSA HTTPd se estancó en 1994, varios administradores coordinaron sus parches, formaron el grupo Apache en febrero de 1995 y publicaron la primera versión en abril de ese año; en menos de un año su servidor era el más usado del mundo, y el proyecto pasó después a la Apache Software Foundation, que desde 1999 da un marco sin ánimo de lucro a este tipo de iniciativas.

El término «código abierto» nació el 3 de febrero de 1998 en Palo Alto, poco después de que Netscape anunciara el 22 de enero que liberaría el código de su navegador; el código se publicó el 31 de marzo de ese año y de ahí surgió el proyecto Mozilla. Ese mismo año se constituyó la Open Source Initiative, cuya definición se apoyó en las directrices de Debian que ya existían desde 1997. ¿Por qué hizo falta un nombre nuevo? Porque el desarrollo abierto tiene ventajas prácticas que también entiende una empresa a la que no le interesan las discusiones éticas, y en 1998 hacía falta decir precisamente eso.

Software libre y código abierto designan en la práctica casi lo mismo: las mismas licencias, los mismos programas, la misma forma de compartir. La diferencia está en el acento. La tradición del software libre, con la Free Software Foundation, sitúa en el centro la libertad de quien usa el programa y la justifica éticamente; la corriente del código abierto insiste en las ventajas prácticas. Ninguna de las dos cambia lo que puede hacer con el programa: eso lo decide la licencia que lleve, no la etiqueta.

Y conviene separar dos cosas que el inglés mezcla en una sola palabra: aquí libre se refiere a la libertad, no al precio. Un programa puede ser gratuito y no ser libre —si su licencia prohíbe compartirlo o modificarlo—, y puede ser libre y costar dinero, porque desarrollar, operar y mantener software siempre cuesta trabajo. Por eso «software gratis» no explica nada: lo que importa es qué permite su licencia.

Los permisos tienen consecuencias concretas: puede inspeccionar el software, adaptarlo a su caso —una estructura de página, un flujo, una traducción—, usarlo comercialmente incluso dentro de algo que nunca publique, seguir con él si quien lo escribió pierde el interés y marcharse sin depender de una cuenta ni de la generosidad de un proveedor. A cambio, la licencia entrega capacidad, no medios: alguien tiene que configurar, desplegar, mantener y entender lo que se ejecuta.

Conviene precisar dos cosas. La libertad de modificar es la libertad de cambiar su copia y de distribuir su propia versión; no es un derecho a que su cambio se acepte en el proyecto del que tomó el software. Eso lo deciden quienes lo mantienen, según lo que encaje con su propósito y según sus propias reglas. Y gratuito de usar no significa gratuito de crear: alguien dedica tiempo a la documentación, las pruebas, las versiones y la compatibilidad, y por eso este proyecto explica dónde puede ayudar quien quiera ayudar. Nadie está obligado a nada: usar Foundation sin contribuir no es hacer nada mal.

Foundation se publica bajo la licencia Apache 2.0 porque su propósito es ser una base reutilizable para webs informativas de empresas, y ese propósito sería contradictorio con una licencia que permitiera adoptarla y luego limitara lo que puede hacerse con el resultado. Apache 2.0 permite el uso independiente, privado y comercial, incluye una licencia de patentes y no transfiere propiedad exclusiva: Foundation sigue siendo abierto para todos. El material de terceros conserva su propia licencia y su atribución, y la licencia no concede derechos sobre el nombre ni las marcas de Provelopment.

Lo decisivo no es la promesa, sino la construcción: que los contenidos, la configuración y la identidad vivan como archivos en su repositorio, que las adaptaciones no se hagan en el núcleo de la plataforma, que los servicios externos queden detrás de interfaces intercambiables y que la plataforma esté documentada en público. Eso no hace la independencia automática, pero la hace ejercitable, y una independencia que no puede ejercerse no es independencia. Si quiere ayuda, Provelopment puede ofrecerla como servicio, nunca como condición.

Los proyectos abiertos suelen empezar con un problema personal: alguien escribe la solución que necesita para su propio trabajo y descubre que otras personas tienen el mismo problema. Las razones para continuar son variadas —aprender, hacer útil el propio trabajo, el reconocimiento entre colegas—, y en las organizaciones se añaden otras más prosaicas: una biblioteca que muchos usan se mantiene mejor entre todos que reescribiéndola en cada empresa, y depender de un solo proveedor para una pieza básica es un riesgo.

La primera versión del código es la parte pequeña del trabajo. Lo demás es leer informes de fallos, responder preguntas, actualizar dependencias, reaccionar ante problemas de seguridad, mantener la documentación, preparar versiones y comprobar que una actualización no rompe lo que ya funcionaba. Ese trabajo existe aunque el software no se pague, y con frecuencia recae en muy pocas personas, a veces en una sola: si esa persona se detiene, el proyecto se detiene. De ahí salen dos afirmaciones honestas. Nadie puede garantizar que un proyecto siga vivo tal como está: las licencias aseguran la continuidad legal, no el mantenimiento. Y el apoyo más eficaz es el que compra tiempo: una aportación mensual sostenida permite que alguien dedique al proyecto una parte fija de su jornada en lugar de lo que sobra de otras tareas.

Foundation se ofrece, como cualquier proyecto abierto, sin garantía: ninguna licencia obliga a corregir un fallo concreto, responder una pregunta o dar soporte comercial. Lo que sí obtiene es la capacidad de actuar por su cuenta: arreglarlo usted, encargarlo a otra persona o sustituir lo que no le sirva; elegir la versión, decidir cuándo actualizar y comprobar las copias de seguridad es decisión suya. Participar no exige ser desarrollador: un informe claro —qué esperaba, qué ocurrió, cómo reproducirlo y con qué versión— ahorra tiempo a quien lo lee; una sugerencia que describa el problema ayuda más que una solución cerrada; mejorar o traducir la documentación llega directo a la siguiente persona; y responder a otras personas en público reparte el esfuerzo. El apoyo económico es otra vía, voluntaria, y no equivale a comprar un servicio.