Што трэба ведаць пра ліцэнзіі GitHub: як абраць і дадаць

GitHub ліцэнзіі – пра што гаворка? Для таго, каб стварыць праграмнае забеспячэнне, трэба не толькі напісаць яго але і вырашыць, што з ім маюць права рабіць карыстачы або распрацоўнікі. Калі хто-небудзь стварае бясплатную праграму для ўсіх, ён робіць добрую справу, аднак той, хто яе выкарыстоўвае, павінен будзе абгрунтаваць, тое, як ён яе выкарыстоўвае. Напрыклад, калі фірма ў сваёй дзейнасці будзе працаваць з якім-небудзь бясплатным офісам (напрыклад, LibreOffice), то для правяраючых яна павінна ўмець давесці, што мае права так рабіць. Для гэтага дастаткова будзе прад’явіць адпаведную ліцэнзію. Калі распрацоўшчык забудзецца яе сфармуляваць, то фірма можа апынуцца ў складаным становішчы.

Ствараючы прыкладанне, распрацоўнік павінен вырашыць, якія дзеянні з яго праграмай будуць дазволеныя, а якія – не. Напрыклад, гаворка можа ісці не толькі аб выкарыстанні, але і аб вывучэнні тэкстаў праграм або занясенне сваіх карэкціровак у праграмны прадукт. GitHub прадстаўляе адзін з найбуйнейшых сэрвісаў, якія даюць магчымасць весці сумесную распрацоўку праектаў. Пры гэтым тут могуць працаваць не толькі над бясплатнымі, але і камерцыйнымі праектамі. Указаўшы прыдатную ліцэнзію, распрацоўшчыкі ліквідуюць невыразнасці ў тым, як выкарыстоўваць створаны прадукт. Праблема складаецца ў тым, што існуе іншага розных тыпаў ліцэнзій, і не заўсёды дастаткова проста вызначыць, які менавіта варыянт варта аддаць перавагу ў канкрэтным выпадку. Таксама нярэдкія сітуацыі, калі ліцэнзія ў некаторых праектаў адсутнічае.

Навошта трэба ліцэнзаванне Open Source праектаў на GitHub

Указваючы неабходную ліцэнзію, распрацоўшчык можа прадугледзець у ёй наступнае:

1. Умовы выкарыстання праграмы . Яны могуць прадугледжваць унясенне платы ці ў некаторых, ці ва ўсіх выпадках, дазваляць бясплатнае выкарыстанне.
2. Часам праграмы ствараюцца для таго, каб іх развівала супольнасць . У гэтым выпадку важна, каб з праграмнымі тэкстамі маглі азнаёміцца ​​ўсе ахвочыя.
3. Калі тэксты праграмы даступныя, некаторыя маглі б унесці змены , зрабіўшы праграму функцыянальнай і як мага больш надзейнай. Часам аўтар можа дазволіць гэта рабіць усім жадаючым, у іншых выпадках прапануе дасылаць змену яму, а ўносіць карэктывы ў праект самастойна.
4. Трэба вырашыць, ці могуць трэція асобы ўносіць змены ў праект і прапанаваць ад свайго імя. Пры гэтым неабходна ўказаць, з якой ліцэнзіяй павінен быць іх прадукт.

Вырашаючы гэтыя і аналагічныя пытанні аўтар прыкладання фактычна шмат у чым вызначае далейшы лёс створанага ім праграмнага прадукта.

Якія віды ліцэнзій існуюць

