There’s No Such Thing as a Free (Software) Lunch

June 14, 2004
Volume 2, issue 3

Download PDF version of this article PDF

There's no such thing as a free (software) lunch

Jay Michaelson, Wasabi Systems

What every developer should know about open source licensing

“The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software to make sure the software is free for all its users.”1 So begins the GNU General Public License, or GPL, which has become the most widely used of open source software licenses. Freedom is the watchword—it’s no coincidence that the organization that wrote the GPL is called the Free Software Foundation—and that open source developers everywhere proclaim, “Information wants to be free.”

As the GPL indicates two paragraphs later, however, “To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights.”2 As most open source software developers know, this means that, in practice, the GPL is actually one of the less “free” software licenses out there because it requires anyone who modifies a GPL’d program to make the program’s code freely available, if the program is “distributed” to others.

IS THE SKY FALLING?

Microsoft and other big players in the proprietary software business are almost continuously accused of spreading enormous amounts of FUD (fear, uncertainty, and doubt)3 with regard to this particular requirement. They and their allies have even argued that the GPL threatens national security. In addition, some have also claimed that the contents of a Linux server may be unprotected, and they have warned of everything short of the sky falling—and once someone gets a patent on clouds, they’ll probably warn about that, too.

The Linux community has responded in kind and, to be completely fair to companies such as Microsoft, has capitalized on equally paranoid fears on the part of some of its larger users. The Chinese government, for example, has an official policy of using Linux because it believes that Microsoft software is part of a U.S. plot for world domination.4

What all this chaos means for developers is that it’s often hard to know whether or not the GPL will be a factor in a given project. This article should help clear the waters.

Now, to give you fair warning, I’m not entirely objective myself as I happen to be a founder of a BSD (Berkeley Software Distribution) development company, Wasabi Systems. Much of our business is based on helping OEMs embed NetBSD in networked storage devices, Internet infrastructure, and other embedded systems. We also work extensively with the GNU tools, most of which are governed by the GPL. So you might say I’m an open source partisan, though perhaps not quite a Linux partisan.

OPEN SOURCE LICENSES

Here’s a brief discussion of what the various open source licenses are: The GPL we have already discussed—and it’s the most widely used open source license. GPL partisans like to call it a “protective license” because it ensures that code covered by it will remain open source forever. In addition to the GPL, such licenses include the Artistic License,5 LGPL (GNU Lesser General Public License), v.2.1,6 IBM Public License v.1.0,7 Mozilla Public License v.1.0 and v.1.1,8 Open Software License v.1.1,9 and Sun Public License v.1.0.10

All of these licenses have slight variations in them, and there are about a dozen more in use. In fact, open source licenses are some of the most intensely engineered products the open source community develops.

THE BSD LICENSE

The BSD license is the second most widely used open source license. Its most significant difference from the GPL is that it does not require that anything be made open source. You can, if you like, take the entire NetBSD operating system, change one line of code, and then make the whole thing proprietary and try to sell it as YourOS. For this reason, a variant of BSD is now the second most widely used desktop computer operating system. Apple took pieces of Mach, FreeBSD, and NetBSD, created Darwin, and then spun Darwin into Mac OS X. There are large pieces of OS X that are now closed source software, even though they are based on BSD. That’s one of the features of the BSD license: it leaves to folks like Steve Jobs and the crew over at Apple the decision of whether they want to share or not.

Similar to the BSD license are the Academic Free License v.1.2,11 Apache Software License v.1.1,12 Artistic License (which governs Perl),13 Attribution Assurance License,14 BSD License,15 Sun Industry Standards Source License,16 University of Illinois/NCSA Open Source License,17 Vovida Software License v.1.0,18 W3C Software Notice and License,19 and Zope Public License v.2.0.20 Once again, there are other licenses as well.

MICROSOFT SHARED SOURCE

Lately, Microsoft has been promoting Shared Source software,21 a move that to some looks like an attempt to capitalize on the open source groundswell. Shared Source basically means that eligible developers and companies can access the code to certain Microsoft software if they sign up for the program. So far, because the Shared Source Initiative is still young, the fate of its developer community cannot be predicted.

FREE—SORT OF

Finally, there are software licenses where code is not shared at all. There is software that may be free to use, but not free to modify or dissect. And, of course, there is software that you have to pay to use and you never get to see the code, like the word processor I’m using right now (Corel WordPerfect—I’m a die-hard).

