Fundamentals of Copyright Law

The phrase "open source license" refers to a large number of agreements that license the copyrights inherent in software widely, fairly, and with the fewest restrictions possible. This article -- the first of two -- describes the tenets of copyright and explains the intents of an open source license. The second article in this series explores individual licenses, such as the GNU Public License and the Apache License.




In the 1600s, the British government faced an almost
constant threat from pirates. In fact, in a span of less
than a decade, Barbary corsairs plundered nearly 500
merchant vessels, commandeering the ships and and selling
the crews and passengers into slavery. The pirates roamed
with impunity, often ransacking and even decimating coastal
settlements.

But the corsairs weren’t the only pirates profiting at
the time. The invention of the printing press by Johannes
Gutenberg in 1436 greatly simplified the manufacturing — and
piracy — of books. Armed with moveable type presses,
Scottish plagiarists “looted” British booksellers by selling
bootlegged tomes at 30 to 50 percent less than the price of
an original.

So, beginning with The Licensing Act of 1662 (a
law that granted a state-sanctioned publishing monopoly to
twenty or so booksellers), then improved in The Statute
of Anne in 1710,
and further clarified by the case of
Donaldson v. Beckett in 1774, British Parliament
created much of the modern notion of “copy right”, a law
that grants certain exclusive rights to the author, or
proprietor, of a creative work.

In particular, Parliament created “copy right”
(literally) as the right to manufacture copies. The
Statute of Anne
mandated that an author or a
duly-appointed agent of the author could exclusively
reproduce a particular book on a particular (physical)
printing press and sell those copies to the public. In
effect, “copy right” granted the author an entitled monopoly
and made it a criminal offense for anyone else to print
unauthorized copies of a work.

But in response to the favoritism demonstrated in the
Licensing Act of 1662, the framers of the Statute
of Anne
chose to limit the term of an author’s monopoly
to 21 years. With that term limit affirmed in the case of
Donaldson v. Beckett, the Statute of Anne
deemed that once a “copy right” expired, the associated work
became unencumbered, allowing the work to be freely consumed
by the general public and be freely duplicated by any
publisher. In other words, once an author’s “copy right”
expired, the work matriculated to a “public domain” — a
novel and compelling notion that didn’t exist prior to 1774.

Copyright is (Still) Fundamental

Today, nearly three hundred years after the Statute
of Anne
passed into law, the same fundamental tenets of
copyright remain and the rights of an author prevail as an
essential impetus to create new works. Indeed, copyright has
been expanded frequently and greatly since 1710 to
comprehend emerging technologies, to protect innovative
forms of creative works of all kinds, and to protect the
author’s entitled monopoly.

For example, the International Copyright Act of
1886
gave an author the exclusive right to produce
translations, and the British Copyright Act of 1911
extended copyright protection to sound recordings and works
of architecture. (Similarly, the United States’s revision of
its Copyright Act in 1909 also broadened copyright
protection to music and further to all works of authorship.)
More recently, a revision of the U.S. Copyright Act
in 1976 extended copyright protection to unpublished works
and codified what constitutes “fair use”. And in 1998, the
United States’s (much-maligned and sometimes ambiguous)
Digital Millenium Copyright Act granted protection to
boat hull designs and allowed computer users to make
temporary copies of computer programs for the purpose of
maintenance (among other changes). Copyright now protects
photographs, screenplays, images (as created, say, in
Photoshop), typefaces, web pages, sound effects, movies, and
more.

Of course, copyright has also been expanded to protect
software, which is yet another (albeit rather unique) form
of authorship. As it does for a novelist, painter, and
musician, copyright extends certain exclusive rights to the
creator of a software program. (Copyright is often referred
to as a “negative right,” because it restricts what others
can do with the work.)

The Privileges of
the Software Developer

Specifically, the privileges of a software developer
(like any other author) include:

  1. The right to produce copies of the work and to
    sell those copies (including electronic copies and
    executable binaries).
  2. The right to create
    derivative works. A derivative work is based upon one or
    more pre-existing works and is also considered an original
    work of authorship.
  3. The right to sell or assign
    any of the rights granted by copyright to others.

(Copyright provides other rights to a creator; see
United States Code, Title 17. Also, an author can be an
individual or a group; if the latter and if the work was
created in concert and intended to be used as a whole, the
work is considered a joint work and the rights
provided by copyright are controlled by the group.)

According to these rights, the author of a piece of
software is its sole proprietor and is has complete control
over how the code is reproduced, sold, and reused. And
interestingly, an author may not waive any of the rights
provided by copyright. However, an author can choose to
transfer or license any subsisting rights, either wholly or
separably, according to his or her own terms.

A License to Code

The term license essentially means
permission. The copyright holder, or licensor,
grants another person or entity, the licensee,
specific permissions to use the work, typically for a
specific term and in a certain well-defined territory (such
as the world, North America, or Spain) in return for some
consideration, which may or may include monetary
compensation. If money is part of the consideration, a
licensor can ask for a one-time payment, a royalty, or a
combination of the two.

The term license is also commonly used to refer
to the (legal) document that captures the terms of the
agreement between the licensor and licensee. Hence, a
software license is an agreement that dictates how a
piece of software can be used. For instance, a proprietary
software license may grant you the permission to run a
program, but not see its source code.

The phrase “open source license” is an umbrella for a
large number of agreements that try to license the
copyrights inherent in software widely, fairly, and with as
few restrictions as possible. No doubt that you’ve heard of
the Berkeley Software Distribution (BSD) license, the
first open source license, created in 1993. Other notable
open source licenses include the GNU Public License,
the Apache License, and Sun Microsystems’s Common
Development and Distribution License.
In fact, there are
more than fifty open source licenses listed on the Open
Source Initiative (OSI) web site at href="http://www.opensource.org">http://www.opensource.org.

Each of those open source licenses is tailored to meet
certain goals for specific kinds of content (for example,
some for software, others for documentation, still others
for images or data) and varies in its terms, but each shares
five fundamental intents (borrowed from attorney Lawrence
Rosen’s 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.

As mentioned earlier, the rights subsisting in a piece
of software cannot be waived by its author, but must be
transferred or licensed. Here, all of the intentions begin
with the word “licensees”, declaring that each of the
specific permissions are being granted only under the terms
of a license. A licensee can agree to the terms and enjoy
the prescribed permissions or forego using the the software.

Intention 1 is plain enough, but its extent is both
broad and subtle. Open source software doesn’t require the
licensee to audit usage, justify any application, or
document the deployment.

Intention 2 is also clear, but what the grant doesn’t
say is important, too: Consistent with Intention 1,
Intention 2 does not impede the sale of open source
software. So while you can make copies and distribute them,
both freely, you can also sell such copies unemcumbered.

Recall that a derivative work is one that’s based on a
pre-existing work, yet is also considered to be a new work.
Intention 3 builds on the previous two intentions, insuring
that a licensor cannot charge for the privilege to create
and distribute a new work, nor can the licensor impose any
restrictions on derivative works.

Derivatives of a software work can rarely be created
without the original work’s underlying source code.
Intention 4 stipulates that open source software be
transparent, available as source code for no fee.

Finally, Intention 5 builds on the preceding intentions
and grants the licensee the ability to mix open source
software with other software. But more important, Intention
5 doesn’t necessitate restrictions on an end-user. An
end-user can mix and match open source software with any
other software.

All of these intentions are affirmative and hardly bar
the licensor or licensee from imposing additional terms. For
example, a licensor could ask for reciprocity — that a
licensee must provide the software according to the same
terms it agreed to — and still remain open source software.
A licensee can profit from the sale of the software. A
licensor can provide the software under more than one
license, perhaps one that is open source and one that’s
proprietary. Certainly, while the latter license is not an
open source license, an open source license does not
preclude other simultaneous licensing terms.

While it may seem shocking that there are at least fifty
OSI-approved licenses, the licenses vary to suit the
content, the purpose, and the needs of the licensor. (Even
so, OSI has admitted that there are too many, and that it
hopes to reduce the number of approved licenses to perhaps
six or seven.) The GPL realizes the goals of open
source software licensing differently than the Apache
License,
but both are firmly rooted in copyright (and
contract) law and reach the same ends, albeit with different
means.

Not All Open Source Software Licenses Are Equal

While all open source licenses share
similar intentions, each license typically accomplishes its
goal via different means. One license may grant rights
liberally, while another may be far more restrictive.

In other words, just because you can download, compile, and
link two open source software packages together in a single
application doesn’t mean you can legally combine the code.
In some cases, the specifics of one open source software
license may render it incompatible or even in opposition
with the terms of one or more other licenses.

The second half of this series will explore compatibility
issues further. In the mean time, before you mix-and-match
code from different open source projects, vet each open
source license with counsel.

Choosing the Right License

If you intend to start an open source software project
or want to release existing software under an open source
license, consider the following questions:

  1. Is your work encumbered in any way? For example,
    is your work derived from another work? If so, what terms
    did you agree to as a licensee? Are you able to warrant that
    you have all of the rights you are granting to the
    licensees?
  2. Who holds (or will hold) the copyrights in the
    software? Is the work (will the work be) a joint work?
  3. Do you want access to your licensees improvements? If
    so, how do you want the reciprocity to work?
  4. Do you want to make money from your open source
    software? How?

There are many, many other factors to consider, and
depending on the scope and scale of your project, you may
want to engage the services of competent legal counsel to
help address all of your issues.

On the other hand, you may find that an existing open
source license meets your project’s needs. The OSI web site
has any number to choose from and many software companies
now have their own. For example, Sleepycat Software
(http://www.sleepycat.com), the makers of Berkeley DB, and
MySQL AB (http://www.mysql.com), the creators of the MySQL
database, have created so-called “dual licenses” that
provide open source software to the community under generous
open source license terms and for-profit software under
commercial licenses to corporations for use in products and
production environments.

The second half of this series will investigate a number
of open source licenses and look at the benefits and
obligations of each one — necessary information whether you
want to adopt some open source software in your own project
or want to launch the next great open source project.

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
trivia game and
the
After Dark screen saver
. Martin earned a Master of Science degree in computer science from Purdue University.
His first job after graduate school was programming UNIX for CONVEX supercomputers. This article was first published by IBM developer Works at http://www.ibm.com/developerWorks.


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