GPL לעומת MIT ו-Apache: הבדלים ברישוי תוכנה

GPL לעומת MIT לעומת Apache: מה כל רישיון דורש ממך

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

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

מדוע ה-GPL קיים: מדפסת שאף אחד לא הורשה לתקן

בסביבות שנת 1980 קיבלה מעבדת הבינה המלאכותית של MIT מדפסת לייזר מדגם Xerox 9700. המעבדה ביצעה התאמות בתוכנה של מדפסת קודמת כדי שתתריע כאשר מתרחשת חסימת נייר. עבור המדפסת החדשה לא היה בנמצא קוד מקור, והבקשה לקבל אותו סורבה בשל הסכם סודיות. ריצ'רד סטולמן, שהיה אז מתכנת במעבדה, התייחס לסירוב הזה כאל מקרה מייצג ולא כאל תקלה חד-פעמית, והכריז על פרויקט GNU ב-27 בספטמבר 1983.

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

סטולמן כתב תחילה רישיון עבור GNU Emacs, ולאחר מכן הכללי אותו לגרסה 1 של GPL ב-25 בפברואר 1989. גרסה 2 של GPL הגיעה ביוני 1991, והיא עדיין הרישיון של רוב תוכנות המערכת שאתה מריץ. ה-Lesser GPL נוצר עבור ספריות, כך שספרייה תחת Copyleft תוכל להיקשר לתוכנה תחת כל רישיון אחר, מבלי לגרור את אותה תוכנה לתוך ה-GPL.

פרט אחד קובע כיצד ה-GPL משפיע על מי שמארח שירותים בעצמו (self-hoster). החובה מופעלת בעת הפצה, לא בעת שימוש. אתה יכול לשנות תוכנת GPL, להריץ אותה על השרת הפרטי שלך, ולשרת באמצעותה את הציבור, מבלי להיות חייב דבר לאיש, כיוון שמעולם לא מסרת עותק לאחרים. הפער הזה הוא הסיבה לקיומו של ה-AGPL.

המסורת המתירנית: BSD, ולאחריה MIT

אוניברסיטת ברקלי בחרה בדרך שונה. קבוצת המחקר למערכות מחשב (Computer Systems Research Group) הפיצה את עבודתה על Unix תחת רישיון שדרש לשמור על הודעת זכויות היוצרים והתנער מכל אחריות. הגרסה המקורית כללה ארבעה סעיפים, כאשר הרביעי שבהם, "סעיף הפרסום", דרש מתן קרדיט לאוניברסיטה בכל חומר פרסומי המזכיר תכונות של התוכנה. דרישה זו אינה ישימה בקנה מידה רחב. Stallman מנה 75 אזכורים נפרדים בגרסה של NetBSD משנת 1997. אוניברסיטת ברקלי הסירה את הסעיף ב-22 ביולי 1999, במכתב מאת William Hoskins ממשרד רישוי הטכנולוגיה שלה.

מה שנותר הוא רישיון BSD בעל 3 סעיפים, המוסיף איסור על שימוש בשמות התורמים כדי לקדם מוצר, וגרסת 2 הסעיפים, שמוותרת גם על כך. נוסח רישיון MIT יצא מ-MIT בשנות ה-80, שם הוא כיסה את X Window System, ובפועל הוא מבצע את אותה עבודה כמו רישיון BSD בעל 2 סעיפים.

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

יש לקח שני מברקלי, וזהו הלקח שהפוסט הזה חוזר אליו שוב ושוב. מעבדות Unix System של AT&T תבעו את Berkeley Software Design בשנת 1992 בגין קוד ה-BSD, והתיק הגיע להסדר בתחילת 1994. במשך שנתיים איש לא יכול היה להיות בטוח שזה בטוח לבנות על בסיס BSD, והאימוץ נעצר בזמן ש-Linux צמחה. אי-ודאות משפטית עוצרת אימוץ מהר יותר מאשר היעדר תכונה כזו או אחרת.

מדוע Apache 2.0 הוסיפה הענקת פטנטים

