Microsoft changed IronPython, IronRuby and DLR licenses to Apache 2 (ironpython.codeplex.com)
Previously they were released with the Microsoft Permissive License.
http://ironpython.codeplex.com/license
http://ironruby.codeplex.com/license
http://dlr.codeplex.com/license
22 comments
[ 1.8 ms ] story [ 48.9 ms ] threadAnd, about motivations, I will not trust Microsoft. They are constantly threatening Linux users with patent suits and forcing them to license undisclosed technologies, maintaining an atmosphere of legal uncertainty. Why would anyone want to use tools that are vulnerable to such attacks?
Given all that background, it makes sense for people to be cautious -- though not unremittingly and unthinkingly hostile -- regarding Microsoft.
Now, for me, if I was developing on the CLR, I would very much consider using IronPython. Though having said that, I wouldn't consider developing for the CLR, because it isn't open source and doesn't run on Linux. Instead I might use the JVM, which seems to be acquiring a good ecosystem of languages (Groovy, Clojure) and tools (ANTLR, various IDEs) that run on it.
Instead MS though their dominance of the PC space meant they could relax and didn't need to develop good products. And now Apple is eating their lunch.
I find it very sad that very nice tools like IronPython, IronRuby and the whole CLR stack have such threats associated with them. I would love to use them, but I find it risky and I do not enter any course of action that may empower Microsoft against the FLOSS community.
http://www.mail-archive.com/users@lists.ironpython.com/msg11...
It seems like a public image choice more than anything, even though "Microsoft Public License" was an OSI-approved license it still carries the dreaded M-word. Plus people are more familiar with the Apache license.
Someone in the thread also commented that Apache License 2.0 is designed to be GPLv3-compatible whereas MPL was less clear on GPL compatibility.
Yes, that's true. But I'm curious: How would open-sourcing their implementation of the language (and not just the specification) help in making its use more wide-spread? (Especially when the compiler is already available at no-cost to those who want it, and for those interested in extending an existing compiler for their own internal use, the Mono source is available)
I guess one possible answer might be that Microsoft's specific compiler implementation may actually diverge from the standard submitted to ECMA (this is actually the case on some edge cases in the language dealing with type casting where they found that what their compiler implements doesn't follow the standard exactly)
What are the other reasons?
On March 27 they've published a working draft for the CLI specifications (ECMA 335) ... http://mono-project.com/ECMA-335-CLI-Public-Draft
I don't know what went in, since .NET 3.5/4.0 haven't suffered major CLR changes.
Also, ECMA 334 which covers the C# language hasn't been updated since June 2006, so it doesn't cover C# 3.5 or 4.0.
And even then, I would be cautious.