On 26 November 2012 04:37, Francesco Potortì <poto...@isti.cnr.it> 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. ------------------------------------------------------------------------------ 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 Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
