GitHub Copilot y el blanqueo de código abierto

Este artículo es una traducción del artículo «GitHub Copilot and open source laundering» publicado por Drew Devault bajo la licencia CC BY-SA 2.0.

Aviso: soy el fundador de una empresa que compite con GitHub. También soy un desarrollador de y defensor desde hace mucho tiempo del software libre, con un amplio conocimiento de las licencias y la filosofía del software libre. No voy a nombrar a mi empresa en esta publicación para reducir el alcance de mi conflicto de interés.

Hemos visto una explosión del aprendizaje automático en la última década, junto a la explosión en la popularidad del software libre. Al mismo tiempo que el software libre ha dominado el software y ha encontrado su lugar en casi todos los nuevos productos de software, el aprendizaje automático ha aumentado dramáticamente en sofisticación, facilitando interacciones más naturales entre humanos y ordenadores. Sin embargo, pese a su auge paralelo en la computación, estos dos dominios permanecen filosóficamente distantes.

Aunque algunas empresas llamadas con nombres osados podrían sugerir lo contrario, el área del aprendizaje automático no ha disfrutado de casi ninguna de las libertades promovidas por el movimiento del software libre y de código abierto. Gran parte del código con relación con el aprendizaje natural está disponible públicamente, y hay muchos artículos de acceso abierto disponibles para que los lea cualquiera. Sin embargo, la clave para el aprendizaje automático es el acceso a conjuntos de datos de gran calidad y a muchísimo poder computacional para procesar esos datos, y estos dos recursos todavía están guardados bajo llave por casi todos los participantes de este área1.

La barrera esencial de entrada para proyectos de aprendizaje automático es superar estos dos problemas, que normalmente son muy difíciles de conseguir. Para producir un conjunto de datos de alta calidad bien catalogado se requieren generalmente miles de horas de trabajo2, una tarea que puede llegar a costar millones de dólares. Por tanto, cualquier enfoque que baje esta cifra es muy deseable, incluso si el coste es hacer compromisos éticos. Con Amazon toma la forma de explotación de la economía de los pequeños encargos. Con GitHub toma la forma de incumplir los términos de las licencias de software libre. En este proceso han creado una herramienta que facilita el blanqueo a gran escala de software libre como software no libre para sus clientes, a quienes GitHub ofrece negación plausible mediante un algoritmo inescrutable.

El software libre no es un regalo sin condiciones. Existen condiciones para su uso y reutilización. Incluso las denominadas licencias de software «liberales» imponen requisitos de reutilización, como la atribución. Citando la licencia de MIT:

Por la presente se concede el permiso [...] sujeto a las siguientes condiciones:

El anterior aviso de copyright y este aviso de permiso se incluirán en todas las copias o partes sustanciales del Software.

O la igualmente «liberal» licencia de BSD:

Se permite la redistribución y el uso en forma de código fuente y binario, con o sin modificación, siempre que se cumplan las siguientes condiciones:

Las redistribuciones del código fuente deben conservar el aviso de derechos de autor anterior, esta lista de condiciones y el siguiente descargo de responsabilidad.

Al otro lado del espectro, las licencias copyleft, como la Licencia Pública General de GNU o la Licencia Pública de Mozilla, van más allá y no solo les exigen atribución a las obras derivadas, sino que estas también se publiquen con la misma licencia. Citando la GPL:

Puede transmitir un trabajo basado en el Programa, o las modificaciones para producirlo a partir del Programa, en forma de código fuente bajo los términos de la sección 4, siempre que también cumpla todas estas condiciones:

[...]

Debe licenciar el trabajo completo, en su totalidad, bajo esta Licencia a cualquier persona que entre en posesión de una copia.

Y la Licencia Pública de Mozilla:

Toda distribución del Software Amparado en Forma de Código Fuente, incluyendo cualquier Modificación que Usted cree o a la que contribuya, debe realizarse bajo los términos de esta Licencia. Debe informar a los destinatarios de que la Forma de Código Fuente del Software Cubierto se rige por los términos de esta Licencia, y cómo pueden obtener una copia de la misma. Usted no puede intentar alterar o restringir los derechos de los destinatarios en la Forma de Código Fuente.

Las licencias de software libre imponen obligaciones a los usuarios mediante los términos que cubren la atribución, el sublicenciamiento, la distribución, patentes, marcas registradas y relaciones con leyes como la Digital Millennium Copyright Act. La comunidad del software libre no es desconocedora de las dificultades para hacer cumplir estas obligaciones, que algunos grupos ven demasiado onerosas. Pero por lo onerosas que le parezcan estas obligaciones a alguno, uno está, no obstante, obligado a cumplirlas. Si crees que la fuerza del derecho de autor debería proteger tu programa privativo, entonces tienes que estar de acuerdo en que protege igualmente las obras de código abierto, a pesar de la inconveniencia o coste asociados con esta verdad.

