Re: Question about the criteria for a library to be in contrib
Michael Wild them...@gmail.com writes: On 04/05/2011 03:23 AM, Hendrik Weimer wrote: Michael Wild them...@gmail.com writes: I find this hard to believe, since the package only uses the free and publicly available API defined by the Khronos group and it is up to the user of the package against which implementation of OpenCL he wishes to link. How is this different from Java before OpenJDK was released? I think it is different because the package will only contain source code. It hasn't been processed by or linked against any proprietary, non-free software. Of course, one could argue that it is implicitly tied to non-free software since there is currently no alternative. So, for me, this is kind of a conundrum :-) The question is whether one can use ViennaCL without an OpenCL implementation. If not, then the ViennaCL package must depend on an OpenCL package, no matter whether it is source code only or not. BTW, there is a free implementation of OpenCL in the works in Mesa, called Clover [1]. However, I'm not sure how far along it is and how active it is, the last commit is from late November, last year. If Clover gets packaged and you can use ViennaCL with it, I see no problem for the latter to go into main. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zko43l36@mid.gienah.enyo.de
Re: Question about the criteria for a library to be in contrib
On 04/05/2011 03:05 PM, Hendrik Weimer wrote: Michael Wild them...@gmail.com writes: On 04/05/2011 03:23 AM, Hendrik Weimer wrote: Michael Wild them...@gmail.com writes: I find this hard to believe, since the package only uses the free and publicly available API defined by the Khronos group and it is up to the user of the package against which implementation of OpenCL he wishes to link. How is this different from Java before OpenJDK was released? I think it is different because the package will only contain source code. It hasn't been processed by or linked against any proprietary, non-free software. Of course, one could argue that it is implicitly tied to non-free software since there is currently no alternative. So, for me, this is kind of a conundrum :-) The question is whether one can use ViennaCL without an OpenCL implementation. If not, then the ViennaCL package must depend on an OpenCL package, no matter whether it is source code only or not. BTW, there is a free implementation of OpenCL in the works in Mesa, called Clover [1]. However, I'm not sure how far along it is and how active it is, the last commit is from late November, last year. If Clover gets packaged and you can use ViennaCL with it, I see no problem for the latter to go into main. Hendrik So, this means that ViennaCL must Depends: on some OpenCL implementation. Currently the only one packaged in Debian (still in experimental) I can find is the one from NVIDIA. So, this probably means then that it really has to go into contrib, right? Reading the ITP for the OpenCL headers [1] also confirms this. Thanks for the help Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598477 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9b1947.60...@gmail.com
Re: Question about the criteria for a library to be in contrib
Michael Wild them...@gmail.com writes: So, this means that ViennaCL must Depends: on some OpenCL implementation. Currently the only one packaged in Debian (still in experimental) I can find is the one from NVIDIA. So, this probably means then that it really has to go into contrib, right? Unfortunately, yes. It is really sad that there is currently no usable free GPGPU solution available. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcys3ixt@mid.gienah.enyo.de
