صفحه نمایش رایانه با چند خط کد برنامه‌نویسی

فرض کنید مدیر یک استارتاپ، بی‌آنکه حتی یک خط برنامه‌نویسی بلد باشد، در چند شب با چند جمله ساده به یک مدل زبانی، اپلیکیشنی کامل بسازد؛ اپلیکیشنی که کار می‌کند، مشتری جذب می‌کند و حالا سرمایه‌گذار می‌خواهد بداند دقیقاً چه چیزی را می‌خرد. پرسش حقوقی همین‌جا متولد می‌شود؛ این کد مال کیست؟ اگر بخشی از آن از کد دیگران برداشته شده باشد، چه کسی پاسخ‌گوست؟ و اگر حفره امنیتی‌اش داده مشتریان را بیرون بریزد، آیا می‌توان گفت «ماشین نوشته، نه من»؟

این پرسش‌ها دیگر فرضی نیستند. مؤسسه حقوقی Heuking در ۲۰ مهر ۱۴۰۵ (۱۲ اکتبر ۲۰۲۶) تحلیلی مفصل درباره «وایب‌کدینگ» (Vibe Coding) منتشر کرده است؛ یعنی ساختن نرم‌افزار فقط با دستورهای زبان طبیعی، که در آن کاربر غالباً کد تولیدشده را نه می‌خواند و نه بازبینی می‌کند. هم‌زمان، وکلای Steptoe در Bloomberg Law هشدار داده‌اند که سپردن کدنویسی به هوش مصنوعی، خطر دعاوی کپی‌رایت را نه‌تنها از بین نمی‌برد، بلکه ممکن است بیشتر هم بکند.

۱. مسئله اصلی، هوش مصنوعی نیست؛ غیبت نظارت انسانی است

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

۲. نرم‌افزاری که شاید هیچ صاحبی ندارد

حمایت کپی‌رایت از برنامه رایانه‌ای، در اغلب نظام‌های حقوقی، بر وجود یک پدیدآورنده انسانی استوار است. در آلمان، قانون کپی‌رایت فقط انسان را پدیدآورنده می‌شناسد و در آمریکا نیز دادگاه تجدیدنظر ناحیه کلمبیا در پرونده Thaler v. Perlmutter (۲۸ اسفند ۱۴۰۳ / ۱۸ مارس ۲۰۲۵) و رویه اداره کپی‌رایت، آثاری را که صرفاً هوش مصنوعی پدید آورده، بیرون از حمایت دانسته‌اند. نتیجه برای وایب‌کدینگ تکان‌دهنده است؛ برنامه‌ای که تماماً ماشین نوشته، هرقدر هم بزرگ و ارزشمند باشد، ممکن است عملاً در قلمرو عمومی قرار گیرد، چون دستورهای کاربر معمولاً فقط ایده و کارکرد را توصیف می‌کنند و ایده موضوع حمایت نیست. وضعیت وقتی تغییر می‌کند که انسان معماری، ساختار داده و چیدمان ماژول‌ها را تعیین کند یا خروجی را به‌طور جدی بازنویسی کند. پیامد عملی‌اش به نظر من روشن است؛ کسی که در دعوا به حق مؤلف استناد می‌کند، باید سهم انسانی را اثبات کند و بدون مستندسازی فرایند توسعه، این اثبات تقریباً ناممکن است! هر دو منبع، حمایت از اسرار تجاری را راه جایگزین می‌دانند، اما این راه هم شرط دارد؛ اگر شرکت اجازه داده باشد ارائه‌دهنده ابزار از کدش برای آموزش مدل استفاده کند، ادعای محرمانگی سست می‌شود.

۳. کد دیگران در دل کد شما؛ تله مجوزهای متن‌باز

مدل‌های زبانی با حجم عظیمی از کدهای عمومی آموزش دیده‌اند و گاه بخش‌هایی از همان کدها را بازتولید می‌کنند. به گزارش Heuking، دیدگاه غالب در آلمان این است که شرکتی که چنین کدی را در محصولش به کار می‌برد، خودش مسئول نقض است و قانونی یا غیرقانونی بودن آموزش مدل در این مسئولیت اثری ندارد. خطر اصلی در مجوزهای متن‌باز است؛ مجوزهای «کپی‌لفت» مانند GPL اقتضا می‌کنند نرم‌افزار مشتق، هنگام توزیع، با همان شرایط و همراه با کد منبع عرضه شود، و حتی مجوزهای آسان‌گیر مانند MIT و Apache نیز حفظ اعلان‌های کپی‌رایت و مجوز را لازم می‌دانند؛ اعلان‌هایی که در کد تولیدشده با هوش مصنوعی معمولاً غایب‌اند. Steptoe هم یادآوری می‌کند که نقض این شروط می‌تواند هم نقض کپی‌رایت باشد و هم نقض قرارداد. نکته ظریف‌تر این است که تعهد جبران خسارتِ ارائه‌دهندگان ابزار معمولاً به فعال بودن فیلترهای تشابه کد مشروط است؛ معتقدم شرکتی که این فیلترها را خاموش می‌کند، در واقع چتر حمایتی خود را با دست خودش بسته است.

۴. داده‌های شخصی و امنیت؛ مسئولیتی که منتقل نمی‌شود

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

۵. مسئولیت محصول و قراردادها؛ مقررات به شیوه ساخت اهمیت نمی‌دهد

حقوق اتحادیه اروپا تکالیف را به خود محصول گره می‌زند، نه به شیوه تولید آن. تکالیف گزارش‌دهی مقرره تاب‌آوری سایبری (CRA) از ۲۰ شهریور ۱۴۰۵ (۱۱ سپتامبر ۲۰۲۶) اجرا شده و اجرای کامل آن از ۲۰ آذر ۱۴۰۶ (۱۱ دسامبر ۲۰۲۷) است؛ دستورالعمل جدید مسئولیت ناشی از کالا هم، که پیش‌تر در یادداشت دیگری درباره‌اش نوشته‌ام، نرم‌افزار را صراحتاً کالا می‌داند و مهلت انتقال آن به حقوق داخلی ۱۸ آذر ۱۴۰۵ (۹ دسامبر ۲۰۲۶) است. یک مشکل فنی‌ـ‌حقوقی جالب هم وجود دارد؛ کدی که هوش مصنوعی از یک کتابخانه بیرونی بازتولید کرده، در فهرست اجزای نرم‌افزار (SBOM) به‌عنوان وابستگی بیرونی ثبت نمی‌شود و ظاهراً «توسعه داخلی» است، پس آسیب‌پذیری‌های کتابخانه اصلی ممکن است هرگز ردیابی نشود. در سطح قرارداد هم Heuking پیشنهاد می‌کند قراردادهای توسعه نرم‌افزار روشن کنند آیا و تا چه حد استفاده از هوش مصنوعی مجاز است و خطر فقدان حمایت کپی‌رایت یا نقض حق دیگران با کیست؛ و در معاملات خرید شرکت، استفاده از هوش مصنوعی در توسعه نرم‌افزار جزو ارزیابی حقوقی (Due Diligence) باشد.

۶. درس‌هایی برای ایران

به نظر من این بحث برای اکوسیستم استارتاپی ما فوری‌تر از آن است که در نگاه اول به نظر می‌رسد. نخست، ما قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای مصوب ۱۳۷۹ را داریم؛ اما تا جایی که بنده اطلاع دارم، این قانون و رویه قضایی ما هنوز تکلیف نرم‌افزاری را که بدون مشارکت خلاقانه انسان تولید شده، به‌صراحت روشن نکرده‌اند و این خلأ، دیر یا زود در یک دعوای واقعی خودش را نشان خواهد داد. دوم، بنیان‌گذاران استارتاپ از همین امروز باید تاریخچه دستورها، تغییرات و بازبینی‌های کد را نگه دارند؛ این مستندات هم دلیل اثبات سهم انسانی است و هم سپر دفاعی در برابر ادعای نقض. سوم، وکلای شرکت‌ها باید در قراردادهای برون‌سپاری توسعه نرم‌افزار، بندی صریح درباره استفاده از هوش مصنوعی، افشای آن و تخصیص ریسک بگنجانند؛ قراردادی که در این باره ساکت است، اختلاف آینده را پیش‌خرید کرده است. چهارم، سرمایه‌گذاران و صندوق‌های جسورانه در ارزیابی حقوقی پیش از سرمایه‌گذاری بپرسند چه بخشی از کد محصول با هوش مصنوعی تولید شده و آیا بررسی مجوزهای متن‌باز انجام شده است. پنجم، دادگاه‌ها و کارشناسان رسمی در دعاوی نرم‌افزاری باید آماده شوند که «منشأ کد» را به‌عنوان پرسشی مستقل بررسی کنند. و ششم، تا جایی که بنده اطلاع دارم، لایحه حمایت از داده‌های شخصی هنوز به قانون تبدیل نشده است؛ اما حتی بدون آن، وارد کردن داده واقعی مشتریان به ابزارهای رایگان هوش مصنوعی به نظر من با احتیاط حرفه‌ای و تعهد به حفظ اسرار مشتری سازگار نیست. واقعیت این است که هوش مصنوعی می‌تواند کد بنویسد، اما نمی‌تواند به جای ما پاسخ‌گو باشد!

منابع: Heuking، ۱۲ اکتبر ۲۰۲۶؛ Bloomberg Law (Steptoe)، ۲۹ آوریل ۲۰۲۶؛ FOSS Force، ۷ اوت ۲۰۲۶. تصویر: Wikimedia Commons.jpg)، Markus Spiske، مجوز CC0.

این یادداشت جنبه آموزشی دارد و جایگزین مشاوره حقوقی در پرونده‌های مشخص نیست.