ওপেন সোর্স সফটওয়্যারের ইতিহাস: GPL থেকে SSPL

ওপেন সোর্স সফটওয়্যার কী এবং এর উৎপত্তি

ওপেন সোর্স সফটওয়্যারের ইতিহাস মূলত এর লাইসেন্সগুলোর ইতিহাস। কারণ অন্য কেউ লেখা কোড দিয়ে আপনি কী করতে পারবেন, তা নির্ধারণ করে একমাত্র লাইসেন্সই। এই লাইসেন্সগুলো লিখিত হওয়ার অনেক আগে থেকেই কোড উন্মুক্তভাবে শেয়ার করা হতো। কোড যখন একটি পণ্যে পরিণত হলো, তখন তা শেয়ার করা বন্ধ হয়ে গেল। আদালতে সেই শেয়ারিংয়ের অধিকার কার্যকর রাখার জন্যই লাইসেন্সগুলো লেখা হয়েছিল।

এটি সংক্ষিপ্ত সংস্করণ। বিস্তারিত ইতিহাস গুরুত্বপূর্ণ, কারণ আজ আপনি সার্ভারে যে সফটওয়্যার চালান, তাতেও সেই সিদ্ধান্তগুলোর প্রভাব রয়ে গেছে। কিছু সিদ্ধান্ত 1983 সালে নেওয়া হয়েছিল। কিছু সিদ্ধান্ত নেওয়া হয়েছে গত বছর। এ কারণেই আমাদের self-hosting গাইডের কয়েকটি অ্যাপ্লিকেশন এখন ভিন্ন নামের দুটি সংস্করণে পাওয়া যায়।

বিক্রি হওয়ার আগে সফটওয়্যার শেয়ার করা হতো

1950 এবং 1960-এর দশকে সফটওয়্যার মেশিনের সঙ্গেই পাওয়া যেত। IBM তাদের সিস্টেমের সঙ্গে source code দিত। 1955 সালে প্রতিষ্ঠিত SHARE-এর মতো user group-গুলো tape-এর মাধ্যমে প্রোগ্রাম একে অপরের মধ্যে বিতরণ করত। দুটি কারণে এই ব্যবস্থা শেষ হয়। 1969 সালে IBM ঘোষণা করে যে hardware-এর দাম থেকে software-এর দাম আলাদাভাবে নির্ধারণ করা হবে। এর ফলে software-এর নিজস্ব বাজার তৈরি হয়। এরপর আইনও সেই পরিবর্তনের সঙ্গে সামঞ্জস্যপূর্ণ হয়। 1980 সালের Computer Software Copyright Act নিশ্চিত করে যে United States-এ প্রোগ্রাম copyright সুরক্ষাযোগ্য কাজ। 1980 সালের পর, আপনি নিজে লেখেননি এমন code ডিফল্টভাবে closed থাকত। তাই সেটি শেয়ার করতে লেখকের লিখিত অনুমতি প্রয়োজন হতো।

The Homebrew Computer Club এবং Hobbyists-দের উদ্দেশে Open Letter

The Homebrew Computer Club-এর প্রথম সভা 1975 সালের March মাসে California-এর Menlo Park-এ একটি garage-এ অনুষ্ঠিত হয়। সদস্যরা hardware ও paper tape নিয়ে আসতেন, এবং meeting-এর অংশ হিসেবেই copying করা হতো। Bill Gates ও Paul Allen-এর লেখা Altair BASIC, copied tape-এ room জুড়ে একে অন্যের কাছে পৌঁছে যেত। February 1976-এ Gates club-এর newsletter-এ "An Open Letter to Hobbyists" শিরোনামে উত্তর দেন।

Hobbyists-দের অধিকাংশই নিশ্চয়ই জানেন যে, আপনাদের অধিকাংশই software চুরি করেন।

তিনি লেখেন, দশজন Altair owner-এর মধ্যে একজনেরও কম BASIC-এর জন্য অর্থ দিয়েছিলেন, এবং এটি লেখার জন্য ব্যবহৃত computer time-এর মূল্য 40,000 dollars-এর বেশি ছিল। আধুনিক বিতর্কের পুরো কাঠামো ওই letter-এই ইতিমধ্যে রয়েছে। Software copy করতে কোনো খরচ হয় না, এবং যারা copy করে তাদের প্রত্যেকের উপকার হয়। কিন্তু এটি লিখতে কারও জীবনের এক বছর ব্যয় হয়েছে। নিচে বর্ণিত প্রতিটি licence একই সঙ্গে এই দুটি সত্যের উত্তর দেওয়ার চেষ্টা।

