Os avogados de Oracle comparan a reimplementación da API de Java en Android coa copia do contido de "Harry Potter". pdf

O Tribunal Supremo dos Estados Unidos coñecerá un caso importante a principios deste ano. Oracle vs Google, que determinará a situación legal da API en virtude da lei de propiedade intelectual. Se o tribunal está do lado de Oracle na súa demanda multimillonaria, podería sufocar a competencia e consolidar o dominio dos xigantes tecnolóxicos, posiblemente incluíndo o propio Google.

Ao mesmo tempo, o negocio de Oracle construíuse inicialmente sobre a implementación da linguaxe de programación SQL desenvolvida por IBM, e aínda agora a compañía ofrece un servizo na nube cunha API de Amazon S3, e isto é completamente normal. A reimplementación da API foi unha parte natural do desenvolvemento da informática desde o inicio da industria.

Oracle acusa a Google de copiar ilegalmente a API de Java, incluíndo unha lista de comandos con nome vinculados a estruturas gramaticais. O sistema operativo Android é especialmente compatible coa API de Java para facilitar aos programadores de Java a transferencia de software e coñecemento á nova plataforma. Para iso, Android copiou exactamente os comandos e estruturas gramaticais da API de Java correspondentes. argumento Oracle é que esa "reimplementación" da API de Java pode compararse coa copia da obra dun autor, como a novela literaria "Harry Potter" (esta un exemplo real dado polos avogados de Oracle), e Google viola os dereitos de autor de Oracle sobre os nomes e estruturas de comandos da API de Java.

Pero as API de Java non son as únicas API e Android non é a única reimplementación. Na industria de TI actual, as API son omnipresentes e a reintrodución é fundamental para manter a competencia e evitar que as grandes empresas monopolicen considera Charles Duane é director de tecnoloxía e política de innovación do R Street Institute.

Duane pon o exemplo da popular plataforma de almacenamento Amazon S3. Para permitir a escritura e a recuperación de ficheiros desde S3, Amazon desenvolveu API detallada para interactuar co servizo. Por exemplo, para obter unha lista de ficheiros gardados (ListaObxectos) enviamos un comando GET especificando os parámetros de host e tipo tipo de codificación, ficha de continuación и x-amz-date. Para traballar con Amazon S3, o software debe usar estes e moitos outros nomes de parámetros específicos exactamente.

GET /?Delimiter=Delimiter&EncodingType=EncodingType&Marker=Marker&MaxKeys=MaxKeys&Prefix=Prefix HTTP/1.1
Host: Bucket.s3.amazonaws.com
x-amz-request-payer: RequestPayer

Amazon é o claro líder no mercado de servizos na nube e os seus competidores ofrecen reimplementacións da API S3, mentres que teñen que imitar nomes de comandos, etiquetas de parámetros, prefixos de tipo. x-amz, estrutura gramatical e organización xeral da API S3. Noutras palabras, todo o que afirma Oracle está protexido por dereitos de autor.

Entre as empresas que ofrecen unha copia da API de Amazon S3 están tamén está o propio Oracle. Para a compatibilidade, a API de compatibilidade de Amazon S3 copia numerosos elementos da API de Amazon, ata as etiquetas x-amz.

Oracle afirma que a legalidade das súas accións está baseada na licenza Apache 2.0 de código aberto, que permite copiar e modificar o código gratuíto. Por exemplo, Amazon SDK para Java tamén vén cunha licenza Apache 2.0.

Pero a cuestión é se a lei de propiedade intelectual se aplica incluso a cousas como as API. Isto é o que debe determinar o Tribunal Supremo.

Quen inventou a API?

O termo e concepto de "biblioteca de subrutinas" apareceu por primeira vez no libro Planning and Coding Problems for an Electronic Computing Instrument - Part II, Volume III (Princeton University Institute of Advanced Study, 1948) de Herman Goldstein e John von Neumann. copia en archive.org. Contido do terceiro volume:

Esta é a primeira descrición dunha metodoloxía de programación para ordenadores que almacena programas na memoria (antes non existía). Foi amplamente distribuído polas universidades, que daquela tentaban crear os seus propios ordenadores. E o máis importante, o libro contén unha idea clave: a maioría dos programas usarán operacións comúns e as bibliotecas con rutinas reducirán a cantidade de novos códigos e erros. Esta idea foi perfeccionada aínda máis por Maurice Wilkes e posta en práctica na máquina EDSAC, pola que recibiu o Premio Turing de 1967.

A biblioteca de subrutinas EDSAC está á esquerda

O seguinte paso foi crear funcións de orde superior e interfaces de software completos, como fixeron Maurice Wilkes e David Wheeler en Preparing Programs for the Electronic Digital Computer (1951).

O termo en si Interface do programa de aplicación (API) apareceu nalgún lugar a finais dos anos 60.

Autor da presentación "Unha breve historia subxectiva da API" Joshua Block dá varios exemplos de interfaces de programación, conxuntos de instrucións e bibliotecas de subrutinas: como foron creadas e utilizadas posteriormente. A idea é que a reutilización é o punto dunha API. Para iso foron creados en primeiro lugar. E os desenvolvedores sempre tiveron a oportunidade de copiar e refacer as API doutras persoas:

API
Creador
Ano
Reimplementación
Ano

Biblioteca FORTRAN
IBM
1958
Univac
1961

IBM S/360 ISA
IBM
1964
Amdahl Corp.
1970

Biblioteca estándar C
AT&T/Bell Labs
1976
Mark Williams Co.
1980

Chamadas ao sistema Unix
AT&T/Bell Labs
1976
Mark Williams Co.
1980

VT100 Esc Seqs
Decembro
1978
Heathkit
1980

BIOS de PC IBM
IBM
1981
Phoenix Technologies
1984

CLI de MS-DOS
Microsoft
1981
Proxecto FreeDOS
1998

Conxunto de comandos Hayes AT
Hayes Micro
1982
Anchor Automation
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Proxecto Samba
1993

Win32
Microsoft
1993
Proxecto do viño
1996

Bibliotecas de clases Java 2
Sol
1998
Google/Android
2008

API web Delicious
delicioso
2003
Taboleiro de anuncios
2009

Fonte: "Unha breve historia subxectiva da API"

Copiar e reutilizar API (bibliotecas, conxuntos de instrucións) non só é correcto, senón que esta metodoloxía de programación está directamente recomendada nos canons da informática. Mesmo antes de copiar interfaces de programación S3, o propio Oracle fixo isto moitas veces. Ademais, o negocio de Oracle construíuse inicialmente na implementación da linguaxe de programación SQL desenvolvida por IBM. O primeiro produto insignia de Oracle foi un DBMS, copiado en gran parte de IBM System R. Neste caso, estamos a falar da reimplementación de SQL como "API estándar" para un DBMS.

Impoñer dereitos de propiedade intelectual ás API pode crear un campo minado legal que afecta a todos. As interfaces API implementan e outros servizos na nube. Moitos estándares técnicos, como Wi-Fi e protocolos de Internet, inclúen API. As interfaces de programación son necesariamente reimplementadas dalgunha forma en todos os ordenadores e servidores de Internet. A teoría dos dereitos de autor de Oracle pode facer que case calquera cousa que fagas co teu ordenador sexa ilegal.

Para evitar estas consecuencias de gran alcance, Oracle e o tribunal de apelación que mantivo os seus argumentos intentaron limitar a infracción dos dereitos de autor a certas reimplementacións da API que son "incompatibles" co orixinal. Pero tamén as reimplementacións parciais son habituais. Mesmo na súa copia da API S3, Oracle observa numerosas "diferenzas" e incompatibilidades coas API orixinais de Amazon.

O principal perigo da demanda de Oracle é que podería impedir que empresas tecnolóxicas máis pequenas creen versións de sistemas compatibles con plataformas dominantes como S3. Sen tal compatibilidade, os programadores quedarían efectivamente bloqueados das ofertas desta empresa.

Os representantes da industria e os desenvolvedores só poden esperar que a razón prevaleza aquí, e os xuíces coñecen os conceptos básicos da programación.

Fonte: www.habr.com