রিচার্ড স্টলম্যান এবং মুক্ত সফটওয়্যার: কোড বদলে দেয়া ধারণা

কেন রিচার্ড স্টলম্যান এখনও গুরুত্বপূর্ণ

সফটওয়্যার শুধু প্রযুক্তিগত পণ্য নয়—এটি অনুমতিগুলোর একটি সেটও। কে এটি চালাতে পারে, কপি করতে পারে, বন্ধুকে শেয়ার করতে পারে, বাগ ঠিক করতে পারে, বা এর উপরে নতুন কিছু তৈরি করতে পারে? এই প্রশ্নগুলোর উত্তর কোডের চেয়ে লাইসেন্সিং দ্বারা বেশি নির্ধারিত। যখন সফটওয়্যার কাজ, যোগাযোগ, এবং গবেষণার কেন্দ্রবিন্দু হয়ে ওঠে, তখন "আপনি কি করতে পারবেন"—এই নিয়মগুলো বৈশিষ্ট্যের তুলনায় একইভাবে বা বেশি করে উদ্ভাবনকে আকার দিতে শুরু করে।

রিচার্ড স্টলম্যান (প্রায়শই “RMS” বলা হয়) গুরুত্বপূর্ণ কারণ তিনি এই নিয়মগুলোকে অগ্রাহ্য করা কঠিন করে দিয়েছেন। ১৯৮০-এর দশকের শুরুতে তিনি দেখেছিলেন যে একটি পরিবর্তন ঘটছে: বেশি বেশি প্রোগ্রাম সোর্স কোড ছাড়া বিতরণ হচ্ছে, এবং ব্যবহারকারীদের ক্রমে বলা হচ্ছিল যে তারা সফটওয়্যার শুধুমাত্র অন্যের শর্তে ব্যবহার করতে পারবে। স্টলম্যান এটাকে কেবল অপ্রসন্নতা হিসাবে দেখেননি—এটিকে ব্যবহারকারী ও ডেভেলপার স্বাধীনতার ক্ষতি হিসেবে দেখেছেন—এবং তিনি সেই স্বাধীনতাগুলো রক্ষা করার জন্য স্পষ্ট নীতিমালা ও আইনগত সরঞ্জাম প্রস্তাব করেন।

এই পোস্ট কী (এবং কী নয়)

এই লেখাটি স্টলম্যানের ধারণা এবং তাদের ব্যবহারিক পরিণতির ওপর কেন্দ্রীভূত: ফ্রি সফটওয়্যার সংজ্ঞা, GNU Project, কপিলেফ্ট, এবং GNU General Public License (GPL)—এবং কীভাবে এগুলো আধুনিক ওপেন-সোর্স ইকোসিস্টেম ও সফটওয়্যার লাইসেন্সিং নর্মগুলোকে গঠন করেছে।

এটি কোনো জীবনী নয়, এবং না কোনো কার্নেল কম্পাইল বা রেপোজিটরি ম্যানেজমেন্টের প্রযুক্তিগত ডীপ ডাইভার। আপনাকে প্রোগ্রামিং ব্যাকগ্রাউন্ড দরকার হবে না।

একটি সমতা-ভিত্তিক, সহজ পাঠযোগ্য দৃষ্টি

স্টলম্যান এই প্রভাবশালী এবং একই সঙ্গে বিতর্কিত। এখানে লক্ষ্য হলো বস্তুনিষ্ঠ ও পাঠযোগ্য থাকা: তিনি কী বলেছিলেন, কী আইনগত যন্ত্রপাতি উদ্ভব হল, ব্যবসা ও ডেভেলপার কিভাবে অভিযোজিত হল, এবং আজ কোথায় বিতর্ক চালিয়ে যাচ্ছে—যাতে আপনি বুঝতে পারেন কেন তার কাজ প্রতিদিনের সফটওয়্যার পছন্দে এখনও প্রভাব ফেলে।

“মুক্ত সফটওয়্যার” আসলে কী বোঝায়

“মুক্ত সফটওয়্যার” ভুলভাবে বোঝা সহজ কারণ মুক্ত শব্দটি দাম বোঝায় এমন ভুল ধারনা দেয়। রিচার্ড স্টলম্যান মুক্ত শব্দটি ব্যবহার করেছেন স্বাধীনতা বোঝাতে—ব্যবহারকারীর ক্ষমতা যাতে তারা তাদের নির্ভর সফটওয়্যার নিয়ন্ত্রণ করতে পারে।

যদি একটি প্রোগ্রাম $0 কিন্তু আপনাকে তা পরিদর্শন, পরিবর্তন বা শেয়ার করতে না দেয়া হয়, তা এখনও “বিনামূল্যে” হতে পারে কিন্তু স্টলম্যানের দৃষ্টিকোণে এটি অমুক্ত।

চারটি অপরিহার্য স্বাধীনতা

মুক্ত সফটওয়্যারকে চারটি মৌলিক অনুমতির দ্বারা সংজ্ঞায়িত করা হয়:

• Freedom 0: যেকোনো উদ্দেশ্যে প্রোগ্রাম চালানোর অধিকার।
• Freedom 1: প্রোগ্রাম কিভাবে কাজ করে তা পড়া এবং সেটিকে আপনার মতোভাবে পরিবর্তন করা।
• Freedom 2: কপিগুলো পুনর্বিতরণ করা যাতে আপনি অন্যদের সাহায্য করতে পারেন।
• Freedom 3: আপনার পরিবর্তিত সংস্করণগুলো বিতরণ করা যাতে কমিউনিটি উপকৃত হয়।

এই স্বাধীনতাগুলো এজেন্সির ব্যাপার: আপনি কেবল টুলের ভোক্তা নন—আপনি অংশগ্রহণকারী হয়ে উঠতে পারেন, যাচাই, অভিযোজন এবং উন্নতি করতে পারবেন।

কেন সোর্স কোড অ্যাক্সেস আপসই নয়

Freedom 1 ও 3 সোর্স কোড অ্যাক্সেস ব্যতীত অসম্ভব—মানব-পাঠ্য নির্দেশাবলী ছাড়া এটি করা যায় না। সোর্স ব্যতীত সফটওয়্যারটি封印কৃত যন্ত্রের মতো: আপনি এটি ব্যবহার করতে পারেন, কিন্তু আপনি বুঝতে পারেন না এটি কী করছে, ভেঙে গেলে মেরামত করতে পারেন না, বা নতুন প্রয়োজনের জন্য মানিয়ে নিতে পারেন না।

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

সরল তুলনা: রেসিপি বনাম সীল করা খাবার

একটি রেস্তোরাঁর খাবারের কথা ভাবুন।

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

এটাই মূল ধারণা: মুক্ত সফটওয়্যার হল ব্যবহারকারীদের প্রয়োজনীয় স্বাধীনতাগুলো যাতে তারা তাদের কম্পিউটিংয়ের উপর নিয়ন্ত্রণ রাখতে পারে।

স্টলম্যান যাঁর প্রতিক্রিয়া দিয়েছিলেন সেই সমস্যা

“সফটওয়্যার লাইসেন্সিং” যখন সবাই ততটা আলোচনা করত না, তখন অনেক প্রোগ্রামিং সংস্কৃতি—বিশেষত বিশ্ববিদ্যালয় ও গবেষণা ল্যাবগুলো—একটি ধরন চালাত: যদি আপনি টুল উন্নত করতে পারেন, আপনি উন্নতি শেয়ার করতেন। সোর্স কোড সফটওয়্যারটির সাথে যেত, মানুষ একে অপরের কাজ পড়ে শিখত, এবং সমস্যা সমাধানগুলি অর্চিতভাবে ছড়িয়ে পড়ত।

শেয়ারিংয়ের নিয়ম থেকে লকডাউন সফটওয়্যারে রূপান্তর

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

প্রিন্টারের গল্প (উদাহরণস্বরূপ)

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

এটি এক প্রিন্টারই নয় যে এককভাবে বৈশ্বিক আন্দোলন সৃষ্টি করেছিল; বরং এটি একটি পরিষ্কার, সম্পর্কযোগ্য উদাহরণ ছিল বৃহত্তর প্রবণতার—যেখানে মানুষ নির্ভরশীল যন্ত্রগুলো ব্যবহারকারীদের দ্বারা ঠিক করা সম্ভব হচ্ছে না।

কেন এটি নতুন লাইসেন্সিং ধারণার দিকে নিয়ে গেল

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

এই অনুপ্রেরণাই পরে যে লাইসেন্সিং উদ্ভাবনগুলোকে রূপ দিল—স্টলম্যান চাইছিল এমন নিয়ম যা ব্যবহার, অধ্যয়ন, পরিবর্তন, এবং শেয়ার করার ক্ষমতা সংরক্ষণ করে—তাই সহযোগিতা বাণিজ্যিক মূল্য অর্জন করার সঙ্গে সঙ্গে প্রত্যাহার করা যাবে না।

GNU প্রকল্প: একটি মুক্ত OS নির্মাণ

স্টলম্যানের বড় পদক্ষেপ কেবল ম্যানিফেস্টো লেখা ছিল না—এটি একটি ব্যবহারিক প্রকৌশল প্রচেষ্টা শুরু করা। ১৯৮৩ সালে তিনি GNU Project ঘোষণা করেন, উদ্দেশ্য ছিল স্পষ্ট ও দামী: একটি সম্পূর্ণ অপারেটিং সিস্টেম বানানো যা কেউ ব্যবহার, অধ্যয়ন, পরিবর্তন, এবং শেয়ার করতে পারবে, এবং Unix-সঙ্গত হতে হবে যাতে পরিচিত প্রোগ্রাম ও ওয়ার্কফ্লো চলতে পারে।

একটি পূর্ণ সিস্টেম, একটি একক টুল নয়

একটি অপারেটিং সিস্টেম একটাই প্রোগ্রাম নয়—এটি পুরো স্ট্যাক। GNU সেট করল প্রতিদিনের কাজে প্রয়োজনীয় সব উপাদান তৈরি করার লক্ষ্য:

