Contrats de licence et en-têtes des contributeurs

Cette page couvre deux tâches importantes des contributeurs : signer les contrats de licence des contributeurs et garantir l'utilisation correcte des en-têtes de licence dans votre code.

Signer les accords de licence des contributeurs

Tous les contributeurs individuels (ceux qui contribuent uniquement en leur propre nom) d'idées, de code ou de documentation au projet Android Open Source (AOSP) doivent remplir, signer et soumettre un accord de licence de contributeur individuel . Vous pouvez exécuter cet accord en ligne via l' outil de révision du code . L'accord définit les conditions de contribution à la propriété intellectuelle à l'AOSP. Cette licence est pour votre protection en tant que contributeur ainsi que pour la protection du projet ; cela ne modifie pas vos droits d'utiliser vos propres contributions à d'autres fins.

Le contrat de licence de contributeur d'entreprise est disponible pour une société (ou autre entité) dont les employés travaillent sur AOSP. Cette version de l'accord permet à une société d'autoriser les contributions soumises par ses employés désignés et d'accorder des licences de droits d'auteur et de brevet.

Google base ses accords de licence de contributeur sur ceux utilisés par Apache Software Foundation , disponibles 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 préférée pour AOSP, et la majorité des logiciels Android sont sous licence avec 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 noyau Linux sont sous licence GPLv2 avec des exceptions système, qui peuvent être trouvées sur The Linux Kernel Archives .

Pour les logiciels de l'espace utilisateur (hors noyau), Google préfère Apache 2.0 (et les licences similaires telles que BSD et MIT) aux autres licences telles que la licence publique générale limitée GNU (LGPL). Voici pourquoi:

  • Android est synonyme de liberté et de choix. Le but d'Android est de promouvoir l'ouverture dans le monde mobile, et Google ne peut pas prédire ni dicter toutes les utilisations de nos logiciels. Ainsi, même si Google encourage tout le monde à créer des appareils ouverts et modifiables, nous ne pensons pas que ce soit à nous de les forcer à le faire. L'utilisation des bibliothèques LGPL peut être restrictive. Voici quelques-unes de nos préoccupations spécifiques :

    • En termes simplifiés, LGPL nécessite l'envoi de la source à l'application ; une offre écrite pour la source ; ou relier dynamiquement la bibliothèque LGPL-ed et permettre aux utilisateurs de mettre à niveau ou de remplacer manuellement la bibliothèque. Les logiciels Android sont généralement livrés sous forme d'image système statique. Le respect de ces exigences restreint donc la conception des fabricants d'appareils. Par exemple, il est difficile pour un utilisateur de remplacer une bibliothèque sur un stockage flash en lecture seule.

    • LGPL exige l'autorisation des modifications client et de l'ingénierie inverse pour le débogage de ces modifications. La plupart des fabricants d'appareils ne souhaitent pas être liés par ces conditions.

    • Historiquement, 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. Former les ingénieurs à ces questions est difficile et prend du temps. 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 LGPL ou d'autres licences. Google apprécie toutes les licences gratuites et open source et respecte les préférences de licence des autres. Google a décidé qu'Apache 2.0 était la solution la mieux adaptée à nos objectifs.

Lorsque vous soumettez du code à inclure dans AOSP, vous devez vous assurer de la bonne utilisation des 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.

Suivez ces bonnes pratiques pour les droits d’auteur et l’en-tête de licence :

  • Ne modifiez pas un droit d'auteur existant. Par exemple, si vous souhaitez contribuer à AOSP avec un fichier contenant du code provenant d'un fichier avec sa propre notification de droit d'auteur, vous devez conserver cette notification de droit d'auteur du fichier d'origine.

  • Si vous ajoutez un tout nouveau fichier source, utilisez le droit d'auteur 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.