Se promulga ley que obliga a compartir código fuente entre agencias de EE. UU.

• El presidente Joe Biden firmó la SHARE IT Act el 23 de diciembre, por lo que las agencias federales de EE. UU. deberán compartir entre sí el código fuente personalizado para reducir los contratos de desarrollo duplicados
• El punto clave es catalogar públicamente el código personalizado de cada agencia y hacerlo reutilizable, con el fin de reducir los aproximadamente 12 mil millones de dólares que se estima que el gobierno federal gasta cada año en compras de software
• Quedan excluidos de la aplicación de la ley el código clasificado, los sistemas de seguridad nacional y el código cuyo intercambio pueda implicar riesgos para la privacidad
• Los CIO de las agencias deberán establecer, dentro de los 180 días posteriores a la entrada en vigor, una política de implementación que incluya cumplimiento de mejores prácticas, divulgación de metadatos y procedimientos estandarizados de reporte
• Atlassian y GitLab Inc. apoyaron el proyecto, que fue aprobado en diciembre por ambas cámaras sin votación nominal registrada

---

Obligación de compartir código bajo la SHARE IT Act

• La Source Code Harmonization And Reuse in Information Technology Act, o SHARE IT Act, exige que las agencias federales compartan con otras agencias el código fuente desarrollado a medida
• Se enfoca en reducir el desarrollo duplicado que ocurre cuando se vuelve a contratar la creación de código ya desarrollado para otra agencia sin saberlo
• Las agencias deberán catalogar públicamente su código personalizado y permitir que otras agencias lo aprovechen

Objetivo de ahorro presupuestario y excepciones de aplicación

• Los patrocinadores de la ley estiman que el gobierno federal gasta aproximadamente 12 mil millones de dólares al año en compras de software
• La SHARE IT Act busca reducir ese costo mediante la reutilización de código personalizado
• Quedan excluidos de la aplicación de la ley los siguientes tipos de código
  • Código clasificado
  • Sistemas de seguridad nacional
  • Código cuyo intercambio pueda generar riesgos para la privacidad

Obligación de los CIO de establecer una política dentro de 180 días

• Los directores de información (CIO) de las agencias deberán crear una política de implementación de la SHARE IT Act dentro de los 180 días posteriores a la entrada en vigor de la ley
• La política debe incluir los siguientes procedimientos
  • Procedimientos para garantizar que el código desarrollado a medida cumpla con las mejores prácticas
  • Procedimientos para proporcionar públicamente los metadatos del código personalizado
  • Procedimientos de reporte estandarizados

Metadatos que deben divulgarse

• Los metadatos a los que se refiere la ley incluyen información que permite verificar el estado de desarrollo y de compartición del código personalizado
• Los elementos incluidos son los siguientes
  • Si el código personalizado fue desarrollado bajo contrato
  • Si el código fue compartido en un repositorio
  • Número de contrato
  • Hipervínculo al repositorio donde se compartió el código

Proceso legislativo y apoyo de la industria

• El proyecto fue patrocinado en el Senado por Ted Cruz y Gary Peters, y en la Cámara de Representantes por Nicholas Langworthy y William Timmons
• El Senado y la Cámara de Representantes aprobaron el proyecto en diciembre sin una votación registrada a favor o en contra
• Según el anuncio de septiembre de Langworthy sobre la presentación del proyecto en la Cámara, Atlassian y GitLab Inc. respaldaron la iniciativa
• Stan Shepard, director jurídico de Atlassian, considera que ampliar la colaboración y el intercambio de código personalizado impulsa la apertura, la eficiencia y la innovación en todo el aparato federal

[GN⁺]

Opiniones en Hacker News

• Si no tienes experiencia en el gobierno, puede que no tengas idea de por qué esto es tan difícil. Las fuerzas armadas le tienen alergia al software interno, y la TI militar es un mundo completamente distinto, atacado todos los días por intrusos con apoyo estatal de primer nivel mundial.
  Las startups no pasan por esto, e incluso grandes empresas como Facebook apenas experimentan algo de nivel similar en términos de importancia; en el sector privado, lo más cercano serían las grandes instituciones financieras. Además, el ejército de EE. UU. es el mayor empleador individual del planeta, equivalente a 4.5 veces Walmart.
  Por eso las fuerzas armadas monitorean todo en múltiples capas y lo bloquean fuertemente con listas de software aprobado por capa. Es muy probable que quienes escriben o supervisan las políticas de seguridad no sean directores de software experimentados, y cuando ven NPM o Maven los consideran vectores de ataque ilimitados creados por gente que no sabe de seguridad; y no están del todo equivocados.
  En el ámbito civil y de contratistas, la propiedad del código también es complicada. Si se construye con dinero del gobierno, debería ser propiedad del gobierno, pero los contratistas consideran que deben llevárselo como un activo propio separado del gobierno para poder volver a cobrar. Si los subcontratistas no están alineados con los objetivos financieros del contratista principal, se vuelve aún más complejo. Personalmente creo que bastaría con entregarle todo al gobierno, pero es raro cómo la gente levanta barreras por capas. La infraestructura del lado del gobierno tiene un nivel de certificación de seguridad mucho más alto, así que en general también tiene menos restricciones.

  • Presentar la TI militar como casi inexpugnable pasa por alto la realidad de que la infraestructura obsoleta y las políticas torpes reducen enormemente la eficiencia.
    Algunas áreas del ejército de EE. UU. quizá enfrenten el nivel de amenazas y sofisticación de seguridad descrito, pero en conjunto hay muchos sistemas legacy donde es difícil integrar soluciones modernas o mejores prácticas. Estos sistemas, flujos de trabajo y burocracias obsoletos suelen generar más ineficiencias y vulnerabilidades que una seguridad sobresaliente.
    Que no escuchemos que el ejército de EE. UU. haya sido vulnerado no significa que no ocurra, sino que, cuando ocurre, se clasifica como secreto. Evitar la vergüenza pública es el uso número uno de la clasificación, lo que crea la creencia de que son competentes. Yo pondría en cualquier momento la seguridad de Facebook por delante de la del ejército de EE. UU., y creo que la diferencia no es pequeña. Facebook también es un procesador de pagos.
  • Me cuesta estar de acuerdo con eso de que “las grandes empresas como Facebook apenas pasan por algo similar porque no son importantes”. Cuando trabajé en Microsoft y hablé con el equipo de seguridad, me dio la impresión de que MSFT sufría ataques de nivel estatal constantemente, incluidos intentos de colocar activos gubernamentales trabajando en Microsoft para extraer secretos.
    Dada la importancia de AWS, es evidente que Amazon también debe enfrentar amenazas similares.
  • A mi parecer, este proyecto de ley tiene muy poco que ver con las fuerzas armadas. El texto real dice que el código fuente clasificado o el código fuente para sistemas de seguridad nacional no está dentro de su alcance.
    (A) Disposición general: esta ley no se aplica al código fuente clasificado ni al código fuente desarrollado principalmente para su uso en sistemas de seguridad nacional, según la definición de 40 U.S.C. 11103.
    (B) Seguridad nacional: la exención de los requisitos de la sección 3 se aplica al código fuente clasificado o al siguiente código fuente: (i) código desarrollado principalmente para su uso en sistemas de seguridad nacional, o (ii) código desarrollado por una agencia integrante de la comunidad de inteligencia, según la definición de la sección 3(4) de la Ley de Seguridad Nacional de 1947, o por una parte de ella.
  • Durante un año hablé con el equipo de seguridad de mi departamento, con gente alrededor del departamento del cliente, con una red de contratistas locales y con varios proveedores; dejé el trabajo de contratación cuando vi que el cliente gubernamental se quedaba mirando en blanco al escuchar que otra rama militar había terminado exactamente lo mismo que mi proyecto varios años antes y que “¿no podrían hablar con ellos?”.
    En ese momento entendí cómo está estructurado el negocio de la contratación gubernamental y por qué las cosas se alargan años más de lo necesario.
  • Simpatizo con la idea de “entregarle todo al gobierno”. De hecho, trabajé en una contratista donde el cliente era dueño de todos los entregables, y siempre me pareció extraño ver a colegas que trabajaban en contratistas donde no era así.
    Es dinero que pagamos con nuestros impuestos, así que uno termina preguntándose por qué deberíamos apoyar un esquema que saca dinero del bolsillo de todos para hacer muy ricos a unos cuantos peces gordos de la empresa y al personal de ventas.
    Si la postura es “no le vamos a dar todo al gobierno”, creo que una forma razonable sería darle al gobierno el derecho de usar los entregables como quiera, pero permitir que los componentes no clasificados y sus derivados se vendan libremente al sector privado.

• La ley exige que el CIO de cada agencia elabore una política dentro de los 180 días posteriores a su entrada en vigor, y que esa política garantice que el código desarrollado a medida se ajuste a las mejores prácticas, además de definir procedimientos para publicar los metadatos del código a medida y procedimientos estándar de reporte.
  En la nueva ley, los metadatos incluyen si el código a medida fue desarrollado por contrato, si fue compartido en un repositorio, el número de contrato y un enlace al repositorio donde se compartió el código.
  Lamentablemente, no parece ser una ley que exija a las agencias convertir el código en open source público, sino solo compartirlo entre agencias. Lo único que debe compartirse públicamente son los “metadatos”. El texto completo del proyecto está en https://www.congress.gov/bill/118th-congress/house-bill/9566...

  • Es un buen primer paso. El siguiente probablemente sea compartirlo con gobiernos estatales, gobiernos locales y universidades. El compartir públicamente distribuye muchas responsabilidades de TI que hoy no existen.
  • Solo con el título publicado, eso ya parece bastante claro.
  • Cuando aparece la expresión “mejores prácticas”, lo primero que hago es sospechar. Es muy probable que fomente aún más el cargo cult burocrático.
  • La mayoría de los contratos del DOE, es decir, los contratos que el gobierno firma con universidades o consorcios que operan laboratorios, suelen decir algo como: “si no se puede demostrar que este código fuente tiene potencial comercial o valor SBIR, puede mantenerse privado o publicarse como open source. Pero no GPL”.
    Hay excepciones, pero también existía la lógica de que otros contratistas debían conservar la capacidad de modificar el código fuente y, del mismo modo, no publicarlo. Supongo que probablemente por el ámbito de defensa.
    Para mantenerlo privado por motivos económicos, el estándar era alto, pero siempre era posible mantenerlo privado por cualquier otro motivo. DOE Code es un programa que rastrea software open source y normalmente se gestiona mediante organizaciones de GitHub. OSTI es la oficina que rastrea toda la propiedad intelectual y la investigación.
  • Algunos, como ZFSOnLinux, ya se comparten públicamente. El repositorio ahora se convirtió en el repositorio de OpenZFS y mejoró la vida de muchas personas. También hizo la mía más fácil.
    El modelo de desarrollo open source también benefició a LLNL, que terminó con una base de código mucho mejor que la que habría obtenido desarrollándola en solitario.
    También hay cosas que ya son públicas, como NASA IKOS: https://github.com/NASA-SW-VnV/ikos
    Este proyecto recibe mucha menos atención de terceros de la que debería. Si pudiera evolucionar hasta convertirse en un analizador estático sólido de propósito general que maneje multithreading, ayudaría a mejorar muchos otros proyectos.

• Alguna vez impulsé un modelo open source completo con la idea de que “si se financia con presupuesto público, el público debería ver los resultados de ese dinero”: https://web.archive.org/web/20200920095030/http://oss4gov.or...
  Creía que el valor predeterminado del software gubernamental debía ser open source, salvo excepciones aprobadas a nivel ministerial. Aunque en ese momento era joven e ingenuo.

  • No creo que eso sea tan polémico. El gobierno del Reino Unido lo ve de forma similar: https://www.gov.uk/service-manual/technology/making-source-c...
  • Trabajé durante años en una contratista militar, y mucha gente cree que, si el contribuyente lo paga y el software no es clasificado, debería ser open source.
    Ghidra es un buen ejemplo, y que este software pasara a ser gratuito fue un gran beneficio para la comunidad de seguridad.
  • La FSFE también comparte la misma idea al otro lado del Atlántico: https://publiccode.eu/en/
  • No eras ingenuo; estabas adelantado a tu tiempo. El progreso es un trabajo duro y una maratón.

• Nosotros creamos software open source e intentamos que las agencias gubernamentales lo adopten o lo usen, pero sorprende el nivel al que estas agencias parecen tener alergia al open source.
  Algunas prefieren construirlo ellas mismas con métodos legacy, como cargas de CSV o parsers rotos, antes que usar código de otros, y de paso crean los bugs y fallas predecibles.
  Incluso al responder a solicitudes de propuestas, la opción open source recibe un escrutinio más fuerte que los sistemas cerrados. Si es público, tienes que demostrar que eso es bueno; si es cerrado, el proveedor puede decir “sí, es perfecto” y la agencia lo acepta. Da la sensación de que las agencias y su personal no quieren asumir ninguna responsabilidad. Aun así, nunca he visto a alguien perder un puesto gubernamental por incompetencia.

  • En términos generales, es proteccionismo laboral, y a nivel individual es una estructura que incentiva a convertirse en experto de la materia sobre tu propia base de código para usarla como palanca de ascenso. Por lo general, las agencias no se ven entre sí como parte del mismo equipo. Pueden ser muy competitivas cuando hacen lobby ante el Congreso para conseguir recursos para su propia agencia.
    Trabajo en el gobierno y lo he vivido directamente. La cultura es muy tóxica y está rota. Tengo curiosidad por ver qué cambios propondrán Elon y el equipo de Trump.
  • En el open source no hay a quién responsabilizar. Con software cerrado, cuando algo sale mal hay alguien a quien señalar con el dedo.

