# 許可證的方面
盡管有許多不同的自由軟件許可證,但在許多重要的方面所說的是同一件事:任何人可以修改代碼,也就是任何人可以再次分發其原始和修改的形式,而版權所有者和作者不做任何保障(考慮到人們會在不知情的情況下運行修改的版本,免責非常重要)。不同許可證的區別經常出現在這些問題上:
私有許可證的兼容性
有一些自由許可證允許覆蓋的代碼用于私有軟件。這不會影響私有程序的許可證條款:它還是私有軟件,它僅僅是包含了一些非私有的源。Apache許可證、X Consortium許可證、BSD樣式的許可證以及MIT樣式的許可證都是私有兼容的許可證。
與其他自由許可證的兼容性
大多數自由許可證與其他兼容,意味著某個許可證下的代碼可以與其他的代碼合并,使用任意一種許可證分發也不會違反另外一種許可證的條款。主要的例外是GNU GPL,它要求使用GPL化的代碼則必須按照GPL分發,并不得增加任何GPL所要求的更多限制。GPL只與某些自由許可證兼容。本章后面的[the section called “GPL和許可證兼容性”](# "GPL和許可證兼容性")將會詳細討論這些細節。
榮譽的強制性
一些自由許可證強制對于所覆蓋代碼的任意使用,必須伴隨一個已指明了放置和顯示方式的提示,給予代碼的作者或版權擁有者榮譽。這些許可證仍然是私有兼容的:他們并不要求衍生的作品是自由的,僅僅要求給予自由代碼一份榮譽。
商標保護
強制榮譽的一個變種。商標保護許可證指明在未經預先書面許可前,原始軟件的名稱(或者其版權所有者,或他們的機構等等)*不能*被用于衍生的作品中。盡管榮譽強制堅持使用特定的名字,而商標保護保證其不被使用,但他們只是相同目的不同表達方式:原始代碼的名聲必須保存和傳遞,但不要因為關聯而玷污。
"藝術完整性"保護
有一些許可證(例如著名的Perl編程語言實現所使用的藝術許可證,以及Donald Knuth的TeX許可證)要求分發時必須明確區分代碼的原始版本和所有的修改。他們與其他自由許可證在實質上允許同樣的自由,但是提出了特定要求,可以輕松的確認原始代碼的完整。除了制作這些許可證的特定程序,并沒有太多這類許可證的使用,所以將不會在本章討論;它們的出現僅出于完全性的考慮。
大多數這類強制不是互斥的,某些許可證會包含多個。他們之間相同的線索是在接受者那里設置要求,交換接受者使用和/或發布代碼的權利。例如,一些項目希望他們的名稱和名聲能夠隨著代碼傳播,并且也值得放置額外的榮譽或商標條款;取決于其難度,這種負擔會導致某些用戶選擇較少要求的包。
- 前言
- 為什么寫這本書?
- 誰應該讀本書?
- 資料來源
- 致謝
- 免責聲明
- 1. 介紹
- 歷史
- 現狀
- 2. 起步
- 從你擁有的開始
- 選擇許可證并應用
- 設置風格
- 通告
- 3. 技術基礎設施
- 一個項目需要什么
- 郵件列表
- 版本控制
- Bug跟蹤
- IRC / 實時聊天系統
- RSS供稿
- Wikis
- 網站
- 4. 社會和政治的基礎架構
- 慈善獨裁者
- 共識為基礎的民主(Consensus-based Democracy)
- 寫下所有的內容
- 5. 金錢
- 參與的類型
- 長期雇傭
- 作為一些個體出現,而不是一個整體
- 公開你的動機
- 錢不能讓你可愛
- 契約
- 資助非編程活動
- 市場營銷
- 6. 交流
- 人如其文
- 避免常見的陷阱
- 刺兒頭
- 處理成長
- Bug跟蹤系統中無對話
- 公開性
- 7. 打包、發布和日常開發
- 版本號
- 發布分支
- 穩定發布版本
- 打包
- 測試和發布
- 維護多發布線
- 發布和日常開發
- 8. 管理志愿者
- 從志愿者中獲取最多
- 像分擔技術任務一樣分擔管理任務
- 轉化
- 提交者
- 榮譽
- 分叉
- 9. 許可證,版權和專利
- 術語
- 許可證的方面
- GPL和許可證兼容性
- 選擇一個許可證
- 版權分配和所有權
- 雙許可證模式
- 專利
- 深入資源
- A. 自由版本控制系統
- B. 自由Bug跟蹤系統
- C. 為什么我要關注車棚的顏色?
- D. 報告bug的樣例指導
- E. 版權