Que tipos de licenças de código aberto NÃO são OK para uso interno em uma corporação? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 4 anos .

Recentemente, aprendi sobre várias ferramentas e bibliotecas completas de código aberto para o Microsoft Visual Studio. As ferramentas apenas ajudam você a ser mais produtivo; as bibliotecas seriam vinculadas à base de código corporativa.

Listei todas essas ferramentas e bibliotecas legais em uma planilha e vou detalhar o tipo de licença em que cada uma está sujeita. Até agora, entre minhas bibliotecas legais, vejo o MIT , BSD , Apache License Versão 2.0 . No entanto, pode haver mais no futuro.

Como posso descobrir (ou melhor ainda, você pode apenas listar) as licenças populares que NÃO são compatíveis com o uso corporativo interno (que não devem ser distribuídas fora da empresa)? E, para um agradecimento extra, você pode dizer ou apontar para uma explicação. Não sou advogado e ler as letras pequenas dessas licenças me dá dor de cabeça.

Quero estar preparado para explicar por que o uso das licenças permitidas está correto.

licensing open-source

— toddmo
fonte

Você realmente gostaria disso com alguém da sua empresa. Como princípio geral, usar qualquer coisa GPL em software proprietário é uma violação. A licença da GPL é viral , o que significa que, se a sua empresa usa código licenciado pela GPL, eles precisam essencialmente abrir o código inteiro do projeto. A maioria das licenças de código aberto não é viral, no entanto. Alguns, como a Mozilla Public License, exigem que você publique livremente as alterações feitas na própria base de código MPL , mas esse requisito não é transferido para o seu próprio código. Mas essa é realmente uma pergunta muito ampla para responder facilmente aqui.

— Mason Wheeler

@MasonWheeler: Disposições como copyleft têm tudo a ver com distribuição; se o programa só for usado internamente, não importa.

— 31715 Robert Harvey

@toddmo: parece que Mason Wheeler ao escrever sobre a GPL ignorou completamente a parte "a não ser distribuída fora da empresa" da sua pergunta? Veja stackoverflow.com/questions/1492687/…

— Doc Brown

Até o próprio Richard Stallman diz o tempo todo que, se você usa o software GPL e não o distribui, não precisa contribuir com nada. Mas sempre leia a licença. Especialmente as licenças mais curtas não são tão difíceis de ler. Se você pode ler o código do computador, vamos lá, você pode ler essas licenças.

— Brandin

@BasileStarynkevitch Perguntas sobre licenças da perspectiva de um desenvolvedor de software (por exemplo, uso, licença, entendimento etc.) estão no tópico ON, desde que não estejam solicitando aconselhamento jurídico especial. Minha impressão é que essa pergunta está correta, pois o OP está procurando orientação para selecionar uma licença apropriada para o software em que está trabalhando.

— maple_shaft

Respostas:

Em geral, as legalidades no licenciamento que podem ocorrer como resultado do uso de software de código aberto se resumem a dois fatores:

Uso comercial e
Distribuição.

Distribuição significa "conferir" o software a terceiros fora da organização. Como você diz que usa o software apenas internamente, mecanismos legais como "copyleft" (o termo usado para a parte viral da licença GPL) provavelmente não se aplicam à sua organização.

O uso comercial (ou outras restrições arbitrárias) é outra questão. Basta ler a licença com cuidado e determinar se alguma dessas restrições se aplica à sua organização. Em particular, licenças permissivas como Apache, MIT e BSD têm poucas, se houver, condições restritivas; essas licenças são ideais para "uso interno".

Parece que sua empresa está relutante em usar software de código aberto. Muitas empresas acreditam que devem possuir completamente seu software e outras propriedades intelectuais e, portanto, possuem políticas que determinam que seus próprios desenvolvedores devem escrever todas as linhas de código. Esclarecer o significado das licenças de código aberto não mudará necessariamente de idéia.

— Robert Harvey
fonte

Nenhuma dessas três licenças possui restrições específicas que impediriam sua empresa de usá-las livremente em um contexto interno da empresa. Todos são considerados licenças "permissivas".

— 31715 Robert Harvey

A maioria das empresas simplesmente não aceita licenças "copyleft" e por boas razões; é extremamente impossível "colocar em quarentena" perfeitamente um sistema e garantir que nada jamais toque indiretamente o código GPL / AGPL. Algumas licenças aparentemente "permissivas" como o WTFPL também não ajudam, porque são vagas demais em questões legais importantes, como direitos autorais. Mesmo que você ache que poderia se defender com sucesso de uma ação, você realmente quer passar por isso? (Dica: os seus advogados provavelmente não.) Atenha-se ao Apache e ao MIT. Eu acho que o BSD também está bem.

