A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Contratti di licenza dei collaboratori e intestazioni
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina illustra due importanti attività dei collaboratori: la firma dei contratti di licenza dei collaboratori e l'utilizzo corretto delle intestazioni di licenza nel codice.
Firmare i contratti di licenza dei collaboratori
Tutti i singoli collaboratori (ovvero coloro che forniscono contributi solo per conto proprio) di idee, codice o documentazione al progetto Android Open Source (AOSP) devono compilare, firmare e inviare un contratto di licenza per i singoli collaboratori.
Puoi stipulare questo contratto online tramite lo
strumento di revisione del codice.
Il contratto definisce i termini per la donazione di proprietà intellettuale
all'AOSP. Questa licenza è a tua tutela in qualità di collaboratore e a tutela del progetto. Non modifica i tuoi diritti di utilizzo dei tuoi contributi per altri scopi.
Il Corporate Contributor License Agreement è disponibile per una società (o un'altra persona giuridica) con dipendenti che lavorano su AOSP.
Questa versione del contratto consente a una società di autorizzare i contributi inviati dai propri dipendenti designati e di concedere licenze per copyright e brevetti.
Android Open Source Project (AOSP) utilizza alcune
iniziative open source approvate per il nostro software.
La Licenza Apache, versione 2.0 (Apache 2.0) è la licenza preferita per AOSP e la maggior parte del software Android è concessa in licenza con Apache 2.0. Sebbene il progetto si impegni a rispettare la licenza preferita, esistono delle eccezioni, che vengono gestite caso per caso. Ad esempio, i patch del kernel Linux sono coperti dalla licenza GPLv2 con alcune eccezioni per il sistema, che puoi trovare negli archivi del kernel Linux.
Per il software nello spazio utente (non del kernel), Google preferisce Apache 2.0 (e licenze simili come BSD e MIT) ad altre licenze come la GNU Lesser General Public License (LGPL). Di seguito le ragioni:
Android è sinonimo di libertà e scelta. Lo scopo di Android è promuovere l'apertura nel mondo mobile e Google non può prevedere o dettare tutti gli utilizzi del nostro software. Pertanto, anche se Google incoraggia tutti a creare dispositivi aperti e modificabili, non riteniamo di avere il diritto di obbligarli a farlo. L'utilizzo di librerie LGPL potrebbe essere limitativo. Ecco alcuni dei nostri dubbi specifici:
In termini semplificati, la licenza LGPL richiede l'invio del codice sorgente all'applicazione; un'offerta scritta per il codice sorgente; o il collegamento dinamico della libreria LGPL e la possibilità per gli utenti di eseguire l'upgrade o la sostituzione manuale della libreria. Il software Android viene solitamente fornito come immagine di sistema statica, pertanto la conformità a questi requisiti limita i progetti dei produttori di dispositivi. Ad esempio, è difficile per un utente sostituire una raccolta su archiviazione flash di sola lettura.
La licenza LGPL richiede la possibilità di modificare il software e di eseguire il reverse engineering per il debug di queste modifiche. La maggior parte dei produttori di dispositivi non vuole essere vincolata da questi termini.
Storicamente, le librerie LGPL sono state fonte di molti problemi di conformità per i produttori di dispositivi e gli sviluppatori di app a valle. Formare gli ingegneri su questi problemi è difficile e richiede tempo. È fondamentale per il successo di Android che i produttori di dispositivi possano rispettare facilmente le licenze.
Questi dubbi non sono critiche alla LGPL o ad altre licenze. Google apprezza tutte le licenze senza costi e open source e rispetta le preferenze di licenza degli altri.
Google ha deciso che Apache 2.0 è la soluzione più adatta ai nostri obiettivi.
Quando invii il codice da includere in AOSP, devi assicurarti di utilizzare correttamente le intestazioni delle licenze. Le sezioni seguenti spiegano come gestire le intestazioni della licenza per i nuovi file e il codice esistente.
Seguire le best practice per le licenze e il copyright
Segui queste best practice per l'intestazione del copyright e della licenza:
Non modificare un copyright esistente. Ad esempio, se vuoi donare un file all'AOSP contenente codice che ha avuto origine in un file con una propria nota sul copyright, devi conservare la nota sul copyright del file originale.
Se aggiungi un file di origine completamente nuovo, utilizza il copyright AOSP predefinito e la seguente intestazione della licenza, a meno che il progetto a cui stai contribuendo non abbia una licenza predefinita diversa:
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.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-27 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."]]
