如何查看源碼的許可協議

Ⅰ 如何查看linux系統源碼

例如：想在Linux系統下查看cat命令工具的源碼，方法如下：

1、查看工具的路徑

$whereiscat
cat:/bin/cat/usr/share/man/man1/cat.1.gz

2、查看工具所屬的包

$dpkg-S/bin/cat
coreutils:/bin/cat
coreutils就是cat的源碼包名

3、下載工具源碼包

$sudoapt-getsourcecoreutils
[sudo]passwordforlizh:
正在讀取軟體包列表...完成
正在分析軟體包的依賴關系樹
正在讀取狀態信息...完成
需要下載10.8MB的源代碼包。
獲取：1http://mirrors.sohu.com/ubuntu/maverick/maincoreutils8.5-1ubuntu3(dsc)[1,891B]
獲取：2http://mirrors.sohu.com/ubuntu/maverick/maincoreutils8.5-1ubuntu3(tar)[10.7MB]
獲取：3http://mirrors.sohu.com/ubuntu/maverick/maincoreutils8.5-1ubuntu3(diff)[21.5kB]
下載10.8MB，耗時42秒(254kB/s)
gpgv:於2015年07月06日星期一13時49分55秒CST創建的簽名，使用RSA，鑰匙號21B2133D
gpgv:無法檢查簽名：找不到公鑰
dpkg-source:警告:對./coreutils_8.5-1ubuntu3.dsc校驗簽名失敗
dpkg-source:info:-8.5
dpkg-source:info:unpackingcoreutils_8.5.orig.tar.gz
dpkg-source:info:applyingcoreutils_8.5-1ubuntu3.diff.gz

Ⅱ C#安裝向導加入許可協議的方法

在你的安裝項目上點右鍵->視圖->用戶界面->然後再左邊的窗口，裡面的啟動上點右鍵->添加對話框->許可協議->確定。然後他會在確認安裝的後面，
按照一般的流程，這個應該出現在歡迎使用之後，你可以用滑鼠拖動許可協議到歡迎使用之後
然後點選許可協議之後，在他的屬性裡面有一個LicenseFile屬性，把那個指定成你准備好的協議文件(*.rtf)即可。

Ⅲ 開源的許可證

開放源代碼定義給出了開放源代碼軟體的基本性質。不幸的是，術語開放源代碼遭到了濫用，並且由於它的描述性，它不能作為一個商標（這是我們的首選）被保護。由於社團需要一種可靠的方式以確定一份軟體是否真正是開放源代碼軟體。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． 一旦許可證符合了開放源代碼定義，並且在許可證論壇上經過了充分的討論或者其它的評審者沒有提出重要的問題，我們將通知你，許可證已經被批准了，同時它被復制到我們的網站上，並且被加入以下的許可證列表。

Ⅳ 開源的源碼怎麼控制授權

License是軟體的授權許可，裡面詳盡表述了你獲得代碼後擁有的權利，可以對別人的作品進行何種操作，何種操作又是被禁止的。軟體協議可分為開源和商業兩類，對於商業協議，或者叫法律聲明、許可協議，每個軟體會有自己的一套行文，由軟體作者或專門律師撰寫，對於大多數人來說不必自己花時間和精力去寫繁長的許可協議，選擇一份廣為流傳的開源協議就是個不錯的決策。
世界上開源軟體協議OPEN SOURCE LICENSE的種類非常之多，並且同一款協議有很多變種，協議太寬松會導致作者喪失對作品的很多權利，太嚴格又不便於使用者使用及作品的傳播，所以開源作者要考慮自己對作品想保留哪些權利，放開哪些限制。

Ⅳ 如何查看github代碼的開源協議

克隆之後會把源代碼下載到本地，創建一個本地的代碼庫，可以任意在本地修改代碼並使用git所提供的命令操作代碼，有代碼對應的歷史記錄和分支。

Ⅵ 採用創作共用版權 cc by-nc-nd/2.5/cn 許可協議是什麼意思

第一步：在CC網站選取適合自己的許可協議
進入CC官方網站，選擇適當的司法管轄區域——例如直接選擇中國大陸；
進入許可協議選擇頁面，按照自己期望的許可方式選擇適當的許可協議；
（強烈建議先閱讀許可協議說明 常見問題等信息，其特點是將權利分解成標准要素，以其合理組合構成標准許可模式——協議）；
選定後，即得到選定的許可名稱、普通文本及法律文本（鏈接）及元數據，元數據包括標準的圖形按鈕標識、協議文本鏈接地址等，對網站/網頁使用則提供可直接使用的 HTML 源碼，例如下框中的內容：