1983 সালে GNU এবং আইনি উদ্ভাবন হিসেবে GPL

Richard Stallman 1983 সালের September মাসে Usenet-এ GNU ঘোষণা করেন। Usenet ছিল এমন একটি newsgroup network, যা web-এর আগে মানুষ ব্যবহার করত। GNU-এর অর্থ হলো "GNU's Not Unix"। পরিকল্পনাটি ছিল এমন একটি সম্পূর্ণ Unix-compatible system তৈরি করা, যা যে কেউ copy ও পরিবর্তন করতে পারবে।

Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.

Free Software Foundation (FSF) 1985 সালে প্রতিষ্ঠিত হয়। তাদের Free Software Definition-এ চারটি স্বাধীনতার কথা বলা হয়েছে এবং সেগুলোর numbering শূন্য থেকে শুরু হয়েছে: যেকোনো উদ্দেশ্যে program চালানো, program অধ্যয়ন ও পরিবর্তন করা, copy পুনর্বিতরণ করা এবং পরিবর্তিত version বিতরণ করা। Freedom 1-এর জন্য source code প্রয়োজন, কারণ বাস্তবসম্মত কোনো উপায়ে কেউ binary অধ্যয়ন করতে পারে না। এখানে "Free" বলতে স্বাধীনতা বোঝানো হয়েছে, দাম নয়। FSF-এর নিজস্ব ভাষায়, এটি free as in free speech, not free beer।

মূল ধারণাটি আবিষ্কার ছিল না। আবিষ্কার ছিল licence-টি। GNU General Public License (GPL) copyright ব্যবহার করে sharing বাধ্যতামূলক করে, sharing প্রতিরোধ করতে নয়। আপনি চারটি স্বাধীনতা একটি শর্তে পান: আপনি যাকে software দেন, সেও source code-সহ একই স্বাধীনতাগুলো পাবে। Stallman এই পদ্ধতির নাম দেন copyleft। এটি প্রথম 1985 সালে GNU Emacs-এর সঙ্গে প্রকাশিত হয়, 1989 সালে GPL version 1 হয় এবং June 1991-এ version 2 প্রকাশিত হয়।

GPL কার্যকর হয়, কারণ এটি copyright law-এর ওপর ভিত্তি করে কাজ করে, copyright law-এর বিরুদ্ধে নয়। কোনো licence না থাকলে অন্য কারও code বিতরণ করার অধিকার আপনার নেই। GPL সেই অধিকার দেয় এবং এর সঙ্গে কিছু শর্ত যুক্ত করে। তাই কোনো vendor router-এর ভিতরে modified GPL code ships করে source code দিতে অস্বীকার করলে, তারা কোনো প্রতিশ্রুতি ভঙ্গ করছে না। তারা copyright লঙ্ঘন করছে, যার বিরুদ্ধে copyright holder আদালতে মামলা করতে পারেন। এ কারণেই enforcement সম্ভব হয়। 2000-এর দশকে Harald Welte-এর gpl-violations.org cases থেকে শুরু করে 2021 সালে দায়ের করা Software Freedom Conservancy-এর Vizio-এর বিরুদ্ধে মামলাও এর উদাহরণ। ওই মামলায় যুক্তি দেওয়া হয়েছে, television কেনা ব্যক্তি source code দাবি করতে পারেন।

Linux সিস্টেম সম্পূর্ণ করেছিল

1991 সালের মধ্যে GNU প্রকল্পে compiler, C library, shell এবং অধিকাংশ tool ছিল। কিন্তু কোনো কার্যকর kernel ছিল না। কারণ GNU-এর নিজস্ব kernel, Hurd, পরিকল্পনার চেয়ে অনেক বেশি সময় নিচ্ছিল। 1991 সালের August মাসে Helsinki-এর এক শিক্ষার্থী comp.os.minix newsgroup-এ লিখেছিলেন:

আমি একটি (বিনামূল্যের) operating system তৈরি করছি (এটি শুধু শখের কাজ; gnu-এর মতো বড় ও পেশাদার হবে না) 386(486) AT clone-এর জন্য।

Linux 0.01 1991 সালের September মাসে প্রকাশিত হয়। তখন এটি Linus Torvalds নিজের লেখা একটি licence-এর অধীনে ছিল, যেখানে এটি বিক্রি করা নিষিদ্ধ ছিল। 1992 সালের শুরুর দিকে তিনি সেই licence-এর পরিবর্তে GPLv2 ব্যবহার করেন। পরে তিনি বলেছেন, এটি ছিল তাঁর নেওয়া সেরা সিদ্ধান্তগুলোর একটি। এই licence-ই corporate contribution নিরাপদ করেছিল। কোনো কোম্পানি kernel-এ engineer নিয়োগ করতে পারত, কারণ তারা জানত যে কোনো প্রতিদ্বন্দ্বী সেই উন্নতিগুলো নিজেদের private code হিসেবে রাখতে পারবে না।

