O Android Open Source Project (AOSP) usa algumas licenças de código aberto aprovadas pela iniciativa de código aberto para nosso software.
Licença AOSP
A Licença Apache Versão 2.0 (Apache 2.0) é a licença preferencial para o AOSP. Além disso, a maior parte dos softwares Android é licenciada com a Apache 2.0. O projeto tenta usar essa licença, mas há exceções que são tratadas individualmente. Por exemplo, os patches do kernel do Linux são administrados pela licença GPLv2 com exceções do sistema, que podem ser encontradas em kernel.org.
Contratos de licença de colaborador
Todos os colaboradores individuais (que fazem contribuições apenas no próprio nome) de ideias, códigos ou documentação para o AOSP precisam preencher, assinar e enviar um Contrato de Licença de Colaborador Individual. Esse contrato pode ser firmado on-line na ferramenta de revisão de código. O contrato define claramente os termos de contribuição da propriedade intelectual para o AOSP. Essa licença é para sua proteção como colaborador, bem como para a proteção do projeto. Ela não muda seus direitos de usar suas contribuições para qualquer outra finalidade.
Um Contrato de Licença de Colaboração Corporativa está disponível para empresas (ou outras entidades) que têm funcionários trabalhando no AOSP. Essa versão do contrato permite que a empresa autorize contribuições enviadas por funcionários designados e conceda licenças de patente e direitos autorais.
Os contratos da Apache Software Foundation, que podem ser encontrados no site da Apache, serviram como base para nossos contratos.
Por que usar a Licença de Software Apache?
Para o software de espaço do usuário (não kernel), é preferível usar a Apache 2.0 (e licenças semelhantes, como BSD e MIT) em vez de outras licenças, como a Lesser General Public License (LGPL). Veja por quê.
O Android representa liberdade e escolha. O objetivo do Android é promover a abertura no mundo dos dispositivos móveis, e não podemos prever ou ditar todos os usos do nosso software. Encorajamos a criação de dispositivos abertos e modificáveis, mas não acreditamos que seja nosso papel impor isso. O uso de bibliotecas LGPL pode ser restritivo. Estas são algumas das nossas preocupações específicas:
- Em termos simplificados, a LGPL requer o envio da origem para o aplicativo, uma oferta por escrito para a origem ou a vinculação dinâmica da biblioteca LGPL, bem como permitir que os usuários façam upgrade ou substituam a biblioteca manualmente. Como o software Android geralmente é enviado na forma de uma imagem estática do sistema, cumprir esses requisitos restringe os designs dos fabricantes de dispositivos. Por exemplo, é difícil para um usuário substituir uma biblioteca em um armazenamento flash somente de leitura.
- A LGPL requer permissão de modificação do cliente e engenharia reversa para depurar essas modificações. A maioria dos fabricantes de dispositivos não quer se submeter a esses termos.
- Historicamente, as bibliotecas LGPL têm sido a fonte de muitos problemas de compliance para fabricantes de dispositivos downstream e desenvolvedores de aplicativos. Preparar e capacitar engenheiros para resolver essas questões é difícil e leva tempo. É fundamental para o sucesso do Android que os fabricantes de dispositivos possam cumprir as licenças com facilidade.
As questões discutidas acima são nossos motivos para recomendar o uso da Apache 2.0 com nosso código. Elas não são críticas à LGPL ou a outras licenças. Gostamos de todas as licenças gratuitas e de código aberto e respeitamos a preferência por outras. Apenas concluímos que a Apache 2.0 é a licença ideal para nossos objetivos.