gnucap-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]