ໃບອະນຸຍາດຊອບແວແຫຼ່ງເປີດພາຍໃຕ້ກົດໝາຍຂອງໂຮນລັງ ແລະ ສະຫະພາບເອີຣົບ

ເກືອບທຸກຜະລິດຕະພັນຊອບແວການຄ້າມີອົງປະກອບແຫຼ່ງເປີດ, ໂດຍປົກກະຕິແລ້ວແມ່ນຫຼາຍຮ້ອຍອັນ, ເຊິ່ງຖືກເລືອກໂດຍນັກພັດທະນາແທນທີ່ຈະເປັນທະນາຍຄວາມ. ນັ້ນກາຍເປັນບັນຫາເມື່ອບໍ່ມີໃຜສາມາດບອກໄດ້ວ່າໃບອະນຸຍາດໃດທີ່ໃຊ້ໄດ້, ສິ່ງທີ່ພວກມັນຕ້ອງການ, ແລະຜະລິດຕະພັນນັ້ນປະຕິບັດຕາມຫຼືບໍ່. ບົດຄວາມນີ້ອະທິບາຍວ່າໃບອະນຸຍາດແຫຼ່ງເປີດເຮັດວຽກແນວໃດພາຍໃຕ້ກົດໝາຍຂອງໂຮນລັງ ແລະ ສະຫະພາບເອີຣົບ, ບ່ອນທີ່ມີຄວາມສ່ຽງ, ແລະສິ່ງທີ່ຕ້ອງມີ.

ໃບອະນຸຍາດແຫຼ່ງເປີດແມ່ນຫຍັງ, ໃນແງ່ທາງກົດໝາຍ

ໃບອະນຸຍາດແຫຼ່ງເປີດແມ່ນໃບອະນຸຍາດລິຂະສິດທີ່ໄດ້ຮັບອະນຸຍາດພາຍໃຕ້ເງື່ອນໄຂ. ມັນບໍ່ແມ່ນການຍົກເວັ້ນ, ບໍ່ແມ່ນການອຸທິດໃຫ້ແກ່ສາທາລະນະ, ບໍ່ແມ່ນການປະຖິ້ມສິດ. ຜູ້ຂຽນຍັງຄົງຮັກສາລິຂະສິດພາຍໃຕ້ມາດຕາ 1 Aw ແລະ ມາດຕາ 10 Aw, ເຊິ່ງປົກປ້ອງໂປຣແກຣມຄອມພິວເຕີເປັນຜົນງານ, ແລະໃບອະນຸຍາດອະນຸຍາດໃຫ້ມີການກະທຳທີ່ຈະລະເມີດສິດທິສະເພາະພາຍໃຕ້ມາດຕາ 12 Aw ແລະ ມາດຕາ 13 Aw.

ຜົນສະທ້ອນມີຄວາມສຳຄັນຫຼາຍກວ່າຄຳນິຍາມ. ປະຕິບັດຕາມ, ແລະການຄັດລອກ ແລະ ການແຈກຢາຍຂອງທ່ານແມ່ນຖືກຕ້ອງຕາມກົດໝາຍ. ການບໍ່ປະຕິບັດຕາມ, ແລະການອະນຸຍາດບໍ່ໄດ້ກວມເອົາສິ່ງທີ່ທ່ານໄດ້ເຮັດ: ການນຳໃຊ້ຂອງທ່ານແມ່ນການລະເມີດລິຂະສິດ, ບໍ່ແມ່ນການລະເມີດສັນຍາ. ໃບອະນຸຍາດລິຂະສິດສ່ວນໃຫຍ່ເສີມສ້າງສິ່ງນີ້ໂດຍການຢຸດຕິໂດຍອັດຕະໂນມັດເມື່ອມີການລະເມີດ - GPLv2 ໂດຍບໍ່ມີໄລຍະເວລາແກ້ໄຂໃດໆ, ໃນຂະນະທີ່ GPLv3 ແລະ AGPLv3 ຈະຟື້ນຟູສິດຄືນໃໝ່ຖ້າການລະເມີດໄດ້ຮັບການແກ້ໄຂພາຍໃນໄລຍະເວລາທີ່ກຳນົດໄວ້ຫຼັງຈາກການແຈ້ງການ.

