تملک اموال معنوی

هر مالکیتی ‌همراه با هزینه‌، ریسک‌ها و مسوولیت‌های خود است و هر کسی که این موارد را جدی نگیرد، نمی‌تواند به‌طور کامل از مالکیت خود استفاده کند. در دنیای فیزیکی، همه این مساله را بخوبی می‌دانیم و به ‌آن آگاه هستیم. اگر خانه‌ای داشته‌باشیم، باید هر ساله برای آن مالیات بدهیم، به‌خاطر نگهداری و مصرف انرژی آن هزینه بپردازیم.

اگر نتوانیم از عهده این موارد بر آییم، در این صورت مجبوریم قید داشتن آن را بزنیم و ساختمان بتدریج متروکه، در نهایت خراب می‌شود و به ساختمانی دیگر با مالکیت متفاوت درخواهد آمد.

در دنیای معنوی و دیجیتال، اوضاع کمی متفاوت است. نمی‌توان مرز و حدود مشخصی برای مسوولیت‌های موجود در قبال یک حق معنوی مشخص کرد. برای مثال، اگر یک حق تجاری به‌ثبت برسانیم، در صورتی که از آن دفاع نکنیم، از دست خواهد رفت.

نگهداری یک بخش از نرم‌افزار آزاد نیز تلاشی گسترده می‌طلبد ؛ چرا که بخش‌های اعظمی از تولید نرم‌افزار در حال تغییر است، کامپایلرها، وابستگی‌ها، سیستم‌های عامل و توافق‌های برنامه‌نویسی همه در حال تغییرند. مسوولیت نگهداری از نرم‌افزار نباید ساده انگاشته شود، اگر بخواهیم پروژه نرم‌افزاری پویا و مفید باشد، باید آن را به‌روز نگهداریم. نگهداری از پروژه معمولا بر دوش توسعه‌دهندگان اصلی آن است، نه کسانی که کمک اندکی در توسعه آن می‌کنند. کسانی که گاهی به پروژه کمکی می‌کنند و در وقت خالی خود یک وصله امنیتی یا قابلیتی به آن اضافه می‌کنند، تمایل دارند پروژه به‌روز شود، اما نه توسط آنها.

در اختیار داشتن چیزی مسوولیت‌هایی را نیز ایجاد می‌کند. برای مثال در برخی کشورها اگر خانه‌ای داشته باشید و کسی از روی پله‌های آن سر بخورد و آسیب ببیند، صاحبخانه مسوول است. اگر ماشینی داشته باشید که از کسی قرض گرفته باشید و ترمزش کار نکند و تصادف کند، مسوول صاحب خودروست. در مورد کدها نیز، ایجاد یک وصله حتی اگر کوچک هم باشد، باعث می‌شود تولیدکننده آن وصله در مقابل آن مسوول باشد.

یکی از بزرگ‌ترین جنگ‌های رخ داده شده در باب صاحب کد بودن، بین سان و ناول در مورد یک پلاگین در اوپن‌آفیس شکل گرفت که اتفاقات جالبی در پس آن ‌دارد. سان دیگر آن را تولید نکرد ؛ چرا که ناول آن را به سان نمی‌داد. ناول این مولفه را خود به‌تنهایی تولید کرده بود و تمایل داشت آن را به‌روز نگه دارد و نگهداری کند. نتیجه منطقی این بود که سان اجازه دهد ناول به کار خود بپردازد و مسوولیت‌های آن پلاگین را هم به عهده بگیرد ؛ اما اشتباه سان اینجا بود که تلاش کردند کاری را که قبلا انجام شده بود، از اول و خودشان انجام دهند که باعث تلف شدن وقت و زمان بسیاری از پروژه اوپن‌آفیس شد. مورد دیگر این که کد می‌تواند هسته یک نرم‌افزار را بهتر به‌کار بگیرد، اما بدون آن مستقل نیست ؛ بنابراین می‌تواند به‌صورت مستقل به حیات خود ادامه دهد.

