CLA در مقابل DCO: پروژهٔ متن‌باز شما باید از کدام توافق‌نامهٔ مشارکت‌کننده استفاده کند؟

پروژهٔ جانبی‌تان همین حالا از ۵۰۰ ستاره گذشته است، و یک غریبه اولین درخواست ادغام جدی را باز کرده است: ۲٬۰۰۰ خط که مشکلی را برطرف می‌کند که ماه‌ها از آن طفره می‌رفتید. می‌خواهید دکمهٔ ادغام را بزنید. اما پیش از این کار، این پرسش ناخوشایند را بپرسید: آیا واقعاً حق قانونی انتشار آن کد را دارید — و ادامهٔ انتشار آن تحت مجوز خودتان، برای همیشه، مهم نیست آن مشارکت‌کننده برای چه کسی کار می‌کند؟

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

دو سازوکار این مشکل را حل می‌کنند، و تقریباً هر پروژهٔ متن‌بازی یکی از آن‌ها را انتخاب می‌کند: توافق‌نامهٔ مجوز مشارکت‌کننده (CLA) و گواهی مبدأ توسعه‌دهنده (DCO). هر دو برای این وجود دارند که مشخص کنند یک مشارکت‌کننده اجازهٔ انجام آن مشارکت را دارد و پروژه حق توزیع آن را دارد. اما در وزن، اصطکاک و آنچه بعداً به شما اجازه می‌دهند انجام دهید، به‌شدت متفاوت‌اند. این راهنما توضیح می‌دهد که هرکدام چگونه کار می‌کنند، چه زمانی کدام را انتخاب کنید، و چگونه انتخاب خود را در یک بعدازظهر پیاده‌سازی کنید.

چرا پروژهٔ شما اصلاً به سیاست مشارکت نیاز دارد​

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

• اعطای ورودی. مجوز خروجی شما (MIT، Apache-2.0، GPL) به کاربران می‌گوید با کد شما چه کاری می‌توانند بکنند. یک سیاست مشارکت صریحاً مشخص می‌کند که مشارکت‌های ورودی تحت شرایط سازگار می‌رسند، تا بتوانید کار ترکیبی را بدون ردیابی دستی منشأ هر فایل توزیع کنید.
• ادعاهای کارفرما. بیشتر قراردادهای استخدامی مالکیت معنوی پروژه‌های جانبی را به کارفرما واگذار می‌کنند، دست‌کم برای کار مرتبط با شغل کارمند. سیاستی که از مشارکت‌کنندگان می‌خواهد تأیید کنند حق ارسال دارند، این مسئولیت — و ردّ کاغذی آن — را بر دوش مشارکت‌کننده می‌گذارد.
• اختیار بازمجوزدهی. اگر روزی بخواهید مجوز را تغییر دهید، نسخهٔ تجاری اضافه کنید، یا پروژه را به یک بنیاد اهدا کنید، به حقوق همهٔ مشارکت‌کنندگان نیاز دارید. گردآوری این اجازه به‌صورت گذشته‌نگر از ده‌ها مشارکت‌کنندهٔ پیشین چیزی میان دشوار و ناممکن است. سیاستی که روز اول انتخاب می‌شود تعیین می‌کند که آن در باز بماند یا نه.
• حمایت از حق اختراع. مشارکت‌های کدی می‌توانند حقوق اختراع را با خود حمل کنند. برخی سیاست‌ها اعطای صریح حق اختراع را شامل می‌شوند؛ برخی نمی‌شوند، و این موضوع بیش از آنچه بیشتر نگه‌دارندگان درک می‌کنند اهمیت دارد.

هیچ‌یک از این‌ها نیازی به استخدام یک شرکت حقوقی ندارد. نیاز به انتخاب CLA یا DCO، نوشتن آن در مخزن‌تان، و اجرای خودکارش دارد. در ادامه ببینید هر انتخاب چه چیزی به همراه دارد.

توافق‌نامهٔ مجوز مشارکت‌کننده (CLA) چیست؟​

