由gpl软件自动生成的代码

1. 关于开源GPL协议。

加广告不违背GPL协议。
GPL描述的是源代码相关的限制，你要做的就是确保源代码是放在GPL下的（不是光开源就可以了）。一般的做法是在每个源代码文件开始位置添加一段声明（头文件和源代码相关脚本一般不用，详细要求见GPL协议末尾），并且在源代码根目录放上一份完整的GPL协议文本（这个完整的协议文本是不是必须的，不清楚，对文件名有没有要求，不清楚）。特别注意（容易被忽略）：部分GPL软件要求在引用代码时注明代码来源，如果引用了一个软件组件的大部分（看重要性，不是看文件大小）内容，可能还有要求，不得在未经同意的情况下修改其名称、作者等信息（不能拿别人的软件，稍作修改，然后声称这是自己写的，这对具有某个完整功能的程序片段同样适用）。原作者可能还有其他要求，一定要重视（一般在该软件的代码根目录或文件起始位置就能找到这些条款）。

细节说完了，下面有一点不容易忘记，但不得不提：只要自己的软件不对外发布，可以不管GPL，不过对外发布时，一定要保证别人可以随时免费得到源代码（“我的软件放到GPL下了，要源代码的来我家拿，路费1000元自己解决”不知道可不可以）。

GPL协议并不是太长，一个小时内完全可以看完，还是花时间弄清楚吧，最好是看GPL原文（翻译的可能会偏离原意）。许可协议是软件开发的一个重要内容，不是搭头，需要重视。

如果违背了这个协议，并且被“有关部门”发现了（没发现自然没人找你），一般会给你来一份警告，你只要立即停止自己的项目（停止提供软件发布和相关支持）或将项目放到GPL下面就可以了（自己的名声有损是没法避免了），不需要负法律责任（如果警告时就要求作出一些表示，那就要看你自己愿意公了还是私了）。如果在警告后，没有及时作出上面的回应，那你将会受到的处罚可能就要看法官的意思了。

补充：修改代码中的函数名，类名甚至它们的具体实现都可以。

2. 如果我接受了Qt的LGPL或者GPL协议自己开发了一个程序，那么这个程序的源代码会被公布吗

前提是这个程序的源代码值得被公布, 一般这些协议都是对大公司才有比较大约束力, 个人或者小公司的话一般还没有到那种程度

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 代码的决策。

4. 引用了基于GPLv3的类库开发出来的软件，可以使用Apache2.0协议吗

您好，Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。

5. GNU GPL的代码可以直接商用吗

GNU是 Richard Stallman 于 1975 年，在 MIT 所成立的 Free Software Foundation (FSF）中所执行的一项计划
。它的目标是创建一套
完全自由的操作系统.
GNU计划下的软体，不只提供软体的使用权，也提供软体的原始程式，任何人都可以
根据需要来修改
程式，也可以尽己之力来找出程式的错误，使隶属于GNU的软体在大家的努力下能尽善尽美。
GNU计划下的软体，是可不需付费而享有使用权。
GNU对使用者唯一的要求就是，当使用者对于GNU计划下的软体做了进一步的修改时，仍必须维持GNU的精神， 就是对于修改过的软体仍然必须
将其无条件的奉献出来
，任何人都不可将修改过的GNU软体当成商品来买卖。GNU是GNU's Not Unix的递归缩写。Stallman宣布GNU应当发音为Guh-NOO，与canoe发音相同，以避免与gnu（非洲牛羚，发音与new相同）这个单词混淆。
通用性公开许可证
(General Public License，简称GPL
)。
为保证GNU软件可以自由地使用、复制、修改和发布，所有GNU软件都在一份在
禁止其他人添加任何限制
的情况下授权所有权利给任何人的协议条款，GNU通用公共许可证（GNU General Public License，GPL）。这个就是被称为反版权（或称Copyleft）的概念。
GPL同其它的自由软件许可证一样，
许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。
GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通的程序不能同非自由的软件合并。
GPL 是 GNU General Public License (GNU 通用公共许可证)的缩写形式；LGPL 是 GNU Lesser General Public License (GNU 宽通用公共许可证)的缩写形式，旧称 GNU Library General Public License (GNU 库通用公共许可证)；GFDL 是 GNU Free Documentation License (GNU 自由文档许可证)的缩写形式。它们是自由软件(Free Software)的
通用版权认证协议
，由自由软件基金会(FSF)制定和发布。
基于 GPL 的软件允许商业化销售，但不允许封闭源代码。
如果您对遵循 GPL 的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承 GPL 协议，不允许封闭源代码。
基于 LGPL 的软件也允许商业化销售，但不允许封闭源代码。
如果您对遵循 LGPL 的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承 LGPL 协议，不允许封闭源代码。

6. gpl在哪里看

gpl在源代码相关看。

一般的做法是在每个源代码文件开始位置添加一段声明（头文件和源代码相关脚本一般不用，详细要求见GPL协议末尾），并且在源代码根目录放上一份完整的GPL协议文本。

部分GPL软件要求在引用代码时注明代码来源，如果引用了一个软件组件的大部分（看重要性，不是看文件大小）内容，可能还有要求。

源代码主要功用有如下2种作用：

生成目标代码，即计算机可以识别的代码。

对软件进行说明，即对软件的编写进行说明。为数不少的初学者，甚至少数有经验的程序员都忽视软件说明的编写，因为这部分虽然不会在生成的程序中直接显示，也不参与编译。但是说明对软件的学习、分享、维护和软件复用都有巨大的好处。

需要指出的是，源代码的修改不能改变已经生成的目标代码。如果需要目标代码做出相应的修改，必须重新编译。

7. GNU和GPL是什么

简介：GNU GPL（GNU General Public License，通用公共许可证）是一个广泛被使用的自由软件许可证，最初由理乍得·斯托曼为GNU计划而撰写。到目前为止，GPL先后发布了有3个版本。

版本：GPLv1 GPLv1是最初的版本，发布于1989年1月，其目的是防止那些阻碍自由软件的行为，而这些阻碍软件开源的行为主要有两种（一种是软件发布者只发布可执行的二进制代码而不发布具有源代码，一种是软件发布者在软件许可加入限制性条款）。因此GPLv1规定，如果发布了可执行的二进制代码，就必须同时发布可读的源代码，并且在发布任何基于GPL许可的软件时，不能添加任何限制性的条款。
GPLv2 在GPLv2中所做的最大的改动就是增加了“自由还是死亡”（Liberty or Death）的条款。该条款规定，如果发布源于GPL的软件时，只能以二进制代码的形式发布软件，那么他将根本无权发布该软件。
GPLv3 发布于2007年6月29日。在所进行的修改中最重要的有四个：解决软件专利问题；与其他许可证的兼容性；源代码分割和组成的定义；解决数字版权管理 (DRM) 问题。

概念：
在GPL中有一个关键的概念就是Copyleft。GPL规定，再发行权的授予需要许可证接受人公开软件的源代码及所有修改，而且复制件、修改版本都必须以GPL为许可证。这些要求就是Copyleft，它的基础就是作品在法律上版权所有。
由于版权所有，一般情况下，许可证接受人无权对作品进行修改和再发行（除合理使用），除非它有一个 Copyleft条款。Copyleft利用版权法来达到与其相反的目的： Copyleft给人不可剥夺的权利，而不是版权法所规定的诸多限制。这也是GPL被称作“被黑的版权法”的原因。
Copyleft只在程序再发行时发生效力。对软件的修改可以不公开或开放源代码，只要不发行。注意left只对软件有效力，而对软件的输出并无效力（除非输出的是软件本身）。

8. linux下开发的软件用到GPL协议的源代码或者库就必须开放源代码吗

用源代码肯定要GPL的。
用库的一般要GPL。
LGPL的可以用库不用LGPL。