ડચ અને EU કાયદા હેઠળ ઓપન સોર્સ સોફ્ટવેર લાઇસન્સ

લગભગ દરેક કોમર્શિયલ સોફ્ટવેર પ્રોડક્ટમાં ઓપન સોર્સ ઘટકો હોય છે, સામાન્ય રીતે સેંકડો, જે વકીલો કરતાં ડેવલપર્સ દ્વારા પસંદ કરવામાં આવે છે. જ્યારે કોઈ કહી શકતું નથી કે કયા લાઇસન્સ લાગુ પડે છે, તેમને શું જરૂરી છે અને ઉત્પાદન તેનું પાલન કરે છે કે નહીં ત્યારે તે સમસ્યા બની જાય છે. આ લેખ સમજાવે છે કે ડચ અને EU કાયદા હેઠળ ઓપન સોર્સ લાઇસન્સ કેવી રીતે કાર્ય કરે છે, જોખમ ક્યાં રહે છે અને શું હોવું જોઈએ.

કાનૂની દ્રષ્ટિએ ઓપન સોર્સ લાઇસન્સ શું છે?

ઓપન સોર્સ લાઇસન્સ એ શરતોને આધીન આપવામાં આવતું કૉપિરાઇટ લાઇસન્સ છે. તે કોઈ ત્યાગ નથી, જાહેર ક્ષેત્ર પ્રત્યેનું સમર્પણ નથી, અધિકારોનો ત્યાગ નથી. લેખક આર્ટ. 1 Aw અને આર્ટ. 10 Aw હેઠળ કૉપિરાઇટ જાળવી રાખે છે, જે કમ્પ્યુટર પ્રોગ્રામ્સને કાર્યો તરીકે સુરક્ષિત કરે છે, અને લાઇસન્સ એવા કૃત્યોને મંજૂરી આપે છે જે અન્યથા આર્ટ. 12 Aw અને આર્ટ. 13 Aw હેઠળ વિશિષ્ટ અધિકારોનું ઉલ્લંઘન કરશે.

પરિણામ વ્યાખ્યા કરતાં વધુ મહત્વનું છે. પાલન કરો, અને તમારી નકલ અને વિતરણ કાયદેસર છે. પાલન કરવામાં નિષ્ફળ જાઓ, અને પરવાનગી તમે જે કર્યું છે તેને આવરી લેતી નથી: તમારો ઉપયોગ કૉપિરાઇટ ઉલ્લંઘન છે, કરારનો ભંગ નથી. મોટાભાગના કૉપિરાઇટ લાઇસન્સ ભંગ પર આપમેળે સમાપ્ત કરીને આને મજબૂત બનાવે છે — GPLv2 કોઈપણ ઉપચાર સમયગાળા વિના, જ્યારે GPLv3 અને AGPLv3 જો સૂચના પછી નિર્ધારિત વિંડોમાં ઉલ્લંઘનનો ઉકેલ આવે તો અધિકારો પુનઃસ્થાપિત કરે છે.

ડચ અદાલતો આ તર્ક લાગુ કરે છે. આરબીમાં. Amsterdam 22 સપ્ટેમ્બર 2020, ECLI:NL:RBAMS:2020:4717, એક વિતરક જેણે ફોર્ક્ડ કોડબેઝમાંથી લાયસન્સ ટેક્સ્ટ અને કૉપિરાઇટ સૂચના દૂર કરી હતી તેને તેની પરવાનગી ગુમાવી દીધી હતી અને ઉલ્લંઘન કરતી હોવાનું માનવામાં આવ્યું હતું. મોટા પ્રમાણમાં નવા કોડ ઉમેરવાથી સ્વતંત્ર કાર્ય બન્યું ન હતું: મૂળ ઓળખી શકાય તેવું હાજર રહ્યું, તેથી જવાબદારીઓ તેની સાથે મુસાફરી કરી.

બે પરિવારો: પરવાનગી આપનાર અને કોપીલેફ્ટ

પરવાનગી આપનારા લાઇસન્સ - MIT, BSD લાઇસન્સ, Apache 2.0 - ઉપયોગ, ફેરફાર અને પુનઃવિતરણની મંજૂરી આપે છે, જેમાં ક્લોઝ્ડ-સોર્સ ઉત્પાદનોનો સમાવેશ થાય છે, જો તમે કૉપિરાઇટ સૂચનાઓ અને લાઇસન્સ ટેક્સ્ટ સાચવો છો.

