Wat jy moet weet oor GitHub-lisensies: hoe om te kies en by te voeg

GitHub-lisensies – waaroor praat ons? Om sagteware te skep, moet ‘n mens dit nie net skryf nie, maar ook besluit wat gebruikers of ontwikkelaars die reg het om daarmee te doen. As iemand vir almal ‘n gratis program skep, doen hy ‘n goeie daad, maar wie dit gebruik, sal moet regverdig hoe hy dit gebruik. Byvoorbeeld, as ‘n maatskappy in sy aktiwiteite met een of ander gratis kantoor sal werk (byvoorbeeld LibreOffice), dan moet dit aan inspekteurs kan bewys dat dit die reg het om dit te doen. Om dit te doen, sal dit genoeg wees om die toepaslike lisensie voor te lê. As die ontwikkelaar vergeet om dit te formuleer, kan die maatskappy in ‘n moeilike posisie wees.

Wanneer ‘n toepassing geskep word, moet die ontwikkelaar besluit watter aksies met sy program toegelaat sal word en watter nie. Ons kan byvoorbeeld nie net praat oor die gebruik nie, maar ook oor die bestudering van die tekste van programme of om jou eie aanpassings aan die sagtewareproduk te maak. GitHub is een van die grootste dienste vir samewerkende projekontwikkeling. Terselfdertyd kan hulle hier nie net aan gratis nie, maar ook aan kommersiële projekte werk. Deur die toepaslike lisensie te spesifiseer, sal die ontwikkelaars onduidelikhede uitskakel oor hoe om die geskepte produk te gebruik. Die probleem is dat daar baie verskillende tipes lisensies is, en dit is nie altyd maklik om te bepaal watter opsie om in ‘n spesifieke geval te kies nie. Dit is ook nie ongewoon dat sommige projekte geen lisensie het nie.

Waarom u oopbronprojekte op GitHub moet lisensieer

Wanneer die vereiste lisensie gespesifiseer word, kan die ontwikkelaar die volgende daarin verskaf:

1. Gebruiksvoorwaardes van die program . Dit kan ‘n fooi behels of, in sommige of alle gevalle, gratis gebruik toelaat.
2. Soms word programme geskep om deur die gemeenskap ontwikkel te word . In hierdie geval is dit belangrik dat almal wat wil kennis maak met die programtekste.
3. Wanneer die tekste van die program beskikbaar is, kan sommige veranderinge aanbring om die program funksioneel en so betroubaar moontlik te maak. Soms kan die skrywer almal toelaat om dit te doen, in ander gevalle bied hy aan om die verandering aan hom te stuur, en maak op sy eie aanpassings aan die projek.
4. Jy moet besluit of derde partye veranderinge aan die projek en aanbod namens hulle kan maak. Wanneer jy dit doen, moet jy spesifiseer met watter lisensie hul produk moet wees.

Deur hierdie en soortgelyke vrae op te los, bepaal die skrywer van die toepassing eintlik grootliks die toekomstige lot van die sagtewareproduk wat hy geskep het.

Watter tipe lisensies bestaan

‘n Lisensie is ‘n ooreenkoms waarin een party (die lisensiegewer) ‘n reël daarstel vir die ander party (die lisensiehouer) om die produk wat deur hom geskep is, te gebruik. In die praktyk praat ons nie van die ondertekening van ‘n dokument deur die partye nie, maar van outomatiese ooreenkoms met die ooreenstemmende regte en verpligtinge by die gebruik daarvan. Daar is feitlik geen beperkings op die spesifiseer van regte en verpligtinge nie. Die enigste voorwaarde is dat hulle aan die wet moet voldoen. Om jou eie lisensies te skep is ‘n komplekse taak, aangesien dit versoenbaar moet wees met ander regulasies. Die beste opsie is om een ​​van die standaardvariëteite van sulke dokumente te kies en te gebruik. In die praktyk is dit ook gebruiklik om multilisensiering te gebruik. Dikwels word in sulke gevalle twee lisensies gelyktydig gebruik. Alhoewel die skrywer van die program die reg het om onafhanklik die reëls te formuleer wat gebruikers moet volg, het die gebruik van ‘n groot aantal tipes lisensies in die praktyk ontwikkel, waaruit u in die meeste gevalle die regte een kan kies. Die volgende is die gewildste opsies wat in die meeste gevalle op Git Hub gebruik word. Die lisensies wat die meeste op Git Hub gebruik word, is:
Die programmeerder sal een moet kan kies wat by sy planne pas. Om dit korrek te doen, moet jy verstaan ​​watter kenmerke inherent is aan sekere spesies.

As die skrywer weier om die dokument te formuleer, sal kopiereg in hierdie geval geld, wat by verstek deur die wetgewing van sy land voorsien word. Die afwesigheid van ‘n lisensie op hierdie manier beteken nie dat enigiets met die program gedoen kan word nie. Trouens, so ‘n situasie kan as een van die tipes lisensies beskou word.