Berkeley-তে একটি free Unix আগে থেকেই ছিল। Linux কেন BSD (Berkeley Software Distribution)-এর পরিবর্তে default free Unix হয়ে উঠল, তার একটি কারণ ছিল মামলা। Unix System Laboratories 1992 সালে Berkeley Software Design-এর বিরুদ্ধে মামলা করে। মামলাটি 1994 সালের শুরুর দিক পর্যন্ত চলেছিল। ওই দুই বছর BSD system-গুলোর সঙ্গে legal risk ছিল, কিন্তু Linux-এর সঙ্গে তেমন ঝুঁকি ছিল না। সেই সময়ই ব্যবহারকারীরা Linux গ্রহণ করতে শুরু করেন। FSF মানুষকে সম্মিলিত system-টিকে GNU/Linux বলতে অনুরোধ করে, কারণ Linux হলো kernel এবং আশপাশের অধিকাংশ tool GNU-এর। অধিকাংশ মানুষ Linux বলে। দুটি নামই একই software collection-কে নির্দেশ করে।

1998: open source-এর পুনর্নামকরণ এবং যে বিভাজনের আর নিরাময় হয়নি

1998 সালের January মাসে Netscape ঘোষণা করে যে তারা তাদের browser-এর source code প্রকাশ করবে। এর আগে এমন সিদ্ধান্ত নেওয়া সবচেয়ে বড় কোম্পানি ছিল এটিই, এবং এই সিদ্ধান্ত একটি বাস্তব সমস্যা প্রকাশ করে। "free software" কথাটি English-এ "যে software-এর জন্য কোনো অর্থ দিতে হয় না" হিসেবে বোঝা যায়, এবং নির্বাহীরা ঠিক সেটিই বুঝেছিলেন। একটি দল 1998 সালের February মাসে Palo Alto-তে আরও উপযুক্ত একটি term খুঁজতে বসে, এবং Christine Peterson "open source" প্রস্তাব করেন। কয়েক সপ্তাহের মধ্যে Eric Raymond এবং Bruce Perens Open Source Initiative (OSI) প্রতিষ্ঠা করেন। এটি Open Source Definition গ্রহণ করে, যা Perens 1997 সালে রচিত Debian Free Software Guidelines থেকে অভিযোজিত হয়েছিল।

Open Source Definition-এ দশটি criterion আছে। আধুনিক অধিকাংশ বিতর্কের ফল দুটি criterion নির্ধারণ করে: source অবশ্যই উপলভ্য হতে হবে, এবং licence প্রোগ্রামটি কে ব্যবহার করতে পারবে বা কী কাজে ব্যবহার করতে পারবে, তা সীমাবদ্ধ করতে পারবে না। কোনো licence-এ যদি বলা থাকে, "আপনি এটি commercial service হিসেবে দিতে পারবেন না", তাহলে অন্য সব অনুমতি থাকলেও সেটি এই পরীক্ষায় ব্যর্থ হয়। এই বাক্যটি মনে রাখুন। আজকের source-available licence-গুলো এই সীমারেখাই অতিক্রম করে।

1998 সালে শুরু হওয়া বিভাজনটি কোন licence গ্রহণযোগ্য, তা নিয়ে নয়; এটি কারণ নিয়ে। FSF-এর যুক্তি নৈতিক: যে user প্রোগ্রাম পরিবর্তন করতে পারেন না, তিনি নিজের computer নিয়ন্ত্রণ করেন না। Raymond-এর "The Cathedral and the Bazaar" প্রবন্ধে ব্যবসায়িক ক্ষেত্রে উপস্থাপিত OSI-এর যুক্তি বাস্তবভিত্তিক: open development উন্নততর software তৈরি করে, এবং কোনো কোম্পানি এই পদ্ধতি কাজে লাগাতে পারে। Stallman-এর জবাব, "Why Open Source Misses the Point of Free Software", এখনও gnu.org-এ প্রকাশিত আছে, এবং তিনি নতুন term-টি কখনও গ্রহণ করেননি। এটি তৈরিতে সহায়তাকারী Perens 1999 সালে OSI board থেকে পদত্যাগ করেন। তাঁর বক্তব্য ছিল, movement-টি free software থেকে দূরে সরে গেছে।

