בתשובה לצפריר כהן, 25/12/09 10:54
 |
|
 |
||
|
||||
 |
א. זה נכון שסאן לא רוצה שזה יקרה. אבל אם זה יקרה, במה נראה לך המשתמשים יבחרו, בגרסה שממשיכה להתפתח באופן מאסיבי וסגורה, או בגרסה ההרבה פחות מתקדמת שתהיה פתוחה? אני חושב שרוב המשתמשים ינהרו לגרסא של סאן. ב. (אגב, הספריה נקראת lift). שני הערות: ב1. נכוונה של ההערה שלי היתה להראות שבעולם האמיתי דוחים שימוש בתוכנה חופשית מטעמי רשיון, וזה גרם לו לתת רשיון נוח עם מינימום בעיות משפטיות. אז לומר שלא מעניין את HTC, למשל, באיזה רשיון הפרוייקט, והיא תשתמש בו בעל אופן, זה לא ממש מדוייק. ב2. ניהול גרסאות לא עוזר לך. המפתחים שיש להם commit לפרוייקט לוקחים הרבה פעמים patch-ים מ"who knows where", ואם אין לך מדיניות קשוחה כמו של DPP מהפוסט אתה עלול למצוא את עצמך מחוייב להוכיח שאין לך אחות. הסיבה העיקרית שמערכות משובצות לא השתמשו בNetBSD כמו גם בלינוקס, היא כי שניהן לא מיועדים לreal-time. בלינוקס יש תוספים לליבה שהופכים אותה לאיכשהו realtime, אבל היא לא מיועדת לזה. |
 |
 |
 |