توافق‌نامهٔ مجوز مشارکت‌کننده سندی حقوقی و امضاشده میان مشارکت‌کننده و پروژه (یا شرکت یا بنیاد پشت آن) است. مشارکت‌کننده یک‌بار امضا می‌کند، و آن امضا همهٔ مشارکت‌های آیندهٔ او را پوشش می‌دهد.

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

CLA فردی در مقابل شرکتی​

• CLA فردی (ICLA): توسط شخصی امضا می‌شود که به نمایندگی از خودش مشارکت می‌کند. معمولاً به پروژه یک مجوز گستردهٔ حق تکثیر و اغلب مجوز حق اختراع اعطا می‌کند، در حالی که مشارکت‌کننده حق تکثیر خود را حفظ می‌کند.
• CLA شرکتی (CCLA): توسط یک شرکت امضا می‌شود و به کارمندانش اجازهٔ مشارکت می‌دهد. شرکت همان حقوق را برای کاری که افرادش ارسال می‌کنند اعطا می‌کند. پروژه‌هایی که مشارکت‌های شرکتی را بدون CCLA می‌پذیرند، به این اعتماد می‌کنند که مدیر هر کارمند می‌داند — و تأیید می‌کند — و این دقیقاً همان نوع اعتمادی است که در بررسی دقیق محو می‌شود.

اعطای مجوز در مقابل واگذاری حق تکثیر​

بیشتر CLAهای مدرن اعطای مجوز هستند: مشارکت‌کننده مالکیت را حفظ می‌کند و به پروژه مجوزی دائمی، جهانی و بدون حق امتیاز می‌دهد — اغلب مجوزی به‌قدری گسترده که بازمجوزدهی را ممکن کند. ICLA بنیاد نرم‌افزار آپاچی نمونهٔ کانونی این رویکرد است.

اقلیتی از پروژه‌ها از واگذاری حق تکثیر استفاده می‌کنند، که در آن مشارکت‌کننده مالکیت را کاملاً منتقل می‌کند (رویکرد بنیاد نرم‌افزار آزاد). واگذاری به پروژه حداکثر آزادی را برای اجرای حق و بازمجوزدهی می‌دهد، اما بیشترین تقاضا را از مشارکت‌کنندگان دارد و در پروژه‌های اجتماع‌محور از رونق افتاده است.

هزینهٔ CLA برای شما و مشارکت‌کنندگانتان​

معاوضه، اصطکاک است. یک مشارکت‌کنندهٔ تازه‌وارد باید درخواست ادغام را رها کند، سندی حقوقی بخواند، آن را امضا کند (معمولاً الکترونیکی)، و منتظر بماند تا بررسی وضعیت سبز شود تا یک نگه‌دارنده کدش را بازبینی کند. ابزارها این کار را تقریباً بی‌درد کرده‌اند — ربات‌هایی مانند CLA Assistant روی درخواست ادغام با پیوند امضا نظر می‌گذارند و امضا را خودکار ثبت می‌کنند — اما همچنان دروازه‌ای میان «باگ شما را درست کردم» و «می‌توانی اصلاح من را ادغام کنی» است. برخی مشارکت‌کنندگان گذری از آن دلسرد می‌شوند.

در عوض، پروژه یک سابقهٔ امضاشده و قابل حسابرسی به دست می‌آورد: این شخص، در این تاریخ، این حقوق را اعطا کرد. برای پروژه‌های شرکت‌محور، پروژه‌های دومجوزه، و هر چیزی که ممکن است روزی خریداری شود، آن ردّ کاغذی ارزش پول واقعی دارد.

گواهی مبدأ توسعه‌دهنده (DCO) چیست؟​

گواهی مبدأ توسعه‌دهنده در سال ۲۰۰۴ توسط بنیاد لینوکس برای هستهٔ لینوکس معرفی شد، دقیقاً برای پرهیز از سنگینی یک CLA. این یک قراردادی نیست که مشارکت‌کننده امضا کند و بایگانی شود. یک گواهی کوتاه است — پنج بند، نسخهٔ ۱.۱ — که مشارکت‌کننده با هر کامیت با افزودن خط Signed-off-by به پیام کامیت آن را تأیید می‌کند:

