Earlier this month, Sen Cruz (R,TX) introduced S 3594, the Source code Harmonization and Reuse in Information Technology (SHARE IT) Act. The bill would require the federal government to “maximize efficiency, minimize duplication, and enhance security and innovation across Federal agencies by requiring the sharing of custom-developed code between agencies”. The bill specifically prohibits the authorization of new funding to support the program.
Definitions
Section 3 of the bill provides the definitions of key terms used in the legislation. Only two of the nine listed terms are fully defined by reference to existing statutory definitions. Key technical terms include:
Purpose of Code Sharing
Section 2(a)(1) of the bill establishes the ‘congressional findings’ that necessitate the crafting and approval of this legislation. After establishing the need for the legislation subsection (b) goes on to outline the purpose of the proposed program; it would include:
Enabling agencies to benefit mutually from the investments of other agencies in custom-developed code,
Promoting technological consistency and interoperability among agencies, thereby facilitating seamless data exchange and system integration,
Fostering a culture of sharing engineering best practices and successful technological innovations among agencies,
Enhancing transparency by making federally funded custom-developed code available for public scrutiny, subject to necessary security considerations, and
Leveraging inter-agency collaboration for better security auditing of the shared codebase, aiming for a more unified and secure technological infrastructure across agencies.
Software Reuse
Within 210-days of the bill’s enactment of the legislation, the head of each agency is required to ensure that:
The custom-developed code of the agency is contained at not less than 1 public or private repository and is accessible to Federal employees,
All software and other key technical components, including documentation, data models, schemas, metadata, and architecture designs, are owned by the agency, and
Metadata for the custom-developed code of the agency publicly accessible.
Section 4(b) delineates the requirements that contracts “for the custom development of software shall acquire and enforce rights sufficient to enable the governmentwide access, execution, and modification of the custom-developed code relating to the software”. This includes requirements that each head of a government agency will ensure that:
Appropriate contract administration and use of best practices to secure the full scope of licenses and rights for the Federal Government of the custom-developed code developed under the contract, to allow for access, execution, and modification by other agencies.
The use of best practices to require and obtain the delivery of the custom-developed code, documentation of the custom-developed code, configuration and artifacts required to develop, build, test, and deploy the custom-developed code, and other associated materials from the developer throughout the development process.
Moving Forward
As I mentioned yesterday, this bill will be considered by the Senate Homeland Security and Governmental Affairs Committee tomorrow. There is one aspect of the bill that could engender opposition (see my Commentary below), but it could easily be revised in tomorrows markup. With that change, I suspect that there would be substantial bipartisan support for the bill. Since the bill is not politically important enough to be considered under the Senate’s time-consuming regular order, it will be important to watch tomorrow's hearing to see if Sen Paul (R,KY) supports the bill. If he opposes the bill, he would be likely to oppose consideration of the bill in the full Senate under the unanimous consent process. With his position as Ranking Member, he could effectively veto adding the provisions of the bill to other bills via the floor amendment process. Even if he supports the bill in Committee, he could still object to consideration of the bill under that process for unrelated political leverage.
Commentary
The biggest problem this bill is going to face moving forward is industry objections to the provisions of §4(a)(2):
(2) all software and other key technical components, including documentation, data models, schemas, metadata, and architecture designs, are owned by the agency.
This paragraph would require that all contracts for software (not restricted to ‘custom code’) going forward would provide for the government ownership of the software, not licensing for use by the vendor. This would be a major change that would be resisted by most (if not all) major software companies. I suspect that if were accepted by vendors (the federal government is a big customer after all) it would come with increased costs and a whole series of legal caveats that are currently covered by licensing agreements and ‘terms of use’ restrictions.
This problem could be solved by substituting the phrase used multiple times in this bill, ‘custom-developed code’ for the opening ‘all software’ in the paragraph. That is, after all, the overall intent of the bill. While there are arguments to be made for changing the ownership structure of software, that is a much larger issue than the relatively minor sharing of custom code in the federal government.