按此：您的 WordPress 外掛是否相容於 GPL？

歡迎來到 Press This，WMR 的 WordPress 社群播客。 每集都有來自社區各地的嘉賓，並討論 WordPress 開發人員面臨的最大問題。 以下是原始錄音的轉錄。

由紅圈提供支持

Doc Pop ：您正在收聽 Press This，這是 WMR 上的 WordPress 社群播客。 每週我們都會專注於 WordPress 社群的成員。 我是你們的主持人，波普博士。 我透過在 WP Engine 中的角色以及對 TorqueMag.io 的貢獻來支持 WordPress 社群。 您可以在 RedCircle、iTunes、Spotify 或您最喜歡的播客應用程式上訂閱 Press This，也可以直接從 WMR.fm 下載劇集。

如果您曾經為開源專案做出貢獻，您就會知道這一切都與協作和創新有關，但是許多開發人員在確保他們的插件符合 GPL、GNU、通用公共授權。 這不僅僅是合規問題。 這是為了維護開源精神。

今天我們有一位特別嘉賓，Jeff Paul，10up 的開源總監，他將分享他今年在 WordCamp US 上提出的一個改變​​遊戲規則的解決方案。 想像一下，有一個工具可以自動掃描您的程式碼庫，以確保您的插件的 GPL 相容性，即使您添加新功能和依賴項也是如此。

這就是我們今天要討論的內容。 但在我們深入探討之前，Jeff，您能告訴我們您的 WordPress 起源故事嗎？

傑夫保羅：當然。 我不知道我有確切的年份。 大概是2000年代初。 我在以前的 CMS 上有一個個人網站，我想它叫做 Geeklog。 加上當時我的託管供應商，以及誰知道還有多少其他因素，CMS 中的內容崩潰了。

所以我當時只是在尋找一些東西來代替它。 我發現 WordPress 可以滿足我的需求。 您知道，我自己並沒有走上建立 CMS 的道路，這對許多人來說似乎是一個很好的起源故事。 但那是，我不知道，'04 到 '07，在這個範圍內的某個地方，但我沒有，有點跨越鴻溝做出貢獻，直到 WordPress 4.7 版本發布，當時我加入了發布小組海倫·侯桑迪和亞倫·喬賓。 因此，我花了很多年時間成為該專案的消費者，直到相當長的一段時間後，我才成為貢獻者，並且從那時起，你知道，我一直在這條道路上繼續前進。 嗯，你知道，此時，雙重消費者和貢獻者。

DP ：您也是 WordPress 核心的非常積極的貢獻者。 10up 在插件儲存庫中維護了數十個插件，包括 ElasticPress、Distributor、ClassifAI。 這些都可以在 wordpress.org 儲存庫上找到，並在 GitHub 上公開並使用開源實踐進行維護。

您對我們將要深入探討的主題非常熟悉。 為什麼我們不從 WordPress 儲存庫（例如 WordPress 外掛程式儲存庫）開始呢？ 快速告訴我們，什麼是 WordPress 儲存庫以及向其上傳任何內容的規則是什麼？

JP ：當然。 因此，WordPress 儲存庫由開源專案 WordPress.org 託管，與 WordPress.com 分開，與生態系統中的任何其他主機分開，與第三方外掛程式公司或經銷商分開。 它是直接連結或綁定到每個 WordPress 安裝的內容。 當有人在 WordPress 管理員中搜尋外掛程式或主題時，這些搜尋是透過 WordPress 管理員中提供的 WordPress.org 外掛程式儲存庫和主題儲存庫進行的。 WordPress.org 上也是如此。 實際上，那裡提供相同的搜尋、相同的內容。

就列出其中的內容而言，wordpress.org 外掛程式審查團隊為外掛程式開發人員提供了一套詳細的注意事項指南。 然後有一個實際的提交工作流程來完成向 wordpress.org 外掛程式儲存庫的初步提交。 一旦獲得批准，就會為您的插件建立一個 SVN 儲存庫。 而且，您知道，任何更新、發布等都會推送到 SVN。 這就是目前所有可在 WordPress.org 或 WordPress 管理員中搜尋的內容的生存和呼吸之處。

