ArtCraft: el proyecto en Rust que quiere reemplazar a Adobe con AI… ¿Y qué dice la ley de EE. UU.?

Ojo: esto es información general, no asesoría legal, y habla de la ley de Estados Unidos. En México las reglas son distintas.

1. El código: la parte más firme

El derecho de autor protege el código fuente escrito, no la idea de lo que hace un programa. Un desarrollo “clean-room” busca justo eso: reproducir el comportamiento sin copiar el código. Según los README’s de ArtCraft, las apps se escribieron a partir de especificaciones públicas (ITU-T, ISO, IETF) y observando el funcionamiento del programa. Las reglas para colaboradores y agentes de AI del proyecto dicen textualmente “Never read, disassemble or copy anything inside Adobe application bundles” (nunca leer, desensamblar ni copiar nada dentro de los paquetes de Adobe). Si eso es cierto, el riesgo de infracción de copyright sobre el código es relativamente bajo. Todo depende de que sea cierto y se pueda demostrar.

2. Interfaz y funciones: el terreno del “método de operación”

La Ley de Copyright (sección 102(b)) excluye de protección a los “métodos de operación”. En el caso Lotus v. Borland (1995), el Primer Circuito decidió que la jerarquía de menús de Lotus 1-2-3 era un método de operación y no se podía proteger. Pero ojo: la Corte Suprema quedó empatada 4-4, así que la decisión se mantuvo solo para ese circuito y ningún otro tribunal de apelaciones la ha adoptado.

Más recientemente, en Google v. Oracle (2021), la Corte Suprema decidió que reimplementar parte de una API de Java para Android fue uso legítimo (fair use). Pero lo hizo asumiendo “por el bien del argumento” que ese código era protegible, sin resolver si lo es. Es una señal favorable para quien reimplementa interfaces funcionales, no un cheque en blanco.

3. Trade dress y marcas: la zona más delicada

Aquí está el punto que casi todos los medios señalan, incluyendo Ars Technica según varios reportes. El trade dress protege el aspecto distintivo de un producto cuando puede confundir al público. Si PhotoCraft se parece demasiado visualmente a Photoshop, Adobe podría argumentar confusión. En contra, ArtCraft pone avisos de que no está afiliado ni respaldado por Adobe y usa los nombres solo para describir compatibilidad (algo parecido al uso nominativo de una marca). Las funciones útiles (qué hace cada botón) suelen ser más difíciles de proteger que el diseño ornamental. Qué tan “parecido de más” sea es una pregunta de hecho que decidiría un juez.

4. Patentes: el riesgo que el “clean-room” no cubre

Ser “clean-room” te protege de que te acusen de copiar código, pero no de una patente: una patente cubre una forma de hacer algo, aunque lo hayas inventado por tu cuenta. Según un análisis citado por LinuxCompatible, Adobe tiene miles de patentes de software sobre flujos de trabajo funcionales. No he visto que se haya invocado ninguna contra ArtCraft, pero es un riesgo teórico real.

5. La AI como programadora: autoría y “clean-room”

La Oficina de Copyright de EE. UU. publicó en enero de 2025 la parte 2 de su informe sobre AI: solo se protege la creatividad humana, y los prompts por sí solos no bastan para ser autor del resultado, aunque sí puede protegerse la selección, arreglo o modificación humana creativa del material. Para ArtCraft esto implica una zona gris: si gran parte del código lo escribió un modelo, ¿qué parte es realmente protegible y, por lo tanto, licenciable bajo MIT/Apache? Y no es un detalle menor: sin copyright claro, es más difícil hacer valer una licencia.

Además, está la discusión de fondo: si un modelo entrenado con documentación y descripciones públicas del software que luego reimplementa puede considerarse un “clean-room”. Cuando un mantenedor usó Claude para reescribir la librería chardet y cambiarle la licencia, la directora de la Free Software Foundation opinó que usar un modelo entrenado con ese código no es un proceso limpio. Con Adobe, el argumento no se traslada directo (su código es cerrado), pero la pregunta sigue sin resolverse en los tribunales.

6. Términos de uso y recursos incluidos

Observar un programa “usándolo” también puede chocar con los términos de servicio o licencia de ese programa. Muy poca gente sabe qué dicen los de Adobe —nadie los lee—, así que lo dejo como una duda abierta. Los recursos incluidos (fuentes, íconos, imágenes) conservan sus propias licencias y ArtCraft los documenta en un archivo ASSETS.md, además de aclarar que el nombre y logos de ArtCraft sí son marcas registradas y no son código abierto. Un detalle chistoso: según un resumen, los README’s declaran licencia dual MIT o Apache-2.0, pero la interfaz de GitHub muestra solo Apache-2.0 en algunos repositorios, algo que conviene revisar antes de reutilizar el código.