More riffing on software licenses

Suppose you've written some software from scratch on your own time, using no resources from your employer. Suppose also that, having written it, you're proud of it and want to show it off to other people, perhaps get them to use it and give you feedback on it.

When doing this, the question invariably comes up of which software license you should publish it under, especially if other people would also like to contribute to it. If your aim is to eventually publish it as proprietary software you might choose a restrictive license like the Microsoft Reference Source License (Ms-RSL) which allows people to look at the source code but not to redistribute it. If your aim is to further the cause of eliminating all proprietary software you might choose a copyleft license like the GNU General Public License (GPL) which forbids use of the code in proprietary software. If your aim is to allow the software to end up running in as many places as possible, you might choose a permissive license like BSD.

Generally one will have multiple goals. For example:

  1. I want the software to be as useful as possible to its users.
  2. I want the software to do the greatest good for the greatest number of people. Note that this isn't the same as (1), since software can be useful to those running it without doing good to society as a whole - consider the case of the software controlling the machines at the cigarette factory.
  3. I want the software to be as widespread as possible to maximize my reputation.
  4. I want to make as much money as possible from the software, one way or another.

I think it's pretty difficult to predict at the start of a program's lifecycle which license is going to have which effect on which goals. Therefore the choice tends to be made on philosophical principles rather than sound science, such as "I believe the greatest good is done by making life as difficult as possible for developers of proprietary software" or "I believe that putting as few restrictions as possible on developers will make the software as useful as possible" or "I can maximize my chances of making money with this software by forbidding its distribution".

The philosophical principle which currently seems to make most sense to me is that goals 1, 3 and 4 are the important ones: the best way in the long term to make lots of money out of my personal programming projects is to make a good reputation for myself, which means getting my software running in as many places as possible, which means making it as useful as possible. Goal 2 would be nice but it's impossible to predict the long-term social good of any given action. The money spent on Microsoft software has done an enormous amount of good, for example, but that doesn't necessarily mean that all Free Software authors should drop what they are doing and contribute to proprietary software instead.

Suppose I write some piece of software X, and software developer Y takes this work and incorporates it into product Z, adding proprietary feature W and releasing the result as proprietary software. I haven't really lost anything in this situation - I (and the other users of X) can still do all the same things we could do before Y got involved (we can just pretend that product Z doesn't exist if we prefer to). Users who buy Z benefit because feature W is worth more to them than the cost they paid (both in money and reduced freedom) - they have one option that they didn't have before Y got involved. I (and the other users of X) benefit from publicity that Y creates around Z (especially if they don't try to hide the fact that Z is based on X) since that may itself draw more users to X (users who would not have otherwise heard about X and for whom W is not worth the cost).

As I see it there are a few disadvantages for copyleft licenses. One is that they are incompatible with existing non-copyleft software licenses (for example, one cannot take GNU code and use it in software that has an incompatible but still copyleft license). Another is that many companies have an aversion to copyleft licenses, eschewing such software entirely for the (not unfounded) fear that an accidental inclusion of copyleft software into their proprietary products will cause said products to become copyleft. In such cases the advantages for X above would never have happened.

Compatibility with other licenses is a big advantage for a permissive license - the BSD license is compatible with the GPL, for example (meaning you can take BSD code and release it under the GPL - the reverse is forbidden). Can we do better than the BSD license for compatibility? I think we can - even the BSD license includes some restrictions, such as the one that the warranty disclaimer must remain in place. I don't really see the advantage of warranty disclaimers - they seem like a CYA piece of legalese which doesn't actually do anything except take up space in licenses. I'm not a lawyer, but has anybody ever been sued because free software they wrote misbehaved and didn't have a warranty disclaimer? I doubt it - it seems like we can't even prosecute malware authors, who not only don't disclaim warranty but write software that's actively harmful.

My preferred software license would therefore be the most permissive one possible - essentially equivalent to not being copyrighted at all (same as "public domain" in many places). This state of affairs is compatible with any license that a third party chooses to use when redistributing the software. Maximum compatibility means greatest usefulness. Now, not all contributors to my software necessarily feel the same way, and that's okay - if Richard Stallman wants to contribute to my software but only on condition that his changes are GPL, that's okay - he can just make a GPL fork of my software and contribute to it. Others might contribute to my fork (if they share my views) or to the GPL fork (if they share Stallman's). One could even have a change-tracking system which would keep track of the license associated with each change, and therefore be able to tell you which license you can distribute the software under, if you include changes A, B and C. Forks could then compete on the merits of the resulting software - i.e. if one license tends to get more and better patches than another, its quality will rise and it will tend to be the one that gets used, so further patches will build on it and use the same license. If one particular license causes the software to be less useful, that license should die out. It would be an interesting ecosystem experiment to do. My suspicion is that the root "public domain"-like license would tend to be win more often than not because I would expect that most programmers would think the same way I do, preferring to get their patch into all license forks rather than just one. Also, restrictions can always be added in the future but removing them is much more difficult.

Leave a Reply