È importante notare che questo scenario può verificarsi sia in forma legale che illegale.
Ciò può verificarsi legalmente se la società possiede o ha accesso al copyright associato al codice. Ad esempio, team di sviluppo più piccoli e indipendenti potrebbero voler vendere o concedere in licenza il proprio copyright a un'azienda più grande. Allo stesso modo, se la maggior parte del copyright del codice può essere acquisita, la parte "irraggiungibile" può essere semplicemente eliminata e riscritta.
Dall'altro lato della medaglia, il codice può essere semplicemente preso illegalmente. New Corp, Inc. potrebbe non interessarsi delle conseguenze legali. Il progetto potrebbe essere troppo vecchio o abbandonato o New Corp pensa che vinceranno in una causa. Oppure New Corp potrebbe essere registrato in un'area in cui questo tipo di "acquisizione" semplicemente non è definito illegale. Non tutte le licenze OSS sono esecutive, soprattutto non quelle che sono state messe insieme da non esperti della legge. Non tutti i proprietari di progetti potrebbero avere la possibilità di far valere i propri diritti di copyright e organizzazioni più grandi come la FSF potrebbero non essere in quella giurisdizione per tale reclamo. TL; DR: quest'area può diventare molto sfocata e brutta molto velocemente.
Transizione e prevenzione
Come avviene la transizione e cosa si può fare per impedirla oltre a scegliere una licenza differenza?
La transizione si verifica quando New Corp, Inc. acquisisce la base di codice e pone tale copia sotto il loro controllo. Gli sviluppatori di New Corp iniziano quindi a lavorare sulla loro versione della base di codice apportando le modifiche che i signori dell'azienda hanno ritenuto necessarie. La meccanica effettiva di questo fork varierà in base al repository. E mentre è un grosso problema filosofico, nella pratica è davvero deludente. get allda OpenRepos e quindi checkina PrivateRepos.
Cosa si può fare per impedire che non distribuisca mai la fonte? Niente. Scusa.
Usiamo GPL (licenza pubblica GNU) come esempio. GPL richiede che la fonte sia disponibile per chiunque riceva una copia legittima del progetto. Non esistono disposizioni che consentano al detentore della fonte di rifiutare la consegna della fonte a un legittimo detentore di una copia della domanda GPL. Va contro il grano del software libero, ed è per questo che il copyleft GPL è a posto.
Potenzialmente, hai azioni legali di fatto da perseguire. Ma quelli sono tutti dopo che la fonte è fuggita ed è stata biforcuta, non prima. E in alcune giurisdizioni non avrai alcun ricorso legale. E tutto ciò presuppone che tu sia persino consapevole che si è verificato il fork. Potresti non scoprirlo mai.
Etica
Quali sono le responsabilità (etiche o sociali) per l'azienda? (Ad esempio: restituire al progetto open source sarebbe la cosa etica da fare)
L'etica è locale per la cultura. Quindi tempera questa sezione con quel granello di sale. Una discussione completa sulla considerazione culturale dell'etica va oltre lo scopo di questa risposta e fuori tema per i programmatori.
Ho notato che la comunità di programmatori tende a reagire negativamente a un fork ostile. Diamine, in alcuni casi la stessa comunità reagisce ancora negativamente a un fork amichevole e legale. È una comunità piuttosto complessa.
Dal punto di vista FOSS, ci si aspetta che New Corp "ripaghi" la comunità per il contributo che ha investito. I termini, le condizioni e la durata di tale rimborso sono diversi quanto il numero di progetti OSS esistenti. Alcuni nella comunità (pensa Richard Stallman) non si accontenteranno mai di un progetto aperto che verrà chiuso. Altri cercheranno il beneficio fornito alla comunità in generale e giudicheranno in base a quello. E altri semplicemente non se ne cureranno perché non hanno mai saputo o curato il progetto di origine.
Disponibilità della fonte
Se la versione open source e quella chiusa sono entrambe disponibili, in che modo la concorrenza influisce su entrambi i prodotti?
Dipende davvero da quanto siano comparabili le due basi di codice per quanto riguarda funzionalità, prestazioni e stabilità.
Se le basi di codice rimangono simili e New Corp è favorevole alla comunità OSS, possono contribuire con i loro aggiornamenti al progetto di base. In questo caso, tutti ne beneficiano. In questo caso non è una "competizione", ma piuttosto una collaborazione reciprocamente vantaggiosa.
Se le basi del codice divergono selvaggiamente e New Corp non è amichevole con la comunità OSS, allora non c'è ancora concorrenza. Più prodotto ricco di funzionalità sopravvive e il prodotto meno ricco tende a morire. Si noti che ciò può andare in entrambi i modi: la versione chiusa potrebbe estinguersi se la versione open source continua a innovare o soddisfare meglio le esigenze della comunità.
La realtà sarà da qualche parte tra quelle due estremità dello spettro.
Esempio
Red Hat ha due distribuzioni principali: Enterprise Linux e Fedora. EL è la loro versione con licenza "chiusa" e Fedora è la loro edizione per la comunità. A causa della GPL, gran parte, se non tutta, dell'edizione EL viene rilasciata in formato sorgente. Un altro progetto non affiliato con Red Hat chiamato CentOS prende le modifiche a EL e lo distribuisce dopo un piccolo rebranding.
Ci sono stati alcuni brontolii quando Red Hat ha passato in due edizioni separate, ma nel complesso, è stato un accordo piuttosto fattibile. La comunità Fedora desiderava che le funzionalità venissero introdotte nella distribuzione più velocemente di quanto i clienti aziendali di Red Hat fossero a loro agio. Miglioramenti al flusso di basi di codice in entrambe le direzioni.