由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。