حال که همهگیری ویروس کرونا، این توفیق اجباری را فراهم کرده که گردهماییها به صورت برخط برگزار شوند، باید تلاش کنیم که محدودیتهای دنیای واقعی را کورکورانه در جهان برخط نیز به دوش نکشیم و تا جای ممکن، از این محددیتها بکاهیم. در ادامه، روشی برای برگزاری همایشهایی چون روز آزادی نرمافزار پیشنهاد میشود که البته، به دلیل تازه بودن این مفهوم، خامدستانه بوده و در آینده، با تفکر بیشتر و ورود تجربیات تازه، بهروز خواهد شد. همرسانی نظرها، پیشنهادها و نقدها به این موضوع، بی شک موجب رشد و بهبود این طرح و کمک به اجتماعهایی نظیر اجتماع کاربری نرمافزار آزاد خواهد شد.
روند برگزاری همایش به دو بخش پیش از همایش و روز نمایش تقسیم میشود.
آنچه که پیش از همایش لازم است، سکویی برای انتشار آزاد پروندههای ویدیویی است. این سکو میتواند نمونهای از پیرتیوب یا هر فناوری مناسب دیگری باشد. در صورت امکان، حتا میتوان از یک کانال، روی نمونهای از پیرتیوب استفاده کرد و ویدیوها را آنجا بازنشر داد؛ هرچند این کار، از خودکار بودن روند برگزاری پس از مشخّص شدن مکان بارگزاری میکاهد، ولی نیاز به تمرکز در ابتدای کار را از بین میبرد.
با اعلام سکوی مشخّصشده در مدّت زمانی معقول پیش از روز نمایش، از افراد خواسته میشود ارائههای خود را به صورت ویدیویی ضبط کرده و پس از اطمینان از محتوای ارائهشده، آن را روی سکوی مورد نظر بارگذاری کنند.
با آغاز از زمان مشخّصشده برای شروع همایش، هر ویدیوی بارگذاری شده، با یک گام زمانیِ از پیش تعیینشده، مدّت زمانی برای پرسش و پاسخ مربوط به آن ارائه برایش مشخّص میشود. برای مثال، نخستین ویدیوی بارگذاری شده، ساعت ۱۰، دومی ساعت ۱۰:۳۰، سومی ساعت ۱۱ و همینطور تا پایان ارائهها، زمانها به صورت خودکار برایشان تخصیص داده میشود.
مخاطبین میتوانند در فاصلهٔ بین بارگذاری ارائه و روز همایش، ارائهها را مشاهده کرده و در صورت نیاز، نکات مربوط به آن را یادداشت کرده و زمان شروع جلسهٔ پرسش و پاسخ آن را محاسبه کنند.
در روز همایش، در ساعت اعلام شده، اتاق گفتوگو که میتواند نمونهای از بیگبلوباتن باشد، گشوده شده و نخستین ارائهدهنده، آمادهٔ پاسخگویی به پرسشها و نکات مخاطبان است. پس از پایان زمان تخصیصیافته، ارائهدهندهٔ بعدی، اتاق را در دست گرفته و به پرسشهای مخاطبان خود پاسخ میدهد. این روند تا پایان همایش ادامه خواهد یافت.
هنوز معایبی برای این مدل برگزاری پیدا نشده است. خوشحال میشوم با نظرات خود، این نوشته را کاملتر کنید.
این که نام سیستمعاملی که ما در قالب توزیعهایی مانند اوبونتو استفاده میکنیم چیست، در سالهای اخیر، اختلاف نظرهای بسیاری را برانگیخته است. در این جستار تلاش میکنیم تا با بررسی علمی و به دور از هیجانهای رایج در این زمینه، به نتیجهٔ درست برسیم.
در تعریف سیستمعامل، بزرگان فن سخن بسیار راندهاند. با این حال، هیچیک هنوز به تعریف کاملاً دقیقی از آن دست نیافتهاند. با این حال، همانگونه که پیشتر بیان شد، اندرو تننباوم که از بزرگترین افراد متخصّص در این حوزه است، بهترین تلاش خود را برای تعریف سیستمعامل به این صورت بیان میکند:
سیستمعامل عبارت است از یک مجموعهٔ نرمافزاری متشکّل از کرنل و هر آنچه مستقیماً با کرنل کار میکند، مانند کتابخانهها، میانافزارها، کامپایلرها و ابزارهای توسعه. کرنل در این میان بخشی است که مستقیماً با سختافزار صحبت کرده و وظیفهٔ اختصاص منابع را برعهده دارد.
هنگامی که لینوس توروالدز، دانشجوی فنلاندی دانشگاه هلسینکی که در سال ۱۹۹۱، حدود یک دهه پس از شکلگیری و گسترش استفاده از سیستمعامل گنو، شروع به کارش روی لینوکس را در گروه خبری مینیکس اعلام میکند، اعتراف میکند که پروژهاش یک تفریح بوده و قرار نیست چیزی به بزرگی گنو و آنقدر حرفهای باشد. همین بیانیه، جایگاه گنو را پیش از انتشار لینوکس به روشنی نشان میدهد. حتا پس از انتشار لینوکس نیز، لینوس توروالدز در یادداشت انتشار آن در بخش مربوط به حق رونوشت چنین مینویسد:
متأسّفانه یک کرنل به تنهایی راه به جایی نمیبرد، برای داشتن یک سامانهٔ قابل استفاده، نیاز به یک پوسته، کامپایلرها، یک کتابخانه و… دارید. اینها قسمتهایی مجزّا هستند که ممکن است تحت حق رونوشتی محکمتر (یا حتا نرمتر) باشند. اکثر ابزارهای مورد استفاده برای لینوکس، نرمافزارهای گنو هستند و تحت کپیلفت گنو قرار دارند.
در مورد بالا، به جز پوستهٔ بش که البته آن هم جزیی از پروژهٔ گنو است، مقصود از کامپایلرها gcc و مقصود از کتابخانه glib است که هر دو از اجزای سیستمعامل گنو هستند.
خود لینوکس به صورت ذاتی چیزی جز حدود ۳۸۰ فراخوانی سامانه نیست. طبق تعریف تننباوم از سیستمعامل، میتوان نشان داد که این فراخوانیها همچنین تنها توسّط خود سیستمعامل قابل دسترسی بوده و توان پاسخگویی مستقیم به برنامههای کاربردی را ندارد. بنا بر این نرمافزارهای کاربردی، با بخشهای غیر کرنلی سیستمعامل در ارتباط بوده و هرگز جز با پرسش از خود سیستمعامل، متوجّه حضور و نوع کرنل به کار رفته در آن نخواهند شد.
در مقابل کتابخانهٔ glib به عنوان بخش اصلی سیستمعامل گنو در لایهٔ اجرایی، مانند یک پوشش روی کرنل است که بیش از ۲۰۰۰ زیرروال را برای فراخوانده شدن توسّط برنامهها فراهم کرده و در لایهٔ زیرین خود، به ارتباط با کرنل میپردازد. بنا بر این با تغییر دادن این لایهٔ زیرین و تطبیق آن با فراخوانیهای سامانهٔ کرنلهای دیگر میتوان آن را برای هر کرنل دیگری با ساختار پازیکس قابل استفاده کرد.
از این روست که میبینیم بخش عمدهٔ مخازن توزیع بزرگی مانند دبیان، بدون تلاشهای بسیار بزرگ از جانب توسعهدهندگان این توزیع، برای کرنلهای مختلفی چون لینوکس، هرد، مینیکس، kFreeBSD و… پورت شدهاند، زیرا که اکثر برنامههای کاربردی، برای اجرا روی سیستمعامل گنو نوشته شدهاند و نه کرنل لینوکس.
از سوی دیگر میتوان نگاهی به برنامههای سیستمعامل اندروید داشت. همانطور که احتمالاً میدانید، اندروید نیز یکی از سیستمعاملهایی است که از لینوکس به عنوان کرنل استفاده میکند. ولی برنامههای نوشته موجود برای این سیستمعامل، در توزیعهای گنو مانند اوبونتو و… به صورت بومی قابل اجرا نیستند. عمدهٔ برنامههای این سیستمعامل به صورت قرنطینه و روی زیرساختی با نام ART اجرا میشوند که خود، برای کار با کتابخانهای با نام بایونیک که بخش اصلی سیستمعامل اندروید در لایهٔ اجرایی است نوشته شده است. دلیل اجرا نشدن این برنامهها و برنامههای دیگری که به کمک جعبهٔ توسعهٔ بومی (NDK) به صورت مستقیم با بایونیک کار میکنند، به صورت بومی در توزیعهای گنو، این است که مانند مورد مشابه در گنو، همهٔ این برنامهها برای اجرا روی سیستمعامل اندروید نوشته شدهاند و نه کرنل لینوکس.
گفتنی است به تازگی پروژهای با نام هیبریس شروع به توسعه کرده است که تلاش دارد همانگونه که واین لایهٔ سازگاری دودویی برای تبدیل زیرروالهای ویندوز به زیرروالهای پازیکس گنویی را فراهم میکند، یک لایهٔ سازگاری برای تبدیل زیرروالهای بایونیک به glib را ایجاد کند. البته این پروژه هنوز در ابتدای راه است و به دلیل یکسان بودن کرنل گنو و اندروید، تمرکزش روی تبدیل فراخوانیهای صرفاً وابسته به کرنل، مانند راهاندازهای سختافزاری و… است.
اصل کلّی در نامگذاری نرمافزارها این است که به پدیداورندهٔ آن، حق گذاشتن هرنام دلخواهی را روی نرمافزارش دارد. ولی حق دخالت درنامگذاری دیگر محصولاتی که با نرمافزارش در تعامل هستند را ندارد. برای مثال، توسعهدهندگان GNOME در سال ۲۰۱۰ نام میزکارشان را به Gnome تغییر دادند و کاملاً هم اختیار این کار را داشتند، ولی نمیتوانستند و نمیتوانند در نامگذاری Ubuntu که به صورت پیشگزیده از میزکار گنوم بهره میبرد دخالتی داشته باشند.
به همین صورت، لینوس توروالدز این حق طبیعی را دارد که نام خود را روی کرنلی که ایجاد کرده بگذارد، ولی برای مثال حق تغییر نام سیستمعامل اندروید را که به صورت پیشگزیده از لینوکس به عنوان کرنل استفاده میکند ندارد و تنها مرجع قابل قبول برای تعیین نام اندروید، تا زمانی که از بایونیک استفاده میکند، توسعهدهندهٔ اصلی و صاحبامتیاز نشان تجاری آن، یعنی گوگل است. برای درک بهتر این موضوع، خوب است به لینیج اواِس نگاهی بیندازیم که با وجود تمام تفاوتهای پایهایش با اندرویدِ موجود، به دلیل استفاده از بایونیک، خود را یک توزیع اندروید و نه یک سیستمعامل جدید میخواند.
همین امر در مورد سیستمعامل گنو نیز صادق است. توسعهدهندگان اصلی این سیستمعامل، نام گنو (و نه نام خودشان) را بر این سیستمعامل گذاشتهاند و فارق از نرمافزارهای به کار رفته در آن، باید همواره از آن به همین نام یاد شود. با نگاهی به دیگر سیستمعاملهای مطرح دنیا نیز در مییابیم که نوع و نام کرنل به کار رفته در سیستمعامل، نقشی در نامگذاری آن سیستمعامل نداشته و همواره از یک سیستمعامل، با نام خودش یاد شده است. با این حال، گنو تنها سیستمعاملی است که به دلیل پایبندی بیشازحد توسعهدهندگانش به اخلاق حرفهای، این اجازه را دادهاند که در توزیعهایی از این سیستمعامل که با کرنلهای مختلف ارائه میشود، برای اعتبار دادن به پروژههای خارج از گنو، نام آنها نیز در ادامهٔ نام گنو بیاید.
در ادامه تعدادی از شبهات بسیار دیده شده در مورد گنو و لینوکس آورده شده و تلاش شده به آنها پاسخ داده شود. در صورت برخورد با شبهات مشابه، لطفاً آنها را در قسمت دیدگاهها بنویسید تا به متن افزوده شود.
گویندگان این جمله، سیستمعامل گنو را با پروژهٔ گنو اشتباه گرفتهاند. پروژهٔ گنو، پروژهای است که یک سال پس از معرّفی سیستمعامل گنو، به منظور نوشتن نرمافزارهای آزاد کاربردی برای سیستمعامل گنو شروع به کار کرد. حاصل این پروژه، بسیاری از نرمافزارهای آزاد است که امروزه بر روی سیستمعامل گنو استفاده میشود، ولی جزو خود سیستمعامل نیست؛ مانند ویرایشگرهای متن، بازیها و…
گنو یک کامپایلر نیست، بخشی از آن با نام GCC یک مجموعه کامپایلر است. این مجموعه به همراه کتابخانهٔ glibc به عنوان پایهٔ اصلی سیستمعامل گنو نوشته شده و افراد غیرفنّی ممکن است نتوانند تفاوت این دو را به خوبی درک کنند. برای روشنتر شدن موضوع میتوان به جعبهابزار گرافیکی GTK اشاره کرد که به عنوان پایهٔ اصلی نرمافزار گیمپ نوشته شده، ولی گیمپ فقط یک جعبهابزار گرافیکی نیست.
ادّعای درستی است. ولی توجّه داشته باشید که استالمن خواهش نکرده لینوکس را گنو/لینوکس بنامید. پس از گزینش لینوکس به عنوان کرنل آیندهٔ سیستمعامل گنو و همزمان با کار گروه توسعهٔ گنو روی لینوکس برای سازگار کردن آن با سیستمعامل گنو، فهرست پستی گنو با رشتههای متعدّدی پر شد که پس از تلاشهای زیاد برای رفع مشکلات عجیبی که به نظر منطقی نمیرسیدند، مشخّص میشد فرد پرسشگر از لینوکس به جای کرنل مطرح وقت گنو یعنی تریکس استفاده میکرده است. بنا بر این استالمن از کابران گنو خواست در صورت استفاده از لینوکس به عنوان کرنل، در انتهای عنوان درخواست خود، برای مشخّص شدن کرنل مورد استفاده، عبارت «+لینوکس» را درج کنند. این سنّت بعدها منجر به نوشتن نام سیستمعامل به صورت گنو+لینوکس شد و پس از مدّتی به دلیل نیاز + به تایپ شدن با دو انگشت، به صورت گنو/لینوکس خلاصه شد. بنابراین خواهش استالمن گفتن این عبارت به جای گنو بود و نه بهجای لینوکس!
برخی عنوان کردهاند اگر در نام سیستمعامل، گنو و لینوکس را میآوریم، چرا دیگر برنامهها مانند آپاچی و گنوم و ویالسی و… را نیاوریم. پاسخ به این پرسش بسیار ساده است. نخست این که نیازی به درج نام کرنل در سیستمعامل نیست و میتوان به سادگی آن را فقط با نام خودش، یعنی گنو نامید. دوم این که این اجزا، بخشی از سیستمعامل نیستند که نامشان در نام سیستمعامل درج شود، زیرا نه کرنلند و نه مستقیماً با کرنل کار میکنند. حتا در صورتی که مستقیماً با کرنل کار میکردند نیز، بنا بر تعریف تننباوم، خودشان بخشی از سیستمعامل میشدند و آنگاه تا زمانی که از glib استفاده میشد، تمام آن مجموعه نام گنو میگرفت.
با توجّه به تمام تفاسیر ارائه شده، میتوان با قطعیت گفت که نام این سیستمعامل «گنو» است و در صورتی که لازم باشد نوع کرنل به کار رفته در آن مشخّص شود، میتوان آن نام را هم به گنو افزود.
در پایان توصیهٔ من برای آنانی که سیستمعامل گنو را به نامهای دیگری مانند لینوکس میخوانند این است که سیستمعامل خودشان را مستقل از گنو توسعه داده و سپس مانند گوگل با اندروید، سامسونگ با تایزن و… هر نامی که مایلند را روی آن بنهند.
مدیریت حقوق دیجیتالی (Digital Rights Management)، نام عمل تحمیل محدودیتهای فنّیای است که آنچه کاربران میتوانند با رسانهٔ دیجیتال انجام دهند را کنترل میکند. هنگامی که به وسیلهٔ یک نرمافزار، از رونوشت یا همرسانی یک آهنگ، خواندن یک کتاب الکترونیک روی دستگاهی دیگر یا انجام یک بازی تکنفره بدون دسترسی به اینترنت منع میشوید، در واقع بهوسیلهٔ DRM محدود شدهاید، چرا که از انجام کاری که بدون وجود DRM میتوانستید انجام دهید، جلوگیری شده است. این عمل کنترل بر تولید و پخش رسانه را شدّت بخشیده و به تاجران DRM، قدرت کتابسوزانهای بزرگ دیجیتالی و تجّسس وسیع در عادات رسانهای مردم و از آن بدتر، قدرت کنترل بر ماشینها، دستگاههای پزشکی، تلفنها، رایانهها و… را میدهد.
از این رو، هواداران آزادی بیان و حقوق بشر، DRM را نه «مدیریت حقوق دیجیتالی»، که «مدیریت محدودیتهای دیجتالی» (Digital Restrictions Management) میخوانند و میگویند اگر خواهان اجتناب از آیندهای هستیم که در آن، افزارههایمان ابزار پایش و واپایش برهمکنشمان با رسانههای دیجیتال باشند، باید برای از دست ندادن کنترل بر رسانهها و نرمافزارهایمان بجنگیم.
اگه مردم حتا بفهمن DRMای هم وجود داره، چی هست و طرز کارش چیه، دخلمون اومده!
پیتر لی، مدیر کمپانی دیزنی در گفتوگو با اکونومیست (۲۰۰۵)
کارتلهای بزرگ و سرمایهدار، همواره استادان محدودیتهای دیجیتالی بودهاند و هستند. زمانی با دزد دریایی خواندن افرادی که از رسانهها استفادهٔ شخصی میکردند، زمانی با وضع قانونهای متجّرانه به عنوان پیشگری، دورهای با تصویب مجازاتهای غیرعقلانی برای اعمال طبیعی و اکنون با آخرین فنآوریهای روز دنیا. بنابراین عجیب نیست که در میان حامیان و سازندگان این مفهوم، نامهایی چون مایکروسافت، اپل، گوگل، دیزنی، سونی، آمازون و… را ببینیم. با نگاهی به پیشینه و شیوهٔ رفتاری هر یک از این موارد، میتوان هدف آنها را از خلق و استفاده از این فنآوریها دریافت. DRM این اجازه را به ناشر میدهد که بدون دردسر، محدودیتهایی را فراتر از آنچه که حتا قانونهایی که خود، با اعمال قدرت، پرداخت هزینه و گمراهی قانونگزاران به تصویب رساندهاند اعمال کنند؛ چرا که تصوّر میکنند این عمل، سوددهی آنان را بیشتر خواهد کرد.
این شرکتها همچنین به تازگی درتلاشند تا یک استاندارد DRM را وارد وب کنند تا از این طریق بتوانند بر رفتارهای افراد در مرورگرهای وبشان نیز کنترل و نظارت داشته باشند. برای مثال نتفلیکس قصد دارد از این طریق، کنترل کاملی بر چگونگی استفادهٔ اعضایش بر فیلمها و سریالهایی که میبینند داشته باشد. همچنین اسپاتیفای نظارت بر آهنگهایی که افراد به آنها گوش میکنند را در برنامهٔ خود دارد. این اقدامات با مخالفتهایی جدّی در حوزهٔ وب مواجه شده که تا کنون، همچنان بحث و اختلاف نظر بر سر آن داغ است.
میتوان تصوّر کرد که افراد و گروههای مدافع آزادی و حقوق بشر، عمدتاً رویکرد مخالف با این پدیده گرفته اند. ریچارد استالمن در جستار «حقّ خوانش»، DRM را نمونهای از یک ویژگی مخرّب میشمرد که برای آسیب زدن به کاربر طرّاحی شده و از این رو قابل تحمّل نیست. بنیادهای مختلفی چون بنیاد نرمافزار آزاد(FSF) و بنیاد مرزهای دیجیتال(EFF) با راهاندازی پویشهایی مانند defectivebydesign اقدامهایی عملی برای مبارزه با این پدیده راهاندازی کردهاند. همچنین اهمّیت این ماجرا در حدی است که نهادهای بینالمللی را نیز به واکنش واداشته است. برای مثال، سازمان علمی، آموزشی و فرهنگی ملّل متّحد (یونسکو) در نامهای به تیم برنرز لی (خالق وب)، DRM را ایدهای بسیار بد خوانده و از وی خواسته برای جلوگیری از قرار گرفتن چنین فنآوریهایی در وب تلاش کند.
همچنین پروانههای انتشار GPL نگارش ۳ و خانوادهٔ Creative Commons نگارش ۴، در مفاد قانونی خود، بندهایی را قرار دادهاند که در عمل DRM را بیاثر کرده و از آلوده شدن موارد تحت حمایتشان به DRM جلوگیری میکند.
دامنهٔ این اعتراضات تا جایی بالا گرفت که حامیان سرسخت این فنآوریها را نیز وادار به عقبنشینی کرد. برای مثال بیل گیتس در سال ۲۰۰۶ اعلام کرد DRM چیزی که باید باشد، نیست. و باعث بروز مشکلاتی برای مصرفکنندگان قانونی هنگام متمایز کردن کاربران قانونی و غیرقانونی شده است. همچنین استیو جابز در سال ۲۰۰۹ دستور حذف DRM از آهنگهای موجود در فروشگاه آیتونز اپل را داد.
نخستین و تنها راه قطعی مقابله با DRM، دوری از هرگونه محصولی است که به نوعی با DRM در ارتباط باشد. برای رسیدن به این هدف باید قید هرگونه محتوای دارای DRM را حتا در صورت توزیع رایگان آن محتوا زد و از آن استفاده نکرد.
از راههای مفید دیگر برای دوری از DRM میتوان به استفادهٔ صرف از نرمافزارهای کاملاً آزاد و تنظیم آنها برای خودداری از پخش محتوای دارای DRM اشاره کرد، زیرا که به دلیل ماهیت مخرّب این فنآوری، قابلیت پیادهسازی آن به صورت آزاد وجود نداشته و نرمافزارهای آزاد نمیتوانند به صورت توکار از DRM پشتیبانی کنند. روشی که این نرمافزارها در صورت اجبار به نمایش محتوای دارای DRMبه کار میبرند، استفاده از حبابهای دودویی انحصاریای است که از پیش روی دستگاه وجود دارد. سیستمعاملهای آزاد مانند گنو/لینوکس، این حبابها را داخل خود ندارند و کاربر اگر به صورت دستی آنها را به سیستمعامل نیفزاید، لازم نیست نگرانیای از این بابت داشته باشد، ولی سیستمعاملهای انحصاری مانند ویندوز مایکروسافت و اواس اپل، عموماً به همراه این حبابها عرضه میشوند. همچنین برخی دستگاهها که به همراه سیستمعامل انحصاری خود عرضه میشوند، مانند دستگاههای اندرویدی، کتاب خوانهای کیندل و… نیز حاوی این حبابها هستند که اگر هنگام خرید چنین دستگاههایی، دقّت لازم انجام شود، میتوان مدلهایی را برای خرید انتخاب کرد که توانایی هک شدن و برداشتن حبابهای مربوط به DRM را داشته باشند.
همچنین یک راهکار بسیار مناسب برای گسترش موج مقابله با DRM، افزایش اطّلاعات و آگاهیرسانی دربارهٔ ماهیت DRM و مشکلات آن است.
همانطور که میدانید خوشبختانه ایران به دلیل عدم عضویت در معاهدهٔ کنوانسیون برن، مشمول قانون کپیرایت جهانی نیست. با این وجود، همانگونه که پیشتر اشاره شد، DRM ابزاری فراتر از قانون برای کنترل بدون اجازهٔ شرکتها بر مردم است و از این رو، تمامی مشکلات DRM، در ایران و برای مردم ایران نیز برقرار است.
ولی در کنار معضلاتی که شرکتهای خارجی بر مردم ایران وارد میکنند، به تازگی شرکتها و استارتآپهای داخلی نیز قدم در راه DRM گذاشته و بدون نگاه به وضعیت جهانی، راه بهاشتباه رفتهٔ کمپانیهای بزرگ را میروند. این شرکتها که بیشتر در حوزهٔ کتابهای الکترونیک، موسیقی و فیلم فعّالند، از ناآگاهی مردم ایران از چیستی DRM و معضلات آن و نداشتن تجربهٔ عمومی مبارزههای دیگران علیه این ابزارها نهایت سوءاستفاده را برای رسیدن به سود بیشتر انجام میدهند.
همانگونه که گفته شد برای مبارزه با این اقدامات، بهترین راه، استفاده نکردن از محصولات آنان و آگاه کردن مردم ایران نسبت به هزینههای بسیار زیادیست که برای داشتن یک تجربهٔ به ظاهر راحتتر میپردازند.