The Rewards and Risks of Open-Source Software

Posted on February 15, 2016 by admin

Open-source software (or “OSS”) is computer software distributed under a license whose source code is available for modification or enhancement by anyone. This is different than free (or public domain) software, which is not distributed under a license. Free and open-source software are alternatives to “closed source,” or proprietary, software.

Companies use OSS for a variety of reasons. In some cases, it’s used as part of a project deliverable, such as a DLL or a JavaScript library. In others, it’s used as a tool as part of the development process or production environment, such as a compiler, development environment, web server software, database software, etc.

The Rewards of OSS. There are significant benefits to using open-source software in your business. Here are some of the most significant:

Enhanced Security. Anyone can modify and enhance OSS, resulting in a larger developer base than proprietary software. This means that security holes are often found more quickly, and patched more quickly, than proprietary software.
Lower Cost. There is no license fee for open-source software. (That does not mean it’s totally free – OSS is subject to license requirements.)
Dev Cycle Streamlining. Using OSS in a project cuts down development time by allowing developers to avoid “reinventing the wheel” on needed code if an OSS version of that code is available.
Perpetual Use. As long as you abide by the terms of the open-source software license, you can generally use it forever. There are no annual renewal fees or license renegotiations for mission-critical software.
Adaptability/Customizability. Users of closed source software must find the software package that most closely aligns with the business’ needs, and adapt to it. There’s no need to settle with OSS – since it can be customized and adapted, you can start with the existing code and modify it to fit your company’s exact needs.
Better Quality. Since there is a larger developer base, new and enhanced features and functionality are often rolled out, and usability bugs fixed, at a more rapid rate than in proprietary software.
Support Community. Many common closed source software packages require the purchase of a maintenance subscription along with a license. Well-used OSS has a robust developer community that can help with questions.There are also companies that have sprung up around common OSS packages to provide support solutions.

Know Your OSS Licenses. The author of software code owns the copyright to that code. If the author released software into the public domain, he/she is waiving his/her copyrights in that code, making it free for anyone to use. However, if someone creates a derivative work of public domain code, the new portions of code are protected by copyright, and are not in the public domain. In other words, by adding his/her own modifications, someone can take public domain software and make it proprietary.

That’s the primary difference between free software and OSS. In most cases, when an author makes his/her software code open-source, that author is allowing use of his/her copyrighted code under an open-source software license, but is not relinquishing his/her copyright. Under the OSS license, the author grants others a right to use the author’s copyrighted code to modify, copy and redistribute it, but only if they follow the terms of the open-source software license. There are hundreds (or more) open-source licenses out there. However, there are relatively few that are considered generally accepted with a strong developer community. The Open Source Foundation (OSF) categorizes the most common OSS licenses here. The most common are the GNU General Public License (GPL), the GNU Lesser General Public License (LGPL), the “New” BSD License, the “Simplified” BSD License, the MIT License, and the Apache License v2. However, not all OSS licenses are the same. There are many websites that can help you analyze the differences between OSS licenses, including tl;dr Legal and Wikipedia’s Comparison of Open-Source Software Licenses.

Many OSS licenses are “permissive” licenses, meaning that a work governed by that license (e.g., a BSD License) may be modified and redistributed under a different license as long as you comply with the requirements of the permissive license (e.g., attribution). Other OSS licenses are “copyleft” licenses. A copyleft license is one under which a work may only be used, modified or distributed if the same license rights apply to anything derived from it. The copyleft license will “infect” modifications and derivations of the source (some think of it as a “viral” license). It’s a play on words as copyright and copyleft are converse terms: copyright gives exclusive rights to a work to one person, and copyleft gives non-exclusive rights to a work to everyone. There are two types of copyleft licenses:

“Strong” copyleft licenses (e.g., the GNU GPL) state that if you modify code governed by a copyleft license, you must distribute the software as a whole under that copyleft license, or not distribute it at all.
“Weak” copyleft licenses (e.g., the GNU Lesser GPL) state that if you modify code governed by a copyleft license, portions of the software containing modifications (e.g., a software module or library) must be distributed under that copyleft license, but other portions may be distributed under a different license type.

The Risks of OSS. Due to its benefits and rewards, most companies use open-source software, whether the management and Legal teams know it or not. Quite often, developers rely on OSS to deliver software development projects on time and within budget. The bigger question is whether developers are using OSS in a way that exposes the company to risk. Unless your company has a well-defined OSS policy that has been well-communicated to the developers at your company, you’re “flying blind” when it comes to OSS usage. Here are some of the risks and considerations for companies using OSS:

OSS makes more sense for “utility layer” software needs than for “competitive/proprietary layer” software needs. Think of the software used in business as two layers. The first is software at the “utility layer” – software packages that go to the general operation of the business and its IT infrastructure, and do not give the business a competitive advantage based on the code itself. Examples are web server software, database software, and standard APIs. Above that is the software at the “competitive/proprietary layer” – software that gives your company a competitive advantage you’re your competition, or provides significant offensive or defensive IP protection. Examples are custom functionality on your website and specialized software applications. OSS makes a lot of sense at the utility layer – you don’t need something better than everyone else, just something that works and works well. Introducing OSS at the competitive/proprietary layer can be problematic as you may want to ensure the entire solution is proprietary.

You can’t get IP warranties or indemnification for OSS. When you negotiate a software license agreement for proprietary closed source proprietary code, in most cases the software licensor will provide warranties and/or indemnification against claims of IP infringement. With OSS, there is no IP warranty or indemnity. If someone introduced proprietary code into the OSS earlier in its life, you bear the risk of infringement if you use it.

Some OSS license types can snuff out IP rights to your own developed code (and even expose it). The type of OSS license governing OSS used in your business, and how you use OSS software, can directly affect your IP rights to your own developed code. If you use OSS governed by a strong copyleft license to enhance your own codebase, your entire codebase could potentially become governed by a copyleft license. This means that a savvy competitor or customer that suspected or learned of OSS in your code could send you a letter demanding a copy of your source code under the copyleft license, or just decompile it and modify it, putting you on the defensive as to why your software license should override the copyleft open source license.

If you don’t follow the license terms, you can be sued. Open source software is licensed. That means there are license terms you must follow. If you don’t, you may face litigation from competitors or others. There has been a recent upswing in litigation for breach of the terms of open source licenses, and that trend is expected to continue. For example, VMware was sued in March 2015 alleging that it violated the GNU GPL v2 license by not releasing the source code for VMware software that used OSS subject to the copyleft license.

Implement a Company-Appropriate OSS Policy. To mitigate the risks associated with OSS, all companies should implement an open-source software policy governing the when, why and how of using open-source software in the company’s codebase. Here are some important considerations:

Ensure there is alignment on the goal of the OSS policy at the outset. Different stakeholders may have different views on the goal of an OSS policy. To Legal, it make be to protect the company’s intellectual property; to IT, it may be to leverage OSS to reduce costs; to developers, it could be to ensure they are free to keep using the OSS they need to meet goals and deadlines. One thing stakeholders cannot do is go in with the mindset that OSS is bad for business or that they can keep it out of their code. OSS in business is a reality that can either be ignored or accepted. The policy’s goal should be to ensure OSS is being used effectively to advance the company’s business objectives while protecting its IP and living within its risk profile.
An OSS policy must balance the practical needs of developers with risk management. OSS is the domain of the developer, not the Legal department. While the risks are something lawyers consider, a policy written and imposed by non-developers on your developer corps will likely face an uphill battle, or worse, be viewed as “out of sync with the goals of the business” and just ignored. The attorneys’ role in creating an OSS policy is to provide guidance on the risks of OSS to the company as a whole, provide “best practices” guidance in OSS policies, and to draft the actual policy from the outline in plain English (remember, developers, not other attorneys, are the audience). IT management’s role is to provide guidance on the outside contours of the policy. Developers need to be directly involved in developing the policy itself as they are the ones using OSS in their daily work. Developers, Legal and IT should develop the company’s OSS strategy, and its OSS policy, as equal stakeholders.
- Ensure senior management buys into the policy before it is finalized; it’s important that management understand how OSS is used in the business.
- Ensure the policy covers key topics, e.g., sourcing OSS; selecting OSS code for use at the utility layer and the competitive/proprietary layer; the OSS approval process; support and maintenance requirements; redistribution; tracking OSS usage; and audits/training.
- Ensure the policy covers independent contractor developers as well as employees.
OSS code review and approval must be a streamlined process. If the review and approval process is complicated, developers will be more likely to just skip it. Make approval easy. Provide a “pre-approved list” of OSS – certain combinations of license types, utility level software categories, and/or specific code packages that only need notification of usage for tracking purposes.
- Have a simple process for vetting other usage requests, asking the critical questions (e.g., What is the name and version number of the software package for which use is requested? What license type applies? Where was the code sourced from? Will the code be modified? What is the support plan? Will the code be distributed or used internally? What is the expected usage lifetime of the code? Are there closed source alternatives? Etc.) so that the legal and business risks can be measured and balanced against the benefits of usage.
- Determine who will do the first review and escalated review (IT, Legal).
- Turn requests quickly as delays can impact development timeframes.
Keep a database of all used OSS, including where is it used and what license type applies. Knowing what OSS you’re using is critical to avoid introducing code that has a bad reputation or is governed by an OSS license your company is not comfortable with (e.g., a strong copyleft license). IT should maintain a database of OSS used by the company, including the license type for each OSS. This database is also helpful when responding to security questionnaires and is often needed in M&A due diligence.
Other Considerations. Consider conducting quarterly or semi-annual reviews of OSS usage, e.g., questionnaires to developers. Consider having developers acknowledge the OSS policy at hire, and on an annual basis. Consider conducting OSS training if your company’s learning management system (LMS) has an available course module on OSS. And most importantly, review the OSS policy no less than once a year with all stakeholders to ensure it is evolves as the world of OSS, and the company’s own needs, change over time.

Why Accessible Websites and Mobile Applications Matter

Posted on January 25, 2016 by admin

The Internet is an essential part of life in the 21st century. A 2015 Nielsen study found that people spend an average of 2.5 hours a day using smartphones and PCs to access the Internet.

Look at any website or app and think of how different the experience would be if you couldn’t see it or hear it like everyone else. The American with Disabilities Act (“ADA”) was enacted in 1990 to ensure Americans with disabilities had equal access to places and things such as government facilities and places of public accommodation. Soon after the ADA was enacted, a new communications medium arose – the World Wide Web, marking the start of the Second Age of the Internet. The question soon arose as to what extent websites were “places of public accommodation” requiring reasonable accommodations to allow use by disabled Americans under the ADA. The Department of Justice has repeatedly delayed its rulemaking on website accessibility guidelines, most recently postponing it to at least 2017. This may be due to the explosion of apps on the Internet and the corresponding decrease in website usage – a recognition that the landscape of what would be regulated is changing too rapidly at this point.

However, don’t think you’re safe to just wait for the DOJ’s guidance. Even without rules, the DOJ has gone on record stating that the ADA applies to web services. The DOJ has instituted a number of lawsuits against companies which they believe are not meeting accessibility standards, including their websites and apps. For example, in 2015 the DOJ settled with Carnival Cruise Lines requiring not only improvements in accessibility of its ships, but of its website and mobile application. Many US companies are unaware that under Section 508 of the United States Workforce Rehabilitation Act of 1973, websites and apps developed by companies receiving federal funds or under contract with a federal agency must meet certain accessibility standards. Private and government litigants continue to bring actions against companies under federal and state law for inaccessible websites – over 45 in 2015 alone, according to BNA. There have reportedly been many more demand letters sent to companies concerning digital properties allegedly inaccessible by persons with disabilities.