ব্যবহারিক ব্যবধানটি কতটা ছোট, সে বিষয়ে নির্ভুল থাকা গুরুত্বপূর্ণ। FSF-এর free licence-এর তালিকা এবং OSI-এর approved licence-এর তালিকা প্রায় সব ক্ষেত্রেই একমত; এর মধ্যে GPL, MIT, Apache 2.0 এবং BSD-ও রয়েছে। যেসব লেখকের একই সঙ্গে দুটি অর্থ বোঝানো দরকার, তারা FOSS (free and open source software) বা FLOSS (free/libre and open source software) ব্যবহার করেন।

কোম্পানিগুলো কীভাবে কোড প্রকাশ করতে শিখল

1999 সালে Red Hat-এর stock market listing দেখিয়েছিল যে কপি বিক্রির চেয়ে support এবং packaging-এ বেশি অর্থ রয়েছে। 2001 সালে IBM Linux-এর জন্য এক বিলিয়ন ডলার বরাদ্দ করেছিল। 2001 সালে Microsoft-এর chief executive Linux-কে "a cancer" বলেছিলেন। একই কোম্পানি 2016 সালে Linux Foundation-এর platinum member হয় এবং 2018 সালে stock-এর বিনিময়ে 7.5 billion dollars-এ GitHub কিনে নেয়। 2019 সালে IBM 34 billion dollars-এ Red Hat কিনে নেয়। এসবের কোনোটিই licence সম্পর্কে মত পরিবর্তনের ফল ছিল না। পরিবর্তনটি হয়েছিল অর্থ কোথায় থাকে, সেই জায়গায়। কোনো operating system যদি shared cost হয়, তাহলে নিজেরটি রক্ষণাবেক্ষণের জন্য অর্থ ব্যয় করা ব্যয়বহুল। তাই প্রতিটি vendor operating system-এর ওপরের স্তরে প্রতিযোগিতা করতে বেশি আগ্রহী।

Corporate ownership-এর বিপরীত প্রভাবও দেখা যায়। Oracle 2010 সালে Sun কিনলে MySQL এবং OpenOffice.org তার অধীনে আসে, এবং উভয় community-ই আলাদা হয়ে যায়। MySQL থেকে MariaDB গড়ে ওঠে। 2010 সালের September-এ OpenOffice.org থেকে LibreOffice fork করা হয়। একটি fork-ই user community-এর হাতে থাকা প্রকৃত একমাত্র ভোট। Licence সেই ভোট দেওয়া সম্ভব করে।

কিছু self-hosted অ্যাপের এখন fork কেন রয়েছে

2018 সাল থেকে কয়েকটি কোম্পানি আগে প্রকাশ করা software-এর licensing terms পরিবর্তন করেছে। প্রতিবার পরিস্থিতি একই ছিল। একটি কোম্পানি প্রায় সব developer নিয়োগ করেছিল, অনেক বড় একটি cloud provider একই software managed service হিসেবে বিক্রি করছিল, এবং ছোট কোম্পানিটি সিদ্ধান্ত নিয়েছিল যে প্রতিযোগিতা করতে না পারার কারণ licence।

• MongoDB October 2018-এ Server Side Public License (SSPL) গ্রহণ করে। SSPL অনুযায়ী, আপনি software-টি অন্যদের service হিসেবে দিলে সেই service দিতে ব্যবহৃত সবকিছুর source প্রকাশ করতে হবে। OSI এটিকে open source হিসেবে গ্রহণ করেনি, এবং MongoDB 2019 সালে পর্যালোচনা থেকে এটি প্রত্যাহার করে।
• Redis 2018 এবং 2019 সালে কিছু module-এ ব্যবহারের বিধিনিষেধ যোগ করে। এরপর March 2024-এ version 7.4 থেকে মূল server-কে dual source-available terms-এর অধীনে নিয়ে যায়। সর্বশেষ BSD-licensed release-এর একটি fork কয়েক দিন পর Valkey হিসেবে প্রকাশিত হয়। এটি Linux Foundation-এর অধীনে রয়েছে এবং Amazon, Google ও Oracle-সহ অন্যান্য প্রতিষ্ঠান এর পৃষ্ঠপোষক। May 2025-এ Redis Redis 8-এর জন্য তৃতীয় বিকল্প হিসেবে Affero General Public License version 3 (AGPLv3) যোগ করে। এই licence OSI-approved।
• Elastic January 2021-এ Elasticsearch এবং Kibana-কে Apache 2.0 থেকে সরিয়ে SSPL এবং Elastic License terms-এর dual ব্যবস্থায় নিয়ে যায়। Amazon OpenSearch fork করে। Elastic August 2024-এ তৃতীয় বিকল্প হিসেবে AGPLv3 যোগ করে। September 2024-এ OpenSearch-কে Linux Foundation-এর অধীনে OpenSearch Software Foundation হিসেবে হস্তান্তর করা হয়।
• HashiCorp August 2023-এ Terraform এবং তাদের অন্যান্য tool-কে Business Source License (BUSL)-এর অধীনে নিয়ে যায়। BUSL কার্যকর থাকা অবস্থায় open source licence নয়, কারণ এটি প্রতিযোগী production use নিষিদ্ধ করে। প্রতিটি release নির্দিষ্ট তারিখে open licence-এ রূপান্তরিত হয়; Terraform-এর ক্ষেত্রে চার বছর পর। কয়েক সপ্তাহের মধ্যেই OpenTofu fork করা হয় এবং এটিও এখন Linux Foundation-এর অধীনে রয়েছে।

