%      Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course

% License: CC-By-SA-4.0

% The copyright holders hereby grant the freedom to copy, modify, convey,

% Adapt, and/or redistribute this work under the terms of the Creative

% Commons Attribution Share Alike 4.0 International License.

% This text is distributed in the hope that it will be useful, but

% WITHOUT ANY WARRANTY; without even the implied warranty of

% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% You should have received a copy of the license with this document in

% a file called 'CC-By-SA-4.0.txt'.  If not, please visit

% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive

% the license text.

\part{Case Studies in GPL Enforcement}

{\parindent 0in

This part is: \\

\begin{tabbing}

Copyright \= \copyright{} 2003, 2004, 2014 \= \hspace{1.mm} \=  \kill

Copyright \> \copyright{} 2014 \>  Bradley M. Kuhn. \\

Copyright \= \copyright{} 2014 \> \hspace{.2in} Denver Gingerich \\

Copyright \= \copyright{} 2003, 2004, 2014 \= \hspace{.2in} Free Software Foundation, Inc. \\

\end{tabbing}

\vspace{1in}

\begin{center}

Authors of this part are: \\

Bradley M. Kuhn \\

John Sullivan

\vspace{3in}

Copy editors of this part include: \\

Martin Michlmayr

\vspace{3in}

The copyright holders hereby grant the freedom to copy, modify, convey,

Adapt, and/or redistribute this work under the terms of the Creative Commons

Attribution Share Alike 4.0 International License.  A copy of that license is

available at \url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.

\end{center}

}

% =====================================================================

% START OF SECOND DAY SEMINAR SECTION

% =====================================================================

\chapter*{Preface}

This one-day course presents the details of five different GPL

compliance cases handled by FSF's GPL Compliance Laboratory. Each case

offers unique insights into problems that can arise when the terms of

the GPL are not properly followed, and how diplomatic negotiation between

the violator and the copyright holder can yield positive results for

both parties.

Attendees should have successfully completely the course, a ``Detailed

Study and Analysis of the GPL and LGPL,'' as the material from that

course forms the building blocks for this material.

This course is of most interest to lawyers who have clients or

employers that deal with Free Software on a regular basis. However,

technical managers and executives whose businesses use or distribute

Free Software will also find the course very helpful.

\bigskip

These course materials are merely a summary of the highlights of the

course presented. Please be aware that during the actual GPL course, class

discussion supplements this printed curriculum. Simply reading it is

not equivalent to attending the course.

%FIXME-LATER: write these

%\chapter{Not All GPL Enforcement is Created Equal}

%\section{For-Profit Enforcement}

%\section{Community and Non-Profit Enforcement}

\chapter{Overview of Community Enforcement}

The GPL is a Free Software license with legal teeth. Unlike licenses like

the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is

designed to defend as well as grant freedom. We saw in the last course

that the GPL uses copyright law as a mechanism to grant all the key freedoms

essential in Free Software, but also to ensure that those freedoms

propagate throughout the distribution chain of the software.

\section{Termination Begins Enforcement}

As we have learned, the assurance that Free Software under the GPL remains

Free Software is accomplished through various terms of the GPL: \S 3 ensures

that binaries are always accompanied with source; \S 2 ensures that the

sources are adequate, complete and usable; \S 6 and \S 7 ensure that the

license of the software is always the GPL for everyone, and that no other

legal agreements or licenses trump the GPL. It is \S 4, however, that ensures

that the GPL can be enforced.

Thus, \S 4 is where we begin our discussion of GPL enforcement. This

clause is where the legal teeth of the license are rooted. As a copyright

license, the GPL governs only the activities governed by copyright law ---

copying, modifying and redistributing computer software. Unlike most

copyright licenses, the GPL gives wide grants of permission for engaging with

these activities. Such permissions continue, and all parties may exercise

them until such time as one party violates the terms of the GPL\@. At the

moment of such a violation (i.e., the engaging of copying, modifying or

redistributing in ways not permitted by the GPL) \S 4 is invoked. While other

parties may continue to operate under the GPL, the violating party loses their

rights.

Specifically, \S 4 terminates the violators' rights to continue

engaging in the permissions that are otherwise granted by the GPL\@.

Effectively, their rights revert to the copyright defaults ---

no permission is granted to copy, modify, nor redistribute the work.

Meanwhile, \S 5 points out that if the violator has no rights under

the GPL, they are prohibited by copyright law from engaging in the

activities of copying, modifying and distributing. They have lost

these rights because they have violated the GPL, and no other license

gives them permission to engage in these activities governed by copyright law.

\section{Ongoing Violations}

In conjunction with \S 4's termination of violators' rights, there is

one final industry fact added to the mix: rarely does one engage in a

single, solitary act of copying, distributing or modifying software.

Almost always, a violator will have legitimately acquired a copy of a

GPL'd program, either making modifications or not, and then begun

distributing that work. For example, the violator may have put the

software in boxes and sold them at stores. Or perhaps the software

was put up for download on the Internet. Regardless of the delivery

mechanism, violators almost always are engaged in {\em ongoing\/}

violation of the GPL\@.

In fact, when we discover a GPL violation that occurred only once --- for

example, a user group who distributed copies of a GNU/Linux system without

source at one meeting --- we rarely pursue it with a high degree of

tenacity. In our minds, such a violation is an educational problem, and

unless the user group becomes a repeat offender (as it turns out, they

never do), we simply forward along a FAQ entry that best explains how user

groups can most easily comply with the GPL, and send them on their merry way.

It is only the cases of {\em ongoing\/} GPL violation that warrant our

active attention. We vehemently pursue those cases where dozens, hundreds

or thousands of customers are receiving software that is out of

compliance, and where the company continually offers for sale (or

distributes gratis as a demo) software distributions that include GPL'd

components out of compliance. Our goal is to maximize the impact of

enforcement and educate industries who are making such a mistake on a

large scale.

In addition, such ongoing violation shows that a particular company is

committed to a GPL'd product line. We are thrilled to learn that someone

is benefiting from Free Software, and we understand that sometimes they

become confused about the rules of the road. Rather than merely

giving us a postmortem to perform on a past mistake, an ongoing violation

gives us an active opportunity to educate a new contributor to the GPL'd

commons about proper procedures to contribute to the community.

Our central goal is not, in fact, to merely clear up a particular violation.

In fact, over time, we hope that our compliance lab will be out of

business. We seek to educate the businesses that engage in commerce

related to GPL'd software to obey the rules of the road and allow them to

operate freely under them. Just as a traffic officer would not revel in

reminding people which side of the road to drive on, so we do not revel in

violations. By contrast, we revel in the successes of educating an

ongoing violator about the GPL so that GPL compliance becomes a second-nature

matter, allowing that company to join the GPL ecosystem as a contributor.

\section{How are Violations Discovered?}

Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL

Compliance Lab runs at a loss (in other words, it is subsided by our

donors). Our violation reports come from volunteers, who have encountered,

in their business or personal life, a device or software product that

appears to contain GPL'd software. These reports are almost always sent

via email to $<$license-violation@fsf.org$>$.

Our first order of business, upon receiving such a report, is to seek

independent confirmation. When possible, we get a copy of the software

product. For example, if it is an offering that is downloadable from a

Web site, we download it and investigate ourselves. When it is not

possible for us to actually get a copy of the software, we ask the

reporter to go through the same process we would use in examining the

software.

By rough estimation, about 95\% of violations at this stage can be

confirmed by simple commands. Almost all violators have merely made an

error and have no nefarious intentions. They have made no attempt to

remove our copyright notices from the software. Thus, given the

third-party binary, {\tt tpb}, usually, a simple command (on a GNU/Linux

system) such as the following will find a Free Software copyright notice

and GPL reference:

\begin{quotation}

{\tt strings tpb | grep Copyright}

\end{quotation}

In other words, it is usually more than trivial to confirm that GPL'd

software is included.

Once we have confirmed that a violation has indeed occurred, we must then

determine whose copyright has been violated. Contrary to popular belief,

FSF does not have the power to enforce the GPL in all cases. Since the GPL

operates under copyright law, the powers of enforcement --- to seek

redress once \S 4 has been invoked --- lie with the copyright holder of

