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) ההחלטה האם לשחרר את הקוד היא יותר מכל החלטה עסקית.