זכויות המתכנת בקוד המקור
אסור לזלזל באותיות הקטנות של חוזים גם כאשר הכל ברור וגלוי לכאורה. למילים יש לפעמים משמעות אחרת בהקשר המשפטי ולכן מומלץ להעביר את החוזה לקריאת מומחה ולהקפיד שלא יישארו בו היבטים לא ברורים. דע את זכויותיך על הקוד שכתבת
ידידה שלי, שעוסקת בתכנות כמפתחת עצמאית, שאלה אותי שאלה תמימה לכאורה: האם קוד המקור הוא חלק מהתיעוד של מוצר תוכנה? מתברר שהתשובה מורכבת יותר ממה שנראה לעין, גם אם העין שייכת למשפטן, ותלויה רבות בניסוח המדויק של חוזה העבודה בין הקבלן ללקוח.
בדיקה מקצועית של החוזה הספציפי העלתה מספר נקודות לא ברורות, כמו השאלה אם קוד המקור שייך למזמין או קניינו הרוחני הבלעדי של המתכנת. מאחר שנושא זה נוגע לחלק מהקוראים, כדאי להקדיש לו כמה מלים. טור זה לא יהפוך את קוראיו למומחים לחוזי תוכנה, אך יסייע להם לפתח מודעות לעניין.
החוזה של ידידתי חייב אותה לספק ללקוח: (1) את כל המידע הרלוונטי לשירותים שבוצעו במסגרת הפרוייקט (2) דוחות חודשיים (3) יומן עבודה (4) ודוח שעות (5), כמו גם להיפגש עם נציגי הלקוח לעתים מזומנות כדי לדון בהתקדמות העבודה והשגת מטרות הפרוייקט.
הלקוח דרש ממנה להביא לפגישות את קוד המקור, על מנת שייבדק על ידי צד ג' המשמש כמפקח על איכות המוצר. בין השאר, הבודק אמור לקבוע האם המתכנת משתמש בשיטות הטובות ביותר (Best Practices) להשגת המטרות. כמובן שכאן עולה שאלה פתוחה נוספת, והיא מהן השיטות הטובות ביותר? ברור שהכוונה היא לשיטות המבטיחות כי המטרות המוגדרות יושגו במערכת מאובטחת, אבל האם הקריטריונים צריכים לכלול מהירות? ומה גודל הקוד הרצוי? האם על המתכנתת להבטיח יכולת שימוש חוזר במודולים, לעמוד בסגנון תכנותי מסוים ולהשתמש בשפות תכנות מסוימות? ומה לגבי התאמה עם רכיבי תוכנה של חברות אחרות?
אם הפרמטרים האלה לא הוגדרו בחוזה, למי הזכות לקבוע מה נחשב לשיטה טובה ומה לא? ומי ישמש בורר אם המתכנת והבודק לא מסכימים ביניהם מה טוב יותר ומה טוב מספיק?
מה ההבדל בין מתכנת לרופא?
כפי אפשר להבין, מתכנת אינו ספק של מוצר פשוט, שהתאמתו למשימה ניתנת לבחינה פשוטה על ידי מומחים בלתי תלויים. ומצד שני הוא לא מספק שירות מקצועי מהסוג שמציע עורך דין או רופא, שמתחייבים לעשות את "מיטב המאמצים" כדי לשרתו אך אינם יכולים להתחייב להצליח.
בעיה נוספת נעוצה ברצון הלגיטימי של מרבית התוכניתנים לשמור בסוד חלקים קריטיים מהקוד, בהם ניתן לעשות שימוש חוזר בפרוייקטים אחרים. ברור לנו שרכישת תוכנת מדף אינה מעבירה את הבעלות על הנכסים האלה מהיצרן לקונה. האם אותו כלל תופס גם כאשר היצרן הוא קבלן תוכנה והקונה מזמין עבודה במיוחד למפרט שלו?
במקרים פשוטים במיוחד התשובה לכך היא פשוטה. אם המערכת היא קניינית לחלוטין ואין לה קונים אחרים, אם החוזה מגדיר במפורש כי הלקוח יוכל לתחזק ולעדכן את הקוד בצורה בלתי תלויה במתכנת, ואם המתכנת מעוניין להשתחרר מאחריות לקוד אחרי בחינות הקבלה, בכל המקרים האלה סביר כי הלקוח יקבל את קוד המקור כחלק מהתיעוד.
בין ארכיטקטורה לתכנות
עם זאת, קבלת הקוד לא הופכת את הלקוח לבעל הנכס האינטלקטואלי, כפי שהעברת תוכניות בניין מארכיטקט ללקוח לא מאפשרת לאחרון לשכפל ולמכור אותן. הלקוח יכול ללמוד את התוכניות, ו"לגנוב" רעיונות עבור בניינים אחרים, אבל לא להעתיק אלמנטים שלמים כפי שהם ובוודאי לא למכור אותם לצד ג'.
ההבחנה בין המקרים השונים אינה פשוטה, ובניגוד למצב המשפטי בארכיטקטורה (או במקצועות חופשיים קלאסיים אחרים), המערכת המשפטית מתקשה לקבוע זכויות בתוכנה על פי תקדימים. מוטב לקבוע את כל הפרטים האלה בחוזה העבודה ולא להסתמך על ניסוחים כלליים, שנשמעים טוב אבל לא מספקים את האבחנה הדרושה.
אם מוסכם שהמתכנת ישמור על קוד המקור לעצמו, עדיין נשאר לקבוע איך תתבצע הבחינה של איכות המוצר. מעבר לשאלות הכלליות של הגדרת האיכות יש צורך לקבוע דרכים טכניות לבחינה. בהחלט סביר שהלקוח ידרוש בחינה של קוד המקור, ולו אף כדי להשתכנע שאינו מכיל וירוסים, מלכודות (Trapdoors), סוכני ריגול או כל קוד הרסני אחר, שאי-אפשר לזהותו בזמן ריצה.
האם קוד המקור יסופק בתיעוד כתוב או אלקטרוני? איך יובטח למתכנת שהבוחן לא מעתיק אותו? האם הבדיקה תעשה אך ורק בנוכחות המתכנת ועל המחשב שלו? האם הקוד הנבדק ישמר בנאמנות על ידי גוף מוסמך לצורך השוואה במקרים של סכסוכים עתידיים? ואם כבר מדברים בקוד המקור, ברור שצריך להגדיר מראש את היחסים שלו עם קוד זמן הריצה: על איזו פלטפורמה יפותח הקוד ומה היא פלטפורמת המטרה. באיזה מהדר (קומפיילר) ישתמשו? על איזה מחשב יעשה ההידור הסופי? באיזו סביבות תוכנה ירוץ היישום?
לא רק שאלות טכניות
כל אלה אינן רק שאלות טכניות של הגדרת הפרוייקט. מדובר בפרמטרים רלוונטיים מבחינה משפטית לשאלה, האם הקבלן עמד בדרישות החוזיות או לא. גם הבודק יהיה חייב להתייחס אליהם בהערכת איכות הקוד - ובית המשפט ידע להתייחס לחוות הדעת של הבודק בהתאם לקפדנות בו הוא נצמד לחוקי הבדיקה המוסמכים מראש.
השורה התחתונה היא: אסור לזלזל בפרטים החוזיים גם כאשר מבחינה טכנית הכל נראה ברור וגלוי. למילים יש לפעמים משמעות אחרת בהקשר המשפטי ולכן מומלץ לתת למומחה לקרוא את החוזה ולהקפיד שלא יישארו סעיפים שאינם ברורים או מוגדרים היטב. העלות המשפטית הכרוכה בחוסר ההבנה היא יקרה מדי.