על רישיון פרויקט תוכנה חופשית

ב־21.6.2010, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים; ‏7 תגובות

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

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

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

בד"כ זאת לא בעיה עד ש... רוצים לשנות את הרישיון. לדגומה, פרויקט תחת GPLv2 רוצה לשחרר קוד תחת GPLv3, או פרויקט תחת LGPL רוצה לעבור ל־MIT,‏ Boost או BSD. מסתבר שזה לא אפשרי - כי כדי לשנות את הרישיון, אתה חייב לרוץ אחרי 50 מפתחים ולקבל מהם אישור לשינוי רישיון, לעתים זה לא אפשרי. אז או שאתה מוותר על שינוי רישיון או אתה מוותר על חלק מהקוד שלך, בדיוק מה שאורון פלד דיבר עליו.

רוצים דוגמה? OpenSSL ועוד כמה פרויקטים שתקועים של ‎4-clause-BSD שלא תואם GPL; גם אם הם היו מאוד רוצים לשנות את הרישיון, אי אפשר.

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

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

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

תגובות

קפלן, ב־21.6.2010, 15:15

זה יתרון וחסרון, תלוי בסיטואציה.

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

ik_5, ב־21.6.2010, 16:42

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

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

יש בקוד הפתוח אבל הרבה בעיות אחרות. מחוסר הבנה של רישוי (מה ההבדל בין MPL לבין GPL למשל ?) וגם הבנה מתי אפשר לשחרר תת קוד ברישוי שונה מהקוד המקורי (למשל ב MPL אפשר להוסיף קוד שהוא l/GPL כאשר יורשים מקוד MPL), אבל ב GPL זה לא אפשרי. זו הסיבה שבלינוקס אי אפשר לכלול את zfs למשל.

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

אורון פלד, ב־21.6.2010, 23:25
  1. לטענתך לגבי חברה המפתחת תכנה קניינית ש־"כל זכויות היוצרים שייכות לה" אין הרבה בסיס במציאות. תכנות קנייניות גדולות מכילות כמעט תמיד מרכיבים רבים מצד שלישי, בעלי רשיונות שונים ומשונים.
  2. אתה צודק שקשה לשנות רשיון לקוד מרובה מפתחים. זה לא באג -- זה פיצ'ר! זוהי הגנה מובנית כנגד החלטה דיקטטורית של אדם (או חברה) אחת.
  3. אתה צודק שלחברות המובילות פרוייקטים זה יותר נוח שמפתחים בודדים מעבירים להם את הזכויות. בנוסף לנוחיות זה גם מספק להן שליטה מלאה על בסיס הקוד (בשונה מהמצב המקובל שתיארתי בסעיף 1). אבל לנוחיות הזו יש מחיר יקר -- נקודת כשל יחידה (החברה השולטת בקוד).
  4. בהקשר לסעיף הקודם, שתי החברות שהזכרת מספקות דוגמא מצויינת לסיכונים -- שתיהן נרכשו לאחרונה והרשיונות של התכנה שונו. לפחות באחד מהמקרים, המדובר בגורם בעל ניגוד עניינים ברור...
ארתיום, ב־22.6.2010, 9:54

אתה צודק שקשה לשנות רשיון לקוד מרובה מפתחים. זה לא באג – זה פיצ'ר! זוהי הגנה מובנית כנגד החלטה דיקטטורית של אדם (או חברה) אחת.

מסכים, ואפילו ציינתי שזה רצוי בחלק מהמקרים. אבל בכל רישיון כמו גם בתכנה יש "פריצות" שלפעמים ראוי לתקן (קרי GPLv2 -> GPLv3).

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

לא זכור לי שינויים ברישוי של MySQL אבל, במקרה של Trollteck זה דווקא יצא לטעני לטובה כי Nokia שחררה את Qt תחת LGPL.

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

צפריר, ב־22.6.2010, 10:08

כל פרוייקטי מו מוזילה , שתקועים עם רשיון NPL בלבד. או כל פרוייקטי BSD שתקועים עם רשיון BSD הישן.

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

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

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

ZFS הוא חלק מהקרנל של OpenSolaris. האם בקרנל של סולריס משתמשים בחלקים מהקוד של לינוקס? זה ייצור בדיוק את אותן הבעיות שנוצרו בכיוון ההפוך.

ארתיום, ב־22.6.2010, 13:24

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

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

צפריר כהן, ב־22.6.2010, 18:35

ארתיום: לדוגמה: https://issues.asterisk.org/view_license_agreement.php

הוסף תגובה:

 
 כתובת דוא"ל לא תוצג
 

ניתן לכתוב תגובות עם שימוש בתחביר Markdown.

חובה לאפשר JavaScript כדי להגיב.

דפים

נושאים