Final review of legal article

Author: yuichielectric

_articles/ja/legal.md

@@ -1,7 +1,7 @@
 ---
 lang: ja
 title: オープンソースの法的側面
-description: オープンソースについてあなたが不思議に思ったことのすべてと、思いもしなかったいくつかのこと。
+description: オープンソースの法的側面についてあなたが疑問に思うだろうことや、思いもしないだろうことについて。
 class: legal
 order: 10
 image: /assets/images/cards/legal.png
@@ -12,11 +12,11 @@ related:
 
 ## オープンソースの法的意味を理解しよう
 
-あなたの創造的な仕事を世界に共有することは、とても興奮することであり報われる経験になり得ます。しかし、それは懸念必要があることを知らなかった多くの法的な事柄が必要になるということでもあるのです。ありがたいことに、あなたはゼロから始める必要はありません。あなたが必要な法的知識をここにまとめました。（読み進める前に、私達の[免責事項](/notices/)をお読みください。）
+あなたの創造的な仕事を世界に共有することは、とても興奮することであり報われる経験になり得ます。しかし、それは懸念する必要があることをそもそも知らなかったような、多くの法的な事柄が必要になるということでもあるのです。ありがたいことに、あなたはゼロから始める必要はありません。あなたが必要な法的知識をここにまとめました。（読み進める前に、[免責事項](/notices/)をお読みください。）
 
 ## なぜオープンソースの法的な側面を気にするんですか？
 
-聞いてくれて嬉しいです！何か作品（文書、グラフィックス、コードなど）を創作するときには、その作品はデフォルトで排他的な著作権によって守られます。つまり、あなたは作品の作者として、他の人があなたの作品についてやって良いことについて意見があるということを法律は想定しています。
+よくぞ聞いてくれました！何か作品（文書、グラフィックス、コードなど）を創作するときには、その作品はデフォルトで排他的な著作権によって守られます。つまり、あなたは作品の作者として、他の人があなたの作品についてやって良いことについて意見があるということを法律は想定しています。
 
 この事は、一般的にはあなたの作品を使ったり、コピーしたり、配布したり、修正することは、取り下げや捜査、訴訟のリスクが発生することを意味します。
 
