La Apple Public Source License v2.0 (APSL) autorise l’utilisation, la modification et la redistribution du code d’Apple sous certaines conditions. Derrière ces termes techniques se jouent des enjeux concrets de propriété intellectuelle, de brevets et de stratégie commerciale. Comprendre son fonctionnement avant de l’adopter est donc essentiel pour tout utilisateur qui souhaite exploiter ou contribuer à des logiciels open source tout en préservant la valeur de ses actifs immatériels.
À qui s’adresse l’APSL ?
D’abord, l’APSL cible les entreprises et développeurs qui souhaitent s’appuyer sur des briques logicielles issues de macOS ou d’autres projets Apple tout en restant compatibles avec un modèle économique propriétaire. En effet, la licence est dite « copyleft faible ». Elle impose la publication du code source uniquement pour les fichiers dérivés directement du code Apple. Vous exploitez un composant couvert ? Vous devrez placer les modifications de ce fichier sous APSL et publier les sources lorsque le logiciel est mis à disposition « en production » (external deployment). En revanche, vos propres modules placés dans des fichiers séparés peuvent rester totalement propriétaires. Cette modularité attire les éditeurs qui veulent conjuguer open source et secret industriel.
Juridiquement, elle repose sur les articles L.122-6 et L.122-7 du Code de la propriété intellectuelle concernant le droit de reproduction et de représentation, et sur la faculté de concession de droits prévue à l’article L.131-3.
Toutefois, la licence prévoit que tout litige sera tranché par les tribunaux de l’État de Californie. Cette clause doit alerter les sociétés françaises non familiarisées avec la common law.
Comment fonctionne l’Apple Public Source License v2.0 : mécanique juridique et technique
Ensuite, le mécanisme repose sur un déclencheur précis. Dès qu’un utilisateur met en ligne ou livre à un tiers une application intégrant du code APSL, il réalise un « external deployment ». Cet acte active trois obligations cumulatives :
- fournir le code source modifié du ou des fichiers dérivés ;
- accorder une licence mondiale, gratuite et irrévocable sur ces modifications ;
- notifier clairement l’usage de l’APSL.
La licence contient également une clause de licence de brevets. Ainsi, chaque contributeur octroie automatiquement une licence sur ses brevets nécessaires pour exploiter la contribution, sécurisant l’utilisateur contre une action en contrefaçon (articles L.613-3 et L.613-8 du Code de la Propriété intellectuelle). En cas de non-respect, la suspension des droits est automatique, mais un délai de trente jours est prévu pour corriger la violation avant résiliation définitive — une souplesse appréciable.
Contrairement aux licences copyleft fortes (GNU GPL v3), l’APSL n’impose pas de transmettre le code source de modules indépendants liés dynamiquement. Cela est possible grâce au fonctionnement « par fichier ». Seul le fichier contenant du code dérivé doit rester ouvert.
Enfin, aucune compatibilité explicite n’est prévue avec d’autres licences. Tout usage mixte exige donc un audit juridique pour éviter une incompatibilité de clauses, notamment avec la GNU GPL ou l’Apache 2.0.
Les atouts et les limites de l’Apple Public Source License v2.0 pour votre entreprise
Du côté des avantages, l’APSL combine la sécurité d’un cadre open source solide et la flexibilité d’un maintien de la propriété sur vos développements internes. Vous bénéficiez d’une base de code testée par Apple, d’une communauté active et d’un régime de brevets protecteur. Le risque de « viralité » étendue, souvent redouté avec la GPL, est ici réduit. En effet, vos bibliothèques complémentaires, vos interfaces graphiques ou votre couche métier peuvent rester fermées, préservant votre avantage concurrentiel. La clause de cure de trente jours limite également l’exposition à une résiliation brutale, offrant un filet de sécurité crucial.
Cependant, cette licence comporte aussi des contraintes importantes. La compétence exclusive en Californie peut entraîner des frais procéduraux élevés et un décalage culturel dans la conduite du procès. De plus, l’obligation de publier le code source en cas de déploiement externe peut effrayer les entreprises qui misent sur la confidentialité de certaines optimisations.
Enfin, l’absence de compatibilité automatique complique les projets hybrides. Un simple rapprochement avec un module Apache 2.0 peut exiger la rédaction d’avenants ou le recours à une double licence.
En pratique, l’APSL est donc un compromis. Idéale pour les sociétés qui veulent collaborer avec Apple tout en conservant une partie de leur code, moins adaptée aux start-ups qui visent une ouverture totale ou complète.
APSL, GPL, MPL : quelle licence choisir ?
Pour terminer, confrontons l’APSL à ses cousines.
- La Mozilla Public License 2.0 (MPL) partage la logique « par fichier ». Seul le fichier modifié doit être publié sous MPL. En revanche, elle prévoit une compétence juridique plus neutre et jouit d’une compatibilité croisée, simplifiant les projets multi-licences.
- La GNU General Public License v3 (GPL), elle, impose le partage de tout code lié, même dans des fichiers distincts. C’est le régime copyleft fort. La GPL protège davantage la liberté des utilisateurs finaux, mais peut rebuter les éditeurs issus du secteur SaaS qui misent sur le secret logiciel.
- À l’opposé, l’Apache License 2.0 offre une permissivité maximale, sans obligation de publication et avec une concession de brevets, mais n’apporte aucune garantie de réciprocité. En conséquence, vos améliorations peuvent être privatisées par un tiers.
L’APSL se situe donc entre ces extrêmes. Plus protectrice que l’Apache pour éviter l’appropriation pure, moins contraignante que la GPL pour préserver vos modules stratégiques. En outre, ces distinctions entre les licences peuvent être illustrées dans le tableau suivant :
Source : Benjamin Jean, Option libre, Du bon usage des licences libres, Frambook, 2011
Ainsi, le choix dépendra de votre modèle d’affaires, de votre stratégie d’innovation ouverte et du niveau de contrôle souhaité. Pour arbitrer, l’analyse des flux de revenus, de la roadmap technique et des marchés cibles reste fondamentale. Un accompagnement sur mesure permet d’anticiper les risques de contamination de droits et de structurer une gouvernance de contributions efficace.
Deshoulières Avocats vous conseille et vous accompagne dans le choix, la négociation et la conformité de vos licences libres, en mettant son expertise en propriété intellectuelle et en droit du logiciel au service de votre stratégie d’innovation.
RESSOURCES :
- Code de la propriété intellectuelle : articles L.122-6 à L.122-7 et L.131-3 (droit d’autoriser et contrats).
- Code de la propriété intellectuelle : articles L.613-3 et L.613-8 (licence et épuisement des brevets).
- Apple Public Source License v2.0 (texte officiel Apple – 2003).
- Deshoulières Avocats, « Licences libres et open source : quelle licence choisir ? ».
