אני מודה שמדובר באחת הכותרות ה…מלהיבות ביותר שנתתי לפוסט . אבל זו קריאה קריטית לכל מי שבונה תוכנה/מוצר שמשתמשים בה. אנחנו רגילים להשתמש בלא מעט ספריות תוכנה ומודולים שונים בכל שפה שבה אנו בונים את המוצר שלנו. אם אנו משתמשים במוצר קנייני, עניין הרשיונות פחות רלוונטי לפיתוח עצמו. אם למשל בית העסק חותם עסקה עם (לצורך העניין) חברת"משה שירותי עיבוד תמונה", אני לא צריך לבדוק את הרשיון של החברה אם אני מטמיע את הקוד שלה במוצר שלי כיוון שזה לא נסגר ברמת הפיתוח. אבל אם אני משתמש בקוד של ספריה כלשהי מגיטאהב או npm או Packagist או ווטאבר במוצר שלי – אני חייב לבדוק את הרשיון. למה? כי קוד פתוח לאו דווקא אומר "תשמש איפה שבא לך בחבחבחבח" ולא חסרים מקרים, גם בישראל, ששימוש ברשיון לא מתאים עשה לבעלים צרות צרורות (הנה דוגמה מעולה מהבלוג של עורך הדין יהונתן קלינגר שכותב בשפה פשוטה על עניינים משפטיים). גם סביב ריאקט, למרות שהיא היתה בגיטהאב ובקוד פתוח היה בלגן סביב עניין הרשיונות שממש העיב על ריאקט עד שפייסבוק שינו את הרשיון.
אם אתם מאנפפים בביטול וחושבים ש:"מה, זו רק בעיה של ווב ופרונט אנד" אז תחשבו שוב. נתתי את הדוגמה של e-vrit שהיתה לא מוצר וובי בכלל. לאחרונה ראינו בלגן אחר ברשיונות שהגיע מהכיוון של סלברייט – גם כן מוצר לא וובי. סלברייט, שהסתבכו עם סיגנל והמייסד/מנכ"ל שלה מוקסי שחשף, לאחר ניתוח של המוצר שלהם, שהם משתמשים בספרייה קניינית של אפל והציב אותם על מסלול התנגשות ישיר מול אפל. שהיא חברה שאתם ממש ממש ממש לא רוצים להיות איתה במסלול התנגשות ישיר או בכלל.
אם אתם בונים ספרית קוד פתוח שנועדה להפצה, אתר קטן או אופרציות סמול סקייל – אני לא חושב שצריך להיות מוטרדים בענייני רשיונות (למעט unknown שעליו אדבר בהמשך). אבל כל השאר – ובמיוחד חברות מוצר – כדאי לשקול להטמיע בדיקת רשיונות. ובדיקת רשיונות טובה נעשית כחלק מתהליך הפיתוח – כלומר בתהליך ה continuous integration שרץ אצלכם – מי בגיטהאב, מי בג'נקינס ומי בגיטלאב או במקומות אחרים. התהליך הזה בדרך מכיל בדיקות סטטיות שונות, בדיקות אוטומטיות ובדיקות אבטחה – אבל הוא יכול להכיל גם בדיקת רשיונות. בדיקת הרשיונות פשוטה – אם כל הרשיונות תואמים למדיניות החברה, הכל עובר. אם לא – הבילד נכשל. אחד מהמתכנתים יוסיף מוצר שאין לו רשיון או מוצר לא מתאים? הבילד ייפול. עכשיו תצטרכו ללכת לביזנס/ליגל/להנהלה ולבדוק איתם מה עושים. האם להכניס את החבילה ל-exclude list כי מדובר במודול קטן שפשוט לא הוסיפו לו רשיון? האם להחליף את החבילה? מה שכן – לא תעמדו במצב לא נעים אחר כך, כשזה יתגלה.
אם אתם עובדים בקורפורייט גדול (אהם אהם) יש סיכוי שכבר יש לכם בחברה הסכם עם ספק צד שלישי שמתמחה בבדיקות כאלו. סניק למשל מספקים מוצר כזה ולא, אני לא מקבל מהם תמלוגים 🙂 יש עוד כמה פתרונות שמסתובבים בשוק כשכל אחד מהם שונה בהתאם לאקוסיסטם.
כיוון שאני עובד בעיקר באקוסיסטם של ג'אווהסקריפט, אני אפרט על הפתרון באקוסיסטם הזה 🙂
אם אתם משתמשים ב-npm או ב-yarn – כלומר באקוסיסטם של ג'אווהסקריפט – אפשר גם להשתמש ב-package שקיים כבר ב-npm. יש את license-checker שהוא פופולרי מאוד אבל מיושן. יש לו פורקים שתיקנו לא מעט שגיאות, בעיות וצרות. אבל אפשר בהחלט להשתמש בו. איך? תלוי בכם ובאילוצים. אם למשל יש לכם רשיונות שאתם מחויבים להשתמש בהם ורק בהם, תצטרכו להשתמש ב-onlyAllow – כלומר רק אלו שמפורטים ברשימה (שימו לב – רשימה ללא רווחים ועם ; כמפריד). אם במוצר שלכם תהיה חבילת תוכנה שמשתמשת ברשיון שלא מפורט, תקבלו שגיאה:
npx license-checker --production --json --onlyAllow='MIT;ISC;BSC;BSD-2-Clause;Apache-2.0;CC-BY-3.0;CC0-1.0'
אם הכל תקין, תקבלו אובייקט JSON המפרט את הרשיונות – בכל מקרה זה יצליח והבילד לא ייפול פה.
אם יש לכם רשיונות ספציפיים שאתם צריכים להמנע מהם – אז משתמשים ב-failOn:
npx license-checker --production --json --failOn='MIT;CC-BY-2.0'
כמובן שיש לא מעט משחקים. אפשר למשל לבוא ולעשות exclude למודול מסוים שמשתמש ברשיון ספציפי (כי הליגל אישרו אותו לצורך העניין או שמנכ"לית החברה אמרה שזה בסדר והיא מקבלת על עצמה את הסיכונים).
אחד הדברים הכי שימושיים גם אם אתם מפתחים מוצר חינמי ובקוד פתוח הוא לבדוק אם אין לכם חבילות תוכנה שאין להן רשיון. למה זה שימושי? כי אם יש ב-dependencies שלכם רשיון שהוא unknown – זה ימנע מאחרים להשתמש במוצר שלכם.
npx license-checker --production --unknown
שימו לב שהשתמשתי בפלאג production – יש הבדל מהותי בין ספריות שמשתמשים בהן במוצר המוגמר (וכך כל אחד יכול לראות אם משתמשים בהן ואם לא) לבין ספריות שמשתמשים בהן ב-dev dependencies שבחלק מהתנאים לא חייבים לבדוק את השימוש בהן.
לסיכום
הראיתי כמה קל לבצע בדיקת רשיונות באקוסיסטם של ג'אווהסקריפט. אבל יש בדיקות כאלו בכל שפה ובכל אקוסיסטם רציני – ולא סתם יש בדיקות כאלו – כי זה באמת יכול לסבך אתכם ואת החברה שאתם עובדים בה. שימוש בבדיקות כאלו הוא ההבדל בין בלגן עתידי לסדר. ובאמת קל להטמיע אותן. אם אין לכם בארגון שלכם? הייתי הולך על זה. או עם מוצר בנוי, או לבנות בעצמכם.
4 תגובות
נייס!
חשוב מאוד! עניין הרשיונות לא מקבל מספיק תשומת לב….
זה התווסף לטרלו.
לליגל של אחד הלקוחות שלי יש דרישות מאוד מוגדרות במה מותר להשתמש לבמה אסור.
נמאס לי לחשוש אולי פספסתי משהו.
יש כל מיני דברים שאני לא אוהב באקוסיסטם של JavaScript, אבל אני מניח שדפוס השימוש ב-npm מקל על בדיקת רשיונות – ההרגלים הגרועים של מפתחי JavaScript (למה לי להבין מה צריך לעשות ולכתוב את הקוד – או להעתיק אותו מהאינטרנט, אם אני יכול לעשות mpn install leftpad) דווקא משחקים פה טוב – קל לעשות בדיקת רשיון (או חוסר ברשיון) אם יש מטאדטה על כל בלוק קוד נפרד.
פעם הייתי אחראי IP compliance בקבוצת פיתוח באחת מחברות התוכנה הגדולות בישראל, שם פיתחו ב-C++, והשתמשנו במוצר מסחרי שמנתח קטעי קוד ומשווה למאגרי תוכנה באינטרנט. ומחוץ ל-false positives, היה המון קטעי קוד שבברור הועתקו מהאינטרנט, אבל מאתרים שבהם אף אחד לא חשב שצריך לשים רשיון, או שיש איזשהו רשיון מומצא שלא ברור איך חברה יכולה להשתמש בו, או דברים נוראיים יותר (היי CPOL!), ו\או שהמפתח שהכניס את זה עזב לפני 3 שנים ואי אפשר להבין למה הקוד נראה ככה ותחת איזה רשיון הוא חשב שהוא משתמש בו.
כל זה לא אומר שאני נגד הרעיון – להפך, אבל אני כן רוצה לחדד:
א. חייבים לעשות IP Compliance מההתחלה – אם נזכרים להתחיל 3 שנים אחרי שהמוצר כבר בשוק, יתכן שכבר אי אפשר יהיה לתקן.
ב. תדריכו את המפתחים בהיגיינת רשיונות קוד – תחסכו לכם הרבה כאב ראש בעתיד. המון מפתחים לא מבינים שאסור סתם להעתיק קטעי קוד מהאינטרנט.
ג. מומלץ להשתמש בסורק שיודע להשוות קטעי קוד ולא רק מסתכל על מטאדטה.
תודה!
בהנחה שאני לא ארכוש רישיון מכלים דמויי סניק, האם ישנו חסרון מובהק בשימוש בכלים החינמיים?