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
work.)
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.
--Nathanael
Reply to: