התביעה של אורקל נגד גוגל

(למי שמחפש את ההיסטוריה על התביעה, ערעור וכו' – אני ממליץ לקרוא את הדברים כאן)

יש לא מעט אנשים וחברות שאפשר בכיף לקרוא להם "נבלות". קחו לדוגמא את המקרה הקלאסי של נבל בשם מרטין שקרלי שקנה את תרופת Daraprim מחברת Impax Laboratories והוא הפך מכירה של תרופה שעלתה 13.5$ ל-750$ פר כדור. עליה של 5,556% ביום אחד! התגובות במדיה החברתית היו צפויות ומהירות, וכל איחול רע שקיים בלקסיקון, איחלו לו. כמו תמיד, אנשים כמו מרטין עם אגו עד השמיים עושים לפעמים שטויות רציניות שגורמים לרשויות כמו ה-SEC לבדוק אותם ובמקרה שלו לעצור אותו (הוא שוחרר בערבות) ולהיזרק מתפקיד המנכ"ל.

אבל יש לא רק אנשים כאלו, יש גם חברות. אם פעם אנשים חשבו שמיקרוסופט היא התגלמות הרשע, באה אורקל אמריקה ולקחה את הכותרת של חברה נבלה. לא, זה לא רק דעה שלי, זו ההתנהגות של החברה גם כלפי לקוחותיה. נניח ואתם משתמשים ב-ESXI בחברה והחלטתם להשתמש ב-DB או במוצרים אחרים שאורקל מוכרת וגובה לפי מעבד/ליבה. נניח והגדרתם את המכונה הוירטואלית להיות עם 2 ליבות בלבד (לא חשוב מה השאר). מבחינתכם, ההגיון שלכם אומר שאתם צריכים לשלם על רשיון ל-2 ליבות נכון? זהו, אורקל לא מקבלת את הטיעון הזה ומבחינתם אתם צריכים לשלם על כל הליבות והמעבדים שנמצאים בשרת, כלומר אם אתם מריצים את זה על מכונה עם 4 מעבדים שיש לכל אחד מהם 8 ליבות, אז התכבדו ושלמו נא על רשיון ל-32 ליבות. למה? ככה! האם יש פתרון לכך? בוודאי – אם תשתמשו בפתרון הוירטואליזציה (המזוויע) של אורקל – ה-Oracle VM.

הסיפור עם גוגל די פשוט: כשאנדרואיד החל להיבנות והיה בפיתוח (עוד לפני שגוגל רכשה אותם), המהנדסים החליטו ללכת על שפת JAVA במקום להשתמש בשפות אחרות. בפיתוח עצמו אנדרואיד לא השתמשו ב-JRE או JDK כדי להריץ אפליקציות JAVA אלא הם פיתחו את Dalvik, ו-Dalvik זו האפליקציה (כמה שאפשר לקרוא לה כך) כדי להריץ אפליקציות אנדרואיד שמפותחות בשפת JAVA.

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

המציאות, מה לעשות, קצת שונה ממה שאורקל מתארים. כמה שונה? מאוד שונה.

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

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

החל מגירסת Cupcake של אנדרואיד שיצאה ב-2009 ועד גירסת Jelly Beans שיצאה ב-2012 – אורקל לא אמרה מילה. הקוד של אנדרואיד לא היה חבוי ותמיד היה זמין לכל אחד שיש ברשותו חיבור אינטרנט ודפדפן ואורקל עצמה הוציאה לא מעט אפליקציות לאנדרואיד – ועדיין, שום מילה על "הפרה" כלשהי, עד לחודש מאי 2012, חודשיים לפני יציאת Jelly Beans, אז באורקל נזכרו באנדרואיד ומכאן החלה התביעה שנדחתה, הערעור שהחזיר חלק מהתביעה לחיים והקמת "גועליציה" של חברות שהחליטו ששימוש ב-API מצריך תשלום, לזה נגיע מאוחר יותר.

מה קרה שאורקל שראתה במשך 3 שנים את אנדרואיד יוצא לא פצתה פה ולפתע היא החליטה לתבוע? הסיפור די פשוט: אורקל היא חברה גדולה שלא ממש "שמה" על הלקוחות שלה או על התפתחויות טכנולוגיות וזה דבר ידוע מימים ימימה. שאורקל הודיעו שהם הולכים לרכוש את SUN, לקוחות של SUN החלו לנטוש את החברה בהמוניהם (קראו בלינק לעיל בעדותו של שוורץ) לשמחת המתחרים ובראשם HP ו-IBM. אורקל קנו את SUN במצב ש-SUN פתחה כמעט כל פרויקט/מוצר שלה כקוד פתוח, מ-ZFS ו-Solaris ועד MySQL, SSO, Grid Engine ועוד מוצרים רבים כי ב-SUN האמינו שאם המוצרים יהיו בקוד פתוח, חברות ירכשו שרותי תמיכה (מה שלא ממש קרה..). אחרי שאורקל רכשה את SUN הם החלו לסגור את הקוד של המוצרים וקצב הפיתוח שלהם צנח מטה. נסו לדוגמא להשוות את פיתוח ZFS לפני רכישת SUN ואחרי, ותראו שהפיתוח בקושי התקדם (ולא, BTRFS לא היה של SUN ומעולם הוא לא תוכנן להחליף את ZFS – ה-BTRFS הוא פיתוח של אורקל שכצפוי – ננטש באמצע והפיתוח שלו הומשך ע"י אחרים וכיום הוא מובל ע"י Facebook). כנ"ל לגבי Solaris או Jenkins (שבמקור היה Hudson אבל כרגיל אורקל הצליחו להסתכסך עם הקהילה והקהילה החליטה לעשות Fork ולקרוא ל-Fork בשם Jenkins ומשם הפיתוח היה עצמאי) וכנ"ל לגבי MySQL. בקיצור – אורקל די התנערה מכל מה ש-Sun עשתה וגם פיתוח הברזלים (שהיה גולת הכותרת של SUN ולא סתם. SUN עשו שרתים מעולים עם עיצוב מזוויע) התעכב זמן רב. ענן? בזמן שבאמזון חוגגים עשור של ענן ציבורי, אורקל החליטה להיכנס לנושא רק בשנתיים האחרונות ורק עכשיו הם מנסים לתפוס לקוחות ל"ענן" שלהם.

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

הנושא העיקרי של התביעה הוא שימוש ב-API (מי שלא מכיר מה זה API מוזמן להציץ כאן). אורקל רוצה פסק דין שיחייב לא רק את גוגל אלא כל אחד שמשתמש ב-API של JAVA להתחיל לשלם. (שימו לב – אני מדבר על API ולא על ה-Development Kit או ה- Runtime Environment) וכאן בעצם מתחילה הבעיה המרכזית במיוחד כיום.

כיום, כשאתם שוכרים VM מאמזון לדוגמא, אתם משתמש בשרות של AMAZON שמשתמש ב-API של XEN כדי ליצור VM עבורכם ואמזון בנתה ממשק לאותו VM ומפתח יכול להשתמש ב-API של אמזון כדי לנהל את אותו VM ומאות שרותים אחרים של אמזון. אמזון לא גובה סנט שחוק על השימוש ב-API (זולת השימוש בשרותים עצמם, רוחב פס וכו'). אנחנו נמצאים היום גם בעיצומו של גל ענק שמעודד להשתמש במוצרים שהם קוד פתוח ואותם מוצרים ואפליקציות מציעים API למפתחים, ומפתחים רבים משתמשים ב-API כדי ליצור כלים חדשים כדי להשתמש במוצרים ובשרותים וברוב המקרים הכלים האלו מאפשרים חסכון עצום של עבודה. אותן חברות שמציעים את הכלים בקוד פתוח עושות את הכסף מבניית Appliances שקלים לשימוש עבור חברות וארגונים ושרותי תמיכה ואינטגרציה לתשתיות קיימות של חברות. כולם משתמשים ב-API של כלי זה או אחר ובמקרים רבים של מספר כלים במקביל וזה לא רק בעולם הקוד הפתוח בלינוקס, זה קורה גם בעולם של אפל ומיקרוסופט.

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

לעניות דעתי, לאורקל אין Case בתביעה הזו. כשאנדרואיד (החברה) פיתחה, שגוגל קנתה את אנדרואיד – ל-Sun לא היתה בעיה ולא היתה דרישת תשלום וגם מאורקל לאחר רכישת Sun לא היתה דרישה כזו. גוגל מימשו API בצורה עצמאית (למעט חלק מאוד קטן שגם הוא נלקח מ-Apache Harmony) מבלי להזדקק ל-SUN או אורקל וה"התעוררות" של אורקל מחזקת מאוד את החשד שאורקל פשוט מחפשת לעשות כאן "בוחטה" מסיבות שאינן הוגנות. האם הם יצליחו? זו שאלה טובה שקשה לענות עליה. הכל נתון להחלטת 12 מושבעים שמבינים בקוד וב-API כמו שהחתולים שלי מבינים.

ולסיום, משפט לאורקל: די חבר'ה, נגמרו הימים בהם הייתם פופולריים כי נשאתם את הדגל של "אנטי מיקרוסופט". כיום מיקרוסופט בעצמה השתנתה והיא פותחת יותר ויותר פרויקטים לקוד פתוח מבלי לבקש כספים על שימוש בפרויקטים (אם כי מיקרוסופט בהחלט מבקשים כספים על שימוש מסחרי כשזה מגיע לפטנטים שלהם כמו RDP וכו'). מיקרוסופט גם למדה לחיות עם לינוקס ואפילו בקרוב להוציא את ה-SQL שלהם ללינוקס, לתמוך בכלים מבוססי קוד פתוח ואפילו לתת תמיכה להפצות לינוקס (ב-Azure). אתם לעומת זאת קופאים על השמרים והחלטתם להתחרות ברד-האט בכך שתעתיקו את ההפצה ותתנו שרותי תמיכה במחיר יותר נמוך מרד-האט. כמות הפרויקטים בקוד פתוח שיש לכם מביכה וכבר שנים שאין פרויקטים חדשים. אנחנו חיים בעולם של ענן שבו הכסף נעשה ב-PaaS ו-SaaS, עולם שבו חברות לא רק משתמשות בקוד פתוח, אלא גם מוציאות את הקוד שלהן. לא הגיע הזמן שתתקדמו להווה?

מה קורה עם ZFS? עדכון מצב

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

נתחיל בחלק הפחות טכני ויותר "פוליטי". זה לא סוד שעקב חשש מעורפל מרשיון שאינו תואם GPL, אנשים וחברות רבות היססו להתקרב ל-ZFS על לינוקס, אולם היו מספיק אנשים שהבינו שגם אם אין תואמות מבחינת רישוי, אין שום מניעה להתקין SPL/ZFS על לינוקס ולהנות מ-ZFS.

הויכוח שנוצר קשור דווקא לחלק שאנשים שוכחים מה שקשור בליבת (Kernel) של לינוקס: במהלך "אורך חיים" של הפצת לינוקס אתה תקבל לפחות 5-10 עדכוני kernel שאמנם הם תואמים בינארית 100% אולם אתה חייב לקמפל מודולים חיצוניים מול ה-Kernel החדש. במערכות לינוקס מודרניות משתמשים בדבר כמו DKMS שעושה את העבודה אוטומטית ברגע ש-kernel חדש מותקן במערכת ואתה עושה reboot למכונה (יש גם אפשרות לגרום ל-DKMS לקמפל עבור kernel חדש גם מבלי לעשות reboot אולם לא ניכנס לכך בפוסט זה). בשביל ש-DKMS יוכל לגרום למודולים של ZFS לעבוד, הוא חייב את הקוד מקור כדי לקמפל את המודולים שנותנים את התאימות ל-SUN (מה שנקרא SPL) ולאחר מכן לקמפל את ה-ZFS. מה הרשיון CDDL V1 שתחתיו נמצאים SPL ו-ZFS מבקש? (לחצו להגדלה)

כלומר אנחנו ממלאים אחר הרשיון בכך שאנחנו משתמשים ב-DKMS שמצריך את החבילות קוד מקור, וזה גם מה שחברת קנוניקל עושים. הם לא מכניסים את zfs.ko (המודול) לתוך חבילת ה-kernel בכלל וזה גם לא מותקן במכונה כברירת מחדל, ואתה לא יכול להקים מכונת אובונטו 16.04 שתהיה כולה ב-ZFS כי ההתקנה לא מאפשרת ליצור מחיצות ZFS. החבילות נמצאות בנפרד ואותם אתה יכול להתקין. הצעד הזה גם עודד את Debian לעשות אותו דבר ברמת חבילות קוד מקור ב-Beta של ההפצה.

הכנסת ה-ZFS לאובונטו 16 ודביאן (גם ב-BETA) החלה לגרום לתהליך שיש יותר ויותר אנשים שמנסים את ZFS. מי שרוצה לנסות את ZFS אהלן וסהלן אבל מי שרוצה להשתמש בזה בפרודקשן, אני ממליץ לעבוד עם ה-REPO הרשמי (לדוגמא: ב-Wheezy יש את גירסה 0.6.5.6 בזמן שהגירסה הרשמית היא 0.6.5.7) של ZFS On Linux ואפשר כבר לראות issues שנפתחו ע"י משתמשי דביאן ואובונטו כאן. כמו כן, אם אתם משתמשים ב-RHEL או CentOS, השתמשו בגרסאות האחרונות של ההפצה (6.7 או 7.2) ולא גירסאות ישנות יותר (אלא אם אתם רוצים להיתקל בבאג כמו זה)

מבחינת יציבות (שאלה שאני שומע שוב ושוב): כן, ZFS יציב מאוד כשזה מגיע לשרתים. כשזה מגיע לדסקטופים/לאפטופים, יש באגים (כמו זה) אבל אם אתם מחפשים File System לדסקטופ, פתרונות כמו EXT4 יתאימו הרבה יותר (במיוחד עם LVM) ולמען האמת לא נראה לי כי אלו שעובדים על קוד ה-ZFS מתעניינים במשתמשי דסקטופ. האם ZFS יותר יציב מ-btrfs? התשובה פשוטה: כן.

מבחינת פיתוח: ZFS על לינוקס מתפתח במקביל ל"אחיו" בגרסאות IllumosOS, FreeBSD וכו'. כיום אם אתה משתמש בכלי אוטומציה (Ansible, Puppet, Chef) אתה יכול להקים לך שרת שכולו יהיה על ZFS (לא מומלץ לשים את ה-boot/ על ZFS) ולאחרונה גם נכנס קוד להצפנה של ZFS (עדיין לא יציב!). כלל אצבע הוא: רוצה יציבות? תשתמשו ב-0.6 האחרון. רוצים להשתולל ולא אכפת לכם שהמערכת תיפול? תשתמשו ב-0.7 (רק שימו לב לבעיות).

ולבסוף, כמה טיפים אם אתם הולכים להשתמש ב-ZFS:

  • זכרון – כמה שיותר, יותר טוב. יש "כלל אצבע" של 1 ג'יגהבייט על כל 1 טרהבייט מקום בדיסק (לפני RAIDZ), מומלץ יותר אם אתם הולכים להשתמש בדחיסה, Dedup ועוד. בד"כ אני ממליץ על מערכת כבדה מינימום 32 ג'יגה זכרון ומעלה.
  • ZFS אינו יודע לעשות קסמים. הכנסתם דיסקים SSD שישמשו כ-Cache "לפני" דיסקים SATA? אל תצפו לביצועים גבוהים. ה-Cache ב-SSD (למעט ZIL) מיועד לשימוש כ-Read Cache. רוצים ביצועים? SAS SSD ומעלה (M.2, PCIe Express). לא SATA.
  • הגדלת שטח – במקום לעבור את המסלול של להחליף דיסק דיסק ביותר גדולים, מומלץ להוסיף דיסקים למערכת. יש JBOD, יש PCIe Express, יש המון אפשרויות להוסיף אחסון.
  • טעות נפוצה: לא צריך בקרי RAID משוכללים, לא צריך Cache על ה-RAID, לא צריך סוללה, ולא להגדיר שום מצב RAID אלא אך ורק מצב JBOD בבקר. בקרים פשוטים (M1015 לדוגמא) מספיקים בהחלט. תשקיעו את הכסף בדיסקים.
  • אם אין כסף למערכת שכוולה SSD SAS, אפשר להסתפק ב-SSD SATA אולם יש לכך מחיר – SATA הוא פרוטוקול שיתופי, אין ערוצים נפרדים, כך שאם המערכת צריכה לכתוב כמות רצינית, הביצועים ירדו באופן רציני מאוד. כשזה מגיע לדיסקים מכניים, עדיף את ה-15K RPM אולם גם NL-SAS יכולים לעבוד טוב כל עוד לא מדובר בשימוש מכונה כסטורג' ל-VM (שם – רק SAS SSD ומעלה).
  • טיפ קטן אם אתם משתמשים במכונת ZFS כסטורג' ל-VM: אין לכם כסף ל-VEEAM או תוכנת גיבוי רצינית? ZFS Snapshots יכול לשמש כפתרון גיבוי ושחזור מעולה (מתוך הנחה שאתם מייצאים החוצה NFS, לא iSCSI).
  • בבירת המחדל ZFS על לינוקס נותן אפשרויות ליצור snapshots כל פרק זמן שתרצו ואין בעיה להכניס זאת ל-crontab, רק קחו בחשבון שזה לוקח מקום בדיסק, ולכן מומלץ לעיתים לנקות snapshots).
  • אם אתם רוצים להשתמש ב-ZFS כ-iSCSI target, מומלץ לעבור ל-LIO במקום TGT. מומלץ לקרוא את המאמר הזה. אגב, אם אתם הולכים לתת שרותי iSCSI ל-vSphere, אז LIO יתן לכם האצת VAAI, לא משהו להקל בו ראש.