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

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Bortez: Modified GCC SDK}

In our first case study, we will consider Bortez, a company that

produces software and hardware toolkits to assist OEM vendors, makers

of consumer electronic devices.

\section{Facts}

One of Bortez's key products is a Software Development Kit (``SDK'')

designed to assist developers building software for a specific class of

consumer electronics devices.

FSF received a report that the SDK may be based on the GNU Compiler

Collection (which is an FSF-copyrighted collection of tools for software

development in C, C++ and other popular languages). FSF investigated the

claim, but was unable to confirm the violation. The violation reporter

was unresponsive to follow-up requests for more information.

Since FSF was unable to confirm the violation, we did not pursue it any

further. Bogus reports do happen, and we do not want to burden companies

with specious GPL violation complaints. FSF shelved the matter until

more evidence was discovered.

FSF was later able to confirm the violation when two additional reports

surfaced from other violation reporters, both of whom had used the SDK

professionally and noticed clear similarities to FSF's GNU GCC\@. FSF's

Compliance Engineer asked the reporters to run standard tests to confirm

the violation, and it was confirmed that Bortez's SDK was indeed a

modified version of GCC\@. Bortez had ported to Windows and added a number

of features, including support for a specific consumer device chipset and

additional features to aid in the linking process (``LP'') for those

specific devices. FSF explained the rights that the GPL afforded these

customers and pointed out, for example, that Bortez only needed to provide

source to those in possession of the binaries, and that the users may need

to request that source (if \S 3(b) was exercised). The violators

confirmed that such requests were not answered.

FSF brought the matter to the attention of Bortez, who immediately

escalated the matter to their attorneys. After a long negotiation,

Bortez acknowledged that their SDK was indeed a modified version of

GCC\@. Bortez released most of the source, but some disagreement

occurred over whether LP was also derivative of GCC\@. After repeated

FSF inquiries, Bortez reaudited the source to discover that FSF's

analysis was correct. Bortez determined that LP included a number of

source files copied from the GCC code-base.

\label{davrik-build-problems}

Once the full software release was made available, FSF asked the violation

reporters if it addressed the problem. Reports came back that the source

did not properly build. FSF asked Bortez to provide better build

instructions with the software, and such build instructions were

incorporated into the next software release.

At FSF's request as well, Bortez informed customers who had previously

purchased the product that the source was now available by announcing

the availability on its Web site and via a customer newsletter.

Bortez did have some concerns regarding patents. They wished to include a

statement with the software release that made sure they were not granting

any patent permission other than what was absolutely required by the GPL\@.

They understood that their patent assertions could not trump any rights

granted by the GPL\@. The following language was negotiated into the release:

\begin{quotation}

Subject to the qualifications stated below, Bortez, on behalf of itself

and its Subsidiaries, agrees not to assert the Claims against you for your

making, use, offer for sale, sale, or importation of the Bortez's GNU

Utilities or derivative works of the Bortez's GNU Utilities

(``Derivatives''), but only to the extent that any such Derivatives are

licensed by you under the terms of the GNU General Public License. The

Claims are the claims of patents that Bortez or its Subsidiaries have

standing to enforce that are directly infringed by the making, use, or

sale of an Bortez Distributed GNU Utilities in the form it was distributed

by Bortez and that do not include any limitation that reads on hardware;

the Claims do not include any additional patent claims held by Bortez that

cover any modifications of, derivative works based on or combinations with

the Bortez's GNU Utilities, even if such a claim is disclosed in the same

patent as a Claim. Subsidiaries are entities that are wholly owned by

Bortez.

This statement does not negate, limit or restrict any rights you already

have under the GNU General Public License version 2.

\end{quotation}

This quelled Bortez's concerns about other patent licensing they sought to

do outside of the GPL'd software, and satisfied FSF's concerns that Bortez

give proper permissions to exercise teachings of patents that were

exercised in their GPL'd software release.

Finally, a GPL Compliance Officer inside Bortez was appointed to take

responsibility for all matters of GPL compliance inside the company.

Bortez is responsible for informing FSF if the position is given to

someone else inside the company, and making sure that FSF has direct

contact with Bortez's Compliance Officer.

\section{Lessons}

This case introduces a number of concepts regarding GPL enforcement.

\begin{enumerate}

\item {\bf Enforcement should not begin until the evidence is confirmed.}

  Most companies that distribute GPL'd software do so in compliance, and at

  times, violation reports are mistaken. Even with extensive efforts in

  GPL education, many users do not fully understand their rights and the

  obligations that companies have. By working through the investigation

  with reporters, the violation can be properly confirmed, and {\bf the

    user of the software can be educated about what to expect with GPL'd

    software}. When users and customers of GPL'd products know their

  rights, what to expect, and how to properly exercise their rights

  (particularly under \S 3(b)), it reduces the chances for user

  frustration and inappropriate community outcry about an alleged GPL

  violation.

\item {\bf GPL compliance requires friendly negotiation and cooperation.}

  Often, attorneys and managers are legitimately surprised to find out

  GPL'd software is included in their company's products. Engineers

  sometimes include GPL'd software without understanding the requirements.

  This does not excuse companies from their obligations under the license,

  but it does mean that care and patience are essential for reaching GPL

  compliance. We want companies to understand that participating and

  benefiting from a collaborative Free Software community is not a burden,

  so we strive to make the process of coming into compliance as smooth as

  possible.

\item {\bf Confirming compliance is a community effort.}  The whole point

  of making sure that software distributors respect the terms of the GPL is to

  allow a thriving software sharing community to benefit and improve the

  work. FSF is not the expert on how a compiler for consumer electronic

  devices should work. We therefore inform the community who originally

  brought the violation to our attention and ask them to assist in

  evaluation and confirmation of the product's compliance. Of course, FSF

  coordinates and oversees the process, but we do not want compliance for

  compliance's sake; rather, we wish to foster a cooperating community of

  development around the Free Software in question, and encourage the