Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Markus Rechberger mrechber...@gmail.com: 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. since a customer was trying to use this module the only feedback I can give right now is that there are still some fundamental bugs in that work. Just running it with some intuitive parameters (without having a dvb device connected) caused it to hang. ./vtunerc.i686 -c 1 vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C as mode 0, searching for tuner types 2 vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode specified: 1 allow values are: -s -S -s2 -S2 -c -t it just never returned. Never returned? How it is possible if just next line is exit(1) call? DMESG: vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer ps fax | grep vtunerc: 5194 pts/4 S 0:00 | \_ bash 5210 pts/4 S+ 0:00 | \_ [vtunerc.i686] that way it's not good enough for inclusion yet anyway. I never wanted to get it include immediatelly. I never stated that. That is why subject of this mail starts with [RFC]. I wanted to know if such driver is even interesting by others and if so to get help from community having the code better. I was already noted that it is my first kernel driver and I understand that reviewing code by kernel hackers can help making code better. On the other hand I never thought that the code can be totally refused because of its nature. Even I all time was writing that all subsystem (kernel + userland daemons) are GPL. Marcus, tell the customer I'm just starting some howto document to guide all willing to test how it works through compilation and installation process. In parallel I'm going to address all hints gave me by Andreas, the only guy who even had a look at source. Anyway, I'm happy for any feedback, so thanks. /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 09:37, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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.
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 02:55 PM, Mauro Carvalho Chehab wrote: Em 22-06-2011 09:30, Andreas Oberritter escreveu: On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
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 mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab mche...@redhat.com: Em 22-06-2011 09:30, Andreas Oberritter escreveu: On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
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 mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab mche...@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 mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 11:03, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab mche...@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 mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: 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 mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: [...] 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. Of course it doesn't. You're the one who proposed to put networking into the driver. I however fail to see how you imagined to add remote tuner support to any existing application by using LD_PRELOAD. 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. Right. 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; Just like anything else DVB related inside the kernel. Adding a new feature to the proxy would mean that a new feature got added to the frontend API, so a new kernel would be required anyway. 2) Data will need to be using copy_from_user/copy_to_user for every data access; Also, just like anything else DVB related inside the kernel. No one would notice some frontend ioctl parameters being copied twice. We're talking about a few bytes. Passing the remote TS to the kernel is completely *optional*, and only required if you want to use the kernel's demux or the underlying hardware's filtering and decoding features. However, the TS even gets filtered before being transferred over the network. So again, even if used though being optional, this is not a big data rate. 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; Breaking the ABI of libraries isn't much better than breaking the ABI of kernel interfaces. A library may have many users, more than the userspace client you're talking about. 2) There's no need to recompile the kernel when someone wants to use the proxy; You could of course build it as a module, without the need to recompile the kernel. 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. For the same reason one could argue that putting device drivers into userspace would have the same benefits. Well, the original proposal was to add a driver with supporting programs which enables every existing DVB application to *transparently* work with remote tuners. What you're proposing now is to write a library, which works with remote tuners, too,
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 11:24, Andreas Oberritter escreveu: On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: 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 mche...@redhat.com: Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: [...] 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. Of course it doesn't. You're the one who proposed to put networking into the driver. I however fail to see how you imagined to add remote tuner support to any existing application by using LD_PRELOAD. If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write glibc calls. So, when an userspace application calls open, it will run the library code, and not glibc open function. So, it is completely transparent to the userspace application. 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. Right. 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; Just like anything else DVB related inside the kernel. Yes. Adding a new feature to the proxy would mean that a new feature got added to the frontend API, so a new kernel would be required anyway. 2) Data will need to be using copy_from_user/copy_to_user for every data access; Also, just like anything else DVB related inside the kernel. Yes, but if you do it on userspace, you don't need to do double buffering. With a proxy, the same data will need to be passed 3 times from/to kernelspace: 2 times at vtunerc, and 1 time to the network driver. If implemented on userspace, all it needed is to pass the data to the network driver, reducing latency. Also, newer functions can be added on userspace in order to optimize applications that will use it as a library, like providing functions that combine DVB and network commands altogether. No one would notice some frontend ioctl parameters being copied twice. We're talking about a few bytes. If the intention is to limit it to just frontend ioctl's, you're right: the only difference is that latency will be a little higher, probably unnoticed (yet, introduced for not a good reason). But, if the intention is to also provide remote streaming, then the volume of data copied tree times will be noticeable, especially if the stream is in HD and/or if support for full-featured DVB cards is added later. Passing the remote TS to the kernel is completely *optional*, and only required if you want to use the kernel's demux or the underlying hardware's filtering and decoding features. However, the TS even gets filtered before being transferred over the network. So again, even if used though being optional, this is not a big data rate. 3) There's no good reason to write such code inside kernelspace. On a library based approach, what you'll
Re: [RFC] vtunerc - virtual DVB device driver
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. Mauro, My comments for your review: I've spoken on this topic many times, it's bad news for the LinuxTV eco-system and it will eventually lead to binary only drivers that ultimately diminishes all of the good work that me any my fellow developers have poured into Linux over the last 5-10 years. I repeat my message from 2 years ago when the subject was raised: and this is (paraphrase) I can say with great certainty that if we allow API's that permit closed source drivers then silicon vendors and board manufacturers will take advantage of that, they will only delivery (at best) closed source drivers. If closed source drivers is what the community wants then this is a way to achieve this. I don't want to see user-space drivers happen through LinuxDVB or V4L2 API's. I politely and respectfully nack this idea. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On Sat, Jun 18, 2011 at 8:10 PM, HoP jpetr...@gmail.com wrote: Hi, get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. In conjunction with Dreamtuner userland project [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger user can create virtual DVB device on client side and connect it to the server. When connected, user is able to use any Linux DVB API compatible application on client side (like VDR, MeTV, MythTV, etc) without any need of code modification. As server can be used any Linux DVB API compatible device. I can think of many interesting uses for a solution like this. It's great that such a driver exists and that people can use it now to create interesting do-it-yourself projects, however, I do not believe this should ever be merged into the kernel. If this solution were merged into the kernel, there would be no reason for companies like Hauppauge to ever again contribute any open source drivers. Once it's possible to deliver a closed source driver to the masses, that's what vendors will do -- there will no longer be any motivation to continue working in open source. Some may like that idea, but I feel this will destroy the foundation that we've been building for years. I repeat, the solution itself has some potential, and I see nothing wrong with this existing and being available to users in source code form, but it should never be merged into a kernel to be shipped directly to end-users. This can create a horrible president that would truly result in the prevention of open source driver contributions from silicon vendors and hardware manufacturers. Regards, Michael Krufky LinuxTV developer / Hauppauge Digital -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 16:18, Rémi Denis-Courmont escreveu: Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit : 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? Are you seriously asking why people write tunneling drivers in user-space? Or why they want to use the kernel-space socket API and protocol stack? 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. No. Set aside the problem of licensing, the correct way is to reuse existing code, which means the layer-3/4 stacks and the socket API in net/*. That avoids duplicating efforts (and bugs) and allows socket API apps to run unchanged and without brittle hacks like LD_PRELOAD. And indeed, that's what the Linux ecosystem does, thanks to the tuntap network device driver. Rémi, Using the Kernel network layer is the right thing to do, but you don't need to add a new driver for it: it is already there. All that userspace needs to do is to use glibc socket's support. It could make sense to have some sort of virtualization driver that would allow passing DVB API calls via, for example, the network socket API, to allow accessing a physical DVB driver (or a remote machine DVB driver)from a VM machine. That was my original understanding. Instead, the proposal is wrapper, that will be a sort of kernelspace implementation for LD_PRELOAD that just returns the DVB commands back to some other application in userspace. The real code to transmit DVB commands will be in userspace. Technically speaking, this is a hack. If I would code something like that, I would write it as a library with some functions like: connect_to_dvb() get_dvb_properties() get_frontend_parameters() set_frontend_parameters() get_dvb_ts() And write a few patches for the userspace applications I would care. If I wanted to provide transparent access to it, I would simply implement a LD_PRELOAD schema, in order to help the new library deployment. With such approach, at the initial stages (the worse case, e. g. using LD_PRELOAD), it will be equivalent to have a kernel wrapper code, but, at long term, it will allow important optimizations, like avoiding the need of copying data from/to the wrapper, supporting the extra delays introducing by the network and allowing the applications to implement themselves the dialog windows to control the network properties. Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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). We don't want to go on this way again. 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. 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. If you're feared of exposing kernel interfaces to userspace, then I think your only option is to remove the whole userspace. You might want to remove i2c-dev and the loadable module interface first. Regarding the code, Honza, I think the interface is neither clean nor generic enough to be included in the kernel. It doesn't make much sense to stay compatible to the interface used by the Dreambox. This interface evolved from very old versions of the DVB API and therefore carries way too much cruft and hacks for a shiny new interface. As a side note: Your ioctl constants already differ from the original vtuner code. IMO, at least these steps need to be taken: - Remove unused code. You already mentioned it, but it really should be removed before submitting code, because it makes review much harder. - Remove redefined structs and constants. - Drop support for anything older than S2API. - Define a way to use an existing demux instead of registering a new software demux. On hardware that supports it, an input channel should be allocated for each vtuner, in order to use the hardware's filtering and decoding capabilities. - Drop VTUNER_SET_NAME, VTUNER_SET_HAS_OUTPUTS, VTUNER_SET_MODES, VTUNER_SET_TYPE and VTUNER_SET_NUM_MODES. They are all either specific to the Dreambox or already obsoleted by S2API commands or should be implemented as new S2API commands. Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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). We don't want to go on this way again. 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. 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. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications, and, if they're using a GPL'd code inside a closed source application, they can be sued. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned into it, I'll review and consider for its inclusion upstream. For that to happen, it should not try to use any Dreambox specific application or protocol, but to just use the standard DVBv5 API, as you've pointed. If you're feared of exposing kernel interfaces to userspace, then I think your only option is to remove the whole userspace. You might want to remove i2c-dev and the loadable module interface first. Regarding the code, Honza, I think the interface is neither clean nor generic enough to be included in the kernel. It doesn't make much sense to stay compatible to the interface used by the Dreambox. This interface evolved from very old versions of the DVB API and therefore carries way too much cruft and hacks for a shiny new interface. As a side note: Your ioctl constants already differ from the original vtuner code. IMO, at least these steps need to be taken: - Remove unused code. You already mentioned it, but it really should be removed before submitting code, because it makes review much harder. -
Re: [RFC] vtunerc - virtual DVB device driver
On 06/21/2011 02:05 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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). We don't want to go on this way again. 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. 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. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications *Not that it would apply to this case*, but disallowing closed source applications in userspace is ridiculous. And why should you reject a possibly nice interface just because no open source application using it has already been written? and, if they're using a GPL'd code inside a closed source application, they can be sued. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. I see. That's where you're wrong. Neither does it depend on any closed application (Honza even included the link to the source code of the application: https://code.google.com/p/dreamtuner/), nor is this application specific to the Dreambox. The Dreambox is just the origin of the vtuner API. Btw.: Honza repeatedly stated that he's using his code with VDR, which in other words means that he's not using a Dreambox. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned into it, I'll review and consider for its inclusion upstream. You mean, if the code could be turned into what it already is? For that to happen, it should not try to use any Dreambox specific application or protocol, but to just use the standard DVBv5 API, as you've pointed. The DVB API v5 (as of now) is a
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 08:04, Andreas Oberritter escreveu: On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote: Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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). We don't want to go on this way again. 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. 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. Yes, but we don't need to review/maintain a kernel driver meant to be used by closed source applications, and, if they're using a GPL'd code inside a closed source application, they can be sued. Well, seems you are trying to argue using wrong arguments. One more again: If you follow my picture - all on the path, INCLUDING userland application, is GPL code. If you think about Enigma, it is GPLed also, at least version 1. But my driver is not for dreamboxes! They have similar implementation already included there. My intention was different: to allow same thing like is possible with dreamboxes, on normal linux PC desktop. Using any other userland DVB application, like VDR or MythTV or vlc. Got my point? I have nothing to do with any closed source or even binary blobs! I want DVB adapter distribution across network, nothing more. Everything is clear, from GPL point of view. I didn't review the patchset, but, from the description, I understood that it were developed to use some Dreambox-specific closed source applications. With such requirement, for me it is just a wrapper to some closed source application. I understand that my English can be not crystal clear, so you missed inside my description. But I must say it again - my code has zero connection with dreamboxes. Of course other then borrowing theirs sharing possibility and reusing same network daemons (again fully GPLed!) for it. That's said, I'm not against a driver that allows using a DVB kernel driver by a DVB open source application either inside a virtual machine or on a remote machine. This seems useful for me. So, if the code could be turned
Re: [RFC] vtunerc - virtual DVB device driver
I hope this driver will be included if it can be useful for some and if it follows the GPL rules. But really, +1 to Sebastien's comment - this project is a frustrating one it seems. And at the point where I am, I would rather pay for a working driver for a S2 + CI card, instead of trying to debug existing drivers for which the maintainers are virtually non existent. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@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. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter o...@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). 2.) a simple wrapper that calls userspace, therefore not having to open up any secrets at all. Of course it's nice that you could trick that vendor into publishing code under GPL terms. And while everyone appreciates it, I would also appreciate keeping politics off the table. If the proposed interface results in closed
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Andreas Oberritter o...@linuxtv.org: Yes, and you did lie to your vendor, too, as you did not mention the possibilities to create I don't know if this is a language barrier issue, but calling someone a liar (let alone in an open forum) is a pretty offensive thing to do. In fact, such discussions did come up. However I simply didn't mention them here in the previous email in an attempt consolidate one hour conversations into nine sentences in an attempt at brevity. 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). This definitely enters a grey area from a legal standpoint. Depending on who you talk to, using such symbols may or may not violate the GPL, depending on what lawyer you talk to. This all falls back to the notion of whether non-GPL loadable modules violate the GPL, for which even today there is considerable debate within the kernel community. Smart companies are generally risk-averse, and recognize that it's usually not worth the risk of being sued by doing something that may or may not violate a license. 2.) a simple wrapper that calls userspace, therefore not having to open up any secrets at all. Like the above, this raises all sorts of issues involving the definition of derivative work. Again, we're going around in circles here. This issue has been beaten to death both in the linux dvb mailing lists as well as in the lkml in general. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Devin Heitmueller dheitmuel...@kernellabs.com writes: 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. Wouldn't it be just as trivial to bundle the closed-source tuner support with this patch or a similar GPL licensed driver? This doesn't change anything wrt closed source drivers. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 10:44, Devin Heitmueller escreveu: 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. I was a little faster to answer to my previous emails. I'm not feeling well today due to a strong pain on my backbone. So, let me explain what would be ok, from my POV: A kernelspace driver that will follow DVBv5 API and talk with wit another device via the Kernel network stack, in order to access a remote Kernel board, or a kernel board at the physical machine, for virtual machines. That means that the dvb stack won't be proxied to an userspace application. Something like: Userspace app (like kaffeine, dvr, etc) - DVB net_tunnel driver - Kernel Network stack Kernel Network stack - DVB net_tunnel driver - DVB hardware In other words, the DVB net_tunnel driver will take care of using the network stack, implement Kernel namespaces, etc, in order to allow virtualizing a remote hardware, without needing any userspace driver for doing that (well, except, of course, for the standard network userspace applications for DNS solving, configuring IP routes, etc). Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 11:56, Bjørn Mork escreveu: Devin Heitmueller dheitmuel...@kernellabs.com writes: 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. Wouldn't it be just as trivial to bundle the closed-source tuner support with this patch or a similar GPL licensed driver? This doesn't change anything wrt closed source drivers. Yes, but adding some code into a GPL licensed code is derivative work, The end result is also covered by GPL (not only the kernelspace, but also the userspace counterpart). If some company is doing things like that and not providing the entire driver under GPL, if going to court, the judge will likely consider this as an explicitly attempt to violate the legal property of someone's else's copyright. Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@redhat.com: Em 21-06-2011 10:44, Devin Heitmueller escreveu: 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. I was a little faster to answer to my previous emails. I'm not feeling well today due to a strong pain on my backbone. So, let me explain what would be ok, from my POV: A kernelspace driver that will follow DVBv5 API and talk with wit another device via the Kernel network stack, in order to access a remote Kernel board, or a kernel board at the physical machine, for virtual machines. That means that the dvb stack won't be proxied to an userspace application. Something like: Userspace app (like kaffeine, dvr, etc) - DVB net_tunnel driver - Kernel Network stack Kernel Network stack - DVB net_tunnel driver - DVB hardware for such a design a developer should be fired ^^ Everything back to ring 0, however I guess that particular developer who designed this does not know about that security concept, otherwise he wouldn't propose to put such things into kernelspace. and from the kernel network stack you go via TCP and connect to whoever you want (particular userspace daemon with all the implementation). Aside of the security issue which it introduces you won't even protect what you try to protect because you cannot control the connection. It would be interesting if someone would implement it that way now, so Mauro disqualified himself with this proposal. Although please continue I'll keep watching, either result (supporting or not supporting it) is fine with me. Markus In other words, the DVB net_tunnel driver will take care of using the network stack, implement Kernel namespaces, etc, in order to allow virtualizing a remote hardware, without needing any userspace driver for doing that (well, except, of course, for the standard network userspace applications for DNS solving, configuring IP routes, etc). Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab mche...@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 o...@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
Re: [RFC] vtunerc - virtual DVB device driver
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. since a customer was trying to use this module the only feedback I can give right now is that there are still some fundamental bugs in that work. Just running it with some intuitive parameters (without having a dvb device connected) caused it to hang. ./vtunerc.i686 -c 1 vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C as mode 0, searching for tuner types 2 vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode specified: 1 allow values are: -s -S -s2 -S2 -c -t it just never returned. DMESG: vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer ps fax | grep vtunerc: 5194 pts/4S 0:00 | \_ bash 5210 pts/4S+ 0:00 | \_ [vtunerc.i686] that way it's not good enough for inclusion yet anyway. Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. In conjunction with Dreamtuner userland project [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger user can create virtual DVB device on client side and connect it to the server. When connected, user is able to use any Linux DVB API compatible application on client side (like VDR, MeTV, MythTV, etc) without any need of code modification. As server can be used any Linux DVB API compatible device. IMHO, this needs a Documentation file for the userspace API (kinda like tuntap.txt). -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Rémi Denis-Courmont r...@remlab.net: Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Hi Devin. 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: 2011/6/20 Rémi Denis-Courmont r...@remlab.net: Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. Thanks /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On Mon, Jun 20, 2011 at 2:17 PM, HoP jpetr...@gmail.com wrote: Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. See the userspace tuner thread here for the background: http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840 easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It helps in that it allows third parties to write drivers in userspace that leverage the in-kernel implementation of DVB core. It means that a product developer who didn't want to abide by the GPL could write a closed-source driver in userland which takes advantage of the thousands of lines of code that make up the DVB core. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. I am against things like this being in the upstream kernel which make it easier for third parties to leverage GPL code without making their code available under the GPL. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] vtunerc - virtual DVB device driver
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Devin Heitmueller Sent: lundi 20 juin 2011 20:25 To: HoP Cc: Rémi Denis-Courmont; linux-media@vger.kernel.org Subject: Re: [RFC] vtunerc - virtual DVB device driver On Mon, Jun 20, 2011 at 2:17 PM, HoP jpetr...@gmail.com wrote: Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. See the userspace tuner thread here for the background: http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840 easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It helps in that it allows third parties to write drivers in userspace that leverage the in-kernel implementation of DVB core. It means that a product developer who didn't want to abide by the GPL could write a closed-source driver in userland which takes advantage of the thousands of lines of code that make up the DVB core. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. I am against things like this being in the upstream kernel which make it easier for third parties to leverage GPL code without making their code available under the GPL. If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Also, most the DVB drivers code released under GPL is nearly impossible to understand as there is no documentation (because of NDA agreements with developers - as I understood) and no inline comments. So does-it make so much difference with closed source code? I really don't want to aggress anybody here, but it's really a question I have. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Sébastien RAILLARD (COEXSI) s...@coexsi.fr: If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. If somebody wants to write a closed source driver, they are welcome to (in fact, some companies actually have). But I'll be damned if they're going to reuse GPL code to accomplish it. They are welcome to reimplement the DVB core in userland if that is their goal (under whatever licensing terms suits them). Also, most the DVB drivers code released under GPL is nearly impossible to understand as there is no documentation (because of NDA agreements with developers - as I understood) and no inline comments. So does-it make so much difference with closed source code? I really don't want to aggress anybody here, but it's really a question I have. I disagree with this assertion. I have worked on *many* different drivers in the DVB subsystem, most of them without having the datasheets. While having the datasheets definitely is helpful (and can definitely speed up debugging), I would argue that they are not essential. Also, a number of the drivers are reverse engineered (no datasheets from the vendor), which is why the registers are not documented (the person writing the code didn't actually know). While there are indeed cases where an NDA specifically prohibited releasing a GPL driver that contained the register names, this tends to be more the exception rather than the rule. All the drivers I have done with vendor assistance/datasheets have allowed me to include register names in the driver. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Hello again, Le lundi 20 juin 2011 20:41:44 Devin Heitmueller, vous avez écrit : Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it easier for evil tuner manufacturers to leverage all the hard work done Err? My point is exactly the opposite: without a dedicated virtual DVB device, (open-source) developers are stuck with CUSE, which if it would work at all, would be a major waste of effort. And then, it won't work for unprivileged processes due to CUSE ioctl's restrictions. In other words, my point was technical, not political. by the LinuxTV developers while providing a closed-source solution. This does not enable much that evil closed-source device vendors couldn't already do. Virtually any Linux-DVB-capable tool will also accept MPEG-TS feed piped from standard input. Tuning would have to use a dedicated interface; that's pretty much the only inconvenience. DVB_NET can be implemented with the TUNTAP driver easily if it comes to that. And remote control can be mulated with the uinput driver all the same. There is even a mem2mem V4L2 device nowadays, is there not? And while uinput and tuntap allow proprietary userspace drivers, they come with major limitations inherent to userspace which limit their usefulness for proprietary device drivers. FWIW, virtual device driver enables (open-source) innovation. There are countless useful IP tunnels or emulators using TUN or TAP for instance. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I am afraid I don't understand how is Linux-DVB different from other Linux subsystems, such as the (much larger in terms of non-driver-specific code) networking one. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: 2011/6/20 Sébastien RAILLARD (COEXSI) s...@coexsi.fr: If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. If somebody wants to write a closed source driver, they are welcome to (in fact, some companies actually have). But I'll be damned if they're going to reuse GPL code to accomplish it. They are welcome to reimplement the DVB core in userland if that is their goal (under whatever licensing terms suits them). 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): I have equipment, based of course on Linux and others open-source code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs on inputs and ethernet on output). If I understand you well, I have to cut such box feature (which is, btw, one of very nicer usecase of such box) and stop thinking about it? Do you really think that it is a good way which should linux come? I don't like binary drivers as well. But if developers can't extend usability of linux because of worrying about blob drivers, it is not good, it is path to the hell. My 2cents. /Honza PS: I don't want to start any war, but I would like to know if it is only Devin POV or it has wider support inside linux-media hackers. Of course I will stay with my drivers outside the kernel. Ugly, I know. But I never want to enter by closed doors. Not my way. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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. Every couple of years somebody implements such a driver, and they have all been rejected for upstream. I have equipment, based of course on Linux and others open-source code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs on inputs and ethernet on output). If I understand you well, I have to cut such box feature (which is, btw, one of very nicer usecase of such box) and stop thinking about it? Do you really think that it is a good way which should linux come? I don't like binary drivers as well. But if developers can't extend usability of linux because of worrying about blob drivers, it is not good, it is path to the hell. The unfortunate fact is that allowing this sort of thing *does* allow for abuse of the interface, even if was not the intention of the original author of the patch/driver. In fact, I believe all the cases in the past were by people who were friendly to open source. My 2cents. /Honza PS: I don't want to start any war, but I would like to know if it is only Devin POV or it has wider support inside linux-media hackers. Of course I will stay with my drivers outside the kernel. Ugly, I know. But I never want to enter by closed doors. Not my way. To be fair, I am not the originator of this argument. If you read the history, a variety of other Linux DVB-V4L developers have shared the same view (which I adopted after hearing the arguments). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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. Every couple of years somebody implements such a driver, and they have all been rejected for upstream. Why same not apply to other devices? If I would be really accurate I would vote for removing nfs, smbfs and all other network sharing filesystems. original author of the patch/driver. In fact, I believe all the cases in the past were by people who were friendly to open source. I would like to know how much such bad guys stayed with kernel development. To be fair, I am not the originator of this argument. If you read the history, a variety of other Linux DVB-V4L developers have shared the same view (which I adopted after hearing the arguments). Seems DVB hackers are very specific group. Such politic rule don't wan't to have any place in the code development. Of course, it's my personal opinion only. /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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. I simply didn't expect that my source will be refused because of worrying about misuse it to the bad things(tm). Note again: I did it GPLed and opensourced, I never ever thought about binary blobs or some other closed stuffs! /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Devin Heitmueller dheitmuel...@kernellabs.com writes: Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. You could use the same argument against adding a loadable module interface to the Linux kernel (and I'm pretty sure it was used). Thankfully, usability won back then. Or we most likely wouldn't have had a single Linux DVB driver. Or Linux at all, except as a historical footnote. Honza posted a GPL licensed driver and gave a pretty good usage scenario. Please don't reject it based on fear of abuse. If you think about it, almost any usability improvement will also make abuse easier. And if you reject all of them based on such fear, then your system will die. Thanks. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On Mon, Jun 20, 2011 at 6:11 PM, Bjørn Mork bj...@mork.no wrote: Devin Heitmueller dheitmuel...@kernellabs.com writes: Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. You could use the same argument against adding a loadable module interface to the Linux kernel (and I'm pretty sure it was used). Thankfully, usability won back then. Or we most likely wouldn't have had a single Linux DVB driver. Or Linux at all, except as a historical footnote. Honza posted a GPL licensed driver and gave a pretty good usage scenario. Please don't reject it based on fear of abuse. If you think about it, almost any usability improvement will also make abuse easier. And if you reject all of them based on such fear, then your system will die. There isn't much sense in having this discussion again (and kicking off yet another flamewar). All of your arguments have been made before (and in the case of Linux DVB, they failed). I would suggest you read the archives and see how the developers arrived at their conclusions. If you have some *new* argument to offer, then feel free. Otherwise it's just flamebait. Anyway, I've said what I have to say on this topic. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com 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). We don't want to go on this way again. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
