This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]