איך בונים סטארט-אפ עם קוד של אחרים [הרצאה לכנס אופןאיזראל 2010]

0.
ביום ה' הקרוב אעביר הרצאה במסגרת כנס OpenIsrael2010 על בניית סטארט-אפ עם קוד של אחרים; זה התקציר. סטארטאפ טוב בנוי על שני נדבכים: רעיון ומודל עסקי. הרעיון הוא המהות, בעוד שהמודל העסקי הוא רק הדרך לייצר כסף מאותה מהות (ועל ידי כך לתת הצדקה עסקית למהות). לכן, כאשר גיבשת רעיון טוב, אתה צריך להתחיל לבחון איך אתה מבצע אותו. רעיון טוב הוא פתרון לבעיה שקיימת לך ועד כה לא קיבל פתרון. הוא לא חייב להיות גרנדיוזי במיוחד (והרי יאהו! התחילו בתור מדריך אתרי אינטרנט, ICQ התחיל בתור דרך לדעת אם בחורה מסוימת אונליין וקרייגזליסט החל בתור הדרך של קרייג ניומארק להודיע לחברים במייל על אירועים מגניבים). לצורך ההרצאה הזו, הרעיון שלנו יכול להיות אתר, אפליקציה או פלטפורמה לאחרים; אם הבעיה שלנו, לדוגמא, היא לזכור היכן חנינו עם הרכב, ניתן לפתור אותה במספר דרכים.

1.
עכשיו, אחרי שגיבשנו את הרעיון שלנו, אנחנו היינו בדרך כלל צריכים ללכת ולחפש מפתחים שיבנו אותו מאפס. וכעת עומדות בפני המפתח שתי חלופות (או בעצם שלוש). החלופה הקניינית מתחלקת לשתיים: לשלם למפתחים שיפתחו את האפליקציה מאפס או לרכוש מערכת מוכנה ולהתאים אותה אישית; לעומת זאת החלופה הפתוחה היא מעניינת יותר: למצוא רכיבים בקוד פתוח שמתאימים (בערך) לאפליקציה, ולהתאים אותם אישית. כאן צריך להבין שההחלטה היא עסקית נטו והרבה פעמים תהיה תלויה במודלים עסקיים. החלופה הקניינית אינה, כמובן, נושא ההרצאה, ולכן נשים אותה בצד. ונניח שהחלטנו לצאת במודל הקוד הפתוח. כעת, צריך לבחון איזה רכיבים קיימים בשוק. לדוגמא, נוקיה מפרטת כתריסר אפליקציות פייתון למציאת מיקום כאשר חלק מהן משוחררות ברשיונות קוד פתוח. אבל, צריך לזכור שקוד פתוח זה לא סוג אחד של רשיון, אלא יש מאות רשיונות שהפופולריים בינהם הם הGPL וMIT, אבל ישנם רשיונות פחות פופולריים, ומצחיקים לא פחות כמו הWTFPL או Beer License שמחייב את המשתמש בתוכנה, אם הוא חושב שהיא שווה משהו, לקנות למפתח המקורי בירה אם הם נפגשים. כלומר, גם אחרי שיש לנו רעיון, אנחנו עדיין צריכים לבחון איך המודל העסקי שלנו יושפע על ידי הרישוי, ומה ההשפעה של הרשיון על היכולת שלנו אחר כך להמשיך לפתח את הרעיון.

2.
ככלל, ההגדרה של תוכנות קוד פתוח, לפי עשרת הדיברות של יוזמת הקוד הפתוח הן פשוטות: (1) הרשיון מאפשר הפצה חופשית של הקוד; (2) למקבל הרשיון יש את הזכות לקבל גם את קוד המקור של התוכנה; (3) מותר לייצר יצירות נגזרות מהתוכנה (כלומר, מותר לך לשנות אותה); (4) ניתנת גישה לתוכנה המקורית ממנה נוצרה התוכנה; (5) אין אפליה בין בני אדם או קבוצות בשימוש בתוכנה; (6) אין אפליה בין מטרות או שימושים; (7) הזכויות הצמודות לרשיון מוצמדות לכל הפצה נמשכת; (8) הזכויות אינן צמודות למוצר ספציפי אלא לקוד תוכנה; (9) הרשיון לא יכול להגביל תוכנה אחרת ו(10) הרשיון נייטרלי מבחינה טכנולוגית. כך, לדוגמא, ארגון זכויות בעלי החיים פיתה הכריז לפני מספר שבועות על השקת רשיון Harmless Permissive License שמטרתו הפצה של הקוד למטרות שאינן מזיקות לבעלי חיים. הרשיון הזה, לדוגמא אינו עומד בסטנדרטים של יוזמת הקוד הפתוח, כיוון שהוא מפלה בין מטרות.

3.
אולם, סביר להניח שבמקרה הטוב הבחירה תהיה בין שתי חלופות קוד: אחת במודל שהוא Reciprocal והשני הוא Permissive; ההבדל בין השתיים הוא שמיים וארץ. הקבוצה הראשונה היא קבוצה אליה משתייכים הGPL, RPL, והMs-RL של מיקרוסופט (ועוד כמה). המיוחד במשפחות אלה הוא האפקט הויראלי: כל שימוש בקוד שניתן תחת הרשיון הזה מחייב שכל שימוש עתידי יהיה רק באמצעות אותם הרשיונות ולא בשום צורה אחרת; המשמעות של זה היא שכל פיתוח של אפליקציה על סמך תוכנה ששוחררה ברשיונות האלה לא תוכל להיות בצורה קניינית וגם תדרוש ממך להפיץ את הקוד הלאה ללקוחות; גם אם לא את כל קוד התוכנה, הרי שעדיין תהיה חובה ועשויה לקום אי-ודאות משפטית. הרשיונות ממשפחת הPermissive הם לדוגמא הPHP, Artistic, Apache וMIT. אם פיתוח האפליקציה יהיה על סמך הרשיונות האלה, הרי שניתן יהיה לשלב אותן עם קוד קנייני ולא לשחרר לציבור את הסוד המסחרי: קוד התוכנה.

4.
לכן, השאלה של "איזה רשיון לבחור" היא שאלה של מודל עסקי נטו; הרשיונות ממשפחת הRecipriocal דורשים שקוד המקור של התוכנה ישוחרר לאחר שבוצעו בו שינויים (בחלק מהמקרים מדובר על כל קוד המקור ובחלקים אחרים רק חלק), מה שעשוי למנוע את היכולת לגבש מודל עסקי שמבוסס על מכירת התוכנה, או אפילו הצגת פרסומות בה. דמיינו שקרן מוזילה, המפתחת של פיירפוקס, היתה בוחרת יום אחד להציג פרסומות בתוך הדפדפן כמודל עסקי; כיוון שהקוד משוחרר תחת רשיון MPL, הרי שכל אדם שמקבל עותק מFirefox זכאי לקבל גם את קוד המקור ולהפיץ אותו הלאה עם השינויים שהכניס בו. לכן, הייתי יכול להוריד את הקוד, לבצע את השינוי ולהסיר את הפרסומות, ואז להפיץ הלאה את הדפדפן. כך היה, אגב, במקרה אחר אבל דומה. כיום יש ויכוח לא קטן ברשת על וידאו, האם להציג אותו בטכנולוגית Flash או HTML5. האתר יוטיוב בחר להשתמש בHTML5 עם מקודד וידאו בטכנולוגיות H.264, שהיא טכנולוגיה קניינית שמוגנת בפטנט. ולכן, כשהמפתחים של Firefox החליטו לא לאמץ את הטכנולוגיה כדי לא לשלם תמלוגים על פטנטים בתוכנה הם ביצעו החלטה כלכלית ומשפטית נכונה. אולם, הם עשו זאת כיוון שהם נמצאים בארצות הברית, שם יש פטנטים על תוכנה. מנגד, בשאר העולם אין פטנטים על תוכנה, ולכן פרויקט כמו WildFox יכל לצוץ. הפרויקט הזה הוא נטילה של הקוד של פיירפוקס, עם הטמעה של מקודד H.264 שמיועד לארצות בהן אין פטנטים על תוכנה.

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

5.
מנגד, חלק ניכר מהפיתוחים כיום בכלל לא דורשים הפצה של תוכנה או קוד, אלא מבוססי Web (או שירותי Cloud). במצב כזה, צריך להבין שהרשיון אינו מגביל את השימוש בתוכנה, ולכן ניתן ללקט תוכנות בעלות רשיונות שונים, לחבר בינהם ואפילו לבנות עליהם אפליקציות רבות (כל עוד לא מדובר ברשיונות ממשפחת Affero GPL אשר מחייבים הפצה של כל שינוי שמוכנס בקוד גם אם מדובר על Web-Based). כך, ניתן לבנות אפליקציות רבות תוך הכנסת שינויים לקוד המקור, התאמה של יחידות שונות והטמעת כולן יחד, מבלי לחשוש כי יתגלה צורך לחשוף את הסודות המסחריים. כאשר העסק הוא הפצת חומרה, הרי שהרצון של מפיץ החומרה אמור להיות לאפשר למשתמשים כמה שיותר פיתוחים על סמך החומרה, ולכן רשיון Reciprocal אמור להיות רצוי.

חשבו על סטארט-אפ היום שבסך הכל בונה רשת חברתית לגברים שאוהבים גזר; הוא שוכר שרת (וירטואלי או לא) שמריץ מערכת הפעלה (ככל הנראה לינוקס) שמשוחררת בקוד פתוח, עם שרת ווב (כנראה Apache) ומפתח את האתר בשפת PHP. גם אם האתר נכתב במלואו על ידי מפתח, הרי שהוא עדיין תלוי ברכיבי קוד פתוח שחסכו לו אלפי דולרים; כעת, הוא יכול להתקין את elgg, רשת חברתית בקוד פתוח, ולהקים את האתר שלו בהשקעה של כמה אלפי דולרים בודדים. מנגד, ותמורת ההנחה הזו, אם הוא אי פעם יחליט להפיץ את הקוד או לעשות כסף ממכירה של התוכנה ששינה (אבל לא את האתר, כי אם הוא עושה אקזיט אין בעיה) אז הוא צריך להחזיר את התרומה שלו חזרה לקהילה. בסך הכל, מדובר בעסקה הוגנת, לא?

6.
אחרי שנבחרה האפליקציה והרשיון הראוי, ונבדק שהם לא מתנגשים עם המודל העסקי. השאלה שעולה היא האם שחרור של הקוד יפגע לך ביכולת להתפרנס או לא. לדוגמא, לפני כשנה דווח כי מיקרוסופט עשתה שימוש בעת פיתוח מערכת ההפעלה שלה בקוד שהיה "נגוע" בGPL. במקרה הזה, מיקרוסופט נדרשה לשחרר את קוד המקור של השינויים שערכה באפליקצית USB/DVD Download. אולם, סביר להניח שהשחרור הקטן הזה לא פגע במרכז הרווח והמודל העסקי של מיקרוסופט. אולם,לא בכל המקרים תהיה חובה לשחרר את כל הקוד, גם אם מפותחות תוכנות שמבוססות על קוד ששוחרר בGPL. בדרך כלל, רצוי להוועץ בעורך דין לעניין הזה, אבל אם רוצים לעמוד בצד הבטוח, עדיף לשחרר כל עוד הדבר לא פוגע במודל העסקי; ורק אם יש סכנה למודל העסקי להוועץ עם עורך דין לפני שהתוכנה תשוחרר.