કોપીલેફ્ટ લાઇસન્સ માટે જરૂરી છે કે જ્યારે તમે સોફ્ટવેરનું વિતરણ કરો છો, અથવા તેના પર બનેલ કંઈક, ત્યારે તમારે તે જ લાઇસન્સ હેઠળ કરવું જોઈએ અને અનુરૂપ સ્ત્રોત ઉપલબ્ધ કરાવવો જોઈએ. તેઓ પહોંચમાં અલગ અલગ હોય છે.

કોપીલેફ્ટ ટ્રિગર અને લિંકિંગ પ્રશ્ન

કોપીલેફ્ટ જવાબદારીઓ વિતરણ પર અસર કરે છે, ઉપયોગ પર નહીં. આંતરિક રીતે GPL સોફ્ટવેર ચલાવતી કંપની, ભલે ગમે તેટલી મોટી સુધારેલી હોય, કંઈપણ વિતરણ કરતી નથી અને કંઈપણ દેવાની નથી. "શું આપણે વિતરણ કર્યું છે?" હંમેશા પહેલો પ્રશ્ન હોય છે, અને તેથી જ કન્ટેનર, ઉપકરણો, ફર્મવેર અને SDK આંતરિક ટૂલિંગ કરતાં વધુ મહત્વપૂર્ણ છે.

બીજો પ્રશ્ન વધુ મુશ્કેલ છે. GPL "પ્રોગ્રામ પર આધારિત કાર્ય" ની વાત કરે છે, જે અમેરિકન વ્યુત્પન્ન કાર્યની વિભાવનાને ઉધાર લે છે. ડચ કાયદામાં આવો કોઈ શબ્દ નથી: વિશ્લેષણ પ્રજનન અને અનુકૂલન અધિકારો દ્વારા ચાલે છે, પૂછે છે કે શું મૂળમાંથી સુરક્ષિત અભિવ્યક્તિનું પુનઃઉત્પાદન કરવામાં આવ્યું છે.

વ્યવહારુ કેસ લિંકિંગનો છે. શું માલિકીના મોડ્યુલને GPL લાઇબ્રેરી સાથે લિંક કરવાથી કોપીલેફ્ટને આધીન એક કાર્ય બને છે તે ડચ કોર્ટ દ્વારા ક્યારેય નક્કી કરવામાં આવ્યું નથી, અને કોઈ બંધનકર્તા EU સત્તા નથી. ફ્રી સોફ્ટવેર ફાઉન્ડેશનનો મત કે લિંકિંગ સંયુક્ત કાર્ય બનાવે છે તે લાઇસન્સ સ્ટુઅર્ડનું અર્થઘટન છે, કાયદો નહીં, અને વિરોધી દૃષ્ટિકોણ એટલો જ અપ્રમાણિત છે. ઇન્ટરનેટનો પ્રિય જવાબ - ગતિશીલ લિંકિંગ સલામત, સ્થિર લિંકિંગ નહીં - ડચ કૉપિરાઇટ કાયદામાં કોઈ આધાર નથી, જે પૂછતું નથી કે કમ્પાઇલર કેવી રીતે વર્તે છે. વધુ સંરક્ષણાત્મક વિશ્લેષણ પૂછે છે કે ઘટકો કેટલા ઘનિષ્ઠ રીતે જોડાયેલા છે: શું તેઓ સરનામાંની જગ્યા અને ડેટા સ્ટ્રક્ચર્સ શેર કરે છે, શું સંયોજન એક ઉત્પાદન તરીકે મોકલવામાં આવે છે, કાં તો એકલા કાર્ય કરી શકે છે, શું માલિકી બાજુ કોપીલેફ્ટ બાજુથી હેડર્સ, મેક્રો અથવા ઇનલાઇન કોડનું પુનઃઉત્પાદન કરે છે? તે પ્રશ્નો સામાન્ય રીતે જોખમનું નિરાકરણ કરે છે. જ્યાં તેઓ નથી કરતા, ત્યાં પ્રક્રિયા સીમા પાછળના ઘટકને અલગ કરો, તેને બદલો અથવા વ્યાપારી લાઇસન્સ લો.

AGPL અને નેટવર્ક ઉપયોગ

AGPL અસ્તિત્વમાં છે કારણ કે કોપીલેફ્ટ વિતરણ દ્વારા ટ્રિગર થાય છે અને SaaS પ્રદાતાઓ વિતરણ કરતા નથી. તેના નેટવર્ક કલમ માટે જરૂરી છે કે જો તમે સોફ્ટવેરમાં ફેરફાર કરો છો અને તેને દૂરસ્થ રીતે તેની સાથે ક્રિયાપ્રતિક્રિયા કરતા વપરાશકર્તાઓ માટે ઉપલબ્ધ કરાવો છો, તો તમે તેમને તમારા સંશોધિત સંસ્કરણનો અનુરૂપ સ્ત્રોત પ્રદાન કરો છો.

