ডাচ এবং ইইউ আইনের অধীনে ওপেন সোর্স সফটওয়্যার লাইসেন্স

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

আইনি পরিভাষায় ওপেন সোর্স লাইসেন্স বলতে কী বোঝায়

একটি ওপেন সোর্স লাইসেন্স হলো শর্ত সাপেক্ষে প্রদত্ত একটি কপিরাইট লাইসেন্স। এটি কোনো অধিকার ত্যাগ, পাবলিক ডোমেইনে উৎসর্গ বা অধিকারের পরিত্যাগ নয়, এবং এই দিক থেকে এটি ডাচ আইনের অধীনে অন্য যেকোনো সফটওয়্যার লাইসেন্সের মতোই কাজ করে । লেখক ধারা ১ Aw এবং ধারা ১০ Aw-এর অধীনে কপিরাইট ধরে রাখেন, যা কম্পিউটার প্রোগ্রামকে কর্ম হিসেবে সুরক্ষা দেয়, এবং এই লাইসেন্স এমন সব কাজের অনুমতি দেয় যা অন্যথায় ধারা ১২ Aw এবং ধারা ১৩ Aw-এর অধীনে থাকা একচেটিয়া অধিকার লঙ্ঘন করত।

সংজ্ঞার চেয়ে তার ফলাফল বেশি গুরুত্বপূর্ণ। নিয়ম মেনে চললে, আপনার অনুলিপি ও বিতরণ আইনসম্মত হবে। নিয়ম না মানলে, আপনার করা কাজটি অনুমতির আওতায় পড়বে না: আপনার ব্যবহারটি হবে কপিরাইট লঙ্ঘন, চুক্তিভঙ্গ নয়। বেশিরভাগ কপিলেফট লাইসেন্স এই বিষয়টিকে আরও জোরদার করে, কারণ নিয়ম লঙ্ঘনের ক্ষেত্রে লাইসেন্সটি স্বয়ংক্রিয়ভাবে বাতিল হয়ে যায় — GPLv2-এর ক্ষেত্রে কোনো প্রতিকারের সুযোগ থাকে না, অন্যদিকে GPLv3 এবং AGPLv3-এর ক্ষেত্রে নোটিশ দেওয়ার পর একটি নির্দিষ্ট সময়ের মধ্যে লঙ্ঘনটি সংশোধন করা হলে অধিকার পুনর্বহাল করা হয়।

ডাচ আদালতগুলো এই যুক্তি প্রয়োগ করে। আরবি মামলায়। Amsterdam ২২ সেপ্টেম্বর ২০২০, ECLI:NL:RBAMS:2020:4717 মামলায়, একজন ডিস্ট্রিবিউটর একটি ফোর্ক করা কোডবেস থেকে লাইসেন্স টেক্সট এবং কপিরাইট নোটিশ সরিয়ে ফেলার কারণে তার অনুমতি হারিয়েছে এবং লঙ্ঘনকারী হিসেবে গণ্য হয়েছে। বিপুল পরিমাণ নতুন কোড যোগ করা একটি স্বাধীন কাজ তৈরি করেনি: মূল কাজটি শনাক্তযোগ্যভাবে উপস্থিত ছিল, তাই এর সাথে দায়বদ্ধতাগুলোও স্থানান্তরিত হয়েছে।

দুটি পরিবার: অনুমতিমূলক এবং কপিলেফট

অনুমতিমূলক লাইসেন্স — যেমন এমআইটি, বিএসডি লাইসেন্স, অ্যাপাচি ২.০ — কপিরাইট বিজ্ঞপ্তি এবং লাইসেন্সের মূল লেখা সংরক্ষণ করার শর্তে, ক্লোজড-সোর্স পণ্যের অভ্যন্তর সহ, ব্যবহার, পরিবর্তন এবং পুনঃবিতরণের অনুমতি দেয়।

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

কপিলেফট ট্রিগার এবং লিঙ্কিং প্রশ্ন

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

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

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

এজিপিএল এবং নেটওয়ার্ক ব্যবহার

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

সাধারণত তিনটি বিষয় উপেক্ষা করা হয়। এই বাধ্যবাধকতাটি পরিষেবার ব্যবহারকারীদের উপর বর্তায়, যা একটি উন্মুক্ত-সাইনআপ পণ্যের ক্ষেত্রে খুব একটা স্বস্তিদায়ক নয়। এটি পরিবর্তনের মাধ্যমে সক্রিয় হয়, তাই একটি অপরিবর্তিত কম্পোনেন্ট এটিকে সক্রিয় করে না, কিন্তু একটি প্যাচ করা বিল্ড তা করতে পারে। এবং এটি আপনার স্ট্যাকের বাকি অংশের জন্য GPL-এর মতোই একই সম্মিলিত-কাজের প্রশ্ন তোলে — যে কারণে অনেক কোম্পানি প্রোডাকশন কোডে AGPL নিষিদ্ধ করে।

লাইসেন্স সামঞ্জস্যতা

সামঞ্জস্যতা হলো এমন সব উপাদান একত্রিত করার সমস্যা, যাদের লাইসেন্স এমন কিছু বাধ্যবাধকতা আরোপ করে যা একটি ডিস্ট্রিবিউশনে একসাথে পূরণ করা সম্ভব নয়: অনুমতিমূলক লাইসেন্সগুলো প্রায় সবকিছুর সাথেই সামঞ্জস্যপূর্ণ, কিন্তু কপিলেফট লাইসেন্সগুলো কেবল তাদের নিজস্ব শর্তাবলীতে যা অনুমোদিত, তার সাথেই সামঞ্জস্যপূর্ণ। এর আদর্শ উদাহরণ হলো অ্যাপাচি ২.০ এবং জিপিএলভি২। অ্যাপাচি সফটওয়্যার ফাউন্ডেশন এবং ফ্রি সফটওয়্যার ফাউন্ডেশন একমত যে এই সংমিশ্রণটি অনুমোদিত নয়, কারণ অ্যাপাচি ২.০-এর পেটেন্ট বাতিলকরণ এবং ক্ষতিপূরণের বিধানগুলো হলো অতিরিক্ত সীমাবদ্ধতা যা জিপিএলভি২ অনুমোদন করে না। জিপিএলভি৩ এগুলোকে গ্রহণ করার জন্যই তৈরি করা হয়েছিল। সামঞ্জস্যতা একমুখীও বটে: অ্যাপাচি কোড একটি জিপিএলভি৩ প্রকল্পে অন্তর্ভুক্ত করা যেতে পারে, কিন্তু এর বিপরীতটি সম্ভব নয়। একটি জিপিএল উপাদান ভুল জায়গায় থাকলে পুনরায় লাইসেন্স প্রদান, পুনঃপ্রকৌশল বা অপসারণের মধ্যে একটি বেছে নিতে বাধ্য করতে পারে — যা প্রকাশের পরে করার চেয়ে আগে করা অনেক সস্তা।

কৃতিত্ব প্রদান এবং বিজ্ঞপ্তির বাধ্যবাধকতা

সবচেয়ে বেশি লঙ্ঘিত বাধ্যবাধকতাগুলো হলো সবচেয়ে কম গুরুতর: ডিস্ট্রিবিউশনের সাথে থাকা উপকরণগুলিতে কপিরাইট নোটিশ, লাইসেন্স টেক্সট, ডিসক্লেইমার এবং অ্যাপাচি ২.০-এর অধীনে, নোটিস (NOTICE) কন্টেন্ট পুনরুৎপাদন করা। এমআইটি (MIT) এবং বিএসডি (BSD) সহ প্রতিটি ভাষা পরিবারই এগুলো আরোপ করে। এগুলো লঙ্ঘিত হয় কারণ এগুলোর কোনো মালিক নেই, এবং এগুলো ঠিক করাও সবচেয়ে সহজ — সাধারণত প্রোডাক্টের সাথে পাঠানো একটি জেনারেটেড অ্যাট্রিবিউশন ফাইলের মাধ্যমে। উপরের ডাচ মামলাটি ঠিক এই ব্যর্থতার কারণেই ঘটেছিল।

পেটেন্ট মঞ্জুরি এবং পেটেন্ট প্রতিশোধ

এমআইটি এবং বিএসডি পেটেন্ট সম্পর্কে কিছুই বলে না, এবং একটি পেটেন্ট লাইসেন্স অনুমিত হতে পারে কিনা তা অমীমাংসিত। অ্যাপাচি ২.০ প্রত্যেক অবদানকারীর কাছ থেকে একটি সুস্পষ্ট, রয়্যালটি-মুক্ত পেটেন্ট লাইসেন্স যুক্ত করেছে, যার সাথে একটি প্রতিশোধমূলক ধারাও রয়েছে: কাজটি স্বত্ব লঙ্ঘন করেছে এমন অভিযোগ এনে পেটেন্ট মামলা করলে আপনার পেটেন্ট লাইসেন্স বাতিল হয়ে যাবে। GPLv3-তে একটি তুলনীয় অনুদান এবং এর নিজস্ব পেটেন্ট বিধান রয়েছে।

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

