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.
The concept of copyleft seems to be wonderful in theory: it subverts the (arguably broken and archaic) copyright system of protecting intellectual property into a system that requires that information (specifically source code) be freely available, modifiable, and transferrable infinitely. In an ideal world, this leads to companies openly exchanging and contributing to each other's source code, making improvements that the community as a whole can share and defeats the lock-in of proprietary system code. The GNU General Public License (GPL) is the most well-known example of a so-called "copyleft" license and it requires, among other things, that any project which utilizes GPL code that is released must, itself, be released under the GPL.
The First Problem: Rockets vs. Rubber Bands
The GPL truly is a powerful and useful tool in the correct circumstances. The archetypical example of the GPL, namely Linux, is (I believe) greatly helped by the "required openness" of a copyleft license. No doubt for many large-scale, traditional software distribution projects the same can be said. There are a few reasons for this:
- It is an incredibly large, complex project to which most people do not have the knowledge or ability to contribute.
- It fits a traditional software distribution model (i.e. installable, distributed as a discrete package).
- It is so all-encompassing that it is extremely unlikely to be used as a "small part" of a larger project. Any fork of the Linux code is likely to be useful to a large part of the Linux community.
In essence, Linux is like a community-built rocket ship. It's large, has lots of knowledge and moving parts behind the scenes, and accomplishes a very difficult task that very few people are able to solve quickly or efficiently by themselves Additionally, someone could easily take the "open" blueprints for that rocket ship, make a few minor proprietary improvements, and directly sell the result making a profit off of the hard work of others.
Now let's imagine that the community came together and built a rubber band (licensed somehow under the GPL). They didn't use any special tools or processes, and it would be easy enough to rebuild the plans for the rubber band from scratch. Let's say I'm creating an incredibly complex machine that can turn aluminum into gold but needs a couple rubber bands to function. I'm going to look at the community-built rubber band and think "hey, that would save me some time". Maybe I even have a few ideas for how to make the rubber band better that I'd be willing to try out and contribute back. I get excited, maybe even start tinkering with the plans for the rubber band. Then I stop.
Wait a minute, I think, if I use this rubber band, this tiny insignificant piece of my much larger brilliant machine I will be obligated to share the blueprints for my gold-making machine whenever I sell it. Ha! I don't think so. I'll just build my own rubber band instead. It will take a little bit longer, but that's nothing compared to what I'll lose by having to share my blueprints with the world.
I've never built an open-source project so large or complex that someone else, given a little time and elbow grease, couldn't work out a similar solution in a reasonable amount of time. I mostly build small open-source libraries for Ruby many of which I completed the first version in a day or less. I like to think that I'm clever and perhaps think of a few neat tricks that would be inconvenient to live without, but I'm under no illusions. Most people in my industry could recreate my work quickly and in a straightforward manner. So how do I get people to contribute? It isn't going to be by using the GPL…people will say "screw it" and build their own version of my library that they can use without worrying about overly cumbersome licenses. No, I get people to contribute by giving it away as completely as possible (I use the MIT license, but also like the WTFPL) and asking them to contribute interesting stuff back. And you know what? It happens.
Any project I've built that has been even remotely successful has received plenty of support, patches, and help from the community. No one is required to do any of this. So why does it happen? It happens for two reasons:
- Everyone benefits from having battle-tested libraries. It's much more sane to make a patch to an existing library than go into proprietary land where the only person you can ask for help is yourself.
- GitHub. GitHub makes it so insanely, ridiculously easy to manage and make community contributions that contributing a patch is pretty much exactly as easy as writing a patch.
Copyleft licenses are simply not necessary for the vibrancy of the open-source community when it comes to simple libraries and, in fact, are more likely to hinder the community by encouraging the creation of multiple libraries to accomplish the same thing simply to avoid the requirements of a license like the GPL.
The Second Problem: The Groan Factor
A few months ago the Diaspora Project released its source code. While I was skeptical about the code quality and the project as a whole, I thought it might have the potential to be a real force for openness in the social networking community. Then I saw that it was licensed under the Affero GPL, and I groaned. My exact words, as posted to Present.ly that day, were:
Diaspora is AGPL, eh? Well that ENSURES that no one will ever, ever use it.
The Affero GPL is a variant of the GPL specifically designed to address software that runs on network servers (such as web applications). It requires that any server running the software (or a modified version thereof) must make available the full source code of any modifications. This is, as far as I'm concerned, a complete and total block of any usefulness the Diaspora project could have had.
Diaspora is purportedly about decentralizing the social networking space, making it so that a vast array of disparate, smaller social networks can all talk to each other. Ideally (I would imagine) the creators imagine it being adopted by companies big and small. There's just one problem. No one is ever going to build anything on top of Diaspora if any competitive advantage they might try to add (enhanced UI, additional domain-specific features) is going to have to be open-sourced as well. The license is an anchor around the project's neck, and I doubt it will ever see much adoption outside of an extremely small niche.
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.
This is a single but indicative example of the "groan factor" inherent with copyleft licenses. The more restrictive, the more cumbersome the open-source license is on a project, the less chance it is going to have of gaining widespread adoption. It is so easy to contribute to open-source projects these days, and is seen as a badge of pride by companies large and small. Sure, there are exceptions and there will be abuses, but by and large the community is better served by taking a pragmatic, practical approach to engendering community-driven development.
Frankie Says Relax
So what's the takeaway from all of this? The answer certainly isn't to do away with the GPL and all copyleft licenses. They have a very specific, very useful place in the community. However, an adjustment that I do think needs to be made is assuming that the GPL is the "default correct" choice for an open-source license. Just because it was the first doesn't mean its the best fit for most projects. I think that a more permissive license (such as MIT) should be the mindshare "default" and GPL is only used in situations where the copyleft restrictions will help, not hinder, the contributing community. The Ruby community (for one) has largely embraced this, and just about the only time I see GPL'ed Ruby code is when a company unaccustomed to releasing Ruby code builds a gem or when a native library a gem utilizes is under the GPL. It's one of the things that makes me happy to be a Rubyist.
Rather than fighting the problems in the copyright system by using it against itself, how about we fight it by taking away its power? Permissive licenses are a truly free way to share code because they recognize that it doesn't always make sense to open-source a derivative project. So the next time you're throwing that LICENSE file in your open-source project, think twice before you "just go with the GPL, I guess".
