150,000 Reasons to Comply With an Open Source Software License

Open source software license agreements allow you to use software for free. They tend to have a few requirements such as provide the source code to customers and transfer modifications to the source code to the community. Look at the license carefully as there are different version with different requirements. Since the license is free, you may feel there is no reason to comply with any of the terms. Since the software is free, you may think there must be no damages for the author of the software to recover. Not so.

While the software is free, damages for non compliance may seem trivial. That depends. First there is an issue whether a breach of a software license agreement is a lawsuit for breach of license agreement or copyright infringement. Jacobsen v. Katzer 535 F.3d 1373 (Fed Cir. 2008). By granting a license to the copyright, the claim is for breach of license agreement unless the acts are outside of the scope of the license. In Jacobsen, the court held that failure to comply with the open source license was an act outside of the scope of the license. That means the defendant could be sued for copyright infringement.

The next problem is trying to prove actual damages when the software was given away for free. But if the software author registers the software, no damages are required. A plaintiff may elect statutory damages ‘regardless of the adequacy of the evidence offered as to his actual damages and the amount of the defendant’s profits.’ “ Columbia Pictures Television, Inc. v. Krypton Broad. of Birmingham, Inc., 259 F.3d 1186, 1194 (9th Cir.2001) (citations omitted).

Normal statutory damages max out at $30,000. But if the copyright infringement is willful, a court may award statutory damages of up to $150,000. 17 U.S.C. § 504(c)(2).  And you may have to pay attorney’s fees too. 17 U.S.C. § 505. This means, if all the stars are aligned, a party could be liable for $150,000 for using free software the wrong way.

Use Recitals to Explain the Deal

A recital section in a Software License is the part that’s supposed to explain the basic deal. They often don’t. They should.

Legally, the recital part of a contract has limited effect. The facts stated in the recitals are presumed true. California Evidence Code §622. But this rule excludes terms of consideration. The recitals are often referred to as the “whereas” section because they have a bunch of sentences that start with “Whereas.” This archaic ritual has been passed down from medieval times. Using whereas clauses is a standard practice so it is not wrong. You are free to start your license agreement:

Whereas, Licensor has developed a software application it desires to license to Licensee; Whereas, Licensee wishes to license Licensor’s software from Licensor under the terms and conditions of this Agreement

Then like a bass drum, NOW Therefore, the parties agree ….. .

That is style hard to read and a bit confusing. Try these example recitals anyone can quickly understand and perhaps would like to see some day:

Google licenses Oracle’s Java APIs to end their lawsuit.


Microsoft allows Apple to resell its complete Word application for royalties.

Look at what the deal boils down to and just state it. Do not load it with definitions-those come soon enough. And limit all the noise and limitations and restrictions. Avoid this:

Microsoft, and affiliates, allow by limited revocable and terminable license, Apple to resell or sublicense, directly or through distribution, Microsoft’ Word application, in binary code only for the minimum guaranteed royalties in the territory stated in the attached exhibit or as defined below in section 1……

Just stop putting all the noise in and explain the deal simply. By stating less, people can sort out the type of agreement quickly and look at all the details when they want.

Facebook: Getting Electronic Evidence Is Not As Hard As Getting It Admitted

There are many articles on using discovery to obtain electronically stored information. Also known as ESI. Emails, electronic documents like excel spreadsheets, word docs, powerpoint presentation and pdfs are evidence found on computers. Before you ponder the maze required to obtain and analysis ESI, first consider how you are going to get the electronic document into evidence.

In the Face book litigation, you may have heard that Mr. Ceglia now claims he has an email from Mr Zuckerberg discussing a contract to give Mr. Ceglia 50 percent of Facebook. From what I can tell the evidence is not the email but a word document Ceglia says he used to save the email. So there is a debate over the validity of the saved email in a word doc.

The problem is establishing a foundation for a court to allow the document into evidence. If a party cannot show the document is what it purports to be, the jury never even sees it. Facebook has hired Gerald McMenanim, a professor at California State University in Fresno. I have hired him too on the same type of problem. He looks at the questioned email and compares it to known writings. His considers the documents using linguistics. This technique is used to establish similarity or, as in the Facebook case, dissimilarity of authorship.

This task would probably not be required if Ceglia had the original email. The original would have meta data which helps computer forensic people determine the who sent the email, when, and from what computer. Because Ceglia did not save the email from the 2003-2004 time period, that information is not available. So what to do.

Look at Lorraine v. Markel American Ins. Co. 241 F.R.D. 534 (D. Md. 2007). Magistrate Grimm wrote this 48 page tome about getting electronic evidence admitted. The case in not very high tech. The parties were battling over an arbitration award based on an insurance claim: a lightning bolt hit a yacht. The parties made cross motions for summary judgment. The motions were denied because the parties had not provided adequate foundation for electronically stored evidence. Before you wonder about the weight of authority a magistrate’s opinion has your jurisdiction, read the case. Most of it is dicta. But through the tireless efforts of Ms. Puja Gupta, Mr. Ben Peoples and Ms Kathryn Widmayer, See fnt 63, the opinion provides a masterful walk down the process of getting ESI into evidence.

After looking at the case, you may realize Ceglia’s major hurdle in the Facebook case is his first. Since he copied the email to a word doc, the document is not what it purports to be. It is not the original of the email; it is a copy of an email. Ceglia faces a best evidence rule (FRE 1002) problem since he cannot offer the original of the document. Ceglia may also have a problem with electronic signature law on contracts. Then there is the linguistics expert. This goes to show that solving the admissibility of electronic evidence is often harder than getting it in the first place.

Software Project Management, Find a Pilot

A long time ago a CEO told me that the reason airplanes don’t crash is because they put a pilot in the front seat behind the windshield. The person in charge is the first to see the consequences of failure.  Well airplanes do crash but probably not as often as if they flew remotely with 10 different people working on the process.

What does it look like when there is no pilot? See Charles Babcock’s excellent coverage of the opening legal volleys in Monteclair State University v. Oracle.  www.informationweek.com/news/software/enterprise_apps/229800001?pgno=1

This is a classic tale about a project management without a pilot. Right now we do not know which side was missing the pilot. But Montclair mentions there were about 129 people worked on the project in a 12 month period. Something seems wrong with that. It would be hard keep track of that number of people let alone manage them. But then again if there was offshore coding or testing, the number is not that large. Time will tell who fouled this up.

The best practice is to get a pilot on both sides at the time the statement of work is prepared. Then have them follow through. If there are change orders, follow a change order process. Follow it through as though your life depended on it. That is what a pilot does and the planes land safely.

Acceptance is a Big Deal in Software License Agreements

A key event in a software license agreement is when the buyer accepts the software. The reason is that date usually triggers the start of the warranty period, the start of support, the term of a term license, and the clock on payment. Variations on these trigger dates abound, but acceptance is a normal triggering event in software license agreement.  

SEMI ANNUAL NOTE ON USAGE. This blog uses seller and buy for software agreements. There are two reasons.  1) Buyer and seller are easier to read, write and understand than licensee and licensor, and 2) under the uniform commercial code, that is what the parties are called.   

Acceptance is the time when the software license transfers to the buyer and significant obligations begin. Before acceptance, a buyer may reject the software because it does not conform to the agreement. At that point, no amount is due and the seller must show the software conforms or repair or replace the software.

After software is accepted, the buyer may still claim a problem with the software but the buyer must show the software is nonconforming. From an accounting point of view, normally once software is accepted, the seller can book the deal as revenue and the buyer must show the liability. What can be gleaned from all this is the seller want a fast acceptance while the buyer wants a slow acceptance.   

How is the software accepted. This issue is usually divided between commercial off the shelf(“COTS”) software and custom or customized software. With COTS software there is no reason for a lengthy acceptance period. The software is often made immediately available at an FTP site and the buyer can download and install the software. Since the software normally works, a buyer does not need to inspect the software to see if it conforms to the manual. A short time may be appropriate to verify that the software received was what was ordered. But further delay is only used to delay starting the payment clock. 

Since payment is often triggered on acceptance, if payment is due 30 days after acceptance, then the seller wants acceptance on the email of the password to FTP site. Buyer wants 30 days after acceptance. That way instead of payment in 30 days, payment is due acceptance period plus 30 days. That can be a hard date to pin down.  

