GNU Telephony

When we think of the cloud often we have to think of the negative consequences, of diminishing the rights of users and removing their control even over their own computing. When combined with an illegitimate surveillance state and abusive monopolies that believe they have the right to look at people’s private data and communications at whim, this puts basic liberty, and even the life, of people engaging in entirely legitimate activities in danger from that most basic human need, that of communicating and sharing with each other. However, not all ideas for cloud computing need be based on or potentially offer anti-social and otherwise destructive outcomes.

Much of cloud computing infrastructure of course also uses free software. True software freedom even includes the freedom of some to misuse. The GNU General Public License deals with a very specific form of misuse, where anti-social parasites could try to create proprietary versions of existing free software and thereby deny their own downstream users the same freedoms they themselves received. However, the potentially malicious aspects of cloud computing use is different, and, for example, like free software used in military systems, is one which to solve potentially has the unintended consequence of destroy freedom for many others. We simply cannot of course predefine for others what are legitimate uses for our software, we can only assure that people who receive it have the same freedoms we ourselves received, whether we feel they use it for what we may deem as good or bad purposes. If we act otherwise and define for others what we consider “permitted” uses we would in doing so destroy freedom 0.

However, it is worth noting that not all uses of cloud computing need have negative social consequences, and I wished to spotlight a specific example which I think shows a better way to go forward. This particular one is a service and software stack for cloud services offered by RedHat known as Openshift. I do not choose to endorse particular companies, products, or services, but I wished to highlight what RedHat is doing in the context of this discussion because they are doing something very relevant and interesting that may offer a means for addressing the anti-social and more destructive aspects of cloud computing.

Openshift itself was originally called Makara and part of a company that RedHat acquired in 2010. Having done so, they made the entire stack available on a free software license (Apache 2.0) last year. Of course as noted other cloud computing stacks are available on free software platforms, and at least some with liberal/free software licenses. This is not the problem. However, there are several essential things that RedHat is doing differently that are worth noting.

First, they make use of git and shell access to deploy applications. This solves one important issue; data migration. Often cloud computing providers lock your application services on their platform, and you cannot then easily get your computing back or otherwise migrate it, for example even to another provider, and even if they both use the same base software stack. This makes application migration as easy as setting a different remote git repository and pushing. However, the real problem in cloud computing is not in being able to migrate from one potentially abusive external entity to another all under the watchful eyes of a surveillance society, but also in being able to regain full control of your computing if you so choose or otherwise need to. It is in this I think Openshift offers an interesting solution that I think should be a default behavior for all legitimate cloud computing services.

Starting, I believe with Fedora 19, the entire Openshift stack is being included in the Fedora repository as a simple set of packages anyone can download and install. There is also online resources and documentation for building the infrastructure from source. This means if you do not wish your computing externally hosted, you could, with relatively modest resources, host your own cloud computing directly. And since simplicity of data and application migration is already part of that infrastructure, it also should be very easy to migrate services and applications back to your own facilities anytime you may wish. To me this helps to mitigate an essential risk in cloud computing.

The Openshift infrastructure of course itself somewhat complex to setup and configure, and this I do not see as avoidable. However, having the freedom to do so, and the means to find expertise to help as needed, as well as very simple application migration, are essential elements missing in many cloud computing services. Having the means to do so with pre-packaged components in a distribution repository and under a free software license also will make that freedom much more realizable than simply theoretical freedom.

I see much less risk in having the freedom and means to host with an external cloud computing provider, so long as one can reclaim control and local ownership of one’s hosted computing if so choosing, and can do so relatively easily. Nor do I see any problem with using cloud computing tools for local infrastructure so long as they are provided as free software that runs on free software platforms. There is certainly room for improvement, though. Elasticity should mean seamless migration from local facilities on demand and by desire entirely under the users control, rather than by first requiring external migration. That is, the cloud elasticity should be an adjunct resource for times and workloads when desired, rather than an either/or choice. Having matching infrastructure locally could help eventually make seamless operations possible, certainly it is the place to begin.

RedHat itself offers some infrastructure for the community to experiment with Openshift, and we have been using this for a few things. In particular we are using it to host a bug tracking system and a friendika instance. In some ways this is better than a some kinds of more traditional external hosting provider because we do have the means to easily maintain our applications, as well as having the freedom to easily migrate and have these things hosted elsewhere if we do so need. This I think is at least closer to how cloud computing services should be offered.

I have recently been working on RaspberryPi GNU sipwitch servers. I actually have two things in mind for this. The first is a simple and complete stand-alone secure free software voip “switch” anyone could deploy and use, much like a FreedomBox for VoIP, as a kind of wallwort with ethernet you can plug into any router. A low cost and general purpose secure VoIP server does I think have appeal, and producing complete pre-configured and assembled servers would certainly be more interesting than selling project t-shirts. The second idea is a sipwitch VoIP public wifi access point to enable anonymous secure calling, like pictured here.

The RaspberryPi itself shown here was actually won in the recent Fedora participant open hardware giveaway contest. While I do participate in Fedora as a packager, in recent years I tended to focus more on Debian, and currently do have the Debian derived RaspberryPi distro on it. I would be happy to try Fedora for arm on it as well, especially since I do package sipwitch for Fedora.

I also maintain an active package archive in GNU Telephony that now includes both armel and armhf packages for Debian Wheezy, as well as mipsel for use with entirely free hardware and bios, such as the Lemote yeeloong netbooks. This archive can be added to any Debian related distro adding “deb http://www.gnutelephony.org/archive/ wheezy/” to a sources.list. I also have squeeze packages, and I include both source and binary packages for everything I build. Awhile ago I found a simple means to automate production of multiple binary architectures through the use of qemu as part of my normal release process for those packages I maintain. Having a publicly accessible Debian archive updated for each new release seemed a natural extension of this.

The sipwitch coventry voip and wifi access points really came about because I originally wanted a sipwitch raspberrypi server I could take with to conferences to setup and demo, complete with an entirely portable communication infrastructure that I could use. Too often I have been at conferences where infrastructure was not available in the presentation rooms, or otherwise not suitable for this, like what happened to me several years ago at Harvard, which had password restricted wifi and isolated individual machines from each other. It also fits well into GNU Telephony’s goal of developing self-organizing mesh networks and community grids.

In respect to presentations with this initial experimental access point, it could be rather interesting to be able to accept VoIP calls for q&a from the local audience directly. It would be even more interesting if we can get a network to tie to for the ethernet side that would allow remote voice and video participation as well. I want to re-think how such presentations are done, and how to make it easier for remote participation in general. These all offer interesting ways to demonstrate and promote the freedom of free software to think, imagine, and go beyond how things are done today.

The specific use of a powered usb hub was to avoid the problem with too little power on the RaspberryPi to drive a wifi device. This is not needed when using it as a pure voip wall-wort through local ethernet, and that would likely be the most convenient and widespread form factor I would propose building, and of course that has some natural overlap with the FreedomBox effort. Another interesting idea that came out of this effort was to create a RaspberryPi hylafax server using usb fax modems.

The particular choice of coventry itself as a name for our RaspberryPi VoIP servers really came from the idea of what to properly call a collection of bruja de sip del GNU servers, which, spectacularly obviously, would have to be some form of coven.

It has been known that I tend to do some cross-platform development, including for software that can be used by people unfortunate enough to have to use Microsoft Windows. However, I thought it particularly relevant to talk about how we do this, as it offers a much clearer vision of how to maintain freedom in the production of free software even when doing so for otherwise captive users.

For me the most logical approach has been to make use of MinGW (Minimalist GNU for Windows), which is a set of GNU tool chains, GCC compilers, and tools that have already been adapted for compiling applications for Microsoft Windows. However I do not use these on Microsoft Windows itself, as I do not run proprietary systems to develop or build applications, or even have proprietary operating systems on my machines. Instead I use it on Debian hosted systems as a cross-compiler environment.

The MinGW tools for cross-compiling have been present for a long time in Debian. The present form is installed with mingw-w64-dev, and supports building applications for both 32 and 64 bit Microsoft windows. Fedora also includes a version of MinGW in their repositories. In their case, they not only package the cross-compiler, but also common free software related libraries, which can be installed to provide a more complete environment. There is also a PPA out there that does the same for Ubuntu. I am however not so sure this is a great idea. What I do instead is directly cross-compile a common set of free software libraries out of a vendor branch repository that has versions I can test and maintain as needed.

The concept of a vendor branch is that one takes an existing external (3d party) library produced elsewhere and imports that into a local repository. One can then track local changes needed for something different (such as mingw cross compiling). Since the base of the tree is an import of an upstream release, one can easily create and submit patches back to an upstream when appropriate.

I now use git for such vendor repositories. While there are different strategies to do this, for me the simplest was to create a bare repository, and then only push and store tags in it. All intermediary work can be done with local branches as needed.

If I want to make a repo for version 5.0.0 of libfoo, I would create a repository, locally create an import branch, and tag it something like v5.0.0-original. This tag then gets pushed. If I want to do some changes, I can create a temporary work branch locally in git, do the changes, and then create a new tag, like v5.0.0-patch1, and then push that new tag to a remote vendor repository. If I want to then submit a patch upstream, it is as simple as using git to diff between v5.0.0-original and v5.0.0-patch1.

So a new 5.0.1 release comes out. This too I can import into the same repository, using a new temporary local branch, and import in a new tag, v5.0.1-original. In theory I can then apply the changeset between v5.0.0-original to v5.0.0-patch1 to it to get any patches/changes I found needed for local builds, and save that as a new tag, v5.0.1-patch1, as well. This is very similar to how vendor branches used to be handled in cvs.

So far I have been able to rebuild most libraries one finds in a GNU distribution for common application development, as well as cross-platform desktop toolkits like Qt. In the case of Qt, I was able to create new spec files that explicitly support cross-building mingw32 hosted on Debian and then use Qt’s own configure to generate appropriate makefiles. I also have been looking at wxWidgets for some uses.

Building instable binaries on MinGW32 hosted on Debian also provides a much saner way to develop software for Microsoft Windows. Where Microsoft never really seems to have developed a concept for a standard shared place to store common libraries and headers, and I think this is because even the most basic philosophy of code sharing seems completely alien to them, I can organize one on a debian box and build with it with simple configure flags.

Since I also use nsis (also packaged in Debian) to make pretty graphical installers for applications for Microsoft Windows users, and can use wine for testing, this means I can build and test deployable binary applications for Microsoft windows users without ever having to have a license or any other legal instrument with Microsoft, whether for their development tools or operating system, and this too I am happy about. We can build free software for that platform using entirely free as in freedom tools and operating systems. These tools can never be taken away at the whim of a proprietary vendor, nor enable false legal harassment that any form Eula with an entity like Microsoft can potentially enable.

Of course we license our software using the GNU General Public License (v3 or later), and so others do have the freedom to build, modify, run, and distribute our software as well, even on entirely proprietary platforms, if they so wish. Also, we will take patches into our distribution for such uses, so long as they do not interfere with the ability to build and run on free platforms.

Where free software tools and software are needed to empower and liberate users even on defective source secret operating systems, I feel the only ethical means to do so is using free software tools hosted on already free platforms. For this reason I will probably never produce installable binaries for OS/X, as I have yet to find an effective means to support cross-compiling on a free platform for that. Certainly also I will not produce installable binaries that can only be offered to users through closed application stores which are in effect censored. Those I see as dis-empowering both end users and software maintainers, even those producing proprietary software, in ways that are unconscionable. I see it as part of a clear and very deliberate attack on what we call freedom 0. I also see it as a form of restraint of trade and may seek other means to address it going forward.

Sometimes you learn about what’s going on in a distribution by accidentally breaking something. Such was the case for me recently with respect to Fedora.

Fedora is an RPM based GNU/Linux distribution that does focus on providing a free software license clean repository, with the one unfortunate exception of the Linux kernel itself including binary blobs, and that publicly fights against software patenting. Fedora also happens to focus on enabling community self service a lot. For this latter reason too it came to pass that I maintain some of my upstream packages directly in Fedora over two years ago, rather than having this done by an intermediary Fedora package maintainer, as more often occurs in other GNU/Linux distributions.

Often Fedora provides the most current software in the community. Recently (in F17) Fedora choose to upgrade to the latest ortp. We have been in the process of quietly integrating GNU ZRTP into ortp since last year. The result of this was first realized accidentally with this new Fedora release, when my current commoncpp release, for the first time, broke KDE Kopete and Linphone in Fedora 17 over an old and never before identified bug.

Breaking something in a distribution is not the most horrible thing, and we were quick to resolve it by providing a fixed package. However, it made me think about something deeper. In Fedora, we have sflphone, linphone, and kopete, we may even still have Twinkle too (I haven’t checked), and all of them are now offering the potential for secure calling using the GNU ZRTP stack. They may well be the first widely used distribution that now potentially offers media path secure calling in most of the included voip clients by default. And Fedora does also include GNU SIP Witch.

I think it is time again to think about what secure calling means from the perspective of a distribution. How do we effectively put together something at a GNU/Linux distribution level where all the pieces work together seamlessly, and it is easy for anyone to setup and deploy secure calling clients or services, whether for private use or for an organization. And what does this vision mean for what we need to do next with GNU Free Call, how does a GFC client finally help bring these pieces together.

The last time I thought about the question this way was also over two years ago, and it was perhaps premature then. We still did not have all the parts needed to do so available to end users in any distribution at the time. We were still struggling with what was an artificially overly political process even getting packages included in some GNU/Linux distributions. It also before GFC, and what was thought about then is now rather obsolete.

Fedora operates as a true community of equals without politics, and I will give them much credit for doing that also. It was at the time back then, and I think it remains the easiest GNU/Linux distribution to try and work with in this way. This time I want to get more feedback about what others think and expect a distribution that offers the possibility for providing secure communications through free software much more out of the box should look like, and this need not be limited to voip.

If there is interest in this I would be happy to put together and propose a new feature for what will be Fedora 19 and 20, as well as seeing what packages would need to be suggested for inclusion in their repository, or otherwise modified as part of such a feature proposal. Some of this work will be needed anyway to introduce GNU Free Call into Fedora when the time comes to do so. Having more feedback I think will make for a cleaner and more compelling feature set. If we can similarly work better with other free software distributions, I would be very happy to do that also.

Cross platform development is always an interesting challenge. Often it can be useful to identify or expose bugs that might be less visible on some platforms, or even on some compilers.

With cross platform development comes some important questions of software freedom. There would be no true software freedom if we said we would permit our software to compile and run only on specific platforms, that is after all what proprietary software vendors often do. However in GNU Telephony we do principally develop and test our software on GNU systems specifically and do not have expertise in or interest in supporting proprietary ones.

If people wish to work on or support other platforms also, they are certainly free to do so. As one of our goals in GNU Telephony is ubiquity, this is essential. However, unlike some groups who choose such goals, or distributions who choose “popularity” as their essential goal, we will never do so if it means also compromising the freedom of our contributors and users. Given this, if people want to submit patches for building and running on other platforms, we are happy to take such patches in, so long as they do not break features or functionality on free software platforms, and do not impose any additional restrictions on how we convey software to others.

For those who do choose to develop on or for Microsoft Windows, and wish to contribute to our packages, we do suggest using the mingw toolchain hosted on Debian GNU/Linux. We have done some preliminary tests with this, and have built things which then do run in wine. This does make it possible to do a complete build and qa test cycle for applications that will run on Microsoft Windows systems using entirely free software tools and platforms, as well as making it easier to avoid traps in undocumented proprietary api’s. We will accept patches and bug fixes from those who do build on proprietary compilers as well, assuming there is no restrictions or breakage to do so, since, as I note different compilers sometimes do expose useful bugs, however our desire is to support development tools and platforms that do support and encourage software freedom.

Software freedom and complete free software platforms is our projects essential goal, for without it, there is no possibility for communication privacy or security. This makes fully free software platforms, which are hostile to hosting malicious features or hidden backdoors, equally essential. While we do the best we can to facilitate secure communications in our packages, we do not recommend using or running our software on proprietary platforms, as we consider these untrustworthy and potentially insecure by design.