btrfs-progs relicensing update
Hi all, In the process to relicense btrfs-progs to LGPLv2.1[1], we have 40 of 114 approvals so far. I have sent mass-emails to everyone with more than 1 commit, and am now sending individual emails down the list to people I haven't heard from. (I'm waiting to tackle the single-commit people until we get all the more major contributors.) Here's progress so far: https://docs.google.com/spreadsheet/ccc?key=0AuE18RMM7JeKdFF4OVdsYU9GVmVEOGNKajdPYThHSWcusp=sharing If you are a contributor and haven't yet given your ok, please feel free to reply to me off-list with this text: -I grant permission to re-license my contributed code to btrfs-progs under the GNU LGPLv2.1 license.- and I'll be sure to count you :-) Thanks -- Regards -- Andy [1] this is to allow btrfs-progs to be used as a library without licensing considerations. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Btrfs-progs Relicensing effort has begun
Hi all, We want to relicense btrfs-progs, using the LGPLv2.1 instead of GPLv2. We can then build btrfs-progs code as a shared library, libbtrfs, and this library can be used by other code -- GPLv3+, BSD/Apache, and non-free, without causing the GPLv2 to apply to the other code. This will allow btrfs support to be more tightly integrated into other management tools. Chris Mason, as well as Oracle, have approved this change and are on-board, but we also need *all* contributors to agree. I will be emailing all contributors (as shown by git) over the next few weeks. Progress will be shown here: https://docs.google.com/spreadsheet/ccc?key=0AuE18RMM7JeKdFF4OVdsYU9GVmVEOGNKajdPYThHSWcusp=sharing Instead of waiting for the email, you can also email me now (agro...@redhat.com) with the below phrase, or something similar: -I grant permission to re-license my contributed code to btrfs-progs under the GNU LGPLv2.1 license.- or with any questions. Thanks! -- Regards -- Andy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs.h and btrfs-progs licensing
Hi everybody, I'd like it to be possible to have a library that configures btrfs directly instead of using the cmdline tools. (I think Mark Fasheh and David Sterba have already done some work here.) However, as it stands, the kernel's include/uapi/linux/btrfs.h and btrfs-progs are GPLv2, which means that a libbtrfs that is based on either of these might also be construed to need to be GPLv2, and any program *using* libbtrfs might also be construed to need to be GPLv2. I don't think this was the intent. I think we'd be better off if we relicense btrfs-progs to LGPLv2, and dual-license the kernel btrfs.h header to GPLv2/LGPLv2 (this may not be strictly necessary, RMS says it isn't[1], but we probably want to be completely clear). This will involve getting the OK from everyone who has contributed to btrfs-progs. Yay git. If someone more closely involved with btrfs dev wanted to spearhead this I'd love it, but am willing to do it too (I *really* want a libbtrfs. :-) Any thoughts? Objections? Regards -- Andy [1] http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lvm volume like support
On 02/25/2013 10:25 PM, Suman C wrote: Thanks for the sparse file idea, I am actually using that solution already. I am not sure if its the best way, however. (Sorry to respond to such an old thread.) Hi Suman, I think zvol-like functionality would be very nice for btrfs to have. It would be more natural to manage btrvols than looped-back files I think, and removing those sw layers may also increase performance, but who knows by how much. It would let btrfs really act as just the LVM, if desired. Do we have any sense for how much work adding this would be? Regards -- Andy p.s. some interesting stuff on zvols http://pthree.org/2012/12/21/zfs-administration-part-xiv-zvols/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Writing a wtapper for BTRFS
On 02/27/2013 01:34 PM, Zach Brown wrote: On Wed, Feb 27, 2013 at 04:19:57PM +0100, David Sterba wrote: On Wed, Feb 27, 2013 at 01:08:46PM +, Hugo Mills wrote: You may want to look at the btrfs-progs libify patches (posted to this list in the last couple of months), which try to pull out the more useful bits of btrfs-progs as a userspace C API. FYI, libify patch will be in the next integration branch. You may also want to look at the bits I implemented in python[2] for a subset of the btrfs ioctls and data structures in btrfs-gui. Other than that, it's down to the data structures documentation on the wiki[1], and reading through ioctl.h. bedup https://github.com/g2p/bedup does python binding, in a different way than btrfs-gui. Andy also mentioned being interested in language bindings of a libified btrfs-progs, cc:ing. Yeah. Python/otherlang wrappers around a btrfs-progs C api seem preferable to each binding calling ioctls themselves, no? I think every common language is going to eventually want a btrfs lib. -- Andy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
