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

[Jordi Gutiérrez Hermoso]

On 26 November 2012 04:37, Francesco Potortì <address@hidden> 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.