├── VERSION ├── .gitignore ├── ARL Form - 266.pdf ├── code.json ├── GLOSSARY.md ├── LICENSE.txt ├── LEGAL_ANALYSIS.md └── README.md /VERSION: -------------------------------------------------------------------------------- 1 | 1.0.4 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /ARL Form - 266.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions/HEAD/ARL Form - 266.pdf -------------------------------------------------------------------------------- /code.json: -------------------------------------------------------------------------------- 1 | { 2 | "version": "1.0.3", 3 | "agency": "DOD", 4 | "projects": [ 5 | { 6 | "name": "The U.S. Army Research Laboratory (ARL) Software Release Process for Unrestricted Public Release", 7 | "organization": "US Army Research Laboratory", 8 | "description": "This document provides procedures that ARL Government personnel MUST follow when releasing software source code and software-related material to the public, and for accepting software-related contributions from the general public.", 9 | "license": "https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions/blob/master/LICENSE.txt", 10 | "openSourceProject": 0, 11 | "governmentWideReuseProject": 1, 12 | "tags": [ 13 | "policy" 14 | ], 15 | "contact": { 16 | "email": "usarmy.adelphi.rdecom-arl.mbx.ARL-Open-Source-policy@mail.mil" 17 | }, 18 | "status": "Production", 19 | "vcs": "git", 20 | "repository": "https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions", 21 | "homepage": "https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions", 22 | "downloadURL": "https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions", 23 | "languages": [ 24 | ], 25 | "partners": [ 26 | ], 27 | "exemption": null, 28 | "exemptionText": "No exemption requested", 29 | "updated": { 30 | "lastCommit": "2017-02-28", 31 | "metadataLastUpdated": "2017-02-28", 32 | "lastModified": "2017-02-28" 33 | } 34 | } 35 | ] 36 | } 37 | -------------------------------------------------------------------------------- /GLOSSARY.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | **AR. 380-10** The U.S. Army 4 | regulation that governs how Army software can be released to the public. 5 | 6 | **AR. 5-11** The U.S. Army 7 | regulation that governs how Army models and simulations may be released to the 8 | public. 9 | 10 | **U.S. Army Research Laboratory 11 | (ARL)** The nation's premier research laboratory for land forces. 12 | 13 | **ARL Form 1** The form and the 14 | process used by ARL for OPSEC review of all publications, including software. 15 | 16 | **ARL-M-5-2** The memorandum 17 | that governs which models and simulations may be released outside of ARL. 18 | 19 | **Cooperative Research and 20 | Development Agreement (CRADA)** An agreement between a Government agency and a 21 | private company or university to work together on research and development. 22 | 23 | **Contributor License Agreement 24 | (CLA)** A legally binding contract that a contributor signs that describes the 25 | rights being transferred with the work that a contributor is giving. 26 | 27 | **Creative Commons Zero (CC0)** 28 | license A license that, as far as is legally permitted in a jurisdiction, 29 | places a work in the public domain. 30 | 31 | **Department of Defense (DOD)** 32 | The portion of the U.S. Government charged with national defense and security. 33 | 34 | **Document object identifier 35 | (DOI)** A code used to uniquely identify an object. On GitHub, these are used 36 | to uniquely identify particular releases of software. 37 | 38 | **Export Administration 39 | Regulations (EAR)** Regulations controlling the release of "dual use" items. 40 | See https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear 41 | for more information. 42 | 43 | **Freedom of Information Action 44 | (FOIA)** The law that governs which Government records MUST be made available 45 | to the public. 46 | 47 | **Government Furnished Property 48 | (GFP)** Property owned by the Government that is provided to a contractor. 49 | 50 | **Government Furnished Software 51 | (GFS)** Software owned by the Government that is provided to a contractor. 52 | 53 | **Invention Evaluation 54 | Committee (IEC)** The committee at ARL charged with deciding if patent 55 | protection should be pursued for an invention. 56 | 57 | **Intellectual property (IP)** 58 | Anything that can be trademarked, copyrighted, or patented under U.S. law. 59 | 60 | **International Traffic in Arms 61 | Regulations (ITAR)** Regulations controlling the export and import of defense- 62 | related articles and services on the United States Munitions List. See 63 | https://www.pmddtc.state.gov/regulations_laws/itar.html for more information. 64 | 65 | **Operational security 66 | (OPSEC)** Practices and procedures put in place to protect U.S. national 67 | security interests. 68 | 69 | **Public Affairs Office (PAO)** 70 | The office at ARL responsible for presenting ARL to the public. 71 | 72 | **Principal developer (PD)** 73 | The developer or developers of a software package that is being proposed for 74 | release under this process. 75 | 76 | **Point of contact (POC)** The 77 | PD or PDs that serve as contacts for questions regarding the project. In 78 | general, all persons listed on the ARL Form 1 as authors will also be POCs for 79 | the project. 80 | -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | Creative Commons Legal Code 2 | 3 | CC0 1.0 Universal 4 | 5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE 6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN 7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS 8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES 9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS 10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM 11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED 12 | HEREUNDER. 13 | 14 | Statement of Purpose 15 | 16 | The laws of most jurisdictions throughout the world automatically confer 17 | exclusive Copyright and Related Rights (defined below) upon the creator 18 | and subsequent owner(s) (each and all, an "owner") of an original work of 19 | authorship and/or a database (each, a "Work"). 20 | 21 | Certain owners wish to permanently relinquish those rights to a Work for 22 | the purpose of contributing to a commons of creative, cultural and 23 | scientific works ("Commons") that the public can reliably and without fear 24 | of later claims of infringement build upon, modify, incorporate in other 25 | works, reuse and redistribute as freely as possible in any form whatsoever 26 | and for any purposes, including without limitation commercial purposes. 27 | These owners may contribute to the Commons to promote the ideal of a free 28 | culture and the further production of creative, cultural and scientific 29 | works, or to gain reputation or greater distribution for their Work in 30 | part through the use and efforts of others. 31 | 32 | For these and/or other purposes and motivations, and without any 33 | expectation of additional consideration or compensation, the person 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she 35 | is an owner of Copyright and Related Rights in the Work, voluntarily 36 | elects to apply CC0 to the Work and publicly distribute the Work under its 37 | terms, with knowledge of his or her Copyright and Related Rights in the 38 | Work and the meaning and intended legal effect of CC0 on those rights. 39 | 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be 41 | protected by copyright and related or neighboring rights ("Copyright and 42 | Related Rights"). Copyright and Related Rights include, but are not 43 | limited to, the following: 44 | 45 | i. the right to reproduce, adapt, distribute, perform, display, 46 | communicate, and translate a Work; 47 | ii. moral rights retained by the original author(s) and/or performer(s); 48 | iii. publicity and privacy rights pertaining to a person's image or 49 | likeness depicted in a Work; 50 | iv. rights protecting against unfair competition in regards to a Work, 51 | subject to the limitations in paragraph 4(a), below; 52 | v. rights protecting the extraction, dissemination, use and reuse of data 53 | in a Work; 54 | vi. database rights (such as those arising under Directive 96/9/EC of the 55 | European Parliament and of the Council of 11 March 1996 on the legal 56 | protection of databases, and under any national implementation 57 | thereof, including any amended or successor version of such 58 | directive); and 59 | vii. other similar, equivalent or corresponding rights throughout the 60 | world based on applicable law or treaty, and any national 61 | implementations thereof. 62 | 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention 64 | of, applicable law, Affirmer hereby overtly, fully, permanently, 65 | irrevocably and unconditionally waives, abandons, and surrenders all of 66 | Affirmer's Copyright and Related Rights and associated claims and causes 67 | of action, whether now known or unknown (including existing as well as 68 | future claims and causes of action), in the Work (i) in all territories 69 | worldwide, (ii) for the maximum duration provided by applicable law or 70 | treaty (including future time extensions), (iii) in any current or future 71 | medium and for any number of copies, and (iv) for any purpose whatsoever, 72 | including without limitation commercial, advertising or promotional 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each 74 | member of the public at large and to the detriment of Affirmer's heirs and 75 | successors, fully intending that such Waiver shall not be subject to 76 | revocation, rescission, cancellation, termination, or any other legal or 77 | equitable action to disrupt the quiet enjoyment of the Work by the public 78 | as contemplated by Affirmer's express Statement of Purpose. 79 | 80 | 3. Public License Fallback. Should any part of the Waiver for any reason 81 | be judged legally invalid or ineffective under applicable law, then the 82 | Waiver shall be preserved to the maximum extent permitted taking into 83 | account Affirmer's express Statement of Purpose. In addition, to the 84 | extent the Waiver is so judged Affirmer hereby grants to each affected 85 | person a royalty-free, non transferable, non sublicensable, non exclusive, 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the 88 | maximum duration provided by applicable law or treaty (including future 89 | time extensions), (iii) in any current or future medium and for any number 90 | of copies, and (iv) for any purpose whatsoever, including without 91 | limitation commercial, advertising or promotional purposes (the 92 | "License"). The License shall be deemed effective as of the date CC0 was 93 | applied by Affirmer to the Work. Should any part of the License for any 94 | reason be judged legally invalid or ineffective under applicable law, such 95 | partial invalidity or ineffectiveness shall not invalidate the remainder 96 | of the License, and in such case Affirmer hereby affirms that he or she 97 | will not (i) exercise any of his or her remaining Copyright and Related 98 | Rights in the Work or (ii) assert any associated claims and causes of 99 | action with respect to the Work, in either case contrary to Affirmer's 100 | express Statement of Purpose. 101 | 102 | 4. Limitations and Disclaimers. 103 | 104 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 105 | surrendered, licensed or otherwise affected by this document. 106 | b. Affirmer offers the Work as-is and makes no representations or 107 | warranties of any kind concerning the Work, express, implied, 108 | statutory or otherwise, including without limitation warranties of 109 | title, merchantability, fitness for a particular purpose, non 110 | infringement, or the absence of latent or other defects, accuracy, or 111 | the present or absence of errors, whether or not discoverable, all to 112 | the greatest extent permissible under applicable law. 113 | c. Affirmer disclaims responsibility for clearing rights of other persons 114 | that may apply to the Work or any use thereof, including without 115 | limitation any person's Copyright and Related Rights in the Work. 116 | Further, Affirmer disclaims responsibility for obtaining any necessary 117 | consents, permissions or other rights required for any use of the 118 | Work. 119 | d. Affirmer understands and acknowledges that Creative Commons is not a 120 | party to this document and has no duty or obligation with respect to 121 | this CC0 or use of the Work. 122 | -------------------------------------------------------------------------------- /LEGAL_ANALYSIS.md: -------------------------------------------------------------------------------- 1 | # Legal Analysis - Software Protection & Release Mechanisms 2 | 3 | "Software," as that term is used herein, means computer programs, executables, 4 | source code, and object code. Software does not include computer databases or 5 | software documentation. Additionally, although design details, algorithms, 6 | processes, flowcharts, formula, and related material that would enable a 7 | particular piece of ARL software, or a functional equivalents thereof, to be 8 | reproduced or created are not considered "Software", their premature release 9 | may jeopardize IP protection and commercialization of software to which they 10 | relate. 11 | 12 | ## Forms of Intellectual Property Protection for Software 13 | ### Patent 14 | 15 | Software that meets the statutory or legal requirements may be patentable 16 | under U.S. Patent Law. In other words, the software must constitute a 17 | patentable invention. Once a patent application (provisional or non- 18 | provisional) is on file with the U.S. Patent and Trademark Office, the 19 | Government's rights in the invention are preserved although there is no 20 | guarantee that a patent will ultimately be issued. 21 | 22 | ### Copyright 23 | 24 | Software can be protected under U.S. Copyright Law as a literary work. 25 | Copyright protection attaches as soon as the work is expressed in a tangible 26 | medium of expression. However, software created solely by civil servants as 27 | part of their jobs is considered a U.S. Government work to which U.S. 28 | copyright protection is not available. There are different opinions on the 29 | ability to assert foreign copyright even though the software is a U.S. 30 | Government work. In any case, the Government may obtain and hold copyright 31 | transferred to it. The copyright only protects the expression that the 32 | software code takes and does not protect the underlining algorithms or 33 | processes. Algorithms and processes are best protected by attempting to 34 | obtain a patent. Due to the nature of software being both a literary work and 35 | invention it can be protected by both a copyright and patent. 36 | 37 | ### Ability to Withhold Release to the Public ("like a trade secret") 38 | 39 | In the private sector, software (usually the source code) can be protected as 40 | a trade secret. In the Government, it has been held that certain software is 41 | not a "Government record" under the Freedom of Information Act (FOIA) that 42 | would require its release. Thus, the ability to withhold its release creates 43 | a certain level of protection of the software. Moreover, in accordance with 44 | the authority in SEC. 801 of Public Law 113-66, software may be exempt from 45 | disclosure under section 552 of title 5, United States Code, for a period of 46 | five years after the development of the computer code. Should a release be 47 | contemplated, conditions could include nondisclosure and copyright like 48 | restrictions based on contract principles. 49 | 50 | ### Trademark 51 | 52 | Trademark protection is established through use in commerce on goods and 53 | services. Additional protection can be obtained through the federal 54 | registration process. The proper use of the name selected for a particular 55 | piece of software as a trademark will go a long way to establishing 56 | protection. 57 | 58 | Whenever a new name is being coined for computer software it should be 59 | referred to as "ARL Trademark" as opposed to just "Trademark." For example, 60 | just as Microsoft Word and Microsoft Excel refer to Microsoft's word 61 | processing and spreadsheet software, respectively, ARL would benefit by having 62 | its corporate name preceding newly coined software. This is especially 63 | important for software ARL plans to publicly distribute. The ARL is already a 64 | federally registered trademark that works as our "house brand." 65 | 66 | Always use a Trademark as a proper adjective together with the generic name of 67 | the product. The Trademark (adjective) modifies the generic term (noun). To 68 | avoid a Trademark from becoming generic never use a Trademark as a common noun 69 | or by using a plural form (adding s) or a possessive form (adding s). Never 70 | use a Trademark as a verb. Example: to the extent "xerox" is used as a verb 71 | (to copy something), it lessens the value of the term as a Trademark. Use of 72 | "Brand" following a Trademark is especially helpful to combat generic 73 | tendencies. For example, repeated reference to SCOTCH tape as SCOTCH Brand 74 | cellophane tape (or SCOTCH cellophane tape) helps remind consumers that SCOTCH 75 | is a Brand name for tape from a single source, i.e., the 3M Company. In 76 | contrast, repeated reference to just SCOTCH tape, without following it with 77 | the word Brand or cellophane, may ultimately lead consumers to think SCOTCH is 78 | a generic term for cellophane tapes from any source. 79 | 80 | ## Intellectual Property Assessment 81 | 82 | The software needs to be reported to the IP Law Branch. The IP Law Branch 83 | will make an IP assessment to determine ARL's rights and ability to release 84 | the software. 85 | 86 | ## OPSEC Review 87 | 88 | All projects proposed for release must undergo an OPSEC review by undergoing 89 | the ARL Form 1 process. OPSEC is a process used to identify and deny critical 90 | information (specific information about capabilities and/or intentions) from 91 | adversaries who seek to exploit such information for their advantage and our 92 | disadvantage. The OPSEC process involves systems threat and vulnerability 93 | analyses, risk assessment, and cost-effective countermeasure planning and 94 | implementation. Its results include improved understanding of the following: 95 | 96 | * the specific items deemed critical to the mission, 97 | * indicators of that information, 98 | * countermeasures that protect this information from the adversary, and 99 | * an analytical basis for these decisions, if the process is applied properly. 100 | 101 | ## Patent Review 102 | 103 | Recognize that it is the intent of the patent system to eventually disclose 104 | the invention described in a non-provisional patent application to the public. 105 | Unless a patent applicant specifically requests otherwise, the U.S. Patent & 106 | Trademark Office will publish the patent application after 18 months. Even if 107 | an applicant has requested that the application not publish after 18 months, 108 | any patent that ultimately issues will be publicly available. Patent 109 | applications filed on classified and other critically sensitive inventions 110 | will be placed under secrecy orders. Thus, each invention being considered 111 | for patenting needs to have an OPSEC review and ARL Form 1 completed so that 112 | ARL Legal knows whether or not details of the invention can be released to the 113 | public. 114 | 115 | ## Types of Releases and Options 116 | 117 | ### Releases of Army Model and Simulation Software (MOA) 118 | 119 | There is a specific Army regulation concerning the release of model and 120 | simulation software (Army Regulation 5-11, Management of Army Models and 121 | Simulations). The party requesting the software must have a valid requirement. 122 | For release to other U.S. Government agencies, U.S. contractors, and federally 123 | funded research and development centers (FFRDCs), the release approval 124 | authority is the major Army command (MACOM) commander or agency head of the 125 | organization, which is the model and simulation proponent of the requested 126 | software. Designation of release approval authority can be delegated to lower 127 | levels as defined in Appendix B-2. (AR 5-11, 8-3, Release Approval Authority). 128 | The ARL has a companion policy document ARL-M-5-2, Release of Models and 129 | Simulations Outside ARL. 130 | 131 | ### Releases to Contractors 132 | 133 | The preferred approach for providing Government-furnished property (GFP), 134 | including Government-furnished software (GFS), to a company under a Government 135 | contract is through the contract, either at the beginning of the effort or 136 | through a contract modification. In either case, a Contracting Officer with 137 | the authority to bind the Government signs on behalf of the Government. The 138 | decision to provide GFS should be made only after careful consideration of all 139 | relevant factors. Providing software to a contractor through a separate 140 | letter agreement from the technical organization having custody of the 141 | software is not the best mechanism to use. The technical person signing the 142 | letter may not have the authority to transfer the software. If a letter is 143 | being used because the thought is that a contract modification is too 144 | burdensome, then a "standard" contract mod to provide GFS could be created to 145 | facilitate the process. 146 | 147 | ### Beta Test Agreement 148 | 149 | Software has been released by ARL to companies that sometimes also happen to 150 | be Government contractors for beta testing. Issues include the following: 151 | 152 | #### Voluntary Services vs. Gratuitous Services. 153 | 154 | As long as the arrangement does not amount to acceptance of voluntary services 155 | for which the beta testing party could file a claim but, instead, is 156 | structured as "gratuitous services", where the individual agrees (often in 157 | writing in advance) to perform the services and will not request payment, such 158 | an arrangement would not be considered to violate the Anti-deficiency Act (31 159 | U.S.C. 1342). 160 | 161 | #### Under what authority can ARL provide software to a company for beta testing? 162 | 163 | A sample Beta Test Agreement ARL has used in the past does not include a cite 164 | to any authority. One approach might be to enter into a no cost contract, 165 | which would be signed by a contracting officer. Again, there must be some 166 | sort of value or consideration for the contractor as there would be no 167 | exchange of money. 168 | 169 | ### Patent Licenses 170 | 171 | A patent license basically grants permission to a licensee to use the 172 | invention without the fear of infringement. Generally, patent licensees want 173 | to use software covered by the patent in one of three ways: (1) the licensee 174 | wants to sell a software program as a standalone commercial product, (2) the 175 | licensee wants to integrate the software into one of its own existing 176 | commercial products, or (3) the licensee wants to use the software for its own 177 | internal purposes. Thus, the scope of the license must be tailored to fit the 178 | circumstance. A patent application (provisional or non-provisional) should be 179 | on file with the U.S. Patent and Trademark Office before a license is entered 180 | into. The Director of ARL has authority to grant patent licenses under 15 181 | U.S.C. 3710a. Royalties negotiated and collected under a patent license are 182 | shared with the inventors listed on the patent and any balance remaining may 183 | be retained by the laboratory. 184 | 185 | ### Copyright Licenses 186 | 187 | A copyright license grants permission to a licensee to do one or more of the 188 | following: (1) reproduce the work, (2) distribute the work, (3) prepare 189 | derivative works, and (4) display or perform the work publicly. Although 190 | Government works (i.e., those created by civil servants under the scope of 191 | their employment) are not protected by U.S. copyright, ARL may obtain 192 | copyright on software through an assignment to the Government. The Director 193 | of ARL is the official delegated to license the laboratory's IP, which could 194 | arguably include copyright assigned to the Government. However, any royalties 195 | collected under a copyright license are considered to fall under the 196 | miscellaneous receipts statute and must be forwarded to the U.S. Treasury. 197 | 198 | ### SEC 801 Licenses 199 | 200 | SEC. 801 of the FY14 National Defense Authorization Act, Public Law 113-66, 201 | provides new authority, and assigns responsibilities and procedures for DOD 202 | licensing of computer software and related documentation developed at a DOD 203 | Laboratory. Royalties collected are to be shared with the software 204 | developers. [Waiting for DOD implementation of policy and delegations.] 205 | 206 | ### Releases to CRADA Collaborators 207 | 208 | Software may be provided as part of the Government's contribution to a CRADA 209 | relationship. If there is no patent or copyright protecting the software it 210 | can be provided with "copyright like" restrictions. However, these 211 | contractual restrictions will only apply to the CRADA Collaborator. Should 212 | the software be released to others there is no way to prevent its use by third 213 | parties. If software is provided to a CRADA Collaborator, it appears that a 214 | fee could be charged to reimburse the laboratory for its use by the CRADA 215 | Collaborator. Determining the amount to charge could be a challenge and, of 216 | course, subject to negotiation. The ARL is authorized to retain money 217 | collected under a CRADA but is not authorized to share the money with civil 218 | servants involved in the software's creation. Note that any changes to the 219 | software made by the CRADA partner may be protected by copyright. 220 | 221 | Patent License in CRADA. For preexisting inventions, a CRADA partner must 222 | apply for a patent license just as any prospective licensee would be required 223 | to. The process must follow the Government's licensing regulations (see, 37 224 | CFR Part 404). For ARL software-related inventions made under a CRADA, the 225 | CRADA partner may be offered a patent license as part of the CRADA deal. The 226 | Government's licensing regulations do not apply to patent licenses on 227 | inventions made under a CRADA. 228 | 229 | Copyright License in CRADA. The CRADA statute, 15 U.S.C. 3710a. (a)(2), 230 | authorizes the Director to license "other intellectual property" (e.g., a 231 | copyright) that "may be voluntarily assigned to the Government" if "other 232 | authority" exists. Again, we are unaware of any "other authority" that would 233 | authorize the Director to license a copyright covering software under a CRADA. 234 | Software could be arguably be provided to a CRADA partner with "copyright 235 | like" contractual restrictions. 236 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | #

The U.S. Army Research Laboratory (ARL) Software Release Process for Unrestricted Public Release

2 |

Version 1.0.4

3 |

28 July 2017

4 | 5 | # Summary 6 | 7 | This document provides procedures that ARL Government personnel MUST follow 8 | when releasing software source code and software-related material to the 9 | public, and for accepting software-related contributions from the general 10 | public. The `master` branch of this repository is the only official document; 11 | all other branches are for discussion and development only, and may or may not 12 | become part of a future official policy. 13 | 14 | # Table of Contents 15 | 16 | * [Definitions](#20721692C17C11E69585003EE1B763F8) 17 | * [Goals and Rationale](#21147298C17C11E6BA7B003EE1B763F8) 18 | * [Why Releasing Software is Important](#22AFD814C17C11E6BAC9003EE1B763F8) 19 | * [Issues Related to Releasing Source Code](#25060DEEC17C11E6B53F003EE1B763F8) 20 | * [OPSEC and Security](#267B9930C17C11E6AAEE003EE1B763F8) 21 | * [Intellectual Property Issues](#29EF7A14C17C11E69F71003EE1B763F8) 22 | * [Liability and Fitness for Purpose](#2D0B7162C17C11E6BD34003EE1B763F8) 23 | * [The CC0 License and the ARL Contributor License Agreement (ARL CLA)](#2DF49A4AC17C11E69E3A003EE1B763F8) 24 | * [Release Rights](#2FA38FF4C17C11E6A781003EE1B763F8) 25 | * [Release Instructions](#32B21988C17C11E687F7003EE1B763F8) 26 | * [Major Reviews](#3449D4BEC17C11E68DD1003EE1B763F8) 27 | * [Informal Approval](#37D9C8B4C17C11E6AE38003EE1B763F8) 28 | * [Code Cleanup and Release Preparation](#3981656EC17C11E6B2AE003EE1B763F8) 29 | * [File an ARL Form 1](#4066B47EC17C11E6BFC7003EE1B763F8) 30 | * [Obtain Invention Evaluation Committee (IEC) Approval](#433214A2C17C11E6952E003EE1B763F8) 31 | * [Intellectual Property Review](#45A6CE62C17C11E6A6C0003EE1B763F8) 32 | * [Distribution Methods](#476F65D4C17C11E69E2F003EE1B763F8) 33 | * [Final Release and Principal Developer Responsibilities](#49715508C17C11E69019003EE1B763F8) 34 | * [Minor Reviews](#4ADBEADCC17C11E6B9BC003EE1B763F8) 35 | * [Incorporating External Contributions](#4D5F4B34C17C11E6ADBB003EE1B763F8) 36 | * [A Note on Impact and Metrics](#A_Note_on_Impact_and_Metrics) 37 | * [Evidence of Impact](#5092761CC17C11E6B23A003EE1B763F8) 38 | * [Software Maturity and Software Engineering](#53A23266C17C11E6BEEE003EE1B763F8) 39 | * [CC0 1.0 Universal (CC0 1.0) Public Domain Dedication](#55B06322C17C11E6920E003EE1B763F8) 40 | * [Contributor License Agreement (CLA)](#D3DC705AC3C411E6BBB4003EE1B763F8) 41 | * [Legal Analysis - Software Protection & Release Mechanisms](#D18EB61EC23E11E692E5003EE1B763F8) 42 | * [Glossary](#CDCCBA76C23E11E6AB7D003EE1B763F8) 43 | * [Footnotes](#93338EDCC17C11E6B720003EE1B763F8) 44 | 45 | # Definitions 46 | 47 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 48 | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 49 | interpreted as described in RFC 2119. See RFC 2119 "Key words for use in RFCs 50 | to Indicate Requirement Levels", Request for Comments: 2119; Internet 51 | Engineering Task Force, March 1997 (https://tools.ietf.org/html/rfc2119) for 52 | the complete definitions. 53 | 54 | # Goals and Rationale 55 | 56 | The goal of this memorandum is to both clarify how software developed by ARL 57 | personnel may be released to the public and encourage ARL personnel to do so, 58 | while remaining firmly within the legal and regulatory requirements of the 59 | United States and the Army. These goals are in some ways conflicting, which 60 | is why the process described in this document may seem bureaucratic and 61 | onerous. This chapter explains why publishing software is important and some 62 | of the legal and regulatory constraints on doing so. Reading it is OPTIONAL, 63 | but doing so may give the reader some insight into the reasons for the 64 | process. 65 | 66 | ## Why Releasing Software is Important 67 | 68 | Software has become an integral part of modern research. It is used in 69 | everything from simulation and modeling, to data gathering and analysis. In 70 | many cases, the only way to assimilate the details of research published in 71 | various technical papers is by analyzing the software used in the research. As 72 | a result, research that has its source code published has a significantly 73 | greater impact on the public than research that does not. Published source 74 | code accomplishes the following: 75 | 76 | * Allows external researchers to analyze and verify that the software is 77 | correct, which helps prove the claims in any accompanying papers are valid. 78 | * Attracts public attention. 79 | * Reduces the barrier to entry for others to join in on the research. As a 80 | result, collaborations are formed as others want to learn more and build on 81 | an organization's work. 82 | * If the software becomes dominant, then the organization that owns it becomes 83 | the de-facto leader in the field, and all others follow their lead. 84 | 85 | Conversely, when software is not published, the following are true: 86 | 87 | * Claims in papers based on the software cannot be verified, potentially 88 | leading to doubts in the claims. 89 | * Barriers to collaboration are raised significantly: 90 | * Published research may be ignored, because external researchers do not 91 | fully understand it. 92 | * New researchers must "reinvent the wheel" by writing their own software. 93 | * The ARL may lose its leadership position to others solely due to others 94 | having published their code first. 95 | 96 | The ARL leadership has recognized these facts and, to ensure that ARL remains 97 | a leader rather than a follower, has created an organizational site on GitHub, 98 | a social networking website focused on sharing code, to publish ARL software 99 | to the world as a part of Open Campus. However, ARL is not a private entity 100 | and MUST obey numerous laws and regulations when releasing any material to the 101 | public. These protocols are intended to protect sensitive material from 102 | inadvertent release, protect the Intellectual Property (IP) rights of ARL, and 103 | prevent ARL from accidentally trespassing on the rights of others. 104 | 105 | ### Issues Related to Releasing Source Code 106 | 107 | The ARL faces a number of issues when defining a software release process. 108 | Legal and regulatory issues are fully outlined in [Legal Analysis - Software 109 | Protection & Release Mechanisms](#D18EB61EC23E11E692E5003EE1B763F8), while 110 | other issues are summarized here. 111 | 112 | #### OPSEC and Security 113 | 114 | As an organization within the Department of Defense (DOD), ARL MUST be able to 115 | properly evaluate information that is proposed for publication to ensure no 116 | sensitive information is accidentally released. This includes software. Since 117 | it is possible to accidentally violate various laws with even a seemingly 118 | trivial change[1](#Footnote_1), it is critical that all changes be 119 | reviewed by a competent Operational Security (OPSEC) officer before release. 120 | This step is intended to protect ARL personnel from the repercussions of such 121 | a release by reducing the chances of it occurring in the first place. 122 | 123 | Moreover, just as aggregating unclassified information may raise its 124 | classification level, combining a set of changes into a whole may also raise 125 | its classification level. This is why any review MUST consider the software 126 | as a whole, not just the portion that changed. 127 | 128 | #### Intellectual Property Issues 129 | 130 | For most publications, once an ARL Form 1 is completed, the publication is 131 | approved for public release. However, the ARL Form 1 process was designed 132 | primarily for OPSEC and quality control purposes, and does not address IP 133 | concerns. This can cause significant legal challenges if not correctly 134 | addressed, both when ARL accidentally releases valuable IP without protecting 135 | it and when ARL accidentally trespasses on the rights of others. There are 136 | three main types of IP rights that ARL MUST be considered for software 137 | release: trademark, copyright, and patent rights. 138 | 139 | Trademarks are intended to prevent consumer confusion over who is the source 140 | of goods and services. Thus, the name given to software can become a valuable 141 | piece of IP, particularly as the user community starts to associate the 142 | software with ARL. Trademark misuse can take a number of forms. Improper or 143 | unauthorized use can imply to a consumer that a trademark owner is providing 144 | or endorsing a product when they are not. Provided no such implication is 145 | made when using trademarks owned by others, ARL should be relatively safe. 146 | More on this can be found in [Legal Analysis - Software Protection & Release 147 | Mechanisms](#D18EB61EC23E11E692E5003EE1B763F8). To help protect ARL IP, all 148 | ARL-developed software SHOULD use "ARL" in its name. 149 | 150 | Copyright is another form of IP that can give owners a method of control over 151 | their works. Works generated by non-Governmental persons or Government 152 | employees acting outside of their official duties automatically have copyright 153 | attached to them. This means that any outside contribution to a Government 154 | software project will not be owned by the Government unless the copyright is 155 | assigned to the Government. Because of this, unless a contract exists between 156 | the Government and the outside entity, the outside entity can claim at least 157 | part ownership of the project and make additional demands of the Government, 158 | which may lead to a project being shut down. 159 | 160 | Thus far, the Government has had the following options to protect itself 161 | against these problems: 162 | 163 | * Refuse to share software with entities not covered by a Cooperative Research 164 | and Development Agreement (CRADA), Cooperative Agreement (CA), or another 165 | similar vehicle. 166 | * Refuse all outside contributions. 167 | * Arrange for a contractor to author and own the work, and then assign 168 | copyright to the Government. 169 | 170 | The process in this document outlines a new option, and as such, requires 171 | careful consideration of copyright implications. 172 | 173 | Patents are another method of protecting IP rights. If software is released 174 | by ARL without adequate review, ARL's patent rights may be impacted. For 175 | instance, if contractors or other collaborators have co-invented a 176 | "software-related invention"[2](#Footnote_2), they have the right 177 | to pursue a patent first. Contractors may be legally permitted to patent the 178 | software, preventing others from using it. In this case, ARL SHOULD NOT 179 | release the software to the public under this process. If a project will 180 | eventually be released under this process, developers SHOULD consult with ARL 181 | Legal to determine the best course of action to take with regard to any 182 | contractors or outside contributors. If this is not done, then at some later 183 | date, developers may find that there are patents that effectively prevent ARL 184 | from releasing the software to the public[3](#Footnote_3). 185 | 186 | In addition, unless this process is followed, ARL will not be waiving its 187 | patent rights; instead, the right to pursue patent protection falls back to 188 | the inventors (i.e., ARL employees who have created a "software-related 189 | invention"). This can lead to legal complications that ARL would rather 190 | avoid. 191 | 192 | #### Liability and Fitness for Purpose 193 | 194 | A major difference between software and a journal paper or other presentation 195 | is that software is effectively a machine. As such, there are concerns about 196 | fitness for purpose, as well as the liability incurred, should the software 197 | not meet its stated capabilities. Releasing software without an adequate 198 | license or contract may leave both the authors of the software and ARL open to 199 | liability issues that could be avoided. 200 | 201 | ### The CC0 License and the ARL Contributor License Agreement (ARL CLA) 202 | 203 | With few exceptions, U.S. Government works do not enjoy copyright protection. 204 | Because of this, licenses that rely on copyright for their protection 205 | mechanism may be declared invalid under U.S. Law[4](#Footnote_4). 206 | For this reason, for works that do not have copyright attached, ARL relies on 207 | a combination of the Creative Commons Zero (CC0) license 208 | (https://creativecommons.org/publicdomain/zero/1.0/legalcode and reproduced at 209 | [CC0 1.0 Universal (CC0 1.0) Public Domain 210 | Dedication](#55B06322C17C11E6920E003EE1B763F8)) and the contributor license 211 | agreement shown in [Contributor License Agreement 212 | (CLA)](#D3DC705AC3C411E6BBB4003EE1B763F8). All external contributors MUST 213 | execute and return a CLA to the project owners before their contributions can 214 | be accepted to ensure that all IP issues are settled. 215 | 216 | ## Release Rights 217 | 218 | The most complicated aspect of a software release is usually determining if 219 | there are adequate rights held by the Government to perform a release to the 220 | public. If the software does not yet exist but there is public release 221 | intention, it is advantageous to establish adequate rights in advance, 222 | particularly for works developed with contractor involvement. 223 | 224 | The first question to consider is whether the software or related material 225 | should be released to the public. While there are considerable collaborative 226 | benefits that have the potential to reduce acquisition costs for the 227 | Government, there are also potential new costs to consider and risks to 228 | mitigate. For example, ARL software in active use that is converted into an 229 | open-source project can reasonably expect to receive externally developed 230 | software improvements, but there will be additional information assurance (IA) 231 | requirements to review before integrating those contributions. To release 232 | software, a supervisor MUST decide that there is an overall expected benefit 233 | to the Government to perform the release. 234 | 235 | The second question to consider is whether or not the software can be released 236 | under the ARL Form 1 process with a distribution statement of Distribution A, 237 | "Approved for public release; distribution unlimited." If this is not 238 | possible, then the software cannot be released under the process in this 239 | document. Contact ARL Legal and ARL Security with the specifics of the 240 | project to see if there are changes that can be made that will allow it to 241 | have a Distribution A, "Approved for public release; distribution unlimited" 242 | statement. The following is a non-exhaustive list illustrating why some 243 | software and related material face complications in releasing it to the public 244 | due to law, regulation, or policy. Software that falls into these categories 245 | will require further scrutiny. Consult with ARL Legal to determine if it is 246 | possible to release the software. 247 | 248 | The third question involves the rights of others. Copyright attaches to works 249 | when they are created[5](#Footnote_5); if ARL does not own the 250 | copyright to a work, it MUST obtain the rights to release the material before 251 | it may do so. If a software project does not yet exist, then there are no 252 | copyright, authorship or licensing issues preventing release. However, if 253 | what is being prepared for release already exists, a thorough review to 254 | ascertain origination, provenance, and licensing MUST be conducted to ensure 255 | that the rights of others are not trespassed. 256 | 257 | If the work was developed solely by Government employees as part of their 258 | official duties, then there are no copyright concerns and the Government has 259 | the right to release the work. If there are any contractors or other external 260 | parties involved, they may have rights that prevent the Government from 261 | releasing and/or redistributing their contributions without their permission. 262 | If there are any third-party libraries, applications, or data that are 263 | incorporated into the work, there MUST be appropriate license and/or rights to 264 | distribute them. 265 | 266 | When works are developed by a mixture of Government employees and Government 267 | contractors, determining who has the right to release the software to the 268 | public as open source depends on what contract clauses are in effect. Consult 269 | with ARL Legal to determine what clauses are in effect and what options there 270 | are to release the software. 271 | 272 | # Release Instructions 273 | 274 | These instructions MUST be followed when ARL personnel release software to, or 275 | accept contributions from, the general public. If a project does not yet have 276 | any software associated with it (such as when a project is being initially 277 | formulated) and the project is intended to be released to the general public, 278 | then this process MUST still be followed. 279 | 280 | ## Major Reviews 281 | 282 | The major review process MUST be followed if any of the following are true: 283 | 284 | * This is the first release of the project. 285 | * The project's scope has changed sufficiently that any of the principal 286 | developers (PDs), their OPSEC officers, or anyone in their chains of command 287 | believe a new one ought to be filed. 288 | * It has been more than 1 year since the last time a major review has been 289 | done and the project is still active (material is being published to the 290 | public). 291 | * The PDs feel they have accomplished something of note and wish to get credit 292 | for it in their performance metrics. 293 | 294 | ### Informal Approval 295 | 296 | Before developer(s) release software, they MUST obtain informal approval from 297 | their supervisor(s). If their supervisors do not approve release of the 298 | software, then the software MUST NOT be released. Do not continue with this 299 | process. When deciding if a project can be released, review the requirements 300 | of RELEASE RIGHTS. The requirements in that chapter MUST be met before any 301 | software or related materials are released. 302 | 303 | ### Code Cleanup and Release Preparation 304 | 305 | Fast-moving projects often accumulate useless, nonfunctional, or otherwise 306 | undesirable code and other material that needs to be cleaned up. Before 307 | moving forward with the formal portions of the process, the project MUST be 308 | cleaned up to ensure it meets certain minimum standards. Remember that a 309 | formal review can only be done on what is actually being released, so cleaning 310 | up the code after the formal review is not an option. If a project is being 311 | formulated, but does not yet have any code associated with it, this section 312 | SHOULD be used as a guide for how to write the software. 313 | 314 | This section applies to everything that is being released, including any older 315 | commits in any repositories. By design, repositories preserve history, which 316 | can include material that should not be published. It is the responsibility 317 | of the project's developers to ensure that both the current code and any 318 | history in any repositories that are proposed for release have been properly 319 | scrubbed before the material is reviewed for release. 320 | 321 | Software that is released to the public is similar to a publication and SHOULD 322 | be treated like one. The author(s) MUST ensure that there is no embarrassing, 323 | disparaging, or otherwise unprofessional language in what is released. 324 | Language that would not be used in a professional journal MUST not be used in 325 | software. Direct any questions about this to the ARL Public Affairs Office 326 | (PAO). 327 | 328 | Where possible, it is wise to follow best practices in software engineering. 329 | Because of the wide variety of programming languages in use, project goals, 330 | etc., ARL wants to avoid forcing a single process on any developers or group. 331 | For this reason, ARL has chosen a minimal set of requirements and provides 332 | some best practice suggestions. Individual implementation of the voluntary 333 | portions is recommended as they may have an effect on impact and metrics. See 334 | [A Note on Impact and Metrics](#A_Note_on_Impact_and_Metrics) for details on 335 | metrics. 336 | 337 | Unless a project is required to follow other guidelines, the guidelines 338 | described in the latest Semantic Versioning guidelines (http://semver.org/) 339 | SHOULD be followed when setting the version number for any release. A file 340 | MAY be created in the top-level directory called "VERSION." If the "VERSION" 341 | file is created, then it MUST be a plain-text file in either ASCII or UTF-8 342 | encodings. The file MUST contain the version number of the release and MUST 343 | NOT contain anything else. By following this guideline, automated systems are 344 | more likely to be able to determine if the project has been updated and how 345 | significant those updates are simply by parsing the "VERSION" file. 346 | 347 | The license to be used depends on whether or not the project has copyright 348 | attached to it. Works generated solely by Government employees in the course 349 | of their duties do not have any copyright attached to them. Works produced 350 | with non-Government persons or organizations may have copyright attached. If 351 | there is uncertainty about the copyright status of a project, ARL Legal SHOULD 352 | be consulted to determine the legal state of the project and determine which 353 | license to use. 354 | 355 | If the project does not have copyright, the Creative Commons Zero 1.0 356 | Universal (CC0 1.0) Public Domain Dedication MUST be used. Follow the 357 | instructions in that section for how to use it. 358 | 359 | If the project has copyright, any license that ARL Legal approves of MAY be 360 | used. It is RECOMMENDED that the Apache 2.0 license 361 | (http://www.apache.org/licenses/LICENSE-2.0) be used. 362 | 363 | Unless the guidelines the project is following require otherwise, the long 364 | form of any license used SHOULD be in a file called LICENSE in the top-level 365 | of the project directory. For any LICENSE file, the file MUST be a plain-text 366 | file in either ASCII or UTF-8 encoding. The README file (described below) 367 | MUST state the name of the file that contains the complete 368 | license[6](#Footnote_6). If the project has a webpage, the license 369 | being used MUST be stated somewhere on the webpage, with a link pointing to 370 | where the file containing the license can be found. 371 | 372 | All contributions to the project MUST be done under the license and the 373 | contributions MUST be irrevocable. Questions about this can be directed to 374 | ARL Legal for clarification. 375 | 376 | A "README" file MUST be created at the top level of the directory with at 377 | least the following in it: 378 | 379 | * The intended purpose of the software. 380 | * A note pointing to the license or contract covering the software. 381 | * If there is no "VERSION" file, the version number of the release SHOULD be 382 | included. 383 | * At least some basic documentation on how to build and use the software. 384 | 385 | The "README" file MUST be a plain-text file in either ASCII or UTF-8 encoding. 386 | 387 | While only the "README" file is mandatory, other documentation is highly 388 | desirable. This can include comments in the source code, high-level design 389 | documentation, etc. There are many methods and tools to support this type of 390 | documentation. Where reasonable, please document both high- and low-level 391 | design details, as well as how the software should be used. 392 | 393 | Example code is also a form of documentation. If the project is a library, it 394 | can be useful to provide small, complete, and well-documented programs that 395 | illustrate how to use the software. If possible, refer to publications and 396 | projects that used or referred to this code; they can become additional 397 | examples of how to use the code, as well as testimonials for why the code 398 | should be used. 399 | 400 | Unit tests are strongly RECOMMENDED. They can not only increase confidence 401 | that the code was written correctly, but they can also convince a user that 402 | the code is behaving as expected on the system on which it is installed. This 403 | will increase the likelihood that others will be willing to use the code, 404 | making it wise to include unit tests in the project. In addition, unit tests 405 | can serve as examples of how to use the code; this can be invaluable when a 406 | user is trying to understand the documentation. 407 | 408 | For legal reasons, all language talking about the project MUST be prefixed 409 | with "ARL". For example, if a project is named WhizBang, then all literature 410 | in the package SHOULD refer to it as "ARL WhizBang" or the "ARL WhizBang 411 | project." "ARL" is a federally registered trademark and using it in this 412 | manner adds some degree of trademark protection to a project. 413 | 414 | ### File an ARL Form 1 415 | 416 | An ARL Form 1 MUST be filed. In the process described in this document, the 417 | primary purpose of the ARL Form 1 is for OPSEC review, but it also serves the 418 | secondary purposes of describing releases for publicity and metrics. To 419 | support this, a short abstract describing the software MUST be written. The 420 | abstract SHOULD be at most one page in length and provide the following 421 | information: 422 | 423 | * The name of the project. 424 | * A description of the project. This includes what it does and what its 425 | intended purpose is. This SHOULD be as complete as is reasonably possible. 426 | Portions of the "README" file MAY be copied here. 427 | 428 | This information will be used both for publicity purposes, and by a supervisor 429 | and others to decide if it is time for a project to be subjected to another 430 | major review. 431 | 432 | If this is not the first major review of the software, then the abstract MUST 433 | also include the following information: 434 | 435 | * The change or changes that caused this review to become necessary. 436 | * What the impact of the software has been since the last major review for 437 | this project. See 438 | [A Note on Impact and Metrics](#A_Note_on_Impact_and_Metrics) for examples 439 | of how impact is measured and for what to include. 440 | 441 | Note that while ARL wants to credit an author for the impact the software has 442 | made, it will not "double count" what authors have done by including the 443 | impact from earlier major reviews. Only the impact made since the last time 444 | the major review process was completed SHOULD be included. 445 | 446 | This abstract, along with everything planned on being released (software, 447 | source code, documentation, etc.), MUST be fully reviewed by a level 1 OPSEC 448 | officer. If this is not an initial review, the OPSEC officer MAY choose to 449 | only review what has changed since the last review, but both the author and 450 | the OPSEC officer are responsible for the release as a whole. Thus, even if 451 | the changes are cleared for public release, if the release as a whole cannot 452 | be cleared for release, then the changes are not cleared for release either. 453 | To be cleared for release, the project as a whole MUST receive an "Approved 454 | for public release; distribution unlimited" statement. Finally, no one is 455 | permitted to OPSEC-approve material that he or she created. Review RELEASE 456 | RIGHTS for what needs to be considered. 457 | 458 | ### Obtain Invention Evaluation Committee (IEC) Approval 459 | 460 | The ARL may have IP interests in the software. Before it can be released, the 461 | IEC MUST determine that it is in the best interest of the Government and ARL 462 | to waive any IP rights that ARL might have and release it to the public. To 463 | do so, the PD MUST inform the current chair of the IEC (or the chair's 464 | delegate) of the intention to release the software by sending the chair a 465 | digitally signed email that contains the following: 466 | 467 | * The abstract that was submitted as a part of the ARL Form 1 process above. 468 | The related software is not sent to the IEC chair (or the chair's delegate) 469 | unless he or she requests it. 470 | * A list of all software-related inventions that the PD and his or her 471 | supervisor believe are contained in the work[7](#Footnote_7). 472 | * A statement that, in the opinion of the PD and his or her supervisor, all 473 | IP, including the listed inventions, should be irrevocably placed in the 474 | public domain. 475 | 476 | If the chair (or the chair's delegate) agrees that ARL should waive any patent 477 | or other IP interests ARL may have and that the software should be put into 478 | the public domain, then the chair (or the chair's delegate) will reply back 479 | with a digitally signed email with a statement similar to the following: 480 | 481 | `<> is to be dedicated to the public domain for promoting its 482 | commercial and non-commercial use. It is not intended to become the subject 483 | of any patent application or license. All intellectual property rights ARL 484 | may be able to assert or establish are hereby waived.` 485 | 486 | If the PD has received approval from IEC chair (or the chair's delegate), then 487 | the PD MAY continue with the rest of this process. 488 | 489 | If the IEC chair (or the chair's delegate) believes that ARL has IP interests 490 | that ARL wants protected, then the PD and the chair (or the chair's delegate) 491 | MUST discuss the issues to determine how to move forward. This discussion MAY 492 | be performed by email, telephone, or any other convenient and legal means. 493 | Records of the final determination MUST be kept by the PD. If it is 494 | determined to be in the best interests of ARL and the Government to seek 495 | patent protection, then the rest of this process does not apply. Do not 496 | continue with the rest of this process. 497 | 498 | To determine the appropriate person to contact within the IEC, consult ARL 499 | Legal. 500 | 501 | This step MAY be done in parallel with the steps described below. 502 | 503 | ### Intellectual Property Review 504 | 505 | Although ARL MAY choose to waive ARL's rights to any IP established in 506 | software, if an author has incorporated contributions from others, those 507 | contributors may have rights to those contributions that restrict ARL's 508 | ability to release the software. Thus, before the software can be released, 509 | the following questions MUST be addressed: 510 | 511 | * Has every part of the proposed release been generated by Government 512 | employees in the course of their duties? 513 | * If not, is there permission from every other rights holder to release all of 514 | the other parts under the project's license? 515 | 516 | The PD MUST consult with ARL Legal to perform an IP review (this review MAY be 517 | done by email or any other convenient and legal means). If there are external 518 | contributions that were not contributed under the project's license, then the 519 | PD MUST determine the license and copyright information for each contribution. 520 | Provide these to ARL Legal for review and final determination if the licenses 521 | are compatible with the license or contract under which the software is being 522 | released. If ARL Legal determines that there are impediments to releasing the 523 | software, whatever permissions are necessary MUST be obtained before the 524 | software is released. If it is not possible to obtain the necessary 525 | permissions, then the software MUST NOT be released. Do not continue with the 526 | rest of this process. If ARL Legal agrees that there are no IP impediments to 527 | releasing the software, then ARL Legal MUST send a digitally signed email to 528 | the PD stating so. 529 | 530 | Note that copyright protection attaches to all literary works, including 531 | software, when they are created[8](#Footnote_8). This includes 532 | software copied off of blogs, sites like http://stackoverflow.com/, and any 533 | other sources. If such code or documentation has been copied into a project 534 | without permission and permission from the rights holder cannot be obtained, 535 | it may not be possible to release the software. 536 | 537 | ### Distribution Methods 538 | 539 | There are many different ways of distributing software. The ARL GitHub site 540 | is the RECOMMENDED method, but is not the only method. The PDs MAY choose to 541 | distribute by FTP, email, another website, or other means, in addition to or 542 | in place of GitHub. For any and all distribution methods chosen, the PDs are 543 | responsible for creating their own accounts. If the distribution method uses 544 | email addresses as part of the sign up process, then the PDs MUST use their 545 | Government email addresses. All login accounts MUST be reported to the PDs' 546 | supervisors. Passwords MUST be kept secret. If a site uses cryptographic 547 | authentication such as public/private key pairs, PDs MAY choose to use this 548 | facility in addition to, or instead of, passwords. Private keys MUST be 549 | treated like passwords and kept secret. 550 | 551 | Where possible, it is strongly RECOMMENDED that projects be distributed via 552 | the ARL GitHub site. This will make it significantly easier to gauge the 553 | impact of the project by the Technology Transfer and Outreach Office (T2O2) 554 | and by a supervisor, which will impact performance metrics. 555 | 556 | ### Final Release and Principal Developer Responsibilities 557 | 558 | If the software is approved for final release and there is not yet a project 559 | for it on GitHub, then the T2O2 will generate a project on the ARL GitHub 560 | site. If there is already a project on the ARL GitHub site for the software, 561 | then the T2O2 will note the release for metrics purposes, but will take no 562 | other action. If an author chooses not to use the ARL GitHub site, he or she 563 | MAY request that the T2O2 not create a project. However, as mentioned in 564 | Distribution Methods, it is strongly RECOMMENDED that GitHub be used to 565 | distribute software. 566 | 567 | The PDs SHOULD put their software on their project's site. The T2O2 will 568 | publicize this site on behalf of the PDs. The software MAY also be distributed 569 | by any and all other methods the PDs see fit. The PD (or PDs) MAY promote 570 | their projects on their own, but SHOULD do so in consultation with the T2O2, 571 | to both ensure that all promotions are professional in nature and minimize any 572 | duplication of effort. 573 | 574 | If the PDs choose to use GitHub as a distribution method for their software, 575 | then the PDs are responsible for generating a digital object identifier (DOI) 576 | for the release. The instructions to do so are at 577 | https://guides.github.com/activities/citable-code/. 578 | 579 | ## Minor Reviews 580 | 581 | Minor releases include all releases that the PD, the PD's OPSEC officer, and 582 | the PD's supervisor do not believe require a major review. These include bug 583 | fixes and minor updates. A minor release only requires review by a level-1 584 | OPSEC officer before being published. These reviews are called "minor 585 | reviews" and are subject to the following: 586 | 587 | * The OPSEC officer MAY also be the technical reviewer for the release. 588 | * Only if the project as a whole, including the minor changes being proposed 589 | for release, receives an "Approved for public release; distribution 590 | unlimited" statement can the changes be released. 591 | 592 | The process for a minor release is as follows: 593 | 594 | * The person who created the material sends it to the OPSEC reviewer. 595 | * The OPSEC reviewer reviews the material and sends a digitally signed email 596 | back to the creator either stating that it may not be released or that it 597 | may be released. 598 | * If the material may be released, then the creator pushes the material out to 599 | the public. 600 | 601 | Note that there are numerous methods of sending the material. If the material 602 | is stored under git, and both the creator and the OPSEC officer have access to 603 | the same private repository[9](#Footnote_9), then the creator MAY 604 | choose to push to the private repository and ask the OPSEC officer to pull it 605 | and review the changes. Alternatively, git bundles MAY be used, or one could 606 | even email text files. Regardless of the method chosen, there are two 607 | requirements that MUST be met: 608 | 609 | * The chosen method MUST uniquely identify the set of changes under 610 | discussion. Examples include the complete git commit hash under discussion, 611 | emails with the complete change set, or any cryptographically signed 612 | method. This ensures non-repudiation or confusion. 613 | * The OPSEC reviewer MUST track what he or she has approved. This MAY be done 614 | by saving the digitally signed emails that were sent. 615 | 616 | These steps are REQUIRED for audit purposes. Without them, ARL cannot prove 617 | to the Department of the Army that it is properly reviewing material before it 618 | is released. 619 | 620 | If a release appears to be a major release in the opinions of any of the PDs, 621 | the OPSEC officer, or any of their superiors, then a new ARL Form 1 MUST be 622 | filed and the full release process described above re-executed. A major 623 | release is any release that significantly changes the scope of the project or 624 | may violate any of the checks described in this document. 625 | 626 | ## Incorporating External Contributions 627 | 628 | Once the software has passed the process outlined above and has been publicly 629 | distributed, any contributions to the project MUST be subject to its license. 630 | 631 | External contributions do not need to undergo OPSEC review as they are assumed 632 | to be public at the time of contribution. They SHOULD be reviewed for quality 633 | purposes before being accepted into a project to ensure that they are 634 | professional in nature and perform as expected. All external contributors 635 | MUST have a CLA on file before their contributions are accepted into the 636 | project. A CLA only needs to be executed once by each legal entity. Project 637 | owners MUST turn over executed CLAs to the T2O2 for record keeping. Project 638 | owners MUST explain in the README file that external contributors MUST execute 639 | a CLA before their contributions will be accepted. 640 | 641 | ## A Note on Impact and Metrics 642 | 643 | Publishing software as a regular business practice is new territory for ARL, 644 | and how to measure a project's impact on the general public is still a matter 645 | for debate. While GitHub gathers numerous statistics on projects, from the 646 | number of downloads, to the number of followers, etc., these are, at best, 647 | suggestions of what a project's true impact is. For the sake of metrics, a 648 | project's PDs MUST create a short report (at most one page) describing what 649 | they think the impact is and providing evidence to back up this claim. The 650 | greater impact a project has had, the better it is for metrics and performance 651 | evaluation. 652 | 653 | To be absolutely clear, impact is based on major reviews (releases that follow 654 | the procedure outlined in Major Reviews). Minor reviews, as described in Minor 655 | Reviews, might lead toward a major review, but will not count toward metrics. 656 | If an author wants releases to count toward metrics, the procedures outlined 657 | in Major Reviews MUST be followed. 658 | 659 | ### Evidence of Impact 660 | 661 | It is up to the PD to decide what types of evidence to use when describing the 662 | impact of a project. As noted in File an ARL Form 1, ARL will not "double 663 | count" the impact; ARL is primarily interested in the impact since the last 664 | major review. That said, some forms of evidence are difficult to express as a 665 | difference from a prior major review. In that case, a PD MAY wish to express 666 | both the current absolute numbers and the changes since the project was last 667 | filed. 668 | 669 | Below are some examples of evidence PDs MAY wish to consider giving: 670 | 671 | * The number of citations of different releases. It is possible to cite 672 | releases on GitHub just as papers might be cited. See 673 | https://guides.github.com/activities/citable-code/ for more information on 674 | how to do this. 675 | * If a project is a library or something else that is intended to be 676 | incorporated into other projects, list those projects and describe their 677 | importance. 678 | * The number of followers, including the level of interest as measured by 679 | issues opened and persons contacting the PDs 680 | * The number of forks 681 | * The number of contributions from outside (non-ARL) sources 682 | * Letters of acknowledgment, thanks, or other forms of recognition 683 | * Software maturity 684 | 685 | The PDs should not feel that they are limited to these pieces of evidence, nor 686 | should they feel the need to include all of these examples. As stated 687 | earlier, ARL is still learning which metrics to use when determining the 688 | impact of a project. The PDs should feel free to use any metric they wish, but 689 | should note that supervisors and others will make the final decision on how 690 | heavily to weight the chosen metrics. For example, the number of citations 691 | for a software project is more important than the number of downloads it has. 692 | If a project is a library, then the number and importance of projects using 693 | the library will have greater weight than the number of people that have 694 | forked the project[10](#Footnote_10). 695 | 696 | In general, supervisors will want to know how a project has made a difference 697 | in the world and how important that difference has been since its last major 698 | review. The better evidence provided, the easier this becomes. 699 | 700 | ### Software Maturity and Software Engineering 701 | 702 | The ARL would like to be a world leader in computer science research. To be a 703 | world leader means that ARL must have an impact and to have an impact means 704 | that ARL's software must be used. Poorly written software that is 705 | incomprehensible or difficult to compile or use will not be used, and will 706 | have little, if any, impact. Thus, if the primary improvement to a project 707 | involves bringing it in line with generally accepted best practices in 708 | software engineering to facilitate its transition to others, then this is also 709 | of value and SHOULD be credited. Examples of this include, but are not 710 | limited to, the following: 711 | 712 | * Providing a well-designed, thoroughly documented application programming 713 | interface (API) or other interface. 714 | * Adding tests (unit tests, regression tests, integration tests, etc.) that 715 | increase confidence that your software is performing correctly. 716 | * Increasing code coverage of tests. 717 | * Adding examples and high-level documentation. This includes ensuring that 718 | all examples and documentation are up to date with the current software. 719 | * Simplifying building and installation of software. 720 | 721 | These are just some examples of mature software. If there is other evidence 722 | of the maturity or quality of software, a PD should feel free to use it when 723 | describing the impact of the software. Supervisors MUST consider improvements 724 | in software engineering when considering the impact of software. 725 | 726 | # CC0 1.0 Universal (CC0 1.0) Public Domain Dedication 727 | 728 | The text of the CC0 license can be found 729 | [here](https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt). 730 | A local copy of the license is in the file [LICENSE.txt](LICENSE.txt). 731 | 732 | # Contributor License Agreement (CLA) 733 | 734 | The ARL Contributor License Agreement (ARL Form 266) can be found 735 | [here](ARL%20Form%20-%20266.pdf)[11](#Footnote_11). Each external 736 | contributor must execute and return a copy for each project that he or she 737 | intends to contribute to. Once ARL receives the executed form, it will remain 738 | in force permanently. Thus, external contributors need only execute the form 739 | once for each project that they plan on contributing to. 740 | 741 | # Legal Analysis - Software Protection & Release Mechanisms 742 | 743 | An in-depth analysis of the issues surrounding the release of software can be 744 | found [here](LEGAL_ANALYSIS.md). 745 | 746 | # Glossary 747 | 748 | A glossary of terms can be found [here](GLOSSARY.md). 749 | 750 | # Footnotes 751 | 752 | 1 As an example, U.S. law restricts the 753 | strength of any encryption software that is being released to the world in 754 | general by restricting the length of the keys being used. Since this could be 755 | a hard-coded number in a piece of source code, a change in a single line may 756 | convert it from legal to illegal. 757 | 758 | 2 Software may be copyrighted but not 759 | patented. "Software-related inventions" may be patented. At the time of this 760 | writing, there was no clear definition of the difference between "software" 761 | and "software-related invention". Consult ARL Legal for a more complete 762 | explanation. 763 | 764 | 3 Contracts usually protect the Federal 765 | Government from the related patent issues. That said, if you have concerns, 766 | consult ARL Legal and your contracting officer to determine what rights there 767 | are. 768 | 769 | 4 At the time of this writing, this has 770 | not been litigated in Federal Court. Consult the ARL Chief Counsel's Office 771 | to determine what the current laws are. 772 | 773 | 5 Except for works created by U.S. Federal 774 | Government employees in the course of their duties. These are automatically 775 | in the public domain. 776 | 777 | 6 Some licenses have guidelines that 778 | differ from the ones described here. For example, the GPL states that the 779 | filename must be COPYING. This is why your README MUST specify which file 780 | contains the license. 781 | 782 | 7 If you have questions about what are 783 | "software-related inventions", consult with ARL Legal. 784 | 785 | 8 Excluding works generated by Government 786 | employees in the course of their duties. 787 | 788 | 9 A private repository is only accessible 789 | from within ARL; it MUST NOT be publically accessible! 790 | 791 | 10 As an example, if a library is only 792 | used within the Linux kernel, it will have been used by very few projects, but 793 | will have an extraordinary impact. 794 | 795 | 11 This form may not preview correctly in 796 | your browser. If you have trouble opening the file, or if the file has a 797 | phrase similar to "Please wait... If this message is not eventually replaced 798 | by...", then try downloading the form and opening it in the latest version of 799 | Adobe® Acrobat Reader. ARL is aware of the issue, and is working to correct 800 | the problem. 801 | --------------------------------------------------------------------------------