From 2d185ff65cf0c1d9ca44a91f81a37f6d7523ce70 Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 8 May 2025 14:41:18 -0400 Subject: [PATCH 1/7] Added inventory-code.md v1 (removed hidden button) --- content/guidance/inventory-code.md | 170 ++++++++++++++++++++++++++++- 1 file changed, 169 insertions(+), 1 deletion(-) diff --git a/content/guidance/inventory-code.md b/content/guidance/inventory-code.md index ca78d8fe..ec3f437b 100644 --- a/content/guidance/inventory-code.md +++ b/content/guidance/inventory-code.md @@ -13,4 +13,172 @@ sidenav: true sticky_sidenav: true --- -Creating your enterprise code inventory +

Creating your enterprise code inventory

+

Overview

+

+ Section + 7.2 + and 7.3 of the Source Code Policy require agencies to provide an inventory of their 'custom-developed code' to support government-wide reuse and make Federal open source code easier to find. +

+

+ Using these inventories, Code.gov will provide a platform to search federally funded open source software and software available for government-wide reuse. +

+

Publishing Your Agency's Inventory

+

+ Agencies are required to publish their inventories using a standard metadata schema - a JSON file that they'll make available on their agency websites. Agencies are strongly encouraged to use version 2.0.0 of the schema, which is described below. This version includes revisions that make your inventory much more useful and intuitive. +

+