— Aaronaught 28/03

@Aaronaught Você tem alguma fonte geralmente respeitada que apóie sua alegação de que o WTFPL é um direito vaga de direitos autorais? A FSF aceita como compatível com GPL. As principais distribuições Linux aceitam-no como grátis. Posso encontrar uma alegação de que o OSI o rejeitou por ser muito vago, mas isso é falso, o OSI o rejeitou como redundante, pois uma rápida pesquisa no Google por "wtfpl osi" confirmará. Posso pensar em problemas com o WTFPL, com certeza, mas quando se trata de direitos autorais, a imprecisão não é um desses problemas.

— hvd 28/03

@hvd: Pode chocar você saber que os advogados corporativos não se importam com coisas como "grátis" ou "não livre". Eles se preocupam com "podemos usar isso sem ser processado?". Você realmente leu o WTFPL ? Isso não diz nada. Leia a seção 2 da Licença Apache para ver como é uma cláusula de direitos autorais adequada. O WTFPL não concede explicitamente uma licença de direitos autorais, nem a torna irrevogável. Você não precisa ler a avaliação da FSF - basta olhar para a licença!

— Aaronaught 28/03

Ainda estamos falando sobre isso?

— Robert Harvey

Há algumas coisas que você deve saber: primeiro, os advogados de sua empresa podem entrar em acordo se você usar código de terceiros sem pedir a eles. Portanto, você não deve usar código de terceiros sem informar seu chefe ou gerente e obter o consentimento deles. Como você disse, você não é um advogado.

Segundo, um desagradável: se você encontra código na internet e ele tem alguma licença, não sabe de onde vem. Você não sabe se a pessoa que adicionou a licença realmente tinha o direito de fazê-lo.

Terceiro, para licença GPL e uso interno: coisas que são para uso interno hoje podem não ficar para uso interno. Você pode ter escrito um software muito bom para uso interno e sua empresa pode decidir lucrar com a venda. E então você pode ter um problema.

— gnasher729
fonte

No seu segundo exemplo, isso seria problema de outra pessoa

— whatsisname 28/03

@whatsisname Diga isso ao autor original quando ele o processar.

— sapi 28/03/2015

@whatsisname Se A escreveu o software e detém os direitos autorais, B o distribui sob alguma licença sem permissão, e C obtém o software de B e usa e talvez modifica ou redistribui-o. moral ou legal, ir atrás de B. A pode nem estar ciente de B. C é quem é pego usando, modificando, redistribuindo, então C é quem precisa parar e pagar uma indenização. Não há nenhuma maneira de C poder continuar. Na melhor das hipóteses, C pode ir atrás de B no tribunal, mas isso é apenas se C puder encontrar B. Boa sorte se for um cara na China.

— hvd 28/03

A situação no parágrafo 2 é sempre uma possibilidade. Suponha que você compre uma biblioteca de origem comercial com a licença para usar essa fonte fechada vinculada no seu código. Como você realmente sabe que a empresa que vendeu esse software legalmente tem direito a isso?

— Brandin

O segundo parágrafo é o mais perigoso. Eu pessoalmente me deparei com isso quando um desenvolvedor mencionou que um pouco de código era "algo que ele encontrou em algum site em algum lugar" bastante próximo do lançamento. Não tem graça. Lição # 412 em "por que você deve revisar tudo de código".

— Gort the Robot

Isso depende muito do contexto.

Se você deseja usar qualquer software de código aberto para o qual você é livre.

Se você deseja usar qualquer software de código aberto para a base de projetos internos da empresa, também é livre para (uma vez que licenças mais contagiosas como a gpl exigem que você forneça o código-fonte, mediante solicitação, a todos para quem o código compilado é distribuído, se for um aplicativo interno, isso não é problema)

Se você quiser usar software de código aberto para a base de um produto, siga a licença com cuidado (envolva os advogados da empresa) e, se a licença for infecciosa, talvez seja necessário disponibilizar seu código-fonte para todos aqueles que recebem o código compilado. Em alguns casos, isso é aceitável (por exemplo, escrever um produto personalizado para um único cliente que possui o código-fonte de qualquer maneira) em outros, isso não é (por exemplo, um produto vendido ao público em geral com uma versão "trial" disponível para qualquer pessoa )

Mas, para responder sua pergunta diretamente, lgpl e gpl são perfeitamente adequados para uso corporativo interno.

Como posso fazer o download do nedit, ou gnu, alterá-lo para o conteúdo do meu coração sem a necessidade de tornar meu código público, e depois usá-lo eu mesmo, não há diferença para o fazer para uso interno dos meus empregadores.

— Damian Nikodem
fonte