From: DJ Delorie <dj@redhat.com>
To: Peter.Ryser@xilinx.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: ser-ocd.c gone! What now?
Date: Tue, 31 Jul 2001 14:11:00 -0000 [thread overview]
Message-ID: <200107312110.RAA24733@greed.delorie.com> (raw)
In-Reply-To: <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.
next prev parent reply other threads:[~2001-07-31 14:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-31 10:53 Peter Ryser
2001-07-31 14:11 ` DJ Delorie [this message]
2001-07-31 18:39 ` Peter Ryser
2001-08-01 7:03 ` DJ Delorie
2001-07-31 20:06 ` Steven Johnson
2001-08-01 6:50 ` Quality Quorum
2001-08-01 9:01 ` Peter Ryser
2001-08-01 10:06 ` Quality Quorum
2001-07-31 19:56 Peter Reilley
2001-08-01 9:29 ` Peter Ryser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200107312110.RAA24733@greed.delorie.com \
--to=dj@redhat.com \
--cc=Peter.Ryser@xilinx.com \
--cc=gdb@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox