Re: gdbstubs library posted at sourceforge

[David Williams <davidwilliams at ozemail dot com dot au>]

William Gatliff wrote:

> <snip>
> Actually, that's a good question.  The following are my concerns, which I
> think the LGPL addresses, although not perfectly.  I'm open to differing
> opinions and suggestions, though, as I'm no expert:
>
>    * I want to encourage leaving the stubs in production embedded systems

I want this as well.

>
>    * I don't want to force users to divulge the non-gdbstubs parts of their
>      application if they don't want to

A must!

>
>    * I want to avoid proprietary, closed-source modifications to the stubs;
>      minor tweaks to overcome hardware and security issues are fine, but
>      nothing that makes it work better with gdb than the public sources

Good.

>
>    * I want to encourage contributions to the stubs

I agree.

>
>    * I don't want someone turning gdbstubs itself into a closed source
>      product (particularly the tracepoint stuff, when it arrives)

Agreed.

>
>
> Straightaway, the first, second and last points seem to rule out GPL.
>
> My problem with the public domain distribution of the gdb-distributed stubs
> is that they don't encourage the kind of thing I'm doing--- cooperative
> building of more advanced stubs, to try and make gdb an increasingly
> attractive debugger for embedded systems.  The MIT license seems to have a
> similar problem, in that it allows users to modify gdbstubs without
> returning those modifications to the community.
>
> As I understand it, linking an LGPL work with a proprietary application
> doesn't force one to divulge the source for the application, but they must
> divulge modifications to the LGPL'd work, so I'm pretty good so far.  The
> .o requirement would come up if someone wanted to update the stubs without
> updating the application, but that doesn't seem like a circumstance that's
> likely to come up, at least not on the kinds of embedded systems I'm
> familiar with. [note: this is an open invitation for experiences to the
> contrary!]  So, it still seems ok, at least in my current world.
>

As far as I understand LGPL license (having read it several times now) as a
minimum if the LGPL gdbstub code is included in a product of mine then I have
to make the source for the gdbstub and the object code available so that users
can modify the stub code and re-link with the supplied objects to create a new
"executable". Making these available is not really a problem for me. I assume
referring the user to a suitable web site (of mine) where such source and
objects would be available would be satisfactory. The problem for my users is
then that the "executable" as such needs to be written into flash memory. To do
this the user would have to pull apart the device and then connect two pins on
the PCB and then use some other software running on a PC (not normally supplied
to the user) to download and program the flash memory with the new image. This
is normally done as a factory proceedure. How far do I have to go to meet LGPL
requirements???

>
> Maybe CEPL is a closer fit for what I'm after, because it accomplishes
> everything the LGPL does *and* eliminates the need for .o's?  I could go
> there.
>

What is CEPL? Where can I get a copy?

>
> I suppose that I can also offer alternate licenses for people who want to
> make proprietary modifications, but I'm hesitant to do so because:
>
>    * it's a headache, and I don't want to pay that much attention to the
>      process
>    * I don't want to get into disputes over ideologies with contributors
>    * I'm having trouble seeing what a "proprietary" extension might
>      actually be
>    * I don't want "forks" of proprietary extensions with nifty features not
>      found in the public code base
>    * it's just not good karma  :^)
>

No problem with these comments.

>
> Several other people have expressed concerns with the LGPL to me
> privately.  I would appreciate said people (you know who you are!) making
> the background for their objections known publicly, so that we can arrive
> at a workable solution.  I'll follow consensus as long as it's the most
> realistic solution available for the motivations I list above.
>

See above.

>
> Myself, I don't think I have a problem with LGPL because I don't intend to
> make proprietary mods to gdbstubs, and I don't expect my clients (who get
> source anyway) or customers (who wouldn't know what to do with it) to want
> to update their stubs.  My products don't ship with stabs information
> either, so the stub is of little value except for engineering-level
> testing.  I admit that my avoiding the possiblity of a .o distribution
> doesn't really eliminate it, however...
>
> I am PERFECTLY HAPPY to select a different license, as long as it's one
> that doesn't permit proprietary mods to gdbstubs itself.
>
> Ideas?

If CEPL avoids problem of .o as you suggest then sounds better. However I
better find out what CEPL is first!
<snip>

Dave Williams.