DP ：我認為首要規則之一是，您放入 WordPress 儲存庫的任何內容都需要符合 GPL，包括字體和圖像，而不僅僅是程式碼。 那是對的嗎？

JP ：正確。 正確的。 因此，從字面上看，插件團隊的第一條規則是插件整體必須相容於 GPL。 這與 WordPress 遵循的許可證相同，正如您所提到的，程式碼、圖片和第三方程式庫都必須相容於 GPL。 它不一定是實際的，你知道，GPLv2 許可證，還有其他與GPL 兼容的許可證，但是，是的，字體、圖像、第三方庫、依賴項，所有這些都必須與GPL 兼容，而不僅僅是插件開發人員編寫的程式碼，對吧？ 所有其他的東西也需要兼容 GPL。

DP ：為了不讓聽眾等待，我們可以直接跳進去。 您的演講是關於如何使用 GitHub 操作檢查 GPL 相容性。 您能引導我們完成這個過程嗎？

JP ：是的，這在某種程度上源自於我作為 10Up 開源總監的角色。 您知道，單一插件甚至多個插件的日常插件作者可能不會意識到這一點，或者不會打擾他們。 但我認為在某些時候，我幾乎在半夜醒來，想，「我不知道我是否確定你知道，所有的圖像，所有的第三方依賴項，所有的字體等等，都是GPL 相容的，並試圖在10up 中為我們找到一種大規模的方法，就像您提到的那樣，我們有數十個外掛程式可以在wordpress.org 儲存庫或GitHub 上找到。 源頭在那裡。

我不想仔細梳理所有這些內容，也不想檢查我們用於插件的任何上游依賴項，並弄清楚這些是如何獲得許可的。 對於單一插件來說這可能是一件痛苦的事，更不用說多個插件了。 透過一些在線搜索，我發現有一些工具、一些 GitHub 操作可以用來幫助有效地自動化該過程，這樣，你知道，不僅僅是對存儲庫進行一次一次性掃描就可以說，是的，你兼容或不相容，你不相容，但繼續掃描，以便任何未來的錯誤修復、增強等，這可能會添加新的依賴項，或者可能會在插件中增加依賴項，而這可能會改變某些東西的方式獲得許可，能夠檢查正在進行的情況，並進行這種首次通過是我試圖弄清楚的事情，這樣它就不會成為一個手動的、密集的過程，並且有點像一場持續的噩夢，以確保，即兼容性。

所以，是的，我的意思是，我認為我最初擔心的是，我不知道 — 我無法知道我們添加的某些功能（如果我們包含新的依賴項）與 GPL 兼容，然後意識到可能存在更糟糕的情況，即我們已經發布了插件，並對其軟體中已經存在不相容性的情況進行了迭代。

這就是我想嘗試解決的第一個問題。 第一次初始掃描，對吧？ 您知道，我們的各個插件以及 10up 支援的所有插件是否真正與我們聲明的許可證相容？ 希望他們是這樣。 然後，你知道，從那裡開始，持續檢查確保未來的 PR，無論是來自我的團隊還是 10up 的開源實踐，廣泛地與其他 10up 為專案做出貢獻，或者只是社區中的任何人，確保這些保留了我們在插件本身中聲明的許可。

DP ：只是為了在這裡澄清一下，如果你沒有，如果你透過這個發現，存在，呃，一些現有的依賴關係或其中的某些東西，這是不合規的，那麼後果就是某種羞辱或者您是否因不遵守規則而可能遭受懲罰性損害？

JP ：所以我不是律師，對吧？ 所以，你知道，我沒有律師資格來發表此評論，所以，你知道，這不是有效的法律建議，而是我在插件上運行這些掃描時所採取的方法，因為同樣，我沒有我知道，我實際上很緊張運行所有這些，不知道結果會是什麼。

我的計劃是，如果我發現有一個插件正在使用不相容 GPL 的東西，那麼最好的方法是刪除該依賴項，將其換成其他東西，有效地清除它，無論問題是什麼很快就發布了新版本，對嗎？

