プロジェクト

全般

プロフィール

CM Plan » 履歴 » バージョン 1

KOBAYASHI Shinji, 2009/04/02 14:34

1 1 KOBAYASHI Shinji
h1. CM Plan
2
3
openEHR リリース 1.0	パブリックコメント
4
5
openEHR 	Release 1.0	public comment
6
7
8
openEHR 変更マネジメント計画
9
編集:{ T Beale} 
10
校訂版:1.0
11
頁数:37
12
13
The openEHR Change Management Plan
14
Editor:{T Beale}1
15
Revision: 1.0
16
Pages: 37
17
18
© 2003-2006 openEHR 財団
19
openEHR財団 
20
 は、消費者と医療者との保健医療記録共有の実現をオープンソースによる標準化を通じて推進する、独立した非営利のコミュニティです。
21
創設者会長 David Ingram, ロンドン大学医療情報学教授, CHIME.
22
創設メンバー P Schloeffel 博士, S Heard 博士, D Kalra 博士, D Lloyd 氏, T Beale 氏
23
email: info@openEHR.org web: http://www.openEHR.org
24
25
© 2003-2006 The openEHR Foundation
26
The openEHR foundation
27
is an independent, non-profit community, facilitating the creation and sharing
28
of health records by consumers and clinicians via open-source, standardsbased
29
implementations.
30
Founding		David Ingram, Professor of Health Informatics, CHIME, University
31
Chairman		College London
32
Founding Members	Dr P Schloeffel, Dr S Heard, Dr D Kalra, D Lloyd, T Beale
33
email: info@openEHR.org web: www.openEHR.org
34
 
35
著作権についての注意事項
36
	© openEHR 財団 2001-2005
37
	無断複写・転載を禁じます。
38
# この文書は、openEHR財団が全世界に所有する著作権乃至データベース権によって、保護されています。
39
# 個人的、非商業的な使用のために、本文書を読み、印刷することができます。
40
# この文書(全体または一部)を、商業上の使用でなく、且つopenEHRについてコメントするか、openEHRの目標を追求するか、またはopenEHRについて第三者に知らせる目的である限り、プレゼンテーションおよび教育のために使用することができます。
41
# 本文書の使用にあたって、(第2項および第3項に基づき許容されるものを除き)いかなる変更、修正、追加、削除も行ってはならない。
42
# この文書を使用する場合は必ず、次の様式の著作権表示を行わなければならない。
43
“© Copyright openEHR Foundation 2001-2005. All rights reserved. www.openEHR.org”
44
# この文書は、学術コミュニティ向けのサービスおよび非商業的利用のために提供されている。したがってopenEHR財団は、その資料や文書とそれらの内容に関し、関係法令が許す限り、何ら責任を負うことは無く、何の保証もしない。
45
# 上記第1項から第6項に掲げる事由以外で、このサイトの資料や文書を、商業利用、ライセンス化、販売、配布、使用、複写することを希望する場合は、openEHR有償商業利用ライセンスの規約と条件に従うか、そうした活動を規定するopenEHR財団との個別的な同意文書を締結しなければならない。openEHR有償商業利用ライセンスの規約と条件は、次のURL:http://www.openehr.org/free_commercial_use.htm に掲載されている。
46
47
48
Copyright Notice
49
© Copyright openEHR Foundation 2001 - 2005
50
All Rights Reserved
51
# This document is protected by copyright and/or database right throughout the world and is owned by the openEHR Foundation.
52
# You may read and print the document for private, non-commercial use.
53
# You may use this document (in whole or in part) for the purposes of making presentations and education, so long as such purposes are non-commercial and are designed to comment on, further the goals of, or inform third parties about, openEHR.
54
# You must not alter, modify, add to or delete anything from the document you use (except as is permitted in paragraphs 2 and 3 above).
55
# You shall, in any use of this document, include an acknowledgement in the form:
56
"© Copyright openEHR Foundation 2001-2005. All rights reserved. www.openEHR.org"
57
# This document is being provided as a service to the academic community and on a non-commercial basis. Accordingly, to the fullest extent permitted under applicable law, the openEHR Foundation accepts no liability and offers no warranties in relation to the materials and documentation and their content. 
58
# If you wish to commercialise, license, sell, distribute, use or otherwise copy the materials and documents on this site other than as provided for in paragraphs 1 to 6 above, you must comply with the terms and conditions of the openEHR Free Commercial Use Licence, or enter into a separate written agreement with openEHR Foundation covering such activities. The terms and conditions of the openEHR Free Commercial Use Licence can be found at http://www.openehr.org/free_commercial_use.htm
59
60
修正記録
61
版番号	内容	修正者	完了日付
62
リリース 1.0
63
1.0	リリース版の細部を更新。	T Beale	2006.1.28
64
0.9	派生版へ移管したことによる変更。	T Beale	2005.7.28
65
0.8	『openEHRの概観』文書を分離。	T Beale	2005.2.04
66
0.7	管理、IP、プロジェクト概観の項目を追加。	T Beale
67
M Darlison	2005.1.10
68
0.6	UCLチームによる見直し。	D Kalra
69
T Austin
70
N Lea
71
D Lloyd
72
T Beale	2004.12.10
73
0.5.2	David Ingram教授(UCL)による見直し。	D Ingram	2004.2.20
74
0.5.1	Tim Cook Tim@openparadigms.com による再度の見直し。	T Cook	2003.12.10
75
0.5	ARB業務による開発の進展。	T Beale	2003.12.06
76
0.4	Tim Cook Tim@openparadigms.com による見直し;更なる開発。	T Cook
77
T Beale	2003.11.22
78
0.3	openEHR CMサイト公開準備のための更新。	T Beale	2003.11.15
79
0.2	5月のUCL訪問を更新。	T Beale	2003.5.13
80
0.1	最初の記載	T Beale	2003.1.20
81
謝辞
82
 この論文は、ロンドン大学(UCL)とオーシャン・インフォマティクス社(オーストラリア)の出資を受けています。
83
84
Amendment Record
85
 
86
Acknowledgements
87
This paper has been funded by The University College, London and Ocean Informatics, Australia.
88
89
 
90
目次
91
1 はじめに
92
1.1 目的
93
1.2 読者
94
1.3 状態
95
1.4 用語と略号
96
2 あらまし
97
2.1 活動
98
2.2 マネジメント
99
3 openEHR 技術プロジェクト
100
3.1 仕様プロジェクト
101
3.2 参照実装プロジェクト
102
3.2 特別暫定実装プロジェクト
103
4 文書保管組織
104
4.1 リポジトリ命名規則
105
4.2 リポジトリ設計
106
5 リリース管理
107
5.1 あらまし
108
5.2 リリース構造と分岐
109
5.3 リリース命名規則
110
111
Table of Contents
112
1 Introduction.............................................................................. 7
113
1.1 Purpose...................................................................................................7
114
1.2 Audience ................................................................................................7
115
1.3 Status......................................................................................................7
116
1.4 Terms and Acronyms .............................................................................7
117
2  Overview ................................................................................... 8
118
2.1 Activities ................................................................................................8
119
2.2 Management...........................................................................................8
120
3 openEHR Technical Projects................................................. 12
121
3.1 The Specification project .....................................................................12
122
3.2 Reference Implementation Projects .....................................................14
123
3.3 Ad hoc Implementation Projects..........................................................14
124
4 Repository Organisation ........................................................ 16
125
4.1 Repository Naming ..............................................................................16
126
4.2 Repository Design................................................................................16
127
5  Release Management ............................................................. 18
128
5.1 Overview..............................................................................................18
129
5.2 Release Structure and Branching .........................................................18
130
5.3 Release Naming ...................................................................................20
131
132
6 変更マネジメント
133
6.1 あらまし
134
6.2 変更プロセス
135
6.2.1 あらまし
136
6.2.2 問題の報告
137
6.2.3 openEHR参照プロジェクトのための変更請求プロセス
138
6.2.3.1 業務手順
139
6.2.3.2 CRライフサイクル
140
6.2.3.3 プロジェクト・グループ-管理されたCR
141
6.2.3.3 レビュー委員会-管理されたCR
142
6.2.4 アドホックプロジェクトのための変更請求プロセス
143
6.2.4.1 業務手順
144
6.2.4.2 CRライフサイクル
145
6.2.4.3 CRマネジメント
146
147
6 Change Management  ............................................................. 21
148
6.1 Overview..............................................................................................21
149
6.2 The Change Process.............................................................................22
150
6.2.1 Overview........................................................................................22
151
6.2.2 Problem Reporting.........................................................................23
152
6.2.3 Change Request Process for openEHR Reference Projects...........23
153
6.2.3.1 Workflow ....................................................................................................23
154
6.2.3.2 CR Lifecycle ...............................................................................................24
155
6.2.3.3 Project Group-managed CRs ......................................................................25
156
6.2.3.4 Review Board-managed CRs ......................................................................25
157
6.2.4 Change Request Process for ad hoc Projects .................................26
158
6.2.4.1 Workflow ....................................................................................................26
159
6.2.4.2 CR Lifecycle ...............................................................................................27
160
6.2.4.3 CR Management .........................................................................................27
161
162
163
7 ツール類
164
7.1 あらまし
165
7.2 設定マネジメントシステム
166
7.3 PR / CRデータベース
167
7.4 発行 / 配布
168
8 CIの識別
169
付録A 様式集
170
A.1 問題報告書様式
171
A.2 PR様式フィールド
172
A.3 変更請求様式
173
A.4 CR様式フィールド
174
175
7 Tools......................................................................................... 29
176
7.1 Overview..............................................................................................29
177
7.2 Configuration Management System ....................................................29
178
7.3 PR / CR Database ................................................................................30
179
7.4 Publishing/Distribution........................................................................30
180
8 CI Identification ..................................................................... 31
181
Appendix AForms ............................................................................ 33
182
A.1 Problem Report Form ..........................................................................33
183
A.2 PR Form Fields ....................................................................................33
184
A.3 Change Request Form..........................................................................34
185
A.4 CR Form Fields....................................................................................34 
186
187
 
188
1 はじめに
189
1.1 目的
190
 この文書の目的はopenEHR技術プロジェクト、つまり(文書『openEHRのご紹介』で解説された)openEHR技術スペース上でopenEHR開発環境により遂行されるプロジェクトのマネジメントを解説することにある。これらのプロジェクトには「管理された」成果物と、この文書によって定義された明確な問題報告と変更請求の戦略がある。二つの変更マネジメント戦略は、一つは参照プロジェクトのための「審査委員会」により行うもの、もう一つは特別暫定プロジェクトのための「審査委員会」なしで行うもの、と説明される。
191
192
1 Introduction
193
1.1 Purpose
194
The purpose of this document is to describe the management of openEHR technical projects, i.e. projects in the openEHR technical space (as described in the document Introducing openEHR) and carried out within the openEHR development environment. These projects have “controlled” deliverables, and a clear problem reporting and change request strategy, defined by this document. Two change management strategies are described: one with a “review board” for reference projects, and one without, for ad hoc projects.
195
196
1.2 読者
197
 この文書の主たる読者は、openEHR財団のための仕様とソフトウェアの開発者である。
198
1.3 状態
199
 この文書は、http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/CM/CM_plan.pdf で入手できる。
200
 この文書の最新版は、http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf にある。
201
202
1.2 Audience
203
The primary audience for this document is developers of specifications and software for the openEHR Foundation.
204
1.3 Status
205
This document is available at http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/CM/CM_plan.pdf.
206
The latest version of this document can be found at http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf.
207
208
1.4 用語と略号
209
ARB (Architectural Review Board) アーキテクチャ審査委員会
210
CI (Configuration Item) 作物。例えば文書、ソース・ファイル、テスト事例など
211
CM (Configuration Management) 設定管理
212
IP (Intellectual property) 知的財産
213
PG (Project Group) プロジェクト・グループ
214
215
1.4 Terms and Acronyms
216
ARB Architectural Review Board
217
CI Configuration Item - any controlled artifact, such as a document, source file, test
218
case etc.
219
CM Configuration management
220
IP Intellectual property
221
PG Project Group
222
223
 
224
2 あらまし
225
2.1 活動
226
 下図は、仕様および実装プロジェクトと、配布・展開活動を含む、openEHRの技術的活動領域を図示している。
227
228
   技術的活動
229
			仕様類
230
   仕 様				アーキテクチャ	   ITSs
231
 プロジェクト		 要求事項
232
					適合性
233
234
   実 装	   E H R	人口管理	アーキテクチャ	
235
 プロジェクト	 サーバー	サーバー	解析プログラム	  ・・・
236
 										
237
  配 布		    各 種	 標準規格  適合性  教 育
238
  活 動	 ツール類  システム  業務提携  試 験  訓 練
239
図1 openEHR技術的活動
240
241
2 Overview
242
2.1 Activities
243
	The figure below illustrates the technical activity areas of openEHR, including specification and implementation projects, and delivery/deployment activities.
244
 
245
246
 図の左側の実線で囲まれている枠が、それぞれ一つのopenEHRプロジェクトである。図示したとおり、仕様、実装、知識、配布という4つの大きな活動領域がある。最初の2領域は、多くの人々がソフトウェア開発とみなしていることに対応し、その変更マネジメントが、この文書の主題である。これら2領域のプロジェクトは、第3節の12頁で更に詳しく説明している。
247
248
	Each solid-line bubble on the left part of the diagram is a project in openEHR. As shown, there are four major areas of activity: specification, implementation, knowledge, and delivery. The first two correspond to what most people would think of as software development; their change management is the subject of this document. The projects in these two groups are described in more detail in section 3 on page 12.
249
250
251
2.2 マネジメント
252
 openEHRの技術的空間では、プロジェクト・グループ(PGs)によって作業が行われ、場合によっては、アーキテクチャ審査委員会(ARB)がそれらを監督している。ARBは8名、またはそれ以上のopenEHRの国際的メンバーで構成され、全員が医療情報の分野で長い経験を持っている。ARBの現在の構成は、openEHRウエブサイトのARB pageでみることができる。ARBの役割は、あるプロジェクトに大きなインパクトがあるか、またはプロジェクト開発グループがそれ自身では解決できない変更を要求することについて、判断することである。決定は、単純多数決の方法で行っている。
253
254
2.2 Management
255
	In the technical space of openEHR, work is performed by project groups (PGs), which are in some cases overseen by the Architectural Review Board (ARB). The ARB consists of a eight or more international members of openEHR, all with long-term experience in an area of health informatics. The current makeup of the ARB may be found on the openEHR website ARB page. The ARB’s function is to review and make decisions on requests for change that either have significant impact on a project, or that cannot be resolved by the project development group on its own. It operates using simple majority voting.
256
257
258
プロジェクトの種類
259
 プロジェクト・グループは、一つのプロジェクトで行われる作業に責任を持つ開発者の集まりである。openEHR技術プロジェクトには、参照プロジェクトと、アドホック(臨時暫定)プロジェクトの二種類がある。参照プロジェクトでは、コミュニティが製品を開発し適合性を試験する「公式な」基盤を形成するための、参照成果物を開発する。全ての参照プロジェクトは、担当するプロジェクト・グループとARBにより変更が管理される。
