החלטת בית המשפט בשבוע שעבר בתביעת הענק של חברת אורקל נגד גוגל (Oracle America, Inc. v. Google, Inc., 3:10-cv-03561-WHA (N.D. Cal. May 31, 2012), כדאי לקרוא את הסיכום בבלוג של אריק גולדמן) היא יותר מכל נצחון לעולם הקוד הפתוח ומבהירה הרבה סוגיות שלא בטוח שהשופט התכוון עליהן. בקצרה, וכדי להבין את הסיפור: חברת אורקל היא המפתחת והבעלים של שפת התכנות Java; גוגל פיתחה ממשק פיתוח (API) אשר איפשר שימוש במכשירים סלולריים בצורה זהה לשימוש במכשירים נייחים, אשר יישם פונקציונאליות זהה לזו של אורקל ושמות זהים לפקודות בממשק הפיתוח. כלומר, הפעילות של גוגל איפשרה לאנשים להריץ תוכנות אשר נכתבו למכשירים נייחים על המכשירים הניידים של גוגל (במערכת ההפעלה Android).

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

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

Contrary to Oracle, copyright law does not confer ownership over any and all ways to implement a function or specification, no matter how creative the copyrighted implementation or specification may be. The Act confers ownership only over the specific way in which the author wrote out his  version. Others are free to write their own implementation to accomplish the identical function, for, importantly, ideas, concepts and functions cannot be monopolized by copyright.

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

כעת, הבעיה שהיתה (עד הפסיקה בעניין אורקל) היא כזו: אני פיתחתי תוכנה מסוימת, ושיחררתי אותה ברשיון קוד-פתוח. לתוכנה יש ממשק פיתוח שאיפשר פעילות מסוימת. בא חבר ופיתח תוכנה המתממשקת לממשק הפיתוח הזה ורצה לשחרר את התוכנה שלו; עד עתה, הוא היה צריך לבדוק האם התוכנה היא independent and separate כדי לדעת האם הרשיון חל גם עליו, והוא גם חייב לשחרר את התוכנה שלו ברשיון GPL. אותה בחינה גרמה לכך שתוכנות רבות לא הסכימו להתממשק עם רכיבי קוד פתוח, ובעקבות זאת לא באו לעולם. היום, יכול להיות שהמצב השתנה.

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

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

"the structure, sequence and organization of a computer program may (or 12 may not) qualify as a protectable element depending on the “particular facts of each case” and  always subject to exclusion of unprotectable elements"

כלומר, גם על מבנה התוכנה, שיכול לקבל הגנה בזכויות יוצרים אם הוא מקורי ויצירתי (לדוגמא א 64269/07 שטיינברג נ' סמבירא, ורעא 39695-05-10 נהון נ' נוריאל בישראל), עומדים הכללים בבסיס חוק זכויות יוצרים. אם תוכנת מחשב תקבל הגנה כמו יצירה ספרותית רק אם היא מקורית ויצירתית, הרי שממשק התוכנה (API) הוא פונקציונאלי, ואינו מכיל מקוריות ולכן יהיה ניתן להשתמש בו, ורשיון זכויות היוצרים לא יחול על תוכנות שמתממשקות אליו.

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

המשמעות של גישה זו בפועל, היא שממשק תכנות או פיתוח יוצר שכבה של הפרדה בין התוכנה המקורית לבין התוכנה שנמצאת סביבה. גישה זו מלווה מספר החלטות שאפשרו הנדסה חוזרת לצורך יצירת ממשקים בפסיקה האמריקאית (נניח, Sega Enterprises Ltd. v. Accolade Inc. U.S. Court of Appeals (October 1992); כלומר, יכול להיות שהרשיון עצמו אולי לא מרשה לעשות משהו, אבל החוק חזק מהרשיון, ויש מקרים בהם החוק בכלל לא נותן הגנה בזכויות יוצרים. בכך, יכול להיות, תפתר אחת הבעיות הגדולות שהיו בתחום הקוד הפתוח.