Why Copyleft Mozilla Public License is my favorite

I have never been an open source purist or ideologue. It actually wasn’t until ten years ago or so that I really started to engage with and contribute to open source projects. In that time I’ve migrated from being philosophically ambivalent about free and open source software (FOSS) to being a very large proponent of it. Even within that progression I’ve gone from finding the “viral nature” of copyleft licenses to be unfair to feeling that non-copyleft licenses lead to more practical unfairness in many cases. My driving motivation is the essence of fairness combined with believing that humans sharing information as openly as possible is what is best for us all. I optimize that in my own projects by choosing the copyleft Mozilla Public License (MPL) as my go-to open source license. In this post I detail my thoughts behind that.

Why bother with FOSS anyway?

I started my career working for a proprietary software company. I spent most of my career after that building systems for people around mostly proprietary software technology. Today I still use a substantial amount of proprietary software. My mobile devices are all iOS. My fitness trackers are all running proprietary software. So too does my car, my tv, some of my laptops, and some of the analysis products I still use. I say that to put up front that I have never been nor will I ever be a FOSS ideologue or purist. I try to use FOSS when it is reasonably appropriate for me to do so. When developing with Java I use an open-core IntelliJ IDE that I happily pay for the commercial version but I use the open source OpenJDK not proprietary Oracle JDK for my runtime environment. I spend 80-90% of my daily computer time on Linux machines. I am very much looking forward to exploring the fully open source PinePhone, PineTime, and other product, and am already spending time with the fully open source Android-based /e/os. I spend much of my time nowadays contributing to open source projects and almost all the software I write nowadays I open source. So while I have an affinity for FOSS I am not a purist about it. What is it about FOSS that appeals to me?

The biggest aspect of FOSS that I like is that it brings us back to a state of more open sharing of information. There was a time not too long ago where most scientific, engineering, and mathematical information was shared very freely. Of course people played the sandbox game, had secret formulas, etc. but on balance we were about telling the world our findings from which then others would build on. That standing on the shoulders of giants and aggregation of knowledge over the centuries is what brought humans from being like all the other primates to being a global interconnected species that totally dominates the planet (for good and bad of it). Yet in recent times, especially in the realm of engineering and computers, much of the knowledge was siloed away into proprietary systems. There was a lot of money to be made from that. It wasn’t entirely the case though. A lot of the computer languages we have were built in the open. UNIX was source available from day one as a consequence of anti-monopoly concerns Ma Bell had at the time. Many of the foundational technologies of the internet were paid for with government research and therefore had specifications widely available. Lastly, our entire foundation of relational databases came from research published by IBM. So it is not appropriate to say that the pre-FOSS world was entirely closed but there was a tremendous amount of proprietary engineering and software out there. In the end I believe that impeded innovation and growth.

We can see that impedance directly with how explosive the growth in capabilities during the FOSS era compare with the pre-FOSS era. Even back in the pre-FOSS era the open sharing principle backed systems are a substantial location of what drove our innovation, especially with respect to networking and the internet. Imagine an internet where Tim Berners-Lee kept the WorldWideWeb protocol proprietary, all the protocols were owned by IBM and Cisco, no Apache server to host it, and no Linux to run it. That alternate history is not only impossible but actually was more probable. Thankfully it didn’t play out that way. The diversity of the early internet and the technologies it was based on would have been a fraction of what we have and had. It’s growth and the way it changed society would have been drastically reduced too.

One of the reasons the biggest companies in the world continue to fund and promote FOSS is because they see the advantage for everyone, including themselves, in building on that system. In a magic wand ideal world I’d love for all software to be FOSS in a way that we could build sustainable companies of all sizes around it. That isn’t our reality, even today there is a debate of how sustainable FOSS is outside of the orbits of the biggest companies. The alternative though of going back to a mostly proprietary world would I think be worse not better. But it’s not just the altruism of helping us build on the shoulders of giants that draws me to FOSS it also about doing so in a way that I consider to be fair. That’s where choosing the right open source license becomes important.

Licensing Choice Is About Fairness

While FOSS as a general category is good there are various kinds of licenses to choose from. On one end there are permissive licenses, such as MIT, BSD, and Apache, where there are only requirements for things like attribution but not to share the derived work under a compatible FOSS license. On the extreme are the copyleft licenses like GPL where there is a “share alike” principle. That is if you use their software in your distributed derived software work then that too needs to be open sourced and licensed under a compatible terms. The definition of “distribution” is where some even more specifics get into play. Is using it internally distribution? What about hosting it on a web server, like with Software as a Service (SaaS)? What about what you need to make it work in a SaaS, etc. There are impulses on which of these is better which people have legitimate disagreements over. I come to my conclusion on which is best based on what I consider to be fairness of information and effort sharing.

My position on fairness comes mostly from the point of view of a software developer that works as both a creator of libraries and applications and a consumer of open source libraries and applications. If I put a lot of effort into a library I want others to be able to use it. I imagine a student at a university or some one off developer that could benefit from having my library in their application. I want them to be able to do that regardless of if that is private code, commercial code, or open source code that they share with the world as well. Yes my little cog is part of their much larger part and it may even be an integral part of it but that is still just using my cog to build something else. I don’t feel slighted in the least if they have a successful product with my cog somewhere in the middle of it. I feel the same way if it is a huge company like IBM or GM if they solely use my library. While I’d like for them to contribute back other code and resources to open source, maybe even to my library’s project, I don’t feel that it is unfair for them to use it and keep their own code proprietary or under a different license. Where I would feel slighted is if anyone made updates and improvements to my piece of software and then kept all of that for themselves. That would go many times over again for large companies that do this.

What is the difference between if they are building with my cog versus updating my cog? For me it’s very much about the contributions to the piece itself rather than how the piece is being used in other places. The developers and community around the open source library/application put a great deal of time and effort into this so that others could use it. Others who use it but don’t change it aren’t materially advantaged more than anyone else. Yet if these people made improvements to it they then stood on others shoulders yet felt no compunction to give back so others, including the original library developers and community, do the same. To me that feels like a very one sided and unfair relationship. You can hope that they’d do the right thing and give back but as the old saying goes, “hope is not a strategy.” That is where choosing the correct license to achieve the goal of compelling contributions when they change the original library but allowing them the freedom to license their larger derived work how they see fit comes in. With that in mind I can look at the various licenses and determine which is my preference.

First up are the permissive licenses (e.g. Apache, MIT, BSD). While I used to be a huge fan of these they have no share alike provisions at all. Therefore someone is not only free to use a piece of FOSS software in their own derivative work but they are also free to modify and do whatever to the original software and never share those changes back. It certainly is fair to the user of the library in that they aren’t compelled to release their software in ways they may not want. However it violates fairness towards the library developer who then contribute lots of effort into a piece of software that this developer gets value out of but gets absolutely nothing in return. Yes they are compelled to at least acknowledge the use but that’s insufficiently fair to the FOSS library developer in my book. What’s left then are the copyleft licenses which do compel them. However copyleft license can go too far on that front for my liking.

Copyleft licenses have a share alike principle at its core but the details around it vary wildly. The most famous of all copyleft licenses is the GPL. This is the license that is used for lots of very big projects like the Linux kernel. A developer that uses a piece of GPL software even just to call one little function is compelled to license and distribute their own software under the GPL or a compatible license whether they were originally tending to make their project open source or not. This is the “viral nature” of copyleft which people bring up, often in a FUD attempt. While this compels contribution back to the FOSS library’s development I don’t feel it is fair to the user of this library and their project. There could be some rationale of fairness if the library is a huge percentage of the project but there is no such “at least as much” provision, which would probably be difficult to impossible to enforce anyway. Using even the most infinitesimal function or data compels the developer to open source their own project in the same way if they decide to distribute their software. What does the term distribution mean for the derivative work. The details of that is where the variations of GPL come into play.

GPL was written before the internet as we know it existed. Software was therefore always distributed in a very concrete way. Development Shop A gives the software to Development Shop B or a customer who install it and runs it. That was distribution. In the internet age we have things like “Software as a Service” (SaaS) or “Platform as a Service” (PaaS) where distribution is nowhere near clear cut. If I’m letting you use my online editing website did I distribute my software to you or not? The GPL doesn’t really say and most people interpreted such SaaS/PaaS usage as not distributing the software. AGPL makes it explicit that SaaS/PaaS style services count as distribution. That means that if you use FOSS server side software that you then host and serve you must release any modifications you’ve made as well. Recently vendors such as Mongo have taken it a step further with the Server Side Public License (SSPL) which forces providers to open source not only their changes to the software but infrastructure code around it. This is specifically targeting cloud providers who basically re-host Mongo or other software that uses that license. While I understand how they got to where they are this seems to open up cans of worms far in excess of what I think is appropriate.

There is a final category of copyleft licenses which blend some permissiveness with copyleft principles. These are licenses like the “lesser” GPL (LGPL) and the Mozilla Public License (MPL). In both cases if one solely uses the software as a library to build a derivative work then there is no need to license this derivative work with the same license. You can therefore use LGPL or MPL code in commercial software, open source software with permissive licenses, etc. There are two big important differences between the them that makes me choose MPL over LGPL.

The first big difference is the nature of the linking can either be static or dynamic, depending on how you build the derivative work. Static linking basically means it bundles the library code into the derivative work’s library/executable. Dynamic linking means that the derivative work knows about the library’s code and that library is assumed available on the system dynamically at run time. From a fairness perspective I don’t see any distinction between the two. The library is self contained and isolated in both cases. It’s strictly a question of how the derivative work is distributed. With LGPL you can only use dynamic linking to skirt the need to also open source the derivative work under an LGPL compatible license. MPL makes no distinction so statically linked or dynamically linked are treated the same.

The second big difference is that the LGPL is an additional term on the larger GPL which has some other complexities and problems that it will inherit. That includes a term which states that unless it specifically states so that the terms of the license will always be to the latest version, of which the Free Software Foundation has sole control over. MPL is far cleaner and gets around all of that.

It is for all of those reasons that in the last year I’ve switched from choosing LGPL for library projects and AGPL for end user products to solely using MPL for all of my projects and have in fact gone back and started changing the licenses on existing projects.



Picture of Me (Hank)

Categories

Updates (129)
Software Engineering (127)
Journal (119)
Daily Updates (84)
Commentary (74)
Methodology (60)

Archive

2021
2020
2019
2018
2017
2016
2015
2014
2013