@@ -34,7 +34,7 @@ GitHub 上で[新しいプロジェクトを作る](https://help.github.com/arti
 
 **GitHub 上のプロジェクトをおパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
 
-もし、他に人に対してプロジェクトの利用、配布、変更、コントリビュートをしてもらいたいと思うのであれば、オープンソースライセンスをプロジェクトに含める必要があります。たとえあなたのプロジェクトがパブリックだったとしても、もしあなたがプロジェクトのソースコードをほか脳 p ロジェクトで使って良いと明記しない限りは、他の人はそのプロジェクトのコードのどの部分も合法的に使うことができません。
+もし、他に人に対してプロジェクトの利用、配布、変更、コントリビュートをしてもらいたいと思うのであれば、オープンソースライセンスをプロジェクトに含める必要があります。たとえあなたのプロジェクトがパブリックだったとしても、もしあなたがプロジェクトのソースコードを他のプロジェクトで使って良いと明記しない限りは、他の人はそのプロジェクトのコードのどの部分も合法的に使うことができません。
 
 ## 私のプロジェクトを守るのに必要な概要だけを教えてください。
 
@@ -46,7 +46,7 @@ GitHub で新しいプロジェクトを作るときには、[ライセンスを
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
-  標準化されたライセンスは、ソフトウェアに対して他の人は何ができて何ができないのかを正確に把握していない人にとっては、代理人として機能します。どうしても必要な場合を除いて、カスタムしたり、修正したり、標準的でない条項は使わないようにしましょう。そういったものは、政府機関のコードを下流で使う際の障壁となります。
+  標準化されたライセンスは、ソフトウェアに対して他の人は何ができて何ができないのかを正確に把握していない人にとっては、代理人として機能します。どうしても必要な場合を除いて、カスタムしたり、修正したり、標準的でない条項は使わないようにしましょう。そういったものは、政府機関のコードから使う際の障壁となります。
   <p markdown="1" class="pquote-credit">
 — @benbalter, ["Everything a government attorney needs to know about open source software&nbsp;licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
   </p>
@@ -78,7 +78,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 例えば、プロジェクトが成長するに従って依存関係やユーザーが増えたり、あなたの企業が戦略を変更したり、こういった理由によって異なるライセンスが必要になることがあります。それに加えて、もしプロジェクトを開始する際にライセンスを指定していなかったら、ライセンスをあとから追加するということはライセンスを変更することと実質上同じになります。ライセンスを追加したり変更する際に考えるべき重要なポイントは 3 つあります：
 
-**事態は複雑。** ライセンスの互換性や遵守を検討したり、誰がコピーライトを保持しているのかを調査することはすぐに複雑で混乱するでしょう。新しいリリースやコントリビュートについてのみ、新しいが互換性のあるライセンスに切り替えるのは、過去のコントリビュートの全てのライセンスを切り替えることとは事情が異なります。ライセンスを変更したいと思い始めた時に、法務部門を巻き込みましょう。たとえプロジェクトのコピーライトの保有者からライセンスの変更について許可を得ている（もしくは得ることが可能）としても、プロジェクトの他のユーザーやコントリビューターへの影響をきちんと考慮しましょう。ライセンスの変更は、あなたのプロジェクトにおける「運営上の大きな出来事」だと考えるようにしましょう。そうすることで、プロジェクトの利害関係者と明確なコミュニケーションと相談を行い、物事が円滑に進むようになります。プロジェクト発足時に適切なライセンスを選んで使うべきなのはこういった事情のためです！
+**事態は複雑です。** ライセンスの互換性や遵守を検討したり、誰がコピーライトを保持しているのかを調査することは、すぐに複雑で混乱するものだとわかるでしょう。新しいリリースやコントリビュートについてのみ、新しいが互換性のあるライセンスに切り替えるのと、過去のコントリビュートの全てのライセンスを切り替えることとは事情が異なります。ライセンスを変更したいと思い始めた時に、法務部門を巻き込みましょう。たとえプロジェクトのコピーライトの保有者からライセンスの変更について許可を得ている（もしくは得ることが可能）としても、プロジェクトの他のユーザーやコントリビューターへの影響をきちんと考慮しましょう。ライセンスの変更は、あなたのプロジェクトにおける「運営上の大きな出来事」だと考えるようにしましょう。そうすることで、プロジェクトの利害関係者と明確なコミュニケーションと相談を行い、物事が円滑に進むようになります。プロジェクト発足時に適切なライセンスを選んで使うべきなのはこういった事情のためです！
 
 **プロジェクトの既存のライセンス。** もし既存のライセンスとこれから変更しようとしているライセンスで互換性があるのであれば、単に新しいライセンスを使い始めれば大丈夫です。なぜなら、もしライセンス A がライセンス B と互換性がある場合、ライセンス B の規約に従っているのであればライセンス A の規約も遵守していることになるからです（ただし、必ずしも逆は成り立ちません）。もし現在使っているのが寛容なライセンス（例えば MIT ）であれば、 MIT ライセンスと関連するコピーライト表示を保ちつづける（つまり、 MIT ライセンスの最低限の条件は守り続ける）かぎりは、より条件の多いライセンスに変更することができます。しかし、現在使っているライセンスが寛容でなく（例えばコピーレフトやライセンスがない場合）、あなたが単一のコピーライト保持者ではない場合、単純にライセンスを MIT に変更することはできません。基本的に寛容なライセンスでは、プロジェクトのコピーライト保有者は前もってライセンスの変更を許可しているということになります。
 
@@ -106,7 +106,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 * あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する（オンラインかオフラインでの _サイン_）必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない（たとえ実際には十分だったとしても！）と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。
 * あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[Developer Certificate of Origin](https://developercertificate.org/) の要件はこれを達成するプロジェクトの数です。例えば、Node.js コミュニティは彼らが以前使っていた CLA の[代わりに](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution)、DCO を[使っています](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md)。あなたのリポジトリでDCOの執行を自動化するためのシンプルなオプションは [DCO Probot](https://github.com/probot/dco) を使うことです。
-* プロジェクトで使っているオープンソースライセンスに特許許諾が明記されておらず（ MIT ライセンスのように）、全てのコントリビューターから特許許諾を取る必要がある場合。コントリビューターの中にあなたのプロジェクトやプロジェクトのコントリビューター、ユーザーを巨大な特許ポートフォリオの対象にする企業があるかもしれないためです。 [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) は、 Apache License 2.0 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。
+* プロジェクトで使っているオープンソースライセンスに特許許諾が明記されておらず（ MIT ライセンスのように）、全てのコントリビューターから特許許諾を取る必要がある場合。これは、コントリビューターの中にあなたのプロジェクトやプロジェクトのコントリビューター、ユーザーを巨大な特許ポートフォリオの対象にする企業があるかもしれないためです。 [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) は、 Apache License 2.0 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。
 * プロジェクトがコピーレフトライセンスを使っているが、プロプライエタリバージョンも提供する必要がある場合。この場合、全てのコントリビューターから、コピーライトをあなたに割り当てるか、寛容なライセンスを（パブリックに対してではなく）あなたに対して許諾する必要があるでしょう。 [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) はこの種の同意の例です。
 * プロジェクトが成熟するに連れてライセンスを変更する必要があるを考えており、コントリビューターに前もってライセンス変更の同意を得ておきたい場合。
 
@@ -128,7 +128,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 * **商標：** あなたのプロジェクトの名前が[既存の商標と衝突していないか](../starting-a-project/#名前の衝突を避ける)入念に確認しましょう。もしあなたの企業の商標をプロジェクトで使っている場合は、それによって利害の対立が発生しないかを確認しましょう。 [FOSSmarks](http://fossmarks.org/) はフリーやオープンソースプロジェクトの文脈における商標について理解するための実践的なガイドです。
 
-* **プライバシー：** あなたのプロジェクトではユーザーのデータを収集していますか？"Phone home" to company servers?法務部門が企業の方針や外部の規制を遵守するために手助けしてくれます。
+* **プライバシー：** あなたのプロジェクトではユーザーのデータを収集していますか？企業のサーバーに秘密の通信を行っていませんか？法務部門が企業の方針や外部の規制を遵守するために手助けしてくれます。
 
 もし企業内で初めてのオープンソースプロジェクトを公開しようとしているのであれば、オープンソース化の道のりには上記以外にもあるかもしれません（でも心配しないでください、ほとんどのプロジェクトでは大きな問題はありません）。