A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página aborda duas importantes tarefas do colaborador: assinar contratos de licença
e garantir o uso correto dos cabeçalhos de licenciamento no seu código.
Assinar 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 no Android Open Source Project (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.
Ele define os termos da propriedade intelectual da contribuição
no AOSP. Essa licença existe 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.
O Contrato de licença de colaboração corporativa
está disponível para empresas (ou outras entidades) que tenham 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 de licença de contribuição do Google são baseados nos contratos usados pela
Apache Software Foundation, que podem
ser encontrados no
site da Apache.
Incluir cabeçalhos de licença
O Android Open Source Project (AOSP) usa algumas
licenças de código aberto aprovadas pela iniciativa de
código aberto (link em inglês) no nosso software.
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. Ainda assim,
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
The Linux Kernel Archives.
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 GNU Lesser General
Public License (LGPL). Confira os motivos:
O Android representa liberdade e escolha. O objetivo do Android é promover
transparência no mundo dos dispositivos móveis, e o Google não pode 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 limitante. 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,
que permite 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 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 são fonte de muitos problemas de
compliance para fabricantes de dispositivos downstream e desenvolvedores de apps. 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 obedecer aos requisitos das licenças com facilidade.
Essas preocupações não são críticas à LGPL ou a outras licenças. O Google é grato
por todas as licenças livres e de código aberto e respeita a preferência por outras.
O Google decidiu que a Apache 2.0 é a melhor opção para nosso objetivo.
Ao enviar o código que vai ser incluído no AOSP, é preciso garantir o uso adequado dos
cabeçalhos de licença. As seções a seguir explicam como processar os
cabeçalhos de licença para novos arquivos e códigos existentes.
Seguir as práticas recomendadas de licença e direitos autorais
Siga estas práticas recomendadas de direitos autorais e cabeçalho de licença:
Não modifique um direito autoral existente. Por exemplo, se você quiser contribuir com um
arquivo para o AOSP que contenha código originado em um arquivo com seu próprio
aviso de direitos autorais, é preciso manter o aviso do arquivo original.
Se você adicionar um arquivo de origem totalmente novo, use o direito autoral padrão do AOSP e o
seguinte cabeçalho de licença, a menos que o projeto para o qual você está contribuindo tenha uma
licença 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.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-04-04 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-04-04 UTC."],[],[],null,["# Contributor license agreements and headers\n\nThis page covers two important contributor tasks: signing contributor license\nagreements and ensuring correct use of licensing headers in your code.\n\nSign contributor license agreements\n-----------------------------------\n\nAll individual contributors (those making contributions only on their own\nbehalf) of ideas, code, or documentation to Android Open Source Project (AOSP)\nare required to complete, sign, and submit an\n[Individual Contributor License Agreement](https://cla.developers.google.com/about/google-individual).\nYou can execute this agreement online through the\n[code review tool](https://android-review.googlesource.com/#/settings/agreements).\nThe agreement defines the terms for contributing intellectual property\nto AOSP. This license is for your protection as a contributor as well as the\nprotection of the project; it doesn't change your rights to use your own\ncontributions for any other purpose.\n\nThe [Corporate Contributor License Agreement](https://cla.developers.google.com/about/google-corporate)\nis available for a corporation (or other entity) with employees working on AOSP.\nThis version of the agreement lets a corporation authorize contributions\nsubmitted by its designated employees and grant copyright and patent\nlicenses.\n| **Note:** A Corporate Contributor License Agreement doesn't remove the need for a developer to sign their own Individual Contributor License Agreement as an individual. The individual agreement is needed to cover any of their contributions that are *not* owned by the corporation signing the Corporate Contributor License Agreement.\n\nGoogle bases their contributor license agreements on those used by the\n[Apache Software Foundation](http://www.apache.org), which can\nbe found on the\n[Apache website](http://www.apache.org/licenses/).\n\nInclude license headers\n-----------------------\n\nThe Android Open Source Project (AOSP) uses a few\n[open source initiative](http://www.opensource.org/) approved open source\nlicenses for our software.\n\n[Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0)\n(Apache 2.0) is the preferred license for AOSP, and the majority of Android\nsoftware is licensed with Apache 2.0. While the project strives to adhere to the\npreferred license, there are exceptions, which are handled on a case-by-case\nbasis. For example, the Linux kernel patches are under the GPLv2 license with\nsystem exceptions, which can be found on\n[The Linux Kernel Archives](http://www.kernel.org/pub/linux/kernel/COPYING).\n\nFor userspace (nonkernel) software, Google prefer Apache 2.0 (and similar\nlicenses such as BSD and MIT) over other licenses such as the GNU Lesser General\nPublic License (LGPL). Here's why:\n\n- Android is about freedom and choice. The purpose of Android is to promote\n openness in the mobile world, and Google can't predict or dictate all of the\n uses for our software. So, while Google encourages everyone to make open and\n modifiable devices, we don't think it's our place to force them to do so. Using\n LGPL libraries could be restrictive. Here are some of our specific concerns:\n\n - In simplified terms, LGPL requires shipping of source to the application; a\n written offer for source; or linking the LGPL-ed library dynamically and\n allowing users to manually upgrade or replace the library. Android software is\n typically shipped as a static system image, so complying with these\n requirements restricts device manufacturer designs. For example, it's\n difficult for a user to replace a library on read-only flash storage.\n\n - LGPL requires the allowance of customer modification and reverse engineering\n for debugging those modifications. Most device makers don't want to be bound\n by these terms.\n\n - Historically, LGPL libraries have been the source of many compliance\n problems for downstream device makers and app developers. Educating\n engineers on these issues is difficult and time consuming. It's critical to\n Android's success that device makers can easily comply with the licenses.\n\nThese concerns aren't criticisms of LGPL or other licenses. Google appreciates\nall free and open source licenses, and respect others' license preferences.\nGoogle has decided that Apache 2.0 is the best fit for our goals.\n\nWhen submitting code to be included in AOSP, you must ensure proper use of\nlicense headers. The following sections explains how to handle\nlicense headers for new files and existing code.\n\n### Follow license and copyright best practices\n\nFollow these best practices for copyright and license header:\n\n- Don't modify an existing copyright. For example, if you want to contribute a\n file to AOSP that contains code that originated in a file with a its own\n copyright notice, you must retain that copyright notice from the original file.\n\n- If you add a wholly new source file, use the default AOSP copyright and the\n following license header, unless the project you're contributing to has a\n different predefined license:\n\n Copyright (C) \u003cvar translate=\"no\"\u003eyyyy\u003c/var\u003e The Android Open Source Project\n Licensed under the Apache License, Version 2.0 (the \"License\");\n you may not use this file except in compliance with the License.\n You may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\n Unless required by applicable law or agreed to in writing, software\n distributed under the License is distributed on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n See the License for the specific language governing permissions and\n limitations under the License.\n\n | **Note:** \u003cvar translate=\"no\"\u003eyyyy\u003c/var\u003e refers to the year that the file is added."]]
