El Proyecto de Código Abierto de Android (AOSP) utiliza algunas licencias aprobadas por iniciativas de código abierto para nuestro software.
Licencia del AOSP
La Licencia de Apache Versión 2.0 (Apache 2.0) es la preferida para el AOSP, y la mayor parte del software de Android cuenta con ella. Si bien nos esforzamos para que el proyecto se adhiera a la licencia preferida, hay excepciones que se resuelven según cada caso. Por ejemplo, los parches del kernel de Linux cuentan con la licencia GPLv2, con excepciones de sistema, que usted puede encontrar en kernel.org.
Contratos de Licencia de Colaboradores
Todos los colaboradores individuales (quienes realizan contribuciones solo en su nombre) que aporten ideas, código o documentación al AOSP deben completar, firmar y enviar un Contrato de Licencia para Colaboradores Individuales. El acuerdo se puede realizar en línea a través de la herramienta de revisión de código. Allí se definen de forma clara las condiciones que se deben cumplir para contribuir con propiedad intelectual al AOSP. El propósito de la licencia es proteger a los colaboradores y al proyecto; esta licencia no modifica su derecho de usar sus propias contribuciones para cualquier otro fin.
También encontrará disponible un Contrato de Licencia para Colaboradores Corporativos dirigido a empresas (o a otras entidades) que cuentan con empleados que trabajan en el AOSP. Esa versión del contrato permite que una empresa autorice contribuciones de sus empleados designados y otorgue licencias de derechos de autor y patentes.
Basamos nuestros acuerdos en los que usa la Apache Software Foundation, que se encuentran en el sitio web de Apache.
¿Por qué elegimos la Licencia del Software Apache?
Para el software del espacio del usuario (sin kernel), preferimos usar Apache 2.0 (y licencias similares como BSD y MIT) en lugar de otras licencias como la Licencia Pública General Reducida (LGPL). A continuación, detallamos los motivos.
Android se basa en tener libertad y opciones entre las cuales elegir. Dado que el objetivo de Android es promover la apertura en el mundo de los dispositivos móviles, no podemos predecir ni dictar todos los usos de nuestro software. Si bien recomendamos crear dispositivos abiertos y modificables, no pretendemos obligar a todos a que lo hagan. Las bibliotecas de LGPL podrían restringir esa libertad. Estas son algunas de nuestras preocupaciones específicas:
- En simples palabras, la LGPL requiere que se envíe la fuente a la aplicación, que se proporcione una oferta por escrito para la fuente o que se vincule la biblioteca con la LGPL de forma dinámica y se permita que los usuarios actualicen o reemplacen la biblioteca manualmente. El software de Android se suele enviar como una imagen de sistema estática, por lo que el cumplimiento de esos requisitos restringe los diseños de fabricantes de dispositivos. Por ejemplo, a los usuarios les resulta difícil reemplazar una biblioteca en un almacenamiento de escritura en la memoria flash de solo lectura.
- Un requisito de la LGPL es permitir que el cliente haga modificaciones y habilitar el uso de ingeniería inversa para depurar esas modificaciones. La mayoría de los fabricantes de dispositivos no quieren estar sujetos a estas condiciones.
- Históricamente, las bibliotecas de la LGPL les causaron muchos problemas de cumplimiento a fabricantes de dispositivos y desarrolladores de aplicaciones en fases posteriores. Además, resulta difícil brindar capacitaciones para los ingenieros sobre estos problemas y requiere mucho tiempo. A fin de garantizar el éxito de Android, es fundamental que los fabricantes de dispositivos puedan cumplir fácilmente con las licencias.
Los problemas que se mencionan más arriba engloban los motivos por los que preferimos usar Apache 2.0 para nuestro código. Nuestra intención no es criticar la LGPL ni otras licencias. Apreciamos todas las licencias gratuitas y de código abierto, y respetamos las preferencias que tienen otras organizaciones. Simplemente concluimos que Apache 2.0 se adecúa mejor a nuestros objetivos.