Casi cualquier software a medida usa librerías de código abierto, y eso no es un problema si se respetan sus licencias. Las licencias permisivas, como MIT o Apache 2.0, piden sobre todo conservar los avisos de autoría. Las de tipo GPL obligan, si distribuyes el programa, a transmitir las mismas libertades que recibiste. Pide a tu proveedor la lista de componentes y sus licencias.
Por qué tu software usa código abierto.
Nadie programa hoy todo desde cero. Para gestionar fechas, enviar correos o leer un PDF se usan librerías ya escritas y probadas por miles de personas.
Muchas de esas librerías son de código abierto. Su código es público y se puede usar gratis, pero con condiciones. Esas condiciones son la licencia.
Usar código abierto es una buena práctica, no un atajo. Lo importante es saber qué piezas lleva tu programa y qué piden sus licencias.
Licencias permisivas.
Las licencias permisivas dejan usar, modificar e incluir el código en un programa propio con pocas condiciones.
La licencia MIT es el ejemplo más conocido. Su condición principal es incluir el aviso de copyright y el de permiso en todas las copias o partes sustanciales del software.
La licencia Apache 2.0 añade una cláusula de patentes. Cada contribuidor concede una licencia sobre sus patentes, que pierde quien inicie un litigio alegando que la obra infringe una patente. Para una empresa, es una protección más.
Licencias de tipo GPL.
La GNU GPL tiene otra filosofía. Busca garantizar la libertad de compartir y modificar todas las versiones de un programa.
Por eso pone una condición fuerte. Si distribuyes copias de un programa con esta licencia, debes transmitir a quien las recibe las mismas libertades que recibiste. En la práctica, eso puede obligar a entregar el código fuente, con la misma licencia, a quien reciba el programa.
No significa que una librería GPL esté prohibida. Significa que hay que entender bien cómo se usa y si el programa se va a distribuir.
Cuándo importa la distribución.
La palabra clave en muchas licencias es distribuir. No es lo mismo un programa que solo usa tu empresa en su servidor que una app que descargan tus clientes.
Una app publicada en las tiendas se distribuye a cada persona que la instala. En un programa que se usa desde el navegador, la parte que se ejecuta en tu servidor no se entrega a nadie. En cambio, el código que se descarga al navegador, como el JavaScript, sí llega a cada usuario. Por eso las mismas librerías pueden tener consecuencias distintas.
Hay licencias que también cubren el uso a través de la red. La GNU AGPL obliga a ofrecer el código de una versión modificada a quienes la usan a distancia. Si tu proyecto es un servicio en línea, pide que el proveedor lo revise expresamente.
Qué pedir a tu proveedor.
Antes de aceptar el proyecto, pide estas tres cosas:
- La lista de componentes de terceros y la licencia de cada uno.
- Una explicación de si alguna licencia obliga a publicar código o a algo más.
- El compromiso de avisarte antes de añadir un componente con una licencia distinta.
Guarda esa lista con la documentación del proyecto. Si un día cambias de proveedor o vendes la empresa, te la pedirán.
Revísala también en cada versión importante. Las librerías se actualizan, y alguna puede cambiar de licencia entre una versión y otra.
Lo que es tuyo y lo que no.
El código que el proveedor escribe para ti puede ser tuyo si te cede los derechos. Esa cesión debe hacerse por escrito. Las librerías de terceros, en cambio, siguen siendo de sus autores. Tú las usas según su licencia.
Con un programa estándar pasa algo parecido. La ley presume que la cesión del derecho de uso es no exclusiva e intransferible, salvo prueba en contrario. Lo explicamos en de quién es el código fuente y en qué debe incluir un contrato de desarrollo de software.
Cómo lo hacemos nosotros.
Usamos librerías de código abierto como cualquier equipo de desarrollo. Pide siempre a tu proveedor la lista de componentes y sus licencias. El código que escribimos queda a nombre del cliente en la mayoría de nuestros proyectos, según contrato.
La trayectoria del fundador empieza en 2013 y suma más de 100 proyectos, además de más de 50 proyectos propios publicados. Puedes ver cómo trabajamos en desarrollo de software a medida. Si estás preparando el encargo, mira cómo preparar el encargo de un software.
Preguntas frecuentes.
No, si se respetan las licencias. Lo arriesgado es no saber qué piezas lleva ni qué piden.
Depende de las licencias. Con las permisivas suele ser posible conservando los avisos. Con las de tipo GPL hay que revisarlo con cuidado.
El proveedor debe conocerlas y explicártelas. Para un caso dudoso, consulta con un abogado.
Solo si alguna licencia de sus componentes lo exige. Con la GPL, al distribuir la app hay que entregar el código fuente a quien la reciba. Por eso conviene conocer la lista desde el principio.