Fix off-by-one error in retry backoff calculation
 
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
 
Signed-off-by: Alex Rivera <[email protected]>

افزودن این خط فقط یک گزینه است: git commit -s آن را به‌طور خودکار با استفاده از هویت Git تنظیم‌شدهٔ شما اضافه می‌کند. با امضای این تأییدیه، مشارکت‌کننده گواهی می‌دهد که:

۱. او مشارکت را (به‌طور کامل یا جزئی) خلق کرده و حق ارسال آن تحت مجوز متن‌باز پروژه را دارد، یا ۲. مشارکت او بر پایهٔ کار پیشینی است که از قبل تحت مجوز متن‌باز مناسبی است که این ارسال را مجاز می‌کند، یا ۳. او مشارکت را از شخص دیگری دریافت کرده که یکی از موارد بالا را گواهی کرده، و او آن را تغییر نداده است، و ۴. او می‌داند که مشارکت و سابقهٔ آن — از جمله تأییدیهٔ او — عمومی است و به‌طور نامحدود نگه‌داری می‌شود.

کل سازوکار همین است. بدون سند جداگانه، بدون اتصال حساب، بدون فرایند ورود به پروژه. اجرا یک بررسی وضعیت است: اپ DCO یا بررسی معادلی تأیید می‌کند که هر کامیت در درخواست ادغام تأییدیهٔ معتبر دارد، و نگه‌دارندگان تنها زمانی ادغام می‌کنند که سبز باشد.

محدودیت‌های عامدانهٔ DCO​

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

حامیان این را یک مزیت می‌دانند: موانع پایین DCO خودش هدف است. هستهٔ لینوکس، GitLab (که در سال ۲۰۱۷ از CLA به آن تغییر کرد)، و Chef (که در سال ۲۰۱۶ تغییر کرد) همه نتیجه گرفتند که تأییدیهٔ هر-کامیت منشأ موردنیازشان را فراهم می‌کند بدون آنکه بر هر مشارکت‌کننده مالیات بگذارد. کمیتهٔ فنی OpenStack در سال ۲۰۲۵ تصمیم گرفت CLA خود را با DCO برای همهٔ مشارکت‌ها جایگزین کند. روند صنعت انکارناپذیر است — اما یک روند برای پروژهٔ شما حکم قطعی نیست، همان‌طور که بخش‌های بعدی توضیح می‌دهند.

CLA در مقابل DCO، کنار هم​

چه زمانی CLA انتخاب درست است​

CLA را انتخاب کنید هنگامی که آیندهٔ پروژه ممکن است به حقوقی وابسته باشد که DCO آن‌ها را ثبت نمی‌کند:

• قصد دومجوزدهی یا بازمجوزدهی دارید. اگر نسخهٔ تجاری، تغییر مجوز، یا حرکت از کپی‌لفت به مجوز آزاد حتی به‌طور دور از ذهن محتمل باشد، CLA با اعطای گستردهٔ متقابل تنها راه سبک برای باز نگه‌داشتن این گزینه است. بازسازی رضایت سال‌ها بعد، سناریوی کابوس است.
• شرکتی پشت پروژه ایستاده است. حامیان شرکتی، خریداران، و مشتریان سازمانی که بررسی دقیق مالکیت معنوی انجام می‌دهند، ثبتی از امضاها می‌خواهند، نه باستان‌شناسی. گوگل، پروژه‌های آپاچی، و Canonical دقیقاً به همین دلیل از CLA استفاده می‌کنند.
• حق اختراع در حوزهٔ شما مهم است. کدک‌ها، پروتکل‌های بی‌سیم، معماری‌های مدل یادگیری ماشین — در زمینه‌های پُر از حق اختراع، اعطای صریح حق اختراع در CLA کار واقعی انجام می‌دهد که DCO بی‌صدا از آن می‌گذرد.
• یک بنیاد آن را الزامی می‌کند. برخی بنیادها CLA خود را شرط میزبانی یا ارتقا قرار می‌دهند. پیش از فرض اینکه DCO کافی است، بررسی کنید.

