オープンソース・レジスタンス：勤務時間中にオープンソースを守ろう

 (ossresistance.com)
6 ポイント 投稿者 GN⁺ 2026-05-15 | 2件のコメント | WhatsAppで共有
  • Open Source Resistance は、企業が依存しているオープンソースソフトウェアの保守を、勤務時間内に静かに、プロフェッショナルに行おうという直接行動の宣言文（マニフェスト）
  • すべての企業がオープンソースなしでは事業を運営できないにもかかわらず、メンテナーに別途の許可や寄付ボタン、金曜午後の時間を乞わせる構造を拒否
  • これまでも Open Source Pledge（開発者1人あたり年額 US$2,000 の支払いを要請）や Open Source Friday（毎週金曜に最低2時間の貢献）といった代替案は存在したが、より直接的な実行を掲げる
  • 「時間の窃盗だ」という反論には、企業はすでに無料の OSS 補助金を受け取ってきており、依存している OSS の保守は共有インフラの作業だと答えられる
  • 雇用契約書の IP 譲渡条項 を必ず確認し、オープンソースのカーブアウトを文書で交渉すべき

マニフェスト：すでに必要な仕事を直すのに許可を求めるな

  • Open Source Resistance は、会社が依存している オープンソースソフトウェア（OSS） の保守を夜間や週末の趣味に追いやるのではなく、静かに、プロフェッショナルに勤務時間中に行おうという直接行動の提案
  • オープンソースソフトウェアは余暇時間の「趣味」ではなく、企業は毎時間オープンソースから価値を引き出している一方で、メンテナーには金曜午後を一度、寄付ボタンひとつ、全社会議での感謝の言葉程度しか提供しない
  • メンテナーは企業内部で、会社がすでに依存している OSS コードに対する作業を、書類作成、社内プログラム、管理者の承認なしに勤務時間中に行うべき
  • これは新しい発想ではなく、ほとんどのオープンソースがこれまで常に成立してきたやり方を公然と口にすること
  • メンテナーたちは会議やスプリント、プロダクトマネージャーの許可を待たずにインターネットを支えてきた

中核となる行動原則

  • 自分を守ること

    • 雇用契約書を確認し、機密情報は社内に留め、自分が公開するオープンソース IP の所有権を確保する必要がある

  • 作業を行うこと

    • PR レビュー、依存関係の更新、すでに OSS である部分のバグ修正を実行する

  • 無謀にならないこと

    • 勤務時間の 100% を OSS に使って解雇されたあと他人のせいにするのは禁止、鍵はバランス

既存の代替案

  • Open Source Pledge: 企業にメンテナーへの支払いを要請（開発者1人あたり年額 US$2,000）
  • Open Source Friday: 企業に時間の寄付を要請（毎週金曜に最低2時間）
  • 雇用主を先に説得する**丁寧なルート**も存在し、どれも前向きで支援する価値がある
  • Open Source Resistance はこの流れの次の段階として、依存関係チェーンの保守は管理者が名付けていなくてもすでに仕事の一部だと宣言する
  • 会社の予算配分は自分の管理範囲外でも、自分の勤務時間の使い方は管理できる

想定される反論と回答

  • 「時間の盗みだ / 株主に対する窃盗だ」

    • 企業はすでに毎日オープンソースメンテナーから価値を引き出しており、株主は何十年にもわたり無料のオープンソース補助金を受けてきた
    • 雇用主が OSS に依存しているなら、それを保守することは公共インフラの作業であって窃盗ではない

  • 「許可を求めるべきだ」

    • 許可の申請は権力の不均衡を維持する行為
    • 雇用主がすでに依存しているインフラを保守するのに管理者の祝福は不要

  • 「quiet quitting と同じだ」

    • quiet quitting は仕事量を減らすが、これはインターネットを成り立たせているOSS インフラを生み出す行為
    • 問題は作業そのものではなく、企業がそれを業務として分類することを拒んでいる点にある

  • 「良い雇用主まで被害を受ける」

    • 良い雇用主は勤務時間内のオープンソース保守を許可し、メンテナーに資金を提供したり、Open Source Pledge に参加したりすることでこの問題を回避できる

Mike McQuaid の経験

  • Open Source Friday と GitHub Sponsors の共同創設者であり、Homebrew プロジェクトのリーダー（2009年からメンテナー）
  • どの職場でも Homebrew のようなオープンソースプロジェクトへの作業が主業務として給与支払いの対象になったことはない
  • それでもすべての雇用主のもとでそれを行い、IP 契約を交渉して合法化し、仕事上の約束も果たしてきた
  • 子どもを持って以降、オープンソース作業の 90% 以上が勤務時間中に行われている
  • Open Source Maintainers Owe You Nothing で述べているように、ある会社のビジネスモデルが自分のコードに依存しているからといって、誰にも保守者の無償の夜間・週末・家族時間を要求する権利はないという立場

注意事項と法的告知

  • 法律上の助言ではない

    • これは法律上の助言ではなく、契約・雇用主・在留資格・ライセンス義務・個別事情に関する助言でもないと明記している
    • リスクが大きい場合は、行動する前に有資格者へ相談すべき
    • 大半のオープンソースライセンス と同様に、いかなる保証もなく、「現状のまま」提供される

  • 契約、ポリシー、所有権

    • 雇用契約、ハンドブックのポリシー、発明譲渡条項は、雇用中に作成された成果物、雇用主の機器で作られた成果物、担当業務の範囲内にある成果物について権利を主張できる場合がある
    • 一部の州では、私的時間と私的機器で作られた成果物に対するこうした権利主張を制限しているが、詳細が重要
    • 実行する前に雇用契約を読み、公開しようとしているオープンソース IP を雇用主が所有していないことを確認すべき
    • デバイス、ネットワーク、アカウントによって所有権リスクが変わるなら、自分のものを使うべき

  • IP 契約の交渉

    • IP 譲渡はしばしば交渉可能であり、内定を受けた際には署名前にオープンソース例外条項を書面で求めるよう勧めている
    • まず 従業員 IP 契約 を読んで、どの部分に異議を唱えるべきかを知る必要がある
    • Mike McQuaid はほぼすべての雇用主と、標準契約から外れる変更を交渉してきたが、反発はたいてい予想よりはるかに小さかったと述べている
    • GitHub の Balanced Employee IP Agreement を将来の雇用主に見せることができる
    • この契約は CC0 でオープンソース化されており、大手上場企業でも実際に使われていて、雇用主は対価を払ったものを保持し、従業員は事業と競合しないオープンソース作業を保持できるよう設計されている

  • 機密保持とセキュリティ

    • 非公開リポジトリ、認証情報、インシデント、顧客データ、ロードマップ、未公表の脆弱性、社内議論を公開してはならない
    • セキュリティ統制を迂回したり、許可されていないアクセス権を使ったりしてはならない
    • 直接行動とは会社の機密情報を公開する口実ではなく、公開作業を公開のまま保ち、営業秘密とは明確に分離すること

  • 静かであることは不注意を意味しない

    • ポリシー、契約、顧客義務、安全規則がリスクを変える場合には、自分で判断する必要がある
    • 自分の機器、アカウント、ネットワークで作業しなければならない場合もある
    • 会社から「盗む」のではなく、会社がオープンソースから受け取るものと、自分が与えられるものとのバランスを取ること
    • 同僚より低い人事評価を受けるかもしれないが、持続可能な B 評価のほうが、明日にでも解雇できる会社でA 評価のために人生をすり減らすより健全

  • 適用の限界

    • 時間が特定顧客、助成金、政府機関、防衛プロジェクト、規制環境に請求される場合、この主張は最も弱くなる
    • 不利益に耐えられるだけの影響力がないジュニアまたは不安定なエンジニアに対しても最も弱い
    • 雇用主がすでに使っている公開依存関係を修正するシニアメンテナーに対して最も強い
    • 最もすっきりした形は「勤務時間中にやりたいことをやれ」ではなく、オープンソース保守をエンジニアリング業務の一部として扱うこと
    • すでに保守しているプロジェクトを保守し、仕事が触れている共有ツールを改善し、無関係な仕事・プロプライエタリコード・現実の約束を取りこぼす原因になることは避けるべき

