כש ריצ'רד סטולמן חשב לראשונה על תוכנה חופשית היו לו ארבע חירויות בסיסיות של GPL במוחו: החירות להריץ את התוכנה, החירות לשנות את קוד המקור, החירות להפיץ את התוכנה והחירות להרשות אבולוציה ושיפור מתמד של התוכנה. המקרה שהביא את סטולמן לתובנה הזו היה פשוט: הוא עבד כמתכנת במעבדות הבינה המלאכותית של MIT ורצה לשנות את הדרייברים במדפסת הXerox שלו. כשXerox עברו לדרייברים קניינים ומנעו מסטולמן לגשת לקוד המקור של המדפסת, הוא חשב לראשונה על תוכנה חופשית כדי לעזור לו ולאחרים לחלוק ידע ולשחק עם התוכנה. (קראו עוד כאן)
מאז שהחלה האבולוציה של רשיון הGPL, היו ויכוחים רבים (והיה לי העונג לקחת חלק לפחות באחד מהם) אודות סגולות הרשיון. אולם, מהלכי השבוע החולף וההצהרות שמראות שהחירויות הבסיסיות של הGPL אינן מה שתנועת התוכנה החופשית מתכוונת אליהן בדרך שהיא מפרשת את הGPL, הן צעד שעשוי להזיק לקהילת הקוד הפתוח במקום לעזור לה.
שתי מערכות תוכן (CMS) פופולאריות החליטו ליישם פרשנות שמרנית ונוקשה של הGPL. שתי המערכות הפופולריות מבוססות שרת ומשוחררות תחת רשיון GPL. הן WordPress והן Joomla החליטו שבכדי להופיע במאגר שלהן להרחבות, עלייך לשחרר את התוסף (או התבנית) תחת תנאי הGPL. החלטת וורדפרס שתבניות לוורדפרס חייבות להיות משוחררות ברשיון GPL והחלטת ג'ומלה שכל התוספים חייבים להיות משוחררים תחת הרשיון הזהמסתמכות על פרשנות קפדנית של מרכז התוכנה החופשית: "it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works".
בכדי להבין את ההסבר, יש צור להבין את רשיון הGPL ואת תנאיו. הרשיון דורש שכל יצירה נגזרת (כלומר יצירה שמבוססת על התוכנה המקורית) תהיה משוחררת תחת רשיון GPL גם כן (ראו סעיף 2 לGPLv2): "מותר לך לשנות את העותק שלן או עותקים של התוכנה או כל חלק ממנה, ובכך לצור יצירה המבוססת על התוכנה, ולהעתיק ולהפיץ שינוי זה או עבודה זו…"; למשתמש ניתנת החירות לשנות את התוכנה בלי דאגות כל ע וד הוא לא מפיץ אותה בכל צורה למעט הGPL (כלומר, מותר לו לשנות ולא להפיץ). זהו האופי הויראלי של הGPL: כל השיפורים בתוכנה חייבים להיות משוחררים תחת אותו הרשיון (אם משחררים אותם).
אולם, חירות 1, כפי שהוגדרה על ידי סטולמן עצמו, היא החירות לשנות את התוכנה, בלי החובה לשחרר את השינויים. כאשר אני 'מתקן' תוכנת מחשב להתאים לצרכים שלי, או כשאני מעצב תבנית לבלוג, אני לא חייב לשחרר את זה לציבור (בשביל זה יש את הaGPL, ואם וורדפרס לא היתה מבוססת בצורה כל כך כבדה על קוד של אחרים, אולי היא היתה יכולה לשחרר את התוכנה תחת הרשיון הזה ולשמור על החירויות). מה שג'ומלה ווורדפרס עשו הוא בדיוק ההפך, הן לקחו חירויות של אחרים להריץ את התוכנה (חירות 0).
קחו לדוגמא את התוכנה הפופולרית של עמרי ידן, Firestats. עמרי כתב אפליקצית PHP שמספקת שירותי אנאליטיקס פשוטים ויעילים. התוכנה רצה כמעט על כל שרת וכל מערכת תוכן, ומסופקת חינם. מעבר לכך, Firestats אינה יצירה נגזרת של WordPress או Joomla, היא "יצירה נפרדת ועצמאית" (GPLv3 סעיף 5, GPLv2 סעיף 2) שמשמעה שהיא בצד הבטוח של GPL, כאשר הרשיון קובע כי "אם חלקים נפרדים של היצירה אינם נגזרים מהתוכנה, ובצורה סבירה ניתן להחשיבם כעצמאיים ונפרדים בפני עצמם, אז רשיון זה, ותנאים, לא חלים על חלקים אלו כאשר אתה מפיץ אותם כיצירות נפרדות"
לכן, גם אם פיירסטאטס היה משוחרר אם אחת ממערכות הCMS המג'ופלות, הוא עדיין היה בצד המותר להפצה ללא צורך בהרשאה תחת הGPL. אולם, בכדי להיות מופץ עם Joomla, עמרי נדרש לשנות את תנאי הרשיון שלו ולשחרר אותו תחת הGPL.
האבסורד מגיע ליישום כאשר הלבנת-GPL מתרחשת. דמיינו על המקרה הבא: אני משתמש במספר מקטעי קוד בעיצוב שלי, לרבות קוד שנכתב תחת רשיון קריאטיב קומונס ממדריך, ועיצבתי תבנית. בכדי להריץ את התבנית, השתמשתי גם בקוד של וורדפרס וגם PHP:
<title><?php if (is_home () ) { bloginfo('name'); } elseif ( is_category() ) {
single_cat_title(); echo " - "; bloginfo('name');
} elseif (is_single() || is_page() ) {
single_post_title();
} elseif (is_search() ) {
bloginfo('name'); echo " search results: "; echo wp_specialchars($s);
} else { wp_title('',true); }
?></title>
הדוגמא מראה שימומש בפקודות מספריות של PHP, MySQL וWordPress. אולם, זו אינה יצירה נגזרת של PHP או MySQL ואינה יצירה המבוססת עליה; זה ברור. לכן, מדוע זה נחשב כיצירה נגזרת של וורדפרס? האם דברים היו נראים שונה אם לוורדפרס היה API לפוסטים ומידע, והתבנית עצמה היתה רצה בצורה נפרדת? אכן, התבנית לא יכולה להיות עצמאית, אלא רק נפרדת. אולם, פלאג-אין יכול להחשב כשניהם.
הבעיה ממשיכה מעבר לכך, כאשר תבניות ותוספים לא מופצים עם וורדפרס, אלא בצורה נפרדת ולכן לא נדרשים לציית לכללי הGPL; חירות 1 (כמו גם השימוש ההוגן) מקנה לי את החירות לשנות את התוכנה על השרת שלי לשימושי האישי; אני לא צריך לדאוג כל עוד אני לא מפיץ את התוכנה. במידה ואחליט להפיץ את וורדפרס עם תוספים (או תבניות) מותקנות מראש, אז אדרש לרשותם של המפתחים המקוריים.
הפרשנות של וורדפרס וג'ומלה לGPL מגביל שימוש בתוכנה שאינה מורשית תחת GPL ומגבילה את השימוש בתוכנה חופשית, ההגבלה עשויה עוד לפגוע בתחרות החופשית ובמשתמשים מעבר לכוונתם על שימוש בקוד.
אתה צודק שזה מגביל במידה מסויימת אבל אחת הסיבות של ג'ומלה לבצע את הדרישה לGPL היא פשוט כי אין להם זמן להתחיל לבדוק רשיונות –
making the JED a GPL only resource is the easiest and most practical solution. It frees the JED team from having to investigate or worry about licensing issues.
בנוסף, למיטב ידעתי אין שום בעיה לשחרר פרויקט תחת שני רשיונות, במקרה של פיירסטאטס זה יהיה bsd/gpl
astupidog,
קודם כל, ג'ומלה לא צריכים לבדוק רשיונות; המשתמש מתקין על המערכת שלו את התוסף והוא אחראי על השימוש, הוא לא יכול להפוך משהו לGPL בכל מקרה.
לגבי פיירסטאטס, הם לא משוחררים בBSD אלא ברשיון קנייני; עמרי לא רוצה את זה בקוד פתוח, ואני מבין אותו.
ומה תגיד על הלינוקס קרנל?
הלינוקס קרנל משוחרר תחת רשיון GPL.
באופן ברור, הרחבות ותוספות שנכתובת בתוך קוד הקרנל עצמו צריכות להיות משוחררות תחת רשיון GPL גם הם, ולגבי זה כמעט ואין בעיה.
הבעיה האקוטית היא לגבי LKM או דרייברים בלשון העם. שהשאלה היא האם הם יצירה נזגרת או לא עדין לא נפתרה (למעשה עדין לא נבדקה באופן מעשי).
אם יום אחד יקום מישהו (נניח שופט כלשהו) ויחליט שכל LKM הוא יצירה נגזרת ע"פ GPL, הרבה מאוד אנשים עשויים למצוא עצמם בבעיה גדולה מאוד (כולל האנשים שעומדים מאחורי ה GPL עצמו).
דן,
הקרנל הוא יצירה אחת. הרחבות שמשוחררות אינן יצירות נגזרות אם אני מתקין אותן לבד. אני מסכים איתך שהקרנל עצמו חייב להיות רק עם רכיבי GPL; אבל כאשר אנחנו מחוץ לקרנל, מדברים על מודולים קנייניים, אין בעיה לשלב אותם עם הקרנל. העובדה שnVidia כתבו דרייברים לxorg לא הופך אותם לGPL.
בשביל שיקום שופט צריך מישהו שיביא את זה לבית משפט, זה כמעט קרה כמה פעמים, אבל תמיד זה נסגר מחוץ לבית המשפט (וכל מקרה מסיבותיו ומתוך העדפה לגמור את העניין מהר ועם פתרון צודק).
אני קצת סוטה מנושא הדיון, אבל מתי יצירה מפסיקה להיות יצירה נגזרת ומתחילה לעמוד בפני עצמה?
לצורך הדוגמא, אני מתחיל לעבוד מתבנית וורדפרס קיימת (ולו רק ע"מ לא לעמוד מול דף ריק) ומתחיל לשנות כל קובץ וקובץ, כולל PHP כולל תמונות ובעיקר CSS.
מתי התבנית שיצרתי מפסיקה להיות יצירה נגזרת? אחוזי זהות?
אילן,
כעקרון זו השאלה שמנחה את האמנות והGPL מראשית ימיה. כעקרון, הדרישה בGPL היא Separate and Independent ואני מוכן ללכת על זה. אבל תחשוב על שקף שמצויר עליו שפם וקרניים. השקף עצמו הוא לא יצירה נגזרת אלא יצירה בפני עצמה, אתה יכול להסתכל עליה תמיד, אבל אם תניח את השקף על תמונה, נניח של אביגדור ליברמן, היא תצור את אותה הדמות בצורה דמונית. האם אז זו יצירה נגזרת? החוק לא בהכרח מתייחס לזה.
דנבי:
"באופן ברור, הרחבות ותוספות שנכתובת בתוך קוד הקרנל עצמו צריכות להיות משוחררות תחת רשיון GPL גם הם, ולגבי זה כמעט ואין בעיה".
לא ברור בכלל, קח למשל את ZFS:
זה פרוייקט עם זכות קיום בפני עצמו, ולא יצירה נגזרת של לינוקס בשום צורה.
התפיסה הזו שכל הרחבה של לינוקס צריכה להיות תחת GPL מונעת ממני כמשתמש להשתמש בלינוקס וZFS ביחד. זו למשל הסיבה שאני הולך להתקין אופן-סולאריס היום.
אני אישית לא רואה שום מניעה לכך שיהיה מודול ברשיון לא תואם GPL, שבסך הכל לא יהיה מופץ עם לינוקס.
אני ילד גדול, אם אני מתקין משהו אני מסכים לתנאי הרשיון. אני לא צריך שוטרים עם קרניים של גנו שיגנו עלי מפני העולם העויין.
יהונתן, יש לך בעיית עימוד עם הקוד. תוסיף לו עימוד שמאלה, אי אפשר לקרוא אותו.
תודה, תוקן.
חבל שהם עושים דבר כזה, אני לא מבין מה זה נותן להם. נראה שהחופשיות של התוכנה עלתה להם לראש כל כך שהם התחילו לפגוע בה בלי לשים לב, חחח.
בכל מקרה, לא צריך להופיע ברשימות של וורדפרס בשביל לשחרר תוסף, ואם הוא גם מסחרי ונמכר אז יש לו גם תקציב פרסום שיחליף את הצורך להופיע ברשימת התוספים הרשמית של וורדפרס.
בנימין,
ברור שלא צריך להיות ברשימות שלהם, אבל הופעה ברשימות יוצרת פופולריות, והיא שירות. בעצם יש כאן אפליה במתן שירות על סמך מאפיינים שאינם קשורים לתוכנה.
אז אם למשל, לקחתי תבנית קיימת של וורדפרס שמותרת להפצה תחת GPL
ותרגמתי והתאמתי אותה לעברית, והוספתי לה למטה רישיון cc-by, זה בסדר או לא, או שאין לי בכלל צורך להוסיף את הcc-by?
מה שאני מעוניין זה שאם מישהו יבחר להשתמש בתבנית, אז שישאיר את הקרדיט שלי שם למטה בצד על התרגום וההסבה. אגב, מבחינת יוצר התבנית הוא לא מחייב להשאיר את הקרדיט שלו שם.
אפשר לראות את התבנית כאן –
http://bit.ly/qSegx
תודה
הערונת קטנה – השעון אצלך מראה שעת פרסום אחת אחורה מהשעה שבה פורסמה התגובה..
אולי אפשר ככה להרוויח עוד שעה ביום? :-)
מאור,
השאלה שלך דורשת חוות דעת משפטית מפורטת שהייתי מעדיף שדלא לתת בבלוג. כעקרון, התשובה היא "לא": אי אפשר לדרוש קרדיט על התרגום אם היצירה היא בקוד מחשב (כיוון שהחוק הישראלי לא מכיר בקרדיט על קוד תוכנה).
אלא שיש בכך עניינים ארוכים ומפורטים אחרים.
אם תרצה חוות דעת מפורטת (בתשלום) אני אשמח לתת לך אחת.
יהונתן,
תודה על התשובה.
אם כך, הדבר הכי פשוט שאני יכול לעשות בינתיים (בלי להיכנס לחוות דעת משפטיות מפורטות, או מאידך להסתבכויות מיותרות) הוא פשוט לוותר בינתיים הוספת ה- cc-by וזהו?
לא.
מדוע לא? הרי תבניות הוורדפרס מופצות באופן חופשי ומתרגמי התבניות בארץ כולם, ככל הידוע לי, פועלים באופן הזה של תרגום התבניות ושחרורן לציבור.
מהי אם כך הבעיה? האם יש איסור על תרגום התבניות והפצתן באופן חופשי כפי שעושים למשל אח"י דקר, ארז וולף (we-cms), מאסטר-גייט ואחרים?
אין איסור על הפצה, יש בעיה בשאלה שלך. אסור לך להפר את הGPL בו משוחררת התבנית, לכן, מה שאתה הצעת הוא לא הפתרון הפשוט ביותר, אלא לעמוד בתנאי הרשיון.
מאור, אתה לא יכול לעשות שינויים ברשיון של קבצים שלא שינית וגם אם השינויי אינו מהותי סביר להניח שאין לך זכות לשנות את הרישיון.
אבל אם לעומת זאת יצרת קובץ CSS חדש סביר להניח שאתה יכול להפיץ אותו תחת רשיון שונה מזה של התבנית.
ואם אתה מתכוון לcc-by בפוטר, אז לפחות הצורה שאני מבין אותו הוא שהוא מתיחס לתכנין של הבלוג ולא לתבנית.
אבל הנקודה החשובה מכל היא מה בדיוק אתה מתכוון אם מישהו יפר את הרשיון שלך? האם אתה מתכוון כל יום לעבור על כל האתרים בעברית ולבדוק שאף אחד לא לקח את התבנית ומחק ממנה את הקרדיט שלך? ונניח שתמצא אחד כזה האם תפנה ליהונתן ותבקש ממנו לתבוע את אותו אדם? אתה יודע מה סכום הפיצויים שאתה זכאי לו על גנבת עבודה שאתה מוסר לכל אחד בחינם מצד אחד, ומצד שני עלות שעת העבודה של יהונתן, וכמה זמן אתה באופן אישי תצטרף לבזבז על זה?
אנשים טובים ממילא ישמרו על הקרדיט שלך בלי קשר לרישיון ואנשים רעים יטענו שהם תרגמו את התבנית בעצמם, אז האם אתה באמת חושב שקרדיט בתבנית יצדיק את הזמן והכסף שיעלה לך לשחק בשוטרים ועורכי דין מולם?
נסתכל על כמה דוגמאות נוספות. עמרי ירצה להוסיף את את החבילה שלו למאגר החבילות של הפצת דביאן. הוא ייתקל בסירוב מנומס. הנימוק: "לא תואם לחוזה החברתי של דביאן".
http://www.debian.org/social_contract
כשדביאן נוסדה, הגישה שלה לגבי תוכנה קניינית היתה גישה קיצונית למדי. גישה של כל מיני סטולמנים. כיום הגישה הזו היא הגישה השלטת אצל הפצות הלינוקס הראשיות. בחלקן תוכנה קניינית אסורה. בחלקן היא איכשהו נסבלת. הסיבה היא סיבה מעשית: תוכנה קניינית יוצרת בעיות באריזה. כמוכן אם ההפצה תעודד יצירת תוכנה חופשית, למשתמשיה יהיה יותר נוח לעבוד בעתיד.
בהכנסך לפרשנות משפטית אתה תוקף איש קש. בשני המקרים הוצהר במפורש שהסיבות אינן סיבות משפטיות (ליתר דיוק: במקרה של וורדפרס השינוי נגרם כתוצאה מסיבה משפטית, אבל הוא מעבר למה שנדרש ממנה). לכן מיותר לנסות לתקוף אותו בנימוקים משפטיים. מה שחשוב כאן הוא מה שטוב למשתמשים. אם תוכנה חופשית מפותחת בניגוד לדעת משתמשיה, הם יכולים (במקרה הגרוע) לפצל את הפיתוח. מפתחי Joomla מודעים היטב לאפשרות הזו.
לכן אם זה באמת מפריע למשתמשים, תראה בקרוב מאגרים חלופיים שכוללים תוספות שלא יכולות להכנס למאגרים הרשמיים.
עמרי, ZFS היא חלק מ־OpenSolaris. היא ברשיון שתוכנן בכוונה להיות חופשי ולא תואם ל־GPL. כלומר: מי ששחרר את הקוד מאוד לא רצה ש־ZFS יהיה חלק מלינוקס ואף יצר לשם־כך מכשולים משפטיים.
נחמד לראות שאתה מזלזל ברשיונות שימוש. אבל אם זה כך, בוודאי לא תתנגד לכך שאקח את FireStats ואשנה את רשיונו ל־GPL.
מרק,
ברור שאין לי כל כוונה להתחיל לחפש אתרים שעשו שימוש בתבנית לבלוג שלהם, יש לי כמובן דברים יותר מעניינים לעשות עם הזמן ולשחק בשוטרים ועורכי דין על תבניות זה ממש לא אחד מהם.
כמובן שאני לא רוצה ולא מתיימר לעשות שינוי ברישיון של קבצים שלא שיניתי, (אבל בכל מקרה בתרגום תבנית אתה מבצע שינויים בתוך רוב הקבצים, אם לא בכולם) המחשבה הראשונית היתה על רישיון לתרגום עצמו לצורך קרדיט, אבל אתה צודק במה שאתה כותב – אנשים טובים ממילא ישמרו על הקרדיט בלי קשר לרישיון, ואלה שלא – לא שווים את ההתעסקות עם זה עבור העניין הנידון.
יהונתן,
ודאי שאסור לי להפר את הGPL בו משוחררת התבנית, אין לי גם שום עניין להפר אותו. אבל אם אני לא מוסיף cc-by ופשוט משחרר תבנית כפי שהיא רק מתורגמת ומותאמת לשפה (עם הקרדיט למקור, למרות שהיוצר במקרה הספציפי הזה כותב שהוא לא מחייב זאת), האם גם אז לא עמדתי בתנאי הרישיון?
בקשר להערה שלך על ה־aGPL: הביקורת עליו מתמקדת בכך שהוא פוגע באותה חירות ראשונה.
כשאתה לוקח יצירה קיימת ומוסיף שינויים, יש לך זכויות יוצרים על היצירה החדשה. אולם היצירה הזו נוצרה מיצירה קודמת. בצורה מאוד פשטנית אפשר לחשוב על זה כאילו יש לך זכויות על השינויים מהיצירה הקודמת. אני לא רוצה כרגע להכנס למלוא המשמעות.
בכל מקרה, הדבר הכי פשוט לעשות הוא לא לשנות את רשיון השימוש. אם אין לך סיבה טובה מאוד לשנות את הרשיון, אל תשנה אותו. אתה מסבך את החיים למי שירצו למזג בעתיד את שינוייך. אתה עלול לחשוף כל מיני בעיות משפטיות שלא צפית מראש.
התבנית ברשיון GPL? אם אין לך סיבה טובה מאוד, תשאיר גם את התרגום ברשיון GPL. (ואותו הדבר אמור לכל רשיון סביר אחר).
קיבלתי צפריר, בסופו של עניין זהו אכן הקומון סנס.
תודה.
צפריר,
אני קורא שוב את מה שכתבתי ולא מצליח להבין איך הסקת שאני מזלזל ברשיונות שימוש.
לגבי לשנות את הרשיון של משהו שלא יצרת, אתה באמת רוצה תגובה רצינית? :)
מאור, יש תבניות שבנויות מראש לתרגום בעזרת כלי תרגום, בפעם הבאה תשתדל לתרגם תבנית כזו, זה הרבה יותר נח ….
עמרי, מי שמפריע לך להשתמש ב־ZFS בלינוקס היא בעיקר המחברים המקוריים שלה. הם השתמשו ברשיון שיוצר בעיה חוקית.
כדי להבין למה יש כאן בעיה, תחשוב על בעיה דומה:
כתבתי תוכנית ברשיון CDDL (כמו זה של ZFS) ואני רוצה להשתמש בספריית Readline (שמשתמשת ברשיון GPL). למה יש כאן בעיה אם התוכנית שלי לא השתמשה בכלל בקוד של Readline?
(רמז: את הבעיה של ה־headers של readline שאתה מכליל בתוך התוכנית אפשר לעקוף בקלות ע"י כתיבתן מחדש או הצהרה שמדובר על ממשק פומבי עם מימוש אחר. אני לא מדבר על זה)
צפריר,
רשיונות צריכים לטפל בהפצה ולא בשימוש. אם אני רוצה להשתמש בZFS והיא יודעת להשתמש בקרנל של לינוקס, שום דבר ברשיון לא אמור למנוע ממני להיות מסוגל להשתמש בתוכנה מג'ופלת.
להבדיל, אם אני רוצה להפיץ חבילת תוכנה אחת, עצם ההפצה שלה כיחידה אחת ומזוהה ככזו היא הבעיה.
אני גם לא מבין למה להכריח את עמרי לשחרר את התוכנה שלו ברשיון ספציפי, היא תוכנה שלו והיא די בטוח יצירה עצמאית שלא תלוי בדברים אחרים.
וכן, הaGPL הוא רשיון בעייתי, אבל דה-פקטו, זה מה שוורדפרס עושים.
עמרי לא חייב להשתמש ברשיון זה או אחר. אם הוא רוצה שחבילתו תיכנס למאגר מסויים, הוא צריך לעמוד בתנאיו של אותו מאגר. דביאן עושים את זה כבר יותר מ־15 שנים.
כל דצריך יכול להקים מאגר חלופי. אם אין מאגר חלופי כזה (במקרה של Joomla חלפה כבר יותר מחצי שנה מאז ההכרזה המקורית) זה רומז שהמשתמשים באופן כללי מרוצים.
אם אתה חושב שאין בעיה עם ZFS, אז כנראה שאין בעיה גם עם תוכנית ה־CDDL מהדוגמה שלי. באמת אין בעיה?
אני חוזר לבעיה שנוצרת עם LKM.
הבעיה היא לא האם LKM הוא חלק מהקרנל או לא. קיימת הסכמה כמעט גורפת לגבי זה ש LKM הוא חלק נפרד מהקרנל ולא חייב להיות מופץ תחת GPL.
הבעיה היא שה API שמייצא הקרנל חלקו מיוצא תחת רשיון GPL וחלקו לא.
השימוש ב API שמייוצא תחת רשיון GPL מחייב את ה LKM שמייבא אותו להיות מופץ תחת רשיון GPL, אחרת זה מאוד בעייתי להשתמש בו.
הבעיה נהיית חמורה עקב אי השמירה על תאימות לאחור בלינוקס קרנל.
API שקיים בגירסה אחת של הקרנל שאינו מייוצא תחת רשיון GPL עשוי להיות מוחלף מאוד בקלות ע"י API שייוצא כן תחת רשיון GPL.
אני כמפתח של קוד נפרד ללינוקס קרנל, נתקל פתאום בבעיה. דברים שיכולתי לעשות בגירסה א' תחת רשיון כלשהו, אני יכול לעשות בגירסה ב' רק תחת רשיון GPL.
ואם זו לא בעיה, אז מה כן?
בינתיים נשמר איזון כלשהו, מעין מלחמה קרה בין הרשיונות השונים. אבל זה לא בלתי נמנע שיבוא יום והקרנל ייצא API רק תחת רשיון GPL, ומה ניתן יהיה לעשות אז? לפרסם את הקוד? לסגור הבסטה?
דנבי,
אם אני מדבר עם הAPI של טוויטר אני לא יוצר יצירה נגזרת שלו, כך גם עם כל מודלים שמתחברים לקרנל.
צפריר,
שימוש בREADLINE אומר שהתוכנית שלך "תדבק" (מצטער, אני לא מצליח לחשוב על מינוח פחות מעליב) בGPL, ולכן כנראה תמנע מלעשות את זה (בדיוק כמו שאני נמנעתי מלהשתמש בקוד ברשיון GPL כשפיתחתי את פיירסטטס).
אני לא חושב שהמרה של ZFS ללינוקס יצטרך להשתמש ביותר מאשר משאבים רגילים שזמינים לכל תוכנית אחרת שרצה במערכת.
אם אתה טוען ששימוש במשאבי מערכת ההפעלה לינוקס מדביק כל תוכנית בGPL אז יש בעיה רצינית לחצי מהעולם.
לגבי שאלתך למה אין לי בעיה עם דביאן:
ככל שידוע לי, זו היתה המדיניות של דביאן מאז ומעולם.
חוץ מזה, יש להם גם את מאגר NON-FREE ואת מאגר CONTRIB, שמראים שאיכפת להם מהמשתמשים שלהם.
בנוסף, אם נורא בא לי אני יכול ליצור DEB משלי, לשים אותו במאגר משלי ולתת לינק למשתמשי דביאן, ומאותו רגע הם לא צריכים לחשוב על זה שהחבילה שלי מיוחדת.
אם וורדפרס יאפשרו לגורמי צד שלישי ליצור מאגר שיאפשר לפלאגינים שלא תחת שליטת וורדפרס לקבל את אותם שרותים אז היה מקום להשוואה.
במקרה של ג'ומלה הם (עדיין) לא נותנים שרותים ולכן ההפסד הגדול שלי הוא שהחשיפה שלי למשתמשי ג'ומלה נפגעה.
צפריר, שיהיה ברור :
אני כן בא בטענות אל סאן על הרשיון שהם בחרו, וברור לי למה הם עשו את זה.
אין לי בעיה שמפתחי לינוקס לא מוכנים להמיר את ZFS ללינוקס כי זה נוגד את אמונתם.
מה שמפריע לי זה שיש איזו תפיסה מוזרה – שאיתה אני לא מסכים – שאסור לפתח מודול ZFS ללינוקס.
אסור להפיץ מודול ZFS עם לינוקס, זה כן, אבל לפתח?
שהמשתמש יחליט אם הרשיון נראה לו, ואם כן – שיתקין.
אני רוצה לראות את הFSF תובעים את NVIDIA על הדריברים הקנייניים שלהם.
זה יהיה מעניין, ובטוח יעזור נורא ללינוקס.
לגבי תוכנית שרצה מחוץ לקרנל החוקים שונים. הרשיון של לינוקס מתיר במפורש לכל תוכנית משתמש רגילות שמדברות עם הקרנל בעזרת קריאות מערכת:
http://lxr.linux.no/linux/COPYING
דוגמה לתוכנית כזו:
http://www.wizy.org/wiki/ZFS_on_FUSE
מה מפריע לך לשים את החבילה שלך במאגר משלך? מה מפריע לך (או למישהו אחר, שעובד קצת יותר עם Joomla) להקים JED חלופי? זה בדיוק מה ששאלתי. יכול להיות שזה הפסד שלהם. עדיין מעניין למה במשך חצי שנה עדיין לא קם מי שיציע שירותים כאילו.
כמוכן יש לציין שה־FSF לא יכולים לתבוע את nVidia: הם אינם בעלי זכויות היוצרים של החלקים הרלוונטיים בקרנל.
מודול קרנל רץ בתוך מרחב הזכרון של הקרנל, נטען ע"י הקוד של הקרנל וקורא לפונקציות אחרות מתוך הקרנל. לכן יש כאן מצב דומה לשימוש בספריה.
הטענה הנגדית שמושמעת היא שמודולים שמשתמשים רק בממשקים "סטנדרטיים" ולכן המצב דומה לתוכניות userspace. הטענה הזו שנויה במחלוקת במקרה הטוב (תאור יותר מתאים הוא כנראה "נשענת על כרעי תרנגולת") אבל ללינוס כנראה המצב האפור הזה נוח.
כדי להקטין את התחום האפור הזה לגודל יותר סביר הקרנל מגדיר ממשקים מסויימים כ־GPL-only . המשמעות היא שזהו ממשק פנימי. אם מודול משתמש בממשק כזה, הוא משתמש ב"ממשקים פנימיים" של הספריה. זה מראה מעל לכל ספק שמדובר על מודול שרשיונו חייב להיות תואם ל־GPL.
הדרייבר של nVidia לא משתמש בממשקים פנימיים. כל מערכת קבצים (ובפרט: ZFS, שהיא הרבה יותר מסתם מערכת קבצים) חייבת להשתמש בממשקים פנימיים כאילו.
דנבי: מבחינת מפתחי הקרנל של לינוקס, מודולים חיצוניים (גם לא קניניים) הם דבר נסבל אך לא ממש מועדף. הם מעדיפים לתחזק את כל הדרייברים אצלם בעץ, ובינתיים עושים עבודה טובה מאוד (וגם הצליחו לבזר את עבודת התחזוקה בצורה מרשימה למדי).
באופן כללי הם די קיצוניים יחסית לפרוייקטים אחרים בגישה הזו. יכול להיות שגם בגלל שבאגים שנגרמים בגלל קוד קרנל גרוע יותר מסובכים לדיבוג מבאגים שנגרמים בגלל קוד PHP גרוע.
Ilan, המונח "עבודה נגזרת" לא הומצא ע"י רשיון ה־GPL (או ע"י רשיון CC-BY-SA). הוא מונח שמוגדר (בצורה עמומה למדי) בחוק זכויות היוצרים ומוגדר קצת יותר טוב בכל מיני תקדימים משפטיים. קשה לתת תשובה טובה לשאלה הזו ובאופן כללי רצוי להמנע מהמצב הזה :-( .
(לכאורה אפשר לטעון שגם לאחר ששינית כל פרט ופרט נשאר משהו מרוח המקור. במקרים מסויימים זה יוכל להיות אפילו נכון. לדוגמה: במקרה של תרגום.)
ואם זה לא ברור: אני לא עו"ד.
ולמען הסר ספק: גם אם זה כן ברור: אני לא עו"ד.
בתור "משתמש" כבד בג'ומלה, לא יזיק שאתן גם אני את התייחסותי (טיפה ארוך).
אם זכרוני אינו מטעה אותי, לפני כשנה+ היה דיון בג'ומלה העולמי בשאלה המשפטית האם רכיבים/מודולים/תוספים (הרחבות…או איך שתקראו לזה…) עבור ג'ומלה אינם בגדר תוכנה עצמאית אלא תוכנה נגזרת ולכן הם חייבים להיות GPL.
לא זכור לי שהיתה החלטה בענין, אך הטענה כמו של יונתן שאמר כי שימוש בפקודות PHP אינו מדביק את התוכנה ברישיון של Php, הייתה אחת הטענות החזקות מדוע אין מדובר ביצירה נגזרת.
בעקבות הדיון האמור החלו מפתחים לפתח הרחבות לג'ומלה אשר אומנם מותקנות דרך פנאל הניהול של ג'ומלה, אך מדברות באופן ישיר מול מסד הנתונים ומבצעות שאילתות רבות ומגוונות לצורך תפקוד התוכנה, שאילתות שהיו נחסכות אילו היו משתמשים בפונקציות המובנות של ג'ומלה.
מה שקרה החודש עם JED (ספריית ההרחבות לג'ומלה…שהייתה לפני חודש עם למעלה מ4000 הרחבות), זה לא ענין משפטי.
למיטב ידיעתי, ג'ומלה (ואילו שעומדים מאחוריה..open source matter) לא טוענת כי הרחבות שמופתחות עבור ג'ומלה צריכות להיות GPL כי הן פשוט "נדבקות" מג'ומלה.
הסיפור עם JED הוא ענין אידאולוגי נטו – ערכי קהילה.
ג'ומלה פשוט לא רוצה לעודד פיתוח תוכנות עם רישיון שאינו חופשי.
אף אחד מג'ומלה לא מתיימר לתבוע מפתחיי הרחבות שיפיצו/ימכרו הרחבות בקוד סגור – פשוט לא יתנו להם בימה באתר ג'ומלה העולמי. זה הכל.
אני לא רואה בעיתיות מבחינה משפטית.
במילים אחרות, אפשר להפיץ הרחבות לג'ומלה בקוד שאינו GPL, רק פשוט שהוא לא יזכה לחשיפה באתר הראשי של ג'ומלה…כמו שגם הרחבה בGPL שלא עומדת בכללים אחרים (כגון תמיכה, שם מקורי וכדומה), לא תפורסם.
ודרך אגב יש כבר אתר עבור הרחבות שאינן GPL:
http://www.cmsextensions.org/
ועוד דבר, ג'ומלה מוכנים לפרסם תבניות גרפיות שאינן GPL…כי לדעתם זה מקרה מיוחד, אם כי מבחינת הקוד זה בדיוק אותו דבר כמו מערכת טפסים שכן כפופה לכללים החדשים של JED.