dma-buf: Use EXPORT_SYMBOL

Message ID 1349884592-32485-1-git-send-email-rmorell@nvidia.com
State New
Headers show

Commit Message

Robert Morell Oct. 10, 2012, 3:56 p.m.
EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
issue, and not really an interface".  The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use EXPORT_SYMBOL instead.

Signed-off-by: Robert Morell <rmorell@nvidia.com>
---
This patch is based on Linus's master branch.

We held a discussion at ELC, and agreed that EXPORT_SYMBOL is more appropriate
for this interface than EXPORT_SYMBOL_GPL.

 drivers/base/dma-buf.c |   34 +++++++++++++++++-----------------
 1 files changed, 17 insertions(+), 17 deletions(-)

Comments

Mauro Carvalho Chehab Oct. 10, 2012, 4:23 p.m. | #1
Em Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell <rmorell@nvidia.com> escreveu:

> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface".  The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL instead.
> 
> Signed-off-by: Robert Morell <rmorell@nvidia.com>

NAK, as already explained at:

http://lists.freedesktop.org/archives/dri-devel/2012-January/018281.html

Regards,
Mauro
Alan Cox Oct. 10, 2012, 6:17 p.m. | #2
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell <rmorell@nvidia.com> wrote:

> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface".  The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL instead.

NAK. This needs at the very least the approval of all rights holders for
the files concerned and all code exposed by this change.

Also I'd note if you are trying to do this for the purpose of combining
it with proprietary code then you are still in my view as a (and the view
of many other) rights holder to the kernel likely to be in breach
of the GPL requirements for a derivative work. You may consider that
formal notification of my viewpoint. Your corporate legal team can
explain to you why the fact you are now aware of my view is important to
them.

Alan
Rob Clark Oct. 10, 2012, 9:02 p.m. | #3
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 10 Oct 2012 08:56:32 -0700
> Robert Morell <rmorell@nvidia.com> wrote:
>
>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> issue, and not really an interface".  The dma-buf infrastructure is
>> explicitly intended as an interface between modules/drivers, so it
>> should use EXPORT_SYMBOL instead.
>
> NAK. This needs at the very least the approval of all rights holders for
> the files concerned and all code exposed by this change.

Well, for my contributions to dmabuf, I don't object.. and I think
because we are planning to use dma-buf in userspace for dri3 /
dri-next, I think that basically makes it a userspace facing kernel
infrastructure which would be required for open and proprietary
drivers alike.  So I don't see much alternative to making this
EXPORT_SYMBOL().  Of course, IANAL.

BR,
-R

> Also I'd note if you are trying to do this for the purpose of combining
> it with proprietary code then you are still in my view as a (and the view
> of many other) rights holder to the kernel likely to be in breach
> of the GPL requirements for a derivative work. You may consider that
> formal notification of my viewpoint. Your corporate legal team can
> explain to you why the fact you are now aware of my view is important to
> them.
>
> Alan
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave Airlie Oct. 10, 2012, 11:22 p.m. | #4
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 10 Oct 2012 08:56:32 -0700
> Robert Morell <rmorell@nvidia.com> wrote:
>
>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> issue, and not really an interface".  The dma-buf infrastructure is
>> explicitly intended as an interface between modules/drivers, so it
>> should use EXPORT_SYMBOL instead.
>
> NAK. This needs at the very least the approval of all rights holders for
> the files concerned and all code exposed by this change.

I think he has that. Maybe he just needs to list them. But this
doesn't change the license on the code at all really, so its actually
not like a re-license where you need approval.

But in any case I personally don't care about this interface being
used if the alternative is they do it themselves. I'm still not going
to debug things with a binary module taint.

Dave.
Mauro Carvalho Chehab Oct. 11, 2012, 1:11 a.m. | #5
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie <airlied@gmail.com> escreveu:

> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell <rmorell@nvidia.com> wrote:
> >
> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> >> issue, and not really an interface".  The dma-buf infrastructure is
> >> explicitly intended as an interface between modules/drivers, so it
> >> should use EXPORT_SYMBOL instead.
> >
> > NAK. This needs at the very least the approval of all rights holders for
> > the files concerned and all code exposed by this change.
> 
> I think he has that. Maybe he just needs to list them. 

My understanding it that he doesn't, as the dmabuf interface exposes not only
the code written by this driver's author, but other parts of the Kernel.

Even if someone consider just the dmabuf driver, I participated and actively
contributed, together with other open source developers, during the 3 days 
discussions that happened at Linaro's forum where most of dmabuf design was
decided, and participated, reviewed, gave suggestions approved the code, etc
via email. So, even not writing the dmabuf stuff myself, I consider myself as 
one of the intelectual authors of the solution.

Also, as dmabuf will also expose media interfaces, 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.

Regards,
Mauro
Dave Airlie Oct. 11, 2012, 2:50 a.m. | #6
>> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > On Wed, 10 Oct 2012 08:56:32 -0700
>> > Robert Morell <rmorell@nvidia.com> wrote:
>> >
>> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> >> issue, and not really an interface".  The dma-buf infrastructure is
>> >> explicitly intended as an interface between modules/drivers, so it
>> >> should use EXPORT_SYMBOL instead.
>> >
>> > NAK. This needs at the very least the approval of all rights holders for
>> > the files concerned and all code exposed by this change.
>>
>> I think he has that. Maybe he just needs to list them.
>
> My understanding it that he doesn't, as the dmabuf interface exposes not only
> the code written by this driver's author, but other parts of the Kernel.
>
> Even if someone consider just the dmabuf driver, I participated and actively
> contributed, together with other open source developers, during the 3 days
> discussions that happened at Linaro's forum where most of dmabuf design was
> decided, and participated, reviewed, gave suggestions approved the code, etc
> via email. So, even not writing the dmabuf stuff myself, I consider myself as
> one of the intelectual authors of the solution.
>
> Also, as dmabuf will also expose media interfaces, 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.

Though that does beg the question why you care about this patch :-)

Dave.
Hans Verkuil Oct. 11, 2012, 6:57 a.m. | #7
On Wed October 10 2012 23:02:06 Rob Clark wrote:
> On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell <rmorell@nvidia.com> wrote:
> >
> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> >> issue, and not really an interface".  The dma-buf infrastructure is
> >> explicitly intended as an interface between modules/drivers, so it
> >> should use EXPORT_SYMBOL instead.
> >
> > NAK. This needs at the very least the approval of all rights holders for
> > the files concerned and all code exposed by this change.
> 
> Well, for my contributions to dmabuf, I don't object.. and I think
> because we are planning to use dma-buf in userspace for dri3 /
> dri-next, I think that basically makes it a userspace facing kernel
> infrastructure which would be required for open and proprietary
> drivers alike.  So I don't see much alternative to making this
> EXPORT_SYMBOL().  Of course, IANAL.

The whole purpose of this API is to let DRM and V4L drivers share buffers for
zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers
are closed source. So we have a choice between keeping the export symbols GPL
and forcing those closed-source drivers to make their own incompatible API,
thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
the closed source vendors worry about the legality. They are already using such
functions (at least nvidia is), so they clearly accept that risk.

I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse
evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL
limitation. Neither situation is paradise, but at least one is a slightly less
depressing world than the other :-)

In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did not
do any coding but only some initial design help and reviewing.

Regards,

	Hans
Hans Verkuil Oct. 11, 2012, 7:20 a.m. | #8
On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote:
> Em Thu, 11 Oct 2012 09:22:34 +1000
> Dave Airlie <airlied@gmail.com> escreveu:
> 
> > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > On Wed, 10 Oct 2012 08:56:32 -0700
> > > Robert Morell <rmorell@nvidia.com> wrote:
> > >
> > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > >> issue, and not really an interface".  The dma-buf infrastructure is
> > >> explicitly intended as an interface between modules/drivers, so it
> > >> should use EXPORT_SYMBOL instead.
> > >
> > > NAK. This needs at the very least the approval of all rights holders for
> > > the files concerned and all code exposed by this change.
> > 
> > I think he has that. Maybe he just needs to list them. 
> 
> My understanding it that he doesn't, as the dmabuf interface exposes not only
> the code written by this driver's author, but other parts of the Kernel.
> 
> Even if someone consider just the dmabuf driver, I participated and actively
> contributed, together with other open source developers, during the 3 days 
> discussions that happened at Linaro's forum where most of dmabuf design was
> decided, and participated, reviewed, gave suggestions approved the code, etc
> via email. So, even not writing the dmabuf stuff myself, I consider myself as 
> one of the intelectual authors of the solution.
> 
> Also, as dmabuf will also expose media interfaces,

