diff --git a/gpl-installation.tex b/gpl-installation.tex index 6036fad817303182aa6b32bdc4b8697cfbeeb524..b4c958f0c145e1d536132c57ffe4a1534a68d5da 100644 --- a/gpl-installation.tex +++ b/gpl-installation.tex @@ -1,3 +1,6 @@ +% Copyright (C) 2018, Bradley M. Kuhn +% License: CC-BY-SA-4.0 + \documentstyle[twocolumn]{article} \pagestyle{empty} \begin{document} @@ -56,4 +59,148 @@ 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}