7.
לסיכום: (1) לא כל רשיונות התוכנה החופשית והקוד הפתוח זהים; (2) גם אם בונים סטארט-אפ על קוד של מישהו אחר, אין תמיד חובה לשחרר את כל הקוד; (3) המודל העסקי מכתיב, הרבה פעמים, האם ישתמשו באלמנטים ששוחררו תחת רשיונות קוד פתוח או לא ו(4) ההחלטה האם לשחרר את הקוד היא יותר מכל החלטה עסקית.

19 thoughts on “איך בונים סטארט-אפ עם קוד של אחרים [הרצאה לכנס אופןאיזראל 2010]

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

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

    הבעיה היא שאי אפשר לעשות את זה בהרצאה של 20 דקות.

  3. תודה על ה"פוסט השטחי", יהונתן – לא הייתי מודע למשמעות של AGPL. הפוסט בהחלט מעניין; אין ספק שאם תבחר גם להתעמק יותר (בעיקר ביצירות נגזרות) אשמח!

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

  5. קוקו,
    לא התייחסתי לLGPL מהרבה סיבות. אחת מהן היא התשובה לשאלה של יהודה: הוא לא רשיון Permissive אבל הוא לא ממש Reciprocal. הוא רשיון בעייתי ולא ממש בטוח שהוא אחד מהשניים, הוא חל רק על חלקי קוד (בדומה לMPL) אבל אני בהחלט לא הייתי אומר שהוא מאפשר לבנות על הקוד שלו סטארטאפ.

  6. יהונתן,

    מניסיוני הרבה מאוד חברות מוכרות מוצרים שבנויים מעל LGPL, למשל אחד הכלים הנפוצים ביות בפיתוח תוכנה (כולל מסחרית) הוא קוד פתוח שנקרא Hibernate שמאפשר שימוש ב-GPL או LGPL. הוא נפוץ היום בהרבה החברות שמוכרות תוכנות לחברות אחרות ואפליקציות ווב. אם אכן לא היה אפשר לבנות מעליו סטארטאפ או תוכנה מסחרית לא היו משתמשים בו (ואני כאן ממתכוונת שמשתמשים בקוד הפתוח כמו שהוא ולא משנים אותו). מדוע אתה אומר שאי אפשר לבנות מעליו סטאטראפ?

  7. האם אפשר להבין מה מותר לי לעשות עם ספריית קוד המשוחררת תחת רישיון LGPL?
    1. שינוי הקוד ושימוש (לא הפצה, אלא שירות אונליין).
    2. הוספת ספריות קוד בצד או כנגזרת ללא שינוי לספרייה המקורית.

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

    יהודה,
    מותר לך לשנות קוד גם של GPL וגם של LGPL, כל עוד אתה לא מפיץ אותן הלאה.

    לגבי הוספת ספריות בצד שמופצות עם הספריה המקורית, LGPL הוא יחסית יותר ברור מהGPL. רשיון הLGPL אומר ש:

    The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

    * a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
    * b) Accompany the object code with a copy of the GNU GPL and this license document.

    הוא גם אומר שמותר לשלב את היצירה בתוך יצירה גדולה יותר (וזה גם בGPL) ואז השאלה לאיזה מהסעיפים השינויים שלך נכנסים תלויה באיך הקוד ממתמשק עם הקוד ששוחרר בLGPL.

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

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

  11. מה לגבי waze ?
    לא הצלחתי להבין מהרישיון שלהם אם הם קוד פתוח או לא

  12. וויט סורס (White Source) היא חברה ישראלית חדשה שפיתחה שירות לזיהוי OSS והרשיון שלו, מעקב אחרי מלאי ה-OSS, דוחות, התראות, תהליכי אישור, וכיו"ב. הכל ב-SAAS והשירות בחינם (יותר מאוחר יהיו שרותי פרימיום בתשלום אבל הבסיס ישאר חינם). תוך 10 דקות תקבלו מיפוי של הפרויקט שלכם. נסו ותגידו לנו מה אתם חושבים…

    תודה

    רון רימון
    http://www.whitesourcesoftware.com

  13. יהונתן תודה על ההשקעה.
    הוסיף לי הרבה.

Comments are closed.