ハクソク

世界を動かす技術を、日本語で。

オープンソースの抵抗：企業の時間内にOSSを維持する

2026年5月14日原文(ossresistance.com)

概要

  • OSS（オープンソースソフトウェア） は企業に不可欠なインフラ
  • OSS保守は業務時間中に行うべき で、許可を求める必要はない
  • 雇用契約やIP管理の注意点 を押さえることが重要
  • バランス感覚を持って行動 し、無理は禁物
  • 法的リスクや職場状況 によって判断を変える柔軟性が必要

許可を求めず必要なことをやる宣言

  • OSSは「趣味」ではなく企業の基盤インフラ
    • すべての企業がOSSに依存
    • 企業はOSSから利益を得ている
  • OSSメンテナンスは業務の一部
    • 追加の申請や上司の許可は不要
    • 技術的負債やインフラ保守と同じ扱い
  • 従来から行われてきたやり方の明文化
    • OSSメンテナーは自律的に作業
    • ミーティングや承認を待たずにインターネットを支える

実践方法と注意点

  • やるべきこと
    • PRレビュー、依存関係の更新、バグ修正など、担当OSSの保守作業
  • 自分を守る方法
    • 契約内容の確認
    • 機密情報は公開しない
    • 公開OSSのIP（知的財産）権の帰属を確認
  • やりすぎ注意
    • 業務時間の100%をOSSに使わない
    • バランス重視、自己責任

代替案と進化

  • 他のアプローチ
    • Open Source Pledge（開発者1人あたり年2000ドル支払い）
    • Open Source Friday（毎週金曜2時間をOSSに）
    • 雇用主への事前相談も推奨
  • Open Source Resistance
    • 依存OSSの保守は既に業務の一部
    • 自分の裁量で作業時間を使う
    • 予算管理は会社側の問題、時間配分は自分でコントロール

よくある反論とその回答

  • 「これは窃盗だ」
    • 企業は日常的にOSSから価値を得ている
    • OSS保守は共通インフラの維持であり窃盗ではない
  • 「許可を取るべき」
    • 許可を求めるのは力関係の固定化
    • インフラ保守に許可は不要
  • 「サボり（quiet quitting）だ」
    • これは生産性の低下ではなく、OSSインフラの維持
    • 企業が作業を業務と認めないのが問題
  • 「良い雇用主も巻き込まれる」
    • 良い企業は既にOSS保守を認めたり支援している
    • それでも自分のプロジェクトは自分で守る必要

Mike McQuaidの実践例

  • Homebrew、GitHub Sponsors、Open Source Fridayの立ち上げ
  • 自身のOSS活動の大半を業務時間内で実施
  • IP契約の交渉経験多数
  • プライベートの時間を搾取される義務はない
    • 持続可能なOSS活動の重要性を強調

注意事項・法的な観点

  • これは法的助言ではなく倫理・政治的主張
  • リスクが高い場合は専門家に相談
  • 雇用契約・IP規定・社内ポリシーの確認必須
    • 雇用中の成果物は会社のものになる可能性
    • 個人時間・個人機材での作業ルールは州や契約で異なる
  • IP契約の交渉方法
    • 入社前にOSS活動の例外を明記
    • GitHubのBalanced Employee IP Agreementを参考に交渉
  • 機密保持とセキュリティ遵守
    • 機密情報や社内リソースの公開厳禁
    • 公私の区別を明確に
  • 静かに、しかし慎重に
    • リスクを見極めて自己判断
    • パフォーマンス評価が下がる可能性も許容
    • 持続可能な働き方の重視

適用範囲と限界

  • クライアントワーク、政府案件、規制環境では弱い主張
  • ジュニアや不安定な立場のエンジニアにはリスクが高い
  • シニアで既存OSS依存の保守なら強い主張
  • 「何でも業務時間で」ではなく「既存OSSの保守を業務の一部に」
    • 担当プロジェクトや業務関連ツールの改善に限定
    • 関連性のない作業やプロプライエタリなものは避ける

Hackerたちの意見

いいアイデアだと思うけど、「抵抗」として位置づけるのはどうかな。多分、君の仕事は何か目標を達成することだよね。君がその目標をどうやって達成するかを決める専門家なんだから。オープンソースソフトウェアがその決定の一部なら、維持管理もその一環だよ。これは過激なことじゃなくて、君の仕事を支えるための未来の安定性や維持管理を守るためにやるべきことなんだ。

└

同意する。そういう表現だと、誰かがSNSで注目を集めようとしてるみたいに見える。すべてが誇張されなきゃいけないなんて、悲しいよね。

└

それに、ビジネス的にも理にかなってるよね。オープンソースを通じてコラボレーションを促進する企業は、自分たちのビジネスを支えるエコシステムを育ててるんだ。

└

君の言うことには賛成だけど、最近のほとんどのテック企業の現実（私の経験に基づいて）では、強制されない限り、自分たちのインフラやライブラリの維持に時間を投資しないんだよね。ましてやオープンソースなんて。ゲームのメトリクスのために無駄な機能を作ったり、エンシチフィケーションやダークパターン、ボーダーラインのマルウェア/ハイプ統合なんかが、基盤のインフラやライブラリへの投資よりも優先されるんだ。

この考えには全面的に賛成だけど、実際にやるのは難しいと思う。私の知る限りでは、一般的に雇用主が知的財産を所有しているから、OSSとして公開するには明示的な許可が必要なんだ。その許可を得るのはしばしば難しくて、無限の手続きや法務部門を通さなきゃいけないこともある。> アメリカ、イギリス、その他いくつかの法域では、従業員が職務の一環として作成した作品は、雇用主が法的著作者または著作権の最初の所有者と見なされる。 https://en.wikipedia.org/wiki/Work_for_hire とはいえ、オープンソースの作業（維持管理や開発）は、寄付をお願いするボランティアではなく、給料をもらっている専門家によって行われるべきだと思う。大きな問題は、それをどう実現するか、企業がOSSへの貢献を特別な交渉が必要なものではなく、標準的な実践として受け入れるようにするにはどうすればいいかだね。

└

完全なオープンソースを推進する必要はないよ。会社の知的財産が依存しているOSSパッケージの維持管理を手伝う時間を交渉したり、後でコミュニティにリリースできるような中立的なモジュールを作るために自分の知的財産を設計したりできる。

└

これはすべての州に当てはまるわけじゃないよ。カリフォルニア州には、労働者の知的財産を雇用主が盗むことを禁止するカリフォルニア労働法第2870条がある。

└

個人的には、特定の契約の例外を設けて、例えば会社の機器での勤務時間中だけ適用されるようにしてるよ（もっと緩やかでもいいかも）。GitHubの緩いIP契約は、ここでさらにリラックスした例だね。

└

一般的な概念としては全面的に同意するけど、実際に実現するのは難しいと思う。君が言ってる問題は、実際には「実践の中の問題」じゃなくて、理論的な問題だよ。実際には、ただやりたいことをやればいいんだ。コンピュータ上でgit pushを止めるサブルーチンなんてないし。実際には、雇用主は雇用契約にいろいろ書くだけだよ。可能な限りすべてを書いて、あらゆる方向からのリスクをカバーしようとする。もし彼らが自由に書けるなら、君も自由にやっていいんじゃない？何も問題じゃない。実際には、ほとんどのオープンソースプロジェクトはこの技術的な理由でIPが挑戦されたことなんてないよ。

└

オランダでは、法律がかなり明確で、これは悪いアイデアだね。> 「雇用の性質」ルール：ソフトウェア開発者として雇われた場合、あなたが作成したほとんどのソフトウェア（自分の時間に作ったものでも）を雇用主が主張できる。私たちは常に従業員に例外を求めるようにアドバイスしてる。私たちはかなりリラックスしてるけど、全体的な例外は出さないよ。

└

私は法律の専門家ではないけど、一般的には雇用主が知的財産を所有していて、OSSとして公開するには明示的な許可が必要だよ。もしその作業が仕事に関連しているなら、これは本当だよ。仕事に関連していない場合は州によるけど、多くの州では雇用主が自分の知的財産として主張できることに制限がある。一般的な契約書は、言葉を広く使うからすべてを主張しようとするけど、法律では、雇用主があなたの自由時間にやった仕事を主張できないって言ってることが多い。もし勤務時間中に作業をしたり、会社のノートパソコンを使ったりしたら、雇用主はそれに対して権利を主張できる。ほとんどの会社は気にしないだろうけど、もし争いが起きたときのために、きちんとした状態を保つことは大事だよ。自分の時間で、自分のハードウェアで作業して、雇われている仕事や職場で触れたものと重ならないようにしよう。

└

現在のプログラミングの状況が示していることは、知的財産権や著作権法はもう存在しないってことだね。

Hacker Newsで議論の続きを見る