הרישיון הראשון של The Apache Group היה נגזרת של BSD בעל 4 סעיפים, שכלל את אותה בעיית פרסום. גרסה 1.1, משנת 2000, הסירה סעיף זה. גרסה 2.0, שפורסמה בינואר 2004, הייתה כתיבה מחדש ולא רק תיקון.

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

שאר גרסה 2.0 הוא אדמיניסטרטיבי, וזו הסיבה שחברות מעדיפות אותה. קיים קובץ NOTICE מוגדר, כך שלייחוס יש מקום אחד במקום שיהיה מפוזר לאורך עץ הקבצים. ניתן להחיל את הרישיון באמצעות הפניה במקום להדביק אותו בכל קובץ מקור. תרומות מכוסות על ידי תנאים מפורשים. סימנים מסחריים מוחרגים. סקירה משפטית של תלות מסוג Apache 2.0 מוצאת שכל שאלה שעלתה כבר נענתה בטקסט, ולכן האישור הופך לשגרה, וזהו עיקר המשמעות של "ברירת מחדל ארגונית".

מה השתנה ב-GPLv3, ומדוע Linux נשארה ב-GPLv2

חברת TiVo שיווקה מקליט וידאו המריץ Linux ופרסמה את קוד המקור של ה-kernel, בדיוק כפי ש-GPLv2 דורש. החומרה ביצעה בדיקה של חתימה קריפטוגרפית בזמן ה-boot וסירבה להריץ kernel שהיא לא זיהתה. ניתן היה לקרוא את הקוד, לשנות אותו ולקמפל אותו. לא ניתן היה להריץ אותו על המכשיר שממנו הוא הגיע. לשון הרישיון קוימה אך מטרתו סוכלה, והפרקטיקה הזו קיבלה את השם tivoisation.

גרסה 3 של GPL, שפורסמה ב-29 ביוני 2007, עונה על כך ישירות. כאשר אתם מעבירים קובץ בינארי בתוך מכשיר צרכני, עליכם לספק גם את ה-"Installation Information": המפתחות או ההוראות הדרושים כדי להתקין גרסה שעברה שינוי ולהריץ אותה. גרסה 3 הוסיפה גם הענקת פטנט מפורשת, תנאים שנכתבו בתגובה להסכם הפטנטים בין Microsoft ל-Novell מנובמבר 2006, ותאימות חד-כיוונית ל-Apache 2.0.

Linux לא הלכה בעקבותיה. ה-kernel הוא ברישיון GPL גרסה 2 בלבד, ללא סעיף יציאה של "או כל גרסה מאוחרת יותר", וקובץ ה-COPYING שלה מציין זאת. Linus Torvalds התנגד בפומבי לתנאים נגד ה-tivoisation עבור חומרה חתומה. המחסום המעשי גדול יותר מהמחלוקת: ל-kernel יש אלפי בעלי זכויות יוצרים, כך שאף אחד לא יכול לאסוף את ההרשאות שרישוי מחדש ידרוש, גם אם כולם היו רוצים בכך. העובדה היחידה הזו היא ההגנה החזקה ביותר שיכולה להיות לפרויקט, וכדאי לזכור זאת כשבוחנים פרויקט שבבעלות חברה אחת.

הרישיון השני מ-2007 חשוב לכם יותר. ה-GNU Affero GPL גרסה 3, שפורסם בנובמבר של אותה שנה, מרחיב את חובת המקור לאנשים שמתקשרים עם התוכנה דרך רשת. הריצו שירות AGPL שעבר שינוי עבור הציבור, ואתם חייבים לאותם משתמשים את קוד המקור. זו הסיבה לכך שכל כך הרבה תוכנות web בניהול עצמי הן AGPL. Nextcloud היא דוגמה אחת, ואם אתם משווים בין החלופות בניהול עצמי ל-Nextcloud, שורת הרישיון במאגר של כל מועמד מספרת לכם יותר על חמש השנים הבאות שלו מאשר רשימת הפיצ'רים שלו.

