torvalds - Licencia y uso del kernel de Linux
unix (12)
Creo que vas a tener que ser más específico sobre lo que quieres decir con ''OS''. De ninguna manera es un concepto claro. Algunos dirían que el núcleo es todo el sistema operativo. Otros dirían que las utilidades shell y core como ''ls'' son parte del sistema operativo. Otros llegarían a decir que las aplicaciones estándar, como el Bloc de notas, son parte del sistema operativo.
IANAL, pero no creo que haya nada que te impida agrupar el kernel de Linux con una gran cantidad de programas de código cerrado propios. Sin embargo, tenga cuidado de no utilizar ningún código de biblioteca GPL (LGPL está bien).
Yo cuestiono tus motivos.
Me gustaría escribir mi propio sistema operativo y me gustaría saltar temporalmente la complicada tarea de escribir el kernel y volver a utilizarlo más tarde usando el kernel de Linux. Sin embargo, me gustaría proporcionar el sistema operativo como fuente cerrada por ahora. ¿En qué licencia está el kernel de Linux y es posible usarlo para su lanzamiento con un sistema operativo de código cerrado?
Editar: no estoy interesado en cerrar la fuente del kernel de Linux, aún así lo proporcionaría como fuente abierta. Me pregunto si podría usar un sistema operativo de código cerrado con un kernel de código abierto.
Edición adicional: por sistema operativo, me refiero al sistema que se ejecuta en la parte superior del kernel y se utiliza para iniciar otros programas. Ciertamente no quise incluir el kernel en la declaración de fuente cerrada.
Debes mantener la fuente abierta, y cualquier trabajo derivado del código, sin embargo, si usas el Kernel, escribe tu propia pila de aplicaciones además de (casi TODO lo de GNU) entonces no tienes que abrir eso .
La GPL dice que "derivado" funciona ... así que si estás escribiendo código nuevo, en lugar de expandirlo, está bien. De hecho, incluso podría, por ejemplo, usar la cadena de herramientas GNU, el kernel de Linux, y luego tener su propio sistema además de eso (o solo un DE) que es de fuente cerrada.
¡Es cuando modifica / deriva de algo que tiene que mantenerlo abierto!
El kernel de Linux se publica bajo GPLv2 y puede usarlo como parte de un sistema operativo de fuente cerrada, pero debe mantener el kernel y todas las modificaciones liberadas GPLv2.
Editar: Por cierto, es posible que desee utilizar algo como OpenSolaris en su lugar. Es mucho más fácil trabajar con, en mi opinión (obviamente muy subjetivo), y puedes mantener las modificaciones de código cerrado si así lo eliges, siempre y cuando sigas los términos de la CDDL.
En general, diría que se te permite hacer tal cosa, siempre que proporciones la fuente del kernel, pero hay un punto en el que no estoy seguro:
En un sistema Linux normal entre el kernel (GPL) y una aplicación no compatible con GPL, siempre existe la libc GNU, que es LGPL y, por lo tanto, permite trabajos derivados que no son gratuitos. Ahora, si tiene una libc no libre, podría considerarse un trabajo derivado, ya que está llamando directamente al kernel, y también usando encabezados kernel.
Como muchos otros han dicho antes, es mejor que uses un * BSD.
Es GPL. Respuesta corta - no.
Es la versión 2 de GPL y seguramente no puede cerrar su fuente.
Linux tiene el GPL (v2) como su licencia, lo que significa que debe abrir el código fuente de cualquier trabajo derivado.
Es posible que desee utilizar BSD, su licencia es mucho menos restrictiva en lo que puede hacer con los trabajos derivados
Por supuesto, puede escribir cualquier sistema operativo de código cerrado sobre el núcleo de Linux que desee, siempre que sea compatible con la licencia de los componentes con los que se vincula.
Por supuesto, es probable que incluya la biblioteca gnu C (o alguna otra biblioteca C). También es posible que necesite algunas utilidades de línea de comandos que probablemente serán GPL para hacer cosas tales como el mantenimiento del sistema de archivos, la configuración de la red, etc. Pero siempre que las deje como sus propios programas independientes, no debería ser un problema.
Todo lo que se vincule con el kernel mismo (por ejemplo, módulos personalizados, parches) se debe liberar como GPL de código abierto para cumplir con la licencia del kernel.
Siempre puede mantener cualquier extensión (módulo) y / o aplicación que escriba fuente cerrada, pero el kernel en sí deberá permanecer en código abierto.
Hay un aspecto no tan obvio de la GPLv2 que puede explotar mientras prueba el sistema: solo necesita liberar el código fuente para aquellos que tienen acceso al sistema. La GPLv2 establece que debe otorgar acceso completo al código fuente a cualquier persona que tenga acceso a la distribución binaria / compilada del programa. Por lo tanto, si solo va a utilizar el software dentro de la empresa que paga para desarrollarlo, no necesita distribuir el código fuente al resto del mundo, sino solo a ellos.
Si el sistema de archivos que utiliza debe vincularse al kernel mismo, y si planea distribuirlo a otros, la GPL requiere bastante inequívocamente que el sistema de archivos también sea GPL.
Dicho esto: una forma de interactuar legalmente Linux con un sistema de archivos incompatible con GPL es a través de FUSE (sistema de archivos en el espacio de usuario). Esto se ha usado, por ejemplo, para ejecutar el sistema de archivos ZFS incompatible con GPL sobre Linux. Sin embargo, ejecutar un sistema de archivos en el espacio de usuario conlleva una penalización de rendimiento que puede ser significativa.
Si eres serio en el desarrollo de un nuevo sistema operativo y quieres un núcleo funcional para empezar, te sugiero que busques en el kernel de FreeBSD. Tiene una licencia mucho más relajada que Linux, creo que puede que valga la pena.
Solo mis 2 centavos ...
Estoy de acuerdo con MarkR pero nadie ha declarado lo obvio para ti. Si habla en serio, debe consultar a un abogado con experiencia en esta área.