GPL বনাম MIT বনাম Apache: লাইসেন্সের ইতিহাস ও পার্থক্য

GPL বনাম MIT বনাম Apache: প্রতিটি লাইসেন্স আপনার কাছে কী চায়

GPL, MIT এবং Apache 2.0 একই প্রশ্নের ভিন্ন উত্তর দেয়: আপনি সফটওয়্যার অন্যদের কাছে বিতরণ করলে তাদের প্রতি আপনার কী দায়বদ্ধতা থাকে? MIT শুধু copyright notice চায়, আর কিছু নয়। Apache 2.0 ওই notice-এর পাশাপাশি কোডে অবদান রাখা সবার সঙ্গে একটি patent চুক্তি চায়। GPL চায়, আপনি যে সফটওয়্যারের ওপর ভিত্তি করে কিছু তৈরি করেছেন তার source code একই লাইসেন্সের অধীনে প্রকাশ করুন, যে লাইসেন্সে আপনি সফটওয়্যারটি পেয়েছেন।

প্রকল্পের লাইসেন্স পরিবর্তিত হয়ে দুই ভাগে বিভক্ত হওয়ার দিন না আসা পর্যন্ত এটি আইনজীবীদের জন্য একটি প্রশ্ন বলে মনে হতে পারে। এরপর এটি operations-এর প্রশ্ন হয়ে দাঁড়ায়। আপনার বেছে নেওয়ার জন্য দুটি package repository থাকে এবং client library-গুলো একে অপরের সঙ্গে যোগাযোগ বন্ধ করে দেয়। এই গাইডে লাইসেন্স এবং সেগুলোর কার্যপ্রণালি নিয়ে আলোচনা করা হয়েছে, লাইসেন্সগুলো তৈরি করা আন্দোলন নিয়ে নয়। তাই প্রতিটি section শেষ হয় সেই জায়গায়, যেখানে বিষয়টি আপনার ওপর প্রভাব ফেলে: আপনি সেই ব্যক্তি, যাকে upgrade চালাতে হয়।

GPL কেন বিদ্যমান: যে printer কেউ মেরামত করতে পারত না

1980 সালের দিকে MIT Artificial Intelligence Lab একটি Xerox 9700 laser printer পায়। এর আগে ব্যবহৃত একটি printer-এর software-এ lab নিজস্ব পরিবর্তন করেছিল, যাতে print job আটকে গেলে printer সেটি জানাতে পারে। নতুন printer-এর ক্ষেত্রে source code ছিল না, এবং nondisclosure agreement-এর কারণে source code দেওয়ার অনুরোধ প্রত্যাখ্যান করা হয়। তখন lab-এর programmer Richard Stallman এই ঘটনাকে সাময়িক সমস্যা হিসেবে নয়, বরং সাধারণ পরিস্থিতি হিসেবে দেখেন এবং 27 September 1983-এ GNU project ঘোষণা করেন।

Copyleft copyright law-এর ভিত্তির ওপর তৈরি, copyright law-এর বিরোধিতা করে নয়। সাধারণ নিয়মে অন্য কারও code copy করার কোনো অধিকার আপনার থাকে না। GPL একটি শর্তে সেই অধিকার দেয়: আপনি program অন্য কাউকে দিলে একই শর্তে তাকে source code-ও দিতে হবে, যাতে সে সেই কাজ করতে পারে যা lab করতে পারেনি। এই শর্ত কার্যকর করা যায়, কারণ licence ছাড়া শুরুতেই আপনার কোনো অনুমতি ছিল না।

Stallman প্রথমে GNU Emacs-এর জন্য একটি licence লেখেন। পরে সেটিকে সাধারণ রূপ দিয়ে 25 February 1989-এ GPL version 1 তৈরি করেন। GPL version 2 প্রকাশিত হয় June 1991-এ, এবং আপনি যে অধিকাংশ system software ব্যবহার করেন, সেগুলোর licence এখনও এটিই। Library-এর জন্য Lesser GPL তৈরি হয়, যাতে copyleft library যেকোনো licence-এর অধীনে থাকা program-এর সঙ্গে link করা যায়, এবং সেই program-কে GPL-এর আওতায় আনতে না হয়।

GPL self-hoster-এর ওপর কী প্রভাব ফেলবে, তা একটি বিষয় নির্ধারণ করে। বাধ্যবাধকতা use-এর সময় নয়, distribution-এর সময় কার্যকর হয়। আপনি GPL program পরিবর্তন করে নিজের server-এ চালাতে পারেন এবং সেটি দিয়ে public-কে service দিতে পারেন; তবু কারও কাছে আপনার কোনো দায় থাকবে না, কারণ আপনি program-এর কোনো copy বিতরণ করেননি। এই ব্যবধানের কারণেই AGPL বিদ্যমান।

অনুমতিমূলক ধারার বিকাশ: BSD, তারপর MIT

Berkeley ভিন্ন পথ নিয়েছিল। Computer Systems Research Group এমন একটি লাইসেন্সের অধীনে তাদের Unix কাজ প্রকাশ করে, যাতে copyright notice অক্ষুণ্ণ রাখার শর্ত ছিল এবং সব ধরনের warranty অস্বীকার করা হয়েছিল। মূল সংস্করণে চারটি clause ছিল। তৃতীয়টি, অর্থাৎ advertising clause, software-এর বৈশিষ্ট্যের উল্লেখ থাকা সব বিজ্ঞাপন উপকরণে University-এর প্রতি acknowledgement দাবি করত। এই ব্যবস্থা বড় পরিসরে কার্যকর নয়। Stallman NetBSD-এর 1997 সংস্করণে 75টি আলাদা acknowledgement গুনেছিলেন। UC Berkeley 22 July 1999 তারিখে University-এর Office of Technology Licensing-এর William Hoskins-এর একটি চিঠির মাধ্যমে clause-টি প্রত্যাহার করে।

বর্তমানে 3-clause BSD licence-এ মূল লাইসেন্সের সেই নিষেধাজ্ঞা থাকে, যা contributors-এর নাম ব্যবহার করে আপনার product-এর endorsement বোঝাতে বাধা দেয়। 2-clause সংস্করণে এই নিষেধাজ্ঞাটিও বাদ দেওয়া হয়েছে। MIT licence-এর text 1980s-এ MIT থেকে প্রকাশিত হয়েছিল। তখন এটি X Window System-এর জন্য ব্যবহৃত হতো। বাস্তবে এটি 2-clause BSD-এর মতোই কাজ করে।

উদ্দেশ্যগুলো ভিন্ন ছিল। public money-তে অর্থায়িত একটি university চেয়েছিল তার কাজ সর্বত্র ব্যবহৃত হোক, company-গুলোর দ্বারাও। GNU project এমন একটি commons চেয়েছিল, যা বন্ধ করে দেওয়া যাবে না। উভয় অবস্থানই সৎ, এবং উভয়েরই একটি করে ব্যর্থতার দিক আছে। Permissive code ব্যক্তিগতভাবে নিয়ে নেওয়া যেতে পারে, আর তার বিনিময়ে আপনি কিছুই নাও পেতে পারেন। যেসব company-এর lawyer-রা এই শর্ত মেনে নেন না, তারা copyleft code প্রত্যাখ্যান করে।

Berkeley থেকে আরও একটি শিক্ষা পাওয়া যায়। এই post-এ বারবার সেই বিষয়টিতেই ফিরে আসা হয়েছে। AT&T-এর Unix System Laboratories 1992 সালে BSD code নিয়ে Berkeley Software Design-এর বিরুদ্ধে মামলা করে। 1994 সালের শুরুর দিকে মামলাটির নিষ্পত্তি হয়। দুই বছর ধরে BSD-এর ওপর নির্ভর করে development করা নিরাপদ কি না, তা কেউ নিশ্চিতভাবে জানত না। এই সময়ে adoption স্থবির হয়ে পড়ে, আর Linux বিস্তৃত হতে থাকে। কোনো feature না থাকার চেয়ে legal uncertainty দ্রুত adoption থামিয়ে দেয়।

Apache 2.0 কেন patent grant যোগ করেছিল

Apache Group-এর প্রথম licence ছিল BSD 4-clause-এর একটি derivative, যাতে একই advertising সমস্যা ছিল। 2000 সালের Version 1.1-এ ওই clause বাদ দেওয়া হয়। 2004 সালের January-তে প্রকাশিত Version 2.0 কোনো patch নয়, বরং সম্পূর্ণ পুনর্লিখন ছিল।

