Licencias
La GPL: paradojas en el software libre
La GPL nació para proteger la libertad del software, pero sus cláusulas recíprocas pueden frenar la colaboración y generar fricciones con los modelos permisivos.
La Licencia Pública General de GNU (GPL) utiliza los derechos de autor para garantizar la libertad de ejecutar, estudiar, compartir y modificar el software cubierto. Sus condiciones recíprocas son deliberadas: quien distribuye una obra cubierta debe conservar esas libertades para sus destinatarios. Este artículo cuestiona el coste de integración de ese mecanismo sin tergiversar su alcance.
Un diseño con restricciones Contradictorias
La GPL impide que un distribuidor tome una obra cubierta, distribuya una versión modificada o combinada y oculte el código fuente correspondiente bajo términos incompatibles. Ejecutar software GPL o instalar programas independientes en un mismo sistema no produce ese efecto. La obligación se vincula a las obras derivadas o combinadas cubiertas y a su distribución; por eso importa delimitar cada caso.
El enlace estático frente al dinámico no constituye una vía general
de escape. Las preguntas
frecuentes de GNU sobre la GPL consideran que ambas formas crean
una combinación cuando se enlaza código GPL con otros módulos. Linux
añade reglas propias: los módulos propietarios marcan el núcleo como
contaminado y el cargador les impide enlazar con símbolos
EXPORT_SYMBOL_GPL(), según documentan las reglas
de licencias del núcleo. El derecho de autor sigue determinando si
un componente concreto es derivado, por lo que el artículo no reduce
esa cuestión jurídica a un método técnico de enlace.
La dicotomía entre filosofía y Práctica
La GPL vincula la libertad a una reciprocidad exigible. Así protege a los destinatarios posteriores, pero también impide algunas combinaciones con código cuyos términos no pueden cumplirse junto con la versión de la GPL aplicable. El código BSD y MIT suele poder incorporarse a una obra combinada bajo GPL; la distribución inversa no puede eliminar las obligaciones que ya cubren el código GPL.
El desacuerdo reside, por tanto, en qué libertad debe priorizar la licencia. El copyleft protege el acceso de cada destinatario al código fuente y su derecho a modificarlo. Una licencia permisiva concede a cada destinatario más autoridad para distribuir derivados con términos propietarios. Ninguno de los dos modelos carece de restricciones: imponen obligaciones distintas al distribuidor.
El impacto en la colaboración y el Desarrollo Empresarial
La GPL no prohíbe el uso comercial, la modificación privada ni la venta de copias. La restricción empresarial aparece cuando una compañía distribuye una obra cubierta y debe proporcionar el código fuente correspondiente bajo la licencia. Las empresas que necesitan derivados propietarios prefieren por ello términos permisivos o negocian otra licencia con los titulares de los derechos.
LLVM muestra con claridad la alternativa. Su licencia Apache 2.0 con excepciones de LLVM permite derivados propietarios a la vez que conserva avisos y una concesión de patentes. Esa política ha sostenido la colaboración entre proveedores y comunidad sin imponer la publicación recíproca del código. Demuestra que una licencia permisiva puede sostener una infraestructura compartida de primer nivel; no demuestra que cualquier proyecto recibiría las mismas contribuciones sin copyleft.
Hacia una ética de compartir sin Coacciones
Mi crítica favorece la reciprocidad voluntaria frente a la obligatoria. Una licencia permisiva admite la cooperación entre sistemas abiertos y propietarios y deja que cada autor posterior elija la licencia de su código nuevo. El coste es igual de concreto: un destinatario puede mejorar el programa, distribuir el resultado y ocultar esas mejoras al público. El copyleft impide ese resultado.
La elección debe seguir la garantía buscada. Conviene elegir la GPL cuando todo derivado distribuido deba conservar el acceso al código; una licencia permisiva encaja cuando tienen prioridad la integración amplia y la libertad de licencia posterior. La gobernanza clara, la revisión y la relación con quienes contribuyen importan en ambos modelos.
Conclusiones
La GPL protege con eficacia la reciprocidad cuando se distribuyen obras cubiertas, y ese es su logro central. El mismo mecanismo excluye integraciones cuyos términos no pueden coexistir con esas obligaciones. Prefiero las licencias permisivas cuando la colaboración a través de esas fronteras importa más que obligar a publicar el código posterior. Esta conclusión responde a una elección entre garantías jurídicas explícitas, no a la afirmación falsa de que la GPL prohíbe la actividad empresarial o todo software propietario.