Understanding Open Source Licenses, Part Two

More than the protocols, backbones, and servers that underlie the Internet, open source licenses have facilitated the exchange of source code and ideas. Here's a look at academic and reciprocal licenses and how to use them.

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 deflowering
virgins, worshipping Satan, and singlehandedly dismantling
the once invincible British Navy) 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 nattiness is the mother of invention.

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 moveable type, gunpowder,
the sandwich, the internal combustion engine, the
light bulb, the telephone, the atom, the transistor, and the
Internet.

Arguably, the invention of the Internet is the most
impressive of all — at least to our generation — largely
because its still being invented and largely because the
Internet has become ubiquitous in a scant 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.

But 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 so-called “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):

  1. Licensees are free to use open source software for any
    purpose whatsoever.
  2. Licensees are free to make copies of open source software
    and are free to distribute those copies without payment of
    royalties to a licensor.
  3. 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.
  4. Licensees are free to access and use the the source code of
    open source software.
  5. Licensees are free to combine open source and other software.

All of these intentions are affirmative: none prevent the
licensor or licensee from imposing additional terms. In
fact, there are more than fifty unique Open Source
Initiative-approved licenses listed at
http://www.opensource.org/, each with its own mechanics,
requirements, and restrictions.

Fifty licenses may seem like a daunting number, but most of
those open source licenses 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 Public
    License,
    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):

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 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 GNU General Public
License,
or 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:

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:

  1. That the licensed software is provided in source code form
    (and may be provided in other forms according to other
    clauses).
  2. That the licensed software may be may
    be used for any purpose whatsoever.
  3. That the
    licensed software software may be modified freely and
    combined with other software to create derivative works.
  4. That the licensed software may be redistributed.

Like the MIT License, the GPL also meets all
of 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 of 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 via
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
very cognizant of all of your obligations as a licensee,
according to all of the licenses you’ve agreed to.

In general, mixing code from various licenses in a
collective works present 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 instance, if
you’ve adopted and incorporated software licensed via 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 the license is unconstitutional.
Others take offense at the GPL’s reciprocity. And even one
plaintiff has sued the Free Software Foundation, claiming
the GPL attempts to fix software prices at zero, 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.

Martin Streicher is the Editor-in-Chief of Linux Magazine. This article first appeared on developerWorks in November 2005.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62