Re: CUDA/OpenCL version of Octave for GPGPU?

[Jordi Gutiérrez Hermoso]

On 16 June 2011 10:47, Michael Poole <address@hidden> wrote:
> On Thu, Jun 16, 2011 at 11:14 AM, John Swensen wrote:
>>
>> On Jun 16, 2011, at 10:23 AM, John W. Eaton wrote:
>>
>>> On 17-Mar-2011, Tim Rueth wrote:
>>>
>>> | Have there been any thoughts about a CUDA/OpenCL version of Octave (on 
>>> Windows)
>>> | that can run on a GPGPU?
>>>
>>> Is there a complete free software implementation of CUDA libraries
>>> that is distributed under terms that are compatible with the GPL?
>>>
>>> jwe
>>
>> I have often seen this question come up when discussing
>> CUDA/OpenCL. My question is whether it is against the spirit or
>> the letter of the law for a GPL program to link against a non-free
>> shared library?

The FSF's legal opinion, so far unchallenged, is that linking of any
sort and distributing non-free software linked to GPLed software
violates the letter of the law of the GPL. This opinion hinges on
interpreting linking as a derived work, thus covered by copyright law.

>> Doesn't essentially every Linux computer that runs X11 and uses the
>> NVidia provided driver do this exact thing?

No. The nvidia blob also provides a Linux module that in turn loads
the blob. While the FSF's legal opinion is that linking copyleft
software to proprietary modules violates the GPL (such as a Linux
module), it's a grey area whether nvidia's usage also does. It hinges
if a judge considers that the blob is a derivative work of Linux or
not. In my opinion, this certainly violates the spirit of the GPL, but
it would be up to Linux copyright holders to persecute this if they
wanted to do so and thought they had a good case. Since this hasn't
happened, perhaps this grey area is more on the white than black side
for them.

It is somewhat interesting that Linux emits the warning that using
blobs "taints the kernel". I've never quite understood what they mean
by that. Perhaps that you cannot distribute Linux together with a blob
because of this tainting.

I personally solve this grey area by not buying nvidia. I'm a happy
user of Intel graphics chipsets, and I will be as long as they don't
implement crippled hardware DRM in them like they did with Sandy Bridges.

> GPL'ed X clients use the same interface to talk to both open-source
> and proprietary X drivers (whether for 2D, OpenGL, or other things),
> so the GPL cannot reach across that interface.

In my opinion, thinking if the "GPL can reach across an interface" is
wrongheaded. The GPL isn't about interfaces, but about derived work.
You may be able to argue that something is a derived work of GPLed
software without mucking around with hair splitting if such and such
technology is exchanging bytes in such and such way. Copyright law
doesn't account for that level of detail about how a work is a derived
work.

Also, it would be nice if you called it free software instead of open
source (this is a GNU project mailing list we're talking in after all,
*GNU* Octave). Remind yourself that what matters is freedom, not
merely if you can see the source or not. The nvidia blob often has
bugs that we can't fix nor even understand, and we have to beg for
nvidia to do so instead. This is not freedom. We're at the mercy of
nvidia.

> OpenCL is a borderline case.  It has a standard interface for both API
> and ABI,

AIUI, OpenCL is only a specification like OpenGL, and any
implementation of it may or may not be free. Is there already a
standard implementation you're thinking of?

> but it probably does not fall under the GPL's "system library"
> exceptions on Linux on account of OpenCL libraries not being widely
> distributed with Linux distributions. (There are reasonable
> arguments that go both ways.) Ironically -- and unfortunately -- it
> is probably more legitimate to distribute an OpenCL-linked GPL'ed
> executable for Windows or Mac OS X than for any open source
> operating system.

The legitimacy of distributing non-free software isn't about legal
technicalities. It's simply illegitimate because it prevents us, the
users, from using, studying, and modifying the software to our needs.

- Jordi G. H.