Hoe om ‘n Github-lisensie te kies

Voordat jy na ‘n geskikte opsie begin soek, is dit nodig dat die programmeerder sy vereistes formuleer, van waaruit hy met verdere lisensiëring gaan voortgaan. Vervolgens moet u uself vertroud maak met die tipiese opsies wat by die versoek pas. Daarna sal jy die regstaal noukeurig moet bestudeer en ‘n finale besluit neem oor wat die lisensie moet wees. Om ‘n ingeligte keuse te maak, moet jy verstaan ​​watter regte en verpligtinge met ‘n bepaalde tipe lisensie geassosieer word. Om die regte keuse te maak, kan u spesiale dienste gebruik wat vergelykers genoem word. Hier is ‘n paar voorbeelde:

1. https://choosealicense.com/. Hierdie webwerf het leidende vrae oor die keuse van die regte opsie en gedetailleerde advies om jou te help om die kenmerke van gebruik te verstaan.
2. Die https://opensource.org/licenses-bladsy is toegewy aan die hersiening van verskeie gratis sagteware-oplossings.
3. Die webwerf https://tldrlegal.com/ kan as ‘n ensiklopedie vir verskeie lisensie-opsies beskou word. Daar is beide presiese wetlike formulerings en gedetailleerde kommentaar.

Die mees produktiewe manier om te kies is egter om die relevante regsdokumente noukeurig te lees . Alhoewel ons van arbeidsintensiewe aktiwiteite praat, sal die bestudering van die tekste die ontwikkelaar al die nodige antwoorde gee.

Hoe om ‘n lisensie by Github te voeg

Ten spyte van die uitgebreide keuse van lisensie-opsies wat in die praktyk as doeltreffend en betroubaar bewys is, kan die ontwikkelaar sy eie idees hê oor wat die lisensie vir die program wat hy geskep het, moet wees. In hierdie geval bied die diens die vermoë om jou eie weergawe by te voeg of die bestaande een aan te pas. Om ‘n lisensie by Github te voeg, sal jy hierdie stappe moet volg:

1. U moet na die hoofbladsy van u bewaarplek gaan.
2. Jy moet op die knoppie klik om ‘n lêer by te voeg, kies dan “Skep nuwe lêer”.
3. Vervolgens moet u ‘n lêernaam invoer. Vir ‘n lisensie kan dit een van twee opsies wees: LICENSE of LICENCE.md. Hier is die gebruik van hoofletters verpligtend.
4. Klik regs van die lêernaam-invoerveld om ‘n lisensiesjabloon te kies.
5. In die kieslys aan die linkerkant van die bladsy, kies die reël “Voeg ‘n lisensie by jou projek”. In hierdie geval word ‘n variant uit bestaande dokumente gekies.
6. Klik dan op die reël “Hersien en dien in”. Voer dan jou ooreenkomsbesonderhede in.
7. Daarna is dit nodig om te verduidelik wat die toevoegings of veranderinge aangebring is. Dui dan aan of die geselekteerde dokument reggestel is en of dit gaan oor die skep van ‘n ander weergawe van die lisensie.

Nadat die veranderinge bevestig is, voltooi die ontwikkelaar die prosedure om veranderinge aan die lys lisensies op die Git Hub-diens aan te bring.

Kies ‘n lisensie Github – voorbeelde van gewilde lisensies op Git Hub

Die volgende is die opsies wat die gewildste is. Deur hul sterk- en swakpunte te verstaan, sal die programmeerder die regte opsie kan vind of verstaan ​​hoe om doeltreffend te soek.

GPL

Hierdie lisensie kan een van die gewildste genoem word. Dit is klassiek vir diegene wat gratis sagteware vervaardig. Een van die hoofvereistes van hierdie dokument is dat dit
derde partye toelaat om die program vrylik te wysig , maar terselfdertyd het hulle die reg om die resultaat slegs onder dieselfde lisensie te versprei. Hierdie lisensie kan verskillende weergawes hê. Die jongste hiervan is die derde. Die GPL is gebruik deur ontwikkelaars van programme soos die Drupal-webinhoudbestuurstelsel, die MariaDB-databasisbestuurstelsel, die InkSkape vektorgrafika-redigeerder, en ‘n paar ander. Dit is interessant om daarop te let dat SQL nie net die GPL gebruik nie, maar ook ‘n kommersiële lisensie.

LGPL

Hierdie naam vertaal na “GNU GPL Lesser General Public License”. Vir sommige ontwikkelaars is die GPL nie geskik nie, aangesien dit ‘n verpligting vir hulle skep om gewysigde produkte onder dieselfde lisensie te versprei. Die kenmerke van die toepassing van hierdie opsie kan geïllustreer word deur hoe die proses van lisensiëring van die gebruik van biblioteke wat deur die programmeerder geskep is, plaasvind. In hierdie geval word die volgende drie opsies oorweeg:

1. Wanneer ‘n biblioteek nuwe funksionaliteit verskaf waar geen ander kommersiële biblioteek dieselfde kan doen nie, dan is die GPL die beste keuse.
2. Die ontwikkelaar in die gratis biblioteek het reeds die bestaande standaard geïmplementeer. In hierdie area is daar kommersiële opsies met soortgelyke funksies. Vir hierdie geval sal dit gerieflik wees om LGPL te kies.
3. As dit kom by ‘n nuwe standaard wat eintlik meeding met die kommersiële een, is die Apache-lisensie die pad om te gaan.

Hierdie standaard
laat kommersiële gebruik van biblioteke toe . Indien wysigings aangebring word, moet dieselfde bepalings en voorwaardes vir verspreiding gebruik word. Die eenvoudige gebruik van die kode laat egter toe dat die toestande verander.

Eclipse Publieke Lisensie

Hierdie dokument
laat verspreiding onder ander lisensies toe, insluitend kommersiële lisensies . Die hoofvoorwaarde is dat in die gewysigde werke innovasies in ‘n aparte module geplaas sal word. Hierdie lisensie het gewild geword in die ontwikkeling van produkte in Java. ‘n Voorbeeld is die Clojure-programmeertaal, ‘n raamwerk om java-toepassings te toets.

Mozilla publieke lisensie

Sommige sien hierdie dokument as ‘n kompromie tussen die GPL en kommersiële lisensies. Die MPL vereis
oop toegang tot sekere lêers . Die sagtewareproduk kan sommige lêers onder hierdie lisensie en ander daarsonder bevat. Na die wysiging word dit toegelaat om die lisensie te plaas wat nodig is (dit kan byvoorbeeld ‘n kommersiële een wees), maar dit is slegs moontlik op voorwaarde dat toegang tot lêers wat onder MPL vrygestel is, steeds oop sal wees. In hierdie geval moet die eindgebruiker van inligting oor die outeurs van die oorspronklike sagteware voorsien word. In ooreenstemming met hierdie dokument is die LibreOffice-kantoor, die Mozilla-blaaier en ander sagtewareprodukte vrygestel.

Apache-lisensie Github

AL word die liberale vrye lisensie genoem. Hierdie kenmerk is te wyte aan die feit dat daar
geen vereiste is om ‘n afgeleide produk onder dieselfde toestande as voorheen vry te stel nie . Hierdie dokument word aktief deur die Apache Software Foundation gebruik. Wanneer dit gebruik word, word die volgende toegelaat:

1. Die sagtewareproduk word toegelaat om verder vir kommersiële doeleindes gebruik te word.
2. Aansoekwysigings word toegelaat.
3. Daaropvolgende verspreidings moet die naam van die oorspronklike outeur insluit.

Deur ‘n nuwe variant te skep, is daar geen verpligting vir lisensiehouers om die oorspronklike produkkode te verskaf nie. So ‘n lisensie het aansienlike gewildheid verwerf. Dit kan gedemonstreer word deur bekende sagtewareprodukte te lys wat onder hierdie tipe lisensie vrygestel word: die Android-bedryfstelsel, ‘n raamwerk wat ondernemingstoepassings in Java skep, en die Apache-webbediener. https://youtu.be/wyZq-EazOmU

MIT lisensie

Sommige beskou hierdie gratis sagteware lisensie opsie as die gewildste. Die grootste voordeel daarvan word deur sommige beskou as goeie verenigbaarheid met verskillende soorte gratis of kommersiële lisensies. Die belangrikste kenmerke is die
vermoë om die kode te wysig, sowel as die toestemming om onder ander lisensies te versprei na die keuse van die een wat die veranderinge gemaak het . Die sagtewareprodukte wat hierdie dokument gebruik, is: ‘n JavaScript-biblioteek genaamd JQuiery, ‘n Atom-teksredigeerder, AngularJS, ‘n JavaScript-ontwikkelingsraamwerk.

Onderwater rotse

Soms kies die skrywer eers een weergawe van die lisensie, en wil dit later verander. As hy die program alleen geskep het, sou so ‘n verandering nie moeilik wees nie. In gevalle waar daar baie deelnemers aan die ontwikkeling was, sal dit egter nie werk sonder hul toestemming nie. Byvoorbeeld, die skepper van Linux, hoewel hy eintlik die basis van die bedryfstelsel gemaak het, sal nie die lisensie kan verander sonder die toestemming van al daardie programmeerders wat aan verdere ontwikkeling deelgeneem het nie. Wanneer hulle onder die MPL versprei word, kan diegene wat veranderinge aan die kode gemaak het, nie lêers onder die MPL onder ‘n ander lisensie aanbied nie. Die gebruik van die nuwe dokument sal na ander programmodules verwys.