260
261
Project types
262
	Project groups are groups of developers responsible for the work done on a project. There are two kinds of openEHR technical project - reference projects, and ad hoc projects. Reference projects develop reference deliverables, which constitute the “official” basis for the community to develop and test the conformance of products. All reference projects are change managed by their project group and the ARB.
263
264
 他方、アドホックopenEHRプロジェクトは参照仕様や実装を開発することはなく、ARBの関与なしに変更管理ができる。アドホック・プロジェクト・グループは、大抵は自薦によって構成される。あるグループに対して参加することを知らせれば、誰でも既存のプロジェクトのメンバーになることができ、関係するリポジトリ(電子書庫)で変更を行う権利が与えられる。openEHR技術空間でのマネジメント概観図を、以下の図2に示す。本図では、参照プロジェクト・グループは審査委員会に線でつないで示されるが、アドホック・プロジェクトはつながれていない。
265
266
	Ad hoc openEHR projects on the other hand do not generate reference specifications or implementations, and can be change-managed without recourse to the ARB. Ad hoc project groups will most likely be self-selecting. Anyone can become a member of a project by making themselves known to the existing group, and being given modification rights on the relevant repository. A management view of openEHR’s technical space is illustrated in FIGURE 2 below. In this figure, reference project groups are shown connected to a board of review, while ad hoc projects are not.
267
268
269
openEHR理事会
270
	 	
271
配布活動
272
図2: openEHR技術空間でのマネジメント概観図
273
274
 
275
276
277
openEHR参照成果物
278
 openEHR技術空間で創造される成果物のなかに「参照成果物」がある。これら制作物:openEHR情報およびサービス・モデル仕様、XMLスキーマといった実装技術仕様(ITSs)、プログラム言語インターフェイス、openEHR用語体系、適合性テスト事例、openEHR参照実装物(例えば構文解析パーサー)は、そのカテゴリーでの決定的なインスタンスである。参照実装物は、適合性テストを目的とすると同時に、絶対的に信頼できて、繰り返し使用可能な、標準的な構成部材が必要な場合のために創造されている。全てのopenEHR参照成果物は、openEHR参照プロジェクトで創造されている。様々な種類のプロジェクトとopenEHR/非openEHRプロジェクトとの関係を、以下の図3に示す。
279
280
openEHR Reference Deliverables
281
	Some deliverables created in the openEHR technical space are “reference deliverables”. These artifacts are the definitive instance in their category: the openEHR information and service model specifications, the implementation technology specifications (ITSs) such as XML-schemas, programming language interfaces, openEHR terminology, conformance test cases and openEHR reference implementations (e.g. parsers). Reference implementations are created either for the purposes of conformance testing, or in cases where absolutely dependable, re-usable, standard components are required. All openEHR reference deliverables are created by openEHR reference projects. The relationship among various kinds of projects and openEHR/non-openEHR products is shown in FIGURE 3 below.
282
283
284
285
					  openEHR.org
286
		   openEHR			    openEHR
287
     非	   	   製品を	    openEHR	     参  照
288
  openEHR	   開発する	    アドホック	   プロジェクト
289
  プロジェクト	   その他の 	    プロジェクト		   	     openEHR
290
		  プロジェクト					     参照成果物
291
			openEHR 製品
292
図3 プロジェクトと製品との関係
293
294
 
295
296
297
openEHR技術プロジェクトの定義
298
 openEHRの旗印の下で行うマネジメント業務の目的のため、「openEHR技術プロジェクト」という観念は、このマネジメント計画に従うあらゆるプロジェクトと明確に定義されている。「openEHR技術プロジェクト」は、a) 何らかの正式な方法で(典型的には、openEHRの適合基準を満たす何かを構築する目的で)openEHRに準拠しており、b) 以下に定義されるようなopenEHR.orgが提案する開発フレームワークの範囲内で作業することに同意しているものである。参照成果物を開発する全てのプロジェクトは、openEHRプロジェクトである。openEHRプロジェクト開発環境は、以下のように定義される。
299
300
Definition of an openEHR Technical Project
301
	For the purposes of managing work done under the openEHR banner, the notion of an “openEHR technical project” is explicitly defined as any project that follows this change management plan. is a) based on openEHR in some formal way (typically aims to build something that satisfies openEHR conformance criteria) and b) that agrees to do its work within the development framework offered at openEHR.org, defined below. All projects that develop reference deliverables are openEHR projects. The openEHR project development environment is defined by the following.
302
303
304
変更マネジメント
305
・標準バージョンと変更マネジメントツール/環境。この目的で、openEHRは現在、オープンソース・ツールSubversionを使用している。
306
・変更マネジメントの基本的ルール ― プロジェクトチームのメンバーのみが、a) 変更の要求、およびb) プロジェクト・リポジトリに何らかの変更を行うこと、が可能です。このことは、チームは常にその構成員を承知しており、お互いに修正を行い得ることを承認しているという意味に過ぎません。チームの非構成員で合理的な修正を望む者は、おそらくチームに参加するよう要請されます。
307
・標準的問題報告(PR)ライフサイクル。
308
・標準的変更要求(CR)ライフサイクル。
309
310
Change Management
311
• A standard version and change management toolset/environment. openEHR currently uses the open source tool Subversion for this purpose.
312
• A basic change management rule - only a member of a project team can a) create a change request, and b) make any change to the project repository. This simply means that the team always knows who is in it, and has agreed among themselves that they can make modifications. Non-team members proposing sensible modifications are likely to be asked to join the team.
313
• A standard Problem Report (PR) lifecycle.
314
• A standard Change Request (CR) lifecycle.
315
316
・CRおよびPRを作成しアクセスするための、標準オンラインツール/環境。CRが作成されたら、標準的方法により、開発者が目を通す必要があります。一方、PRが作成されたら、一定の場所で合理的な方法により、ユーザーが目を通す必要があります。PRは、ユーザーのための、公開された問題記録・報告のインターフェイスです。
317
・参照プロジェクトでは、ARBは、23ページのopenEHR参照プロジェクトのための変更請求プロセスに則って、その開発を監督します。アドホックプロジェクトの開発では、26ページのアドホックプロジェクトのための変更請求プロセスに説明される、ARBが関与しない、より簡略なプロセスが採用することが出来ます。
318
319
• A standard online tool/environment for creating and accessing CRs and PRs. CRs need to be able to be created and viewed in a standard way by developers, whilst PRs need to be created and viewed in a known place and in a sensible way by users. PRs are the public problem-logging and reporting interface for users.
320
• For reference projects, development is overseen by the ARB, according to the change management process described in Change Request Process for openEHR Reference Projects on page 23. For ad hoc projects, development may adopt the simpler non-ARB process described in Change Request Process for ad hoc Projects on page 26.
321
322
323
ビルドとリリース
324
・実装プロジェクトの最上層のディレクトリ構造は、同一でないとしても、ほぼ類似しています。
325
・(開発者が複数のプロジェクトで作業し易いように)プロジェクト間で出来るだけ同質的なビルド管理の方法。これは単一のツールが必要ということではありませんが、もしも例えばantとmakeが使用されたら、これらのツールを同様のやり方で、複数のプロジェクト間で利用すべきです。
326
・ソフトウェア、とりわけバイナリーファイルを、ユーザーに配布する標準的な方法(つまり、非ITユーザーが簡単に利用できるようにするために)。
327
328
Build and Release
329
• The top level directory structure of implementation projects is fairly similar if not the same.
330
• An approach to build management that is as far as possible homogeneous across projects (facilitates developers working on more than one project). This does not necessarily have to be a single tool, but if e.g. ant and make are used, they should be used in the same way across projects.
331
• A standard way of distributing the software to users, particularly binaries (i.e. make it easy for non-IT users).
332
333
知的財産権
334
・著作権は、openEHR財団に移転されるか、openEHR財団との共同著作権に転換されるか、または制作した機関や個人が保有するかを、選択できます。
335
・文書類(例えばマニュアル類)は、標準openEHR文書ライセンスを使用します。
336
・ソースコードは、標準openEHRオープンソースライセンスを使用します。現在、これはMozilla Tri-Lisenceですが、その実態は、ソフトウェアを使用するライセンスに即してユーザーにGPL、LGPL、またはMPLを推奨するメタ・ライセンス契約です。
337
338
Intellectual Property Rights
339
• Copyright may optionally be transferred to the openEHR Foundation, converted to joint copyright with the openEHR Foundation, or may remain with the originating organisation or author.
340
• Documents (e.g. manuals) use the standard openEHR document licence.
341
• Source code uses the standard openEHR open source licence. This is currently the Mozilla tri-license, which is really just a meta-license allowing the user to nominate GPL, LGPL, or MPL as the licence they use the software under.
342
343
・ソースコード、スキーマ、用語体系、およびその他あらゆる参照成果物について、ARBが定めるorg.openehrネームスペースの構造を尊重しなければなりません。参照プロジェクトでないものは、org.openehrネームスペースを使用することはできません。
344
・取り消し不能性:組織は openEHR環境で開発したソフトウェアやその他の成果物を、openEHR財団とコミュニティが継続使用する権利を、過去に遡って取り消すことはできません(この行為はライセンスの規定に違反することになるからです)。勿論、参加組織はそうした開発済み著作物のいずれかを、別の開発の基盤にしても構いません。この条件は、(構成要素として依存することになるであろう)コミュニティと(相当の時間と資金とを開発に費やしたであろう)開発元の組織のいずれもが、著作物へのアクセス権を失わないことを確証します;利害が一致しなくなった際には、その開発は単純に「二股」に分かれ、そしてopenEHRのフレームワーク中には、唯一本の開発ラインが残ることになります。
345
346
• Respect the structure of the org.openehr namespace by the ARB, for source code, schemas, terminologies and any other reference deliverable. Non-reference projects may not use the org.openehr namespace.
347
• Irrevocability: organisations cannot retrospectively revoke the right of the openEHR Foundation and community to continue to use software or other artifacts which they have developed within the openEHR environment (since this would contravene the terms of the license). They may of course use any such developed works as a basis for other developments. This condition ensures that neither the community (which may have come to rely on a component) nor the original developing organisation (which may have spent significant time and money on the development) lose access to the work; if the interests cease to coincide, the development is simply “forked”, and only one line remains with openEHR.
348
349
350
 これらの条項に同意するプロジェクトは、バージョン管理、複数のビルド・サーバー、1個の配布サーバーを含む、openEHRが提供する設備を利用することができます。これで特に、普通なら十分な物的資源を利用できない比較的小規模なプロジェクトの推進が、可能になります。
351
352
	Projects that agree to these items will be able to take advantage of the facilities provided by the openEHR Foundation, including version management, build servers and a distribution server. It particularly enables smaller projects to proceed where otherwise they might not have sufficient technical resources.
353
354
 この開発アプローチは、openEHRによるサービスとして提供されるもので、openEHR適合製品開発の必須条件では、勿論ありません。開発組織は、openEHR準拠製品の開発に、自らが適切と考えるどんな方法を用いても構いません。多くのプロジェクトが、企業、大学などにより、完全に商業ベースで非公開ソースによるプロジェクトを含め、それら組織自身の業務プロセスに基づいて遂行されるでしょう。
355
356
	This approach to development is offered as a service by openEHR, and of course is not a requirement of developing openEHR-compliant products. Development organisations are encouraged to develop openEHR-based products in any way they see fit. Many projects will be done by companies, universities and so on, according to their own processes, including completely commercial closed source projects.