Peer review of source-code policy

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

General observations

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

Specific critique

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Line 167 - define unlimited data rights

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Line 412 - Please give examples to clarify.

Line 431 Please define source code.

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

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

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

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

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

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

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

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

love the idea of an opengov license. this is really well thought out, thanks for the input. love the idea of look @ oss 1st before cots. would add onto the clarification of open source code and outcomes: everything that comes out of contracts not relying on 3rd party proprietary solutions, is open. open access. open data. open source. open science. open education. open educational resources. i realize the definition of open needs to be fine tuned, but that is a brief generalization. if its gov built, its people owned.

This is Canada's Open Gov License http://open.canada.ca/en/open-government-licence-canada Although leaning on things like the Creative Commons & MIT is great too as they are so much better understood by developers.

I would hope that any software licensing recommendations relies on existing, well-known, and widely-adopted open licenses. Developing custom government licenses takes a huge effort, and it can be incredibly difficult to ensure compatibility/interoperability with existing open licenses. I work for Creative Commons, and this has been an ongoing challenge over the years. Regarding open software licenses, there are existing recommendations from the Free Software Foundation and Open Source Initiative. The CC licenses are not recommended, although the CC0 Public Domain Dedication could be used to put the code directly into the public domain.

@jalbertbowden Thank you for the compliment.

I still think that the creation of an open government licence is warranted. I think there are certain protections that would need to be in place for the usage of the particular source code we are referring to. Some of the stated goals of this policy are to reduce costs to the federal government and to increase transparency. Please consider this situation, that currently affects government spending.

The federal government will develop code to be used for some system. That code is then requested under the freedom of information act by a some contracting company. That code is then modified or built upon (hopefully) and sold back to the federal government or (other entity) as a proprietary product. This is not to say that this is undesirable, however with out transparency into what work was already done by federal government and what was done by the contractor, it becomes a burden for the federal government to negotiate a fair contract for these products. The usage of the meta data in the software inventory described in this policy will be a crucial tool for any federal employees making these purchasing decisions. I hope that special care is taken when designing the search interface, with consideration for federal employees attempting to find source code that meets the needs of their agency before having to purchase a solution. An open government licence might also help protect the federal government from inflated costs related to the situation I described above.

The licence should consider the current restrictions our federal government has on the export of cryptographic software and possibly other areas of interest.

@tvol I think your points are excellent. The open government licence should strongly consider the wording of existing open licences and ensure their compatibility/interoperability to the furthest extent.

@mgifford thank you for the link. It's great to be aware of how other governments are handling this.

NASA created their own open license, and it has been more problematic that beneficial. Any of the OSI approved licenses are more than sufficient.

On Saturday, March 12, 2016, Michael Bevilacqua notifications@github.com wrote:

@jalbertbowden https://github.com/jalbertbowden Thank you for the compliment.

I still think that the creation of an open government licence is warranted. I think there are certain protections that would need to be in place for the usage of the particular source code we are referring to. Some of the stated goals of this policy are to reduce costs to the federal government and to increase transparency. Please consider this situation, that currently affects government spending.

The federal government will develop code to be used for some system. That code is then requested under the freedom of information act by a some contracting company. That code is then modified or built upon (hopefully) and sold back to the federal government or (other entity) as a proprietary product. This is not to say that this is undesirable, however with out transparency into what work was already done by federal government and what was done by the contractor, it becomes a burden for the federal government to negotiate a fair contract for these products. The usage of the meta data in the software inventory described in this policy will be a crucial tool for any federal employees making these purchasing decisions. I hope that special care is taken when designing the search interface, with consideration for federal employees attempting to find source code that meets the needs of their agency before having to purchase a solution. An open government licence might also help pr otect the federal government from inflated costs related to the situation I described above.

The licence should consider the current restrictions our federal government has on the export of cryptographic software and possibly other areas of interest.

@tvol https://github.com/tvol I think your points are excellent. The open government licence should strongly consider the wording of existing open licences and ensure their compatibility/interoperability to the furthest extent. This draft of the policy makes mention to the Open Source Initiative cooperation (open source.org) Maybe this is an opportunity to request that their organization or (some other group) create a submit a report, to submit to this forum, showing the commonalities between the major open source licences that exist today. The opensource.org site currently lists 78 open source licences.

@mgifford https://github.com/mgifford thank you for the link. It's great to be aware of how other governments are handling this.

— Reply to this email directly or view it on GitHub https://github.com/WhiteHouse/source-code-policy/issues/26#issuecomment-195756704 .

Kane Sent from my mobile device

