Compare commits

...

50 commits

Author SHA1 Message Date
Bradley M. Kuhn
a2d90d4b73 Merge branch 'next'
New section regarding GPLv2 Irrevocability is ready to go live.
2018-09-26 10:31:16 -07:00
Bradley M. Kuhn
d7ff8bd6ff Additional connecting text for irrevocability discussion.
A forward reference is added to connect to the irrevocability section, and
one transition sentence added in the irrevocability section itself, since
it's another "digression" from the walk-through of GPLv2 in these sections.
2018-09-26 09:30:21 -07:00
Pamela Chestek
d2b7845460 More detail on Irrevocability of GPLv2
This section, fit in just after the detailed discussion of GPLv2 Section 6,
explains in futher detail various arguments for why the GPLv2 is irrevocable.
2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
fcfe1bea4d Remove UTF-8 apostrophe in favor of a LaTeX one. 2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
462a1dad97 Fix build issues. 2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
0c41351153 More slides for CCS examples from a long time ago. 2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
06e02e66fa A few sentences more for the next section. 2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
8be5affab9 first draft: completed Historical Background section 2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
a9a0513787 Began work in Introduction and Historical Background
These are probably too long, but various parts of this may work as
replacements for some of the older text in the larger tutorial.
2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
871a6447e6 GPL Installation Instructions Article: abstract
This is my first draft at an abstract for this article.  I suspect that this
Abstract is too long, so I may move some it out into other text.
2018-09-26 09:30:21 -07:00
Bradley M. Kuhn
76b1557c0d Document the One Rule for merging into master. 2018-09-25 16:33:40 -07:00
Bradley M. Kuhn
0dd9826afd Correct reference to wrong section. 2018-09-25 16:33:40 -07:00
Bradley M. Kuhn
5ade052eff Note new commit bits given out to three others. 2018-09-25 16:33:40 -07:00
Bradley M. Kuhn
1e393d014e Would help online contributors send small changes?
HT: Loïc Dachary <loic@dachary.org>

... who told me about this project.
2018-09-25 16:33:40 -07:00
Bradley M. Kuhn
7c2266b966 Fix build issues. 2018-09-25 16:31:54 -07:00
Bradley M. Kuhn
01d2164017 More slides for CCS examples from a long time ago. 2018-09-25 16:31:34 -07:00
Bradley M. Kuhn
bdae945705 A few sentences more for the next section. 2018-09-25 16:31:05 -07:00
Bradley M. Kuhn
f07e7d4716 first draft: completed Historical Background section 2018-07-02 07:04:26 -07:00
Bradley M. Kuhn
b7ae80de48 Began work in Introduction and Historical Background
These are probably too long, but various parts of this may work as
replacements for some of the older text in the larger tutorial.
2018-06-19 14:06:22 +09:00
Bradley M. Kuhn
ad0696d186 GPL Installation Instructions Article: abstract
This is my first draft at an abstract for this article.  I suspect that this
Abstract is too long, so I may move some it out into other text.
2018-06-19 12:04:06 +09:00
Bradley M. Kuhn
4a26646df6 Various links. 2017-05-09 11:38:55 -05:00
Bradley M. Kuhn
d3e5b80535 Presentations as prepared by Karen for OSCON 2017. 2017-05-09 11:15:22 -05:00
Bradley M. Kuhn
1b3e3f8791 Copy over build details and CC BY SA logo. 2017-05-09 09:55:04 -05:00
Bradley M. Kuhn
9e66a996bd Change name to this presentation. 2017-05-09 09:52:15 -05:00
Bradley M. Kuhn
a504d9f041 Change Karen requested verbally. 2017-05-09 09:52:05 -05:00
Bradley M. Kuhn
e8963927dc Copy over install scripts and CC BY SA logo. 2017-05-09 09:50:49 -05:00
Bradley M. Kuhn
3bf3440511 Rename presentation to this one. 2017-05-09 09:50:40 -05:00
Bradley M. Kuhn
64fdf604a1 Add Karen's name. 2017-05-09 09:49:46 -05:00
Bradley M. Kuhn
88f3821430 Change base name to the one in this presentation. 2017-05-09 09:48:48 -05:00
Bradley M. Kuhn
c53c74a02b Various changes based on Karen's verbal comments. 2017-05-09 09:48:00 -05:00
Bradley M. Kuhn
0f15eade4a Copied over Makefile and CC BY SA logo. 2017-05-09 09:45:32 -05:00
Bradley M. Kuhn
489d24a49f Working Makefile installation. 2017-05-09 09:40:33 -05:00
Bradley M. Kuhn
4d3566829d Karen corrected me on this term. 2017-05-09 09:40:24 -05:00
Bradley M. Kuhn
922f7f4b87 Add Karen's name. 2017-05-09 09:40:19 -05:00
Bradley M. Kuhn
0e6bd590b6 Set up Makefile and add CC By SA logo. 2017-05-09 09:24:11 -05:00
Bradley M. Kuhn
f41608f4f2 Add copyright notice. 2017-05-09 09:23:42 -05:00
Bradley M. Kuhn
3329223add Non-Copyright systems slide first draft. 2017-05-09 08:57:02 -05:00
Bradley M. Kuhn
c3c5265c96 Links to related Guide sections. 2017-05-09 08:22:08 -05:00
Bradley M. Kuhn
490107d60b Add introduction slide. 2017-05-09 08:12:38 -05:00
Bradley M. Kuhn
594a4f744d Remove extraneous material to just CCS examples. 2017-05-09 08:12:21 -05:00
Bradley M. Kuhn
a002bf4681 Larger presentation -> CCS report examples
cp -pa presentations/2hr-GPL-compliance-focus/2hr-GPL.md presentations/ccs-report-examples/ccs-examples.md

