OSBC: Life at the edge of the GPL

Most clients who want to combine GPL and proprietary code, Norman said, do not have an open source business model in mind. But the idea of creating a mixed GPL/proprietary software product is difficult and expensive. Step one for the lawyer is to explore the reasons behind the idea. The question is: "Why do you want to do something unusual instead of complying with open source disclosure requirements?" Only if the client says, "We can't open source this," does Norman recommend what he calls "shimming," which he defines as "programing practices and architectures that reduce the risk that independently created proprietary code might be deemed a derivative work based upon some other code that is intended to operate with such proprietary code." Shimming includes both procedural shims, which are development practices, and substantive shims, which are design decisions.

The GPL's reciprocity requirements rely not on any technical criterion, but on the legal definition of a "derivative work." The definition is actually consistent across countries. Norman surveyed the law in US, Europe, and Asia, and found "little substantial difference." While the definition is consistent, it's also broad, often surprisingly broad. Case law shows that derivative works can come into existence easily, whenever pre-existing work is either incorporated into new work or modified.

Two cases show the wide reach of the derivative work concept. A.R.T Company sold products based on unmodified postcards, and in one case was found to be creating a derivative work. (Another case found that A.R.T.'s product consisting of a postcard mounted on a tile was not infringing, creating a conflict between two U.S. circuit courts.) In another case, Midway Manufacturing Co. v. Artic International, Inc., the court found that selling a hardware speed-up kit for an existing arcade game was creating a derivative work of the game software, even though the defendant did not copy or modify the original game software. Courts use the test of "access and substantial similarity." If the alleged infringer had access to the copyrighted work, and even parts of the alleged derivative work are substantially similar, then, according to the test, it's a derivative work. Applying the idea to software, "proprietary code may incorporate non-proprietary code in non-obvious ways," Norman said.

"There are built in to most computer languages directives that cause code to be combined," he said. The C preprocessor's #include directive is one example. "I've seen hundreds of thousands of lines of code incorporated with one include." In one example, a proprietary program used a widget class's API, and the widget class, using a header file, incorporated code from a system library. "This whole thing becomes a derivative work," he said.

Distribution or not?

If a combination of GPL and proprietary code is only for in-house use, some clients decide simply not to redistribute it. The GPL's reciprocity requirements apply only in distribution. However, distribution could happen in a lot of ways. Does depositing source code in escrow count as distribution? How about an acquisition that's structured as a sale of assets from one company to another? "Relying on no distribution is very dangerous. There are a lot of situations where distribution can happen but you wouldn't think of it as distribution," Norman said.

The other approach is what Norman recommends. "Don't create a derivative work and then you won't have a problem." He said that some open source advocates say, "You're violating the spirit or the purpose of the GPL." But in the long run, allowing a license to reach out too far could enable proprietary vendors to apply unwanted terms to open source code. "If the end user is not creating a derivative work, not only are the license terms not being triggered but you don't want them to be triggered,"

Fallacies

In the years that developers have been using and discussing the GPL, some have developed a false sense of security about when they're creating a derivative work. Just using an API may or may not create a derivative work. The purely functional aspects of a function call are not copyrightable. However, Norman says, even minor non-functional aspects of an API, such as the sequence of fields in a structure, are probably copyrightable. And just using an API can result in bringing thousands of lines of code into your application. Another fallacy is the often-heard, "We can avoid any problems if we use dynamic rather than static links," However, dynamic linking by itself does not automatically avoid creating a derivative work.

Some US circuits ignore extremely small copying under the so-called "de minimis" exception. However, Norman said, "it would almost never cover code," There's no sure test for what is or isn't de minimis copying, and one module or section of a program could be found to be a derivative work. "Even if the whole project is not substantially similar, one module may be substantially similar," he added.

The clean room

With the broad standards of what is a derivative work, combined with the ways that software can mingle at build time, "derivative works practically create themselves," Norman said. In order for a combined product not to be a derivative work, developers need to take specialized and expensive measures. Avoiding creating a derivative work is not something to do in the ordinary course of business. Shimming requires the same clean-room techniques that software companies use to protect themselves when doing reverse engineering. Building a combined product cleanly "really has to be worth it," Norman said. "If you have someone who has never done a clean room before you're going to spend time getting them up to speed." Besides the development costs, there's some publicity cost. "In any shimming scenario you may get some negative PR," he said.

The wrong way to do shimming is simply to build a wrapper, implementing essentially the same interface as the GPL software, then communicate with the wrapper. It doesn't work because the wrapper becomes a derivative work, then the code that talks to the wrapper does too. In practice, two development teams need to work side by side, but not in direct communication with each other. One team handles GPL code, the other handles the proprietary code, and the two communicate only through the legal department, which acts as filter.

They have to be kept separate, Norman says, because, "Programmers like to borrow just like lawyers. How often do you borrow from somebody else's brief?" The filtering has to block any knowledge about creative expression from making its way across the barrier. Since anyone could have seen the GPL code, "We have a set of programmers who verify under affidavit that they've never looked at this code before." The clean room developers' access to the Internet has to be monitored, or better yet, blocked. "It's a fairly cumbersome technique, but most software companies have done some kind of clean room before," Norman said.

NDISwrapper is an example of another safe approach, Norman said. A network device driver originally written and compiled for Microsoft Windows cannot be a derivative work of Linux. NDISwrapper itself is GPL-licensed, and probably a derivative work of Linux (it's very difficult to make a kernel module that isn't). The API used in the Windows driver clearly has nothing to do with the copyleft API.

Another approach is to split the GPL code into a server process and put the proprietary code in the client. However, this is unlikely to work if the server and client are distributed together on the same CD, relying on what the GPL calls "mere aggregation." Any "intimate communication" between the server and client could also create a derivative work, Norman said. The last approach is to time-shift the creation of a derivative work to the end user. An example is the NVIDIA proprietary device drivers for Linux, which the company distributes separately from the kernel. This only works for technical or hobbyist end users, not for an integrated product. There's also a potential patent problem: distributing two pieces that, when combined, infringe a patent constitutes contributory infringement, Norman said later.

A problem shimming scenario is using it to attempt to undo a previous decision to combine software. It could be "admitting that what you did was problematic." If possible, try to buy a exception from the copyright holder instead, Norman said. Shimming is possible and might even be necessary, as in the case of third-party code that can't be relicensed. But the lesson is that companies will save time, use fewer developers, make a simpler product, and avoid legal bills just sticking with the copyleft.