O que debes saber sobre as licenzas de GitHub: como seleccionar e engadir

Licenzas GitHub: de que estamos a falar? Para crear software, cómpre non só escribilo, senón tamén decidir que usuarios ou desenvolvedores teñen dereito a facer con el. Se alguén crea un programa gratuíto para todos, está a facer unha boa acción, pero quen o utiliza terá que xustificar como o usa. Por exemplo, se unha empresa nas súas actividades vai traballar con calquera oficina libre (por exemplo, LibreOffice), entón os auditores deben poder demostrar que ten dereito a facelo. Para iso, será suficiente presentar a correspondente licenza. Se o desenvolvedor esquece formulalo, entón a empresa pode atoparse nunha posición difícil.
Clasificación de licenzas e tipos de licenzas [/ caption] Ao crear unha aplicación, o programador debe decidir que accións co seu programa se permitirán e cales non. Por exemplo, podemos falar non só de usar, senón tamén de estudar os textos dos programas ou de facer os seus propios axustes no produto software. GitHub é un dos maiores servizos para o desenvolvemento de proxectos colaborativos. Ao mesmo tempo, poden traballar aquí non só de xeito gratuíto, senón tamén en proxectos comerciais. Ao especificar unha licenza adecuada, os desenvolvedores eliminarán a confusión sobre como usar o produto creado. O problema é que hai diferentes tipos de licenzas, e non sempre é doado determinar que opción se debe preferir nun caso concreto. Ademais, non é raro que algúns proxectos non teñan licenza.É necesario saber máis sobre as licenzas para comprender cales son os dereitos e obrigas dos usuarios en diferentes casos.

Por que necesito licenciar proxectos de código aberto en GitHub

Ao especificar a licenza requirida, o desenvolvedor pode proporcionar o seguinte:

1. Condicións de uso do programa . Poderán prever o pago dunha taxa ou, nalgúns ou todos os casos, permitir o seu uso gratuíto.
2. Ás veces créanse programas para ser desenvolvidos pola comunidade . Neste caso, é importante que todos os que o desexen poidan familiarizarse cos textos do programa.
3. Cando o código está dispoñible, algúns poden facer cambios para que o programa sexa funcional e sexa o máis fiable posible. Ás veces o autor pode permitir que todo o mundo o faga, noutros casos ofrécese a enviarlle un cambio e fai axustes no proxecto por si mesmo.
4. Debe decidir se terceiros poden facer cambios no proxecto e propoñer no seu nome. Neste caso, é necesario indicar con que licenza debe estar o seu produto.

Resolvendo estes e outros problemas similares, o autor da aplicación determina en gran medida o destino futuro do produto de software que creou.

Que tipos de licenzas hai

Unha licenza é un acordo no que unha das partes (o concedente) establece unha regra para que a outra parte (o licenciatario) utilice o produto que crea. Na práctica, non estamos a falar da sinatura dun documento por parte das partes, senón do consentimento automático cos dereitos e obrigas correspondentes ao seu uso. Practicamente non hai restricións para especificar dereitos e obrigas. A única condición é que cumpran coa lei. Crear as túas propias licenzas é un traballo complicado xa que debes asegurarte de que é compatible con outras normativas. A mellor opción é seleccionar e utilizar un dos tipos estándar deste tipo de documentos. Na práctica, tamén é costume utilizar multilicenza. Na maioría das veces, nestes casos, utilízanse dúas licenzas simultaneamente.Aínda que o autor do programa ten dereito a formular de forma independente as regras que deben seguir os usuarios, con todo, na práctica desenvolveuse o uso dunha gran cantidade de tipos de licenzas, das que pode escoller a adecuada na maioría dos casos. As seguintes son as opcións máis populares utilizadas en Git Hub na maioría dos casos. As licenzas máis comúns utilizadas en Git Hub son:
O programador terá que ser capaz de escoller un que se axuste aos seus plans. Para facelo correctamente, cómpre comprender que características son inherentes a determinadas especies.