Despite the uncertain landscape, there is a path forward to minimize the risk that your company’s digital properties will come under scrutiny or attack. All companies, and especially those currently or prospectively doing business with the government, should make accessibility part of the calculus when designing, building, and refreshing websites and mobile applications. Here are some important considerations for companies.

(1) Ensure your web and app developers are familiar with WCAG 2.0 standards and Section 508 requirements. Although the DOJ has not yet released its own rules, they continue to use Version 2.0 of the Web Content Accessibility Guidelines (WCAG 2.0) as a de facto standard. WCAG 2.0 was released in 2008 and became an ISO standard in 2012. There are 4 core principles for web content under the guidelines: content must be Perceivable (e.g., alternatives for non-text content, alternative content presentation, separate foreground and background content, etc.); Operable (e.g., make all functionality keyboard-accessible, allow sufficient time to read content, ensure navigation and search are easily usable, etc.); Understandable (e.g., clear text content, predictable operation of web pages, etc.); and Robust (e.g., use standardized and proper tagging; ensure content can be interpreted reliably by varied user agents such as assistive technologies). While there are 3 levels of conformance with WCAG – A, AA, and AAA – AA is the most common and the one referenced in most litigation and DOJ actions. Additionally, Section 508 imposes specific obligations on software applications and operating systems and intranet and Internet websites.

It’s very likely a future version of WCAG will form a foundation of the DOJ’s guidance; the DOJ has referred to the WCAG as a recognized international industry web accessibility standard. If the DOJ’s advice aligns with this standard, it will likely mean only minor accessibility adjustments will be required by companies that are already WCAG compliant. If you have international users of your digital properties and/or an international presence, consider whether international standards such as Canada’s Standard on Web Accessibility, the UK’s Disability Discrimination Act, and France’s AccessiWeb impose any obligations above and beyond WCAG 2.0 AA.

(2) Ensure your app developers are also familiar with and OS assistive capabilities such as Google Talkback and VoiceOver for iOS. Google and iOS both have assistive software. Apple offers VoiceOver, a gesture-based screen reader integrated with iOS. Google Talkback similarly enhances Android with spoken, audible and vibration feedback to better enable use of Android devices by visually impaired persons. Your app developers should understand these and other assistive technologies available for app operating systems so they can utilize them to the fullest extent possible.

(3) Perform an accessibility audit of your digital properties. An accessibility audit will help you understand what accessibility improvements are needed to ensure WCAG 2.0 AA and Section 508 compliance, as well as the cost and resources that will be required for your company to achieve compliance. Being able to demonstrate the costs of compliance vs. some of the settlements forced by litigants and the DOJ can help add a quantifiable metric to the risk analysis. An internal audit can be helpful to ensure your internal team understands the accessibility requirements, but also consider using third party tools and partners such as SiteImprove, IBM’s Rational Policy Tester Accessibility Edition, ACCVerify, or ComplianceSherriff.

(4) Make “accessibility by design” part of your creative development process. Many of the visual design elements we take for granted, such as layouts, have a very different meaning (if any) to a visually disabled person. Audiovisual content is very different to a hearing-impaired individual – if can be very difficult for a captioned video to deliver the nuances of inflection that often go into a vocal performance. Consider the user experience of someone hearing your copy (not just reading it), or reading your video or narration (not just hearing it). Consider having your marketing and design teams use screen readers and watch captioned videos for a better understanding of that experience with their content. Include audio captions in videos or narrated presentations to assist hearing-impaired individuals. Look at what features and functionality are available to assist you with enabling accessible creative content.

(5) Make it part of your coding and testing DNA, too. Ensure your web design techniques promote accessibility. Make the WCAG 2.0 AA guidelines, Section 508 requirements, and OS assistive capability support part of your development requirements for any new coding project or project refresh. When contracting with web and app developers and with web and commerce platform vendors, ask them for examples of projects they’ve done which were assistive technology and guideline compliant, and require them to follow accessibility guidelines. Use web design tools that support and enable accessibility. When you develop customer profiles for testing, consider adding profiles for visually-impaired and hearing-impaired users.

Website and app accessibility compliance can seem daunting, but it doesn’t have to be. Knowing accessibility requirements and guidelines, and your company’s current implementation of them in their digital properties, is an important first step. Making a plan to build accessibility into your company’s design and development DNA, and implementing accessibility support and features in your digital properties, can help keep you ahead of both accessibility litigation and future government regulations.

The Fourth Age of the Internet – the Internet of Things

Posted on January 4, 2016 by admin

We are now in what I call the “Fourth Age” of the Internet. The First Age was the original interconnected network (or “Internet”) of computers using the TCP/IP protocol, with “killer apps” such as e-mail, telnet, FTP, and Gopher mostly used by the US government and educational organizations. The Second Age began with the creation of the HTTP protocol in 1990 and the original static World Wide Web (Web 1.0). The birth of the consumer internet, the advent of e-commerce, and 90’s dot-com boom (and bust in the early 2000’s) occurred during the Second Age. The Third Age began in the 2000’s with the rise of user-generated content, dynamic web pages, and web-based applications (Web 2.0). The Third Age has seen the advent of cloud computing, mobile and embedded commerce, complex e-marketing, viral online content, real-time Internet communication, and Internet and Web access through smartphones and tablets. The Fourth Age is the explosion of Internet-connected devices, and the corresponding explosion of data generated by these devices – the “Internet of Things” through which the Internet further moves from something we use actively to something our devices use actively, and we use passively. The Internet of Things has the potential to dramatically alter how we live and work.

As we move deeper into the Fourth Age, there are three things which need to be considered and addressed by businesses, consumers and others invested in the consumer Internet of Things:

