㈠ 開源協議的協議比較
BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以」為所欲為」,可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟體再發布。
但」為所欲為」的前提當你發布使用了BSD協議的代碼,或則以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
◆如果再發布的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。
◆如果再發布的只是二進制類庫/軟體,則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。
◆不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD 代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟體發布和銷售,因此是對 商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。 Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發布(作為開源或商業軟體)。需要滿足的條件也和BSD類似:
◆需要給代碼的用戶一份Apache Licence
◆如果你修改了代碼,需要在被修改的文件中說明。
◆在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。
◆如果再發布的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。 我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代 碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商 業軟體公司開發的免費軟體了。
GPL協議的主要內容是只要在一個軟體中使用(」使用」指類庫引用,修改後的代碼或者衍生代碼)GPL 協議的產品,則該軟體產品必須也採用GPL協議,既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題, 還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議,對於使用GPL協議的開源代碼,商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。 LGPL 是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協議不同。LGPL 允許商業軟體通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的代碼。這使得採用LGPL協議的開源代碼可以被商業軟體作為類庫引用並 發布和銷售。
但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因 此LGPL協議的開源 代碼很適合作為第三方類庫被商業軟體引用,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟體採用。
GPL/LGPL都保障原作者的知識產權,避免有人利用開源代碼復制並開發類似的產品。 MIT是和BSD一樣寬范的許可協議,作者只想保留版權,而無任何其它的限制。也就是說,你必須在你的發行版里包含原許可協議的聲明,無論你是以二進制發布的還是以源代碼發布的。MIT協議又稱麻省理工學院許可證,最初由麻省理工學院開發。被授權人權利:1、被授權人有權利使用、復制、修改、合並、出版發行、散布、再授權及販售軟體及軟體的副本。2、被授權人可根據程式的需要修改授權條款為適當的內容。被授權人義務:在軟體和軟體的所有副本中都必須包含版權聲明和許可聲明。

㈡ 開源許可證都有什麼區別,一般開源項目用什麼許可證
開源許可證是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。
㈢ 關於開源軟體許可GPL(GNU通用公共許可證)的問題
「為了保護你的權利,我們需要作出規定:禁止任何人不承認你的權利,或者要求專你放棄這些權利。如屬果你修改了自由軟體或者發布了軟體的副本,這些規定就轉化為你的責任。
例如,如果你發布這樣一個程序的副本,不管是收費的還是免費的,你必須將你具有的一切權利給予你的接受者;你必須保證他們能收到或得到源程序;並且將這些條款給他們看,使他們知道他們有這樣的權利。」
來源:網路
㈣ 什麼是開源,為什麼linux是開源,windows不是
問題很搞笑。。。
使用Linux必須手動輸入命令是一個偏見。本人長年累月地使用Linux,但是我並不熟悉Linux的命令。
Linux一般都部署在伺服器上,為了讓伺服器更穩定,在伺服器上安裝Linux時常常不安裝圖形環境。這也是讓人產生「做什麼事情都需要手動輸入命令」的錯覺。
實際上,我對開源的概念也不是十分理解。簡單地說,允許查看、修改源代碼的軟體就屬於開源軟體。而像Win和MacOsX這樣的系統,源代碼都是保密的,他們都是閉源軟體。
按照開源許可協議,所有的Linux發行版都必須公開源代碼。不過因為源代碼很佔用空間,源代碼一般不會直接附在發行版的光碟中,需要您自己下載。
DOS系統是由匯編語言編寫的,其餘的能叫上名字的操作系統,比如Linux、DBS、Win之類的,一般都是由C語言編寫的。
因為Win是閉源軟體,因此您看不到它的源代碼,修改起來也比較難。要想修改Win,首先您要熟悉軟體的反匯編技術,其次您要做好保密工作,不要讓人發現,被發現了是要坐牢的。
順便說一句:WinCE是開源的。
修改Linux的源代碼就比較自由了。
不知到您的編程水平如何,我稍微提醒您一下,自2.6.27開始,Linux內核的代碼就超過1000萬行了,雖然大部分的代碼都是些驅動程序。
在閱讀源代碼前,最好先找本介紹Linux內核原理的書。
㈤ 開源協議GPL和LGPL最大的區別是什麼
簡單的說,GPL協議的話,你寫的代碼必須全部開源,
LGPL則不需要
㈥ 怎樣將自己開發的軟體發布成支持GPL協議的開源軟體
2進制文件可以不用,但源碼是一定要。另外如果你的代碼用了別人的源代碼,而這份開源代碼使用的協議與gpl沖突的話,就不能用GPL發布了
㈦ 開源許可證GPL,BSD,MIT,Mozilla,Apache和LGPL的區別
因CooCox用戶數及影響力越來越大,CooCox團隊也逐漸提高了對軟體及代碼協議的重視。在收集整理的過程中,一些歸納好的信息和大家分享一下。
首先借用有心人士的一張相當直觀清晰的圖來劃分各種協議:開源許可證GPL、BSD、MIT、Mozilla、Apache和LGPL的區別
license.jpeg
以下是上述協議的簡單介紹:
BSD開源協議
BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以」為所欲為」,可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟體再發布。
但」為所欲為」的前提當你發布使用了BSD協議的代碼,或則以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
如果再發布的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。
如果再發布的只是二進制類庫/軟體,則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。
不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD 代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟體發布和銷售,因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。
Apache Licence 2.0
Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發布(作為開源或商業軟體)。需要滿足的條件也和BSD類似:
需要給代碼的用戶一份Apache Licence
如果你修改了代碼,需要再被修改的文件中說明。
在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。
如果再發布的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。
GPL
我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商業軟體公司開發的免費軟體了。
GPL協議的主要內容是只要在一個軟體中使用(」使用」指類庫引用,修改後的代碼或者衍生代碼)GPL 協議的產品,則該軟體產品必須也採用GPL協議,既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題,還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議,對於使用GPL協議的開源代碼,商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。
LGPL
LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協議不同。LGPL 允許商業軟體通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的代碼。這使得採用LGPL協議的開源代碼可以被商業軟體作為類庫引用並發布和銷售。
但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源代碼很適合作為第三方類庫被商業軟體引用,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟體採用。
GPL/LGPL都保障原作者的知識產權,避免有人利用開源代碼復制並開發類似的產品
MIT
MIT是和BSD一樣寬范的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版里包含原許可協議的聲明,無論你是以二進制發布的還是以源代碼發布的.
MPL
MPL是The Mozilla Public License的簡寫,是1998年初Netscape的 Mozilla小組為其開源軟體項目設計的軟體許可證。MPL許可證出現的最重要原因就是,Netscape公司認為GPL許可證沒有很好地平衡開發者對源代碼的需求和他們利用源代碼獲得的利益。同著名的GPL許可證和BSD許可證相比,MPL在許多權利與義務的約定方面與它們相同(因為都是符合OSIA 認定的開源軟體許可證)。但是,相比而言MPL還有以下幾個顯著的不同之處:
◆ MPL雖然要求對於經MPL許可證發布的源代碼的修改也要以MPL許可證的方式再許可出來,以保證其他人可以在MPL的條款下共享源代碼。但是,在MPL 許可證中對「發布」的定義是「以源代碼方式發布的文件」,這就意味著MPL允許一個企業在自己已有的源代碼庫上加一個介面,除了介面程序的源代碼以MPL 許可證的形式對外許可外,源代碼庫中的源代碼就可以不用MPL許可證的方式強制對外許可。這些,就為借鑒別人的源代碼用做自己商業軟體開發的行為留了一個豁口。
◆ MPL許可證第三條第7款中允許被許可人將經過MPL許可證獲得的源代碼同自己其他類型的代碼混合得到自己的軟體程序。
◆ 對軟體專利的態度,MPL許可證不像GPL許可證那樣明確表示反對軟體專利,但是卻明確要求源代碼的提供者不能提供已經受專利保護的源代碼(除非他本人是專利權人,並書面向公眾免費許可這些源代碼),也不能在將這些源代碼以開放源代碼許可證形式許可後再去申請與這些源代碼有關的專利。
◆ 對源代碼的定義
而在MPL(1.1版本)許可證中,對源代碼的定義是:「源代碼指的是對作品進行修改最優先擇取的形式,它包括:所有模塊的所有源程序,加上有關的介面的定義,加上控制可執行作品的安裝和編譯的『原本』(原文為『Script』),或者不是與初始源代碼顯著不同的源代碼就是被源代碼貢獻者選擇的從公共領域可以得到的程序代碼。」
◆ MPL許可證第3條有專門的一款是關於對源代碼修改進行描述的規定,就是要求所有再發布者都得有一個專門的文件就對源代碼程序修改的時間和修改的方式有描述。
㈧ 開源軟體、GNU計劃、GPL協議各是什麼三者之間的關系是怎麼樣的
大多數軟體許可證決意剝奪你的共享和修改軟體的自由。對比之專下,GNU通用公共許可證力圖保證屬你的共享和修改自由軟體的自由。——保證自由軟體對所有用戶是自由的。GPL適用於大多數自由軟體基金會的軟體,以及由使用這些軟體而承擔義務的作者所開發的軟體。當然了,大多開源軟體都是基於開源系統上來實現的。著名的開源系統linux,開源軟體apache。
㈨ 開源的許可證
開放源代碼定義給出了開放源代碼軟體的基本性質。不幸的是,術語開放源代碼遭到了濫用,並且由於它的描述性,它不能作為一個商標(這是我們的首選)被保護。由於社團需要一種可靠的方式以確定一份軟體是否真正是開放源代碼軟體。OSI為此目的而注冊了一個認證標志,OSI Certified。如果在一份軟體上看到了該標志,那麼該軟體就是必定是按照遵從開放源代碼定義的許可證發布的,否則,該發行人就是在濫用該標志而且違反了法律。
許可證將特定的權利賦予用戶,但同時也會規定用戶必須遵守的約束。開源軟體通常使用開源許可證。所有的開源許可證由開放源代碼促進會標准組織(Opensource Initiative,OSI)認證。
獲得批準的許可證
以下許可證滿足開放源代碼的定義,並且已經被批准用於OSI Certified的開放源代碼軟體。沒有給出批准日期的許可證是在1999年1月1日以前批準的。
* The GNU General Public License(GPL)
* The GNU Library(Lesser)General Public License(LGPL)
* The X Consortium License
* The Artistic License
* The Mozilla Public License(MPL)
* TheQPL
* OpenLDAPPublic License
其它符合定義的許可證包括:libpng許可證、zlib許可證、IJG JPEG許可證和BSD許可證。 按照使用條件的不同,開源軟體許可證可以分為三類(嚴苛程度遞減)
1. 使用該開源軟體的代碼再散布(redistribute)時,源碼也必須以相同許可證公開。
代表許可類型:GPL,AGPL
例:GPL
GNU 通用公共許可協議(英語:GNU General Public License,簡稱GNU GPL或GPL),是一個廣泛被使用的自由軟體許可證條款,最初由理查德·斯托曼為GNU計劃而撰寫。GPL是自由軟體基金會的主打許可證,常用的是1991年的第2版和2007年的第3版。
GPL授予程序接受人以下權利: 以任何目的運行此程序的自由; 再發行復製件的自由; 改進此程序,並公開發布改進的自由(前提是能得到源代碼)。 GPL許可協議具有強Copyleft,有「病毒效應」,意味著用戶如果要對GPL許可的軟體或基於GPL許可的軟體的作品做再發行即Redistribution(例如作為用戶的產品的一部分發行),那麼必須以不強於GPL許可證限制的條款發行,即必須也是開源和免費,這就是所謂的「傳染性」。GPL許可協議是目前最流行的開源許可證,被諸多有名的開源軟體使用,例如Linux內核、MySQL資料庫等。
2. 使用該開源軟體的代碼並且對開源代碼有所修改後再散布時,源碼必須以相同許可證公開。
代表許可類型:LGPL, CPL,CDDL, CPL,MPL等
例:LGPL
GNU 寬通用公共許可協議(英語:GNULibrary General Public License,簡稱LGPL),又名GNU庫通用公共許可證,同樣出自自由軟體基金會,有1999年的2.1版和2007年的3.0版。LGPL是GPL的寬松版,它對產品所保留的權利比GPL 少,總的來說,LGPL 適合那些用於非GPL 或非開源產品的開源類庫或框架。因為GPL 要求,使用了GPL 代碼的產品必須也使用GPL 協議,開發者不允許將GPL 代碼用於商業產品。LGPL 繞過了這一限制。LGPL具有弱Copyleft效力,較商業友好: 允許動態鏈接; 有條件地允許靜態鏈接 對於LGPL許可的代碼本身做了修改,那麼再發行就必須使用LGPL或GPL許可證進行。 3. 使用該開源軟體的代碼(包括修改)再散布(redistribute)時,沒有特殊限制,只需要明記許可。
代表許可類型:ASL, BSD,MIT等
例:MIT
MIT協議可能是幾大開源協議中最寬松的一個,由麻省理工學院在1988年推出,又名X11許可證或者X許可證,有不少變種。核心條款是:該軟體及其相關文檔對所有人免費,可以任意處置,包括使用,復制,修改,合並,發表,分發,再授權,或者銷售。唯一的限制是,軟體中必須包含上述版權和許可提示。這意味著:你可以自由使用,復制,修改,可以用於自己的項目。可以免費分發或用來盈利。唯一的限制是必須包含許可聲明。MIT 協議是所有開源許可中最寬松的一個,除了必須包含許可聲明外,再無任何限制。
例:BSD
BSD許可證源自加州大學伯克利分校,所有者是加州大學的董事會。跟其他許可證相比,從GNU通用公共許可證(GPL)到限制重重的著作權(Copyright),BSD許可證比較寬松,甚至跟公有領域更為接近。事實上,BSD許可證被認為是center(中間版權),界乎標準的right與GPL的left之間。Take it down to the center and make as many copies as you want。 可以說,GPL強迫後續版本必須一樣是自由軟體,BSD的後續版本可以選擇要繼續是BSD或其他自由軟體條款或封閉軟體等等。
該協議有多種版本,不同項目發行的BSD許可證不同,比如Apple的BSD許可證與4.4BSD Lite衍生操作系統的BSD許可證最主要的版本有兩個,新BSD 協議與簡單BSD 協議,這兩種協議經過修正,都和GPL 兼容,並為開源組織所認可。新BSD 協議(3條款協議)在軟體分發方面,除需要包含一份版權提示和免責聲明之外,沒有任何限制。另外,該協議還禁止拿開發者的名義為衍生產品背書,但簡單BSD 協議刪除了這一條款。 1.通過電子郵件把許可證發送給license-approval@ opensource .org。在電子郵件中說明你是否願意以你的簽名或者匿名地把許可證發送到許可證討論列表中。(我們願意考慮那些根本不希望被發送的許可證,但由於社團的評審是批準的一個重要組成部分,我們將不得不把該許可證私下地發送給評審者:因此,對沒有被發送到許可證討論列表中的許可證的批准,要花費更長的時間,並且通常要更多地與你交流。)
2.如果我們發現你的許可證不符合開放源代碼的定義,我們將與你一同解決這個問題。
3. 同時,我們將關注許可證論壇列表,並且與你一同工作以解決大家提出的任何未包含的問題。
4.作為該過程的一部分,我們還將就許可證問題向外界尋求法律上的建議。
5. 一旦許可證符合了開放源代碼定義,並且在許可證論壇上經過了充分的討論或者其它的評審者沒有提出重要的問題,我們將通知你,許可證已經被批准了,同時它被復制到我們的網站上,並且被加入以下的許可證列表。