Se o autor se nega a formular o documento, neste caso aplicaranse os dereitos de autor, que están previstos por defecto pola lexislación do seu país. A ausencia dunha licenza deste xeito non significa que poidas facer o que queiras co programa. De feito, esta situación pódese considerar como un dos tipos de licenzas.

Como elixir unha licenza Github

Antes de comezar a buscar unha opción axeitada, é necesario que o programador formule os seus requisitos, a partir dos cales vai proceder a máis licenzas. A continuación, debes familiarizarte coas opcións típicas correspondentes á solicitude. Despois diso, terás que estudar coidadosamente a redacción legal e tomar unha decisión final sobre cal debe ser a licenza. Para facer unha elección informada, cómpre comprender cales son os dereitos e obrigas que determina un determinado tipo de licenza. Para facer a elección correcta, pode utilizar servizos especiais chamados comparadores. Aquí tes algúns exemplos:

1. https://choosealicense.com/. Este sitio contén preguntas orientativas para escoller a opción correcta e consellos detallados para axudarche a comprender os detalles específicos do uso.
2. A páxina https://opensource.org/licenses está dedicada a revisar varias solucións de software libre.
3. O sitio https://tldrlegal.com/ pódese ver como unha enciclopedia para varias opcións de licenza. Contén linguaxe xurídica precisa e comentarios detallados.

Compare as licenzas en https://choosealicense.com/ [[]] Non obstante, a opción máis produtiva é ler atentamente os documentos legais relevantes. Aínda que esta é unha actividade que leva moito tempo, non obstante, o estudo dos textos dará ao desenvolvedor todas as respostas que necesita.

Como engadir unha licenza a Github

A pesar dunha ampla selección de opcións de licenza, que na práctica demostraron a súa eficacia e fiabilidade, o programador pode ter as súas propias ideas sobre cal debe ser a licenza para o programa que creou. Neste caso, o servizo ofrece a posibilidade de engadir a súa propia versión ou axustar a existente. Para engadir unha licenza a Github, debes seguir estes pasos:

1. Debes ir á páxina principal do teu repositorio.
2. Debe facer clic no botón para engadir un ficheiro e, a continuación, seleccionar “Crear novo ficheiro”.
3. A continuación, cómpre introducir o nome do ficheiro. Para unha licenza, pode ser unha das dúas opcións: LICENCE ou LICENCE.md. Aquí é obrigatorio usar maiúsculas.
4. Á dereita do campo de entrada do nome do ficheiro, faga clic para seleccionar un modelo de licenza.
5. No menú do lado esquerdo da páxina, seleccione a liña “Engadir unha licenza ao seu proxecto”. Neste caso, selecciónase unha opción dos documentos existentes.
6. A continuación, fai clic na liña “Revisar e enviar”. A continuación, introduza os detalles do seu acordo.
7. Despois diso, é necesario aclarar cales foron as adicións ou cambios que se fixeron. A continuación, indican se o documento seleccionado foi corrixido ou se estamos a falar de crear outra versión da licenza.

Despois de confirmar os cambios, o programador completa o procedemento para facer cambios na lista de licenzas do servizo Git Hub.

Escolla unha licenza GitHub – Exemplos de licenzas populares en Git Hub

A continuación, consideraremos aquelas opcións que son as máis populares. Despois de comprender os seus puntos fortes e débiles, o programador poderá atopar a opción correcta ou comprender como buscar de forma eficaz.

GPL

Esta licenza pódese chamar unha das máis populares. É clásico para os que fan software libre. Un dos principais requisitos deste documento é que
permite a terceiros modificar libremente o programa , pero ao mesmo tempo teñen dereito a distribuír o resultado só baixo a mesma licenza. Esta licenza pode ter versións diferentes. O último é o terceiro. A GPL foi utilizada polos desenvolvedores de programas como o sistema de xestión de contido web Drupal, o sistema de xestión de bases de datos MariaDB, o editor de gráficos vectoriais InkSkape e varios outros. É interesante notar que SQL usa non só a GPL senón tamén unha licenza comercial.

LGPL