אילו רישיונות ניתן לשלב בפועל?

תאימות פועלת בכיוון אחד, מרישיונות מתירניים (permissive) לעבר רישיונות copyleft.

• קוד תחת רישיונות MIT ו-BSD יכול להיכלל בכל פרויקט, כולל מוצר קנייני (closed source).
• קוד תחת רישיון Apache 2.0 יכול להיכלל בפרויקט GPLv3, והתוצר המשולב יהיה תחת רישיון GPLv3.
• לא ניתן לכלול קוד תחת רישיון Apache 2.0 בפרויקט המוגבל ל-GPLv2 בלבד. תנאי סיום הפטנט והשיפוי (indemnity) שבו הם תנאים נוספים ש-GPLv2 אינו מאפשר להוסיף. הן ה-FSF והן ה-ASF מפרסמים מסקנה זו.
• אינך יכול להעביר קוד GPL לרישיון מתירני. רק בעלי זכויות היוצרים יכולים לעשות זאת, מה שמחזיר אותך לשאלה מי הם אותם בעלים.

עידן שינוי הרישיונות: SSPL, BUSL, ומה הם לא

הגורם המניע היה מסחרי. חברה מחזיקה בזכויות היוצרים על מוצר, ספק ענן מוכר אותו כשירות מנוהל בהיקף נרחב אך תורם מעט מאוד בחזרה, והחברה משנה את הרישיון כדי לעצור זאת. Redis Labs ביצעה את הצעד הבולט הראשון באוגוסט 2018, כאשר הוסיפה את Commons Clause על גבי Apache 2.0 עבור כמה מהמודולים שלה. MongoDB הלכה בעקבותיה ב־16 באוקטובר 2018, במעבר מ־AGPLv3 ל־Server Side Public License.

ה־SSPL הוא למעשה AGPL עם סעיף אחד ששוכתב. אם אתם מציעים את התוכנה לצדדים שלישיים כשירות, עליכם לפרסם את קוד המקור של כל מה שאתם משתמשים בו כדי לספק את השירות, כולל תוכנות הניהול והתזמור סביבו. לחובה זו אין גבול ברור, ואף בית משפט לא בחן אותה. ה־OSI מעולם לא אישר את הרישיון, ו־MongoDB משכה את בקשתה במרץ 2019. דביאן (Debian) כבר הצהירה בדצמבר 2018 שתוכנת SSPL אינה שייכת למאגרים שלה, ופדורה (Fedora) קבעה בינואר 2019 שהרישיון אינו חופשי; בעקבות זאת, Red Hat הסירה את MongoDB מ־Fedora ומ־Red Hat Enterprise Linux. זו התוצאה הטכנית של שינוי רישיון: ההפצה מפסיקה לארוז את התוכנה, ולכן העדכונים שלכם מגיעים כעת ממאגר של הספק ועל פי לוח הזמנים שלו.

ה־Business Source License הוא מנגנון שונה. הוא הגיע ממייסדי MariaDB, וגרסה 1.1 שלו מתוארכת ל־2017. הוא אינו copyleft ואינו קוד פתוח. קוד המקור גלוי, והשימוש בו חופשי למעט השימוש שהספק מחריג – שבדרך כלל הוא הרצת שירות מתחרה – וכל גרסה הופכת אוטומטית לרישיון קוד פתוח אמיתי בתאריך שינוי שאינו מאוחר מארבע שנים לאחר אותה גרסה. הרישיון שאליו הוא הופך חייב להיות תואם GPLv2. חברת HashiCorp העבירה את Terraform ומוצרים נוספים שלה ל־BUSL 1.1 ב־10 באוגוסט 2023. גם Outline משתמשת בו, וזה נתון שכדאי להכיר אם אתם בוחרים מתוך חלופות Notion להרצה עצמית: הרצה עבור הצוות שלכם מותרת, אך בניית שירות על גביה אינה מותרת.

