Reading NI TDMS files

[David Bateman]

Michael Goffioul wrote:
> On 12/19/07, John W. Eaton <jwe at bevo.che.wisc.edu> 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.


Use a mex-file, then you can say it was for matlab and still link
against Octave (tongue in cheek).. Seriously, I think the fact that we
can use mex-files in Octave makes all of this argument moot..

D.