This is the mail archive of the gdb@sourceware.cygnus.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: gdbstubs library posted at sourceforge


Jim:

Jim Kingdon wrote:

> > I just moved my gdbstubs library to sourceforge.net.
>
> Cool!  I've added a link from http://sourceware.cygnus.com/gdb/ - at the
> bottom of the page with the other links.

Thanks!


> > The release license is LGPL.
>
> Are you sure you want this rather than public domain (as the stubs in the
> GDB distribution) or XFree86-style?  I suppose maybe it is a moot point
> if people leave out the stubs when they actually ship code, but in
> general, the LGPL's requirement that people make available .o's makes it
> somewhat impractical for many embedded applications.

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 don't want to force users to divulge the non-gdbstubs parts of their
     application if they don't want to
   * 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
   * I want to encourage contributions to the stubs
   * I don't want someone turning gdbstubs itself into a closed source
     product (particularly the tracepoint stuff, when it arrives)

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.

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.

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  :^)

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.

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?


> > I'll also take any suggestions on how to manage the project--- I'm not
> > exactly skilled in the art of extreme multitarget development, at
> > least not yet.  :^)
>
> You've already done the hard part by being dumb ^H^H^H^H brave enough to
> start the project!  Feel free to ask if you have specific questions.

LOL.  :^)

How about pointers to a tutorial on configure?  Seems like it would be nice
to be able to do 'configure --target=x-y-z', but maybe that's overkill.

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.




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