החלטתם לפתח אתר, אפליקציה או תוכנה – מרגש! יש 3 אפשרויות לעשות את זה: (א) מפתח שהוא/היא חלק מהצוות (מה שנקרא CTO – Chief Technological Officer), (ב) בעצמכם – אם יש לכם רקע בתכנות או קצת חוש טכנולוגי בעזרת כלי AI או no code, או (ג) בעזרת בית תוכנה או פרילנסר/ים. לכל אחת מהאפשרויות יתרונות וחסרונות (עלויות, זמן, איכות ועוד) – אבל בכל מקרה, כנראה שתצטרכו הסכם פיתוח תוכנה.

בנוסף, לכל אחת מהאפשרויות יש היבטים משפטיים שצריך להכיר: במקרה שיש CTO – צריך לחתום על הסכם מייסדים. במקרה של פיתוח עצמי, יש לוודא שאתם באמת הבעלים של זכויות היוצרים במה שיצרתם (ושזה לא שייך – למשל – לבעלי התוכנה שנעזרתם בה), ובמקרה של בית תוכנה או פרילנסרים, צריך לחתום על הסכם פיתוח או הסכם שירותים. בפוסט הזה אתמקד בנושאים הנדרשים בהסכם פיתוח תוכנה.

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

אז מה יכול להשתבש ולמה צריכים הסכם (מקרים אמיתיים):

• סטארט-אפ שילם $20,000 עבור פיתוח אפליקציה, רק כדי לגלות חודשים מאוחר יותר שהקניין הרוחני (ה-"IP") מעולם לא הועבר למייסדים או לסטארט-אפ – אלא נשאר אצל המפתח. מאוחר יותר, כשהמייסד ניסה לגייס השקעה, הוא נאלץ לשלם עוד 15,000$ נוספים רק כדי לקבל בעלות שהייתה אמורה להיות שלו מלכתחילה.
• צוות מפתחים קיבל 70% משכר הפרויקט מראש  ואז נטש את הפרויקט באמצע. למייסדים כבר לא נשאר מספיק כסף להשלים את הפרויקט במקום אחר ונתקעו עם קוד חצי גמור שאף אחד לא היה מוכן לגעת בו (מתכנתים פחות אוהבים להמשיך לעבוד על קוד אחר – זה לרוב מסובך יותר אם אין תיעוד מספיק טוב של מה נעשה).
• אפליקציית ווב (web-app) נמסרה ללקוח (יזמת), אך הגרסה שקיבלה הייתה רחוקה ממה שציפתה לקבל והתעוררו מחלוקות לגבי מי צריך לשלם עבור התיקונים והשינויים הנדרשים. המחלוקות הובילו לאיומים, והפרויקט נתקבע.

מצבים אלה אינם נדירים, והם ניתנים למניעה עם החוזה הנכון וצעדים מעשיים חכמים.

למה הסכם פיתוח תוכנה הוא קריטי

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

מתי כדאי להשתמש בהסכם פיתוח תוכנה?

גם ללקוחות וגם למפתחים יש אינטרס ברור שיהיה הסכם פיתוח תוכנה. עם זאת, לא בכל מצב זה משתלם (לפחות לא מבחינה כלכלית). כלל האצבע בגדול הוא כזה: אם עלות הפרויקט נמוך מעלות עריכת ההסכם (ראו עלויות של חוזים נפוצים לסטארט-אפים) או העלות של עו"ד לבדוק את ההסכם שקיבלתם מבית התוכנה (סביבות 3,000 – 15,000 שקלים – תלוי בסוג הפרויקט), אז אולי עדיף (כלכלית, לא משפטית) לחתום על טופס הזמנת עבודה קצר שמכסה את הנושאים העיקריים (חלקם מוזכרים כאן למטה) ולוותר על הסכם מלא. ההמלצה המשפטית הא שתהיה הסכם, אבל אם אתם מפתחים אתר שעולה 7,000 שקלים, כנראה שלא יהיה כדאי לשלם כמה אלפי שקלים לניסוח או בדיקת ההסכם…

אילו נושאים חשוב לכסות בהסכם פיתוח תוכנה

1. תיאור השירותים / הפרויקט

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

2. הגדרת אבני דרך ברורות, סבבי תיקונים ותוצרים

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

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

3. בעלות על קניין רוחני

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

מה צריך לכלול בהסכם:

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

4. אופן ביצוע התשלום

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

• תשלומים לפי אבני דרך: חלקו את הפרויקט לשלבים (למשל, wireframes – תמונות של האפליקציה, גרסת בטא, מסירה סופית) וקשרו את התשלומים להשלמה מוצלחת של כל שלב. רצוי לפרט כל שלב ושלב. זה בסדר אם המפתחים יבקשו מקדמה קטנה – לא כל הלקוחות הוגנים או ישרים וגם הם צריכים להגן על עצמם, אבל זה לא צריך להיות יותר מ-5%-15% (ככל שהפרויקט יקר יותר, האחוז נמוך יותר ולהיפך). במקרה של מחלוקת, אפשר גם להיעזר בצד שלישי (סוג של נאמן, או למצוא פתרון אחר).
• שמירת אחוז מהתשלום הסופי: רצוי לשמור כ-10%-20% מהסכום הכולל למשך תקופה מסוימת מתום הפרויקט (לפחות 2-3 שבועות לאתרי אינטרנט, 1-2 חודשים לאפליקציות ותוכנות). לאחר אותה תקופה, תהיה תקופת תמיכה בתשלום מוסכם מראש.
• אישור אבני הדרך: חשוב להבהיר שהתשלום עבור כל אבן דרך ייעשה רק בדיקת האיכות ומתן אישור שהכל תקין.
• עותק של הקוד: תוודאו שביחד עם ביצוע התשלום (עבור כל שלב) אתם מקבלים העתק של הקוד שנכתב עד לאותו השלב. חשוב שזה יכלול גם את ה-documentation (הסברים לאיך הקוד נכתב ולמה).

5. קוד פתוח

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

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

6. הימנעות מהפרת זכויות צד שלישי

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

7. סודיות ואי תחרות

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

8. סמכות שיפוט – התמודדות עם אתגרי אכיפה

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

מחשבות לסיום

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

אם אתם זקוקים לעזרה בניסוח או בדיקת הסכם פיתוח תוכנה – מוזמנים ליצור קשר!