נדמה לי שחסידי הקוד הפתוח נופלים בתוך הפח של הדיאלקטיקה שלהם ושוכחים מהי המשמעות של המילה פתוח בתוך "קוד פתוח". למילה פתוח יש שלושה פירושים מקובלים בהקשר הטכנולוגיה/תיכנותי המיחסים לנגישותו של קוד המקור
- כותב התוכנה נותן לך אישור לעשות מה שבא לך עם התוכנה והקוד שלה. תוכנות מהסוג הזה מאופינות בשימוש ברשיונות מסוג BSD.
- כותב התוכנה נותן לך אישור לעשות מה שבא לך עם התוכנה והקוד שלה כל עוד תיתן את אותן זכויות לאנשים שאליהם תעביר את התוכנה, גם אם ביצעת בה שינויים. אלו רישיונות מסוג הGPL.
- קוד המקור מסופק ביחד עם התוכנה עם אישור לשנות אותו אבל בלי אישור (או אם אישור מגביל מאוד) להפיץ אותו הלאה.
כל זה טוב ויפה כאשר ההקשר הוא היכולת של הלקוח לבצע שינויים בקוד המקור שהוא מקבל. בהקשר הזה תוכנה שמופצת ללא קוד המקור שלה ודאי שאינה פתוחה. הבעיה היא שלפעמים מרוב חלוקת העולם לקוד פתוח ושאינו פתוח מאבדים את ההקשר ומשתמשים בחלוקה הזו גם במצבים שבהם אין שום דרישה לשנות את הקוד.
הדוגמא הטובה ביותר העולה בדעתי היא הויכוח האם משרדים ממשלה צריכים לתת עדיפות לשימוש בתוכנות קוד פתוח. הטיעון של הדורשים זאת לא מבוסס בהכרח על היכולת לשנות את הקוד, כי גם הם מבינים שאף מזכירה לא תתחיל לתקן באגים בתוכנת מאבד התמלילים שלה, אלא מסתמכים על כך שבגלל שהקוד נגיש יותר קל למצוא בו פרצות אבטחה.
אבל העובדה שקוד המקור אינו נגיש לא משפיעה כלל על היכולת של אדם לבדוק איך התוכנה עובדת והאם יש בה פרצות אבטחה. מעבר לעובדה שניתן לבדוק תוכנה כ"קופסא שחורה" פשוט על ידי הכנסת כל מיני סוגי קלטים ובדיקה שהפלט תקין ולא גורם לבעיות, ניתן גם לקרוא את הקוד, לא כפי שהוא נכתב במקור, אלא כפי שהוא נקרא על ידי המחשב.
לשפות מודרניות יחסית כמו JAVA וC# יש תוכנות מיוחדות המסוגלות להוציא קוד הדומה במידה מסוימת לקוד המקור מתוך הקובץ אותו המחשב יבצע בזמן הפעלת התוכנה. זה יותר קשה לביצוע בתוכנות שנכתבו במקור בשפת C, אבל לא בלתי אפשרי. למעשה ברגע שהצלחתי לקרוא את הקוד ואני מעונין לבצע בו שינוי, אני יכול בעזרת הכלים המתאימים לקוד שקיבלתי. במקרה הגרוע ביותר ניתן פשוט לשנות את הקבצים של התוכנה על ידי כל עורך שיודע להציג את הערכים הקיימים בקובץ ולא רק את הטקסט.
בעצם יכולתי לקצר ולכתוב – ודאי שכל קוד הוא פתוח. אם קוד שמופץ על ידי מיקרוסופט וחברות קניניות אחרות הוא באמת סגור, איך כל ה"פירטים" מצליחים להבין את הקוד בצורה מספיק טובה ליצירת מעקפים לכל מנגנוני ההגנה?
סיבה אחת שאני יכול לחשוב עליה למה קוד פתוח הוא סוג של יתרון זה לא בגלל שמישהו מצפה שאיזו מזכירה תתחיל לתקן באגים אלא שקוד פתוח מגיע לרוב בליווי רישיון שמבטיח לך שגם אם "בעל הבית" ישתגע ויחליט לא לפתח יותר את התוכנה או לכפות עליך לשדרג לגרסא חדשה יותר, עצם העובדה שהקוד פתוח, מעניקה לך סוג של הגנה ודרכים לעקוף בעיות כאלה.
לגבי הויכוח של משרדי ממשלה ויתרונות הקוד הפתוח, אני לא ממש בטוח על מה מדובר כאן ואם התעורר ויכוח בעת האחרונה, אבל שוב, אני חושב שזה יותר עניין אידיאולוגי של קוד קנייני לעומת קוד פתוח, ולא עניין של יתרון טכנולוגי.
מה שאני מנסה להגיד ואולי גם אני נופל באותו פח שהזכרת בתחילת הפוסט, זה שקוד פתוח הוא משהו שחורג מעבר להגדרות הרישיון שלו.
ולגבי עקיפת "הקוד" שהזכרת בסוף.
הדברים האלה נעשים ברמה נמוכה, של זכרון ואוגרים (registers) או בקיצור בreverse engineering ומעט מאוד קוד מעורב בזה (מלבד קוד בשפת אסמבלי) וגם אם אותם קראקרים מצליחים להבין מספיק ממה שנעשה ברמת הקוד, להגיד שזה מה שעושה קוד לפתוח?
טוב, אני רק אגיד שזו הגדרה מאוד מאוד נדיבה:)
מהסוף להתחלה.
מה שאתה אומר על רגיסטרים וכדומה נכון לקוד שכתוב בשפת C, או כל קוד אחר שמקומפל לשפת אסמבלר. אבל היום הרבה מאוד תוכנה נכתבת בשפות כמו JAVA וכל וריאציות ה.NET והן לא מקומפלות לאסמבלר אלא לשפת ביניים שאותה קל יחסית לקרוא, ויש כלים שהופכים את קוד הביניים בחזרה לקוד "הרגיל". כמובן שבתהליך הולכות לאיבוד כל ההערות ושמות משתנים משמעותיים, אבל ממה שנשאר אפשר להבין הרבה מאוד על הצורה בה עובדת התוכנה.
לענין של מה קורה עם החברה נסגרת ואין מי שיתן תמיכה יש פיתרון וקוראים לו שירותי escrow. בעל התוכנה מפקיד אצל עורך דין המתמחה שמתן שירותים כאלו את קוד המקור של התוכנה (ואני מניח שהעורך דין בודק שגם כל סביבת הקומפילציה נמצאת ומתאימה), ובמקרה שהמפתח סוגר את החברה הלקוח מקבל את הקוד. אני לא יודע עד כמה דברים כאלו מקובלים בארץ, אבל הם לא נדירים בארצות הברית.
בכל מקרה, הרי אפילו אם הממשלה היתה עוברת מחר ללינוקס וIBM היתה מתאימה את התוכנות לצרכים. מה הסיכוי שמישהו בממשלה היו דואג שיהיה לו עותק מעודכן של קוד המקור וסביבת העבודה של כל התוכנות?
הדיון בקוד פתוח עולה למשל בקטע של מערכות הצבעה אלקטרוניות. אנשים טוענים שמערכות כאלו המבוססות על קוד פתוח יותר בטוחות.
אנשים
טוענים שהן יותר בטוחות בהקשר הזה לא בגלל פרצות אבטחה, אלא בגלל שבמקרים כאלה, הן עלולות להיות זדוניות בעצמן.
נניח שהמתכנת הוא קומוניסט מרושע (כל המתכנתים שמאלנים, כל השמאלנים מרושעים, לא?). הוא שותל שורת קוד שאומרת שכל 120 קולות, צריך להפוך קול אחד לקול לחד"ש – והופ, חד"ש הרוויחו מנדט.
לעלות על זה בקוד פתוח זה קשה – צריך פרוייקט מסודר של סריקת הקוד. לעלות על זה בקוד סגור, גם עם reverse engeneering, זה קרוב לבלתי אפשרי.
דרומי, אתה ממש טועה. עובדתית, נתגלו הרבה מאוד פרצות אבטחה בקוד של מיקרוסופט למרות שהוא "סגור". לפי הטענה שלך הדבר הזה בלתי אפשרי. איך זה נעשה? אין לי מושג אבל העובדה היא שזה אפשרי ביותר.
מעבר לזה, כתבתי פה 100 מילים שבחרת להתעלם מהן לחלוטין. כל תוכנה בצורת ההרצה שלה מכילה את כל הקוד שלה וניתן לקרוא אותו. קיימים כלים עבור כל שפות התכנות שלוקחים את קוד ההרצה והופכים אותו לקוד מקור. התוצאה תהיה באופן עקרוני פחות קריאה שהקוד המקורי, מאחר שילכו לאיבוד שמות המשתנים וההערות, אבל עד כמה זה יותר קשה להבין קוד לא ברור? זה הרי לא שכל הפרויקטים של קוד פחות מכילים קוד ברור, מתועד ומוער (בתור תרגיל תנסה למצוא הערות בקוד של וורדפרס).
אז עד כמה זה יותר קשה לקרוא קוד "סגור"? לא יודע, אבל ודאי שזה לא בלתי אפשרי מאחר שכבר עשיתי דברים כאלו בחיי במקומות בהן הייתי צריך להבין איך ספריות עובדות ולא היה להן תיעוד מספק.