Software Escrow: הגנה על קוד מקור
דמיינו שהתוכנה שמנהלת את כל המחסן שלכם פותחה על ידי חברה קטנה. יום אחד החברה נסגרת — מייסד עזב, כספים נגמרו. אין תמיכה. אין גישה לקוד. לא ניתן לתקן תקלות. Software Escrow הוא הכלי המשפטי שמונע את התרחיש הזה.
מה זה Software Escrow ומתי הוא נחוץ?
Software Escrow הוא הסכם שלושה צדדים: הלקוח (שרכש את התוכנה), הספק (שפיתח אותה), ונאמן (צד שלישי נייטרלי). הנאמן מחזיק את קוד המקור ומשחרר אותו ללקוח אם מתקיים אחד מהתנאים המוגדרים בחוזה.
מתי זה הכרחי? כאשר התוכנה שנרכשה היא קריטית לפעילות העסק ואין לה חלופה קלה. תוכנת ניהול ייצור, מערכת ERP מותאמת אישית, או ממשק ייחודי עם לקוחות — כל אלה מצדיקים Escrow. תוכנה מדף (SaaS רגיל, Office, Zoom) — לא.
אילו סוגי Escrow קיימים?
Source Code Escrow — הנפוץ ביותר. הנאמן מחזיק את קוד המקור של התוכנה — הגרסה שממנה ניתן לבנות מחדש את המוצר ולתחזק אותו. זה מה שרוב הלקוחות צריכים.
Object Code Escrow — הנאמן מחזיק בקוד הבינארי (קבצי EXE, DLL) שניתן להריץ, אך לא לשנות. מגן על הפעלה המשך בסיסית, אך לא מאפשר תחזוקה אמיתית.
Documentation Escrow — תיעוד המערכת: ארכיטקטורה, מדריכי התקנה, מסמכי API. חיוני לכל מצב שבו צד שלישי ייאלץ להמשיך לתחזק את הקוד.
Database Escrow — במערכות מורכבות, גם מבנה מסד הנתונים ונתוני הקונפיגורציה מופקדים אצל הנאמן.
מתי הלקוח יכול לדרוש את הקוד?
אלה הטריגרים הנפוצים שמגדירים מתי הנאמן משחרר את קוד המקור ללקוח:
פשיטת רגל או פירוק הספק — זה המקרה הכי ברור וחשוב. אם הספק נכנס להליכי חדלות פירעון, הקוד עובר ללקוח ומאפשר לו להמשיך לפעול.
הפסקת תמיכה — הספק מודיע שהוא מפסיק לתמוך בגרסה הנוכחית ואין לו כוונה לספק תחליף. הלקוח זכאי לקוד כדי לתחזק בעצמו.
הפרת חוזה שירות מהותית — כשהספק לא עומד ב-SLA לאורך זמן ולא מתקן. הגדרת "מהותית" חייבת להיות מפורשת בחוזה.
חדלות פירעון פרטית — גם בלי הליך רשמי, אם הספק לא מסוגל לעמוד בהתחייבויותיו לאורך תקופה מוגדרת.
מה חייב להיות בחוזה Escrow?
חוזה Escrow שאינו כולל את הרכיבים הבאים — כמעט חסר ערך:
הגדרת "חומרי Escrow" — בדיוק מה מופקד: קוד מקור, תיעוד, מפתחות הצפנה, credentials לשירותי ענן. ניסוח עמום יוצר מחלוקת בדיוק כשצריכים את הקוד.
לוח עדכונים — כמה פעמים בשנה הספק מחויב לעדכן את החומרים אצל הנאמן. הקוד שמוחזק אצל הנאמן לא שווה כלום אם הוא גרסה ישנה מלפני שנתיים.
בדיקת Verification — הזכות של הלקוח לבדוק פעם בשנה שהחומרים המופקדים אכן תקינים, מלאים, ועובדים. בלי Verification — אין לדעת אם מה שהופקד שמיש בכלל.
הליך שחרור מוגדר — מי מודיע לנאמן, תוך כמה ימים הנאמן פועל, ומה קורה אם הספק מתנגד לשחרור.
מה עולה הסדר Escrow?
עלויות אופייניות (לנאמנים בינלאומיים כמו NCC Group, Iron Mountain):
עמלת הצטרפות: $300–$500 חד-פעמי. שמירה שנתית: $150–$400 לשנה. עדכון קוד: $200–$300 לעדכון. שחרור קוד במקרה אמיתי: $500–$1,000. בישראל ניתן לעבוד גם עם נאמנים מקומיים שעלויותיהם נמוכות יותר — אך יש לוודא שהם מכירים את הדין הישראלי ומבוטחים.
טעויות נפוצות בהגדרת Software Escrow
להניח ש-SaaS כולל Escrow — ברוב הסכמי SaaS, הלקוח רוכש שירות, לא תוכנה. הקוד לא שייך לו ואין לו זכות לקבלו. ללא סעיף Escrow מפורש בחוזה — אין הגנה.
לשכוח לעדכן — הסכם Escrow שנחתם ביום הפרויקט ולא עודכן מאז — מגן על גרסה ישנה. חייבת להיות חובת עדכון חוזית מפורשת.
לא לבצע Verification — לקוחות רבים חותמים על הסכם Escrow ומניחים שהכל בסדר. אחרי שנה מגלים שהנאמן מחזיק קוד שבור שאינו מתקמפל. בדיקה שנתית היא לא אופציה — היא חובה.
קראו גם:
📌 זווית מקצועית — לעורכי דין
- טיפ פרקטי: בכל הסכם פיתוח תוכנה ייחודי — דרשו Software Escrow כתנאי בסיסי. הסבירו ללקוח שזה כמו ביטוח: אנחנו מקווים לא להזדקק לו, אבל ללא — הסיכון בלתי מוגן. העלות נמוכה ביחס לחשיפה.
- פסיקה רלבנטית: ⚠️ קיימים מקרים בבתי משפט ישראלים שבהם לקוח ביקש לקבל קוד מקור ללא הסכם Escrow מוקדם — ולא הצליח. מומלץ לאמת מול עורך דין טכנולוגי לפני ציטוט ספציפי.
- טעות נפוצה: לחשוב שחוזה SaaS כולל אוטומטית גישה לקוד מקור. ב-SaaS הרגיל — הקוד אינו חלק מהרישיון ואין ללקוח כל זכות אליו.
- נקודה טקטית: דרשו "בדיקת Verification" שנתית בחוזה הנאמנות — כדי לוודא שהקוד שנמסר לנאמן עובד, מתקמפל, ומעודכן לגרסה הנוכחית. בלי Verification — ההסכם הוא הגנה על נייר בלבד.