• কম্পাইলার (বিশেষত GCC) যাতে ডেভেলপাররা কোডকে রানেবল প্রোগ্রামে রূপান্তর করতে পারে
• কোর কমান্ড-লাইন ইউটিলিটি (ফাইল কপি, টেক্সট সার্চ, প্রসেস ম্যানেজমেন্ট ইত্যাদি)
• লাইব্রেরি ও ডেভেলপার টুলস যাতে আরও সফটওয়্যার নির্মাণ করা যায়
• শেল ও এডিটর যাতে ডেইলি কাজ করা যায়

সরল কথায়: GNU প্লাম্বিং, ওয়্যারিং, এবং সুইচগুলো তৈরি করছিল—শুধু একটি যন্ত্র নয়।

GNU + Linux: অধিকাংশ মানুষ কীভাবে দেখেছে

১৯৯০-এর দশকের শুরুতে GNU অনেক অংশ তৈরি করেছিল, কিন্তু একটি গুরুত্বপূর্ণ অংশ পিছিয়ে ছিল: কর্নেল (যা সরাসরি হার্ডওয়্যার ও সিস্টেম রিসোর্স ম্যানেজ করে)। ১৯৯১ সালে Linux আবির্ভাব হল, এবং সেটি সেই গ্যাপকেই পূরণ করে।

এই কারণেই আজকের বহু জনপ্রিয় সিস্টেমে GNU উপাদান এবং Linux kernel মিলিয়ে দেখা যায়—প্রায়ই “GNU/Linux” বলা হয়।

অবকাঠামো আদর্শের চাইতে কম নয়

GNU মুক্ত সফটওয়্যার ধারণাটিকে বাস্তবে পরিণত করেছিল একটি কার্যকর বেস দিয়ে যার ওপর অন্যেরা তৈরি করতে পারে। দার্শনিকতা দেখায় কেন স্বাধীনতা গুরুত্বপূর্ণ; GNU সেই টুলসগুলো পৌঁছে দিল যা স্বাধীনতাকে ব্যবহারিক, পুনরাবৃত্ত, এবং স্কেলেবল করে তোলে।

সহজ বাংলায় কপিলেফ্ট

কপিলেফ্ট এমন একটি লাইসেন্স কৌশল যা সফটওয়্যারকে মুক্ত রেখে ভবিষ্যত সংস্করণগুলিকেও স্বাধীন রাখার চেষ্টা করে। যদি আপনি কপিলেফ্টকৃত কোড পান, আপনি সেটি ব্যবহার, অধ্যয়ন, পরিবর্তন, এবং শেয়ার করতে পারবেন—কিন্তু যখন আপনি আপনার পরিবর্তিত সংস্করণ বিতরণ করবেন, আপনাকে একই স্বাধীনতাগুলো অন্যদেরও দিতে হবে।

কপিরাইটের উপর নির্মিত একটি আইনগত সরঞ্জাম

কপিলেফ্ট শুনলে মনে হতে পারে “অ্যান্টি-কপিরাইট”, কিন্তু এটি আসলে কপিরাইট আইনের উপর নির্ভর করে। লেখক তার কপিরাইট ব্যবহার করে লাইসেন্সে অনুমতির শর্ত রাখে: “আপনি এটি কপি ও পরিবর্তন করতে পারেন, কিন্তু যদি আপনি পুনর্বিতরণ করেন, আপনাকে একই লাইসেন্সে রাখতে হবে।” কপিরাইট না থাকলে এই শর্তগুলো কার্যকর করার আইনি উপায় হত না।

“শেয়ার-এলাইক” ধারণা (সহজ উদাহরণসহ)

এটি কোডের সঙ্গে চলমান একটি নিয়ম:

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

লক্ষ্য হলো সেই ধারা আটকানো যাকে স্টলম্যান চিন্তা করতেন: কেউ কমিউনিটি কাজ নিয়ে তা উন্নত করে তারপর ঐ উন্নতিটা লক করে রাখে।

কপিলেফ্ট বনাম পারমিসিভ লাইসেন্স

পারমিসিভ লাইসেন্স (MIT বা BSD মত) সাধারণত আপনাকে প্রায় যে-কিছু করতেও দেয়—এমনকি পরিবর্তিত সংস্করণগুলোকে ক্লোজড, প্রোপাইটারি লাইসেন্সে পুনর্বিতরণ করাও সম্ভব। কপিলেফ্ট লাইসেন্স (উদাহরণ GPL) বিস্তৃত ব্যবহার ও পরিবর্তনকে অনুমোদন করে, কিন্তু পুনর্বিতরণে অনুচ্ছিন্নভাবে একই শর্ত বজায় রাখতে বলে—তাই downstream-এ স্বাধীনতা সংরক্ষিত থাকে।

কীভাবে GNU GPL লাইসেন্সিংকে বদলে দিয়েছে

GNU General Public License (GPL) সফটওয়্যার লাইসেন্সিং পরিবর্তন করেছে কারণ এটি “শেয়ারিং”-কে একটি প্রয়োগযোগ্য নিয়মে রূপান্তর করে, কেবল সৌহার্দ্য নয়। GPL-এর আগে আপনি সোর্স পেয়ে তা উন্নত করে পরে ক্লোজড ভার্সনে পাঠাতে পারতেন। GPL উল্টে দেয় সেই গতিবিধি: এটি পুনর্বিতরণে শর্ত আরোপ করে ব্যবহারকারীর স্বাধীনতাকে রক্ষা করে।

