%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''.  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 fact 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 host architecture, and

   the investigator simply removed ``toolchain/bin'' and created 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 the ``Kernel Log''

section of the web 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{U-Boot Installation}

The U-Boot installation process is substantially more complicated than the

firmware update.  The investigator purchased the optional serial cable

along with the TPE-NWIFIROUTER, in order to complete the U-Boot installation

per the instructions in ``u-boot\verb0_0reflash'' in its section ``Installing

u-boot to your router'', which reads:

\begin{quotation}

  \begin{enumerate}

    \item Install and configure any TFTP server on your PC (tftp-hpa).

       Set a fixed IP address on your PC \ldots and connect it to the router,

       using RJ45 network cable \ldots

 \item Connect USB to UART adapter to the router and start any application to

   communicate with it, like PuTTY. \ldots

   \item Power on the router, wait for a line like one of the following and

     interrupt the process of loading a kernel:

\begin{verbatim}

 Autobooting in 1 seconds

      (for most TP-Link routers, you should enter tpl at this point)

Hit ESC key to stop autoboot: 1 (for 8devices Carambola 2, use ESC key)

 Hit any key to stop autoboot: 1 (for D-Link DIR-505, use any key)

\end{verbatim}

\item   Set ipaddr and serverip environment variables:

\lstset{tabsize=2}

\begin{lstlisting}

    hornet> setenv ipaddr 192.168.1.1

    hornet> setenv serverip 192.168.1.2

\end{lstlisting}

  \end{enumerate}

\end{quotation}

%FIXME: image of the serial cable available anywhere to put here:

%  https://www.adafruit.com/images/970x728/954-02.jpg

The investigator used the purchased serial cable, which was a USB serial

adapter with a male USB type A connector to 4 female jumper wires.  The

female jumper wires were red, black, white, and green.

The instructions here were slightly incomplete, since they did not specify

how to connect the wires to the router.  However, the investigator found

general information available online at

\url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} which

described the proper procedure.  While the ``power'' and ``ground'' cables

were obvious, some trial and error was necessary to find the RX and TX

cables, but this was easily determined since miswiring TX and RX yields no

I/O and proper wiring yields the output as expected.  Using the pin gender

changer included with the adapter, the investigator was able to stably wire

the pins for use once the proper RX and TX connections were determined.

The investigator then used the recommended 115200 8N1 for serial console

settings, leaving all flow control off, and tested both with the

\verb0minicom0 and \verb0screen0 commands.  The investigator found that if

all 4 wires were connected on the USB serial adapter that the router would

start without additional power and the console would receive the startup

messages.  The investigator could replicate the same behavior by omitting the

power cable from the USB serial adapter (red wire) and connecting the main

power adapter to the router instead.

At this point, the on-screen messages as described in the installation

instructions appeared, but the investigator found that no key events sent via

the serial port appeared to reach the U-Boot console.  In other words, while

the investigator saw both U-Boot and kernel boot messages in the serial

console, the investigator was unable to interrupt the boot process as

instructed by ``u-boot\verb0_0reflash''.  Hitting a key simply did

\textit{not} interrupt the boot process and yield the \verb0hornet>0 prompt.

After additional trial and error over a period of hours, the investigator had

finally to consider this question for the first time during the process:

``Has ThinkPenguin violated the GPL?'' More specifically, the immediate

question was: ``Given this failure, has the distributor met

