תקנון לאפליקציה, שמכונה בדרך כלל גם תנאי שימוש, מסדיר את מערכת היחסים בין מפעיל האפליקציה לבין המשתמשים שלה. הוא צריך להסביר מה השירות שהאפליקציה מספקת, מי רשאי להשתמש בה, אילו כללים חלים על חשבון המשתמש, מה מותר ואסור לעשות, כיצד מתבצעים תשלומים אם קיימים ומה קורה כאשר השירות מופסק או החשבון נסגר.
אין תקנון אחד שמתאים לכל אפליקציה. אפליקציה להזמנת בעלי מקצוע אינה דומה לרשת חברתית, אפליקציית כושר אינה דומה למשחק ואפליקציה שמוכרת מנוי דיגיטלי אינה דומה לשירות חינמי שמציג מידע בלבד. ככל שהמוצר מורכב יותר, כך צריך להסדיר באופן מדויק יותר את היחסים שנוצרים סביבו.
לכן השאלה אינה רק מה צריך להיות כתוב בתקנון לאפליקציה, אלא אילו פעולות המשתמש יכול לבצע, אילו התחייבויות האפליקציה לוקחת על עצמה ואיפה עלולות להתעורר מחלוקות.
התקנון צריך להתחיל במה שהאפליקציה באמת עושה
תקנון טוב אינו מתחיל בסעיפי אחריות אלא בהבנה של המוצר. לפני שמנסחים אותו צריך לדעת מי מפעיל את האפליקציה, מה המשתמש מקבל ממנה ומהו התפקיד של המפעיל בתוך השירות.
נניח שאפליקציה מאפשרת להזמין מטפל, טכנאי או בעל מקצוע. קיימת משמעות גדולה לשאלה אם מפעיל האפליקציה הוא זה שמוכר את השירות ללקוח, או שהוא רק מפעיל פלטפורמה שמחברת בין שני צדדים שאחר כך מתקשרים ישירות. המשתמש יכול לראות את אותו מסך הזמנה בשני המקרים, אבל מבחינה משפטית מדובר במערכות יחסים שונות.
אותו דבר נכון באפליקציה שמציגה מידע. אם מדובר בתוכן כללי בלבד, התקנון יכול להיות פשוט יחסית. אם האפליקציה נותנת המלצות אישיות, שומרת נתונים, מאפשרת ביצוע פעולות או יוצרת הסתמכות על המידע שהיא מציגה, צריך לבחון בזהירות רבה יותר כיצד השירות מתואר ואילו גבולות מציבים לו.
מי רשאי להשתמש באפליקציה?
בחלק מהאפליקציות כל אדם יכול להוריד ולהשתמש בשירות. באחרות יש מגבלות גיל, תנאי סף, אזור גיאוגרפי מסוים או דרישה שהמשתמש יהיה בעל עסק, בעל רישיון או נציג מוסמך של חברה.
אם קיימת מגבלה כזו, כדאי שהיא תופיע בתקנון ותתאים גם לתהליך ההרשמה בפועל. אין טעם לכתוב בתנאים שהשירות מיועד רק לבני 18 ומעלה אם האפליקציה מאפשרת לכל משתמש לפתוח חשבון בלי שום התייחסות לגיל.
כאשר האפליקציה מיועדת לקטינים או מאפשרת להם להשתמש בחלק מן השירותים, נדרשת בחינה נפרדת של אופן ההתקשרות ושל המידע שנאסף מהם. במקרה כזה תקנון רגיל שנלקח מאפליקציה למבוגרים אינו בהכרח מתאים.
פתיחת חשבון משתמש יוצרת מערכת יחסים מתמשכת
כאשר המשתמש פותח חשבון, התקנון צריך להסדיר לא רק את רגע ההרשמה אלא גם את מה שקורה לאחר מכן. אפשר לקבוע שהמשתמש אחראי למסירת פרטים נכונים, לשמירת אמצעי ההתחברות שלו ולפעולות שמתבצעות באמצעות החשבון שלו, בכפוף לדין ולנסיבות.
חשוב גם להבהיר אם ניתן להחזיק יותר מחשבון אחד, האם אפשר להעביר חשבון לאדם אחר ומה קורה כאשר מתעורר חשד לשימוש בלתי מורשה. באפליקציות שבהן לחשבון יש משמעות כספית או עסקית, שאלות כאלה יכולות להפוך למחלוקת ממשית.
התקנון צריך להתיישב עם המערכת עצמה. אם הוא מאפשר למשתמש לשנות פרטים מסוימים אבל בפועל אין לכך אפשרות באפליקציה, או אם הוא מדבר על שחזור חשבון שאינו קיים במוצר, נוצר פער בין המסמך לבין השירות.
מה מותר ומה אסור לעשות באפליקציה?
כמעט כל אפליקציה צריכה להגדיר גבולות שימוש מסוימים, אבל הגבולות צריכים להיות קשורים למוצר.
באפליקציה שמאפשרת תקשורת בין משתמשים, למשל, ייתכן שיהיה צורך להתייחס להטרדה, התחזות, פרסום תוכן בלתי חוקי או שימוש בחשבון לצורך פגיעה באחרים. באפליקציה שמספקת כלי מקצועי, ייתכן שהמוקד יהיה איסור על ניסיון לעקוף מנגנוני אבטחה, שימוש אוטומטי בלתי מורשה או העתקת השירות.
הניסוח צריך להיות רחב מספיק כדי להתמודד עם שימוש לרעה, אבל לא כללי עד כדי כך שהמפעיל נותן לעצמו לכאורה זכות בלתי מוגבלת לחסום כל משתמש מכל סיבה. ככל שההגבלה משמעותית יותר, רצוי להבין למה היא נדרשת וכיצד היא קשורה להגנה על השירות ועל יתר המשתמשים.
אם המשתמשים מעלים תוכן, צריך להסדיר למי שייכות הזכויות
אפליקציה שמאפשרת העלאת תמונות, סרטונים, תגובות, פוסטים, ביקורות או מסמכים זקוקה להתייחסות מפורשת לתוכן הזה.
נקודת מוצא חשובה היא שהמשתמש אינו אמור לוותר אוטומטית על כל הזכויות שלו רק משום שהעלה יצירה לאפליקציה. מצד שני, כדי שהשירות יוכל להציג את התוכן, לשמור אותו ולהעביר אותו למשתמשים אחרים בהתאם לפונקציונליות של המוצר, הוא עשוי להזדקק לרישיון מסוים להשתמש בו.
לכן צריך להגדיר מה המשתמש מרשה לאפליקציה לעשות בתוכן שלו, לאיזו תקופה ולשם אילו מטרות. נוסח שלפיו המפעיל מקבל “את כל הזכויות בעולם, לנצח ולכל מטרה” אינו בהכרח נחוץ רק משום שאפשר לכתוב אותו.
בנוסף כדאי להבהיר שהמשתמש צריך להיות בעל הזכויות הנדרשות בתוכן שהוא מעלה. אחרת האפליקציה עלולה למצוא את עצמה מתמודדת עם טענות לכך שמשתמש העלה צילום, מוזיקה או תוכן ששייכים לאדם אחר.
מה קורה כאשר משתמש מפרסם תוכן פוגעני?
אפליקציות שמארחות תוכן של משתמשים עלולות להתמודד עם תלונות על לשון הרע, פגיעה בפרטיות, זכויות יוצרים, התחזות ותוכן אסור אחר.
התקנון יכול לקבוע כללים לגבי סוגי תוכן שאינם מותרים וכן לאפשר למפעיל לבחון תלונות, להגביל חשיפה או להסיר תוכן במקרים המתאימים. יחד עם זאת, התקנון אינו הופך את מפעיל האפליקציה לבית משפט ואינו פותר מראש כל מחלוקת בין המשתמשים.
נניח שמשתמש מפרסם ביקורת חריפה על בעל מקצוע והצד השני דורש להסיר אותה בטענה שמדובר בלשון הרע. ייתכן שלא ניתן לדעת מהתקנון בלבד מי צודק. לכן חשוב להבחין בין כללי הקהילה של הפלטפורמה לבין זכויות משפטיות שעשויות לדרוש בירור רחב יותר.
תשלום בתוך האפליקציה צריך להיות ברור גם בתקנון וגם במסך הרכישה
כאשר האפליקציה גובה כסף, תנאי התשלום הופכים לחלק מרכזי מהתקנון. צריך להסביר עבור מה משלמים, מה המחיר, כיצד החיוב מתבצע ומה המשתמש מקבל בתמורה.
אם מדובר במנוי, יש חשיבות מיוחדת לשאלה האם החיוב מתחדש, באיזו תדירות ומה קורה אם המשתמש מבקש להפסיק אותו. תנאי מהותי כזה לא צריך להיות קבור רק בתוך תקנון ארוך. הוא צריך להיות ברור גם במקום שבו המשתמש מקבל את החלטת הרכישה.
גם כללי חנויות האפליקציות יכולים להשפיע על אופן הגבייה, במיוחד כשמדובר במוצרים דיגיטליים ובמנויים. לכן התקנון צריך להתאים למנגנון התשלום שבו האפליקציה באמת משתמשת ולא לתאר מערכת אחרת.
**
מדיניות ביטולים והחזרים צריכה להתאים לסוג העסקה
לא כל רכישה באפליקציה ניתנת לביטול באותה דרך. קניית מוצר פיזי, הזמנת שירות, רכישת תוכן דיגיטלי ומנוי מתחדש יכולים להיות כפופים לכללים שונים.
לכן לא נכון להשתמש במשפט גורף שלפיו “לא ניתן לקבל החזר בשום מקרה” או, מהצד השני, להבטיח זכות ביטול רחבה יותר ממה שהעסק באמת מתכוון לתת. צריך לבדוק את סוג העסקה ואת הדין החל עליה.
במקום שבו חנות האפליקציות עצמה מטפלת בחלק מתהליך התשלום או ההחזר, כדאי להסביר למשתמש כיצד הדבר משתלב עם השירות של מפעיל האפליקציה. גם כאן חשוב שהתקנון והמסכים בפועל לא יסתורו זה את זה.
תנאי שימוש אינם תחליף למדיניות פרטיות
תקנון לאפליקציה ומדיניות פרטיות הם שני מסמכים שונים.
התקנון עוסק ביחסים המשפטיים הנוגעים לשימוש בשירות. מדיניות הפרטיות עוסקת באיסוף, שימוש, שמירה והעברה של מידע אישי. ניתן להפנות מתוך התקנון למדיניות הפרטיות, אבל סעיף קצר שלפיו “המשתמש מסכים למדיניות הפרטיות” אינו מחליף מדיניות שמתארת בפועל את פעילות המידע של האפליקציה.
גם אין משמעות לכך שהמשתמש “מסכים לתקנון” אם בתוך המסמך מנסים להכניס היתר גורף לכל שימוש עתידי במידע. שאלות של פרטיות והסכמה למידע צריכות להיבחן בהתאם לדיני הפרטיות ולדרך שבה האפליקציה אוספת ומשתמשת במידע.
**
צריך להסדיר גם את הקניין הרוחני של האפליקציה
האפליקציה עצמה יכולה לכלול קוד, עיצוב, לוגו, טקסטים, מאגרי תוכן, איורים ורכיבים נוספים המוגנים בזכויות שונות.
בתנאי השימוש ניתן להבהיר שהשימוש באפליקציה אינו מעביר למשתמש בעלות בנכסים האלה. המשתמש מקבל זכות להשתמש בשירות בהתאם לתנאים, ולא זכות להעתיק את המוצר, לשכפל חלקים ממנו או להציג את עצמו כבעל הזכויות.
עם זאת, התקנון אינו מתקן בעיית בעלות פנימית. אם חברת הפיתוח או מעצב חיצוני יצרו רכיבים של האפליקציה והזכויות מולם לא הוסדרו בהסכם, משפט בתקנון מול המשתמשים אינו הופך אוטומטית את מפעיל האפליקציה לבעל הזכויות.
שירותים חיצוניים צריכים לקבל התייחסות מתאימה
אפליקציות רבות מסתמכות על שירותים של חברות אחרות: מפות, סליקה, התחברות באמצעות חשבון חיצוני, שירותי ענן, מערכות בינה מלאכותית או ממשקי מידע.
אם חלק מן השירות תלוי בגורם חיצוני, ייתכן שכדאי להסביר זאת למשתמש במידה הרלוונטית. לדוגמה, אם האפליקציה מציגה נתונים שמגיעים מספק אחר, צריך לבחון האם היא מתחייבת לדיוקם ובאיזו מידה יש לה שליטה על זמינות השירות.
מצד שני, סעיף כללי שלפיו “כל שירות של צד שלישי הוא באחריות המשתמש בלבד” אינו בהכרח מתאים אם אותו ספק הוא חלק מהותי מהשירות שהאפליקציה עצמה מציעה.
הגבלת אחריות צריכה להתאים למוצר
כמעט בכל תקנון מופיע סעיף אחריות, אבל הוא צריך להיכתב בזהירות. אין טעם לכתוב שהאפליקציה “אינה אחראית לשום דבר, בשום מקרה ובכל סכום” ולחשוב שהמשפט לבדו פותר כל חשיפה אפשרית.
היקף האחריות תלוי בשירות, בדין ובנסיבות. יש הבדל בין אפליקציית בידור לבין אפליקציה שאנשים מסתמכים עליה בקבלת החלטה עסקית, רפואית או פיננסית. גם האופן שבו המוצר מוצג בפרסום ובמסכים עצמם יכול להשפיע על הציפייה של המשתמש.
סעיף אחריות טוב מנסה להגדיר בצורה מציאותית את גבולות השירות ואת הדברים שמפעיל האפליקציה באמת יכול או אינו יכול להבטיח, במקום להשתמש בהצהרות מוחלטות שאינן מתיישבות עם הפעילות.
גם זמינות האפליקציה אינה מובטחת לנצח
שירותים דיגיטליים עוברים תחזוקה, עדכונים ותקלות. לעיתים גם מפסיקים לתמוך בפיצ’ר מסוים או מחליטים לסגור את השירות כולו.
התקנון יכול להסביר שהאפליקציה עשויה להשתנות ושאין התחייבות לכך שכל תכונה תישאר זמינה לנצח. עם זאת, אם משתמש שילם מראש עבור שירות לתקופה מסוימת, אי אפשר להתעלם מהתחייבויות שכבר נוצרו כלפיו רק באמצעות סעיף כללי שמאפשר לשנות הכול בכל רגע.
ככל שהשינוי משמעותי יותר למשתמש, כך צריך לבחון אם די בעדכון התקנון או שנדרשת גם הודעה ברורה יותר.
מתי אפשר להשעות או לסגור חשבון?
אפליקציה עם חשבונות משתמשים צריכה לחשוב מראש על מצבים שבהם יש הצדקה להגביל חשבון.
שימוש לרעה בשירות, ניסיון הונאה, הפרה חוזרת של כללי הקהילה או סיכון למשתמשים אחרים יכולים להצדיק מנגנוני אכיפה. התקנון יכול להגדיר את הסמכות הזאת ואת המצבים העיקריים שבהם היא עשויה להיות מופעלת.
אבל גם כאן רצוי להימנע מניסוח שנותן למפעיל לכאורה זכות שרירותית למחוק כל משתמש ללא קשר לנסיבות. באפליקציה שבה לחשבון יש תוכן, יתרה כספית, היסטוריית רכישות או פעילות עסקית, לסגירת החשבון יכולה להיות משמעות ממשית.
ומה אם המשתמש עצמו רוצה לעזוב?
התקנון צריך להתייחס גם לצד השני של מערכת היחסים. אם המשתמש יכול לסגור את החשבון, כדאי להסביר מה קורה לאחר הסגירה ומה ההבדל בין סיום השימוש, ביטול מנוי ומחיקת מידע.
אלה אינן תמיד אותה פעולה. משתמש יכול לבטל מנוי אך להשאיר חשבון חינמי, או למחוק חשבון ועדיין להשאיר נתונים שהעסק מחויב לשמור מסיבה משפטית אחרת.
כאשר האפליקציה מופצת דרך חנויות אפליקציות, עשויות להיות גם דרישות פלטפורמה הנוגעות למחיקת חשבון ומידע. לכן כדאי שמסלול היציאה מן השירות ייבנה כחלק מהמוצר עצמו ולא רק כמשפט בתקנון.
האם צריך שהמשתמש יסמן "אני מסכים לתקנון"?
עצם קיומו של התקנון אינו בהכרח מספיק אם רוצים להסתמך עליו כחלק מההתקשרות עם המשתמש.
ככל שהתנאים מהותיים יותר, חשוב לבחון כיצד הם מוצגים וכיצד המשתמש מקבל הזדמנות סבירה לעיין בהם לפני שהוא מתקשר. באפליקציה עם הרשמה, רכישה או מנוי, שילוב נכון של הפניה לתנאים בתוך התהליך יכול להיות משמעותי יותר מקישור שמופיע רק במסך צדדי שאיש אינו מגיע אליו.
גם כאן אין טעם להעמיס על המשתמש מסמך משפטי ארוך דווקא ברגע קריטי. אפשר להציג את התנאים המהותיים במסך עצמו ולהפנות לתקנון המלא לפרטים נוספים.
שינוי התקנון אינו מאפשר לשנות כל דבר בדיעבד
אפליקציות משתנות, ולכן גם התקנון עשוי להזדקק לעדכון. ניתן להוסיף תכונות חדשות, לשנות מודל עסקי או להתאים את השירות לדרישות חדשות.
עם זאת, משפט שמאפשר למפעיל “לשנות את התקנון בכל עת וללא הודעה” אינו נותן בהכרח תשובה לכל שינוי אפשרי. יש הבדל בין תיקון טכני לבין שינוי מהותי בתשלום, בזכויות המשתמש או בשירות שכבר נרכש.
לכן כדאי להבחין בין סוגי השינויים ולבחון מתי נכון לפרסם גרסה חדשה, מתי יש ליידע את המשתמשים ומתי נדרשת פעולה נוספת מעבר לעדכון העמוד.
דין וסמכות שיפוט אינם רק סעיף סיום טכני
תקנונים רבים מסתיימים בסעיף שמכריז כי כל מחלוקת תתברר בבית משפט מסוים. אבל גם סעיף כזה כפוף לדין ואינו בהכרח גובר על כל זכות אחרת שעומדת למשתמש.
כאשר האפליקציה פועלת בישראל אך זמינה גם למדינות אחרות, השאלה נעשית מורכבת עוד יותר. ייתכן שהמפעיל רוצה להחיל דין ישראלי, אבל משתמשים במדינות אחרות יכולים להיות מוגנים גם על ידי הוראות מקומיות שאינן ניתנות להתניה.
לכן סעיפי הדין וסמכות השיפוט צריכים להתאים לקהל היעד ולמודל הפעילות ולא להילקח אוטומטית מתקנון של אפליקציה אמריקאית.
למה לא כדאי להעתיק תקנון של אפליקציה אחרת?
שתי אפליקציות יכולות להיראות כמעט זהות במסך הבית ועדיין לפעול באופן משפטי שונה לחלוטין.
אחת עשויה להיות רק פלטפורמה שמחברת בין משתמשים, והשנייה ספק השירות עצמו. אחת גובה מנוי, השנייה עמלה מכל עסקה. אחת מאפשרת העלאת תוכן ציבורי, והשנייה אינה מאפשרת שום אינטראקציה בין משתמשים.
כאשר מעתיקים תקנון, מעתיקים גם את ההנחות שמאחוריו. כך אפשר להכניס סעיפים שאינם רלוונטיים ולהשמיט דווקא את הסיכונים המרכזיים של המוצר החדש.
התקנון צריך להיבנות מתוך האפליקציה, לא להפך.
מתי נכון להכין את התקנון?
עדיף להכין את תנאי השימוש כאשר מבנה האפליקציה כבר ברור, אבל לפני שההשקה הושלמה.
בשלב הזה אפשר עדיין לזהות פערים בין המוצר לבין המסמך. ייתכן, למשל, שהתקנון דורש מהמשתמש לאשר פעולה מסוימת אבל אין לכך מסך מתאים, או שהאפליקציה מאפשרת העלאת תוכן בלי שום מנגנון לטיפול בתלונות.
כאשר הבדיקה נעשית בזמן, ניתן להתאים גם את התקנון למוצר וגם את המוצר לתקנון. אם מחכים עד יום ההשקה, נשאר לפעמים רק לנסות לנסח מסמך שמתאים בדיעבד למערכת שכבר נבנתה.
תקנון לאפליקציה אינו מסמך טכני שמוסיפים כדי לסמן וי לפני ההשקה. הוא אמור לתרגם את המוצר למערכת כללים ברורה בין מי שמפעיל את האפליקציה לבין מי שמשתמש בה.
כדי לעשות זאת נכון צריך להבין את השירות עצמו: האם קיימים חשבונות משתמשים, מה המשתמשים יכולים לפרסם, האם יש תשלומים או מנויים, אילו פעולות אסורות, מתי ניתן לסגור חשבון ואיפה מסתיימת האחריות של מפעיל האפליקציה.
ככל שהתנאים תואמים יותר למסכים ולתהליכים שהמשתמש פוגש בפועל, כך הם גם ברורים ושימושיים יותר. תקנון שהועתק ממוצר אחר או שנכתב בלי להבין את האפליקציה עלול להיראות מקצועי מבחוץ, אבל לא להסדיר דווקא את המקומות שבהם תתעורר המחלוקת הראשונה.