Razões para NÃO abrir código sem fins lucrativos de código-fonte? [fechadas]

Eu sou um grande fã de código-fonte aberto. Eu acho que entendo a maioria das vantagens de ter código aberto. Sou pesquisador de estudantes de ciências e tenho que trabalhar com uma quantidade bastante surpreendente de software e código que não é de código aberto (seja proprietário ou público). Não vejo realmente uma boa razão para isso e posso ver que o código e as pessoas que o usam definitivamente se beneficiariam de ser mais públicos (se nada mais, na ciência, é vital que seus resultados possam ser replicados, se necessário, e isso é muito mais difícil se outras pessoas não tiverem acesso ao seu código).

Antes de sair e iniciar o proselitismo, quero saber: existem bons argumentos para não divulgar publicamente o código sem fins lucrativos e com uma licença compatível com OSI?

(Eu sei que existem algumas perguntas semelhantes por aí, mas a maioria se concentra em situações em que o código é usado principalmente para ganhar dinheiro, e eu não era muito relevante nas respostas.)

Esclarecimento: Por "sem fins lucrativos", incluo motivos de lucro a jusante, como reconhecimento da marca da empresa-mãe e expectativas de lucro do investidor. Em outras palavras, a questão refere-se apenas ao software para o qual NÃO há motivo de lucro vinculado ao software que nunca.

Você precisa levar em consideração que o código aberto do código pode exigir um esforço adicional.

Como exemplo, nesta entrada do blog, o engenheiro da Sun / Oracle descreve os esforços que eles tiveram que realizar ao fornecer código aberto : código- fonte aberto ou roupa suja?

À medida que nos preparamos para mergulhar no mundo do código aberto, uma das muitas atividades que está ocorrendo é a preparação do código para o código aberto. Existem algumas coisas óbvias que precisam ser feitas. Por exemplo, nosso código-fonte inclui uma mistura de código que escrevemos e código que licenciamos de outras pessoas. Precisamos separar o último e o código aberto apenas os trechos de código apropriados.

Outra atividade de preparação é "limpar" o código de informações proprietárias, menciona clientes particulares, desenvolvedores, tecnologias etc. Isso é um pouco menos óbvio, mas considere o seguinte exemplo:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Embora tudo isso possa ser verdade, provavelmente temos um tipo de relacionamento com a Intertrode Tech e ter comentários como este no código pode prejudicar nossos negócios de alguma forma e, portanto, deve ser removido. Indiscutivelmente, ele não deveria estar lá em primeiro lugar, mas agora é a hora de eliminá-lo.

Outra parte da atividade "esfregar" é remover palavrões e outras palavras "indesejáveis" ...

Observe que todas as alterações acima tiveram que ser feitas no código que foi considerado perfeitamente correto como fonte fechada - o que torna um esforço extra puro , por assim dizer.

Segurança.

Por exemplo, digamos que você construa uma estrutura da Web e você mesma a use.

Como um projeto sem fins lucrativos, você não teve tempo para se dedicar a inspecionar cada pedaço de código em busca de vulnerabilidade a um ataque ou outro:

• CSRF
• XSS
• injeção SQL
• Fixação de sessão
• Uso de bibliotecas de terceiros com erros ou mesmo idiomas

Agora, com o código aberto do projeto, você permite que olhos amigáveis ​​contribuam, mas também permite que olhos maliciosos tenham uma visão completa do seu trabalho e, se eles encontrarem um servidor que esteja executando seu código, você eliminou sua capacidade de ocultar imperfeições na obscuridade.

Obviamente, isso pode não se aplicar ao tipo de software em que você está trabalhando; e, como sempre, a obscuridade não é desculpa para a preguiça na segurança.

No entanto, assim como eu encontrei nos dois níveis que passei no Stripe, capture o jogo da bandeira , sabendo que o código é uma das maneiras mais fáceis de encontrar vulnerabilidades (e às vezes pode ser a única maneira).

Um bom motivo para não abrir o código-fonte é que parte da sua fonte pode ter direitos autorais. Com que frequência você não pesquisa na Web uma solução rápida para um problema e apenas pega o trecho de código encontrado?

Bem, eles podem ter direitos autorais e não sei se o autor gostaria de encontrar seu código sendo licenciado sob uma licença diferente.

Você precisa ter cuidado com a maneira como escolhe sua licença para evitar possíveis problemas de responsabilidade.

Um advogado pode ser uma pessoa melhor para conversar sobre isso, mas a idéia geral é o que acontece se alguém usa (ou usa mal) o aplicativo e isso causa algum dano? Você é responsável? Obviamente, isso dependeria do tipo de software que você está escrevendo, mas você sempre precisa ter cuidado com o que sua licença diz sobre sua responsabilidade. Isso pode ser uma coisa complicada de corrigir, então pode ser mais fácil simplesmente não liberar o código-fonte.

Aviso: Não sou advogado .

Bem, se é uma organização sem fins lucrativos e sua propriedade intelectual está fortemente ligada ao código do software, alguns podem querer protegê-lo de ser reutilizado comercialmente ou mesmo explorado abusivamente para criar cópias em carbono do seu software.

Algumas outras razões - que provavelmente estão profundamente enraizadas na primeira - são: no seu caso, muitas das pesquisas de ponta acontecem com financiamento privado, e geralmente os investidores desejam ver o ROI. E até agora, nem todos os atores da indústria de software (ou recém-chegados) foram totalmente convencidos da viabilidade do modelo de código aberto (provavelmente por falta de conhecimento e entendimento do licenciamento, ou por simples medo de que o licenciamento não impeça ações maliciosas). usos e cópias).

Além disso, essas empresas não querem ser processadas por aqueles que tentaram obter lucro, e o licenciamento também é visto como uma salvaguarda a esse respeito, por um bom motivo ou não.

Pode não parecer, mas talvez as organizações sem fins lucrativos sejam lucrativas para seus fundadores ou investidores. Os benefícios simplesmente não são diretos. Portanto, eles têm um grande interesse em que os PFN fiquem fortes e não sejam derrotados pelos concorrentes (mesmo que você também não pense em "concorrentes" no mercado sem fins lucrativos), e desejam preservar seus interesses. IP, mesmo que isso acarrete o custo de não obter mais folgas para revisar seu código para encontrar problemas e melhorá-lo desde o início.

Observe também que as leis de direitos autorais diferem de país para país. Muitos países europeus consideram as leis de direitos autorais dos EUA e o sistema de patentes dos EUA bastante atordoados, por exemplo, então há uma base cultural e um peso que são difíceis de eliminar.

Jut meus 2 centavos sobre o assunto.

(Trabalhei muito com universidades e, recentemente, em bioinformática e saúde ... É uma pergunta recorrente para mim e meus colegas :))

Existem pelo menos dois tipos diferentes de código aberto.

Se sua atitude é "aqui está algo útil, eu terminei com isso" (e isso acaba sendo preciso), então há pouca desvantagem.

Por outro lado, se sua atitude for "Estou realmente empolgado e quero que alguns usuários reais ajudem a impulsionar o desenvolvimento futuro", pense com muito cuidado. Você precisará gastar tempo dando suporte aos usuários, muitos dos quais não têm noção. Você precisará considerar solicitações conflitantes de recursos e aprimoramentos. Você achará cada vez mais difícil fazer alterações, preservar a compatibilidade com versões anteriores.