最近接觸到一些source code,走AGPL的規範,因此稍為上網蒐集了一下相關資訊,其內容以wiki與一些中文介紹為主,以快速了解。
首先一定得看wiki的說法: http://en.wikipedia.org/wiki/Affero_General_Public_License
The Affero General Public License, often abbreviated as Affero GPL andAGPL (and sometimes informally called the Affero License), refers to two distinct, though historically related,free software licenses:
AGPLv1, AGPLv3
Both versions of the AGPL were designed to close a perceived application service provider "loophole" (the "ASP loophole") in the ordinary GPL, where by using but not distributing the software, the copyleft provisions are not triggered. Each version differs from the version of the GNU GPL on which it is based in having an additional provision addressing use of software over a computer network. The additional provision requires that the complete source code be made available to any network user of the AGPL-licensed work, typically a Web application.
The Free Software Foundation has recommended that the GNU AGPLv3 be considered for any software that will commonly be run over a network.[2] The Open Source Initiative approved the GNU AGPLv3[3] as an open source license in March 2008 after Funambol submitted it for consideration.[4]
Compatibility with the GPL
Both versions of the AGPL, like the corresponding versions of the GNU GPL on which they are based, are strong copyleft licenses. In the FSF's judgment, the additional requirement in section 2(d) of AGPLv1 made it incompatible with the otherwise nearly identical GPLv2. That is to say, one cannot distribute a single work formed by combining components covered by each license.
By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each license) that together achieve a form of mutual compatibility for the two licenses. These clauses explicitly allow the "conveying" of a work formed by linking code licensed under the one license against code licensed under the other license,[7] despite the licenses otherwise not allowing relicensing under the terms of each other.[2] In this way, the copyleft of each license is relaxed to allow distribution of such combinations.[2]
To establish an upgrade path from AGPLv1 to the FSF's AGPLv3, Affero, Inc.published the Affero General Public License version 2, which is merely a transitional license that allows recipients of software licensed under "AGPLv1 or any later version as published by Affero, Inc." to distribute the software, or derivative works, under AGPLv3.
The Affero General Public License, often abbreviated as Affero GPL andAGPL (and sometimes informally called the Affero License), refers to two distinct, though historically related,free software licenses:
AGPLv1, AGPLv3
Both versions of the AGPL were designed to close a perceived application service provider "loophole" (the "ASP loophole") in the ordinary GPL, where by using but not distributing the software, the copyleft provisions are not triggered. Each version differs from the version of the GNU GPL on which it is based in having an additional provision addressing use of software over a computer network. The additional provision requires that the complete source code be made available to any network user of the AGPL-licensed work, typically a Web application.
The Free Software Foundation has recommended that the GNU AGPLv3 be considered for any software that will commonly be run over a network.[2] The Open Source Initiative approved the GNU AGPLv3[3] as an open source license in March 2008 after Funambol submitted it for consideration.[4]
Compatibility with the GPL
Both versions of the AGPL, like the corresponding versions of the GNU GPL on which they are based, are strong copyleft licenses. In the FSF's judgment, the additional requirement in section 2(d) of AGPLv1 made it incompatible with the otherwise nearly identical GPLv2. That is to say, one cannot distribute a single work formed by combining components covered by each license.
By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each license) that together achieve a form of mutual compatibility for the two licenses. These clauses explicitly allow the "conveying" of a work formed by linking code licensed under the one license against code licensed under the other license,[7] despite the licenses otherwise not allowing relicensing under the terms of each other.[2] In this way, the copyleft of each license is relaxed to allow distribution of such combinations.[2]
To establish an upgrade path from AGPLv1 to the FSF's AGPLv3, Affero, Inc.published the Affero General Public License version 2, which is merely a transitional license that allows recipients of software licensed under "AGPLv1 or any later version as published by Affero, Inc." to distribute the software, or derivative works, under AGPLv3.
不喜歡看英文的人,看些對岸的寫法吧
http://baike.baidu.com/view/2422767.htm
原有的GPL協議,由於現在網絡服務公司興起(如:google)產生了一定的漏洞,比如使用GPL的自由軟件,但是並不發布與網絡之中,則可以自由的使用GPL協議卻不開源自己私有的解決方案。AGPL則增加了對此做法的約束。
FROM : http://www.oschina.net/question/5189_4168 http://my.oschina.net/tonybear
GPL的約束生效的前提是“發布”軟件,即使用了GPL成分的軟件通過互聯網或光盤release軟件,就必需明示地附上源代碼,並且源代碼和產品也受GPL保護。
這樣如果不“發布”就可以不受約束了。比如使用GPL組件編寫一個Web系統,不發布這個系統,但是用這個系統在線提供服務,同時不開源系統代碼。
聯想到之前Google Code一直封殺AGPL,可能是這個原因吧。
http://linux.ubuntu.org.cn/news/31025.html
開源力量是國內知名的開源社區,提供以開源為主題的各種服務,如圈子,項目,創意,活動等應用。在2010 Apache Roadshow上海活動上,開源力量創始人Steven宣布,該網站源程序將在AGPL協議下發布,這個協議是一個比較嚴謹的許可方式,主要針對的是基於web的應用程序,要求網絡程序開發者必須讓源代碼能通過網絡分發。
http://baike.baidu.com/view/2422767.htm
原有的GPL協議,由於現在網絡服務公司興起(如:google)產生了一定的漏洞,比如使用GPL的自由軟件,但是並不發布與網絡之中,則可以自由的使用GPL協議卻不開源自己私有的解決方案。AGPL則增加了對此做法的約束。
FROM : http://www.oschina.net/question/5189_4168 http://my.oschina.net/tonybear
GPL的約束生效的前提是“發布”軟件,即使用了GPL成分的軟件通過互聯網或光盤release軟件,就必需明示地附上源代碼,並且源代碼和產品也受GPL保護。
這樣如果不“發布”就可以不受約束了。比如使用GPL組件編寫一個Web系統,不發布這個系統,但是用這個系統在線提供服務,同時不開源系統代碼。
聯想到之前Google Code一直封殺AGPL,可能是這個原因吧。
http://linux.ubuntu.org.cn/news/31025.html
開源力量是國內知名的開源社區,提供以開源為主題的各種服務,如圈子,項目,創意,活動等應用。在2010 Apache Roadshow上海活動上,開源力量創始人Steven宣布,該網站源程序將在AGPL協議下發布,這個協議是一個比較嚴謹的許可方式,主要針對的是基於web的應用程序,要求網絡程序開發者必須讓源代碼能通過網絡分發。
我想上面的敘述.....其詭異的中文,正常人應該是看不懂=.=?
可參考這篇,會又清楚些...
Google和AGPLv3之間的故事 http://civicrm.org.cn/node/48
一向致力與開放源碼社區建立良好關係的 Google,曾經因為 Google Code 服務不容許採用該服務的項目採用 Affero GPLv3 開放源碼授權,掀起一系列爭論,抨擊 Google 不願回饋開放源碼界的態度。
Google 與 Affero GPLv3 之間的這場爭論,起因自 Chris DiBona 在 Google Group 發表的討論串,要求採用 Affero GPL 的項目離開 Google Code。
一個普遍的看法認為,Google 很明顯地站在開放源碼這邊,只是因為開放源碼能帶給該公司好處,但 Google 的回饋卻相對地不足。這一派人士認定 Google Code 禁止服務的項目採用 Affero GPL 授權的政策,背離 Google 宣稱尊重且認同的開放源碼主張。
Chris DiBona 在文章中寫道,code.google.com 事實上不支援 AGPL,在 code.google.com 上成立 AGPL 項目,卻宣稱採用的是 GPL,同樣是不受允許。解決方法就是移除你的項目,將項目轉到其他地方。
DiBona 舉出的理由,包括 AGPL 並非 OSI 認可的授權以及 AGPL 使用不夠廣泛。僅管部份理由遭到社區人士反駁。
AGPL 或稱之為 Affero GPL 擴大了 GPL 對於散佈的定義。GPL 的條款只有散佈 GPL 授權的程式碼時,才會發揮效用。除非程式碼被散佈到組織外,否則 GPL 軟體的使用者或企業沒有義務揭露自己對 GPL 程式碼的修改。
AGPL 修正了這個漏洞,對於部份人士而言,足以讓他們眼中的搭開放源碼便車的各家公司,如 Google、Digg 等,再也無法使用開放源碼軟體而不須回饋。在此背景下,Google Code 拒絕讓 Google Code 上出現採用 AGPL 授權的項目,也就格外引人注意,並且難以使外界不多做聯想。Google 不願意 Google Code 容納 AGPL 授權項目,是因為一旦所有人在開放源碼上獲得同等立足點,Google 將會喪失優勢。
從協助創新的觀點看來,Google、Yahoo! 等公司積極回饋開放源碼社區,將為自身與整個產業帶來好處。由於 Google、Yahoo! 對 Linux、MySQL 所作的不公開修改,彼此間的差別或許不如廠商單方面想像的多。同樣的開放源碼項目,同時有相似的創新活動在進行。當這些公司能分享自身開發的部份,所有人都將脫離核心、基本的類似程式碼,進行更進一步的創新活動。
支持 Google 的一方以 Google 等公司透過提供支薪人力支援或財務支援等方式,對開放源碼項目做出回饋為例,宣稱許多重要的開放源碼項目事實上靠了企業支援,才得以擁有如今的規模。例如 IBM、惠普 (HP)、甲骨文 (Oracle)、紅帽 (Red Hat) 與 Novell 之於 Linux,Yahoo! 之於 PHP,Firefox 之於 Google 等。
此外,假如 Linux、PHP、Apache、HTTPD 與 MySQL 等一開始採用的是 AGPL,Google 等企業很有可能選擇付費取得無須回饋程式碼修改的權力。畢竟願意將重要差異化技術資產公諸在競爭者面前的企業並不多。更糟的情況下,Google 等公司也許不會成長到像今天這樣的規模。
基於 Google 等企業為 IT 使用者帶來的服務價值,社區部份人士認為,足以彌補廠商對開放源碼社區回饋不足之處。
單就授權本身看來,防止授權暴增帶來的溷亂情況是 Google 所提出的理由之一。Google 在 Google Code 上最初允許 7 種項目授權,加入 GPLv3 後增加到 8 種。Google 擔心開放源碼授權數量暴增後,開發者整合來自不同授權項目的元件時,法律權力將複雜不明。
人們猜測,Google 拒絕 AGPL,是因為 AGPL 有害 Google 核心競爭力?或者只是防止授權暴增問題的方法?由於 Google 同樣不允許項目採用 Eclipse Public License 等其他授權,防止授權暴增之說似有可信之處,但是當採用 AGPL 的項目漸增後,Google 於2010年最終將其代碼提供站點code.google.com納至FSF和OSI規範之下,這也意味著包括自由軟件協會(FSF)的存在爭議的AGPLv3(一個旨在保證代碼被回饋至開源社區的許可,主 要適用於Web服務如Google提供的一些)和Sun的CDDL(用於OpenSolaris和前Sun的許多Java項目中)。
Google Code將不會列出任何這些“少數”許可作為新項目的選擇,但他們至少會允許應用在代碼框 寫出它們所使用了的許可,大概會由Google人工核實。儘管公司仍然不鼓勵使用不在其“推薦”列表中的許可的使用,其限制許可的濫用這一點仍值得讚賞;現在的項目可以使用任何OSI推薦的開源許可,可以自己決定哪一項許可適合用在自 己的項目上。
Google原先被批評自定規則,並以其代碼服務站點為形式來反對開源運動中它不看好的那一部分。此次這一新的開放是 一個受歡迎的行動,更多地對準了廣大的開源與自由軟件運動,減小了與FSF和OSI不必要的摩擦。
可參考這篇,會又清楚些...
Google和AGPLv3之間的故事 http://civicrm.org.cn/node/48
一向致力與開放源碼社區建立良好關係的 Google,曾經因為 Google Code 服務不容許採用該服務的項目採用 Affero GPLv3 開放源碼授權,掀起一系列爭論,抨擊 Google 不願回饋開放源碼界的態度。
Google 與 Affero GPLv3 之間的這場爭論,起因自 Chris DiBona 在 Google Group 發表的討論串,要求採用 Affero GPL 的項目離開 Google Code。
一個普遍的看法認為,Google 很明顯地站在開放源碼這邊,只是因為開放源碼能帶給該公司好處,但 Google 的回饋卻相對地不足。這一派人士認定 Google Code 禁止服務的項目採用 Affero GPL 授權的政策,背離 Google 宣稱尊重且認同的開放源碼主張。
Chris DiBona 在文章中寫道,code.google.com 事實上不支援 AGPL,在 code.google.com 上成立 AGPL 項目,卻宣稱採用的是 GPL,同樣是不受允許。解決方法就是移除你的項目,將項目轉到其他地方。
DiBona 舉出的理由,包括 AGPL 並非 OSI 認可的授權以及 AGPL 使用不夠廣泛。僅管部份理由遭到社區人士反駁。
AGPL 或稱之為 Affero GPL 擴大了 GPL 對於散佈的定義。GPL 的條款只有散佈 GPL 授權的程式碼時,才會發揮效用。除非程式碼被散佈到組織外,否則 GPL 軟體的使用者或企業沒有義務揭露自己對 GPL 程式碼的修改。
AGPL 修正了這個漏洞,對於部份人士而言,足以讓他們眼中的搭開放源碼便車的各家公司,如 Google、Digg 等,再也無法使用開放源碼軟體而不須回饋。在此背景下,Google Code 拒絕讓 Google Code 上出現採用 AGPL 授權的項目,也就格外引人注意,並且難以使外界不多做聯想。Google 不願意 Google Code 容納 AGPL 授權項目,是因為一旦所有人在開放源碼上獲得同等立足點,Google 將會喪失優勢。
從協助創新的觀點看來,Google、Yahoo! 等公司積極回饋開放源碼社區,將為自身與整個產業帶來好處。由於 Google、Yahoo! 對 Linux、MySQL 所作的不公開修改,彼此間的差別或許不如廠商單方面想像的多。同樣的開放源碼項目,同時有相似的創新活動在進行。當這些公司能分享自身開發的部份,所有人都將脫離核心、基本的類似程式碼,進行更進一步的創新活動。
支持 Google 的一方以 Google 等公司透過提供支薪人力支援或財務支援等方式,對開放源碼項目做出回饋為例,宣稱許多重要的開放源碼項目事實上靠了企業支援,才得以擁有如今的規模。例如 IBM、惠普 (HP)、甲骨文 (Oracle)、紅帽 (Red Hat) 與 Novell 之於 Linux,Yahoo! 之於 PHP,Firefox 之於 Google 等。
此外,假如 Linux、PHP、Apache、HTTPD 與 MySQL 等一開始採用的是 AGPL,Google 等企業很有可能選擇付費取得無須回饋程式碼修改的權力。畢竟願意將重要差異化技術資產公諸在競爭者面前的企業並不多。更糟的情況下,Google 等公司也許不會成長到像今天這樣的規模。
基於 Google 等企業為 IT 使用者帶來的服務價值,社區部份人士認為,足以彌補廠商對開放源碼社區回饋不足之處。
單就授權本身看來,防止授權暴增帶來的溷亂情況是 Google 所提出的理由之一。Google 在 Google Code 上最初允許 7 種項目授權,加入 GPLv3 後增加到 8 種。Google 擔心開放源碼授權數量暴增後,開發者整合來自不同授權項目的元件時,法律權力將複雜不明。
人們猜測,Google 拒絕 AGPL,是因為 AGPL 有害 Google 核心競爭力?或者只是防止授權暴增問題的方法?由於 Google 同樣不允許項目採用 Eclipse Public License 等其他授權,防止授權暴增之說似有可信之處,但是當採用 AGPL 的項目漸增後,Google 於2010年最終將其代碼提供站點code.google.com納至FSF和OSI規範之下,這也意味著包括自由軟件協會(FSF)的存在爭議的AGPLv3(一個旨在保證代碼被回饋至開源社區的許可,主 要適用於Web服務如Google提供的一些)和Sun的CDDL(用於OpenSolaris和前Sun的許多Java項目中)。
Google Code將不會列出任何這些“少數”許可作為新項目的選擇,但他們至少會允許應用在代碼框 寫出它們所使用了的許可,大概會由Google人工核實。儘管公司仍然不鼓勵使用不在其“推薦”列表中的許可的使用,其限制許可的濫用這一點仍值得讚賞;現在的項目可以使用任何OSI推薦的開源許可,可以自己決定哪一項許可適合用在自 己的項目上。
Google原先被批評自定規則,並以其代碼服務站點為形式來反對開源運動中它不看好的那一部分。此次這一新的開放是 一個受歡迎的行動,更多地對準了廣大的開源與自由軟件運動,減小了與FSF和OSI不必要的摩擦。
對各種規範 ex. GPL, MIT License, LGPL,...等都不熟悉的人,可以看這篇:
http://blog.csdn.net/terrycanny/article/details/8621095
GPL 協議:即通用性公開許可證(General Public License,簡稱GPL)。
GPL同其它的自由軟件許可證一樣,許可社會公眾享有:運行、複製軟件的自由,發行傳播軟件的自由,獲得軟件源碼的自由,改進軟件並將自己作出的改進版本向社會發行傳播的自由。
GPL還規定:只要這種修改文本在整體上或者其某個部分來源於遵循GPL的程序,該修改文本的 整體就必須按照GPL流通,不僅該修改文本的源碼必須向社會公開,而且對於這種修改文本的流通不准許附加修改者自己作出的限制。因此,一項遵循GPL流通 的程序不能同非自由的軟件合併。GPL所表達的這種流通規則稱為copyleft,表示與copyright(版權)的概念“相左”。
GPL協議最主要的幾個原則:
1、確保軟件自始至終都以開放源代碼形式發布,保護開發成果不被竊取用作商業發售。任何一套軟 件,只要其中使用了受 GPL 協議保護的第三方軟件的源程序,並向非開發人員發布時,軟件本身也就自動成為受 GPL 保護並且約束的實體。也就是說,此時它必須開放源代碼。
2、GPL 大致就是一個左側版權(Copyleft,或譯為“反版權”、“版權屬左”、“版權所無”、“版責”等)的體現。你可以去掉所有原作的版權 信息,只要你保持開源,並且隨源代碼、二進製版附上 GPL 的許可證就行,讓後人可以很明確地得知此軟件的授權信息。GPL 精髓就是,只要使軟件在完整開源 的情況下,盡可能使使用者得到自由發揮的空間,使軟件得到更快更好的發展。
3、無論軟件以何種形式發布,都必須同時附上源代碼。例如在 Web 上提供下載,就必須在二進製版本(如果有的話)下載的同一個頁面,清楚地提供源代碼下載的鏈接。如果以光盤形式發布,就必須同時附上源文件的光盤。
4、開發或維護遵循 GPL 協議開發的軟件的公司或個人,可以對使用者收取一定的服務費用。但還是一句老話——必須無償提供軟件的完整源代碼,不得將源代碼與服務做捆綁或任何變相捆綁銷售。
GPL詳細信息
AGPL 協議:原有的GPL協議,由於現在網絡服務公司興起(如:google)產生了一定的漏洞,比如使用GPL的自由軟件,但是並不發布與網絡之中,則可以自由的使 用GPL協議確不開源自己私有的解決方案。AGPL則增加了對此做法的約束。
GPL的約束生效的前提是“發布”軟件,即使用了GPL成分的軟件通過互聯網或光盤release軟件,就必需明示地附上源代碼,並且源代碼和產品也受GPL保護。
這樣如果不“發布”就可以不受約束了。比如使用GPL組件編寫一個Web系統,不發布這個系統,但是用這個系統在線提供服務,同時不開源系統代碼。
AGPL詳細信息
LGPL 協議:寬鬆公共許可證(Lesser General Public License)或庫通用公共許可證(Library General Public License)
基於 LGPL 的軟件也允許商業化銷售,但不允許封閉源代碼。
如果您對遵循 LGPL 的軟件進行任何改動和/或再次開發並予以發布,則您的產品必須繼承 LGPL 協議,不允許封閉源代碼。但是如果您的程序對遵循 LGPL 的軟件進行任何連接、調用而不是包含,則允許封閉源代碼。
LGPL詳細信息
Apache 協議:Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發布(作為開源或商業軟件)。需要滿足的條件也和BSD類似:
需要給代碼的用戶一份Apache Licence
如果你修改了代碼,需要在被修改的文件中說明。
在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。
如果再發布的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。
http://en.wikipedia.org/wiki/Apache_License
Zlib/Libpng協議:The license only has the following points to be accounted for:
Software is used on 'as-is' basis. Authors are not liable for any damages arising from its use.
The distribution of a modified version of the software is subject to the following restrictions:
1.The authorship of the original software must not be misrepresented,
2.Altered source versions must not be misrepresented as being the original software, and
3.The license notice must not be removed from source distributions.
The license does not require source code to be made available if distributing binary code.
中文參考如下(個人理解)
該協議要求遵守以下幾點:
基於該軟件的原樣使用,作者不負責使用該軟件照成的任何損失。
該軟件修改後的版本將受到以下限制:
不能歪曲原軟件的著作權
修改後的軟件不能歪曲為原版軟件
不能刪除源碼中的協議許可內容
如果發布二進制代碼可以不用附上源代碼。
http://en.wikipedia.org/wiki/Zlib_License
BSD 協議:BSD開源協議是一個給於使用者很大自由的協議。可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟件再發布。當你發布使用了BSD協議的代碼,或者以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
如果再發布的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。
如果再發布的只是二進制類庫/軟件,則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟件發布和銷 售,因此是對商業集成很友好的協議。很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者 二次開發。
http://zh.wikipedia.org/wiki/BSD%E8%AE%B8%E5%8F%AF%E8%AF%81
MIT 協議:MIT許可證之名源自麻省理工學院(Massachusetts Institute of Technology, MIT),又稱「X條款」(X License)或「X11條款」(X11 License),MIT內容與三條款BSD許可證(3-clause BSD license)內容頗為近似,但是賦予軟體被授權人更大的權利與更少的限制。
被授權人有權利使用、複製、修改、合併、出版發行、散布、再授權及販售軟體及軟體的副本。
被授權人可根據程式的需要修改授權條款為適當的內容。
在軟件和軟件的所有副本中都必須包含版權聲明和許可聲明。
此授權條款並非屬copyleft的自由軟體授權條款,允許在自由/開放源碼軟體或非自由軟體(proprietary software)所使用。此亦為MIT與BSD(The BSD license, 3-clause BSD license)本質上不同處。MIT條款可與其他授權條款並存。另外,MIT條款也是自由軟體基金會(FSF)所認可的自由軟體授權條款,與GPL相容。
http://en.wikipedia.org/wiki/MIT_License
http://blog.csdn.net/terrycanny/article/details/8621095
GPL 協議:即通用性公開許可證(General Public License,簡稱GPL)。
GPL同其它的自由軟件許可證一樣,許可社會公眾享有:運行、複製軟件的自由,發行傳播軟件的自由,獲得軟件源碼的自由,改進軟件並將自己作出的改進版本向社會發行傳播的自由。
GPL還規定:只要這種修改文本在整體上或者其某個部分來源於遵循GPL的程序,該修改文本的 整體就必須按照GPL流通,不僅該修改文本的源碼必須向社會公開,而且對於這種修改文本的流通不准許附加修改者自己作出的限制。因此,一項遵循GPL流通 的程序不能同非自由的軟件合併。GPL所表達的這種流通規則稱為copyleft,表示與copyright(版權)的概念“相左”。
GPL協議最主要的幾個原則:
1、確保軟件自始至終都以開放源代碼形式發布,保護開發成果不被竊取用作商業發售。任何一套軟 件,只要其中使用了受 GPL 協議保護的第三方軟件的源程序,並向非開發人員發布時,軟件本身也就自動成為受 GPL 保護並且約束的實體。也就是說,此時它必須開放源代碼。
2、GPL 大致就是一個左側版權(Copyleft,或譯為“反版權”、“版權屬左”、“版權所無”、“版責”等)的體現。你可以去掉所有原作的版權 信息,只要你保持開源,並且隨源代碼、二進製版附上 GPL 的許可證就行,讓後人可以很明確地得知此軟件的授權信息。GPL 精髓就是,只要使軟件在完整開源 的情況下,盡可能使使用者得到自由發揮的空間,使軟件得到更快更好的發展。
3、無論軟件以何種形式發布,都必須同時附上源代碼。例如在 Web 上提供下載,就必須在二進製版本(如果有的話)下載的同一個頁面,清楚地提供源代碼下載的鏈接。如果以光盤形式發布,就必須同時附上源文件的光盤。
4、開發或維護遵循 GPL 協議開發的軟件的公司或個人,可以對使用者收取一定的服務費用。但還是一句老話——必須無償提供軟件的完整源代碼,不得將源代碼與服務做捆綁或任何變相捆綁銷售。
GPL詳細信息
AGPL 協議:原有的GPL協議,由於現在網絡服務公司興起(如:google)產生了一定的漏洞,比如使用GPL的自由軟件,但是並不發布與網絡之中,則可以自由的使 用GPL協議確不開源自己私有的解決方案。AGPL則增加了對此做法的約束。
GPL的約束生效的前提是“發布”軟件,即使用了GPL成分的軟件通過互聯網或光盤release軟件,就必需明示地附上源代碼,並且源代碼和產品也受GPL保護。
這樣如果不“發布”就可以不受約束了。比如使用GPL組件編寫一個Web系統,不發布這個系統,但是用這個系統在線提供服務,同時不開源系統代碼。
AGPL詳細信息
LGPL 協議:寬鬆公共許可證(Lesser General Public License)或庫通用公共許可證(Library General Public License)
基於 LGPL 的軟件也允許商業化銷售,但不允許封閉源代碼。
如果您對遵循 LGPL 的軟件進行任何改動和/或再次開發並予以發布,則您的產品必須繼承 LGPL 協議,不允許封閉源代碼。但是如果您的程序對遵循 LGPL 的軟件進行任何連接、調用而不是包含,則允許封閉源代碼。
LGPL詳細信息
Apache 協議:Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發布(作為開源或商業軟件)。需要滿足的條件也和BSD類似:
需要給代碼的用戶一份Apache Licence
如果你修改了代碼,需要在被修改的文件中說明。
在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。
如果再發布的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。
http://en.wikipedia.org/wiki/Apache_License
Zlib/Libpng協議:The license only has the following points to be accounted for:
Software is used on 'as-is' basis. Authors are not liable for any damages arising from its use.
The distribution of a modified version of the software is subject to the following restrictions:
1.The authorship of the original software must not be misrepresented,
2.Altered source versions must not be misrepresented as being the original software, and
3.The license notice must not be removed from source distributions.
The license does not require source code to be made available if distributing binary code.
中文參考如下(個人理解)
該協議要求遵守以下幾點:
基於該軟件的原樣使用,作者不負責使用該軟件照成的任何損失。
該軟件修改後的版本將受到以下限制:
不能歪曲原軟件的著作權
修改後的軟件不能歪曲為原版軟件
不能刪除源碼中的協議許可內容
如果發布二進制代碼可以不用附上源代碼。
http://en.wikipedia.org/wiki/Zlib_License
BSD 協議:BSD開源協議是一個給於使用者很大自由的協議。可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟件再發布。當你發布使用了BSD協議的代碼,或者以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
如果再發布的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。
如果再發布的只是二進制類庫/軟件,則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟件發布和銷 售,因此是對商業集成很友好的協議。很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者 二次開發。
http://zh.wikipedia.org/wiki/BSD%E8%AE%B8%E5%8F%AF%E8%AF%81
MIT 協議:MIT許可證之名源自麻省理工學院(Massachusetts Institute of Technology, MIT),又稱「X條款」(X License)或「X11條款」(X11 License),MIT內容與三條款BSD許可證(3-clause BSD license)內容頗為近似,但是賦予軟體被授權人更大的權利與更少的限制。
被授權人有權利使用、複製、修改、合併、出版發行、散布、再授權及販售軟體及軟體的副本。
被授權人可根據程式的需要修改授權條款為適當的內容。
在軟件和軟件的所有副本中都必須包含版權聲明和許可聲明。
此授權條款並非屬copyleft的自由軟體授權條款,允許在自由/開放源碼軟體或非自由軟體(proprietary software)所使用。此亦為MIT與BSD(The BSD license, 3-clause BSD license)本質上不同處。MIT條款可與其他授權條款並存。另外,MIT條款也是自由軟體基金會(FSF)所認可的自由軟體授權條款,與GPL相容。
http://en.wikipedia.org/wiki/MIT_License
Comparison of Open Source Licenses March 21, 2012 by e1ven
其實最完整的一篇我覺得得看這篇:
http://e1ven.com/2012/03/21/comparison-of-open-source-licenses/
這篇裡面有兩張表格,清楚的表示出 任兩種規範之間的關係,非常值得參考。 (也因為有表格,我貼過來會亂掉,因此不貼了...)
這篇是對岸朋友的翻譯: http://my.oschina.net/2011xuesong/blog/51743 不習慣看英文的人也可以酌量參考。
http://e1ven.com/2012/03/21/comparison-of-open-source-licenses/
這篇裡面有兩張表格,清楚的表示出 任兩種規範之間的關係,非常值得參考。 (也因為有表格,我貼過來會亂掉,因此不貼了...)
這篇是對岸朋友的翻譯: http://my.oschina.net/2011xuesong/blog/51743 不習慣看英文的人也可以酌量參考。