این دوشنبه صبح را تصور کنید: شرکت کوچک نرمافزاری که سیستم پشتیبان صورتحسابها، انبار یا سوابق مشتریان شما را میچرخاند، یکشبه درهایش را بسته است. خط پشتیبانی قطع شده، فاکتور تمدید هرگز نخواهد آمد و یک باگ بحرانی که هفته گذشته گزارش دادهاید هرگز رفع نخواهد شد. سالها برای نرمافزار پول دادهاید — اما هرگز مالک کد منبع نبودهاید، بنابراین نمیتوانید آن را اصلاح کنید، منتقل کنید یا حتی روی سرور جدیدی اجرا نگه دارید. همان شکاف میان پرداخت برای نرمافزار و کنترل آن، دقیقاً چیزی است که یک قرارداد اسکرو نرمافزار پر میکند.
قرارداد اسکرو نرمافزار در واقع چیست
قرارداد اسکرو نرمافزار یک قرارداد سهجانبه میان شما (دارنده مجوز یا ذینفع)، فروشنده نرمافزار (واریزکننده) و طرف ثالث بیطرفی به نام نماینده اسکرو است. فروشنده نسخهای از کد منبع و مواد مرتبط خود را نزد نماینده به امانت میگذارد که آنها را بهصورت امن نگهداری میکند و تنها در صورت وقوع یکی از محرکهای آزادسازی مشخصشده در قرارداد آنها را به شما تحویل میدهد — معمولاً ورشکستگی فروشنده، ناتوانی آن در پشتیبانی از محصول، یا نقض تعریفشده دیگری.
این ترتیب همزمان از هر دو طرف محافظت میکند. فروشنده در عملیات عادی مالکیت کامل مالکیت فکری خود را حفظ میکند؛ هیچ چیزی به اشتراک گذاشته نمیشود و توسعه طبق معمول ادامه مییابد. شما یک پشتوانه تداوم به دست میآورید: اگر فروشنده دیگر نتواند نرمافزار را زنده نگه دارد، مواد لازم برای نگهداری آن را خودتان یا سپردن آن به توسعهدهنده دیگری دریافت میکنید.
چند چیز که اسکرو نیست، چون هر سوءبرداشت از آنها خریداران واقعی را سوزانده است:
- این انتقال مالکیت نیست. حداکثر مجوزی مشروط برای استفاده از مواد آزادشده بهمنظور پشتیبانی از عملیات خودتان دریافت میکنید — نه حق فروش مجدد محصول یا ادعای مالکیت فکری.
- این خودکار نیست. تا زمانی که سه طرف قراردادی امضا نکنند، فروشنده واقعاً موادی واریز نکند و واریزها بهروز نمانند، اسکروی وجود ندارد. بندی در مجوز شما که میگوید «فروشنده باید اسکرو منعقد کند» بدون پیگیری عملی، هیچ چیزی را محافظت نمیکند.
- این جایگزین حقوق داده نیست. کد بدون دادههای شما پوسته خالی است. اسکرو مواد فروشنده را پوشش میدهد؛ حق شما برای صادرات دادههای خودتان در قالبی قابل استفاده باید در خود مجوز یا قرارداد SaaS باشد.
چه چیزی در واریز گنجانده میشود
واریز شامل هر چیزی است که یک توسعهدهنده کارآمد برای بازسازی، نصب و نگهداری نرمافزار بدون کمک فروشنده نیاز دارد. کد منبع بهتنهایی بهندرت کافی است. یک واریز کامل معمولاً شامل کد منبع نسخه تولیدی جاری، اسکریپتهای ساخت و دستورالعملهای کامپایل، کتابخانههای شخص ثالث و فهرست وابستگیها، طرحوارههای پایگاه داده و اسکریپتهای مهاجرت، فایلهای پیکربندی، مجموعههای تست، مستندات سیستم و توصیف محیط توسعه شامل نسخههای کامپایلر و جزئیات زنجیره ابزار است.
بهاندازه محتوا، آهنگ بهروزرسانی هم مهم است. نرمافزار مدام تغییر میکند و واریزی از دو سال پیش ممکن است با نسخهای که امروز اجرا میکنید مطابقت نداشته باشد. قراردادهای قوی فروشنده را ملزم میکنند که هر نسخه جدید — یا حداقل هر نسخه اصلی و فرعی — را در بازه زمانی مشخصی مانند ۳۰ روز پس از عرضه عمومی واریز کند. برخی نمایندگان اسکرو از واریزهای خودکار همگامشده با مخزن فروشنده پشتیبانی میکنند که حالت شکست «فراموش کردیم اسکرو را بهروز کنیم» را کاملاً حذف میکند. هنگام مذاکره بپرسید واریزها چگونه تحویل داده میشوند و چه کسی دریافت را تأیید میکند؛ «فروشنده قول میدهد بهروزرسانیها را بفرستد» بدون مرحله تأیید، حلقهای ضعیف است که ارزش اصلاح پیش از امضا را دارد.
محرکهای آزادسازی: بندی که همهچیز را تعیین میکند
شرایط آزادسازی قلب قرارداد است: رویدادهای مشخصی که باعث میشوند نماینده مواد را به شما تحویل دهد. اگر فهرست محرکها بیش از حد محدود باشد، اسکرو درست در همان بحرانی که برایش هزینه دادهاید بیکار میماند. محرکهایی که خریداران بیشتر مذاکره میکنند عبارتند از:
- ورشکستگی یا اعسار فروشنده، شامل واگذاری به نفع طلبکاران.
- توقف کسبوکار، چه از طریق تعطیلی، انحلال یا توقف پایدار عملیات.
- ناتوانی در پشتیبانی یا نگهداری نرمافزار برای دوره مشخصی، مانند ۳۰ یا ۶۰ روز پس از اخطار کتبی.
- نقض اساسی قرارداد مجوز یا نگهداری که فروشنده در دوره رفع نقص آن را جبران نکند.
- توقف خط محصولی که به آن وابستهاید، حتی اگر خود فروشنده باقی بماند.
- تغییر کنترل، مانند خرید توسط یک رقیب مستقیم — فروشندگان اغلب با این یکی مقاومت میکنند چون ادغام و تملک خودشان را پیچیده میکند، پس انتظار مذاکره داشته باشید.
دو نکته در نگارش بیش از انتظار خریداران اهمیت دارد. اول، محرکها باید بهطور عینی قابل اثبات باشند — «ناتوانی در ارائه پشتیبانی به مدت ۴۵ روز پس از اخطار» قابل اثبات است، در حالی که «از دست رفتن اعتماد به بقاپذیری فروشنده» دعوایی را دعوت میکند که نماینده در وسط آن گیر میافتد. دوم، محرکهای مرتبط با ورشکستگی نیازمند دقت هستند: مقرراتی که صرفاً به دلیل ثبت دادخواست ورشکستگی فعال میشوند ممکن است در دادگاه ورشکستگی با پرسشهای قابلیت اجرا مواجه شوند. بنابراین وکلای باتجربه حداقل برخی محرکها را به شکستهای عملکردی مشخص گره میزنند — رد مجوز، عدم پشتیبانی پایدار، نقض جبراننشده — که از بررسیها جان سالم به در میبرند چون توصیف میکنند فروشنده چه کاری را متوقف کرده، نه اینکه در کدام دادگاه پرونده ثبت کرده است.
مکانیزم آزادسازی را هم تأیید کنید: چگونه به نماینده اطلاع میدهید، فروشنده چقدر فرصت اعتراض دارد و در طول پنجره اعتراض چه اتفاقی میافتد. چرخه اخطار و اعتراض ۱۰ تا ۱۵ روزه معمول است و قرارداد باید تصریح کند که اعتراضهای بیهوده آزادسازی را بهطور نامحدود منجمد نمیکنند.
تأیید: اثبات اینکه واریز واقعاً بازسازی میشود
واریز اسکروی که هرگز آزمایش نکردهاید یک وعده است، نه تضمین. تأیید همان خدمتی است — معمولاً توسط نماینده اسکرو یا یک حسابرس فنی انجام میشود — که بررسی میکند آیا مواد واریزشده در صورت آزادسازی واقعاً کار میکنند. عموماً سه سطح دارد:
- سطح ۱: فهرست و کامل بودن. نماینده وجود واریز را تأیید میکند، محتویات آن را فهرست میکند و بررسی میکند که دستههای وعدهدادهشده مواد موجود و قابل خواندن باشند. این سطح واریزهای خالی یا ناقص را میگیرد اما درباره کامپایل شدن کد چیزی نمیگوید.
- سطح ۲: تأیید ساخت. حسابرس کد منبع واریزشده را در محیطی تمیز کامپایل میکند و تأیید میکند که نرمافزار کارآمدی تولید میکند. این سطح وابستگیهای مفقود، اسکریپتهای ساخت خراب و الزامات مستندنشده زنجیره ابزار را میگیرد.
- سطح ۳: آزمون کامل عملکرد. واریز ساخته، مستقر و با محصول زنده مقایسه میشود — گاهی مقایسه باینری یا آزمون کامل قابلیت استفاده نامیده میشود — تا تأیید شود مواد آزادشده همان نرمافزاری را بازتولید میکنند که واقعاً استفاده میکنید.
هر سطح از سطح قبلی گرانتر است، پس سطح را با میزان ریسک تطبیق دهید. برای نرمافزاری که شکست آن صورتحساب یا عملیات شما را متوقف میکند، تأیید سطح ۲ حداقل سالانه کف معقول است؛ سطح ۱ بهتنهایی پرسش اصلی — آیا این ساخته میشود؟ — را بیپاسخ میگذارد. هر سطحی که انتخاب میکنید، تأیید را بهعنوان رویدادی تکرارشونده و متصل به نسخههای اصلی زمانبندی کنید، نه یک تیک یکباره در زمان امضا. شایعترین شکست اسکرو فروشنده حیلهگر نیست، بلکه واریز کهنه و تأییدنشدهای است که سه سال کسی به آن نگاه نکرده.
هزینه آن چقدر است و چه کسی میپردازد
قیمتگذاری به دو بازار تقسیم شده است. نمایندگان اسکرو سنتی معمولاً یک هزینه راهاندازی یکباره بهعلاوه هزینه سالانه به ازای هر قرارداد دریافت میکنند: نقاط شروع منتشرشده حدود ۹۹۵ دلار برای راهاندازی و ۱٬۵۹۵ دلار در سال برای قرارداد تکذینفع است، با خدمات تأیید و ساختارهای چندذینفع بهصورت اضافه. پلتفرمهای اسکرو خودخدمت که هدفشان شرکتهای کوچکتر است، قیمت اشتراک از حدود ۱۳۹ دلار در ماه برای اسکرو نرمافزار و حدود ۱۹۹ دلار در ماه برای اسکرو SaaS را فهرست میکنند، با واریزهای خودکار و تأیید سطحبندیشده بهعنوان افزونه. قراردادهای سازمانی با واریزهای مکرر و تأیید ساخت کامل میتوانند سالانه به پنجرقمی برسند.
اینکه چه کسی میپردازد قابل مذاکره است و معمولاً از اهرم قدرت پیروی میکند. فروشندگان اغلب وقتی میپردازند که اسکرو روش استاندارد فروش سازمانیشان باشد — بهویژه تحت یک قرارداد چندذینفع که بسیاری از مشتریان را با هزینه سرانه کم پوشش میدهد. خریداران اغلب وقتی میپردازند که خودشان از فروشندهای که بهطور معمول اسکرو ارائه نمیدهد آن را مطالبه میکنند. در هر صورت، یک پشتوانه پرداخت در قرارداد بگنجانید: شایعترین دلیل فروپاشی خاموش ترتیبات اسکرو این است که کسی پرداخت هزینه سالانه نماینده را متوقف میکند. قراردادهای سهجانبه معمولاً به ذینفع حق جبران پرداخت ازدسترفته و کسر آن از سایر مبالغ بدهی را میدهند، که محافظت را دقیقاً در همان پریشانی فروشنده که برایش وجود دارد زنده نگه میدارد.
اسکرو SaaS: خریداران ابری در عوض چه چیزی میگیرند
اسکرو سنتی برای نرمافزاری ساخته شد که خودتان نصب و اجرا میکنید. برای نرمافزار ابری، انبوهی از کد منبع بدون زیرساخت، پایگاههای داده، خطوط لوله استقرار و دانش عملیاتی فروشنده ممکن است تقریباً بیفایده باشد — نمیتوانید یک محصول SaaS چندمنطقهای را روی لپتاپ «کامپایل و اجرا» کنید. به همین دلیل اسکرو SaaS به دسته محصولی خودش با واریزهای گستردهتر تبدیل شده است.
واریز اسکرو SaaS معمولاً بسیار فراتر از کد میرود: تصاویر کانتینر یا بستههای استقرار، قالبهای زیرساخت بهعنوان کد، طرحوارههای پایگاه داده بهعلاوه رویههای پشتیبانگیری و بازیابی، فهرست پیکربندی و اسرار با رویههای تحویل مستند، دستورالعملهای عملیاتی استقرار و وابستگیهای خدمات شخص ثالث. تأیید بر همین اساس تغییر میکند، از «آیا کامپایل میشود» به «آیا سرویس قابل بازسازی است» — برخی ارائهدهندگان واقعاً بازیابی آزمایشی برنامه را در محیطی ایزوله تست میکنند.
در بالای بازار، اسکرو تداوم قرار دارد که در آن نماینده یک محیط بازیابی نگهداری میکند تا سرویس مشتری پس از یک رویداد آزادسازی برای دورهای مشخص، معمولاً تا ۹۰ روز، در حالی که مشتری مهاجرت میکند، به کار خود ادامه دهد. و صرفنظر از سطح، هر اسکرو SaaS را با حقوق داده قوی در قرارداد زیربنایی جفت کنید: صادراتهای زمانبندیشده که خودتان کنترل میکنید، قالبی مستند و پنجره دسترسی پس از خاتمه. اسکرو از برنامه محافظت میکند؛ تنها پشتیبانها و حقوق صادرات خودتان دادههایتان را با اطمینان محافظت میکنند.
پشتوانه ورشکستگی که باید بشناسید
قانون ورشکستگی ایالات متحده حفاظت مشخصی به دارندگان مجوز نرمافزار میدهد که ارزش دانستن در سطح کلی را دارد. تحت ماده 365(n) قانون ورشکستگی، اگر فروشنده شما دادخواست ورشکستگی دهد و متولی آن قرارداد مجوز شما را رد کند، میتوانید انتخاب کنید حقوق قراردادی خود نسبت به مالکیت فکری را برای باقیمانده مدت مجوز حفظ کنید، بهجای آنکه رد را پایان معامله تلقی کنید. دادگاهها قراردادهای اسکرو را بهعنوان قراردادهای تکمیلی مشمول این انتخاب تلقی کردهاند، که دلیل دیگری برای ارجاع صریح قرارداد اسکرو به مجوز شماست.
محدودیتهای عملی را در نظر داشته باشید. ماده 365(n) حق شما برای استفاده از آنچه دارید را حفظ میکند؛ فروشنده ورشکسته را ملزم نمیکند به پشتیبانی، ارسال بهروزرسانی یا پاسخ دادن به تلفن ادامه دهد. قانون از مجوز محافظت میکند، اما تنها یک واریز اسکرو جاری و تأییدشده مواد واقعی را به دست شما میرساند. قانون را مجوز حقوقی و واریز اسکرو را چیزی که به شما اجازه استفاده از آن را میدهد در نظر بگیرید — به هر دو نیاز دارید و هیچکدام بدون دیگری کار نمیکند.
چگونه هزینههای اسکرو را در دفتر کل خود ثبت کنید
هزینههای اسکرو هزینههای عادی کسبوکار هستند، اما زمانبندی آنها نیازمند کمی دقت حسابداری است. هزینههای راهاندازی و تأیید مرتبط با یک قرارداد مشخص معمولاً در زمان تحقق هزینه میشوند. هزینههای سالانه اسکرو که دوازده ماه پوشش میخرند یک هزینه پیشپرداخت کلاسیک هستند: پرداخت کل سال از پیش و هزینهکردن یک ماه در هر بار، صورت سود و زیان هر ماه را صادق نگه میدارد بهجای آنکه کل صورتحساب را روی ژانویه بار کند.
اگر دفاتر خود را بهصورت متن ساده نگه میدارید، الگو اینگونه است:
2026-01-15 * "EscrowTech" "Source-code escrow annual fee - ERP vendor"
Assets:Prepaid:Escrow-Fees 1,595.00 USD
Assets:Checking
2026-01-31 * "Amortize January escrow coverage"
Expenses:Professional-Services:Legal 132.92 USD
Assets:Prepaid:Escrow-Feesثبت استهلاک ماهانه را تکرار کنید — یا آن را با یک تراکنش زمانبندیشده خودکار کنید — و موجودی پیشپرداخت دقیقاً زمانی به صفر میرسد که اخطار تمدید میآید، که همزمان یادآوری است برای تأیید بهروز بودن واریزهای فروشنده پیش از پرداخت یک سال دیگر. اگر هزینههای اسکرو در قرارداد نرمافزاری بزرگتری گنجانده شدهاند و جداگانه صورتحساب نمیشوند، آنها را در حساب خودشان تفکیک کنید تا ببینید حفاظت تداوم واقعاً چه هزینهای دارد وقتی مذاکرات تمدید فرا میرسد. ثبتهای خط مستقیم ماهانه تمام چیزی است که بیشتر کسبوکارهای کوچک در اینجا نیاز دارند؛ مستندات Beancount الگوهای ثبت پیشرفتهتری را برای افراد فنیتر پوشش میدهد.
اشتباهات رایجی که محافظت را از بین میبرند
بیشتر اسکروهای شکستخورده به روشهای کسلکننده و قابل پیشگیری شکست میخورند. پیش از امضا و سالی یک بار پس از آن این فهرست را مرور کنید:
- هرگز تأیید نکردن واریز. اسکروی آزمایشنشده گرانترین نوع آرامش کاذب است. برای حداقل تأیید در سطح ساخت روی نرمافزار حیاتی کسبوکار بودجه بگذارید.
- گذاشتن واریزها به حال خود تا کهنه شوند. تعهدات واریز را با شمارش روز به نسخهها گره بزنید، از نماینده تأیید دریافت را بخواهید و یک بررسی فصلی در تقویم بگذارید که نسخه واریز با نسخه تولیدی شما مطابقت دارد.
- پذیرفتن محرکهایی که هرگز فعال نمیشوند. «ورشکستگی فروشنده» بهتنهایی زوال آهسته را از دست میدهد: پشتیبانیای که تحلیل میرود، خط محصولی که بیصدا رها میشود، تملکی که پس از آن قرارداد شما فقط به اسم محترم است. بر محرکهای ناتوانی در پشتیبانی و توقف محصول با دورههای رفع نقص مشخص پافشاری کنید.
- نبود حق جبران در هزینهها. اگر فقط فروشنده میتواند به نماینده بپردازد و فروشنده در حال شکست است، اسکرو دقیقاً وقتی بیشترین نیاز را دارید منقضی میشود. حق پرداخت و کسر ذینفع را حفظ کنید.
- تلقی اسکرو بهعنوان کل برنامه خروج. اسکرو مواد را به دست شما میدهد، نه مهاجرت را. صادرات داده خودتان را حفظ کنید، یکپارچهسازیهایتان را مستند کنید و بدانید — پیش از بحران — چه کسی واقعاً سیستم را از یک نسخه آزادشده بازسازی و اجرا خواهد کرد.
آیا واقعاً به اسکرو نیاز دارید؟
هر رابطه با فروشنده هزینه و مذاکره را توجیه نمیکند. اسکرو ارزش خود را زمانی اثبات میکند که نرمافزار حیاتی کسبوکار باشد، فروشنده کوچک یا از نظر مالی مبهم باشد، هزینههای جابهجایی بالا باشد، یا یک ناظر یا مشتری سازمانی عملاً آن را از شما بخواهد. SaaS کالاییشده با رقابت سالم، صادرات داده یککلیکی و شرایط ماهبهماه بهندرت به آن نیاز دارد — اهرم شما در آنجا توانایی ترک کردن است و برنامه خروج یک دستورالعمل مهاجرت است نه یک واریز.
وقتی واقعاً نیاز دارید، با یک فهرست کوتاه به مذاکره بروید: تعریف کامل واریز با مواد نامبردهشده، واریز در هر نسخه ظرف ۳۰ روز، محرکهای ناتوانی در پشتیبانی و توقف محصول در کنار ورشکستگی، حق شما برای جبران هزینههای پرداختنشده نماینده، تأیید در سطح ساخت حداقل سالانه، و — برای SaaS — مواد زیرساخت بهعلاوه بازیابی آزمایششده. این شش شرط را درست بگیرید و قرارداد همان کاری را میکند که خریداران فرض میکنند هر اسکرو از قبل انجام میدهد. آخرین قدم سادهترین است: پس از امضای قرارداد، پیش از بستن پرونده، اولین تأیید و اولین بررسی تأیید واریز را در تقویم بگذارید، چون اسکرویی که کسی از آن مراقبت نمیکند فقط یک هزینه ثبت با کاغذبازی است.
