ווטסאפ - לינוקס, BSD, קוד פתוח ותוכנה חופשית בעברית. Whatsup - Linux, BSD, open source and free software in Hebrew

 
 
  כניסת חברים · רישום · שכחתי סיסמה  
tux the penguin

quick_linkתפוח רקוב, שועל צולע, וכובע חיוור

published at 27/05/2005 - 06:05 · ‏פורסם דוביקס · ‏tags קוד פתוח , דעות ופרשנות · שלח לחברידידותי למדפסת
קוד פתוח כמה שנים אחורה, כשדניאל רובינס עסק בפיתוח Enoch, הוא נתקל בשלב מסויים בבעיית תקיעה מוזרה שמנעה משרת ה-X לעלות. אחרי דיבוג מאסיבי, הוא גילה באג ב-glibc, ספריית ה-C של גנו המהווה רכיב מרכזי בכל מערכת גנו/לינוקס. התיקון לבעיה הגיע ממקור בלתי צפוי - לרובינס התברר שמפתחי רד האט נתקלו בבעיה, וכללו טלאי עבורה בחבילת glibc של ההפצה.

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

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

שועל צולע

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

ראשית הסיפור בטענה של בן גודג'ר, המפתח הראשי של פיירפוקס, על רמת האבטחה של נטסקייפ. הדפדפן החדש של AOL פותח בהתבסס על פיירפוקס 1.0.3. למרות שגרסה 1.0.4 של פיירפוקס שוחררה זמן קצר לפני נטסקייפ 8, AOL לא טרחה לשדרג את בסיס הקוד וטענה שבעיות האבטחה שתוקנו בפיירפוקס אינן נוגעות לנטסקייפ.

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

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

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

תפוח רקוב

אותו בן גודג'ר, יצא לפני ימים אחדים נגד KHTML (מנוע הרינדור של קונקורר) ובעד אפל, ששתתה לכאורה מהבאר ולאחר מכן ירקה לתוכה.

גם השורשים של הסיפור הזה הם לפני מספר שנים, כאשר אפל בחרה במנוע KHTML כבסיס לדפדפן המק שלה, ספארי. אפל פיתחה מעטפת משלה מעל המנוע (הנקרא Web core) ושחררה מדי פעם טלאים לקוד ששינתה, כמחוייב על פי הרשיון. רבים מהטלאים האלו שולבו במנוע הרינדור

לפני מספר ימים, אפל הודיעה שספארי עבר בהצלחה את מבחן Acid-2, הבודק את תאימות הקוד לתקני HTML ו-CSS. אחד ממפתחי KDE הלין בבלוג שלו על הארוע, וטען למשחק לא הוגן מצד אפל. בעוד שאלו קיבלו גישה ל-cvs של KHTML, הם קיבלו בתמורה ערימות קוד ללא היסטוריית שינויים. לא רק זאת, אלא שהתיעוד המצורף הוא לרוב קריפטי ולא מובן למי שלא מדבר בז'ארגון הפנימי של אפל ו/או יש לו גישה למסד הבאגים של אפל.

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

אחרית דבר

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

קישורים:

IBM Developer Works, From Enoch to Gentoo, via minor setbacks and corporate run-ins,
הבלוג של בן גודג'ר, Netscape 8 Is Unsafe,
הבלוג של כריס אאילון, Never Say Never,
הבלוג של זאק רוסין, So, when will KHTML merge all the WebCore changes?,
OSViews, KDE + KHTML + Apple + Safari + Webcore - Know the facts!
 

קישורים רלוונטיים

· עוד על קוד פתוח
· חדשות מאת דוביקס


הסיפור הנקרא ביותר בנושא קוד פתוח:
לראשונה: סקר קוד פתוח מקיף

תפוח רקוב, שועל צולע, וכובע חיוור | כניסה / יצירת מנוי חדש | 8 תגובות
סף חסימה
  
ההערות הינן מטעם כותביהן. אין צוות האתר לוקח אחריות על תוכנן
אתיקה? יעילות (ניקוד: 0)
ע"י פינגווין אנונימי ב 27/05/2005 - 07:55
לטווח הארוך האינטרס של ההפצה הוא שיהיו לה מינימום שינויים מקומיים שאותם היא צריכה לתחזק. לכן ההפצות בד"כ ינסו להחזיר את השינויים שלהן. מצד שני, זה דורש עוד עבודה (תשתלם בהמשך, אבל לא תמיד יש לכך זמן).

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

צפריר

[ השב לזאת ]

