בדיקת רשיונות תוכנה כחלק מהליך CI

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

אני מודה שמדובר באחת הכותרות ה…מלהיבות ביותר שנתתי לפוסט . אבל זו קריאה קריטית לכל מי שבונה תוכנה/מוצר שמשתמשים בה. אנחנו רגילים להשתמש בלא מעט ספריות תוכנה ומודולים שונים בכל שפה שבה אנו בונים את המוצר שלנו. אם אנו משתמשים במוצר קנייני, עניין הרשיונות פחות רלוונטי לפיתוח עצמו. אם למשל בית העסק חותם עסקה עם (לצורך העניין) חברת"משה שירותי עיבוד תמונה", אני לא צריך לבדוק את הרשיון של החברה אם אני מטמיע את הקוד שלה במוצר שלי כיוון שזה לא נסגר ברמת הפיתוח. אבל אם אני משתמש בקוד של ספריה כלשהי מגיטאהב או 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 שבחלק מהתנאים לא חייבים לבדוק את השימוש בהן.

 לסיכום

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

פוסטים נוספים שכדאי לקרוא

רספברי פיי

התקנת OpenCanary על רספברי פיי

מה זה OpenCanary ואיך אפשר להתקין אותה על רספברי פיי ולשדרג את אבטחת הרשת הביתית או המשרדית.

תמונה של עציץ, רספברי פיי ורמקול
רספברי פיי

לגרום לעציץ שלכם לדבר

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

גלילה לראש העמוד