Desktop version

Home arrow Computer Science

  • Increase font
  • Decrease font


<<   CONTENTS   >>

Software Development Kit (SDK) Agreements

Checklist

Content of SDK

□ APIs

□ Sample code

□ Sample documentation

□ Other data and information

□ Ensure IP protected

Scope of License

□ Scope

□ Internal development

□ Internal testing

□ Distributable

□ What agreement applies to distribution

□ Developer rights

Ownership

□ Company owns SDK materials

□ Modifications and derivatives

□ Company ownership of suggestions and feedback

Confidentiality

□ Testing of third-party software products

□ No representations or warranties as to compatibility

□ Confidentiality of SDK

Support

□ Not generally provided

□ If provided, precise obligations

□ No representations or warranties with respect to support services

□ As is and as available

Warranty Disclaimers

□ No warranties

□ No liability of company

□ As is, as available

Limitations of Liability

□ Complete limitation

□ Exclusion of consequential damages

□ No recovery of direct damages

□ Stop gap if unenforceable

Indemnification

□ Developer indemnification of company for all claims against company related to developer’s use of SDK

Export and Import

□ Developer’s compliance with all export and import laws

□ Indemnification for claims against company

□ Acquisition by federal government

□ Protection of IP

Term and Termination

□ Term?

□ Termination for convenience

□ Termination for breach/bankruptcy

Overview

A software development kit (SDK) is comprised of software tools and documentation that enable a third-party software developer to interface with a company’s software and/or hardware products; but does not contemplate the redistribution of any company software or products to third parties (i.e., a reseller or original equipment manufacturer (OEM) agreement would be required for any redistribution). SDKs must be provided pursuant to an SDK agreement that provides critical protections for the company’s intellectual property and ensures that the company is not exposed to undue risk as a result of permitting access to the company’s software and/or hardware products.

SDKs are generally furnished as-is under a nonnegotiable simple agreement. Tire party desiring to use the SDK must either accept the agreement without modification or, potentially, forego the opportunity.

Key Considerations and Essential Terms

SDK agreements must generally contain the following terms in order to ensure that the company’s business and legal objectives are achieved.

■ Tire SDK should include enough data and information, such as application programming interfaces (“APIs”), sample code, and documentation, to accomplish the goal of allowing third parties to develop applications to interface with company software and hardware. However, company intellectual property is a critical concern, and the company should not provide more than is necessary to accomplish this goal, particularly with respect to the company’s source code and other trade secrets.

Scope of License

■ SDK agreements should clearly specify the scope of the license being granted and what the third party can do with the SDK materials, such as APIs, sample code, and documentation. For example, certain code may be for internal development and testing only, while other code may be distributable in object code format only, but only under a separately executed OEM or reseller agreement.

■ Tire agreement should describe what products or services will be provided by the developer for interfacing with the company’s software and/or hardware.

Ownership

■ Tire company must retain ownership of all right, title, and interest in the SDK materials, and all intellectual property rights therein, including any modifications or derivatives of the SDK materials. Each SDK agreement should clearly establish the rights of ownership to the SDK materials. In addition, the company should retain the right to use and disclose any suggestions or feedback provided by the developer relating to the SDK materials or any of the company’s software or hardware products. That is, if the developer makes a suggestion for the improvement of the SDK materials, the company should have unlimited rights to use and implement that suggestion in its business.

■ In many instances, the company should consider including protection to ensure that if a third party uses the SDK to create something that the third party will not later sue the company if another licensee of the SDK chooses to do something similar or, if the company, itself, decides to do something similar. This language generally takes the form of a “non-assert,” meaning that the licensee will not attempt to assert intellectual property rights it develops using the SDK against the original company or its customers.

Confidentiality

■ Each SDK agreement should contain strong confidentiality restrictions and protections with respect to the SDK materials, particularly if any source code will be disclosed to the other party.

Compatibility Testing

■ Depending on the circumstances, the company may want to require the right to test the third party’s software/products to confirm they are compatible with the company software and/or hardware. In these circumstances, the language should clearly state that the testing is only for the company’s purposes and benefit and is not a representation or warranty to the developer or any third party (including end users) with respect to the developer’s products and/or compatibility with company’s software and hardware. In certain instances, the company may want to develop a “seal” or “certification” program under which third-party products may expressly be certified by the company as compliant with its products. These programs, however, must be carefully constructed to ensure that the company does not assume liability to end users who purchase the third party’s products and later encounter a compatibility issue.

Support

■ Support is not typically provided with the SDK. If the company is to provide support, the support obligations should be precisely defined in the SDK agreement. Any services of this kind are generally provided on a completely as-is and as-available basis.

Warranty Disclaimers

■ Since SDKs are typically provided to developers at no charge, the SDK agreement should contain very strong warranty disclaimers and limitations of liability. The SDK materials should be provided completely “as-is” with no warranties, express or implied.

Limitations on Liability

■ Companies are not generally liable for any damages whatsoever with respect to SDKs, and the SDK agreement should make this clear. Because SDKs are provided at no charge, it would be unusual and inappropriate for the company to assume liability for the SDK. This limitation of liability should apply to both consequential damages (e.g., lost profits, data loss) and any other damages, including any direct damages suffered by the developer.

■ It is important to provide a stop-gap/fail-safe measure in the event any portion of the limitation is held unenforceable (e.g., the agreement should provide a very low liability cap, such as $50).

Indemnification

■ The developer should agree to indemnify and hold the company harmless from any and all losses and third-party claims against the company relating to the developer’s use of the SDK, or any software, hardware, or services provided by the developer. The indemnity should include protections from claims by any third party to whom the developer may distribute its products and services.

Export/lmport

■ In light of certain restrictions on the export and import of software and other technology, SDK agreements should require the developer to comply with all export and import laws and to indemnify and hold the company harmless from any claims arising out of the developer’s breach of such laws.

Acquisition by Federal Government

■ Because the federal government can obtain certain rights to software provided to the government, the SDK agreement should include language protecting the proprietary nature of the company’s software.

Term and Termination

■ While not always necessary, SDK agreements may contain a term, which may be a particular period of time (e.g., one year). Unless business reasons dictate otherwise, the company should have the right to terminate the SDK agreement for its convenience (i.e., at any time, for any reason, or for no reason at all, immediately and without cause). Written notice of termination (e.g., ten business days prior to the effective date of termination) would be appropriate in some circumstances and can be considered.

■ As with many other agreements, the company should retain the right to immediately terminate the SDK agreement if the developer breaches the agreement or declares bankruptcy.

Summary

Because an SDK permits a developer to interface with a company’s software and hardware, care should be taken to ensure that the company has the appropriate protections in place to protect against the associated risks and reduce its liability. Understanding the key considerations discussed in this chapter and including the foregoing essential terms in your company’s SDK agreements can protect the company from the inherent risks associated with SDKs and the liability that could potentially arise.

 
<<   CONTENTS   >>

Related topics