# 版權分配和所有權
有三種處理自由代碼和文檔版權所有權的方法,許多人為此做出了貢獻。第一種是完全無視版權的問題(我不建議如此)。第二種方法是從項目中工作的每個人那里收集一個*貢獻者許可證協議*(*CLA*),明確項目對使用個人貢獻的權利。這通常對大多數項目已經足夠了,更好的是在一些司法權中,CLA是可以通過email發送的。第三種方法是從貢獻者那里獲得真正的版權協議,這樣項目(例如一些法律實體,通常是非盈利)就是所有東西的版權所有者。這通常是無懈可擊的方法,但也是貢獻者的負擔;只有少數項目堅持如此。
請注意,即使在集中式的版權所有權時,代碼[[30](#)]還是自由的,因為開源許可證并沒有給版權持有者可以將所有代碼的拷貝收回所有的權利。所以即使作為法律實體的項目突然轉向開始將所有的代碼使用限制許可證發布,也不會給公共社區帶來什么問題。其他開發者可以簡單的根據最新的代碼拷貝開始一個分叉,并當作沒發生任何事情一樣繼續。因為他們知道他們可以這樣做,大多數被問及簽署CLA或版權協議時會非常合作。
### 無為而治
大多數項目從來沒有從他們的貢獻者那里收集過CLA或版權協議。相反,只要代碼是合理清除,而且貢獻者愿意將其組合進項目,他們就會接受代碼。
在通常情況下,這是正常的。但是偶爾會有人決定因版權侵害而訴訟,聲稱他們是問題代碼的所有者,而且他們從沒有同意這些代碼由項目使用開源許可證分發。例如,SCO團隊向Linux團隊這樣做的,細節見[http://en.wikipedia.org/wiki/SCO-Linux_controversies](http://en.wikipedia.org/wiki/SCO-Linux_controversies)。當這些發生時,項目沒有文檔說明貢獻者正式的賦予使用這些代碼的權利,可能會導致一些法律辯護。
### 貢獻者許可證協議
CLA可能是在安全性和便利性之間提供了最好的折衷。一個CLA通常是一個發送給開發者填寫并發回項目的電子表格。在大多數司法中,郵件提交已經足夠。或許需要安全電子簽名;可以咨詢律師找出對你的項目最合適的方法。
大多數項目使用兩個些許不同的CLA,一個針對個人,一個針對公司貢獻者。但是在兩種類型中,核心的語言是相同的:貢獻者賦予項目*"...永久的、全世界的、非獨占的、免費的、特許自有、不能取消的版權許可證,可以用于重新制作、準備衍生作品、公開顯示、公開操作、發放從屬證書和分發這些貢獻和此類衍生作品。"*再次強調,你應當有一個律師確認CLA,但是如果你能了解所有這些程序,那樣會很好。
當你從貢獻者那里請求CLA時,請確認強調你*不是*要求真正的版權授予。實際上,許多CLA使用這些語句來提醒讀者:
> *這僅僅是一個許可證協議;它不會轉移版權所有權,也不會改變因任何目的使用自己貢獻的權利。*
下面是一些例子:
-
個人貢獻者CLA:
-
[http://apache.org/licenses/icla.txt](http://apache.org/licenses/icla.txt)
-
[http://code.google.com/legal/individual-cla-v1.0.html](http://code.google.com/legal/individual-cla-v1.0.html)
-
公司貢獻者CLA:
-
[http://apache.org/licenses/cla-corporate.txt](http://apache.org/licenses/cla-corporate.txt)
-
[http://code.google.com/legal/corporate-cla-v1.0.html](http://code.google.com/legal/corporate-cla-v1.0.html)
### 版權轉移
版權轉移的含義是貢獻者將自己的貢獻賦予給項目版權所有權。理想情況下,需要書面完成并傳真或郵寄給項目。
一些項目堅持完全的協議,因為如果開源許可證的條款需要強制時,一個單獨的法律實體擁有整個代碼基的版權會非常有用。如果沒有單個實體有這樣的權利,所有貢獻者需要合作,但問題發生時可能某人沒有時間或無法找到。
不同的組織對于收集授權的嚴苛程度不同。有一些僅僅是某個貢獻者在公共郵件列表中的簡單非正式陳述—類似“我這里將我的在該項目的代碼授權,使用其余代碼相同的許可證條款。 ”至少有一個我交流過的律師認為這樣已經足夠,大體推測,可能是因為它發生在一個版權授權已經非常普通和預期的方式,而且因為它代表了項目一方對于確保開發者真正意圖的*誠意*努力。另一方面,自由軟件基金會則進入對立的極端:他們要求貢獻者物理上簽署并郵寄一份文件,包含版權授權的正式描述,有時僅針對一份貢獻,有時針對當前和未來的貢獻。如果開發者被雇傭,FSF也會要求雇員簽署這個東西。
FSF的偏執狂可理解的。如果某人違反了GPL關于將他們的軟件組合到私有程序的條款,FSF會需要與之在法庭上斗爭,他們希望他們的版權在這種情況發生時可以無懈可擊。因為FSF是許多流行軟件的持有者,他們認為這是真實可能的。無論你的組織是否有只有你所決定的需要類似的小心謹慎,請咨詢律師。通常情況下,除非一些特別的原因需要你的項目擁有完全的版權授權,你可以直接采用CLA;他們對每個人都很簡單。
[[30](#)] 之后我使用的“代碼”指的是代碼和文檔。
- 前言
- 為什么寫這本書?
- 誰應該讀本書?
- 資料來源
- 致謝
- 免責聲明
- 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. 版權