সবচেয়ে গুরুত্বপূর্ণ সংযোজন হলো patents। MIT এবং BSD licence-এ patents সম্পর্কে একেবারেই কিছু বলা নেই। কোনো contributor তাদের code ব্যবহারের জন্য আপনাকে স্পষ্ট copyright permission দিতে পারেন, কিন্তু একই সঙ্গে এমন একটি patent ধরে রাখতে পারেন, যা ওই code-এর কার্যপ্রণালীর ওপর প্রযোজ্য। এরপর তিনি code ব্যবহারকারীদের বিরুদ্ধে মামলা করতে পারেন। Apache 2.0 এই ফাঁক বন্ধ করে: প্রতিটি contributor তাদের contribution-এর আওতাভুক্ত patent-এর জন্য একটি licence দেন। আর কেউ যদি তাদের patents লঙ্ঘনের অভিযোগে ওই work ব্যবহারকারীর বিরুদ্ধে মামলা করেন, তাহলে ওই work-এর জন্য তিনি নিজের patent licence হারান। এই সুরক্ষা দুই পক্ষের জন্য প্রযোজ্য, তাই বাস্তবে কেউ এমন মামলা করে না।

2.0-এর বাকি অংশ administrative, আর এই কারণেই companies এটি পছন্দ করে। এতে একটি নির্ধারিত NOTICE file আছে, তাই attribution পুরো tree জুড়ে ছড়িয়ে না থেকে এক জায়গায় থাকে। প্রতিটি source file-এ licence-এর সম্পূর্ণ text পেস্ট না করে reference-এর মাধ্যমে licence প্রয়োগ করা যায়। Contributions স্পষ্ট terms-এর আওতায় থাকে। Trademarks এর বাইরে রাখা হয়েছে। কোনো Apache 2.0 dependency-এর legal review করলে text-এর মধ্যেই প্রয়োজনীয় প্রতিটি প্রশ্নের উত্তর পাওয়া যায়। ফলে approval একটি নিয়মিত প্রক্রিয়ায় পরিণত হয়, আর "corporate default" বলতে মূলত এটাই বোঝায়।

GPLv3-এ কী পরিবর্তন হয়েছিল এবং Linux কেন GPLv2-তেই রয়ে গেল

TiVo এমন একটি video recorder বাজারে ছাড়ে, যেটি Linux চালাত এবং GPLv2-এর প্রয়োজন অনুযায়ী kernel source প্রকাশ করত। এরপর hardware boot-এর সময় একটি cryptographic signature যাচাই করত এবং অচেনা kernel চালাতে অস্বীকার করত। আপনি source পড়তে, পরিবর্তন করতে এবং compile করতে পারতেন। কিন্তু যে device-এর জন্য kernel তৈরি হয়েছিল, সেটিতেই তা চালাতে পারতেন না। License-এর আক্ষরিক শর্ত পূরণ হয়েছিল, কিন্তু এর উদ্দেশ্য ব্যর্থ হয়েছিল। এই পদ্ধতি পরে tivoisation নামে পরিচিত হয়।

29 June 2007-এ প্রকাশিত GPL version 3 এই সমস্যার সরাসরি সমাধান দেয়। কোনো consumer device-এর ভিতরে binary বিতরণ করলে আপনাকে "Installation Information" দিতে হবে: modified version install করে সেটি চালানোর জন্য প্রয়োজনীয় key বা নির্দেশনা। Version 3-এ একটি স্পষ্ট patent grant, November 2006-এর Microsoft ও Novell patent agreement-এর প্রতিক্রিয়ায় লেখা শর্ত, এবং Apache 2.0-এর সঙ্গে one-way compatibility-ও যোগ করা হয়।

Linux এই পরিবর্তন গ্রহণ করেনি। Kernel শুধুমাত্র GPL version 2-এর অধীনে প্রকাশিত, এতে "or any later version" শর্ত নেই, এবং এর COPYING file-এ তা স্পষ্টভাবে লেখা আছে। Signed hardware-এর জন্য anti-tivoisation শর্তগুলোর বিরোধিতা Linus Torvalds প্রকাশ্যে করেছিলেন। তবে বাস্তব বাধা এই মতবিরোধের চেয়ে বড়: kernel-এর হাজার হাজার copyright holder আছে। সবাই রাজি হলেও relicence-এর জন্য প্রয়োজনীয় অনুমতিগুলো কেউ একত্র করতে পারত না। কোনো project-এর জন্য এটিই সবচেয়ে শক্তিশালী সুরক্ষা হতে পারে। একক কোনো company-এর মালিকানাধীন project দেখার সময় এই বিষয়টি মনে রাখা গুরুত্বপূর্ণ।

