ഡച്ച്, യൂറോപ്യൻ യൂണിയൻ നിയമങ്ങൾക്ക് കീഴിലുള്ള ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയർ ലൈസൻസുകൾ

മിക്കവാറും എല്ലാ വാണിജ്യ സോഫ്റ്റ്‌വെയർ ഉൽപ്പന്നങ്ങളിലും ഓപ്പൺ സോഴ്‌സ് ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു, സാധാരണയായി നൂറുകണക്കിന്, അഭിഭാഷകരല്ല, ഡെവലപ്പർമാരാണ് തിരഞ്ഞെടുക്കുന്നത്. ഏതൊക്കെ ലൈസൻസുകളാണ് ബാധകമാകുന്നത്, അവയ്ക്ക് എന്താണ് വേണ്ടത്, ഉൽപ്പന്നം അത് പാലിക്കുന്നുണ്ടോ എന്ന് ആർക്കും പറയാൻ കഴിയാത്തപ്പോൾ അത് ഒരു പ്രശ്‌നമായി മാറുന്നു. ഡച്ച്, യൂറോപ്യൻ യൂണിയൻ നിയമപ്രകാരം ഓപ്പൺ സോഴ്‌സ് ലൈസൻസുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു, അപകടസാധ്യത എവിടെയാണ്, എന്തെല്ലാം ഉണ്ടായിരിക്കണം എന്നിവ ഈ ലേഖനം വിശദീകരിക്കുന്നു.

നിയമപരമായി പറഞ്ഞാൽ ഒരു ഓപ്പൺ സോഴ്‌സ് ലൈസൻസ് എന്താണ്?

ഒരു ഓപ്പൺ സോഴ്‌സ് ലൈസൻസ് എന്നത് നിബന്ധനകൾക്ക് വിധേയമായി അനുവദിക്കുന്ന ഒരു പകർപ്പവകാശ ലൈസൻസാണ്. ഇത് ഒരു ഇളവ് അല്ല, പൊതുസഞ്ചയത്തിലേക്കുള്ള സമർപ്പണമല്ല, അവകാശങ്ങൾ ഉപേക്ഷിക്കുന്നതുമല്ല, ആ കാര്യത്തിൽ ഇത് ഡച്ച് നിയമപ്രകാരമുള്ള മറ്റേതൊരു സോഫ്റ്റ്‌വെയർ ലൈസൻസിനെയും പോലെ പ്രവർത്തിക്കുന്നു . രചയിതാവ് ആർട്ട് പ്രകാരം പകർപ്പവകാശം നിലനിർത്തുന്നു. 1 Aw ഉം ആർട്ടും. 10 Aw, കമ്പ്യൂട്ടർ പ്രോഗ്രാമുകളെ കൃതികളായി സംരക്ഷിക്കുന്നു, കൂടാതെ ആർട്ടിന് കീഴിലുള്ള എക്സ്ക്ലൂസീവ് അവകാശങ്ങൾ ലംഘിക്കുന്ന പ്രവൃത്തികൾക്ക് ലൈസൻസ് അനുവദിക്കുന്നു. 12 Aw ഉം ആർട്ടും. 13 Aw.

നിർവചനത്തേക്കാൾ പ്രധാനമാണ് പരിണതഫലങ്ങൾ. അനുസരിക്കുക, നിങ്ങളുടെ പകർത്തലും വിതരണവും നിയമാനുസൃതമാണ്. അനുസരിക്കുന്നതിൽ പരാജയപ്പെടുന്നു, കൂടാതെ അനുമതി നിങ്ങൾ ചെയ്തതിനെ ഉൾക്കൊള്ളുന്നില്ല: നിങ്ങളുടെ ഉപയോഗം പകർപ്പവകാശ ലംഘനമാണ്, കരാറിന്റെ ലംഘനമല്ല. മിക്ക കോപ്പിലെഫ്റ്റ് ലൈസൻസുകളും ലംഘനത്തിൽ യാന്ത്രികമായി അവസാനിപ്പിക്കുന്നതിലൂടെ ഇത് ശക്തിപ്പെടുത്തുന്നു - ഒരു ചികിത്സാ കാലയളവും ഇല്ലാതെ GPLv2, അതേസമയം GPLv3, AGPLv3 എന്നിവ അറിയിപ്പിന് ശേഷം നിർവചിക്കപ്പെട്ട ഒരു വിൻഡോയ്ക്കുള്ളിൽ ലംഘനം പരിഹരിക്കപ്പെട്ടാൽ അവകാശങ്ങൾ പുനഃസ്ഥാപിക്കുന്നു.

ഡച്ച് കോടതികൾ ഈ ന്യായവാദം പ്രയോഗിക്കുന്നു. റഷ്യൻ ഫെഡറേഷനിൽ. Amsterdam 2020 സെപ്റ്റംബർ 22, ECLI:NL:RBAMS:2020:4717, ഫോർക്ക്ഡ് കോഡ്ബേസിൽ നിന്ന് ലൈസൻസ് ടെക്സ്റ്റും പകർപ്പവകാശ നോട്ടീസും നീക്കം ചെയ്ത ഒരു വിതരണക്കാരന് അതിന്റെ അനുമതി നഷ്ടപ്പെട്ടതായും ലംഘനം നടത്തിയതായും കണ്ടെത്തി. പുതിയ കോഡിന്റെ വലിയ അളവ് ചേർക്കുന്നത് ഒരു സ്വതന്ത്ര സൃഷ്ടി സൃഷ്ടിച്ചില്ല: ഒറിജിനൽ തിരിച്ചറിയാവുന്ന തരത്തിൽ നിലനിന്നു, അതിനാൽ ബാധ്യതകൾ അതിനൊപ്പം തുടർന്നു.

രണ്ട് കുടുംബങ്ങൾ: അനുവാദപരവും പകർപ്പവകാശമില്ലാത്തതും

