Practitioner’s Perspective Open Source Software Issues by Holly K. Towle, J.D.

advertisement
Guide to Computer Law—Number 273
Practitioner’s Perspective
by Holly K. Towle, J.D.
Open Source Software Issues
Open source software presents issues for businesses that are becoming
increasingly significant. If you are not already familiar with open source
issues, you may wish to take another look. Consider two situations:
Holly K. Towle is a
partner with Kirpatrick &
Lockhart Preston Gates
Ellis LLP (K&L Gates), an international law firm,
and chair of the firm’s E-merging Commerce
group. Holly is located in the firm’s Seattle
office and is the coauthor of The Law of
Electronic Commercial Transactions (2003,
A.S. Pratt & Sons). Holly.Towle@KLgates.com,
206-623-7580.
1. Your business is developing a proprietary software program with high
hopes of profitable distribution— its value lies in its secret source code.
But one of your employees, or an independent contractor working with
your development team, included a small piece of open source code.
Or the code was included after your company merged with another
business, merging products as well, and the open source issues weren’t
flagged in the due diligence process; or
2. You have based your company’s internal operations on open source
software. Your company is not in the software business, you don’t plan
to distribute software and, therefore, you don’t care that your open
source license requires you to share with others any adaptations and
improvements you make to the source code. You just like the program.
Then you get a notice of infringement—the letter says you must stop
using the open source software because your use violates the rights
of one of perhaps several hundred developers who contributed to the
program. You have to defend the suit and stop using.
In each case, the terms of your open source license affect your fate. If you don’t
know why, this article is intended to provide some basic information.
What is open source software and where did it come from? Open source
software is generally traced to Richard Stallman, who began the Free
Software Foundation in 1984, and Linus Torvalds, who developed the first
version of the Linux operating system in 1991. Torvalds released his original
Linux program code over the Internet so that other programmers could
modify and enhance it. He released it under an open source license so that
enhancements and improvements would also be made publicly available.
The base concept is an ever-building common code that, via licenses, is
donated to and kept in the public domain:
Practitioner’s Perspective appears periodically
in the monthly Report Letter of the CCH Guide to
Computer Law. Various practitioners provideindepth analyses of significant issues and trends.
[Open source restrictions help] programmers who want to contribute
improvements to free software get permission to do that. These
programmers often work for companies or universities that would
do almost anything to get more money. A programmer may want
to contribute her changes to the community, but her employer
may want to turn the changes into a proprietary software product.
When we explain to the employer that it is illegal to distribute the
improved version except as free software, the employer usually
CCH GUIDE TO COMPUTER LAW
decides to release it as free software rather than throw it
away. (See http://www.gnu.org/licenses/licenses.html#Intro,
“What is CopyLeft?”)
Open source software is often called “free” software—is it
really? In this context, “free” doesn’t necessarily mean “no
charge.” It does mean that the source code must be “open”
for review. Many companies offering “open source” software
do so for profit either by charging for the copy or charging
for related services:
The intention was that nobody would have to pay for
“permission” to use the GNU system.… I have learned
to distinguish carefully between “free” in the sense of
freedom and “free” in the sense of price. Free software
is software that users have the freedom to distribute
and change. Some users may obtain copies at no charge,
while others pay to obtain copies—and if the funds help
support improving the software, so much the better.
The important thing is that everyone who has a copy
has the freedom to cooperate with others in using it.
(See http://www.gnu.org/manifesto.htm#f1)
The GNU web site says, “think ‘free speech’, not ‘free beer.’”
Why would a business care if the software it licenses is open
source or not? As with all software, the license is the key.
Software is protected by a variety of intellectual property
laws, including copyright, which limits a user’s ability to
copy, modify or distribute the software except as permitted
by the copyright owner. The terms of that permission are
set forth in the license. Many open source licenses require
users, who combine open source code with the user’s
otherwise proprietary product, to make the source code for
the whole product entirely open. That is why some speak
of open source software as “infecting” other code. If your
business plan depends upon keeping your code confidential,
an “infection” is, obviously, a problem. Are all open source
licenses the same? No. They are increasingly as variable as
other software licenses and, correspondingly, must be read
carefully to understand the rights granted and restrictions
imposed (see e.g., http://opensource.org/licenses). Whether open
source software is “better” or “worse” than other software
depends on many factors, both technical and legal, and the
user’s ultimate goals. The point here is that “open source”
software licenses are not all the same, and it’s important
to understand those license terms to avoid potentially
unpleasant surprises.
How can open source software affect your business if you only
use it internally to run your business? Infringement. If you are
modifying or copying the open source software, you may
be exposed to a copyright infringement action by a rightsholder in the development chain who claims, for example,
that someone else in the chain used code in violation of that
developer’s license or didn’t obtain or qualify for a license at
all. You can also be exposed to patent infringement claims,
NUMBER 273
since the scope of patent rights obtained under a given open
source license can be more limited than a user might expect.
Claims of infringement can happen with any software. The
difference with open source is that informal permission
structures can enhance the risk of infringement claims. This
kind of litigation has begun and will likely increase. The SCO
Group, for example, is claiming that the Linux operating
system infringes SCO’s proprietary rights. Defendant
distributors of Linux disagree. SCO has also sued some
large customers who are simply using the software. In some
cases, voluntary funds have been established by companies
promoting open source software to help defray the costs of
defense, but the outcome in terms of expense and the ability
to continue to use the software, is still unknown.
Are open source licenses enforceable? An enforceable license is
a defense to an infringement action and open source licenses
should be just as enforceable as any other contract. The
problem is that contract law requirements are not consistently
met by open source licensors and licensees. If everyone, in
fact, behaved as contemplated by the licenses, e.g., if every
licensee developer ensured that the next transferee agreed
to be bound by the relevant license, then there would be no
problem. But that does not consistently happen. Frequently,
the licensee does not know about the license or does not
intentionally engage in conduct sufficient to pass muster as
legal assent.
There are many ways to consent to a contract in modern
commerce and there’s nothing about open source that alters
those choices—the problem is that frequently, none are
used. That can create a chain with problems in several links
or everywhere below the weak link. Contracts can also be
formed by trade usage—so there may be questions whether
you were aware of that usage, what it was, and whether you
are bound by a contract you did not realize you had made.
Even if a contract is correctly formed, particular terms might
not be enforceable. For example, in several states with a nonuniform version of the UCC, implied warranties may not
be disclaimed, yet most of the open source licenses require
disclaimer (this assumes the UCC would even apply—
although it should not apply, that is part of a debate in
licensing law).
To complicate this, some open source “licensors” adopt the
legal position that their “licenses” are not contracts at all.
Thus, contract law can be ignored. Under this view, open
source terms are merely a notice given by the copyright
owner of what can or cannot be done—a user who ignores
the notice will not breach a contract, but will be subject to an
infringement action.
Why not just get permission from someone in authority?
That’s easier said than done. Take a children’s story: many
people have intellectual property rights in it, including the
illustrator, the author, and the publisher. Now make the
story a software product and add music, sound effects, code
CCH GUIDE TO COMPUTER LAW
allowing different endings, film clips and much more. All
of those creators have intellectual property rights too. In a
proprietary product, the publisher would typically obtain
appropriate rights from the owners or authorized licensors of
each of those components. Open source software is similarly
comprised of contributions from many different sources, but
they may come under myriad licenses or notices that may
or may not, in fact, be effective. The legal result is less clear
NUMBER 273
and less tested, although this will change over time as the
proprietary rights in open source software are challenged in
the courts.
The point here is that a free lunch usually comes at some
price and so does “free” or open source software. Users who
are not aware of that price or its impact should learn more
before imbibing, knowingly or unknowingly.
Download