この規格ページの目次
13
X 0164-3 : 2019 (ISO/IEC 19770-3 : 2016)
図2−二つの使用権ライブラリでの割当ての例
5.3.5 移転
移転は,他の組織に権利(の一部)の所有の法的な変更を反映することが必要とされる。売却,分割又
は統合のように移転が望まれる理由は色々ある。移転が行われるとき,エンドユーザは,ソフトウェアラ
イセンス提供者との契約内で行われる権利をもっていることを確実にすることが望ましい。また,ソフト
ウェアライセンス提供者との相談によって移転の承認を得てもよい。
移転する組織は,使用権の移転によっていかなるライセンス遵守の責任ももつことはない。
移転は,異なる二つのEntのタイプを生成することで実装される(図3参照)。
− 追加Entタイプ(SupplementalEntType)は,“TransferSent”の追加Entが生成され,かつ,移転される
主Entの<entId>に等しく<linkedToPrimaryEntId>がセットされることで主Entにリンクされる。このEnt
は,移転する組織(又は送信者)によって使われる。数値は負の値であり,例えば,50の権利が移転
されたならば,数値は−50と記録される。
注記1 “allocating organization (or sender)”は,“transferring organization (or sender)”の間違いと思
われるので“移転する組織(又は送信者)”と訳した。
− 主Entタイプが“TransferReceived”の新しい<entId>。このEntは移転を受ける組織で使われる。数値
は正の値である。
――――― [JIS X 0164-3 pdf 16] ―――――
14
X 0164-3 : 2019 (ISO/IEC 19770-3 : 2016)
注記2 “the organization receiving the allocation”は,“the organization receiving the transferring”の間違
いと思われるので“移転を受ける組織”と訳した。
図3−ライセンスされた組織間の移転の例
5.3.6 統合
複数の使用権を一つにすることは,膨大なEntを一つのEntで置き換える必要性及び要望を反映してい
る。これをどのように行うかはかなりの裁量が許されており,十分に正しく,かつ,将来監査可能な文書
化が行われていることが重要である。
統合は,異なる二つのEntのタイプを生成することで実装される。
− SupplementalEntType=“ConsolidationPart”の追加Entは,統合される主Entの<entId>に等しい
<linkedToPrimaryEntId>で生成される。この追加Entは,前のEnt及び全ての追加Entを効果的に取り
消す。この処理は,統合させるそれぞれの初期(initial)Entに対して繰り返される。
− Type=“Consolidation”の主Entは,新しい<entId>で生成される。このEntは,統合が完了し,かつ,
全ての統合されるEnt及び権利が効果的に置き換えられるEntからの関連情報を全て含むことが望ま
しい。<consolidatesEntIds>と呼ばれる属性に統合化されるEntはリスト化される。
この種の処理が行われる多くの状況があり,その例を次に示す。
− ソフトウェアライセンス提供者及びエンドユーザが,監査の終了時に,全ての以前の権利に代えて,
実際の権利を書面で正式に合意する場合。
− エンドユーザ組織が,基本ライセンス(Entをもつ又はもたないにかかわらず)の詳細分析の結果を
――――― [JIS X 0164-3 pdf 17] ―――――
15
X 0164-3 : 2019 (ISO/IEC 19770-3 : 2016)
マネジメント目的のために単一のEntで表したい場合。例えば,最初にソフトウェアアセットマネジ
メントのためのシステムを構築したとき,又はスプレッドシートのような単純なツールを使っている
とき。
− 複雑な権利履歴又は法体系に直面しているエンドユーザ組織が,権利を最適化した現状のライセンス
を明確にしたい場合(例えば,アップグレード権が,特定の基本権利によってだけ明らかにされるこ
ともある。幾つかのツールは,正しく認識できない複数の異なるアップグレードパスが存在する場合
もある。)。
5.3.7 取消
全体(すなわち,主Ent及び全ての追加Ent)又は部分(すなわち,一つの追加Ent)で上記Entの幾つ
かを取り消す必要がある場合。これは,オリジナルのEntを生成するときに間違いを認識するか,又はマ
ネジメント上の決定(例えば,事後に独自の名前で権利を発注した団体に対して取り消す。)によって引き
起こされることがある。
取消は,追加Entのタイプが“Revocation”のEntを生成することで実装する。これは,
<linkedToPrimaryEntId>属性に取り消されるEntの<entId>を記述する。
5.3.8 アーカイブ
アーカイブの目的は,実稼働の利用環境からEntを除去することにある。それゆえ,権利マネジメント
の目的で実際に使われることはない。例えば,プラットフォーム又はソフトウェアアーキテクチャ変更の
ためにソフトウェアがもはや使われないという権利のためには適切である。
アーカイブ機能は,追加Entのタイプが“Archived”のEntを生成することで実装する。これは,
<linkedToPrimaryEntID>属性にアーカイブされるEntの<entId>を記述する。
注記 “which is to be revoked in”は,“which is to be archived in”の間違いと思われるので“アーカイ
ブされる”と訳した。
5.4 Entタイプ
Entのタイプは,<entType>の値で定義する。表1に取り得る値を示す。
表1−entTypeの値
entType 値 意味
Initial これは,通常,ソフトウェアライセンス提供者によって発行される最初の主Entである。
Consolidation これは,様々な他のEntを統合する主Entである。通常,エンドユーザ組織が,複数の履歴レコ
ードを置き換え,一つの新レコードを生成するため,又はライセンス遵守の監査合意の後,終
了点を記録するために使用する。根本的に,統合情報及び他のsupplementalEntType=
“ConsolidationPart”のEntに関連する多くの情報を表すことを意図しているが,他のEntに含
まれない統合に関する情報も含む。
AllocationReceived これは,他の組織から割り当てられた権利を受領した組織のために生成される主Entである。
初期(Initial)Entとほぼ同等だが,権利の所有権は,割り当てた組織にある。
TransferReceived これは,他の組織から権利の法的な移転を受けた組織によって生成される主Entである。初期
(Initial)Entとほぼ同等で,権利の所有権を反映している。しかし,ソフトウェアライセンス
提供者のレコードは,移転を示していないので,別々に識別される。それゆえ,分離したサポ
ートドキュメントが要求される権利を別々に識別することは有益である。
Supplemental これは,主Entではなく,Entが追加であるときに使われなければならない。
――――― [JIS X 0164-3 pdf 18] ―――――
16
X 0164-3 : 2019 (ISO/IEC 19770-3 : 2016)
5.5 追加Entタイプ
Entが“Supplemental”のタイプの場合,それらの区別は,“supplementalEntType”の値によって定義する。
表2に推奨される値を示す。8.7.12の“SupplementalEntType”の定義によると追加の値が定義できる。こ
れは,これらの追加の値に関する定義の共通の理解がないと思われる場合で追加Entを本当に必要とする
ところでだけ行われることが望ましい。
表2−supplementalEntTypeの値
supplementalEntTypの値 意味
InfoAdded この追加の記録は,既存のEntに情報を追加する(ただし,数量は追加しな
い。)。同じ要素又は属性(同じか又は異なる追加Entにあるかどうかにかかわ
らず)に対して異なるデータ値が追加された場合,そのデータの解釈,すな
わち,優先順位は,この規格で特定されない(誤った値又は変更された値の
追加Entは,取り消されることが望ましい。次を参照。)。
Revocation この追加Entは,既存のEntを取り消す。
取り消されたEntの<entId>は,<linkedToPrimaryEntId>属性で定義する。
<linkedToPrimaryEntId>値が,<entType>=“Supplemental”のEntを示す場合,
その追加されたEntだけが取り消される。
<linkedToPrimaryEntId>属性に示された<entId>が,<entType>=“Supplemental”
でない場合,その<entId>及び<entId>に関連する全ての追加Entは取り消され
たとみなされる。
この機能によって,全体のEnt及び関連する全ての割当てを取り消すことな
く,個々の割当てを取り消すことができる。
特定のタイプの追加Entの取消しは,他の組織のために作成された
AllocationReceived又はTransferReceivedの主Entの取消しに対して,更なるア
クションを意味することに注意する。
ConsolidationPart この追加Entは,<linkedToPrimaryEntId>属性の<entId>によって識別されるEnt
が,EntType=“Consolidation”の新しいEntに統合されていることを示す。
“ConsolidationPart”の追加Entの機能は,“Revocation”の追加Entと同様だ
が,分析(analysis)を容易にするために使われるのに対し,“Revocation”は
調停(reconciliation)に使われる。
<linkedToPrimaryEntId>属性に示される<entId>は,<entType>が“Supplemental”
であってはならない。示されたEnt,及びその<entId>に関連する全ての追加さ
れたEntは,統合されているとみなされる。
AllocationSent この追加のEntは,現在の権利が付与された組織から別の組織への割当て(数
量を伴う)が行われていることを示す。例えば,親会社が子会社にライセン
スを割り当てる場合,これが必要になる。
割当ては,権利の所有権の変更を示すものではない。<linkedToPrimaryEntId>
属性は,どのEntから割当てが行われたかを示す。
割当ては,別個の権利ライブラリをもつ組織にだけ行われることを意図して
いる。“AllocationSent”の追加Entごとに,受領組織のEntライブラリ内に作
成された<EntType>=“AllocationRecieved”の対応するEntが存在すると期待
される。
割り当てられた権利の所有権は,割り当てた組織にとどまり,通常,割り当
てられた権利に対する契約上のライセンス遵守義務も保持される。
――――― [JIS X 0164-3 pdf 19] ―――――
17
X 0164-3 : 2019 (ISO/IEC 19770-3 : 2016)
表2−supplementalEntTypeの値(続き)
supplementalEntTypの値 意味
TransferSent この追加のEntは,現在の権利が付与された組織から別の組織への移転(数量
を伴う)が行われていることを示す。例えば,親会社が他の会社としての子
会社にライセンスを売却する場合,これが要求される。
移転は,権利の所有の法的変更を示す。
<linkedToPrimaryEntId>属性は,どのEntから移転が行われたかを示す。
移転は,別個の権利ライブラリをもつ組織にだけ行われることを意図してい
る。“TransferSent”の追加Entごとに,受領組織のEntライブラリ内に作成さ
れた<EntType>=“TransferRecieved”の対応するEntが存在すると期待される。
移転された数量は,通常,初期Entのトータル数量になるが,少ない場合,例
えば,企業分割などもある。
Archived この追加Entは,既存のEntをアーカイブする。
アーカイブされるEntの<entId>は,<linkedToPrimaryEntId>属性で指定する。
<linkedToPrimaryEntId>値が<entType>=“Supplemental”であるEntを示す場合,
その追加Entだけがアーカイブされる。
<linkedToPrimaryEntId>属性で定義された<entId>が,<entType>=
“Supplemental”でない場合,その<entId>及び<entId>に関連する全ての追加
Entはアーカイブされたとみなされる。
追加Entは,Entがアーカイブされていること,実稼働環境から除去されてい
ること,したがって,もはや資格管理の目的で積極的に使用されていないこ
とを示す。これは,例えば,プラットフォーム又はソフトウェアのアーキテ
クチャが変更されたために,ソフトウェアの権利がもはや使用されなくなっ
た場合などに当てはまる。“Archived”の追加Entの効果は,“Revocation”の
効果と同じであるが,特定の目的で使われる。
<any> この規格で,まだ特定されていない追加の用途の拡張性を提供するために,
使用してもよい任意の値。
5.6 識別子の一意性
5.6.1 一般
JIS X 0164-2のように,この規格は,登録機関を要求していない。それゆえ,関連するコンテキストで
識別子の一意性を保証するためにGUIDの利用に頼っている。
5.6.2 組織登録の識別−regid
5.6.2.1 一般
この規格と同じようにJIS X 0164-2の最も重要なグローバルに一意な識別子は,組織登録の識別子,又
は“regid”である。“regid”は,一意な名前付けの権威ある識別子を提供する。
5.6.2.2 regidの構造
regidはURIリファレンス(RFC 3986を参照)を使用しなければならない。組織が当該組織のregidを
定めたならば,そのregidは,その組織によって作られる全てのEntのために一貫して使われなければなら
ない。これは,JIS X 0164-2で示されたように当該組織によって生成された全てのSWIDで使われるもの
と同じregidでなければならない。
オープンソースプロジェクトのサポート及び第三者のタグの一貫性を認める相互運用性の確保のために
は,regidを作成するときに,次の推奨事項を適用する。
− 特に断りがない限り,URIはhttpスキーマを使用する。
− httpスキーマを使用した場合,“http://”はregidの文字列から削除する(URIスキーマのない文字列は
――――― [JIS X 0164-3 pdf 20] ―――――
次のページ PDF 21
JIS X 0164-3:2019の引用国際規格 ISO 一覧
- ISO/IEC 19770-3:2016(IDT)
JIS X 0164-3:2019の国際規格 ICS 分類一覧
JIS X 0164-3:2019の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX0164-2:2018
- ソフトウェア資産管理―第2部:ソフトウェア識別タグ