Re: ser-ocd.c gone! What now?

[DJ Delorie <dj@redhat.com>]

> I'm confused. Was the "old" GDB (with ser-ocd.c) and the seperately
> distributed wigglers.dll legally correct?

I'm not sure.  There was some debate about that.

> I am not talking about applications. I am talking about
> drivers. According to your definition you will not be able to use
> GDB with the remote protocol over an ethernet card that comes with
> an extra driver since the driver was not part of the OS.

Except that the ethernet *interface* is a normal part of the operating
system, and that's what gdb is using.  You can expect, for example,
winsock to exist on all windows systems, regardless of the status of
the ethernet driver.  A dll that adds a *new* interface for gdb to use
is not in the same class.

> If I understand this correctly, I can ship a compiled version of GDB
> with the corresponding source code. I also can ship (separately) a
> compiled DLL that does not come with source code (of course not
> under GPL). Is that right?

Um, no.  If the "corresponding source code" you claim is not the
"complete source code" then the GPL won't let you distribute that
binary.  In this case, the source for that dll may be part of the
"complete source code" from the GPL's viewpoint.  Without that, you
have not really shipped the corresponding source code to the *work*
that is gdb+dll.

> I would like to point out that we want to contribute to the open
> source project.

That is good.  Convincing the dll to become open source is a way of
contributing.

> and we would like to integrate them in the main source tree.

That may not be possible if they depend on proprietary code (the dll).

Another idea is to write a dll that converts the proprietary API to
one of gdb's standard APIs, like the remote protocol, so that custom
code is not needed in gdb?