[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] parallel
From: |
al davis |
Subject: |
Re: [Gnucap-devel] parallel |
Date: |
Thu, 6 Mar 2014 11:28:05 -0500 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
On Tuesday 04 March 2014, beranger six wrote:
> Regarding CUDA licensing, I refered to the FAQ
> #SystemLibraryException pointing to the section 1 of
> GNU/GPL3.
No. That is not what the system library exception is for.
To see what it is for, consider that we want a version of gnucap
that runs on MS-Windows and on Mac. To do that, we would use
the tools available there. Unfortunately, the system library
there is proprietary. But, it comes with the system, is always
there, and there is nothing we can do to change that.
In this case, the only practical way is to use it, hence the
system library exception. If you are building on MS-Windows,
it's ok to link to the library that they give you.
This does not apply to optional libraries or optional features.
Ideally, the free project would not need to do anything extra to
support what they call a standard library. Practically it
doesn't always work that way.
The standard C++ library is clearly a place where YOU could
apply the system library exception. WE don't need to do
anything.
There is a gray zone that includes how plugins are attached.
In this case we take the approach of minimum intrusion. The
standard code supports the free interface as provided in all GNU
systems. For others, provide wrappers to make the proprietary
way look like the free way. These wrappers must be kept
separate from the main code. In gnucap distributed code, all of
it is confined to md.h or additional files specifically for this
interface that can be removed when they don't apply. These
additional files must be arranged so that they don't get in the
way when they are not used. If someone might see it and ask
"what's that", that is too much intrusion.
> Based on that I assume we could distribute the software with
> CUDA code in it but without the actual library. Not
> considering here libraries based on CUDA i.e. Cublas.
No. Once linked it becomes a "combined work". When you have a
combined work, the license on it is also a combination. When
parts are licensed differently, for the combined work you must
comply with both licenses. If you cannot simultaneously comply
with both licenses, you cannot distribute the combined work at
all.
> To me, CUDA looks like one of the easiest way to work with
> GPGPUs since it provides debugging and performance analysis
> tools. CUDA would provide a good insight on what happens
> allowing me to detect issue before re-factoring the code
> using OpenCL. Which is more compliant with GPLv3 license.
As an experiment, go for it. But beware .. the proprietary
license may make it illegal for you to distribute your own code.