對於已經出版和發布的內容，我覺得沒什麼可以做的。 從我的角度來看，這一切都不會是故意規避許可的。 你知道，這只是在某個時刻出現的人為錯誤，有點類似於向插件作者報告的安全問題。 就像，最好的方法是進行補救並快速發布版本，以便那些保持插件最新狀態的人處於更安全的狀態，無論是安全問題還是在這種情況下，許可問題。 當然，如果碰巧有一個插件能夠產生顯著的收入，並且如果可能有的話，有理由表明擁有某些未授權的東西是一個已知的錯誤，除此之外，我不相信該領域的任何人們是故意這樣做的，但我認為唯一可能面臨法律風險的是那些能顯著創造收入的項目，這將是許可的目標。

所以，是的，我認為長話短說，如果有人運行掃描並在現有程式碼庫中發現問題，我認為最好的方法實際上是發布一個版本，一個更新版本，你知道，在更改日誌中調用，在發行說明中指出更改的內容和原因，並對此保持透明。 但在這一點上，我認為插件作者在這種情況下能做的就是最好的事情。 幸運的是，對於 10up 的插件來說，我們沒有遇到這種情況。 幸運的是，一切都是相容的，我希望絕大多數沿著這條路走下去的人，設定一些自動化來給他們帶來那種程度的舒適感，能夠有類似的體驗。

等待 GitHub 操作運行幾秒鐘或一分鐘可能會有點緊張、焦慮。 但是，你知道，一旦一切都過去了，我想大多數人可能最終都會陷入這種狀態。

DP ：說到舒服，我們要短暫休息一下。 因此，請坐下來放鬆一下，短暫的廣告休息後，我們將回來對 10up 開源計劃總監 Jeff Paul 進行更多採訪，內容涉及如何保持插件符合 GPL 規定。 短暫休息後，請繼續關注更多內容。

DP ：歡迎回到 WordPress 社群播客 Press This。 我是醫生。 我正在與 Jeff Paul 討論如何使用 GitHub 操作來確保您的程式碼、外掛程式符合 GPL 規定。 在休息之前，我們對此進行了一些深入探討，並討論瞭如果您不完全合規的後果。 我想我想回到這個具體的事情。 任何人都可以建立 GitHub 操作。 但是 Jeff，您在 WordCamp 演講中提到您使用官方 GitHub 操作，我認為做了一些小的更改。 您能告訴我們人們應該尋找能夠做到這一點的操作名稱嗎？

JP ：當然。 這就是依賴性審查操作。 所以 GitHub.com，斜線操作，斜線依賴，連字符審查，連字符操作。 希望抄本能夠正確理解這一點。 如果發現任何問題，我確實在我的網站上的一篇涵蓋該演講的帖子上對此進行了註釋。 因此，有可用的鏈接，但如果您在 GitHub 操作市場中搜索依賴項審查操作，您將有望找到我使用的官方鏈接，它不僅僅是檢查插件依賴項。 它不僅會檢查許可證。 它還可以檢查插件依賴項中的漏洞和其他內容。 但我使用它的唯一目的，也是我使用它的核心目的，是檢查插件依賴項中的無效許可證。

DP ：您可以透過此操作設定您想要遵循的 GPL 類型。 您可以包含一個許可證，它會根據該許可證進行檢查。 而且，如果您維護數十個插件，您仍然可以獲得相同的東西。 您可以將所有這些您維護的插件仍然保存到該目錄中，這樣您就不必每次都去更新它，對嗎？

JP ：正確。 是的。 我看到你在 WordCamp US 上聽完了我的演講，感謝你在觀眾中清醒地傾聽，或者你在 YouTube 或 WordPress.tv 上看到了它，但是，是的，我希望大家有兩種標準流程跟隨這裡。

第一，負責一個或極少數插件的插件作者，或擁有一對多插件的人，他們有很多支援的插件。 因此，對於只有一個操作的人來說，GitHub 操作（正如您所定義的那樣）可以在該工作流程文件中有效地調用依賴項審核操作，並讓它掃描您的儲存庫，有兩個環境變量或您可以提供的參數。 該操作之一是允許許可證，其必然結果是拒絕許可證。 你不能同時做這兩件事。 我採取的方法是使用允許許可證而不是拒絕許可證。 我的想法是……我寧願遇到這樣的情況：我忘記在允許許可證清單中包含 GPL 相容許可證，從而得到有效的誤報，對吧？ 就像將依賴項標記為與我的許可證不相容，因為它的許可證只是我忘記添加到列表中的東西，而如果我使用拒絕許可證列表並且我忘記拒絕我不想要的許可證，那麼這可能意味著依賴關係將通過，不會被此檢查捕獲。

