This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: ser-ocd.c gone! What now?
- To: Peter dot Ryser at xilinx dot com
- Subject: Re: ser-ocd.c gone! What now?
- From: DJ Delorie <dj at redhat dot com>
- Date: Tue, 31 Jul 2001 17:10:56 -0400
- CC: gdb at sourceware dot cygnus dot com
- References: <3B66F1A0.77040683@xilinx.com>
I answer this only in the context of the GNU GPL...
> About DLLs: when you write a OCD/BDM/JTAG back-end for a debugger you
> need to have internal knowledge of how the processor works. Often you
> can only get this information by signing a NDA.
The mere fact of the NDA may disqualify that code from any GPL'd
program. Being in a separate file (the dll) may not exempt it and
gdb from being one "work" by legal definitions.
> IMHO it is dangerous to exclude DLLs. It only results in branches of the
> GDB sources.
If it is illegal to support a proprietary interface on the trunk, it
will be just as illegal on a branch. However, it may also be that it
was removed for political reasons - to convince the DLL to be free.
Anyone continuing support for a non-free dll is then doing a
disservice to the gdb community, by making it easy for proprietary
solutions to remain proprietary.
> A DLL itself is only useful with the corresponding cable/hardware. The
> DLL often relies on additional drivers provided by the OS (e.g. parallel
> port). In that sense you could also say that the DLL gets part of the
> operating system as soon as it is installed.
The GPL talks about things that are normally considered part of the
OS. I doubt anyone could convince a court that a custom
hardware/software debugging package is a normal part of the OS.
By your definition, *all* applications become part of the OS when
installed, as they *all* rely on something from the OS. Since that is
a useless legal definition (it doesn't help discriminate), I doubt the
courts would interpret it that way.
> With ser-ocd.c gone (and it probably won't be back in, will it?) I have
> to find a new method to communicate with the processor. As far as I can
> see there is no way to talk to locally attached hardware (cable at
> parallel port). I could use the remote protocol and write a dedicated
> server. This has two disadvantages. First, it is a lot of work. Second,
> it is not really efficient if GDB and the server are on the same host.
>
> Perhaps I'm missing a simple method. If anybody knows of a different
> solution please let me know.
The GPL allows this solution - distribute your changes as a patch, in
source form, without the DLL or base GDB sources. The GPL only comes
into affect when you create a binary (either gdb or the dll) *and*
distribute it, and only applies to GPL'd sources. If the patch is
entirely written by you, you can distribute just the patch under other
terms, as long as it includes *no* original gdb sources or binaries
built from them.