\hyperref[GPLv2s3-build-scripts]{the requirements for `scripts used to

  control \ldots installation of the executable' (GPLv2)} and

\hyperref[GPLv3-installation-information]{necessary `Installation

  Information' (GPLv3)}?''

The appropriate answer to the question (at this specific stage) is ``possibly,

but more information is needed''.  Embedded installation and configuration is

a tricky and complex technical process.  While the GPL requires documentation

and clear instructions for this process, the investigator did not immediately blame the distributor

for what may be an honest, correctable mistake, or an issue legitimately explained by

feasible alternative theories.

In this case, upon remembering the issues of wiring, the investigator wonder

if perhaps the power pin was accidentally connected for a moment to the RX

pin while live.  Such action could easily fry the RX pin, and yield the

observed behavior.  Since the investigator could not rule out the possibility

of accidental connection of power to the RX pin mentioned, the investigator

had to assume the instructions would work properly if he had not made that

error.

That conclusion, while correct, also left the investigator with only two

option to complete the final verification of the CCS:

\begin{itemize}

   \item Purchase a new router and cable anew, and reattempt the installation

     process while taking extra care not to miswire any cables.

   \item Seek assistance from the libreCMC community to find an alternative

     method of installation.

\end{itemize}

The investigator chose the latter and then contacted a libreCMC developer

familiar with the product.  That developer, who  agreed the the RX pin was

likely ruined, described an alternative method for console access using the

{\tt netcat}.  The libreCMC developer described the process as follows:

\begin{quotation}

  \begin{itemize}

  \item Change the IP address of the router to 192.168.1.1.

  \item Change the IP address of a desktop GNU/Linux system to 192.168.1.2.

  \item Power on the router while holding the reset button for 7 seconds.

  \item Use the {\tt netcat} command (as below) on the desktop, and press

    enter to receive U-Boot's prompt:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

$ nc -u -p 6666 192.168.1.1 6666

uboot>

\end{lstlisting}

  \end{itemize}

\end{quotation}

Upon following this procedure, the investigator was able to confirm the

(original) shipped version of U-Boot was still installed:

\begin{lstlisting}[language=bash]

$ nc -u -p 6666 192.168.1.1 6666

uboot> version

U-Boot 1.1.4 (Jul 28 2014)

\end{lstlisting}

Thereafter, the investigator followed the instructions from

``u-boot\verb0_0reflash''.  Specifically, the investigator configured a TFTP server

and placed the newly built firmware into \texttt{/srv/tftp}.  The investigator

also followed the remaining instructions in ``u-boot\verb0_0reflash'', but

used the \texttt{netcat} console rather than the serial console, and

used U-Boot's \texttt{reset} command to reboot the router.

Upon reboot, the serial console (still connect with working output) showed

the message \texttt{U-Boot 1.1.4  (Oct 17 2014)}, and thus confirmed a

successful reflash of the U-Boot image built by the investigator.

\section{Firmware Comparison}

Next, 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

  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 Logged into the router via SSH, using the root user with the

  aforementioned password.

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

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

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

  particular, the investigator did the following comparisons:

  \begin{enumerate}

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

    and that the file sizes are similar.

  \item Checked 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 Repeated the above two steps for ``/lib/modules'', ``/usr/bin'', and other directories with

   a significant number of binaries.

 \item Checked that the kernel was 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 any investigator at any community-oriented

enforcement organization.  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 copy and/or symlink built toolchain binaries in the right location.

\item Failure to include information in the U-Boot installation instructions for

  wiring the serial cable.

\item Ideally, the U-Boot installation instructions would also include the

  {\tt netcat} method of installation.

\item Finally, the instructions should note that the new U-Boot firmware

  should be placed into \texttt{/srv/tftp} when using TFTP on most GNU/Linux

  desktops.

\end{itemize}

Thus, no CCS is absolutely perfect, but GPL violation investigators always

give the distributors the benefit of any doubts and seek to work with the

vendors and improve their CCS for the betterment of their users, customers,

and the entire software freedom community.

\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 also (and more importantly) doing so

  \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 the relevant copyleft license).

\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 the build and installation.  Typically,

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

  programmed scripts.  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, but also

  double-check to investigate if a more generalized solution (such as other

  host systems) work just as well for the build.

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

  the license}.  Encouragement of users to improve and

  make their devices better is one of ThinkPenguin's commercial differentiators.  Copyleft advocates

  that other companies have undervalued the large and lucrative

  market of

  users who seek hackable devices.  By going beyond the

  mere minimal requirements of GPL, companies can immediately reap the

  benefits in that target market.

  \item Community-oriented enforcement organizations do not play ``gotcha''\footnote{For lack of a better

    phrase.} with distributors regarding GPL

    violations.  The goal in the GPL enforcement process is to achieve

    compliance and correct mistakes and annoyances.  Such organizations

    due to honest error rather than malicious action '' approach.  The goal

    is compliance (in direct contrast with

    the \hyperref[Proprietary Relicensing]{discussion in \S~\ref*{Proprietary Relicensing} about the

      proprietary relicensing} business model).

\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

  once-violator to begin participating in that community.

\item {\bf Informing the harmed community is part of compliance.} FSF asks

  violators to make some attempt --- such as via newsletters and the

  company's Web site --- to inform those who already have the products as

  to their rights under the GPL\@. One of the key thrusts of the GPL's \S 1 and

  \S 3 is to {\em make sure the user knows she has these rights\/}. If a

  product was received out of compliance by a customer, she may never

  actually discover that she has such rights. Informing customers, in a

  way that is not burdensome but has a high probability of successfully

  reaching those who would seek to exercise their freedoms, is essential

  to properly remedy the mistake.

