Four Out of Eight Doesn’t Cut It: The IP Safeguards that Most Lawyers Miss When Protecting Software

Software is an extremely valuable good for those who produce it because it provides value to the software’s end users. That value, however, also makes it a target for those who would prefer to obtain the value without compensating the software producer. As a result, like with any valuable asset, software suppliers and Internet of Things (IoT) companies must implement safeguards to protect it. Since software is intellectual property, attorneys who work for or advise software producers (which, let’s be honest, is just about every technology company these days, given the addition of hardware manufacturers via the ubiquity of their “smart” devices to the existing desktop, mobile, and SaaS applications that we all use in both our personal and business lives), are frequently asked to advise on how to best protect this valuable asset. Unfortunately, as discussed below, most lawyers only deliver half of what they should.

Eight safeguards are essential for a full, robust software protection regime. Despite that, most lawyers talk about only four of them. In their defense, they only learned about four of them in law school, which is why that’s their go-to advice. But in today’s world, lawyers need to go beyond law school and include real-world, practical solutions to augment the legal protections that are their bread and butter. This article will review all eight, but the bulk of the discussion will illustrate the importance and usefulness of the four less-frequently discussed methods.

Legal Protections

The first four methods—which lawyers already know about and take action on—focus on protecting software from a purely legal perspective: 

1. Trade secrets: Trade secret law is the primary methodology for protecting commercial software. Essentially, this requires taking reasonable measures to keep the software a secret. This usually involves multiple steps, such as having employees sign confidentiality agreements, limiting access to the software’s source code (i.e., the human readable version of the software code) to only those who truly need access to it (hint: that probably doesn’t include the CEO or the lawyers!), compiling the code (i.e., converting the source code from human-readable code into machine-readable code before distributing it) and having customers contractually agree not to try and access the source code or reverse engineer it. While some of these steps would qualify as practical protections in and of themselves, lawyers generally recommend them in order to meet the “reasonable measures” element of trade secret law.
2. Copyrights: Software companies may also use copyright law to protect software because software is considered a literary work. To afford themselves of copyright protections, lawyers work with clients to devise the appropriate scheme, generally including a proper copyright notice in the software and registration of the copyrighted material.
3. Patents: Whether or not to patent a piece of software is a complicated topic, the bulk of which is well outside the scope of this article. That said, patents absolutely should be considered as a legal method for protecting software.
4. Contracts: Regardless of whether you use trade secret, copyright or patent law to protect your software, a contract is always involved. Even in the case of open source software (where the software’s creators make the source code available to everyone), there’s generally an open source license associated with the software that’s considered an enforceable contract. Contracts are the most widely recognized and used of these legal elements; who hasn’t clicked “I accept” to a long document no one ever reads?

Practical Protections

While each legal protection discussed above is great and must be considered, the truth is that the best outcome for the software producer is when they never have to rely on the legal protections at all. Enforcing legal rights is expensive, time consuming and distracting to a software producer that would much rather focus on developing the next product instead of defending the last one. How do you do that? How do you avoid having to actually rely on the legal protections we just laid out? By using technology to prevent the software from being misused or overused—intentionally and unintentionally—in the first place. Below are some practical solutions your clients can deploy:

5. Entitlement management: This is the first safeguard that’s less known and less commonly addressed. While a contract frequently identifies the license level the customer is entitled to (e.g., the number of users entitled to use the software or the number of devices on which the software may be installed), pulling contracts to determine what rights were granted is inefficient at best. A good entitlement management system provides easy access (for both licensee and licensor) into what’s actually owned by the licensee, when it expires, what version is available, etc. Deploying a system like this reduces the likelihood of conflict with your client’s customers by creating a shared portal that can be the single source of truth. Such a system can be a practical enforcement mechanism of the legal rights agreed to in the contract.
6. License management: Not only is tracking entitlements important, so is enforcing them. Yes, these are contractual limitations that can be enforced through legal means, but any good lawyer will tell you that the best contract is one that you sign, put in a drawer and never look at again. With software, that’s actually doable. How? By utilizing a license management system that can help enforce contractual limitations and manage customer compliance. These systems are generally able to not only programmatically limit the use of the software to the license level initially agreed to in the contract, but to change over time to keep up with changes to the customer’s usage, such as additional quantities or additional functionality not included in the initial purchase.
7. Compliance intelligence: Every lawyer loves to have belt and suspender provisions in their contracts; we all sleep better knowing that if one set of protections fails, there’s a reliable backup. Best practices for software protection take a similar approach. In addition to the license management solutions that are designed to keep honest customers honest, it’s important to consider solutions that help catch people who go around your license management solution. Compliance intelligence solutions track actual usage, enabling the software producer to monitor for piracy and other unauthorized usage. As with belts and suspenders, you don’t need both license management and compliance intelligence. But unlike with belts and suspenders, where it’s rare for you to even consider wearing both, license management and compliance intelligence are actually best when used together.

Protect Your Software Protections

The final software protection strategy is less about protection of the software producer’s rights; it’s more related to solidifying the foundation of the software producer’s products. Most commercial code today relies to some degree (and often to a great degree) on the use of open source software components. Open source software, as referenced above, is code developed by third parties and then incorporated into a software producer’s final product. While there’s usually no fee charged by the open source provider, the open source code is subject to contractual requirements. Given that this whole article is about how to protect your client’s software from misuse, it would be ironic if your client then failed to take the necessary steps to ensure it didn’t misuse open source software! Unfortunately, open source software is unmanaged by most companies. On average, most software producers are aware of and manage a mere 5% of the open source software used in their products. Failure to fully document and understand open source usage and to comply with relevant obligations can undo all of the careful work taken through the first seven safeguards above. With this in mind, the final safeguard is:

8. Software composition analysis (SCA): SCA is an automated process of evaluating open source software components within a software product; it forms the core of robust open source management processes. It can help software suppliers build a software bill of materials (i.e., a list of all the third-party software components within its product and the license associated with each one), and manage compliance with the various open source license obligations applicable to each open source component. Lest you think that doesn’t sound difficult, there are more than 200 open source licenses; each carries unique terms, rights and obligations. Without an open source management process with an SCA tool at its center, customers (particularly those who are part of or feed into a highly regulated supply chain) struggle to meet their commitments to the open source community, while also simultaneously exposing themselves to claims of breach of contract. That would be an ironic and unenviable position to be in as a software vendor—especially if they’ve gone through the myriad of steps discussed in this article to protect their own software!

In 1941, baseball’s Ted Williams of the Boston Red Sox finished the season with a .406 batting average, meaning he successfully reached base in .406 of his at bats. In the 79 years since, no one has equaled that feat, heralded as one of baseball’s unbreakable records. While that’s impressive, it means Mr. Williams failed almost 60% of the time! In the world of software protection, the good news is that most lawyers are out-hitting Ted Williams, usually deploying 50% of the protection schemes available to them. The bad news: 50% isn’t cause for celebration. Using the additional four practical protections discussed above is what will provide a comprehensive approach to protecting software. Eight out of eight—that’s something to celebrate.

Image Rights acquired by 123RF.com