പെർമിസീവ് ലൈസൻസുകൾ - MIT, BSD ലൈസൻസുകൾ, Apache 2.0 - പകർപ്പവകാശ അറിയിപ്പുകളും ലൈസൻസ് ടെക്സ്റ്റും സംരക്ഷിക്കുന്ന പക്ഷം, ക്ലോസ്ഡ്-സോഴ്‌സ് ഉൽപ്പന്നങ്ങൾക്കുള്ളിൽ ഉൾപ്പെടെ, ഉപയോഗിക്കാനും പരിഷ്‌ക്കരിക്കാനും പുനർവിതരണം ചെയ്യാനും അനുവദിക്കുന്നു.

സോഫ്റ്റ്‌വെയറോ അതിൽ നിർമ്മിച്ച മറ്റേതെങ്കിലും സോഫ്റ്റ്‌വെയറോ വിതരണം ചെയ്യുമ്പോൾ, അതേ ലൈസൻസിന് കീഴിൽ തന്നെ അത് ചെയ്യണമെന്നും അനുബന്ധ ഉറവിടം ലഭ്യമാക്കണമെന്നും കോപ്പിലെഫ്റ്റ് ലൈസൻസുകൾ ആവശ്യപ്പെടുന്നു. അവ എത്തിച്ചേരുന്നതിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.

കോപ്പിലെഫ്റ്റ് ട്രിഗറും ലിങ്കിംഗ് ചോദ്യവും

പകർപ്പവകാശ ലംഘന ബാധ്യതകൾ ഉപയോഗത്തിലല്ല, വിതരണത്തിലാണ്. ആന്തരികമായി GPL സോഫ്റ്റ്‌വെയർ പ്രവർത്തിപ്പിക്കുന്ന ഒരു കമ്പനി, എത്ര വലിയ മാറ്റങ്ങൾ വരുത്തിയിട്ടുണ്ടെങ്കിലും, ഒന്നും വിതരണം ചെയ്യുന്നില്ല, ഒന്നും കടപ്പെട്ടിട്ടില്ല. "നമ്മൾ വിതരണം ചെയ്തിട്ടുണ്ടോ?" എന്നതാണ് എല്ലായ്‌പ്പോഴും ആദ്യത്തെ ചോദ്യം, അതുകൊണ്ടാണ് കണ്ടെയ്‌നറുകൾ, ഉപകരണങ്ങൾ, ഫേംവെയർ, SDK-കൾ എന്നിവ ആന്തരിക ഉപകരണങ്ങളെക്കാൾ പ്രധാനമാകുന്നത്.

രണ്ടാമത്തെ ചോദ്യം കൂടുതൽ ബുദ്ധിമുട്ടാണ്. ഡെറിവേറ്റീവ് വർക്ക് എന്ന അമേരിക്കൻ ആശയം കടമെടുത്ത് "പ്രോഗ്രാമിനെ അടിസ്ഥാനമാക്കിയുള്ള വർക്ക്" എന്നാണ് ജിപിഎൽ പറയുന്നത്. ഡച്ച് നിയമത്തിൽ അത്തരമൊരു പദമില്ല: പുനർനിർമ്മാണ, പൊരുത്തപ്പെടുത്തൽ അവകാശങ്ങളിലൂടെ വിശകലനം കടന്നുപോകുന്നു, ഒറിജിനലിൽ നിന്നുള്ള സംരക്ഷിത പദപ്രയോഗം പുനർനിർമ്മിച്ചിട്ടുണ്ടോ എന്ന് ചോദിക്കുന്നു.

ലിങ്കിംഗ് ആണ് പ്രായോഗിക കേസ്. ഒരു പ്രൊപ്രൈറ്ററി മൊഡ്യൂൾ ഒരു ജിപിഎൽ ലൈബ്രറിയിലേക്ക് ലിങ്ക് ചെയ്യുന്നത് കോപ്പിലെഫ്റ്റിന് വിധേയമായി ഒരു കൃതി സൃഷ്ടിക്കുന്നുണ്ടോ എന്ന് ഒരു ഡച്ച് കോടതി ഒരിക്കലും തീരുമാനിച്ചിട്ടില്ല, കൂടാതെ EU അധികാരവും ബാധകമല്ല. ലിങ്കിംഗ് ഒരു സംയോജിത കൃതി സൃഷ്ടിക്കുന്നു എന്ന ഫ്രീ സോഫ്റ്റ്‌വെയർ ഫൗണ്ടേഷന്റെ വീക്ഷണം ലൈസൻസ് സ്റ്റുവാർഡിന്റെ വ്യാഖ്യാനമാണ്, നിയമമല്ല, എതിർ വീക്ഷണവും ഒരുപോലെ പരീക്ഷിക്കപ്പെട്ടിട്ടില്ല. ഇന്റർനെറ്റിന്റെ പ്രിയപ്പെട്ട ഉത്തരം - ഡൈനാമിക് ലിങ്കിംഗ് സുരക്ഷിതം, സ്റ്റാറ്റിക് ലിങ്കിംഗ് അല്ല - ഡച്ച് പകർപ്പവകാശ നിയമത്തിൽ ഒരു അടിസ്ഥാനവുമില്ല, അത് ഒരു കംപൈലർ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ചോദിക്കുന്നില്ല. കൂടുതൽ പ്രതിരോധാത്മകമായ വിശകലനം ഘടകങ്ങൾ എത്രത്തോളം അടുത്താണ് സംയോജിപ്പിച്ചിരിക്കുന്നതെന്ന് ചോദിക്കുന്നു: അവ ഒരു വിലാസ സ്ഥലവും ഡാറ്റാ ഘടനകളും പങ്കിടുന്നുണ്ടോ, കോമ്പിനേഷൻ ഒരു ഉൽപ്പന്നമായി ഷിപ്പ് ചെയ്യുന്നുണ്ടോ, ഒന്നുകിൽ ഒറ്റയ്ക്ക് പ്രവർത്തിക്കാൻ കഴിയുമോ, പ്രൊപ്രൈറ്ററി സൈഡ് കോപ്പിലെഫ്റ്റ് വശത്ത് നിന്ന് ഹെഡറുകൾ, മാക്രോകൾ അല്ലെങ്കിൽ ഇൻലൈൻ കോഡ് പുനർനിർമ്മിക്കുന്നുണ്ടോ? ആ ചോദ്യങ്ങൾ സാധാരണയായി അപകടസാധ്യത പരിഹരിക്കുന്നു. അവ അങ്ങനെ ചെയ്യുന്നില്ലെങ്കിൽ, ഒരു പ്രോസസ് ബൗണ്ടറിക്ക് പിന്നിലുള്ള ഘടകത്തെ ഒറ്റപ്പെടുത്തുക, അത് മാറ്റിസ്ഥാപിക്കുക, അല്ലെങ്കിൽ ഒരു വാണിജ്യ ലൈസൻസ് എടുക്കുക.

AGPL ഉം നെറ്റ്‌വർക്ക് ഉപയോഗവും

ഡിസ്ട്രിബ്യൂഷൻ കോപ്പിലെഫ്റ്റ് പ്രവർത്തനക്ഷമമാക്കുന്നതിനാലും SaaS ദാതാക്കൾ വിതരണം ചെയ്യാത്തതിനാലുമാണ് AGPL നിലനിൽക്കുന്നത്. സോഫ്റ്റ്‌വെയറിൽ നിങ്ങൾ മാറ്റം വരുത്തുകയും വിദൂരമായി അതുമായി സംവദിക്കുന്ന ഉപയോക്താക്കൾക്ക് അത് ലഭ്യമാക്കുകയും ചെയ്താൽ, നിങ്ങളുടെ പരിഷ്കരിച്ച പതിപ്പിന്റെ അനുബന്ധ ഉറവിടം അവർക്ക് നൽകണമെന്ന് അതിന്റെ നെറ്റ്‌വർക്ക് ക്ലോസ് ആവശ്യപ്പെടുന്നു.

മൂന്ന് പോയിന്റുകൾ സാധാരണയായി അവഗണിക്കപ്പെടുന്നു. സേവനത്തിന്റെ ഉപയോക്താക്കളിൽ ബാധ്യതയുണ്ട്, ഒരു ഓപ്പൺ-സൈൻ അപ്പ് ഉൽപ്പന്നത്തിൽ ഇത് വളരെ ആശ്വാസകരമാണ്. ഇത് പരിഷ്കരണത്തിലൂടെയാണ് ആരംഭിക്കുന്നത്, അതിനാൽ പരിഷ്കരിക്കാത്ത ഒരു ഘടകം അതിൽ ഏർപ്പെടുന്നില്ല, പക്ഷേ ഒരു പാച്ച് ചെയ്ത ബിൽഡ് അതിൽ ഏർപ്പെടാം. നിങ്ങളുടെ സ്റ്റാക്കിന്റെ ബാക്കി ഭാഗത്തിന് GPL പോലെ തന്നെ സംയോജിത-വർക്ക് ചോദ്യം ഇത് ഉയർത്തുന്നു - അതുകൊണ്ടാണ് പല കമ്പനികളും പ്രൊഡക്ഷൻ കോഡിൽ AGPL നിരോധിക്കുന്നത്.

ലൈസൻസ് അനുയോജ്യത

ഒരു വിതരണത്തിൽ പാലിക്കാൻ കഴിയാത്ത ബാധ്യതകൾ ചുമത്തുന്ന ഘടകങ്ങളുടെ ലൈസൻസുകൾ സംയോജിപ്പിക്കുന്നതിന്റെ പ്രശ്നമാണ് അനുയോജ്യത: പെർമിറ്റിവ് ലൈസൻസുകൾ മിക്കവാറും എല്ലാത്തിനും അനുയോജ്യമാകും, കോപ്പിലെഫ്റ്റ് ലൈസൻസുകൾ അവയുടെ സ്വന്തം നിബന്ധനകൾ അനുവദിക്കുന്നതിനൊപ്പം മാത്രം. സ്റ്റാൻഡേർഡ് കേസ് അപ്പാച്ചെ 2.0 ഉം GPLv2 ഉം ആണ്. അപ്പാച്ചെ 2.0 ന്റെ പേറ്റന്റ് അവസാനിപ്പിക്കലും നഷ്ടപരിഹാര വ്യവസ്ഥകളും GPLv2 അനുവദിക്കാത്ത അധിക നിയന്ത്രണങ്ങളായതിനാൽ, അപ്പാച്ചെ സോഫ്റ്റ്‌വെയർ ഫൗണ്ടേഷനും ഫ്രീ സോഫ്റ്റ്‌വെയർ ഫൗണ്ടേഷനും ഈ കോമ്പിനേഷൻ അനുവദനീയമല്ലെന്ന് സമ്മതിക്കുന്നു. അവ സ്വീകരിക്കുന്നതിനാണ് GPLv3 ഡ്രാഫ്റ്റ് ചെയ്തത്. അനുയോജ്യതയും ദിശാസൂചനയാണ്: അപ്പാച്ചെ കോഡ് ഒരു GPLv3 പ്രോജക്റ്റിലേക്ക് ആഗിരണം ചെയ്യാൻ കഴിയും, പക്ഷേ വിപരീതമല്ല. തെറ്റായ സ്ഥലത്ത് ഒരു GPL ഘടകം റീലൈസൻസിംഗ്, റീ-എഞ്ചിനീയറിംഗ് അല്ലെങ്കിൽ നീക്കംചെയ്യൽ എന്നിവയ്ക്കിടയിൽ ഒരു തിരഞ്ഞെടുപ്പ് നിർബന്ധിതമാക്കും - റിലീസിന് മുമ്പുള്ളതിനേക്കാൾ വളരെ വിലകുറഞ്ഞതാണ്.

ആട്രിബ്യൂഷനും അറിയിപ്പ് ബാധ്യതകളും

ഏറ്റവും കൂടുതൽ ലംഘിക്കപ്പെടുന്ന ബാധ്യതകൾ ഏറ്റവും നാടകീയമല്ലാത്തവയാണ്: പകർപ്പവകാശ അറിയിപ്പുകൾ, ലൈസൻസ് വാചകങ്ങൾ, നിരാകരണങ്ങൾ, അപ്പാച്ചെ 2.0 പ്രകാരം, വിതരണത്തോടൊപ്പമുള്ള മെറ്റീരിയലുകളിൽ അറിയിപ്പ് ഉള്ളടക്കങ്ങൾ എന്നിവ പുനർനിർമ്മിക്കുക. ഓരോ കുടുംബവും അവ അടിച്ചേൽപ്പിക്കുന്നു, MIT, BSD എന്നിവയുൾപ്പെടെ. ആരും അവ സ്വന്തമാക്കാത്തതിനാലും പരിഹരിക്കാൻ എളുപ്പമുള്ളതിനാലും അവ ലംഘിക്കപ്പെടുന്നു - സാധാരണയായി ഉൽപ്പന്നത്തിനൊപ്പം അയയ്ക്കുന്ന ഒരു ജനറേറ്റഡ് ആട്രിബ്യൂഷൻ ഫയൽ. മുകളിലുള്ള ഡച്ച് കേസ് കൃത്യമായി ഈ പരാജയത്തിന് കാരണമായി.