Este título tradúcese a GNU Lesser General Public License GPL. Para algúns desenvolvedores, a GPL non é adecuada, xa que lles crea a obriga de distribuír produtos modificados baixo a mesma licenza. As peculiaridades do uso desta opción pódense ilustrar por como se produce o proceso de licenza de uso de bibliotecas creadas por un programador. Neste caso, é habitual considerar as seguintes tres opcións:

1. Cando unha biblioteca ofrece novas funcións e ningunha biblioteca comercial pode realizar unha tarefa semellante, entón o uso da GPL é óptimo.
2. O programador da biblioteca gratuíta xa implementou o estándar existente. Neste ámbito, hai opcións comerciais con funcións similares. Neste caso, será conveniente escoller LGPL.
3. Cando se trata dun novo estándar que compite con outro comercial, a licenza de Apache é adecuada.

Este estándar
permite o uso comercial das bibliotecas . Se se realizan modificacións, deberán utilizarse os mesmos termos e condicións para a distribución. Non obstante, o simple uso do código permite que as condicións cambien.

Licenza pública Eclipse

Este documento
permite a distribución baixo outras licenzas, incluídas as comerciais . A principal condición é que nas obras modificadas as novidades se coloquen nun módulo aparte. Esta licenza gañou popularidade no desenvolvemento de produtos Java. Un exemplo é a linguaxe de programación Clojure, un marco para probar aplicacións java.

Licenza pública de Mozilla

Algúns ven este documento como un compromiso entre a GPL e as licenzas comerciais. É un requisito da MPL
ter acceso público a determinados ficheiros . O produto de software pode conter algúns ficheiros baixo esta licenza e outros sen ela. Despois da modificación, permítese poñer a licenza que se precisa (por exemplo, pode ser comercial), pero isto só é posible a condición de que o acceso aos ficheiros liberados baixo a MPL aínda estea aberto. Neste caso, o usuario final debe recibir información sobre os autores do software orixinal. LibreOffice Office, o navegador Mozilla e outros produtos de software foron publicados de acordo con este documento.

Licenza Apache Github

AL chámase licenza libre liberal. Esta característica débese a que non hai
ningún requisito para lanzar un produto derivado nas mesmas condicións que antes . Este documento é usado activamente pola Apache Software Foundation. Ao usalo, permítese o seguinte:

1. O produto de software pode seguir utilizándose con fins comerciais.
2. Admítense modificacións nas solicitudes.
3. As redistribucións posteriores deberán incluír o nome do autor orixinal.

Ao crear unha nova variante, os licenciatarios non teñen a obriga de proporcionar o código de produto orixinal. Esta licenza gañou unha gran popularidade. Isto pódese demostrar enumerando os produtos de software coñecidos que se lanzan baixo este tipo de licenza: o sistema operativo Android, o marco co que crear aplicacións empresariais en Java, o servidor web Apache. https://youtu.be/wyZq-EazOmU

Licenza MIT

Algunhas persoas consideran que esta opción de licenza de software libre é a máis popular. Algúns consideran que a súa principal vantaxe é a boa compatibilidade con varios tipos de licenzas libres ou comerciais. As características máis importantes son a
posibilidade de modificar o código, así como o permiso para redistribuír baixo outras licenzas a elección da persoa que fixo os cambios . Os produtos de software que usan este documento son: unha biblioteca JavaScript chamada JQuiery, un editor de texto Atom, AngularJS, un marco para desenvolver en JavaScript.
Comparación de licenzas para Git Hub [/ caption]

Rochas submarinas

Ás veces, o autor escolle inicialmente unha versión da licenza e despois quere cambiala. Se creou o programa só, tal cambio non será difícil. Non obstante, nos casos nos que houbo moitos participantes no desenvolvemento, non funcionará sen o seu consentimento. Por exemplo, o creador de Linux, aínda que en realidade fixo a base do sistema operativo, non poderá cambiar a licenza sen o consentimento de todos aqueles programadores que participaron no desenvolvemento posterior. Ao redistribuír baixo MPL, aqueles que fixeron cambios no código non poden ofrecer ficheiros baixo MPL baixo outra licenza. O uso do novo documento aplicarase a outros módulos de software.