Fwd: permission to re-license strbuf subsystem as LGPL

Fwd: permission to re-license strbuf subsystem as LGPL

[Brandon Casey]

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

Re: permission to re-license strbuf subsystem as LGPL

[Michael Witten]

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.

Re: Fwd: permission to re-license strbuf subsystem as LGPL

[Jakub Narebski]

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

Re: Fwd: permission to re-license strbuf subsystem as LGPL

[Jonathan Nieder]

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

Re: Fwd: permission to re-license strbuf subsystem as LGPL

[Brandon Casey]

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

Re: Fwd: permission to re-license strbuf subsystem as LGPL

[Jeff King]

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