এই বিরোধের উভয় পক্ষেরই বাস্তব যুক্তি রয়েছে, এবং কোনো পক্ষই অসৎ উদ্দেশ্যে কাজ করছে না। একটি কোম্পানি যখন পঞ্চাশটি salary দেয়, অথচ অনেক বড় একটি প্রতিষ্ঠান তার কাজ resell করে, তখন এমন সমস্যা তৈরি হয় যা goodwill দিয়ে সমাধান করা যায় না। আবার Apache 2.0 terms-এর ভিত্তিতে system তৈরি করা কোনো user নতুন terms-এর অধীনে জেগে উঠলেও সমস্যায় পড়েন, এবং আগে কেউ তার মতামত নেয়নি। এই ঘটনাগুলোর দুটিতে এরপর কী ঘটেছিল, তা লক্ষ্য করুন। fork-গুলো প্রতিষ্ঠিত হওয়ার পর Elastic এবং Redis উভয়ই আবার শক্তিশালী copyleft যোগ করে। Copyleft মূল অভিযোগের সমাধান করে, কারণ AGPLv3 অনুযায়ী service provider-কে সে যে পরিবর্তন চালায় তা প্রকাশ করতে হয়। August 2026 পর্যন্ত উভয় project এবং উভয় fork-ই সক্রিয় রয়েছে। Licence-গুলো এমন ফলাফল সম্ভব করার জন্যই তৈরি করা হয়েছিল।

লাইসেন্স পরিবর্তন করার অনুমতি কার আছে

কোনো প্রকল্পের সব কপিরাইটের নিয়ন্ত্রণ একটি পক্ষের হাতে থাকলেই কেবল সেটির লাইসেন্স পরিবর্তন করা যায়। কোম্পানিগুলো সাধারণত দুটি উপায়ের একটির মাধ্যমে এই নিয়ন্ত্রণ পায়। কপিরাইট assignment-এর মাধ্যমে প্রতিটি contribution-এর মালিকানা কোম্পানির কাছে হস্তান্তর করা হয়। Contributor licence agreement (CLA)-এর মাধ্যমে আপনি মালিকানা ধরে রাখেন, কিন্তু কোম্পানিকে আপনার কাজের লাইসেন্স পরিবর্তন করার জন্য যথেষ্ট বিস্তৃত অধিকার দেন। সাধারণত আপনার প্রথম pull request-এ কোনো bot যে link পোস্ট করে, তাতে click করেই যেকোনো একটি চুক্তিতে স্বাক্ষর করা হয়।

Linux-এর কোনো CLA নেই। Contribution-গুলো Developer Certificate of Origin সহ GPLv2-এর অধীনে আসে, এবং কপিরাইট হাজার হাজার ব্যক্তি ও কোম্পানির মধ্যে ছড়িয়ে আছে। কেউ Linux-এর লাইসেন্স পরিবর্তন করতে পারে না, কারণ সবার স্বাক্ষর একত্র করা কারও পক্ষেই সম্ভব হবে না। একই সুরক্ষা বহু স্বাধীন কপিরাইট মালিক থাকা যেকোনো প্রকল্পের ক্ষেত্রেও প্রযোজ্য। এটি কোনো প্রতিশ্রুতির চেয়ে শক্তিশালী সুরক্ষা, কারণ এটি কার মালিকানায় কী আছে—সে বিষয়ে একটি বাস্তব তথ্য।

তাই আপনি যে software-এর ওপর নির্ভর করার পরিকল্পনা করছেন, সে সম্পর্কে প্রশ্নটি হওয়া উচিত—এটি আজ open source কি না, তা নয়। প্রশ্নটি হওয়া উচিত, কে সেটির লাইসেন্স পরিবর্তন করতে পারে এবং তারা একাই তা করতে পারবে কি না।

