これを押してください: WordPress プラグインは GPL 互換ですか?

公開: 2023-10-06

WMR の WordPress コミュニティポッドキャスト、Press This へようこそ。 各エピソードでは、コミュニティ周辺からのゲストが登場し、WordPress 開発者が直面している最大の問題についてディスカッションします。 以下はオリジナルの録音の書き起こしです。

レッドサークル提供

Doc Pop : WMR の WordPress コミュニティポッドキャストである Press This を聞いています。毎週、WordPress コミュニティのメンバーにスポットライトを当てます。私はあなたのホスト、ドク・ポップです。私は WP Engine での役割と TorqueMag.io への貢献を通じて WordPress コミュニティをサポートしています。 RedCircle、iTunes、Spotify、またはお気に入りのポッドキャスティングアプリで Press This を購読したり、WMR.fm からエピソードを直接ダウンロードしたりできます。

オープンソースプロジェクトに貢献したことがある方なら、コラボレーションとイノベーションがすべてであることをご存知でしょう。しかし、多くの開発者がプラグインを GPL、GNU、一般公衆利用許諾。それはコンプライアンスだけの問題ではありません。それはオープンソースの精神を維持することです。

そこで今日は、特別ゲストとして 10up のオープンソースディレクターである Jeff Paul をお迎えし、彼が今年 WordCamp US で発表した革新的なソリューションを共有していただきます。新しい機能や依存関係を追加する場合でも、コードベースを自動的にスキャンしてプラグインの GPL 互換性を保証するツールがあることを想像してください。

今日はそれについて話します。しかし、本題に入る前に、ジェフ、WordPress の誕生秘話を教えていただけますか?

ジェフ・ポール：そうですね。正確な年は分かりません。おそらく2000年代初頭だったと思います。私は以前の CMS 上に個人サイトを持っていました。Geeklog という名前だったと思います。そして、それと当時のホスティングプロバイダーとの間に、そして他にどれだけ多くの要因があるか誰にもわかりませんが、CMS のコンテンツの崩壊がありました。

それで、当時私はちょうどそれに代わるものを探していました。私は WordPress を見つけました。そして、それは私が必要としていたものに機能しました。ご存知のとおり、私は CMS を構築する道を自分で歩んだわけではありませんが、これは多くの人にとって良い起源物語のようです。しかし、それは、何というか、わかりませんが、2004 年から 2007 年までの範囲のどこかにありましたが、WordPress 4.7 リリースまでは、私がリリースチームに参加したとき、ある種の境界線を越えて貢献できませんでした。ヘレン・ホーサンディとアーロン・ジョービン。つまり、私はプロジェクトの消費者として何年も過ごしましたが、コントリビューターになったのはかなり後になってからであり、それ以来その道を歩み続けています。そうですね、この時点では消費者と貢献者が二重になっています。

DP : そしてあなたは WordPress コアにも非常に積極的に貢献してきました。 10up は、ElasticPress、Distributor、ClassifAI など、数十のプラグインをプラグインリポジトリに維持しています。これらはすべて wordpress.org リポジトリで入手でき、GitHub で公開され、オープンソースの実践を使用して維持されています。

あなたはこれから私たちが取り上げるテーマについてよくご存知です。まずは WordPress リポジトリ (WordPress プラグインリポジトリなど) から始めてみませんか? WordPress リポジトリとは何ですか?また、そこに何かをアップロードできるようにするためのルールは何ですか?

JP : そうですね。したがって、WordPress リポジトリは、WordPress.com とは別、エコシステム内の他のホスト、サードパーティのプラグイン会社やディストリビューターとは別に、オープンソースプロジェクトである WordPress.org によってホストされます。そして、それはそこにあるすべての WordPress インストールに直接リンクまたは関連付けられているものです。 WordPress 管理者がプラグインまたはテーマを検索している場合、それらの検索は WordPress 管理者で利用可能な WordPress.org プラグインリポジトリとテーマリポジトリを通じて行われます。 WordPress.org でも同様です。事実上、同じ検索、同じコンテンツがそこで利用可能です。

そこに何かを掲載するという点に関して、wordpress.org プラグインレビューチームは、プラグイン開発者向けに「すべきこと」と「してはいけないこと」に関する一連の詳細なガイドラインを用意しています。そして、wordpress.org プラグインリポジトリへの最初の送信を行うために、実際の送信ワークフローを実行する必要があります。それが承認されると、プラグイン用に SVN リポジトリが作成されます。そしてご存知のとおり、更新やリリースなどは SVN にプッシュされます。そして、それは、WordPress.org または WordPress 管理内で検索できるものすべてが現在生き生きとしている場所のようなものです。

DP : 私が信じている最初のルールの 1 つは、WordPress リポジトリに置くものはすべて、コードだけでなくフォントや画像も含めて GPL に準拠する必要があるということです。あれは正しいですか？

JP : そうですね。右。つまり文字通り、プラグインチームの最初のルールは、プラグイン全体が GPL 互換でなければならないということです。これは WordPress が従うライセンスと同じであり、前述したように、コード、画像、サードパーティのライブラリはすべて GPL 互換である必要があります。必ずしも実際の GPLv2 ライセンスである必要はありません。GPL 互換のものは他にもありますが、フォント、画像、サードパーティのライブラリ、依存関係など、すべてが GPL 互換である必要があります。プラグイン開発者が書くコードですよね？他のすべてのものも GPL 互換である必要があります。

DP : それで、リスナーを待たせないように、そのまま飛び込んでもいいのです。あなたの話は、GitHub アクションを使用して GPL 互換性をチェックできる方法についてでした。そのプロセスについて説明していただけますか?

JP : そうですね、これは 10Up でのオープンソースのディレクターとしての私の役割に少し由来しています。おそらく、単一のプラグイン、あるいは複数のプラグインを日常的に作成しているプラグイン作成者にとっては、おそらくそれを認識したり、気にしたりするようなことではありません。しかし、ある時点で私はほぼ文字通り、真夜中に目が覚めて次のように考えていたと思います。「すべての画像、すべてのサードパーティの依存関係、すべてのフォント」などは GPL 互換であり、10up では、あなたが言及したように、wordpress.org リポジトリまたは GitHub でも利用できる数十のプラグインを備えた大規模な方法を見つけようとしています。そこのソース。

私は、これらすべてを細かい櫛で調べて、プラグインに使用していた上流の依存関係をチェックして、これらがどのようにライセンスされているかを把握する必要があったのが嫌でした。これは、複数のプラグインはもちろんのこと、単一のプラグインにとっては面倒な作業になる可能性があります。そして、オンライン検索を通じて、そのプロセスを効果的に自動化するために使用できるツールや GitHub アクションがあることを確認しました。これにより、リポジトリの 1 回のスキャンだけで「はい、互換性があるか、いいえ、互換性はありませんが、今後のバグ修正や機能拡張などで、新しい依存関係が追加されたり、プラグイン内の依存関係が変更されたりする可能性があるため、スキャンを継続しました。ライセンスを取得し、それが進行中であることを確認し、その種の初回パススルーを実行できることは、単なる手動で集中的なプロセスになり、継続的な悪夢のようなものにならないように、私が理解しようとしていたことでした。、その互換性。

つまり、最初に私が抱いた懸念は、それは知らなかったということでした。新しい依存関係を含める場合に追加する機能が GPL 互換であるかどうかを知る方法がなかったのです。そして、リリースされたプラグインがソフトウェア内ですでに非互換性を持っていたことを繰り返すという、さらに悪いシナリオが存在する可能性があることに気づきました。

