軟體協議有哪些

A. 手機軟體是走https協議的有哪些

1、你是說手機上的客戶端軟體或者APP嗎？我所知道的走配有https協議的手機軟體：微信、qq、支付寶、淘寶、蘋果AppStore裡面的軟體，所有的手機銀行客戶端（中、農、工、建）、招商等等。
2、https協議是一種加密傳輸協議，比http更加安全，可以很好的保障傳輸數據的安全，一般和金融相關，支付相關，購物相關的軟體幾乎都要使用https協議，還有涉及到用戶隱私，含有賬號密碼等軟體都要使用。
3、https實現需要SSL證書，SSL證書需要到CA機構比如（ 沃通CA ）等去申請，通過審核後才簽發。

B. 視頻直播軟體開發中常用的流媒體傳輸協議有哪些

視頻直播軟體系統開發，常用的流媒體傳輸協議有RTMP,RTSP,HLS,HTTP-FLV
RTMP:(可用於推流端和拉流端) Real Time Messaging Protocol 實時消息傳輸協議，RTMP協議中，視頻必須是H264編碼，音頻必須是AAC或MP3編碼，且多以flv格式封包。因為RTMP協議傳輸的基本是FLV格式的流文件，必須使用flash播放器才能播放.
RTSP:(用於推流端) Real-Time Stream Protocol，RTSP 實時效果非常好，適合視頻聊天、視頻監控等方向
HLS(用於拉流端) Http Live Streaming，由Apple公司定義的基於HTTP的流媒體實時傳輸協議。傳輸內容包括兩部分：1.M3U8描述文件，2.TS媒體文件。TS媒體文件中的視頻必須是H264編碼，音頻必須是AAC或MP3編碼。數據通過HTTP協議傳輸。目前video.js庫支持該格式文件的播放
HTTP-FLV(用於拉流端) 本協議就是http+flv,將音視頻數據封裝成FLV格式,然後通過http協議傳輸到客戶端,這個協議大大方便了瀏覽器客戶端播放直播視頻流.目前flv.js庫支持該格式的文件播放

C. 這些協議是那些軟體用的

GPL授予程序接受人以下權利（或稱「自由」）：以任何目的運行此程序的自由；再發行復製件的自由；改進此程序，並公開發布改進的自由（前提是能得到源代碼）。

相反地，隨版權所有軟體的最終用戶許可協議幾乎從不授予用戶任何權利（除了使用的權利），甚至可能限製法律允許的行為，比如逆向工程。

GPL與其他一些「許可的」自由軟體許可協議（比如BSD許可協議）相比，主要區別就在於GPL尋求確保上述自由能
在復製件及演繹作品中得到保障。它通過一種由斯托曼發明的叫Copyleft的法律機制實現，即要求GPL程序的演繹作品也要在GPL之下。相反，BSD
式的許可協議並不禁止演繹作品變成專有軟體。

由於某些原因，GPL成為了自由軟體和開源軟體的最流行許可協議。到2004年4月，GPL已佔Freshmeat
上所列的自由軟體的約75%，SourceForge的約68%。類似的，2001年一項關於Red Hat Linux
7.1的調查顯示一般的代碼都以GPL發布。著名的GPL自由軟體包括Linux核心和GCC。

D. 幾種開發者常見的開源軟體協議的分析與介紹

本文主要是針對幾種開發者常見的開源軟體協議的分析與介紹。
Mozilla Public License
MPLLicense，允許免費重發布、免費修改，但要求修改後的代碼版權歸軟體的發起者。這種授權維護了商業軟體的利益，，它要求基於這種軟體得修改無償貢獻版權給該軟體。這樣，圍繞該軟體得所有代碼得版權都集中在發起開發人得手中。但MPL是允許修改，無償使用得。MPL軟體對鏈接沒有要求。
BSD開源協議
BSD開源協議是一個給於使用者很大自由的協議。可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟體再發布。 當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：
1. 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
2. 如果再發布的只是二進制類庫/軟體，則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。
3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟體發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。
Apache Licence 2.0
Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布(作為開源或商業軟體)。需要滿足的條件：
1. 需要給代碼的用戶一份Apache Licence
2. 如果你修改了代碼，需要再被修改的文件中說明。
3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
4. 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。
GPL
GPL許可證是自由軟體的應用最廣泛的軟體許可證，人們可以修改程式的一個或幾個副本或程式的任何部分，以此形成基於這些程式的衍生作品。必須在修改過的檔案中附有明顯的說明：您修改了此一檔案及任何修改的日期。您必須讓您發布或出版的作品，包括本程式的全部或一部分，或內含本程式的全部或部分所衍生的作品，允許第三方在此許可證條款下使用，並且不得因為此項授權行為而收費。
LGPL
Linux就是採用了GPL。GPL協議和BSD,ApacheLicence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商業軟體公司開發的免費軟體了。
GPL協議的主要內容是只要在一個軟體中使用(「使用」指類庫引用，修改後的代碼或者衍生代碼)GPL協議的產品，則該軟體產品必須也採用GPL協議，既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題，還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似
Public Domain
公共域授權。將軟體授權為公共域，這些軟體包沒有授權協議，任何人都可以隨意使用它。
zlib/libpng
只要不誤傳該軟體的起源並保留原始發布的公告，任何人可以以任何目的使用該軟體，包括商業應用
Artistic許可使作者保持對進一步開發的控制。
MIT
MIT是和BSD一樣寬范的許可協議，作者只想保留版權,而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。

E. 軟體開發一系列合同

