Los desarrolladores de software propietario se muestran a veces recelosos de las plataformas Linux integradas, debido a las implicaciones de las licencias de código abierto como la GPL (la licencia pública de GNU) para sus aplicaciones. Les preocupa que la ejecución en Linux pueda exponerles a las obligaciones de las licencias de código abierto de otros componentes de software en el sistema, de manera que se les pueda exigir (mediante litigio) que compartan su código fuente con competidores, clientes o el público en general.
Sin pretender ofrecer asesoramiento jurídico, este artículo presenta algunos consejos y sugerencias prácticas para quienes estén pensando en desplegar una aplicación propietaria en una plataforma de código abierto, basándose en la experiencia típica de muchos de nuestros clientes que utilizan plataformas comunes como Digi Embedded Yocto, Linaro, Android y otras.
Android como alternativa de código abierto
Es cierto que la forma más segura y fiable de evitar la exposición a la GPL es no utilizar GNU/Linux en absoluto: El sistema operativo Android de Google ofrece una alternativa de código abierto para dispositivos integrados que se diseñó deliberadamente desde el principio para eliminar el software con licencia GPL de su entorno de espacio de usuario, en favor de componentes con licencias más permisivas (como las licencias Apache o BSD) que no requieren que los desarrolladores de obras derivadas compartan sus fuentes.
Las versiones modernas de Android no contienen prácticamente ningún componente GPL (aparte del propio núcleo de Linux, que no impone restricciones a las aplicaciones). Hay distribuciones disponibles para el hardware común (incluidos los SOM ConnectCore® de Digi), y Android se ha portado con éxito a muchas placas integradas personalizadas.
Por otro lado, Android ha sido tradicionalmente menos adecuado para los sistemas sin cabeza, y hasta cierto punto es un sistema operativo mantenido por y para los vendedores de teléfonos móviles y las compañías de telefonía celular. Aunque hoy en día hay mucho talento para crear aplicaciones en los teléfonos, los desarrolladores con experiencia en BSP (paquetes de soporte para placas) que utilizan Android embebido son algo menos comunes en la comunidad.
Consideraciones sobre la GPL en GNU/Linux embebido
Los sistemas Linux embebidos siguen disfrutando de una gran diversidad de soporte de hardware y de una gran comunidad de desarrolladores que trabajan en todos los niveles de la pila de software. Para quienes no se oponen a los sistemas con software GPL, puede ser una opción de plataforma excelente y fiable. Al menos, según nuestra experiencia, la inmensa mayoría de los desarrolladores de software de aplicación no tienen problemas legales con sus clientes, competidores o el público en general.
No obstante, los desarrolladores de aplicaciones en Linux embebido deben tener en cuenta algunos conceptos básicos y reglas generales. Abarcaremos lo siguiente:
- Fundamentos de la GPL
- Aplicación vs. Controladores
- Bibliotecas de código abierto
- Enlace estático frente a enlace dinámico
- Comunicación entre procesos
- Biblioteca C estándar
- Python y otros lenguajes de programación
Fundamentos de la GPL
El software con licencia GPL es de código abierto: el código fuente debe compartirse con cualquier persona a la que se distribuya el software. Pero el concepto fundamental y más distintivo de la GPL (tanto de la GPLv2 como de la GPLv3) es la autopropagación: la licencia GPL se aplica a cualquier obra derivada, es decir, a otros programas informáticos como las aplicaciones que incorporan el software GPL, por ejemplo enlazando con bibliotecas GPL. Para resumirlo, si su aplicación se enlaza con software GPL o lo incorpora de cualquier otro modo, puede estar obligado a compartir sus fuentes.
Aplicación vs. Controladores
En un sistema Linux, los controladores en general son componentes que se compilan con el núcleo de Linux, y están necesariamente sujetos a la GPL. Si escribe un controlador para Linux, es posible que tenga que compartir sus fuentes, al igual que hacen los principales proveedores de silicio (NXP, TI, Intel, etc.). Hay algunos vendedores que distribuyen módulos del kernel en forma binaria (principalmente para dispositivos criptográficos y otro hardware muy sensible), pero la situación legal de estos controladores no libres no está resuelta.
En cualquier caso, la mayoría de los dispositivos periféricos no tienen problemas serios de IP en el nivel de la interfaz del bus donde opera el software del controlador. Cuando los dispositivos de hardware sí contienen IP valiosa, a menudo se gestiona en el firmware dentro del dispositivo y no se expone a los controladores a través de una interfaz de bus. Una aplicación, por otro lado, opera en el nivel de espacio de usuario: puede comunicarse con el núcleo de Linux (a través de llamadas al sistema a través de bibliotecas), pero es ampliamente aceptado que las aplicaciones no tienen ninguna dependencia de licencia con el núcleo de Linux.
Bibliotecas de código abierto
Las aplicaciones C/C++ generalmente deben enlazarse con bibliotecas disponibles públicamente para acceder a las facilidades del sistema y evitar reinventar la rueda. (Por ejemplo, un programa en C que utilice Bluetooth puede necesitar enlazar libbluetooth, que forma parte de la pila BlueZ y tiene licencia GPL). Dado que muchas bibliotecas del sistema en GNU/Linux tienen licencia GPL, la aplicación puede asumir obligaciones GPL al enlazar con ellas.
Enlace estático frente a enlace dinámico
Existe la creencia generalizada de que enlazar dinámicamente (en lugar de estáticamente) protege a la aplicación de la herencia de la GPL, pero en realidad se trata de una cuestión controvertida que no se ha resuelto del todo en los tribunales. La FSF (Free Software Foundation, asociada a GNU) sostiene que la GPL sí se extiende al código enlazado dinámicamente: https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic.
Comunicación entre procesos
Por otro lado, las aplicaciones C/C++ no necesitan enlazar con todas las bibliotecas del sistema. Muchas aplicaciones se desenvuelven bien sin libbluetooth u otras bibliotecas con licencia GPL. No se confiere ninguna obligación GPL a la aplicación si no incorpora software con licencia GPL, incluso cuando opera en un entorno GNU. Si una aplicación realiza comunicaciones entre procesos con componentes GPL (como el uso de DBus para comunicarse con systemd u otros procesos daemon), se acepta generalmente que esto no confiere ninguna obligación GPL a la aplicación.
Biblioteca C estándar
La única biblioteca con la que prácticamente cualquier aplicación C necesita enlazar es la biblioteca C estándar: la implementación más común en Linux es glibc de GNU. Aunque existen opciones alternativas de bibliotecas C para sistemas Linux embebidos que tienen licencias permisivas (como uclibc o musl), no hay necesidad real de que los desarrolladores de aplicaciones propietarias eviten la biblioteca C de GNU a causa de la licencia: porque no es GPL.
La biblioteca C de GNU tiene en realidad una licencia LGPL: la principal distinción práctica entre las dos es que la LGPL ("Limited GPL") permite explícitamente el enlazado dinámico: si su aplicación enlaza glibc dinámicamente (no estáticamente), no tiene la obligación de compartir sus fuentes.
Python y otros lenguajes de programación
¿Qué ocurre con otros lenguajes? Si su código no está escrito en C, ¿puede eludir la GPL porque no está enlazando con bibliotecas GPL? Por ejemplo, el intérprete de Python tiene su propia licencia permisiva de código abierto. No impone ningún requisito de compartir las fuentes. Pero la licencia de Python también es compatible con la GPL. Si escribe y distribuye un script de Python e importa sólo bibliotecas de Python no GPL, puede evitar las obligaciones de la GPL. Por otra parte, algunas bibliotecas de Python tienen licencia GPL. (Por ejemplo, si dependen de bibliotecas GNU C subyacentes, de modo que la GPL se propaga a la biblioteca Python). Resulta que el caso de una aplicación Python es muy similar al de C/C++.
Para llevar
Las aplicaciones propietarias de código cerrado pueden coexistir con componentes de software GPL en un sistema GNU/Linux. Dado que el estatus legal de la vinculación dinámica bajo la GPL sigue siendo objeto de disputa, una forma segura de evitar asumir accidentalmente las obligaciones de la GPL es asegurarse de que su aplicación no se vincule con ningún software GPL ni lo "incorpore" directamente. Esto puede significar la búsqueda de alternativas para ciertas bibliotecas C o Python. Pero la propia biblioteca C estándar de GNU no está entre ellas, ya que sólo tiene una licencia LGPL. Hay muchos otros componentes con licencia GPL que se ejecutan en un sistema Linux, pero es generalmente aceptado que éstos no propagan su licencia a una aplicación cuyo código no se deriva de ellos.
Nuestro equipo puede proporcionar orientación sobre el diseño, servicios completos de diseño de hardware y desarrollo de aplicaciones, apoyo a la certificación y mucho más. Póngase en contacto con nosotros para iniciar la conversación.