octave-dev

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Juan P. C. <car...@if...>]

On Sun, Nov 25, 2012 at 11:48 PM, Julien Salort <li...@ju...> wrote:
> Sergei Steshenko <ser...@ya...>
> writes:
>
>> I am wondering what is more amusing:
>>
>> 1) a puppy or a kitten trying to catch its own tail;
>> 2) a cat chasing laser pointer light spot on a wall or a floor;
>> 3) GPL proponents shooting themselves in the foot.
>
> I'm not very amused personally. I was wrong to think that Octave was a
> good choice for instrument control. I wanted something free because I
> didn't want to rely on restricted licenses for my experimental setups:
> what happens if the network gets down ? No license server, no instrument
> control anymore. That seemed unacceptable to me. That's why I've been
> advocating for Octave to several colleagues.
>
> Now I have a bunch of Octave-only code that I can't share with
> anyone. If I had chosen Matlab in the first place, I would be able to
> publish the code without restriction. This is very paradoxical and I had
> not anticipated this problem. I must admit that I should have read
> Octave license carefully in the first place. But I wrongly thought that
> careful reading of licenses was only necessary when using proprietary
> software, because the GPL was meant to protect me, as a user. And I was
> happy with publishing my own code under GPL too.
>
> Now I realise that I would not have had problem if I had gone with
> Python instead of Octave.  I understand why they have a GPL-phobia now.
>
> But I have several experimental setups that have been tuned with Octave
> scripts and switching to Matlab or Python will be too huge a work.
> So I'll have to stick with Octave, but with no possibility of sharing
> my code publicly.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Julien,

Jordi said it is a violation to GPl, but is the matter truly solved? I
see no answer regarding the example I sent to RMS. Maybe adding the
compiler directives may solve the problem. Lets wait to that answer.

Also, the fobia is unjustified, since it is an artifact created by the
existence of non-free licenses. The idea is that we do not want o
violate GPL to prevent the proliferation of non-free software.
Otehrwise, as oyu just said, the existence of the non-free software
makes the life hard for people trying to free software!

It is only the "practical" posture, not considering the ethical
aspects, that makes some people exasperated about free licenses. If
you believe in free software, then rally your courage and hold
together till the storm passes. This is maybe similar to people saying
that military research is good for everyone, just because they
willingly ignore the fact that their contributions will eventually
kill humans.

Btw, how is the situation with the comedi drivers? Did they also used
proprietary software, I think not! Can you double check?
http://comedi.org/
Please let us know what you find in a different thread (maybe subject Comedi)
Thank you.

JPi






-- 
Dr. sc. nat. Juan Pablo Carbajal
-----
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Jordi G. H. <jo...@oc...>]

On 25 November 2012 17:48, Julien Salort <li...@ju...> wrote:
> I'm not very amused personally. I was wrong to think that Octave was a
> good choice for instrument control. I wanted something free because I
> didn't want to rely on restricted licenses for my experimental setups:
> what happens if the network gets down ? No license server, no instrument
> control anymore. That seemed unacceptable to me. That's why I've been
> advocating for Octave to several colleagues.
>
> Now I have a bunch of Octave-only code that I can't share with
> anyone. If I had chosen Matlab in the first place, I would be able to
> publish the code without restriction. This is very paradoxical and I had
> not anticipated this problem.

The problem isn't Octave. It's the license of the non-free libraries
it's linking to. Matlab's license is even more restrictive and I
imagine they would also consider you linking to both libraries to be
worse. The GPL is far more permissive than Matlab's license, so I
imagine Matlab's EULA would also pose the same problem. If not, I
would be happy to be proven wrong and be pointed to the clause in the
Matlab EULA that allows you to make derivative work of both Matlab and
the non-free libraries you're linking to.

I agree that not being allowed to share your work seems problematic,
and I am not happy about this either. I am much less happy with how
you are forced to use non-free software to communicate with your
hardware. You shouldn't be unhappy with Octave. You should be unhappy
with the hardware manufacturers who won't let you freely use the
software for the hardware you've already bought.

- Jordi G. H.

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Francesco P. <Po...@is...>]

Julien Salort:
>> Now I have a bunch of Octave-only code that I can't share with
>> anyone. If I had chosen Matlab in the first place, I would be able to
>> publish the code without restriction. This is very paradoxical and I had
>> not anticipated this problem.

Jordi Gutiérrez Hermoso:
>The problem isn't Octave. It's the license of the non-free libraries
>it's linking to. Matlab's license is even more restrictive and I
>imagine they would also consider you linking to both libraries to be
>worse. The GPL is far more permissive than Matlab's license, so I
>imagine Matlab's EULA would also pose the same problem. 

I definitely think not.  I can't imagine the Matlab lawyers ask anyone
to unpublish code that allows Matlab to link with instrumentation.  That
would be against their own interest.

This is a real problem for Octave.  If really it is not currently
possible to publish a wrapper that allows Octave to call an external
instrumentation routine, then adding an exception to the Octave licence
should be considered.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.315.3058 (op.2111)
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(entrance 20, 1st floor, room C71)     Web:    http://fly.isti.cnr.it

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Jordi G. H. <jo...@oc...>]

On 26 November 2012 04:37, Francesco Potortì <Po...@is...> wrote:
> Julien Salort:
>>> Now I have a bunch of Octave-only code that I can't share with
>>> anyone. If I had chosen Matlab in the first place, I would be able to
>>> publish the code without restriction. This is very paradoxical and I had
>>> not anticipated this problem.
>
> Jordi Gutiérrez Hermoso:
>>The problem isn't Octave. It's the license of the non-free libraries
>>it's linking to. Matlab's license is even more restrictive and I
>>imagine they would also consider you linking to both libraries to be
>>worse. The GPL is far more permissive than Matlab's license, so I
>>imagine Matlab's EULA would also pose the same problem.
>
> I definitely think not.  I can't imagine the Matlab lawyers ask anyone
> to unpublish code that allows Matlab to link with instrumentation.  That
> would be against their own interest.

The Matlab license is routinely violated and the Mathworks lawyers
selectively enforce it. Consider all of the students learning Matlab
worldwide and their primary method for acquiring it. Stating the the
GPL is more restrictive than the Matlab license might only be true if
you consider how seldom the Matlab EULA is enforced. I have seen far
more violations of the Matlab license in the wild than of Octave's
GPL, e.g. people modifying Matlab's m-files and publishing them or
distributing Matlab's Compile Runtime without permission.

This is a common tactic with non-free software: make the license terms
so restrictive, vague, and difficult to understand that almost anyone
has violated them at least in some small way. Thus anyone can be
pressured whenever there is need. We have a GPL FAQ that attempts to
clarify its terms. Where is the Matlab EULA FAQ, or even the license
text itself? They instead confuse, obfuscate, and selectively enforce
as suits their need.

> This is a real problem for Octave.  If really it is not currently
> possible to publish a wrapper that allows Octave to call an external
> instrumentation routine, then adding an exception to the Octave licence
> should be considered.

We can't change Octave's license, not without much effort. We don't do
copyright assignments, and even if we did, we have a number of
contributors who are dead. We would have to remove their contributions
if we wanted to change Octave's license.

This is a problem for Octave in the same way that the nVidia blob is a
problem for Linux users. If Linus wants nVidia to fuck off so badly,
why doesn't he enforce Linux's copyleft? You would quickly see nVidia
dancing to another tune if all of its Linux users couldn't use its
binary blob.

I am not sure much more can be done for our case than to pressure the
hardware companies to release free libraries or specs for
communicating with their hardware. Julien can still use his library
privately and Octave in the meantime has a free instrument control
package implemented by Andrius Sutas. It is unfortunate that Julien
can't share his code with us, but the GPL is not to blame here. Why
are the hardware manufacturers not allowing Julien to use his hardware
*and* software however he pleases?

I will nevertheless consult with the FSF and GNU; perhaps there is
another solution I have not seen here.

- Jordi G. H.

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Jordi G. H. <jo...@oc...>]

Removing maintainers and help from this thread; until the lists are
merged, this is purely something that interests the OF packages.

On 27 November 2012 10:09, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:

> "Ivan.Cousins" wrote:

>> For those wanting an open source (GNU) alternative to NI closed
>> source code here is a VXI11 set of source code by Steve D.
>> Sharples. The linux package can be compiled on Cygwin/Windows.
>> Hopefully this can be of use to someone.
>
> Did you read the start of this thread?
>
> As you can see at
> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh

> I use this package for my octave VXI11 toolbox.

Is this exclusively the only package you use? Does your code link to
non-free libraries? If it does link to non-free libraries, please take
it down, as this is a GPL violation.

On 27 November 2012 10:17, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
>
> Jordi Gutiérrez Hermoso wrote:
>>> Some years ago I already posted my toolbox for serial, tcp, gpib
>>> (and visa) to this list. Meanwhile I have added VXI11 and USBTMC.
>>> National Instruments GPIBENET-100 support is started, but even more
>>> incomplete than the rest of the toolbox. However, basic I/O is
>>> working and I'm able to talk with all of my instruments.
>>
>> It would be more useful if you could add your code to the existing
>> instrument-control package in OF and merge your instrument-control
>> with the one that Andrius Sutas wrote for SOCIS.
>>
>> Do you have the time and interest to do so?
>
> I have ported the TCP and USBTMC part. Could you take a look,
> please?

Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
to judge this contribution. I am CC'ing them here.

As an aside, it's not "GNU/Octave". There should be no slash there.
The slash in "GNU/Linux" is meant to indicate that the operating
system is a combination of GNU with the Linux kernel. "GNU Octave"
isn't an operating system of which Octave is a kernel; it is merely a
GNU package.

- Jordi G. H.

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

>>> For those wanting an open source (GNU) alternative to NI closed
>>> source code here is a VXI11 set of source code by Steve D.
>>> Sharples. The linux package can be compiled on Cygwin/Windows.
>>> Hopefully this can be of use to someone.
>>
>> Did you read the start of this thread?
>>
>> As you can see at
>>
>> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh
>> 
>> I use this package for my octave VXI11 toolbox.
> 
> Is this exclusively the only package you use? Does your code link to
> non-free libraries? If it does link to non-free libraries, please take
> it down, as this is a GPL violation.
>

vxi11_tb uses source code from Steve D. Sharples VXI11 library. Except of vxi11.x (which has it's own open source license) all GPL.

gpib_tb uses linux-gpib (GPLv2)

usbtmc_tb and tcp_tb uses libc

dummy visa_tb uses openvisa (GPLv2)


>>> It would be more useful if you could add your code to the existing
>>> instrument-control package in OF and merge your instrument-control
>>> with the one that Andrius Sutas wrote for SOCIS.
>>>
>>> Do you have the time and interest to do so?
>>
>> I have ported the TCP and USBTMC part. Could you take a look,
>> please?
> 
> Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
> to judge this contribution. I am CC'ing them here.

OK

> As an aside, it's not "GNU/Octave". There should be no slash there.
> The slash in "GNU/Linux" is meant to indicate that the operating
> system is a combination of GNU with the Linux kernel. "GNU Octave"
> isn't an operating system of which Octave is a kernel; it is merely a
> GNU package.

done

Re: [OctDev] low level I/O (GPIB, USBTMC, VXI11)

[Juan P. C. <aju...@gm...>]

On Tue, Nov 27, 2012 at 4:47 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
>>>> For those wanting an open source (GNU) alternative to NI closed
>>>> source code here is a VXI11 set of source code by Steve D.
>>>> Sharples. The linux package can be compiled on Cygwin/Windows.
>>>> Hopefully this can be of use to someone.
>>>
>>> Did you read the start of this thread?
>>>
>>> As you can see at
>>>
>>> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh
>>>
>>> I use this package for my octave VXI11 toolbox.
>>
>> Is this exclusively the only package you use? Does your code link to
>> non-free libraries? If it does link to non-free libraries, please take
>> it down, as this is a GPL violation.
>>
>
> vxi11_tb uses source code from Steve D. Sharples VXI11 library. Except of vxi11.x (which has it's own open source license) all GPL.
>
> gpib_tb uses linux-gpib (GPLv2)
>
> usbtmc_tb and tcp_tb uses libc
>
> dummy visa_tb uses openvisa (GPLv2)
>
>
>>>> It would be more useful if you could add your code to the existing
>>>> instrument-control package in OF and merge your instrument-control
>>>> with the one that Andrius Sutas wrote for SOCIS.
>>>>
>>>> Do you have the time and interest to do so?
>>>
>>> I have ported the TCP and USBTMC part. Could you take a look,
>>> please?
>>
>> Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
>> to judge this contribution. I am CC'ing them here.
>
> OK
>
>> As an aside, it's not "GNU/Octave". There should be no slash there.
>> The slash in "GNU/Linux" is meant to indicate that the operating
>> system is a combination of GNU with the Linux kernel. "GNU Octave"
>> isn't an operating system of which Octave is a kernel; it is merely a
>> GNU package.
>
> done
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

I moved this thread to "[PKG] Instrument control: GPIB, USBTMC, VXI11"