Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@xxxxxxxxxxx> wrote: >>>>> Mauro and Devin, I think you're missing the point. This is not about >>>>> creating drivers in userspace. This is not about open or closed source. >>>>> The "vtuner" interface, as implemented for the Dreambox, is used to >>>>> access remote tuners: Put x tuners into y boxes and access them from >>>>> another box as if they were local. It's used in conjunction with further >>>>> software to receive the transport stream over a network connection. >>>>> Honza's code does the same thing. >>>> >>>> I'm not missing the point at all. I realize exactly what Honza is >>>> trying to accomplish (and from a purely technical standpoint, it's not >>>> a bad approach) - but I'm talking about the effects of such a driver >>>> being introduced which changes the kernel/userland licensing boundary >>>> and has very real implications with how the in-kernel code is >>>> accessed. >>>> >>>>> You don't need it in order to create closed source drivers. You can >>>>> already create closed kernel drivers now. Also, you can create tuner >>>>> drivers in userspace using the i2c-dev interface. If you like to connect >>>>> a userspace driver to a DVB API device node, you can distribute a small >>>>> (open or closed) wrapper with it. So what are you arguing about? >>>>> Everything you're feared of can already be done since virtually forever. >>>> >>>> I disagree. There is currently no API which allows applications to >>>> issue tuning requests into the DVB core, and have those requests >>>> proxied back out to userland where an application can then use i2c-dev >>>> to tune the actual device. Meaning if somebody wants to write a >>>> closed source userland application which controls the tuner, he/she >>>> can do that (while not conforming to the DVB API). But if if he wants >>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>>> core. >>>> >>>> The introduction of this patch makes it trivial for a third party to >>>> provide closed-source userland support for tuners while reusing all >>>> the existing GPL driver code that makes up the framework. >>>> >>>> I used to work for a vendor that makes tuners, and they do a bunch of >>>> Linux work. And that work has resulted in a bunch of open source >>>> drivers. I can tell you though that *every* conversation I've had >>>> regarding a new driver goes something like this: >>>> >>>> === >>>> "Devin, we need to support tuner X under Linux." >>>> >>>> "Great! I'll be happy to write a new GPL driver for the >>>> tuner/demodulator/whatever for that device" >>>> >>>> "But to save time/money, we just want to reuse the Windows driver code >>>> (or reference code from the vendor)." >>>> >>>> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >>>> >>>> "Not currently. So can we just make our driver closed source?" >>>> >>>> "Well, you can't reuse any of the existing DVB core functionality or >>>> any of the other GPL drivers (tuners, bridges, demods), so you would >>>> have rewrite all that from scratch." >>>> >>>> "Oh, that would be a ton of work. Can we maybe write some userland >>>> stuff that controls the demodulator which we can keep closed source? >>>> Since it's not in the kernel, the GPL won't apply". >>>> >>>> "Well, you can't really do that because there is no way for the DVB >>>> core to call back out to userland when the application makes the >>>> tuning request to the DVB core." >>>> >>>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>>> to give us the reference driver code under the GPL." >>>> === >>>> >>>> I can tell you without a doubt that if this driver were present in the >>>> kernel, that going forward that vendor would have *zero* interest in >>>> doing any GPL driver work. Why would they? Why give away the code >>>> which could potentially help their competitors if they can keep it >>>> safe and protected while still being able to reuse everybody else's >>>> contributions? >>>> >>>> Companies don't contribute GPL code out of "good will". They do it >>>> because they are compelled to by licenses or because there is no >>>> economically viable alternative. >>>> >>>> Mauro, ultimately it is your decision as the maintainer which drivers >>>> get accepted in to the kernel. I can tell you though that this will >>>> be a very bad thing for the driver ecosystem as a whole - it will >>>> essentially make it trivial for vendors (some of which who are doing >>>> GPL work now) to provide solutions that reuse the GPL'd DVB core >>>> without having to make any of their stuff open source. >>>> >>>> Anyway, I said in my last email that would be my last email on the >>>> topic. I guess I lied. >>> >>> Yes, and you did lie to your vendor, too, as you did not mention the >>> possibilities to create >>> 1.) closed source modules derived from existing vendor drivers while >>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs. >>> EXPORT_SYMBOL_GPL). >> >> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL >> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly >> adds a restriction, not using it doesn't necessarily mean that the symbol >> can be used by a closed source driver. >> >> If you take a look at Kernel's COPYING file, the only exception to GPL license >> allowed there is: >> >> NOTE! This copyright does *not* cover user programs that use kernel >> services by normal system calls - this is merely considered normal use >> of the kernel, and does *not* fall under the heading of "derived work". >> >> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that >> it is also covered by GPL. > > Of course. But as you should know, the GPL only covers derived work. > Whether or not a driver is a derived work of the kernel can only be > decided individually. It is my understanding that a Windows driver > ported to Linux is unlikely to be a derived work of Linux. > >> I was told that several lawyers defend the idea that all software inside the >> kernel tree is covered by GPL, even the aggregated ones. That was the rationale >> used to split the firmware packages from the kernel itself. > > However, I wasn't referring to the kernel tree at all. > >>> 2.) a simple wrapper that calls userspace, therefore not having to open >>> up any "secrets" at all. >> >> A wrapper for a closed source driver is illegal, as it is trying to circumvent >> the GPL license. > > Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be > illegal by its pure existence and a wrapper does usually not try to do > anything by itself. Third, you can implement a wrapper using normal > system calls (read, write, mmap, ioctl ...). That's what vtuner does, > too, to accomplish a totally different goal. Do you think vtuner is > illegal? I would be very surprised if it was. It perfectly matches the > license exception cited above. And even without the exception, a closed > driver in userspace would only very unlikely be a derived work of the > kernel. I think we're diverging from the subject. Most of those discussions are interesting on some lawyers forum, not here. My view about this subject is that vtuner can't give any additional permissions to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners, nor were approved by them. So, the extra permission at the COPYING clause from kernel doesn't apply here, while the code is not merged into the Kernel. So, while it should be legal to use vtuner with a GPL'd client application, using it by a closed source application violates GPL. My understanding is that an addition of a code that exposes the internal DVB core API to userspace like that will require that all dvb developers that have copyright rights at the dvb core should explicitly ack with such change, otherwise adding such code will violate the original license. On the other hand, if vtunerc won't act as a proxy to userspace, it should probably be ok. If people have different understandings, then we'll likely need to ask some support from Open source lawyers about this subject. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
