Cómo funciona
Reimplementar una interfaz o API significa volver a ofrecer el punto de contacto que usa otro programa sin conservar necesariamente el mecanismo que lo atiende. El trabajo comienza inventariando nombres, firmas, tipos, constantes, estructuras, convenciones de llamada, excepciones, efectos laterales y reglas de versión. Después se implementa cada operación y se prueba con clientes reales o suites de compatibilidad. Lo decisivo no es que dos funciones compartan un nombre: código ya compilado puede depender de su ABI, orden de campos, códigos de error y manejo de memoria; código fuente puede depender de jerarquías de paquetes, sobrecargas y semántica documentada.
GNU Classpath muestra el patrón a escala de biblioteca. El proyecto produjo una implementación libre de las bibliotecas esenciales de Java y exigía que clases, interfaces, métodos y variables públicos coincidieran con la especificación, mientras las clases internas podían organizarse bajo espacios propios. Wine lo realiza a escala de plataforma: expone llamadas de la API Windows y las traduce a operaciones POSIX o X11. En ambos casos, la superficie se conserva para que programas ajenos mantengan su inversión; el código que ejecuta el servicio se sustituye.
Interfaz no equivale a implementación
Una API es una clase de contrato, no todo el comportamiento del producto. Reproducir sólo nombres y firmas puede bastar para compilar y aun así fallar al ejecutar; reproducir resultados comunes puede fallar por una excepción, un callback o una estructura binaria. Por eso esta práctica es un subconjunto enfocado de Functional reimplementation y suele apoyarse en pruebas conductuales. Frente a una Protocol reimplementation, la API suele describir llamadas dentro de un proceso o entre capas de una plataforma; un protocolo añade mensajes entre participantes autónomos, orden temporal y estado distribuido. La frontera puede difuminarse en RPC o APIs web, pero la distinción sigue siendo útil para localizar qué se conserva.
Lotus v. Borland hace visible otra forma de interfaz: Borland permitió que Quattro Pro entendiera macros escritas para la jerarquía de comandos de Lotus 1-2-3. El Primer Circuito consideró esa jerarquía un “método de operación” excluido de copyright por 17 U.S.C. § 102(b); la Corte Suprema confirmó por empate, sin opinión que estableciera precedente nacional. El caso no proclamó que toda interfaz carezca de protección: resolvió esa jerarquía concreta bajo derecho estadounidense y en ese circuito.
Una frontera jurídica dependiente del caso
En Google v. Oracle, Google había copiado parte del código declarativo y de la organización de la API Java al construir Android. La Corte Suprema evitó decidir si la API era protegible: asumió ese punto sólo para el análisis y sostuvo que el uso concreto era fair use. Presentarlo como “la Corte dijo que las APIs no tienen copyright” borra precisamente la cuestión que el tribunal dejó sin resolver. En Europa, SAS Institute v. World Programming trató funcionalidad, lenguaje y formatos de datos como no protegidos, como tales, por el copyright de programas, pero mantuvo separada la posible copia de expresión del manual.
Además del copyright, una reimplementación de interfaz puede tocar patentes, contratos, marcas, secretos o restricciones de acceso. También puede incorporar legítimamente componentes licenciados en vez de reescribirlos. El nombre de la técnica sólo indica qué contrato se preserva; no demuestra desarrollo independiente ni una conclusión jurídica. Esta ficha es conceptual y no constituye asesoría jurídica.
Operación de inventiva
La operación consiste en tratar la frontera como estable y el interior como reemplazable. Obliga a descubrir qué promesas consumen realmente los dependientes: no sólo la forma de la llamada, sino los efectos y excepciones que se volvieron parte del contrato. La inventiva aparece al construir otro interior que honra esas promesas sin reproducir automáticamente la arquitectura que las originó.
Fuentes
- Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir. 1995), aff’d by an equally divided Court, 516 U.S. 233 (1996). Opinión sobre jerarquía de comandos, macros y “método de operación”. https://law.justia.com/cases/federal/appellate-courts/F3/49/807/551122/
- Supreme Court of the United States. Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021). La Corte asumió protegibilidad a efectos argumentales y resolvió fair use. https://www.supremecourt.gov/opinions/20pdf/18-956_new_o7jp.pdf
- Tribunal de Justicia de la Unión Europea. SAS Institute Inc. v. World Programming Ltd., C-406/10, sentencia de 2 de mayo de 2012. https://curia.europa.eu/juris/liste.jsf?num=C-406/10
- GNU Project. GNU Classpath Hacker’s Guide, secciones “Project Goals” y “Specification Sources”. https://www.gnu.org/software/classpath/docs/cp-hacking.html
- GNU Project. “GNU Classpath FAQ”. Define el proyecto como implementación libre de la biblioteca estándar Java y documenta su política de independencia. https://www.gnu.org/software/classpath/faq/faq.html
- WineHQ. “About Wine”. Descripción oficial de traducción de llamadas Windows API a POSIX e historia del proyecto. https://www.winehq.org/about
- ReactOS Project. “Intellectual Property Guideline”, definición de API y política de fuentes. https://reactos.org/intellectual-property-guideline/