目錄 1. 甲方乙方介紹 3 2. 術語、關鍵詞解釋 3 3. 甲方委託乙方開發的內容和要求 4 4. 乙方開發計劃 4 5. 甲方驗收計劃 5 7. 乙方維護計劃 5 8. 禁止轉委託開發 5 9. 保密 6 10. 知識產權歸屬 6 11. 第三方知識產權 6 12. 風險責任的承擔 6 13. 報酬及支付方式 7 14. 違約與賠償 7 15. 不可抗力 8 16. 解除合同 8 17. 爭議解決 8 18. 一般條款 9 19. 開發過程中的變更聲明 9 20. 簽字確認 10 附件10 1. 甲方乙方介紹 1.1 甲方介紹 甲方（委託方）名稱 通信地址 聯系人 電話、傳真 E-Mail 介紹 1.2 乙方介紹 乙方（承包方）名稱 通信地址 聯系人 電話、傳真 E-Mail 介紹 2. 術語、關鍵詞解釋 術語、關鍵詞 解釋 3. 甲方委託乙方開發的內容和要求 3.1 開發內容介紹 提示：此處扼要地闡述項目開發內容，詳細內容可以放在附件中。 3.2 技術指標和質量要求 3.3 應當遵循的標准和規范 4. 乙方開發計劃 4.1 開發期限和開發地點 本項目的開始日期為 ，截至日期為 。 本項目的開發地點是 。 4.2 任務進度計劃 提示： （1）乙方和甲方共同協商開發計劃，此處的計劃是高層描述，僅用於合同。 （2）乙方項目小組應當撰寫更加詳細的《項目計劃》以指導項目開發。該《項目計劃》不得與本合同抵觸，須通過甲方的審批。（甲方是乙方的客戶） 5. 甲方驗收計劃 驗收時間 地點 甲方負責人 乙方負責人 乙方應交付的成果 輸入乙方應交付的所有成果 驗收方式 （1）甲方組織人員對乙方交付的文檔進行技術評審。（2）甲方組織人員對乙方交付的可執行軟體進行驗收測試，《驗收測試計劃》和《驗收測試用例》由雙方共同確定。 問題處理約定 如果甲方發現工作成果中存在缺陷，雙方應當視問題的嚴重性給出合適的處理措施。約定如下：（1）如果工作成果存在嚴重的缺陷，則退回給乙方。乙方應當給出糾正缺陷，雙方協商第二次驗收的時間。乙方應當賠償給甲方造成的損失。（2）如果工作成果存在一些輕微的缺陷，則乙方應當給出糾正缺陷的措施，雙方協商是否需要第二次驗收。 7. 乙方維護計劃 免費維護時間 收費維護時間 維護方式與響應時間 補充： 8. 禁止 轉委託 開發 在本 合同有效 期內，乙方必須親自履行甲方委託的開發項目，未徵得甲方的書面同意，不得將其在本合同項下的受託 項目部 分或 全部轉讓給 任何其它方執行。違 反本 項規定的，乙方將承擔全部可能產生的責任。 9. 保密 9.1 乙方應對本合同所述的技術資料和 技術秘密 採取保密措施，乙方未經甲方的書面同意，不得將 本項目 所涉及的技術秘密和資料向與本項目無關的人員或第三方透露，也不能就有關合同內容的任何部分進行新聞的發布、公開的宣稱、否認或承認。 9.2 乙方知道違反本 條規 定將給甲方造成難以彌補的損失，為此同意承擔由此產生的經濟上和法律上的責任。 9.3 乙方承認本合同中的技術資料和技術秘密為甲方所專有，將其對乙方進行披露並不意味著任何 所有權 、專利權的轉讓。 9.4 在本合同項目的研究開發結束並通過驗收後，乙方應向甲方提供本合同項目的研究成果，包括 技術規范 、測試文件和 質量標准 等相關的技術資料，或者 計算機軟體 、文檔及 源代碼 等。乙方應歸還甲方提供的所有技術資料或文件等，並承諾不保留任何復印件。 9.5 乙方在下列情況下沒有為任何信息 保守秘密 的義務，即當乙方已事 先知 道它無需為其保守秘密時；當該信息已為公眾所知且不是由乙方未經授權而提供時；當該信息是由乙方獨自開發的；或者當乙方從某第三方合法地接受該信息且沒 有保 密限制時。 9.6 本條規定的義務和權利在本 合同期 滿或終止後將持續 年有效。 10. 知識產權 歸屬 10.1 本合同項目 技術成果 的 專利申請權 、計算機軟體的 著作 、技術秘密以及技術資料等知識產權歸甲方所有。同時乙方放棄 計算機軟體著作權 的 署名權 。 10.2 乙方不得在向甲方交付研究開發成果之前，將研究開發成果及 非專利技術 泄露或轉讓給第三方。 10.3 在履行本合同期間及以後，乙方不得就本合同的研究開發項目先後與任何第三方簽訂或接受委託開發合同。乙方如重復簽訂研究開發 項目合同 ，應對以後簽 訂合同 的無效及其對侵犯甲方的知識產權承擔所有經濟和法律的責任。 11. 第三方知識產權 11.1 乙方承諾，其在受託開發本合同項目中，不會侵犯第三方的知識產權，同時，在交付本合同成果中也不會涉及或非法使用第三方的知識產權。 11.2任何因甲方使用本項目的成果而引起對第三方知識產權的侵權訴訟，乙方應積極協助甲方進行抗辯。如確因本項目成果引起的侵權，乙方應承擔所有的賠償責任，包括甲方因訴訟產生的一切費用。 12. 風險責任的承擔 12.1 乙方在研究開發過程中，由於受現有的 科學知識 、技術水平或 試驗條件 的限制，發生無法預見、無法防止或無 法克 服的技術困難，導致研究開發工作全部或部分失敗，該風險責任的損失由雙方共同承擔，即根據損失的金額各自承擔50%。 12.2 確定上述風險必須同時具備以下三個條件： （1）研究開發的項目本身在國際和國內 現有技術 水平下具有足夠的難度； （2）研究開發方在開發過程中已充分發揮了主觀的努力； （3）同領域的專家認為在技術上是屬於合理的失敗。 12.3 乙方發現可能致使研究開發失敗或部分失敗的情形時，應當 及時通 知甲方並採取適當措施減少損失。沒有及時通知並採取適當措施，致使損失擴大的，應當就擴大的損失承擔責任。 13. 報酬及支付方式 提示：付款方式是指分幾次付款，每次支付條件和（或）日期等內容。甲方將根據本合同項目的開發進程支付上述報酬。 合同總金額 乙方銀行帳號 支付批次 金額 支付條件 估計時間 補充： 14. 違約 與賠償 14.1 甲方未按本 合同規定 支付第一期研究開 發報 酬， 乙方 有權解除合同。 14.2甲方逾期支付第二期或第三期開發研究報酬的，自逾期的第二天起，每逾期一天支付應付報酬額的0.05% 違約金 ，違約金總額不超過 應付款 額的50%。逾期二個月仍不支付的，造成研發工作停滯、延誤或失敗的，乙方對此不承擔責任。 14.3 乙方未按計劃或不實施研究開發工作，甲方有權要求乙方實施研究開發計劃並採取 補救措施 。如乙方逾期一個月仍未按計劃或不實施研究開發工作，甲方有權解除本合同，並且乙方應在二周內返還所有甲方提供的研究開發報酬，返還或銷毀甲方提供的有關技術資料和文件，並承擔本合同報酬總額20%的違約金。 14.4 乙方應按本合同規定的研究開發進程完成開發項目。如乙方逾期完成開發項目，甲方將給予乙方一個月的 寬限期 ，並且不追究乙方的 違約責任 。但寬限期滿後，乙方仍未完成開發項目，其違約責任應 追溯 到本合同規定的違約的第一天起，每延期一天向甲方支付本合同開發研究報酬總額的0.05%違約金，違約金總額不超過本合同開發研究報酬總額的50%。 14.3 除了本合同第7.2 條規 定的條件外，乙方未能完成甲方委託的開發項目或開發成果不符合本合同約定的要求，乙方承擔本合同報酬總額20%的違約金，並返還研究開發費用。 14.4 乙方將甲方支付的研發經費用於履行合同以外的目的，甲方有權制止並要求其糾正。如因此造成本合同研究開發項目停滯、延誤或失敗的，乙方應當承擔給甲方造成的損失賠償責任。 15. 不可抗力 15.1 不可抗力是指本 合同生效 後，發生不能預見並且對其發生和後果不能防止或避免的事件，如 地震 、 台風 、 水災 、 火災 、戰爭等，致使直接影響本 合同的履行 或不能按約定的條件履行。 15.2發生不可抗力的一方應立即通知對方，並在十五天內提供不可抗力的詳情及將有關證 明文 件送交對方。 15.3發生不可抗力事件時，甲乙雙方應協商以尋找一個合理的解決方法，並盡一切努力減輕不可抗力產生的後果。 15.4如不可抗力事件持續三十天時，甲乙雙方應友好協商解決本合同是否 繼續履行 或終止的問題。 16. 解除合同 16.1 如果滿足以下條件，任一方在通知對方後，都可以解除本合同。 16.2 一方嚴重違 反本 合同項下的義務，並且違約方在對方通知後三十天仍未糾正，非違約方向違約方發出解除合同的書面通知時。如果該違約無法在三十天內糾正，而違約方在此期限內已經開始著手，並將以努力誠懇繼續糾正此 違約行為 ，則守約方應為違約方合理地延長該時間的期限。 16.3 當一方按正常程序停止經營業務、破產、處於付款拖欠、延期償付、公司重組或倒閉狀況，或全部轉讓利潤與 債權人 、書面承認 無力償還 到期債務、 委派 清算人 清算其業務或財產，或參與或接受與破產或債權人權利有關的法律或 行政訴訟 程序時。 16.4 當本合同以任何原因終止時，乙方應立即停止使用並銷毀包含甲方機 密信 息的 所有物 件，並證明該銷毀情況；或者將這些物件歸還對方。 17. 爭議解決 17.1 本合同及其修訂本的有效性、履行和與本合同及其修訂本效力有關的所有事宜，將受 中華人民共和國 法律管轄，任何爭議僅適用中華人民共和國法律。 17.2 甲乙雙方因合同的解釋或履行發生爭議時，首先應爭取通過友好協商解決，該協商應在三十天內解決。 17.3 如協商不能解決時，合同的任何一方可將爭議提交本地 仲裁委員會 ，並按該 委員 會的 仲裁規則 進行仲裁。仲裁決定對雙方都有約束力。 17.4 爭議進行仲裁期間，除爭議事項外，甲乙雙方應繼續履行各自本合同中規定的義務和行使權利。 18. 一般條款 18.1 除非本合同另有規定，任何一方對本合同提出的任何棄權、修改或更改須以書面形式提交給對方，並經對方簽字認可，否則本合同的任何條款均不得視作已被棄權、修改或更改。本合同的修改或變更，須由雙方友好協商並經授權代表簽署書面文件方可生效。 18.2 如本合同的一條或者一條以上的條款被適用法律視為無法實施，則（1）該無法實施的條款不會影響到本合同中其他任何條款；（2）本合同應被視為從未包含該無法實施的條款；（3）雙方應本著誠信的原則商議，用一條意思最接近的條款替換該無法實施的條款。 18.3 合同各方在此聲明並保證：（1）代表各方簽署本合同的人員擁有明確的授權，其簽字對簽約方具有約束力；（2）本合同的執行、遞交與履行不會違反各方公司的章程、規定；以及（3）本合同的執行、遞交與履行已經得到全部所需合作方或 公司行為 的正式授權；並且本合同已對上述 方形 成了有效的、具有約束力的同時能按其條款執行的義務。 18.4 本合同文本的 定稿 應以 文寫成，附件以 文寫成。合同各方在本合同執行過程中進行的所有 通信聯絡 均應以 文進 行。本合同以 文文本為准（或「兩種文本有同等 法律效力 」） 18.5 雙方同意，本合同條款的上下文如果表示出該條款在本 合同有效 期後仍然有效，則該條款在本合同有效期後應繼 續保 持有效。 18.6 本合同與附件構成雙方間的完整的合同，並將取代之前所有的書面或口頭、執行或未執行的討論、合同或聲明。未經雙方授權代表再簽定 正式合同 ，本合同將不作變化、增刪和修改或其他活動。 19. 開發過程中的變更聲明 由於甲乙雙方在簽 訂合同 之際，對項目需求的了解不夠深入，因此本合同中的開發內容和計劃可能與實際情況不符合。在實際開發過程中，雙方可能變更開發內容和開發計劃。 為了避免將來發生糾紛，特此聲明： 本項目 的實際開發內容、開發計劃、 驗收標准 以雙方簽字確認的《需求 規格說明 書》為依據。如果需求發生變更，雙方將重新協商開發計劃和費用。 20. 簽字確認 本合同一式__份，甲乙雙方各持__份，自合同各方授權代表簽字之日起生效。 甲方簽字 簽字日期 乙方簽字 簽字日期 追問： 大俠，完了嗎？ 回答： 恩，他這個不能一次發完！ 上面發的這個是比較全面的，你看下！ 希望對你有幫助！

F. 自由軟體協議包括哪些

下面的正文是自由軟體基金會GNU通用公共許可證原始文檔的副本。Linux操作系統以及與它有關的大量軟體是在GPL的推動下開發和發布的。
你將看到：如果你打算為了發布的目的修改，更新或改進任何受通用公共許可證約束的軟體，你所修改的軟體軟體同樣必須受到GNU通用許可證條款的約束。

GNU通用公共許可證
1991.6 第二版

版權所有（C）1989，1991 Free Software foundation, Inc.
675 Mass Ave, Cambridge, MA02139, USA
允許每個人復制和發布這一許可證原始文檔的副本，但絕對不允許對它進行任何修改。

序言

大多數軟體許可證決意剝奪你的共享和修改軟體的自由。對比之下，GNU通用公共許可證力圖保證你的共享和修改自由軟體的自由。——保證自由軟體對所有用戶是自由的。GPL適用於大多數自由軟體基金會的軟體，以及由使用這些軟體而承擔義務的作者所開發的軟體。（自由軟體基金會的其他一些軟體受GNU庫通用許可證的保護）。你也可以將它用到你的程序中。當我們談到自由軟體（free software）時，我們指的是自由而不是價格。我們的GNU通用公共許可證決意保證你有發布自由軟體的自由（如果你願意，你可以對此項服務收取一定的費用）；保證你能收到源程序或者在你需要時能得到它；保證你能修改軟體或將它的一部分用於新的自由軟體；而且還保證你知道你能做這些事情。為了保護你的權利，我們需要作出規定：禁止任何人不承認你的權利，或者要求你放棄這些權利。如果你修改了自由軟體或者發布了軟體的副本，這些規定就轉化為你的責任。
例如，如果你發布這樣一個程序的副本，不管是收費的還是免費的，你必須將你具有的一切權利給予你的接受者；你必須保證他們能收到或得到源程序；並且將這些條款給他們看，使他們知道他們有這樣的權利。
我們採取兩項措施來保護你的權利。
（1）給軟體以版權保護。
（2）給你提供許可證。它給你復制，發布和修改這些軟體的法律許可。
同樣，為了保護每個作者和我們自己，我們需要清楚地讓每個人明白，自由軟體沒有擔保（no warranty）。如果由於其他某個人修改了軟體，並繼續加以傳播。我們需要它的接受者明白：他們所得到的並不是原來的自由軟體。由其他人引入的任何問題，不應損害原作者的聲譽。
最後，任何自由軟體不斷受到軟體專利的威脅。我們希望避免這樣的風險，自由軟體的再發布者以個人名義獲得專利許可證。事實上，將軟體變為私有。為防止這一點，我們必須明確：任何專利必須以允許每個人自由使用為前提，否則就不準許有專利。
下面是有關復制，發布和修改的確切的條款和條件。