That's new to me. All it does is represent a buffer. It doesn't expose any
interfaces, media or otherwise.

> 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)

BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL.
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.

Regards,

	Hans
Hans Verkuil Oct. 11, 2012, 7:51 a.m. | #9
On Thu 11 October 2012 09:20:12 Hans Verkuil wrote:
> On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote:
> > Em Thu, 11 Oct 2012 09:22:34 +1000
> > Dave Airlie <airlied@gmail.com> escreveu:
> > 
> > > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > > On Wed, 10 Oct 2012 08:56:32 -0700
> > > > Robert Morell <rmorell@nvidia.com> wrote:
> > > >
> > > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > > >> issue, and not really an interface".  The dma-buf infrastructure is
> > > >> explicitly intended as an interface between modules/drivers, so it
> > > >> should use EXPORT_SYMBOL instead.
> > > >
> > > > NAK. This needs at the very least the approval of all rights holders for
> > > > the files concerned and all code exposed by this change.
> > > 
> > > I think he has that. Maybe he just needs to list them. 
> > 
> > My understanding it that he doesn't, as the dmabuf interface exposes not only
> > the code written by this driver's author, but other parts of the Kernel.
> > 
> > Even if someone consider just the dmabuf driver, I participated and actively
> > contributed, together with other open source developers, during the 3 days 
> > discussions that happened at Linaro's forum where most of dmabuf design was
> > decided, and participated, reviewed, gave suggestions approved the code, etc
> > via email. So, even not writing the dmabuf stuff myself, I consider myself as 
> > one of the intelectual authors of the solution.
> > 
> > Also, as dmabuf will also expose media interfaces,
> 
> That's new to me. All it does is represent a buffer. It doesn't expose any
> interfaces, media or otherwise.
> 
> > 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)
> 
> BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL.
> 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.

One thing I am also worried about is that if vendors can't use dmabuf for their
closed-source GPU driver, then they may not bother making GPL V4L drivers and
instead stick to a proprietary solution (e.g. OpenMAX), Which would be a shame
since we are making good progress with convincing vendors (esp. SoC vendors) to
create GPL V4L2 drivers for their hardware.

Regards,

	Hans
Maarten Lankhorst Oct. 11, 2012, 9:10 a.m. | #10
Op 11-10-12 09:51, Hans Verkuil schreef:
>>> 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)
>>
>> BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL.
>> 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.
> One thing I am also worried about is that if vendors can't use dmabuf for their
> closed-source GPU driver, then they may not bother making GPL V4L drivers and
> instead stick to a proprietary solution (e.g. OpenMAX), Which would be a shame
> since we are making good progress with convincing vendors (esp. SoC vendors) to
> create GPL V4L2 drivers for their hardware.
Powervr is probably the most well known and I knwo of at least one BSD/GPL driver,
iirc tegra does similar so it should be possible to do similar for their x86 counterparts.
They can still do whatever they want in userspace and are not required to disclose
source for their super secret opengl/cuda/vdpau sauce, cf COPYING.

Usual disclaimer applies, I'm not a lawyer, and speaking for myself here.

~Maarten
Mauro Carvalho Chehab Oct. 11, 2012, 11:13 a.m. | #11
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.

> 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
Alan Cox Oct. 11, 2012, 11:30 a.m. | #12
> 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)

Yes. The GPL talks about derivative works (as does copyright law).

Alan
Alan Cox Oct. 11, 2012, 11:34 a.m. | #13
> The whole purpose of this API is to let DRM and V4L drivers share buffers for
> zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers
> are closed source. So we have a choice between keeping the export symbols GPL
> and forcing those closed-source drivers to make their own incompatible API,
> thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
> the closed source vendors worry about the legality. They are already using such
> functions (at least nvidia is), so they clearly accept that risk.

Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
calling into it anyway can't they. Your argument makes no rational sense
of any kind.