EUPL এবং ডাচ সরকারি খাত

ইউরোপীয় ইউনিয়ন পাবলিক লাইসেন্স সংস্করণ ১.২, যা ২০১৭ সালের মে মাসে ইউরোপীয় কমিশনের একটি বাস্তবায়নকারী সিদ্ধান্তের মাধ্যমে অনুমোদিত হয়েছে, হলো একটি OSI-অনুমোদিত কপিলেফট লাইসেন্স যার তিনটি স্বতন্ত্র বৈশিষ্ট্য রয়েছে।

• ভাষা. এটি ইইউ-এর দাপ্তরিক ভাষাগুলোতে বিদ্যমান এবং এর সকল অনুমোদিত সংস্করণের মান অভিন্ন, তাই একটি ডাচ কর্তৃপক্ষ ডাচ ভাষায় চুক্তি করতে পারে।
• সামঞ্জস্যতা। একটি পরিশিষ্টে সামঞ্জস্যপূর্ণ লাইসেন্সগুলোর একটি তালিকা দেওয়া হয়েছে — যার মধ্যে রয়েছে GPLv2 ও v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL এবং CeCILL — এবং এটি EUPL কোডের সাথে তালিকাভুক্ত কোনো লাইসেন্সের কোড একত্রিত করে তৈরি করা কোনো উদ্ভূত কাজকে সেই লাইসেন্সের অধীনে বিতরণ করার অনুমতি দেয়।
• পৌঁছানো. বিতরণের সংজ্ঞা অনুযায়ী, কাজটি অনলাইনে বা অফলাইনে উপলব্ধ করা এর অন্তর্ভুক্ত। অথবা এর অপরিহার্য কার্যকারিতাগুলিতে অ্যাক্সেস প্রদান করাএবং EUPL-এর ৫ নং ধারা কপিলেফটের বাধ্যবাধকতাকে সেইসব দূরবর্তী মিথস্ক্রিয়া পর্যন্ত প্রসারিত করে, যেখানে একই কার্যকারিতা প্রদান করা হয়। ফলে, এটি পরিষেবা হিসেবে সরবরাহ করা সফটওয়্যারকেও অন্তর্ভুক্ত করে, যা GPL করে না।

ডাচ সরকারি খাতের কোনো গ্রাহক আইনের পরিবর্তে নীতিগত কারণে EUPL চাইতে পারেন। ইন্টারঅপারেবল ইউরোপ অ্যাক্ট, রেগুলেশন (EU) 2024/903, সরকারি সংস্থাগুলোকে সীমাবদ্ধ লাইসেন্সিং শর্ত ছাড়া ইন্টারঅপারেবিলিটি সমাধানকে অগ্রাধিকার দিতে নির্দেশ দেয়, যেমন ওপেন সোর্স, যেখানে সমতুল্য; জাতীয়ভাবে, ওপেন সোর্সের নীতিটি আইনের উপর নয়, বরং মন্ত্রিসভার সিদ্ধান্ত এবং নীতিমালার উপর নির্ভর করে: ডিজিটাল কর্তৃপক্ষ ডিজিটাল পরিচয় পরিকাঠামোকে সহজতর করে কিন্তু সমস্ত সোর্স কোড প্রকাশ করার জন্য কোনো বাধ্যতামূলক বাধ্যবাধকতা আরোপ করে না। টেন্ডারের নথিগুলো পড়ুন: একটি EUPL আবশ্যকতা আপনার সরবরাহযোগ্য পণ্যের উপর বাধ্যবাধকতা আরোপ করে এবং এটি আপনার পুনঃব্যবহারের উদ্দেশ্যে ব্যবহৃত মালিকানাধীন কোডের সাথে বেমানান হতে পারে।

বাস্তবে প্রয়োগ

কারা মামলা করতে পারে? স্বত্বাধিকারী — অর্থাৎ স্বতন্ত্র অবদানকারী, অথবা অর্পিত কপিরাইট ধারণকারী ফাউন্ডেশন বা কোম্পানি। স্বত্বাধিকারের এই খণ্ডিত অবস্থাই এক্ষেত্রে একটি বাস্তব প্রতিবন্ধকতা: একজন দাবিদারকে আলোচ্য কোডটির মালিকানা প্রমাণ করতে হয়। এই বিষয়টিই ইউরোপের সবচেয়ে পরিচিত GPL মামলাটিকে ব্যর্থ করে দিয়েছিল, যেখানে স্বত্বাধিকার প্রমাণের অভাবে একটি ভার্চুয়ালাইজেশন বিক্রেতার বিরুদ্ধে একজন কার্নেল ডেভেলপারের করা দাবি খারিজ হয়ে যায় (LG Hamburg 8 July 2016, 310 O 89/15; upheld OLG Hamburg 28 February 2019, 5 U 146/16)।

মামলার আইন যা প্রতিষ্ঠা করে। জার্মান আদালতগুলো বারবার মেনে নিয়েছে যে ওপেন সোর্স লাইসেন্সগুলো বৈধ এবং এর লঙ্ঘন বিতরণকে বেআইনি করে তোলে, যা প্রথম GPL নিষেধাজ্ঞার (LG München I 19 May 2004, 21 O 6123/04) মাধ্যমে শুরু হয়েছিল। মার্কিন ফেডারেল সার্কিট Jacobsen বনাম Katzer , 535 F.3d 1373 (Fed. Cir. 2008) মামলায় একই সিদ্ধান্তে পৌঁছেছে: লাইসেন্সের শর্তাবলী হলো অনুদানের পরিধির উপর শর্ত, নিছক অঙ্গীকার নয়, তাই এর লঙ্ঘন কপিরাইট দাবি এবং নিষেধাজ্ঞামূলক প্রতিকারকে সমর্থন করে। মার্কিন যুক্তরাষ্ট্রে মামলা-মোকদ্দমা খতিয়ে দেখছে যে, কোনো ডাউনস্ট্রিম প্রাপক তৃতীয়-পক্ষ সুবিধাভোগী হিসেবে GPL প্রয়োগ করতে পারে কিনা। ক্যালিফোর্নিয়ার সুপিরিয়র কোর্টে Software Freedom Conservancy বনাম Vizio মামলার কেন্দ্রীয় প্রশ্নটি হলো : ভোক্তারা, তৃতীয়-পক্ষ সুবিধাভোগী হিসেবে, GPLv2-এর অধীনে সোর্স কোড প্রকাশের দাবি করতে পারে কিনা। ২০২৫ সালের ২৩শে ডিসেম্বর আদালত সংক্ষিপ্ত নিষ্পত্তির মাধ্যমে একটি বিষয়ে সিদ্ধান্ত দেয়, যেখানে বলা হয় যে GPLv2 এবং LGPLv2.1-এর জন্য এমন সোর্স কোড প্রয়োজন যা অন্যত্র ব্যবহারের জন্য সংগ্রহ ও পরিমার্জন করা যায়, এমন সোর্স কোড নয় যা কার্যকারিতা অক্ষুণ্ণ রেখে ডিভাইসে পুনরায় ইনস্টল করা যায়। তৃতীয় পক্ষের সুবিধাভোগী সংক্রান্ত প্রশ্নটি বেঞ্চ ট্রায়ালের জন্য রেখে দেওয়া হয়েছিল, যা একাধিকবার স্থগিত করা হয়েছে। এটি যাই হোক না কেন, ক্যালিফোর্নিয়ার চুক্তি আইনের একটি প্রশ্ন, তাই এটি নেদারল্যান্ডসে কোনো বাধ্যবাধকতা তৈরি করে না; তবে এর ফলে অভিযোগ করার যোগ্য মানুষের সংখ্যা পরিবর্তিত হবে।

একটি ডাচ আদালত কীভাবে বিষয়টি দেখবে। Auteurswet-এর অধীনে কপিরাইট লঙ্ঘন হিসেবে: বাদী মালিকানা এবং পুনরুৎপাদন বা যোগাযোগের প্রমাণ দেয়; বিবাদী লাইসেন্সের বিষয়টি উত্থাপন করে; বাদী উত্তর দেয় যে তার শর্তগুলো পূরণ করা হয়নি, ফলে প্রতিরক্ষা ব্যর্থ হয়। ধারা 6:265 BW-এর অধীনে চুক্তিভিত্তিক প্রতিকারগুলো সমান্তরালভাবে চলে, কিন্তু কপিরাইট হলো অধিকতর শক্তিশালী পথ।