אף אחד מהרישיונות הללו אינו חסר יושרה. שניהם מצהירים בבירור שהם source available. אף אחד מהם אינו קוד פתוח לפי ההגדרה של ה־OSI, וההבדל משפיע עליכם יותר מאשר על ספק הענן שאליו הם כוונו.

OpenSearch: המחיר שמשלם מפעיל המערכת על פיצול רישוי

ב־14 בינואר 2021 הודיעה Elastic כי Elasticsearch ו־Kibana יעברו מרישיון Apache 2.0 לבחירה בין SSPL לבין Elastic License, החל מגרסה 7.11. גרסה 7.10.2 הייתה הגרסה האחרונה תחת רישיון Apache 2.0. כשבוע לאחר מכן הודיעה AWS כי תיצור ותתחזק פיצול (fork) של שניהם תחת רישיון Apache 2.0. ב־12 באפריל 2021 קיבל הפיצול את השם OpenSearch, ו־Kibana שונה ל־OpenSearch Dashboards. ב־12 ביולי 2021 שוחררה גרסה 1.0 של OpenSearch, שנבנתה על בסיס Elasticsearch 7.10.2 ו־Kibana 7.10.2.

בחנו את המחיר ששילמו מנהלי ה־clusters. שמות החבילות והמאגרים השתנו. כל אזכור של Kibana בתיעוד התפעולי הפך ל־OpenSearch Dashboards. שמות התוספים השתנו. לאחר מכן הגיע הפיצול לקוד היישום: החל מגרסה 7.13 של ספריות הלקוח הרשמיות של Elastic, הלקוח בודק מול מה הוא התחבר ומסרב להמשיך לעבוד מול כל מה שאינו Elasticsearch, תוך דיווח שהשרת הוא מוצר לא מוכר. החלטת רישוי בחברה שאינכם עובדים בה הופיעה כקריאה שנכשלה בתוך היישום שלכם.

הסיפור עבר תפנית פעמיים נוספות. ב־29 באוגוסט 2024 הוסיפה Elastic את AGPLv3 כאופציית רישוי שלישית, כך ש־Elasticsearch הנוכחי הוא שוב קוד פתוח המאושר על ידי ה־OSI. ב־16 בספטמבר 2024 העבירה AWS את OpenSearch ל־OpenSearch Software Foundation, בחסות ה־Linux Foundation, מה שהעניק לפיצול בית ניהולי שאינו חברה בודדת. חמש שנים לאחר הפיצול, שני הפרויקטים הם קוד פתוח, שניהם מתוחזקים, ו־OpenSearch נמצאת בסדרת גרסאות 3.x נכון לאוגוסט 2026.

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

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

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

כל פער נמדד מהודעת הספק לציבור ועד לשחרור היציב הראשון של הפיצול, לפי התאריכים המפורטים מטה. OpenSearch 1.0 דרשה 179 ימים, כיוון שהיה צורך לשנות את שמות הרכיבים ולבנות אותם מחדש ללא פיצול קודם להעתקה. OpenTofu דרשה 153 ימים. Valkey דרשה 27 ימים, כיוון שהיא פיצלה את Redis 7.2.4 ושמרה על הפרוטוקול ועל פורמט הנתונים בדיסק זהים. הכיוון הוא החלק המועיל: פיצול אמין מגיע כיום בתוך שבועות, עם קרן תומכת ומתחזקים בשכר מהיום הראשון.

Valkey ו-OpenTofu: אותו דפוס, מהיר יותר

חברת Redis Ltd העבירה את Redis מרישיון BSD 3-clause לבחירה בין RSALv2 ל-SSPLv1 ב-20 במרץ 2024. שמונה ימים לאחר מכן הכריזה קרן Linux Foundation על Valkey, פיצול (fork) מ-Redis 7.2.4 שנשאר תחת רישיון BSD 3-clause. הגרסה Valkey 7.2.5 שוחררה ב-16 באפריל 2024 עם אותו פרוטוקול ואותם קובצי נתונים, כך שעבור רוב המפעילים המעבר הסתכם בשינוי שם החבילה. לאחר מכן, במאי 2025, הוסיפה Redis את AGPLv3 כאופציה שלישית ב-Redis 8, מה שהופך אותה שוב לקוד פתוח לפי הגדרת ה-OSI, בעוד Valkey ממשיכה תחת ממשל עצמאי. המבנה דומה מאוד לזה של Elasticsearch.

Terraform עברה מסלול דומה עם פרק נוסף. OpenTofu פוצלה מגרסת ה-Mozilla Public License 2.0 האחרונה, הצטרפה ל-Linux Foundation בספטמבר 2023 ושחררה את גרסה 1.6.0 ב-10 בינואר 2024. ב-3 באפריל 2024 שלחו עורכי הדין של HashiCorp מכתב התראה (cease and desist) לפרויקט, בטענה שקוד מגרסת Terraform ברישיון BUSL הועתק לתוך הפיצול. ב-11 באפריל 2024 פרסמה OpenTofu תגובה מפורטת המכחישה זאת, ואיתרה את הקוד השנוי במחלוקת בהיסטוריה של רישיון ה-MPL המשותפת לשני הפרויקטים. שום דבר נוסף לא קרה בפומבי. הסיכון האמיתי בפרשה זו הוא זה שיש לזכור: האשמה בלבד יכולה להקפיא אימוץ של טכנולוגיה למשך רבעון, אפקט זהה לזה שהיה לתביעה המשפטית של Berkeley לפני שלושים שנה.

לא כל פיצול מתחיל ברישיון. Forgejo פוצלה מ-Gitea ב-2022 לאחר שהפיתוח של Gitea עבר לחברה מסחרית; זה היה סכסוך ממשל ולא סכסוך רישוי. Forgejo נשארה תחת רישיון MIT לאורך סדרת גרסאות 8, ולאחר מכן עברה לרישיון GPLv3 ומעלה החל מגרסה 9.0 ב-2024, כדי שלא ניתן יהיה להחזיר את עבודתה לתוך מוצר בשליטה מסחרית. אם אתם שוקלים את אפשרויות שרת ה-Git לאירוח עצמי, צמד זה הוא הדוגמה החיה והברורה ביותר לבסיס קוד אחד ושתי פילוסופיות.

הבדיקה שיש לבצע לפני אימוץ כל פתרון

ארבע שאלות, שיש לשאול לפני ההתקנה הראשונה ולא אחריה.

1. מי מחזיק בזכויות היוצרים? שינוי רישיון דורש אישור מכל בעל זכויות יוצרים, לכן פרויקט עם מאות תורמים עצמאיים וללא העברת זכויות מרוכזת אינו ניתן לשינוי רישיון באופן מעשי. פרויקט שבו חברה אחת מחזיקה בכל הזכויות יכול לשנות רישיון בהחלטת דירקטוריון.
2. האם קיים CLA, ומה הוא מעניק? הסכם תורמים (Contributor Licence Agreement) המאפשר לחברה לשנות את רישיון התרומה שלך לכל תנאי שתבחר, הוא המנגנון המדויק שמאחורי כל שינויי הרישיונות שצוינו לעיל. DCO (Developer Certificate of Origin), שורת האישור שגרעין ה-Linux אימץ ב-2004, אינו מעביר זכויות כלל. CLA המוחזק על ידי קרן בטוח יותר מזה המוחזק על ידי חברה, כיוון שחברה ניתנת למכירה.
3. מי מחזיק בסימן המסחרי? חברת Elastic שמרה לעצמה את השם Elasticsearch, לכן ה-fork נאלץ לשנות את שמו, וכל מדריך (runbook) שהזכיר את Kibana נדרש לכתיבה מחדש.
4. מה יעלה לך שינוי רישיון באופן אישי? שקללו את פורמט הנתונים, ספריות הלקוח, התצורה שתצטרכו לכתוב מחדש, והאם קיים כבר fork תואם.

שתי פקודות עונות על חלק מזה בתוך שניות.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

