Wandering Thoughts archives

A thought about free software licenses

It's recently occurred to me that one way to think about the GPL versus BSD/MIT licensing issue is that they are embodying two competing bits of psychology: people want to share their work and have it widely used, and people don't like being taken advantage of.

(Although it may be surprising, there is quite a bit of evidence that we are in some sense wired to feel strongly about 'unfairness' and to punish it, even at a cost to our own interests. Psychologists have done a number of interesting experiments on this; see, for example, the discussion in here, or the discussion of the 'ultimatum game' in this Wikipedia article. Having your work 'taken advantage of' is a form of perceived unfairness.)

This implies that there is no global right answer for which software license to use, since people have different balances of these drives, so how they weight the various licenses will also differ.

(Then when people argue with each other over the license choice, each side can wind up in some sense arguing past each other, because the weights they put on low-level bits of psychology differ significantly.)

A sociopolitical advantage of distributed version control

One of the recent discussion topics on Planet Debian has been version control systems, especially distributed VCS versus centralized VCSes like CVS and Subversion. (I have some opinions on this myself, so I read the entries with some interest.)

One of the points brought up for DVCSes, expressed for example here or the comments here, is that with a DVCS you don't have to start your serious involvement with a project by begging for commit access (that you are unlikely to get, since you have no track record).

But there's another benefit: they let you be a first-class (VCS) citizen even if you are doing something that people don't like or are uninterested in accepting. You get to be a first-class citizen even if you're just doing local hacks or working on an unpopular or unwanted feature.

This matters a lot, because when you are working on something that won't get merged is just when you really need merging and other VCS support to keep it all straight. And there will always be local hacks that people want or need to do on any project of decent size.

For example, I recently patched the Linux kernel to take out a printk() about a SCSI ioctl that's now considered obsolete, because my CD player uses it a lot and right now I'm not interested in either hacking the program or changing to another one. The Linux kernel people would rightfully laugh at me if I tried to send this patch in, so my odds of getting commit access (even on a branch) in any centralized system are low.

In a distributed VCS like the Linux kernel uses, though, there's no problem. I don't have to set up my own VCS environment for the Linux kernel and try to keep it synchronized and so on; I can just branch in my own local copy of the real one, which makes pulling updates and merging and so on fairly painless.

An explanation for the popularity of threads

Today, I had an insight (possibly an obvious one) about one big reason why threads are such a popular and widespread method of doing concurrent programming:

Threads are so popular because they are so easy to implement. I don't mean 'to write programs in', because they aren't really; I mean 'to add to languages and language environments'. Unlike other models of concurrent programming, adding basic threading to your environment or your language takes very little work. So threading implementations proliferate like weeds.

(Note that there are strong arguments that good threads cannot be implemented without relatively deep support from the compiler. See Hans Boehm's paper Threads Cannot be Implemented as a Library and the resulting discussion on Lambda the Ultimate here.)

Other concurrent programming models, such as Hoare's CSP, generally require a fair bit of compiler and language support. The additional work needed means there are fewer implementations in fewer languages, with the knock on effect that it's harder for programmers to play around with these models.

(People who want to experiment with CSP style concurrent programming on Unix might find the Plan 9 'libthread' library useful. It has been ported to Unix as part of the 'Plan 9 from User Space' project, and you can find a bunch of resources on the general model and subject here.)