Contratti di licenza e intestazioni del collaboratore

Questa pagina copre due importanti attività del collaboratore: firmare i contratti di licenza del collaboratore e garantire l'uso corretto delle intestazioni di licenza nel codice.

Firmare accordi di licenza per i contributori

Tutti i singoli contributori (quelli che contribuiscono solo per proprio conto) di idee, codice o documentazione al progetto Android Open Source Project (AOSP) sono tenuti a completare, firmare e inviare un contratto di licenza per collaboratore individuale . Puoi eseguire questo accordo online tramite lo strumento di revisione del codice . L'accordo definisce i termini per il conferimento della proprietà intellettuale ad AOSP. Questa licenza serve per la tua protezione come collaboratore e per la protezione del progetto; ciò non modifica i tuoi diritti di utilizzare i tuoi contributi per qualsiasi altro scopo.

Il Contratto di licenza per collaboratore aziendale è disponibile per una società (o altra entità) con dipendenti che lavorano su AOSP. Questa versione dell'accordo consente a una società di autorizzare i contributi presentati dai dipendenti designati e di concedere licenze di copyright e brevetti.

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

Includi intestazioni di licenza

Il progetto Android Open Source (AOSP) utilizza alcune licenze open source approvate da iniziative open source 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 sforzi di aderire alla licenza preferita, esistono delle eccezioni, che vengono gestite caso per caso. Ad esempio, le patch del kernel Linux sono sotto la licenza GPLv2 con eccezioni di sistema, che possono essere trovate su The Linux Kernel Archives .

Per il software userspace (non kernel), Google preferisce Apache 2.0 (e licenze simili come BSD e MIT) rispetto ad altre licenze come la GNU Lesser General Public License (LGPL). Ecco perché:

  • Android è 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. Quindi, anche se Google incoraggia tutti a realizzare dispositivi aperti e modificabili, non pensiamo che sia nostro compito obbligarli a farlo. L'utilizzo delle librerie LGPL potrebbe essere restrittivo. Ecco alcune delle nostre preoccupazioni specifiche:

    • In termini semplificati, LGPL richiede l'invio del codice sorgente all'applicazione; un'offerta scritta per la fonte; o collegando dinamicamente la libreria LGPL e consentendo agli utenti di aggiornare o sostituire manualmente la libreria. Il software Android viene generalmente fornito come immagine di sistema statica, quindi la conformità a questi requisiti limita la progettazione del produttore del dispositivo. Ad esempio, è difficile per un utente sostituire una libreria su una memoria flash di sola lettura.

    • LGPL richiede la concessione di modifiche da parte del cliente e di reverse engineering per il debug di tali 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 downstream e gli sviluppatori di app. Formare gli ingegneri su questi temi è difficile e richiede tempo. È fondamentale per il successo di Android che i produttori di dispositivi possano facilmente rispettare le licenze.

Queste preoccupazioni non sono critiche alla LGPL o ad altre licenze. Google apprezza tutte le licenze gratuite 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 garantire l'uso corretto delle intestazioni della licenza. Le sezioni seguenti spiegano come gestire le intestazioni di licenza per i nuovi file e il codice esistente.

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

  • Non modificare un diritto d'autore esistente. Ad esempio, se desideri contribuire con un file ad AOSP che contiene codice originato in un file con un proprio avviso di copyright, devi conservare tale avviso di copyright del file originale.

  • Se aggiungi un file sorgente completamente nuovo, utilizza il copyright AOSP predefinito e la seguente intestazione di 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.