הפוסט נכתב ע"י ד"ר רון רימון, מייסד ויו"ר חברת White Source.
חברות רבות עושות שימוש בתוכנות קוד פתוח בשלבים שונים של פיתוח המוצר. עפ"י חברת המחקר גרטנר, כ-85% מפרויקטי התוכנה משתמשים בספריות קוד פתוח, במילים אחרות כמעט ואי אפשר לפתח היום מוצרים מבלי להשתמש בקוד פתוח, וההערכה היא כי 80% משורות הקוד במוצרים מסחריים הם למעשה חלקים מספריות קוד פתוח.
לפי ארגון הקוד הפתוח (Open Source Initiative), תוכנת קוד פתוח היא תוכנה אשר קוד המקור שלה מופץ בצורה פתוחה ונגישה לכלל קהילת המפתחים, כאשר ניתן לערוך וליצור גרסאות חדשות שלו, והכול ללא תשלום דמי רישיון. אולם כאשר ניגשים לעבודה עם תוכנות אלו יש לשים לב למספר נקודות חשובות שימנעו מהחברה לבזבז זמן יקר, להיות חשופה לבעיות אבטחה או תביעות משפטיות בהמשך הדרך.
ניהול רישיונות שימוש
אי קיום הדרישות של רישיונות השימוש של כל אחת מהספריות יכולה לגרום לסיכונים מיותרים, כך לדוגמא בצד המשפטי שימוש ב-GPL עלול לפגוע בזכויות היוצרים שלך, ורישיונות אחרים עשויים להשפיע על האפשרות להגשת פטנט. בצד העסקי, שימוש לא זהיר יכול לגרור תביעות והפעלת צו מניעה נגדך או נגד לקוחותיך. כך לדוגמא אפל "זרקה" אפליקציה פופולארית כ-VLC Player מהאפסטור.
הנושא תופס מקום מרכזי במהלך מיזוגים ורכישות, וידוע על לא מעט מקרים שבהם הרוכש נסוג לאחר שבדיקת נאותות גילתה שימוש לא תקין. גם בהסכמים מסחריים משמעותיים אחרים, בפרט OEM, נהוג לדרוש רשימת ספריות קוד פתוח שבשימוש, והצהרת שימוש נכון כולל הסכמה לשיפוי במקרה הצורך. נקודה נוספת שלא כולם מודעים אליה היא שלעתים קרובות (ב64% מהמקרים) ספריות קוד פתוח מכילות ספריות קוד פתוח אחרות שרישיון השימוש שלהן שונה – לכן יש לתעד את כל הספריות הנ"ל ורישיונותיהן.
טיפול בפרצות אבטחה ובעיות איכות
קוד פתוח הוא קוד, ולכן סובל לעתים מאותם הפגמים של קוד אחר. עפ"י סקר של חברת Coverity, יש לצפות לפגם אחד בממוצע בכל 1,000 שורות קוד (גם פתוח וגם לא). ועפ"י סקר של חברת Veracode, כ-70% מיישומי התוכנה שנבדקו הכילו בעיות אבטחה ברמות שונות. כמובן שבעיות אבטחה ופגמים שמתגלים בקוד פתוח משפיעים על כל מוצר שמכיל אותם ויש לעקוב אחריהם ולתקנם בהקדם האפשרי. ואכן, קהיליות קוד פתוח נוטות לתקן פגמים במהירות יחסית, אך דווקא המשתמשים בספריות לעתים מתמהמהים ובכך חושפים את לקוחותיהם לאותם פגמים באופן שאינו מחויב המציאות. עפ"י נתוני White Source כ-85% מפרויקטי התוכנה מכילים ספריות קוד פתוח שלא עודכנו. ככלל, מרבית מפתחי התוכנה בודקים את הקוד שכתבו בקפדנות, אך אינם עושים זאת עבור קוד פתוח שמוטמע במוצריהם.
ניהול נכון
במרבית החברות כיום מנהלים את השימוש בקוד פתוח באופן ידני ובלתי יעיל, התנהלות אשר יוצרת שתי בעיות מרכזיות: בזבוז זמן יקר על מחקר עובדות טריוויאליות, ובמקביל, בצורת עבודה זו בד"כ מפספסים דברים חשובים כמו למשל מידע על ספריות תלויות. לחילופין, בחברות בהן משתמשים בסורקים אוטומטיים, מבזבזים זמן רב על בדיקת חשדות מדומים. לעתים קרובות מוצאים הסורקים אלפי קטעי קוד הדומים במידה מסוימת לקטעי קוד פתוח כלשהו, ואז מוטלת האחריות על המפתח לוודא שאין המדובר בהעתקה. בשני המקרים, מעטות החברות שבהן משתמשים בכלים באופן רציף ומשולב לאורך תהליך הפיתוח, ובכך מעמיסים על המפתחים בנקודת שחרור הגרסה. עוד נקודה שיש לשים אליה לב היא שכאשר עורכים בדיקה באופן חד פעמי (למשל בשחרור גרסה), או אחת לתקופה, קורה שמגלים ספריה שיש להחליפה (למשל כי הרישיון בעייתי) ואז יורד לטמיון כל המאמץ שהושקע באינטגרציה, ויתכן שנגרם עיכוב בתהליך הפיתוח ושחרור התוכנה.
אוטומציה
מפתחים רוצים לעסוק בפיתוח. החלק היחיד בניהול הקוד הפתוח שבו הם רוצים ויכולים לתרום הוא בבחירת הספריות המתאימות, ושילובן. לכן, רצוי שתהליכי זיהוי ובדיקת הרישיונות יהיו אוטומטיים ככל האפשר. כדי לאפשר זאת, המדיניות הארגונית בקשר לרישיונות צריכה להידון ולהיקבע ע"י מנהלים ומשפטנים באופן נפרד, ואז להכפות אוטומטית ע"י כלים המחוברים לכלי הפיתוח השונים. כמובן שיש גם לעקוב, אוטומטית כמובן, אחר פרצות אבטחה, ופגמים אחרים, שמתגלים בקוד פתוח שבו אנו משתמשים, ובעת האפשר לעדכן גרסאות שמתקנות אותם.
כותב הפוסט צפוי להשתתף ולדבר בועידת הקניין הרוחני על חוקיות וזכויות השימוש בתוכנות קוד פתוח.
קרדיט תמונה: open source via shutterstock.