如果您維護的是 FSF 擁有著作權的套件，當您納入其他人撰寫的具法律意義的變更時，需要遵循特定的法律程序。這確保了 FSF 擁有發布該套件的合法權利，以及在必要時於法庭上捍衛其 GPL 授權狀態的資格。
GNU 套件不一定需要由 FSF 擁有著作權；這取決於作者（們），通常在套件被稱為 GNU 時決定。當著作權轉讓給 FSF 時，FSF 有權採取行動阻止關於該套件的 GPL 違規行為（否則，法律行動將由作者（們）決定）。這也允許我們在必要時授予套件額外的許可，例如例外條款。此外，持有著作權也使我們能夠升級套件的授權，即使它最初是以「僅限 GPLv2」發布的（而不是 FSF 推薦的「或更新版本」授權選項）。本節的其餘部分是關於套件由 FSF 擁有著作權的情況。
在納入重大變更之前，請確保撰寫變更的人員已簽署著作權文件，並且自由軟體基金會已收到並簽署這些文件。我們可能還需要該人員雇主的免責聲明，以確認該工作不是該人員工作的一部分，且雇主對其不主張任何權利。然而，一份該人員的僱傭合約副本，顯示雇主不能對此工作主張任何權利，通常就已足夠。
如果雇主確實主張該工作是該人員工作的一部分，且沒有明確的依據可以說該主張無效，那麼我們必須認為該主張有效。如此一來，該人員就不能轉讓著作權，但雇主可以。許多公司都這樣做過。請要求相關經理聯絡 assign@gnu.org。
要檢查是否已收到文件，請查看 /gd/gnuorg/copyright.list。如果您無法直接查看，fsf-records@gnu.org 可以為您檢查。我們的職員也可以檢查正在等待輸入的文件，並在預期的文件到達時通知您。
本文件中通篇提及的目錄 /gd/gnuorg 在通用的 GNU 伺服器上可用，目前是 fencepost.gnu.org。如果您是 GNU 套件的維護者，您應該在那裡有一個帳戶。如果您還沒有帳戶，請參閱 https://gnu.dev.org.tw/software/README.accounts.html。此類 GNU 登入帳戶包含電子郵件（請參閱 https://www.fsf.org/about/systems/sending-mail-via-fencepost）。
您可以為在套件工作上顯著幫助您的人員申請帳戶；在有充分理由的特殊情況下，我們會這樣做。
為了讓貢獻者知道他們應該簽署文件，您需要向他們索取必要的文件。如果您不熟悉該人員，並且不知道該人員是否習慣我們處理著作權文件的方式，那麼最好以類似這樣的訊息提出這個主題：
您是否願意將著作權轉讓給自由軟體基金會，以便我們可以將其安裝到 套件 中？
或者
您是否願意簽署著作權免責聲明，將此變更置於公共領域，以便我們可以將其安裝到 套件 中？
如果貢獻者想要更多資訊，您可以向他們發送檔案 /gd/gnuorg/conditions.text，其中解釋了他們的選項（轉讓 vs. 免責聲明）及其後果。
一旦對話開始，且貢獻者準備好了解更多細節，您應該發送目錄 /gd/gnuorg/Copyright/ 中找到的範本之一；它們也可以從 gnulib 專案的 doc/Copyright/ 目錄中取得，網址為 https://savannah.gnu.org/projects/gnulib。本節說明在哪些情況下您應該使用哪些範本。請不要使用此處列出的範本以外的任何範本，並且請不要更改措辭。
一旦對話開始，您可以透過電子郵件向貢獻者發送精確的措辭和指示。在您執行此操作之前，請務必取得您將使用的範本的最新版本！我們會偶爾更改這些範本 — 請勿持續使用舊版本。
對於大型變更，請要求貢獻者進行轉讓。向他們發送檔案 request-assign.changes 的副本。（像所有 'request-' 檔案一樣，它位於 /gd/gnuorg/Copyright 和 gnulib 中。）
對於中小型變更，請透過發送檔案 request-disclaim.changes 向他們請求個人免責聲明。
如果貢獻者可能會持續進行變更，他們可能希望簽署一份針對他們未來對該程式的所有變更的轉讓。因此，向他們提供該替代方案是有用的。如果他們想以這種方式進行，請向他們發送 request-assign.future。
當您發送 request- 檔案時，您無需在發送前填寫任何內容。只需將檔案逐字發送給貢獻者即可。該檔案為他們提供了關於如何要求 FSF 郵寄要簽署的文件的指示。request- 檔案還提出了從貢獻者雇主處取得雇主免責聲明的問題。
當貢獻者透過電子郵件將表格發送給 FSF 時，FSF 會向他們發送一份電子（通常是 PDF）版本的轉讓書。這個或任何所需的回覆，應在首次請求後的五個工作日內發生。如果在那段時間後仍未收到 FSF 的回覆，請發送提醒。如果在一週後仍然沒有回覆，請寫信給 maintainers@gnu.org 反映。
在收到必要的表格後，貢獻者需要簽署它。居住在美國或義大利的貢獻者可以使用 GPG 來簽署他們的轉讓書。位於任何其他地方的貢獻者可以列印、簽署，然後將掃描副本透過電子郵件（或傳真）發回給 FSF。（兩種情況的具體指示都隨轉讓書表格一起發送。）如果他們願意，也可以使用郵寄方式。要強調的是，必要的區別在於這些國家的居民和非居民之間；國籍並不重要。
對於較不常見的情況，我們有範本檔案您應該發送給貢獻者。請務必在發送之前，在範本中標示為 'NAME OF PERSON' 和 'NAME OF PROGRAM' 的地方填寫人員姓名和程式名稱；否則他們可能會在沒有注意到的情況下簽署，而這些文件將毫無用處。請注意，在某些範本中，有多個地方需要填寫程式名稱或人員姓名；請務必全部更改。所有範本也都提出了雇主免責聲明的問題。
對於僅在其描述的軟體套件中發布的手冊，您無需要求單獨的文件。但是，如果我們有時單獨發布手冊（例如，如果我們將其作為書籍出版），那麼我們需要針對手冊中的變更提供單獨的法律文件。對於較小的變更，請使用 disclaim.changes.manual；對於較大的變更，請使用 assign.changes.manual。要涵蓋手冊的過去和未來變更，您可以使用 assign.future.manual。對於手冊的翻譯，請使用 assign.translation.manual。
對於程式字串的翻譯（例如 GNU Gettext 使用的翻譯；請參閱 GNU 編碼標準 中的 國際化），請使用 disclaim.translation。如果您使用 Translation Project (https://translationproject.org) 的工具，請與 TP 協調員確認他們是否已向貢獻者發送文件；如果他們沒有發送，那麼您應該發送文件。在任何情況下，您都應該等待 FSF 的確認，確認已收到並接受簽署的文件，然後再整合新貢獻者的材料，一如往常。
如果貢獻者不願意為大型變更簽署轉讓書，但願意簽署免責聲明，這是可以接受的，因此如果這有助於您達成協議，您應該提供此替代方案。我們更傾向於針對較大型變更的轉讓，以便我們可以為新文本強制執行 GNU GPL，但免責聲明足以讓我們使用該文本。
如果您維護的是程式集合，偶爾會有人貢獻一個應該添加到該集合中的完整獨立程式或手冊。那麼您可以使用檔案 request-assign.program、disclaim.program、assign.manual 和 disclaim.manual。我們非常傾向於針對新的獨立程式或手冊的轉讓，除非它非常小，但如果貢獻者堅持以這種方式處理，則免責聲明是可以接受的。
當著作權持有人已簽署針對套件所有未來變更的轉讓書，並貢獻一個由不需要變更任何舊檔案的新檔案組成的變更時，我們希望避免對這些檔案是否旨在作為套件的變更並因此受該轉讓書約束產生任何不確定性。解決這個問題的方法是要求貢獻者在給您的訊息中說明這一點 — 例如，「我的模組 'frog' 和 'kangaroo' 旨在作為程式 Hoppers 的變更」。將訊息轉發給 assign@gnu.org，他們將永久保存它。此程序的變體：撰寫新檔案的貢獻者可以發送包含此類訊息的新檔案副本。
如果貢獻者希望 FSF 僅發布筆名，這是可以的。貢獻者應在回覆 request- 表格時說明這一點，並聲明所需的筆名。實際的法律文件將使用真實姓名，但 FSF 將僅發布筆名。當使用其他表格之一時，請填寫真實姓名，但要求貢獻者在發回簽署的表格之前與 assign@gnu.org 討論筆名的使用。
雖然除了此處列出的範本之外還有其他範本，但它們適用於特殊情況；未經 assign@gnu.org 的建議，請勿使用它們。
如果您不確定該怎麼做，請向 assign@gnu.org 尋求建議；如果貢獻者向您詢問有關法律文件的含義和後果的問題，而您不知道答案，您可以將其轉發給 assign@gnu.org，我們將回覆。
請不要嘗試自行更改範本的措辭。如果您認為需要更改，請與 assign@gnu.org 討論，我們將與律師合作決定該怎麼做。