Intellectual Property: Copyright and Software Licenses

Or, How I Stopped Clicking "I Accept" and Learned to Love the LGPL

Jean Barmash and Alberto Gemin

December 2007

Revised February 2008

Summary: It is necessary for an architect to have a good grasp of intellectual property concepts, because the architect is partially responsible for legal ramifications that originate from any software project. (8 printed pages)

Contents

Legal Disclaimer
Introduction
Legalese for Developers
Legal Lunch-and-Learn
Conclusion
Critical-Thinking Questions
Sources
Further Study
Glossary
 

Legal Disclaimer

This article is based on best knowledge of the authors and is current as of January 2007. For any further questions, please consult an attorney who specializes in intellectual-property law.

Introduction

We were working nights to fix the last bugs before our beta release, when an e-mail from the legal department froze us all: Could we possibly deliver to them a list of all the external components we were packaging? The lawyers wanted to conduct a legal review of our product, to make sure we complied with any legal requirements imposed by external components.

We knew we were using some open-source components (Free/Libre/Open-Source Software, or FLOSS), but did we ever read the licenses? Is not open-source software supposed to be free to use? After the initial panic, we gathered the team and made a list of six open-source components that had crept into our product over time. The licenses were in fine print and way too verbose for comfort.

Legalese for Developers

Later that week, I sat down with Jackie (one of the lawyers) and presented the material. During that meeting, and in the following days, I found myself on a steep learning curve. All of a sudden, I had to understand issues that I never remotely considered, and I wished I had taken the time at least to glance through those license agreements, instead of hastily clicking I accept. Fortunately, Jackie guided me through the process. She taught me a lot about licenses and, more importantly, about the restrictions that they imposed on our products.

One of the first things she explained was the difference between a software license and a copyright. The owner of a copyright can control reproduction, preparation of derivative work, and distribution of copies of the work. In other words, authors can benefit from their creation by controlling who uses it and how. These rights are automatically assigned to the author by virtue of creation, but the owner can also officially register the copyright with the U.S. Government. This does not provide extra protection, but people and companies do so, because it is easy to do and will be helpful in an infringement lawsuit. To illustrate her point, Jackie pointed out that authors would be much less likely to write books if somebody else can just copy the text and reprint the book themselves. Copyright laws apply to software, too, especially because it is so easy to copy code; companies need protection to make sure they can benefit from their creation.

However, the copyright owner does not have to retain all the rights: They can decide to lend their rights to someone else, whether exclusively or not. The most common way to accomplish this, especially in the case of software, is through licenses. A license allows copyright owners to direct how the product can be used, and allows them to willingly extend (lend) some of the copyright rights. For example, some licenses allow use for personal purposes; however, to redistribute the software commercially, they impose licensing fees that have to be paid to the copyright owner.

When Free Is Not Free

After this preamble, Jackie moved to the list of components we produced. She scanned the list of components and asked, "Are we distributing any of our source code?"

I knew the answer to that: "Of course not. It's our proprietary code!"

"Then, we have a problem. You are using a LGPL component right there," she retorted.

I knew about the GNU Lesser General Public License (LGPL), and about the original GNU General Public License (GPL), but it turned out that some of what I knew was wrong. Jackie explained that the GPL demands that any product that uses components licensed through the GPL has to be licensed also through the GPL. This made sense; the GPL is linked to the Free Software Foundation, and their mantra is that all improvements to code should be redistributed back to the community, so that everybody can benefit from the new features and fixes. This requirement is known as copyleft. GPL specifically allows redistribution, but dictates how redistribution must be accomplished. If the redistribution methods violate the terms of the GPL—that is, by not distributing the source code—the original authors could sue under copyright law.

Luckily, in our case, we were dealing with the Lesser GPL, which has fewer restrictions than the GPL, because it does not force users to license all their software through the same license. Nevertheless, it does require redistribution of the original source code together with anything that uses it, and this is where our problem lay. In my mind, I could already see our nights becoming even longer while we scrambled to modify the installer to include the source files.

The second problem Jackie flagged was even more serious. She told me that another component we used was under a license that required paying a fee for commercial redistribution. She asked me how important this component was, and if there was a way to do without it. This was not a core component to our system, and I knew we could rewrite some of the functionality that it was providing. I felt that distinctive stomach-tightening associated with delivering bad news to the team. More late hours were ahead of us, to eliminate any reference to the component.

When we came to the end of the list of components, we realized we had no more bad news to deliver to the team. Jackie explained that the Web server and the application server that we were redistributing were already licensed to our company—a fact that did not surprise me, because these were part of the corporate-standard toolset for many of our products.

Over the next two weeks, we implemented all the changes and reran the regression tests. We survived, but the experience left me with a bad taste. It was clear I had been lacking a whole body of knowledge, and I had just experienced how that fault quickly translated into extra work. We were able to escape with minor damage, instead of a last minute-disaster; but it had been only a matter of luck.

Legal Lunch-and-Learn

Upon my suggestion, after our release was well behind us, we had a lunch-and-learn meeting with Jackie and her team, and open to the whole department. My team was the first to sign up, and I made sure that team leads who worked on other products were attending. The initial atmosphere was a bit tense; these people made us work extra hours. However, after the lawyers explained some of the concepts that I had learned in the previous weeks, the mood quickly turned inquisitive.

My team members had many questions on copyright concepts: Because the work that is created by authors is copyrighted, does this mean that we can never use code that is found on the Web in our work? Jackie explained that a concept known as fair-use doctrine is at play here. It means that there are cases in which other people's work can be freely used—for example, for educational purposes.

In general, authors often specify what rights they grant to readers. Jackie suggested that, when people are considering using something that they found, they must read if the rights are reserved, the terms are spelled out, or the article is offered under some widely available license that you understand—such as the Creative Commons License.

Another question that was discussed was related to ownership of copyright. Because authors are automatically assigned the copyright of the work that they create, does this mean that when leaving a job, employees can take with them copies of the software that they created at work? The lawyers explained that another concept was at play here: work for hire. Anything a worker produces in their capacity as an employee (and while receiving a salary for the work) is work made for hire, and, as such, the employer is the copyright holder.

"What if you do not get a salary? We have a guy working with us who is a contractor!" Jackie explained that our company had a standard legal contract for all the independent contractors, and one of the clauses specifies that all their work is work for hire, and, as such, the rights are assigned to the company. However, she said, without that provision in place, the contractor might be able to claim the copyright on their work.

"This is what you get the big bucks for," I thought.

Some of my colleagues started wondering what that meant if they wanted to use some of the ideas that they saw at their old jobs. We had some experienced developers who had worked on similar products in the past; they were concerned that they might be infringing on a copyright. Jackie emphasized an important concept: A copyright covers only the expression of an idea, not the idea itself. People are free to use the ideas they came across, as long as they do not copy the actual code. However, Jackie pointed out that in case of computer code, it is admissible to copy simple tidbits. For example, because there are only so many ways to count from one to one hundred, it would be unreasonable to protect an algorithm to do it. If there were only a few ways of expressing the idea, protecting the expression would be equivalent to protecting the idea itself. Of course, she added, a truly novel and unique idea could also be protected, and she introduced the concept of patents.

Jackie explained that until a few years ago, companies could not patent software. However, some software can now be patented in the U.S. Although, so far, the list of granted patents has been relatively short, companies file for patents routinely. Because patent law does not allow patenting of a mathematical idea (an algorithm), obtaining a patent for software is tricky, as the distinction between business methods (patentable) and their implemented algorithms (not patentable) is blurry and much more subject to interpretation than in the case of a traditional patent that is based on physical invention.

There are several requirements that apply to all patents, the two most important being that the idea being patented is novel and non-obvious. Jackie further explained that the intellectual-property protections exist to encourage innovation. The patent holders are granted exclusive temporary rights to their invention, in return for disclosing the invention and making it available to the public. This way, anybody can benefit from the invention after the patent period expires.

Jackie asked us to think of ideas we included in our product that we thought were innovative, and promised to return in a few weeks to help us figure out if they were patentable. To encourage us to go through the process, she informed us that our company offered a monetary bonus for any patents that we generated. In addition, she said that the legal department would do a patent search on some of those ideas to ensure we have not accidentally infringed on other people's patents.

The discussion then turned back to licensing and to the various licenses that are commonly used. Jackie explained that there are hundreds of different licenses, and that you should always read the license if you have never seen it or it has not been cleared for use by the legal department. The most widely used licenses are the GPL, LGPL, BSD, MIT License, and Apache Licenses. Jackie had a prepared table that outlined the main characteristics of the different licenses:

Table 1. Common licenses and their terms

Jackie concluded the meeting by explaining to us that all these protections—and all intellectual-property protection in the United States, for that matter—go back all the way to the U.S. Constitution. Article 1, Section 8 gives the Congress the power "to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries." Other countries have similar clauses in their constitutions or equivalent governing documents, but differences exist between protections in different countries.

Conclusion

I learned from this experience that it is necessary for an architect to have a good grasp of intellectual property concepts, because the architect is partially responsible for legal ramifications that originate from any software project. Because of the predicament in which we found ourselves, I became much more careful about using third-party components.

I am now the guy who actually reads the licenses before using them on a project. I am much more aware of the constraints imposed by their licenses ahead of time, and can account for that in my plans. As for patents, I am much more aware of what they mean, and look for opportunities to protect intellectual property. I even keep a notebook for ideas that I think might be patentable, to establish a date of invention, which can be used in any potential patent litigation.

Gradually, I came to understand that intellectual-property laws all attempt to strike a balance between the public good and protection of innovation. They try to make sure that the people who create can profit from their work, if they want to. Alternatively, people can choose also to contribute to the good of the community—like the Free Software Foundation and the GNU projects are trying to do. For example, a few of my team members found the ideas of the Free Software Foundation quite inspiring and became regular contributors to the open-source movement.

Critical-Thinking Questions

· If, when you issue your software, you do not do anything in the legal sense, what intellectual-property rights do you retain?

· How is software fundamentally different from physical products, and what implications does that have for intellectual-property-protecting it?

· What criteria does an idea have to meet in order to be patentable? How is patenting of software different from patenting a physical invention?

· How do people in the open-source community encourage sharing of ideas and code through licensing?

· How would you go about proving that somebody violated your copyright by copying your code?

Sources

· [Constitution] The United States Constitution. Article 1, Section 8, Clause 5.

· [Wikipedia 1] Wikipedia contributors. "Assignment (law)." Wikipedia, the Free Encyclopedia. 2006. (Cited January 11, 2007.)

· [Wikipedia 2] Wikipedia contributors. "Copyleft." Wikipedia, the Free Encyclopedia. 2007. (Cited January 11, 2007.)

· [Wikipedia 3] Wikipedia contributors. "Creative Commons licenses." Wikipedia, the Free Encyclopedia. 2006. (Cited January 11, 2007.)

Further Study

· Richards, John. "Copyright Protection for Computer Software in the United States." Ladas & Parry LLP. 2002. (Accessed January 9, 2007.)

· Cornell University Law School, Legal Information Institute. "Patent." 2007. (Accessed January 11, 2007.)

· Free Software Foundation. "Licenses." (Various licenses and comments about them). 2007. (Accessed January 9, 2007.)

· Landau, Michael. "Ownership Issues in Copyright Law." GigaLaw.com. 2000. (Accessed January 9, 2007.)

· St. Laurent, Andrew M. Understanding Open Source and Free Software Licensing. Sebastopol, CA: O'Reilly Media, 2004.

· Leaffer, Marshall A. Understanding Copyright Law. Fourth edition. Newark, NJ: LexisNexis, 2005.

· Open Source Initiative. "Open Source Licenses." 2006. (Accessed January 9, 2007.)

· Groklaw. (Site that tracks many issues in software intellectual property). 2007.

Glossary

Assignment—A concept describing the transfer of rights held by one party (the assignor) to another party (the assignee). An assignment of copyright rights is akin to the sale of personal property. The original owner sells his/her rights to a third party, and can no longer control how the third party uses these rights. Contracts between a corporation and an independent contractor usually contain a copyright-assignment clause that assigns the copyright to the corporation when the contractor authors copyrighted material. (See [Wikipedia 1].)

Copyleft—A requirement of the GPL that imposes the restriction that all code that uses GPL-licensed components has to be licensed also through the GPL. It is really a copyright hack, because it turns the copyright law inside out; thus, instead of imposing restrictions, the copyleft grants distribution rights and protects itself from restrictions on those rights. (See [Wikipedia 2].)

Creative Commons licenses—A set of several copyright licenses released by the nonprofit corporation Creative Commons. All of them grant some basic rights, such as the right to share the work on file-sharing networks. Different versions grant particular rights, such as the permission to copy or distribute the work only if the original author is given credit, or only for noncommercial purposes, and so forth. (See [Wikipedia 3].)

Fair use—A doctrine that allows limited use of copyrighted material without requiring permission from the rights holders. It allows legal, nonlicensed citation or incorporation of copyrighted material in noncommercial derivation from the primary work, such as writing criticism, commenting, teaching, or research. Although the term fair use refers technically to U.S. copyright law, similar principles exist in other jurisdictions. In the U.S., it derives from the rights provided by the First Amendment to the United States Constitution (free speech).

FLOSS—Free/Libre/Open-Source Software, an alternative acronym for open-source software (OSS). In this context, the term libre (borrowed from various romance languages) refers to freedom, and it is preferred to the English term free, because the latter also means zero-priced. Non-open-source freeware is an example of software that is free, but not libre.

About the authors

Jean Barmash is a senior consultant/trainer at Infusion Development, where he is involved in architecture, project management, and hands-on development. As an integration consultant and technical lead for Trilogy, he worked on several large automotive projects. While working as principal software engineer for Symantec, Jean helped develop a product focused on business-intelligence solutions for the data center. Well-versed in both .NET and Java, he is currently focused on Web business-intelligence solutions.

Alberto Gemin is a senior consultant at Infusion Development in New York. Starting at Ericsson in Sweden, where he designed real-time operating systems, he moved on to Accenture in France, where he became involved in customer-relations management (CRM). After three years at Akibia in London as a senior architect implementing EAI solutions, Alberto found at Infusion the opportunity to expand his experience with a wide range of architectural challenges.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.