Questa pagina illustra due importanti attività dei contributori: la firma dei contratti di licenza per i contributori e l'utilizzo corretto delle intestazioni delle licenze nel codice.
Firmare i contratti di licenza per i contributori
Tutti i singoli contributori (coloro che forniscono contributi solo per conto proprio) di idee, codice o documentazione per Android Open Source Project (AOSP) sono tenuti a compilare, firmare e inviare un contratto di licenza per i singoli contributori. Puoi eseguire questo contratto online tramite lo strumento di revisione del codice. Il contratto definisce i termini per il contributo di proprietà intellettuale ad AOSP. Questa licenza è per la tua protezione come contributore, nonché per la protezione del progetto; non modifica i tuoi diritti di utilizzare i tuoi contributi per qualsiasi altro scopo.
Il contratto di licenza per i contributori aziendali è disponibile per una società (o altra persona giuridica) con dipendenti che lavorano su AOSP. Questa versione del contratto consente a una società di autorizzare i contributi inviati dai dipendenti designati e di concedere licenze di copyright e brevetti.
Google basa i propri contratti di licenza per i contributori su quelli utilizzati da Apache Software Foundation, che possono essere trovati sul sito web di Apache.
Includere le intestazioni delle licenze
Android Open Source Project (AOSP) utilizza alcune iniziative open source approvate open source licenze 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 eccezioni, che vengono gestite caso per caso. Ad esempio, le patch del kernel Linux sono soggette alla licenza GPLv2 con eccezioni di sistema, che sono disponibili in The Linux Kernel Archives.
Per il software userspace (non kernel), Google preferisce Apache 2.0 (e licenze simili come BSD e MIT) ad altre licenze come la GNU Lesser General Public License (LGPL). Ecco perché:
Android è sinonimo di libertà e scelta. Lo scopo di Android è promuovere l'apertura nel mondo mobile e Google non può prevedere o imporre tutti gli utilizzi del nostro software. Pertanto, sebbene Google incoraggi tutti a creare dispositivi aperti e modificabili, non riteniamo che sia nostro compito costringerli a farlo. L'utilizzo delle librerie LGPL potrebbe essere restrittivo. Ecco alcune delle nostre preoccupazioni specifiche:
In termini semplificati, LGPL richiede la spedizione 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 sostituire manualmente la libreria. Il software Android viene in genere spedito come immagine di sistema statica, pertanto il rispetto di questi requisiti limita le progettazioni dei produttori di dispositivi. Ad esempio, è difficile per un utente sostituire una libreria su una memoria flash di sola lettura.
LGPL richiede la concessione della modifica e del reverse engineering da parte del cliente 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 la fonte di molti problemi di conformità per i produttori di dispositivi e gli sviluppatori di app a valle. Educare 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.
Queste preoccupazioni non sono critiche nei confronti di LGPL o di 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 migliore per i nostri obiettivi.
Quando invii codice da includere in AOSP, devi assicurarti di utilizzare correttamente le intestazioni delle licenze. Le sezioni seguenti spiegano come gestire le intestazioni delle licenze 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 contribuire con un file ad AOSP che contiene codice proveniente da un file con una propria nota di copyright, devi conservare la nota di 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.