In the past week, the Internet has been buzzing about WordPress co-Founder Matt Mullenweg’s accusation surrounding Wix’s apparent code theft.
Cut long story short, Wix decided to use an open source project for their new product, which was previously released by Automattic (the company behind WordPress). Fast forward four and a half months, Mullenweg comes out all guns blazing, claiming Wix had not complied with the terms under which their open source project was licensed. What was this license, you may ask. Well, as you might have guessed, it was the famous (or infamous) GNU GPL v2.
Wix had just launched their Wix App which allows users to handle their Wix operating systems and websites, all from their smartphones. Nothing to get excited about yet. Things started to go awry when Mullenweg downloaded the App and felt a sense of a déjà vu. Automattic did some research and found out that Wix used Automattic’s GPL’d Rich Text Editor project in their app, then open sourced the modified and updated version (but not the complete app) on GitHub under the permissive MIT license.
On October 28th Mullenweg blasts Wix, Auotmattic’s main competitor, of “blatant rip-off and code theft”. He argued that when integrating and distributing GPL’d code “it doesn’t matter if it’s 30 lines or 30 million lines: because it includes GPL code and you distributed the app, the entire thing needs to be GPL.”
This assertion makes us focus on a central question. If you modify and distribute a GPL’d component, just how far does GPL’s effect reach into your software?
Before diving into the central question here of just how far does GPL’s effect reach into your software, let’s have a brief reminder of what the family of GPL licenses is all about.
The GPL is a copyleft license (a play on the word copyright), also called a viral license. This means regardless of the amount of GPL’d components you use in your code, you have to release its source code, as well as the rights to modify and distribute the entire code. Furthermore, according to the GPL family of licenses, you also need to release the source code under the same GPL license (hence the name viral license).
However, the point which causes many debates is exactly how much of your software do you need to release as open source under the GPL license. The GPL v2 requires you to share the code of all ‘derivative work’. Yet what exactly does the term ‘derivative work’ mean? Well, some companies out there choose to interpret this term more loosely than others.
So now back to Mullenweg’s accusation that Wix failed to read the open source small print.
To be honest, unlike a lot of companies out there, Wix had a good understanding of the open source components it was using, and their license requirements. After all, they submitted back to GitHub, and attributed Automattic for supplying the original source code.
Wix developer Kol’s shout out to Automattic
The problem started when Wix released their modified version under the MIT license and not the GPL one. By the way, Wix has already relicensed the version under the GPLv2 after Mullenweg’s post release. In addition, Mullenweg also made a general claim (with no details) that they should have released their entire app as open source, instead of just the modified version.
However, another thought comes to mind after reading Tal Kol’s post, Wix’s ex-developer who actually added the code. And that is, Wix could have avoided this entire issue altogether by using the MIT licensed ZSS Rich Text Editor, which therefore places minimal restrictions on developers, rather than using WordPress’ later GPL’d Rich Text component version.
But did Wix really deserve all the bad press it’s been receiving over the past few days?
Now, truth being said, I don’t think the outcome of the Wix-WordPress dispute is all that important. I’m sure Automattic and Wix will find a way to settle things among themselves without having to lawyer up. What does bother me is that it is this type of news story which makes CEOs or legal counsels come out and define a ‘no GPL license’ rule for their company. Or even worse, a ‘no open source rule’. Although to be honest, I can’t imagine software development teams not using open source components in their software in 2016.
There are already so many false assumptions surrounding the use of open source in the software development world. Many CEOs, CTOs and even developers out there are afraid to use open source in their software due to the requirements placed on them, by GPL licenses in particular. However, this fear usually doesn’t just apply to GPL’d components, but all open source licensed components. Yet, by refusing to use open source components in their software, organizations are passing up significant software development and commercial benefits.
Due to the wealth of tried and tested code on offer, open source has been the force behind the speed and growth of technological innovation over the past ten years. For rather than having to reinvent the wheel by writing code for generic functions every time developers build new products, they can instead focus on developing functionalities which push their software products to the bleeding edge. There’s no point throwing away all of these benefits away just for the sake of misplaced fear.
Open Source Is Our Friend
The bottom line is open source is great and it really can’t be passed up if you’re looking to develop quality software at speed. You just need take responsibility for your usage. This means tracking what components you’re using, managing them correctly and being aware of any license requirements which you may be under.
With all this in mind, open source is something to be embraced with open arms rather than be scared of.