Opengov licensing should not have restrictions such as disallowing third party code - for example, if someone wants to publish an R package that relies on other developers' open source code and libraries as dependencies, they should be able to do so. The NASA license, as I understand it, does not allow this.

@tvol :+1: to using existing and widely used free software license, preferably one that puts code paid for by the government into the public domain. If a new government license is to be created to avoid a political battle of licenses or situations as @mikeBeviBevi describes then it should receive input from and be compatible with as many existing and popular public domain licenses as possible.

Side note - annoying that these files are in markdown on GitHub. Makes resolving and linking to line numbers in the web interface quite a pain.

DO NOT CREATE A NEW SPECIAL GOV OSS COPYRIGHT LICENSE !!! it wont be compatible with other license

@johnmod3 What licence are you referring to? .

There are many articles which compare the current open source licences and explain the sort of business models that they are supporting. The battle between "free software" and "open source" is an example. Many of the licences are in conflict with each other to a certain extent. I would think that even before compatibility, we need to consider a licence that protects the American government and the American public interests. There is probably a deep divide between methodologies to accomplish this, just as there is with other business decisions. I think the best solution will probably be balanced between government, business and citizen's interests. I suppose the aim might be to generate wealth (both monetarily and intellectually) for all parties.

Some items I think the licence should address (in no particular order):

Supports the economic policies of the federal government.
Allows the widest access of source code, created with tax payer funds, to the public
Protect the federal government against charges related to usage of federal open source code by other parties
Does not protect federal government from charges related to usage of their own open source code from their own repositories or otherwise.
Protects the security interests of the federal government
Prevent against sole source software monopolies

It is probably important to have wide compatibility, but not at the expense of these things I mentioned. Whether we choose to go with an existing licences or create a new one, there is a good chance that we will not achieve 100% compatibility. I'm not convinced that is a bad thing.

@kmclean Its funny that you mention the NASA licence because that is OSI approved! I can see the issue one might have with requiring any changes to the released source code be your own, which seems to prevent changes that include third party source. I do not know what NASA's intent was, but this may be offering them some necessary protection.

I honestly don't know what the best approach is, from the federal government stand point, with out knowing more about the strategic goals that this policy is supposed to support.

@mikeBeviBevi First off: per gov law and regulation the government is suppose to adopt industry/commercial best practice when it comes to IT. Commercail best practice is to reuse existing approved F/OSS-type licenses. Some are more optimal than others, some have taken over the market for licenses (Apache kinds rules i think). Each tenant (Some items...) you list is covered under existing OSS licenses

@johnmod3 commercial best practices do not supersede national security or other regulations. I am not trying to suggest that their is not an existing F/OSS license that could be adopted per this policy. I am disagreeing that ANY F/OSS licence will do. The Apache licence may be fine, but how does the federal government feel about the Grant of Patent License. section? Also do we want to allow other parties to make a profit off of federal open source code without seeking permission from the federal government? Perhaps we do, I think these are some of the things we need to clarify before making a choice of licence.

Valid issue you bring up: Also do we want to allow other parties to make a profit off of federal open source code without seeking permission from the federal government?

this happens now with SaaS vendors making money off OSS code My hope is that the gov releases code and it gets improved upon without gov funding. These are taxpayer funds we are talking about. not gov money. I'd like to see the code on the outside. Creating a new 'gov-only' special license has already been done (see the NASA one) and its not used by commercial industry, as it has certain non-helpful section, i.e., give back to original developer, etc.

Federal employees need to evaluate proposed solutions from several parties including contractors, internal personnel, and COTS / FOSS products to help determine what is going to be the best use of tax payers funds.

I think they would feel much more comfortable making these decisions with the knowledge of how much of the code, referred to in this policy, is being used in a particular solution. I imagine that there are times where a lack of visibility has hindered their ability to make a properly informed decision.

It's understandable that a company would want to make as much money as they can off of their service/product. It is the responsibility government personnel to ensure that they are getting a fair deal. My hope is that what ever licence is used, it will help increase visibility on both sides. Allowing the federal government to make better informed decisions and allow the taxpayers access to the work they are paying for.

We definitely don't want to stifle the community with a license that prevents the commercial industry from making money but we also want prevent the general tax payer funds.

If commercial entities build off of open source code, and profit from it, I have no issue with that - in a way they then become dependent on the original code and there's an incentive to contributing to the repo to strengthen it. If it could be done similar to how open source Apache projects are being supported and built by communities of commercial entities, fantastic.

DO NOT CREATE A NEW SPECIAL GOV OSS COPYRIGHT LICENSE

I agree with @johnmod3 and am strongly :-1: to the suggestion that government need create its own license. Open source software should be optimized for code consumers and contributors, not for the significantly more legally sophisticated (and self-complex) code publishers.

Standardized open source licenses go a long way to allow individual developers to contribute to large open source projects, without the need to hire an IP lawyer to enterpret custom terms. If a developer sees a project that is under the MIT, Apache, or GPL license (to name a few common example), they know what their rights are, and what rights they are foregoing, or a the very least, have a wide variety of existing resources to answer those threshold questions (which can be a bar for use on or contribution).

A license created by the government, which has far less experience with open source licensing than the open source community, would most likely produce a license optimized for the government and the legal challenges government agencies face (not those faced by potential contributors). The bespoke and presumably verbose legalese (because it is a government legal document), would serve as a high barrier to entry for potential contributors. Additionally such a US-specific license would most likely create countless unanticipated edge cases, when non-US developers seek to use, contribute, or redistribute the work outside the US legal framework.

Again, we should be optimizing for code use and contribution, not for sophisticated publishers which have the resources to address complex legal issues without pushing that complexity downstream.

@benbalter good analysis. I'm not sure that the argument that the government has less experience with open source is totally valid. The government has allot of experience with dealing with open source, they presently incorporate open source solutions into many systems while navigating heir own complex contracts. I would argue that the government has much more experience and resources to deal with any requirements and or legalities that arise. The government is no stranger to managing huge complex safety critical, and secure systems. In general the open source community does not deal with the level of scrutiny or legal contracts that dictate development on government systems. I do agree that what ever license chosen should be very accessible to developers, and work well with existing open source licenses. However the government has to protect itself and the public as well. I think this is a complex issue that might not be satisfactorily covered by current open source licenses. The current open source licenses already "create edge cases".

The government is no stranger to managing huge complex safety critical, and secure systems.

I agree. And if you can further stipulate that most open source developers are strangers to the legal complexity of those systems, then the license should be optimized for the developer's use, not the government's as the government will be able to navigate the complexity of the process, whether that complexity is in the license, or around it, whereas the developer will not.

I think this is a complex issue that might not be satisfactorily covered by current open source licenses.

Can you provide some examples of those edge cases? How are they not already covered by federal law (e.g., logo use, impersonation, implying endorsement)? How is the complexity of this large, bureaucratic and highly regulated organization sufficiently different than other highly regulated bureaucratic organizations (e.g. financial services, healthcare) that are able to participate within the open source community under existing licenses? Is that difference so sufficient as to justify creating a new license that would shift all that complexity on to developers?

Regulations that apply to privately/publicly owned companies do not apply to government entities and vice versa. For instance, the government cannot sue for copyright violations. I'm not sure that the government would have the necessary rights to enforce the protections that the certain OS licences offer. Although, I am not a legal expert so I could definitely be wrong. You may be correct that other federal laws might already have these things covered. I also wonder if there are any special considerations for systems that interface with other foreign governments or the involvement of persons from foreign countries. There are certain considerations when federal agencies are doing business with other foreign countries. I'm not sure that they can be a prime contractor on work for U.S. agencies in some cases. So how do we handle a similar situation when there is work done on open source projects that would be used by the federal government?

Regulations that apply to privately/publicly owned companies do not apply to government entities and vice versa.

True. My point is that existing open source licenses thrive in highly regulated industries, even if the particular requirements differ.

So how do we handle a similar situation when there is work done on open source projects that would be used by the federal government?

Easy. The open source license requires that contributions be licensed to the world under the terms of the project license. If an English citizen, a French contractor, or the German government itself wrote a piece of software and released it to the world under an open source license (or contributed to an existing open source project), the US Federal Government could use that software, just as it could use WordPress, Drupal, and MediaWiki (which themselves, have non-US contributors and use existing open source licenses).

the government cannot sue for copyright violations.

The government cannot enforce copyright, because under 17 USC § 105, we, the people, have told them that they are not allowed to. Creating a contract vehicle to expand the government's rights only in the realm of software development would be contrary to public policy. We don't let the government assert copyright, because we want that code to be widely available to public citizens (along with data, laws, policy guidance, reports, etc.). Software does not require a unique treatment under the law with regard to government release, and thus should not require special treatment with regard to citizen use or contribution beyond existing open source licenses.

Just to be clear, I'm not trying to suggest changes to 17 USC § 105, I understand the reasoning.

WhiteHouse / source-code-policy

Peer review of source-code policy #26