ສານໂຮນລັງໃຊ້ເຫດຜົນນີ້. ໃນ Rb. Amsterdam ໃນວັນທີ 22 ກັນຍາ 2020, ECLI:NL:RBAMS:2020:4717, ຜູ້ຈັດຈຳໜ່າຍທີ່ໄດ້ລຶບຂໍ້ຄວາມໃບອະນຸຍາດ ແລະ ແຈ້ງການລິຂະສິດອອກຈາກຖານຂໍ້ມູນລະຫັດທີ່ຖືກແຍກອອກໄດ້ຖືກຖືວ່າໄດ້ສູນເສຍການອະນຸຍາດ ແລະ ເປັນການລະເມີດ. ການເພີ່ມລະຫັດໃໝ່ຈຳນວນຫຼວງຫຼາຍບໍ່ໄດ້ສ້າງຜົນງານທີ່ເປັນເອກະລາດ: ຕົ້ນສະບັບຍັງຄົງຢູ່ຢ່າງຮັບຮູ້ໄດ້, ດັ່ງນັ້ນພັນທະຕ່າງໆຈຶ່ງມາພ້ອມກັບມັນ.

ສອງຄອບຄົວຄື: ຄອບຄົວທີ່ອະນຸຍາດ ແລະ ຄອບຄົວທີ່ລິຂະສິດ

ໃບອະນຸຍາດທີ່ໄດ້ຮັບອະນຸຍາດ — MIT, ໃບອະນຸຍາດ BSD, Apache 2.0 — ອະນຸຍາດໃຫ້ນຳໃຊ້, ດັດແປງ ແລະ ແຈກຢາຍຄືນໃໝ່, ລວມທັງຜະລິດຕະພັນແຫຼ່ງປິດພາຍໃນ, ໂດຍມີເງື່ອນໄຂວ່າທ່ານຮັກສາແຈ້ງການລິຂະສິດ ແລະ ຂໍ້ຄວາມໃບອະນຸຍາດໄວ້.

ໃບອະນຸຍາດ Copyleft ຮຽກຮ້ອງໃຫ້ເມື່ອທ່ານແຈກຢາຍຊອບແວ ຫຼື ບາງສິ່ງບາງຢ່າງທີ່ສ້າງຂຶ້ນໃນຊອບແວນັ້ນ, ທ່ານຕ້ອງເຮັດແນວນັ້ນພາຍໃຕ້ໃບອະນຸຍາດດຽວກັນ ແລະ ເຮັດໃຫ້ແຫຼ່ງຂໍ້ມູນທີ່ສອດຄ້ອງກັນສາມາດໃຊ້ໄດ້. ພວກມັນແຕກຕ່າງກັນໃນການເຂົ້າເຖິງ.

ຕົວກະຕຸ້ນ copyleft ແລະຄຳຖາມກ່ຽວກັບການເຊື່ອມໂຍງ

ພັນທະຂອງລິຂະສິດມີຂອບເຂດຈຳກັດໃນການແຈກຢາຍ, ບໍ່ແມ່ນການນຳໃຊ້. ບໍລິສັດທີ່ດຳເນີນຊອບແວ GPL ພາຍໃນ, ເຖິງວ່າຈະມີການດັດແປງຢ່າງໜັກ, ກໍ່ບໍ່ໄດ້ແຈກຢາຍຫຍັງເລີຍ ແລະ ບໍ່ເປັນໜີ້ຫຍັງເລີຍ. “ພວກເຮົາໄດ້ແຈກຢາຍແລ້ວບໍ?” ແມ່ນຄຳຖາມທຳອິດສະເໝີ, ແລະ ມັນແມ່ນເຫດຜົນທີ່ວ່າເປັນຫຍັງຄອນເທນເນີ, ອຸປະກອນ, ເຟີມແວ ແລະ SDK ຈຶ່ງມີຄວາມສຳຄັນຫຼາຍກວ່າເຄື່ອງມືພາຍໃນ.

ຄຳຖາມທີສອງແມ່ນຍາກກວ່າ. GPL ກ່າວເຖິງ “ຜົນງານທີ່ອີງໃສ່ໂຄງການ”, ໂດຍຢືມແນວຄວາມຄິດຂອງອາເມລິກາກ່ຽວກັບຜົນງານອະນຸພັນ. ກົດໝາຍຂອງໂຮນລັງບໍ່ມີຄຳສັບດັ່ງກ່າວ: ການວິເຄາະດຳເນີນໄປຜ່ານສິດທິໃນການສຳເນົາ ແລະ ການດັດແປງ, ໂດຍຖາມວ່າ ການສະແດງອອກທີ່ໄດ້ຮັບການປົກປ້ອງຈາກຕົ້ນສະບັບໄດ້ຖືກສຳເນົາແລ້ວຫຼືບໍ່.

