These are very important questions, since components that are distributed to the general public are more exposed to product scrutiny and greater compliance with the license. This is in contrast to components that are developed and remain within the company, which are subject to criticism by the company's employees only (with emphasis on the legal department).
I will demonstrate for simplicity: Suppose a company uses open source software to develop software that calculates purchasing costs for the company. In addition, the company uses open source to develop a product sold to customers. While the use of the first open code is only exposed to users of the system who are employees of the company, the use of the second open code is exposed to anyone who decides to purchase the company's product. The use of the purchasing costs software is the internal use and use of the software distributed to the customer is the external use. The Company should note that these uses may change as the Company's business portfolio changes so that the previously used code will become external and will result in a change in the Company's legal liability with respect to the copyright of the original source code creator. For example, if the company decides to sell the software it has developed to calculate acquisition costs for other companies? Therefore, sometimes we prefer to be stringent and maintain high standards of compliance in any use of open source within the company.
It is important to pay attention to the license to which the user is subject to open source in order to understand the legal rights of the work derived from this code. As mentioned above, open source code that is subject to the GPL license, for example, requires the user to distribute all the developments of this code as open source. Therefore, a start-up that produces an amazing product that contains open source code that is subject to the GPL license actually creates a new open source without any unique copyright value. This may alienate investors, who will discover the matter at the company's due diligence stage.
In summary, the use of open source is welcome and makes it very easy for users and entrepreneurs to create their own projects while enjoying quality code elements at no additional cost. On the other hand, open source is sometimes protected by copyright which requires the user to act in a certain way that limits his rights in the derivative work. Therefore, it is important to pay attention to which open source components are used, what licenses the components are subject to, and what the legal consequences of this use are, in order to reduce infringement of the rights to the product developed by the company.
The information presented should not be viewed as legal advice and should not be relied upon as such. The information may be out of date and may change at any time without notice or post facto.
כיצד לפעול נכון כדי למזער את החשיפה המשפטית בשימוש בקוד פתוח?
ראשית, חשוב מאוד לתעד את השימוש בקוד פתוח במסגרת המיזם במסמך אחד מרוכז. יש לדעת לגבי כל קוד פתוח בו נעשה שימוש את הדברים הבאים- תוכן הקוד הפתוח, הרישיון שניתן לקוד הפתוח (ומה נדרש במסגרת ציות לרישיון), דרישות נוספות במידה וישנן, (לדוגמא Copyrights – היוצר דורש, במסגרת הרישיון, קרדיט שיינתן לו עבור כל שימוש בקוד הפתוח) ולבסוף – לאיזה רכיב במוצר מתחבר הקוד הפתוח? האם מדובר ברכיב שמופץ מחוץ לחברה או שנשאר בתוך החברה?
מדובר בשאלות חשובות מאוד, שהרי רכיבים אשר מופצים לקהל הרחב, חשופים יותר לבחינה של המוצר ואכיפה גבוהה יותר של ציות לרישיון. זאת למול רכיבים שמפותחים ונשארים בתוך החברה, אשר חשופים לביקורת מצד עובדי החברה בלבד (בדגש על המחלקה המשפטית).
אדגים לצורך הפשטה: נניח וחברה עושה שימוש בקוד פתוח לצורך פיתוח תוכנה שמחשבת עלויות רכש לחברה. בנוסף, החברה עושה שימוש בקוד פתוח לצורך פיתוח מוצר שנמכר ללקוחות. בעוד שהשימוש בקוד הפתוח הראשון חשוף רק למשתמשי המערכת שהינם עובדי החברה, השימוש בקוד הפתוח השני חשוף לכל אדם שיחליט לרכוש את מוצר החברה. השימוש לצורך תוכנת עלויות הרכש הוא השימוש הפנימי והשימוש בתוכנה המופצת ללקוח הוא השימוש החיצוני. על החברה לשים לב ששימושים אלה עלולים להשתנות ככל שהפורטפוליו העסקי של החברה משתנה כך שקוד ששימש בעבר כפנימי, יהפוך חיצוני ויגרור שינוי של החבות המשפטית של החברה ביחס לזכויות היוצרים של יוצר קוד המקור הראשוני. לדוגמא, אם החברה תחליט למכור את התוכנה שפיתחה לצורך חישוב עלויות רכש לחברות אחרות? לכן, לעיתים נעדיף להחמיר ולשמור על סטנדרטים גבוהים של ציות בכל שימוש של קוד פתוח במסגרת החברה.
חשוב לשים לב לרישיון אליו כפוף המשתמש בקוד הפתוח על מנת להבין את הזכויות המשפטיות של היצירה הנגזרת מקוד זה. כאמור, קוד פתוח הכפוף לרישיון GPL לדוגמא, מחייב את המשתמש להפיץ את כל הפיתוחים של קוד זה כקוד פתוח. ולכן, סטארט-אפ שמייצר מוצר מדהים אשר מכיל בתוכו קוד פתוח הכפוף לרישיון GPL, למעשה יוצר קוד פתוח חדש ללא ערך ייחודי מבחינת זכויות יוצרים. הדבר עשוי להרחיק משקיעים, שיגלו את הנושא בשלב בדיקת הנאותות של החברה.
לסיכום, שימוש בקוד פתוח הינו מבורך ומקל מאוד על משתמשים ועל יזמים ליצור את המיזמים שלהם תוך הנאה מרכיבי קוד איכותיים ללא עלות נוספת. מאידך, קוד פתוח מוגן לעיתים בזכויות יוצרים אשר מחייבות את המשתמש לפעול בצורה מסוימת שמגבילה את זכויותיו ביצירה הנגזרת. לכן, חשוב לשים לב באיזה רכיבי קוד פתוח משתמשים, מה הרישיונות להם אותם רכיבים כפופים ומה ההשלכות המשפטיות של שימוש זה, כדי לצמצם פגיעה בזכויות במוצר אותו פיתחה החברה.
אין לראות במידע המוצג כייעוץ משפטי ואין להסתמך עליו ככזה. המידע עשוי להיות לא מעודכן ולהשתנות בכל עת ללא הודעה מראש או בדיעבד.