Friday, May 30, 2014

Commercializing Open Source Licenses

Nearly a year ago in this blog, I had a post up arguing that Richard Stallman's position on the necessity of using strong copyleft licenses to protect the open source movement was misguided. I'm following that post, now, by explaining that, in fact, not only are strong copyleft licenses inappropriate for certain business cases, but, in others, they are a powerful tool in the monetization of commercial software - where Stallman seems to want to live in a world where copyleft licenses exist only to promote the open source movement as a whole. Let's review:

A "strong" copyleft license is a software license that requires all distributed derivative works of that software to be licensed under the same terms as the original license, which typically includes distribution of source code. E.g. GPL.

A "weak" copyleft license may allow works that are bundled with the original software to be distributed under a different license, as long as the original copyleft software remains unaltered and under the same license. E.G. BSD, MIT, Apache, LGPL (to a lesser extent).

Stallman has argued that unless we all use GPL for all of our libraries, the open source movement will be eaten by the commercial software industry. He is wrong for three sets of reasons:

1. In many circumstances, the GPL is fundamentally incompatible with business needs, and these business needs are simply not going away.
2. The free and open source movement has been shown to co-exist harmoniously with the proprietary, commercial software industry.
3. Strong copyleft licenses have been a powerful tool for the commercialization of proprietary commercial software, under a scheme of dual licensing, totally turning Stallman's vision for the GPL on its head.

(1) Business Needs
If you are distributing software1 that has trade secrets embedded in source code, clearly, a strong copyleft license would be inappropriate, as it would require public disclosure of trade secrets. This could be a trade secret ranging from anything from a financial hedging algorithm or controls of precision machinery, to graphics processing or even your secret fantasy football handicapping scheme. Laying your code bare would give all these secrets away, which, from a trade secret law perspective, would invalidate their standing as trade secrets. This is a big no-no.

Additionally, the terms of the Apple App Store make it very difficult to include GPL licensed software in apps. For instance, the App Store may distribute your software outside of the united states, and the GPL requires that you cannot restrict licenses for GPL licensed software, which includes geographic restrictions. So, if you are distributing software that has export restrictions, either due to technology, agreement, or privacy laws, you find yourself in a very tricky situation. It is navigable with clever engineering and proper lawyering, but it is an enormous headache.

(2) Harmonious Coexistence with Commercial Software
As stated in previous posts, the Ruby on Rails community basically lives off of the MIT, BSD and Ruby licenses, all of which are weak copyleft licenses. This is simply a fact that cannot be disputed. It may be the case that when Stallman first founded the GNU foundation, strong copyleft licenses were a necessity for the success of linux - given the nature of the atmosphere back then, with only a few large companies controlling the balance of commercially viable developers. However, as time has passed, the number of developers has grown tremendously, and they are not all controlled by a handful of old-world corporations. As a result, there are now many totally viable motivations for contributing to open source projects beyond mere legal compulsion to do so - the Apache foundation is an excellent example of this motivation. Quite simply, developers enjoy having access to tools with large user bases, the prestige and reputation of being an open source contributor, which may further a commercial career, and the sense of community that comes with being part of an open source project.

(3) Dual Licensing
Stallman has accepted that while Dual Licensing is legal, he is not a fan. In essence, Dual Licensing, (in certain circumstances called Single Vendor Commercial Open Source Business Model) is where a company may make their proprietary software available under the GPL and also under a commercial, proprietary license. MySQL is an excellent example of the success of this license. It can be thought of as a type of "freemium" model - as long as you are not distributing your software, you are free to use, study and modify GPL licensed software pretty much to your hearts content. This allows for academic use, and purely internal commercial use, e.g., a hedge fund can download MySQL and use it internally, modifying it as much as they want, without worrying about the copyleft provisions. However, if they want to license their hedge-fund approved version of MySQL, but don't want to release their entire codebase to the public, they need to pay Oracle for a commercial license. This is precisely what happened to MySQL, which has very successfully used dual licensing to create a substantial business.

In the end, I think that it is clear that strong copyleft software has a permanent place in commercial applications - but I also believe that at this point, the alternative motivations for contributing to open source software - beyond mere legal compulsion to do so - are more than sufficient to allow for a vibrant weak copyleft open source community to thrive.

However, if you are considering integrating GPL code into your proprietary, commercial software before it ships, I highly suggest you find a very competent lawyer.

No comments:

Post a Comment