ກໍລະນີປະຕິບັດແມ່ນການເຊື່ອມໂຍງ. ບໍ່ວ່າການເຊື່ອມໂຍງໂມດູນທີ່ເປັນເຈົ້າຂອງກັບຫ້ອງສະໝຸດ GPL ຈະສ້າງຜົນງານໜຶ່ງທີ່ຢູ່ພາຍໃຕ້ລິຂະສິດຫຼືບໍ່ນັ້ນ ບໍ່ເຄີຍຖືກຕັດສິນໂດຍສານໂຮນລັງ, ແລະບໍ່ມີອຳນາດ EU ທີ່ມີຜົນບັງຄັບໃຊ້. ທັດສະນະຂອງມູນນິທິຊອບແວເສລີທີ່ວ່າການເຊື່ອມໂຍງສ້າງຜົນງານລວມກັນແມ່ນການຕີຄວາມໝາຍຂອງຜູ້ຄຸ້ມຄອງໃບອະນຸຍາດ, ບໍ່ແມ່ນກົດໝາຍ, ແລະທັດສະນະທີ່ກົງກັນຂ້າມກໍ່ຍັງບໍ່ໄດ້ຮັບການທົດສອບເຊັ່ນກັນ. ຄຳຕອບທີ່ອິນເຕີເນັດມັກທີ່ສຸດ - ການເຊື່ອມຕໍ່ແບບໄດນາມິກທີ່ປອດໄພ, ການເຊື່ອມຕໍ່ແບບຄົງທີ່ບໍ່ແມ່ນ - ບໍ່ມີພື້ນຖານໃນກົດໝາຍລິຂະສິດຂອງໂຮນລັງ, ເຊິ່ງບໍ່ໄດ້ຖາມວ່າຕົວລວບລວມມີພຶດຕິກຳແນວໃດ. ການວິເຄາະທີ່ປ້ອງກັນໄດ້ຫຼາຍກວ່ານັ້ນຖາມວ່າອົງປະກອບຕ່າງໆຖືກລວມເຂົ້າກັນຢ່າງໃກ້ຊິດແນວໃດ: ພວກມັນແບ່ງປັນພື້ນທີ່ທີ່ຢູ່ ແລະໂຄງສ້າງຂໍ້ມູນບໍ, ການລວມກັນຖືກສົ່ງເປັນຜະລິດຕະພັນດຽວບໍ, ສາມາດເຮັດວຽກໄດ້ຢ່າງດຽວ, ຝ່າຍທີ່ເປັນເຈົ້າຂອງສ້າງຫົວຂໍ້, ມາໂຄຣ ຫຼືລະຫັດໃນແຖວຈາກຝ່າຍທີ່ເປັນເຈົ້າຂອງບໍ? ຄຳຖາມເຫຼົ່ານັ້ນມັກຈະແກ້ໄຂຄວາມສ່ຽງ. ບ່ອນທີ່ພວກມັນບໍ່ເຮັດ, ແຍກອົງປະກອບໄວ້ເບື້ອງຫຼັງຂອບເຂດຂະບວນການ, ປ່ຽນແທນມັນ, ຫຼືເອົາໃບອະນຸຍາດການຄ້າ.

AGPL ແລະ ການໃຊ້ເຄືອຂ່າຍ

AGPL ມີຢູ່ເພາະວ່າ copyleft ຖືກກະຕຸ້ນໂດຍການແຈກຢາຍ ແລະ ຜູ້ໃຫ້ບໍລິການ SaaS ບໍ່ໄດ້ແຈກຢາຍ. ຂໍ້ເຄືອຂ່າຍຂອງມັນຮຽກຮ້ອງໃຫ້ຖ້າທ່ານດັດແປງຊອບແວ ແລະ ເຮັດໃຫ້ມັນສາມາດໃຊ້ໄດ້ກັບຜູ້ໃຊ້ທີ່ພົວພັນກັບມັນຈາກໄລຍະໄກ, ທ່ານຈະຕ້ອງສະເໜີແຫຼ່ງຂໍ້ມູນທີ່ສອດຄ້ອງກັນຂອງເວີຊັນທີ່ຖືກດັດແກ້ຂອງທ່ານໃຫ້ພວກເຂົາ.

