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

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

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

প্রকল্প পরিচালনাকারী কোনো software-এর লাইসেন্স পরিবর্তন করে সেটি দুটি অংশে বিভক্ত না হওয়া পর্যন্ত এটি আইনজীবীদের জন্য একটি প্রশ্ন বলে মনে হতে পারে। এরপর এটি operations-এর প্রশ্ন হয়ে দাঁড়ায়। আপনাকে দুটি package repository-এর মধ্যে একটি বেছে নিতে হয়, এবং client library-গুলো একে অপরের সঙ্গে যোগাযোগ বন্ধ করে দেয়। এই guide-এ লাইসেন্স ও সেগুলোর কার্যপদ্ধতি নিয়ে আলোচনা করা হয়েছে, এগুলো তৈরি করা movement নিয়ে নয়। তাই প্রতিটি 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 দাবি করত। এই ব্যবস্থা বড় পরিসরে কার্যকর নয়। 1997 সালের NetBSD-এর একটি সংস্করণে Stallman 75টি আলাদা acknowledgement গণনা করেছিলেন। UC Berkeley 22 July 1999 তারিখে Office of Technology Licensing-এর William Hoskins-এর একটি চিঠির মাধ্যমে এই clause প্রত্যাহার করে।

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

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

Berkeley থেকে আরও একটি শিক্ষা পাওয়া যায়। এই post-এ বারবার সেই শিক্ষার কথাই ফিরে এসেছে। AT&T-এর Unix System Laboratories 1992 সালে BSD code নিয়ে Berkeley Software Design-এর বিরুদ্ধে মামলা করে। 1994 সালের শুরুর দিকে মামলাটির নিষ্পত্তি হয়। দুই বছর ধরে BSD-এর ওপর নির্ভর করে build করা নিরাপদ কি না, তা কেউ নিশ্চিতভাবে জানত না। এই সময় Linux-এর বৃদ্ধি অব্যাহত থাকলেও adoption থমকে ছিল। Missing 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 নতুন করে লেখা হয়েছে। আপনি যদি program-টি third party-দের service হিসেবে দেন, তাহলে তা দেওয়ার জন্য ব্যবহৃত সবকিছুর source publish করতে হবে। এর মধ্যে program-টির management ও orchestration software-ও রয়েছে। এই বাধ্যবাধকতার স্পষ্ট সীমা নেই, এবং কোনো court এটি পরীক্ষা করেনি। OSI licence-টি অনুমোদন করেনি। MongoDB 2019 সালের March-এ তাদের application প্রত্যাহার করে। Debian তার আগেই 2018 সালের December-এ বলেছিল যে SSPL software তাদের archive-এ থাকা উচিত নয়। Fedora 2019 সালের January-এ সিদ্ধান্ত দেয় যে licence-টি free নয়। এরপর Red Hat Fedora এবং Red Hat Enterprise Linux—উভয় স্থান থেকেই MongoDB বাদ দেয়। Relicence-এর সরাসরি ফল এটাই: distribution software-টি package করা বন্ধ করে। ফলে আপনার upgrade এখন vendor-এর repository থেকে এবং vendor-এর schedule অনুযায়ী আসে।

Business Source License একটি ভিন্ন পদ্ধতি। এটি MariaDB-এর founders-দের কাছ থেকে এসেছে, এবং version 1.1-এর সময়কাল 2017। এটি copyleft নয় এবং open source-ও নয়। Source public থাকে। Vendor যে ব্যবহারটি বাদ দেয়, তা ছাড়া ব্যবহার free। সাধারণত বাদ দেওয়া ব্যবহার হলো প্রতিযোগী hosted service চালানো। প্রতিটি release স্বয়ংক্রিয়ভাবে একটি প্রকৃত open source licence-এ রূপান্তরিত হয়। এই পরিবর্তন release-এর সর্বোচ্চ চার বছর পরের কোনো date-এ ঘটে। যে licence-এ রূপান্তর হবে, সেটি GPLv2-compatible হতে হবে। HashiCorp 10 August 2023-এ Terraform এবং তাদের অন্যান্য product BUSL 1.1-এ স্থানান্তর করে। Outline-ও এটি ব্যবহার করে। আপনি যদি self-hosted Notion-এর বিকল্পগুলি থেকে বেছে নেন, তাহলে বিষয়টি জানা দরকার: নিজের team-এর জন্য এটি চালানো অনুমোদিত, কিন্তু এর ওপর ভিত্তি করে service তৈরি করা অনুমোদিত নয়।

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

OpenSearch: একটি লাইসেন্স পরিবর্তনের খরচ অপারেটরের ওপর কতটা পড়ে

Elastic 14 January 2021-এ ঘোষণা করে যে Elasticsearch এবং Kibana Apache 2.0 ছেড়ে SSPL অথবা Elastic License গ্রহণ করবে, যা 7.11 release থেকে কার্যকর হবে। 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 নিজে যাচাই করে যে সেটি কোন পণ্যের সঙ্গে connected হয়েছে। Elasticsearch ছাড়া অন্য কিছুর সঙ্গে connected হলে এটি কাজ চালিয়ে যেতে অস্বীকার করে এবং server-কে unknown product হিসেবে report করে। আপনি যে কোম্পানিতে কাজ করেন না, সেই কোম্পানির একটি licence decision আপনার নিজের application-এর ভেতরে failing call হিসেবে দেখা দিল।

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

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

একটি relicence কতটা ক্ষতি করবে, তা নির্ধারণ করে announcement এবং বাস্তবে 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 অপরিবর্তিত রাখা হয়েছিল। প্রবণতাটিই গুরুত্বপূর্ণ: এখন একটি বিশ্বাসযোগ্য fork কয়েক সপ্তাহের মধ্যেই আসে, এবং প্রথম দিন থেকেই foundation ও paid maintainer যুক্ত থাকে।

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 করে কয়েক মাস সময় পাওয়া যায়। তবে এটি কোনো দীর্ঘমেয়াদি পরিকল্পনা নয়।