
怎樣看開源代碼版權_版權聲明在開源代碼中泛濫成災
怎樣看開源代碼版權
?天,我在查看并注意到頂部有版權聲明。 現在,我絕對不想選擇尼古拉斯。 OpenStack?檔和代碼中有數百種此類版權聲明,?這只是我碰巧看到的?例。
(請注意,我的雇主在OpenStack代碼中擁有其版權聲明的份額。?乎所有參與OpenStack的公司都這樣做。我認為我們應該停?。)
我向OpenStack-docs列表發送了?個便箋,它?成了?個 。 據我了解,我們?勵?們將版權聲明放?貢獻的源代碼和?檔中,并在他們修改的?件中添加版權?。
我認為這是?件?常不好的事情,原因如下:
如果我編輯?個?件,并在頂部說該?件是BigCo版權所有,那么我就不建議編輯該?件,因為這暗?著我會踩在別?的腳趾上。 ?件不應有任何跡象表明它們由任何?個?或公司“擁有”。 ( “擁有”代碼的更多信息, Karl Fogel的?章。)這積極地阻?了?們投?并修復某些東西。
如果N個?為?個?件做出貢獻,那么我們應該在?件中包含N個版權聲明嗎? 這不會隨著時間推移?擴展。 想象?下,從現在開始?年后,這些?件將是什么樣,現在就解決問題。
在?件中包含作者姓名會?勵?們出于錯誤的原因做出貢獻。
Git跟蹤誰做出了哪些更改。 不需要明確的版權聲明。
對我??,第?個原因是最引?注?的。 應當盡量避免任何阻礙貢獻的事情,尤其是對于初學者??。
當遇到源代碼中的版權聲明時,有?問我在提交補丁之前是否必須征得該?的許可。 如果我們什?可以避免?個?問這個問題,那么我們已經為該項?提供了服務。
我還擔?那些堅持在稿件中聲明版權聲明的公司既不理解版權法也不理解開放源代碼。 ???,Git中的審核記錄可以保護您的貢獻記錄,從?保護您的版權。 另???,如果您的版權對您如此重要,那么也許您不應該將其貢獻給?個開源項?。 對?個項?說他們可以做出貢獻是反社區的,但前提是您必須斷?這是您的個?財產。 開源與社區和協作有關。 如果建筑物是社區所有,那么堅持堅持使?特定的磚塊,您會得到什么?
在Apache軟件基?會,?年前,我們進?了辯論,并決定源代碼中的author標簽是反社區的,因此不?勵使?。 引?當時的評論主題,尤其是引?Sander Striker:
在Apache軟件基?會,我們不?勵在源代碼中使?author標記。 除了法律后果外,還有多種原因。 協作開發是關于作為?個?組進?項?并作為?個?組來關?項?。 給予信任是好事,應該這樣做,但要以
不允許誤導甚?暗?的?式進?。 沒有何時添加或刪除作者標簽的明確?。 更改評論時是否添加姓名? 當您進?單?修復時? 重構代碼時,您是否刪除了其他作者標簽,看起來與其他標簽有95%的差異? 您對要接觸每個?件的?該怎么辦,要對其進??夠的更改以使虛擬作者標簽具有?夠的配額,以便他們的名字?處不在?
有更好的信貸?式,我們更喜歡使?信貸。 從技術?度來看,作者標簽是不必要的; 如果您想找出誰編寫了特定的代碼,可以參考版本控制系統來解決。 作者標簽也趨于過時。 您是否真的想私下聯系您五年前編寫的?段代碼,并很?興被遺忘了?
這是?個稍有不同的問題(作者標簽?不是版權聲明),但觀點完全相同。 更正?檔中的語法或拼寫時是否添加版權聲明? 當我添加?個段落或對句?重新排序以提?清晰度時怎么樣? 在什么時候我刪除了您的版權聲明,因為我已經對該?件做了很多更改?
然后,當然,您應該考慮更?的問題-您為什么在乎? 您要防?什么? 如果您試圖保護??的貢獻不被社區占?并?于其他?的,那么貢獻Apache許可的代碼庫也許不是最明智的選擇。
最初發布 。經許可重新發布。
怎樣看開源代碼版權