Compare commits
50 commits
1905e9f3aa
...
a2d90d4b73
Author | SHA1 | Date | |
---|---|---|---|
|
a2d90d4b73 | ||
|
d7ff8bd6ff | ||
|
d2b7845460 | ||
|
fcfe1bea4d | ||
|
462a1dad97 | ||
|
0c41351153 | ||
|
06e02e66fa | ||
|
8be5affab9 | ||
|
a9a0513787 | ||
|
871a6447e6 | ||
|
76b1557c0d | ||
|
0dd9826afd | ||
|
5ade052eff | ||
|
1e393d014e | ||
|
7c2266b966 | ||
|
01d2164017 | ||
|
bdae945705 | ||
|
f07e7d4716 | ||
|
b7ae80de48 | ||
|
ad0696d186 | ||
|
4a26646df6 | ||
|
d3e5b80535 | ||
|
1b3e3f8791 | ||
|
9e66a996bd | ||
|
a504d9f041 | ||
|
e8963927dc | ||
|
3bf3440511 | ||
|
64fdf604a1 | ||
|
88f3821430 | ||
|
c53c74a02b | ||
|
0f15eade4a | ||
|
489d24a49f | ||
|
4d3566829d | ||
|
922f7f4b87 | ||
|
0e6bd590b6 | ||
|
f41608f4f2 | ||
|
3329223add | ||
|
c3c5265c96 | ||
|
490107d60b | ||
|
594a4f744d | ||
|
a002bf4681 | ||
|
b5c77f2ede | ||
|
4dc867878b | ||
|
81ab95b091 | ||
|
e55bdd6f0c | ||
|
a55777a6ed | ||
|
72ee4d2823 | ||
|
8495d9b65e | ||
|
a53d1919b0 | ||
|
9122138cf0 |
6 changed files with 523 additions and 6 deletions
|
@ -100,8 +100,9 @@ and Guide
|
|||
|
||||
{\parindent 0in
|
||||
\begin{tabbing}
|
||||
Copyright \= \copyright{} 2003--2005, 2008, 2014--2015 \hspace{1.mm} \= \kill
|
||||
Copyright \> \copyright{} 2003--2005, 2008, 2014--2015 \> Bradley M. Kuhn. \\
|
||||
Copyright \= \copyright{} 2003--2005, 2008, 2014--2015, 2018 \hspace{1.mm} \= \kill
|
||||
Copyright \> \copyright{} 2018 \> Chestek Legal. \\
|
||||
Copyright \> \copyright{} 2003--2005, 2008, 2014--2015, 2018 \> Bradley M. Kuhn. \\
|
||||
Copyright \> \copyright{} 2014--2015 \> Anthony K. Sebro, Jr. \\
|
||||
Copyright \= \copyright{} 2014 \> Denver Gingerich. \\
|
||||
Copyright \= \copyright{} 2003--2007, 2014 \> Free Software Foundation, Inc. \\
|
||||
|
|
220
gpl-installation.tex
Normal file
220
gpl-installation.tex
Normal file
|
@ -0,0 +1,220 @@
|
|||
% 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}
|
119
gpl-lgpl.tex
119
gpl-lgpl.tex
|
@ -2160,7 +2160,8 @@ GPLv2~\S4 is GPLv2's termination clause. Upon first examination, it seems
|
|||
strange that a license with the goal of defending users' and programmers'
|
||||
freedoms for perpetuity in an irrevocable way would have such a clause.
|
||||
However, upon further examination, the difference between irrevocability
|
||||
and this termination clause becomes clear.
|
||||
and this termination clause becomes clear. (See~\ref{gplv2-irrevocable} for
|
||||
expanded discussion of GPLv2 irrevocability.)
|
||||
|
||||
The GPL is irrevocable in the sense that once a copyright holder grants
|
||||
rights for someone to copy, modify and redistribute the software under terms
|
||||
|
@ -2320,6 +2321,120 @@ rights\footnote{While nearly all attorneys and copyleft theorists are in
|
|||
Jaeger and almost everyone else in the copyleft community for nearly a
|
||||
decade, regard an almost moot and wholly esoteric legal detail.}.
|
||||
|
||||
\section{GPLv2 Irrevocability}
|
||||
\label{gplv2-irrevocable}
|
||||
|
||||
This section digresses briefly to examine the manner in which GPLv2\S\S~4--6
|
||||
interact together to assure that the license grant is irrevocable.
|
||||
There are two legal theories why a contributor cannot terminate their license
|
||||
grant. First is an argument that the text of the GPL prevents it; second is
|
||||
that a contributor would be estopped from succeeding on an infringement claim
|
||||
for continued use of the code even if it wasn't removed.
|
||||
|
||||
\subsection{The text of the GPLv2}
|
||||
|
||||
The GPLv2 have several provisions that, when taken together, can be construed
|
||||
as an irrevocable license from each contributor. First, the GPLv2 says ``by
|
||||
\emph{modifying} or distributing the Program (or any work based on the Program), you
|
||||
indicate your acceptance of this License to do so, and all its terms and
|
||||
conditions for copying, distributing or modifying the Program or works based
|
||||
on it'' (GPLv2\S5, emphasis added). A contributor by definition is modifying
|
||||
the code and therefore has agreed to all the terms in the GPLv2, which
|
||||
includes the web of mechanisms in the GPLv2 that ensure the code can be used
|
||||
by all.
|
||||
|
||||
More specifically, the downstream license grant says ``the recipient
|
||||
automatically receives a license from the original licensor to copy,
|
||||
distribute or modify the Program subject to these terms and conditions.''
|
||||
(GPLv2\S6). So in this step, the contributor has granted a license to the
|
||||
downstream, on the condition that the downstream complies with the license
|
||||
terms.
|
||||
|
||||
That license granted to downstream is irrevocable, again provided that the
|
||||
downstream user complies with the license terms: ``[P]arties who have
|
||||
received copies, or rights, from you under this License will not have their
|
||||
licenses terminated so long as such parties remain in full compliance''
|
||||
(GPLv2\S4).
|
||||
|
||||
Thus, anyone downstream of the contributor (which is anyone using the
|
||||
contributor's code), has an irrevocable license from the contributor. A
|
||||
contributor may claim to revoke their grant, and subsequently sue for
|
||||
copyright infringement, but a court would likely find the revocation was
|
||||
ineffective and the downstream user had a valid license defense to a claim of
|
||||
infringement.
|
||||
|
||||
Nevertheless, for purposes of argument, we will assume that for some
|
||||
reason the GPLv2 is not enforceable against the contributor\footnote{For
|
||||
example, the argument has been made that there may be a failure of
|
||||
consideration on the part of the contributor. While \textit{Jacobsen
|
||||
v. Katzer}, 535 F.3d 1373 (Fed. Cir. 2008) is accepted as holding that
|
||||
there is consideration received by the contributor in a FOSS license, the
|
||||
posture of the case was one where the contributor advocated for the theory,
|
||||
not against it. The author is not aware of any other decisions that have analyzed
|
||||
the question in any depth, so it perhaps could be challenged in the right
|
||||
factual situation.}, or that the irrevocable license can be
|
||||
revoked\footnote{A contract without a definable duration can be terminated on
|
||||
reasonable notice. \textit{Great W. Distillery Prod. v. John A. Wathen Distillery
|
||||
Co.}, 10 Cal. 2d 442, 447, 74 P.2d 745, 747 (1937). The term nevertheless
|
||||
can be a term of indefinite length where its continuing effect is tied to
|
||||
the conduct of the parties. \emph{Id}.}. In that case, the application of
|
||||
promissory estoppel will likely mean that the contributor still cannot
|
||||
enforce their copyright against downstream users.
|
||||
|
||||
\subsection{Promissory estoppel}
|
||||
|
||||
``Promissory estoppel'' is a legal theory that says, under some
|
||||
circumstances, a promise is enforceable against the promisee even after the
|
||||
promisee tries to renege on the promise. The test for how and when promissory
|
||||
estoppel applies differs from state to state, but generally where there is a
|
||||
``promise which the promisor should reasonably expect to induce action or
|
||||
forbearance on the part of the promisee or a third person and which does
|
||||
induce such action or forbearance is binding if injustice can be avoided only
|
||||
by enforcement of the promise.''\footnote{\textit{Kajima/Ray Wilson v. Los Angeles
|
||||
Cty. Metro. Transp. Auth.}, 23 Cal. 4th 305, 310, 1 P.3d 63, 66 (2000), \emph{citing}
|
||||
Restatement (Second) of Contracts \S 90(1) (1979).} Breaking it down, it is:
|
||||
\begin{enumerate}
|
||||
\item where there is a clear and definite promise;
|
||||
\item where the promisor has a reasonable expectation that the offer will
|
||||
induce action or forbearance on the part of the promisee;
|
||||
|
||||
\item which does induce actual and reasonable action or forbearance by the promisee; and
|
||||
|
||||
\item which causes a detriment which can only be avoided by the enforcement
|
||||
of the promise.
|
||||
\end{enumerate}
|
||||
|
||||
In this case, the promisor is the contributor. This should be an easy
|
||||
standard to meet in any widely used software.
|
||||
\begin{enumerate}
|
||||
\item The promise is contained in the GPL, which is a promise that one can
|
||||
continue to use the licensed software as long as the terms of the license
|
||||
are met.
|
||||
|
||||
|
||||
\item A contributor knows that there is a broad user base and users consume
|
||||
the software relying on the grant in the GPL as assuring their continued
|
||||
ability to use the software (one might even say it is the \textit{sine qua
|
||||
non} of the intent of the GPL).
|
||||
|
||||
\item Users do, in fact, rely on the promises in the GPL, as they ingest the software
|
||||
and base their businesses on their continued ability to use the software.
|
||||
|
||||
\item Whether the user will suffer detriment is case-specific, but using
|
||||
Linux, a software program that is often fundamental to the operation of a
|
||||
business, as an example, the loss of its use would have a significantly
|
||||
detrimental, perhaps even fatal, effect on the continued operation of the
|
||||
business.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Conclusion}
|
||||
|
||||
Whether as a matter of a straightforward contractual obligation, or as a
|
||||
matter of promissory estoppel, a contributor's attempt to revoke a copyright
|
||||
license grant and then enforce their copyright against a user is highly
|
||||
unlikely to succeed.
|
||||
|
||||
\section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''}
|
||||
\label{GPLv2s7}
|
||||
|
||||
|
@ -4885,7 +5000,7 @@ found that for higher-end hardware, the profit made from proprietary
|
|||
software licensing fees is negligible. The real profit is in the hardware,
|
||||
but it is essential that software be stable, reliable and dependable, and
|
||||
the users be allowed to have unfettered access to it. Free Software, and
|
||||
GPL’d software in particular, is the right choice. For instance IBM can be
|
||||
GPL'd software in particular, is the right choice. For instance IBM can be
|
||||
assured that proprietary versions of the their software will not exist to
|
||||
compete on their hardware.
|
||||
|
||||
|
|
|
@ -2,6 +2,77 @@
|
|||
% Bradley M. Kuhn & Karen M. Sandler
|
||||
% Tuesday 9 May 2017
|
||||
|
||||
# CCS
|
||||
|
||||
Complete, Corresponding Source
|
||||
|
||||
# How GPLv3 says CCS.
|
||||
|
||||
<hr/>
|
||||
|
||||
> The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
|
||||
<span class="fitonslide">
|
||||
<p align=right>
|
||||
— GPLv3§1
|
||||
</p>
|
||||
</span>
|
||||
|
||||
# How GPLv2 says CCS.
|
||||
|
||||
<hr/>
|
||||
|
||||
> You may copy and distribute the Program (or a work based on it, under
|
||||
> § 2) in object code or executable form under the terms of § 1
|
||||
> & 2 above provided that you … [a]ccompany it with the complete
|
||||
> corresponding machine-readable source code … The source code for a
|
||||
> work means the preferred form of the work for making modifications to it.
|
||||
> For an executable work, complete source code means all the source code for
|
||||
> all modules it contains, plus any associated interface definition files,
|
||||
> plus the scripts used to control compilation and installation of the
|
||||
> executable.
|
||||
|
||||
<p align=right>
|
||||
— GPLv2§3
|
||||
</p>
|
||||
</span>
|
||||
|
||||
# The 11 Words That Consumed My Life
|
||||
|
||||
+ GPLv2 enforcement, for embedded products, is all about the these eleven
|
||||
words.
|
||||
|
||||
+ I could give an entire talk on any one of these 11 words.
|
||||
+ Yes, I can even give 20-30 minute treatises on each use of “the”.
|
||||
|
||||
+ Yet, when enforcement processes are at their best, they're about the spirit
|
||||
behind these words, not the words themselves.
|
||||
|
||||
<hr>
|
||||
> the scripts used to control compilation and installation of the executable.
|
||||
|
||||
<p align=right>
|
||||
— GPLv2§3
|
||||
</p>
|
||||
</span>
|
||||
|
||||
# The 11 Words That Consumed My Life
|
||||
|
||||
+ Basic reference rule:
|
||||
+ Can a developer reasonably skilled in the art of embedded software
|
||||
build your sources, take the (copylefted) executables and install
|
||||
them?
|
||||
|
||||
+ Enforcement spends its most attention on testing CSS
|
||||
“candidates” to verify that.
|
||||
|
||||
<hr>
|
||||
> the scripts used to control compilation and installation of the executable.
|
||||
|
||||
<p align=right>
|
||||
— GPLv2§3
|
||||
</p>
|
||||
</span>
|
||||
|
||||
# CCS "Round" Reports
|
||||
|
||||
+ Evaluate each CCS candidate.
|
||||
|
@ -309,6 +380,116 @@
|
|||
to email NAME@COMPANY.com , which is how the above instructions for
|
||||
downloading the source were received.
|
||||
|
||||
# A Pristine Example
|
||||
|
||||
+ Enforcement must often use a “know it when I see it” standard.
|
||||
+ i.e., can we take your CCS build it, and install it?
|
||||
|
||||
+ We've reached compliant CCS with hundreds of companies:
|
||||
+ but that didn't mean the CCS was pretty.
|
||||
|
||||
+ Thanks to ThinkPenguin, we finally have an example of beautiful embedded
|
||||
product compliance.
|
||||
|
||||
# Lessons Learned from Pristine Example
|
||||
|
||||
+ The full paper for this talk is available online:
|
||||
+ [compliance.guide/pristine-example](http://compliance.guide/pristine-example)
|
||||
|
||||
|
||||
+ It's part of the larger tutorial called [*Copyleft and the GNU General
|
||||
Public License: A Comprehensive Tutorial and Guide*](https://copyleft.org/guide/)
|
||||
at copyleft.org.
|
||||
|
||||
# Give a roadmap in a README
|
||||
|
||||
+ Scripts doesn't only mean shell scripts and Makefiles.
|
||||
|
||||
+ Think of the script of a play or movie.
|
||||
|
||||
+ If your build process includes human intervention …
|
||||
|
||||
+ … then the script are a written explanation of what the human must
|
||||
do.
|
||||
|
||||
<hr>
|
||||
> **the scripts** used to control compilation and installation of the executable.
|
||||
|
||||
<p align=right>
|
||||
— GPLv2§3
|
||||
</p>
|
||||
</span>
|
||||
|
||||
# ThinkPengiun's README
|
||||
|
||||
A file called “README” at the top-level directory said:
|
||||
|
||||
In order to build firmware images for your router, the following needs to be installed:
|
||||
|
||||
gcc, binutils, bzip2, flex, python, perl, make, find, grep, diff, unzip,
|
||||
gawk, getopt, libz-dev and libc headers.
|
||||
|
||||
Please use “make menuconfig” to configure your appreciated configuration
|
||||
for the toolchain and firmware. Please note that the default configuration
|
||||
is what was used to build the firmware image for your router. It is advised
|
||||
that you use this configuration.
|
||||
|
||||
Simply running “make” will build your firmware. The build system will
|
||||
download all sources, build the cross-compile toolchain, the kernel and all
|
||||
chosen applications.
|
||||
|
||||
To build your own firmware you need to have access to a GNU/Linux system
|
||||
(case-sensitive filesystem required).
|
||||
|
||||
# Make Sure It Builds
|
||||
|
||||
+ Can your CCS pass this test?
|
||||
+ Give you source release to another developer from another department.
|
||||
+ Ask them to follow the instructions you wrote.
|
||||
+ They should get the equivalent binaries you get in building.
|
||||
|
||||
+ Very few organizations bother to do this.
|
||||
|
||||
+ It's probably the most useful step to verify compliance, yet *no*
|
||||
compliance process recommendations I've ever seen include this.
|
||||
|
||||
<hr>
|
||||
> the scripts used to **control compilation** and installation of the executable.
|
||||
|
||||
<p align=right>
|
||||
— GPLv2§3
|
||||
</p>
|
||||
</span>
|
||||
|
||||
|
||||
# It's not “make install”
|
||||
|
||||
+ Server system software can offer a “make install” that
|
||||
reasonable works to meet installation requirements.
|
||||
|
||||
+ Embedded products are admittedly difficult to install.
|
||||
|
||||
+ To comply here, you'll usually just have write out the instructions.
|
||||
|
||||
+ It is required; don't skip this part.
|
||||
|
||||
<hr>
|
||||
> the scripts used to **control** compilation and **installation** of the executable.
|
||||
<p align=right>
|
||||
— GPLv2§3
|
||||
</p>
|
||||
</span>
|
||||
|
||||
# Missing hardware components
|
||||
|
||||
+ Inclusion of specialized installation hardware is not a
|
||||
“script”.
|
||||
|
||||
+ In our ThinkPenguin example, we had to go buy a USB serial adapter to
|
||||
install the modified firmware.
|
||||
|
||||
+ Just tell the user what they have to go buy for the install to work.
|
||||
|
||||
# More Info / Talk License
|
||||
|
||||
<img align="right" src="cc-by-sa-4-0_88x31.png" />
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
# an environment variable before you type make.
|
||||
|
||||
ifndef PRESENTATION_BASE
|
||||
PRESENTATION_BASE=ccs-examples
|
||||
PRESENTATION_BASE=non-copyright
|
||||
endif
|
||||
|
||||
DO_INCREMENTAL_POINTS = -i -s
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
#!/bin/sh
|
||||
|
||||
talk=half-day-gpl/ccs-examples
|
||||
talk=half-day-gpl/non-copyright
|
||||
|
||||
rsync -HavP ./ /home/pres/$talk/
|
||||
rm -rf /home/pres/$talk/ui
|
||||
|
|
Loading…
Reference in a new issue