בקצרה: קוד פתוח לא אומר ״ללא תנאים״. כל רישיון קוד פתוח מטיל חובות משלו, וחלקן — כמו חובת מסירת קוד המקור של המוצר שלכם — מסוכנות מאוד לעסקים מסחריים. לא עמדתם בתנאי הרישיון, במודע או בטעות? שימוש שחורג מהרישיון עלול להיות הפרת זכות יוצרים (סעיף 47 לחוק זכות יוצרים), ובית המשפט רשאי לצוות עליכם להפסיק להפיץ את המוצר (צו מניעה, סעיף 53).

עמוד השירות: עורך דין מסחר דיגיטלי ו-AI: תקנון, פרטיות ודיוור.

קוד פתוח — בלי תשלום, אבל לא בלי חובות

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

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

שאלה על המקרה שלכם? כתבו בוואטסאפ · 050-431-3155

הרישיונות העיקריים ומה הם דורשים

MIT ו-Apache 2.0 — הרישיונות המתירניים ביותר. מאפשרים שימוש מסחרי, שינויים, ושילוב בקוד קנייני. דרישה עיקרית: ציון הייחוס המקורי (attribution). חברות כמו גוגל ומיקרוסופט אוהבות רישיונות אלה.

GPL (GNU General Public License) — ״רישיון ויראלי״. אם שילבתם קוד GPL במוצר שאתם מפיצים, תצטרכו לתת רישיון GPL ליצירה המשולבת כולה ולמסור למקבלים את קוד המקור שלה (סעיפים 5(c) ו-6 לרישיון GPLv3); שימוש פנימי בלי הפצה אינו מפעיל את החובה (סעיף 2). עבור חברות שמוכרות תוכנה קניינית — זה עשוי להיות הרסני.

LGPL — גרסה מוקלת של GPL המאפשרת שימוש בספרייה מבלי להדביק את כל הפרויקט. כלומר, ניתן לקרוא לספריית LGPL מקוד קנייני.

AGPL — גרסה מחמירה של GPL: מי ששינה את התוכנה ומאפשר למשתמשים לתקשר איתה מרחוק דרך רשת חייב להציע להם את קוד המקור של הגרסה שלו (סעיף 13 לרישיון) — גם בלי להפיץ עותק. זה הרישיון שמפחיד הכי הרבה חברות SaaS ישראליות.

כלל אצבע: MIT ו-Apache — בסדר לשימוש מסחרי. כל גרסת GPL — דרוש ייעוץ משפטי לפני שילוב בקוד קנייני.

מה קורה כשמפרים רישיון קוד פתוח?

שימוש שחורג מתנאי רישיון קוד פתוח עלול להיות הפרת זכות יוצרים (סעיף 47), ולא רק הפרת חוזה. בישראל, חוק זכות יוצרים, התשס״ח-2007, מגן על תוכנת מחשב כיצירה ספרותית (סעיף 1). לתוכנת מחשב אין זכות מוסרית (סעיף 45(א)), ולכן חובת הייחוס בקוד פתוח נובעת מתנאי הרישיון עצמו. התרופות כוללות צווי מניעה (סעיף 53) ופיצויים ללא הוכחת נזק של עד 100,000 ₪ לכל הפרה, כשהפרות במסכת אחת של מעשים נחשבות הפרה אחת (סעיף 56).

ארגונים כמו Software Freedom Conservancy עוקבים אחר הפרות GPL ונוקטים פעולה משפטית — גם מחוץ לארה״ב.

שאלה על אתר, פרטיות, תנאי שימוש או AI בעסק?אחזור אליכם בשעות הפעילות (א׳–ה׳, 9:00–18:00).

050-431-3155

בדיקת ציות לרישיונות

כל חברה שמשתמשת בקוד פתוח צריכה לבצע ״audit״ של הרישיונות שבשימוש. כלים כמו FOSSA, Black Duck, ו-Snyk עושים זאת אוטומטית. בתהליך M&A, בדיקת רישיונות קוד פתוח היא חלק סטנדרטי מה-due diligence.

