@@ -804,193 +804,193 @@ The comparison steps were as follows:
\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}
\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
therefore take an ``innocent until proven guilty $\rightarrow$ guilty
therefore take an ``innocent until proven guilty $\rightarrow$ assume guilty
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).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\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.