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 contribuent seuls d'idées, de code ou de documentation à un projet Android Open Source (AOSP) sont tenus de remplir, de signer et d'envoyer Contrat de licence pour les 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 le Apache Software Foundation, qui permet sur le Site Web Apache
Inclure les en-têtes de licence
Le projet Android Open Source (AOSP) utilise quelques initiative open source approuvée open source licences de notre logiciel.
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 fournie sous forme d'image système statique. Le respect de ces limite la conception des appareils par le fabricant. Par exemple, il est difficile pour un utilisateur de remplacer une bibliothèque sur un espace de 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 veulent pas être liés par les présentes conditions.
Les bibliothèques LGPL ont toujours été à l'origine de nombreux problèmes de conformité pour les fabricants d'appareils et les développeurs d'applications en aval. Instruire ingénieurs sur 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 vous remercie toutes les licences sans frais et Open Source, et respecter préférences de licence. Google a décidé qu'Apache 2.0 était la solution la mieux adaptée à ses objectifs.
Lorsque vous soumettez le code à inclure dans AOSP, vous devez vous assurer que vous utilisez correctement en-têtes de licence. Les sections suivantes expliquent comment gérer des 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 concernant l'en-tête des droits d'auteur et des licences:
Ne modifiez pas les droits d'auteur existants. 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 tout nouveau fichier source, utilisez les droits d'auteur d'AOSP par défaut et la propriété l'en-tête de licence suivant, à moins que le projet auquel vous contribuez une autre licence prédéfinie:
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.