מדוע ה–GPL אינו „ויראלי”

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

אלא שלדעתי הוא לא.

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

כדי להמחיש את הנקודה, אני מציע את הניסוי המחשבתי הבא. שתי חברות מייצרות מוצר מאוד דומה. אחת משתמשת בלינוקס בתור התשתית שלה למוצר, ואחת בחלונות. שתי החברות עושות כן מבלי לקבל את ההסכמה הנדרשת מבעל הזכויות (הראשונה ע״י כך שאינה עומדת בתנאי הרשיון של ה–GPL, והשניה ע״י שלא חתמה על ההסכם המתאים עם מיקרוסופט/לא שילמה על עותקי מערכת ההפעלה שהיא שילבה במוצר). אמרו לי, לו אתם מייצגים קרן הון סיכון. איזו חברה נמצאת, לדעתכם, בסיכון גדול יותר? איפה פוטנציאל הנזק הכלכלי גדול יותר? היכן עלות החזרת המוצר לתנאי עמידה ברשיון תהיה קטנה יותר? אני חושב שדי ברור שהחברה שהתבססה על לינוקס נמצאת במצב הרבה יותר טוב, על אף ה„ויראליות” של הרשיון שהופר.


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

לצורך הדיון בואו נניח שחברת קניין רוחני בע״מ (להלן: החברה) מייצרת מוצר קנייני שאותו היא מוכרת על פי המודל המקובל, ללא שחרור קוד המקור. בואו עוד נניח שהחברה, בתום לב (נגיד, קבלן משנה לא זהיר) שילבה בתוך המוצר שלה קוד ששוחרר תחת רשיון ה–GPL בצורה שללא עוררין דורשת, לצורך עמידה בתנאי הרשיון, שגם הקוד הראשי של החברה ישוחרר תחת GPL. בואו עוד נניח שגרסאות מפרות כבר שוחררו ללקוחות. לסיום, בואו נניח שבעל הזכויות הוא גוף שאין סיכוי שיסכים להנפיק להם רשיון קנייני. לצורך הדיון, בואו נניח שהקוד בא מפרוייקט GNU, ובעל הזכויות הוא ה–FSF.

בואו ננתח שני מקרים.

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

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

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

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

ומה אם השמיים נופלים, והפעם הראשונה שבה שומעים על העובדה שקיימת הפרה היא באמצעות כתב תביעה? אפילו במקרה זה, אני לא רואה מצב שבו החברה מחוייבת לשחרר את הקוד שלה. ראשית, לחברה עומדת הגנת „מפר תמים”. במילים אחרות, בהחלט ייתכן שאם החברה תראה מאמץ כן לפתור את בעיית ההפרה באחת משתי הדרכים שצויינו לעיל, לא יחייבו אותה במתן פיצויים כלל. אפילו אם לא, רשיון ה–GPL מגדיר היטב את הסנקציה שעומדת כנגד משתמש שלא עומד בתנאי הרשיון. הסנקציה היא שהרשיון ישלל ממנו. אין שם אף מילה על חיוב שחרור של שאר הקוד. במילים אחרות, אם ה–FSF תובע את החברה על כך שהפרה את תנאי הרשיון, הוא יכול לזכות בנזקים על ההפרה שבוצעה (שהיא הפצת יצירה מוגנת ללא רשיון), והוא יכול לזכות בצו מניעה שמונע מהחברה להמשיך ולהפיץ את הקוד המפר, אבל לא ידוע לי על מקרה, ועל פי מיטב הבנתי, אין תימוכין בלשון הרשיון, לכך שהוא יכול לדרוש מהחברה להפיץ את הקוד שבו היא בעלת זכויות היוצרים.

וחשוב להבהיר: אלע״ד זלע״ם
אני לא עורך דין
זו לא עיצה משפטית

שחר

מאת

שחר שמש

מייסד–שותף וחבר ועד בתנועה לזכויות דיגיטליות מייסד שותף בעמותת „המקור”. פעיל קוד פתוח. מפתח שפת התכנות Practical

2 תגובות בנושא “מדוע ה–GPL אינו „ויראלי””

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

    כמשתמש צעיר, לפני שנקלעתי לעולם העסקי, GPL סימל עבורי חופש. יותר חופשי מ- LGPL ו- BSD-style.
    מכשהתחלתי להשתפשף עם העולם העסקי, בתחילה היה לי קשה קצת להבין איך התמונה הפוכה: עבור מי שעוסק בפיתוח תוכנה בעולם העסקי שאינו מייצר קוד פתוח (יש שם לא רק אנשים מרושעים!), הבחירה ה*חופשית* היא LGPL ו- BSD-style. הילד הרע הוא דווקא GPL.

    וההסבר הכי פשוט מדוע GPL הוא רע, האמירה הי ש- GPL *מדביק* גם את הקוד שלך ברשיון (אם אתה הגון ועובד לפי תנאי הרשיון כמובן). אני חושב שזו הדרך הכי מדוייקת לנסח את הבעייתיות של GPL בעולם העסקים, וכל ניסוח אחר הוא יופימיזם. ני מעדיף את “מדבק” מאשר “ויראלי” כי הוא יותר מדוייק ופחות שלילי. אשמח לתיקון אם לא הבנתי נכון, כמובן.

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

  2. אני חושב שהעמדה שלך לא נכונה.

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

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

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

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

    שחר

סגור לתגובות.