[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using a script licensed under GPL in an application licensed under a

From: Stefaan A Eeckels
Subject: Re: Using a script licensed under GPL in an application licensed under a license that's not compatible with GPL
Date: Fri, 15 Dec 2006 23:11:29 +0100

On Fri, 15 Dec 2006 16:05:41 +0100
David Kastrup <> wrote:

> Stefaan A Eeckels <> writes:
> > You don't get it - one cannot write a (useful) 'C' program without a
> > few #include statements (which will cause the preprocessor to
> > "import" the header files). If that makes the source code a
> > derivative work of the header files, you'd have to ask the
> > permission of AT&T, and Sun before you'd be allowed to write even
> > just the following line (on my Solaris system):
> The usual consensus seems to be that the resulting binaries being
> derivative works of the header files is irrelevant for typical header
> files since they contain definitions that have to be "just so", and
> thus are void of copyrightable creative content.

Quite a lot of creative work can be done with macros :)

> For similar reason, C++ header files are believed to be more murky
> legal ground, particularly where templates are being involved.  But
> also extensive class and inline information obviously is not free for
> the taking just because it is compiled by inclusion.

The problem is not the compiled program, but the source. Our OP says:

> The scripts are in ruby, basically what I do
> is:
> require 'gpl_script'
> GplClass.do_work
> Similarly in Python I would do:
> import gpl_script
> GplClass.do_work()
> These GPL scripts are not necessary to use the application, they just
> add more functionality.

Whereupon Alfred ejaculates:

> This is clearly a deriviate work, the program changes how it works if
> you remove the GPLed library/script/whatever.  It also stops working
> without the GPLed library/script/whatever.

Factual errors (and opiate) aside, it is quite obvious that he believes
the source code to be a derivative work of the GPLed Ruby or Python
scripts. He uses functional criteria - "the program changes how it
works", instead of "does the source contain a substantial amount
of source code from the GPLed script". According to his interpretation,
source code that references other source code through an include
mechanism becomes a derivative work. 

This is why I argue that if this were to be true, programming would be
impossible. Compiled source code is clearly another matter, as it
quite easily can contain substantial amounts of material not related
to the source code itself. The fact that the compiled version of the
code might be a derivative work of, say, the C++ headers, does NOT mean
that the source code is a derivative work of the same.

The same applies to script files, where the copy in RAM that is being
interpreted, and where the GPLed script has been included for
execution would be a derivative work of both scripts. Again, that does
not mean that the original script becomes a derivative work.

Stefaan A Eeckels
And as crazy as this sounds, people tend to be able to manage systems
better if they have a good internal mental model of how the system 
works.                                              --Logan Shaw

reply via email to

[Prev in Thread] Current Thread [Next in Thread]