ມີສາມຈຸດທີ່ມັກຖືກພາດໄປ. ພັນທະດັ່ງກ່າວຈະແລ່ນໄປຫາຜູ້ໃຊ້ບໍລິການ, ເຊິ່ງໃນຜະລິດຕະພັນການລົງທະບຽນເປີດແມ່ນບໍ່ຄ່ອຍມີຄວາມສະດວກສະບາຍເທົ່າໃດ. ມັນຖືກກະຕຸ້ນໂດຍການດັດແປງ, ສະນັ້ນອົງປະກອບທີ່ບໍ່ໄດ້ດັດແປງຈະບໍ່ມີສ່ວນຮ່ວມກັບມັນ ແຕ່ການສ້າງທີ່ຖືກແກ້ໄຂອາດຈະມີສ່ວນຮ່ວມ. ແລະມັນເຮັດໃຫ້ເກີດຄຳຖາມກ່ຽວກັບການເຮັດວຽກຮ່ວມກັນຄືກັນກັບ GPL ສຳລັບສ່ວນທີ່ເຫຼືອຂອງ stack ຂອງທ່ານ - ຊຶ່ງເປັນເຫດຜົນທີ່ບໍລິສັດຫຼາຍແຫ່ງຫ້າມ AGPL ໃນລະຫັດການຜະລິດ.

ຄວາມເຂົ້າກັນໄດ້ຂອງໃບອະນຸຍາດ

ຄວາມເຂົ້າກັນໄດ້ແມ່ນບັນຫາຂອງການລວມອົງປະກອບທີ່ໃບອະນຸຍາດມີພັນທະທີ່ບໍ່ສາມາດປະຕິບັດໄດ້ທັງສອງຢ່າງໃນການແຈກຢາຍດຽວ: ໃບອະນຸຍາດທີ່ອະນຸຍາດແມ່ນເຂົ້າກັນໄດ້ກັບເກືອບທຸກຢ່າງ, ໃບອະນຸຍາດລິຂະສິດເທົ່ານັ້ນທີ່ມີເງື່ອນໄຂຂອງຕົນເອງອະນຸຍາດ. ກໍລະນີມາດຕະຖານແມ່ນ Apache 2.0 ແລະ GPLv2. ມູນນິທິຊອບແວ Apache ແລະ ມູນນິທິຊອບແວເສລີເຫັນດີວ່າການລວມກັນບໍ່ໄດ້ຮັບອະນຸຍາດ, ເພາະວ່າຂໍ້ກຳນົດການຢຸດຕິສິດທິບັດ ແລະ ການຊົດເຊີຍຂອງ Apache 2.0 ແມ່ນຂໍ້ຈຳກັດເພີ່ມເຕີມທີ່ GPLv2 ບໍ່ອະນຸຍາດ. GPLv3 ໄດ້ຖືກຮ່າງຂຶ້ນເພື່ອຍອມຮັບພວກມັນ. ຄວາມເຂົ້າກັນໄດ້ຍັງເປັນທິດທາງ: ລະຫັດ Apache ສາມາດຖືກດູດຊຶມເຂົ້າໃນໂຄງການ GPLv3, ແຕ່ບໍ່ແມ່ນກົງກັນຂ້າມ. ອົງປະກອບ GPL ໜຶ່ງໃນສະຖານທີ່ທີ່ບໍ່ຖືກຕ້ອງສາມາດບັງຄັບໃຫ້ມີການເລືອກລະຫວ່າງການອອກໃບອະນຸຍາດຄືນໃໝ່, ວິສະວະກຳຄືນໃໝ່ ຫຼື ການລຶບອອກ - ລາຄາຖືກກວ່າກ່ອນການປ່ອຍຕົວກ່ວາຫຼັງຈາກນັ້ນ.

ພັນທະໃນການໃຫ້ເຫດຜົນ ແລະ ການແຈ້ງບອກ

ພັນທະທີ່ຖືກລະເມີດເລື້ອຍໆທີ່ສຸດແມ່ນພັນທະທີ່ໜ້ອຍທີ່ສຸດ: ການສ້າງສຳເນົາແຈ້ງການລິຂະສິດ, ຂໍ້ຄວາມອະນຸຍາດ, ຂໍ້ປະຕິເສດຄວາມຮັບຜິດຊອບ ແລະ ພາຍໃຕ້ Apache 2.0, ເນື້ອໃນແຈ້ງການໃນເອກະສານທີ່ມາພ້ອມກັບການແຈກຢາຍ. ທຸກໆຄອບຄົວບັງຄັບໃຊ້ພວກມັນ, ລວມທັງ 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, ຊີ້ນຳໃຫ້ອົງການພາກລັດຈັດລຳດັບຄວາມສຳຄັນຂອງວິທີແກ້ໄຂການເຮັດວຽກຮ່ວມກັນໂດຍບໍ່ມີເງື່ອນໄຂການອອກໃບອະນຸຍາດທີ່ຈຳກັດ, ເຊັ່ນ: ແຫຼ່ງເປີດ, ບ່ອນທີ່ທຽບເທົ່າ; ໃນລະດັບຊາດ, ຫຼັກການຂອງ ແຫຼ່ງເປີດ, tenzij ແມ່ນຂຶ້ນກັບການຕັດສິນໃຈຂອງຄະນະລັດຖະມົນຕີ ແລະ ແນວທາງນະໂຍບາຍ, ບໍ່ແມ່ນກົດໝາຍ: Wet digitale overheid ອຳນວຍຄວາມສະດວກໃຫ້ແກ່ໂຄງສ້າງພື້ນຖານການລະບຸຕົວຕົນດິຈິຕອນ ແຕ່ບໍ່ມີພັນທະທີ່ບັງຄັບໃຊ້ໄດ້ໃນການເຜີຍແຜ່ລະຫັດແຫຼ່ງທັງໝົດ. ອ່ານເອກະສານປະມູນ: ຂໍ້ກຳນົດ EUPL ຜູກມັດຜົນງານຂອງທ່ານ ແລະ ອາດຈະບໍ່ເຂົ້າກັນໄດ້ກັບລະຫັດທີ່ເປັນເຈົ້າຂອງທີ່ທ່ານຕັ້ງໃຈທີ່ຈະນຳໃຊ້ຄືນ.

ການບັງຄັບໃຊ້ໃນການປະຕິບັດ

ຜູ້ທີ່ສາມາດຟ້ອງຮ້ອງໄດ້. ຜູ້ຖືສິດ — ຜູ້ປະກອບສ່ວນສ່ວນບຸກຄົນ, ຫຼື ມູນນິທິ ຫຼື ບໍລິສັດທີ່ຖືລິຂະສິດທີ່ໄດ້ຮັບມອບໝາຍ. ການຂຽນທີ່ແບ່ງແຍກແມ່ນອຸປະສັກທາງປະຕິບັດ: ຜູ້ຮຽກຮ້ອງຕ້ອງພິສູດຄວາມເປັນເຈົ້າຂອງລະຫັດທີ່ມີບັນຫາ. ສິ່ງນັ້ນໄດ້ເອົາຊະນະກໍລະນີ GPL ທີ່ມີຊື່ສຽງທີ່ສຸດຂອງເອີຣົບ, ບ່ອນທີ່ການຮຽກຮ້ອງຂອງນັກພັດທະນາ kernel ຕໍ່ຜູ້ຂາຍ virtualisation ລົ້ມເຫຼວຍ້ອນຂາດຫຼັກຖານການຂຽນ (LG Hamburg 8 ກໍລະກົດ 2016, 310 O 89/15; ຢືນຢັນ OLG Hamburg 28 ກຸມພາ 2019, 5 U 146/16).

