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. Regards, Andreas -- 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
