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.

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

[..]

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

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.


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

And that's exactly where the branching starts. Get a patch from here, get a
patch from there...

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?

I would like to point out that we want to contribute to the open source
project. So all the changes we make to GDB to support the 405 will be
available as source code and we would like to integrate them in the main
source tree. The cable that we use to connect a Windows/Linux PC or Solaris
Workstation will be "open source" (i.e. you can make your own cable). The only
thing that we cannot distribute in source code (at least that's what we
believe at this moment) is the part that translates the GDB commands into
JTAG/BDM bitstreams. This would be available in a DLL as the driver of the
cable. I think that this would be a low cost solution for debugging a 405.

- Peter



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