ສິ່ງທີ່ກົດໝາຍວ່າດ້ວຍກໍລະນີກຳນົດໄວ້. ສານເຢຍລະມັນໄດ້ຍອມຮັບຊ້ຳແລ້ວຊ້ຳອີກວ່າໃບອະນຸຍາດແຫຼ່ງເປີດແມ່ນຖືກຕ້ອງ ແລະ ການລະເມີດດັ່ງກ່າວເຮັດໃຫ້ການແຈກຢາຍຜິດກົດໝາຍ, ເລີ່ມຕົ້ນດ້ວຍຄຳສັ່ງຫ້າມ GPL ທຳອິດ (LG München I 19 ພຶດສະພາ 2004, 21 O 6123/04). ສານລັດຖະບານກາງສະຫະລັດໄດ້ບັນລຸຂໍ້ສະຫຼຸບດຽວກັນໃນ Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): ເງື່ອນໄຂຂອງໃບອະນຸຍາດແມ່ນເງື່ອນໄຂກ່ຽວກັບຂອບເຂດຂອງການອະນຸຍາດ, ບໍ່ແມ່ນພຽງແຕ່ພັນທະສັນຍາ, ສະນັ້ນການລະເມີດສະໜັບສະໜູນການຮຽກຮ້ອງລິຂະສິດ ແລະ ການບັນເທົາທຸກດ້ວຍຄຳສັ່ງຫ້າມ. ການດຳເນີນຄະດີຂອງສະຫະລັດກຳລັງສຳຫຼວດວ່າຜູ້ຮັບທີ່ຢູ່ພາຍໃຕ້ສັນຍາສາມາດບັງຄັບໃຊ້ GPL ໃນຖານະເປັນຜູ້ຮັບຜົນປະໂຫຍດພາກສ່ວນທີສາມໄດ້ຫຼືບໍ່. ນັ້ນແມ່ນຄຳຖາມຫຼັກໃນ Software Freedom Conservancy v Vizio ຕໍ່ໜ້າສານສູງຄາລິຟໍເນຍ: ຜູ້ບໍລິໂພກ, ໃນຖານະເປັນຜູ້ຮັບຜົນປະໂຫຍດພາກສ່ວນທີສາມ, ສາມາດຮຽກຮ້ອງໃຫ້ປ່ອຍລະຫັດແຫຼ່ງຂໍ້ມູນພາຍໃຕ້ GPLv2 ໄດ້ຫຼືບໍ່. ຄຳຕັດສິນສຸດທ້າຍທີ່ສຳຄັນຄາດວ່າຈະມີການຕັດສິນຫຼັງຈາກການພິຈາລະນາຄະດີຂອງຄະນະລູກຂຸນໃນປີ 2026, ສະນັ້ນຈຸດດັ່ງກ່າວຍັງບໍ່ທັນໄດ້ຕັດສິນໃຈເທື່ອ.

ວິທີທີ່ສານໂຮນລັງຈະດຳເນີນການ. ໃນຖານະເປັນການລະເມີດລິຂະສິດພາຍໃຕ້ 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, ບໍ່ມີສິດທິໃນການແກ້ໄຂ, ຊຶ່ງເປັນເຫດຜົນທີ່ການບັງຄັບໃຊ້ສ່ວນໃຫຍ່ສິ້ນສຸດລົງດ້ວຍການປະຕິບັດຕາມຂໍ້ຕົກລົງ. ໃຫ້ສັງເກດວ່າສິດທິພິເສດແມ່ນຂຶ້ນກັບຄໍາແນະນໍາຈາກທະນາຍຄວາມຂອງທ່ານ, ບໍ່ແມ່ນບົດລາຍງານວິສະວະກໍາພາຍໃນ.

ແຫຼ່ງເປີດໃນການລວມຕົວ ແລະ ຊື້ກິດຈະການ ແລະ ການກວດສອບຢ່າງລະອຽດ

ໃນການຊື້ຊອບແວ, ແຫຼ່ງເປີດແມ່ນກະແສການເຮັດວຽກມາດຕະຖານ, ແລະອົງປະກອບ copyleft ທີ່ບໍ່ໄດ້ເປີດເຜີຍໃນຜະລິດຕະພັນຫຼັກແມ່ນໜຶ່ງໃນການຄົ້ນພົບບໍ່ຫຼາຍປານໃດທີ່ເຮັດໃຫ້ຂໍ້ຕົກລົງເກີດຂຶ້ນຢ່າງແທ້ຈິງ: ຖ້າຜະລິດຕະພັນບໍ່ສາມາດແຈກຢາຍໄດ້ໂດຍບໍ່ຕ້ອງປ່ອຍແຫຼ່ງຂໍ້ມູນຂອງມັນ, ຜູ້ຊື້ກຳລັງຊື້ຊັບສິນທີ່ແຕກຕ່າງຈາກອັນທີ່ມີລາຄາ.