GPL কি দেয়—এবং বিনিময়ে কি চায়

প্রায়োগিকভাবে, GPL ব্যবহারকারীদের প্রোগ্রাম যেকোনো উদ্দেশ্যে চালানোর, সোর্স পড়ার ও পরিবর্তন করার, এবং মূল বা পরিবর্তিত সংস্করণগুলো শেয়ার করার অধিকার দেয়।

আপনি যদি GPL সফটওয়্যার পুনর্বিতরণ করেন (বিশেষত কোনো পণ্যে বা গ্রাহকের কাছে শিপ করেন), আপনাকে সাধারণত:

• সোর্স কোড প্রদান করতে হবে (বা সেকার্য উপায় দিতে হবে)
• লাইসেন্স টেক্সট অন্তর্ভুক্ত করতে হবে এবং কপিরাইট নোট বজায় রাখতে হবে
• আপনার পরিবর্তনগুলোকে GPL-এর অধীনে লাইসেন্স করতে হবে যাতে downstream ব্যবহারকারীরা ব্লক না হয়

সোর্স বিতরণের বাধ্যবাধকতা (কখন প্রযোজ্য)

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

“ডেরিভেটিভ ওয়ার্ক” সহজ ভাষায়

আইনি তত্ত্ব না জানলেও ধারণা পাওয়া যায়: যদি আপনার প্রোগ্রাম GPL কোডকে এমনভাবে অন্তর্ভুক্ত করে বা লিঙ্ক করে যে একটি যৌথ কাজ সৃষ্টি হয় (উদাহরণস্বরূপ, আপনার অ্যাপ্লিকেশনে সেটি লিঙ্ক করা), তবে ফলাফল সাধারণত ডেরিভেটিভ ওয়ার্ক ধরা হয় এবং GPL-এ বিতরণ করতে হবে। কেবল একটি GPL প্রোগ্রাম চালানো, বা স্ট্যান্ডার্ড ইন্টারফেসে আলাদাভাবে প্রসেসের সঙ্গে কথা বলা, প্রায়শই আলাদা বিবেচিত।

GPL ভ্যারিয়েন্ট: v2, v3, এবং LGPL

• GPLv2: ক্লাসিক, ব্যাপকভাবে ব্যবহৃত সংস্করণ
• GPLv3: পেটেন্ট চুক্তি ও টিভোইজেশন সম্পর্কে অতিরিক্ত সুরক্ষা করে
• LGPL: লাইব্রেরি-ফ্রেন্ডলি; নির্দিষ্ট শর্তে প্রোপাইটারি প্রোগ্রামগুলো থেকে লিঙ্ক করার অনুমতি দেয় যতক্ষণ লাইব্রেরিটিই মুক্ত থাকে

ডেভেলপার অধিকার — এবং দায়িত্ব — মুক্ত লাইসেন্সের আওতায়

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

আপনি কী অধিকার পান

GPL-এর আওতায় আপনি পারবেন:

• বিশ্বাস নিয়ে টinker করা: সোর্স পড়া, পরিবর্তন করা, এবং আপনার সংস্করণ চালানো
• আপনার কাজ শেয়ার করা: মূল বা পরিবর্তিত প্রোগ্রামের কপি বিতরণ করা
• অন্যদের উন্নতির ওপর তৈরি করা: কারণ প্রাপকদের একই স্বাধীনতাগুলো দিতে হবে

একারণে GPL প্রায়ই “প্রয়োগযোগ্য প্রতিদান” বলে বর্ণিত হয়। যদি কেউ GPL-আচ্ছাদিত প্রোগ্রাম (বা ডেরিভেটিভ) বিতরণ করে, তারা downstream ব্যবহারকারীদের একই ধরনের পরিবর্তন ও শেয়ারিং থেকে বঞ্চিত করতে পারবে না।

আপনি কী দায়িত্ব নেবেন

এই অধিকারগুলোর সঙ্গে কিছু বাধ্যবাধকতা আসে যখন আপনি বিতরণ করেন:

• কপিরাইট ও লাইসেন্স নোট বজায় রাখা
• প্রাসঙ্গিক সোর্স (বা সোর্স অফার) প্রদান যখন GPL ছাড়ে
• লাইসেন্স অটল রাখা যাতে প্রাপকেরা তাদের অধিকার জানে

এই দায়িত্বগুলো “জটিলতা” নয়—এগুলোই সহযোগিতাকে একপলারোপে পরিণত হতে দেয় না।

কমপ্লায়েন্স সম্পর্কে বাস্তব দ্রষ্টব্য

টিমগুলোকে লাইসেন্স কমপ্লায়েন্সকে রিলিজ হাইজিনের মতো দেখলে ভালো। ট্র্যাক করুন:

• আপনি কোন ওপেন-সোর্স কম্পোনেন্ট শিপ করছেন,
• তাদের ভার্সন ও লাইসেন্স কি,
• প্রাপকদের কোথায় সোর্স দেওয়া হয়েছে (বা লিখিত অফার),
• এবং আপনি যে কোনো পরিবর্তন করেছেন তা নথিভুক্ত আছে কি না।

একটি সাধারণ SBOM এবং রিলিজ চেকলিস্ট আইনজীবীর কাছে যাওয়ার আগে বেশিরভাগ সমস্যা প্রতিরোধ করতে পারে।

মুক্ত সফটওয়্যার বনাম ওপেন সোর্স: মানের বিভাজন

কোড স্তরে, “মুক্ত সফটওয়্যার” ও “ওপেন সোর্স” প্রায়ই একই প্রকল্পগুলোর বর্ণনা করে। বিভাজনটি প্রধানত কেন শেয়ারিং গুরুত্বপূর্ণ সেটাতে।

ভিন্ন অগ্রাধিকার: স্বাধীনতা বনাম গ্রহণযোগ্যতা

ফ্রি সফটওয়্যার আন্দোলন (রিচার্ড স্টলম্যান ও Free Software Foundation-এর সঙ্গে যুক্ত) সফটওয়্যার স্বাধীনতাকে নৈতিক ইস্যু হিসেবে দেখে: ব্যবহারকারীদের চালানো, পড়া, পরিবর্তন, এবং শেয়ার করার অধিকার থাকা উচিত। উদ্দেশ্য কেবল ভাল ইঞ্জিনিয়ারিং নয়—ব্যবহারকারীর স্বায়ত্তশাসন রক্ষা করা।

ওপেন সোর্স পন্থা ব্যবহারিক ফলাফলকে গুরুত্ব দেয়: ভালো সহযোগিতা, দ্রুত পুনরাবৃত্তি, কম বাগ, এবং স্বচ্ছতার মাধ্যমে উন্নত নিরাপত্তা। এটি এই ধারণাকে ব্যবসায়িকভাবে উপস্থাপন করতে স্বাচ্ছন্দ্যবোধ করে, কিন্তু নৈতিক দৃষ্টিকোণটি চাপ দেয় না।

কেন “ওপেন সোর্স” দ্রুত জনপ্রিয় হলো

১৯৯৮ সালে Open Source Initiative (OSI) “open source” টার্মকে প্রচলিত করে যাতে ধারণাটি ব্যবসা-বান্ধব হয়। “Free software” প্রায়শই ভুল হয়ে বোঝা হত “শূন্য মূল্য”, এবং কিছু কোম্পানি অধিকার ও নৈতিকতার কথা বললে সন্দিহান ছিল। “Open source” প্রতিষ্ঠানগুলোকে বলে দেয় “আমরা এভাবে কাজ করতে পারি”—একটু কম আদর্শিক সংবাদ সহ।

একই লাইসেন্স, ভিন্ন ব্যাখ্যা

অনেক প্রকল্প যে নিজেকে ওপেন সোর্স বলে সেগুলোই GNU GPL বা অন্যান্য কপিলেফ্ট লাইসেন্স ব্যবহার করে, আবার অনেকে MIT বা Apache মতো পারমিসিভ লাইসেন্স বেছে নেয়। আইনি টেক্সট একই থাকতে পারে; কন্ট্রিবিউটর, ব্যবহারকারী, ও গ্রাহকদের কাছে যে গল্পটি বলা হয় তা আলাদা। একটি বার্তা হচ্ছে “এটি আপনার স্বাধীনতা রক্ষা করে,” আর অন্যটি হচ্ছে “এটি গ্রহণযোগ্যতা বাড়ায় এবং গতি বাড়ায়।”

সহজ সিদ্ধান্ত-মাধ্যম

• যদি আপনার টিম চাই যে downstream ব্যবহারকারীরা একই স্বাধীনতা বজায় রাখুক, মুক্ত সফটওয়্যার ফ্রেমিং নিয়ে শক্ত কপিলেফ্ট বিবেচনা করুন।
• যদি লক্ষ্য হচ্ছে গ্রহণযোগ্যতা সর্বাধিক করা (কোম্পানিগুলোও যেন ব্যবহার করে), ওপেন সোর্স ফ্রেমিং ও প্রায়শই পারমিসিভ লাইসেন্স উপযুক্ত হতে পারে।
• যদি আপনি বিস্তৃত সহযোগিতা চান কিন্তু উন্নতিগুলো ফিরে পাওয়ারও আশা রাখেন, ওপেন সোর্স ভাষা ব্যবহার করে অ্যাপ্রোচ গ্রহণযোগ্য করে নিন এবং ফলাফলের জন্য কপিলেফ্ট লাইসেন্স বেছে নিন।

ব্যবসায়িক মডেল ও বাস্তবগত প্রণোদনা

মুক্ত সফটওয়্যার মানে “কেউ অর্থ প্রদানে পাবে না” নয়। এর মানে হলো ব্যবহারকারীরা সফটওয়্যার চালাতে, পড়তে, পরিবর্তন ও শেয়ার করতে স্বাধীন থাকেন। অনেক কোম্পানি সেই স্বাধীনতার ওপর ভিত্তি করে সুস্থ আয় তৈরি করে—প্রধানত যেগুলো প্রতিষ্ঠানের জন্য মূল্যবান: নির্ভরযোগ্যতা, জবাবদিহিতা, এবং সময়।

কোম্পানিগুলো FOSS দিয়ে কীভাবে উপার্জন করে