The terms consumers associate with the Internet of Things, e.g., “smart devices,” should be defined before “smart device” and “Internet of Things device” become synonymous in the minds of consumers. As more companies, retailers, manufacturers, and others jump on the “connected world” bandwagon, more and more devices are being labeled as “smart devices.” We have smart TVs, smart toasters, smart fitness trackers, smart watches, smart luggage tags, and more (computers, smartphones and tables belong in a separate category). But what does “smart” mean? To me, a “smart device” is one that has the ability not only to collect and process data and take general actions based on the data (e.g., sound an alarm), but can be configured to take user-configured actions (e.g., send a text alert to a specified email address) and/or can share information with another device (e.g., a monitoring unit which connects wirelessly to a base station). But does a “smart device” automatically mean one connected to the Internet of Things? I would argue that it does not.

Throughout its Ages, the Internet has connected different types of devices using a common protocol, e.g., TCP/IP for computers and servers, HTTP for web-enabled devices. A smart device must do something similar to be connected to the Internet of Things. However, there is no single standard communications protocol or method for IoT devices. If a smart device uses one of the emerging IoT communications protocols such as Zigbee or Z-Wave (“IoT Protocols”), or has an open API to allow other devices and device ecosystems such as SmartThings, Wink or IFTTT to connect to it (“IoT APIs”), it’s an IoT-connected smart device, or “IoT device.” If a device doesn’t use IoT Protocols or support IoT APIs, it may be a smart device, but it’s not an IoT device. For example, a water leak monitor that sounds a loud alarm if it detects water is a device. A water leak monitor that sends an alert to a smartphone app via a central hub, but cannot connect to other devices or device ecosystems, is a smart device. Only if that device uses an IoT Protocol or support IoT APIs to allow it to interconnect with other devices or device ecosystems is an IoT device.

“Organic” began as a term to define natural methods of farming. However, over time it became overused and synonymous with “healthy.” Players in the consumer IoT space should be careful not to let key IoT terminology suffer the same fate. Defining what makes a smart device part of the Internet of Things will be essential as smart devices continue to proliferate.

Smart devices and IoT devices exacerbate network and device security issues. Consumers embracing the Internet of Things and connected homes may not realize that adding smart devices and IoT devices to a home network can create new security issues and headaches. For example, a wearable device with a Bluetooth security vulnerability could be infected with malware while you’re using it, and infect your home network once you return and sync it with your home computer or device. While there are proposals for a common set of security and privacy controls for IoT devices such as the IoT Trust Framework, nothing has been adopted by the industry as of yet.

Think of your home network, and your connected devices, like landscaping. You can install a little or a lot, all at one or over time. Often, you have a professional do it to ensure it is done right. Once it’s installed, you can’t just forget about it — you have to care for it, through watering, trimming, etc. Occasionally, you may need to apply treatments to avoid diseases. If you don’t care for your landscaping, it will get overgrown; weeds, invasive plants (some poisonous) and diseases may find their way in; and you ultimately have a bigger, harder, more expensive mess to clean up later on.

You need to tend your home network like landscaping, only if you don’t tend your home network the consequences can be much worse than overgrown shrubbery. Many consumers are less comfortable tinkering with computers than they are tinkering with landscaping. Router and smart device manufacturers periodically update the embedded software (or “firmware”) that runs those devices to fix bugs and to address security vulnerabilities. Software and app developers similarly periodically release updated software. Consumers need to monitor for updates to firmware and software regularly, and apply them promptly once available. If a device manufacturer goes out of business or stops supporting a device, consider replacing it as it will no longer receive security updates. Routers need to be properly configured, with usernames and strong passwords set, encryption enabled, network names (SSID) configured, etc. Consumers with a connected home setup should consider a high-speed router with sufficient bandwidth such as 802.11ac or 802.11n.

The third party managed IT services industry has existed since the Second Age. As connected homes proliferate resulting in complex connected home infrastructure, there is an opportunity for “managed home IT” to become a viable business model. I expect companies currently offering consumer-focused computer repair and home networking services will look hard at adding connected home management services (installation, monitoring, penetration testing, etc.) as a new subscription-based service.

Smart device companies need to think of what they can/can’t, and should/shouldn’t, do with data generated from their devices. IoT devices and smart devices, and connected home technologies and gateways, generate a lot of data. Smart/IoT device manufacturers and connected home providers need to think about how to store, process and dispose of this data. Prior to the Internet of Things, behavioral data was gathered through the websites you viewed, the searches you ran, the links you clicked – “online behavioral data.” The IoT is a game-changer. Now, what users do in the real world with their connected devices can translate to a new class of behavioral data – “device behavioral data.” Smart/IoT device manufacturers, and connected home providers, will need to understand what legal boundaries govern their use of device behavioral data, and how existing laws (e.g., COPPA) apply to the collection and use of data through new technologies. Additionally, companies must look at what industry best practices, industry guidelines and rules, consumer expectations and sentiment, and other non-legal contours shape what companies should and should not do with the data, even if the use is legal. Companies must consider how long to keep data, and how to ensure it’s purged out of their systems once the retention period ends.

IoT and smart device companies, and connected home service and technology providers, should build privacy and data management compliance into the design of their devices and their systems by adopting a “security by design” and “privacy by design” mindset. Consumers expect that personal data about them will be kept secure and not misused. They must ensure their own privacy policies clearly say what they do with device behavioral data, and not do anything outside the boundaries of their privacy policy (“say what you do, do what you say”). Consider contextual disclosures making sure the consumer clearly understands what you do with device behavioral data. Each new Age of the Internet has seen the FTC, state Attorneys General, and other consumer regulatory bodies look at how companies are using consumer data, and make examples of those they believe are misusing it. The Fourth Age will be no different. Companies seeking to monetize device behavioral data must make sure that they have a focus on data compliance.

Key Security Provisions for Vendor/Partner Contracts

Posted on December 14, 2015 by admin

One of the most important lessons from the 2013 Target breach was that hackers will look for the weakest link in a company’s security chain when seeking a point of entry. Often, that weakest link is the vendors and partners which integrate with your IT infrastructure or have login credentials to your systems. Target’s HVAC vendor suffered a phishing attack that resulted in hackers obtaining access credentials to Target’s network which they used as their point of entry. Companies are increasingly doing security diligence on their vendors and partners to ensure that if they have access to the company’s network or systems, they will meet minimum security requirements. It’s critical that your vendors and partners agree to minimum contractual security commitments as well. I often use a “security addendum” with controlling language to ensure that my standard provisions control over any conflicting provisions in the vendor/partner agreement, but will sometimes embed them directly into the contract.

Here are some of the provisions I like to include in vendor and partner agreements:

Definitions of Personal Information and Financial Account Information. It’s important to define what “personal information” and “financial account information” mean. In many cases, your vendor/partner’s definition of these terms may differ from yours. Ensuring you’re on the same page (e.g., you may consider IP addresses to be personal information, they do not) can be critical in the event there is an unauthorized release of information. Be careful using a list of information types as the list may change over time; instead, consider a broad definition with examples.
Credentials. If you are providing credentials to your vendor/partner to access your network or systems, or that of a third party (e.g., a marketing service, a cloud hosting environment, etc.), ensure they will only use them as required by the contract. Ensure they fall under the contractual definition of Confidential Information and will be treated as such. Access to credentials should be limited to those with a “need to know.”
Safeguards. I like to include a requirement to implement and follow administrative, physical and technical safeguards (no less rigorous than industry standard) designed to protect information and credentials. This can be a good catch-all that can be leveraged if the vendor/partner has a problem later on and did not use industry standard security safeguards. I also like to call out the importance of installing security software patches immediately to reduce the risk of an exploitable security hole. If the vendor/partner has obtained security certifications (e.g., SSAE16, ISO 27001, etc.) that you are relying on, ensure they provide evidence of current certification upon request and do not let certifications lapse during the term of the Agreement.
Anti-Phishing Training. Over 90% of hacking attacks start with a “phishing” attack. Consider specifically requiring your vendors/partners to provide anti-phishing training to all employees.
Payment Account Information. If the vendor/partner will not be handling payment account information, add an affirmative obligation that the vendor/partner will not access, use, store, or process payment account information. If you are afraid that information might be inadvertently provided to the vendor/partner, consider adding a provision stating that if any payment account information is inadvertently provided to the vendor/partner, as long as they destroy it immediately and notify your company the vendor/partner will not be in breach of the affirmative obligation not to use payment account information. If your vendor/partner will handle payment account information, ensure you have appropriate language that covers both current and future PCI-DSS (Payment Card Industry Data Security Standard) versions. If appropriate, add language making clear that payment account information will be stored in active memory only, and not stored or retained on the vendor/partner’s servers (e.g., where the payment information is “tokenized” and/or securely transmitted to your company’s own servers at the time the transaction is processed).
Information Security Questionnaire. Include the right to have the vendor/partner complete a written security questionnaire once a year signed by a corporate officer. Requiring an annual questionnaire can help identify whether your vendors/partners are on top of emerging threats and risks. If you have limited resources to conduct audits, the responses to the questionnaires can help you identify which vendors/partners may be best to audit. As part of the questionnaire, ask for copies of the vendor/partner’s disaster recovery plan and business continuity plan, and certificate of insurance for the vendor/partner’s cyber security policy if your company is named as an additional insured.
Audit Rights. Include a right to do a security audit of a vendor/partner’s information technology and information security controls. This should include the right to conduct penetration testing of the vendor/partner’s network, ideally on an unannounced basis. Make sure the vendor/partner is obligated to correct any security discrepancies found at their expense; if they don’t make corrections to your reasonable satisfaction, you should be able to exit the contract. Ensure you can use internal and third party resources to conduct the training. In addition to a right to audit on a regular basis (e.g., once per year), allow the right to audit after a security breach so you can do your own analysis of how well the vendor/partner has bulletproofed their systems in light of a breach.
Security Breach. Define what a “security breach” is (consider a broad definition that includes security incidents as well). Ensure the vendor/partner promptly notifies your company in the event of a security breach, ideally by email to a “role” mailbox or to your CIO/CTO. The vendor/partner should take any triage steps necessary to close the immediate security hole and then thoroughly review and bulletproof its systems and networks. The vendor/partner should agree to work with your company and any government entities in any investigation of the breach. Ensure that your company, not the vendor/partner, decides whether and how to communicate with affected individuals. Ensure the vendor/partner bears the costs associated with a security breach.
Preservation Notices and E-Discovery. If the records of the vendor/partner may be important if litigation is brought against your company, consider adding a clause ensuring that the vendor/partner will comply with any document preservation/litigation hold notice you provide, and that the vendor/partner will reasonably assist with electronic discovery requests. A “friendly” clause like this can help avoid issues and strain on the partnership if litigation occurs.

Once you have these provisions in your agreement, don’t forget to tie them into your risk allocation provisions. If the vendor/partner carries insurance to protect against security breaches, ensure you are an additional insured and ask for a certificate of insurance annually. Ensure your indemnification section fully covers any breach of security obligations, and consider excluding these from your limitation of liability to the greatest extent possible.

Narrowing the Knowledge Gap in Compliance Training

Posted on December 11, 2015 by admin

Last week I was fortunate to have the opportunity to join Deirdre Patten in presenting a Thomson Reuters webinar on “Narrowing the Knowledge Gap in Compliance Training.” We reviewed the why and when of compliance training, shared ideas for maximizing retention of valuable information through refresher and opportunistic training, and discussed ways to build a strong culture of compliance as part of an effective compliance program. The webcast is available for free through Thomson Reuters by clicking here.

Podcast – Implementing Compliance without Slowing Down Business

Posted on December 4, 2015 by admin

I recently had the privilege of being interviewed by Leona Lewis for ComplyEthic‘s “Masters of Disaster” podcast series, on the benefits of a “compliance by design” approach to manage risk without slowing down the business. Building strong relationships within the organization is one of the critical keys to a strong and effective compliance program. You can listen to the podcast by clicking here.

10 Common Negotiation Positions and How To Work Through Them

Posted on November 19, 2015 by admin

One of the more frustrating things to run into during a contract negotiation is the “stock position.” These are negotiation positions often used as tactics to shut down discussion on a point, or to push back on an otherwise reasonable request Part of every attorney’s job is to find and leverage ways to make the negotiation cycle more efficient. Being prepared for these 10 common negotiation positions, and knowing ways to work through them, can help you avoid a stumble on your way to the negotiation finish line.

10. It’s Locked Down (“We only send our agreement as a [PDF/locked Word document].”)
Why you hear this: Some companies try to limit redlines to their agreements by only distributing agreements as a PDF or a Word document locked against editing, making it very burdensome if you want to propose changes.
How to respond: Propose capturing any changes in an amendment or rider to keep the agreement itself as-is, but ask for a Word version so you can show the changes you’d propose be captured in the amendment or rider. If they won’t budge, consider creating your own Word version to redline (modern versions of Adobe Acrobat Pro have built-in OCR that lets you save a PDF in Word format, or you can print and then use Optical Character Recognition (OCR) to convert the PDF to an editable version). You can also create an unlocked version of a Word document for editing purposes fairly easily – see my earlier article on this topic. If you create an editable version yourself, be sure to state in your cover note when sending the agreement back that you have created a Word version solely to facilitate your and their negotiation of the agreement, and reiterate that you would be happy to capture the agreed-upon changes in an amendment or rider to the agreement.

9. Can’t Help You There (“I don’t have the authority to negotiate that.”)
Why you hear this: The person you are negotiating with either doesn’t have the authority to approve changes to this provision, or wants you to think that he/she can’t make changes to it.
How to respond: If the change is important to your company, let them know why, and ask them if they can break out to seek approval from a person with authority (you’ll hold if on a call). Alternatively, ask if the person with authority can join the conference call or meeting so you can explain the importance of the change or provision directly. If they balk, ask them to set up a follow-up call or meeting with the person with authority. If they’re bluffing, asking them to bring in someone with authority may result in a change in position.

8. We’re The Best Around (“Do you know who we are? We’re the number one [vendor/supplier/provider/client] [of/to] [thing] in the [geographic area].”)
Why you hear this: This response is the equivalent of “we’re the big fish in this pond – be lucky you’re working with us.” They’re trying to use their market position to get you to back off your position or request.
How to respond: This is one of the reasons it’s important to have a credible backup partner/supplier/vendor waiting in the wings, or at least know who the other party’s major competitors are. If your position or request is reasonable, you’ll need to stand your ground. Let them know that while you are aware they are a major player, your request is important to your company, and that you hope they can negotiate on this point. If you hold fast, you may have to drop the names of their competitors (if you know the name of a sales rep in your area, drop that) and let them know, expressly or by implication, that their willingness to work with you on this point is more important than your desire to work with the top player in the market.

7. Don’t Stop Us Now (“Why are you asking about that? You’re slowing the deal down/this [will/may] cause us to miss our [contract execution date/launch date/etc.].”)
Why you hear this: All too often, parties enter negotiation where one or both are already committed or invested in the relationship — implementation has already started, financial forecasting has already assumed the agreement is completed by a certain date, commitments regarding the agreement have been made to senior management, etc. The other side may be trying to leverage a “need for speed” on your company’s part to avoid discussion of potentially contentious or unfavorable points.
How to respond: It depends on what is more important to your company — getting the deal done quickly, or taking the time to negotiate your point. If it’s a “nice to have” point, discuss the pros and cons internally of giving on the position in the interests of time. If it’s a “must have,” call the other side’s bluff and let them know that while you understand that digging into this point may impact the negotiation or launch schedule, resolving this point must take precedence. If you do that, be aware that the other side may try to “forum shop” and reach out to one of the negotiating parties, or a superior, who they think is feeling pressure to close the deal and can exert leverage to get past this point. Propose alternative or compromise positions, and offer to work on a compromise in real-time on a call or via a WebEx or GoToMeeting session to keep the ball rolling.

6. Take Our Word For It (“I know the contract doesn’t say that, but it’s our practice.”)
Why you hear this: The contract template you are working from may be old and no longer tracks to the operational realities of the parties’ obligations and duties. It’s also used where the other side is unwilling to commit contractually to a negotiating or marketing statement or position.
How to respond: Stress that the contract needs to accurately reflect the business and operational reality of the relationship. If it’s their practice, they should be willing to give you a contractual commitment on it. If they refuse, let them know that if they can’t back up their statement with a corresponding obligation in the contract, that’s a red flag and you’ll need to discuss their position with your business team (in other words, give them a Don’t Stop Now). Consider ending the call/meeting early to huddle with your business team on this point – it can send a message to the other side that you are serious about this issue.

5. We Can’t Afford That (“That will affect our revenue recognition.”)
Why you hear this: The requested change could require them to spread the revenue across a longer period of time, or shift it from one fiscal month/quarter/year to the next. If the sales rep has already committed a contract close to the business, or is planning on it to meet quota or get bonus, this can be a major stumbling block for them. For example, a termination for convenience clause can often affect revenue recognition.
How to respond: This can be a legitimate argument. However, there is often a creative way to structure terms that meets their revenue recognition requirements yet gives your company the flexibility it needs. Put on the creativity hat and work with your business/legal counterpart, and your finance team, to try to find an alternative that will work. If not, you’ll need to stand firm and see whether they want the business even with altered revenue recognition terms.

