We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Open Source Software: Free and Open Source License Myths

Originally published January 12, 2006

*Software licensing and copyright are legal issues, and if you have specific questions about their practice and application you should consult an attorney. This article should not be considered legal advice as I am not a lawyer.

Copyright can be applied to software to limit how it may be copied and distributed. As I examined in my last article, Open Source Software and the Myth of Viral Licensing, copyright alone is not enough to define what a software purchaser may do. Thus, in addition to being copyrighted, virtually all software is distributed under the terms of some license that spells out what the user is and is not permitted to do with the code.

Proprietary commercial licenses, like those under which Microsoft and Oracle offer their packages, generally forbid customers from examining the source code or even decompiling executable files; users may not make copies or otherwise share the software with others; finally, users are not permitted to distribute any modifications to the licensed software.

In other words, proprietary software vendors use licenses to maintain complete control over what goes into their software, who can use the software, who sees how it works, and who patches or improves it. Even when you are permitted to pass along copies of proprietary software, as with run-time licenses, those copies are still the property of the vendor. And the recipients are still bound by the terms of the license.

Therefore, all software licenses can be viewed as "viral": the terms of use are defined by the originator of the code, and those terms impose limits on how the code may be used.

Proprietary Software Problems
When you buy a book, you own it: you can dog ear the pages, write in the margins and highlight portions of the text. You can loan it to your friends, give it away as a gift or donation, sell it or even take it apart and hang the individual pages on the wall. You can read it in bed, on a plane, at work or at home.

But proprietary software is different: the terms of the license forbid you from doing almost anything beyond executing the binary instructions on your computer. You do not have access to the original source code, you can not make copies to run on other computers, and you are not permitted to make any changes to the code and then pass them along to anyone else. This raises some issues, mostly about trust. When you choose proprietary software, you trust that the vendor will:

  • Produce software that does what you want and only what you want. Keeping the source code secret means the vendor might sneak in a backdoor for support or compliance checking; you've got to trust the vendor to be skillful enough to do that without exposing your systems to malicious third-parties.
  • Not just find and fix bugs in the software, in a timely manner, but also that they will allocate the funds necessary to do so. You must do this even though there is no revenue associated with such expenditures. Unfortunately, they also detract from the bottom line.
  • Fix bugs you find (rather than label them "features") and hope they will add useful new features in the future. This must be done without substantially changing the software's functionality or suitability to your organization.
  • Continue to offer support for the systems you want, without mandating otherwise unnecessary operating system or hardware upgrades.
  • Not mandate significant changes in your IT platforms, hardware and software, to remain compatible with their software; likewise, to provide alternatives to costly upgrades.

All of these problems derive from so-called "vendor lockin," the commitment a customer makes when purchasing proprietary software. These problems can be solved when source code is made freely available.

This is what the open source software movement is all about: making sure that software does what you want it to, and giving you the right to fix it if it doesn't.

Open Source Software
The alternative to proprietary—or closed source—software is open source software. Just as every proprietary software vendor creates the terms for its own licenses, sometimes it seems as if every open source software project comes up with its own, unique license. In fact, there are a handful of dominant open source licenses and a few dozen more that are used less often.

Open source software is sometimes referred to as "free"; a word loaded with political, philosophical and emotional baggage that creates further confusion with its many different meanings. There are several forms of software licensing that are more or less "free" in some way, but not truly "open.” There is also "Free Software,” which we'll discuss further below.

In particular, there is a family of "freeware" software released under licenses that allow copying and use without fees. Such freeware otherwise restricts access to source code, allows only educational or personal use, or places some other restrictions on the code. Software isn’t “free” simply because you don’t have to pay for it.

Similarly, just because you have access to the source doesn't make it "open." Some proprietary software vendors, including Microsoft, offer licenses under which you can have access to source code. However, you still may not copy, modify, or redistribute that code: you can just look at it.

The Open Source Initiative (OSI) is a compliance manager for the open source community, defining and promoting the ideas of open source. There, you can find the Open Source Definition, a list of ten criteria defining open source licenses.

Most of the attributes are encapsulated in the first three criteria:

  1. Free Redistribution: Anyone can sell or give away a copy of the software, without requiring any royalties.
  2. Source Code: If you distribute the software, you must make the source code available.
  3. Derived Works: You can modify and redistribute the changes under the same license.

Open source licensing has its origins in the academic world. Regulations sometimes mandate software developed in state universities under government funding be released in a form that makes it accessible to those who paid for it: the public.

By the early 1980s, the University of California, Berkeley, was distributing their UNIX-like OS, the Berkeley Software Distribution (BSD) under the BSD License.

The BSD License grants permission to do whatever you want, as long as you incorporate the copyright and a disclaimer of liability. This is one of the earliest open source licenses. Under its terms you may do virtually whatever you want. For example, you could adapt BSD-licensed source code to create a proprietary, commercial product.

Originally, the BSD license required that advertising for any products include a line crediting the original authors of the software. Though not an issue where the author is "the University of California, Berkeley and its contributors," the clause causes serious problem when there are dozens of contributors, or when the product includes work based on dozens of different BSD-licensed projects, all of which would have to be identified in any ads. As a result, the BSD license has been amended to eliminate this problematic clause.

Even more permissive is the MIT License, reproduced here:

The MIT License

Copyright (c)

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.


In other words, as long as you retain the copyright and permission notice and the disclaimer of warranty, you can do whatever you like with the software.

Are these licenses "viral"? Yes, in the sense that they restrict the ways in which you can use licensed software. The fact that they allow the software to be modified and redistributed makes them far more permissive than proprietary licenses, but simultaneously allows for greater transmissibility of the license "virus." Every program that uses a piece of BSD-licensed code, including early Microsoft Windows TCP/IP networking stacks and Apple's Mac OS X, must be acknowledged with the appropriate copyright and warranty disclaimer.

When open source software is released under BSD-style licenses, proprietary software vendors (like Microsoft and Apple) are free to adapt the source to improve their own products. So even if such open source software gains market share, its threat is not as great to proprietary software vendors.

It's the Free Software movement that complicates matters.

Free Software and GNU
While the BSD license was introduced, Richard M. Stallman was working at MIT and examining how people use software and how it is published. Then, most software was proprietary, particularly software sold for use on then-novel personal computers. But Stallman concluded that keeping software proprietary benefited only software sellers which resulted in the production of inferior software.

But Stallman also turned his conception of Free Software into a philosophical and political movement, in which free distribution, open access to source, and the freedom to modify and redistribute the code are not enough to insure that software is Free (with a capital "F"). It's not enough, for Stallman and the Free Software movement that a program starts out as open source. If it is modified and redistributed, it must continue to be open source. The problem with the BSD and MIT licenses (and other similar open source licenses) is that they allow redistribution of modified code in binary-only form, without the source. According to Stallman, this was a fatal flaw.

At the time, Stallman was working on a UNIX-like operating system that he recursively christened GNU is Not UNIX (GNU), and started publishing the code under the GNU General Public License. Eventually, the Free Software Foundation was founded, to help support the movement; you can find a treasure trove of Free Software philosophy links. You can also read a recent interview with Richard Stallman for more.

Despite being viewed by many in the open source community as extreme, the Free Software movement is extremely successful. The vast majority of open source software is released under some form of the GPL.

The GPL is much longer than most open source licenses. This is because it incorporates much of the Free Software philosophy, as well as the license terms itself. What makes the GPL different is that not only while users are permitted to modify and redistribute source code, if they choose to do so they must do so under the same license as the original code.

Stallman set out to recursively hack the concept of "copyright" by using it to create a concept of "copyleft": you can do whatever you want with the content, including change and redistribute it, as long as you use the same license terms as the originator of the content.

Under “Copyleft,” the author copyrights the material, a process normally used to reserve all rights in the work to the owner. Under the GPL, the owner then grants the rights to copy, change, and distribute modifications to the material—but ONLY if you do so under the same terms as the original license.

