רישוי תוכנה הוא המנגנון החוזי שבאמצעותו בעל זכויות היוצרים בתוכנית מתיר לאחר להשתמש בה. על פי החוק ההולנדי, תוכנית מחשב היא יצירה מוגנת בפני עצמה לפי סעיף 10, פסקה ראשונה, נקודה 12 של Auteurswet (חוק זכויות היוצרים), כך שכל פעולה של טעינה, העתקה או עיבוד שלה דורשת אישור או חריג סטטוטורי. רישיון הוא אישור זה, והיקפו, משכו ותנאיו נקבעים בהסכם, בכפוף לגרעין מצומצם של זכויות שלא ניתן לכפות על בעל הרישיון לוותר עליהן.
מסגרת זו מסבירה כמעט כל דבר שארגונים טועים לגבי רישוי תוכנה: הם מתייחסים לרישיון כאל קבלה ולא כאל חוזה, הם נוטלים על עצמם זכויות שהרישיון מעולם לא העניק, והם מגלים את הפער במהלך ביקורת ספק או הגירה. מאמר זה מפרט מה החוק ההולנדי והאירופי נותן לך בפועל, מה הרישיון מוסיף או גורע, ואילו סעיפים קובעים את החשיפה שלך.
מה שאתה רוכש כשאתה רוכש רישיון לתוכנה
אינך קונה תוכנה. אתה רוכש זכות להשתמש בעותק, על פי תנאי הרישיון, בעוד שזכויות היוצרים נשארות בידי בעל הזכויות. להבחנה זו יש השלכות מעשיות: אינך יכול להניח שאתה רשאי להתקין את התוכנה בשרת שני, להריץ אותה עבור חברה קבוצתית, לאפשר לקבלן להשתמש בחשבונך, או להמשיך להשתמש בה לאחר סיום ההסכם, אלא אם כן הרישיון קובע זאת.
עם זאת, החוק ההולנדי אינו מתייחס לכל רכישת תוכנה כאל רישיון טהור. בפסק הדין De Beeldbrigade מיום 27 באפריל 2012 (ECLI:NL:HR:2012:BV1301), קבע בית המשפט העליון כי הכללים על מכירה בספר 7 של הקודקס האזרחי חלים על רכישת תוכנה סטנדרטית המסופקת לתקופה בלתי מוגבלת תמורת תשלום חד פעמי, למרות שתוכנה אינה חפץ מוחשי. ההשפעה המעשית היא שדרישת ההתאמה של חוק המכר חלה: התוכנה חייבת להיות בעלת התכונות שהקונה היה זכאי לצפות להן. זוהי עמדה חזקה משמעותית מאחריות חוזית גרידא, וזו אחת הסיבות לכך שספקים מעדיפים מודלים של מנוי וענן, שהם שירותים ולא מכירות.
כאשר הלקוח הוא צרכן, חלה שכבה נוספת. ספר 7 של הקודקס האזרחי מכיל סט נפרד של כללים בנוגע לחוזים לאספקת תוכן דיגיטלי ושירותים דיגיטליים מאז ה-1 בינואר 2022, המיישם את ההנחיה האירופית בנושא זה. כללים אלה מטילים דרישות התאמה, חובת עדכון כל עוד הצרכן רשאי לצפות באופן סביר לעדכונים, ותרופות שלא ניתן לשלול לרעת הצרכן. רישיונות עסק לעסק נותרים במידה רבה לחופש החוזים, וזו בדיוק הסיבה שהמשא ומתן חשוב יותר בהקשר זה.
מי הבעלים של תוכנה שנכתבה עבורך היא שאלה נפרדת שתופסת ארגונים רבים. זכויות יוצרים בתוכנית שנכתבה על ידי עובד במילוי תפקידו מוקנות למעסיק על פי סעיף 7 לחוק Auteurswet. זכויות יוצרים בתוכנית שנכתבה על ידי פרילנסר או סוכנות פיתוח נשארות בידי אותו צד אלא אם כן הן מועברות באמצעות שטר בכתב. לקוח המזמין ללא העברת רישיון בכתב מקבל בסופו של דבר רישיון משתמע בעל היקף לא ודאי, שמתגלה ברגע שהוא צריך למכור את העסק או להחליף ספק. המאמר שלנו על רישוי תוכנה קנייני בוחן את הקשר הזה ביתר פירוט.
הזכויות שהחוק מעניק לך, כל מה שכתוב ברישיון
חוק התוכנה האירופי שומר מספר קטן של זכויות לרוכש החוקי, וסעיף המתיימר לשלול אותן הוא בטל. ידיעתן משנה את האיזון בסכסוך.
סעיף 45j לחוק Auteurswet מתיר לרוכש כדין של עותק לבצע את ההעתקים הנדרשים לשימוש המיועד של התוכנה. הצדדים רשאים לשנות זאת בחוזה, למעט חריג אחד שלא ניתן לשנותו: העתקה המתרחשת במהלך טעינת התוכנה, הצגתה או תיקון שגיאות בה אינה ניתנת לאיסור בהסכם. רישיון האוסר עליך לתקן תקלה המונעת מהתוכנה לפעול כמתוכנן, במידה זו, אינו ניתן לאכיפה.
סעיף 45k לחוק ה-Auteurswet מאפשר למשתמש החוקי ליצור עותק גיבוי כאשר הדבר נחוץ לשימוש המיועד, וגם זכות זו אינה ניתנת לויתור. סעיף 45m מתיר דה-קומפילציה, אך רק בתנאים מחמירים: השגת המידע הדרוש להשגת יכולת פעולה הדדית עם תוכנה שנוצרה באופן עצמאי חייבת להיות הכרחית, היא חייבת להתבצע על ידי רוכש חוקי, המידע לא חייב להיות זמין כבר עכשיו, והיא חייבת להיות מוגבלת לחלקי התוכנה הנחוצים למטרה זו. דה-קומפילציה לצורך בניית מוצר מתחרה אינה נחשבת לחריג. בית המשפט לצדק אישר בפסק הדין Top System (C-13/20, 6 באוקטובר 2021) כי רוכש חוקי רשאי לבצע דה-קומפילציה גם כדי לתקן שגיאות המשפיעות על תפקוד התוכנה.
עיקרון נוסף מגביל את מה שרישיון יכול להשתלט עליו. בפסק הדין SAS Institute (C-406/10, 2 במאי 2012) קבע בית המשפט לצדק כי לא הפונקציונליות של תוכנית מחשב, לא שפת התכנות ולא הפורמט של קבצי הנתונים שבה היא משתמשת מוגנים על ידי זכויות יוצרים בתוכנית. מה שמוגן הוא הביטוי: קוד המקור וקוד האובייקט. המדריך שלנו לדיני קניין רוחני בהולנד מציב זכויות יוצרים בתוכנה לצד זכויות אחרות שעסק טכנולוגי מסתמך עליהן. מתחרה שלומד את מה שהתוכנה שלך עושה וכותב את המימוש שלו אינו מפר את זכויות היוצרים שלך, גם אם זה לא רצוי.
רישיונות קנייניים, קוד פתוח וזכויות יוצרים
רישיונות מתחלקים לשלוש משפחות, וההבדל ביניהן אינו אידיאולוגי אלא מבצעי: הוא קובע מה עליך לחשוף ועל מה אתה רשאי לגבות תשלום.
רישיונות קנייניים
רישיון קנייני שומר על קוד המקור סגור ומעניק זכות שימוש מוגדרת, בדרך כלל לא בלעדית ובלתי ניתנת להעברה. ההגבלות הן מהות ההסכם: מספר מרבי של משתמשים או מכשירים בעלי שם, סביבה מותרת, איסור על רישוי משנה ואיסור על הנדסה לאחור, שתקף רק במידה שאינו מתנגש בזכויות החוקיות שתוארו לעיל. הספק שולט בעדכונים, בתמיכה ובתמחור, והלקוח נושא בעלות ההגירה אם המוצר מופסק או שהתנאים משתנים. תלות זו היא סיכון חוזי, והיא מנוהלת על ידי משא ומתן על תקופות הודעה מוקדמת, תקרות העלאת מחירים, הסדרי המשכיות, ועבור מערכות קריטיות לעסקים, נאמנות בקוד מקור.
רישיונות קוד פתוח מתירים
רישיונות קוד פתוח הם רישיונות זכויות יוצרים, לא ויתור על זכויות יוצרים, והם ניתנים לאכיפה באותו אופן כמו כל רישיון אחר: הפרת התנאים תאבד את ההרשאה, מה שמותיר אותך כמפר.
רישיונות מתירניים כמו MIT, BSD ו-Apache 2.0 מטילים מעט התחייבויות. ניתן לשלב את הקוד במוצר מסחרי, כולל מוצר שאתם מפיצים בצורה בינארית בלבד, בתנאי שתשכפלו את הודעת זכויות היוצרים, טקסט הרישיון וההצהרות. Apache 2.0 מוסיף רישיון פטנט מפורש ודרישה לציין ששיניתם את הקבצים. התחייבויות אלו קלות לעמוד בהן וקלות להתעלם מהן, וקובץ הודעה שהושמט הוא כשל התאימות הנפוץ ביותר בקוד פתוח בפועל.
רישיונות זכויות יוצרים
רישיונות זכויות יוצרים, שהרישיון הציבורי הכללי של GNU הוא הידוע ביותר, מצמידים תנאי להפצה: מי שמקבל את הקובץ הבינארי חייב להיות מסוגל גם להשיג את המקור המתאים, תחת אותו רישיון. אם משנים קוד GPL ומפיצים את התוצאה , חובת זכויות היוצרים משתרעת על היצירה כולה, מה שיכול להיות חשיפת קוד שהתכוונת לשמור קנייני. שימוש בתוכנת GPL באופן פנימי, מבלי להפיץ אותה, אינו מפעיל את החובה, אך גרסת Affero של ה-GPL מתייחסת לזמינות התוכנה ברשת כשווה ערך להפצה, וזה בדיוק המצב של ספק SaaS.
ה-GPL הקטן יותר תופס נקודת ביניים: ניתן לקשר קוד קנייני לספריית LGPL מבלי לפתוח קוד משלך, בתנאי שהמשתמש יכול להחליף את הספרייה בגרסה שונה. האם קישור סטטי עומד בתנאי זה היא שאלה שמצריכה ייעוץ לפני, ולא אחרי, השחרור.
עבור חברה שמספקת תוכנה, התשובה המעשית היא מדיניות קוד פתוח כתובה, מלאי של כל רכיב והרישיון שלו, ובדיקה אוטומטית בצנרת הבנייה. המלאי הוא גם מה שרוכש יבקש במהלך בדיקת הנאותות, והיעדרו מפחית באופן מהימן את מחיר הרכישה.
מודלים של רישוי ומה משמעותם המשפטית
סוג הרישיון מציין מה מותר לך לעשות עם הקוד. מודל הרישוי מציין כיצד אתה משלם וכיצד נמדד השימוש, והוא קובע היכן נמצא סיכון התאימות.
רישיון למשתמש בעל שם או רישיון לפי מושב קשור לאדם מזוהה. שיתוף חשבון בעל שם בין שני עובדים מהווה הפרה גם כאשר השניים לעולם לא עובדים בו זמנית, וזו ההפרה שספקים מזהים בקלות רבה ביותר. רישיון מקביל או צף מגביל את מספר המשתמשים בו זמנית ונאכף על ידי שרת רישיונות; כאן הסיכון אינו שיתוף אלא חריגה מהשיא. רישיון לפי מכשיר או לפי ליבה נמדד מול חומרה, ווירטואליזציה היא המקום שבו זה משתבש: הפעלת מופע מורשה על אשכול יכולה, תחת המדדים של ספקים מסוימים, להיחשב כרישוי של כל ליבה פיזית באשכול זה. קראו את הגדרת המדד, לא את רשימת המחירים.
הבחירה בין רישיון קבוע למנוי היא משפטית וגם כלכלית. רישיון קבוע מעניק זכות בלתי מוגבלת להשתמש בגרסה ספציפית; תמיכה וגרסאות חדשות מגיעות מהסכם תחזוקה נפרד , ופקיעת הסכם זה אינה מבטלת את הזכות להמשיך להשתמש במה שיש לך. מנוי מעניק שימוש רק כל עוד אתה משלם, כך שסוף החוזה הוא סוף הגישה שלך; השאלות שיש להכריע מראש הן מה קורה לנתונים שלך, באיזה פורמט הם מוחזרים, ולכמה זמן הספק יסייע ביציאה.
פריסה בענן ובמקומית מעלות שוב סוגיות שונות. כאשר תוכנה פועלת על תשתית הספק, אתם רוכשים שירות, וההסכם צריך להתייחס לזמינות, זמני תגובה של התמיכה, קבלני משנה, מיקום הנתונים וההשלכות של סיום העסקה. כאשר מעובדים נתונים אישיים, אתם זקוקים גם להסכם עיבוד נתונים העומד בדרישות סעיף 28 של ה-GDPR; הסכם רישיון אינו עושה את העבודה הזו. המאמר שלנו על חוזה הענן בהולנד מפרט מה חוזה זה חייב לכסות.
האם ניתן למכור או להעביר רישיון תוכנה
לעיתים, והתשובה עוקבת אחר קו אירופאי ברור. בפסק הדין UsedSoft (C-128/11, 3 ביולי 2012) קבע בית המשפט לצדק כי כאשר בעל זכויות מעמיד עותק של תוכנה לרשות הורדה ומעניק, תמורת תשלום, זכות להשתמש בעותק זה לתקופה בלתי מוגבלת, הוא מכר את העותק. זכות ההפצה בעותק זה מוצה אז, ובעל הזכויות אינו יכול להתנגד למכירתו החוזרת, למרות שהעותק מעולם לא היה על דיסק. הרוכש הראשון חייב להפוך את העותק שלו לבלתי שמיש ברגע המכירה החוזרת, ורישיון למספר מוגדר של משתמשים אינו ניתן לפיצול ולמכירה בחלקים.
למגבלות יש חשיבות לא פחות מהכלל. מיצוי חל על רישיון קבוע הנמכר תמורת סכום חד פעמי, ולא על מנוי או שירות. בית המשפט אישר בתיק טום קבינט (C-263/18, 19 בדצמבר 2019) כי אספקת ספר אלקטרוני באמצעות הורדה לשימוש קבוע היא תקשורת לציבור ולא הפצה, ולכן לא נוצר מיצוי; פסק הדין בנושא תוכנה נשען על הוראות ספציפיות של הוראת התוכנה ואינו חל על יצירות דיגיטליות אחרות. חוזי תחזוקה ותמיכה אינם מועברים עם הרישיון אלא אם כן הספק מסכים.
בפועל, רישיון שנמכר על בסיס זה ניתן להעברה למרות איסור חוזי, אך כל מה שסביבו ניתן למשא ומתן. לפני רכישת רישיונות יד שנייה, בקשו את שרשרת הבעלות, את החשבונית המקורית ואישור בכתב מהמוכר כי העותקים שלה נמחקו.
ביקורות ספקים ומה חברה הולנדית צריכה לקבל
רוב הסכמי הארגון מכילים סעיף ביקורת, וספקים משתמשים בו. הסעיף הוא שמעניק לספק את זכויותיו, ולכן זהו המסמך הראשון שיש לקרוא כאשר מגיעה הודעה.
ביקורת טיפוסית מתחילה במכתב המודיע על ביקורת ומבקש נתוני פריסה, רישומי רכישה ודוחות מערכת בתוך פרק זמן מוגדר. אתם מחויבים למה שמספק הסעיף ולא יותר. סעיף מנוסח היטב מגביל ביקורות לפעם בשנה, דורש הודעה מוקדמת סבירה, מגביל את ביצוען לשעות הפעילות הרגילות, מחייב את המבקר לחתום על התחייבות סודיות, קובע שהספק יישא בעלות אלא אם כן נמצא גירעון מהותי, ומגביל את היקף הביקורת למוצרים שניתנו בפועל ברישיון. כאשר הסעיף שותק, דרישות הסבירות וההגינות לפי סעיף 6:248 לחוק האזרחי ממלאות את החסר, והן אינן מזכות ספק גישה בלתי מוגבלת למערכות שלכם.
שלושה כללים מעשיים חלים. אל תמסור נתונים גולמיים לפני שביצעת את המדידה בעצמך; הדיון הוא כמעט תמיד על אופן ספירת השימוש ולא על מה שהותקן. ניתב את כל התקשורת דרך אדם אחד ואשר כל הסכם בכתב. ושמור על התרגיל בתוך החוזה: מבקר המבקש גישה למערכות מחוץ למוצרים המורשים, או לנתונים אישיים של עובדים, מבקש משהו שהסעיף אינו מספק, וה-GDPR חל על בקשה זו בדיוק כמו על כל בקשה אחרת.
כאשר קיים גירעון אמיתי, תביעת הספק היא חוזית עבור הרישיונות שהיו צריכים להירכש, ובדרך כלל יש מקום לנהל משא ומתן: רכישה צופה פני עתיד במקום עמלות רטרואקטיביות, ויתור על קנסות בתמורה לתקופה ארוכה יותר, או מעבר למדד אחר. כאשר הספק מאיים בהליכי זכויות יוצרים, עליו להוכיח הפרה של זכויות ספציפיות, והסעדים העומדים לרשותו הם אלה של Auteurswet, כולל האפשרות לגבות את מלוא העלויות המשפטיות של הליכי קניין רוחני. המאמר שלנו על אכיפת זכויות קניין רוחני בהולנד מתאר מסלול זה, וסכסוך מסוג זה מתחיל לעתים קרובות במכתב הפסקת זכויות.
ההפרות המופיעות בדוחות הביקורת הן עקביות: התקנות שגדלו לאחר הפריסה המקורית ללא רכישות תואמות, חשבונות של עובדים שעזבו שנותרו פעילים, רישיונות משתמש בעל שם שחולקו בין אנשים, שדרוגים שהותקנו ללא זכויות שדרוג, שימוש בייצור ברישיון פיתוח או בדיקה, וסביבות וירטואליות שנספרו בצורה שונה ממה שהלקוח שיער. כל אחת מהן ניתנת למניעה על ידי רישום מדויק של הרשאות ופריסות, המבוצע לפי התאמה לפחות פעם בשנה. ניהול רישום זה הוא גם חלק מתאימות משפטית כללית בארגון.
הסעיפים שקובעים את הסיכון שלך
רוב רישיונות התוכנה מוצגים כבלתי ניתנים למשא ומתן. עבור כלי מוכן לשימוש, זה בדרך כלל נכון ובדרך כלל מקובל. עבור כל דבר שהעסק תלוי בו, חמישה סעיפים ראויים לתשומת לב אמיתית.
היקף המענק הוא הראשון לציון. עליו לציין מי רשאי להשתמש בתוכנה, כולל חברות הקבוצה, קבלנים וספקי מיקור חוץ; באילו סביבות, כולל בדיקות, התאוששות מאסון וגיבוי; ובאילו טריטוריות. מענק מצומצם יותר מהאופן שבו אתם פועלים בפועל הוא גירעון שמחכה להתגלות.
השני הוא הגבלת האחריות. על פי החוק ההולנדי, סעיף כזה תקף ביחסים עסקיים, אך ניתן לבטל אותו כאשר הסתמכות עליו אינה מקובלת על פי סטנדרטים של סבירות והגינות, והוא לא יגן על צד שכוונתו או פזיזותו המכוונת גרמו לנזק. מה שחשוב הוא ההתאמה: תקרת תשלום שנתית ניתנת להגנה עבור כלי בעל ערך נמוך ובלתי ניתנת להגנה עבור מערכת שכשלה עוצר את הייצור. יש לבחון בנפרד האם הפסד עקיף ותוצאתי אינו נכלל, מכיוון שהחרגה זו מבטלת לעתים קרובות את ההפסד שיפגע בפועל.
השלישי הוא פיצויים בגין קניין רוחני. אם צד שלישי טוען שהתוכנה מפרה את זכויותיו, הלקוח הוא זה שנתבע בגין השימוש בה. פיצויים הולמים מחייבים את הספק להגן על התביעה ולשלם את הנזקים והעלויות הנובעים מכך, ומעניקים לו את האפשרות לרכוש רישיון, לשנות את התוכנה או להחזיר חלק יחסי מהאגרה. שימו לב לפיצויים שמוגבלים לאותו סכום נמוך כמו סעיף האחריות הכללית, מה שהופך אותם לכמעט חסרי ערך.
הרביעית היא המשכיות. מה קורה אם הספק מפסיק לתמוך במוצר, נרכש או הופך לחדל פירעון? נאמנות בקוד מקור עם טריגר שחרור ברור היא התשובה הרגילה עבור תוכנה מקומית, ועבור שירותי ענן המקבילים הם תוכנית יציאה, פורמטי נתונים מוסכמים ותקופת מעבר מוגדרת. חדלות פירעון ראויה לתשומת לב משום שמעמדו של בעל רישיון בפשיטת רגל הולנדית אינו פשוט: הנאמן אינו מחויב להמשיך לבצע, וככל שהשירות תלוי יותר בספק שעושה משהו ולא רק סובל את השימוש שלך, כך אתה חשוף יותר.
סעיף החמישי הוא סעיף השינוי. ספקים שומרים לעצמם באופן שגרתי את הזכות לתקן תנאי מוצר, מדדים או תיעוד באופן חד צדדי. קבלה של תנאי זה ללא הגבלה פירושה קבלה של מחיר והיקף שטרם ראיתם. פשרה ישימה קושרת שינויים לתקופת הודעה מוקדמת ומעניקה ללקוח את הזכות לסיים את העסקה ללא קנס אם השינוי הוא לרעה באופן מהותי. הנחיות כלליות למשא ומתן על מסמכים אלה מפורטות במאמר שלנו בנושא חוזים והסכמים.
מה לעשות לפני שחותמים, ומה לעשות כל שנה
לפני החתימה, יש למפות את אופן השימוש בפועל בתוכנה בניגוד לתנאי ההסכמה, ולסגור את ההפרש בחוזה ולא בדוא"ל מנציג מכירות. יש לקבוע איזה מדד חל וכיצד הוא נמדד, בכתב, באמצעות דוגמה מעשית עבור הסביבה שלכם. יש לאשר האם ההסדר הוא רישיון קבוע או מנוי, ומה אתם שומרים בסוף. יש לבדוק את סעיף הביקורת, את תקרת האחריות, את השיפוי ואת סעיף השינוי ביחס לערך המערכת לעסק.
לאחר החתימה, העבודה היא אדמיניסטרטיבית והיא זו שמונעת מחלוקות. יש לשמור רישום יחיד של זכויות: חוזים, טפסי הזמנה, חשבוניות, מפתחות רישיון, מדדים ותאריכי חידוש. יש להתאים אותו לפריסות בפועל לפחות פעם בשנה, ותמיד לאחר ארגון מחדש, רכישה או מעבר לתשתית וירטואלית או ענן, כי אלו האירועים שיוצרים גירעונות. יש להסיר את החשבונות של אנשים שעזבו. יש לשמור על מלאי קוד פתוח מעודכן לצד זה. שום דבר מזה אינו קשה, וכל זה זול בהרבה מהאלטרנטיבה.
Law & More מייעץ לעסקים בהולנד בנושאי רישוי תוכנה, פיתוח והסכמי SaaS, תאימות לקוד פתוח וסכסוכים עם ספקי תוכנה, כולל ביקורות ותביעות הפרה. אנו סוקרים ומשא ומתן על תנאי רישיון, מעריכים את עמדתכם כאשר ספק מגיש תביעה, ופועלים בהליכים בהם הסדר אינו זמין. אם ברצונכם לבחון את חוזי התוכנה שלכם, אנא צרו קשר עם עורכי הדין שלנו.
