軟體開放知識產權協議

『壹』 軟體授權協議 誰是甲方

甲方（委託方）：_________ 法定代表人：_________ 地址：_________ 郵編：_________ 乙方（開發方）：_________ 法定代表人：_________ 地址：_________ 聯系電話：_________ 郵編：_________ 目 錄 一、定義二、開發軟體描述三、軟體開發四、交付、領受與驗收五、知識產權和使用權六、維護和培訓七、價格與付款方式八、保證與責任九、保密十、違約與賠償責任十一、項目變更十二、其它十三、爭議解決十四、合同的生效、解除補充條款附件鑒於甲方有意委託乙方開發用於 （財務、經營管理等業務）的計算機信息化系統軟體，雙方特依據《中華人民共和國合同法》及相關的法律法規之規定，在自願、平等、互利互惠、協商一致的基礎上，雙方達成如下協議：一、定義 本合同中使用的下列詞語具有如下含義：1．「軟體」包括「軟體系統」，除另有指明外，指描述於本合同附件_________中的在本合同履行期內所開發和提供的當前和將來的軟體版本，包括乙方為履行本合同所開發和提供的軟體版本和相關的文件。2．「可交付件」指附件 中指定的由乙方所交付的軟體，包括源代碼、安裝盤、技術文檔、用戶指南、操作手冊、安裝指南和測試報告等。3．「交付」 指乙方在雙方規定的日期內交付約定開發的軟體的行為。但是乙方完成交付行為，並不意味著乙方已經完成了本合同項下所規定的所有義務。4．「規格」是指在技術或其他開發任務上所設定的技術標准、規范。5．「里程碑」是指附件_________中所規定的由乙方在本軟體開發過程中階段性完成的，並具有相對獨立性的部分軟體或模塊。 6．「源代碼」指用於該軟體的源代碼。其必須可為熟練的程序員理解和使用，可列印以及被機器閱讀或具備其他合理而必要的形式，包括對該軟體的評估、測試或其它技術文件。 7．「商業秘密」指甲、乙方各自所擁有的，不為公眾所知的管理信息、方式方法、顧客名單、商業數據、產品信息、銷售渠道、技術訣竅、源代碼、計算機文檔等，或由甲、乙方在履行本合同過程中明確指明為商業秘密的、法律所認可的任何信息。8．「工作日」指國家所規定的節假日之外的所有工作日，未指明為工作日的日期指自然順延的日期。二、開發軟體描述 1．本軟體是甲方為_________（經營的業務）而開發的軟體。該軟體處理的對象是甲方的_________（財務、人力資源管理、業務交易數據處理、游戲軟體等）；該軟體的主要功能目標為_________。2．甲方原有信息系統描述（開發軟體在甲方原系統中運行選擇本條）甲方原有的相關計算機信息系統為_________，其主要功能是_________。乙方將結合甲方的計算機信息系統進行軟體開發，使開發軟體的功能同現有系統中已有的設備和相關軟體相匹配。已有系統的設備和軟體見附件_________。3．軟體系統 3．1乙方所開發的軟體系統為_________（系統名稱）；其中：（1）屬於第三方的軟體為_________；（2）屬於乙方所擁有的軟體為_________；（3）甲方委託乙方開發的軟體為_________；（4）乙方可以委託具有相應開發能力的第三方開發的軟體為_________。 3．2乙方為甲方開發的軟體系統分為_________個子系統，包括_________子系統_________子系統和_________子統，與_________（甲方原有系統）共同構成本合同所規定的軟體系統。該軟體所構建的系統的主要功能為_________。該軟體系統的名稱、里程碑、模塊、功能、規格、版本、價格、檢測標准等相關情況見附件_________。4．軟體開發的目標軟體整體功能符合甲方所描述的_________（經營、管理等）系統的要求，應達到_________（正確性、效率、安全性、可靠性、開放性、實用性等）的技術指標。5．軟體開發的交付時間和進度 5．1本開發軟體交付的時間為_________年_________月_________日；5．2軟體開發分為_________個里程碑階段，每個里程碑階段的項目完成後，均應該依據本合同附件_________所列的檢測標准進行檢測和交付。甲方將按照本合同的第_________條規定進行付款。乙方開發軟體或引用的檢測標准不得低於_________（國家/行業/企業）的標准。其具體規格、檢測標准、階段和進度、交付時間與地點、付款方式等見附件_________。三、軟體開發1．開發自本合同簽訂之日起，乙方應盡力履行其在開發計劃中所規定的義務，按時完成並交付每一項里程碑，其質量標准應符合附件_________的規定。2．分包本合同項下的項目禁止轉包。如雙方同意，乙方可以將本合同項下的_________（項目名稱）等非主體項目分包給具有相應資質的第三方實施。違反本條規定的，乙方應依據本合同的相關規定承擔違約責任。3．項目管理（供選擇） 合同各方指派代表組成本信息系統開發管理小組，管理本軟體的開發。管理小組成員名單和通訊方式見附件_________。合同各方可以根據具體情況重新指定本方的管理小組的成員，但應當以書面方式通知另一方；如一方重新指定的小組成員涉及到本項目的重要方面，更換方應事先徵得對方的書面同意。另一方應及時審查更換方提出的書面建議，雙方在合理、善意、維護雙方利益的基礎上討論更換事宜。 4．信息與資料乙方有權根據本合同的規定和項目需要，向甲方了解有關情況，調閱有關資料，向有關職能人員調查、了解甲方現有的相關數據和資料，以對該軟體進行全面的研究和設計。甲方應予以積極配合，向乙方提供有關信息與資料，特別是有關甲方對開發軟體的功能和目標需求方面的信息和資料。如甲方對乙方完成本合同所需的甲方所有的信息和資料不予提供，則由甲方承擔不予提供的損害後果。5．需求與需求分析 5．1甲、乙雙方將根據上述第_________條中甲方為其業務開發軟體及其所需功能的描述和甲方所提供的資料與信息共同製作需求分析。甲方在提交有關需求說明、資料和信息時，可以就其中所涉及的軟體功能、目標、需求構成及相關技術問題向乙方咨詢或徵求意見，乙方應當及時予以解釋和答復。5．2乙方在獲取上述需求信息和資料後，應及時完成需求分析書。該需求分析書經甲方認可，並由甲、乙雙方簽字後作為本合同的附件。6．需求說明書、概要設計說明書和詳細設計說明書 6．1乙方在取得了甲方提供的必要的信息和資料後，將依據本合同所約定的軟體的功能、目標與需求分析書，在_________年_________月_________日之前完成需求說明書，在6．1乙方在取得了甲方提供的必要的信息和資料後，將依據本合同所約定的軟體的功能、目標與需求分析書，在 _________年_________月_________日之前完成概要設計說明書，在6．1乙方在取得了甲方提供的必要的信息和資料後，將依據本合同所約定的軟體的功能、目標與需求分析書，在_________年_________月_________日之前完成詳細設計說明書。以上三項完成後，均應提交甲方審核。甲方在收到上述文件後，對其中所描述軟體的適用性、需求性和應用性等進行審核。甲方應在6．1乙方在取得了甲方提供的必要的信息和資料後，將依據本合同所約定的軟體的功能、目標與需求分析書，在_________年_________月_________日之前完成需求說明書的審核，在6．1乙方在取得了甲方提供的必要的信息和資料後，將依據本合同所約定的軟體的功能、目標與需求分析書，在_________年_________月_________日之前完成概要設計說明書的審核，在6．1乙方在取得了甲方提供的必要的信息和資料後，將依據本合同所約定的軟體的功能、目標與需求分析書，在_________年_________月_________日之前完成詳細設計說明書的審核。如甲方認可上述文件後的，則在上述文件中簽字。如有異議，則以書面方式說明理由並提交乙方復審。如乙方認為不構成問題，則應向甲方予以解釋。確有問題的，乙方應及時予以修改並再次提交甲方審核。甲乙雙方將重復此程序，直至雙方一致認可簽字。6．2甲方對上述說明書的簽字認可，僅代表對上述說明書中開發軟體的適用性、需求性、可用性、等的審核。甲方並不對說明書中的技術問題進行審核。如說明書中出現任何與乙方設計相關的技術問題或技術調整，仍由乙方承擔責任。6．3如甲方未在約定的時間內完成本條款所規定的義務，乙方則可以相應順延交付時間。如該延時對乙方造成損失，甲方還應賠償乙方的損失。6．4上述需求說明書、概要設計說明書和詳細設計說明書經雙方簽字後，作為本合同的附件，與本合同具有同等效力。7．進度報告乙方應於每月/季度終了的20/_________工作日內，以書面形式向甲方提供項目階段進度報告，內容包括項目進度或里程碑計劃執行情況，已完成的軟體開發項目，有無遇到的困難和障礙，本項目的預期效果，人員配置情況，有無項目變更及變更情況或其它與本項目有關的甲方應該知道或甲方要求知道的情況。如有重大的問題或重要的變更發生，乙方應當在變更發生之日起7/_________工作日內向甲方做出書面報告。乙方應當在7/_________工作日內回復甲方在其它時間內提出的與本項目相關的詢問。如乙方違反本條的規定，應該承擔由此而引起的項目遲延和甲方不能及時付款或配合項目進行的後果。甲方在收到乙方的書面報告後，應當在7/_________工作日內回復乙方。8．第三方監理甲方有權聘請第三方作為本軟體開發的監理。如甲方指定了第三方作為甲方的監理，依甲方的授權，該監理享有與本合同中所約定的甲方同等的權利，以監理本項目的進行。監理方應擁有相應的資質並依法行使其監理職責，否則乙方有權拒絕接受監理。四、交付、領受與驗收1．交付1．1乙方應在進行每項交付前_________個工作日內，以書面方式通知甲方。甲方應當在接到通知後的_________個工作日內安排接受交付。乙方在交付前應根據附件_________所列的檢測標准對該交付件進行測試，以確認其符合本合同的規定。1．2如由於甲方的原因而導致交付不能按照規定的時間進行，乙方將按延期時間順延交付。如因延期交付而導致乙方損失，甲方應賠償乙方的實際損失。如甲方無正當理由不接受交付，則視為乙方已經交付，甲方應當按照約定付款，甲、乙雙方對此另有約定的除外。2．交付內容 2．1乙方應按照合同及其附件所約定的內容進行交付，所交付的文檔與文件應當是電子版式和可供人閱讀的。具體交付內容見附件 。2．2如由於甲方運行、檢測不當或其它原因而導致所交付項目存在故障或問題，經甲方要求，乙方應在_________個工作日內幫助處理此項故障或問題，由此而發生的費用由甲方承擔。3．領受 甲方在領受了上述交付件後，應立即對該交付件進行測試和評估，以確認其是否符合開發軟體的功能和規格。甲方應在_________個工作日內，向乙方提交書面說明以表示接受該交付件。如有缺陷，應遞交缺陷說明及指明應改進的部分，乙方應立即糾正該缺陷，並再次進行測試和評估。甲方應於_________個工作日內再次檢驗並向乙方出具書面領受文件或遞交缺陷報告。甲、乙雙方將重復此項程序直至甲方領受，但重復此項程序的次數最多不得超過_________次，超過約定次數甲方可解除合同。4．驗收4．1自軟體交付通過之日起，甲方擁有_________天的試運行權利。4．2如由於乙方原因，軟體在試運行期間出現故障或問題，乙方應及時排除該方面的故障或問題，所引起的相關費用由乙方承擔。4．3如由於甲方原因，導致軟體在試運行期間出現故障或問題，甲方可委託乙方排除該方面的故障或問題，所引起的相關費用由甲方承擔。 4．4乙方應在合理的期限內排除故障或處理問題。如以上故障或問題影響軟體基本功能和目標的實現，且排除故障或處理問題的時間超過_________個工作日，則視為乙方交付違約，除非上述故障和問題是由甲方引起的。5．系統驗收5．1軟體試運行完成後，甲方應及時按規定對該軟體進行系統驗收。乙方應以書面形式向甲方遞交驗收通知書，甲方在收到驗收通知書的_________個工作日內，安排具體日期，由甲、乙雙方按照本合同的規定完成軟體系統驗收。 5．2如屬於乙方原因致使軟體未通過系統驗收，乙方應排除故障，並承擔相關費用，同時延長試運行期限_________個工作日，直至軟體系統完全符合驗收標准。5．3如屬於甲方原因致使軟體未通過系統驗收，如屬甲方原有計算機系統故障原因，甲方應在合理時間內排除故障，再進行驗收。如繫上述故障之外的原因，除因本合同規定的不可抗力外，甲方未能在規定的時間內完成驗收，乙方有權以其認為合理的方式進行單方面驗收，並將驗收報告提交甲方，即視為軟體系統驗收已經通過。乙方在進行單方面驗收時，甲方應提供驗收便利。如甲方在乙方提出單方面驗收後的_________個工作日內不提供驗收便利，則視為該系統已經通過驗收。五、知識產權和使用權 1．知識產權_________擁有開發軟體的知識產權。另一方非經對方同意，不得以任何方式向第三方披露、轉讓和許可有關的技術成果、計算機軟體、技術訣竅、秘密信息、技術資料和文件。除本研發工作需要之外，未得到_________的書面許可，_________不得以任何方式商業性地利用上述資料和技術。如_________違反本條的規定，除立即停止違約行為外，還應支付違約_________。2．使用權（如知識產權歸一方所有，需訂立本款） 對軟體具有使用權。本使用權的使用范圍為：（總公司、分支機構）。 3．許可權（如知識產權歸一方所有，需訂立本款） 對 所許可的使用權軟體 向第三方許可的權利。除本合同另有規定外， 許可 使用軟體或相關任何知識產權，並不表示 已經從 獲得其向第三人許可使用該項權利的權利。4．甲方在使用乙方提供的屬於第三方軟體時，應當依照乙方與第三方對該軟體使用的約定進行。乙方應將該約定的書面文件的復印件交甲方參閱。 5．本合同項下雙方的任何權利和義務不因合同雙方發生收購、兼並、重組、分立而發生變化。如發生上述情形之一，則本合同項下的權利和義務隨之轉移至收購、兼並、重組或分立之單位。如甲、乙雙方在本合同項下的各項權利和義務由甲、乙雙方之分立單位分別承受的，則甲、乙雙方與甲、乙雙方之分立單位分別享有和承擔相關權利和義務。 k