+ Agencies should make the "code.json" available in the root folder of their website (e.g., https://www.agency.gov/code.json). Code.gov will then retrieve these JSON files daily and compile them. +

+

Metadata Schema version 2.0.0

+

+ The schema fields and definitions are listed below. + + Here is version 2.0.0 of the metadata schema file in JSON format + with parent/child relationships. +

+

Agency code.json file location and contents:

+
    +
  • code.json must live in the root directory of your agency’s website.
    • +
  • + code.json must include a single object represented as JSON, with key-value pairs according to the list below. +
    • +
+
+ +

Source Code Considerations for AI R&D Models

+

+ Consistent with the + Executive Order on Maintaining American Leadership in Artificial Intelligence (EO 13859), agencies are directed to improve source code inventory documentation (i.e., agency code.json) + to enable discovery and usability of source code AI models. +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameTags
Data TypeArray
Definition + An array of keywords that will be helpful in discovering and searching for the release. +
RequiredAlways
AI R&D Guidance + Agencies shall include the keyword of usg-artificial-intelligence for all source code determined to support AI R&D. Other keywords can be developed and used as appropriate and coordinated with standard data tagging available on + resources.data.gov. +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameContact
Data TypeObject
DefinitionPoint of contact information for the release.
RequiredAlways
AI R&D Guidance + Be sure to identify and include domain experts and their contact information who can discuss the model with interested AI researchers. If not the same as the domain expert, Agencies shall also identify an expert and their contact information who can discuss restrictions or controls on the model. +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameexemptionText
Data TypeString or Null
Definition + If an exemption is listed in the usageType field, this field should include a one or two sentence justification for the exemption used. +
RequiredNo
AI R&D Guidance + Agencies shall describe how researchers may be able to access + governmentWideReuse or exempt data. +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Field NamerelatedCode
Data TypeArray
Definition + An array of affiliated government repositories that may be a part of the same project. For example, relatedCode for code-gov-front-end would include code-gov-api and code-gov-client. +
RequiredNo
AI R&D GuidanceAgencies shall describe related models and code.
+ +

Example code.json file

+

+ Here are some + good metadata examples + for reference when creating your agency code.json file. +

+

+ You can find previous schema revisions in + our changelog. +

+
From 7ac51085f5cb96f850b2ca9ea795d0258f1e90f8 Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 8 May 2025 15:57:59 -0400 Subject: [PATCH 2/7] Added procurement.md markdown version --- content/guidance/procurement.md | 132 +++++++++++++++++++++++++++++++- 1 file changed, 131 insertions(+), 1 deletion(-) diff --git a/content/guidance/procurement.md b/content/guidance/procurement.md index f81942c4..8cb883dc 100644 --- a/content/guidance/procurement.md +++ b/content/guidance/procurement.md @@ -13,4 +13,134 @@ sidenav: true sticky_sidenav: true --- -Agency Compliance + +# Building and Buying Custom Software + +Section 3.1 of the Source Code Policy requires that: + +> In meeting their software needs, covered agencies must conduct [a] three-step analysis […] intended to leverage existing solutions – consistent with principles of category management and shared services – and suitable commercial solutions, while mitigating unnecessary spending on custom-developed software solutions. + +### The three steps are: +1. Conduct Strategic Analysis and Analyze Alternatives; +2. Consider Existing Commercial Solutions; and +3. Consider Custom Development + +Below are tips that your agency can use to apply these steps effectively. + +## Step 1: Conduct Strategic Analysis and Analyze Alternatives + +> Step 1 (Conduct Strategic Analysis and Analyze Alternatives): Each agency must conduct research and analysis prior to initiating any technology acquisition or custom code development. The strategic analysis should consider not only agency mission and operational needs, but also external public initiatives and interagency initiatives such as Cross-Agency Priority Goals. Having conducted the strategic analysis, agencies shall then conduct an alternatives analysis, evaluating whether to use an existing Federal software solution or to acquire or develop a new software solution. The alternatives analysis shall give preference to the use of an existing Federal software solution + +The purpose of Step 1 is to ensure that your agency – not just your acquisition team, but also your technology team, program management team, and leadership, among others – has a complete strategic view of what offerings exist before determining that an acquisition is in fact required. + +Further, Step 1 is meant to ensure that agencies do market research to discover what Federal and non-Federal solutions are already available before buying or building software. + +### Things to consider during Step 1: + +

+ Consult your agency's mission statement to broaden your strategy beyond the immediate project requirements. + As required in the policy, also consider relevant "external public initiatives and interagency initiatives such as Cross-Agency Priority Goals" for the same reason. + Review OFPP memorandum M-16-12 "Improving the Acquisition and Management of Common Information Technology: Software Licensing" and consult with your agency's appointed Software Manager. +

+ +## Step 2: Consider Existing Commercial Solutions + +> Step 2 (Consider Existing Commercial Solutions): If an agency's alternatives analysis concludes that existing Federal software solutions cannot efficiently and effectively meet the needs of the agency, the agency must explore whether its requirements can be satisfied with an appropriate commercially-available solution + +As with Step 1, the purpose of Step 2 is to develop your agency's strategic view of the marketplace prior to initiating an acquisition. Agencies should remember in surveying the marketplace of commercial solutions that many commercial solutions can be extended through custom code to satisfy your requirements entirely (see discussion of hybrid solutions below). + +### Things to consider during Step 2: + +

Open Source Software may meet the definition of "commercial computer software" and may also be included in a commercial solution in accordance with FAR 2.101(b). For example, Open Source Software that "[h]as been offered for sale, lease, or license to the general public" may be considered "commercial" for purposes of a federal acquisition. Be sure to consult your agency's policy regarding Open Source Software acquisitions. + +It is important to apply category management principles, which give preference to best-in-class solutions, in your analysis. + +Agencies must use Category Management Policy 16-1 for this analysis.

+ +## Step 3: Consider Custom Development + +> Step 3 (Consider Custom Development): If an agency's alternatives analysis concludes that an existing Federal software solution or commercial solution cannot adequately satisfy its needs, the agency may consider procuring custom-developed code in whole or in conjunction with existing Federal or commercial code. When commissioning new custom-developed software, agencies must consider the value of publishing custom code as OSS and negotiate data rights reflective of its value-consideration. Agencies must also obtain sufficient rights to fulfill this policy's objectives related to Government-wide code reuse and the open source pilot program. + +Having determined that no Federal or commercial solutions exist that completely meet their needs, agencies may build or buy custom software. + +In doing so, the most important thing to remember is that the Federal Source Code Policy requires agencies to "acquire and enforce rights sufficient to enable Government-wide reuse" when contracting for the custom development of code. With respect to release, the Federal Source Code Policy's Pilot Program requires agencies to release at least 20 percent of new custom-developed code each year as open source software. While agencies are encouraged to release a greater percentage of code, if doing so is beneficial to the government, agencies are not required to release more than 20 percent of code. + +Accordingly, consider the following during the acquisition lifecycle: + +## Presolicitation + +Once your agency has determined that custom code development is necessary, it is important to actively communicate that government reuse and open source, as appropriate, are core to the requirements of your project from the outset. Whether during an RFI or industry day, relay to potential vendors early and often that your agency intends to receive appropriate rights for government re-use and/or open source. + +Your acquisition strategy should allow the agency to determine which software modules or components should be built separately. In the spirit of modular development, the technical and licensing approach can be tackled per component to maximize public benefit. + +## Solicitation, Negotiation, and Award + +### Government code reuse + +Agencies must obtain unlimited rights to all custom-developed code first produced in the performance of the contract. + +The Federal Acquisition Regulation's (FAR) General Rights in Data clause – FAR 52.227-14 – provides for "unlimited rights" in data first produced in the performance of the contract, which generally covers custom-developed code. This includes both the right to share the custom-developed code with other agencies and, as explained below, the right to publicly release the code for reuse subject to restrictions in an open source license However, if an agency is not seeking, or able, to obtain the rights to publicly release the code, the rights license should still provide, at a minimum, the Government's rights to share the custom-developed code with other agencies. Rights for government reuse outside the unlimited rights clause may be accomplished by using the limited rights notice under Alternate II of the 52.227-14 clause. In enforcing such data rights, agencies should ensure that deliverables do not contain markings that limit rights of distribution within the contracting agency or bureau only. + +A number of agencies have already developed supplementary contract clauses to further address and clarify the government's rights. Agencies, in particular those visiting this issue for the first time, can benefit from comparing their practices and contract clauses with others and standardizing where possible. + +As one example, the Department of Defense has developed a license rights clause for noncommercial computer software where the parties look to the source of funds used to develop computer software as the basis for establishing associated reuse rights by the government. + +If the government exclusively funds the development of the code, the clause would give the agency an unlimited rights license in noncommercial technical data, noncommercial computer software and noncommercial computer software documentation. + +If the development is exclusively funded by the contractor, the agency usually acquires a restricted rights license in noncommercial computer software. + +The DFARS 252.227-7013 and -7014 clauses specifically provide for this determination to be made at the lowest practicable portion of software, which allows the Department of Defense to assert reuse rights in a hybrid solution involving both commercial and custom code. + +If an agency is interested in taking advantage of the DFARS language, it could consider a deviation in accordance with FAR Subpart 1.4 to follow the relevant Defense Federal Acquisition Regulation Supplement. + +As a best practice, consider expressly asserting in the solicitation (and resulting contract) that unlimited rights attach to all code furnished in the performance of the contract, unless the parties expressly agree otherwise in the contract. This practice can help to avoid disputes after contract award as to whether triggers in the standard clauses (e.g., "first produced in the performance of the contract" or "developed exclusively with government funds") have been met. + +### Open source software + +If applicable, identify the requirement for open-source software in the solicitation. If you have a preferred open source license, specify it in the solicitation. + +The FAR's unlimited rights clause establishes the basic right for the Government to publish custom-developed code first produced in the performance of the contract publicly for reuse subject to restrictions in an open source license. + +If an agency intends to publish software as open source, it should not include Alternate IV to the clause, which would provide the contractor a blanket permission to assert copyright. A contractor's request for permission to assert copyright under FAR 52.227-14 should be denied in instances where the agency intends to publish code as OSS. A contractor, if given such permission, could assert its copyright interests against third parties interested in using and contributing to custom-developed code released by the Government. In all instances, even where a contractor is given permission to assert copyright, the Government must preserve the right to share code with other agencies and those contractors retained by the agencies to modify, refresh, or otherwise use the code by or on behalf of the Government. + +### Other considerations +#### Identify all deliverables and asserted restrictions + +

For commercial data/software, the contractor needs to provide a copy of the proposed commercial license agreement to the contracting officer prior to contracting;

+ +

For noncommercial data/software, the contractor needs to identify prior to contracting, often in proposals, the data that will be delivered with restrictions (FAR 27.404-3b; DFARS 252.227-7017);

+ +

The solicitation and contract must specify delivery of the data package and source code. The agency should include additional data requirements clauses in the FAR to permit flexibility in ordering additional deliverables.

+ +#### Make sure that your contractor holds to the software and data rights requirements, and require the contractor to provide all licenses for software dependencies as part of the deliverables + +

Ensure that all deliverables are appropriately marked with the applicable restrictive legends;

+

If contractor omits restrictive markings, data or software delivered without restrictive markings, the Government is deemed to have received unlimited rights in the deliverable (the Government may allow the contractor to correct the error according to certain procedures);

+

If delivery is made with restrictive markings that are not authorized by the contract, the marking is characterized as nonconforming (contract contains procedure for correcting nonconforming markings);

+

Agencies should also require delivery of the source code and other relevant materials and associated documents, which is specified in the contract requirements.

+ +#### Hybrid solutions + +Appropriately, agencies often contract for the delivery of solutions that are a hybrid of commercial and custom-developed code. Hybrid solutions entail a mix of rights; agencies may have unlimited rights to custom-developed parts of the solution but restricted rights to the rest. Because of this added complexity, contracts for hybrid solutions warrant closer attention to make sure that unlimited rights are being secured for the custom code and that the code is actually delivered. + +Agencies should not give up unlimited rights to government reuse of the segment of the solution involving custom code unless an appropriate basis is established for doing so. One such basis may exist if the custom code qualifies as a minor modification to commercial computer software, which by law and regulation is considered a commercial item in which the government takes restricted rights. Another such basis may be the negotiation of Government Purpose Rights, as defined in the DFARS. + +### Contract Administration + +After contract award, agencies should watch for unauthorized or incorrect markings that seek to limit the Government's rights, such as by limiting reuse rights to the acquiring agency, and agencies should take advantage of the procedures provided in FAR 27.404-5 to cancel such markings. + +## Glossary +
+
Data
+
+ "Data" means recorded information, regardless of form or the media on which it may be recorded. The term includes technical data and computer software. The term does not include information incidental to contract administration, such as financial, administrative, cost or pricing, or management information. [FAR 52.227-14 (a)] +
+
Computer software
+
"Computer software" means (i) Computer programs that comprise a series of instructions, rules, routines, or statements, regardless of the media in which recorded, that allow or cause a computer to perform a specific operation or series of operations; and (ii) Recorded information comprising source code listings, design details, algorithms, processes, flow charts, formulas, and related material that would enable the computer program to be produced, created, or compiled. Does not include computer databases or computer software documentation. [FAR 52.227-14 (a)]

+"Computer software" means computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae, and related material that would enable the software to be reproduced, recreated, or recompiled. Computer software does not include computer databases or computer software documentation. [DFARS 252.227-7014(a)(4)]
+ +
Unlimited rights
+
"Unlimited rights" means the right of the Government to use, disclose, reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, in any manner and for any purpose, and to have or permit others to do so. [FAR 52.227-14 (a)]

"Unlimited rights" means rights to use, modify, reproduce, perform, display, release, or disclose technical data in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so. [DFARS 252.227-7014(a)(16)]
+
Government purpose rights
+
"Government purpose" means any activity in which the United States Government is a party, including cooperative agreements with international or multi-national defense organizations or sales or transfers by the United States Government to foreign governments or international organizations. Government purposes include competitive procurement, but do not include the rights to use, modify, reproduce, release, perform, display, or disclose computer software or computer software documentation for commercial purposes or authorize others to do so. "Government purpose rights" means the rights to— (i) Use, modify, reproduce, release, perform, display, or disclose computer software or computer software documentation within the Government without restriction; and (ii) Release or disclose computer software or computer software documentation outside the Government and authorize persons to whom release or disclosure has been made to use, modify, reproduce, release, perform, display, or disclose the software or documentation for United States government purposes.[DFARS 252.227-7014(a)(11-12)]
+
From b6baa9427bdaadf9df69bb8910906ba8cd390a21 Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 8 May 2025 17:05:43 -0400 Subject: [PATCH 3/7] Fixed Un-html-ify the inventory-code.md --- content/guidance/inventory-code.md | 53 +++++++++++++----------------- 1 file changed, 22 insertions(+), 31 deletions(-) diff --git a/content/guidance/inventory-code.md b/content/guidance/inventory-code.md index ec3f437b..bb3634b1 100644 --- a/content/guidance/inventory-code.md +++ b/content/guidance/inventory-code.md @@ -13,8 +13,8 @@ sidenav: true sticky_sidenav: true --- -

Creating your enterprise code inventory

-

Overview

+# Creating your enterprise code inventory +## Overview

Section 7.2 @@ -23,36 +23,36 @@ sticky_sidenav: true

Using these inventories, Code.gov will provide a platform to search federally funded open source software and software available for government-wide reuse.

-

Publishing Your Agency's Inventory

+ +## Publishing Your Agency's Inventory

Agencies are required to publish their inventories using a standard metadata schema - a JSON file that they'll make available on their agency websites. Agencies are strongly encouraged to use version 2.0.0 of the schema, which is described below. This version includes revisions that make your inventory much more useful and intuitive.

Agencies should make the "code.json" available in the root folder of their website (e.g., https://www.agency.gov/code.json). Code.gov will then retrieve these JSON files daily and compile them.

-

Metadata Schema version 2.0.0

+ +## [Metadata Schema version 2.0.0](#metadataschema)

The schema fields and definitions are listed below. Here is version 2.0.0 of the metadata schema file in JSON format with parent/child relationships.

-

Agency code.json file location and contents:

-
    -
  • code.json must live in the root directory of your agency’s website.
    • +### [Agency code.json file location and contents:](#filelocationandcontents) +
      +
    • code.json must live in the root directory of your agency’s website.
    • - code.json must include a single object represented as JSON, with key-value pairs according to the list below. + code.json must include a single object represented as JSON, with key-value pairs according to the list below.
    -
-

Source Code Considerations for AI R&D Models

+## [Source Code Considerations for AI R&D Models](#data-assets-ai")

Consistent with the - Executive Order on Maintaining American Leadership in Artificial Intelligence (EO 13859), agencies are directed to improve source code inventory documentation (i.e., agency code.json) - to enable discovery and usability of source code AI models. + Executive Order on Maintaining American Leadership in Artificial Intelligence (EO 13859), agencies are directed to improve source code inventory documentation (i.e., agency code.json) to enable discovery and usability of source code AI models.

- +
@@ -83,7 +83,7 @@ sticky_sidenav: true
Field Name
- +
@@ -105,13 +105,11 @@ sticky_sidenav: true - +
Field Name
AI R&D Guidance - Be sure to identify and include domain experts and their contact information who can discuss the model with interested AI researchers. If not the same as the domain expert, Agencies shall also identify an expert and their contact information who can discuss restrictions or controls on the model. - Be sure to identify and include domain experts and their contact information who can discuss the model with interested AI researchers. If not the same as the domain expert, Agencies shall also identify an expert and their contact information who can discuss restrictions or controls on the model.
- +
@@ -125,9 +123,7 @@ sticky_sidenav: true - + @@ -135,14 +131,11 @@ sticky_sidenav: true - +
Field Name
Definition - If an exemption is listed in the usageType field, this field should include a one or two sentence justification for the exemption used. - If an exemption is listed in the usageType field, this field should include a one or two sentence justification for the exemption used.
Required
AI R&D Guidance - Agencies shall describe how researchers may be able to access - governmentWideReuse or exempt data. - Agencies shall describe how researchers may be able to access governmentWideReuse or exempt data.
- +
@@ -156,9 +149,7 @@ sticky_sidenav: true - + @@ -170,8 +161,8 @@ sticky_sidenav: true
Field Name
Definition - An array of affiliated government repositories that may be a part of the same project. For example, relatedCode for code-gov-front-end would include code-gov-api and code-gov-client. - An array of affiliated government repositories that may be a part of the same project. For example, relatedCode for code-gov-front-end would include code-gov-api and code-gov-client.
Required
- -

Example code.json file

+ +## [Example code.json file](#how-to-inventory-b)

Here are some good metadata examples From 1eff57aafa93fb14a4dbb0f00574730c5534e8a5 Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 8 May 2025 17:08:54 -0400 Subject: [PATCH 4/7] Fixed broken non-linked headings; remove divs --- content/guidance/inventory-code.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/guidance/inventory-code.md b/content/guidance/inventory-code.md index bb3634b1..b167b24c 100644 --- a/content/guidance/inventory-code.md +++ b/content/guidance/inventory-code.md @@ -32,14 +32,15 @@ sticky_sidenav: true Agencies should make the "code.json" available in the root folder of their website (e.g., https://www.agency.gov/code.json). Code.gov will then retrieve these JSON files daily and compile them.

-## [Metadata Schema version 2.0.0](#metadataschema) +## Metadata Schema version 2.0.0

The schema fields and definitions are listed below. Here is version 2.0.0 of the metadata schema file in JSON format with parent/child relationships.

-### [Agency code.json file location and contents:](#filelocationandcontents) + +### Agency code.json file location and contents:
  • code.json must live in the root directory of your agency’s website.
  • @@ -47,7 +48,7 @@ sticky_sidenav: true
-## [Source Code Considerations for AI R&D Models](#data-assets-ai") +## Source Code Considerations for AI R&D Models

Consistent with the Executive Order on Maintaining American Leadership in Artificial Intelligence (EO 13859), agencies are directed to improve source code inventory documentation (i.e., agency code.json) to enable discovery and usability of source code AI models. @@ -162,7 +163,7 @@ sticky_sidenav: true -## [Example code.json file](#how-to-inventory-b) +## Example code.json file

Here are some good metadata examples @@ -172,4 +173,3 @@ sticky_sidenav: true You can find previous schema revisions in our changelog.

-
From 24d7e89038d44c5d6de10dd88ca3b7365bd0de3f Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 15 May 2025 14:35:20 -0400 Subject: [PATCH 5/7] Fixed as per feedback in #4 --- content/guidance/inventory-code.md | 60 ++++++++++++------------------ content/guidance/procurement.md | 34 ++++++++--------- 2 files changed, 41 insertions(+), 53 deletions(-) diff --git a/content/guidance/inventory-code.md b/content/guidance/inventory-code.md index b167b24c..e1d80466 100644 --- a/content/guidance/inventory-code.md +++ b/content/guidance/inventory-code.md @@ -13,32 +13,26 @@ sidenav: true sticky_sidenav: true --- -# Creating your enterprise code inventory -## Overview -

- Section - 7.2 - and 7.3 of the Source Code Policy require agencies to provide an inventory of their 'custom-developed code' to support government-wide reuse and make Federal open source code easier to find. -

-

- Using these inventories, Code.gov will provide a platform to search federally funded open source software and software available for government-wide reuse. -

+# Overview + +Section + 7.2 + and 7.3 of the Source Code Policy require agencies to provide an inventory of their 'custom-developed code' to support government-wide reuse and make Federal open source code easier to find. + +Using these inventories, Code.gov will provide a platform to search federally funded open source software and software available for government-wide reuse. ## Publishing Your Agency's Inventory -

- Agencies are required to publish their inventories using a standard metadata schema - a JSON file that they'll make available on their agency websites. Agencies are strongly encouraged to use version 2.0.0 of the schema, which is described below. This version includes revisions that make your inventory much more useful and intuitive. -

-

- Agencies should make the "code.json" available in the root folder of their website (e.g., https://www.agency.gov/code.json). Code.gov will then retrieve these JSON files daily and compile them. -

+ +Agencies are required to publish their inventories using a standard metadata schema - a JSON file that they'll make available on their agency websites. Agencies are strongly encouraged to use version 2.0.0 of the schema, which is described below. This version includes revisions that make your inventory much more useful and intuitive. + +Agencies should make the `code.json` available in the root folder of their website (e.g., https://www.agency.gov/code.json). Code.gov will then retrieve these JSON files daily and compile them. ## Metadata Schema version 2.0.0 -

- The schema fields and definitions are listed below. - - Here is version 2.0.0 of the metadata schema file in JSON format - with parent/child relationships. -

+ +The schema fields and definitions are listed below. + +Here is version 2.0.0 of the metadata schema file in JSON format +with parent/child relationships. ### Agency code.json file location and contents:
    @@ -49,10 +43,9 @@ sticky_sidenav: true
## Source Code Considerations for AI R&D Models -

- Consistent with the - Executive Order on Maintaining American Leadership in Artificial Intelligence (EO 13859), agencies are directed to improve source code inventory documentation (i.e., agency code.json) to enable discovery and usability of source code AI models. -

+Consistent with the +Executive Order on Maintaining American Leadership in Artificial Intelligence (EO 13859), agencies are directed to improve source code inventory documentation (i.e., agency code.json) to enable discovery and usability of source code AI models. + @@ -106,7 +99,7 @@ sticky_sidenav: true - +
AI R&D GuidanceBe sure to identify and include domain experts and their contact information who can discuss the model with interested AI researchers. If not the same as the domain expert, Agencies shall also identify an expert and their contact information who can discuss restrictions or controls on the model.Be sure to identify and include domain experts and their contact information who can discuss the model with interested AI researchers. If not the same as the domain expert, Agencies shall also identify an expert and their contact information who can discuss restrictions or controls on the model.
@@ -164,12 +157,7 @@ sticky_sidenav: true ## Example code.json file -

- Here are some - good metadata examples - for reference when creating your agency code.json file. -

-

- You can find previous schema revisions in - our changelog. -

+ +Here are some [good metadata examples](https://github.com/GSA/code-gov/blob/master/docs/metadata_examples.md) for reference when creating your agency code.json file. + +You can find previous schema revisions in [our changelog](https://github.com/GSA/code-gov-data/blob/master/CHANGELOG.md) diff --git a/content/guidance/procurement.md b/content/guidance/procurement.md index 8cb883dc..ec9dee73 100644 --- a/content/guidance/procurement.md +++ b/content/guidance/procurement.md @@ -13,9 +13,6 @@ sidenav: true sticky_sidenav: true --- - -# Building and Buying Custom Software - Section 3.1 of the Source Code Policy requires that: > In meeting their software needs, covered agencies must conduct [a] three-step analysis […] intended to leverage existing solutions – consistent with principles of category management and shared services – and suitable commercial solutions, while mitigating unnecessary spending on custom-developed software solutions. @@ -37,11 +34,11 @@ Further, Step 1 is meant to ensure that agencies do market research to discover ### Things to consider during Step 1: -

- Consult your agency's mission statement to broaden your strategy beyond the immediate project requirements. - As required in the policy, also consider relevant "external public initiatives and interagency initiatives such as Cross-Agency Priority Goals" for the same reason. - Review OFPP memorandum M-16-12 "Improving the Acquisition and Management of Common Information Technology: Software Licensing" and consult with your agency's appointed Software Manager. -

+Consult your agency's mission statement to broaden your strategy beyond the immediate project requirements. + +As required in the policy, also consider relevant "external public initiatives and interagency initiatives such as Cross-Agency Priority Goals" for the same reason. + +Review OFPP memorandum M-16-12 "Improving the Acquisition and Management of Common Information Technology: Software Licensing" and consult with your agency's appointed Software Manager. ## Step 2: Consider Existing Commercial Solutions @@ -51,11 +48,11 @@ As with Step 1, the purpose of Step 2 is to develop your agency's strategic view ### Things to consider during Step 2: -

Open Source Software may meet the definition of "commercial computer software" and may also be included in a commercial solution in accordance with FAR 2.101(b). For example, Open Source Software that "[h]as been offered for sale, lease, or license to the general public" may be considered "commercial" for purposes of a federal acquisition. Be sure to consult your agency's policy regarding Open Source Software acquisitions. +Open Source Software may meet the definition of "commercial computer software" and may also be included in a commercial solution in accordance with FAR 2.101(b). For example, Open Source Software that "[h]as been offered for sale, lease, or license to the general public" may be considered "commercial" for purposes of a federal acquisition. Be sure to consult your agency's policy regarding Open Source Software acquisitions. It is important to apply category management principles, which give preference to best-in-class solutions, in your analysis. -Agencies must use Category Management Policy 16-1 for this analysis.

+Agencies must use Category Management Policy 16-1 for this analysis. ## Step 3: Consider Custom Development @@ -106,18 +103,21 @@ If an agency intends to publish software as open source, it should not include A ### Other considerations #### Identify all deliverables and asserted restrictions -

For commercial data/software, the contractor needs to provide a copy of the proposed commercial license agreement to the contracting officer prior to contracting;

+For commercial data/software, the contractor needs to provide a copy of the proposed commercial license agreement to the contracting officer prior to contracting; -

For noncommercial data/software, the contractor needs to identify prior to contracting, often in proposals, the data that will be delivered with restrictions (FAR 27.404-3b; DFARS 252.227-7017);

+For noncommercial data/software, the contractor needs to identify prior to contracting, often in proposals, the data that will be delivered with restrictions (FAR 27.404-3b; DFARS 252.227-7017); -

The solicitation and contract must specify delivery of the data package and source code. The agency should include additional data requirements clauses in the FAR to permit flexibility in ordering additional deliverables.

+The solicitation and contract must specify delivery of the data package and source code. The agency should include additional data requirements clauses in the FAR to permit flexibility in ordering additional deliverables. #### Make sure that your contractor holds to the software and data rights requirements, and require the contractor to provide all licenses for software dependencies as part of the deliverables -

Ensure that all deliverables are appropriately marked with the applicable restrictive legends;

-

If contractor omits restrictive markings, data or software delivered without restrictive markings, the Government is deemed to have received unlimited rights in the deliverable (the Government may allow the contractor to correct the error according to certain procedures);

-

If delivery is made with restrictive markings that are not authorized by the contract, the marking is characterized as nonconforming (contract contains procedure for correcting nonconforming markings);

-

Agencies should also require delivery of the source code and other relevant materials and associated documents, which is specified in the contract requirements.

+Ensure that all deliverables are appropriately marked with the applicable restrictive legends; + +If contractor omits restrictive markings, data or software delivered without restrictive markings, the Government is deemed to have received unlimited rights in the deliverable (the Government may allow the contractor to correct the error according to certain procedures); + +If delivery is made with restrictive markings that are not authorized by the contract, the marking is characterized as nonconforming (contract contains procedure for correcting nonconforming markings); + +Agencies should also require delivery of the source code and other relevant materials and associated documents, which is specified in the contract requirements. #### Hybrid solutions From 653798784e5576c07ebcab821e5edf005902ce97 Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 15 May 2025 14:42:52 -0400 Subject: [PATCH 6/7] Fixed the tags --- content/guidance/procurement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/guidance/procurement.md b/content/guidance/procurement.md index ec9dee73..1349e78c 100644 --- a/content/guidance/procurement.md +++ b/content/guidance/procurement.md @@ -32,7 +32,7 @@ The purpose of Step 1 is to ensure that your agency – not just your acquisitio Further, Step 1 is meant to ensure that agencies do market research to discover what Federal and non-Federal solutions are already available before buying or building software. -### Things to consider during Step 1: +### Things to consider during Step 1: Consult your agency's mission statement to broaden your strategy beyond the immediate project requirements. From aa611d1ec686c53c7a73337da7e6a613050b08a2 Mon Sep 17 00:00:00 2001 From: Remy Date: Thu, 15 May 2025 14:46:52 -0400 Subject: [PATCH 7/7] Remove optional metadata text --- content/guidance/inventory-code.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/guidance/inventory-code.md b/content/guidance/inventory-code.md index e1d80466..48b02a04 100644 --- a/content/guidance/inventory-code.md +++ b/content/guidance/inventory-code.md @@ -30,7 +30,6 @@ Agencies should make the `code.json` available in the root folder of their websi ## Metadata Schema version 2.0.0 The schema fields and definitions are listed below. - Here is version 2.0.0 of the metadata schema file in JSON format with parent/child relationships.