search

WhiteHouse / source-code-policy

Federal Source Code Policy
https://sourcecode.cio.gov
Other
249 stars 92 forks source link

Current Lack of Emphasize Social Justice / Civil Liberties / Implications for Education #99

Closed pikurasa closed 8 years ago

pikurasa commented 8 years ago

@freephile addresses some issues in pull request https://github.com/WhiteHouse/source-code-policy/pull/78

...however, the more I read it I realize that there is a fundamental flaw. The flaw is that it does not target they real issue--social justice.

I am trying to create a patch, but this is sum of issue:

  1. The emphasis is mainly on efficiency and cost savings. However, this is merely a by-product of having freedom. The government desires this freedom in their technology solutions, and as a matter of principle they would like to make it public.
  2. There is some confusion in the proposal's current language between the concepts of a) software freedom and b) private vs. public.
  3. The U.S. government really should be striving to run on 100% free/libre software, for its own sake and for the sake of its citizens.
  4. As an educator, I would appreciate if the benefits for education were included. Citizens, if given access to the source code, would then have something to study--to learn from. To the extent that the U.S. government publishes its source code both a) under a free software license and b) publicly, its citizens may use that source code to better their own lives--and not just as users, but as learners/teachers as well.

I will do my best to work with what I have been given here to create an adequate solution to this issue. Thank you!

pikurasa commented 8 years ago

I emailed my latest draft to sourcecode@omb.eop.gov last night but have yet to see it published here, so I will copy and paste below. Thank you!

To: sourcecode@omb.eop.gov Subject: Suggested Edits to the Source Code Policy Date: Mon, 18 Apr 2016 21:27:53 -0400 ---[email start]---

To Whomever it may Concern,

Below (and attached) are my suggested changes to the source code policy.

I am a music teacher and not skilled at coding, but I understand the implications of licensing for everyday users. As an educator, I understand the implications of licensing for education. As a U.S. citizen, I understand the need for civil liberties, equality, and social justice. That is why I stand by the recommendations made by the Free Software Foundation (https://www.fsf.org/blogs/community/u-s-federal-source-code-policy-fsf-supports-and-urges-improvements-comment-by-april-18).

The draft below is my attempt to adapt the language your agency provided to better fit the FSF's recommendations (before the deadline for submissions), and thereby better aligning the language of the document with the founding principals of the United States of America. It is not yet perfect, but a better start toward a policy that puts American citizens' rights and freedoms first.

Thank You, Devin Ulibarri

layout: page

title: Federal Source Code Policy

permalink: /

description: "Introduction for Public Comment"

Introduction for Public Comment

The White House committed to adopting a Government-wide Free Software policy in its Second Open Government National Action Plan that "will support improved access to custom software code developed for the Federal Government," emphasizing that using and contributing back to free software can fuel innovation, lower costs, and benefit the public.1 In support of that commitment, today the White House Office of Management and Budget (OMB) is releasing a draft policy to improve the way custom-developed Government code is acquired and distributed moving forward. This policy is consistent with the Federal Government’s long-standing policy of ensuring that "Federal investments in IT (information technology) are merit-based, improve the performance of our Government, and create value for the American people."<sup id="fnr2">2

This policy requires that, among other things: (1) new custom code whose development is paid for by the Federal Government be made available for reuse across Federal agencies; and (2) a portion of that new custom code be released to the public as Free Software (FLOSS).

We welcome your input on this innovative draft policy. We are especially interested in your comments on considerations regarding the release of custom code as FLOSS. The draft policy proposes a pilot program requiring covered agencies to release at least 20 percent of their newly-developed custom code, in addition to the release of all custom code developed by Federal employees at covered agencies as part of their official duties, subject to certain exceptions as noted in the main body of the policy.3

Considerations regarding releasing custom code as Free Software include:

Considerations Regarding Releasing Custom Code as Free Software

  • To what extent is the proposed pilot an effective means to fuel innovation, lower costs, benefit the public, and meet the operational and mission needs of covered agencies?
    • Would a different minimum percentage be more or less effective in achieving the goals above?
    • Would a "free software by default" approach that required all new Federal custom code to be released as FLOSS, subject to exceptions for things like national security, be more or less effective in achieving the goals above?
    • Is there an alternative approach that OMB should consider?
  • What are the advantages and disadvantages associated with implementing this type of pilot program? To what extent could this policy have an effect on the software development market? For example, could such a policy increase or decrease competition among vendors, dollar amounts bid on Federal contracts, or total life-cycle cost to the Federal Government? How could it impact new products developed or transparency in quality of vendor-produced code?
  • What metrics should be used to determine the impact and effectiveness of the pilot proposed in this draft policy, and of a free software policy more generally?
  • What opportunities and challenges exist in Government-wide adoption of a free software policy?
  • How broadly should a free software policy apply across the Government? Would a focus on particular agencies be more or less effective?
  • This policy addresses custom code that is created by Federal Government employees as well as custom code that is Federally-procured. To what extent would it be appropriate and desirable for aspects of this draft policy to be applied in the context of Federal grants and cooperative agreements?
  • How can the policy achieve its objectives for code that is developed with Government funds while at the same time enabling Federal agencies to select suitable software solutions on a case-by-case basis to meet the particular operational and mission needs of the agency? How should agencies consider factors such as performance, total life-cycle cost of ownership, security and privacy protections, interoperability, ability to share or reuse, resources required to later switch vendors, and availability of support?

Thank you for taking the time to participate in the development of this Federal policy. We look forward to receiving your comments and working together to solidify our commitment to efficiency and openness in Government.

The proposed guidance is now open for public comment on this page. The public comment period will last 30 days, closing on April 11, 2016. Following the public comment period, feedback received will be analyzed to help inform the development of any final policy.

Instructions for Public Comment

You may provide feedback in one of three ways. We ask that you do not submit the same comment more than once.

  1. Content suggestions and discussions are welcome via GitHub "issues." Each issue is a conversation initiated by a member of the public. We encourage you to browse and participate in discussions on existing issues, or start a new conversation by opening a new issue.
  2. Direct changes and line edits to the content are welcome through "pull requests" by clicking "Edit this page" (if prompted, follow the instructions to “Fork this repository and propose changes”). You do not need to install any software to suggest a change. You can use GitHub's in-browser editor to edit files and submit a pull request for your changes to be merged into the document. Directions on how to submit a pull request can be found here. Pull requests that have already been submitted for the proposed guidance can be found here.
  3. We are also accepting content suggestions or proposed revisions through emails sent to the OMB Office of the Federal Chief Information Officer at sourcecode@omb.eop.gov. Please note that all comments received will be posted publicly here.

Footnotes

layout: page title: Federal Source Code Policy | Introduction permalink: /introduction/

description: ""

Introduction

The U.S. Government is committed to improving the way Federal agencies buy, build, and deliver information technology (IT) and software solutions to better support cost efficiency, mission effectiveness, and the consumer experience with core Government programs. Each year, the Federal Government spends more than $9 billion on software through more than 50,000 transactions.1 A large portion of Government software—including proprietary, <a href="https://www.gnu.org/philosophy/free-sw.html.en">free software, and mixed source options—is commercially-available "off the shelf" (COTS) software2 that is developed and owned by either proprietary software vendors or a free software provider, requiring no additional custom code to be written for its use in the Federal Government.<a href="#fn3">3

However, when Federal agencies are unable to identify an existing Federal or COTS software solution that satisfies their specific needs, an agency may choose to develop a custom software solution on its own or pay for its development. When agencies procure custom-developed code, they are not always in a position to make their new code broadly available for Federal Government-wide reuse.<a href="#fn4">4

In some cases, agencies may have difficulty establishing under the terms of the contract that the software was produced in the performance of a Federal Government agreement. Furthermore, even when agencies are in a position to make their code available on a Government-wide basis, they do not routinely make their source code discoverable and usable to other agencies in a consistent manner. These shortcomings can result in duplicative acquisitions for the same code and inefficient spending of taxpayer dollars. This policy seeks to address these challenges by laying out steps to help ensure that new custom-developed Federal source code be made broadly available for reuse across the Federal Government.5 This is consistent with the Digital Government Strategy's "Shared Platform" approach, which enables Federal employees to work together—both within and across agencies—to reduce costs, streamline development, apply uniform standards, and ensure consistency in creating and delivering information.6 Enhanced reuse of custom-developed code across the Federal Government can have significant benefits for American taxpayers, such as reducing Federal vendor lock-in,7 decreasing duplicative costs for the same code, increasing transparency across the Federal Government, and minimizing the challenges associated with integrating large blocks of code from multiple sources.

While the benefits of enhanced Federal code reuse are significant, additional benefits can accrue when code is also made available to the public as Free Software (FLOSS). Making code available with an FLOSS license can enable continual improvement of Federal code projects when a broader community of users implements the code for its own purposes and publishes bugs and improvements. A number of private sector companies have already shifted some of their software development projects to a free software model,8 in which the source code of the software is made broadly available to the public for inspection, improvement, and reuse. In fact, several Federal agencies and component organizations also have already begun publishing custom-developed code under free software licenses or in the public domain, as discussed further below. Moreover, the Administration made a commitment, as part of its Second Open Government National Action Plan,9 to develop an Open Source Software policy that, together with the U.S. Digital Services Playbook,10 will support improved access to custom code developed for the Federal Government. This policy fulfills that commitment in an effort to improve U.S. Government software development and make the Government more open, transparent, and accessible to the public. Just as the Administration's Open Data Policy11 contributed to the creation of valuable and successful private businesses and services based upon open data released by the Government,<sup id="fnr12">12 improving access to taxpayer-funded source code can help facilitate similar results predicated on FLOSS.

Footnotes

layout: page title: Federal Source Code Policy | Objectives permalink: /Objectives/

description: ""

1. Objectives

This policy will accomplish the following objectives:

  1. Bring social justice and equality to American citizens through the government's adoption and procurement of Free Software solutions, while making the software tools publicly accessible.
  2. Provide guidance to covered agencies<a href="#fn13">13 on software procurement considerations that must be made prior to acquiring any custom-developed software. This applies only to software developed in the performance of a Federal agreement;
  3. Establish policy requirements for Government-wide source code receipt and reuse, including requirements for covered agencies to require delivery of source code produced in the performance of a Federal Government agreement and, subject to certain exceptions,<sup id="fnr14">14 make it broadly available Government-wide;
  4. Establish requirements for releasing code in the public domain or as FLOSS, including requirements for covered agencies to secure the rights necessary to make some custom-developed source code releasable to the public as FLOSS; and
  5. Provide instructions and support to facilitate implementation of this policy.

Footnotes

layout: page title: Federal Source Code Policy | Scope and Applicability permalink: /Scope/

description: ""

2. Scope and Applicability

The requirements outlined in this policy apply to all covered agency agreements that (1) relate to Federally-procured software solutions; and (2) include requirements for, or may result in, custom-developed source code. Source code developed for National Security Systems, as defined in 44 U.S.C. §3542, is exempt from the requirements of this policy. For National Security Systems, agencies shall follow applicable statutes, Executive Orders, directives, and internal agency policies.

This policy does not require that existing custom-developed source code created by third party developers or vendors for the Federal Government be retroactively made available for Government-wide reuse or as FLOSS; however, making such code available for Government-wide reuse or as FLOSS, to the extent permissible under existing contracts or other agreements, is strongly encouraged. This policy also does not apply to software code whose development was not paid for by the Federal Government, even if later procured by the Federal Government (e.g., "Microsoft Word", which is proprietary software and whose copyright is held with a 3rd party company).

Furthermore, this policy applies to all custom code created by covered agency employees in the course of their official duties, subject to certain exceptions noted below. For such code, it is encouraged that covered agencies apply the requirements of this policy retroactively to the extent practicable.

The covered agencies' Chief Information Officers (CIO), Chief Acquisition Officers (CAO) and other key stakeholders shall immediately begin working together to implement this guidance.

layout: page title: Federal Source Code Policy | Software Procurement Considerations permalink: /Procurement/

description: ""

3. Software Procurement Considerations

The U.S. government is would like to adopt a policy that considers software freedom for its agencies and for its citizens. Software freedom will benefit the U.S government in many ways, but it will also benefit U.S. citizens when made publicly available and therefore the government will strive to move from proprietary solutions to entirely free software solutions all while maintaining a public distribution of the developed software.

In meeting their software needs, covered agencies should give preference to existing Federal software solutions (e.g., Federal shared services or existing reusable source code) or a purchasable off-the-shelf software solutions (e.g., COTS) that can efficiently and effectively meet their operational and mission needs. When a covered agency determines that these alternatives do not meet its needs, the agency may need to procure custom-developed source code built from scratch or built on top of a proprietary solution.

Consistent with OMB policy, in the course of deciding whether a custom solution is necessary, covered agencies must conduct the following three-step analysis (as illustrated in Appendix B). This analysis is intended to mitigate unnecessary spending on custom-developed software solutions by ensuring that existing Federal and commercial solutions, including existing proprietary and/or free software solutions and reusable code, are considered as potential alternatives. In any of the following steps, covered agencies may consider hybrid solutions (i.e., those containing a mixture of existing, COTS, and/or custom solutions) if a preexisting Federal software solution or COTS solution does not—on its own—fully meet the covered agency's operational and mission needs.15 Furthermore, consistent with OMB policy, covered agencies must evaluate safe and secure cloud computing options throughout every step of the software procurement analysis.16 These steps are consistent with the long-standing OMB policy commonly known as "Raines' Rules."17

Footnotes

layout: page title: Federal Source Code Policy | Government-wide Code Reuse permalink: /Reuse/

description: ""

4. Government-Wide Code Reuse

Under U.S. copyright law, all software created by Federal Government employees as a “government work” is in the public domain and, accordingly, is not subject to copyright protection in the United States.20 However, software created on behalf of the Government by third parties, such as private sector vendors, is subject to copyright protection. Currently, the majority of software solutions used in the Federal Government are developed by third parties and therefore its copyright is held with the respective vendors--the vast majority of whom choose a restrictive, proprietary license.

As discussed earlier, the reuse of custom-developed source code purchased by the Federal Government has numerous benefits for American taxpayers. To take advantage of these benefits, all covered agencies and component organizations that procure custom-developed software solutions for the Federal Government must, at a minimum, comply with the following requirements:

  1. Require delivery of the underlying custom source code, associated documentation, and related files—from the third-party developer or vendor to the Federal organization (including build instructions and, when applicable, software user guides, other associated documentation, and automated test suites); and
  2. Secure unlimited rights to the custom source code, associated documentation, and related files—which includes the rights to reproduction, reuse, and distribution of the custom source code, associated documentation, and related files across the Federal Government.

Covered agencies that enter into agreements for the development of software should require unlimited data rights in accordance with this policy. Additional guidance, including sample language for agreements, shall be provided as a part of Project Open Source.<a href="#fn21">21

Securing Federal Government-wide reuse rights for custom code is a critical first step in gaining efficiencies in Federal software purchasing; however, without broad and consistent dissemination of the code across the Federal Government, these efficiencies cannot be fully realized. Therefore, in addition to securing the rights discussed above, covered agencies must make custom-developed code available to all other Federal agencies.22 The "Implementation" section of this policy provides additional guidance on this requirement.

Note that although Government-wide reuse of custom-developed code shares some of the same benefits as FLOSS, it does not meet the definition of FLOSS23 and should therefore not be mislabeled as such.

Footnotes

layout: page title: "Federal Source Code Policy | Federally Funded Custom Code as Free Software" permalink: /FLOSS/

description: ""

5. Federally Funded Custom Code as Free Software

As previously mentioned, a number of private sector companies have shifted some of their software use and development to a free software model.24 Similarly, when properly implemented and documented, releasing code as free software can benefit Federal agencies by allowing professional communities of practice to develop around software libraries and Application Programming Interfaces (APIs). This collaborative atmosphere makes it easier to conduct software peer review and security testing, to reuse existing solutions, and to share technical knowledge.<a href="#fn25">25 In fact, the Federal Government and partner organizations have recently begun using more FLOSS and publishing some of their custom software code under free software licenses or in the public domain. Some examples include:

As outlined in the OMB Open Government Directive,<a href="#fn32">32 the three principles of transparency, participation, and collaboration form the cornerstone of an open government. Federally released FLOSS embodies these principles. Leveraging the skills and knowledge of individuals across the Federal Government and beyond can result in, among other things, enhancements to code quality and security as a result of public scrutiny of free software code.33 Federal FLOSS can also contribute to economic growth and innovation as state and local governments, private sector companies, taxpayers, and others can reuse that code to develop products and services for the public.<sup id="fnr34">34

5.1 Pilot Program

In furtherance of the objectives outlined in the Open Government Directive, this policy requires that covered agencies participate in the following pilot program to encourage the development and publication of custom-developed Government code as FLOSS.

Each covered agency shall release 100 percent of its newly-developed custom code each year as FLOSS. Custom code is defined as code for all custom software projects, modules, and add-ons that are self-contained.35 When deciding which custom code projects to release, each covered agency should prioritize the release of custom code that it considers potentially useful to the broader community.<a href="#fn36">36

Within 120 days of the publication of this policy, OMB shall develop metrics to assess the impact of the pilot program. No later than two years after the publication date of this policy, OMB shall consider whether to issue a subsequent policy to continue, modify, eliminate, or expand the pilot program. Unless extended by OMB through the issuance of further guidance, the pilot program will expire three years (36 months) after the publication date of this policy. Please refer to the "Implementation" section of this policy for additional guidance on how to comply with the requirements of the pilot program.

5.2 Membership in the Free Software (FLOSS) Community

Communities are critically important to the long term viability of free software projects. Consistent with the Digital Government Strategy's principles to participate in free software communities and leverage public crowdsourcing, covered agencies should develop and release code in a manner that (1) fosters communities around shared challenges; (2) optimizes the ability of the community to provide feedback on, and make contributions to, the code; and (3) encourages Federal employees and contractors to contribute back to the broader FLOSS community by making contributions to existing free software projects. In furtherance of this strategy, covered agencies must comply with the following principles:

  1. Protect U.S. Citizens' Civil Liberties Free Software lincenses are the only licenses that afford its users the liberties they need to use, share, study, modify, and redistribute their software tools. By moving to free software solutions, the U.S. government is choosing to protect its own freedoms. Additionally, by making such software available to the public, the U.S. government offers software that affords its citizens the same liberties.
  2. Leveraging Existing Communities – Whenever possible, custom code released to the public as FLOSS should be incorporated into existing communities of practice that are self-sustaining. For example, there are already existing communities for electronic health records and geospatial software.37 Government agencies should only develop their own communities when existing communities do not satisfy their needs.
  3. Open Development – Software that is custom-developed for or by covered agencies should, to the extent possible and appropriate, be developed in the open. Open development practices provide an environment in which free software code can flourish and repurposed. This principle, as well as the principle for "Releasing Code" below, shall include the distribution of a minimum viable product as free software code, engaging the public before official release,38 and drawing upon the public's knowledge for bug fixes, algorithmic optimization, and other improvements to the project.
  4. Incremental Release – In instances where software cannot be developed in the open, but is otherwise appropriate for release to the public, covered agencies must develop and use an incremental release schedule and undertake all necessary steps to make the code and associated documentation available for public use. This will assist in discouraging the practice of releasing large, bulk pieces of software code, which negates many of the positive attributes of free software software.
  5. User Engagement – Like in the Administration's Open Data Policy, covered agencies must create a process to engage in two-way communication with users to solicit help in prioritizing the release of code and feedback on the agencies' engagement with the community. See Project Open Source for best practices and tools that can be used to implement user engagement efforts.
  6. Code Contributions – One of the most powerful potential benefits of FLOSS lies within the communities that grow around FLOSS projects, whereby any party can contribute new code, modify existing code, or make other suggestions to improve the software. Communities can be used to monitor changes to code, track potential errors and flaws in code, and other related activities. These kinds of contributions should be anticipated and, where appropriate, considered for integration into custom-developed Government software or associated materials.
  7. Documentation – It is important to provide FLOSS users and contributors with adequate documentation of source code in an effort to facilitate use and adoption. At a minimum, FLOSS repositories must include a README (or similar) file that includes the following information (note that additional guidance on repositories can be found in the "Implementation" section of this policy):
    1. The status of the software (e.g., prototype, alpha, beta, release, etc.);
    2. The intended purpose of the software;
    3. Expected engagement level (i.e., how frequently the community can expect to be engaged by the agency);
    4. License details; and
    5. Any other relevant technical details on how to build, make, install, or use the software, including library dependencies (if applicable).

5.3 Leverage Educational Opportunity that Free Software Affords

Source Code has an amazing amount of valuable information that can be leveraged as a learning/teaching tool. Free Software allows software to be studied and therefore the public benefits from the freedom of being able to study, modify, and redistribute the source code by learning more about the way the world works. <a href="https://www.gnu.org/education/edu-schools.en.html">https://www.gnu.org/education/edu-schools.en.html

Footnotes

layout: page title: Federal Source Code Policy | Implementation permalink: /Implementation/

description: "Implementation"

6. Implementation

The Federal Information Technology Acquisitions Reform Act (FITARA)<sup id="fnr39">39 creates clear responsibilities for agency CIOs related to IT investments and planning as well as requiring that agency CIOs be involved in the IT acquisition process. OMB’s FITARA implementation guidance—M-15-14: Management and Oversight of Federal Information Technology<a href="#fn40">40—established a "common baseline" for roles, responsibilities, and authorities of the agency CIO and the roles of other applicable Senior Agency Officials<a href="#fn41">41 in managing IT as a strategic resource. Accordingly, the heads of covered agencies must ensure that CIOs are positioned with the responsibility and authority necessary to implement the requirements of this policy in coordination with other Senior Agency Officials. As appropriate, the CIO should also work with the agency's public affairs staff, open government staff, web manager or digital strategist, program owners and other leadership, to properly identify, publish, and work with communities concerning their free software projects.

Project Open Source

Within 90 days of the publication date of this policy, the Administration will launch Project Open Source,<a href="#fn42">42 an online repository of tools, best practices, and schemas to help covered agencies implement this guidance. Project Open Source will be accessible at https://project-open-source.cio.gov. Project Open Source will evolve over time as a community resource to facilitate the adoption of good custom source code development and release practices. Guidance and language on free software licenses will be provided as part of Project Open Source. The repository will include further definitions, evaluation metrics, checklists, case studies, model contract language and more, and will enable collaboration across the Federal Government in partnership with the public.

Code Repositories

Accessible repositories for the storage, discussion, and modification of custom code are a critical portion of both the Government-wide reuse and FLOSS pilot program portions of this policy. Covered agencies should utilize existing code repositories and common third-party repository platforms as necessary to comply with this policy.<a href="#fn43">43 Project Open Source will contain additional guidance on using custom code repositories as related to achieving the objectives of this policy.

Code Inventories and Discovery

Code inventories are a means of discovering information such as the functionality and location of potentially reusable or releasable custom code repositories. Within 90 days of the publication date of this policy, each covered agency must update, and thereafter keep up to date, its inventory of agency information resources (as required by OMB Circular A-130)44 to include an enterprise code inventory that lists all custom code developed for or by the agency after the publication date of this policy. The enterprise code inventory is not intended to house the custom code itself; rather, it is intended to serve as a tool for discovering custom code that may be available for Government-wide reuse or as FLOSS, and to provide transparency into custom software code that is developed using Federal funds. The inventory will indicate whether the code is available for Federal reuse, is available publicly as FLOSS, or cannot be made available due to a specific exception from this policy.

Covered agencies must describe projects within the inventory using extensible metadata that will be described in an inventory schema on Project Open Source. OMB will provide this inventory schema to covered agencies within 60 days of the publication date of this policy. Within 120 days of the publication of this policy, OMB will identify a suitable central location to make the reported FLOSS searchable and discoverable for agencies and the public. Please refer to Project Open Source for best practices, tools, and schema to implement the enterprise code inventory and harvestable files.

Updated TechFAR Guidance

OMB’s Office of Federal Procurement Policy (OFPP) and the U.S. Digital Service (USDS) will update the TechFAR Handbook<a href="#fn45">45 to highlight how agencies can go about securing Federal reuse rights and free software licenses as part of their acquisitions processes.

Agency Policy

Within 90 days of the publication date of this policy, each covered agency CIO must develop an agency-wide policy that addresses the requirements of this memo. In accordance with OMB guidance,<sup id="fnr46">46 these policies will be posted publicly. Moreover, within 90 days of the publication date of this policy, each covered agency’s CIO office must work to correct or amend any policies that are inconsistent with the requirements of this memo, including the correction of policies that automatically treat FLOSS as noncommercial software.

Accountability Mechanisms

Progress on agency implementation of the actions required in this policy will be primarily assessed by OMB through analysis of each covered agency’s internal Government repositories, public FLOSS repositories, and code inventories, as well as data obtained through the quarterly Integrated Data Collection (IDC), quarterly PortfolioStat sessions, the IT Dashboard, and additional mechanisms to be provided via Project Open Source.47

Exceptions to Government-wide Reuse or to Publication

The exceptions provided below may be applied, in specific instances, to exempt a covered agency from (1) sharing custom code with other Government agencies, or (2) publically releasing custom code that is developed by covered agency employees. Any exceptions used must be approved and documented by the agency’s CIO. Please note that the exceptions below do not exempt a covered agency from acquiring unlimited data rights in newly procured custom code. Moreover, these exceptions do not apply in calculating a covered agency’s codebase for purposes of the FLOSS pilot program; but covered agencies should, as part of their internal 20 percent of custom code selection process, refrain from selecting code that would fit any of the characteristics listed below. In the event that a covered agency’s CIO believes that the agency cannot meet the 20 percent requirement of the FLOSS pilot program because the agency is otherwise prohibited from releasing more than 80 percent of its code, the CIO should consult with OMB.

Applicable exceptions are as follows:

OMB expects exceptions to be rare and the result of a significant Government interest. Excepted software must still be listed in the agency’s enterprise code inventory, with certain redactions allowed. Please refer to Project Open Source for additional guidance on this topic. This memorandum is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.

Footnotes

layout: page title: Federal Source Code Policy | Appendix A - Definitions permalink: /Appendixa/

description: "Appendix A: Definitions"

Appendix A: Definitions

Code Contributions: Source code or other materials written by external parties and submitted to the developers/maintainers of a software project. Some common examples of code contributions are bug fixes, new or improved features, and documentation improvements.

Covered Agency: For purposes of this policy, a covered agency is one that meets the definition of agency under the Federal Information Security Management Act of 2002 (FISMA). See 44 U.S.C. §3502.

Custom Code: Software source code that is written to fulfill a specific purpose that is not already addressed by existing programs or COTS solutions. For the purposes of this policy, custom code development must be fully funded by the Federal Government and is either developed by a contracting entity for use by the Federal Government, or developed by covered agency employees in the course of their official duties.

Derivative Works: For the purposes of this policy, a "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.<sup id="fnr48">48

Mixed Source: A mixed source software solution may incorporate public domain, free software, and/or proprietary code. Developers and users of mixed source software solutions must take component-level intellectual property rights into consideration whenever modifying, reusing, or distributing source code.

Public Development: "Public development" means to publish the source code at a publicly accessible website, so that project(s) under active development can be audited by U.S. citizens and contributions can be made before final release of the software. In the framework of computer software design, it is a process by which developers ensure the highest possible levels of transparency, legibility, testability, and modularity in their code from the start. This process is designed to engage and empower a community in the development of that code in an incremental and agile manner. Open development provides a larger base for quality assurance and product support in the initial phases of a project, in addition to making code easier to read, understand, repurpose, and incorporate for other programmers who may not be able to contact the original coder for support.

Open Source Software: Sometimes something similar to "Free Software" (see definition below) is referred to as "Open Source Software" (OSS). However, OSS connotes an entirely different ideal, which does not align with the values of the United States of America. The definition is also more vague than the official "Free Software" definition (see below)<sup id="fnr49"><a href="#fn49>49. Because of the lack in clarity of the goals of OSS, it is sometimes more restricted than Free Software in that a central authority (corporate owner) sometimes maintains a method of restricting its users and therefore impinging on their freedoms by retaining some exclusive rights to the software and its associated source code, and may distribute the software under more restrictive proprietary terms. These licenses specify how a particular work may be reproduced, modified, or used as a component of a larger system or as a standalone piece of software.<a href="#fn50">50

Free Software (also known as Free/Libre Open Source Software or FLOSS): Software that gives its users the rights to 1) use for any purpose, 2) study the source code 3) share without restriction 4) modify, and redistribute the modified changes. FLOSS is distributed under licenses that comply with the definition of "Free Software" provided by the Free Software Foundation (https://www.gnu.org/philosophy/free-sw.html).<sup id="fnr51">51 The term "Free Software" puts emphasis on civil liberties ("freedom"), the rights of its users, and social justice. These are all ideals that the citizens of the United States of America fight to uphold and therefore the chosen recommended terminology for U.S. national policy decisions.

Proprietary Software: Software with intellectual property rights that are retained exclusively by an individual or a company. Although FLOSS intellectual property rights can also be retained by an individual or a company (through the use of a proper FLOSS license), the term "proprietary software" refers to software that restricts the user of the software in one of the four fundamental freedoms defined by Free Software. For example, proprietary software is typically called "closed-source", in that its source code is not made broadly available to users or the general public without restrictions defined by the owner.

Free Software Directory: An online catalog of existing Free Software (https://directory.fsf.org/).

Public Domain: The set of works for which copyrights and related rights have expired, been relinquished, or do not apply, making the work freely available to the public for any purpose. Under U.S. copyright law, works created by Government employees within the scope of their employment are not subject to domestic copyright protections under 17 U.S.C. §105. Note that this definition is unrelated to the term "public domain" as it is used in export control regulations.

Software: Can refer to either: (i) Computer programs that comprise a series of instructions, rules, routines, or statements, regardless of the media in which recorded, that allow or cause a computer to perform a specific operation or series of operations; or (ii) Recorded information comprising source code listings, design details, algorithms, processes, flow charts, formulas, and related material that would enable the computer program to be produced, created, or compiled. Software does not include computer databases or computer software documentation.<sup id="fnr52">52

Source Code: Information written in a computer programming language that is readable by people. Source code must be interpreted or compiled before a computer can execute the code as a program. Source code readability can benefit from the inclusion of comments or other in-code documentation that indicates the requirements and functionality of specific algorithms and other components.

Footnotes

  • 48 _See_ http://www.copyright.gov/circs/circ14.pdf ↩
  • 49> _See_ https://www.gnu.org/philosophy/open-source-misses-the-point.html ↩
  • 50 As of the publication date of this policy, a valid free software license is one that meets the criteria described by "The Free Software Definition" (https://www.gnu.org/philosophy/free-sw.html). Further licensing considerations, including suggested licenses, will be provided via Project Open Source. ↩
  • 51 This definition is current as of the publication date of this policy. For future guidance regarding this definition, please refer to Project Open Source. ↩
  • 52 Definition from 48 CFR §2.101 ↩

    • layout: page title: "Federal Source Code Policy | Appendix B" permalink: /Appendixb/

    description: ""

    Appendix B: Software Procurement Analysis

    ---[email end]---