| Just about anything you can think of has, or will be, specified in a license agreement. Examples of issues that are commonly covered in license agreements that are likely to affect your tarchitecture include the following. -
Definition of technical terms: This is probably the biggest single area of license compliance and one that tarchitects should be familiar with. Do all the definitions reflect the actual product under development? Are the version numbers in the contract correct? What about the defined operating systems and operating environments? Do you have the rights to use the product in the manner envisioned by your business plan? More specifically , can you operate the in-licensed technology in a way that supports all your deployment architectures? Can you fully embed the technology in your product? What is the degree or nature of the embedding? Are there any geographic or export restrictions? -
APIs: Can you simply expose any third-party APIs provided in the license agreement? Chances are you can't, and trivially wrapping third-party APIs with your own API won't cut it. Most license agreements require you to substantially enhance the functionality of an API before it can be exposed (whatever that means). -
Support: Who fields what support questions? What kind of information must you capture and forward to the third party? License agreements can get very precise about the support information required, affecting both your tarchitecture and other corporate processes. -
Branding: Do you have to include visible or direct attribution of the third-party component? Consider the ubiquity of the "Intel Inside" marketing campaign to get a sense of just how important third-party technology suppliers consider such attributions. |