ໃບອະນຸຍາດ GitHub – ພວກເຮົາເວົ້າກ່ຽວກັບຫຍັງ? ເພື່ອສ້າງຊອບແວ, ຄົນຫນຶ່ງຕ້ອງບໍ່ພຽງແຕ່ຂຽນມັນ, ແຕ່ຍັງຕັດສິນໃຈວ່າຜູ້ໃຊ້ຫຼືຜູ້ພັດທະນາມີສິດທີ່ຈະເຮັດກັບມັນ. ຖ້າໃຜຜູ້ຫນຶ່ງສ້າງໂປລແກລມຟຣີສໍາລັບທຸກຄົນ, ລາວກໍາລັງເຮັດດີ, ແຕ່ຜູ້ທີ່ໃຊ້ມັນຈະຕ້ອງອ້າງວ່າລາວໃຊ້ມັນແນວໃດ. ຕົວຢ່າງ, ຖ້າບໍລິສັດໃນກິດຈະກໍາຂອງຕົນຈະເຮັດວຽກກັບບາງຫ້ອງການຟຣີ (ຕົວຢ່າງ, LibreOffice), ຫຼັງຈາກນັ້ນ, ມັນຈະຕ້ອງສາມາດພິສູດໃຫ້ຜູ້ກວດກາວ່າມັນມີສິດທີ່ຈະເຮັດແນວນັ້ນ. ເພື່ອເຮັດສິ່ງນີ້, ມັນຈະພຽງພໍທີ່ຈະນໍາສະເຫນີໃບອະນຸຍາດທີ່ເຫມາະສົມ. ຖ້ານັກພັດທະນາລືມການສ້າງມັນ, ຫຼັງຈາກນັ້ນບໍລິສັດອາດຈະມີຄວາມຫຍຸ້ງຍາກ.
- ເປັນຫຍັງທ່ານຕ້ອງການອະນຸຍາດໂຄງການ Open Source ໃນ GitHub
- ມີໃບອະນຸຍາດປະເພດໃດແດ່
- ວິທີການເລືອກໃບອະນຸຍາດ Github
- ວິທີການເພີ່ມໃບອະນຸຍາດໃຫ້ກັບ Github
- ເລືອກໃບອະນຸຍາດ Github – ຕົວຢ່າງຂອງໃບອະນຸຍາດທີ່ນິຍົມໃນ Git Hub
- GPL
- LGPL
- ໃບອະນຸຍາດສາທາລະນະ Eclipse
- ໃບອະນຸຍາດສາທາລະນະຂອງ Mozilla
- Apache License Github
- ໃບອະນຸຍາດ MIT
- ຫີນໃຕ້ນ້ຳ
ເປັນຫຍັງທ່ານຕ້ອງການອະນຸຍາດໂຄງການ Open Source ໃນ GitHub
ເມື່ອກໍານົດໃບອະນຸຍາດທີ່ຕ້ອງການ, ນັກພັດທະນາສາມາດສະຫນອງສິ່ງຕໍ່ໄປນີ້ໃນມັນ:
- ເງື່ອນໄຂການນໍາໃຊ້ໂຄງການ . ພວກມັນອາດມີຄ່າທຳນຽມ ຫຼື, ໃນບາງກໍລະນີ, ອະນຸຍາດໃຫ້ໃຊ້ຟຣີ.
- ບາງຄັ້ງໂຄງການຖືກສ້າງຂື້ນເພື່ອພັດທະນາໂດຍຊຸມຊົນ . ໃນກໍລະນີນີ້, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະທຸກຄົນທີ່ຕ້ອງການທີ່ຈະຮູ້ຈັກກັບບົດເລື່ອງໂຄງການ.
- ເມື່ອບົດເລື່ອງຂອງໂປລແກລມມີຢູ່, ບາງຄົນ ອາດຈະປ່ຽນແປງ ເພື່ອເຮັດໃຫ້ໂຄງການເຮັດວຽກແລະເຊື່ອຖືໄດ້ເທົ່າທີ່ເປັນໄປໄດ້. ບາງຄັ້ງຜູ້ຂຽນສາມາດອະນຸຍາດໃຫ້ທຸກຄົນເຮັດສິ່ງນີ້, ໃນກໍລະນີອື່ນໆທີ່ລາວສະເຫນີໃຫ້ສົ່ງການປ່ຽນແປງໄປຫາລາວ, ແລະເຮັດໃຫ້ການປັບຕົວກັບໂຄງການດ້ວຍຕົນເອງ.
- ທ່ານຈໍາເປັນຕ້ອງຕັດສິນໃຈວ່ າພາກສ່ວນທີສາມສາມາດປ່ຽນແປງໂຄງການ ແລະສະເຫນີໃນນາມຂອງພວກເຂົາ. ໃນເວລາດໍາເນີນການນີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ລະບຸວ່າໃບອະນຸຍາດຜະລິດຕະພັນຂອງເຂົາເຈົ້າຄວນຈະມີ.
ການແກ້ໄຂຄໍາຖາມເຫຼົ່ານີ້ແລະຄ້າຍຄືກັນ, ຜູ້ຂຽນຂອງຄໍາຮ້ອງສະຫມັກຕົວຈິງແລ້ວສ່ວນໃຫຍ່ກໍານົດຊະຕາກໍາໃນອະນາຄົດຂອງຜະລິດຕະພັນຊອບແວທີ່ລາວສ້າງ.
ມີໃບອະນຸຍາດປະເພດໃດແດ່
ໃບອະນຸຍາດແມ່ນຂໍ້ຕົກລົງທີ່ຝ່າຍຫນຶ່ງ (ຜູ້ໃຫ້ອະນຸຍາດ) ໄດ້ສ້າງກົດລະບຽບສໍາລັບພາກສ່ວນຫນຶ່ງ (ຜູ້ອະນຸຍາດ) ການນໍາໃຊ້ຜະລິດຕະພັນທີ່ສ້າງໂດຍເຂົາ. ໃນທາງປະຕິບັດ, ພວກເຮົາບໍ່ໄດ້ເວົ້າກ່ຽວກັບການລົງນາມໃນເອກະສານໂດຍຝ່າຍຕ່າງໆ, ແຕ່ກ່ຽວກັບຂໍ້ຕົກລົງອັດຕະໂນມັດກັບສິດທິແລະພັນທະທີ່ສອດຄ້ອງກັນຕາມການນໍາໃຊ້ຂອງມັນ. ຕົວຈິງບໍ່ມີຂໍ້ຈໍາກັດກ່ຽວກັບການກໍານົດສິດແລະພັນທະ. ເງື່ອນໄຂດຽວແມ່ນວ່າພວກເຂົາຕ້ອງປະຕິບັດຕາມກົດຫມາຍ. ການສ້າງໃບອະນຸຍາດຂອງທ່ານເອງແມ່ນວຽກທີ່ສັບສົນ, ເພາະວ່າມັນຕ້ອງເຂົ້າກັນໄດ້ກັບກົດລະບຽບອື່ນໆ. ທາງເລືອກທີ່ດີທີ່ສຸດແມ່ນການເລືອກແລະນໍາໃຊ້ຫນຶ່ງໃນແນວພັນມາດຕະຖານຂອງເອກະສານດັ່ງກ່າວ. ໃນການປະຕິບັດ, ມັນຍັງເປັນປະເພນີທີ່ຈະໃຊ້ multilicensing. ສ່ວນຫຼາຍມັກ, ໃນກໍລະນີດັ່ງກ່າວ, ສອງໃບອະນຸຍາດຖືກນໍາໃຊ້ພ້ອມກັນ. ເຖິງແມ່ນວ່າຜູ້ຂຽນຂອງໂປລແກລມມີສິດທີ່ຈະສ້າງກົດລະບຽບທີ່ຜູ້ໃຊ້ຕ້ອງປະຕິບັດຕາມຢ່າງເປັນເອກະລາດ, ຢ່າງໃດກໍຕາມ, ໃນທາງປະຕິບັດ, ການນໍາໃຊ້ໃບອະນຸຍາດຈໍານວນຫລາຍໄດ້ພັດທະນາ, ເຊິ່ງທ່ານສາມາດເລືອກທີ່ເຫມາະສົມໃນກໍລະນີຫຼາຍທີ່ສຸດ. ຕໍ່ໄປນີ້ແມ່ນຕົວເລືອກທີ່ນິຍົມໃຊ້ໃນ Git Hub ໃນກໍລະນີຫຼາຍທີ່ສຸດ. ໃບອະນຸຍາດທີ່ໃຊ້ຫຼາຍທີ່ສຸດໃນ Git Hub ແມ່ນ:
ຖ້າຜູ້ຂຽນປະຕິເສດທີ່ຈະສ້າງເອກະສານ, ໃນກໍລະນີດັ່ງກ່າວນີ້, ລິຂະສິດຈະຖືກນໍາມາໃຊ້, ເຊິ່ງໄດ້ຖືກສະຫນອງໃຫ້ໂດຍຄ່າເລີ່ມຕົ້ນໂດຍກົດຫມາຍຂອງປະເທດຂອງລາວ. ການບໍ່ມີໃບອະນຸຍາດໃນທາງນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າສິ່ງໃດສາມາດເຮັດໄດ້ກັບໂຄງການ. ໃນຄວາມເປັນຈິງ, ສະຖານະການດັ່ງກ່າວສາມາດຖືກພິຈາລະນາເປັນຫນຶ່ງໃນປະເພດຂອງໃບອະນຸຍາດ.
ວິທີການເລືອກໃບອະນຸຍາດ Github
ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນຊອກຫາທາງເລືອກທີ່ເຫມາະສົມ, ມັນເປັນສິ່ງຈໍາເປັນທີ່ນັກຂຽນໂປລແກລມສ້າງຄວາມຕ້ອງການຂອງລາວ, ເຊິ່ງລາວຈະດໍາເນີນການອອກໃບອະນຸຍາດຕື່ມອີກ. ຕໍ່ໄປ, ທ່ານຄວນຄຸ້ນເຄີຍກັບຕົວເລືອກປົກກະຕິທີ່ກົງກັບຄໍາຮ້ອງຂໍ. ຫຼັງຈາກນັ້ນ, ທ່ານຈະຕ້ອງໄດ້ສຶກສາພາສາທາງດ້ານກົດຫມາຍຢ່າງລະມັດລະວັງແລະຕັດສິນໃຈສຸດທ້າຍກ່ຽວກັບສິ່ງທີ່ໃບອະນຸຍາດຄວນຈະເປັນ. ເພື່ອເຮັດໃຫ້ການເລືອກທີ່ມີຂໍ້ມູນ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈສິດທິແລະພັນທະທີ່ກ່ຽວຂ້ອງກັບປະເພດຂອງໃບອະນຸຍາດສະເພາະ. ເພື່ອເຮັດໃຫ້ການເລືອກທີ່ຖືກຕ້ອງ, ທ່ານສາມາດນໍາໃຊ້ບໍລິການພິເສດທີ່ເອີ້ນວ່າການປຽບທຽບ. ນີ້ແມ່ນບາງຕົວຢ່າງ:
- https://choosealicense.com/. ເວັບໄຊທ໌ນີ້ມີຄໍາຖາມຊັ້ນນໍາສໍາລັບການເລືອກທາງເລືອກທີ່ເຫມາະສົມແລະຄໍາແນະນໍາຢ່າງລະອຽດເພື່ອຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈລັກສະນະຂອງການນໍາໃຊ້.
- ຫນ້າ https://opensource.org/licenses ແມ່ນອຸທິດຕົນເພື່ອທົບທວນຄືນວິທີແກ້ໄຂຊອບແວຟຣີຕ່າງໆ.
- ເວັບໄຊທ໌ https://tldrlegal.com/ ສາມາດຖືກພິຈາລະນາເປັນ encyclopedia ສໍາລັບທາງເລືອກໃບອະນຸຍາດຕ່າງໆ. ມີທັງການສ້າງກົດຫມາຍທີ່ຊັດເຈນແລະຄໍາເຫັນລະອຽດ.
ວິທີການເພີ່ມໃບອະນຸຍາດໃຫ້ກັບ Github
ເຖິງວ່າຈະມີທາງເລືອກຂອງໃບອະນຸຍາດຢ່າງກວ້າງຂວາງທີ່ໄດ້ພິສູດວ່າມີປະສິດທິພາບແລະເຊື່ອຖືໄດ້ໃນການປະຕິບັດ, ຜູ້ພັດທະນາອາດມີຄວາມຄິດຂອງຕົນເອງກ່ຽວກັບສິ່ງທີ່ໃບອະນຸຍາດສໍາລັບໂຄງການທີ່ລາວສ້າງຄວນຈະເປັນ. ໃນກໍລະນີນີ້, ການບໍລິການສະຫນອງຄວາມສາມາດໃນການເພີ່ມສະບັບຂອງທ່ານເອງຫຼືປັບຕົວທີ່ມີຢູ່ແລ້ວ. ເພື່ອເພີ່ມໃບອະນຸຍາດໃຫ້ກັບ Github, ທ່ານຈະຕ້ອງປະຕິບັດຕາມຂັ້ນຕອນເຫຼົ່ານີ້:
- ທ່ານຈໍາເປັນຕ້ອງໄປຫາຫນ້າຕົ້ນຕໍຂອງ repository ຂອງທ່ານ.
- ທ່ານຈໍາເປັນຕ້ອງຄລິກໃສ່ປຸ່ມເພື່ອເພີ່ມໄຟລ໌, ຫຼັງຈາກນັ້ນເລືອກ “ສ້າງໄຟລ໌ໃຫມ່”.
- ຕໍ່ໄປ, ທ່ານຈໍາເປັນຕ້ອງໃສ່ຊື່ໄຟລ໌. ສໍາລັບໃບອະນຸຍາດ, ນີ້ສາມາດເປັນຫນຶ່ງໃນສອງທາງເລືອກ: LICENSE ຫຼື LICENCE.md. ໃນທີ່ນີ້ການໃຊ້ຕົວພິມໃຫຍ່ແມ່ນບັງຄັບ.
- ຢູ່ເບື້ອງຂວາຂອງຊ່ອງໃສ່ຊື່ໄຟລ໌, ຄລິກເພື່ອເລືອກແມ່ແບບໃບອະນຸຍາດ.
- ໃນເມນູດ້ານຊ້າຍຂອງຫນ້າ, ເລືອກເສັ້ນ “ເພີ່ມໃບອະນຸຍາດໃຫ້ກັບໂຄງການຂອງທ່ານ”. ໃນກໍລະນີນີ້, ຕົວແປແມ່ນເລືອກຈາກເອກະສານທີ່ມີຢູ່ແລ້ວ.
- ຫຼັງຈາກນັ້ນ, ໃຫ້ຄລິກໃສ່ເສັ້ນ “ທົບທວນແລະສົ່ງ”. ຈາກນັ້ນໃສ່ລາຍລະອຽດຂໍ້ຕົກລົງຂອງທ່ານ.
- ຫຼັງຈາກນັ້ນ, ມັນຈໍາເປັນຕ້ອງໃຫ້ຄວາມກະຈ່າງແຈ້ງກ່ຽວກັບສິ່ງທີ່ເພີ່ມເຕີມຫຼືການປ່ຽນແປງ. ຕໍ່ໄປ, ຊີ້ບອກວ່າເອກະສານທີ່ເລືອກຖືກແກ້ໄຂແລ້ວ ຫຼືວ່າມັນເປັນການສ້າງໃບອະນຸຍາດສະບັບອື່ນ.
ຫຼັງຈາກຢືນຢັນການປ່ຽນແປງ, ນັກພັດທະນາເຮັດສໍາເລັດຂັ້ນຕອນເພື່ອເຮັດການປ່ຽນແປງບັນຊີລາຍຊື່ຂອງໃບອະນຸຍາດໃນການບໍລິການ Git Hub.
ເລືອກໃບອະນຸຍາດ Github – ຕົວຢ່າງຂອງໃບອະນຸຍາດທີ່ນິຍົມໃນ Git Hub
ຕໍ່ໄປນີ້ແມ່ນທາງເລືອກທີ່ເປັນທີ່ນິຍົມຫຼາຍທີ່ສຸດ. ໂດຍການເຂົ້າໃຈຈຸດແຂງແລະຈຸດອ່ອນຂອງພວກເຂົາ, ນັກຂຽນໂປຼແກຼມຈະສາມາດຊອກຫາທາງເລືອກທີ່ເຫມາະສົມຫຼືເຂົ້າໃຈວິທີການຄົ້ນຫາທີ່ມີປະສິດທິພາບ.
GPL
ໃບອະນຸຍາດນີ້ສາມາດຖືກເອີ້ນວ່າເປັນຫນຶ່ງໃນທີ່ນິຍົມທີ່ສຸດ. ມັນເປັນຄລາສສິກສໍາລັບຜູ້ທີ່ຜະລິດຊອບແວຟຣີ. ຫນຶ່ງໃນຂໍ້ກໍານົດຕົ້ນຕໍຂອງເອກະສານນີ້ແມ່ນວ່າມັນ
ອະນຸຍາດໃຫ້ພາກສ່ວນທີສາມສາມາດດັດແປງໂຄງການໄດ້ຢ່າງເສລີ , ແຕ່ໃນເວລາດຽວກັນພວກເຂົາມີສິດທີ່ຈະແຈກຢາຍຜົນໄດ້ຮັບພາຍໃຕ້ໃບອະນຸຍາດດຽວກັນ. ໃບອະນຸຍາດນີ້ອາດຈະມີສະບັບທີ່ແຕກຕ່າງກັນ. ຫລ້າສຸດຂອງເຫຼົ່ານີ້ແມ່ນທີສາມ. GPL ໄດ້ຖືກນໍາໃຊ້ໂດຍຜູ້ພັດທະນາໂຄງການເຊັ່ນລະບົບການຄຸ້ມຄອງເນື້ອຫາເວັບ Drupal, ລະບົບການຈັດການຖານຂໍ້ມູນ MariaDB, ບັນນາທິການຮູບພາບ vector InkSkape, ແລະອື່ນໆ. ມັນຫນ້າສົນໃຈທີ່ຈະສັງເກດວ່າ SQL ໃຊ້ບໍ່ພຽງແຕ່ GPL, ແຕ່ຍັງເປັນໃບອະນຸຍາດທາງການຄ້າ.
LGPL
ຊື່ນີ້ແປເປັນ “GNU GPL Lesser General Public License”. ສໍາລັບນັກພັດທະນາບາງຄົນ, GPL ແມ່ນບໍ່ເຫມາະສົມ, ຍ້ອນວ່າມັນສ້າງພັນທະສໍາລັບພວກເຂົາທີ່ຈະແຈກຢາຍຜະລິດຕະພັນທີ່ຖືກດັດແປງພາຍໃຕ້ໃບອະນຸຍາດດຽວກັນ. ຄຸນນະສົມບັດຂອງຄໍາຮ້ອງສະຫມັກຂອງທາງເລືອກນີ້ສາມາດສະແດງໃຫ້ເຫັນໂດຍວິທີການຂະບວນການຂອງການອະນຸຍາດການນໍາໃຊ້ຫ້ອງສະຫມຸດທີ່ສ້າງໂດຍ programmer ເກີດຂຶ້ນ. ໃນກໍລະນີນີ້, ສາມທາງເລືອກຕໍ່ໄປນີ້ຖືກພິຈາລະນາ:
- ເມື່ອຫ້ອງສະຫມຸດສະຫນອງການເຮັດວຽກໃຫມ່ທີ່ບໍ່ມີຫ້ອງສະຫມຸດການຄ້າອື່ນໆສາມາດເຮັດໄດ້ຄືກັນ, GPL ແມ່ນທາງເລືອກທີ່ດີທີ່ສຸດ.
- ນັກພັດທະນາໃນຫ້ອງສະຫມຸດຟຣີໄດ້ປະຕິບັດມາດຕະຖານທີ່ມີຢູ່ແລ້ວ. ໃນຂົງເຂດນີ້, ມີທາງເລືອກການຄ້າທີ່ມີຫນ້າທີ່ຄ້າຍຄືກັນ. ສໍາລັບກໍລະນີນີ້, ມັນຈະສະດວກໃນການເລືອກ LGPL.
- ໃນເວລາທີ່ມັນມາກັບມາດຕະຖານໃຫມ່ທີ່ແຂ່ງຂັນກັບການຄ້າ, ໃບອະນຸຍາດ Apache ແມ່ນທາງທີ່ຈະໄປ.
ມາດຕະຖານນີ້
ອະນຸຍາດໃຫ້ນໍາໃຊ້ໃນການຄ້າຂອງຫ້ອງສະຫມຸດ . ຖ້າມີການດັດແກ້, ຂໍ້ກໍານົດແລະເງື່ອນໄຂດຽວກັນຕ້ອງຖືກນໍາໃຊ້ສໍາລັບການແຈກຢາຍ. ຢ່າງໃດກໍຕາມ, ການນໍາໃຊ້ງ່າຍດາຍຂອງລະຫັດອະນຸຍາດໃຫ້ເງື່ອນໄຂທີ່ຈະມີການປ່ຽນແປງ.
ໃບອະນຸຍາດສາທາລະນະ Eclipse
ເອກະສານນີ້
ອະນຸຍາດໃຫ້ແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດອື່ນໆ, ລວມທັງການຄ້າ . ເງື່ອນໄຂຕົ້ນຕໍແມ່ນວ່າໃນວຽກງານທີ່ຖືກດັດແປງ, ການປະດິດສ້າງຈະຖືກຈັດໃສ່ໃນໂມດູນແຍກຕ່າງຫາກ. ໃບອະນຸຍາດນີ້ໄດ້ຮັບຄວາມນິຍົມໃນການພັດທະນາຜະລິດຕະພັນໃນ Java. ຕົວຢ່າງຫນຶ່ງແມ່ນພາສາການຂຽນໂປລແກລມ Clojure, ກອບສໍາລັບການທົດສອບຄໍາຮ້ອງສະຫມັກ java.
ໃບອະນຸຍາດສາທາລະນະຂອງ Mozilla
ບາງຄົນເຫັນວ່າເອກະສານນີ້ເປັນການປະນີປະນອມລະຫວ່າງ GPL ແລະໃບອະນຸຍາດທາງການຄ້າ. MPL ຕ້ອງ
ການການເຂົ້າເຖິງໄຟລ໌ສະເພາະ . ຜະລິດຕະພັນຊອບແວອາດມີບາງໄຟລ໌ພາຍໃຕ້ໃບອະນຸຍາດນີ້ ແລະໄຟລ໌ອື່ນໆທີ່ບໍ່ມີມັນ. ຫຼັງຈາກການດັດແກ້, ມັນຖືກອະນຸຍາດໃຫ້ໃສ່ໃບອະນຸຍາດທີ່ຕ້ອງການ (ຕົວຢ່າງ, ມັນສາມາດເປັນການຄ້າ), ແຕ່ນີ້ເປັນໄປໄດ້ພຽງແຕ່ໃນເງື່ອນໄຂທີ່ການເຂົ້າເຖິງໄຟລ໌ທີ່ຖືກປ່ອຍອອກມາພາຍໃຕ້ MPL ຈະຍັງເປີດ. ໃນກໍລະນີນີ້, ຜູ້ໃຊ້ສຸດທ້າຍຕ້ອງໄດ້ຮັບການສະຫນອງຂໍ້ມູນກ່ຽວກັບຜູ້ຂຽນຂອງຊອບແວຕົ້ນສະບັບ. ອີງຕາມເອກະສານນີ້, ຫ້ອງການ LibreOffice, ຕົວທ່ອງເວັບ Mozilla ແລະຜະລິດຕະພັນຊອບແວອື່ນໆໄດ້ຖືກປ່ອຍອອກມາ.
Apache License Github
AL ແມ່ນເອີ້ນວ່າໃບອະນຸຍາດເສລີເສລີນິຍົມ. ຄຸນນະສົມບັດນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າບໍ່
ມີຄວາມຕ້ອງການທີ່ຈະປ່ອຍຜະລິດຕະພັນອະນຸພັນພາຍໃຕ້ເງື່ອນໄຂດຽວກັນກັບກ່ອນ . ເອກະສານນີ້ຖືກນໍາໃຊ້ຢ່າງຈິງຈັງໂດຍ Apache Software Foundation. ເມື່ອນໍາໃຊ້, ຕໍ່ໄປນີ້ແມ່ນອະນຸຍາດໃຫ້:
- ຜະລິດຕະພັນຊອບແວໄດ້ຖືກອະນຸຍາດໃຫ້ນໍາໃຊ້ຕື່ມອີກເພື່ອຈຸດປະສົງທາງການຄ້າ.
- ອະນຸຍາດໃຫ້ມີການດັດແກ້ແອັບພລິເຄຊັນ.
- ການແຈກຢາຍຕໍ່ມາຄວນປະກອບມີຊື່ຂອງຜູ້ຂຽນຕົ້ນສະບັບ.
ໂດຍການສ້າງຕົວແປໃຫມ່, ບໍ່ມີພັນທະສໍາລັບຜູ້ອະນຸຍາດທີ່ຈະໃຫ້ລະຫັດຜະລິດຕະພັນຕົ້ນສະບັບ. ໃບອະນຸຍາດດັ່ງກ່າວໄດ້ຮັບຄວາມນິຍົມຢ່າງຫຼວງຫຼາຍ. ນີ້ສາມາດສະແດງໃຫ້ເຫັນໄດ້ໂດຍລາຍຊື່ຜະລິດຕະພັນຊອບແວທີ່ມີຊື່ສຽງທີ່ຖືກປ່ອຍອອກມາພາຍໃຕ້ໃບອະນຸຍາດປະເພດນີ້: ລະບົບປະຕິບັດການ Android, ກອບທີ່ສ້າງຄໍາຮ້ອງສະຫມັກວິສາຫະກິດໃນ Java, ແລະເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ Apache. https://youtu.be/wyZq-EazOmU
ໃບອະນຸຍາດ MIT
ບາງຄົນພິຈາລະນາທາງເລືອກໃບອະນຸຍາດຊອບແວຟຣີນີ້ເປັນທີ່ນິຍົມທີ່ສຸດ. ປະໂຫຍດຕົ້ນຕໍຂອງມັນແມ່ນພິຈາລະນາໂດຍບາງຄົນທີ່ຈະເຂົ້າກັນໄດ້ດີກັບປະເພດຕ່າງໆຂອງໃບອະນຸຍາດຟຣີຫຼືການຄ້າ. ລັກສະນະທີ່ສໍາຄັນທີ່ສຸດແມ່ນ
ຄວາມສາມາດໃນການດັດແປງລະຫັດ, ເຊັ່ນດຽວກັນກັບການອະນຸຍາດໃຫ້ແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດອື່ນໆຕາມທາງເລືອກຂອງຜູ້ທີ່ເຮັດການປ່ຽນແປງ . ຜະລິດຕະພັນຊອບແວທີ່ນໍາໃຊ້ເອກະສານນີ້ແມ່ນ: ຫ້ອງສະຫມຸດ JavaScript ທີ່ເອີ້ນວ່າ JQuiery, ຕົວແກ້ໄຂຂໍ້ຄວາມ Atom, AngularJS, ກອບການພັດທະນາ JavaScript.
ຫີນໃຕ້ນ້ຳ
ບາງຄັ້ງຜູ້ຂຽນທໍາອິດເລືອກຫນຶ່ງສະບັບຂອງໃບອະນຸຍາດ, ແລະຕໍ່ມາຕ້ອງການປ່ຽນມັນ. ຖ້າລາວສ້າງໂຄງການຢ່າງດຽວ, ການປ່ຽນແປງດັ່ງກ່າວຈະບໍ່ມີຄວາມຫຍຸ້ງຍາກ. ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີທີ່ມີຜູ້ເຂົ້າຮ່ວມຈໍານວນຫຼາຍໃນການພັດທະນາ, ຫຼັງຈາກນັ້ນໂດຍບໍ່ມີການຍິນຍອມເຫັນດີຂອງເຂົາເຈົ້າ, ນີ້ຈະບໍ່ເຮັດວຽກ. ຕົວຢ່າງ, ຜູ້ສ້າງ Linux, ເຖິງແມ່ນວ່າລາວສ້າງພື້ນຖານຂອງລະບົບປະຕິບັດການ, ຈະບໍ່ສາມາດປ່ຽນໃບອະນຸຍາດໄດ້ໂດຍບໍ່ມີການຍິນຍອມເຫັນດີຈາກນັກຂຽນໂປລແກລມທັງຫມົດຜູ້ທີ່ເຂົ້າຮ່ວມໃນການພັດທະນາຕື່ມອີກ. ເມື່ອແຈກຢາຍພາຍໃຕ້ MPL, ຜູ້ທີ່ເຮັດການປ່ຽນແປງລະຫັດບໍ່ສາມາດສະເຫນີໄຟລ໌ພາຍໃຕ້ MPL ພາຍໃຕ້ໃບອະນຸຍາດທີ່ແຕກຕ່າງກັນ. ການນໍາໃຊ້ເອກະສານໃຫມ່ຈະຫມາຍເຖິງໂມດູນໂຄງການອື່ນໆ.