『貳』 軟體許可協議怎麼寫

用戶許可協議

一、軟體使用協議
本協議是用戶 (自然人、法人或社會團體)與XXXX公司之間關於「XXXX」軟體產品（以下

簡稱「本軟體產品」）的法律協議。一旦安裝、復制或以其他方式使用本軟體產品，即表示同意接受協議各項條件的約束。如果用戶

不同意協議的條件，請不要使用本軟體產品。

二、軟體產品保護條款
1）本軟體產品之著作權及其它知識產權等相關權利或利益（包括但不限於現已取得或未來可取得之著作權、專利權、商標權、

營業秘密等）皆為XXXX公司所有。本軟體產品受中華人民共和國版權法及國際版權條約和其他知識產權法及條約的保護

。用戶僅獲得本軟體產品的非排他性使用權。
2）用戶不得：刪除本軟體及其他副本上一切關於版權的信息；對本軟體進行反向工程，如反匯編、反編譯等；
3）本軟體產品以現狀方式提供，XXXX公司不保證本軟體產品能夠或不能夠完全滿足用戶需求，在用戶手冊、幫助

文件、使用說明書等軟體文檔中的介紹性內容僅供用戶參考，不得理解為對用戶所做的任何承諾。XXXX有限公司保留對軟體

版本進行升級，對功能、內容、結構、界面、運行方式等進行修改或自動更新的權利。
4）為了更好地服務於用戶，或為了向用戶提供具有個性的信息內容的需要，本軟體產品可能會收集、傳播某些信息，但XXXX公司承諾不向未經授權的第三方提供此類信息，以保護用戶隱私。
5）使用本軟體產品由用戶自己承擔風險，在適用法律允許的最大范圍內，XXXX公司在任何情況下不就因使用或不

