Hoe kies je een GitHub-licentie en waarom is het belangrijk om niet de verkeerde keuze te maken? GitHub is de grootste dienst voor het gezamenlijk ontwikkelen van IT-projecten en de daarop volgende hosting. Met behulp van deze webservice kan een onbeperkt aantal mensen tegelijk aan een project werken, maar ook van waar ook ter wereld. Ook in GitHub is er een beheersysteem of controle waarmee u absoluut alle wijzigingen door ontwikkelaars voor elk moment kunt bekijken en controleren, en waarmee u ook kunt terugkeren naar de staat die vóór de wijzigingen plaatsvond.
Wat is een GitHub-licentie?
Een licentie is een speciaal document dat is opgesteld door de staatsvorm en waarmee men een bepaald type ondernemingsactiviteit kan uitoefenen, wat noodzakelijkerwijs speciale aandacht van de staat die partij is vereist. Maar in de praktijk worden meestal alleen verkorte licentieovereenkomsten gebruikt of overeenkomsten die voorzien in de afgifte van privaatrechtelijke licenties. In het algemeen streeft de licentie maar één doel na, maar het belangrijkste doel is een overeenkomst over verplichtingen en rechten tussen de licentiegever en de licentienemer. Deze plichten en rechten kunnen van alles zijn, maar alleen binnen het kader van de wet. Een treffend voorbeeld is dat de licentiegever bij gebruik van het werk door de licentienemer de verplichte vermelding van de naam van de auteursrechthebbende kan verlangen. Of bijvoorbeeld om het kopiëren van het werk toe te staan,maar verbied absoluut elke wijziging ervan. Of, om zulke eisen af te leiden dat het werk onder absoluut dezelfde voorwaarden als het origineel moet worden geproduceerd, enzovoort, zijn er veel voorbeelden van verschillende voorwaarden die naar voren worden gebracht. [bijschrift id = “attachment_12368” align = “aligncenter” width = “780”]
Maar we mogen ook niet vergeten dat de licentie de rechten van niet alleen de licentiegever, maar ook de licentienemer beschermt. Daarin kun je alle gebruiksvoorwaarden van het werk duidelijk zien en lezen en hoeft hij dus niet bang te zijn dat de licentiegever plotseling royalty’s of enige andere vergoeding voor het gebruik van zijn werk zal eisen.
Als u zich afmeldt voor een licentie die aan een werk is gekoppeld, blijft het auteursrecht gelden volgens de in dat land geldende wettelijke regels. Simpel gezegd, het ontbreken van een licentie betekent op geen enkele manier dat andere auteurs dit project kunnen gebruiken zoals ze willen. Alles, absoluut, integendeel, want zonder enige specifieke licentie doet een programmeur op geen enkele manier afstand van de rechten die door de wet zijn verleend. Het is ook belangrijk om altijd te onthouden dat de licentie alle rechten en plichten regelt. Dit is om de eigenaar van het werk te beschermen tegen de verwachtingen van de gebruiker en wat eventuele garantie inhoudt. Niemand wil immers dat zijn code op wat voor manier dan ook voor de rechter komt.
Wat is auteursrecht?
Copyright verschijnt alleen aan een persoon wanneer hij als gevolg van intellectuele activiteit een werk creëert dat uniek is, maar tegelijkertijd nuttig, als voorbeeld kun je het schrijven van hetzelfde programma nemen. Wanneer al het bovenstaande is gedaan, wordt de persoon de auteur en heeft hij nu absoluut alle auteursrechten voor dit werk. Er moet ook worden gezegd dat auteursrechten eigendomsrechten en niet-eigendomsrechten zijn. Hun verschil is dat eigendomsrechten aan iedereen kunnen worden overgedragen, maar niet dat eigendomsrechten altijd alleen bij de auteur blijven in elke situatie. Auteur zijn is immers een onvervreemdbaar en onvervreemdbaar recht.
Waarvoor dient een Open Source-licentie?
Dit is ook een vrij populaire vraag onder beginnende ontwikkelaars en programmeurs, omdat ze gewoon niet begrijpen waarom ze een licentie aan hun projecten zouden moeten koppelen, want zonder deze kan het project ook gemakkelijk bestaan. Dit is echter niet helemaal waar, want als bijvoorbeeld een beginnende ontwikkelaar een nogal belangrijk en nuttig stuk code heeft geschreven, maar dit niet met een licentie heeft beveiligd, hebben andere gebruikers vragen. En juist daarom, als klanten bij hem komen en dit stukje code willen gebruiken voor hun commerciële doeleinden, zien ze dat de code geen licentie heeft en weigeren ze het gewoon. Dit komt doordat bedrijven de code gewoonweg niet zonder vergunning zullen gebruiken, omdat ze geen problemen met de wet en advocaten nodig hebben.
Welke GitHub-licentie is geschikt voor bepaalde voorwaarden – hoe te kiezen?
Een exact antwoord op deze vraag is er niet, aangezien de keuze voor een licentie alleen afhangt van de doelstellingen van het project en van de persoonlijke voorkeuren en wensen van de ontwikkelaar zelf. Zoals je kunt zien, zijn er veel verschillende licenties op GitHub, en het belangrijkste is dat ze allemaal gratis en openbaar beschikbaar zijn, wat betekent dat elke programmeur de Open Source- licentie kan vinden
die precies geschikt is voor zijn project. Maar het belangrijkste is dat we niet mogen vergeten dat een Open Source-licentie niet zomaar een code is zonder licentie.
- Sterk beschermend.
- Zwak verdedigen.
- Toegeeflijk.
Sterk beschermend
Sterk defensieve licenties zijn meestal varianten van de GPL. Deze licenties vereisen noodzakelijkerwijs een licentie voor het project, evenals de openbaarmaking van broncodes, zelfs ongeacht hoe een code of project zal worden gebruikt of al is gebruikt.
zwak verdedigend
Zwak defensieve licenties zijn meestal varianten van de Kleinere GPL. Waarbij het belangrijkste verschil met permissieve licenties is dat het simpelweg noodzakelijk is om het programma onder de GPL-licentie te licentiëren, en ook om de broncodes zonder mankeren te verstrekken. Bovendien, als het project van een programmeur een bibliotheek bevat, dat wil zeggen statische koppeling of dynamische koppeling onder de LGPL-licentie, dan zal het ook compatibel zijn met elke projectlicentie van de programmeur.
Toegeeflijk
Er is een groot aantal permissieve licenties, waaronder de meest populaire licenties MIT, Apache 2.0 en BSD. Met kleine variaties hebben deze licenties de mogelijkheid om het gebruik van de code zowel in Open Source-projecten als voor commerciële doeleinden en projecten toe te staan. Maar in dit geval is het belangrijk om te onthouden dat het noodzakelijk is om het auteurschap van het originele programma aan te geven.
Andere populaire GitHub-licenties
Naast deze drie groepen licenties zijn er nog andere, bijvoorbeeld een van de meest bruikbare licenties is GPLv2 met classpath-extensies. Deze licentie kan ook gebruikt worden zowel in Open source projecten als in commerciële projecten en doeleinden. De meest populaire verschijning is bij Oracle, dit bedrijf gebruikt GPLv2 met classpath-extensies om zijn Open Source-projecten en -oplossingen te licentiëren. Deze licentie is vrij belangrijk en nuttig, aangezien gewone GPL-licenties bijvoorbeeld nooit bytecode aankunnen. Dat wil zeggen, ze hebben een speciale beschrijving van het compilatie- en koppelingsproces, wat volkomen ongepast is voor andere geïnterpreteerde programmeertalen, zoals de meest populaire Java-taal.Voor dergelijke gevallen is een speciale GPLv2-licentie met classpath-extensies uitgebracht. Er staat immers heel duidelijk en duidelijk dat de bibliotheek die onder deze licentie is uitgebracht, met absoluut elke andere licentie in commerciële projecten en doeleinden kan worden gebruikt.
GitHub-licenties .
Een licentie toevoegen
Nadat de definitieve licentie uiteindelijk is geselecteerd, hoeft u deze alleen nog maar toe te voegen aan de projectroot zelf. Om deze actie uit te voeren, moet u de geselecteerde licentie onder de projectroot toevoegen tijdens het aanmaken van het project zelf, of in het algemeen op een ander moment. Maar zelfs bij deze actie slaagde de GitHub-webservice erin om voor zijn gebruikers te zorgen en ze maakten een redelijk gemakkelijke manier om de definitieve licentie toe te voegen, zelfs aan het begin van het project zelf.
