How To Break The GPL - Direct Functionality versus Copyrighted Expression

Dennis E. Hamilton infonuovo at
Sun Mar 5 15:54:03 UTC 2000

I am concerned that moving this discussion toward "direct functionality" is
completely leaving the domain of Copyright, at least as it has been dealt
with in the United States.  So long as the GPL is solely a license of some
or all of the exclusive rights that are possessed by an owner of a
copyright, we should confine ourselves to copyrightable subject matter.

My sense of this is that it is important to recognize that copyright applies
to *expressions* fixed in tangible forms.  (e.g., an actual source code,
this e-mail note as rendered by a computer, etc.)  Generally, the idea,
procedure, or "function" expressed in a work protected by copyright is not
protected by copyright.  It may be protected by other means, but not

In the U.S. copyright history there has also been a principle of utilitarian
necessity.  That is, if the ways of expressing a particular idea or concept
are severely limited, then a court is likely to rule that such expression is
not protected by copyright.  This seems to be so one cannot copyright
language and one cannot use copyright to obtain the power of a patent by
round-about means.  Note that this principle did *not* protect Borland in
the Lotus suit over replication of the Lotus 1-2-3 look-and-feel as a "skin"
for Quattro Pro.  At the same time, it is generally agreed (and tested in
courts a little) that APIs are not protected works from the standpoint of

Now, software presents some novel conditions around expression, mention,
usage, and performance.  We run into that in discussions of derivative
works.  It is important to remember that whatever the FSF claims about this
regarding the GPL, this has not, as far as I know, ever been upheld in a
court of law.

Yes, there is a cloud around this because of the lack of a definitive
precedent (as far as I know).  This means that users of GPL's works in
conjunction with non-GPL'd works are appropriately wary.  On the other hand,
relying on this to obtain constraints on the use of a work that may not be
ones right to restrict is not particularly useful either, since this
supposed exclusive right around usage or "co-operation" can vanish in the
twinkling of an eye.

So long as the GPL is solely a copyright license, it cannot assert an
exclusive right that the distributor of the work doesn't possess as a matter
of copyright.  (This is why there *are* EULAs and licenses for the *use* of
commercial software.  Copyright alone is insufficient to prevent
re-engineering and a host of other things that EULA-bound licensees agree
not to perform.)

I just want to suggest being mindful that we are talking about copyrighted
subject matter here and not other things.   When we are discussing a
thin-ice area (e.g., derivative works that don't involve alteration of the
original in any way but depend on the function expressed), it is not prudent
to head farther into the center of the lake for resolution.

-- Dennis

Dennis E. Hamilton
mailto:infonuovo at
tel. +1-206-779-9430 (gsm)
fax. +1-425-793-0283

-----Original Message-----
From: Ken Arromdee [mailto:arromdee at]
Sent: Saturday, March 04, 2000 23:12
To: license-discuss at
Subject: Re: How To Break The GPL

On Sat, 4 Mar 2000, David Johnson wrote:
> But what does "direct functionality" mean in terms of licensing? I can see
> functionality being added to a GPL application in ways that both would and
> would not violate the GPL. If I wrote a new plugin for Gimp, it would add
> functionality, but would only have runtime linkage. But putting the exact
> code within the body of the Gimp source code cause it to come under the
> of the GPL.

According to RMS, plugins are *also* derivative works, so both your examples
would come under the GPL.  (Which produces the odd result that it is legal
to write a GPL plugin for Internet Explorer but not for Netscape 4, since
Internet Explorer comes under the system component exception.)

More information about the License-discuss mailing list