𓏞מילים דיגיטליות

הצגה של גישות שונות בנוגע להגבלות על שימוש במידע (ובפרט: בתוכנה), וטענות הן כנגד הגישה ה"סגורה" והגישה של "FOSS" (ה־GPL כרשיון ה"מומלץ" בדרך־כלל). לגבי הראשונה: אצביע על החסרונות; לגבי השניה: אטען שהיא לא באמת "חופשית" (as in freedom, libre) ואצביע על הבעיות שבה מבחינת חירויות המשתמש, בעיות שבכמה מובנים גורמות לה להיות פחות "חופשית" אפילו מהגישה הסגורה.
בטקסט אתמקד ברישוי של תוכנות, אבל חלק גדול ממה שכתוב, בשינויים הנדרשים, רלוונטי גם לרישוי של יצירות אחרות. בשביל הקריאוּת לא כתבתי בכל מקום פירוט של הבדלים בסגנון של "במקרה של רישוי של מלל שכתוב בשפה טבעית, זה ככה וככה וככה"; סמכתי על זה שהקורא (כן, אתה) נבון מספיק כדי להבין לבד. בפרט, הביקורת על GPL רלוונטית גם ל־GFDL.

הערה קטנה: אני לא עורך־דין (או, כמו שנהוג לקצר: אלע"ד). אין ליחס למה שכתוב כאן כל סמכות משפטית שהיא וכו'.

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

יש כאלו שקוראים לתקופה הנוכחית "עידן המידע" (Information Age, באנלוגיה ל"עידן האבן", "עידן הברזל" וכו'). אולי זו תווית בומבסטית־משהו, לפחות להווה, אבל יש בה אמת מסויימת.
לא מידע ולא ידע הם דברים חדשים - טכנולוגיות, עובדות, אומנות, וסיפורים כולם עברו בין בני־אדם מאז ומעולם - זוהי מהותה של התקשורת, העברה של מידע וידע (במובן הרחב). גם הגבלה על מידע או ידע היא לא דבר חדש: גם בעבר הרחוק מידע הוגבל על־ידי אנשים שרצו בהגבלתו. עם זאת, למרות השם "עידן המידע", במאות האחרונות החלה תופעה חדשה - סוגים חדשים של הגבלה על הידע, "זכויות יוצרים" ו"פטנטים".

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

תוכנה סגורה

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

1. אין למשתמש אפשרות לקרוא את קוד־המקור* [לביאור, ר' ההערה בהמשך] של התוכנה.
   המשתמש מקבל תוכנה מקומפלת: הוא יכול להפעיל אותה, הוא יכול לנסות להנדס אותה לאחור, אבל מה שהוא לא יכול לעשות זה לקרוא את קוד המקור. למעשה על־פי חוק בארצות־הברית אסור אפילו להנדס לאחור מה שרשום עליו פטנט; פטנטים זה בכלל רעיון רע (על זה, אולי בפוסט אחר), אבל פטנטים על תוכנה זה רעיון רע במיוחד.
   "למה חשובה האפשרות לקרוא את קוד המקור?" שואל פלוני, שהוא לא מתכנת ולא מתכוון להיות מתכנת. אה! שתי סיבות עיקריות:
   • סור מרע: לדעת מה באמת התוכנה עושה.
     אם להשתמש בדוגמה חבוטה, תוכנה סגורה היא כמו כספת שקונים בלי לקבל שום מידע על איך היא פועלת. אולי יש בה back door? אולי היא עשויה מחומר כזה כך שאם מחממים נקודה מסויימת בגוף הכספת היא נפתחת? לא באמת תוכלו לדעת, לא בלי לעשות ניסויים והנדסה הפוכה. לעומת זאת, תוכנה שקוד־המקור שלה זמין, אפשר באמת לראות איך היא בנויה, ולהיות בטוחים שהיא עושה את מה שהיא אמורה לעשות, ורק את זה (המשל: כספת שיש לכם פירוט מלא על האופן שבו היא בנויה ועל האופן שבו אפשר לבנות אחת זהה לה). היתרון כאן הוא לא רק למתכנתים: עצם הנגישות של קוד המקור לאנשים שיכולים להבין אותו מועילה גם למי שלא יכול להבין אותו - הקיום של אנשים חיצוניים שיכולים למצוא back doors גם גורם למפתחים שלא להכניס כאלה במזיד ואולי להזהר יותר למנוע ליקויים אחרים, וגם, במידת הצורך, מאפשר לכלל המשתמשים בתוכנה לדעת על קיום של פרצות וחורים, שהיו יכולים להיות מוסתרים בקלות אלמלא העיניים הבוחנות, או עצם הקיום האופציונאלי שלהן.
     זה קצת, בכמה מובנים, כמו מחסום watch: במישור אחד, הקיום של עיניים בוחנות (כאלו שאיכשהו יכול להיות שאכפת לחיילים של הצבא הישראלי מהן: עיניים לא "ישראליות", של הסובלים מאותם חיילים, לא יותר מדי מזיזות להם) יכול להפחית את האלימות של החיילים, ובמישור השני - אותן עיניים בוחנות יכולות גם להפיץ מידע על הנעשה בפומבי. הבדל עקרוני הוא שבעוד שבתוכנה מסויימת אפשר לבחור שלא להשתמש אם היא לא לרוחכם, את הזרוע הצבאית של מדינת־ישראל כבר קשה יותר לעקוף, במיוחד אם האתנוס שלכם או האופן שבו אתם רוצים לחיות את חייכם לא מוצאים־חן בעיניה...
   • עשה טוב: היכולת ליצור קבוצות־פיתוח רב־גוניות בנות מספר רב של אנשים.
     באופן מסורתי, פיתוח של תוכנה סגורה נעשה בקבוצות תחומות וסגורות. רק העובדים בחברה שעובדים על הפיתוח של התוכנה רשאים לקרוא את הקוד שלה ולהשתתף בפיתוח. הרבה פעמים, מסיבות חיצוניות, מתקבל מצב שבו המפתחים של התוכנה נמצאים בחתך מאוד צר באוכלוסיה. מעט מוחות, ובטח כשהם באים מרקע דומה, יוצרים תוכנה משעממת, חסרת־מעוף, שאולי מתאימה לצורת המחשבה שלהם עצמם, אבל לא תמיד לזו של המשתמשים בתוכנה. מעט עיניים גם מאפשרות לבאגים לפרוח. וזה בכלל בלי לדבר על ההיררכיזציה שנהוגה בחברות, וחונקת את המחשבה החופשית.
     עכשיו, נניח שכל אדם, בפוטנציה, יכול להשתתף בפיתוח של התוכנה, ושהכל שקוף: כל ההתנהלות של הפיתוח והקוד עצמו. היתרונות שבמודל כזה הם עצומים: קצב פיתוח מהיר, זיהוי טוב יותר של באגים, פיתוח גמיש יותר (בעוד שבחברה סגורה אפשר להכתיב נורמות מסויימות בכל המישורים, כאן חייבים ליצור רכיבים מודולאריים שיתממשקו אחד עם השני ויעשו את זה בצורה יעילה. פיתוח כזה מקנה גמישות רבה יותר: רק תסתכלו על המבנה המודולארי של לינוקס מול "חלונות", שבנויה כמו יציקה אחת של בטון, או על הקלות שבה ניתן לשנות ולהתאים תוכנות כמו WordPress), יכולת להשתמש בחלקים שנכתבו כבר עבור תוכנה אחת בשביל תוכנה אחרת (מיחזור של קוד, שהרי הקוד זמין), יכולת של המשתמש (שיכול, כמובן, גם להיות חברה גדולה) להתאים את התוכנה לצרכיו בדיוק וללמוד איך היא פועלת (דורש, כמובן, ידע מהמשתמש או שימוש ב־outsourcing), וכן הלאה. הנקודה האחרונה מבטלת את התלות של המשתמש בחברה אחת, שיכולה להתנהג בעריצות במטרה לסחוט מהמשתמש עוד כסף (העדר תאימות בין הגרסאות של Microsoft Office לגבי אופן שמירת/פענוח הקבצים היא דוגמה מצויינת: על־ידי התנהגות כזו, מיקרוסופט מכריחה את המשתמשים שלה "לשדרג" את חבילת־התוכנה, גם אם למשתמש אין שום צורך ישיר בגרסה חדשה יותר). כמובן שחלק מהיתרונות האלה קיימים רק במידה שהקוד לא מוגן בזכויות־יוצרים במובן הסגור של המילה: אני עשיתי, לך אסור לשכפל ולהתבסס במישרין על מה שעשיתי.
     אפשר לכתוב על זה עוד הרבה, אבל אריק ריימונד כתב על זה כבר קודם. ממש מומלץ לקרוא את The Cathedral and the Bazaar שלו (יש גם תרגום עברי).

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

   • כתבנו תוכנה שמתאימה למחשב מסוג x. מה יקרה אם נרצה להריץ אותה על מחשב מסוג y? לא נוכל, בגלל שהפקודות שמקבל המחשב y שונות בצורה ובמבנה מאלו שמקבל מחשב x. לכן, נצטרך לכתוב את התוכנה מחדש, באופן שיתאים למחשב y; או לכל הפחות לבצע את ההתאמה הנדרשת על התוכנה המקורית, במקרה שיש דמיון מבני בין מחשבי־x ומחשבי־y. זו טרחה לא מעטה.
   • מה מבטיח לנו שקל לתכנת את המחשב ישירות (כלומר לתת לו את מערך־ההוראות באופן שהוא יוכל לפרש אותו בלא תיווך)? למעשה, בכל סוגי המחשבים היום, תכנות ישיר ב"שפת־מכונה" של תוכניות לא־טריוויאליות הוא לא נוח, לא גמיש, ודורש השקעה של זמן רב בעניינים טכניים לחלוטין, שוליים, בעבודה שחורה.

   בגלל שתי הסיבות האלה בעיקר - גמישות בין פלטפורמות־מחשוב שונות וקלות־התכנות - משתמשים בשפות תכנות. מדובר בתקן, שבדרך־כלל בנוי בצורה ברורה וקריאה לאדם, אחרי שרכש את הידע המתאים (מה שאי־אפשר להגיד על שפת־מכונה; היא לא ממש קריאה וקלה להבנה, גם לא לגורואים); תקן שמסדיר כתיבה של פקודות למחשב באופן שהוא נוח לתכנות ולקריאה, ובעקרון לא תלוי בפלטפורמה [הערת־אגב: "שפות תכנות" כמו Visual Basic לוקות בתכונה הזו - הן מתאימות רק לפלטפורמת־מחשוב אחת. במקרה של VB: מערכת־ההפעלה "Windows", על מחשבי x86].
   את הפקודות שנכתבו בשפת־התכנות ממירה תוכנה - "קומפיילר" - לצורה שאותה המחשב יכול לפענח. התהליך הזה הוא די בלתי־הפיך: את התוצאה שהתקבלה מההמרה (פלט מקומפל) אי־אפשר להפוך בחזרה, אוטומטית, לצורה קלה להבנה. למה לא? בשפות־התכנות, העיליות, קיימות הבחנות שלא קיימות בשפת־המכונה, והמבנה שלהן שונה.

2. אסור למשתמש להשתמש בתוכנה באיזה אופן שהוא רוצה.
   מהעדר האפשרות לקרוא את קוד המקור של התוכנה, ראינו שנובעות הגבלות רבות: פיתוח צר, סכנה ל־backdoors, סיכוי רב יותר לקיום באגים, אפשרות לחברה שמפתחת את התוכנה להתבריין כנגד המשתמשים, חוסר יכולת להתאמה אישית של התוכנה וחוסר יכולת לתרום לכלל המשתמשים על־ידי פיתוח של התוכנה באופן עצמאי ופרסום השינויים (אם בהחזרה של השינויים לעץ הפיתוח הראשי, ואם ביצירת פיצול (fork)).
   מלבד ההגבלות של תוכנה סגורה שנובעות מסגירות־הקוד, קיימות הגבלות נוספות, שנובעות מרשיון־השימוש של התוכנה. באופן רגיל, במסורת של פיתוח תוכנה סגורה, אסור למשתמש להפיץ עותקים של התוכנה, ולמעשה רק למי שקנה עותק של התוכנה ניתנת הזכות להשתמש בה (כאשר יש אפשרות לקנות מספר רב של רשיונות, עבור יותר ממחשב/משתמש אחד, בהתאם לתנאים ולמחירים מצד החברה שמפתחת את התוכנה). זו הגבלה מאוד חמורה על האפשרויות שיש אפשר לעשות בתוכנה.
   בנוסף להגבלה על היכולת ליצור עותקים של התוכנה, ברוב המקרים קיימים גם איסורים שונים על המשתמש, כמו היכולת לעשות בתוכנה שימוש מסחרי (בדרך־כלל במקרה שיש הבחנה, יש גרסה של הרשיון, זולה יותר, שבה אסור להפיק רווח כלכלי ישיר משימוש בתוכה, וגרסה יקרה יותר שבה לא קיים האיסור הזה) או לעשות שימוש חריג בתוכנה.

מהנקודות שהועלו קודם, אפשר לראות שתוכנה סגורה, מנקודת המבט של המשתמש, היא תוכנה מאוד מגבילה, תוכנה "רעה". אלא במקרה שאין אלטרנטיבה (כמו בתוכנות־נישה) סבירה, נראה שעדיף למשתמש לבחור בתוכנה פתוחה על־פני תוכנה סגורה: גם מבחינה כלכלית (ברוב המקרים תוכנה סגורה דורשת תשלום עבור השימוש בה, בעוד שמהחופש להפיץ ולהשתמש בתוכנה לא סגורה נובע שאפשר להשתמש בה, "חוקית", מבלי שיהיה תשלום נדרש) ובעיקר מבחינת הבטחון שיכול להיות למשתמש בתוכנה ומבחינת החירויות שהוא מקבל.

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

תוכנה חופשית "טובה" אליבא ד־FSF

כאן הגיוני היה להכניס סקירה היסטורית על ה־Free Software Foundation, על סטולמאן ו־GNU ו־GPL/GFDL. היה הגיוני, אבל זה כבר נעשה כל־כך הרבה פעמים בכל־כך הרבה מקומות, כך שאין באמת טעם לכתוב כאן שוב דברים שנכתבו בעבר.
כדי לקבל סקירה היסטורית, חפשו ברשת; היא מפוצצת במידע בנושא. ב"הקתדרלה והבזאר ועוד מאמרים על קוד פתוח וחופש המידע", שהוא חומר קריאה מומלץ מאוד, תוכלו לקרוא על זה, ועל דברים מעניינים נוספים.
אז בקצרה: בראשית היה סטולמאן, והוא מאס בסגירות בתוכנה. הוא אבא של ה־Free Software Foundation ושל GNU, מערכת־הפעלה דמויית־יוניקס שרשומה תחת הרשיון GPL (ר"ת: GNU Public License). ה־קרנל שבדרך־כלל מצרפים עם GNU הוא לינוקס. עד כאן היסטוריה.

"החזון של ה־FSF" ו"GPL" הם כמעט שמות־נרדפים.
מה אומר ה־GPL, בגדול ובלי להכנס לפרטים משפטיים וטכניים?

• מותר להשתמש בתוכנה לכל מטרה.
• מותר ליצור עותקים של קוד המקור (והוא זמין).
• מותר לשנות את התוכנה ולהפיץ את השינויים.
• תוכנה תחת GPL פטורה מאחריות של היוצרים על תוצאות של השימוש בה. (כמובן שניתן לתת אחריות, בתשלום או לא; הרשיון רק פוטר את היוצרים).
• כל נגזרת שנוצרה מיצירה שרשומה תחת GPL חייבת להיות רשומה תחת GPL.

כדאי גם לקרוא את ה־GPL עצמו, אם במקור ואם בתרגום.

בואו ונראה, לפי הסעיפים שרשומים למעלה, עד כמה ה־GPL "חופשי":
שלושת הסעיפים הראשונים מתירים למשתמש חירויות של שימוש בתוכנה: מותר לו להשתמש לכל מטרה, ליצור עותקים ולשנות את התוכנה. את החירויות האלה מבטלים הסכמי־שימוש סגורים.
הסעיף הרביעי די נייטרלי: הוא אומר "אם יוצא עשן סגול מהמחשב שלך אחרי שהפעלת את התוכנה, ז'בשך". מובן והגיוני: אתה לא בהכרח משלם לנו כסף עבור התוכנה - אנחנו לא מתחייבים שהיא תעבוד ולא תזיק לך.
הסעיף האחרון מעניין במיוחד. כל מה שמבוסס על תוכנה מג'ופלת (GPLed) גם הוא מג'ופל. בגלל שגם הוא מג'ופל, כל מה שמבוסס עליו צריך להיות מג'ופל, וכן הלאה. העקרון הזה נקרא copyleft.

הטענה של סטולמן והחבר'ה היא שהסעיף האחרון מגן על התוכנה להיות חופשית ומאפשר (ומעודד) לתוכנה חופשית (על־פי הגדרתם) להתפשט. ב־Copyleft: Pragmatic Idealism, לדוגמה, סטולמן מציג כמה "מקרי־הצלחה" של ה־GPL, כמו הקומפיילר GCC, ששופר על־ידי חברות מסחריות שהיו חייבות לפרסם את השינויים תחת GPL.
הטענה שלי היא שהאידיאל של ה"חופש" (freedom) שסטולמן מדבר עליו כל־כך הרבה מוקרב על מזבח המלחמה בתוכנה הסגורה. מבחינתו, כפי הנראה, "המטרה מקדשת את האמצעים", אם לדבר בססמאות נדושות.

מידע חופשי ותוכנה חופשית, כפי שלדעתי ראוי שיהיו

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

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

Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works.

(ר' ב־/.)

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

בואו רגע וננסה להבין מה בעצם עומד מאחורי הדרישה של ה־GPL לחיוב להפצה ב־GPL של דברים שרשומים תחת GPL. מאיפה הדרישה הזו נובעת? זו בעצם דרישה ל"שיתוף פעולה", "שיתוף פעולה בכפיה". זה נראה כאילו שכשרושמים תוכנה תחת GPL חסר הביטחון העצמי שמי שירצה יתרום מרצונו לפיתוח של התוכנה (במידה ומפרסמים את הקוד): ממש כופים שיתוף פעולה. אני לא מבין למה שמישהו אחר לא יהנה ממה שאני עושה, למה לחייב אותו "לתרום" - ירצה, ישלח תיקונים ושיפורים כדי שאלו יתווספו אל ה"ענף" המקורי, או שיפצל ענף משלו; למה הכפיה כאן? יש כאן משהו שנראה לי קשור לאיזו חשדנות וצרות־עין כלפי העולם, כאילו אומרים: הם רוצים לנצל אותי, הם רוצים לנצל [קרי: להשתמש] את מה שאני עושה בלי להחזיר לי כלום, הא! אתחכמה להם, אכפה עליהם לשתף איתי פעולה.

בנוסף, מה יקרה בעולם האידיאלי של FSF, בו הכל מג'ופל, כל דבר שזז כולל איתו רישיון GPL? זה לא מחזה יפה. אמנם אפשר לעשות הרבה שימושים "חופשיים" בתוכנות, אבל נעלמות להן חירויות חשובות אחרות: מי שלא רוצה להשתמש ב־GPL, נשמטות לו כתפי־הענקים מתחתיו. זה חופש כבול בשלשלאות פלדה. מכמה בחינות עדיף כבר מצב של "שלטון" של תוכנות סגורות, לא "ויראליות" באופן ההתפשטות של הרשיון שלהן, על המצב הזה.

גם לא ממש מובן לי למה להקריב את החירות של מי שמפתח משהו על־בסיס מה שפותח לבחור לעשות עם זה מה שהוא רוצה. כלומר, איזו תועלת יש בלחייב אותו לשחרר את זה תחת אותו רשיון? זה שוב חוזר לאותו העניין: זה נראה לי סתמי. אם לעשות פרפרזה על המשפט הנדוש "information wants to be free", אפשר לומר "information also wants to be used freely".

מכל הדברים האלה, נובע שלפחות מבחינתי הצורה הטובה ביותר לרישוי של תוכנות - אם העקרון של חופש וחירות, שכמובן תלוי בהגדרה שלנו לאלה, עומד כחשוב - היא שיחרור ל־Public Domain, רשות הציבור.
מה זה אומר? אם מה שחשוב לנו זו החירות לעשות בתוכנה כל מה שרוצים, PD בדיוק מאפשר את זה. מבחינה מסויימת, זה כמו במקרה שמישהו מצא את הקוד של התוכנה מודפס, מתגלגל לו ברחוב באילום־שם, רק שכאן הוא לא יכול לטעון ל"בעלות" על הקוד. (בהקשר הזה אפשר להזכיר את "הבה נגילה" אצל עידו אמין, שנמצא ב־PD). נניח שאנחנו משחררים תוכנה ל־PD (כלומר, מוותרים על זכויות היוצרים שלנו) ובנוסף מפיצים את הקוד המלא ברשת. במצב כזה כל אחד יכול לעשות מה שהוא רוצה עם הקוד, וזה לא מפריע לאחרים לעשות מה שהם רוצים. מישהו רצה לסגור את הקוד ולמכור את התוכנה המקומפלת שאפשר להפיק ממנו? יופי לו! זה לא מפריע כהוא־זה למצב שהיה קודם: עדיין אפשר להמשיך ולהשתמש באותו קוד מקורי בכל אופן שהוא. ה"הגבלה" היחידה ש־PD גורם היא שאי אפשר להגביל את השימוש ביצירה המקורית: כל אחד יכול לעשות איתה מה שהוא רוצה, בין אם זה למכור עותק סגור שלה, להפיץ אותה תחת GPL (ה־GPL יהיה תקף רק מאותו תת־ענף) או כל דבר אחר.

מצד שני, במצב כזה אדם יכול לקחת על עצמו את הקרדיט כיוצר של התוכנה. זה רק טבעי לרצות למנוע את זה, ולרצות לקבל קרדיט על מה שעשיתם. במקרה כזה, שימוש ברשיון בסגנון של BSD הוא הגיוני. זו אחד הסיבות שהפסקתי להשתמש בלינוקס ועברתי ל־FreeBSD; אמנם אני לא יכול לנטוש תוכנות מג'ופלות בלי לשנות באופן דרסטי את האופן שבו אני משתמש במחשב (ולפגוע מאוד בפרודוקטיביות), אבל להחליף מערכת־הפעלה לכזו שאני רואה כפתוחה וחופשית זה מעשה שרק מתבקש אם אני רוצה לשמור על עקביות עם הדברים שאני מאמין בהם.