Cómo funciona
Una rewrite sustituye una implementación existente mediante una nueva redacción; una traducción cambia su representación, manual o automáticamente, a otro lenguaje o nivel. Ambas parten normalmente de acceso directo al código o diseño anterior. Un transpiler puede mapear construcciones sintácticas casi uno a uno; una reescritura manual puede conservar módulos, algoritmos y pruebas mientras cambia arquitectura y estilo. El grado de transformación forma un continuo, pero hay un rasgo común: el original actúa como antecedente directo, no sólo como sistema cuyo comportamiento se observa desde fuera.
C2Rust lo muestra con claridad. Su traductor convierte C99 a Rust inseguro que refleja de cerca el C de entrada para preservar funcionalidad; las pruebas deben seguir pasando y una fase posterior intenta producir Rust seguro e idiomático. Cambiar el lenguaje no elimina de inmediato la estructura, el flujo de control ni las decisiones expresivas de la fuente. La traducción facilita una migración verificable precisamente porque conserva mucho; esa misma continuidad impide usar “está en otro lenguaje” como prueba de independencia.
Rewrite no significa clean room
En Computer Associates v. Altai, un empleado había copiado parte del código ADAPTER al programa OSCAR 3.4. Tras conocer el problema, Altai organizó una reescritura que produjo OSCAR 3.5; el tribunal observó que prácticamente no quedaron líneas idénticas. Sin embargo, el Segundo Circuito no trató el mero acto de reescribir como un salvoconducto. Aplicó Abstraction–Filtration–Comparison a elementos no literales, filtró ideas, exigencias funcionales y material público, y comparó la expresión restante. El episodio demuestra dos cosas distintas: eliminar identidad literal puede corregir una dimensión del problema, pero estructura no literal y procedencia todavía requieren análisis.
Una Clean-room implementation restringe qué expresión ve el equipo implementador; una rewrite suele requerir verla. Una Functional reimplementation puede coincidir en el resultado, pero empieza desde un contrato o conducta y admite una arquitectura sin linaje directo. Aun así, una reescritura “desde cero” puede convertirse operacionalmente en reimplementación independiente si se define desde especificaciones y pruebas, no desde el código anterior. Para que la etiqueta sea informativa hay que decir qué materiales consultó quién, qué artefactos se conservaron y cómo se validó el resultado.
Relación con porting y derecho
Porting cambia el entorno objetivo y procura conservar el mismo programa; una rewrite cambia la implementación aunque permanezca el entorno. En la práctica se solapan: portar a otra arquitectura puede exigir reescribir ensamblador, y traducir a otro lenguaje puede obligar a adaptar bibliotecas de plataforma. La diferencia útil está en la variable principal que se sustituye.
En Estados Unidos, la Copyright Office ha tratado para fines de registro una traducción entre lenguajes como programa derivado y su Compendium actual incluye como ejemplo un programa traducido de C++ a C#. Eso no decide automáticamente una disputa ni significa que toda semejanza funcional esté protegida: autoría, licencia, elementos copiables, excepciones y jurisdicción siguen importando. La Directiva europea reserva al titular determinadas traducciones y adaptaciones, a la vez que prevé excepciones concretas para uso legítimo e interoperabilidad. Esta ficha no ofrece asesoría jurídica; sólo impide confundir cambio de sintaxis con independencia de expresión.
Operación de inventiva
La operación consiste en cambiar la forma de una solución conocida mientras se decide cuánto de su organización debe sobrevivir. La traducción maximiza continuidad para reducir riesgo funcional; la reescritura puede gastar esa continuidad para obtener otra arquitectura, seguridad o mantenibilidad. La restricción decisiva es el linaje: cada elemento conservado facilita verificar comportamiento, pero limita cuánto puede afirmarse que la nueva realización es independiente.
Fuentes
- Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). Historia de OSCAR 3.4/3.5 y análisis de similitud no literal. https://law.justia.com/cases/federal/appellate-courts/F2/982/693/137252/
- U.S. Copyright Office. Compendium of U.S. Copyright Office Practices, Third Edition, cap. 700, especialmente §§ 721.2 y 721.8 sobre programas derivados y nuevo material. https://www.copyright.gov/comp3/docs/compendium.pdf
- U.S. Copyright Office. Compendium II of Copyright Office Practices (1984), § 323.01. Incluye el ejemplo histórico de traducción de COBOL a FORTRAN. https://www.copyright.gov/history/comp/compendium-two.pdf
- C2Rust Project. “README”. Describe una traducción de C99 a Rust inseguro que refleja el original y usa las pruebas como criterio de preservación funcional. https://github.com/immunant/c2rust/blob/master/README.md
- C2Rust Project. “Cross-checks”. Instrumentación para comparar ejecuciones de código C y Rust traducido. https://github.com/immunant/c2rust/tree/master/cross-checks
- Parlamento Europeo y Consejo. Directiva 2009/24/CE, arts. 4–6, sobre reproducción, traducción, adaptación y descompilación para interoperabilidad. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32009L0024