The Question of Virulence
Is the GPL a virus that can infect your organization? Although it makes a large body of good source code available for anyone to use in (almost) any way, it imposes obligations for its use that are unacceptable to some users. However, GPL’ed software works well for most uses and most users. Here are some examples:

  • You install Linux on a PC, using an install CD borrowed from a colleague. You use the software to write a copyrighted book to sell both in print and online. The GPL has no effect, other than allowing you to install the software for free.
  • You use the same PC to write from scratch and compile programs that will be distributed as part of proprietary, closed-source software. The GPL has no effect, other than allowing you to use free development tools.
  • You modify a database utility program, released under GPL, to add a special search function to your proprietary package. As long as the program is separate and free-standing, you can probably release it with full source under the GPL alongside your proprietary product.
  • You grab code from a GPL'ed database utility program and compile it into your proprietary package. In this case, you've created a derivative program. You are almost certainly obligated to release it, with source, under the terms of the GPL.
  • You make modifications to a GPL'ed database program, adding some features and improving performance, and use it only on your PC. If you don't make copies, and you don't give or sell the program to anyone, you aren't redistributing the software. As a result, you don't have to license it under the GPL. (But it would be nice to give your modifications to the community by sharing them.)
  • If you modify, compile and sell a GPL'ed program as your own product, you would almost certainly be violating the terms of the GPL.

While BSD-style licenses say, "Here is some software, use it as you like," the GPL says "Here is some software, use it as you like, but if you modify and/or redistribute it you must give your users the same rights you are being given."

Things get fuzzier when dealing with tools like database servers, where you build your own applications to use with the open source tool. Here is another example:

  • You create a MySQL database application to distribute to your customers. While your application consists of your own software code, you do it with the MySQL server software to make distribution simpler. This software was installed with the original Linux distribution.

MySQL is distributed under the GPL in this case. Is there a way for you to keep your own software proprietary while still using the GPL'ed MySQL database server?

Dual Licensing with Open Source
If you create software, you get to choose how it is distributed. You may want to distribute it in more than one way. That's why MySQL AB dual-licenses its database server. Virtually identical software can be downloaded, used, modified and redistributed freely under the GPL. Such software can be purchased directly from MySQL AB.

MySQL AB offers a proprietary license so developers can distribute applications built with MySQL under proprietary software licenses. This is similar to what can be done for applications built on proprietary database servers sold by Microsoft, Oracle and others.

This approach allows MySQL to continue as a robust open source software project, with significant corporate support from MySQL AB. At the same time, it allows developers and resellers to use MySQL as a platform for their own businesses, as well as any users who need direct corporate support from the vendor.

MySQL AB publishes this overview to their dual-licensing approach; increasingly, other open source businesses are following suit.

The growth of the open source community would not hurt proprietary vendors so badly if it were not for the GPL. It restricts how software may be used that makes it impossible for traditional proprietary software vendors to benefit.

As Apple has shown with Mac OS X, proprietary vendors can provide significant user benefits by building their products WITH established open source software; one wonders whether OS X would have been as good if Apple had been forced to write the whole thing from scratch. If spreading great software of the type so often found in Linux distributions is the point, then more permissive licensing terms might be preferable. But if keeping the software free and accessible to everyone is the point, then USING THE stricter GPL makes more long term sense.

  • Pete LoshinPete Loshin

    Pete is Founder of Internet-Standard.com, an open source and open standard computing consultancy providing technology assessment, needs analysis and transition planning services for organizations seeking alternatives to commercial software. Pete has written 20 books, including “TCP/IP Clearly Explained” 4th Edition, Morgan Kaufmann, 2003) and “IPv6 : Theory, Protocol, and Practice,” 2nd Edition (Morgan Kaufmann, 2004).

    Pete can be reached at pete@loshin.com or at 781. 859.9175.

Recent articles by Pete Loshin



Want to post a comment? Login or become a member today!

Be the first to comment!