Observations from where technology meets business


Border Disputes in Enterprise Use of Open Source 3C

This is the fourth in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the risk of inadvertently licensing proprietary software as open source by mixing it with a GPL-licensed product.

Recall that my research focuses on the use of communication, collaboration, and content management (3C) solutions within enterprises. As it turns out, a large number of the leading open source 3C products are licensed under the GPL. So care must be taken if organizations choose to integrate these products with enterprise systems. The concern has to do with the GPL’s Copyleft provision, which states that a system must be licensed under the GPL if any GPL-licensed source code was used to create it and it was distributed. A previous blog post discussed hereditary and permissive open source licenses in more detail.

But let’s say this up-front, if your plans do not include modifying the source code of (or integrating with) a GPL-licensed product, or if you have no intention to distribute any software which involves GPL-licensed software (either linked or integrated with another system) then you should have nothing to worry about.

The issue I want to highlight here is where organizations are considering integrating a GPL-licensed product with an enterprise system. In some cases it is fairly straightforward to determine if a piece of software falls under the GPL. For example, if a developer links their source code with GPL-licensed source code then the resulting program is considered a derived work and would have to be licensed under the GPL, if it were distributed.

In her book “The Open Source Alternative: Understanding Risks and Leveraging Opportunities” Heather Meeker does a good job describing the “border dispute” of the Copyleft provision in the GPL. The problem is the GPL itself is not always clear as to what defines a program that is considered derived from GPL software. Meeker is very good at setting the scope of the issues and then exploring a number of scenarios regarding the applicability of Copyleft.

However, while Meeker’s background and analysis is interesting I don’t intend to explore the legal issues brought on by the GPL in cases such as loadable kernel modules in Linux or proprietary operating systems running within a Xen host. What I want to briefly touch on here are the issues surrounding the use of GPL-licensed software within enterprise environments, most notably those which may have to integrate with corporate systems.

So let’s explore these issues by going through two scenarios:

  1. Configuring Drupal to use an enterprise’s directory system. For example, an enterprise uses Microsoft Active Directory as a central source of usernames and passwords. Should we be concerned with integrating Active Directory with a Drupal installation via an LDAP interface using the LDAP integration module?
  2. Surfacing data originating from an enterprise system within a sidebar on a blog running WordPress. For example, the latest sales numbers are displayed on a blog written by a marketing director, via a plugin which pulls data from their proprietary sales tracking system.

At first it may not be obvious that either of these scenarios would qualify as a derived work and be subjected to Copyleft. In both cases the GPL-licensed products involved (Drupal or WordPress) would probably not run on the same computers as the proprietary systems with which they are communicating.

To get some guidance we can refer to the Free Software Foundation. As Meeker says in her book: “The Free Software Foundation (FSF) is in some ways the de facto enforcer of the GNU General Public License (GPL).” To help clarify these types of questions about the GPL, the FSF has a frequently asked question list on their website. The answer to the question “I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?” provides some illumination as to how the GPL applies to the above scenarios. It says in part:

“However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.”

In other words, it matters a great deal how a GPL-licensed program integrates with a proprietary system, regardless of whether they are on the same system (and, we should also note, given the pervasive connectivity of the Internet, it doesn’t matter if the two systems are on the same network of even in the same company). If they operate as a single program then the FSF considers them a single program now subject to Copyleft.

So, the key is to be able to demonstrate that the two systems involved can still be considered separate. In the first scenario (Drupal using Active Directory) communication between the two systems is done via a well-known protocol (LDAP). All of the software used in the Drupal system can operate as a separate entity by connecting to any LDAP-compatible directory, not just this particular Active Directory. The two systems are clearly separate programs.

The second scenario is less clear. In her book Meeker suggests “to focus on the spirit of the GPL rather than its letter” and goes on to say the degree in which the proprietary code can be considered a “black box” will help clarify whether there is sufficient “arms length” (as the FSF describes it above) between the two.

If the proprietary sales tracking system was custom-written by company employees and the company wrote a custom extension to serve the data along with a custom WordPress plugin to pull the data and display it within the blog, then this sounds like two systems performing as a single program and subject to Copyleft, if either of the two were distributed.

On the other extreme, let’s say the company purchased a widely available sales tracking system, which provides sales data in RSS feed, and an RSS feed is fetched by a WordPress RSS plugin (which can be used with any RSS feed) that simply displays the feed items on the blog. This certainly seems to qualify as a “black box” and the two systems can be considered separate.

In closing, while is makes sense for enterprises to use GPL-licensed software (after all, a large number of the leading open source 3C products are GPL-licensed) care must be taken when integrating them with proprietary systems.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

The Roles Open Source Can Play in an Enterprise Vendor's Business

This is the third in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the roles an open source product can play in an enterprise vendor’s business (which are enabled by open source licenses) and what this means for the enterprise itself.

A previous post discussed the four key levers of open source licensing that can support a vendor’s business model:

  1. Hereditary versus permissive licensing (and the impact of Copyleft)
  2. Source code ownership rights
  3. Limitations around attribution
  4. What defines “distribution”

