Where is GDB going

Where is GDB going

[Andrew Cagney]

Just FYI,

I'm currently aware of three significant and ongoing architectural
developments in GDB (I use the word `ongoing' loosely as like any work
it suffer from fits and starts):

	o	mi/libgdb/cli

		An interface for building better
		and more robust GUIs.  If is signficant
		as it involves separating the CLI
		from the core of GDB.

	o	multi-arch

		Allowing GDB to debug more complex
		targets containing several architectures

	o	async/event-loop

		Eliminating the assumption that
		the world stops when the target

Beyond that I also know of some more localized development (C++
cleanup/revamp, harvard/segment architecture discussion, ...).

	Andrew

Re: Where is GDB going

[Quality Quorum]

On Fri, 23 Feb 2001, Andrew Cagney wrote:

> Just FYI,
> 
> I'm currently aware of three significant and ongoing architectural
> developments in GDB (I use the word `ongoing' loosely as like any work
> it suffer from fits and starts):
> 
> 	o	mi/libgdb/cli
> 
> 		An interface for building better
> 		and more robust GUIs.  If is signficant
> 		as it involves separating the CLI
> 		from the core of GDB.
> 
> 	o	multi-arch
> 
> 		Allowing GDB to debug more complex
> 		targets containing several architectures
> 
> 	o	async/event-loop
> 
> 		Eliminating the assumption that
> 		the world stops when the target
> 
> Beyond that I also know of some more localized development (C++
> cleanup/revamp, harvard/segment architecture discussion, ...).

