頂 翻譯的不錯哦!
GNU寬通用公共許可證是一種GPL更加寬松的版本?;贚GPL授權的組件可能關聯到程序,但是程序本身并不必開源或者基于GPL或LGPL授權,換句話說,LGPL和GPL相似,因此任何派生作品也必須開源。
王政
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
MIT
亦被稱為X11協議。該協議相對寬松,對于使用該協議的項目,協議的遵循者必須自動放棄對該項目代碼發布權以及使用權的私有,而賦予公眾相應權利。因此,遵循MIT協議的代碼或許被會被引用在一些沒有聲明遵循某項協議的特定代碼中。此外,MIT協議與GPL協議兼容,所以你完全可以用MIT協議下的代碼來開發GPL協議的應用。
王政
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
BSD3
協議有點松,有點松……該協議相對寬松,對于使用該協議的項目,協議的遵循者必須自動放棄對該項目代碼發布權以及使用權的私有,而賦予公眾相應權利。此外,項目中任何以二進制形式發布的代碼(譯者注:貌似.bin文件之類的),也需要在許可文檔中聲明該協議。那么,該協議與MIT協議的區別在哪里呢?當該協議的標的物(譯者注:一般,這里的“標的物”是聲明使用該協議的代碼,為了保證嚴謹性,在此進行注釋)被其他人使用時,他們不可以用該標的物的所有權人的名字進行商業宣傳。例如,如果我寫了一段遵循該協議的代碼,而你把他用著自己的應用里面,你是不可以用哥哥我的名字去做宣傳的,除非經過我的同意。最后,BSD3協議也是和GPL兼容的。
好吧,其實還有很多開源協議本文沒有介紹,但是以上協議應該是最受大家關注的。
圖片版權所有:opensourceway.
erichua23
翻譯于 9天前
0人頂
頂 翻譯的不錯哦!
需要注意的一點是 Creative Commons許可證并非設計來于軟件的. 所有的 Creative Commons許可證都是為"創造性工作"制定的, 例如音頻, 圖像, 視頻和文字. 制定 Creative Commons 的組織他們自己也不推薦將 Creative Commons許可證用于軟件, 應該在軟件中使用專門為軟件制定的許可證, 通常也就是上文討論的四種.
erichua23
翻譯于 9天前
0人頂
頂 翻譯的不錯哦!
因此, 你應該選擇哪個許可證呢? 這點大部分由你想別人怎么使用你的代碼決定. 因為LGPL, MIT 和 BSD3都和GPL完全兼容, 這還不是最需要關注的. 如果你想所有你軟件的修改版本都只被用于開源軟件, 那么你應該選擇GPL. 如果你的代碼是設計成一個不需要修改而可以直接引入別人的項目使用的組件, 那么你可能會考慮LGPL. 否則, MIT和BSD3許可證時比較通常的選擇. 個人比較趨向于喜好MIT許可證, 而商業上可能更加的偏向于喜好BSD3許可證以保證他們的公司名稱不會被未授權的使用.
erichua23
翻譯于 9天前
0人頂
頂 翻譯的不錯哦!
為了幫助你做決定, 看一下這些流行的開源軟件項目都使用了些什么協議:
jQuery: MIT license
YUI: BSD3 license
Dojo Toolkit: dual-licenced under BSD3 and Academic Free License
Backbone: MIT license
erichua23
翻譯于 9天前
0人頂
頂 翻譯的不錯哦!
另外一個選擇就是直接把你的代碼發布為 public domain(公有領域), 在 public domain中的代碼沒有版權擁有者, 這些代碼可以完全隨意使用. 如果你沒有打算保持你對代碼的控制全 或者 你只是想向世界分享你的代碼而不打算持續開發它, 那就可以考慮一下把代碼發布到 public domain.
erichua23
翻譯于 9天前
0人頂
頂 翻譯的不錯哦!
想進一步了解許可證與它們相關的法律問題以及這些許可證如何工作, 請閱讀 David Bushell的 Understanding Copyright and Licenses.
erichua23
翻譯于 9天前
0人頂
頂 翻譯的不錯哦!
代碼組織
決定在你的開源項目中使用何種許可證以后, 這幾乎是時候把你的代碼放出來了. 但是在這之前, 你得先看看代碼是怎么組織的. 不是所有代碼都會得到大家的貢獻. 如果一個潛在的貢獻者無法通讀你的代碼, 那么他非??赡芤矝]法做出任何貢獻. 在你分享你的代碼給公眾之前, 你組織代碼的方式, 包括文件目錄結構, 代碼風格都是需要認真考慮的因素. 別隨意把你胡亂寫的代碼扔出來. 多花點時間考慮別人可能會怎么閱讀你的代碼以及他們在這過程中可能會遇到什么問題.
原文轉自:http://www.anti-gravitydesign.com