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. --jh--