GNU 軟體維護者資訊，上次更新於 2023 年 6 月 8 日。
Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2019, 2022 Free Software Foundation, Inc.
在符合自由軟體基金會發行的 GNU 自由文件授權條款 1.3 版或任何後續版本的條款下，且不包含不變章節、封面文字和封底文字，特此授予複製、散布及/或修改本文件的許可。授權條款的副本包含在標題為「GNU 自由文件授權條款」的章節中。
| • 序言 | ||
| • 尋求協助 | ||
| • GNU 帳號與資源 | ||
| • 卸任 | ||
| • 招募開發者 | ||
| • 法律事務 | ||
| • 清理 | ||
| • 平台 | ||
| • 不應接受的修補程式 | ||
| • 郵件 | ||
| • 舊版本 | ||
| • 發行 | ||
| • 網頁 | ||
| • 倫理與哲學考量 | ||
| • 幽默 | ||
| • 其他政治 | ||
| • 術語 | ||
| • 訪談與演講 | ||
| • 託管 | ||
| • 捐款 | ||
| • 自由軟體目錄 | ||
| • 使用校對者清單 | ||
| • 建議回覆 | ||
| • GNU 自由文件授權條款 | ||
| • 索引 |
本檔案包含針對代表 GNU 專案維護 GNU 程式的人員的指南與建議。每個人都有權變更和重新散布 GNU 軟體；您不需要注意本檔案以取得許可。但是，如果您想要維護一個廣泛散布的版本，我們建議您遵循這些指南。如果您是或想要成為 GNU 維護者，那麼遵循這些指南至關重要。
除了本文件之外，請閱讀並遵循 GNU 編碼標準（請參閱目錄，位於GNU 編碼標準中）。您也可以參考「給新 GNU 維護者的提示」 (https://gnu.dev.org.tw/software/maintainer-tips)，其中列出了您作為新維護者需要執行的最重要事項。
請將對本文件的更正或建議發送至 bug-standards@gnu.org。如果您提出建議，請盡可能包含建議的新措辭。我們偏好 Texinfo 來源的 context diff，但如果您覺得困難，您可以針對本文件的其他版本製作 diff，或以任何清楚的方式提出建議。本文件的原始碼儲存庫位於 https://savannah.gnu.org/projects/gnustandards。
如果您想接收這些 GNU 文件每次變更的 diff，請加入郵寄清單 gnustandards-commit@gnu.org，例如透過位於 https://lists.gnu.org/mailman/listinfo/gnustandards-commit 的網頁介面。歸檔文件也在此處提供。
本文件使用性別中立的第三人稱代詞「person」（可以縮寫為「perse」）、「per」、「pers」和「perself」。這些代詞（除了「perse」之外）由 Marge Piercy 在Woman on the Edge of Time中推廣，甚至可能是發明的。它們的使用方式與「she」、「her」、「hers」和「herself」相同，只是它們適用於任何性別。例如，「Person placed per new program under the GNU GPL, to maintain freedom for all users of per work, and this way perse knows perse has done the right thing.」（Person 在 GNU GPL 下放置 per 新程式，以維護所有 per 作品使用者的自由，這樣 perse 就知道 perse 做對了事。）
此版本的 GNU 維護者資訊上次更新於 2023 年 6 月 8 日。
如果您有任何一般問題，或遇到不清楚如何完成某事或該向誰詢問的情況，您（作為 GNU 貢獻者）始終可以寫信給 mentors@gnu.org，這是一個由幾位經驗豐富的 GNU 人士組成的清單，他們自願回答問題。任何與 GNU 相關的問題都可以在 mentors 清單中提出。
GNU 顧問委員會協助代表 RMS（Richard Stallman，首席 GNUisance）協調 GNU 專案中的活動。如果您有任何組織問題或疑慮，可以透過 gnu-advisory@gnu.org 與委員會聯繫。請參閱 https://gnu.dev.org.tw/contact/gnu-advisory.html 以了解目前的委員會成員。其他資訊位於 /gd/gnuorg/advisory。
如果您發現任何 GNU 電腦系統（fencepost.gnu.org、ftp.gnu.org、www.gnu.org、savannah.gnu.org、…）似乎已關閉，您可以透過 https://hostux.social/@fsfstatus 查看目前狀態。如果問題可以在 FSF 端緩解，則很可能已經在處理中。
FSF 系統管理員維護 GNU 網路和伺服器硬體。您可以透過電子郵件 sysadmin@fsf.org 與他們聯繫。請立即向他們報告 GNU 伺服器中的任何故障。除此之外，請盡量不要不必要地加重他們的負擔。
本文件中通篇提及的目錄 /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）。
您可以為在套件工作上對您有顯著幫助的人員申請帳號；在有充分理由的特殊情況下，我們會這樣做。
GNU 維護者可用的其他資源在 https://gnu.dev.org.tw/software/devel.html 以及本文件中都有描述。簡而言之：
幸運的話，您將繼續維護您的套件數十年。但有時由於各種原因，維護者會決定卸任。
如果您是 GNU 套件的官方維護者，並且您決定卸任，請通知 GNU 專案 (maintainers@gnu.org)。我們需要知道套件不再有維護者，以便我們可以尋找和任命新的維護者。
如果您對誰應該接任有想法，請告訴 maintainers@gnu.org 您的建議。新維護者的任命需要 GNU 專案的確認，但您對某人有能力勝任這項工作的判斷將具有很大的份量。
作為您作為維護者的最後一項行動，在 savannah.gnu.org 下設定或更新套件會很有幫助（請參閱舊版本）。這將使新的維護者更容易從您離開的地方繼續，並將確保原始碼樹狀結構不會錯放，如果我們需要一段時間才能找到新的維護者。
除非您的套件相當小，否則您可能無法獨自完成所有工作。大多數維護者會招募其他開發者來協助。
有時會有人主動表示願意幫忙。他們有些人能力很好，有些人則不然。這取決於您來判斷誰提供了有用的幫助，並鼓勵這些人更多地參與。
一些主動提供幫助的人會支持 GNU 專案，而另一些人可能是出於其他原因感興趣。有些人會支持自由軟體運動的目標，但有些人可能不會。我們都歡迎他們協助工作—我們不會在人們貢獻 GNU 套件之前詢問他們的觀點或動機。
因此，您不能期望所有貢獻者都支持 GNU 專案，或關心其政策和標準。因此，作為維護者，您的部分工作是在這些觀點出現時行使您的權威。無論其他人完成多少工作，您都負責發行版本中的內容。當關鍵點出現時，您應該冷靜地說明您的決定並堅持下去。
有時一個套件有多位共同維護者，他們共同承擔維護者的角色。與協助的開發者不同，共同維護者實際上是被共同任命為套件的維護者，他們共同執行維護者的職責。如果您想提名您的一些開發者作為共同維護者，請聯繫 maintainers@gnu.org。
我們很樂意在 https://gnu.dev.org.tw/people/people.html 網頁上感謝所有對 GNU 套件的主要貢獻者。請將您自己的條目發送至 webmasters@gnu.org，並隨時建議您套件上的其他重要開發者也這樣做。
本章描述您在維護程式時應出於法律原因遵循的程序，以避免法律上的困難。
| • 著作權文件 | ||
| • 具法律意義 | ||
| • 記錄貢獻者 | ||
| • 從其他套件複製 | ||
| • 著作權聲明 | ||
| • 授權聲明 | ||
| • 外部函式庫 | ||
| • 歸功作者 |
如果您維護 FSF 著作權套件，則在合併其他人撰寫的具有法律意義的變更時，需要遵循某些法律程序。這確保 FSF 具有散布套件的合法權利，以及在必要時在法庭上捍衛其 GPL 涵蓋狀態的立場。
GNU 套件不一定要是 FSF 著作權；這取決於作者，通常在套件被稱為 GNU 時決定。當著作權被轉讓給 FSF 時，FSF 可以採取行動阻止關於該套件的 GPL 違規行為。否則，法律行動取決於作者。
在合併重大變更之前，請確保撰寫變更的人員已簽署著作權文件，並且自由軟體基金會已收到並簽署這些文件。我們可能還需要該人員雇主的免責聲明，以確認該工作不是該人員工作的一部分，並且雇主對其不主張任何權利。但是，該人員僱傭合約的副本，顯示雇主不能對此項工作主張任何權利，通常就足夠了。
如果雇主確實主張該工作是該人員工作的一部分，並且沒有明確的依據可以說該主張無效，那麼我們必須認為它是有效的。那麼該人員不能轉讓著作權，但雇主可以。許多公司都這樣做了。請要求適當的經理聯繫 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）。
您可以為在套件工作上對您有顯著幫助的人員申請帳號；在有充分理由的特殊情況下，我們會這樣做。
為了讓貢獻者知道 person 應該簽署文件，您需要向 per 索取必要的文件。如果您不認識 per，並且您不知道 person 習慣我們處理著作權文件的方式，那麼向 per 提出這個主題可能是個好主意，訊息如下：
您是否願意將著作權轉讓給自由軟體基金會，以便我們可以將其安裝在 套件 中？
或
您是否願意簽署著作權免責聲明，將此變更置於公共領域，以便我們可以將其安裝在 套件 中？
如果貢獻者然後想要更多資訊，您可以將檔案 /gd/gnuorg/conditions.text 發送給 per，其中說明 per 的選項（轉讓與免責聲明）及其後果。
一旦對話開始進行，並且貢獻者準備好了解更多細節，您應該發送目錄 /gd/gnuorg/Copyright/ 中找到的範本之一；它們也可以從 gnulib 專案的 doc/Copyright/ 目錄中取得，網址為 https://savannah.gnu.org/projects/gnulib。本節說明在哪些情況下您應該使用哪些範本。請不要使用此處列出的範本以外的任何範本，並且請不要更改措辭。
一旦對話開始進行，您可以透過電子郵件將精確的措辭和說明發送給貢獻者。在您執行此操作之前，請務必取得您將使用的範本的目前版本！我們會不時更改這些範本—請勿繼續使用舊版本。
對於大型變更，請要求貢獻者進行轉讓。將檔案 request-assign.changes 的副本發送給 per。（像所有 'request-' 檔案一樣，它位於 /gd/gnuorg/Copyright 和 gnulib 中。）
對於中小型變更，請透過發送檔案 request-disclaim.changes 給 per 來請求個人免責聲明。
如果貢獻者可能會持續進行變更，person 可能會想要簽署一份轉讓書，將 person 未來對程式的所有變更都轉讓出去。因此，向 per 提供該替代方案是有用的。如果 person 想要以這種方式進行，請將 request-assign.future 發送給 per。
當您發送 request- 檔案時，您無需在發送之前填寫任何內容。只需逐字將檔案發送給貢獻者即可。該檔案向 per 提供了關於如何要求 FSF 將要簽署的文件郵寄給 per 的說明。request- 檔案也提出了從貢獻者的雇主處取得雇主免責聲明的問題。
當貢獻者透過電子郵件將表格發送給 FSF 時，FSF 會向 per 發送轉讓書的電子（通常是 PDF）副本。此副本或任何所需的回覆應在首次請求後的五個工作天內送達。如果在該時間過後 FSF 沒有回覆，請發送提醒。如果再過一週仍然沒有回覆，請寫信給 maintainers@gnu.org 告知此事。
收到必要的表格後，貢獻者需要簽署。居住在美國或義大利的貢獻者可以使用 GPG 來簽署其轉讓書。位於其他任何地方的貢獻者可以列印、簽署，然後透過電子郵件（或傳真）將掃描副本寄回 FSF。（兩種情況的具體說明都隨轉讓書表格一起發送。）如果他們願意，他們可以使用郵寄方式。要強調的是，必要的區別在於這些國家的居民和非居民；公民身分並不重要。
對於較不常見的情況，我們有範本檔案，您應該將其發送給貢獻者。請務必在這些範本中填寫人員姓名和程式名稱，在上面寫著 'NAME OF PERSON' 和 'NAME OF PROGRAM' 的地方，然後再發送；否則 person 可能會在沒有注意到的情況下簽署，而這些文件將毫無用處。請注意，在某些範本中，有多個地方可以放置程式名稱或人員姓名；請務必全部更改。所有範本也都提出了雇主免責聲明的問題。
對於僅在其描述的軟體套件中散布的手冊，您無需要求單獨的文件。但是，如果我們有時單獨散布手冊（例如，如果我們將其出版成書），那麼我們需要單獨的法律文件來處理手冊中的變更。對於較小的變更，請使用 disclaim.changes.manual；對於較大的變更，請使用 assign.changes.manual。若要涵蓋手冊的過去和未來變更，您可以使用 assign.future.manual。對於手冊的翻譯，請使用 assign.translation.manual。
對於程式字串的翻譯（例如 GNU Gettext 使用的翻譯；請參閱GNU 編碼標準中的國際化），請使用 disclaim.translation。如果您使用翻譯專案 (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 交談，我們將與律師合作決定該怎麼做。
如果某人貢獻超過約 15 行程式碼及/或在著作權方面具有法律意義的文字，我們需要該貢獻的著作權文件，如上所述。
僅幾行（約少於 15 行）的變更在著作權方面不具有法律意義。一系列重複的變更，例如重新命名符號，即使符號必須在許多地方重新命名，也不具有法律意義。但是請記住，同一人進行的一系列小變更可能會加起來構成重大貢獻。重要的是人員的總貢獻；與何時貢獻哪些部分無關。
著作權不涵蓋想法。如果有人貢獻想法但沒有文字，這些想法在道德上可能具有貢獻意義，並且值得讚揚，但它們在著作權方面並不重要。同樣，錯誤報告在著作權方面也不計算在內。
在讚揚其貢獻在著作權方面不具有法律意義的人員時，請務必明確說明這一事實。讚揚應清楚地說明他們沒有貢獻重要的程式碼或文字。
當人員的貢獻在法律上不重要，因為他們沒有撰寫程式碼時，請清楚說明他們的貢獻是什麼。例如，您可以這樣寫：
/* * Ideas by: * Richard Mlynarik <mly@adoc.xerox.com> (1997) * Masatake Yamato <masata-y@is.aist-nara.ac.jp> (1999) */
Ideas by: 清楚地表明 Mlynarik 和 Yamato 在此處僅貢獻了想法，而不是程式碼。如果沒有 Ideas by: 註記，幾年後我們將很難確定他們是否貢獻了程式碼，我們可能必須追蹤他們並詢問他們。
當您在變更日誌檔案中記錄一個小修補程式時，首先搜尋同一人員先前的變更，並查看 per 過去的貢獻加上新的貢獻是否加起來達到具有法律意義的程度。如果是，您應該在安裝新變更之前取得 per 所有變更的著作權文件。
如果不是這樣，您可以安裝小修補程式。在修補程式作者姓名後寫上「(tiny change)」，如下所示：
2002-11-04 Robert Fenk <Robert.Fenk@gmx.de> (tiny change)
保持正確的記錄，記錄哪些部分是由誰撰寫的。 這非常重要。這些記錄應說明哪些檔案或檔案的哪些部分是由每個人撰寫的，以及哪些檔案或檔案的哪些部分是由每個人修訂的。這應包括安裝腳本以及手冊和文件檔案—所有內容。
這些記錄不需要像變更日誌一樣詳細。它們不需要區分在不同時間完成的工作，只需要區分不同的人。它們不需要比變更了哪些檔案或檔案的哪些部分更詳細地描述變更。它們也不需要說明檔案或變更的功能或目的—著作權註冊處不在乎文字做什麼，只在乎誰撰寫或貢獻了哪些部分。
清單也應提及，如果同一個套件中散布的某些檔案實際上是單獨的程式。
只需要列出在著作權方面具有法律意義的貢獻（請參閱具法律意義）。可以省略小貢獻、錯誤報告、想法等。
例如，這將描述 GAS 的早期版本：
Dean Elsner first version of all files except gdb-lines.c and m68k.c.
Jay Fenlason entire files gdb-lines.c and m68k.c, most of app.c,
plus extensive changes in messages.c, input-file.c, write.c
and revisions elsewhere.
Note: GAS is distributed with the files obstack.c and obstack.h, but
they are considered a separate package, not part of GAS proper.
請將這些記錄保存在程式原始碼目錄中名為 AUTHORS 的檔案中。
如果您願意，可以使用變更日誌作為這些記錄的基礎。只需確保記錄每次變更的正確作者（撰寫變更的人，而不是安裝它的人），並為那些對於著作權而言微不足道的變更新增 '(tiny change)'。稍後您可以從變更日誌更新 AUTHORS 檔案。如果您小心變更日誌條目的格式，甚至可以自動完成。
在 AUTHORS 中包含其他電子郵件地址、姓名和程式資訊（例如錯誤報告資訊）是可以的。請參閱標準郵寄清單。
本節說明將其他套件中的程式碼合併到您的套件中時的法律考量。將整個模組作為一個整體使用並維持其獨立性是一個不同的問題；請參閱外部函式庫。
| • 非 FSF 著作權套件 | ||
| • FSF 著作權套件 |
在此，我們假設您的套件不是 FSF 著作權套件。
當您從另一個具有 GPL 相容授權的自由軟體套件複製具有法律意義的程式碼時，您應該查看該套件的記錄，找出您複製部分程式碼的作者，並將他們列為您複製程式碼的貢獻者。如果您所做的只是複製，而不是編寫，那麼就著作權而言，您不是此程式碼的貢獻者之一。
如果程式碼應屬於公共領域，請確保這確實屬實：程式碼的所有作者都已聲明放棄著作權權益。然後，當將新檔案複製到您的專案中時，請在檔案開頭新增簡短註記，記錄作者、公共領域狀態以及任何其他相關資訊。
另一方面，當將一些公共領域程式碼合併到 GPL（或 LGPL 或其他自由軟體授權）涵蓋的現有檔案中時，沒有理由指出哪些部分是公共領域。聲明整個檔案都在 GPL（或其他授權）下的聲明在法律上就已足夠。
使用非公共領域的程式碼，而是根據 GPL 相容的自由授權發布的程式碼，可能需要保留著作權聲明或其他步驟。當然，您應該遵守規定的要求。
上一篇：非 FSF 著作權套件，上一層：從其他套件複製 [目錄][索引]
如果您正在維護 FSF 擁有著作權的套件，請在複製任何程式碼之前，先驗證我們是否擁有該程式碼的適當法律文件。
如果您從另一個 FSF 擁有著作權的套件複製，那麼我們大概擁有該套件自身程式碼的文件，但您必須檢查您複製的程式碼是否是外部函式庫的一部分；如果是這種情況，我們沒有該函式庫的文件，因此您不應複製它。無論如何，向該套件的開發人員再次確認一下總是沒有壞處的。
當您複製我們尚未擁有文件的程式碼時，您需要取得該程式碼的文件。如果程式碼不是作為對您的套件的貢獻而編寫的，則可能難以取得文件，但這並不表示可以沒有文件。如果您無法取得程式碼的文件，您只能將其用作外部函式庫（請參閱外部函式庫）。
您應該在套件中每個重要的檔案中維護適當的著作權聲明和授權聲明。（任何超過十行的檔案都因此目的而言屬於重要檔案。）這包括標頭檔和用於建置或執行程式的介面定義、文件檔案和任何支援檔案。如果檔案已明確置於公共領域，那麼它應該有一個聲明明確指出它屬於公共領域的聲明，而不是著作權聲明。
即使是圖像檔案和聲音檔案，如果它們的格式允許，也應包含著作權聲明和授權聲明。某些格式沒有空間放置文字註釋；對於這些檔案，請在同一目錄的 README 檔案中說明著作權和複製權限。
變更日誌檔案應在末尾包含著作權聲明和授權聲明，因為新材料會新增在開頭，但末尾始終是末尾。
當檔案是從發行版中的其他檔案自動產生時，如果可能，自動程序最好複製產生它的檔案的著作權聲明和許可聲明。或者，在開頭放置一個聲明，說明它是從哪個檔案產生的。
著作權聲明看起來像這樣
Copyright (C) year1, year2, year3 copyright-holder
根據國際慣例， ‘Copyright’ 這個詞必須始終使用英文。
著作權持有人 可能是自由軟體基金會公司 (Free Software Foundation, Inc.)，也可能是其他人；您應該知道您的套件的著作權持有人是誰。
如果可以使用，請將 ‘(C)’ 替換為 C 圈符號。例如，在 Texinfo 檔案中使用 ‘@copyright{}’。但是，除非您知道 C 圈符號可以運作，否則請堅持使用括號 ‘C’。例如，程式的標準 --version 訊息應預設使用括號 ‘C’，儘管訊息翻譯可能會在已知該符號可運作的地區設定中使用 C 圈符號。或者，可以完全省略 ‘(C)’ 或 C 圈符號； ‘Copyright’ 這個詞就足夠了。
若要更新年份列表，請新增您對套件進行重大變更的每個年份。（這裡我們假設您正在使用公開可存取的版本控制伺服器，以便安裝的每個修訂版本也會立即自動發布。）當您新增新年份時，不需要追蹤哪些檔案在新的一年中發生重大變更，哪些檔案沒有。建議且更簡單的做法是將新年份新增到套件中的所有檔案，並在今年剩餘的時間內完成此操作。
但不要刪除舊的年份數字；它們很重要，因為它們表明如果電影公司沒有繼續購買法律以進一步延長著作權，較舊的版本理論上可能會進入公共領域。如果您從其他程式複製檔案到套件中，請保留檔案隨附的著作權年份。
如果且僅當：1) 範圍內的每個年份（包含在內）確實是「可取得著作權」的年份，本來會單獨列出；且 2) 您在 README 檔案中明確聲明此用法，則您可以使用範圍（‘2008-2010’）而不是列出個別年份（‘2008, 2009, 2010’）。
對於定期從另一個專案複製的檔案（例如 ‘gnulib’），請保留原始檔案中的著作權聲明。
著作權聲明可以跨越多行，無論是在原始碼檔案中還是在任何產生的輸出中。對於歷史悠久、出版年份眾多的檔案，通常會發生這種情況。
對於 FSF 擁有著作權的套件，如果您已遵循程序取得法律文件，則每個檔案都應只有一個著作權持有人：自由軟體基金會公司。您應該編輯檔案的著作權聲明，以列出該名稱且僅列出該名稱。
但是，如果貢獻者並非都將其著作權轉讓給單一著作權持有人，則很容易發生一個檔案有多個著作權持有人的情況。每個貢獻重要文本的貢獻者都是著作權持有人。
在這種情況下，您應始終包含以檔案主要著作權持有人名義發出的著作權聲明。您也可以包含其他著作權持有人的著作權聲明，對於貢獻大量內容的人以及明確要求以其姓名發出聲明的人來說，這是一個好主意。（有時，您複製的程式碼的授權可能需要保留某些著作權聲明。）但您不必為每個對檔案做出貢獻的人都包含聲明（這會非常不方便）。
有時，程式會有一個適用於整個程式的整體著作權聲明。它可能在 README 檔案中，或者可能在程式啟動時顯示。此著作權聲明應提及最新主要版本的完成年份；它可以提及先前主要版本的完成年份，但這是可選的。
每個重要的檔案都需要授權聲明以及著作權聲明。（如果沒有授權聲明授予複製和變更檔案的權限，則該檔案是非自由的。）
套件本身應包含 GPL 的完整副本（純文字格式，通常在名為 COPYING 的檔案中）和 GNU 自由文件授權條款（包含在您的文件中，因此無需單獨的純文字版本）。如果套件包含任何根據 Lesser GPL 發行的檔案，它也應包含其純文字版本的完整副本（通常在名為 COPYING.LESSER 的檔案中）。
如果您對 GNU 套件的授權問題有疑問，請寫信至 licensing@gnu.org。
| • 哪個 | ||
| • 規範 | ||
| • 程式碼 | ||
| • 文件 | ||
| • 範例 | ||
| • 其他 |
通常，GNU 套件應使用最新版本的 GNU GPL，並帶有「或任何更新版本」的措辭。有關授權聲明的確切措辭，請參閱程式碼的授權聲明。
偶爾，GNU 函式庫可能會提供專有程式透過替代實作已廣泛提供的功能；例如，GNU C 函式庫。在這種情況下，應使用 Lesser GPL（同樣，關於聲明措辭，請參閱程式碼的授權聲明）。但是，如果 GNU 函式庫提供獨特的功能，則應使用 GNU GPL。https://gnu.dev.org.tw/licenses/why-not-lgpl.html 討論了此策略選擇。
其中一些函式庫需要與根據僅限 GPLv2 發行的程式一起使用；也就是說，允許 GNU GPL 第 2 版但不允許更新版本。在這種情況下，GNU 套件應以雙重授權發行：GNU GPL 第 2 版（或任何更新版本）和 GNU Lesser GPL 第 3 版（或任何更新版本）。以下是這種情況下的聲明
This file is part of GNU package.
GNU package is free software: you can redistribute it and/or
modify it under the terms of either:
* the GNU Lesser General Public License as published by the Free
Software Foundation; either version 3 of the License, or (at your
option) any later version.
or
* the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your
option) any later version.
or both in parallel, as here.
GNU package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received copies of the GNU General Public License and
the GNU Lesser General Public License along with this program. If
not, see https://gnu.dev.org.tw/licenses/.
對於小型套件，您可以使用「This program」（此程式）而不是 「GNU package」（GNU 套件）。
您可以從多個地方取得這些檔案的官方版本。您可以使用對您來說最方便的任何一個。
gnulib 專案位於 savannah.gnu.org 上，您可以透過匿名 Git 或 CVS 存取。請參閱 https://savannah.gnu.org/projects/gnulib。授權條款的官方 Texinfo 來源也在這些相同的地方提供，因此您可以將它們包含在您的文件中。GFDL 涵蓋的手冊應以這種方式包含 GFDL。請參閱 Texinfo 中的 GNU 範例文字，以取得 Texinfo 手冊中的完整範例。
通常，程式檔案（包括建置腳本、設定檔和 makefile）的授權聲明應引用 GPL，如下所示
此檔案是 GNU package 的一部分。
GNU package 是自由軟體：您可以根據自由軟體基金會發布的 GNU 通用公共授權條款重新發布和/或修改它，無論是授權條款的第 3 版，或是（由您選擇）任何更新版本。
發行 GNU package 是希望能對您有所幫助，但不提供任何擔保；甚至不提供適銷性或特定用途適用性的暗示擔保。請參閱 GNU 通用公共授權以取得更多詳細資訊。
您應該已收到隨此程式一起提供的 GNU 通用公共授權副本。如果沒有，請參閱 https://gnu.dev.org.tw/licenses/。
但在只有幾個檔案的小型程式中，您可以使用以下內容代替
此程式是自由軟體：您可以根據自由軟體基金會發布的 GNU 通用公共授權條款重新發布和/或修改它；無論是授權條款的第 3 版，或是（由您選擇）任何更新版本。
發行此程式是希望能對您有所幫助，但不提供任何擔保；甚至不提供適銷性或特定用途適用性的暗示擔保。請參閱 GNU 通用公共授權以取得更多詳細資訊。
您應該已收到隨此程式一起提供的 GNU 通用公共授權副本。如果沒有，請參閱 https://gnu.dev.org.tw/licenses/。
在任一種情況下，對於少數使用 Lesser GPL 的套件（請參閱GNU 套件的授權），請在所有三個位置的「通用 (General)」之前插入「Lesser」一詞。https://gnu.dev.org.tw/licenses/gpl-howto.html 更詳細地討論了 GPL 的應用。
下一篇：程式碼範例的授權聲明，上一篇：程式碼的授權聲明，上一層：授權聲明 [目錄][索引]
文件檔案也應具有授權聲明。手冊應使用 GNU 自由文件授權條款。以下是在著作權行之後使用的授權聲明範例，其中使用了 GFDL 的所有功能。
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'', with the Front-Cover Texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled ``GNU Free Documentation License''. (a) The FSF's Back-Cover Text is: ``You have the freedom to copy and modify this GNU manual. Buying copies from the FSF supports it in developing GNU and promoting software freedom.''
如果 FSF 未以紙本形式發行本手冊，則省略 (a) 中關於從 GNU Press 取得副本的最後一句話。如果 FSF 不是著作權持有人，則將 ‘FSF’ 替換為適當的名稱。
請根據您的手冊調整不變章節列表。如果沒有不變章節，則說「with no Invariant Sections」（沒有不變章節）。如果您的手冊不是由 FSF 發行，且頁數少於 400 頁，您可以省略封面文字。但是，如果著作權歸 FSF 所有，請務必詢問 FSF 該怎麼做。
請參閱 Texinfo 中的 GNU 範例文字，以取得 Texinfo 手冊中的完整範例，並參閱 https://gnu.dev.org.tw/licenses/fdl-howto.html 以取得關於如何使用 GNU FDL 的更多建議。
如果您編寫的手冊人們可能會想購買紙本，請寫信至 maintainers@gnu.org 告知 FSF。我們可能會想出版它。
如果手冊超過 400 頁，或者如果 FSF 認為它可能是紙本出版的好選擇，請包含 GNU GPL，如上面的聲明所示。另請包含我們的標準不變章節，其中說明了自由文件的重要性。寫信至 assign@gnu.org 以取得此章節的副本。
當您在一個軟體套件中一起發行多個手冊時，它們的線上形式可以共用 GFDL 的單一副本（請參閱第 6 節）。但是，印刷的（‘.dvi’、‘.pdf’、…）形式應各自包含 GFDL 的副本，除非它們設定為僅一起印刷和發行。因此，通常最簡單的做法是在每個手冊中都包含 GFDL。
當文件中的程式碼範例超過兩三行，且足夠具體以至於人們可能想要複製和改編它時，我們建議將範例副本放在程式碼檔案中，並根據某些自由軟體授權發行。這表示它將根據兩個不同的授權發行：手冊中根據 GFDL，程式碼範例檔案中根據軟體授權。
如果範例很重要且不平凡，且有 40 行或更多行，我們建議根據與其相關程式相同的授權發行程式碼副本。否則，我們建議根據 X11 授權發行。
上一篇：程式碼範例的授權聲明，上一層：授權聲明 [目錄][索引]
小型支援檔案、簡短手冊（少於 300 行）和粗略文件（README 檔案、INSTALL 檔案等）可以使用像這樣簡單的完全許可授權
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.
此授權的舊版本沒有包含明確的擔保免責聲明的第二句話。沒有迫切需要更新現有檔案，但新檔案應使用新文本。
如果您的套件發行 Autoconf 巨集，這些巨集旨在由第三方套件在可能不相容的授權下使用（因此發行），您也可以對這些巨集使用上述完全許可授權。
這些類型的檔案也可以放入公共領域。如果在美國發行，插入聲明即可。否則，請使用 Creative Commons 的 CC0 — 請參閱 https://creativecommons.org/choose/zero/。
作為 FSF 擁有著作權的 GNU 套件的維護者，您如何使用單獨發布的通用自由模組？（我們也稱它們為「函式庫」，因為我們將它們用作函式庫；它們是否封裝為函式庫並不重要。）
要求其作者將著作權轉讓給 FSF 是不合理的。他們編寫這些模組並不是為了貢獻給 GNU。我們只是剛好想使用它們，就像任何開發人員一樣。無緣無故地要求開發人員將其著作權授予 FSF 是不禮貌的。在這種情況下請不要提出這種要求。
使用這些模組的正確方法是將您的套件與它們連結，並聲明它們不是您套件的一部分。請參閱下文了解其機制。
為避免目前或未來的法律問題，您必須確保模組的授權與目前和未來 GPL 版本相容。「GNU GPL 第 3 版或更新版本」很好，任何包含允許在這些 GPL 版本下使用的許可也很好（包括「GNU GPL 第 2 版或更新版本」、「LGPL 第 n 版或更新版本」、「LGPL 第 2.1 版」、「GNU Affero GPL 第 3 版或更新版本」）。寬鬆的許可授權也可以，因為它們與所有 GPL 版本相容。
「僅限 GPL 第 2 版」顯然是不可接受的，因為它與 GPL 第 3 版不相容。「僅限 GPL 第 3 版」和「僅限 GPL 第 2 或 3 版」有一個更細微的問題：如果我們發布 GPL 第 4 版，它們將與 GPL 第 4 版不相容，因此該模組將成為將您的套件授權升級到「GPL 第 4 版或更新版本」的障礙。請勿使用此類模組。
您需要避免使用的一個函式庫是 goffice，因為它僅允許 GPL 第 2 版和第 3 版。
因此，以下是如何安排您的套件以使用不相關的自由模組的機制。
使用此方法，沒有必要將模組視為函式庫並從中建立 ‘.a’ 檔案。您可以像往常一樣直接與 ‘.o’ 檔案連結。
這兩種方法都會造成不規則性，我們的律師已告知我們應盡量減少此類不規則性的數量。因此，僅對不是為您的套件編寫的通用模組使用這些方法。對於任何作為對您的套件的貢獻而編寫的內容，請取得簽署的文件。
嚴格來說，這不是法律問題，但它似乎與著作權聲明有關。
在任何 FSF 擁有著作權的 GNU 套件中，檔案的作者都不會在著作權聲明中被提及。因此，最好在著作權聲明附近的頂部包含註解行 ‘Authors: authors of this file’（作者：此檔案的作者），以表彰他們與其貢獻密切相關的功勞。
不要覺得有義務包含其他人要求您包含的每個變更。您必須判斷哪些變更是改進 — 部分基於您認為使用者會喜歡什麼，部分基於您自己對什麼更好的判斷。如果您認為變更不好，您應該拒絕它。
如果有人向您發送有用的變更，但編寫方式醜陋或難以理解且未來難以維護，請毫不猶豫地要求對方在您合併變更之前清理他們的變更。由於我們可以做的工作量有限，我們越說服其他人幫助我們有效率地工作，GNU 的發展速度就越快。
如果貢獻者不願意或無法使變更變得足夠乾淨，那麼可以合法地說「我無法以目前的形式安裝它；只有在您清理乾淨後我才能安裝。」邀請對方以其他方式發行他們的變更，或尋找其他人使其變得足夠乾淨，以便您安裝和維護。
自己進行這些清理的唯一理由是 (1) 它很容易，比告訴作者要清理什麼更省事，或者 (2) 變更很重要，重要到值得清理它的工作。
當您要求人們清理變更時，GNU 程式碼標準是一個很好的發送對象（請參閱 GNU 程式碼標準 中的 目錄）。Emacs Lisp 手冊包含一個附錄，其中提供了 Emacs Lisp 程式的程式碼標準；最好敦促 Lisp 作者閱讀它（請參閱 GNU Emacs Lisp 參考手冊 中的 提示和慣例）。
大多數 GNU 套件都在廣泛的平台上執行。這些平台的重要性並不相同。GNU 套件要支援的最重要平台是 GNU 作業系統的自由變體，無論它使用哪個核心。
GNU 專案的實際工作是開發 GNU 作業系統；GNU 套件應使整個 GNU 系統更強大，並鼓勵人們切換到該系統。
請在您的工作中牢記這些目標。例如，您新增的每個新功能都應在 GNU 上運作。如果新功能僅在 GNU（例如，在 GNU/Linux 上）執行，這是可以接受的。但是，僅在其他系統上執行而不適用於 GNU 的功能會破壞目標。
因此，當被要求實作這樣的功能時，請拒絕，並引用這些原因，並要求貢獻者也為 GNU 系統實作該功能。請參閱不應接受的修補程式。
您自然會希望保持程式在它支援的所有平台上執行。但您個人將無法存取大多數這些平台 — 那麼您應該如何處理它們呢？
不要擔心嘗試存取所有這些平台。即使您可以存取所有平台，您自己在每個平台上測試程式也是沒有效率的。相反，您應該在少數平台上測試程式，包括 GNU 的一些自由變體，並讓使用者在其他平台上測試它。您可以在正式發布之前的預先測試階段執行此操作；當沒有理由預期會出現問題時，尤其是在主要可移植的套件中，您可以直接發布並讓使用者告訴您是否引入了任何不可移植的內容。
在 GNU 或 GNU/Linux 上親自測試程式非常重要，因為這些是 GNU 套件最重要的平台。如果您無法存取其中一個平台，作為 GNU 維護者，您可以存取通用的 GNU 登入機器；請參閱 https://gnu.dev.org.tw/software/README.accounts.html。
支援其他平台是可選的 — 當這似乎是個好主意時，我們會這樣做，但我們不認為這是必須的。如果使用者不照顧特定平台，您可能必須取消對它的支援，除非且直到有使用者挺身而出提供協助。相反，如果使用者提供變更以支援其他平台，您可能會想安裝它們，但您不必這樣做。如果您覺得變更複雜且難看，如果您認為它們會增加未來維護的負擔，您可以並且應該拒絕它們。這包括自由或主要自由的平台，例如 OpenBSD、FreeBSD 和 NetBSD，以及非自由平台，例如 Windows。
維護程式包括接收使用者建議的修補程式並決定安裝哪些修補程式。在大多數情況下，這是一個技術優缺點的問題，作為維護者，您將權衡和判斷。
但是，有些修補程式存在根本的道德問題，因此您不應接受它們，除非/直到這些問題得到解決。
| • 非僅限 GNU 的功能 | GNU 套件中的每個功能都應在 GNU 上運作。 | |
| • 與非自由軟體的互通性 | 不要為了與非自由軟體互通操作而做得比自由軟體更好。 | |
| • 存放庫中未安裝的程式碼 | 將程式碼放入套件存放庫但不安裝它。 |
下一步：與非自由軟體的互通操作，上一層：不應接受的修補程式 [目錄][索引]
請不要編寫或安裝在 GNU 系統上功能會比某些非 GNU 系統更差或更少（或沒有）的功能的程式碼。
任何 GNU 程式的主要目的是增強 GNU 系統賦予使用者自由的能力，因此 GNU 套件的每個功能都應該在 GNU 作業系統的自由發行版（https://gnu.dev.org.tw/distros/）上可用且有用。就此而言，「功能」是指對使用者來說實質上有用的操作，而不是實作的技術細節。我們在下面進一步解釋這一點。
僅在某些非 GNU 作業系統上運作或在這些系統上運作更好的功能，會破壞主要目的；更糟的是，它會以 GNU 為代價來推廣該非 GNU 系統。這種情況會直接與將使用者從這些系統中解放出來的目標背道而馳，即使安裝造成這種情況的功能，就「開放原始碼」哲學而言，會被視為是理想的。
由於使用電腦的自由是總體目標，我們需要明確地朝著這種自由邁進。我們需要透過我們的實際決策—以及我們對這些決策的解釋—來表明，我們所致力的是比「更好的軟體」和「更方便」更深刻和更重要的東西。這將讓使用者有機會反思我們採取與大多數程式設計師不同的道路的原因。請參閱 https://gnu.dev.org.tw/philosophy/open-source-misses-the-point.html。
因此，當您作為 GNU 維護者收到對 GNU 系統不起作用的功能的貢獻時，請解釋此規則以及其必要性。解釋說我們需要 GNU 套件中的所有功能在 GNU 系統上正常運作，以便它們相互增強並使 GNU 系統更好。因此，變更不應以目前的形式安裝。
這並不表示變更永遠不能安裝。如果並且當在 GNU 系統上對相同功能的同等良好的支援可以同時安裝時，它可以稍後安裝。解釋這一點是要求人們協助編寫程式碼以在 GNU 上支援該功能的好機會。也告知貢獻者有關如何支援 GNU 上此功能的資源，以便他/她可以考慮完成該工作—或招募其他人來協助。
如果程式碼的某些部分是與系統無關的，並且將在 GNU 系統上支援功能方面完成部分工作，您可以立即安裝它們。或者您可以將它們放入套件存放庫中，而無需實際安裝它們，放在 ‘wip-name’ 分支中。將它們放在存放庫中可能有助於並鼓勵人們完成在 GNU 上實作該功能。
如果您認為它非常重要，您可以自己實作對 GNU 系統上該功能的支援。如果您認為在 GNU 上有一天擁有該功能是非常理想的，您可以做出特別安排，將非 GNU 系統特定的程式碼放入套件存放庫中，但不安裝它—請參閱 存放庫中未安裝的程式碼。
如果某個功能在 GNU 上至少與在非 GNU 系統上一樣好地運作，即使它在不同的系統上以不同的方式實作，在其實作中使用不同的系統設施，或在某些細節上對使用者來說看起來不同，也是可以接受的實作或支援非 GNU 系統的功能。在每個系統上，以方便或傳統的方式實作這些小細節以使功能運作是可以接受的。重點是程式和功能應該「在 GNU 上執行得最好」。
如果某些其他系統上的系統設施在沒有任何特殊應用程式程式碼的情況下，提供了 GNU 上沒有的功能，則無需進行工作來阻止其運作。在這種情況下，我們應該努力在 GNU 中實作該功能。
我們不將控制或配置特定操作的介面的小細節，或實作操作的細節視為「功能」。同樣地，系統設施（包括系統隨附的函式庫）是實作功能的手段，但設施的使用本身並不是功能。
例如，程式設計平台通常提供一個介面，用於在低層級控制電腦或作業系統。在非 GNU 系統上支援低層級控制功能是可以的，前提是套件也支援 GNU 系統上的相同功能，即使從系統到系統，調用該功能的細節有所不同。但是，請務必使跨系統的功能調用保持一致，以實現多個系統上支援的特定操作。
主要用於與其他使用者的電腦或未設定為作為群組緊密耦合使用的電腦之間進行通訊的功能，完全是另一回事。只有當通訊功能與 GNU 系統的自由發行版互通操作時，例如 TCP/IP，它才真正「與 GNU 上的功能相同」。用於非 GNU 系統的不可移植、系統特定的通訊設施是對社群的濫用，因此請勿安裝對它們的支援。如果曾經有機會在不相關的電腦之間移動這些檔案，則此點也適用於用於程式之間通訊的檔案格式。（例外：如果您可以做到，編寫程式碼從此類檔案中提取使用者的資料是值得讚賞的。）
最後，請注意不要讓安裝或支援非 GNU 系統的系統特定程式碼佔用您太多時間。請參閱 GNU Coding Standards 中的 GNU 編碼標準。
假設人們要求在某些非 GNU 系統上支援功能 F，而功能 F 在 GNU 上確實有效。如果您願意，您可以說是，但您沒有義務編寫或維護該程式碼。您可以告訴他們，編寫和維護它是他們的責任。如果他們為其編寫了良好且乾淨的程式碼，您可以批准其安裝，但這並不表示您或任何其他人有義務支援它。如果有一天程式碼遭受位元腐爛，如果使用者不修復它，您可以刪除它。
請參閱 建議的回應，其中提供了一些您可以使用的文字或改編的文字，如果您願意，可以用來拒絕這些修補程式。它的目的是邀請他們在新功能中同等地支援 GNU 系統。如果沒有希望，只需「不，謝謝」就足夠了。
下一步：存放庫中未安裝的程式碼，上一步：僅限非 GNU 功能，上一層：不應接受的修補程式 [目錄][索引]
在 GNU 程式中實作功能以使其方便地與廣泛使用的非自由工具和應用程式一起運作是很常見的。但是在某些情況下，您不應該實作與非自由程式的合作，我們在這裡可以將其稱為 ShackleMe。
請參閱 建議的回應，其中提供了一些您可以使用的文字，如果您願意，可以用來表明您拒絕支援 ShackleMe，除非對 ShackleMe 的自由競爭對手提供同等良好的支援。其目的是邀請貢獻者支援這些競爭對手。您可以根據需要修改它以適應情況。
上一步：與非自由軟體的互通操作，上一層：不應接受的修補程式 [目錄][索引]
當您想要將非 GNU 功能的系統相關程式碼放入套件存放庫中，而無需實際安裝它時，您需要與 GNU 專案進行特別安排。
為此，您寫信給 maintainers@gnu.org 並解釋該功能、其對其他系統的依賴性，以及阻止在 GNU 上支援它的障礙。他們將確保您了解情況和安排，並讓您承諾如果該功能未完成，稍後以適當的方式使分支消失。
實際上，這些特殊安排意味著您將程式碼放入套件存放庫中的不鼓勵分支中，以表明它未安裝，您沒有完成它的承諾，並且它可能會消失。將分支命名為 ‘ungnu-temp/name’。（如果該名稱與您使用的版本控制系統不符，我們將制定一個解決方案。）
在分支中放入一個 README 檔案，內容如下
This code partially implements the what is it feature. We can't install it now because it needs to be finished, so that it runs on the GNU system. We invite you to write the missing code to implement this feature on GNU, so we can install the feature. Until then, this branch must not be merged into any branch that might ever be released. See the section "Don't Install a Feature Until It Works on GNU", in the GNU Maintainer's Guide, for explanation of the reasons for this.
不鼓勵分支「消失」是因為您不從程式開發的主幹合併變更。如果分支變得太過時而無法完全運作，您只需刪除它即可。
本章描述如何為您的套件設定郵件列表，並在您擁有郵件列表後，提供有關如何處理錯誤報告和隨機請求的建議。
| • 標準郵件列表 | ‘bug-pkg@gnu.org’ 和其他標準名稱。 | |
| • 建立郵件列表 | 最好的方法是使用 Savannah。 | |
| • 回覆郵件 | 有關回覆收件郵件的建議。 |
一旦程式投入使用，您將收到有關它的錯誤報告。大多數 GNU 程式都有自己的特殊列表，用於發送錯誤報告。廣告宣傳的錯誤報告電子郵件地址應始終為 ‘bug-package@gnu.org’，以幫助向使用者表明該程式是 GNU 套件，但如果您願意，可以將該列表設定為轉發到另一個站點。
我們還有一個包羅萬象的列表，bug-gnu-utils@gnu.org，用於所有沒有自己特定列表的 GNU 程式。但如今，我們希望為每個程式提供自己的錯誤報告列表，並逐漸擺脫使用 bug-gnu-utils。
請參閱 回覆郵件，以了解有關處理和追蹤錯誤報告的更多資訊。
一些擁有大量使用者的 GNU 程式有一個幫助列表 ‘help-package@gnu.org’，供人們向其他使用者尋求幫助。如果您的程式有很多使用者，您應該為它建立這樣一個列表。對於一個相當新的程式，它還沒有龐大的使用者群，最好不要費心去做。
如果您願意，您也可以擁有一個郵件列表 ‘info-package@gnu.org’ 用於公告（請參閱 公告）。您可以建立您認為有用的任何其他郵件列表。
套件發行版應在顯眼的位置說明所有套件的郵件列表的名稱，並要求使用者透過適當地報告錯誤來幫助我們。頂層 README 檔案和/或 AUTHORS 檔案是不錯的位置。郵件列表資訊也應包含在手冊和套件網頁中（請參閱 網頁）。
到目前為止，使用 savannah.gnu.org 上的網頁介面是建立普通郵件列表的最簡單方法，這些郵件列表透過 GNU 郵件伺服器上的 Mailman 進行管理。一旦您在 Savannah 上註冊了您的套件，您就可以透過「郵件列表」選單自己建立（和移除）列表，而無需等待任何其他人介入。此外，透過 Savannah 建立的列表將具有針對反垃圾郵件目的的合理預設配置（請參閱下文）。
要建立和維護簡單的別名和非託管列表，您可以編輯主 GNU 伺服器上的 /com/mailer/aliases。如果您在那裡沒有帳戶，請閱讀 https://gnu.dev.org.tw/software/README.accounts.html（請參閱 GNU 帳戶和資源）。
但是如果您不想學習如何做這些事情，您可以要求 new-mailing-list@gnu.org 幫助您。
您應該審核來自您的郵件列表上未訂閱地址的貼文，以防止將不需要的訊息（「垃圾郵件」）傳播給訂閱者和列表封存檔。對於由 Mailman 控制的列表，您可以透過將 Privacy Options - Sender Filter - generic_nonmember_action 設定為 Hold 來執行此操作，然後定期（最好是每天）審閱保留的訊息，接受真實的訊息並丟棄垃圾訊息。
透過 Savannah 建立的列表將具有此設定以及許多其他設定，以便垃圾郵件將被自動刪除（在短暫延遲後）。Savannah 郵件列表頁面描述了所有詳細資訊。您仍然應該審閱保留的訊息，以便批准任何真實的訊息。
當您收到錯誤報告時，請記住錯誤報告對您的工作至關重要。如果您不知道問題，您就無法修復它們。因此，始終感謝每個發送錯誤報告的人。
但是，您沒有義務給予更多的回應。錯誤報告的主要目的是透過改進程式的下一個版本來幫助您為社群做出貢獻。許多報告錯誤的人沒有意識到這一點—他們認為重點是讓您個別幫助他們。有些人會要求您專注於而不是改進程式。如果您順從他們的願望，您將會從維護程式的工作中分心。
例如，人們有時會以模糊（因此無用）的方式報告錯誤，當您要求提供更多資訊時，他們會說：「我只是想看看您是否已經知道解決方案」（在這種情況下，錯誤報告將無助於改進程式）。當這種情況發生時，您應該向他們解釋錯誤報告的真正目的。（罐頭式的解釋會使這更有效率。）
當人們要求您投入時間來幫助他們使用程式時，做他們要求的事情似乎「有幫助」。但是，這遠不如改進程式有幫助，而改進程式才是維護者的真正工作。
當您感覺到自己有時間時，請盡一切努力幫助個別使用者。但是請注意限制您花費在這上面的時間量—不要讓它蠶食您維護程式所需的時間！知道如何拒絕；當您時間緊迫時，只需「謝謝您的錯誤報告—我會修復它」就足夠了。
一些 GNU 套件，例如 Emacs 和 GCC，附帶了關於如何使錯誤報告有用的建議。複製和改編它可能對您的套件非常有用。
如果您想使用基於電子郵件的錯誤追蹤系統，請參閱 https://bugs.gnu.org；這可以與常規錯誤報告地址連接。或者，如果您想使用基於網頁的錯誤追蹤系統，Savannah 支援此功能（請參閱 舊版本），但請不要拒絕透過常規電子郵件接收錯誤—我們不想對使用者提交報告設置不必要的障礙。
保留所有 GNU 原始碼檔案的備份檔案非常重要。如果您願意，可以使用原始碼控制系統（例如 Bazaar、RCS、CVS、Git、Subversion 等）來執行此操作。使用許多此類系統的簡單方法是透過 Emacs 中的版本控制函式庫（請參閱 The GNU Emacs Manual 中的 版本控制簡介）。
先前修訂版的歷史記錄和日誌條目對於套件的未來維護者非常重要，因此即使您不公開訪問它，也要注意不要在存放庫或變更日誌中放入任何您不想在某天移交給另一個維護者的內容。
GNU 專案提供了一個伺服器，GNU 套件可以用於原始碼控制和其他套件需求：savannah.gnu.org。Savannah 由 savannah-hackers@gnu.org 管理。有關使用和貢獻 Savannah 的更多詳細資訊，請參閱 https://savannah.gnu.org/maintenance。
這不是絕對的要求，但強烈鼓勵所有 GNU 維護者利用 Savannah，因為共享這樣一個中心點可以促進 GNU 開發人員之間的社群意識，並有助於跟上專案管理。請不要將 Savannah 專案標記為 GNU 套件的私有專案；這在很大程度上違背了首先使用 Savannah 的目的。
如果您確實使用 Savannah，請訂閱 savannah-announce@gnu.org 郵件列表（https://lists.gnu.org/mailman/listinfo/savannah-announce）。這是一個非常低流量的列表，用於讓 Savannah 使用者了解系統升級、問題等。
製作 GNU 軟體發行版時，請遵循 GNU 慣例。
| • 發行版 tar 檔案 | ||
| • 發行版修補程式 | ||
| • 二進制發行版 | ||
| • ftp.gnu.org 上的發行版 | ||
| • 測試發行版 | ||
| • 自動化 FTP 上傳 | ||
| • 公告 |
所有套件都應提供 tar 檔案，用於發行其發行版。程式 foo 的 m.n 版本的 tar 檔案應命名為 foo-m.n.tar。它應解壓縮到名為 foo-m.n 的子目錄中。Tar 檔案不應解壓縮到目前目錄中的檔案中，因為如果使用者碰巧解壓縮到一個包含其他檔案的目錄中，這是不方便的。
以下是 Bison 的 Makefile 如何建立 tar 檔案。此方法適用於其他程式。
dist: bison.info
echo bison-`sed -e '/version_string/!d' \
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
-rm -rf `cat .fname`
mkdir `cat .fname`
dst=`cat .fname`; for f in $(DISTFILES); do \
ln $(srcdir)/$$f $$dst/$$f || { echo copying $$f; \
cp -p $(srcdir)/$$f $$dst/$$f ; } \
done
tar --gzip -chf `cat .fname`.tar.gz `cat .fname`
-rm -rf `cat .fname` .fname
符號連結到其他檔案系統的原始碼檔案無法使用 ln 安裝在暫存目錄中，因此如果 ln 失敗，請使用 cp。
使用 Automake 是處理編寫 dist 目標的好方法。
下一步：二進制發行版，上一步：發行版 tar 檔案，上一層：發行版 [目錄][索引]
如果程式很大，為每個發行版製作一組針對先前重要發行版的差異是有用的。
在差異集的前面，簡要說明這是哪個版本，以及它是相對於哪個先前版本的。還應說明人們需要做哪些其他事情才能正確更新原始碼（例如，在安裝差異之前刪除或重新命名某些檔案）。
擁有差異的目的是它們很小。為了保持它們的小巧，請排除使用者可以輕鬆更新的檔案。例如，排除 info 檔案、DVI 檔案、標籤表、Bison 或 Flex 的輸出檔案。在 Emacs 差異中，我們排除了編譯後的 Lisp 檔案，讓安裝程式重新編譯修補過的原始碼。
當您製作差異時，每個版本都應放在適當命名的目錄中—例如，gcc-2.3.2 和 gcc-2.3.3。這樣，從差異本身就可以非常清楚地看出哪個版本是哪個版本。
如果您使用 GNU diff 來製作修補程式，請使用選項 ‘-rc2P’。這會將任何新檔案作為「完全不同」放入輸出中。此外，修補程式的上下文差異標頭應具有使用傳統 Unix 格式的通用時間的日期和時間，以便修補程式接收者可以使用 GNU patch 的 ‘-Z’ 選項。例如，您可以使用以下 Bourne shell 命令來建立修補程式
LC_ALL=C TZ=UTC0 diff -rc2P gcc-2.3.2 gcc-2.3.3 | \ gzip -9 >gcc-2.3.2-2.3.3.patch.gz
如果發行版中有子目錄，則差異可能包含子目錄中的某些檔案。為了幫助使用者可靠地安裝此類修補程式，請為他們提供關於如何執行修補程式的精確指示。例如，這樣說
To apply these patches, cd to the main directory of the program and then use ‘patch -p1’. ‘-p1’ avoids guesswork in choosing which subdirectory to find each file in.
明智的做法是透過將修補程式應用於舊版本的副本來測試您的修補程式，並檢查結果是否與新版本完全匹配。
下一步：ftp.gnu.org 上的發行版，上一步：發行版修補程式，上一層：發行版 [目錄][索引]
一些套件維護者發行用於專有系統（例如 Microsoft Windows 或 MacOS）的預編譯二進制檔案。是否這樣做完全取決於您；我們不要求您這樣做，但我們不反對。請不要讓任何人讓您覺得您有義務這樣做。
如果您發行它們，請顯著告知其使用者，這些非自由平台踐踏了他們的自由。將他們轉介到 https://gnu.dev.org.tw/philosophy/free-software-even-more-important.html 是有用的。您可以說：「此程式尊重您的自由，但 Windows 不尊重。為了擁有自由，您需要停止使用 Windows 和其他剝奪您自由的軟體。」
ftp.gnu.org 上發行我們強烈建議使用 ftp.gnu.org 來發行官方發行版。如果您還想從您自己的站點發行套件，那很好。使用其他站點而不是 ftp.gnu.org 是可以接受的，前提是它允許來自任何地方的任何人的連線。
請參閱 自動化 FTP 上傳，以了解將新版本放在 ftp.gnu.org 上的程序細節。
下一步：自動化 FTP 上傳，上一步：ftp.gnu.org 上的發行版，上一層：發行版 [目錄][索引]
當您發行程式的重大變更的新主要版本時，您可能希望將其作為預先測試來執行。這表示您製作一個 tar 檔案，但僅將其發送給您招募的一組志願者。（使用合適的 GNU 郵件列表/新聞群組來招募他們。）
我們通常使用伺服器 alpha.gnu.org 進行預先測試和預發行版本。請參閱 自動化 FTP 上傳，以了解將新版本放在 alpha.gnu.org 上的程序細節。
一旦程式被廣泛使用，並且人們期望它能穩固地運作，最好在每個「真實」發行版之前進行預先測試發行版。
有三種處理預先測試版本的版本號的方法。一種方法是將它們視為即將發行的版本之前的版本。
在此方法中，如果您即將發行 4.6 版，但您想先進行預先測試，請將其稱為 4.5.90。如果您需要第二次預先測試，請將其稱為 4.5.91，依此類推。如果您真的不幸，十次預先測試還不夠，在 4.5.99 之後，您可以進階到 4.5.990，依此類推。（您也可以使用 4.5.100，但 990 的優點是按正確的順序排序。）
另一種方法是將日期附加到即將發行的發行號碼。對於 2002 年 12 月 10 日製作的 4.6 版的預先測試，這將是 4.6.20021210。同一天製作的第二次預先測試可以是 4.6.20021210.1。
對於不是正式預先測試的開發快照，僅使用日期而不使用版本號也是可以的。
第三種方法，如果套件使用 Git，是執行來自 Gnulib 的腳本 build-aux/git-version-gen 以產生測試發行版版本號碼。它產生的版本號碼格式為 ‘version.commits-commithash’，其中 version 是最新的版本標籤，commits 是自該標籤以來的提交次數，而 commithash 是最新提交的雜湊碼。
您永遠不應該做的一件事是以與計劃的真實發行版相同的版本號發行預先測試。許多人只會查看版本號（在 tar 檔案名稱、它解壓縮到的目錄名稱或他們可以找到它的任何位置）來確定 tar 檔案是否為最新版本。人們可能會以這種方式查看測試發行版，並將其誤認為是真實發行版。因此，當您發行變更後的程式碼時，始終變更號碼。
為了將新發行版上傳到 ftp.gnu.org 或 alpha.gnu.org，您首先需要註冊必要的資訊。然後，您可以自己執行上傳，而無需系統管理員的介入。
一般概念是發行版在公開發布之前應經過加密簽署。
| • 自動化上傳註冊 | ||
| • 自動化上傳程序 | ||
| • FTP 上傳發行檔案三元組 | ||
| • FTP 上傳指令檔案 | ||
| • FTP 上傳目錄樹 | ||
| • FTP 上傳檔案替換 | ||
| • FTP 上傳獨立指令 | ||
| • FTP 上傳指令檔案 - v1.1 | ||
| • FTP 上傳指令檔案 - v1.0 |
下一步：自動化上傳程序，上一層：自動化 FTP 上傳 [目錄][索引]
以下是如何註冊您的資訊，以便您可以為您的 GNU 套件執行上傳
gpg --clearsign msgfile 對其進行 GPG 簽署，最後將產生的 msgfile.asc 作為附件電子郵件發送至 ftp-upload@gnu.org。可選但建議：將您的金鑰傳送到 GPG 公開金鑰伺服器：gpg --keyserver keys.gnupg.net --send-keys keyid...，其中 keyid 是 gpg --list-public-keys 在日期前的 pub 行報告的八個十六進制數字。關於 GPG 的完整資訊，請參閱 https://gnu.dev.org.tw/software/gpg。
當管理員新增了適當的 GPG 金鑰，授權您為相應的套件上傳檔案時，他們會確認您的訊息。
當上傳完成時，無論成功與否，上傳系統都會將收據透過電子郵件寄送到指定的電子郵件地址。
如果您稍後需要更新您的 GPG 金鑰，您必須將其重新提交給 Savannah 和 ftp-upload@gnu.org，因為這些系統並未連接。
下一步：FTP 上傳發佈檔案三檔案組，上一步：自動上傳註冊，上一層：自動 FTP 上傳 [目錄][索引]
一旦您按照上一節的描述註冊了您的資訊，您就可以而且應該為您的套件執行 ftp 上傳。有兩種基本的上傳類型（詳細資訊在以下章節中）
ftp.gnu.org 或 alpha.gnu.org 的檔案：請參閱 FTP 上傳發佈檔案三檔案組。在任何一種情況下，您都透過匿名 ftp 將檔案上傳到主機 ftp-upload.gnu.org。如果上傳目標是 ftp.gnu.org，請將檔案放在目錄 /incoming/ftp 中。如果上傳目標是 alpha.gnu.org，請將檔案放在目錄 /incoming/alpha 中。
上傳每五分鐘處理一次。在上傳處理腳本執行時正在進行的上傳會被正確處理，因此不用擔心上傳的時機。虛假和過時的上傳檔案會在 24 小時後自動刪除。
如果處理您的套件上傳時出現問題，您的指定上傳電子郵件地址（請參閱 自動上傳註冊）會收到訊息。當上傳成功處理時，您也會收到訊息。
創建和傳輸必要檔案的一種程式化方法是使用 gnupload 腳本，該腳本可從 gnulib 專案的 build-aux/ 目錄中取得，網址為 https://savannah.gnu.org/projects/gnulib。執行 gnupload --help 以取得描述和範例。（使用 gnupload，您可以指定目的地，例如 ‘ftp.gnu.org:’pkgname，而不是使用 ‘ftp-upload’ 主機名稱。）
gnupload 調用程式 ncftpput 執行實際傳輸；如果您碰巧沒有安裝 ncftp 套件，gnulib 的 build-aux/ 目錄中的 ncftpput-ftp 腳本可以作為替代方案。它使用純命令列 ftp 程式。
如果您在上傳時遇到困難，請發送電子郵件至 ftp-upload@gnu.org。您可以查看在 https://lists.gnu.org/archive/html/ftp-upload-report 處理的上傳檔案存檔。
通常，目標是上傳您套件的新版本，例如，來源封存檔 foo-1.0.tar.gz。為此，您需要同時上傳三個檔案
檔案的名稱很重要。簽名檔的名稱必須與要發布的檔案相同，並附加 .sig 副檔名。指令檔的名稱必須與要發布的檔案相同，並附加 .directive.asc 副檔名。如果您不遵循此命名慣例，上傳將不會被處理。
下一步：FTP 上傳目錄樹，上一步：FTP 上傳發佈檔案三檔案組，上一層：自動 FTP 上傳 [目錄][索引]
重申，（已簽署的）指令檔必須是每次上傳的一部分。未簽署的原始檔只是一個純文字檔案，您可以使用任何文字編輯器建立。其名稱必須是，例如，foo-1.0.tar.gz.directive，以伴隨 foo-1.0.tar.gz 的上傳。
建立檔案後，執行 ‘gpg --clearsign foo-1.0.tar.gz.directive’，這將建立 foo-1.0.tar.gz.directive.asc；這是要上傳的檔案。
當作為三檔案組的一部分用於上傳發佈檔案時，指令檔必須始終包含指令 version、filename 和 directory。此外，comment 指令是可選的。這些指令可以以任何順序給出。
繼續我們將名為 foo 的套件的 foo-1.0.tar.gz 上傳到 ftp.gnu.org 的範例，值將如下所示
version必須是值 ‘1.2’（截至 2012 年 5 月的目前版本）
version: 1.2
filename必須是要發布的檔案的名稱
filename: foo-1.0.tar.gz
directory指定上傳的檔案及其 .sig 夥伴要放置的最終目標目錄。在這裡，我們將把檔案放在套件的頂層目錄中，這是最常見的做法
directory: foo
comment是可選的，如果存在則忽略
comment: let's hope this works!
將以上所有內容放在一起，我們的範例中指令檔 foo-1.0.tar.gz.directive 的完整內容將是
version: 1.2 directory: foo filename: foo-1.0.tar.gz comment: let's hope this works!
然後您按照上述給出的方式 ‘gpg --clearsign’ 檔案，並（使用匿名 ftp）上傳三個檔案
到主機 ftp-upload.gnu.org，目錄 /incoming/ftp（用於官方發佈），或目錄 /incoming/alpha（用於測試發佈）。
在系統驗證簽名後，檔案 foo-1.0.tar.gz 和 foo-1.0.tar.gz.sig 會被放置在 ftp.gnu.org 上的 gnu/foo/ 目錄中。也就是說，我們將在 ‘https://ftp.gnu.org/gnu/foo/foo-1.0.tar.gz’ 提供我們的發佈版本（然後透過我們的許多鏡像站點，透過 ‘https://ftpmirror.gnu.org/foo/foo-1.0.tar.gz’）。呼～
上傳失敗的一個常見原因是您的 GPG 簽名未在上傳系統中註冊。沒有任何操作會自動執行此操作。您必須按照上述說明透過電子郵件聯絡系統管理員（請參閱 自動上傳註冊）。
下一步：FTP 上傳檔案替換，上一步：FTP 上傳指令檔，上一層：自動 FTP 上傳 [目錄][索引]
您可以在您的套件目錄下建立任何您喜歡的目錄層次結構。系統會自動建立您在 directory 指令中指定的任何中間目錄。
稍微修改上面的範例，以下指令檔
version: 1.2 directory: foo/foo-1.0 filename: foo-1.0.tar.gz comment: creates per-version subdirectory as needed
會將 tar 檔案放置在套件 foo 的 foo-1.0/ 子目錄中，最終路徑為 ‘ftp.gnu.org:gnu/foo/foo-1.0/foo-1.0.tar.gz’。
但是，為了讓使用者更簡單，我們建議不要使用子目錄，除非您的套件的每個發佈版本都包含許多單獨的檔案。
下一步：FTP 上傳獨立指令，上一步：FTP 上傳目錄樹，上一層：自動 FTP 上傳 [目錄][索引]
您可以透過包含指令行 replace: true 來替換已上傳的現有檔案。例如，您可能希望在發佈目錄中提供 README 檔案，並隨時更新它。該檔案的完整指令檔如下所示
replace: true version: 1.2 directory: foo filename: README comment: replaces an existing README
如果要替換的檔案尚不存在也沒關係；那麼新檔案只會被簡單地添加，也就是說，replace 指令不起作用。
當現有檔案被替換時，原始檔案會被封存到一個私人位置。沒有自動或公開的方式可以訪問這些封存的檔案；如果您想檢索或查看它們，請發送電子郵件至 sysadmin@fsf.org。
我們非常不建議替換實際的軟體發佈檔案，例如 foo-1.0.tar.gz。發佈版本應該是唯一的，並且永久存在。如果您需要進行修復，請建立另一個發佈版本。如果您有緊急理由需要讓特定發佈檔案不再可用，則可以明確地封存它，如下一節所述。
如果您想使用通用名稱（例如 foo-latest.tar.gz）提供當前發佈版本，最好使用符號連結來完成，這也在下一節中描述。
下一步：FTP 上傳指令檔 - v1.1，上一步：FTP 上傳檔案替換，上一層：自動 FTP 上傳 [目錄][索引]
前面的章節描述了如何上傳要公開發佈的檔案。也可以單獨上傳指令檔，以對上傳目錄執行一些操作。支援的指令有
symlink建立符號連結。
rmsymlink移除符號連結。
archive使檔案或目錄離線。
至於上述描述的指令，directory 和 version 指令仍然是必需的，comment 指令仍然是可選的，並且不允許使用 filename 指令。
.sig 檔案不應在指令中明確提及。當您指定一個指令來操作檔案時，其對應的 .sig 檔案將會自動處理。
當單獨上傳時，指令檔的名稱並不重要。但它仍然必須簽署，使用 ‘gpg --clearsign’；結果產生的 .asc 檔案才是應該上傳的檔案。
以下是建立 foo-latest.tar.gz 符號連結的完整指令檔範例
version: 1.2 directory: foo symlink: foo-1.1.tar.gz foo-latest.tar.gz comment: create a symlink
如果您在獨立上傳中包含多個指令，則指令會按照它們在其中指定的順序執行。如果指令導致錯誤，則會中止上傳的進一步執行。
移除不存在的符號連結（使用 rmsymlink）會導致錯誤。另一方面，嘗試建立已存在的符號連結（使用 symlink）不會導致錯誤。在這種情況下，symlink 的行為類似於命令 ln -s -f：在建立連結之前，任何現有的符號連結都會被移除。（但現有的常規檔案或目錄不會被替換。）
以下是移除符號連結的範例，例如，如果您決定不再維護 foo-latest 連結
version: 1.2 directory: foo rmsymlink: foo-latest.tar.gz comment: remove a symlink
以下是封存檔案的範例，例如，意外上傳
version: 1.2 directory: foo archive: foo-1.1x.tar.gz comment: archive an old file; it will not be comment: publicly available any more.
archive 指令會導致指定的項目變得無法訪問。這應該僅在它們的可用性實際上是不利的情況下使用，例如，您錯誤地上传了某些東西。
如果您的目標只是減少發佈目錄中的內容，另一種方法是發送電子郵件至 sysadmin@fsf.org，並要求他們將舊項目移動到 https://ftp.gnu.org/old-gnu/ 目錄；這樣它們仍然可用。然而，總體而言，我們建議將所有官方發佈版本保留在主發佈目錄中。
下一步：FTP 上傳指令檔 - v1.0，上一步：FTP 上傳獨立指令，上一層：自動 FTP 上傳 [目錄][索引]
v1.1 版本的上傳協定缺少 replace 指令；相反，檔案替換是自動且靜默地完成的（顯然不受歡迎）。這是 v1.2 和 v1.1 之間唯一的區別。
上一步：FTP 上傳指令檔 - v1.1，上一層：自動 FTP 上傳 [目錄][索引]
對 v1.0 版本上傳的支援已於 2012 年 5 月終止；請升級到 v1.2。
在 v1.0 版本中，指令檔包含一行，不包括明文簽署的 GPG 插入數據，該行指定了項目 (1) 和 (2) 要放置的最終目標目錄。
例如，foo-1.0.tar.gz.directive.asc 檔案可能包含單行
directory: bar/v1
此目錄行表示 foo-1.0.tar.gz 和 foo-1.0.tar.gz.sig 是套件 bar 的一部分。如果您要將三檔案組上傳到 /incoming/ftp，並且系統可以正確驗證簽名，則檔案 foo-1.0.tar.gz 和 foo-1.0.tar.gz.sig 將被放置在 ftp.gnu.org 站點的 gnu/bar/v1 目錄中。
指令檔可用於建立目前不存在的目錄樹，只要它們位於您套件的套件目錄下（在上面的範例中，即 bar）。
當您有新發佈版本時，請發布公告。對於官方新發佈版本，包括僅為修復錯誤而發佈的版本，我們強烈建議使用（經過審核的）通用 GNU 公告列表 info-gnu@gnu.org。這樣做可以讓使用者和開發人員更容易找到最新的 GNU 發佈版本。另一方面，請不要在 info-gnu 上公告測試發佈版本，除非情況非常特殊。
也請在您的 Savannah 專案網站的新聞部分發布發佈公告。在這裡，也可以為測試發佈版本和任何其他有新聞價值的事件撰寫新聞條目。來自 savannah 上所有 GNU 專案的新聞提要都彙總在 https://planet.gnu.org (GNU Planet)，除非條目的文字包含字串 ‘::noplanet::’。您也可以直接發布項目，或安排從其他位置發送提要；請參閱 GNU Planet 網頁上的資訊。
如果您願意，您也可以維護自己的郵件列表（通常是 ‘info-package@gnu.org’）用於公告。對於您自己的列表，當然由您自行決定哪些事件值得公告。（有關設定此項以及更多關於處理您套件郵件的建議，請參閱 郵件。）
撰寫公告時，請包含以下內容
https://gnu.dev.org.tw/software/package/’）。https://ftp.gnu.org/gnu/package/’）。提及 https://gnu.dev.org.tw/order/ftp.html 的鏡像列表也很有用，並且 ‘https://ftpmirror.gnu.org/package/’ 將自動重新導向到附近的鏡像站點。您可能會發現 announce-gen 腳本對於建立公告很有用，該腳本可從 gnulib 專案的 build-aux/ 目錄中取得，網址為 https://savannah.gnu.org/projects/gnulib。
當我們將一個程式稱為 GNU 套件時，我們會將其 GNU 首頁（在 ‘https://gnu.dev.org.tw/software/’ 中命名為 package）列在 https://gnu.dev.org.tw/software/software.html 和 https://gnu.dev.org.tw/manual/manual.html 上。為了避免連結失效，網站管理員會建立一個臨時首頁，如下所示
https://savannah.gnu.org/projects/package’，其中應提供簡短描述。這個臨時首頁應該盡快被真正的首頁替換。
有些 GNU 套件只有簡單的網頁，但您提供的資訊越多越好。因此，請盡可能多地撰寫有用的資訊，並將所有資訊放在 www.gnu.org 上。但是，訪問資料庫的頁面（包括郵件存檔和錯誤追蹤）是例外；將它們設定在對您來說方便的任何站點上，並使 www.gnu.org 上的頁面連結到該站點。
您的網頁應遵循我們通常的標準（請參閱 https://gnu.dev.org.tw/server/fsf-html-style-sheet.html）。總體目標是支援各種瀏覽器，專注於資訊而不是視覺裝飾，並在某些重要方面保持 gnu.org/software/ 的一致性。
我們鼓勵您使用標準的 www.gnu.org 範本作為您頁面的基礎：https://gnu.dev.org.tw/server/standards/boilerplate-source.html。此範本會因各種原因而不時略有變化。如果變更影響現有的網頁，網站管理員會通知您；然後您可以進行變更，或者他們可以進行變更。
請在您的網頁中遵循最佳的可訪問性實踐（請參閱 https://gnu.dev.org.tw/accessibility/accessibility.html）。
| • 網頁託管 | ||
| • 網頁的自由 | ||
| • 網頁上的手冊 | ||
| • 網頁中的 CVS 關鍵字 |
維護您專案網頁的最佳方法是在 savannah.gnu.org 上註冊專案。然後您可以使用 CVS 編輯頁面，使用 Savannah 上提供的單獨的「網頁儲存庫」，該儲存庫對應於 ‘https://gnu.dev.org.tw/software/package/’。您也可以將您的原始碼檔案保存在那裡（使用各種版本控制系統中的任何一種），但如果您願意，您可以僅將 savannah.gnu.org 用於您的 gnu.org 網頁；只需註冊一個「僅限網頁」專案。
如果您不想使用該方法，請與 webmasters@gnu.org 討論其他可能的方法。例如，如果需要，您可以郵寄頁面給他們安裝。但這對他們來說是更多的工作，所以如果可以，請使用 Savannah。
請注意，GNU 網站管理員可能會修復您網頁中的技術細節（HTML、CSS、明顯的錯別字、頁腳中的失效連結等），並在之後通知您變更。
如果您使用 Savannah，您可以使用一個名為 .symlinks 的特殊檔案來建立符號連結，CVS 不支援符號連結。有關詳細資訊，請參閱 https://gnu.dev.org.tw/server/standards/README.webmastering.html#symlinks。
如果您使用 www.gnu.org 以外的站點，請確保該站點僅在自由軟體上運行。（如果站點使用未發佈的自訂軟體也沒關係，因為從瑣碎的意義上來說，那是自由軟體：只有一個使用者，並且它具有四種自由。）如果 GNU 套件的網站運行在非自由軟體上，公眾會看到這一點，並且這將具有授予非自由程式合法性的效果。
如果您使用多個站點，它們都應遵循該標準。請不要連結到關於您套件的網站，公眾可能會認為該網站與您的套件相關，並反映其開發人員的立場，除非該網站遵循該標準。
請確保可以使用 Lynx 瀏覽器以及啟用 LibreJS 的 IceCat 瀏覽器完整地使用該網站。它應該在 Tor 和不使用 Tor 的情況下都能正常工作。當然，該網站最好能支援盡可能多的其他瀏覽器。
從歷史上看，GNU 套件的網頁不包含 GIF 圖像，因為專利問題（請參閱 倫理和哲學考量）。儘管 GIF 專利已於 2006 年到期，但仍不建議使用 GIF 圖像，因為 PNG 和 JPEG 格式通常更優越。請參閱 https://gnu.dev.org.tw/philosophy/gif.html。
請確保您網頁中的任何 JavaScript 程式碼都受自由授權條款約束，並且其授權以 LibreJS 可以識別的方式指示。請參閱 https://gnu.org/philosophy/javascript-trap.html。如果頁面中的 JavaScript 已縮小，或由於任何其他原因不是原始碼，則必須按照那裡的描述指向其原始碼。
下一步：網頁中的 CVS 關鍵字，上一步：網頁的自由，上一層：網頁 [目錄][索引]
套件的網頁應包含其手冊，格式為 HTML、DVI、Info、PDF、純 ASCII 和原始碼 Texinfo。所有這些都可以使用 Makeinfo 和其他程式從 Texinfo 自動生成。如果 Texinfo 本身是從其他原始碼格式生成的，也請包含在內。
當只有一本手冊時，將其放在名為 manual 的子目錄中；檔案 manual/index.html 應包含指向手冊各種格式的連結。
如果套件有多本手冊，請將每本手冊放在 manual 的子目錄中，在每個子目錄中設定 index.html 以連結到該手冊的所有格式，並使 manual/index.html 通過其子目錄連結到每本手冊。
請參閱以下章節，了解有關腳本的詳細資訊，該腳本可以簡化建立所有這些不同格式和索引頁面的工作。
我們希望在 https://gnu.dev.org.tw/manual 頁面上列出所有 GNU 手冊，因此如果您的手冊不在那裡，請發送郵件至 webmasters@gnu.org，要求他們添加您的手冊，他們將根據您的 manual 目錄的內容進行添加。
| • 調用 gendocs.sh |
gendocs.shgendocs.sh 腳本簡化了為您上面的網頁部分生成 Texinfo 文件輸出的任務。它有一個配套的範本檔案，用作 HTML 索引頁面的基礎。兩者都可從 Gnulib 開發取得
https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gendocs.sh https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/gendocs_template
還有一個極簡範本，可從以下位置取得
像這樣調用腳本，在包含 Texinfo 原始碼的目錄中
gendocs.sh --email yourbuglist yourmanual "GNU yourmanual manual"
其中 yourmanual 是您套件的簡短名稱，yourbuglist 是錯誤報告的電子郵件地址（應為 bug-package@gnu.org）。腳本處理檔案 yourmanual.texinfo（或 .texi 或 .txi）。例如
cd .../texinfo/doc # download gendocs.sh and gendocs_template gendocs.sh --email bug-texinfo@gnu.org texinfo "GNU Texinfo manual"
gendocs.sh 建立一個子目錄 manual/，其中包含以所有標準輸出格式生成的手冊：Info、HTML、DVI 等，以及 Texinfo 原始碼。然後您需要將所有這些檔案（保留子目錄）移動到您套件的網頁中。
您可以指定選項 -o outdir 以覆蓋名稱 manual。outdir 的任何先前內容都將被刪除。
第二個參數，帶有描述，包含在整體 manual/index.html 檔案的 HTML <title> 中。它應包含正在記錄的套件的名稱，如所示。manual/index.html 是通過從檔案 gendocs_template 替換創建的。（隨時可以根據自己的目的修改通用範本。）
如果您有多本手冊，您需要使用不同的參數多次運行此腳本，每次使用 -o 指定不同的輸出目錄，並將所有輸出移動到您的網頁。然後（手動）編寫一個整體 index.html，其中包含指向所有手冊的連結。例如
cd .../texinfo/doc gendocs.sh --email bug-texinfo@gnu.org -o texinfo texinfo "GNU Texinfo manual" gendocs.sh --email bug-texinfo@gnu.org -o info info "GNU Info manual" gendocs.sh --email bug-texinfo@gnu.org -o info-stnd info-stnd "GNU info-stnd manual"
預設情況下，腳本使用 makeinfo 生成 HTML 輸出。如果您更喜歡使用 texi2html，請使用 --texi2html 命令列選項，例如
gendocs --texi2html -o texinfo texinfo "GNU Texinfo manual"
範本檔案將自動為 texi2html 生成的其他 HTML 輸出生成條目（即，按章節分割）。
您可以設定環境變數 MAKEINFO、TEXI2DVI 等，以控制要執行的程式，並設定 GENDOCS_TEMPLATE_DIR 以控制 gendocs_template 檔案的查找位置。
像往常一樣，運行 ‘gendocs.sh --help’ 以取得所有選項、環境變數和更多資訊的描述。
請將關於 gendocs 的錯誤報告、增強請求或其他信件發送至 bug-texinfo@gnu.org。
由於 www.gnu.org 通過 CVS 工作，因此您手冊中的 CVS 關鍵字（例如 $Log$）需要特殊處理（即使您碰巧沒有在 CVS 中維護您的手冊）。
如果這些關鍵字最終在生成的輸出中以文字字串形式出現，它們將被展開。處理此問題的最穩健方法是關閉此類生成檔案的關鍵字展開。對於現有檔案，這是通過
cvs admin -ko file1 file2 ...
對於新檔案
cvs add -ko file1 file2 ...
請參閱 CVS 手冊中的「Keyword Substitution」（關鍵字替換）章節，可從 https://cvs.nongnu.org 取得。
在 Texinfo 原始碼中，以文字方式指定「dollar」（美元）關鍵字的建議方法是
@w{$}Log$
@w 阻止 Texinfo 原始碼本身中的關鍵字展開。此外，makeinfo 會注意到 @w 並生成避免文字關鍵字字串的輸出。
GNU 專案對軟體自由採取堅定的立場。很多時候，這意味著當某些技術的使用會與我們的長期目標衝突時，您需要避免使用這些技術。
軟體專利威脅著自由軟體的發展和程式設計的自由。美國有如此多的軟體專利，以至於任何大型程式都可能實施數百種專利技術，而程式開發人員對此一無所知。嘗試尋找和避免所有這些專利將是徒勞且適得其反的。但是，我們知道有些專利很可能被用來威脅自由軟體，因此我們努力避免使用專利技術。如果您擔心專利的危險並希望獲得建議，請寫信至 licensing@gnu.org，我們將盡力幫助您從律師那裡獲得建議。
有時，GNU 專案會對特定的專利技術採取強硬立場，以鼓勵社會大眾拒絕它。這就是為什麼我們拒絕 MP3 音訊格式，而支持未取得專利的 Ogg Vorbis 格式的原因。據報導，這些專利已經過期，但我們仍然偏好 Ogg 格式勝過 MP3 格式。請支持這項運動，讓 Ogg Vorbis 成為 GNU 套件及其網站上音訊發行的首選格式。
我們會在未來考慮使用 Ogg Opus。散布 Ogg Opus 檔案也可以，但請繼續散布 Ogg Vorbis，這樣才不會催促使用者更換他們用來收聽音訊的軟體。
我們找不到現代壓縮視訊格式是真正免於專利疑慮的，因此我們使用 Ogg Theora 和 WebM 格式，因為這兩種格式尚未成立授權聯盟。GNU 程式及其網站不應散布 MPEG-2 或 MPEG 4 格式的視訊。
GNU 套件不應推薦使用任何非自由程式，也不應要求使用非自由程式（例如非自由的編譯器或 IDE）來建置。因此，GNU 套件不能用沒有自由軟體實作的程式語言編寫。既然 GNU/Linux 系統已廣泛普及，所有 GNU 套件都應在 100% 自由的 GNU/Linux 系統上提供完整功能，並且不應要求任何非自由軟體來建置或運作。《GNU 編碼標準》對此議題有更詳盡的說明。
同樣地，GNU 套件不應要求使用非自由軟體，包括 JavaScript，來協調其開發工作。例如，請不要使用 Transifex 來翻譯您的軟體，因為它要求您的翻譯人員使用非自由、基於 JavaScript 的編輯工具。相反地，應該使用沒有任何道德疑慮的服務，例如 The Translation Project（https://translationproject.org）。
GNU 套件不應引導使用者參考任何非自由的自由軟體文件。自由軟體需要附帶自由文件，這現在是 GNU 專案的主要重點；為了表明我們對自由文件的需求是認真的，我們絕不能透過推薦使用非自由的文件來反駁我們的立場。
請不要在需要非自由軟體的服務中託管關於您套件的討論。例如，Google+「社群」需要執行非自由的 JavaScript 程式才能發布訊息，因此它們不能在自由世界中使用。Google Groups 也有同樣的問題。在那裡託管討論將會排除那些奉行自由軟體原則的人。
當然，您不能命令人們不要使用這些服務彼此交談。您可以做的是不使其合法化，並利用您的影響力引導人們遠離它們。例如，在您說明在哪裡進行與程式相關的討論時，請不要列出這樣的地方。
最後，關於軟體自由倫理的新議題經常出現。我們要求 GNU 維護者，至少在與其套件具體相關的事務上，在這些議題出現時與 GNU 專案的其他成員站在一起。
在 GNU 中，我們欣賞工作中的幽默感。
GNU 是一個駭客專案，而駭客行為意味著富於玩樂的聰明才智。即使是「GNU」這個名字也是玩樂聰明才智的一個例子——它是一個「GNU’s Not Unix」的遞迴縮寫。
本著這種精神，我們讚賞 GNU 套件中偶爾出現的幽默。幽默在 GNU 套件中不是強制性的；我們不會告訴維護者：「讓使用者微笑，否則就完蛋了！」但是當維護者這樣做時，我們也會微笑。
如今，我們這種樂觀其成的幽默方式偶爾會遇到直接、全面的反對。有些人提倡，甚至要求，從軟體套件中移除笑話，僅僅因為它們是笑話。我們對這種觀點不屑一顧。
笑話與其他寫作一樣，會受到各種問題和批評。有時，對幽默的文字提出合理的異議，因此我們不會愚昧地捍衛每一個笑話到最後。但是它是笑話這一事實並不是一個合理的異議。
有些人不贊成任何稍微帶有暗示性或爭議性的事物，包括笑話。如果這種態度盛行，那將是極其可悲的，因此我們的政策是偶爾出現的帶有暗示性的笑話是可以接受的。GNU 是一個 21 世紀的專案，而不是 19 世紀的專案。
GNU 專案支持軟體自由的事業，也就是電腦使用者應能掌控他們的電腦活動。這要求他們能掌控執行這些活動的軟體，而這反過來又要求他們使用自由軟體執行這些活動，並有可能用他們自己的副本替換任何共享副本。
它也支持電腦運算中的基本人權，包括使用網際網路；例如，反對審查制度。
GNU 套件不應認真提倡任何其他政治事業。並非 GNU 專案反對那些其他事業。而是，它對它們保持中立，GNU 套件也應保持中立。例如，如果您是（比方說）和平主義者，您絕不能在您開發的 GNU 套件中提倡和平主義。反之亦然，如果您想發動戰爭，您開發的 GNU 套件也不應提倡戰爭。
本章說明了幾個術語議題，這些議題對於糾正關於 GNU 的兩個廣泛且重要的誤解至關重要。
| • 自由軟體與開放原始碼 | ||
| • GNU 與 Linux |
下一節：GNU 與 Linux，上一層：術語 [目錄][索引]
「自由軟體」和「開放原始碼」這兩個詞彙雖然描述的幾乎是同一類別的軟體，但代表的觀點卻基於根本不同的價值觀。自由軟體運動是理想主義的，並提出了自由、倫理、原則以及構成美好社會的要素等議題。開放原始碼這個詞彙於 1998 年提出，與一種刻意迴避這些問題的哲學相關聯。如需詳細說明，請參閱 https://gnu.dev.org.tw/philosophy/open-source-misses-the-point.html。
GNU 專案與自由軟體運動保持一致。這並不意味著所有 GNU 貢獻者和維護者都必須同意；您對這些議題的看法取決於您自己，並且當您為自己發言時，您有權表達它們。
然而，由於「開放原始碼」這個詞彙受到更廣泛的宣傳，GNU 專案需要克服一種廣泛的錯誤印象，即 GNU 現在且一直以來都是一項「開放原始碼」活動。因此，請在 GNU 軟體發行版、GNU 文件以及您以 GNU 套件維護者身分發布的公告和文章中使用「自由軟體」一詞，而不是「開放原始碼」或「FOSS」。參考上面給出的網址來解釋差異也是很有幫助的。
上一節：自由軟體與開放原始碼，上一層：術語 [目錄][索引]
GNU 專案的成立是為了開發一個自由的類 Unix 作業系統 GNU。這個系統的存在是我們的主要成就。然而，廣泛使用的 GNU 系統版本，其中 Linux 被用作核心，通常簡稱為「Linux」。因此，大多數使用者不了解 GNU 專案的主要成就——或更準確地說，他們了解它，但沒有意識到它是 GNU 專案的成就和存在理由。即使是那些認為自己了解真實歷史的人，也常常認為 GNU 的目標是開發「工具」或「公用程式」。
為了糾正這種混淆，我們多年來一直努力區分 Linux（Linus Torvalds 編寫的核心）和 GNU/Linux（GNU 和 Linux 的組合作業系統）。由此產生的對 GNU 專案已完成工作的更高認知度，有助於 GNU 專案的每一項活動招募更多的支持和貢獻者。
請在 GNU 軟體發行版、GNU 文件以及您以 GNU 套件維護者身分發布的公告和文章中始終如一地做出這種區分。如果您想解釋術語及其原因，您可以參考網址 https://gnu.dev.org.tw/gnu/linux-and-gnu.html。
為了清楚表明 Linux 是一個核心，而不是作業系統，請注意避免在這些資料中使用「Linux 系統」一詞。如果您想有機會聲明關於核心是 Linux 的系統，請寫「核心是 Linux 的系統」或「以 Linux 作為核心的系統」。這明確地對比了系統和核心，並將幫助讀者理解兩者之間的區別。請避免使用簡化的形式，例如「基於 Linux 的系統」，因為這些形式未能突顯核心和系統之間的區別，並可能鼓勵讀者忽略這種區別。
為了將真正的 GNU 系統與 GNU/Linux 進行對比，您可以稱其為「GNU/Hurd」或「GNU/Hurd 系統」。但是，當這種對比不是特別關注的重點時，請僅稱其為「GNU」或「GNU 系統」。
當提及作為 GNU 核心更高層級的伺服器集合時，請稱其為「Hurd」或「GNU Hurd」。請注意，這使用的是空格，而不是斜線。
有關此要點的更多資訊，請參閱 https://gnu.dev.org.tw/gnu/gnu-linux-faq.html。
關於您套件的訪談和演講是向公眾宣傳 GNU 系統和自由軟體運動理念的重要管道。請避免說「開放原始碼」，並避免稱 GNU 系統為「Linux」，就像您在套件本身中所做的那樣（請參閱術語）。同樣地，避免宣傳非自由程式（請參閱GNU 編碼標準中的參考文獻），就像您在套件本身中所做的那樣。
許多 GNU 使用者對 GNU 有錯誤的想法。在我們的社群之外，大多數人認為它是 Linux。請利用您的機會來糾正他們的錯誤觀念。從回答以下基本問題開始您的簡報：
如果您感受到不說這些話的社會壓力，您可能是接觸到一些寧願不說這些話的人。這正是我們最需要您的支持的時候。
請不要包含任何公司、產品或服務的廣告或宣傳。即使該產品符合 FSF 認可的標準，在關於 GNU 套件的簡報中宣傳它也是不合適的。同樣地，請不要包含公司口號。僅在主題需要時才提及公司。
一些 GNU 套件實際上是特定公司的商業活動。在這種情況下，一開始就說明是可以接受的。否則，請表明這是一個 GNU 專案的專案，並避免暗示它是任何公司的專案。
如果您受僱於一家公司來開發 GNU 套件，以謹慎的方式感謝該公司是適當的，但請不要超出這個範圍。
在您進行演講或訪談之前，請聯絡 GNU 專案領導層。我們可以為您提供關於如何應對各種突發事件的建議。
當您的訪談和演講錄音或文字稿發布時，請告訴我們。然後我們可以公開宣傳它們。
請以對自由軟體友好的格式發布它們：不要使用 Doc 或 Docx 格式，不要使用 Flash，不要使用 QuickTime，不要使用 MP3、MPEG2 或 MPEG4。純文字、HTML 和 PDF 都是不錯的選擇。
我們建議使用 savannah.gnu.org 作為您套件的原始碼儲存庫，但這不是必需的。有關 Savannah 的更多資訊，請參閱 舊版本。
我們強烈建議您使用 ftp.gnu.org 作為發行版的標準發布站點。這樣做可以讓開發人員和使用者更容易找到最新的 GNU 發行版。但是，如果您願意，可以使用另一個伺服器，前提是該伺服器允許一般公眾無限制地存取（例如，不排除任何國家/地區）。
如果您使用公司的機器來存放您程式的儲存庫，或作為其發行發布站點，請在網站的顯著位置放置以下聲明，以防止人們對套件與公司之間的關係產生錯誤的想法：
The programs <list of them> hosted here are free software packages of the GNU Project, not products of <company name>. We call them "free software" because you are free to copy and redistribute them, following the rules stated in the license of each package. For more information, see https://gnu.dev.org.tw/philosophy/free-sw.html. If you are looking for service or support for GNU software, see https://gnu.dev.org.tw/gethelp/ for suggestions of where to ask. If you would like to contribute to the development of one of these packages, contact the package maintainer or the bug-reporting address of the package (which should be listed in the package itself), or look on www.gnu.org for more information on how to contribute.
作為維護者，您可能想要接受對您工作的捐款，特別是如果您為自己的任何託管/開發基礎設施付費。以下是一些您可以根據自己的情況調整的文字，並在您套件的網站、README 或您認為有用的任何地方使用：
We appreciate contributions of any size -- donations enable us to spend more time working on the project, and help cover our infrastructure expenses. If you'd like to make a small donation, please visit url1 and do it through payment-service. Since our project isn't a tax-exempt organization, we can't offer you a tax deduction, but for all donations over amount1, we'd be happy to recognize your contribution on url2. We are also happy to consider making particular improvements or changes, or giving specific technical assistance, in return for a substantial donation over amount2. If you would like to discuss this possibility, write to us at address. Another possibility is to pay a software maintenance fee. Again, write to us about this at address to discuss how much you want to pay and how much maintenance we can offer in return. If you pay more than amount1, we can give you a document for your records. Thanks for your support!
我們不推薦任何特定的付款服務。但是，GNU 開發人員不應使用要求他們簽署專有軟體許可證的服務，例如 Google 的付款服務。也請避免要求使用者執行非自由軟體才能捐款的網站。（這包括 JavaScript 軟體，因此請使用 LibreJS 或禁用 JavaScript 試用。）
在您發布在網站上的文字中，請注意我們關心的術語問題（請參閱術語）。
我們不反對使用比特幣接受捐款。
FSF 可以為數量有限的專案募集捐款；如果您想為您的專案提出建議，請寫信至 maintainers@gnu.org。FSF 需要監督這些資金的支出。
當然，鼓勵人們加入 FSF (https://www.fsf.org) 或進行一般捐款，無論是代替還是與套件特定的捐款一起，也是很好的。
自由軟體目錄旨在成為符合特定標準的自由軟體套件的完整列表。每個 GNU 套件都應列在那裡，因此請參閱 https://gnu.dev.org.tw/help/directory.html#adding-entries 以獲取關於如何為您的套件編寫條目的資訊。如有任何問題或對自由軟體目錄的建議，請聯絡 bug-directory@gnu.org。
如果您想在文件中尋找錯誤，或想協助改進寫作品質，或者如果您不是英語母語人士，並想獲得製作優質英文文件的協助，您可以使用 GNU 校對人員郵寄清單：proofreaders@gnu.org。
但是當您使用該列表時請小心，因為上面有 200 多人。如果您只是要求列表上的每個人閱讀您的作品，校對人員可能會進行大量的重複工作，並且您可能會收到 100 次相同的錯誤報告。這必須避免。
此外，列表上的人員不希望收到來自該列表的大量郵件。因此，永遠不要要求列表上的人員向列表發送郵件！
以下是一些似乎合理的使用方法：
務必明確指定隨機選擇程序；否則人們可能會使用並非真正隨機的心理程序，例如「選擇靠近中間的部分」，並且您將無法獲得均勻的覆蓋率。
您可以將作品實際劃分為 20 個單獨的檔案，或描述虛擬劃分，例如按章節劃分（如果您的作品大約有 20 個章節）。如果您採用後者，請務必精確說明——例如，您是否希望將第一個章節標題之前的材料算作一個章節，還是不算？
下一節：GNU 自由文件許可證，上一節：使用校對人員列表，上一層：頂層 [目錄][索引]
如果您願意，以下是一些您可以在適當時機使用的回應。
這是一種拒絕安裝程式碼以使您的套件在專有作業系統 ShackleOS 上運作的方法。
您要求我們安裝對在 ShackleOS 上執行 XYZ 的支持。在我們在 GNU 系統上獲得對 XYZ 的支持之前，我們無法做到這一點。GNU 專案政策是在我們對 GNU 系統具有同等支持之前，不為非自由作業系統添加特殊支持。
非自由系統會奴役使用者。如果您已經習慣了這種奴役，您可能不會注意到這一點，但我們會注意到。自由軟體運動旨在透過用自由軟體（例如 GNU 系統）取代非自由系統來解放這些使用者。
這個程式的目的不是取代 ShackleOS，但 GNU 系統的目的確實如此。我們必須支持取代 ShackleOS 的努力，而不是削弱它。如果我們為 ShackleOS 實作比 GNU 更多或更好的支持，我們將會自擺烏龍。
所以請讓這個功能在 GNU 上運作，然後我們就可以安裝它了。
這是一種拒絕安裝程式碼以使您的套件與專有程式 ShackleMe 協同運作的方法。
您要求我們安裝一個專門與 ShackleMe 協同運作的功能，但該程式是非自由的。GNU 專案政策是在我們同等或更好地支持與可比較的自由程式互通之前，不為與非自由程式互通添加特殊支持。
非自由程式會奴役使用者。如果您已經習慣了這種奴役，您可能不會注意到這一點，但我們會注意到。GNU 專案的使命是透過用自由程式取代非自由程式來解放這些使用者。
這個程式的目的不是取代 ShackleMe，但其他自由程式的目的確實如此或應該如此。我們必須支持他們取代 ShackleMe 的努力。如果我們實作與 ShackleMe 的互通性超過與他們的互通性，那麼這個程式將成為他們成功的額外障礙。我們將會自擺烏龍。
所以請先讓這個功能與那些自由的替代品良好地協同運作。一旦我們支持它們，我們也可以支持 ShackleMe。
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. https://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
本許可證的目的是使手冊、教科書或其他功能性和有用的文件在自由的意義上是自由的：確保每個人都擁有有效自由地複製和重新發布它，無論是否修改它，無論是商業用途還是非商業用途。其次，本許可證為作者和出版商保留了一種為其工作獲得認可的方式，同時不被視為對他人所做的修改負責。
本許可證是一種「著作權保留」，這意味著文件的衍生作品本身必須在相同的意義上是自由的。它補充了 GNU 通用公共許可證，後者是為自由軟體設計的著作權保留許可證。
我們設計本許可證是為了將其用於自由軟體的手冊，因為自由軟體需要自由文件：自由程式應附帶提供與軟體相同的自由度的手冊。但是本許可證不限於軟體手冊；它可以適用於任何文字作品，無論主題為何，也無論它是否以印刷書籍的形式出版。我們主要建議將本許可證用於以教學或參考為目的的作品。
本許可證適用於任何手冊或其他作品，以任何媒體形式呈現，其中包含著作權持有人放置的聲明，表明它可以根據本許可證的條款分發。此類聲明授予在全球範圍內、免版稅的許可，期限不受限制，以根據本文所述的條件使用該作品。「文件」，在下文中，指的是任何此類手冊或作品。任何公眾成員都是被許可人，並被稱為「您」。如果您以版權法下需要許可的方式複製、修改或分發該作品，則表示您接受本許可證。
文件的「修改版本」是指任何包含文件或其一部分的作品，無論是逐字複製，還是經過修改和/或翻譯成另一種語言。
「次要章節」是指文件的命名附錄或前言章節，該章節專門處理文件的出版商或作者與文件整體主題（或與相關事項）的關係，並且不包含任何可能直接屬於該整體主題的內容。（因此，如果文件部分是數學教科書，則次要章節不得解釋任何數學。）這種關係可能是與該主題或相關事項的歷史聯繫，或是關於它們的法律、商業、哲學、倫理或政治立場。
「不變章節」是某些次要章節，其標題在聲明文件中被指定為不變章節，該聲明文件表明文件根據本許可證發布。如果章節不符合上述次要章節的定義，則不允許將其指定為不變章節。文件可能包含零個不變章節。如果文件未識別任何不變章節，則沒有不變章節。
「封面文字」是在聲明文件中列出的某些簡短文字段落，作為正面封面文字或背面封面文字，該聲明文件表明文件根據本許可證發布。正面封面文字最多可以有 5 個字，背面封面文字最多可以有 25 個字。
文件的「透明」副本是指機器可讀的副本，以其規範可供公眾使用的格式表示，適用於使用通用文字編輯器（對於由像素組成的圖像）通用繪圖程式或（對於繪圖）一些廣泛可用的繪圖編輯器直接修改文件，並且適用於輸入文字格式化器或自動翻譯成各種適用於輸入文字格式化器的格式。以其他透明檔案格式製作的副本，其標記或缺少標記的方式旨在阻礙或阻止讀者隨後進行修改，則不是透明的。如果圖像格式用於大量文字，則該圖像格式不是透明的。不是「透明」的副本稱為「不透明」。
適用於透明副本的格式範例包括不帶標記的純 ASCII、Texinfo 輸入格式、LaTeX 輸入格式、使用公開可用的 DTD 的 SGML 或 XML，以及符合標準的簡單 HTML、PostScript 或 PDF，專為人工修改而設計。透明圖像格式的範例包括 PNG、XCF 和 JPG。不透明格式包括只能由專有文字處理器讀取和編輯的專有格式、DTD 和/或處理工具通常不可用的 SGML 或 XML，以及某些文字處理器僅為輸出目的而生成的機器生成 HTML、PostScript 或 PDF。
「標題頁」對於印刷書籍而言，是指標題頁本身，以及容納本許可證要求出現在標題頁中的資料所需的後續頁面。對於沒有任何標題頁的格式的作品，「標題頁」是指最顯著出現的作品標題附近的文字，位於正文文字的開頭之前。
「出版商」是指向公眾分發文件副本的任何個人或實體。
「標題為 XYZ」的章節是指文件的命名子單元，其標題恰好是 XYZ 或在文字後面的括號中包含 XYZ，該文字將 XYZ 翻譯成另一種語言。（此處 XYZ 代表下面提到的特定章節名稱，例如「致謝」、「題獻」、「認可」或「歷史」。）當您修改文件時「保留」此類章節的「標題」是指它根據本定義仍然是一個「標題為 XYZ」的章節。
文件可能在聲明本許可證適用於文件的聲明旁邊包含保固免責聲明。這些保固免責聲明被認為是透過引用包含在本許可證中，但僅限於免責聲明：這些保固免責聲明可能具有的任何其他含義均無效，並且對本許可證的含義沒有影響。
您可以以任何媒體形式複製和分發文件，無論是商業用途還是非商業用途，前提是本許可證、著作權聲明和聲明本許可證適用於文件的許可證聲明在所有副本中都得到複製，並且您未在本許可證的條件之外添加任何其他條件。您不得使用技術措施來阻礙或控制您製作或分發的副本的閱讀或進一步複製。但是，您可以接受報酬以換取副本。如果您分發足夠多的副本，您還必須遵守第 3 節中的條件。
您也可以在上述相同條件下借出副本，並且您可以公開展示副本。
如果您出版印刷副本（或通常帶有印刷封面的媒體副本）的文件，數量超過 100 份，並且文件的許可證聲明要求封面文字，您必須將副本封裝在封面上，該封面清楚且清晰地印有所有這些封面文字：正面封面文字在正面封面上，背面封面文字在背面封面上。兩個封面還必須清楚且清晰地將您標識為這些副本的出版商。正面封面必須呈現完整標題，標題的所有文字均同樣突出且可見。您可以在封面上添加其他材料。僅限於封面更改的複製，只要它們保留文件的標題並滿足這些條件，就可以在其他方面被視為逐字複製。
如果任一封面的所需文字過於龐大而無法清晰地容納，您應將列出的第一個文字（盡可能多地容納）放在實際封面上，並將其餘文字繼續放在相鄰頁面上。
如果您出版或分發數量超過 100 份的文件的不透明副本，您必須在每個不透明副本中包含一個機器可讀的透明副本，或者在每個不透明副本中或與之一起聲明一個電腦網路位置，一般網路使用者可以透過使用公用標準網路協定從該位置下載文件的完整透明副本，且不包含任何附加材料。如果您使用後一種選項，您必須採取合理謹慎的步驟，當您開始大量分發不透明副本時，以確保該透明副本將在所述位置保持可存取狀態，直到至少在您最後一次向公眾分發該版本的（直接或透過您的代理商或零售商）不透明副本後一年為止。
建議但不強制要求您在重新分發大量副本之前與文件的作者聯絡，以便讓他們有機會向您提供文件的更新版本。
您可以根據上述第 2 節和第 3 節的條件複製和分發文件的修改版本，前提是您根據本許可證準確地發布修改版本，修改版本扮演文件的角色，從而將修改版本的發行和修改許可給任何擁有其副本的人。此外，您必須在修改版本中執行以下操作：
如果修改版本包含符合次要章節資格的新增前言章節或附錄，且未包含從文件中複製的材料，您可以選擇將部分或全部這些章節指定為不變更章節。若要執行此操作，請將其標題新增至修改版本授權條款聲明中的不變更章節清單。這些標題必須與任何其他章節標題不同。
您可以新增標題為「背書」的章節，但前提是該章節僅包含各方對您的修改版本的背書，例如同儕審查聲明，或組織已批准該文本作為標準的權威定義。
您可以新增最多五個字的段落作為封面文字，以及最多 25 個字的段落作為封底文字，加到修改版本中封面文字清單的末尾。任何單一實體（或透過其安排）只能新增一段封面文字和一段封底文字。如果文件已經包含您或您代表的同一實體先前新增的相同封面的封面文字，您不得新增另一個；但您可以替換舊的，但需獲得新增舊封面的先前出版者的明確許可。
文件的作者和出版者並未透過本授權條款授權使用其姓名來宣傳或聲明或暗示對任何修改版本的背書。
您可以將本文件與其他依本授權條款發布的文件合併，其條款定義於上述第 4 節關於修改版本的規定，前提是您在合併版本中包含所有原始文件的所有不變更章節，且未經修改，並將它們全部列為合併作品授權條款聲明中的不變更章節，並且您保留其所有保固免責聲明。
合併作品僅需包含一份本授權條款的副本，多個相同的不變更章節可以用單一副本替換。如果有多個名稱相同但內容不同的不變更章節，請在每個此類章節的標題末尾加上括號，註明該章節的原始作者或出版者（如果已知），或者使用唯一編號，使每個章節的標題獨一無二。在合併作品的授權條款聲明中的不變更章節清單中，對章節標題進行相同的調整。
在合併版本中，您必須合併各原始文件中標題為「歷史」的所有章節，形成一個標題為「歷史」的章節；同樣地，合併任何標題為「致謝」的章節，以及任何標題為「獻詞」的章節。您必須刪除所有標題為「背書」的章節。
您可以製作一個彙編，其中包含本文件和其他依本授權條款發布的文件，並將各文件中個別的本授權條款副本替換為彙編中包含的單一副本，前提是您在所有其他方面都遵循本授權條款關於逐字複製每個文件的規則。
您可以從此類彙編中提取單一文件，並依本授權條款個別散布，前提是您在提取的文件中插入本授權條款的副本，並在關於逐字複製該文件的所有其他方面都遵循本授權條款。
將本文件或其衍生作品與其他獨立的文件或作品彙編成冊，或儲存在儲存或散布媒體上，如果彙編產生的著作權不用於限制彙編使用者的合法權利，超出個別作品許可的範圍，則稱為「彙整」。當本文件包含在彙整中時，本授權條款不適用於彙整中非本文件衍生作品的其他作品。
如果第 3 節的封面文字要求適用於本文件的這些副本，則如果本文件少於整個彙整的一半，則本文件的封面文字可以放在括住彙整中本文件的封面上，或者如果本文件為電子形式，則放在封面的電子等效物上。否則，它們必須出現在括住整個彙整的印刷封面上。
翻譯被視為一種修改，因此您可以依第 4 節的條款散布文件的翻譯版本。將不變更章節替換為翻譯版本需要其著作權持有者的特別許可，但您可以包含部分或全部不變更章節的翻譯版本，以及這些不變更章節的原始版本。您可以包含本授權條款的翻譯版本，以及文件中所有授權條款聲明和任何保固免責聲明，前提是您也包含本授權條款的原始英文版本以及這些聲明和免責聲明的原始版本。如果本授權條款或聲明或免責聲明的翻譯版本與原始版本之間存在歧異，則以原始版本為準。
如果文件中的章節標題為「致謝」、「獻詞」或「歷史」，則保留其標題的要求（第 4 節）通常需要更改實際標題（第 1 節）。
除非本授權條款明確規定，否則您不得複製、修改、再授權或散布本文件。任何以其他方式複製、修改、再授權或散布本文件的企圖均屬無效，並將自動終止您在本授權條款下的權利。
但是，如果您停止所有違反本授權條款的行為，則您從特定著作權持有人處獲得的授權將恢復：（a）暫時恢復，除非且直到著作權持有人明確且最終終止您的授權，以及（b）永久恢復，如果著作權持有人在停止違規後 60 天內未以某種合理方式通知您違規行為。
此外，如果您已以某種合理方式收到著作權持有人的違規通知，這是您第一次收到該著作權持有人發出的（針對任何作品的）本授權條款違規通知，並且您在收到通知後 30 天內糾正了違規行為，則您從該特定著作權持有人處獲得的授權將永久恢復。
根據本節終止您的權利不會終止已從您處根據本授權條款收到副本或權利的各方的授權。如果您的權利已被終止且未永久恢復，則收到部分或全部相同材料的副本不會賦予您任何使用權。
自由軟體基金會可能會不時發布 GNU 自由文檔許可證的新修訂版本。此類新版本在精神上將與目前版本相似，但在細節上可能有所不同，以解決新問題或疑慮。請參閱 https://gnu.dev.org.tw/licenses/。
每個授權條款版本都有一個區分版本的編號。如果文件指定本授權條款的特定編號版本「或任何後續版本」適用於它，您可以選擇遵循該指定版本或自由軟體基金會已發布的任何後續版本（非草稿）的條款和條件。如果文件未指定本授權條款的版本號，您可以選擇自由軟體基金會曾經發布的任何版本（非草稿）。如果文件指定代理人可以決定可以使用本授權條款的哪些未來版本，則該代理人公開聲明接受某個版本，即永久授權您可以為該文件選擇該版本。
「大型多人協作網站」（或「MMC 網站」）是指任何發布受著作權保護作品，並為任何人編輯這些作品提供顯著便利設施的全球資訊網伺服器。任何人都可以編輯的公共維基百科就是此類伺服器的範例。「大型多人協作」（或「MMC」）在網站中是指 MMC 網站上發布的任何一組受著作權保護的作品。
「CC-BY-SA」是指創意共享組織發布的創用CC 姓名標示-相同方式分享 3.0 授權條款，該組織是一個主要營業地點位於加利福尼亞州舊金山的非營利公司，以及該組織發布的該授權條款的未來共享創意版本。
「納入」是指將文件全部或部分作為另一份文件的一部分發布或再發布。
如果 MMC 符合以下條件，則「符合重新授權的資格」：它依本授權條款授權，並且所有最初在本授權條款下發布在 MMC 以外的地方，隨後全部或部分納入 MMC 的作品，（1）沒有封面文字或不變更章節，並且（2）是在 2008 年 11 月 1 日之前納入的。
MMC 網站的營運者可以在 2009 年 8 月 1 日之前的任何時間，在同一網站上依 CC-BY-SA 重新發布網站中包含的 MMC，前提是 MMC 符合重新授權的資格。
若要在您撰寫的文件中使用本授權條款，請在文件中包含本授權條款的副本，並在標題頁之後放置以下著作權和授權條款聲明
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
如果您有不變更章節、封面文字和封底文字，請將「with…Texts.」行替換為以下內容
with the Invariant Sections being list their titles, with
the Front-Cover Texts being list, and with the Back-Cover Texts
being list.
如果您有不變更章節但沒有封面文字，或三者的其他組合，請合併這兩種替代方案以適應情況。
如果您的文件包含程式碼的非平凡範例，我們建議在您選擇的自由軟體授權條款下平行發布這些範例，例如 GNU 通用公共許可證，以允許在自由軟體中使用它們。
上一頁：GNU 自由文檔許可證，上一層：頂層 [目錄][索引]
| 跳至： | $ / A B C D E F G H I L M O P Q R S T U V W |
|---|
| 跳至： | $ / A B C D E F G H I L M O P Q R S T U V W |
|---|