কয়েকটি সাধারণ, প্রমাণিত মডেল:

• সাপোর্ট ও সেবা: পেইড হেল্পডেস্ক, SLA, ট্রেনিং, অডিট, কাস্টম ফিচার, মাইগ্রেশন
• হোস্টিং ও ম্যানেজড অফারিং: হোস্টেড সংস্করণ বিক্রি যেখানে গ্রাহকরা কনভিনিয়েন্স, স্কেলিং, ব্যাকআপ ও কমপ্লায়েন্সের জন্য টাকা দেয়
• ডুয়াল লাইসেন্সিং: একই সফটওয়্যারকে মুক্ত লাইসেন্সে (প্রায়শই কপিলেফ্ট) এবং পেইড বাণিজ্যিক লাইসেন্সে দেওয়া
• ওপেন কোর (সতর্কভাবে): একটি বাস্তবে মুক্ত বেস রেখে প্রোপাইটারি অ্যাড-অন বিক্রি করা; কাজ করতে পারে, কিন্তু কমিউনিটি আস্থায় টান পড়তে পারে

একটি আধুনিক মোড় হলো প্ল্যাটফর্ম যা দ্রুত অ্যাপ বানায় ও চালায়—উদাহরণস্বরূপ, Koder.ai একটি ভイブ-কোডিং প্ল্যাটফর্ম যা টিমকে চ্যাটের মাধ্যমে ওয়েব, ব্যাকএন্ড, ও মোবাইল অ্যাপ তৈরিতে সাহায্য করে—ইতিমধ্যে সোর্স কোড এক্সপোর্ট সাপোর্ট করে। দ্রুত পুনরাবৃত্তি + কোড মালিকানা—এই সংমিশ্রণ সফটওয়্যার স্বাধীনতার নীতির সাথে ভালভাবে মিলে যায়: যখন দরকার তখন কোড পরীক্ষা, বদলানো, এবং সরানো যায়।

পারমিসিভ বনাম কপিলেফ্ট কৌশলগত প্রভাব

লাইসেন্স পছন্দ মূল্য ধরা কারোর ওপর প্রভাব ফেলে:

• পারমিসিভ লাইসেন্স (MIT/Apache) আপনার কোডকে বড় প্লেয়াররা প্রোপাইটারি পণ্যেও সহজে reuse করতে দেয়। এতে গ্রহণযোগ্যতা বাড়তে পারে, কিন্তু এক্সক্লুসিভিটি মনিটাইজের সুযোগ কমতে পারে।
• কপিলেফ্ট লাইসেন্স (GPL) downstream পুনর্বিতরণকারীদের পরিবর্তনগুলো শেয়ার করতে বাধ্য করে। এটি ক্লোজড ফর্ককে নিরুৎসাহিত করতে পারে এবং সার্ভিস বা সার্টিফাইড ডিস্ট্রিবিউশন বা ডুয়াল লাইসেন্সিংয়ের মতো মডেলকে সহায়তা করতে পারে।

“বাণিজ্যিক” ও “মুক্ত সফটওয়্যার” বিপরীত নয়

“বাণিজ্যিক” মানে কীভাবে বিক্রি হচ্ছে; “মুক্ত সফটওয়্যার” মানে ব্যবহারকারীর অধিকার কী। একটি কোম্পানি মুক্ত সফটওয়্যার বিক্রি করতে পারে, সাপোর্টের জন্য চার্জ করতে পারে, এবং তবু সফটওয়্যার স্বাধীনতা সম্মান করতে পারে।

টেকসইতার চেকলিস্ট

কোনো FOSS প্রকল্পে নির্ভর করার আগে জিজ্ঞেস করুন:

• সক্রিয় কমিউনিটি আছে কি (ইস্যু, রিলিজ, রিভিউ)?
• গভর্ন্যান্স স্পষ্ট কি (কে সিদ্ধান্ত নেয়, বিরোধ কিভাবে মিটিং করা হয়)?
• অর্থায়ন দৃশ্যমান কি (স্পনসর, কোম্পানি সাপোর্ট, ফাউন্ডেশন)?
• মেইনটেইনার লোড টেকসই কি (বাস ফ্যাক্টর, বার্নআউট সংকেত)?
• নিরাপত্তা অনুশীলন ডকুমেন্টেড কি (প্যাচ ক্যালেন্ডার, অ্যাডভাইজরি)?

GPL এবং FOSS সম্বন্ধে সাধারণ ভুল ধারণা

GPL এবং “FOSS” নিয়ে প্রচুর আলোচনা হয়, কিন্তু কয়েকটি বারবার ওঠা মিথ সামঞ্জস্য নষ্ট করে—বিশেষত টিমগুলোর জন্য যারা কেবল প্রোডাক্ট শিপ করতে চায়।

“GPL মানে পাবলিক ডোমেইন”

না। পাবলিক ডোমেইন মানে কোনো কপিরাইট মালিক নেই—কোনো শর্ত ছাড়াই কেউই কাজটি ব্যবহার করতে পারে।

GNU GPL ঠিক উল্টো: লেখক কপিরাইট বজায় রাখে এবং বড় ধরনের অনুমতি দেয়, কিন্তু শর্ত হিসেবে GPL-এর শর্ত মানতে হবে (বিশেষ করে সোর্স শেয়ারিং যখন বাইনারি বিতরণ করা হয়)।

