- Red Hat की RHEL source उपलब्ध कराने की शर्तों में बदलाव को Unix, GNU, Linux और IBM के लंबे इतिहास के संदर्भ में देखना चाहिए, और IBM/Red Hat का रुख है कि वे GPL के “binary प्राप्त करने वालों को source उपलब्ध कराना” वाले सिद्धांत का पालन कर रहे हैं
- शुरुआती software को researchers और users अपनी ज़रूरत के मुताबिक बनाते और share करते थे, लेकिन 1980 के दशक के बाद copyright और license मजबूत हुए और EULA, source code contract, permissive license और GPL अलग-अलग रास्तों पर चले गए
- GNU और Linux open source और community contributions से बढ़े, और IBM ने Linux में 1 अरब डॉलर के निवेश की घोषणा के बाद developers को नियुक्त कर और SCO lawsuit का सामना कर ecosystem में भरोसा बढ़ाया
- RHEL, Fedora को experimental base के रूप में इस्तेमाल करने वाला enterprise server product है, और Red Hat support, QA, documentation, release engineering और global support system पर आने वाली लागत को customer licenses से वसूल करना चाहता है
- RHEL clone users दूसरी Linux distributions चुन सकते हैं, लेकिन clone बनाने वालों के लिए simple copying के बजाय RHEL से competition करने वाली distribution बनाना ज्यादा productive होगा
Red Hat बदलाव को देखने का बुनियादी रुख
- Red Hat की हाल की sales terms में बदलाव ने विवाद पैदा किया है, लेकिन मूल बात यह है कि RHEL binaries पाने वाले customers को source उपलब्ध कराया जाता है
- GPL का सार यह है कि binary recipients bugs ठीक कर सकें और operating system को extend कर सकें, इसके लिए source और modify करने की क्षमता की guarantee दी जाए
- IBM/Red Hat अपने contract customers को source code और distribution build के लिए जरूरी जानकारी उपलब्ध कराते हैं, और GPL code में किए गए बदलाव भी लगातार upstream भेजते हैं—ऐसा माना जाता है
- “community” शब्द भर से सभी हितों को एक साथ समझना मुश्किल है, और जिन्हें उसी स्तर की engineering और support की जरूरत नहीं है, वे दूसरी Linux distributions चुन सकते हैं
Software sharing से licensing के दौर तक
- 1969 के आसपास programming मुख्यतः researchers, professors और engineers अपने काम के लिए करते थे, और “professional programmer” नाम का पेशा आम नहीं था
- DECUS जैसी user groups customers द्वारा लिखे गए software को copy cost के स्तर पर distribute करती थीं, और कई users code को Public Domain में release करते थे
- उस समय software copyright या patent का लागू होना सीमित था, इसलिए code को protect करने के लिए trade secrets, contract law और binary distribution पर निर्भर रहना पड़ता था
- 1980 के दशक की शुरुआत में binaries और source code पर मजबूत copyright doctrine लागू होने लगा, तो developers को users को अधिकार समझाने के लिए licenses की जरूरत पड़ी
- end users के लिए EULA सामने आया
- developers के लिए source code contracts अलग से लागू हुए
Unix, BSD और GNU ने जो नींव बनाई
- Unix 1969 में Bell Labs में शुरू हुआ और बाद में UC Berkeley, MIT, Stanford और CMU जैसी research universities में फैल गया
- UC Berkeley का BSD Unix demand-paged virtual memory, native TCP/IP और भरपूर utilities देता था, और कई शुरुआती Unix vendors का आधार बना
- SunOS, Ultrix और HP/UX जैसे products ने BSD base अपनाया
- John Lions की Unix Version 6 commentary लंबे समय तक formally publish होने से रोकी गई, लेकिन copies के जरिए इसने अनगिनत Unix programmers को kernel structure और design thinking सिखाई
- AT&T का Unix source license महंगा और restrictive था, इसलिए कुछ companies ने binary-only Unix-like systems बेचने के लिए redistribution contract चुना
- Richard M. Stallman ने binary-only Unix distribution देखने के बाद, users जरूरी modifications नहीं कर सकते—इस problem awareness से GNU project शुरू किया
- GNU का उद्देश्य ऐसा free operating system बनाना था जिसमें binary distribute करने वाला व्यक्ति recipient को source और modify करने की क्षमता की guarantee दे
- emacs, compiler suite और utilities जैसे programmers के लिए सीधे उपयोगी software पहले बनाए गए
Permissive licenses और GPL का अंतर
- MIT और UC Berkeley जैसी universities research code बेचने के बजाय distribute करना चाहती थीं, लेकिन copyright लागू होने के बाद usage terms और liability limitation वाली license की जरूरत पड़ी
- ऐसी licenses को बाद में open source की permissive licenses कहा गया
- developers binary-only distributions बना सकते हैं
- मूल रूप से मिले source के अलावा किए गए बदलावों को end users के सामने खोलना जरूरी नहीं है
- GPL को ऐसी restrictive license के रूप में समझा गया जो binary पाने वाले end users को बदलाव देखने की ability enforce करती है
- GPL को लेकर शुरुआत में कई misunderstandings थीं
- कुछ लोग सोचते थे कि GNU compiler से बने binaries पर भी GPL लागू होता है
- कुछ लोग सोचते थे कि GPL code बेचा नहीं जा सकता, लेकिन RMS ने इसका खंडन किया
- Walnut Creek और Prime Time Freeware for Unix जैसी companies कई open source code को CD-ROM और DVD में bundle करके बेचती थीं
Unix market का दबाव और Linux का उदय
- DEC, HP, Sun और IBM जैसी system companies ने AT&T System V या BSD family पर आधारित Unix-like operating systems बनाए, और इसके लिए engineers, documentation writers, QA staff और product managers को hire किया
- प्रतिस्पर्धी Unix-like system बनाने के लिए हर company लगभग 1 अरब से 2 अरब डॉलर सालाना खर्च करती थी—ऐसा माना जाता है
- Microsoft ने PC manufacturers से स्वतंत्र होकर वही operating system बेचा, और server operating system market में ऊपर आते हुए Unix vendors पर दबाव डाला
- Linux kernel project कई परिस्थितियों के मेल से 1991 के अंत में शुरू हुआ, और 1993 के अंत तक कई distributions growth phase में आ गईं
- GNU, MIT, BSD और independent projects का software पहले से मौजूद था
- operating system internals की जानकारी internet पर काफी हो गई थी
- high-speed internet घरों तक आना शुरू हो रहा था
- demand-paged virtual memory में सक्षम low-cost processors फैल गए थे
- luck और opportunity थी
- एक stubborn और charismatic project leader था
- Soft Landing Systems, Yggdrasil, Debian, Slackware और Red Hat जैसी distributions सामने आईं; कुछ commercial distributions थीं और कुछ community projects के रूप में शुरू हुईं
Linux और community model
- Linux को BSD से पहले public attention मिलने की एक वजह यह थी कि BSD “Unix Systems Labs Vs BSDi” lawsuit में फंसा हुआ था
- GPL ने binaries के साथ source distribute कराने वाला dynamic effect पैदा किया, और कोई भी permission लिए बिना distribution project शुरू कर सकता था, जिससे सैकड़ों distributions बनीं
- X Window System MIT Project Athena से निकला, और Kerberos भी उसी project से आया
- X Window System development MIT और Project Athena से आगे बढ़कर X Consortium में गया; X Consortium 1993 में खुला और 1996 में बंद हुआ
- OSF Unix systems के source code और API standards तय करने के लिए बनाया गया, और 1996 में X/Open के साथ मिलकर Open Group बन गया
- कई consortiums के पास शुरुआत में काफी funding थी, लेकिन participant companies “कोई और company खर्च देगी” सोचकर निकलती गईं और funds सूखते गए—ऐसा pattern दिखा
FOSS development की sustainability problem
- शुरुआती FOSS में कम developers कम users के लिए passion से काम करते थे, और अक्सर paid नहीं होते थे
- users की growth की speed developers की growth से आगे निकलने लगी, जिससे maintenance pressure बढ़ा
- खासकर QA, release engineering, documentation और translation जैसे “sexy नहीं” क्षेत्रों में developers की कमी साफ दिखी
- कुछ developers को यह बात असहज लगी कि उनके free में contribute किए code से दूसरे लोग पैसा कमा रहे हैं, लेकिन रुख यह है कि companies Linux से पैसा कमा सकें तभी Linux तेजी से आगे बढ़ सकता है
- समय के साथ community में code लिखने वालों के अलावा documentation, translation और promotion करने वाले लोग भी शामिल हो गए, और बाद में gratis software ही इस्तेमाल करने वाले और freedom software को न समझने वाले लोग भी बढ़े
Software piracy और Free Software की लागत
- Software piracy license के विरुद्ध illegal copying और use करने की क्रिया है
- FOSS community के कुछ सदस्य intellectual property या copyright को हल्के में लेते हैं, लेकिन copyright न हो तो software पर control भी खत्म हो जाता है
- Brazil conference में जब “Free Software इस्तेमाल करना चाहिए” कहा गया, तो audience ने “हमारा software तो पूरा free है” जवाब दिया—ऐसा एक उदाहरण आता है
- उस समय Brazil desktop software का लगभग 90% pirated था
- इस स्थिति में Free Software की low cost वाली advantage का एक हिस्सा गायब हो जाता है
- माना जाता है कि Linux kernel इस्तेमाल करने वाला हर व्यक्ति अगर हर hardware platform के लिए सिर्फ 1 डॉलर दे, तो अधिकतर FOSS development को आसानी से support किया जा सकता है
IBM की Linux में भागीदारी
- IBM के भीतर ऐसे लोग थे जो FOSS पर भरोसा करते थे और अपने समय में projects करते थे; Daniel Frye ने उन्हें IBM के अंदर FOSS organization के रूप में जोड़कर Linux को आगे बढ़ाने की कोशिश की
- याद किया जाता है कि IBM के Lou Gerstner ने ऐसा पत्र भेजा था कि पहले business reason होने पर ही open source होता था, लेकिन आगे से business reason होने पर ही closed source की ओर जाएंगे
- इसी समय IBM ने Linux में 1 अरब डॉलर invest करने की घोषणा की, जिसने बड़ा impact डाला
- इसके बाद IBM ने Linux developers को hire कर कई Linux-related हिस्सों पर full-time काम कराया, और Apache Web Server जैसे क्षेत्रों में भी developers को salary दी
- IBM ने करीब एक साल बाद पहला 1 अरब डॉलर का investment recover कर लिया, और एक और 1 अरब डॉलर invest करने की घोषणा की
- IBM ने laptop और desktop business Lenovo को बेच दिया और Price Waterhouse Cooper को acquire करते हुए business solutions company की दिशा में कदम बढ़ाया
- इसके बाद business solutions सिर्फ IBM hardware और software से बंधे नहीं रह सकते थे
- Open Source को ऐसा factor माना गया जिससे IBM solution providers कम cost में बेहतर solutions बना सकें
SCO lawsuit में IBM की भूमिका
- Santa Cruz Operations ने AT&T code-based Unix distribution बनाई थी, और बाद में इसे Caldera Group को बेच दिया गया
- Caldera ने अपना नाम बदलकर SCO किया, फिर यह कहते हुए Linux vendors के खिलाफ lawsuit strategy अपनाई कि Linux में AT&T source code शामिल है और license terms का उल्लंघन हुआ है
- Linux community के अधिकतर लोग इस claim को false मानते थे, और AT&T व Novell contracts पढ़ने के अनुभव के आधार पर Santa Cruz Operations के AT&T code का copyright owner होने का दावा भी भरोसेमंद नहीं लगता था
- IBM, Novell और Red Hat आदि lawsuit में शामिल हुए, और अंततः courts ने यह निष्कर्ष निकाला बताया जाता है कि SCO केवल IBM के साथ समाप्त हो चुके contract की समस्या उठा सकता है, Linux में समस्या नहीं है
- इस प्रक्रिया में Big Blue का legal fight में शामिल होना Linux vendors और users को यह भरोसा देता था कि चीजें ठीक दिशा में जाएंगी
Red Hat और RHEL का business model
- Red Hat Raleigh की एक छोटी company के रूप में शुरू हुई, जिसकी technical capability मजबूत थी लेकिन business और marketing कमजोर थे; Bob Young जुड़कर company policy और direction बनाने में मददगार बने
- Bob Young ने Red Hat को “Linux का Heinz ketchup” जैसा बनाने की analogy दी, और Red Hat ने services बेचने वाले model से revenue कमाया
- समय के साथ Red Hat ने RHEL-centered enterprise business पर focus किया
- desktop सिर्फ RHEL development platform के तौर पर important था, और desktop development Fedora को सौंपा गया
- Fedora नए ideas को बाद में RHEL में डालने के लिए test base की भूमिका निभाता है
- RHEL customers वे organizations हैं जो companies और governments की तरह “mission critical”, “always on” की मांग करती हैं, और अक्सर दर्जनों-सैकड़ों नहीं बल्कि हजारों systems operate करती हैं
- ऐसे customers MTTF, MTTR, 99.999% uptime जैसी service conditions और penalty clauses संभालते हैं, और general first-level support नहीं बल्कि second- और third-level support expect करते हैं
- Red Hat enterprise support, QA, documentation, certification और release engineering पर खर्च करता है, और customers उसके बदले भुगतान करते हैं
Full Stack companies और IBM के Red Hat acquisition की logic
- Oracle द्वारा Sun Microsystems की intellectual property acquire करने का मामला hardware, operating system और applications—सभी को control करने वाली full-stack strategy के रूप में देखा जाता है
- full-stack company पूरे stack को बदलकर applications को benefit दे सकती है, और पूरे stack को test करके inefficiencies और weaknesses खोज सकती है
- IBM और Apple को full-stack companies में रखा जाता है, और products महंगे हों तब भी कई serious customers यह cost चुकाते हैं
- IBM को अपने business solutions business में इस्तेमाल करने के लिए Linux-based full-stack solution की जरूरत थी, और Red Hat के RHEL के पास enterprise solutions की reputation और engineering थी
RHEL clones और Red Hat की terms में बदलाव
- समय के साथ कुछ customers ने कुछ ही RHEL systems खरीदने और बाकी systems पर Red Hat के साथ bug-for-bug compatible दूसरी distribution इस्तेमाल करने का pattern बनाया
- इस तरीके ने customer cost कम की, लेकिन Red Hat उतना ही काम करते हुए भी कम revenue पा रहा था, और Red Hat पर license price बढ़ाने, staff घटाने या दूसरे projects छोड़ने का pressure आने लगा
- IBM/Red Hat ने business decision लिया कि वे source code और build information केवल उन customers को distribute करेंगे जो सभी RHEL-running systems के लिए licenses खरीदते हैं
- यह condition GPL के core से मेल खाती है—ऐसा माना जाता है
- binary पाने वाला व्यक्ति source पाकर bugs ठीक कर सकता है और extend कर सकता है
- Red Hat और IBM GPL code changes को लगातार upstream भेजते हैं
- बड़े community के साथ ideas sharing भी जारी रखते हैं
- clone developers को “freeloader” नहीं कहा जाता, लेकिन clones इस्तेमाल करते हुए किसी भी रूप में community को वापस न देने वाले users freeloading के करीब माने जाते हैं
Clone के बजाय competition बनाने का सुझाव
- Red Hat बदलाव के बाद कई distributions ने कहा कि वे “not RHEL” बनाना जारी रखेंगी, और इससे सामान्य users के लिए कौन-सी distribution इस्तेमाल करनी चाहिए, यह और confusing हो सकता है
- अलग-अलग clones बनाने के बजाय मिलकर एक अच्छी distribution बनाना, या RHEL का सच्चा competitor बनाना बेहतर है—यह रुख है
- SuSE ने RHEL competitor बनाने के लिए 1 करोड़ डॉलर invest करने की घोषणा की, इसे positive माना गया
- हालांकि वही business channels, worldwide support team और enterprise support system बनाना सस्ता नहीं है
- 1 करोड़ डॉलर शुरुआत हो सकता है
- RHEL customers को Red Hat/IBM और channel partners द्वारा दिए जाने वाले support की value देखकर चुनाव करना चाहिए
- अगर कोई customer RHEL की एक copy खरीदकर बाकी free distribution पर चलाना चाहता है, और IBM अब ऐसे customer से deal नहीं करना चाहता, तो उस customer को ऐसा model संभाल सकने वाला दूसरा enterprise Linux provider ढूंढना चाहिए
व्यक्तिगत निष्कर्ष
- Jon “maddog” Hall बताते हैं कि Open Source, Free Software Foundation और GNU project के बनने से पहले से ही वे source code खोलने और customers को source उपलब्ध कराने का काम करते रहे हैं
- Community contribution सिर्फ code लिखने, documentation लिखने और bug reports तक सीमित नहीं है
- schools, companies और governments में Free Software promote किया जा सकता है
- Linux Club बनाया जा सकता है या Upgrade to Linux activities में मदद की जा सकती है
- जब तक companies license का उल्लंघन नहीं करतीं, वे business terms तय कर सकती हैं, और customers उन्हें accept या reject कर सकते हैं
- Red Hat और IBM को “evil” की तरह दिखाते हुए, साथ ही permissive license base पर end users को source guarantee न करने वाली या सिर्फ closed source license देने और clones allow न करने वाली companies को न देखना असंतुलित रवैया है
- researchers, students, hobby users और जिनके पास बहुत कम पैसा है, उनके लिए RHEL जिन architectures को cover नहीं करता उनसे भी आगे support देने वाली सैकड़ों Linux distributions मौजूद हैं
1 टिप्पणियां
Hacker News टिप्पणियां
90 के दशक के आखिर से Red Hat Linux (शुरुआत में 90s क्लोन Caldera Linux), Fedora, RHEL और उसके क्लोन (Scientific, CentOS, Rocky) को निजी तौर पर, शिक्षा में और काम के लिए इस्तेमाल करता आया हूं, और desktop व server के लिए भी recommend करता रहा हूं
अगर कोई Linux इस्तेमाल करना चाहता था, तो मैं कहा करता था कि स्थिर और अच्छी तरह supported विकल्प दो हैं: Red Hat और Debian. लेकिन मेरे हिसाब से Red Hat हाल में मर चुका है. RIP
अब मुझे यकीन नहीं है कि Fedora एक सक्रिय open source project के रूप में बना रहेगा या नहीं. अगर IBM अभी RHEL clones को खत्म कर रहा है, तो मैं यह risk क्यों लूं कि Fedora अगला नंबर नहीं होगा?
मुझे पता है कि “RHEL, Fedora से derived है” और “Fedora एक अलग open source project है”, लेकिन अब RHEL, CentOS Stream से derived है. तो फिर Fedora की जरूरत क्यों है, और Red Hat को Fedora के लिए engineering और infrastructure क्यों देना चाहिए—यह सवाल है
यह सही है कि Fedora एक अलग project है, लेकिन ज्यादातर contributions Red Hat employees करते हैं. अगर IBM कल तय कर ले कि CentOS Stream काफी है और Fedora का खर्च देना बंद कर दे, तो क्या Fedora स्वतंत्र रूप से टिक पाएगा?
यह सिर्फ डर, अनिश्चितता और संदेह (FUD) भी हो सकता है, लेकिन मैं अब IBM के मालिकाना Linux distribution पर भरोसा नहीं करता. अपनी personal machines पहले ही Debian पर ले गया हूं और काम में भी Debian की सलाह दे रहा हूं. जो संगठन Linux installs को काफी customize करते हैं, उनके लिए बिना किसी शर्त वाले पूरी तरह open source project के बजाय अनिश्चित Red Hat/IBM आधारित distribution चुनना मुझे गैर-जिम्मेदाराना लगता है. एक बार धोखा खाओ तो गलती दूसरे की, दो बार हो तो मेरी—और IBM से फिर नहीं ठगा जाऊंगा
Fedora अब भी CentOS की हर चीज, और इसलिए RHEL की हर चीज, के लिए testing ground की भूमिका निभाता है. Fedora जैसे “future distribution” को रखकर future RHEL releases को model करने की development approach के खिलाफ क्या तर्क है, यह जानना चाहूंगा
जो लोग Linux kernel को करीब से follow नहीं करते, उनके लिए बता दूं कि maddog एक legendary शख्सियत हैं
उनका नजरिया बहुत दिलचस्प और सराहनीय है, खासकर जिस तरह वे इतिहास के आधार पर मुद्दे को frame करते हैं. इतिहास जानने से context समझने में सचमुच मदद मिलती है. मूल लेख लंबा है, लेकिन पढ़ने लायक है
मैं Jon Hall से करीब 30 साल छोटा हूं, इसलिए मौखिक परंपरा या लिखी गई बातों के अलावा उनके काम को सीधे जान नहीं सकता था. उन्होंने कोई mega-hit किताब या ऐसा software भी नहीं छोड़ा जिसे मैं इस्तेमाल कर सकूं (ठीक है, Linux for Dummies है), इसलिए मैं लगातार देखता था कि लोग उन्हें legend कहते हैं, लेकिन समझ नहीं पाता था क्यों
आखिरकार मैंने Linux kernel community से पूछा, और उनके योगदान का दायरा समझाया गया. एक मायने में वे Linus के mentor थे. 1994 में जब वे मिले, Linus 25 साल के student थे और Jon 44 साल के DEC marketing manager थे. मैं उनकी बातचीत को कुछ ऐसे scene की तरह imagine करता हूं: “बेटा, मेरी बात ध्यान से सुनो. अब तुम्हें यह करना है”
इस बात को ध्यान में रखें तो Jon Hall की Wikipedia biography की एक पंक्ति खास ध्यान खींचती है. उसमें लिखा है कि Digital में काम करते समय उन्होंने पहली बार Linux में रुचि ली, और Linus Torvalds को Digital के Alpha platform पर पहला port करने के लिए equipment और resources दिलाने में अहम भूमिका निभाई
LinkedIn experience की एक पंक्ति भी यही दृष्टिकोण दिखाती है. Senior Marketing Manager, DEC, 1983-1998: 1994 में Linus Torvalds से मिले, Linux की commercial value पहचानी, और Linux को 64-bit Alpha processor पर port करने के लिए funding secured की, जिससे Linux-based high-performance supercomputers की multi-billion dollar business line खुली
WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
LI: https://www.linkedin.com/in/maddog/
“इन clones का इस्तेमाल करते हुए किसी भी रूप में community को वापस न देने वाले लोगों को ‘free riders’ मानता हूँ” वाली बात से मैं सहमत हूँ, लेकिन यह मूल रूप से free software में कुछ हद तक स्वीकार की गई चीज़ रही है। किसी चीज़ को मुफ़्त में देना यह भी मतलब रखता है कि हर कोई कुछ, या कुछ भी, वापस नहीं देगा
Oracle Awesome Linux जैसी चीज़ से फर्क यह है कि वे Red Hat के value-added काम और ecosystem को service के रूप में बेच रहे हैं। असल में बात कुछ ऐसी है: “हमारे दूसरे products के साथ support चाहिए तो इसे खरीदिए। हम Red Hat जो release करता है, उसे वैसा ही distribute करते हैं”
मेरे हिसाब से Red Hat का बदलाव exclusive “Oracle Red Hat for X” जैसे business model बनाना ज़्यादा महँगा करने की दिशा में है। जिन लोगों के लिए academic high-performance infrastructure में RHEL afford करना संभव नहीं था, वे अब भी afford नहीं कर पाएँगे और बस कुछ और चुन लेंगे
यहाँ Fedora को लेकर शोर मचाने का खास मतलब नहीं है। Fedora कंपनी की जरूरतों को पूरा करने वाला commercial purpose वाला project है, और जिस दिन तक वह मौजूद रहना बंद नहीं करता, मौजूद रहेगा
Red Hat, Microsoft नहीं है। सभी मानते हैं कि distributions बहुत हैं और उनमें कई बेहतरीन भी हैं। आप आज ही एक distribution शुरू कर सकते हैं। लेकिन “ठीक है, बस Debian इस्तेमाल कर लेते हैं” भी कोई खास valid जवाब नहीं है। Debian एक शानदार project और product है, लेकिन अगर आपने Red Hat को इसलिए नहीं चुना था कि 1998 में आपको magazine supplement CD मिली थी, बल्कि किसी और वजह से चुना था, तो Debian बहुत काम किए बिना ideal न होने की संभावना है। आखिर में यह पैसे का मामला है—लोगों से खुद काम करवाने की लागत बनाम Red Hat को काम सौंपकर लोगों को दूसरे काम करने देने की लागत
पुराने समय में Fedora project को servers और hosting donate करने की बात याद आती है। Server setup करते समय मैंने प्रभारी व्यक्ति से पूछा, “आप RHEL चलाना चाहेंगे, है न?” तो उन्होंने “हाँ” कहा, और जब मैंने पूछा, “क्या आपके पास इस्तेमाल करने लायक license key है?” तो बोले, “मिल तो सकती है, लेकिन झंझट है, बस CentOS install कर दीजिए”
Instructor ने class के बाद practice के लिए CentOS इस्तेमाल करने की सलाह दी थी (CentOS के acquire होने से पहले)। बाद में projects में से एक में आखिरकार Red Hat इस्तेमाल हुआ
उसके बाद CentOS और clones थे, और कुछ समय तक तो लगता था कि जब लोग RHEL कहते हैं तो असल में CentOS मतलब रखते हैं
Qt भी ऐसा ही है। Software का लगभग सब कुछ Qt पर depend करता हो, फिर भी Digia को पैसे न देने के लिए लोग Qt 4.x पर टिके रहते हैं
Red Hat employee के रूप में maddog का नजरिया अच्छा लगता है। काश दूसरे लोग भी companies open source के लिए क्या करती हैं इसे उनकी तरह व्यापक रूप से देख पाते
अंदर से काम कैसे बनता है, यह देखने पर नजरिया बदल जाता है। काश हम लोगों को बता पाते कि हम असल में क्या बेचते हैं। हम software या software license नहीं बेचते
हम open source licenses से बचकर नहीं निकल रहे, न ही license बदल रहे हैं। हम अपने उन लोगों को काम करते रहने देना चाहते हैं जो customers के लिए valuable काम करते हैं। हमारे बहुत से काम upstream projects में जाते हैं और competitors, community, users के साथ share होते हैं
maddog से ऐसी शानदार historical stories सुनना अच्छा लगता है। जब उन्होंने अपने लेख में बताए Austin visits में से एक किया था, तब मैं LTC में काम कर रहा था, और lunch के दौरान बातचीत करने का मौका मिला था। करीब 20 साल पहले की बात है
70s में पहुँच चुके लोग अपने career में किसे “inflection point” मानते हैं, यह सुनना हमेशा दिलचस्प होता है। मेरे inflection points और उनके inflection points जिस तरह उलझे हुए हैं, वह भी खास तौर पर प्रभावशाली है
मैं SCO की बकवास हलचल के बीच में था, लेकिन पता नहीं उसमें से कुछ कहना ठीक है या नहीं। शायद अब company lawyers पर्याप्त रूप से retire हो चुके होंगे या मर चुके होंगे, तो हो सकता है मैं जो कहना चाहूँ कह सकूँ। अगर motivation हुई तो
खुशी है कि maddog अब भी अपनी stories share कर रहे हैं। उम्र बढ़ने के साथ internet पर किसी से भी कुछ share करने में मेरी दिलचस्पी कम होती जा रही है। मेरे लिए meaningful conversations आजकल लगभग हमेशा face-to-face होती हैं, इसलिए जिन लोगों को मैं personally नहीं जानता, उनके साथ share करने या जुड़ने की खास value नहीं लगती
जिस company में मैं काम करता हूँ, वह हमारे बनाए high-performance server equipment पर RHEL चलाना चाहती थी, लेकिन हमें प्रति license लगभग 1 million dollars quote किया गया और negotiation की गुंजाइश नहीं थी। इससे हमारा product बहुत महँगा हो जाता
इसलिए अंत में हम CentOS पर गए और फिर Rocky पर shift हुए, और इसे manage करने के लिए करीब 30 लोगों की team hire की (वे दूसरे projects भी संभालते हैं)। Red Hat और उनके software को उनके चाहने के तरीके से manage करने के अधिकार का मैं सम्मान करता हूँ, लेकिन पिछले कुछ सालों के experience से लगता है कि वे brand से maximum निचोड़ना चाहते हैं। अगले 5 सालों में क्या होगा, यह देखने की उत्सुकता है
“1969 में प्रोग्रामिंग शुरू की”, “असल में सॉफ्टवेयर बेचना न सिर्फ मुश्किल था, बल्कि उस पर copyright लागू भी नहीं किया जा सकता था” वाले हिस्से पर, मुझे जिज्ञासा है कि 1969 में असल कानूनी स्थिति वाकई ऐसी थी क्या। क्या सच में सॉफ्टवेयर पर copyright लागू नहीं किया जा सकता था?
यह तो काफी संभव लगता है कि 1969 में लेखक ऐसा मानते रहे हों, लेकिन यह धारणा कानूनी रूप से सही थी या नहीं, यह जानना चाहता हूँ
उस समय मैंने कानूनी practice नहीं की थी, लेकिन जो समझ सुनने में आई थी उसके मुताबिक यह स्पष्ट नहीं था कि copyright सॉफ्टवेयर पर लागू होगा या नहीं, और अगर होगा तो कैसे होगा। हालांकि trade secret से आगे, लिखे गए सॉफ्टवेयर के लिए किसी न किसी तरह की protection बनेगी, यह समझदार पक्ष आम तौर पर उम्मीद कर रहे थे
यह copyright law के तहत होगा या सॉफ्टवेयर के लिए किसी अलग व्यवस्था के जरिए, इस पर तरह-तरह के सवाल, theories और proposals थे। अमेरिका का जवाब तब स्पष्ट हुआ जब copyright law के दायरे की परिभाषा में “computer program” शामिल किया गया। आज भी बचे हुए मुद्दों पर चर्चा करते समय उस recommendation को आगे बढ़ाने वाली committee, CONTU, का हवाला दिया जाता है
https://en.wikipedia.org/wiki/Software_copyright#History
Jon Hall पर भरोसा न करके social media पर किसी भी अनजान व्यक्ति पर भरोसा करना अजीब है
2000 के आसपास Paris में मेरे co-host किए गए एक event में maddog से मिला था। हमने बहुत सारे सवाल पूछे, और उन्होंने insightful जवाब दिए। कभी-कभी linked article जैसी लंबी कहानी में लपेटकर जवाब देते थे
जो सबसे ज्यादा याद है, वह यह है। “सवाल: Linux को desktop पर पहले से मौजूद कुछ percentage points से आगे market share पाने में हम कैसे मदद कर सकते हैं?”
“जवाब: यह नहीं हो सकता। ऐसा market खोजिए जो अभी computer इस्तेमाल नहीं कर रहा है, उस market की जरूरतों को हल करने वाला product बनाइए, और उस product में Linux इस्तेमाल करवाइए। उदाहरण के लिए smartphone के बारे में सोचिए”
अच्छा लग रहा है कि maddog अभी भी FOSS में सक्रिय रूप से जुड़े हुए हैं
90 के दशक के आखिर के आसपास Chicago के COMDEX में, उन्होंने मुझे और मेरे दोस्त को मनाया था कि हम कुछ घंटों के लिए उनका booth संभाल लें ताकि वे exhibition floor घूम सकें। वह LPI था या LI, या कोई और Linux-related organization, यह याद नहीं। शायद हम distro CDs बांट रहे थे और लोगों को Linux के बारे में समझा रहे थे
वह पागलपन भरा दौर था जब Linux PC दुनिया में छा रहा था, और Tux हर जगह था