പേറ്റന്റ് ഗ്രാന്റുകളും പേറ്റന്റ് പ്രതികാര നടപടികളും

പേറ്റന്റുകളെക്കുറിച്ച് എംഐടിയും ബിഎസ്ഡിയും ഒന്നും പറയുന്നില്ല, പേറ്റന്റ് ലൈസൻസ് സൂചിപ്പിക്കാൻ കഴിയുമോ എന്നത് ഇപ്പോഴും തർക്കത്തിലാണ്. അപ്പാച്ചെ 2.0 ഓരോ സംഭാവകനിൽ നിന്നും ഒരു എക്സ്പ്രസ്, റോയൽറ്റി രഹിത പേറ്റന്റ് ലൈസൻസ് ചേർത്തു, ഒരു പ്രതികാര വ്യവസ്ഥയും അതിൽ ചേർത്തു: സൃഷ്ടി ലംഘിക്കുന്നുവെന്നും നിങ്ങളുടെ പേറ്റന്റ് ലൈസൻസ് അവസാനിപ്പിക്കുന്നുവെന്നും ആരോപിച്ച് പേറ്റന്റ് വ്യവഹാരം കൊണ്ടുവരിക. GPLv3-ൽ താരതമ്യപ്പെടുത്താവുന്ന ഗ്രാന്റും അതിന്റേതായ പേറ്റന്റ് വ്യവസ്ഥകളും അടങ്ങിയിരിക്കുന്നു.

പേറ്റന്റ് പോർട്ട്‌ഫോളിയോകളുള്ള കമ്പനികൾക്ക് രണ്ട് പ്രത്യാഘാതങ്ങൾ. നിങ്ങളുടെ എഞ്ചിനീയർമാർ അപ്പാച്ചെ- അല്ലെങ്കിൽ GPLv3-ലൈസൻസുള്ള പ്രോജക്റ്റുകളിൽ സംഭാവന നൽകുകയാണെങ്കിൽ, നിങ്ങൾ നിങ്ങളുടെ സ്വന്തം പേറ്റന്റുകൾക്ക് കീഴിലാണ് ലൈസൻസുകൾ നൽകുന്നത്. നിങ്ങൾ ഉപയോഗിക്കുന്ന അതേ അപ്പാച്ചെ-ലൈസൻസുള്ള ഘടകങ്ങളെ ആശ്രയിച്ച് ഒരു കമ്പനിക്കെതിരെ നിങ്ങൾ എപ്പോഴെങ്കിലും പേറ്റന്റുകൾ അവകാശപ്പെട്ടാൽ, പ്രതികാരം നിങ്ങൾ ആശ്രയിക്കുന്ന ലൈസൻസ് നഷ്ടപ്പെടുത്തിയേക്കാം.

EUPL ഉം ഡച്ച് പൊതുമേഖലയും

2017 മെയ് മാസത്തിൽ തീരുമാനം നടപ്പിലാക്കിക്കൊണ്ട് യൂറോപ്യൻ കമ്മീഷൻ അംഗീകരിച്ച യൂറോപ്യൻ യൂണിയൻ പബ്ലിക് ലൈസൻസ് പതിപ്പ് 1.2, മൂന്ന് വ്യത്യസ്ത സവിശേഷതകളുള്ള ഒരു 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 മെയ് 2004, 21 O 6123/04). ജേക്കബ്സെൻ വി കാറ്റ്സർ , 535 F.3d 1373 (ഫെഡ്. സർ. 2008) എന്ന കേസിൽ യുഎസ് ഫെഡറൽ സർക്യൂട്ട് ഇതേ നിഗമനത്തിലെത്തി: ലൈസൻസ് നിബന്ധനകൾ വെറും ഉടമ്പടികളല്ല, ഗ്രാന്റിന്റെ വ്യാപ്തിയെക്കുറിച്ചുള്ള വ്യവസ്ഥകളാണ്, അതിനാൽ ലംഘനം ഒരു പകർപ്പവകാശ ക്ലെയിമിനെയും ഇൻജങ്ക്റ്റീവ് റിലീഫിനെയും പിന്തുണയ്ക്കുന്നു. ഒരു ഡൗൺസ്ട്രീം സ്വീകർത്താവിന് മൂന്നാം കക്ഷി ഗുണഭോക്താവായി GPL നടപ്പിലാക്കാൻ കഴിയുമോ എന്ന് യുഎസ് വ്യവഹാരം പരിശോധിക്കുന്നു. കാലിഫോർണിയയിലെ സുപ്പീരിയർ കോടതിക്ക് മുമ്പാകെ സോഫ്റ്റ്‌വെയർ ഫ്രീഡം കൺസർവൻസി വി വിസിയോയിലെ കേന്ദ്ര ചോദ്യം ഇതാണ് : മൂന്നാം കക്ഷി ഗുണഭോക്താക്കൾ എന്ന നിലയിൽ ഉപഭോക്താക്കൾക്ക് GPLv2 പ്രകാരം സോഴ്‌സ് കോഡ് പുറത്തിറക്കണമെന്ന് ആവശ്യപ്പെടാൻ കഴിയുമോ. 2025 ഡിസംബർ 23-ന് കോടതി സംഗ്രഹ വിധിന്യായത്തിൽ ഒരു കാര്യം തീരുമാനിച്ചു, GPLv2 ഉം LGPLv2.1 ഉം ഉപകരണത്തിൽ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയുന്ന ഉറവിടമല്ല, മറിച്ച് മറ്റെവിടെയെങ്കിലും ഉപയോഗിക്കുന്നതിന് നേടാനും പുനർനിർമ്മിക്കാനും കഴിയുന്ന ഉറവിടം ആവശ്യമാണെന്ന് വിധിച്ചു. മൂന്നാം കക്ഷി ഗുണഭോക്തൃ ചോദ്യം തന്നെ ബെഞ്ച് വിചാരണയ്ക്കായി അവശേഷിപ്പിച്ചു, അത് ഒന്നിലധികം തവണ മാറ്റിവച്ചു. എന്തായാലും ഇത് കാലിഫോർണിയൻ കരാർ നിയമ ചോദ്യമാണ്, അതിനാൽ ഇത് നെതർലാൻഡിൽ ഒന്നും ബന്ധിപ്പിക്കുന്നില്ല; ഇത് മാറ്റുന്നത് പരാതിപ്പെടാൻ കഴിയുന്ന ആളുകളുടെ എണ്ണമാണ്.

