How To Break The GPL - Direct Functionality versus Copyrighted Expression

Sun Mar 5 16:59:07 UTC 2000

Dennis, People,

Having read your email about "direct functionality" concerns, I think I share 
your views.  Taking on board what you said, could you see an opportunity to 
make distictions within derived works, say for example, Derived by making use 
of, and derived by modifying.  From another angle.  Making use of the 
copyrighted code, distinguished from Extended or changing the copyrighted code.

Perhaps it is opportune that I explain where I am coming from.  I have 
developed some software that I want to release as open source.  My background 
is not legal, and I am trying to find away to reduce my view of how the code 
should be treated into sensible wording.  Basically I am happy to release the 
code such that others may do with it as they please, so long as if the 
functionality of the code is changed, then those changes become part of the 
code.  I have no interest in other code that may use this code to serve the 
other code's purpose.  I also have no problem if this code is included 
(compiled or dynamically linked) as part of a larger commercial proprietary 
code.  It is not my intent to constrain "derived by making use of" code by this 
code's licenseing, other than 1) indicating that this code was used, and 2) if 
any changes were made to this code, then those changes become part of this 
code. 

I am actually quite frustrated.  In my head, it is so clear what I want to 
achieve, but I cannot get it to jive on paper.  Also what I am discussing is 
not strictly GPL, perhaps it needs a different subject name so as not to dilute 
the GPL interest.

Jonathan

> 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 copyright.
> 
> 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 copyright.
> 
> 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
> InfoNuovo
> mailto:infonuovo at email.com
> tel. +1-206-779-9430 (gsm)
> fax. +1-425-793-0283
> http://www.infonuovo.com
> 
> -----Original Message-----
> From: Ken Arromdee [mailto:arromdee at rahul.net]
> Sent: Saturday, March 04, 2000 23:12
> To: license-discuss at opensource.org
> 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
> some
> > code within the body of the Gimp source code cause it to come under the
> purview
> > 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.)
> 

   Sometimes I sits and thinks, and sometimes I just sits.
      --  Spike Milligan

Jonathan Marks, http://www.novatek.co.nz
11360 Clipper Court, Richmond, B.C. V73 4M3, Canada
Tel:(604) 274-2277, (604) 805-4035. Fax: (707) 221-3689 