Domanda

Vorrei scrivere il mio sistema operativo e vorrei saltare temporaneamente il complicato compito di scrivere il kernel e tornarci in seguito usando nel frattempo il kernel Linux. Tuttavia, per ora vorrei fornire il sistema operativo come sorgente chiusa. Quale licenza è sotto il kernel Linux ed è possibile usarlo per il rilascio con un sistema operativo chiuso?

Modifica: non mi interessa chiudere il sorgente del kernel Linux, lo fornirei comunque come open source. Mi chiedo se potrei usare un SO chiuso con un kernel open source.

Ulteriore modifica: per sistema operativo intendo il sistema che gira in cima al kernel e viene usato per avviare altri programmi. Non intendevo certamente includere il kernel nell'istruzione closed source.

È stato utile?

Soluzione

Puoi ovviamente scrivere qualsiasi sistema operativo open source sul kernel Linux che ti piace a condizione che tu sia compatibile con la licenza dei componenti a cui ti colleghi.

Naturalmente è probabile che includa la libreria C gnu (o qualche altra libreria C). Potresti anche aver bisogno di alcune utility da riga di comando che probabilmente saranno GPL per fare cose come la manutenzione del filesystem, la configurazione della rete ecc. Ma purché tu li lasci come programmi autonomi, non dovrebbe essere un problema.

Tutto ciò che si collega al kernel stesso (ad es. moduli personalizzati, patch) dovrebbe essere rilasciato come GPL open source per rispettare la licenza del kernel.

Altri suggerimenti

Il kernel Linux è rilasciato sotto GPLv2 e puoi usarlo come parte di un sistema operativo a sorgente chiuso ma devi mantenere il kernel e tutte le modifiche rilasciate GPLv2.

Modifica: tra l'altro, potresti voler usare qualcosa come OpenSolaris. È molto più facile lavorare con me, a mio avviso (ovviamente molto soggettivo), e puoi tenere le modifiche chiuse se lo desideri, purché segua i termini del CDDL.

Penso che dovrai essere più specifico su cosa intendi per "OS". Non è affatto un concetto chiaro. Alcuni direbbero che il kernel è tutto il sistema operativo. Altri direbbero che la shell e le utility di base come 'ls' fanno parte del sistema operativo. Altri direbbero che le applicazioni standard come Blocco note fanno parte del sistema operativo.

IANAL, ma non credo che ci sia nulla che ti impedisca di raggruppare il kernel Linux con un carico di programmi a sorgente chiuso. Fare attenzione a non utilizzare alcun codice della libreria GPL (LGPL è OK).

Metto in dubbio le tue motivazioni.

Linux ha la licenza GPL (v2) come licenza, il che significa che è necessario open source qualsiasi opera derivata.

Potresti voler usare BSD, la sua licenza è molto restrittiva in ciò che puoi fare con le opere derivate

Devi tenere aperto il sorgente e qualsiasi lavoro derivato dal codice, tuttavia, se usi il Kernel, scrivi il tuo stack di applicazioni sopra quello (praticamente TUTTE le cose GNU), quindi non devi aprilo.

La GPL afferma che "derivato" funziona ... quindi se stai scrivendo un nuovo codice, invece di expanind su, allora va bene. In effetti, potresti persino, ad esempio, usare la toolchain GNU, il kernel Linux, e quindi avere il tuo sistema sopra (o solo un DE) che è un codice chiuso.

È quando si modifica / deriva da qualcosa che è necessario tenerlo aperto!

È GPL versione 2 e potresti certamente non chiuderne l'origine.

Se il filesystem che usi deve essere collegato al kernel stesso, e se prevedi di distribuirlo ad altri, la GPL richiede inequivocabilmente che anche il filesystem sia GPL.

Detto questo: un modo per interfacciare legalmente Linux con un filesystem incompatibile con GPL è tramite FUSE (filesystem nello spazio utente). Questo è stato usato, ad esempio, per eseguire il file system ZFS incompatibile con GPL su Linux . L'esecuzione di un filesystem nello spazio utente comporta tuttavia una riduzione delle prestazioni che può essere significativa.

Puoi sempre mantenere qualsiasi estensione (modulo) e / o applicazione che scrivi in ??codice chiuso, ma il kernel stesso dovrà rimanere open source.

C'è un aspetto non così ovvio di GPLv2 che puoi sfruttare durante il test del sistema: devi solo rilasciare il codice sorgente a coloro che hanno accesso al sistema. GPLv2 afferma che è necessario fornire pieno accesso al codice sorgente a chiunque abbia accesso alla distribuzione binaria / compilata del programma. Quindi, se hai intenzione di utilizzare solo il software all'interno dell'azienda che sta pagando per svilupparlo, non è necessario distribuire il codice sorgente nel resto del mondo, ma solo loro.

Generalmente direi che ti è permesso fare una cosa del genere, purché tu fornisca il sorgente per il kernel, ma c'è un punto in cui non sono sicuro:

Su un normale sistema Linux tra il kernel (GPL) e un'applicazione non GPL compatibile, c'è sempre la GNU libc, che è LGPL e consente quindi lavori derivati ??non liberi. Ora, se hai una libc non libera, potrebbe essere considerata un'opera derivata, dal momento che stai chiamando direttamente il kernel e anche usando le intestazioni del kernel.

Come molti altri hanno già detto, potresti stare meglio usando un * BSD.

Se sei serio nello sviluppo di un nuovo sistema operativo e vuoi che inizi un kernel funzionante, ti suggerisco di esaminare il kernel di FreeBSD. Ha una licenza molto più rilassata rispetto a Linux, penso che potresti trovarla utile.

Solo i miei 2 centesimi ...

Sono d'accordo con MarkR ma nessuno ti ha dichiarato ovvio. Se sei serio, devi consultare un avvocato con esperienza in questo settore.

È GPL. Risposta breve - no.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top