Subject: Re: License question about v4l1-compat.c
From: Bill Dirks <[email-masked]>
To: Hans de Goede <[email-masked]>
Cc: Huzaifa Sidhpurwala <[email-masked]>
Date: Tue, 18 May 2010 23:43:04 -0700

Hi, Hans. Nice to 'meet' you.

Yes, that's fine. Take what you need from my code and use it in your 
LGPL licensed library. I'm all in favor of removing v4l1 from the kernel.

Bill.

On 5/18/2010 12:40 AM, Hans de Goede wrote:
> Hi Bill,
>
> AFAIK you've been out of the v4l loop, so I assume you
> don't know me, this let me start with a shot self introduction:
>
> I'm a Linux enthusiast / developer. Amongst other things I've
> ported over many webcam drivers from v4l1 to v4l2 and I'm the
> author and maintainer of libv4l.
>
> Let me also quickly introduce libv4l about 3 years ago I had
> too much free time and was looking for a hobby project and I
> decided that improving webcam support under Linux would be
> a nice project. At that time there were many webcam driver but
> most of them were out of tree, including the gspca driver
> which is a usb webcam driver framework supporting a lot
> of different chipsets.
>
> One problem with getting these merged is that a lot of webcam
> chipsets produce proprietary (compressed) video formats, which
> apps don't understand. The out of tree drivers all "fixed" this
> by doing decompression and video format conversion inside the
> kernel.
>
> This was not acceptable thus it was time to write a library
> to sit between v4l2 apps and devices which could do format
> conversion if necessary. This resulted in libv4l2 and
> libv4lconvert being written, with libv4l2 being the glue sitting
> in between and libv4lconvert doing the actual conversion.
>
> But this did not help v4l1 apps, so I also wrote libv4l1 for those.
>
> Both libv4l1 and libv4l2 work by emulating the raw device API, all
> one needs to do is write v4lx_open instead of plain open when opening
> the device and them use v4lx_ioctl, etc. on the resulting fd instead
> of their plain versions. This serves 2 purposes:
> 1) It makes porting of apps the the library trivial
> 2) It allows for an LD_PRELOAD shim (used for proprietary apps such
>    as skype).
>
> And now (finally) my question to you, lately we (the v4l devs) have
> been working on removing the last bits of v4l1 from the kernel.
> We would like to also remove the v4l1 ioctl compatibility (*), but
> currently libv4l1 depends on the v4l1 ioctl compatibility for some
> ioctls.
>
> Fixing this comes down to looking at what the kernel compat code
> does and then implementing that in libv4l1. This will likely involve
> some direct copying and libv4l1 is licensed under the LGPL rather
> then the GPL. Thus my question is would it be ok to use your v4l1 compat
> code under the LGPL inside libv4l1 ?
>
> Thanks & Regards,
>
> Hans
>
>
> (*) As in practice v4l1 apps need libv4l1 anyways both for format
> conversion and because some v4l2 drivers don't implement VIDIOCGMBUF
> including rather important ones like the UVC driver, thus we've
> come to the conclusion that we might just as well drop the
> compatibility from the kernel
>

#############################################################################

Date: Wed, 19 May 2010 10:25:44 +0200
From: Gerd Hoffmann <[email-masked]>
To: Hans de Goede <[email-masked]>
Subject: Re: Re-licensing v4l1-compat.c code which you wrote

   Hi,

> My question to you is would it be ok to use your v4l1 compat
> contributions under the LGPL inside libv4l1 ?

Fine with me.

cheers,
   Gerd

#############################################################################

Date: Wed, 19 May 2010 10:27:50 +0200
Subject: Re: Re-licensing v4l1-compat.c code which you wrote
From: "Hans Verkuil" <[email-masked]>
To: "Hans de Goede" <[email-masked]>
Cc: "Gerd Hoffmann" <[email-masked]>,
        "Mauro Carvalho Chehab" <[email-masked]>,
        "Trent Piepho" <[email-masked]>,
        "Huzaifa Sidhpurwala" <[email-masked]>

