Re: Where is GDB going

[Steven Johnson <sjohnson at neurizon dot net>]

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.

This is wrong, and should not be tolerated or encouraged.

> So, I am staying quite discuraged from working in
> this area at all.
> 

I would be very discouraged as well, if your first point is as i've
interpreted it.  But this can not be so as it is non-sensical.  The
second point shouldn't discourage you, it should enourage you that maybe
these abuses are going to be prevented.  At the end of the day, there
are no readilly available processors that have GPL microcode or
execution units, so A Line has to be drawn, I think point 2 is valid,
but no one could convince me of the rationality of point 1.  (Or in fact
that you could only run GPL code on processors with GPL microcode.)

> 
> Thanks,
> 
> Aleksey

Regards,
Steven Johnson