Harvard Law School Professor Lawrence Lessig, author of the book Code and Other Laws of Cyberspace,22 arbitrator in the Microsoft antitrust case, and a leading expert in the “law of cyberspace,” points out that because of all the rhetoric about “free software,” we often get a skewed view of developer rights and responsibilities. The conventional matrix looks like that shown in table 1.

That matrix is accurate from the perspective of the code itself. As we will see, the GPL ensures that the code will be free forever. From the perspective of a developer, however, the GPL actually imposes significant restrictions. Suppose you are an embedded systems developer, and you want to take GPL’d software, modify it, and roll it into your company’s product. If that product is going to be sold (“distributed”), you must make all of the resultant code open source—including your modifications. Now, the GPL does not affect other applications that may interact with the modified code, which is why it really doesn’t present a problem in most desktop or server applications. But in the embedded space (the one I’m closest to), OEMs regularly spend hundreds of thousands of dollars modifying and customizing the operating system kernel itself or adapting various device drivers. The GPL restricts the abilities of these OEMs to do what they want, which in most cases is keep the code secret. They’ve invested a lot of money in development, and they would prefer not to share that development with their competitors.

So, from the perspective of a developer’s choices, the matrix should really look like table 2.

FREEDOM AND ITS CONSTRAINTS

In short, what promotes the most code freedom is not the same as what promotes the most developer freedom. When the information is freest, the developer may be most constrained.

I can hear the Linux crowd shouting now, so let me acknowledge their main fear: If nasty corporations are allowed to take the code and not share their modifications, open source software development will be undermined. The premise of the open source model is that developers worldwide are working to improve software. This model won’t work if developers take their marbles and go home.

In theory, that makes a lot of sense. In practice, however, a far more complicated situation has emerged. First, many OEMs do share their BSD-licensed code—some because they want to be good citizens, and others because they want their code to be continually updated and improved by others. They may just not want to do so right away. Companies such as Wasabi have been told by clients, in effect, to wait six months and then release everything, the theory being that six months is enough of a jump on any competitors.

Second, as embedded and nonembedded Linux companies have struggled to find a business model, Linux itself is fragmenting. The great fear of the BSD license was supposed to be “code forking”: some developers would spin off their own versions of BSD, and communities would fall apart. This happened, to some extent; there are at least four flavors of BSD being used today. But Linux, unlike the BSDs, strictly speaking refers only to the Linux kernel, and there are dozens of versions of Linux with different TCP stacks, modules, etc. Moreover, and here we come to the stickiest part of the GPL, while “derivative works” (a standard copyright term) are required to be GPL’d, works that are either separate from or are in a “mere aggregation” (a GPL term) with the GPL’d software are not. In a drive to somehow make money from Linux, some Linux companies have created large modules that load after the kernel is booted, and thus—they say—are exempt from the GPL.

GPL EXEMPTION?

Most of the rest of this article tries to ascertain whether that’s true or not, but note at the outset that the whole enterprise runs contrary to the theoretical premise of GPL’d open source software: that we’re all working on the same project here. Either the Linux companies’ additions are trivial, in which case their customers are getting a raw deal; or they are significant, in which case they’re not really playing the open source game in a fair way. They’re looking for loopholes.

I’m not going to spend much time on the recent lawsuit by SCO alleging that Linux itself contains bits of Unix code (which is SCO’s intellectual property) and that all Linux users thus need to buy a license from SCO. These claims have been widely discussed in the media and don’t really address the developer question: “OK, I have this code, I’ve done this work—what are my responsibilities?” The lawsuit is relevant to companies, which now have proof that if enough money is involved, the nature of Linux will invite litigation on behalf of the greedy; it’s also good propaganda for BSD, which settled its Unix-related issues 10 years ago. But that’s about all.

To understand the use of the GPL more fully, it’s useful to look at use scenarios and see what the developer’s obligations are in each. I’ll again focus on familiar ground by looking at the embedded space.

Suppose you modify the Linux kernel by porting it to a new hardware architecture or by making improvements in the Linux kernel. The resultant software is then embedded in a commercial device. Easy answer: The resultant code must be released—under the GPL.

Ordinarily, hardware drivers are part of the kernel, so they, too, must be released pursuant to the GPL. To protect proprietary hardware drivers, however, prominent Linux users such as TiVo have built them as loadable modules that load after the kernel has booted. They keep those modules proprietary. TiVo’s Jim Barton said in a previous issue of ACM Queue that “the use of proprietary modules... is the key to the use of Linux in embedded systems.”23

PROPRIETARY MODULES

But are proprietary modules kosher or not?

Depends on whom you ask. People associated with the FSF have said no—but then again, the FSF doesn’t actually own the copyright to the Linux kernel, so it wouldn’t have standing to sue. The conventional wisdom in the embedded Linux industry is that Linus Torvalds has said proprietary modules are OK, but what he has actually said is more subtle.24 According to Torvalds, if a driver is a derivative work of the Linux kernel (more on that later), it’s covered by the GPL, regardless of when it boots. But he takes a more restrictive definition of “derivative work” than the U.S. Copyright Act25 does, and as a result says that if a loadable module was originally written for a different operating system and then merely ported to Linux without a major rewrite, it’s not covered by the GPL. Since Torvalds owns the copyright—and since he’s not as litigious or ideologically motivated as the FSF in any case—proprietary modules may be OK, not because they are beyond the terms of the GPL, but because the chief enforcer of the GPL as it pertains to the Linux kernel has chosen, so far, not to sue.

That may be enough for developers: Torvalds says he won’t sue, so some proprietary modules are OK (although, again, not as many as some embedded Linux companies claim). But it is definitely not enough for lawyers, particularly because the consequences of any GPL violation is the immediate termination of the license. What if Torvalds changes his mind? What if other copyright-holders are affected? What does the law actually say?

DERIVATIVE WORK

Without a court case—the GPL has never been tested in court—lawyers like me can offer only theories, not facts. But what seems to me the most plausible construction of the GPL is that a device driver that relies on the functionality of a program (say, the Linux kernel), whose job it is to get the program to operate a particular device, is a “derivative work” under copyright law, and not something that is a “mere aggregation” under the GPL. Torvalds may have a more restrictive definition, but I’m basing my interpretation on copyright law, not on my own view of the world.

A typical “derivative work” under the U.S. Copyright Act is a translation, or a recording.26 For example, your tape of a Phish show is a derivative work of the show itself, and so Phish owns the copyright to it, even though you made the tape. But the Copyright Act adds that “a work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a ‘derivative work’.”27 That is, even if the “elaborations” and “annotations” are original works of authorship, they are a derivative work of the original product.

Notice that the Copyright Act does not care whether a derivative work is “part of” the original work or not. Your Phish tape certainly “loads” well after the concert is over—that is, when you put it in your car stereo—but it’s still a derivative work. On the other hand, mere reference to another work isn’t enough. Remember the recent court case about The Wind Done Gone,28 a retelling of Margaret Mitchell’s Gone With the Wind29 from a slave’s perspective? Alice Randall, the author of that retelling, won her case because the court decided that it was actually a wholly new work, not just an elaboration or annotation. But is that really true of a device driver, or other loadable module, that merely extends the functionality of a program or allows it to operate a new piece of hardware?

Based on my experience in copyright law, I believe that device drivers, however and whenever they are loaded, are derivative works not only of the operating system kernel but potentially of other modules that they “elaborate.” But the truth is, we don’t really know, and there are reasonable arguments on both sides. Some people argue that the GPL as a whole isn’t even enforceable; certainly, there have been cases of companies simply ignoring their responsibilities under the GPL, keeping code secret, and not telling anyone about it. The FSF, I think rightly, calls this theft: by not conforming to the GPL, these folks are stealing the code that they obtained subject to it. At the end of the day, the unfortunate reality is that developers should check with their companies’ legal departments before proceeding with any GPL-related development, because the requirements may vary on a case-by-case basis.

It should be clear that, in raising these concerns, we are still light-years away from the aforementioned FUD. Applications that run atop the GNU/Linux operating system are clearly not derivative works of it; nor are pieces of data stored on it. The only time these issues come up are when works are being created, based on or modifying the Linux kernel or other GPL’d software.

TERMINATION

One important fact for developers to remember is that, according to the terms of the GPL, the consequence of any violation is a termination of the license—there is no other available remedy. What that means is, if you have distributed software that should have been released to the public, you are distributing the software illegally. FSF, Linus Torvalds, and every other copyright holder own the copyright to the “free” software you are using—it’s not “free” as in free beer, to paraphrase Richard Stallman.30 So, if you’re distributing their software without a license because your GPL terminated as a result of your violation, you may be subject to injunctive relief (i.e., a court order to stop selling products with the software on it), compensatory damages—even punitive damages.

People tend to think of Linux and other open source software as free and unowned, but it’s not. It’s owned by the people who created it—and who allow you to use and distribute it subject to the terms of a license.

LESSER GPL

We should also take note of the LGPL (Lesser GPL, formerly the Library GPL, but changed because the FSF believed it was being overused for libraries). In a way, the LGPL’s mere existence is proof of what some Linux antagonists like to claim: that because of the Copyright Act’s definition of “derivative work,” the GPL can be said to be “viral,” and can “infect” applications other than the packages directly governed by it. The concern animating the creators of the LGPL (including—full disclosure—Wasabi’s board chairman, David Henkel-Wallace) was that applications that used dynamically linked libraries could be considered “derivative works” and thus “infected” by the GPL license. The LGPL therefore excludes the GPL’s requirements as applied to applications that make use of libraries. It specifically states that an application that works with a library “is not a derivative work of the Library, and therefore falls outside the scope of this License.”

Although the LGPL is fairly narrowly constructed, the FSF believes it is being used too widely and has been trying to have libraries governed by the GPL instead. (The GNU Web site explains that by GPL’ing more and more of the GNU library, it hopes to give free software users additional advantages over proprietary users.) Thus, developers need to pay close attention to which libraries, and which licenses, they are using.

The most interesting point about the LGPL, in fact, may be what it says about the GPL: that the FSF is well aware of what a “derivative work” is under the U.S. Copyright Act, and that the workarounds on the part of some proprietary Linux shops are very, very unstable. If a party hostile to the overall success of Linux were to try to enforce the GPL against the TiVos of the world—well, let’s just say their odds would be better than SCO’s.

Of course, with the BSD license and licenses of its type, none of the foregoing issues arises. If you want to keep something proprietary, you can do it. Period.

The real problem here is that people are trying to use the FSF’s creation in a way directly opposed to the FSF’s ideological intentions. That is going to lead to trouble, and it already has. TiVo may seem like a hardware company, but as Barton wrote in the aforementioned ACM Queue article,31 most of its IP (intellectual property) is actually in its software. Is it any surprise that a proprietary software company runs into legal issues when it uses the license of the “Free Software Foundation”?

THE LEGAL ELEMENT

In my experience, what happens is that developers go about their business and try to keep legal out of it. Legal departments, for their part, often have no idea of the requirements of open source licenses, and the potential consequences for violating them—particularly legal departments of large corporations for whom software development may be only a small sideline operation. What results is a sort of blissful ignorance. If lawyers knew what they were getting into, they and company engineers would all be pretty unhappy. But the way it is now, developers try not to worry about the law, and lawyers don’t know enough to worry about the developers.

Every so often, like partisan political advertising aimed at the lowest common denominator, Microsoft’s broad invectives, among others, frighten management—even as they strike many developers as nonsense.

BSD or GPL?

My own, admittedly biased, experience—having drafted contracts for dozens of OEMs who embed BSD in their products, and having worked extensively with the GPL as well—is that the BSD License is better suited for many commercial applications than the GPL, especially in the embedded space. Wasabi, for example, has created a suite of storage products based on NetBSD without any of the uncertainty or loophole-hunting that marks a lot of embedded Linux efforts. Because it lets developers do what they want with the code, in this case the BSD license is better for business.

Now, is it better or worse for open source development in general? I’m not sure. At Wasabi we regularly contribute code back to the NetBSD project, and we also support NetBSD through other means—ranging from my own legal work to subsidizing our developers to work on NetBSD-specific projects. What we’ve found is that the hardware-specific customizations and optimizations that our OEM customers want to keep private are precisely those bits that are least interesting to NetBSD as a whole. Not always—but most of the time.

I’ve also worked extensively with GPL’d software, and have, because of my previous experience, become a more overbearing general counsel than most software developers would like. Because Wasabi and the NetBSD Project have had instances of “GPL-creep” as more and more code falls under the ambit of the license, I now recommend (or even insist) that all companies involved with modifying and distributing GPL’d software obtain a legal review before development begins and before code is either released to the public or distributed in a product.

You might ask, “Was the GPL intended to provide jobs for lawyers?” No, it just seems that way—for now.

Case Study: Apache License 2.0 and the GPL

A tempest in a teapot has recently been brewing over an alleged incompatibility between the new Apache License 2.0 and the GPL (GNU General Public License). The controversy surrounds the Apache License’s patent-licensing provision, through which each Apache contributor grants a user a license to use any patented software that falls under the license—in exchange for which the user agrees not to institute any patent-related litigation. An important point (for the controversy, at least) is that the Apache License terminates upon any violation of this restriction. The GPL, which has a similar provision, does not.