For custom or customized software, acceptance is another story. The parties need to develop a comprehensive software requirements document and acceptance needs to satisfy the agreed software requirements. But, while this suggests a lengthy process, often it is not. The reason is the parties have been dealing with the development and customization for months and have a good handle on whether the requirements are met. 

The acceptance terms need to be detailed so each party knows when the software is accepted. A seller wants terms such as the software is accepted within 10 days of delivery unless buyer rejects in writing with details of the nonconfomity. Buyers want a term such as the software is acceptance when, in buyers sole discretion, the software satisfies buyers requirements. Some point between these position may practically resolve the issue. One good term is to state that the software is deemed accepted if put into commercial use. That way, you do not have a buyer that refuses to accept because of some small flaw but is using the software anyway.          

What Happens to a Software License Agreement in Bankruptcy

When you receive a notice of bankrupcty you normally mentally right off the account. Not so fast if the bankruptcy involves a software license agreement. Unlike an unpaid invoice, a software license agreement has a special life in bankruptcy. The first move is get a bankruptcy attorney where the bankruptcy is filed. The reason is complex. There are technical issues under rules for executory or non executory contracts. This deals with whether a contract is completed or still has pending performance. A classic example is a real estate lease. Since leases have continuing performance, the contract falls under an area where the debtor can assume or reject the lease. 

This is quite frankly why many retailers file bankruptcy. They get rid of bad store leases. Under the Bankruptcy Code 11 USC 365 there are special for intellectual property license rights. The question is whether the debtor can keep its license rights as a licensee or a licensor. The good news is that when a debtor assumes the software license agreement, they have to bring it current. So, if your software is embedded in the company’s product and they are trying to reorganize under Chapter 11, they will have to continue the license to have a product. Under the assumption rules, they have to keep the license current to maintain the rights. It gets challenging in a chapter 7 if they are trying to sell your license. But that is why you should get a local bankruptcy attorney on board.

A last note: filing bankruptcy is not a default allowing the license to terminate. It is easier to leave the term in the standard agreements than explain why this is so. That means if you made a bad deal, you cannot terminate it just because the licensee filed for bankruptcy.     

Software Support and Warranty Are Not The Same

Why do you need a support agreement when you have a nice warranty? This is a common issue where a customer wants support to start after the warranty ends. That extends the time the seller gets paid for support. The story is while the software is in warranty there is no need for support.

Not so. Look at a standard software warranty: “Licensor agrees that the Software will conform to the Documentation for a period of 90 days after delivery.” You can bicker over the length of the warranty or that it should start on acceptance and not delivery. The seller will explain the problems that accountants give them under the revenue recognition rules. But focus on what the warranty covers: the software will do what the documentation says it will. If you do not read the manual and want to know how to use the software, you do not have a warranty problem.

Support folks often talk about RTFM. That is “Read The F%$&%#$ Manual.” But users may be lazy or, to be fair, the manual may not solve the issue in crystal clear terms. The point is, when users first get the software, they are most likely to have a learning curve problem and need to call support. 

The failure of the user to understand how to do something is not a warranty issue. In fact, the warranty is rarely called into question for most seasoned software products. The real need is for a support phone or email to solve those pressing user issues. So do not treat a helping hand as a warranty claim because support and warranty are not the same.       

Open Source Software is Ok to Use

Several year end deals bogged down over open source code. The reason is buyers have a punch list which says no open source code. This makes sense at first because risk managers do not want the dreaded software that provideds a free license grant for everyone. The standard General Public License (GPL) open source license requires you to grant all your development to the open source community. The software is free with a significant catch. This causes problems because most companies do not want to give what they do away. 

So, the risk managers issue an edict no open source code in purchased software. This is not a bad point to start with but there should be a rosetta stone explaining when the edict does not apply. Why? For starters, the grant back license only applies to developments made on the open source. If you are only using the object code of an open source product, you have no concerns with the grant back clause.

When you use a Linux operating system, you do not have to give away all the work you do. The use point may not solve all concerns with open source, but if you are only using the object code, you probably have no grant back problems. 

