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