能使用本軟體產品所發生的特殊的、意外的、非直接或間接的損失承擔賠償責任。即使已事先被告知該損害發生的可能性。
6）XXXX公司定義的信息內容包括：文字、軟體、聲音；本公司為用戶提供的商業信息，所有這些內容受版權、商

標權、和其它知識產權和所有權法律的保護。所以，用戶只能在本公司授權下才能使用這些內容，而不能擅自復制、修改、編撰這些

內容、或創造與內容有關的衍生產品。
7）如果您未遵守本協議的任何一項條款，XXXX公司有權立即終止本協議，並保留通過法律手段追究責任。

三、XXXX公司具有對以上各項條款內容的最終解釋權和修改權。如用戶對XXXX公司的解釋或修改有異議，

應當立即停止使用本軟體產品。用戶繼續使用本軟體產品的行為將被視為對XXXX公司的解釋或修改的接受。

四、因本協議所發生的糾紛，雙方同意按照中華人民共和國法律，由XXXX公司所在地的有管轄權的法院管轄。

XXXX公司

『叄』 軟體知識產權的歸屬怎麼寫

1、軟體著作權屬於軟體開發者，即屬於實際組織開發、直接進行開發，並對開發完成的軟體承擔責任的法人或者其他組織；或者依靠自己具有的條件獨立完成軟體開發，並對軟體承擔責任的自然人。
2、合作開發的軟體，其著作權的歸屬由合作開發者簽訂書面合同約定。無書面合同或者合同未作明確約定，合作開發的軟體可以分割使用的，開發者對各自開發的部分可以單獨享有著作權；合作開發的軟體不能分割使用的，其著作權由各合作開發者共同享有。
3、接受他人委託開發的軟體，其著作權的歸屬由委託人與受託人簽訂書面合同約定；無書面合同或者合同未作明確約定的，其著作權由受託人享有。
4、由國家機關下達任務開發的軟體，著作權的歸屬與行使由項目任務書或者合同規定；項目任務書或者合同中未作明確規定的，軟體著作權由接受任務的法人或者其他組織享有。
5、自然人在法人或者其他組織中任職期間所開發的軟體有下列情形之一的，該軟體著作權由該法人或者其他組織享有：
（一）針對本職工作中明確指定的開發目標所開發的軟體；
（二）開發的軟體是從事本職工作活動所預見的結果或者自然的結果；
（三）主要使用了法人或者其他組織的資金、專用設備、未公開的專門信息等物質技術條件所開發並由法人或者其他組織承擔責任的軟體。

『肆』 如何申請開發軟體知識產權保護

這塊不大好做，只能做個登記。

『伍』 軟體開發中涉及的知識產權問題

那你就去注冊知識產品，現在國家對知識產權保護很重視，誰申請到了誰版就受保護，如果權並沒有簽約制定這個歸前公司所有，你可以去申請你的專利，這樣就是歸你個人所有，前公司也是不可以用的，如果對方已經申請下來了，那就麻煩一些了

『陸』 計算機軟體開發合同的知識產權歸屬,在什麼情況下才可以認定為技術開發合同

具體要合同怎麼簽。
如果是基於乙方開發平台或者應用的，甲方只擁有上層部分的軟體知識產權。
如果是基於開源免費平台，從零開始的，甲方擁有完全知識產權。

『柒』 軟體合同知識產權方面條款的制訂

我理解，貴抄公司法律顧襲問之所以將「因履行本合同所產生的成果及其相關的知識產權、使用權及轉讓權均歸甲方所有」改變為「乙方因履行本合同所開發軟體的著作權歸甲方享有」，關鍵在於其僅僅從單層面的法律角度去考慮問題，而不是從貴公司利益保障這個服務角度去考慮問題，他認識到了「計算機軟體」在現行法律框架內是歸屬於著作權保護范疇，但他忽略了計算機軟體實際上涉及到許多方面的權利（正如樓主認識到的），更要命的是，他忽略了他是公司最大權益化的爭取者和實施者。
同意的觀點，你們的新法律顧問所做的修改確實不利於保護你們的權利。
感謝各位,iknow

『捌』 開放源代碼軟體的常見協議

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