وکلای اوراکل اجرای مجدد Java API در اندروید را با کپی کردن محتوای "هری پاتر" مقایسه می کنند. پی دی اف

دادگاه عالی ایالات متحده در اوایل سال جاری به یک پرونده مهم رسیدگی خواهد کرد. اوراکل در مقابل گوگل، که وضعیت حقوقی API را تحت قانون مالکیت معنوی تعیین می کند. اگر دادگاه در دعوی چند میلیارد دلاری از اوراکل حمایت کند، می‌تواند رقابت را خفه کند و سلطه غول‌های فناوری از جمله خود گوگل را تثبیت کند.

در همان زمان، کسب و کار اوراکل در ابتدا بر اساس پیاده سازی زبان برنامه نویسی SQL توسعه یافته توسط IBM ساخته شد و حتی در حال حاضر این شرکت یک سرویس ابری با یک API از Amazon S3 ارائه می دهد و این کاملاً طبیعی است. پیاده سازی مجدد API بخشی طبیعی از توسعه علوم کامپیوتر از همان ابتدای صنعت بوده است.

اوراکل گوگل را به کپی غیرقانونی API جاوا، از جمله فهرستی از دستورات نام‌گذاری شده مرتبط با ساختارهای گرامری، متهم می‌کند. سیستم عامل اندروید به طور خاص با Java API سازگار است تا برنامه نویسان جاوا بتوانند نرم افزار و دانش را به پلتفرم جدید انتقال دهند. برای انجام این کار، اندروید دقیقا دستورات جاوا API و ساختارهای گرامری مربوطه را کپی کرد. بحث و جدل Oracle این است که چنین "اجرای مجدد" API جاوا را می توان با کپی کردن آثار یک نویسنده مقایسه کرد، مانند رمان ادبی "هری پاتر" (این یک مثال واقعی که توسط وکلای اوراکل ارائه شده است)، آ گوگل حق نسخه برداری Oracle را بر روی نام ها و ساختارهای دستورات Java API نقض می کند.

اما API های جاوا تنها API ها نیستند و اندروید تنها پیاده سازی مجدد آنها نیست. در صنعت IT امروزی، APIها همه جا حاضر هستند و معرفی مجدد برای حفظ رقابت برای جلوگیری از انحصار شرکت های بزرگ ضروری است. خوانده چارلز دوان مدیر سیاست فناوری و نوآوری در موسسه R Street است.

Duane پلتفرم ذخیره سازی محبوب Amazon S3 را مثال می زند. برای فعال کردن نوشتن و بازیابی فایل‌ها از S3، آمازون توسعه داده است، API دقیق برای تعامل با سرویس به عنوان مثال، برای دریافت لیستی از فایل های ذخیره شده (List Objects) یک دستور GET ارسال می کنیم که پارامترهای میزبان و نوع را مشخص می کند نوع رمزگذاری, ادامه نشانه и x-amz-date. برای کار با آمازون 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

آمازون پیشرو آشکار در بازار خدمات ابری است و رقبای آن اجرای مجدد S3 API را ارائه می‌کنند، در حالی که باید از نام‌های فرمان، برچسب‌های پارامتر، پیشوندهای نوع تقلید کنند. x-amz، ساختار دستوری و سازماندهی کلی S3 API. به عبارت دیگر، هر چیزی که اوراکل ادعا می کند دارای حق چاپ است.

از جمله شرکت هایی که نسخه ای از API آمازون S3 را ارائه می دهند، هستند خود اوراکل نیز وجود دارد. برای سازگاری، آمازون S3 Compatibility API عناصر متعددی از API آمازون را تا تگ‌های x-amz کپی می‌کند.

اوراکل ادعا می کند که قانونی بودن اقداماتش بر اساس مجوز منبع باز Apache 2.0 است که امکان کپی و اصلاح رایگان کد را فراهم می کند. مثلا، Amazon SDK برای جاوا همچنین دارای مجوز آپاچی 2.0 است.

اما سوال اینجاست که آیا قانون مالکیت معنوی حتی در مورد مواردی مانند API ها نیز صدق می کند؟ این چیزی است که دیوان عالی کشور باید تعیین کند.

چه کسی API را اختراع کرد؟

اصطلاح و مفهوم "کتابخانه زیر روال" برای اولین بار در کتاب مسائل برنامه ریزی و کدگذاری برای یک ابزار محاسباتی الکترونیکی - قسمت دوم، جلد سوم (موسسه مطالعات پیشرفته دانشگاه پرینستون، 1948) توسط هرمان گلدشتاین و جان فون نویمان ظاهر شد. در archive.org کپی کنید. مطالب جلد سوم:

این اولین توصیف از روش برنامه نویسی برای رایانه هایی است که برنامه ها را در حافظه ذخیره می کند (قبلاً این روش وجود نداشت). این به طور گسترده در دانشگاه ها توزیع شد، که در آن زمان سعی در ایجاد رایانه های خود داشتند. و مهمتر از همه، این کتاب حاوی یک ایده کلیدی است: اکثر برنامه‌ها از عملیات مشترک استفاده می‌کنند و کتابخانه‌های دارای روال، مقدار کد و خطاهای جدید را کاهش می‌دهند.. این ایده توسط موریس ویلکس بیشتر اصلاح شد و در ماشین EDSAC عملی شد و جایزه تورینگ را در سال 1967 دریافت کرد.

کتابخانه زیر روال EDSAC در سمت چپ قرار دارد

گام بعدی ایجاد توابع درجه بالاتر و رابط های نرم افزاری کامل بود، همانطور که موریس ویلکس و دیوید ویلر در تهیه برنامه ها برای کامپیوتر دیجیتال الکترونیکی (1951) انجام دادند.

خود اصطلاح رابط برنامه کاربردی (API) جایی در اواخر دهه 60 ظاهر شد.

نویسنده ارائه "تاریخچه ذهنی مختصر API" Joshua Block چندین مثال از رابط های برنامه نویسی، مجموعه دستورالعمل ها و کتابخانه های زیر روال ارائه می دهد: نحوه ایجاد و متعاقبا استفاده از آنها. ایده این است که استفاده مجدد نقطه یک API است. این همان چیزی است که آنها در وهله اول برای آن خلق شده اند. و توسعه دهندگان همیشه این فرصت را داشته اند که API های دیگران را کپی و بازسازی کنند:

API
خالق
سال
پیاده سازی مجدد
سال

کتابخانه FORTRAN
آی بی ام
1958
یونیواک
1961

IBM S/360 ISA
آی بی ام
1964
Amdahl Corp.
1970

کتابخانه استاندارد C
آزمایشگاه AT&T/Bell
1976
شرکت مارک ویلیامز
1980

تماس های سیستم یونیکس
آزمایشگاه AT&T/Bell
1976
شرکت مارک ویلیامز
1980

VT100 Esc Seqs
دسامبر
1978
Heathkit
1980

بایوس کامپیوتر IBM
آی بی ام
1981
فن آوری های فونیکس
1984

MS-DOS CLI
مایکروسافت
1981
پروژه FreeDOS
1998

مجموعه دستورات Hayes AT
هیز میکرو
1982
اتوماسیون لنگر
1985

پست اسکریپت
خشت
1985
گنو/گوست اسکریپت
1988

SMB
مایکروسافت
1992
پروژه سامبا
1993

Win32
مایکروسافت
1993
پروژه شراب
1996

کتابخانه های کلاس جاوا 2
خورشید
1998
گوگل/اندروید
2008

Web API Delicious
خوشمزه - لذیذ
2003
پینورد
2009

منبع: "تاریخچه ذهنی مختصر API"

کپی کردن و استفاده مجدد از API ها (کتابخانه ها، مجموعه های دستورالعمل) نه تنها صحیح است، بلکه این روش برنامه نویسی مستقیماً در قوانین علوم کامپیوتر توصیه می شود. حتی قبل از کپی کردن رابط های برنامه نویسی S3، خود اوراکل بارها این کار را انجام داد. علاوه بر این، کسب و کار اوراکل در ابتدا بر اساس پیاده سازی زبان برنامه نویسی SQL توسعه یافته توسط IBM ساخته شد. اولین محصول پرچمدار Oracle یک DBMS بود که عمدتاً از IBM System R کپی شده بود. در این مورد، ما در مورد پیاده سازی مجدد SQL به عنوان یک "API استاندارد" برای یک DBMS صحبت می کنیم.

تحمیل حقوق مالکیت معنوی بر API ها می تواند یک میدان مین قانونی ایجاد کند که همه را تحت تاثیر قرار دهد. API ها پیاده سازی و سایر خدمات ابری. بسیاری از استانداردهای فنی، مانند پروتکل‌های Wi-Fi و اینترنت، شامل API هستند. واسط های برنامه نویسی لزوماً به شکلی در هر رایانه و سرور در اینترنت دوباره پیاده سازی می شوند. نظریه کپی رایت اوراکل می تواند تقریباً هر کاری را که با رایانه خود انجام می دهید غیرقانونی کند.

برای جلوگیری از این پیامدهای گسترده، اوراکل و دادگاه استیناف که استدلال های آن را تایید کرد، تلاش کرده اند نقض حق نسخه برداری را به برخی از API های مجدد که با نسخه اصلی "ناسازگار" هستند محدود کنند. اما اجرای مجدد جزئی نیز رایج هستند. اوراکل حتی در نسخه‌ای از S3 API به «تفاوت‌ها» و ناسازگاری‌های متعددی با APIهای اصلی آمازون اشاره می‌کند.

خطر اصلی شکایت اوراکل این است که می تواند شرکت های فناوری کوچکتر را از ایجاد نسخه هایی از سیستم های سازگار با پلتفرم های غالب مانند S3 جلوگیری کند. بدون چنین سازگاری، برنامه نویسان به طور موثر از پیشنهادات این شرکت قفل خواهند شد.

نمایندگان و توسعه دهندگان صنعت فقط می توانند امیدوار باشند که عقل در اینجا غالب شود و داوران اصول برنامه نویسی را می دانند.

منبع: www.habr.com