Oracle сама скопировала API у Amazon S3, и это совершенно нормально


    Юристы Oracle сравнивают реимплементацию Java API в Android с копированием содержания «Гарри Поттера», pdf

    В начале этого года Верховный суд США рассмотрит важное дело Oracle против Google, которое определит правовой статус API в соответствии с законом об интеллектуальной собственности. Если суд встанет на сторону Oracle в её многомиллиардном иске, это может задушить конкуренцию и закрепить доминирование технологических гигантов, возможно, включая саму Google.

    В то же время бизнес Oracle изначально построен на имплементации языка программирования SQL, разработанного IBM, да и сейчас компания предлагает облачный сервис с API из Amazon S3, и это совершенно нормально. Реимплементация API была естественной частью развития информатики с самого зарождения отрасли.

    Oracle обвиняет Google в незаконном копировании Java API, в том числе списка именованных команд, привязанных к грамматическим структурам. Операционная система Android специально совместима с Java API, чтобы Java-программистам было проще перенести программное обеспечение и знания на новую платформу. Для этого Android точно скопировала соответствующие команды Java API и грамматические структуры. Аргумент Oracle заключается в том, что такую «реимплементацию» Java API можно сравнить с копированием авторского произведения, такого как литературный роман «Гарри Поттер» (это реальный пример, который привели юристы Oracle), а Google нарушает копирайт Oracle на имена команд и структуры Java API.

    Но Java API — не единственные API, а Android — не единственная реимплементация. В современной IT-индустрии API встречаются повсеместно, а повторное внедрение фундаментально важно для сохранения конкуренции, чтобы предотвратить монополию крупных фирм, считает Чарльз Дюан, директор по технической и инновационной политике в R Street Institute.

    Дюан приводит пример популярной платформы хранения данных Amazon S3. Чтобы позволить запись и извлечение файлов с S3, Amazon разработала всесторонний, подробный API для взаимодействия с сервисом. Например, для получения списка сохранённых файлов (ListObjects) мы отправляем команду GET с указанием хоста и параметров типа encoding-type, continuation-token и x-amz-date. Для работы с Amazon S3 программное обеспечение должно в точности использовать эти и многие другие специфические названия параметров.

    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 является явным лидером на рынке облачных сервисов, а её конкуренты предлагают реимплементацию API S3, при этом им приходится имитировать названия команд, теги параметров, префиксы типа x-amz, грамматическую структуру и общую организацию API S3. Другими словами, всё то, что, по утверждению Oracle, защищено авторским правом.

    Среди компаний, предлагающих копию API Amazon S3, есть и сама Oracle. Для совместимости Amazon S3 Compatibility API копирует многочисленные элементы API Amazon, вплоть до тегов x-amz.



    Oracle уверяет, что законность её действий основана на опенсорсной лицензии Apache 2.0, которая позволяет свободное копирование и изменение кода. Например, Amazon SDK для Java тоже поставляется с лицензией Apache 2.0.

    Но вопрос в том, применимо ли вообще законодательство об интеллектуальной собственности к таким объектам, как API. Именно это должен установить Верховный суд.

    Кто изобрёл API?


    Термин и понятие «библиотеки подпрограмм» (subroutine library) впервые появилось в книге Хермана Голдстайна и Джона фон Неймана «Планирование и кодирование проблем для электронного вычислительного инструмента» — часть II, том III (Институт продвинутых исследований Принстонского университета, 1948), копия на archive.org. Содержание третьего тома:



    Это первое описание методологии программирования для компьютеров с сохранением программ в памяти (ранее таковой не существовало). Она широко разошлась по университетам, которые в то время пытались создать собственные вычислительные машины. И главное, книга содержит ключевую идею: большинство программ будет использовать общие операции, а библиотеки с подпрограммами уменьшат количество нового кода и ошибок. Эту идею доработал Морис Уилкс и применил на практике в машине EDSAC, за что получил премию Тьюринга 1967 года.


    Библиотека подпрограмм EDSAC стоит слева

    Следующим шагом было создание функций более высокого порядка и полноценных программных интерфейсов, что сделали Морис Уилкс и Дэвид Уилер в книге «Подготовка программ для электронного цифрового компьютера» (1951).

    Сам термин Application Program Interface (API) появился где-то в конце 60-х.

    Автор презентации «Краткая Субъективная история API» Джошуа Блок приводит несколько примеров программных интерфейсов, наборов инструкций и библиотек подпрограмм: как они создавались и использовались впоследствии. Идея в том, что повторное использование — и есть смысл API. Именно для этого они создавались в первую очередь. И у разработчиков всегда была возможность копировать и переделывать чужие API:

    API Создатель Год Повторная реализация Год
    Библиотека FORTRAN IBM 1958 Univac 1961
    IBM S/360 ISA IBM 1964 Amdahl Corp. 1970
    Стандартная библиотека С AT&T / Bell Labs 1976 Mark Williams Co. 1980
    Системные вызовы Unix AT&T / Bell Labs 1976 Mark Williams Co. 1980
    VT100 Esc Seqs DEC 1978 Heathkit 1980
    IBM PC BIOS IBM 1981 Phoenix Technologies 1984
    MS-DOS CLI Microsoft 1981 FreeDOS Project 1998
    Набор команд Hayes AT Hayes Micro 1982 Anchor Automation 1985
    PostScript Adobe 1985 GNU/GhostScript 1988
    SMB Microsoft 1992 Samba Project 1993
    Win32 Microsoft 1993 Wine Project 1996
    Библиотеки классов Java 2 Sun 1998 Google/Android 2008
    Веб-API Delicious Delicious 2003 Pinboard 2009
    Источник: «Краткая Субъективная история API»

    Копировать и повторно использовать API (библиотеки, наборы инструкций) — это не только правильно, но такая методология программирования прямо рекомендуется в канонах информатики. Ещё до копирования программных интерфейсов S3 сама компания Oracle неоднократно делала это. Более того, бизнес Oracle изначально построен на имплементации языка программирования SQL, разработанного IBM. Первым флагманским продуктом Oracle стала СУБД, во многом скопированная с IBM System R. В данном случае речь идёт о реимплементации SQL как «стандартного API» для СУБД.

    Наложение интеллектуальных прав на интерфейсы API может создать юридическое минное поле, от которого пострадают все. Интерфейсы API реализуют и другие облачные сервисы. Многие технические стандарты, такие как Wi-Fi и протоколы интернета — включают API. Программные интерфейсы обязательно повторно реализованы в каком-то виде на каждом компьютере и сервере в интернете. Теория копирайта Oracle может превратить почти всё, что вы делаете с компьютером, в незаконное деяние.

    Чтобы избежать этих далеко идущих последствий, Oracle и апелляционный суд, поддержавший её аргументы, попытались ограничить нарушение копирайта лишь некоторыми реимплементациями API, которые «несовместимы» с оригиналом. Но частичные реимплементации тоже являются обычным делом. Даже в своей копии API S3 компания Oracle отмечает многочисленные «отличия» и несовместимости с оригинальными API Amazon.

    Главная опасность иска Oracle заключается в том, что он может помешать небольшим технологическим компаниям создавать версии систем, совместимые с доминирующими платформами, такими как S3. Без такой совместимости программисты будут фактически заблокированы в предложениях этой фирмы.

    Представителям индустрии и разработчикам остаётся надеяться, что разум здесь восторжествует, а судьи знают основы программирования.
    Дата-центр «Миран»
    Решения для аренды и размещения ИТ-инфраструктуры

    Комментарии 6

      +2
      Кажется, перевод задержался на 3 с лишним года.
      С учётом этого можно было сделать ремарку по поводу временной привязки в начале текста
        +9
        Обещают решить до июня 2020 года. Это будет финальная точка в разбирательстве, которое продолжается десять лет.
        In 2018, an appeals court ruled in favor of Oracle and overturned previous rulings that favored Google. Dissatisfied with the lower court’s decision, Google petitioned the Supreme Court to hear its case. Previously, the Supreme Court had refused to hear Google’s petition but finally granted it on November 15th, 2019.
        0

        Интересно, можно ли запатентовать протокол (а не его реализацию), например, HTTP(S)? И обязать выплачивать роялти всех, кто его использует в своих продуктах...

          +1
          Язык запатентовать. Английский.
            +1
            Запатентовать можно только то, что отличается принципиальной новизной. HTTP уже не получится. Можно разработать свой протокол и его запатентовать. Вопрос в том, а кто будет его тогда использовать?
              0
              Можно. И делают.
              в стандартах сотовой связи патентов — куча. Другое дело что при их создании владельцы патентов дают обязательство лицензировать их как минимум всем желающим (FRAND-лицензии ) и все равно получается иногда интересно (Qualcomm например своими патентами на 3G/LTE вполне себе пользовалась для не особо красивой конкуренции)
              в видеокодеках — сразу патентные пулы создаются и прописываются единые условия лицензирования.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое