É importante observar que esse cenário pode ocorrer em formas legais e ilegais.
Isso pode ocorrer legalmente se a empresa possuir ou tiver acesso aos direitos autorais associados ao código. Por exemplo, equipes de desenvolvimento menores e independentes podem querer vender ou licenciar seus direitos autorais para uma empresa maior. Da mesma forma, se a maior parte dos direitos autorais do código puder ser adquirida, a parte "inatingível" pode ser simplesmente descartada e reescrita.
Do outro lado da moeda, o código pode ser simplesmente tomado ilegalmente. A New Corp, Inc. pode não se importar com as implicações legais. O projeto pode ser muito antigo ou abandonado ou a New Corp acha que vencerá em um processo. Ou a New Corp pode ser registrada em uma área onde esse tipo de "aquisição" simplesmente não é definido como ilegal. Nem todas as licenças de OSS são aplicáveis, especialmente as que foram construídas por não especialistas na lei. Nem todos os proprietários do projeto podem aplicar suas reivindicações de direitos autorais, e organizações maiores, como a FSF, podem não estar nessa jurisdição para essa reivindicação. TL; DR - essa área pode ficar turva e feia muito rápido.
Transição e prevenção
Como a transição acontece e o que pode ser feito para evitar que ela escolha uma licença diferente?
A transição ocorre quando a New Corp, Inc. adquire a base de código e coloca a cópia sob seu controle. Os desenvolvedores da New Corp começam a trabalhar em sua versão da base de código, fazendo as alterações que os senhores da empresa considerarem necessárias. A mecânica real deste fork irá variar com base no repositório. E, embora seja um grande negócio filosoficamente, é realmente bastante avassalador na prática. get alldo OpenRepos e, em seguida, checkinpara o PrivateRepos.
O que pode ser feito para evitar que ela nunca distribua a fonte? Nada. Desculpe.
Vamos usar a GPL (licença pública GNU) como exemplo. A GPL exige que a fonte esteja disponível para qualquer pessoa que receba uma cópia legítima do projeto. Não há disposições que permitam ao detentor da fonte recusar a entrega da fonte a um detentor legítimo de uma cópia do aplicativo da GPL. Isso vai contra o grão do software livre, e é por isso que o copyleft da GPL está em vigor.
Potencialmente, você tem cursos de ação legais a seguir. Mas tudo isso é depois que a fonte escapou e foi bifurcada, não antes. E em algumas jurisdições você não terá nenhum recurso legal. E tudo isso pressupõe que você esteja ciente de que o garfo ocorreu. Você pode nunca descobrir.
Ética
Quais são as responsabilidades (éticas ou sociais) da empresa? (Por exemplo: devolver o projeto de código aberto seria a coisa ética a ser feita)
A ética é local da cultura. Então tempere esta seção com esse grão de sal. Uma discussão completa sobre a consideração cultural da ética está além do escopo desta resposta e fora do tópico para programadores.
Percebi que a comunidade de programação tende a reagir negativamente a uma bifurcação hostil. Heck, em alguns casos, a mesma comunidade ainda reage negativamente a uma discussão amigável e legal. É uma comunidade bastante complexa.
Do ponto de vista do software livre, há uma expectativa de que a New Corp "retribua" a comunidade pela contribuição que recebeu. Os termos, condições e duração desse reembolso são tão variados quanto o número de projetos de OSS existentes. Alguns na comunidade (pense em Richard Stallman) nunca se contentarão com um projeto aberto sendo fechado. Outros procurarão o benefício fornecido à comunidade em geral e julgarão com base nisso. E outros simplesmente não se importam porque nunca souberam ou se importaram com o projeto de origem.
Disponibilidade da fonte
Se a versão de código aberto e a versão de código fechado estão disponíveis, como a concorrência afeta um dos produtos?
Realmente depende de quão comparáveis as duas bases de código são em relação à funcionalidade, desempenho e estabilidade.
Se as bases de código permanecerem semelhantes e a New Corp for amigável para a comunidade OSS, elas poderão contribuir com suas atualizações de volta ao projeto base. Nesse caso, todos se beneficiam. Não é uma "competição" nesse caso, mas mais uma colaboração mutuamente benéfica.
Se as bases de código divergem bastante e a New Corp não é amiga da comunidade OSS, ainda não há uma competição. O produto mais rico em recursos sobrevive e o menos rico tende a morrer. Observe que isso pode ocorrer de qualquer maneira - a versão fechada pode morrer se a versão de código aberto continuar inovando ou melhor atender às necessidades da comunidade.
A realidade estará em algum lugar entre esses dois extremos do espectro.
Exemplo
A Red Hat tem duas distribuições principais - Enterprise Linux e Fedora. EL é sua versão licenciada "fechada" e o Fedora é sua edição comunitária. Devido à GPL, grande parte, se não toda, da edição EL é lançada na forma de fonte. Outro projeto não afiliado à Red Hat, chamado CentOS, pega as alterações no EL e distribui esse projeto após algumas pequenas alterações de marca.
Houve algumas queixas quando a Red Hat entrou em duas edições separadas, mas, em geral, tem sido um acordo bastante viável. A comunidade Fedora queria que os recursos entrassem na distribuição mais rapidamente do que os clientes corporativos da Red Hat se sentiam à vontade. Os aprimoramentos nas bases de código fluem nas duas direções.