Getting It Together

This article is protected by copyright. I’ve expressed my ideas with a unique ordering of words and if the same or a strongly similar ordering of words is found in some other publication, you could be hearing from my lawyer (which in this case would be me). There’s nothing magic about this particular ordering of words—in fact a better writer might arrange them in more interesting and clever ways—but this exact ordering of words is my artistic expression, providing a foundation for my copyright.

This article is protected by copyright. I’ve expressed my ideas with a unique ordering of words and if the same or a strongly similar ordering of words is found in some other publication, you could be hearing from my lawyer (which in this case would be me). There’s nothing magic about this particular ordering of words—in fact a better writer might arrange them in more interesting and clever ways—but this exact ordering of words is my artistic expression, providing a foundation for my copyright.

If something in this column resonates with you, and you want to convey the ideas expressed in it to someone else, that’s great. It’s encouraged. That’s why I wrote this column and why Web Techniques decided to publish it. It’s supposed to be informative and help you advance your career as a Web professional. Take these ideas and use them, with or without attribution.

But what if this column were code? Instead of using this space to describe a problem with open-source licenses, what if the space were filled with lines of code comprising the latest Linux kernel or just a good JavaScript routine? That code would be no less an expression of an idea—meant to be helpful to the reader—and the unique ordering of its words, numbers, and symbols would be even more interwoven with its expression. Unlike my column, in which the ideas can be easily separated from the unique ordering of my words and pithy phrases, ideas expressed by code may be very dependent on the code itself.

I could claim a copyright on the code, but because most non-HTML code is eventually compiled, and so made private, I would have a difficult, if not impossible time establishing that someone had infringed upon my copyrighted expression. Even though I claimed a copyright on the code, I would have published it in a magazine with national distribution and read by my friends, my collaborators, and my competitors. If someone used my idea, even by copying the code line for line, could I really expect that adding “©2000” as a footer would make a difference? Would the motive to borrow, steal, or infringe have been markedly different if the code had been published as copyleft or under some other open-source license?

Trying to put rules around open code is a bit like trying to keep birds in a corral. You could build such a corral, but good luck keeping the birds inside. Whether the rules you set on your published open code are copyright, copyleft, or one of the myriad other open-source licenses now governing development efforts, good luck keeping the code inside. You might well ask yourself, why try?

The Licensing Jumble
The spirit of open source is the sharing of information and the belief that people working together solve problems better and more efficiently than people working in isolation. Experience suggests that the noble beliefs embodied in the open-source movement are, in fact, true. This really happens. Software is better when lots of people work to create it, then debug it, and use it.

But while the open-source movement may be driven by a shared belief about the benefit of working in the open, those participating in it don’t publish their work in the public domain. In the public domain, information is free to be used by anyone, for any purpose, commercial or noncommercial, sometimes even without attribution. That’s not how open source works.

Open source takes all the component parts of software and lays them bare for anyone to see, revise, or build upon. But there are strings attached. The “open” in open source refers to the ability to see the code, not the ability to use it. Before you use code from an open-source development effort, you have to promise to do so according to licensing rules set by the development team. And that’s where the problems start.

Each individual open-source effort has its own rules. Those rules probably make sense in the context of what that group is trying to do. But when you look at the big picture, viewing all open-source development projects as a part of something bigger, you realize that the pieces don’t fit together so well. In fact, sometimes they don’t fit at all.

Open-source development is proceeding under comically disparate sets of licensing rules. These restrictions usually govern what can be shared, whether someone can charge a fee or not, and what something should be named. Virtually all of the license agreements require that derivative works be placed back into the development effort under the same terms as the originally taken material.

Richard Stallman, the prime mover behind the Free Software Foundation’s GNU General Public License (GPL) describes the rationale behind the GNU GPL as “pragmatic idealism.” In other words, the license is the pragmatic step necessary to ensure that the idealism of GNU’s open development efforts are continued and furthered. The fear is that without the pragmatic restriction of a legal contract, the movement’s idealism would be thwarted by those seeking a short-term profit through the co-option of GNU’s intellectual capital.

To accomplish this brand of pragmatic idealism, the GNU GPL essentially requires three things: future distributions of any GNU-licensed material or new work based on such material must be distributed without charge; all distributions must include machine-readable source code; and all distributions must themselves be distributed under the GNU GPL.

