Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

Open source licensing, Part 2: Academic v. reciprocal

Martin Streicher (mstreicher@linux-mag.com), Editor in Chief, Linux Magazine
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.

Summary:  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.

View more content in this series

Date:  15 Nov 2005
Level:  Introductory
Also available in:   Japanese

Activity:  12262 views
Comments:  

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

  • 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.

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Open source, Linux
ArticleID=98434
ArticleTitle=Open source licensing, Part 2: Academic v. reciprocal
publish-date=11152005
author1-email=mstreicher@linux-mag.com
author1-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.

For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers