It’s been decades, and we still can’t help but talk about open source licensing. RedMonk analyst Steven O’Grady is sick of writing about licensing, but we’re apparently not sick of reading about it. And yet the “correct” answer for any would-be open source project lead is relatively simple: the license you choose determines “the kind of community that you’re going to build,” according to Hassy Veldstra, founder of open source load testing tool Artillery.io. He detailed why Artillery chose the Mozilla Public License (MPL) version 2, and the different paths open to open source projects.

Too restrictive, and no one will show up. Too permissive, and competitors may “borrow” your value. What to do?

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

Why licensing is “extremely important”

Some of us may be tired of rehashing open source licensing debates, but the topic is “extremely important,” said Veldstra. Why? Because “the license that you pick will end up affecting the kinds of use cases that software will be used for and the kind of community that you’re going to build.”

How so?

“Artillery has a third-party community of plug-ins and extensions,” Veldstra noted, in significant part because it uses a permissive license (the MPL). But not Apache/BSD-levels of permissiveness: While it’s important to encourage developers to build, he noted, “You want to pick a license that encourages contributions back to the source.” You need balance, in other words, between developer freedom and encouragement to give back.

At one end of the spectrum, he continued, you have the GNU General Public License, or GPL. “Anyone who modifies your software [and distributes it] will have to contribute back.” This is great from the “encourage to contribute back” perspective, but “in a lot of environments, the GPL is outright banned, which by definition would restrict the kinds of contributions you get.” So, for example, Google restricts use of Affero GPL code because “The license places restrictions on software used over a network which are extremely difficult for Google to comply with.” 

By contrast, with a highly permissive BSD license, he went on, “You have the ultimate freedom. You can do whatever you want with the software.” This would be great except, “Companies aren’t incentivized to contribute back in the same way” as with the GPL.

For Artillery, it was important to find middle ground between these two licensing philosophies. Because of its use of the MPL, he said, Artillery attracts “contributions from employees of some big corporations…because they know that they can build on top of Artillery without infecting the rest of their code base….So you get this really nice and clean separation.” This separation has resulted in a budding community growing up around Artillery with dozens of external contributors and an expanding portfolio of third-party libraries/extensions. 

So that’s great for building community. But how does Artillery protect itself from free riders?

Are you doing something wrong?

“It’s very, very easy to imagine the worst case scenario,” Veldstra suggested. “You build something, and this big, evil cloud vendor comes along and just steals your work.” That sounds bad, right? “In practical terms, that’s extremely unlikely to happen. And we don’t really have good examples of that,” he concluded. 

But he goes further, arguing that potential competition on a project helps to feed its community. “[H]aving] someone else launch a service based on that project does not necessarily spell the end of the community, quite the opposite.” Why? Because “There will be an influx of new users and new contributors to the open source project.” Even if this doesn’t prove true, he went on, “If the whole premise of a commercial product built on top of an open source product is that someone else cannot launch a competing service, then really you shouldn’t be in a business in the first place. If someone can [just] take your code and kill off your business by launching a competing service, then you’re doing something wrong somewhere else.”

For Artillery, the company, that means building proprietary value on top of the open source code in a traditional “open core” model. “If your only value [is hosting open source software], then good luck to you. Your business isn’t going to be around for a very long time. There has to be significant innovation on top of it that customers are willing to pay for.” 

Whether you agree or disagree, Veldstra is almost certainly correct that striking the right balance in licensing will help shape an open source project’s destiny. 

Disclosure: I work for AWS, but the views expressed herein are mine.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see