Esta familia estudia cómo conservar función, compatibilidad, comportamiento o interfaces mientras se sustituye una implementación. Su pregunta transversal es: ¿qué parte del sistema debe mantenerse para que siga cumpliendo su función ante otros componentes, y qué parte puede cambiar? La respuesta no es única porque “lo que se conserva” puede ser una salida, una API, una conversación de red, un entorno binario o la continuidad del mismo código en otra plataforma.
El mapa separa tres planos. Adquisición de conocimiento: ingeniería inversa y caja negra. Procedencia y organización: clean room. Artefacto o resultado: reimplementación funcional, de interfaz, de protocolo o plataforma compatible. Porting, rewrite y traducción conservan otro tipo de linaje; AFC pertenece al análisis jurídico posterior. Separar estos planos evita usar “clean room”, “clon”, “ingeniería inversa” y “reescritura” como sinónimos.
Alcance jurídico: las fichas comparan hechos técnicos, textos legales y decisiones judiciales. No ofrecen asesoría jurídica. Copyright, patentes, secretos empresariales, contrato, medidas tecnológicas, competencia y marcas pueden producir resultados distintos según jurisdicción y hechos.
Fichas
- Clean-room implementation — disciplina de procedencia que separa el estudio del original de la escritura de la nueva implementación.
- Reverse engineering for interoperability — extracción de la información necesaria para que un sistema independiente pueda cooperar con otro.
- Black-box analysis — inferencia de reglas mediante entradas, salidas y estado observable sin consultar la estructura interna.
- Functional reimplementation — construcción de una realización nueva para un perímetro explícito de funciones existentes.
- Interface and API reimplementation — conservación de llamadas, tipos, constantes, efectos y ABI que consumen otros programas.
- Protocol reimplementation — conservación de sintaxis, semántica, secuencias y estados de una conversación entre participantes autónomos.
- Compatible implementation and compatible clone — objetivo de sustituibilidad frente a software, datos, periféricos o usuarios de una plataforma.
- Porting — adaptación del mismo linaje de código a otro entorno de ejecución o construcción.
- Rewrite and translation — nueva redacción o cambio de lenguaje basado directamente en una implementación antecedente.
- Abstraction–Filtration–Comparison — método judicial estadounidense para filtrar elementos no protegibles antes de comparar similitud no literal.
Relaciones principales
| Origen | Relación | Destino | Significado |
|---|---|---|---|
| Black-box analysis | technique-for | Reverse engineering for interoperability | La observación externa puede descubrir requisitos de interoperabilidad. |
| Reverse engineering for interoperability | enables | Interface and API reimplementation | Los hallazgos pueden convertirse en un contrato de llamadas y datos. |
| Reverse engineering for interoperability | enables | Protocol reimplementation | El análisis de mensajes y estados puede alimentar otro participante. |
| Clean-room implementation | constrains-provenance-of | Functional reimplementation | La separación controla qué expresión llega a quienes implementan. |
| Interface and API reimplementation | is-a | Functional reimplementation | Conserva una clase delimitada de comportamiento: la interfaz programática. |
| Protocol reimplementation | is-a | Functional reimplementation | Conserva una clase delimitada de comportamiento: la conversación distribuida. |
| Interface and API reimplementation | contrasts-with | Protocol reimplementation | Llamada dentro de una plataforma frente a intercambio temporal entre agentes, con zonas híbridas. |
| Interface and API reimplementation | enables | Compatible implementation and compatible clone | Una plataforma puede volverse sustituible al preservar interfaces consumidas por aplicaciones. |
| Protocol reimplementation | enables | Compatible implementation and compatible clone | Un sistema puede ocupar el rol de otro sin reproducirlo entero. |
| Porting | contrasts-with | Compatible implementation and compatible clone | Portar cambia el programa para el entorno; compatibilizar cambia el entorno para programas existentes. |
| Rewrite and translation | contrasts-with | Clean-room implementation | Rewrite suele conservar acceso y linaje expresivo; clean room restringe ese acceso. |
| Abstraction–Filtration–Comparison | legal-framework-for | Rewrite and translation | Analiza si una nueva redacción conserva expresión no literal protegible; no dirige la ingeniería. |
Fronteras terminológicas
| Elemento | Distinción usada en estas fichas |
|---|---|
| Funcionalidad | Lo que el sistema hace para un usuario o componente. Puede describirse a varios niveles y no equivale al código que la realiza. |
| Idea | Concepción o principio general separable de su formulación. Decidir el nivel de generalidad es parte del problema, no un paso automático. |
| Método de operación | Medio por el que una persona hace funcionar algo; en Lotus, la jerarquía de comandos concreta fue tratada así bajo 17 U.S.C. § 102(b). No toda interfaz queda clasificada automáticamente del mismo modo. |
| Interfaz / API | Frontera programática de nombres, tipos, llamadas y efectos. Puede contener hechos funcionales y elecciones expresivas; su régimen no se reduce a una regla mundial. |
| Protocolo | Reglas de interconexión e interacción: mensajes, significado, orden y estado entre participantes. No es el código interno de ninguno de ellos. |
| Algoritmo | Procedimiento para obtener un resultado. Dos implementaciones pueden compartirlo y expresar sus pasos de manera distinta; copyright, patente y secreto hacen preguntas diferentes sobre él. |
| Estructura | Organización de módulos, datos y flujo a distintos niveles. Parte puede venir dictada por función o entorno y parte puede reflejar elecciones; AFC obliga a filtrar antes de comparar. |
| Código fuente / código objeto | Representaciones legible y ejecutable de un programa. Cambiar de una a otra no elimina el vínculo con la misma implementación ni convierte el código en mera funcionalidad. |
| Expresión literal | Texto, instrucciones o datos copiados de forma directa. Es distinta de compartir un resultado o una idea. |
| Elementos no literales | Organización o relaciones que pueden asemejarse sin líneas idénticas; su posible protección requiere un análisis como AFC en los tribunales que lo usan. |
| Interoperabilidad | Capacidad de sistemas independientes para intercambiar información y usarla con sentido. Es una finalidad técnica; no es por sí sola una excepción jurídica universal. |
| Copia intermedia | Reproducción realizada durante observación, carga o desensamblado y no incorporada al producto final. Sega y Sony analizaron copias concretas como fair use; la calificación depende de hechos y jurisdicción. |
| Desarrollo independiente | Producción sin copiar expresión protegida. Puede apoyarse en registros y separación clean room, pero la etiqueta necesita evidencia de procedencia y no responde por patentes, contrato u otros derechos. |
Casos y proyectos conectables
- IBM PC BIOS — frontera firmware que el software compatible esperaba encontrar.
- Columbia Data Products — MPC de 1982; el Computer History Museum lo identifica como primer clon de IBM PC y documenta una BIOS equivalente creada en clean room.
- Compaq Portable — compatibilidad IBM PC convertida en propuesta comercial portátil; anunciado en 1982 y distribuido en 1983.
- Phoenix ROM BIOS — implementación limpia licenciable desde mayo de 1984; permitió que otros fabricantes compraran la frontera firmware compatible en vez de reconstruirla por separado.
- Computer Associates v. Altai — copia literal en OSCAR 3.4, reescritura 3.5 y formulación de AFC para elementos no literales.
- Sega v. Accolade — desensamblado y copias intermedias para descubrir requisitos de la interfaz Genesis; fair use bajo los hechos del caso.
- Sony v. Connectix — observación y desensamblado de BIOS durante la construcción de una plataforma nueva para juegos PlayStation.
- Lotus v. Borland — compatibilidad de comandos y macros; el Primer Circuito calificó la jerarquía como método de operación.
- SAS Institute v. World Programming — reproducción de conducta y lenguaje SAS; resultados jurídicos distintos en Europa, Reino Unido y Estados Unidos según norma y pretensión.
- Google v. Oracle — reuso de parte de la API Java en Android; la Corte Suprema decidió fair use sin resolver la protegibilidad general de la API.
- Oracle v. Rimini Street — límite útil: interoperabilidad no basta para una obra derivada, pero copias efectivas, licencias y procesos de soporte siguen requiriendo análisis propio.
- Samba — análisis de red y reimplementación de SMB para que sistemas Unix ocuparan roles en redes heterogéneas.
- Wine — capa que reimplementa APIs Windows y traduce llamadas a POSIX, sin reproducir un sistema Windows completo.
- GNU Classpath — biblioteca estándar Java libre con reglas estrictas de procedencia y fidelidad a especificaciones públicas.
- ReactOS — sistema compatible con aplicaciones y controladores Windows, con política documentada de propiedad intelectual y un episodio de auditoría clean room.
Incertidumbres y límites documentales
- Origen del término. 1982 es un hito comercial bien documentado para BIOS compatibles, no una “fecha de invención” demostrada de clean-room implementation.
- “Primer clon”. El Computer History Museum llama a Columbia el primer clon IBM PC; otras narraciones reservan “primer clon totalmente compatible” o “primer clon legal de gran éxito” para Compaq. Las fichas conservan esas proposiciones estrechas en vez de fabricar un único ganador.
- Equivalencia funcional. No existe un umbral universal para declarar que dos sistemas tienen “la misma función”. Cada proyecto debe indicar versión, dominio de entradas, tolerancias, errores y dependientes cubiertos.
- API frente a protocolo. RPC y APIs web mezclan llamadas y conversaciones de red; los nodos se separan por el tipo principal de frontera, no porque toda tecnología caiga limpiamente en uno.
- Compatibilidad dinámica. Wine y ReactOS evolucionan. Aquí son casos para entender mecanismos, no certificaciones actuales de que una aplicación concreta funcione.
- Diferencias jurídicas. Altai, Sega, Sony, Lotus y Google aplican derecho estadounidense en tribunales y cuestiones diferentes; C-406/10 y la Directiva 2009/24/CE pertenecen al marco europeo. Ninguno permite una frase mundial como “las APIs no tienen copyright” o “clean room hace legal copiar”.
- Contrato y copyright. Los litigios SAS y Oracle/Rimini muestran que una conducta puede recibir análisis diferentes bajo copyright, contrato, licencia o remedios. El resultado técnico no debe confundirse con una conclusión jurídica única.
Fuentes troncales
- Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). https://law.justia.com/cases/federal/appellate-courts/F2/982/693/137252/
- Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992). https://law.justia.com/cases/federal/appellate-courts/F2/977/1510/305345/
- Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). https://law.justia.com/cases/federal/appellate-courts/F3/203/596/474793/
- Tribunal de Justicia de la Unión Europea. SAS Institute Inc. v. World Programming Ltd., C-406/10, 2 de mayo de 2012. https://curia.europa.eu/juris/liste.jsf?num=C-406/10
- Parlamento Europeo y Consejo. Directiva 2009/24/CE, de 23 de abril de 2009. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32009L0024
- Supreme Court of the United States. Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021). https://www.supremecourt.gov/opinions/20pdf/18-956_new_o7jp.pdf