Key Words

History of open source; GPL licenses; software derivatives; DMCA; shareware; litigation and open source

Best read in a Volkswagen minibus

The “Open-Source Initiative” is really an interesting animal. Open-source software has revolutionized the embedded software industry. Most of the licenses that are of interest to the embedded engineer can be boiled down into a few items of inquiry. They are as follows:

To understand this further, and in keeping with the 1960s feel of the “initiative,” imagine some hippies sharing a certain type of cigarette. The first guy, say his name is Mort (known for a good stash), starts up a cigarette and passes it around. Mort doesn’t mind passing it around as long as he gets the credit for the hit. So, as it passes, the other users have to say “This is from Mort.” That is the copyright or “copyleft” notice. Now suppose Herb in the group adds his special herbal additive. It is a different color and the group can clearly see Herb’s stuff mixed in with Mort. That is OK with everyone as long as it is publicized along the lines of “This is Mort’s stash, but Herb has added his #4 herbal additive.” That is a modification to the source code and notice. If others like the #4 additive, then Herb is obligated to tell what is in his #4 contribution, if asked, and even give the recipe. No one in the group should ask for money for the cigarette. Now, someone in the group can charge for the act of passing the hit along or for the paper wrapper. That is cool. And you don’t have to share the “bread” with the group. However, suppose someone decides to mix Mort’s cigarette with his own cigarette to the point that it is no longer clear where Mort’s stash stops and the other’s begins. That’s uncool.

As you can see, over time, people in the group may want to make sure that they are only getting Mort’s stash and they may want to make sure that all of the known additives have been documented. Someone in the group discovers that even though you can get the stuff free, there is a market for making sure that it is from Mort. Furthermore, in that market all the recipes of Mort are correct and if there is a problem, then there is someone to call and ferret out problems and troubleshoot issues. Hence, the creation of companies sells open-source software services.

Historically, the creation of open-source software is traced to the GNU² project which eventually resolved into the Free Software Foundation. Any embedded engineer should be aware that there are other types of “free software” and projects that are not affiliated with the GNU initiative, for instance, The Debian Project software. Not all open-source license terms are the same. At any rate, the GNU project advocated four fundamental “freedoms”:

It is important to understand that these “freedoms” under GPL (General Public License) have nothing to do with issues regarding your desire, or not, to charge for services associated with the software. You certainly can charge. You must, however, offer the source code and derivatives of the software for free.³

The GNU GPL permits the licensee to copy, modify, i.e., create derivative works, and distribute the licensed software subject to certain conditions. These are the same rights that the Copyright Act of 1976 protects in 17 U.S.C. §106. Since the GPL is a license, the Licensor has the right to set conditions of the license that may not be contained in any law. For instance, the GPL requires that any software distribution be accompanied by access to the source code. Additionally, the GPL allows for modifications to the software and the subsequent distribution of modifications, as long as the modifications are also licensed under the terms of the GPL. Thus, there are two conditions where the GPL must be applied:

One never-ending issue in open-source software development is trying to determine where the open-source software starts and where it ends. In other words, where and how can proprietary software interface with the open-source code and not be subject to the license requirements. This issue has its origin, the legal interpretation of derivative works in traditional copyright law. A derivative work belongs to the original copyright owner and is defined as a work that is based upon, is similar to, or contains a substantial amount of the pre-existing work.⁴ It is a difficult and complex question in law and license interpretation to determine if the code is a derivative of the licensed code (and thus subject to the GPL) or not subject to the GPL when proprietary links are established. Proprietary links may be code that calls to various modules or libraries.

You can see a simple representation depicting where the open-source software is delineated and how the proprietary software interfaces in Figure 21.1.

Is the proprietary code (the code that you may not want to be subject to the GPL) so intertwined with the existing GPL code, so that it must be considered part of the licensed source code or is it sufficiently separated? In other words, is it a derivative work or not? To try to solve this question, many in the industry have tried to determine how the proprietary code interfaces with the GPL code and thus make this the determining factor. To this end, they employ a static or dynamic linking analysis. Under this analysis, static linking is considered to be a derivative and dynamic linking is not. This analysis is not settled among practitioners of trademark law and the courts. Nor does it take into account, in my opinion, the fact that section 102(b) of the Copyright Act does not provide copyright protection for processes and methods.

At any rate, consider link editors as being defined as linkers. The compiler automatically invokes the linker as the last step in compiling a program. The linker inserts code (or maps in shared libraries) to resolve program library references and/or combines object modules into an executable image suitable for loading into memory.

Static linking is the result of the linker copying all library routines used in the program into the executable image. The linker is given the user’s compiled code with unresolved references to library routines. Static linking does not require the presence of the library on the system where it is run. A static link outputs a combined file from the compiled code and the libraries.

Dynamic linking is accomplished by placing the name of a sharable library in the executable image. When a linker builds a dynamically linked application, it resolves all the references to library routines without copying the code into the executable image. Actual linking with the library routines does not occur until the image is run, when both the executable image and the library are placed in memory. Multiple programs can share a single copy of the library.⁵

This concept of distinguishing static linking from dynamic linking has some compelling logic as, after all, the goal is to determine the degree that the software program makes use of the copyrighted original work.

The courts tend to begin with a broader analysis. They will look to see how the licensed work is incorporated into the alleged derivative work. Next, they look for substantial similarity. Third, the courts will analyze the market impact of the alleged derivative. This embodies the idea that if demand for the original work has not been impacted, then it is unlikely that the alleged derivative has made much use of the original work. Lastly, the courts like to construe the definition of a derivative narrowly so as to not chill the market from new innovations. Some similarities relating to the basic functioning of computer systems (e.g., subroutine entry and exit code, external interfaces) can occur by coincidence or intentionally, because “that’s the way computers have to work.” In other cases, program functions are coded in a particular way, because that is the only (or most effective or the industry standard) way to implement that specific function on that particular computer architecture. Such source code must be excluded from the comparison because it is not entitled to copyright protection; instead, it is an idea that has merged into expression and is thereby rendered uncopyrightable.⁶

There can be an interesting intersection between the Digital Millennium Copyright Act or DMCA (see more regarding the DMCA under laws that can nail the embedded engineer below) and open-source licensing schemes, in that at least one court has ruled copyright information that was removed in violation of open-source license terms was a removal of copyright management information under the DMCA! This demonstrates how many legal aspects can be implicated in a simple event such as failing to maintain a copyright notice.

Top 20 most commonly used licenses in open-source projects

Table 21.1 illustrates the top 20 licenses that are used in open-source projects.

Most recent projects to convert to GPLv3, LGPLv3, or AGPLv3

Table 21.2 highlights the 10 most recent projects to be converted to GPLv3, LGPLv3, or AGPLv3. This list updates daily.

Public domain and shareware

The internet has ratcheted up the issue as to what exists in the public domain in regard to copyrights. The way the law exists now is that almost anything that is written down, i.e., “fixed in a medium” is automatically given copyright protection without claiming the right or even by giving copyright notice. It is often asked “What is in the public domain?” Or, is artfully stated, “It is shareware so, it is public domain.” Because of the automatic copyright attachment, there is really only one way to be sure that the shareware has really been dedicated to public use. That is to have the originator actually file with the copyright office! 37 CFR 201.26 which implements 17 USC 201.4 provides for recordation: any document clearly designated as a “Document Pertaining to Computer Shareware” and which governs the legal relationship between owners of computer shareware and persons associated with the dissemination or other use of computer shareware may be recorded in the Computer Shareware Registry.

Litigation and an open-source license

A very interesting case which demonstrates the type of modern litigation that engineers can find themselves embroiled in, and that demonstrates that even open-source licenses can be problematic, would be exemplified by Jacobsen v. Katzer.⁷ The case settled for a $100K payment by the defendant, but not before more than 400 filings were made in federal district court proceedings, that included two appeals to appellate courts. There were allegations of patent infringement, as well as cyber squatting proceedings, before a WIPO⁸ tribunal. But what should interest us here are the open-source license issues. First, the facts are described.

Jacobsen managed an open-source software group called the Java Model Railroad Interface (JMRI). The group created an application called DecoderPro which allowed model railroad enthusiasts to use their computers to program the decoder chips that control model trains. This application was available for download under the Artistic License⁹ which contained, among others, two salient provisions: (i) Jacobsen’s copyright notice was to be maintained and (ii) any changes to the files must contain a description of how the files or code had been changed. Defendant Katzer, it was alleged, when offering his competing Decoder Commander program used the open-source files and did not include (i) the author’s names, (ii) JMRI copyright notices, (iii) references to the COPYING file, (iv) an identification of JMRI as the original source of the definition files, and (v) a description of how the files or code had been changed from the original source. All of these actions would have constituted a violation of the Artistic License.

The court solidified the concept that even though the copyright holders of the software at issue offered the software for free that did not mean that valuable benefits, including economic benefits, would not ensue. The court stated that the originator may enhance its reputation or increase market share by offering certain components for free. Additionally, the court recognized that improvements and bug fixes may be obtained faster and from experts in the community of programmers.¹⁰

In ruling upon the matter, one of the threshold questions for the court was to determine whether the terms of the Artistic License are conditions of the license or covenants contained in a contract. The court noted that a copyright owner who grants a nonexclusive license to use his copyrighted material waives his right to sue the licensee for copyright infringement and can sue only for breach of contract. The court further stated that if a copyright license is limited in scope, and the licensee acts outside the scope, the licensor can bring an action for copyright infringement. The distinction regarding a condition or covenant is important, because the remedies that are available to a Plaintiff will hinge on the type of claim that can be brought. For instance, a breach of contract action could be claimed, where damages would be hard to prove by one who offered his software for free, or a claim could be filed for infringement where, at least, injunctive relief can be obtained, i.e., to seek a court order to stop the infringing activity of Katzer.

The court had no trouble finding that the terms of the Artistic License held various conditions of use which, if breached, would be outside the scope of the granted license and thus, a case was made for copyright infringement rather than just breach of contract.

Significantly, the court stated further that

This case should stand as a beacon of understanding to all software developers who use open-source licenses that there are licensors that will jealously guard the terms of the open-source license and make that free software very expensive.