מכרת רישיון תוכנה ללקוח Enterprise אוסטרלי גדול אחרי שאנשי המכירות שלך עבדו כמה חודשים על העסקה, ומדובר בסכום מאוד יפה עבורך. אמנם המו"מ היה קשוח ולקח הרבה זמן, והעסקה כמעט נפלה כמה פעמים, אבל בסוף חתמתם והלקוח התחיל לפרוס את התוכנה בשרתים שלו.
ואז מגיע התשלום, שנמוך משמעותית ממה שציפית. אתה בודק מול מחלקת הכספים שלך מה קורה, ושם מסבירים לך שבזמן שהתנהל המו"מ, שער החליפין של הדולר האוסטרלי ירד משמעותית ולכן גם התמורה בשקלים היא נמוכה משמעותית. אז נכון שהסכום בהצעת המחיר היה טוב בזמנו, ובהצעת המחיר היה רשום שהוא בתוקף רק למשך 30 ימים, אבל בלהט המשא ומתן לא חשבתם לעדכן את המחיר כי זה יכול היה לפגוע בעסקה.
אחרי חודשיים סמנכ"ל התפעול שלך מעדכן אותך שכמעט חצי ממחלקת התמיכה שלכם עוסקים עכשיו באותו לקוח אוסטרלי, וזה מתחיל לפגוע בשירות ללקוחות אחרים. צריך דחוף לגייס עובדים חדשים למתן שירותי תמיכה, והתהליך כמובן ייקח זמן. אתה בודק למה פתאום הצורך בתמיכה של הלקוח עלה בצורה כל כך חדה, ומגלה שהלקוח בדיוק מיזג לתוכו חברת ענק אחרת והיקף הפעילות שלו עם התוכנה שלך הוכפל. המחיר שנתתם עבור תמיכה היה fixed price, ולא לקחתם בחשבון שהלקוח יצמח בצורה כל כך חדה כל כך מהר. אבל אין מה לעשות, כי זה עדיין אותו לקוח וההסכם מחייב אתכם לתת להם שירותי תמיכה.
פתאום כל העסקה הזאת נראית הרבה פחות טוב, ולאט לאט הופכת לנטל על החברה. כי לא לקחתם בחשבון כל מיני גורמים שהשפיעו על כדאיות, ועכשיו אתם תקועים עם העסקה הזאת. אולי אפילו לכמה שנים. ואין לך אפשרות לבטל את ההסכם עקב חוסר כדאיות.
אז כשאתה מוכר תוכנה ללקוח, במיוחד כשמדובר בתוכנה On Prem, יש מספר נקודות חשובות שכדאי להסדיר בעסקה כדי להימנע מהתרחישים שתיארתי ומתרחישים שונים נוספים שהופכים את העסקה להפסד עבור החברה.
נקודות חשובות בהסכם רישיון עם הרוכש
כשאתה מסדיר את אופן השימוש בתוכנה שלך בהסכם רישיון תוכנה, חשוב להתייחס לנקודות הבאות, לפי הצורך:
- התוכנה – מה היא התוכנה ומה היא בעצם עושה? עדיף להבהיר מהו המקסימום שאתה מוכן להתחייב לו.
זה לא המקום לקחת טקסט שיווקי שאולי נשמע יפה אבל קרוב לוודאי נותן תיאור אופטימי מדי ליכולות של התוכנה שלך. אם תיארת את התוכנה שלך בתור Insanely Great, כדאי מאוד שזה יבוא עם תעודה מפסיכיאטר בעל שם.
האם ההסכם הוא לגבי תוכנה ספציפית או לגבי כל התוכנות שלך (כולל תוכנות עתידיות) או לגבי כל תוכנה מסוג מסוים שאתה מייצר?
האם אתה מעביר לצד השני להסכם קוד מקור או רק גרסה סופית מקומפלת של התוכנה? לרוב עדיף להימנע מהעברת קוד מקור עד כמה שאפשר בגלל הסיכון שהקוד ידלוף, אבל בסוף זה תלוי בנסיבות המו"מ או ברגולציה שחלה על הקונה מבחינת אבטחה.
האם אתה רשאי לבצע שינויים בתוכנה כרצונך? לך כמוכר כמובן עדיף שיהיה לך כמה שיותר חופש בנושא, אבל אפשר להסכים להגבלות הגיוניות – למשל שלא תעשה שינוי כיוון מוחלט מתוכנת גרפיקה לבסיס נתונים.
האם אתה חייב להעמיד לרשות הצד השני את כל הגרסאות של התוכנה שתפתח בתקופת ההסכם? אם כן, מתי? גם כאן עדיף לך כמה שיותר חופש.
- תשלום – כמה ואיך הרוכש צריך לשלם לך? תמחור תוכנה זה מדע בפני עצמו.
איך התשלום יתבצע - האם זה יהיה סכום קבוע, תשלומים תקופתיים, אחוזים (וממה בדיוק – מהכנסה ברוטו או מרווחים או ממשהו אחר), או שילוב כלשהו?
האם ישלמו לך מראש, או בתשלומים? בעסקאות מסוג זה הנטייה היא לתשלום מראש.
האם אתה מוכר רישיון "לכל החיים" או לתקופה מוגבלת (למשל שנתי)? אם לכל החיים, חשוב להבהיר מה נחשב לתקופת חיים של התוכנה – למשל כל עוד אתה מספק תמיכה או ממשיך לפתח את אותה גרסה ראשית. שתיקה לגבי מה זה תקופת חיים תוביל הרבה מאוד פעמים למשבר עם לקוחות כשתפסיק לפתח את התוכנה או לספק לה שירותי תמיכה.
באיזה מטבע יתבצע התשלום, ואם במט"ח אז לפי איזה שער חליפין? בעסקאות גדולות ובסביבה הכלכלית של היום גם הפרש של מספר ימים יכול לשנות משמעותית את הסכום, שלא לדבר על תקופה של שבועות או חודשים בין מתן הצעת המחיר לבין חתימה על הסכם סופי ותשלום בפועל, ולכן חשוב שתהיה ברור לגבי התמורה שאתה מצפה לקבל.
אם הייתם קובעים שהתשלום לפי השער ביום החתימה, או בשקלים, הירידה של הדולר האוסטרלי הייתה בעיה של הלקוח ולא שלכם.
אם אתה נותן ללקוחות רישיונות "ללא הגבלה", קח בחשבון שלפעמים לקוחות מתמזגים או נרכשים, וכך רישיון שנתת במחיר נמוך לחברה קטנה פתאום הופך לרישיון של חברה גדולה שהייתה יכולה לשלם הרבה יותר ושצריכה פתאום הרבה יותר תמיכה. במקרה כזה אפשר לקבוע שהרישיון בתוקף כל עוד אין החלפת שליטה בלקוח, או שבהחלפת שליטה דנים מחדש בתמורה לפי גודל החברה החדש.
אז ברגע שהלקוח מיזג לתוכו חברה גדולה, היה לכם בסיס לפתוח מחדש את המחיר.
- רישיון שימוש – מה בדיוק מותר לרוכש לעשות עם התוכנה? עדיף לך לאשר רק את השימושים שעבורם התוכנה נבנתה, ושדרושים לרוכש, אחרת נושא התמיכה יהפוך להרבה יותר מאתגר.
האם הרוכש יכול להעביר את הרישיון שלו למישהו אחר? לך כמובן עדיף שלא, אבל יש לקוחות גדולים שדורשים שהרישיון יהיה ניתן להעברה בתוך קבוצת חברות שהם חלק ממנה.
- בדיקת יכולות – לקוחות גדולים הרבה פעמים יבקשו את האפשרות לבדוק את התוכנה ולראות האם היא אכן מתאימה לצרכים שלהם.
במקרה כזה צריך לקבוע בדיוק איך יתבצע תהליך הבדיקה, כמה זמן הוא ייקח, ומה ייחשב לתוצאה מוצלחת.
אתה רוצה לקבוע שהדרישות לעמידה במבחן יהיו כמה שיותר פשוטות, ישירות וספציפיות, כדי שלא תהיה מחלוקת לגבי התוצאה שהתקבלה.
כדאי גם לקבוע שאם לא ניתנה תשובה תוך הזמן הקבוע, זה ייחשב כמעבר חיובי של המבחן.
תשתדל לא לתת תקופת מבחן בחינם. עדיף שתקבל תשלום כלשהו מראש, ואז תן ללקוח אפשרות לזמן מוגבל לבטל את הרכישה. כך תהיה יותר בטוח שבעלי הסמכות להוציא כסף אכן אישרו את העסקה, וזה לא סתם ניסוי של מישהו שרוצה לשחק עם תוכנה חדשה אבל אין לו סמכות לאשר עסקה.
- מצגים – לגבי אילו היבטים של התוכנה אתה כן מוכן להתחייב? כמובן שעדיף לך שיהיו כמה שפחות מצגים, כי כך האחריות שלך תהיה מינימלית.
האם אתה מתחייב שהתוכנה עומדת בדרישות מסוימות, כגון ביצועים או יכולת לבצע פעולות מסוימות 100% מהזמן? שוב, זה לא המקום לכתוב טקסט שיווקי על התוכנה המדהימה והמהפכנית לחלוטין שלך.
בבקשה אל תכתוב שבתוכנה שלך לא יהיו שום באגים. זה פשוט לא מציאותי.
- קניין רוחני – מי בעל הזכויות בכל הקניין הרוחני הקשור בתוכנה (כולל מה שנוצר במהלך תקופת ההסכם)? כמובן שעדיף לקבוע במפורש שכל הזכויות הללו הן שלך. במקרים נדירים של שת"פ לצורך פיתוח טכנולוגי אפשר לדון בחלוקה של זכויות בקניין הרוחני לגבי פיתוחים חדשים שנוצרו כחלק מהשת"פ.
האם אתה רשאי לבצע שינויים בקניין הרוחני (למשל שינוי בלוגו, בשם המסחרי וכו'). עדיף לך שזה יהיה לגמרי בידיים שלך, אבל מותר לקבל הגבלות הגיוניות מסוימות – למשל לא לשנות את השם המסחרי למילים גסות או לשנות את הלוגו למשהו שנראה כמו חלק מאנטומיה נשית.
- נאמנות על קוד מקור – לפעמים לקוחות גדולים שרוכשים ממך הרבה רישיונות לתוכנה ירצו להיות בטוחים שיוכלו להשתמש בתוכנה גם אם אתה כבר לא תהיה בתמונה – למשל בגלל פירוק החברה שלך או הפסקת פיתוח התוכנה.
לכן לקוח כזה יבקש כי קוד המקור של התוכנה יופקד בנאמנות אצל גוף מקצועי כלשהו, כך שאם אתה תיעלם הלקוח יוכל להמשיך בתחזוקה ופיתוח של התוכנה שרכש.
אם זה בא כדרישה לעסקה מהותית, לדעתי מדובר בדרישה שבהחלט כדאי לשקול אותה ברצינות.
כמובן שהנאמן צריך להיות גוף שזה עיסוקו העיקרי ושאין לו היסטוריה של דליפות או בעיות טכניות.
בנוסף, במקרים כאלה חשוב מאוד להבהיר למי בדיוק ובאילו מקרים תהיה גישה לקוד המקור, מתי בדיוק אותו לקוח יוכל לעשות שימוש כלשהו בקוד, ומה בדיוק מותר לו לעשות עם הקוד.
- איסוף ושימוש במידע – אם התוכנה אוספת מידע כלשהו במהלך ההתקנה, השימוש, ההסרה, או בכל מצב אחר, חשוב ליידע על איסוף מידע זה ולהבהיר איזה מידע בדיוק התוכנה אוספת, למי שייך המידע, האם המידע מועבר אליך, ולמי יש אילו זכויות שימוש במידע. זה בוודאי חשוב מאוד אם התוכנה אוספת מידע אישי.
- שינויים בתוכנה – כל עוד התוכנה שלך נמצאת בשימוש, אתה כמעט בוודאות תמשיך לפתח אותה. אז כדאי להסדיר כבר בהתחלה איך בדיוק השינויים האלה ייקלטו אצל הלקוח.
מי יכול לבצע שינויים בתוכנה? כמובן שעדיף שרק לך יהיה מותר לשנות את התוכנה שלך.
מי בעל הזכויות בשינויים? שוב, אתה רוצה שכל הזכויות פה יהיו רק שלך, אפילו אם מישהו אחר מבצע את השינויים עבורך.
האם אתה חייב לבצע שינויים שיתבקשו על-ידי המשתמש? ייתכן ולקוחות גדולים יבקשו תמיכה והתאמה לצרכים שלהם, וזה לגיטימי כל עוד התמורה מתאימה לך.
על חשבון מי יתבצעו השינויים? אם מדובר בשינוי שהתבקש על-ידי המשתמש, כמובן עדיף שהמשתמש ישלם על השינוי.
- תהליך בדיקת שינויים – האם קיים תהליך של בדיקת השינויים? אם כן - מהו התהליך, ומי מאשר בסוף את השינוי ופריסתו אצל הלקוח?
על חשבון מי תהליך הבדיקה מתבצע? אם השינוי היה על חשבון המשתמש, הגיוני שגם הבדיקות יהיו על חשבונו.
- תמיכה ותיקוני באגים – התוכנה שלך אף פעם לא תהיה מושלמת. תמיד יהיו באגים כלשהם, או תכנון לא ברור או סוגיה אחרת שיוצרת בעיות למשתמשים. אז אתה צריך להחליט כבר בהתחלה אילו דברים אתה מתחייב לתקן. לגיטימי למשל שתתקן באג שמונע הפעלה של התוכנה. לגיטימי פחות שתטפל בתלונה של משתמש קצה על כך שהפונט בתפריט הוא לא מספיק יפה.
אילו תיקונים, אם בכלל, חייבים לבצע בתוכנה, ובאילו מקרים? אפשר לחלק את התלונות של המשתמשים למספר קטגוריות – מהכי חמורה (לא ניתן להשתמש בתוכנה) ועד להכי פחות חמורה (תלונה על משהו שלא מפריע לשימוש סביר) - ואז להחליט באילו קטגוריות אתה מוכן לטפל. חשוב כמובן גם להבהיר את אופן הגשת התלונות של המשתמשים – האם זה יהיה פתיחת טיקטים במערכת שלך, או באופן אחר – אתה לא רוצה שלקוחות ייקחו יוזמה וישלחו דיווח על באג דרך עמוד הפייסבוק שלך כי לא מצאו דרך אחרת לעשות את זה והנושא לא הוסדר מולם.
או שאפשר לקבוע מראש שהתוכנה מועברת "AS IS" ואין לך שום אחריות לגביה.
כמובן שאם הלקוח משלם בנפרד על שירותי תמיכה, אין צורך להחרגות הללו. פשוט תעשה מה שמשלמים לך עליו.
זה מה שקרה עם הלקוח האוסטרלי: מחיר קבוע לתמיכה, בלי תקרה על היקף השימוש.
תוך כמה זמן התיקונים יתבצעו? אם החלטת שאתה כן לוקח אחריות על תיקונים כלשהם, תקבע מראש תוך כמה זמן תבצע את התיקונים, וכמובן מקובל שהתקופות יהיו שונות בהתאם לחומרת הבאג.
על חשבון מי יתבצעו התיקונים? ברישיונות ללקוחות Enterprise הרבה פעמים קובעים כי שירותי התמיכה יינתנו בתשלום בלבד, ועלות התמיכה תהיה אחוז כלשהו מהמחיר של הרישיון.
- רמת שירות (SLA) – כשהתוכנה שלך עונה על צורך קריטי, לרוב המשתמש יבקש ממך להתחייב לרמת שירות או רמת ביצועים מינימלית.
ייתכן ותתבקש להתחייב למדדי ביצועים, תנאים לגבי זמינות התוכנה, איכות שירותי התמיכה שלך, וזמן לביצוע תיקונים.
למשל, האם צריך לתקן באג חמור במיוחד תוך X שעות או לדאוג שהתוכנה תהיה זמינה 99% מהזמן או שתאפשר ביצועים מינימליים מסוימים.
חשוב גם לקבוע מה יקרה אם התוכנה לא עומדת בתנאים הללו – האם אתה צריך לבצע תיקונים או לאפשר שימוש חינם בתוכנה לזמן מסוים או לשלם קנס או לעשות משהו אחר.
ייתכן ותרצה לקבוע באילו מקרים אפשר לסיים את ההסכם עקב בעיות חמורות בתוכנה, כדי שלשני הצדדים יהיה ברור איפה עובר הקו.
- ביקורת – האם מותר לך לבצע ביקורת במשרדי הרוכש כדי לבדוק שהוא עומד בתנאי הרישיון?
נניח למשל שהרישיון שהענקת מאפשר התקנה רק על שרת אחד. איך תדע שהתוכנה לא הותקנה על מספר שרתים?
אם מותר לך לבצע ביקורת – אחת לאיזו תקופה ובאיזה אופן?
מה קורה אם אתה מגלה שהרוכש הפר את תנאי הרישיון?
רק תשתדל לא להגזים עם הדרישות שלך, כמו אורקל במקרים מסוימים.
- הדרכה בשימוש בתוכנה – האם אתה חייב לבצע הדרכה ולהסביר איך להשתמש בתוכנה? אם כן, איך והיכן ההדרכה תתבצע?
על חשבון מי ההדרכה תתבצע?
מי, אם בכלל, אחראי על תוצאות תהליך ההדרכה?
- אחריות ושיפוי – מי אחראי על אילו נזקים אשר ייגרמו על-ידי התוכנה או עקב השימוש בה או בגלל שהיא לא זמינה לשימוש או לא נותנת תוצאות כלשהן? לך כמובן עדיף להיות אחראי על כמה שפחות, במיוחד על נזק עקיף.
האם יש הגבלות מבחינת סכומים אותם חייבים לשלם? במידה ואתה כן לוקח אחריות, האם זה על כל סכום הנזק, או רק עד סכום מסוים? האם אתה אחראי גם על נזקים בסכומים קטנים?
האם יש תקופת אחריות מוגבלת? האם תמיד תהיה אחראי על הנזק, או רק לתקופה מוגבלת – למשל שנה מאז שהנזק נגרם?
הפתרון היותר מקובל מצד ספקי תוכנה הוא שהאחריות היא עד לסכום עסקת רכישת הרישיון או עד לסכום ששולם בפועל ב-12 חודשים אחרונים.
- ביטוח – האם אתה חייב להחזיק פוליסת ביטוח למקרה שיהיה צורך לשלם שיפוי? אם כן, מהם תנאי הפוליסה? אם מדובר בסכומים משמעותיים, בהחלט כדאי לך לבדוק כדאיות של הסדרי ביטוח לתחום.
- ביטול רכישה וסיום ההסכם – מתי ובאילו נסיבות הרוכש יכול לבטל את הרכישה ולסיים את ההסכם?
האם מחזירים למשתמש כזה את כל כספו או רק חלק? זה כמובן תלוי גם במבנה התשלום של הרוכש.
מה קורה לכל הזכויות והחובות שהוענקו לפי ההסכם?
האם צריך להחזיר קניין רוחני ו/או מידע סודי?
האם צריך לשלם קנס כלשהו על סיום מוקדם?
- תקופת העסקה – מה משך תקופת ההסכם? שנה, 5 שנים, משהו אחר?
משך תקופת הרישיון הוא דבר חשוב, כי פה אתה בעצם מחליט כמה זמן ישלמו לך כסף על הרישיון.
אם הרישיון הוא לתקופה ארוכה, או שהוא מתחדש אוטומטית מדי תקופה, כדאי לכל הפחות להצמיד את התשלום לעליות במדד לצרכן (אינפלציה). בהרבה מקרים מקובל שמחיר הרישיון השנתי פשוט עולה בכל שנה באחוז מסוים.
חקיקה
הנקודות הנ"ל צריכות לקבל ביטוי בהסכם, אבל קח בחשבון שבמדינות שונות יש גם חקיקה שמתייחסת לחלק מהנקודות האלה, ולרוב גוברת על תנאי ההסכם (לפעמים גם אם רשום שחל דין של מדינה אחרת).
כך למשל חוקים בתחומי הגנת פרטיות, תחרות, ייצוא, והגנת צרכנים יכולים לדרוש כי העסקה תתבצע באופן מסוים, או לא תתבצע בכלל. ולא משנה מה רשום בהסכם.
אתה בהחלט תרצה לבצע בדיקה משפטית במקרים מסוימים, כדי להבין מה החוק הרלוונטי מחייב אותך לעשות, והאם העסקה עדיין משתלמת לך לאור החוק הרלוונטי. תלוי בתחום העיסוק של החברה שלך ובאזור הגיאוגרפי של השוק שלך.
סיכום
חשוב שתחשוב עד כמה שיותר לעומק על עסקה שכזו. אתה הרי רוצה שהיא תהיה רווחית גם עבורך, לא?
כבר בשלב כתיבת התוכנה כדאי לך לראות אילו סוגי רישיון נותנים המתחרים שלך (פר מחשב, פר משתמש, פר משרד וכו'), ועד כמה רישיונות אלו הוגנים כלפי משתמשי הקצה. אחרי שהחלטת איזה רישיון נראה לך מתאים, אל תשכח לכלול בתוכנה מנגנונים מתאימים שיאפשרו לך לבצע מעקב כלשהו אחר תנאי הרישיון.
רוצה לבדוק אם יש בהסכם הרישיון שלך סעיפים שיעלו לך ביוקר? שלח לי אותו בוואטסאפ ונקבע שיחה.
גילוי נאות: מאמר זה מיועד להעשרת הידע ואינו מהווה ייעוץ משפטי. עמידה בדרישות החוק תלויה באופיין הספציפי של הפעילות והמערכות בחברתך.