קראו גם בנושא

עמוד התחום: היבטים משפטיים של מסחר מקוון

רישיון AGPL: המלכודת המיוחדת לחברות SaaS

רישיון AGPL (GNU Affero General Public License) מרחיב את חובת מסירת קוד המקור גם למקרה שהתוכנה לא מופצת בכלל: מי ששינה את התוכנה ומאפשר למשתמשים לתקשר איתה מרחוק דרך רשת חייב להציע להם את קוד המקור של הגרסה שלו (סעיף 13 לרישיון). חברת SaaS שמשלבת ספרייה בעלת רישיון AGPL בשירות שלה, בלי להפיץ אף עותק של התוכנה למשתמש, עשויה להיות מחויבת להציע למשתמשים את קוד המקור של הגרסה ששינתה — ולעתים גם של קוד קנייני שנכתב בתוך החברה, אם הוא חלק מאותה יצירה. זו הפתעה נפוצה למפתחים שמכירים רק רישיונות מתירניים כמו MIT או Apache, ולא בודקים אם מישהו בערימת התלויות (dependencies) הסמויה כלל את ה-AGPL.

שימוש בקוד פתוח בחברה ישראלית — רשימת בדיקה

לפני שמוסיפים ספריית קוד פתוח למוצר — ענו על השאלות האלה:

  1. איזה רישיון? MIT/Apache — ירוק. GPL — דגל אדום. AGPL — דגל אדום כפול לשירותי ענן
  2. האם אתם מפיצים את הקוד? אם כן — GPL מחייב אתכם למסור למקבלים את קוד המקור של היצירה המשולבת (סעיפים 5(c) ו-6 לרישיון)
  3. האם ציינתם ייחוס? ייחוס חסר (שם המחבר, קישור לרישיון) הוא הפרה נפוצה — גם ב-MIT
  4. בדקתם את ה-dependencies? לא רק את הספרייה עצמה — אלא גם את מה שהיא מביאה איתה. GPL יכול ״להידבק״ דרך שרשרת
  5. יש לכם מדיניות פנימית? חברות בוגרות מחייבות אישור ממונה לפני הוספת כל רכיב פתוח עם רישיון מחמיר

מה עושים אם גיליתם הפרה?

הצעד הנכון:

מקורות

הקישורים מפנים לנוסח החקיקה במקור. הנוסח המחייב הוא זה שפורסם בספר החוקים.

מה בודקים בפועל

  • טיפ פרקטי: בעסקאות M&A, דרשו מהחברה הנרכשת רשימת כל רכיבי קוד פתוח ורישיונותיהם — SBOM (Software Bill of Materials). הפרת GPL שלא התגלתה לפני הרכישה יכולה להפוך לחבות משמעותית.
  • הפניה חקיקתית: חוק זכות יוצרים, התשס״ח-2007: סעיפים 47–48 (מהי הפרה, לרבות הפרה עקיפה); סעיף 52 (הפרה היא עוולה אזרחית); סעיף 53 (צו מניעה); סעיף 56 (פיצויים ללא הוכחת נזק עד 100,000 ₪ לכל הפרה).
  • טעות נפוצה: לייעץ ללקוח ש״קוד פתוח = מותר לשימוש חופשי״. כל רישיון הוא חוזה — יש לקרוא אותו.
  • נקודה טקטית: כשמייעצים לסטארטאפ, הכניסו סעיף ל-IP Policy הפנימי שמחייב אישור מחלקת משפטית לפני הוספת כל ספריית קוד פתוח עם רישיון מחמיר.
הבהרה משפטית: המידע במאמר זה נועד לצרכי מידע כללי בלבד ואינו מהווה ייעוץ משפטי, חוות דעת או תחליף להתייעצות עם עורך דין. כל מקרה ייחודי ויש לבחון אותו לגופו. אין ליישם את המידע ללא ייעוץ משפטי פרטני.