2007 সালের অন্য license-টি আপনার জন্য বেশি গুরুত্বপূর্ণ। একই বছরের November-এ প্রকাশিত GNU Affero GPL version 3 network-এর মাধ্যমে program-এর সঙ্গে যোগাযোগ করা ব্যবহারকারীদের ক্ষেত্রেও source প্রকাশের বাধ্যবাধকতা বাড়ায়। কোনো modified AGPL service জনসাধারণের জন্য চালালে সেই ব্যবহারকারীদের source দিতে হবে। এ কারণেই অনেক self-hosted web software AGPL-এর অধীনে প্রকাশিত হয়। Nextcloud একটি উদাহরণ। আপনি যদি Nextcloud-এর self-hosted বিকল্পগুলো তুলনা করেন, প্রতিটি candidate-এর repository-র license line তার feature list-এর চেয়ে পরবর্তী পাঁচ বছরে project-টির সম্ভাবনা সম্পর্কে বেশি তথ্য দেবে।

কোন কোন লাইসেন্স বাস্তবে একসঙ্গে ব্যবহার করা যায়?

সামঞ্জস্যতা permissive লাইসেন্স থেকে copyleft লাইসেন্সের দিকে একমুখীভাবে কাজ করে।

• MIT এবং BSD-এর অধীনে থাকা code যেকোনো কিছুর সঙ্গে ব্যবহার করা যায়, closed product-এর সঙ্গেও।
• Apache 2.0-এর অধীনে থাকা code GPLv3 প্রকল্পে অন্তর্ভুক্ত করা যায়, এবং সম্মিলিত work-এর লাইসেন্স হয় GPLv3।
• Apache 2.0-এর অধীনে থাকা code GPLv2-only প্রকল্পে অন্তর্ভুক্ত করা যায় না। Apache 2.0-এর patent termination এবং indemnity শর্ত অতিরিক্ত শর্ত হিসেবে গণ্য হয়, যা GPLv2 যোগ করার অনুমতি দেয় না। FSF এবং ASF—উভয়েই এই সিদ্ধান্ত প্রকাশ করেছে।
• আপনি নিজে GPL-এর অধীনে থাকা code-কে permissive লাইসেন্সে স্থানান্তর করতে পারবেন না। এটি কেবল copyright holder-রা করতে পারেন। সেক্ষেত্রে আবার প্রশ্ন ওঠে, copyright holder কারা।

পুনঃলাইসেন্সের যুগ: SSPL, BUSL এবং এগুলো যা নয়

এর পেছনে বাণিজ্যিক কারণ ছিল। একটি কোম্পানি কোনো পণ্যের copyright-এর মালিক, একটি cloud provider সেটিকে বড় পরিসরে managed service হিসেবে বিক্রি করে এবং বিনিময়ে সামান্যই অবদান রাখে, তাই কোম্পানিটি তা বন্ধ করতে licence পরিবর্তন করে। Redis Labs 2018 সালের August-এ প্রথম দৃশ্যমান পদক্ষেপ নেয়। তারা নিজেদের কয়েকটি module-এর ওপর Apache 2.0-এর সঙ্গে Commons Clause যোগ করে। MongoDB 16 October 2018-এ AGPLv3 থেকে Server Side Public License-এ পরিবর্তন করে।

SSPL হলো এমন AGPL, যার একটি section নতুন করে লেখা হয়েছে। আপনি কোনো third party-কে service হিসেবে programটি দিলে, সেটি দেওয়ার জন্য ব্যবহৃত সবকিছুর source প্রকাশ করতে হবে। এর মধ্যে programটির management ও orchestration software-ও অন্তর্ভুক্ত। এই বাধ্যবাধকতার সীমানা স্পষ্ট নয়, এবং কোনো আদালত এটি পরীক্ষা করেনি। OSI licenceটি অনুমোদন করেনি, এবং MongoDB March 2019-এ তাদের application প্রত্যাহার করে। Debian তারও আগে December 2018-এ জানিয়েছিল যে SSPL software তাদের archive-এ থাকা উচিত নয়। Fedora January 2019-এ সিদ্ধান্ত নেয় যে licenceটি free নয়। এরপর Red Hat Fedora এবং Red Hat Enterprise Linux—উভয় জায়গা থেকেই MongoDB বাদ দেয়। পুনঃলাইসেন্সের যান্ত্রিক ফল এটাই: distribution softwareটি package করা বন্ধ করে। ফলে আপনার upgrade এখন vendor repository থেকে vendor-এর নির্ধারিত schedule অনুযায়ী আসে।

