寫開源軟體之前請先確認你知道你的版權權利

誰擁有那些僱傭工作的程式碼？可能是你哦

　　你應該知道當你擁有版權時，你的老闆或者諮詢客戶也擁有這份版權。如果你寫的程式碼屬於你老闆，歸根到底，它不是屬於你的。如果它不是你的，那麼你就沒有權利去給開源專案授權。所以我們這樣假設，僱傭或自由職業都自動地屬於僱傭行為。

　　比如，你在工作之餘正在開發的那個小專案，完全屬於你自己嗎？或許屬於你，但就像Daniel A.Tysver,一個Beck & Tysver的合夥人，在BitLaw寫到：

當招聘程式設計師時，軟體開發商應該密切關注版權所有權問題。在大多數情況下，如果專案是付了薪水的員工做的，那麼這個專案就屬於僱傭行為下的專案。所以，軟 件開發商就會認為，這個被員工開發的軟體的作者和所有權就理所應當的屬於開發商。不過精明的開發商會讓程式設計師簽署一份協議，讓他們同意授權他們開發出的軟 件給開發商。開發商這麼謹慎是因為決定一個員工是不是合法需要分析很多因素，並且在極個別情況下會引起意想不到的結果。另外，僱傭期間的工作需要在員工在 僱傭期間完成。通常，程式設計師開發的專案都會在僱傭期間完成，但這也是一個模糊的概念，我們最好不做以此做條件。

現在，加入開源貢獻

　　這些關注點同樣適用於開源專案。大多數專案具有某種版權轉讓協議（CAAs）或版權許可協議（CLAs），你必須在你寫的程式碼提交到專案之前簽署。在CAAs，你轉讓你的版權給一個公司或組織；在CLAs，你將一個廣泛的使用你的程式碼的許可給予該團體。

　　雖然一些開源組織認為，例如Bradley Kuhn的軟體自由保護組織，不要其中任何一個開源軟體的版權許可，幾乎所有的專案都有它們。

　　而且它們會經常帶來麻煩。

　　舉個例子，最近的一個關於版權的煩惱，是在GnuTLS專案中，那是一個SSL(安全套接層)協議的免費的軟體實現。該專案的創立者，它的兩個主要作者之一，Nikos Mavrogiannopoulos在2012年12月宣佈他在移動該專案到GNU專案的基礎設施之外，這是因為對自由軟體基金會(FSF)的決策與實踐的一個主要的分歧。“我不再認為GnuTLS是一個GNU專案，”他寫道，“而且未來的貢獻沒有必要在FSF的版權下。”

　　Richard M. Stallman，GNU與FSF的創立者，對此完全不認同！在一封題為GNUTLS不會去任何地方 的電子郵件中，Stallman, a.k.a. RMS回覆道，“你不能將GNUTLS帶出GNU專案。你無法為GNU包指定一個非GNU程式做一個替代。我們將繼續GNUTLS的開發。”

　　聽上去好像那已經離作為一個開源開發者至少需要知道的版權的東西越來越遠，但請再忍一會兒。因為它引起了幾個麻煩的問題，像Michael Kerrisk, 一個LWN.net 作者說的，“這些問題的第一個已經在上面顯示了： 誰擁有該專案？  GnuTLS 專案是由Nikos作為一個GNU專案誠意的發起的。在該專案的生命週期中，最主要的貢獻到專案中的程式碼是由兩個個人寫的，現在他們都（推測的）想離開 GNU專案。如果該專案是被獨立開發的，那麼顯然 Nikos 和 Simon將被認為擁有該專案的程式碼與名字。然而，轉讓版權給FSF時，他們就放棄了他們自己的權利 ”

　　如果你對一個特殊的團體有任何問題——你應該會有問題——在它的貢獻者許可協議中檢查一下，確切看看這個團體要求了什麼權力。然後，如果你仍然有問題（你 可能會有），與該組織或一個著作權代理人協商。這不是你在點選那些網站的“我已經閱讀並同意該隱私政策”時毫無顧慮的忽略掉的check（對勾）標記。從 字面上理解，你在提交你自己，或者至少是在需要三杯咖啡的睡眼惺忪的除錯時寫下的程式碼。

　　權力的轉讓不僅僅是一個對非盈利性開源團體的版權問題。一些商業開源組織要求你把給他們專案貢獻的程式碼的版權交給他們。其他的，像Oracle (PDF文件)要求你的貢獻的聯合版權，這是為了它的OpenJDK, GlassFish, 和 MySQL專案。

　　底線並非是你必須成為一個律師——儘管我理解你會這樣認為！——但你的確需要仔細檢查你對你程式碼的權利。你需要了解在使用開源協議或針對一個特定專案時，你放棄了那些權利。如果你仍然疑惑，卻找專業法律幫助吧。

　　你不會希望陷入版權的泥沼之中的。祝好運。