Roadblocking Collaboration
But GNU is by no means the only development effort that asks its members to do this. Development for BSD, Linux, Apache, and Mozilla, to name a prominent few, all have their own unique restrictions, though each would properly call itself an open-source development effort. And each requires that its license be passed forward onto any future improvements or developments incorporating work published under its license.

As should be readily apparent, the differences in these various licensing agreements can become material obstacles to sharing information across open-source development efforts. At the trivial level, there’s the question of what to call the resulting hybrid. More fundamentally, there are questions about whether you can incorporate open code from a free software project as a component part of an open-source project that permits certain for-profit applications.

But whether the problem is significant or trivial, it shouldn’t take the equivalent of a United Nations summit meeting to determine whether and how to share code among different development efforts. This is especially true when the code is already open—published for anyone to see.

Other open-source development efforts as compiled by the Free Software Foundation can be found in “Online.” Interestingly, the links to the various licensing agreements are organized according to whether they’re compatible or incompatible with the GNU GPL. It might surprise open-source newcomers that most of the listed open source development efforts are deemed incompatible by the Free Software Foundation. This world is less open than it may appear from the outside.

Pragmatism Sacrifices Idealism
These incompatibilities aren’t without their costs. Not only do they prevent similar development efforts from combining their work, but they may discourage development teams from even reviewing the work of others. After all, why review someone else’s code if you fear that using it could lead to a breach of your license agreement and infringe on theirs? And even if you decided not to use their code and only to look at it, how do you draw a distinction between building on their idea and using their code when the idea and the code may be inextricably tied?

The pragmatic idealism behind open-source licenses places a premium on pragmatism, which is certainly understandable. If you remove the license, you run the risk that your ideas will be siphoned off, wrapped into an executable file, and repackaged inside a shrink-wrapped box bearing a high price tag. Perhaps most importantly, as Mr. Stallman has pointed out, without a copyleft license, developers lose an important tool in convincing their supervisors that they’re obligated to place their code back into the open-source pool.

These restrictions were established, however, at a time when open source was largely ignored by commercial and mainstream users, when you needed an explanation for management because participating in something called “free software” made you a kook. But things have changed. Although Mozilla’s promise to put an open-source application on the desktops of mainstream users everywhere has been AOLed, the mindshare captured in the Internet community by the likes of Linux and Apache has brought open source to the fore. The new economy runs on open source.

Which prompts the question, do open-source licenses still serve any purpose?

Trust the Process
To a real degree, there’s no turning back. No one questions that open-source development is a fertile working environment, producing robust applications and tools. In fact, many would argue—with ample support—that open-source development produces better applications, better servers and tools, and better operating systems.

Having established the proof of this concept, is there truly any remaining danger that unwrapping open-source works from their copyleft licensing agreements would forestall future development and lead to the outflow of intellectual property into the private sector? Is it time to turn everything over to the public domain?

The central purpose of copyleft licensing is to perpetuate the movement. If you take, you’re required to give back. At some point though, and maybe we’re already there, you give back not because you’re required to, but because the results you get when you do make it worth your while.

There’s also a generation of programmers schooled in the open-source movement who know and trust the benefits of open collaboration. They know that the work they get from a stranger in Norway, known only by an email address, is better than what the guy in the corner cubicle produces.

The widespread acceptance of open source also comes at a time when many are questioning the very foundations of intellectual property in general, and specifically, the enforceability of copyrights. Copyleft is no more immune to the threat of infringement than is copyright. While the Free Software Foundation has anecdotes about effectively denying companies the right to use their software for commercial distribution, that only happens when they’re asked first. Who knows how often open-source code is lifted into commercial distributions without anyone asking?

While woe to the company that crosses those in the open-source movement—who no doubt are vigilant in the protection of their ideals and their collectively copylefted work—is there any doubt that copyleft is virtually unenforceable? The Motion Picture Association of America (MPAA) is already chasing its tail trying to protect works that were once encrypted, for heaven’s sake. Should the open-source movement take even minimal precautions for works that are laid bare?

Licensing Last Rights
Which brings me back to my column. It’s not encrypted. It’s right here. And if you want to use any idea out of this column, use this one. Open source should think about lowering the obstacles to collaboration posed by the artificial barriers of its licensing agreements. If open source hasn’t already won the war, it soon will. And when it does, the code should be set free.

Bret is an intellectual property and Internet attorney, and a partner with Hancock, Rothert & Bunshoft. You can reach him at

Author: Bret A. Fausett

News Service:


Leave a Reply

%d bloggers like this: