guide/gpl-installation.tex

% Copyright (C) 2018, Bradley M. Kuhn
% License: CC-BY-SA-4.0

\documentstyle[twocolumn]{article}
\pagestyle{empty}
\begin{document}

%don't want date printed
\date{}

%make title bold and 14 pt font (Latex default is non-bold, 16 pt)

\title{\Large\bf A Comprehensive Consideration of Installation Requirements of the GPL}

%for two authors (this is what is printed)

\author{\begin{tabular}[t]{c@{\extracolsep{8em}}c@{\extracolsep{8em}}c}
    Bradley M. Kuhn & Behan Webster \\
    Software Freedom Conservancy, Inc. & Converse In Code
\end{tabular}
}

\thispagestyle{empty}

\maketitle

\subsection*{\centering Abstract}

The GNU General License (``GPL'') is the most widely used \textit{copyleft}
license for software.  Copyleft licenses function as copyright license in
atypical manner: rather than restricting permission to copy, modify and
redistribute the software, copyleft licenses encourage and enable such
activities.  However, these license have strict requirements that mandate
further software sharing by enabling downstream users to easily improve,
modify, and upgrade the copylefted software on their own.

GPL has two versions in common use: version 2 (``GPLv2'') and version 3
(``GPLv3'').  Both versions require those who redistribute the software to
provide information related to the installation of software modified by
downstream.  These installation requirements, however, differ somewhat in
their details.  While some business practices around license compliance
efforts have reached adequate sophistication to address simpler compliance
problems, firms have generally given inadequate attention to the installation
requirements of both common versions of GPL\@.  Misunderstanding of these
clauses is often common, and violations related to installation instructions
remain prevalent.

Furthermore, perceived differences in the requirements, and lack of rigorous
study of the Installation Information requirements of GPLv3\S6 has allowed
rumor and impression, rather than a textually grounded adherence to the
written rules, to govern industry response in adoption of software licensed
under GPLv3.  The resulting scenario often causes redistributors to assume
the GPLv2 has \textbf{no} requirements regarding installation information,
and that GPLv3's requirements in this regard are impossible to meet,
particularly in security-conscious embedded products.

This paper explores the installation provisions of both common versions of
GPL, discusses historical motivations and context for each, and suggests best
practices regarding installation information for firms that redistribute
software under both licenses.

\section{Introduction}

Free, Libre and Open Source (``FLOSS'') licenses are typically categorized as
either copyleft or non-copyleft licenses.  The license compliance demands of
most non-copyleft licenses typically center purely around issues of author
attribution, and thus are straightforwardly addressed by license compliance
programs such as OpenChain and SPDX, which focus on the details of properly
annotating licensing information for software in the supply-chain to assure
proper downstream license and related author credit notification.

Copyleft licenses do indeed require proper downstream license and credit
notification, and thus we can broadly model copyleft license requirements as
a proper superset of those requirements of non-copyleft licenses.  The
compliance subset of license annotation is a well-studied problem, and many
automation tools exist and remain under active development to assist in these
aspects of compliance. Unfortunately, the nascent state of industry
compliance efforts currently means that firms are often ill-equipped to
handle the additional requirements of copyleft licenses.

In particular, software copyleft licenses are specifically designed to
promulgate a transparent agenda to champion the rights of downstream users to
effectively and easily copy, modify, reinstall and redistribute the software
both commercially and non-commercially.  Proper verification of source code
for license compliance generally cannot be automated.  Indeed, given that
program equivalence (often colloquially called the ``Halting Problem'') was
mathematically proven as an undecidable problem in the computing subfield of
Theory of Computation, we know that a generalized solution that shows
specific source code corresponds to a specific set of binaries remains
unsolvable in the general case.

We do expect automation tools that approximate solutions for the specific
cases of most interest to adopter of copylefted software to eventually exist.
Currently, much research and industry attention has turned toward the
software engineering problem of ``reproducible builds''.  We find this area
of endeavor directly applicable to the requirements of copyleft license
compliance, and believe that reproducible build techniques will eventually
become as common for  compliance with source code provisioning terms of
FLOSS licenses as SPDX and OpenChain are for the license notice and
attribution requirements are today.

However, even that solution, when it exists, will not fully satisfy the goals
of many firms.  Frankly, most firms do not share the idealistic goals of
software freedom activists who design copyleft licenses.  These activists
seek to defends the rights of software users by creating copyleft licenses
that mandate source code provisioning, which include the rights to modify and
install modified versions of the software.  However, in what the inventor of
copyleft, Richard M.~Stallman, called ``pragmatic idealism'', copyleft
licenses make reasonable trade-offs regarding how much disclosure is required
to downstream.  While conventional wisdom often considered copyleft licenses
to contain substantial and complicated requirements, ultimately the
requirements are substantially more permissive than most industry-standard
proprietary licenses, which often complete prohibit redistribution of the
software and disclose absolutely no source code.  Copyleft licenses typically
make a clear compromise between maximal software freedom for the downstream
recipient and permission for firms to distribute proprietary software in
aggregation with copylefted software.

By way of hypothetical counterexample, consider this possible ``copyleft''
license that one might create:

\begin{quotation}
  \begin{center}
    {\Large The Unreasonably Overly Broad Copyleft License}
  If you distribute this software in any form, you agree to publicly release
  the complete source code of all software that you and your successors in
  interest write, in any form, for perpetuity.
\end{quotation}

Besides likely being unenforceable for various reasons, firms would quickly
ban all software under this license, and ban all employees from ever using
such software at home or work.  A highly broad license of this nature, even
if succeeded in the very short term in a few instances, would fail long-term
to reach the long term goal of maximizing software freedom for users.
Copyleft, therefore, must find a balance between two competing goals:

\begin{itemize}

\item Ensure the rights to copy, share, modify, redistribute,
  and reinstall the software for downstream users.

\item Entice firms that do not seek the same goals as the activists to adopt,
  share and improve the copylefted software to assure its promulgation.
\end{itemize}

In essence, much FLOSS licensing balances these competing goals.
Non-copyleft licenses favor the latter much more than the former, and
copyleft licenses seek to create an optimal policy between the ``maximal
software freedom'' vs. ``adoption and popularity'' dichotomy, to assure that
in the long term, users have these specific rights, but also allow for short
term interest of firms and individuals alike who may not share the software
freedom activist perspective.

\section{Historical Background}

Despite the awareness of copyleft activists, the adoption of copyleft
licenses has been wrought with acrimony and accusation.  To our knowledge,
there are no specific empirical studies of attitudes and reasoning why firms
initially rejected copyleft (and that some still do).  However, consideration
of anecdotes can illuminate study of the reasons why confusion exists
regarding copyleft licensing requirements in general, and in particular
(which will be the focus of this article) the installation requirements of
the GNU General Public License (``GPL'').

The Free Software Foundation (``FSF''), which is the license steward for all
existing versions of the GPL, was the first to license software under GPL\@.
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.

\end{document}