Re: licensing issues

[Stan Shebs <shebs at cygnus dot com>]

   Date: Thu, 9 Dec 1999 11:32:09 -0500 (EST)
   From: Quality Quorum <qqi@world.std.com>

   I am developing replacement/enchancement for gdbserver. The major 
   difference is that it will allow to debug not only process on 
   the remote machine, but it also allows to debug an embedded system
   attached to the remote machine, plus it has support for bigger 
   amount of recent quirks.

This would be great to have.  Lately I've been contemplating what
should be done with gdbserver - it's a very useful idea that has
been somewhat neglected.

   I have a question  related to GPL. I posted it earlier and I got no 
   response. I am posting it again in a hope that ones in the know,
   would respond. I would like to allow a possibility to attach
   debuggers with proprietary interfaces (e.g macraigor wiggler).

Sorry, I was planning to reply to your first message, but it got lost
in a recent snowstorm of mail.

My belief is that calling a proprietary DLL to access a specialized
piece of hardware is allowed by the letter of the GPL, although it is
not really consistent with the spirit; the user is unable to fix the
DLL or to write a replacement, should there be a problem.  However,
such a DLL is really a driver for the hardware, and it's generally
agreed that the GPL status of a program does not affect any drivers it
happens to use.

   I would like to publish my work under GPL, however, it is unclear 
   to me whether my intention to allow proprietary stuff (in the form
   of shared libs) in is in line with GPL. In my view it is: I put 
   .h file defining interface into public domain and there is no 
   need for anybody to use or link any other part of GPL'ed code in
   proprietary library: there are only three callback functions, which 
   are passed as pointers through the API, and no data sharing.

If you want to link directly with proprietary libraries, then the GPL
is not right for you.  Instead, use something like the BSD license,
which has fewer restrictions, and no constraints on intermixing with
proprietary code.  From a practical point of view (setting aside my
rabid fanatic GNU maintainer hat :-) ), it would be very useful to
have something like gdbserver that can be used with a variety of
proprietary libraries, such as emulator interfaces and cycle-accurate
simulators.  Yes, some nefarious software hoarder could take the
program, make improvements, and not share them; but the program is
really too simple for anybody to care.  We also have a precedent in
that the example stubs are public-domain, and don't have any kind of
license at all!

A beneficial side-effect for GDB is that it removes some of the
pressure to try to link in proprietary interfaces to hardware;
instead, they can be linked with "alekseys-gdbserver", then the user
only needs GDB to have the standard protocol.  Also, the server can
live on a different machine, such as a Windows box in the lab
connected to the targets, while you get to it from the GDB on your
Linux system at home.

So I think this would be a great project, and if you undertake it,
I'll help out in any way that I can.

								Stan