Released in 1991, GPLv2 came into wide use by other software authors,

including those of Linux.  During the 1990s, the alternative body of software

released under GPLv2 gained slow but steady adoption, until major firms could

no longer ignore it.

In 2001, Microsoft launched a series of political attacks against the GPL\@.

Over a period of months, various Microsoft executives called the GPL

``unAmerican'' and a ``cancer'' on the software industry.  This was the first

time most in the industry had ever heard of the GPL, and the rhetoric created

the expected fervor.

The industry context of the time was the growing adoption of GPL'd software,

and Linux, in particular, by firms.  While Microsoft was not the first to

draw negative attention to GPL's copyleft provisions, but sadly the

misunderstandings launched in these attacks remain with us today.

Adoption of FLOSS grew quickly in the last two decades.  License compliance

and FLOSS supply-chain adoption techniques have become essential components

of most large firms along with this adoption.  However, these tools and

procedures have focused on the straightforward problems of license notice,

attribution, and supply-chain FLOSS inclusion discovery techniques.  The

finer points of copyleft license compliance, particularly source code

provisioning and installation requirements of GPL, remain often

misunderstood, and sometimes outright ignored.

Historically, firms have often reacted to the two popular versions of the GPL

in the same pattern.  During the feverish anti-copyleft rhetoric of the

1990s, firms widely considered the GPLv2 as a toxic license they could not

abide.  Eventually, executives and lawyers at major firms learned what their

engineers often already knew: that GPLv2 was not unreasonable, its

requirements were well understood and could be respected by businesses that

produced both FLOSS and proprietary products.

We now see the same process happening, albeit much more slowly, with GPLv3.

We hear rhetoric drawing attention to perceived differences between GPLv2's

and GPLv3's requirements, which seem untenable to firms, some of whom

maintain GPLv2'd forks of projects that have moved on to the

``GPLv3-or-later'' upstream.  It is our view that if firms give some

attention to the history of ``slow but sure'' adoption of copyleft licenses,

after careful study of the compliance requirements, that GPLv3 requirements

can become as acceptable as the GPLv2 requirements already are.  This paper

provides analysis, guidance and explanation of a set of specific terms in

GPLv3 that some firms have declared untenable: GPLv3's updated Installation

Information requirements.  It is our hope that this detailed analysis will

replace rumor and supposition about GPLv3 requirements with cool-headed

consideration of the trade-offs between avoiding GPLv3 and meeting those

requirements --- just as firms did in the late 1990s with GPLv2.

\end{document}