Plan to reduce this just to the CCS examples.
2017-05-09 07:52:35 -05:00
Bradley M. Kuhn
b5c77f2ede correct date again. 2017-05-09 07:41:30 -05:00
Bradley M. Kuhn
4dc867878b Make plural. 2017-05-09 07:39:53 -05:00
Bradley M. Kuhn
81ab95b091 CD is not the primary shipped media these days. 2017-05-09 07:39:39 -05:00
Bradley M. Kuhn
e55bdd6f0c Update date. 2017-05-09 07:39:25 -05:00
Bradley M. Kuhn
a55777a6ed Reduce slides to only those introducing violations 2017-05-09 07:27:37 -05:00
Bradley M. Kuhn
72ee4d2823 2hr compliance to select sides for violation intro
cp -pa presentations/2hr-GPL-compliance-focus/2hr-GPL.md presentations/20min-violation-intro/violation-intro.md
2017-05-09 07:15:39 -05:00
Bradley M. Kuhn
8495d9b65e Add final slide with links to pertinent sections. 2017-05-09 07:07:10 -05:00
Bradley M. Kuhn
a53d1919b0 Shorten length; include only section discussion
Shorten this down to include discussion only of specific GPL sections.
2017-05-09 07:02:13 -05:00
Bradley M. Kuhn
9122138cf0 Copy 1hr-GPL.markdown to specific-sections.md
cp 1hr-GPL/1hr-GPL.markdown 30min-specific-sections/specific-sections.md

Start from the 1hr version to make a short version that talks about just
a few specific sections of the GPL.
2017-05-09 06:51:59 -05:00
6 changed files with 523 additions and 6 deletions

View file

@ -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
View 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}

View file

@ -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
GPLd 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.

View file

@ -2,6 +2,77 @@
% Bradley M. Kuhn &amp; 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>
&mdash; GPLv3&sect;1
</p>
</span>
# How GPLv2 says CCS.
<hr/>
> You may copy and distribute the Program (or a work based on it, under
> &sect; 2) in object code or executable form under the terms of &sect; 1
> &amp; 2 above provided that you &hellip; [a]ccompany it with the complete
> corresponding machine-readable source code &hellip; 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>
&mdash; GPLv2&sect;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 &ldquo;the&rdquo;.
+ 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>
&mdash; GPLv2&sect;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
&ldquo;candidates&rdquo; to verify that.
<hr>
> the scripts used to control compilation and installation of the executable.
<p align=right>
&mdash; GPLv2&sect;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 &ldquo;know it when I see it&rdquo; 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 &hellip;
+ &hellip; 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>
&mdash; GPLv2&sect;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>
&mdash; GPLv2&sect;3
</p>
</span>
# It's not &ldquo;make install&rdquo;
+ Server system software can offer a &ldquo;make install&rdquo; 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>
&mdash; GPLv2&sect;3
</p>
</span>
# Missing hardware components
+ Inclusion of specialized installation hardware is not a
&ldquo;script&rdquo;.
+ 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" />

View file

@ -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

View file

@ -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