The fall of GPL and the rise of permissive open-source licenses

Via ZDNet

-----

I know very few open-source programmers, no matter how skilled they may with the intricacies of C++, who relish learning about the ins and outs of open-source licenses. I can't blame them. Like it or not, though, picking an open-source license is a necessity.

The Open Source Initiative has long provided vital open-source licensing reference information, but it still left programmers more puzzled than informed. Lately, OSI-related sites, such as Choose a License and the open-source license FAQ on GitHub, have made it easier, but some programmers haven't been bothering with any license at all.

Idiots.

Things have improved a little. In July 2013 when Black Duck Software found that 77 percent of projects on GitHub have no declared license. Earlier that year Aaron Williamson, senior staff counsel at the Software Freedom Law Center, discovered that 85.1 percent of GitHub programs had no license.

In 2014, many GitHub programmers, using arguably the most popular code hosting system in the world, still don't use any license at all.

That's a big mistake. If you don't have a license, you're leaving the door open for people to fool with your code. You may think that's just fine... just like the poor sods did who used a permissive Creative Common license for "their" photographs that they'd stored on Yahoo's Flikr only to discover that Yahoo had started to sell prints of their photos ... and keeping all the money.

Maybe you're cool with that. I'm not.

Now, as Stephen O'Grady, co-founder of Red Monk, a major research group, has observed, as software is shifting to being used more in a service mode rather than deployed, you may not need to protect your code with a more restrictive license such as the GPLv3 since "if the code is not a competitive advantage, it is likely not worth protecting." Even in the case of code with little intrinsic value, however, O'Grady believes that, "permissive licenses [such as the MIT License] are a perfect alternative."

So while O'Grady using Black Duck data found that "the GPL has been the overwhelmingly most selected license," these two licenses, GPLv2 and v3 are, "no longer more popular than most of the other licenses put together."

Instead, "The three primary permissive license choices (Apache/BSD/MIT) ... collectively are employed by 42 percent. They represent, in fact, three of the five most popular licenses in use today." These permissive licenses has been gaining ground at GPL's expense. The two biggest gainers, the Apache and MIT licenses, were up 27 percent, while the GPLv2, Linux's license, has declined by 24 percent.

This trend towards more permissive licensing is not, however, just the result of younger programmers switching to thinking of code as means to an end for a cloud services such as Software-as-a-Service (SaaS). Instead, it's been moving that way since 2004 according to a 2012 study by Donnie Berkholz, a Red Monk analyst.

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

I'm not sure that's wise, but this is 2014, not 1988. Many program's functionality are now delivered as a service rather than from a program residing on your computer. What I do know, though, is that if you want some say in how your code will be used tomorrow, you still need to put in under some kind of license.

Yes, without any license, your code defaults to falling under copyright law. In that case, legally speaking no one can reproduce, distribute, or create derivative works from your work. You may or may not want that. In any case, that's only the theory. In practice you'd find defending your rights to be difficult.

You should also keep in mind that when you "publish" your code on GitHub, or any other "public" site, you're giving up some of your rights. Which ones? Well, it depends on the site's Terms of Service. On GitHub, for example, if you choose to make your project repositories public -- which is probably the case or why would be on GitHub in the first place? --then you've agreed to allow others to view and fork your repositories. Notice the word "fork?" Good luck defending your copyright.

Seriously, you can either figure out what you want to do with your code before you start exposing it to the world, or you can do it after it's become a problem. Me? I think figuring it out first is the smart play.