出典とプロジェクト

関連記事

2件のコメント

 
roxie 23 일 전

総合的に見ると、、、レジスタンスという表現が適切なようです
 
GN⁺ 2026-05-15
Hacker Newsのコメント

  • 企業が特定のオープンソースプロジェクトへの貢献について包括的な許可を出しているケースは、全体としてかなり多かった。
    言い方が重要だ。「気分よくなるために少し慈善活動をしてもいいですか？」ではなく、「この分野の専門家たちから無料で厳格なレビューを受け、修正をアップストリームのオープンソースプロジェクトに反映して、会社の将来の保守コストをなくしてもいいですか？」と言うべきだ。
    実際、それが本質であり、そう言って断られた雇用主はいなかった。会社の利益に完全に合致するので、それが見えるように手助けすればいい

    • 前の職場を解雇されたのは色々な意味で残念だが、大きな理由の一つは、自分がKafka Streamsライブラリに加えたかなり大きな変更をオープンソースとして公開するかどうかを議論していたからだ。
      APIの大部分は互換性を保ったまま多くを書き直し、必要であればバックプレッシャーのセマンティクスを使えるような、非ブロッキングI/Oを重視する方向だった。ステートストアとブロッキング／ノンブロッキングI/Oを混在させつつもかなりの性能を維持でき、面白いことが色々可能になったし、目立たない多くの箇所で性能を引き出したプロジェクトだったので特に誇りに思っていた。
      GitHubで公開するか、アップストリームのKafka StreamsプロジェクトにPRを送らせてほしいと強く求めていたが、その前にレイオフがあり、その後はその仕事を後押ししてくれるチャンピオンがいなくなって、独占コードとして閉じ込められてしまった。
      今でも、最初から作り直して自由なオープンソースとして公開しようかと考えている。かなり時間も経ったので、書き直して公開しても問題ない気がするし、特許のようなものもなく、Vert.x依存をなくすなど変えたい点もある。いつか1週間ほど休めたらやるかもしれない
    • こういうことを許してくれる場所で働いていた頃が懐かしい。
      会社によっては、法務レビューの手続きだけで話がこんがらがる。
      あるとき、あるプロジェクトにパッチを送ってよいか許可を求めたところ、興味深いメールスレッドが続いた。結局のところ質問は一つだけだった。顧客に請求される時間内に、納品物のバグを直すために書いたパッチであり、パッチ済みライブラリを再コンパイルしてソースコードと一緒に納品しなければならず、契約書には製品に関するあらゆる成果物と知的財産権が顧客に移転すると書かれているなら、そのパッチをパブリックドメインとして公開する権利は我々にあるのか、ということだ。
      法務チームは答えたがらなかった
    • おおむね良いアプローチで、仕事をプロフェッショナルにフレーミングする優れた例だと思う。ただし、問題の核心は解決していない。特にエンジニアリング中心の会社のリーダーシップなら、こうした利点は即座に理解すべきで、そうでないならそれ自体が問題だ。
      どんな形で進められるかは、雇用主の運にもかなり左右される
    • 「了解です、これをコンプライアンスチームに回してみます。知的財産権の侵害がないか確認したいだけなので。具体的にどのリポジトリとイシューですか？」

  • 「そして配布するオープンソースの知的財産権を確実に所有せよ」という話については、自分が働いてきた法域では、勤務時間中に書いて配布するコードは自分ではなく雇用主の所有だった。
    勤務時間中に貢献するかどうかを自分一人で決めることはできず、オープンソースコードに取り組むには正式な合意が必要だった。依頼のたびに法務部門を通すのに何か月もかかり、結局あきらめたり、その間に別のコントリビューターがすでにPRを出していて、もう依頼しなくなったりした

    • おそらく「自分のものではない成果物を勝手に寄付しようとしてはいけない」という意味だったのだと思う。下に関連セクションはあるが、上の箇条書きだけ見ると混乱する。
      経験豊富な開発者には自明なことだが、いくつかの会社のジュニア開発者にとっては実際に問題になっていた。会社が内部プロジェクトで何かクールなことをしていると、それをどこかのオープンソースプロジェクトに貢献すればよいと考えつつ、非公開コードの知識を使って実質的に似たコードを提出したり、時にはコピー＆ペーストしたりする問題が起きることを考慮していない
    • 自分で調べたわけではないが、ドイツでは基本的に勤務時間中に作ったすべてのソースコードは雇用主の所有だと理解していた。
      IT中心でない雇用主の大半は、オープンソースが何か、どう機能するのかすら理解していないだろう。だから多くの人から許可を取るのは絶望的になり得る。
      リンク先のサイトは、まず雇用主に向けてオープンソースの利点を説明し、雇用主向けの法的ガイドラインを提唱することに重点を置いたほうがよいと思う
    • 会社がプロダクションに入る部分を除いて寛容ライセンスのコードとして公開しないのなら、そういう職場には行かないと思う。自分にとってはやる気を削がれるし、精神的に限界まで追い込まれそうだ。むしろ貧しいほうを選ぶ

  • 良い考えだし、むしろ素晴らしい考えですらあるが、これを抵抗として位置づけるのが良いかどうかは分からない。
    職務の目的は通常、何らかの目標を達成することだ。その目標をどう達成するかは、専門家である開発者が決められるはずだ。その判断にオープンソースソフトウェアが含まれるなら、それを保守することもその判断の一部であるべきだ。
    急進的な話ではなく、自分の仕事に依存しているものの将来の安定性と保守性を守りながら仕事をしているだけだ

    • これは単に優れたビジネス感覚でもある。オープンソースを通じた協業を奨励する会社は、自社の事業を支えるエコシステムを育てていることになる
    • 言っていることにはすべて同意するが、最近の多くのテック企業の現実は、自分が経験した限りでは違う。強制されない限り、自分たちのインフラやライブラリの保守にすら時間を投資しないのに、ましてオープンソースとなるとさらに難しい。
      指標ゲームのための無意味な機能、enshittification、ダークパターン、マルウェアすれすれの流行りの統合などが、基盤インフラやライブラリへの投資より優先される
    • 同意する。こういう描き方は、誰かがソーシャルメディアでもっと注目を集めようとしているように見えてしまう。何もかも誇張しなければならない地点まで来てしまったのは残念だ

  • 総論としては全面的に賛成だが、実際にやり遂げるのは厄介だと思う。弁護士ではないが、一般に知的財産権は雇用主が所有するので、オープンソースとして公開するには明示的な許可が必要だと理解している。
    そしてその許可を得るプロセスは、しばしば難しく、果てしない手続きと法務部門を経なければならない。
    「米国、英国および複数の法域では、従業員が職務の一部として著作物を作成した場合、雇用主が法的著作者または最初の著作権者とみなされる」
    https://en.wikipedia.org/wiki/Work_for_hire
    それでも、オープンソースの仕事、つまり保守と開発は、寄付を乞うボランティアではなく給与を受け取るプロが担うべきだと思う。核心的な問いは、それをどう実現するか、そして企業にオープンソースへの貢献を個別交渉が必要な例外ではなく標準的な慣行として受け入れさせる方法だ

    • 説明されている問題は、「実務上の問題」というより理論上の問題に近い。
      実際には、ただやればいい。コンピュータの中にgit pushを止めるサブルーチンはない。現実には雇用主は雇用契約書にあれこれ書き込む。あらゆる方向から責任を回避しようとして、できるだけ多く盛り込む。向こうが好き勝手に書けるなら、なぜこちらはただやってはいけないのか。何も重要ではない。
      実際、こうした技術的理由で知的財産権を争われたオープンソースプロジェクトは、ほぼゼロに近い
    • その作業が職務に関連しているなら、知的財産権を雇用主が持つというのは正しい。
      職務と無関係なら州によって異なる。多くの州では、雇用主が自社の知的財産だと主張できる範囲に制限がある。一般的な契約書は文言を広く取り、あらゆるものを主張しようとするが、法律はしばしば、雇用主と無関係な自由時間の作業まで会社が取得することはできないとしている。
      勤務時間中に行ったり会社のノートPCを使ったりすると、会社が権利を主張する余地が生まれる。多くの会社は気にしないだろうが、争いになったときにきれいにしておきたいなら油断してはいけない。
      個人の時間、個人の機材で作業し、雇われた業務や会社で接したものと重ならないようにすべきだ
    • 弁護士ではないが、同僚に試してもらうためにコピーを渡したなら、それ自体ですでにオープンソースライセンスを使ったことになるのではないかと思う。その同僚はライセンスが与える法的権利を持ち、変更を再配布する権利も持つのではないか？
      変更をアップストリームに載せることこそが保守を保証する最善の方法なのに、これ全体がとても滑稽に見える。内部の独占フォークを維持することに伴う法的な不確実性も同様だ
    • この記事は最も抵抗の少ない道をたどれと提案しているように見える。会社の時間で作業し、大きな波風は立てないことだ。見つかったら許しを請えばよい。会社にとっては、許すほうが楽な道だ。弁護士を引き込めばコストは非常に大きくなり、広報上の悪夢になるかもしれない
    • 現在のプログラミングの状態が示しているものがあるとすれば、知的財産権と著作権法はもはや存在しないということだ

  • かなり大きな会社で働いている。うちの会社のオープンソースポリシーは、おおむね「まずマネージャーに相談すること、会社名義でやらないこと、機密情報を公開しないこと」に要約できる。
    問題になったことはなく、大枠では完全に合理的だと感じる

  • 勤務時間中にサードパーティのオープンソースプロジェクトへバグ修正のような貢献をするのは問題ないと思うが、自分のオープンソースをどう扱うべきかは分からない。
    たとえば個人的に作った小さなライブラリがあり、それを会社で使っていて、勤務時間中にバグを見つけたとする。その勤務時間中に貢献するとグレーゾーンになりそうだ。
    面接中にこういうことを交渉したことがある人はいるだろうか？ どうやったのか気になる

    • 実際にこれを気にする会社で働いたことはない。ただ必要なことをやっていた。「正しく」やるにはどうすればいいのかと聞いても、答えをもらえたことはなかった

  • 大企業で働いていたときは、だいたいの場合、会社のコードベースに直接コードを書く以外の作業依頼については、根拠を示しても直属のマネージャーから「自由時間にやれ」と返されていた。
    利益志向の環境では、即時の価値だけが追求に値すると見なされる。そうした態度はかなり寄生的であり、上から降ってくるさらなる効率化と指標競争がそれを生み出している

  • 業務上の問題を解決するためにフォークして修正し、その結果をアップストリームにPRとして送ったことは確かにある。
    それは、オープンソースを使えてアクセスできることの良い点の一つだ。package.jsonやcargo.tomlでgitがほぼ第一級の選択肢になっている理由もここにある。変更がアップストリームに入るまで、フォークを直接指せるからだ

  • シニアになると、面接プロセスで「何か質問はありますか？」という段階に来たとき、「この会社が依存しているオープンソースプロジェクトに、私の時間の一部を使って貢献することについて、どのような立場ですか？」と尋ねる。
    その答えを見て、その先に進むかどうかを決めればいい