Business Source License একটি ভিন্ন ব্যবস্থা। এটি MariaDB-এর founders-দের কাছ থেকে এসেছে, এবং version 1.1-এর তারিখ 2017। এটি copyleft নয় এবং open source-ও নয়। Source public, এবং non-production use বিনামূল্যে। Production use কেবল vendor-এর Additional Use Grant যতটা অনুমতি দেয় ততটাই করা যায়। এই grant সাধারণত competing hosted service চালানো নিষিদ্ধ করে। প্রতিটি release স্বয়ংক্রিয়ভাবে একটি প্রকৃত open source licence-এ রূপান্তরিত হয়। এই পরিবর্তনটি release-এর সর্বোচ্চ চার বছরের মধ্যে নির্ধারিত একটি change date-এ ঘটে। যে licence-এ এটি রূপান্তরিত হবে, সেটি অবশ্যই GPL version 2.0 বা পরবর্তী version হতে হবে, অথবা তার কোনো একটির সঙ্গে compatible licence হতে হবে। HashiCorp 10 August 2023-এ Terraform এবং তাদের অন্যান্য product BUSL 1.1-এ স্থানান্তর করে। Outline-ও এটি ব্যবহার করে। তাই self-hosted Notion-এর বিকল্পগুলো থেকে বেছে নেওয়ার সময় বিষয়টি জানা দরকার: নিজের team-এর জন্য এটি চালানো অনুমোদিত, কিন্তু এর ওপর service তৈরি করা অনুমোদিত নয়।

কোনো licence-ই অসত্ নয়। দুটিই স্পষ্টভাবে বলে যে এগুলো source available। OSI-এর সংজ্ঞা অনুযায়ী কোনোটিই open source নয়। আর এই পার্থক্যের প্রভাব cloud provider-এর বদলে আপনার ওপরই পড়ে, যাকে লক্ষ্য করে licenceগুলো তৈরি করা হয়েছিল।

OpenSearch: একটি লাইসেন্স fork অপারেটরের জন্য কতটা ব্যয়বহুল

Elastic 14 January 2021-এ ঘোষণা করে যে Elasticsearch এবং Kibana Apache 2.0 ত্যাগ করে SSPL অথবা Elastic License-এর যেকোনো একটিতে যাবে। এই পরিবর্তন release 7.11 থেকে কার্যকর হয়। Version 7.10.2 ছিল Apache 2.0-এর অধীনে শেষ release। প্রায় এক সপ্তাহ পরে AWS জানায় যে তারা উভয়ের Apache 2.0 fork তৈরি ও রক্ষণাবেক্ষণ করবে। 12 April 2021-এ forkটির নাম OpenSearch রাখা হয় এবং Kibana-এর নাম বদলে OpenSearch Dashboards করা হয়। OpenSearch 1.0 12 July 2021-এ সাধারণভাবে ব্যবহারের জন্য available হয়; এটি Elasticsearch 7.10.2 এবং Kibana 7.10.2-এর ভিত্তিতে তৈরি হয়েছিল।

Cluster পরিচালনাকারীদের জন্য এর খরচ কী ছিল, তা দেখুন। Package-এর নাম এবং repository পরিবর্তিত হয়। Runbook-এ Kibana-এর প্রতিটি উল্লেখ OpenSearch Dashboards-এ বদলাতে হয়। Plugin-এর নাম পরিবর্তিত হয়। এরপর বিভাজন application code-এ পৌঁছায়: Elastic-এর official client library-এর version 7.13 থেকে client সংযোগের অপর প্রান্তে কী আছে তা পরীক্ষা করে। Elasticsearch ছাড়া অন্য কিছুর সঙ্গে সংযোগ হলে এটি কাজ চালিয়ে যেতে অস্বীকার করে এবং server-কে unknown product হিসেবে জানায়। আপনি যে কোম্পানিতে কাজ করেন না, তাদের একটি লাইসেন্স-সংক্রান্ত সিদ্ধান্ত আপনার নিজের application-এর ভেতরে ব্যর্থ call হিসেবে দেখা দেয়।

এরপর ঘটনাটি আরও দুবার মোড় নেয়। Elastic 29 August 2024-এ ঘোষণা করে যে তারা তৃতীয় লাইসেন্স বিকল্প হিসেবে AGPLv3 যোগ করবে। তাদের licensing FAQ-তে এই সংযোজনের সময় September 2024 বলা হয়েছে। ফলে বর্তমান Elasticsearch আবার OSI-approved open source। 16 September 2024-এ AWS OpenSearch-কে OpenSearch Software Foundation-এ স্থানান্তর করে। Foundationটি Linux Foundation-এর অধীনে পরিচালিত হয়। এর ফলে forkটি কোনো একক কোম্পানির পরিবর্তে একটি governance home পায়। বিভাজনের পাঁচ বছর পর উভয় project-ই open source এবং উভয়টির রক্ষণাবেক্ষণ চলছে। October 2026 অনুযায়ী OpenSearch তার 3.x series-এ রয়েছে।

শেষ ঘটনাটিই মূল শিক্ষা। লাইসেন্স ফিরে এলেও fork থেকে গেল। একটি ecosystem-এ একবার সবকিছুর দুটি করে সংস্করণ তৈরি হলে, কাগজপত্রের পরিবর্তন পূর্বাবস্থায় ফিরিয়ে দিলেই সেগুলো আবার একীভূত হয় না।

একটি relicensing সিদ্ধান্ত কতটা ক্ষতি করবে, তা নির্ধারণ করে vendor-এর ঘোষণা থেকে বাস্তবে deploy করা যায় এমন একটি stable fork পাওয়া পর্যন্ত সময়ের ব্যবধান।

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

নিচের তারিখগুলো ব্যবহার করে প্রতিটি ব্যবধান vendor-এর public announcement থেকে fork-এর প্রথম stable release পর্যন্ত গণনা করা হয়েছে। OpenSearch 1.0 পেতে 179 দিন লেগেছিল। কারণ forkটির নাম পরিবর্তন করতে হয়েছিল এবং অনুকরণ করার মতো কোনো আগের fork ছিল না। OpenTofu পেতে 153 দিন লেগেছিল। Valkey পেতে 27 দিন লেগেছিল। কারণ এটি Redis 7.2.4 fork করে protocol এবং on-disk format অপরিবর্তিত রেখেছিল। গুরুত্বপূর্ণ বিষয় হলো দিকটি: foundation এবং প্রথম দিন থেকেই যুক্ত paid maintainer থাকলে একটি বিশ্বাসযোগ্য fork এখন কয়েক সপ্তাহের মধ্যেই আসে।

Valkey এবং OpenTofu: একই ধারা, আরও দ্রুত

Redis Ltd 20 March 2024-এ Redis-এর licence 3-clause BSD থেকে RSALv2 অথবা SSPLv1-এর যেকোনো একটিতে পরিবর্তন করে। 8 দিন পরে Linux Foundation Valkey ঘোষণা করে। এটি Redis 7.2.4 থেকে fork করা এবং BSD 3-clause licence-এ থাকে। Valkey 7.2.5 16 April 2024-এ প্রকাশিত হয়। এতে একই protocol এবং একই data files ছিল। তাই অধিকাংশ operator-এর জন্য migration বলতে package name পরিবর্তন করাই বোঝায়। পরে May 2025-এ Redis 8-এ তৃতীয় বিকল্প হিসেবে AGPLv3 যোগ করে। OSI-এর সংজ্ঞা অনুযায়ী এতে Redis আবার open source হয়। Valkey অবশ্য নিজস্ব governance-এর অধীনেই থাকে। এই ধারাটি Elasticsearch-এর ঘটনার সঙ্গে খুব মিল।

