Why Dash uses the MIT license (and NOT a copyleft GPL license)

This article is originally published at https://moderndata.plot.ly

Is GPL software overly restrictive? 

Software licensing can be a personal or philosophical choice, and we’re not looking to incite controversy. But, we do want to examine why more and more developers are opting for permissive licensing. 

At Plotly, we offer our flagship open-source software through the MIT license. Why? It’s simple: we want to provide developers with the intellectual freedom to share their contributions in whatever manner they see fit. If they work hard on a Dash project, they should be able to freely share their insight without any worry of legal repercussions.

Let’s take a step back and learn about these types of licenses.

What is GPL software and what is Permissive software?

Before a developer actually creates something that you can use, they create source code. The source code is generally transformed into an  “executable” file that developers can run on their own computer or smartphone. That’s the end product.

Generally speaking, developers can distribute software in one of two ways. There’s a third way which we get to later. 

The first is “proprietary” where a company pays a developer to create code that’s totally private to that company. The company ships off the product (the executable file). Microsoft, Apple, and Adobe all typically produce software in this manner (along with other types). 

Another approach to software development is termed “open source.” With this model, developers ship the final product to the user with the source code.  The end user must abide by a set of conditions called the “license.”

With open source software, there are two main types of licenses: 

The first is called the GNU General Public License (the GPL). You can run, change, ship, and commercialize the distribution of software licensed under the GPL. But, you must reveal the changes that you made to the source code to whomever you ship the product to. It’s like paying respect to the past developers who worked on the piece of software.

As Android Authority’s Gary Sims said, the GPL is like a social contract: “Freely you have received, and freely you must give.”

If a developer writes a million lines of code for a project and then incorporates even a few lines of GPL-licensed code, then all the code must be revealed under the GPL. The developer can’t mix their own proprietary software and GPL software together. This is precisely why the GPL has drawn the ire of many professional developers. 

In fact, former Microsoft CEO Steve Ballmer famously said that the Linux operating system (which is licensed under GPLv2) was “like cancer” because everything it touched was infected. 

The second type of license are “permissive” licenses, like BSD (Berkeley Software Distribution), MIT (Massachusetts Institute of Technology) and Apache licenses. These licenses are less restrictive when it comes to  the release of source code. 

For the BSD license in particular, the only condition is that if a developer ships a product using BSD, they must include a disclaimer equivalent to, “Yes, I used this person’s BSD-licensed work and I modified it.” They do not need to reveal their proprietary work, rather only acknowledge using another person’s BSD-licensed work. 

Permissive software licenses are now more popular than GPL or “copyleft” licenses. According to Sims, BSD is included in Mac OS, iOS as well as many well-known projects used with the Android operating system. Google intentionally chose the Apache 2.0 license for Android so people can build stuff on top of it while not revealing their source code. 

Before we go further, we should note that GPL licenses control the mechanism by which other individuals may reproduce all or part of the licensed work. Thus, they restrict distribution. 

But if all they want to do is use GPL-licensed code for their own project and never ship it out to anyone, then they don’t have to reveal their source code. It’s only when they want to share or “reproduce” their end product that they must abide by the GPL’s rules. 

Enter the AGPL 

The original iteration of the GPL license was unveiled in 1989. The second iteration, GPLv2, came out two years later  in 1991. By the time GPLv3 came out in 2007, a lot had changed in the ways that companies were distributing software. 

The GNU Affero General Public License (AGPL) came out in 2008, as a response to some of those changes. 

Companies had started shifting towards the aforementioned “third way” of selling software, software-as-a-service (SaaS) rather than products. It meant that big companies were circumventing the GPL’s distribution requirement. Technically, they weren’t distributing anything, but they also weren’t sharing their changes. Unlike a Desktop application, when someone opens the website of a SaaS product (like Gmail), they aren’t downloading all of the code that runs on that company’s servers. This flustered many within the open source community.  

“The free software advocates said ‘we’re going to plug that loophole’,” Heather Meeker, a partner at Silicon Valley law firm O’Melveny, told Plotly. Meeker specializes in IP and Copyright law. 

Rather than a distribution-style license, AGPL is considered an “end user license.” 

Let’s say you use AGPL-licensed code on your backend server but you never distribute your software to an end user. The AGPL license dictates that you must still reveal your source code changes to the users. 

There’s a good reason for that: the AGPL treats SaaS deployment as if someone is distributing software, said Meeker.

“And that’s why a lot of companies won’t use code under that license because now they don’t just have to worry about code they’re distributing,” said Meeker. “Now they have to worry about code they’re actually just using, and a lot of companies just don’t have the compliance infrastructure to do that.”
Partly because of this, veteran tech columnist Matt Asay called the AGPL “toxic and unpopular”. Asay said that the AGPL is absolutely not free in any meaningful sense for developers.

The GPL: “Like a cell phone plan that you can never leave”

