האם אתם מסכימים שבחירת מערכת הפעלה שתשמש כבסיס לבניית מערכת חדשה – דבר לא רק חשוב אלא גם מסובך? בתור חברת מיקור חוץ אנחנו לעיתים קרובות משתתפים בתהליך בחירת הטכנולוגיה ומערכת ההפעלה. אנחנו יודעים מהנסיון שבתהליך הבחירה צריך להתחשב במספר רב של הגורמים: אבטחת הקוד, נגישות למפתחים שיש להם ניסיון פיתוח בסביבה הנתונה, פיתוח אקטיבי של הטכנולוגיה וספריות, תמיכה בחוצה-פלטפורמות, יכולת שילוב במערכות אחרות, ועוד. כאן אני רוצה להתייחס לנושא לא פחות חשוב: עלות הרישיון לכלי פיתוח והמוצר. קיימים גם כלים שעולים כסף וגם כלים “כביכול חינמיים”. בואו נתבונן במה כרוכה “החינמיות” של לינוקס.
את היתרונות של בשימוש בלינוקס כולנו מכירים, אלה הם גישה לכל הקוד, מגוון כלי פיתוח חופשיים, אי תלות בהחלטות של חברה אחת, גישה רחבה למשאבים ולאוכלוסייה של מפתחים בכל העולם. יחד עם זאת, נושא של הרישיון הינו מאוד מעורפל.
אנחנו נתקלים לא פעם אחת ולא פעמיים במספר רב של מפתחים ואפילו מנהלים בעלי דעה שלינוקס הוא חינמי. אם הרצון הוא רק להתקין הפצת לינוקס חופשית כגון אובונטו (Ubuntu) ולהשתמש בה עבור צרכי עבודה יום-יומיים, אז הדבר אכן נכון. אולם אם צריכים לפתח על לינוקס ועבור לינוקס, אז הוא איננו בהכרח חינמי. לינוקס הינו חופשי, אבל זה לא שווה ערך לחינמי.
אחת הבעיות גדולות שנתקלים בהן מקבלי ההחלטות – זה להבין השלחות של הסכמי הרישיון של לינוקס. היום קיימים מגוון הסכמי רישיון קוד פתוח שונים, בין היתר GPL, LGPL, MIT, Apache ומספר אחרים, כך שלא תמיד ברור מה מותר ומה אסור לעשות עם התוכנה שמפותחת תחת לינוקס, ומקומפלת ע”י GCC על בסיס ספריות כמו glibc או Qt. תחת איזה רישיון להוציא את המוצר, האם חייבים לספק את הקוד או מספיק “רק” תוצר בינארי? הרבה פעמים “מתקבלת” החלטה לא להחליט, ומפתחים בלי להתייחס לרישיון, עד שיום אחד כעבור 10 שנים עוצרים מכירות של המוצר על הפרת זכויות היוצרים, כי המוצר אינו עומד בהסכמי הרישיון של אחד או יותר ממרכיביו ה”סטנדרטיים”.
ובכן, נעשה קצת סדר בדברים.
סוגי הרישיונות
ה-GPL או GNU GPL (GNU General Purpose License – הרישיון הציבורי הכללי של GNU) הינו סוג של רישיון של תוכנת קוד פתוח ו/או תוכנה חופשית (מכאן והילך נתייחס למושג קוד פתוח גם במובן של התוכנה החופשית), שמגדיר שיצירות נגזרות תשמרנה תחת אותם תנאי הרישיון. דהיינו, כל מה שנוצר ע”י שימוש ברכיבים שמופצים תחת GPL, חייב גם כן להיות מופץ תחת GPL, גם אם רכיבי המקור השתנו או שודרגו.
ישנן מספר גרסאות של ה-GPL. כיום משתמשים בעיקר ב-GPLv2 ו-GPLv3. הגרסה 3 לעומת גרסה 2 מכילה התייחסות לפטנטים, ליחסים עם סוגי רישיונות אחרים, לטיפול בהפרות של הרישיון ומספר נושאים נוספים. רישיון ה-GPL הינו אחד הרישיונות היותר נפוצים בעולם תוכנת קוד פתוח, החל בגרעין לינוקס עצמו וכלה במרבית התוכנות של GNU כגון GCC, וגם תוכנות כמו Notepad++, Code::Blocks, Joomla ואחרות.
ה-GNU LGPL (GNU Lesser General Public License הרישיון הציבורי הכללי המוקטן של GNU) בא לפתור את הבעית הקשיחות של ה-GPL. בגדול, רישיון ה-LGPL דורש הפצת קוד של התוכנה המפותחת רק במקרה שהתוכנה משתמשת ברכיב שמופץ תחת רישיון ה-LGPL ובוצעו בו שינויים כאלה או אחרים. במקרה ומשתמשים ברכיב כמו שהוא, אז אין דרישת הפצת הקוד. דוגמאות של תוכנות שמופצות תחת תנאיי השימוש של רישיון ה-LGPL הן 7 Zip, UClibc, Glib, GTK+, VLC, Qt (לא כולל גרסאות עבור ה-Embedded devices).
רישיון ה-MIT הינו רישיון לתוכנה חופשית שמאפשר שימוש חוזר גם בתוכנה קניינית, בתנאי שעותקו של הרישיון יצורף לעותקי התוכנה. תוכנה קניינית תישאר קניינית למרות שיש בה רכיבים ברישיון ה-MIT. רישיון ה-MIT תואם לרישיון ה-GPL, אם התוצר כולו מופץ תחת רישיון ה-GPL. דוגמאות של תוכנות שמופצות תחת רישיון ה-MIT הן Node.js, jQuery, מערכת X-Window ו-Lua.
רישיון אפאצ’י (Apache License) הינו רישיון לתוכנת קוד פתוח שמקורו במוסד התוכנה אפאצ’י. הרישיון דורש את שמירת ההערות הכוללות זכויות יוצרים ואת שמירת כתב הוויתור. קיים הסכם גרסה 2 של רישיון אפאצ’י שתואם גרסה 3 של רישיון ה-GPL, אך הגרסאות הקודמות אינן תואמות. בנוסף לתוכנות המפותחות ע”י מוסד אפאצ’י כגון שרתי אפאצ’י, קיימים מוצרים רבים שגם הם מופצים תחת תנאיי השימוש של הרישיון הזה, כמו OpenSSL (משתמש גרסה 1 של הרישיון) ומספר רב של מרכיבי אנדרואיד.
מה עושים?
קודם כל, מחד גיסא חשוב לציין שכל ההמלצות כאן מסתמכות על ניסיון מפרויקטים רבים ומגוונים, שקשורים בין היתר לנושא הרישיונות. מאידך גיסא, אנחנו לא עורכי דין, ולכן במקרה של ספק תמיד כדאי להעזר בעורך דין שמתמחה בנושאי קניין רוחני.
אם אי-פעם קניתם נתב ביתי, רוב הסיכויים שלא שמתם לב לחתיכת נייר שהייתו איתו בקופסה ופשוט זרקתם אותה. בפעם הבא אנחנו ממליצים לעיין בה. שם, בין היתר, תוכלו לראות את הרשימה של כל התוכנות שנמצאות בשימוש בנתב עם ציון של כל הרישיונות והדרך שבה אפשר לקבל את קוד המקור שלהן. זה בא לא מהרצון הטוב של היצרן, אלא מפני שכל הרישיונות של קוד פתוח דורשים הוספת הצהרה כזו. לכן כאשר אתם משחררים את המוצר שלכם לשוק, אתם חייבים להוסיף אותה במסמכים נלווים, או באחד החלונות “אודות” של התוכנה שלכם. בתור דוגמה טובה לכתיבת ההצהרה ניתן להשתמש בזו שמופיעה בטלפון הנייד שלכם תחת “הגדרות”->”אודות”->”מידע משפטי”.
כיוון שאנחנו מדברים על לינוקס, אז לפחות דבר אחד נדרש באופן חד משמעי: לתת אפשרות גישה לקוד של הגרעין של לינוקס, כולל כל השינויים שנעשו עבור החומרה שלכם, תהליך הבניה עם ציון של כל ה-toolchains הרלבנטיים, ואפילו איך ניתן לטעון את התוצר הבניה למכשיר שלכם.
במקרה שתהיתם האם צריך להסביר אילו מהברגים צריך לפתוח ואיפה לחבר את הכבל, אז התשובה היא כן, (וכנראה כדאי גם לציין שהדבר עלול לגרום לביטול האחריות ו/או התמיכה שלכם במוצר). האם מספיק לתת קישור לאתר שממנו הורדתם את ה-toolchain או את קוד המקור של לינוקס? התשובה היא לא, זה באחריות שלכם לשמור על הגרסאות של כלים ומרכיבים.
ישנם מספר אופנים לפרסם את הקוד, אבל שניים מהם נפוצים יותר. ביחד עם רשימת הרישיונות של קוד פתוח שצירפתם למוצר ניתן:
א) לתת קישור באינטרנט למקום בו נמצא קוד המקור (למשל, באתר הבית שלכם)
ב) לפרסם הצהרה כתובה, שמסבירה איך ניתן לקבל את הקוד עם כל התהליכים הנלווים. ניתן גם לבקש חיוב על הדבר, אך הוא צריך להיות מוגבל לעלות שליחת ה-CD בדואר. חשוב לציין שברגע שקיבלתם את בקשת הלקוח שמעוניין בכך, אתם מחיובים לספק את הקוד מיידית, אחרת אתם חשופים לתביעה על הפרת תנאיי הרישיון.
כל הדברים הנ”ל רלבנטיים גם לגבי ספריות וכלים אחרים שמופצים תחת רישיונות GPL ו-LGPL, דוגמת ה-Qt או glibc. אם השתמשתם בספריות שמופצות תחת GPL, בין שבאמצעות קישור (linkage) סטאטי ובין שדינאמי, רוב הסיכויים שאתם חייבים לפרסם גם את קוד המקור שלכם. בהקשר זה ב-2001 סטיב בולמר, המנכ”ל דאז של מיקרוסופט, השווה את ה-GPL ל”סרטן שבמתחבר, במובן קניין הרוחני, לכל מה שהוא נוגע”.
לעומת זאת, אם השתמשתם בקישור דינאמי בלבד לספריה המופצת תחת LGPL (כמו Qt) ולא שיניתם אותה, ניתן לשמור על הקוד שלכם. בנוסף היינו רוצים להרגיע אתכם לגבי שימוש במהדר GCC: התוצרים שלו אינם תחת ה-GPL, אבל כאמור אתם חייבים לספק גישה לגרסת GCC המתאימה.
מהן החלופות?
אחד הדברים שיורידו מכם את הדאגות לגבי הקניין הרוחני שלכם הוא לקנות את הרישיונות של ספריות – Qt, של אינטל וגם אחרים מציעים אפשרות לרכוש את הרישיון לספריות שלהם, ואז, כמו בעולם של מיקרוסופט, אין צורך בפתיחת הקוד.
האפשרות השנייה היא להשתמש ב-Embedded Android. אומנם במקרה הזה עדיין תהיו חייבים לספק את קוד המקור של הגרעין (כידוע אנדרואיד משתמש בגרעין של לינוקס), אבל כל מערך של ממשק המשתמש מופץ תחת רישיון אפאצ’י 2.0.
במספר הפרויקטים בהם השתתפנו היה ניתן להסתפק במערכות הפעלה “זמן אמת” קטנות (כדוגמת FreeRTOS) על בסיס חומרה מצומצמת (כגון Cortex M7 או Cortex M7). מערכות מסוג זה תומכות בממשק משתמש עבור מסכי LCD על בסיס מערכות Touch GFX או Embedded Wizard, קידוד וידאו בחומרה, ממשקי אודיו, אתרנט ו-WiFi עבור IoT, ו-USB למכשירים היקפיים.
לסיכום
היינו רוצים לחזור על מספר נקודות חשובות:
אסור להזניח נושא של רישיון בעולם הקוד הפתוח. את בדיקות הרישיונות של הכלים והפלטפורמות לפיתוח צריך לבצע בתחילת הפרויקט, אחרת עלולים להיתקל בצורך בכתיבה מחדש של חלקים מתוכנה, כי היא לא תעמוד בדרישות הרישיון.
אם לא רוצים להסתבך עם תביעות ועצירת מכירות, תמיד צריך להתייעץ עם עורך דין שמתמחה בקניין הרוחני.
תמיד כדאי לשאול את השאלה: אולי יש חלופות זולות יותר?
