Cette page aborde deux tâches importantes pour les contributeurs : la signature des contrats de licence de contributeur et l'utilisation correcte des en-têtes de licence dans votre code.
Signer des contrats de licence pour les contributeurs
Tous les contributeurs individuels (ceux qui contribuent uniquement en leur nom propre) d'idées, de code ou de documentation au projet Android Open Source (AOSP) sont tenus de remplir, de signer et d'envoyer un Contrat de licence des contributeurs individuels. Vous pouvez exécuter cet accord en ligne à l'aide de l'outil d'examen du code. L'accord définit les conditions de contribution de la propriété intellectuelle à AOSP. Cette licence est destinée à vous protéger en tant que contributeur, ainsi qu'à protéger le projet. Elle ne modifie pas vos droits d'utiliser vos propres contributions à d'autres fins.
Le Corporate Contributor License Agreement est disponible pour les entreprises (ou autres entités) dont les employés travaillent sur AOSP. Cette version de l'accord permet à une entreprise d'autoriser les contributions envoyées par ses employés désignés et d'accorder des licences de droits d'auteur et de brevets.
Google base ses contrats de licence pour les contributeurs sur ceux utilisés par l'Apache Software Foundation, que vous trouverez sur le site Web Apache.
Inclure des en-têtes de licence
Le Projet Android Open Source (AOSP) utilise quelques licences Open Source approuvées par l'Open Source Initiative pour nos logiciels.
La licence Apache, version 2.0 (Apache 2.0) est la licence préférée pour AOSP, et la majorité des logiciels Android sont sous licence Apache 2.0. Bien que le projet s'efforce de respecter cette licence, il peut y avoir des exceptions qui sont traitées au cas par cas. Par exemple, les correctifs du noyau Linux sont soumis à la licence GPLv2 avec des exceptions système, que vous trouverez sur The Linux Kernel Archives.
Pour les logiciels de l'espace utilisateur (non liés au noyau), Google préfère la licence Apache 2.0 (et les licences similaires telles que BSD et MIT) aux autres licences telles que la licence publique générale GNU (LGPL). Pourquoi ?
Android est synonyme de liberté et de choix. L'objectif d'Android est de promouvoir l'ouverture dans le monde mobile. Google ne peut pas prédire ni dicter toutes les utilisations de son logiciel. Ainsi, bien que Google encourage chacun à créer des appareils ouverts et modifiables, nous ne pensons pas qu'il nous revienne de les y contraindre. L'utilisation de bibliothèques LGPL pourrait être restrictive. Voici quelques-uns de nos problèmes spécifiques :
En termes simplifiés, la licence LGPL exige l'expédition de la source à l'application, une offre écrite pour la source ou la liaison dynamique de la bibliothèque sous licence LGPL et l'autorisation des utilisateurs à mettre à niveau ou remplacer manuellement la bibliothèque. Le logiciel Android est généralement fourni sous la forme d'une image système statique. Le respect de ces exigences limite donc les conceptions des fabricants d'appareils. Par exemple, il est difficile pour un utilisateur de remplacer une bibliothèque sur un stockage flash en lecture seule.
La licence LGPL exige que les modifications apportées par le client et la rétro-ingénierie soient autorisées pour déboguer ces modifications. La plupart des fabricants d'appareils ne souhaitent pas être liés par ces conditions.
Par le passé, les bibliothèques LGPL ont été à l'origine de nombreux problèmes de conformité pour les fabricants d'appareils et les développeurs d'applications en aval. Il est difficile et chronophage de sensibiliser les ingénieurs à ces problèmes. Il est essentiel au succès d'Android que les fabricants d'appareils puissent facilement respecter les licences.
Ces préoccupations ne sont pas des critiques de la licence LGPL ou d'autres licences. Google apprécie toutes les licences Open Source sans frais et respecte les préférences de licence des autres. Google a décidé qu'Apache 2.0 était la licence la mieux adaptée à ses objectifs.
Lorsque vous envoyez du code à inclure dans AOSP, vous devez vous assurer d'utiliser correctement les en-têtes de licence. Les sections suivantes expliquent comment gérer les en-têtes de licence pour les nouveaux fichiers et le code existant.
Suivre les bonnes pratiques concernant les licences et les droits d'auteur
Suivez ces bonnes pratiques pour l'en-tête de copyright et de licence :
Ne modifiez pas un droit d'auteur existant. Par exemple, si vous souhaitez ajouter à l'AOSP un fichier contenant du code provenant d'un fichier avec son propre avis de copyright, vous devez conserver cet avis de copyright du fichier d'origine.
Si vous ajoutez un tout nouveau fichier source, utilisez le copyright AOSP par défaut et l'en-tête de licence suivant, sauf si le projet auquel vous contribuez a une licence prédéfinie différente :
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.