開源協議在再發布過程中的授權總結

2021-07-27 20:06:50 字數 3025 閱讀 2262

大部分人都希望作品能夠被多數人分享查閱。這樣不僅提高自己業界的知名度,同時也方便了需要的人為開源做出了貢獻。但是**一旦被貼出來,任何人都可以看到並獲取,之後發生的事情你就無法控制了。所以為了公開分享你的**,同時又讓你對**保留一定權利,在作品中宣告乙個許可協議是非常有必要的。有協議和沒宣告協議的裸**是有非常重要區別的,一般作品當中沒宣告協議的預設為copy right的,也就是版權保留。此種情況表明他人沒有任何授權,不得複製分發修改使用等等。有了協議的宣告,在未來你的維權上面會方便很多,讓你的作品在分享的同時保留了自身的一些權利。

license是軟體的授權許可,裡面詳盡表述了你獲得**後擁有的權利,可以對別人的作品進行何種操作,何種操作又是被禁止的。

軟體協議可分為開源和商業。

對於商業協議,或者叫法律宣告、許可協議,每個軟體會有自己的一套行文,由軟體作者或專門律師撰寫。因為涉及到以後侵權打官司這種事情,這種商業條款的行文是非常嚴謹而講究的,讀起來很晦澀難懂。

對於開源協議,要知道開源不等於免費,也不等於沒有約束。雖然相對商業協議要更加簡明,但對於很多人來說還是像在看天書一樣。

本文旨在從開源軟體再發布過程使用許可權的角度入手,總結各個常見開源協議的異同,方便理解。

現今存在的開源協議很多,而經過open source initiative 組織通過批准的開源協議目前有60多種( )。我們在常見的開源協議如bsd, gpl, lgpl,mit等都是osi批准的協議。

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

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

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

apache licence是著名的非盈利開源組織apache採用的協議。該協議和bsd類似,同樣鼓勵**共享和尊重原作者的著作權,同樣允許**修改,再發布(作為開源或商業軟體)。需要滿足的條件也和bsd類似:

我們很熟悉的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一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制。也就是說,你必須在你的發行版裡包含原許可協議的宣告,無論你是以二進位制發布的還是以源**發布的。

gpl協議、lgpl協議與bsd協議的法律區別。

簡而言之,gpl協議就是乙個開放源**協議,軟體的初始開發者使用了gpl協議並公開軟體的源程式後,後續使用該軟體源程式開發軟體者亦應當根據gpl協議把自己編寫的源程式進行公開。gpl協議要求的關鍵在於開放源程式,但並不排斥軟體作者向使用者收費。雖然如此,很多大公司對gpl協議還是又愛又恨,愛的是這個協議項下的軟體歷經眾多程式設計師千錘百鍊的修改,已經非常成熟完善,恨的是必須開放自己後續的源程式,導致競爭對手也可以根據自己修改的源程式開發競爭產品。

正因大公司對gpl協議在商業上存在顧慮,因此,另兩種協議被採用的更多,第一種是lgpl(亦稱gpl v2)協議,可以翻譯為更寬鬆的gpl協議。與gpl協議的區別為,後者如果只是對lgpl軟體的程式庫的程式進行呼叫而不是包含其源**時,相關的源程式無需開源。呼叫和包含的區別類似在網際網路網網頁上對他人網頁內容的引用:如果把他人的內容全部或部分複製到自己的網頁上,就類似包含,如果只是貼乙個他人網頁的**鏈結而不引用內容,就類似呼叫。有了這個協議,很多大公司就可以把很多自己後續開發內容的源程式隱藏起來。

第二種是bsd協議(類似的還有mit協議)。bsd協議鼓勵軟體的作者公開自己後續開發的源**,但不強求。在bsd協議項下開發的軟體,原始的源程式是開放源**的,但使用者修改以後,可以自行選擇發布源程式或者二進位制程式(即目標程式),當然,使用者有義務把自己原來使用的源程式與bsd協議在軟體對外發布時一併發布。因為比較靈活,所以bsd深受大公司的歡迎。

如何為你的**選擇乙個開源協議 - 劉哇勇的部落格

重要開源協議的比較(bsd,apache,gpl,lgpl,mit) – techbirds在路上

游雲庭律師的回答 - 主流開源協議之間有何異同? - 知乎

choose a license

ClickOnce發布過程中的學習

簡單普通的發布過程網上可以搜到一大把,但是針對複雜專案的發布需要進一步加入一些東西。目前要發布在公司區域網,先在iis上新建乙個 配置好物理路徑d piis ip 192.12 埠 8016。發布其他選項跟 在iis上發布 一樣設定,選項 設定中配置如下圖 先發布版本1,在d piis 中找到發布的...

在測試的過程中的效率

在測試的過程中,效率低下是乙個重要問題,經常表現在 bug重 現重複提交 發現bug,但描述資訊不詳細 存在不量的bug不被發現 這主要是因為沒有寫測試用例,分工不詳所造成。沒有寫測試用例。每個人都自己亂點,碰運氣式的測試。結果就是,潛在大量的bug不被發現,小量的bug被重 現 測試人員沒有範圍。...

動態sql在儲存過程中的實現

這種情況下,如何轉為儲存過程呢?以上面的兩個動態為例,在儲存過程中實現如下 create or replace procedure my procedure1 tablename in varchar2,studentname in varchar2,my cursor1 out my proced...