Re: resizing file system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, 

Based on the situation I've searched for a few days,
I conclude that it's better to change license of the nilfs2_fs.h header.
I'll comment it inline.

At Tue, 28 Sep 2010 01:01:38 +0900 (JST),
Ryusuke Konishi wrote:
> 
> Hi,
> On Mon, 27 Sep 2010 19:59:54 +0900, Jiro SEKIBA wrote:
> > Hi,
> > 
> > At Sat, 18 Sep 2010 01:20:00 +0900 (JST),
> > Ryusuke Konishi wrote:
> > > 
> > > Hi,
> > > On Fri, 17 Sep 2010 18:15:59 +0900, Jiro SEKIBA wrote:
> > > > Hi,
> > > > 
> > > > I think it would be good to have a generic libraries for other user land tools,
> > > > like parted, for the purpose to modify/tweek file system off line.
> > > > At least, resize/fsck/mkfs are the generic functionalities that parted
> > > > can handle.  So it's good if there is a library that can perform
> > > > those things to avoid implementing same thing all over the place.
> > > > 
> > > > One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
> > > > Still, contributers of libnilfs2 are countable, so maybe we can get agreements
> > > > from all contributers to change licence to LGPL2, isn't it?
> > > 
> > > Definitely yes.  I think we should migrate the licence of the library
> > > to LGPL2.
> > > 
> > > One practical problem is that some of the source files derive the
> > > kernel code, and they are licensed under GPLv2.
> > > 
> > > For example, nilfs2_fs.h and crc32.c are just such ones.
> > > 
> > > Do you think we need replacement for these?
> > 
> > We could choose to change the licence as LGPL like mqueue.h (*1).
> > However, we may be able to think that license of nilfs2_fs.h won't affect
> > license of user land tools.
> 
> > At least, Linus stated that "There's a
> > clarification that user-space programs that use the standard system call
> > interfaces aren't considered derived works, ..." (*2). 
> >
> > *1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/mqueue.h;hb=HEAD
> > *2) http://kerneltrap.org/node/1735
> 
> "unistd.h" is distributed under LGPL.  So, the above Linus' statement
> sounds like saying just fundamental charateristics of LGPL.

I interpreted his statement different way, that using standard interface
of kernel is using system call or ioctl.  Using those functionality 
requires including headers for binary compatibility.

> The point of "nilfs2_fs.h" issue differs from that.  A copy of
> nilfs2_fs.h is actually included in nilfs-utils, and the nilfs library
> is depending on the copy.
> 
> The "mqueue.h" solution seems to be an approved manner (sigh).
> 
> Another solution is extracting requisites from "nilfs2_fs.h" and
> rewriting them under LGPL for the library and userland programs.
> 
> Or, do you know any examples of GPL header file whose library is
> licensed under LGPL?

libv4l includes videodev2.h which is GPL, but is released under LGPL.
 http://freshmeat.net/projects/libv4l

However, that is the only LGPL library I found  which includes GPL header.
Other libraries intentionally or unintentionally don't include GPL headers.

Actually, I realized that some of exported headers of linux kernel are
not GPL, but like LGPL, BSD, MIT.  Or even no license declaration.

Here is the diff of the kernel that merely changes license of header
to avoid the license issues we have been talking.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=19b3eecc21b65a24b0aae2684ca0c8e1b99ef802

So non-GPLed header is common way to export linux headers.

thanks,

regards

> > While, crc32.c must be replaced other implementation :(.
> > I'll search lgpled implementation.
> 
> OK, let's replace it with a compatible one if we change the library
> license to LGPL.
> 
> Thanks,
> Ryusuke Konishi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


-- 
Jiro SEKIBA <jir@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux BTRFS]     [Linux CIFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux