استفاده از کد پیشنهادشده توسط هوش مصنوعی چند پرسش مستقل دارد: آیا خروجی مشمول حمایت copyright است، آیا بخشی از آن با کد دارای مجوز شباهت دارد، قرارداد ابزار چه می‌گوید و مسئول تحویل نرم‌افزار به مشتری کیست؟ پاسخ یکی از این پرسش‌ها جای دیگری را نمی‌گیرد. مجاز بودن استفاده از یک ابزار، درستی کد یا پاک بودن تمام خروجی از تعهد مجوز را اثبات نمی‌کند.
این راهنما برای مرتب کردن تصمیم تیم توسعه نوشته شده است. مباحث حقوقی به حوزه قضایی و قرارداد واقعی بستگی دارند. منابع آمریکایی درباره copyright را نباید حکم مستقیم برای قرارداد ایرانی یا تمام کشورها دانست. اگر خروجی در محصول حساس، قرارداد بزرگ یا اختلاف مالکیت استفاده می‌شود، متن قرارداد و کد مشخص باید با متخصص همان حوزه بررسی شود. نتیجه کلی «مالک همه چیز هستید» یا «همه کدها ممنوع‌اند» اطلاعات کافی برای چنین تصمیمی ندارد.
مالکیت خروجی و منشأ کد دو مسئله‌اند
پرسش مالکیت بررسی می‌کند چه بخش‌هایی از یک اثر و با چه شرایطی حمایت می‌شوند. پرسش منشأ می‌پرسد آیا خروجی شامل بیان قابل شناسایی از منبع دیگری است و چه تعهدی درباره آن دارید. ممکن است درباره حمایت از خروجی خود تردید باشد و هم‌زمان درباره مجوز یک بخش اقتباس‌شده سؤال مطرح شود. یکی را با نبودن دیگری حل‌شده فرض نکنید.
U.S. Copyright Office در گزارش Part 2 منتشرشده در ژانویه ۲۰۲۵ به copyrightability خروجی‌های generative AI پرداخته است. محور این گزارش، مشارکت انسانی و بیان خلاقه قابل حمایت در چارچوب حقوق آمریکا است. صرف درخواست از مدل به‌طور خودکار تمام خروجی را اثر انسانی قابل حمایت نمی‌کند. این منبع را در محدوده موضوع و حوزه خودش بخوانید، نه به‌عنوان پاسخ جهانی مالکیت نرم‌افزار.
برای تیم، ثبت مشارکت واقعی انسان مفید است: طراحی مسئله، انتخاب راه‌حل، اصلاح کد و تصمیم‌های معماری. این ثبت نباید داستانی ساختگی درباره تولید کاملاً انسانی بسازد. هدف، توضیح فرایند و مسئولیت تصمیم‌هاست. وجود یک prompt طولانی نیز به‌تنهایی همه پرسش‌های حقوقی را پاسخ نمی‌دهد؛ نسبت آن با خروجی و کار انجام‌شده باید مشخص باشد.
مجوز منبع را از شباهت کلی تفکیک کنید
کدهای ساده برای یک وظیفه مشترک ممکن است شبیه باشند. اما یافتن شباهت، به خودی خود تصمیم حقوقی نهایی نیست و نبودن نتیجه در ابزار هم تضمین پاک بودن نیست. اگر تطابق مشخصی پیدا می‌شود، منبع، نسخه، فایل LICENSE و شرایط استفاده را بخوانید. یک عدد درصد شباهت، ماهیت کد و زمینه استفاده را کامل توضیح نمی‌دهد.
MIT مجوزی با شرط‌های مشخص است؛ متن رسمی MIT License الزام حفظ notice را بیان می‌کند. آن را با عبارت «هر کاری آزاد است و چیزی لازم نیست» خلاصه نکنید. اگر کد یا بخش لازم از آن را توزیع می‌کنید، روش رعایت شرط‌ها باید در بسته تحویل معلوم باشد. نام مجوز باید به فایل و منشأ واقعی مربوط باشد، نه حدس از پاسخ مدل.
GPL هم خانواده‌ای با شرایط دقیق است. متن GPLv3 و FAQ رسمی GNU درباره مفاهیم و تعهدهای آن توضیح می‌دهند. صرف دیدن واژه GPL در یک نتیجه جست‌وجو، برای حکم درباره کل محصول کافی نیست. شکل ترکیب، توزیع، نسخه مجوز و کد مورد استفاده باید مشخص شود.
اگر تیم نمی‌تواند تعهد مجوز را برای قرارداد محصول برآورده کند، تصمیم باید قبل از انتشار گرفته شود. حذف comment مجوز راه حل نیست؛ منشأ و شرط استفاده با حذف برچسب از بین نمی‌رود. گزینه می‌تواند انتخاب dependency مناسب‌تر یا نوشتن implementation مستقل با بررسی لازم باشد. بازنویسی سطحی نام متغیرها هم خودکار همه مسائل را حل نمی‌کند.
ابزار تشخیص تطابق، کمک بررسی است
GitHub برای بعضی پیشنهادهای Copilot قابلیت Code Referencing دارد. راهنمای Code Referencing محدوده و رفتار این قابلیت را شرح می‌دهد. مرجع نشان‌داده‌شده می‌تواند شما را به مخزن و مجوز مربوط برساند. این ابزار تحلیل حقوقی کامل تمام کد پروژه نیست و نتیجه آن نباید جای بررسی قرارداد منبع را بگیرد.
تنظیم مسدود کردن پیشنهادهای منطبق با کد عمومی نیز باید با محصول و طرح مورد استفاده تطبیق داده شود. رفتار همه سطح‌های یک ابزار الزاماً یکسان نیست. اگر سازمان سیاست مشخص دارد، آن را در تنظیم‌های قابل مدیریت ثبت کنید و روش بازبینی استثنا را روشن نگه دارید. اتکا به اینکه هر توسعه‌دهنده یک گزینه را دستی به خاطر می‌سپارد، قرارداد پایدار تیمی نمی‌سازد.
هنگام مشاهده تطابق، یافته را با داده لازم ثبت کنید: قطعه مربوط، URL منبع، مجوز و تصمیم انجام‌شده. اطلاعات خصوصی پروژه را برای توضیح یافته در یک issue عمومی منتشر نکنید. اگر بررسی تخصصی لازم است، مجموعه محدود و مربوط تهیه کنید تا شخص بررسی‌کننده مجبور نباشد از میان خروجی‌های پراکنده حدس بزند.
شرایط ابزار با حقوق منبع فرق دارد
به‌روزرسانی قراردادهای GitHub انتقال از Copilot Product Specific Terms به GitHub Generative AI Services Terms را برای اشتراک‌های جدید یا تمدیدشده از ۵ مارس ۲۰۲۶ توضیح می‌دهد. قرارداد مرتبط به تاریخ و نوع اشتراک وابسته است. ضمانت یا پوشش احتمالی را مجوز آزاد استفاده از هر خروجی یا تضمین صحت برنامه معرفی نکنید؛ متن همان قراردادی را بخوانید که سازمان واقعاً به آن متعهد است.
برای ابزارهای دیگر نیز همین تفکیک لازم است. داده prompt چگونه پردازش می‌شود، چه نوع حسابی استفاده می‌کنید و شرایط نگهداری چه می‌گوید؟ پاسخ از نام عمومی مدل به دست نمی‌آید. ممکن است محیط سازمانی و حساب شخصی قواعد متفاوتی داشته باشند. تصمیم ارسال کد مشتری باید با اجازه و قرارداد آن مشتری هماهنگ شود.
رازها، داده شخصی و کد محرمانه را فقط به دلیل مفید بودن context در prompt وارد نکنید. از نسخه کوچک و بی‌اطلاعات حساس مسئله استفاده کنید، اگر همان نسخه برای دریافت راهنمایی کافی است. این کار هم سطح داده منتقل‌شده را محدود می‌کند و هم سؤال فنی را روشن‌تر می‌سازد. کنترل محرمانگی موضوعی جدا از مالکیت خروجی است.
قرارداد مشتری باید محدوده تعهد را روشن کند
اگر قرارداد ادعا می‌کند تمام اجزا از صفر نوشته شده‌اند، استفاده از dependency یا خروجی ابزار باید با همان متن سازگار باشد. تیم نباید تعهدی بدهد که فرایند واقعی‌اش را توصیف نمی‌کند. شرح استفاده از ابزار، اجزای ثالث و مسئولیت نگهداری باید پیش از تحویل روشن شود. این موضوع برای کد دستی هم وجود دارد؛ AI فقط لایه دیگری از پرسش را اضافه می‌کند.
مالکیت کد اختصاصی، حق استفاده از اجزای متن‌باز و دسترسی به سرویس میزبانی‌شده را در تحویل جدا بنویسید. مشتری ممکن است کد برنامه را دریافت کند ولی کلید یا قرارداد یک API به نام دیگری باشد. چنین وابستگی باید در مستند تحویل دیده شود. انتقال مخزن به تنهایی همه حقوق و دسترسی‌های عملیاتی را منتقل نمی‌کند.
برای تغییرهای بعدی، مسئول بررسی نسخه و مجوز dependencyها را مشخص کنید. بسته‌ای که امروز شرایط مناسب دارد ممکن است در نسخه دیگری قرارداد متفاوتی داشته باشد. Lockfile، فهرست اجزا و یادداشت تغییر به پیگیری کمک می‌کنند. نام ابزار تولید کد در یک سطر، جای صورت‌وضعیت واقعی وابستگی‌ها را نمی‌گیرد.
درستی و مسئولیت فنی همچنان با تیم تحویل است
کد تولیدشده ممکن است API ناموجود، dependency نامناسب یا منطق اشتباه داشته باشد. نسبت دادن خطا به ابزار پاسخ مناسبی برای مشتری نیست. تیم باید کد را بفهمد و محدوده رفتار آن را بررسی کند. اگر خروجی پیچیده‌تر از توان نگهداری تیم است، پذیرفتن آن صرفاً چون سریع تولید شده تصمیم عملی مناسبی نیست.
بازبینی فنی باید بر نیاز واقعی تمرکز کند: کنترل دسترسی، اعتبارسنجی و حالت شکست. توضیح مدل درباره «امن بودن» implementation شاهد محسوب نمی‌شود. نمونه‌ای که داده ثابت دارد رفتار Production با ورودی نامعتبر یا عملیات هم‌زمان را ثابت نمی‌کند. نتیجه بررسی را با محدوده‌اش ثبت کنید و قابلیت آزمایش‌نشده را در متن تحویل تأییدشده ننامید.
برای فرایند مرور، مقاله Pair Programming و برای ثبت مراحل تحویل، CI/CD فرانت‌اند ادامه‌های مرتبط‌اند. هیچ روش فنی به‌تنهایی نظر حقوقی درباره یک اختلاف صادر نمی‌کند، ولی مستند روشن به یافتن مسئله و جمع‌آوری شواهد لازم کمک می‌کند.
یک سیاست کوتاه و قابل اجرا بنویسید
سیاست تیم باید مشخص کند چه داده‌ای وارد ابزار می‌شود، چه خروجی‌ای نیاز به بررسی منشأ دارد و تصمیم پذیرش کجا ثبت می‌شود. متن بسیار کلی «مسئولانه استفاده کنید» رفتار مشخصی تعریف نمی‌کند. توسعه‌دهنده باید بداند در مشاهده تطابق چه قدمی بردارد و چه کسی درباره سازگاری مجوز با قرارداد تصمیم می‌گیرد.
برای شروع، یک تغییر واقعی و محدود را انتخاب و مسیر تصمیم آن را ثبت کنید. منبع‌های احتمالی، شروط ابزار، اصلاح انسانی و وابستگی نهایی را نگه دارید. اگر سؤال حقوقی باقی مانده، همان سؤال و مدارک مربوط را به متخصص حوزه قرارداد بدهید. این مسیر از حکم‌های عمومی درباره مالکیت تمام خروجی‌ها دقیق‌تر است و به تیم کمک می‌کند تحویل را با واقعیت فرایندش هماهنگ نگه دارد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!