> You're welcome, and I am very impressed with your willingness to take
what was meant as constructive criticism. That's very rare in opensource
these days.
I love constructive criticism :) It's the easiest way for me to get
answers to the always-relevant question of "How can I do it better?"

> My concern was mainly related to the fact I didn't know what they were,
which you have answered adequately. Are they LGPL?
libpstat and fskit are both LGPLv3 (my motivation for v3 over v2 is the
explicit patent license). Again, I'm willing to dual-license them with
something more BSD-friendly. I was leaning towards ISC earlier since
that's what OpenBSD uses, but I don't have a strong opinion. Is there
something the MIT license offers that you particularly like?

Thanks,
Jude


On Wed, Dec 17, 2014 at 7:09 PM, T.J. Duchene <t.j.duchene@???> wrote:
>
>
>
> >Hi and thanks for the feedback!
> You're welcome, and I am very impressed with your willingness to take what
> was meant as constructive criticism. That's very rare in opensource these
> days.
>
>
>
>
>
> >I'm open to GPLv3/ISC dual licensing, if there is sufficient interest.
> My subnotebook runs OpenBSD, for instance, and OpenBSD is my next porting
> target after Linux.
> I've not been writing open code from some time, work and making a living
> has been proprietary. When I do write open code, I place it under
> GPLv2/MIT of possible. That way I had a guarantee with the GPL, but it
> could also be used by the BSD folks. Versions could be relicensed
> downstream as needed, but my code remained open.
>
>
>
> > 2) It is dependent on his personal projects.
> My concern was mainly related to the fact I didn't know what they were,
> which you have answered adequately. Are they LGPL?
>
>
>
> Thanks for your information on what you are about with FUSE. I've not
> looked at the code personally, I've just noticed some strange behavior in
> some distributions, which is not always related to programming - but setup
> and packaging. I'd be interested in testing vdev for you, looking at code
> sometime.
>
>
>
> >Nothing would ever need to link against vdev. I have no intention of
> creating a "libvdev" like there is for libudev--I would rather invest the
> time into making the vdev filesystem interface sufficiently expressive to
> obviate the need for a dedicated library.
>
> > fskit is the bigger concern, since both vdev and runfs (another
> project) link against it. I'm in the process of making the public fskit
> API declared as 'extern "C"' to remedy this.
>
> That's awesome!
>
>
>