\item {\bf Lines between various copyright, patent, and other legal

  mechanisms must be precisely defined and considered.}  The most

  difficult negotiation point of the Bortez case was drafting language

  that simultaneously protected Bortez's patent rights outside of the

  GPL'd source, but was consistent with the implicit patent grant in

  the GPL\@. As we discussed in the first course of this series, there is

  indeed an implicit patent grant with the GPL, thanks to \S 6 and \S 7.

  However, many companies become nervous and wish to make the grant

  explicit to assure themselves that the grant is sufficiently narrow for

  their needs. We understand that there is no reasonable way to determine

  what patent claims read on a company's GPL holdings and which do not, so

  we do not object to general language that explicitly narrows the patent

  grant to only those patents that were, in fact, exercised by the GPL'd

  software as released by the company.

\end{enumerate}

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

\chapter{Bracken: a Minor Violation in a GNU/Linux Distribution}

In this case study, we consider a minor violation made by a company whose

knowledge of the Free Software community and its functions is deep.

\section{The Facts} 

Bracken produces a GNU/Linux operating system product that is sold

primarily to OEM vendors to be placed in appliance devices used for a

single purpose, such as an Internet-browsing-only device. The product

is almost 100\% Free Software, mostly licensed under the GPL and related

Free Software licenses.

FSF found out about this violation through a report first posted on a

  Slashdot\footnote{Slashdot is a popular news and discussion site for

  technical readers.} comment, and then it was brought to our attention again

  by another Free Software copyright holder who had discovered the

  same violation.

Bracken's GNU/Linux product is delivered directly from their Web site.

This allowed FSF engineers to directly download and confirm the

violation quickly. Two primary problems were discovered with the

online distribution:

\begin{itemize}

\item No source code nor offer for source code was provided for a number

  of components for the distributed GNU/Linux system; only binaries were

  available

\item An End User License Agreement (``EULA'') was included that

  contradicted the permissions granted by the GPL\@

\end{itemize}

FSF contacted Bracken and gave them the details of the violation. Bracken

immediately ceased distribution of the product temporarily and set forth

a plan to bring themselves back into compliance. This plan included the

following steps:

\begin{itemize}

\item Bracken attorneys would rewrite the EULA to comply with the GPL and

  would vet the new EULA through FSF before use

\item Bracken engineers would provide source side-by-side with the

  binaries for the GNU/Linux distribution on the site (and on CD's, if

  ever they distributed that way)

\item Bracken attorneys would run an internal seminar for its engineers

  regarding proper GPL compliance to help ensure that such oversights

  regarding source releases would not occur in the future

\item Bracken would resume distribution of the product only after FSF

  formally restored Bracken's distribution rights

\end{itemize}

This case was completed in about a month. FSF approved the new EULA

text. The key portion in the EULA relating to the GPL read as follows:

\begin{quotation}

Many of the Software Programs included in Bracken Software are distributed

under the terms of agreements with Third Parties (``Third Party

Agreements'') which may expand or limit the Licensee's rights to use

certain Software Programs as set forth in [this EULA]. Certain Software

Programs may be licensed (or sublicensed) to Licensee under the GNU

General Public License and other similar license agreements listed in part

in this section which, among other rights, permit the Licensee to copy,

modify and redistribute certain Software Programs, or portions thereof,

and have access to the source code of certain Software Programs, or

portions thereof. In addition, certain Software Programs, or portions

thereof, may be licensed (or sublicensed) to Licensee under terms stricter

than those set forth in [this EULA]. The Licensee must review the

electronic documentation that accompanies certain Software Programs, or

portions thereof, for the applicable Third Party Agreements. To the

extent any Third Party Agreements require that Bracken provide rights to

use, copy or modify a Software Program that are broader than the rights

granted to the Licensee in [this EULA], then such rights shall take

precedence over the rights and restrictions granted in this Agreement

solely for such Software Programs.

\end{quotation}

FSF restored Bracken's distribution rights shortly after the work was

completed as described.

\section{Lessons Learned}

This case was probably the most quickly and easily resolved of all GPL

violations in the history of FSF's Compliance Lab. The ease with which

the problem was resolved shows a number of cultural factors that play a

role in GPL compliance.

\begin{enumerate}

\item {\bf Companies that understand Free Software culture better have an

  easier time with compliance.}  Bracken's products were designed and

  built around the GNU/Linux system and Free Software components. Their

  engineers were deeply familiar with the Free Software ecosystem, and

  their lawyers had seen and reviewed the GPL before. The violation was

  completely an honest mistake. Since the culture inside the company had

  already adapted to the cooperative style of resolution in the Free

  Software world, there was very little work for either party to bring the

  product into compliance.

