If you don't want to be mistaken for a rabid OSS zealot, you should be more knowledgable about Mono's license(s) and not fling RMS-poo around.

http://www.mono-project.com/License

The fact that C# programmers can code for multiple platforms thru easier porting makes them more likely to explore OSS options instead of staying solely in Redmonds garden.

I see no patent grant that protects users, distributors, or non-Mono/Microsoft developers.

So, again, how does that license protect open source? It is neither GPLv3 or ASLv2, nor will Microsoft stop using patents to attack people.

I'm not sure how I can interpret it any other way. Being sued by Microsoft is something no one wants.

How is that different from any other OSS project? If MS wants, they could look at a projects source code and decide that they've violated a patent and sue them. To my knowledge they're yet to do this.

The difference is that Microsoft created .Net and the patents covering it together, so they're fairly narrow patents and it'd be a hell of a lot harder to find relevant prior art to use against them. (The same's true of OOXML, incidentally; Microsoft even tried to get a patent covering both it and ODF but the examiner narrowed it to just OOXML based on a huge amount of prior art dating back to SGML in the 80s.)

We don't own any patents on Mono, so licensing it under GPLv3 would not provide any additional patent protection to anyone.

That said, the code donated by Microsoft has been under Apache2 which does provide patent protection, just like GPLv3.

You are reading too much into events. MS likes Miguel because he brings some open source respectability to the NET platform. It is also a potential source of licensing revenue stream in the future. MS has no reason to want someone else's implementation of the CLR and VM.

Mono's VM executes C# bytecode faster than Microsoft's, and Mono's C# compiler produces better bytecode than Microsoft's.

So, yeah, Microsoft is very interested in trying to make their core product faster so they can catch up to other solutions such as native code (C/C++) or Java (C# is still typically much slower than Java).

Oh, and Mono can also compile to AoT binaries, which do not require Mono/.Net installed on the target system, such as being able to target iOS under Apple's anti-VM policy.

Microsoft is very interested in all of these.

Complete nonsense:

- Microsoft's CLR is vastly more sophisticated than Mono, involving millions of man-hours work, unless you show me a benchmark I have absolutely no reason to believe it executes bytecode faster, especially given that Microsoft Research publish papers on fast JIT [1].

- Mono still doesn't have a stable generational GC [2], I hope you like memory leaks and long pauses.

- .NET can compile AoT binaries, and does this for all built-in libraries using ngen [3]

In conclusion: Microsoft have no interest in any of Mono's technologies.

[1] http://research.microsoft.com/en-us/projects/spur/

[2] http://mono-project.com/Generational_GC

[3] http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).as...

Hey, Xamarin dev here...

Not that I want to defend Diablo-D3 (he's a troll), I do want to make a few slight corrections to your comment.

1. You are correct in that Microsoft's .NET VM performs better than Mono overall (at least in the general case), but Mono does perform better than .NET in some cases.

Unfortunately I don't have a list of the areas where Mono outperforms .NET handy, so I can't list them here. Perhaps one of the other Mono devs can follow up and provide details. Most likely SIMD would be on the list.

Whether Microsoft would be interested in taking Mono's implementation for these areas or not for their own VM is questionable. Likely not, as it would likely not be easily adaptable to their implementation anyway.

2. SGen is actually stable these days. It is used in Mono4Android and we are working on moving MonoTouch over to SGen as well.

Moonlight was also being moved to SGen (it started out using Boehm because that was the default GC when the project was started) when the Novell layoffs came along.

As responsible developers, we have been taking our time moving to SGen as the default GC because we don't want the move to break any existing apps if we can avoid it. As with all new things, there are still likely to be bugs here and there, but overall we feel that it is ready for use and we've been eating our own dog food.

3. As was mentioned in another comment already, Microsoft's AOT isn't quite the same as Mono's AOT which allows generation of binaries that do not require an external CLR to run.

Glad to here that SGen is stable now, of course turning it on by default in Mono is the true test of 'stable', but as you say it's reckless to break things needlessly.

There was once an entire company called Xenocode, founded by ex-MS devs, and built on the idea that it would be really useful to distribute .NET apps without the CLR. They had a tool which could do this, even with ngen'd assemblies. Turned out it wasn't so useful. They've now pivoted into enterprise application virtualisation, and their offering is similar to Softricity, which later became Microsoft App-V.

Distributing .NET apps w/o a CLR is probably the biggest strength of Mono - it's how Mono is able to work on iPhone, Wii and other devices which do not allow dynamic code generation.

I would say that Xenocode's failure wasn't so much that no one found .NET w/o a CLR useful, it was that they likely only supported Windows.

Oh well, Xenocode's loss is our gain :-)

Few things to notice here.

Mono's new gc is quite solid now. Mono for Android customers use it by default.

Yes, performance is not the best nor does it support a concurrent mode. But a garbage collector is one of those projects that is never done and always have an infinite amount of work left. Our gc has been improving a lot and the next release, for example, features a lot of scalability and performance work.

Said that, if you compare it to other gcs offered on mobile environment we're doing very well.

Mono features a much simpler JIT and runtime and this is a competitive advantage for us or do you think MS ships its desktop/server VM on winphone? We do, and it has teached us a lot about how been slim and simple makes you much more adaptable.

Now on the subject of AOT, mono features a much more sofisticated system than .net, it's the only one that supports running without a JIT while retaining generics.

BTW, I work for Xamarin but those are my personal opinions on the matter.

Ngen still requires the CLR to be present though.

Microsoft is very interested in AoT binaries that don't require a runtime installed? Microsoft has specifically said they have no plans to pursue this path, even though they could obviously do so. The reasons was that they didn't want to deal with patching all these programs that had the runtime embedded in them. I found that sort of a weak argument; they probably just wanted to get higher penetration numbers.

Have you even tried to submit a patch to Microsoft for one of their Microsoft Shared-Source projects (there is a list here: http://www.microsoft.com/resources/sharedsource/default.mspx ), ? It is near impossible to get MS to accept them. They will give away code, but paranoid about taking contributions.

> not only do they refuse, they are getting rid of all GPLv2 code in favor of BSD code.

This claim is completely fictitious.

We started an effort a few years ago to migrate MonoDevelop code to LGPL and MIT/X11 (not BSD) from GPL. Our reason for doing so was to make it possible for third parties to write extensions (addins) to MonoDevelop and license it under whatever license they wanted, i.e. we did not want to force them to have to develop their addins and license them under GPL if they didn't want to.

It was not some big conspiracy to prepare for some Microsoft takeover or anything.

could you pliz stop the bull*$#t ? thank you