These levers are important to enabling the roles a vendor intends a software product to play in support of their business objectives, which are listed below. I’ll go through each of these in detail:

  • Commoditizing a Function
  • Increasing Accessibility to Code, But Retaining Ownership
  • Sustaining a Community
  • Delivering Services
  • Providing Support

Commoditizing a Function: This role is enabled by permissive open source licenses. For example, the Apache web server has commoditized basic web serving. Large companies like IBM have been the biggest contributors to these types of projects, often supplying the most developers and even contributing code that becomes the basis of new projects.

Nearly all open source products benefit from these products since they provide the foundation for other opportunities (e.g., LAMP-based solutions). IBM benefits by incorporating these in commercial product offerings, enabling contributions to come from a wider audience of developers (thereby sharing some cost), providing a forum to explore new technologies and standards (reducing risk and increasing interoperability), and reducing the chance of competing technologies from becoming standards (for example, the Apache web server has remained the most popular web server despite efforts from companies like Microsoft).

Increasing Accessibility to Code, But Retaining Ownership: This role is enabled by dual licensing of software. In particular, companies have licensed software they own with both a proprietary license and a hereditary open source license, such as the GPL. The classic example of this is MySQL. In the content management market, Alfresco is a good example.

The key to enabling this dual licensing approach is having ownership rights to the source code. For example, take a look at the Sun Contributor Agreement. The author of a contribution that makes it into the core product must give ownership rights to Sun.

In this role the GPL discourages competitors from incorporating MySQL source code into a proprietary product (since distributing the resulting product would require it to be licensed under the GPL) while also increasing visibility enabling others to interoperate with it. Nearly every Linux distribution comes packaged with the GPL version of MySQL, making it an easy choice for many developers to use. I’m sure Alfresco would love to have the same type of relationship with Linux at some point.

Sustaining a Community: For all of the complaints made against the GPL (mostly by commercial software vendors) it is hard to dispute the success of a number of communities supporting GPL-licensed products. For example, the  Drupal community has over 350,000 members and the Wordpress community has produced over 4,200 plugins. These are extremely active communities and are examples of what many established commercial vendors have been striving to build for years.

None of the main commercial entities involved in these products (Acquia for Drupal and Automattic for Wordpress) control the source code, nor license it separately. The GPL seems to level the playing field, enabling community members to compete on aspects other than proprietary software offerings. Rather, community members use the source code as a basis for competing in downstream markets such as custom website development, various types of services, and support. The result is a robust open source product that incorporates cutting-edge innovations at a pace commercial software vendors have difficulty matching.

Delivering Services: One of the ways Acquia and Automattic leverage their open source products is to provide services and support. For example, basic hosted Wordpress.com blogs are free. But, Automattic also provides premium blogging services as well as software support for enterprises. Acquia also provides support and later this year will offer site hosting and a premium site-search service (based on Solr, an Apache-licensed product, and provided via a Drupal module). Of course, many online service providers use open source software. The most recognizable being Google and Yahoo.

Providing Support: Although community leaders (such as Acquia, Alfresco, and Automattic) offer paid support services for their open source products, there are also companies that provide support for a broader selection. These include OpenLogic and SpringSource. For example, OpenLogic provides support for MediaWiki (the software which runs Wikipedia) as well as hundreds of other open source products including development tools.

Most enterprises will need some type of commercial support for open source products, unless they intend to maintain a staff with sufficient skills to do it themselves. So which type of support should you use, a contract with a community leader or a support-only vendor? Each situation can be different but, in most cases, I would first consider going with the community leader (since this contributes to the long-term viability of the product), unless the use of the product is limited and the risk of problems low. Either way, I think there is room in the market for both types of open source vendors and their positioning will be sorted out over time.

Clearly, open source products need viable community leaders and these companies will likely provide the best support. However, enterprises can only be expected to maintain so many vendor relationships and there are literally hundreds of opportunities for enterprises to use open source (many, of which, do not have a commercial entities behind them) so the open source support vendors should have plenty of business to go after.

What does this all mean to enterprises wanting to use open source solutions? When considering a particular open source product,first understand the role it plays in the plans of vendors supporting it.

  • Products with strong communities behind them will tend to be more innovative, likely have enterprise support options, and be around for some time.
  • Those products without strong communities need to be assessed as if they were a commercial product being sold by the vendor providing support.
  • If they have neither a strong community nor a viable commercial vendor behind them, either reconsider your options or proceed with caution and look for signs that the community will continue growing.

The key is understanding the long-term viability of an open source product, whether it is backed by a vendor or a community.

In my next post I will discuss some of the risks involved with open source licensing, thoughts on mitigating these risks, and open questions that still remain.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Key Levers of Open Source Licenses

This is the second in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the basics of open source licensing while also highlighting aspects that can enable vendor business models and influence how an enterprise approaches using open source products.

