BSA
Contracts - Where the Action Is †
このセクションでは技術的な契約と関連付けられる、基本的な要素のいくつかと、それに共通して見られる条件のいくつかについて概説する。
契約の基本 †
適正な契約は次の3つのことを要求する: 申し出と承諾、考慮（約因？）だ
・申し出とは、申し出る者（人または法人）が条項に合意する記述のことだ。
・承諾は申し出を指し示す被申込者の実体が申し出る者の契約案を受け入れることを指し示す時に起こる。
・考慮（約因？）は、集団において交換される価値の全てだ。技術的なライセンス契約は通常、支払い条件として考慮された特定の金銭的な形式で、次のセクションで多くの細部について論じていく。
ライセンスの条項 †
どうライセンスが合意され、条項がターキテクチャに影響を与える可能性を理解できる前に、すでに存在する種類の条項についてのアイデアを持っていないといけない。
このセクションでは技術的なライセンス契約で共通して見られる条項について記述する。
定義 †
技術的な説明はしばしば、次のようになっている。
・ソフトウェアとはライセンサーにとってオブジェクトコードソフトウェアとして所有され、価格表に記載されていることを意味する。
または次かもしれない
・ソフトウェアとはライセンサーにとってオブジェクトコードソフトウェアとして所有され、このライセンス契約の付属物として記載されることを意味する。
”記載される”ということに注意してほしい。
なぜなら定義とは特定のバージョン番号や、サポートするオペレーティングシステムなどをしばしば含むからだ。
もし、それらが定義されていなかったら、サポートやアップグレードを受け取ることができないかもしれないし、必要とする技術を提供するサプライヤーに金銭を払う別の契約を作成しないといけないかもしれない。
使用および許可 †
ライセンス下のテクノロジーを使うことができる方法。
このセクションでは契約のもっとも長い部分の一つかもしれない、またそれはここで記述する他の条項の多くをしばしば含む。
持続期間および条件、または他のキーとなる日付 †
契約の始まりと終わりについて。
マーキテクトとターキテクトが共に働き、特定の日付についての厳密な契約について交渉することでその会社にとって良い結果を作りだすことができる。
多くのライセンス契約は契約の開始と終了を以上に様々な種類の他に重要な期間を記述する。
もしそれらの期間を理解していないと、多くの代償が高いトラブルへと向かうだろう。
最小限ながら、表5-1に記載された期間について把握する必要がある。
表5-1 把握すべき期間について
期間 なぜ重要なのか
・影響期間： 影響が考えれる契約期間
・有効期限： 契約期間の終了。様々な方法により記述されるかもしれないし、絶対的なものか計算されるものかもしれない（例えば、影響期間に固定の区切りの時間をプラスしたもの）
・支払い期間： 料金の支払い期限。通常は支払い条項に沿って記載される（例えば、30日後の支払いや支払いは毎月15日か末日など）
・監査の頻度：ライセンサーがどうテクノロジーが使われたか監査できる区切り。
・契約終了の通知： 契約の終了を許可する時間。これは終了された技術をきちんとリプレイスできるに十分な期間がないといけない（多くの契約が十分に長い時間を記載していない）
・その他期間： ライセンスが依存したり、契約が必要とする幅広い種類の追加となる期間。ライセンスはきちんと定義されたスケジュールに調和した使用レポートを必要とするかもしれない。
OEMや提携契約は4半期や半期や年間の技術的なレビューを記載するかもしれない。
タイムテーブルは契約上に記載されるかもしれないニューリリースに関連付けられるし、罰則とともにそれらの期間は外されるべきだ。
高価なリニューアル †
私が仕事をしたライセンス化されたクロスプラットフォームなデータベースアクセスライブラリの製品があった。
ライセンス契約は明確に終了日時を記載していた。
終了日時が来た時、製品の開発チームはシンプルな選択をした：契約を更新するか、ライブラリを削除し製品を再開発するかだが、、
私たちは再開発することを選択したが、第一の理由はベンダーが数千ドル価格を上げたいと思っていたためだった。
私たちはまた品質を改善し、ハイパフォーマンスな実装をすでに現存する技術を組み合わせて新しいデータベースアクセスレイヤーを用いることにより実現できると思った。
がしかし、不運なことに、私たちの再開発する試みは記載されたリニューアルの日付に終了せず、ライセンス契約を更新することになり、会社に対して相当なコストとなってしまった。
この例と異なることとしては、多くの契約が自動更新であることだ。
自動更新であれば、一旦契約がサインされたら、明確にそれがキャンセルされない限り、自動更新される。
このもっとも重要なことはこれらの更新を自覚することだ。
環境が変わった場合、再契約したいと思わないほうがいいかもしれない。
テリトリー †
ライセンス化されたテクノロジーが使用されることができる適用テリトリー。
これは地理的な制限に注意を払うことが特に重要で、なぜならそれらはWebで接続された世界においては重きを置くことが非常に難しいかもしれないからだ。
特定の使用 †
開発、品質保証、テクニカルサポートやテクノロジーの商用利用などライセンス上で記載されるもの。
これはなにを契約がカバーしているか理解するために重要だ。
一般的な条項ではときには一つの契約でカバーできるかもしれないが、特定の条項では他の関連した契約でカバーすることもあることに気づくだろう。
独占 †
ライセンシーの合意が誰にでも許可されない技術の度合い。
一般的に、独占は手に入れるのが難しい、だが、手に入れる方法はある。
例として、ヨーロッパで使われることを意図しただけのキーテクノロジーを許可したいとする。
これはヨーロッパ市場にむけて独占を獲得できる可能性を持っているかもしれない。
これはまた高い料金を獲得できるかもしれない。
多くの環境では独占を必要としないかもしれないので、多くを心配しなくてよいと思う。
サブライセンス †
ライセンシーがサードパーティに技術を許可できる度合い。
サブライセンス権利は通常、組み込み技術で必要とされる。
例えば、部品情報で用いコアテクノロジーを許可を与えるとしよう。
顧客にあなたのソリューションを許可しようとしているときにとても良いチャンスで、それはテクノロジーのベンダーのサブライセンスを必要とする。
後の章でサブライセンス権利がしばしば、ターキテクチャに大きな影響をあたえることを記述する。
終了 †
片側からかもしれないの契約の終了の方法。
全ての契約には少なくとも一つの終了の条項が見られ、多くのそれがいくつかの条項を含む。
これらの条項は性能に違反があった場合に契約を破棄することをどちら側にも認めている。
性能違反とは通常、特定の状態で例えば特定の日付への納品の不履行や定義された処理要求にシステムが対応できない場合などだ。
潜在的な違反や改善策を列挙したり、記述したりすることは契約の交渉をする側面でもっとも時間がかかる作業の一つだ。
違反による契約の破棄は、考えているよりも大変で、なぜなら通常、違反からリカバリーするプロセスだからだ（救済）
多くの技術的なライセンス契約は相手側に十分に前もっての警告与えた上での契約の破棄をどちら側にも認めていて、その警告期間は少なくて30日で多い場合は1年間になる。
時間の有る限り、もっとも長い猶予を交渉しようと試みるべきだ。
ライセンス化されたテクノロジーを別のものか内製で開発されたものに置き換えるには計画されたものよりも時間がかかるからだ。
どちらかの側が破産したり、定義された財務基準に満たない場合に契約は終了することができる。片側がテクノロジーへのサポートを終了すること
を選んだ場合や、相当な管理方法の変更がある場合なども該当する（例えば競合者の技術提供者の獲得など）
契約の終了については比較的冗長になりがちだが、注意深く読む必要がある。
更新 †
技術的なライセンス契約はしばしば一つまた複数の更新条項を含む。
これらの条項は自動的かもしれない、自動更新はターキテクチャの進化に依存した高すぎる料金を会社が支払うケースも確かにあるかもしれない。
自動更新条項はセキュリティの感覚の喪失を伴う可能性もある（自動更新は自動アップグレードを意味するわけではないから）
一般的に言って、私は自動更新に対して、ライセンス契約を評価することを強く勧め、ニーズにあっているかよく確認するべきだ。
料金または、有料期間 †
正当な契約の基礎となるのは、約因のいくつかの形だ。
4章で創造的なラインセンスモデルとビジネスモデルを多くあることを述べて、全てのそれらが契約の料金のセクションで締めくくられる。
絶対的に重要なことはターキテクチャが支払い条項が必要とすることをサポートすることだ。
もし、ライセンス化されたテクノロジーが、トランザクションモデルをベースとするものの場合は、ターキテクチャはビジネスモデルをサポートする必要がある。
キーポイントとなる論点はビジネスモデルがライセンス内で必要とされるものが、あなたが顧客と使用するものと相違がある場合だ。
この相違は注意深い交渉を通してのみ解決することができ、次の章で記述する。
開発における制限 †
いくつかのラインセンス契約は一つまたは複数の開発の手段をテクノロジーに関連づけて制限している。
例としては、ベンダーが顧客による開発のためのテクノロジーを使用する契約や、ASPとして利用されることを想定したライセンス化されたテクノロジーを必要とすることがあるかもしれない。開発についてのオプションについては、詳細を7章にて記載する。
その他または一般的な制限 †
なにをしていいかを定義する追加される条項、そしてまた、なにをしていけないか注意深く定義するライセンス契約。
他の条項と共に、ターキテクチャに影響を与える可能性のあるこれらの制限条項。
一つの例としては、ランセンス化されたテクノロジーのリバースエンジニアリングや改変の形式に対する、とても共通した制限がある。
この種類の制限の現実的な影響は、驚くべきものとなりうる。
例えば、開発者がライセンス化されたコンポーネントにバグを見つけたとする。
リバースエンジニアリングに対する制限がバグを特定するためにテクノロジーを解析することの妨げとなるかもしれない。
この制限がなかったとしよう。その場合あなたは開発者にバグの調査を指示するだろう。
もし開発者が修正方法を見つけたとしても、不運なことに改変に対する制限を受けていたら、修正を適用できないだろう。
あなたが修正をサポートすることをベンダーにしか許可していなかったら、問題に対するパッチかニューリリースを待たないといけないかもしれない。
ベストは彼らの開発計画に影響を及ぼすことができることで、それができなかったら、長時間待たされることになるかもしれない。
非競合 †
ベンダーはテクノロジーが競合しない解決策を要求するかもしれない。
言い換えれば、新しい申し出をしないといけなくなるということだ。
これは馬鹿げたように聞こえるかもしれないが、新しい製品を開発しないで、新製品の中にテクノロジーを統合すると見せかけたJ2EEWebサーバライセンスようなことから人々を防ぐことができる。
この結果はオリジナルなベンダーソリューションと競合する新たなソリューションとなるかもしれない。
ソースコードへのアクセス †
技術的な契約はライセンサーが違反した場合、ソースコードのコピーを第3者を通して、ライセンシーに与えることをしばしば記載している。
持論だが、これは素晴らしいことだと思っている。なぜなら、必要とするテクノロジーにたいして完全なアクセスができることが確かに必要だからだ。
現実には、しかしながら、それは役に立たないことが多い。
例としてベンダーが違反をし、ソースコードにアクセスができたとする。
それはどうなるかというと、機会としては良いのだが、テクノロジーを管理するスタッフか必要なスキルを持っていないかもしれない。
マーケット的要求 †
契約はプレスリリースの発表か、ライセンシーかライセンサー（または両方）が彼らの他のWebサイトに製品名やコーポレートロゴの使用する権利を義務付けるかもしれない。
すべてのテクノロジーに関連するその他のマーケティングに関連する要求は一風変わっているかもしれず、注意深く読むべきだ。
マーケティングやブランディングの要求はターキテクチャに対してやっかいな驚きとなりうる。
担当者のつぶやき †
みんなの突っ込み †