اگر این مسیر را می‌روید، خود CLA را استاندارد و کسل‌کننده نگه دارید: به‌جای پیش‌نویس از صفر، از ICLA آپاچی یا قالب Harmony شروع کنید، هم نسخهٔ فردی و هم شرکتی را منتشر کنید، و از روز اول یک ربات امضا راه‌اندازی کنید تا اصطکاک یک کلیک باشد، نه رفت‌وبرگشت با PDF.

چه زمانی DCO برنده می‌شود​

DCO را انتخاب کنید هنگامی که مشارکت‌ها رگ حیاتی پروژه‌اند و اصطکاک دشمن است:

• پروژه‌های اجتماع‌محور با مشارکت‌کنندگان گذری فراوان. اصلاح مستندات، تصحیح غلط تایپی، وصله‌های کوچک باگ — مشارکت‌هایی که بیش از همه احتمال دارد از یک دروازهٔ امضا دلسرد شوند، همان‌هایی هستند که DCO به‌راحتی مدیریت می‌کند.
• مجوز آزاد، بدون برنامهٔ بازمجوزدهی. اگر پروژه برای همیشه MIT یا Apache-2.0 بماند و نسخهٔ تجاری در نقشهٔ راه نباشد، حقوق اضافی CLA چیز کمی برایتان می‌خرد.
• نگه‌دارندگان تک‌نفره و تیم‌های کوچک. DCO نیازی به زیرساخت امضا، نهاد حقوقی برای نگه‌داری توافق‌نامه‌ها، یا فرایند امضای متقابل فرم‌های شرکتی ندارد. حکمرانی‌ای است که می‌توانید از یک فایل CONTRIBUTING.md و یک بررسی وضعیت اجرا کنید.
• رویکرد حداکثر سازگاری. برخی مشارکت‌کنندگان — به‌ویژه کسانی که در شرکت‌های بزرگ با سیاست‌های سخت‌گیرانهٔ مالکیت معنوی کار می‌کنند — می‌توانند DCO را تأیید کنند اما نمی‌توانند بدون بررسی حقوقی یک CLA بیرونی را امضا کنند. DCO این در را باز نگه می‌دارد.

هرکدام را انتخاب کنید، تصمیم را بنویسید. یک CONTRIBUTING.md که سیاست را اعلام می‌کند، جریان دقیق تأییدیه یا امضا را نشان می‌دهد، و متن کامل را پیوند می‌دهد، رایج‌ترین منبع سردرگمی را از میان می‌برد: حدس زدن مشارکت‌کنندگان دربارهٔ الزامات از یک بررسی وضعیت ناموفق.

۵ اشتباهی که هر انتخاب را تضعیف می‌کند​

۱. هر دو را گفتن. رایج‌ترین شکست واقعی، CONTRIBUTING.md است که در یک پاراگراف تأییدیهٔ DCO و در پاراگراف دیگر امضای CLA می‌خواهد — معمولاً پس از یک مهاجرت نیمه‌کاره. مشارکت‌کنندگان یک دستور را پیروی می‌کنند، بررسی دیگر شکست می‌خورد، و نگه‌دارندگان به‌هرحال ادغام می‌کنند، که هدف هر دو را باطل می‌کند. یک سازوکار را انتخاب کنید، آن را اجرا کنید، و هر ردی از دیگری را پاک کنید.

۲. بدون اجرای خودکار. سیاستی که فقط در نوشتار اعلام شده، پیشنهاد است. بررسی را به‌عنوان یک بررسی وضعیت الزامی در جریان کاری درخواست ادغام بگنجانید — اپ DCO برای تأییدیه‌ها، CLA Assistant یا EasyCLA برای امضاها — تا مشارکت بدون رضایت به‌طور تصادفی یا از خستگی نگه‌دارنده ادغام نشود.