The definition of an open source license is generally considered to be the responsibility of the Open Source Initiative (OSI), a non-profit corporation formed in 1998 to promote the development and use of open source software. The OSI definition of an open source license is called the Open Source Definition (OSD) and is made up of 10 requirements that must be met before a license can be considered open source. OSI maintains a list of approved software licenses that have gone through their license approval process. Software creators can use the OSI Certification Mark logo and notification text if their software is licensed with one of the OSI approved licenses.

OSI presently lists 72 approved open source licenses. However, only a few of them are in wide use. For example, Freshmeat (a site that tracks open source software) says that over 60% of open source projects use the GNU General Public License (GPL). To make open source licenses easier to understand it is best to break these down into two broad categories: hereditary licenses and permissive licenses.

The most controversial, and most recognizable, hereditary open source license is the GPL. The terms of the GPL most relevant to enterprises using open source products are:

  • The source code must be made freely available.
  • Once software is licensed as GPL its licensing terms cannot be changed (the only exception being an owner, who retains all rights to the original source code).
  • Any modifications to the GPL-licensed source code, or any software incorporating GPL software, must also be licensed under the GPL and may also be required to be made freely available. This is also known as the “Copyleft” provision. However, this provision is only triggered when the software is distributed.

In the diagram below, source code licensed under the GPL is mixed with “Your Source Code,” which could be as simple as small changes to the GPL-licensed source code or as complex as software intended to be kept proprietary (either custom developed or purchased). The GPL’s “Copyleft” provision requires the resulting software to also be licensed under the GPL, if it has been distributed. Resulting software not distributed is not required to be licensed under the GPL.

 Hereditary License Example

For many businesses, which sell commercially licensed software, the GPL is viewed as “viral” and a threat to their business model. Open source products licensed under a permissive license, such as the Apache License, are generally acceptable to commercial software vendors and not seen as a threat. The diagram below illustrates why:

Permissive License Example 

The key points from the above diagrams are:

  • Enterprises need to be careful when integrating with products with open source hereditary licenses. However, I should also note that care should be taken for integrating with any licensed software.
  • The act of distributing the resultant software (“Something New”) triggers the Copyleft provision of the GPL. Unless the software is distributed then the provision is not invoked. In an enterprise context, distribution of source code generally means giving copies of it to someone outside of the enterprise. However, there are other hereditary open source licenses that define “distribution” much more broadly and includes the act of using the software over a network (for example, a web application being used over the Internet) and may not involve the transfer of source code at all.

Other levers that are involved but are not obvious from the above diagrams:

  • A source code owner (the original author or somebody who has obtained ownership rights) can license the software any way they like. For example, they can release one version under the GPL and another under a commercial license.
  • A few open source licenses have other restrictions requiring some form of attribution. This can be simply attributing ownership in the source code or retaining the use of the owner’s name or logo in screens seen by someone using the product.

To sum it up, the key levers of open source licensing, which can support a vendor’s business model, and which enterprises should be aware of are:

  1. Hereditary versus permissive licensing (and the impact of Copyleft)
  2. Source code ownership rights
  3. Limitations around attribution
  4. What defines “distribution”

My next post will discuss the types of open source businesses these levers enable and what this means for enterprises wanting to use open source solutions.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Open Source Software Licensing for IT Managers

A recent article from Bruce Perens, a leading open source advocate, entitled “How Many Open Source Licenses Do You Need?” reminded me of how confusing open source licensing can be for IT managers who aren’t plugged into the open source world. Although the article is published on a website intended to be read by IT managers it was clearly written for companies producing open source software. After writing down some of my own ideas for explaining open source licenses to IT managers I decided to turn these into a series of posts.

But first, some background. My research at Burton Group focuses on the use of communication, collaboration, and content management (3C) solutions within large enterprises. What this means is I don’t come to this topic from only a developer’s or a system or network administrator’s perspective. The 3C solutions we cover are usually considered infrastructure components that can be leveraged by applications. We tend to have a foot in both the infrastructure and application side of IT.

What we see driving IT management interest in open source is:

  1. Saving money through lower licensing costs.
  2. A desire to tap into innovative solutions, particularly those driven by active open source communities.
  3. Using open source software to learn about emerging technologies (for example, much of what is called Web 2.0 was first built with open source)

The concerns IT managers have with open source software are:

  • How well does the software work?
  • Will it integrate with my existing infrastructure and applications?
  • How well is it supported?
  • Is it secure?
  • Are there any risks with using open source software?

In my client dialogues about open source a topic that often drives discussion is licensing. One of the keys to effectively applying open source solutions is to understand a vendor’s business model and the role the software plays in their market plans. An open source license supports that role and business model. Therefore, understanding open source licenses is important because:

  • They are an indication of the business model used by an open source company (and commercial software and services companies using open source software).
  • Each of these business models has a different set of factors to pay attention to in terms of how they use open source and what they must do to succeed.
  • They also influence how an enterprise might use an open source product. For example, maybe you are using an open source library in one of your applications or perhaps you are using a full product (like an open source blog) but are thinking of integrating it with an application. Each of these scenarios comes with a different set of opportunities and risk.

My next post will be an introduction to specific open source licenses, the levers they can bring to bear on a software market, and what they can mean to an enterprise using open source software.

This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog

Syndicate content