それが私が解決しようと思った最初の問題のようなものでした。最初の初期スキャンですよね? 私たちの個々のプラグイン、そして 10up がサポートするすべてのプラグインは、私たちが宣言したライセンスと本当に互換性がありますか? そして願わくば、彼らがそうであったことを黙ってほしいと思います。そして、そこから、将来の PR が、私のチームや 10up のオープンソース実践者、プロジェクトに貢献している他の 10uper や、コミュニティ内の誰でも、広く、これらは、プラグイン自体に記載されているライセンスを維持していることを確認しました。

DP : ここで明確にしておきますが、もしそうでなかった場合、つまり、準拠していない既存の依存関係か何かがそこにあったことがわかった場合、その波及効果は、ある種の、それとも、ルールに従わなかった場合に受ける可能性のある懲罰的損害の可能性はありますか?

JP : ということは、私は弁護士ではないんですね？つまり、私はこのコメントをするのに弁護士の資格を持っていないので、有効な法的アドバイスではありませんが、プラグインでこれらのスキャンを実行するときに私がとったアプローチは、繰り返しになりますが、私はそうしなかったので、実は、これらすべてを実行して結果がどうなるか非常に緊張していました。

私の計画は、GPL と互換性のないものを使用しているプラグインがあることがわかった場合、問題が何であれ、その依存関係を削除するか、別のものに置き換えて、それを効果的に解決するのが最善のアプローチであるというものでした。そしてすぐに新しいバージョンをリリースしましたね?

すでに出版され、リリースされているものに対してできることはあまりありませんでした。私の観点からすると、意図的にライセンスを回避しようとするような形で行われたものはどれもありません。それは、プラグイン作成者に報告されるセキュリティ問題に似た、ある時点での人的ミスだったでしょう。同様に、最善のアプローチは、セキュリティの問題であれ、この場合はライセンスの問題であれ、プラグインを最新の状態に保っている人々がより安全な状態になるように、修復に取り組み、すぐにリリースすることです。確かに、たまたま大幅な収益を生み出すプラグインがあったとして、そしておそらくその可能性があるとしても、何かをライセンスを外したことが既知の間違いであることを示す理由は別として、私はこの分野で誰もそのような考えを持っていないと思います。は意図的にそうしたことを行っていますが、潜在的に法的リスクにさらされる可能性があるのは、大幅な収益を生むものだけであり、ライセンスの対象となると思います。

そうですね、簡単に言えば、誰かがスキャンを実行して既存のコードベースに問題が見つかった場合、最善のアプローチは実際にリリースや更新バージョンを発行し、変更ログで呼びかけることだと思います。リリースノートで何が変更されたか、そしてその理由を明らかにし、それについて透明性を保ちます。しかし、その時点では、それがプラグイン作成者ができる最善のことだと思います。幸いなことに、10up のプラグインではそのようなシナリオには遭遇しませんでした。幸いなことに、すべてに互換性があり、このレベルの快適さを提供するために自動化をセットアップしてこの道を歩む大多数の人々が同様の経験をすることを願っています。

GitHub アクションが実行されるまで数秒または 1 分間待つのは、少し緊張して不安になるかもしれません。しかし、すべてが過ぎ去ると、おそらくほとんどの人がその状態に陥ると思います。

DP : 快適になると言えば、少し休憩します。座ってリラックスしてください。短いコマーシャル休憩の後に、プラグインの GPL 準拠の維持に関する 10up のオープンソースイニシアチブのディレクターである Jeff Paul とのインタビューの続きをお届けします。この短い休憩の後、さらなる続報にご期待ください。

DP : WordPress コミュニティポッドキャストである Press This へようこそ。私はドクターです。私は Jeff Paul と、GitHub アクションを使用してコードとプラグインが GPL に準拠していることを確認することについて話しています。休憩の前に、これについて少し掘り下げて、完全に準拠していない場合の影響について話し合いました。そして、私はこの特定のことに戻りたかったのだと思います。誰でも作成できる GitHub アクションがあります。しかし、ジェフ、あなたは WordCamp の講演で、公式の GitHub アクションを使用しているとおっしゃっていましたが、それにはいくつかの小さな変更が加えられていると思います。これを行うために人々が求めるべきアクションの名前は何ですか?

JP : そうですね。それが依存関係のレビューアクションです。 GitHub.com、スラッシュアクション、スラッシュ依存関係、ハイフンレビュー、ハイフンアクション。トランスクリプトがそれを正しく理解していることを願っています。問題がある場合は、この件についてのメモが私のサイトにあるので、この講演を取り上げた投稿をご覧ください。したがって、利用可能なリンクがありますが、GitHub アクションマーケットプレイスで依存関係レビューアクションを検索すると、私が使用した公式のアクションが見つかると思います。これは、プラグインの依存関係をチェックするだけではありません。ライセンス以外にもチェックが行われます。また、プラグインの依存関係の脆弱性やその他のものをチェックすることもできます。しかし、私がそれを使用する唯一の目的、つまり私がそれを使用する中心的な目的は、プラグイン内の依存関係に無効なライセンスがないかチェックすることです。

DP : これは、どのタイプの GPL に従いたいかを設定できるアクションです。ライセンスを含めることができ、それに対してチェックが行われます。また、たとえば何十ものプラグインを維持している場合、同じものを引き続きソースできる可能性もあります。管理しているプラグインはすべてその 1 つのディレクトリに保存できるので、毎回アクセスして更新する必要はありません。

JP : そうですね。うん。あなたは WordCamp US で私の講演をじっと聞いていましたね。聴衆の中にいて起きて聞いてくれたことに敬意を表します。あるいは、YouTube や WordPress.tv でそれを視聴したこともありますが、はい、私が期待する標準的なフローが 2 つあります。ここをフォローしてください。

1 つは、1 つまたは非常に少数のプラグインを担当するプラグイン作成者、または 1 対 n スケールでより多くのプラグインを作成し、サポートしているプラグインを多数所有している人です。したがって、1 つしか持っていない人にとって、定義した GitHub アクションは、そのワークフローファイル内で効果的に依存関係レビューアクションを呼び出し、リポジトリをスキャンさせることができます。環境変数は 2 つあります。または指定できるパラメータ。そのアクション 1 はライセンスを許可することであり、その結果としてライセンスが拒否されます。両方を同時に行うことはできません。そして私がとったアプローチは、ライセンスを拒否するのではなく、ライセンスを許可することでした。そこで考えられたのは…許可ライセンスリストに GPL 互換ライセンスを含めるのを忘れて事実上の誤検知が発生するケースのほうが望ましいですよね。たとえば、ライセンスがリストに追加するのを忘れただけであるため、ライセンスと互換性がないというフラグが付けられた依存関係を取得するのに対し、ライセンス拒否リストを使用していて、必要のないライセンスを拒否するのを忘れた場合は、その可能性があります。これは、依存関係が通過し、このチェックで捕捉されないことを意味します。

したがって、私が非常に強く推奨するのは、その許可ライセンスリストを使用することです。また、誰かが単一のプラグインを保守している場合は、ワークフローファイル内のそのパラメータとライセンスのリストを使用するだけです。したがって、10up の場合、プラグインの場合、それはドット GitHub ディレクトリであり、そこにある workflows サブディレクトリです。そして、その依存関係レビューアクションを呼び出す依存関係レビューワークフローがあり、許可ライセンスリストがあり、私のサイトで私のプレゼンテーションを表示するか、オンラインで講演を見つけて、私たちが所有するライセンスのリストを確認できます。 GitHub 上の 10up のリポジトリを探索し、調査したライセンスを確認することもできます。

私たちのワークフローファイルはかなり詳しく文書化されており、プラグインと互換性のあるライセンスであると感じたものを特定する方法を説明しています。したがって、人々は私たちが持っているリストを使用することを歓迎しますし、そのリストのサブセットを使用することも歓迎します。おそらくそのレベルの快適さを感じるために、独自の調査を行うことも歓迎します。しかし、許可ライセンスリストで使用しているものが実際に宣言したものと互換性があることを確認するために、かなり長い調査を行いました。そして、10up ではほぼデフォルトで GPLv2 以降を使用するため、特にリストするライセンスはすべて GPLv2 と互換性があります。

したがって、これは、プラグイン作成者が単一のプラグインを保守している場合にも当てはまります。先ほども述べたように、誰かが複数のライセンスを持っている場合、その中で宣言されたすべてのライセンスを事実上含む別個のライセンスポリシーファイルを作成できます。次に、プラグインのワークフローでその構成ファイル、そのライセンスポリシーファイルを参照します。これにより、前述したように、その時点では、互換性のあるライセンスのリストを維持する必要がある場所は 1 か所だけになります。たまたま、GPLv2 と互換性のある、イニシアチブによって承認された新しいオープンソースのライセンスが存在した場合、そうでしょう? 新しいものが登場したら、それをリストに追加することもできますし、何らかの理由で削除する必要がある場合でも、何十もの場所で削除する必要はありません。これを 1 つの場所で行うと、その構成を参照しているすべてのワークフローファイルが、その新しいライセンスリストを使用してすぐに更新されます。

DP : これはすべて自動化されているので、誰かがプルリクエストを行うと、それはあなたに代わって行われます。右？

JP : そうです、その通りです。したがって、リポジトリにワークフローファイルを作成すると、プルリクエストにトリガーが発生します。したがって、CRON スケジュールで実行するように設定したり、毎週または毎月実行したりすることもできますが、実際には、最初の実行後、依存関係のコードベース全体をスキャンすることになります。実際に必要なのは、受信するプルリクエストだけです。プラグインのデフォルトブランチまたは安定したブランチに PR を要求するというかなり厳密なシステムを使用していない場合は、おそらく個々のコミットをチェックすることもできます。

したがって、ユーザーが使用したい追加のトリガーが存在する可能性があります。 10up の場合、このアクションを確実に使用できるように、また、新しい依存関係を導入したり、ライセンスを変更するためにバージョンを変更したりする依存関係への変更がこれによって捕捉されることを認識できるように、PR にブランチの開発とトランクをかなり厳密に要求する傾向があります。。そうですね、私たちはプルリクエストをピボットしたりトリガーしたりしていますが、人々がどれだけ厳格であるかによっては、特定のブランチへの個別のコミットをチェックしたり、毎日、毎週、毎月、定期的に実行したりすることもあります。コードがまだ合格していること、この場合は 10up の GPLv2 と互換性のないライセンスがないことを知って安心するためです。

DP : ここでまた少し休憩します。戻ってきたら、GPL ライセンスについての Jeff Paul との会話を終えて、以前に触れなかった内容についても取り上げる予定です。この短い休憩の後、さらなる続報にご期待ください。

DP : WordPress コミュニティポッドキャストである Press This へようこそ。ショーを終えて、少しギアを切り替えるつもりです。最近、プラグインリポジトリのレビュープロセスについていくつかの話題があり、基本的に事実として述べておきますが、以前よりも少し時間がかかっています。

一部の人々は、何かがレビューされるまでに何か月もかかることを知っていると言っていますが、私の WordPress 歴のほとんどでは、おそらく 4 週間がピークだったと思います。それで、ジェフ、彼らがおそらくそれに加える変更について話し合っていることは知っています。チームが現在どのようなことに取り組んでいるのか教えていただけますか?

JP : そうですね。うん。そして私は、あなたが言ったことをさらに強調しています。歴史的に見て、私が提出したものはすべて 2 週間以内で、通常報告されているものよりもはるかに速かったと思います。そしてそれは約88日で終わるか、関係者全員にとって残念なことです。