۳. نادیده گرفتن مشارکت‌کنندگان شرکتی. اگر شرکت‌ها از پروژهٔ شما استفاده و آن را وصله‌کاری می‌کنند، کارمندان در ساعات کاری کد ارسال خواهند کرد. تحت سیاست CLA، این یعنی امضای CCLA را زودتر، وقتی رابطه گرم است، بگیرید. تحت سیاست DCO، یعنی مطمئن شوید الزام تأییدیه به‌قدری نمایان است که اولین مشارکت هیچ‌کس به یک حادثهٔ مالکیت معنوی تبدیل نشود.

۴. فرض اینکه قراردادهای استخدامی اجازهٔ مشارکت می‌دهند. روی دیگر همان سکه: اگر به پروژه‌های دیگر مشارکت می‌کنید، ابتدا قرارداد استخدامی خودتان را بررسی کنید. بسیاری مالکیت معنوی پروژه‌های جانبی مرتبط با کار را به‌طور پیش‌فرض به کارفرما واگذار می‌کنند. گواهی DCO («من حق ارسال این را دارم») تنها زمانی درست است که آن کاغذبازی چنین بگوید.

۵. بدون سیاست برای کد تولیدشده با کمک هوش مصنوعی. مشارکت‌های ماشین‌تولید پرسش‌های منشأیی را مطرح می‌کنند که نه متن DCO از دوران ۲۰۰۴ و نه بیشتر قالب‌های CLA پیش‌بینی کرده‌اند. موضع خود را تعیین کنید — مجاز با بازبینی، با افشا، یا ممنوع — و آن را در CONTRIBUTING.md در کنار سیاست CLA/DCO خود بیان کنید، پیش از آنکه اولین درخواست ادغام تولیدشده با هوش مصنوعی برسد، نه بعد از آن.

جنبهٔ مالی پروژه‌تان را فراموش نکنید​

بخشی که نگه‌دارندگان تا فصل مالیات به تعویق می‌اندازند این است: همان لحظه‌ای که پروژه‌تان اولین دلار را به دست می‌آورد — پرداخت‌های GitHub Sponsors، کمک‌های Open Collective، یک مشاوره که به خاطر README شما آمده — دارای امور مالی است، و امور مالی نیازمند دفاتر است.

همان نظمی که منشأ مشارکت را قابل حسابرسی می‌کند، پول پروژه را قابل مدیریت می‌سازد. درآمد حمایت مالی را جدا از حقوق خودتان ردیابی کنید تا بدانید چه درآمد خوداشتغالی مشمول مالیات است. هزینه‌های پروژه — تمدید دامنه، دقایق CI، بعدازظهری که یک وکیل صرف بررسی CLA شما کرد — را در حساب‌های خودشان ثبت کنید تا کسورات در صورت‌حساب کارت شخصی محو نشوند. اگر پروژه به یک LLC تبدیل شود یا به یک میزبان مالی بپیوندد، سوابق تاریخی تمیز این گذار را کسل‌کننده می‌کند نه پزشکی قانونی.

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

دفاتر پروژه‌تان را به‌قدر تاریخچهٔ Git آن تمیز نگه دارید​

انتخاب میان CLA و DCO یک بعدازظهر وقت می‌گیرد؛ سر و سامان دادن به منشأ یا امور مالی پروژه سال‌ها بعد، هفته‌ها وقت می‌گیرد. همین حالا تصمیم مشارکت را بگیرید، اجرای آن را خودکار کنید، و به پول پروژه همان توجهی را بدهید که به کامیت‌هایش می‌دهید. Beancount.io حسابداری متن‌ساده را فراهم می‌کند که به شما شفافیت کامل و کنترل بر داده‌های مالی‌تان می‌دهد — بدون جعبهٔ سیاه، بدون قفل شدن به فروشنده. رایگان شروع کنید و ببینید چرا توسعه‌دهندگان و متخصصان مالی به حسابداری متن‌ساده روی می‌آورند.