“ওপেন সোর্স সবসময় সিকিউর”

কোড দেখা যায় বলে তা সিকিউর হবে এমন নয়। একটি প্রকল্প ওপেন সোর্স হলেও তা:

• অব onderhouden থাকতে পারে,
• খারাপভাবে রিভিউ করা থাকতে পারে,
• বছর খানেক ভুক্তভোগী দুর্বলতা থাকতে পারে।

নিরাপত্তা আসে সক্রিয় রক্ষণাবেক্ষণ, অডিট, রেসপনসিবল ডিসক্লোজার, এবং ভালো অপারেশনাল অনুশীলন থেকে—লাইসেন্স লেবেল থেকে নয়।

“ভাইরাল লাইসেন্স” দাবিটা

মানুষ প্রায়ই GPL-কে “ভাইরাল” বলে—অর্থাৎ এটি সবকিছুকে ছড়িয়ে দেয়। এটা একটি লোডড মেটাফর।

অধিকাংশ ক্ষেত্রেই এটি নির্দেশ করে কপিলেফ্ট: যদি আপনি GPL কোডের ডেরিভেটিভ বিতরণ করেন, আপনাকে সংশ্লিষ্ট সোর্স GPL-এ দিতে হবে। এই বাধ্যবাধকতা ইচ্ছাকৃত—এটি downstream স্বাধীনতাগুলো সংরক্ষণ করে। এটি “সংক্রমণ” নয়; এটি একটি শর্ত আপনি গ্রহণ বা এড়িয়ে যেতে পারেন।

“আমি কি আমার অ্যাপে বা সার্ভিসে GPL কোড ব্যবহার করতে পারি?” (উচ্চ স্তরের)

নির্ধারক মূলনীতিঃ বাধ্যবাধকতা প্রধানত বিতরণে ট্রিগার হয়।

• অভ্যন্তরীণ ব্যবহার: সাধারণত GPL সোর্স প্রকাশের বাধ্যবাধকতা নেই।
• অ্যাপ/ডিভাইস শিপ করা: আপনি যদি GPL-লাইসেন্সকৃত প্রোগ্রাম বিতরণ করেন বা ডিভাইসে শিপ করেন, সাধারণত সোর্স ও নোট দিতে হবে।
• SaaS / ওয়েব সার্ভিস: সাধারণত সার্ভার-সাইডে GPL চালালে ব্যবহারকারীদের কাছে সোর্স ছাড়তে হয় না। (AGPL এই ফাঁক বন্ধ করার জন্য তৈরি করা হয়েছিল.)

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

সমালোচনা, বিবাদ, এবং চলমান বিতর্ক

রিচার্ড স্টলম্যান একটি বিতর্কিত ব্যক্তি। এটিকে স্বীকার করে কথা বলা সম্ভব—এবং এখনও তাঁর ধারনাগুলোর স্থায়ী প্রভাব নিয়ে আলোচনা করা উচিত।

একটি উপযোগী শুরু হল দুইটি আলাদা কথোপকথনকে আলাদা করা: (1) স্টলম্যান একজন ব্যক্তি এবং কমিউনিটি সদস্য হিসেবে বিতর্কিত—এই বিষয়ে বিতর্ক, ও (2) মুক্ত সফটওয়্যার নীতির, GNU Project-এর, এবং GNU GPL-এর পরিমাপযোগ্য প্রভাব—লাইসেন্সিং ও ডেভেলপার অধিকারগুলোর ওপর। দ্বিতীয়টি প্রাথমিক উৎস (লাইসেন্স টেক্সট, প্রকল্প ইতিহাস, গ্রহণের প্যাটার্ন) দিয়ে আলোচনা করা যায় এমনকি ব্যক্তিগত বিতর্ক থাকলেও।

গভর্ন্যান্স: “কে সিদ্ধান্ত নেয়?”

একটি বারবার ওঠা সমালোচনা লাইসেন্সের কথা নয়, বরং গভর্ন্যান্স সম্পর্কে: প্রকল্পগুলো কীভাবে সিদ্ধান্ত নেয়, কার কি কর্তৃত্ব, এবং যখন প্রতিষ্ঠাতা, মেইনটেইনার, ও ব্যবহারকারীরা ভিন্ন মত পায় তখন কী হয়। মুক্ত সফটওয়্যার কমিউনিটিগুলো প্রশ্নগুলো নিয়ে লড়াই করেছে:

• নেতৃত্ব কিভাবে নির্বাচিত বা প্রতিস্থাপিত হবে?
• ফাউন্ডেশন মেম্বার-চালিত, বোর্ড-চালিত, না মেইনটেইনার-চালিত হওয়া উচিত?
• কখন মেইনটেইনারদের “স্বাধীনতা” কন্ট্রিবিউটরদের প্রয়োজনের সাথে সংঘর্ষ করে?

এই প্রশ্নগুলো গুরুত্বপূর্ণ—লাইসেন্স আইনি শর্ত দেয়, কিন্তু স্বাস্থ্যকর সিদ্ধান্ত গ্রহণ নিজেরে তৈরি করে না।

