The Pervasive Data Center

If the license wars aren't over, they've certainly muted.

The adoption of the new version of the General Public License, used by Linux and many other open-source projects, was a long, loud, and contentious process. But after all the sturm und drang, it's not clear to me what real impact GPL 3 will have.

Depending on whom you ask, clauses concerning ideological sticking points such as digital rights management were either narrowed in scope or defanged almost completely. And it seems entirely possible that Linux, perhaps the best-known open-source project licensed under the GPL, may never move to the new license version.

More broadly, I just don't feel that there's a whole lot of interest, much less passion, out there in the various open-source communities for fighting license battles. That's not to say that everyone agrees that there is one perfect approach to licensing. Not all all! But there is, for the most part, a pragmatic understanding and a realization that the license for a given open-source project has to match up with its governance, collaboration, and even business model. It's just one piece of the puzzle.

In a similar vein, there are just so many accumulated examples of different approaches that have succeeded. Yes, Linux is successful, and it uses GPL 2. But the very popular Apache Web server uses a much more permissive license (in the sense that enhancements don't need to be contributed back to the commons). The Firefox Web browser uses a license that's somewhere in between.

We've also accumulated a lot of evidence that open source is simply a pretty effective development model that can bring a lot of benefits to those who use it. As a result, there's less of a sense that open source needs protection through a restrictive license.

None of this is to say that lawyers and license geeks don't sometimes get into squabbles over how various licenses interact, and so forth. But, in the grand scheme of things, these are micro issues, not macro ones.

I think the best evidence for the winding down of the license wars comes from what's happening around cloud computing, which I define generally as software and infrastructure accessed in the network.

As I've written about previously, the provisions in the GPL, and many other open-source licenses requiring that modifications and enhancements to source code be contributed back to the public, often don't apply in a cloud-computing world. That's because accessing software in the form of a service over the network isn't "distribution," the event that triggers the requirement to make source code available.

Some view this state of affairs as a loophole, one that a variant on the GPL 3--the Affero GPL (AGPL)--explicitly plugs by expanding the definition of distribution to encompass the delivery of services over the network. The AGPL effectively remaps the rules from the original Unix-like environment in which the GPL was born into a network computing one.

What's striking to me is how few people seem to really care about the AGPL and the supposed problem it's trying to solve. Yes, there are the zealots who go apoplectic at the thought of open source being used for profit-making purposes. And there's a fair bit of discussion about how to best protect portability, privacy, and so forth in a cloud-computing world.

There's also no small degree of what might be best called social or community pressure on large cloud vendors such as Google to make meaningful contributions to open-source projects. But forcing all this through licenses? Not so much.

The "Is VMware violating the GPL" question is circulating again (Matt Asay follows up his own post here) so I thought it would be useful to dust off an Illuminata Perspectives that I wrote when this same thing cropped up about a year ago. I've excerpted the most salient points from the original post and added a little updated commentary.

Background:

The basic issue is as follows. As most folks involved with servers know by now, VMware ESX Server is a server virtualization product that allows multiple "guest" operating systems to co-exist on a single physical server independently of each other. ESX provides what is known as "native" virtualization--that is, the VMware software sits directly on the physical hardware; it isn't "hosted" like an application in the manner of, for example, Microsoft's Virtual Server. We usually use the term "hypervisor" to refer colloquially to this layer of software that lets virtual machines be created on top of it.

This is somewhat of an oversimplification, however. ESX Server, similarly to the Open Source Xen Project, actually has two major pieces. One is a virtual machine manager (VMM)--the layer that actually controls the virtual machines. In VMware's case, it's called the "VMkernel" and is proprietary code. The other is a service console that lets the user control and monitor the functions of the VMM. This "Console OS" is based on the Linux 2.4 kernel; it's Open Source under the terms of the GPL.

How Things Work:

The VMkernel and the Console OS are two separate pieces of code. VMware's Zachary Amsden describes how they work (in a comment to the VentureCake blog post that kicked this discussion off last summer):

First, the vmkernel is not a Linux kernel module. The vmkernel is a completely isolated and separate piece of software which is loaded by a module called vmnix. The vmkernel has no knowledge or understanding of Linux data structures or symbols, and as a necessary result, does not depend on the Linux kernel for any services whatsoever.

Second, the vmkernel does not run inside or as part of the Linux kernel. It simply takes over control of the CPU and switches into a completely alien operating mode - one where Linux itself no longer exists. The former kernel used to boot the systems is still alive, but to switch back to it is a complex and involved process, similar to the well-defined copyright boundary of switching between two user processes, which are completely separate programs, running in their own address spaces. The vmkernel and the console OS Linux kernel are two completely separate entities, and the process of going from one to another is even a stronger separation than that given to user processes - more like rebooting the processor and re-creating the entire world.

What's described here is the standard ESX Server product. My understanding is that VMware's "embedded hypervisor," ESXi, uses a Remote Command Line Interface for management that does not rely on a Linux-based foundation.

The Issue:

At issue here is that Linux (vmnix is part of the Linux-based Console OS) is involved with bootstrapping the VMkernel. Does this constitute a form of linkage that would make the entire resulting "work" (i.e. the whole of ESX Server) subject to the GPL--thereby requiring that the source code be made public?

My Take:

As Matt notes, this looks a lot like what happens when Linux loads "binary blobs" such as closed source device drivers, a long-standing practice that Linus Torvalds has blessed. There would also seem to be similarities to the bootstrap loaders used to bring up Linux (such as GRUB or LILO), which can also be freely used with Windows and other proprietary operating systems.

It is also true that some Linux kernel developers, such as Alan Cox, are on record as questioning the legality of loadable kernel modules with proprietary licenses. So, does this mean as Matt suggests, that all these uses are illegal?

This is a corner case that involves a type of linkage and relationship that the GPL doesn't explicitly cover. It's also a type of linkage and relationship between software components that Linux Torvalds, the Software Freedom Law Center, the Free Software Foundation, etc. are well aware of and have explicitly or implicitly decided that it's something they'll tolerate even if they don't enthusiastically endorse it.

But is it legal? Well, yes, until some court decided it isn't. Which is a battle that none of the most relevant players have any interest in fighting.

One of the reasons I attend O'Reilly's Open Source Conference (OSCON) is that, more so than others I go to, it gets into the intellectual and--dare I say--philosophical underpinnings of things as well as the things themselves.

To be sure, this sort of thing may not be especially important if we're talking about things like servers--although these too interact with long-term undercurrents such as massively multi-core programming  that are largely removed from day-to-day concerns but which are immensely important in the long view. In the case of Open Source, however much it has blended into the mainstream of software, is still also very part and parcel of the history and motivations behind it.

Much of that background, the continuing areas of conflict that are part and parcel of it, hints at how Open Source may evolve, and some of the opportunities (and challenges) of bringing Open Source into domains other than code were on display at the Participate 08 panel discussion yesterday. The complexities of the many interweaving threads are neatly captured in these whiteboards drawn by Collective Next during the panel.

But for our purposes here I'm going to focus on one specific thread. I'll be following up with further discussion of other points.

One of the panelists was John Wilbanks, who run the Science Commons project (within Creative Commons). He had some interesting perspectives on the concerns of scientists, as opposed to programmers. For example, in the Open Source code world, as it has evolved, attribution (at least formal attribution) isn't a component of most licenses. But, in the academic community, it's all about attribution. As he described it: "the motivation is to be associated with the publication of an idea... to own a fact."

This is a potentially huge disconnect between the data/science world and the code world. This is especially so because attribution clauses are not a part of most Open Source licenses for deliberate reason. The problem is that attributions "stack"--that is, they acquire threads of contributors that may go back years. Thus, to have a legal requirement to preserve some list of all that historical accretion of intellectual property would get enormously unwieldy to implement in a practical way.

Academics deal with this sort of thing all the time. However, it's handled within the context of social norms and customs and violations are dealt with largely by corresponding social censures rather than legal ones. Attribution is serious business in academia--but it's not implemented through formal legal strictures that require literature searches for previously unknown Russian papers of 30 years past. (Of course, there are often bruised egos and perceived slights all the time--welcome to the world--but these are issues mostly resolved within a community rather than in a court of law.

As a side issue, John also noted that, in the sciences, he does not recommend that work be limited to non-commercial use or to prohibit derivative (i.e. transformed) use of the work. He said that such restrictions have a very chilling effect on integration and federation. I've written previously about the Non-Commercial clause of some Creative Commons licenses in the context of photographs. Increasingly strictures against commercial use, an area that Open Source code licenses have largely stayed away from to their betterment, seem to be something that appear reasonable and fair but, in fact, have far more cons than pros.

As open data, creative writing and media, and code merge, we're going to increasingly need to reconcile the issues that matter most to the communities who own the copyrights to their respective bodies of work.

A couple weeks ago, the Linux Foundation released a podcast interview with Linus Torvalds that, among other topics, touched on if or when Linux would "upgrade" from the GPLv2 license to the new GPLv3 version that was approved last year after much acrimony. Allison Randal's summary over at O'Reilly Radar seems about right: "In the end, what we have is a stable system by reason of inertia. It may eventually shift, but not anytime soon."

One major reason is that Linus just doesn't see any compelling reason to make the shift--which is to say that he doesn't see any particular advantage to Linux at this time. That said, he's indicated the relicensing of OpenSolaris under GPLv3 could persuade him to make such a move. (Sun Microsystems floated such a move as sort of a trial balloon but it was shelved--at least for a bit--because of vocal objections from the OpenSolaris community.) In other words, if shifting Linux to GPLv3 would give Linux access to code that it wouldn't otherwise be able to use, that could be interesting. On GPLv3--as on many other matters--Linus is a rather pragmatic individual. Truth be told, far more pragmatic than many of the other highly visible personalities around open source.

Thus, don't expect Linus to push Linux toward the GPLv3 for philosophical reasons. Indeed, he's objected loudly to the GPLv3--although his more recent rhetoric has calmed--precisely because it essentially makes philosophical judgements about allowable uses (especially Digital Rights Management) that have nothing directly to do with code.

However, in the wake of this interview, a meme was also making the rounds that it would be difficult from a practical and legal perspective to move Linux over to the GPLv3. At issue is that Linux (as in the Linux kernel) is licensed under GPLv2. Some GPL’d software is licensed under the terms “GPLv2 or later,” but not Linux itself. Furthermore, contributors to Linux do not assign their copyrights to some other controlling entity--as do, for example, contributors to the Free Software Foundation’s GNU project. Thus, the logic goes, relicensing Linux under GPLv3 would require getting agreement from hundreds of contributors or more--and, perhaps, even having to rewrite code submitted by people who don't agree to the shift or who couldn't be contacted.

I'm not a lawyer and have no legal opinion on this, but I wanted to point out that Eben Moglen discussed this situation at the Red Hat Summit last May. While certainly not a definitive opinion, as the former general counsel for the Free Software Foundation that created the GPL, Eben's voice surely carries some weight. As I noted in a piece I wrote at the time:

From Eben’s perspective, “My guess is that Linux is a collective work…as evidenced by a decade of LKML [the Linux Kernel Mailing List] discussions. That’s my guess.” So, while it remains very much an open question whether Linus (and the other lead kernel developers) would want to make the move to GPLv3, it’s unclear that there are any fundamental roadblocks (such as having to get explicit agreement from every person and organization who ever contributed to Linux) should he choose to do so.

To be sure, the answers to legal questions are often ambiguous; as Eben also noted, there are alternative theories that could play here as well. However, if Linus and the other key kernel developers were to back a shift to GPLv3, and if there were reasonable legal air cover from respected Open Source authorities for doing so, it seems unlikely that we'd see a substantive challenge to such a move. Oh sure, there would be loud hand-wringing over at Debian and in other forums--this is open source after all. But, as a practical matter, I'd expect any "controversy" to blow through pretty quickly.

I think that Alfresco's Matt Asay and I share some of the same concerns about the current spate of lawsuits that BusyBox and the Software Freedom Law Center (SFLC) have been busily filing. On the one hand, open-source developers have to protect their rights. However, as Matt notes:

My primary concern is that this (and the other two ongoing BusyBox lawsuits) will create more misunderstanding about the requirements the GPL imposes. It won't be helpful to have this result in less GPL-licensed software being adopted.

Put another way: if using GPL software comes to be seen as an invitation to get sued, fewer people will use GPL software. Whether individual enforcement actions can be justified isn't really the point. It's whether, collectively, copyleft-style licenses (including the GPL) start to look more legally risky than beneficial. CNET.com's Stephen Shankland took a look at SFLC's increasingly hard-line approach to license enforcement in "GPL defenders say: See you in court."

The latest BusyBox lawsuit against Verizon seems especially problematic.

Essentially, Verizon distributes Actiontec MI424WR routers to its customers for its Fios Internet service. It's unclear to me whether the device is sold or loaned or given away as part of the service; perhaps it's different by geographical location as I've heard conflicting experiences. In any case, the router is an integral part of Verizon's service. The routers use firmware that contains a variety of GPL software including BusyBox, a set of small versions of many common Unix utilities combined into a single executable.

The crux of the complaint is that Verizon allows its customers to download the router firmware from Verizon. Thus, although Actiontec apparently provides source code as required by the GPL on its own Web site, Verizon does not. It's also unclear whether the Verizon firmware is identical to Actiontec's and, if there are differences, whether they are relevant to the GPL or BusyBox. Regardless, the complaint focuses on the fact that Verizon offers firmware binaries for download without offering the corresponding source code; it makes no mention of Verizon distributing the binaries for a unique version of BusyBox.

Because Verizon is distributing firmware binaries without an offer of source code, this would, in fact, appear to be a violation of the GPL.

But it seems a rather picayune and hyper-technical one--especially if the Verizon firmware uses the same BusyBox code that is already available on the manufacturer's Web site.

It seems only a small step from this case to others that would raise some real concerns about using open source. I'm not a lawyer and draw no conclusion about whether these different sets of facts could trigger GPL violations or not. I merely note that they're close enough to the Verizon case that fine legal parsing would be needed to distinguish them.

• What if the entity distributing the routers was less clearly an OEM and more of a conventional retail outlet or electronics distributor? Presumably Best Buy doesn't today have to offer open-source source code for all the products that it sells, but what if it were to offer downloads to drivers and such as a convenience to customers? Could it run afoul of the GPL in the same way as Verizon?
• And why exactly does it matter whether the software binaries are being offered for download anyway? Even if they're just burned into flash inside the device, how is that different?
• OK, you say. So long as the hardware device comes with a piece of paper of whatever pointing the user to some source code download location at the original manufacturer's Web site, there's no problem. I guess that means that stores need to be careful about selling products in OEM packaging (i.e., not retail boxed). How would Micro Center even know whether some unboxed Seagate drive they're selling uses GPL code in its firmware or not?

To my non-lawyer (but reasonably open source-educated) eyes, these cases aren't clearly unique from that of Verizon. And, if they can't be clearly distinguished, they suggest scenarios that would be troubling to a lot of vendors making use of GPL software.

(Throughout this post, I've used the generic term "GPL." The new iteration of the license, GPLv3, includes some specific language related to end-user hardware devices that may or may not be relevant in this context. In any case, the reality is that the vast bulk of existing GPL software still uses the GPLv2 version.)

A few days back, I posted about the difficulty of distinguishing commercial from noncommercial usage with respect to the Creative Commons license.

There's an ongoing legal case that concerns another aspect of Creative Commons commerciality. As Josh Wolf describes the original story:

On April 21, 2007, during a church camp, Chang's counselor snapped a photo of her and uploaded it to his Flickr account. He published the photo under a CC-BY-2.0 license, which allows for commercial use of the photo without obtaining permission from the copyright owner.

In less than two months, the photo had been cropped and repurposed to promote Virgin Mobile in Australia.

Upon learning of the ad, Chang wrote on a Flickr page, "hey that's me! no joke. i think i'm being insulted...can you tell me where this was taken." Underneath Chang's comment, there is a note from the original photographer: "where was this? do you think virgin mobile will give me stuff?"

It's unclear whether Virgin coughed up any loot, but Chang's family has taken legal action against the company for not obtaining proper permission for the use of her likeness.

The basic legal problem here is that, although the photographer gave his permission for Virgin Mobile Australia (or anyone else) to use the photograph for commercial purposes (with attribution), that doesn't mean that all the rights were cleared to use the photo in an advertisement. A stock photo--which is essentially how Virgin Mobile Australia was using the image--typically requires model releases from any identifiable person. Releases may also be needed for photographed property under some circumstances. Identifiable trademarks and the like can also be an issue.

It seems a rather fundamental error on Virgin Mobile Australia's (and even more so their ad agency's part). I guess they just assumed that the Creative Commons photo was like an ordinary stock photo where someone had taken care of clearing all the rights.

But as Larry Lessig says--with the dropping of Creative Commons itself from the suit:

As I said when I announced the lawsuit here, the fact that the laws of the United States don't make us liable for the misuse in this context doesn't mean that we're not working extremely hard to make sure misuse doesn't happen. It is always a problem (even if not a legal problem) when someone doesn't understand what our licenses do, or how they work.

The intent of Creative Commons is that the photographer (I'll stick to photography here) can give his permission for commercial, or noncommercial, entities to use his or her work without compensation. It is not, however, intended to be a representation that all the commercial rights to use the photograph in any context have been cleared. In fact, with Creative Commons licenses that permit modification of the final work it's hard to see how it would even be possible to certify in advance that any possible use was permitted under all laws anywhere in the world. And even stock sites place a variety of restrictions on the final use.

This seemed a fairly obvious point to me. But as I read stories and comments in this case, it seems that a lot of people assume that licensing a photo for commercial use under Creative Commons is, in fact, warranting it as unconditionally appropriate for commercial use rather than merely giving a narrower set of permissions strictly from the photographer's perspective.

Back when I was writing software for PCs, it was pretty common to see licenses offering some program free "for noncommercial use" or some similar wording. The basic idea was that if you got people using some application at home, maybe they'd want to use it at work too--and then they'd buy a commercial license. Besides, very few of those home users were about to send you a check anyway. It's a little bit like using an open-source business model to build volume and awareness with free, unsupported software and then make money from support contracts when a company wants to put the software into production.

There's a difference though.

No widely used open-source software license that I know of makes a distinction about how the software is going to be used. Rather, open-source licenses concern themselves with essentially technical details about how code is combined with other code and what the resulting obligations are with respect to making code changes and enhancements available to the community. But none of the major open-source software licenses restrict use to schools or personal PCs or anything like that. ... Read more