220 lines
11 KiB
TeX
220 lines
11 KiB
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. 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.
|
|
|
|
\section{GPLv2 Installation Requirements}
|
|
|
|
As discussed in the previous section, firms have generally been completely
|
|
comfortable
|
|
|
|
\end{document}
|