Contratti di licenza dei collaboratori e intestazioni

Questa pagina tratta due importanti attività dei collaboratori: la firma dei contratti di licenza e l'uso corretto delle intestazioni delle licenze nel codice.

Firma i contratti di licenza del collaboratore

Tutti i singoli autori (coloro che forniscono contributi solo per proprio conto) di idee, codice o documentazione per l'Android Open Source Project (AOSP) sono tenuti a compilare, firmare e inviare un Individual Contributor License Agreement. 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 in qualità di collaboratore, nonché per la protezione del progetto. Non modifica i tuoi diritti di utilizzo dei tuoi contributi per qualsiasi altro scopo.

Il Contratto di licenza per i contributori aziendali è disponibile per una società (o un'altra persona giuridica) con dipendenti che lavorano su AOSP. Questa versione dell'accordo consente a una società di autorizzare i contributi inviati dai suoi dipendenti designati e di concedere licenze di copyright e brevetti.

Google basa i propri contratti di licenza per i collaboratori su quelli utilizzati dalla Apache Software Foundation, che possono essere trovati sul sito web di Apache.

Includi intestazioni delle licenze

Android Open Source Project (AOSP) utilizza alcune licenze open source approvate dall'Open Source Initiative 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 coperte dalla licenza GPLv2 con eccezioni di sistema, che possono essere trovate su The Linux Kernel Archives.

Per il software userspace (non kernel), Google preferisce la licenza 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 usi del nostro software. Pertanto, anche se Google incoraggia tutti a creare dispositivi aperti e modificabili, non riteniamo che sia nostro compito obbligarli a farlo. L'utilizzo di librerie LGPL potrebbe essere restrittivo. Ecco alcuni dei nostri dubbi specifici:

    • In termini semplificati, la licenza LGPL richiede la spedizione del codice sorgente all'applicazione, un'offerta scritta per il codice sorgente o il collegamento dinamico della libreria con licenza LGPL e consente agli utenti di eseguire l'upgrade o la sostituzione manuale della libreria. Il software Android viene in genere fornito come immagine di sistema statica, pertanto il rispetto di questi requisiti limita i progetti dei produttori di dispositivi. Ad esempio, è difficile per un utente sostituire una libreria su un dispositivo di archiviazione flash di sola lettura.

    • La licenza 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 downstream. Formare gli ingegneri su questi problemi è difficile e richiede molto tempo. È fondamentale per il successo di Android che i produttori di dispositivi possano rispettare facilmente le licenze.

Queste preoccupazioni 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 migliore per i 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 delle licenze per i nuovi file e il codice esistente.

Segui queste best practice per l'intestazione di copyright e licenza:

  • Non modificare un copyright esistente. Ad esempio, se vuoi contribuire con un file all'AOSP che contiene codice proveniente da un file con una propria nota sul copyright, devi conservare la nota sul copyright del file originale.

  • Se aggiungi un file sorgente completamente nuovo, utilizza il copyright AOSP predefinito e l'intestazione della licenza seguente, a meno che il progetto a cui contribuisci 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.