Hardware Reference
In-Depth Information
ten one-of-a-kind, were typically created by the legal representatives of both parties for each
piece of software. When there were only a few companies using computers, this was cum-
bersome but manageable. However, as software products have become more ubiquitous and
the cost of these contracts went from absurd to prohibitive, developers adopted the
End User
License Agreement
(
EULA
) as the primary form of licensing. You are probably only vaguely
aware of EULAs. These are the documents, and increasingly screens or hyperlinks, you agree
to look at in order to use commercial software. These documents are generally written in dense
legal speak, often making use of font-based tactics to make them difficult to read or under-
stand. For example, they often use small font or all caps. When combined, this is a particu-
larly effective method to slow readers down to increase the probability that they will give up
and simply ignore what you write. Not surprisingly, the vast majority of commercial software
users simply ignore EULAs and remorselessly lie when they click the button indicating they
have “read and agree” to it. EULAs treat the software as a copyrighted product to which the
user only has certain rights even if they have just purchased the software. Software companies
use EULAs because unlike custom licenses, EULAs can be applied to every piece of software
without much modification, allowing for the high-volume distribution of software. The most
common EULA is the so-called “shrink-wrap agreement”, in which the user of the software
into unread agreements [
7
], this licensing in the world of proprietary software is ubiquitous.
to proprietary software, early open-source software did not include any licenses because there
was no need to enforce copyright restrictions. Released into the public domain, software was
free to be redistributed, used and modified as users wished. Ideally, this system could have
stayed in place and everyone simply could have concentrated on the technical aspects of mak-
ing superior code. Unfortunately, this anarchic system was born in a culture of greed [
8
],
which enabled some users to repackage modified open-source software as proprietary soft-
ware. Thus, software that had once been in the commons was locked back down and became
private property. You can imagine how the people that wrote the original code felt. At the
same time, the lack of open-source contracts encouraged companies like IBM, who worked on
commons software projects such as UNIX, to assert intellectual monopoly “rights” on com-
mons software [
9
]. To prevent this movement of software from the commons, simply to en-
rich rent seekers, a new type of licensing was necessary. Luckily, Richard Stallman, an MIT
programmer and powerful supporter of the open-source movement, called for developers to
and modifiable by everyone. The GPL contains two critical vital components of the license:
irst, it ensures that programs released under the GPL cannot become proprietary, and in ad-
dition, the GPL prevents the commercialization of software by requiring that derivative works
be subject to the same license conditions as the original program, and that open and closed
in the 1980s, alternatives to the GPL were created in the 1990s to overcome some of its restric-
tions that some companies viewed as a problem, like the mixing of open and closed code [
9
].
The GPL remains the standard for true freedom and open-source development. Today, there
is a wide variety of open-source software licenses that fall into three major categories: unres-
trictive, restrictive, and highly restrictive [
10
]
. Highly restrictive licenses (the good kind of re-
striction), like the GPL, do not allow for any mixing of open and closed code or any transfer
of open code to closed code. Unrestrictive licenses (e.g. Berkeley Software Distribution (BSD))
Search WWH ::
Custom Search