સામાન્ય રીતે ત્રણ મુદ્દા ચૂકી જાય છે. આ જવાબદારી સેવાના વપરાશકર્તાઓ પર લાગુ પડે છે, જે ઓપન-સાઇનઅપ પ્રોડક્ટમાં થોડી સુવિધા આપે છે. તે ફેરફાર દ્વારા શરૂ થાય છે, તેથી એક અસંશોધિત ઘટક તેને જોડતો નથી પરંતુ પેચ કરેલ બિલ્ડ કરી શકે છે. અને તે તમારા બાકીના સ્ટેક માટે GPL જેવો જ સંયુક્ત-કાર્ય પ્રશ્ન ઉઠાવે છે - જેના કારણે ઘણી કંપનીઓ ઉત્પાદન કોડમાં AGPL ને પ્રતિબંધિત કરે છે.

લાઇસન્સ સુસંગતતા

સુસંગતતા એ એવા ઘટકોને જોડવાની સમસ્યા છે જેના લાઇસન્સ એવી જવાબદારીઓ લાદે છે જે બંને એક વિતરણમાં પૂર્ણ કરી શકાતા નથી: પરવાનગી આપનારા લાઇસન્સ લગભગ દરેક વસ્તુ સાથે સુસંગત હોય છે, કોપીલેફ્ટ લાઇસન્સ ફક્ત તેમની પોતાની શરતો દ્વારા જ મંજૂરી આપે છે. માનક કેસ અપાચે 2.0 અને GPLv2 છે. અપાચે સોફ્ટવેર ફાઉન્ડેશન અને ફ્રી સોફ્ટવેર ફાઉન્ડેશન સંમત છે કે આ સંયોજનને મંજૂરી નથી, કારણ કે અપાચે 2.0 ની પેટન્ટ સમાપ્તિ અને વળતર જોગવાઈઓ વધારાના પ્રતિબંધો છે જે GPLv2 મંજૂરી આપતું નથી. GPLv3 ને તેમને સ્વીકારવા માટે તૈયાર કરવામાં આવ્યું હતું. સુસંગતતા પણ દિશાત્મક છે: અપાચે કોડને GPLv3 પ્રોજેક્ટમાં સમાવી શકાય છે, પરંતુ વિપરીત નહીં. ખોટી જગ્યાએ એક GPL ઘટક રિલાઇસન્સિંગ, રિ-એન્જિનિયરિંગ અથવા દૂર કરવા વચ્ચે પસંદગી કરવાની ફરજ પાડી શકે છે - રિલીઝ પછી કરતાં પહેલાં ઘણું સસ્તું.

એટ્રિબ્યુશન અને નોટિસ જવાબદારીઓ

સૌથી વધુ વારંવાર ઉલ્લંઘન કરાયેલી જવાબદારીઓ સૌથી ઓછી નાટકીય હોય છે: વિતરણ સાથેની સામગ્રીમાં કૉપિરાઇટ સૂચનાઓ, લાઇસન્સ ટેક્સ્ટ્સ, ડિસ્ક્લેમર અને Apache 2.0 હેઠળ, NOTICE સામગ્રીઓનું પુનઃઉત્પાદન. દરેક પરિવાર તેમને લાદે છે, MIT અને BSD સહિત. તેઓ ઉલ્લંઘન થાય છે કારણ કે કોઈ તેમની માલિકી ધરાવતું નથી, અને તેને ઠીક કરવા માટે સૌથી સરળ છે - સામાન્ય રીતે ઉત્પાદન સાથે મોકલવામાં આવતી જનરેટ કરેલ એટ્રિબ્યુશન ફાઇલ. ઉપરોક્ત ડચ કેસ બરાબર આ નિષ્ફળતા પર આધારિત હતો.

પેટન્ટ અનુદાન અને પેટન્ટ પ્રતિશોધ

MIT અને BSD પેટન્ટ વિશે કંઈ કહેતા નથી, અને પેટન્ટ લાઇસન્સ ગર્ભિત હોઈ શકે છે કે કેમ તે અનિશ્ચિત છે. Apache 2.0 એ દરેક ફાળો આપનાર પાસેથી એક સ્પષ્ટ, રોયલ્ટી-મુક્ત પેટન્ટ લાઇસન્સ ઉમેર્યું, જેમાં એક બદલો કલમ પણ સામેલ છે: પેટન્ટ મુકદ્દમા લાવો જેમાં આરોપ લગાવવામાં આવે છે કે કાર્ય ઉલ્લંઘન કરે છે અને તમારું પેટન્ટ લાઇસન્સ સમાપ્ત થાય છે. GPLv3 માં તુલનાત્મક ગ્રાન્ટ અને તેની પોતાની પેટન્ટ જોગવાઈઓ છે.

પેટન્ટ પોર્ટફોલિયો ધરાવતી કંપનીઓ માટે બે અસરો. જો તમારા એન્જિનિયરો Apache- અથવા GPLv3-લાઇસન્સવાળા પ્રોજેક્ટ્સમાં યોગદાન આપે છે, તો તમે તમારા પોતાના પેટન્ટ હેઠળ લાઇસન્સ આપી રહ્યા છો. અને જો તમે ક્યારેય Apache-લાઇસન્સવાળા ઘટકોનો ઉપયોગ કરો છો તેના આધારે કોઈ કંપની સામે પેટન્ટનો દાવો કરો છો, તો બદલો લેવાથી તમને તે લાઇસન્સ ગુમાવવું પડી શકે છે જેના પર તમે આધાર રાખો છો.

EUPL અને ડચ જાહેર ક્ષેત્ર

યુરોપિયન યુનિયન પબ્લિક લાઇસન્સ વર્ઝન 1.2, જે યુરોપિયન કમિશન દ્વારા મે 2017 માં અમલમાં મુકાયેલા નિર્ણય દ્વારા મંજૂર કરવામાં આવ્યું હતું, તે OSI-મંજૂર કોપીલેફ્ટ લાઇસન્સ છે જેમાં ત્રણ વિશિષ્ટ સુવિધાઓ છે.

• ભાષા તે સત્તાવાર EU ભાષાઓમાં અસ્તિત્વમાં છે, બધા મંજૂર સંસ્કરણો સમાન મૂલ્ય ધરાવે છે, તેથી ડચ સત્તાવાળાઓ ડચમાં કરાર કરી શકે છે.
• સુસંગતતા. પરિશિષ્ટમાં સુસંગત લાઇસન્સ - GPLv2 અને v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL અને CeCILL - ની યાદી આપવામાં આવી છે અને સૂચિબદ્ધ લાઇસન્સ હેઠળના કોડ સાથે EUPL કોડને જોડતા ડેરિવેટિવ કાર્યને તે લાઇસન્સ હેઠળ વિતરિત કરવાની મંજૂરી આપે છે.
• પહોંચ. વિતરણની તેની વ્યાખ્યામાં કાર્યને ઓનલાઈન અથવા ઓફલાઈન ઉપલબ્ધ કરાવવાનો સમાવેશ થાય છે. અથવા તેની આવશ્યક કાર્યક્ષમતાઓની ઍક્સેસ પ્રદાન કરવી, અને કલમ 5 EUPL રિમોટ ઇન્ટરેક્શન સુધી કોપીલેફ્ટ જવાબદારી વહન કરે છે જેમાં તે જ કાર્યક્ષમતા ઓફર કરવામાં આવે છે. તેથી તે સેવા તરીકે વિતરિત સોફ્ટવેર સુધી પહોંચે છે, જે રીતે GPL નથી પહોંચતું.

ડચ જાહેર ક્ષેત્રના ગ્રાહકને કાયદાને બદલે નીતિના વિષય તરીકે EUPL ની જરૂર પડી શકે છે. ઇન્ટરઓપરેબિલિટી યુરોપ એક્ટ, રેગ્યુલેશન (EU) 2024/903, જાહેર ક્ષેત્રની સંસ્થાઓને પ્રતિબંધિત લાઇસન્સિંગ શરતો વિના ઇન્ટરઓપરેબિલિટી સોલ્યુશન્સને પ્રાથમિકતા આપવાનો નિર્દેશ આપે છે, જેમ કે ઓપન સોર્સ, જ્યાં સમકક્ષ હોય; રાષ્ટ્રીય સ્તરે, ઓપન સોર્સનો સિદ્ધાંત, ટેન્ઝીજ, કાયદા પર નહીં, પરંતુ કેબિનેટના નિર્ણયો અને નીતિ રેખાઓ પર આધારિત છે: વેટ ડિજિટલ ઓવરહેઇડ ડિજિટલ ઓળખ માળખાને સરળ બનાવે છે પરંતુ બધા સ્રોત કોડ પ્રકાશિત કરવા માટે કોઈ અમલ કરી શકાય તેવી જવાબદારી લાદતું નથી. ટેન્ડર દસ્તાવેજો વાંચો: EUPL આવશ્યકતા તમારા ડિલિવરેબલને બાંધે છે અને તમે ફરીથી ઉપયોગ કરવા માંગતા હો તે માલિકીના કોડ સાથે અસંગત હોઈ શકે છે.

