רישיונות תוכנה בקוד פתוח תחת החוק ההולנדי והאירופי

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

מהו רישיון קוד פתוח, מבחינה משפטית

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

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

בתי המשפט ההולנדיים מיישמים נימוק זה. ב-Rb. Amsterdam 22 בספטמבר 2020, ECLI:NL:RBAMS:2020:4717, מפיץ שהסיר את טקסט הרישיון והודעת זכויות היוצרים מבסיס קוד מפוצל, נקבע כמי שאיבד את רשותו וכמי שהפר זכויות יוצרים. הוספת כמות גדולה של קוד חדש לא יצרה יצירה עצמאית: המקור נותר קיים באופן ברור, כך שהחובות עברו איתו.

שתי המשפחות: מתירניות וזכויות יוצרים

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

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

טריגר זכויות היוצרים ושאלת הקישור

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

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

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

AGPL ושימוש ברשת

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

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

תאימות רישיון

תאימות היא הבעיה של שילוב רכיבים שרישיונותיהם מטילים התחייבויות שלא ניתן לעמוד בהפצה אחת: רישיונות מתירניים תואמים כמעט לכל דבר, ורישיונות זכויות יוצרים תואמים רק למה שמאפשרים התנאים שלהם. המקרה הסטנדרטי הוא Apache 2.0 ו-GPLv2. קרן התוכנה של Apache וקרן התוכנה החופשית מסכימים שהשילוב אינו מותר, מכיוון שהוראות סיום הפטנט והשיפוי של Apache 2.0 הן הגבלות נוספות ש-GPLv2 אינו מאפשר. GPLv3 נוסח כדי לקבל אותן. תאימות היא גם כיוונית: קוד Apache יכול להיספג בפרויקט GPLv3, אך לא להיפך. רכיב GPL אחד במקום הלא נכון יכול לאלץ בחירה בין רישוי מחדש, הנדסה מחדש או הסרה - הרבה יותר זול לפני השחרור מאשר אחריו.

חובות ייחוס והודעה

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

מענקי פטנטים ופעולות תגמול על פטנטים

MIT ו-BSD אינם אומרים דבר על פטנטים, והאם רישיון פטנט יכול להיות משתמע אינו ברור. Apache 2.0 הוסיף רישיון פטנט מפורש ופטור מתמלוגים מכל תורם, בשילוב עם סעיף נקמה: להגיש תביעה משפטית בנוגע לפטנטים בטענה שהיצירה מפרה זכויות יוצרים ורישיון הפטנט שלך יפוג. GPLv3 מכיל מענק דומה והוראות פטנט משלו.

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

ה-EUPL והמגזר הציבורי ההולנדי

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

• שפה. הוא קיים בשפות הרשמיות של האיחוד האירופי, כאשר לכל הגרסאות המאושרות ערך זהה, כך שרשות הולנדית יכולה להתקשר בהולנדית.
• תְאִימוּת. נספח מפרט רישיונות תואמים - GPLv2 ו-v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL ו-CeCILL ביניהם - ומאפשר הפצה של יצירה נגזרת המשלבת קוד EUPL עם קוד תחת רישיון רשום תחת רישיון זה.
• לְהַגִיעַ. הגדרת ההפצה שלה כוללת הפיכת היצירה לזמינה באופן מקוון או לא מקוון. או מתן גישה לפונקציות החיוניות שלהוסעיף 5 לחוק ה-EUPL מעביר את חובת זכויות היוצרים עד לאינטראקציה מרחוק שבה מוצעת אותה פונקציונליות. לכן, היא מגיעה לתוכנה המסופקת כשירות, באופן ש-GPL לא עושה זאת.

ייתכן שלקוח במגזר הציבורי הולנדי לדרוש את ה-EUPL כעניין של מדיניות ולא כחוק. חוק אירופה לתפעול הדדי, תקנה (EU) 2024/903, מורה לגופים במגזר הציבורי לתעדף פתרונות פעולה הדדית ללא תנאי רישוי מגבילים, כגון קוד פתוח, כאשר הוא שווה ערך; ברמה הלאומית, עקרון הקוד הפתוח, tenzij, נשען על החלטות קבינט וקווי מדיניות, ולא על חוק: ה-Wet digitale overheid מאפשר את תשתית הזהות הדיגיטלית אך אינו מטיל חובה ניתנת לאכיפה לפרסם את כל קוד המקור. קרא את מסמכי המכרז: דרישת EUPL מחייבת את התוצר שלך ועשויה להיות לא תואמת לקוד קנייני שהתכוונת לעשות בו שימוש חוזר.

אכיפה בפועל

מי יכול לתבוע? בעל הזכויות - תורמים בודדים, או הקרן או החברה המחזיקות בזכויות יוצרים שהוקצו. זכויות יוצרים מקוטעות הן הבלם המעשי: תובע חייב להוכיח בעלות על הקוד המדובר. מקרה זה נכשל במקרה ה-GPL האירופי הידוע ביותר, שבו תביעה של מפתח ליבה נגד ספק וירטואליזציה נכשלה בשל חוסר הוכחת זכויות יוצרים (LG Hamburg 8 ביולי 2016, 310 O 89/15; אושר OLG Hamburg 28 בפברואר 2019, 5 U 146/16).

