Open-Source Licensing: Here’s What I’ve ‘Noticed’

Open-source license compliance is a sensitive topic. Lawyers and technicians have devoted endless hours, lengthy blog postings and much mental energy to questions like, “What is a derivative work?” and “What is distribution?”

Very interesting stuff indeed, and grist for meaty discussions. However, in the trenches, people who are using open-source code as building blocks in their products spend more time on one compliance task than any other: notices. Like most time-consuming tasks, it is not exactly an intellectual thrill.

Have You Noticed?

The open-source license world is full of amusing requirements, such as the “beerware” license or the “guitar” license. Fortunately these requirements are not mandatory, or many more coders would be drunken musicians. Notice requirements are not so amusing. In fact, while they seem innocuous, they can suck developers — and their lawyers — into a vortex of make-work that feels like a Kafka story. Granted, most of the lawyer’s trade may feel like make-work from a Kafka story, but it is no great accomplishment to make the situation worse.

If you are wondering what I am talking about, consider the “mostly harmless” MIT license, which originated at the Massachusetts Institute of Technology. One of the most famous and popular non-hereditary open-source licenses, it contains a notice that reads as follows:”The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”

Now, let us suppose you are a cell phone maker, and you want to use code issued with an MIT license in your product. This agreement, literally, requires you to reproduce not only a copyright notice, but also the entire “permission notice” — meaning presumably the entire license. Clients have one overarching question for me about this: “Are they serious?”

The MIT license, short and sweet as it is, might have a hope of fitting on a cell phone. After all, cell phones are little computers these days. But does anybody really have a copy of, say, the Lesser General Public License on his cell phone? Would anyone want to have it on a cell phone? I don’t even want to use the Web on my cell phone, much less read a 4,000-word license agreement on it.

What Are They For?

Most developers who ask for attribution think they are being reasonable — and in fact they are. Still, anyone who has sat through the credits for a movie lately can understand that a little bit of attribution can mean a lot of small print. I’m from Los Angeles, and that is the only town where people sit through the credits, but that is because they all know, at a minimum, the Second Assistant Scene Painter. Most normal people just hide their popcorn containers under the seat and leave.

I bet even fewer people read the copyright notices for software products. (One exception — those creating competing products.) It’s not clear that having a copyright notice listed among hundreds of notices in a product that are “About Screen” is really all that helpful to a developer’s reputation.

In addition, I suspect most individual developers consider a copyright notice a kind of magic talisman, and it is no such thing. Since the United States’ adoption of the Berne Convention in 1989, copyright notices haven’t meant much. Before then, publishing a work without a notice could cause it to fall into the public domain. These days, the industrialized world has quite sensibly dispensed with such technicalities.

Notices actually serve at least three purposes: copyright notice, licensing information and author attribution. Part of the problem is that many open-source licenses employ copyright notices as a substitute for providing information about what code is included in the development. However, a notice like “This product includes code Copyright 2006 Mai T. Hacker” says nothing about what the code is or what it does.

Some Justification

For practical purposes, information about what is embedded in a product is important. First, that information is necessary for code provided under free software licenses to inform the licensee of the legal terms that govern the use of the software. However, that information is also important for non-hereditary licenses where terms are not passed through.

The whole concept of open source is to make source code freely available. If the licensee gets a product in closed-source form, having information about what open-source code is embedded in the product helps the licensee take best advantage of the community good the open-source software represents, because the licensee could often get his own license to the portions of the code available in open-source form, even if the product itself were licensed under other terms.

There is plenty of justification for notice requirements. However, the way notices are currently provided causes problems that need not exist, and a single copyright notice is inadequate to serve all three purposes.

What’s Wrong With Notices?

For instance, most notices are wrong — in irritating little ways that drive lawyers crazy. The form of the notice specified by the Copyright Act is “Copyright 2006 Kaiser Sose” — that is, the word “copyright,” year of publication, copyright owner. Most notices also say “All rights reserved.” About half of all open source notices have some slightly incorrect variation, such as “Copyright Kaiser Sose All Rights Reserved 2006.”

One who is obligated to reproduce the notice must consider these questions: Do I follow the letter of the license or the spirit of it? Should I correct or not? One usually engages in this kind of deep thought at 11 p.m. on the night before a product release.

If you think this is only a problem for evil corporate developers, you are wrong. Academic and non-commercial developers seem to have just as difficult a time with this as anyone else. If you don’t believe me, you can go through the exercise of looking at the code in a non-commercial development and seeing if all the notices are correct. If you don’t have the energy to check this yourself, you are going to have to trust me: Many of them are not.

A Ray of Light

In one of its rare practical actions, the open-source community generally repudiated the Apache 1.0 and BSD Unix licenses because of their advertising requirements. Still, many open-source licenses require extensive notice provisions, and many notice requirements have not been updated to allow for the trend toward online distribution.

The easiest way to comply with notice provisions in source code is to leave the notices that are already in the code alone. The vast majority of open-source software code used in commercial products is used without modification. So, this approach allows a licensee to comply with the notice provisions by simply passing along the notice file along with the rest of the source code distribution. It is also flexible enough to help developers like device and embedded systems manufacturers, allowing distribution in product literature, on boxes and so forth. Still, I think we can do a little bit better.

In practice, placing notices on products is often difficult or impossible. Setting aside the situation in which the product is not application software and does not contain an obvious place to put notices — such as when products are electronic devices or software toolkits — there are many products that are so complex and contain so many individual modules that the notice provisions alone would run hundreds of lines. Keeping in mind that these notices will change with every significant revision of the product due to updating and replacement of modules in succeeding versions, maintaining a list of copyright notices becomes an arduous task.

The problem with arduous tasks, of course, is that they tend to remain undone. When a company has different departments responsible for user documentation and software development — and let us devoutly hope most of them do — it is easy for updates to surface in the engineering department without the notices being updated in the packaging department. This places the company at risk of violating its inbound licenses due to minor administrative snafus — in other words, it’s a trap for those who are inattentive. Creating traps like this is the kind of nefarious act usually attributed to lawyers, not software developers. Please, don’t stoop to our level.

Notices in the Real World

The easiest way to handle this, and the way that gives the programmer his due and encourages the disclosure of full notices, is to allow the distributor to maintain a central Web page that displays all the notices for a product release. In fact, this is what many commercial developers actually do, notwithstanding that this solution is often not compliant, technically, with open-source software license agreements. Having a single, centralized repository for notices for a particular product encourages the product developer to keep the notices accurate and makes the notices public for all to see.

We should recognize that accessing information online is no longer only the province of the technically savvy. Requiring notices in paper documentation is archaic and unworkable in 2006. Any open-source license that does not allow this method of notice disclosure runs the risk of becoming obsolete — or worse, unenforceable — because licensors who allow rampant violation of their licenses can be restricted from enforcing them due to a legal doctrine called “equitable estoppel.” It’s best for licensor and licensee alike to have notice requirements that are practical and complied with, rather than unworkable and ignored.

Still Fighting the Bruised Knee

As problems go, the irritations of notice provisions are not going to make any headlines. Maybe I’m the only one who cares about the issue. I am long accustomed to being the person trying to fix things that cause people unnecessary irritation and trouble. I am the one in our office who submits an endless stream of “bugs” to IT like, “The default on this input screen is not the most intuitive one!” Nearly 20 years ago, I wrote an article for a computer magazine on how to design user input screens. Keep in mind that in 1988 many user input screens consisted of the C prompt, and user-friendliness was a relatively new concept. Now, I will tell the same story I told then.

When I was in college, I used to exercise in the winter by running around an indoor track with a cement floor. In those pre-Nike days, I wore deck shoes when I ran. After about three months my knees were killing me. I went to the doctor and told him about my problem. He tapped me on the knee cap with his index finger and said, “Does that hurt?” I said no. “Well,” he said, “If I did it 100,000 times it would.” My knee, he explained, was bruised on the inside as a result of my running in inappropriate shoes.

Because I am a practicing attorney and spend most of my time solving practical problems for my clients, I don’t get excited about many policy issues. I don’t spend a lot of time telling people what is right to do; I tell them what is expedient to do. In this case, though, I will take a stand, mindful that you will consider it a small one. Most open-source licenses need to be modified to fix this problem, and authors who license code under existing open-source licenses should think carefully about what notices they need to attach to their code — mindful that those notices will need to be passed on by all their licenesees.

I know that the stewards of open-source licenses hate to change them. Still, no software license is so sacrosanct that it should cause this much heartache over problems that are, ultimately, avoidable. Little problems turn into big problems when they are both repeated constantly and impossible to avoid. I avoided re-bruising my knee by changing my shoes, but developer licensees are stuck with the licenses that apply to open-source code.