Terraform একই পথ অনুসরণ করে, তবে এতে একটি অতিরিক্ত অধ্যায় ছিল। OpenTofu সর্বশেষ Mozilla Public License 2.0 release থেকে fork করা হয়, September 2023-এ Linux Foundation-এ যোগ দেয় এবং 10 January 2024-এ 1.6.0 প্রকাশ করে। 3 April 2024-এ HashiCorp-এর আইনজীবীরা project-টিকে cease and desist letter পাঠান। তাঁদের দাবি ছিল, BUSL-licensed Terraform release-এর code fork-এ copy করা হয়েছে। OpenTofu 11 April 2024-এ বিস্তারিত জবাব প্রকাশ করে এবং অভিযোগটি অস্বীকার করে। তারা disputed code-এর উৎস হিসেবে উভয় project-এর অভিন্ন MPL-licensed history দেখায়। প্রকাশ্যে এরপর আর কোনো ঘটনা ঘটেনি। এই ঘটনার আসল ঝুঁকিটি মনে রাখা দরকার: শুধু একটি অভিযোগই এক quarter-এর জন্য adoption থামিয়ে দিতে পারে। 30 বছর আগে Berkeley lawsuit-এর প্রভাবও একই ছিল।

প্রতিটি fork licence পরিবর্তন দিয়ে শুরু হয় না। Gitea-এর development একটি company-এর অধীনে চলে যাওয়ার পরে 2022 সালে Forgejo, Gitea থেকে fork হয়। এটি licensing dispute নয়, governance dispute ছিল। Forgejo তার version 8 series পর্যন্ত MIT licence-এ থাকে। এরপর 2024 সালের version 9.0 থেকে GPLv3 or later licence গ্রহণ করে, যাতে এর work কোনো commercially controlled product-এ ফিরিয়ে নেওয়া না যায়। আপনি যদি self-hosted Git server-এর বিকল্পগুলি বিবেচনা করেন, তাহলে একই codebase এবং দুটি ভিন্ন philosophy-এর সবচেয়ে স্পষ্ট বর্তমান উদাহরণ হলো এই জুটি।

কোনো কিছু গ্রহণ করার আগে যে পরীক্ষা চালাবেন

প্রথম install-এর পরে নয়, তার আগেই চারটি প্রশ্ন করুন।

1. Copyright কার হাতে? Relicensing-এর জন্য প্রতিটি copyright holder-এর অনুমতি প্রয়োজন। তাই শত শত স্বাধীন contributor-সমৃদ্ধ এবং rights assignment না থাকা কোনো project-কে বাস্তবে relicence করা যায় না। একটি company সবকিছুর মালিক হলে board meeting-এ relicence করা সম্ভব।
2. CLA আছে কি, এবং এটি কী অনুমতি দেয়? যে contributor licence agreement company-কে আপনার contribution নিজের ইচ্ছামতো যেকোনো terms-এর অধীনে relicence করার অনুমতি দেয়, উপরের প্রতিটি relicence-এর পেছনে সেটিই মূল mechanism। Linux kernel 2004 সালে গ্রহণ করা sign-off line, অর্থাৎ DCO (developer certificate of origin), কোনো right transfer করে না। কোনো foundation-এর হাতে থাকা CLA, company-এর হাতে থাকা CLA-এর চেয়ে নিরাপদ, কারণ company বিক্রি হয়ে যেতে পারে।
3. Trademark কার মালিকানায়? Elastic Elasticsearch নামটি রেখে দিয়েছিল। তাই fork-কে নতুন নাম নিতে হয়েছিল এবং Kibana-এর উল্লেখ থাকা প্রতিটি runbook পুনরায় লিখতে হয়েছিল।
4. বিশেষভাবে আপনার জন্য relicence-এর খরচ কত হবে? Data format, client library, যে configuration নতুন করে লিখতে হবে এবং ইতিমধ্যে compatible fork আছে কি না—সব হিসাব করুন।

দুটি command কয়েক সেকেন্ডে এর একটি অংশের উত্তর দেয়।

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

প্রতিটি Debian এবং Ubuntu package /usr/share/doc/<package>/copyright-এ একটি file সরবরাহ করে। সেখানে আপনার install করা version-এর licence লেখা থাকে, project বর্তমানে যে licence ব্যবহার করে তা নয়। Ubuntu 24.04-এ bash-এর জন্য ওই file-এ GNU General Public License version 3 লেখা থাকে। দ্বিতীয় command-টি কোনো source checkout-এর ভিতরে চালালে licence file-টির নিজের history দেখতে পাবেন। গত দুই বছরে সেখানে কোনো commit থাকলে project-এর ওপর কিছু build করার আগে সেটি পড়া মূল্যবান। command কোনো output না দিলে repository-তে licence file-এর অন্য নাম আছে। তাই root directory list করে খুঁজে দেখুন।

