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.

While it is true that technological means for mass communication intercept has grown with incremental improvements in communication technology, the means to apply and use encryption techniques to counter these abuses and offer communication privacy on a large scale using free software have also become possible. Given the nature of this project, important work had been done by volunteers and contributors in Europe such as Werner Dittmann who created the ZRTP compliant stack we use, over the summer of 2006, and Federico Pouzols, who re-wrote the RTP stack I originally authored for use in GNU Bayonne. The use of non-US contributors was specifically encouraged to avoid putting additional people in potential danger in the United States for working on cryptographic systems for worldwide public use specifically to avoid communication intercept.

One result of the initiative was creation of the GNU ZRTP stack (and our related GNU ZRTP4J now used in SIP communicator). The project was first publicly introduced in October 2006 during the 4th International Free Knowledge conference, where a complete ZRTP enabled client (the Twinkle softphone) became immediately available for use by anyone through Debian GNU/Linux for establishing simple secure point to point VoIP calls over the public Internet. This offered a basic means of establishing secure calls using Phil Zimmerman’s ZRTP protocol and a free software licensed implementation, but did not offer a means to truly integrate and manage secure calling or make it a standard or easy to deploy Internet user service.

This latter goal became possible through the development of GNU SIP Witch, which can be used to create and deploy network scalable secure privacy enabling VoIP solutions for individuals, private organizations, and even national governments. My focus in this project over the past year has been on this recently introduced GNU SIP Witch package. While this package is still rather new, there is a basic howto for system admins to use and deploy GNU SIP Witch with Ubuntu GNU/Linux. Ideally I would like to do far more to make it easier to deploy secure calling networks without requiring system admin skills.

GNU SIP Witch is different from many other VoIP servers, such as for example Asterisk, in that it never establishes media connections with or through a server, and hence does no protocol conversion or media operations that would otherwise require decrypting a secure audio session in a central location. Instead it relies on published open standards and the SIP protocol to coordinate secure endpoints which can then form direct peer to peer media connections. This means these media sessions are not decrypted by a central server, nor are encryption keys shared with or managed by a central server.

One use case for GNU SIP Witch is as a kind distributed domain service to handle inbound VoIP calls directly received over the public Internet for the SIP protocol much like something like sendmail does for SMTP. In this role, one could then create local publicly reachable SIP identities (URI’s) that match email addresses and thereby offer a consistent means of contact. This eliminates the need for some kind of centralized “registry” of callable users which so many other schemes and services wish to reply upon since we can make use of DNS and individually ran services. This suggests an alternate and much more distributed model for enabling secure public voice, video, and instant messaging contact to that of Skype, the latter of which requires a central user directory and control point, as well as using source secret protocols and methods which cannot be independently validated.

Another interesting use case is that of creating a secure calling “domain” in conjunction with an already existing insecure VoIP infrastructure, such as for example might be offered by Asterisk. Used this way SIP Witch will maintain both a secure and “insecure” identity for each ZRTP enabled node it is used to manage. The insecure identity will be cross-registered to the insecure IP-PBX so insecure users can reach users in the secure domain. Similarly, all non-secure destinations dialing from a secure VoIP user agent are automatically routed through the insecure IP-PBX. Dialing a secure destination from a secure user agent will however bypass the insecure IP-PBX entirely, and establish a direct peer to peer media session.

Awhile back I was asked about speaking at LinuxCon 2009 about this project, and now I am ready to do so. Given my topic, I am uncertain as to whether LinuxCon is really ready for me. However there is a preliminary copy of my presentation next month now available at http://www.gnutelephony.org/data/linuxcon2009.odp and http://www.gnutelephony.org/data/linuxcon2009.pdf for those curious about my talk next month.

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.