০৭ নভে, ২০২৫·8 মিনিট
রিচার্ড স্টলম্যান এবং মুক্ত সফটওয়্যার: কোড বদলে দেয়া ধারণা
রিচার্ড স্টলম্যানের মুক্ত সফটওয়্যার তত্ত্ব, GNU প্রকল্প, ও GPL কীভাবে লাইসেন্সিং, ডেভেলপার অধিকার, এবং ওপেন সোর্সের অবকাঠামো বদলে দিয়েছে তা জানুন।
রিচার্ড স্টলম্যানের মুক্ত সফটওয়্যার তত্ত্ব, GNU প্রকল্প, ও GPL কীভাবে লাইসেন্সিং, ডেভেলপার অধিকার, এবং ওপেন সোর্সের অবকাঠামো বদলে দিয়েছে তা জানুন।
সফটওয়্যার শুধু প্রযুক্তিগত পণ্য নয়—এটি অনুমতিগুলোর একটি সেটও। কে এটি চালাতে পারে, কপি করতে পারে, বন্ধুকে শেয়ার করতে পারে, বাগ ঠিক করতে পারে, বা এর উপরে নতুন কিছু তৈরি করতে পারে? এই প্রশ্নগুলোর উত্তর কোডের চেয়ে লাইসেন্সিং দ্বারা বেশি নির্ধারিত। যখন সফটওয়্যার কাজ, যোগাযোগ, এবং গবেষণার কেন্দ্রবিন্দু হয়ে ওঠে, তখন "আপনি কি করতে পারবেন"—এই নিয়মগুলো বৈশিষ্ট্যের তুলনায় একইভাবে বা বেশি করে উদ্ভাবনকে আকার দিতে শুরু করে।
রিচার্ড স্টলম্যান (প্রায়শই “RMS” বলা হয়) গুরুত্বপূর্ণ কারণ তিনি এই নিয়মগুলোকে অগ্রাহ্য করা কঠিন করে দিয়েছেন। ১৯৮০-এর দশকের শুরুতে তিনি দেখেছিলেন যে একটি পরিবর্তন ঘটছে: বেশি বেশি প্রোগ্রাম সোর্স কোড ছাড়া বিতরণ হচ্ছে, এবং ব্যবহারকারীদের ক্রমে বলা হচ্ছিল যে তারা সফটওয়্যার শুধুমাত্র অন্যের শর্তে ব্যবহার করতে পারবে। স্টলম্যান এটাকে কেবল অপ্রসন্নতা হিসাবে দেখেননি—এটিকে ব্যবহারকারী ও ডেভেলপার স্বাধীনতার ক্ষতি হিসেবে দেখেছেন—এবং তিনি সেই স্বাধীনতাগুলো রক্ষা করার জন্য স্পষ্ট নীতিমালা ও আইনগত সরঞ্জাম প্রস্তাব করেন।
এই লেখাটি স্টলম্যানের ধারণা এবং তাদের ব্যবহারিক পরিণতির ওপর কেন্দ্রীভূত: ফ্রি সফটওয়্যার সংজ্ঞা, GNU Project, কপিলেফ্ট, এবং GNU General Public License (GPL)—এবং কীভাবে এগুলো আধুনিক ওপেন-সোর্স ইকোসিস্টেম ও সফটওয়্যার লাইসেন্সিং নর্মগুলোকে গঠন করেছে।
এটি কোনো জীবনী নয়, এবং না কোনো কার্নেল কম্পাইল বা রেপোজিটরি ম্যানেজমেন্টের প্রযুক্তিগত ডীপ ডাইভার। আপনাকে প্রোগ্রামিং ব্যাকগ্রাউন্ড দরকার হবে না।
স্টলম্যান এই প্রভাবশালী এবং একই সঙ্গে বিতর্কিত। এখানে লক্ষ্য হলো বস্তুনিষ্ঠ ও পাঠযোগ্য থাকা: তিনি কী বলেছিলেন, কী আইনগত যন্ত্রপাতি উদ্ভব হল, ব্যবসা ও ডেভেলপার কিভাবে অভিযোজিত হল, এবং আজ কোথায় বিতর্ক চালিয়ে যাচ্ছে—যাতে আপনি বুঝতে পারেন কেন তার কাজ প্রতিদিনের সফটওয়্যার পছন্দে এখনও প্রভাব ফেলে।
“মুক্ত সফটওয়্যার” ভুলভাবে বোঝা সহজ কারণ মুক্ত শব্দটি দাম বোঝায় এমন ভুল ধারনা দেয়। রিচার্ড স্টলম্যান মুক্ত শব্দটি ব্যবহার করেছেন স্বাধীনতা বোঝাতে—ব্যবহারকারীর ক্ষমতা যাতে তারা তাদের নির্ভর সফটওয়্যার নিয়ন্ত্রণ করতে পারে।
যদি একটি প্রোগ্রাম $0 কিন্তু আপনাকে তা পরিদর্শন, পরিবর্তন বা শেয়ার করতে না দেয়া হয়, তা এখনও “বিনামূল্যে” হতে পারে কিন্তু স্টলম্যানের দৃষ্টিকোণে এটি অমুক্ত।
মুক্ত সফটওয়্যারকে চারটি মৌলিক অনুমতির দ্বারা সংজ্ঞায়িত করা হয়:
এই স্বাধীনতাগুলো এজেন্সির ব্যাপার: আপনি কেবল টুলের ভোক্তা নন—আপনি অংশগ্রহণকারী হয়ে উঠতে পারেন, যাচাই, অভিযোজন এবং উন্নতি করতে পারবেন।
Freedom 1 ও 3 সোর্স কোড অ্যাক্সেস ব্যতীত অসম্ভব—মানব-পাঠ্য নির্দেশাবলী ছাড়া এটি করা যায় না। সোর্স ব্যতীত সফটওয়্যারটি封印কৃত যন্ত্রের মতো: আপনি এটি ব্যবহার করতে পারেন, কিন্তু আপনি বুঝতে পারেন না এটি কী করছে, ভেঙে গেলে মেরামত করতে পারেন না, বা নতুন প্রয়োজনের জন্য মানিয়ে নিতে পারেন না।
সোর্স কোড অ্যাক্সেস বিশ্বাসযোগ্যতার জন্যও জরুরি। এটি স্বাধীন পর্যালোচনার সুযোগ দেয় (গোপনীয়তা, নিরাপত্তা, ও ন্যায্যতার জন্য) এবং মূল ডেভেলপার আর সহায়তা না দিলেও সফটওয়্যার মেইনটেইন করা সম্ভব করে তোলে।
একটি রেস্তোরাঁর খাবারের কথা ভাবুন।
এটাই মূল ধারণা: মুক্ত সফটওয়্যার হল ব্যবহারকারীদের প্রয়োজনীয় স্বাধীনতাগুলো যাতে তারা তাদের কম্পিউটিংয়ের উপর নিয়ন্ত্রণ রাখতে পারে।
“সফটওয়্যার লাইসেন্সিং” যখন সবাই ততটা আলোচনা করত না, তখন অনেক প্রোগ্রামিং সংস্কৃতি—বিশেষত বিশ্ববিদ্যালয় ও গবেষণা ল্যাবগুলো—একটি ধরন চালাত: যদি আপনি টুল উন্নত করতে পারেন, আপনি উন্নতি শেয়ার করতেন। সোর্স কোড সফটওয়্যারটির সাথে যেত, মানুষ একে অপরের কাজ পড়ে শিখত, এবং সমস্যা সমাধানগুলি অর্চিতভাবে ছড়িয়ে পড়ত।
এই সংস্কৃতি বদলে যেতে শুরু করে যখন সফটওয়্যার নিজে একটি পণ্য হিসেবে গুরুত্বপূর্ণ হতে থাকে। কোম্পানি ও কিছু প্রতিষ্ঠান সোর্স কোডকে প্রতিযোগিতামূলক সুবিধা হিসেবে গণ্য করতে শুরু করে। বিতরণে “শেয়ার করা যাবে না” শর্ত আসে, কোড প্রোগ্রামের সঙ্গে আর পাঠানো হয় না, এবং গোপনীয়তা চুক্তি স্বাভাবিক হয়ে ওঠে। যে ডেভেলপাররা সাধারণত সমষ্টিগতভাবে সমস্যা সমাধান করত, তাদের জন্য এই পরিবর্তন কেবল অপ্রসন্নতা ছিল না—এটি এমন একটি নিয়ম পরিবর্তন মনে হচ্ছিল যা কমিউনিটি সমস্যার সমাধানকে আইনিভাবে ঝুঁকিপূর্ণ করে তুলছিল।
একটি প্রসিদ্ধ শুরুর গল্প MIT-এর AI ল্যাবের একটি প্রিন্টার নিয়ে। স্টলম্যান বর্ণনা করেছেন যে একটি নতুন প্রিন্টার এসেছে যার সফটওয়্যার শুধুমাত্র বাইনারি রূপে বিতরণ করা হয়েছিল, সোর্স ছাড়া। ব্যবহারিক সমস্যাটি সাধারণ ছিল: ল্যাবটি চাইছিল প্রোগ্রামটি মডিফাই করা যেন জ্যাম এলে ব্যবহারকারীদের জানায় বা কাজগুলো আরও বুদ্ধিমত্তার সাথে রুট করে। পুরনো "হ্যাকার" নিয়মে কেউ কোডটি প্যাচ করে এবং ফিক্স শেয়ার করে দিতো। এখানে তারা পারল না—কারণ তারা সোর্স দেখতে বা বদলাতে পারছিল না।
এটি এক প্রিন্টারই নয় যে এককভাবে বৈশ্বিক আন্দোলন সৃষ্টি করেছিল; বরং এটি একটি পরিষ্কার, সম্পর্কযোগ্য উদাহরণ ছিল বৃহত্তর প্রবণতার—যেখানে মানুষ নির্ভরশীল যন্ত্রগুলো ব্যবহারকারীদের দ্বারা ঠিক করা সম্ভব হচ্ছে না।
স্টলম্যানের কাছে মূল সমস্যা কেবল প্রযুক্তিগত অ্যাক্সেস ছিল না; এটা সহযোগিতা করার স্বাধীনতার ক্ষতি ছিল। যদি আপনি একটি প্রোগ্রাম কিভাবে কাজ করে তা পড়তে না পারেন, আপনি সত্যিই এটি নিয়ন্ত্রণ করতে পারবেন না। যদি আপনি উন্নতি শেয়ার করতে না পারেন, কমিউনিটিগুলো বিচ্ছিন্ন হয়ে পড়ে, এবং প্রত্যেকে একে অপরকে ব্যক্তিগতভাবে ফিক্স করে নতুন করে আবিষ্কার করতে বাধ্য হয়।
এই অনুপ্রেরণাই পরে যে লাইসেন্সিং উদ্ভাবনগুলোকে রূপ দিল—স্টলম্যান চাইছিল এমন নিয়ম যা ব্যবহার, অধ্যয়ন, পরিবর্তন, এবং শেয়ার করার ক্ষমতা সংরক্ষণ করে—তাই সহযোগিতা বাণিজ্যিক মূল্য অর্জন করার সঙ্গে সঙ্গে প্রত্যাহার করা যাবে না।
স্টলম্যানের বড় পদক্ষেপ কেবল ম্যানিফেস্টো লেখা ছিল না—এটি একটি ব্যবহারিক প্রকৌশল প্রচেষ্টা শুরু করা। ১৯৮৩ সালে তিনি GNU Project ঘোষণা করেন, উদ্দেশ্য ছিল স্পষ্ট ও দামী: একটি সম্পূর্ণ অপারেটিং সিস্টেম বানানো যা কেউ ব্যবহার, অধ্যয়ন, পরিবর্তন, এবং শেয়ার করতে পারবে, এবং Unix-সঙ্গত হতে হবে যাতে পরিচিত প্রোগ্রাম ও ওয়ার্কফ্লো চলতে পারে।
একটি অপারেটিং সিস্টেম একটাই প্রোগ্রাম নয়—এটি পুরো স্ট্যাক। GNU সেট করল প্রতিদিনের কাজে প্রয়োজনীয় সব উপাদান তৈরি করার লক্ষ্য:
সরল কথায়: GNU প্লাম্বিং, ওয়্যারিং, এবং সুইচগুলো তৈরি করছিল—শুধু একটি যন্ত্র নয়।
১৯৯০-এর দশকের শুরুতে GNU অনেক অংশ তৈরি করেছিল, কিন্তু একটি গুরুত্বপূর্ণ অংশ পিছিয়ে ছিল: কর্নেল (যা সরাসরি হার্ডওয়্যার ও সিস্টেম রিসোর্স ম্যানেজ করে)। ১৯৯১ সালে Linux আবির্ভাব হল, এবং সেটি সেই গ্যাপকেই পূরণ করে।
এই কারণেই আজকের বহু জনপ্রিয় সিস্টেমে GNU উপাদান এবং Linux kernel মিলিয়ে দেখা যায়—প্রায়ই “GNU/Linux” বলা হয়।
GNU মুক্ত সফটওয়্যার ধারণাটিকে বাস্তবে পরিণত করেছিল একটি কার্যকর বেস দিয়ে যার ওপর অন্যেরা তৈরি করতে পারে। দার্শনিকতা দেখায় কেন স্বাধীনতা গুরুত্বপূর্ণ; GNU সেই টুলসগুলো পৌঁছে দিল যা স্বাধীনতাকে ব্যবহারিক, পুনরাবৃত্ত, এবং স্কেলেবল করে তোলে।
কপিলেফ্ট এমন একটি লাইসেন্স কৌশল যা সফটওয়্যারকে মুক্ত রেখে ভবিষ্যত সংস্করণগুলিকেও স্বাধীন রাখার চেষ্টা করে। যদি আপনি কপিলেফ্টকৃত কোড পান, আপনি সেটি ব্যবহার, অধ্যয়ন, পরিবর্তন, এবং শেয়ার করতে পারবেন—কিন্তু যখন আপনি আপনার পরিবর্তিত সংস্করণ বিতরণ করবেন, আপনাকে একই স্বাধীনতাগুলো অন্যদেরও দিতে হবে।
কপিলেফ্ট শুনলে মনে হতে পারে “অ্যান্টি-কপিরাইট”, কিন্তু এটি আসলে কপিরাইট আইনের উপর নির্ভর করে। লেখক তার কপিরাইট ব্যবহার করে লাইসেন্সে অনুমতির শর্ত রাখে: “আপনি এটি কপি ও পরিবর্তন করতে পারেন, কিন্তু যদি আপনি পুনর্বিতরণ করেন, আপনাকে একই লাইসেন্সে রাখতে হবে।” কপিরাইট না থাকলে এই শর্তগুলো কার্যকর করার আইনি উপায় হত না।
এটি কোডের সঙ্গে চলমান একটি নিয়ম:
লক্ষ্য হলো সেই ধারা আটকানো যাকে স্টলম্যান চিন্তা করতেন: কেউ কমিউনিটি কাজ নিয়ে তা উন্নত করে তারপর ঐ উন্নতিটা লক করে রাখে।
পারমিসিভ লাইসেন্স (MIT বা BSD মত) সাধারণত আপনাকে প্রায় যে-কিছু করতেও দেয়—এমনকি পরিবর্তিত সংস্করণগুলোকে ক্লোজড, প্রোপাইটারি লাইসেন্সে পুনর্বিতরণ করাও সম্ভব। কপিলেফ্ট লাইসেন্স (উদাহরণ GPL) বিস্তৃত ব্যবহার ও পরিবর্তনকে অনুমোদন করে, কিন্তু পুনর্বিতরণে অনুচ্ছিন্নভাবে একই শর্ত বজায় রাখতে বলে—তাই downstream-এ স্বাধীনতা সংরক্ষিত থাকে।
GNU General Public License (GPL) সফটওয়্যার লাইসেন্সিং পরিবর্তন করেছে কারণ এটি “শেয়ারিং”-কে একটি প্রয়োগযোগ্য নিয়মে রূপান্তর করে, কেবল সৌহার্দ্য নয়। GPL-এর আগে আপনি সোর্স পেয়ে তা উন্নত করে পরে ক্লোজড ভার্সনে পাঠাতে পারতেন। GPL উল্টে দেয় সেই গতিবিধি: এটি পুনর্বিতরণে শর্ত আরোপ করে ব্যবহারকারীর স্বাধীনতাকে রক্ষা করে।
প্রায়োগিকভাবে, GPL ব্যবহারকারীদের প্রোগ্রাম যেকোনো উদ্দেশ্যে চালানোর, সোর্স পড়ার ও পরিবর্তন করার, এবং মূল বা পরিবর্তিত সংস্করণগুলো শেয়ার করার অধিকার দেয়।
আপনি যদি GPL সফটওয়্যার পুনর্বিতরণ করেন (বিশেষত কোনো পণ্যে বা গ্রাহকের কাছে শিপ করেন), আপনাকে সাধারণত:
GPL বাধ্যবাধকতা প্রধানত তখন ট্রিগার করে যখন আপনি সফটওয়্যার অন্যদের কাছে বিতরণ করেন—বাইনারি শিপ করা, ডিভাইসে সফটওয়্যার ইনস্টল করে বিক্রি করা, বা গ্রাহকদেরকে কপি দেয়া। যদি আপনি GPL কোড ব্যক্তিগত অভ্যন্তরীণ ব্যবহারের জন্য পরিবর্তন করেন এবং তা বিতরণ না করেন, সাধারণত সোর্স প্রকাশ বাধ্যতামূলক হয় না।
আইনি তত্ত্ব না জানলেও ধারণা পাওয়া যায়: যদি আপনার প্রোগ্রাম GPL কোডকে এমনভাবে অন্তর্ভুক্ত করে বা লিঙ্ক করে যে একটি যৌথ কাজ সৃষ্টি হয় (উদাহরণস্বরূপ, আপনার অ্যাপ্লিকেশনে সেটি লিঙ্ক করা), তবে ফলাফল সাধারণত ডেরিভেটিভ ওয়ার্ক ধরা হয় এবং GPL-এ বিতরণ করতে হবে। কেবল একটি GPL প্রোগ্রাম চালানো, বা স্ট্যান্ডার্ড ইন্টারফেসে আলাদাভাবে প্রসেসের সঙ্গে কথা বলা, প্রায়শই আলাদা বিবেচিত।
মুক্ত লাইসেন্সগুলো (বিশেষত GNU GPL) কেবল শেয়ারিং “অনুমোদন” করে না—এসব ব্যবহারকারীদের পড়ার, পরিবর্তনের, এবং পুনর্বিতরণের অধিকার এমনভাবে রক্ষা করে যা পরবর্তী ধাপে সহজে ফিরিয়ে নেওয়া যায় না। ডেভেলপারদের জন্য এর মানে হলো আপনার উন্নতিগুলো অন্যান্যদের কাছে একই শর্তে উপলব্ধ থাকতে পারে, কোনো ক্লোজড প্রোডাক্টে গিলেূ খেয়ে ফেলা হবে না।
GPL-এর আওতায় আপনি পারবেন:
একারণে GPL প্রায়ই “প্রয়োগযোগ্য প্রতিদান” বলে বর্ণিত হয়। যদি কেউ GPL-আচ্ছাদিত প্রোগ্রাম (বা ডেরিভেটিভ) বিতরণ করে, তারা downstream ব্যবহারকারীদের একই ধরনের পরিবর্তন ও শেয়ারিং থেকে বঞ্চিত করতে পারবে না।
এই অধিকারগুলোর সঙ্গে কিছু বাধ্যবাধকতা আসে যখন আপনি বিতরণ করেন:
এই দায়িত্বগুলো “জটিলতা” নয়—এগুলোই সহযোগিতাকে একপলারোপে পরিণত হতে দেয় না।
টিমগুলোকে লাইসেন্স কমপ্লায়েন্সকে রিলিজ হাইজিনের মতো দেখলে ভালো। ট্র্যাক করুন:
একটি সাধারণ SBOM এবং রিলিজ চেকলিস্ট আইনজীবীর কাছে যাওয়ার আগে বেশিরভাগ সমস্যা প্রতিরোধ করতে পারে।
কোড স্তরে, “মুক্ত সফটওয়্যার” ও “ওপেন সোর্স” প্রায়ই একই প্রকল্পগুলোর বর্ণনা করে। বিভাজনটি প্রধানত কেন শেয়ারিং গুরুত্বপূর্ণ সেটাতে।
ফ্রি সফটওয়্যার আন্দোলন (রিচার্ড স্টলম্যান ও Free Software Foundation-এর সঙ্গে যুক্ত) সফটওয়্যার স্বাধীনতাকে নৈতিক ইস্যু হিসেবে দেখে: ব্যবহারকারীদের চালানো, পড়া, পরিবর্তন, এবং শেয়ার করার অধিকার থাকা উচিত। উদ্দেশ্য কেবল ভাল ইঞ্জিনিয়ারিং নয়—ব্যবহারকারীর স্বায়ত্তশাসন রক্ষা করা।
ওপেন সোর্স পন্থা ব্যবহারিক ফলাফলকে গুরুত্ব দেয়: ভালো সহযোগিতা, দ্রুত পুনরাবৃত্তি, কম বাগ, এবং স্বচ্ছতার মাধ্যমে উন্নত নিরাপত্তা। এটি এই ধারণাকে ব্যবসায়িকভাবে উপস্থাপন করতে স্বাচ্ছন্দ্যবোধ করে, কিন্তু নৈতিক দৃষ্টিকোণটি চাপ দেয় না।
১৯৯৮ সালে Open Source Initiative (OSI) “open source” টার্মকে প্রচলিত করে যাতে ধারণাটি ব্যবসা-বান্ধব হয়। “Free software” প্রায়শই ভুল হয়ে বোঝা হত “শূন্য মূল্য”, এবং কিছু কোম্পানি অধিকার ও নৈতিকতার কথা বললে সন্দিহান ছিল। “Open source” প্রতিষ্ঠানগুলোকে বলে দেয় “আমরা এভাবে কাজ করতে পারি”—একটু কম আদর্শিক সংবাদ সহ।
অনেক প্রকল্প যে নিজেকে ওপেন সোর্স বলে সেগুলোই GNU GPL বা অন্যান্য কপিলেফ্ট লাইসেন্স ব্যবহার করে, আবার অনেকে MIT বা Apache মতো পারমিসিভ লাইসেন্স বেছে নেয়। আইনি টেক্সট একই থাকতে পারে; কন্ট্রিবিউটর, ব্যবহারকারী, ও গ্রাহকদের কাছে যে গল্পটি বলা হয় তা আলাদা। একটি বার্তা হচ্ছে “এটি আপনার স্বাধীনতা রক্ষা করে,” আর অন্যটি হচ্ছে “এটি গ্রহণযোগ্যতা বাড়ায় এবং গতি বাড়ায়।”
মুক্ত সফটওয়্যার মানে “কেউ অর্থ প্রদানে পাবে না” নয়। এর মানে হলো ব্যবহারকারীরা সফটওয়্যার চালাতে, পড়তে, পরিবর্তন ও শেয়ার করতে স্বাধীন থাকেন। অনেক কোম্পানি সেই স্বাধীনতার ওপর ভিত্তি করে সুস্থ আয় তৈরি করে—প্রধানত যেগুলো প্রতিষ্ঠানের জন্য মূল্যবান: নির্ভরযোগ্যতা, জবাবদিহিতা, এবং সময়।
কয়েকটি সাধারণ, প্রমাণিত মডেল:
একটি আধুনিক মোড় হলো প্ল্যাটফর্ম যা দ্রুত অ্যাপ বানায় ও চালায়—উদাহরণস্বরূপ, Koder.ai একটি ভイブ-কোডিং প্ল্যাটফর্ম যা টিমকে চ্যাটের মাধ্যমে ওয়েব, ব্যাকএন্ড, ও মোবাইল অ্যাপ তৈরিতে সাহায্য করে—ইতিমধ্যে সোর্স কোড এক্সপোর্ট সাপোর্ট করে। দ্রুত পুনরাবৃত্তি + কোড মালিকানা—এই সংমিশ্রণ সফটওয়্যার স্বাধীনতার নীতির সাথে ভালভাবে মিলে যায়: যখন দরকার তখন কোড পরীক্ষা, বদলানো, এবং সরানো যায়।
লাইসেন্স পছন্দ মূল্য ধরা কারোর ওপর প্রভাব ফেলে:
“বাণিজ্যিক” মানে কীভাবে বিক্রি হচ্ছে; “মুক্ত সফটওয়্যার” মানে ব্যবহারকারীর অধিকার কী। একটি কোম্পানি মুক্ত সফটওয়্যার বিক্রি করতে পারে, সাপোর্টের জন্য চার্জ করতে পারে, এবং তবু সফটওয়্যার স্বাধীনতা সম্মান করতে পারে।
কোনো FOSS প্রকল্পে নির্ভর করার আগে জিজ্ঞেস করুন:
GPL এবং “FOSS” নিয়ে প্রচুর আলোচনা হয়, কিন্তু কয়েকটি বারবার ওঠা মিথ সামঞ্জস্য নষ্ট করে—বিশেষত টিমগুলোর জন্য যারা কেবল প্রোডাক্ট শিপ করতে চায়।
না। পাবলিক ডোমেইন মানে কোনো কপিরাইট মালিক নেই—কোনো শর্ত ছাড়াই কেউই কাজটি ব্যবহার করতে পারে।
GNU GPL ঠিক উল্টো: লেখক কপিরাইট বজায় রাখে এবং বড় ধরনের অনুমতি দেয়, কিন্তু শর্ত হিসেবে GPL-এর শর্ত মানতে হবে (বিশেষ করে সোর্স শেয়ারিং যখন বাইনারি বিতরণ করা হয়)।
কোড দেখা যায় বলে তা সিকিউর হবে এমন নয়। একটি প্রকল্প ওপেন সোর্স হলেও তা:
নিরাপত্তা আসে সক্রিয় রক্ষণাবেক্ষণ, অডিট, রেসপনসিবল ডিসক্লোজার, এবং ভালো অপারেশনাল অনুশীলন থেকে—লাইসেন্স লেবেল থেকে নয়।
মানুষ প্রায়ই GPL-কে “ভাইরাল” বলে—অর্থাৎ এটি সবকিছুকে ছড়িয়ে দেয়। এটা একটি লোডড মেটাফর।
অধিকাংশ ক্ষেত্রেই এটি নির্দেশ করে কপিলেফ্ট: যদি আপনি GPL কোডের ডেরিভেটিভ বিতরণ করেন, আপনাকে সংশ্লিষ্ট সোর্স GPL-এ দিতে হবে। এই বাধ্যবাধকতা ইচ্ছাকৃত—এটি downstream স্বাধীনতাগুলো সংরক্ষণ করে। এটি “সংক্রমণ” নয়; এটি একটি শর্ত আপনি গ্রহণ বা এড়িয়ে যেতে পারেন।
নির্ধারক মূলনীতিঃ বাধ্যবাধকতা প্রধানত বিতরণে ট্রিগার হয়।
যখন এটা গুরুত্বপূর্ণ হয়, কোড কিভাবে সংযুক্ত ও বিতরণ হচ্ছে তা নির্দিষ্ট করে আইনগত পর্যালোচনা নেবেন—শুধু অনুমান করবেন না।
রিচার্ড স্টলম্যান একটি বিতর্কিত ব্যক্তি। এটিকে স্বীকার করে কথা বলা সম্ভব—এবং এখনও তাঁর ধারনাগুলোর স্থায়ী প্রভাব নিয়ে আলোচনা করা উচিত।
একটি উপযোগী শুরু হল দুইটি আলাদা কথোপকথনকে আলাদা করা: (1) স্টলম্যান একজন ব্যক্তি এবং কমিউনিটি সদস্য হিসেবে বিতর্কিত—এই বিষয়ে বিতর্ক, ও (2) মুক্ত সফটওয়্যার নীতির, GNU Project-এর, এবং GNU GPL-এর পরিমাপযোগ্য প্রভাব—লাইসেন্সিং ও ডেভেলপার অধিকারগুলোর ওপর। দ্বিতীয়টি প্রাথমিক উৎস (লাইসেন্স টেক্সট, প্রকল্প ইতিহাস, গ্রহণের প্যাটার্ন) দিয়ে আলোচনা করা যায় এমনকি ব্যক্তিগত বিতর্ক থাকলেও।
একটি বারবার ওঠা সমালোচনা লাইসেন্সের কথা নয়, বরং গভর্ন্যান্স সম্পর্কে: প্রকল্পগুলো কীভাবে সিদ্ধান্ত নেয়, কার কি কর্তৃত্ব, এবং যখন প্রতিষ্ঠাতা, মেইনটেইনার, ও ব্যবহারকারীরা ভিন্ন মত পায় তখন কী হয়। মুক্ত সফটওয়্যার কমিউনিটিগুলো প্রশ্নগুলো নিয়ে লড়াই করেছে:
এই প্রশ্নগুলো গুরুত্বপূর্ণ—লাইসেন্স আইনি শর্ত দেয়, কিন্তু স্বাস্থ্যকর সিদ্ধান্ত গ্রহণ নিজেরে তৈরি করে না।
আরেকটি চলমান বিতর্ক ইনক্লুসিভিটি ও কমিউনিটি নর্ম নিয়ে: প্রాజেক্টগুলো কিভাবে সম্মানজনক আচরণের প্রত্যাশা সেট করে, কিভাবে সংঘাত সামলায়, এবং নতুনদের জন্য কতটা স্বাগত। কিছু কমিউনিটি আনুষ্ঠানিক কন্ডাক্ট কোড জোর দেয়; অন্যরা ন্যূনতম নিয়ম ও অনানুষ্ঠানিক মধ্যস্থতাকে পছন্দ করে। কোন পদ্ধতিই স্বয়ংক্রিয়ভাবে “সঠিক” নয়, কিন্তু ট্রেড-অফগুলো বাস্তব এবং ব্যক্তিগত আক্রমণ ছাড়া আলোচনায় রাখা উচিত।
স্টলম্যানের উত্তরাধিকারের মূল্যায়ন করলে সাহায্য করে যদি দাবি গুলো যাচাইযোগ্য রাখা হয়: GPL কী চায়, কপিলেফ্ট কীভাবে কমপ্লায়েন্স অনুশীলন বদলে দিয়েছে, এবং এই ধারণাগুলো পরবর্তীকালে কী লাইসেন্স ও প্রতিষ্ঠানকে প্রভাবিত করেছে। আপনি সমালোচক, সমর্থক, বা অনির্ণীত হতেই পারেন—কিন্তু নির্ভুলতা, সম্মান, এবং স্পষ্টতা বজায় রাখুন কী সম্পর্কে আলোচনা হচ্ছে।
স্টলম্যানের সবচেয়ে বড় ব্যবহারিক উপহারটি হলো একটি সরল প্রশ্ন: আপনি downstream-এ কোন স্বাধীনতাগুলো নিশ্চিত করতে চান? এটি উত্তর দিলে লাইসেন্স পছন্দকে একটি সিদ্ধান্তে পরিণত করে।
আপনি অনিশ্চিত হলে লক্ষ্য অনুযায়ী সিদ্ধান্ত নিন: গ্রহণযোগ্যতা (পারমিসিভ) বনাম প্রতিদান (কপিলেফ্ট) বনাম লাইব্রেরি-বান্ধব প্রতিদান (দুর্বল কপিলেফ্ট)।
LICENSE ফাইল রাখুন (পূর্ণ লাইসেন্স টেক্সট কপি করুন)।AI-সহায়তায় (চ্যাটভিত্তিক প্ল্যাটফর্মসহ) ডেভেলপ করলে এই চেকলিস্টটি আরও বেশি জরুরি: আপনি বাস্তবে নির্ভরশীল উপাদান শিপ করছেন, বাস্তবে আর্টিফ্যাক্ট শিপ করছেন, এবং বাস্তবে লাইসেন্সাল বাধ্যবাধকতা রয়েছে। গতি দায়িত্বকে বিলুপ্ত করে না—বরং পুনরায় ব্যবহারযোগ্য কমপ্লায়েন্স রুটিন বিশেষ মূল্য রাখে।
এটি বিরক্তিকর এবং পুনরাবৃত্তিমূলক করুন:
গভীর তুলনাগুলোর জন্য দেখুন /blog/choosing-an-open-source-license এবং /blog/gpl-vs-mit-vs-apache.
“মুক্ত সফটওয়্যার” মানে স্বাধীনতা, দাম নয়.
একটি প্রোগ্রাম যদি $0 দামে পাওয়া যায় তাও হতে পারে অমুক্ত যদি আপনি সেটি পরীক্ষা, পরিবর্তন বা শেয়ার করতে না পারেন। মুক্ত সফটওয়্যার ফোকাস করে সেই অধিকারগুলোর ওপর: চালানো, পড়া, বদলানো, এবং পুনর্বিতরণ।
সংজ্ঞাটি চারটি মূল অনুমতির ওপর দাঁড়ায়:
যদি এসবের কোনোটি না থাকে, ব্যবহারকারীরা নিয়ন্ত্রণ হারান এবং সহযোগিতা কঠিন হয়ে পড়ে।
কারণ আপনি বাস্তবে সফটওয়্যার পড়তে বা বদলাতে পারবেন না যদি সোর্স কোড না থাকে.
সোর্স কোড অ্যাক্সেস থেকে পাওয়া সুবিধা:
কপিলেফ্ট কপিরাইট আইন ব্যবহার করে “শেয়ার-এলাইকের” একটি নিয়ম বসায় যখন আপনি পুনর্বিতরণ করেন.
আপনি ব্যবহার, পরিবর্তন, এমনকি বিক্রি করতে পারেন, কিন্তু যদি আপনি পরিবর্তিত সংস্করণ বিতরণ করেন, তাহলে আপনাকে প্রাপকদের একই স্বাধীনতা দিতে হবে (সাধারণত ওই সোর্স একই লাইসেন্সে রিলিজ করে)।
GPL ব্যবহারকারীদের বিস্তৃত অধিকার দেয় (চালানো, পড়া, পরিবর্তন, শেয়ার) এবং বিনিময়ে বিতরণে reciprocity চায়.
আপনি যদি GPL-আধারিত বাইনারি বিতরণ করেন, সাধারণত আপনাকে করতে হবে:
সাধারণত, না.
GPL-এ বাধ্যবাধকতা প্রায়শই বিতরণ-এর সময় ট্রিগার হয়। যদি আপনি GPL কোড নিজে ব্যবহার করে ভিতরে পরিবর্তন করেন এবং তা বাইরে কাউকে না দেন, সাধারণত আপনাকে তা প্রকাশ করতে হয় না.
(পার্থক্যভিত্তিক কেস আছে—এটি সাধারণ নীতি, আইনগত পরামর্শ নয়।)
এটি নির্ভর করে কোড কীভাবে জুড়েছে বা ব্যবহৃত হয়েছে।
সাধারণত:
যখন গুরুত্বপূর্ণ, তখন প্রকৃত ইন্টিগ্রেশন প্যাটার্ন নির্দিষ্ট করে নেবেন।
তারা বিভিন্ন উদ্বেগ লক্ষ্য করে:
আপনি কি চান: শক্তিশালী reciprocity (GPL) নাকি লাইব্রেরি-বান্ধব reciprocity (LGPL) — সেই অনুযায়ী বেছে নেবেন।
প্রায়ই নয়।
GPL অনুসারে, যদি আপনি সার্ভারে GPL সফটওয়্যার চালান এবং ব্যবহারকারীরা নেটওয়ার্কের মাধ্যমে শুধু ইন্টারঅ্যাক্ট করে, সাধারণত আপনি “বিতরণ” করেন না, তাই সোর্স-শেয়ারিং বাধ্যবাধকতা ট্রিগার হয় না.
আপনি যদি নেটওয়ার্ক-আধারিত ব্যবহারেও সোর্স শেয়ার বাধ্যতামূলক করতে চান, তাহলে AGPL-এর দিকে তাকান।
হ্যাঁ—অনেক কোম্পানি মুক্ত/ওপেন সোর্স সফটওয়্যার ব্যবহার করে উপার্জন করে, কিন্তু ব্যবহারকারীর অধিকার সীমাবদ্ধ করে না.
সাধারণ মডেলগুলো:
লাইসেন্স পছন্দ কৌশল নির্ধারণ করে: permissive গ্রহণযোগ্যতা বাড়ায়; copyleft বন্ধ শাখা গঠনে বাধা দেয় এবং reciprocity-ভিত্তিক মডেলকে সমর্থন করে।