Splitting Mono into EMCA and non-EMCA packages?

[GreyGeek]

One of the common claims of the Mono proponent is that distribution packagers are splitting Mono into ECMA and non-ECMA packages. Debian and/or Ubuntu are commonly held up as examples in this area.

Read the following article, which includes a very informative email by Jo Shields, who packages Mono for Debian and Ubuntu:
http://www.the-source.com/2010/12/on-mono-packaging/

Mr. Shields was kind enough to respond, and here’s the summarized deal:

1. ECMA/non-ECMA is not a consideration in packaging Mono.
2. No distribution ships Mono with ECMA-only components.
3. It is not possible to do so without “deep surgery”.
4. Splitting along ECMA/non-ECMA lines is not a priority.

So, we can reject the claim that distribution packagers are splitting Mono into ECMA/non-ECMA components.

I asked you kind folks to read that article in order to understand what I am about to write. Following Canonical's Technical Board statement that future desktop remixes of Ubuntu would be "dependent" on Mono, a debate raged about the risks involved. Pro-Mono people were claiming that Microsoft's promise not to sue for using Mono eliminated the risk. Others, like myself, stated the obvious: EMCA 334 covered only C# and EMCA 335 covered only the CLI. Microsoft's "Community Promise" is a promise not to sue for using technologies in those two standards and some other technology on their CP webpage. What is not included in the two EMCA standards or on the CP webpage are the patented technologies like ASP.NET, ADO.NET and Windows Forms.

The current claims is that "These technologies are today not fully implemented in Mono and not required for developing Mono-applications, they are simply there for developers and users who need full compatibility with the Windows system.". This assertion is patently wrong because "not fully" isn't defined. If they are included but not functional/useful then they are bloat. But, "full compatibility" implied full functionality. It can't be both ways.

But, it is even worse. The lead link points out something that most people were not aware of. When asked in 2004 about patented technology in Mono de Icaza replied:

The discussion quickly got steered into the patent problem. Miguel is very aware of the patent situation in US today and the dangers this [will] mean for Free and Open Source Software (F/OSS).
....
Regarding Mono and the Microsoft .NET patents, Ximian is now splitting the "non-free" parts of .NET in Mono, and so OS providers can decide if they want to include in their products the "non-free non-ECMA" portions or not. Apparently, even without the non-free portions, Mono is fully usable, complete with the GTK# bindings, database and other free parts.
...
Miguel explains: "If there is indeed a new technology that Microsoft holds a patent to and they do not explicitly allow us to use, we will remove that code, or rework the code in a way that does not infringe the patent. We do not like the current patent environment in the US, but we have to play by the rules."

Following Canonical's June 29, 2009 announcement de Icaza joyfully posted on his blog, 7 days later, that "First the big news: Microsoft will be applying the Community Promise patent licensing to both C# and the CLI. " and then he followed that up with

Astute readers will point out that Mono contains much more than the ECMA standards, and they will be correct.

In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + A lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, Winforms and others.

Depending on how you get Mono today, you might already have the this split in house or not.

De Icaza KNEW in 2004 that Mono contained patented technology and promised to "split the patented parts out". He made the same promise 5 years later, in 2009, so his promise in 2004 was insincere or quickly forgotten. So, following TWO separate promises of removing patented material from Mono, we now learn that not only has the Mono team NOT separated the non-ECMA standard items from the patented items, it is probably not possible to do so without destroying Mono. Jo Shields "deep surgery" would be so deep as to remove the patented items in mscorelib.dll. He states:

As far as I can tell, most people consider some technologies more dubious than others - System.Windows.Forms or System.Data is hairy, whereas a non-spec method on the String class doesn't make everybody leap in fear.
.....
So it's true that we have distinct packages for the "scary" bits like System.Data versus "less scary" stuff like mscorlib.dll, but it is absolutely true to say that no distribution ships a Mono framework with ECMA-only components, and it's not possible to do so without deep surgery on the class library, requiring a lot of man hours. Which is time Miguel would rather get his guys to invest in MonoDroid or MonoTouch.

I knew that GTK# was required by Mono for it to be able to create graphical user dialogs and windows, and I had heard that patented Windows.Forms technology had been included in Mono to allow it to create GUI without GTK# bindings, but I hadn't heard that the basic Mono library, libmono-corlib2.0-cil, contained a copy of Microsoft's mscorlib.dll, and that mscorlib.dll contained System.Drawing, System.Windows and System.Data, among other patented technologies. Libmono-corlib2.0-cil in the repository has this as part of its description:

This package contains the Core Library (mscorlib.dll) of Mono for CLI 2.0, which is the glue between the BCL (Base Class Libraries) and the JIT.

So, mscorlib.dll IS the "core library of Mono FOR CLI 2.0" and it contains System.Windows.Forms and other patented technology. But, the CLI is covered by ECMA 335. ECMA 335 does not include "mscorlib.dll" but it does include "mscoree.dll" and "mscoree_", which appear related to the runtime engine, not a GUI tool.

This raises some questions:
1) Who knew that libmono-corlib2.0-cil contained mscorelib.dll?
2) Who knew that mscorelib.dll contained the patented technology?
3) Since ECMA 335 does not appear to contain mscorelib.dll, who added it to the core Mono library, OR, is mscorelib.dll THE core of libmono-corlib2.0-cil and that libmono cannot function without mscorelib.dll and hence Mono cannot function without libmono?
4) Who knew mscorelib.dll was in libmono--corelib2.0-cil and still asserted that Mono was patent safe? Such a person is a liar and was aiding and abetting in a conspiracy of entrapment.
5) If someone asserted Mono was patent safe, or claimed no patented technology existed in Mono but was ignorant of mscorelib.dll being in libmono-corelib2.0-cil, will they continue to assert their ignorance?

My sig applies here: IF MS API becomes the default on the Linux desktop then what is the point of Linux?