Grit: reescribiendo Git en Rust con agentes
(blog.gitbutler.com)- Grit es un proyecto que reimplementa Git desde cero como una biblioteca basada en Rust, con el objetivo de crear un núcleo reentrante y enlazable que interactúe formalmente con repositorios Git
- Git es un software complejo que miles de personas han ampliado durante 20 años alrededor de combinaciones de comandos, y su estructura tiene el problema arquitectónico de incurrir en el costo de
fork/execen cada operación dentro de procesos de larga duración - Grit se desarrolló tomando como referencia más de 1,400 scripts y más de 42,000 pruebas del proyecto Git, y al final logró pasar 41,715 / 42,001 pruebas {p:99}
- La versión actual aún carece de suficiente validación en uso real y tiene limitaciones como funcionamiento lento, API sin pulir, falta de compilación para Windows y posibilidad de corrupción de datos
- El desarrollo basado en agentes permitió empujar rápidamente un port de gran escala, pero también dejó ver que los desafíos clave están en evitar atajos para pasar pruebas, roturas del harness, coordinación, recursos y control de costos
Objetivos y contexto de Grit
- Grit fue un intento de reimplementar Git no como un port del código en C, sino como una nueva implementación centrada en una biblioteca Rust
- El objetivo era crear una biblioteca núcleo puramente en Rust capaz de interactuar formalmente con repositorios Git
- El núcleo busca ser reentrante, enlazable, modular y con una estructura integral
- Un crate de CLI separado usa esta biblioteca y valida su nivel de completitud tratando de pasar la mayor parte posible de la suite de pruebas de Git
Por qué reimplementar Git
- Git es un software complejo con muchos comandos de bajo nivel de tipo plumbing y comandos de alto nivel de tipo porcelain
- Git tradicional no está construido sobre una biblioteca reentrante y enlazable, sino sobre una estructura más cercana a la filosofía Unix de encadenar comandos simples
- En esta estructura, cuando un proceso de larga duración usa funciones de Git, se incurre en el overhead de
fork/execen cada tarea - El proyecto Git cuenta con más de 42,000 pruebas repartidas en más de 1,400 scripts, así que su comportamiento puede validarse con un criterio bastante concreto
Estado actual y advertencias
- Grit es una reimplementación de Git en Rust, segura en memoria y basada en bibliotecas, creada desde cero, y pasa más del 99% de la suite de pruebas de Git
- Algunas pruebas se omitieron intencionalmente, entre ellas funciones relacionadas con correo electrónico, i18n, el importador de Perforce/SVN y algunos elementos de midx/bitmap
- Dentro del alcance considerado relevante para la mayoría de lectores, la biblioteca y el CLI de Grit sí pasan la suite de pruebas de Git
- Aún falta validación en proyectos reales, y existe la posibilidad de comportamiento incorrecto o corrupción de datos
- Las limitaciones actuales incluyen rendimiento lento, funciones no probadas, una API desordenada y ausencia de compilación para Windows
Posibles usos
- GitButler y herramientas Git independientes podrían usar Grit para integrar funciones de red complejas como push/fetch
- Las funciones de red de Gitoxide y libgit2 son parciales, lentas o inexistentes
- GitButler y Jujutsu dependen de hacer
forka procesos Git para manejar datos de push/pull - La lógica compleja de credenciales es una de las grandes razones, y en teoría Grit cubre esa área
- Una compilación WASM podría permitir usos como ejecutar casi cualquier comando Git dentro de funciones edge de Vercel
- Funciones como Cloudflare Artifacts podrían usar una compilación WASM totalmente compatible de Grit en lugar de una implementación parcial como isomorphic-git
- Si las funciones de Git se dividen en piezas de biblioteca embebibles por separado, también sería posible crear funciones personalizadas de cliente o servidor Git basadas en Rust
- La compilación completa actual de las funciones Git en Rust pesa alrededor de 27 MB, pero podría dividirse en subcrates por dominio funcional para usar solo lo necesario
Seguridad de memoria
- La mayor parte del código de Grit está escrita en safe Rust
- Las únicas partes que realmente necesitan comunicarse con C vía FFI son básicamente un módulo de fecha/hora y una verificación de TTY
- Se necesita ese FFI porque no existe un reemplazo puro en Rust para
localtime_r,strftimeymktimeque maneje correctamente el entorno TZ - Fuera de eso, el código de Grit está compuesto en safe Rust
Problemas detectados en el desarrollo con agentes
-
Los agentes pueden tomar atajos para pasar pruebas
- El objetivo de “hacer que pase las pruebas de Git” podía llevar a un agente a escribir una función trivial que simplemente delegara la operación a Git
- En el archivo AGENTS fue necesario dejar reglas base muy explícitas, como prohibir atajos
- En el soporte para sha256, la prueba solo verifica que después de
git init --object-format=sha256,rev-parse --show-object-formatimprimasha256 - Grit pasó esa prueba porque guardó correctamente los metadatos de configuración, pero no se comprobó realmente que
add,commitylogfuncionaran en un repositorio sha256 - El agente solo implementó lo necesario para satisfacer lo que revisaba la prueba, no soporte real para objetos sha256
-
Los agentes no saben qué fue lo que rompieron
- Uno de los agentes en paralelo rompió una parte fundamental del harness de pruebas, lo que hizo parecer que había regresiones masivas
- Por este problema se llegó a pensar que el trabajo en paralelo estaba causando más daño que beneficio, y el proyecto casi se detuvo por un tiempo
- Tras retomar el trabajo a inicios de junio, un agente encontró y corrigió el error del harness, y la tasa de pruebas aprobadas volvió a subir hasta alrededor del 80%
- Esa recuperación fue lo que impulsó al proyecto a llevarlo hasta el final
-
El trabajo paralelo de largo plazo es difícil de coordinar
- Dividir una lista compartida de tareas entre varios agentes de larga ejecución resultó más difícil de lo esperado
- Compartir un archivo de planificación con casillas se volvió desordenado, y enfoques como Linear o GitHub Issues requerían acceso de red, autenticación y configuración de herramientas según el cliente
- En la etapa final se usó el sistema local de tickets Ticgit para editar la lista de tareas localmente y moverla con Git
- También siguió habiendo fricción al momento de empaquetar fácilmente el estado del trabajo entre varios sistemas para hacer handoff a otro entorno
Recursos y costos
- El trabajo se hizo en varios entornos, incluyendo una laptop, una Mac Studio, un servidor de Hostinger y Cursor cloud agents
- La compilación de Rust exigió más CPU y memoria de lo esperado al ejecutarse en paralelo
- Los agentes pudieron depurar y corregir problemas como swap thrashing y CPU thrashing, pero la gestión de recursos siguió siendo difícil
- El costo de uso de Cursor y Anthropic no se calculó con exactitud, pero se estima en alrededor de $10,000~$15,000
- El consumo de tokens fue aproximadamente de 14 mil millones en Claude Code, 12 mil millones en Cursor GPT/Codex y 16 mil millones en Cursor composer-2, para un total cercano a 45 mil millones de tokens
- El modelo
composer-2de Cursor completó casi la mitad del proyecto mediante muchos cloud agents cortos y enfocados
Enfoques de agentes utilizados
-
OpenClaw + Claude Code
- Al principio se trabajó remotamente ejecutando subagentes de Claude Code con OpenClaw
- Debido al uso de la API por token, en pocos días se generó la mayor parte del costo total del proyecto
- La estabilidad de ejecución fue baja por problemas de memoria y CPU, además de fallas en el servidor de Hostinger
-
Cursor cloud agents
- Para reducir el aumento de costos, se cambió a una estrategia que aprovechaba tokens de suscripción y modelos más baratos
- Gran parte del proyecto avanzó lanzando un Cursor cloud agent por cada archivo a trabajar y fusionando el resultado al terminar
- Algunas pruebas cambiaban el entorno, hacían que el binario de Grit se usara en lugar de Git o rompían el almacén de credenciales, haciendo fallar
git pushdentro del contenedor - En muchos casos hubo que entrar manualmente al terminal del contenedor, volver a agregar el remote y hacer push del commit
-
Cursor cloud grind mode
- Si en Cursor cloud agent se elige el selector de modelo
Long-running, el trabajo continúa por largo tiempo en “Grind mode” - Se operaba con prompts como “haz que pase toda la familia de pruebas t1” y luego se esperaba un día para ver un PR con 100 commits acumulados
- Este terminó siendo el enfoque preferido entre varios intentos
- Si en Cursor cloud agent se elige el selector de modelo
-
Modo
/goaly Claude dynamic workflows- El modo
/goalde Codex y Claude Code también realizaba trabajos largos similares - El modo
/goalde Codex siguió avanzando, pero Claude se detenía con frecuencia y requería intervención - En la última semana se usó el modo de esfuerzo “Ultracode” de Claude dynamic workflows para dividir familias grandes de pruebas
- Como las compilaciones paralelas de
rustcpueden consumir demasiada CPU y memoria y volverse lentas, fue necesario gestionar los recursos
- El modo
Formas de trabajo que resultaron más efectivas
- Una estrategia escalonada definida por personas dio resultados más rápidos que dejar que un grupo de agentes con coordinación ligera eligiera el siguiente archivo de prueba
- Funcionó bien un enfoque bottom-up que empezaba por comandos básicos de plumbing y luego subía a comandos importantes que dependen de ellos
- Partes como la salida del formato diff, de la que casi no dependen otras funciones, era mejor resolverlas al final
- Cuando el orden para abordar los problemas se definía con detalle y se entregaba por etapas, los resultados fueron buenos; cuando se paralelizó a lo grande sin mucho control, hubo más problemas y estancamiento
Licencia
- El código fuente de Git tiene licencia GPL, y libgit2 usa una estructura con linking exception sobre GPL porque enlazar es parte central de su propósito
- La licencia de libgit2 ha sido objeto de discusión desde hace tiempo y sigue siendo un tema abierto
- Tras revisar el código generado por LLM y los amplios cambios de arquitectura necesarios para convertirlo en biblioteca y hacerlo seguro en memoria, se concluyó que el codebase de Grit no debe considerarse una obra derivada que deba heredar GPL
- El código de Grit se publica con licencia MIT
- La decisión puede ser polémica, pero se consideró la mejor opción para la comunidad Git en un sentido más amplio
Resultado final
- El trabajo avanzó durante unas semanas de abril, luego se detuvo y se terminó en la primera semana de junio
- El tiempo real dedicado fue de unas 2 a 3 semanas trabajando algunas horas al día, y la mayor parte se fue en coordinar ejecuciones en segundo plano, integrar cambios o encontrar problemas
- El tamaño final del código supera las 360,000 LOC
grit-libtiene alrededor de 100,000 LOCgrit-clitiene alrededor de 260,000 LOC- Es aproximadamente comparable al tamaño del código C de Git sin contar headers
- El resultado se construyó a lo largo de más de 500 pull requests y más de 7,000 commits
- El resultado de pruebas fue de 41,715 aprobadas de 42,001, con una tasa de aprobación del 99.3%
- La página oficial del proyecto es https://grit-scm.com
3 comentarios
https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
Viendo la controversia sobre la licencia, me viene a la mente un caso anterior.
https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201
Es bastante desagradable. ¿Por qué Grit-lib sigue siendo MIT?
Comentarios en Hacker News
Parece que será un punto interesante la parte que dice: “Tras revisar el código generado por el LLM, concluimos que este código base no debía heredar la GPL como obra derivada, porque hacer la implementación reutilizable como biblioteca y segura en memoria requirió cambios arquitectónicos bastante grandes y amplios, así que decidimos publicarlo bajo MIT”
Pero si al traducir un libro empiezas a cambiar incluso la trama y la personalidad de los personajes, se vuelve ambiguo en qué momento deja de ser una obra derivada. No soy abogado, pero supongo que en la jurisprudencia sobre obras creativas este límite se ha tratado bastante
En un ambiente como el actual, donde el alcance de la “propiedad intelectual” sigue ampliándose, si se admite que el LLM tuvo acceso al código fuente de Git, la posición legal parece débil
Según Jplag, la similitud máxima entre los codebases es menor al 1.8%, se hizo de buena fe y creo que también beneficia a todo el ecosistema de Git. Claro, eso supone que Grit realmente llegue a ser útil; por ahora no estamos en una etapa para afirmarlo
Desde la perspectiva del copyright, de todo esto solo el primer punto es relevante. Grit es una implementación escrita de forma independiente de un comportamiento compatible con Git, y considero que la similitud con el código fuente de Git es lo bastante insignificante como para ignorarla
antirez resumió bien la situación y en general estoy de acuerdo: https://antirez.com/news/162
Quienes me conocen y han trabajado conmigo en Git y en la comunidad de código abierto durante los últimos 20 años saben que mi intención es contribuir, compartir y promover la innovación y el aprendizaje. Varios de los principales autores del código fuente de Git son mis amigos, y no tengo en absoluto la intención de robarle nada a nadie. Solo quiero hacer que las grandes ideas sean más ampliamente útiles
https://news.ycombinator.com/item?id=47350424
Como con 1984 o Torment Nexus, alguien tomó como manual de instrucciones una idea que debió haber entendido como advertencia
Por ejemplo, supongamos que extraes el binario de Goldeneye de N64, haces que un LLM lo desensamble y luego lo reescriba en un lenguaje moderno de alto nivel. ¿Nintendo diría “como le metiste mucho esfuerzo, ya quedó fuera de nuestra licencia”? Claro que no. No tiene sentido
Darle el código fuente y hacer que produzca un resultado en otro lenguaje es claramente una obra derivada. No hace falta ser abogado de propiedad intelectual para saberlo
En cambio, si solo le dieras documentación a Claude y le pidieras crear una implementación compatible, ¿sería una obra derivada sujeta a la GPL? Probablemente sí, pero ya no puedo decirlo con 100% de certeza, y no asumiría ese riesgo
Como otro experimento mental, si alguien metiera este árbol de código fuente con “licencia MIT” en otro LLM y le pidiera que lo escupiera en C, ¿qué pasaría con la licencia? Como hay formas limitadas de crear hashes SHA1 o de hacer un parser de línea de comandos, podría quedar bastante parecido
Este también fue uno de los puntos clave en el caso Oracle v. Google. Google argumentó con éxito que, como hay maneras limitadas de escribir un bucle, el hecho de que hubiera bucles similares al original no implicaba automáticamente infracción de copyright
En cualquier caso, adoptar una postura así es realmente forzado
No lo entiendo. Gitoxide ya existe y es excelente
Puede que le falten partes, pero sería más fácil agregarle a Gitoxide mantenido las funciones de red necesarias con vibe coding que quemar tokens intentando clonar Git completo otra vez
Git quiere una incorporación en Rust, y Gitoxide es un proyecto de varios años, así que probablemente tenga mejor mantenimiento que un clon improvisado hecho con vibes que “dice pasar las pruebas”
No me opongo al clon vibe en sí si hay un caso útil, pero en este caso no le veo ventajas. Git es una herramienta que a mucha gente le gusta, no una situación como vinext, que salió por rechazo al vendor lock-in de Next.js
La gerencia también debería saber que la historia de “quemamos miles de dólares en tokens para hacer nuestra copia de software querido” no es algo que la comunidad vaya a recibir positivamente, incluso dejando de lado las disputas de copyright y licencias
No se siente bien ver que una obra que te gusta sea duplicada sin ningún beneficio. Ya pasamos la etapa de “experimento para ver hasta dónde puede llegar la IA”
Ha habido intentos recientes de meter más funcionalidad de Git en Gitoxide mediante vibe loops, y eso es interesante: https://github.com/GitoxideLabs/gitoxide/pull/2538
Aun así, creo que este proyecto podría tener valor con un poco más de trabajo. Este anuncio no es el producto final, solo un hito. Incluso a mitad del proyecto no estábamos seguros de si esto sería posible
Hemos aprendido mucho y todavía aprenderemos más, pero tanto Gix, una biblioteca parcial de Git de alta calidad, hecha a mano y con criterios claros, como Grit, una biblioteca Git hecha con vibes, más cercana a una implementación completa pero algo desprolija, podrían tener casos de uso útiles. Por ahora creo que vale la pena explorar e invertir en ambas opciones
Además, yo soy parte de la gerencia involucrada, y a lo largo de los años he hecho bastante por la comunidad de Git. La idea de que quiero tener “mi propia copia” no tiene sentido
Escribí y publiqué como open source el libro Pro Git(https://git-scm.com/book/en/v2) y antes de eso Git community book(https://schacon.github.io/gitbook/index.html), hice el sitio web oficial de Git(https://git-scm.com), cofundé GitHub, que aloja casi todo el open source del mundo, y llevo casi 20 años promoviendo y apoyando el ecosistema de Git
Hace 15 años reinicié y financié el desarrollo de libgit2; también se podría afirmar que eso era gerencia queriendo su “propia copia” de Git con una licencia más permisiva, pero esa afirmación sería igual de absurda
Probablemente concluyeron que gitoxide no era suficiente para su caso de uso, o que el costo de extenderlo y mejorarlo era demasiado alto
La seguridad de memoria y cosas así están bien, pero sinceramente no entiendo para qué caso de uso sería esto
¿Es para mostrar desarrollo estilo agente? Llevo más de 10 años usando Git y nunca me ha fallado por un desbordamiento de memoria o algo parecido. Hay software que entra en la categoría de “ya es suficientemente bueno”, y estoy bastante seguro de que Git entra ahí
Incluso en equipos con más de 20 desarrolladores y muchos artefactos binarios, casi nunca me he topado con los límites de Git. Si realmente estás llevando Git al límite, quizá tengas que salirte de Git, y una reescritura en Rust no ayuda en nada. Así que lo vuelvo a preguntar: ¿por qué?
Incluso para hacer algo pequeño tienes que hacer fork/exec de un proceso y comunicarte por stdin/stdout. O reimplementarlo todo por tu cuenta y manejar todos los casos límite
Por ejemplo, leer un objeto es fácil si es un objeto loose, pero es mucho más difícil si está dentro de un packfile. Leer una referencia, es decir, ver a qué SHA apunta una rama, también puede implicar un archivo loose, un packfile o una reftable
Nadie va a usar esto para CLI. Incluso si se estabiliza, casi seguro siempre será más lento y peor en todos los aspectos. Ahora mismo ni siquiera es estable
Puedes usar libgit2 o Gitoxide, y ambos son proyectos que ayudé a iniciar o que GitButler está ayudando a impulsar actualmente. Son más rápidos y mejores en casi todo, pero no tienen funcionalidad completa
Esto no es para gente que usa Git, sino para gente que quiere crear herramientas que usen partes de Git
Ahora parece que las licencias de software ya no significan nada, porque cualquiera puede decidir que su clon hecho con LLM no es una obra derivada
Hace poco Casey Muratori dijo algo parecido en un contexto similar: que el impulso de Microsoft por la IA podría estar relacionado con el hecho de que tienen una base de código vieja y enorme. Las grandes empresas de software antiguas tienen ventajas en el entrenamiento de modelos y pueden aportar valor adicional con su propiedad intelectual
Pero ahora esa propiedad intelectual podría quedar metida dentro del modelo y volverse accesible para cualquiera. Si realmente entrenan un modelo con su propia propiedad intelectual, cualquiera podría implementar esa API y ponerle una licencia GPL
A partir de ese punto la cosa se va a poner realmente interesante
Esto es plagio de código GPL y lavado de licencia.
Puedo entender trabajar en reversa a partir del suite de pruebas, pero esto literalmente lee el código fuente original: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
Parece que los usuarios de LLM viven en otro mundo, donde todo lo que no está clavado al piso se puede robar y presentar como si fuera trabajo propio
Por ejemplo, eso fue exactamente lo que hice cuando intenté hacer que la firma de commits por SSH funcionara bien en GitButler: https://blog.gitbutler.com/signing-commits-in-git-explained
Como se puede ver en el artículo, me metí en el código fuente en C para averiguar el comportamiento correcto, y luego implementé lo mismo en Rust, pero sin copiar el código fuente
Hay algunas similitudes entre el código fuente en Rust de Grit y el código de Git, pero en su mayoría son cosas como el manejo de tiempo y formato, o desplazamientos de bytes necesarios para parsear packfiles. A mí no me parece que haya copia directa de código
Para convertir esto en una base de código reentrante, segura en memoria y centrada en bibliotecas, la aproximación es tan distinta que copiar en general no resulta útil
Pero los formatos binarios de packfile o reftable no están documentados adecuadamente, así que nadie puede acertarlos por simple adivinanza. Lo sé bien porque probablemente fui una de las pocas personas que intentó documentar el formato binario de packfile: https://schacon.github.io/gitbook/7_the_packfile.html
No queda más remedio que leer el código fuente. Bajo esta definición, libgit2, Gitoxide y todas las demás reimplementaciones de Git también serían “lavado de licencia”, porque tuvieron que consultar el código fuente de Git para verificar la especificación técnica
Si encuentras en Grit código claramente copiado línea por línea, dímelo. Lo reemplazaré. Pero el código fuente de Git es, en sí, la especificación de Git, y con o sin LLM, toda reimplementación se ve obligada a este tipo de enfoque para lograr compatibilidad
No entiendo cómo otros dueños de propiedad intelectual —por ejemplo, quienes tienen software privativo valioso, o música, películas, e incluso los propios LLM— no piensan que el leopardo va a venir a comerles la cara después
Esta erosión de la propiedad intelectual tiene que detenerse. Si no, cualquiera que haga trabajo intelectual va a quedar completamente arruinado. Si solo afectara a la gente de FOSS, me preocuparía que la tiraran junto con el agua de la bañera, pero claramente esto aplica de forma general
Ya había usado antes la analogía de “pedirle un deseo a un genio: hay que dejar las reglas básicas realmente claras”
Antes se sentía más cercano a un gólem, pero por el modo de sabotaje de Fable https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html ahora definitivamente parece más un genio
Antes lo expresaba como “el modelo no te da lo que quieres, te da lo que pediste”. Ahora, como en Fable ni siquiera te da lo que quieres, ya no sé
Si es por experimentar, en realidad me interesaría más ver lo contrario. Este tipo de proyectos por lo general parecen reescribirse por “rendimiento”, probablemente porque la IA bajó el costo de hacerlo
Me gustaría ver trabajos raros pero divertidos, como portar Quake III a Python, o Kubernetes a Perl, o incluso Rails a Python
Según recuerdo, la mayor parte de Natural Selection 2 estaba hecha en Lua, y eso ya fue hace más de 10 años
Es más lento, tiene menos pruebas, y básicamente produjeron una implementación incompleta de Git por apenas 10 mil a 15 mil dólares
Y en el proceso también desperdiciaron bastante tiempo humano
También ya se había mencionado que en otra parte algún grupo estaba haciendo un port a Rust. ¿Cuánto se habría podido lograr si esa cantidad de dinero y recursos de desarrollo de software se hubieran invertido ahí?
Parece que ya quedó demostrado que la IA puede portar algo si no se prueba con suficiente rigor. Cada vez le veo menos valor a este tipo de trabajo. Puede que haya sido divertido para el autor, pero no sé cómo ayuda a los demás
Todo el movimiento RiiR es muy claramente un intento de alejarse de la GPL, que es una licencia favorable para el usuario
Estoy de acuerdo con la primera parte de “es un experimento bastante interesante, y creo que se puede pulir hasta convertirlo en algo realmente útil para toda la comunidad”. Los experimentos los podemos disfrutar entre todos.
Pero en la parte de “como no es una biblioteca enlazable y reentrante, sino que está basado en la filosofía Unix de encadenar comandos más simples, es difícil usarlo en procesos de larga duración sin el overhead de fork/exec en cada ocasión” sí tengo una diferencia filosófica.
Es el único pasaje de todo el texto donde se explica el “por qué”, y hasta se podría decir que la forma Unix es una funcionalidad y que hoy es incluso más importante: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic
La frase completa “como no es una biblioteca enlazable y reentrante, sino que está basado en la filosofía ‘Unix’ de encadenar comandos más simples, es difícil usarlo en procesos de larga duración sin el overhead de fork/exec para todas las tareas” es el punto clave.
Llevo más de 15 años usando Git y ni una sola vez he sufrido un crash. ¿Qué problema se supone que está resolviendo esto?
gcy el pruning provocaban cierres inesperados durante un tiempo.Aun así, la estabilidad general ha sido realmente excelente. Pero no puedo responder al “¿por qué?” de esta reescritura en particular.
Se meten a hacer cosas de forma completamente inconsciente e ingenua, y perdieron la capacidad de pensar por sí mismos. En cambio, el LLM que piensa por ellos no les va a decir “hacer X es una mala idea”. El LLM existe para producir tantos tokens como sea posible para su dueño.
Esto viene de un cofundador de GitHub, alguien que muy probablemente sabe exactamente para qué existe la GPL.
Más allá de cuáles sean las ventajas o desventajas legales, construir sobre toda la suite de pruebas de un proyecto GPL3 y luego volver a licenciarlo como MIT no es actuar de buena fe con los autores originales.
Me parece realmente asqueroso y me dan ganas de evitar por completo todo GitButler.
No puedes elegir una licencia y luego, porque no te gustó el resultado, agregar condiciones extra después. Eso es precisamente algo que la licencia GPL no permite explícitamente.