Cette page décrit deux tâches importantes pour les contributeurs: signer des accords de licence de contributeur et s'assurer d'une utilisation correcte des en-têtes de licence dans le code.
Signer des contrats de licence pour les contributeurs
Tous les contributeurs individuels (ceux qui ne contribuent qu'en leur nom propre) d'idées, de code ou de documentation au projet Android Open Source (AOSP) doivent remplir, signer et envoyer un Contrat de licence des contributeurs individuels. Vous pouvez signer cet accord en ligne via l'outil de revue de code. Le contrat définit les conditions de contribution de propriété intellectuelle à l'AOSP. Cette licence vous protège en tant que contributeur, mais aussi le projet. Elle ne modifie pas vos droits d'utiliser vos propres contributions à d'autres fins.
Le Contrat de licence pour les contributeurs professionnels est disponible pour les entreprises (ou autres entités) dont les employés travaillent sur AOSP. Cette version du contrat permet à une entreprise d'autoriser les contributions envoyées par ses employés désignés et de concéder des licences de droits d'auteur et de brevets.
Google base ses contrats de licence de contributeur sur ceux utilisés par l'Apache Software Foundation, disponible sur le site Web d'Apache.
Inclure les en-têtes de licence
Le projet Android Open Source (AOSP) utilise quelques licences Open Source approuvées par l'initiative Open Source pour nos logiciels.
La licence Apache, version 2.0 (Apache 2.0) est la licence privilégiée pour AOSP, et la majorité des logiciels Android sont sous licence Apache 2.0. Bien que le projet s'efforce de respecter la licence préférée, il existe des exceptions, qui sont traitées au cas par cas. Par exemple, les correctifs du kernel Linux sont soumis à la licence GPLv2 avec des exceptions système, que vous pouvez consulter sur les archives du kernel Linux.
Pour les logiciels de l'espace utilisateur (non-noyau), Google préfère Apache 2.0 (et les licences similaires telles que BSD et MIT) à d'autres licences telles que la GNU Lesser General Public License (LGPL). Pourquoi ?
Android est synonyme de liberté et de choix. L'objectif d'Android est de promouvoir l'ouverture dans l'univers mobile, et Google ne peut pas prédire ni dicter toutes les utilisations de notre logiciel. Par conséquent, bien que Google encourage tout le monde à créer des appareils ouverts et modifiables, nous ne pensons pas qu'il nous appartienne de les y forcer. L'utilisation de bibliothèques LGPL peut être restrictive. Voici quelques-unes de nos préoccupations spécifiques:
En termes simplifiés, la loi LGPL nécessite l'envoi du code source à l'application, une offre écrite pour la source ou l'association dynamique de la bibliothèque prise en compte par la LGPL, et permettant aux utilisateurs de mettre à niveau ou de 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 LGPL exige que les clients puissent modifier et effectuer une rétro-ingénierie de ces modifications. La plupart des fabricants d'appareils ne souhaitent pas être liés par ces termes.
Par le passé, les bibliothèques LGPL ont été à l'origine de nombreux problèmes de conformité pour les fabricants d'appareils en aval et les développeurs d'applications. Former les ingénieurs à ces problèmes est difficile et prend du temps. Il est essentiel pour le succès d'Android que les fabricants d'appareils puissent facilement respecter les licences.
Ces préoccupations ne sont pas des critiques de la LGPL ou d'autres licences. Google apprécie toutes les licences sans frais et Open Source, et respecte les préférences des autres utilisateurs. Google a décidé qu'Apache 2.0 était la solution la plus adaptée à nos 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.
Respecter les bonnes pratiques concernant les licences et les droits d'auteur
Suivez ces bonnes pratiques pour l'en-tête des droits d'auteur et des licences:
Ne modifiez pas un droit d'auteur existant. Par exemple, si vous souhaitez partager sur AOSP un fichier contenant du code provenant d'un fichier avec sa propre notification de droits d'auteur, vous devez conserver cet avis de droits d'auteur du fichier d'origine.
Si vous ajoutez un fichier source entièrement nouveau, utilisez les droits d'auteur AOSP par défaut et l'en-tête de licence suivant, sauf si le projet auquel vous contribuez possède 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.