whitehouse / source-code-policy Goto Github PK

Reference: Code Inventories and Discovery – Beginning at Line Number 342

The effective reusability of “anything” parallels what has been learned in the library sciences. Three things are required for effective reuse: (1) a classification scheme for storage and retrieval of content (a Dewey decimal-like structure), (2) artifacts (code) actually designed for reuse, with reuse as an explicit design intent, and (3) a librarian to manage the reuse library.

We suggest that a classification system is vital, and begins with the six interrogatives used to describe “anything” – What, How, Where, Who, When, and Why.

Providing examples of these six interrogatives in the context of Code, the classifications would represent indexing, at the highest level by:

Why – Strategies/Goals
How – Processes/Activities
What – Materials/Things
Who – Roles/Responsibilities
Where – Locations/Geography
When – Events/Triggers

Of course, as is in the Dewey Decimal System, refinement from this initial ontological classification is required.

We suggest that this effort be done prior to any Code Inventory, or at least, parallel to the development of the Code Inventory. This “salad bar” approach to system development is the highest (third level) of enterprise system maturity: Level 1 – Make to Order, Level 2 – Provide from Stock (COTS packages), and Level 3 – Assemble to Order (minimal/or no handcrafting/writing of code). This approach requires a true reuse code inventory ontology that represents the Level 3 desired maturity.

Past efforts in this domain suggest, that no matter how good the code itself is, the classification of the code is key to not having a disorganized and potentially bloated inventory, and being able to locate potential reuse candidates.

An incentive system needs to be designed and implemented that rewards reuse of code. This is not only by “mandate” but by actually providing “rewards/compensation” for actually not writing new code. Today’s programming / agile programming approaches, and the community involved with these approaches, are in conflict with code reuse. As an incentive example, a person/vendor would be paid “X” for reusing code, which in some cases, would be more compensation than writing new code. The cost of new code development and code vetting is extreme in comparison to reuse. We suggest that the incentive system design and implementation also proceeds or parallels the Code Inventory development.

Respectfully:
Samuel (Sam) B Holcman
Pinnacle Business Group, Inc.

[Email comment, received: Monday, 3/21/2016, 4:07pm EDT]

My name is Robert David Steele. I started the Open Source Intelligence (OSINT) revolution in 1988, and because I was not listened to, today we have a secret intelligence community that has wasted $1 trillion (an average of $40 billion a year over 25 years) and that provides, "at best," according to General Tony Zinni, USMC, then Commanding General of the US Central Command engaged in two wars and 12 joint task forces, 4% (FOUR PERCENT) of what a top government decider needs in the way of decision-support. It could also be suggested that because we have failed to make the most of OSINT in support of strategy, policy, acquisition (45% documented waste in the Pentagon), and operations (75% documented waste in Afghanistan, $4 trillion wasted on the basis of 935 now documented lies that the secret intelligence world refused to challenge in public) the USA today is headed toward being a Third World country on the verge of revolution. Put bluntly, the US Government has refused to be serious about "open" since 1988 when I started this revolution, and also refused to be serious about cyber-security since 1994 when I sent the first letter to the White House and NSA was allowed to sabotage security across the US communications and computer industry, with the active complicity of the CEOs of major IT companies.

In 2012 I wrote The Open Source Everything Manifesto: Transparency, Truth, & Trust, subsequently featured in a profile by Nafeez Ahmed in The Guardian that received an unheard of 33,000 shares in three days, now up to 68,000 shares. This book identified over 60 "opens" and set the stage for a a broad global community discussion that has now agreed on nine major open source categories among which Open Software is one of the nine, documented at the P2P Foundation wiki page Category:Open Source Everything. I am now the foremost proponent for Open Source Everything Engineering (OSEE).

Comments on the Source Code initiative and other White House open source / open data / open government dabbling:

01 Too little too late. Lipstick on the pig. The digital innovators are nice people and mean well but everything they are doing is a joke on the margins. They appear terrified of over-stepping their playpen's boundaries. Impacting on $80 billion within a $4 trillion budget is an effectiveness grade of 1% of 1%, at best -- and does nothing for the national economy or the global economy. As Dr. Russell Ackoff (May 2004) has said, "Stop doing the wrong things righter and do the right thing."

02 OMB is incoherent and not paying attention. For example, the Director of OMB does not appear to have received his copy of the Memorandum on the need for an Open Source (Technologies) Agency that the US Postal Service has certified was delivered to the offices of the Vice President, the Secretaries of State and Defense, and the Administrator of the US Agency for International Development as well as the Director. What OMB _should_ be doing is rapidly processing this Memorandum as an inter-agency decision memorandum. The digital innovators are naive and inexperienced. One of them told me that "no new agencies" were desired by the President (whom I am sure he never sees). The very next day OPM announced a new agency to deal with security clearances. The Open Source (Technologies) Agency would be a path-finding and grant-making agency and could easily be managed with as few as 250 growing toward 1,200 at Full Operating Capability. It would lead to the eradication of the 50% waste that is endemic across all US policy domains (not just in government spending, but across the entire US economy) from agriculture to energy to health to housing to security to water.

03 I seek a meeting with the Director of OMB to discuss the two times previously that OMB senior officials have approved an Open Source Agency in principle, and to discuss advancing the Open Source (Technologies) Agency as an immediate Presidential initiative consistent with the Secretary of Defense D3 Innovation Summit objectives, and the President's varied intentions with respect to stabilizing and reconstructing the US economy and society so as to give the young and old and the unemployed hope. There is prior Congressional history -- Congressman Rob Simmons (R-CT-02) and I developed the Smart Nation - Safe Nation Act in one page, and if OMB desires, we can mobilize Congressman Simmons, now outside the Congress, to orchestrate an assured approval from the Republican controlled Congress for this new agency; it can also be, as NSA was, an executive agency funded by DoD under diplomatic auspices for its global engagement role but working intimately with every Cabinet office to achieve impact across all nine Opens in every policy domain.

04 The proposed policies on open source code should be set aside. The new Open Source (Technologies) Agency should become the operational and policy authority, and would both enable massive adoption of open source software and hardware and spectrum enabling true open data, open decision-support, and open governance; and also absolute blockchain cyber-security for all government data and operations. No one in the US Government knows enough to be effective at regulating or promulgating Open Source Code, much less Open Source Everything Engineering (OSEE). All the knowledge needed to get this right and replicate what Vint Cerf did for the Internet is outside the USG. The Director of OMB has an opportunity to lead the creation of the Open Source (Technologies) Agency, and that in turn could become the engine for making the M in OMB a central aspect of how we govern going forward. Hybrid governance is not a concept OMB understands yet, but it could become central to the M in OMB: harnessing the distributed intelligence of the Whole Nation (a phrase Mike Nelson borrowed from me for Al Gore to use in 1994), and bringing together academia, civil society, commerce, government, law enforcement. media, military, and non-government/non-profit in one seamless scalable exascale World Brain that practices holistic analytics conscious of true cost economics at every level across every domain. It's time for OMB to start MANAGING. The Open Source (Technologies) Agency is the engine for going forward.

05 OSEE costs one tenth of the financial cost of legacy approaches with their varied licensing, training, and maintenance fees. It also requires one tenth of the time, one tenth of the manpower, and ultimate yields a hundred-fold increase in inter-operability and scalability. In Europe open source is now standard for governments. At a strategic level OSEE is the only way the Sustainable Development Goals (SDG) can be achieved, in a fraction of the time at a fraction of the cost envisioned by the conventional donor financing and industrial technology approaches, and this in turn translates into making possible the President's call for a reduction of the Pentagon budget by 30% or more, while also empowering diplomacy, commerce, and development.

The time has come for the Director of OMB to think really big thoughts. We can have the Open Source (Technologies) Agency up and running within 30 days from Executive Order, fully-funded by DoD from within its existing budget, and this will translate into a public diplomacy, public relations, public interest, public benefits bonanza I would be glad to explain personally to the leadership of OMB before I leave for Europe on 16 April.

The original memorandum as delivered; as immediately translated into Chinese and then Spanish (Arabic and Russian and Iranian and Indonesian translations have been proposed); and as now refined and posted online, is attached. A related reference is below. I would like very much to see this comment reach the Director of OMB, the only person in OMB with the responsbility and authority necessary to ingest and act on this comment in the public interest.
D3 Innovation 1.8 CHINESE.docx
D3 Innovation Memorandum 1.8.docx
D3 Innovation Memorandum 2.1 SPANISH.docx
D3 Innovation Memorandum 3.0.docx

2016 Robert Steele: The Ultimate Hack – Resilient Villages, Smart Cities, Prosperous Nations at Peace — and Unlimited Clean Water

Robert David Steele
CEO, Earth Intelligence Network
http://robertdavidsteele.com

[Received: Tue 3/15/2016 12:46 PM]

This should be hosted on a site that open sources their code. Github is a closed source company. Recommend gitlab, etc.

The irony is high.

Sent from my Windows Phone

[Sender Name: "Ace OfHearts"]

To support the re-use of open source software between government agencies, it would be of great value to to have an online catalog of F/OSS products that are already in use by other goverment agencies, and with description, licensing, and assessment, and guidance. As an example of such a catalog is the U.S. Department of Veterans Affairs software catalog:

http://www.va.gov/TRM/SearchPage.asp

=> If you filter this search for "open-source" the result is 718 Open-Source licensed software products that are endorsed for use in the U.S. Department of Veterans Affairs.

=> The VA Software Catalog may thus be a good starting place for a Federal Open-Source Software Catalog

