The Problem With Patchwork

I'm working on a project that involves using microphones attached to StrongARM-based microcontrollers. My source is GPL. As such, I borrowed much of the StrongARM driver code from the Linux kernel. I plan to borrow Fast Fourier Transform code from fftw, a GPLed FFT library. This will probably save me about a month of work. This is the power and freedom of truely free software.

In the past couple of months, a number of companies have released programs under what I call "patchwork" licenses. The license allow for free-of-cost distribution, and modification, but modified versions may only be distributed as the original program, and a "patch," or list of modifications that were made to the program (patches can be automatically applied without much difficulty).

Patchwork licenses are Open Source(tm), as certified by Eric Raymond, holder of the Open Source(tm) trademark before he lost it. The claim is: since people can modify and distribute code, so it is free software. A few of the more prominent people in the community have bought that claim. Even Richard Stallman has accepted some of these licenses.

However, they are not free software (unlike "Open Source," no one owns the term "free software," so I am free to decide for myself).

The main purpose of free software is, as the name says, freedom. Economic efficiency is a secondary, but still important, aspect of free software. Both of those are limited by patchwork. I'm no longer free to use other people's code in other projects. If the Linux kernel and fftw were under patchwork, I would no longer be free to borrow bits of their code to do my research. As such, I loose freedom, as well as time. I am forced to reinvent the wheel.

Worse, it is difficult, if not impossible to make some types of changes to a program. If I were porting a graphical toolkit to a new platform, very little of the original code would remain, and I could trivially bring it to the point where none of the original code looked the same to a patch program. Even if I simply reindent the code to a different style, patch will consider it a completely new program. It's unclear how I could legally redistribute that. If I decide to develop this in a larger group, with public CVS read access, I again break the license. Since people can download the new version in non-patch format from CVS (and most other versioning tools), it is much more difficult to organize group projects. If I decide to take a file for the "list" widget, copy it over, and modify it to make a "tree" widget, the patch program will also not be able to deal. The patch will be illegally distributing some of the original code (if it were legal, I could again reindent the whole program, and distribute a patch containing everything, getting around the license).

I'll insert a simple analogy for non-programmers here: If you take an English work under a patchwork license, and translate it into Polish, there's no convenient way to distribute the new work as the original and a list of changes. If I rearrange the book, but keep most of the original text, it's also difficult to find an automated way to keep track. If I pick up a short exert from the book for another book, it becomes incredibly cumbersome to distribute the new work as the original and a list of changes.

Programmers who use patchwork are good people contributing to the community, and should not be flamed (any more than proprietary vendors bringing their products to GNU/Linux). There are also some very good and valid uses for more constrained licenses. However, we need to realize that patchwork is not free software, and we should avoid letting it into the core OS.


Copyright (c) 1999. Piotr F. Mitros.