|
|
|
||
|
||||
|
א. כיום משתמשים צריכים לשלם עבור הגרסה של סאן. אפילו מוסדות לימודיים. כמוכן לא ברור לי מאיפה ההנחה שהתוכנה של סאן תתקדם יותר מהר: הם יצטרכו להשקיע בפיתוח יותר מאשר היום כדי לקבל את אותן התוצאות. ויותר משאבים יגיעו למפתחים עצמאיים. בקיצור, לפי כדור הבדולח שלי, הגרסה הקניינית לא תעמוד בתחרות. ב1. רשיון שימוש הוא דבר חשוב. נא לא לזלזל בו. לדחות תוכנה עם רשיון שימוש לא טוב נשמע לי לגיטימי. לדחות מנימוקים מוטעים, זה כבר לא. הנימוקים שהוזכרו שם לא התייחסו לרשיון עצמו (אלא לשאלה האם יש השמת זכויות יוצרים לגוף יחיד) ורובם היו שגויים. מכיוון שלא יכולתי להתערב באותו דיון, לא יכולתי לתקן. ב2. גם בפרוייקטים שדורשים השמת רשיון מפתחים יכולים לקחת Patch מ־Who knows where. את זה צריך למנוע ע"י חינוך המפתחים. כמובן שכלים מתאימים יעזרו. במערכת ניהול הגרסאות git, לדוגמה, בכל שינוי מופיע שם המחבר שלו. הפרטים הללו נשמרים גם כאשר השינוי ממוזג למעלה. כך מחבר יכול לעבוד על העץ הפרטי שלו ולהעביר שינויים (אם ע"י push ישירות ואם ע"י שליחת patch), והפרטים על השינוי ישמרו. השינויים הללו לא נעשו במקרה. השמות מהדוגמה הקודמת רמזו על הסאגה המשפטית המגוכחת של http://en.wikipedia.org/wiki/SCO_Group . אני לא הולך לפרט כאן את כל פרטי המקרה על כל השתלשלויותיו המוזרות. רק אזכיר שמדובר על חברה שטענה שקוד שהיה שייך אליה הגיע ללינוקס. היא גם תבעה את IBM בסכומי עתק והצליחה בכך לנפח את מנייתה. עם כל העובדה שמדובר היה על טענות שהיו ברורות לחלוטין כמגוכחות לכל משקיף מקצועי, הפרשה הזו גרמה לשידוד מערכות בכל ההתייחסות לזכויות יוצרים. כאשר נכתבה מערכת git (אשר תוכננה מראש עבור הקרנל של לינוקס), אחת הדרישות החשובות בה היתה לאפשר זיהוי פשוט של הקוד שמגיע מכל מיני מקומות. נוספו גם אמצעים פשוטים כדי לדווח מאיפה הגיע הקוד ואיזה מסלול הוא עבר. מבחן התוצאה אומר הכל. יש לא מעט פרוייקטים של תוכנה חופשית שמפותחים בצורה מבוזרת ונמצאים בשימוש ע"י גופים עם כסף שאפשר לתבוע. ובכל זאת כמות הסכסוכים והתביעות מהסוג הזה קטנה להפליא. אם התאוריה שלך היתה נכונה, היינו כבר מזמן שומעים שומעים על כל מיני טרולים שמנסים לסחוט בדרך הזו כסף מ־IBM, סאן, רד־האט ונובל (לדוגמה). הראיתי גם לך שרשיונות לא נוחים גורמים לבעיות בחיי היום־יום. בעקבות הנסיון הרב שיש לי עם תוכנה שבה נהוגה השמת זכויות יוצרים (אסטריסק [ויקיפדיה]) אני רואה איך זה פוגע בתהליך הפיתוח. אם אני צריך להחתים מפתח על מספך שמשמעותו היא אישור לחברה אחרת לחטוף את הקוד שלו בעתיד, הוא לא בהכרח יסכים. אני מכיר לא מעט קוד שלא נכנס לאסטריסק מהסיבה השטותית הזו. ג. אין שום קשר הכרחי בין מערכות משובצות לבין דרישות real-time. הנתב המסכן שלי לא מריץ מערכת real-time. טלפון ה־Voip שלי מריץ מערכת לינוקס רגילה ללא "תוספות realtime". וטלפון מתעסק עם קול ולכן הוא מערכת soft-realtime בהגדרה. יש לך הסבר חלופי? |
|
|
|
|
|
|
||
|
||||
|
א. כדור הבדולח שלך לצערי לא מתאים למציאות. רוב הפיתוחים ל-OO מבוצעים בסאן או בחברות קנייניות אחרות. כשחשבתי על לתרום קוד ל-OO העברי, דיברתי עם tksoft, שמשרד האוצר שכר, והם אמרו לי "עזוב, צריך דוקטורט רק בשביל לקמפל את החיה הזו". הקהילה לא נותנת פיתוחים משמעותיים ו-Sun כן. זאת עובדה. אם Sun ממשיכה לבד, רוב הפיתוחים יקרו בגרסא שלה. כנראה שהפיתוח של OO יתעכב (תרגומים וכו') ואז היא תצבור פער עצום יותר מMS. השאלה היא, האם המשתמשים יעדיפו גרסא נחותה וחופשית על גרסא משופרת וקניינית. תסתכל על אחוזי השימוש של MS-office לעומת OO ותגלה את התשובה ללא כדור בדולח. ב1. כל מה שהתכוונתי לומר בדוגמא, זה, שלא משנה כמה אתה צודק, בפועל, מנהלים של חברות מתרחקים מבעיות רישוי. זו המציאות הקשה שצריך להתמודד איתה. זהו. אז אולי כל המנהלים מטומטמים, ורק הפריקים של OSS הם החכמים (ברצינות, בלי ציניות), אבל אם אתה רוצה שחברות גדולות ישתמשו במוצר שלך, אתה חייב לקחת את הטמטום של המנהלים בחשבון. ההודעה שלו הראתה לך שיש מנהלים שבודקים את הרישוי בפועל, ולא משתמשים בתוכנה בגלל הרישוי. לגבי החינוך, נכון מאד. DPP חינך את המפתחים של Lift יפה - לא נוגעים בקוד שמישהו תרם. עכשיו אין בעיות רישוי ל-Lift. ג. צודק. זה לא מסביר את הפופולריות של לינוקס. הסבר אלטרנטיבי שיש לי הוא: ההתמקדות של לינוקס ב-x86 גרם לה לפופולריות. ממש לא נראה לי שיש תכונות טכניות עיקריות שיגרמו להעדפה של זה על זה (אולי היום בגלל הפופולריות של לינוקס, אבל בטח לא אז). |
|
|
|
|
|
|
||
|
||||
|
א. זה היה נכון בעבר. כיום החבילה של OpenOffice.org נבנית בצורה אוטומטית בכל הפצת לינוקס סבירה. זה אמנם דורש מקום מסוים על הדיסק (8GB, אאז"נ), אבל עובד. נראה לי שאנו חלוקים כאן על הנתונים. לכן אאלץ פשוט להגיד "לא נכון ולא נכון!" ב1. תתפלא כמה מנהלים בורים בקשר לבעיות רישוי. אם למנהלים היתה כזו בקיאות בענייני רשיון, לא היתה כמעט אף הפרת רשיון של Busybox: כמעט בכל המקרים הפרת הרשיון הזה היא תוצאה של עצלנות ו/או בורות. חברות חושפות את עצמן לתביעה ללא סיבה טובה במקום פשוט לפרסם את ההצהרה והנתונים הנדרשים. הדוגמה של lift הסבירה יפה למה כדאי להשתמש בתוכנות GNU (יש להם כיסוי תחת מהסוג של השמת זכויות יוצרים) ולא בלינוקס (שם אין). לעומת זאת, הנה כמה חברות עם מנהלים אמיצים שמשתמשים בלינוקס: ג. גם הפיתוח של NetBSD התמקד בפועל בעיקר ב־x86 (כי זו היתה התוכנה הקיימת). כך גם FreeBSD. בקיצור: הסבר לא מספק. לפי הטענה שלך הרשיון של לינוקס נוראי ולכן מנהלים היו אמרים לברוח ממנו. |
|
|
|
|
|
|
||
|
||||
|
א1. אולי קל לבנות את זה, אבל בדוק בבאגזילה של OO כמה באגים נפתרים על ידי מפתחים של Sun, וכמה ע"י מתנדבים מהקהילה. אני אחסוך לך את הבדיקה לגבי באגים הקשורים לעברית. 100% ע"י Sun ושלוחותיה. אף patch מהקהילה. אז במה ישתמשו דוברי העברית, בגרסא של סאן, עם העברית המתוקנת, או בגרסת הקהילה בלי העברית? ב1+ג. השימוש בlinux, משתמש בו כמ"ה. אני לא מכיר הרבה חברות ששינו משמעותית את ה-Kernel, כעסק. הרשימה שהבאת מדברת על חברות שמשתמשות בליבה, בשביל הנתב, ולא תורמות *כחלק מהעסק* לקרנל. הנתב יעבוד אותו דבר עם השינויים שהם תרמו או בלעדיהן. כמובן, בגלל שהכסף שלהם מושקע בלינוקס, הן רוצות שהוא ימשיך להתפתח אז הן תורמות לו בכסף או בקוד. קצת כמו שTI תורמת לeclipse, היא נותנת את eclipse עם הסביבת פיתוח למעבדים שלה. היא רוצה שeclipse תתחזק כי היא משתמשת בה - אז היא תורמת לה קוד ואולי גם כסף. אבל, אני לא מכיר חברות שהליבה היא עיקר המוצר שלה, והיא מתבססת על לינוקס. למשל, חברה שמוציאה ליבה מיוחדת עבור שרתי DB, שנותנת ביצועים הרבה יותר טובים, ומתבססת על לינוקס. אפילו Integrity שמשתמשת בלינוקס כמוצר מדף, ונותנת אותו עם המעבדים שלה, מפתחת בנפרד את vxWorks עם feature-ים מיוחדים ל-realtime ו*לא* מתבססת על לינוקס. תשאל אותי למה? אענה לך בשלוש אותיות באנגלית שמהוות ראשי תיבות של הרשיון של לינוקס. |
|
|
|
|
|
|
||
|
||||
|
א1. מדינת ישראל משלמת שכר עבור חלק מתחזוקת OpenOffice, כולל פתרון באגים בעברית. חלק גדול מהקוד של התמיכה בעברית וערבית נכתב בעזרת IBM ישראל ו־IBM מצריים. ב1+ג. ברור. פיתוח תוכנה הוא תקורה. פיתוח תוכנה ביחד עם חברות אחרות מקטין את התקורה הזו. הגיון כלכלי פשוט. דוגמה לחברה שהשקיעה בקוד GPL היא http://en.wikipedia.org/wiki/Qumranet (היום: מרכז הפיתוח של רד־האט בישראל). היא הצליחה להוציא מוצר עובד כ"כ מהר בין השאר מכיוון שהיא עמדה על כתפי ענקים. התחיל מהלך לנסות לבנות ממשק וירטואליזציה שיתאים ל־Xen. אנשי VMWare רצו שהוא יתאים גם להם. כשהממשק הבשיל, התברר שיותר פשוט לכתוב דבר חדש בעזרתו מאשר להמשיך לשווא לנסות להשתמש במפלצות של Xen ושל VMWare. עוד דוגמה נגדית לטענה שלך: http://en.wikipedia.org/wiki/Xen |
|
|
|
|
|
|
||
|
||||
|
א1. למי היא משלמת? ל-Sun. אם Sun אומרת למדינה שהקוד יהיה סגור, והתוכנה חינם? לדעתי היתה משלמת, ואם לא, אז לא היה OO בעברית. הדוגמא של Xen, לא רלוונטי, פותח מודול נפרד מהקרנל לשימוש בחומרה של IBM. בדיוק כמו שאמרתי. בקשר לQumranet, צריך לבדוק. לא מכיר את החברה. |
|
|
|
|
|
|
||
|
||||
|
א. מדינת ישראל שילמה (ומשלמת) לחברה ישראלית בשם TK Open Sysetms. ב. למה הדוגמה של Xen לא רלוונטית? התוכנה שלהם עובדת על כל חומרת X86 סטנדרטית, למיטב זכרוני. היא כמובן עובדת טוב יותר אם יש תמיכה מצד המעבד בהוראות וירטואליזציה. לאיזה מודול(Xen) בדיוק אתה מתכוון? חיפוש פשוט העלה כמה תוצאות שדומות אבל לא נראות רלוונטיות. |
|
|
|
|
|
|
||
|
||||
|
א. ידוע. אבל הם עובדים בשת"פ עם Sun בנושא, ובכל אופן, אין לקהילה (או ל-tkos) כח להרים כזה פרוייקט בלי Sun. אם תסתכל ב-issuezilla, תראה שהרבה מאד מהבאגים של RTL מתוקנים ע"י מפתחים מגרמניה. ב. כי Xen הוא תוסף לליבה שמיועד לקדם מוצרים של IBM, ולא מוצר שמתבסס על GPL וממשיך לתחזק אותו. מעבר לזה שלIBM יש אינטרס בכללי שלינוקס יצליח בשביל למכור את ה*חומרה* שלהם, לכן הם משקיעים בו. המוצר של IBM הוא לא תוכנה, אלא שרתים והם רוצים וירטואליזציה בשביל שיקנו יותר שרתים. יותר זול להם לפתח את Xen ולינוקס מלפרסם. |
|
|
|
|
|
|
||
|
||||
|
א. הם עובדים בשיתוף פעולה עם סאן מכיוון שסאן משתפים פעולה. לגבי הטענה שאי־אפשר להרים פרוייקט כזה ללא סאן: טענה מוזרה. יש את פרוייקט KDE שקם ללא עזרתה האדיבה של סאן. יש את הקרנל של לינוקס שקם ללא עזרתה האדיבה של סאן. לתת דוגמה לעוד פרוייקטים? ב. על מה מדובר כאן בדיוק? אנחנו מדברים על החברה שנמכרה ל־Citrix? אבל הנקודה המהותית כאן היא: מי שרוצה להצליח בתחום של הוירטואליזציה צריך לדעת להשתמש בכוח המחקר של IBM. ולכן עדיף לו להשתמש בטכנולוגיה ברשיון GPL כדי שהמתחרים ידעו שאין כאן בעיה. דוגמאות: http://en.wikipedia.org/wiki/OpenVZ (היה פעם קנייני) והשניים שכבר הזכרתי: לרוב המפתחים בעולם הליבה היא משהו ש"יותר זול להם לפתח" ברשיון חופשי. רשיון ה־GPL נותן את הביטוח הבסיסי מכך שמתחרה יגנוב את המוצר ויוריד לכיסו הפרטי את העבודה שאני השקעתי בפיתוח התוכנה. בגלל זה ה־GPL עובד. |
|
|
|
|
|
|
||
|
||||
|
א. לא אמרתי שא"א להרים פרוייקט כזה, למרות שייתכן שזה נכון. אמרתי שבמצב הנוכחי א"א לתחזק את OO בלי Sun. תן דוגמא לכמות של פאטצ'ים לOO שנכתבו בלי Sun, או לfeature משמעותי. בעברית - אין. ב. כל מי שמנית לא מוכר תוכנה, אלא מוכר חומרה ומשקיע בתשתית התוכנה בשביל שיקנו יותר חומרה. כמו ששטראוס עושה קמפיין לקידום המודעות לצריכת סידן. התוכנה Citrix עצמה איננה Open Source. |
|
|
|
|
|
|
||
|
||||
|
א. http://en.wikipedia.org/wiki/Go-oo הפיתוח של העברית מתנהל במקרה ישירות מול אנשי סאן בגרמניה (חברת StarDivision לשעבר). זה עובד ולכן אין טעם לשבור את זה. אם לא היתה ברירההיו מפתחים ישירות מול go-oo. ליתר דיוק, הפצות לינוקס התבססו מאז ומתמיד על go-oo (בשמו הקודם: ooo-build) פשוט מפני שלעבוד ישירות מול סאן לא היה נוח. רוב התכונות של התמיכה בלינוקס (לדוגמה: אינטגרציה בשולחנות עבודה, תמיכה במערכת הגופנים - זו שבסאן לא אהבו, תמיכה במערכת ההדפסה) נכנסו משם. שלא לדבר על האפשרות הפשוטה לבנות את התוכנה ללא צורך בקורס מיוחד. ב. רד־האט, נובל ומונטה־ויסטה מוכרות תוכנה (או ליתר דיוק - שרותי תמיכה בתוכנה). חברת WindRiver, המפתחת של VxWorks, אשר השמיצה בעבר קשור את לינוקס, הצטרפה גם היא לשוק הזה. רוב התוכנה נכתבת כחלק מתשתית. התוכנה שנמכרת בפועל היא חלק קטן. כמובן שאותה מפרסמים יותר כי אותה צריכים למכור. |
|
|
|
|
|
|
||
|
||||
|
קנייתה של סאן ע"י אורקל אושרה סופית. אבל אורקל ממאנת להפסיק את פיתוח OpenOffice.org ולכן חסרה לנו דוגמה. אני חושב שזו חוצפה מצידה של אורקל. כדי לכפר על־כך היא החליטה לסגור כמה פרוייקטים מעניינים אחרים של סאן. אחד מהם הוא פרוייקט OpenSSI. הוא מבוסס על קוד שסאן שיחררה בשנת 2008 - הרבה אחרי OpenOffice. מסתבר שיש מי שרוצה להמשיך לפתח את הפרוייקט ומוכן להשקיע בכך: בינתיים, חבורת המשוגעים שהוציאה את ה־Neo FreeRunner (ואח"כ גם את ה־Wikipedia Reader) החליטה כנראה להמציא מחדש את המונח 100$ Laptop. התוצאה: ובמקביל, ב"גולם במעגל"[*] החליטו לנסות להבטיח קצת יותר פרטיות: [*] לא בדיוק, אבל דומה. |
|
|
|
|
|
|
||
|
||||
|
ג. לי נראה שהתשובה היא שלוש אותיות אחרות: תו"ב: ר"ת של תופסן־ביצים. INTEGRITY היא מוצר של חברת Green Hills: החברה הזו מתמחה בפיתוח מערכות קטנות מאוד, סגורות מאוד ואמינות מאוד. באותה מידה שהם לא מתבססים על לינוקס, על http://en.wikipedia.org/wiki/QNX או http://en.wikipedia.org/wiki/VxWorks או אפילו על http://en.wikipedia.org/wiki/Contiki הם כותבים הכל בעצמם. זה מאפשר להם להבטיח כל מיני דברים על התוכנה. כמובן שהמחיר בזמן פיתוח ובכיסוי תכונות גדול בהרבה. זו אולי תוכנה שתרצה לשים במחשב שיפקח על המטוס, אבל לא במחשב של יחידת הבידור של מושב המטוס. הדרך שלהם לממן את זה היא ע"י התו"ב האמור. חלק בלתי־נפרד מהמוצר הוא אותו תופסן שנצמד לחלק רגיש מהלקוח ולא מאפשר לך להפרד מהמוכר. רוצה להוסיף תמיכה בחומרה חדשה? אין בעיה, שלם לנו. רוצה לתקן את הבאג המרגיז הזה? הוא לא מספיק מרגיז, תחזור שוב עוד שנה. רוצה לתקן אותו בעצמך? זבש"ך. הרבה לקוחות הסיקו מסקנות והבינו שהם לא רוצים להיות תלויים כל־כך בספקי התוכנה שלהם. הם מעדיפים להשקיע ישירות כסף בפיתוח אם נדרש פיתוח. או לחילופין לשכור חברה אחרת שתעשה את זה. התוצאה היא התפתחות שוק של ספקי תמיכה, שהמעבר ביניהם זול יחסית. לי בתור צרכן די ברור מה אני מעדיף. |
|
|
|
|
|
|
||
|
||||
|
ה"תלות" שאתה מתאר הוא מהותה של תוכנה קניינית. וזה פחות טוב ללקוח מבחינות מסוימות. כי מצד שני, Integrity בשביל לשמור על הלקוחות שלה מרוצים תסכים לתקן bug קטן בשביל לקוח קטן, אפילו שהוא לא משלם לה את מלוא מחיר הפיתוח, כי הם רוצים מוניטין טובים, ומה שהם מפסידים עליך הם מקבלים ממקום אחר. הרבה פעמים הם יעשו שינויים שלך אין את היכולת לעשות, גם אם היה לך את הקוד של Integrity. אבל, לך נסה לבקש מ-IBM לתקן bug מסויים ב-eclipse, שלא כ"כ מעניין אותם עכשיו. אם זה פשוט - אתה יכול לתקן בעצמך. אם זה קצת יותר מדי מסובף זה ממש זבש"ך. ואין לך אפילו עם מי לדבר, כי זו הרי תכנה חופשית, תגיד תודה ל-IBM שהם שחררו את Webspehre בכלל. אבל זו בדיוק הנקודה שלי, הרבה חברות לא מוכנות להשתמש במוצר שלא מאפשר להם מודל מכירות קנייני. ואם אתה לא מאפשר את זה, הרבה חברות פשוט לא ישתמשו במוצר שלך, וחבל. לכן למשל, ספריות Javascript הן תמיד תחת MIT, ולא GPL, כי הן מאד רוצות שישתמשו בהן (יש תחרות עזה) ואף אחד לא יסתכל לכיוונך אם אתה משפיע לי על המודל מכירות. אתה קורא לזה תופסן, החברות קוראות לזה ביזנס. |
|
|
|
|
|
|
||
|
||||
|
ולכן לי אישית חשוב להשקיע בתוכנות שהן copyleft כדי למנוע מתוכנות קנייניות את האפשרות לחטוף הצידה קוד ובכך לגרום לעבודה שהשקעתי להיות מבוזבזת. הם קוראים לזה ביזנס? שיסבלו. |
|
|
|
|
|
|
||
|
||||
|
אז אתה גם לא תורם קוד לתוכנות ברשיון GPL שיש לכל הקוד בעלות אחת, שם גם אפשר לחטוף את הקוד בקלות דומה? קל וחומר שלא תיגע בתוכנות כמו MySQL וQt שאפילו מציעים את ההצעה המגונה הזו לחברות אחרות (הקוד בGPL, אבל רוצים לחטוף אותו? בכיף, כמה דולרים ותוכלו לפתח אותו מאחורי דלתיים סגורות). הבנתי נכון? |
|
|
|
|
|
|
||
|
||||
|
ראשית כל, זוהי הזדמנות להזכיר שחוץ מה־GPL קיים גם LGPL ורשיונות דומים. באופן כללי הם אומרים: מותר לך להשתמש במה שכתבנו (לדוגמה: שימוש בספרית קוד) ללא שום מגבלות, כל עוד לא שינית אותה. אולם אם אתה רוצה לשנות את הספריה, חלים באופן כללי אותם כללי copyleft כמו במקרה של GPL. לא דיברתי על "לא לגעת". דיברתי על "לעודד". כמו שנכתב במאמר, פרוייקטים שדורשים השמת רשיון סובלים מעצם העובדה שהם מניחים מכשולים בפניהם של תורמים פוטנציאליים. זה לא אומר שאני אמנע משליחת תיקונים ל־Xorg או אפאצ'י אם במקרה יעלה הצורך. אבל אני אשתדל לא להשתמש ברשיונות הללו לתוכנה שאני כותב. זה לפעמים גם שיקול שלי בבחירת תוכנה אם יש כמה אפשרויות. מכיוון שכחלק מעבודתי אני מתעסק עם פרוייקט כזה (GPL, דורש השמת רשיון), אני חורק שיניים ותורם. לפי מיטב הכרתי את הנפשות הפועלות, לא צפוי שהקוד של אותו פרוייקט בעתיד הנראה לעין: המפתחים הנוכחיים לא יסתדרו עם זה ופשוט ינטשו (ויהיה להם איפה למצוא עבודות). אבל שיקולים מהסוג הזה אינם דומים לוודאות הפשוטה שמקבלים עם מגגון בעלי זכויות יוצרים. לגבי MySQL - בשנה האחרונה הוא מראה, כאמור, יותר ויותר סימני עצמאות. QT הוא סיפור יותר מעניין. זו חברה ששינתה את הרשיון בלחץ משתמשי התוכנה החופשית (לא סתם מחאות, אלא התחלה של מימוש מחדש של הספריה). כיום ספריה זו כבר אינה מוצר הדגל של חברה אלא עוד תוכנה של נוקיה, מה שהביא לשינוי נוסף ברשיון (נוספה אפשרות לשימוש כ־LGPLv2 - מאפשר ליצרני תוכנה קניינית להשתמש בה). נראה שנוקיה צריכה יותר את QT ואת סביבת http://en.wikipedia.org/wiki/KDE שמבוססת עליה עובדות היטב וקצת פחות תלויה ברווחים ממכירת התוכנה. משום מה יש לי הרגשה שבעלות כזו על קוד היא לא מצב מספיק יציב. ולסיום - הזמנה להרצאה שכנראה תעניין את באי האתר: |
|
|
|
|
|
|
||
|
||||
|
הגזמתי קצת עם ה"לא לגעת". אבל בוא נשאל שאלה מאד פרקטית. פתחת פרויקט ברשיון GPL. מישהו תרם קוד, ומוכן לתת לך את זכויות היוצרים של הקוד שתרם. אני מבין ממך שתתעקש לא לקבל אותם, נכון? אחרת לפרויקט הזה יש את אותן בעיות כמו שיש לBSD ושות' |
|
|
|
|
|
|
||
|
||||
|
אם מישהו יתעקש? למה לא. לא ברור לי מאיזו סיבה הוא יתאמץ. אבל לא אבקש את זכויות היוצרים. בשביל מה לסבך את החיים? לא הבנתי למה זה גורם לצרות. |
|
|
|
|
|
|
||
|
||||
|
כי אז אפשר לחטוף את הפרוייקט, ובעצם זה מקביל לבעיה שהזכרת ברשיון BSD. אם תתעקש אז הוא לא יוכל לחטוף את הפרוייקט או למכור אותו תמורת בצע כסף ללא הסכמתך. | |
|
|
|
|
|
||
|
||||
|
הוא מראש לא יוכל לחטוף את הפרוייקט - השינויים שלו ממילא תלויים בקוד שלי. לכן גם אם הוא יחליט מחר לשנות את הרשיון לחלק הקוד שלו, זה לא יהיה שווה יותר מדי. ואני יודע שאני לא אחטוף על הפרוייקט - אני סומך על עצמי (אם כי לא דורש מאחרים לסמוך עלי). מהסיבה הזו הוזכר במאמר שקישרתי בתגובה 532022 שבפועל אין הבדל בין דרישה להעברת זכויות יוצרים ליוצר הפרוייקט המקורי לבין דרישה להענקת הרשאה לאותו יוצר לשנות את תנאי הרישוי (אך ללא ויתור על זכויות היוצרים) - בשני המקרים לא יהיה ערך נפרד לתרומתי. דוגמה לפרוייקט שלא דורש העברת זכויות יוצרים אלא קבלת רשיון נפרד "לשנות הכל": דוגמה לארגון שדורשים העברת זכויות יוצרים: אם כי יש לציין שלפחות ה־FSF התחייבה באותו כתב השמה כולל התחייבות מצד מקבל הרשיון (ה־FSF) להשתמש בקוד רק ל"מטרות ראויות" ולא לחטוף אותו. |
|
|
|
|
|
|
||
|
||||
|
אז לא הבנתי, אתה מתנגד לארגונים שדורשים העברת זכויות יוצרים\לשנות את רישוי התרומה שלך או לא. קודם הבנתי שלא, עכשיו אתה אומר שאתה באמת מתנגד לבקשה להעברת זכויות יוצרים. |
|
|
|
|
|
|
||
|
||||
|
אני אכן מתנגד באופן כללי, מסיבות עקרוניות (יכולת חטיפה) ומעשיות (מסרבל את תהליך העבודה שלא לצורך). | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |