Contributing GPL Licensed Code Back
Recently, I have come across a number of articles that made the point that you need to be careful of using GPL licensed code because you may have to contribute back your improvements. I wanted to clarify this assertion because, in most cases, it is simply not true. Still, even if you are not required to contribute back improvements to GPL licensed code, it may be in your best interest to do so but I will get to that later.
First a little on the GPL. The GPL, a.k.a. the GNU General Public License, is a product of the Free Software Foundation and it is considered the most restrictive of the many OSI Certified open source licenses. Many great open software applications including the Linux Kernel, are licensed under the GPL. Unlike some of the more laissez faire licenses, such as the BSD License, the GPL has a "viral clause" that says derivative works must be distributed under the same terms as the source work. So code based on GPL licensed code is GPL licensed.
Although this sounds scary, the "viral clause" is only triggered when the derivative work is distributed - as in sold or shared among a select group of entities. So if you extend Zope to add a new capability for your organization, and never share the code with anyone, you do not need to publish your improvement under the GPL rules. The trick is knowing what is considered distribution. Philip Albert wrote a great article in Linux Insider on this subject. Albert writes that sharing across certain corporate relationships, such as between subsidiaries or between a system's integrator and client, could be considered distribution. If you are working with a system's integrator on GPL code, you should be careful to structure the relationship as "work for hire." Otherwise, if you sharing the code with your consultants could be considered distribution.
Another factor is whether your code is a derived work or is considered a module or application that uses the GPL licensed application. Plugins and things of that nature are not considered derived work. In fact, software is often open sourced for the reason of expanding a market for non-open source software uses it. For example, SAP open sourced their database to make the value of ERP less about the database than the application sitting on top of the database. The Firefox browser phenomena is so interesting because it has the potential to create a market of extensions that work on the freely available browser.
I have talked about why you may not have to contribute back your improvements to GPL licensed code. Now, lets discuss why you may want to contribute back your improvements. You contribute code back when the competitive advantage of sole access is outweighed by the cost of maintaining it. When you contribute back, great things can happen. The code gets reviewed by really good programmers. The code becomes part of the core application so that you have less to worry about it when you upgrade. The contribution that you make also has the potential to grow into a new feature that would be useful to you. The application gets better and attracts more users which ensures its future.
Much has been written about strategies for using and contributing to open source. One of the more powerful models is Geoffrey Moore's distinction between "Core" and "Context" which he presented at OSBC 2005 in San Francisco. I have also found my colleague Stephe Walli's 2005 USENIX presentation Under the Hood: Open Source Business Models in Context to be helpful in understanding the benefits of using and contributing back to open source. The general gist behind these models is that a company has certain capabilities that give it a competitive advantage (Core) and a whole lot of other capabilities that it needs to keep the lights on or make the core stuff work (Context). That is not to say that the context stuff is not important. Companies need to pay their employees but having the best payroll system is not going to make one company a market leader.
Back to the world of content management. There are many content management features that are always context (storage) and many features that are frequently context (workflow) and occasionally there will be some features that are core (such as, perhaps, views of content that give new insight or knowledge). But, of course, it is the content that resides in the system which is really core to the company. Based on this breakdown, content management has high potential to attract cooperation and contributions from organizations that want solid systems and are not threatened by the prospect of their competitor having the same core capabilities.