GNU通用公共許可證
有關復制，發布和修改的條款和條件

0. 此許可證適用於任何包含版權所有者聲明的程序和其他作品，版權所有者在聲明中明確說明程序和作品可以在GPL條款的約束下發布。下面提到的「程序」指的是任何這樣的程序或作品。而「基於程序的作品」指的是程序或者任何受版權法約束的衍生作品。也就是說包含程序或程序的一部分的作品。可以是原封不動的，或經過修改的和／或翻譯成其他語言的（程序）。在下文中，翻譯包含在修改的條款中。每個許可證接受人（licensee）用你來稱呼。
許可證條款不適用於復制，發布和修改以外的活動。這些活動超出這些條款的范圍。運行程序的活動不受條款的限止。僅當程序的輸出構成基於程序作品的內容時，這一條款才適用（如果只運行程序就無關）。是否普遍適用取決於程序具體用來做什麼。

1. 只要你在每一副本上明顯和恰當地出版版權聲明和不承擔擔保的聲明，保持此許可證的聲明和沒有擔保的聲明完整無損，並和程序一起給每個其他的程序接受者一份許可證的副本，你就可以用任何媒體復制和發布你收到的原始的程序的源代碼。
你可以為轉讓副本的實際行動收取一定費用。你也有權選擇提供擔保以換取一定的費用。

2. 你可以修改程序的一個或幾個副本或程序的任何部分，以此形成基於程序的作品。只要你同時滿足下面的所有條件，你就可以按前面第一款的要求復制和發布這一經過修改的程序或作品。
a） 你必須在修改的文件中附有明確的說明：你修改了這一文件及具體的修改日期。
b） 你必須使你發布或出版的作品（它包含程序的全部或一部分，或包含由程序的全部或部分衍生的作品）允許第三方作為整體按許可證條款免費使用。
c） 如果修改的程序在運行時以交互方式讀取命令，你必須使它在開始進入常規的交互使用方式時列印或顯示聲明：包括適當的版權聲明和沒有擔保的聲明（或者你提供擔保的聲明）；用戶可以按此許可證條款重新發布程序的說明；並告訴用戶如何看到這一許可證的副本。（例外的情況：如果原始程序以交互方式工作，它並不列印這樣的聲明，你的基於程序的作品也就不用列印聲明）。
這些要求適用於修改了的作品的整體。如果能夠確定作品的一部分並非程序的衍生產品，可以合理地認為這部分是獨立的，是不同的作品。當你將它作為獨立作品發布時，它不受此許可證和它的條款的約束。但是當你將這部分作為基於程序的作品的一部分發布時，作為整體它將受到許可證條款約束。准予其他許可證持有人的使用范圍擴大到整個產品。也就是每個部分，不管它是誰寫的。
因此，本條款的意圖不在於索取權利；或剝奪全部由你寫成的作品的權利。而是履行權利來控制基於程序的集體作品或衍生作品的發布。
此外，將與程序無關的作品和該程序或基於程序的作品一起放在存貯體或發布媒體的同一卷上，並不導致將其他作品置於此許可證的約束范圍之內。

