While the Free Software Foundation’s GNU General Public Licenses (GPL) are used in nearly three-quarters of all free and open source software, GPL-based licenses not the only game in town.
Part 1 of this series delves into the particulars of GPL v3. Part 2 looks beyond GPL. There are dozens of other free and open source-focused software licenses out there. While most aren’t heavily used — or aren’t even useful for the challenges of modern-day licensing — they offer various levels of permission and protection designed to govern use and distribution.
For anyone considering releasing a free and/or open source solution, licensing can be a complicated issue that can end up reducing a developer’s ability to use his or own code in the future — or even profit from it. For that reason, free software developers should make sure they understand the full text and ramifications of any license they consider — and possibly consult an attorney well-versed in free and open source law.
Dominance Sets the Benchmark
Because GPL v2 is so widely used, it sets the benchmark for how others are measured, even the brand-spanking-new GPL v3. GPL v2 is a copyleft license, which basically means that the rights granted by the license travel downstream with the code. In practical terms, copyleft in GPL means that if a GPL-licensed application is licensed as free software, all modified and extended versions of the program must remain free as well.
GPL v2, for example, has the intentional side effect of ensuring that improved solutions built with GPL-licensed components remain free for everyone to use in the future. That tends to spawn additional GPL v2 licenses since the newly released modified code would need to be licensed under GPL v2; however, to permit linking with non-free modules, the GNU Lesser General Public License (GNU LGPL) can be used.
In practical terms, developers use GPL v2 and GPL v3 if they want their software to be free and open and remain free and open no matter how the code is used downstream. It can get more complicated than this, of course, especially since the copyright holder (and only the copyright holder) of GPL v2-licensed code, for example, can sell it and even use it in closed source solutions. Basically, though, GPL v2 and v3’s key point is to make the code “free forever.”
Code that is limited to free and open use, though, can also ensure that commercial entities don’t use it, improve it and offer valuable and interesting services with it. Developers who don’t mind how their code is used, modified or redistributed would typically shy away from a GPL-type license.
Public Domain
It seems as if one of simplest ways to make a program free software is not to copyright or license it all, and simply donate it to the public domain to let anyone use it however they want — but it’s not that simple.
“Perhaps counter-intuitively, no license at all means traditional, proprietary licensing — that is assumed to be the default by the courts and the legal system,” notes Luis Villa, a law student and former GNOME Foundation Board member, told LinuxInsider.
If software is released without a license whatsoever, then users must assume it’s copyrighted. “The recipients wouldn’t have permission to share or modify the work,” Brett Smith, Free Software Foundation licensing compliance engineer, told LinuxInsider. “So, if you release software without any license, it’s not free software.”
Developers who want to offer their code freely without restrictions, then, can be served well by explicitly stating such in the form of a public domain certification, but the “practical effects would be similar to licensing under the BSD (Berkeley Software Distribution) license,” Villa noted.
Multiple Versions of Licenses
In the free and open source licensing world, people refer to license generically as well as specifically — and sometimes in shorthand or slang form. The problem crops up with the popular BSD license, which, in its original form, contained an advertising-based clause that many developers unwittingly changed to create multiple versions of essentially the same license, which in turn created a nightmare for future developers using multiple components of software put together with slightly different, but still valid, licenses.
Consequently, the original BSD license is on the way out, even though many people still say “BSD” when they are referring to a modified version of BSD or even FreeBSD, the latter of which strips out two clauses from the original BSD license.
The entire licensing landscape can get even crazier because a copyright holder can create or modify the terms of any license and essentially create a new license for some sort of specific issue. The downside of creating a new license — in addition to the fact that the creator is more or less reinventing the wheel — is that poorly understood licenses tend to scare away users, which means a developer’s code may never get used.
“The key is selecting a license which is widely used by others. That guarantees that the license is well-reviewed and well-understood, and ideally gives you a base of other projects to work with without license compatibility problems,” Villa explained.
Apache, BSD, MIT, MPL, CDDL and More
Many software projects retain the original license that came with the original code — it’s easier to license new code under the same terms and conditions than it is to dual-license code under compatible licenses that retain each license’s full terms and conditions.
“Apache projects, for example, use the Apache software license rather than the GPL,” Stephen O’Grady, an analyst for RedMonk, told LinuxInsider.
The Mozilla Public License (MPL) is used by Mozilla and with Firefox, primarily, while the Common Development and Distribution License (CDDL) is based on the MPL but includes copyleft features while permitting the creation of larger solutions for commercial purposes. Sun Microsystems uses CDDL with its OpenSolaris source code.
“Basically it’s a matter of rights,” O’Grady said. “There’s a license continuum with Apache/BSD-style licenses at one end, GPL at the other, and MPL/CDDL, etc., somewhere in between.”
Licenses are defined then, on what’s possible and what’s restricted. While GPL is free and open, it’s also restricted to remaining free and open. BSD and MIT (Massachusetts Institute of Technology), on the other hand, are less restrictive, but they also may allow software to end up in closed source, commercially sold software solutions.
“The GPL presumes that you want others to play under the same rules you do, which is a widely held, but not universal, assumption,” Villa explained. “BSD/Apache/MIT allow proprietary forks of the code base, and some people actually like that — they feel it brings more people into the community.”
Apache is similar to BSD and MIT with the exception of how it details patent licensing, and, as O’Grady noted, it is used primarily in Apache-based HTTP Web server solutions.
How Free is Free?
Overall, there are dozens of viable free and open source licenses of many flavors used and/or created by developers, organizations, and software vendors. There’s licenses for use with Perl, Ruby, Python, Jabber, Eclipse and PHP — to name a handful that go with easily recognizable code bases. The Free Software Foundation provides a large, descriptive list of free and open source licenses, as does Opensource.org.
Even though the Free Software Foundation is the primary proponent of its GPL-based licenses, it recognizes that it’s a complex world.
“For our own part, we think about licensing decisions very tactically and choose the license that will provide the most benefit for the free software community,” Smith noted. “For example, Ogg Vorbis is an audio file format akin to MP3. We supported the release of its code under a simple permissive license, rather than the GPL or even the LGPL, because it was worthwhile for Ogg Vorbis to gain as much adoption as possible against the patent-encumbered MP3 format.”
Loading ...
