בקצרה: GPL "מדביק" — כל קוד שמשלב GPL חייב להיות GPL ולהתפרסם. לעסקים: MIT ו-Apache בטוחים לשימוש מסחרי. לפני M&A — בדקו אילו רישיונות קיימים בקוד. שכחתם? זו בעיה משפטית רצינית.

למה בחירת רישיון חשובה?

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

MIT, GPL, AGPL — מה כל רישיון דורש בפועל, ומה הסיכון לחברה שלכם?

הצד המתירני: MIT License הוא הרישיון הפשוט ביותר. שתי דרישות בלבד: שמרו על הודעת זכויות היוצרים, ואל תאשימו את היוצר בנזקים. Apache 2.0 דומה אך מוסיף הגנה מפורשת מפני תביעות פטנטים.

האמצע: LGPL מאפשר לחברות מסחריות להשתמש בספרייה כ-"blackbox" מבלי לחשוף את הקוד שלהן, כל עוד לא שינו את הספרייה עצמה.

הצד ה"ויראלי": GPL2 ו-GPL3 דורשים שכל קוד שמשלב קוד GPL יהפוך בעצמו ל-GPL ויפורסם. AGPL מחמיר עוד יותר — חל גם על שירותי ענן שרצים מבלי שהקוד "מופץ" טכנית.

Creative Commons — לא לקוד

שימוש ברישיונות Creative Commons לקוד מחשב הוא טעות נפוצה. CC לא תוכנן לקוד — הוא מיועד לתוכן יצירתי כמו מוזיקה, תמונות, ומאמרים. לקוד — השתמשו ברישיוני OSI.

כיצד לבחור רישיון?

שאלו את עצמכם: האם רוצים שחברות מסחריות ישתמשו בקוד שלכם ללא תנאים? MIT. האם רוצים שכל מי שמשפר את הקוד יפרסם את השיפורים? GPL. האם רוצים לאפשר שימוש מסחרי אבל לא להתחרות בכם עם ה-SaaS? שקלו SSPL או Business Source License.

רוצים לשנות את הרישיון של הפרויקט? הנה מה שצפוי לכם

שינוי רישיון של פרויקט קיים דורש הסכמת כל התורמים (contributors). ארגונים גדולים כמו HashiCorp ו-Elastic עשו זאת לאחרונה ועוררו סערה בקהילה. אם אתם צופים שתרצו גמישות עתידית — בקשו מתורמים CLA (Contributor License Agreement) מראש.

📌 זווית מקצועית — לעורכי דין