ഒരു ഡച്ച് കോടതി അതിനെ എങ്ങനെ സമീപിക്കും. Auteurswet പ്രകാരം പകർപ്പവകാശ ലംഘനമായി: അവകാശവാദി ഉടമസ്ഥാവകാശവും പുനരുൽപാദനവും അല്ലെങ്കിൽ ആശയവിനിമയവും തെളിയിക്കുന്നു; പ്രതി ലൈസൻസ് ഉയർത്തുന്നു; അതിന്റെ വ്യവസ്ഥകൾ പാലിച്ചിട്ടില്ലെന്ന് അവകാശവാദി മറുപടി നൽകുന്നു, അതിനാൽ പ്രതിരോധം പരാജയപ്പെടുന്നു. ആർട്ടിക്കിൾ പ്രകാരമുള്ള കരാർ പരിഹാരങ്ങൾ. 6:265 BW സമാന്തരമായി പ്രവർത്തിക്കുന്നു, പക്ഷേ പകർപ്പവകാശമാണ് ശക്തമായ മാർഗം.

പരിഹാരങ്ങൾ. ആർട്ടിക്കിൾ പ്രകാരമുള്ള ഒരു ഇൻജക്ഷൻ. 3:296 BW, സാധാരണയായി പിഴ അടയ്ക്കലും സംഗ്രഹ നടപടിക്രമങ്ങളിൽ ലഭ്യമാണ്; ആർട്ടിക്കിൾ പ്രകാരമുള്ള നാശനഷ്ടങ്ങൾ. 27 Aw, ആർട്ടിക്കിൾ പ്രകാരമുള്ള ലാഭത്തിന്റെ കണക്ക്. 27a Aw; ആർട്ടിക്കിൾ പ്രകാരമുള്ള തിരിച്ചുവിളിക്കൽ, കീഴടങ്ങൽ അല്ലെങ്കിൽ നാശം. 28 Aw; ആർട്ടിക്കിൾ പ്രകാരമുള്ള ന്യായമായതും ആനുപാതികവുമായ നിയമപരമായ ചെലവുകളുടെ പൂർണ്ണമായ വീണ്ടെടുക്കൽ. 1019h Rv. സോഫ്റ്റ്‌വെയർ സൗജന്യമായി വിതരണം ചെയ്തിടത്ത്, നഷ്ടം കണക്കാക്കാൻ പ്രയാസമാണ്, കൂടാതെ ഒരു ജർമ്മൻ അപ്പീൽ കോടതി ഇൻജക്ഷൻ ഉയർത്തിപ്പിടിച്ചുകൊണ്ട് നഷ്ടപരിഹാരം നൽകാൻ വിസമ്മതിച്ചു (OLG Hamm 13 ജൂൺ 2017, 4 U 72/16). അപൂർവ്വമായി നാശനഷ്ടങ്ങൾ വരുത്തുന്നത് ഇതാണ്: ഇത് ഇൻജക്ഷൻ, തിരിച്ചുവിളിക്കൽ, ചെലവ് ഉത്തരവ്, നിങ്ങൾ ഒരിക്കലും പ്രസിദ്ധീകരിക്കാൻ ഉദ്ദേശിച്ചിട്ടില്ലാത്ത ഉറവിടം പ്രസിദ്ധീകരിക്കേണ്ടിവരിക എന്നിവയാണ്.

നിങ്ങൾ ഒരു അനുസരണ പ്രശ്നം കണ്ടെത്തുമ്പോൾ

സാധാരണയായി ഒരു ഉപഭോക്താവിന്റെ സുരക്ഷാ ചോദ്യാവലിയിൽ നിന്നോ, ജാഗ്രതയ്ക്കിടെയുള്ള ഒരു സ്കാനിൽ നിന്നോ, അല്ലെങ്കിൽ ഒരു അവകാശിയുടെ കത്തിൽ നിന്നോ കണ്ടെത്തൽ വരുന്നു. തുടർന്ന് പരിഹാര നടപടികൾ ഇപ്രകാരമാണ് നടക്കുന്നത്. എക്സ്പോഷർ ഗുരുതരമാണെങ്കിൽ ബാധിത ബിൽഡിന്റെ വിതരണം നിർത്തുക. ഏത് ഘടകം, ഏത് പതിപ്പ്, ഏത് ലൈസൻസ്, ഏത് ഉൽപ്പന്നങ്ങളും റിലീസുകളും ഏത് കാലയളവിൽ സ്ഥാപിക്കുക. ലൈസൻസിന് യഥാർത്ഥത്തിൽ എന്താണ് ആവശ്യമെന്ന് തീരുമാനിക്കുക - പലപ്പോഴും ഉറവിട റിലീസിന് പകരം ഒരു ആട്രിബ്യൂഷൻ ഫയൽ. ആർട്ടിഫാക്റ്റുകൾ തയ്യാറാക്കുക: അറിയിപ്പുകൾ, ലൈസൻസ് ടെക്സ്റ്റുകൾ, ബിൽഡ് സ്ക്രിപ്റ്റുകൾ ഉൾപ്പെടെയുള്ള അനുബന്ധ ഉറവിടം പൂർത്തിയാക്കുക, ഉപയോഗിച്ചിടത്ത് ഒരു രേഖാമൂലമുള്ള ഓഫർ. ഒരു അനുസരണയുള്ള റിലീസ് അയയ്ക്കുക, തുടർന്ന് നിങ്ങൾ ചെയ്യേണ്ടതുണ്ടോ എന്ന് വാദിക്കുന്നതിനുപകരം അവകാശിയുടെ ഉടമയോട് നിങ്ങൾ എന്താണ് ചെയ്തതെന്ന് പറയുക.