ইনক্লুসিভিটি, আচরণ, ও কমিউনিটি স্ট্যান্ডার্ড

আরেকটি চলমান বিতর্ক ইনক্লুসিভিটি ও কমিউনিটি নর্ম নিয়ে: প্রాజেক্টগুলো কিভাবে সম্মানজনক আচরণের প্রত্যাশা সেট করে, কিভাবে সংঘাত সামলায়, এবং নতুনদের জন্য কতটা স্বাগত। কিছু কমিউনিটি আনুষ্ঠানিক কন্ডাক্ট কোড জোর দেয়; অন্যরা ন্যূনতম নিয়ম ও অনানুষ্ঠানিক মধ্যস্থতাকে পছন্দ করে। কোন পদ্ধতিই স্বয়ংক্রিয়ভাবে “সঠিক” নয়, কিন্তু ট্রেড-অফগুলো বাস্তব এবং ব্যক্তিগত আক্রমণ ছাড়া আলোচনায় রাখা উচিত।

আলোচনাকে ভিত্তিপ্রস্তর রাখুন

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

ব্যবহারিক সারসংক্ষেপ: লাইসেন্স বাছাই ও কন্ট্রিবিউট করা

স্টলম্যানের সবচেয়ে বড় ব্যবহারিক উপহারটি হলো একটি সরল প্রশ্ন: আপনি downstream-এ কোন স্বাধীনতাগুলো নিশ্চিত করতে চান? এটি উত্তর দিলে লাইসেন্স পছন্দকে একটি সিদ্ধান্তে পরিণত করে।

সহজ সিদ্ধান্ত-ট্রি

• আপনি চান অন্যান্যরা (প্রতিদ্বন্দ্বীরাও) আপনার কোডকে অল্প শর্তে reuse করুক? একটি পারমিসিভ লাইসেন্স (যেমন MIT, Apache-2.0) বেছে নিন।
• আপনি চান আপনার কোডের উন্নতিগুলো পুনর্বিতরণ হলে শেয়ারবল থাকতে চায়? শক্ত কপিলেফ্ট বেছে নিন (উদাহরণ: GNU GPL)।
• আপনি চান শেয়ারিং প্রধানত আপনার লাইব্রেরির পরিবর্তনে প্রযোজ্য হোক, কিন্তু প্রোপাইটারি অ্যাপগুলোকে লিঙ্ক করতেও দেবেন? দুর্বল কপিলেফ্ট বেছে নিন (উদাহরণ: LGPL, MPL)।

আপনি অনিশ্চিত হলে লক্ষ্য অনুযায়ী সিদ্ধান্ত নিন: গ্রহণযোগ্যতা (পারমিসিভ) বনাম প্রতিদান (কপিলেফ্ট) বনাম লাইব্রেরি-বান্ধব প্রতিদান (দুর্বল কপিলেফ্ট)।

দায়িত্বশীলভাবে সফটওয়্যার শিপ করার বাস্তব ধাপ

1. প্রতিটি প্রোজেক্টে একটি লাইসেন্স বেছে নিন এবং README-তে স্পষ্টভাবে উল্লেখ করুন।
2. প্রকল্প রুটে একটি LICENSE ফাইল রাখুন (পূর্ণ লাইসেন্স টেক্সট কপি করুন)।
3. যেখানে আপনার সংস্থা চায় সেখানে কপিরাইট হেডার যোগ করুন।
4. ডিপেন্ডেন্সি ডকুমেন্ট করুন (সরাসরি এবং গুরুত্বপূর্ণ ট্রান্সিটিভগুলো)।
5. আপনি যদি বাইনারি বিতরণ করেন, প্রয়োজনীয় নোটিস, সোর্স অফার (যদি প্রযোজ্য), এবং উল্লেখ যোগ করুন।

AI-সহায়তায় (চ্যাটভিত্তিক প্ল্যাটফর্মসহ) ডেভেলপ করলে এই চেকলিস্টটি আরও বেশি জরুরি: আপনি বাস্তবে নির্ভরশীল উপাদান শিপ করছেন, বাস্তবে আর্টিফ্যাক্ট শিপ করছেন, এবং বাস্তবে লাইসেন্সাল বাধ্যবাধকতা রয়েছে। গতি দায়িত্বকে বিলুপ্ত করে না—বরং পুনরায় ব্যবহারযোগ্য কমপ্লায়েন্স রুটিন বিশেষ মূল্য রাখে।

একটি হালকা-ওজন অভ্যন্তরীণ কমপ্লায়েন্স রুটিন

এটি বিরক্তিকর এবং পুনরাবৃত্তিমূলক করুন:

• বিল্ডের সময় একটি SBOM জেনারেট করুন।
• একটি notices ফাইল টেমপ্লেট রাখুন এবং ডিপেন্ডেন্সি বদলালেই আপডেট করুন।
• PR/রিলিজে লাইসেন্স রিভিউ চেকপয়েন্ট যোগ করুন (একটি ১০-মিনটের চেকলিস্টও যথেষ্ট)।

গভীর তুলনাগুলোর জন্য দেখুন /blog/choosing-an-open-source-license এবং /blog/gpl-vs-mit-vs-apache.