קטגוריות
מערכות מידע דעה כללי

שינוי רישיון Redis

במהלך חודש מרץ 2024, עברה חברת Redis מרישיון קוד פתוח BSD לרישיון כפול עם השמות הקליטים Redis Source Available License 2.0 (RSALv2) Agreement, ו-Server Side Public License (SSPL). השינוי, לדברי החברה, הוא כתוצאה מניצול לרעה של הקוד הפתוח על ידי ספקי הענן, הנותנים את המוצר כשרות ללקוחותיהם, ללא תמורה ל-Redis עצמם, וללא השתתפות בפיתוח המוצר. העולם כמרקחה, לפחות בעיתונות הפופולרית, תוך דגש על הכעס של המפתחות וקהילות הקוד הפתוח. הכעס נובע בעיקר מהתחייבותה של Redis בעבר לרישיון BSD.

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

זאת לא הפעם הראשונה שאירוע של שינוי רישיון, או אפילו חשש משינוי רישיון, מעורר ענין . רכישת Sun עם ידי Oracle גרמה למפתח המקורי של MySQL לפתוח את MariaDB (מזל שהיו לו שתי בנות, מאי ומריה). הגבלת הרישיון של OpenOffice (על ידי IBM) העבירה משתמשות ל-LibreOffice. IBM מאז העבירה את ניהול הרישוי לקרן אפאצ׳י. שינויי הרישוי של RedHat, ובעיקר חיסול CentOS כחלופה חינמית היה מהלך שהביא לחזית את AlmaLinux ו-Rocky Linux

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

כבר עכשיו עומדת לצאת תוכנה חלופית ל-Redis, בשם Valkey, המבוססת על הגרסה האחרונה של Redis, שעדיין תחת רישיון BSD. אמזון, אורקל וגוגל, התחייבו לממן את פרויקט valkey, אותו התחילה מדלין אולסון, עובדת אמזון שבעבר עבדה על Redis. עובדה מעניינת, בהינתן שאמזון הייתה אחת מאלו שבגללן שינתה Redis את תנאי הרישיון. לא אהיה מופתע אם יופיע שרות חדש באמזון של מסד נתונים  NoSQLבשיטת המפתחות, שמאוד דומה ל-Redis, כפי שאמזון מציעה שרתי תואמי MySQL ו-PostgreSQL עם שרותי Aurora, או שרות MongoDB תחת השם DocumentDB. עם זאת, הפרויקט יאוכסן וינוהל תחת קרן לינוקס, כך שלא יהיה גוף מסחרי עם שליטה על הקנין הרוחני.

הם ישנם לקחים אותם ניתן ללמוד מהמקרה?

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

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

קטגוריות
מערכות מידע משולחן היועץ

השוואת חבילות שרותי דואר בענן

בהמשך לסקירה על המעבר מ-Google Workspace, השוואת המחירים נכונה לאפריל 2022

תכניתעלותנפח
דואר
נפח
קבצים
תכנות
משרד
1Domain אחד בלבדFastMail Basic$32איןלא
FastMail Standard$530איןלא
Zoho Standard$33010ענן
Zoho Professional$6100100ענן
Zoho Mail Light$15איןלא
Zoho Mail Premium$450?לא
Microsoft 365 Business Basic$5501024ענן
Microsoft 365 Business Standard$12.5501024שולחני
וענן
Microsoft Exchange Online (Plan 1)$450איןלא
Google Workspace Starter$6302שטח האיכסון כולל דואר, תמונות וקבציםענן
Google Workspace Standard$1220482שטח האיכסון כולל דואר, תמונות וקבציםענן
1Domain אחד בלבדFastMailMailCow Classic4.9 €20איןלא
3אין הגבלת משתמשיםMailCow Managed39.9 €100איןלא

קטגוריות
מערכות מידע משולחן היועץ אינטרנט

עוזב את Google Workspace

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

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

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

הכלכליות של פתרונות אלו תלויה בכמות המשתמשים שיש (לי יש ארבע), כמות המתחמים (Domains), הזמן שלכן ועלויות התפעול (שרתי הענן או ה-UPS בבית למשל).

כאמור, ההצעה של מיקרוסופט (לאחר ההנחה) יצאה משתלמת יותר מהפתרונות של FastMail, Zoho, Google או המערכת המנוהלת של MailCow. לטווח ארוך, כמובן, יהיה צורך לבחון את הפתרונות מחדש.

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

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

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

העברת הדואר לא תכלול חוקים (אם הגדרתם כאלו), ויהיה צורך ליצר אותם מחדש.

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

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

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

ישנם דברים אותם לא ניתן להגר:

  1. קבוצות וכתובות דואר חלופיות (Aliases) צריך לייצר מחדש.
  2. התקשרויות ב-Chat לסוגיו. אפשר לייצא את תוכן השיחות כקובצי טקסט, אבל צרופות והדגשות יאבדו.
  3. שימוש בשרות להיכנס לשרות אחר (Login with Google). כדי להיכנס להגדרות החשבון ולראות אלו אתרי צד ג׳ מתבססים על השרות, ולעבור לזיהוי עם סיסמה.
  4. רכישות שנעשו דרך השרות. יתכן כי ניתן להעביר אותם לחשבונות פרטיים.
  5. אלבומי תמונות.

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

חלופות

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

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

קטגוריות
מערכות מידע

תאמין לו, לנו זה יעלה יותר

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

מאין, אם כן, המספרים?

  • מה העלות של ניתוח המערכת. כלל האצבע שלי הוא של שהעלות האופטימית היא של 10% מההערכה הפסימית ביותר לעלות הפרויקט. אם נניח כי ה"מערכת הראשונית" תעלה 1.7 מיליון ש"ח, ואם נניח כי אותה מערכת תשמש במקום ניתוח המערכת, הרי שהפרויקט הוא בעלות של 17 מיליון ש"ח להקמה.
  • הנושא הבא הוא תחזוקה. כאן כלל האצבע הוא של 15-20% לשנה, דהיינו, 2.5 עד 3.5 מיליון ש"ח לשנה.
  • הוסף את עלויות ההדפסה, ותגיע למספרים דומים של המרכז למחקר ומידע.

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

הבא נבחן מספר חלופי:

  • בבריטניה כ-65 מליון תושבים, ועלות פרויקט תעודת הזהות החכמה הוא ב-5.5 מליארד ליש"ט.
  • אם נניח את אותם משתנים לגבי ישראל, שלה כ-7 מליון תושבים, נגיע ל-3.5 מליארד ש"ח, וזאת בהנחה כי הבריטים יותר טובים מאיתנו בניהול פרויקטי מיחשוב גדולים, והתחשיב שלהם מתאים יותר למציאות.
  • נוסיף להנחה שלעיל את העובדה כי בישראל כבר קיים מנגנון של תעודות זהות ורישום, ואת העובדה כי לאזרחי המדינה יש כבר תעודות קיימות, כך שאין צורך בישום מהיר, נהיה אופטימיים עד מאוד, ונוריד את עלות הפרויקט ב-60%.

יותר ממיליארד ש"ח.

מופרך? חיזרו למאמר של יונתן קלינגר בו הוא מביא את דוגמאות לפרויקטים ממשלתיים אחרים.

ולסיום, השר שטרית הבטיח רמת הגנה של 11? לא ידעתי שהוא חסיד של ספינל טפ.

קטגוריות
מערכות מידע משולחן היועץ

אבטחת מידע לבני אדם

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