常見開源協定（整理）

開源在今天的軟體業已經很普遍,但開源是否意味着使用者可以對開源後的代碼為所欲為呢?答案是否定的.開源運動同樣有自己的遊戲規則和道德準則.不遵行這些規則不但損害開源運動的健康發展,也會對違規者造成名譽和市場上的損失,更可能陷入法律糾紛和賠償.

　　1. Contributors 和 Recipients

　 　Contributors

指的是對某個開源軟體或項目提供了代碼(包括最初的或者修改過的)釋出的人或者實體(團隊、公司、組織等),Contributors

按照參與某個軟體開源的時間先後,可以分為 an initial Contributor 和 subsequent Contributors

.

　　Recipients指的是開源軟體或項目的擷取者,顯然,subsequent Contributors 也屬于

Recipients之列.

　　2. Source Code 和 Object

Code

　　Source Code 指的是各種語言寫成的源代碼,通過Source Code,結合文檔,

可以了解到整個軟體的體系結構及具體到某個功能函數的實作方法等.

　　Object Code 指的是Source Code

經過編譯之後,生成的類似于“類庫”一樣的,提供各種接口供他人使用的目标碼,按我的了解,它就是像常見的DLL、ActiveX、OCX控件性質的東西.(不知道這樣了解對不對)

　　厘清楚這兩個概念的目的在于,有些開源,隻釋出Object

Code ,當然,大多數釋出的是Source Code.很多協定也對 “你釋出的是哪種Code的時候應該怎樣”,有着明确的限制.

　　3. Derivative Module 和 Separate

Module

　　Derivative Module

指的是,依托或包含“最初的”或者“從别人處擷取的”開源代碼而産生的代碼,是原“源代碼”的增強(不等于增加)、改善和延續的子產品,意為“衍生子產品”.

　　Separate

指的是,參考或借助原“源代碼”,開發出的獨立的,不包含、不依賴于原“源代碼子產品”,意為“獨立的子產品”.了解這兩個概念的目的在于,很多協定對涉及到商業釋出的時候,會有哪些是衍生的,哪些是獨立的,有着明确的商業釋出規定.

　　現今存在的開源協定很多,而經過Open

Source Initiative組織通過準許的開源協定目前有58種.我們在常見的開源協定如BSD, GPL,

LGPL,MIT等都是OSI準許的協定.如果要開源自己的代碼,最好也是選擇這些被準許的開源協定.

參考連結：