The best approach is to provide the buyer with a list of all open source software and licenses.  Then they can go through and see if the open license agreements cause problems. In fact, open source license may not even be GPL and may not require a grant back for development. Sellers and buyer beware, the only way to determine the license requirements is to read the license. Assume there is no standard usage. Even when the software says it is GPL, there may be wonderful exceptions. See for example   http://ecos.sourceware.org/license-overview.html . Ecos is a popular open source runtime system. It is licensed under GPL with a significant exception: 


Plain as day. Well your technical folks can let you know if that exception saves the day. It usually does with Ecos. So, the next time you run into the No open source software edict, read the licenses! If you are only using the object code, you probably have no problems at all.   

Applying the UCC to Software License Agreements

The Uniform Commercial Code is a commercial set of laws that apply in most states. The UCC covers a number of commercial transaction like sales, notes, letters of credits and security interests. While UCC Article 2 applies to the sale of goods, the common notion is it only applies to tangible things like wheat, pigs and shoes. Since software is normally licensed and is intangible technology, many people will not even consider the UCC in resolving software license issues. 

So, what law applies. Initially, the thought is that copyright law controls a software license agreement. But there is really little contract law in the copyright laws. For contract law, the courts look to the applicable state law. And, when there is a license, copyright laws and remedies often do not even apply. The relationship is controlled by contract law.

Most states will have several areas of contract law. Article 2 of the UCC will apply to the sale of goods and other cases or statutes will apply to services, real estate and other contracts. But when a software license has all the underpinnings of a sale, the UCC will apply. See RRX Industries, Inc. v. Lab-Con, Inc.  772 F.2d 543 (9th Cir.1985). The key is the good or services analysis. The court will look at the deal and determine if it more of a sale of a good or a service. A software licenses can be a good, a good with services, or pure services. For example a custom software development is probably treated as a service so the UCC would not apply. Software Distribution or reseller agreements are more likely to be treated as a sale of software for purposes of the UCC.  

In the negotiation process of entering a software license agreement, the parties may agree the UCC applies. When an issue arises, the parties may also agree that the UCC applies. See Lockheed Electronics Company, Inc, v. Keronix, Inc. (1981) 114 Cal. App.3d 304. Ordinarily, this takes great effort after the fact because both sides will have to figure out whether they do better applying the UCC or not.

If the UCC applies, remember the key to the UCC is notice and communication. If a party is not paying its bills, demand adequate assurance of payment. When there is a defect claim, make it in a detailed writing and the licensor should demand an itemization of defects. While exclusions of implied warranties are common practice in software license agreements, an overlooked provision is the warranty of title and against infringement (UCC §2312). As a result, some software license agreements have no infringement indemnities provisions. But if the UCC applies, they do. So consider the UCC in software license agreement issues and the parties may actually have an easier time resolving problems. At least they will have a solid framework to work with.     


TweetLikeEmailLinkedInGoogle Plus

How To Limit Defect Claims Under A Software License Agreement

Where do you start when a customer claims the software is defective. An inherent problem with software is there is nothing to see or touch. The problem is not like a clock that does not tell time. As a result, solving a defective product issue is challenging.

Start with establishing what the software should or should not do. The license agreement may be helpful where the warranty is limited to the software conforming to the documentation. But be careful, in one case the documentation was 5 banker’s boxes of coding instructions. More often there is no documentation for the software at all. By far the best approach is to require and comply with defect notice provisions.

In a warranty section, there should be a term that requires the licensee to provide notice of the defect and explain in detail what the defect is. So, if you have a 90 day warranty, and hear nothing from the licensee, they may have trouble proving any defect. This is also where the Uniform Commercial Code can be handy. Look at UCC § 2605. That section says a buyer waives objections they do not make. See Lockheed Electronics Company, Inc, v. Keronix, Inc. (1981) 114 Cal. App.3d 304. In that case, the debtor lost defect claims because they were waived.

When a buyer propely claims the software is defective, under the UCC, the seller can ask for a written statement of all defects the buyer intends to rely on. By this process, the seller can pin down the defects the buyer can assert as a defense. If the buyer declines to respond or limits the response, the defect claim is reduced or eliminated.  

Even where a raft of defects is permitted, the best approach is to point to a customer who successfully implemented the software. In one case, I asked if the arbitrator had a cell phone. It happened to use my client’s software as an operating system. I asked him if the software worked. He got the point, and we got the judgment.