2011/6/21 Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>: > Em 20-06-2011 18:31, HoP escreveu: >> 2011/6/20 Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>: >>> Em 20-06-2011 17:24, HoP escreveu: >>>> 2011/6/20 Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx>: >>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@xxxxxxxxx> wrote: >>>>>> Do you think it is really serious enough reason to prevent of having >>>>>> such virtualization driver in the kernel? >>>>>> >>>>>> Let check my situation and tell me how I should continue (TBH, I already >>>>>> thought that driver can be accepted, but my dumb brain thought because >>>>>> of non quality code/design or so. It was really big "surprise" which >>>>>> reason was used aginst it): >>>>> >>>>> Yes, this is entirely a political issue and not a technical one. >>>> >>>> Political? So we can declare that politics win (again) technicians. Sad. >>> >>> This is not a political issue. It is a licensing issue. If you want to use >>> someone's else code, you need to accept the licensing terms that the developers >>> are giving you, by either paying the price for the code usage (on closed source >>> licensing models), or by accepting the license when using an open-sourced code. >>> >>> Preserving the open-source eco-system is something that everyone >>> developing open source expect: basically, you're free to do whatever >>> you want, but if you're using a code written by an open-source developer, >>> the expected behaviour that GPL asks (and that the developer wants, when he >>> opted for GPL) is that you should return back to the community with any >>> changes you did, including derivative work. This is an essential rule of working >>> with GPL. >>> >>> If you're not happy with that, that's fine. You can implement another stack >>> that is not GPL-licensed. >> >> Mauro, you totally misunderstood me. If you see on my first post in that thread >> I was sending full GPL-ed driver to the mailinglist. > > You misunderstood me. Something that exposes the kernel interface to for an > userspace client driver to implement DVB is not a driver, it is a wrapper. > > The real driver will be in userspace, using the DVB stack, and can even be > closed source. Some developers already tried to do things like that and sell > the userspace code. Such code submission were nacked. There is even one case > where the kernelspace code were dropped due to that (and later, replaced by an > opensource driver). No, you are again wrong, sorry. If you ever tried to understand my small schema and description, you would find that REAL drivers remeains in kernel. May be you understand what I want from attached picture. You can see that the driver acts as bridge (ok, you like wording "wrapper" so) to distribute remote driver functionality down to the client and back. /Honza
Attachment:
vtuner-small-picture.png
Description: PNG image
