La Californie a adopté à l’unanimité une exemption Linux et open source à sa future loi d’age-verification. Les parlementaires ont validé fin août 2026 l’AB 1856, un amendement qui retire du champ du Digital Age Assurance Act les systèmes d’exploitation et logiciels distribués sous des licences autorisant la copie, la redistribution et la modification. Concrètement, les distributions Linux diffusées sous GPL, MIT, BSD ou Apache n’auraient plus à mettre en place la collecte d’âge prévue au 1er janvier 2027. Le texte a été adopté par le Sénat le 26 août par 39 voix contre 0, puis par l’Assemblée le 27 août par 69 voix contre 0, selon le suivi législatif.
Cette correction met fin à des mois d’incertitude sur le sort des distributions Linux face à une loi pensée, à l’origine, pour les grandes plateformes disposant d’un compte utilisateur et d’un magasin d’applications. Elle ne supprime pas le dispositif californien : Windows, macOS, iOS et Android restent, eux, dans le périmètre.
L’exemption Linux repose sur une nouvelle définition du fournisseur d’OS
Le point central de l’AB 1856 est juridique, mais ses effets sont très concrets. Le texte redéfinit la notion d’« operating system provider » pour en exclure toute personne ou entité qui distribue un système d’exploitation ou une application sous des termes de licence permettant à l’utilisateur de copier, redistribuer et modifier le logiciel.
Dans les faits, cela couvre les licences open source les plus courantes citées dans les sources : GPL, MIT, BSD et Apache. Les distributions comme Debian, Fedora, Ubuntu ou Arch, ainsi que la famille BSD, sortent donc du champ d’application. Avant cet amendement, le doute était réel : la loi initiale pouvait laisser penser qu’un OS Linux devait lui aussi recueillir des informations d’âge lors de la configuration d’un compte, comme le feront les plateformes fermées à partir de 2027.
La nuance compte. L’exemption ne vise pas « tous les logiciels gratuits », mais un mode de distribution précis, défini par les droits accordés par la licence. Autrement dit, ce n’est pas la gratuité qui protège, c’est la possibilité légale de réutiliser et modifier le code.
Pour les projets open source, c’est surtout un soulagement en matière de conformité. Les critiques formulées après l’adoption de la loi initiale soulignaient qu’un écosystème distribué, souvent maintenu par des communautés ou des structures légères, ne pouvait pas déployer facilement une infrastructure d’age-gating conçue pour des acteurs centralisés. L’amendement traduit cette différence de modèle dans la lettre même de la loi.
La loi californienne d’age-verification reste entière pour Windows, macOS, iOS et Android
L’AB 1856 ne détricote pas le Digital Age Assurance Act. La loi principale reste prévue pour entrer en vigueur le 1er janvier 2027. À cette date, les fournisseurs de systèmes d’exploitation toujours visés devront recueillir des informations d’âge au moment de la configuration du compte afin de générer un signal de tranche d’âge, transmis ensuite aux applications via les magasins d’apps ou, selon la rédaction, aux développeurs.
Un second calendrier s’applique aux appareils déjà configurés avant cette entrée en vigueur : ils devront être mis en conformité au plus tard le 1er juillet 2027. Les sources insistent sur un point souvent mal compris : le mécanisme porte sur un age-bracket signal, donc sur une catégorie d’âge, et non sur une date de naissance brute ou une pièce d’identité complète.
Cette architecture continue donc de peser sur les écosystèmes fermés. Microsoft, Apple et Google restent exposés, là où Linux et la majorité des OS open source s’éloignent du radar réglementaire californien. C’est toute la portée politique de l’amendement : la pression demeure sur les plateformes qui contrôlent à la fois le compte utilisateur, l’OS et le circuit de distribution des applications.
Les bibliothèques, dépendances et extensions de navigateur sont aussi sorties du périmètre
L’AB 1856 ne s’arrête pas aux systèmes d’exploitation. Le texte ajoute une deuxième exclusion pour les composants logiciels qui ne sont pas proposés au consommateur comme application exécutable autonome via un covered application store. En pratique, cela vise les bibliothèques, les dépendances et d’autres briques distribuées par des gestionnaires de paquets comme apt ou pacman.
Le signal est clair : le législateur a voulu éviter que le filet réglementaire n’engloutisse, par effet de bord, l’infrastructure technique qui fait tourner l’open source au quotidien. Sans cette précision, la frontière entre application, composant et dépôt aurait pu devenir une source de contentieux ou d’obligations intenables.
Une troisième exclusion concerne les boutiques qui distribuent des extensions ou add-ons fonctionnant uniquement à l’intérieur d’une application hôte. Cette formulation écarte de fait les magasins d’extensions de navigateur.
Le texte encadre aussi les usages possibles du futur signal d’âge. Il précise qu’aucune personne ne peut demander ce signal à un fournisseur d’OS ou à un app store sauf si la loi l’exige. C’est une barrière importante contre un détournement de l’API vers de la collecte de données plus large. En parallèle, les plateformes et développeurs bénéficient d’un good-faith safe harbor en cas de signal erroné, ce qui limite leur responsabilité si l’information transmise est inexacte.
SteamOS reste un cas ambigu, GrapheneOS sort clairement du champ
Tout n’est pas complètement verrouillé. Le cas de SteamOS reste décrit comme incertain dans les éléments disponibles. Son socle repose sur des composants open source, mais Valve distribue l’image avec le client Steam, qui est propriétaire. Avec les seules informations fournies par les sources, il est donc impossible d’affirmer définitivement que SteamOS est, ou non, couvert par l’exemption.
GrapheneOS, en revanche, apparaît plus lisible. Le système est mentionné comme distribué sous licences MIT et Apache, ce qui le place désormais hors du champ de l’exigence californienne. Les sources précisent toutefois qu’une autre réglementation brésilienne continuerait de s’y appliquer. Le cas est intéressant : une exemption locale, même large, ne protège pas automatiquement d’obligations similaires sur d’autres marchés.
Sur le plan politique, cette marche arrière partielle est directement liée aux critiques déclenchées par la loi initiale. Buffy Wicks, à l’origine du texte de départ comme de l’amendement, a introduit l’exemption après les réactions de développeurs Linux et de l’Electronic Frontier Foundation. Le calendrier le montre bien : l’AB 1856 a été déposé le 11 février 2026, l’exemption open source est apparue dans une version amendée du 18 mai, avant l’adoption unanime de fin août.
La prochaine étape à surveiller tient désormais au statut final du texte auprès du gouverneur Gavin Newsom. Les sources consultées indiquent un envoi au gouverneur, tandis que certains suivis affichent déjà le bill comme devenu loi : ce point mérite d’être vérifié au fil de la procédure. Ensuite, l’échéance ne bougera pas : 1er janvier 2027 pour l’entrée en vigueur du régime principal, puis 1er juillet 2027 pour les appareils déjà configurés. D’ici là, le dossier à suivre sera moins Linux que l’interprétation des cas hybrides, SteamOS en tête.
