本文目录
开源技术使用范围和权利义务
维护作者和贡献者的合法权利，保证软件不被一些商业机构或个人窃取而影响软件的长远发展。要求金融机构在使用开源技术时，应遵循“安全可控、合规使用、问题导向、开放创新”等原则。金融机构应当遵循开源技术相关法律和许可要求，合规使用开源技术，明确开源技术的使用范围和使用的权利与义务，保障开源技术作者或权利人的合法权益。开源技术指金融机构从代码托管平台、技术社区、开源机构官方网站等渠道获取，或通过合作研发、商业采购等方式引入的开源代码、开源组件、开源软件和基于开源技术的云服务等。
如何使用开源代码
开源代码都有自身的发布许可证（License），License 中会规定使用者权力和义务。有些License 中的规定可能给使用者带来知识产品方面的风险，比如GPL License，就要求使用者基于该代码衍生出的新的软件代码页必须要用GPL 发布，也就是一定要开源，如果用户的软件没有开源，或者没有按照GPL License 来发布，就会有法律风险。另外，有些开源代码本身也存在漏洞，也会给使用者带来风险。这些都是使用开源代码时须有注意的，当然，有一款叫black duck software 的软件能够很好的帮助使用者解决这些问题。
使用开源代码有风险吗，怎样避开这些风险
有风险的，不管是开源代码被使用的权限会不会涉及到知识产品等法律问题，还是部分开源代码本身是否存在安全漏洞等等都是有风险的。当然，有一款叫black duck的软件是专业帮助使用者解决此类问题的，目前好像达信通成科技在代理这款软件。
计算机设计大赛开源代码与组件使用情况说明怎么填写
网站上都有提示，根据提示填写即可，填写格式按照说明是格式。详细设计说明书又可称程序设计说明书。编制目的是说明一个软件系统各个层次中的每一个程序 （每个模块或子程序）的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关 内容合并入概要设计说明书。说明书格式如下：1引言1.1编写目的说明编写这份详细设计说明书的目的，指出预期的读者。1.2背景a．待开发软件系统的名称；b.本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。1.3定义列出本项目中用到专门术语的定义和外文首字母组词的原词组。
这个代码属于什么代码，要如何使用
首先你上面贴出的代码肯定是Python脚本语言代码。其次我估计你问的主要是 __license__ = ’GPL v3’ 这个是什么。GPL V3是一种开源协议。其实是GPL协议的第三版，标在此处，也是声明这个代码的协议类型，后人如果用它这个代码也必须遵守GPL V3这个协议，关于这个协议具体介绍，因为百度不允许发链接，所以我Copy了网文：在过去的十年中，软件开发实践中最惊人的变更之一是“复合”软件系统的构建 —— 一种由自产的、开源的和第三方组件构成的组合，这使得开发团队可以快速地交付先进、全面的解决方案。然而，不受监管地使用开放源码和第三方组件增加了风险。这种方式容易因此侵犯知识产权，产生未知的特许权义务，增加维护成本，并引入未经确认的安全漏洞。在本文中，我将介绍由创建复合软件系统而引起的复杂性问题的相关背景，并阐述最新版本的 General Public License (GPLv3) 在许多重要的领域如何影响开发监管（governance）。背景开源软件是极好的资源，因为它让开发人员复用现有的代码来满足具体的需求，而不是从零开始写新的软件。还有额外的好处是，能满足用户和开发人员需求的开源组件会持续存活，并随着时间的推移，会由许多不同的人对现存代码进行持续的审查和改进。渐渐地，所开发的软件将演进为错误更少（bug-free）、更有用，而且更健壮。开源代码在众多开源项目中开发。就在写作本文的时候，已经有超过 180,000 个独立的开源项目（尽管不是所有的项目都是活动的），并且每天都在产生着更多的开源项目。根据定义，开源代码是共享的，因此，开源项目一般存放在可公共访问的 Web 上（尽管最初的时候代码是通过磁带和电子公告板进行共享的，并且有时可以从其他来源，例如从图书中获得）。大量的 Web 站点存有开源项目。我的公司，黑鸭软件 (Black Duck Software)，已经确认出超过 3000 个下载站点，它们包含了超过 4 亿 8 千 5 百万个开源文件。自从 2006 年 1 月以来，开源软件许可领域中有史以来最大的争论一直围绕着 GNU General Public License (GPL) v3 的制定。1991 年发布的 GPLv2 是监管开源代码的最知名且使用最广泛的许可证之一。它被应用于 Linux 内核以及许多其他被广泛使用的开源项目。在全球范围内，GPLv2 已经影响了数以千计的公司以及它们的应用程序开发团队，他们将 GPL 监管的代码作为它们产品的一部分。GPL 的基本权益是任何人均可以使用、修改和再分发由许可证监管的代码，约定 1) 任何分发副本都包含一份许可证的副本，并且 2) 衍生产品的所有源代码都是可自由获得的。版本 3 如何扩展 GPL 的适用范围在经过多个月的制定之后，GNU General Public License 版本 3 (GPLv3) 由自由软件基金会 (Free Software Foundation, FSF) 于 2007 年 6 月 29 日正式发布。GPLv3 的术语与 GPLv2 相似，但扩展了 GPL 的适用范围，甚至更深入涉及到像专利和数字版权管理这样的领域。GPLv3 在四个关键的方面（分别涉及互惠权益、数字版权管理、专利，和许可证兼容性）包含了影响软件开发的条款。以下是这些条款的简要概括：互惠权益（衍生产品）同 GPLv2 一样，GPLv3 是互惠的许可证。这意味着如果应用程序加入了 GPL 所监管的代码，或者，是使用了“基于 GPL 监管代码的产品”，并且因此而产生的应用程序是用于分发的，那么它必须在 GPL 下分发。GPL 本身规定，任何分发副本都必须包括其源代码和 GPL 许可证副本。多年来，对于在软件这一前提下“基于……的产品”或“衍生产品”这两个术语的含义有相当多的争议。举例来说，Free Software Foundation 认为动态地链接文件也产生了衍生产品。因而，在他们的世界观里，即使将您的专有代码链接到 GPL 监管的 .DLL 文件或其他共享的库中，都应该强制将源代码的公开发布。这种诠释释无疑令开发组织在使用 GPL 许可的代码用作开发过程一部分的问题上小心谨慎。GPLv3 在关于衍生产品具体由什么构成的问题上增加了更多的透明度。举例来说，GPLv3 规定，如果程序是“特别设计成”使用 GPL 监管的库的，那么该库即被认为是整体产品的一部分，并且整个应用程序受 GPL 监管。然而，如果可以使用另一个库将 GPL 库完全置换（也即，如果应用程序不是“特别设计成”使用 GPL 库的），那么该库就不是整体产品的一部分，并且不会受许可证的监管。数字版权管理（嵌入式设备）“数字版权管理” (Digital Rights Management, DRM) 描述了一种技术方法，通过它，消费型设备的发行人可以防止用户将篡改的代码部署到设备上。FSF 想要定义 DRM 的含义，至少对于涉及 GPLv3 的代码。要这样做，GPLv3 包含了以下内容：首先，许可证禁止将 GPLv3 本身用作 DRM 的一部分。其次，FSF 增加了条款，用于确保任何用户可以修改安装在消费型设备上的 GPLv3 代码，以及在设备上重新加载代码被修改过的版本。除了提供 GPLv3 之下源代码的义务以外，许可证还要求发行人提供在可应用的设备上重新加载已修改代码所需的所有安装信息。虽然有一些内在的局限性，但 GPLv3 的 DRM 条款将很自然地有利于消费型设备的制造者和发行人，这是由于它们一旦使用了 GPLv3 代码而履行相应义务，从而获得的宽松政策。专利（再分发代码）新的许可证提供了与可能应用于已开发代码的专利义务相关的指南。GPLv3 包含了一个广泛的扩散专利许可 (expressed patent license)。简单地说，这意味着如果开发人员修改了 GPL 代码并且重新发布它，该开发人员即自动地向所有可能应用于整个应用程序的专利授予专利许可证。任何衍生产品都因此得益于此专利许可证。通过这种方式，FSF 试图确保用户拥有任何已被修改的 GPL 监管代码的广泛专利版权。GPLv3 还包含了“专利保护”条款，意思是，如果 GPL 代码 (GPL’d code) 的用户提出了任何基于该代码的专利声明，那么该用户将丧失他们对这一 GPL 下代码所拥有的 GPL 许可证。许可证兼容性（多重许可证问题）GPL 版本 3 并不是要取代版本 2。它们将并存，因此开源项目可以选择在任一许可证版本下发布他们的代码。GPLv2 下的大部分代码可以被用户转换为 GPLv3（这是在 GPLv2 下通常被允许的惯例）。然而，一些项目 —— 最著名的是 Linux 内核 —— 不是在包含这种权限的许可证版本下发布的。那些项目不计划在 GPLv3 下发布他们的项目。GPLv3 中其他的许可证兼容性条款是同样需慎重对待的。新的许可证向开发人员提供了可以向许可证添加某些规定的额外条款的权利，从而令其代码与其他开源许可证兼容。开发人员一直在申请这个权利，而现在，举例来说，只要将所需的条款添加到他们自己所制定的 GPLv3 版本中，就可以将流行的 Apache 许可证所监管的代码和在 GPL 下编写的代码进行结合。如果组织发布 GPLv3 代码，那么它们将需要明了那些额外的条件。最后，GPLv3 包含了让开发人员将 GPLv3 代码与 Affero 许可证涵盖的代码相结合的语言。Affero 许可证去掉开发人员在 GPL 中发现的一个“漏洞”，即如果的应用程序是基于 Web 的（例如在基于 Web 的搜索引擎中，等等），由于 GPL 要求开发人员发布源代码而带来的一个“漏洞”。虽然这个条件在 GPLv3 的正文中不存在，但是开发人员可以将 GPLv3 的代码与 Affero 代码相结合，而 Affero 条款将应用于整个产品。结论对于进行异构代码汇集和代码复用的应用程序开发团队来说，GPLv3 许可证的复杂性说明了对代码组件管理和监管的需求。由于有了这些对 GPL 最新的变更，应用程序开发人员、经理，及其法律顾问必须研究这些变更的含义，并且制定关于如何最佳地在他们的项目中包含基于 GPLv3 代码的决策。
