[SciPy-dev] implementing IDL, Matlab, etc. functionality

Joe Harrington jh at oobleck.astro.cornell.edu
Mon May 2 09:03:10 CDT 2005

Two of the big barriers to people converting from commercial
environments to SciPy are 1) their dependence on specific packages in
those languages (e.g., the fuzzy logic package in Matlab that was
recently mentioned, or the IDL Wavelet Toolkit), and 2) their
dependence on their own code, developed over the course of their
career.  There are legal issues we need to be aware of in coming up
with solutions.

There are two problems: first, to use IDL (and, I assume, Matlab), you
have to agree to a license that says you will not reverse engineer the
product.  The packages include a lot of routines in source form.  Most
users who are likely to write compatible packages in SciPy have looked
at these routines.  They thus have "tainted brains": the commercial
entity can claim that they have seen proprietary information, and that
they had to use this information to produce the Python package.
Second, Cornell's legal staff has informed me that there are two court
precedents that state that if you have *ever* used a product, and you
try to make something that works the same way, it's reverse
engineering.  I know that sounds ludicrous to everyone, it does to me,
but you may have to fight at the Federal Appeals level or above to be
sure.  Again, since users of IDL and Matlab have agreed to licenses
that prohibit reverse engineering, this would mean that any code
produced by such people would be tainted and we could be sued.  "We"
means us as individuals, our institutions (who employ us, pay us, and
might be construed as the licencees of IDL and Matlab), Enthought for
distributing it, etc.  Regardless of how crazy this interpretation
might sound, I doubt that we as a community have the financial
resources to mount an appeal.  There is also no shortage of crazy
legal interpretations that stick in current computer law, so there is
no guarrantee that we'd win.  One of the original plaintiffs was Sony,
which would surely weigh in with amicus briefs and perhaps financial
help to the plaintiff, since their IP would be at stake if their
precedent were turned over on our appeal.

I think there is a technical way out, however.  I have only agreed to
an IDL license.  Nothing says I can't implement something that works
like Matlab.  Reverse engineering is legal, at least in the great
state of New York, unless you sign that right away.  So, it makes some
sense to set up some trades: I can write a Matlab -> Python converter
if you'll do it for IDL.  All that's needed is for each side to
provide examples of code in the proprietary language that they have
written themselves, along with descriptions of what it does and sample
inputs and outputs.  That plus commercial books on the languages
should provide all the information we need.

For specific packages, it makes more sense for people to do them from
scratch or by wrapping existing open-source code.  For one thing, the
efforts of the commercial packages are usually old and almost always
procedural.  Much is to be gained implementing as a good OO design
based on the method descriptions in the literature and the particular
strengths of scipy.base.  Then, someone else who has not signed a
license can do workalike interfaces for the commercial packages.  The
benefit here is that IDL and Matlab are pretty backward languages,
whereas Python is quite modern.  Matlab users may benefit from
encountering a Matlab-compatible fuzzy logic interface, but IDL users
certainly don't.  It would be much better for them to learn the OO
interface.  The reverse is of course true for, say, IDL wavelets.

So, before anyone (else) goes diving into implementing something from
IDL, Matlab, etc., please give consideration to these issues.


More information about the Scipy-dev mailing list