怎樣才有資格被稱為開源軟體薦

發現國內不少軟體都開源了。但很奇怪，他們都有自己相同一套的軟體版權許可協議。這些軟體許可協議跟開源本身的精神是有衝突的。舉個例子：
    摘自Discuz!NT 裡的許可協議：禁止在 Discuz!NT 的整體或任何部分基礎上以發展任何派生版本、修改版本或第三方版本用於重新分發。 與其它條款無牴觸的前提下，允許以自用為目的的進行進行二次開發或整合，但同樣受前文第3項約束和限制，即保留Discuz!NT名稱與連結。
    以上規定顯然是違背開源精神的，通過OSI認證的許可協議：如GNU GPL、MPL、BSD等許可協議裡面都明確規定可以修改版本或第三方版本用於重新分發的權利，但要保證你釋出的系統也必須開源，包括你修改的地方都要註釋清楚。著名的開源軟體SUGARCRM就有幾個較好的派生版本如：vtigerCRM、C3CRM。
    這些自搞一套許可協議的嚴格上都不能算是開源軟體，開源軟體不光光是軟體原始碼的開放，除了這些，還要說明遵守那種許可協議(OSI認可)，還要包括開源文件（使用手冊和開發手冊）。那麼怎樣才有資格被稱為開源軟體？Eric Steven Raymond給出如下解釋：
    根據許可的目的，我們可以區別許可證賦予你的各種不同權利。複製和再發布的權利，使用的權利，為個人目的修改的權利，釋出修改後的作品的權利。一個許可證可能會對這些權利加上一些限制或給出一些附加條件。opensource.org就是各種對軟體“開源”或“自由”思考的結果。該站點許可證的約束條款包括：
    1. 無限制的拷貝權。
    2. 無限制的使用權。
    3. 無限制的針對個人使用目的而修改的權利。
    這些指導方針保證修改後的二進位制程式碼的再發布權；這與那些要求可以無障礙的取用軟體的發行商的需求相吻合。這個做法使得軟體的作者們可以要求修改的原始原始碼採取把原有程式碼加上補丁程式的方式來再發布，這樣就保全了作者們的原意同時又可以讓他們“審查”其他人對專案的改進工作。
    OSD（開放原始碼定義）是對“OSI開源軟體認證”證書的法律定義，實際上她和人們曾經提出的各種關於“自由軟體”的定義一樣好。所有標準的許可證協議（如 MIT、BSD、Artistic、GPL和LGPL協議）都與該提法一致（然而有時候，比如GPL，有更多的限制條款，在選擇這些許可證時請仔細理解）。
    值得注意的是有些只允許非商業用途的許可證並沒有資格被成為開源許可證，儘管他們標榜自己是“GPL”或者其他典型的許可證。這種許可證對特殊的擁有者，或者對個人和小組有著歧視。他們對通過光碟渠道再發布的做法以及其他商業化的推廣開源軟體的嘗試做出種種限制，從而把事情搞的非常複雜。
   
   部落格園的開源專案NBear做的非常不錯，完全符合開源精神，是一個地地道道的開源專案，NBear採用的是BSD的開源協議，專案也做得非常成功，為中國的開源專案的楷模。主要有幾點非常值得國內的開源專案學習：
    1、建立開源社群：建立開源社群內容包括：專案概況、軟體下載（原始碼CVSSVN）、文件(wiki)、BUG提交、FAQ、互動平臺。讓更多的人可以參與進來，這也是開源軟體的開發模式。NBear的官方網站（[url]http://nbear.org/[/url]）都包含這些非常重要的內容，希望大家支援NBear.
    2、軟體許可協議: NBear採用的是BSD的開源協議,找一個符合自己專案的開源許可協議。如gpl、mpl、mit等等。這些許可協議可以幫助你來對付一些侵權行為的組織和人。
    3、軟體服務模式：NBear專案也有一個連結是贊助|Donate NBear ，這也是為了專案生存的經濟來源。我也看到了NBear的領導者Teddy`s Knowledge Base的公告裡有一段“承接有償技術諮詢及專案外包”。