בתחילת אוקטובר השנה הגישה חברת Splunk, חברה מובילה בתחום התוכנות לניתוח דאטה, תביעה כנגד עובד לשעבר (קלינט שארפ) וחברת Cribl, חברה מתחרה בתחום ניתוח דאטה, בגין שימוש בקניין רוחני ללא רישיון ושלא כחוק. על פי כתב התביעה, מר שארפ ייסד את חברת Cribl על בסיס קוד של Splunk, אותו לכאורה גזל מהחברה בזמן שעבד ב-Splunk. כמובן שמיד עם הגשת התביעה פרסמה חברת Cribl הכחשה בטענה כי חברת Splunk מנסה להשיג יתרון תחרותי בשוק על ידי תביעות של חברות מתחרות.
על פי כתב התביעה מר שארפ תרם קוד קנייני של החברה לפרויקט קוד פתוח אותו ניהל באתר GitHub ואשר על בסיסו הקים את חברת Cribl. מר שארפ לכאורה הסיר כל סימן מזהה מהקוד ותרם את הקוד כקוד מקורי שלו תחת רישיון קוד פתוח (MIT) המאפשר שימוש חופשי בקוד, לרבות שימוש מסחרי.
עם הגשת התביעה הוסר הפרויקט מחשבונו הפרטי של מר שארפ אשר מונה כעשרים וחמישה פרויקטים שונים, חלקם בני יותר מעשור. למרות שכתב ההגנה טרם הוגש סביר כי יטען שפרויקט הקוד הפתוח של מר שארפ, למרות שנועד לאותה תכלית, נכתב באופן עצמאי, בזמנו החופשי, וכי למר שארפ היסטוריה ארוכת שנים של תרומה לקוד פתוח, הרבה לפני המקרה הנ"ל, וכי כאמור אין בכך כל הפרה של זכויות יוצרים.
לחברת Splunk עשוי להיות אתגר לא פשוט. מבט חטוף בפרויקטים הציבוריים של החברה באתר GitHub מלמד שבכל הנוגע לניהול הקוד הפתוח הציבורי של החברה יש לא מעט בלאגן. ישנם פרויקטים ציבוריים ללא רישיון. בפרויקטים אלו כאמור לא ניתן לעשות שימוש חופשי כחוק ללא רישיון מצד בעל זכויות היוצרים. כמו כן, בין הפרויקטים הציבוריים של Splunk ישנם גם פרויקטים עם רישיון מוצהר אשר עומד בסטירה עם רישיונות קוד פתוח של חלק מרכיבי הקוד הפתוח בהם נעשה שימוש בפרויקט.
"הקוד הקנייני של חברה מנוהל לרוב באותם סטנדרטים ועל פי אותם נהלים כפי שמנוהל הקוד הפתוח של החברה. במידה רבה פרויקט קוד פתוח של חברה מסחרית עשוי להעמיד את החברה במערומיה גם בנוגע לאופן בו מנוהל הקוד הקנייני של החברה, זה שאינו פתוח לעיני הציבור"
הניסיון מלמד שהקוד הקנייני של חברה מנוהל לרוב באותם סטנדרטים ועל פי אותם נהלים כפי שמנוהל הקוד הפתוח של החברה. במידה רבה פרויקט קוד פתוח של חברה מסחרית עשוי להעמיד את החברה במערומיה גם בנוגע לאופן בו מנוהל הקוד הקנייני של החברה, זה שאינו פתוח לעיני הציבור. הדבר נכון באספקט של ציות לרישיונות קוד פתוח של רכיבים בהם נעשה שימוש בפרויקט, אבל לא רק.
הדבר נכון גם באספקט של חולשות אבטחה בקוד. באספקט השני לפחות, נראה כי Splunk עשו עבודה טובה יותר, כפי שעולה מסריקה מדגמית בכלי software composition analysis המציינים חולשות אבטחה ידועות ברכיבי קוד פתוח. במקרה של Splunk, אופן ניהול רישיונות הקוד הפתוח בפרויקטים הציבוריים של החברה עשוי להעיד על מדיניות קוד פתוח חסרה באופן כללי ותרומה לקוד פתוח בפרט, חוסר בתהליכים ו/או אכיפה, אשר בהחלט עשויים להקשות על Splunk בהמשך.
ניהול כושל, קוד פרוץ
אם המקרה הנ"ל נשמע לכם מעט מוכר אולי זה בגלל שלפני כשנתיים הייתה תביעה דומה של חברת Lynwood כנגד שני עובדים לשעבר וכנגד חברת F5, תביעה אשר עדיין מתנהלת בבית המשפט ובמרכזה שרת האינטרנט הפופולארי NGINX. גם במקרה זה נטען כי העובדים תרמו קוד קנייני של החברה לפרויקט קוד פתוח אשר לימים שימוש כבסיס לחברה אותה הקימו העובדים לשעבר.
חברה אשר מאוחר יותר נמכרה ל-F5 בתמורה צנועה של 670 מיליון דולר (סכום יפה לכל הדעות). בשונה מהמקרה של Splunk, במקרה של Lynwood העובדים תרמו את הקוד הקנייני לפרויקט קוד פתוח של החברה עצמה. על פי כתב התביעה של Lynwood התרומה נעשתה לכאורה ללא אישור תקין של תוכן הקוד שנתרם ותחת מסווה כי מדובר בקוד בעל ערך נמוך.
במקרה של Lynwood כנגד העובדים נפתח גם הליך פלילי ברוסיה אשר בינתיים נסגר ללא כתב אישום. אם יש דבר אחד שחשוב ללמוד מהמקרים של Splunk ו-Lynwood זו החשיבות של מדיניות תרומה ברורה לקוד פתוח. בהנחה ומדובר בתרומה של קוד לפרויקט קוד פתוח אשר מתבצעת בתום לב, הרי שיש בכוחה של מדיניות ברורה למנוע בלבול אפשרי ותרומה אסורה. ובהנחה ומדובר בתרומה של קוד לפרויקט קוד פתוח שאינה בתום לב, הרי שיש בכוחה של מדיניות תרומה ברורה להקל את ההוכחה בבית המשפט בבוא היום.
מדיניות תרומה לקוד פתוח חשובה לא רק לארגונים אשר תורמים לקוד פתוח בפועל, אלא לכל ארגון אשר יש בבעלותו קוד. מדיניות תרומה לקוד פתוח לא חייבת להיות ארוכה. מסמך מדיניות אשר אומר את הדבר הבא: "הארגון שלנו לא תורם לקוד פתוח", הינו מסמך מדיניות מקובל, ובלבד שכל העובדים מודעים לקיומו ולתוכנו. מסמך מדיניות אידאלי יכלול לרוב התייחסויות לא רק לתרומה בשם הארגון אלא גם לתרומה פרטית על ידי העובד. כגון במקרה של תרומה פרטית לקוד פתוח תוך שימוש במשאבים של הארגון או תרומה לפרויקטים אשר עשויים להתחרות במוצרים ו/או שירותים של הארגון ואשר רצוי להתנותם באישור פורמאלי ומראש.
הכותב הוא יניב אוזרזון, עו"ד לתחומי קניין רוחני ומשפט מסחרי ושותף מייסד בחברת FOSSAware, חברת ייעוץ ושירותים לניהול סיכוני שימוש בקוד פתוח