{"thread":{"id":"28470","subject":"Fwd: permission to re-license strbuf subsystem as LGPL","startedAt":"2011-09-23T15:01:35Z","lastAt":"2011-09-24T06:05:40Z","messageCount":6,"participants":["Brandon Casey","Michael Witten","Jakub Narebski","Jonathan Nieder","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176069","messageId":"CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com","threadId":"28470","inReplyTo":"CA+sFfMeRDQiqGhO9Y=k3tEnzdXjMx59huFE_fx6Y14cJxj1J=Q@mail.gmail.com","subject":"Fwd: permission to re-license strbuf subsystem as LGPL","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2011-09-23T15:01:35Z","receivedAt":"2011-09-23T15:01:35Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Oops. I forgot to include the git mailing list on the email below. I\nintended to include the git mailing list for two reasons. 1) so that\nwhen people replied giving there permission it would become part of\nthe public record, and 2) because maybe someone had already done this\nand they could speak up before I duplicated their effort.\n\nThe following people have already given their consent:\n\n Jeff King (LGPL)\n Avery Pennarun (LGPL)\n Jonathan Neider (LGPL, ZLIB, Expat, BSD)\n Johannes Schindelin (LGPL, BSD)\n Linus Torvalds (LGPL)\n Alex Riesen (LGPL)\n Marco Costalba (LGPL)\n Lukas Sandström (LGPL, BSD)\n Michal Rokos (LGPL, BSD)\n Thomas Rast (LGPL, BSD)\n\nThe following have not yet responded (the email just went out last night):\n\n Pierre Habouzit\n René Scharfe\n Junio C Hamano\n Kristian Høgsberg\n Johannes Sixt\n Frank Li\n Shawn O. Pearce\n\nJonathan Nieder suggested using a more permissive license than LGPL.\nBSD seems to have the most support. If the remaining contributors\nagree, then I'm fine with licensing under BSD.\n\nAnyway, here is my original email requesting permission to re-license\nstrbuf et al so that it can be made into a library...\n\n---------- Forwarded message ----------\nFrom: Brandon Casey \nDate: Thu, Sep 22, 2011 at 11:21 PM\nSubject: permission to re-license strbuf subsystem as LGPL\n\nTo those who have contributed to git's strbuf subsystem,\n\nI'd like to turn git's strbufs into a library.  So with your consent\nI'd like to re-license the code in strbuf.c and strbuf.h, and any\ncompat/ dependencies as LGPL so that I can create a strbuf library.\nJust skimming through strbuf.c, I'm thinking the other files that may\nbe needed include ctype.c, compat/snprintf.c, and as little of\nwrapper.c as necessary (hopefully only xread).  I think all of the\nauthors are included in this email.  The reason for LGPL, of course,\nis so that it can be linked with non-GPL code.\n\nPlease offer your consent to re-license your contributions under LGPL\nby replying to this email.\n\nAll comments welcome.\n\nThanks,\n-Brandon\n\np.s. sorry for the mostly cut-n-paste email for those who also\nreceived my email about archive-zip\n"},{"id":"176070","messageId":"CAMOZ1BvUFtCJ0=cqMX6QnJVJ0FyPYBDoJpWFqw_JhkCtJy3p-Q@mail.gmail.com","threadId":"28470","inReplyTo":"CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com","subject":"Re: permission to re-license strbuf subsystem as LGPL","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-23T15:36:07Z","receivedAt":"2011-09-23T15:36:07Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Sep 23, 2011 at 15:01, Brandon Casey wrote:\n\n> Jonathan Nieder suggested using a more permissive license than LGPL.\n> BSD seems to have the most support. If the remaining contributors\n> agree, then I'm fine with licensing under BSD.\n\nBSD is more permissive for only the upstream; the downstream\n('end-users') get nothing.\n\nIn fact, the downstream may ultimately get a license that is more\nrestrictive on further developments---possibly even restrictions that\nmight hinder the development of your own upstream work should you find\nyourself in some sort of downstream position relative to a fork.\n"},{"id":"176076","messageId":"m3mxdvqj31.fsf@localhost.localdomain","threadId":"28470","inReplyTo":"CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com","subject":"Re: Fwd: permission to re-license strbuf subsystem as LGPL","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-23T17:12:34Z","receivedAt":"2011-09-23T17:12:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Brandon Casey writes:\n\n> ---------- Forwarded message ----------\n> From: Brandon Casey \n> Date: Thu, Sep 22, 2011 at 11:21 PM\n> Subject: permission to re-license strbuf subsystem as LGPL\n> \n> To those who have contributed to git's strbuf subsystem,\n> \n> I'd like to turn git's strbufs into a library.  So with your consent\n> I'd like to re-license the code in strbuf.c and strbuf.h, and any\n> compat/ dependencies as LGPL so that I can create a strbuf library.\n\nThat's a laudable goal. Do you plan on librarizing other universal\nmini-libraries, like parseopt or test-lib?\n\nI wonder if for example \"perf\" tool in Linux kernel sources (userspace\ncompanion to perf events subsystem) will move to using it; currently\nit reuses some of internal git minilibraries, IIRC strbuf and parseopt\nincluded.\n\nBy the way, how the 'strbuf' from git (which I think was created among\nothers to avoid additional external dependencies) differs from\nexisting C (not C++) string libraries, like 'bstring'[1], The Better\nString Library, or the C libraries in http://bstring.sourceforge.net/features.html?\n\n[1]: http://bstring.sourceforge.net\n\n-- \nJakub Narębski\n"},{"id":"176105","messageId":"20110923221611.GA2548@elie","threadId":"28470","inReplyTo":"CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com","subject":"Re: Fwd: permission to re-license strbuf subsystem as LGPL","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-09-23T22:16:11Z","receivedAt":"2011-09-23T22:16:11Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Brandon Casey wrote:\n\n> Jonathan Nieder suggested using a more permissive license than LGPL.\n> BSD seems to have the most support. If the remaining contributors\n> agree, then I'm fine with licensing under BSD.\n\nA few words of clarification. My opinion shouldn't matter much here\n--- I am more of a bystander and user than a contributor to strbuf. :)\n\nThe main reason I suggested a permissive license is that the strbuf\nlib contains some inline functions and I do not want it to be\ncomplicated to use them. To comply with the LGPL, in addition to\nreleasing any changes made to the library, distributors usually do one\nof a few things:\n\n a. offer the source code for your work that uses the library in\n addition to any binaries,\n\n b. use dynamic linking, or\n\n c. provide object files for your work that uses the library, so it\n can be re-linked against a modified version of the library.\n\n(b) and (c) don't handle inline functions. Luckily, there is a way out:\n\n d. only use the inline functions from within a subset of your work\n for which you are willing to provide source. Dynamically link to\n it or provide object files to allow re-linking.\n\nWith that in mind, I have nothing against the use of the LGPL here\n(and one of the two main authors of the strbuf lib explained a good\nreason to prefer it over the BSD license). The inline functions in\nthe strbuf lib are pretty small, so the above was probably not too\nimportant in the first place.\n\nThanks, and sorry for the unnecessary noise.\n\nRegards,\nJonathan\n"},{"id":"176109","messageId":"CA+sFfMdt-95rfaZmiYAHx02Ukjt_WN-kLJr410AzZfGHYkSv5w@mail.gmail.com","threadId":"28470","inReplyTo":"m3mxdvqj31.fsf@localhost.localdomain","subject":"Re: Fwd: permission to re-license strbuf subsystem as LGPL","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2011-09-23T22:50:27Z","receivedAt":"2011-09-23T22:50:27Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"2011/9/23 Jakub Narebski :\n> Brandon Casey writes:\n>\n>> ---------- Forwarded message ----------\n>> From: Brandon Casey \n>> Date: Thu, Sep 22, 2011 at 11:21 PM\n>> Subject: permission to re-license strbuf subsystem as LGPL\n>>\n>> To those who have contributed to git's strbuf subsystem,\n>>\n>> I'd like to turn git's strbufs into a library.  So with your consent\n>> I'd like to re-license the code in strbuf.c and strbuf.h, and any\n>> compat/ dependencies as LGPL so that I can create a strbuf library.\n>\n> That's a laudable goal.  Do you plan on librarizing other universal\n> mini-libraries, like parseopt or test-lib?\n\nNot at the moment.\n\n> I wonder if for example \"perf\" tool in Linux kernel sources (userspace\n> companion to perf events subsystem) will move to using it; currently\n> it reuses some of internal git minilibraries, IIRC strbuf and parseopt\n> included.\n\nI would be pleased if it was useful to them.\n\n> By the way, how the 'strbuf' from git (which I think was created among\n> others to avoid additional external dependencies) differs from\n> existing C (not C++) string libraries, like 'bstring'[1], The Better\n> String Library, or the C libraries in http://bstring.sourceforge.net/features.html?\n>\n> [1]: http://bstring.sourceforge.net\n\nHmm, I forgot about bstring. I think strbuf is a little smaller in\nscope than bstring, perhaps less ambitious. Less abstraction, and\nless protection too. With strbuf, you never forget that you're\ndealing with C char arrays. The data structures are pretty similar,\nbut I don't think strbuf will ever have a function like\n\n bconcat(bstring1, bstring2)\n\ninstead, you'd just do\n\n strbuf_add(strbuf1, strbuf2.buf, strbuf2.len)\n\nThe benefit, of course, of a bconcat function is that either bstring1\nor bstring2 can be NULL (like if a previous bstring2 = bfromcstr()\ninitialization failed). This allows you to perform a sequence of\nbstring operations and only check errors at the end.\n\n-Brandon\n"},{"id":"176118","messageId":"20110924060540.GA13974@sigill.intra.peff.net","threadId":"28470","inReplyTo":"CA+sFfMdt-95rfaZmiYAHx02Ukjt_WN-kLJr410AzZfGHYkSv5w@mail.gmail.com","subject":"Re: Fwd: permission to re-license strbuf subsystem as LGPL","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-24T06:05:40Z","receivedAt":"2011-09-24T06:05:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 23, 2011 at 05:50:27PM -0500, Brandon Casey wrote:\n\n> Hmm, I forgot about bstring. I think strbuf is a little smaller in\n> scope than bstring, perhaps less ambitious. Less abstraction, and\n> less protection too. With strbuf, you never forget that you're\n> dealing with C char arrays. The data structures are pretty similar,\n> but I don't think strbuf will ever have a function like\n> \n> bconcat(bstring1, bstring2)\n> \n> instead, you'd just do\n> \n> strbuf_add(strbuf1, strbuf2.buf, strbuf2.len)\n\nI think it's spelled:\n\n strbuf_addbuf(strbuf1, strbuf2);\n\nin the current code.\n\n> The benefit, of course, of a bconcat function is that either bstring1\n> or bstring2 can be NULL (like if a previous bstring2 = bfromcstr()\n> initialization failed). This allows you to perform a sequence of\n> bstring operations and only check errors at the end.\n\nThere is no error checking with strbufs at all. The only thing that can\nfail is malloc, and in that case, we always die().\n\nIt wouldn't be too hard to make it return errors (or set a global error\nflag), and have any failed mallocs just leave the strbuf unchanged.\nBecause strbufs are always in a consistent state, it would be safe to\ndo:\n\n global_strbuf_error_flag = 0;\n strbuf_addbuf(strbuf1, strbuf2);\n strbuf_addbuf(strbuf3, strbuf1);\n strbuf_addbuf(strbuf3, strbuf4);\n if (global_strbuf_error_flag)\n ...\n\nThe contents of the strbufs would be indeterminant, but you would never\nhave violated any memory constraints.\n\n-Peff\n"}]}