The release of Puppet 2.7 brought one major change that has nothing to
do with its actual feature list — the license was changed
from the GPLv2 to the Apache License 2.0. This came as no surprise to
the Puppet contributor community, but it seems as if it might be part of a
trend towards more permissive licenses by companies working with open
source. Luke Kanies, the founder and CEO of Puppet Labs (the company that has grown up around Puppet) says that he has no political axe to grind with the decision — it's simply a matter of reducing "friction" when it comes to Puppet adoption.
In conversations about licensing, Kanies shows little passion for the
topic. But, when asking about the actual goals for Puppet, he exhibits a lot more interest about what Puppet (or something like Puppet) needs to accomplish — the ability to manage large-scale networks without needing to know the particulars for each device in the network.
Puppet is an "enterprise systems management platform" which started as a replacement for Cfengine. Kanies, who was a major contributor to Cfengine before starting Puppet, has a fairly modest goal for Puppet — ubiquity. "If we can get ubiquity, we can accomplish what we're trying to do... profitability is easy. What we're trying to do is [make it so] you don't need to know what OS you're running on."
According to Kanies, there was simply no good reason to remain with the
GPL. The license didn't do anything specifically to address his goals for
Puppet, and could actually hinder Puppet's ubiquity. Why? Kanies says that
"a number of companies," and two in particular, were
"quite afraid" of the GPL. One company, he says, avoids even
having Puppet in its infrastructure — to the point of having a
separate approval process for deploying GPL software. The other company
didn't have qualms about the use of GPL software, but did have concerns
about mixing GPL code with other code they ship.
It seems odd in 2011 to hear that companies still have "fears" about the
GPL, given its widespread adoption and endorsement by such a diverse
selection of companies — up to and including a giant like
IBM. However, Kanies says that plenty of companies (or perhaps more
accurately, their lawyers) have concerns about the GPL — and IBM is
perhaps a poor example:
You're right that IBM is comfortable with the GPL,
but there aren't many companies that can sue IBM. It's tough to scare IBM,
and IBM not being afraid is not a good indicator that everyone else should
not be afraid.
So what's the fear? Kanies says that it's the standard argument about
the GPL being untested in the courts, along with the fact that there's
disagreement and a lack of clarity about what "linking" means with regards to
dynamic languages, and whether that linking creates a derivative work. For the record, Kanies points out that he does not share the same fears about the GPL — but he also does not feel particularly strongly about the GPL, and certainly not enough to keep the license if it stands in the way of Puppet adoption.
As a single event, the change of one project's license from GPL to Apache is not particularly important (outside that project, of course). However, if it's part of a larger migration away from the GPL, then it may be worth noting.
Are projects moving away from the GPL? Not in droves, but there does seem to be less of a tendency for companies or projects without a strong philosophical bent to choosing permissive licenses like the Apache, MIT, and BSD licenses. The 451 Group pointed to some evidence last year that companies were favoring more permissive licenses like the LGPL, BSD, Apache, and Eclipse Public Licenses. In January of this year, Stephen O'Grady noted that Black Duck Software's license figures showed a decline for the GPL overall.
The GPL still seems to be the dominant license, however. Black Duck Software tracks the adoption of GPLv3 versus GPLv2. The GPLv2 has dropped to well under 50% (45.42%), with the GPLv3 at nearly 7% of the projects it tracks. The Apache License 2.0 is at nearly 5%, and the MIT license is at just over 8%, as is the Artistic License. According to O'Grady, this is a 4% decline for GPLv2 since August 2009 (with an increase of only 1.34% for GPLv3) and nearly 4% increase for the MIT license.
On Contributor License Agreements
The license change should not come as a surprise to anyone in the Puppet
community, though it has been greeted with some surprise in wider circles. Kanies says he has been asking the community for about two years, and has talked to "all of the major contributors" about the change. Kanies says that none of the contributors have raised a fuss, though he's gotten "one person that's said they're upset, and a couple who seem like they aren't that happy with the change and say 'I'd like to better understand this decision that you've made."
Since late 2009, Puppet has required a Contributor License
Agreement (CLA) in order to submit code to the project. Kanies says
it's similar to the Apache CLA, which basically provides the right to
relicense the software any way the project sees fit.
In the case of Puppet, there seems to be little real cause for
concern. Kanies provided ample time for the larger Puppet community to
comment on the license change, first raising
the issue in April, 2009 (when he thought he might go to the Affero
GPL), and announcing the planned change
to the Apache license five months later. It seems that few in the Puppet
community are upset by the change. Users receiving Puppet under the Apache
license are essentially in the same place they were before — able to
study, modify, use, and distribute Puppet freely. Contributors to Puppet
may not receive the same "protections" that the GPL affords, but it seems
that the contributor community to Puppet is not particularly concerned about this.
The Puppet change should serve as a reminder to other developers that CLAs are in place for a reason. When giving permission to a project or organization to re-license a work, it should be assumed the organization will exercise its rights at some point — perhaps in a way that is unoffensive, perhaps not. Absent a guarantee in the CLA to stick with a certain class of license, it should be at least considered that the program may be re-licensed in a way that is less friendly to its user and contributor community.
to post comments)