La IA está incrementando la productividad de los desarrolladores y esto se está reflejando el el número de commits registrados en GitHub
La IA está incrementando la productividad de los desarrolladores
El crecimiento de commits en GitHub ha sido realmente impresionante en tiempos recientes. En 2025 se registraron 1,000 millones. Para finales de este año se deberían alcanzar los 14 ,000 millones.
Yup, platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.)
GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now… https://t.co/iGsM2j1efO
Este crecimiento no se debe al azar. El uso de la IA está incrementando la productividad de los desarrolladores y está permitiendo que cada día surjan nuevos proyectos y aplicaciones que antes simplemente no hubiera sido posible crear.
Los commits en GitHub son una medida aproximada de lo que logra la IA
El número de commits en GitHub no es una medida exacta del aumento de productividad que la IA está permitiendo lograr, porque ni todos los desarrolladores han adoptado aún la IA ni todos lo han hecho de la misma forma. Sin embargo, entre los más entusiastas, los que publican sus proyectos en GitHub y que son generalmente «Early adopters» (o sea que adoptan rápidamente las nuevas tecnologías), lo números parecen ser concluyentes. El aumento de productividad no parece ser del 30 al 40% como han reportado algunas empresas. Estamos hablando de números mucho más altos.
GitHub, de Microsoft, corrigió un problema de seguridad que amenazaba a todos sus usuarios
A un punto y coma del desastre
Un simple git push. Ese comando cotidiano que millones de desarrolladores ejecutan a diario estuvo, hasta el 4 de marzo de 2026, peligrosamente cerca de convertirse en la puerta de entrada a uno de los incidentes de seguridad más graves en la historia de GitHub.
Descubierta por Wiz y registrada como CVE-2026-3854, esta vulnerabilidad de ejecución remota de código (RCE) podía permitir el acceso a repositorios privados de prácticamente cualquier organización alojada en la plataforma. Lo más sorprendente es que fue encontrada con ayuda de inteligencia artificial y solucionada en apenas seis horas.
Lo que ocurre detrás de un git push
Cuando un desarrollador sube código, el proceso no consiste solo en guardar archivos. El comando atraviesa una cadena de servicios internos escritos en distintos lenguajes que se comunican mediante un encabezado HTTP interno llamado X-Stat.
Este encabezado funciona como una lista de parámetros clave=valor separados por punto y coma, que controlan reglas críticas como permisos, políticas de tamaño de archivos o nombres de ramas.
El problema surgió en el primer servicio de la cadena, llamado babeld. Este servicio construía el encabezado X-Stat tras autenticar al usuario, pero cometía un error fatal: no filtraba los puntos y coma en los push options (git push -o).
Ese pequeño detalle permitía a un atacante inyectar nuevos campos dentro del encabezado. Como el sistema priorizaba el último valor leído, era posible sobrescribir parámetros de seguridad y, combinando tres campos internos específicos, lograr ejecución remota de código en la infraestructura de GitHub.
Nube vs. servidores empresariales
La vulnerabilidad afectaba tanto a GitHub.com como a GitHub Enterprise Server (GHES).
En servidores empresariales el ataque era directo. En la nube, los investigadores descubrieron un paso extra con el que podían activar el “modo Enterprise” mediante otro campo inyectable en el encabezado X-Stat, completando así la cadena de explotación.
El hallazgo fue posible gracias a ingeniería inversa asistida por IA con la herramienta IDA MCP, marcando uno de los primeros casos importantes de vulnerabilidades críticas descubiertas en software propietario mediante IA.
Carrera contrarreloj: seis horas
La respuesta de GitHub fue extremadamente rápida:
40 minutos para reproducir la vulnerabilidad internamente.
2 horas para identificar la causa raíz y desplegar el parche en GitHub.com.
6 horas después, mitigación completa y análisis forense.
La investigación confirmó que no hubo explotación maliciosa.
Sin embargo, el problema persistía para instalaciones locales de GHES. Al hacerse pública la vulnerabilidad el 28 de abril, Wiz estimó que el 88% de las instancias seguían vulnerables, requiriendo actualización urgente a la versión 3.19.3 o superior.
Un momento complicado para GitHub
Este incidente llegó en un periodo turbulento para la plataforma, propiedad de Microsoft. Días antes, GitHub sufrió una caída importante que revertía commits ya fusionados para algunos usuarios, sumándose a preocupaciones internas sobre fiabilidad y salida de líderes.
Aun así, la rapidez con la que se solucionó esta vulnerabilidad demuestra la importancia de la colaboración entre investigadores y plataformas. Y por ahora, los desarrolladores pueden respirar tranquilos, ya que el git push vuelve a ser un comando rutinario.
Anthropic lideró la revolución que supuso usar agentes de IA, mediante la creación de estándar MCP
Anthropic vuelve al centro del debate de seguridad tras revelarse una vulnerabilidad sistémica en su Model Context Protocol (MCP), el estándar open-source que conecta aplicaciones de IA con sistemas externos. Investigadores de OX Security afirman que el problema podría permitir el control completo de hasta 200,000 servidores.
Lo que genera polémica es que Anthropic sostiene que el comportamiento es intencional y esperado y no un bug.
El problema es la ejecución de herramientas MCP a través de STDIO
El origen del fallo está en cómo MCP usa STDIO (entrada/salida estándar) para lanzar servidores MCP como subprocesos.
El flujo actual permite:
Ejecutar comandos del sistema operativo.
Si el comando crea un servidor STDIO, devuelve el handle.
Si el comando es malicioso, el error llega después de ejecutarlo.
El resultado es que esto permite la ejecución arbitraria de comandos (RCE). Claramente, esto abre acceso potencial a:
Datos sensibles
Bases internas
Claves API
Historiales de chat
El impacto es enorme ya que se han dado más de 150 millones de descargas del SDK y hay miles de servidores públicos afectados, con más de 10 CVEs críticos emitidos.
Las cuatro grandes vías de ataque
1) Inyección de comandos (con y sin autenticación)
Algunos frameworks permiten ejecutar comandos directamente desde input del usuario.
Proyectos afectados:
LangFlow (sin CVE aún)
GPT Researcher (CVE-2025-65720)
Investigadores lograron ejecutar comandos en seis plataformas en producción.
2) Bypass de “hardening”
Incluso plataformas que intentaron limitar comandos permitidos fueron vulnerables.
Ejemplos:
Upsonic (CVE-2026-30625)
Flowise (GHSA-c9gw-hvqq-f33r)
El truco en estos casos consiste en inyectar comandos dentro de los argumentos permitidos.
3) Prompt injection “zero-click” en IDEs de IA
Herramientas de desarrollo con IA también resultaron vulnerables.
Entre ellas:
Google (Gemini CLI)
Microsoft (GitHub Copilot)
Cursor y Claude Code
Los proveedores argumentan que requieren permisos explícitos, pero los investigadores consideran que el riesgo sigue siendo alto.
4) Ataques vía marketplaces MCP
Los investigadores lograron “envenenar” 9 de 11 registros MCP con una prueba de concepto. Un solo servidor malicioso podría comprometer miles de equipos de desarrolladores.
La controversia: ¿bug o decisión de diseño?
Anthropic confirmó que no cambiará la arquitectura del protocolo ya que su postura es que:
El modelo STDIO es un “default seguro”.
La sanitización de inputs es responsabilidad del desarrollador.
Tras el informe, la empresa solo añadió una advertencia en su política de seguridad recomendando usar adaptadores STDIO “con cautela”.
Los investigadores discrepan. Según ellos, un cambio a nivel protocolo podría proteger automáticamente a millones de usuarios. A todas luces, tienen razón, aunque esto forzaría a los desarrolladores a actualizar la librería en los programas clientes de MCP y en los servidores.
Cómo proteger la infraestructura MCP ahora mismo
Si usas MCP mediante STDIO, las recomendaciones urgentes son:
Trata toda configuración externa como no confiable
Bloquea input del usuario hacia configuraciones de ejecución.
No expongas servicios al internet público
Especialmente herramientas conectadas a APIs o bases de datos.
Ejecuta servicios en sandbox
Sin acceso completo al disco o shell.
Usa solo repositorios oficiales
Evita registros MCP no verificados.
Monitorea invocaciones de herramientas
Detecta exfiltración de datos o tráfico sospechoso.
Actualiza o aísla servicios vulnerables
Si no hay parche disponible, desactívalos.
Sin embargo, la preocupación de los investigadores podría ser excesiva. El protocolo STDIO está pensado desde el inicio como un modo sencillo de crear prototipos para los desarrolladores, no para ponerlo tal cual en producción. Quienes lo hayan hecho, lo hicieron por pereza o desconocimiento, ya que el mismo protocolo ofrece otros mecanismos seguros para conectarse a servidores MCP usando protocolos de autenticación.
Si usas un programa como LocalIntelligence en macOS, puedes conectarte a un servidor MCP no solo mediante STDIO sino también a través de TCP/IP.
Esto es por lo tanto una llamada de atención a los desarrolladores para que solo usen STDIO durante la fase de desarrollo y nunca en producción.
Otro ataque más a la cadena de suministro, hackean Axios en npm para distribuir malware
Otro ataque más a la cadena de suministro
La popular librería de JavaScript Axios, utilizada por millones de desarrolladores para enviar solicitudes HTTP entre aplicaciones y servicios web, fue comprometida en uno de los ataques a la cadena de suministro más graves registrados en el ecosistema npm.
Con cerca de 100 millones de descargas semanales, el incidente encendió alarmas en toda la industria del software.
Cómo ocurrió el ataque
El ataque no explotó una vulnerabilidad del código de Axios. En cambio, los atacantes lograron secuestrar la cuenta de la persona responsable por mantener el proyecto y cambiar su correo por una bandeja anónima de ProtonMail.
Desde ahí, los intrusos evitaron los controles automáticos del pipeline de GitHub Actions y publicaron manualmente versiones maliciosas en el registro de npm usando la línea de comando (CLI).
En tan solo 39 minutos, se publicaron dos versiones comprometidas:
axios@1.14.1 (00:21 UTC)
axios@0.30.4 (01:00 UTC)
Cualquier desarrollador que instaló estas versiones descargó malware sin saberlo.
El caballo de Troya: un paquete falso llamado plain-crypto-js
El ataque fue planeado minuciosamente. Los atacantes publicaron primero un paquete falso llamado plain-crypto-js para crear historial y credibilidad.
18 horas después, lo actualizaron con código malicioso y lo añadieron como dependencia dentro de la versión comprometida de Axios.
Su función real era actuar como puerta de entrada para un Remote Access Trojan (RAT).
Tras la instalación, un script automático descargaba una segunda carga maliciosa adaptada al sistema operativo:
macOS: disfrazado como daemon del sistema
Windows: ejecución vía PowerShell
Linux: puerta trasera en Python
Después de infectar el sistema, el malware eliminaba sus rastros para dificultar el análisis forense.
Un ataque altamente sofisticado
La firma de seguridad StepSecurity analizó el incidente y lo calificó como uno de los ataques más sofisticados contra npm.
Según Ashish Kurmi, CTO y cofundador de la empresa:
“No fue oportunista. Se prepararon tres cargas para distintos sistemas, se atacaron dos ramas en menos de una hora y todo fue diseñado para autodestruirse”.
Este tipo de campañas confirma una tendencia preocupante: los atacantes están enfocándose directamente en la cadena de suministro del software.
Riesgo crítico para desarrolladores y empresas
Aunque npm eliminó rápidamente las versiones maliciosas, el daño potencial es enorme:
Equipos de desarrollo infectados
Pipelines CI/CD comprometidos
Posible filtración de credenciales y tokens
Riesgo de infiltración en entornos de producción
Los expertos advierten que si instalaste esas versiones de Axios, debes asumir que tu sistema está comprometido.
Qué hacer si tu proyecto fue afectado
Las recomendaciones de seguridad son:
1) Revertir versiones
Volver a una versión segura de Axios
Verificar la eliminación de la dependencia maliciosa
2) Auditar pipelines
Revisar logs de CI/CD y despliegues recientes
3) Rotar credenciales
Cambiar contraseñas, API keys y tokens
4) Reconstruir entornos
Reinstalar máquinas y pipelines desde cero si es necesario
Debido a la enorme presencia de Axios en el ecosistema global, las consecuencias de este ataque pueden perdurar.
Pretext: la librería de 15KB que podría resolver un problema de rendimiento web viejo de 30 años
Un viejo problema
Durante décadas, medir y posicionar texto en la web ha sido una trampa silenciosa de rendimiento. Cada vez que el navegador calcula el tamaño de un párrafo o dónde cortar una línea, ejecuta una de las tareas más costosas del rendering, a saber el reflow de layout.
Ahora, el ingeniero Cheng Lou, creador de React Motion y senior engineer en Midjourney, presentó una solución radical, Pretext, una librería TypeScript de solo 15KB que mide texto multilinea hasta 600 veces más rápido que los métodos tradicionales.
El costo oculto del texto en la web
Renderizar texto parece simple, pero no lo es.
Los navegadores deben manejar:
Emojis y modificadores de tono de piel
Ligaduras tipográficas
Sistemas de escritura sin espacios como el japonés o el chino
Idiomas RTL (right-to left) como el árabe o el hebreo que se escriben de derecha a izquierda
Para medir el tamaño del texto, los desarrolladores normalmente insertan elementos invisibles en el DOM y consultan sus dimensiones. Esto provoca un reflow sincrónico, que según el equipo de Chrome DevTools puede bloquear el hilo principal entre 10 y 100 ms en móviles.
Multiplica eso por cientos de bloques de texto y obtienes:
UI lenta
“Web jank”
Peor CLS (Cumulative Layout Shift)
Penalizaciones SEO
El cambio de paradigma de Pretext
Pretext rompe con el enfoque tradicional ya que no usa el DOM ni CSS para medir texto.
Su método funciona en dos pasos:
1) Medición sin reflow
Utiliza canvas.measureText() para acceder al motor tipográfico del navegador sin activar layout.
2) Cálculo matemático puro
Con el ancho del contenedor, calcula:
Saltos de línea
Justificación
Altura total
Resultado:
Método tradicional: 500 bloques → 15–30 ms + 500 reflows
Pretext: 500 bloques → 0.05 ms y 0 reflows
No es solo optimización, es una nueva forma de pensar el layout.
Nuevas posibilidades para interfaces y animación
Separar el layout del DOM desbloquea varios casos de uso antes imposibles.
Solución al problema histórico del SVG
Desde su lanzamiento en 2003, SVG nunca ha ofrecido una solución adecuada al wrapping automático de texto. Con Pretext + herramientas tipográficas, ahora es posible generar texto SVG que se ajusta automaticamente.
Pretext llena un vacío enorme en el desarrollo web moderno. Disponible como código abierto en npm, ofrece a los desarrolladores un control total y ultrarrápido sobre el elemento más básico de la web que es el texto.
Si se adopta masivamente, podría cambiar cómo se construyen interfaces en internet durante la próxima década.
Sin embargo, lo más importante podría terminar siendo que esta librería al fin hiciera que la W3C se fijara en este problema fundamental y definiera un nuevo estándar para resolver este problema de programación tan común que afecta a tantos desarrolladores de front-end.
Oracle anunció Java 26 con Project Detroit para acelerar la interoperabilidad entre Java, JavaScript y Python
Java 26 incluye Project Detroit para acelerar la interoperabilidad entre Java, JavaScript y Python
En el marco de JavaOne, Oracle ha anunciado oficialmente Java 26 y lo más interesante de esta nueva versión es Project Detroit, una nueva iniciativa que busca mejorar de forma significativa la interoperabilidad entre Java, JavaScript y Python.
Está claro que Java perdió el tren de la IA. Los desarrolladores apostaron principalmente por Python y en menor medida por JavaScript para crear aplicaciones con IA. Si bien no hay nada que impide que una aplicación Java explote APIs de IA como los de OpenAI o Google, Java tiene muchos menos frameworks de desarrollo para integrar Java a sus aplicaciones y eso es un problema para la plataforma.
Por eso, el objetivo de Java 26 es permitir a los desarrolladores utilizar código escrito en esos lenguajes y que usan esos frameworks de los que carece Java para crear nuevas aplicaciones de forma más rápida, eficiente y segura. Uno podría preguntarse porqué los desarrolladores no abandonan simplemente Java y adoptan Python o JavaScript. La respuesta es sencilla, Java sigue siendo un lenguaje de programación mucho más serio que ambas alternativas y mejor diseñado para aplicaciones empresariales.
Un nuevo enfoque: runtimes nativos dentro de la JVM
A diferencia de soluciones anteriores, Project Detroit apuesta por integrar directamente los runtimes más utilizados dentro de la máquina virtual de Java:
V8 (motor de JavaScript)
CPython
Esto elimina la necesidad de reimplementaciones, como ocurrió con proyectos anteriores como Nashorn, que intentaban recrear JavaScript dentro de Java.
El resultado:
Mejor compatibilidad con ecosistemas reales
Menos problemas en casos límite
Mayor rendimiento
El papel clave del FFM API
Uno de los pilares técnicos de esta mejora es el Foreign Function and Memory API, introducido en Java 22.
Este API reemplaza al antiguo Java Native Interface (JNI) con un enfoque más moderno y sencillo, permitiendo crear capas muy ligeras para:
Llamar código JavaScript desde Java
Invocar Java desde otros lenguajes
Rendimiento y seguridad mejorados
Según Oracle, el nuevo enfoque ofrece ventajas claras:
Mayor velocidad en la ejecución entre lenguajes
Aislamiento de memoria entre heaps (Java, V8, CPython)
Modelo de seguridad más robusto
Esto es especialmente relevante en aplicaciones modernas que necesiten combinar código Java con componentes en Python o JavaScript, principalmente para usar la IA.
Java 26: una versión de transición
Java 26 es una versión de Java que tendrá un tiempo de vida corto ya que será reemplazada dentro de seis meses por Java 27.
Entre las novedades de Java 26:
Mejoras incrementales en concurrencia estructurada
Avances en el Vector API
Soporte para HTTP/3
También marca el fin de una era con la eliminación definitiva de los applets de Java, ya obsoletos.
Más novedades dentro del ecosistema Java
Oracle también anunció otros movimientos estratégicos:
Project Helidon se integrará en OpenJDK
Lanzamiento del Java Verified Portfolio (JVP), un conjunto validado de herramientas empresariales
Soporte renovado para JavaFX
Integración de Java en notebooks de Visual Studio Code
Además, la compañía está reforzando su apuesta por la IA con proyectos como:
Helidon AI
LangChain4j (fuertemente apoyado por IBM)
Spring AI
Java se adapta (tarde) a la era de la IA
Project Detroit refleja una tendencia clara, ya ningún lenguaje vive en aislamiento. Las aplicaciones modernas combinan múltiples tecnologías, especialmente ante el auge de la inteligencia artificial.
Al integrar directamente los runtimes más populares, Oracle busca posicionar Java como un actor central en este nuevo paradigma, facilitando la colaboración entre ecosistemas sin sacrificar rendimiento ni compatibilidad.
En definitiva, más que competir con otros lenguajes, Java apuesta por convivir con ellos de forma nativa y eficiente.
Dos décadas de Amazon S3, el motor invisible de Internet creado por AWS
De un lanzamiento discreto al motor invisible de Internet
Hace 20 años, el 14 de marzo de 2006, Amazon Web Services lanzó silenciosamente un servicio que cambiaría para siempre la industria tecnológica: Amazon S3. Sin demos, sin ejemplos de código y con apenas un breve anuncio, el servicio ofrecía algo aparentemente simple: almacenar datos (PUT) y recuperarlos (GET) utilizando un API REST.
Lo que parecía una herramienta básica acabaría convirtiéndose en uno de los pilares fundamentales de Internet moderno.
De un petabyte a cientos de exabytes
En sus inicios, S3 contaba con:
~1 petabyte de capacidad total
400 nodos de almacenamiento
Objetos de hasta 5 GB
Un coste de $0.15 por GB
Actualmente, la escala es difícil de imaginar:
Más de 500 billones de objetos almacenados
Más de 200 millones de solicitudes por segundo
Cientos de exabytes de datos distribuidos en 39 regiones
Un tamaño máximo por objeto de 50 TB
El coste también se ha desplomado a poco más de $0.02 por GB, una reducción del 85%, propiciada por el crecimiento de la capacidad de los discos duros y la reducción del costo por GB. Además, herramientas como S3 Intelligent-Tiering han permitido ahorrar miles de millones a los clientes.
El impacto cultural: el “backend” del mundo digital
S3 no solo creció en tamaño, sino en influencia. Se convirtió en la infraestructura invisible detrás de servicios globales como:
Netflix
Spotify
Gracias a su escalabilidad prácticamente ilimitada, permitió que estas plataformas redefinieran cómo consumimos contenido.
Además, su API se transformó en un estándar de facto. Hoy en día, no hay proveedor de nube que no ofrezca soluciones 100% compatibles con S3, replicando su modelo y convenciones, generalmente a menor costo.
Desafíos y evolución técnica
Operar a esta escala no ha estado exento de problemas. Uno de los incidentes más recordados fue la caída de 2017 en la región US-EAST-1, que afectó a buena parte de Internet.
También hubo retos de seguridad: en sus primeros años, configuraciones abiertas por defecto provocaron filtraciones de datos hasta que AWS endureció sus políticas.
Para garantizar fiabilidad, S3 está diseñado con 11 nueves de durabilidad (99.999999999%), lo que logra gracias a:
Sistemas automáticos de verificación y reparación
Arquitectura de microservicios
Uso de métodos formales para validar código
En los últimos años, AWS ha reescrito partes críticas del sistema en Rust, mejorando rendimiento y eliminando potenciales errores relacionados con el uso de la memoria.
Y quizás lo más impresionante es que el código escrito en 2006 que usaba S3, sigue funcionando hoy sin cambios, manteniendo una compatibilidad total.
La base de la era de la IA
El futuro de S3 va mucho más allá del almacenamiento tradicional. AWS quiere convertirlo en la base universal para datos e inteligencia artificial.
Entre las nuevas capacidades destacan:
Tablas gestionadas con Apache Iceberg (S3 Tables)
Gestión centralizada de metadatos
Almacenamiento nativo de vectores (S3 Vectors)
Este último es clave para casos como búsqueda semántica y sistemas de IA con RAG (Retrieval-Augmented Generation). Solo en unos meses de 2025, se crearon más de 250,000 índices y se almacenaron más de 40,000 millones de vectores.
Un estándar que define la industria
La visión es de AWS es clara. El objetivo es almacenar cualquier tipo de dato una sola vez y procesarlo directamente en S3, eliminando la necesidad de mover información entre sistemas.
Esto no solo simplifica la arquitectura técnica, sino que también refuerza el papel de AWS como eje central del ecosistema de datos.
De herramienta simple a infraestructura global
En dos décadas, S3 ha pasado de ser una utilidad básica a convertirse en la columna vertebral del mundo digital.
Su éxito demuestra una idea poderosa: cuando la infraestructura funciona de forma invisible y fiable, los desarrolladores pueden centrarse en innovar. Y eso, en última instancia, es lo que ha permitido construir gran parte de Internet tal y como lo conocemos hoy.
IA y código abierto. Los conflictos que vienen. Chardet solo es el primer caso.
Vivimos en una era distinta. Todo está cambiando.
El auge de la inteligencia artificial generativa está transformando rápidamente la industria tecnológica, pero una nueva controversia ha puesto de relieve uno de sus efectos más complejos: la reescritura de software mediante el uso de la IA.
Modelos de lenguaje avanzados y agentes de programación son capaces de recrear grandes bases de código en cuestión de horas o días. Esto está permitiendo que desarrolladores reescriban proyectos existentes y los publiquen bajo licencias diferentes, lo que pone a prueba conceptos fundamentales del mundo del software como el copyright, las licencias y el movimiento copyleft.
El caso más reciente surgió en la comunidad de Python con el popular proyecto chardet.
La controversia de chardet
La librería Python chardet fue creada para detectar el tipo de codificación utilizado para una cadena de caracteres o una página web. Fue creada en 2006 por Mark Pilgrim y se ha convertido en una herramienta extremadamente popular con unos 130 millones de descargas mensuales.
El proyecto fue publicado bajo la licencia LGPL, una licencia copyleft que exige que las versiones derivadas mantengan las mismas condiciones de distribución.
En 2012, Mark Pilgrim dejó el proyecto y el mantenimiento del mismo pasó a manos de Dan Blanchard quien estuvo actualizándolo hasta ahora.
Distribuida bajo la licencia MIT, mucho más permisiva
Para crear esta nueva versión, Mark utilizó Claude de Anthropic, completando el trabajo en tan solo cinco días.
El cambio de licencia tenía un objetivo claro: facilitar que la biblioteca pudiera integrarse en la biblioteca estándar de Python.
El creador original se opone
Poco después del lanzamiento, Mark Pilgrim reapareció en GitHub para protestar.
Según él, los mantenedores no tienen derecho a cambiar la licencia del proyecto.
Pilgrim argumentó que incluso si fuera cierto que el código fue reescrito, los desarrolladores habían estado expuestos durante años al código original, lo que podría convertir la nueva versión en una obra derivada bajo los términos de la LGPL.
También cuestionó el argumento de que usar IA cambiara la situación legal:
“Añadir un generador de código sofisticado no concede ningún derecho adicional”.
El debate del “clean room”
El conflicto gira en torno al concepto de implementación “clean room”.
Históricamente, este método se utilizó para recrear software sin violar derechos de autor. El caso más famoso ocurrió en 1982 cuando Compaq clonó el BIOS de IBM.
El proceso requería dos equipos separados:
El primero analizaba el producto original y escribía una especificación
El otro creaba un nuevo código basándose únicamente en esa especificación
Este proceso podía tardar meses.
Actualmente, un modelo de IA puede realizar ese proceso en cuestión de horas.
Blanchard reconoce que su método no fue un clean room tradicional, ya que conoce el proyecto desde hace más de una década. Sin embargo, sostiene que lo importante es que el resultado final sea estructuralmente independiente.
Para demostrarlo utilizó JPlag, una herramienta de detección de plagio de código. Según sus pruebas, la similitud máxima entre el nuevo código y versiones anteriores es inferior al 1.3 %.
El problema de fondo: el entrenamiento de la IA
El uso de IA introduce una complicación completamente nueva.
Incluso si el desarrollador comenzó con un repositorio vacío, el modelo Claude probablemente fue entrenado con código público, incluyendo potencialmente el código original de chardet.
Esto plantea una pregunta jurídica inédita:
¿Puede una IA entrenada con código copyleft generar legalmente una versión no derivada de ese mismo software?
La respuesta todavía no está clara.
Un posible terremoto para la industria
Muchos expertos creen que el caso chardet es solo el primer indicio de un problema mucho mayor.
En listas de correo del desarrollo del kernel de Linux ya se debate la posibilidad de que agentes de IA reescriban grandes partes del sistema operativo bajo licencias distintas.
“No hay nada ‘limpio’ en un modelo de lenguaje que ha ingerido el código que se le pide reimplementar”.
La incertidumbre legal
La situación legal tampoco está definida.
El año pasado, la Corte Suprema de los EEUU rechazó revisar el caso Thaler v. Perlmutter, confirmando que el contenido generado exclusivamente por IA no puede tener copyright.
Esto deja abiertas preguntas importantes:
¿Cuánta participación humana se necesita para reclamar derechos de autor?
¿Quién es responsable legalmente de una reescritura generada por IA?
Ahora bien, el que no se pueda proteger código escrito por la IA no significa que la nueva versión de chardet sea una copia de la versión original.
¿El fin del modelo económico del software?
Algunos pioneros del software libre creen que estamos ante un punto de inflexión.
Armin Ronacher, creador del framework Flask, señala que las licencias copyleft siempre han dependido de la “dificultad”de reescribir código.
Según Perens, esta tecnología podría transformar completamente la economía del software:
“Estoy rompiendo el vidrio y activando la alarma de incendios. La economía del desarrollo de software está acabada”.
Incluso demostró el problema recreando con IA una plataforma completa de System Reliability Engineering (SRE) en cuestión de días y bajo otra licencia.
Hay que decir que esto no es nada nuevo y es algo que ya vemos que está beneficiando a sistemas operativos minoritarios como Linux y macOS ya que se ha vuelto muy sencillo portar aplicaciones de Windows a esos sistemas operativos.
Un punto de inflexión tecnológico
La capacidad de la IA para reescribir software plantea un dilema profundo tanto para empresas propietarias como para el movimiento de código abierto.
Si cualquier base de código puede ser recreada rápidamente mediante el uso de la IA, los límites tradicionales entre software original, derivado y reimplementado podrían desaparecer.
Como señaló Perens, quizá estamos viviendo un momento comparable a la invención de la imprenta:
el conocimiento ha alcanzado una masa crítica, y las reglas que lo rodean están a punto de cambiar para siempre.
