Just When I Had It All Figured Out

Every four years, the fall sport becomes following U.S. presidential politics. As any sports fan knows, you have to know the lingo to understand the talking heads. I take politics seriously, so after hearing the expressions “red-state” and “blue-state,” I did my research and learned that red is the color of Republican leaning states and blue is the color of Democratic leaning states.

After that, I was confident I could follow the fast pace of the game and read the maps. However, just when I had it figured out, on Election Day the television news channels started using green! I had to turn off the television and get back to thinking about open- source licensing.

I had worked through the ins and outs of the applicability of the constraints and implications of various common free and open-source licenses. But then, when tweaking the source of a Mozilla extension, I came across the “tri-license.” Wasn’t it complicated enough already?

Highlights of the Tri-License

The tri-license is the preferred license for mozilla.org. This license is also referred to as the “MPL/GPL/LGPL triple license.” Ostensibly, this license was created for compatibility between the MPL (Mozilla Public License) and the GPL/LGPL (General Public License and Lesser General Public License).

The tri-license can be applied file by file, rather than work-by-work, as is the case with the GPL. Rather than simply licensing a particular file of source code under the MPL, the GPL or the LGPL, the tri-license is a grant to downstream users that gives them the right to copy and redistribute the licensed source code, but it also gives them a choice as to the type of license they can use for modifications.

The GPL requires that downstream licensors use nothing more restrictive than the GPL. The MPL allows for combination of MPL-licensed code and code under other licenses that can be more restrictive. With the tri-license, a contributor who modifies the tri-licensed code can choose to leave the tri-license in place, giving others downstream from that contributor the right to choose the GPL.

Evolution of More Complex Species

A basic copyright license deals with the interface between the copyright holder and the recipient of a copy. Where a copyright holder doesn’t care what happens next, that is sufficient.

The next stage of evolution was the realization that free software propagates so just dealing with the first interaction was not enough. In order to reach his goal of “free software” abundance, Richard Stallman included copyleft features in the GPL that focus on the actions of downstream recipients.

Another consequence of the unfettered propagation allowed by GPL-ed software was that licenses could not be easily updated. For the first link from copyright holder to the first recipient, a license could be updated to grant further rights by the copyright holder simply issuing another license. That is not so simple with GPL-ed software, since the software propagates, others might have contributed, etc.

The current version of the GPL deals with this nicely, by specifying that a licensor could choose to license using the current license or any later license. This in itself is unusual, as it is an agreement between two parties where the agreement is not fully specified and the specification is left to an independent party (the FSF, in this case).

Kudos for Pulling This Off

Now, with the tri-license, an even more complex species exists, wherein a downstream user can choose the license they are licensed under and can also choose which license to apply to downstream recipients. Thus, some could create a derivative work from the Mozilla code and redistribute the derivative work under the tri-license, someone else could obtain that derivative work and modify it further and change from a tri-license to a GPL or LGPL only license.

This would be done, for example, where a derivative work creator wanted to ensure that his or her contribution has to be redistributed in source code form and could not be combined with proprietary code.

The uncontrollable propagation of software does make it difficult to take licenses back, even when it is to provide a more flexible license downstream. The Mozilla Foundation spent two years tracking down all of the almost 450 contributors to the Mozilla code base and earlier this year completed the task of contacting each of them to get them to agree to relicense their contribution using the tri-license. That wasn’t the end of it. They then had to figure out an automated way to accurately change all of the source code to reflect the new license.

Code base managers need to be aware of the evolution of licensing techniques before the code base comes into being. It is not enough to work out what license to use. Now, a code base manager also needs to take into account what licenses downstream users might use or want and how to constrain or unconstrain downstream users. Instead of just worrying about how best to propagate code updates, they need to worry about the possibility of license updates and how to propagate them.

Of course, there is always a limit to practical advice when it comes to anticipating evolution, because while change and increasing complexity are certain, the direction of change cannot always be predicted.