4. You Don’t Need To See That Now (“We don’t give our [customers/partners] our [documentation/policies] before they sign the agreement.”)
Why you hear this: If an agreement has policies that apply to your company and are referenced or incorporated by reference in the agreement (e.g., Terms of Use, Terms of Service, Vendor Code of Conduct, Conflict of Interest Policy, Trademark Guidelines, etc.), taking the time to review these policies can extend the negotiation cycle. They agreement may also contain a warranty that the product or service conforms to the documentation, which you’ll need to review to understand how strong of a warranty you’re getting. If there’s anything in there that your company can’t abide by, you could be setting your company up for a problem out of the gate.
How to respond: Explain that your company can’t fully commit to an agreement until it has reviewed and signed off on all terms and policies related to the agreement. If they’re balking at providing documentation relating to a warranty section, let them know you need to see the documentation first. See if there’s a group within your company that can play “bad cop” here, e.g., “Internal Audit needs to see it before we can sign.” Consider adding a 30-day right to rescind to the agreement in your client’s favor, which lets you sign first, but lets you back out if you don’t like the terms of their policies. Search online — many times you can find a policy on the other side’s own website.

3. I Can’t Believe You Said That (“We take offense to your position that we might [lose your data/breach the warranties, etc.]”)
Why you hear this: The “rightful indignation” argument is common when the other party wants to avoid a discussion on a topic, or truly doesn’t understand why you would be asking about that. They may be confusing your risk management with an insinuation that you don’t trust they can live up to their obligations.
How to respond: Explain why the issue is important to your company. If your company has been burned by the issue in the past, or your General Counsel/management team is focused on this issue, let them know — almost every company has some hot-button issue that can impact its contract negotiations. You can also let them know you’ve seen recent articles about this issue and it’s top of mind. Be sure to stress that you’re not playing Devil’s advocate and looking at the worst-case scenario, but you’re rather be prepared for the worst and have some extra words in the contract than be caught unprepared when the unthinkable happens.

2. That Comes Later (“We will [address/schedule] [your implementation/that topic] in a [SOW/Addendum] after we sign.”)
Why you hear this: Punting on a contentious or time-consuming issue, such as ownership of deliverables, can help move the agreement to completion. Once the contract is signed, however, you may lose your leverage to negotiate that provision. Alternatively, the other party may attempt to include a provision in the SOW/Addendum that will take precedence over a corresponding provision in the base agreement, essentially renegotiating it.
How to respond: If a provision is material or critical to the agreement or to your company, insist that it’s negotiated as part of, or at the same time as, the agreement. Ensure you have a strong order of precedence clause so your negotiated wins in the agreement aren’t undone in a later document.

1. That One’s New (“No one has ever asked us for that before/we’ve never given that to anyone before.”)
Why you hear this: Unless a company is very new, it’s very uncommon that no one has ever asked for a particular request before. It’s more likely that the person you are negotiating with has never heard anyone ask for that before.
How to respond: Ask them to confirm they are saying that no contract the company has ever signed has had that provision. If they hold firm, use it as an opportunity to push for a contractual representation to that effect (putting their money where there mouth is), and/or push for a “most favored nations” (MFN) clause on that term so that if they do offer that term to anyone in the future it will be automatically incorporated into your agreement. These approaches often lead to a change of tune. They may try to limit a rep or MFN clause to similarly situated clients/partners – consider whether this makes sense.

“Consumer Disclosure Icons” in Mobile and Social Marketing

Posted on October 28, 2015 by admin

The advent of mobile and social marketing has created a significant headache for attorneys and marketers alike. The FTC has stated that consumer disclosure requirements to avoid deception (e.g., ensuring that disclosures are clear and conspicuous, are in close proximity to the statement requiring the disclosure, are sufficiently prominent, are in understandable language, are not hidden behind a non-descriptive hyperlink, etc.) apply to marketers regardless of the medium in which they are delivered. Whether you’re delivering a marketing communication via email to a desktop computer, via social media, or to a mobile or wearable device, these rules apply.

The result is an understandable tension between attorneys trying to ensure that required disclosures are being made to control risk, and marketers seeking to deliver a compelling message and CTA (call to action) in a limited amount of space. Attorneys need to partner with their marketing brethren to find creative solutions to achieve both goals.

One idea for common ground here from an industry perspective worth pitching is to develop a set of standard “consumer disclosure icons,” or CDIs, that use a single character to denote a standard marketing disclosure phrase, e.g., “additional purchase required,” “no purchase necessary,” “subscription required,” “terms and conditions apply,” “sponsored promotion,” “paid advertisement,” etc. These could be something as simple as a set of initials in a box, such as the following for “no purchase necessary”:

Using these as a single character in a standard browser font would mean each CDI only takes up one character in a text-based communication, freeing up valuable real estate for the communication itself. Each could be a hyperlink to a page with explanations of the meanings of standard CDIs. Companies would want to use them consistently, e.g., at the end of each paragraph with claims triggering a disclosure.

CDIs would not work for non-standard disclosures, and companies would need to be careful not to improperly use CDIs where a custom disclosure is required.

Through efforts such as “Operation Full Disclosure” in September 2014, the FTC is looking to the industry to demonstrate their compliance with standard consumer marketing requirements even as the medium in which these messages are delivered continues to evolve (and shrink in size). Devising a set of consumer disclosure icons for common disclosures in visual mobile and social marketing may be a solution embraceable by marketers, attorneys and regulators alike.

Revisiting Risk Management

Posted on October 12, 2015 by admin