I am playing with (1) the idea of rewriting it in C++, the thing got grown
complex enough to justify these efforts (I suppose it may provide a
good pay off into multi-arch) and (2) with the idea of separating native
and cross-debugging in the process, while preserving the common interface
and structure.

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, (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. So, I am staying quite discuraged from working in
this area at all. 

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: Where is GDB going

[Steven Johnson]

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

Re: Where is GDB going

[Quality Quorum]

On Mon, 26 Feb 2001, Steven Johnson wrote:

> 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?  

I hope I misunderstood RMS, however, I had asked him the same question
in a few variants, and response was about the same. I must note that 
(1) English is not my native language though and (2)I am not a lawyer.
 
> > (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.

I agree that there should be a line in the sand, however, currently 
it is way far to the left. If people have intellectual property and 
trade secrets hardwired into their hardware, then they should be allowed
to protect these secrets from disclosure by writing closed library 
obscuring details of their stuff. Otherwise, I would not be 
surprised that say GPL 4.0 code would require verilog code of all chips 
it is driving to be GPLed too.

> > 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.

I can only hope.

> Regards,
> Steven Johnson

Thanks,

Aleksey

Re: Where is GDB going

[Per Bothner]

Quality Quorum <qqi@world.std.com> writes:

> I agree that there should be a line in the sand, however, currently 
> it is way far to the left. If people have intellectual property and 
> trade secrets hardwired into their hardware, then they should be allowed
> to protect these secrets from disclosure by writing closed library 
> obscuring details of their stuff.

Of course they should be.  RMS would agree 100%.  But you're missing
the point: if people make that choice, they have no right to expect a
free ride from Free Software.  What does Free Software (or the World
for that matter) gain by making it too easy for people to keep their
intellectual property secret?  The whole point of GNU to encourage
openness, not trade secrets.

Anyway, discussion about the morality of the GPL are not appropriate
to this mailing list.  Concrete questions about the licensing
implications of using Gdb remote stubs, probably ok, I guess.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Where is GDB going

[Quality Quorum]

On 25 Feb 2001, Per Bothner wrote:

> Quality Quorum <qqi@world.std.com> writes:
> 
> > I agree that there should be a line in the sand, however, currently 
> > it is way far to the left. If people have intellectual property and 
> > trade secrets hardwired into their hardware, then they should be allowed
> > to protect these secrets from disclosure by writing closed library 
> > obscuring details of their stuff.
> 
> Of course they should be.  RMS would agree 100%.  But you're missing
> the point: if people make that choice, they have no right to expect a
> free ride from Free Software.  What does Free Software (or the World
> for that matter) gain by making it too easy for people to keep their
> intellectual property secret?  The whole point of GNU to encourage
> openness, not trade secrets.

I do not think that I am missing the point. So, far GNU stuff was 
an enabling technology allowing a bunch of a small guys to pool
resources and provide ourselves with tools and systems where big 
dogs for years did not provide anything suitable and always overpriced.
However, most of the people who use GNU tools in embedded space 
are doing it to earn living off their PROPRIETARY applications being
developed/debugged with GNU tools. If GNU is going to become a
social engineering tool (as you just confirmed) it is going to die - 
this is just an opinion of information age's joe-six-pack, I am
interested in any more discussions on this topic.


> Anyway, discussion about the morality of the GPL are not appropriate
> to this mailing list.  Concrete questions about the licensing
> implications of using Gdb remote stubs, probably ok, I guess.

It was you idea to discuss this matter under this angle. I had 
a very simple question I would like to be either firmly confirmed or 
firmly denied. If I have i386-stub.c (which is public domain) linked with
my evil-proprietary-system then it will be breach of GPL 3.0 to debug
my evil-proprietary-system with GDB using GDB remote protocol.

So, far it was confirmed, while not that firmly.


> 	--Per Bothner

Thanks,

Aleksey

correction. Re: Where is GDB going

[Quality Quorum]

On Mon, 26 Feb 2001, Quality Quorum wrote:
> ... 
> I am interested in any more discussions on this topic.

It should be read:

I am not interested in any more discussions ...
 

Thanks,

Aleksey
 

Re: Where is GDB going

[Per Bothner]

Quality Quorum <qqi@world.std.com> writes:

> If GNU is going to become a social engineering tool ..

It has been, since it was launched in 1984.  Check www.gnu.org.

> It was you idea to discuss this matter under this angle.

No, you were whining that the GPL 3.0 might be preventing you
from using Gdb, and complaining this would be wrong.

> I had 
> a very simple question I would like to be either firmly confirmed or 
> firmly denied. If I have i386-stub.c (which is public domain) linked with
> my evil-proprietary-system then it will be breach of GPL 3.0 to debug
> my evil-proprietary-system with GDB using GDB remote protocol.

This cannot be confirmed, since GPL 3.0 does not exist.

I would not worry about GPL 3.0.  It is a hypothetical problem.  Your
concern should be whether GPL 2.0 allows you to do what you need to
do; I believe it does.  If a future GPL 3.0 is too restrictive, you
always have the option of sticking with an older version of Gdb.
The GPL does allow you to create your own fork, if you want to,
from say Gdb 5.0.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Where is GDB going

[Quality Quorum]

> 
> I would not worry about GPL 3.0.  It is a hypothetical problem.  Your
> concern should be whether GPL 2.0 allows you to do what you need to
> do; I believe it does.  If a future GPL 3.0 is too restrictive, you
> always have the option of sticking with an older version of Gdb.
> The GPL does allow you to create your own fork, if you want to,
> from say Gdb 5.0.

This was my point, there is no sense for me do anything new in this are
until these issues are firmly resolved one way or the other. Thank you for
reiterating.

> 	--Per Bothner

Thanks,

Aleksey

Re: Where is GDB going

[Steven Johnson]

Quality Quorum wrote:
> 
[SNIP]
> 
> > Anyway, discussion about the morality of the GPL are not appropriate
> > to this mailing list.  Concrete questions about the licensing
> > implications of using Gdb remote stubs, probably ok, I guess.
> 
> It was you idea to discuss this matter under this angle. I had
> a very simple question I would like to be either firmly confirmed or
> firmly denied. If I have i386-stub.c (which is public domain) linked with
> my evil-proprietary-system then it will be breach of GPL 3.0 to debug
> my evil-proprietary-system with GDB using GDB remote protocol.
> 
My take is that as long as you do not ship your final product with
i386-stub.c in use, then there is no GPL violation.  As far as I
understand from my reading of the GPL the only requirement is that you
distibute (or have available on request) source to GPL programs and
programs that incorporate GPL Licenced code.  If i386-stub.c is only
used for development and never with the intent of giving your program
features once released then its use would not constitute a breach of the
GPL in Law or in Spirit.

As far as discussing this on the GDB list, I think it is appropriate and
Necessary.  I agree it should not become a philosophical debate.  We
still have two fairly major questions that need answering:

1.  Does using the RSP require the program using it be a GPL Program? 
   My Take: Id be surprised if this was so. (unless you used a GPL Stub
and distributed your program with it included).
2.  Does linking GDB to Closed Source proprietary libraries constitute a
GPL Violation.
   My Take: Yes it does.

Of these I think question 2 is the most important and needs to be put to
bed before V5.1 of GDB is released.  If they turn out to be GPL
Violations then something should be done to rectify them by their
contributors.  

Whatever the final answer is to Question 2, it needs to be documented in
lay terms for future contributors, so that the rules (and line in the
sand) are clear.

Steven Johnson