Data Breach Notification Laws - Not Just For California Anymore

It has now been more than five years since California became the first state to pass a data breach notification law (California SB 1386) mandating that companies notify consumers when they have lost the consumer’s personal data.  While not all states have followed suit, the folks at CSOonline have published a very handy resource showing those states that have now passed their own data breach legislation.

The research by CSOOnline reveals that 38 states that have enacted some form of data breach disclosure law. Most of these laws follow the general outline of the California law and require that companies immediately disclose a data breach to their customers. However, the laws differ in their details and in particular on issues such as:

1. Deadlines and timing requirements for informing customers of a data breach.
2. Penalties faced by companies for failure to disclose.
3. Private rights of action for customers in the case of failures to notify.
4. Exemptions in which companies need not report breaches.

Customer data is becoming an ever more valuable (and marketable) asset for all technology companies (whether or not they are operating through a software as a service business model). As this trend increases, state and federal government agencies have likewise increased their focus on the protection of that data. In the current environment, knowledge and observance of the laws governing customer/consumer data has become an essential requirement for those companies that collect, use, and mine that data as part of their business models. While CSOOnline points out that their resource is not meant to be comprehensive, it is a handy tool to help in starting to understand the legal landscape in the area of data breach notification.

McAfee Issues Risk Factor Over Open Source Licenses

Computer security firm McAfee has included a risk factor in its most recent annual report filed last month with the Securities and Exchange Commission (SEC) warning investors of potential risks posed to the company by “ambiguous” license terms governing open source software used in McAfee products. The report notes that “despite having conducted the appropriate due diligence,” these ambiguities “may result in unanticipated [licensing] obligations regarding our products. ” As the report puts it, “to the extent that we use ‘open source’ software, we face risks.” These are interesting comments indeed from a company more accustomed to issuing warnings about the dangers posed by software viruses and bugs to other companies.

McAfee appears to be particularly concerned with the terms of version 2 of the GNU General Public License (GPL), by most measures the most prevalent open source license in the world today. McAfee acknowledges use of open source software under the GPL in its annual report and notes that it perceives that there are risks posed by the fact that “the scope and requirements of the [. . . ] GPL have not been interpreted in a court of law.” They also, however, appear to acknowledge a broader scope of open source usage, indicating that “other forms” of open source software licensing present license compliance risks to McAfee which “could result in litigation or loss of the right to use this software.”

While not noted specifically in the annual report, the reference to “litigation” appears to have been prompted by the recent spate of lawsuits filed by the Software Freedom Law Center (SFLC) on behalf of its clients Erik Andersen and Rob Landley (the two principal developers of the BusyBox open source utility) alleging violations of the GPL. These suits, brought against Monsoon Multimedia, Xterasys Corporation, High-Gain Antennas, and Verizon Communications, represent the first lawsuits brought in the US to enforce the GPL (click here and here for more information about these cases). As a user of software licensed under the GPL, it appears from its annual report that McAfee considers the potential for additional suits by the BusyBox developers (or suits by the owners of other open source software used by McAfee in its products) to pose a potentially material risk to the company. Note that McAfee has also at times been an outspoken critic of open source software and the role they claim it plays in assisting hackers in the development of bots and other malware. Whether McAfee has come to perceive itself as a larger target for such suits as a result of these statements is not mentioned in their annual report.

Of course, McAfee is not the first company to include a cautionary statement regarding open source software or open source licensing in their SEC filings. For example, as InformationWeek notes in an article about McAfee, DVR-maker Tivo warned investors in its 2007 annual report that it may have to discontinue using open source software in its products due to concerns about the GPL. Likewise, many proprietary software companies have made references in their SEC filings to the risks posed by competition created by open source software. In particular, Microsoft created a stir when it noted in a prospectus filed in 2003 that, “the popularization of the open source model continues to pose a significant challenge to our business model.” McAfee itself has also included competition-related open source risk factors in previous filings, and includes one again in another section of its current annual report, warning of increasing “competition from numerous smaller companies, shareware and freeware authors and open source projects” that are developing competing products to those of McAfee.

While not unprecedented, the current filing by McAfee underscores the fact that the BusyBox cases (and the potential for other lawsuits like them) represent a series of changes ongoing in the open source software license enforcement landscape. The fact that McAfee has seen fit to include a risk factor in its annual report regarding the potential risks posed by cases such as these is a good example of how open source compliance practices are beginning to evolve to address these changes. As I have mentioned in the past, now more than ever, companies that do not take note and move to evolve their open source compliance practices to address these changes on their own terms will increasingly find themselves being required to do so on terms imposed by others. McAfee, it would appear, is not content to wait for this to happen.

 

 

 

 

Dealing with “Irrational” Negotiators

HBS Working Knowledge recently ran another useful article discussing how to deal with “irrational” negotiators — you know, the kind who in the midst of negotiations behave recklessly, seemingly without a strategy, and even act in ways that seem to contradict their own self-interests. Anyone who has faced a seemingly “irrational” party on the other side of a negotiation knows that dealing with them can be more difficult (and frustrating) than dealing with an even moderately sane individual. Rather than throwing up your hands (or throwing the nearest object across the table), the article suggests considering whether the other side is truly irrational. More often than not, the seemingly irrational behavior has a rational — albeit hidden — cause, such as a lack of accurate information, hidden constraints or hidden interests. According to the authors, the key to stopping the behavior and smoothing the negotiations requires discovering that hidden cause and working to overcome it with the other party — rather than simply dismissing it as irrational.

The article is excerpted from a book titled: Negotiation Genius: How to Overcome Obstacles and Achieve Brilliant Results at the Bargaining Table and Beyond. I have not yet picked up a copy, but based on the excerpts in this article, I have added it to my list.