[קובץ התביעה (זהירות, מסמך DOC)]

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

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

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

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

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

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

2.
שני השירותים האלו החזיקו זמן רב כבכירים בשוק, אבל לא לנצח. הוטמייל פינה את מקומו לשירות שהושק שמונה שנים לאחריו: ג'ימייל של גוגל, וICQ הפכה להיות עוד אות בספר ההיסטוריה שכמעט ולא תזכר, כאשר בני הנוער מתכתבים באמצעות Facebook Messenger וWhatsapp. גם המספרים שנראו לנו אז אסטרונומיים היום נשמעים מגוחכים; Whatsapp, שמספקת היום שירות מסרים מהירים, מוערכת בשווי של 11,000,000,000 דולר, פי 40 ומעלה מהשווי של ICQ. אבל הערכת השווי של Whatsapp אינה יתומה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Contrary to Oracle, copyright law does not confer ownership over any and all ways to implement a function or specification, no matter how creative the copyrighted implementation or specification may be. The Act confers ownership only over the specific way in which the author wrote out his  version. Others are free to write their own implementation to accomplish the identical function, for, importantly, ideas, concepts and functions cannot be monopolized by copyright.

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

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

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

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

"the structure, sequence and organization of a computer program may (or 12 may not) qualify as a protectable element depending on the “particular facts of each case” and  always subject to exclusion of unprotectable elements"

כלומר, גם על מבנה התוכנה, שיכול לקבל הגנה בזכויות יוצרים אם הוא מקורי ויצירתי (לדוגמא א 64269/07 שטיינברג נ' סמבירא, ורעא 39695-05-10 נהון נ' נוריאל בישראל), עומדים הכללים בבסיס חוק זכויות יוצרים. אם תוכנת מחשב תקבל הגנה כמו יצירה ספרותית רק אם היא מקורית ויצירתית, הרי שממשק התוכנה (API) הוא פונקציונאלי, ואינו מכיל מקוריות ולכן יהיה ניתן להשתמש בו, ורשיון זכויות היוצרים לא יחול על תוכנות שמתממשקות אליו.

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

המשמעות של גישה זו בפועל, היא שממשק תכנות או פיתוח יוצר שכבה של הפרדה בין התוכנה המקורית לבין התוכנה שנמצאת סביבה. גישה זו מלווה מספר החלטות שאפשרו הנדסה חוזרת לצורך יצירת ממשקים בפסיקה האמריקאית (נניח, Sega Enterprises Ltd. v. Accolade Inc. U.S. Court of Appeals (October 1992); כלומר, יכול להיות שהרשיון עצמו אולי לא מרשה לעשות משהו, אבל החוק חזק מהרשיון, ויש מקרים בהם החוק בכלל לא נותן הגנה בזכויות יוצרים. בכך, יכול להיות, תפתר אחת הבעיות הגדולות שהיו בתחום הקוד הפתוח.

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

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

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

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

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

Motorola, כמובן, נתבעת על ידי Microsoft על הפרת פטנטי שקר-כלשהו במערכות ההפעלה Android. הענקים ברדמונד ציפו, בצורה כלשהיא, שMotorola יתפשרו ויעדיפו לתת רשיון צולב לפטנטים אך קיבלו הפתעה שלא תאמן: במקום לקבל פשרה קרירה וחשאית, הם קיבלו את הנתבעת החדשה שלא רצו לתבוע עד היום.

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

זו לא הפעם הראשונה שGoogle עושה כן, גם את אתר YouTube זו רכשה על מנת לנהל תביעות כנגדו.

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

[אגב, בתור הבעלים הגאה של מכשיר Motorola שמריץ Android כבר שבוע ומשהו, אני חייב לומר: פטנטים או לא פטנטים, דבר לא מתחרה היום בAndroid מבחינת מערכת הפעלה ניידת, וזו הבעיה האמיתית. י.ק]

מסיבה זו תאגידים כגון Microsoft נוטים לראות פטנטים בתוכנה כשוט אסטרטגי; לדוגמא, מיקרוסופט פנתה ליצרנית הטלפונים HTC עם הצעת פשרה נדיבה, לפיה HTC תשלם 5$ עבור כל מכשיר אנדרויד שהיא תמכור. העניין הוא שמיקרוסופט מתחרה ישירות עם אנדרויד באמצעות "Windows Phone", מערכת ההפעלה של מיקרוסופט לטלפונים סלולריים.לכן, מיקרוסופט מרוויחה יותר כסף עבור כל מכשיר שהיא לא מוכרת, אלא שהמתחרים שלה מוכרים, מאשר כאשר היא כן מוכרת מכשיר. אבל, כמובן, זו הבעיה ולא הפתרון [ושוב, יש סיבות מדוע מיקרוסופט לא תובעת את גוגל ישירות.

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

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

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

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

הדרך היחידה לנצח היא להלחם.

[פורסם במקור באנגלית]

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

1.
המקרה המדובר כלל אינו תיאורטי, הוא התרחש לתקופה קצרה מאוד בחודשים האחרונים באמצעות BitCoins; שירות מטבעות בקוד-פתוח מבוסס עמיתים (Peer to Peer); נוצרה בורסה שהחליפה בין מטבעות BitCoin לבין מטבעות אחרים ואף אתרים מסוימים קיבלו תשלום במטבע זה. הרעיון של יצירת מטבע שכוחו תלוי אך ורק באמון הקהילה בו מייצר חברה וכלכלה יציבה יותר, שאינה תלויה בממשלות מרכזיות [וראו סקירה יפה על המטבע].

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

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

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

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

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

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

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

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

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

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

1. מדוע הסלולר מפחד מקוד פתוח?
גם Apple וגם Microsoft מפחדות מהקוד הפתוח. Apple לאחרונה אסרה על נגן המדיה פתוח הקוד VLC להשתתף בחגיגה הסלולרית כיוון שזה שוחרר תחת רשיון הGPL (וסיפור משעשע הרבה יותר עם XPilot) וכך גם מיקרוסופט עם הסכם המפתחים של Windows Phone 7 שקובע כי תוכנות המכילות רכיבי קוד פתוח לא יכולות להיות מופצות באמצעות השוק (מה שגרם למספר מפתחים לשנות את מודל הרישוי שלהם). אלא שהאיסור של מיקרוסופט ושל אפל נובע מבורות בנוגע לרשיון יותר מכל.

2. מדוע ההבנה של מיקרוסופט של הרשיון שגויה?
מיקרוסופט אוסרת על הפצה של תוכנות המכילות רכיבים המורשים תחת מה שהם קוראים לו "Excluded License", שהוא רשיון שדורש כתנאי לשימוש, שינוי ו\או הפצה הכפופה לרשיון, שהתוכנה או תוכנות המשולבות איתה יהיו (1) זמינות בקוד מקור; (2) מורשות לשינוי לצורך הכנת יצירות נגזרות ו(3) מופצות הלאה ללא כל תמורה (סעיף 1.l לרשיון). אלא, שרשיונות הקוד הפתוח מבוססים על הפצה ואינם חלים כאשר אין הפצה של תוכנה, ולכן לדוגמא, שירותי ענן רבים משתמשים בתשתיות פתוחות-קוד. סעיף שאוסר על שימוש ברכיבי תוכנה אשר ההפצה שלהם מחייבת שחרור של הקוד חל על כל מה שמוגדר, על ידי מיקרוסופט, כאפליקציה: אפליקציות WM6.x או אפליקציות Windows Phone 7. במידה וחלק מרכיב האפליקציה מבוסס צד-שרת, מעניין מאוד מה יקרה כאשר השרת יבוסס על קוד פתוח?

3. מדוע איסור קוד פתוח פוגע במחשוב הענן?
המקרה הבא הוא תיאורטי לגמרי: פייסבוק, שמבוססת על תשתית פתוחת-קוד, מפתחת אפליקציה לWP7 אשר תתמשק לפרופיל האישי. חלק מהרכיבים בשירותיה של פייסבוק (אך לא בתוכנה) מפותחים תחת רשיונות שאוסרים הפצה אלא ברשיון קוד פתוח. למרות שהרכיבים הרלוונטים לא מופצים כלל, הם נכנסים תחת הסעיף הדרקוני והחזק מדי. גם אם זה נשמע תיאורטי ולא רלוונטי, אני רוצה לקחת דוגמא אחרת שתדגים את האבסורד: אחד הפרוייקטים השאפתניים והמוצלחים ביותר בתולדות האנושות הוא ויקיפדיה; אנציקלופדיה חופשית שמאגדת את קורפוס הידע האנושי. התכנים באנציקלופדיה משוחררים ברשיון Creative Commons, שמאפשר את ההפצה בצורה חופשית, כל עוד כל שינוי שנתרם מופץ גם הוא תחת אותו רשיון. כעת, יבוא מפתח פלוני ויפתח אפליקציית ויקיפדיה לWP7; תבוא מיקרוסופט ותטען כי סעיף 5.e להסכם אוסר על הפצת אפליקציות אשר החומרים המוצגים בה משוחררים תחת רשיון מסוג זה ותגנוז את ויקיפדיה מחנות האפליקציות שלה.

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

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

הקדמה: מפתחי ווב פרילנסרים הם כשל שוק ידוע. תחום פיתוח אתרי האינטרנט בארץ נחלק לשתי קבוצות, שבצורה מצחיקה הקטביות בינהן היא כה משמעותית עד שלא מדובר במתחרים אלא בשווקים משלימים. בקבוצה הראשונה נמצאות חברות כמו דרונט, אידיאולוג'יק, 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, תשתמו בו בבקשה כדי לחלוק את הידע עם חברים.