Qual é a melhor maneira de fornecer versões de código aberto e fechado lado a lado com segurança?

Minha empresa está procurando desenvolver e lançar um projeto de software de código aberto juntamente com uma versão aprimorada proprietária, semelhante ao VirtualBox anterior à 4.0.

Qual é a melhor maneira de manter as duas bases de código de modo que as alterações na versão de código aberto possam ser facilmente incorporadas à versão comercial com risco mínimo de enviar acidentalmente código proprietário para o produto de código aberto?

open-source proprietary version-control

— rkjnsn
fonte

Respostas:

Eu criaria 2 projetos.

Projeto OSS que pode ser executado de forma independente.
Código proprietário que depende do código do projeto OSS.

Você pode ter a dependência como um tempo de construção ou dependência de tempo de execução. Se você deseja que cada pacote seja independente, poderá solicitar que o pacote proprietário puxe os arquivos OSS necessários durante a criação do pacote / compilação. Se você está bem com uma dependência de tempo de execução, você pode apenas empacotar o código proprietário sozinho e fazê-lo depender do pacote OSS no tempo de execução.

Benefícios:

Libera você da duplicação de código.
Obtenha correções de erros em ambos pelo custo de obtê-lo em um.
Delineamento claro entre OSS e Proprietário.

— dietbuddha
fonte

+2: Se possível, crie os plugins de funções proprietárias. A experiência das pessoas com a versão do OSS aumentará seu apetite e elas poderão comprar / instalar diretamente as novas funções enquanto executam o aplicativo. Você pode até configurá-lo para que cada plug-in proprietário tenha um período de avaliação de X dias. Isso não apenas resolve seu problema de gerenciamento de base de código, como facilita o marketing.

— Peter Rowell

Controle e ramificação da fonte

A raiz seria o código comum às duas distribuições. Você também (presumivelmente) criaria dois ramos da sua raiz:

Open Source

Closed Source

Open Sourceprovavelmente espelharia sua raiz nesse cenário. Em uma base regular, você mesclaria Open Sourcee Closed Sourcemanualmente ( Closed Sourceprovavelmente não obteria tantas atualizações).

Dessa forma, você pode manter os aprimoramentos em sua Closed Sourcefilial e obter novas alterações na versão de código-fonte aberto.

— Craige
fonte

Existe uma maneira de fazer isso usando repositórios separados? Esperamos ter o repositório que contém o código-fonte aberto visível publicamente.

— precisa saber é o seguinte

Depende da licença de código aberto que não está declarada na pergunta. A GPL apresenta a maioria dos problemas a esse respeito e qualquer link estático ou link de tempo de execução é suspeito.

Leia as perguntas frequentes para obter melhores resultados; não confie em outras respostas. O uso de plug-ins não é verdadeiramente legítimo. Muitos produtos comerciais violam a GPL de maneiras diferentes e basicamente parecem de outra maneira.

http://www.gnu.org/licenses/gpl-faq.html

Se um programa lançado sob a GPL usa plug-ins, quais são os requisitos para as licenças de um plug-in? Depende de como o programa chama seus plug-ins. Se o programa usa fork e exec para chamar plug-ins, então os plug-ins são programas separados, portanto, a licença para o programa principal não requer requisitos para eles.

Se o programa vincular dinamicamente plug-ins e eles fizerem chamadas de função entre si e compartilharem estruturas de dados, acreditamos que eles formarão um único programa, que deve ser tratado como uma extensão do programa principal e dos plug-ins. Isso significa que os plug-ins devem ser liberados sob a GPL ou uma licença de software livre compatível com GPL e que os termos da GPL devem ser seguidos quando esses plug-ins forem distribuídos.

Se o programa vincular dinamicamente plug-ins, mas a comunicação entre eles se limitar a chamar a função 'principal' do plug-in com algumas opções e aguardar o retorno, esse é um caso limítrofe.

— Jonathan Cline IEEE
fonte

Se você detém os direitos autorais do software GPL, pode distribuir os plug-ins de código fechado - o detentor dos direitos autorais original é quem define as regras de licença e certamente não está vinculado à licença. Por outro lado, isso significa que 1) você não pode aceitar contribuições da GPL sem exigir uma atribuição de direitos autorais e 2) que outras pessoas não podem distribuir os plug-ins com o software da GPL.

— han

Por que você confiaria nas perguntas frequentes sobre outras fontes? Está vindo talvez da fonte mais tendenciosa concebível. E se eu colocar meu trabalho sob a GPL, não importa se a FSF diz que a GPL diz que você pode fazer X. Se a lei ea licença dizer que você não pode, eu ainda pode processá-lo e eu ainda vai ganhar.

— David Schwartz

"Por que você confiaria no FAQ sobre outras fontes?" Como o FAQ é baseado em casos anteriores do mundo real, não na hipótese de poltrona de escritores de blog de troca de pilha cujas reputações técnicas são visíveis principalmente principalmente por pontos atribuídos pela popularidade e não pela correção.

— Jonathan Cline IEEE

Ainda não escolhemos uma licença para a versão de código aberto. Temos os direitos autorais de todo o código, portanto, liberá-lo sob duas licenças separadas não deve ser um problema.

— Rkjnsn 20/09/11

Se você não escolheu uma licença, é muito melhor usar uma licença baseada em BSD do que uma viral (viral = significa baseada em GPL). Muitos produtos usam o netbsd incorporado em um produto de servidor com código proprietário (as partes de valor agregado) diretamente integradas à árvore. Embora como outro autor indique, você pode liberar usando uma licença dupla .. que pode ser confusa para vendas e mkting. Talvez um exemplo bem-sucedido de referência seja o Apple Darwin ("Licença de fonte pública da Apple", agora licença Apache): en.wikipedia.org/wiki/Darwin_(operating_system)#License

— Jonathan Cline IEEE