ઓપન સોર્સ 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 પાસ કરે.
મધ્ય સ્તંભ શું કરે છે તે ધ્યાનમાં લો. દરેક પંક્તિ એવો દસ્તાવેજ માંગે છે જે કાં તો છે કાં નથી, અને તે મતને એવી ડિલિવરીમાં ફેરવે છે જે કોઈ બનાવી કે નકારી શકે.
ક્લાયન્ટને સેવાથી અલગ રાખો
ક્લાયન્ટ એપ્લિકેશન માટેનો સપોર્ટ કરાર તમારો ટ્રાફિક જે સર્વર પર પહોંચે છે તે વિશેની પ્રતિબદ્ધતા નથી. પુરાવા રજૂ કરતા પહેલાં નોંધો કે માર્ગના કયા ભાગ ભાગીદાર ચલાવે છે અને કયા ભાગ તમે તેના વતી ચલાવો છો. બંને ભેળવવાથી એવું દસ્તાવેજ પેકેટ બને છે જે વ્યાપક લાગે છે અને કંઈ જવાબ આપતું નથી.
જો વિસ્તરણ તમારું હોય, તો ભાગીદારને ફક્ત એક ઓળખ અને એક ઍક્સેસ નિયમ પર વિશ્વાસ કરવાની જરૂર પડી શકે, જે તમારી સંપૂર્ણ સોફ્ટવેર પુરવઠા શૃંખલા પર વિશ્વાસ કરવા કરતાં ઘણી નાની વિનંતી છે. જો વિસ્તરણ તેનું હોય, તો તમે પસંદ કરો તે ક્લાયન્ટ અપ્રસ્તુત હોઈ શકે અને ગેટવે રૂપરેખાંકન વિષય બને છે. બીજી બેઠક પહેલાં તમે કઈ સ્થિતિમાં છો તે નક્કી કરવાથી એક સમીક્ષા ચક્ર બચે છે.
પછી એ કામગીરીના પ્રશ્નો તપાસો જેમાં સમીક્ષાઓ ખરેખર નિષ્ફળ જાય છે: કોણ એકાઉન્ટ દૂર કરે છે, કેટલી ઝડપથી, અને પછી કયા પુરાવા રહે છે. દૂર કરવાની પ્રક્રિયા વગરનું સુંદર રીતે દસ્તાવેજીકૃત મૂલ્યાંકન પણ ખુલ્લું નિરીક્ષણ જ રહે છે.
ચર્ચાથી નહીં, નિર્ણયથી પૂર્ણ કરો
આદાન-પ્રદાનને લેખિત પરિણામ સાથે પૂર્ણ કરો: સ્વીકૃત આવૃત્તિ, તેની સાથે જોડાયેલા નિયંત્રણો, નામ આપેલા ઓપરેટરો, હજી બાકી રહેલા પુરાવા અને તે આપવાની તારીખ. કોઈપણ અણઉકેલ્યું સામાન્ય મંજૂરીના નિવેદનમાં સમાવી લેવાને બદલે શરત તરીકે નોંધવું જોઈએ.
જો નીતિ ચોક્કસ મંજૂર ઉત્પાદનનું નામ લે છે, તો કોઈએ અધિકૃત ન કરેલી સમાંતર ગોઠવણ બનાવવાને બદલે અપવાદ માર્ગ વાપરો. પ્રેરક તકનીકી દલીલ પરવાનગી આપતી નથી, અને અનધિકૃત વિસ્તરણ શોધાવાની રાહ જોતું નિરીક્ષણ છે.
જો કોઈ આવશ્યકતા ખરેખર પૂરી ન થઈ શકે, તો મંજૂર વિકલ્પ પર જાઓ અને કેમ તે કહો. આ કસરતનો હેતુ એ નક્કી કરવો છે કે સંસ્થા કઈ બાબત પર આધાર રાખી શકે, અને સ્પષ્ટ ના એ એવી મંજૂરી કરતાં સારું પરિણામ છે જે પછી કોઈ બચાવી ન શકે.