Alan
Hans Verkuil Oct. 11, 2012, 11:36 a.m. | #14
On Thu 11 October 2012 13:34:07 Alan Cox wrote:
> > The whole purpose of this API is to let DRM and V4L drivers share buffers for
> > zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers
> > are closed source. So we have a choice between keeping the export symbols GPL
> > and forcing those closed-source drivers to make their own incompatible API,
> > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
> > the closed source vendors worry about the legality. They are already using such
> > functions (at least nvidia is), so they clearly accept that risk.
> 
> Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> calling into it anyway can't they. Your argument makes no rational sense
> of any kind.

Out of curiosity: why do we have both an EXPORT_SYMBOL and an EXPORT_SYMBOL_GPL
if there is no legal difference?

And if there is a difference between the two, then what is it?

Regards,

	Hans
Alan Cox Oct. 11, 2012, 11:37 a.m. | #15
> > 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.
> 
> Though that does beg the question why you care about this patch :-)

Because my legal advice is to object and remind people who suggest
otherwise. There are specific reasons to do so around estoppel and
willful infringement.

It's not a case of objections anyway - if the _GPL matters then it's a
licensing change so you need the approval of everyone whose code is
involved. At that point I think Nvidia are starting in the wrong place
and need to start with a collection of vendors corporate legal contacts
and then work down the call tree involved.

Alan
Hans Verkuil Oct. 11, 2012, 12:10 p.m. | #16
On Thu 11 October 2012 13:36:45 Hans Verkuil wrote:
> On Thu 11 October 2012 13:34:07 Alan Cox wrote:
> > > The whole purpose of this API is to let DRM and V4L drivers share buffers for
> > > zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers
> > > are closed source. So we have a choice between keeping the export symbols GPL
> > > and forcing those closed-source drivers to make their own incompatible API,
> > > thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
> > > the closed source vendors worry about the legality. They are already using such
> > > functions (at least nvidia is), so they clearly accept that risk.
> > 
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
> 
> Out of curiosity: why do we have both an EXPORT_SYMBOL and an EXPORT_SYMBOL_GPL
> if there is no legal difference?
> 
> And if there is a difference between the two, then what is it?

Answering myself:

http://lwn.net/Articles/154602/
Laurent Pinchart Oct. 11, 2012, 12:52 p.m. | #17
Hi Hans,

On Thursday 11 October 2012 13:36:45 Hans Verkuil wrote:
> On Thu 11 October 2012 13:34:07 Alan Cox wrote:
> > > The whole purpose of this API is to let DRM and V4L drivers share
> > > buffers for zero-copy pipelines. Unfortunately it is a fact that
> > > several popular DRM drivers are closed source. So we have a choice
> > > between keeping the export symbols GPL and forcing those closed-source
> > > drivers to make their own incompatible API, thus defeating the whole
> > > point of DMABUF, or using EXPORT_SYMBOL and letting the closed source
> > > vendors worry about the legality. They are already using such functions
> > > (at least nvidia is), so they clearly accept that risk.
> > 
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
> 
> Out of curiosity: why do we have both an EXPORT_SYMBOL and an
> EXPORT_SYMBOL_GPL if there is no legal difference?
> 
> And if there is a difference between the two, then what is it?

As far as I understand, EXPORT_SYMBOL_GPL means "I consider closed-source 
kernel modules as a GPL violation, you can have a different opinion, but then 
don't use my APIs".
Rob Clark Oct. 11, 2012, 1:47 p.m. | #18
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
Mauro Carvalho Chehab Oct. 11, 2012, 2:55 p.m. | #19
Em Thu, 11 Oct 2012 08:47:15 -0500
Rob Clark <robdclark@gmail.com> escreveu:

> 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.


IANAL. My understanding is that nothing changes by using either programmer's
dialect: it sounds doubtful that the court would actually take a look
into the Kernel's source code: they're lawyers, not programmers, and
both clauses are just Kernel's source code. Nothing more, nothing less:

EXPORT_SYMBOL, is not EXPORT_SYMBOL_BSD (or similar): this syntax
doesn't bring _any_kind_ of additional licensing rights. That means that
the licensing terms that apply there are just the ones stated at COPYING
file.

