'हमें Oracle को हमारे अनुबंध के बारे में शिक्षित करना पड़ा,' CIO ने Big Red audit के बाद कहा

मूल लेख ↗ Hacker News चर्चा ↗

Oracle की आक्रामक लाइसेंसिंग और ऑडिट प्रथाएँ कई संगठनों को उसकी databases, Java, और अन्य products पर अपनी निर्भरता पर फिर से सोचने के लिए प्रेरित कर रही हैं। टिप्पणीकार ऐसे audits का वर्णन करते हैं जो revenue-maximizing “shakedowns” जैसे लगते हैं, proprietary features के जरिए गहरा vendor lock-in, और अनुपालन से निपटने में मदद करने वाले ex-Oracle consultants का एक द्वितीयक उद्योग भी। जबकि core technology की अक्सर प्रशंसा की जाती है, अधिकांश लोग तर्क देते हैं कि अब legal risk, cost, और inflexibility लाभों से अधिक हो गए हैं, जिसके कारण कई लोग PostgreSQL, SQL Server, और अन्य open-source या कम litigiously prone विकल्पों को पसंद कर रहे हैं.

Oracle लाइसेंसिंग, ऑडिट, और अनुपालन पारिस्थितिकी तंत्र

  • कई टिप्पणीकार Oracle की डिफ़ॉल्ट स्थिति को “आप अनुपालन में नहीं हैं” के रूप में बताते हैं, और ऑडिट्स को राजस्व उपकरण की तरह इस्तेमाल किया जाता है।
  • ऑडिट्स को आक्रामक बताया गया है, जो कभी-कभी पूर्व-कर्मचारियों या डाउनलोड टेलीमेट्री (जैसे Java, VirtualBox) से ट्रिगर होते हैं।
  • Oracle लाइसेंस अनुपालन के आसपास एक परामर्श पारिस्थितिकी तंत्र मौजूद है, जिसमें अक्सर ex-Oracle लोग होते हैं; कुछ इसे एक “racket” मानते हैं।
  • कुछ कंपनियों ने बातचीत की या यहाँ तक कि रिफंड भी प्राप्त किया; अन्य को छह-अंकीय बैक बिलों का सामना करना पड़ा और, कम-से-कम एक मामले में, उसके तुरंत बाद उनका व्यवसाय बंद हो गया।

Java और अन्य Oracle उत्पाद

  • हाल के Java SE सब्सक्रिप्शन बदलावों (प्रति-कर्मचारी लाइसेंसिंग) ने कुछ संगठनों को Oracle Java से हटने के लिए प्रेरित किया।
  • सहमति: non-Oracle JDKs (OpenJDK builds, Corretto, Azul, distro builds) का उपयोग करने से लाइसेंसिंग के बहुत से झंझटों से बचा जा सकता है, हालांकि support और LTS नीतियाँ अलग-अलग होती हैं।
  • VirtualBox Extension Pack लाइसेंसिंग की Oracle की policing ने कुछ लोगों को चिंतित किया; अन्य लोग ध्यान दिलाते हैं कि Docker भी इसी तरह license enforcement करता है।

Vendor lock‑in और migration की कठिनाई

  • Oracle DB का गहरा उपयोग (proprietary SQL, PL/SQL, stored procedures, triggers, ERP suites जैसे EBS) switching costs को बहुत ऊँचा बना देता है।
  • Oracle से PostgreSQL, DynamoDB, या अन्य systems पर multi-year migrations की कई कहानियाँ हैं (बड़े cloud providers सहित)।
  • टिप्पणीकार जोर देते हैं कि DB बदलने में व्यापक query और procedure rewrites, schema tweaks, और छिपे हुए edge cases (जैसे empty-string semantics) शामिल होते हैं।
  • कुछ का तर्क है कि migration “असंभव नहीं” है और वे MySQL/MariaDB/Postgres पर सफल moves साझा करते हैं; अन्य 30–40 साल पुराने, mission-critical systems के लिए जोखिम और लागत पर ज़ोर देते हैं।

Oracle बनाम alternatives पर तकनीकी विचार

  • तकनीकी रूप से, Oracle DB को अक्सर शक्तिशाली, परिपक्व, और transactions, rollbacks, तथा analytics में मज़बूत बताया जाता है।
  • कई लोग कहते हैं कि PostgreSQL अब नए projects के लिए “good enough” है या पसंदीदा है; अन्य scale या niche use cases के लिए MS SQL Server, MariaDB, और specialized modern systems का उल्लेख करते हैं।
  • कुछ लोग कहते हैं कि Oracle की मुख्य समस्या technology नहीं बल्कि legal और cost risk है।

संगठन अभी भी Oracle (या SAP, आदि) क्यों चुनते हैं

  • enterprise और government खरीदार developer sentiment से ज़्यादा “a vendor to call” और risk transfer को महत्व देते हैं।
  • निर्णय अक्सर non-technical executives या accounting/ERP functions द्वारा लिए जाते हैं, और कभी-कभी aggressive sales तथा perks का प्रभाव होता है।
  • कई लोग Oracle और इसी तरह के vendors को inertia, जमे हुए staff skills, और विशाल legacy systems को फिर से लिखने के डर से टिके हुए मानते हैं।