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

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

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

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

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

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

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

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

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

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

投稿は、抵抗の少ない道を選ぶように提案してるんだと思う。会社の時間で働いて、大きな波を立てないようにする感じ。もし捕まったら、許しを請う。会社にとっては、許してくれるのが楽な道だし、弁護士を巻き込むとすごく高くつくし、PRの悪夢になる可能性もあるからね。

一般的な概念としては全く同意するけど、実際にそれを達成するのは難しいと思う。法律の専門家じゃないけど、一般的には雇い主が知的財産を所有しているから、OSSとして公開するには明示的な許可が必要だよね。法律の専門家じゃないけど、同僚にコピーを渡して実行させたら、OSSライセンスを使ってそれができるってことだよね？同僚はそのライセンスによって法的権利を持つことになるよね？変更を再配布する権利も含めて？上流に変更をプッシュするのが、変更が維持される確実な方法なのに、これって本当に馬鹿げてるよね。内部の独自フォークを維持することに関する法的な不確実性も言うまでもないし。

残念ながら、責任の問題がよく出てくるんだよね。もしコードをコミットして、それが後で訴訟の対象になったらどうするの？「やりたくない」ってだけじゃ済まないよ。（私は全面的に支持してるけど、法律が絡むとリスクを正当化できる必要があるんだ。）

“もちろん、これをコンプライアンスチームに通してみるね。知的財産の侵害がないか確認するために。どのリポジトリと問題なの？”

いろんな理由で前の仕事をクビになったのはちょっと悲しいけど、その中でも大きな理由の一つは、私がKafka Streamsライブラリに対して行った大きな変更をオープンソースにする話が出ていたことだね。APIをほぼ互換性を保ちながら、多くの部分を書き直して、必要に応じてバックプレッシャーセマンティクスを強調する非ブロッキングIOに焦点を当てたんだ。すごく面白いことができて、状態ストアやブロッキングと非ブロッキングIOを組み合わせて、比較的パフォーマンスが良い形で実現できたのが本当にクールだった。これがすごく良いプロジェクトで、自分が誇りに思っている理由の一つだよ。パフォーマンスを引き出すのが難しいところで、たくさんの場所でそれを実現できたからね。Githubにリリースしたり、上流のKafka StreamsプロジェクトにPRを出すことを推進していたけど、残念ながらその前にレイオフがあって、その後は本当にそれを推進する「チャンピオン」がいなくなっちゃったから、プロプライエタリな状態に留まってしまった。もしかしたら、ゼロからやり直してFOSSにするかもしれない。もう十分な時間が経ったから、書き直してリリースしても問題ないと思うし（特許とかはついてなかったし）、いくつか変更したい点もある（例えば、Vert.xの依存関係をなくすとか）。もし1週間の休みが取れたら、やってみるかもね。

こういうことができる職場で働いていたのが懐かしいな。雇い主によっては、法的なレビューにばかりこだわってしまうことがあるよね。以前、プロジェクトにパッチを提出する許可を求めたことがあって、面白いメールのやり取りがあったんだ。結局、こんな質問に行き着いた。「そのパッチが顧客に請求する時間内に書かれたもので、バグ修正のためのもので、パッチを当てるライブラリを再コンパイルしてソースコードと一緒に納品しなければならず、契約書には製品に関連するすべての作業と知的財産が顧客に譲渡されると書かれている場合、私たちはそのパッチをパブリックドメインで公開する権限があるのか？」法務はその質問に答えたくなかったみたい。

一般的にはいいアプローチだと思うし、プロフェッショナルに物事を考える素晴らしい例だけど、問題の核心を解決してないのが気になる。エンジニアリングに特化した会社のリーダーがすぐに理解しないのは問題だと思う。運もこのアプローチには大きく影響するよね。

生産部分以外で、雇用主が許可されたライセンスのコードを公開していない仕事は受けないな。それは私にとって士気を下げるし、精神的にギリギリになる。むしろ貧乏の方がマシだよ。

彼らが言いたかったのは、自分のものでない作業を勝手に公開しようとしない方がいいってことだと思う。下の方にもそのことについてのセクションがあるけど、最初の箇条書きがちょっと混乱を招いたね。この点は経験豊富な開発者には明らかだけど、うちの会社の若手開発者には本当に問題になってることがある。社内プロジェクトで面白いことをやってるのを見て、それをオープンソースプロジェクトに貢献できると思ってしまうんだ。でも、クローズドソースのコードを使って似たようなコードを提出することの問題を考えないんだよね（場合によってはコピー＆ペーストすることも）。

ちゃんと調べたことはないけど、ドイツでは基本的に勤務時間中に作成されたソースコードは雇用主が所有するって印象がある。ITに特化してないほとんどの雇用主は、オープンソースが何か、どう機能するかも理解してないだろうから、許可を得るのは無理だと思う。リンク先のサイトは、オープンソースの利点を説明することと、雇用主向けの法的ガイドラインを提唱することに重点を置くべきだね。