Re: [RFC] vtunerc - virtual DVB device driver

From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: HoP <jpetrous@gmail.com>
Cc: Andreas Oberritter <obi@linuxtv.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [RFC] vtunerc - virtual DVB device driver
Date: Wed, 22 Jun 2011 11:23:00 -0300	[thread overview]
Message-ID: <4E01FAC4.7080401@redhat.com> (raw)
In-Reply-To: <BANLkTin6abTC_krfyFcyC7GChpAgsAp1jw@mail.gmail.com>

Em 22-06-2011 11:03, HoP escreveu:
> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>>> Em 22-06-2011 09:37, HoP escreveu:
>>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>>>>> accessed.
>>>>>>>>>>>>
>>>>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>>>>
>>>>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>>>>> core.
>>>>>>>>>>>>
>>>>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>>>>
>>>>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>>>>
>>>>>>>>>>>> ===
>>>>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>>>>
>>>>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>>>>
>>>>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>>>>
>>>>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>>>>
>>>>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>>>>
>>>>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>>>>
>>>>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>>>>
>>>>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>>>>
>>>>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>>>>> ===
>>>>>>>>>>>>
>>>>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>>>>> contributions?
>>>>>>>>>>>>
>>>>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>>>>> economically viable alternative.
>>>>>>>>>>>>
>>>>>>>>>>>> Mauro, ultimately it is your decision as the maintainer which drivers
>>>>>>>>>>>> get accepted in to the kernel.  I can tell you though that this will
>>>>>>>>>>>> be a very bad thing for the driver ecosystem as a whole - it will
>>>>>>>>>>>> essentially make it trivial for vendors (some of which who are doing
>>>>>>>>>>>> GPL work now) to provide solutions that reuse the GPL'd DVB core
>>>>>>>>>>>> without having to make any of their stuff open source.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>>>>> topic.  I guess I lied.
>>>>>>>>>>>
>>>>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>>>>> possibilities to create
>>>>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>>>>
>>>>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>>>>> can be used by a closed source driver.
>>>>>>>>>>
>>>>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>>>>> allowed there is:
>>>>>>>>>>
>>>>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>>>>
>>>>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>>>>> it is also covered by GPL.
>>>>>>>>>
>>>>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>>>>
>>>>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>>>>
>>>>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>>>>
>>>>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>>>>> up any "secrets" at all.
>>>>>>>>>>
>>>>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>>>>> the GPL license.
>>>>>>>>>
>>>>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>>>>> license exception cited above. And even without the exception, a closed
>>>>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>>>>> kernel.
>>>>>>>>
>>>>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>>>>> interesting on some lawyers forum, not here.
>>>>>>>>
>>>>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>>>>
>>>>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>>>>> using it by a closed source application violates GPL.
>>>>>>>>
>>>>>>>> My understanding is that an addition of a code that exposes the internal
>>>>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>>>>> change, otherwise adding such code will violate the original license.
>>>>>>>>
>>>>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>>>>> probably be ok.
>>>>>>>
>>>>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>>>>> cares. It looks for me like you should send some patch for removal such
>>>>>>> "weak" places in kernel which allow to violate GPL.
>>>>>>>
>>>>>>> Do you really think that it is possible (in real, no in threory) to create
>>>>>>> any networked subsystem for sharing anything over net the way
>>>>>>> when it is not exposed (somehow) to the userspace? How will be
>>>>>>> such system managable? Why there is usually companion daemon
>>>>>>> there, which is responsible for managing connections etc?
>>>>>>>
>>>>>>> I think it is very evident you want find the way how to get yours word
>>>>>>> back and return to your original position = such code is not acceptable.
>>>>>>> Even if you still are not able to give anything clear.
>>>>>>>
>>>>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>>>>
>>>>>> You got wrong. You can't change someone's else license without their acks.
>>>>>
>>>>> That I understand very well. I never want to force anybody to change
>>>>> his licence.
>>>>>
>>>>> I simply don't believe you that it is necessary. Why the same was not needed
>>>>> with USBIP driver? If you check theirs nice big picture on
>>>>> http://usbip.sourceforge.net/
>>>>> you see that it is exactly same technology like vtunerc, but for USB subsystem.
>>>>> Why such driver exists at all?
>>>>>
>>>>> And I'm sure I can find more examples inside kernel tree. What about NBD
>>>>> (http://nbd.sourceforge.net)? Do you want find me more examples?
>>>>>
>>>>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>>>>> accept that what you're doing is the right thing. We've got everybody's
>>>>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>>>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>>>>> code itself).
>>>>>>
>>>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>>>> support from Open source lawyers about this subject.
>>>>>>>
>>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>>>> but not here.
>>>>>>
>>>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>>>> driver after all? The proper solution is to write an userspace library for that,
>>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>>>> it.
>>>>>
>>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>>>> and/or debugging.
>>>>
>>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications
>>>> that weren't ported to it yet. It offers two ways:
>>>>      1) you can use it as a normal library;
>>>>      2) you can use it with LD_PRELOAD.
>>>>
>>>>
>>>>> Library would be possible, but then you kill main advantage
>>>>> - totally independece of changes inside userland DVB applications.
>>>>
>>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>>>> is to just run:
>>>>      sed s,open,dvb_open,g
>>>>      sed s,ioctl,dvb_ioctl,g
>>>>
>>>>
>>>> The library and the application will be completely independent.
>>>
>>> How do you transparently set up the network parameters? By using
>>> environment variables? How do you pass existing sockets to the library?
>>> How do you intercept an open() that won't ever happen, because no
>>> virtual device to be opened exists?
>>
>> Sorry, but I failed to see at the vtunerc driver anything network-related.
>> Also, the picture shows that it is just acting as a proxy to an userspace code
>> that it is actually handling the network conversion. The complete solution
>> seems to have a kernel driver and an userspace client/daemon.
>>
>> Technically, doing such proxy in kernel is not a good idea, due to several
>> reasons:
>>
>> 1) The proxy code and the userspace network client will need to be tightly coupled:
>> if you add a new feature at the proxy, the same feature will need to be supported by
>> the userspace daemon;
>>
>> 2) Data will need to be using copy_from_user/copy_to_user for every data access;
>>
>> 3) There's no good reason to write such code inside kernelspace.
>>
>> On a library based approach, what you'll have, instead is a library. The same
>> userspace client/daemon will be needed. However, as both can be shipped together
>> (the library proxy code and the userspace client/daemon), there are several
>> advantages, like:
>>
>> 1) The library and the userspace client will be in sync: there's no need to check
>> for version differences at the api, or providing any sort of backport support;
>>
>> 2) There's no need to recompile the kernel when someone wants to use the proxy;
>>
>> 3) The userspace won't be bound to the Kernel release schedule: When the code is
>> stable enough, both libraries and userspace can be released at the same time.
> 
> If you are (for first time!) inside technical discussion, please
> answer my already
> asked questions why it is done in other kernel sybsystems and nobody
> needs to complain against it. I can refresh you similarities I have found
> already - USBIP (http://usbip.sourceforge.net/) and NBD
> (http://nbd.sourceforge.net/)?

Currently, I can't tell you anything about those two projects, as I'm not aware of them.
I'll seek for some time to take a look on them.

Mauro