כיצד אורקל נ 'גוגל יכולה לעודד את פיתוח התוכנה

אורקל נ 'גוגל מתפתלת בערכאות זה עשור. בוודאי כבר שמעתם כי המקרה המשפטי הבולט יכול להפוך את הנדסת התוכנה כפי שאנו מכירים אותה - אך מכיוון שנראה ששום דבר לא קורה, נסלח אם נהגתם לכוון את החדשות.

ייתכן שהגיע הזמן להיכנס שוב. איטרציה האחרונה של המקרה תידון על ידי בית המשפט העליון בארה"ב בעונת 2020-2021, שהחלה השבוע (לאחר שנדחקה לאחור עקב חששות לנגיף הכלילי). החלטתו של בית המשפט העליון במדינה אינה ניתנת לביטול וסביר להניח שהיא תיפסל, כך שבניגוד להחלטות קודמות ברמה המחוזית ובבית המשפט הקדמי, היא תישאר לטובה. ובעוד התיק נדון בארה"ב, ההחלטה תשפיע על כל תעשיית הטכנולוגיה העולמית.

[גם בנושא: האם APIs צריכים להיות מוגנים בזכויות יוצרים? 7 סיבות ו 7 נגד]

במקרה שלא קראת מאמרים ששווים את עשר השנים, הנה רענון. בתביעתה, אורקל טוענת שהשימוש של גוגל בממשקי API של Java במערכת ההפעלה של Android מהווה הפרה של זכויות יוצרים מכיוון שגוגל מעולם לא קיבלה רישיון Java. ככזו, אורקל נ 'גוגל עוסקת בשאלה האם ממשקי API מוגנים בזכויות יוצרים, ואם כן, האם השימוש בהם ביישומי תוכנה מהווה "שימוש הוגן" על פי החוק.

זו שאלה מרכזית עבור מפתחי תוכנה ותעשיית התוכנה כולה. יישום מחדש של ממשקי API הוא לחם וחמאה של הנדסת תוכנה, ואם אורקל תזכה, זה ישנה באופן דרסטי את אופן העבודה של המפתחים. אבל איך בדיוק נראה השינוי הזה - ומה המשמעות של עבודתך בתעשיית התוכנה? הנה תצוגה מקדימה קצרה של ההשפעה האפשרית.

מה פירוש ממשקי ה- API של קופירייטינג

רוב השיטות המומלצות לפיתוח תוכנה מודרניות בנויות סביב יישומי API חדשים. בעולם שבו SCOTUS שולט לטובת אורקל, מפתחים יצטרכו לשנות את האופן שבו הם בונים תוכנה חדשה. אבל השינויים לא ייפסקו שם. ההשפעה של החלטה פרו-אורקל תזלזל כלפי חוץ בכל תעשיית התוכנה.

חברות נוספות ינסו לייצר רווח מממשקי ה- API שלהן

אחת ההשפעות המיידיות ביותר של החלטה לטובת אורקל תהיה לאפשר לחברות לייצר רווח מממשקי ה- API שלהם. סביר להניח שהם יעשו זאת על ידי גביית דמי רישוי עבור ממשקי API, כפי שחברות רבות כבר עושות עבור תוכנת SaaS.

במבט ראשון, רישוי עשוי להיראות כמו זרם הכנסות אטרקטיבי, במיוחד עבור חברות עם ממשקי API פופולריים מאוד (למשל, ממשקי API של S3 של אמזון). עם זאת, לא סביר שחברות רבות ישלמו עבור רישיונות API. בעוד שממשק API מסייע לתאימות, מה שחשוב באמת הוא הקוד שאתה מיישם מאחוריו בכדי לבצע דברים. זה "הרוטב הסודי" של החברה שלך והאופן בו היא מבדילה את עצמה מהמתחרים. לאור זה, תשלום עבור ממשקי API לא יוסיף יתרון תחרותי וכנראה שלא יהיה כדאי לטווח הארוך.

במקום זאת, רוב החברות כנראה יתאימו את הקוד שלהן מספיק בכדי להפוך את ה- API שלהן ל"שונה "על פי חוק זכויות היוצרים - למרות שקוד זה יעשה את אותו הדבר כמו קודם. זה עשוי לחסוך כסף לחברות התוכנה, אך זה ייצור כאבי ראש תאימות בטווח הארוך.

ייתכן גם שחברות מסוימות עם ממשקי API פופולריים יבחרו להפוך אותן לקוד פתוח. ישנם יתרונות רבים בכך שהפרוטוקול הקנייני שלך יהיה הסטנדרט בתעשייה, גם אם אינך מרוויח ממנו כסף ישירות. עם זאת, חברות המודאגות מליטיגציה או אגרות רישוי עתידיות עלולות להיזהר משימוש בכל ממשק API ללא שינוי.

התוכנה תהיה פחות תואמת צולבות

קשה יותר לגרום לתוכנות שונות לעבוד יחד כאשר כולן פועלות על קוד קנייני ייחודי במקום על תקן אוניברסלי יחיד. אותו עיקרון תקף מחוץ לתוכנה - לכן מותקן שקע חשמל רגיל בקירות של כולם, במקום שקע אחר בהתאם לחברת החשמל שלכם.

בעולם שבו ממשקי API מוגנים בזכויות יוצרים, יישומים לא היו משחקים יחד כמעט באותה מידה. המעבר מספק SaaS אחד למשנהו פירושו לשנות את הקוד שלך כך שיתאים לממשקי ה- API הייחודיים שלו - תהליך מייגע ועתיר עבודה. שינוי זה יהפוך גם את כישוריכם כמפתחים לניידים פחות. יהיה עליך ללמוד קבוצה חדשה של ממשקי API בכל פעם שאתה מחליף עבודה במקום להחיל את הידע הקיים שלך על תקני התעשייה.

התחרות עם חברות תוכנה מבוססות תקשה יותר

ממשקי API של זכויות יוצרים יהפכו את החברות שהופכות אותם לשומרי סף שמגיעים להחליט מי משתמש בממשקי ה- API היקרים ביותר שלהם. תעשיית הטכנולוגיה מאוד תחרותית, וחברות מסוימות עשויות למנוע מאחרות גישה רק כדי להקשות על חייהן. לחלופין, חברות יכולות למנוע גישה ממשק API לכל מי שאינן מסכימות איתו, מבחינה פוליטית או אחרת, ולפתוח מערך נושאים נוסף.

בנוסף, מחסור בממשקי API של קוד פתוח יקשה על העקירה של בעלי התפקידים. נכון לעכשיו, אם חברה לא מספקת שירות נהדר מאחורי ה- API שלה, התחלה יכולה לצאת בקלות לשוק עם שירות טוב יותר ולהשתמש באותו API כדי להפוך את השירות לתואם לתוכנה קיימת, ולהבטיח אימוץ פשוט. עם זכויות יוצרים על API, זה יוצא מהחלון. חברות יצטרכו לבצע שינויים גדולים בתשתית בכדי לאמץ את הפתרון החדש.

רמז לעתיד

רובנו בעולם הטכנולוגיה שורשים לניצחון בגוגל, שישמור על המצב הקיים בפיתוח תוכנה. למרבה המזל, הדברים נראים די מלאי תקווה. בחודש מאי, הזמינה SCOTUS תקצירים משלימים מאת אורקל וגוגל המפרטים את תקן הבדיקה שהוחלה על מנת לקבוע שימוש הוגן במשפט מושבעים של בית המשפט המחוזי המקורי. (בית המשפט המחוזי הכריע לטובת גוגל, אך החלטה זו בוטלה מאוחר יותר בערעור בבית המשפט המחוזי הפדרלי.)

בקשת השופטים עשויה להיות סימן לכך ש- SCOTUS שוקלת בין השאר נקודת מבט שהועלתה בין היתר על ידי מרכז החוק לחופש התוכנה (SFLC), אשר טוען כי ערכאת הערעור על ביטול פסק דין של חבר מושבעים בנושא שימוש הוגן אינה חוקתית על פי שביעית. תיקון. בעקבות קו טיעון זה יאפשר לסקוטוס להסדיר את התיק בהתבסס על סוגיה פרוצדוראלית יחסית. בית המשפט יימנע מהתעמקות במורכבות הטכנית של פיתוח תוכנה - ולא ייתן תקדים לאופן בו יש לפרש ממשקי API לאור חוק זכויות היוצרים.

עם זאת, למרות רמזים אלה לא נדע באמת את התוצאה עד שסקוטוס תפסוק את התיק בשנה הבאה. יהיה זה חכם לכל חברות התוכנה להיערך לאפשרות שאורקל תזכה וממשקי API יהיו מוגנים בזכויות יוצרים. זה לא אומר שעליך להתחיל לשכתב את ממשקי ה- API הקיימים של היישומים שלך כעת - אבל זה יהיה הגיוני להציב תוכנית שתעשה זאת במהירות וביעילות אם יהיה צורך בכך. בינתיים, כל מה שאנחנו יכולים לעשות זה לחכות.

חנו ולטונן הוא מייסד ומנהל מוצר ראשי בחברת Aiven, ספקית פלטפורמת נתונים בענן המפעילה פתרונות קוד פתוח מנוהל, הזרמת אירועים, זיכרון מטמון, חיפוש וגרפים עבור לקוחות ברחבי העולם. 

-

פורום טק חדש מספק מקום לחקור ולדון בטכנולוגיה ארגונית מתפתחת בעומק ורוחב חסרי תקדים. הבחירה היא סובייקטיבית, על סמך בחירת הטכנולוגיות שלדעתנו הן חשובות ומעניינות ביותר את הקוראים. אינו מקבל ביטחונות שיווקיים לפרסום ושומר לעצמו את הזכות לערוך את כל התוכן שתרם. שלח את כל הבירורים לכתובת [email protected]