Home >> Linux >> Mono – Lost in Translation

Mono – Lost in Translation

Follow @LinuxUserMag

Making a success of Mono as a key element in the free software development stack was always going to be an uphill task, given Mono’s origins as an explicitly Microsoft technology. Mono was a free software implementation of the .NET framework, which the developers, led by Miguel de Icaza, hoped to take to the heart of the free software ecosystem as the tool of choice for the rapid development of applications for GNOME.

.NET had been Microsoft’s response to the success of Java. As such, it shared some objectives with Java and was a tool for developing web-related technologies. But there were signifi cant differences. Java was the ‘write once, run everywhere’ solution to the problem of interoperability. .NET had no such aims, and was specific to Windows, but gave programmers the ability to write applications in a variety of languages to a single Common Language Runtime (CLR), which was something akin to the Java Virtual Machine (JVM).

Between the language and the user

The Common Language Runtime took away the responsibility for the more menial tasks from the programmer, and made it easier to write lean applications. The CLR element of .NET was designed to nullify the problems Microsoft had encountered with its own APIs, which had “made the (Windows) platform horrible.” As Miguel de Icaza noted, “Microsoft has terrible APIs to code against. Anyone who has used Win32 and any combination of the various layered cakes that have been built on top of it has stuck to that platform only because of the size of the market, but it is one of the most horrible APIs ever built.”

The CLR “injected fresh air” into the Windows platform “by building and designing a new programming platform that addresses all these pains.” De Icaza hoped that Mono would solve similar issues for the developers of GNOME, where “libraries have been built by disconnected groups (PNG, JPEG, GTK+, XML, Bonobo, CORBA spec APIs etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.” The simple theory was that a programmer could achieve fast and predictable outcomes by writing against the Common Language Runtime.

As De Icaza pointed out, “The CIL (or Common Intermediate Language) has one feature not found in Java: byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to
Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix.”

The CLR wasn’t a new idea. An earlier manifestation, sometimes quoted by de Icaza, was ANDF (the Architecture
Neutral Distribution Format), developed by the UK Royal Signals Research Establishment as a binary standard format
for UNIX applications. It gave a means by which applications could be stored and distributed in a format, the ANDF format, which an ANDF translator would transform into native machine code on the host machine. The ANDF translator
could be seen as a precursor of the Java Virtual Machine and the translation process was roughly equivalent to just-in-time compilation.

Nothing but Java

From de Icaza’s perspective, the objective of Mono was not so much to achieve compatibility with Microsoft but to use the CLR as an enabler for the development of distribution- and language-neutral Linux desktop applications. De Icaza’s argument was that Mono, the CLR and the .NET framework were “the fastest way we can get stuff out there.”

“.NET is nothing but Java,” said de Icaza. “They just happened to learn the mistakes from Java and build things they couldn’t do with Java because it was set in stone. GNU was based on a proprietary technology [UNIX]. Think of Mono
as following the same process: we are bringing the best technology out there to our beloved free software platform.”

The complication was that de Icaza saw the CLR as a means of writing applications for GNOME, without much relevance
to Microsoft’s project for world domination, and others couldn’t see it that way. Although Mono is based on a published standard and is a clean implementation of specifications that Microsoft had, for the most part, put in the public domain, the doubts remained.

Visual Basic for Linux

Mono and the alternative free software clone DotGNU were deliberate attempts to offer open alternatives to .NET, independent of proprietary interests. C# and Asp.NET developers could jump straight from Windows to Linux, or vice versa, and applications developed for Windows could be migrated to Linux more or less seamlessly. Mono allows you to program in Visual Basic on Linux and run your applications on Windows, or develop in C# on Windows and run your applications on Linux.

De Icaza’s enthusiasms for Microsoft technologies were not widely shared. He once said of Silverlight 4: “I think I speak for the whole Mono team when I say that this is exciting, fascinating, challenging and feels like we just drank a huge energy boost drink.” Writing Visual Basic for Linux is not an ambition for many developers, and duplicating Microsoft technologies (where the fi rm allows you to) is not often the motivation for becoming involved with free and open source software.

Mono did serve one useful purpose, which was to allow access to Microsoft technologies for migration and interoperability purposes, but the Mono developers wanted a world where Mono was the base technology for developing applications for the desktop. The ability to “join forces with Windows/Mac OS developers to create the next generation of desktop applications” is only useful if the underlying technologies are free and open, and are likely to remain free and open.

Nonetheless, Mono fulfils a useful role for Windows developers and applications, providing an easy route for the migration of commercially developed Asp.NET and other software applications from Windows Server to Linux, and allowing .NET developers to migrate seamlessly from Windows to Linux. And MonoTouch has evidently found a successful niche as a tool for developing cross-platform mobile apps that will run on iOS and Android.

Owned by Microsoft

Mono isn’t the only free software project to have been based on Microsoft technologies. Samba, which implements Microsoft’s SMB/CIF protocols, could provided some useful lessons. Jeremy Allison once recounted that Microsoft was helpful to the Samba project as long as Samba was seen as an ally in its aim of overturning the market share of NetWare, but “once NetWare was defeated by Windows NT, their attitudes changed, and the fl ow of information stopped. Proprietary modifi cations to core protocols like the Kerberos authentication protocol followed, and these changes were treated as trade secrets, patented if possible, and only released under restrictive non-disclosure agreements, if released at all.”

Much later down the road, the Samba Team managed to forge an agreement between the Protocol Freedom Information Foundation (PFIF) and Microsoft which gave the Samba developers the right to access and use the SMB/CIF protocols. This agreement stands in stark contrast to the confusion and ambivalence that surrounded Microsoft’s patent indemnity agreement with Novell and the ‘IP’ issues surrounding .NET and Mono.

Microsoft gave a certain level of encouragement to Mono in the knowledge that the project helped to spread the word and bring developers into the Microsoft fold. It is also true that many individuals within Microsoft had a genuine interest in promoting the idea of ‘open source’, usually with strings attached, and Mono gave credibility to Microsoft’s claim that its technologies were multi-platform, accessible to free software developers and a ‘part of the open web’.

But Microsoft always held back on a full commitment to patent neutrality and the possibility was always open that some aspect of Mono might be patent encumbered. Some elements of Mono were covered by ECMA. Some were not. Even where de Icaza did manage to forge an agreement with Microsoft such as its ‘Covenant to End-Users of Moonlight’, the language was ambivalent and open to reinterpretation.

As Tom ‘spot’ Callaway, Fedora’s engineering manager noted, the ‘covenant’ was “specifically worded to apply only to end-users, and makes the following noteworthy distinction: ‘an entity or individual cannot qualify both as an End User and a Distributor for use of the same copy of a Moonlight Implementation.’ It grants no patent rights to Distributors, aside from those already granted to Novell in the previous covenant. What it practically means is that once you distribute, you stop being considered an ‘End User’ by Microsoft, and are no longer protected by this ‘covenant’ (unless you’re Novell or Microsoft).” The covenant reserved the right for Microsoft to discontinue the agreement at any time, and didn’t allow the use of “GPLv3 or a similar licence”.

Most computer users don’t care about the origins of the software they use, but this has never been the case with Linux users and developers. Richard Stallman expressed the opinion of many when he wrote: “I have always supported the development of free platforms for C#, just as I’ve supported the development of free platforms for any language that users use. I also wouldn’t argue that people should not use C# with a free platform for secondary applications… However, making GNOME depend on Mono is running a grave risk, and [is] a grave mistake.”

The shame is that the idea of a Common Language Runtime hasn’t been taken up as a realistic free software project, independent of the .NET or Mono implementation.

Follow @LinuxUserMag

Leave a Reply

Your email address will not be published. Required fields are marked *