As more businesses store and share data via third-party “cloud computing services”, privacy risks and Federal Trade Commission enforcement actions have also increased. Many companies’ standard vendor services contracts are woefully inadequate to address these risks. When contracting for cloud computing services, the contract should specifically describe data handling practices, security breach notification procedures, and data return requirements when the contract ends.
My colleagues Sharon Klein and Tabitha Sullivan recently wrote an article that includes tips and traps to consider when negotiating or drafting a cloud computing services contract. As they note in the article:
The scope of the cloud computing services will impact the respective responsibilities of the vendor and the customer. This contractual clarity is especially important given that most cloud computing vendors believe security of data is the customer’s responsibility, not theirs. . . . The [customer's] contracting department should work closely with the IT department to identify the company’s specific requirements and incorporate appropriate provisions to ensure the company’s needs are met.
To view the full article on the Pepper Hamilton website, click here.
Filed under: Software
Free and open source software (FOSS) offers a free, time-saving solution to many software developers. However, “free” does not always mean “without cost”. As my colleague David Wormser wrote in a recent article:
[S]ometimes even “royalty free” can be too expensive. FOSS almost invariably comes with strings attached. . . . Depending on the FOSS and the developer’s plans for it, complying with the applicable license may be relatively easy and painless. But, if it a developer wants to avoid potentially serious consequences, it needs to take a systematic approach to managing the FOSS opportunity.
The legal challenges flow from the terms of the license agreements themselves. The license agreements are essential to the developer’s legal ability to use FOSS code. . . . Each license imposes a specific set of requirements and limitations on developers wanting to modify and/or redistribute the FOSS in question. Unfortunately, from the developer’s point of view, complying with the license can be complicated, particularly when the developer intends to use in a single software product FOSS from a variety of sources.
For Dave’s full article and recommendations on how best to manage the use of open source software in your company, click here.
Philip Brooks’ Patent Infringement Updates recently posted some useful statistics about the USPTO’s issuance of software patents, along with how frequently courts have declared software patents invalid over the last few years. Interesting nuggets from the stats include:
The USPTO granted 752 software patents in 2006 — far more than in any other year. However, in 2006, the U.S. Supreme Court began to question whether the USPTO was going to too far when granting software patents, as shown by Justice Breyer’s dissenting opinion in LabCorp v. Metabolite, Inc. and Justice Kennedy’s concurring opinion in eBay, Inc. v. MercExchange, L.L.C.
After all of this, the USPTO also began to more aggressively reject claims directed to software, and the number of software patents granted dipped to 707 in 2007. The number held steady at 707 in 2008.
The Federal Circuit recently issued an opinion that refines certain standards for patent infringement. In particular, the decision in Ricoh Company, Ltd. v Quanta Computer Inc., may limit the situations under which software can directly infringe a patented method, while increasing potential liability for contributory infringement for sellers of products containing infringing components. (more…)
On October 30, 2008, the US Court of Appeals for the Federal Circuit issued its long-awaited decision in In re Bilski, which was an appeal of the USPTO’s rejection of business method patent claims as non-eligible subject matter. The decision rejected several prior tests for subject-matter eligibility and stated that a process is patent-eligible if “(1) it is tied to a particular machine or apparatus, or (2) it transforms a particular article into a different state or thing.“
The most interesting part of the Court’s decision may be its express disavowal of being the final word on the patentability of business method and software patents. The Court acknowledges the temporary nature of its decision, stating that: (more…)
A recent ruling from the US Court of Appeals for the Federal Circuit favors the ability of open source software developers to impose limits on distribution of the software by others. Specifically, the decision confirms that open source developers can enjoin further use of the software – rather than simply seek damages for breach of license terms – when others violate the terms of the open source license.
If you know what open source software is, you can skip to the next paragraph. If not, here’s a bit of background: (more…)
When a software license agreement imposes restrictions on transfer or resale of the software, is that restriction legally effective? A recent decision from a district court in the state of Washington suggests that the answer may be “no” if the license governed a transfer of a physical copy (such as a CD) of the software and did not require the transferee to return the copy at the conclusion of the contract’s term.
More on the court’s decision in Vernor v Autodesk follows below. (more…)
The Federal Circuit recently issued two opinions addressing the question of “what is a patentable invention” in the context of software and business methods. Although the opinions are not likely to cause a major change in current USPTO examination practice, they do affirm certain aspects of that practice. The cases also will guide corporate IP managers and due diligence professionals who need to examine the likelihood that a software/business method invention is patentable — or whether an issued software/business method patent is likely to withstand a challenge in the future. (more…)
In June 2007 the Free Software Foundation released version 3 of the GNU General Public License relating to open source software code. Under version 3, distributors of open source software have the option to continue distribution under GPLv2 or changing distribution to GPLv3.
When IP due diligence reveals that a software product is licensed using the GNU General Public License, the license version (GPLv2 or GPLv3) can be important. For example, GPLv3 does not permit licensed open source code to be used as a “technological measure” for controlling access to a copyrighted work. Thus, if the software product at issue includes technical features such as digital rights management (DRM) to prevent copying, GPLv3 prohibits the use of licensed open source code to achiee the DRM or similar features.
In addition, GPLv3 expressly requires a user of open source code to license any relevant patents to others who also want to use the open source code. Thus, if a software product is covered by a patent but also contains open source code, the resulting product’s code must not only be made available to others, but any patents covering the product also may be automatically licensed to others. Of course, this can significantly reduce the value of the patent.
Issues such as these may require that IP due diligence include an inquiry into which version of the GPL covers open source code. The complete text of GPLv3 is available from the GNU Project.
A common shortcut in due diligence is to give commercially-available, off-the-shelf (COTS) software a cursory review, since such licenses can easily be purchased if needed after the transaction is complete. However, if a due diligence target is out of compliance with a COTS software license, the cost to correct the noncompliance can be substantial — especially for a small company or a company that does not ensure that its employees understand the risk of noncompliance.
The U.S. Court of Appeals for the Sixth Circuit recently issued a reminder of this cost in Thoroughbred Software International v. Dice Corp. (No. 06-2080, June 14, 2007), when it considered a software license that permitted the licensee to make one backup copy of each licensed product. However, a software audit found the licensee made a 38 extra copies of one licensed product,and 31 extra copies of another product. Although most of the copies were merely residing on computers that were not being used, the court found the copies to violate the terms of the license and awarded the software company nearly $184,000 in damages. The Sixth Circuit also vacated the lower court’s denial of attorney’s fees and remanded the case to determine whether the infringing licensee should also pay the software company’s attorneys’ fees.
A few well-placed inquiries during due diligence can help to avoid headaches down the road, since in most cases software noncompliance can be corrected before a transaction is complete.