מה קובע הפסיקה. בתי המשפט הגרמניים קיבלו שוב ושוב כי רישיונות קוד פתוח הם תקפים וכי הפרה הופכת את ההפצה לבלתי חוקית, החל מצו המניעה הראשון של GPL (LG München I 19 מאי 2004, 21 O 6123/04). בית המשפט הפדרלי לערעורים של ארה"ב הגיע לאותה מסקנה ב- Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): תנאי רישיון הם תנאים להיקף ההענקה, לא רק התניות, ולכן הפרה תומכת בתביעת זכויות יוצרים ובסעד מניעה. התביעה הליטיגטיבית בארה"ב בוחנת האם מקבל רישיון במורד הזרם יכול לאכוף את ה-GPL כמוטב צד שלישי. זוהי השאלה המרכזית ב- Software Freedom Conservancy v Vizio בפני בית המשפט העליון של קליפורניה: האם צרכנים, כמוטבים צד שלישי, יכולים לדרוש שחרור קוד המקור במסגרת GPLv2. פסיקה סופית מהותית צפויה רק ​​לאחר משפט מושבעים בשנת 2026, כך שהנקודה טרם הוכרעה.

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

סעדים. צו מניעה לפי סעיף 3:296 לחוק הפשוט של ארצות הברית, בדרך כלל עם תשלום קנס וזמין בהליכים מקוצרים; פיצויים לפי סעיף 27 לחוק הפשוט של ארצות הברית וחשבון על רווחים לפי סעיף 27א לחוק הפשוט של ארצות הברית; החזרה, מסירה או השמדה לפי סעיף 28 לחוק הפשוט של ארצות הברית; והחזר מלא של הוצאות משפטיות סבירות ומידתיות לפי סעיף 1019h Rv. במקרים בהם תוכנה הופצה ללא תשלום, קשה לכמת את ההפסד, ובית משפט לערעורים גרמני סירב לפסוק פיצויים תוך שהוא מאשר את הצו (OLG Hamm 13 ביוני 2017, 4 U 72/16). מה שפוגע לעיתים רחוקות הוא פיצויים: זהו צו המניעה, החזרה, צו ההוצאות והצורך לפרסם מקור שמעולם לא התכוונת לפרסם.

כאשר אתה מגלה בעיית תאימות

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

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

קוד פתוח במיזוגים ורכישות ובדיקת נאותות

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

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

רשימת החומרים, סריקה וחוק חוסן הסייבר

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

חוק חוסן הסייבר, תקנה (EU) 2024/2847, נכנס לתוקף ב-10 בדצמבר 2024 והוא נכנס לתוקף בהדרגה. חובות הדיווח על פגיעויות שמנוצלות באופן פעיל ואירועים חמורים בסעיף 14 לחוק מעקב אחר סייבר (CRA) חלות החל מ-11 בספטמבר 2026; ההוראות בנוגע להודעה על גופי הערכת תאימות החל מ-11 ביוני 2026; התקנה במלואה החל מ-11 בדצמבר 2027 (סעיף 71 לחוק מעקב אחר סייבר). נספח I לחוק מעקב אחר סייבר דורש מיצרנים לזהות ולתעד את הרכיבים במוצר, לרבות על ידי הכנת רשימת חומרים של התוכנה בפורמט נפוץ וקריא על ידי מכונה, המכסה לכל הפחות את התלויות ברמה העליונה. אין צורך לפרסם אותו; רשויות מעקב השוק רשאיות לבקש זאת.

תוכנה חופשית וקוד פתוח המסופקת מחוץ לפעילות מסחרית אינה חלה על ה-CRA. התקנה מציגה את האחראי על תוכנה בקוד פתוח - אדם משפטי המעניק תמיכה מתמשכת לפיתוח תוכנה בקוד פתוח המיועדת לפעילויות מסחריות - עם חובות קלות יותר בסעיף 24 ל-CRA: מדיניות אבטחת סייבר מתועדת, שיתוף פעולה עם רשויות מעקב שוק ודיווח. אם אתם מסחורים קוד פתוח, או מממנים פרויקט שאחרים מסחורים, קבעו איזה תפקיד אתם ממלאים. הנציבות אימצה את ההנחיות הראשונות שלה ב-27 ביולי 2026: הנחיות הנציבות ליישום חוק חוסן הסייבר (CRA), המצורפות להודעה C(2026) 5252, העוסקות בין היתר בדברים מתי תוכנה חופשית וקוד פתוח נכללת במסגרת. לא אומץ חוק יישום הקובע פורמט לרשימת חומרי התוכנה, כך שהסטנדרט של התקנה עצמה - פורמט נפוץ וקריא על ידי מכונה - נותר המדד לעת עתה.

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

אם אתם מפרסמים קוד משלכם: CLAs ו-DCO

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

תעודת המפתח (Developer Certificate of Origin) , המשמשת את ליבת לינוקס ופרויקטים רבים אחרים, אינה מענק רישיון אלא אישור קליל, שנוסף כשורת חתימה לכל commit, שהתורם רשאי להגיש את הקוד תחת רישיון הפרויקט. פחות מעיק ופחות מגן: אין רישיון פטנט, אין רישוי מחדש.

אם רישוי כפול או רישוי חוזר עתידי אפשריים, השתמשו בהסכם זכויות יוצרים (CLA); אם הפרויקט הוא רכוש משותף אמיתי, ה-DCO בדרך כלל מספיק. כך או כך, ודאו שהסכמי ההעסקה והקבלן שלכם מקצים זכויות יוצרים בקוד שכותבים אנשיכם.

רשימת בדיקה מעשית למדיניות

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