あのチームには多少の入れ替わりがあったと思う。非常に経験豊富な上級者の知識の一部が失われました。そして、その空白を埋めるために快く介入してくれた人たちは、プラグインの処理と最初の提出物のレビューで同じようなスループットを達成できるところまでまだ到達していると思います。そして、その一部を自動化するために彼らは取り組んでいます。つまり、コンピューターが人間よりも優れていることの中には、おそらく WordPress コーディング標準を実行したり、本当に重大なエラーが報告された箇所に重点を置いたりすることなどが挙げられます。人間がこれらのことを調べて処理する代わりに、自動化できるものを実行してチェックするプラグインチェッカーを用意することで、プラグインレビューチームが「自動化されたものは合格しているか?」という最初の一時停止を簡単に得ることができます。もしそうなら、人間によるレビューに飛び込んで、作業を急いでください。本質的に自動化されていて、通過していないことが報告されている場合は、そのプラグイン開発者に対して、「スキャンでこれらの初期のものを特定しました。どうか、それらを解決してください」という応答がより迅速になると思います。その後、更新された zip ファイルを送信して、作業を正常に戻します。

ですから、彼らが自動化を追加しようと取り組んでいることは知っています。その道を支援するために彼らができることが多ければ多いほど良いと思います。なぜなら、現時点ではプラグインが千をはるかに超えており、バックログが長いからです。、そこでは誰も助けません。はい、彼らは自動化に取り組んでいます。彼らがもっとやりたいと思っていることは知っていますし、誰かが自動化に特に才能があり、貢献したいと考えている分野であれば、プラグインレビューチームはその面で何らかの支援が欲しいと思うと思います。その場合は、必ず Slack で連絡してください。

DP : WordCampUS でのあなたの講演、または 10uP がオープンソース領域で取り組んでいるプロジェクトの一部について質問がある場合に連絡を取ることについて言えば、人々があなたに連絡を取る最善の方法は何ですか? ?

JP : そうですね。私のウェブサイトは jeffpaul.com です。私のプレゼンテーションはそこにあります。GPL を検索すれば、おそらくいずれにせよ最初の投稿の 1 つになるでしょう。それ以外の場合、私の電子メールは[email protected] 、仕事用の電子メール、そしてほぼすべてのソーシャルネットワークです。 WordPress.org、GitHub、Twitter、スラッシュ X、そして私は @Jeff Paul です。皆さんもそうやってソーシャルネットワークで私を見つけることができます。

DP : 同様に、リスナーが GitHub 上でおそらく 10uP の作品の例を見つけたい場合、それは GitHub 上の 10up に過ぎないと思いますか?

JP : そうです、そうです、github.com/10up。私たちのプラグインのリポジトリはすべて公開されています。私たちのチームは、新しい問題や PR を綿密に追跡しています。それらはすべて Slack チャンネルにパイプされるので、人々のあらゆる質問、ディスカッションがそこで開かれます。私たちのチームはそれらにかなり反応するはずですが、そうでない場合は、WordPress Slack や Twitter で電子メールで私に連絡することで、どれでも機能します。私はコミュニティの人々とオープンソースについていつでも喜んでチャットします。

DP : そうですね、今日はご参加いただきありがとうございます、ジェフ、あなたと話せて本当に良かったです。GitHub がプルリクエストとそのエクスペリエンスを自動化するためのアクションについて多くのことを学びました。とても助かります。

Press This の先週のエピソードを見逃した方のために、MySQL 5.7 のサポート終了に向けてサイトを準備するために実行できる手順と、MySQL 8 に備える方法についてカルメンジョンソンと話しました。これは本当に良いエピソードです。他にもたくさんあります。転写されたバージョンを見つけたい場合は、TorqueMag.io で見つけることができます。 WMR の WordPress コミュニティポッドキャスト、Press This をお聞きいただきありがとうございます。 Twitter や Torque Mag で私たちの冒険をフォローしてください。

RedCircle、iTunes、Spotify、またはお気に入りのポッドキャスティングアプリで Press This を購読したり、WMR.fm からエピソードを直接ダウンロードしたりできます。私はあなたのホストです、ポピュラー博士です。私は WP Engine での役割を通じて WordPress コミュニティをサポートしており、PressThis で毎週そのコミュニティのメンバーにスポットライトを当てるのが大好きです。