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

Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used byGPL-incompatible apps

On Tue, 2003-05-20 at 05:15, Branden Robinson wrote:

> I am uncomfortable with some of the ramifications but I am also
> uncomfortable with totally declawing the GNU GPL by adopting and
> interpretation of it that would let people wrapper and language-bind
> their way out of the copyleft commons.

Anthony DeRobertis then said:

>At some point, we've got to draw a line where it's de-clawed. After 
>all, I think we all agree that if a shell script calls GNU grep[0], it 
>isn't required to be under the GPL.

This is the way I usually see it. :-)  Beware that this is not the FSF's 
position, or anyone else's as far as I know.  The rest of this message 
is simply *my* position.

Programming to a public, totally open interface puts no license 
requirements on the programmer.  By this, I mean an interface which is 
fully documented so that many programs could implement it, and so that 
there are no legal impediments to implementing it.  This is because the 
subsequent use of the program (via execve, shell script, or dynamic 
linking) constitutes normal, expected use of the program, rather than 
creation of a derived work.

This does not affect legal issue beyond programming to the interface.
If, for example, including header files is required to program to the 
interface, the header files must be public domain or X11/BSD-style 
licensed (since they're included in the program code when compiled) to 
allow inclusion in proprietary software.

Writing scripts for a publicly documented, freely implementable 
language like "Bourne shell script" is fine, and imposes no 
requirements.  ("Bash" is for running shell scripts, so running one 
with bash is normal everyday use.)  Writing a script specifically for 
undocumented features of "bash" would impose bash's GPL requirements, 
at least on the  distribution of the combination of the script and bash.  
(It can't be considered a mere aggregation or collection because the 
script absolutely *depends* on bash, so the combination is a derived 

Calling POSIX grep is therefore fine.  Calling GNU grep with 
GNU-grep-specific options (supposing there were any; I suspect there 
aren't) is fine only if the options are publicly documented so that they
could be implemented in other versions of 'grep'.  Preferably documented 
by the creator of the new program.  So for instance, if someone creates 
a program which uses a special GNU grep option, and says "This program
requires GNU grep to work", the program should go under the GPL.  If 
instead they say "This program requires a version of grep supporting the 
-xxx option, meaning precisely blah blah blah.  For example, GNU grep", then 
the program can be under any license.

(If there are grep-specific options, they may not be freely 
implementable.  If the only descriptions of them are under GPL or more
restrictive copyrights, they probably aren't, until someone 
reverse-engineers them using a Chinese Wall process.)

No doubt this isn't the interpretation of most people who look at this, 
but I believe it is the closest to the concept intended by the GPL.  
Using a published interface is ordinary and expected use of the original 
program, which is unrestricted.  Using a secret interface is effectively
making use of the original program's source code to make a derived work,
since the new program is intrinsicly tied up with the original program and 
useless without it.

So in regards to "declawing", this makes a *non-arbitrary* distinction, 
unlike the distinction between dynamic linking and execve() calls.  
Certain execve() calls create a combined, derived work.  Certain dynamic 
links don't.  It's a matter of whether the linkage is integral to the 
program, or not.  Admittedly the distinction must be applied carefully 
on a case-by-case basis, but that's often what makes good law.

So there's my two cents; make of it what you will.


Reply to: