octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reading NI TDMS files


From: Michael Goffioul
Subject: Re: Reading NI TDMS files
Date: Wed, 19 Dec 2007 21:32:12 +0100

On 12/19/07, John W. Eaton <address@hidden> wrote:
> OK, I think you are misunderstanding my statement above.  I'm talking
> about a case where distribution does happen.  Whether the parts are
> distributed together or separately, the result is the same (they are
> distributed, and linked together, so the GPL does not permit it).
>
> But I think I see what the misunderstanding may be.  It seems that you
> are thinking of the case of the METIS library, and whether it is OK
> for you to link that with your copy of Octave in the privacy of your
> own organization.  I'm thinking of a case where someone writes a
> plug-in for Octave, specifically with the intent of linking to a
> proprietary module, that they would not be allowed to distribute if it
> were all (Octave, the plug-in, and the proprietary code) linked
> together, but they try to get around this by distributing them
> separately and expecting that the user link them together in the end.

I - personally - find this unfortunate as it indeed limits the area of
applications for octave. More specifically, it prevents anybody to
bridge octave with any GPL-incompatible software
(at least in the most efficient way, using oct-files). The first example
that comes to my mind (although I'm not an expert at all in that
area) is bridging octave with instrumentation softwares like LabView,
which are usually proprietary. But if the GPL is written like that,
just let it be...

I'm just happy that Sun released Java under GPL, otherwise my java
package would be a clear violation of the GPL license.

Moreover, shouldn't the packages located in the "nonfree" directory
of octave-forge be removed?

Michael.


reply via email to

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