开放源代码促进会 (OSI) 对白宫管理与预算办公室关于“联邦源代码政策”的评论
*注意：以下评论是代表 OSI 提交给白宫管理与预算办公室，关于“联邦源代码政策”的意见 [https://github.com/WhiteHouse/source-code-policy/issues/227](https://github.com/WhiteHouse/source-code-policy/issues/227)*
**引言**
开放源代码促进会 (OSI) <[https://open-source.org.cn](https://open-source.org.cn)> 于 1990 年代后期注册成立为加利福尼亚州 501C3 非营利组织，旨在推进开放源代码许可和开发，以提高人们对开放源代码软件的认识和采用。今天，OSI 继续通过教育、公共宣传和社区建设来推广开放源代码原则和实践，并保护开放源代码标签。作为开放源代码定义 (OSD) <[https://open-source.org.cn](https://open-source.org.cn/osd)> 的管理者，通过批准许可证为“OSI 认证”，并将此类批准确立为开放源代码软件开发和发行的标准，OSI 已成为软件自由的基石。
**立场**
OSI 在国际上被公认为认证开放源代码许可证是否符合 OSD 的唯一权威机构。OSD 是开放源代码许可的黄金标准，而 OSI 作为一个标准机构，受到全球开发者社区以及企业和政府的信任。来自全球各地的组织已向 OSI 提交许可证以供审查和批准，其中包括：苹果、冠群电脑、IBM、微软、诺基亚、甲骨文、伊利诺伊大学国家超级计算应用中心、印第安纳大学、美国宇航局、欧盟委员会、魁北克省政府，以及 Eclipse、Mozilla、PHP、PostgreSQL、Python、万维网联盟 (W3C) 以及更多组织。
OSI 董事会成员经常环游世界，参加开放源代码会议和活动，会见开放源代码开发者和用户，并与公共和私营部门的行政人员讨论开放源代码技术、许可证和开发模式如何提供经济和战略优势。最近，在政府部门，OSI 与纽约市、旧金山市和县、加拿大魁北克省政府、加利福尼亚州、纽约州、印度政府和白宫合作，就与开放源代码软件许可和开发作为软件自由推动因素有关的事实问题提供意见。
此外，OSI 很荣幸拥有不断增长的会员群体，其中包括世界上一些最成功的开放源代码项目——明确独立的团体，对开放源代码有着清晰的承诺——他们加强了我们的使命，即教育和倡导开放源代码的好处，并在开放源代码社区的不同群体之间架起桥梁。OSI 目前的会员包括但不限于 Creative Commons、Debian、Drupal 协会、Eclipse 基金会、FreeBSD 基金会、Linux 基金会、Mozilla 基金会、开放源代码电子健康记录联盟 (OSEHRA)、Python 软件基金会、维基媒体基金会、WordPress 基金会。每个附属会员都承诺维护开放源代码促进会和开放源代码定义的使命、价值观和目标。
**一般性评论和与政策的对齐：明确要求 OSI 批准的开放源代码许可证。**
OSI 非常高兴白宫管理与预算办公室 (OMB) 最近承诺采纳政府范围内的开放源代码软件政策，正如“联邦源代码政策——通过可重用和开放源代码软件实现效率、透明度和创新” <[https://open-source.org.cn](https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/SourceCodePolicy.pdf)> 中概述的那样。我们同意，这样一项政策“将支持改进对为联邦政府开发的定制软件代码的访问”，并且“可以促进创新、降低成本并造福公众”。 <[https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/README.md](https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/README.md)>。
全球各国政府都认识到开放源代码的价值，它既是一种为公众提供价值的技术解决方案，也是一种将纳税人投资回报给其代表的社会的发展方法。“联邦源代码政策”的实施将成为“减少联邦供应商锁定、降低相同代码的重复成本、提高整个联邦政府的透明度以及最大限度地减少与集成来自多个来源的大量代码块相关的挑战”（联邦源代码政策第 30 行）的关键组成部分。
对于 OSI 和开放源代码软件社区而言，最重要的是对开放源代码促进会本身及其作用、OSI 批准的许可证以及开放源代码定义的权威性的认可，特别是：
– “有效的开放源代码许可证是指经开放源代码促进会批准的许可证 [https://open-source.org.cn/licenses](https://open-source.org.cn/licenses)”；
– “开放源代码软件 (OSS)：可以由任何人自由访问、使用、更改和共享（以修改或未修改的形式）的软件。OSS 通常根据符合开放源代码促进会提供的“开放源代码”定义的许可证分发 [https://open-source.org.cn/osd](https://open-source.org.cn/osd)”，以及；
– ““开放源代码软件”的最广泛认可的定义——无论是在美国还是国际上——都由开放源代码促进会提供，并提供了软件必须满足的 10 个标准才能被视为开放源代码。此定义可在 https://open-source.org.cn/osd 访问。”
由于 OSD 是一项国际公认的标准，OSI 批准的许可证确保软件自由，并首先向实施组织提供许可，以便他们能够采用、改编、改进和创新。正如前 OSI 主席 Simon Phipps 所写，“在当今社会，我们越来越期望个人可以采取行动来使用或改进[开放源代码]软件和范围越来越广的其他人工制品，而无需首先请求许可。” 正如他所指出的，这需要“提前给予许可并且可以被假定。这就是开放源代码的 governing principle。OSI 批准的许可证保证我们拥有使用、研究、改进和共享软件源代码的自由，因此每个人都预先获得许可，可以使用该软件解决自己的问题，而无需首先寻求许可” <[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)>。
OSI 批准的许可证向组织（例如美国联邦政府内的组织）保证，他们有兴趣实施的软件确实是“开放源代码软件”。OSI 的许可证审查流程“确保标记为“开放源代码”的许可证和软件符合现有的社区规范和期望” <[https://open-source.org.cn/approval](https://open-source.org.cn/approval)>。所有许可证都必须经过审查流程，其中包括与开放源代码定义的一致性、适当的许可证扩散类别识别、对“虚荣”和重复许可证的评估以及公众审查和评论。OSI 董事会提前与提交实体协商，以帮助他们浏览流程并改进其许可证，但正式批准需要通过许可证审查。
正是由于 OSD 作为标准的认可和 OSI 的许可证审查流程，组织才能如此成功地围绕开放源代码软件进行协作、贡献和共同创建，从而形成了今天可用的壮观的开放源代码软件集合。如果没有这样的标准、流程和监督组织，就会出现歧义和不确定性。不幸的是，随着积极和真实地参与使用 OSI 批准的许可证分发的软件开发的组织获得业务、经济、运营和技术优势，并因其成功而获得公众赞誉和知名度提升，“开放源代码粉饰” <[http://michellethorne.cc/2009/03/openwashing/](http://michellethorne.cc/2009/03/openwashing/)> 和 “fauxpen source” <[http://www.fauxpensource.org/](http://www.fauxpensource.org/)> 变得越来越普遍。Mozilla Webmaker 项目主管 Michelle Thorn 于 2009 年首次定义了开放源代码粉饰，“将产品或公司宣传为开放的，尽管它不是”，而 fauxpen source 由 Phil Marsosudiro 引入，作为“对声称是开放源代码但缺乏开放源代码定义要求的完全自由的软件的描述”。
这不是一个理论问题，因为最近的几个例子说明了这一点，例如：
– Qabel 将自己标记为“开放源代码”，但实际上并非如此。根据他们的网站，Qabel 是一个免费、开放源代码和可扩展的平台。然而，他们的许可证包含限制，这些限制将对其在政府中的使用施加严重限制，“原始版权持有人未授予用于军事、情报或相关目的的许可，包括但不限于情报和军事研究” <[https://qabel.de/en/license](https://qabel.de/en/license)>。
– SailfishOS 推广开放源代码，但未获得此类许可：“您的平板电脑由名为 Sailfish 的开放源代码软件驱动” ([https://www.youtube.com/watch?v=jBQdfcLhts8](https://www.youtube.com/watch?v=jBQdfcLhts8) 1:05 分钟)。然而，Jolla 在 SailfishOS 最终用户许可协议中声明，“尽管我们鼓励您开发我们的软件以使其更好，但我们不允许对此类开发、修改或与产品中集成的软件版本进行任何有害交互” <[https://jolla.com/sailfish-eula/](https://jolla.com/sailfish-eula/)>。这种方法将给已经将 SailfishOS 确定为其首选移动操作系统的政府带来困惑和障碍 <[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/)>。
– Fair Source License 试图与开放精神保持一致，但实际上阻碍了广泛采用：“Fair Source License 允许所有人查看源代码，并使该软件可以在您的组织中免费供有限数量的用户使用。它提供了一些开放源代码的好处，同时保留了对软件收费的能力” <[https://fair.io/](https://fair.io/)>。然而，正如前 OSI 主管兼 Adobe 移动副总裁 Matt Asay 所说，“开发者不想为许可不确定性而烦恼。因此，对于 Sourcegraph 的 CEO [Fair Source 作者] 声称“90% 开放比 10% 开放更好”，我会回应说，“不，真的不是。两者都很逊。要么开放，要么封闭，但不要用 Milquetoast 版本的开放源代码来迷惑开发者”” <[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/)>。
联邦政府赞助的开发者（或任何组织）寻求创新、降低成本和提供公共利益，应确保正在考虑的软件带有 OSI 批准的开放源代码许可证。如果没有 OSI 批准的许可证，对为联邦政府开发的定制软件代码的访问实际上会减少，因为每个机构或部门内的潜在采用者和贡献者都需要单独评估他们期望的软件自由是否实际存在，或者该软件是否只是简单地——并且虚假地——带有不真实的“开放”标签。实际上，fauxpen source 软件会破坏该政策的目标，即“交付信息技术 (IT) 和软件解决方案，以更好地支持成本效率、任务有效性以及消费者与核心政府计划的体验”（联邦源代码政策第 5 行）。联邦机构和部门评估软件是否实际上是开放源代码所产生的成本、时间和专业知识，可以通过 OSI 许可证审查流程和 OSI 批准的许可证认证来缓解。如果没有这些，评估未知的（即非 OSI 批准的）许可证可能对机构和/或部门的访问、使用、修改和分发产生何种影响将成为政府以及任何其他可能希望参与该项目的组织的额外负担。OSI 批准的开放源代码许可证是“使联邦雇员能够在机构内部和跨机构协同工作——以降低成本、简化开发、应用统一标准并确保创建和交付信息的一致性”（联邦源代码政策第 22 行）的机制。美国政府可以确信，许可证上的“OSI 批准”意味着可以安全地协作。
使用 OSD 作为许可标准的另一个好处是与贡献的开发者和集成的其他项目建立社区。根据联邦源代码政策，我们同意，“社区对于开放源代码项目的长期生存能力至关重要。” OSI 许可证审查流程和由此产生的 OSI 批准的许可证是使开放源代码社区能够形成和利用同行开发的促成因素。OSI 批准的开放源代码许可证将允许“机构以以下方式开发和发布代码：
1. 培养围绕共同挑战的社区；
2. 最大化社区提供反馈和为代码做出贡献的能力，以及；
3. 鼓励联邦雇员和承包商通过为现有开放源代码项目做出贡献来回馈更广泛的 OSS 社区。”
然而，如果没有这样的标准，潜在的社区成员将无法轻易理解联邦政府赞助的代码开发的机会和限制。更糟糕的是，有些人可能会发现与非 OSI 许可证下发布的代码相关的任何独特条件与现有的 OSI 批准的许可证相矛盾——甚至冲突。
特别值得注意的是，使用现有标准——特别是 OSD——符合并促进了该政策的关键社区原则：
– “利用现有社区”（联邦源代码政策第 262 行）最好通过承认现有规范并与当前标准合作来实现——OSI、OSI 许可证和 OSD 受到这些社区的认可和尊重。
– “开放开发”（联邦源代码政策第 267 行）通过 OSD 得到保证，OSD 声明“开放源代码不仅仅意味着访问源代码”，而是提供确保（如政策要求）“开放源代码可以蓬勃发展并被重新利用的环境”的条件，例如：
– “不得限制任何一方出售或赠送软件”（OSD 标准 1），
– “允许修改和派生作品”（OSD 标准 3），
– “不得歧视任何人或人群或任何领域”（OSD 标准 5 和 6），
– “不得特定于产品，不得限制其他软件，并且必须是技术中立的”（OSD 标准 8、9 和 10）。
OSI 强烈建议仅将带有 OSI 批准的许可证的软件标识为开放源代码软件，承认开放源代码定义是评估开放源代码许可证的标准，而 OSI 的许可证审查流程是认证的唯一手段。
**具体评论：建议的修改以确保引用 OSI 批准的许可证。**
第 6 行：“联邦政府每年在软件上的支出超过 90 亿美元，交易超过 50,000 笔。很大一部分政府软件——包括专有、开放源代码和混合源代码选项——是商业上可用的“现成” (COTS) 软件，这些软件由私人供应商或开放源代码提供商开发和拥有，无需编写额外的定制代码即可在联邦政府中使用。”
评论：显然，联邦政府有详细的软件采购政策和实践。虽然这可能超出政策的范围，但 OSI 建议制定/修订采购实践，以包括评估使用 OSI 批准的开放源代码许可证分发的软件。开放源代码软件选项通常可能不会因其不为人知而获得审查的好处。与专有选项的销售和营销团队不同，联邦政府可能不知道所有可能的解决方案。要求联邦机构和部门在整个采购过程中包括对开放源代码选项的引用将扩展对开放源代码选项的了解，加强审查流程，并确保公平考虑所有可能的解决方案。
第 33 行：“虽然增强联邦代码重用的好处显着，但当代码也作为开放源代码软件 (OSS) 向公众提供时，可以获得额外的好处。”
评论：为了确保通过该政策实现开放源代码软件的全部好处，我们建议将该行编辑为，“……当代码也通过 OSI（开放源代码促进会）批准的开放源代码许可证向公众提供时。” 实际上，这些好处（更高的质量、更好的可靠性、更大的灵活性、更低的成本以及最终消除锁定）之所以存在，是因为开放源代码定义使它们成为可能。
第 35 行：“当更广泛的用户社区出于自身目的实施代码并发布错误和改进时，使用 OSS 许可证提供代码可以实现联邦代码项目的持续改进。”
评论：建议政策声明，“使用 OSI（开放源代码促进会）批准的开放源代码许可证提供代码可以实现……”
第 38 行：“许多私营部门公司已经将其部分软件开发项目转移到开放源代码模式，在这种模式下，软件的源代码被广泛提供给公众进行检查、改进和重用。”
评论：建议政策声明，“……将其部分软件开发项目转移到包括 OSI（开放源代码促进会）批准的开放源代码许可证，在这种模式下，源代码……”
第 124 行：“如果受管辖机构的替代方案分析得出结论，认为没有现有的联邦解决方案能够有效且高效地满足其运营和任务需求，则受管辖机构随后必须探索是否可以获得合适的 COTS 解决方案。”
评论：我们建议该政策包括受管辖机构采购使用 OSI 批准的开放源代码许可证分发的软件的手段（即允许），即使存在政府持有适当许可证或重用能力的现有解决方案。例如，除了允许采购的条件（如果现有解决方案不可用）之外，“如果受管辖机构的替代方案分析得出结论，认为没有现有的联邦解决方案能够有效且高效地满足其运营和任务需求，或者仅以专有许可证分发，则受管辖机构随后必须探索是否可以获得带有 OSI 批准的开放源代码许可证的合适解决方案。”
第 157 行：要求第三方开发者或供应商向联邦组织交付底层定制源代码、相关文档和相关文件（包括构建说明以及在适用时，软件用户指南、其他相关文档和自动化测试套件）；
评论：仅需要求第三方开发者或供应商分配 OSI 批准的开放源代码许可证即可确保满足这些要求。
第 162 行：获得定制源代码、相关文档和相关文件的无限权利——其中包括在整个联邦政府范围内复制、重用和分发定制源代码、相关文档和相关文件的权利
评论：同样，仅需要求第三方开发者或供应商分配 OSI 批准的开放源代码许可证即可确保满足这些要求。此外，政府机构（以及整个联邦政府的所有机构）将受益于更大的潜在开发者/贡献者群体，使非政府组织也能够参与该项目，从而扩大开放源代码软件开发的好处。
第 170 行：确保联邦政府范围内的定制代码重用权是在联邦软件采购中提高效率的关键第一步；但是，如果没有在整个联邦政府范围内广泛而一致地传播代码，这些效率就无法充分实现。因此，除了获得上述讨论的权利外，受管辖机构还必须向所有其他联邦机构提供定制开发的代码。
评论：如前所述，要求第三方开发者或供应商分配 OSI 批准的开放源代码许可证将确保满足此要求。并且如上所述，所有政府机构都将受益于更大的潜在开发者/贡献者群体，非政府组织也可以参与该项目，从而扩大开放源代码软件开发的好处。
第 184 行：同样，当正确实施和记录时，以开放源代码形式发布代码可以通过允许围绕软件库和应用程序编程接口 (API) 发展专业实践社区来使联邦机构受益。
评论：在这里，我们建议明确声明“以 OSI 批准的开放源代码许可证发布代码”，以确保与行业标准保持一致。
第 218 行：联邦政府及其他机构可以通过公众对开放源代码的审查，从而提高代码质量和安全性等。
评论：在这里，我们建议引用带有 OSI 批准的许可证的代码，例如，“……通过公众对根据 OSI 批准的开放源代码许可证分发的代码的审查，从而提高安全性。”
第 177 行：请注意，尽管政府范围内的定制开发代码重用与 OSS 共享一些相同的好处，但它不符合 OSS 的定义，因此不应被错误地标记为 OSS。
评论：政府范围内的定制开发代码重用在哪些方面不同于 OSD 提供的条件？在政府内部建立另一套代码开发和分发标准将增加软件开发社区的歧义和困惑。组织将被要求投入大量资源来评估每个代码版本和任何随附的定制/一次性许可证，以确保他们有能力使用、修改和/或重新分发此类代码。默认使用 OSI 批准的开放源代码许可证将消除这种负担并加快开发、共享和创新的步伐。
第 184 行：同样，当正确实施和记录时，以开放源代码形式发布代码可以通过允许围绕软件库和应用程序编程接口 (API) 发展专业实践社区来使联邦机构受益。
评论：建议将该行修改为，“……以 OSI 批准的开放源代码许可证发布代码……”以确保与开放源代码社区内的期望保持一致性和连续性，如下一行所述，“这种协作氛围使软件同行评审和安全测试、重用现有解决方案以及共享技术知识变得更加容易。”
第 229 行：每个受管辖机构每年应将其至少 20% 的新开发的定制代码作为 OSS 发布。
评论：我们建议更新政策语言，要求每个受管辖机构每年将其至少 20% 的新开发的定制代码以 OSI 批准的开放源代码许可证发布。此外，我们希望该政策可以包含更高的百分比，但认识到迭代过程可能有助于联邦机构和部门转型。或许在政策中包含增加发布的代码量的方法和指标可能会有所帮助？
第 458 行：开放源代码许可证：OSS 通常与许可证相关联，该许可证详细说明了管理软件及其相关源代码知识产权的条款和条件。这些许可证规定了如何复制、修改特定作品或将其用作更大系统或独立软件的组件。(49)
49. 截至本政策发布之日，有效的开放源代码许可证是指经开放源代码促进会 (https://open-source.org.cn/licenses) 批准的许可证。进一步的许可考虑因素，包括建议的许可证，将通过开放源代码项目提供。
评论：由于所有许可证“详细说明了管理软件及其相关源代码知识产权的条款和条件”，我们认为最好明确指出开放源代码软件许可的特定差异（条件），这是通过 OSD 实现的。最好通过具体说明来传达这一点，例如，“OSS 是使用经开放源代码促进会认证的许可证分发的软件，该许可证详细说明了条款和条件……”
此外，“进一步的许可考虑因素，包括建议的许可证，将通过开放源代码项目提供”这一行令人困惑，并将引起潜在合作者的担忧，例如：
潜在的采用者和贡献者担心投入必要资源来充分评估这些新的“建议的许可证”的条款和条件；
怀疑新的“建议的许可证”是否实际提供社区标准 OSI 批准的许可证的所有自由，以及；
担心与其他已知的 OSI 批准的许可证的许可证兼容性。
我们强烈建议与 OSI 及其许可证审查流程合作，而不是创建任何新的许可证或许可流程。
第 463 行：开放源代码软件 (OSS)：可以由任何人自由访问、使用、更改和共享（以修改或未修改的形式）的软件。OSS 通常根据符合开放源代码促进会提供的“开放源代码”定义的许可证分发 (https://open-source.org.cn/osd)。(50)
50. 此定义在本政策发布之日为最新。有关此定义的未来指导，请参阅开放源代码项目。
评论：我们很高兴该政策引用了 OSI 常见问题解答“什么是“开放源代码”软件？”
即使我不使用批准的许可证，我可以将我的程序称为“开放源代码”吗？
请不要这样做。如果您在不使用批准的许可证的情况下将其称为“开放源代码”，您会使人们感到困惑。这不仅仅是一个理论上的担忧——我们过去已经看到过这种困惑发生，这也是我们制定正式许可证批准流程的部分原因。另请参阅我们的许可证扩散页面，了解为什么这是一个问题。 <[https://open-source.org.cn/faq#avoid-unapproved-licenses](https://open-source.org.cn/faq#avoid-unapproved-licenses)>。
**感谢您的机会**
我谨代表 OSI 董事会，非常感谢您在制定周到而全面的政策以及向公众开放审查和评论您的工作方面所做的出色工作。我们希望我们作为开放源代码软件运动的创始人和行业公认的开放源代码许可权威机构的经验，可以为白宫管理与预算办公室提供一些额外的见解，以供进一步考虑。如果我们在任何方面可以提供帮助，请知道我们随时准备为您服务。
祝您一切顺利，
Patrick Masson
总经理兼主管，
开放源代码促进会，
855 El Camino Real, Ste 13A, #270
Palo Alto, CA 94301
美国
[opensource.org](https://open-source.org.cn)