Recomendações e experiências sobre qual licença escolher para o software?

Os desenvolvedores de software têm a opção de escolher uma licença apropriada de acordo com o (s) objetivo (s) do trabalho.

Alguém pode dar algumas recomendações / experiências sobre qual licença escolher para o software?

Quais são os prós / contras de "doar" todo o trabalho codificado como códigos de fonte aberta?

Como lidar com atores industriais que gostariam de se beneficiar do código de pesquisa?

Alguém pode dar algumas recomendações / experiências sobre qual licença escolher para o software?

A licença que você escolheu depende da liberdade que você deseja que seu código seja, mas a liberdade significa coisas diferentes para pessoas diferentes.

• Para proponentes de licenças permissivas , grátis significa permitir que as pessoas agora usem o software da maneira que desejarem agora , sem se preocupar com a derivação futura livre .
• Para proponentes de licenças copyleft , livre significa garantir que o software e qualquer derivação dela permaneçam livres , estando preparado para sacrificar algumas liberdades imediatas para garantir isso.

Quanto mais permissiva for uma licença, mais pessoas poderão usá-la, mas menos controle você terá sobre ela. Quanto mais restritivo, porém, maior a probabilidade de você adiar as pessoas usando o seu software.

Existem várias licenças de código aberto e gratuitas disponíveis, incluindo GPL <= 2, GPL 3 , LGPL , BSD , Eclipse e assim por diante. Existem prós e contras em cada um deles, portanto, leia quais restrições eles impõem ao código e decida quem você deseja usá-lo. Atenção , o que você escolher, alguém irá reclamar - este é um território de guerra santa .

No geral, é um ato de equilíbrio sutil e depende muito do público-alvo do seu software.

• Um excelente recurso para determinar qual licença é a licença certa para você é o diferenciador de licença interativo e muito abrangente , do Oxford Universities OSS Watch .

Na minha opinião, as licenças permissivas e copyleft são apropriadas para o código científico - o importante é que o código seja de código aberto em primeiro lugar. Acredito que a ciência deve ser aberta, assim como o código usado para apoiar essa ciência.

Quais são os prós / contras de "doar" todo o trabalho codificado como códigos de fonte aberta?

A idéia de doar seu software é que, se outros acharem útil, eles o usarão.

Se eles o usarem, eles encontrarão, reportarão e frequentemente corrigem erros, economizando seu esforço de fazer o mesmo.

Se eles gostarem e o seu software fizer quase o que eles querem, eles poderão aprimorá-lo e contribuir com esses aprimoramentos.

Isso é um monte de ifs embora.

Como lidar com atores industriais que gostariam de se beneficiar do código de pesquisa?

Em primeiro lugar, se você quiser proibir o uso comercial do seu código, poderá selecionar uma licença com uma cláusula de não reutilização comercial.

Em segundo lugar, se você acha que alguém pode usar o seu software para alimentar um serviço, sem nunca distribuir o código para outra pessoa, considere o Affero GPL que conecta essa brecha específica do copyleft.

Em terceiro lugar, você pode fazer o acima e oferecer uma opção de licença dupla. A oferta de licenças GPL ou AGPL para download público e licenças comerciais mediante uma taxa oferece o melhor dos dois mundos e significa que você poderá gerar alguma receita com as vendas comerciais do seu software, o que pode ajudar a apoiar suas atividades científicas.

Observe que, se você quiser fazer isso, ofereça-o desde o início - o que provavelmente causará menos atrito por parte dos contribuidores de código aberto do que começar a oferecer licenças comerciais mais tarde. Se a sua comunidade se tornar popular, você não quer que as pessoas o acusem de vender, se você não tiver certeza da possibilidade de exploração comercial posteriormente. Idealmente, você deve configurar um Contrato de Licença de Colaborador (CLA) adequado antes de começar a aceitar contribuições de terceiros em sua base de código.

Esta resposta a esta pergunta também fornece algumas informações boas sobre esta opção.

O PETSc usa essa licença , que é uma forma menos restritiva de BSD . A diferença crucial da GPL, é que o software pode ser usado comercialmente. Muitas pessoas têm uma objeção de princípio ao software fechado, no entanto, na minha experiência, nenhum negócio chegará perto do seu código se ele tiver uma licença GPL. Além disso, os usuários industriais do PETSc têm sido incrivelmente valiosos. Eles tendem a enfrentar problemas bastante complexos, que a maioria dos acadêmicos consideraria mais difícil do que o necessário para uma publicação. Eles também contribuíram com muito código para o PETSc, para que ele entrasse na cadeia de suporte normal. Eu recomendaria contra qualquer licença sem potencial de uso comercial e, de fato, defenderia a licença menos restritiva possível (você pode definitivamente gravar o PETSc em um CD e tentar vendê-lo para o crédulo).

Eu uso a GPL, principalmente por causa do sentimento ao movimento original de código aberto (e, portanto, espero que ajude a se espalhar). Além disso, esta é paradoxalmente a melhor maneira de proteger seus possíveis ganhos dos capitalistas imorais - como autor, você sempre pode distribuir o código em uma licença diferente em paralelo e, assim, manter a versão proprietária para uso comercial de marca branca.
No entanto, isso também pode ser um problema - sua fonte de financiamento pode ter um aviso de que todo o seu trabalho deve se tornar de domínio público, o que vai além desta licença.

De qualquer forma, a coisa mais importante nesse tópico é que qualquer licença é melhor que nenhuma, o que infelizmente é comum no mundo do desenvolvimento científico - e eu odeio todos aqueles / * Roubados do programa de John Smith que ele nunca publicou * / ou A CI acha que vi isso no post de Jane Smith em algum grupo em 1995 ... ou talvez 1993?

Primeiro, os prós / contras de se tornar um código aberto:

Pro: mais pessoas usarão seu código, fornecerão comentários, correções, melhorias etc. Você acabará tendo um código melhor e mais pessoas que confiam nele.

Contras: se você quiser basear uma empresa em seu código, terá menos opções (mas ainda existem algumas, como a venda de serviços de consultoria)

Quanto à escolha de uma licença, eu continuaria na seguinte ordem:

1. Seu empregador / agência de doações impõe alguma coisa? Então você não tem escolha. Verifique isso para todos os colaboradores do código.
2. Você reutiliza o código que possui alguma licença específica que limita sua escolha? Então suas escolhas também são limitadas. Na prática, a integração de partes do código licenciado pela GPL é a fonte mais frequente de tais limitações.
3. Decida o que você mais valoriza: a filosofia de todo o código deve ser aberto por trás da GPL e licenças similares ou a filosofia de incentivar o mais amplo possível por trás da licença BSD.
4. Dentro de cada uma das duas grandes famílias de licenças de código aberto, escolha de acordo com o que é mais comum / aceito em sua comunidade.

A maior parte da minha pesquisa é financiada por fundos públicos e, portanto, sinto a obrigação de usar a licença menos restritiva possível. Se outras pessoas no meu país estiverem ajudando a pagar por essa pesquisa, eu realmente tenho o direito de dizer que elas não podem integrar meu código em uma fonte fechada e / ou distribuição de software comercial? Espero que a maioria das pessoas que usa meu código seja cientista acadêmico, mas não tenho problemas filosóficos com as empresas que aprimoram meu software, integrando-o a outro software (possivelmente comercial), colocando uma GUI nele, etc., para entregar um produto isso os ajuda a obter lucro.

Dito isto, tento usar licenças que exigem atribuição adequada. Por exemplo, se uma empresa não dobrar meu código em um produto comercial maior, eu quero que eles deixam claro que o meu código pode ser obtido livremente de mim. Mas, além disso, quero impor o mínimo de requisitos possível aos usuários do meu código.

Para o desenvolvimento de software que não é financiado por dólares dos contribuintes, entendo que outras licenças podem ser mais apropriadas.

Ninguém explicou isso muito claramente, então acho que vale a pena dizer:

Algumas das licenças de código aberto (principalmente: a GPL) são "virais" no sentido de que sempre que o código é usado em um novo projeto, o novo projeto deve ser licenciado da mesma maneira. Além disso, o código não pode ser vinculado a (de certas maneiras) código licenciado de maneira diferente.

Uma conseqüência prática é:

• Se você implementar um novo método numérico em C, a licença não permitirá chamá-lo de software comum como MATLAB ou Mathematica

