Content Management System (CMS) News, Reviews, Events and Analysis.
 
 
 

Open Source: The GPL, Your CMS Project and You

By Dee-Ann LeBlanc  | Published Apr 21, 2009

The GPL, Your Project, and YouAs the best-known free software and open source license, the GNU General Public License, or GPL, has become both a rallying point for the free software and open source (FLOSS) communities and a focus of FUD (Fear, Uncertainty and Doubt) campaigns for those who fear that these movements will destroy their revenue streams.

Let's take a look at some of the issues and misunderstandings that get in the way.

Common Misunderstandings

Let's hit the easy stuff first. The GPL in no way prevents you from selling your software.

It also doesn't mean you have to give the source to anyone that asks, even people who aren't your customers and the GPL does not cover the program's output. If you want to license the output of something you can do so however you like — as long as part of the program's source isn't part of the output.

The GPL does state that if you sell your software to someone in binary form and they ask for the source, you have to give it to them for the reasonable cost of the materials (say, a CD) and shipping. Or, you can't charge a fee for downloading the source that's higher than you charged for downloading the binary.

Also, if you modify a GPL'd program for your own purposes in-house, you do not have to release that modification. However, if you distribute your changes, then you also have to make the modified source available.

The GPL and Versions

One clause you'll find in the license declarations from many popular open source Content Management Systems is the statement that the software is licensed under "GPLv2 or any later version of the GPL."

If you've never encountered this statement before, it can be jarring. Yet, this is the recommended approach from the Software Freedom Law Center, the entity that advises many of the major FLOSS CMS projects — Drupal and Joomla! for example.

According to footnote 9 in "A Practical Guide to GPL Compliance":

However, most so-called GPLv2 programs are actually distributed with permission to redistribute under GPLv2 or any later version of the GPL (“GPLv2-or-later”). In the latter cases, the redistributor can choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the v2 termination provision will always apply. If the redistributor has chosen v3, the v3 termination provision will always apply. If the redistributor has chosen GPLv2-or-later, then the redistributor may want to narrow to GPLv3-only upon violation, to take advantage of the termination provisions in v3.

Making Complicated More Complex?

Does using such language ultimately complicate already complex legal issues? Neither the Free Software Foundation nor the Software Freedom Law Center seem to think so.

According to Pamela Jones of Groklaw, this phrasing is designed to legally and administratively simplify things for FLOSS projects. "It also makes enforcement by FSF faster and quicker, for those parts of code that are given over to FSF to protect."

GPLv2 and GPLv3 Incompatibilities

Another issue the phrasing simplifies is the fact that the GPLv2 and GPLv3 are in some cases not compatible with one another. If you have a project that needs to use some code licensed under GPLv2 and some code licensed under GPLv3, adopting the "or later" language can help ensure license compatibility.

Joe Brockmeier, openSUSE Community Manager, says that he feels that the suggestion to use "or later" is a way of pushing people to adopt the most recent version of the GPL, version 3, which has not been adopted as broadly as version 2. Brockmeier says he prefers "specificity," as far as linking to the specific version of the license that's in use.

Jones points out that the GPLv2 or later language was in use long before GPLv3 was written.  The GPLv2 was published in 1991 and it included this language:

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

The GPL and Content Management System Extensions

One of the biggest issues around the GPL in the Content Management Systems community is around modules, extensions, add-ons or whatever you want to call the external pieces that third parties might build to extend a particular CMS's capabilities.

Generalizations are Elusive

This topic is so thorny to discuss because the intersection of license and copyright issues for code extensions makes it nearly impossible for a lawyer to make general statements on the matter.

Some take the very strict interpretation that all extensions to a GPL project should also be licensed by the GPL. In some cases, this decision may simply be to avoid complex legal wrangling over the subtleties inherent in each individual case. Even commercial companies couldn't afford much of this, let alone open source projects run by volunteers.

Focus on the Interface

In general, if you at all have to modify the project's source to install your extension, then your code is bound by the same license as the source code. Code that goes only through the API on the other hand may not be strictly considered a derivative work.

When trying to understand this issue, Russ Nelson, an open source developer, offered that if the only interaction is at the level of a public API, the project's software could actually be replaced with other software that also used that API. So, the extension could in fact be used without needing the project's code.

CMS Projects Handle this Differently

You can see how the different interpretations of this issue play out within the various open source CMS projects.

Joomla! has decided that all extensions listed in its own resources will have to be licensed with the GPL. Drupal is the same. Plone is discussing allowing exceptions on a case by case basis and even then will specify which alternative license can be used for those exceptions they approve.

Who Has Got it Right?

Ultimately, there's no way to say with certainty who is right unless a dispute makes it to court — though some follow a policy of deferring to the license creators when unsure.

Lawyers can speak as long as they like, but it's the courts that make the final call. No project, company or individual so far has been wiling to risk those muddy waters, but everyone is doing their best to make what they feel is the right decision for their community.

Do keep in mind that when you contribute code to a project, you contribute that code under a specific license version. You will not be held to any obligations created by later versions of the license even if the project itself uses the "or later" language.

The GPL and CMS Templates

Templates are a simpler issue. Kind of.

The Free Software Foundation's GPL FAQ explicitly recommends releasing templates under a simple permissive license to keep things uncomplicated.

However, some templates use heavily calls to JavaScript. In the words of the FAQ:

Since Javascript is often non-trivial, it is worth copylefting. Because the templates will be combined with user data, it's possible that template+user data+Javascript would be considered one work under copyright law. A line needs to be drawn between the Javascript (copylefted), and the user code (usually under incompatible terms).

Within the FAQ, you will find a GPL exception for such code. Read and apply it carefully.

License Compatibility

The third major issue is that of what is compatible with the GPL (though this issue of course occurs with any license).

When it comes to using source that is GPL'd in the same code as source from under another license, the big question is whether or not the two licenses have conflicting permissions or obligations.

To go to an extreme, if one license demands that you give the source to anyone that asks and another demands that you not show the source to anyone who hasn't paid the original developer, these two licenses are considered incompatible. Depending on the licenses, you may be able to use both pieces of code by linking them as separate libraries or through another method.

Some GNU Licenses Don't Get Along

Interestingly, not even all GNU licenses are compatible with one another. In the Frequently Asked Questions about the GNU Licenses document, you'll find a compatibility chart telling you which GNU licenses can be used together and which can't.

The GPL and Patents

When it comes to patents, it's hard to talk too much about this issue, as everyone asked ran screaming from discussing it.

Some licenses explicitly address patents. Others address them only in an implied form, while still more say nothing at all about the issue. See the FSF FAQ for more information when it comes to the Free Software Foundation's licenses.

The GPLv3 does explicitly address patents in section 11. In its preamble, the license states:

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

There is no license out there that can completely protect you from patent issues, since only the people using a license are bound by it. Until the US software patent system is fixed, patents will continue to cast a shadow over all software development.

Too Much Trouble?

Before you start to say that FLOSS licensing is too much trouble, have you read a closed source software license recently?

Remember that the purpose of this community's software licenses is for programmers to ensure that the code they may be giving away for free continues to be used in a way they find acceptable.

Given the billions of dollars worth of programming effort the FLOSS communities have provided, that's not a lot to ask in return. Just make sure that if you're a programmer wanting to use code licensed with the GPL or any license for that matter, you take the time to read the license you're dealing with and understand its terms.

For a more in-depth education on a variety of FLOSS licenses, check out Black Duck Software's ongoing series of legal seminars on open source licensing.

 
Read More About:
, , , , ,
 
Was this article useful?
 

2 Reader Comments

1 | Dave Lane — May 17, 2009 4:35 PM

A useful resource, thanks very much… That said, I think it would be even stronger if the first sentence of the last paragraph was in the first paragraph. Otherwise, those who don't know about open source already are likely to stop reading before they get to the bottom…

2 | Kevin Cochrane — August 8, 2009 2:23 PM

I think this article is informative and well-written, but it does miss a central point: open source is about building a community and getting developers to share and collaborate to build both infrastructure and applications. The challenge with the GPL: precisely between it does require that you have to make your source available, it acts as an impediment to true community development, contribution, and use.

The Apache License represents an alternative to the GPL. The Apache License was designed as a liberal use license … anyone can take any Apache project and safely incorporate into their own product and sell and market without needing to worry about changing their own licensing models. It's for this reason that many vendors - both commercial and open source - make use of Apache projects, most notably the Apache Web server, Tomcat, Lucene, and Jackrabbit.

Why is this important? Because it helps support an entire ecosystem of developers, commercial software suppliers, open source software suppliers, systems integrators, and others to jointly collaborate to provide great infrastructure and application components to advance key Web and CMS technologies.

I do believe that a liberal-use model simply is a better path forward for the entire open source and CMS community. GPL can be a bit of a scorched earth tactic for some: while the source may be available, it's use means others cannot use the GPL-licensed open source version of a product as it does have implications on their own licensing and distribution models. This inhibits community development - and that contravenes one of the primary goals of open source.

Again, I prefer the open source community move away from the GPL to a liberal use license like Apache. Then we can see even ostensible competitors collaborate and build shared components that they can both take to market … much like what occurs with Apache Jackrabbit today.

Leave a Response

  Remember me?

Related Web CMS Articles

 

From our Job Board  View all jobs | feed Jobs RSS feed | Post a job right now

 

Featured Events  View all events | feed Events RSS feed | Add your event

STAY UP TO DATE
Subscribe to our RSS feed...
SUBSCRIBE TO OUR RSS FEED

Just Commented On




Resources