GNU Telephony

Until society can resolve what I will call for the first time the “Stallman Paradox”, where learning and access enabling technologies, such as for example digital books, conversely disables the freedom to read and hence more than negates the actual benefits of said access, the rush to embrace all digital libraries and textbooks is a rush to a new dark ages.

This is perhaps best exemplified in the case of Cushing Acedemy. In this place of assumed learning, the administration choose to abandon a library collection of some 10,000 books which any student may freely access and share for the presumed benefit of DRM (Digital Restriction Management) disabled e-book solutions including the Amazon Kindel. While it is true that the amount of material available is far greater potentially for students, however in doing so, this institution has also decided to accept that costs associated with DRM solutions will mean each student will only be able to afford and have access to a far smaller actual collection of material than they had access to before.

Furthermore, outside of the question of turning universal education to a monitary privilege that only few will be able to afford, DRM disabling solutions mean that the right to read and share and learn together is immeasurably harmed. This is perhaps best exemplified in Stallman’s essay on the “Right to Read”, and hence, along with a question of basic freedom of access to knowledge and basic human rights, why I propose this problem be called the “Stallman Paradox”.

The logical solution is one where the right to read and think, and to share knowledge, is not made into a good that only few will be able to experience. In the European dark age, education was an exclusive privilege enabled only for a very few. While most societies today now recognize that universal education is both a right and a need, the use of mandated digitally restricted e-book solutions for education could well return societies to a new dark age.

Richard Stallman, and others, have explained rather well important legal and social reasons for why clearly Mono should not become a default part of a Debian GNU/Linux install, or similarly used for core applications of the GNOME desktop. This is especially true I think in regard to the Debian social contract which is meant to assure that core packages are built from and use free (as in freedom) software, that is without encumbrances or surprises. The ECMA process allows for patent surprises even in the core language specification itself, which can be patent licensed under RAND terms. I happen to believe there are additional valid technical reasons for not including Mono as a core part Debian.

While some may be surprised I should speak so strongly on this topic, given my involvement with Debian and Ubuntu, I found it an ethical requirement to speak out about this, and especially given my past involvement in dotgnu, I have come to feel that the community is being deliberately mislead by some about the what I think the role of Mono probably should have been. While I can see why Mono can be an important tool for promoting and enabling cross-platform development, a role that has been neglected, I believe in fact for this very reason Mono applications should NOT be used to build core required applications or be part of the default install of a distribution, just as for example Java applications are not used to build default core Solaris specific applications for Solaris, or (shutter) Visual Basic was used to build default applications shipped with Microsoft Windows (I am assuming they never did that…).

Hence, I do not see Mono as particularly useful for developing GNU/Linux specific free software applications, but rather in better enabling legacy proprietary ISV’s to build cross-platform add-on/value add applications and migrate to the free world. In this role, there would then be pressure from these ISV’s, many of whom may participate in Microsoft development, to keep Mono/.NET honest and truly cross-platform compatible. When we use Mono to build core GNOME applications, such as Tomboy, Banshee, and Beagle, we remove this pressure, and encourage what should be a cross-platform technology to be used as a single platform one, making it easier for Mono and platform specific GNU/Linux free software written with it to be more effectively ghetto’d by Microsoft. The greater there is this dependency on Mono for core parts of the GNU/Linux platform, the greater the vulnerability to those risks Stallman outlines.

Furthermore, if only a few “core” applications require it, and there are alternative applications that do not, why drag a 40 or 50 meg dependency onto everyone? Mono dependency might well be enough to be the difference between a single live CD distribution or one that requires DVD media to fit. While Microsoft’s proprietary legacy platform is tied principally to Moore’s Law and desktop computing, GNU/Linux is not. GNU/Linux is a free software platform for current and next generation hardware such as smartbooks, and is platform agnostic. Just getting Mono to sorta run on ARM has been a major distraction that should not have been necessary in the first place.

I also think an important goal of a default core distribution should be a GNU/Linux experience that is both GNU/Linux specific (unique) and works well for users. If, as we see in tomboy vs gnote, or tracker vs beagle, there is such a large discrepancy in performance and resulting user experience, then I think clearly Mono is the wrong choice to make even for purely technical reasons alone.

Part of that user experience is a consistent packaging and operation within the rest of a GNU/Linux system. In this respect, I have read the Debian packaging policy for Mono applications, and it highlights the fact that fitting Mono on a Debian GNU/Linux system is actually more awkward than packaging Java for Debian. Essentially, it suggests one creates a /usr/lib/progrname directory, and fill it both with the applications libraries and executables, and then write a wrapper script for /usr/bin. This is because Mono carries certain policies and expectations one finds on Microsoft Windows, where applications and dependent libraries were often bundled together under a private directory because binaries were never shared between vendors. This wasteful inefficiency and inability to cooperate that is the hallmark of proprietary software practices creates to me a very unnatural packaging policy requirement for Debian.

I know of course this viewpoint is at odds also with at least some others that are involved in Debian and Ubuntu, but it represents what I do think and feel is the best course of action. I personally do not fear nor dis-favor Mono, I simply do not personally believe it belongs in a core or default install of Debian or Ubuntu GNU/Linux distribution, and should not be used to build critical or default applications for GNOME. Other use cases individual developers must separately consider, however putting free software platforms at risk of Microsoft extortion simply because certain individuals and Novell made a large investment in Mono is to me a very selfish motivation.

Of course at the time Mono first appeared, Java was not licensed as free software and there was uncertainly around it. That being said, I do of course feel more comfortable with the present licensing situation of Java than with that of Mono. However, I would not suggest, even on purely technical merits, writing core parts of GNOME in Java or requiring Java as a core part of any GNU/Linux distribution, just as strongly, and for many of the same reasons as I would not with respect to Mono either.

Finally, I recognize a lot of excellent work has been put in making Mono a viable technology, and I believe this work has it’s best chance to endure with it being far more clearly and honestly presented in the role of a cross-platform enablement technology. That also is the best way I see to reduce the risk of potential patent traps by Microsoft.