En esta página, se tratan dos importantes tareas de los colaboradores: firmar contratos de licencia para colaboradores y garantizar el uso correcto de los encabezados de licencia en tu código.
Firma los contratos de licencia para colaboradores
Todos los colaboradores individuales (quienes realizan contribuciones solo en su nombre) que aporten ideas, código o documentación al Proyecto de código abierto de Android (AOSP) deben completar, firmar y enviar un Contrato de Licencia para Colaboradores Individuales. Puedes firmar este contrato en línea a través de la herramienta de revisión de código. En dicho contrato, se definen 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 los derechos relacionados con el uso de contribuciones propias para cualquier otro fin.
También hay disponible el Contrato de Licencia para Colaboradores Corporativos dirigido a empresas (o a otras entidades) cuyos empleados 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.
Google basa sus contratos de licencia para colaboradores en los que usa la Apache Software Foundation, que se encuentran en el sitio web de Apache.
Incluye los encabezados de licencia
El Proyecto de código abierto de Android (AOSP) utiliza algunas licencias de código abierto aprobadas por iniciativas de código abierto para nuestro software.
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 cumpla con 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 puede encontrar en Linux Kernel Archives.
Para el software del espacio del usuario (sin kernel), Google prefiere usar Apache 2.0 (y licencias similares, como BSD y MIT) en lugar de otras licencias, como la Licencia Pública General Reducida (LGPL) de GNU. Estos son 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, Google no puede predecir ni dictar todos los usos de nuestro software. Si bien Google recomienda crear dispositivos abiertos y modificables, no pretendemos obligar a todos a que lo hagan. Las bibliotecas de la 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 de 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 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 apps en fases posteriores. Además, brindar capacitaciones para los ingenieros sobre estos problemas resulta difícil y requiere mucho tiempo. Para garantizar el éxito de Android, es fundamental que los fabricantes de dispositivos puedan cumplir fácilmente con las licencias.
Estas preocupaciones no son una crítica a la LGPL ni a otras licencias. Google aprecia todas las licencias gratuitas y de código abierto, y respeta las preferencias que tienen otras organizaciones. Google ha decidido que Apache 2.0 es la mejor opción para nuestros objetivos.
Cuando envíes el código para ser incluido en el AOSP, debes asegurarte del uso correcto de los encabezados de licencia. En las siguientes secciones, se explica cómo manejar los encabezados de licencia para archivos nuevos y código existente.
Sigue las prácticas recomendadas para las licencias y los derechos de autor
Sigue estas prácticas recomendadas para los encabezados de licencia y los derechos de autor:
No modifiques derechos de autor existentes. Por ejemplo, si quieres contribuir con un archivo al AOSP que incluye código que se originó en un archivo con su propio aviso sobre derechos de autor, debe conservar ese aviso del archivo original.
Si agregas un archivo fuente completamente nuevo, utiliza los derechos de autor predeterminados del AOSP y el encabezado de licencia que aparece más abajo, a menos que el proyecto al que está contribuyendo tenga una licencia predefinida diferente:
Copyright (C) yyyy The Android Open Source Project Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.