ওপেন সোর্স VPN কেন ক্রয় প্রক্রিয়ায় প্রত্যাখ্যাত হয়
ওপেন সোর্সে আপত্তি তোলা পর্যালোচক সাধারণত লাইসেন্সের রুচি নয়, একটি প্রয়োজনীয়তা রক্ষা করেন। জিজ্ঞাসা করুন কোনটি, তারপর সেই প্রয়োজনীয়তার উত্তর দেওয়া নথিটি তৈরি করুন।
ওপেন সোর্সের কথা উল্লেখ করা প্রত্যাখ্যান সাধারণত লাইসেন্সিং নিয়ে হয় না। পর্যালোচক সাধারণত একটি প্রয়োজনীয়তা রক্ষা করেন: যে কেউ স্থাপিত সংস্করণটি রক্ষণাবেক্ষণ করবে, ইনস্টল করা বিল্ডটি শনাক্ত করা যাবে, কোনো মূল্যায়ন যা সংযুক্ত হচ্ছে তা ঢেকে রাখবে, অথবা সংযোগটি প্রত্যাহার করা যাবে। এরপরের বিতর্ক সাধারণত এমন প্রশ্নের উত্তর দেয় যা কেউ করেনি।
লাইসেন্স রক্ষা করার আগে জিজ্ঞাসা করুন কোন প্রয়োজনীয়তাটি প্রযোজ্য। উত্তরই নির্ধারণ করে আপনার কোন নথি দরকার।
লেবেলটিই প্রয়োজনীয়তা নয়
পাঠযোগ্য সোর্স কোড মানে প্রকাশিত বাস্তবায়নটি পরিদর্শন করা যায়। এর মানে নয় যে কেউ এটি পরিদর্শন করেছে, গেটওয়েতে থাকা বিল্ডটি প্রকাশিতটির সঙ্গে মেলে, বা কোনো রক্ষণাবেক্ষণকারী আপনার স্থাপনার জন্য সংশোধনী দিতে ঋণী। এর প্রত্যেকটি আলাদা মালিকসহ আলাদা দাবি, এবং যে পর্যালোচকের এর একটি দরকার, তিনি বাকিগুলোতে সন্তুষ্ট হবেন না। দাবিটি উচ্চস্বরে নামকরণ করাই সাধারণত কথোপকথন বদলানোর জন্য যথেষ্ট।
উল্টো ভুলটিও সমান সাধারণ। বাণিজ্যিক লাইসেন্স প্রমাণ করে না যে সহায়তা আপনার নির্ভর করা বৈশিষ্ট্যটি ঢাকে, কোনো মূল্যায়ন আপনার স্থাপন করা উপাদানটি পরীক্ষা করেছে, বা বিক্রেতা আপনার রক্ষণাবেক্ষণ সময়সীমার মধ্যে সংশোধন পাঠাবে। লাইসেন্সিং বিতরণের শর্ত বর্ণনা করে, আর ক্রয়ের সিদ্ধান্ত নির্ভরশীলতা নিয়ে। দুই ক্ষেত্রেই লাইসেন্স উত্তরটির সবচেয়ে কম তথ্যবহুল অংশ।
ক্লায়েন্ট ও সেবাকে আলাদা রাখুন। ডেস্কটপ ক্লায়েন্টের নিরীক্ষা অংশীদারের গেটওয়ে কনফিগারেশন, তার পরিচয় প্রদানকারী বা তার অপারেটররা অ্যাকাউন্ট অপসারণ কীভাবে সামলায় সে সম্পর্কে কিছুই বলে না। আপনার সংগৃহীত যেকোনো প্রমাণ সেই সীমারেখার সঙ্গে মিলতে হবে যা অংশীদারকে বিশ্বাস করতে বলা হচ্ছে।
উদ্বেগকে নথিতে রূপ দিন
অনুমোদনকারীকে একটি বাক্যে প্রয়োজনীয়তাটি বলতে অনুরোধ করুন, তারপর যে নথিটি তা পূরণ করবে তার নাম বলুন। অস্পষ্ট আশ্বাসই এই কথোপকথনগুলোকে ভাবাদর্শ নিয়ে বিতর্কে পরিণত করে।
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework এখানে একটি সংকীর্ণ কারণে উপযোগী: এটি ক্রয়ের কথোপকথনকে অনুশীলন ও সরবরাহকারী যোগাযোগের একটি সাধারণ শব্দভান্ডারের চারপাশে গড়ে তোলে। এটি লেবেল নিয়ে তর্কের বদলে নির্দিষ্ট প্রমাণ চাওয়াকে সমর্থন করে, আর এটি এমন কোনো সনদ নয় যা কোনো নির্দিষ্ট VPN পাস করে।
মাঝের কলামটি কী করে তা লক্ষ্য করুন। প্রতিটি সারি এমন একটি নথি চায় যা হয় আছে নয়তো নেই, আর এটি একটি মতকে এমন সরবরাহে রূপ দেয় যা কেউ তৈরি করতে বা প্রত্যাখ্যান করতে পারে।
ক্লায়েন্টকে সেবা থেকে আলাদা করুন
ক্লায়েন্ট অ্যাপ্লিকেশনের সহায়তা চুক্তি আপনার ট্র্যাফিক যে সার্ভারে পৌঁছায় সে সম্পর্কে কোনো অঙ্গীকার নয়। প্রমাণ উপস্থাপনের আগে চিহ্নিত করুন পথের কোন অংশগুলো অংশীদার পরিচালনা করে আর কোনগুলো আপনি তার হয়ে পরিচালনা করেন। দুটো মেশালে এমন এক নথিপত্র তৈরি হয় যা পূর্ণাঙ্গ দেখায় কিন্তু কিছুই উত্তর দেয় না।
স্থাপনাটি যদি আপনার হয়, অংশীদারকে হয়তো কেবল একটি পরিচয় ও একটি অ্যাক্সেস নিয়মে ভরসা করতে হতে পারে, যা আপনার সম্পূর্ণ সফটওয়্যার সরবরাহ শৃঙ্খলে ভরসা করার চেয়ে অনেক ছোট অনুরোধ। স্থাপনাটি যদি তার হয়, আপনি পছন্দ করা ক্লায়েন্ট অপ্রাসঙ্গিক হতে পারে এবং গেটওয়ে কনফিগারেশনই বিষয় হয়ে ওঠে। দ্বিতীয় বৈঠকের আগে আপনি কোন অবস্থায় আছেন তা বের করা একটি পর্যালোচনা চক্র বাঁচায়।
তারপর সেই পরিচালনামূলক প্রশ্নগুলো দেখুন যেগুলোতে পর্যালোচনা আসলে ব্যর্থ হয়: কে অ্যাকাউন্ট অপসারণ করে, কত দ্রুত, আর পরে কী প্রমাণ থাকে। অপসারণ পদ্ধতি ছাড়া সুন্দরভাবে নথিভুক্ত মূল্যায়নও একটি খোলা পর্যবেক্ষণই থাকে।
বিতর্ক নয়, সিদ্ধান্ত দিয়ে শেষ করুন
বিনিময়টি একটি লিখিত ফলাফলে শেষ করুন: গৃহীত সংস্করণ, তার সঙ্গে যুক্ত নিয়ন্ত্রণগুলো, নামকৃত অপারেটররা, এখনও বাকি প্রমাণ এবং তা দেওয়ার তারিখ। অমীমাংসিত কিছু সাধারণ অনুমোদন বিবৃতিতে শুষে না নিয়ে শর্ত হিসেবে লিপিবদ্ধ করা উচিত।
নীতিতে নির্দিষ্ট কোনো অনুমোদিত পণ্যের নাম থাকলে, কেউ অনুমোদন দেয়নি এমন সমান্তরাল ব্যবস্থা গড়ার বদলে ব্যতিক্রম পথটি ব্যবহার করুন। প্ররোচক কারিগরি যুক্তি অনুমতি দেয় না, আর অনানুষ্ঠানিক স্থাপনা এমন একটি পর্যবেক্ষণ যা ধরা পড়ার অপেক্ষায় থাকে।
কোনো প্রয়োজনীয়তা সত্যিই পূরণ করা না গেলে অনুমোদিত বিকল্পে যান এবং কেন তা বলুন। এই অনুশীলনের উদ্দেশ্য হলো প্রতিষ্ঠান কীসের উপর নির্ভর করতে পারে তা প্রতিষ্ঠা করা, আর স্পষ্ট একটি ‘না’ এমন অনুমোদনের চেয়ে ভালো ফলাফল যা পরে কেউ রক্ষা করতে পারবে না।