El Copilot de GitHub está entrenado con programas que se rigen por estos términos, y falla al respetarlos, y permite que clientes accidentalmente fallen al respetar ellos mismos estos términos. Algunos argumentan sobre los riesgos de una «sorpresa copyleft», en la que alguien incorpora un trabajo licenciado por la GPL en su producto y se sorprende al darse cuenta de que está obligado a publicar su producto bajo los términos de la GPL también. Copilot institucionaliza este riesgo, y cualquier usuario que desee usarlo para desarrollar software no libre debería ser bien recomendado para no hacerlo, o sino podría verse obligado a cumplir esos términos, quizás en última instancia a liberar sus obras bajo los términos de una licencia que no es deseable para sus objetivos.

En esencia, la discusión se reduce a si el modelo constituye o no una obra derivada de sus entradas. Microsoft argumenta que no lo es. Sin embargo, estas licencias no son específicas en cuanto a los medios de derivación; el enfoque clásico de copiar y pegar de un proyecto a otro no tiene por qué ser el único medio para que se apliquen estos términos. El modelo existe como resultado de la aplicación de un algoritmo a estas entradas, por lo que el propio modelo es una obra derivada de sus entradas. El modelo, utilizado después para crear nuevos programas, transmite sus obligaciones a esas obras.

Todo esto supone la mejor interpretación del argumento de Microsoft, con una fuerte dependencia del hecho de que el modelo se convierte en un programador de propósito general, habiendo aprendido significativamente de sus entradas y aplicando este conocimiento para producir un trabajo original. Si un programador humano adoptara el mismo enfoque, estudiando software libre y aplicando esas lecciones, pero no el código en sí, a proyectos originales, yo estaría de acuerdo en que su conocimiento aplicado no está creando obras derivadas. Sin embargo, no es así como funciona el aprendizaje automático. El aprendizaje automático es esencialmente un motor glorificado de reconocimiento y reproducción de patrones, y no representa una auténtica generalización del proceso de aprendizaje. Quizás sea capaz de una cantidad limitada de originalidad, pero también es capaz de degradarse al simple caso de copiar y pegar. He aquí un ejemplo de Copilot reproduciendo, textualmente, una función que se rige por la GPL, y que por tanto se regiría por sus términos:

Continúa leyendo GitHub Copilot y el blanqueo de código abierto

Es importante que el software libre use infraestructuras de software libre

Este artículo es una traducción del artículo «It is important for free software to use free software infrastructure» publicado por Drew Devault bajo la licencia CC BY-SA 2.0.

Aviso: he fundado un proyecto y una empresa centrada en infraestructura de software libre. Decido no nombrarlos en esta publicación y solo recomendaré soluciones en las que no tengo un interés personal.

Los proyectos de programas libres necesitan infraestructura; un lugar para facilitar cosas como la revisión de código, apoyo al usuario final, seguimiento de errores, mercadotecnia, etc. Un ejemplo común de esto es la plataforma de «forja»: infraestructura que se anuncia como una tienda de todo en uno para muchas de las necesidades de proyectos libres, como alojamiento y revisión de código, seguimiento de errores, discusiones, etc. Muchos proyectos también recurrirán a plataformas adicionales para proporcionar otros tipos de infraestructura: salas de chat, foros, redes sociales y demás.

Muchas de estas necesidades tienen a su disposición soluciones no libres, privativas. GitHub es una popular forja de código privativa, y GitLab, el mayor competidor de GitHub, es parcialmente no libre. Algunos proyectos usan Discord o Slack para salas de chat, Reddit como foro, o Twitter y Facebook para mercadotecnia, divulgación y soporte; todos estos son no libres. En mi opinión, depender de que estas plataformas proporcionen infraestructura para tus proyectos libres es un error.

Cuando tu proyecto libre elige usar una plataforma no libre, le das un voto de confianza oficial en nombre de tu proyecto. En otras palabras, le prestas parte de la credibilidad y legitimidad de tu proyecto a las plataformas que eliges. Estas plataformas son fruto de efectos de red, y tu elección es una inversión en esa red. Yo cuestionaría esta inversión por si sola, la conciencia de que estás brindando a estas plataformas tu confianza y legitimidad; pero también hay una consecuencia más preocupante de esta elección: una inversión en una plataforma no libre también es una no inversión en las alternativas libres.

Repito, los efectos de red son el principal motivo del éxito de estas plataformas. Las grandes plataformas comerciales tienen un montón de ventajas en este sentido: grandes presupuestos de mercadotecnia, mucho capital de inversores y la ventaja de la titularidad. Cuanto más grande sea la plataforma titular, mayor dificultad entraña la tarea de competir con ella. Compara esto con las plataformas de software libre, que generalmente no tienen el beneficio de grandes sumas de inversiones o grandes presupuestos de mercadotecnia. Asimismo, las empresas son más propensas a jugar sucio para asegurar su posición que los proyectos de software libre. Si tus propios proyectos compiten con opciones comerciales privativas, ya debes estar muy familiarizado con estos desafíos.