The VA Catalog presents a list of assessed technologies and standards used to develop, operate, and maintain enterprise applications. Entries on this list have undergone a strategic assessment based upon the nature of the technology. Each entry contains guidance, along with any known applicable constraints, on the permissible range of technologies or standards that a VA user, technical support team or project development team may select or shall use. The VA Catalog is not intended to direct procurements, although each entry contains available VA licensing information, if known.

First, this is fantastic!

Second - I'd like to request what I hope is a simple procedural point in processing feedback solicited through these Github issues.

The observation that I had from a previous solicitation for comments request using Github was that I don't recall there was indication that anyone read the issue after it had been submitted. It would be nice to have the equivalent of what hopefully happens after you send a letter to Congress - there's some indication that the letter has been opened and read.

What I'd like to suggest is simple tagging and / or categorization of comments into general themes as a way to acknowledge that someone has read them.

Thanks! Again, this is a fantastic effort.

The head of Section 4 points out that the US copyright code does not apply to software originated by gov't employees.

But this leaves open the option of putting restrictive copyrights outside the USA, which zealous agency lawyers may do (and yes, I have seen this happen). Such a dual license clouds the waters to no serious benefit. Can a non-US contractor improve the codebase? Does a US company with servers in Canada need a dispensation from the US gov't? Would the US gov't ever seriously contemplate selling the code to a non-US buyer?

I thus recommend adding verbiage explicitly recommending and permitting authors to list their code as CC0 at the head of Section 4.

for reference, worth a read thru, applies to DoD, but interesting:

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7D&resultIndex=1

A BILL
To amend title 10, United States Code, to provide for modular open system architecture in major defense acquisition programs, and for other purposes.

Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled,

SECTION 1. SHORT TITLE; TABLE OF CONTENTS.
(a) Short Title.—This Act may be cited as the “Acquisition Agility Act”.

(b) Table Of Contents.—The table of contents for this Act is as follows:

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H74F7D8891B75449181FFD4A6628F6A9F
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HB695783D841843639CF366ECA402885D
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H8512AA9AE79B4CFA9DFAB702FB637790
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HFC037E86B4D4441BA8DF6FC5078A60D5
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H0E70B36B69744F3B8262D9206247DE46
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HC1D9ED4F5828482C8843B81DC9F265A6

SEC. 2. MODULAR OPEN SYSTEM ARCHITECTURE IN DEVELOPMENT OF MAJOR WEAPON SYSTEMS.
(a) In General.—Part IV of subtitle A of title 10, United States Code, is amended by inserting after chapter 144A the following new chapter:

“CHAPTER 144B—WEAPON SYSTEMS DEVELOPMENT AND RELATED MATTERS
“Subchapter ............................................................................................. Sec.
“I. Modular Open System Architecture in Development of Weapon Systems 2446a
“II. Weapon System Component Development, Prototyping, and Deployment 2447a
“III. Cost, Schedule, and Performance of Major Defense Acquisition Programs 2448a
“SUBCHAPTER I—MODULAR OPEN SYSTEM ARCHITECTURE IN DEVELOPMENT OF WEAPON SYSTEMS

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H4CE0EF8F601A43BE82649025656E3EFC
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H4CE0EF8F601A43BE82649025656E3EFC
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H2A64CD51C19941FB9A9519C8C07B1076
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H18AC81629CBD462985D30D785D3AB5D7
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H1D7DCA99835149CC97A814E88E98CA86

Ҥ 2446a. Requirement for modular open system architecture in major defense acquisition programs; definitions
“(a) Modular Open System Architecture Requirement.—A major defense acquisition program initiated after October 1, 2018, shall be designed and developed with a modular open system architecture to enable incremental development.

“(b) Definitions.—In this chapter:

“(1) The term ‘modular open system architecture’ means, with respect to a major defense acquisition program, an integrated business and technical strategy that—

“(A) employs a modular design and uses, if available and suitable, widely supported and consensus-based standards for major system interfaces between the major system platform being developed under the program and its major system components;

“(B) is subjected to testing to ensure major system interfaces comply with widely supported and consensus-based standards; and

“(C) uses a system architecture that allows major system components to be incrementally added, removed, or replaced throughout the life cycle of the major system platform to afford opportunities for enhanced competition and innovation while yielding—

“(i) significant cost savings or avoidance;

“(ii) schedule reduction; or

“(iii) increased interoperability.

“(2) The term ‘major system platform’ means the structure of a major weapon system on which a major system component can be mounted or integrated.

“(3) The term ‘major system component’—

“(A) means a subsystem or assembly that can be mounted or installed on a major system platform through well-defined, open major system interfaces; and

“(B) includes a subsystem or assembly that is likely to have additional capability requirements, is likely to change because of evolving technology or threat, is needed for interoperability, facilitates incremental deployment of capabilities, or is expected to be replaced.

“(4) The term ‘major system interface’ means a shared boundary between a major system platform and its major system components, defined by various characteristics pertaining to—

“(A) physical standards for mounting major system components;

“(B) functional standards for integrating major system components, such as electrical, radio frequency, data, or software elements; and

“(C) open intellectual property rights consistent with section 2320 of this title.

“(5) The term ‘program capability document’ means, with respect to a major defense acquisition program, a document that specifies capability requirements for the program, such as a capability development document or a capability production document.

“(6) The terms ‘program cost target’ and ‘fielding target’ have the meanings provided in section 2448a(a) of this title.

“(7) The term ‘major defense acquisition program’ has the meaning provided in section 2430 of this title.

“(8) The term ‘major weapon system’ has the meaning provided in section 2379(f) of this title.

Ҥ 2446b. Requirement to address modular open system architecture in program capabilities development and acquisition weapon system design
“(a) Program Capability Document.—A program capability document for a major defense acquisition program shall identify and characterize—

“(1) the extent to which requirements for system performance are likely to evolve during the life cycle of the system because of evolving technology, threat, or interoperability needs; and

“(2) for requirements that are expected to evolve, the minimum acceptable capability that will be available upon initial operating capability of the major defense acquisition program.

“(b) Analysis Of Alternatives.—The Director of Cost Assessment and Performance Evaluation, in formulating study guidance for analyses of alternatives for major defense acquisition programs and performing such analyses under section 139a(d)(4) of this title, shall ensure that any such analysis for a major defense acquisition program includes consideration of an incremental development approach and modular open system architecture.

“(c) Acquisition Strategy.—An acquisition strategy for a major defense acquisition program, as required under section 2431a of this title, shall—

“(1) clearly describe the modular open system architecture to be used for the program;

“(2) differentiate between the major system platform and major system components being developed under the program;

“(3) clearly describe the incremental approach to major system components that are anticipated to meet requirements for system performance;

“(4) identify additional major system components that may be added later in the life cycle of the major system platform; and

“(5) clearly describe how intellectual property and related issues, such as data deliverables and license rights, that are necessary to support a modular open system architecture will be addressed.

“(d) Request For Proposals.—The milestone decision authority for a major defense acquisition program shall ensure that a request for proposals for the development or production phases of the program shall address the modular open system architecture to be used.

“(e) Milestone B.—A major defense acquisition program may not receive Milestone B approval under section 2366b of this title until the milestone decision authority determines in writing that—

“(1) the program incorporates a modular open system architecture with clearly defined major system interfaces between the major system platform and major system components to be developed under the program;

“(2) such major system interfaces are consistent with the widely supported and consensus-based standards that exist at the time of the milestone decision, unless such standards are unavailable or unsuitable for particular major system interfaces; and

“(3) the Government has arranged to obtain appropriate and necessary intellectual property rights with respect to such major system interfaces upon completion of the development of the major system platform.

Ҥ 2446c. Requirements relating to availability of major system interfaces and support for modular open system architecture
“The Secretary of each military department shall—

“(1) coordinate with the other military departments, the defense agencies, defense and other private sector entities, and national standards-setting organizations with respect to the identification, development, and maintenance of major system interfaces and standards for use in major system platforms, where practicable;

“(2) ensure that major system interfaces incorporate commercial standards to the maximum extent practicable;

“(3) ensure sufficient systems engineering and development expertise and resources are available to support modular open system architecture in requirements development and acquisition program planning;

“(4) ensure that necessary planning, programming, and budgeting resources are provided to identify, develop, and maintain modular open system architecture and associated major system interfaces; and

“(5) ensure adequate training in modular open system architecture is provided to members of the requirements and acquisition workforce.

Ҥ 2446d. Requirement to include modular open system architecture in Selected Acquisition Reports
“For each major defense acquisition program that receives Milestone B approval after October 1, 2018, a description of the key elements of the modular open system architecture or, if a modular open system architecture was not used, the rationale for not using such an architecture, shall be submitted to the congressional defense committees with the first Selected Acquisition Report required under section 2432 of this title for the program.”.

(b) Clerical Amendment.—The table of chapters for title 10, United States Code, is amended by adding after the item relating to chapter 144A the following new item:

“144B. Weapon Systems Development and Related Matters .................. 2446a”.
(c) Conforming Amendment.—Section 2366b(a)(3) of such title is amended—

(1) by striking “and” at the end of subparagraph (K); and

(2) by inserting after subparagraph (L) the following new subparagraph:

“(M) the requirements of section 2446b(e) of this title are met; and”.

(d) Effective Date.—Subchapter I of chapter 144B of title 10, United States Code, as added by subsection (a), shall take effect on October 1, 2016.

SEC. 3. WEAPON SYSTEM COMPONENT DEVELOPMENT, PROTOTYPING, AND DEPLOYMENT.
(a) In General.—Chapter 144B of title 10, United States Code, as added by section 2, is further amended by adding at the end the following new subchapter:

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#HB6110B544DDF4061B974A6B10A3270FB

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H9CAB53E4530649A8B164C66A8A62C301
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H9CAB53E4530649A8B164C66A8A62C301
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HABE19F502842446B99855593DC788188
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HE90031B4F5BF4E3EB45EC467E6AF69A8
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H219F73092674438B8B4037648CD07A64
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H020396E4034A448485D2FCC5ACC62B74
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H7776E4394F4141138652B8AD6FDFF381

Ҥ 2447a. Technology development in the acquisition of major weapon systems
“Technology shall be developed in a major defense acquisition program that is initiated after October 1, 2018, only if the milestone decision authority for the program determines with a high degree of confidence that such development will not delay the fielding target of the program. If the milestone decision authority does not make such determination for a major system component being developed under the program, the milestone decision authority shall ensure that technology related to the major system component shall be sufficiently matured separate from the major defense acquisition program using the prototyping authorities of this section or other authorities, as appropriate.

Ҥ 2447b. Weapon system component prototype projects: display of budget information
“(a) Requirements For Budget Display.—In the defense budget materials for any fiscal year after fiscal year 2017, the Secretary of Defense shall, with respect to advanced component development and prototype activities (within the research, development, test, and evaluation budget), set forth separately the amounts requested for each of the following:

“(1) Acquisition programs of record.

“(2) Experimentation and rapid prototyping of weapon system components or other technologies and subsystems.

“(3) Other budget line items as determined by the Secretary of Defense.

“(b) Additional Requirements.—For purposes of subsection (a)(2), the amounts requested for experimentation and rapid prototyping of weapon system components or other technologies and subsystems shall be—

“(1) displayed in separate budget lines structured into either capability or weapon system component portfolios that reflect the priority areas for prototype projects; and

“(2) justified with general descriptions of the types of capability areas and technologies being funded or expected to be funded during the fiscal year concerned.

“(c) Definitions.—In this section, the terms ‘budget’ and ‘defense budget materials’ have the meaning given those terms in section 234 of this title.

Ҥ 2447c. Weapon system component prototype projects: oversight
“(a) Establishment.—The Secretary of each military department shall establish or appoint an oversight board or similar group of senior advisors for managing prototype projects for weapon system components and other technologies and subsystems, including the use of funds for such projects, within the military department concerned.

“(b) Membership.—Each oversight board shall be comprised of senior officials with—

“(1) expertise in requirements; research, development, test, and evaluation; acquisition; or other relevant areas within the military department concerned; and

“(2) awareness of the component capability requirements of major weapon systems, including scheduling and fielding goals for such component capabilities.

“(c) Functions.—The functions of each oversight board are as follows:

“(1) To issue a strategic plan every three years that prioritizes the capability and weapon system component portfolio areas for conducting prototype projects, based on assessments of high priority warfighter needs, capability gaps on existing major weapon systems, opportunities to incrementally integrate new components into major weapon systems, and technologies that are expected to be sufficiently mature to prototype within 3 years.

“(2) To annually recommend funding levels for weapon system component prototype projects across capability or weapon system component portfolios.

“(3) To annually recommend to the service acquisition executive of the military department concerned specific weapon system component prototype projects, subject to the requirements and limitations in section 2447d of this title.

“(4) To ensure projects are managed by experts within the Department of Defense who are knowledgeable in research, development, test, and evaluation and who are aware of opportunities for incremental deployment of component capabilities to major weapon systems.

“(5) To ensure projects are conducted in a manner that allows for appropriate experimentation and technology risk.

“(6) To ensure necessary technical, contracting, and financial management resources are available to support each project.

“(7) To submit to the congressional defense committees a semiannual notification that includes the following:

“(A) A description of each weapon system component prototype project initiated during the preceding six months, including an explanation of each project and its required funding.

“(B) A description of the results achieved from weapon system component prototype projects completed and tested during the preceding six months.

Ҥ 2447d. Requirements and limitations for weapon system component prototype projects
“(a) Limitation On Prototype Project Duration.—A prototype project shall be completed within three years of its initiation.

“(b) Merit-Based Selection Process.—A prototype project shall be selected by the service acquisition executive of the military department concerned through a merit-based selection process that identifies the most promising and cost-effective prototypes that address a high priority warfighter need and are expected to be successfully demonstrated in a relevant environment.

“(c) Type Of Transaction.—Prototype projects shall be funded through contracts, cooperative agreements, or other transactions.

“(d) Funding Limit.—(1) Each prototype project may not exceed a total amount of $5,000,000 (based on fiscal year 2017 constant dollars), unless—

“(A) the Secretary of the military department, or the Secretary’s designee, approves a larger amount of funding for the project, not to exceed $25,000,000; and

“(B) the Secretary, or the Secretary’s designee, submits to the congressional defense committees, within 30 days after approval of such funding for the project, a notification that includes—

“(i) a description of the project;

“(ii) expected funding for the project; and

“(iii) a statement of the anticipated outcome of the project.

“(2) The Secretary of Defense may adjust the amounts (and the base fiscal year) provided in paragraph (1) on the basis of Department of Defense escalation rates.

Ҥ 2447e. Mechanisms to speed deployment of successful weapon system component prototypes
“(a) Selection Of Prototype Project For Production.—A weapon system component or technology prototype project may be selected by the service acquisition executive of the military department concerned for a follow-on production contract or other transaction without the use of competitive procedures, notwithstanding the requirements of section 2304 of this title, if—

“(1) a prototype project addresses a high priority warfighter need;

“(2) competitive procedures were used for the selection of parties for participation in the prototype project;

“(3) the participants in the project successfully completed the project provided for in the transaction; and

“(4) the prototype was demonstrated in a relevant environment.

“(b) Special Transfer Authority.—(1) The Secretary of a military department may transfer funds that remain available for obligation in procurement appropriation accounts of the military department to fund the low-rate initial production of a prototype until required funding for full-rate production can be submitted and approved through the regular budget process of the Department of Defense.

“(2) The funds transferred under this subsection to be used for production of a prototype shall be for a period not to exceed two years, the amount for such period may not exceed $10,000,000, and the special transfer authority provided in this subsection may not be used more than once to fund procurement of a particular prototype.

“(3) The special transfer authority provided in this subsection is in addition to any other transfer authority available to the Department of Defense.

“(c) Notification To Congress.—Within 30 days after the service acquisition executive of a military department selects a weapon system component or technology prototype project for a follow-on production contract or other transaction, the service acquisition executive shall notify the congressional defense committees of the selection.

Ҥ 2447f. Definition of weapon system component
“In this subchapter, the term ‘weapon system component’ has the meaning provided the term ‘major system component’ in section 2446a of this title.”.

(b) Effective Date.—Subchapter II of chapter 144B of title 10, United States Code, as added by subsection (a), shall take effect on October 1, 2016.

SEC. 4. COST, SCHEDULE, AND PERFORMANCE OF MAJOR DEFENSE ACQUISITION PROGRAMS.
(a) In General.—Chapter 144B of title 10, United States Code, as added by section 2, is amended by adding at the end the following new subchapter:

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#H56EEFE4AECCC442E90334AF7D9931936

https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HC82692A908DB43ECB31EF79365B30F37
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HC82692A908DB43ECB31EF79365B30F37
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-HCCED7E27A4724F20827FC31C80A8B426
https://www.congress.gov/bill/114th-congress/house-bill/4741/text?q=%7B%22search%22%3A%5B%22thornberry+and+acquisition%22%5D%7DresultIndex=1#toc-H8546FE228A084E1081B67D1CD57F3B63

Ҥ 2448a. Program cost and fielding targets in planning major defense acquisition programs
“(a) Program Cost And Fielding Targets.—Before Milestone A approval is granted for a major defense acquisition program, the Secretary of Defense shall ensure the program will be affordable and fielded when needed by establishing targets for—

“(1) the program acquisition unit cost (referred to in this section as the ‘program cost target’; and

“(2) the date for initial operational capability (referred to in this section as the ‘fielding target’).

“(b) Considerations.—In establishing targets under subsection (a) for the program, the Secretary of Defense shall consider each of the following:

“(1) The capability needs and timeframe specified in the initial capabilities document, opportunities for incremental deployment of capabilities, and minimum acceptable capability increments.

“(2) Resources available to fund the development, production, and life cycle of the program, using a reasonable estimate of future defense budgets.

“(3) Procurement quantity objectives.

“(4) Trade-offs among cost, schedule, technical risk, and performance objectives identified in the analysis of alternatives required under section 2366a of this title.

“(5) The independent cost estimate prepared or approved under section 2334(a)(6) of this title.

“(6) The independent technical risk assessment conducted or approved under section 2448b of this title.

“(c) Delegation.—The responsibilities of the Secretary of Defense in subsection (a) may be delegated only to the Deputy Secretary of Defense or the Under Secretary of Defense for Acquisition, Technology, and Logistics.

“(d) Definitions.—In this section:

“(1) The term ‘program acquisition unit cost’ has the meaning provided in section 2432(a) of this title.

“(2) The term ‘initial capabilities document’ has the meaning provided in section 2366a(d)(2) of this title.

Ҥ 2448b. Independent technical risk assessments
“(a) In General.—The Under Secretary of Defense for Acquisition, Technology, and Logistics shall conduct or approve an independent technical risk assessment for a major defense acquisition program—

“(1) before any decision to grant milestone approval pursuant to section 2366a or 2366b of this title;

“(2) before any decision to enter into low-rate initial production or full-rate production; and

“(3) at any other time considered appropriate by the Under Secretary.

“(b) Categorization Of Technical Risk Levels.—The Under Secretary shall issue guidance and a framework for categorizing the degree of technical risk in a major defense acquisition program and a major automated information system.

Ҥ 2448c. Adherence to requirements and thresholds in major defense acquisition programs
“(a) Capabilities Determination.—The Secretary of the military department concerned shall ensure that the capability development document supporting a Milestone A or subsequent milestone for a major defense acquisition program may not be submitted to the Joint Requirements Oversight Council for approval until the Chief of the armed force concerned determines in writing that the requirements in the document are necessary and realistic in relation to the program cost and fielding targets established under section 2448a(a) of this title.

“(b) Compliance With Targets Before Milestone B Approval.—A major defense acquisition program may not receive Milestone B approval until the milestone decision authority for the program determines in writing that the estimated program acquisition unit cost and the estimated date for initial operational capability for the baseline description for the program (established under section 2435) do not exceed the program cost and fielding targets established under section 2448a(a) of this title. If such estimated cost is higher than the program cost target or if such estimated date is later than the fielding target, the milestone decision authority may request that the Secretary of Defense increase the program cost target or delay the fielding target, as applicable.”.

(b) Effective Date.—Subchapter III of chapter 144B of title 10, United States Code, as added by subsection (a), shall apply with respect to major defense acquisition programs that reach Milestone A after October 1, 2016.

(c) Modification Of Milestone Decision Authority.—Effective October 1, 2016, subsection (d) of section 2430 of title 10, United States Code, as added by section 825(a) of the National Defense Authorization Act for Fiscal Year 2016 (https://www.gpo.gov/fdsys/pkg/PLAW-114publ92/pdf/PLAW-114publ92.pdf; 129 Stat. 907), is amended—

(1) in paragraph (2)(A), by inserting “subject to paragraph (5),” before “the Secretary determines”; and

(2) by adding at the end the following new paragraph:

“(5) The authority of the Secretary of Defense to designate an alternative milestone decision authority for a program with respect to which the Secretary determines that the program is addressing a joint requirement, as set forth in paragraph (2)(A), shall apply only for a major defense acquisition program that reaches Milestone A after October 1, 2016, and before October 1, 2019.”.

SEC. 5. TRANSPARENCY IN MAJOR DEFENSE ACQUISITION PROGRAMS.
(a) Reports On Milestone Decision Metrics.—Subchapter III of chapter 144B of title 10, United States Code, as added by section 2, is amended by adding at the end the following new section:

Ҥ 2448d. Reports on milestone decision metrics

“(a) Report On Milestone A.—Not later than 15 days after granting Milestone A approval for a major defense acquisition program, the milestone decision authority for the program shall provide to the congressional defense committees a brief summary report that contains the following:

“(1) The program cost and fielding targets established by the Secretary of Defense under section 2448a(a) of this title.

“(2) The cost and schedule estimates for the program conducted by the military department concerned.

“(3) The independent cost estimate for the program conducted or approved under section 2334(a)(6) of this title, and any independent schedule estimate conducted for the program.

“(4) A summary of the technical risks associated with the program, as determined by the military department concerned.

“(5) A summary of the independent technical risk assessment conducted or approved under section 2448b of this title.

“(6) A summary of the sufficiency review conducted by the Director of Cost Assessment and Program Evaluation of the analysis of alternatives performed for the program (as referred to in section 2366a(b)(6) of this title).

“(7) Any other information the milestone decision authority considers relevant.

“(b) Report On Milestone B.—Not later than 15 days after granting Milestone B approval for a major defense acquisition program, the milestone decision authority for the program shall provide to the congressional defense committees a brief summary report that contains the following:

“(1) The program cost and fielding targets established by the Secretary of Defense under section 2448a(a) of this title.

“(2) The cost and schedule estimates for the program conducted by the military department concerned.

“(3) The independent cost estimate for the program conducted or approved under section 2334(a)(6) of this title, and any independent schedule estimate conducted for the program.

“(4) The cost and schedule estimates approved for the program by the milestone decision authority.

“(5) A summary of the technical risks associated with the program, as determined by the military department concerned.

“(6) A summary of the independent technical risk assessment conducted or approved under section 2448b of this title.

“(7) A list of critical technologies, if any, associated with the program, that have not been successfully tested in a relevant environment.

“(8) A statement of whether the preliminary design review for the program (referred to in section 2366b(a)(1) of this title) has been completed.

“(9) A statement of whether a modular open system architecture is being used for the program.

“(10) Any other information the milestone decision authority considers relevant.

“(c) Report On Milestone C.—Not later than 15 days after granting Milestone C approval for a major defense acquisition program, the milestone decision authority for the program shall provide to the congressional defense committees a brief summary report that contains the following:

“(1) The cost and schedule estimates for the program conducted by the military department concerned.

“(2) The independent cost estimate for the program conducted or approved under section 2334(a)(6) of this title, and any independent schedule estimate conducted for the program.

“(3) The cost and schedule estimates approved by the milestone decision authority for the program.

“(4) A summary of the production, manufacturing, and fielding risks associated with the program.

“(d) Additional Information.—At the request of any of the congressional defense committees, the milestone decision authority shall submit to the committee further information or underlying documentation for the information in a report submitted under subsection (a), (b), or (c), including the independent cost and schedule estimates and the independent technical risk assessments referred to in those subsections.”.

(b) Clerical Amendment.—The table of sections at the beginning of such subchapter is amended by adding at the end the following new item:

“2448d. Reports on milestone decision metrics.”.

SEC. 6. AMENDMENTS RELATING TO TECHNICAL DATA RIGHTS.
(a) Rights Relating To Item Or Process Developed Exclusively At Private Expense.—

(1) Subsection (a)(2)(C) of section 2320 of title 10, United States Code, is amended—

(A) by striking clause (ii) and inserting the following:

“(ii) relates to form, fit, function, or the external interface of an item or process with other items or processes, including any major system interface of a major system component with a major system platform or other major system component;”; and

(B) in clause (iii), by inserting after “or process data” the following: “, including data pertaining to a major system component”.

(2) Subsection (a)(2)(D)(i) of such section is amended—

(A) by inserting “or” at the end of subclause (I);

(B) by striking subclause (II); and

(C) by redesignating subclause (III) as subclause (II).

(b) Rights Relating To Item Or Process Developed In Part With Federal Funds And In Part At Private Expense.—Subsection (a)(2) of section 2320 of such title is further amended—

(1) by redesignating subparagraphs (F) and (G) as subparagraphs (G) and (H), respectively;

(2) in subparagraph (E), by striking “In the case of” and inserting “Except as provided in subparagraph (F), in the case of”; and

(3) by inserting after subparagraph (E) the following new subparagraph (F):

“(F) Notwithstanding subparagraph (E), in the case of an external interface that is developed in part with Federal funds and in part at private expense, the United States shall have unlimited rights to—

“(i) use technical data pertaining to such external interface; or

“(ii) release or disclose the technical data to persons outside the government or permit the use of the technical data by such persons.”.

(c) Definitions.—Section 2320 of such title is further amended—

(1) in subsection (f), by inserting “Covered Government Support Contractor Defined.—” before “In this section”; and

(2) by adding at the end the following new subsection:

“(g) Additional Definitions.—In this section, the terms ‘major system platform’, ‘major system component’, and ‘major system interface’ have the meanings provided in section 2446a of this title.”.

(d) Government-Industry Advisory Panel Amendments.—Section 813(b) of the National Defense Authorization Act for Fiscal Year 2016 (https://www.gpo.gov/fdsys/pkg/PLAW-114publ92/pdf/PLAW-114publ92.pdf; 129 Stat. 892) is amended—

(1) by adding at the end of the paragraph (1) the following: “The panel shall develop recommendations for changes to sections 2320 and 2321 of title 10, United States Code, and the regulations implementing such sections.”;

(2) in paragraph (3)—

(A) by redesignating subparagraphs (D) and (E) as subparagraphs (E) and (F), respectively; and

(B) by inserting after subparagraph (C) the following new subparagraph (D):

“(D) Ensuring that the Department of Defense and Department of Defense contractors have the technical data rights necessary to support the modular open system architecture requirement set forth in section 2446a of title 10, United States Code, taking into consideration the distinct characteristics of major system platforms, major system interfaces, and major system components developed exclusively with Federal funds, exclusively at private expense, and with a combination of Federal funds and private expense.”; and

(3) in paragraph (4), by striking “September 30, 2016” and inserting “December 15, 2016”.

(e) Amendment Relating To Negotiated Rights For Item Or Process Developed With Mixed Funding.—Subsection (a)(2)(E) of section 2320 of title 10, United States Code, is further amended by striking the period at the end of the first sentence in the matter preceding clause (i) and all that follows through “establishment of any such negotiated rights shall” and inserting “and shall be based on negotiations between the United States and the contractor, except in any case in which the Secretary of Defense determines, on the basis of criteria established in the regulations, that negotiations would not be practicable. The establishment of such rights shall”.

(f) Amendment Relating To Deferred Ordering.—Subsection (b)(9) of section 2320 of such title is amended—

(1) by striking “at any time” and inserting “, until the date occurring five years after acceptance of the last item (other than technical data) under a contract or the date of contract termination, whichever is later,”;

(2) by striking “or utilized in the performance of a contract” and inserting “in the performance of the contract”; and

(3) by striking clause (ii) of subparagraph (B) and inserting the following:

“(ii) is described in subsection (a)(2)(C); and”.

For example, the government of Brazil has had an open-source policy for software procurement since 2003. It might be helpful to review the goals and effects of that policy. @gilbertocamara has published several articles on the question may be a good source of information.

It was very hard to find the text of this policy. There is no link afaict on the blog page that announced it (https://www.whitehouse.gov/blog/2016/03/09/leveraging-american-ingenuity-through-reusable-and-open-source-software). There is a link on the discussion page (https://sourcecode.cio.gov/), but it's labeled "View PDF", which sounds like it's just another way to view the discussion page--but it is in fact the actual policy. I think you should put up links on both pages that are clearly labeled "View policy (PDF)" or some such.

As is noted in the policy, code written by an employee of the government in the course of their duties is not copyrightable and thus would be released as public domain. However, it is worth remembering that this noncopyrightability is a specific effect of United States copyright law and would not necessarily apply abroad.* This is particularly important given that national-level use cases will naturally be of interest to foreign government users. Therefore, a fallback license should be prepared for those foreign users who will need one. Given that the code is otherwise public domain, a CC0 license would appear to be appropriate and avoid confusion.

It would, of course, be wildly inappropriate to use an open source release or open source development with non-employee contributions to impose a license on the code that is more restrictive than it would otherwise have (i.e., to domestically employ a non-public domain license on any codebase primarily developed in-house by federal employees).

*Wonk aside: The only common exceptions would be countries that both observe the rule of the shorter term and consider noncopyrightability in the country of origin to be equivalent to a zero-length term . . . and any programmer should know better than to assume that what happens when you compare an empty set with a numerical value will be the same in all languages and environments. ;)

The exceptions section includes these two bullet points:

The release of the item would compromise national security, confidentiality, or individual privacy;
The release of the item would create an identifiable risk to the stability, security, or integrity of the agency’s systems or personnel;

The second requires "identifiable risks", which implies that there must be some serious justification that there is a risk, not just hand-waving that this code is somehow important. However, the first does not include the word "identifiable", implying that the risks to security or PII need not be specific. I recommend rewording the bullet regarding national security and PII to include only "identifiable risks to national security, confidentiality, or individual privacy". Without additional constraints, this bullet point could otherwise be used by to exempt any code that processes PII in any way.

This is especially relevant in tandem with the subsequent bullet: because the first currently does not require an identifiable risk while the second does, there is an implication of a lower standard for exclusion.

Similar to Rousseau's Social Contract, it's good to consider the establishment of behavioral norms for civic open source contribution. We shouldn't want to simply write code; we should also want to help each other understand the problems we face around this country and empathize with different solutions. Without forethought and positive standards for behavior, open source communities are prone to devolve into toxic interactions and gamesmanship. At its best, an open source community fosters the development of its members more than the development of code.

So, here are four pithy statements I came up with, based on years of experience working primarily in the Drupal Open Source world. Drupalists maintain an OSS space of thousands of contributors that persists for over a decade. The community actively works to foster top talent and new talent; diversity and idiosyncrasy.

1. Encourage those who know less
2. Learn from those who know more
3. Be curious and courteous
4. Take pride in what we build together

Workshopping of the above statements is, of course, encouraged. If we could get it down to 3 statements, that would awesome. Most important is to express that everyone who contributes is at times a mentor and at other times a mentee. We all learn and teach and should acknowledge that a lack of knowledge is an opportunity to grow.

It would be useful for the policy to provide guidance on whether there is a preference for copyleft versus permissive licenses, either in general or in specific cases. Permissive licenses such as the Apache license are often well-suited to libraries, drivers, and other utility-type codebases that are unlikely to have much standalone business value, in order to gain as much adoption and standardization as possible. Some organizations will not touch non-permissively licensed code.

The AGPL and related copyleft licenses are useful for preventing a company from taking code created by the government, modifying and extending it, and creating a business out of that fork. It is best suited to code that has sophisticated functionality and substantial business value, as it requires any modifications to be made public, potentially benefiting the government in the future.

Making these distinctions clear and providing guidance will hopefully enable each individual agency and team make the best decision for their particular case.

The money comes from the taxpayers. I don't see any legitimate reason to hide the code or claim copyright to it...

It's a small thing but if the wiki is unused, I recommend disabling it [a checkbox in the settings] just to remove the visual distraction.

We work on making legal texts reusable by organizing them as objects. Other governments could more easily benefit from the policy and learning more easily if they could make their own policies by overriding elements of yours. This is part of a vision of full codification of legal documents.

I did a really quick job of putting the pages into Cmacc format. This obviously needs to be refactored, but you will get the idea.

http://commonaccord.org/index.php?action=source&file=GHx/WhiteHouse/source-code-policy/pages/0.md

(From that page, click through for the source on GitHub)

Three cheers for the great work!

The link goes to https://sourcecode.cio.gov/source-code-policy and looks like should go to https://sourcecode.cio.gov.

Interoperability should be one of the primary metrics.

Open source removes constraints that prevent interoperability. Programmers are free to create APIs and other connectivity that brings enterprise-wide integration.

Interoperability is often the main driver for government solutions in areas such as cross-agency coordination, business process reengineering, innovation and general efficiency. Many of government's largest problems are related to business software systems that are not integrated. Without continual interoperability updates, you cannot re-engineer your business processes; your IT systems hold your business process improvements hostage. The most important areas for interoperability planning are in national security and emergency preparedness.

Alex Glaros

This policy only addresses federally-funded software projects, but does not mention datasets generated by federally-funded projects. I know there is as much or more talk about opening up datasets--curious to know if there any complementary policies mandating the open licensing of datasets.

One of the key cost-savings components of Open Source software is the ability to re-use code; the policy emphasizes this, but it incentivizes only the creation and publication of code that can be reused by other people or other portions of the government.

It does not, to my reading, actually push for any savings by actually consuming that code again, and I'd like to see some discussion of how that could be improved. Section 5.2 a) touches on it, and the procurement policy in Appendix B indicates OSS should be procured preferentially in Step 1, but at Step 3 it seems like an all-or-nothing affair, while in reality we want to espouse significant attempts to reuse OSS code and libraries. In any case these brief mentions are not strongly represented in the rest of the document.

I'd like to add an "Objective" that indicates some measure of actual reuse, and replace "reuse" in objective 2 with "publication" or something. This is to clarify that the publication and consumption (reuse) of OSS code are two related but separate goals. Code is not re-used if it's simply available.

We could consider another goal (10%? 20%?) to have the code in a new government funded project make use of existing OSS code (government or not). This is a pain to measure, but the point is there's little benefit to having a library of open source code if no one uses it. The objectives should indicate this.

(I may take a stab at composing such an objective later, depending on feedback here).

At minimum, relatedly, OMB should explicitly add a metric to track OSS code consumption, rather than just publication. Again, this is onerous, but I think it's essential for realizing cost savings.

Reference: Pilot Program, Exceptions to Government-wide Reuse or to Publication

STRIKE LINES: 229-233, 235-243, 391-400, 414-416

ADD NEW SECTION TO PILOT
All Custom Code and GOTS development will contain the following provisions in all Custom Code development contracts and GOTS programs starting the effective date of the memorandum:

This software application / source code is licensed as GOTS to the Department/Agency as the sole and exclusive agent of the U.S. Government and must not be released to the public or other non-U.S. Government entities. The government has unlimited and unrestricted government-purpose rights to the software in perpetuity; subject to the obsolescence clause below. The Department/Agency at their discretion, may choose to share or redistribute the software application / source code to other branches of the U.S. Government at no cost to the receiving parties; and subject to the government employee and contractor clause below. Under this license, the government has the right to alter, update, or change the software. The Department / Agency may also utilize or authorize the modification of the software application / source code to develop alternative and derived applications for any alternative purpose; or alternatively designate in writing and post publicly any government entity for this purpose. Parties utilizing this application/source code may not resell or re-license the source code to non-U.S. Government entities or back to the U.S. Government.

Government Employee and Contractor Clause. Employees and contractors of the government are only permitted to modify or derive alternative applications from the source code for the sole and exclusive use of the U.S. Government. Employees and contractors of the government who may modify or derive alternative applications from the software application / source code are not permitted to make intellectual property claims upon, or make profit from, the modified or derived source code or applications.

Open Source Clause. The Department/Agency may, at its discretion, determine that some or all of the application / source code is suitable for OSS release for use outside of the U.S. Government after an Agency security review and redaction of Inherently Governmental Functions that could pose a risk to the American Public or U.S. Government.

Obsolescence Clause. The Department/Agency CIO must be kept apprised of the re-development, maintenance, and derived applications of this software application / source code and any derived applications. If the Department/Agency fails to utilize and maintain the software application / source code and any derived applications for a period of one year, this license is voided and the software may be petitioned for OSS release after an Agency security review and redaction of Inherently Governmental Functions that could pose a risk to the American Public or U.S. Government.

RATIONALE / DISCUSSION
Footnote 8. Although Microsoft publishes the .NET framework and Apple provides Swift, neither publish their application source code. An important distinction.

Software Security. Many private companies (especially security companies) do not publish their source code is because it allows attackers to (a) construct highly targeted attacks against the software, or (b) build-in malware directly into the source code, compile, then replace key software components as 'dopplegangers' of the original. How will this be prevented?

OSS and Inherently Governmental Functions. This definition is insufficient. It basically tries to leave limited discretion with the CIO, but forces them to release 20% of custom code per year under the assumption they know which custom code is safe for release. It is clear that OSS is appropriate for functions common between the Government and Civilian sectors. However, when Inherently Governmental Functions, non-FOIA'able, law enforcement, or security functions that are non-NSS are involved, there is risk that the Government can compromise law enforcement investigations, increase the possibility of fraud or crimes, or compromise security tools not technically NSS. Examples: citizenship anti-fraud rules that are coded into software, identification of special codes used to flag law enforcement actions, APT threat indicator scripts, mafia having a copy of all FBI system code, terrorist with access to air traffic control software, etc. How will this be prevented? I can understand why OSS rules could be established to help facilitate appropriate OSS communities, but why must it be 20% each year?

Altruistic Motivation. Although Educational Institutions may wish to contribute to OSS; it is unclear whether contractors and vendors will really wish to contribute to Government Open Source improvements. Another possibility is that the contractors or vendors will take the code, improve upon it, then sell it back as COTS to the Government. However, if the source code involves inherently governmental functions; then information regarding those functions could be inadvertently leaked (such as law enforcement or anti-fraud / criminal activity processes, which is not a desirable outcome).

Legal Costs. Once source code is released, it is difficult to determine if any of it has been re-utilized in other commercially available programs, such as those developed by foreign software companies. In the event of legal action, does the Government possess the Intellectual Property and Code Vetting resources to protect its interests against commercial companies (both domestic and internationally) abusing the licensing agreement?

Fuel Innovation. GOTS Development. Since corporations will primarily benefit (not really the public), what motivation do Government software developers have if their custom code is given to commercial corporations to sell back to the Government for large amounts of money? Sends the message that if you're a good code developer, you should (a) not enter or (b) leave Government service since there is nothing 'special' that they do.

Overall Cost Savings. Although the U.S. once enjoyed a relative monopoly of software development, the growing trend is the outsourcing of software code development overseas. "Globally, only 10 percent of MNCs outsourced IT work offshore in 2002, but that figure had risen to 70 percent by 2008, according to Oppenheimer Equity Research. Gartner Inc. estimates that by 2012, the worldwide IT services market, which is the largest segment within the outsourcing industry as a whole, will top $1 trillion." China Business Review, China’s Emerging Role in Global Outsourcing, Nov 1, 2009. EXAMPLE SCENARIO: Release of U.S. taxpayer-funded code development will, over time, provide foreign access to U.S. GOTS source code but without reciprocation; placing U.S. government-funded software contractors at a distinct disadvantage unless they claim proprietary software rights over the developed custom code. Once that is done, then the software development silo is reborn (but this time in a private company that could go bankrupt or be sold to a foreign entity). The now proprietary code could not be transferred to a new company in the case of a contract change; so the new company would be forced to develop their own system or alternatively purchase the rights from the exiting contractor. To avoid bankruptcy, the exiting contractor could now charge what they wish for the now proprietary code (the exact spiraling cost scenario that this policy presumably claims to avoid). Eventually, this will have the adverse effect of either (a) U.S. code developers not wishing to produce code for the U.S. Government knowing that their intellectual property could be poached by overseas competitors, or (b) ensure that only certain companies maintain proprietary code for which they could charge any amount of money they wish.

Sincerely,

Keith Hall

There is a link to a definition in Appendix A, but it would be good to be explicit about which agencies are covered. For example, would branches of the military need to share any custom code?

Article 14.17 of the Trans Pacific Partnership (TPP) deals with the treatment of source code and restricts what actions a member government may perform.
Specifically: “No Party shall require the transfer of, or access to, source code of software owned by a person of another Party, as a condition for the import, distribution, sale or use of such software, or of products containing such software, in its territory.”

Whilst the intent of this article was likely otherwise, the text as written will likely have an impact on the ability of governments to enforce their own copyrights on any Open Source product or service against a company or person from another TPP nation.

Note that this is something that only applies to governments. Private organisations and individuals are not 'parties' in the context of the TPP, but governments and government agencies are.

Research into this article indicates that none of the additional clauses would change the above. This includes 14.17.3(a) as licenses such as those commonly used in open source software (e.g. the GNU General Public License - GPL) are not considered ‘commercially negotiated contracts’.

Has there been any consideration of this at all?

And not just because my github profile will say I've contributed to the WhiteHouse's repo. 💯💯💯💯

Glad to see this intiative, Github is a great place for collaboration on text.

You may want to consider the use of CommonAccord data model for these documents, which would make them more easily re-usable and would allow greater gains in efficiency when starting to produce documents across agencies.
We have done an example of what it would look like here: http://www.commonaccord.org/index.php?action=doc&file=GHx/WhiteHouse/source-code-policy/pages/0.md

The concept of re-use of whole or portions of the text produced is important. And CommonAccord is also relevant to discussions on blockchain because the text can be read by machines as well as by humans, thus providing the legal context around "smart contracts" which are otherwise NOT contracts.

Feel free to contact me if you have any questions.
For more information on CommonAccord:
https://github.com/CommonAccord/Cmacc-Org
http://www.commonaccord.org

This section of the draft policy appears to require a new inventory. Recommend avoiding a wholly new inventory.

FAR Subpart 27.4 defines "Data" as follows: “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.

Recommend adopting this definition of data and extending the coverage of OMB Memorandum M-13-13 to include code.

Recommend leveraging the existing project open data metadata schema and requiring code repositories to be listed in the Enterprise Data Inventory.

Recommend updating and extending the project open data metadata schema to facilitate the production of relevant metadata for a code repository.

The language in the draft policy is a little ambiguous or less than perfectly clear on its applicability. It does state that it applies to code developed both by Federal employees and contracts, but then makes statements like the following under the objectives: "This applies only to software developed in the performance of a Federal agreement."

Many government employees, especially from agencies with a science or engineering mission, develop quite a lot of software directly in addition to software developed through Cooperative Agreements and other contracting vehicles. The policy could be improved by making this point clear and indicating that it applies to software developed by Federal employees and to contractors/partners under Federal agreements.

This is a follow-on issue to issue #12. (what percentage of government funded code should be released to the public). The consensus on the issue of what percent of government-funded software needs to be released as open-source is 100%.

However, focusing on percent of code published to the public as result of a government-funded development project somewhat misses the point of open source.

The real benefit of open source is the process and community that it builds, and the quality of code that results.

Open source "the process" allows other coders to provide feedback contemporaneously as the code is being developed. This makes for better quality code. It also creates a large community around it. Which also builds confidence in the end users of the software that they will have support for the software if they adopt it.

But this requires contemporaneous peer review of the code in flight.

Therefore, a better framing of any policy regarding open source should state "100% of government-developed code should be developed openly, under public, contemporaneous peer review by default"

As an example of this, see the DoD's contracting language. It mandates the use of a Project Repository on a public Github repository for contemporaneous public, peer review .

https://github.com/vistadataproject/documents/blob/master/Submissions/src/VistAMetadata-2015-12-09-PWS.md#data-rights

1.6.15.1 Artifact Repository: To facilitate the management, reporting, collaboration, and continuity of access of all artifacts and deliverables produced under this contract as a single logical unit, all artifacts and deliverables shall be developed, version-controlled, stored, and delivered on an industry-standard public Github repository (“Project Repository”). Upon commencement of the contract period, the contractor shall establish the Project Repository, and provide the URL of the Project Repository to the project manager, contracting representative, and relevant stakeholders.

I do not see a discussion in the draft policy on scientific software such as analytical codes and workflows built in something like Python, R, or other software platforms popular in the sciences, with many open science code projects operatingright here within GitHub. In many cases, the open release of this type of software is being pushed by publishers and journal editors who are beginning to demand the availability of software underlying scientific papers. However, that direction with commercial publishers can also introduce its own challenges to openness with some groups beginning to offer services for hosting scientific codes behind the same paywall as their journal articles. While I don't begrudge the commercial publishers' right to build commercial success, scientific code and scientific data are the fundamental building blocks whose open access is critical in accelerating the pace of scientific discovery to face our planet's pressing challenges. It would be helpful for this policy to make mention of scientific software to help bolster the overall administration push on open science (2013 Holdren memo).

"Federal agreement" * may be a well-known term of art for procurement lawyers, in which case it may not be worth using as a defined term, but to a mere IP lawyer it appears to be both critical (easy way to avoid the bite of the regulation) and undefined.

* in Sec. 1, "This applies only to software developed in the performance of a Federal agreement"

The VA and DoD have invested considerable resources to establishing technical and legal frameworks for technical collaboration on software development because they are Congressionally mandated to interoperate.

A most recent example is the VA-DoD Interagency Agreement established for co-development of software is linked here. Of particular interest is the Data Rights section ((1.6.15 and its subsections):

https://github.com/vistadataproject/documents/blob/master/Submissions/src/VistAMetadata-2015-12-09-PWS.pdf

The Markdown version:

https://github.com/vistadataproject/documents/blob/master/Submissions/src/VistAMetadata-2015-12-09-PWS.md#data-rights

=> This might be a good template for inclusion in this Whitethous source code policy.

The introduction states one consideration as being:

Would an “open source by default” approach that required all new Federal custom code to be released as OSS, subject to exceptions for things like national security, be more or less effective in achieving the goals above?

At an (extremely) broad level open source code can be split into two categories: (1) code which is fairly self-contained and not likely useful to others outside of some purposes like education and the ability for users to provide feedback or things like typo fixes directly to the developers; and (2) code which is modular and meant to be consumed by other users.

For several reasons I would suggest that no, an open source by default would not largely help to meet the stated goals of "fuel innovation, lower costs, benefit the public, and meet the operational and mission needs of covered agencies".

Most code which is written by developers falls into category (1) above. While there is an argument for making this type of code open-source-by-default, it doesn't entirely make sense because,

• This places an additional burden on developers (for a website to be open source they have to take time to separate application code from any private keys, passwords needed for deployment, etc).
• It mostly adds noise to the open-source ecosystem. I'd rather see a few useful libraries be open sourced than 20 ruby on rails apps. There are plenty of existing examples to learn from in most cases.

One metric that some companies use, is that if they see the same code being re-used across multiple projects they see that as a library and will either open-source it or modularize it for easier internal use. I could see this as being useful for government work, especially when sharing code across agencies or branches.

Maybe a useful heuristic would be: where feasible with respect to national security, if one government agency wants to re-use code that another has written the mechanism for doing so should through open source.

Effectiveness will depend largely on the expectations. As a pilot one could select a specific agency or look at a class of systems that support a defined range of workflows, inventory their contract-developed custom code, and release appropriate portions of that.

The pilot could follow a number of projects that aim to develop new systems and monitor their experience in applying the policy and reusing released custom code. Some questions that could be asked in such a pilot could include:

• Did the reused code provide enough documentation to understand its purpose and working? Were requirements/design documentation produced as part of the work and can those be released?
• Is (should?) test documentation and data be included?
• How much recoding was needed to meet functional needs?
• Did we really need all these functions that required customization?
• Was the code indeed reusable and did the reuse save time?

The pilot should also address whether to refactor the custom code resulting from the project as modifications of the original reused code or whether the result will be released as its own new code base. Releasing code to a public code repository is not just an upload of a zip file. As can seen here, there are wikis, issues and other aspects that need to be managed. When looking at this from a project perspective, one needs to ask who maintains the code after the project has been completed. Releasing code alone is not enough.

Procurement processes and especially project planning will require adjusting as described in the policy, but here lies also one of the major opportunities resulting from this policy: collaboration between in planning of systems used in government agencies that meet broad needs with little to no customization.

Very closely related to the benefits of Open Source Software, is the adoption of Open Standards.
Open Standards facilitates interoperability between applications and organisations, mitigates risk of vendor lock-in and obsolescence, and is usually widely adopted by Open Source applications.
This policy should include reference to Open Standards, including recommending why standards should be adopted where they exist.
Refer to: http://mil-oss.org/resources/books/open-technology-development which includes:
"Use/modify/create open standards, in that order." It also defines an Open Standard.

Many tools and services exist to test source code or binaries for well known vulnerabilities. Government use of these tools, or government agencies requiring contractors or software suppliers, has been minimal and inconsistent.

The world does not need more insecure code - this process needs to as a minimum require common process for code to be tested for "basic app development hygiene" before being submitted or at least before being accepted.

NIST had fiddled around with such tools for over a decade now, this would be a good vehicle for them to move towards actual operational improvements in government software security.

John Pescatore

I am concerned that developing open source software may result in overly/unnecessarily secure code that uses strong encryption protocols. This will likely become a significant safety issue, hindering law enforcement and investigation, as we have seen with Apple's designs. I believe a key escrow system would be the most effective solution. Information will be protected with encryption but still be accessible by authorities in case of national security or other law enforcement needs.

I obviously have a github account, but for people who do not yet have one, when they click on the part of the introduction page that says:

Please note that all comments received will be posted publicly here.

The link "here" points to: https://github.com/whitehouse/source-code-policy/issues/new and redirects the viewer to GitHub's login page before they can proceed. Any possibility of this being changed so they can view the public comments without signing into GitHub?

The document contains a requirement to have 20 percent of custom code released as open source, but doesn't specify how this should be measured. Two possible methods:

• 20% of projects
• 20% of lines of code

What is the intention of this 20 percent? Thoughts?

In Section 3, Software Procurement Considerations, footnote 22 is crucial. Wondering if this doesn't deserve more attention in the policy, for fear that footnotes aren't always read with great consistency?

Not sure if this qualifies as an "issue" or not and apologies if this has been discussed. Relatively new to using GitHub discussion boards.

Without sacrificing too much of speed, reliability, and other concerns, it is important to think longterm about the complexity of systems. Governments, handling so many things at once, tend to become so big that nobody understands more than small parts, so its especially important here to plan longterm to keep things simple and define measures and rewards for it.

Let's say that a hypothetical big government agency (BGA) needs some hypothetical software that bakes digital bagels.

They determine that there is no current in-house or open-source solution to bake digital bagels, so they contract some hypothetical big software company (BSC) to make their digital bagel baking software.

Does this mean that BSC's digital baking software would have to be open-source, or... what? Or am I completely misunderstanding, and only code that BGA makes needs to be made open-source?

Also, let's say that BSC already has some existing, but closed-source, digital oven software. They only need to add the digital bagel functionality to the digital over software. What does this imply? Does all of the digital oven software have to be made open-source or only the "digital bagel module"?

To date, government purchasing guidelines inadvertently favour proprietary over open source. Purchasing guidelines and practices should be updated to address this.

1. Potential value of future community contributions is rarely considered when purchasing. "If I extend an open source product, and spend an extra 20% of my budget on integrating the new code into the product baseline, and supporting building a community around my extension, then the greater community will likely support and extend my work, resulting in reduced long term costs to me." Being able to identify and then quantify such opportunities, will lead to a more realistic comparison of open source versus proprietary.
2. A proprietary vendor can split product development costs between multiple agencies, providing an attractive license price when compared to each agency developing the product themselves. For an Open Source alternative to compete, multiple agencies would need to collaborate and pool resources into a common platform. This would require cross agency collaboration in purchasing, or business justifications similar to (1).
3. Guidelines should help purchasers quantify the cost of potential vendor lock-in solutions.
4. Guidelines should emphasise the importance of open standards, to reduce vendor lock-in.
5. Governments in Australia have a tendency to spend all their money in a few months before end-of-financial year. (I assume it is the same in the US). This is difficult for companies providing Open Source support to Governments, as contracts are typically pay-as-you-go. "Pay a developer to write a feature for a product". Changing government to have a sustained spend throughout the year will lead to a more stable and established business community supporting government in open source services.
6. To date, government open source purchases typically focus on buying a product (as capital expense). This results in an injection of funds into adding a feature to an open source product, without consideration for long term community support and maintenance of that feature. This results in the feature becoming unmaintained, obsolete, then dropped. Purchasing of all software, including open source, should recognise the strong need for long term maintenance (operational expense), and budgets should be structured to account for this.

Please clarify the impact of the government requesting functional enhancements to closed-source COTS and Middleware. Given that agencies typically don't have sufficient software engineering talent to customize COTS, they work with systems integrators to build customize enhancements for these products. Systems integrators like to retain ownership (souce code of plugins and exclusive admin control of platforms) of these closed-source customizations to have leverage to force sole-source contracts for ongoing maintenance. More recently, the integrator will call this a SaaS offering (targeting a single customer). According to the spirit of this document, I would expect that the government agency should take delivery of the source-code for all plugins and custom enhancements and release the codebase as open-source as this policy stipulates. To do this, the government need to properly license managed COTS and middleware products to retain admin rights and have access to APIs and the relevant plugin architecture. Please add content to the document targeting anti-competitive systems integrator practices to ensure clean acquisition of closed source platforms and the open-sourcing of plugins to those platforms.

[Submitted Tue 3/15/2016 10:14 AM]

Good Morning,

I have been working to obtain a customized software program with an outside federal agency who wants to share their information with us at no cost. They are offering it to us without warranty and to receive this “as is” by a Memorandum of Agreement. We have the IT support to implement the software on our end without having to go through a vendor to recreate something already accomplished by a federal agency. However, we cannot get the support of our Special Counsel to agree on this because they believe we MUST pay for this. Your draft policy is heading in the right direction; however, we would ike to see this happen sooner than later. Any suggestions in the meantime? Thank you.

Very Respectfully,
Melanie A. Murguia
Supervisory Personnel Security Specialist
Security Branch, National Labor Relations Board

You need to run gem install bundler after installing Ruby in order to be able to use Bundler to install dependencies. I think that should be mentioned in the README.

Making 20% of government code open source will expose contractor code to public scrutiny.

This will help find bugs cost effectively.

But this will also inform contractors that their code might be open to public scrutiny.

Managers and developers will adjust their software development processes accordingly, likely yielding better code quality over a few years or a decade.

While I applaud this step - and the use of github! making sure code that what is released (and not!) is properly maintained and regularly updated is very important in a world where bugs can be exploited worldwide, in a matter of hours.

We (myself, vint cerf and a cast of 260 well known others) tried to put forward some of these ideas in:

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf

which was not at all specific to how the fcc treated things (the letter had been brewing for a year). Hopefully some insights from what we wrote above will apply to your new policy proposals.

Thank you for the opportunity to take part in the review of this policy. The following is my review:

General observations

• There should probably be a preference for abstraction and not implementation in this document for certain sections of this policy.
• Does the federal government agency need to report when they are using OSS? If this policy is seeking transparency than I think there needs to be record of not just when an agency is "pulling down" the source code, but also when they are actively using it. I also wonder how this information would drive the OSS community. I'm not entirely convinced that this would not somehow hinder the diversity of work that has made the OSS community what it is today.
• There is some re-stating and frivolous re-wording through out this policy that should be removed. Try to keep descriptions of unrealized benefits to a minimum or at least segregated from sub sections describing specific devices.
• Must there be a clear distinction between when a federal employee has made a contribution to source code and when a non-fed has? At what times are contributions by fed employees considered to be work done by the federal government? Can federal employees charge for this time? Can non-feds charge for this time? What work can be charged and what cannot in refernce to work done to fulfill this policy?

Specific critique

Line 20 Possible rewording, because there is no process defined, nor a federal platform for agencies to share source code even if they wanted to. The current wording seems to say that it is currently the individual agencies short comings which are costing tax payers dollars.

Line 77 - I also think that certain operational systems should be considered for exception. I think some other criteria for exception might be

• systems which provide access/manipulation to sensitive personnel information that is not necessarily classified or part of military operations.
• certain safety critical systems such as air traffic control

In general I think the same methodology for determining security classification could used when we replace the words "national interest" with "human lives" or "national economic impact". I'm not certain as to what the criteria should be.

I do think that systems that are to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). Might be considered for exception.

Note: I realize that the rules for filing for an exception are later stated however, the reference used here has wording that I think might conflict.

Line 86 - could be tricky because the federal government has many times taken on software that was originally developed by contractors. I think that when the federal government makes any change to these products or has been deemed to be the sole maintainer of the product than that source code should be made available under the terms of this policy.

* Lines 98-103* - I believe there should be a general preference for existing Federal open source solutions than COTS products when not taking into consideration total costs to agency. In reality, short term/long term costs and scheduling are the factors that weigh most heavily into this decision.

Line 103 - Not just custom code form scratch or proprietary solution but, build off of open source solution.

Line 113-114 - What OMB policy is the use of cloud based technology consistent with? This is not specified in "Raines Rules". What is the reasoning that cloud based deployment solutions are preferable? Also does this mean a federal government owned cloud service or the cloud of some third party business? I would think that the federal government should maintain its own “community cloud” for deployment which could be configured by each system making use of the deployment service. This would be a shared service across federal government. We can still keep data and source code hosted publicly. Also cloud computing is a "buzz word". Since NIST is mentioned later in this document I offer their definition: "Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction". This definition seems vague at best. I do not believe stating the preference for cloud computing is appropriate for this policy.

Line 119 - What does it mean to demonstrate a preference?

Line 124 - 129 - COTS products are different than open source. I believe there should be a preference for open source before COTS product with consideration for my comments made on Lines 98-103.

Lines 136 - 141 There should be a preference for developing a solution based off of any existing open source code before developing solution from scratch or customizing existing federal or COTS product. With the understanding that the customization of the COTS product source code would be under open source licensing described in this policy.

Lines 145-149 There should also be consideration made for not only copyright, but also trademarking. I believe that there is currently or could be code developed with federal funds that have been part of a system that has been trademarked by companies contracted by federal government. software created on behalf of the government should not be subject to trademark protection. Also often the copyright of source code is largely predicated on the process or algorithms that are unique to that source code. In some cases, it is the federal government entity that is creating this design and the third party is contracted to implement it. In these cases, I believe that the source code should not be subject to copyright protection. There must be a mechanism to accurately track these track these cases, either by mandating that a design be uploaded to some federal repository or some other mechanism.

157 - 160 I'm not sure that this policy should dictate the deliverable. That should be in the terms of the individual contracts. If the federal government desires to be that specific than I think build instructions, user guides, test suites etc. should be defined here or in a supplement to this policy. I also think that it would be useful to have a supplement to that might attempt to recommend deliverable artifacts based on some classification of software development contracts that we have yet to define. Perhaps something related to scope of complexity, cost, type of system, or specific agency.

Line 162-164 - These terms should be dictated by some specific open source licence that has yet to be or already been established as acceptable by the federal government. Perhaps one of the licences defined by NIST?

Line 167 - define unlimited data rights

Lines 177-179 - I propose the creation of a new "Open government licence" which would be used for "government -wide reuse of custom-developed code"

187-188 - Please define peer review and security testing or make reference to some existing material. These processes can vary greatly depending on the project. I think the federal government should have some definition of minimum criteria for peer review and security testing.

Section 5.0 - Possibly move the text of this section to an earlier part of this document. This is a more general discussion of the purpose of this policy. This section should be labeled something like "Road map" or "Implementation" to group the remaining subsections.

Section 5.1 - Rather than each covered agency releasing 20%, why not choose agencies with operations that have been deemed to have low risk to human lives/sensitive information/security etc. and have those agencies take part in the pilot program to determine proof of concept. After the impact assessment, another group of agencies should take part in this program. The order would be based on the amount of risk each agencies operations have to the areas described above. There also be an allowance for any CIO of an agency to request admittance to the program earlier than scheduled if they should choose. Also the code contributed as part of the 20% should not be incomplete. If code released as part of the 20% requires some dependency that can be described as "newly-developed custom code" than those dependencies must also be released as well. This is to prevent unusable/incoherent/un-compilable code from being released to meet the 20% criteria. Again I would not that many times federal employees are designing the software or in some cases are dictating the source code to contract personnel. I question whether or not that code would be considered as developed by third part vendors. This needs to have a clear distinction.

Lines 245 -246 - Please define criteria that will be used to evaluate the success of this pilot program in a supplement to this policy. (lines of code contributed, labor months saved, etc.).

Line 268-269 - Frivolous statement "Open development practices...."

Lines 270-273 - Define engaging the public. What is the minimum level of engagement? What if there simply is not an interested community for the source code? Define alpha and beta phase. This varies wildly between projects. Also refrain from using "1.0" To my knowledge and my experience there is no standard software versioning that is used across software projects. There are many schemes accepted to be part of best practice and many custom schemes that are actively used today. instead describe the state which the software must be in before official release. Although again I think this is getting into to deep into implementation of this policy.

Lines 274-279 - Define incremental release schedule. I also think this is to deep into implementation. What is considered incremental for one team could be much different than another.

Line 280 - define "User". Who is the federal government engaging?

Lines 285 - 291 - What are the criteria for consideration? I think there should be some minimum standards either described generally here or this policy should enforce each project to define their own minimum standards.

Section 5.2 - Who's job is it to enforce these policies and provide oversight on this community?

Lines 292 - 304 - Who is responsible for this documentation? This this change depending on whether the original author or designated "owner/manager" of the project is a federal employee or not?

Line 318 - Are "web manager" and "digital strategist" positions defined by the federal government? Does every agency have this position slotted?

Lines 324-332 - Who will be developing/managing the content of Project open source? Will the federal government also accept public input for this effort? Will there be access levels created to separate federally accessible information from publicly available information? Who woudl control those access levels?

Lines 336 - 340 - Who will be held responsible for funding efforts associated with transferring source code from current repositories (or lack there of) to these public ones? Who will fund training for federal personnel and current contractors who must now use these repositories?

Lines 344 - 354 - How are individual artifacts in this inventory defined? Where is this inventory maintained and how is it made available? Who is it made available to?

Lines 356 - 362 - Can agencies request updates to this schema? How do they accomplish that? Who will be defining this schema?

Lines 383 - 385 - What is the quarterly Integrated data collection? Who performs this collection? How is the data used? Is that data available to the public? Same for PortfolioStat, IT dash etc.

Lines 404 - 412 - I think these exemptions and general reasons should be captured in meta data found in the enterprise code inventory. I know this is stated later but I wanted to make it clear that it was part of the schema.

Lines 409-410 - I would even go so far as to say that there should be some automated process to scan code before it would be uploaded to the national open source repository so that we could prevent such information from being uploaded. We could also require that the uploader confirm that they understand they are held responsible for the information that is uploaded.

Line 412 - Please give examples to clarify.

Line 431 Please define source code.

Line 431 - 435 What about code that has neither been funded by nor used by the federal government but has been uploaded to the publicly accessible federal code repository?

Line 452 - remove frivolous use of "agile". Agile is a formal set of principles that dictate a certain engineering development life cycle model. This policy should not dictate the development model used for a particular system. This needs to be left up to the managers of the system so that they can pick the model which meets their needs. There is no development lifecycle model that can meet the needs of all systems. This document needs to refrain from using such language.

Line 461 - Regarding the mention of opensource.org. What is the approving process for determining licences and other definitions? What influence does sponsorship have on the standards that this site recommends? I think the definition of open license and which open licenses are accepted should follow the same model as the source code that falls under these licenses. I mean to say that the decision making process should be transparent and input should be accepted from the general public. I think the federal government should list the specific open source licenses that are considered acceptable for this open source code policy or it should have representation on any board that has been tasked to do so. There are possibly many other groups whose aims are similar to but conflict with opensource.org. I think it is important that the federal government does not appear to give preferential treatment in this case. What is the relationship between opensource.org and project-open-source.cio.gov (if any)?

Line 489 - 494 - I believe the definitions of software, computer databases and computer software documentation need to be updated in 48 CFR 2.101. Part ii. of software definition and the definition of software documentation have overlap which should not exist when trying to draw a distinction. Specifically, Design details, algorithms, processes, flow charts, formulas, that allow programs to be produced or created could also be defined by computer software documentation. By definition of software, I am not convinced that a computer database should not be considered software. That is dictated by house the specific data in the computer database is used.

489 - 500 - These two definitions should have a direct relation by using common language in their definitions.

496 - 497 - What does it mean to be readable by people? A picture is not “readable” however it could be used as source code. Are we referring to any person or the general human population? I think this needs a more specific description. A possible definition of source code could be any information that could be represented by binary data and/or cause some machine function. I believe that a broad definition, such as this, could easily be abused. I think we should ensure that we cover any Esoteric languages in our definition. Here are some examples: https://en.wikipedia.org/wiki/Esoteric_programming_language

497 - 498 - Is this to say that only the precompiled/interpreted data is considered source code? It might be beneficial to define compiled and or interpreted.

498 - 500 - This is not part of source code definition and should be stated else where.

This is related to source code because the legal ability to use it often depends on patents. Its debatable what rights opensource licenses give when they say you can use, modify, and distribute. Its my opinion that if a patent owner says you can use, modify, and distribute something which their patent describes, they need not mention patents since it is a logical dependency of what they offered. But usually opensource is not released by the relevant patent owners. We live under potential legal attack for many things we dont even know about. Most choose to ignore danger until its too late, investing our efforts into opensource that may not legally be usable.

A government is a process done for the people and should not be in business for its own profit, such as licensing its patents for money or saying who can and cant use them.

Also, as much of the world is angry at USA for various reasons, that could be improved by releasing all government owned patents to public-domain would help everyone and nobody would lose the ability to do what those patents describe.

A patent has 2 functions: To improve the reputation of inventors by proving they invented something, and to prevent others from using it by default, possibly allowing it in some cases.

Its great to know who invented things, but the other function of patents, to prevent others from using it, is not something governments should do. It is a selfish act, and we should want our government to be altruistic.