• El Departamento de Defensa de EE. UU. tiene una FAQ sobre software de código abierto: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx y https://github.com/risacher/DoD-OSS-FAQ
  Esta versión fue publicada en GitHub como un experimento de herramienta colaborativa para la participación pública en documentos de política gubernamental, y se indica que personal militar y civil, contratistas y ciudadanos pueden enviar propuestas de cambios o agregados mediante pull requests
  Video de 2010: https://www.youtube.com/watch?v=WWt0YiXcEkE
  Dan Risacher, de la oficina del CIO del DoD, y el experto en seguridad de código abierto David A. Wheeler explican la historia y el impacto de un memorando reciente del DoD que aclaró la postura de que el Departamento de Defensa considera el código abierto como una forma viable de software comercial
  Material de 2024: https://openssf.org/press-release/2024/10/29/openssf-expands...
  La OpenSSF de la Linux Foundation dijo que reconoce la necesidad de capacitación en seguridad y, según David A. Wheeler, director de seguridad de la cadena de suministro de código abierto de OpenSSF, más de 25,000 personas se han inscrito en estos materiales de capacitación desde el inicio del curso

• La intención es buena, pero en la práctica no creo que pase mucho más que los posibles competidores del contratista 1 acorten la brecha o ataquen basándose en la calidad del código de contratos existentes. Leer código es más difícil que escribirlo

  • Si los posibles competidores acortan la brecha, para el gobierno eso significa más competencia y menores costos
    Si atacan basándose en la calidad del código de contratos existentes, eso es code review y, de una u otra forma, lleva a mejorar la calidad del código. No veo cuál es el problema aquí

• Es algo excelente. Recuerdo haber sufrido por no poder leer código incluso dentro de la misma organización. Este tipo de cambio parece que les facilitará el trabajo a quienes crean modelos mentales descendentes

• En general, todo lo pagado con dinero de los contribuyentes debería ser público. Public Monies Public Goods debería ser el principio básico absoluto

  • Ya existen reglas así, pero el único organismo que las toma en serio es el DoD. Ejemplos son BRL-CAD y FalconView
    Eso no impide que contratistas inmorales le pongan copyright al código y cobren licencias. Así es la mayor parte del código del DoE, con excepciones como NWCHEM. Siempre me pregunté por qué eso no terminó en demandas; probablemente porque a nadie le importa demasiado
  • Es interesante que algunos gobiernos locales pongan copyright a sus propias leyes para que otros gobiernos locales no puedan copiarlas sin pagar
    Por un lado, entiendo que vean a otras regiones como aprovechándose gratis del sistema de ordenanzas financiado por los contribuyentes de esa localidad. Más aún si esa ley se aplica principalmente al gobierno local de la zona. Por otro lado, se siente raro que las leyes estén restringidas por copyright
  • No estoy de acuerdo. Por China. El gobierno de EE. UU. debe mantener su código en privado, incluso el código basura de contratistas absurdamente caros
  • En el caso del software, no estoy de acuerdo
  • ¿Propones hacer público todo, desde material clasificado hasta memorandos de oficina y registros de personal? Eso no va a ocurrir
    Cuando contratas a alguien para hacer un trabajo en tu casa, también hay que pensar qué exactamente pasas a poseer además del resultado final

• Es una gran dirección. Trabajando con equipos gubernamentales, vi lugares donde este enfoque se presentaba como práctica recomendada: https://www.forgov.qld.gov.au/information-and-communication-...
  Sin embargo, en muchos casos todavía hace falta el paso de convertirlo en un requisito legal para que esa recomendación realmente se siga. Especialmente en los servicios públicos, donde es común que haya personas que nunca participaron en una comunidad open source
  Como otros señalaron, el presupuesto público debe traducirse en beneficio público, y el open source es una buena forma de ampliar ese beneficio

• Hay una frase que dice: “La nueva ley no se aplica a código clasificado, sistemas de seguridad nacional ni código que, al compartirse, suponga riesgos para la privacidad”
  ¿Qué clase de código podría suponer un riesgo para la privacidad si se comparte? Suena como si el código y los datos estuvieran mezclados de una forma bastante mala

  • No hay un riesgo real, pero da una buena excusa para no publicarlo. Empresas y agencias gubernamentales han rechazado solicitudes de acceso a información sobre documentación técnica por motivos de protección de datos personales. Decían cosas como “se aplica a sistemas que procesan datos personales” o “conocer el funcionamiento interno del sistema aumentaría la probabilidad de que el sistema sea comprometido”
    Los contratistas gubernamentales admiten de buen grado, entre líneas, que su código es pésimo y que en general depende de la seguridad por oscuridad. La comisión de información también les dio la razón algunas veces
  • El código lo suficientemente personalizado acaba teniendo funcionalidades que revelan mucha información sobre la tarea objetivo
    Por ejemplo, basta pensar qué podrías ver en fórmulas de Excel
  • No hay diferencia entre ambas cosas