La loi imposant le partage du code source entre agences américaines est promulguée

 (fedscoop.com)
1 points par GN⁺ 2024-12-27 | 1 commentaires | Partager sur WhatsApp
  • Le président Joe Biden a signé le SHARE IT Act le 23 décembre, imposant aux agences fédérales américaines de partager entre elles le code source personnalisé afin de réduire les contrats de développement redondants
  • L’objectif central est de réduire les quelque 12 milliards de dollars que le gouvernement fédéral est estimé dépenser chaque année en achats de logiciels, en rendant le code personnalisé de chaque agence publiquement inventorié et réutilisable
  • Sont exclus du champ d’application de la loi le code classifié, les systèmes de sécurité nationale et le code dont le partage pourrait poser un risque pour la vie privée
  • Les CIO des agences doivent, dans un délai de 180 jours après l’entrée en vigueur, établir une politique de mise en œuvre comprenant le respect des bonnes pratiques, la publication des métadonnées et des procédures de reporting standardisées
  • Atlassian et GitLab Inc. ont soutenu le texte, adopté en décembre par la Chambre et le Sénat sans vote nominal

Obligation de partage du code dans le SHARE IT Act

  • Le Source Code Harmonization And Reuse in Information Technology Act, ou SHARE IT Act, exige que les agences fédérales partagent avec les autres agences le code source qu’elles ont fait développer sur mesure
  • Le texte vise à réduire le développement redondant, c’est-à-dire le fait de repasser contrat pour recréer du code déjà développé pour une autre agence sans le savoir
  • Les agences doivent dresser un inventaire public de leur code personnalisé et permettre aux autres agences de l’utiliser

Objectif d’économies budgétaires et exceptions

  • Les promoteurs de la loi estiment que le gouvernement fédéral dépense environ 12 milliards de dollars par an pour l’achat de logiciels
  • Le SHARE IT Act vise à réduire ce coût par la réutilisation du code personnalisé
  • Les codes suivants sont exclus du champ d’application de la loi
    • code classifié
    • systèmes de sécurité nationale
    • code dont le partage pourrait créer un risque pour la vie privée

Obligation pour les CIO des agences d’établir une politique sous 180 jours

  • Les directeurs des systèmes d’information (CIO) des agences doivent élaborer une politique de mise en œuvre du SHARE IT Act dans les 180 jours suivant l’entrée en vigueur de la loi
  • Cette politique doit inclure les procédures suivantes
    • des procédures garantissant que le code développé sur mesure respecte les bonnes pratiques
    • des procédures pour fournir publiquement les métadonnées du code personnalisé
    • des procédures de reporting standardisées

Métadonnées à publier

  • Les métadonnées au sens de la loi comprennent les informations permettant de vérifier l’état de développement et de partage du code personnalisé
  • Les éléments à inclure sont les suivants
    • si le code personnalisé a été développé dans le cadre d’un contrat
    • si le code a été partagé dans un dépôt
    • le numéro du contrat
    • un lien hypertexte vers le dépôt où le code a été partagé

Parcours législatif et soutien de l’industrie

  • Le texte a été porté au Sénat par Ted Cruz et Gary Peters, et à la Chambre par Nicholas Langworthy et William Timmons
  • La Chambre et le Sénat l’ont adopté en décembre sans vote nominal enregistré
  • Selon l’annonce faite en septembre par Langworthy lors du dépôt du texte à la Chambre, Atlassian et GitLab Inc. ont soutenu la loi
  • Stan Shepard, directeur juridique d’Atlassian, estime qu’un élargissement de la collaboration et du partage du code personnalisé favorisera l’ouverture, l’efficacité et l’innovation dans l’ensemble des organisations fédérales

À lire aussi

1 commentaires

 
GN⁺ 2024-12-27
Réactions sur Hacker News

  • Sans expérience de l’administration, on peut ne pas se rendre compte de pourquoi c’est si difficile. L’armée a une aversion pour les logiciels internes, et l’IT militaire évolue dans un monde totalement à part, attaqué chaque jour par les meilleurs acteurs étatiques du globe
    Les startups ne connaissent pas ce genre de situation, et même de grands groupes comme Facebook n’en approchent péniblement l’ampleur qu’en termes d’importance ; dans le privé, ce qui s’en rapproche le plus, ce sont sans doute les grandes institutions financières. L’armée américaine est aussi le plus grand employeur unique de la planète, soit l’équivalent d’environ 4,5 Walmart
    Du coup, l’armée surveille tout à plusieurs niveaux et verrouille fortement via des listes de logiciels approuvés par échelon. Les personnes qui rédigent ou appliquent les politiques de sécurité ne sont probablement pas des directeurs logiciels chevronnés, et quand ils voient NPM ou Maven, ils y voient un vecteur d’attaque illimité conçu par des gens qui ne connaissent pas la sécurité — et ce n’est pas complètement faux
    Côté civil et prestataires, la propriété du code est aussi compliquée. Si c’est développé avec de l’argent public, l’État devrait en être propriétaire, mais les contractants estiment devoir le conserver comme actif distinct de l’État pour pouvoir le refacturer ensuite. Cela se complique encore si un sous-traitant n’est pas aligné sur les objectifs financiers du contractant principal. Personnellement, je pense qu’il suffit de tout remettre à l’État, mais il est étrange de voir les gens empiler les barrières. L’infrastructure côté gouvernement a un niveau de certification de sécurité bien plus élevé, donc elle a aussi en général moins de contraintes

    • Décrire l’IT militaire comme presque imprenable passe à côté de la réalité : des infrastructures vieillissantes et des politiques lourdes nuisent fortement à l’efficacité
      Certains pans de l’armée américaine font peut-être face au niveau de menace et de sophistication sécuritaire décrit, mais dans l’ensemble il y a beaucoup de systèmes legacy qui rendent difficile l’intégration de solutions modernes ou de bonnes pratiques. Ces vieux systèmes, workflows et couches bureaucratiques produisent plus facilement de l’inefficacité et des vulnérabilités qu’une sécurité d’excellence
      Si on n’entend pas parler de compromissions de l’armée américaine, ce n’est pas parce qu’il n’y en a pas, mais parce qu’elles sont classifiées quand elles se produisent. Éviter l’humiliation publique est l’usage numéro un du classement secret, ce qui entretient l’idée de compétence. Moi, je mettrais la sécurité de Facebook devant celle de l’armée américaine n’importe quand, et l’écart ne me semble pas faible. Facebook traite aussi des paiements
    • J’ai du mal à être d’accord avec l’idée que « des grands groupes comme Facebook ne vivent que vaguement des situations comparables parce qu’ils ne sont pas si importants ». Quand je travaillais chez Microsoft et que je discutais avec l’équipe sécurité, j’avais l’impression que MSFT subissait en permanence des attaques de niveau étatique, y compris des tentatives de faire embaucher des agents d’un gouvernement chez Microsoft pour exfiltrer des informations confidentielles
      Vu l’importance d’AWS, il est évident qu’Amazon fait face à des menaces comparables
    • À mes yeux, ce texte a très peu de rapport avec l’armée. La loi précise en réalité que le code source classifié ou le code source destiné aux systèmes de sécurité nationale n’est pas concerné
      (A) Disposition générale — Cette loi ne s’applique pas au code source classifié ni au code source développé principalement pour être utilisé dans un système de sécurité nationale tel que défini au 40 U.S.C. 11103
      (B) Sécurité nationale — L’exemption aux exigences de la section 3 s’applique au code source classifié ou au code source suivant : (i) code développé principalement pour être utilisé dans un système de sécurité nationale, ou (ii) code développé par un organisme de la communauté du renseignement, ou une composante d’un tel organisme, tel que défini à la section 3(4) du National Security Act de 1947
    • Après avoir passé un an à parler avec l’équipe sécurité de mon service, autour du département client, dans le réseau local de prestataires et avec plusieurs fournisseurs, j’ai quitté le contracting après avoir vu le regard vide de mon client public quand je lui ai dit qu’une autre branche de l’armée avait terminé exactement le même projet quelques années plus tôt et qu’il suffisait peut-être de leur parler
      C’est à ce moment-là que j’ai compris comment fonctionne le business des contrats publics et pourquoi les choses durent des années de plus que nécessaire
    • Je partage l’idée qu’« il suffit de tout remettre à l’État ». J’ai effectivement travaillé dans une société de prestation où le client était propriétaire de tous les livrables, et en voyant des collègues dans des boîtes où ce n’était pas le cas, j’ai toujours trouvé ça étrange
      C’est notre argent via les impôts ; alors pourquoi soutenir un système qui vide les poches de tout le monde pour enrichir massivement quelques dirigeants et commerciaux d’entreprise ?
      Si la position est de ne pas « tout donner à l’État », alors la manière raisonnable me semble être de lui accorder le droit d’utiliser les livrables comme il le souhaite, tout en permettant la vente libre dans le privé des composants non classifiés et de leurs dérivés

  • La loi exige que les CIO des agences élaborent une politique dans les 180 jours suivant son entrée en vigueur, et que cette politique garantisse que le code développé sur mesure respecte les bonnes pratiques, tout en définissant des procédures pour publier les métadonnées du code sur mesure ainsi qu’une procédure standard de reporting.
    Dans la nouvelle loi, les métadonnées incluent si le code sur mesure a été développé dans le cadre d’un contrat, s’il a été partagé dans un dépôt, le numéro du contrat, et le lien vers le dépôt où le code a été partagé.
    Malheureusement, il ne semble pas s’agir d’une loi obligeant les agences à rendre leur code open source publiquement, mais seulement à le partager entre agences. La seule chose qui doive être partagée publiquement, ce sont les « métadonnées ». Le texte complet du projet de loi est ici : https://www.congress.gov/bill/118th-congress/house-bill/9566...

    • C’est un bon premier pas. L’étape suivante serait sans doute de le partager avec les États, les collectivités locales et les universités. Le partage public répartit beaucoup de responsabilités IT qui n’existent pas aujourd’hui
    • Cela semble déjà assez clair rien qu’avec le titre publié
    • Quand je vois le terme « bonnes pratiques », je deviens d’abord méfiant. Parce que cela risque surtout d’encourager davantage le cargo cult bureaucratique
    • La plupart des contrats du DOE, c’est-à-dire les contrats que le gouvernement passe avec des universités ou des consortiums qui exploitent des laboratoires, contiennent en général quelque chose comme : « ce code source peut rester fermé ou être publié en open source si l’on ne peut pas démontrer qu’il a un potentiel commercial ou une valeur SBIR. Mais pas sous GPL. »
      Il y avait des exceptions, mais aussi l’argument selon lequel d’autres contractants devaient pouvoir modifier le code source tout en conservant la même capacité à ne pas le publier. Je suppose que cela vient probablement du secteur de la défense.
      Le seuil était élevé pour le garder fermé pour des raisons d’argent, mais il a toujours été possible de le garder fermé pour n’importe quelle autre raison. DOE Code est un programme qui suit les logiciels open source et il est généralement géré via une organisation GitHub. OSTI est le service qui suit toute la propriété intellectuelle et la recherche
    • Certains, comme ZFSOnLinux, sont déjà partagés publiquement. Le dépôt est désormais devenu le dépôt OpenZFS et cela a amélioré la vie de beaucoup de gens. La mienne aussi.
      Le modèle de développement open source a aussi profité au LLNL, qui a obtenu une base de code bien meilleure qu’en développant seul.
      Il y a aussi des choses déjà publiques, comme NASA IKOS : https://github.com/NASA-SW-VnV/ikos
      Ce projet reçoit bien moins d’attention de la part de tiers qu’il ne le devrait. S’il pouvait évoluer en analyseur statique générique et correct traitant le multithreading, cela aiderait à améliorer beaucoup d’autres projets

  • J’ai déjà essayé de promouvoir un modèle entièrement open source à partir de l’idée que « si c’est financé par l’argent public, le public devrait pouvoir voir ce qui en résulte » : https://web.archive.org/web/20200920095030/http://oss4gov.or...
    Je pensais que, par défaut, les logiciels du gouvernement devraient être open source, sauf exception approuvée au niveau ministériel. Mais à l’époque, j’étais jeune et naïf

    • Je ne vois pas cela comme particulièrement controversé. Le gouvernement britannique voit les choses de façon similaire : https://www.gov.uk/service-manual/technology/making-source-c...
    • J’ai travaillé pendant des années chez un sous-traitant militaire, et beaucoup de gens pensent que si les contribuables ont payé et que le logiciel n’est pas classifié, alors il devrait être open source.
      Ghidra en est un bon exemple, et le fait que ce logiciel soit devenu gratuit a été un énorme bénéfice pour la communauté de la sécurité
    • La FSFE partage la même idée de l’autre côté de l’Atlantique : https://publiccode.eu/en/
    • Tu n’étais pas naïf, tu étais en avance sur ton temps. Le progrès est un travail difficile et un marathon

  • Nous créons des logiciels open source et essayons de les faire adopter ou utiliser par des agences gouvernementales, mais il est surprenant à quel point ces agences semblent allergiques à l’open source.
    Certains préfèrent tout reconstruire eux-mêmes avec des méthodes héritées comme l’import CSV ou des parseurs cassés plutôt que d’utiliser le code de quelqu’un d’autre, et ils reproduisent au passage les bugs et défauts prévisibles.
    Même quand on répond à un appel d’offres, la solution open source subit un examen plus strict qu’un système fermé. Il faut prouver qu’être public est une bonne chose, alors qu’avec un système fermé le fournisseur peut dire « oui, c’est parfait » et l’agence peut passer à autre chose. On a l’impression que les agences et leurs employés ne veulent assumer aucune responsabilité. Pourtant, je n’ai jamais vu quelqu’un perdre un emploi public pour cause d’incompétence

    • À grande échelle, c’est du protectionnisme de l’emploi, et au niveau individuel, c’est une structure où l’on cherche à devenir l’expert métier qui utilisera sa propre base de code pour obtenir une promotion. En général, les agences ne se voient pas comme travaillant dans la même équipe. Elles peuvent être très concurrentielles quand il s’agit de faire du lobbying au Congrès pour obtenir des ressources pour leur propre agence.
      Je travaille dans l’administration et je l’ai vécu directement. La culture est profondément toxique et dysfonctionnelle. J’attends de voir quels changements l’équipe d’Elon et Trump proposera
    • Avec l’open source, il n’y a personne à blâmer. Avec un logiciel fermé, quand quelque chose tourne mal, il y a quelqu’un du doigt à pointer

  • Le département américain de la Défense dispose d’une FAQ sur les logiciels open source : http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx et https://github.com/risacher/DoD-OSS-FAQ
    Cette version a été publiée sur GitHub comme expérimentation d’un outil collaboratif destiné à la participation du public autour de documents de politique gouvernementale, et il est indiqué que des militaires, des personnels civils, des prestataires et des particuliers peuvent soumettre des modifications ou des ajouts via pull request
    Vidéo de 2010 : https://www.youtube.com/watch?v=WWt0YiXcEkE
    Dan Risacher, du bureau du DSI du DoD, et l’expert en sécurité open source David A. Wheeler y expliquent l’historique et l’impact d’un mémo récent du DoD qui clarifie la position du département selon laquelle il considère l’open source comme un logiciel commercial exploitable
    Document de 2024 : https://openssf.org/press-release/2024/10/29/openssf-expands...
    L’OpenSSF de la Linux Foundation a déclaré reconnaître la nécessité de la formation à la sécurité, et selon David A. Wheeler, directeur de la sécurité de la chaîne d’approvisionnement open source à l’OpenSSF, plus de 25 000 personnes se sont inscrites à ces supports de formation depuis le lancement du cours

  • L’intention est bonne, mais en pratique il ne se passera probablement pas grand-chose, si ce n’est que les concurrents potentiels du prestataire n°1 combleront l’écart ou attaqueront la qualité du code du contrat existant. Lire du code est plus difficile que d’en écrire

    • Si des concurrents potentiels comblent l’écart, du point de vue du gouvernement cela signifie plus de concurrence et moins de coûts
      S’ils attaquent la qualité du code du contrat existant, c’est une revue de code, et cela conduit d’une manière ou d’une autre à une amélioration de la qualité du code. Je ne vois pas où est le problème ici

  • C’est une excellente chose. Je me souviens avoir galéré parce qu’il était impossible de lire du code même au sein d’une même organisation. Ce genre de changement devrait faciliter le travail de ceux qui construisent des modèles mentaux top-down

  • En règle générale, tout ce qui a été payé avec l’argent du contribuable devrait être public. Public Monies Public Goods devrait être un principe de base absolu

    • Une telle règle existe déjà, mais le DoD est la seule agence à la prendre au sérieux. On peut citer BRL-CAD et FalconView
      Cela n’empêche toutefois pas des prestataires peu scrupuleux d’apposer un copyright sur le code et de facturer des frais de licence. C’est le cas de la plupart des codes du DoE, avec des exceptions comme NWCHEM. Je me suis toujours demandé pourquoi cela n’avait pas donné lieu à des poursuites, mais c’est probablement parce que personne ne s’en soucie vraiment
    • Il est intéressant de voir que certains gouvernements locaux apposent un copyright sur leurs propres lois pour empêcher d’autres collectivités de les copier sans payer
      D’un côté, on peut comprendre l’idée que d’autres territoires profitent gratuitement d’un système réglementaire financé par les contribuables locaux. C’est d’autant plus vrai si la loi s’applique principalement aux collectivités locales de cette zone. D’un autre côté, l’idée que la loi soit restreinte par le copyright paraît étrange
    • Je ne suis pas d’accord. À cause de la Chine. Le gouvernement américain doit garder son code privé, y compris le code médiocre de prestataires absurdement chers
    • Pour les logiciels, je ne suis pas d’accord
    • Tu proposes donc de rendre public tout, depuis les documents classifiés jusqu’aux notes de service et dossiers du personnel ? Cela n’arrivera pas
      Il faut aussi réfléchir à ce qu’on possède exactement, au-delà du livrable final, quand on mandate quelqu’un pour faire un travail chez soi

  • C’est une très bonne direction. En travaillant avec des équipes gouvernementales, j’ai déjà vu cette approche présentée comme pratique recommandée : https://www.forgov.qld.gov.au/information-and-communication-...
    Dans bien des cas, il reste cependant nécessaire d’aller jusqu’à l’inscrire dans la loi comme exigence pour que cette recommandation soit réellement suivie. C’est particulièrement vrai dans les services publics, où il est fréquent de trouver des personnes n’ayant jamais participé à une communauté open source
    Comme d’autres l’ont souligné, les budgets publics devraient produire un bénéfice public, et l’open source est un bon moyen d’amplifier ce bénéfice

  • Le texte dit : « La nouvelle loi ne s’applique pas au code classifié, aux systèmes de sécurité nationale ni au code dont le partage créerait un risque pour les données personnelles »
    Quel genre de code pourrait bien créer un risque pour les données personnelles s’il était partagé ? On dirait surtout que le code et les données sont assez mal mêlés

    • Il n’y a pas forcément de risque réel, mais cela fournit un bon prétexte pour ne pas publier. Des entreprises et des organismes publics ont déjà refusé des demandes d’accès à des documents techniques au motif de la protection de la vie privée. C’était du genre « cela s’applique à un système qui traite des données personnelles » ou « connaître le fonctionnement interne du système augmenterait les risques de compromission »
      Les prestataires publics reconnaissent volontiers en creux que leur code est mauvais et qu’il repose généralement sur la sécurité par l’obscurité. La commission d’accès à l’information leur a parfois donné raison
    • Un code suffisamment personnalisé finit par intégrer des fonctionnalités qui révèlent beaucoup d’informations sur le travail visé
      Il suffit de penser à ce qu’on pourrait voir dans des formules Excel
    • Il n’y a aucune différence entre les deux