This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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. ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |