藝術贊助 vs 軟體贊助

我提出了兩種新的系統來資助藝術家，在一個我們已將已出版作品的分享（非商業用途的精確副本再發行）合法化的世界中。其中一種是國家徵稅用於此目的，並根據每位藝術家的人氣的立方根比例（通過調查人口樣本來衡量）將資金分配給他們。另一種是讓每位使用者都有一個「捐款」按鈕，匿名地向製作了最後播放作品的藝術家發送小額款項（在美國也許是 50 美分）。這些資金將給予藝術家，而不是他們的出版商。

人們經常想知道為什麼我沒有為自由軟體提出這些方法。這是因為很難將它們應用於自由作品。

我認為，設計用於執行實際工作的作品必須是自由的。使用它們的人們應該有權控制他們所做的工作，這需要控制他們用來完成工作的作品，這需要四項自由。用於執行實際工作的作品包括教育資源、參考文獻、食譜、文字字型，當然還有軟體；這些作品必須是自由的。

這個論點不適用於意見作品（例如這篇）或藝術作品，因為它們不是設計給使用者執行實際工作的。因此，我不認為這些作品必須是自由的。我們必須將分享它們、以及在混音中使用片段來製作完全不同的新作品合法化，但這不包括發布它們的修改版本。因此，對於這些作品，我們可以知道作者是誰。每部已出版的作品都可以指定其作者是誰，而更改該資訊可能是非法的。

這個關鍵點使得我提出的資助系統能夠運作。這意味著，如果您播放一首歌曲並按下「捐款」按鈕，系統可以確定誰應該收到您的捐款。同樣地，如果您參與計算人氣的調查，系統會知道因為您聽了那首歌或複製了它，而將更多的人氣歸功於誰。

當一首歌由多位藝術家製作時（例如，幾位音樂家和一位詞曲作者），這並非偶然。他們知道他們正在一起工作，並且可以預先決定如何分配這首歌後來發展出的人氣——或者使用標準的預設規則進行分配。這種情況對於這兩個資助提案沒有造成問題，因為作品一旦完成，就不會被其他人更改。

然而，在自由作品的領域中，一部大型作品可能有數百甚至數千位作者。可能會有各種版本，其中作者集合不同且重疊。此外，這些作者的貢獻在種類和規模上都會有所不同。這使得以一種可以被證明是正確的方式，將作品的人氣在貢獻者之間分配變得不可能。這不僅僅是辛苦的工作；它不僅僅是複雜的。這個問題提出了沒有好的答案的哲學問題。

例如，考慮一下自由程式 GNU Emacs。在我們開始使用版本控制之前的時期，我們關於 GNU Emacs 程式碼貢獻的記錄是不完整的——在那之前我們只有變更日誌。但是，讓我們想像一下，我們仍然擁有每個版本，並且可以精確地確定每個數百位貢獻者的程式碼貢獻。我們仍然會陷入困境。

如果我們想按程式碼行數（或者應該是字元數？）比例給予功勞，那麼一旦我們決定如何處理由 A 編寫然後由 B 更改的行，就會變得簡單明瞭。但這假設每一行都與其他每一行一樣重要。我確信這是錯誤的——程式碼的某些部分執行更重要的工作，而另一些部分則較不重要；有些程式碼更難編寫，而另一些程式碼則更容易。但我看不出有任何方法可以量化這些區別，開發人員可能會永遠爭論它們。我可能因為最初編寫了該程式而應該獲得一些額外的功勞，而某些其他人可能因為最初編寫了某些後來的重要的添加內容而應該獲得額外的功勞，但我看不出有任何客觀的方法來決定多少。我無法為像 GNU Emacs 這樣的程式提出一個合理的規則來分配人氣功勞。

至於要求所有貢獻者協商協議，我們甚至無法嘗試。已經有數百位貢獻者，我們今天無法找到他們所有人。他們在 26 年的時間跨度內做出了貢獻，而且從未有任何時候所有這些人都決定一起工作。

我們甚至可能不知道所有作者的名字。如果某些程式碼是由公司捐贈的，我們不需要詢問是哪些人編寫了這些程式碼。

那麼 GNU Emacs 的分支或修改變體呢？每一個都是一個額外的案例，同樣複雜但不同。這種變體的功勞應該有多少歸於那些在這個變體上工作的人，又有多少歸於從其他 GNU Emacs 版本、其他程式等獲得程式碼的原始作者？

結論是，我們無法提出 GNU Emacs 的功勞分配，並證明它是除了任意之外的任何東西。但 Emacs 並非特例；它是一個典型的例子。許多重要的自由程式以及其他自由作品（如 Wikipedia 頁面）也會出現同樣的問題。

這些問題是我不建議在軟體、百科全書或教育等領域使用這兩種資助系統的原因，在這些領域，所有作品都應該是自由的。

對於這些領域來說，有意義的是要求人們為他們計劃進行的工作捐款給專案。這個系統很簡單。

自由軟體基金會以兩種方式請求捐款。我們請求一般捐款以支持基金會的工作，並且我們邀請針對某些特定專案的定向捐款。其他自由軟體組織也這樣做。