Re: Where is GDB going

["Peter Reilley" <micrio at mv dot com>]

I think that there are some good points here.


-----Original Message-----
From: Steven Johnson <sjohnson@neurizon.net>
To: Quality Quorum <qqi@world.std.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Date: Sunday, February 25, 2001 6:48 PM
Subject: Re: Where is GDB going


>Quality Quorum wrote:
>>
>>
>> However, I had a short but unpleasant private discussion with RMS about
>> GPL 3.0 from which I concluded (1) that it may preclude proprietary
>> software debugging with future versions of GDB by closing protocol
linking
>> loophole in GPL 2.0,
>
>Im guessing that you mean linking to a GPL Program, that is necessary
>for  your program to work, using a communication protocol (say, on top
>of TCP/IP) instead of binary linking (say, using a loadable/linked
>library) would imply that the connecting program needs to be GPL?
>
>This does not make sense, and given the history of the FSF and the GPL
>where they created free alternatives to commonly available Unix
>Utilities (some of which could inter-communicate using comms protocols)
>is also paradoxical.  If this was the case then if Samba used GPL3.0
>then you would not be able to share files with MS Windows unless MS
>Windows was GPL!!  Bye Bye Samba :(  I Must have misunderstood what you
>mean here, could you explain what this loophole is?
>
>> (2) that it will be for sure impossible (and it is
>> may be illegal right now) to link gdb with proprietary software driving
>> various hardware probes.
>I Agree with this.  There are way too many vendors making Windows DLL's
>for their proprietary debug Hardware, and cluttering GDB with Hooks to
>those DLL's.  This is (in my opinion) a clear brach of the GPL (in
>spirit if not in word).  These vendors are riding off the back of the
>work done by and for the FSF without contributing anything back.  And in
>some cases these vendors are obstructionist in even allowing people to
>write properly GPL'd alternatives to their Closed Windows DLL.  I don't
>think it should be allowed, or supported by the GDB community and Any
>patches to GDB that do this trick should be rejected out of hand. See
>ser-ocd.c and v850ice.c (in alphabetical order) for examples of this in
>the current GDB source.  These vendors should either open up their
>direct interfaces to their debuggers or they should not expect a free
>debugger in GDB.  This is a classic "Free as in Beer" not "Free as in
>Freedom" situation.  There are also other Vendor specific versions of
>GDB with similar closed interfaces.


There really is no need for including interfaces to targets that do not
have GPL'ed monitors in the gdb standard source tree.   They are of
no use unless you have bought the hardware.   On the other hand if
we eliminate all such interfaces they there may be only a few
interfaces left, which would decrease the value of gdb for everyone.

If you are suggesting that gdb cannot be used with these proprietary
devices at all then gdb fails in one of the GNU ideals, that is to provide
free tools that replace commercial products.

This is a fine line to draw.   Is communicating to a proprietary
monitor OK if it is by ASYNC or TCP/IP but not if it is by
way of a library?   This is a subject that it is easy to get
religious about.   Unfortunately, at the end of such wars
most people are dead.   If we can accommodate the feelings
and needs of everyone in this community then we will
make progress together.   I say, strip out the proprietary
interface code and allow the manufacturers to provide their own
GPL'ed patched that satisfy their needs.   That should
keep most people happy.

Pete