A couple of years ago, I wrote an article on “Risk Management 101.” Risk management is not the same as risk avoidance — taking risk is an important driver of business growth. As an attorney, it’s important to recognize that “zealously representing your client” is not the same thing as insulating your client from risk. Risk in business is like risk in investing; you have to be willing to take a loss if you want to achieve solid growth, and your appetite for risk determines how much risk you’re willing to take. Any risk management decision is a decision on whether or not to proceed with a particular course of action (or inaction) given the balance between the potential benefits and the potential risks. Given the importance of risk management, I thought it was time to revisit the topic.

What to do with business risk. Once you’ve identified a business risk, there are four things you can do with it:

Mitigate it by following or implementing technical, administrative or procedural steps or safeguards, or best practices, to reduce your company’s exposure to the risk;
Shift it by making another party responsible for the risk exposure through contract terms (e.g., representations and indemnification, liquidated damages, etc., requirements to be named as an additional insured or loss payee under the other party’s insurance), or through obtaining your own insurance;
Reject it by walking away from the proposed course of action or inaction that causes the business risk; or
Accept it by proceeding with the proposed course of action or inaction knowing it could cause an exposure based on the business risk.

When faced with a business risk that calls for a risk management decision, you should first reduce the risk, then decide what to do with the remaining risk.

To reduce the risk, the attorney will partner with his or her business counterparts to mitigate and shift as much of the risk as possible. For example, the attorney will work with business owners to determine if there are procedures in place to control the risk, or whether procedures could be put in place to help control the risk. The attorney will work with the company’s insurance group to see if its insurance will cover the risk. If the risk is arising in the context of a contract, the attorney will work to incorporate risk shifting provisions into the agreement to control the risk. The goal is to reduce the risk as much as possible, but be mindful that there can be an ROI impact here. If mitigating a risk through new processes, new insurance premiums, etc. increases the cost to the business, the overall costs from taking the course of action is impacted.
Once the risk has been reduced, a decision has to be made to accept or reject the remaining risk. Unless the risk relates to a violation of law, the attorney will turn to the business decision-maker to call the ball. When presenting a risk decision to the decision-maker, (1) describe the business risk; (2) explain what risk mitigation steps will be implemented or taken; (3) explain the potential costs related to the remaining risk (both tangible, e.g., cost, and intangible, e.g., impact to the business), and the benefits of the course of action; and (4) let the business decision-maker call the ball. This way, the business decision-maker can make an informed business risk decision. The amount of detail you go into is often driven by the speed at which the decision needs to be made. If a decision must be made quickly, you may not have the time to explore risk mitigation steps first, in which case you can describe the mitigation steps that could be taken. Consider your audience — be as concise as possible in describing the costs and benefits to management. Make sure the person that is approving or rejecting the risk has the authority to do so within the organization. Lastly, the attorney and business person should ensure that the risk management decision is documented in case an issue arises later on.

What to do if a risk exposure occurs. While the initial instinct when something bad happens is to assess blame, an authorized decision-maker who makes a well-informed business risk decision should not be “thrown under the bus” if the risk exposure ultimately occurs. If proper risk management procedures are followed, the exposure should result in a review of the risk management decision to see if other “hindsight” data points would have impacted the risk management decision if known at the time, and determine if changes to the decision-making process or the company’s risk profile are appropriate on a go-forward basis. Risk exposures will happen in business. If a decision-maker is disciplined (or worse) in the event of an exposure just for making the business risk decision, even if the benefits far outweighed the potential risks at the time the decision was made, the company will send the message that good risk management practices don’t matter to management. Reward those who follow good risk management practices.

Accepting a business risk is the same thing as electing to self-insure against the risk. If you don’t identify and manage a risk, your business is accepting the entire risk without any mitigation steps. For small risks, this usually doesn’t cause a problem. For bigger risks, this can be catastrophic. Understanding, implementing, and fostering solid risk mitigation practices at your company can make all the difference.

How to stop (or start) Word redlines changing to “Author” on document save

Posted on October 1, 2015 by admin

You’ve probably noticed that in certain documents, as soon as you click “Save” all of your Word redlines change color and switch from your name to “Author.” If you’re like me, when negotiating or commenting up a document with others I prefer to “layer” redlines in different colors so everyone knows whose comments and redlines are whose. This can help avoid confusion and keep the negotiation process running as efficiently as possible. There’s nothing more frustrating than redlining a document only to find your edits changed to Author the second you save your draft. (I’ve had situations where my business team commented on a draft assuming the “Author” redlines in an agreement were my redlines, when they were really from the other side.) This author information for redlines is one example of the “metadata” that Microsoft Word saves with your document.

On the flip side, there are times you may want to remove all of the personal information in a document regarding authors (e.g., when releasing a policy or document that had multiple authors, and you don’t want to show who worked on what parts). Word includes an option in the Trust Center which lets you remove all personal information from a document upon save. If this option is selected, metadata (including names of redline owners) is stripped out of the document when it is saved. If your redlines are changing to “Author” on save, it’s because this option is turned on in your document. This is a document setting, not a global setting, so changing it for a given document changes it for that document only.

To turn on or off the removal of personal information from a document upon save in Office 2010 or 2013, follow these steps:

Click on “File,” then “Options.”
In the “Options” box, select “Trust Center” at the bottom of the left-hand menu.
In the “Trust Center” dialog box, click the “Trust Center Settings” button.
The Trust Center should open on “Privacy Options” (if not, select it). You’ll find what you are looking for under “Document-Specific Settings” – it’s the option “Remove personal information from file properties on save.”
If it’s turned on, it will look like this. To turn it off, uncheck the box, click “OK,” and close Word Options. Your redlines should now stay as-is when you save the document.
If the checkbox and option is turned off and grayed out like in the image below, you will have to do one thing before you can turn it on, you need to first run Document Inspector by pressing the button on this screen and manually remove all metadata under “Comments, Revisions, Versions and Annotations.” (You can run Document Inspector at any time to manually remove metadata from a Word document.)

Notes from the Trenches

Articles, thoughts, tips, and tricks from an veteran in-house counsel

Author Archives: admin