Open Source Business
, held at San Francisco's Palace Hotel, draws a lot of
lawyers, from both corporate legal departments and law firms. Continuing
Legal Education (CLE) credit is available. Jeff Norman, a partner
at the law firm of Kirkland & Ellis
, delivered a talk on "Shims and
Shams: Firewalling Proprietary Code in a Copyleft Context."
This talk gives some insights into the current thinking on how difficult it
can be to create a combined software product using
both copyleft and proprietary code.
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,"
"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
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,"
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,"
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
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
to post comments)