 | Level: Introductory Martin Streicher (mstreicher@linux-mag.com), Editor in Chief, Linux Magazine
15 Nov 2005 Open source licenses provide the legal foundation for propagation of open source code. This article, the second of two in the "Open source licensing" series explores the two most popular forms of open source licenses -- the academic license and the reciprocal license -- and describes the obligations of licensees that accept the terms of each.
A popular legend credits the creation of the sandwich to John Montagu, the Fourth Earl of Sandwich. According to the story, Montagu was too busy gambling and cavorting to have a proper meal, so he ordered a slice of roast beef placed between two pieces of bread to keep his fingers and playing cards clean. Alas, sometimes waywardness is the mother of invention.
|
This is not legal advice
This series is intended to introduce readers to the basics of open source licensing. Neither open source licensing nor copyright are settled areas of law. Both will continue to evolve after the publication of this series, which may render details of this series obsolete.
Also, neither the author nor editors involved in the publication of this series are licensed attorneys, and the author is not an IBM employee. This series is not intended as legal advice. Accordingly, you should consult an attorney before making decisions regarding copyright issues.
|
|
Whether the lore of the sandwich is fact or fiction, there's no denying that even the most serendipitous invention can have big repercussions. Consider movable type, gunpowder, the sandwich, the internal combustion engine, the light bulb, the telephone, the transistor, and the Internet.
Arguably, the invention of the Internet is the most impressive of all -- at least to our generation -- largely because it's still being invented and also because the Internet has become ubiquitous in a very short time, affecting commerce, communication, culture, and yes, vice. Montagu would have loved the browser.
And certainly, if you're reading this, you probably appreciate just how much the Internet has changed software development. Source code has long appeared on bulletin boards and in certain Usenet newsgroups (where else could you download the latest version of Rogue in 1986?), but a fast and global Internet popularized sharing.
Perhaps more than the protocols, backbones, and servers that underlie the Internet, open source licenses have facilitated the exchange of source code and ideas. Indeed, many of the Internet's most instrumental applications -- Linux®, Apache, MySQL, Perl, PHP (the "LAMP" stack) -- are all provided via open source licenses. Open source licenses try to license the copyrights inherent in software widely, fairly, and with as few restrictions as possible.
The intent of open source licenses
In particular, all open source licenses share five fundamental intents (borrowed from attorney Lawrence Rosen's book Open Source Licensing: Software Freedom and Intellectual Property Law and used with permission):
- Licensees are free to use open source software for any purpose whatsoever.
- Licensees are free to make copies of open source software and are free to distribute those copies without payment of royalties to a licensor.
- Licensees are free to create derivative works of open source software and are free to distribute those works without payment of royalties to a licensor.
- Licensees are free to access and use the source code of open source software.
- Licensees are free to combine open source and other software.
All these intentions are affirmative; none prevents the licensor or licensee from imposing additional terms. In fact, there are more than 50 unique Open Source Initiative (OSI)-approved licenses listed at Opensource.org, each with its own mechanics, requirements, and restrictions.
Fifty licenses may seem like a daunting number, but most of those fall into two categories: academic licenses and reciprocal licenses.
- Academic licenses, such as the Berkeley Software Distribution (BSD) license, allow software to be used for any purpose without expectations of any kind. Software obtained via an academic license can be freely modified, sold, redistributed, sublicensed, and combined with other software, with the caveat that other software licenses may preclude such combination. (While academic licenses were originally created by universities to license academic works to the public at large -- hence, the name -- the licensor or licensee need not be an academic institution to abide by such a license.)
- Reciprocal licenses, like the prototypical GNU General Public License (GPL), also allow software to be used for any purpose, but mandate that a derivative work be relicensed under the exact same license terms. Like an academic license, a work licensed under a reciprocal license is intended for the common good. However, the reciprocal license goes further to ensure that all subsequent derivations are also made available for the common good.
 |
Academic licenses
Software provided under an academic license is essentially a "gift." You may use it unencumbered and may relicense your derivative work under a new license of your own choosing.
The BSD license is an academic license, as is the Apache Software License and the MIT License. The latter is especially concise and yet exemplifies academic licenses (the warranty clause of the MIT License and any discussion about software warranties have been omitted for the sake of brevity):
| An excerpt from the MIT License |
|---|
Copyright (c) year, copyright holders
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. |
Direct and to the point, the clauses of the MIT License align closely with the five intents of open source licenses. The word permission implies a license; the phrase free of charge indicates that no compensation is due the licensor; the clause without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies allows copying, source code access ("modify"), combination ("merge"), redistribution, and even profit ("sell"). The phrase including without limitation the rights to sublicense is an especially important one: It permits a licensee to grant licenses, but does not obligate a licensee to do so. Moreover, the licensee can set the terms of a sublicense -- the MIT License imposes no restrictions. The one condition to include the copyright notice verbatim imposes a small onus on all licensees, but otherwise isn't contrary.
Reciprocal licenses
Of all the open source licenses, the GPL is the most widely used and is the most influential. Written by the Free Software Foundation's Richard Stallman, the GPL asks software developers to simultaneously agree to and proffer a bargain to other software developers: "You can use this source code freely, but if you change it and choose to distribute your changes in any form, you must provide your source code to others under the terms of this very bargain."
Specifically, the GPL states:
| An excerpt from the GNU license |
|---|
You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work -- provided that you -- cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. |
The entire GPL is substantially longer, but the two paragraphs above represent its seminal ideas:
- That the licensed software is provided in source code form (and may be provided in other forms according to other clauses)
- That the licensed software may be may be used for any purpose whatsoever
- That the licensed software may be modified freely and combined with other software to create derivative works
- That the licensed software may be redistributed
Like the MIT License, the GPL also meets all the criteria of an open source license. Its reciprocity is merely an added stipulation.
Can you sell software licensed under the GPL? Absolutely. For example, you can download gcc, build it for your favorite flavor of Linux, and charge others for the binaries. However, you must also provide the software in source form even if you made improvements.
Can you include GPL software in your software? Yes, but your obligations depend on how you've included the code. If you distribute a binary built from GPL code and your own code, all the source code needed to recreate that binary must be made available. However, if your software is a collective work -- an assembly of independent pieces, some yours and some provided under the GPL -- only the GPL code must be made available. And at least according to Linus Torvalds, the creator and chief architect of Linux, code linked against GPL code -- say, against libavl, the GNU library for balanced binary trees -- isn't subject to reciprocity, either.
Using open source licenses
While the MIT License and the GPL are both valid open source licenses, each accomplishes its end through different means. One is not necessarily better than the other; each simply suits a different purpose.
But that renders some open source licenses incompatible with others. Oddly, even if Module A and Module B are written in C and can be blended easily by any compiler, the modules' respective licenses may preclude the combination.
If you're adopting open source code into your project, be cognizant of all your obligations as a licensee, according to all the licenses you've agreed to. In general, mixing code from various licenses in a collective works presents no issues. Each independent work retains its own copyright and license, and the collective work itself is typically distributed as a whole under a separate license chosen by the packager.
Derivative works are far more complicated. For example, if you've adopted and incorporated software licensed through a reciprocal license, your derivative work must be offered anew, according to the exclusive terms of that single, same license. Obviously, code licensed according to the GPL cannot be mixed with other code licensed under a different reciprocal agreement.
However, GPL code can freely be mixed with BSD and MIT License code. Unfortunately, though, the authors of the GPL maintain (by interpretation, not precedent) that the Apache License is incompatible. Once again, all open source licenses are not created equal. If you need to adopt code governed by different open source licenses, consult competent legal counsel.
Free, as in freedom
Critics of the GPL claim that the license is unconstitutional. Others take offense at the GPL's reciprocity. And one plaintiff has even sued the Free Software Foundation, claiming that the GPL attempts to fix software prices at $0, thus denying the plaintiff a living as a software developer.
But open source licenses are not inventing law. Instead, as this article has shown, open source licenses are firmly based in copyright law and seek to express a proprietor's wishes to share code as widely as possible. Nothing mandates that you license your code as open source, nor is there a mandate that you must agree to the terms of an open source license. You're free to choose: build, buy, or borrow. More and more developers are choosing to borrow (and lend), making open source a bargain in all senses of the word.
Resources Learn
Get products and technologies
-
Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
-
Innovate your next open source development project with
IBM trial software, available for download or on DVD.
Discuss
About the author | | | Martin Streicher is the editor in chief of Linux Magazine. Formerly, he was an executive producer at Berkeley Systems and developed award-winning software, including the YOU DON'T KNOW JACK game and the After Dark screensaver. He earned a master's degree in computer science from Purdue University. His first job after graduate school was programming UNIX for CONVEX supercomputers. |
Rate this page
| |