㈩ 採用GPL協議的程序,可以免費應用於商業用途嗎
一群廢物,說了一堆的屁話,不如讓我來說:
GPL協議,它只是針對此辦件的開發而擁有的協議,軟體的使用是免費的,也就是說,它在你使用時,是免費的,你可不用向任何人付錢,但是如果你為了讓這個軟體更加的靈活,那麼你就可以把軟體的源碼上載下來進行二次開發,那麼二次開發的軟體,如果你再使用,就必須要在發布這個修改了之後的程序時,同時在發布包里,加上這個程序的修改了之後的源碼。
總之就是兩個思路:
【適用於開發】: 適用於二次或N次開發,那麼發布時要帶上源碼,讓其傳播,所以它最終的版權是大眾的,而非某一個人的,因此不用交錢就可以使用。
【適用於應用】: 應用GPL協議的軟體不用交錢。
【何時適用於收費】:當這個軟體你自己不會修改,又需要找人修改時,你可以向軟體的有修改能力的協助者交一部分的錢,那麼這就是收費的部分。
GPL協議,它其實就是放下了源碼的私藏,公之於眾,並以上面的三條協議,使軟體在開發,傳播上,擁有生命力,從而取得大眾共同開發的目的,所以,這個軟體的版權是開源者的,但是使用權卻是大眾的,軟體可以出賣它的版權,但是它確再也不可以約束大眾免費使用的權益。
從而成為一個大眾文化用品。
比如:甲骨文買走了MySQL的版權,但是這個軟體,它的使用權,免費權,開發權確是在大眾的手裡,所以,甲骨文,它只有一個掛名權,與GPL協議的上三條維護權,其它的它沒有任何權益。
所以,放開使用GPL協議下的任何軟體吧,讓那麼壟斷的軟體商們去雙腿顫抖吧。