האם אתה מעדיף לארח או להתארח?(ניקוד: 0)
ע"י פינגווין אנונימי ב 27/05/2005 - 11:05
האם אי אפשר לעקוב באופן שוטף אחר הפרויקט וכך גם להיות מעורבים, בין השאר, בקבלת דיווחים על חורים באבטחה ויצירת התיקון להם?
יש כאן שתי דרישות סותרות מצד המפתחים: מצד אחד הם רוצים שלפרויקט שלהם יהיו מקסימום משתמשים, ולכן הם ירצו להזרים עדכוני אבטחה למטה ביוזמתם. אך מצד שני הם עשויים לרצות מקסימום מעורבות של הקהילה בפרויקט, מה שאומר, בין היתר, שהקהילה תשתתף בפרויקט באופן פעיל ביוזמתה. אם הם לא יזרימו עדכוני אבטחה למטה אז השאיפה היא שהקהילה תבוא אליהם כדי לקחת את זה.
זו כנראה דואליות בסיסית בחברה: האם אתה מעדיף לארח יותר מאשר להתארח או להיפך? אני חושב שלא יכול להיות שיווי משקל יציב לנקודת האמצע, רק שיווי משקל רופף.

[ השב לזאת ]

Re: האם אתה מעדיף לארח או להתארח?(ניקוד: 1)
ע"י דוביקס ב 27/05/2005 - 11:13
(מידע על משתמש | שלח הודעה)
נדמה לי שבפרוייקט מוזילה יש בעייתיות מיוחדת - באגים שמתוייקים כבעיות אבטחה מסומנים לעתים כחסויים ולכן גורמי חוץ (ובכלל זה ההפצות) אינן חשופות לתיקון עד שהוא משתחרר. ומרגע שהוא משתחרר יכול לקחת זמן מה ליישם את התיקון ולשחרר גרסה מתוקנת עבור ההפצה.

[ השב לזאת ]

Re: האם אתה מעדיף לארח או להתארח?(ניקוד: 0)
ע"י פינגווין אנונימי ב 27/05/2005 - 12:59
המדיניות הזו אינה ייחודית לפרוייקט מוזילה. מקובל להסתיר בעיות אבטחה שאינן ידועות עדיין לעולם כדי לאפשר הוצאת תיקון מסודרת. אני מניח שכך נוהגים, לדוגמה, גם ברד־האט.
אולם כשיש בעיה עם sendmail, לדוגמה, מפתחי sendmail נוהגים להודיע על כך מראש להפצות ולתאם איתן את הכנת התיקון. בד"כ מתאמים מראש חשיפה של התיקונים.

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

צפריר

[ השב לזאת ]

Re: אתיקה? יעילות(ניקוד: 1)
ע"י דוביקס ב 27/05/2005 - 11:10
(מידע על משתמש | שלח הודעה)
האחד לא סותר את השני. ברור שכאשר מדובר בתיקון של המפיץ ולא של היצרן, אי-החזרת הקוד upstream תחייב את המפיץ לתחזק את הקוד במקום להעביר אותו ליצרן וכך להנות מתחזוקה מרכזית שלו.

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

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

[ השב לזאת ]

Re: אתיקה? יעילות(ניקוד: 0)
ע"י פינגווין אנונימי ב 27/05/2005 - 13:58
מה שכתבתי הוא שאותו כלל אתי בעצם נועד לנסות "לכפות" על המפתח התנהגות שתעזור לו לטווח הרחוק. אם אתה שומר את התיקונים שלך לעצמך, אתה תהיה בסופו של דבר הנפגע העיקרי אם תרצה להמשיך לתחזק את הקוד: תצטרך להשקיע יותר עבודת תחזוקה. יש כאן גם פגיעה משנית בקהילת המשתמשים.

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

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

צפריר

[ השב לזאת ]

Re: אתיקה? יעילות(ניקוד: 1)
ע"י דוביקס ב 27/05/2005 - 14:39
(מידע על משתמש | שלח הודעה)
בהחלט מסכים אתך.

[ השב לזאת ]

Re: תפוח רקוב, שועל צולע, וכובע חיוור (ניקוד: 0)
ע"י פינגווין אנונימי ב 27/05/2005 - 11:07
he probebly never tried submiting a patch to glibc
there are patchs pending there for years before getting any reaction from developers

I doubt it's only redhat
in XFree there used to be the same problem but once Xorg was forked suddenly
redhat and other dist started to contribute
I guess the same would happen if glibc would treat its contributer in normal fasion


nakee

[ השב לזאת ]