Cette page présente deux tâches importantes pour les contributeurs: signer une licence Contributeur des contrats et en veillant à utiliser correctement les en-têtes de licence dans votre code.
Signer des contrats de licence Contributeur
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 ce contrat en ligne via le outil de revue de code. L'accord définit les conditions de contribution à la propriété intellectuelle. à AOSP. Cette licence est destinée à votre protection en tant que contributeur ainsi qu'aux la protection du projet ; cela n'a aucune incidence sur vos droits d'utiliser vos propres des contributions à d'autres fins.
Contrat de licence Contributeur en entreprise est disponible pour les entreprises (ou toute autre entité) dont les employés travaillent sur AOSP. Cette version de l'accord permet à une entreprise d'autoriser les cotisations par les employés désignés, et accorde les droits d'auteur et les brevets licences.
Google base ses contrats de licence de contributeur sur ceux utilisés par l'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.
Licence Apache, version 2.0 (Apache 2.0) est la licence privilégiée pour AOSP, et la majorité des logiciel est concédé sous licence Apache 2.0. Bien que le projet s’efforce de respecter les licence préférée, il existe des exceptions, qui sont traitées au cas par cas. à la base. Par exemple, les correctifs du noyau Linux sont sous licence GPLv2 avec les exceptions système disponibles sur Archives du noyau Linux
Pour les logiciels d'espace utilisateur (hors noyau), Google préfère Apache 2.0 (et des versions similaires licences comme BSD et MIT) par rapport à d'autres licences comme GNU Lesser General Licence publique (LGPL). Pourquoi ?
Android est synonyme de liberté et de choix. Android vise à promouvoir dans l'univers mobile. Google n'est pas en mesure de prévoir ni de dicter pour notre logiciel. Ainsi, alors que Google encourage chacun à faire des choses ouvertes et les appareils modifiables, nous ne pensons pas que c'est à nous de les forcer à le faire. En utilisant Les bibliothèques LGPL peuvent être restrictives. Voici quelques-unes de nos préoccupations spécifiques :
Pour faire simple, la loi LGPL nécessite d'envoyer la source à l'application. un offre écrite pour la source ; ou en liant la bibliothèque soumise à la LGPL de manière dynamique 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 la modification des clients 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 en aval et les développeurs d'applications. Former les ingénieurs à ces problèmes est difficile et prend du temps. Il est essentiel de La réussite d'Android, grâce à laquelle les fabricants d'appareils peuvent facilement se conformer aux licences.
Ces préoccupations ne sont pas des critiques de la LGPL ou d'autres licences. Google apprécie toutes les licences libres et Open Source, et respecte les préférences des autres utilisateurs en matière de licence. Google a décidé qu'Apache 2.0 était la solution 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.
Respecter les bonnes pratiques concernant les licences et les droits d'auteur
Suivez ces bonnes pratiques concernant l'en-tête des droits d'auteur et des licences:
Ne modifiez pas un droit d'auteur existant. Par exemple, si vous souhaitez contribuer vers AOSP contenant du code provenant d'un fichier possédant son propre l'avis de droits d'auteur, vous devez le conserver dans le 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 dispose d'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.