با اینکه جهان فناوری همواره از قدرت بالایی برخوردار بوده، اما اغلب توان مهار این قدرت زیاد را نداشته است. حقیقت این است که نرم‌افزارها نوشته می‌شوند؛ اما چه کسی اهمیت می‌دهد که کجا و چگونه مورد استفاده قرار می‌گیرند؟ با اینکه درس‌های مربوط به اخلاق حرفه‌ای در برنامه‌های درسی برخی از رشته‌هایی مهندسی گنجانده شده، اما هنوز هم در زمینه رشته‌های علوم کامپیوتر جای خالی چنین بحثی احساس می‌شود. با این‌وجود و با توجه به اینکه نرم‌افزارها هر روز نقش بیشتری در زندگی ما بازی می‌کنند، برنامه‌نویسان باید مسئولیت بیشتری بر دوش خود احساس نمایند. امروزه که کدهای برنامه‌نویسان در هر جا از جمله یخچال‌ها، ترموستات‌ها وجود دارند، هرگونه حرکت اشتباه، نبود بینش یا عدم تصمیم‌گیری صحیح و به‌جا می‌تواند در جایی که کد هست، انسانیت را هم به‌خطر بیندازد.
آنچه که در پی می‌آید، چالش‌هایی اخلاقی هستند که امروزه توسعه‌دهندگان با آنها روبه‌رو می‌باشند؛ خواه خودشان بدانند یا ندانند. از آنجا که طبیعت کار برنامه‌نویسی بسیار مجرد و انتزاعی است، شاید هیچ پاسخ ساده‌ای به این چالش‌ها وجود نداشته باشد. از این بدتر، از آنجا که کسب‌وکار امروزی با فناوری کامپیوتری گره خورده، به دشواری می‌توان میان نیازها و انگیزه‌های لازم تمام طرف‌های درگیر، تعادل برقرار نمود و بنابراین (همان‌گونه که جورج اُروِل هم در کتاب خودش به‌تصویر کشیده)، با یک کابوس روبه‌رو نشد.
شاید بهتر باشد فراتر از زرق‌وبرق‌های امروزی فکر کنیم و مصرف آینده آنچه را که امروز بنا می‌کنیم، درنظر داشته باشیم. کار ساده‌ای است، این‌طور نیست؟ می‌توانید این مقاله را به‌عنوان نقطه آغازی برای تصمیم‌گیری‌های خود در مورد چالش‌های اخلاق حرفه‌ای در علوم کامپیوتر مدنظر داشته باشید و از آن استفاده کنید.
چالش شماره ۱: فایل‌های ثبت (log)؛ چه چیزی باید ثبت و ذخیره شود و چگونه باید از آنها استفاده کرد؟
برنامه‌نویسان شبیه به برخی از موش‌ها هستند؛ آنها از هر چیزی یک رکورد و سابقه نگهداری می‌کنند و علت آن هم اغلب این است که در موقع لزوم، این کار را تنها راه اشکال‌زادایی (debugging) از یک سیستم می‌دانند. اما فایل‌های log همچنین می‌توانند هر کاری را که یک کاربر انجام داده، ردیابی نمایند و اگر در دست افراد نامناسب قرار بگیرند می‌توانند رازهای کاربران را برملا کنند.
بسیاری از کسب‌وکارها هستند که به‌طور فعال و کنش‌گرانه از فایل‌های log محافظت می‌نمایند. حتی برخی از سرویس‌های تهیه فایل پشتیبان از راه دور نیز وعده می‌دهند که کپی‌های اضافی از این اطلاعات را در مکان‌های جغرافیایی مختلفی قرار می‌دهند. برای مثال، شرکت Snapshot برای تهیه فایل‌های پشتیبان از داده‌ها تأسیس شد و کاربرانی که از فراموشکاری سیستم‌های خود در به‌یاد نیاوردن اطلاعات به ستوه آمده بودند، از ایده و کار این شرکت استقبال کردند.
صرف وجود و حضور فایل‌های log، پرسش‌های اخلاقی زیادی به‌پیش می‌کشد؛ از جمله اینکه آیا آنها به‌اندازه کافی محافظت می‌شوند؟ چه کسی به آنها دسترسی دارد؟ وقتی می‌گوییم این فایل‌ها را نابود می‌کنیم، آیا واقعاً آنها را نابود می‌کنیم؟ مسئله اصلی این است که چه اطلاعاتی ارزش نگهداری را دارند.
در اینجا، مسئله «آینده» معادله را پیچیده‌تر می‌کند. در دهه ۶۰ میلادی، کشیدن سیگار در ایالات متحده مورد استقبال قرار می‌گرفت؛ اما هیچ‌کسی به فکر نگهداری سابقه و ردیابی عادات سیگار کشیدن مردم نبود. اما امروزه اطلاع از سیگار کشیدن افراد می‌تواند برای افزایش نرخ بیمه سلامت، یا حتی عدم پوشش بیمه آنها مورد استفاده قرار بگیرد. نمی‌توان به‌درستی پیش‌بینی کرد که این فایل‌های log بی‌گناه، چه موارد استفاده‌ای در آینده پیدا خواهند کرد؛ اما درنظر گرفتن اخلاق در نحوه به‌کارگیری آنها، از اهمیت زیادی برخوردار است.
چالش شماره ۲: چگونه می‌توان کاربران را به محصولات تبدیل کرد؟
در زمانی که شرکت‌های تازه‌کار فناوری یکی پس از دیگری تأسیس می‌شدند، این ضرب‌المثل به‌وجود آمده بود: «اگر برای یک سرویس پولی پرداخت نمی‌کنید، شما مشتری نیستید؛ بلکه محصول هستید». سرویس‌های «رایگان» به‌وفور در اینترنت یافت می‌شوند. در حقیقت آنقدر زرق‌وبرق و شگفتی‌های خدمات اینترنتی رایگان ما را مجذوب خود می‌کنند که یادمان می‌رود از خود بپرسیم پس این سرویس‌های رایگان از کجا پول به‌دست می‌آورند.
اما توسعه‌دهندگان این دغدغه را دارند که چه کسی از کار آنها پشتیبانی می‌کند و اینکه از کجا باید پول دربیاورند. هرگونه تغییری باید به شکلی روشن و در فواصل زمانی معین به کاربران اعلام شود تا آنها شوکه نشوند. تبدیل مردم به محصولات، گذر و تحولی اخلاقی است که به‌هیچ‌وجه نباید آن را دست‌کم گرفت. معاملات ناصادقانه در مورد آگهی‌ها، ارتباط ناصادقانه با شبکه‌های آگهی و غیره، همگی مواردی هستند که موجب به‌خطر افتادن اعتماد نخستین نسل از کاربران سیستم‌ها می‌شوند.
چالش شماره ۳: محتوا تا چه حد باید رایگان باشد؟
تعدادی از کسب‌وکارها هستند که بدون دریافت پول، محتوا تولید می‌کنند. برخی از آنها آگهی می‌فروشند، یا حتی برخی از آنها برای دسترسی به محتوا، پول دریافت می‌کنند. این کسب‌وکارها اغلب نمی‌توانند به بقای خود ادامه دهند و نمی‌توانند روی سرویس خود قیمت‌گذاری کنند.
توسعه‌دهندگان باید از خودشان بپرسند که کد آنها چگونه از همه پشتیبانی می‌کند؛ از سازنده آن گرفته تا مصرف‌کننده. آیا کسانی که محتوا تولید می‌کنند، دوست دارند که کارشان به‌این طریق توزیع شود؟ آیا تنها اینکه کارشان در دسترس دیگران قرار بگیرد و مورد توجه باشند، برایشان کافی است؟ آیا درآمدی منصفانه دارند؟
درنظر نگرفتن این پرسش‌ها منجر به دزدی محتوا می‌گردد و باعث می‌شود مردم چشم خود را در برابر دزدی بسته نگه دارند. از این گذشته، قرار نیست اطلاعات و دسترسی به آن، تماماً رایگان باشد.
چالش شماره ۴: چه میزان از محافظت لازم است؟
برخی می‌گویند باید هرچیزی با دو الگوریتم مختلف، دو بار رمزگذاری شود و سپس روی یک هارددیسک ذخیره گردد و آن هم در یک گاوصندوق قرار داده شود. اما این کار باعث کاهش سرعت کار می‌شود و فرایند توسعه را ده‌برابر دشوارتر می‌نماید. بدتر از این، اگر یک بیت یا بخشی از الگوریتم اشتباه باشد، تمام اطلاعات از دست می‌رود؛ چرا که رمزنگاری قابل بازگشت (undo) نیست.
از سوی دیگر، محافظت از داده‌ها برای دیگران اهمیتی ندارد. در واقع، گروه توسعه‌دهنده بعدی در صورت لزوم می‌تواند کار رمزنگاری را انجام دهد. این ممکن است حرف توسعه‌دهندگان باشد، یا حتی ممکن است بگویند که لازم نیست در این مورد حساسیت زیاد به‌خرج داد.
گروه‌هایی که از این مسئولیت‌ها غفلت می‌کنند، معمولا قادر هستند کدهای دیگری تولید کنند و ویژگی‌های جالبی ایجاد نمایند که برای مردم جذابیت دارند و مردم از آنها استقبال می‌کنند. اما واقعاً چه کسی اهمیت می‌دهد که این کدها ایمن هستند یا نه؟ برای میزان محافظت، هیچ پاسخ ساده‌ای وجود ندارد. تنها برخی حدس‌ها در این زمینه وجود دارد. البته امنیت بیشتر، همیشه بهتر است.
چالش شماره ۵: اشکال‌زدایی بکنیم یا نکنیم؟
بحث راجع به چالش‌های اخلاقی در هنگام گرفتن تصمیم‌های فعال، به‌اندازه کافی دشوار است و وقتی که در کناری گذاشته می‌شوند و برچسب «دارای اشکال» می‌خورند تا اینکه نهایتاً اشکال‌زدایی شوند، مسئله حتی دشوارتر هم می‌گردد. برای حل مسائلی که در کد به‌وجود می‌آیند، چقدر باید کار کنیم تا آنها را حل کنیم؟ آیا باید تمام کد را کنار بگذاریم؟ چگونه متوجه می‌شویم که آیا یک اشکال، به‌اندازه کافی جدی هست که آن را رفع نماییم یا نه؟
سال‌ها پیش آیزاک آسیموف هنگامی که قوانین روباتیک را می‌نوشت، با چنین مسئله‌ای روبه‌رو بود. یکی از قوانین او، از این قرار بود که روبات نباید کاری انجام دهد که موجب آسیب رساندن به انسان‌ها شود. البته روبات‌های آسیموف دارای مغزهایی بودند که می‌توانستند به‌طور آنی مسئله را حل کنند. اما این پرسش‌ها در مورد توسعه‌دهندگان آنقدر پیچیده هستند که از بسیاری از اشکال‌ها غفلت می‌شود و حل‌نشده باقی می‌مانند؛ چون هیچ کسی دوست ندارد حتی در مورد آنها کمی فکر کند.
آیا یک سازمان می‌تواند لیستی از اشکال‌های اولویت‌دار تهیه کند؟ آیا واقعاً برخی از مشتریان مهم‌تر از باقی مشتریان هستند؟ آیا یک برنامه‌نویس می‌تواند برخی از اشکال‌ها را به دیگر اشکال‌ها ترجیح دهد؟ حقیقت این است که به‌دشواری می‌توان تصور کرد که یک اشکال، تا چه میزان می‌تواند مخرب باشد.
چالش اخلاقی شماره ۶: برای جلوگیری از سوءاستفاده، تا چه حد باید کدنویسی کرد؟
دوربین وب که اپل در ابتدا روانه بازار کرد، دارای یک جزء مکانیکی اضافی بود؛ یک شاتر که در هنگام تمام شدن کار دوربین، لنز آن را می‌بست. شاتر و سوییچِ مربوط به آن، با هم لینک بودند و بدون باز کردن شاتر نمی‌شد از دوربین استفاده کرد. برخی از وب‌کم‌های امروزی دارای یک LED هستند که در هنگام کار دوربین مورد استفاده قرار می‌گیرند. ایده جالبی است؛ اما کسی که کار برنامه‌نویسی کامپیوتری انجام داده باشد، می‌داند که ممکن است در جایی از کد، اتصال میان دوربین و LED از بین برود. اگر این جا پیدا شود، دوربین می‌تواند به‌عنوان یک ابزار جاسوسی مورد استفاده قرار بگیرد.
چالشی که یک مهندس با آن روبه‌روست، پیش‌بینی موارد سوءاستفاده از کد و تلاش برای جلوگیری از آن است. شاتر اپل، یکی از مثال‌های بارز و کارآمد است که نشان می‌دهد این طراحی تا چه حد می‌تواند بهینه و ظریف باشد. پیش‌تر، هکری را دیده بودم که تلاش می‌کرد یک نرم‌افزار شبکه به ماشین‌حساب خودش اضافه کند. پس از کمی فکر، تصمیم گرفت سیستم وی تنها از پروتکل‌های سیمی (wired) پشتیبانی کند؛ چون از آن نگران بود که ممکن است نوجوانان، یک ماشین‌حساب با قابلیت وای‌فای را با خود سر جلسه امتحان ببرند. او با پشتیبانی از پروتکل سیمی، اطمینان حاصل کرد که اگر کسی بخواهد از این ماشین‌حساب استفاده کند، باید به وسیله یا دستگاه کناری خود سیم وصل کند که البته ریسک سوءاستفاده از آن بسیار بالا است.
چالش شماره ۷: تا چه حد می‌توان از مشتریان دربرابر درخواست جمع‌آوری اطلاعات، دفاع کرد؟
اگر سازمان شما اطلاعاتی راجع به مردم جمع‌آوری می‌کند، می‌توانید مطمئن باشید که روزی فرا خواهد رسید که میان خدمت‌رسانی به مردم و در اختیار گذاشتن اطلاعات آنها به دولت، یکی را باید انتخاب کنید. این روزها، درخواست نهادهای حقوقی و دولتی برای در اختیار داشتن اطلاعات، به امری معمول تبدیل شده و موجب گردیده تا سازمان‌های نرم‌افزاری و خدماتی به این مسئله فکر کنند که تا چه حد باید اطلاعات مربوط به حریم خصوصی کاربران خود را در برابر قانون لو بدهند.
می‌توان این درخواست‌ها را وارسی کرد یا حتی از یک وکیل کمک گرفت تا ببینید اینها تا چه حد از مشروعیت قانونی برخوردار هستند. اما مسئله این است که زور دادگاه‌ها بیشتر از افراد است و آنها کار خود را به‌پیش می‌برند. در این زمینه هیچ راهکار ساده‌ای وجود ندارد. برخی از شرکت‌ها ترجیح می‌دهند دست از کسب‌وکار بکشند و به مشتریان خود دروغ نگویند. اما برخی دیگر بیشتر مایل هستند با آغوش باز از چنین درخواست‌هایی استقبال کنند.
چالش شماره 8: با سرشت بین‌المللی و فرامرزی اینترنت چه باید کرد؟
اینترنت از مرزهای جغرافیایی عبور می‌کند و در همه‌جا حضور دارد. این مسئله می‌تواند برای مشتریان (الف) و (ب) که در کشورهای مختلفی زندگی می‌کنند، یک چالش حقوقی باشد. اما مسئله به همین‌جا ختم نمی‌شود؛ چون ممکن است سرورهای (پ) و (ت) هم در کشورهای مختلفی باشند. این امر به مسائل اخلاقی آشکار منجر می‌شود.
برای نمونه، اروپا در مورد نگهداری از اطلاعات شخصی و خصوصی افراد، قوانین سفت‌وسختی دارد و عبور از حریم خصوصی را برنمی‌تابد. برخی دیگر از کشورها از شرکت‌ها می‌خواهند سوابق و اطلاعات کاربران را در اختیار آنها قرار دهند. حال این پرسش پیش می‌آید که وقتی مشتریان در کشورهای مختلفی قرار دارند، یک شرکت مفروض باید از قوانین کدام کشور پیروی کند؟ وقتی که داده‌ها در کشورهای مختلفی وجود دارند، چطور؟ وقتی که داده‌ها از مرزهای بین‌المللی عبور می‌کنند، مسئولیت حفظ آنها با چه کسی است؟
چالش شماره 9: به اوپن‌سورس چقدر باید اهمیت داد؟
همه می‌دانند که فناوری اوپن‌سورس رایگان است؛ یعنی لازم نیست برای آن هیچ پولی پرداخت شود و همین مسئله است که آن را جالب و در عین‌حال پیچیده می‌سازد. ولی افراد کمی هستند که موارد اخلاقی کد مجانی و رایگان را مدنظر قرار می‌دهند. همه بسته‌های اوپن‌سورس، دارای مجوزهایی هستند که باید آنها را اجرا کرد.
برخی از این مجوزها، چیز زیادی از کاربران نمی‌خواهند. مجوزهایی همچون Apache یا MIT از این دسته هستند. اما سایر مجوزها همچون مجوز عمومی GNU از شما می‌خواهند تا تمام بهبودها و توسعه‌های خود را با دیگران نیز به‌اشتراک بگذارید. تخطی از مجوزهای اوپن‌سورس، می‌تواند چالش‌هایی اخلاقی ایجاد کند.
زمانی یکی از این مدیران یکی از شرکت‌های بزرگ به من گفت: «ما MySQL را توزیع نمی‌کنیم و بنابراین به هیچ‌کسی هم بدهکار نیستیم.» او دست روی مسئله مهمی می‌گذاشت که دهه‌ها پیش نوشته شده بود؛ یعنی تعهد توزیع مجدد نرم‌افزار. این شرکت برای برنامه‌های کاربردی وب خود، از MySQL استفاده می‌کرد و تصور می‌کرد که نباید آن را دوباره توزیع کند.
هیچ راه ساده‌ای برای سنجش تعهدات اخلاقی وجود ندارد و بسیاری از برنامه‌نویسان شاید وقت خود را تلف کرده‌اند و صفحه‌ها در مورد شرایط و موارد استفاده از نرم‌افزار، قلم‌فرسایی یا به‌عبارت بهتر «صفحه‌کلیدفرسایی» کرده‌اند. با این وجود، اگر مردم از توزیع مجدد نسخه‌هایی که خودشان آنها را بهبود و ارتقاء می‌دهند، پرهیز کنند، تمام تلاش اوپن‌سورس به بن‌بست خواهد انجامید. جالب آن‌که در اغلب موارد، این‌گونه مشارکت‌ها به نفع همه است؛ زیرا همه دوست دارند نرم‌افزار اصلی، با موارد استفاده آنها سازگاری داشته باشد.
چالش شماره 10: چه میزان از سرکشی و نظارت لازم است؟
شاید رئیس شرکت شما مایل باشد اطمینان حاصل کند که همه کارمندان کارشان را به‌درستی انجام می‌دهند. ممکن است شما هم بخواهید اطمینان حاصل کنید که برای کاری که انجام می‌دهید، پول دریافت می‌کنید. شاید این ایده برای شما مطرح شود که برای گرفتار کردن افراد خلافکار، بهتر است از یک تله (در پشتی) استفاده کنید. اما در هر صورت، باید اطمینان حاصل نمایید که این در پشتی (همچون قدرت سوپرمن) تنها برای حقیقت و عدالت مورد استفاده قرار می‌گیرد. اما اگر خلافکاران متوجه وجود همچین در پنهانی شوند و خودشان از آن سوءاستفاده کنند، چطور؟ اگر در پنهانی شما، برای دروغ و بی‌عدالتی مورد سوءاستفاده قرار بگیرد، چطور؟ کد شما نمی‌تواند در مورد مسائل اخلاقی تصمیم‌گیری کند؛ این کار شماست که تصمیم‌گیری کنید.
چالش شماره 11: یک کد تا چه حد باید ایمن از آسیب باشد؟
مطمئناً در زمانی که مسائل کوچک هستند، محاسبات مینیمال، ساختمان داده‌ها ساده، و رویکرد غیرمستقیم و brute force بهترین جواب را می‌دهند. کاربران کد خود را امتحان می‌کنند و می‌گویند: «خدای من، چقدر سریع عمل می‌کند!» اما چند ماه بعد، وقتی که به‌اندازه کافی داده وارد سیستم شده، نقاط ضعف الگوریتم مشخص می‌شوند و کد نهایتاً زمین‌گیر می‌شود. توسعه‌دهندگان اغلب باید تصمیم بگیرند که تا چه حد باید مجدّانه روی محصول نهایی کار کنند.
آیا بهتر است از راه‌حلی ساده و «دم‌دستی» استفاده کنند، یا اینکه هفته‌ها وقت صرف تقویت کد خود بکنند؟ درست است که مشتریان و کاربران باید جوانب احتیاط را رعایت کنند و از برنامه‌ها sign-off کنند؛ اما توسعه‌دهندگان نیز باید مراقب چنین مواردی باشند و آنها را از قبل پیش‌بینی نمایند.
چالش شماره 12: پیامدهای آتی، تا چه حد روی تصمیمات کنونی تأثیرگذار است؟
بسیاری از پروژه‌ها، پیامدهای آتی چندانی ندارند؛ اطلاعات وارد آنها می‌شود و هرگز خارج نمی‌گردد؛ اما برخی از این اطلاعات ممکن است خارج شود و کاری بکند که نباید بکند. امنیت، نفوذ، جاسوسی؛ اینها همه مواردی هستند که کد شما می‌توانند سیستم را بدین‌ترتیب به مخاطره بیندازد.
برای بیشتر توسعه‌دهندگان، آسیب‌های جانبی چندان آشکار و مشهود نیستند. ما برای امروز کد می‌نویسیم؛ اما باید عواقب آن را هم درنظر بگیریم. برای مثال، برخی از برنامه‌نویسان عاشق نوشتن کدهای پیچیده‌ای هستند که با سیستم‌عامل یکپارچه می‌شوند و درایوهای جدید یا پیچیده‌تری نصب می‌کنند. آیا این کار در آینده هم جواب خواهد داد؟ آیا با درایوهای جدید هم به‌خوبی کار خواهد کرد؟ آیا با نسل‌های آتی سیستم‌های عامل هم سازگاری خواهد داشت، یا اینکه نرم‌افزار شما نهایتاً موجب خواهد شد که مردم کامپیوتری آهسته‌تر داشته باشند که مرتباً از کار باز می‌ایستد؛ حتی در زمانی که نرم‌افزارهای شما را هم اجرا نمی‌کنند؟!
شاید ساده به‌نظر برسد، اما تصمیم بر سر اینکه از APIها استفاده کنیم یا از استانداردها پیروی کنیم، یک تصمیم اخلاقی است. بله، فناوری خیلی سریع به‌پیش می‌رود و تکامل می‌یابد و دلدادگی به مواردی از قبیل آنچه که در بالا به آن اشاره شد، می‌تواند مانعی بر سر راه پیشرفت ایجاد کند. اما بهتر است به نقش خودمان در نوشتن و منتشر ساختن کد نیز فکر کنیم و درنظر داشته باشیم که در این فرایند، نقشی طولانی‌مدت داریم و بهتر است بدانیم که همواره در صورت لزوم می‌توانیم در APIها یا استانداردها، تغییرات ایجاد کنیم.
منبع: ماهنامه دنیای کامپیوتر و ارتباطات
دریافت لینک صفحه با کد QR