So, in any case, the court will judge the allegations based at the Kernel
licensing terms, and will seek if the terms of such licensing were
violated. The court will also likely use formal notifications of
potential infringements, like the ones in this thread, and other
non-technical documents, like meeting reports, email threads, etc,
in order to check who has intelectual rights on the Linux Kernel,
and if the ones that violated the rights did it by purpose.

Regards,
Mauro
Dave Airlie Oct. 11, 2012, 8:08 p.m. | #20
On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> The whole purpose of this API is to let DRM and V4L drivers share buffers for
>> zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers
>> are closed source. So we have a choice between keeping the export symbols GPL
>> and forcing those closed-source drivers to make their own incompatible API,
>> thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
>> the closed source vendors worry about the legality. They are already using such
>> functions (at least nvidia is), so they clearly accept that risk.
>
> Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> calling into it anyway can't they. Your argument makes no rational sense
> of any kind.

But then why object to the change, your objection makes sense, naking
the patch makes none, if you believe in your objection.

Also really its just bullshit handwaving all of it, your objection,
_GPL etc. until someone grows a pair and sues someone, instead of
hiding behind their employment status. If you really believed you were
right, you could retire on the settlement payout.

Dave.
Alan Cox Oct. 12, 2012, 4:32 p.m. | #21
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
> 
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.

[l/k added as I imagine a few other peopel will want to see this who
 don't read driver specific lists, Greg especially I guess]

'estoppel' and because my legal advice is specifically to do so. If you
don't understand why it matters then please get qualified legal advice.

I'm also objecting to the failure to follow proper process. If this does
make a difference as Nvidia seem to think then it is a clear requirement
that you gain permission from every rightsholder affected, as with any
other licensing change.

So I would suggest Nvidia start by going through the call tree and all
potential rightsholders and negotiating with all their corporate
attorneys to get each of them to provide a Signed-off-by: line for that
change and perhaps charge them for a license in the process.

Now as it happens lots of other people have objected to this last time it
was posted, and this time, so maybe they should just recognize the clear
will of the rightsholders concerned and give up on it.

It's very clear how most rights holders involved see the Nvidia
situation. What was it Linus said..

http://www.youtube.com/watch?v=IVpOyKCNZYw

so right from the top the opinion seems to be fairly clear.

> Also really its just bullshit handwaving all of it, your objection,
> _GPL etc. until someone grows a pair and sues someone, instead of
> hiding behind their employment status. If you really believed you were
> right, you could retire on the settlement payout.

Unlikely as most of the code I've written belongs to Intel or Red Hat. I
also have better things to do with life than sue Nvidia and start an all
out copyright and patent war in Linuxspace.

It's simple enough

If Nvidia think their code is not derivative then why do they care about
the _GPL being significant ?

Nouveau can call the DMA buf methods.

Alan
Robert Morell Oct. 16, 2012, 9:22 p.m. | #22
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote:
> On Wed October 10 2012 23:02:06 Rob Clark wrote:
> > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > On Wed, 10 Oct 2012 08:56:32 -0700
> > > Robert Morell <rmorell@nvidia.com> wrote:
> > >
> > >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > >> issue, and not really an interface".  The dma-buf infrastructure is
> > >> explicitly intended as an interface between modules/drivers, so it
> > >> should use EXPORT_SYMBOL instead.
> > >
> > > NAK. This needs at the very least the approval of all rights holders for
> > > the files concerned and all code exposed by this change.
> > 
> > Well, for my contributions to dmabuf, I don't object.. and I think
> > because we are planning to use dma-buf in userspace for dri3 /
> > dri-next, I think that basically makes it a userspace facing kernel
> > infrastructure which would be required for open and proprietary
> > drivers alike.  So I don't see much alternative to making this
> > EXPORT_SYMBOL().  Of course, IANAL.
> 
> The whole purpose of this API is to let DRM and V4L drivers share buffers for
> zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers
> are closed source. So we have a choice between keeping the export symbols GPL
> and forcing those closed-source drivers to make their own incompatible API,
> thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
> the closed source vendors worry about the legality. They are already using such
> functions (at least nvidia is), so they clearly accept that risk.
> 
> I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse
> evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL
> limitation. Neither situation is paradise, but at least one is a slightly less
> depressing world than the other :-)
> 
> In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did not
> do any coding but only some initial design help and reviewing.

