* Fwd: permission to re-license strbuf subsystem as LGPL [not found] <CA+sFfMeRDQiqGhO9Y=k3tEnzdXjMx59huFE_fx6Y14cJxj1J=Q@mail.gmail.com> @ 2011-09-23 15:01 ` Brandon Casey 2011-09-23 15:36 ` Michael Witten ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Brandon Casey @ 2011-09-23 15:01 UTC (permalink / raw) To: git Oops. I forgot to include the git mailing list on the email below. I intended to include the git mailing list for two reasons. 1) so that when people replied giving there permission it would become part of the public record, and 2) because maybe someone had already done this and they could speak up before I duplicated their effort. The following people have already given their consent: Jeff King (LGPL) Avery Pennarun (LGPL) Jonathan Neider (LGPL, ZLIB, Expat, BSD) Johannes Schindelin (LGPL, BSD) Linus Torvalds (LGPL) Alex Riesen (LGPL) Marco Costalba (LGPL) Lukas Sandström (LGPL, BSD) Michal Rokos (LGPL, BSD) Thomas Rast (LGPL, BSD) The following have not yet responded (the email just went out last night): Pierre Habouzit René Scharfe Junio C Hamano Kristian Høgsberg Johannes Sixt Frank Li Shawn O. Pearce Jonathan Nieder suggested using a more permissive license than LGPL. BSD seems to have the most support. If the remaining contributors agree, then I'm fine with licensing under BSD. Anyway, here is my original email requesting permission to re-license strbuf et al so that it can be made into a library... ---------- Forwarded message ---------- From: Brandon Casey <drafnel@gmail.com> Date: Thu, Sep 22, 2011 at 11:21 PM Subject: permission to re-license strbuf subsystem as LGPL To those who have contributed to git's strbuf subsystem, I'd like to turn git's strbufs into a library. So with your consent I'd like to re-license the code in strbuf.c and strbuf.h, and any compat/ dependencies as LGPL so that I can create a strbuf library. Just skimming through strbuf.c, I'm thinking the other files that may be needed include ctype.c, compat/snprintf.c, and as little of wrapper.c as necessary (hopefully only xread). I think all of the authors are included in this email. The reason for LGPL, of course, is so that it can be linked with non-GPL code. Please offer your consent to re-license your contributions under LGPL by replying to this email. All comments welcome. Thanks, -Brandon p.s. sorry for the mostly cut-n-paste email for those who also received my email about archive-zip ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: permission to re-license strbuf subsystem as LGPL 2011-09-23 15:01 ` Fwd: permission to re-license strbuf subsystem as LGPL Brandon Casey @ 2011-09-23 15:36 ` Michael Witten 2011-09-23 17:12 ` Fwd: " Jakub Narebski 2011-09-23 22:16 ` Jonathan Nieder 2 siblings, 0 replies; 6+ messages in thread From: Michael Witten @ 2011-09-23 15:36 UTC (permalink / raw) To: Brandon Casey; +Cc: git On Fri, Sep 23, 2011 at 15:01, Brandon Casey <drafnel@gmail.com> wrote: > Jonathan Nieder suggested using a more permissive license than LGPL. > BSD seems to have the most support. If the remaining contributors > agree, then I'm fine with licensing under BSD. BSD is more permissive for only the upstream; the downstream ('end-users') get nothing. In fact, the downstream may ultimately get a license that is more restrictive on further developments---possibly even restrictions that might hinder the development of your own upstream work should you find yourself in some sort of downstream position relative to a fork. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: permission to re-license strbuf subsystem as LGPL 2011-09-23 15:01 ` Fwd: permission to re-license strbuf subsystem as LGPL Brandon Casey 2011-09-23 15:36 ` Michael Witten @ 2011-09-23 17:12 ` Jakub Narebski 2011-09-23 22:50 ` Brandon Casey 2011-09-23 22:16 ` Jonathan Nieder 2 siblings, 1 reply; 6+ messages in thread From: Jakub Narebski @ 2011-09-23 17:12 UTC (permalink / raw) To: Brandon Casey; +Cc: git Brandon Casey <drafnel@gmail.com> writes: > ---------- Forwarded message ---------- > From: Brandon Casey <drafnel@gmail.com> > Date: Thu, Sep 22, 2011 at 11:21 PM > Subject: permission to re-license strbuf subsystem as LGPL > > To those who have contributed to git's strbuf subsystem, > > I'd like to turn git's strbufs into a library. So with your consent > I'd like to re-license the code in strbuf.c and strbuf.h, and any > compat/ dependencies as LGPL so that I can create a strbuf library. That's a laudable goal. Do you plan on librarizing other universal mini-libraries, like parseopt or test-lib? I wonder if for example "perf" tool in Linux kernel sources (userspace companion to perf events subsystem) will move to using it; currently it reuses some of internal git minilibraries, IIRC strbuf and parseopt included. By the way, how the 'strbuf' from git (which I think was created among others to avoid additional external dependencies) differs from existing C (not C++) string libraries, like 'bstring'[1], The Better String Library, or the C libraries in http://bstring.sourceforge.net/features.html? [1]: http://bstring.sourceforge.net -- Jakub Narębski ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: permission to re-license strbuf subsystem as LGPL 2011-09-23 17:12 ` Fwd: " Jakub Narebski @ 2011-09-23 22:50 ` Brandon Casey 2011-09-24 6:05 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Brandon Casey @ 2011-09-23 22:50 UTC (permalink / raw) To: Jakub Narebski; +Cc: git 2011/9/23 Jakub Narebski <jnareb@gmail.com>: > Brandon Casey <drafnel@gmail.com> writes: > >> ---------- Forwarded message ---------- >> From: Brandon Casey <drafnel@gmail.com> >> Date: Thu, Sep 22, 2011 at 11:21 PM >> Subject: permission to re-license strbuf subsystem as LGPL >> >> To those who have contributed to git's strbuf subsystem, >> >> I'd like to turn git's strbufs into a library. So with your consent >> I'd like to re-license the code in strbuf.c and strbuf.h, and any >> compat/ dependencies as LGPL so that I can create a strbuf library. > > That's a laudable goal. Do you plan on librarizing other universal > mini-libraries, like parseopt or test-lib? Not at the moment. > I wonder if for example "perf" tool in Linux kernel sources (userspace > companion to perf events subsystem) will move to using it; currently > it reuses some of internal git minilibraries, IIRC strbuf and parseopt > included. I would be pleased if it was useful to them. > By the way, how the 'strbuf' from git (which I think was created among > others to avoid additional external dependencies) differs from > existing C (not C++) string libraries, like 'bstring'[1], The Better > String Library, or the C libraries in http://bstring.sourceforge.net/features.html? > > [1]: http://bstring.sourceforge.net Hmm, I forgot about bstring. I think strbuf is a little smaller in scope than bstring, perhaps less ambitious. Less abstraction, and less protection too. With strbuf, you never forget that you're dealing with C char arrays. The data structures are pretty similar, but I don't think strbuf will ever have a function like bconcat(bstring1, bstring2) instead, you'd just do strbuf_add(strbuf1, strbuf2.buf, strbuf2.len) The benefit, of course, of a bconcat function is that either bstring1 or bstring2 can be NULL (like if a previous bstring2 = bfromcstr() initialization failed). This allows you to perform a sequence of bstring operations and only check errors at the end. -Brandon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: permission to re-license strbuf subsystem as LGPL 2011-09-23 22:50 ` Brandon Casey @ 2011-09-24 6:05 ` Jeff King 0 siblings, 0 replies; 6+ messages in thread From: Jeff King @ 2011-09-24 6:05 UTC (permalink / raw) To: Brandon Casey; +Cc: Jakub Narebski, git On Fri, Sep 23, 2011 at 05:50:27PM -0500, Brandon Casey wrote: > Hmm, I forgot about bstring. I think strbuf is a little smaller in > scope than bstring, perhaps less ambitious. Less abstraction, and > less protection too. With strbuf, you never forget that you're > dealing with C char arrays. The data structures are pretty similar, > but I don't think strbuf will ever have a function like > > bconcat(bstring1, bstring2) > > instead, you'd just do > > strbuf_add(strbuf1, strbuf2.buf, strbuf2.len) I think it's spelled: strbuf_addbuf(strbuf1, strbuf2); in the current code. > The benefit, of course, of a bconcat function is that either bstring1 > or bstring2 can be NULL (like if a previous bstring2 = bfromcstr() > initialization failed). This allows you to perform a sequence of > bstring operations and only check errors at the end. There is no error checking with strbufs at all. The only thing that can fail is malloc, and in that case, we always die(). It wouldn't be too hard to make it return errors (or set a global error flag), and have any failed mallocs just leave the strbuf unchanged. Because strbufs are always in a consistent state, it would be safe to do: global_strbuf_error_flag = 0; strbuf_addbuf(strbuf1, strbuf2); strbuf_addbuf(strbuf3, strbuf1); strbuf_addbuf(strbuf3, strbuf4); if (global_strbuf_error_flag) ... The contents of the strbufs would be indeterminant, but you would never have violated any memory constraints. -Peff ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: permission to re-license strbuf subsystem as LGPL 2011-09-23 15:01 ` Fwd: permission to re-license strbuf subsystem as LGPL Brandon Casey 2011-09-23 15:36 ` Michael Witten 2011-09-23 17:12 ` Fwd: " Jakub Narebski @ 2011-09-23 22:16 ` Jonathan Nieder 2 siblings, 0 replies; 6+ messages in thread From: Jonathan Nieder @ 2011-09-23 22:16 UTC (permalink / raw) To: Brandon Casey; +Cc: git Brandon Casey wrote: > Jonathan Nieder suggested using a more permissive license than LGPL. > BSD seems to have the most support. If the remaining contributors > agree, then I'm fine with licensing under BSD. A few words of clarification. My opinion shouldn't matter much here --- I am more of a bystander and user than a contributor to strbuf. :) The main reason I suggested a permissive license is that the strbuf lib contains some inline functions and I do not want it to be complicated to use them. To comply with the LGPL, in addition to releasing any changes made to the library, distributors usually do one of a few things: a. offer the source code for your work that uses the library in addition to any binaries, b. use dynamic linking, or c. provide object files for your work that uses the library, so it can be re-linked against a modified version of the library. (b) and (c) don't handle inline functions. Luckily, there is a way out: d. only use the inline functions from within a subset of your work for which you are willing to provide source. Dynamically link to it or provide object files to allow re-linking. With that in mind, I have nothing against the use of the LGPL here (and one of the two main authors of the strbuf lib explained a good reason to prefer it over the BSD license). The inline functions in the strbuf lib are pretty small, so the above was probably not too important in the first place. Thanks, and sorry for the unnecessary noise. Regards, Jonathan ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-24 6:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CA+sFfMeRDQiqGhO9Y=k3tEnzdXjMx59huFE_fx6Y14cJxj1J=Q@mail.gmail.com> 2011-09-23 15:01 ` Fwd: permission to re-license strbuf subsystem as LGPL Brandon Casey 2011-09-23 15:36 ` Michael Witten 2011-09-23 17:12 ` Fwd: " Jakub Narebski 2011-09-23 22:50 ` Brandon Casey 2011-09-24 6:05 ` Jeff King 2011-09-23 22:16 ` Jonathan Nieder
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.