Open Source Commentary from Navica's CEO, Bernard Golden

September 2005 Newsletter

• GPL 3: The Calm Before The Storm

• Takeaways

GPL 3: The Calm Before The Storm

Many discussions of open source obsess about licenses. Organizations spend a ton of time understanding them, analyzing them, consulting lawyers about them, setting policies about them, and, most of all, discussing them ad naseum. This, despite the fact that most organizations merely use open source, never modify it, and never distribute it, thus sidestepping any possible complications from an open source license.

This is due to what may be termed the “veil of the firewall.” If you are an IT organization that takes advantage of open source software, but use it solely for internal applications (that is, inside your firewall), you have no obligation to share any code changes you might make to an open source product. Of course, the vast majority of open source users never modify the source at all – for them, the community surrounding the product is much more important than the license under which it is distributed. This topic was addressed in last month's newsletter, which may be accessed here. The overall meaning of the veil of the firewall is that most organizations can obtain the benefits of open source without paying much attention to license niceties.

The fraction of open source users that modify open source code and distribute the resulting changes also typically do not have to worry about the license conditions. Most of them are improving the product and have no reason to keep their changes private; in fact, one of the main reasons they distribute the changes is to ensure they are merged back into the mainstream code base of the product.

Only a miniscule percentage of open source users – software vendors-- worry about the redistribution implications of open source. That percentage has an important reason to be concerned about redistribution requirements of source changes: handled incorrectly (and depending upon the specific license), their product could be “infected” with the open source license and thereby become open source itself.

Software vendors that do distribute modified open source now operate under a widely-shared set of assumptions about license requirements, developed over the past decade. In essence, the $200 billion software business is getting ready to start playing a new game, based on a common understanding of the current open source licenses and their conditions.

However, a revision of the GPL is due for release in the near future, and has the potential of disrupting the growth of the open source software industry. GPL 3 may very well:

• Make it more difficult for software vendors to pursue an open source-based strategy
  
• Confuse mainstream IT organizations as to whether their open source use falls under redistribution requirements

The Free Software Foundation (promulgator of the GPL) recognizes that it must not veer too far from the current GPL 2 license; otherwise, it faces the possibility that many projects will stick with GPL2. Put another way, if GPL 3 represents too large a change, the FSF confronts the potential of a GPL fork. Therefore, the FSF has pledged that GPL 3 will offer only incremental, minor change from GPL 2. It is not clear that the implications of GPL 3 as currently discussed are consistent with that pledge. What is clear, however, is that the open source community is going to be embroiled in GPL discussions for at least the next year.

Why could the introduction of GPL 3 cause such turmoil?

Keep in mind the following:

1. The GPL is the most widely-used open source license

The GPL is by far the most widely-used open source license. Nearly 70% of the projects calling SourceForge home use the GPL. When someone creates a new open source project, the GPL is the typical choice for its license. It enables someone to make his work available for use while precluding anyone else from “hijacking” the project source base.

There are literally tens of thousands of GPL-based open source projects. Therefore, any implications of the GPL 3 will affect a huge number of open source products. As each one of those projects releases new products, its developers will have to decide which GPL license to use: GPL 2 or GPL 3. It doesn’t take much imagination to envision a huge amount of discussion and angst about which version to use, repeated 20,000 times.

2. Extending the GPL to software services will muddle who is subject to reciprocity requirements

One of the rumored areas that GPL 3 will address is the use of GPL software in so-called Software-as-a-Service (SaaS) implementations. Perhaps the best-known example of SaaS is SalesForce.com. It is thought that SalesForce makes heavy use of GPL software (perhaps having made modifications to it).

The current GPL license does not countenance software functionality being delivered as a service, and therefore does not address it. The rumor floating around the industry is that GPL 3 will explicitly address SaaS and consider it as public use, which would therefore trigger reciprocity requirements.

In some sense, this is consistent with a GPL licensing perspective that precludes a user from profiting by modifying a base product and realizing revenues from the resulting product while incurring no obligations for reciprocity.

3. The GPL license is created under unique conditions

The GPL is promulgated by the Free Software Foundation (FSF) and is the creation of its founder, Richard Stallman. He has a strong ideological perspective about software, believing that all software should be freely distributed and incapable of licensing restrictions that allow intellectual property-based profits. An entire industry has coalesced around the current interpretation of GPL 2; however, Stallman is unlikely to restrict GPL 3 licensing conditions merely to ensure that they support commercial vendor business models.

This means that business models and product architectures based on current GPL 2 conditions may need to be rethought in light of GPL 3. The FSF’s attorney, Eben Moglen, noted during a recent LinuxWorld talk that the FSF is setting up a mechanism for the expected 100,000+ comments that will be submitted regarding GPL 3; nevertheless, despite a very broad input mechanism, the final decision on the license depends on one person, not a shared consensus.

The Potential Impact of GPL 3

Based on these factors, what is the potential impact of GPL 3? Here are three scenarios that are possible, ordered from most probable to least probable.

Scenario One: GPL 3 is like GPL 2 but modified to address global licensing requirements

In this scenario, the impact of the GPL modifications is quite modest, limited to clarifying its implications for non-US nations. The economic underpinnings of the nascent open source commercial movement are left undisturbed, and the working practices of IT users can continue unaffected.

On the other hand, if the changes to the GPL are so uncontroversial as to extend merely to global licensing harmonization, why would an infrastructure capable of accepting 100,000+ comments be necessary? Also, the vision of little change described by Moglen in his LinuxWorld presentation may not be entirely accurate.

In discussing the background for this newsletter, I spoke with Larry Rosen, a well-known open source intellectual property and licensing attorney. He pointed out that it may not be a simple transition from GPL 2 to GPL 3 for products; in other words, a product licensed under GPL 2 may not seamlessly be able to be released under GPL 3 if the conditions of licensing are changed. In any case, if a product contains even one portion released under GPL 3, the entire product will have to abide by GPL 3 distribution conditions. This means that the impact of GPL 3 is likely to be sudden and substantial, rather than slow and slight, because it will only require one GPL 3 file to trigger new distribution conditions.

It might be possible to sort out these issues for Linux, given the number of well-heeled sponsors of the product, but thousands of open source products that have adopted GPL 2 may not have the resources to perform the analysis and modification of the licensed product.

Expect an enormous amount of discussion and confusion when the true impact of GPL 3 becomes clearer.

Scenario Two: Software services triggers reciprocity requirements

Somewhat less likely than Scenario One, but, as noted above, strongly rumored as part of GPL 3, is the potential for concretely defining software services as constituting a form of distribution. Also noted earlier was the seeming fairness of asserting reciprocity if the resulting product's services participate in economic transactions. In simple terms, if SalesForce.com modifies a GPL product and sells services based on the modified product, it should have to release those source code changes to its customers. This would have the net effect, of course, of making those changes available to everyone, since SalesForce.com's customers can then turn around and freely distribute the modified product they've received. Overall, this provision would impact software service vendors by subjecting them to the same licensing conditions as software product vendors who use GPL-based components, and provides a consistency for vendors.

Not so obvious from this discussion, however, is the potential impact this licensing condition might have on IT users. A major industry trend is the move to Service-Oriented Architectures (SOA) which enable organizations to cooperate more effectively by tying their computer systems together. SOA is based on several protocols, the most fundamental of which is Simple Object Access Protocol (SOAP). IT organizations are increasingly using SOAP and its sister protocols to improve their economic performance.

The question is, would a GPL 3 licensing condition defining SaaS as triggering reciprocity requirements have the effect of bringing SOA implementations under GPL 3 as well? It seems probable that, at the least, there would be a strong likelihood that organizations might fall under those requirements – after all, how can you tell where SaaS leaves off and SOA begins?

In his LinuxWorld San Francisco presentation, Moglen cited the need for a “single legal phrase” to cover these distributed services. It's not clear, though, that such a single phrase can be found. It's straightforward to make a case that a business that sells software (whether via CD, download, or remote service) should be subject to license reciprocity; it seems much less straightforward that a company that uses software in running its business should disclose its proprietary business knowledge that is embedded in code; however, extending GPL to attempt to cover services will muddy the distinction between vendor and user license obligations.

In a recent interview with Richard Stallman, he indicated that the FSF’s current thinking on this issue is to require that any GPL 3 code that offers a service call (this would seem to be an API of some sort) to emit its source code would need that call to be made available by any organization that runs the code within a service. It is very unclear how this could work: if the organization’s service only offers a specified set of services, how would it make the GPL 3 service call available? If GPL 3 requires that any organization using code with such a service call make it callable through their service interface, it is going to be a big problem. Who wants to have to make a bunch of extra service calls available? Furthermore, just keeping track of all the service calls the organization would be obligated to offer up would be extremely difficult. It’s likely that this method will be rethought before release of the draft GPL 3 license; however, its challenges give a picture of how difficult it would be to implement this licensing requirement.

No matter what the implementation mechanism of this requirement, however, it will almost certainly have the effect of piercing the “veil of the firewall.” In other words, organizations that never had to think about the implications of distribution requirements will now have to factor them into their implementation plans.

The most troubling potential outcome of this could be that organizations might be dissuaded from using open source, deciding it's easier to pay a commercial vendor for software for which licensing implications are quite clear. Even worse, they might decide to forego SOA implementations due to increased project costs since open source might not be considered a viable choice.

Up to now, open source users have fallen neatly into two camps: vendors who really need to think about license implications, and users that have had the luxury of dismissing these considerations. Extending GPL 3 to cover delivery of service as a distribution would have the effect of mingling those two categories.

Scenario Three: GPL Defined to Expand Reciprocity

One of the most vexing things about GPL 2 is figuring out how it applies to a given software product. Of course, as a standalone product licensed completely under the GPL, it's clear that the product must live by GPL conditions. However, when one begins to combine GPL-licensed code with other software components, things start to get complicated very quickly. The intent of the GPL is fairly clear – it wants to ensure that any product that extends GPL-licensed code itself must be distributed under the GPL.

What about GPL 3? One might have expected that this version of the license would more explicitly define the circumstances under which the reciprocity conditions of the license would apply. Furthermore, one might have expected GPL 3 to make the definition more extensive, ensuring that more products would fall under GPL licensing conditions.

On the other hand, as noted earlier, the FSF recognizes that it must not go too far with GPL 3. If it effects too large a change, the FSF faces the possibility of a license fork. Therefore, in order to encourage adoption of the new license, the FSF must not present current users with unacceptable license implications, even should it desire to do so in the name of software freedom. Even revolutionaries suffer from the problem of an installed base!

In fact, in Moglen's remarks at LinuxWorld was a little-noted statement that GPL 3 would lower barriers that today prevent the mixing of software covered by the GPL and other open source licenses. This is extremely interesting, as it seems to imply that GPL 3 would renounce the position that mixing GPL code with other code extends the GPL license over the resulting product. Given that there isn't any obvious way to apply this “mixing” ability only to open source-licensed code, this might imply that it will be easier for commercial products to incorporate GPL 3-licensed code without triggering reciprocity distribution requirements. The net effect could be to encourage commercial products to take greater advantage of GPL-licensed components, which could be a great boon to both vendors and users alike.

Takeaways

Notwithstanding the protestations that GPL 3 will be a minor tweaking of GPL 2, it is likely that its release will cause a tremendous amount of confusion, alarm, and controversy. Now that open source occupies a major position in vendor and user strategic plans, what once might have been an “inside the beltway” discussion will generate months of discussion and argument.

If you are a vendor, it's critical that you look at the new license and understand whether it offers a mechanism to more easily take advantage of GPL-licensed component, or whether you may need to rethink your strategy, if it was based on a SaaS delivery mechanism that is no longer immune to reciprocity.

If you are a user, it's vital that you look at your SOA plans and architecture to understand whether your offering and business model will be affected due to GPL 3's conditions. On the other hand, the new license might have the effect of reducing your costs as vendors reduce prices due to the ability to more widely use GPL-licensed code.

The bottom line: get ready for a giant brouhaha. Expect at least a year’s worth of discussion and argument. This controversy will serve notice that open source is now a critical piece of IT infrastructures and vendor strategies.