GNU Telephony

“Information in the computer age is the last genuine free market left on earth except those free markets where indigenous people are still surviving” – Russell Means

Mitakuye Oyasin,
(to all my relations)

Today is a fine day, and while I have shared this elsewhere, I thought I would take the time to share this here. In many ways the struggle of the North American Indian remains to this day one to simply be recognized as and treated with common human dignity, and there remains I think an interesting and potentially important role for free software in this process, especially in overcoming some of the vast deprivations of both past and present faced by the communities in the captive nations. Given that I was asked several years ago to help speak for the people of the Lakota nation, it seemed appropriate to do so presently here once more.

Well before considering free software as an economic model, some of the captive nations in North America have tried many different things in the past to create self-sustaining economic development, including of course casinos and call centers. Some have tried meat packing for freedom. Yet, unemployment remains high, over 80% for some communities, such as on the Lakotah reservations in North America. Similarly, per capita income often remains below the poverty line. On the Lakotah reservations, per capita income in fact is less than $4,000 annually, and average life expectancy is now under 47 years. These are not statistics from communities in Haiti , but rather from within the United States itself. The exact story is of course different for each of the captive nations, but the overall results of even the best of these efforts have usually been rather bleak.

One essential problem with call centers and casinos is that they require nations and people to participate in a culturally foreign social-economic model. Each time doing so, a small part of the culture dies in the process. That is because this model requires people to compete against each other, often by any means necessary, and to do so while using the labor of others for personal gain in a market that is often closed and where goods and services often become artificially scarce and demand is artificially generated to further extract wealth, rather than meeting real needs.

Certainly, for the American Indian working at a meat packing factory or a call center a job is a means of survival for a family. But it leads to no real economic development or further growth, whether for the worker or for the nation. It is a relationship that exists solely because the cost of bargained labor is so very cheap on the reservations. If the standard of living and income expectations did materially rise, those so eager to place some temporary facility or industry on the reservation will often simply pull up and leave to someplace cheaper. In fact, this relationship specifically discourages investment in the kind of economic development that would produce long term growth, infrastructure, and economic facilities, because doing so both will create higher future labor costs and make it far more difficult to later leave.

Even in the case of casinos, there are issues. Where a nation is fortunate enough to be the direct beneficial owner of a casino rather than simply licensing the rights and profits to an outside entity, this casts the nation itself in the role of extracting wealth through deliberate deception of others. It may be ironic, given that this is essentially a reversal of roles, since often indigenous lands were acquired through such tactics, but this too means people must forget who they are and what their lifeways mean and take up the very same behaviors of the invader that they found to be so very offensive. In this way, also, the nations and culture can surely also slowly die.

As I noted there are often basic cultural questioned tied to economics, and this is so often ignored by the great economic theorists. This understanding came most clearly to me from a discussion I had with Russell Means. While at the time I was starting a GNU/Linux telecenter project on the reservations, we ended up discussing the social and cultural consequences of western education. What he reminded me, and to roughly paraphrase his words, “Indians do not compete”. This however is in reality very much a social-economic statement, and not just one about education.

Clearly a possible way forward is to look at sustainable models based on voluntary cooperative economics, and there are a number examples found practiced today which do not require high levels of (presumably external) investment to get started, and which have already been demonstratively effective. One of the best examples of this is potentially found in the economics of free (as in freedom) software, and this is where I think technological-social free software projects could have an important role that can effect the real future of families, and not just in enabling education.

As we all know, free (as in freedom) software is often expressed and provided through a copyright license, and the best example is the GNU General Public License. The terms of such a license essentially are that one who receives free software is free to provide the software to others, whether in original form or modified, so long as they add no additional restrictions or conditions when they do so. Since they originally received the software with the full source code to compile and the information to build it (per gplv3 for example), it is necessary to offer it to others with the same. This, in economic terms, is also a transaction, but not necessarily an exchange of money, it is rather an exchange of consideration.

This relationship does not in any way prevent free software from being commercially sold in any fashion, as indeed demonstrated even by very large public corporations like IBM or very successful new ones like RedHat. However, it does mean one cannot artificially control or otherwise restrict the freedom of what the purchaser may do with what you have sold them. It instead offers new ways, including especially economic opportunities, for buyers and sellers to relate. Since the downstream seller may choose to make changes or fixes and then redistribute the improved version, those changes too become public, and can make their way to the original developer and all users of said software who then benefit. This is where cooperative benefits scale, and in a manner that is both socially and culturally consistent with the lifeways of many nations.

When speaking of upstream providers, downstream sellers, and end users, this is an analogous representation of what many free software integration projects and true free software business models already do in terms of it’s upstream and downstream relationships. Equally important, free software allows cooperative expertise rather than forcing rivalrous knowledge. Since one cannot derive exclusive benefit at the expense of another, there is much greater incentive for people working on similar problems to do so together, even when the outcome is in free software that will then be commercially sold. This might be thought of both as a market of both abundance and mutual interdependency, and such markets are the only kind I have seen that can self-sustain without abuse.

With no market barriers to participation, and today with the possibility for near zero cost in distribution, much of the cost of commercially starting in free software are entirely infrastructure and equipment costs. Given the cooperative nature of free software, this too could lend itself to shared or cooperative costs. Individual nations could even minimally invest in setting up small community development centers where equipment and infrastructure are particularly scarce. We had looked at starting something very much like this in Lakotah.

Free software certainly will not solve all the problems of the captive nations alone. However, it certainly can even in a small way help contribute to the establishment of sustainable economic development as well as a means to enable individual and communal economic sovereignty even in the present world, and hence to do so without having to compromise core social and cultural principles in the process.

I will be speaking at LibrePlanet 2010 being hosted at Harvard on March 21st on enabling the creation of bottom-up user controlled real-time encrypted communication networks to preserve privacy and as a means of asymmetric warfare on mass communication surveillance, using GNU SIP Witch and the GNU ZRTP stack. Preliminary copies of my presentation may be found at http://www.gnutelephony.org/data/harvard2010.pdf.

Co-hosted with LibrePlanet2010 is the GNU Hackers meeting. This to me, especially in these times, is an essential gathering of GNU maintainers, as I believe this decade may well be when the future of freedom may well be decided for humanity. We face a choice between a world where people are free to learn and participate in the collective heritage of all mankind by contributing to our shared human knowledge, or one where what people will be permitted to think, or even communicate and express, to be entirely controlled as the age of science and reason comes to an end for the greed of a sociopathic few.

For this reason more than any other, I choose to attend this years conference, to hear and consider more what actions can and should be taken to assure freedom endures.

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.

For the last few years I had been working when time was available on what is called the GNU Telephony Secure Calling Initiative. This initiative was originally started specifically to make passive voice communication intercept a thing of the past using free software and public standards, and came out of ideas from and the work of the New York City civil liberties community and New York Fair Use in the early part of this decade.

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.

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.