Licencias

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 puedes encontrar en kernel.org.

Acuerdos 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 Acuerdo 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 el proyecto; no modifica tus derechos de usar tus propias contribuciones para cualquier otro fin.

También encontrarás disponible un Acuerdo 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 acuerdo permite que una empresa autorice colaboraciones 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 términos simplificados, la LGPL requiere el envío de la fuente a la aplicación, una oferta por escrito para la fuente o vincular la biblioteca con LGPL de forma dinámica y permitir que los usuarios actualicen o reemplacen la biblioteca manualmente. El software de Android se suele enviar como una imagen de sistema estático, 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 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 LGPL les causaron muchos problemas de cumplimiento a fabricantes de dispositivos y desarrolladores de aplicaciones intermedios. 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.