ຄາດວ່າຈະມີການສະແກນລະຫັດຖານ, ສິນຄ້າຄົງຄັງສ່ວນປະກອບທີ່ມີໃບອະນຸຍາດ, ແລະ ຄຳຖາມກ່ຽວກັບການຈັດການຂອງຜູ້ປະກອບສ່ວນ ແລະ ຜູ້ຮັບເໝົາ. ຜົນໄດ້ຮັບທົ່ວໄປແມ່ນການຊົດເຊີຍສະເພາະ, ການຮັກສາໄວ້ທີ່ລໍຖ້າການແກ້ໄຂ, ເງື່ອນໄຂກ່ອນໜ້າທີ່ຕ້ອງການການລຶບອອກ, ຫຼື ການຮັບປະກັນແຫຼ່ງເປີດທີ່ສ້າງຂຶ້ນເອງ. ຜູ້ຂາຍຄວນສະແກນກ່ອນ: ຜົນການຄົ້ນພົບທີ່ທ່ານເປີດເຜີຍແມ່ນການເຈລະຈາ, ຜົນການຄົ້ນພົບທີ່ທີ່ປຶກສາຂອງຜູ້ຊື້ເຮັດແມ່ນຜົນປະໂຫຍດ. ຜູ້ຊື້ບໍ່ຄວນຊອກຫາ "ບໍລິສັດເປັນເຈົ້າຂອງ 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 ສ້າງສິນຄ້າຄົງຄັງທີ່ໃຫ້ບໍລິການການປະຕິບັດຕາມ, ການທົບທວນໃບອະນຸຍາດ ແລະ ການກວດສອບຢ່າງລະອຽດໃນເວລາດຽວກັນ. ເຄື່ອງມືດັ່ງກ່າວພາດລະຫັດທີ່ຈຳໜ່າຍ, ລະບຸໂຄງການທີ່ມີໃບອະນຸຍາດສອງຢ່າງຜິດພາດ ແລະ ບໍ່ສາມາດອ່ານເງື່ອນໄຂຂອງໃບອະນຸຍາດໄດ້: ຖືວ່າຜົນຜະລິດເປັນຈຸດເລີ່ມຕົ້ນຂອງການທົບທວນ, ບໍ່ແມ່ນການທົບທວນ.

ຖ້າທ່ານເຜີຍແຜ່ລະຫັດຂອງທ່ານເອງ: CLAs ແລະ DCO

ບໍລິສັດທີ່ປ່ອຍລະຫັດ ແລະ ຍອມຮັບການປະກອບສ່ວນຈາກພາຍນອກຕ້ອງຮູ້ວ່າຕົນມີສິດໃນສິ່ງທີ່ມັນລວມເຂົ້າກັນ. ສັນຍາອະນຸຍາດຜູ້ປະກອບສ່ວນ ແມ່ນສັນຍາລະຫວ່າງໂຄງການ ແລະ ຜູ້ປະກອບສ່ວນ, ໂດຍປົກກະຕິແລ້ວຈະໃຫ້ໃບອະນຸຍາດລິຂະສິດຢ່າງກວ້າງຂວາງ ແລະ ໃບອະນຸຍາດສິດທິບັດທີ່ຈະແຈ້ງ, ພ້ອມດ້ວຍການຮັບປະກັນກ່ຽວກັບຄວາມເປັນຕົ້ນສະບັບ ແລະ ສິດອຳນາດ. ມັນແມ່ນສິ່ງທີ່ຊ່ວຍໃຫ້ບໍລິສັດສາມາດອອກໃບອະນຸຍາດໂຄງການຂອງຕົນຄືນໃໝ່ໃນພາຍຫຼັງ, ຫຼື ສະເໜີໃບອະນຸຍາດທາງການຄ້າຄຽງຄູ່ກັບໃບອະນຸຍາດແຫຼ່ງເປີດ. ຄ່າໃຊ້ຈ່າຍຂອງມັນແມ່ນຄວາມຂັດແຍ້ງ.

ໃບ ຢັ້ງຢືນຕົ້ນກຳເນີດຂອງນັກພັດທະນາ , ທີ່ໃຊ້ໂດຍ Linux kernel ແລະໂຄງການອື່ນໆອີກຈຳນວນຫຼາຍ, ບໍ່ແມ່ນການອະນຸຍາດໃຫ້ໃຊ້ໃບອະນຸຍາດ ແຕ່ເປັນການຢັ້ງຢືນທີ່ມີນ້ຳໜັກເບົາ, ເພີ່ມເປັນແຖວລົງນາມໃສ່ແຕ່ລະຄຳໝັ້ນສັນຍາ, ວ່າຜູ້ປະກອບສ່ວນອາດຈະສົ່ງລະຫັດພາຍໃຕ້ໃບອະນຸຍາດຂອງໂຄງການ. ມີພາລະໜ້ອຍກວ່າ, ແລະ ປົກປ້ອງໜ້ອຍກວ່າ: ບໍ່ມີໃບອະນຸຍາດສິດທິບັດ, ບໍ່ມີການອອກໃບອະນຸຍາດຄືນໃໝ່.

ຖ້າການອອກໃບອະນຸຍາດສອງແບບ ຫຼື ການອອກໃບອະນຸຍາດຄືນໃໝ່ໃນອະນາຄົດເປັນໄປໄດ້, ໃຫ້ໃຊ້ CLA; ຖ້າໂຄງການເປັນໂຄງການສາທາລະນະທີ່ແທ້ຈິງ, DCO ມັກຈະພຽງພໍ. ບໍ່ວ່າຈະເປັນແນວໃດກໍ່ຕາມ, ໃຫ້ແນ່ໃຈວ່າສັນຍາຈ້າງງານ ແລະ ສັນຍາຜູ້ຮັບເໝົາຂອງທ່ານໄດ້ມອບໝາຍລິຂະສິດໃນລະຫັດທີ່ຄົນຂອງທ່ານຂຽນ.

ບັນຊີກວດສອບນະໂຍບາຍທີ່ໃຊ້ໄດ້ຈິງ

• ສ້າງສາງສ່ວນປະກອບຕໍ່ຜະລິດຕະພັນ ແລະ ການປ່ອຍໃນທໍ່ສົ່ງການຜະລິດ, ບໍ່ແມ່ນດ້ວຍມື.
• ເຜີຍແຜ່ນະໂຍບາຍພາຍໃນ: ບັນຊີລາຍຊື່ທີ່ໄດ້ຮັບອະນຸຍາດ, ບັນຊີລາຍຊື່ທີ່ຖືກຫ້າມ ແລະ ເສັ້ນທາງການອະນຸມັດສຳລັບທຸກຢ່າງອື່ນໆ.
• ໃຫ້ນິຍາມເປັນລາຍລັກອັກສອນວ່າສິ່ງທີ່ນັບເປັນການແຈກຢາຍແມ່ນຫຍັງ — ການຕິດຕັ້ງໃນສະຖານທີ່, ອຸປະກອນ, ຕູ້ຄອນເທນເນີ, SDKs, ແອັບມືຖື, ເຟີມແວ.
• ສົ່ງໄຟລ໌ການລະບຸຕົວຕົນທີ່ສ້າງຂຶ້ນພ້ອມກັບແຕ່ລະຜະລິດຕະພັນ.
• ອະນຸມັດຕົວເລືອກໃບອະນຸຍາດໃນເວລາອອກແບບ, ເມື່ອເລືອກອົງປະກອບ, ບໍ່ແມ່ນໃນເວລາປ່ອຍ.
• ຕັດສິນໃຈວ່າການປະກອບສ່ວນເຂົ້າໃນໂຄງການພາຍນອກຕ້ອງການການອະນຸມັດຫຼືບໍ່, ໂດຍພິຈາລະນາເຖິງການໃຫ້ສິດທິບັດທີ່ກ່ຽວຂ້ອງ, ແລະເລືອກ CLA ຫຼື DCO ກ່ອນການປະກອບສ່ວນຈາກພາຍນອກຄັ້ງທຳອິດ.
• ຈັດລຽງການຮັບປະກັນດ້ານຊັບສິນທາງປັນຍາ, ການຊົດເຊີຍ ແລະ ເງື່ອນໄຂຂອງ escrow ໃຫ້ສອດຄ່ອງກັບແຫຼ່ງເປີດຕົວຈິງໃນຜະລິດຕະພັນ.
• ດຳເນີນການທົບທວນຄືນກ່ອນຂະບວນການລະດົມທຶນ ຫຼື ການຂາຍ, ບໍ່ແມ່ນໃນລະຫວ່າງຂະບວນການດັ່ງກ່າວ.