\item {\bf When people in key positions understand the Free Software

  nature of their software products, compliance concerns are as

  mundane as minor software bugs.}  Even the most functional system or

  structure has its problems, and successful business often depends on

  agile response to the problems that do come up; avoiding problems

  altogether is a pipe dream. Minor GPL violations can and do happen

  even with well-informed redistributors. However, resolution is

  reached quickly when the company --- and in particular, the lawyers,

  managers, and engineers working on the Free Software product lines

  --- have adapted to Free Software culture that the lower-level

  engineer already understood

\item {\bf Legally, distribution must stop when a violation is

  identified.}  In our opinion, Bracken went above and beyond the call of

  duty by ceasing distribution while the violation was being resolved.

  Under GPL \S 4, the redistributor loses the right to distribute the

  software, and thus they are in ongoing violation of copyright law if

  they distribute before rights are restored. It is FSF's policy to

  temporarily allow distribution while compliance negotiations are ongoing

  and only in the most extreme cases (where the other party appears to be

  negotiating in bad faith) does FSF even threaten an injunction on

  copyright grounds. However, Bracken --- as a good Free Software citizen

  --- chose to be on the safe side and do the legally correct thing while

  the violation case was pending. From start to finish, it took less

  than a month to resolve. This lapse in distribution did not, to FSF's

  knowledge, impact Bracken's business in any way.

\item {\bf EULAs are a common area for GPL problems.}  Often, EULAs

  are drafted from boilerplate text that a company uses for all its

  products. Even the most diligent attorneys forget or simply do not

  know that a product contains software licensed under the GPL and other

  Free Software licenses. Drafting a EULA that accounts for such

  licenses is straightforward; the text quoted above works just fine.

  The EULA must be designed so that it does not trump rights and

  permissions already granted by the GPL\@. The EULA must clearly state

  that if there is a conflict between it and the GPL, with regard to GPL'd

  code, the GPL is the overriding license.

\item {\bf Compliance Officers are rarely necessary when companies are

  educated about GPL compliance.}  As we saw in the Bortez case, FSF asks

  that a formal ``GPL Compliance Officer'' be appointed inside a

  previously violating organization to shepherd the organization to a

  cooperative approach to GPL compliance. However, when FSF

  sees that an organization already has such an approach, there is no

  need to request that such an officer be appointed.

\end{enumerate}

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

\chapter{Vigorien: Security, Export Controls, and GPL Compliance}

This case study introduces how concerns of ``security through obscurity''

and regulatory problems can impact GPL compliance matters.

\section{The Facts}

Vigorien distributes a back-up solution product that allows system

administrators to create encrypted backups of file-systems on

Unix-like computers. The product is based on GNU tar, a backup utility

that replaces the standard Unix utility simply called tar, but has

additional features.

Vigorien's backup solution added cryptographic features to GNU tar, and

included a suite of utilities and graphical user interfaces surrounding

GNU tar to make backups convenient.

FSF discovered the violation from a user report, and determined that the

cryptographic features were the only part of the product that constituted

a derivative work of GNU tar; the extraneous utilities merely made

shell calls out to GNU tar. FSF requested that Vigorien come into

compliance with the GPL by releasing the source of GNU tar, with the

cryptographic modifications, to its customers.

Vigorien released the original GNU tar sources, but kept the cryptographic

modifications proprietary. They argued that the security of their system

depending on keeping the software proprietary and that regardless, USA

export restrictions on cryptographic software prohibited such a release.

FSF disputed the first claim, pointing out that Vigorien had only one

option if they did not want to release the source: they would have to

remove GNU tar from the software and not distribute it further. Vigorien

rejected this suggestion, since GNU tar was an integral part of the

product, and the security changes were useless without GNU tar.

Regarding the export control claims, FSF proposed a number of options,

including release of the source from one of Vigorien's divisions overseas

where no such restrictions occurred, but Vigorien argued that the problem

was insoluble because they operated primarily in the USA\@.

The deadlock on the second issue was resolved when those cryptographic

export restrictions were lifted shortly thereafter, and FSF again raised

the matter with Vigorien. At that point, they dropped the first claim and

agreed to release the remaining source module to their customers. They

did so, and the violation was resolved.

\section{Lessons Learned}

\begin{enumerate}

\item {\bf Removing the GPL'd portion of the product is always an

  option.}  Many violators' first response is to simply refuse to

  release the source code as the GPL requires. FSF offers the option to

  simply remove the GPL'd portions from the product and continue along

  without them. Every case where this has been suggested has led to

  the same conclusion. Like Vigorien, the violator argues that the