It has always been true that for integration with proprietary licensing, more permissive licenses like Apache, MIT and BSD are more popular than GPL licenses, wrote Claburn.

To some supporters of permissive licenses, GPL licensing restrictions can seem like it’s not a “free” license at all. Rather it’s a milder set of conditions than a proprietary, copyrighted piece of software. GPL advocates, on the other hand, might argue that GPL is “more free” because it guarantees perpetual freedom through all mutations of the software.

“In the worst-case scenario, you may be required to release your proprietary software under the same license—royalty-free,” writes Synopses, the publicly-traded Silicon Valley-based electronic design automation company.

3D Robotics CEO Chris Anderson went as far as saying that GPLv3, the most recent iteration of the GPL that came out in 2007, is “toxic for business”. 

“It discourages companies from using it because it can infect everything else with this force to expose your IP,” said Anderson. 

Patricia Johnson, an open source licensing and security expert at WhiteSource, wrote that the GPL is a “complete no-go for larger organizations”. 

“They can’t afford the risk of GPL-licensed code getting into their products, so virtually all medium-large companies have clauses explicitly banning GPL-licensed code,” Johnson wrote. 

“If you want maximum adoption you use a permissive license,” said Meeker. “There’s no doubt about that.”

Moving in a modern, permissive direction

Shane Curcuru, an open source consultant, told a crowd at OSCON 2015 that the GPL is “kind of like a cell phone plan that you can never leave.” Once you use it, you’re always stuck with it. 

He noted the gradual creation of the broad array of open source programs at developers’ disposals has served as a catalyst for the rescinding popularity in the GPL. 

“The issue is that with any sort of belief system that makes everyone follow the same exact rules, that’s kind of hard for a lot of people to accept,” he said. “It’s so easy to start new projects, people don’t want to have as many as the restraints of copyleft licensing”.

GPL vs Permissive licenses: what does the data tell us?

Now that open source is mainstream, Curcuru argues that licenses like the GPL actually hinder many modern business models from profiting as much. 

It’s simple, he said. Permissive licenses allow many more business models to work. And people simply aren’t going to be as interested in sharing their GPL code anymore. 

“I believe in the modern world we don’t need the strings of the GPL anymore,” he said.

The data seems to back up these claims. 

According to a 2012 study by Donnie Berkholz, a Red Monk analyst, developers have been shying away from GPL and towards permissive licenses since as early as 2004. 

Since 2010, “this trend has reached a point where permissive is more likely than copyleft [GPL] for a new open-source project,” said Berkholz, using data from Ohloh, an open-source code research project now known as Open Hub. 

By 2012, wrote Claburn, 59 percent of projects used copyleft licenses (the family of licenses which GPL is part of) while permissive licenses accompanied just 41 per cent.

This was part of WhiteSource’s analysis of some four million open-source packages and 130 million open-source files in over 200 different programming languages.

By 2019, 33 percent of the software in the WhiteSource data set relied on copyleft licenses while 67 percent of the software favored a permissive open-source license.

WhiteSource concluded that “use of permissive open-source licenses continues to rise, while usage of copyleft licenses, and the GPL-family in particular, continues to decrease.”

Tools for R developers: Are AGPL-licensed tools still worth the trouble?

Once upon a time, in the 1990s, the GPL was quite useful. But times have changed. In today’s network connected world, R developers, researchers, and scientists need software that is unambiguously “no strings attached.” 

The question remains for R developers: is AGPL-licensed software worth the trouble when there are permissively licensed equivalents? 

One popular R software tool, Shiny, licenses its package as a whole under GPLv3, but the server (which one needs to run its apps) is licensed under the AGPL. 

So why would a company license their product under AGPL if they want people to actually use it?

Meeker offered up one possibility, likening the GPL and AGPL bundle to companies selling software through a freemium model.

“Sometimes companies release software under a scary open source license like AGPL and then they sell exceptions to it. So they say, here, our stuff is under AGPL, but if you don’t want to abide by that license, we’ll sell you a commercial license. It’s a model called dual-licensing and AGPL is the license of choice for that model now, because it is the scariest approved open source license there is at this point.”

“It can yield a lot of license revenue,” said Meeker. 

Plotly’s Dash: the MIT-licensed Python Standard

Needless to say, we don’t think there’s anything scary about Dash. When developer’s use Dash and its permissive MIT license, they can put it on the internet without sharing app source code with anyone and not worry about a thing. 

Here’s a license summary for some of the most popular “open-source” data science projects, including the ones mentioned in this article:

Having fun with Dash? Deploy your open-source Dash apps on Dash Enterprise—the leading PaaS for productionizing AI and advanced analytics. Contact us directly at https://plotly.com/contact-us

Thanks for visiting r-craft.org
This article is originally published at https://moderndata.plot.ly
Please visit source website for post related comments.