英文原文：Writing Open Source Software? Make Sure You Know Your Copyright Rights、編譯：oschina
開源軟體再好不過了，但是在將自己的精力和無數程式碼投入一個專案之前，請確保你準確理解了你的程式碼的版權將發生什麼變化——以及你的職業生涯將發生什麼變化。
我知道。如果想成為律師，你會去法學院，而不是整夜鑽研K&R。然而，在2013年，如果你是一個開源程式設計師，你需要知道版權法相關的一些事情。如果不這樣做，會發生不好的事情——非常不好的事情。
在開始這個話題之前，我必須指出，我不是一個律師（IANAL）。如果你有一個具體的實際問題，找一個律師談談。找一個精通版權法的律師。
每當你寫程式碼，就在創造有版權的成果。當我問到關於版權的陷阱時，正如OSI（開源軟體促進會）主席Simon Phipps所說，“最大的一個是年輕開發者完全迴避版權證照的趨勢。當他們這麼做時，就將為所有合作者增加風險，當然自身也面臨潛在的賠償責任。”
開發者需要知道版權是自動受伯尼爾公約保護的，Phipps解釋道。自從這個公司付諸實施後，所有軟體開發都涉及到拷貝和其他版權相關的活動，Phipps說到，所有沒有被許可的開發工作都潛在地侵犯了版權。“或許現在沒有造成麻煩，但沒有永久的版權許可將會對合作者造成永久的危害”。
“你可以假裝你需要的版權不存在，但將來它會反咬你一口，” Phipps接著說道，“這就是為什麼[如果你開始一個新專案]你需要申請一個開源授權許可”。如果你想要公共域，請使用MIT許可，它很簡單，並能保護你和你的合作者免受這些危害。如果你真的在意，請使用現在專利保護許可，像Apache,MPLv2,或者GPLv3，請確保你得到其中一個許可。
誰擁有那些僱傭工作的程式碼？可能是你哦
你應該知道當你擁有版權時，你的老闆或者諮詢客戶也擁有這份版權。如果你寫的程式碼屬於你老闆，歸根到底，它不是屬於你的。如果它不是你的，那麼你就沒有權利去給開源專案授權。所以我們這樣假設，僱傭或自由職業都自動地屬於僱傭行為。
比如，你在工作之餘正在開發的那個小專案，完全屬於你自己嗎？或許屬於你，但就像Daniel A.Tysver,一個Beck & Tysver的合夥人，在BitLaw寫到：
當招聘程式設計師時，軟體開發商應該密切關注版權所有權問題。在大多數情況下，如果專案是付了薪水的員工做的，那麼這個專案就屬於僱傭行為下的專案。所以，軟體開發商就會認為，這個被員工開發的軟體的作者和所有權就理所應當的屬於開發商。不過精明的開發商會讓程式設計師簽署一份協議，讓他們同意授權他們開發出的軟體給開發商。開發商這麼謹慎是因為決定一個員工是不是合法需要分析很多因素，並且在極個別情況下會引起意想不到的結果。另外，僱傭期間的工作需要在員工在僱傭期間完成。通常，程式設計師開發的專案都會在僱傭期間完成，但這也是一個模糊的概念，我們最好不做以此做條件。
如果你是一個自由職業者，並且你在僱傭期間程式設計序，那麼即使那些程式碼也是開源軟體的一部分，你的客戶也擁有你寫的程式碼的版權嗎？實際上，這不好確定。
Tysver接著說道：
當招聘一個程式設計師時，軟體開發商必須十分謹慎。為了確定員工所做的專案屬於僱傭期間，必須考慮3個因素： 專案必須是事先計劃好或者指派的； 招聘程式設計師的合同必須有員工簽字，而且必須在明確指出在雙方都同意的情況下，員工做的專案是僱傭期間的工作； 開發的專案必須屬於9個類別中的一個。 當一個程式設計師被招聘來開發一個具體的專案的時候，第一個條件就已經成立了。第二個條件可以通過仔細地制定程式設計師的合同來解決。然而，第三個條件就比較複雜了。軟體工程不屬於9個類別中的一個，最好的賭注就是使軟體專案符合“視聽作品”的定義。雖然有些軟體專案很明顯屬於視聽作品，但讓法官認為所有的軟體專案都屬於這一概念是不可能的，因此，軟體開發商不能肯定籤合同的程式設計師做的專案屬於僱傭期間的工作。 最好的方法是簽訂一份協議來解決這個不確定性。協議中應明確員工做的專案是僱傭期間的工作，也應該明確指出，即使專案不屬於僱傭期間的工作，程式設計師也應該同意把該專案授權給軟體開發商。 最後，當僱傭一個公司來提供程式設計師簽約服務時，一定得確認程式設計師把版權的所有者交給了軟體開發商，所以軟體開發商不僅審查提供簽約服務公司的合約，也得審查和程式設計師簽約的協議。
他說的是你簽署的僱傭工作合同並不能說明誰會得到程式碼的版權，也就是意味著你可能仍然擁有版權嗎？好吧，是的，事實上他是這個意思。如果你仔細看一下U.S. 版權法 (PDF)，你會發現有九種被描述為“僱傭作品”(WMFH)的作品。它們沒有一個是程式程式碼。
因此，像一個作者在 Law-Forums.org寫的，以morcan的筆名，“計算機程式沒有逐漸落入委託條件下的WMFH法定類別，因此，應該簡單的稱它為未被法規確認的。”
他（或她）繼續道，“因此，你當然可以有一個書面的WMFH協議（無論什麼它很值得），明確的概述雙方的意向，就是你是委託工作的‘版權的作者與所有者’，但對所有權力，題名，和在該專案下所創立工作的任何所有部分的承包人的版權利益，你仍然需要一個（單獨的）轉讓與讓渡，這一點從在WMFH中他或她是作者中自然顯現出來。”用其他話來說，如果在你的合同中沒有一個“版權所有權的轉移”條款，是你這個程式設計師，而不是給你這個合同的公司，可能仍然具有版權。
那會導致真正的麻煩。“我確實看到過重要企業的併購被破壞，由於一些目標軟體公司的人員，具有僱傭作品(WMFH)協議下的‘合同程式設計師’身份,使併購不能獲得必要的關於簽約版權的書面轉讓。”morcan補充道。
Rich Santalesa,資訊法律組織 的高階法律顧問，同意morcan的看法。“可能發生的事情是，謹慎的（也就是說：可靠的）軟體/版權律師用一種帶子與吊帶褲的方法，將’在所有方面適用的’一個’僱傭作品’字樣 加到開發協議當中——結果實際上，美國國稅局(IRS)或者一些其他稅收主體也會說’不,那個人是一個僱員,不是一個獨立的簽約者’”Santalesa說。協議也包括了一個一旦執行將立即有效的轉讓與讓渡條款。
“無論何時何地，我們[代表工作締約方的版權律師]總試圖針對僱傭情況做一點工作，“Santalesa解釋道。”因此由於版權的目的，作者/程式設計師不再是‘法定作者’。而且在出爐的合同中最終證據方面，常常在特定事實問題上，它可能會很棘手。“
我陳述所有這些的意思是，你應該試著確定，你和與你簽署合同的公司應具有一份法律合約，從字面上明確任何自定義程式碼的版權會怎樣處理。如果只是簡單的說一些東西是僱傭作品，這將不符合要求。
現在，加入開源貢獻
這些關注點同樣適用於開源專案。大多數專案具有某種版權轉讓協議（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的開發。”
你看，當你建立一個GNU專案而沒有轉讓版權給FSF時，FSF將不會在GPL下保護該專案的著作權(IP)，除非你做了轉讓。並且，回溯到專案開始的時候，Mavrogiannopoulos完成了版權轉讓。此外，如RMS指出，不管你在世界的何方，如果你選擇了這條途徑，版權將給予U.S. FSF ，而不是它的姐妹組織。
在許多激烈的爭論以後，這個特別的衝突開始安靜下來。Mavrogiannopoulos現在希望他曾做出的是一個不同的決定。“我非常後悔轉讓所有權利給FSF，但看起來我沒有什麼能去做來使之改變的。”他可以建立程式碼分支，但不能在專案的名字裡加上他，因為那是版權的一部分。
聽上去好像那已經離作為一個開源開發者至少需要知道的版權的東西越來越遠，但請再忍一會兒。因為它引起了幾個麻煩的問題，像Michael Kerrisk, 一個LWN.net 作者說的，“這些問題的第一個已經在上面顯示了： 誰擁有該專案？ GnuTLS專案是由Nikos作為一個GNU專案誠意的發起的。在該專案的生命週期中，最主要的貢獻到專案中的程式碼是由兩個個人寫的，現在他們都（推測的）想離開GNU專案。如果該專案是被獨立開發的，那麼顯然 Nikos 和 Simon將被認為擁有該專案的程式碼與名字。然而，轉讓版權給FSF時，他們就放棄了他們自己的權利 ”
然而還有更多麻煩。像Kerrisk指出的，“FSF的能耐——作為唯一的版權持有者——控告違背授權者是被當作一個主要的版權轉讓的優勢來招攬顧客。但是，如果由於某一個或另一個原因，FSF選擇了不履行它的權利呢？”那麼從轉讓他或她的版權，程式設計師能得到什麼好處呢？
最後，Kerrisk補充說，對企業與非贏利組織，分派時都會有一個問題發生。“簽署版權轉讓協議的要求給參與者設定了一個障礙。一些個人與公司只是不想被這些書面的工作打擾。另一些可能對在一個自由軟體許可下貢獻程式碼覺得沒有問題，但是他們（或他們的律師）對交出程式碼的所有權利感到猶豫。”
你能給一個專案做出貢獻嗎？合法的？
對參與者的障礙不只是理論上的，Kerrisk援引Greg Kroah-Hartman這位著名的Linux核心開發者的例子。在一次關於Gentoo Linux的釋出是否要版權轉讓的談話中， Greg Kroah-Hartman說，“從個人來說，如果任何版權轉讓是合適的，我永遠也不可能成為一個Gentoo開發者，如果它被放在合適的位置，我不認為我會被允許繼續做下去。我確信現在很多其他開發者也處於同樣的境地。”
其他非贏利性開源團體採取了不同的處理。例如Apache基金會，要求“一個永久的，世界的，非排他的，免費的，免稅的，不可撤銷的版權許可，來再生產，準備衍生作品，公開展示，公開表演，轉授權，釋出你的貢獻和它的衍生作品。”
如果你對一個特殊的團體有任何問題——你應該會有問題——在它的貢獻者許可協議中檢查一下，確切看看這個團體要求了什麼權力。然後，如果你仍然有問題（你可能會有），與該組織或一個著作權代理人協商。這不是你在點選那些網站的“我已經閱讀並同意該隱私政策”時毫無顧慮的忽略掉的check（對勾）標記。從字面上理解，你在提交你自己，或者至少是在需要三杯咖啡的睡眼惺忪的除錯時寫下的程式碼。
權力的轉讓不僅僅是一個對非盈利性開源團體的版權問題。一些商業開源組織要求你把給他們專案貢獻的程式碼的版權交給他們。其他的，像Oracle (PDF文件)要求你的貢獻的聯合版權，這是為了它的OpenJDK, GlassFish, 和 MySQL專案。
一些公司，如Ubuntu Linux的母公司， Canonical, 已經對這些說法的要求給予支援。例如，Canonical現在宣告“你保留你貢獻部分的版權的所有權，而且對你所擁有的在沒有進入該協議時的貢獻，具有同樣使用或許可的權力。”Red Hat, 在它的 Fedora 專案貢獻協議中，現在只要求你具有對程式碼版權的授權的權力，它的許可是在CC 署名-相同方式共享 3.0 Unported 許可 或 一個變化的MIT許可 任意一個之下。如果你不知道在向你要什麼，徵詢專家的意見。
對所有這些怎麼處理版權的不一致之處，你可能奇怪為什麼人們沒有試圖用一個通用的辦法來處理它們。好吧，他們曾經做過：它被稱為和諧計劃。然而，和諧計劃沒有獲得許多支援，而且它的版權模版沒有被廣泛接受。
底線並非是你必須成為一個律師——儘管我理解你會這樣認為！——但你的確需要仔細檢查你對你程式碼的權利。你需要了解在使用開源協議或針對一個特定專案時，你放棄了那些權利。如果你仍然疑惑，卻找專業法律幫助吧。
你不會希望陷入版權的泥沼之中的。祝好運。