Thanks for the discussion.

My intention is not to steal any code from the kernel or change any licenses.
The goal here is to allow interoperation between drivers.  I understand that it
can be difficult to debug the kernel when the nvidia binary module is loaded;
I'm not trying to force anyone to do that.  You're free to continue to use your
debug environment without change after this patch is applied.

I believe that the developers and maintainers of dma-buf have provided
the needed signoff, both in person and in this thread.  If there are any
objections from that group, I'm happy to discuss any changes necessary to get
this merged.

- Robert
Alan Cox Oct. 17, 2012, 9:53 a.m. | #23
> I believe that the developers and maintainers of dma-buf have provided
> the needed signoff, both in person and in this thread.  If there are any
> objections from that group, I'm happy to discuss any changes necessary to get
> this merged.

You need the permission of the owners of all the dependant code that
forms the work. The rules and licence are quite clear, as I think are the
views of several of the rights holders on both the interpretation and
intent of the licensing of their code.

Please go and discuss estoppel, wilful infringement and re-licensing with
your corporate attorneys. If you want to relicense components of the code
then please take the matter up with the corporate attorneys of the rights
holders concerned.

Alan
Dave Airlie Oct. 17, 2012, 9:54 a.m. | #24
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I believe that the developers and maintainers of dma-buf have provided
>> the needed signoff, both in person and in this thread.  If there are any
>> objections from that group, I'm happy to discuss any changes necessary to get
>> this merged.
>
> You need the permission of the owners of all the dependant code that
> forms the work. The rules and licence are quite clear, as I think are the
> views of several of the rights holders on both the interpretation and
> intent of the licensing of their code.
>
> Please go and discuss estoppel, wilful infringement and re-licensing with
> your corporate attorneys. If you want to relicense components of the code
> then please take the matter up with the corporate attorneys of the rights
> holders concerned.

Alan please stick with the facts. This isn't a relicense of anything.
EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
totally pointless thing, it should be
EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it
really should be EXPORT_SYMBOL, and really consult your lawyers
anyways.

Dave.
Dave Airlie Oct. 17, 2012, 10:08 a.m. | #25
>> Please go and discuss estoppel, wilful infringement and re-licensing with
>> your corporate attorneys. If you want to relicense components of the code
>> then please take the matter up with the corporate attorneys of the rights
>> holders concerned.
>
> Alan please stick with the facts. This isn't a relicense of anything.
> EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
> totally pointless thing, it should be
> EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it
> really should be EXPORT_SYMBOL, and really consult your lawyers
> anyways.
>

Also we should look at this
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html

original code posting had no EXPORT_SYMBOL, so the original author's
intents were quite clear.

Dave.
Dave Airlie Oct. 17, 2012, 10:19 a.m. | #26
b>>
>> Alan please stick with the facts. This isn't a relicense of anything.
>> EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
>> totally pointless thing, it should be
>> EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it
>> really should be EXPORT_SYMBOL, and really consult your lawyers
>> anyways.
>>
>
> Also we should look at this
> http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html
>
> original code posting had no EXPORT_SYMBOL, so the original author's
> intents were quite clear.

Yeah so a history research shows this didn't change until v3 of the
code base, and I don't think any lawyers were consulted about changing
the exports then, so I don't see why we should need any now. If we do
need some now, then we needed some then thus making the original
change of the exports a problem.

Now how do I withdraw a Signed-off-by and have dma-buf removed from the kernel?

(not I'm just spouting bullshit here which has as much value as
Alan's, as I said before unless someone grows a pair and sues someone
its all just IANAL and humble opinions.)

Dave.
Dave Airlie Oct. 17, 2012, 10:22 a.m. | #27
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > Please go and discuss estoppel, wilful infringement and re-licensing with
>> > your corporate attorneys. If you want to relicense components of the code
>> > then please take the matter up with the corporate attorneys of the rights
>> > holders concerned.
>>
>> Alan please stick with the facts. This isn't a relicense of anything.
>
> In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer
> - NO. Does my laywer disagree with you - YES.

Okay then we should remove this code from the kernel forthwith, as I
showed it was illegally relicensed previously in your lawyers opinion.

Dave.
Alan Cox Oct. 17, 2012, 10:25 a.m. | #28
> > Please go and discuss estoppel, wilful infringement and re-licensing with
> > your corporate attorneys. If you want to relicense components of the code
> > then please take the matter up with the corporate attorneys of the rights
> > holders concerned.
> 
> Alan please stick with the facts. This isn't a relicense of anything.

In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer
- NO. Does my laywer disagree with you - YES.

> EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
> totally pointless thing,

In your personal viewpoint. I disagree. I'm a rights holder too. 

Several rights holders have made it clear the change is not wanted. It's
over, done, buried. If you want it can go as far as Linus and then he can
get a copy of all the discussion and say that same as he did in the
classic video.

Should I start submitting all the Intel non-free user space X drivers at
this point as there seems to be a dramatic policy change going on here ?

Alan
Alan Cox Oct. 17, 2012, 10:38 a.m. | #29
On Wed, 17 Oct 2012 20:22:04 +1000
Dave Airlie <airlied@gmail.com> wrote:

> On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> > Please go and discuss estoppel, wilful infringement and re-licensing with
> >> > your corporate attorneys. If you want to relicense components of the code
> >> > then please take the matter up with the corporate attorneys of the rights
> >> > holders concerned.
> >>
> >> Alan please stick with the facts. This isn't a relicense of anything.
> >
> > In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer
> > - NO. Does my laywer disagree with you - YES.
> 
> Okay then we should remove this code from the kernel forthwith, as I
> showed it was illegally relicensed previously in your lawyers opinion.

That would not be the same question I asked my lawyer.

Anyway I refer you to the Developer's Certificate of Origin 1.1.

Anything Signed off was submitted under the GPL and so is usable as part
of a GPL derived work, but not as part of a non GPL derived work. Thus
Nouveau can happily use it for example. Simples.

And as I said before if Nvidia believe the _GPL makes no difference and
their work is not derivative then it's clearly within their power to just
ignore it, at which point *they* take the risk on their own.

From the fact this patch keeps getting resubmitted despite repeated
objection I deduce they are in fact of the view it does matter and that
therefore it is a licensing change and they are scared of the
consequences of ignoring it.

Alan
Dave Airlie Oct. 17, 2012, 10:40 a.m. | #30
> From the fact this patch keeps getting resubmitted despite repeated
> objection I deduce they are in fact of the view it does matter and that
> therefore it is a licensing change and they are scared of the
> consequences of ignoring it.
>

No I think they just want to have to write a pointless hack lie in
their kernel module.

There is no nice way for nvidia developers to say our lawyers don't
think this is a license issues without doing

MODULE_LICENSE("GPL\0 OH NOT WE DIDNT OUR LAWYESR ARE OKAY");

I don't think I'd be going quite into how illegal it is.

The thing is I can't base a useful userspace interface on this, and
since the nvidia driver exists everwhere despite what we'd wish, I'd
rather let the users have some hope of a sane architecture, instead of
nvidia having to replace even more userspace code and kernel code with
their own insane shit.

Dave.
Dave Airlie Oct. 25, 2012, 9:30 p.m. | #31
> Unlikely as most of the code I've written belongs to Intel or Red Hat. I
> also have better things to do with life than sue Nvidia and start an all
> out copyright and patent war in Linuxspace.

I forgot to ask, but after your petty G+ trolling, if most of the code
belings to Intel or Red Hat, why do we need to listen to *your*
lawyers advice? It seems like you aren't a major rights holder but a
troll.

Dave.