the software. FSF is one of the largest copyright holders in the world of

GPL'd software, but we are by no means the only one. Thus, we sometimes

discover that while GPL'd code is present in the software, there is no

software copyrighted by FSF present.

In cases where FSF does not hold copyright interest in the software, but

we have confirmed a violation, we contact the copyright holders of the

software, and encourage them to enforce the GPL\@. We offer our good offices

to help negotiate compliance on their behalf, and many times, we help as a

third party to settle such GPL violations. However, what we will describe

primarily in this course is FSF's first-hand experience enforcing its own

copyrights and the GPL\@.

\section{First Contact}

The Free Software community is built on a structure of voluntary

cooperation and mutual help. Our community has learned that cooperation

works best when you assume the best of others, and only change policy,

procedures and attitudes when some specific event or occurrence indicates

that a change is necessary. We treat the process of GPL enforcement in

the same way. Our goal is to encourage violators to join the cooperative

community of software sharing, so we want to open our hand in friendship.

Therefore, once we have confirmed a violation, our first assumption is

that the violation is an oversight or otherwise a mistake due to confusion

about the terms of the license. We reach out to the violator and ask them

to work with us in a collaborative way to bring the product into

compliance. We have received the gamut of possible reactions to such

requests, and in this course, we examine four specific examples of such

compliance work.

% FIXME: make this section properly TeX-formatted

\chapter{ThinkPenguin Wireless Router: Excellent CCS}

Too often, case studies examine failure and mistakes.  Indeed, most of the

chapters that follow herein will consider the myriad difficulties discovered

in community-oriented GPL enforcement for the last two decades.  However, to

begin, we offer a study in how copyleft compliance can be done correctly.

This example is, in fact, more than ten years in the making.  Since almost

the inception of for-profit corporate adoption of Free Software, companies

have requested a clear example of a model citizen to emulate.  Sadly, while

community-oriented enforcers have vetted uncounted thousands of ``Complete,

Corresponding Source'' CCS candidates from hundreds of companies, the CCS

release describes the first one CCS experts have declared a ``pristine

example''.

% FIXME (above): link to a further discussion of CCS in the compliance guide

% when a good spot exists, then (below) link to a ``CCS iteration''

% discussion in compliance-guide.tex when one exists.  (the ``iteration

% process'' is discussed in~\ref{} of this guide)

Of course, most CCS examined for the last decade has (eventually) complied

with the GPL, perhaps after many iterations of review by the enforcer.

However, in the experience of the two primary community-oriented enforcers,

Conservancy and the FSF, such CCS results routinely fix the description of

``barely complies with GPL's requirements''.  To use an academic analogy:

while a ``C'' is certainly a passing grade, any instructor prefers to

disseminate to the class an exemplar sample that earned an ``A''.

Fortunately, thanks in large part to the FSF's

``Respects Your Freedom'' (RYF) certification campaign\footnote{\href{http://www.fsf.org/resources/hw/endorsement/respects-your-freedom}{RYF is

    a campaign by FSF to certify products that truly meet the principles of

    software freedom}.  Products must meet

  \href{http://www.fsf.org/resources/hw/endorsement/criteria}{strict

    standards for RYF certification}, and among them is a pristine example of

  CCS\@.}, electronics products have begun to appear on the market that are

held to a higher standard of copyleft compliance.  As such, for the first

time in the history of copyleft, CCS experts have pristine examples to study

and present as exemplars worthy of emulation.

This case study therefore examines the entire life-cycle of a GPL compliance

investigation: from product purchase, to source request, to CCS review.

Specifically, this chapter discusses the purchase, CCS provision, and a

step-by-step build and installation analysis of a specific, physical,

embedded electronics product.  The product in question is

\href{https://www.thinkpenguin.com/gnu-linux/free-software-wireless-n-broadband-router-gnu-linux-tpe-nwifirouter}{the

  ``TPE-NWIFIROUTER'' wireless router by ThinkPenguin}.\footnote{The FSF of

  course performed a thorough CCS check as part of the certification process.

  The analysis discussed herein was independently performed by Software

  Freedom Conservancy without reviewing any findings of the FSF, and thus the

  analysis provides a ``true to form'' analysis as it occurs when Conservancy

  investigates a potential GPL violation.  In this case, obviously, no

  violation was uncovered.}

\section{Consumer Purchase and Unboxing}

The process for copyleft compliance investigation, when properly conducted,

determines whether users inclined to exercise their rights under a copyleft

license will be successful in their attempt.  Therefore, at every stage, the

investigator seeks to take actions that reasonably technically knowledgeable

users would during the ordinary course of their acquisition and use of

products.  As such, the investigator typically purchases the device on the

open market to verify that distribution of the copylefted software therein

complies with binary distribution requirements (such as those

\tutorialpartsplit{discussed in \textit{Detailed Analysis of the GNU GPL and

    Related Licenses}}{discussed here in \S~\ref{GPLv2s3} and

  \S~\ref{GPLv3s6}}).

% FIXME: Above is my only use of \tutorialpartsplit in this chapter.  I just

% got lazy and that should be fixed by someone.

\label{thinkpenguin-included-ccs}

Therefore, the investigator first purchased the TPE-NWIFIROUTER through an

online order, and when the package arrived, examined the contents of the box.

The investigator immediately discovered that ThinkPenguin had taken advice

from \S~\ref{offer-for-source} in this guide, and had chosen to use

\hyperref[GPLv2s3a]{GPLv2\S3(a)} and \hyperref[GPLv3s6]{GPLv3s6}, rather than

using the \hyperref[offer-for-source]{problematic offer for source

  provisions}.  This choice not only speeds up the investigation (since there

is no CCS offer to test), but also simplifies the compliance requirements for

ThinkPenguin.

\section{Root Filesystem and Kernel Compilation}

The CD found in the box was labeled ``libreCMC v1.2.1 source code'', and

contained 407 megabytes of data.  The investigator copied this ISO and

examined its contents.  Upon doing so, the investigator immediately found a

file called ``README'' at the top-level directory:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

  $ dd if=/dev/cdrom of=libreCMC_v1.2.1_SRC.iso

  $ mkdir libCMC

  $ sudo mount -o loop ./libreCMC_v1.2.1_SRC.iso libCMC

  mount: block device /path/to/libreCMC_v1.2.1_SRC.iso is write-protected, mounting read-only

  $ ls -1 libCMC

  bin

  librecmc-u-boot.tar.bz2

  librecmc-v1.2.1.tar.bz2

  README

  u-boot_reflash

  $ cat libCMC/README

\end{lstlisting}

\label{thinkpenguin-toplevel-readme}

The investigator therefore knew immediately to begin the CCS check by

studying the contents of the ``README'', which contained the appropriate

details to get started with a build:

\begin{quotation}

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).

\end{quotation}

In other words, the first ``script'' that investigator ran in building

testing this CCS candidate was the above, which ran on the investigator's own

brain --- like a script of a play.  Less glibly, instructions written in

English are particularly necessary for parts of the build and installation

process that require some amount of actual intelligence to complete.

In this case, the investigator was able to determine the requirements for the

host system to use when constructing the firmware for the embedded device.

GPL does not, of course, give specific guidance on the form or location of

such instructions.  Community-oriented GPL enforcers generally use a

reasonableness standard to evaluate such instructions.  If an investigator of

average skill in embedded firmware construction can surmise the proper

procedures to build and install a replacement firmware, the instructions are

likely sufficient to meet GPL's requirements.  However, in this case, the

instructions are more abundant and give more detail.

These instructions are more general than typical.  Often, top-level build

instructions will specifically name a host distribution to use, such as

``Debian 7 installed on an amd64 system with the following packages

installed''.  If the build will not complete on any other system,

instructions should have such details.  However, in this case, the CCS can

build on a wide range of distributions, and thus no specific distribution was

specified.

\label{thinkpenguin-specific-host-system}

In this specific case, the developers of the libreCMC project (on which the

TPE-NWIFIROUTER is based) have clearly made an effort to ensure the CCS builds

on a variety of host systems.  The investigator was in fact dubious upon

seeing these instructions, since finicky embedded build processes usually

require a very specific host system.   Even in this case, a

\hyperref[thinkpenguin-glibc-214-issue]{minor annoyance was found that more

  detailed instructions would address}.

Anyway, since these instructions did not specify a specific host system, the

investigator simply used his own amd64 Debian 6 desktop system.  Before

beginning, the investigator used the following command:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

  $ dpkg --list | egrep '^iii' | less

\end{lstlisting}

to verify that the required packages listed in the README were

installed\footnote{The ``dpkg'' command is a Debian-specific way of

  finding installed packages.}.

Next, the investigator then extracted the primary source package with the

following command:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

  $ tar --posix -jxpf libCMC/librecmc-v1.2.1.tar.bz2

\end{lstlisting}

The investigator did notice an additional source release, entitled

``librecmc-u-boot.tar.bz2''.  The investigator concluded upon simple

inspection that the instructions found in ``u-boot\verb0_0reflash'' were

specific instructions for that part of the CCS\@.  This was a minor

annoyance, and ideally the ``README'' would list that fact, but the existing

layout met the reasonable standard that community-oriented GPL enforcers

typically apply, since the skilled investigator could determine the correct

course of action with a few moments of study.

The investigator then noted the additional step offered by the ``README'',

which read:

\begin{quotation}

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.

\end{quotation}

This instruction actually goes above and beyond the requirements of GPL\@.

Specifically, the instruction guides users in their first step toward

exercising the freedom to modify the software.  While the GPL does contain

requirements that facilitate the freedom to modify (such as ensuring the CCS is

in the ``preferred form \ldots for making modifications to it'' form), it

does not require that you write specific instructions explaining how

modifications might be undertaken.  This instruction therefore exemplifies

the exceptional quality of this particular CCS\@.

%FIXME: add a \hyperref to some ``preferred for for modification'' stuff above.

However, for purposes of the CCS verification process, typically the

investigator avoids any unnecessary changes to the source code during the

build process, lest the investigator err and cause the build to fail through

his own modification, and thus incorrectly identify the CCS as inadequate.

Therefore, the investigator proceeded to simply run:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

  $ cd libCMC

  $ make

\end{lstlisting}

and waited approximately 40 minutes for the build to complete\footnote{Build

  times will likely vary widely on various host systems.}.  The investigator

kept a

\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_librecmc-complete.log}{full

  log of the build}, which is not included herein due its size (approximately

7.2K of text).

\label{thinkpenguin-main-build}

Upon completion of the ``make'' process, the investigator immediately found

(almost to his surprise) several large firmware files in the ``bin/ar71xx''

directory.  Typically, this step in the CCS verification process is

harrowing.  In most cases, the ``make'' step will fail due to a missing

package or because toolchain paths are not setup correctly.

From experience, the investigator is sure that ThinkPenguin's engineers did

the most important step in self-CCS verification: use one's own instructions

on a clean system.  Ideally, an employee with similar skills but

unfamiliar with the specific product can most easily verify CCS  and identify

problems before a violation occurs.

% FIXME: Is there stuff about the above in the compliance guide?  If so, link

% to it.  If not, write it, then link to it. :)

However, upon completing the ``make'', the investigator was unclear which

filesystem and kernel images to install on the TPE-NWIFIROUTER hardware.

Ideally, the original ``README'' would indicate which image is appropriate

for the included hardware.  However, this was ultimately an annoyance rather

than a compliance issue due to other information available.  Specifically,

the web UI (see next section) on the TPE-NWIFIROUTER performs firmware image

installation.  Additionally, the router's version number was specified on the

bottom of the device, which indicated which of the differently-versioned images

we should install.  It would be ideal to find

\href{http://librecmc.org/librecmc/wiki?name=Tp+MR3020}{instructions similar

  to these} in the README itself.  However, application of the reasonableness

standard indicates compliance, since a knowledgeable user was able to

determine the proper course of action.

\section{U-Boot Compilation}

%FIXME: link to u-boot reflash, maybe put it in log-output dir?

The investigator then turned his attention to the file,

``u-boot\verb0_0reflash'' instructions.  These instructions explained how to

build and install the bootloader for the device.

The investigator followed the instructions for compiling U-Boot, and found

them quite straight-forward.  The investigator discovered two minor

annoyances, however, while building U-Boot:

\begin{itemize}

 \item The variable \verb0$U-BOOT_SRC0 was used as a placeholder for the name

   of the extracted source directory.  This was easy to surmise and was not a

   compliance issue (per the reasonableness standard), but explicitly stating

   that at the top of the instructions would be helpful.

\label{thinkpenguin-glibc-214-issue}

\item Toolchain binaries were included and used by default by the build

  process.  These binaries were not the appropriate ones for the

  investigator's host system, and the build failed with the following error:

\lstset{tabsize=2}

\begin{lstlisting}

mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6:

   version `GLIBC`_2.14' not found

     (required by mips-librecmc-linux-uclibc-gcc.bin)

\end{lstlisting}

   (The

\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-build_fail.log}{complete

  log output from the failure} is too lengthy to include herein.)

   This issue is an annoyance, not a compliance problem.  It was clear from

   context that these binaries were simply for a different architecture, and

   the investigator simply removed ``toolchain/bin'' and used a symlink to

   utilize the toolchain already built earlier (during the compilation

   discussed in \S~\ref{thinkpenguin-main-build}):

\lstset{tabsize=2}

\begin{lstlisting}

  $ ln -s \

  ../../staging_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/bin \

  toolchain/bin

\end{lstlisting}

   After this change, the U-Boot build completed successfully.

\end{itemize}

The

\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-finish_build.log}{full

  log of the build} is not included herein due its size (approximately 3.8K

of text).  After that, the investigator found a new U-Boot image in the

``bin'' directory.

\section{Root Filesystem and Kernel Installation}

The investigator next tested installation of the firmware.  In particular,

the investigator connected the TPE-NWIFIROUTER to a local network, and

visited \url{http://192.168.10.1/}, logged in, and chose the option sequence:

``System $\Rightarrow$ Backup / Flash Firmware''.

From there, the investigator chose the ``Flash new firmware image'' section

and selected the

``librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin'' image from

the ``bin/ar71xx'' directory.  The investigator chose the ``v8'' image upon

verifying the physical router read ``v8.2'' on its bottom.  The investigator

chose the ``sysupgrade'' version of the image because this was clearly a

system upgrade (as a firmware already came preinstalled on the

TPE-NWIFIROUTER).

Upon clicking ``Flash image\ldots'', the web interface prompted the

investigator to confirm the MD5 hash of the image to flash.  The investigator

did so, and then clicked ``Proceed'' to flash the image.  The process took

about one minute, at which point the web page refreshed to the login screen.

Upon logging in, the investigator was able to confirm in ``Kernel Log''

section of the interface that the newly built copy of Linux had indeed been

installed.

The investigator confirmed that a new version of ``busybox'' had also been

installed by using SSH to connect to the router and ran the command

``busybox'', which showed the newly-compiled version (via its date of

compilation).

%FIXME: dg: can you get me  a screen shot for the Kernel Log above, and paste

%in the output of running busybox ?

%FIXME: bkuhn: the screen shot for the Kernel Log is in the log output dir at

%thinkpenguin_librecmc-built-kernel_log.png and the BusyBox output is in the

%same directory at thinkpenguin_librecmc-built-busybox_output.log - you may want

%to only use part of the BusyBox output (maybe even just the login) for brevity

\section{Firmware Comparison}

To ensure the CCS did indeed correspond to the firmware original

installed on the TPE-NWIFIROUTER, the investigator compared the built

firmware image with the filesystem originally found on the device itself.

The comparison steps were as follows:

\begin{enumerate}

\item Extract the filesystem from the image we built by running

  \href{https://gitorious.org/copyleft-org/gpl-compliance-scripts/source/master:find-firmware.pl}{find-firmware.pl}

  on ``bin/ar71xx/librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin''

  and then running

  \href{http://www.binaryanalysis.org/en/content/show/download}{bat-extratools}'

  ``squashfs4.2/squashfs-tools/bat-unsquashfs42'' on the resulting

  morx0.squash, using the filesystem in the new squashfs-root directory for

  comparison.

\item Login to the router's web interface (at \url{http://192.168.10.1/ }) from a computer that is

  connected to the router.

\item Set a password using the provided link at the top (since the router's

  UI warns that no password is set and asks the user to change it).

\item Login to the router via SSH, using the root user with the

  aforementioned password.

\item Compare representative directory listings and binaries to ensure the set of

  included files (on the router) is similar to those found in the firmware image

  we created (whose contents are now in the local squashfs-root directory).  In

  particular, we did the following comparisons:

  \begin{enumerate}

  \item List the /bin folder (``ls -l /bin'') and confirm the list of files is the same

    and that the file sizes are similar.

  \item Check the ``strings'' output of ``/bin/busybox'' to confirm it is similar in both

   places (similar number of lines and content of lines).  (One cannot directly

   compare the binaries because the slight compilation variations will cause

   some bits to be different.)

 \item Do the above two steps for ``/lib/modules'', ``/usr/bin'', and other directories with

   a significant number of binaries.

 \item Check that the kernel is sufficiently similar.  The investigator

   compared the "dmesg" output both before and after flashing the new

   firmware.  As the investigator expected, the kernel version string was

   similar, but had a different build date and user@host indicator.  (The

   kernel binary itself is not easily accessible from an SSH login, but was

   retrievable using the U-Boot console (the start address of the kernel in

   flash appears to be 0x9F020000, based on the boot messages seen in the

   serial console).

  \end{enumerate}

\end{enumerate}

\section{Minor Annoyances}

As discussed in detail above, there were a few minor annoyances, none of

which were GPL violations.  Rather, the annoyances briefly impeded the

build and installation.  However, the investigator, as a reasonably skilled

build engineer for embedded devices, was able to complete the process with

the instructions provided.

To summarize, no GPL compliance issues were found, and the CCS release was

one of the best ever reviewed by an investigator.  However, the following

annoyances were discovered:

\begin{itemize}

\item Failure to explain how to extract the source tarball and then where to run the

  ``make'' command.

\item Failure to explain how to install the kernel and root filesystem on the

  device; the user must assume the web UI must be used.

\item Including pre-built toolchain binaries that don't work on all systems,

  and failure to put built toolchain binaries in the right location.

\end{itemize}

\section{Lessons Learned}

Companies that seek to redistribute copylefted software can benefit greatly

from ThinkPenguin's example.  Here are just a few of the many lessons that

can be learned here:

\begin{enumerate}

\item Even though copyleft licenses have them,

  \hyperref[thinkpenguin-included-ccs]{\bf avoid the offer-for-source

    provisions.}  Not only does including the CCS alongside binary

  distribution make violation investigation and compliance confirmation

  substantially easier, but more importantly it also

  \hyperref[offer-for-source]{completes the distributor's CCS compliance

    obligations at the time of distribution} (provided, of course, that the

  distributor is otherwise in compliance with copyleft).

\item {\bf Include top-level build instructions in a natural language (such

  as English) in a \hyperref[thinkpenguin-toplevel-readme]{clear and

    conspicuous place}.}  Copyleft licenses require that someone reasonably

  skilled in the art can reproduce your work.  Ultimately, sometimes

  instructions written in English are necessary, and often easier than trying

  to write programmed scripts to do everything.  The ``script'' included can

  certainly be more like the script of a play and less like a Bash script.

\item {\bf Write build/install instructions to the appropriate level of

  specificity}.  The upstream engineers

  in this case study \hyperref[thinkpenguin-specific-host-system]{clearly did

    additional work to ensure functionality on a wide variety of host build

    systems}; this is quite rare.  When in doubt, include the maximum level

  of detail build engineers can provide with the CCS instructions.

\item {\bf Seek to adhere to the spirit of copyleft, not just the letter of

  the license}.  ThinkPenguin uses encouragement of  users to improve and

  make their devices better as a commercial differentiator.  Copyleft advocates

  remain baffled as to why other companies have not realized how the large the

  market for

  users who seek hackable devices continues to grow.  By going beyond the

  mere minimal requirements of GPL, companies can immediately reap the

  benefits in that target market.