כל חבילה ב-Debian וב-Ubuntu מפיצה קובץ ב-/usr/share/doc/<package>/copyright, והוא מתעד את הרישיון של הגרסה שהתקנתם, לא את הרישיון שבו הפרויקט משתמש כיום. עבור bash ב-Ubuntu 24.04, הקובץ מציין את GNU General Public License version 3. הריצו את הפקודה השנייה בתוך עותק מקור (source checkout) ותקבלו את ההיסטוריה של קובץ הרישיון עצמו. כדאי לקרוא כל commit שבוצע שם בשנתיים האחרונות לפני שאתם בונים משהו על בסיס הפרויקט. אם הפקודה לא מציגה דבר, המאגר קורא לקובץ הרישיון שלו בשם אחר, לכן הציגו את רשימת הקבצים בתיקיית השורש וחפשו אותו.

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

FAQ

האם רישיון MIT זהה לרישיון BSD?

בפועל, MIT תואם לרישיון BSD בעל 2 הסעיפים: יש לשמור על הודעת זכויות היוצרים ועל הסתייגות האחריות, ולאחר מכן ניתן לעשות כרצונכם, כולל בניית מוצר סגור. רישיון BSD בעל 3 הסעיפים מוסיף דבר אחד: איסור על שימוש בשמות התורמים כדי לקדם את המוצר שלכם ללא אישור. הגרסה הישנה יותר, בעלת 4 הסעיפים, דרשה גם אזכור בחומרי פרסום, אך אוניברסיטת קליפורניה בברקלי ביטלה סעיף זה ב-22 ביולי 1999, כך שכמעט שום תוכנה מודרנית אינה נושאת אותו עוד.

האם ניתן להכניס קוד ברישיון Apache 2.0 לפרויקט GPLv2?

לא. רישיון Apache 2.0 מוסיף תנאים ש-GPLv2 אינו מתיר להוסיף, בעיקר סעיף פקיעת הפטנט, ולכן יצירה משולבת אינה יכולה לעמוד בשני הרישיונות בו-זמנית. ה-FSF וה-ASF מפרסמים שניהם מסקנה זו. הכיוון ההפוך עובד: קוד Apache 2.0 יכול להיכלל בפרויקט GPLv3, והתוצאה היא GPLv3. זו גם הסיבה שקוד Apache 2.0 אינו יכול להתמזג לתוך ה-Linux kernel, שמופץ תחת GPL גרסה 2 בלבד.

האם SSPL הוא רישיון קוד פתוח?

לא, ולתשובה זו יש השלכות מעשיות. ה-OSI מעולם לא אישר אותו, ו-MongoDB משכה את בקשתה במרץ 2019. דביאן הצהירה בדצמבר 2018 שתוכנת SSPL אינה שייכת למאגר שלה, ופדורה קבעה בינואר 2019 שהרישיון אינו חופשי, ולאחר מכן Red Hat הסירה את MongoDB מ-Fedora ומ-Red Hat Enterprise Linux. עבורכם, המשמעות היא שחבילה שההפצה שלכם נהגה לתחזק מגיעה כעת ממאגר של הספק, לפי לוח הזמנים של התמיכה שלו. גם ה-Business Source License הוא רישיון "זמין מקור" (source available) ולא קוד פתוח, אף שכל גרסה הופכת לרישיון קוד פתוח בתוך ארבע שנים.

האם שינוי רישיון חל על הגרסה שאני מריץ כבר עכשיו?

לא. רישיון שניתן עם גרסה מסוימת אינו יכול להישלל מעותקים שכבר פורסמו, וזו בדיוק הסיבה שפיצולים (forks) אפשריים. OpenSearch נבנה מתוך Elasticsearch 7.10.2, הגרסה האחרונה ש-Elastic פרסמה תחת Apache 2.0. מה שאתם מאבדים הוא את העתיד, כיוון שתיקון האבטחה הבא יגיע תחת התנאים החדשים. קיבוע (pinning) של הגרסה האחרונה ששוחררה תחת רישיון מתירני קונה לכם כמה חודשים, אך זו אינה תוכנית עבודה.