This small difference led the FSF (Free Software Foundation) to declare the Apache License “incompatible” with the GPL, because one of the fundamental tenets of the GPL is that software distributed under it cannot be encumbered with further restrictions. As the Apache.org Web site states, it’s hard to imagine scenarios where the difference really matters, particularly in light of the GPL’s own termination provisions. Nevertheless, a “further restriction” is a further restriction, and the FSF does not recommend using the Apache License—nor can GPL-covered software be distributed subject to it.

What this controversy shows is that, sometimes, software developers need to think like lawyers when they use the different open source licenses. Presumably, no one intended for it to be this way. But license writers are a partisan bunch, and the GPL brooks no deviation from its terms. Caveat licensor.

RESOURCES

Apache Software Foundation

http://www.apache.org

Apache License v2.0 and GPL Compatibility

http://www.apache.org/licenses/GPL-compatibility.html

GNU Project

http://www.gnu.org/

REFERENCES

1. For more information on the GPL, visit the GNU Website; http://www.gnu.org/.

2. See reference 1.

3. See: http://en.wikipedia.org/wiki/FUD; http://info.astrian.net/jargon/terms/f/FUD.html.

4. Smith, C. S. Fearing control by Microsoft, China backs the Linux System. New York Times, July 7, 2000; http://www.nytimes.com/library/tech/00/07/biztech/articles/08soft.html.

5. Artistic License: see http://www.perl.com/pub/a/language/misc/Artistic.html.

6. GNU Lesser General Public License: see http://gnu.org/copyleft/lesser.html.

7. IBM Public License: see http://www.opensource.org/licenses/ibmpl.php; http://www-124.ibm.com/developerworks/oss/CPLv1.0.htm.

8. Mozilla Public License: see http://www.mozilla.org/MPL/MPL-1.1.html; http://www.opensource.org/licenses/mozilla1.0.php.

9. Open Software License: see http://www.opensource.org/licenses/osl-1.1.txt.

10. Sun Public License: see http://www.netbeans.org/about/legal/license.html.

11. Academic Free License: see http://www.opensource.org/licenses/academic.php.

12. Apache Software License: see http://www.apache.org/LICENSE.txt.

13. See Reference 5.

14. Attribution Assurance License: see http://www.opensource.org/licenses/attribution.php.

15. BSD License: see http://www.opensource.org/licenses/bsd-license.php.

16. Sun Industry Standards Source License: see http://www.openoffice.org/licenses/sissl_license.html.

17. University of Illinois/NCSA Open Source License: see http://uilib-oai.sourceforge.net/license.html.

18. Vovida Software License: see http://www.vovida.org/About/license.html.

19. W3C Software Notice and License: see http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231.

20. Zope Public License: see http://cmf.zope.org/download/CMF-1.2beta2/LICENSE.txt.

21. Shared Source: see http://www.microsoft.com/resources/sharedsource/default.mspx.

22. Lessig, L. Code and Other Laws of Cyberspace. Basic Books, New York: NY, 2000.

23. Barton, J. “From Server Room to Living Room.” ACM Queue 1,5 (July/August 2003), 20-32.

24. Linus Torvalds e-mail: see http://lkml.org/lkml/2003/12/3/228.

25. U.S. Copyright Act: see http://www.copyright.gov/title17/92chap1.html.

26. U.S. Copyright Act, Section 103, Subject matter of copyright: Compilations and derivative works: see http://www.copyright.gov/title17/92chap1.html#103.

27. See reference 26.

28. Randall, A. The Wind Done Gone. Houghton Mifflin, Boston: MA, 2001.

29. Mitchell, M. Gone with the Wind. Macmillan, New York: NY, 1936.

30. Williams, S. Free as in Freedom. O’Reilly, Sebastopol, CA, 2002; http://www.oreilly.com/openbook/freedom/ch09.html.

31. See reference 23.

LOVE IT, HATE IT? LET US KNOW

[email protected] or www.acmqueue.com/forums

JAY MICHAELSON cofounded Wasabi Systems, BSD-based software company and leading provider of iSCSI-enabled storage software tools, in 2000. Currently the company’s vice president and general counsel, Michaelson is a noted expert on intellectual property issues in the technology field. He holds a J.D. from Yale Law School (where he was part of the Law of Cyberspace class immortalized in Lawrence Lessig’s book Code), and his work has been published in the Yale Law Journal, Duke Law Review, and other legal periodicals. He wrote his first program, in Basic, in 1981. It is not covered by the GPL.

Originally published in Queue vol. 2, no. 3—
Comment on this article in the ACM Digital Library