« Welcome... | Main | The IDs of March »

net.wars: A fork in the code

The open-source community has always been conscious of the dangers of forking: the splitting of the software codebase into multiple versions that make the software too confusing to use. The result is that although there are multiple flavors of GNU/Linux they are all compatible. People have been very careful about the codebase.

The problem now, as so often, is lawyers. While everyone has agreed on the importance of shared programming code, there has been less agreement on the importance of shared licenses that dictate how people may use the codebase. If you choose free or open source software because you want to be able to modify, reuse, and redistribute the code, you may spend more time studying the licensing terms than you do the software. The Open Source Initiative lists 58 approved licenses.

The trouble is that many licenses require new work using old code to be distributed under the same license the old code used; when you mix code, you also mix licenses. This provision was Richard Stallman's key insight when he created the General Public License, the father of all these licenses: he wanted to ensure that software written as free software would remain forever free. This recursive requirement brilliant, and Stallman undoubtedly deserved his MacArthur Foundation Genius Award. But dozens of imitators later, it's like computer hardware in the 1970s – dozens of incompatible designs.

Aware of this, the Open Source Initiative has set up a license proliferation committee to try to streamline things.

"About 30 are kind of hard-coded with the name of the licensor such as Apple or IBM," says Cliff Schmidt, legal affairs officer for the Apache Foundation and a member of the license proliferation committee. "You could edit them, but if the point of OSI is to have licesnes you can reuse, that's a quick way to get rid of a bunch and say they're not really useful as they stand because they can't be reused."

If you move away from software, you find that Creative Commons is beginning to wrestle with the same problem. People talk about "a Creative Commons license" and imply that means their work can be remixed, reused, and redistributed, but the actual license terms vary quite a bit and people don't always notice.

That confusion is the reason Stallman has given recently for refusing to support any of the Creative Commons licenses. "I no longer endorse Creative Commons," he said in an interview with LinuxP2P a couple of weeks ago, going on to explain that the terms of some Creative Commons licenses, such as some of its Sampling licenses are "unacceptable to use for any kind of work". Debian's legal members, too, last year analyzed some of the Creative Commons licenses and have recommended against using some of them for varying reasons. A particular stumbling block for free/open source software advocates is the option of prohibiting commercial reuse and distribution – and there, I suspect, is a key difference between the content industries and the software industry.

The content industries have long been a war between individual artists/creators and large publishers/distributors. Until recently, it was rare for artists or creators to have access to the means of distribution. But software has grown up in a world where copies were easily exchanged, in an industry new enough that huge companies can be built by two people starting in a garage. Most content creators create whole works (outside of the movies, which are fundamentally collaborative). Most software is written collaboratively. Content creators are usually self-employed, most live near the edge of solvency, and they have learned from an industry with a long history of treating people like them badly to be wary that everyone but them will profit from their work. Even something like the Free Art License recognizes this danger.
Programmers, on the other hand, usually have jobs, and their work in open source may pay for itself in increased visibility, respect from their peers, and even higher salaries. That fundamental difference in outlook is, I think, one reason why documentation in the free/open source movement tends to be so poor: few writers can afford to work for free, and when they do they want to do something that isn't the same as everything else they do that day.

It seems clear that the number of licenses will be streamlined. But the fundamental political differences are not going to go away, as the inclusion of the express bar on DRM (which Stallman refers to as "Digital Restrictions Management") in GPL version 3 makes plain. In the end, we are likely to wind up with three main branches of free/open source licenses: the purist branch which bars all restrictions on reuse, digital or otherwise; the commercial branch, which allows some restrictions but does not distinguish between commercial and non-commercial reuse; and the non-commercial branch, which allows some or no restrictions for non-commercial reuse but retains control over commercial reuse. I do not see any way that these three fundamental disagreements can ever be resolved into a single free license codebase.

TrackBack

TrackBack URL for this entry:
http://WWW.pelicancrossing.net/cgi-sys/cgiwrap/wendyg/managed-mt/mt-tb.cgi/21

Comments

It's true, there is a disease in the open source community; the desire to find a license that is the "perfect fit". There is no perfect fit. Applying an obscure, narrow license to your work may protect it in exactly the ways you desire, but everyone's desires are different in some tiny particular; you end up with innumerable creations intended for reuse and reused for nothing.

There is perhaps a gesture to be made towards license individuality; a group of licenses with variable clauses designed to work together as the "lowest common denominator". An author may not want to restrict his work to non-commercial use, but may also respect the desire of other authors to make this restriction; the license could therefore make a special exception allowing works to be combined with other works so restricted, under the terms of the more restrictive sister-license.

One would have to be careful to limit the number of restrictions available, though, or we would merely end up with a vast mass of works which nobody can use for anything.

Yes. One comment I didn't manage to include in that piece from Cliff Schmidt was that in thinking about licenses he needs to think about what Apache's customer base wants. I hadn't thought of licenses being like a product -- but it intrigued me, especially considering how little input consumers have to commercial software licenses.

wg