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

מי הבעלים של קוד, עיצוב או מוצר שפותחו עבור סטארט־אפ על ידי פרילנסר או ספק חיצוני?

בסטארט־אפ צעיר, לא תמיד יש צוות פיתוח פנימי מלא. מייסדים רבים נעזרים בפרילנסרים, בתי תוכנה, מעצבים, מומחי UX/UI, יועצי מוצר, מפתחי no-code או ספקים מחו״ל כדי לבנות את ה־MVP, לפתח פיצ׳רים ראשונים, לעצב את הממשק או ליצור את המוצר הראשוני.

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

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

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

למה בעלות בקוד היא נושא קריטי לסטארט־אפ?

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

אם הבעלות בקוד או בעיצוב אינה מוסדרת, החברה עלולה להיתקל בבעיות מהותיות:

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

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

מה אומרת ברירת המחדל בחוק לגבי פרילנסרים?

יש הבדל חשוב בין עובד שכיר לבין פרילנסר.

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

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

המשמעות המעשית היא פשוטה: לא בונים סטארט־אפ על הנחות בעל פה. בונים אותו על הסכמים חתומים.

מה ההבדל בין רישיון שימוש לבין בעלות מלאה?

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

רישיון שימוש

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

בעלות מלאה

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

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

מה חייב להופיע בהסכם IP Assignment עם פרילנסר?

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

הסכם כזה צריך לכלול כמה רכיבים מרכזיים:

העברה מפורשת ובלתי חוזרת

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

הגדרה רחבה של התוצרים

ההסכם צריך לכלול לא רק את התוצר הסופי, אלא גם:

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

תחולה רחבה בזמן ובמקום

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

זכויות נלוות

ההסכם צריך להתייחס גם לזכויות נוספות, ככל שהן רלוונטיות:

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

הצהרה שאין זכויות צד שלישי

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

למה חשוב לחתום לפני תחילת העבודה?

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

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

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

האם התכתבות בדוא״ל מספיקה?

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

בדוא״ל לרוב חסרים פרטים חשובים:

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

לכן, גם אם יש התכתבות טובה, עדיף לא להסתמך עליה בלבד.

מהי זכות מוסרית ולמה חשוב להתייחס אליה?

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

בסטארט־אפ זה יכול להיות רלוונטי במיוחד ל:

• עיצוב UI/UX.
• לוגו ומיתוג.
• תוכן שיווקי.
• מצגות.
• איורים.
• סרטונים.
• ממשקים.
• ולעיתים גם תוצרי תוכנה מסוימים.

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

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

GitHub של החברה אינו מוכיח לבדו בעלות

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

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

לכן יש להפריד בין שני דברים:

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

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

למה GitHub פרטי של פרילנסר מסוכן במיוחד?

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

הבעיות האפשריות:

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

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

שימוש בקוד פתוח: מתי זה הופך לסיכון?

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

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

לכן, השאלה אינה רק האם נעשה שימוש בקוד פתוח, אלא:

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

מה צריך לעשות בפועל?

• לדרוש מהפרילנסר גילוי מלא על כל רכיב open source.
• לנהל רשימת רכיבים ורישיונות.
• להגדיר רישיונות מותרים ואסורים.
• לבצע סריקות קוד תקופתיות.
• לקבוע אישור מראש לשימוש ברישיונות רגישים.
• לתעד את השימוש בדאטה רום לקראת השקעה או רכישה.

האם NDA מספיק כדי להגן על הקוד?

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

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

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

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

ההגנה הנכונה היא שילוב של שני מנגנונים:

• NDA לפני חשיפת מידע רגיש.
• IP Assignment לפני תחילת הפיתוח או העיצוב.

עבודה עם ספקים בחו״ל: מה חייבים להסדיר?

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

בהסכם עם ספק בחו״ל חשוב להסדיר:

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

מנגנונים מסחריים שמצמצמים סיכון

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

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

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

מה עושים אם כבר פיתחו בלי הסכם?

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

במצב כזה, כדאי לפעול מהר:

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

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

סיכון נפוץ ומה צריך לעשות

איך משקיעים ורוכשים בודקים את הנושא?

בבדיקת נאותות, משקיע או רוכש יבקשו לראות:

• הסכמי העסקה עם מייסדים ועובדים.
• הסכמי IP Assignment עם פרילנסרים וספקים.
• הסכמי NDA.
• רשימת ספקי פיתוח ועיצוב.
• רשימת קבלני משנה.
• גישה או תיעוד של מאגרי קוד.
• רשימת רכיבי קוד פתוח.
• רישיונות תוכנה חיצוניים.
• בעלות בדומיינים, חשבונות ענן וחשבונות פיתוח.
• הצהרות שאין טענות או תביעות IP.

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

שאלות נפוצות

סיכום: תשלום אינו בעלות, והנחה בעל פה אינה מגינה על סטארט־אפ

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

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

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

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

אודות המחבר: עו״ד משה כאהן

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

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