0. הקדמה:

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

כשל השוק כאן הוא ברור: מפתח ווב או מעצב שמתבסס על מערכת בקוד פתוח מספק מעט עבודה, בצורה יחסית, ומקבל גמול של אלפי שקלים בודדים לעיתים עבור עבודת הפיתוח שביצע. במצב כזה, אין ידו מספקת לייעוץ המשפטי הדרוש על מנת ללוות את הפרויקט. לשם ההדגמה, אם פרויקט מסוים עלה 9,000 ש"ח על פי 50 שעות לפי 180 ש"ח לשעת עבודה, הרי שדי להבין שאם התעריף המינימאלי של עורך דין לעריכת חוזה על פי כללי לשכת עורכי הדין (התעריף המינימלי המומלץ) הוא 560 ש"ח, ועבודת עורך הדין דורשת כאן למידה של הפרויקט, ייעוץ ועוד.

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

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

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

1. הצעת מחיר כהסכם מחייב:

ראשית, יש לזכור כי הצעת המחיר הנשלחת ללקוח היא הצעה מחייבת לפי חוק החוזים (חלק כללי). על פי חוק החוזים, חוזה מורכב מהצעה וקיבול; כלומר די בכך שהצעה תכיל מסוימות (כלומר, רמת פירוט מינימאלית) ותקובל על ידי הצד השני כדי להיות מחייבת על שני הצדדים. מרגע ששלחת הצעת מחיר ללקוח, הרי שהתחייבת בפניו לבצע עבודה ספציפית במחיר ספציפי; בית המשפט העליון הסביר בפסק הדין עא 440/75 אשר זנדבנק נ' מלכה דנציגר כי "דרישה של החוק לפיה על ההצעה להיות מסויימת, טומנת בחובה יסוד פוזיטיבי, הוא ענין הבהירות הנדרשת, אך משתמע ממנה גם כי אין צורך שיהיו בהצעה כל הפרטים הצריכים לענין, עד לאחרון שבהם. אמת-המידה איננה בכך שהפירוט יהיה כליל השלמות, אלא בכך שמתוך אותו פירוט המובא בהצעה, ניתן יהיה להסיק בבירור על מהותה ותחומיה של העסקה וזו משמעותה של האמירה, לפיה על ההצעה להיות "מסויימת"".

1.1.

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

1.2.

עכשיו, עולה השאלה מהו סוג האישור שיש לקבל מהלקוח? האם חובה לקבל את חתימתו הפיסית, האם די בחתימה על פקס או אישור במייל, או שמספיקה ההסכמה הטלפונית שלו? בכלל, חוק החוזים אינו מחייב כי ההסכמה להצעה תהיה בכתב, אלא מאפשר קיבול "בהודעת הניצע שנמסרה למציע", למעט מספר חריגים הקבועים בחוקים ספציפיים כמו חוק המקרקעין, שקובע כי עסקאות במקרקעין (כמו מכירת דירה) חייבות להיות בכתב, ההסכמה יכולה להיות בעל-פה. חשוב להבין שכאשר ישנה הצעה מחייבת בכתב, ורק ההסכמה היתה בעל פה, קבע בית המשפט העליון בעא  196/87 רות שוייגר נ' אליהו רז לוי, פ"מ מו(3) כי ניתן להסכים בעל-פה להצעה שניתנה בכתב, אלא שבמידה ויש טענות כי ההסכמה בעל-פה שינתה את האמור בכתב יש להוכיח זאת על ידי עדות: "אכן, לעתים יימנע בית המשפט מלהיכנס לבירור מחלוקות עובדתיות בדבר הסכמות בעל-פה שהושגו כביכול והסותרות את האמור במסמך. הכתב אכן מבטיח גם ודאות ראייתית רבה יותר… אלא שבמקרה שלפנינו הרי מודים הצדדים שאכן כך הוסכם".

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

1.4.

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

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

1.5.

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

2. זכויות יוצרים:

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

2.1.

הדין על יצירה מוזמנת: בין אם מדובר בהרשאת שימוש במערכת שפותחה על ידך או בבניית מערכת חדשה לגמרי עבור לקוח, הוראות הדין אחידות: סעיף 35 לחוק זכויות יוצרים קובע כי "ביצירה שנוצרה לפי הזמנה, הבעלים הראשון של זכות היוצרים בה, כולה או חלקה, הוא היוצר, אלא אם כן הוסכם אחרת בין המזמין והיוצר, במפורש או במשתמע". אולם, במספר מקרים אשר נסמכו על הוראות החוק הישן, פסק בית המשפט כי די היה בהסכמה משתמעת לחלוטין על מנת להעביר את זכות היוצרים למזמין (תא (מרכז) 6004-08-07 מפעלי גדנסקי בע"מ נ' ברום תעשיות טקסטיל (1993) בע"מ, תא (ת"א) 2085/01‏ ‏ מאיר אבגנים נ' עוזיאל בריח). כמו כן, כאשר מדובר בעובד שכיר, הרי שזכויות היוצרים אוטומאטית עוברות למעביד (סעיף 34 לחוק). לכן, ראוי להגיע להסכמה מובהקת לגבי מידת הזכויות המוקנות למפתח ומידת הזכויות המוקנות למזמין: האם המזמין מקבל רשיון שימוש במערכת אשר פיתח או בעלות בקוד? האם למפתח מותר להשתמש בקוד במערכות נוספות שיפתח (בשא (ת"א) 17378/08 לילי פרי נ' הדר פורן געתון בע"מ) והאם המזמין רשאי לנהוג בקוד כבעליו.

2.2.

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

2.3.

מערכות בקוד פתוח: חלק ניכר מעולם פיתוח הWeb מבוסס היום על תשתיות בקוד פתוח. ראשית, ועל מנת להגיע למכנה משותף, אני אסקור מהן תוכנות בקוד פתוח, אסביר מה היתרונות בשימוש בהן, וכיצד יש לטפל במערכות מבוססות קוד פתוח כחלק מפרויקט שניתן בהזמנה. לצורך העניין, חשוב להבין שעל פי חלק מרשיונות הקוד הפתוח, ובמיוחד GPL, כמעט כל שימוש בקוד שמשוחרר בו ידרוש שלאחר מכן כל הפרויקט ישוחרר בקוד פתוח. הטקסט בפרק זה מבוסס על שתי הרצאות שנתתי לאנשים ומחשבים, הראשונה "שימוש בקוד פתוח כתשתית IT לארגון: יתרונות וחסרונות", והשניה "איך בונים סטארט-אפ על קוד של אחרים"; כדי להבין יותר לעומק על מהן תוכנות בקוד פתוח, שרוב מפתחי הWeb עובדים איתן ועליהן כל יום, מומלץ לפחות לקרוא את ההרצאה השניה.

2.3.1.

אז בקצרה, מה הן תוכנות בקוד פתוח? תוכנות בקוד פתוח הן תוכנות בהן, בעת ההעברה, ניתן למזמין קוד המקור (Source Code) של האפליקציה, על ידי אחד מהרשיונות המקובלים על ידי הOpen Source Initiative ועוקב אחרי עשרות הדיברות לקוד פתוח: (1) הרשיון מאפשר הפצה חופשית של הקוד; (2) למקבל הרשיון יש את הזכות לקבל גם את קוד המקור של התוכנה; (3) מותר לייצר יצירות נגזרות מהתוכנה (כלומר, מותר לך לשנות אותה); (4) ניתנת גישה לתוכנה המקורית ממנה נוצרה התוכנה; (5) אין אפליה בין בני אדם או קבוצות בשימוש בתוכנה; (6) אין אפליה בין מטרות או שימושים; (7) הזכויות הצמודות לרשיון מוצמדות לכל הפצה נמשכת; (8) הזכויות אינן צמודות למוצר ספציפי אלא לקוד תוכנה; (9) הרשיון לא יכול להגביל תוכנה אחרת ו(10) הרשיון נייטרלי מבחינה טכנולוגית. במצב כזה, הלקוח מקבל את הרשיון כמו יצירה מוזמנת עבורו, עם כל הזכויות ונקי מהתחייבויות לצדדים שלישיים: כל עוד הלקוח לא מפיץ את הקוד לאחרים, מותר לו לעשות עם התוכנה כמעט כל מה שהיה מותר לו לעשות אם הוא בעצמו היה כותב את הקוד, ואין חובה שהוא ישלם עבור רכישת הקוד או תמלוגים חודשיים (למרות שבפועל ניתן לגבות כסף עבור שירותים או התאמות, או אפילו עבור פיתוח למישהו אחר על בסיס קוד פתוח).

2.3.2

השימוש מאפשר חופש למשתמש, אך מגביל את המפתח מהיכולת להגביל את לקוחותיו. לא בכדי תוכנות קוד פתוח נקראות גם תוכנה חופשית. ללקוח שמקבל את התוכנה ניתן החופש לבחור מה לעשות עמו, ואינו קשור בהסכמים מגבילים של יצרני תוכנה וספקי שירותים. רשיון הGPL, לדוגמא, אחד הרשיונות הפופולריים, כלל אינו מאפשר להטיל כל מגבלה על התוכנה. סעיף 10 לגרסא 3 של הרשיון קובע כי "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License". כלומר כאשר לקוח רוכש או מתקין תוכנה שמוגנת על ידי הGPL, הוא מקבל אותה עם הזכויות שהמפתח אותה קיבל. בניגוד לרשיון בסגנון רשיון השימוש של חלונות XP, שאוסר הנדסה לאחור של מערכת ההפעלה, רשיונות התוכנה החופשית נותנים ללקוח את הזכויות שבדרך כלל מפתחי Web לא היו רוצים לתת.

2.3.3

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

2.3.4

כמובן שרשיונות קוד פתוח מחילים את התנאים שלהם רק כאשר ישנה הפצה בפועל של קוד. כלומר, אם ביצעת עבודה ללקוח והוא מקבל את הפתרון בצורה שהיא Hosted ולא מקבל עותק של קוד המקור, הרי שלא התרחשה הפצה של התוכנה (כדרוש, לפחות ברשיון הGPL, על מנת להכניס את הרשיון לתוקף). מנגד, ספק אם אילוץ פיקטיבי שיאסור על הלקוח להחזיק בעותק של הקוד יהיה תקף וראוי לזכור כי הפרה של הוראות הרשיון היא הפרת זכויות יוצרים, שמפקיעה את הזכות להשתמש או להפיץ את אותו הקוד (Jacobsen v. Katzer, 535 F. 3d 1373 – Court of Appeals, Federal Circuit 2008).

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

2.4.

עיצוב האתר: זכויות היוצרים בעיצוב האתר לא שונות בהרבה מסוגיית הזכויות בקוד התוכנה. אלא שיש כאן הבדל אחד. בעוד שפעמים רבות קוד תוכנה משוחרר תחת רשיון GPL, פעמים רבות התבנית לעיצוב האתר נלקחת מאתרים כמו TemplateMonster ודומיהן. בין אם מדובר על תבניות בתשלום ובין אם מדובר על תבניות שניתנות בחינם, יש צורך לברר ולקרוא את רשיון השימוש בתבנית הספציפית על מנת לוודא שאין הפרה בהפצה ללקוח או בשימוש בתבנית במספר אתרים. מעבר לכך, כאשר משתמשים בתמונות אסור בתכלית האיסור להשתמש בתמונות ש"נמצאו באינטרנט" ולא צורפו אליהן זכויות. כאשר נלקחות תמונות יש לעשות זאת אך ורק ברשות; על פי הפסיקה, לא די בכך שתוכן מסוים "נמצא" ברשת כדי לאפשר את השימוש בו (תא (י-ם) 1191-09 דן פורגוס נ' דוד סיון, א 190227/02 פרחי גורדון נ' פרחים כפר רות, א 58032-07 טס שפלן נ' ידיעות אחרונות, א 25689/08 א.מ פרחים נ' חיים ריימונד בן יצחק, א 65559/04 ערד נ' משכל) וכן לא די בקבלת רשות בשיטת "סמוך עליי" אלא יש לבדוק את קיומה של הזכות ממי שנתן את התמונות (א 19221-01-10 גיל דור נ' פז שמנים).

2.4.1

חובת מתן קרדיט: חשוב לזכור כי בתמונות ותבניות שנרכשו כדין עדיין יש חובה לתת קרדיט, שכן אי מתן קרדיט מפר את זכויות היוצרים (ע"א 2790/93 -Robert E. Eisenman ואח' נ' אלישע קימרון).

2.4.2

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

2.5.

תוכן האתר: מעבר לעיצוב וקוד התוכנה, האתר יכול להכיל תכנים: טקסטים, תמונות, מוסיקה וסרטונים, בין אם שנוצרו על ידי המפתח או על ידי הלקוח. כאשר המפתח הוא מי שמזין את התכנים, באחריותו לבחון את מהות התוכן והוא מי שאחראי על התוכן שהוא הזין; לכן, נאסר עליו להעתיק מאמרים או תכנים מאחרים (א 26386-09-09 גל מור נ' חן אזולאי). כאשר מתבקש המפתח לשנות או לייצר מאמרים עבור הלקוח, הוא לא יכול לבצע הלחמה, הדבקה והעתקה, אלא עליו לייצר תוכן מקורי. כמובן, שאין בכך מניעה שהוא יצטט בצורה הוגנת מקורות תוך מתן הפניה (סעיף 19 לחוק זכויות יוצרים) או ישתמש בתכנים של אחרים על מנת למתוח עליהם ביקורת (תא (י-ם) 8107/01 זום 77 בע"מ נ' הארץ). בכל הנוגע למידע כללי על אודות זכויות יוצרים מומלץ לקרוא את מדריך הכיס שלי בנושא זכויות יוצרים.

2.6.

אם לתת לאחרים לגעת בקוד שלי? אחד האינטרסים המובהקים של מפתח הוא לשמור על הלקוח קרוב אליו ככל האפשר, ולכן מפתחים רבים מעוניינים לאסור על לקוחותיהם להשתמש בשירותים של אחרים על מנת לשנות או להתאים את האתר; חשוב לזכור שהדבר אפשרי בחוזה רק כאשר מדובר בקוד שהוא בבעלותו הבלעדית של המפתח, אולם גם במקרה כזה, ספק אם ניתן יהיה לאכוף הגבלה כזו. ראשית, סעיף 24 לחוק זכויות יוצרים קובע כי "העתקה של תוכנת מחשב או עשיית יצירה נגזרת ממנה, מותרת למי שמחזיק עותק מורשה של תוכנת המחשב, למטרות אלה ובהיקף הדרוש לכך:  (1)  שימוש בתוכנת המחשב למטרות שלשמן נועדה, ובכלל זה תיקון שגיאות בתוכנת המחשב או התאמתה למערכת מחשב או לתוכנת מחשב אחרת;  (2)  בדיקה של אבטחת המידע בתוכנת המחשב, תיקון פרצות באבטחת המידע והגנה מפניהן;  (3)  השגת מידע הדרוש לצורך התאמת מערכת מחשב או תוכנת מחשב אחרת, המפותחת באופן עצמאי, כך שתוכל לפעול עם תוכנת מחשב זו". כלומר, מותר ללקוח לשנות את התוכנה על מנת לתקן שגיאות בה או להתאים אותה למערכת מחשב אחרת (כדוגמאת Facebook Connect); לכן, ספק אם ניתן יהיה להגביל בצורה משמעותית את הזכות הניתנת ללקוח. לכאורה, ניתן לקבוע בהסכם כי על אף האמור בסעיף 24 לחוק יאסר על הלקוח לבצע שינויים; אולם, כשם שספק אם ניתן להגביל את זכותו של המשתמש לשימוש הוגן, ספק אם ניתן להגביל זכויות צרכניות אחרות בהסכם (Elkin-Koren, Niva, Making Room for Consumers Under the DMCA).

3. פיתוח ולוחות זמנים:

הסוגיה המשמעותית ביותר שעולה בעת שעובדים כמפתח היא לוחות הזמנים. למפתחים יש נטיה קיימת להערכת יתר בנוגע ליכולתם לסיים פרויקטים מסובכים מהר מדי, ואלה מתחייבים בהצעת המחיר (שכאמור, היא הסכם מחייב לכל דבר) התחייבות לסיים פרויקטים בתוך "14 ימי עסקים" או "7 ימי עבודה" כאשר אין ביכולתם לעמוד בכך; כיוון שהם יודעים שאין ביכולתם לעשות כן, הם מצרפים סעיף להצעת המחיר שאומר שמותר להם לאחר או להתעכב אם הדבר נגרם כתוצאה מעיכוב של צד שלישי (לדוגמא, המעצב הגרפי). אלא, שבפועל ספק אם דבר כזה יעמוד. בתי המשפט פסקו כי איחור בלוחות הזמנים למסירה של מוצר או שירות הם הפרה מהותית של ההסכם, שמאפשרת ביטולו וקבלת פיצויים (עא  6319/05 קנדרה (ישראל) בע"מ נ' מנהל מקרקעי ישראל) ואף אם התשלום מותנה בעמידה בלוחות הזמנים, הרי שגם אז אי תשלום יכול שיהווה הפרה (תא 912/92 אליעזר בן יעקב נ' מ.ב.י מ.ה בע"מ). כמו כן, בתי המשפט פסקו כי אם גורם העריך שקבלן משנה לו הוא זקוק לביצוע פעילות כלשהיא, כמו מעצב חיצוני, מאחר, הרי שעל המפתח לצפות לאיחור כזה ולהכניסו במועדים המפורטים בהסכם (עניין קנדרה הנ"ל, בו בית המשפט קבע כי "משהסכימה קנדרה ללוח הזמנים שנקצב בחוזה הפיתוח אין היא יכולה להישמע עתה בטענה כי מדובר בסד זמנים בלתי סביר").

3.1.

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

3.2.

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

3.3.

פיצויים: גם אם איחור בביצוע ההזמנה גרם להפרת החוזה, עולה השאלה מהו סוג הפיצוי שינתן ללקוח בגין איחור. במידה והוסכם בהסכם על פיצוי מוסכם, אז ניתן להסתפק בפיצוי זה ולהורות על תשלום הפיצוי המוסכם (לדוגמא, 150 ש"ח על כל יום איחור) וזאת כל עוד ההסכם לא בוטל (עא 1/84 ברדה נתן נ' שמעון ורוזה סטרוד, פ"ד מב(1) 661), אלא שגם אם יבוטל החוזה בעקבות הפרתו, הרי שעדיין ניתן יהיה לתבוע פיצויים מוסכמים. בית המשפט העליון פסק כבר כי "אילו הייתי מקבלת את הדעה שהחוזה הוא חוקי, הייתי מחייבת את המערערת בתשלום כל סכום הפיצויים המוסכמים מראש (כנרמז לעיל)…  כידוע, פורש הסעיף על דרך הצמצום, ואפילו אם נמצא הסכום מוגזם, התוצאה היא הפחתתו עד לקצה הגבוה של גבול הסבירות" (עא 311/78  הניה הווארד נ' נסים מיארה, פ"ד לה(2) 505). מעבר לכך, על פי חוק החוזים (תרופות בשל הפרת חוזה), לאחר ביטול החוזה זכאי הצד הנפגע לתבוע את הוצאותיו והפסדיו. במקרה של בניית מערכת אינטרנט, מדובר על הפסדי ההכנסות (אם יוכל להוכיח כאלה, ולעניין הוכחת נזקים באחסון אתרי אינטרנט ראו תא (י-ם) 16360/08 מזרחי רועי נ' או.אמ.סי (א.א.י) תקשורת מחשבים בע"מ), הפרשים בין עלות המפתח הנוכחי לעלות המפתח המפר, הוצאות משפטיות.

4. אפיון האתר:

אולי השאלה החשובה ביותר היא כיצד צריך להראות אפיון האתר; כאן חשוב לשים לב לדמיון הרב בין בניית אתר לבניית דירה, הן במישור המילולי (השימוש בפועל "בניה"), הן בכך שרוב פסקי הדין המאוזכרים נוגעים לתחום מכר הדירות והן לכך שבשני המקרים מדובר בהשקעות גדולות ומשמעותיות (מעבר לכך, פסק דין בנושא פיתוח תוכנה לקוי משתמש בנרטיב של ליקויי בניה: א 5234/05 מנחם מיטלמן י.מ. מחשבים פיתוח וישום מערכות מידע נ' מוסדי עולם בע"מ). מעבר לכך, הדמיון חשוב: כשם שאדם לא ירכוש דירה בלי לדעת מספר תנאים משמעותיים: גודלה, מיקומה, הקומה בה היא נמצאת, זהות הבעלים שלה, כמות כיווני האוויר ורמת הגימור, כך גם חוזה לבניית אתר חייב לכלול אפיון ראשוני העומד על אותה רמה של מסוימות משפטית (ובית המשפט עשוי לצוק תוכן לתוך האפיון אם לא, עא 4628/93 מדינת ישראל נ' אפרופים שיכון ויזום (1991) בע"מ, מט (2) 265); כלומר, עם כל הכאב שבדבר, על המפתח להעמיד לרשות הלקוח אפיון מספיק במועד החתימה על הזמנת העבודה או ההסכם (ולעניין דירות יש את צו מכר דירות (טופס של מפרט) המפרט בדיוק מה צריך להיות בדירת מגורים). יש לעשות כמיטב היכולת על מנת להבהיר ללקוח מה מכיל כל שלב בתהליך בניית האתר, ולדאוג להצמיד את התשלומים לחלקים אלה; אם למדנו דבר אחד מעניין מיטלמן, זה שהגדרות השלבים צריכות להיות מדויקות על מנת להמנע ממחלוקת לאחר מכן לגבי מהו "שלד תוכנה"; במקרה כזה, יש גם להבהיר מה בדיוק יכיל האתר ומה הלקוח צריך לעשות על מנת לסייע בתהליך האפיון.

4.1.

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

4.2.

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

4.3.

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

בית המשפט פסק, בעניין עא 8151/98 שטרנברג נ' צ'צ'יק, פד נו(1), 539 כי "אי-רישומו של אירוע הפריקה שאירע במהלך הניתוח מנע מן המערערת את האפשרות להוכיח מה טיב האמצעים שננקטו, אם בכלל, על-מנת למנוע פגיעה בעצב ולחץ מופרז על העצב במהלך הניתוח. רישום מסודר ומלא של האירוע היה עשוי לשפוך אור על השאלה אם התרשלו המשיבים בעת שביצעו את פריקת המפרק ואם התרשלות זו הביאה לפגיעה בעצב. לפיכך מועבר אל המשיבים הנטל להוכיח כי לא הייתה כל התרשלות במעשיהם, או כי לא התרשלותם היא שהסבה את הנזק למערערת". לכן, מומלץ לעבוד עם מערכת ניהול קוד כלשהיא אשר תשמור את המידע, ותייצר גיבויים ומעקב אחר שינויים.

4.4.

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

4.5.

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

5. לאחר סיום העבודה:

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

5.1.

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

5.2.

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

5.3.

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

5.4.

אחסנה, כן או לא: אחת השאלות שנוגעות לסיום העבודה מול הלקוח היא האם להמשיך לכבול אותו לשירותייך ולגבות עבור אחסנת האתר שלו, כך שהמפתח ימצא את עצמו מספק גם שירותי אחסון וימשיך להרוויח על הלקוח לאורך תקופה מסוימת (ולעניין זה, כדאי לקרוא את הפוסט המצוין של רויטל סלומון על הקמת אתרי אינטרנט בישראל); מעבר לכך, מפתחים רבים כורכים את בניית האתר באחסונו על ידם ומציעים "אחסון חינם" או מנסים להשתמש במערכת כמרכז רווח נוסף. כאן, עולה השאלה האם כדאי למפתח לאחסן את האתר עבור הלקוח, בלי קשר לשאלות טכניות: ראשית, מבחינה טכנולוגית אכן הוא בעל שליטה מלאה בקונפיגורציה ויכול להבטיח שהלקוח לא יוכל לגרום תקלות ואף לתקן את התקלות בצורה המהירה ביותר. אולם, מנגד עומדת השאלה החשובה: האם כבילת הלקוח היא משהו שמסייע למודל הרווח שלו; כלומר, טובת הלקוח מתאזנת בין השאלה האם הטיפול יהיה מהיר יותר (שכן, תמיד ניתן לאפשר למפתח גישה מהירה לשרת, ומנגד זה לא ימהר לתת לאחרים גישה לשרת שלו) ובין אבדן השליטה במקרה של סכסוך בין המפתח ללקוח. ראיתי, והייתי מעורב, במספר מקרים בהם מפתח האתר החליט לו שלאור סכסוך מסוים בינהם הוא הסיר את האתר וגם במקרים בהם מזמין העבודה החליט לבוא בדרישות מוגזמות והפסיק את תשלומי האחסון שלו עקב סכסוך עם מפתח האתר. לשיטתי, ההפרדה בין האחסון לבין פיתוח האתר משרתת את טובת הלקוח בצורה מובהקת: על המפתח לייעץ ללקוח על הדרך בה יאוחסן האתר על מנת שימנע מלפול במלכודות של שרלטנים (וראו את הפוסט של יובל דרור על אחסון בבזק בינלאומי ואת הפוסט של ניצן ברומר על אחסון אתרים בישראל). אם החשש הוא בצורה של אבדן הכנסות, ניתן תמיד להפנות את הלקוח באמצעות חשבון Affiliate שיזכה אתכם בחלק מההכנסות או לסכם על שיתוף פעולה עם חברת אחסון, אלא חשוב שכמו ששם הדומיין ירשם על שם הלקוח על מנת למנוע סכסוכים בעתיד (וראו לעניין זה את ת"א 46775-10-10 נגה קום בע"מ נ' אריאל פלד) כך גם האחסון צריך להיות רשום על שמו ולהיות משולם ישירות על ידו.

6. תשלום וגביה.

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

6.1.

קניין רוחני: ניתן להשתמש בהוראות חוק זכויות יוצרים על מנת להבטיח את התשלום. כאמור, על מנת להשתמש בקניין רוחני יש צורך ברשיון. ולכן, הסכם הזמנת העבודה הוא רשיון לשימוש במערכת התוכן; סעיף 35 לחוק זכויות יוצרים קובע כי "ביצירה שנוצרה לפי הזמנה, הבעלים הראשון של זכות היוצרים בה, כולה או חלקה, הוא היוצר, אלא אם כן הוסכם אחרת בין המזמין והיוצר, במפורש או במשתמע"; כלומר, אם המפתח הוא המרשה, הוא יכול לקבוע כי התנאי להתחלת הרשיון הוא התשלום במועד. אי תשלום יגרור לא רק את הפרת ההסכם אלא גם הפרת זכויות יוצרים ויאפשר, לפי סעיף 56 לחוק, פיצוי בסכום של עד 100,000 ש"ח.

6.2.

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

6.3.

שימוש בהוצאה לפועל: כפי שהובהר קודם, אחת הסיבות לדרישת החתימה על הצעת המחיר היא על מנת לאפשר את הבאת המסמך להוצאה לפועל כאמור בסעיף 81א1 לחוק ההוצאה לפועל ולביצועו כמו כל שטר. ככל שהלקוח ידע כי הוא חשוף לכך, הוא יטה לשלם מהר יותר. אולם, בטרם פותחים בהליכים מסוג זה על המפתח לתת התראה מראש, בכתב, של 30 ימים, מה שעשוי לעבב את תהליך הגביה. כמו כן, מרגע שהוגשה התנגדות לביצוע ההתחייבות בהוצאה לפועל (לדוגמא, במקרה בו טוען הלקוח כי האתר לא סופק לו), בית המשפט נוטה לאפשר את עיכוב העניין ולהעבירו לבית המשפט אף במקרים קלושים ביותר (לדוגמא, תט (ת"א) 207764-09  פלאפון תקשורת בע"מ נ' יריב מינאי) בהתחשב בהלכות שנפסקו בבית המשפט העליון בנושא בקשות רשות להתגונן אף במקרים בהם מדובר בהגנה קלושה (ע"א 9654/02‏ חב' האחים אלפי בע"מ נ' בנק לאומי לישראל, פ"ד נט(3) 41).

7. סיכום.

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

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

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

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