Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

[Rob Clark <robdclark@gmail.com>]

On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em Thu, 11 Oct 2012 09:20:12 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> > my understaning is
>> > that the drivers/media/ authors should also ack with this licensing
>> > (possible) change. I am one of the main contributors there. Alan also has
>> > copyrights there, and at other parts of the Linux Kernel, including the driver's
>> > core, from where all Linux Kernel drivers are derivative work, including this one.
>> >
>> > As Alan well said, many other core Linux Kernel authors very likely share
>> > this point of view.
>> >
>> > So, developers implicitly or explicitly copied in this thread that might be
>> > considering the usage of dmabuf on proprietary drivers should consider
>> > this email as a formal notification of my viewpoint: e. g. that I consider
>> > any attempt of using DMABUF or media core/drivers together with proprietary
>> > Kernelspace code as a possible GPL infringement.
>>
>> As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your
>> statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking)
>
> If you read the Kernel COPYING file, it is explicitly said there that the Kernel
> is licensing with GPLv2. The _ONLY_ exception there is the allowance to use
> the kernel via normal syscalls:
>
>            "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".
>          Also note that the GPL below is copyrighted by the Free Software
>          Foundation, but the instance of code that it refers to (the Linux
>          kernel) is copyrighted by me and others who actually wrote it."
>
> The usage of EXPORT_SYMBOL() is not covered there, so those symbols are also
> covered by GPLv2.
>
> As the usage of a kernel symbol by a proprietary driver is not explicitly
> listed there as a GPLv2 exception, the only concrete results of this patch is
> to spread FUD, as EXPORT_SYMBOL might generate some doubts on people that
> don't read the Kernel's COPYING file.
>
> With or without this patch, anyone with intelectual rights in the Kernel may
> go to court to warrant their rights against the infringing closed source drivers.
> By not making it explicitly, you're only trying to fool people that using
> it might be allowed.

Maybe a dumb question (I'm a programmer, not a lawyer), but does it
change anything if we make the APIs related to *exporting* a dmabuf as
EXPORT_SYMBOL() and keep the APIs related to *importing* as
EXPORT_SYMBOL_GPL().  This at least avoids the non-GPL kernel module
from calling in to other driver code, while still allowing the non-GPL
driver to export a buffer that GPL drivers could use.

BR,
-R

>> BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL.
>
> Agreed.
>
>> The number of contributors to v4l2-ctrls.c is very limited, and I have no
>> problem moving that to GPL. For me dmabuf is the rare exception where I prefer
>> EXPORT_SYMBOL to prevent the worse evil of forcing vendors to create incompatible
>> APIs. It's a sad but true that many GPU drivers are still closed source,
>> particularly in the embedded world for which dmabuf was primarily designed.
>
> My understanding is that even the creation of incompatible Kernel API
> is a presumed GPL violation, as it is an attempt to circumvent the license.
>
> Basically, if vendors want to work with closed source, there are other options
> in the market. But if they want to work with Linux, they should be contributing
> upstream, instead of doing proprietary blobs.
>
> Regards,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html