Open Source Licenses: When to Use Permissive v. Copyleft

If you work in any industry that heavily relies on software (read: all of them) you will eventually run into open source licenses. So let's take a look at a broad and growing divide between the two main types of open source licenses - copyleft v. permissive. Spoiler: if you are going to be including open source software in client deliverables, it is far easier to stick with permissive licenses, where copyleft licenses should are best used for academic projects, for developer tools or projects that are dedicated to some non-commercial, public good.

Open source licenses were first used in the mid-1980s, under the mantra that "information wants to be free" - not necessarily free in price, but in that it should be freely adaptable to different people's desires. Unsurprisingly, some of the earliest licenses came out of Berkeley and MIT, including the GNU Project, under Richard Stallman. The whole idea was to distribute software that was the result of - and useful for - academic activities, and to do so in such a way that guaranteed no downstream user would be able to co-opt the software and claim ownership over it. Rather, such software would remain available for people anywhere to implement, study, contribute to, etc. As a result, the the idea was to create a recursive license, so that any software built upon software licensed in this way would also be subject to that license. This license would further require that the original software, as well as all derivatives of the original software, would have to be freely distributable and usable without restriction. The license would also provide mechanisms for submitting improvements back to the original software codebase, potentially to be included with later releases. The first such license was the GNU GPL license, which set the whole open source phenomenon.

The requirements described above - that all derivative software and contributions be licensed under the original license, that source code be freely available, that there be a mechanism for contributing improvements back to the original codebase - form what is generally termed a "copyleft" license - so called for its difference from copyright, which typically locks up ownership and use.

The outcome of the combination of the above features is often (derogatorily) called the "viral effect": an entire code base may get 'infected' if a single LGPL component is included - meaning that all software that ships with an LGPL component may be subject to the above terms.

As a result, it shouldn't be that hard to see why using a true copyleft license in commercial software is sometimes untenable: granting access to source code necessarily means giving up claims to trade secrets embodied in that source code. Additionally, the right to re-distribute covered software is automatically granted to any recipient of copyleft licensed software. This can make commercialization tricky - not impossible, but tricky - because any recipient of copyleft licensed software can turn around and resell that software, or even give it away for free. Finally, there are still gray areas in interpretations of the L/GPL regarding how it applies differently to interpreted code as opposed to compiled code.

Contrast these licenses with the so-called "permissive," such as the MIT and BSD: these licenses essentially only require that any software licensed under their terms includes an acknowledgment of prior authors, and they otherwise disclaim all warranties, restrictions and obligations. In addition, they are far, far simpler licenses: the MIT license is literally three sentences long, while the LGPL runs more than a few pages. To be fair, there are still unresolved issues about permissive licenses, such as how BSD interacts with hardware licensing, but by and large, the interpretation and use cases of permissive licenses are far less complicated than copyleft licenses.

The upshot of all this is that as more and more open source code gets built into commercial applications, we are seeing more and more open source code released on BSD and MIT licenses, and less on GPL and LGPL. Say what you will about the philosophy of the movement itself: I believe this is the inevitable outcome of the way that copyleft was originally designed.

Conclusion: If you are going to be integrating open source components into code that you intend to commercialize, it's probably safest to stick with permissively licensed components. If you are contributing to developer tools, utilities, mathematical libraries, projects for the public good, academic work, or the like, L/GPL may be more appropriate. Either way, you should probably consult your attorney.


Popular posts from this blog

The Most Important Bitcoin News of the Week: SEC Statement

Why Stack Overflow Doesn’t Care About Ad Blockers – Stack Overflow Blog – A destination for all things related to development at Stack Overflow

“Huge” number of Mac apps vulnerable to hijacking, and a fix is elusive | Ars Technica