因此，我強烈建議您使用允許許可證清單。 如果有人維護單一插件，則只需在工作流程文件中使用該參數和許可證清單。 因此，對於 10up，對於我們的插件，這是 .GitHub 目錄，然後是那裡的工作流程子目錄。 然後我們有一個依賴項審查工作流程，呼叫該依賴項審查操作，具有允許許可證列表，您可以在我的網站上提取我的簡報或在線查找演講並查看我們擁有的許可證列表。 您還可以探索 GitHub 上的任何 10up 儲存庫並查看我們探索的許可證。

我們的工作流程文件有相當詳細的記錄，並解釋了我們如何識別我們認為與我們的外掛程式相容的許可證。 因此，歡迎人們使用我們擁有的列表，歡迎使用該列表的子集，歡迎人們進行自己的研究，也許可以感受到這種程度的舒適。 但我們確實做了相當長的研究，以確保我們在允許許可證清單中使用的內容實際上與我們聲明的內容相容。 對於 10up，我們幾乎預設使用 GPLv2 或更高版本，因此我們列出的所有授權都與 GPLv2 相容。

這也是插件作者維護一個插件的情況。 正如您所提到的，對於某人擁有多個許可證的情況，您可以擁有一個單獨的許可證策略文件，該文件實際上包含其中聲明的所有許可證。 然後，您在外掛程式的工作流程中引用該設定檔、該許可證策略文件，這樣，正如您所提到的，您實際上只有一個地方需要維護相容許可證清單。 如果碰巧有一個新的開源、經倡議批准的許可證恰好與我們兼容 GPLv2，對嗎？ 如果有一個新的出現，那麼可以將其添加到清單中，或者如果出於某種原因需要刪除一個，您不必在數十個位置中執行此操作。 您可以在一個位置執行此操作，然後使用新的許可證清單立即更新引用該配置的所有工作流程文件。

DP ：這都是自動化的，所以如果有人提出拉取請求，它只會為你做。 正確的？

JP ：正確，正確。 因此，當我們在儲存庫中建立工作流程檔案時，我們確實會觸發拉取請求。 因此，您也許還可以將其設定為按CRON 計劃運行，您可以讓它每週或每月運行一次，但實際上，一旦您執行了第一次運行，您就會掃描依賴項的整個程式碼庫，而且它真的會運行向前，您實際上只需要檢查那些傳入的拉取請求，如果您沒有使用相當嚴格的系統來要求對插件的預設或穩定分支進行PR，那麼您也可以檢查單個提交。

因此，人們可能想要使用其他觸發器。 對於 10up，我們傾向於相當嚴格地要求 PR 來開發和主幹分支，以便我們可以可靠地使用此操作，並知道任何引入新依賴項或碰巧更改許可證的版本的依賴項更改都會被此捕獲。 所以，是的，我們使用，我們樞轉或觸發拉取請求，但根據人們的嚴格程度，您可能會檢查對特定分支的個人提交，甚至每天、每週、每月按計劃運行，只是知道您的程式碼仍在通過，沒有任何與10up 的GPLv2 不相容的許可證，從而感到安心。

DP ：我們要在這裡再短暫休息一下。 當我們回來時，我們將結束與 Jeff Paul 關於 GPL 許可證的對話，並可能討論我們之前沒有提到的任何內容。 因此，在短暫的休息後，請繼續關注更多內容。

DP ：歡迎回到 WordPress 社群播客 Press This。 我們即將結束演出，我們將稍微調整一下節奏。 最近有一些關於插件存儲庫審查過程的討論，基本上只是說明這個事實，它比過去慢了一點。

有些人說他們知道要花幾個月的時間才能對某些內容進行審核，而我認為在我使用 WordPress 的大部分時間裡，審核時間可能會在四週內達到頂峰。 所以，傑夫，我知道他們已經討論過可能要對此做出一些改變。 能告訴我們團隊現在正在做什麼嗎？