Patch hide | download patch | download mbox

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 460e22d..24c28be 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -122,7 +122,7 @@  struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
 
 	return dmabuf;
 }
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL(dma_buf_export);
 
 
 /**
@@ -148,7 +148,7 @@  int dma_buf_fd(struct dma_buf *dmabuf, int flags)
 
 	return fd;
 }
-EXPORT_SYMBOL_GPL(dma_buf_fd);
+EXPORT_SYMBOL(dma_buf_fd);
 
 /**
  * dma_buf_get - returns the dma_buf structure related to an fd
@@ -174,7 +174,7 @@  struct dma_buf *dma_buf_get(int fd)
 
 	return file->private_data;
 }
-EXPORT_SYMBOL_GPL(dma_buf_get);
+EXPORT_SYMBOL(dma_buf_get);
 
 /**
  * dma_buf_put - decreases refcount of the buffer
@@ -189,7 +189,7 @@  void dma_buf_put(struct dma_buf *dmabuf)
 
 	fput(dmabuf->file);
 }
-EXPORT_SYMBOL_GPL(dma_buf_put);
+EXPORT_SYMBOL(dma_buf_put);
 
 /**
  * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
@@ -234,7 +234,7 @@  err_attach:
 	mutex_unlock(&dmabuf->lock);
 	return ERR_PTR(ret);
 }
-EXPORT_SYMBOL_GPL(dma_buf_attach);
+EXPORT_SYMBOL(dma_buf_attach);
 
 /**
  * dma_buf_detach - Remove the given attachment from dmabuf's attachments list;
@@ -256,7 +256,7 @@  void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
 	mutex_unlock(&dmabuf->lock);
 	kfree(attach);
 }
-EXPORT_SYMBOL_GPL(dma_buf_detach);
+EXPORT_SYMBOL(dma_buf_detach);
 
 /**
  * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
@@ -283,7 +283,7 @@  struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
 
 	return sg_table;
 }
-EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
+EXPORT_SYMBOL(dma_buf_map_attachment);
 
 /**
  * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might
@@ -304,7 +304,7 @@  void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
 	attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
 						direction);
 }
-EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
+EXPORT_SYMBOL(dma_buf_unmap_attachment);
 
 
 /**
@@ -332,7 +332,7 @@  int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
 
 	return ret;
 }
-EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
+EXPORT_SYMBOL(dma_buf_begin_cpu_access);
 
 /**
  * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the
@@ -354,7 +354,7 @@  void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
 	if (dmabuf->ops->end_cpu_access)
 		dmabuf->ops->end_cpu_access(dmabuf, start, len, direction);
 }
-EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
+EXPORT_SYMBOL(dma_buf_end_cpu_access);
 
 /**
  * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address
@@ -371,7 +371,7 @@  void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
 
 	return dmabuf->ops->kmap_atomic(dmabuf, page_num);
 }
-EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
+EXPORT_SYMBOL(dma_buf_kmap_atomic);
 
 /**
  * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
@@ -389,7 +389,7 @@  void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num,
 	if (dmabuf->ops->kunmap_atomic)
 		dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
 }
-EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
+EXPORT_SYMBOL(dma_buf_kunmap_atomic);
 
 /**
  * dma_buf_kmap - Map a page of the buffer object into kernel address space. The
@@ -406,7 +406,7 @@  void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
 
 	return dmabuf->ops->kmap(dmabuf, page_num);
 }
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
+EXPORT_SYMBOL(dma_buf_kmap);
 
 /**
  * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
@@ -424,7 +424,7 @@  void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
 	if (dmabuf->ops->kunmap)
 		dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
 }
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
+EXPORT_SYMBOL(dma_buf_kunmap);
 
 
 /**
@@ -466,7 +466,7 @@  int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 
 	return dmabuf->ops->mmap(dmabuf, vma);
 }
-EXPORT_SYMBOL_GPL(dma_buf_mmap);
+EXPORT_SYMBOL(dma_buf_mmap);
 
 /**
  * dma_buf_vmap - Create virtual mapping for the buffer object into kernel
@@ -487,7 +487,7 @@  void *dma_buf_vmap(struct dma_buf *dmabuf)
 		return dmabuf->ops->vmap(dmabuf);
 	return NULL;
 }
-EXPORT_SYMBOL_GPL(dma_buf_vmap);
+EXPORT_SYMBOL(dma_buf_vmap);
 
 /**
  * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
@@ -502,4 +502,4 @@  void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 	if (dmabuf->ops->vunmap)
 		dmabuf->ops->vunmap(dmabuf, vaddr);
 }
-EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+EXPORT_SYMBOL(dma_buf_vunmap);