|
1 | 1 | ## Title |
2 | 2 |
|
3 | | -InnerSource License |
| 3 | +インナーソースライセンス |
4 | 4 |
|
5 | 5 | ## Patlet |
6 | 6 |
|
7 | | -同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいが、法的責任や会社間の会計処理の観点からの影響を懸念している。 |
| 7 | +同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。 |
8 | 8 |
|
9 | | -**インナーソースライセンス**は、組織内でソースコードを共有するための再利用可能な法的枠組みを提供します。これにより、新しいコラボレーションの選択肢が広がり、関係する法人の権利と義務が明確になります。 |
| 9 | +**インナーソースライセンス**は、組織内でソースコードを共有するための再利用可能な法的枠組みを提供します。これにより、新しいコラボレーションの選択肢が広がり、関係する法人 の権利と義務が明確になります。 |
10 | 10 |
|
11 | 11 | ## 問題 |
12 | 12 |
|
13 | | -組織内の2つ以上の法人が互いにコードを共有しようとする場合、条件についての合意が必要であり、多くの場合、法的な契約が必要である。プロジェクトごとにこのような契約を結ぶには労力がかかり、共有の障壁となる。たとえば、ある法人のチームは、複雑そうだからという理由で、組織内の別の法人とソースコードを共有しないことに決めるかもしれない。 |
| 13 | +組織内の2つ以上の法人が互いにコードを共有したい場合、条件についての合意が必要であり、多くの場合で法的契約が必要になります。プロジェクトごとにこのような契約を作成するには手間がかかり、それは共有における障壁になってしまいます。たとえば、ある法人のチームは複雑そうだからという理由で、組織内の別の法人とソースコードを共有しないことに決めるかもしれません。 |
14 | 14 |
|
15 | | -共有の障壁は、組織内の複数の部分で類似のソリューションを再構築する際のサイロ化や労力の重複につながる可能性があります。 |
| 15 | +共有における障壁は、組織の複数で同様のソリューションを再構築する際のサイロ化と車輪の再発明につながる可能性があります。 |
16 | 16 |
|
17 | | -ソースコードを共有する時点では、共有の価値がどうなるかを確実に予測することができない。共有という活動に多大な労力（使用条件の交渉など）を要する場合、法人は投資対効果を気にするため、それを行う可能性は低くなります。 |
| 17 | +ソースコードを共有する時点では、共有の価値を確実に予測することはできません。共有の活動に(使用条件の交渉などの)多大な労力が必要な場合、法人は投資に対する収益率を懸念しているため、一連の活動を行う可能性は低くなります。 |
18 | 18 |
|
19 | 19 | ## 状況 |
20 | 20 |
|
21 | | -- コードを共有したい多くの法人（子会社）を持つ大組織。組織が大きくなると、このパターンの価値が高くなる。 |
| 21 | +- コードを共有したい大量の子会社を持つ持つ大組織。組織が大きくなればなるほど、このパターンの価値は高くなります。 |
22 | 22 | - 定義によると、法人は独自の法的権利と義務を持っている。 |
23 | | -- これらの法人のうち、複数の法人がソフトウェアを開発し、他の法人のサービスを利用している。互いのソースコードにコントリビュートする動機がある。 |
24 | | -- 組織とその組織構造が十分に複雑である。 |
| 23 | +- 複数の法人はソフトウェアを開発しており、他の法人のサービスを使用しています。彼らには、お互いのソースコードに貢献する動機があります。 |
| 24 | +- 組織とその組織構造は十分に複雑です。 |
25 | 25 |
|
26 | 26 | ## ブロッカーとなりうるちから (Forces) |
27 | 27 |
|
28 | | -- 特に、技術、法律、ビジネスの観点を考慮する必要がある場合、正式な契約書を書くのに必要な**労力のレベル**。 |
29 | | -- 大きな組織（多くの法人から成る）には、多くの**内部規制**がある。新たに締結される契約は、セキュリティ、プライバシー、調達プロセスなど、これらの規制に準拠しなければなりません。規制が多いため、特に標準的な手順がない場合、2つの法人間でソフトウェアを共有することがこれらの規制に準拠しているかどうかを評価することが困難になる場合があります。 |
30 | | -- 組織内のいずれかの法人が、独占的なコードと組織内のライセンス料の会計処理に依存する **ビジネスモデル** を有している場合 |
31 | | -- InnerSourceのコラボレーションと共有コードに使用されていない**企業文化**。これは、共有コードを使用する場合の権利と義務についての不確実性をもたらす。 |
32 | | -- ソフトウェアを使用する上の自由は、競争、および所有権の普及につながる |
33 | | -- ソースコードの共有をカバーする法的な契約は存在します。これらの契約は標準化されていないため、プロジェクトごとに交渉と理解のための追加的な労力が発生する。また、既存の契約では、真のインナーソースのアプローチをサポートするために十分オープンな意味でのソースコードの共有ができない場合があります。 |
34 | | -- あるいは、法的な契約は存在しないが、ソースコードは非公式に共有されている場合もあります。その場合、所有権や権利・義務の明確化が必要なケースで、不確実性が生じるかもしれません。 |
| 28 | +- 特に、技術、法律、ビジネスの観点を考慮する必要がある場合、正式な契約書を書くのに必要な**労力のレベル**があります。 |
| 29 | +- 大きな組織(特に多くの法人から成る組織)には、多くの**内部規制**があります。新たに締結される契約は、セキュリティ、プライバシー、調達プロセスなど、これらの規制に準拠しなければなりません。規制が多いため、特に標準的な手順がない場合、2つの法人間でソフトウェアを共有することについてこれらの規制に準拠しているかどうかを評価することが困難になる場合があります。 |
| 30 | +- 組織内のいずれかの法人が、独占的なコードと組織内のライセンス料の会計処理に依存する **ビジネスモデル** を有している場合があります。 |
| 31 | +- インナーソースのコラボレーションとソースコードの共有に**企業文化**が慣れていない場合があります。これは、共有ソースコードを使用する場合の権利と義務についての不確実性をもたらします。 |
| 32 | +- ソフトウェアの使用を自由にすることが、競争と所有権の拡大につながります。 |
| 33 | +- ソースコードの共有に関する事項を含む法的なルールが存在します。しかしこれらのルールは標準化されていないため、プロジェクトごとに交渉と理解のための追加的な労力が発生します。また既存の契約では、真のインナーソースのアプローチをサポートするために十分オープンな意味でのソースコードの共有ができない場合があります。 |
| 34 | +- あるいは、法的な契約は結ばれていないものの、ソースコードが非公式に共有されている場合もあります。その場合、所有権や権利・義務の明確化が必要なケースにおいて不確実性が生じるかもしれません。 |
35 | 35 |
|
36 | 36 | ## ソリューション |
37 | 37 |
|
38 | | -対象組織（およびその法人）のニーズに合わせてカスタマイズした **InnerSource License** を作成する。このライセンスは、最も重要な企業間関係に適用できるような汎用的なものである必要があります。 |
| 38 | +対象組織(およびその法人)のニーズに合わせてカスタマイズした **インナーソース ライセンス** を作成します。このライセンスは、最も重要な企業間関係に適用できるような汎用的なものである必要があります。 |
39 | 39 |
|
40 | | -InnerSourceライセンスは、関係する法的実体の境界を越えて、本当にオープンソースのような共同作業を可能にするように書くことが重要です。したがって、フリーソフトウェアの4つの自由は、ライセンスに統合されるべきです。 |
| 40 | +インナーソース ライセンスは、関係する法的実体の境界を越えて、本当にオープンソースのような共同作業を可能にするように書くことが重要です。したがって、フリーソフトウェアの4つの自由(*)は、ライセンスに統合されるべきです。 |
41 | 41 |
|
42 | | -このライセンスは正式な法的文書として書かれており、コード共有契約を管理するために法人間の契約の一部として使用することができます。 |
| 42 | +このライセンスは正式な法的文書として書かれており、コード共有契約を管理するために法人間の契約の一部として使用することができるようにします。 |
| 43 | + |
| 44 | +(*「4つの自由」の補足: 使用する自由, 変更する自由, 共有する自由, 変更したソフトウェアを再配布する自由) |
43 | 45 |
|
44 | 46 | ## 結果の状況 |
45 | 47 |
|
46 | | -InnerSourceライセンスにより、私たちは組織内の法人間でコードを共有するためのツールを手に入れました。 |
| 48 | +インナーソースライセンスにより、組織内の法人間でコードを共有するためのツールを手に入れることができます。 |
47 | 49 |
|
48 | | -このライセンスは、ソースコードの共有に関するわたしたちの組織内の会話を単純化し、そうする最初の法的主体を動機づけています。 |
| 50 | +このライセンスは、ソースコードの共有に関する組織内の会話を簡素化し、法人が最初に使う動機づけにもなっています。 |
49 | 51 |
|
50 | | -**注：**既知のインスタンスで説明されている実験は初期段階にあります。したがって、しっかりとした**結果コンテキスト**はまだ形成されていない。数ヶ月後には、この問題空間に対するInnerSource Licenseの効果がより明確になり、このセクションは更新されるでしょう。 |
| 52 | +**注:** 事例で説明されている実験は初期段階にあります。したがって、しっかりとした**結果の状況**はまだ形成されていません。数ヶ月後には、この問題に対するインナーソースライセンスの効果がより明確になり、このセクションは更新されるでしょう。 |
51 | 53 |
|
52 | 54 | ## 事例 |
53 | 55 |
|
54 | | -DB Systelは彼ら自身のInnerSource Licenseを作りました、[DB Inner Source License][db-inner-source-license] をご覧ください。彼らは、オープンソースのような出発点を提供する[EUPL][eupl]を使用し、その後、彼らの特定の組織のコンテキストに必要な制約と追加のルールを作り出しました。 |
| 56 | +DB Systel社は彼ら自身のインナーソースライセンスを作りました、内容は[DB Inner Source License][db-inner-source-license] をご覧ください。彼らは、オープンソースのような出発点を提供する[EUPL][eupl]を使用し、その後、彼らの特定の組織のコンテキストに必要な制約と追加のルールを作り出しました。 |
55 | 57 |
|
56 | | -DB AGの中で最初の法人（企業）は、このInnerSource Licenseを使用しています。 |
| 58 | +DB 社の中で最初の法人(企業) は、このインナーソース ライセンスを使用しています。 |
57 | 59 |
|
58 | | -すでに現れているポジティブな効果の1つは、特に関係者の中にまだInnerSourceのコンセプトをよく知らない人がいる場合、会話がシンプルになることです。ライセンスはよく知られた概念なので、InnerSourceライセンスがあることは、議論のきっかけになります。 |
| 60 | +すでに現れているポジティブな効果のひとつは、特に関係者の中にまだインナーソースのコンセプトをよく知らない人がいる場合、会話がシンプルになることです。ライセンスはよく知られた概念なので、インナーソースライセンスがあることは、議論のきっかけになります。 |
59 | 61 |
|
60 | | -この実験では、真のInnerSourceのコントリビューションとコラボレーションモデルにつながるために解決しなければならない、さらなるコラボレーションの課題があることも明らかになりました。 |
| 62 | +この実験では、真のインナーソースのコントリビューションとコラボレーションモデルにつながるために解決しなければならない、さらなるコラボレーションの課題があることも明らかになりました。 |
61 | 63 |
|
62 | 64 | その課題とは、以下のようなものです。 |
63 | 65 |
|
64 | | -- InnerSourceのライセンスプロジェクトを発見できるようにする |
| 66 | +- インナーソースのライセンスプロジェクトを発見できるようにする |
65 | 67 | - オープンソースのように、プロジェクトでコラボレーションするためのコミュニティを構築すること。 |
66 | 68 |
|
67 | | -これまでのところ、このInnerSourceライセンスの下で共有されるソフトウェアは、ほとんどがツール、インフラ、およびスタックの下位にあるツールであることは言及に値します。 |
| 69 | +これまでのところ、このインナーソースライセンスの下で共有されるソフトウェアは、ほとんどがツール、インフラ、およびスタックの下位にあるツールであることは言及に値します。 |
68 | 70 |
|
69 | 71 | ## ステータス |
70 | 72 |
|
71 | | -* 構造化 |
72 | | -* 既知のインスタンス**に記載されている実験は、2020年2月から実施されています。最初の経験では、最初のポジティブな効果を示しているが、パターンを完全に評価するためには、より多くの経験が必要である。 |
73 | 73 |
|
74 | | -## 著者(s) |
| 74 | +* Structured |
| 75 | +* **事例**に記載されている実験は、2020年2月から実施されています。最初の経験では、最初のポジティブな効果を示していますが、パターンを完全に評価するためには、より多くの経験が必要になります。 |
| 76 | + |
| 77 | +## 著者 |
75 | 78 |
|
76 | 79 | - Cornelius Schumacher (DB Systel GmbH) |
77 | 80 | - Schlomo Schapiro (DB Systel GmbH) |
78 | 81 | - Sebastian Spier |
79 | 82 |
|
80 | | -## References |
| 83 | +## リファレンス |
81 | 84 |
|
82 | | -- FOSSBack 2020 Presentation: [Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - watch 27:30 and onwards for details about the InnerSource License |
| 85 | +- FOSSBack 2020 Presentation: [Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - インナーソース ライセンスの詳細については、27:30以降をご覧ください |
83 | 86 | - [DB Inner Source License][db-inner-source-license] |
84 | 87 |
|
85 | | -## Glossary |
| 88 | +## 単語の解説 |
86 | 89 |
|
87 | | -- **organization** - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa) |
88 | | -- **legal entity** - An entity that has its own legal rights and obligations (synonyms: company, subsidiary) (e.g. Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...) |
| 90 | +- **組織** - 複数の企業の母体(同義語: グループ、ホールディング、エンタープライズ) (例: Microsoft Corporation) |
| 91 | +- **法的エンティティ** - 独自の法的権利と義務を有するエンティティ (同義語: グループ子会社、子会社、関連会社) (例: Microsoft Japan, GitHub, LinkedIn) |
89 | 92 |
|
90 | 93 | [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/blob/master/DB-Inner-Source-License.md |
91 | 94 | [eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 |
| 95 | + |
| 96 | +## 翻訳の履歴 |
| 97 | +- **2022-06-05** - 翻訳 [Yuki Hattori](https://github.com/yuhattor) |
| 98 | + |
0 commit comments