GitHub Blog | 非公式日本語

すべての公開リポジトリでシークレットスキャンアラートが無料で利用可能になりました！

GitHubのシークレットスキャンは現在、すべての公開リポジトリを対象に無料で提供されており、ユーザーが数千件の流出シークレットを発見し、トリアージするのに役立っています。

意外と知らない、GitHub Codespacesでできる10のこと！

GitHub Codespacesは、仮想マシン上に強力な統合開発環境（IDE）を提供し、性能の低いマシンを持つ開発者がローカルリソースを消耗せずにコーディングできるようにし、AI画像の生成など様々なタスクに利用することが可能です。

開発チームと運用チームの一貫したワークフローを構築する方法

GitHubが最近発表した「2022 State of the Octoverse」レポートにおいて、HashiCorp Configuration Language（HCL）がGitHubで最も成長したプログラミング言語となりました。HashiCorpは、クラウドコンピューティングのためのInfrastructure as Code (IaC) 自動化のリーディングプロバイダーです。HCLは、Terraformや Vaultなどのツールと共に使用されるHashiCorpの設定言語で、マルチクラウドやオンプレミス環境において、人間が読みやすい設定ファイルでIaC機能を提供することができます。 HCLの成長は、インフラ、運用、開発者の世界を一つにすることの重要性を示しています。これは常にDevOpsの目標でした。しかし、現実には、多くの企業でこれらの世界がサイロ化したままになっています。 この記事では、開発チームと運用チーム、そしてセキュリティ、ガバナンス、ネットワーク・チームを結びつけるビジネスと文化の影響について見ていきます。そして、GitHubとHashiCorpがCI/CDパイプライン全体を通して一貫したワークフローとガードレールをどのように実現できるかを探ります。 従来の運用（Ops）の世界 HashiCorpの共同創業者であるArmon Dadgar氏は、従来のOpsの世界を「木」に例えて説明しています。トランクには、物事を成し遂げるために企業で必要な、共有され一貫性のあるサービスがすべて含まれています。セキュリティ要件、Active Directory、ネットワーク構成などを考えてみてください。ブランチは、企業内のさまざまなビジネスラインを表し、社内または社外にサービスや製品を提供します。葉は、ソフトウェアやサービスが展開されるさまざまな環境と技術を表します。クラウド、オンプレミス、コンテナ環境などです。 多くの企業では、これらの異なるビジネス領域間のコミュニケーション・チャネルやプロセスが煩雑で、コストがかかる場合があります。インフラやアーキテクチャに大きな変更があった場合、通常、複数のチケットが複数のチームに提出され、企業内のさまざまな部署でレビューと承認が行われます。組織を保護するために、変更諮問委員会が一般的に使用されます。通常、文書化が完了しない限り、変更を進めることはできません。一般的に、将来の監査に必要な一連のガバナンスログと監査可能な成果物が存在します。 もし、チームが最適化された自動化されたワークフローを持ち、それを使って納期を早め、安全なガードレールのセットで仕事を終わらせることができるようになったら、企業にとってより有益ではないでしょうか？これは、時間とコストの大幅な節約につながり、ビジネス価値の向上につながる可能性があります。 最近のForresterのレポートでは、GitHubを使うことで3年間で433%のROIを達成したという結果が出ています。もちろん、時間の節約や効率の向上は言うまでもなく、一貫性と作業の合理化によってもたらされるその他の質的なメリットもあります。 あなたの製品やサービスは、遅々として進まない、手作業でエラーが起こりやすいプロセスではなく、セキュリティとガバナンスが組み込まれた最適化された経路でデプロイされることになるでしょう。これこそ、DevOps、GitOps、Cloud Nativeの夢ではないでしょうか？ IaCの導入 別の例えを使いましょう。IaCは、ソフトウェアやサービスをホストするリソース（サーバー、データベース、ネットワークコンポーネント、PaaSサービスなど）の設計図だと考えてください。 病院と学校を設計する場合、両シナリオで同じ全体的な設計図を使用することはないでしょう。なぜなら、両シナリオはまったく異なる目的を持ち、要件も大きく異なるからです。しかし、2つの設計にまたがって再利用できる構成要素や基礎があるはずです。 HCLのようなIaCソリューションでは、ソフトウェア開発でメソッド、モジュール、パッケージライブラリを再利用するのと同様に、これらのビルディングブロックを定義して再利用することができます。IaCであるため、アプリケーションでコラボレーションやデプロイを行う際に使用するのと同じ推奨プラクティスをインフラに採用することができます。 結局のところ、DevOpsの方法論を採用するチームは、生産性、クラウド対応のスケーラビリティ、コラボレーション、およびセキュリティが向上することが分かっているのです。 より良いデリバリー方法 このような背景から、インフラストラクチャをコード化することで得られる具体的なメリットと、それが従来の運用文化の変革にどのように役立つかを探ってみましょう。 リポジトリにコードを保存する まずは、最も低いところにある果実から始めましょう。IaCであれば、GitHubなどのソースコード・リポジトリにインフラストラクチャやアーキテクチャ・パターンを保存することができます。これにより、完全なバージョン履歴を持つ単一のソース・オブ・トゥルースを手に入れることができる。これにより、必要に応じて変更をロールバックしたり、履歴から特定のバージョンの真実をデプロイしたりすることが容易にできるようになります。 企業内のチームは、Git リポジトリ内の個別のブランチでコラボレーションを行うことができます。ブランチを使うことで、チームや個人は「自分のスペース」で生産的になり、「本番」の真実のソース（通常はメインブランチ）から離れて、他のチームの進行中の作業に悪影響を与えることを心配する必要がなくなります。 前節で述べた再利用可能なビルディングブロックであるTerraformモジュールも、Gitリポジトリに保存されバージョン管理されています。そこからTerraform Cloudのプライベートレジストリにインポートすることで、全チームが簡単にモジュールを発見できるようになります。GitHubで新しいリリースバージョンのタグが付けられると、レジストリにも自動的に更新されます。 早期かつ頻繁にコラボレーションする 上で説明したように、チームは現在の状態に影響を与えないように、別々のブランチで変更を加えることができます。しかし、その変更を本番環境のコードベースに反映させたい場合はどうすればいいのでしょうか。もしあなたが Git に慣れていないのなら、プルリクエストという言葉を聞いたことがないかもしれません。その名のとおり、あるブランチから別のブランチに変更を「引き込む」ことができます。 GitHub のプルリクエストは、チーム内の他のユーザーとコラボレーションするためのすばらしい方法です。ピアレビューを受けることで、フィードバックを自分の作業に反映させることができます。プルリクエストのプロセスは、チーム全体のコラボレーションを促進するために意図的に非常にソーシャルになっています。 GitHub では、ブランチ保護ルールを設定してメインブランチへの直接の変更を不可とすることもできます。そうすれば、すべてのユーザーがコードを実運用に移すにはプルリクエストを経由しなければならなくなります。ブランチ保護ルールには、最低限必要なレビュアーの人数を指定することもできます。 ヒント:GitHub のCODEOWNERS ファイルという特殊なファイルを使えば、編集中のファイルに基づいてプルリクエストにレビュアーを自動的に追加することができます。例えば、すべてのHCLファイルは、コアインフラストラクチャチームによるレビューが必要かもしれません。あるいは、勘定系システムのIaC設定には、コンプライアンスチームによるレビューが必要かもしれません。 通常、特定の周期で行われる変更諮問委員会とは異なり、プルリクエストはコードを本番環境に導入するためのプロセスの自然な一部となります。また、意思決定や議論の質も向上します。外部システムで推奨される「イエス/ノー」の決定ではなく、プルリクエストで直接コンテキストと推奨を確認することができます。 プロビジョニングプロセスではコラボレーションも重要です。GitHubとTerraform Cloudの統合により、これらのプロセスを複数のチーム間でスケールさせることができます。Terraform Cloud は Terraform の状態を安全に保存し、GitHub リポジトリと直接統合することで、プルリクエストとマージのライフサイクルをターンキーで体験できるようなワークフロー機能を提供します。 自動化された品質レビューをプロセスに取り入れる 前節の続きですが、プルリクエストでは、提案された変更の品質を自動的にチェックすることもできます。ソフトウェアでは、アプリケーションが正しくコンパイルされているか、ユニットテストは合格しているか、セキュリティの脆弱性はないかなどをチェックするのが一般的です。 IaCの観点からは、同様の自動チェックを我々のプロセスに取り入れることができます。GitHub のステータスチェックを使えば、特定の条件を満たしているかどうかを明確に把握することができます。 GitHub Actions は、GitHub のプルリクエストでこうした自動チェックを実行するためによく使われるものです。IaCの品質を判断するために、以下のようなチェックを入れることができます。 コードが構文的に正しいかどうかを検証する（例えばTerraform validate）。 コードが特定の標準に従っていることを確認するためのLinting（例えば、TFLintや Terraform format）。 静的コード解析により、「設計時」にインフラストラクチャの設定ミスを特定します (たとえば、tfsecやterrascan など)。 関連するユニットテストまたは統合テスト（Terratest などのツールを使用）。 インフラストラクチャを「スモークテスト」環境にデプロイし、インフラストラクチャの構成が（既知のパラメータセットと共に）望ましい状態にデプロイされることを検証します。 Terraform on GitHubを使い始めるのは簡単です。TerraformのバージョンはLinuxベースのGitHubでホストされたランナーにインストールされていますし、HashiCorpには公式のGitHub Actionがあり、指定したTerraformバージョンを使ってランナーにTerraformをセットアップしてくれます。

アジリティを低下させることなく、コンプライアンスのニーズに応える3つの方法

コンプライアンス要件に対応 3つの実践的なステップを踏むことで、社内の文化を変革することなく、コンプライアンス要件を満たし、開発者の生産性と幸福度を向上させることが可能になります。

新しいデータセットでオープンソースに関する政府の政策を測定する

GitHub Policyは、ソフトウェアがどのように構築され、誰がそれを構築するのかに影響を与える政策の開発に情報を提供するための研究とデータを支援することを誇りにしています。 GitHub Policyは、以下のような研究を支援しています。

GitHub Codespacesを使った初心者向けコーディング学習ガイド

新しいコードスペース GitHub Codespacesは、学んだことを応用し、新しい言語やフレームワークを習得するのに有効なツールです。

GitHub Copilotによる責任あるAIペアプログラミング

AIが生成するテキストとコード: GitHub Copilotは、OpenAI Codex を使用して開発者のコーディング作業を支援し、生産性を向上させ、ChatGPTやDALLE-2のようなAIとペアリングするプログラミングの領域に加わります。

ソースコードアーカイブとハッシュの今後の安定性に関する最新情報

2023年1月30日、GitHubはソースコードのダウンロード時の圧縮設定を若干変更する変更を導入しました。この変更は、多くのコミュニティにとって予期せぬ結果となり、その報告を受けた後、私たちはこの変更を元に戻しました。何が起こったのか、予期せぬ事態を防ぐためにどのような対策をとっているのか、そして今後の変更にどのように対処するのかを説明したいと思います。 以下がその内容です。 GitHubでのソースのダウンロードは、Gitのarchiveコマンドに依存しています。GitHubのデータ量が多いため、私たちはgitアーカイブの結果を永久に保持しません。一時的にキャッシュされ、その後削除され、再び要求されたら再作成されます。これは、リリースやタグ、そして任意のコミットを、ストレージの必要量を維持できないレベルまで膨らませることなく利用できるようにするための、良いバランスを保っているのです。 1月30日には、ソースのダウンロードを支援するサービスにGit 2.38をデプロイしました。このバージョンのGitは、gitアーカイブの生成に使われるデフォルトの圧縮コマンドを、外部のgzipから内部のgzipコピーに変更しました。アーカイブに含まれるファイルは同一でしたが、圧縮設定の小さな変更は、アーカイブ自体のバイトレイアウトが変わることを意味しました。これは、アーカイブのハッシュや チェックサム(SHA256, CRC64 など) も変化することを意味します。 その結果として、多くのコミュニティがソースのダウンロードとそのハッシュについて想定していました。再現性やセキュリティを確保するために、多くのシステムはアーカイブを一旦集中的にダウンロードし、そのハッシュを自分たちのリポジトリに記録しています。後でユーザーが GitHub からアーカイブをダウンロードすると、そのクライアントは自動的にアーカイブのハッシュを、先に記録されたものと照合します。もし不一致があれば、クライアントは処理を拒否します（何かが変わったのであれば、それが改ざんされたものなのか、壊れたダウンロードなのか、それとも他のものなのかを人間が判断する必要がある、という想定で）。 この結果が予想外のものだったか イエスでもありノーでもあります。私たちは、git archiveコマンドのデフォルトが変更されたことは知っていました。予想外だったのは、このことが多くのコミュニティに広く影響を与えるかもしれないということです。 内部的には、私たちは長い間git archiveのバイト単位の安定性を保証すべきではないと考えてきました。デフォルトや利用可能なオプションさえも、Gitプロジェクトによってコントロールされており、同様にそのような保証はしていないのです。私たちは、私たちがフォークしたGitと上流のGitとの間の差異を最小にするよう努力しています。したがって、archiveコードに恒久的なパッチを持ち込むことは避けたいと考えています。 しかし、今回の事件で、私たちはこのスタンスを必ずしも明確にしていなかったことを知りました。今、私たちがすべきことは、このスタンスをコミットすることです。このコミットメントに加え、私たちは開発サイクルにテストを追加し、将来的な変更をGitHub.comに反映する前に検出できるようにします。(GitHub Docsはこのコミットメントを反映するためにまもなく更新されます) アーカイブとハッシュの将来的な安定性 GitHubは、今日から1年以上（2023年2月21日）、ダウンロードしたソースをバイト単位で安定的に保持する予定です。これはtarball (.tar.gz) とzipball (.zip)の両方の形式をカバーしています。 将来、どちらかのアーカイブ形式を変更する場合は、6ヶ月前にドキュメント、ブログ、変更履歴でお知らせします。(圧縮パスに重大な脆弱性が発見された場合、私たちのシステムとお客様を保護するために、通知期間を短縮または省略する権利を留保します。このような結果は想定していませんが、わからないものです)。 この変更がもたらす影響の大きさを改めて認識したため、現在のところ、どちらのフォーマットも変更するつもりはありません。完全な透明性を保つために、私たちが修正したいと思ういくつかの欠陥 (zipball に埋め込まれたタイムスタンプ、tarball のシステムgzipへの依存) がありますが、当面の間、私たちはこれらの小さな問題を回避するように設計します。 もしあなたが再現性のためだけに安定したアーカイブに依存しているのなら (アーカイブの中に常に同一のファイルがあることを保証するため)、私たちはソースアーカイブをソースアーカイブ REST API を使って、:refパラメータにコミット ID を指定してダウンロードすることをお勧めします。ハッシュを記録する必要はありません。コミットIDによって、アーカイブ内のファイルの内容が常に同じであることが保証されるからです。GitとGitHubは、コミットIDの生成方法の性質上、これを保証しています。コミットIDを使うことで、リポジトリがタグを書き換えたりブランチヘッドを移動したりしても、影響を受けないようになります。tarball と zipball の形式には、切り捨てに対する保護が組み込まれています。また、TLS (HTTPSによる) によってアーカイブの破損を防いでいます。 セキュリティのために安定したアーカイブに依存している場合 (たとえば、誤って tarbomb を起動しないようにする)、ソースのダウンロードを使う代わりに、リリースアセットに切り替えることをお勧めします。リリースページでは、GitHubにアップロードされたアセットがファイルサイズとともに表示されます。ファイルは、ウェブから手動で追加するか、この（サードパーティ製の）GitHub Actionのようなものを使ってリリースに追加することができます。後でRelease Assets REST API を使ってファイルを取得することもできます。リリースアセットに依存することが不可能な場合は、将来の（頻繁ではない）ハッシュの変更に対応できるような設計を検討することを強くお勧めします。

見逃した人向けに: CodeQLの機能強化

GitHubは、Rubyコードベースのスキャンやモバイルアプリケーションのスキャン機能など、CodeQLに多くの機能強化を行い、開発者がワークフローを中断することなくコードを保護できるよう支援しています。

Copilot for Business の一般提供（GA）を開始

GitHub Copilotは世界初の大規模なAIペアプログラマーであり、この度すべての開発者、チーム、組織、企業向けに提供を開始しました。

GitHub CopilotにAIモデルの改良と新機能が追加されました

GitHub Copilotのコード提案の核となるCodexモデルを改良しました。 GitHub Copilotは改良されたCodexモデルにより、より正確で反応の良いコード提案を実現し、開発者がより速くコーディングできるようアップグレードされました。

Gitのセキュリティ脆弱性に関する発表

本日、Git プロジェクトは、バージョン 2.39.1 以降に存在するセキュリティ脆弱性(CVE-2023-22490およびCVE-2023-23946) に対応した新バージョンをリリースしました。それぞれ、Gitのローカルクローンの最適化、およびgit applyに影響を及ぼします。 CVE-2023-22490 リポジトリをクローンするとき、Git はクローンの URL スキームに適したトランスポート機構を選択して使用します。しかし、ローカルリポジトリをクローンする場合、Git は代わりに別のローカルクローン最適化を使い、コピー元からコピー先まで直接ファイルをコピーします。 特別に作られたリポジトリは、ローカルでないトランスポートを使うときにローカルクローン最適化を使うようにGitをだますことができます。Gitは、$GIT_DIR/objectsディレクトリにシンボリックリンクが含まれるリポジトリからのクローンを中断します。しかし、トップレベルの$GIT_DIR/objectsディレクトリは、それ自体がシンボリックリンクである可能性があります。 この2つを組み合わせることで、被害者のファイルシステムから既知のパスに基づいた任意のファイルをクローンの作業コピーに含めることができ、CVE-2022-39253 と同様の方法でデータを流出させることが可能です。 [ソース］ CVE-2023-23946 Git では、git apply でリポジトリの履歴に任意のパッチを適用することができます。悪意のあるパッチが作業コピーの外にファイルを作成するのを防ぐために、git applyはシンボリックリンクを越えてファイルを書き込もうとするパッチを拒否します。 しかし、悪意のあるパッチがそのシンボリックリンクを最初に作ってしまうと、この仕組みがだまされてしまうことがあります。これを利用して、信頼できないソースから悪意のあるパッチを適用すると、被害者のファイルシステム上に任意のファイルを書き込むことができます。 [ソース］ Gitの最新バージョンにアップグレードする これらの脆弱性から保護する最も効果的な方法は、Git 2.39.2 にアップグレードすることです。すぐにアップデートできない場合は、以下のステップを踏んでリスクを減らしてください。 信頼できないリポジトリに対してgit cloneを--recurse-submodules付きで実行しないようにする。 信頼できないリポジトリからの入力に対してgit apply/git amを実行しないようにします。 ワークフローでサブモジュールが必要な場合は、各.gitmodulesファイルに疑わしいモジュールの URL が含まれていないことを確認した上で、サブモジュールの各レイヤーを繰り返しクローンすることができます。 パッチを適用しても安全かどうかわからない場合は、git apply --stat でパッチの内容を調べます。シンボリックリンクとその先にあるファイルを作成するようなパッチを適用するのは避けましょう。 これらの攻撃からユーザーを守るために、GitHubは積極的な措置をとっています。具体的には、以下の通りです。 CVE-2023-22490およびCVE-2023-23946において、GitHub.com が攻撃のベクトルとして使用されることを防ぐための緩和策を実施しました。 本脆弱性の悪用を防止するGitHub Desktopのリリースを本日2月14日以降に予定しています。 GitHub CodespacesとGitHub Actionsに、Gitのバージョンをアップするためのアップデートを予定しています。 GitHub Enterprise Serverに、パッチを適用したバージョンのGitのアップデートを予定しています。 CVE-2023-22490のクレジットは yvvdwf に、CVE-2023-23946のクレジットは GitLab の Joern Schneeweisz に帰属します。この修正は、GitHub の Taylor Blau 氏と GitLab の Patrick Steinhardt 氏がそれぞれ行い、さらに git-security メンバがフィードバックとレビューを行っています。

Yout amicus: デベロッパーのイノベーションの権利を守るために戦います

開発者のコラボレーションを通じて人類の進歩を加速させるという使命のもと、私たちは開発者のイノベーションの権利を不必要に損なうような法的展開に対して、時折、闘う必要があります。そのため、GitHubはYout LLC v. Recording Industry of America, Inc.の控訴審において、アミカスブリーフ (第三者意見募集)を提出しました。。

リリースレーダー: フェスティバルエディション - 2022年12月～2023年1月

リリースレーダー🎄のスペシャルエディションへようこそ。クリスマスのお祭り、忘年会、旧正月、あるいは単に休暇を楽しんでいる間、ほとんどの人がお祝いをしています。さて、今回は12月中にメジャーバージョンリリースを行った素晴らしいオープンソースプロジェクトをお祝いします。

GitHubの新しいコード検索を支える技術

GitHubは、「コード検索はどのように機能するのか」という疑問に答えるために、Rustでゼロから独自の検索エンジンを構築しました。この記事では、この製品のシステムアーキテクチャと技術的基盤の概要について説明します。

流れに身を任せながらOWASPの脆弱性を緩和する方法

セキュリティ脆弱性の発生ペースと規模が拡大しています。これは、チームが何年も前からコードの安全性を保とうとしてきたにもかかわらず、です。では、なぜ脆弱性がこれほどまでに問題なのでしょうか？チームが、開発者の体験を最適化しないセキュリティツールや戦略を使用すると、開発が遅くなります。これはフラストレーションを生み、顧客の使い勝手を悪くし、ビジネスの成功を妨げることになります。このようなツールや戦略を使用する企業は、結局、セキュリティの優先順位を下げ、ソフトウェアを早くシッピングすることに注力しています。 GitHubでは、開発者の生産性を高めながら、脆弱性を緩和するお手伝いをしたいと考えています。幸いなことに、Open Web Application Security Project (OWASP)がその手助けをしてくれます。OWASPは脆弱性のトップ10リストを提供しており、開発者や組織がアプリケーションのセキュリティやコンプライアンスリスクに対処するために必要な情報を提供しています。本日は、OWASP の脆弱性のいくつかと、開発者の生産性を維持し、さらに向上させながらソフトウェアを安全に保つための、開発者に最適な戦略について検討します。 ユーザビリティを犠牲にしたセキュリティは、セキュリティを犠牲にすることになるのです。 - Avi Douglen、OWASP 理事会 1.理想的なアプリケーションセキュリティ環境 まず第一に、開発チームには、成功を促進する環境が必要です。そして、その最も重要な部分は、開発者のワークフローにセキュリティを埋め込むことです。一般的に、セキュリティリスクを特定するために、サードパーティの異種ツールを使用します。しかし、これらのツールは遅く、ノイズが多く、生産性を低下させる可能性があります。しかし、セキュリティを開発者のフローに組み込むと、コードを迅速かつ容易に保護することができます。GitHub Advanced Security ebookで説明したように、その他の理想的な環境の構成要素は以下のとおりです。 コード、シークレット、サプライチェーンにまたがるセキュリティ態勢の可視化。 軽量で文脈に応じたコミュニケーション・チャネルにより、容易なコラボレーションを可能にする。 ビジネスニーズに合わせた拡張性 ビジネスの成熟度によっては、これらの機能を一度に実装することは不可能かもしれません。しかし、ビジネスの成熟度や継続的な改善に伴い、この理想的な環境を育成することで、脆弱性から保護し、安全なソフトウェアをより早くシッピングできるようになります。 2.OWASP 脆弱性のリスク軽減と予防 理想的な状態を説明したところで、いくつかの OWASP 脆弱性と、それを軽減するためのテクニックを見ていきましょう。 A02-Cryptographic Failures（暗号の失敗 開発者は、自分のソフトウェアを意図的にセキュリティの脅威にさらすことはありません。しかし、API キー、平文パスワード、セキュリティ・トークン、その他の機密データがコード内に残り、暗号の脆弱性につなが ることがあります。 理想的には、秘密が企業、組織、またはリポジトリに到達することはありません。しかし、それらはしばしば発生し、緩和される必要があります。幸いなことに、GitHub Advanced Securityが役に立ちます。 GitHub の秘密スキャン機能は、プッシュ保護機能を実装することで、コードをスキャンして公開されている秘密を探すだけでなく、プッシュで信頼度の高い秘密 (誤検出率の低い秘密) をチェックすることもできるようになります。検出された秘密はすべてリストアップされるので、それを見直して削除することができます。削除しないことが決定された場合、監査証跡が作成されます。 A03-Injection クロスサイトスクリプティング、パスインジェクション、SQLインジェクション、NoSQLインジェクションは、長年アプリケーションを悩ませ、OWASPトップ10に入り続けている脆弱性のいくつかです。 これらの脆弱性に対処する戦略の1つは、一貫した効果的なセキュリティコードレビューを実施することです。コードがきれいになり、技術的負債やコード臭がなくなるだけでなく、より安全になるのです。これらの脆弱性をレビューすることは、既存のGitHubプルリクエストのワークフローの一部とすることができます。 コードスキャンは、機械学習の力を活用してインジェクションの脆弱性を発見し、開発者やセキュリティ専門家へのリスク伝達を支援することも可能です。CodeQLはコードスキャンを強化し、セキュリティ脆弱性がないかデータをスキャンします。 A04-Insecure Design 脅威のモデル化戦略を導入することで、開発者、セキュリティ専門家、さらにはリスク管理チーム間のコラボレーションを促進することができます。これにより、コードが一行も書かれる前に、アーキテクチャとデザインパターンが可能な限り安全であることを確認することができます。 A06-Vulnerable and Outdated Components (脆弱で古いコンポーネント) オープンソースコンポーネントの採用が急速に進む中、ソフトウェアの構成を理解し、脆弱性のあるコンポーネントを更新できるようにすることが、これまで以上に重要になっています。 脆弱なコンポーネントや古いコンポーネントのリスクを管理するための最善の戦略の1つは、セキュリティ脅威が発見されたらすぐに開発者に警告し、通常のワークフローやツールの中で対策を講じることができるようにすることです。 Dependabotを活用することで、既知の脆弱性を持つソフトウェアの依存関係をリポジトリが使用する際にアラートを受け取ることができます。セキュリティチームからプルリクエストを起こすこともでき、セキュリティと開発者がコミュニケーションをとるためのシンプルで効果的な方法となります。 これらのツールの最も良いところは、すべてが GitHub の中で行われることです。そのため、生産性の低下や過度なコンテキストの切り替えを心配する必要はありません。 開発者の力を引き出すアプリケーション・セキュリティ これらの戦略を実施することで、開発者組み込みの、コラボレーション可能でスケーラブルなアプリケーション・セキュリティ環境を構築し、サプライチェーン全体のリスク軽減を実現することができます。同時に、開発者の生産性に悪影響を与えないようにすることができます。 当社は、2月15日から16日まで開催されるOWASP 2023 Global AppSec Dublinのイベントに参加し、ブース#DA2に出展します。このトピックをより深く掘り下げ、これらの戦略に関するあらゆる疑問にお答えするため、当社のエキスパートとの時間を予約してください。 ハンズオンの経験を積みたいですか？GitHub Skillsで、その詳細と、その他の実践的な学習方法をご覧ください。

Ludum Dare 52: スタッフのピックアップ🕹

20年近く続いている週末限定のゲームジャム「Ludum Dare 52」が終了しました。今年のテーマは「収穫」で、応募されたゲームの数はなんと1632本にもなりました。 Ludum Dareは、数日間でゼロからゲームを作り上げるオンラインコンテストです。ただ、応募作品は、大会開始時に発表されるテーマに沿っていなければなりません。例えば「収穫」がテーマなら、コンバイン、麦畑、魂を刈り取る死神（！）、果物集めなど、さまざまなゲームが登場することでしょう。その豊かな歴史については、ウィキペディアをご覧ください。 Ludum Dare 52 の中から、今すぐプレイでき、フォークやクローン、ハッキングが可能なベスト 10 作品をご紹介します。どうぞお楽しみください。 ボバ プレイ </div> <div class="d-flex flex-row flex-items-center mt-2" style="flex-grow: 1;"> <a class="btn-mktg btn-small-mktg btn-muted-mktg d-block mr-2" href="https://github.com/DanielMullinsGames/LD52" target="_blank"> <svg class="octicon d-inline-block mr-1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" width="16" height="16"><path fill-rule="evenodd" d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.

AI時代のリーダーになるチャンスはヨーロッパにある

GitHubのCEOであるトーマスが、ブリュッセルのAI法に関する会議で行った公演です。新しい世代の開発者が次の素晴らしいものを作るのを支援するために、開発者とオープンソースコミュニティのありかたの重要性について説明しています。

GitHub ActionsでIssueOpsによるブランチデプロイメントを可能にする

GitHubでは、ブランチ・デプロイ・モデルはどこにでもあり、私たちがコードをプロダクションにシッピングする標準的な方法であり、それは何年も前からそうでした。私たちは、2015年にChatOpsでブランチデプロイを行う方法の詳細を公開しました。 私たちはほとんどのリポジトリでChatOpsを使用してブランチデプロイメントを実行することができますが、ChatOpsが単にうまくいかない状況もいくつかあります。もし開発者がブランチデプロイを活用したいが、リポジトリにChatOpsのフルスタックを統合していない場合はどうすればいいのでしょうか？私たちは、すべての開発者がGitHubのリポジトリから簡単にブランチ・デプロイを利用できる方法を見つけるために、branch-deploy Action を作りました！ GitHubはこのアクションをどのように使っているのか？ GitHubは主にChatOpsとHubot)を使って、可能な限りブランチデプロイを促進するようにしています。ChatOpsが使えない場合は、このbranch-deploy Actionで代用しています。私たちのユースケースの大半は、Infrastructure as Code (IaC)リポジトリで、インフラの変更をTerraformを使ってデプロイしています。GitHubはこのActionを多くの内部リポジトリで使っていますし、npmもそうです。他にも多くの公共、オープンソース、企業組織がこのActionを採用し、コードを本番環境にシッピングするのに役立っています。 ブランチ・デプロイ・モデルを理解する branch-deploy アクションを理解する前に、まずブランチデプロイモデルとは何か、そしてなぜそれが有用なのかを理解しましょう。 ブランチデプロイモデルを理解するために、まず伝統的なデプロイ → マージモデルを見てみましょう。それは次のようなものです。 ブランチを作成する ブランチにコミットを追加する プルリクエストを発行する フィードバックやピアレビューを収集する ブランチをマージする。 デプロイはメインブランチから開始されます。 では、ブランチのデプロイモデルを見ていきましょう。 ブランチを作成する。 ブランチにコミットを追加する。 プルリクエストを作成する。 フィードバックとピアレビューを収集する 変更をデプロイする 検証する あなたのブランチをmain/masterブランチにマージする。 mainブランチが本当に安定したブランチになることはないため、マージデプロイモデルは本質的にリスクが高いです。デプロイに失敗したり、ロールバックが必要になったりした場合は、もう一度すべてのプロセスをたどって変更をロールバックすることになります。しかし、ブランチデプロイモデルでは、mainブランチは常に「良い」状態であり、いつでもブランチデプロイからデプロイを元に戻すことができます。ブランチデプロイモデルでは、ブランチが正常にデプロイされ、検証された時点で初めて変更をmainブランチにマージします。 注：これは、GitHub flowと呼ばれることもあります。 主要な概念 ブランチ・デプロイ・モデルの主要な概念です。 mainブランチは、常に安定したデプロイ可能なブランチであるとみなされます。 すべての変更は、mainブランチにマージされる前に本番環境にデプロイされます。 ブランチデプロイメントをロールバックするには、mainブランチをデプロイします。 ここまでで、ブランチ配備の方法論に納得していただけたのではないでしょうか。では、どのように実装すればいいのでしょうか?GitHub Actions を使った IssueOps の紹介です。 IssueOps (課題処理) IssueOps を定義するには、似たようなものであるChatOps と比較するのが一番わかりやすいでしょう。ChatOps という概念はすでにご存知かもしれませんが、そうでない場合はここで簡単に定義しておきましょう。 ChatOpsとは、チャットボットと対話し、チャットプラットフォームで直接コマンドを実行するプロセスのことです。例えば、ChatOpsでは、ウェブサイトの状態を確認するために、.ping example.orgのようなことを行うことができます。 IssueOpsは、同じ考え方を採用していますが、媒体が異なります。コマンドを実行するためにチャットサービス（DiscordやSlackなど）を使うのではなく、GitHub Issueやプルリクエストのコメントを利用するのです。GitHub Actionsは、IssueOps コマンドが呼び出されたときに、私たちが望むロジックを実行するランタイムです。 GitHub Actions どのように動作するのでしょうか？このセクションでは、この Action がどのように動作するのかを詳しく説明し、あなたのプロジェクトで活用するきっかけになればと思います。完全なソースコードと詳細なドキュメントはGitHubで見ることができます。 以下、branch-deploy Actionのデモ設定を使って、その手順を説明します。 1.1. GitHub リポジトリの.github/workflows/branch-deploy.ymlの下に、以下のファイルを作成します。 name: "branch deploy demo" # The workflow will execute on new comments on pull requests - example: ".

GitHub DocsチームによるGitHub Projectsの利用方法

ドキュメントは、未来の自分へのラブレターのようなものだと言われています。 もしそうなら、GitHub Docsは、毎日ヘルプやサポートを求めている1億人の開発者へのラブレターと言えるでしょう。アカウントを取得したい学生から、GitHub Enterprise Serverのセットアップを必要とする熟練した上級開発者まで、Docsはそれぞれの人がいる場所で、彼らが話す言語（そしてコーディングも）で対応します。 GitHubは、組織が生産性とイノベーションを促進できるよう支援することを約束します。ここでは、DocsチームがGitHub Projectsを使って2,396のオープンソースDocs記事（すべての言語とバージョンを数えると18,545記事）を管理する理由と方法を探ってみましょう。 複雑さがあるのなら、GitHub Project をぜひ 42人で構成される Docs チームは完全リモートで、北米、オーストラリア、ヨーロッパ、アフリカと世界中に散らばっています。このような多様なチームがこのような大規模なイニシアチブに取り組むには、堅牢なプロジェクト管理ツールが必須です。幸いなことに、GitHub Projects は見事に機能しています。私たちは、隔週で行われる作業サイクルの追跡、作業の優先順位付けと計画、組織全体での作業の可視化、問題のトリアージ、リリースの管理にこのツールを使っています。 ワークフローを活用する ご想像の通り、Docsの記事はかなりの量のバージョン管理が必要です。ある記事はすべてのバージョンで利用でき、ある記事は GitHub.com 専用、またある記事は GitHub Enterprise Server 専用です。さらに、記事によって内部条件が異なり、一つの段落や単語でさえも、あるバージョンでは関連するが、他のバージョンでは関連しないことがあります。このため、私たちのチームにとっては、管理に際しての複雑さが増しています。 しかし、GitHub Projects はさまざまな種類のワークフローを有効にすることで、この複雑さを軽減しています。これらのワークフロー（私たちはGitHub Actionsのワークフローと 組み込みのワークフローの両方を使用しています）により、必要なものをすべて正確に把握することができるのです。これは特にローンチの際に役立ちます。ローンチのたびに、50以上の新しい記事を作成する必要があるかもしれません（通常の日では、15～20のプルリクエストといくつかのアップデートが必要な場合があります）。さまざまなワークフローを有効にすることで、すべてを整理し、軌道に乗せることができます。 ラベルはありますか？ さらに、課題にはラベルを追加できます。これにより、課題がどの機能を追跡しているのか、チームに何を求めているのかが、一目瞭然になります。このラベルは、特にレビュープロセスで役立ちます。私たちのチームは、外部貢献者用のラベル、内部貢献者用のラベル、といった具合にラベルを追加しています。新しいラベルを追加するたびに、GitHub Actions のワークフローが開始されます。たとえば、"ready-for-review" ラベルを追加すると、プルリクエストが自動的にレビューボードに追加されます。また、チームメンバーはワークフローを混乱させることなく、ラベルを使用して独自のビューやインサイトを作成することができます。 魅力的なビジュアル GitHub Projects では、チームメンバーはボードを別のビューで表示できるため、誰でも簡単に可視化・整理することができます。たとえば、私たちのチームにはマネージャーとライターという大きなグループがあります。このふたつのグループは、それぞれの役割に適したプロジェクトボードのビューを使い分けます。同じことが、サブセットチームの人々や、社内の全く別の部署の従業員にも当てはまります。このように、様々な方法でボードをカスタマイズすることで、誰もが必要なもの、見たいものを即座に見ることができます。これによって、スピードアップを図ることができます。また、@me機能により、各メンバーは自分に関連するタスクを見ることができ、知るべきことを即座に知ることができます。 GitHub Project + GitHub Action の最高の組み合わせ 私たちのチームにとって、GitHub Projects を使う最も良いことのひとつは、他の GitHub 製品と簡単に組み合わせて機能を拡張できることです。たとえば、ワークフローをカスタマイズしたり拡張したりするために GitHub Actions を追加しています。このツールとProjects APIを使うことで、プロジェクトを完全に制御できるようになります。GitHub Actionsでは、課題の追跡にレベルを追加し、チームのサブセット（Docsコンテンツ、Docsエンジニアリング、Docs戦略、マネージャーなど）が独自のワークフローで課題をトリアージできるようにもしています。一般的に、GitHub はプラットフォーム全体の統合を可能にするので、私たちが必要とするツールや機能が随所に組み込まれ、シームレスなエクスペリエンスを実現します。 https://github.blog/wp-content/uploads/2023/02/216196044-71c83c1f-a04d-4ba9-87fd-ac9f567326bf.mp4 結論 私たちは、時間を節約して楽しいことに取り組みたいと思っています。GitHub Projects は私たちにぴったりで、直感的に操作できるため、ほとんど意識することがありません。このことが私たちにとって何を意味するのか、おわかりでしょうか。世界中のデベロッパーにラブレターを書く時間が増えるのです。 GitHub Projects を始める準備はできましたか？今すぐどうぞ。

All In for Maintainers の DEI Resource Hub を開設

2021年、私たちは All In を立ち上げ、オープンソースコミュニティに、多様性、公平性、包括性（DEI）のための強力なムーブメントを生み出すために協力する機会を提供しました。All in for Studentsプログラムによる 300 人以上の学生の支援から、2021Open Source DEI Surveyにおける 7,000 人以上の声の収集、Maintainers Listening Tour における 300 人のコミュニティメンバーの受け入れまで、我々は耳を傾け、学び、そして今 All In の次のイニシアティブを構築する準備が整っています。 今日、私たちはAll In for Maintainersイニシアチブとその最初のプログラムであるAll In for Maintainers DEI Resource Hubの立ち上げを発表できることを嬉しく思っています。All In for Maintainersは、コミュニティにおける多様性と包括性を促進するために必要なトレーニングとテクニカルサポートを、メンテナンス担当者に提供することを目的とした包括的なイニシアチブです。新たに開設されたDEIリソース・ハブは、メンテナーによるメンテナーのためのものです。DEIリソース・ハブの重要性をご理解いただき、ぜひご活用ください。 より包括的なコミュニティを構築するために、メンテナを支援する メンテナーは、オープンソースコミュニティにとって、組織内のチームにとってのマネージャーのようなものです。メンテナーとコミュニティのリーダーは、コミュニティで起こることに直接的な影響力を持ちます。彼らは、オープンソースプロジェクトにおいて、誰かが歓迎されていると感じるか、歓迎されていないと感じるか、そのトーンを設定します。 このことを念頭に置き、私たちは、メンテナーの経験に焦点を当てることで、オープンソースの多様性とインクルージョンへの取り組みに焦点を当てました。2021年、私たちは「メンテナリスニングツアー」を実施し、コミュニティ内で多様性、公平性、インクルージョンを推進する際にメンテナが直面する重要な課題を明らかにするのに役立てました。 インクルージョンはコミュニティレベルで行われます。 コミュニティやプロジェクトでDEIを推進する際に、何から手をつければいいのか、誰にサポートを求めればいいのかわからないというのは、メンテナンス担当者からよく聞く課題の一つです。そのため、DEIのスタート地点となるリソースを一箇所で見つけることができるウェブサイトやリポジトリを望んでいることがわかりました。 そこで、私たちはオープンソースの実践者とDEIの思想的リーダーのコミュニティとして、このサイトを一緒に作りました。以下はこのハブで見つけることができるコンテンツの種類の例です。 包括的なリーダーシップ オープンソースプロジェクトに信頼性をもってコントリビューターを引き寄せる。 プロジェクトのためのオープンソース・インクルージョン基本チェックリスト アクセシビリティ ADHD、失読症、自閉スペクトラム症の人のためのオープンソースにおけるアクセシビリティ 視覚障害者のためのLinuxのリミックス バーンアウトとウェルビーイング オープンソースのメンテナは燃え尽きた後どうするのか？ プロジェクトの幸福 オープンソースの多様性、公平性、包括性への貢献 この共創とリソース共有のプロセスにおいて、私たちはこのハブを確実に更新し、包括的なコミュニティを作り、サポートするためにメンテナが必要とするものと一致させるつもりです。オープンソースコミュニティとソフトウェア開発者の人口統計が進化するにつれて必要となる会話や研究、ツール、データを提供し続けたいと考えています。そこで、あなたの出番ですあなたやあなたのコミュニティにとって有益で、共有したいDEIコンテンツがありますか？DEI Resource Hubに掲載するために、DEI Content Submission formに記入して、リソースを提出してください。 一緒に働くことで、私たちは、オープンソースにおける包括的で多様な空間を支持するために必要なツールに誰もがアクセスできることを保証することができます。そうすることで、コラボレーションと透明性を促進し、より多様で包括的なコミュニティを一緒に作ることによって、オープンソースの最初の教義を構築することを望んでいます。 DEIリソースハブの今後の展開 本日のDEIリソースハブの立ち上げは、All In for Maintainersの始まりに過ぎません。この2年間、私たちがオープンソースコミュニティの将来のあり方について、経験や願望を共有するためにつながってきたメンテナーの方々の時間と声に敬意を表したものです。私たちは、DEIリソース・ハブが、コミュニティがすべての人を受け入れ、歓迎するために必要なリソースにアクセスするための手段を提供することを望んでいます。 DEIリソースハブの更新や、All In for Maintainersプログラムの次回の開始に関するアナウンスメントを、私たちのウェブサイトや リポジトリで引き続きチェックしてください。

GitHubの可用性レポート: 2023年1月

1月、私たちは2つのインシデントを経験しました。ひとつはGitHub PackagesとGitHub Pagesのパフォーマンスが低下するもので、もうひとつはgitユーザーに影響を与えるものでした。 1月30日 21:48 UTC (35分継続) 弊社のサービスモニターがGitHub PackagesとGitHub Pagesのパフォーマンス低下を検出しました。コンテナレジストリへのリクエストのほとんどが失敗し、一部のGitHub Pagesのビルドにも影響がありました。この現象はバックエンドの変更が原因であると判断し、その変更を元に戻すことで緩和されました。 この事象は最近発生したものであるため、現在その要因を調査中であり、来月のレポートでより詳細なアップデートを提供する予定です。 1月30日 18:35 UTC (7時間継続) 私たちは、アップストリームからの最新バージョンで、本番用Gitバイナリをアップグレードしました。この更新には、アーカイブを生成する際にgzipの内部実装を使用するように変更することが含まれていました。その結果、GitHub が提供する "Download Source" リンクの内容に微妙な変更が生じ、チェックサムの不一致が発生しました。コンテンツは変更されていません。 多くのコミュニティへの影響を認識した後、圧縮の変更をロールバックして以前の動作に戻しました。 上記と同様に、この事故の要因についても調査中であり、来月のレポートでより詳細な情報を提供する予定です。 状況の変化については、当社のステータスページでリアルタイムに更新していますので、ぜひご覧ください。私たちが取り組んでいることについてもっと知りたい方は、GitHub Engineering Blogをご覧ください。

オープンソースがもたらす、世界の1億人の開発者へのインパクト

オープンソースムーブメントは、私たちが生活や仕事に使用するすべてのテクノロジーを静かに支えています。オープンソースは、単なる技術やライセンス以上のものであり、誰もが世界をより良くするために貢献できる、参加と協力の文化を創造するものです。 オープンソースソフトウェアはGitHubよりずっと以前から存在していました。しかし今日、GitHubはオープンソースコミュニティの多くの人々が出会い、他の人々を刺激し、プロジェクトを成長させ、その仕事を評価される場所となっています。GitHubの開発者数が1億人を突破したことを発表したとき、開発者の定義がテクノロジー企業のためにソフトウェアを作る人たちだけでなく、どのように進化してきたかを見てきました。しかし、それだけではありません。オープンソースで働く、あるいはオープンソースで働くという旅も進化しています。今回は、GitHub でオープンソースプロジェクトのお気に入りのメンテナを紹介し、彼らの経験談を聞いてみたいと思います。 あるアイデアが軌道に乗る ある開発者の個人的なプロジェクトが GitHub 上で広がり、世界中の開発者に影響を与えたという話を聞くのはとても楽しいものです。PSSendGrid のメンテナであり GitHub のスターでもあるBarbara Forbes さんは、まさにこのような体験をしました。GitHub Universe で、彼女の話を聞いてみました。 私は日々の仕事をこなしながら、仕事で遭遇する問題に対して自分なりの解決策を考えていました。突然、人々がリポジトリにスターを追加し、イシューを作成していることを発見したのです。全く期待していなかったのに、本当に流行ったモジュールのひとつが、SendGrid APIに関するラッパーでした。これはもしかしたらみんな使えるかもしれない、だからこれをオンラインに置いておこうと思ったんです。そうしたら、なんと4万件もダウンロードされていたんです。 自分の趣味のプロジェクトが世界中の開発者に利用されていることもそうですが、開発者が自分のプロジェクトに貢献し、みんなのためにより良いものにしようと興奮していることも、また別の話です。この感覚は、プロジェクトを超えた何かを作り上げたとき、つまりコミュニティを作り上げたときに、特別なものとなります。オープンソースプロジェクトは、一人の開発者から、一緒に素晴らしいものを作ろうとする熱心なコミュニティへと急速に成長することができます。Vueのメンテナであるエヴァン・ユーの話を聞いてください。 ユーザー数が一定量に達したとき、Vueはコミュニティになりました。突然、貢献者、教育者、学生など、すべての人々が私を頼りにするようになったのです。Vueのコアメンバーは、本当に情熱を持って取り組んでいました。ユーザーが面白いものを作っている。Vueは、私が想像していた以上に大きな存在になりました。 他の人と一緒にメンテナンスする プロジェクトが成熟するにつれ、多くのメンテナは新しいリーダーや貢献者を受け入れる余裕を持つようになります。メンターシップ、ガバナンスの構築、ミートアップの開催など、持続可能なコミュニティとコードベースを構築するためには、目に見えない多くの作業が必要です。オープンソースでは、多様な人々との円滑なコラボレーションを可能にするために、ガバナンスが重要な鍵を握っています。ロリーナ・メサが、Python Software Foundation の理事会での経験の一部を紹介します。 オープンソースについて考えるとき、人々は技術的な要素に焦点を当てます。しかし、それはまた、コラボレーションについてです。このことを行うには村が必要です。 コードだけでなく、あらゆる種類のコントリビューションを募ることが、メンテナにとって重要なのです。ElectronのメンテナであるKeeley Hammondは、新しい貢献者、特に非技術的な貢献のためのスペースを作るためにどのように働いているかを話してくれました。 私たちは新しいコントリビューターを歓迎し、アクセスしやすくするために努力しています。しかしElectronは、たとえ経験豊富な開発者であっても、入り込むのに躊躇するコードベースです。私がプロジェクトに貢献しようとしたとき、最初は技術的な仕事ではなく、メンテナサミットの運営を手伝ったり、リリースノートを集めたり、ブログ記事を書いたりすることを志願していました。 報酬を得る 何千ものソフトウェア会社や組織が、オープンソースプロジェクトの拡張や保守のためにチームを作っています。MetaによるReactのメンテナンス、PickNikによるRobot Operating SystemのMoveItプロジェクトの運営、Quansight LabsによるNumPy、SciPy、scikit-learnでの作業はすべて、雇用と寄付を通じて基礎となるオープンソースプロジェクトに影響を与える組織の例となります。MetaのオープンソースプログラムオフィスのDmitry Vinnikから話を聞いてみましょう。 Meta は、Meta のオープンソース プロジェクトでさえも、すべてスケールについて考えています。毎年、私たちは1年分のレビューを発表しています。前回のレビューでは、800以上のアクティブなオープンソースリポジトリがありました。 他のプロジェクトは、GitHub Sponsorsのようなツールを使って、寄付によって維持することができます。GitHub Universeでは、CalibreのメンテナであるKovid Goyal氏に、オープンソースでフルタイムに働くためにスポンサーを得た経験について話を聞きました。 Calibreは、私が予想していたよりもずっと大きくなりました。寄付のボタンを設置したら、ピザよりも多くのお金をもらうようになりました...私は妻と話し合い、これをフルタイムでやっていこうと決めました。それ以来、ずっとうまくいっていますよ。 貢献し続ける オープンソースは、私たちのテクノロジーの世界の基礎的な岩盤であり続けるでしょう。オープンソースコミュニティーを発展させ、私たちが信頼するプロジェクトに恩返しをするのは、私たち全員にかかっているのです。私たちは、オープンソースのサポートを継続し、次の1億人の開発者（アーティスト、オーガナイザー、コーダーなど）にツールを提供できることに興奮しています。 最初の寄付をすることに興味がありますか？ オープンソースに貢献する方法」をご覧ください。 次に貢献できる最高のプロジェクトを見つけたいですか？ GitHub Explore をご覧ください。

未来へのスキルアップ: GitHub はどのようにオープンソースコミュニティにおける多様性、公平性、包括性を推進しているのか

GitHubの目標は、誰もが参加でき、有意義な貢献ができるプラットフォームを構築し、オープンソースコミュニティーを活性化させることです。ソフトウェア開発の未来は、オープンソース技術を通じて社会を発展させるために協力し合う、多様な経歴や経験を持つ素晴らしい人々で構成されるものです。 このような未来を実現するためには、まずスキリングから始めなければなりません。私たちは、学校、教師、学生が次のレベルの開発ツールを採用することを保証するだけでなく、技術への参入障壁を低くし、バックグラウンドに関係なく誰もが参加できるようにするため、総合的なスキリング戦略を推進しています。Global Campusや All In for Studentsなどのプログラムを通じて、GitHubは将来の開発者を育成するために、個人や組織にオープンソースやその貢献の仕方について学ぶトレーニングや教育の機会を提供しています。 この活動は、より多くの人々をオープンソースに引きつけるでしょうが、同時に、彼らを確実に惹きつけ続けることも必要です。私たちの最新のプログラムであるAll In for Maintainersは、オープンソースやGitHubに人々を紹介するとき、彼らが人生で最高の仕事をするために、温かく歓迎し、育成する環境で迎え入れることを確実にするために、プラットフォームの開発者たちと協力しています。 十分なサービスを受けていないコミュニティのためのスキルアップ GitHub Social Impactの目標の一つは、オープンソースにおける多様性、公平性、包括性（DEI）を推進することです。ソフトウェア開発の未来のために効果的なスキルを身につけるには、十分なサービスを受けていないコミュニティに存在するギャップを理解し、それに対処することから始める必要があります。GitHubは、今後3年間でオープンソースの分野で十分な経験を積んでいない人々から5,000人のスキルを身につけることを約束しました。私たちは、これらのコミュニティメンバーがデジタルの未来に従事し、成長する開発者エコシステムの一部となるために必要なテクノロジーとスキルにアクセスできるよう支援します。 私たちは、これを単独で行うことはありません。企業パートナー、非営利団体、大学、主要なステークホルダーと協力することで、スキルとリソースの間のギャップを埋めることができます。このコラボレーションによって、多様な視点、アイデア、経験に満ちたコミュニティに必要な公平なソリューションが生まれ、より多くのイノベーションと人類の進歩につながるのです。 GitHubでは多くのスキルアップの取り組みが行われていますが、今回は私のソーシャルインパクトチームが今年取り組んでいるいくつかの取り組みについて詳しく見ていきたいと思います。このプログラムは、オープンソースの多様性、公平性、包括性への取り組みの一環として、オープンソースコミュニティのパートナーと共に開発したものです。 All In for Maintainersの立ち上げ 2021年に実施したメインテナー・リスニング・ツアーで、私たちは、オープンソースコミュニティにおけるインクルージョンの文化を形成するのは、主にメインテナーとコミュニティリーダーであることを知りました。そこで私たちは、コミュニティにおけるインクルージョンを推進するために、リソースやトレーニング、直接的な技術支援を提供する包括的なプログラムの第一弾を、この2月に開始します。多様性とインクルージョンを推進するための提案のほとんどは、非常に手作業で手間がかかるというのが、メンテナの共通認識です。このプログラムでは、アクセシビリティ監査、コミュニティ・ホスピタリティ技術、行動規範分析、インクルーシブ言語スキャンなどの主要なプロセスを自動化するために、自由に利用できるツールを提供し、多様な背景を持つ貢献者の獲得と維持に役立つプログラミングを提供します。このコミュニティに対する今後の取り組みにご期待ください。 All In for Studentsの拡大 All In for Students は、オープンソースの教育、トレーニング、インターンシップの機会を提供する、多様なバックグラウンドを持つ技術系学生のためのオンラインプログラムです。私たちは、社会から疎外されたコミュニティ出身の将来の開発者たちが、アクセスするための障壁を低くし、成功へのオンランプと明確な道筋を提供することを目指します。また、コースのカリキュラムにおける不公平などのインフラの課題や、信頼できるインターネット接続の欠如やインターネットに接続するためのコストなどのアクセスに関する課題にも取り組んでいます。 昨年11月、2021年に試験的に開始したプログラムをより多くの学生に届けるため、どのように規模を拡大しているかについての最新情報をお伝えしましたが、すでに目標を達成していることをお知らせします！。現在までに、2023年のコホートには300人以上の学生がおり（2022年の卒業生30人から増加）、パートナー校も7校から、主に歴史的黒人大学、ヒスパニック支援機関、コミュニティカレッジなど90校近くまで増加しました。今後数カ月、学生たちはインターンシップの応募プロセスの真っただ中にあるため、私たちは次のことに重点を置いています。 経済の先行きが不透明な中で、学生がキャリアアップの機会を得られるように準備すること。これには、面接の準備、履歴書の詳細なレビュー、1対1の指導の機会などが含まれ、これらの学生がインターンシップを確保するために必要な自信を植え付けることができるようにすることです。 NASA、Red Hat、Microsoft などのパートナーとの仮想ハッカソンや地域ハッカソンを通じて、オープンソーススキリングの共同体験を提供します。 4月に開催される仮想卒業式で、コースのカリキュラムと要件を無事修了した学生の功績を称えます。今後数週間、LinkedInで私たちをフォローして詳細をご覧ください。 リソース All In for StudentsまたはAll In for Maintainersについてもっと知りたい方は、All Inウェブサイトをご覧ください。 また、非営利団体やソーシャルセクターが世界にポジティブで永続的な貢献をするための、その他のソーシャルインパクトプログラムもぜひご覧ください。 GitHubが次世代のデベロッパーを育成するためのツールやリソースなどをお探しの場合は、GitHub Educationをご覧ください。GitHub Global Campusでは、学生、教師、学校が次世代のソフトウェア開発に必要なツールにアクセスできるよう支援を行っています。

GitHub DesktopとAtomをご利用の方に必要な対応について

2022年12月7日、GitHubはGitHub DesktopおよびAtomの企画・開発で使用されている一連のリポジトリへの不正アクセスを検知しました。徹底的な調査の結果、この不正アクセスによるGitHub.comのサービスへのリスクはなく、これらのプロジェクトに不正な変更は加えられていないと結論付けました。 暗号化されたコード署名証明書一式が流出しましたが、この証明書はパスワードで保護されており、悪意を持って使用された形跡はありません。予防措置として、GitHub Desktop および Atom アプリケーションで使用されている公開された証明書を失効させます。これらの証明書を取り消すことにより、GitHub Desktop for MacおよびAtomの一部のバージョンが無効になります。 これらのバージョンのGitHub Desktop for Macは、2月2日に動作しなくなります。最新バージョンの Desktop にアップデートしてください。 3.1.2 3.1.1 3.1.0 3.0.8 3.0.7 3.0.6 3.0.5 3.0.4 3.0.3 3.0.2 GitHub Desktop for Windows への影響はございません。 これらのバージョンのAtomも2月2日に動作が停止します。Atom を使い続けるには、ユーザーは以前の Atom バージョンをダウンロードする必要があります。 1.63.1 1.63.0 何が起こったか 2022年12月6日、私たちのatom、desktop、およびその他の非推奨のGithub所有組織のリポジトリが、マシンアカウントに関連する漏洩したPAT (Personal Access Token)によってクローンされました。2022年12月7日に発見されると、当社チームは直ちに漏洩した認証情報を失効させ、顧客および内部システムへの潜在的な影響の調査を開始しました。影響を受けたリポジトリには、お客様のデータは含まれていませんでした。 しかし、これらのリポジトリには、当社のGitHub DesktopおよびAtomリリースのワークフローでActionを介して使用するための暗号化されたコードサイニング証明書が複数保管されていました。脅威者がこれらの証明書を解読または使用できたという証拠はありません。 証明書は、コードがリストされた作者によって作成されたことを確認するために使用され、GitHub上のコミットに署名するのと非常によく似ています。これらの証明書は、既存の Desktop および Atom アプリのインストールを危険にさらすものではありません。しかし、復号化されると、脅威者はこれらの証明書で非公式なアプリケーションに署名し、それらがGitHubによって公式に作成されたように装うことができるようになります。 2022年12月6日時点でも有効な証明書は、Windowsで使用されているDigicertコードサイニング証明書2枚と、Apple Developer ID証明書1枚の計3枚でした。GitHubは2023年2月2日に3つの証明書をすべて失効させる予定です。 1つのDigicert証明書は2023年1月4日に期限切れとなり、2つ目の証明書は2023年2月1日に期限切れとなる予定です。有効期限が切れると、これらの証明書はコードの署名に使用できなくなります。これらは継続的なリスクにはなりませんが、予防措置として、2月2日に失効させる予定です。 Apple Developer ID証明書は、2027年まで有効です。私たちはAppleと協力して、2月2日に証明書が失効されるまで、公開された証明書で署名された新しい実行ファイル（アプリケーションなど）がないか監視しています。 2023年1月4日、私たちはDesktopアプリの新バージョンを公開しました。このバージョンは、脅威者に公開されていない新しい証明書で署名されています。 GitHub.comへの影響 漏洩したリポジトリの内容を調査した結果、上記の特定の証明書以外、GitHub.comやその他の提供物への影響は認められませんでした。また、これらのリポジトリにあるコードに不正な変更は加えられていません。 ユーザー保護のためのGitHubの対応について 本日、Atom アプリ 1.63.0-1.63.1 の最新 2 バージョンをリリースページより削除しました。証明書が失効されると、これらのバージョンは機能しなくなります。以前のAtomリリースは、日没のガイダンスに従って ダウンロードすることができます。 2023年2月2日（木）に、Desktop app バージョン 3.

コンプライアンスの基盤整備

コンプライアンスは世界中にソフトウェアを届けるための基礎ですが、ポリシーの強制によってワークフローが遅くなることに開発者が不満を感じる場合もあるかもしれません。 セキュリティ、データ、プライバシーの要件や規制が異なる地域や企業間で世界中のソフトウェアを実行できるようにするのがコンプライアンスなので、私たちGitHubはビジネスのニーズと開発者の幸福のバランスをとることに精通しています。1億人の開発者とFortune 100の90%がGitHub上でソフトウェアを構築しているのですから。 ここでは、開発者が最高の仕事をするためのツールを提供し、かつビジネスのコンプライアンスニーズを満たす方法について深く掘り下げていきましょう。 コンプライアンスの定義 コンプライアンスを辞書で厳密に定義すると、「願望、要求、提案、方式に従うこと」「強制に従うこと」「公式の要件を満たすこと」に焦点が当てられます。 この定義から、柔軟性、開放性、コラボレーションを重視する開発コミュニティで、コンプライアンスがあまり議論されない理由がわかります。 より開発者やクラウドネイティブに優しい定義は、Office of Compliance(OoC) の記述に見ることができます。OoC は、コンプライアンスを "達成すべき望ましい結果一式と、本番環境に配備する前にシステムを検証する必要のあるプロセス" とみなしています。 理想的な状態とその状態に到達するためのプロセスを定義することは、公式の要件に従うよう強制されるよりもずっと良いように聞こえます。 コンプライアンスのための基礎固め コンプライアンスというと敷居が高いように思われるかもしれませんが、成功するためにまず理解しておくべき、非常に実践的な考え方があります。 母集団を把握する これは当たり前のことですが、コードがどこにあり、開発者が誰であるかを知らなければ、ソフトウェア開発のコンプライアンスニーズに対応できないことを明記しておきます。 コードがGitHubのようなプラットフォームで一元管理されている場合、この最初のコンセプトはカバーされているはずです。 もしコードを一元管理できるプラットフォームがない場合は、まず使用しているすべてのツールを見つけ、そのツールにアクセスできるすべての開発者のリストを取得する必要があります。 ご想像の通り、これは時間のかかる作業であり、母集団が完全である保証はありません。 アクセスの把握 母集団を理解したら、次に誰が何にアクセスできるかを理解する必要があります。 コードは、おそらく組織内で最も重要な情報の一部であり、開発者が安全に利用できるようにする必要があります。 CIAの三原則は、コードの安全性を確保し、必要な人だけがアクセスできるようにするための仕組みを提供します。 機密性：組織は、許可されたユーザーのみが情報にアクセスできるようにするための対策を制定する必要があります。 完全性：正確で信頼できるデータが重要であり、権限のないユーザーがアクセス、変更、またはその他の方法で干渉することを許可しない。 可用性：許可されたユーザーが必要な時に、信頼できる一貫したデータへのアクセスを保証すること。 GitHubは、個人や企業がコードへのアクセスをコントロールできるようにするために、すべてのリポジトリやその他のリソースにアクセス権限を設定し、各ユーザーが業務に必要なものだけにアクセスできるようにしています（最小権限の原則とも呼ばれる）。エンタープライズアカウントという概念は、GitHubのコアに組み込まれています。これにより、アクセスを総合的に管理し、既存のプロバイダーと統合してチームを同期させ、管理を容易にし、ガードレールを設定してエンジニアリングチームの安全な基盤を確保することができるようになります。 世界中の開発者のうち1億人がGitHubを利用しているため、個人と企業のすべての開発者が必要なときにいつでも利用できるようにします。コミュニティへのコミットメントとして、GitHubの可用性レポートを毎月公開し、必要なときにコードが利用可能であることを確認しています。 GitHub Enterprise のような中央のツールを使うことで、必要な管理のオーバーヘッドを減らすことができます。もし、現在のツール環境が複雑になりすぎていて、何か助けが必要な場合は、最近のブログポスト「ツールキットを統合するための3つのヒント」をご覧ください。 ユーザー認証 この段階では、コードがどこにあるか、ユーザーの人口、CIAの3要素に対処していることを確認するための管理方法を理解しています。次に、ユーザーが持つアクセス権を定期的に証明するプロセスを導入する必要があります。従業員が別の役割に移ったり、会社を辞めたりした場合、そのアクセスを確実に取り消すためのプロセスを導入する必要があります。 今後のブログでは、GitHub Actions による自動化と、プルリクエストによる開発者のワークフローを活用して、ユーザーの認証に関連するコンプライアンスを最適化する方法について説明します。 継続的なコンプライアンス 継続的インテグレーション（CI）/継続的デリバリー（CD）という言葉は誰もが知っていると思いますが、何かを継続的に行うというコンセプトは、コンプライアンスにも適用できます。CI/CDの大きなメリットの1つはスピードです。コンプライアンステストや監査が、DevOpsのCI/CDパイプラインのように高速でシームレスに行われる世界を想像してみてください。 継続的なコンプライアンスは一晩で魔法のように現れるわけではありませんが、コンプライアンスの基礎となる部分を理解し、その下準備を始めていれば、コンプライアンスのテストと監査をより速くするいくつかの大きな利点が得られます。 1.不意打ちを食らわない。 コンプライアンス・テストや監査が始まるときに起こりうる最悪のシナリオの1つは、驚かされたり、準備不足になったりすることです。テスト担当者や監査担当者が新しい成果物を要求してきたからと言って、新しい成果物を作成する必要はありません。 2.共通の理解 DevOps監査防御ツールキットの主な目標は、コミュニケーションを改善し、共通の理解を生み出し、"IT管理者と実務者を監査プロセスについて教育し、監査人に対して、ビジネスリスクを理解し、そのリスクを適切に軽減していることを証明できるようにする "ことでした。ITと監査人のコミュニケーションと情報共有が改善されれば、監査がより効率的になり、Forresterによれば、大幅なコスト削減が可能になります。 3.開発者のワークフローに組み込まれる。 ソフトウェアデリバリーライフサイクルの基礎からコンプライアンスが設計されている場合、開発者は日々のフローの一部として、必要なコントロールを満たし、成果物を収集することになります。 AIで実現するコンプライアンス GitHubでは、すでに機械学習を活用して、セキュリティやコンプライアンスに重要なセキュリティ脆弱性を発見するための支援を行っています。製造業では、 監査や工程検査の支援にAIが採用され始めています。また、ガートナーは、銀行が 詐欺の検出やリスクのモデリングに近々活用する技術として、ジェネレーティブAIを挙げています。 AIや機械学習を継続的なコンプライアンスに活用することのメリットと可能性は、非常に魅力的です。今後のブログでは、その先にあるものを詳しく見ていきたいと思います。 次のステップ このようなコンプライアンスの基礎的な側面がよく理解できたら、これらのコンセプトを実装するための次のステップについて考え始めることができます。これが難しいところです。次回の記事では、開発者を満足させながらコンプライアンスの必要性を満たす、いくつかの実用的な方法を紹介します。 安全性とコンプライアンスを保ちつつ、開発者の作業効率を上げるにはどうしたらいいでしょうか?GitHub Enterprise がどのように役立つかを見てみましょう。

開発者数1億人突破

なぜなら、より多くの開発者が一つの場所に集まることで、信じられないようなことが起こるからです。 今日、GitHubを利用してソフトウェアプロジェクトを構築、保守、貢献する開発者が正式に1億人を超えたことをお伝えできることを嬉しく思います。 これは予定より2年早く達成しただけでなく、GitHubが開発者を第一に考え続けるという大きな責任を表しています。 新しい開発者コミュニティ 2007年10月に最初のコードがGitHubにコミットされたとき、人々は開発者とは誰か、そのバックグラウンドや仕事について、かなり確固としたイメージを持っていました。 今日、開発者はもはやテクノロジー企業でソフトウェアを作っているだけの人たちではありません。空いた時間にコードやデザイン、ドキュメントをいじり、オープンソースプロジェクトに貢献し、科学的研究を行うなど、業界の枠を超えて働く、ますます多様でグローバルなグループなのです。 2015年、GitHub上の開発者のほぼ3分の1は北米出身者でした。現在、最も急成長している地域のいくつかは、東南アジア、アフリカ、南米など、米国から遠く離れた場所にあります。インドだけでも、1000万人以上の開発者がGitHubを利用してソフトウェアを作っています。そしてブラジルでは、300万人以上の新しい開発者がGitHubを利用しています。 このようなグローバルな意見交換は、開発者が誰で、何に取り組み、どこに住んでいるのかを民主化するのに役立っています。今日の開発者は、コードをコミットし、ドキュメントを提供し、新しい問題を解決するために新しいソリューションをグローバルなレベルで構築しています。彼らは、病院、映画制作、NASA、そしてAIや機械学習アプリケーションを強化するPyTorchプロジェクトのためのソフトウェアを構築するために、世界中で働いている人たちです。また、大切な人のコミュニケーションや 家族の病気克服の手助けをしたいと考える人たちでもあります。 すべての開発者のための家づくり これだけ責任が重くなると、もはや開発者がより多くのことをできるようにツールを装備するだけでは済まなくなります。開発者が最高の仕事をするために必要なものをすべて提供する必要があるのです。 GitHubはすべてのデベロッパーの家です。これが私たちのビジョンです。プルリクエストの作成から、GitHub Copilotを通じたAIによる開発者の支援まで、私たちが行うことはすべて開発者を第一に考えることです。そして、それはまだ始まりに過ぎません。GitHub Nextで、私たちの研究開発チームは、ソフトウェア開発の未来を調査しています。Code Brushから Hey, GitHub！まで、GitHub NextはGitHubがすべての開発者のためのホームであることを確実にするために極めて重要な役割を担ってきました。 1億人を超える開発者のホームとして、私たちはより多くの新しい開発者をテクノロジーに引き込み、人々が協力して次の素晴らしいものを作り、人類の進歩を加速させ、まだ解明されていない問題を解決できるよう支援する責任を真剣に受け止めています。なぜなら、より多くの開発者が協力し合い、彼らがベストを尽くすために必要なものをすべて手に入れることができれば、誰にとっても素晴らしいことが起きるからです。 さあ、ここから一緒に作り上げましょう。

GitHub Bug Bountyスワッグストアの紹介

バグバウンティチームは、プログラム開始8年目を迎え、6月にはライブハッキングイベントを開催し、サイバーセキュリティ啓発月間にハッカーの一人にスポットライトを当て、DEFCON 30などのイベントでコミュニティとより長い時間を過ごすなど、刺激的な1年を過ごすことができました。また、DEFCON 30などのイベントにも参加しました。このたび、プログラム参加者の皆様からいただいたご意見をもとに、独自のスワッグストアを開設することになりました。 このスワッグストアは、バグバウンティプログラムの継続的な改善に関する多くの会話やフィードバックから生まれました。その結果、研究者はスワッグを受け取ることを純粋に楽しんでいるだけでなく、私たちのバウンティプログラムに参加していることをアピールすることも好きだということがわかりました。 新しいGitHub Bug Bounty swag storeでは、バグバウンティの報酬のボーナス特典として、バグバウンティ・ブランドの限定スワッグを獲得することができるようになります。レポートを通じて、研究者はTシャツ、スウェットシャツ、ステッカー、その他のクールなアイテムと交換できるポイントを受け取ることができます。新しいストアに関する情報は、バウンティストアのFAQをご覧ください。 バグバウンティプログラムの成功には、コミュニティ内の優秀なセキュリティ研究者との連携が欠かせません。皆様からのご投稿は、当社製品、ユーザー、コミュニティの安全性とセキュリティを確保するために非常に重要であり、大きな影響力を持ちます。プログラムの範囲、ルール、報酬の詳細については、当社のウェブサイトをご覧ください。ハッピーハッキング

Yout amicus: デベロッパーのイノベーションの権利を守るために戦います

Published at February 13, 2023
Category: Policy
Author: Kevin Xu

Summary

開発者のコラボレーションを通じて人類の進歩を加速させるという使命のもと、私たちは開発者のイノベーションの権利を不必要に損なうような法的展開に対して、時折、闘う必要があります。そのため、GitHubはYout LLC v. Recording Industry of America, Inc.の控訴審において、アミカスブリーフ (第三者意見募集)を提出しました。。

開発者のコラボレーションを通じて人類の進歩を加速させるという私たちの使命から、開発者のイノベーションの権利を不必要に損なうような法的展開に対して、時折、闘うことが必要です。そのため、GitHubは以下の訴えにアミカスブリーフ(第三者意見募集)を提出しました。 Yout LLC v. Recording Industry of America, Inc..

この訴訟はどのようなものですか？

この訴訟は、Youtという会社が、youtube-dlの設定されたバージョンを使って、ユーザーがYouTubeのビデオをダウンロードするのを助けるオンラインサービスを提供している、というものです。このブログの長年の読者は、私たちがyoutube-dl ソフトウェアに対する削除要請を処理したことを覚えているかもしれません。この決定は、開発者コミュニティからの幅広いフィードバックに耳を傾け、またyoutube-dl の動作に関する新しい事実を認識した後、覆されました。このような経験から、私たちは法律の範囲内で最も開発者に優しいアプローチをとるために、DMCAプロセスのオーバーホールと重要な投資を行うことになりました。

GitHubにとってこの事件の核心は、連邦地裁がDMCAの第1201条（a）項にある、著作物のアクセス制御を回避することを禁じる規定に違反したと認定したことです。しかし、YouTubeの動画は一般に公開されているのに、どうしてそんなことが可能なのでしょうか。連邦地裁は、ダウンロードボタンがないことは、著作物へのアクセスを防止する有効な技術的保護手段であるとし、通常の利用者はYouTube動画をダウンロードできないことを理由としたのです。我々のアミカス(第三者意見募集)は、この理屈は法的に間違っており、開発者のイノベーションを脅かすものであると控訴審に訴えています。

1201条(a)は何を対象とするのか？

DMCA第1201条(a)は、著作物へのアクセスを効果的に制御する「技術的手段」の回避を禁止しています。違反者は、初犯の場合、最高50万ドルの罰金と5年の禁固刑に処される可能性があります。

私たちは、テイクダウン要求を審査した経験から、1201事件の処理が困難であることを知っています。また、この法律は、新たな技術の進歩を考慮し、意図的に幅広い表現で書かれています。私たちのプロセスは、技術的なレビューの要素を含んでいます。このような複雑さを考えると、当事者や裁判官、そして愛されているオンライン開発者コラボレーションプラットフォーム（上記参照）であっても、時に誤った判断を下すことがあるのは理解できます。私たちは皆、そのような経験をしてきました。しかし、インターネット上で間違った判断をすることの素晴らしい点の1つは、世界中の人々が問題やバグレポートを提出し、どこが間違っていたのかを教えてくれることです。驚くべきことに、米国の控訴審の判例も同じです1.

私たちが裁判所に伝えたこと

連邦地裁の判決の主な問題点は、以下の点を混同していることです。 作品へのアクセスと作品の使用を混同していることです。YouTubeの動画はURLで公にアクセスできるため、youtube-dlのようなツールを使ってダウンロードできるかどうかは、もはや1201(a)の問題ではありません。その代わり、裁判所は、この使用が、フェアユースを含む著作権の許容する使用の範囲内にあるかどうかを分析する必要があります。しかし、裁判所は、ダウンロードボタンがないことを1201(a)の「効果的な技術的保護手段」であると判断したため、フェアユースの例外は適用されない。

私たちのアミカスブリーフでは、裁判所の「ダウンロードボタンがない」という分析が、広く許容され有益であると考えられている以下のような無数の他のソフトウェアツールを脅かすものであるため、法的には健全ではないことを説明しています。

  • 広告ブロッカー
  • スクリーン・リーダー
  • ウェブアーカイバー（youtube-dl自体が、「人権のための闘いにおける証拠の保存」など、ビデオファイルを保存するためのアーカイブ目的で一般的に使用されていることに注目）
  • 以下のようなブラウザの拡張機能。
    • ウェブページのダークモードを有効にする
    • ウェブページを他の言語に翻訳する
    • Webページのフォントを失読症の方にも読みやすいものに変更する。
    • ウェブページの印刷レイアウトを改善する
  • カスタムメディアプレーヤー

1201(a)は、その表面上、暗号化ベースのDRM手段のようなアクセス制御をカバーしていますが、今日のインターネット体験を支える最も広くインストールされているブラウザ拡張機能、スクリーンリーダー、Webアーカイバ、その他の重要なツールの多くを犯罪とする可能性がある一方で、人々が利用できるコンテンツをどう体験するかに単に影響を与える手段をカバーすべきではないのです。最高裁がVan Buren v. United Statesにおいて Computer Fraud and Abuse Act（CFAA）の文脈で指摘したように、そうでなければ法を遵守する何百万人もの市民を犯罪者に変えてしまう解釈は懐疑的に扱われるべきなのです。2今回の連邦地裁の1201(a)の解釈の場合も同様です。

さらに、人々が利用可能なコンテンツを体験する方法を改善する努力を犯罪化することは、まさにイノベーションの核心を突いています。DMCAが最初に法律として署名された25年前、ウェブ上でコンテンツを体験する普通のコースは、人類に知られる最も心地よい音を聞き、他の誰もその電話を使おうとしないことを願うというものだった。1998年以来、開発者は、私たちが利用可能なコンテンツを体験する方法を改善するために、無数のイノベーションを生み出し、当時の法律家が考えもしなかった方法で、創造性とインタラクティブ性を可能にしてきました。

開発者は、罰金や投獄を恐れることなく、有益な新技術をいじり、実験し、開発する自由を保証される必要があります。もし裁判所が、Yout裁判所の論理のように、1201(a)の範囲を拡大してそのようなイノベーションをカバーするならば、好奇心を冷やすことによって人類の進歩を後退させる危険性があります。

私たちの主張の全文は、アミカスブリーフをお読みください。

GitHubは開発者のイノベーションの権利の保護に努めており、これらの権利を脅かす可能性のある重要な裁判にアミカスとして参画しています。最近の例としては、230条を分析した最高裁の裁判におけるアミカスブリーフをご覧ください。ここでは、アルゴリズムに関する開発者の革新を可能にし、それらの革新をホストするGitHubのようなプラットフォームを保護するために230条の重要性を強調しています。

備考

  1. 当事者または裁判所の同意が必要ですが、最近同意の要件が削除された最高裁の場合を除きます。
  2. 「もし、"許可されたアクセスを超える "という条項がコンピュータ使用に関するポリシーに対する全ての違反を犯罪とするならば、何百万人もの遵法市民が犯罪者ということになります。Van Buren v. United States, 141 S. Ct. 1648, 1661 (2021).

Source

  Yout amicus: fighting for developers’ right to innovate

Our mission to accelerate human progress through developer collaboration requires us, from time to time, to fight against legal developments that would needlessly impair developers’ right to innovate. That’s why GitHub has filed an amicus brief in the appeal of Yout LLC v. Recording Industry of …

Comments