Reenigne blog

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.

As well as being not invulnerable and somewhat unnecessary, copyleft licenses may also be at least a little bit harmful to the software they are protected by, at least compared to permissive licenses.

The trouble with Free Software licenses (especially restrictive ones) is that they have a tendency to be incompatible with other licenses (even other Free Software licenses). Consider the sad case of the GCC manuals which underwent discussion on the GCC developers mailing list a while back. GCC is licensed under the GPLv3, whilst the documentation is licensed under the GFDL. Both of these are Free Software licenses, but because they contain slightly different restrictions, they are mutually incompatible - you can't take GCC source code and copy it into the GCC manual, nor can you take parts of the GCC manual and copy them into the source code. This means that the technique of literate programming is impossible - documentation can't be automatically generated from the code.

This could be solved if there was one single copyleft license that was used for everything, but I can't see that happening if the GNU project can't even standardize on a single license for its own projects.

It's important to note that these problems are caused by the restrictions imposed by the license, not the freedoms it guarantees - the same problems would occur with proprietary software, if the corresponding situation ever occurred.

Yesterday I showed that copyleft is not invulnerable. Today I will show that it is also (at least somewhat) unnecessary.

Let's again suppose that Microsoft wants to make a proprietary MS-GCC. They make version 1 (based on GCC 4.6.1, say) and it all works out great. But then GCC 4.6.2 becomes available and the proprietary patches don't work with the latest version any more. Microsoft wants to take advantages of the changes in 4.6.2 (otherwise MS-GCC will look bad compared to the latest FSF-GCC). So they re-do their patches. Each time a new GCC becomes available, Microsoft has some work to do to keep up.

It costs Microsoft money to keep doing this, so they look for an alternative. One such alternative is to assign copyright of these patches to the Free Software Foundation and contribute them to FSF-GCC. This might be a bit more work than just updating the patches, but it only needs to be done once. Then, further versions of GCC will include the Microsoft patches without any additional work on Microsoft's part.

This does, of course, mean that those proprietary changes become Free Software. That might not be such a big deal - chances are that if MS-GCC was really that much more useful than GCC, the equivalent functionality would be duplicated by GCC developers anyway (especially now that they know it's possible and useful).

So the "carrot" part exists independently of the "stick" part (the GPL) - even without any threat of a copyright violation lawsuit, there are still reasons to contribute your changes.

A while back I showed that it is possible to work around the anti-Tivoization provision of GPLv3. I've since realized that the GPL itself has a similar loophole.

The entire thing is predicated on the idea that if you change a program, you've created a "derived work" which therefore falls under the same copyright protection as the original. But is a change necessarily a derived work? If it doesn't include any of the original program, I don't think it necessarily would be if the change was distributed as a delta from the original. Normally a diff file says things like "in file x, look for the line that contains y and change it to z". Because this file will contain the line "y" (and even the filename "x", if it could be considered a creative work) it is a derived work of the original program. But one were to use a diff format that says "in the third file, change line 327 to z" that would contain no copyrighted information from the original, and could be distributed without restriction. There really isn't any difference between a code change and "mere aggregation".

What does this mean? Suppose you're Microsoft and you want to include GCC in Windows, modified with some proprietary algorithms and you don't want to release the source code. It turns out that this can be done. All Microsoft would have to do is include in the installer some code that will download the source (or binary) from a known location (perhaps from GNU servers, or a trusted third party's servers) patch it and (if necessary) compile it. Hey presto, there's the MS-GCC binary. The patch could be in the form of obfuscated code, object files or even (with some difficulty) binary deltas as long as care was taken to ensure none of the GNU-copyrighted works ended up in the Microsoft-distributed patch. Microsoft would not be committing copyright violation since none of the things they actually distributed contained any GNU-copyrighted code. The end-user would not be committing copyright violation either since they aren't distributing the software.

Essentially, with this hack, we've shown that the GPL is essentially equivalent to a BSD license. This isn't something that can be fixed by changing the license - it's a fundamental fact of copyright law.

The reason people don't do this is because it's more convenient to just release changes under GPL (so that a compiled binary of the aggregate can be released) than go through this hacky patching process. So it doesn't mean that copyleft isn't worth doing - in fact, I have heard it said that there are important parts of gcc which would never have been contributed if their authors' hands were not forced by the GPL.