شرکت کامپک کامپیوتر^[۱۰۰]، توانست در نهایت یک BIOS سازگار تولید و در سال ۱۹۸۵ روانه‏ی بازار کند. شرکت کامپک به منظور جلوگیری از طرح دعوی نقض حق مؤلف توسط شرکت IBM، پیش از شروع به مهندسی و طراحی کامپیوتر خانگی خود، از مهندسین خود خواست تا سودگندنامه‏ای را امضا کنند که به موجب آن هرگز کد مبدأ BIOS متعلق به شرکت BIOS را ندیده‏اند.

شرکت فنیکس^[۱۰۱] نیز متعاقبا همین اقدام را به شیوه‏ای مشابه، تکرار کرد اما به جای تولید سیستم مشابه سیستم IBM، تراشه BIOS سازگار را به بقیه‏ی تولیدکنندگان کامپیوتر خانگی فروخت. بدین ترتیب زمینه‏ ورود شرکت‏های کوچکتر ‌به این بازار نیز فراهم شد.

چنان که می‏‏بینیم نتیجه‏ نهایی مهندسی معکوس کد BIOS متعلق به شرکت IBM و عرضه‏ی سیستم‏های مشابه، هموار شدن زمینه‏ ورود سایرین به بازار بود که در نهایت منجر به استاندارد شدن یک پلت‏فرم (سخت افزار اصلی) واحد در صنعت کامپیوتر خانگی شد. در نتیجه تولیدکنندگان نرم افزار هم توانستند بر توسعه‏ نرم‏افزارهای خود تمرکز کنند بدون آنکه نگران سازگاری آن ها با پلت‏فرم باشند. ^[۱۰۲]

این پرونده‏ها و نمونه ‏های مشابه نشان می ‏دهند که در حوزه‏ محصولات اطلاعات محور نظیر نرم‏افزارها، مهندسی معکوس غالبا با اهدافی متفاوت از حوزه‏ صنایع تولیدی سنتی صورت می‏ گیرد. در صنایع تولیدی سنتی، مهندسی معکوس عمدتاً در صورتی که به‏منظور تولید محصول رقیب باشد، چه به لحاظ اقتصادی و چه به لحاظ حقوقی چالش‏برانگیز است. مهندسی معکوس نرم‏افزارها بسیار دشوار و زمان‏بر است به نحوی که راه کارآمدی برای تولید برنامه‏ی رقیب نیست.^[۱۰۳] مهندسی معکوس نرم‏افزار مستلزم تلاش فکری فراوانی به‏منظور استخراج اطلاعات و امور انتزاعی از متن برنامه های کامپیوتری است، مضافا اینکه برای پدیدآوردن نرم‏افزار رقیب نیز لازم است اقدامات و تلاش‏هایی به‏منظور به‏کابردن اطلاعات کسب‏شده صورت پذیرد. ‌بنابرین‏ از این جهت نرم افزارها شبیه محصولات تولیدی سنتی بوده و مهندسی معکوس آن‏ها هزینه های زیاد و سایر دشواری‏ها را دارد، به نحوی که پدیدآورندگان اولیه را دربرابر مهندسی معکوس مخرب بازار حفظ می ‏کند.

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

دلایل مهندسی معکوس در حوزه‏ نرم‏افزارها را می‏توان چنین برشمرد: رفع و تعمیر باگ‏ها، مطابق کردن برنامه با نیاز کاربران (به عنوان مثال با افزودن برخی ویژگی‏ها)، یافتن موارد نقض (یا استفاده غیرمجاز از نرم‏افزار) و یادگیری وآموزش. به لحاظ اقتصادی مهمترین دلیل مهندسی معکوس در حوزه‏ نرم‏افزارها دستیابی به سازگاری (برهم‏عمل‏پذیری) بین دو یا چند نرم‏افزار یا برنامه‏ی‏ کامپیوتری است و اکثر دعاوی مرتبط با نرم‏افزارها ‌به این موضوع اختصاص دارد.^[۱۰۴]

به منظور ورود به بحث لازم است توضیح داده شود که بحث سازگاری در جایی مطرح می‏ شود که سیستم موردنظر، از دو قسمت عمده تشکیل شده باشد: ۱- پلت‏فرم^[۱۰۵] (مثل کنسول بازی جنسیس شرکت سگا) و ۲- برنامه یا برنامه ها^[۱۰۶] که بر روی پلت‏فرم اجرا می ‏شوند. برای اینکه این دو قسمت بتوانند با یکدیگر هماهنگ کار کنند باید برهم‏عمل‏پذیری (سازگاری) داشته باشند. از آنجا که ابتدا پلت‏فرم‏ها ساخته می ‏شوند، پدیدآورنده‏ی برنامه باید اطلاعات دقیق و جزیی از نحوه‏ کار پلت‏فرم (اینکه چگونه اطلاعات را دریافت و انتقال می‏ دهد) داشته باشد. از آنجا که رابطه‏ بین پلت‏فرم‏ها و برنامه ها را «واسط‏های برنامه‏سازی کاربردی»^[۱۰۷] که خود «برنامه» محسوب می ‏شوند، برقرار می‏ کنند، اطلاعات دقیق ‌در مورد آن ها نیز ضروری است. این واسط‏ها اکثرا توسط تولیدکنندگان پلت‏فرم‏ها، توسعه می‏یابند.