Las plataformas libres están en una inherente desventaja, y tu fe, o falta de fe, en ellas tiene mucho peso. A GitHub no le quitará el sueño que tu proyecto decida alojar su código en otro lugar, pero elegir Codeberg, por ejemplo, significa mucho para ellos. En efecto, tu elección les importa de manera desproporcionada a las plataformas libres: elegir GitHub daña a Codeberg mucho más de lo que elegir Codeberg daña a GitHub. ¿Y por qué debería un proyecto elegir tu oferta en vez de las alternativas privativas si no le das la misma cortesía? La solidaridad del software libre y de código abierto es importante para elevar el ecosistema en conjunto.

Sin embargo, para algunos proyectos, lo que en última instancia es importante para ellos tiene poco que ver con el beneficio al ecosistema en su conjunto, sino que en su lugar considera solo el potencial para la popularidad y el crecimiento individual del proyecto. Muchos proyectos eligen dar prioridad al acceso al público consolidado que proporcionan grandes plataformas comerciales, para maximizar sus posibilidades de volverse populares y de disfrutar de algunos de los efectos secundarios de esa popularidad, como más contribuciones1. Tales proyectos preferirían exacerbar el problema de los efectos de red en vez de arriesgar algo de su capital social en una plataforma menos popular.

Para mí esto es totalmente egoísta y antiético, aunque puede que tengas diferentes estándares éticos. Desgraciadamente, argumentos contra la mayoría de plataformas comerciales para cualquier estándar ético razonable los hay en abundancia, pero suelen superarse fácilmente con un sesgo de confirmación. Alguien que se opone fuertemente a las prácticas del Servicio de Control de Inmigración y Aduanas de Estados Unidos, por ejemplo, puede encontrar rápidamente alguna justificación para seguir usando GitHub a pesar de su colaboración con ellos. Si este ejemplo no es de tu agrado, hay muchos ejemplos para cada una de las muchas plataformas. Para los proyectos que no se quieren mover, estos se barren normalmente bajo la alfombra2.

Pero, para ser claros, no estoy pidiendo que uses plataformas inferiores por razones filosóficas o altruistas. Estos son solo uno de los muchos factores que deberían contribuir a tu toma de decisiones, y la aptitud es otro factor válido a considerar. Dicho eso, muchas plataformas libres son, al menos en mi opinión, funcionalmente superiores a sus competidoras privativas. Si sus diferencias son mejores para las necesidades únicas de tu proyecto es algo que voy a dejar para que lo investigues por tu cuenta, pero la mayoría de los proyectos no se preocupan en absoluto por investigar. Estate seguro: estos proyectos no son guetos que viven a la sombra de sus mayores equivalentes comerciales, sino plataformas excitantes por sus propios méritos que ofrecen muchas ventajas únicas.

Es más, si necesitas que hagan algo diferente para que se adapten mejor a las necesidades de tu proyecto, tienes el poder de mejorarlas. No estás supeditado a los caprichos de la entidad comercial responsable del código, esperando a que den prioridad al problema o incluso a que, en primer lugar, le importe. Si un problema es importante para ti, eso es suficiente para que puedas conseguir que sea arreglado en una plataforma libre. Puede que pienses que no tienes el tiempo o la habilidad para hacerlo (aunque alguno de tus colaboradores quizá sí); pero, más importante, esto crea una mentalidad de propiedad y responsabilidad colectivas sobre todo el software libre en su conjunto —vuelve popular esta filosofía y perfectamente puedes ser tú quien reciba una contribución de forma similar mañana—.

En resumen, elegir plataformas no libres es una inversión individualista a corto plazo que da prioridad al aparente acceso de tu proyecto a la popularidad sobre el éxito del ecosistema libre en su conjunto. Por otro lado, elegir plataformas libres es una inversión colectiva en el éxito a largo plazo del ecosistema libre en su conjunto, conduciendo a su crecimiento general. Tu elección importa. Puedes ayudar al ecosistema libre eligiendo plataformas libres o puedes dañar el ecosistema libre eligiendo plataformas no libres. Por favor, elige con cuidado.

Aquí hay algunas recomendaciones para herramientas de software libre que simplifican necesidades comunes de proyectos de software libre:

* Solo autoalojado.
† Parcialmente no libre, recomendado solo si otras opciones no son adecuadas.


  1. Debo señalar aquí que estoy presentando de forma acrítica la «popularidad» como una cosa buena para un proyecto, que se ajusta, pienso yo, a los procesos mentales de los proyectos que estoy describiendo. Sin embargo, la verdad no es así. Quizá un tema para un artículo otro día. 

  2. Un ejemplo particularmente notorio es el movimiento de Ethical Source. Discrepo con ellos por muchos motivos, pero adelantándose a este artículo está el hecho de que publican licencias (no libres) de software que abogan por sentimientos anticapitalistas como los derechos laborales y por juicios éticos como la no violencia, y lo hacen en... GitHub y Twitter, plataformas privadas comerciales con infinidad de violaciones éticas publicadas. 

  3. Le he presentado muchas veces los argumentos de esta publicación al equipo de Libera, pero todavía dependen de GitHub, Twitter y Facebook. Han sido una de mis motivaciones para escribir este artículo. Espero que algún día tengan un cambio de actitud.