There are all kinds of do-it-yourself legal services out there today. Many people use LegalZoom® and Google® to create legal agreements to memorialize business deals with their customers and clients. (Whether this is the best way to run your business is a topic for another day.) However, one thing internet tools can’t do is review the contracts you receive from service providers. This review is necessary to make sure you are not agreeing to provisions that can potentially cost you thousands of dollars and major legal headaches in the future. For that, you must hire a real live attorney.
To better understand the problems that can arise without legal review, you must know that most contracts are written in a way that benefits the drafter. Therefore, the party that presents the agreement typically has at least a slight advantage with regard to its terms. And, if you are like most non-lawyers, you either don’t read the contract at all or you skim the first few parts and then your eyes glaze over when you get to the parts that really have the most legal significance. Even if you are diligent enough to read every word of an agreement, there are certain words that have particular significance when used in a legal context—significance that is not obvious to a person without legal education and experience.
At this point, you are probably thinking, “How bad can it be?” Well, within the past week, I have reviewed contracts with provisions so heavily weighted toward the other party that they were unreasonable for my client. These contracts were totally different in nature and were reviewed for two different clients in totally different professions. I am going to share the essence of the unfair provisions without giving enough detail to divulge any confidentiality I owe to my clients.
The first example was a provision in an NDA (non-disclosure agreement). NDAs are usually shared between parties to protect any proprietary information they must share in order to conduct business with each other. In almost all situations, the law provides that the accuser has to prove that the accused was guilty of the wrongdoing (in legal terms, the accuser has the “burden of proof”). This NDA had a provision that would have shifted the burden of proof to my client. In other words, if the other party sued him for revealing or using confidential information, my client would have had to prove that either the information shouldn’t have been classified as confidential or to prove that he didn’t reveal or use the information improperly. This is not a provision you would ever want to agree to. The person suing you should have to prove his accusations—not the other way around.
The other example was contained in an agreement for services from a software provider. Almost all contracts contain provisions for term and termination. These provisions describe how long the contract is in force (the “term”) and how a party can terminate the agreement before the end of the term. It also describes what happens if a party tries to improperly terminate a contract prematurely. In this case, the contract had a provision that said if my client tried to terminate the contract early for any reason, my client would have to immediately pay the full amount that would have been due for the full term of the contract. My client would have owed close to $50,000, if she terminated the contract early for any reason—and this is a contract that had a term of three years. It may not be obvious why this is a problem. Of course, a business needs to hold its customers to contract terms so it can create a budget and be assured it can meet its financial obligations. But, what if this service provider fails to provide the service it has promised in the contract or bills the customer for substantially more than what was agreed to? Without a modification of this provision, my client would have no recourse if the business did not fulfill its end of the deal. This is why my client should never agree to such a provision—and neither should you. If the business breached the contract, it would have cost my client a great deal of money and she would have had no legal argument against it.
There are many other situations where the provisions of a contract are weighted heavily in favor of the drafter. (For example, some employment agreements require an employee to assign all of his IP rights to the company if he creates something while in the employ of the company.) It usually requires a thorough legal review to ferret out these provisions and to negotiate terms that are fairer to both parties. Even if you are in a situation where you are dealing with a large company whose contracts are non-negotiable, you need to understand the terms before entering into a legal agreement.
The internet can do a lot of things for you but it can’t review your contracts. Hiring an attorney to do a review before you sign an agreement can save you a lot of money and headaches in the future. Consider that the next time you are asked to sign a contract.
This is the last in a three-part series about the Internet of Things (IoT) from a Software Developer’s Point of View. Last time, I discussed unavoidable bugs in your code and how those bugs impact you from a legal perspective. Before that, I talked about the inevitability that consumers will use your software in ways you didn’t intend and, in many cases, could have never predicted. This time I will talk about privacy issues that can occur in IoT especially in health-related apps and devices.
For purposes of this discussion, pretend I have created a device called Fungus Fixer. My pretend research shows that two of the major factors that cause toenail fungus are shoes that are too small and toenails that are too long. Fungus Fixer is a device that you wear on your affected toes that detects when your shoes are too small or when you need a pedicure. In addition to storing information about your shoes and toenails, Fungus Fixer also stores your name, e-mail address, and mailing address so we can send you coupons for discounts on new shoes and pedicures.
One of my customers, Mildred, is a very prominent woman in the community. She loves Fungus Fixer because she is embarrassed about her toenail fungus and also loves getting discounts for shoes and pedicures. In addition, Mildred is running for governor.
Mildred’s opponent in the gubernatorial race, Jim, is very unscrupulous and paid me to sell him all my user data. I didn’t realize he was planning to use this data to hurt his opponent. I thought he was going to use it for marketing purposes. Unfortunately for Mildred, she was ahead in the polls before Jim bought this data and published it online. Apparently no one wants a governor who has toenail fungus. Not only that, Mildred has been wearing shoes that are too small. If she is dishonest about her shoe size, what else is she being dishonest about? Citizens who gained access to her mailing and e-mail addresses from the published data have been sending Mildred toenail fungus hate mail. She doesn’t know what to do about his unwanted publicity.
This example shows you how important it is to clearly articulate how you plan to use any personal data that you collect in your app or device. It could mean the difference between winning or losing a lawsuit.
In concluding this series on IoT from a Software Developer’s Point of View, I’d like to leave you with a few take-aways. First, spend a lot of time upfront when designing your product to consider as many use cases as possible. In addition, try to come up with ways your customer may attempt to use your product that are not within the scope of its functionality. Remember all software has bugs but that is no excuse for rushing to get your product to market before you have done thorough testing. Furthermore, strong effective contracts can be your best friend when it comes to defending your products against lawsuits. Most importantly, don’t wait until you have a lawsuit to think about these issues.
This is the second in a three-part series about the Internet of Things from a Software Developer’s Point of View. In the last installation of this series, I talked about the inevitability that consumers will use your software in ways you didn’t intend and, in many cases, could have never predicted. In this entry, I will discuss the unavoidable bugs in your code and how those bugs impact you from a legal perspective. I know, I know…there are no bugs in your code! OK, we both know that isn’t true. So, what are the legal implications of these bugs and what can you do to protect yourself as a software developer?
First, let’s talk a bit about a legal word, “material.” This word has a far more important meaning in a legal context that it does in our everyday speech. In legal matters, a material defect is a defect that prevents your software from performing part of its essential functionality. For example, a cosmetic bug, such as the overlap of two words in your app is a defect but it may not be material if your app still does what the user expects it to do. However, if you have a word-processing app and it won’t let the user type in text, that is clearly a material defect.
To illustrate the risks involved with material defects in IoT software, I have created a pretend app called Breakfast Maker. Breakfast Maker runs on an Apple Watch and you can use it to schedule your coffee maker and toaster to make breakfast for you at a certain time. You just have to load the coffee maker with coffee and the toaster with your choice of bread, pastry, or bagel. When breakfast is ready, your Apple Watch wakes you up and you have hot coffee and toast waiting for you.
I have a client, John, who lives in Los Angeles. He has his Breakfast Maker scheduled to make breakfast and wake him up every weekday at 8:00AM. He went on a whirlwind trip to Florida for the weekend. He took the red-eye home on Monday morning and the flight was expected to land at 6:30AM. John thought it would be wonderful to arrive home on Monday morning to a piping hot cup of coffee and a toasted bagel so he loaded up the coffee maker and the toaster before he left for his trip. He didn’t change the schedule on Breakfast Maker because he expected to be home from the airport right about 8:00. Unfortunately, when he arrived home, his house was engulfed in flames.
What went wrong? Well, there was a bug in Breakfast Maker that didn’t take time zones into account. The scheduled time was calculated using the location of the watch instead of the location of the kitchen devices. His watch hit 8:00AM when the plane was over Dallas. When this happened, the watch automatically started the coffee maker and the toaster. Unfortunately, it was only 6:00AM in Los Angeles. In most cases, this wouldn’t have been a problem; he would have just arrived home to cold breakfast. But, this time, the bagel got stuck in the toaster and no one was there to dislodge it so it caught the toaster, and then the house, on fire.
What are my legal liabilities with respect to Breakfast Maker and this house fire? Remember in strict liability, the attention is on the product. If Breakfast Maker was defective in design and/or manufacture and it caused injury to my customer, I will have to pay damages. It doesn’t matter why the product was defective. As it turns out, Breakfast Maker was defective in design and manufacture because the software didn’t account for the watch being in a time zone that was different from the kitchen appliances. The injury to my customer was his burned-down house. Therefore, since my product was defective and my customer suffered injury, I am probably liable under a theory of strict liability.
Under the theory of negligence, attention is on the conduct of the manufacturer or seller of the product. If I failed to exercise a reasonable degree of care under the circumstances and this lack of care caused injury to my customer, I am negligent. In this case, I can probably be held liable under a theory of negligence because the defect was material and this material defect caused my customer’s house to burn down. A court will probably find that I didn’t exercise a reasonable degree of care in designing, implementing, and testing Breakfast Maker.
Finally, under the theory of breach of warranty, I may or may not be found liable based upon what warranties and what disclaimers of warranty were made in the license agreement.
In summary, all software has bugs but, as a developer, you must spend the time and money necessary to be reasonably sure your software has no material bugs. Don’t rush to get your product on the market before you have done thorough testing.
The last entry in this series will discuss privacy implications especially in apps and devices related to healthcare. Until next time…
Donna Chesteen, Esq.
The Tech Law Firm, PLLC
Every day we become more connected to the world around us through technology—the so-called “Internet of Things” or “IoT.” Fitbits help us manage our workouts. Nest thermostats allow us to control our heating and air conditioning systems from our smart phones and learns from our habits as we use them. And, LG has launched a line of appliances that allows us to start our washing machines or check to see how many eggs we have using a mobile messaging app. Even as I write this, many new disruptive technologies are on the drawing board or are about to go to market. This stuff is right out of The Jetsons. Even a few years ago, they would have been inconceivable as a reality. But, they’re here. Now.
All of these technologies make our lives easier but along with the conveniences come risks. Much has been written about the legal implications of IoT from the perspective of the end-user. This entry is the first of three that addresses the issues from a different point of view; it discusses some of the legal implications that software developers should consider when developing software for an existing device or creating a completely new device to enhance our lives.
As a software developer, there are three basic legal risks you should be aware of so you can protect yourself from liability. First, people are going to use your software in ways you never intended or even imagined. I am always amazed at how many different ways there are to accomplish a task and how creative users are. If you have ever watched someone else do something as basic as organize her e-mail, you will understand what I’m talking about. An individual’s use of a software program can be as unique as his fingerprints. There will also be those who use your software for something totally unintended.
As an example of this, let’s pretend I have created this great new device called the Cat Heeler. It is a device designed to teach your cat to heel—to walk on your left side—without the use of a leash. People train their dogs to do this all the time but it is a bit more complicated with a cat. Cat Heeler consists of a belt with a laser pointer on the left side. The cat is attracted by the laser pointer so he follows it and stays by your left side as you walk. Cats get bored easily so Cat Heeler detects when you stop and starts generating random patterns to keep the cat entertained at your side until you start to walk again.
Now imagine that Joe decided he wanted to use Cat Heeler to train his parrot Polly to heel. The product worked fine at first. Polly followed the laser pointer when Joe was walking but the problem began when Joe ran into a friend in the park. Joe had not seen this friend in many years so their conversation was quite lengthy. Remember, Cat Heeler generates random patterns when its wearer is stopped. While this functionality works great for cats, it was problematic for Polly. She intently followed these patterns while Joe was talking. When Joe finally starting walking again, Polly was dizzy and disoriented and, as a result, kept falling over. Joe rushed her to the vet’s office and even though the vet said Polly had no long-term injuries, Joe insisted she was traumatized and brought suit against me.
What are Joe’s possible causes of action against me? First, we need to discuss three broad categories of products liability lawsuits: (1) strict liability, (2) negligence, and (3) breach of warranty. With strict liability, the attention is on the product itself. Essentially that means if your product was defective in design and/or implementation and it caused injury to your customer, you may have to pay damages. It does not matter why the product was defective. In the case of Cat Heeler, Joe probably does not have a cause of action against me under the theory of strict liability because the product was not defectively designed or implemented.
Under a theory of negligence, the attention is on the behavior of the software developer. If you fail to exercise the degree of care that was reasonable under the circumstances and, by these actions, you caused injury to the user, you are negligent. I was not negligent with regard to Cat Heeler. I exercised reasonable care in designing and implementing my product and Polly’s injuries were not caused by a defect in my code.
The next entry in this series will discuss the legal implications of bugs in your code. Stay tuned…
Donna M. Chesteen, Esq.
The Tech Law Firm, PLLC
BYOD, the practice of using personal devices for business purposes, is growing by the day. When employees first started asking their employers about using these personal devices, many employers saw dollar signs. It seemed like a brilliant business decision to allow (or even to require) employees to use their own devices to do their work. They saw an opportunity to save thousands of dollars on equipment and IT costs.
Unfortunately, many of these employers did not think about the implications and BYOD has become the wild, wild west. What are the implications? One is employer’s loss of control over how, where, and when their business data is transmitted and stored. Since the employee-owned devices are not part of the business infrastructure, this control has been relinquished. This introduces more risk with regard to hacking, viruses, and IP that is being stored on a personal device, and possibly nowhere else. Another important implication is the blurring of the line between personal data and business data. This commingled data can make eDiscovery a total nightmare. These issues, along with others, may greatly reduce the perceived financial advantages of BYOD.
At this point, you may be thinking that BYOD should be prohibited altogether. However, this strategy is unlikely to work. Employees are going to use their personal devices for business-related matters whether the practice is sanctioned by the company or not. Suppose a construction manager is visiting a job site. His company does not provide tablets to its workers. The construction manager, however, has to write a report about his findings on the site. He does not want to have to handwrite all this information and then later type it into his computer. His solution? His solution is to take his personal iPad with him to the job site so he can type in his findings real time. Later he can e-mail this iPad-generated document from his personal e-mail address to his work e-mail address. This practice may leave company proprietary information on his personal iPad. In addition, he is now using his personal e-mail account to perform the duties of this job.
Another example includes a director within the organization. She hurries out the door at 5:00 so she won’t miss her son’s first baseball game. After she is several miles from work, she discovers she has left her company laptop on her desk. This is a real problem, however, because she has a deadline at 9:00AM the following morning. Her solution? Her solution is to access the information from the company’s servers through her company-issued Android phone and to e-mail it to her personal e-mail account so she can work from her personal laptop when she gets home after the ballgame.
So, what should the company do? The company should create BYOD policies to minimize the risks associated with using a personal device for business. These policies, however, should be flexible enough that employees do not try to circumvent them. If an employee uses his own device and has failed to follow the BYOD policy, he is much less likely to report that his stolen phone contains company IP or that his laptop contracted a virus and that this virus may have caused a breach of company data.
The bottom line is that BYOD, whether company-sanctioned or not, is here to stay. People love their electronic devices and use them in every walk of life. Therefore, as a company decision maker, you must minimize the risks involved in this practice by implementing flexible, effective BYOD policies that allow your employees to utilize whatever tools help them to best accomplish the company’s goals. Resistance is futile!
Donna M. Chesteen, Esq.
The Tech Law Firm, PLLC
Sometimes you just have to accept that when the producing party says the file no longer exists, it really no longer exists. Over the years, IT professionals have emphasized again and again that once something has been created electronically, it never really goes away. That is true—to a certain extent.
The problem with this theory is that it greatly oversimplifies what actually happens when you delete a file. It is true that when a file is initially deleted, its contents still exist on the hard-drive of the computer; all that happens is that the “pointer” used to show the operating system how to find the file is gone and the space where the file is stored—the slack space—is marked for reuse by the operating system. Therefore, at that point, a forensics expert may be able to examine the hard-drive and piece the file back together.
This forensic examination would always work on a computer if the hard-drive were static; in other words, this would always work if no other files were ever created or modified on that hard-drive. But every time a file is created or modified, the operating system looks for slack space on which to put it. Therefore, especially on a mostly full hard-drive, the space where the deleted file exists is likely to be at least partially overwritten every time another file is created or modified. Over time, more and more pieces of the deleted file will be replaced by other data. Once the deleted file has been overwritten, it is truly gone forever. The best forensics expert on the planet will not be able to retrieve it. Additionally, because it is very unlikely that someone will delete a file and then stop using the computer, this problem just gets worse over time. On business computers, many files are created and modified every day. And, even on personal computers, the more time that has passed since the file was deleted, the less probable it is that a forensics examination will recover a deleted file.
At this point, many people will assume they can just get the file off of backup tapes. Much of the time, this is not a solution either. Backup tapes are reused time and time again. If the file was deleted long ago (maybe even as little as a few weeks), it is likely that the tapes on which it was originally backed up have been filled with new data. Here again, once the tape has been overwritten, the file is truly gone.
This is further complicated if the files are stored in the cloud (for example, web-based e-mail clients such as gmail or cloud storage solutions such as Dropbox). These cloud servers are far more dynamic than anyone’s business or personal hard-drives and, therefore, deleted files are likely overwritten in a matter of hours. In addition, it would be virtually impossible to require a cloud provider to do a forensics analysis of one of its servers.
Therefore, sometimes you must accept the fact that a file—even one that is critical to your case—is gone forever. More and more, courts are looking to proportionality in eDiscovery. It is likely that if you request a forensic examination of your opponent’s computer, the cost will be shifted to you. In the case that the deleted file existed on a system that is extremely dynamic or the file was deleted a long time ago, this will be expensive and will still not return the evidence you are looking for. In this situation, you should use a balancing test—consider the probability that the file is still retrievable against its value to the case. In many cases, it is probably better to accept that the file is gone and instead attempt to get an adverse inference sanction by showing the court that the file was deleted in “bad faith.”
— Donna M. Chesteen, Esq. (firstname.lastname@example.org)
When the concepts of patents, copyrights, and trade secrets were conceived, software was not even an idea anyone could have fathomed. Patents typically protect “inventions” – mainly of the mechanical kind. Copyrights are best suited for writings and works of art. And trade secrets were much easier to keep secret before the digital age. So, how do you protect your software?
The protection of software is two-fold: the protection of what the program does and the protection of how the program does what it does. Theoretically a patent would be the method to protect what the program does. However, it is very difficult to patent a piece of software because the USPTO and the courts consider an algorithm an abstract idea – which isn’t patentable. In 2010, the Supreme Court held in the Bilski v. Kappos (130 S. Ct. 3218 (2010)) case that a business process is not patentable because it is an abstract idea. The Court did not, however, give guidance as to how a practitioner can determine this “abstractness.” In the past, the USPTO had looked to the machine-or-transformation test – in other words, looked to whether the software was tied to a machine and whether it transformed an object from one state into another – as the sole test in determining patentability. The Bilski Court stated that the machine-or-transformation test is an important test but not the sole one. This decision made it more difficult to determine whether a particular piece of software is patentable rather than making the decision more clear. Due to a lack of real guidance by the courts, it is hard to even determine whether your piece of software is patentable. And, even if it is, the patent process can take many years and cost lots of money to come to fruition. If you are a software entrepreneur or a programmer who works out of her living room to create a program in her “off time,” you probably cannot afford to even try to patent your program.
A copyright can help protect how your program does what it does. In other words, it can protect the expression of your idea. Someone else can write a program that achieves the same end result that yours does but the code used to accomplish that result cannot be “substantially similar” to yours. A piece of software code is like a fingerprint. Regardless of how simple the underlying concepts are, each programmer who writes the code is going to do it in his own unique style. That is how a copyright can help you. If someone else has a program whose code is too much like your code, it is very likely your copyright has been infringed. And, luckily, a copyright is created automatically whenever you type a segment of code on your computer. There are many advantages to registering your copyright but a common law copyright exists even if you fail to register.
Finally, trade secrets can be your best friends when you are trying to protect your software. A trade secret can protect your software in perpetuity – as long as you keep it a secret. If your software is being used only internally within your own organization, a trade secret can protect what your program does. If the software is being publicly distributed, a trade secret can protect how your program does what it does. If anyone misappropriates (i.e., steals) your trade secret, you have a cause of action against her. Unfortunately, courts do not consider reverse engineering to be misappropriation so if an individual discovers your trade secrets through reverse engineering, your trade secret is no longer secret and therefore your protection has been lost.
While none of these – patents, copyrights, or trade secrets – is a complete answer to software protection, there are steps you can take to protect your IP. First, try to maintain your trade secrets at least until your software is publicly released into the market. It takes a long time to go from conception to release so if you can keep your ideas and implementations trade secrets until release date, you have a head start on your competition and have the market for yourself until they can catch up. To maintain these trade secrets, have programmers and third parties sign non-disclosure agreements (NDAs) stating that they will keep this confidential information confidential.
To maintain your trade secrets for a longer period of time, you might want to consider using a code obfuscator to make your code more difficult to reverse engineer. There are some risks to using code obfuscation, however. If virus protection software detects the obfuscated code, it may flag your code as a virus. If a potential customer comes to your website and his virus protection software thinks you have a virus, the customer may leave your site and never return.
Finally, register your copyrights to give you protection against those who are infringing upon your IP. Registering a copyright is really inexpensive and can really pay off in the long run.
— Donna M. Chesteen, Esq. (email@example.com)