প্রতিকারসমূহ। ধারা ৩:২৯৬ BW-এর অধীনে একটি নিষেধাজ্ঞা, সাধারণত জরিমানা প্রদানের শর্তে এবং সংক্ষিপ্ত কার্যধারায় উপলব্ধ; ধারা ২৭ Aw-এর অধীনে ক্ষতিপূরণ এবং ধারা ২৭a Aw-এর অধীনে লাভের হিসাব; ধারা ২৮ Aw-এর অধীনে প্রত্যাহার, সমর্পণ বা ধ্বংস; এবং ধারা ১০১৯h Rv-এর অধীনে যুক্তিসঙ্গত ও আনুপাতিক আইনি খরচের সম্পূর্ণ পুনরুদ্ধার। যেখানে সফটওয়্যার বিনামূল্যে বিতরণ করা হয়েছিল, সেখানে ক্ষতির পরিমাণ নির্ধারণ করা কঠিন, এবং একটি জার্মান আপিল আদালত নিষেধাজ্ঞা বহাল রেখে ক্ষতিপূরণ প্রদানে অস্বীকৃতি জানিয়েছিল (OLG Hamm ১৩ জুন ২০১৭, 4 U 72/16)। যা সঙ্কুচিত হয় তা খুব কমই ক্ষতিপূরণ: বরং তা হলো নিষেধাজ্ঞা, প্রত্যাহার, খরচের আদেশ, এবং এমন সোর্স কোড প্রকাশ করতে বাধ্য হওয়া যা আপনি কখনোই প্রকাশ করতে চাননি।

যখন আপনি একটি সম্মতি সমস্যা আবিষ্কার করেন

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

GPLv3 এবং AGPLv3-এর অধীনে প্রতিকারের সুযোগ গতিকে আইনি বৈধতা দেয়; GPLv2-এর অধীনে প্রতিকারের কোনো অধিকার নেই, যে কারণে বেশিরভাগ প্রয়োগ একটি সমঝোতার মাধ্যমে সম্মতিমূলক অঙ্গীকারে শেষ হয়। আরও মনে রাখবেন যে, বিশেষাধিকার আপনার আইনজীবীর পরামর্শের ক্ষেত্রে প্রযোজ্য, কোনো অভ্যন্তরীণ ইঞ্জিনিয়ারিং রিপোর্টের ক্ষেত্রে নয়।

একীভূতকরণ ও অধিগ্রহণ (M&A) এবং যথাযথ যাচাই-বাছাইয়ে ওপেন সোর্স

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

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

উপকরণের তালিকা, স্ক্যানিং এবং সাইবার স্থিতিস্থাপকতা আইন

সফটওয়্যার বিল অফ মেটেরিয়ালস হলো কোনো পণ্যের উপাদান, সংস্করণ এবং লাইসেন্সের একটি তালিকা। সাম্প্রতিককাল পর্যন্ত এটি সম্পূর্ণরূপে চুক্তিভিত্তিক হলেও, এখন এটি নিয়ন্ত্রকও বটে।

সাইবার রেজিলিয়েন্স অ্যাক্ট, রেগুলেশন (ইইউ) ২০২৪/২৮৪৭, ১০ ডিসেম্বর ২০২৪ তারিখে কার্যকর হয়েছে এবং পর্যায়ক্রমে বাস্তবায়িত হবে। এটি ডাচ সাইবারসিকিউরিটি অ্যাক্ট-এর পাশাপাশি কাজ করে , যা পণ্যের পরিবর্তে প্রতিষ্ঠানকে কেন্দ্র করে তৈরি। সিআরএ-এর ১৪ নং ধারায় সক্রিয়ভাবে ব্যবহৃত দুর্বলতা এবং গুরুতর ঘটনা সম্পর্কিত রিপোর্টিং বাধ্যবাধকতা ১১ সেপ্টেম্বর ২০২৬ থেকে প্রযোজ্য হবে; সামঞ্জস্য মূল্যায়নকারী সংস্থাগুলোকে অবহিত করার বিধানগুলো ১১ জুন ২০২৬ থেকে কার্যকর হবে; এবং সম্পূর্ণ রেগুলেশনটি ১১ ডিসেম্বর ২০২৭ থেকে কার্যকর হবে (সিআরএ-এর ৭১ নং ধারা)। সিআরএ-এর অ্যানেক্স I অনুযায়ী, প্রস্তুতকারকদের পণ্যের উপাদানগুলো শনাক্ত ও নথিভুক্ত করতে হবে, যার মধ্যে একটি সাধারণভাবে ব্যবহৃত এবং মেশিন-পঠনযোগ্য ফরম্যাটে সফটওয়্যার বিল অফ মেটেরিয়ালস তৈরি করাও অন্তর্ভুক্ত, যা অন্ততপক্ষে শীর্ষ-স্তরের নির্ভরতাগুলোকে অন্তর্ভুক্ত করবে। এটি প্রকাশ করার প্রয়োজন নেই; বাজার পর্যবেক্ষণ কর্তৃপক্ষ এটি অনুরোধ করতে পারে।

বাণিজ্যিক কার্যকলাপের বাইরে সরবরাহ করা ফ্রি এবং ওপেন সোর্স সফটওয়্যার সাইবার রেজিলিয়েন্স অ্যাক্ট (CRA)-এর আওতার বাইরে থাকে। এই রেগুলেশনটি ওপেন-সোর্স সফটওয়্যার স্টুয়ার্ড—একটি আইনি সত্তা যা বাণিজ্যিক কার্যকলাপের জন্য উদ্দিষ্ট ওপেন সোর্স সফটওয়্যারের উন্নয়নে ধারাবাহিক সহায়তা প্রদান করে—এর প্রবর্তন করেছে, যার উপর CRA-এর ২৪ নং ধারায় কিছু শিথিল বাধ্যবাধকতা আরোপ করা হয়েছে: একটি নথিভুক্ত সাইবার নিরাপত্তা নীতি, বাজার তদারকি কর্তৃপক্ষের সাথে সহযোগিতা এবং প্রতিবেদন দাখিল। আপনি যদি ওপেন সোর্সকে বাণিজ্যিকীকরণ করেন, অথবা অন্যের বাণিজ্যিকীকরণ করা কোনো প্রকল্পে অর্থায়ন করেন, তবে আপনি কোন ভূমিকায় আছেন তা প্রতিষ্ঠা করুন। কমিশন ২৭ জুলাই ২০২৬ তারিখে তার প্রথম নির্দেশিকা গ্রহণ করে: সাইবার রেজিলিয়েন্স অ্যাক্ট (CRA)-এর প্রয়োগ সংক্রান্ত কমিশনের নির্দেশিকা, যা C(2026) 5252 কমিউনিকেশনের সাথে সংযুক্ত এবং যেখানে অন্যান্য বিষয়ের মধ্যে ফ্রি এবং ওপেন সোর্স সফটওয়্যার কখন এর আওতাভুক্ত হবে তা উল্লেখ করা হয়েছে। সফটওয়্যার বিল অফ মেটেরিয়ালস-এর জন্য কোনো ফরম্যাট নির্ধারণ করে এমন কোনো বাস্তবায়নকারী আইন গৃহীত হয়নি, তাই রেগুলেশনের নিজস্ব মান—একটি বহুল ব্যবহৃত, মেশিন-পঠনযোগ্য ফরম্যাট—আপাতত পরিমাপক হিসেবে রয়ে গেছে।

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

আপনি যদি আপনার নিজের কোড প্রকাশ করেন: CLAs এবং DCO

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

লিনাক্স কার্নেল এবং অন্যান্য অনেক প্রকল্পে ব্যবহৃত ‘ ডেভেলপার সার্টিফিকেট অফ অরিজিন’ কোনো লাইসেন্স প্রদান নয়, বরং এটি একটি হালকা ধরনের প্রত্যয়নপত্র। প্রতিটি কমিটের শেষে একটি স্বাক্ষর-লাইন হিসেবে এটি যুক্ত করা হয়, যা নিশ্চিত করে যে অবদানকারী প্রকল্পটির লাইসেন্সের অধীনে কোডটি জমা দিতে পারেন। এটি কম ঝামেলাপূর্ণ এবং কম সুরক্ষামূলক: এতে কোনো পেটেন্ট লাইসেন্স নেই, পুনঃলাইসেন্সিংয়েরও প্রয়োজন হয় না।

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

একটি বাস্তবসম্মত নীতি চেকলিস্ট

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

Law & More সফটওয়্যার কোম্পানি এবং তাদের বিনিয়োগকারীদের পরামর্শ দেয় Eindhoven এবং Amsterdam একটি লেনদেনের মধ্যে ওপেন সোর্স সম্মতি, লাইসেন্স পর্যালোচনা, অবদানকারী ব্যবস্থা এবং ওপেন সোর্স কর্মপ্রবাহের উপর।