<a rel="license" href=" //creativecommons.org/licenses/by-nc-nd/2.5/cn/">
<img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/2.5/cn/88x31.png" />
</a>
<br />本作品採用
<a rel="license" href= 知識共享署名-非商業性使用-禁止演繹 2.5 中國大陸許可協議</a>進行許可。
得到源碼後，將其復制或保持住，就可以進行下面的步驟。
第二步：在新浪BLOG首頁添加版權說明模塊
進入「管理面板-自定義設置－首頁內容維護－自定義空白面板」，創建一個新的空白面板，可命名為「本站版權說明」；
點擊「顯示源代碼」，將上一步選定許可協議後得到的應用源碼粘貼到空白面板中；
根據自身需要對說明文字的表達方式與內容的適當修改，例如：
·明確目標，比如將「本作品」改為「本網站上的作品」。
·「知識共享」、「禁止演繹」等文字冗長且容易誤解，我部分改為英文縮寫（看協議鏈接文字就知道標準的英文縮寫，這只是我個人的喜好）
·可根據需要調整字體和格式，包括加進自己的說明頁面的鏈接等。
·注意：必須保持原圖標和許可協議的鏈接不變，它們是指向您所選定的標准協議文本的，這也是確保法律效力和網上識別的關鍵；修改後的例子如：

本站作品版權均歸署名作者所有，除非另行說明，本站作品採用 CC BY-NC-ND/2.5/CN 許可協議

保存，添加該模塊到首頁，調整到適當的位置，保存退出。
由於面板不完全是所見即所得，所以可能需要反復編輯，並檢查外觀和確保所有鏈接正確。

Ⅶ 怎麼證明代碼是開源還是不開源

是否開源，要看源碼發布的授權協議。

1.BSD開源協議（original BSD license、FreeBSD license、Original BSD license）

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以」為所欲為」,可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟體再發布。

但」為所欲為」的前提當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：

• 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。

• 如果再發布的只是二進制類庫/軟體，則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。

• 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。

BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟體發布和銷售，因此是對 商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。

2. Apache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0）

Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟體）。需要滿足的條件也和BSD類似：

• 需要給代碼的用戶一份Apache Licence

• 如果你修改了代碼，需要再被修改的文件中說明。

• 在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。

• 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。

Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。

3. GPL（GNU General Public License）

我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代 碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商 業軟體公司開發的免費軟體了。

GPL協議的主要內容是只要在一個軟體中使用(」使用」指類庫引用，修改後的代碼或者衍生代碼)GPL 協議的產品，則該軟體產品必須也採用GPL協議，既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題，還可以享受免費的優勢。

由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。

其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。

4.LGPL（GNU Lesser General Public License）

LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協議不同。LGPL 允許商業軟體通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的代碼。這使得採用LGPL協議的開源代碼可以被商業軟體作為類庫引用並 發布和銷售。

但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源 代碼很適合作為第三方類庫被商業軟體引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟體採用。

GPL/LGPL都保障原作者的知識產權，避免有人利用開源代碼復制並開發類似的產品

5.MIT（MIT）

MIT是和BSD一樣寬范的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版里包含原許可協議的聲明,無論你是以二進制發布的還是以源代碼發布的.

Ⅷ 開放源代碼軟體的常見協議

LGPL許可證
LGPL許可證是LESSER GENERAL PUBLIC LICENSE的簡寫，也叫LIBRARY GENERAL PUBLIC LICENSE，中文譯為「較寬松公共許可證」或者「函數庫公共許可證」。該許可證適用於一些由自由軟體基金會與其它決定使用此許可證的軟體作者所特殊設計的軟體軟體包─比如函數庫（即Library）。LGPL許可證，也是自由軟體聯盟GNU開源軟體許可證的一種，大部分的 GNU軟體，包括一些函數庫，是受到原來的 GPL許可證保護的。而LGPL許可證，適用於特殊設計的函數庫，且與原來的通用公共許可證有很大的不同，給予了被許可人較為寬松的權利，所以叫「較寬松公共許可證」。在特定的函數庫中使用它，以准許非自由的程序可以與這些函數庫連結。當一個程序與一個函數庫連結，不論是靜態連結或使用共享函數庫，二者的結合可以合理地說是結合的作品，一個原來的函數庫的衍生品。因此，原來的通用公共許可證只有在整個結合品滿足其自由的標准時，才允許連結。較寬鬆通用公共許可則以更寬松的標准允許其它程序代碼與本函數庫連結。例如，在少數情況下，可能會有特殊的需要而鼓勵大家盡可能廣泛地使用特定的函數庫，因而使它成為實際上的標准。為了達到此目標，必須允許非自由的程序使用此函數庫。一個較常發生的情況是，一個自由的函數庫與一個被廣泛使用的非自由函數庫做相同的工作，在此情況下，限制只有自由軟體可以使用此自由函數庫不會有多少好處，故我們使用了LGPL許可證。在其他情況下，允許非自由程序使用特定的函數庫，可以讓更多的人們使用自由軟體的大部分。例如，允許非自由程序使用GNU C函數庫，可以讓更多的人們使用整個GNU作業系統，以及它的變形，GNU/Linux操作系統。盡管LGPL許可證對使用者的自由保護是較少的，但它卻能確保與此函數庫連結的程序的使用者擁有自由，而且具有使用修改過的函數庫版本來執行該程序的必要方法。
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條有專門的一款是關於對源代碼修改進行描述的規定，就是要求所有再發布者都得有一個專門的文件就對源代碼程序修改的時間和修改的方式有描述。
BSD許可證
BSD許可證原先是用在加州大學柏克利分校發表的各個4.4BSD/4.4BSD-Lite版本上面（BSD是Berkly Software Distribution的簡寫）的，後來也就逐漸沿用下來。1979年加州大學伯克利分校發布了BSD Unix，被稱為開放源代碼的先驅，BSD許可證就是隨著BSD Unix發展起來的。BSD許可證現在被Apache和BSD操作系統等開源軟體所採納。相較於GPL許可證和MPL許可證的嚴格性，BSD許可證就寬松許多了，一樣是只需要附上許可證的原文，不過比較有趣的是，它還要求所有進一步開發者將自己的版權資料放上去，所以拿到以BSD許可證發行的軟體可能會遇到一個小狀況，就是這些版權資料許可證占的空間比程序還大。
QPL許可證
QPL是The Qt Public License的簡稱，是挪威一家機構創設的。QPL許可證的基本要求是獲得源代碼、修改源代碼，並可將修改從原始代碼中分離出來;修改可以按照作者的意願被組合到新版本中;二進制代碼可以和原始代碼同名，這一點對於動態連接庫來說尤其重要;任何人都可以修正錯誤，這對於系統的發布者來說很關鍵;修改過的軟體可以按照滿足QPL許可證基本要求的任何開源軟體許可證進行發布。
QNCL許可證
QNCL許可證是Qt Non Commercial License的簡稱，是QPL許可證的「兄弟版」，就像GPL許可證與LGPL許可證的關系一樣，QNCL許可證比QPL許可證更嚴格一些。在修改和發布方面的規定，QNCL許可證與QPL許可證是一樣的，差異就在於軟體的范圍方面，或者說在連接方面。QNCL許可證規定「假如一個應用程序給你提供了一個入口，使你有權使用QNCL許可證下的軟體的功能開發程序、重復使用程序的某一部分或其他軟體的某一部分，那麼對該應用程序的使用視為是使用QNCL許可證下的軟體的行為，該應用程序應受到QNCL許可證的約束」。QNCL許可證比QPL許可證更嚴格之處在於，QNCL許可證像GPL許可證那樣，完全禁止根據本許可證得到的開放源碼軟體與其他非系統庫函數連接的軟體以其他許可方式一起發布。
Common許可證
Common許可證的全稱是Common Public License。在滿足OSIA開源軟體許可證認證標準的前提了後，Common許可證還有一些細節性的規定值得參考:◆ 明確了專利授權。一般的開源軟體都有明確源代碼的版權人將自己的修改權、復制權等版權權利向公眾許可，但保留署名權，而Common許可證在此基礎上還明確假如源代碼中含有專利權，源代碼專利權人將復制、使用的專有權利向公眾許可。◆ 規定可以將源代碼及修改過的源代碼與其他類型的不受本許可證約束的代碼結合，以新產品的形式發布，只要其中經該許可證獲得的源代碼及修改過的源代碼能按該許可證的要求發布即可。◆ 細化了該許可證終止的情形，包括發生專利侵權訴訟。◆ 明確了一個獨立承擔責任的原則，就是假如按該許可證使用源代碼的使用者將獲得的源代碼應用於商業使用，那麼他就要對在商業應用中出現的由於使用該源代碼程序而產生的侵權訴訟承擔完全責任。這一條規定是比較特殊的，絕大多數開源軟體許可證都不這么要求。
IBM許可證
IBM許可證的全稱是IBM Public License。在滿足OSIA開源軟體許可證認證標準的前提下，IBM許可證還有如下一些細節性規定:◆ 明確了專利授權。一般的開源軟體都明確源代碼的版權人將自己的修改權、復制權等版權權利向公眾許可，但保留署名權，而IBM許可證在此基礎上還明確假如源代碼中含有專利權，源代碼專利權人將復制、使用的專有權利向公眾許可。◆ 細化了該許可證終止的情形，包括不按該許可證的要求發布和使用源代碼、發生專利侵權訴訟等。◆ 像Common許可證一樣，IBM許可證也明確了獨立承擔責任原則，即假如按該許可證使用源代碼的使用者將獲得的源代碼應用於商業使用，那麼他就要對在商業應用中出現的、由於使用該源代碼程序而產生的侵權訴訟承擔完全責任。
Jabber許可證
Jabber許可證的全稱是Jabber Open Source License，由美國Jabber, Inc.公司提供。Jabber許可證在源代碼的復制、發行規定方面基本上和其他許可證沒有什麼特別，但有一些細節規定值得借鑒:◆ 可以將通過該許可證獲得的源代碼及修改過的源代碼與其他類型的不受該許可證約束的代碼結合，以新產品的形式發布，只要其中經該許可證獲得的源代碼及修改過的源代碼能以與該許可證的要求類似的、符合OSI認證的其他開源軟體許可證的方式發布。◆ 明確了需將源代碼置於公眾可以得到的狀態的時間至少應為12個月。◆ 第三方對法定權利的聲明。假如使用者發現通過本許可證獲得的源代碼及應用程序介面中有一方擁有的知識產權，應單獨在源碼的發布時冠以「LEGAL」為抬頭的聲明，寫明知識產權權利要求的細節，提請源代碼的接受者知道自己獲得了哪些知識產權的授權，讓源碼的接受者知道如何與知識產權權利人聯系。◆ 細化了該許可證終止的情形，包括不按該許可證的要求發布和使用源代碼、發生專利侵權訴訟。
協議對比
BSD開源協議
BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以」為所欲為」，可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟體再發布。但」為所欲為」的前提當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：◆如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。◆如果再發布的只是二進制類庫/軟體，則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。◆不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟體發布和銷售，因此是對 商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。
MIT
MIT是和BSD一樣寬范的許可協議，作者只想保留版權，而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。MIT協議又稱麻省理工學院許可證，最初由麻省理工學院開發。被授權人權利：1、被授權人有權利使用、復制、修改、合並、出版發行、散布、再授權及販售軟體及軟體的副本。2、被授權人可根據程式的需要修改授權條款為適當的內容。被授權人義務：在軟體和軟體的所有副本中都必須包含版權聲明和許可聲明。
GNU GPL
我們很熟悉的Linux就是採用了GPL。GPL協議和BSD， Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代 碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商 業軟體公司開發的免費軟體了。GPL協議的主要內容是只要在一個軟體中使用（」使用」指類庫引用，修改後的代碼或者衍生代碼）GPL 協議的產品，則該軟體產品必須也採用GPL協議，既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題， 還可以享受免費的優勢。由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。
GUN LGPL
LGPL 是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協議不同。LGPL 允許商業軟體通過類庫引用（link）方式使用LGPL類庫而不需要開源商業軟體的代碼。這使得採用LGPL協議的開源代碼可以被商業軟體作為類庫引用並 發布和銷售。但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因 此LGPL協議的開源 代碼很適合作為第三方類庫被商業軟體引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟體採用。GPL/LGPL都保障原作者的知識產權，避免有人利用開源代碼復制並開發類似的產品。
Apache Licence 2.0
Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟體）。需要滿足的條件也和BSD類似：◆需要給代碼的用戶一份Apache Licence◆如果你修改了代碼，需要再被修改的文件中說明。◆在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。◆如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。

Ⅸ 如何查看android源碼

當我們在eclipse中開發android程序的時候，往往需要看源代碼（可能是出於好奇，可能是讀源碼習慣），那麼如何查看Android源代碼呢？

比如下面這種情況

假設我們想參看Activity類的源代碼，按著Ctrl鍵，左擊它，現實的結果卻看不到代碼的，提示的信息便是「找不到Activity.class文件」。

此時點擊下面的按鈕，「Change Attached Source…」，選擇android源代碼所在位置，便彈出圖三的對話框。

第一種是選擇工作目錄，即已經存在的android應用程序源代碼。

第二種分兩種方式

（1）選擇External File…按鈕，添加Jar格式文件或者zip格式文件路徑；

（2）選擇External Floder…按鈕，添加文件夾所在路徑。

下面問題就來了，源代碼在哪裡？不能憑空產生阿。

可以通過Android SDK Manager進行源代碼下載；（推薦該種方法），如圖四

勾選Source for Android SDK，進行下載即可。

此外也可通過其他途徑下載，網上有很多共享的資源。

這里選擇第二種方式的（2）方法，選擇源碼所在目錄（即圖四下載源代碼目錄所在路徑），如圖五

點擊「OK」按鈕，此時，Activity文件便能夠查看源代碼了，如圖六。

這樣就大功告成了！！！