কোনো licence আপনাকে প্রতিটি outcome থেকে সুরক্ষা দেয় না। শুধু ideology অনুসরণ করে নির্বাচন করলেই মানুষ পরে বিস্মিত হয়। এমন project অগ্রাধিকার দিন যার copyright অনেকের মধ্যে ছড়ানো বা কোনো foundation-এর হাতে আছে। আপনার data এমন format-এ রাখুন যা export করতে পারবেন। এরপর কোন fork-এ যাবেন তা নির্ধারণ করুন এবং প্রয়োজন হওয়ার আগেই নামটি লিখে রাখুন। প্রতিটি candidate-এর ক্ষেত্রে এই পরীক্ষা করতে এক ঘণ্টারও কম সময় লাগে। 2026 সালে কোন বিষয় self host করবেন তা নির্ধারণের সময় এটিই upgrade এবং migration-এর পার্থক্য তৈরি করে।

FAQ

MIT licence কি BSD licence-এর মতোই?

কার্যত, MIT licence 2-clause BSD licence-এর সমতুল্য: copyright notice এবং warranty disclaimer বজায় রাখুন, তারপর ইচ্ছামতো ব্যবহার করুন, এমনকি closed product তৈরি করতেও পারেন। 3-clause BSD licence-এ আরও একটি শর্ত আছে: অনুমতি ছাড়া আপনার product সমর্থন করে এমনভাবে contributors-এর নাম ব্যবহার করা নিষিদ্ধ। পুরোনো 4-clause সংস্করণে advertising material-এ acknowledgement দেওয়ার শর্তও ছিল। UC Berkeley 22 July 1999-এ সেই clause প্রত্যাহার করে। তাই বর্তমান software-এ এটি প্রায় আর দেখা যায় না।

Apache 2.0 code কি GPLv2 project-এ যুক্ত করতে পারি?

না। Apache 2.0 এমন কিছু শর্ত যোগ করে, যা GPLv2 অনুমোদন করে না। এর প্রধান উদাহরণ patent termination clause। তাই combined work একই সঙ্গে উভয় licence-এর শর্ত পূরণ করতে পারে না। FSF এবং ASF উভয়েই এই সিদ্ধান্ত প্রকাশ করেছে। বিপরীত দিকটি কার্যকর: Apache 2.0 code GPLv3 project-এ যুক্ত করা যায়, এবং ফলাফলটি GPLv3 হয়। এই কারণেই Apache 2.0 code Linux kernel-এ merge করা যায় না; Linux kernel শুধুমাত্র GPL version 2-এর অধীনে প্রকাশিত।

SSPL কি open source licence?

না, এবং এর বাস্তব প্রভাব আছে। OSI কখনো SSPL অনুমোদন করেনি। MongoDB March 2019-এ তার application প্রত্যাহার করে। Debian December 2018-এ জানায় যে SSPL software তার archive-এ থাকা উচিত নয়। Fedora January 2019-এ সিদ্ধান্ত দেয় যে licence-টি free নয়। এরপর Red Hat Fedora এবং Red Hat Enterprise Linux থেকে MongoDB বাদ দেয়। এর অর্থ হলো, আপনার distribution আগে যে package maintain করত, সেটি এখন vendor repository থেকে আসে এবং vendor-এর support timetable অনুসরণ করে। Business Source License-ও open source নয়; এটি source available। তবে প্রতিটি release চার বছরের মধ্যে একটি open source licence-এ রূপান্তরিত হয়।

আমি যে version ইতিমধ্যে চালাচ্ছি, licence পরিবর্তন কি তার ক্ষেত্রে প্রযোজ্য?

না। কোনো release-এর সঙ্গে দেওয়া licence ইতিমধ্যে প্রকাশিত copy থেকে প্রত্যাহার করা যায় না। Fork তৈরি করা সম্ভব হওয়ার এটিই মূল কারণ। OpenSearch তৈরি করা হয়েছিল Elasticsearch 7.10.2 থেকে। এটি ছিল Apache 2.0-এর অধীনে Elastic-এর প্রকাশিত শেষ release। আপনি যা হারান, তা হলো ভবিষ্যৎ। কারণ পরবর্তী security fix নতুন শর্তের অধীনে আসবে। সর্বশেষ permissively licensed version pin করে কয়েক মাস সময় পাওয়া যায়। তবে এটি কোনো দীর্ঘমেয়াদি পরিকল্পনা নয়।