RE: gdbstubs library posted at sourceforge

["Scott Howard" <scotth at estc dot com>]

The Gnu iostream package is licensed under GPL; however, the documentation
includes the following text:

As a special exception, if you link this library with files compiled with a
GNU compiler to produce an executable, this does not cause the resulting
executable to be covered by the GNU General Public License. This exception
does not however invalidate any other reasons why the executable file might
be covered by the GNU General Public License.

Would something like this do the trick?

-----Original Message-----
From: crossgcc-owner@sourceware.cygnus.com
[mailto:crossgcc-owner@sourceware.cygnus.com]On Behalf Of David Williams
Sent: Friday, January 28, 2000 5:07 PM
To: William Gatliff
Cc: gdb@sourceware.cygnus.com; crossgcc@sourceware.cygnus.com
Subject: Re: gdbstubs library posted at sourceforge




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.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to
crossgcc-unsubscribe@sourceware.cygnus.com



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com