JP ：當然。 是的。 我已經，你知道，我放大了你所說的話。 我認為從歷史上看，我所提交的所有內容都在兩週內完成，並且比通常報告的速度要快得多。 大約需要 88 天，這對每個參與其中的人來說都是不幸的。

我認為該團隊有一些人員流動。 一些非常有經驗的高級知識失去了。 我認為那些慷慨地介入幫助填補這一空白的人們仍然能夠在處理插件和審查那些初始提交方面擁有相同的吞吐量。 他們正在做一些工作來嘗試實現其中一些自動化。 因此，您知道，電腦在某些方面可能比人類更擅長，例如運行 WordPress 編碼標準以及在報告的真正嚴重錯誤的地方進行磨練，對吧？ 不必由人類來檢查和處理這些事情，而是擁有一個插件檢查器來運行和檢查可以自動化的事情，並幫助插件審查團隊獲得快速的初始暫停，例如，自動通過的事情嗎？ 如果是這樣，那麼，好吧，深入進行人工審查並加快進展速度。 如果事情已經被報告，本質上是自動化的，但沒有通過，那麼我認為，這是對插件開發人員的更快響應，嘿，我們已經在掃描中識別出這些最初的事情，你知道，請解決這些問題然後提交更新的 zip 文件，讓事情回到正軌。

所以我知道他們正在努力添加一些自動化，我認為他們能做的越多來幫助他們走上這條路就越好，只是因為在這一點上，有超過一千個插件，積壓很長，而且再次，沒有幫助那裡的任何人。 所以是的，他們正在研究自動化。 我知道他們想做更多的事情，而且我認為如果這是一個在自動化方面特別有天賦並希望做出貢獻的領域，我認為插件審查團隊很樂意在這方面獲得一些幫助。 因此，如果是這種情況，請務必透過 Slack 進行聯繫。

DP ：說到聯繫，如果人們對您在 WordCampUS 上的演講或 10uP 正在開源領域開展的一些專案有疑問，人們聯繫您的最佳方式是什麼？

JP ：當然。 所以我的網站是 jeffpaul.com。 我的簡報就在那裡，如果您只是搜尋 GPL，無論如何它可能會是第一個帖子之一。 否則，我的電子郵件是[電子郵件受保護] ，我的工作電子郵件，嗯，然後是幾乎所有社交網路。 WordPress.org、GitHub、Twitter、slash X，我是@Jeff Paul，你們都可以透過這個方式在社群網路上找到我。

DP ：同樣，如果聽眾想在 GitHub 上找到 10uP 工作的範例，我假設這只是 GitHub 上的 10up 嗎？

JP ：正確，是的，github.com/10up。 我們插件的所有儲存庫都是公開的。 我們的團隊密切追蹤新議題和 PR。 這些都透過管道傳輸到我們的 Slack 頻道，因此人們提出的任何問題、任何討論都可以在那裡打開。 我們的團隊應該對這些問題做出相當的反應，但如果沒有，你知道，在 WordPress Slack 上、透過電子郵件在 Twitter 上聯絡我，這些都可以。 我總是很高興與社群中的人們討論開源問題。

DP ：嗯，非常感謝您今天加入我們，Jeff，與您交談真是太棒了，我學到了很多關於 GitHub 的拉取請求操作和自動化體驗的知識。 這非常有幫助。

如果您錯過了上週的 Press This 節目，我們與 Carmen Johnson 討論了為 MySQL 5.7 生命週期結束而為網站做好準備的步驟，以及如何為 MySQL 8 做好準備。所以這是一個非常好的節目。可以查看一下，我們還有更多。 如果您想尋找轉錄版本，可以在 TorqueMag.io 上找到這些內容。 感謝您收聽 Press This，這是 WMR 上的 WordPress 社群播客。 您可以在 Twitter、Torque Mag 上關注我們的冒險經歷。

您可以在 RedCircle、iTunes、Spotify 或您最喜歡的播客應用程式上訂閱 Press This，也可以直接從 WMR.fm 下載劇集。 我是你們的主持人，人氣博士。 我透過在 WP Engine 中的角色來支援 WordPress 社區，我喜歡每週在 PressThis 上關注該社群的成員。