**Introduction**
The Open Source Initiative (OSI) <[https://opensource.org](https://opensource.org)> was chartered in the late 1990s as a California 501C3 to advance open source licensing and development in order to raise awareness and adoption of open source software. Today, the OSI continues to promote open source principles and practices, and protect the open source label through, education, public advocacy and community building. As the steward of the Open Source Definition (OSD) <[https://opensource.org](https://opensource.org/osd)>, through approval of licenses as “OSI-certified”, and by establishing such approval as the standard for open source software development and distribution, the OSI has become a cornerstone of software freedom.
**Standing**
The OSI is internationally acknowledged as the sole authority for certifying open source licenses as compliant with the OSD. The OSD is the gold standard of open source licensing, and the OSI, as a standards body, is trusted by the developer community as well as businesses and governments around the world. Organizations from across the globe have submitted licenses to the OSI for review and approval, these include: Apple, Computer Associates, IBM, Microsoft, Nokia, Oracle, The University of Illinois National Center for Supercomputing Applications, The University of Indiana, NASA, The European Commission, The Provincial Government of Quebec, as well as the Eclipse, Mozilla, PHP, PostgreSQL, Python, the World Wide Web Consortium (W3C) and many, many more.
OSI Board Members frequently travel the world to attend open source conferences and events, meet with open source developers and users, and discuss with executives from the public and private sectors about how open source technologies, licenses, and models of development can provide economic and strategic advantages. Most recently, within the government sector, the OSI has worked with New York City, the City and County of San Francisco, the provincial Government of Quebec, Canada, the State of California, the State of New York, the Government of India, and the The White House to provide input on factual matters related to open source software licensing and development as an enabler of software freedom.
In addition, the OSI is privileged with a growing membership including some of the worlds most successful open source projects—unequivocally independent groups with a clear commitment to open source—who strengthen our mission to educate about and advocate for the benefits of open source and to build bridges among different constituencies in the open source community. The OSI’s current membership includes, among many others, Creative Commons, Debian, the Drupal Association, Eclipse Foundation, FreeBSD Foundation, Linux Foundation, Mozilla Foundation, Open Source Electronic Health Record Alliance (OSEHRA), Python Software Foundation, Wikimedia Foundation, WordPress Foundation. Each Affiliate Member commits to upholding the mission, values and objectives of the Open Source Initiative and the Open Source Definition.
**General Comments & Alignment with the Policy: Explicitly require OSI Approved Open Source Licenses.**
The OSI is very pleased with the recent commitment to adopt a Government-wide Open Source Software policy within The White House Office of Management and Budget (OMB) as outlined in the “Federal Source Code Policy – Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software” <[https://opensource.org](https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/SourceCodePolicy.pdf)>. We agree that such a policy “will support improved access to custom software code developed for the Federal Government,” and “can fuel innovation, lower costs, and benefit the public.” <[https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/README.md](https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/README.md)>.
Governments around the globe recognize the value of open source as both a technology solution delivering value to the public they serve, as well as an approach for development returning tax-payer investments back to the society they represent. The implementation of the Federal Source Code Policy will be a key component in “reducing Federal vendor lock-in, decreasing duplicative costs for the same code, increasing transparency across the Federal Government, and minimizing the challenges associated with integrating large blocks of code from multiple sources” (Line 30, Federal Source Code Policy).
Most significantly, for the OSI and the open source software community, is the recognition of the Open Source Initiative itself and our role, OSI Approved Licenses, and the authority of the Open Source Definition, specifically:
– “a valid open source license is one that is approved by the Open Source Initiative [https://opensource.org/licenses](https://opensource.org/licenses)”;
– “Open Source Software (OSS): Software that can be freely accessed, used, changed, and shared (in modified or unmodified form) by anyone. OSS is often distributed under licenses that comply with the definition of “Open Source” provided by the Open Source Initiative [https://opensource.org/osd](https://opensource.org/osd)”, and;
– “the most widely-recognized definition of “Open Source Software” – both in the U.S. and internationally – is provided by the Open Source Initiative, and provides 10 criteria that software must meet to be considered open source. This definition is accessible at https://opensource.org/osd.”
Because the OSD is an internationally recognized standard, OSI approved licenses ensure software freedom, and provide permission first to implementing organizations so that they can adopt, adapt, improve and innovate. As former OSI President Simon Phipps wrote, “Increasingly in today’s society we expect that an individual can take action to use or improve [open source] software and a widening range of other artifacts without needing to ask permission first.” As he notes, this requires that “permission is given in advance and can be assumed. That’s the governing principle of open source. OSI approved licenses guarantee we have the freedom to use, study, improve, and share software source code, so everyone has permission in advance to solve their own problems using that software without seeking permission first” <[http://www.infoworld.com/article/2608195/open-source-software/governance-for-the-github-generation.html](http://www.infoworld.com/article/2608195/open-source-software/governance-for-the-github-generation.html)>.
An OSI approved license assures organizations—like those within the U.S. Federal Government—that the software they are interested in implementing, is indeed “open source software.” The OSI’s License Review Process, “ensures that licenses and software labeled as ‘open source’ conforms to existing community norms and expectations” <[https://opensource.org/approval](https://opensource.org/approval)>. All licenses must go through a review process which includes, alignment to the Open Source Definition, identification of appropriate License Proliferation Category, assessment of “vanity” and duplicative licenses, and public review and comment. The OSI Board consults with submitting entities in advance to help them navigate the process and improve their license, but formal approval requires going through license-review .
It is only because of the recognition of the OSD, as a standard and the OSI’s License Review process, that organizations have been so successful in collaborating around, contributing to, and co-creating the spectacular collection of open source software available today. Without such a standard, process, and oversight organization, ambiguity and uncertainty will arise. Unfortunately, as organizations who actively and authentically participate in the development of software distributed with an OSI approved license reap the business, economic, operational, and technical benefits, as well as garner public accolades and increased profile from that success, “openwashing” <[http://michellethorne.cc/2009/03/openwashing/](http://michellethorne.cc/2009/03/openwashing/)> and “fauxpen source” <[http://www.fauxpensource.org/](http://www.fauxpensource.org/)> become more prevalent. Michelle Thorn, Mozilla’s Director of the Webmaker Program, was the first to define openwashing in 2009, “to spin a product or company as open, although it is not,” while fauxpen source was introduced by Phil Marsosudiro, as “a description of software that claims to be open source, but lacks the full freedoms required by the Open Source Definition.”
This is not a theoretical problem, as several recent examples illustrate, for example:
– Qabel labels itself as “open source” but is not. According to their website, Qabel is a free, open-source and expandable platform. Yet their license includes restrictions that would impose serious limits on its use by a government, “No license is granted by the Original Copyright Holder for military, intelligence or related purposes, including but not limited to intelligence and military research” <[https://qabel.de/en/license](https://qabel.de/en/license)>.
– SailfishOS promotes open source, but is not licensed as such: “Your tablet is powered by open source software called Sailfish” ([https://www.youtube.com/watch?v=jBQdfcLhts8](https://www.youtube.com/watch?v=jBQdfcLhts8) minute 1:05). However Jolla states in the SailfishOS End User License Agreement, “Although we encourage you to develop our Software to make it better, we cannot allow such development, modifying or any harmful interaction with the version of our Software distributed integrated in a product” <[https://jolla.com/sailfish-eula/](https://jolla.com/sailfish-eula/)>. This approach will cause confusion and barriers for governments who have already identified SailfishOS as their preferred mobile operating system <[http://www.jollausers.com/2015/05/sailfish-os-to-become-russias-official-operating-system-for-mobile/](http://www.jollausers.com/2015/05/sailfish-os-to-become-russias-official-operating-system-for-mobile/)>.
– The Fair Source License seeks to align itself with the open ethos, but actually hinders wide adoption: “The Fair Source License allows everyone to see the source code and makes the software free to use for a limited number of users in your organization. It offers some of the benefits of open source while preserving the ability to charge for the software” <[https://fair.io/](https://fair.io/)>. However, as former OSI Director and current Vice President of Mobile at Adobe, Matt Asay stated “Developers don’t want to be bothered with licensing uncertainty. So, to Sourcegraph’s CEO [the Fair Source author] who claims ‘It’s better to be 90% open than 10% open,’ I’d respond, ‘No, it’s really not. Both are lame. Go open or go closed, but don’t confuse developers with a Milquetoast version of open source’” <[http://www.techrepublic.com/article/fair-source-licensing-is-the-worst-thing-to-happen-to-open-source-definitely-maybe/](http://www.techrepublic.com/article/fair-source-licensing-is-the-worst-thing-to-happen-to-open-source-definitely-maybe/)>.
Federally sponsored developers (or any organization) seeking to innovate, lower costs, and provide public good should ensure that the software under consideration carries an OSI Approved Open Source License. Without an OSI approved license, access to custom software code developed for the Federal Government would actually be reduced, as potential adopters and contributors within each agency or department will need to individually assess if the software freedoms they expect are actually present, or if the software simply—and fraudulently—carries an inauthentic “open” label. Indeed, fauxpen source software would defeat the policy’s goal to “deliver information technology (IT) and software solutions to better support cost efficiency, mission effectiveness, and the consumer experience with core Government programs” (Line 5, Federal Source Code Policy). The cost, time and expertise incurred by Federal Agencies and Departments to assess if software is actually open source, is mitigated through the OSI License Review process and OSI approved license certification. Without such, evaluating how an unknown (i.e. non-OSI approved) license may impact an agency and/or department’s access, use, modification, and distribution will become an additional burden for the Government, and any other organization that might want to participate in the project. OSI Approved Open Source Licenses, are the mechanism for “enabling Federal employees to work together—both within and across agencies—to reduce costs, streamline development, apply uniform standards, and ensure consistency in creating and delivering information” (Line22, Federal Source Code Policy). The United States Government can be sure that “OSI Approved” on a license means it’s safe to collaborate.
Another benefit of using the OSD as a standard for licensing, is in building community with both developers who contribute, and other projects who integrate. Per the Federal Source Code Policy, we agree, “Communities are critically important to the long term viability of open source projects.” The OSI License Review Process and resulting OSI approved licenses are the enabling factors that allow open source communities to form and leverage peer development. OSI Approved Open Source Licenses would allow “agencies to develop and release code in a manner that:
1. fosters communities around shared challenges;
1. optimizes the ability of the community to provide feedback on, and make contributions to, the code, and;
1. encourages Federal employees and contractors to contribute back to the broader OSS community by making contributions to existing open source projects.”
However, without such a standard, the opportunities and restrictions of Federally sponsored code development will not be readily understood by potential community members. Worse yet, some may find any unique conditions associated with code released under a non OSI license as contradictory—or even conflicting—with existing OSI approved licenses.
Of particular note, using an existing standard—specifically, the OSD—aligns with and promotes the key community principles of the Policy:
– “Leveraging existing communities” (Line 262, Federal Source Code Policy ) is best achieved by acknowledging existing norms and working with current standards—the OSI, OSI licenses and OSD are recognized and respected by these communities.
– “Open development,” (Line 267, Federal Source Code Policy) is guaranteed through the OSD, which states, “Open source doesn’t just mean access to the source code,” but provides affordances that ensures, as required in the Policy, “an environment in which open source code can flourish and be repurposed,” for example:
– “shall not restrict any party from selling or giving away the software” (Criteria !, OSD),
– “allow modifications and derived works” (Criteria 3, OSD),
– “may no discriminate against any person or group of persons or against fields of endeavor” (Criteria 5 & 6, OSD),
– “must not be specific to a product, must not restrict other software and must be technology neutral” (Criteria 8, 9 & 10, OSD).
The OSI strongly recommends identifying only software with an OSI approved license as open source software, recognizing the Open Source Definition as the standard for assessing open source licenses, and the OSI’s License Review Process as the sole means for certification.
**Specific Comments: Suggested modifications to ensure OSI Approved Licenses are referenced.**
LINE 6: “Each year, the Federal Government spends more than $9 billion on software through more than 50,000 transactions. A large portion of Government software—including proprietary, open source, and mixed source options—is commercially-available “off the shelf” (COTS) software that is developed and owned by either private vendors or an open source provider, requiring no additional custom code to be written for its use in the Federal Government.”
COMMENT: Clearly the Federal Government has detailed policies and practices for the acquisition of software. While it may be beyond the scope of the Policy, the OSI would recommend developing/amending procurement practices to include the evaluation of software distributed with an OSI Approved Open Source License. Often open source software options do not receive the benefit of review as they may not be known. Without sales and marketing teams, like those of proprietary options, the Federal Government may not be aware of all possible solutions. Requiring Federal Agencies and Departments to include references to open source options throughout the procurement process would extend the knowledge of open source options, enhance the review process, and ensure equitable consideration of all possible solutions.
LINE 33: “While the benefits of enhanced Federal code reuse are significant, additional benefits can accrue when code is also made available to the public as Open Source Software (OSS).”
COMMENT: In oder to ensure that the full benefits of open source software are realized through the Policy, we recommend editing the line to state, “…when code is also made available to the public through an OSI (Open Source Initiative) Approved Open Source License.” Indeed, these benefits (higher quality, better reliability, greater flexibility, lower cost, and an end to lock-in) exist because the Open Source Definition enables them.
LINE 35: “Making code available with an OSS license can enable continual improvement of Federal code projects when a broader community of users implements the code for its own purposes and publishes bugs and improvements.”
COMMENT: Recommend the Policy state, “Making code available with an OSI (Open Source Initiative) Approved Open Source License can enable…”
LINE 38: “A number of private sector companies have already shifted some of their software development projects to an open source model, in which the source code of the software is made broadly available to the public for inspection, improvement, and reuse.”
COMMENT: Recommend the Policy state, “…shifted some of their software development projects to include an OSI (Open Source Initiative) Approved Open Source License, in which the source code…”
LINE 124: “If a covered agency’s alternatives analysis concludes that no existing Federal solution efficiently and effectively meets its operational and mission needs, a covered agency must subsequently explore whether an appropriate COTS solution is available.”
COMMENT: We would recommend that the Policy include the means for (i.e. permit) covered agencies to procure software distributed with an OSI Approved Open Source License, even if there is an existing solution for which the Government holds an appropriate license or ability to reuse. For example, in addition to the condition that allows procurement if an existing solution is not available, “If a covered agency’s alternatives analysis concludes that no existing Federal solution efficiently and effectively meets its operational and mission needs or is only available distributed with a proprietary license, a covered agency must subsequently explore whether an appropriate solution with an OSI Approved Open Source License is available.”
LINE 157: Require delivery of the underlying custom source code, associated documentation, and related files from the third-party developer or vendor to the Federal organization (including build instructions and, when applicable, software user guides, other associated documentation, and automated test suites);
COMMENT: Simply requiring that the third party developer or vendor assign an OSI Approved Open Source License would ensure these requirements are met.
LINE 162: Secure unlimited rights to the custom source code, associated documentation, and related files—which includes the rights to reproduction, reuse, and distribution of the custom source code, associated documentation, and related files across the Federal Government
COMMENT: Again, simply requiring that the third party developer or vendor assign an OSI Approved Open Source License would ensure these requirements are met. In addition, the Government agency (and all those across the Federal Government) would benefit from a larger pool of potential developers/contributors, enabling non-government organizations to also participate in the project, thus amplifying the benefits of open source software development.
LINE 170: Securing Federal Government-wide reuse rights for custom code is a critical first step in gaining efficiencies in Federal software purchasing; however, without broad and consistent dissemination of the code across the Federal Government, these efficiencies cannot be fully realized. Therefore, in addition to securing the rights discussed above, covered agencies must make custom-developed code available to all other Federal agencies.
COMMENT: As previously suggested, requiring that the third party developer or vendor assign an OSI Approved Open Source License would ensure this requirement is met. And as suggested above, all Government agencies would benefit from a larger pool of potential developers/contributors where non-government organizations could to also participate in the project, thus amplifying the benefits of open source software development.
LINE 184: Similarly, when properly implemented and documented, releasing code as open source can benefit Federal agencies by allowing professional communities of practice to develop around software libraries and Application Programming Interfaces (APIs).
COMMENT: Here we would recommend stating explicitly “releasing code with an OSI Approved Open Source License” to ensure alignment with industry standards.
LINE 218 : Federal Government and beyond can result in, among other things, enhancements to code quality and security as a result of public scrutiny of open source code.
COMMENT: Here we would recommend referencing code carrying an OSI approved license, for example, “…security as a result of public scrutiny of code distributes under an OSI Approved Open Source License.”
LINE 177: Note that although Government-wide reuse of custom-developed code shares some of the same benefits as OSS, it does not meet the definition of OSS and should therefore not be mislabeled as such.
COMMENT: In what ways does the Government-wide reuse of custom-developed code differ from the affordances offered through the OSD? Establishing another set of criteria for code development and distribution within the Government will add to ambiguity and confusion among the software development community. Organizations will be required to invest significant resources in assessing each release of code and any accompanying custom/one-off licenses to ensure they have the ability to use, modify and/or redistribute such code. Defaulting to OSI Approved Open Source Licenses would remove this burden and increase the pace of development, sharing, and innovation.
LINE 184: Similarly, when properly implemented and documented, releasing code as open source can benefit Federal agencies by allowing professional communities of practice to develop around software libraries and Application Programming Interfaces (APIs).
COMMENT: Suggest modifying the line to state, “…releasing code with an OSI Approved Open Source License…” to ensure constancy and continuity with expectations within the open source community as stated in the following line, “This collaborative atmosphere makes it easier to conduct software peer review and security testing, to reuse existing solutions, and to share technical knowledge.”
LINE 229: Each covered agency shall release at least 20 percent of its newly-developed custom code each year as OSS.
COMMENT: We would suggest an update of the Policy language to require each covered agency to release at least 20 percent of its newly-developed custom code each year with an OSI Approved Open Source License. In addition, we would hope that the Policy could include a larger percent, but recognize that an iterative process might help Federal Agencies and Departments transition. Perhaps including in the Policy methods and metrics for increasing the amount of code released could be of benefit?
LINES 458 : Open Source License: OSS is often associated with a license that details the terms and conditions governing the intellectual property rights of the software and its associated source code. These licenses specify how a particular work may be reproduced, modified, or used as a component of a larger system or as a standalone piece of software. (49)
49. As of the publication date of this policy, a valid open source license is one that is approved by the Open Source Initiative (https://opensource.org/licenses). Further licensing considerations, including suggested licenses, will be provided via Project Open Source.
COMMENT: As all licenses, “detail the terms and conditions governing the intellectual property rights of the software and its associated source code,” we feel it would be best to unambiguously denote the specific differences (affordances) of open source software licensing as made possible through the OSD. This is best conveyed by specifically stating, for example, “OSS is software distributed with a license certified by the Open Source Initiative that details the terms and conditions… “
In addition, the line “Further licensing considerations, including suggested licenses, will be provided via Project Open Source,” is confusing and will raise concerns among potential collaborators, such as:
angst among possible adoptors and contributors about investing the required resources to fully assess these new, “suggested licenses’” terms and conditions;
doubt whether the new, “suggested licenses” actually provide all of the freedoms of a community standard OSI approved license, and;
fear over license compatibility with other known OSI approved licenses.
We would strongly recommend working with the OSI and our License Review process over creating any new licenses or process for licensing.
LINE: 463: Open Source Software (OSS): Software that can be freely accessed, used, changed, and shared (in modified or unmodified form) by anyone. OSS is often distributed under licenses that comply with the definition of “Open Source” provided by the Open Source Initiative (https://opensource.org/osd). (50)
50. This definition is current as of the publication date of this policy. For future guidance regarding this definition, please refer to Project Open Source.
COMMENT: We are pleased that the Policy includes a quote from the OSI FAQ, “What is “Open Source” software?”
Can I call my program “Open Source” even if I don’t use an approved license?
Please don’t do that. If you call it “Open Source” without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it’s part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem. <[https://opensource.org/faq#avoid-unapproved-licenses](https://opensource.org/faq#avoid-unapproved-licenses)>.
**Thank you for the Opportunity**
On behalf of the OSI Board of Directors, I would like to thank you very much for your good work in developing a thoughtful and comprehensive Policy as well as extending to the public the opportunity to review and comment on your work. We hope that our experience as the founders of the open source software movement, and industry recognized authority in open source incensing, can provide the White House Office of Management and Budget some additional insights for further consideration. If we can help in any way, please know we stand ready to assist you.
Best of luck moving forward,
Patrick Masson
General Manager and Director,
Open Source Initiative,
855 El Camino Real, Ste 13A, #270
Palo Alto, CA 94301
United States
[opensource.org](https://opensource.org)