The internet can’t review contracts for you

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.

 

 

The Internet of Things From a Software Developer’s Point of View – Part III

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.

As the product developer, what is my liability in this matter if Mildred decides to sue me? This is not a product liability case; instead, it is a breach of contract case. Whether I prevail in this matter depends largely on the language in my privacy policy. If Mildred relied on my privacy policy’s statement that her data would not be sold, I have a big problem. On the other hand, if my privacy policy stated that I planned to sell the data, Mildred is probably out of luck. (FYI, HIPAA does not control this data because I am not a health care provider.)

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.

The Internet of Things From a Software Developer’s Point of View – Part II

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
http://www.thetechlawfirm.com

The Internet of Things From a Software Developer’s Point of View – Part I

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.

Finally, under breach of warranty, the attention is not on the product or on the conduct of the developer but rather on the contract. In the case of a software product, this contract will typically be your terms of use or your licensing agreement. If a customer uses the product that is not expected by the developer, the developer will probably not be held liable for injuries. Since it is unlikely that I would have anticipated that someone would use Cat Heeler to train a parrot, I will probably not be held liable under a breach of warranty theory. I could have further protected myself by explicitly stating in the contract that the product was designed for use only with cats and that any implied warranties are disclaimed.

In summary, always keep in mind that people are probably going to use your software and products in ways you never imagined. Spend a lot of time upfront when designing your product to consider as many use cases as you can. Also, try to think of ways your client may try to use your product that are not within the scope of it functionality. Hire an attorney to help you minimize your risks by drafting strong terms of use and licensing agreements. Don’t wait until you have been sued to think about these issues!

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
donna@thetechlawfirm.com

BYOD – Resistance is Futile

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
donna.chesteen@thetechlawfirm.com

Accept it. Sometimes the file is really gone.

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. (donna.chesteen@thetechlawfirm.com)

http://www.thetechlawfirm.com

The Difficulties of Protecting Software IP

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. (donna.chesteen@thetechlawfirm.com)

http://www.thetechlawfirm.com

Don’t Mix Business With Pleasure – Part III

This is the last of a three-part series about the dangers of mixing business and pleasure with regard to social media.

When an employee joins a company, she more than likely already has accounts on most of the major social networking sites: Facebook, Twitter, LinkedIn, and, maybe, Pinterest, Google+, and some others. Not only does she already have these accounts in place but also she has probably been using them for some time before she joined your company. In this case, how you make a distinction between “personal” messaging and “business” messaging? The answer is: you probably can’t.

For this reason, your company should have strict social media policies in place. The social media policies should include the following: (1) the specific social media sites to be used for business purposes; (2) the exclusion of personal social media accounts for business purposes; (3) the creation of business-specific, business-only social media accounts; (4) the exclusion of business-specific, business-only social media accounts for personal messaging; and (5) ownership of both the social media accounts and their data.

First, the company must determine which social media outlets it considers important to its business models. Each of the social media sites has an entirely different personality and you need to decide which best fits your particular model. Once you have made this determination, you need to find out whether the employee already has an account on this social media site. If he does, you must inform him that he is not allowed to use this existing personal account for anything business related. Your social media policy must clearly articulate what is considered “business related” in this context so there is no confusion down the road. In addition, you need to “enforce” this policy by periodically sending out reminders to your employees that this policy is in place.

Next, you need to create business-specific, business-only accounts for the employee on each of the social networking sites that you have decided to use for your company.  Again, your policy must explicitly state that these accounts are for business purposes only. The policy should be very clear on what is and what is not considered appropriate content.

Your policy also needs to make it very clear that the account is owned by the company and any data related to this social media account is owned by the company NOT by the individual who is actually using the social media account. This includes but is not limited to any “followers” the user may accumulate in his employ. The policy must also include a clause that lets the employee know that, once he leaves the company, he must relinquish his password to this account and he will have no further access to it.

It is almost always better to keep your business life and your personal life separate. This is even more important when you are a business owner. Don’t muddy the waters by allowing your employees to cross-pollenate personal information in a business context or business information in a personal context. You do not want your client to have to connect the dots because he may not connect them properly. Protect your business by having appropriate policies in place to avoid mixing business with pleasure.

 – Donna M. Chesteen, Esq. (donna.chesteen@thetechlawfirm.com)
The Tech Law Firm, PLLC
http://www.thetechlawfirm.com

 

 

Don’t Mix Business With Pleasure – Part II

This is the second of a three-part series about the dangers of mixing business and pleasure with regard to social media.

So, why is so important to keep these different kinds of communication separate? There are many good reasons for this separation. Some of these reasons have legal implications and some do not but they are all important.

One of the reasons a company should keep personal messages and business messages separate is the reputation of the company.  If one of your employees posts vacation pictures of herself doing tequila shots in Mexico, it may harm the way clients look at your business. Now, instead of viewing Ms. Jones as a responsible and respected part of your team, a client may infer that her vacation behavior affects her business judgment. Even if the displayed behavior is not necessarily “bad” behavior, it may be inappropriate in a business context and clients may view it unfavorably.

Another reason for this separation is the clear impact it can have on a company’s financial health. Most companies do not have a political or social agenda. Therefore, the personal opinions and affiliations of employees may have a negative impact on the company’s bottom line. If these messages are not kept separate, a viewer does not necessarily know whether the ideology expressed in a message belongs to the company or to the individual who actually did the posting. If your company does not have a political or social agenda, you do not want the outside world to think that you do. It can cause repercussions by alienating a whole segment of your client base.

Not separating business messaging from personal messaging on social media can have major legal consequences as well.  One of these consequences has to do with the issue of data ownership. Keeping business and personal social messaging separate makes the exit of an employee easier from an administrative point of view. If this separation has always occurred, there is no need to determine who owns the data at his departure. In a recent case, a San Francisco court ruled that an employee who continued to use his employer’s Twitter account after he left the company retained custody of the followers of that account. Data ownership can also be an important issue in the event of litigation against either the company or the individual. Discovery will be much more difficult and expensive if the business data of the company and the personal data of the employee are interspersed.

In addition, an employer may be held vicariously liable for torts committed on social media by her employee. Under the doctrine of respondeat superior, an employer can be held responsible for the negligent acts or omissions of her employee if they are done in the scope of the employee’s work for the company. If business messages are commingled with personal messages, it may be difficult for the court to determine whether the employee was acting within the scope of his employment or within a personal capacity.

If messaging is not kept separately, the company may also be bound to unauthorized agreements made by an employee if an implied agency exists. An implied agency is an actual agency that can arise from the conduct of the employer if the behavior implies an intention to create an agency relationship. For this reason, it is possible that a court might find a personal agreement made by an individual on a social network binds the individual’s employer.

Lastly, there is the issue of free speech. An employee has more freedom of speech on his personal social media messages than he does if the message is the company’s message. If these types of messages are not kept separately, an individual’s speech can be attributed to the company. Where do you draw the line?

All of these are good reasons not to mix business with pleasure when it comes to social media.

 – Donna M. Chesteen, Esq. (donna.chesteen@thetechlawfirm.com)
The Tech Law Firm, PLLC
http://www.thetechlawfirm.com

Follow

Get every new post delivered to your Inbox.

Join 536 other followers