Protect Your Business Secrets: Essential Checklist for Reviewing an NDA!

A Non-Disclosure Agreement (NDA) is a legal contract that ensures that any information shared between parties remains confidential
and doesn't get shared with others.

What are the key points to consider when reviewing an NDA?

1. Parties: Identify the parties involved.

2. Purpose: Specify the transaction covered by the NDA.
3. Mutual or One-way: Consider whether the NDA should be mutual or one-sided, based on the source of confidential
information.
4. Confidential Information: Define 'Confidential Information' to cover all the proprietary information shared between parties.
5. Exclusions: Carve out exceptions to confidential information such as publicly available information which may not require
protection.
6. Confidentiality Obligations- Describe the steps to be taken by parties to prevent the disclosure of confidential information.
7. Permitted Disclosures: Check if the NDA permits the disclosure of confidential information to employees, affiliates or certain
third parties who may need to know it for the intended purpose.
8. Term and Termination: Review the adequacy of the NDA’s term and whether parties can terminate it before it expires.
9. Survival: Determine whether confidentiality obligations survive the termination of the NDA, and if so, for how long.
10. Return or Destruction of Confidential Information: Ensure the NDA requires parties to return or destroy confidential
information upon termination.
11. Remedies for Breach: Assess the available remedies for breach, such as monetary compensation or injunctions.
12. Governing Law and Dispute Resolution: Identify the governing law and dispute resolution mechanism.
13. The Wildcard- Watch out for unusual provisions like non-competes, indemnities and IPR transfers.
What are some other vital considerations while reviewing an NDA?

1. Types of IT Contracts: Software License/Assignment Agreement; IT Professional Services Agreement; Cloud Services
Agreement; Combination Agreement
2. License grants the customer rights to copy software or to exploit it in other ways. It leaves ownership with the vendor. Whereas
Assignment transfers ownership.
3. Key Considerations in Standard End User Software License-
(a) What is being licensed?- In a standard license, it’s usually enough to give the software’s name and version number and
specify object code. If the software has multiple modules which might cause dispute on what’s included, list them. Also
include manuals and documentation if customer needs to reproduce such manuals.
(b) What rights are granted?- Stick to “right to use”.
(c) “Right to reproduce”- Specifically listing reproduction rights isn’t always necessary unless customer needs to make more
copies than the vendor delivers. If the right to reproduce is granted, license should specify the number of copies. (or) In an
enterprise license model, customer can make as many copies as it needs. (or) In “client-server” model, the software sits on
a single server computer. In such case, the license may allow x number of concurrent users or x number of designated
users.
(d) End User Restrictions- Every license should confirm that the customer receives only the rights specifically granted and that
the vendor retains ownership of the software. An end user license should also list certain rights not granted (Eg- right to
sublicense, distribute, modify (create derivative works), or publicly display or perform the software). Vendors should also
consider stating that individual copies of the software are “licensed,” not “sold.”. The vendor should clarify that the
customer gets no time-sharing or service bureau rights, or any other rights to share the software with third parties. The
vendor should also be sure the license forbids reverse engineering and any other attempt to derive source code from the
 software. Finally, the vendor should be sure the customer stops reproducing and using the software when the agreement
terminates. Also, specify if it is restricted only for the customer’s internal use.
(e) Type of License- With a perpetual license, the underlying contract may terminate—ending the customer’s payment
obligations and most other promises—but the license rights last forever, unless they’re revoked. If a license is
“irrevocable,” the vendor can’t take it away, even if the customer breaches the contract. A “royalty-free” license requires no
royalty payments. That doesn’t necessarily mean the customer gets the license for free. The contract might call for a fixed
payment (in such cases, it is good to specify that the license is “fully paid”). Transferable license (Not to be confused with
sublicensable). Unrestricted license- vendor grants all unlimited rights, with a broad scope- usually granted when
customers pay for software development.
4. Key Considerations in Standard Distributor Software License-
(a) Right to Distribute the software to third parties- Geographic territory for distribution to be clearly mentioned.
(b) Some distribution licenses include limited rights to reproduce and use the software, to the extent reasonably necessary to
market the software.
(c) Exclusivity- right to distribute may be exclusive or nonexclusive. If it’s exclusive, no one, not even the vendor itself, has
the right to distribute within the territory—or anywhere if the license is worldwide.
(d) Value-added reseller (VAR)/ OEM licenses grant limited distribution rights. The distributor can only give the software out
as a component of some larger tool—often something the distributor itself produces.
(e) Distributor Restrictions- Vendor should clarify that it still owns the software and that the distributor receives only the rights
specifically granted. Vendor should forbid reverse engineering and any other attempt to derive source code from the
software. Vendor should require that the distributor have its customers sign agreements that restrict software use and
clearly mention that they get license rights (not ownership rights).
(f) Minimum obligations to distribute may be added.
5. Key Considerations in Technology Ownership: Assignment and Work-for-Hire-
(a) Ownership clauses are complicated, and a lot can go wrong, particularly for the customer. Among other issues, the
customer should satisfy itself that the vendor actually has or will have the rights it’s transferring.
(b) Key types of ownership transfers—transfer of work product specifically created for client and transfers of existing assets.
(c) Legal vehicles used in all ownership clauses: assignments and work-for-hire provisions
(d) An assignment clause transfers ownership from the vendor to the customer. A work-for-hire clause, on the other hand,
doesn’t transfer ownership because the vendor isn’t the owner and never was. Under a work-for-hire clause, the customer
owns the software from the moment it’s written, even though the vendor writes it.
(e) Customers should be sure the clause says the vendor “hereby” assigns ownership, as in the clause box, not that the vendor
“shall assign.” That latter isn’t an assignment but rather a promise to execute an assignment document in the future.
(f) Assignment clause can be used as back-up for work-for-hire incase latter can’t be enforced. In case both the assignment
and work-for-hire terms fail, customer can also ask for a backup license.
(g) Software subject to an IP ownership transfer usually includes all forms of code: object code, source code, etc. It might also
include any documentation necessary to understand the software.
6. Key Considerations in Cloud Services Contracts-
(a) Customer gets the right to access and use the software or other technology: a subscription
(b) customers should include a detailed description of the system or service
7. Key Considerations in Professional Services Contracts-
(a) programming, IT consulting, tech support and other human-based services
(b) Professional services descriptions can be task driven (favorable to vendor) or outcome driven (favorable to customer).
 (c) A clear description of the professional services helps prevent scope creep for the vendor. Customer must also ensure the
contract promises all the expected help. Keep the customer’s tasks out of the professional services description- list them
separately.
(d) Can be in the form of SOWs issued pursuant to a Master Agreement.
(e) Change Order procedures to be clearly mentioned.
8. Payment Clauses-
(a) Cloud services agreements often call for periodic payments, usually monthly or annually.
(b) Software license agreements may call for similar periodic “royalty” payments or simple one-time payment.
(c) In software development agreements, best practice for payment is through an acceptance procedure.
(d) Professional services fees can be paid all at once or on a continuing basis, just like license fees.
(e) Royalty based payment obligations- Party receiving payments should make sure the paying party has to report all sales in
detail and on a regular basis. Define “revenues” clearly- where it is gross/net; whether your figure includes sales taxes,
commissions, cost of delivery etc. Recipients paid through a percentage of revenues should also consider a minimum
royalty.
(f) Due Dates and Invoices- An invoice can either start the clock ticking on a payment obligation (or) simply remind the
customer of payment deadlines already set by the contract.
9. Technical Specifications
(a) Technical specifications describe software and computer systems. They say what the technology will do.
(b) Must be elaborated.
(c) Updates on cloud services- “Vendor may revise the Technical Specifications at any time by posting a new version at the
Specs Website and giving Customer written notice, provided no such revision may materially degrade the functionality
required by this Agreement”
10. Service Level Agreements
(a) Clause addressing the performance of a service. Might govern cloud services or a professional service.
(b) SLA is not a separate agreement. It can be a separate annexure in a service agreement