Open Source vs. Source-Available: Lo que el fallo de Coldcard enseña sobre los incentivos del software de Bitcoin

La distinción entre código cerrado y Open Source ha dividido a la industria de Bitcoin y crypto en general durante más de una década. Los defensores de Bitcoin han argumentado durante mucho tiempo que la infraestructura financiera del mundo debería construirse en público. La transparencia y la auditabilidad, dicen, no son negociables cuando hay dinero real en juego. Sin embargo, las capas de aplicaciones y las capas heredadas de las finanzas a menudo no están de acuerdo.

No obstante, el reciente hackeo de Coldcard, una popular hardware wallet de autocustodia donde los usuarios perdieron más de $100 millones en bitcoin (más de 1,500 BTC), puso en duda lo que realmente significa "Open Source". Reveló que quizás la mayoría de las personas, incluso muchos bitcoiners acérrimos, están mal informados sobre la filosofía de desarrollo de software Open Source y cuándo falla.

El lenguaje en torno a Open Source puede ser complicado. Free and Open Source Software (FOSS) y Free/Libre and Open Source Software (FLOSS) se refieren a software que cumple con definiciones formales de libertad para el usuario.

La Free Software Foundation (FSF) define el software libre a través de cuatro libertades esenciales. La Libertad 0 es la libertad de ejecutar el programa como se desee, para cualquier propósito. La Libertad 1 es la libertad de estudiar cómo funciona el programa y cambiarlo para que haga lo que se desee (el acceso al source code es una condición previa para esto).

La Libertad 2 es la libertad de redistribuir copias para ayudar a otros. La Libertad 3 es la libertad de distribuir copias de las versiones modificadas a otros (el acceso al source code es una condición previa para esto). La FSF enfatiza que "libre" se refiere a la libertad, no al precio, en una cita común de los defensores de FOSS: "'libre' como en 'libertad de expresión', no como en 'cerveza gratis'".

La Open Source Definition de la Open Source Initiative añade diez criterios prácticos. Estos incluyen la redistribución gratuita sin royalties, la disponibilidad del source code en la forma preferida para su modificación, y el derecho a crear y distribuir trabajos derivados. También prohíben la discriminación contra personas, grupos o campos de actividad, incluido el uso comercial.

Una licencia debe cumplir los diez criterios para calificar como Open Source bajo el estándar de la OSI. "Source available" o "source viewable" es diferente. El código puede ser de lectura pública, pero la licencia restringe el derecho a venderlo.

El firmware de Coldcard, por ejemplo, se publica bajo los términos de MIT más la Commons Clause. Esta Cláusula elimina específicamente el derecho a "Vender" el software, definido como proporcionarlo a terceros por una tarifa u otra contraprestación en un producto o servicio cuyo valor derive total o sustancialmente del propio software. En otras palabras, el firmware de Coldcard no podía utilizarse comercialmente.

Las propias FAQ de la Commons Clause establecen la diferencia explícitamente: "¿Es esto 'Open Source'? No". Señala que la aplicación de la cláusula significa que el software cumple muchos elementos de la Open Source Definition, pero no todos, y por lo tanto no debería llamarse Open Source.

Estas distinciones importan. Publicar el source code crea la posibilidad de inspección. Conceder el conjunto completo de derechos definidos por la Free Software Definition o la Open Source Definition es lo que convierte al software en FOSS o FLOSS. Sin embargo, tener la insignia de aprobación, poder ondear una bandera FOSS o FLOSS, no es el objetivo principal.

La libertad comercial en FOSS desbloquea incentivos de terceros para probar y revisar el código que de otro modo no existirían, argumentan los críticos. Las cuatro libertades forman el núcleo filosófico de Open Source. En la práctica, se basan en una suposición económica: que suficientes personas motivadas examinarán realmente el código.

Cuando esa suposición falla, el sistema produce una clásica tragedia de los comunes. Esta es una situación en la que un recurso se utiliza en exceso o se descuida porque los usuarios individuales actúan en su propio interés a corto plazo, en lugar de en el interés a largo plazo del grupo. Cada persona tiene un incentivo para tomar más (o contribuir menos) de lo que es sostenible, y el recurso se degrada como resultado.

Esto ocurre cuando hay una desalineación entre el interés individual a corto plazo y el interés a largo plazo del grupo. A veces existe alineación; a veces no. Un desarrollador de Bitcoin expresó el problema sin rodeos: "Usar mocks y stubs de código Open Source en las pruebas es irresponsable y miope".

"El código Open Source se considera seguro porque cualquiera puede verificarlo", continuó el desarrollador de Bitcoin. "Si no estás dispuesto a hacer lo mínimo para probar las características de las que realmente dependes, entonces te estás comportando como una sanguijuela".

Como resultado, Open Source no crea seguridad por sí mismo. Crea la posibilidad de verificación. Si esa verificación ocurre o no, depende de los incentivos, la habilidad y la atención.

Se cree que el FOSS histórico se endurece con el tiempo a medida que se descubren, divulgan y parchean las vulnerabilidades, creando bases sólidas sobre las que otros construyen. El kernel de Linux es un gran ejemplo de FOSS endurecido; impulsa la gran mayoría de los servidores del mundo, la infraestructura cloud, los dispositivos Android y los sistemas embebidos, lo que lo convierte en una de las piezas de software más ampliamente desplegadas en la historia.

Open Source como lo demuestra Bitcoin Core. Bitcoin Core, la implementación de referencia de Bitcoin, es otro ejemplo a gran escala y previsor de funcionamiento Open Source puro en la práctica. El software, que se ejecuta detrás de la mayoría de la infraestructura relacionada con Bitcoin, se lanza bajo la licencia MIT. Su proceso de desarrollo es ampliamente público por diseño.

Cualquiera puede abrir un pull request. La code review es el filtro principal y el punto de entrada recomendado para nuevos colaboradores. Los revisores utilizan un vocabulario formal: Concept ACK (reconocimiento y acuerdo con el objetivo), Approach ACK (acuerdo con el objetivo y el método), ACK con un hash de commit específico (probado y aprobado para merge), o NACK (desacuerdo, que debe ir acompañado de un razonamiento técnico).

Los mantenedores sopesan el consenso entre los colaboradores y los méritos técnicos de un cambio antes de fusionarlo. Los cambios críticos para el consenso enfrentan un listón aún más alto y usualmente requieren un escrutinio adicional.