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(-)
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);
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
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
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
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
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
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
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:
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".
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.
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
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.
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
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
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.
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.
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.
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
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.
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
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.
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.
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
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.
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
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
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
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
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
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
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
linaro-mm-sig@lists.linaro.org
-
Alan Cox -
Dave Airlie -
Hans Verkuil -
Laurent Pinchart -
Maarten Lankhorst -
Mauro Carvalho Chehab -
Rob Clark -
Rob Clark -
Robert Morell