Ліцэнзія ўяўляе сабой дамову, у якім адзін бок (ліцэнзіярам) усталёўвае правіла выкарыстання іншым бокам (ліцэнзіятам) створанага ім прадукта. На практыцы размова ідзе не аб падпісанні дакумента бакамі, а аб аўтаматычнай згодзе з адпаведнымі правамі і абавязкамі па факце яго выкарыстання. Для ўказання правоў і абавязкаў практычна не існуе абмежаванняў. Адзіная ўмова ў тым, што яны павінны адпавядаць заканадаўству. Стварэнне ўласных ліцэнзій уяўляе сабою складаную працу, бо пры гэтым трэба прадугледзець яе сумяшчальнасць з іншымі нарматыўнымі актамі. Аптымальным варыянтам з’яўляецца выбар і прымяненне адной са стандартных разнавіднасцяў такіх дакументаў. На практыцы таксама прынята прымяняць мультыліцэнзаванне. Часцей за ўсё ў такіх выпадках выкарыстоўваюць адначасова дзве ліцэнзіі. Хоць аўтар праграмы мае права самастойна сфармуляваць правілы, якім павінны прытрымлівацца карыстальнікі, тым не менш на практыцы склалася выкарыстанне вялікай колькасці відаў ліцэнзій, з якіх можна выбраць прыдатную ў большасці выпадкаў. Далей прыведзены найболей папулярныя варыянты, выкарыстоўваныя на Git Hub у большасці выпадкаў. Ліцэнзіі, якія выкарыстоўваюцца на Git Hub часцей за ўсё:
Праграмісту трэба здолець выбраць такую, якая будзе адпавядаць яго планам. Каб гэта зрабіць правільна, трэба разбірацца ў тым, якія асаблівасці ўласцівыя пэўным відам.

Калі аўтар адмаўляецца сфармуляваць дакумент, то ў гэтым выпадку будуць дзейнічаць аўтарскія правы, якія прадугледжаны па змаўчанні заканадаўствам яго краіны. Адсутнасць ліцэнзіі такім чынам не азначае, што з праграмай можна зрабіць усё, што заўгодна. Фактычна такую ​​сітуацыю можна разглядаць у якасці аднаго з відаў ліцэнзіі.

Як абраць Github ліцэнзію

Перад тым, як прыступіць да пошуку прыдатнага варыянту, неабходна, каб праграміст сфармуляваў свае патрабаванні, з якіх ён збіраецца зыходзіць пры далейшым ліцэнзаванні. Далей варта азнаёміцца ​​з тыпавымі варыянтамі, якія адпавядаюць запыце. Пасля гэтага спатрэбіцца ўважліва вывучыць юрыдычныя фармулёўкі і прыняць канчатковае рашэнне аб тым, якой павінна быць ліцэнзія. Каб зрабіць абгрунтаваны выбар, трэба зразумець, якія правы і абавязкі вызначаюцца канкрэтным тыпам ліцэнзіі. Каб зрабіць выбар правільна, можна скарыстацца спецыяльнымі сэрвісамі, якія называюцца кампаратарамі. Вось некалькі такіх прыкладаў:

1. https://choosealicense.com/. На гэтым сайце маюцца навадныя пытанні для выбару прыдатнага варыянту і падрабязныя кансультацыі, якія дапамагаюць зразумець асаблівасці выкарыстання.
2. Старонка https://opensource.org/licenses прысвечана разгляду розных свабодных рашэнняў для праграмнага забеспячэння.
3. Сайт https://tldrlegal.com/ можна разглядаць у якасці энцыклапедыі для розных варыянтаў ліцэнзій. Тут ёсць як дакладныя юрыдычныя фармулёўкі, так і падрабязныя каментарыі.

Аднак, найбольш прадуктыўным спосабам выбару з’яўляецца ўважлівае чытанне адпаведных юрыдычных дакументаў. Хоць гаворка ідзе аб працаёмкай дзейнасці, тым не менш, вывучэнне тэкстаў дасць распрацоўніку ўсе неабходныя адказы.

Як дадаць ліцэнзію на Github

Нягледзячы на ​​шырокі выбар варыянтаў ліцэнзій, якія на практыцы пацвердзілі сваю эфектыўнасць і надзейнасць, у распрацоўніка могуць быць свае ўяўленні аб тым, якой павінна быць ліцэнзія для створанай ім праграмы. У гэтым выпадку на сэрвісе прадугледжана магчымасць дадання ўласнага варыянта або карэкціроўкі існуючага. Каб дадаць ліцэнзію на Github, спатрэбіцца выканаць такія дзеянні:

1. Трэба перайсці на галоўную старонку свайго рэпазітара.
2. Трэба націснуць на кнопку для дадання файла, затым абраць “Create new file”.
3. Далей трэба ўвесці імя файла. Для ліцэнзіі гэта можа быць адзін з двух варыянтаў: LICENSE ці LICENCE.md. Тут ужыванне загалоўных літар з’яўляецца абавязковым.
4. Справа ад поля ўводу імя файла клікаюць для выбару шаблона ліцэнзіі.
5. У меню ў левай частцы старонкі выбіраюць радок “Add a license to your project”. Пры гэтым выбіраюць варыянт з ужо існуючых дакументаў.
6. Затым клікаюць па радку “Review and submit”. Пасля гэтага ўводзяць свае дэталі дамовы.
7. Пасля гэтага неабходна ўдакладніць, у чым складаліся зробленыя дапаўненні ці змены. Далей паказваюць, ці праводзілася карэкціроўка выбранага дакумента ці гаворка ідзе аб стварэнні іншага варыянту ліцэнзіі.

Пацвердзіўшы ўнесеныя змены, распрацоўнік завяршае працэдуру занясення змен у спіс ліцэнзій на сэрвісе Git Hub.

Choose a license Github – прыклады папулярных ліцэнзій на Git Hub

Далей будуць разгледжаны тыя варыянты, якія з’яўляюцца найболей папулярнымі. Разабраўшыся ў іх моцных і слабых баках, праграміст зможа знайсці патрэбны варыянт ці зразумець, як эфектыўна здзяйсняць пошук.

GPL

Гэтую ліцэнзію можна назваць адной з найболей папулярных. Яна з’яўляецца класічнай для тых, хто вырабляе свабоднае праграмнае забеспячэнне. Адным з асноўных патрабаванняў гэтага дакумента з’яўляецца тое, што яна
дазваляе свабодна змяняць праграму трэцім асобам , але пры гэтым распаўсюджваць вынік яны маюць права толькі пад такой жа самай ліцэнзіяй. Гэтая ліцэнзія можа мець розныя версіі. Самай позняй з іх з’яўляецца трэцяя. GPL была выкарыстана распрацоўшчыкамі такіх праграм, як сістэма кіравання вэб-кантэнтам Drupal, сістэма кіравання базамі дадзеных MariaDB, вектарны графічны рэдактар ​​InkSkape і некаторых іншых. Цікава адзначыць, што SQL выкарыстоўвае не толькі GPL, але і камерцыйную ліцэнзію.

LGPL

Гэта назва перакладаецца як “Меншая стандартная грамадская ліцэнзія GNU GPL”. Некаторым распрацоўнікам GPL не падыходзіць, бо стварае для іх абавязак распаўсюджваць мадыфікаваныя прадукты пад той жа ліцэнзіяй. Асаблівасці прымянення гэтага варыянта можна праілюстраваць тым, як адбываецца працэс ліцэнзавання прымянення бібліятэк, створаных праграмістам. Пры гэтым прынята разглядаць наступныя тры варыянты:

1. Калі бібліятэка забяспечвае выкананне новых функцый, прычым ніякія камерцыйныя бібліятэкі не могуць выканаць аналагічную задачу, то ў гэтым выпадку аптымальным з’яўляецца ўжыванне GPL.
2. Распрацоўнік у свабоднай бібліятэцы ўжо рэалізаваў існуючы стандарт. У гэтай сферы ёсць камерцыйныя варыянты з аналагічнымі функцыямі. Для гэтага выпадку будзе зручна абраць LGPL.
3. Калі гаворка ідзе аб новым стандарце, які фактычна знаходзіцца ў канкурэнцыі з камерцыйным, тут падыдзе ўжыванне ліцэнзіі Apache.

У гэтым стандарце
дапускаецца камерцыйнае выкарыстанне бібліятэк . Калі вырабляюцца мадыфікацыі, неабходна для распаўсюджвання выкарыстоўваць такія ж умовы. Аднак простае выкарыстанне кода дапушчае змену ўмоў.

Eclipse Public License

Гэты дакумент
дазваляе распаўсюджванне пад іншымі ліцэнзіямі, у тым ліку і камерцыйнымі . Асноўнай умовай з’яўляецца тое, што ў мадыфікаваных працах новаўвядзенні будуць вынесены ў асобны модуль. Гэтая ліцэнзія набыла папулярнасць пры распрацоўцы прадуктаў на Java. У якасці прыкладу можна прывесці мову праграмавання Clojure, фрэймворк для тэставання прыкладанняў на java.

Mozilla Public License

Некаторыя разглядаюць гэты дакумент як кампраміс паміж GPL і камерцыйнымі ліцэнзіямі. Патрабаваннем MPL з’яўляецца
наяўнасць адчыненага доступу да вызначаных файлаў . У праграмным прадукце могуць быць адны файлы пад гэтай ліцэнзіяй, а іншыя – без яе. Пасля мадыфікацыі дазваляецца паставіць тую ліцэнзію, якая патрэбна (напрыклад, гаворка можа ісці аб камерцыйнай), аднак гэта магчыма толькі пры ўмове, што доступ да файлаў, выпушчаным пад MPL будзе па-ранейшаму адчыненым. Пры гэтым канчатковаму карыстачу павінна быць прадстаўлена інфармацыя аб аўтарах першапачатковага праграмнага забеспячэння. У адпаведнасці з гэтым дакументам былі выпушчаны офіс LibreOffice, браўзэр Mozilla і іншыя праграмныя прадукты.

Apache License Github

AL прынята называць ліберальнай свабоднай ліцэнзіяй. Гэтая асаблівасць звязана з тым, што тут
адсутнічае патрабаванне выпускаць вытворны прадукт пад тымі ж умовамі, што і раней . Гэтым дакументам актыўна карыстаецца кампанія Apache Software Foundation. Пры яе ўжыванні дазволена наступнае:

1. Праграмны прадукт дазволена далей выкарыстоўваць у камерцыйных мэтах.
2. Дапускаецца правядзенне мадыфікацыі дадаткаў.
3. Неабходна, каб пры наступным распаўсюджванні згадвалася імя аўтара першапачатковага варыянту.

Ствараючы новы варыянт, у ліцэнзіятаў адсутнічае абавязак па падаванні кода першапачатковага прадукта. Такая ліцэнзія набыла значную папулярнасць. Гэта можна прадэманстраваць, пералічыўшы вядомыя праграмныя прадукты, якія выпускаюцца пад гэтым выглядам ліцэнзіі: аперацыйная сістэма Android, фрэймворк, з дапамогай якога ствараюцца карпаратыўныя прыкладанні на Java, вэб-сервер Apache. https://youtu.be/wyZq-EazOmU

MIT Licence

Некаторыя лічаць, што гэты варыянт ліцэнзій для свабоднага праграмнага забеспячэння мае найбольшую папулярнасць. Яе асноўнай добрай якасцю некаторыя лічаць добрую спалучальнасць з рознымі выглядамі вольных або камерцыйных ліцэнзій. Найважнейшымі асаблівасцямі з’яўляецца
магчымасць мадыфікацыі кода, а таксама дазвол распаўсюджваць пад іншымі ліцэнзіямі па выбары таго, хто ўнёс змены . Праграмнымі прадуктамі, якія выкарыстоўваюць гэты дакумент з’яўляюцца: бібліятэка JavaScript пад назвай JQuiery, тэкставы рэдактар ​​Atom, AngularJS – фрэймворк для распрацоўкі на JavaSсript.

Падводныя камяні

Часам аўтар на першую пару выбірае адзін варыянт ліцэнзіі, а пасля жадае яе змяніць. Калі ён ствараў праграму ў адзіночку, то такая змена не будзе ўяўляць складанасцяў. Аднак у тых выпадках, калі было шмат удзельнікаў распрацоўкі, дык без іх згоды гэтага зрабіць не атрымаецца. Напрыклад, стваральнік Linux, хоць ён фактычна зрабіў аснову аперацыйнай сістэмы, не зможа памяняць ліцэнзію без згоды ўсіх тых праграмістаў, якія бралі ўдзел у далейшай распрацоўцы. Пры распаўсюджванні пад MPL тыя, хто ўносіў змены ў код, не могуць файлы пад MPL прапаноўваць пад іншай ліцэнзіяй. Выкарыстанне новага дакумента будзе ставіцца да іншых праграмных модуляў.