GPLv3, AGPLv3 എന്നിവയ്ക്ക് കീഴിൽ, രോഗശാന്തി വിൻഡോ വേഗതയ്ക്ക് നിയമപരമായ മൂല്യം നൽകുന്നു; GPLv2-ന് കീഴിൽ, രോഗശാന്തി അവകാശം ഇല്ല, അതുകൊണ്ടാണ് മിക്ക നിർവ്വഹണങ്ങളും ചർച്ച ചെയ്ത അനുസരണ കരാറിൽ അവസാനിക്കുന്നത്. ഒരു ആന്തരിക എഞ്ചിനീയറിംഗ് റിപ്പോർട്ടിനൊപ്പമല്ല, നിങ്ങളുടെ അഭിഭാഷകന്റെ ഉപദേശത്തിനാണ് പ്രത്യേകാവകാശം നൽകുന്നതെന്ന് ശ്രദ്ധിക്കുക.

എം&എയിലെ ഓപ്പൺ സോഴ്‌സും കൃത്യമായ ജാഗ്രതയും

ഒരു സോഫ്റ്റ്‌വെയർ ഏറ്റെടുക്കലിൽ, ഓപ്പൺ സോഴ്‌സ് ഒരു സ്റ്റാൻഡേർഡ് ഡിലിജൻസ് വർക്ക്‌സ്ട്രീമാണ്, കൂടാതെ കോർ ഉൽപ്പന്നത്തിലെ വെളിപ്പെടുത്താത്ത ഒരു കോപ്പിലെഫ്റ്റ് ഘടകം ഒരു ഇടപാടിനെ യഥാർത്ഥത്തിൽ ചലിപ്പിക്കുന്ന ചുരുക്കം ചില കണ്ടെത്തലുകളിൽ ഒന്നാണ്: ഉൽപ്പന്നത്തിന്റെ ഉറവിടം പുറത്തുവിടാതെ വിതരണം ചെയ്യാൻ കഴിയുന്നില്ലെങ്കിൽ, വാങ്ങുന്നയാൾ വില നിശ്ചയിച്ചതിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ആസ്തി സ്വന്തമാക്കുകയാണ്.

ഒരു കോഡ്‌ബേസ് സ്കാൻ, ലൈസൻസുകളുള്ള ഒരു ഘടക ഇൻവെന്ററി, സംഭാവകരുടെയും കോൺട്രാക്ടർമാരുടെയും ക്രമീകരണങ്ങളെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾ എന്നിവ പ്രതീക്ഷിക്കുക. ഒരു പ്രത്യേക നഷ്ടപരിഹാരം, പരിഹാരത്തിനായി കാത്തിരിക്കുന്ന ഒരു നിലനിർത്തൽ, നീക്കം ചെയ്യേണ്ട ഒരു വ്യവസ്ഥ മുൻവിധി, അല്ലെങ്കിൽ ഇഷ്ടാനുസരണം തുറന്ന ഉറവിട വാറന്റി എന്നിവയാണ് സാധാരണ ഫലങ്ങൾ. വിൽപ്പനക്കാർ ആദ്യം സ്കാൻ ചെയ്യണം: നിങ്ങൾ വെളിപ്പെടുത്തുന്ന കണ്ടെത്തലുകൾ ഒരു ചർച്ചയാണ്, വാങ്ങുന്നയാളുടെ ഉപദേഷ്ടാവ് നടത്തുന്ന കണ്ടെത്തലുകൾ ലിവറേജാണ്. വാങ്ങുന്നവർ "കമ്പനിയുടെ ഐപി ഉടമസ്ഥതയിലുള്ളതാണ്" എന്നല്ല, മറിച്ച് ഒരു ഉൽപ്പന്നവും ഉടമസ്ഥാവകാശ സോഴ്‌സ് കോഡ് വെളിപ്പെടുത്തേണ്ട ഓപ്പൺ സോഴ്‌സ് ഉൾപ്പെടുത്താത്ത ഒരു പ്രാതിനിധ്യമാണ് തേടേണ്ടത്.

ബിൽ ഓഫ് മെറ്റീരിയൽസ്, സ്കാനിംഗ്, സൈബർ റെസിലിയൻസ് ആക്ട്

ഒരു സോഫ്റ്റ്‌വെയർ ബിൽ ഓഫ് മെറ്റീരിയൽസ് എന്നത് ഒരു ഉൽപ്പന്നത്തിന്റെ ഘടകങ്ങളുടെ ഒരു ഇൻവെന്ററിയാണ്, അതിൽ പതിപ്പുകളും ലൈസൻസുകളും ഉൾപ്പെടുന്നു. അടുത്ത കാലം വരെ പൂർണ്ണമായും കരാർ പ്രകാരമായിരുന്നു, ഇപ്പോൾ ഇത് നിയന്ത്രണപരവുമാണ്.

സൈബർ റെസിലിയൻസ് ആക്ട്, റെഗുലേഷൻ (EU) 2024/2847, 2024 ഡിസംബർ 10-ന് പ്രാബല്യത്തിൽ വന്നു, ഘട്ടം ഘട്ടമായി ഇത് നിലവിൽ വന്നു. ഉൽപ്പന്നത്തെയല്ല, സ്ഥാപനത്തെയാണ് ഇത് അഭിസംബോധന ചെയ്യുന്നത്. സജീവമായി ചൂഷണം ചെയ്യപ്പെടുന്ന ദുർബലതകൾക്കും ഗുരുതരമായ സംഭവങ്ങൾക്കും റിപ്പോർട്ടിംഗ് ബാധ്യതകൾ കലയിൽ. 14 CRA 2026 സെപ്റ്റംബർ 11 മുതൽ ബാധകമാണ്; 2026 ജൂൺ 11 മുതൽ അനുരൂപീകരണ വിലയിരുത്തൽ ബോഡികളുടെ വിജ്ഞാപനത്തിലെ വ്യവസ്ഥകൾ; 2027 ഡിസംബർ 11 മുതൽ പൂർണ്ണ നിയന്ത്രണം (കല. 71 CRA). സാധാരണയായി ഉപയോഗിക്കുന്നതും മെഷീൻ വായിക്കാൻ കഴിയുന്നതുമായ ഫോർമാറ്റിലുള്ള മെറ്റീരിയലുകളുടെ ഒരു സോഫ്റ്റ്‌വെയർ ബിൽ തയ്യാറാക്കുന്നത് ഉൾപ്പെടെ, ഉൽപ്പന്നത്തിലെ ഘടകങ്ങൾ തിരിച്ചറിയാനും രേഖപ്പെടുത്താനും Annex I CRA നിർമ്മാതാക്കളോട് ആവശ്യപ്പെടുന്നു, കുറഞ്ഞത് ഉയർന്ന തലത്തിലുള്ള ആശ്രിതത്വങ്ങൾ ഉൾക്കൊള്ളുന്നു. ഇത് പ്രസിദ്ധീകരിക്കേണ്ടതില്ല; മാർക്കറ്റ് നിരീക്ഷണ അധികാരികൾക്ക് ഇത് അഭ്യർത്ഥിക്കാം.

വാണിജ്യ പ്രവർത്തനങ്ങൾക്ക് പുറത്ത് വിതരണം ചെയ്യുന്ന സ്വതന്ത്ര, ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയർ CRA-യ്ക്ക് പുറത്താണ്. വാണിജ്യ പ്രവർത്തനങ്ങൾക്കായി ഉദ്ദേശിച്ചിട്ടുള്ള ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയറിന്റെ വികസനത്തിന് സ്ഥിരമായ പിന്തുണ നൽകുന്ന നിയമപരമായ വ്യക്തിയായ ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയർ സ്റ്റ്യൂവാർഡിനെ റെഗുലേഷൻ പരിചയപ്പെടുത്തുന്നു - കലയിൽ ലഘുവായ ബാധ്യതകളോടെ. 24 CRA: ഒരു ഡോക്യുമെന്റഡ് സൈബർ സുരക്ഷാ നയം, മാർക്കറ്റ് നിരീക്ഷണ അധികാരികളുമായുള്ള സഹകരണം, റിപ്പോർട്ടിംഗ്. നിങ്ങൾ ഓപ്പൺ സോഴ്‌സ് വാണിജ്യവൽക്കരിക്കുകയോ മറ്റുള്ളവർ വാണിജ്യവൽക്കരിക്കുകയോ ചെയ്യുന്ന ഒരു പ്രോജക്റ്റിന് ധനസഹായം നൽകുകയോ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾ ഏത് പങ്കാണ് വഹിക്കുന്നതെന്ന് സ്ഥാപിക്കുക. കമ്മീഷൻ അതിന്റെ ആദ്യ മാർഗ്ഗനിർദ്ദേശം 2026 ജൂലൈ 27 ന് സ്വീകരിച്ചു: കമ്മ്യൂണിക്കേഷൻ സി (2026) 5252 നോട് അനുബന്ധിച്ച സൈബർ റെസിലിയൻസ് ആക്റ്റ് (CRA) പ്രയോഗിക്കുന്നതിനെക്കുറിച്ചുള്ള കമ്മീഷൻ മാർഗ്ഗനിർദ്ദേശം, ഇത് സ്വതന്ത്ര, ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയർ പരിധിയിൽ വരുമ്പോൾ മറ്റ് കാര്യങ്ങൾക്കൊപ്പം പരിഗണിക്കുന്നു. സോഫ്റ്റ്‌വെയർ മെറ്റീരിയലുകളുടെ ബില്ലിനായി ഒരു ഫോർമാറ്റ് നിർദ്ദേശിക്കുന്ന ഒരു നടപ്പിലാക്കൽ നിയമവും സ്വീകരിച്ചിട്ടില്ല, അതിനാൽ റെഗുലേഷന്റെ സ്വന്തം മാനദണ്ഡം - സാധാരണയായി ഉപയോഗിക്കുന്ന, മെഷീൻ-റീഡബിൾ ഫോർമാറ്റ് - തൽക്കാലം അളവുകോലായി തുടരുന്നു.

CI-യിൽ പ്രവർത്തിക്കുന്ന സോഫ്റ്റ്‌വെയർ കോമ്പോസിഷൻ വിശകലനം, കംപ്ലയൻസ്, ലൈസൻസ് അവലോകനം, ജാഗ്രത എന്നിവ ഒരേസമയം നൽകുന്ന ഇൻവെന്ററി സൃഷ്ടിക്കുന്നു. അത്തരം ഉപകരണങ്ങൾ വെണ്ടേർഡ് കോഡ് കാണുന്നില്ല, ഡ്യുവൽ-ലൈസൻസുള്ള പ്രോജക്റ്റുകളെ തെറ്റായി തിരിച്ചറിയുന്നു, കൂടാതെ ഒരു ലൈസൻസിന്റെ വ്യവസ്ഥകൾ വായിക്കാൻ കഴിയില്ല: ഔട്ട്‌പുട്ടിനെ അവലോകനത്തിന്റെ തുടക്കമായി കണക്കാക്കുക, അവലോകനമല്ല.

നിങ്ങളുടെ സ്വന്തം കോഡ് പ്രസിദ്ധീകരിക്കുകയാണെങ്കിൽ: CLA-കളും DCO-യും

കോഡ് പുറത്തിറക്കുകയും പുറത്തുനിന്നുള്ള സംഭാവനകൾ സ്വീകരിക്കുകയും ചെയ്യുന്ന ഒരു കമ്പനി, അത് ലയിപ്പിക്കുന്ന കാര്യങ്ങളിൽ അവകാശമുണ്ടെന്ന് അറിഞ്ഞിരിക്കണം. ഒരു കോൺട്രിബ്യൂട്ടർ ലൈസൻസ് കരാർ എന്നത് പ്രോജക്റ്റും കോൺട്രിബ്യൂട്ടറും തമ്മിലുള്ള ഒരു കരാറാണ്, സാധാരണയായി ഒരു വിശാലമായ പകർപ്പവകാശ ലൈസൻസും എക്സ്പ്രസ് പേറ്റന്റ് ലൈസൻസും നൽകുന്നു, ഒറിജിനാലിറ്റിയും അധികാരവും സംബന്ധിച്ച് വാറന്റികളുണ്ട്. ഒരു കമ്പനിക്ക് പിന്നീട് അതിന്റെ പ്രോജക്റ്റ് വീണ്ടും ലൈസൻസ് ചെയ്യാനോ ഒരു ഓപ്പൺ സോഴ്‌സ് ലൈസൻസിനൊപ്പം വാണിജ്യ ലൈസൻസുകൾ നൽകാനോ ഇത് അനുവദിക്കുന്നു. അതിന്റെ ചെലവ് സംഘർഷമാണ്.

ലിനക്സ് കേർണലും മറ്റ് നിരവധി പ്രോജക്ടുകളും ഉപയോഗിക്കുന്ന ഡെവലപ്പർ സർട്ടിഫിക്കറ്റ് ഓഫ് ഒറിജിൻ , ഒരു ലൈസൻസ് ഗ്രാന്റ് അല്ല, മറിച്ച് ഒരു ലഘുവായ അറ്റസ്റ്റേഷനാണ്, ഓരോ കമ്മിറ്റിനും ഒരു സൈൻ-ഓഫ് ലൈൻ ആയി ചേർത്തിരിക്കുന്നു, ഇത് സംഭാവകന് പ്രോജക്റ്റിന്റെ ലൈസൻസിന് കീഴിൽ കോഡ് സമർപ്പിക്കാൻ കഴിയും. കുറഞ്ഞ ഭാരവും കുറഞ്ഞ സംരക്ഷണവും: പേറ്റന്റ് ലൈസൻസ് ഇല്ല, റീലൈസൻസിംഗ് ഇല്ല.

ഇരട്ട ലൈസൻസിംഗ് അല്ലെങ്കിൽ ഭാവി അവശിഷ്ടം സാധ്യമാണെങ്കിൽ, ഒരു CLA ഉപയോഗിക്കുക; പ്രോജക്റ്റ് ഒരു യഥാർത്ഥ കോമൺസ് ആണെങ്കിൽ, സാധാരണയായി DCO മതിയാകും. ഏത് സാഹചര്യത്തിലും, നിങ്ങളുടെ തൊഴിൽ, കോൺട്രാക്ടർ കരാറുകൾ നിങ്ങളുടെ ആളുകൾ എഴുതുന്ന കോഡിൽ പകർപ്പവകാശം നൽകുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.

ഒരു പ്രായോഗിക നയ പരിശോധനാ പട്ടിക

• ഓരോ ഉൽപ്പന്നത്തിനും ഒരു ഘടക ഇൻവെന്ററി സൃഷ്ടിച്ച് ബിൽഡ് പൈപ്പ്‌ലൈനിൽ പുറത്തിറക്കുക, കൈകൊണ്ട് അല്ല.
• ഒരു ആന്തരിക നയം പ്രസിദ്ധീകരിക്കുക: അനുവദനീയമായ ഒരു ലിസ്റ്റ്, നിരോധിത ലിസ്റ്റ്, മറ്റെല്ലാത്തിനും ഒരു അംഗീകാര റൂട്ട്.
• വിതരണമായി കണക്കാക്കുന്നത് എന്താണെന്ന് എഴുതി നിർവചിക്കുക — ഓൺ-പ്രെമൈസ് ഇൻസ്റ്റാളുകൾ, വീട്ടുപകരണങ്ങൾ, കണ്ടെയ്‌നറുകൾ, SDK-കൾ, മൊബൈൽ ആപ്പുകൾ, ഫേംവെയർ.
• ഓരോ ഉൽപ്പന്നത്തിനൊപ്പം ജനറേറ്റ് ചെയ്ത ഒരു ആട്രിബ്യൂഷൻ ഫയൽ അയയ്ക്കുക.
• ഒരു ഘടകം തിരഞ്ഞെടുക്കുമ്പോൾ, റിലീസ് ചെയ്യുന്ന സമയത്തല്ല, ഡിസൈൻ ചെയ്യുന്ന സമയത്താണ് ലൈസൻസ് ചോയ്‌സുകൾ അംഗീകരിക്കുക.
• പേറ്റന്റ് ഗ്രാന്റുകൾ കണക്കിലെടുത്ത്, ബാഹ്യ പദ്ധതികളിലേക്കുള്ള സംഭാവനകൾക്ക് അംഗീകാരം ആവശ്യമുണ്ടോ എന്ന് തീരുമാനിക്കുക, ആദ്യ ബാഹ്യ സംഭാവനയ്ക്ക് മുമ്പ് ഒരു CLA അല്ലെങ്കിൽ ഒരു DCO തിരഞ്ഞെടുക്കുക.
• ഉൽപ്പന്നത്തിലെ ഓപ്പൺ സോഴ്‌സുമായി ഐപി വാറന്റികൾ, നഷ്ടപരിഹാരങ്ങൾ, എസ്ക്രോ നിബന്ധനകൾ എന്നിവ യോജിപ്പിക്കുക.
• ഫണ്ട്‌റൈസിംഗ് അല്ലെങ്കിൽ വിൽപ്പന പ്രക്രിയയ്ക്ക് മുമ്പ് അവലോകനം നടത്തുക, ഒന്നിനിടയിലല്ല.

Law & More സോഫ്റ്റ്‌വെയർ കമ്പനികൾക്കും അവരുടെ നിക്ഷേപകർക്കും ഉപദേശം നൽകുന്നത് Eindhoven ഒപ്പം Amsterdam ഓപ്പൺ സോഴ്‌സ് കംപ്ലയൻസ്, ലൈസൻസ് അവലോകനം, കോൺട്രിബ്യൂട്ടർ ക്രമീകരണങ്ങൾ, ഒരു ഇടപാടിലെ ഓപ്പൺ സോഴ്‌സ് വർക്ക്‌സ്ട്രീം എന്നിവയിൽ.