Related link: http://www.microsoft.com/downloads/details.aspx?FamilyID=94082d26-e689-4f7f-859b…
IronPython is a .NET implementation of Python, created by Jim Hugunin who is currently working for Microsoft. Jim didn’t specify a date when to expect 1.0 final, but he did mention that he’d prefer to keep it under 10 beta releases. As always, I’m happy to see the continued emphasis of CPython compatibility with this project. Microsoft takes a continual beating for “not playing nicely with others”, but I haven’t seen anything with the IronPython project that would lend itself to such criticism. I haven’t had a chance to install 1.0 yet. Maybe I’ll get to that next year…. :-)
Licensing: The elephant in the room
The last time I looked, the IronPython license made it extremely doubtful that a non-trivial IronPython app written to take advantage of many of the .NET platform's features would be legal to distribute under the GPL or any other copyleft license.
To me, that's an open-and-shut case for 'not playing well with others', at least for the values of 'playing well' and 'others' that I tend to use.
Licensing: The elephant in the room
You may have a point. I really can't say that I've researched their license to see how FePy could be used in GPL projects. However, what I was really meaning was "playing well with others" from an interoperability standpoint. One of their key focuses all along has been compatibility with CPython. And from reading the mailing list, I get the impression that they are at least communicating well with the Mono folks. While licensing is a huge issue, I think it's interesting to see prove some of my impressions of them wrong. At least it's a good start. I'll have to look into licensing though. It'd be interesting to see if they could really prevent a GPLed project from calling their libraries. That's almost like restricting GPL projects from Windows because those projects would be inadvertently calling system libraries. I'm not saying they haven't done it (or at least tried). I'm just saying that it'd be interesting to see how that would stand up in court.
Licensing: The elephant in the room
IANAL, but I can't see anything in the license that looks like it would preclude distributing GPL software that uses Iron Python. You even have the right to re-distribute Iron Python itself, but only under it's own license. That doesn't necesserily stop your software from having a GPL license, or any other form of license though.
Simon Hibbs
Licensing: The elephant in the room
I think you need to reread the license and if needed seek a professional opinion, since I don't see any problem.
Is there a specific section that leads you to this opinion?
Licensing: The elephant in the room
No, nothing that *directly* prohibits it, but the conversations I've had with folks at Microsoft have made it fairly clear that as far as their concerned, importing constitutes making a derivative work.
This has lead me to the conclusion that a GPL program that imports (ie. depends on) something from the .Net environment that is under a more restrictive license (and there is plenty of the .NET code that is) would not be legal to distribute.
So, while it's true that a GPL-licensed program written in generic python would be perfectly legal to distribute and run on IronPython, anything that was written to take advantage of .Net's features (which would only be accomplished by importing other MS code) would almost certainly *not* be legal to distribute under the GPL.
So, no GPL software written specifically for IronPython.
Licensing: The elephant in the room
Please see my reply to Simon Hibbs below.
Licensing: The elephant in the room
If .Net don't let you to distribute your software under GPL, then use mono. You can use IronPython to make freesoftware (GPL/LGPL/X11) perfectly.