I am a huge fan of open source development. From the developer side of things, it means there are limitless tools at my disposal for creating the next knock-your-socks off application. I can build just about anything with insanely powerful libraries of code that the big guys like Microsoft can't touch. It's an amazing power, and one that's attracted more than a few good developers.
From the consumer side, it means I have the luxury of verifying that the application I install that claims to do X actually does X and not something malicious - I can look at the source code, change it if I want, and go about my business. This has saved my bacon several times when an off-the-shelf solution didn't actually work on my machine. I just cracked the hood, fixed a couple of things here and there, and viola! It worked like new!
The trick to open source development is licensing. You have to pick what's called a "copyleft" license to protect your code. Basically, it's a way of stamping your name on a product, drafting a bill of rights for your customers, and legally requiring them to pass those same rights on to anyone they happen to give the code to. One of the most popular modern licenses that does this is the GNU General Public License.
Until recently, I was in love with the GPL. I learned about it by developing for WordPress, and proceeded to slap it on just about everything I wrote. This made it really easy to keep all my development on track, because I didn't have to worry about which license applied to which piece of code (all of the projects I was submitting code to were also GPL).
But I've stumbled upon a few things recently that make me regret that decision ...
License Ambiguity
First of all, the GPL is only "compatible" with certain other licenses. And it's viral. Meaning that if you have one piece of GPL code in your application, the entire application must be licensed with a compatible license - you must extend the same rights to the code for the entire application that are extended to that piece of code.
On the surface, this seems pretty innocuous. But there are some major hang-ups involved. WordPress, for example, is licensed somewhat ambiguously. The license statement originally claimed WordPress was licensed under "GPL" ... with no version number specified (there are 3 versions of the GPL available, with multiple derivations, too). But some code that makes up the WordPress core is explicitly licensed as GPLv2. Some code is licensed as GPLv2 "or any later version." The confusion over which parts of the code carry which license terms led some (myself included) to believe the entire codebase was licensed as GPLv2.
The problem here is that most of the code I have written over the past 3 years is licensed as GPLv3 ... I like to use the latest version of everything, so this was pretty automatic. Other authors did the same, adopting GPLv3 for their libraries, submitting them to the WordPress plug-in repository, distributing them on Google Code, or hosting on their own website.
The thing is: GPLv3 is not compatible with GPLv2.
So even though we were trying to be good open source contributers, we were actually violating our own license terms. By writing code for WordPress, claiming it was licensed as GPLv2, then using that code in GPLv3-licensed plug-ins we were infringing on the terms of our own licenses. Ironically, this would be like stealing your own car by accident. Or mistakenly breaking in to your own house.
Needless to say, the arguments over which version of the GPL WordPress is actually licensed under is endless. We've debated until everyone's frustrated, upset, sad, scared, and spending more time studying legal precedent than actually writing code. It's a shame, really, when I think about the awesome features that could have been built into WordPress during the countless hours we spent arguing over a stupid version number.
But if we aren't clear on that version number, we can end up destroying any legitimate claims we have against real license violations. If we don't follow our own licensing terms, we can't enforce them on anyone else.
If nothing else, the GPL is aimlessly confusing and seems almost intentionally ambiguous.
Viral Licensing
We've already said that the GPL is a viral license. This means any work that derives from or requires a GPL-licensed code to function must be licensed by the GPL or another compatible license. Like I said, it sounds like a good idea ... but can be fatal to a project in practice.
Let's say you're developing a web application for the financial sector. You need to encrypt data and transfer it securely. As we all know, no encryption is 100% secure and no digital communication is impervious to attack. Eventually, someone will be able to break through. So you keep your client-side code and server-side code as closed as possible - you don't hire outside firms to write sensitive scripts and you keep all of your data processing in-house on on your own machines.
Now you've decided to create a mobile version of your popular web app. So you look around for some available tools to make the job easier and stumble upon a JavaScript library called Sencha Touch. It looks great, has fantastic support for iPhones (the majority of your market), includes fantastic graphing libraries, and is distributed as open source. You download the library, load it on your server (you're a savvy developer and send all of your JavaScript in a minified form), and start pointing customers to your mobile app.
Oops.
Sencha Touch is licensed under the GPL. According to their license terms (and the company representative I spoke with), any application that incorporates or links to their JavaScript must also be licensed under the GPL. This means any JavaScript you use to communicate with Sencha must be open source. Not too bad ... unless your server-side code generates any of the JavaScript dynamically at runtime ... then it too must be licensed under the GPL. So must any of the code that you use to minify your JavaScript. And any code on the server that talks to that.
Unless you've spent extra time making sure your web application is 100% decoupled (we all aim for that, but everyone slips up from time to time), then your entire web application must be licensed under the GPL. That means anyone who uses your website can request a copy of the full source code, and you have to give it to them.
So any security-by-obscurity you used in your application is out the window. Your encryption algorithms are in the public eye. And that other bank down the street can see exactly how you built that cool new feature everyone's talking about.
There is a commercial license available for Sencha Touch, but it's in beta ... and prohibitively expensive for small shops like mine. Which means I have three options:
- Suck it up and open source my entire application (not feasible for security purposes)
- Buy a commercial license for the library (as I said, prohibitively expensive)
- Build my own JavaScript library from scratch to replicate the functionality
It's hard to empathize when it comes to financial software - it exists to turn a profit, and that's the entire reason licenses like the GPL exist - to give the "little guys" a leg up on larger players like Microsoft. But I also work with medical software which, again, is necessarily closed-source for security reasons, personal privacy reasons, and legal compliance reasons. If I were to use a GPL-licensed library in any of my code, and someone with ill intent asked for a copy of my code, I would be legally required to give it to them ... and be putting all of my customers at risk at the same time.
In Conclusion
Yes, the GPL is a good idea. It's aim is to protect small-time developers and give the open source community sets of tools the big players in the market (Microsoft & Apple) can't touch unless they're willing to play on the same level. At the same time, it's overly ambiguous in its terms and inherently dangerous to certain industries where privacy of code is a necessity.
It's easy to get wrapped up in writing GPL-compliant code. So much so, that you almost forget the fact that there are other permissive, copyleft licenses available. I've been using the X11 (aka MIT) license for much of my latest code. It permits the recipient of the code (anyone who downloads it from my site) to use the code in anyway they want ... they just have to leave my copyright notice in the header. My name still gets used in public, freelancers can use my code in their projects, and it's still free to use and free to edit. Without the painful overhead of a 3-page license, weeks of arguments between developers, and the potential to rip apart secure systems.