> Hi All,
>
> I'm writing you all because you've contributed patches
> to the kernels v4l1 ioctl compat code living in v4l1-compat.c
>
> Most of you already know me, and know that I'm working on
> making libv4l1 become independent of the kernel v4l1 ioctl
> compat code, so that it can be removed from the kernel.
>
> For those who don't know me or the v4l1 cleanup effort,
> read below for the long story.
>
> Making libv4l1 independent of the v4l1-compat.c code in the
> kernel comes down to looking at what the kernel compat code
> does and then implementing that in libv4l1. This will likely involve
> some direct copying and libv4l1 is licensed under the LGPL rather
> then the GPL. I already have permission from Bill Dirks who wrote
> the initial v4l1-compat code to do this.
>
> My question to you is would it be ok to use your v4l1 compat
> contributions under the LGPL inside libv4l1 ?

Permission granted.

Looking forward to seeing this in libv4l1 so we can kill this legacy code
in the kernel.

Regards,

         Hans Verkuil

>
> Thanks & Regards,
>
> Hans
>
>
> The long story:
>
> I'm a Linux enthusiast / developer. Amongst other things I've
> ported over many webcam drivers from v4l1 to v4l2 and I'm the
> author and maintainer of libv4l.
>
> Let me also quickly introduce libv4l about 3 years ago I had
> too much free time and was looking for a hobby project and I
> decided that improving webcam support under Linux would be
> a nice project. At that time there were many webcam driver but
> most of them were out of tree, including the gspca driver
> which is a usb webcam driver framework supporting a lot
> of different chipsets.
>
> One problem with getting these merged is that a lot of webcam
> chipsets produce proprietary (compressed) video formats, which
> apps don't understand. The out of tree drivers all "fixed" this
> by doing decompression and video format conversion inside the
> kernel.
>
> This was not acceptable thus it was time to write a library
> to sit between v4l2 apps and devices which could do format
> conversion if necessary. This resulted in libv4l2 and
> libv4lconvert being written, with libv4l2 being the glue sitting
> in between and libv4lconvert doing the actual conversion.
>
> But this did not help v4l1 apps, so I also wrote libv4l1 for those.
>
> Both libv4l1 and libv4l2 work by emulating the raw device API, all
> one needs to do is write v4lx_open instead of plain open when opening
> the device and them use v4lx_ioctl, etc. on the resulting fd instead
> of their plain versions. This serves 2 purposes:
> 1) It makes porting of apps the the library trivial
> 2) It allows for an LD_PRELOAD shim (used for proprietary apps such
>     as skype).
>
> Lately we (the v4l devs) have been working on removing the last bits
> of v4l1 from the kernel. We would like to also remove the v4l1 ioctl
> compatibility (*), but currently libv4l1 depends on the v4l1 ioctl
> compatibility for some ioctls, we are working on fixing this
> which involves re-using code from v4l1-compat.c, hence the
> re-licensing permission question.
>
> (*) As in practice v4l1 apps need libv4l1 anyways both for format
> conversion and because some v4l2 drivers don't implement VIDIOCGMBUF
> including rather important ones like the UVC driver, thus we've
> come to the conclusion that we might just as well drop the
> compatibility from the kernel.
>

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

#############################################################################

Date: Wed, 19 May 2010 11:24:57 -0300
From: Mauro Carvalho Chehab <[email-masked]>
To: Hans de Goede <[email-masked]>
CC: Gerd Hoffmann <[email-masked]>, Hans Verkuil <[email-masked]>,
        Trent Piepho <[email-masked]>,
        Huzaifa Sidhpurwala <[email-masked]>
Subject: Re: Re-licensing v4l1-compat.c code which you wrote

Hans de Goede wrote:
> Hi All,
> 
> I'm writing you all because you've contributed patches
> to the kernels v4l1 ioctl compat code living in v4l1-compat.c
> 
> Most of you already know me, and know that I'm working on
> making libv4l1 become independent of the kernel v4l1 ioctl
> compat code, so that it can be removed from the kernel.
> 
> For those who don't know me or the v4l1 cleanup effort,
> read below for the long story.
> 
> Making libv4l1 independent of the v4l1-compat.c code in the
> kernel comes down to looking at what the kernel compat code
> does and then implementing that in libv4l1. This will likely involve
> some direct copying and libv4l1 is licensed under the LGPL rather
> then the GPL. I already have permission from Bill Dirks who wrote
> the initial v4l1-compat code to do this.
> 
> My question to you is would it be ok to use your v4l1 compat
> contributions under the LGPL inside libv4l1 ?

LGPL for v4l1-compat code is fine for me.

Cheers,
Mauro

#############################################################################