વ્યવહારમાં અમલીકરણ

કોણ દાવો કરી શકે છે. અધિકારધારક - વ્યક્તિગત ફાળો આપનારાઓ, અથવા સોંપાયેલ કૉપિરાઇટ ધરાવતી ફાઉન્ડેશન અથવા કંપની. ખંડિત લેખકત્વ એ વ્યવહારુ બ્રેક છે: દાવેદારે મુદ્દા પર કોડની માલિકી સાબિત કરવી આવશ્યક છે. તેણે સૌથી જાણીતા યુરોપિયન GPL કેસને હરાવ્યો, જ્યાં વર્ચ્યુઅલાઈઝેશન વિક્રેતા સામે કર્નલ ડેવલપરનો દાવો લેખકત્વના પુરાવાના અભાવે નિષ્ફળ ગયો (LG હેમ્બર્ગ 8 જુલાઈ 2016, 310 O 89/15; OLG હેમ્બર્ગ 28 ફેબ્રુઆરી 2019, 5 U 146/16 ને સમર્થન આપ્યું).

કેસ કાયદો શું સ્થાપિત કરે છે. જર્મન અદાલતોએ વારંવાર સ્વીકાર્યું છે કે ઓપન સોર્સ લાઇસન્સ માન્ય છે અને તે ઉલ્લંઘન વિતરણને ગેરકાયદેસર બનાવે છે, પ્રથમ GPL મનાઈ હુકમથી શરૂ થાય છે (LG München I 19 May 2004, 21 O 6123/04). યુએસ ફેડરલ સર્કિટ જેકોબસન વિરુદ્ધ કાત્ઝર , 535 F.3d 1373 (ફેડ. સિર. 2008) માં સમાન નિષ્કર્ષ પર પહોંચ્યું: લાઇસન્સ શરતો ગ્રાન્ટના અવકાશ પરની શરતો છે, ફક્ત કરારો નહીં, તેથી ભંગ કૉપિરાઇટ દાવા અને મનાઈ હુકમ રાહતને સમર્થન આપે છે. યુએસ મુકદ્દમા અન્વેષણ કરી રહ્યું છે કે શું ડાઉનસ્ટ્રીમ પ્રાપ્તકર્તા તૃતીય-પક્ષ લાભાર્થી તરીકે GPL લાગુ કરી શકે છે. કેલિફોર્નિયા સુપિરિયર કોર્ટ સમક્ષ સોફ્ટવેર ફ્રીડમ કન્ઝર્વન્સી વિરુદ્ધ વિઝિયોમાં તે કેન્દ્રિય પ્રશ્ન છે : શું ગ્રાહકો, તૃતીય-પક્ષ લાભાર્થી તરીકે, GPLv2 હેઠળ સ્રોત કોડના પ્રકાશનની માંગ કરી શકે છે. 2026 માં જ્યુરી ટ્રાયલ પછી જ એક મહત્વપૂર્ણ અંતિમ ચુકાદો અપેક્ષિત છે, તેથી મુદ્દો હજુ નક્કી થયો નથી.

ડચ કોર્ટ તેનો કેવી રીતે સંપર્ક કરશે. Auteurswet હેઠળ કૉપિરાઇટ ઉલ્લંઘન તરીકે: દાવેદાર માલિકી અને પ્રજનન અથવા સંદેશાવ્યવહાર સાબિત કરે છે; પ્રતિવાદી લાઇસન્સ ઉઠાવે છે; દાવેદાર જવાબ આપે છે કે તેની શરતો પૂરી થઈ નથી, તેથી બચાવ નિષ્ફળ જાય છે. આર્ટ. 6:265 BW હેઠળ કરાર આધારિત ઉપાયો સમાંતર રીતે ચાલે છે, પરંતુ કૉપિરાઇટ એ મજબૂત માર્ગ છે.

ઉપાયો. કલમ 3:296 BW હેઠળ મનાઈ હુકમ, સામાન્ય રીતે દંડ ચુકવણી સાથે અને સારાંશ કાર્યવાહીમાં ઉપલબ્ધ; કલમ 27 Aw હેઠળ નુકસાન અને કલમ 27a Aw; કલમ 28 Aw હેઠળ નફાનો હિસાબ; કલમ 28 Aw હેઠળ રિકોલ, શરણાગતિ અથવા વિનાશ. કલમ 1019h Rv. જ્યાં સોફ્ટવેર મફતમાં વિતરિત કરવામાં આવ્યું હતું, ત્યાં નુકસાનનું પ્રમાણ નક્કી કરવું મુશ્કેલ છે, અને જર્મન અપીલ કોર્ટે મનાઈ હુકમને સમર્થન આપતાં નુકસાની આપવાનો ઇનકાર કર્યો હતો (OLG Hamm 13 જૂન 2017, 4 U 72/16). જે કરડે છે તે ભાગ્યે જ નુકસાન છે: તે મનાઈ હુકમ, રિકોલ, ખર્ચનો ઓર્ડર અને પ્રકાશિત કરવાનો સ્રોત છે જે તમે ક્યારેય પ્રકાશિત કરવા માંગતા ન હતા.

જ્યારે તમને અનુપાલન સમસ્યા મળે છે

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

GPLv3 અને AGPLv3 હેઠળ, ઉપચાર વિન્ડો ગતિ કાનૂની મૂલ્ય આપે છે; GPLv2 હેઠળ કોઈ ઉપચાર અધિકાર નથી, તેથી જ મોટાભાગના અમલીકરણ વાટાઘાટો દ્વારા પાલનની બાંયધરી સાથે સમાપ્ત થાય છે. એ પણ નોંધ લો કે વિશેષાધિકાર તમારા વકીલની સલાહ સાથે જોડાયેલ છે, આંતરિક એન્જિનિયરિંગ રિપોર્ટ સાથે નહીં.

એમ એન્ડ એમાં ઓપન સોર્સ અને ડ્યુ ડિલિજન્સ

સોફ્ટવેર એક્વિઝિશનમાં, ઓપન સોર્સ એ એક પ્રમાણભૂત ખંત કાર્યપ્રવાહ છે, અને મુખ્ય ઉત્પાદનમાં એક અપ્રગટ કોપીલેફ્ટ ઘટક એ થોડા તારણોમાંથી એક છે જે ખરેખર સોદાને આગળ ધપાવે છે: જો ઉત્પાદન તેના સ્ત્રોતને મુક્ત કર્યા વિના વિતરિત કરી શકાતું નથી, તો ખરીદનાર કિંમતવાળી સંપત્તિ કરતાં અલગ સંપત્તિ પ્રાપ્ત કરી રહ્યો છે.

કોડબેઝ સ્કેન, લાયસન્સ સાથે ઘટક ઇન્વેન્ટરી અને ફાળો આપનાર અને કોન્ટ્રાક્ટર વ્યવસ્થા વિશેના પ્રશ્નોની અપેક્ષા રાખો. લાક્ષણિક પરિણામોમાં ચોક્કસ વળતર, બાકી રિમેડિયેશન, દૂર કરવાની જરૂર હોય તેવી પૂર્વશરત અથવા બેસ્પોક ઓપન સોર્સ વોરંટીનો સમાવેશ થાય છે. વેચાણકર્તાઓએ પહેલા સ્કેન કરવું જોઈએ: તમે જાહેર કરેલા તારણો વાટાઘાટો છે, ખરીદનારના સલાહકાર જે તારણો આપે છે તે લીવરેજ છે. ખરીદદારોએ "કંપની તેના IP ની માલિકી ધરાવે છે" નહીં પરંતુ એક રજૂઆત શોધવી જોઈએ કે કોઈપણ ઉત્પાદનમાં ઓપન સોર્સ શામેલ નથી જેમાં માલિકીનો સ્રોત કોડ જાહેર કરવાની જરૂર હોય.

સામગ્રીનું બિલ, સ્કેનીંગ અને સાયબર સ્થિતિસ્થાપકતા અધિનિયમ

સોફ્ટવેર બિલ ઓફ મટિરિયલ્સ એ ઉત્પાદનના ઘટકોની યાદી છે, જેમાં આવૃત્તિઓ અને લાઇસન્સનો સમાવેશ થાય છે. તાજેતરમાં સુધી તે સંપૂર્ણપણે કરાર આધારિત હતું, પરંતુ હવે તે નિયમનકારી પણ છે.

સાયબર રેઝિલિયન્સ એક્ટ, રેગ્યુલેશન (EU) 2024/2847, 10 ડિસેમ્બર 2024 ના રોજ અમલમાં આવ્યો અને તબક્કાવાર રીતે અમલમાં આવ્યો. સક્રિય રીતે શોષિત નબળાઈઓ અને ગંભીર ઘટનાઓ માટે રિપોર્ટિંગ જવાબદારીઓ. 14 CRA 11 સપ્ટેમ્બર 2026 થી લાગુ થાય છે; 11 જૂન 2026 થી અનુરૂપ મૂલ્યાંકન સંસ્થાઓની સૂચના પરની જોગવાઈઓ; 11 ડિસેમ્બર 2027 થી સંપૂર્ણ નિયમન (કલમ 71 CRA). પરિશિષ્ટ I CRA ઉત્પાદકોને ઉત્પાદનમાં ઘટકો ઓળખવા અને દસ્તાવેજીકરણ કરવાની જરૂર છે, જેમાં સામાન્ય રીતે ઉપયોગમાં લેવાતા અને મશીન-વાંચી શકાય તેવા ફોર્મેટમાં સામગ્રીનું સોફ્ટવેર બિલ તૈયાર કરીને ઓછામાં ઓછા ટોચના સ્તરની નિર્ભરતાને આવરી લેવામાં આવે છે. તેને પ્રકાશિત કરવાની જરૂર નથી; બજાર દેખરેખ સત્તાવાળાઓ તેની વિનંતી કરી શકે છે.

વાણિજ્યિક પ્રવૃત્તિની બહાર પૂરા પાડવામાં આવતા ફ્રી અને ઓપન સોર્સ સોફ્ટવેર CRA ની બહાર આવે છે. નિયમન ઓપન-સોર્સ સોફ્ટવેર સ્ટુઅર્ડ - એક કાનૂની વ્યક્તિ જે વાણિજ્યિક પ્રવૃત્તિઓ માટે બનાવાયેલ ઓપન સોર્સ સોફ્ટવેરના વિકાસને સતત સમર્થન આપે છે - કલામાં હળવા જવાબદારીઓ સાથે રજૂ કરે છે. 24 CRA: એક દસ્તાવેજીકૃત સાયબર સુરક્ષા નીતિ, બજાર દેખરેખ સત્તાવાળાઓ સાથે સહયોગ અને રિપોર્ટિંગ. જો તમે ઓપન સોર્સનું વ્યાપારીકરણ કરો છો, અથવા અન્ય લોકો વ્યાપારીકરણ કરતા પ્રોજેક્ટને ભંડોળ આપો છો, તો તમે કઈ ભૂમિકા ભજવો છો તે સ્થાપિત કરો છો. કમિશને 27 જુલાઈ 2026 ના રોજ તેનું પ્રથમ માર્ગદર્શન અપનાવ્યું: સાયબર રેઝિલિયન્સ એક્ટ (CRA) ના ઉપયોગ પર કમિશન માર્ગદર્શન, જે સંદેશાવ્યવહાર C(2026) 5252 સાથે જોડાયેલ છે, જે ફ્રી અને ઓપન સોર્સ સોફ્ટવેર અવકાશમાં આવે ત્યારે અન્ય બાબતોની સાથે સંબોધિત કરે છે. સોફ્ટવેર બિલ ઓફ મટિરિયલ્સ માટે ફોર્મેટ સૂચવતો કોઈ અમલીકરણ કાયદો અપનાવવામાં આવ્યો નથી, તેથી નિયમનનું પોતાનું ધોરણ - સામાન્ય રીતે ઉપયોગમાં લેવાતું, મશીન-વાંચી શકાય તેવું ફોર્મેટ - હાલમાં માપદંડ રહે છે.

CI માં ચલાવવામાં આવતા સોફ્ટવેર કમ્પોઝિશન વિશ્લેષણ ઇન્વેન્ટરી સર્વિસિંગ કમ્પ્લાયન્સ, લાઇસન્સ સમીક્ષા અને ખંત એકસાથે ઉત્પન્ન કરે છે. આવા સાધનો વેન્ડર કોડ ચૂકી જાય છે, ડ્યુઅલ-લાઇસન્સ પ્રાપ્ત પ્રોજેક્ટ્સને ખોટી રીતે ઓળખે છે અને લાઇસન્સની શરતો વાંચી શકતા નથી: આઉટપુટને સમીક્ષાની શરૂઆત તરીકે ગણો, સમીક્ષા નહીં.

