Why the GPL Matters

There’s an issue that’s been bothering me for quite a while. There’s a problem in the software development world, a practice that breaks down the free and open exchange of information. This practice is widespread throughout the software development world and can lead to a lock-in mindset that is damaging for the advancement of the community as a whole. I’m talking, of course, about copyleft licenses such as the GPL.

via Is Copyleft Really Right for Open Source? – Intridea Blog.

[This started out as a comment on the post above, but it ran long – as my comments are wont to do.]

While I generally agree with the delineation Michael makes (GPL for large systems, MIT for small libraries and tools), I think his characterization of the intentions of the GPL misses out a bit on its historical backdrop. The UNIX family of OSes was severley hobbled by the fragmentation that was a direct result of the original BSD code being, well BSD-licensed. Every vendor built their own incompatible system and it caused a lot of grief for software maintainers and sysadmins alike. Among other things, this is a big part of why we have to deal with the horrible pack of hacks that is Autotools.

So what could Diaspora have done differently? They could have licensed with a very permissive license but added a clause: any modified version of the Diaspora code must remain interoperable with the “standard” release laid out by the Diaspora team. In this way, they could have allowed a thousand seeds to be planted by any company that wants to take a crack at it, knowing that these companies are license-bound to continue supporting the distributed infrastructure of the project.

It’s easy to say “just include a compatibility clause” but in practice that accomplishes nothing. Lots of vendors paid lip service to standards like POSIX, but their clients were locked in anyway because of proprietary APIs that extended beyond the POSIX-specified ones. It would be very easy for a hypothetical “Oracle Diaspora” to hold to the letter of the license and maintain backward compatibility with other Diaspora systems – but to add a whole new set of Oracle-specific APIs. Once an organization began depending on plugins which required on the Oracle extensions for full functionality, they would be effectively locked-in.

In any case, I don’t think Diaspora is a good example, because of all the obstacles preventing that project from ever achieving meaningful success, the license is the least of their worries. Diaspora suffers from the Chandler Sydrome; a total failure to comprehend the economics and dynamics of Open Source systems. You can’t throw money at a vague concept and get usable, popular Open Source software out the other end. It’s been shown time and again that it doesn’t work. OSS projects have to be driven by either a specific itch (usually) or a business plan (more rarely, but see Canonical and Ubuntu).

Rails is actually an interesting test case for MIT licensing in the large, because it is a big enough system and has achieved sufficient corporate interest that someone could potentially release a forked version with proprietary extensions. E.g. (to pick on Oracle again) an “Oracle Rails” with extra features that enabled special hooks into Oracle DBs. Only time will tell; but I hope (perhaps optimistically) that that era is over, and there is now sufficient appreciation for Open Source values within the IT community that any such attempt would be a non-starter.