একটি foundation আসলে কী দেয়

একটি foundation asset ধারণ করে এবং সিদ্ধান্ত কীভাবে নেওয়া হবে, সেই নিয়ম নির্ধারণ করে। Apache Software Foundation, Linux Foundation, এর অধীন Cloud Native Computing Foundation এবং Software Freedom Conservancy—প্রত্যেকেই এই কাজের একটি সংস্করণ করে। কোনো foundation জাদুর কারণে নিরপেক্ষ নয়। সদস্যরা তাদের আসনের জন্য অর্থ দেন, এবং বড় foundation প্রকল্পে full time কাজ করা অধিকাংশ মানুষ member company-গুলোর কাছ থেকে বেতন পান। আপনি যা পান, তা আরও সীমিত হলেও যথেষ্ট মূল্যবান: trademark এবং release process কোনো একক vendor-এর মালিকানাধীন থাকে না। তাই কোনো একটি company প্রকল্পটিকে private করে নিতে পারে না।

মানুষ যে বিষয়টি প্রায়ই উপেক্ষা করে, সেটি হলো trademark। Code license-এর অধীনে থাকে। কোনো নাম একটি trademark, আর trademark code licence-এর আওতায় পড়ে না। আপনি সবসময় code fork করতে পারেন। তবে সাধারণত নামটি রাখতে পারেন না। এ কারণেই এই আলোচনার fork-গুলোর নাম Valkey, OpenSearch, OpenTofu এবং Forgejo।

রক্ষণাবেক্ষণকারীর সমস্যা

আধুনিক অবকাঠামো এমন সব প্রকল্পের ওপর নির্ভরশীল, যেগুলো একজন বা দুজন অবৈতনিক রক্ষণাবেক্ষণকারী পরিচালনা করেন। ব্যর্থতার ঘটনাগুলোই এই বাস্তবতা স্পষ্ট করে। 2014 সালের OpenSSL-এর Heartbleed ত্রুটি এমন একটি library-কে প্রভাবিত করেছিল, যা Internet-এর encrypted traffic-এর বড় একটি অংশ বহন করত এবং প্রায় কোনো অর্থ ছাড়াই অল্প কয়েকজন মানুষ রক্ষণাবেক্ষণ করতেন। 2021 সালের December-এ Log4Shell-এর ঘটনার response সমন্বয় করতে হয়েছিল Apache Log4j প্রকল্পের একটি ছোট volunteer team-এর মাধ্যমে।

2024 সালের March-এ পাওয়া XZ Utils backdoor সবচেয়ে স্পষ্ট উদাহরণ। কারণ আক্রমণটি code-এর বদলে maintainer-কে লক্ষ্য করেছিল। একটি account প্রায় দুই বছর ধরে Linux distribution-গুলোতে ব্যবহৃত একটি compression library-তে সত্যিই উপযোগী contribution জমা দিয়েছিল। অন্য account-গুলো ক্লান্ত একমাত্র maintainer-কে সাহায্য গ্রহণের জন্য চাপ দেয়। নতুন co-maintainer পরে release archive-এ একটি backdoor স্থাপন করে। এটি এমন সিস্টেমকে লক্ষ্য করেছিল, যেখানে SSH (secure shell) daemon liblzma-এর সঙ্গে link করা থাকে। একজন developer login প্রত্যাশার তুলনায় প্রায় half a second বেশি সময় নিচ্ছিল কেন, তা তদন্ত করতে গিয়ে এটি শনাক্ত করেন। এটি ছিল ভাগ্যের ব্যাপার, এবং সংশ্লিষ্ট সবাই প্রকাশ্যে তা স্বীকার করেছেন।

অর্থ আসতে শুরু করেছে: 2019 সাল থেকে GitHub Sponsors, Open Collective, 2022 সাল থেকে Germany-এর Sovereign Tech Fund এবং OpenSSF-এর Alpha-Omega প্রকল্পের মাধ্যমে। অর্থের প্রবাহ অসম, এবং সাধারণত আগে থেকেই পরিচিত প্রকল্পগুলোই অর্থ পায়। Regulation-ও চালু হচ্ছে। European Union-এর Cyber Resilience Act 2024 সালের December-এ কার্যকর হয়, তবে এর অধিকাংশ দায়িত্ব 2027 সালের December থেকে প্রযোজ্য হবে। প্রাথমিক খসড়াগুলোতে অবৈতনিক volunteer-দের ওপর manufacturer liability দেওয়ার কথা ছিল। তাই foundation ও distribution-গুলোর দীর্ঘ lobbying-এর পরে চূড়ান্ত পাঠে "open source software steward" নামে একটি অপেক্ষাকৃত হালকা category তৈরি করা হয়।

VPS-এর সফটওয়্যারের ক্ষেত্রে open source-এর ইতিহাসের অর্থ

আমাদের self-hosting গাইডের প্রতিটি অ্যাপ এই সিদ্ধান্তগুলোর ধারাবাহিক ফল। Nextcloud একটি fork-এর কারণে তৈরি হয়েছে: 2016 সালে ownCloud-এর প্রতিষ্ঠাতা এবং দলের বড় একটি অংশ চলে গিয়ে AGPLv3-এর অধীনে প্রকল্পটি নতুনভাবে শুরু করেন। এরপর থেকে দুটি product সমান্তরালে বিকশিত হয়েছে। এই ইতিহাসই বিবেচনা করার মতো Nextcloud বিকল্পগুলোর এবং উভয়ের সঙ্গে প্রতিযোগিতা করা self-hosted Dropbox বিকল্পগুলোর পটভূমি।

Git hosting-এর ক্ষেত্রেও একই ধারা দেখা যায়। Gitea নিজেই 2016 সালে Gogs-এর একটি fork হিসেবে শুরু হয়। 2022 সালের শেষ দিকে প্রকল্পটির trademark এবং domain একটি company-এর কাছে চলে যায়। ওই বছরের December-এ Codeberg Forgejo fork করে। 2024 সালে version 9 প্রকাশের সঙ্গে Forgejo MIT থেকে GPLv3-এ পরিবর্তিত হয়। উভয় product-ই self-hosted Git server-এর বিকল্পগুলোতে আলোচনা করা হয়েছে। তাদের licence-এর পার্থক্যই তারা আলাদা পথে বিকশিত হওয়ার বড় একটি কারণ। এদিকে অধিকাংশ free software Microsoft-এর মালিকানাধীন একটি closed platform GitHub-এ তৈরি হয়। এটি একটি পুরোনো বিতর্ক, যেখানে উভয় পক্ষেরই যুক্তিসঙ্গত বক্তব্য আছে। দেখুন GitHub আসলে কী।

কোনো project-এর জন্য server নির্দিষ্ট করার আগে চারটি পরীক্ষা করতে দশ মিনিট ব্যয় করা মূল্যবান।

• marketing page নয়, repository-এর LICENSE file পড়ুন। file-এর বক্তব্য বদলে যাওয়ার পরও page-এ অনেক সময় "open source" লেখা থাকে।
• CLA বা copyright assignment আছে কি না দেখুন। এমন কোনো ব্যবস্থা থাকলে একজন owner ভবিষ্যৎ release-এর শর্ত পরিবর্তন করতে পারেন।
• copyright কার হাতে আছে তা জানুন: একটি company, বহু contributor, নাকি একটি foundation।
• সক্রিয় maintainer-এর সংখ্যা গণনা করুন। মাত্র একজন maintainer থাকা সেই ব্যক্তির জন্য যেমন ঝুঁকি, আপনার জন্যও তেমন ঝুঁকি।

এর কোনোটিই single-vendor software এড়িয়ে চলার কথা বলে না। এর অনেকটাই চমৎকার, এবং software-এর জন্য অর্থ পাওয়াই প্রায়ই সেটি রক্ষণাবেক্ষণের একমাত্র কারণ। এটি আপনাকে জানায়, আপনি কোন ঝুঁকির মধ্যে আছেন। কোন software self-hosting করার মতো তা নির্ধারণের সময় memory requirement-এর পাশে comparison-এ licence-টিও রাখুন।

আপনার সামনে থাকা machine-এই আপনি এই ইতিহাসের একটি অংশ দেখতে পারেন। Debian বা Ubuntu system-এর প্রতিটি package নিজের শর্তাবলি সঙ্গে বহন করে:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

প্রথম সংখ্যাটি হলো কতগুলো installed package-এ copyright file আছে। ছোট একটি VPS-এ সাধারণত এই সংখ্যা কয়েকশো হয়। দ্বিতীয় command-টি bash-এর copyright file-এর শুরুর অংশ দেখায়। সেখানে GNU General Public License version 3-এর নাম উল্লেখ থাকে। file অনুপস্থিত হলে বোঝায়, package-টি Debian policy অনুযায়ী build করা হয়নি। এটি বিরল, এবং package-টিকে বিশ্বাস করার আগে বিষয়টি আরও একবার পরীক্ষা করা উচিত।

FAQ

মুক্ত সফটওয়্যার এবং open source-এর মধ্যে পার্থক্য কী?

এগুলো প্রায় একই ধরনের লাইসেন্সের আওতায় পড়ে, তবে সেই লাইসেন্সগুলো কেন গুরুত্বপূর্ণ—এ বিষয়ে তাদের মতভেদ আছে। "মুক্ত সফটওয়্যার" পুরোনো শব্দটি 1985 সালে Free Software Foundation থেকে এসেছে। এর যুক্তি নৈতিক: কোনো ব্যবহারকারী প্রোগ্রাম পরিবর্তন করতে না পারলে কম্পিউটারের ওপর তার নিয়ন্ত্রণ থাকে না। "Open source" শব্দটি February 1998-এ প্রচলিত হয়, যাতে একই লাইসেন্সগুলো কোম্পানিগুলোর কাছে সহজে ব্যাখ্যা করা যায়। এর যুক্তি ব্যবহারিক। GPL, MIT, BSD এবং Apache 2.0—সবগুলো লাইসেন্সই উভয় পক্ষের সরকারি তালিকায় রয়েছে। যারা একই সঙ্গে উভয় অর্থ বোঝাতে চান, তারা FOSS বা FLOSS ব্যবহার করেন।

source-available সফটওয়্যার কি open source-এর সমান?

না। source-available অর্থ আপনি কোড পড়তে পারবেন। Open Source Definition অনুযায়ী open source হওয়ার জন্য আরও শর্ত রয়েছে: লাইসেন্সে সফটওয়্যার কে ব্যবহার করতে পারবে বা কী কাজে ব্যবহার করতে পারবে, তা সীমাবদ্ধ করা যাবে না। SSPL এবং Business Source License—উভয়ই প্রতিযোগী বাণিজ্যিক ব্যবহার সীমাবদ্ধ করে। তাই দুটিই source প্রকাশ করলেও ওই সংজ্ঞা অনুযায়ী open source নয়। আপনি যদি শুধু নিজের জন্য self-host করেন, এই সীমাবদ্ধতা আপনার ক্ষেত্রে প্রযোজ্য নাও হতে পারে। তবে এর ওপর ভিত্তি করে কোনো product তৈরি করতে চাইলে আগে লাইসেন্সের শর্তগুলো ভালোভাবে পড়ুন।

কোনো কোম্পানি ইতিমধ্যে দেওয়া open source লাইসেন্স কি প্রত্যাহার করতে পারে?

ইতিমধ্যে প্রকাশ করা কোডের ক্ষেত্রে পারে না। সেই version যে লাইসেন্সের অধীনে প্রকাশ করা হয়েছিল, সেটির অধীনেই থাকে। এই কারণেই Valkey এবং OpenTofu-এর মতো fork শেষ permissively licensed commit থেকে শুরু করতে পেরেছে। কোম্পানি ভবিষ্যৎ version নতুন শর্তের অধীনে প্রকাশ করতে পারে। তবে পুরো project-এর copyright assignment বা contributor licence agreement-এর মাধ্যমে কোম্পানির নিয়ন্ত্রণে থাকলেই এটি সম্ভব। Linux-সহ যেসব project-এর copyright অনেক স্বাধীন copyright holder-এর হাতে, সেগুলোর license অন্য কেউ একতরফাভাবে পরিবর্তন করতে পারে না।

self-hosted সফটওয়্যারে কোন লাইসেন্স খুঁজব?

আপনি নিজে চালাবেন এবং পুনরায় বিক্রি করবেন না—এমন সফটওয়্যারের জন্য GPL, AGPL, MIT বা Apache 2.0-এর মতো যেকোনো OSI-approved licence আপনার প্রয়োজন মেটাবে। আরও গুরুত্বপূর্ণ বিষয় হলো copyright কার হাতে আছে। কারণ পরে আপনার ওপর প্রযোজ্য শর্ত পরিবর্তন করা যাবে কি না, তা এর ওপর নির্ভর করে। কোনো foundation বা অনেক স্বাধীন contributor-এর অধীনে থাকা project-কে ব্যবহারকারীদের বিরুদ্ধে নতুন লাইসেন্সে নেওয়া যায় না। একক vendor-এর project-এ contributor licence agreement থাকলে তা করা সম্ভব। উভয় ধরনের project-ই ভালো সফটওয়্যার হতে পারে। তবে একমাত্র একক vendor-ই নিজের সিদ্ধান্তে নিয়ম পরিবর্তন করতে পারে।