هفتهٔ پیش (اواخر آبان ۱۳۹۷) معلوم شد که یک کتاب‌خانهٔ نرم‌افزاری بسیار پرکاربرد یک کد مخرب در خود دارد که می‌تواند پول‌های دیجیتال کاربرانش را بدزدد. این خبر به تنهایی به هیچ وجه خاص نیست. دنیای فناوری پر است از محصولاتی که در ظاهر برای کمک به کاربران ساخته شده اند، ولی در عمل کاربران را محدود می‌کنند، اطلاعات خصوصی‌شان را می‌دزدند، و گاهی انسانی‌ترین آسیب‌پذیری‌های کاربر را بر ضد خود او به کار می‌برند.
چیزی که این خبر را جالب می‌کند این است که این کد مخرب درون یک نرم‌افزار آزاد جاگذاری شده بود. نرم‌افزاری که نه تنها (بر اساس مجوز انتشارش) اجازهٔ خواندن کدهایش را به کاربران می‌داد، بلکه کل فرایند توسعه‌اش در یک وبسایت عمومی (گیت‌هاب) انجام می‌شد و بنابراین همهٔ کاربرانش (یعنی همهٔ برنامه‌نویسان دیگری که این کتاب‌خانه را به کار می‌بردند) می‌توانستند متوجه وجود این کدهای مخرب بشوند.
ولی چگونه این کدهای مخرب افزوده شدند؟ چرا ماه‌ها طول کشید تا کسی متوجه شود؟ چرا چنین کتاب‌خانهٔ نرم‌افزاری خطرناکی از آغاز بین برنامه‌نویسان چنین محبوب شد؟ آیا این نشان می‌دهد که نرم‌افزارهای آزاد قابل اعتماد نیستند؟
داستان این است که این کد مخرب را نه نویسندهٔ اصلی این نرم‌افزار، بلکه شخص دیگری که به تازگی مسئولیت به‌روزرسانی‌اش را به عهده گرفته بود به این نرم‌افزار افزوده بود. دومینیک تار، برنامه‌نویس ساکن نیوزلند و نویسندهٔ اصلی این نرم‌افزار می‌گوید:
من این کد را به دلایل بشردوستانه ننوشتم. برای این نوشتم که نوشتنش کیف می‌داد. من داشتم یاد می‌گرفتم، و یادگرفتن کیف می‌دهد. من کد را به طور آزاد منتشر کردم، چون این کار آسان بود، و در ضمن به‌اشتراک‌گذاشتن کد به یادگرفتنم کمک می‌کرد. حدس می‌زنم بیشتر ماژول‌های کوچک npm به دلایل مشابهی نوشته شده‌اند. اما همهٔ این‌ها مال خیلی وقت پیش بود. من دیگر روی این کد کار نمی‌کنم، و دیگر روی کد بعدی‌ای هم که نوشتم کار نمی‌کنم، و حتی به زودی از این یکی کد دیگر هم رد خواهم شد…
دومینیک تار، بیانیه دربارهٔ هک‌شدن کتاب‌خانهٔ event-stream
به طور خلاصه، دومینیک دیگر وقتی برای گسترش و رفع اشکال‌های این برنامه نداشت. حتی با وجود این که هزاران نفر دیگر آن را به کار می‌برند و به آن وابسته هستند، هیچ برنامه‌نویس شناخته‌شده‌ای برای نگهداری این کد پیش‌قدم نشد. بنابراین، دومینیک کنترل این کد را به یک «غریبهٔ مهربان» سپرد که قول داده بود به‌روزرسانی و رفع‌اشکال‌هایش را به عهده بگیرد. و این غریبهٔ مهربان، بلافاصله پس از گرفتن این کنترل، کاری را کرد که نباید می‌کرد (+).
دو نکته دربارهٔ این رویداد می‌توانم بگویم.
نرم‌افزار آزاد امنیت را ممکن می‌کند، ولی تضمین نه
یکی از بزرگ‌ترین استدلال‌های طرفداران نرم‌افزار آزاد (مثل من) این است که به‌کاربردن نرم‌افزار آزاد برای کم‌کردن از آسیب‌پذیری‌های امنیتی (سرقت اطلاعات و از کارافتادن سیستم‌ها) مطلقاً ضروری است. ولی این دلیل نمی‌شود که به کاربردن نرم‌افزار آزاد امنیت را تضمین کند. درست شبیه رویدادی که سال ۱۳۹۳ برای کتاب‌خانهٔ OpenSSL افتاد، تا وقتی که کاربران و متخصصان نتوانند یا نخواهند که کدهای نرم‌افزارهای آزاد را بازبینی کنند، تضمینی نخواهد بود که این کدها همیشه کاری را بکنند که همه انتظار دارند. به زبان دیگر، به‌کاربردن نرم‌افزارهای آزاد شرط لازم برای داشتن امنیت است، ولی شرط کافی نیست. برای همین است که در مواقع لزوم دولت‌ها باید برای بازبینی چنین کدهایی پیش‌قدم شوند یا برای توسعهٔ نرم‌افزارهای آزاد در حوزهٔ عمومی بودجه اختصاص دهند.
دیر فهمیدن بهتر از هرگز نفهمیدن است
تصور کنید که اگر این برنامه‌نویس گیت‌هاب به خودش زحمت نمی‌داد تا کدهای این کتاب‌خانه را بررسی کند چه می‌شد؟ ممکن بود تا مدت‌های زیادی (شاید چندین ماه یا چندین سال) هیچ کسی متوجه چنین خراب‌کاری‌ای نشود.
ولی چه می‌شد اگر بررسی این کدها از اساس ممکن نبود؟ در این صورت هیچ وقت کسی متوجه چنین خراب‌کاری‌ای نمی‌شد. این وضعیت دقیقاً برای همهٔ نرم‌افزارهای غیرآزاد (نرم‌افزارهایی که هیچ کسی اجازهٔ ویرایش یا حتی دیدن کدهایشان را ندارد) رخ می‌دهد. ما نمی‌توانیم بفهمیم که یک نرم‌افزار غیرآزاد چه کارهایی با کامپیوترها، ابزارها، و اطلاعات ما می‌کند. و احتمالاً هیچ وقت هم نخواهیم فهمید.
خوشحال نیستم که چنین چیزی در جامعهٔ نرم‌افزارهای آزاد رخ داده. ولی خوشحالم اگر این رویداد شاخک‌های کاربران عادی و برنامه‌نویسان را حساس‌تر کند. مهم است که همهٔ ما بدانیم که نرم‌افزار بخش مهمی از زندگی مدرن همهٔ ماست. همان طور که برای حفظ آزاد بیان باید پیوسته هوشیار و فعال بود، برای آزادی نرم‌افزار هم باید پیوسته تلاش کرد.