3. 你可以以目標碼或可執行形式復制或發布程序（或符合第2款的基於程序的作品)，只要你遵守前面的第1，2款，並同時滿足下列3條中的1條。
a）在通常用作軟體交換的媒體上，和目標碼一起附有機器可讀的完整的源碼。這些源碼的發布應符合上面第1，2款的要求。或者
b）在通常用作軟體交換的媒體上，和目標碼一起，附有給第三方提供相應的機器可讀的源碼的書面報價。有效期不少於3年，費用不超過實際完成源程序發布的實際成本。源碼的發布應符合上面的第1，2款的要求。或者
c）和目標碼一起，附有你收到的發布源碼的報價信息。（這一條款只適用於非商業性發布，而且你只收到程序的目標碼或可執行代碼和按b）款要求提供的報價）。
作品的源碼指的是對作品進行修改最優先擇取的形式。對可執行的作品講，
完整的源碼包括：所有模塊的所有源程序，加上有關的介面的定義，加上控制可執行作品的安裝和編譯的script。作為特殊例外，發布的源碼不必包含任何常規發布的供可執行代碼在上面運行的操作系統的主要組成部分（如編譯程序，內核等）。除非這些組成部分和可執行作品結合在一起。
如果採用提供對指定地點的訪問和復制的方式發布可執行碼或目標碼，那麼，提供對同一地點的訪問和復制源碼可以算作源碼的發布，即使第三方不強求與目標碼一起復制源碼。

4. 除非你明確按許可證提出的要求去做，否則你不能復制，修改，轉發許可證和發布程序。任何試圖用其他方式復制，修改，轉發許可證和發布程序是無效的。而且將自動結束許可證賦予你的權利。然而，對那些從你那裡按許可證條款得到副本和權利的人們，只要他們繼續全面履行條款，許可證賦予他們的權利仍然有效。

5. 你沒有在許可證上簽字，因而你沒有必要一定接受這一許可證。然而，沒有任何其他東西賦予你修改和發布程序及其衍生作品的權利。如果你不接受許可證，這些行為是法律禁止的。因此，如果你修改或發布程序（或任何基於程序的作品），你就表明你接受這一許可證以及它的所有有關復制，發布和修改程序或基於程序的作品的條款和條件。

6. 每當你重新發布程序（或任何基於程序的作品）時，接受者自動從原始許可證頒發者那裡接到受這些條款和條件支配的復制，發布或修改程序的許可證。你不可以對接受者履行這里賦予他們的權利強加其他限制。你也沒有強求第三方履行許可證條款的義務。

7. 如果由於法院判決或違反專利的指控或任何其他原因（不限於專利問題）的結果，強加於你的條件（不管是法院判決，協議或其他）和許可證的條件有沖突。他們也不能用許可證條款為你開脫。在你不能同時滿足本許可證規定的義務及其他相關的義務時，作為結果，你可以根本不發布程序。例如，如果某一專利許可證不允許所有那些直接或間接從你那裡接受副本的人們在不付專利費的情況下重新發布程序，唯一能同時滿足兩方面要求的辦法是停止發布程序。
如果本條款的任何部分在特定的環境下無效或無法實施，就使用條款的其餘部分。並將條款作為整體用於其他環境。
本條款的目的不在於引誘你侵犯專利或其他財產權的要求，或爭論這種要求的有效性。本條款的主要目的在於保護自由軟體發布系統的完整性。它是通過通用公共許可證的應用來實現的。許多人堅持應用這一系統，已經為通過這一系統發布大量自由軟體作出慷慨的供獻。作者／捐獻者有權決定他／她是否通過任何其他系統發布軟體。許可證持有人不能強制這種選擇。

本節的目的在於明確說明許可證其餘部分可能產生的結果。

8. 如果由於專利或者由於有版權的介面問題使程序在某些國家的發布和使用受到限止，將此程序置於許可證約束下的原始版權擁有者可以增加限止發布地區的條款，將這些國家明確排除在外。並在這些國家以外的地區發布程序。在這種情況下，許可證包含的限止條款和許可證正文一樣有效。

9. 自由軟體基金會可能隨時出版通用公共許可證的修改版或新版。新版和當前的版本在原則上保持一致，但在提到新問題時或有關事項時，在細節上可能出現差別。
每一版本都有不同的版本號。如果程序指定適用於它的許可證版本號以及「任何更新的版本」。你有權選擇遵循指定的版本或自由軟體基金會以後出版的新版本，如果程序未指定許可證版本，你可選擇自由軟體基金會已經出版的任何版本。

10. 如果你願意將程序的一部分結合到其他自由程序中，而它們的發布條件不同。寫信給作者，要求准予使用。如果是自由軟體基金會加以版權保護的軟體，寫信給自由軟體基金會。我們有時會作為例外的情況處理。我們的決定受兩個主要目標的指導。這兩個主要目標是：我們的自由軟體的衍生作品繼續保持自由狀態。以及從整體上促進軟體的共享和重復利用。

沒有擔保

11. 由於程序准予免費使用，在適用法准許的范圍內，對程序沒有擔保。除非另有書面說明，版權所有者和／或其他提供程序的人們「一樣」不提供任何類型的擔保。不論是明確的，還是隱含的。包括但不限於隱含的適銷和適合特定用途的保證。全部的風險，如程序的質量和性能問題都由你來承擔。如果程序出現缺陷，你承擔所有必要的服務，修復和改正的費用。

12. 除非適用法或書面協議的要求，在任何情況下，任何版權所有者或任何按許可證條款修改和發布程序的人們都不對你的損失負有任何責任。包括由於使用或不能使用程序引起的任何一般的，特殊的，偶然發生的或重大的損失（包括但不限於數據的損失，或者數據變得不精確，或者你或第三方的持續的損失，或者程序不能和其他程序協調運行等）。即使版權所有者和其他人提到這種損失的可能性也不例外。

最後的條款和條件
如何將這些條款用到你的新程序

如果你開發了新程序，而且你需要它得到公眾最大限度的利用。要做到這一點的最好辦法是將它變為自由軟體。使得每個人都能在遵守條款的基礎上對它進行修改和重新發布。
為了做到這一點，給程序附上下列聲明。最安全的方式是將它放在每個源程序的開頭，以便最有效地傳遞拒絕擔保的信息。每個文件至少應有「版權所有」行以及在什麼地方能看到聲明全文的說明。

<用一行空間給出程序的名稱和它用來做什麼的簡單說明>
版權所有（C） 19XX <作者姓名>
這一程序是自由軟體，你可以遵照自由軟體基金會出版的GNU通用公共許可證條款來修改和重新發布這一程序。或者用許可證的第二版，或者（根據你的選擇）用任何更新的版本。
發布這一程序的目的是希望它有用，但沒有任何擔保。甚至沒有適合特定目的隱含的擔保。更詳細的情況請參閱GNU通用公共許可證。
你應該已經和程序一起收到一份GNU通用公共許可證的副本。如果還沒有，寫信給：
The Free Software Foundation, Inc., 675 Mass Ave, Cambridge,
MA02139, USA
還應加上如何和你保持聯系的信息。

如果程序以交互方式進行工作，當它開始進入交互方式工作時，使它輸出類似下面的簡短聲明：
Gnomovision 第69版， 版權所有（C） 19XX， 作者姓名，
Gnomovision絕對沒有擔保。 要知道詳細情況，請輸入『show w』。
這是自由軟體，歡迎你遵守一定的條件重新發布它，要知道詳細情況，
請輸入『show c』。
假設的命令『show w』和『show c』應顯示通用公共許可證的相應條款。當然，你使用的命令名稱可以不同於『show w』和『show c』。根據你的程序的具體情況，也可以用菜單或滑鼠選項來顯示這些條款。

如果需要，你應該取得你的上司（如果你是程序員）或你的學校簽署放棄程序版權的聲明。下面只是一個例子，你應該改變相應的名稱：
Yoyodyne公司以此方式放棄James Harker所寫的 Gnomovision程序的全部版權利益。
Ty coon付總裁

這一許可證不允許你將程序並入專用

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

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