Distributed Software Development via Freenet

Criminalization of Developers

If you ever started a free software project, or if you ever submitted a patch for another project, you probably have never worried about being put into jail for it. At least I didn't worry when I wrote a ZIP password cracking program in 1995. But today I am.

Believe it or not, there are numerous examples of programmers ending up in jail basically for writing software, even for software where it isn't immediately obvious that such a thing could be possible.

A famous (the most famous?) example for a criminalization attack is the author of PGP ("Pretty Good Privacy"), Philip Zimmermann. PGP is a program for encrypting files or email messages in a very secure way. While writing and / or using encryption software at that time was perfectly legal (in the US), exporting such software was not. Although Phil never actually went to jail, he has been under investigation for violating export control regulations for three years. He had to spend a huge amount of money on his defense team and was facing a prison sentence until the case was dropped.

A more recent example where a programmer actually went to jail is the case of Dimitry Skylarov, a Russian programmer. For his employer ELCOMSoft, a software company situated in Russia, he wrote a program for breaking into Adobe's ebook format. When he attended the DefCon hacker convention in Las Vegas in 2001, he was arrested for violation of the "Digital Millenium Copyright Act" (DMCA). Although he was never actually found guilty, he spent about three weeks in prison before he was released. The case against him was only dropped after he agreed to be a witness against his employer in another trial.

A case that is still unresolved is the quite famous "DeCSS case" of Jon Johanssen of Norway. His "crime" was to write a program so he could view his legally bought DVD movies on his Linux computer. Although he is probably not facing a prison sentence because at the time he wrote the program he was only 15 years old, his case will continue later this year and is likely to continue causing him trouble.

The point of all these examples is that you don't have to do anything that's actually illegal to get into trouble. If Dimitry Skylarov had anticipated that he would be charged for writing a program in Russia that is legal in Russia he probably wouldn't have gone to the DefCon meeting. Who knows if today we would have software like PGP if Phil Zimmermann had known about the investigation that was to be conducted against him?

Civil Lawsuits

Civil lawsuits against programmers are usually based on patent / trademark or even copyright issues. While these usually do not endanger the programmer of being jailed, they can pose a serious economic risk. Luckily, such actions against individual programmers are not very common, mostly because the financial gain for the plaintiff from winning a lawsuit against an individual programmer is comparatively small.

However, unless some kind of mutual agreement by the parties is found, such lawsuits can seriously hamper progress of a free software project, and even completely extinguish it.

Once again, PGP is a nice example. Phil Zimmermann managed to violate two patents in one program: the patent on the RSA algorithm held until a few years ago by RSA Security, Inc., and the IDEA patent held by Ascom AG of Switzerland. Although an agreement was found so that PGP could be used freely for non-commercial purposes, these patents are probably the main reason why PGP was practically non-existent in the commercial world for a very long time. Moreover, the RSA agreement meant that two different versions of the RSA code had to be maintained.

Sony Corporation have been producing their robot dog "Aibo" for a couple of years now. An owner of that robot was less than satisfied with the software that Sony offered for the robot, and therefore freely distributed his own improvements to Sony's software to other Aibo owners. Despite the fact that the sales of the "dog" and Sony memory sticks benefited from his software (which was even acknowledged by Sony at some time), he was finally bullied by Sony to take the software off the internet.

A less dramatic example is the Unisys GIF patent. Actually, GIF images as such are not covered by the patent, but the algorithm used for compression in GIF images is. After GIF images became quite popular, in the mid-'90s Unisys decided that a license was required for anyone using software for creating compressed GIF images. As a consequence, free software for creating compressed GIF images practically vanished. The giflib library, at that time maintained by well-known Eric S. Raymond, is still available today, but was last modified in 1999. The positive side of this is that thereby Unisys enforced the specification of a much better alternative, i. e. the PNG image format.

An extremely silly example is what happened to Tom Lord, maintainer of the Arch revision control system. He was asked (politely) by BitMover, Inc. to remove the phrase "Line of Development" from the Arch documentation because apparently BitMover own a trademark on that phrase. That trademark is highly questionable, because "Line of Development" is a commonly used term in revision control (e. g. the CVS FAQ mentions it as well). It is worth noting that despite the silliness of the trademark they could've sued Tom Lord instead of just asking.

These examples demonstrate that patent issues in particular can form a severe impediment of the development of any kind of software. While the question of software patents is still largely unresolved in Europe, it seems reasonable to assume that the problems will be getting worse in the future.

Conclusions

The given examples vividly display the threats that programmers are facing today. Laws like the DMCA are being passed in other countries as well. E. g. in Germany a similar law was passed in April 2003. At the same time, the industry is making moves of taking away freedoms of computer users, e. g. with "copy-protected" audio disks or the TCPA aka Palladium aka NGSC efforts. Programmers could re-instate some of these freedoms, like Jon Johanssen tried to, but in the face of the aforementioned threats it is questionable how many programmers will actually take that risk.

The conclusion for me is that I am not going to enter the United States in the foreseeable future, because my ZIP cracking program is probably also a violation of the DMCA, and I have no intent of becoming the next Skylarov.

Freenet

Freenet is a Peer-to-Peer (P2P) network with a strong focus on anonymity and resistance against any form of censorship. In contrast to many other popular P2P networks, freenet is not a filesharing network in the usual sense. Instead of just "sharing a folder", content has to be inserted into freenet explicitly. Therefore, it makes sense to view freenet as a large, unreliable, online storage media.

The freenet network is made up of individual "nodes". Nodes communicate with each other over encrypted connections, exchanging files and other information, like e. g. routing paths. Clients connect to individual nodes to retrieve files from the network. Ususally, nodes restrict client access to very few IP numbers, or even localhost only. There are some publicly accessible nodes, though, like e. g. this one. If you use a public node for client communication, you should be aware that the communication between your client and the node is not secure! In other words, anyone who wants to seriously use freenet should run his own node.

If you have tried the previous link to the public node you'll have noticed that an ordinary web browser can be a freenet client. In this case, an HTTP proxy server is connecting the browser to freenet. People have created complete websites in freenet (so-called "freesites"), e. g. expressing political opinions they'd probably not express on a traceable web server. Other types of clients can connect to the node using a different protocol, which is mostly meant for programmatic access.

Content in freenet is accessed (or uploaded) using "keys". There are three types of keys:

Whenever someone retrieves content from the network, the content is replicated to all the nodes that happen to be in the search path. This is one of the reasons why freenet is pretty resistant against censorship: taking down individual nodes will likely not take down some specific content. The mere process of checking if certain content is available in freenet is causing the propagation of same content!

This also has a drawback: you cannot re-use keys. (Actually you can, as has been shown with the hijacking mentioned above, but the process is unreliable and cumbersome.) To overcome this problem, two tricks are being used:

It is possible to combine both methods by using a DBR key to redirect the client to the current edition.

Arch

Arch is a revision control system designed and written (mostly) by Tom Lord. An important feature of arch is that it is distributed by design. Specifically, it allows every developer to have his own repository. Branching and merging across repository boundaries are possible. Support for locally caching remote archives or parts thereof is also included, which can significantly speed up operations on remote repositories. And it already has a simple API for accessing remote repositories over different network protocols like http, WebDAV, ftp and even sftp (ftp over ssh).

All of these features make arch the preferred choice for software development via freenet: it can easily be adapted to access in-freenet repositories. Every developer can maintain his own repository in freenet, which means every developer can publish his archive under his own SSK. This, in turn, is important for creating trust as described above.

Another good thing about arch repositories is that the files inside the repository hardly ever change. Committing changes into the repository essentially creates a few (less than 5) files inside a new directory in the repository tree, with the bulk being contained in a .tar.gz file. This means that updating an in-freenet repository only requires the upload of the new files, as opposed to uploading possibly many or large files, as would be required by other popular revision control systems.

For people used to CVS-like systems, migration to arch can be a little confusing or even irritating. That is not a result of bad design, though, but rather a result of a quite different design, and in some parts a result of different wording in the respective documentation and tools. However, there is a very good tutorial available.

Throwing them together

The required patches to arch for accessing freenet are very small and touch only very few places, which speaks for good software design in arch. The areas concerned are:

For efficiency, additional files have been placed in the archive's "=meta-info" directory. All of these start with "freenet-" to distinguish them from the rest of the meta-info files. These are not mirrored into freenet.

The freenet-enabled version of arch can be built by checking out the patched version from the arch repository at http://www.unix-ag.uni-kl.de/~conrad/Archives/DSDiF/ or from freenet itself at freenet:SSK@LCgWj0qabAqxUNKbfI93PCTH9RUPAgM/DSDiF, or by downloading the prepared source package from the same URL. It can be compiled, installed and used just like the unpatched version of arch, but please take note of the section "Recommended Practice" below if you're interested in preserving your anonymity.

In order to access archives in freenet, you must simply register the freenet: URI with the command "larch register-archive". Then you can access the in-freenet archive just like any other remote archive with the usual arch commands. Publishing your own archive into freenet is done using the command "larch push-mirror", similar to the way "normal" mirrors can be created.