Merge pull request #1304 from two-pack/fix_ja_typo

Fixes typos in legal.md of Japanese translation

Author: yuichielectric

_articles/ja/legal.md

@@ -32,7 +32,7 @@ GitHub 上で[新しいプロジェクトを作る](https://help.github.com/arti
 
 ![リポジトリの作成](/assets/images/legal/repo-create-name.png)
 
-**GitHub 上のプロジェクトをおパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
+**GitHub 上のプロジェクトをパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
 
 もし、他に人に対してプロジェクトの利用、配布、変更、コントリビュートをしてもらいたいと思うのであれば、オープンソースライセンスをプロジェクトに含める必要があります。たとえあなたのプロジェクトがパブリックだったとしても、もしあなたがプロジェクトのソースコードを他のプロジェクトで使って良いと明記しない限りは、他の人はそのプロジェクトのコードのどの部分も合法的に使うことができません。
 
@@ -90,7 +90,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 
 おそらく必要ありません。大部分のオープンソースプロジェクトでは、オープンソースライセンスはインバウンド（コントリビューターから）もアウトバウンド（他のコントリビューターやユーザー向け）の両方のライセンスとして使うことができます。もしプロジェクトを GitHub 上においているのであれば、 GitHub の利用規約によってインバウンドとアウトバウンドが同じであるということがデフォルトとして[明記されています](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license)。
 
-追加のコントリビューターアグリーメントはしばしば Controbutor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。
+追加のコントリビューターアグリーメントはしばしば Contributor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。
 
 加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない（プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合）と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは有効的でないと受け取られるかもしれません。
 
@@ -108,7 +108,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
 * あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[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 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。
 * プロジェクトがコピーレフトライセンスを使っているが、プロプライエタリバージョンも提供する必要がある場合。この場合、全てのコントリビューターから、コピーライトをあなたに割り当てるか、寛容なライセンスを（パブリックに対してではなく）あなたに対して許諾する必要があるでしょう。 [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) はこの種の同意の例です。
-* プロジェクトが成熟するに連れてライセンスを変更する必要があるを考えており、コントリビューターに前もってライセンス変更の同意を得ておきたい場合。
+* プロジェクトが成熟するに連れてライセンスを変更する必要があると考えており、コントリビューターに前もってライセンス変更の同意を得ておきたい場合。
 
 追加のコントリビューターアグリーメントがあなたのプロジェクトで必要なのであれば、コントリビューターの手間を最小限に留めるために [CLA assistant](https://github.com/cla-assistant/cla-assistant) のような連携ツールを使うことを検討しましょう。