קוד מ-GitHub במוצר מסחרי: רישיונות ומה צריך לבדוק

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

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

מידע מעשי על עבודה עם Ailoot מופיע בתיעוד.

האם נכון שאם קוד נמצא ב-GitHub, מותר להשתמש בו בחינם?#

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

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

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

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

מה קובע אם מותר לכם להשתמש בקוד של מישהו אחר?#

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

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

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

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

אילו רישיונות מאפשרים להשתמש בקוד ולמכור מוצר?#

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

הנפוץ והפשוט ביותר הוא MIT. הנוסח שלו נכנס לפסקה אחת.

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

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

BSD (בגרסאות עם 2 ו-3 סעיפים) דומה בעיקרו ל-MIT: להשתמש, לשנות, למכור ולשמר את הודעת זכויות היוצרים. ריכזתי את שלושתם בטבלה כדי שתוכלו לראות את ההבדלים במבט אחד.

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

איך חלות חובות מסירת קוד המקור של GPL ו-AGPL?#

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

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

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

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

מה לעשות אם אין במאגר קובץ רישיון כלל?#

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

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

מה לעשות בפועל אם לקוד אין רישיון אבל אתם באמת זקוקים לו:

1. כתבו למחבר. פנו אליו ישירות באזור הדיונים של המאגר או בדוא״ל, ושאלו אם מותר לכם להשתמש בקוד ובאילו תנאים. לפעמים המחבר פשוט שכח להוסיף רישיון, ויוסיף אותו אם תבקשו.
2. חפשו תחליף. כמעט לכל משימה יש מאגר דומה שני, שלישי ועשירי — ביניהם תמצאו אחד עם רישיון MIT או Apache תקין.
3. אל תשתמשו בו. אם אין לכם רשות ואין תחליף, הקוד אינו שלכם, ואסור לכם לשלב אותו במוצר שבכוונתכם למכור. הפיתוי לחשוב „מי כבר יגלה?” נגמר רע בדיוק כשהמוצר מתחיל להרוויח כסף ולמשוך תשומת לב.

מה אם Claude עצמו הוסיף לפרויקט קוד של מישהו אחר?#

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

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

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

איך לבדוק רישיון לפני שימוש בקוד: השלבים#

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

1. מצאו את שם הרישיון בדף המאגר

   פתחו את המאגר ב-GitHub. שם הרישיון מופיע בדרך כלל בעמודה הימנית או מתחת לרשימת הקבצים — למשל, „MIT License”, „Apache-2.0” או „GPL-3.0”. אם השדה ריק ואין קובץ רישיון, זה כבר סימן אזהרה; חזרו אליו בשלב האחרון.

2. פתחו את קובץ הרישיון עצמו

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

3. זהו את הסוג: מתירני או Copyleft

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

4. השוו אותו למקרה שלכם

   ענו על שלוש שאלות: האם אתם מוכרים את המוצר, האם אתם משנים את הקוד, והאם אתם רוצים להשאיר את קוד המקור סגור? MIT, Apache ו-BSD מתאימים למוצר סגור למכירה. ב-GPL וב-AGPL קבעו לאיזו יצירה מכוסה או משולבת יידרש קוד מקור מתאים ומתי נוצרת החובה; בדקו אם תוכלו לעמוד בתנאים האלה.

5. אין רישיון? אל תשתמשו בו

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

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

עברו אל Ailoot.