જો તમે તમારો પોતાનો કોડ પ્રકાશિત કરો છો: CLA અને DCO

જે કંપની કોડ રિલીઝ કરે છે અને બહારના યોગદાન સ્વીકારે છે તેને ખબર હોવી જોઈએ કે તે જે મર્જ કરે છે તેના પર તેની પાસે અધિકારો છે. ફાળો આપનાર લાઇસન્સ કરાર એ પ્રોજેક્ટ અને ફાળો આપનાર વચ્ચેનો કરાર છે, જે સામાન્ય રીતે વ્યાપક કૉપિરાઇટ લાઇસન્સ અને એક્સપ્રેસ પેટન્ટ લાઇસન્સ આપે છે, જેમાં મૌલિકતા અને સત્તાની વોરંટી હોય છે. તે જ કંપનીને તેના પ્રોજેક્ટને પછીથી ફરીથી લાઇસન્સ આપવા અથવા ઓપન સોર્સ લાઇસન્સ સાથે વાણિજ્યિક લાઇસન્સ ઓફર કરવાની મંજૂરી આપે છે. તેની કિંમત ઘર્ષણ છે.

Linux કર્નલ અને અન્ય ઘણા પ્રોજેક્ટ્સ દ્વારા ઉપયોગમાં લેવાતું ડેવલપર સર્ટિફિકેટ ઓફ ઓરિજિન , લાઇસન્સ ગ્રાન્ટ નથી પરંતુ એક હળવું પ્રમાણીકરણ છે, જે દરેક પ્રતિબદ્ધતામાં સાઇન-ઓફ લાઇન તરીકે ઉમેરવામાં આવે છે, જેથી ફાળો આપનાર પ્રોજેક્ટના લાઇસન્સ હેઠળ કોડ સબમિટ કરી શકે. ઓછું બોજારૂપ અને ઓછું રક્ષણાત્મક: કોઈ પેટન્ટ લાઇસન્સ નહીં, કોઈ રિલાયસન્સિંગ નહીં.

જો ડ્યુઅલ લાઇસન્સિંગ અથવા ભવિષ્યમાં લાઇસન્સ શક્ય હોય, તો CLA નો ઉપયોગ કરો; જો પ્રોજેક્ટ વાસ્તવિક કોમન્સ હોય, તો DCO સામાન્ય રીતે પૂરતો હોય છે. કોઈપણ રીતે, ખાતરી કરો કે તમારા રોજગાર અને કોન્ટ્રાક્ટર કરારો તમારા લોકો લખે છે તે કોડમાં કૉપિરાઇટ સોંપે છે.

વ્યવહારુ નીતિ ચેકલિસ્ટ

• દરેક ઉત્પાદન માટે ઘટક ઇન્વેન્ટરી બનાવો અને બિલ્ડ પાઇપલાઇનમાં રિલીઝ કરો, હાથથી નહીં.
• આંતરિક નીતિ પ્રકાશિત કરો: પરવાનગીવાળી યાદી, પ્રતિબંધિત યાદી અને બાકીની દરેક વસ્તુ માટે મંજૂરીનો માર્ગ.
• વિતરણ તરીકે શું ગણાય છે તે લેખિતમાં વ્યાખ્યાયિત કરો — ઓન-પ્રિમાઈસ ઇન્સ્ટોલ, ઉપકરણો, કન્ટેનર, SDK, મોબાઇલ એપ્લિકેશન્સ, ફર્મવેર.
• દરેક ઉત્પાદન સાથે જનરેટ કરેલ એટ્રિબ્યુશન ફાઇલ મોકલો.
• ડિઝાઇન સમયે લાયસન્સ પસંદગીઓને મંજૂરી આપો, જ્યારે ઘટક પસંદ કરવામાં આવે છે, રિલીઝ સમયે નહીં.
• પેટન્ટ ગ્રાન્ટને ધ્યાનમાં રાખીને, બાહ્ય પ્રોજેક્ટ્સમાં યોગદાનને મંજૂરીની જરૂર છે કે નહીં તે નક્કી કરો, અને પ્રથમ બાહ્ય યોગદાન પહેલાં CLA અથવા DCO પસંદ કરો.
• ઉત્પાદનમાં ખરેખર ઓપન સોર્સ સાથે IP વોરંટી, વળતર અને એસ્ક્રો શરતોને સંરેખિત કરો.
• ભંડોળ ઊભું કરવાની અથવા વેચાણ પ્રક્રિયા પહેલાં સમીક્ષા ચલાવો, તે દરમિયાન નહીં.