نکته‌ای که باید به آن توجه داشت این است که یک وصله به‌هیچ عنوان نمی‌تواند ارزش کار اصلی را پایین بیاورد و در واقع باید تحسین نیز بشود. فرض کنید برای یک نرم‌افزار وصله‌ای طراحی کرده‌اید، متعاقبا انتظار می‌رود که حقوق کامل آن نرم‌افزار را در اختیار داشته باشید. در کانونیکال، اگر کسی همکاری‌ای اینچنینی با سیستم داشته باشد، مجوز بسیاری از کارها را دریافت می‌کند. بنابراین کسی که همکاری می‌کند امکان فروش، مجوزدهی دوباره و حتی تولید تی‌شرت را دارد و هیچ مسوولیتی در باب تصاحب آن ملک معنوی نخواهد داشت.

اما در مواردی که صاحب حقیقی اثر و همکاری کننده وجود ندارد، تکلیف چه می‌شود؟

در دنیای بیرون کپی‌رایت و کد مدل‌هایی داریم که می‌توانیم به‌آنها رجوع کنیم. برای مثال، شرکت‌ها سهام خود را می‌فروشند و سهام شرکت در اختیار افراد بسیاری قرار دارد. این شرکت‌ها چند مالک دارند و هر‌کدام از آنها عقاید، نظرها و ایده‌آل‌های مختلفی دارند.

نباید برای هر اقدامی، نظر تمامی افراد جلب شود چرا که عملا در این صورت هیچ تصمیمی گرفته نخواهد شد. در حقیقت بسیاری از کارها به تعداد محدودی از افراد سپرده می‌شود تا برآیند عملکرد را مثبت حفظ کنند.

در دنیای مجازی، باید به هر خط کد یا هر وصله کوچک بیندیشیم و ارزشی برابر با بقیه کد برای آن در نظر بگیریم. اگر وصله کوچکی به اشتراک گذاشته می‌شود اما اهدا نمی‌گردد، صاحب آن وصله مسوولیت آن را به عهده دارد. بنابراین از نظر تئوری، هر تغییری در وضعیت کلی نرم‌افزار باید توافق هر مالک را جلب کند ؛ اما در عمل، این کار نشدنی است.

موزیلا، اوبونتو ویکی و حتی ویکی‌پدیا در تلاش بودند تا مجوزهای خود را به‌شیوه‌ای تغییر دهند که همکاری عمومی جلب شود و از طرف دیگر به این همه کاغذبازی نیاز نباشد.

به‌عنوان مثال اگر یک مشکل امنیتی در GPLv2 رخ بدهد، لینوس (خالق لینوکس) باید بحث، بررسی و گفت و گوهای زیادی انجام دهد تا تکلیف نگارش بعدی هسته لینوکس مشخص شود. در صورتی که چسبیدن به بخشی کوچک از چیزی که متعلق به شخص دیگری است، صحیح نیست. بهتر است در این موارد، راهبرد مالکیت بهتری انتخاب کنیم که شامل میتینگ‌ها، نگهداری از نرم‌افزار و همچنین تصمیم‌گیری در باب حرکت‌های بزرگ است.

تملک و تولید باعث یک چیز می‌شود: امکان فضل و بخشش. نمی‌توان چیزی را ببخشیم و توزیع کنیم که مالک آن نیستیم، مگر این که صاحب آن باشیم و همکاری خوبی با آن مجموعه داشته باشیم. برتی مثال هدیه بسیار متفاوت‌تر از وام است. هدیه هیچ وابستگی‌ای ایجاد نمی‌کند، گیرنده را قدرتمندتر می‌سازد و هدیه‌دهنده را از مسوولیت‌های مالکیت آن بخش رها می‌کند.

محمدرضا قربانی

منبع: www.markshuttleworth.com