• Se você implementar um novo algoritmo de processamento de imagem, a licença não permitirá criar um plug-in do Photoshop.

• e assim por diante ...

Isso não apenas impedirá a reutilização comercial, mas também a reutilização conveniente por outros acadêmicos (se eles usarem software fechado) e, se alguém criar sobre o seu código, impedirá que eles denunciem seu trabalho em um "faça "o que você quiser com ele".

Isso é algo que você deve considerar antes de terminar de formular sua licença.

Coloquei desta maneira porque conheci pessoas (não muito familiarizadas com licenças de código aberto) que não estavam cientes disso ou não o consideraram desse ângulo.

^{(Esta é apenas uma opinião pessoal, mas acredito que a aplicação de tais restrições ao trabalho proveniente da academia (financiada publicamente) não é apropriada. Portanto, eu mantenho o código ou o denuncio.)}

Independentemente de qual licença você escolher, lembre-se de verificar cuidadosamente todos os seus contratos de financiamento para garantir que não haja cláusulas neles que ditem ou restrinjam como você pode licenciar seu software.

Eu sei que no meu caso muitos dos meus projetos são construídos a partir de várias camadas de financiamento, um pouco aqui e um pouco ali, e manter o controle de como eu estou autorizado a licenciar as minhas coisas pelas pessoas que mantêm as luzes acesas e as máquinas em execução são bastante complexas.

Para grandes quantidades de código, busco uma das licenças descritas nas outras respostas, e geralmente LGPL. No entanto, embora geralmente não seja recomendado para software , para pequenos scripts independentes que eu possa estar enviando a um colega do setor, geralmente opto por uma licença Creative Commons . Isso ocorre porque eles tendem a ser mais claros para o indivíduo para quem eu envio o código, o que interrompe qualquer problema potencial de mal-entendido. Isso funcionou bem para mim no passado.

Ao contrário da maioria das pessoas que atendem aqui (que trabalham em organizações acadêmicas e / ou públicas), estou trabalhando na esfera comercial.

Para meus produtos, o código está fechado e continuam a existir grandes vantagens comerciais para isso. Mas existem outras maneiras de fazê-lo (por exemplo, como demonstrado pelo MySQL, entre outros). Costumo ver a abordagem de licença comercial LGPL + para bibliotecas. Ainda tenho que usar essa biblioteca em um sistema comercial, mas não a descartaria (até agora, apenas usei essas bibliotecas, por exemplo, ALGLIB, no nível de P&D). Isso contrasta com um produto GPL - que eu poderia usar internamente, mas nunca usaria em um produto, principalmente devido à natureza viral.

Quando libero o código-fonte (exemplos de instruções, programas gratuitos etc.), normalmente uso a licença de Berkeley. Isso parece ser muito mais no espírito do código "livre", com atribuição, mas sem as cordas e a política da GPL. Talvez seja por isso que (ou licenças semelhantes, como a licença MIT) sejam tão populares entre universidades e organizações públicas. O código-fonte é distribuído no verdadeiro significado de 'grátis' (aqui está um código, faça o que você quiser com ele), mas o autor ainda recebe crédito / atribuição.

Essa é uma pergunta antiga, mas acho que vale a pena mencionar a Licença Pública Mozilla como um meio termo entre licenças permissivas (BSD, MIT) e licenças copyleft fortes (GPL). O código MPL pode ser usado e redistribuído, mas o código MPL e quaisquer modificações nele devem ser disponibilizados. Por exemplo, uma empresa pode pegar algum código MPL, fazer seus próprios aprimoramentos e distribuí-lo em um pacote de software de código-fonte proprietário, desde que disponibilize sua versão modificada do código MPL original. Eles não são obrigados a liberar todo o seu próprio código-fonte, como fariam com a GPL.

Com a licença BSD, existe o medo de que uma empresa possa pegar seu código e melhorá-lo sem devolver essas contribuições a você ou à comunidade em geral, sob a lógica de que as melhorias que eles fazem a ele conferem uma vantagem competitiva. (A resposta de Matt Knepley sugere que nem todos agem assim). Por outro lado, muitas pessoas podem evitar completamente o código GPL. O MPL evita essas duas armadilhas potenciais, pelo menos em princípio.